Hi David,

On Sat, 2013-03-16 at 20:31 +0100, Henrik Rydberg wrote:

quoted

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.

quoted

quoted

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

quoted

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.

quoted

 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