RE: Re: Re: Re: [PATCH] usb: core: fix a double free in the usb driver

>On Fri, 3 Jun 2016, Chung-Geol Kim wrote: > >> Yes, you are right, The presentational errors in order to obtain an >> understanding of the process. >> Therefore, I will be happy to explain again the diagrammatic representation >> as shown below. >> If using usb 3.0 storage(OTG), you can see as

Re: [PATCH v3 1/2] Documentation: bindings: add DT documentation for Rockchip USB2PHY

Hi Heiko, On 2016/6/7 10:59, Frank Wang wrote: Hi Heiko & Mark, On 2016/6/6 20:33, Heiko Stübner wrote: Am Montag, 6. Juni 2016, 12:27:54 schrieb Mark Rutland: On Mon, Jun 06, 2016 at 05:20:03PM +0800, Frank Wang wrote: Signed-off-by: Frank Wang --- Changes in

RE: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

Hi Roger > > For Mux devices implementing dual-role, the mux device driver _must_ use > OTG/dual-role core API so that a common ABI is presented to user space for > OTG/dual-role. That's the only point we have concern, do dual role switch through OTG/dual-role core, not do it by itself. > >

Re: [PATCH v3 1/2] Documentation: bindings: add DT documentation for Rockchip USB2PHY

Hi Heiko & Mark, On 2016/6/6 20:33, Heiko Stübner wrote: Am Montag, 6. Juni 2016, 12:27:54 schrieb Mark Rutland: On Mon, Jun 06, 2016 at 05:20:03PM +0800, Frank Wang wrote: Signed-off-by: Frank Wang --- Changes in v3: - Added 'clocks' and 'clock-names' optional

Re: [PATCH v2] usb: dwc3: host: Set the dma_ops for xhci device

On 6 June 2016 at 22:59, Felipe Balbi wrote: > > Hi, > > Baolin Wang writes: >> On ARM64 platform, it will set 'dummy_dma_ops' for device dma_ops if >> it did not call 'arch_setup_dma_ops' at device creation time, that will >> cause failure when setting

