Re: usbtmc: vendor specific i/o

On Mon, Aug 01, 2016 at 08:40:02PM +0200, Ladislav Michl wrote: > Hi, > > I need to ask usbtmc device for vendor specific data. What about adding ioctl > which switches MsgIDs to be vendor specific? Or are there other, better, > options? Patch bellow ilustrates changes to allow reading and

[PATCH v4 6/6] ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property

The current dts describes USB HUB's property at USB controller's entry, it is improper. The USB HUB should be the child node under USB controller, and power sequence properties are under it. Signed-off-by: Peter Chen --- arch/arm/boot/dts/imx6qdl-udoo.dtsi | 26

[PATCH v4 3/6] binding-doc: usb: usb-device: add optional properties for power sequence

Add optional properties for power sequence. Signed-off-by: Peter Chen Acked-by: Rob Herring --- Documentation/devicetree/bindings/usb/usb-device.txt | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git

[PATCH v4 5/6] usb: chipidea: let chipidea core device of_node equal's glue layer device of_node

From: Peter Chen At device tree, we have no device node for chipidea core, the glue layer's node is the parent node for host and udc device. But in related driver, the parent device is chipidea core. So, in order to let the common driver get parent's node, we let the

Re: [v3,2/6] power: add power sequence library

On Fri, Jul 29, 2016 at 01:06:48PM -0700, Matthias Kaehlcke wrote: > >... > > > >+static int pwrseq_generic_get(struct device_node *np, struct pwrseq *pwrseq) > >+{ > >+struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq); > >+enum of_gpio_flags flags; > >+int reset_gpio, ret

[PATCH v4 1/6] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

Add binding doc for generic power sequence library. Signed-off-by: Peter Chen Acked-by: Philipp Zabel Acked-by: Rob Herring --- .../bindings/power/pwrseq/pwrseq-generic.txt | 48 ++ 1 file changed, 48

[PATCH v4 4/6] usb: core: add power sequence handling for USB devices

Some hard-wired USB devices need to do power sequence to let the device work normally, the typical power sequence like: enable USB PHY clock, toggle reset pin, etc. But current Linux USB driver lacks of such code to do it, it may cause some hard-wired USB devices works abnormal or can't be

[PATCH v4 2/6] power: add power sequence library

We have an well-known problem that the device needs to do some power sequence before it can be recognized by related host, the typical example like hard-wired mmc devices and usb devices. This power sequence is hard to be described at device tree and handled by related host driver, so we have

[PATCH v4 0/6] power: add power sequence library

Hi all, This is a follow-up for my last power sequence framework patch set [1]. According to Rob Herring and Ulf Hansson's comments[2], I use a generic power sequence library for parsing the power sequence elements on DT, and implement generic power sequence on library. The host driver can

[PATCH] extcon: Split out the extcon APIs for extcon provider driver

This patchs split out the extcon APIs of extcon provider driver in order to prevent the direct access of struct extcon_dev by extcon consumer driver. The extcon consumer driver don't need to handle the extcon provider APIs. The extcon subsystem has two type of extcon drivers as following: -

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

On 31-07-16, 23:31, Matwey V. Kornilov wrote: > Hello, > > I've also just found that the same commit breaks cpufreq on BeagleBone Black > :) > > So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU > frequency, which is unlisted and being set to 720Mhz by cpufreq driver > (as

Re: [PATCH v3 0/6] power: add power sequence library

On Mon, Aug 01, 2016 at 07:55:10AM -0700, Joshua Clayton wrote: > > > On 07/28/2016 09:41 AM, Fabio Estevam wrote: > > Hi Joshua, > > > > On Thu, Jul 28, 2016 at 12:56 PM, Joshua Clayton > > wrote: > > > >> I assume there is a v4 coming due to rmk's comments on patch

[PATCH v2] USB: validate wMaxPacketValue entries in endpoint descriptors

Erroneous or malicious endpoint descriptors may have non-zero bits in reserved positions, or out-of-bounds values. This patch helps prevent these from causing problems by bounds-checking the wMaxPacketValue entries in endpoint descriptors and capping the values at the maximum allowed. This issue

Re: [PATCH] USB: validate wMaxPacketValue entries in endpoint descriptors

