Re: pl2303_read_int_callback - usb_submit_urb failed with result -19

On Thu, Jul 14, 2016 at 2:14 AM, Greg KH wrote: > On Wed, Jul 13, 2016 at 10:59:10AM +0530, Malith Yapa wrote: >> I think i am. >> >> int readDword(int addr) { >> >> uint16_t reg[1];// will store read registers values >> >> int num = modbus_read_registers(ctx,

RE: [PATCH] usb3: Fixed usb3 device is not detected in s0 when hotplug usb3 disk under S3

On Mon, 11 Jul 2016: Alan Stern wrote: > On Mon, 11 Jul 2016, Huang, Huki wrote: > > When end user inserts a usb3 device and put dut to s3. > What does "dut" mean? DUT : Device under test > > Then hotplug the usb3 disk under s3. > Do you mean that the device is unplugged and the USB disk

FW: [PATCH] usb3: Fixed usb3 device is not detected in s0 when hotplug usb3 disk under S3

On Mon, 11 Jul 2016: Alan Stern wrote: > On Mon, 11 Jul 2016, Huang, Huki wrote: > > When end user inserts a usb3 device and put dut to s3. > What does "dut" mean? DUT : Device under test > > Then hotplug the usb3 disk under s3. > Do you mean that the device is unplugged and the USB disk

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

On 07/13/2016 01:42 AM, Peter Chen wrote: > On Wed, Jul 13, 2016 at 09:27:31AM +0200, Philipp Zabel wrote: >> Am Mittwoch, den 13.07.2016, 10:06 +0800 schrieb Peter Chen: >>> Add binding doc for generic power sequence library. >>> >>> Signed-off-by: Peter Chen >>> --- >>>

Re: Novatel OEM usbserial compatible settings

Tony Enerson writes: > For an integration we are doing here I have needed to add the > following device to use the usbserial driver. It is a Novatel OEM GPS > receiver card that has on-board USB-serial capability and it works > well with the default usbserial driver. The

Re: [PATCH] rndis_host: Set random MAC for ZTE MF910

Kristian Evensen writes: > From: Kristian Evensen > > All ZTE MF910 mifis, at least on some revisions, export the same MAC > address (36:4b:50:b7:ef:da). Check for this MAC address and set a random > MAC if detected. > > Also, changed the

Re: pl2303_read_int_callback - usb_submit_urb failed with result -19

On Wed, Jul 13, 2016 at 10:59:10AM +0530, Malith Yapa wrote: > 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) { >

Novatel OEM usbserial compatible settings

For an integration we are doing here I have needed to add the following device to use the usbserial driver. It is a Novatel OEM GPS receiver card that has on-board USB-serial capability and it works well with the default usbserial driver. The dmesg output mentioned I should forward the

[PATCH] rndis_host: Set random MAC for ZTE MF910

From: Kristian Evensen All ZTE MF910 mifis, at least on some revisions, export the same MAC address (36:4b:50:b7:ef:da). Check for this MAC address and set a random MAC if detected. Also, changed the memcpy() to ether_addr_copy(), as pointed out by checkpatch.

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

On 13 July 2016 at 16:48, Jacek Anaszewski wrote: > On 07/13/2016 02:42 PM, Rafał Miłecki wrote: >> >> This allows specifying USB ports that should be observed by a trigger >> right after activating it. Example: >> >> usb { >> gpios = < 0 GPIO_ACTIVE_HIGH>; >>

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

Hi Rafał, On 07/13/2016 02:42 PM, Rafał Miłecki wrote: 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 = <>, <>, <

Re: [PATCH V2 0/1] usb: add HCD providers

On 13 July 2016 at 15:50, Felipe Balbi wrote: > Rafał Miłecki writes: >> On 13 July 2016 at 15:20, Felipe Balbi wrote: >>> Rafał Miłecki writes: Hi again, This is my second try of

Re: [PATCH V2 0/1] usb: add HCD providers

Hi, Rafał Miłecki writes: > On 13 July 2016 at 15:20, Felipe Balbi wrote: >> Rafał Miłecki writes: >>> Hi again, >>> >>> This is my second try of getting HCD providers into usb subsystem. >>> >>> During discussion of V1 I

Re: [PATCH V2 0/1] usb: add HCD providers

On 13 July 2016 at 15:20, Felipe Balbi wrote: > Rafał Miłecki writes: >> Hi again, >> >> This is my second try of getting HCD providers into usb subsystem. >> >> During discussion of V1 I realized there are about 26 drivers adding a >> single HCD

Re: [PATCH V2 0/1] usb: add HCD providers

Hi, Rafał Miłecki writes: > Hi again, > > This is my second try of getting HCD providers into usb subsystem. > > During discussion of V1 I realized there are about 26 drivers adding a > single HCD and all of them would need to be modified. So instead I > decided to put

[PATCH V2 PROOF OF CONCEPT 2/1] 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_HCD_SHARED>; usb-ports = "1", "1", "1"; };

[PATCH V2 0/1] usb: add HCD providers

Hi again, This is my second try of getting HCD providers into usb subsystem. During discussion of V1 I realized there are about 26 drivers adding a single HCD and all of them would need to be modified. So instead I decided to put relevant code in usb_add_hcd. It checks if the HCD we register is

[PATCH V2 1/1] 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] usb: gadget: fsl_qe_udc: off by one in setup_received_handle()

The udc->eps[] array has USB_MAX_ENDPOINTS elements so > should be >=. Fixes: 3948f0e0c999 ('usb: add Freescale QE/CPM USB peripheral controller driver') Signed-off-by: Dan Carpenter diff --git a/drivers/usb/gadget/udc/fsl_qe_udc.c

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

On 13 July 2016 at 10:02, Peter Chen wrote: > On Wed, Jul 13, 2016 at 07:21:09AM +0200, Rafał Miłecki wrote: >> 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

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

On Wed, Jul 13, 2016 at 09:27:31AM +0200, Philipp Zabel wrote: > Am Mittwoch, den 13.07.2016, 10:06 +0800 schrieb Peter Chen: > > Add binding doc for generic power sequence library. > > > > Signed-off-by: Peter Chen > > --- > > .../bindings/power/pwrseq/pwrseq-generic.txt

[PATCH] usb: ehci-platform: use helper variables in probe function

Probing function was using >dev and dev->dev.of_node over 20 times so I believe it made sense to use helper variables for both of them. To avoid some uncommon variable name for struct device I first replaced existing dev variable with pdev. Signed-off-by: Rafał Miłecki ---

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

On Wed, Jul 13, 2016 at 07:21:09AM +0200, Rafał Miłecki wrote: > 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.

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

Am Mittwoch, den 13.07.2016, 10:06 +0800 schrieb Peter Chen: > Add binding doc for generic power sequence library. > > Signed-off-by: Peter Chen > --- > .../bindings/power/pwrseq/pwrseq-generic.txt | 53 > ++ > 1 file changed, 53 insertions(+) >

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

> So in order to hit this hypothetical corner case today you would > need to be using a real world type-C device something such as a > Dell WD15 on another OEM's machine that has type-C and the exact > same ACPI object name that does $BADSTUFF other than return a > buffer. Exactly what I meant.