Re: [balbi-usb:testing/next 64/67] phy-generic.c:undefined reference to `usb_gadget_vbus_connect'

On Mon, Jun 06, 2016 at 04:16:17PM +0300, Felipe Balbi wrote: > > Hi, > > Felipe Balbi writes: > > [ Unknown signature status ] > > > > Hi, > > > > kbuild test robot writes: > >> tree:

Re: [RFC][PATCH] usb: gadget: Allow to build both USB functions and legacy gadgets

On Mon, Jun 06, 2016 at 09:40:33PM +0200, Krzysztof Opasiak wrote: > Currently it is possible to build in some subset of usb functions > *OR* some gadget module. This is limited only by Kconfig not > any functionality. > > This patch removes this limitation. With this patch it is possible > to

http://www.linux-usb.org/gadget/usb.c exambple problem.

Hi, I need help with getting http://www.linux-usb.org/gadget/usb.c working on my Beagle Bone Black based embedded board. I'm using TI Processor SDK 2.00.02.11 with their linux kernel linux-4.1.18+gitAUTOINC+bbe8cfc1da-gbbe8cfc. My application is based on the usb.c example and it worked OK with

Re: OHCI: NULL or LIST_POISON dereference on ueagle-atm disconnection

> That's clear enough. > > ISO IN 1007 bytes -> 793 us > INT IN 32 bytes -> 35 us >-- >825 us > > The additional requirements are: > > ISO IN 48 bytes -> 45 us -> 870 us total > ISO IN 192 bytes -> 158 us

[no subject]

subscribe linux-usb -- 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] usb: usbip: remove null check

On 06/06/2016 11:23 PM, Sudip Mukherjee wrote: > The only caller of get_gadget_descs() has already dereferenced udc > before calling this function, so udc can not be NULL at this point of > the code and hence no use of checking it. > > Signed-off-by: Sudip Mukherjee

[PATCH] usb: usbip: remove null check

The only caller of get_gadget_descs() has already dereferenced udc before calling this function, so udc can not be NULL at this point of the code and hence no use of checking it. Signed-off-by: Sudip Mukherjee --- drivers/usb/usbip/vudc_sysfs.c | 2 +- 1 file

Re: [PATCH] USB: EHCI: avoid undefined pointer arithmetic and placate UBSAN

Hi Alan, thank you for your effort. I applied it to 4.6.0 and I haven't seen the USBSAN message reported anymore about this (though I do for ext4 and IP stack for example). Tested-By: Martin MOKREJŠ Alan Stern wrote: Several people have reported that UBSAN doesn't like

Re: [RFC][PATCH] usb: gadget: Allow to build both USB functions and legacy gadgets

On 06/06/2016 09:40 PM, Krzysztof Opasiak wrote: > config USB_G_ACM_MS > tristate "CDC Composite Device (ACM and mass storage)" > depends on BLOCK > - select USB_LIBCOMPOSITE > - select USB_U_SERIAL > - select USB_F_ACM > - select USB_F_MASS_STORAGE > + depends

Re: OHCI: NULL or LIST_POISON dereference on ueagle-atm disconnection

On Mon, 6 Jun 2016, Michał Pecio wrote: > > > As I said, it now reports ENOSPC errors if there are low-speed > > > devices or significant isochronous transfers on the bus. > > > > It's quite possible that those are genuine errors. That is, the > > requested bandwidth may be more than the bus

Re: [PATCH v3 00/12] usb/mmc/power: Generic power sequence (and fix USB/LAN when TFTP booting)

Hi, Am Mittwoch, 1. Juni 2016, 10:02:09 schrieb Krzysztof Kozlowski: > My third approach for a USB power sequence which fixes usb3503+lan > on Odroid U3 board if it was initialized by bootloader > (e.g. for TFTP boot). I was just tackling a similar bringup problem regarding an embedded usb hub

[RFC][PATCH] usb: gadget: Allow to build both USB functions and legacy gadgets

Currently it is possible to build in some subset of usb functions *OR* some gadget module. This is limited only by Kconfig not any functionality. This patch removes this limitation. With this patch it is possible to set up all build combinations: 1) Multiple gadgets build in 2) Part of functions

Re: OHCI: NULL or LIST_POISON dereference on ueagle-atm disconnection

> > As I said, it now reports ENOSPC errors if there are low-speed > > devices or significant isochronous transfers on the bus. > > It's quite possible that those are genuine errors. That is, the > requested bandwidth may be more than the bus can provide. Possible. This modem runs 1007 byte

Re: [PATCH 30/62] usb: dwc3: gadget: loop while (timeout)

Felipe Balbi writes: > instead of having infinite loop and always checking > timeout value as a break condition, we can just > decrement timeout inside while's condition. > > Signed-off-by: Felipe Balbi > --- >

Re: OHCI: NULL or LIST_POISON dereference on ueagle-atm disconnection

On Mon, 6 Jun 2016, Michał Pecio wrote: > > Apparently this bug also prevented scheduling of endpoints which > > failed to schedule once in the past. Formerly I was getting only one > > > > usbatm_submit_urb: urb 0x8807f1568b00 submission failed (-28)! > > > > from ueagle-atm and now I'm

Re: Unable to safely detach external HDD on USB 3.0

On Sat, 4 Jun 2016, Marco Chiappero wrote: > On 31/05/2016 16:34, Alan Stern wrote: > > On Tue, 31 May 2016, Mathias Nyman wrote: > > > >> > >> xhci specs say that port will move from Disconnected (PLS = RX_DETECT) to > >> Polling if "SuperSpeed far-end receiver terminations are detected" > >> >

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

> -Original Message- > From: Konstantin Shkolnyy [mailto:konstantin.shkol...@silabs.com] > Sent: Monday, June 6, 2016 12:43 PM > To: Limonciello, Mario ; > hayesw...@realtek.com > Cc: LKML ; Netdev > ; Linux

Re: [PATCH 9/10] usb: host: ehci-st: Inform the reset framework that our reset line may be shared

On Mon, 6 Jun 2016, Lee Jones wrote: > On the STiH410 B2120 development board the ST EHCI IP shares its reset > line with the OHCI IP. New functionality in the reset subsystems forces > consumers to be explicit when requesting shared/exclusive reset lines. > > Signed-off-by: Lee Jones

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

> -Original Message- > From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb- > ow...@vger.kernel.org] On Behalf Of Mario Limonciello > Sent: Monday, June 06, 2016 12:19 > To: hayesw...@realtek.com > Cc: LKML; Netdev; Linux USB; pali.ro...@gmail.com; > anthony.w...@canonical.com; Greg

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

On Mon, Jun 06, 2016 at 05:24:57PM +, mario_limoncie...@dell.com wrote: > That said, I would be highly surprised if Realtek decided to implement > with another OEM differently. It would increase their code complexity > on Windows as well since this is part of the generic driver. Ah, it's

[balbi-usb:testing/next 64/67] drivers/usb/phy/phy-gpio-vbus-usb.c:200: undefined reference to `usb_gadget_vbus_disconnect'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git testing/next head: 89fe2b5ab11cdf6a67d4492d893e70e330aa7060 commit: 231b31ca34485552fe27e67dc6d30d06079c7648 [64/67] usb: gadget: move gadget API functions to udc-core config: arm-pxa_defconfig (attached as .config)

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