On Mon Aug 01 2016 14:28:46 GMT-0400 (EDT), Greg KH wrote: > On Mon, Aug 01, 2016 at 02:04:06PM -0400, Alan Stern wrote: >> On Mon, 1 Aug 2016, roswest wrote: >> >>> Alan, >>> >>> I think it would be more accurate to put Jake Lamberson as the reporter >>> and tester. >> >> I could mention him in

Re: [PATCH] USB: validate wMaxPacketValue entries in endpoint descriptors

On Mon, Aug 01, 2016 at 02:04:06PM -0400, Alan Stern wrote: > On Mon, 1 Aug 2016, roswest wrote: > > > Alan, > > > > I think it would be more accurate to put Jake Lamberson as the reporter > > and tester. > > I could mention him in the body of the patch description. But it > doesn't seem

Re: [PATCH] USB: validate wMaxPacketValue entries in endpoint descriptors

On Mon, Aug 01, 2016 at 12:18:54PM -0400, Alan Stern wrote: > Erroneous or malicious endpoint descriptors may have non-zero bits in > reserved positions, or out-of-bounds values. This patch helps prevent > these from causing problems by bounds-checking the wMaxPacketValue > entries in endpoint

Re: [RFC] usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue

On Mon, 1 Aug 2016, Tejun Heo wrote: > Hello, > > On Mon, Aug 01, 2016 at 03:50:36PM +0200, Michal Hocko wrote: > > > All that would do is deferring the deadlock, right? I'm not sure it > > > makes a lot of sense to protect an IO path against memory pressure > > > half-way. It either can be

usbtmc: vendor specific i/o

Hi, I need to ask usbtmc device for vendor specific data. What about adding ioctl which switches MsgIDs to be vendor specific? Or are there other, better, options? Patch bellow ilustrates changes to allow reading and writing vendor specific messages. Thank you, ladis diff --git

Re: [PATCH] USB: validate wMaxPacketValue entries in endpoint descriptors

On Mon, 1 Aug 2016, roswest wrote: > Alan, > > I think it would be more accurate to put Jake Lamberson as the reporter > and tester. I could mention him in the body of the patch description. But it doesn't seem appropriate to list him as the reporter or tester because he didn't report anything

Re: [RFC] usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue

On Mon 01-08-16 14:00:57, Alan Stern wrote: > On Mon, 1 Aug 2016, Tejun Heo wrote: > > > Hello, > > > > On Mon, Aug 01, 2016 at 03:50:36PM +0200, Michal Hocko wrote: > > > > All that would do is deferring the deadlock, right? I'm not sure it > > > > makes a lot of sense to protect an IO path

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

2016-08-01 20:06 GMT+03:00 Viresh Kumar : > On 01-08-16, 20:01, Matwey V. Kornilov wrote: >> With this patch, there is no cpufreq directory here. >> >> Without this patch, the output is the following: >> >> nohostname:~ # uname -a >> Linux nohostname

[PATCH v2 01/10] usb: ulpi: move setting of ulpi->dev parent up in ulpi_register()

Once ulpi operations use the parent device directly, this will be needed during the operations used in ulpi_register() itself, so set the parent field before calling any ulpi operations. Signed-off-by: Tal Shorer --- drivers/usb/common/ulpi.c | 3 ++- 1 file changed, 2

[PATCH v2 06/10] usb: ulpi: remove old api callbacks from struct ulpi_ops

The old api callbacks, read() and write(), are not referenced anywhere. Remove them. Signed-off-by: Tal Shorer --- include/linux/ulpi/interface.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/linux/ulpi/interface.h b/include/linux/ulpi/interface.h index

[PATCH v2 04/10] usb: dwc3: ulpi: use new api

The old read, write callbacks in struct ulpi_ops have been deprecated in favor of new callbacks that pass the parent device directly. Replace the used callbacks in dwc3's ulpi component with the new api. Signed-off-by: Tal Shorer --- drivers/usb/dwc3/ulpi.c | 12

[PATCH v2 03/10] usb: ulpi: use new api functions if available

If the registered has the new api callbacks {read|write}_dev, call these instead of the deprecated read, write functions. If the registered does not support the new callbacks, revert to calling the old ones as before. Signed-off-by: Tal Shorer --- drivers/usb/common/ulpi.c

[PATCH v2 02/10] usb: ulpi: add new api functions, {read|write}_dev()

