[PATCH 1/4] [SPI] spi_mpc83xx: convert to the OF platform driver

Grant Likely grant.likely at secretlab.ca
Thu May 22 03:17:49 EST 2008

On Wed, May 21, 2008 at 11:05 AM, Anton Vorontsov
<avorontsov at ru.mvista.com> wrote:
> On Wed, May 21, 2008 at 10:50:02AM -0600, Grant Likely wrote:
> [..]
>> > +
>> > +       master->num_chipselect = of_num_children(np);
>> This assumes that there are no gaps in the assigned CS numbers of
>> child nodes, or that the child nodes are an exhaustive list of
>> attached devices, neither of which may be true.  num_chipselect should
>> be calculated from the number of GPIOs specified instead.
> [I'm not arguing just a thought.]


Here's some quick feedback off the top of my head...

> - every SPI device must have its own chip-select, otherwise SPI device
>  node should not be a part of a SPI controller node;

How about this example:  Board has SPI controller with 4 CS lines and
4 devices.  Board vendor has 3 versions of board with different
devices populated (Ver1 has all 4; Ver2 has 1 and 3; Ver3 has 1, 3 and
4).  Board firmware drops nodes from tree for non-present devices
before booting kernel (not arguing if this is the best way for
firmware to behave; but it is valid and legal).  Therefore there may
be gaps in the CS assignments.

Or how about this one: the SPI devices are off board and are plugged
in after boot.  They aren't available to be described in the device
tree, but are added at a later time in response to some hot plug
event.  The SPI bus needs to be already set up with the correct number
of CS lines.

I don't think you can assume that the device tree data will be exhaustive.

> - or there is just once device on the SPI bus with chip-select always
>  asserted, no gpios = <> is specified (this case is implemented);
> - or the SPI is bridged, gpios = <> should list behind-the-bridge devices'
>  chip-selects, and driver should understand that there is a "special"
>  (bridge) device somewhere on the bus (not implemented).

In this case, I think the gpios would be a property of the spi-bridge,
not the spi-master.  The gpios of the spi-master would have to specify
how to address the bridge; not the downstream devices.  The bridge;
when addressed correctly; would then proceed with addressing the
downstream.  In other words; the 'reg' of spi-devices attached to a
bridge would be an address that the bridge understands, not an address
that the master understands.


Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

More information about the Linuxppc-dev mailing list