On Tue, Apr 15, 2014 at 10:18:09AM +0200, Robert Baldyga wrote: > Hi Felipe, > > > >> On 04/02/2014 10:47 AM, Peter Chen wrote: > > >>> We have historic problem that the gadget will not work if the gadget > > >>> is build-in and the udc driver is defered probe due to some > > >>> resources are not ready. Below links are related to this problem. > > >>> > > >>> http://marc.info/?l=linux-usb&m=139380872501745&w=2 > > >>> http://marc.info/?l=linux-usb&m=137991612311893&w=2 > > >>> http://marc.info/?l=linux-usb&m=137706435611447&w=2 > > >>> > > >>> This patch saves pointer of usb_gadget_driver when the udc is not > > >>> ready, and redo usb_gadget_probe_driver when the udc is ready This > > >>> method may not be good enough, but we need to find a way to fix this > > >>> problem, so I post this RFC to see if to see comments, someone may > > >>> have a better solution:) > > >>> > > >> > > >> I have sent patch fixing this problem few weeks ago: > > >> http://www.spinics.net/lists/linux-usb/msg102795.html > > >> > > > > > > Our idea is the same, but your patch is better than me. > > > Felipe queued this patch or not? > > > > > > If it is not, you may need to send v2 that return -ENODEV for not find > > > udc to see if he has further comments, let's try to fix this problem > > > at mainline asap. > > > > > > > Returning -ENODEV doesn't make sense. There is no way to find out if any > > UDC driver is present in system before it will be registered. So you > > can't know, when you should return -ENODEV. > > > > If we really want to return -ENODEV, it will need to modify all UDC > > drivers. They can notify udc-core before returning -EPROBE_DEFER that > > they will register in the future, so gadget drivers can be added to > > driver_list. In another case we can return -ENODEV. > > > > What do you think about this solution? > > We still have unsolved problem with deferred probe in UDC drivers, so > there is real need for some fixes. sure, we do need a fix, but it's very difficult to know when we can allow for gadget drivers to be loaded. Think of it this way: say you have a system with a single UDC controller, and we allow for gadget driver probe deferral. First gadget driver you load binds to the UDC, second gadget driver you load will defer forever, but will still "probe" (in a sense). lsmod will show two gadget drivers. Now say you want to use that gadget driver which is deferred, you unload first gadget driver and then nothing happens because you have no way to tell that gadget driver that you want it to bind to the UDC which is now available. see the problem ? -- balbi
Attachment:
signature.asc
Description: Digital signature
