Re: [PATCH] option: Add support for Quectel EP06

On Tue, Jan 30, 2018 at 03:06:38PM +0100, Kristian Evensen wrote: > The Quectel EP06 is a Cat. 6 LTE modem, and the interface mapping is as > follows: > > 0: Diag > 1: NMEA > 2: AT > 3: Modem > > Interface 4 is QMI and interface 5 is ADB, so they are blacklisted. > > Signed-off-by: Kristian

Re: [PATCH] usb: gadget: core: Fix use-after-free of usb_request

Hi Felipe, On 12/21/2017 9:54 AM, Manu Gautam wrote: > Driver is tracing usb_request after freeing it. > Fix it by changing the order. Let me know if following change looks ok? > > Signed-off-by: Manu Gautam > --- > drivers/usb/gadget/udc/core.c | 2 +- > 1 file

Re: [PATCH v5 00/17] Support for Qualcomm QUSBv2 and QMPv3 USB PHYs

Hi Kishon, On 1/16/2018 4:26 PM, Manu Gautam wrote: > QUSB-v2 and QMP-v3 USB PHYs are present on Qualcomm's 14nm > and 10nm SOCs. > This patch series adds support for runtime PM for these > USB PHYs and adds fixes in drivers to follow PHY reset and > initialization sequence as per hardware

Re: [PATCH] USB TYPEC: RT1711H Type-C Chip Driver

On Tue, Jan 30, 2018 at 01:21:01PM +, shufan_lee(李書帆) wrote: > Hi Guenter, > > For now, it looks like there are two ways to implement vendor data. It > would be nice to hear your suggestion. > > 1. Set vendor data in the data field of of_device_id. > If I understand correctly, this

Re: [Bug 197863] Thinkpad X240 resume dramatically slower on kernels 4.13+

Hi Oliver, On Tue, Jan 30, 2018 at 08:45:17AM +0100, Oliver Neukum wrote: > Am Montag, den 29.01.2018, 19:21 +0100 schrieb Markus Demleitner: > > > > Any guess what might be behind this? > > > have you checked the persist attribute between the versions working > well and working badly? Persist

Re: [RFC usb-next v8 1/3] dt-bindings: usb: add the documentation for USB HCDs

On Thu, Jan 25, 2018 at 01:00:51AM +0100, Martin Blumenstingl wrote: > A USB HCD may have several PHYs which need to be configured before the > the HCD starts working. > This adds the documentation for such a USB HCD as well as a reference to > the new "usb-hcd.txt" from all bindings that

Re: [resend] Questions about "usb usb8-port1: cannot disable (err = -32)"

On Tue, 30 Jan 2018, Mathias Nyman wrote: > On 26.01.2018 03:47, Yoshihiro Shimoda wrote: > > I resent this email with adding Mathias, Alan and Greg as CC. > > > > -Original Message- > > From: Yoshihiro Shimoda, Sent: Thursday, January 18, 2018 6:03 PM > > To: linux-usb@vger.kernel.org >

Re: [resend] Questions about "usb usb8-port1: cannot disable (err = -32)"

On 26.01.2018 03:47, Yoshihiro Shimoda wrote: I resent this email with adding Mathias, Alan and Greg as CC. -Original Message- From: Yoshihiro Shimoda, Sent: Thursday, January 18, 2018 6:03 PM To: linux-usb@vger.kernel.org Subject: Questions about "usb usb8-port1: cannot disable (err =

Re: [PATCH v4 0/7] typec: tcpm: Add sink side support for PPS

On 01/30/2018 05:25 AM, Heikki Krogerus wrote: On Tue, Jan 02, 2018 at 03:50:48PM +, Adam Thomson wrote: This patch set adds sink side support for the PPS feature introduced in the USB PD 3.0 specification. The source PPS supply is represented using the Power Supply framework to provide

[PATCH] option: Add support for Quectel EP06

The Quectel EP06 is a Cat. 6 LTE modem, and the interface mapping is as follows: 0: Diag 1: NMEA 2: AT 3: Modem Interface 4 is QMI and interface 5 is ADB, so they are blacklisted. Signed-off-by: Kristian Evensen --- drivers/usb/serial/option.c | 7 +++ 1 file

Re: [PATCH v4 0/7] typec: tcpm: Add sink side support for PPS

On Tue, Jan 02, 2018 at 03:50:48PM +, Adam Thomson wrote: > This patch set adds sink side support for the PPS feature introduced in the > USB PD 3.0 specification. > > The source PPS supply is represented using the Power Supply framework to > provide > access and control APIs for dealing

RE: [PATCH] USB TYPEC: RT1711H Type-C Chip Driver

Hi Guenter, For now, it looks like there are two ways to implement vendor data. It would be nice to hear your suggestion. 1. Set vendor data in the data field of of_device_id. If I understand correctly, this would be the one more like you mentioned before. In this case, tcpci_rt1711h_data

Re: [PATCH v4 7/7] typec: tcpm: Add support for sink PPS related messages

On Tue, Jan 02, 2018 at 03:50:55PM +, Adam Thomson wrote: > This commit adds sink side support for Get_Status, Status, > Get_PPS_Status and PPS_Status handling. As there's the > potential for a partner to respond with Not_Supported > handling of this message is also added. Sending of >

Re: [PATCH v4 6/7] typec: tcpm: Represent source supply through power_supply class