> > Realtek has this in their Windows driver that all OEM's will be taking. > > Another OEM would just need to burn the right information into the SPI at > > manufacturing and expose it to the DSDT. > > Where it the match up for the Realtek bit to corrispond with this > specific ACPI field? If

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

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 addresses. This information for the system's persistent MAC address is burned in when the system HW is built and

[PATCH 8/10] phy: phy-stih407-usb: Inform the reset framework that our reset line may be shared

On the STiH410 B2120 development board the ports on the Generic PHY share their reset lines with each other. New functionality in the reset subsystems forces consumers to be explicit when requesting shared/exclusive reset lines. Signed-off-by: Lee Jones ---

[PATCH 9/10] usb: host: ehci-st: Inform the reset framework that our reset line may be shared

On the STiH410 B2120 development board the ST EHCI IP shares its reset line with the OHCI IP. New functionality in the reset subsystems forces consumers to be explicit when requesting shared/exclusive reset lines. Signed-off-by: Lee Jones --- drivers/usb/host/ehci-st.c |

[PATCH 10/10] usb: host: ohci-st: Inform the reset framework that our reset line may be shared

On the STiH410 B2120 development board the ST EHCI IP shares its reset line with the OHCI IP. New functionality in the reset subsystems forces consumers to be explicit when requesting shared/exclusive reset lines. Signed-off-by: Lee Jones --- drivers/usb/host/ohci-st.c |

Re: Race condition in usbfs / libusb when using reap-after-disconnect

On Mon, 6 Jun 2016, Hans de Goede wrote: > Hi, > > On 06-06-16 16:48, Greg Kroah-Hartman wrote: > > On Mon, Jun 06, 2016 at 01:44:23PM +0200, Hans de Goede wrote: > >> Hi All, > >> > >> While looking at libusb today I ended up looking at the > >> reap-after-disconnect code. > >> > >> What stands

Re: OHCI: NULL or LIST_POISON dereference on ueagle-atm disconnection

> Apparently this bug also prevented scheduling of endpoints which > failed to schedule once in the past. Formerly I was getting only one > > usbatm_submit_urb: urb 0x8807f1568b00 submission failed (-28)! > > from ueagle-atm and now I'm getting regular spam. I think there's good > chance

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

