Ok, elegance apart:-) You can use the SPI-bridge construct to also describe simple SPI-chipselect configurations. But is it really a good idea? Wouldn't it be better to handle these two cases separately?
It would be best to handle all these things that are specific to a certain SPI controller (like how CSs work) in the binding for that SPI controller, and not try to shoehorn all of this into some artificial generic framework. If you can have identical addresses on the SPI bus going to different devices based on which CS is asserted, you'll have to make the CS part of the "reg". Example: spi-controller { #address-cells = 2; #size-cells = 0; [EMAIL PROTECTED],f000 { reg = < 0 f000 >; } // CS 0, SPI address f000 [EMAIL PROTECTED],f000 { reg = < 1 f000 >; } // CS 1, SPI address f000 [EMAIL PROTECTED],ff00 { reg = < 1 ff00 >; } // CS 1, SPI address ff00 } SPI-to-SPI bridges can (and should!) be handled the same way as anything-to-anything-else bridges are handled as well: either there is a nice simple one-to-one matching (and you can use "ranges") or you need a driver for that bridge that knows how to make it work (or both, "ranges" isn't always enough, the bridge might require some specific handling for some special situations -- error handling, suspend, whatever). Segher _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev