Dropping WUSB/UWB from my patch queue

Dropping WUSB/UWB from my patch queue

[Greg KH]

Hi David,

In looking further at the WUSB/UWB code, it doesn't look like it is
going to make it for the 2.6.27 kernel tree due to the reliance on some
contriversial core USB changes as well as a total lack of documentation
for the sysfs apis.

Because of this, I've dropped all of the patches from my USB queue, so
they will no longer show up in the -next releases anymore.

But I have moved them to the -staging tree, as they are good patches and
some people are finding them useful.  They will show up in those
releases for people to use and develop off of if needed.

So please rebase your local trees off of the -staging tree, and continue
to send me updates from there as needed.

thanks,

greg k-h

Re: Dropping WUSB/UWB from my patch queue

[David Vrabel]

Greg KH wrote:
> Hi David,
> 
> In looking further at the WUSB/UWB code, it doesn't look like it is
> going to make it for the 2.6.27 kernel tree due to the reliance on some
> contriversial core USB changes as well as a total lack of documentation
> for the sysfs apis.

I assume you are referring to the usb_dev_reset_delayed() change here.
This is only required by the wire adapter code and should not prevent
the majority of the UWB and WUSB stack from being merged.

You should postpone:

usb-add-usb_dev_reset_delayed.patch
wusb-add-the-wire-adapter-core.patch
wusb-add-hwa-hc-wireless-host-controller-driver.patch
wusb-wa-abort-rpipe-request-type-fix.patch

I will correct the lack of sysfs API documentation this week.  Please
advise on where the documentation should go and its style and format.
Be aware that some of the API is experimental and subject to change. I
will ensure the documentation is clear on this and that the Kconfig
entries depend on EXPERIMENTAL.

Would this be sufficient to reinstate the majority of the UWB and WUSB
stacks for 2.6.27?

> Because of this, I've dropped all of the patches from my USB queue, so
> they will no longer show up in the -next releases anymore.

In future, it would be appreciated if any issues with UWB patches are
discussed rather than summarily dropping them.

David
-- 
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park,  Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ                 http://www.csr.com/

Re: Dropping WUSB/UWB from my patch queue

[Greg KH]

On Mon, Jul 07, 2008 at 11:03:28AM +0100, David Vrabel wrote:
> Greg KH wrote:
> > Hi David,

Sorry for the delay, was on vacation all last week without email access,
and am on a business trip this week with very limited email access :(

> > In looking further at the WUSB/UWB code, it doesn't look like it is
> > going to make it for the 2.6.27 kernel tree due to the reliance on some
> > contriversial core USB changes as well as a total lack of documentation
> > for the sysfs apis.
> 
> I assume you are referring to the usb_dev_reset_delayed() change here.
> This is only required by the wire adapter code and should not prevent
> the majority of the UWB and WUSB stack from being merged.

Ok, thanks for letting me know, I did not realize this.

> You should postpone:
> 
> usb-add-usb_dev_reset_delayed.patch
> wusb-add-the-wire-adapter-core.patch
> wusb-add-hwa-hc-wireless-host-controller-driver.patch
> wusb-wa-abort-rpipe-request-type-fix.patch

Will the code still work properly for users with these patches removed?
If so, I'll reconsider sending this for 2.6.27.

> I will correct the lack of sysfs API documentation this week.  Please
> advise on where the documentation should go and its style and format.
> Be aware that some of the API is experimental and subject to change. I
> will ensure the documentation is clear on this and that the Kconfig
> entries depend on EXPERIMENTAL.
> 
> Would this be sufficient to reinstate the majority of the UWB and WUSB
> stacks for 2.6.27?

Yes.  I'll take what you sent me, and try to reorder things to make it
so that we can get the majority of the code into .27, I don't want this
to live outside the tree for any longer either, that's why I started
working on getting this mess cleaned up in the first place :)

> > Because of this, I've dropped all of the patches from my USB queue, so
> > they will no longer show up in the -next releases anymore.
> 
> In future, it would be appreciated if any issues with UWB patches are
> discussed rather than summarily dropping them.

Hey, they were not "dropped" in the format that they suddenly
disappeared, they are still around and useful :)

thanks,

greg k-h

Re: Dropping WUSB/UWB from my patch queue

[David Vrabel]

Greg KH wrote:
> On Mon, Jul 07, 2008 at 11:03:28AM +0100, David Vrabel wrote:
>> Greg KH wrote:
>>> Hi David,
> 
>>> In looking further at the WUSB/UWB code, it doesn't look like it is
>>> going to make it for the 2.6.27 kernel tree due to the reliance on some
>>> contriversial core USB changes as well as a total lack of documentation
>>> for the sysfs apis.
>> I assume you are referring to the usb_dev_reset_delayed() change here.
>> This is only required by the wire adapter code and should not prevent
>> the majority of the UWB and WUSB stack from being merged.
> 
> Ok, thanks for letting me know, I did not realize this.
> 
>> You should postpone:
>>
>> usb-add-usb_dev_reset_delayed.patch
>> wusb-add-the-wire-adapter-core.patch
>> wusb-add-hwa-hc-wireless-host-controller-driver.patch
>> wusb-wa-abort-rpipe-request-type-fix.patch

I took another look at where usb_dev_reset_delayed() is used and there
are more places.  You will also need to postpone:

uwb/uwb-add-hwa-rc-radio-controller-driver.patch
uwb/uwb-i1480-driver.patch
uwb/uwb-i1480-wlp-driver.patch
uwb/uwb-disable-command-event-filtering-for-DUB-1210.patch
uwb/uwb-add-intel-i1480-hwa-to-the-uwb-rc-quirk-table.patch

And since there are now no drivers for WLP hardware you may also postpone:

uwb/uwb-add-wimedia-llc-protocol-core.patch
uwb/uwb-wlp-messages.patch
uwb/uwb-wlp-wss.patch
uwb/uwb-wlp-build-system.patch
uwb/wusb-drivers-uwb-wlp-sysfs.c-move-misplaced-debug-statement.patch

> Will the code still work properly for users with these patches removed?
> If so, I'll reconsider sending this for 2.6.27.

Yes, users of WHCI WUSB host controllers are unaffected.

>> I will correct the lack of sysfs API documentation this week.  Please
>> advise on where the documentation should go and its style and format.
>> Be aware that some of the API is experimental and subject to change. I
>> will ensure the documentation is clear on this and that the Kconfig
>> entries depend on EXPERIMENTAL.
>>
>> Would this be sufficient to reinstate the majority of the UWB and WUSB
>> stacks for 2.6.27?
> 
> Yes.  I'll take what you sent me, and try to reorder things to make it
> so that we can get the majority of the code into .27, I don't want this
> to live outside the tree for any longer either, that's why I started
> working on getting this mess cleaned up in the first place :)

Okay. Good.

David
-- 
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park,  Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ                 http://www.csr.com/

RE: Dropping WUSB/UWB from my patch queue

[Perez-Gonzalez, Inaky]

>From: David Vrabel [mailto:david.vrabel@csr.com]
>
>And since there are now no drivers for WLP hardware you may also
postpone:
>
>uwb/uwb-add-wimedia-llc-protocol-core.patch
>uwb/uwb-wlp-messages.patch
>uwb/uwb-wlp-wss.patch
>uwb/uwb-wlp-build-system.patch
>uwb/wusb-drivers-uwb-wlp-sysfs.c-move-misplaced-debug-statement.patch

What happened to the 1480-wlp code?

Re: Dropping WUSB/UWB from my patch queue

[Greg KH]

On Tue, Jul 15, 2008 at 06:48:23PM +0100, David Vrabel wrote:
> Greg KH wrote:
> > On Mon, Jul 07, 2008 at 11:03:28AM +0100, David Vrabel wrote:
> >> Greg KH wrote:
> >>> Hi David,
> > 
> >>> In looking further at the WUSB/UWB code, it doesn't look like it is
> >>> going to make it for the 2.6.27 kernel tree due to the reliance on some
> >>> contriversial core USB changes as well as a total lack of documentation
> >>> for the sysfs apis.
> >> I assume you are referring to the usb_dev_reset_delayed() change here.
> >> This is only required by the wire adapter code and should not prevent
> >> the majority of the UWB and WUSB stack from being merged.
> > 
> > Ok, thanks for letting me know, I did not realize this.
> > 
> >> You should postpone:
> >>
> >> usb-add-usb_dev_reset_delayed.patch
> >> wusb-add-the-wire-adapter-core.patch
> >> wusb-add-hwa-hc-wireless-host-controller-driver.patch
> >> wusb-wa-abort-rpipe-request-type-fix.patch
> 
> I took another look at where usb_dev_reset_delayed() is used and there
> are more places.  You will also need to postpone:
> 
> uwb/uwb-add-hwa-rc-radio-controller-driver.patch
> uwb/uwb-i1480-driver.patch
> uwb/uwb-i1480-wlp-driver.patch
> uwb/uwb-disable-command-event-filtering-for-DUB-1210.patch
> uwb/uwb-add-intel-i1480-hwa-to-the-uwb-rc-quirk-table.patch
> 
> And since there are now no drivers for WLP hardware you may also postpone:
> 
> uwb/uwb-add-wimedia-llc-protocol-core.patch
> uwb/uwb-wlp-messages.patch
> uwb/uwb-wlp-wss.patch
> uwb/uwb-wlp-build-system.patch
> uwb/wusb-drivers-uwb-wlp-sysfs.c-move-misplaced-debug-statement.patch

