Re: [RFC/RFT] Reset bcm5974 into wellspring mode when it forgets

["Henrik Rydberg" <rydberg@euromail.se>]

Hi David,

> 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.

The driver always had suspend/resume, but it is true that the EFI
booting did create a problem with the reset_resume method, so we went
back to rebinding the device. In addition to that problem, there has
been reports in the past that seem to indicate a few exemplars of
faulty hardware.

> 
> > > +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()?

I was thinking about the work function entering the wellspring_mode
function without the pm lock, but your observation seems correct, too :-)

> > 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 :)

But it would be good to know why your machine is special. As you say,
the patch is not really tested, so we don't even know if it will fix
the problem.

> >  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.

Ok, if you manage to hit the problem with a second version of this
patch, I will take it.

Thanks,
Henrik
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html