RE: Fwd: RE: [RFC PATCH 1/1] usb: udc-core: redo usb_gadget_probe_driver when the udc is ready
> > On Wed, 30 Apr 2014, Felipe Balbi wrote: > > > > > 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 ? > > > > > > This is the sort of thing that could be fixed by creating a "gadget" > > > bus type. The user would be able to force a gadget to bind to a UDC > > > by writing to the appropriate sysfs file. > > > > > > Of course, I suppose you could always implement the same sort of > > > functionality with a special-purpose sysfs file, without going to > > > all the effort of adding a new bus type. > > > > Maybe the bus type is what we need to do, something along the lines of > > i2c_bus_type, perhaps ? > > Maybe -- I don't know how the i2c bus type works. But the general idea > is simple enough: Each UDC automatically gets a child device > (representing controller's external interface to the USB bus, as opposed > to its internal interface to an ordinary bus such as PCI or platform), > and each each gadget driver gets registered as a driver on the gadget bus. > > Thus, when a UDC driver registers a controller with udc-core, the core > could dynamically allocate a struct usb_udc_device, which would be little > more than a wrapper around a struct device. The core would register this > device on the gadget bus, on behalf of the UDC driver, as a child of the > actual UDC device. Then binding of gadget drivers to UDCs would be > handled in the same way as binding of any other driver to a device. > > For example, if you had a net2280 card in your computer, the net2280 > driver would bind to the card's PCI device, and udc-core would create a > corresponding usb_gadget device, with a name like "udc-1" -- the full > path would be something like > > /sys/devices/pci:00/:00:1e.0/:01:00.0/udc-1 > > where :01:00.0 is the PCI device corresponding to the net2280 card. > > When a gadget driver registers itself with udc-core, the core would add > the usb_gadget_driver structure to the gadget bus. Then the ordinary > device core mechanism would try to probe each unbound usb_udc_device with > the new gadget driver. This automatic binding might not be what you want, > especially if you have multiple device controllers in the system or > multiple gadget drivers built into the kernel, but the user could always > change the bindings by writing to sysfs files. Can we have multiple gadget drivers build into the kernel? I can't find that way through kernel configuration. > > > The difficulty will be with matching a gadget driver to a particular > > UDC. How would we be able to load g_zero to dwc3 and g_mass_storage to > > dummy ? > > The automatic binding could easily get annoying, but we could disable it > (perhaps by adding a special flag to the bus_type structure). > > At any rate, let's say the dwc3 UDC is registered as > /sys/bus/gadget/devices/udc-1 and the dummy UDC is registered as > /sys/bus/gadget/devices/udc-2. Then you could set up the bindings you > want by doing: > > echo udc-1 >/sys/bus/gadget/drivers/g_zero/bind > echo udc-2 >/sys/bus/gadget/drivers/g_mass_storage/bind > > > Or maybe we load gadgets to the bus and always bind through configfs ?!? > > Maybe. That certainly would be more suitable if the gadget driver needs > to be configured specially for the UDC when it binds. > The most use case is one udc and one gadget, can we take it as default case and use automatic binding, and with another kernel configuration or module parameter to disable automatic binding, and use sys/ entry instead of it? Peter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: RE: [RFC PATCH 1/1] usb: udc-core: redo usb_gadget_probe_driver when the udc is ready
On Wed, Apr 30, 2014 at 03:41:48PM -0400, Alan Stern wrote: > On Wed, 30 Apr 2014, Felipe Balbi wrote: > > > > > 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 ? > > > > > > This is the sort of thing that could be fixed by creating a "gadget" > > > bus type. The user would be able to force a gadget to bind to a UDC > > > by writing to the appropriate sysfs file. > > > > > > Of course, I suppose you could always implement the same sort of > > > functionality with a special-purpose sysfs file, without going to all > > > the effort of adding a new bus type. > > > > Maybe the bus type is what we need to do, something along the lines of > > i2c_bus_type, perhaps ? > > Maybe -- I don't know how the i2c bus type works. But the general idea > is simple enough: Each UDC automatically gets a child device > (representing controller's external interface to the USB bus, as > opposed to its internal interface to an ordinary bus such as PCI or > platform), and each each gadget driver gets registered as a driver on > the gadget bus. > > Thus, when a UDC driver registers a controller with udc-core, the core > could dynamically allocate a struct usb_udc_device, which would be > little more than a wrapper around a struct device. The core would > register this device on the gadget bus, on behalf of the UDC driver, as > a child of the actual UDC device. Then binding of gadget drivers to > UDCs would be handled in the same way as binding of any other driver to > a device. > > For example, if you had a net2280 card in your computer, the net2280 > driver would bind to the card's PCI device, and udc-core would create a > corresponding usb_gadget device, with a name like "udc-1" -- the full > path would be something like > > /sys/devices/pci:00/:00:1e.0/:01:00.0/udc-1 > > where :01:00.0 is the PCI device corresponding to the net2280 card. > > When a gadget driver registers itself with udc-core, the core would add > the usb_gadget_driver structure to the gadget bus. Then the ordinary > device core mechanism would try to probe each unbound usb_udc_device > with the new gadget driver. This automatic binding might not be what > you want, especially if you have multiple device controllers in the > system or multiple gadget drivers built into the kernel, but the user > could always change the bindings by writing to sysfs files. > > > The difficulty will be with matching a gadget driver to a particular > > UDC. How would we be able to load g_zero to dwc3 and g_mass_storage to > > dummy ? > > The automatic binding could easily get annoying, but we could disable > it (perhaps by adding a special flag to the bus_type structure). > > At any rate, let's say the dwc3 UDC is registered as > /sys/bus/gadget/devices/udc-1 and the dummy UDC is registered as > /sys/bus/gadget/devices/udc-2. Then you could set up the bindings you > want by doing: > > echo udc-1 >/sys/bus/gadget/drivers/g_zero/bind > echo udc-2 >/sys/bus/gadget/drivers/g_mass_storage/bind > > > Or maybe we load gadgets to the bus and always bind through configfs ?!? > > Maybe. That certainly would be more suitable if the gadget driver > needs to be configured specially for the UDC when it binds. sounds good. Too bad GSoC is gone, this would've been a great way to get someone working on the gadget framework :-) Maybe next year... > > dunno, anyway back to Tracepoints... > > Are tracepoints really a good way to dump all the data structures > associated with a driver? I thought they were meant more for > monitoring particular events as they occur. Zhang never wanted to dump *all* data structures just some of their addresses. I'm augmenting that with tracing events (reset, resume, link state change, transfer not ready, etc) as they occur. Trace then allows us to enable each one of these events on demand, which is pretty neat. I'll also add a trace event for register accesses which can *really* help with odd cases (e.g. hibernation) which are very hard to implement and debug. It can also serve as a good way of comunicating with RTL Engineers as they wouldn't really understand anything higher level than a sequence of register accesses. cheers -- balbi signature.asc Description: Digital signature
Re: Fwd: RE: [RFC PATCH 1/1] usb: udc-core: redo usb_gadget_probe_driver when the udc is ready
On Wed, 30 Apr 2014, Felipe Balbi wrote: > > > 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 ? > > > > This is the sort of thing that could be fixed by creating a "gadget" > > bus type. The user would be able to force a gadget to bind to a UDC > > by writing to the appropriate sysfs file. > > > > Of course, I suppose you could always implement the same sort of > > functionality with a special-purpose sysfs file, without going to all > > the effort of adding a new bus type. > > Maybe the bus type is what we need to do, something along the lines of > i2c_bus_type, perhaps ? Maybe -- I don't know how the i2c bus type works. But the general idea is simple enough: Each UDC automatically gets a child device (representing controller's external interface to the USB bus, as opposed to its internal interface to an ordinary bus such as PCI or platform), and each each gadget driver gets registered as a driver on the gadget bus. Thus, when a UDC driver registers a controller with udc-core, the core could dynamically allocate a struct usb_udc_device, which would be little more than a wrapper around a struct device. The core would register this device on the gadget bus, on behalf of the UDC driver, as a child of the actual UDC device. Then binding of gadget drivers to UDCs would be handled in the same way as binding of any other driver to a device. For example, if you had a net2280 card in your computer, the net2280 driver would bind to the card's PCI device, and udc-core would create a corresponding usb_gadget device, with a name like "udc-1" -- the full path would be something like /sys/devices/pci:00/:00:1e.0/:01:00.0/udc-1 where :01:00.0 is the PCI device corresponding to the net2280 card. When a gadget driver registers itself with udc-core, the core would add the usb_gadget_driver structure to the gadget bus. Then the ordinary device core mechanism would try to probe each unbound usb_udc_device with the new gadget driver. This automatic binding might not be what you want, especially if you have multiple device controllers in the system or multiple gadget drivers built into the kernel, but the user could always change the bindings by writing to sysfs files. > The difficulty will be with matching a gadget driver to a particular > UDC. How would we be able to load g_zero to dwc3 and g_mass_storage to > dummy ? The automatic binding could easily get annoying, but we could disable it (perhaps by adding a special flag to the bus_type structure). At any rate, let's say the dwc3 UDC is registered as /sys/bus/gadget/devices/udc-1 and the dummy UDC is registered as /sys/bus/gadget/devices/udc-2. Then you could set up the bindings you want by doing: echo udc-1 >/sys/bus/gadget/drivers/g_zero/bind echo udc-2 >/sys/bus/gadget/drivers/g_mass_storage/bind > Or maybe we load gadgets to the bus and always bind through configfs ?!? Maybe. That certainly would be more suitable if the gadget driver needs to be configured specially for the UDC when it binds. > dunno, anyway back to Tracepoints... Are tracepoints really a good way to dump all the data structures associated with a driver? I thought they were meant more for monitoring particular events as they occur. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: RE: [RFC PATCH 1/1] usb: udc-core: redo usb_gadget_probe_driver when the udc is ready
On Wed, Apr 30, 2014 at 01:43:35PM -0400, Alan Stern wrote: > On Wed, 30 Apr 2014, Felipe Balbi wrote: > > > > 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 ? > > This is the sort of thing that could be fixed by creating a "gadget" > bus type. The user would be able to force a gadget to bind to a UDC > by writing to the appropriate sysfs file. > > Of course, I suppose you could always implement the same sort of > functionality with a special-purpose sysfs file, without going to all > the effort of adding a new bus type. Maybe the bus type is what we need to do, something along the lines of i2c_bus_type, perhaps ? The difficulty will be with matching a gadget driver to a particular UDC. How would we be able to load g_zero to dwc3 and g_mass_storage to dummy ? Or maybe we load gadgets to the bus and always bind through configfs ?!? dunno, anyway back to Tracepoints... cheers -- balbi signature.asc Description: Digital signature
Re: Fwd: RE: [RFC PATCH 1/1] usb: udc-core: redo usb_gadget_probe_driver when the udc is ready
On Wed, 30 Apr 2014, Felipe Balbi wrote: > > 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 ? This is the sort of thing that could be fixed by creating a "gadget" bus type. The user would be able to force a gadget to bind to a UDC by writing to the appropriate sysfs file. Of course, I suppose you could always implement the same sort of functionality with a special-purpose sysfs file, without going to all the effort of adding a new bus type. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: RE: [RFC PATCH 1/1] usb: udc-core: redo usb_gadget_probe_driver when the udc is ready
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 signature.asc Description: Digital signature
Fwd: RE: [RFC PATCH 1/1] usb: udc-core: redo usb_gadget_probe_driver when the udc is ready
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. Best regards Robert Baldyga Samsung R&D Institute Poland -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH 1/1] usb: udc-core: redo usb_gadget_probe_driver when the udc is ready
> > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] usb: udc-core: redo usb_gadget_probe_driver when the udc is ready
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. Robert -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH 1/1] usb: udc-core: redo usb_gadget_probe_driver when the udc is ready
> > 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. Peter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/1] usb: udc-core: redo usb_gadget_probe_driver when the udc is ready
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 Best regards, Robert Baldyga -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
