On Sat, 2013-03-16 at 20:31 +0100, Henrik Rydberg wrote:
> What do you mean by "fix for this on suspend/resume"? The driver
> always returns to normal mode at suspend, and sets wellspring mode at
> resume.
Yes, that's exactly what I mean. And in the early days when the driver
didn't have a resume method, users were seeing exactly this 'bad
trackpad package, length: 8' message on resume. Adding the
suspend/resume methods fixed that — and that's why I'm assuming that a
switch back into wellspring mode is going to be sufficient to fix what
I'm seeing too. Unloading and reloading the module certainly is.
> > +static void bcm5974_mode_workfn(struct work_struct *work)
> > +{
> > + struct bcm5974 *dev = container_of(work, struct bcm5974, reset_work);
> > +
> > + dev_info(&dev->intf->dev, "Reset into wellspring mode...\n");
> > + bcm5974_wellspring_mode(dev, true);
> > +}
> > +
>
> This looks racy.
Racy with what? Oh, I see... we should probably move the
cancel_work_sync() from bcm5974_disconnect() to bcm5974_pause_traffic()?
> In general, It does not really make sense for the transaction mode to
> change under our feet without anything in the usb layer knowing about
> it.
If hardware always made sense, the world would be a much better place :)
> Maybe there is a reset state cycle which does not get handle
> properly in the driver?
I don't believe so. A USB reset would end up with the bcm5974_probe()
method being called again, and everything would work fine. The device
may have reset its mode, but the USB bus doesn't seem to notice
anything. When it happens, there are no USB messages; it just starts
spewing the 'bad trackpad package' messages.
--
dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
