A recent change in the usb core "USB: change interface to usb_lock_device_for_reset()"
conflicts with "p54usb: utilize usb_reset_device for 3887".
Sadly, we have to call usb_reset_device before we can upload the firmware on 3887.
Unless someone figures out how to reliably stop the 3887 so the hardware is still usable
next time we want to start it.
Signed-off-by: Christian Lamparter <[email protected]>
---
John,
I guess this patch should be in the next wireless-2.6 pull.
And it would be nice, if you can put "[PATCH] p54: fix p54_set_key's return code" in there too.
---
diff --git a/drivers/net/wireless/p54/p54usb.c b/drivers/net/wireless/p54/p54usb.c
index 4d54826..3bfee58 100644
--- a/drivers/net/wireless/p54/p54usb.c
+++ b/drivers/net/wireless/p54/p54usb.c
@@ -435,14 +435,16 @@ static const char p54u_firmware_upload_3887[] = "<\r";
static int p54u_device_reset_3887(struct ieee80211_hw *dev)
{
struct p54u_priv *priv = dev->priv;
- int ret, lock;
+ int ret, lock = (priv->intf->condition != USB_INTERFACE_BINDING);
u8 buf[4];
- ret = lock = usb_lock_device_for_reset(priv->udev, priv->intf);
- if (ret < 0) {
- dev_err(&priv->udev->dev, "(p54usb) unable to lock device for "
- "reset: %d\n", ret);
- return ret;
+ if (lock) {
+ ret = usb_lock_device_for_reset(priv->udev, priv->intf);
+ if (ret < 0) {
+ dev_err(&priv->udev->dev, "(p54usb) unable to lock "
+ " device for reset: %d\n", ret);
+ return ret;
+ }
}
ret = usb_reset_device(priv->udev);
On Fri, Jan 16, 2009 at 08:24:31PM +0100, Christian Lamparter wrote:
> A recent change in the usb core "USB: change interface to usb_lock_device_for_reset()"
> conflicts with "p54usb: utilize usb_reset_device for 3887".
>
> Sadly, we have to call usb_reset_device before we can upload the firmware on 3887.
> Unless someone figures out how to reliably stop the 3887 so the hardware is still usable
> next time we want to start it.
>
> Signed-off-by: Christian Lamparter <[email protected]>
> ---
> John,
>
> I guess this patch should be in the next wireless-2.6 pull.
> And it would be nice, if you can put "[PATCH] p54: fix p54_set_key's return code" in there too.
The other patch seems fine, but this one doesn't apply to wireless-2.6
-- p54u_device_reset_3887 doesn't seem to exist there?
I'll apply this in wireless-testing and eventually to wireless-next-2.6,
unless you send me an alternative patch based on wireless-2.6?
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Friday 16 January 2009 22:13:52 John W. Linville wrote:
> On Fri, Jan 16, 2009 at 08:24:31PM +0100, Christian Lamparter wrote:
> > A recent change in the usb core "USB: change interface to usb_lock_device_for_reset()"
> > conflicts with "p54usb: utilize usb_reset_device for 3887".
> >
> > Sadly, we have to call usb_reset_device before we can upload the firmware on 3887.
> > Unless someone figures out how to reliably stop the 3887 so the hardware is still usable
> > next time we want to start it.
> >
> > Signed-off-by: Christian Lamparter <[email protected]>
> > ---
> > John,
> >
> > I guess this patch should be in the next wireless-2.6 pull.
> > And it would be nice, if you can put "[PATCH] p54: fix p54_set_key's return code" in there too.
>
> The other patch seems fine, but this one doesn't apply to wireless-2.6
> -- p54u_device_reset_3887 doesn't seem to exist there?
>
> I'll apply this in wireless-testing and eventually to wireless-next-2.6,
> unless you send me an alternative patch based on wireless-2.6?
Ahh, wait... I guess, I know what's wrong here.
This patch "p54usb: fix conflict with recent usb changes" depends on
"[PATCH 1/3] p54usb: utilize usb_reset_device for 3887", which was posted on 26. Dec 2008 together with:
"[PATCH 2/3] p54: prevent upload of wrong firmwares" (unimportant here) and
"[PATCH 3/3] p54: fix WARN_ON at line 2247 of net/mac80211/rx.c" (now: commit 124b68e755c2ef9342d5d477142c499fd7901360 in linus' tree)
And this is were everything went wrong... Because of "p54: fix WARN_ON at line 2247 ..." merge,
I thought you pushed the whole series upstream and not just the last patch ;-).
Sorry!
Regards,
Chr