)
1b9fb31f (usb: core: check for valid id_table when using the RefId feature)
52a6966c (usb: core: bail out if user gives an unknown RefId when using new_id)
Detected by Coverity: CID 1162604.
Signed-off-by: Christian Engelmayer cenge...@gmx.at
---
v2: Added changes suggested by Sergei Shtylyov
)
1b9fb31f (usb: core: check for valid id_table when using the RefId feature)
52a6966c (usb: core: bail out if user gives an unknown RefId when using new_id)
Detected by Coverity: CID 1162604.
Signed-off-by: Christian Engelmayer cenge...@gmx.at
---
v2: Added changes suggested by Sergei Shtylyov
Fix a memory leak in the usb_store_new_id() error paths. When bailing out
due to sanity checks, the function left the already allocated usb_dynid
struct in place.
Detected by Coverity: CID 1162604.
Signed-off-by: Christian Engelmayer cenge...@gmx.at
---
This patch addresses a regression
is triggered and transfered to the host. From user
perspective the BTN_TOUCH release event in this case is stuck until the next
touch down event.
Signed-off-by: Christian Engelmayer christian.engelma...@frequentis.com
---
v2: Added changes suggested by Dmitry Torokhov:
* Prefer a temporary variable
at such a
wMaxPacketSize boundary, the data will not be available to the usbtouch driver
until a further event is triggered and transfered to the host. From user
perspective the BTN_TOUCH release event in this case is stuck until the next
touch down event.
Signed-off-by: Christian Engelmayer christian.engelma
Hello,
We are using the usbtouchscreen driver for a 0eef:0001 eGalax based device and
have observed cases were BTN_TOUCH seems to be stuck as release events are not
reported promptly. In those situations the release event is reported after
arbitrary time when the next touch event is triggered.
a port if the
overcurrent is currently active.
Added quirks flag need_oc_pp_cycle in order to specify the needed behaviour as
there is no common behaviour that can comply with both requirements.
Activated the quirks handling for Freescale 83xx based boards.
Signed-off-by: Christian Engelmayer
the needed behaviour as
there is no common behaviour that can comply with both requirements.
Signed-off-by: Christian Engelmayer christian.engelma...@frequentis.com
---
Did I understand You correctly to add a new flag analogous to eg. ignore_oc,
or would You prefer a new quirks flag in the driver
Hi,
I am currently looking into a seeming regression in ehci-hub.c where a change
triggered by the behaviour of the MAX4967 USB power supply chip has broken the
handling of the MPC8349 USB controller at that point. I'd like to come up
with a patch solving the issue for both chips and would
