On Fri, Aug 6, 2010 at 5:46 PM, Greg KH <gregkh@xxxxxxx> wrote: > On Fri, Aug 06, 2010 at 09:12:27AM -0600, Grant Likely wrote: >> On Fri, Aug 6, 2010 at 8:27 AM, Greg KH <gregkh@xxxxxxx> wrote: >> > On Thu, Aug 05, 2010 at 04:59:35PM -0600, Grant Likely wrote: >> >> (On that point Greg, what is the reason for even having the >> >> /sys/devices/platform/ parent? Why not just let the platform devices >> >> sit at the root of the device tree? In the OF case (granted, I'm >> >> biased) all of the platform_device registrations reflect the actual >> >> device hierarchy expressed in the device tree data.) >> > >> > If we sat them at the "root", there would be a bunch of them there. I >> > don't know, we could drop the parent, I guess whoever created the >> > platform device oh so long ago, decided that it would look nicer to be >> > in this type of structure. >> >> Personally I'd rather see a meaningful structure used here. Maybe >> having them all in the root will encourage people to find realistic >> parents for their platform devices. :-) > > That would be nice, but take your "standard" PC today: > > ls /sys/devices/platform/ > Fixed MDIO bus.0 i8042 pcspkr power serial8250 uevent vesafb.0 > > There are tty devices below the serial port, which is nice to see, but > the others? I don't know what type of bus they would be on, do you? Does it matter? On my PC I count 7 devices. On my servers, I see the same. I don't personally don't see any disadvantage to having them at the root. However, looking at them: "Fixed MDIO bus" is actually a complete hack that I'm going to try and get rid of. i8042 is keyboard/mouse that probably lives on the southbridge. I imagine hanging off the PCI bus in the ISA IO range. ditto pcspkr ditto serial8250 ditto vesafb I wouldn't have any problem modifying those specific drivers to register under something like /sys/devices/legacy, but I don't really think it is in any way necessary. I suppose one *could* try to figure out the actual PCI topology that leads to these devices, but that gets into trying to guess what the BIOS set up to decide where to register those things. Probably a lot of error-prone work for absolutely no benefit. :-) However, on the embedded side I'm seeing a lot of devices show up under /sys/devices/platform. Embedded is generally different. We *know* what the bus topology is. However, it seems to me that many developers are under the mistaken assumption that platform devices must live in /sys/devices/platform, so they don't bother reflecting the topology in the device model and it seems to be affecting how embedded PM is being approached (my opinion). Removing the "struct device platform_bus" may reduce the confusion. >> Why don't I float a patch to remove this and see if anybody freaks >> out. Should I wrap it with a CONFIG_ so that it can be configurable >> for a release or to, or just make it unconditional? > > If you can figure out a structure for the desktop/server machines, sure, > I say just always enable it :) I've got a patch in my tree now. I'll play with it a bit before posting it for RFC. g. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