Hi Adam, On Tue, Jan 02, 2018 at 03:50:54PM +, Adam Thomson wrote: > This commit adds a power_supply class instance to represent a > PD source's voltage and current properties. This provides an > interface for reading these properties from user-space or other > drivers. > > For PPS enabled

Re: [PATCH v4 5/7] power: supply: Add 'connected_type' property and supporting code

On Tue, Jan 02, 2018 at 03:50:53PM +, Adam Thomson wrote: > This commit adds the 'connected_type' property to represent supplies > which can report a number of different types of supply based on a > connection event. > > Examples of this already exist in drivers whereby the existing 'type' >

Re: [PATCH v4 4/7] typec: tcpm: Add core support for sink side PPS

On Tue, Jan 02, 2018 at 03:50:52PM +, Adam Thomson wrote: > This commit adds code to handle requesting of PPS APDOs. Switching > between standard PDOs and APDOs, and re-requesting an APDO to > modify operating voltage/current will be triggered by an > external call into TCPM. > >

Re: [PATCH v4 3/7] typec: tcpm: Add SDB header for Status message handling

On Tue, Jan 02, 2018 at 03:50:51PM +, Adam Thomson wrote: > This commit adds a header providing definitions for handling > Status messages. Currently the header only focuses on handling > incoming Status messages. > > Signed-off-by: Adam Thomson

Re: [PATCH v4 2/7] typec: tcpm: Add ADO header for Alert message handling

On Tue, Jan 02, 2018 at 03:50:50PM +, Adam Thomson wrote: > This commit adds a header providing definitions for handling Alert > messages. Currently the header only focuses on handling incoming > alerts. > > Signed-off-by: Adam Thomson Acked-by: Heikki

Re: [PATCH v4 1/7] typec: tcpm: Add PD Rev 3.0 definitions to PD header

On Tue, Jan 02, 2018 at 03:50:49PM +, Adam Thomson wrote: > This commit adds definitions for PD Rev 3.0 messages, including > APDO PPS and extended message support for TCPM. > > Signed-off-by: Adam Thomson Just one nitpick. I noticed that you are

Re: [PATCH 1/4] dt-bindings: dwc3: add binding documentation for UniPhier dwc3 glue driver

Hi Rob, Thank you for your comments. On Mon, 29 Jan 2018 18:06:53 -0600 wrote: > On Tue, Jan 23, 2018 at 10:00:51PM +0900, Kunihiko Hayashi wrote: > > Add devicetree binding documentation for dwc3 glue driver implemented > > on Socionext UniPhier SoCs. > > > > Signed-off-by:

[PATCH 3/4] usbip tools: use per vhci_hcd controller attributes

From: Salvador Fandiño Now every vhci_hcd device is controlled by its own sysfs attributes (before all of them were controlled by vhci_hcd.0 attributes). This patch addapts the usbip tools to use the new interface through libusbip. The user visible changes are as follows: -

[PATCH 1/4] usbip: make vhci_hcd.* objects independent of vhci_hcd.0

From: Salvador Fandiño The usbip VHCI layer supports multiple "vhci_hcd" devices, every one emulating both a high speed and a super speed USB hub. These devices are exposed in sysfs as "vhci_hcd.0", "vhci_hcd.1", etc. But instead of controlling then by attributes inside their

[PATH 0/4] usbip: make vhci_hcd.* objects independent of vhci_hcd.0

Let me start by explaining the problem that have motivated me to write this patches: I work on the QVD, a virtual desktop platform for Linux. This software runs Linux desktops (i.e. XFCE, KDE) and their applications inside LXC containers, and makes then available through the network to remote

[PATCH 4/4] config: make USB_MAXBUS configurable and adjust VHCI_NR_HCS top limit

From: Salvador Fandiño The maximum number of USB host controllers supported by the kernel had a hard-coded limit of 64. In some scenarios that limit may be not enough. For instance, in my particular case, I have systems with thousands of containers running and would like to

[PATCH 2/4] libusbip: use per vhci_hcd controller attributes

From: Salvador Fandiño Now every vhci_hcd device is controlled by its own sysfs attributes (before all of them were controlled by vhci_hcd.0 attributes). This patch addapts libusbip to this new interface. Before this patch the library did not provide any mean to access a

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

Am Montag, den 29.01.2018, 14:48 +0100 schrieb Menion: > As soon as more than one HD in inserted in the enclosure, when > parallel write operation are send to the HDs, you start to get > immediately CMD error on UAS driver, after a while the USB gets in an > inconsistent status and you are forced

Re: [PATCH v2] usbip: fix protocol documentation

I think I should have send it to Jonathan instead of Valentina, and to linux-doc instead of linux-usb. Alexandre Demers On 2018-01-28 02:15, Alexandre Demers wrote: > While reading the document, I found what seems to be 4 mistakes: > - 1 clarification: it seems more logical to say that the

usbip: was there any follow up to the "usbip: Crypto and ACLs" series?

Hi, I'm writting to both you because you were the last to exchange about the "usbip: Crypto and ACLs" found at https://lkml.org/lkml/2014/9/16/611. Maximilian Eschenbacher last said on November 11th 2014 that he was to resubmit a new series in the next few days, but I can't seem to find it. What

Paired bluetooth keyboards lead to system auto resume from S3 when WoL enabled for e1000e

Hi, This is actually a continuation of [1] with more findings. The machine in question is a CFL desktop. The auto resume roughly happens in 5 ~ 10 mins. After further digging, I found out that the e1000e and XHCI always shares the same wakeup count in /sys/kernel/debug/wakeup_sources, so I did