On Mon, Jun 06, 2016 at 02:56:32PM +, mario_limoncie...@dell.com wrote: > > -Original Message- > > From: Greg KH [mailto:gre...@linuxfoundation.org] > > Sent: Monday, June 6, 2016 9:40 AM > > To: Limonciello, Mario > > Cc: hayesw...@realtek.com; LKML

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Mon, Jun 06, 2016 at 04:45:09PM +0300, Heikki Krogerus wrote: > Hi, > > On Fri, Jun 03, 2016 at 10:20:01PM +0200, Pavel Machek wrote: > > On Thu 2016-05-19 15:44:54, Heikki Krogerus wrote: > > > The purpose of this class is to provide unified interface for user > > > space to get the status

[PATCH 3/7] reset: Supply *_shared variant calls when using of_* API

Consumers need to be able to specify whether they are requesting an 'exclusive' or 'shared' reset line no matter which API (of_*, devm_*, etc) they are using. This change allows users of the of_* API in particular to specify that their request is for a 'shared' line. Signed-off-by: Lee Jones

[PATCH 1/7] reset: Reorder inline reset_control_get*() wrappers

We're about to split the current API into two, where consumers will be forced to be explicit when requesting reset lines. The choice will be to either the call the *_exclusive or *_shared variant depending on whether they can actually tolorate not being asserted when that request is made. The

[PATCH 2/7] reset: Ensure drivers are explicit when requesting reset lines

Phasing out generic reset line requests enables us to make some better decisions on when and how to (de)assert said lines. If an 'exclusive' line is requested, we know a device *requires* a reset and that it's preferable to act upon a request right away. However, if a 'shared' reset line is

[PATCH 7/7] usb: dwc3: st: Inform the reset framework that our reset line may be shared

On the STiH410 B2120 development board the MiPHY28lp shares its reset line with the Synopsys DWC3 SuperSpeed (SS) USB 3.0 Dual-Role-Device (DRD). New functionality in the reset subsystems forces consumers to be explicit when requesting shared/exclusive reset lines. Signed-off-by: Lee Jones

[PATCH 4/7] reset: Supply *_shared variant calls when using *_optional APIs

Consumers need to be able to specify whether they are requesting an 'exclusive' or 'shared' reset line no matter which API (of_*, devm_*, etc) they are using. This change allows users of the optional_* API in particular to specify that their request is for a 'shared' line. Signed-off-by: Lee

[PATCH 5/7] reset: TRIVIAL: Add line break at same place for similar APIs

Standardise the way inline functions: devm_reset_control_get_shared_by_index devm_reset_control_get_exclusive_by_index ... are formatted. Signed-off-by: Lee Jones --- include/linux/reset.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH 6/7] phy: miphy28lp: Inform the reset framework that our reset line may be shared

On the STiH410 B2120 development board the MiPHY28lp shares its reset line with the Synopsys DWC3 SuperSpeed (SS) USB 3.0 Dual-Role-Device (DRD). New functionality in the reset subsystems forces consumers to be explicit when requesting shared/exclusive reset lines. Signed-off-by: Lee Jones

[PATCH 0/7] reset: Consumers to explicitly request 'exclusive' or 'shared' lines

Phasing out generic reset line requests enables us to make some better decisions on when and how to (de)assert said lines. If an 'exclusive' line is requested, we know a device *requires* a reset and that it's preferable to act upon a request right away. However, if a 'shared' reset line is

Re: Race condition in usbfs / libusb when using reap-after-disconnect

Hi, On 06-06-16 16:48, Greg Kroah-Hartman wrote: On Mon, Jun 06, 2016 at 01:44:23PM +0200, Hans de Goede wrote: Hi All, While looking at libusb today I ended up looking at the reap-after-disconnect code. What stands out is that libusb expects to be able to reap all outstanding urbs on a

Re: [PATCH v2] usb: dwc3: host: Set the dma_ops for xhci device

