[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