On Sat, Aug 17, 2013 at 9:29 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 16 Aug 2013, Mark Brown wrote: > >> > Besides, you need to get the platform information to the driver in any >> > case, no matter how you decide to solve the chicken-and-egg problem. >> > It shouldn't be a factor in deciding which solution to use. >> >> It's not that this is hard, it's that I don't see how if you already >> have some concept of the device in the kernel data structures (which you >> must have in order to be able to provide platform data when it's needed) >> anything is gained by not using that when dealing with bootstrapping >> issues. > > I agree. In fact, there's no choice but to use this device concept > during startup. Otherwise there's no way to get the platform data to > the driver when it is needed, because there's no way to tell which > device the data applies to. The question is how elaborate the concept > needs to be and how it gets used. > > Aong those lines, I would like to point out that the device concept > embodied in the kernel's data structures can be pretty thin. For > example, it might be little more than a port number or bus address. Maybe the principle behind drivers/usb/core/usb-acpi.c is helpful for the problem, and DT may refer to ACPI to describe on-board USB devices, and the way to retrieve platform data too. >> Anyway, I think it's time to try to implement something rather than talk >> about it. > > Hopefully this discussion has given you some ideas for alternative > approachs, or at least helped to solidify your ideas. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