Ugh, so, what will end up getting merged?  Anything that people can
actually use?  :)

I'll poke at this on Friday and see what falls out.

thanks,

greg k-h

Re: Dropping WUSB/UWB from my patch queue

[David Vrabel]

Greg KH wrote:
> 
> Ugh, so, what will end up getting merged?  Anything that people can
> actually use?  :)

To summarize what is planned to be merged and what is being postponed.

Merged:

* core UWB stack.
* WHCI radio controller driver
* core WUSB support.
* WHCI host controller driver
* CBAF driver

i.e., a functioning WUSB stack for WHCI (PCI-based) cards.

Postponed:

* HWA radio controller driver
* Wire Adapter core (for HWAs and DWAs).
* HWA host controller
* WLP support
* i1480 firmware download driver.
* i1480 WLP driver.

David
-- 
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park,  Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ                 http://www.csr.com/

RE: Dropping WUSB/UWB from my patch queue

[Perez-Gonzalez, Inaky]

>From: David Vrabel [mailto:david.vrabel@csr.com]
>
>Postponed:
>
>* HWA radio controller driver
>* Wire Adapter core (for HWAs and DWAs).
>* HWA host controller
>* WLP support
>* i1480 firmware download driver.
>* i1480 WLP driver.

If I got you a fix for the USB reset stuff, would you be able to merge
these guys?

Re: Dropping WUSB/UWB from my patch queue

[Greg KH]

On Wed, Jul 16, 2008 at 09:20:30AM -0700, Perez-Gonzalez, Inaky wrote:
> >From: David Vrabel [mailto:david.vrabel@csr.com]
> >
> >Postponed:
> >
> >* HWA radio controller driver
> >* Wire Adapter core (for HWAs and DWAs).
> >* HWA host controller
> >* WLP support
> >* i1480 firmware download driver.
> >* i1480 WLP driver.
> 
> If I got you a fix for the USB reset stuff, would you be able to merge
> these guys?

I don't see why not.

thanks,

greg k-h

Re: Dropping WUSB/UWB from my patch queue

[David Vrabel]

Perez-Gonzalez, Inaky wrote:
>> From: David Vrabel [mailto:david.vrabel@csr.com]
>>
>> Postponed:
>>
>> * HWA radio controller driver
>> * Wire Adapter core (for HWAs and DWAs).
>> * HWA host controller
>> * WLP support
>> * i1480 firmware download driver.
>> * i1480 WLP driver.
> 
> If I got you a fix for the USB reset stuff, would you be able to merge
> these guys?

That would be appreciated.  I just don't have the time to tackle tricky
problems with wired USB devices.

You will also want to add some documentation for any WLP sysfs files.

David
-- 
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park,  Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ                 http://www.csr.com/

RE: Dropping WUSB/UWB from my patch queue

[Perez-Gonzalez, Inaky]

>From: David Vrabel [mailto:david.vrabel@csr.com]
>
>Perez-Gonzalez, Inaky wrote:
>>> From: David Vrabel [mailto:david.vrabel@csr.com]
>>>
>>> Postponed:
>>>
>>> * HWA radio controller driver
>>> * Wire Adapter core (for HWAs and DWAs).
>>> * HWA host controller
>>> * WLP support
>>> * i1480 firmware download driver.
>>> * i1480 WLP driver.
>>
>> If I got you a fix for the USB reset stuff, would you be able to
merge
>> these guys?
>
>That would be appreciated.  I just don't have the time to tackle tricky
>problems with wired USB devices.

I'll see what I can do -- the trip to OLS can be useful for having a 
straight set of ours for patching the kernel, away from the distractions
of work.