On Wed, Aug 14, 2013 at 12:47:44PM -0700, Greg KH wrote: > On Wed, Aug 14, 2013 at 08:39:50PM +0100, Mark Brown wrote: > > That resource is the USB bus I think (I suspect the issue is that the > > fact that power is always present confuses the USB enumeration protocol > > if the device gets brought out of reset prior to the bus being live). > Which USB bus is it? How is this device even probed before the device > is found by the bus? > Ah crud, this is an i2c driver, not a USB driver, no wonder I'm > confused... Well, in this case it's actually only got the GPIOs wired up so fortunately we don't care about the I2C case. This was why I did all that stuff with the platform device - it was only once I'd done that that I realised that it wasn't enough just to set the GPIOs but that they needed to be set at a particular time. Having to cope with I2C would indeed be a pain and it's one that I'm not even trying to confront right now. > You are going to have to find some kind of relationship here, not just > by linker order, otherwise you are going to have problems later on. Oh, clearly - it's not a solution, it's just a really cheap workaround. > > The normal way to grab that resource would be to make the device a > > device on the bus but currently the only way USB gets children is via > > USB enumeration. > Perhaps make this device a child of the USB controller in the DT > description? Yeah, that's the ideal thing and one of the cases I'm thinking of with the whole thing about telling buses that they have children with device data before the devices get probed. People probably also want this to work for ACPI, or at least would find it convenient to have that - I first looked at USB due to chatting to one those guys. > > Right, and I did discuss that with Tushar elsehwere prior to this being > > posted here. We figured given how cheap and non-invasive the workaround > > is it was worth just doing it. > Nope, sorry, I'm not going to take it. Fair enough, that was my first reaction to it too but we figured it was worth considering. > > > So this patch wouldn't really solve the problem, only paper over it for > > > one type of configuration (i.e. driver built into the system), right? > > Yes, though realistically nobody actually does that for the relevant > > systems and if they do it's always possible to control the module load > > order if you really want to. > But you aren't telling anyone that is what is needed. How would anyone > know that they need to control the load order? By debugging it and finding the late initcall. Worst case it'd work just as well as it does now, best case it might do better until the problem actually gets fixed. Like I say for all practical purposes nobody does that, everyone running these boards builds everything into the kernel - that's the model for Android (which is the only thing the board vendor supports) and realistically it's not a system you build general purpose things for even in development.
Attachment:
signature.asc
Description: Digital signature