Hi, Baolin Wang writes: > On ARM64 platform, it will set 'dummy_dma_ops' for device dma_ops if > it did not call 'arch_setup_dma_ops' at device creation time, that will > cause failure when setting the dma mask for device. > > Thus this patch set the xhci device dma_ops

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

> -Original Message- > From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: Monday, June 6, 2016 9:41 AM > To: Limonciello, Mario > Cc: hayesw...@realtek.com; LKML ; Netdev > ; Linux USB

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

> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Monday, June 6, 2016 9:40 AM > To: Limonciello, Mario > Cc: hayesw...@realtek.com; LKML ; Netdev > ; Linux USB

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

> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Monday, June 6, 2016 9:50 AM > To: Limonciello, Mario > Cc: hayesw...@realtek.com; linux-ker...@vger.kernel.org; > net...@vger.kernel.org; linux-usb@vger.kernel.org;

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

On Mon, Jun 06, 2016 at 02:43:37PM +, mario_limoncie...@dell.com wrote: > > -Original Message- > > From: Greg KH [mailto:gre...@linuxfoundation.org] > > Sent: Monday, June 6, 2016 9:40 AM > > To: Limonciello, Mario > > Cc: hayesw...@realtek.com; LKML

Re: Race condition in usbfs / libusb when using reap-after-disconnect

On Mon, Jun 06, 2016 at 01:44:23PM +0200, Hans de Goede wrote: > Hi All, > > While looking at libusb today I ended up looking at the > reap-after-disconnect code. > > What stands out is that libusb expects to be able to > reap all outstanding urbs on a device on receiving > a POLL_ERR status

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

> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Monday, June 6, 2016 9:40 AM > To: Limonciello, Mario > Cc: hayesw...@realtek.com; LKML ; Netdev > ; Linux USB

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

