[PATCH linux 14/15] drivers/fsi: Rename slave to cfam
Christopher Bostic
christopher.lee.bostic at gmail.com
Fri Oct 7 00:41:23 AEDT 2016
On Thu, Oct 6, 2016 at 1:58 AM, Jeremy Kerr <jk at ozlabs.org> wrote:
> Hi Chris,
>
>> Suggested changes to the patch set so far as provided by Jeremy Kerr.
>> Rename slave to cfam to distinguish between the slave engine and its
>> containing cfam.
>
> I'm still not 100% on that. As is my understanding, a (hardware) CFAM
> contains multiple slaves, and that not what `struct fsi_slave`
> represents (it's a single slave).
In redundant configurations yes there are two slaves. However, any
controlling device driver would only ever use one of them. A redundant
system with its own fsi device driver would be controlling the other slave.
I still maintain that there is bound to be confusion with slave->read( )
etc... which are meant for accessing more than just the slave engine.
cfam->read makes it more clear I think that you are accessing some
range within the cfam, not just the slave engine. A cfam acts as a slave
in a general sense but it doesn't distinguish itself from the slave engine.
If this is a big sticking point I'll rename it to slave and deal with the
potential ambiguity that may come up later. I'd like to move ahead
with the rest of the implementation.
>
>> A few formatting changes to make checkpatch accept
>> patches 0001-0013.
>
> Those would be better split out. If you like, I can then take that
> change and re-roll my original skeleton series with that incorporated.
>
I'm not sure what split out means in this case. Git am applies each patch
in sequence so those warnings will be hit before any patches I add to reverse
something are applied.
I know we had discussed last week about making it clear what changes
you had made versus mine. As per discussion I left your changes as
is in the patch series, then made my recommended changes as the
next in the series. A bit confusing on how to deal with checkpatch,
git am, ... in those circumstances.
> Cheers,
>
>
> Jeremy
More information about the openbmc
mailing list