Re: Add MediaTek USB3 DRD Driver

Hi Felipe: Could you please give me some suggestions if you have already reviewed some codes. Thanks a lot. On Wed, 2016-06-15 at 11:07 +0800, Chunfeng Yun wrote: > From 48552e96e4e33f8830cb6a59154fe148425532fd Mon Sep 17 00:00:00 2001 > From: Chunfeng Yun > Date:

Re: pl2303_read_int_callback - usb_submit_urb failed with result -19

I think i am. int readDword(int addr) { uint16_t reg[1];// will store read registers values int num = modbus_read_registers(ctx, addr, 1, reg); //16386 = X2 usleep(5); if (num != 1) { fprintf(stderr, "Failed(%i) to read: %s\n", num, modbus_strerror(errno));

Re: [PATCH 0/2] usb: add HCD providers

On 13 July 2016 at 06:51, Peter Chen wrote: > On Tue, Jul 12, 2016 at 02:35:18PM +0200, Rafał Miłecki wrote: >> I was working on an "usbport" LED trigger driver and specifying its >> default state in DT. I realized I can't really determine numbering of >> USB ports on any

Re: [PATCH 0/2] usb: add HCD providers

On Tue, Jul 12, 2016 at 02:35:18PM +0200, Rafał Miłecki wrote: > Hi, > > I was working on an "usbport" LED trigger driver and specifying its > default state in DT. I realized I can't really determine numbering of > USB ports on any device as it depends on compiled drivers and the > loading

Re: pl2303_read_int_callback - usb_submit_urb failed with result -19

On Wed, Jul 13, 2016 at 08:58:48AM +0530, Malith Yapa wrote: > The reason for the random disconnects is apparently EMI related. > > Mar 1 07:09:09 localhost kernel: [265922.921985] hub 5-0:1.0: port 1 > disabled by hub (EMI?), re-enabling... > > This is very much a possibility because the box

Re: [PATCH v6 5/5] usb: dwc3: rockchip: add devicetree bindings documentation

Dear Rob, On 2016/7/11 23:13, Rob Herring wrote: On Thu, Jul 07, 2016 at 10:58:44AM +0800, William Wu wrote: This patch adds the devicetree documentation required for Rockchip USB3.0 core wrapper consisting of USB3.0 IP from Synopsys. It supports DRD mode, and could operate in device mode

Re: [PATCH v6 3/5] usb: dwc3: add phyif_utmi_quirk

Dear Rob, On 2016/7/11 22:58, Rob Herring wrote: On Thu, Jul 07, 2016 at 10:54:24AM +0800, William Wu wrote: Add a quirk to configure the core to support the UTMI+ PHY with an 8- or 16-bit interface. UTMI+ PHY interface is hardware property, and it's platform dependent. Normall, the PHYIf can

Re: [PATCH v6 3/5] usb: dwc3: add phyif_utmi_quirk

Dear Rob, On 2016/7/11 22:54, Rob Herring wrote: On Fri, Jul 08, 2016 at 02:33:09PM +0200, Heiko Stuebner wrote: Hi William, Am Donnerstag, 7. Juli 2016, 10:54:24 schrieb William Wu: Add a quirk to configure the core to support the UTMI+ PHY with an 8- or 16-bit interface. UTMI+ PHY

Re: pl2303_read_int_callback - usb_submit_urb failed with result -19

The reason for the random disconnects is apparently EMI related. Mar 1 07:09:09 localhost kernel: [265922.921985] hub 5-0:1.0: port 1 disabled by hub (EMI?), re-enabling... This is very much a possibility because the box is in a high current industrial control panel. That is not an issue

Re: [PATCH v6 3/5] usb: dwc3: add phyif_utmi_quirk

Dear Heiko, On 2016/7/10 7:47, Heiko Stuebner wrote: Am Samstag, 9. Juli 2016, 11:38:00 schrieb William.wu: Dear Heiko & Balbi， On 2016/7/8 21:29, Felipe Balbi wrote: Hi, Heiko Stuebner writes: Am Donnerstag, 7. Juli 2016, 10:54:24 schrieb William Wu: Add a quirk to

[PATCH v2 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 v2 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 v2 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 v2 6/6] ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property

From: Peter Chen 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

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

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

[PATCH v2 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: mceusb xhci issue?

On Sat, 9 Jul 2016, Mauro Carvalho Chehab wrote: > C/C linux-usb Mailing list: > > > Em Wed, 18 May 2016 08:52:28 -0600 > Wade Berrier escreveu: ... > > > That message above links to some other threads describing the issue. > > > Here's a post with a patch that supposedly

RE: [PATCH v6 RESEND] r8152: Add support for setting pass through MAC address on RTL8153-AD

> -Original Message- > From: Michał Pecio [mailto:michal.pe...@gmail.com] > Sent: Tuesday, July 12, 2016 2:03 AM > To: David Miller > Cc: Limonciello, Mario ; linux- > ker...@vger.kernel.org; net...@vger.kernel.org; linux- >

[PATCH 2/2] ohci-platform: register HCD provider

This allows platforms using e.g. "generic-ohci" to reference HCD using recently introduced providers mechanism Signed-off-by: Rafał Miłecki --- drivers/usb/host/ohci-platform.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/usb/host/ohci-platform.c

[PATCH 1/2] usb: core: add support for HCD providers

When working with Device Tree we may need to reference controllers (their nodes) and query for HCDs. This is useful for getting some runtime info about host controllers like e.g. assigned bus number. Signed-off-by: Rafał Miłecki --- drivers/usb/core/Makefile| 1 +

[PATCH PROOF OF CONCEPT 3/2] trigger: ledtrig-usbport: read initial state from DT

This allows specifying USB ports that should be observed by a trigger right after activating it. Example: usb { gpios = < 0 GPIO_ACTIVE_HIGH>; linux,default-trigger = "usbport"; usb-controllers = <>, <>, <>; usb-ports = "1", "1", "1"; }; Signed-off-by: Rafał

[PATCH 0/2] usb: add HCD providers

Hi, I was working on an "usbport" LED trigger driver and specifying its default state in DT. I realized I can't really determine numbering of USB ports on any device as it depends on compiled drivers and the loading orders. It means that my physical USB port can be e.g. 1-1 or 2-1 depending on

RE: [PATCH] usb:solve resume usb device identification problem

> -Original Message- > From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Tuesday, July 12, 2016 10:24 AM > To: Lipengcheng; gre...@linuxfoundation.org; st...@rowland.harvard.edu; > chasemetzge...@gmail.com; mathias.ny...@linux.intel.com; > oneu...@suse.com; jun...@freescale.com >

[PATCH 2/2] usb: chipidea: usbmisc: set over current polarity for imx6 and imx7

As all usb power supply use low active for over current flag on imx6 imx7 boards, and the default register setting(0) is for high active, this patch is to correct it. Signed-off-by: Li Jun --- drivers/usb/chipidea/usbmisc_imx.c | 18 -- 1 file changed, 16

[PATCH v3] usb: gadget: f_midi: Add checking if it need align buffer's size to an ep's maxpacketsize

Some gadget device (such as dwc3 gadget) requires quirk_ep_out_aligned_size attribute, which means it need to align the request buffer's size to an ep's maxpacketsize. Thus we add usb_ep_align_maybe() function to check if it is need to align the request buffer's size to an ep's maxpacketsize.

[PATCH 1/2] doc: usb: usbmisc-imx: add imx7d compatible string

Add compatible string for imx7d-usbmisc. Signed-off-by: Li Jun --- Documentation/devicetree/bindings/usb/usbmisc-imx.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt

RE: [PATCH v2 1/5] drivers: usb: chipidea: Add qoriq platform driver

> -Original Message- > From: Peter Chen [mailto:hzpeterc...@gmail.com] > Sent: Monday, July 11, 2016 12:14 PM > To: Rajesh Bhagat > Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; > devicet...@vger.kernel.org; Peter Chen ; >

[PATCH] scsi: introduce a quirk for false cache reporting

Some SATA to USB bridges fail to cooperate with some drives resulting in no cache being present being reported to the host. That causes the host to skip sending a command to synchronize caches. That causes data loss when the drive is powered down. Signed-off-by: Oliver Neukum

Re: usb-serial remembers termios settings between device replugs

On Tuesday, 12 July 2016 01:50:59 CEST, Greg KH wrote: There is, as far as I can tell, no set of "default" termios values for any type of serial port, so the "last" set of them is as good as any, right? Each driver specifies an initial value (usb_serial_tty_driver->init_termios), and this

Re: Problem getting USB DAC to work

Thanks Alan, I will do that :-) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 RESEND] r8152: Add support for setting pass through MAC address on RTL8153-AD

> From: Mario Limonciello > Date: Mon, 11 Jul 2016 19:58:04 -0500 > > > The RTL8153-AD supports a persistent system specific MAC address. > > This means a device plugged into two different systems with host > > side support will show different (but persistent) MAC