On Thu, 10 Jan 2008 17:50:49 +1100 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> > On Thu, 2008-01-10 at 17:02 +1100, David Gibson wrote: > > On Thu, Jan 10, 2008 at 12:53:57AM -0500, Sean MacLennan wrote: > > > David Gibson wrote: > > > > Hrm... I'd say this is not something which has a firm convention yet. > > > > It's going to become more of an issue once we get a macros system for > > > > dtc, so the "440EP" macro would have all the devices, even if some are > > > > not connected on a given board. > > > > > > > > I'm contemplating suggesting that we adopt the "status" property from > > > > IEEE1275 to cover this. > > > > > > > > > > > When I am laying out the dts, leaving out what isn't used makes the dts > > > file cleaner, at least in my view. It doesn't hurt to have the second > > > i2c bus there, but it also doesn't help and leaving it out points out > > > that it is not used. > > > > > > When we get a macro system I assume the second i2c bus will be there but > > > hidden by a macro. It will still be clean and shouldn't cause grief. > > > > Right, but if it is there we'll want to mark it as unused in some way > > so that the kernel doesn't waste resources attempting to drive it. > > Sure but I don't want to make it mandatory for people to put unused > devices in. If the macro system brings them in, then yes, it's good to > have a way to properly mark them unused. But people hand crafting DTS > shouldn't have to bloat them. > > There is -one- case where you may want to put unused devices, is if you > do some kind of resource management on that specific bus (like need to > be able to dynamically allocate space on the bus). In this case, you > want to know everything that's there and potentially decodes addresses > to avoid collisions. There are other uses too. E.g. pin sharing between devices based on DIP switch settings. You'd want to enumerate all the devices, and then add 'status = "failed-not-connected"' to the ones that don't have pins. josh _______________________________________________ Linuxppc-dev mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-dev
