| Message ID | 1309871321-11305-1-git-send-email-dbaryshkov@gmail.com |
|---|---|
| State | New |
| Headers | show |
On Tue, Jul 5, 2011 at 9:08 PM, Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> wrote: > Hello colleagues, > > Please review the following patch serie. It's major task is removal of code > and functionality duplication between pxa2[57]x_udc drivers and OTG > transceivers subsystem. > > The following changes since commit fe0d42203cb5616eeff68b14576a0f7e2dd56625: > > Linux 3.0-rc6 (2011-07-04 15:56:24 -0700) > > are available in the git repository at: > git://git.kernel.org/pub/scm/linux/kernel/git/lumag/tosa-2.6.git misc/pxa-udc-cleanup > > Dmitry Eremin-Solenikov (15): > ARM: pxa/balloon3: drop udc_is_connected > ARM: pxa/mioa701: drop udc_is_connected > ARM: pxa/stargate2: drop udc_is_connected > ARM: pxa25x_udc: separate lubbock handling to lubbock-usb transceiver > ARM: pxa/lubbock: switch to using lubbock_usb_xceiv transceiver > pxa: drop handling of udc_is_connected > pxa25x_udc: drop support for udc_command > otg: add gpio_pullup OTG transceiver for devices with no VBUS sensing > corgi: convert to use gpio-pullup > poodle: convert to use gpio-pullup > h5000: convert to use gpio-pullup > gpio-vbus: support disabling D+ pullup on suspend > mioa701: move gpio-pullup functionality to gpio-vbus > gpio-pullup: support disabling D+ pullup on suspend > pxa2[57]x_udc: drop gpio_pullup handling > > arch/arm/include/asm/mach/udc_pxa2xx.h | 9 -- > arch/arm/mach-pxa/balloon3.c | 7 - > arch/arm/mach-pxa/colibri-pxa320.c | 1 - > arch/arm/mach-pxa/corgi.c | 14 ++- > arch/arm/mach-pxa/devices.c | 2 +- > arch/arm/mach-pxa/h5000.c | 14 ++- > arch/arm/mach-pxa/lubbock.c | 17 +-- > arch/arm/mach-pxa/mioa701.c | 19 +-- > arch/arm/mach-pxa/poodle.c | 13 ++- > arch/arm/mach-pxa/stargate2.c | 6 - > arch/arm/mach-pxa/vpac270.c | 1 - > drivers/usb/gadget/pxa25x_udc.c | 132 --------------------- > drivers/usb/gadget/pxa27x_udc.c | 27 +---- > drivers/usb/otg/Kconfig | 18 +++ > drivers/usb/otg/Makefile | 2 + > drivers/usb/otg/gpio_pullup.c | 204 ++++++++++++++++++++++++++++++++ > drivers/usb/otg/gpio_vbus.c | 42 +++++++ > drivers/usb/otg/lubbock-usb.c | 178 ++++++++++++++++++++++++++++ > include/linux/usb/gpio_vbus.h | 1 + > 19 files changed, 493 insertions(+), 214 deletions(-) > create mode 100644 drivers/usb/otg/gpio_pullup.c > create mode 100644 drivers/usb/otg/lubbock-usb.c > Hi Dmitry, The series looks good to me. It can be better re-ordered so that changes to drivers/usb are the first part, and changes to arch/arm later? Dropping the udc_is_connected() in each board file, I don't mind they are in a same patch or separated. Greg & Felipe, Can you help merge the patches through the USB tree? Or if you can give your Acks here. Thanks. - eric >
Hi, On Tue, Jul 05, 2011 at 05:08:33PM +0400, Dmitry Eremin-Solenikov wrote: > None of pxa25x devices use udc_command() for UDC functionality. > Stop calling this callback from pxa25x_udc code. looks good to me, Greg since this is a big re-work which depends on parts out of the Gadget Framework, can you take all the patches straight ? Here's my Acked-by: Acked-by: Felipe Balbi <balbi@ti.com>
Hi, On Tue, Jul 05, 2011 at 05:08:30PM +0400, Dmitry Eremin-Solenikov wrote: > Move all handling of lubbock board to separate lubbock-usb transceiver, > removing cruft from pxa25x_udc. > > Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> > Signed-off-by: Eric Miao <eric.y.miao@gmail.com> > Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Acked-by: Felipe Balbi <balbi@ti.com>
On Tue, Jul 05, 2011 at 05:08:41PM +0400, Dmitry Eremin-Solenikov wrote: > Now as all drivers were converted to using gpio-vbus, drop gpio-pullup > handling from pxa UDC drivers, thus simplifying them a bit. > > Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> for drivers/usb/gadget: Acked-by: Felipe Balbi <balbi@ti.com>
Hello. Dmitry Eremin-Solenikov wrote: > Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> > Signed-off-by: Eric Miao <eric.y.miao@gmail.com> > Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> One signoff was enough. :-) WBR, Sergei
On 07/05/2011 03:08 PM, Dmitry Eremin-Solenikov wrote: > Now as all drivers were converted to using gpio-vbus, drop gpio-pullup > handling from pxa UDC drivers, thus simplifying them a bit. Is this patch compliant with USB 2 specification regarding maximum time between pullup triggering and UDC ready to answer the "RESET" packet and be assigned an address ? This is the sequence I'm worried about : (1) The gpio-vbus is loaded (2) The pxa27x_udc is loaded (3) USB cable is plugged => VBUS is sensed (4) gpio-vbus pulls up the D+ (Dmitry, is that right ?) (5) the host waits for UDC to settle (100 ms ?) (5) set address packet(s) are sent from host to UDC (6) UDC is not enabled, as no gadget is registered => UDC doesn't answer => usb host cannot assign it an address (7) a gadget is loaded (g_ether for example) => UDC is enabled, but too late Alan, Gregh, could you confirm point (5) about a maximum time between D+ line activation and UDC duty to repond to "set address" packets, as well as the consequence of point (6) where the usb device is rejected because no address could be assigned ? Dmitry, could you confirm the the D+ pullup is done at point (4) ? Cheers. -- Robert
On 7/6/11, Robert Jarzmik <robert.jarzmik@free.fr> wrote: > On 07/05/2011 03:08 PM, Dmitry Eremin-Solenikov wrote: >> Now as all drivers were converted to using gpio-vbus, drop gpio-pullup >> handling from pxa UDC drivers, thus simplifying them a bit. > > Is this patch compliant with USB 2 specification regarding maximum time > between pullup triggering and UDC ready to answer the "RESET" packet and > be assigned an address ? > > This is the sequence I'm worried about : > (1) The gpio-vbus is loaded > (2) The pxa27x_udc is loaded > (3) USB cable is plugged > => VBUS is sensed > (4) gpio-vbus pulls up the D+ (Dmitry, is that right ?) > (5) the host waits for UDC to settle (100 ms ?) > (5) set address packet(s) are sent from host to UDC > (6) UDC is not enabled, as no gadget is registered > => UDC doesn't answer > => usb host cannot assign it an address > (7) a gadget is loaded (g_ether for example) > => UDC is enabled, but too late > > Alan, Gregh, could you confirm point (5) about a maximum time between D+ > line activation and UDC duty to repond to "set address" packets, as well > as the consequence of point (6) where the usb device is rejected because > no address could be assigned ? > > Dmitry, could you confirm the the D+ pullup is done at point (4) ? No, I can't confirm this. IIUC, evrything happens in abit different way: (4) trancseiver notifies udc about VBUS sense (5) a gadget is loaded (g_ether for example) (6) gadget asks udc to enale pullup (7) udc tells gpio_vbus to enable pullup. etc... > > Cheers. > > -- > Robert >
hi, On Wed, Jul 06, 2011 at 12:58:48AM +0400, Dmitry Eremin-Solenikov wrote: > On 7/6/11, Robert Jarzmik <robert.jarzmik@free.fr> wrote: > > On 07/05/2011 03:08 PM, Dmitry Eremin-Solenikov wrote: > >> Now as all drivers were converted to using gpio-vbus, drop gpio-pullup > >> handling from pxa UDC drivers, thus simplifying them a bit. > > > > Is this patch compliant with USB 2 specification regarding maximum time > > between pullup triggering and UDC ready to answer the "RESET" packet and > > be assigned an address ? > > > > This is the sequence I'm worried about : > > (1) The gpio-vbus is loaded > > (2) The pxa27x_udc is loaded > > (3) USB cable is plugged > > => VBUS is sensed > > (4) gpio-vbus pulls up the D+ (Dmitry, is that right ?) > > (5) the host waits for UDC to settle (100 ms ?) > > (5) set address packet(s) are sent from host to UDC > > (6) UDC is not enabled, as no gadget is registered > > => UDC doesn't answer > > => usb host cannot assign it an address > > (7) a gadget is loaded (g_ether for example) > > => UDC is enabled, but too late > > > > Alan, Gregh, could you confirm point (5) about a maximum time between D+ > > line activation and UDC duty to repond to "set address" packets, as well > > as the consequence of point (6) where the usb device is rejected because > > no address could be assigned ? > > > > Dmitry, could you confirm the the D+ pullup is done at point (4) ? > > No, I can't confirm this. IIUC, evrything happens in abit different way: > (4) trancseiver notifies udc about VBUS sense > (5) a gadget is loaded (g_ether for example) > (6) gadget asks udc to enale pullup > (7) udc tells gpio_vbus to enable pullup. yeah, with udc-core.c we only enable pullup after gadget driver is loaded. 290 ret = bind(udc->gadget); 291 if (ret) 292 goto err1; 293 ret = usb_gadget_udc_start(udc->gadget, driver); 294 if (ret) { 295 driver->unbind(udc->gadget); 296 goto err1; 297 } 298 usb_gadget_connect(udc->gadget); but this is the new style bind() and many UDCs still need to be converted.
On 06.07.2011 11:20, Felipe Balbi wrote: > hi, > > On Wed, Jul 06, 2011 at 12:58:48AM +0400, Dmitry Eremin-Solenikov wrote: >> On 7/6/11, Robert Jarzmik<robert.jarzmik@free.fr> wrote: >>> On 07/05/2011 03:08 PM, Dmitry Eremin-Solenikov wrote: >>>> Now as all drivers were converted to using gpio-vbus, drop gpio-pullup >>>> handling from pxa UDC drivers, thus simplifying them a bit. >>> >>> Is this patch compliant with USB 2 specification regarding maximum time >>> between pullup triggering and UDC ready to answer the "RESET" packet and >>> be assigned an address ? >>> >>> This is the sequence I'm worried about : >>> (1) The gpio-vbus is loaded >>> (2) The pxa27x_udc is loaded >>> (3) USB cable is plugged >>> => VBUS is sensed >>> (4) gpio-vbus pulls up the D+ (Dmitry, is that right ?) >>> (5) the host waits for UDC to settle (100 ms ?) >>> (5) set address packet(s) are sent from host to UDC >>> (6) UDC is not enabled, as no gadget is registered >>> => UDC doesn't answer >>> => usb host cannot assign it an address >>> (7) a gadget is loaded (g_ether for example) >>> => UDC is enabled, but too late >>> >>> Alan, Gregh, could you confirm point (5) about a maximum time between D+ >>> line activation and UDC duty to repond to "set address" packets, as well >>> as the consequence of point (6) where the usb device is rejected because >>> no address could be assigned ? >>> >>> Dmitry, could you confirm the the D+ pullup is done at point (4) ? >> >> No, I can't confirm this. IIUC, evrything happens in abit different way: >> (4) trancseiver notifies udc about VBUS sense >> (5) a gadget is loaded (g_ether for example) >> (6) gadget asks udc to enale pullup >> (7) udc tells gpio_vbus to enable pullup. > > yeah, with udc-core.c we only enable pullup after gadget driver is > loaded. > > 290 ret = bind(udc->gadget); > 291 if (ret) > 292 goto err1; > 293 ret = usb_gadget_udc_start(udc->gadget, driver); > 294 if (ret) { > 295 driver->unbind(udc->gadget); > 296 goto err1; > 297 } > 298 usb_gadget_connect(udc->gadget); > > but this is the new style bind() and many UDCs still need to be > converted. This was working before the udc-core. If it doesn't work now for unconverted drivers (PXA e.g.) that's really a huge regression!
Hi, On Wed, Jul 06, 2011 at 11:30:52AM +0400, Dmitry Eremin-Solenikov wrote: > On 06.07.2011 11:20, Felipe Balbi wrote: > >hi, > > > >On Wed, Jul 06, 2011 at 12:58:48AM +0400, Dmitry Eremin-Solenikov wrote: > >>On 7/6/11, Robert Jarzmik<robert.jarzmik@free.fr> wrote: > >>>On 07/05/2011 03:08 PM, Dmitry Eremin-Solenikov wrote: > >>>>Now as all drivers were converted to using gpio-vbus, drop gpio-pullup > >>>>handling from pxa UDC drivers, thus simplifying them a bit. > >>> > >>>Is this patch compliant with USB 2 specification regarding maximum time > >>>between pullup triggering and UDC ready to answer the "RESET" packet and > >>>be assigned an address ? > >>> > >>>This is the sequence I'm worried about : > >>> (1) The gpio-vbus is loaded > >>> (2) The pxa27x_udc is loaded > >>> (3) USB cable is plugged > >>> => VBUS is sensed > >>> (4) gpio-vbus pulls up the D+ (Dmitry, is that right ?) > >>> (5) the host waits for UDC to settle (100 ms ?) > >>> (5) set address packet(s) are sent from host to UDC > >>> (6) UDC is not enabled, as no gadget is registered > >>> => UDC doesn't answer > >>> => usb host cannot assign it an address > >>> (7) a gadget is loaded (g_ether for example) > >>> => UDC is enabled, but too late > >>> > >>>Alan, Gregh, could you confirm point (5) about a maximum time between D+ > >>>line activation and UDC duty to repond to "set address" packets, as well > >>>as the consequence of point (6) where the usb device is rejected because > >>>no address could be assigned ? > >>> > >>>Dmitry, could you confirm the the D+ pullup is done at point (4) ? > >> > >>No, I can't confirm this. IIUC, evrything happens in abit different way: > >>(4) trancseiver notifies udc about VBUS sense > >>(5) a gadget is loaded (g_ether for example) > >>(6) gadget asks udc to enale pullup > >>(7) udc tells gpio_vbus to enable pullup. > > > >yeah, with udc-core.c we only enable pullup after gadget driver is > >loaded. > > > >290 ret = bind(udc->gadget); > >291 if (ret) > >292 goto err1; > >293 ret = usb_gadget_udc_start(udc->gadget, driver); > >294 if (ret) { > >295 driver->unbind(udc->gadget); > >296 goto err1; > >297 } > >298 usb_gadget_connect(udc->gadget); > > > >but this is the new style bind() and many UDCs still need to be > >converted. > > This was working before the udc-core. If it doesn't work now for > unconverted drivers (PXA e.g.) that's really a huge regression! the difference is that before every UDC had to implement that by itself and now we're moving the common parts to a generic layer. If your UDC already implemented it this way when exporting usb_gadget_probe_driver(), then no changes for you, but I guarantee there where UDCs which didn't mind being careful with data pullups and would connect even though a gadget driver was nowhere to be seen ;-)
On Tue, Jul 05, 2011 at 04:46:16PM +0300, Felipe Balbi wrote: > Hi, > > On Tue, Jul 05, 2011 at 05:08:33PM +0400, Dmitry Eremin-Solenikov wrote: > > None of pxa25x devices use udc_command() for UDC functionality. > > Stop calling this callback from pxa25x_udc code. > > looks good to me, Greg since this is a big re-work which depends on > parts out of the Gadget Framework, can you take all the patches > straight ? Here's my Acked-by: > > Acked-by: Felipe Balbi <balbi@ti.com> I can't take these, they should go through the gpio subsystem maintainer instead. thanks, greg k-h
On Fri, Jul 08, 2011 at 02:34:28PM -0700, Greg KH wrote: > On Tue, Jul 05, 2011 at 04:46:16PM +0300, Felipe Balbi wrote: > > Hi, > > > > On Tue, Jul 05, 2011 at 05:08:33PM +0400, Dmitry Eremin-Solenikov wrote: > > > None of pxa25x devices use udc_command() for UDC functionality. > > > Stop calling this callback from pxa25x_udc code. > > > > looks good to me, Greg since this is a big re-work which depends on > > parts out of the Gadget Framework, can you take all the patches > > straight ? Here's my Acked-by: > > > > Acked-by: Felipe Balbi <balbi@ti.com> > > I can't take these, they should go through the gpio subsystem maintainer > instead. But why ? They only touch drivers/usb/gadget/pxa*.c Would it be enough if Grant would Ack them ?
On Sat, Jul 09, 2011 at 12:54:43AM +0300, Felipe Balbi wrote: > On Fri, Jul 08, 2011 at 02:34:28PM -0700, Greg KH wrote: > > On Tue, Jul 05, 2011 at 04:46:16PM +0300, Felipe Balbi wrote: > > > Hi, > > > > > > On Tue, Jul 05, 2011 at 05:08:33PM +0400, Dmitry Eremin-Solenikov wrote: > > > > None of pxa25x devices use udc_command() for UDC functionality. > > > > Stop calling this callback from pxa25x_udc code. > > > > > > looks good to me, Greg since this is a big re-work which depends on > > > parts out of the Gadget Framework, can you take all the patches > > > straight ? Here's my Acked-by: > > > > > > Acked-by: Felipe Balbi <balbi@ti.com> > > > > I can't take these, they should go through the gpio subsystem maintainer > > instead. > > But why ? They only touch drivers/usb/gadget/pxa*.c All 15 patches? No they don't they touch all sorts of things. > Would it be enough if Grant would Ack them ? Sure, but it would be easier if Grant took them all, right? thanks, greg k-h
Hi, On Fri, Jul 08, 2011 at 03:02:58PM -0700, Greg KH wrote: > > > I can't take these, they should go through the gpio subsystem maintainer > > > instead. > > > > But why ? They only touch drivers/usb/gadget/pxa*.c > > All 15 patches? No they don't they touch all sorts of things. > > > Would it be enough if Grant would Ack them ? > > Sure, but it would be easier if Grant took them all, right? Makes sense too.
Hi, On 7/9/11, Greg KH <greg@kroah.com> wrote: > On Tue, Jul 05, 2011 at 04:46:16PM +0300, Felipe Balbi wrote: >> Hi, >> >> On Tue, Jul 05, 2011 at 05:08:33PM +0400, Dmitry Eremin-Solenikov wrote: >> > None of pxa25x devices use udc_command() for UDC functionality. >> > Stop calling this callback from pxa25x_udc code. >> >> looks good to me, Greg since this is a big re-work which depends on >> parts out of the Gadget Framework, can you take all the patches >> straight ? Here's my Acked-by: >> >> Acked-by: Felipe Balbi <balbi@ti.com> > > I can't take these, they should go through the gpio subsystem maintainer > instead. Why? I can understand if you'd say that it should go through the ARM/PXA trees, but why GPIO?
On 7/9/11, Greg KH <gregkh@suse.de> wrote: > On Sat, Jul 09, 2011 at 12:54:43AM +0300, Felipe Balbi wrote: >> On Fri, Jul 08, 2011 at 02:34:28PM -0700, Greg KH wrote: >> > On Tue, Jul 05, 2011 at 04:46:16PM +0300, Felipe Balbi wrote: >> > > Hi, >> > > >> > > On Tue, Jul 05, 2011 at 05:08:33PM +0400, Dmitry Eremin-Solenikov >> > > wrote: >> > > > None of pxa25x devices use udc_command() for UDC functionality. >> > > > Stop calling this callback from pxa25x_udc code. >> > > >> > > looks good to me, Greg since this is a big re-work which depends on >> > > parts out of the Gadget Framework, can you take all the patches >> > > straight ? Here's my Acked-by: >> > > >> > > Acked-by: Felipe Balbi <balbi@ti.com> >> > >> > I can't take these, they should go through the gpio subsystem maintainer >> > instead. >> >> But why ? They only touch drivers/usb/gadget/pxa*.c > > All 15 patches? No they don't they touch all sorts of things. > >> Would it be enough if Grant would Ack them ? > > Sure, but it would be easier if Grant took them all, right? Colleagues, can you please tell me the current status/future of this patches? Are they going to 3.1? 3.2? Should they go via ARM/PXA, via usb? usb-gadget? Via gpio(why?)?? Should I send them to somebody for merging? Thank you!
On Tue, Jul 12, 2011 at 9:41 PM, Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> wrote: > On 7/9/11, Greg KH <gregkh@suse.de> wrote: >> On Sat, Jul 09, 2011 at 12:54:43AM +0300, Felipe Balbi wrote: >>> On Fri, Jul 08, 2011 at 02:34:28PM -0700, Greg KH wrote: >>> > On Tue, Jul 05, 2011 at 04:46:16PM +0300, Felipe Balbi wrote: >>> > > Hi, >>> > > >>> > > On Tue, Jul 05, 2011 at 05:08:33PM +0400, Dmitry Eremin-Solenikov >>> > > wrote: >>> > > > None of pxa25x devices use udc_command() for UDC functionality. >>> > > > Stop calling this callback from pxa25x_udc code. >>> > > >>> > > looks good to me, Greg since this is a big re-work which depends on >>> > > parts out of the Gadget Framework, can you take all the patches >>> > > straight ? Here's my Acked-by: >>> > > >>> > > Acked-by: Felipe Balbi <balbi@ti.com> >>> > >>> > I can't take these, they should go through the gpio subsystem maintainer >>> > instead. >>> >>> But why ? They only touch drivers/usb/gadget/pxa*.c >> >> All 15 patches? No they don't they touch all sorts of things. >> >>> Would it be enough if Grant would Ack them ? >> >> Sure, but it would be easier if Grant took them all, right? > > Colleagues, can you please tell me the current status/future of this patches? > Are they going to 3.1? 3.2? Should they go via ARM/PXA, via usb? usb-gadget? > Via gpio(why?)?? Should I send them to somebody for merging? Well, I agree with Dmitry the whole patchset is not related to the GPIO subsystem at all. The major cleanup is actually to the PXA machines, and touches part of the pxa25x_udc driver. If some one Acks the USB part, I can help take the remaining patches.
On 07/14/2011 04:52 AM, Eric Miao wrote: > Well, I agree with Dmitry the whole patchset is not related to the GPIO > subsystem at all. The major cleanup is actually to the PXA machines, > and touches part of the pxa25x_udc driver. If some one Acks the USB > part, I can help take the remaining patches. Ok, I tested the patches for the pxa27x_udc and mioa701 parts. Therefore, as it is working, for patches 2, 13, and 15 (reduced to pxa27x_udc), I give my : Acked-by: Robert Jarzmik <robert.jarzmik@free> That leaves you with the pxa25x_udc, I'm afraid, but I don't maintain that one. Is there an identified maintainer now, or at least someone able to test it ? Cheers. -- Robert
On 07/14/2011 08:24 PM, Robert Jarzmik wrote: > On 07/14/2011 04:52 AM, Eric Miao wrote: >> Well, I agree with Dmitry the whole patchset is not related to the GPIO >> subsystem at all. The major cleanup is actually to the PXA machines, >> and touches part of the pxa25x_udc driver. If some one Acks the USB >> part, I can help take the remaining patches. > And I forgot patch 12 : Acked-by: Robert Jarzmik <robert.jarzmik@free> Cheers. -- Robert
Not sure if zaurus people can help test it. Pavel? - eric On Fri, Jul 15, 2011 at 2:24 AM, Robert Jarzmik <robert.jarzmik@free.fr> wrote: > On 07/14/2011 04:52 AM, Eric Miao wrote: >> >> Well, I agree with Dmitry the whole patchset is not related to the GPIO >> subsystem at all. The major cleanup is actually to the PXA machines, >> and touches part of the pxa25x_udc driver. If some one Acks the USB >> part, I can help take the remaining patches. > > Ok, I tested the patches for the pxa27x_udc and mioa701 parts. > Therefore, as it is working, for patches 2, 13, and 15 (reduced to > pxa27x_udc), I give my : > Acked-by: Robert Jarzmik <robert.jarzmik@free> > > That leaves you with the pxa25x_udc, I'm afraid, but I don't maintain that > one. Is there an identified maintainer now, or at least someone able to test > it ? > > Cheers. > > -- > Robert >
Hi, On Thu, Jul 14, 2011 at 10:52:47AM +0800, Eric Miao wrote: > On Tue, Jul 12, 2011 at 9:41 PM, Dmitry Eremin-Solenikov > <dbaryshkov@gmail.com> wrote: > > On 7/9/11, Greg KH <gregkh@suse.de> wrote: > >> On Sat, Jul 09, 2011 at 12:54:43AM +0300, Felipe Balbi wrote: > >>> On Fri, Jul 08, 2011 at 02:34:28PM -0700, Greg KH wrote: > >>> > On Tue, Jul 05, 2011 at 04:46:16PM +0300, Felipe Balbi wrote: > >>> > > Hi, > >>> > > > >>> > > On Tue, Jul 05, 2011 at 05:08:33PM +0400, Dmitry Eremin-Solenikov > >>> > > wrote: > >>> > > > None of pxa25x devices use udc_command() for UDC functionality. > >>> > > > Stop calling this callback from pxa25x_udc code. > >>> > > > >>> > > looks good to me, Greg since this is a big re-work which depends on > >>> > > parts out of the Gadget Framework, can you take all the patches > >>> > > straight ? Here's my Acked-by: > >>> > > > >>> > > Acked-by: Felipe Balbi <balbi@ti.com> > >>> > > >>> > I can't take these, they should go through the gpio subsystem maintainer > >>> > instead. > >>> > >>> But why ? They only touch drivers/usb/gadget/pxa*.c > >> > >> All 15 patches? No they don't they touch all sorts of things. > >> > >>> Would it be enough if Grant would Ack them ? > >> > >> Sure, but it would be easier if Grant took them all, right? > > > > Colleagues, can you please tell me the current status/future of this patches? > > Are they going to 3.1? 3.2? Should they go via ARM/PXA, via usb? usb-gadget? > > Via gpio(why?)?? Should I send them to somebody for merging? > > Well, I agree with Dmitry the whole patchset is not related to the GPIO > subsystem at all. The major cleanup is actually to the PXA machines, > and touches part of the pxa25x_udc driver. If some one Acks the USB > part, I can help take the remaining patches. For the gadget part you can have my Ack. Although I don't have how to test those patches, they seem simple enough: Acked-by: Felipe Balbi <balbi@ti.com>
Hello colleagues, Please review the following patch serie. It's major task is removal of code and functionality duplication between pxa2[57]x_udc drivers and OTG transceivers subsystem. The following changes since commit fe0d42203cb5616eeff68b14576a0f7e2dd56625: Linux 3.0-rc6 (2011-07-04 15:56:24 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/lumag/tosa-2.6.git misc/pxa-udc-cleanup Dmitry Eremin-Solenikov (15): ARM: pxa/balloon3: drop udc_is_connected ARM: pxa/mioa701: drop udc_is_connected ARM: pxa/stargate2: drop udc_is_connected ARM: pxa25x_udc: separate lubbock handling to lubbock-usb transceiver ARM: pxa/lubbock: switch to using lubbock_usb_xceiv transceiver pxa: drop handling of udc_is_connected pxa25x_udc: drop support for udc_command otg: add gpio_pullup OTG transceiver for devices with no VBUS sensing corgi: convert to use gpio-pullup poodle: convert to use gpio-pullup h5000: convert to use gpio-pullup gpio-vbus: support disabling D+ pullup on suspend mioa701: move gpio-pullup functionality to gpio-vbus gpio-pullup: support disabling D+ pullup on suspend pxa2[57]x_udc: drop gpio_pullup handling arch/arm/include/asm/mach/udc_pxa2xx.h | 9 -- arch/arm/mach-pxa/balloon3.c | 7 - arch/arm/mach-pxa/colibri-pxa320.c | 1 - arch/arm/mach-pxa/corgi.c | 14 ++- arch/arm/mach-pxa/devices.c | 2 +- arch/arm/mach-pxa/h5000.c | 14 ++- arch/arm/mach-pxa/lubbock.c | 17 +-- arch/arm/mach-pxa/mioa701.c | 19 +-- arch/arm/mach-pxa/poodle.c | 13 ++- arch/arm/mach-pxa/stargate2.c | 6 - arch/arm/mach-pxa/vpac270.c | 1 - drivers/usb/gadget/pxa25x_udc.c | 132 --------------------- drivers/usb/gadget/pxa27x_udc.c | 27 +---- drivers/usb/otg/Kconfig | 18 +++ drivers/usb/otg/Makefile | 2 + drivers/usb/otg/gpio_pullup.c | 204 ++++++++++++++++++++++++++++++++ drivers/usb/otg/gpio_vbus.c | 42 +++++++ drivers/usb/otg/lubbock-usb.c | 178 ++++++++++++++++++++++++++++ include/linux/usb/gpio_vbus.h | 1 + 19 files changed, 493 insertions(+), 214 deletions(-) create mode 100644 drivers/usb/otg/gpio_pullup.c create mode 100644 drivers/usb/otg/lubbock-usb.c