> > On 04/03/2014 03:52 AM, Peter Chen wrote: > > > >> > >> Hi Peter, > >> > >> 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. > Sorry, I did not check it carefully that some gadget drivers have compared usb_composite_probe return value. Peter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
