Re: [PATCH] USB: core: Improve unlocking of a mutex in two functions

On Sat, Nov 4, 2017 at 9:12 PM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 4 Nov 2017 21:00:46 +0100 > > * Add jump targets so that a call of the function "mutex_unlock" is stored > only twice in these function

[PATCH] usb: gadget: bcm63xx_udc: Use common error handling code in bcm63xx_udc_probe()

From: Markus Elfring Date: Sat, 4 Nov 2017 22:02:46 +0100 Add a jump target so that a specific error message is stored only once at the end of this function implementation. Replace two calls of the function "dev_err" by goto statements. This issue was detected by

[PATCH] USB: core: Improve unlocking of a mutex in two functions

From: Markus Elfring Date: Sat, 4 Nov 2017 21:00:46 +0100 * Add jump targets so that a call of the function "mutex_unlock" is stored only twice in these function implementations. * Replace five calls by goto statements. This issue was detected by using the

[PATCH 2/2 v5] typec: tcpm: Only request matching pdos

At present, TCPM code assumes that local device supports variable/batt pdos and always selects the pdo with highest possible power within the board limit. This assumption might not hold good for all devices. To overcome this, this patch makes TCPM only accept a source_pdo when there is a matching

[PATCH 1/2 v5] typec: tcpm: Validate source and sink caps

The source and sink caps should follow the following rules. This patch validates whether the src_caps/snk_caps adheres to it. 6.4.1 Capabilities Message A Capabilities message (Source Capabilities message or Sink Capabilities message) shall have at least one Power Data Object for vSafe5V. The

Re: [PATCH 1/2 v4] typec: tcpm: Validate source and sink caps

Please disregard v4. Going to send another version again. On Sat, Nov 4, 2017 at 11:59 AM, Badhri Jagan Sridharan wrote: > The source and sink caps should follow the following rules. > This patch validates whether the src_caps/snk_caps adheres > to it. > > 6.4.1 Capabilities

Re: [PATCH 2/2 v4] typec: tcpm: Only request matching pdos

Please disregard v4. Going to send another version again. On Sat, Nov 4, 2017 at 11:59 AM, Badhri Jagan Sridharan wrote: > At present, TCPM code assumes that local device supports > variable/batt pdos and always selects the pdo with highest > possible power within the board

[PATCH 1/2 v4] typec: tcpm: Validate source and sink caps

The source and sink caps should follow the following rules. This patch validates whether the src_caps/snk_caps adheres to it. 6.4.1 Capabilities Message A Capabilities message (Source Capabilities message or Sink Capabilities message) shall have at least one Power Data Object for vSafe5V. The

[PATCH 2/2 v4] typec: tcpm: Only request matching pdos

At present, TCPM code assumes that local device supports variable/batt pdos and always selects the pdo with highest possible power within the board limit. This assumption might not hold good for all devices. To overcome this, this patch makes TCPM only accept a source_pdo when there is a matching

Re: [PATCH 2/2] typec: tcpm: Only request matching pdos

On Thu, Nov 2, 2017 at 4:00 AM, Heikki Krogerus wrote: > Hi, > > +Dan and Guenter > > I'm sorry for the late reply. These slipped under my radar. I do > have a one more proposal below, and a few nits.. > > On Wed, Oct 18, 2017 at 01:22:48PM -0700, Badhri Jagan

[PATCH] usbtmc: Use common error handling code in three functions

From: Markus Elfring Date: Sat, 4 Nov 2017 19:36:56 +0100 * Adjust jump targets so that two error messages are stored only once at the end of these function implementations. * Replace 11 calls of the function "dev_err" and 11 assignments to the variable "rv"

Re: sr9800: Use common error handling code in sr9800_phy_powerup()

> If you play the "smaller executable object code" card, people expect that > you provide the actual numbers, too. I can offer another bit of information for this software development discussion. The affected source file can be compiled for the processor architecture “x86_64” by a tool like “GCC

Re: [PATCH] usb: musb: musb_host: Introduce postponed URB giveback

Hi Bin, I've just checked that the issue is still present in 4.13.10. 2017-04-27 13:20 GMT+03:00 Matwey V. Kornilov : > This commit changes the order of actions undertaken in > musb_advance_schedule() in order to overcome issue with broken > isochronous transfer [1]. > > There

Re: [PATCH] net: usb: asix: fill null-ptr-deref in asix_suspend

From: Andrey Konovalov Date: Thu, 2 Nov 2017 21:26:59 +0100 > When asix_suspend() is called dev->driver_priv might not have been > assigned a value, so we need to check that it's not NULL. > > Found by syzkaller. ... > Signed-off-by: Andrey Konovalov

Re: [PATCH v2] USB: add SPDX identifiers to all remaining files in drivers/usb/

On Fri, Nov 03, 2017 at 05:53:01PM +0100, Johan Hovold wrote: > On Fri, Nov 03, 2017 at 11:28:30AM +0100, Greg Kroah-Hartman wrote: > > It's good to have SPDX identifiers in all files to make it easier to > > audit the kernel tree for correct licenses. > > > > Update the drivers/usb/ and

Re: stopping and starting a functionfs USB-device causes panic

On Fri, Nov 03, 2017 at 10:13:17PM +, andy_purc...@keysight.com wrote: > Hello Felipe, > > > > > > > I have a second issue with a functionfs USB-device implementation. > > > > > > The scenario is this: > > > 1) USB-device app starts up, runs fine > > > 2) ssh to the device, kill the app with

Re: stopping and starting a functionfs USB-device causes panic

andy_purc...@keysight.com wrote: >>> >>> I have a second issue with a functionfs USB-device implementation. >>> >>> The scenario is this: >>> 1) USB-device app starts up, runs fine >>> 2) ssh to the device, kill the app with CTRL-C >>> 3) try to start the USB-device app 2nd time >>> >>> PANIC >>>