Add these two new api callbacks to struct ulpi_ops. These are different than read, write in that they pass the parent device directly instead of via the ops argument. They are intended to replace the old api functions. Signed-off-by: Tal Shorer ---

[PATCH v2 00/10] usb: ulpi: remove "dev" field from struct ulpi_ops

struct ulpi_ops is defined as follows: struct ulpi_ops { struct device *dev; int (*read)(struct ulpi_ops *ops, u8 addr); int (*write)(struct ulpi_ops *ops, u8 addr, u8 val); }; Upon calling ulpi_register_interface(), the struct device argument is put inside the struct

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

pwc module output with trace=511 is the following: [ 24.793109] usbcore: registered new interface driver Philips webcam [ 29.276979] pwc: Unsupported pixel format [ 29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480, bytesperline=640, sizeimage=460800, pixelformat=YU12 [

[PATCH v2 09/10] usb: ulpi: make ops struct constant

None of the core ulpi functions perform any changes to the operations struct, and logically as a struct that contains function pointers there's no reason it shouldn't be constant. Signed-off-by: Tal Shorer --- drivers/usb/common/ulpi.c | 3 ++-

[PATCH v2 07/10] usb: ulpi: rename operations {read|write}_dev to simply {read|write}

With the removal of the old {read|write} operations, we can now safely rename the new api operations {read|write}_dev to use the shorter and clearer names {read|write}, respectively. Signed-off-by: Tal Shorer --- drivers/usb/common/ulpi.c | 4 ++--

[PATCH v2 05/10] usb: ulpi: remove calls to old api callbacks

Now that all users use the new api callbacks, remove the calls to the old api functions and force new interface drivers to use the new api. Signed-off-by: Tal Shorer --- drivers/usb/common/ulpi.c | 4 1 file changed, 4 deletions(-) diff --git

[PATCH v2 08/10] usb: ulpi: remove "dev" field from struct ulpi_ops

Operations now use ulpi->dev.parent directly instead of via the ulpi_ops struct, making this field unused. Remove it. Signed-off-by: Tal Shorer --- drivers/usb/common/ulpi.c | 1 - include/linux/ulpi/interface.h | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-)

[PATCH v2 10/10] usb: dwc3: ulpi: make dwc3_ulpi_ops constant

ulpi_register_interface() accepts a const struct ulpi_ops and dwc3 doesn't perform any changes to this struct at runtime, so there's no reason it shouldn't be constant. Signed-off-by: Tal Shorer --- drivers/usb/dwc3/ulpi.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

On 01-08-16, 20:01, Matwey V. Kornilov wrote: > With this patch, there is no cpufreq directory here. > > Without this patch, the output is the following: > > nohostname:~ # uname -a > Linux nohostname 4.6.4-3.gecd9058-default #1 SMP PREEMPT Fri Jul 15 > 08:08:50 UTC 2016 (ecd9058) armv7l armv7l

Re: [PATCH] USB: validate wMaxPacketValue entries in endpoint descriptors

Alan, I think it would be more accurate to put Jake Lamberson as the reporter and tester. Thanks, Rosie On Mon Aug 01 2016 12:18:54 GMT-0400 (EDT), Alan Stern wrote: > Erroneous or malicious endpoint descriptors may have non-zero bits in > reserved positions, or out-of-bounds values. This

Re: pwc over musb: 100% frame drop (lost) on high resolution stream

2016-08-01 19:50 GMT+03:00 Viresh Kumar : > On 31-07-16, 23:31, Matwey V. Kornilov wrote: >> Hello, >> >> I've also just found that the same commit breaks cpufreq on BeagleBone Black >> :) >> >> So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU >>

Re: NEC uPD720200 xHCI Controller dies when Runtime PM enabled

Hi Mike, On Mon, Aug 1, 2016 at 12:05 PM, Mike Murdoch wrote: > On 2016-08-01 13:57, Durval Menezes wrote: > > Hi Mathias, > > > > On Mon, Aug 1, 2016 at 8:20 AM, Mathias Nyman > > wrote: > >>> On 01.08.2016 13:15, Durval Menezes wrote:

Re: [PATCH v3 0/6] power: add power sequence library

On Mon, Aug 1, 2016 at 11:55 AM, Joshua Clayton wrote: > Thanks a million, Fabio! > > 'usbcore.autosuspend=-1' quiets the errors. > > ~joshua > > P.S. I guess this technically is a bug in chipidea usb. > I'll give it a quick once over, though I am not very familiar >

Re: [PATCH] usb: ehci: change order of register cleanup during shutdown

On Mon, 1 Aug 2016, Marc Ohlf wrote: > In ehci_turn_off_all_ports() all EHCI port register bits > (except the PORT_RWC_BITS) are set to zero. Even the PORT_WRC_BITS are set to 0. Oddly enough, the way to set those bits to 0 is to write a 1 to them (see Table 2-16 in the EHCI spec). > On some

Re: [PATCH] xhci: Fix soft lockup in xhci_pci_probe path when XHCI_STATE_HALTED

Kamal Mostafa writes: > Commit 27a41a83ec54 ("xhci: Cleanup only when releasing primary hcd") > causes a soft lockup at boot when XHCI_STATE_HALTED, preventing > VirtualBox 5.1.x from booting if USB3.0 is enabled. > > Revert to allowing xhci_irq to handle the interrupt when

[PATCH] USB: validate wMaxPacketValue entries in endpoint descriptors

Erroneous or malicious endpoint descriptors may have non-zero bits in reserved positions, or out-of-bounds values. This patch helps prevent these from causing problems by bounds-checking the wMaxPacketValue entries in endpoint descriptors and capping the values at the maximum allowed.

[PATCH] xhci: Fix soft lockup in xhci_pci_probe path when XHCI_STATE_HALTED

Commit 27a41a83ec54 ("xhci: Cleanup only when releasing primary hcd") causes a soft lockup at boot when XHCI_STATE_HALTED, preventing VirtualBox 5.1.x from booting if USB3.0 is enabled. Revert to allowing xhci_irq to handle the interrupt when XHCI_STATE_HALTED but not XHCI_STATE_DYING. Fixes:

[PATCH v2] usb: gadget: Add per-lun inquiry string

Introduce an attribute "inquiry_string" to the lun. In some environments, e. g. BIOS boot menus, the inquiry string is the only information about devices presented to the user. The default string depends on the "cdrom" bit of the first lun as well as the kernel version and allows no further

Re: NEC uPD720200 xHCI Controller dies when Runtime PM enabled

Hello, On 2016-08-01 13:57, Durval Menezes wrote: > Hi Mathias, > > On Mon, Aug 1, 2016 at 8:20 AM, Mathias Nyman > wrote: >>> On 01.08.2016 13:15, Durval Menezes wrote: >>> Hello Mike, Mathias, list, >>> >>> On 06.02.2016 19:08, Mike Murdoch wrote: >>> Bug ID:

Re: [PATCH v3 0/6] power: add power sequence library

On 07/28/2016 09:41 AM, Fabio Estevam wrote: > Hi Joshua, > > On Thu, Jul 28, 2016 at 12:56 PM, Joshua Clayton > wrote: > >> I assume there is a v4 coming due to rmk's comments on patch 5. >> I couldn't figure out where to null the of_node in error paths, but in >>

Re: [RFC] usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue

Hello, On Mon, Aug 01, 2016 at 03:50:36PM +0200, Michal Hocko wrote: > > All that would do is deferring the deadlock, right? I'm not sure it > > makes a lot of sense to protect an IO path against memory pressure > > half-way. It either can be depended during memory reclaim or it > > can't. >

Re: [RFC] usb: host: u132-hcd: Remove deprecated create_singlethread_workqueue

On Fri 29-07-16 09:11:47, Tejun Heo wrote: > Hello, Alan. > > On Wed, Jul 27, 2016 at 04:45:19PM -0400, Alan Stern wrote: > > > Hmm... That doesn't really make them dependable during memory reclaim. > > > > True. But it does mean that they can't cause a deadlock by waiting > > indefinitely for

Re: NEC uPD720200 xHCI Controller dies when Runtime PM enabled

Hi Mathias, On Mon, Aug 1, 2016 at 8:20 AM, Mathias Nyman wrote: > > On 01.08.2016 13:15, Durval Menezes wrote: > > Hello Mike, Mathias, list, > > > > On 06.02.2016 19:08, Mike Murdoch wrote: > > Bug ID: 111251 > > > > I have a NEC uPD720200 USB3.0 controller in

Re: Possible design problem with struct ulpi_ops's dev field

Hi, Tal Shorer writes: > struct ulpi_ops is defined as follows: > > struct ulpi_ops { > struct device *dev; > int (*read)(struct ulpi_ops *ops, u8 addr); > int (*write)(struct ulpi_ops *ops, u8 addr, u8 val); > }; > > Upon calling

Re: NEC uPD720200 xHCI Controller dies when Runtime PM enabled

Hi On 01.08.2016 13:15, Durval Menezes wrote: Hello Mike, Mathias, list, On 06.02.2016 19:08, Mike Murdoch wrote: Bug ID: 111251 I have a NEC uPD720200 USB3.0 controller in a Thinkpad W520 laptop on kernel 4.4.1-gentoo. 0e:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host

Re: NEC uPD720200 xHCI Controller dies when Runtime PM enabled

Hello Mike, Mathias, list, On 06.02.2016 19:08, Mike Murdoch wrote: > Bug ID: 111251 > > I have a NEC uPD720200 USB3.0 controller in a Thinkpad W520 laptop on > kernel 4.4.1-gentoo. > > 0e:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host > Controller (rev 04) (prog-if 30 [XHCI]) >

Re: [PATCH 3/3] ehci-platform: add the max clock number to 4

Hi, On 01-08-16 10:18, Icenowy Zheng wrote: 01.08.2016, 15:27, "Hans de Goede" : Hi, On 01-08-16 09:05, Icenowy Zheng wrote: clocks = < CLK_A64_BUS_OHCI1>, < CLK_A64_BUS_EHCI1>,

[PATCH] usb: ehci: change order of register cleanup during shutdown

In ehci_turn_off_all_ports() all EHCI port register bits (except the PORT_RWC_BITS) are set to zero. On some hardware, this can lead to an system hang, when ehci_port_power() accesses the already cleaned registers. This patch changes the order of cleanup. First call ehci_port_power() which

Re: [RFC] usb: phy: generic: get rid of VBUS handling

Hi, Robert Jarzmik writes: > Felipe Balbi writes: > >> Hi Robert, >> >> Robert Jarzmik writes: >>> Felipe Balbi writes: >>> Hi, Robert Jarzmik

Re: [PATCH 3/3] ehci-platform: add the max clock number to 4

Hi, On 01-08-16 09:05, Icenowy Zheng wrote: clocks = < CLK_A64_BUS_OHCI1>, < CLK_A64_BUS_EHCI1>, < CLK_A64_USB_OHCI0>, < CLK_A64_USB_OHCI1>; On A64, EHCI requires the

[PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

Currently the Linux kernel does not provide any standard integration of this feature that integrates the USB subsystem with the system power regulation provided by PMICs meaning that either vendors must add this in their kernels or USB gadget devices based on Linux (such as mobile phones) may not

[PATCH v16 2/4] usb: gadget: Support for the usb charger framework

For supporting the usb charger, it adds the usb_charger_init() and usb_charger_exit() functions for usb charger initialization and exit. It will report to the usb charger when the gadget state is changed, then the usb charger can do the power things. Signed-off-by: Baolin Wang

[PATCH v16 3/4] usb: gadget: Integrate with the usb gadget supporting for usb charger

When the usb gadget supporting for usb charger is ready, the usb charger can implement the usb_charger_plug_by_gadget() function, usb_charger_exit() function and dev_to_uchger() function by getting 'struct usb_charger' from 'struct gadget'. Signed-off-by: Baolin Wang

[PATCH v16 1/4] usb: gadget: Introduce the usb charger framework

This patch introduces the usb charger driver based on usb gadget that makes an enhancement to a power driver. It works well in practice but that requires a system with suitable hardware. The basic conception of the usb charger is that, when one usb charger is added or removed by reporting from

[PATCH v16 4/4] power: wm831x_power: Support USB charger current limit management

Integrate with the newly added USB charger interface to limit the current we draw from the USB input based on the input device configuration identified by the USB stack, allowing us to charge more quickly from high current inputs without drawing more current than specified from others.

Re: [PATCH 3/3] ehci-platform: add the max clock number to 4

On Sunday, July 31, 2016 7:25:36 PM CEST Icenowy Zheng wrote: > Allwinner A64 EHCI requires 4 clocks to be enabled. > > Signed-off-by: Icenowy Zheng > Can you say what those four clocks are? Are you sure that it's not just a case of a clock being incorrectly described in the