On Tue, Mar 5, 2013 at 3:03 PM, Bjørn Mork bj...@mork.no wrote:
Ming Lei ming@canonical.com writes:
Hi,
This patch adds comments on interface driver suspend callback
to emphasize that the failure return value is ignored by
USB core in system sleep context, so do not try to recover
On Tue, Mar 5, 2013 at 3:09 PM, Bjørn Mork bj...@mork.no wrote:
Ming Lei ming@canonical.com writes:
If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this patch doesn't recover device under this situation.
Cc:
On Tue, Mar 5, 2013 at 3:09 PM, Bjørn Mork bj...@mork.no wrote:
Ming Lei ming@canonical.com writes:
If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this patch doesn't recover device under this situation.
Cc:
On Tuesday 05 March 2013 18:55:42 Ming Lei wrote:
All these drivers suspend in multiple steps, where each step can
fail. If a later step fails then they revert any previously successful
step before returning the failure, thereby ensuring that the
device/driver state when suspend returns is
On Tue, Mar 5, 2013 at 8:50 PM, Oliver Neukum oneu...@suse.de wrote:
IMO, for autosuspend, that is right, but it is not for system suspend,
and the driver's suspend callback can't return in resumed state
because the USB core will ignore the failure return value and force
to suspend the
On Tue, Mar 5, 2013 at 12:01 PM, Ming Lei ming@canonical.com wrote:
This patch adds comments on interface driver suspend callback
to emphasize that the failure return value is ignored by
USB core in system sleep context, so do not try to recover
device for this case.
Signed-off-by: Ming
Ming Lei ming@canonical.com writes:
On Tue, Mar 5, 2013 at 3:03 PM, Bjørn Mork bj...@mork.no wrote:
Ming Lei ming@canonical.com writes:
Hi,
This patch adds comments on interface driver suspend callback
to emphasize that the failure return value is ignored by
USB core in system
On Tuesday 05 March 2013 21:08:09 Ming Lei wrote:
On Tue, Mar 5, 2013 at 8:50 PM, Oliver Neukum oneu...@suse.de wrote:
In other words, if we don't handle errors, there must be no errors,
otherwise it doesn't matter what we do in the error case. We'd leave
the problem to generic layers.
Ming Lei ming@canonical.com writes:
On Tue, Mar 5, 2013 at 3:09 PM, Bjørn Mork bj...@mork.no wrote:
Ming Lei ming@canonical.com writes:
If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this patch doesn't
On Tue, Mar 5, 2013 at 9:28 PM, Oliver Neukum oneu...@suse.de wrote:
On Tuesday 05 March 2013 21:08:09 Ming Lei wrote:
On Tue, Mar 5, 2013 at 8:50 PM, Oliver Neukum oneu...@suse.de wrote:
In other words, if we don't handle errors, there must be no errors,
otherwise it doesn't matter what we
Hi Dan,
On Tue, Mar 5, 2013 at 2:06 PM, Dan Carpenter dan.carpen...@oracle.com wrote:
We can't trust dj_report-device_index because it comes from the
user and hasn't been range checked. It is used as an offset into
the djrcv_dev-paired_dj_devices[] array which has 7 elements.
There is one
Ming Lei ming@canonical.com writes:
On Tue, Mar 5, 2013 at 9:46 PM, Bjørn Mork bj...@mork.no wrote:
Now, after inspecting wdm_suspend() which hides behind
info-subdriver-suspend(), I see that this is a completely theoretical
discussion as it always will return 0 if PMSG_IS_AUTO(msg) is
On Tue, Mar 5, 2013 at 11:03 PM, Bjørn Mork bj...@mork.no wrote:
Ming Lei ming@canonical.com writes:
On Tue, Mar 5, 2013 at 9:46 PM, Bjørn Mork bj...@mork.no wrote:
Now, after inspecting wdm_suspend() which hides behind
info-subdriver-suspend(), I see that this is a completely theoretical
Ming Lei ming@canonical.com writes:
Yes, USB core will flush any outstanding URBs, but the driver still need
to deal with suspend failure carefully, for example, suppose usb_resume()
is called in suspend failure path, and the submitted URBs are killed
by USB core later. But after the
hid_output_raw_report() makes a direct call to usb_control_msg(). However,
some USB3 boards have shown that the usb device is not ready during the
.probe(). This blocks the entire usb device, and the paired mice, keyboards
are not functional. The dmesg output is the following:
[ 11.912287]
On Tue, 5 Mar 2013, Bjørn Mork wrote:
Ming Lei ming@canonical.com writes:
Yes, USB core will flush any outstanding URBs, but the driver still need
to deal with suspend failure carefully, for example, suppose usb_resume()
is called in suspend failure path, and the submitted URBs are
Alan Stern st...@rowland.harvard.edu writes:
On Tue, 5 Mar 2013, Bjørn Mork wrote:
Ming Lei ming@canonical.com writes:
Yes, USB core will flush any outstanding URBs, but the driver still need
to deal with suspend failure carefully, for example, suppose usb_resume()
is called in
On Tue, Mar 05, 2013 at 05:34:08PM +0100, Nestor Lopez Casado wrote:
If you want to add a check, it need to be in logi_dj_recv_forward_report().
The current access to djrcv_dev-paired_dj_devices[] in
delayedwork_callback() has been removed in latest HID tree:
From: Stephan Frank sfr...@cs.tu-berlin.de
It is a Wacom device found in Fujitsu Lifebook T902.
Signed-off-by: Stephan Frank sfr...@cs.tu-berlin.de
Acked-by: Ping Cheng pi...@wacom.com
---
note: patch is based on next branch
---
drivers/input/tablet/wacom_wac.c |4
1 file changed, 4
On Wed, Mar 6, 2013 at 12:08 AM, Bjørn Mork bj...@mork.no wrote:
Ming Lei ming@canonical.com writes:
I am starting to wonder why the USB core has combined system suspend and
runtime suspend if we are going to end up with every driver testing
PMSG_IS_AUTO(message) and selecting a
On Wed, Mar 6, 2013 at 10:51 AM, Ming Lei ming@canonical.com wrote:
On Wed, Mar 6, 2013 at 12:08 AM, Bjørn Mork bj...@mork.no wrote:
Ming Lei ming@canonical.com writes:
I am starting to wonder why the USB core has combined system suspend and
runtime suspend if we are going to end up
Ming Lei ming@canonical.com writes:
On Wed, Mar 6, 2013 at 10:51 AM, Ming Lei ming@canonical.com wrote:
On Wed, Mar 6, 2013 at 12:08 AM, Bjørn Mork bj...@mork.no wrote:
I guess proper error handling here require the USB core to see the
interface driver as dead if it fails to suspend
Add support for an atmel_mxt_tp variant in the atmel_mxt_ts.c driver.
Then, add platform data for the 224s trackpad and the 1664s touchscreen
in chromeos_laptop so that the existing version of the driver will
probe these devices correctly.
v2 : Minor bugfix in patch 1. Cleanup client_id from
From: Daniel Kurtz djku...@chromium.org
This same driver can be used by atmel based touchscreens and touchpads
(buttonpads) by instantiating the i2c device as a atmel_mxt_tp.
This will cause the driver to perform some touchpad specific
initializations, such as:
* register input device name
On Wed, Mar 6, 2013 at 3:06 PM, Bjørn Mork bj...@mork.no wrote:
Ming Lei ming@canonical.com writes:
On Wed, Mar 6, 2013 at 10:51 AM, Ming Lei ming@canonical.com wrote:
On Wed, Mar 6, 2013 at 12:08 AM, Bjørn Mork bj...@mork.no wrote:
I guess proper error handling here require the USB
25 matches
Mail list logo
