Patchwork [00/15] Big pxa2[57]x_udc cleanup

login
register
mail settings
Submitter Dmitry Eremin-Solenikov
Date July 5, 2011, 1:08 p.m.
Message ID <1309871321-11305-1-git-send-email-dbaryshkov@gmail.com>
Download mbox
Permalink /patch/103276/
State New
Headers show

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/lumag/tosa-2.6.git misc/pxa-udc-cleanup

Comments

Dmitry Eremin-Solenikov - July 5, 2011, 1:08 p.m.
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
Eric Miao - July 5, 2011, 1:45 p.m.
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

>
Felipe Balbi - July 5, 2011, 1:46 p.m.
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>
Felipe Balbi - July 5, 2011, 1:47 p.m.
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>
Felipe Balbi - July 5, 2011, 1:49 p.m.
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>
Sergei Shtylyov - July 5, 2011, 2:47 p.m.
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
Robert Jarzmik - July 5, 2011, 8:42 p.m.
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
Dmitry Eremin-Solenikov - July 5, 2011, 8:58 p.m.
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
>
Felipe Balbi - July 6, 2011, 7:20 a.m.
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.
Dmitry Eremin-Solenikov - July 6, 2011, 7:30 a.m.
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!
Felipe Balbi - July 6, 2011, 7:34 a.m.
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 ;-)
Greg KH - July 8, 2011, 9:34 p.m.
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
Felipe Balbi - July 8, 2011, 9:54 p.m.
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 ?
gregkh@suse.de - July 8, 2011, 10:02 p.m.
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
Felipe Balbi - July 8, 2011, 10:14 p.m.
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.
Dmitry Eremin-Solenikov - July 9, 2011, 8:50 a.m.
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?
Dmitry Eremin-Solenikov - July 12, 2011, 1:41 p.m.
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!
Eric Miao - July 14, 2011, 2:52 a.m.
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.
Robert Jarzmik - July 14, 2011, 6:24 p.m.
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
Robert Jarzmik - July 14, 2011, 7:01 p.m.
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
Eric Miao - July 15, 2011, 10:40 a.m.
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
>
Felipe Balbi - July 18, 2011, 8:38 a.m.
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>