> + /* returns _AUXMAC_#AABBCCDDEEFF# */ > + status = acpi_evaluate_object(NULL, "\\_SB.AMAC", NULL, ); > + obj = (union acpi_object *)buffer.pointer; > + if (ACPI_SUCCESS(status)) { > + if (obj->type != ACPI_TYPE_BUFFER || > + obj->string.length !=

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Mon, Jun 06, 2016 at 04:45:09PM +0300, Heikki Krogerus wrote: > Hi, > > On Fri, Jun 03, 2016 at 10:20:01PM +0200, Pavel Machek wrote: > > On Thu 2016-05-19 15:44:54, Heikki Krogerus wrote: > > > The purpose of this class is to provide unified interface for user > > > space to get the status

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

On Mon, Jun 06, 2016 at 09:15:21AM -0500, Mario Limonciello wrote: > 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 addresses. > > This information for the

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

On Mon, Jun 06, 2016 at 09:15:20AM -0500, Mario Limonciello wrote: > Since this is a Realtek feature, I feel this shouldn't be moved into a > platform > MAC address lookup. The code should only be run when the correct Realtek > device > is plugged in. > > Changes from v2: > * Only apply to

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

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 addresses. This information for the system's persistent MAC address is burned in when the system HW is built and

[balbi-usb:testing/next 64/67] drivers/usb/chipidea/otg.c:104: undefined reference to `usb_gadget_vbus_disconnect'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git testing/next head: 89fe2b5ab11cdf6a67d4492d893e70e330aa7060 commit: 231b31ca34485552fe27e67dc6d30d06079c7648 [64/67] usb: gadget: move gadget API functions to udc-core config: arm-multi_v5_defconfig (attached as .config)

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

Hi, On Fri, Jun 03, 2016 at 10:20:01PM +0200, Pavel Machek wrote: > On Thu 2016-05-19 15:44:54, Heikki Krogerus wrote: > > The purpose of this class is to provide unified interface for user > > space to get the status and basic information about USB Type-C > > Connectors in the system, control

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Mon, 2016-06-06 at 16:28 +0300, Heikki Krogerus wrote: > I would prefer lower case letters. I don't know the SIDs there are at > them moment, other then Display Port. Do you know them? > > I don't think we can ever guarantee that in every case we will be able > to provide a human readable

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On Fri, Jun 03, 2016 at 11:39:27AM -0700, Guenter Roeck wrote: > On Fri, Jun 03, 2016 at 06:17:46PM +0300, Heikki Krogerus wrote: > [ ... ] > > > > > > > > > > In my test case, this gives me > > > > > /sys/class/type-c/usbc0/ > > > > > usbc0.svid:18d1 > > > > >

Re: [PATCH v5 resend 1/2] ehci-platform: Add support for controllers with multiple reset lines

On Thu, Jun 02, 2016 at 05:14:05PM +0200, Hans de Goede wrote: > From: Reinder de Haan > > At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple > reset lines, the controller will not initialize while the reset for > its companion is still asserted, which

Re: [balbi-usb:testing/next 64/67] phy-generic.c:undefined reference to `usb_gadget_vbus_connect'

Hi, Felipe Balbi writes: > [ Unknown signature status ] > > Hi, > > kbuild test robot writes: >> tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git >> testing/next >> head: 89fe2b5ab11cdf6a67d4492d893e70e330aa7060 >>

Re: [balbi-usb:testing/next 64/67] phy-generic.c:undefined reference to `usb_gadget_vbus_connect'

Hi, kbuild test robot writes: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git > testing/next > head: 89fe2b5ab11cdf6a67d4492d893e70e330aa7060 > commit: 231b31ca34485552fe27e67dc6d30d06079c7648 [64/67] usb: gadget: move > gadget API functions

[balbi-usb:testing/next 64/67] phy-generic.c:undefined reference to `usb_gadget_vbus_connect'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git testing/next head: 89fe2b5ab11cdf6a67d4492d893e70e330aa7060 commit: 231b31ca34485552fe27e67dc6d30d06079c7648 [64/67] usb: gadget: move gadget API functions to udc-core config: x86_64-randconfig-s1-06061834 (attached as

Re: [PATCH v3 1/2] Documentation: bindings: add DT documentation for Rockchip USB2PHY

Am Montag, 6. Juni 2016, 12:27:54 schrieb Mark Rutland: > On Mon, Jun 06, 2016 at 05:20:03PM +0800, Frank Wang wrote: > > Signed-off-by: Frank Wang > > --- > > > > Changes in v3: > > - Added 'clocks' and 'clock-names' optional properties. > > - Specified 'otg-port'

Race condition in usbfs / libusb when using reap-after-disconnect

Hi All, While looking at libusb today I ended up looking at the reap-after-disconnect code. What stands out is that libusb expects to be able to reap all outstanding urbs on a device on receiving a POLL_ERR status from poll (on supported kernels). But the usbfs poll implementation will return

Re: [PATCH v3 1/2] Documentation: bindings: add DT documentation for Rockchip USB2PHY

On Mon, Jun 06, 2016 at 05:20:03PM +0800, Frank Wang wrote: > Signed-off-by: Frank Wang > --- > > Changes in v3: > - Added 'clocks' and 'clock-names' optional properties. > - Specified 'otg-port' and 'host-port' as the sub-node name. > > Changes in v2: > - Changed

[PATCH 1/1] USB: serial: option: add support for Telit LE910 PID 0x1206

This patch adds support for 0x1206 PID of Telit LE910. Since the interfaces positions are the same than the ones for 0x1043 PID of Telit LE922, telit_le922_blacklist_usbcfg3 is used. Signed-off-by: Daniele Palmas --- drivers/usb/serial/option.c | 3 +++ 1 file changed, 3

[PATCH 0/1] USB: serial: option: add support for Telit LE910 PID 0x1206

This patch adds support for PID 0x1206 of Telit LE910. The reserved usb interfaces belong to an adb device and an ECM device. Since the interfaces positions are the same than the ones for 0x1043 PID of Telit LE922, telit_le922_blacklist_usbcfg3 is used. Following the lsusb output: Bus 001

[PATCH v3 1/2] Documentation: bindings: add DT documentation for Rockchip USB2PHY

Signed-off-by: Frank Wang --- Changes in v3: - Added 'clocks' and 'clock-names' optional properties. - Specified 'otg-port' and 'host-port' as the sub-node name. Changes in v2: - Changed vbus_host optional property from gpio to regulator. - Specified

[PATCH v3 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

The newer SoCs (rk3366, rk3399) take a different usb-phy IP block than rk3288 and before, and most of phy-related registers are also different from the past, so a new phy driver is required necessarily. Signed-off-by: Frank Wang --- Changes in v3: - Resolved the

[PATCH v3 0/2] Add a new Rockchip usb2 phy driver

The newer SoCs (rk3366, rk3399) of Rock-chip take a different usb-phy IP block than rk3288 and before, and most of phy-related registers are also different from the past, so a new phy driver is required necessarily. These series patches add phy-rockchip-inno-usb2.c and the corresponding

Re: [PATCH] usb: usbip: fix null pointer dereference

On Mon, Jun 06, 2016 at 10:20:37AM +0200, Krzysztof Opasiak wrote: > > > On 06/05/2016 07:54 PM, Sudip Mukherjee wrote: > > > > Yes, I should have seen earlier that the only caller has already > > dereferenced udc. So maybe the following will be appropriate in this > > situation. > > > > Your

Re: OHCI: NULL or LIST_POISON dereference on ueagle-atm disconnection

> Try moving the first executable line: > > ed->state = ED_OPER; > > to the end of the routine, just before the "return 0;". That should > fix the problem. Yep, this does the trick. I removed my NULL-check before list_del and nothing bad happens anymore. Apparently this bug also

Re: [PATCH] usb: usbip: fix null pointer dereference

On 06/05/2016 07:54 PM, Sudip Mukherjee wrote: > On Friday 03 June 2016 09:29 AM, Krzysztof Opasiak wrote: >> >> >> On 06/02/2016 03:22 PM, Sudip Mukherjee wrote: >>> We have been dereferencing udc before checking it. Lets use it after it >>> has been checked. >>> >> >> To be honest I have mixed

Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

Hi Peter, On 06/06/2016 03:02 PM, Peter Chen wrote: > >> But this code is better co-work with OTG/Dual-role framework, we'd > >> better have only interface that the user can know which role for the > >> current port. > >> OTG/Dual-role framework and portmux framework are not

Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

On Mon, Jun 06, 2016 at 11:04:48AM +0800, Lu Baolu wrote: > Hi Peter, > > On 06/06/2016 09:25 AM, Peter Chen wrote: > > On Sun, Jun 05, 2016 at 02:55:56PM +0800, Lu Baolu wrote: > >> Hi Peter, > >> > >> On 06/04/2016 10:28 AM, Peter Chen wrote: > >>> On Sat, Jun 04, 2016 at 12:06:06AM +0800, Lu

Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

Hi, On 06/06/16 06:04, Lu Baolu wrote: > Hi Peter, > > On 06/06/2016 09:25 AM, Peter Chen wrote: >> On Sun, Jun 05, 2016 at 02:55:56PM +0800, Lu Baolu wrote: >>> Hi Peter, >>> >>> On 06/04/2016 10:28 AM, Peter Chen wrote: On Sat, Jun 04, 2016 at 12:06:06AM +0800, Lu Baolu wrote: >> from

Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

On Mon, Jun 06, 2016 at 10:45:34AM +0800, Lu Baolu wrote: > Hi Peter, > > On 06/06/2016 10:05 AM, Peter Chen wrote: > > On Sun, Jun 05, 2016 at 04:46:55PM +0800, Lu Baolu wrote: > >> Hi, > >> > >> On 06/05/2016 04:33 PM, Jun Li wrote: > Port mux is part of dual role switch, but not the whole