inconsistent lock state with usbnet/asix usb ethernet and xhci

Hi I've noticed that USBnet/ASIX AX88772B USB driver produces deplock kernel warning ("inconsistent lock state") on Chromebook2 Peach-PIT board. No special activity is needed to reproduce this issue, it happens almost on every boot. ASIX USB ethernet is connected to XHCI USB host controller on

[PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

These bindings allow to describe most known standard USB connectors and it should be possible to extend it if necessary. USB connectors, beside USB can be used to route other protocols, for example UART, Audio, MHL. In such case every device passing data through the connector should have

[PATCH v5 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

OF graph describes MHL data lanes between MHL and respective USB connector. Signed-off-by: Andrzej Hajda --- v5: removed extra parenthesis (kbuild test robot) v4: added missing reg property in connector's port node (Krzysztof) ---

[PATCH v5 5/6] extcon: add possibility to get extcon device by OF node

Since extcon property is not allowed in DT, extcon subsystem requires another way to get extcon device. Lets try the simplest approach - get edev by of_node. Signed-off-by: Andrzej Hajda Acked-by: Chanwoo Choi --- v5: function renamed to

[PATCH v5 6/6] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

From: Maciej Purski Currently MHL chip must be turned on permanently to detect MHL cable. It duplicates micro-USB controller's (MUIC) functionality and consumes unnecessary power. Lets use extcon attached to MUIC to enable MHL chip only if it detects MHL cable.

[PATCH v5 0/6] dt-bindings: add bindings for USB physical connector

Hi, Thanks for reviews of previous iterations. This patchset introduces USB physical connector bindings, together with working example. I have removed RFC prefix - the patchset seems to be heading to a happy end :) v5: fixed extra parenthesis in dts, renamed extcon function. v4: improved

[PATCH v5 2/6] dt-bindings: add bindings for Samsung micro-USB 11-pin connector

Samsung micro-USB 11-pin connector beside standard micro-USB pins, has pins dedicated to route MHL traffic. Signed-off-by: Andrzej Hajda Reviewed-by: Rob Herring --- v4: - removed description of property inherited from usb-connector (Rob), - fixed example

[PATCH v5 3/6] arm64: dts: exynos: add micro-USB connector node to TM2 platforms

Since USB connector bindings are available we can describe it on TM2(e). Signed-off-by: Andrzej Hajda --- arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi

Re: [PATCH v4 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

On 26.02.2018 16:21, Krzysztof Kozlowski wrote: > On Wed, Feb 21, 2018 at 9:55 AM, Andrzej Hajda wrote: >> OF graph describes MHL data lanes between MHL and respective USB >> connector. >> >> Signed-off-by: Andrzej Hajda >> --- >> v4: >> - added missing

Re: [PATCH 1/2] usb: gadget: udc: Use scnprintf() instead of snprintf()

This is one patch file not series. Sorry for the patch numbering mistake. Thanks jaejoong 2018-02-27 11:04 GMT+09:00 Jaejoong Kim : > The show() method should use scnprintf() not snprintf() because snprintf() > may returns a value that exceeds its second argument. > >

[PATCH 1/2] usb: gadget: udc: Use scnprintf() instead of snprintf()

The show() method should use scnprintf() not snprintf() because snprintf() may returns a value that exceeds its second argument. Signed-off-by: Jaejoong Kim --- drivers/usb/gadget/udc/core.c | 4 ++-- drivers/usb/gadget/udc/dummy_hcd.c | 2 +- 2 files changed, 3

Re: [RFC PATCH] drivers: use 'depends on MFD_SYSCON' instead of 'select MFD_SYSCON'

2018-02-26 21:43 GMT+09:00 Arnd Bergmann : > On Mon, Feb 26, 2018 at 12:53 PM, Masahiro Yamada > wrote: >> 2018-02-26 17:43 GMT+09:00 Arnd Bergmann : >>> On Sat, Feb 24, 2018 at 3:50 PM, Masahiro Yamada >>>

[PATCH 2/3] console: Fill in struct consw argument names

Reading the function declarations for the console callbacks lacks any hints as to what the arguments are. Instead of going and digging around in various implementations that may each only have a subset of the callbacks, name all the arguments in the declaration. This has no functional change.

[PATCH 0/3] console: Expand dummy functions for CFI

This is a small series that cleans up struct consw a bit and prepares it for Control Flow Integrity checking (i.e. Clang's -fsanitize=cfi). Thanks! -Kees -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo

[PATCH 1/3] console: SisUSB2VGA: Drop dummy con_font_get()

As done in commit: 724ba8b30b04 ("console/dummy: leave .con_font_get set to NULL") This drops the dummy .con_font_get(), as it could leave arguments uninitialized. Cc: Thomas Winischhofer Signed-off-by: Kees Cook ---

[PATCH 3/3] console: Expand dummy functions for CFI

This expands the no-op dummy functions into full prototypes to avoid indirect call mismatches when running under Control Flow Integrity checking, like with Clang's -fsanitize=cfi. Co-Developed-by: Sami Tolvanen Signed-off-by: Sami Tolvanen

Re: [PATCH v3] usb: core: Add "quirks" parameter for usbcore

Hi Kai-Heng, Thank you for the patch! Yet something to improve: [auto build test ERROR on usb/usb-testing] [also build test ERROR on v4.16-rc3 next-20180226] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci

[PATCH 3.16] staging: usbip stub_rx fix static checker warning on unnecessary checks

Upstream commit 10c901209306 ("usbip: stub_rx: fix static checker warning on unnecessary checks") Back-port fix for static checker warning on unnecessary checks smatch warnings: drivers/staging/usbip/stub_rx.c:360 get_pipe() warn: impossible condition '(pdu->u.cmd_submit.transfer_buffer_length >

Re: [PATCH v1 1/1] drivers/usb/storage: NULL pointer dereference [null-pointer-deref] (CWE 476) problem

On Mon, Feb 26, 2018 at 02:08:08PM -0500, Joe Moriarty wrote: > On 2/26/2018 1:12 PM, Greg KH wrote: > > On Mon, Feb 26, 2018 at 12:10:02PM -0500, Joe Moriarty wrote: > > > The Parfait (version 2.1.0) static code analysis tool found the > > > following NULL pointer dereference problem. > > > >

Re: [PATCH v4 01/12] drivers: base: Unified device connection lookup

On 02/26/2018 10:39 AM, Hans de Goede wrote: > diff --git a/include/linux/connection.h b/include/linux/connection.h > new file mode 100644 > index ..0b4430eae53a > --- /dev/null > +++ b/include/linux/connection.h > @@ -0,0 +1,33 @@ > +// SPDX-License-Identifier: GPL-2.0 > + > +#ifndef

Re: [PATCH v1 0/1] Parfait changes

On 2/26/2018 1:12 PM, Greg KH wrote: On Mon, Feb 26, 2018 at 12:10:01PM -0500, Joe Moriarty wrote: The following patch(s) are bugs found by the static compiler 'Parfait'. Care was taken to make sure false positive results were removed from this patchset. This is not a "patchset", it is only

Re: [PATCH v1 1/1] drivers/usb/storage: NULL pointer dereference [null-pointer-deref] (CWE 476) problem

On 2/26/2018 1:12 PM, Greg KH wrote: On Mon, Feb 26, 2018 at 12:10:02PM -0500, Joe Moriarty wrote: The Parfait (version 2.1.0) static code analysis tool found the following NULL pointer dereference problem. What is the "CWE 476" thing in the subject line for? [JDM] (CWE 476) stands for

[PATCH v4 00/12] USB Type-C device-connection, mux and switch support

Hi All, Here is version 4 of Heikki's and my USB Type-C device-connection, mux and switch support series. Version 2, 3 and 4 bring various small code and style fixes based on review (no major changes). Here is the original cover-letter of v1: Some devices with an USB Type-C connector have a

[PATCH v4 02/12] usb: typec: Start using ERR_PTR

From: Heikki Krogerus In order to allow the USB Type-C Class driver take care of things like muxes and other possible dependencies for the port drivers, returning ERR_PTR instead of NULL from the registration functions in case of failure. The reason for taking

[PATCH v4 01/12] drivers: base: Unified device connection lookup

From: Heikki Krogerus Several frameworks - clk, gpio, phy, pmw, etc. - maintain lookup tables for describing connections and provide custom API for handling them. This introduces a single generic lookup table and API for the connections. The motivation for this

[PATCH v4 05/12] usb: typec: tcpm: Set USB role switch to device mode when configured as such

Setting the mux to MUX_NONE and the switch to USB_SWITCH_DISCONNECT when the data-role is device is not correct. Plenty of devices support operating as USB device through a (separate) USB device controller. We really need 2 different versions of USB_SWITCH_CONNECT, USB_SWITCH_CONNECT_HOST and

[PATCH v4 03/12] usb: typec: API for controlling USB Type-C Multiplexers

From: Heikki Krogerus USB Type-C connectors consist of various muxes and switches that route the pins on the connector to the right locations. The USB Type-C drivers need to be able to control the muxes, as they are the ones that know things like the cable plug

[PATCH v4 04/12] usb: common: Small class for USB role switches

From: Heikki Krogerus USB role switch is a device that can be used to choose the data role for USB connector. With dual-role capable USB controllers, the controller itself will be the switch, but on some platforms the USB host and device controllers are separate

[PATCH v4 06/12] usb: typec: tcpm: Use new Type-C switch/mux and usb-role-switch functions

Remove the unused (not implemented anywhere) tcpc_mux_dev abstraction and replace it with calling the new typec_set_orientation, usb_role_switch_set and typec_set_mode functions. Reviewed-by: Heikki Krogerus Reviewed-by: Guenter Roeck

[PATCH v4 08/12] xhci: Add Intel extended cap / otg phy mux handling

The xHCI controller on various Intel SoCs has an extended cap mmio-range which contains registers to control the muxing to the xHCI (host mode) or the dwc3 (device mode) and vbus-detection for the otg usb-phy. Having a role-sw driver included in the xHCI code (under drivers/usb/host) is not

[PATCH v4 09/12] usb: roles: Add Intel xHCI USB role switch driver

Various Intel SoCs (Cherry Trail, Broxton and others) have an internal USB role switch for swiching the OTG USB data lines between the xHCI host controller and the dwc3 gadget controller. Note on some Cherry Trail systems there is ACPI/AML code listening to edge interrupts on the id-pin (through

[PATCH v4 07/12] xhci: Add option to get next extended capability in list by passing id = 0

From: Mathias Nyman Modify xhci_find_next_ext_cap(base, offset, id) to return the next capability offset if 0 is passed for id. Otherwise it will behave as previously and return the offset of the next capability with matching id capability id 0 is not used by xHCI

[PATCH v4 10/12] usb: typec: driver for Pericom PI3USB30532 Type-C cross switch

Add a driver for the Pericom PI3USB30532 Type-C cross switch / mux chip found on some devices with a Type-C port. Reviewed-by: Heikki Krogerus Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede --- Changes

[PATCH v4 11/12] platform/x86: intel_cht_int33fe: Add device connections for the Type-C port

We need to add device-connections for the Type-C mux/switch and usb-role code to be able to find the PI3USB30532 Type-C cross-switch and the device/host role-switch integrated in the CHT SoC. Reviewed-by: Heikki Krogerus Reviewed-by: Andy Shevchenko

[PATCH v4 12/12] extcon: axp288: Set USB role where necessary

The AXP288 BC1.2 charger detection / extcon code may seem like a strange place to add code to control the USB role-switch on devices with an AXP288, but there are 2 reasons to do this inside the axp288 extcon code: 1) On many devices the USB role is controlled by ACPI AML code, but the AML

Re: Wakeup from USB on i.MX6S

Hi Peter, thank you a lot for your answere. This problem gives me headache for about 2 weeks now. I have to admit that I'm not very experienced in working with embedded devices and it took me about one day to find ways to answere your questions. :) I hope I've answered them. If not, please let

Re: [PATCH v1 1/1] drivers/usb/storage: NULL pointer dereference [null-pointer-deref] (CWE 476) problem

On Mon, Feb 26, 2018 at 12:10:02PM -0500, Joe Moriarty wrote: > The Parfait (version 2.1.0) static code analysis tool found the > following NULL pointer dereference problem. What is the "CWE 476" thing in the subject line for? > > dev_to_shost() in include/scsi/scsi_host.h has the ability to

Re: [PATCH v1 0/1] Parfait changes

On Mon, Feb 26, 2018 at 12:10:01PM -0500, Joe Moriarty wrote: > The following patch(s) are bugs found by the static compiler > 'Parfait'. Care was taken to make sure false positive results > were removed from this patchset. This is not a "patchset", it is only 1 patch. -- To unsubscribe from

Re: [PATCH 1/2] [USB]/[misc]: Add waiting in transfer abortion

Hi Oliver, Unfortunately I have only ADU-208 USB/relay interface (adutux driver) for testing. At a glance, the following drivers have the pause in the same way on 'release' procedure, so they must work fine: legousbtower ldusb sisusbvga Driver iowarrior doesn't have a pause before freeing

Re: [PATCH] usb: musb: call pm_runtime_{get,put}_sync before reading vbus registers

On Mon, Feb 26, 2018 at 06:19:30PM +0100, Merlijn Wajer wrote: > Hi, > > On 26/02/18 16:57, Bin Liu wrote: > > Hi, > > > > On Mon, Feb 26, 2018 at 11:56:08AM +0100, Merlijn Wajer wrote: > >> Without pm_runtime_{get,put}_sync calls in place, reading > >> vbus status via /sys causes the following

Re: [PATCH] usb: musb: call pm_runtime_{get,put}_sync before reading vbus registers

Hi, On 26/02/18 16:57, Bin Liu wrote: > Hi, > > On Mon, Feb 26, 2018 at 11:56:08AM +0100, Merlijn Wajer wrote: >> Without pm_runtime_{get,put}_sync calls in place, reading >> vbus status via /sys causes the following error: >> >> Unhandled fault: external abort on non-linefetch (0x1028) at

[PATCH v1 1/1] drivers/usb/storage: NULL pointer dereference [null-pointer-deref] (CWE 476) problem

The Parfait (version 2.1.0) static code analysis tool found the following NULL pointer dereference problem. dev_to_shost() in include/scsi/scsi_host.h has the ability to return NULL if the scsi host device does not have the Scsi_host->parent field set. With the possibilty of a NULL pointer being

[PATCH v1 0/1] Parfait changes

The following patch(s) are bugs found by the static compiler 'Parfait'. Care was taken to make sure false positive results were removed from this patchset. Parfait Overview https://labs.oracle.com/pls/apex/f?p=labs:49:P49_PROJECT_ID:13 v1: Initial release Joe Moriarty

Re: [PATCH] usbip: vudc: fix null pointer dereference on udc->lock

On 02/22/2018 10:39 AM, Colin King wrote: > From: Colin Ian King > > Currently the driver attempts to spin lock on udc->lock before a NULL > pointer check is performed on udc, hence there is a potential null > pointer dereference on udc->lock. Fix this by moving the

Re: Q: Does mass storage gadget use DMA ?

On Mon, Feb 26, 2018 at 5:59 PM, Oliver Neukum wrote: > Am Donnerstag, den 15.02.2018, 11:00 +0200 schrieb Ran Shalit: >> I actually asked about DMA, because I see that it is possible to send >> urb using DMA allocated buffers or not (coherent and non-coherent) >>

Re: usb transfer length

Am Montag, den 26.02.2018, 16:41 +0200 schrieb Ran Shalit: > Hello, > > When performing usb transfer we request for maximum size of transfer, > yet another size of message (shorter or longer) might be sent from > device to host. > > Are both cases (shorter/longer) legal in usb standard ? No.

Re: Q: Does mass storage gadget use DMA ?

Am Donnerstag, den 15.02.2018, 11:00 +0200 schrieb Ran Shalit: > I actually asked about DMA, because I see that it is possible to send > urb using DMA allocated buffers or not (coherent and non-coherent) > usb_buffer_alloc(). > So, How can we actually know if I should use this API with a device or

Re: [PATCH] usb: musb: call pm_runtime_{get,put}_sync before reading vbus registers

Hi, On Mon, Feb 26, 2018 at 11:56:08AM +0100, Merlijn Wajer wrote: > Without pm_runtime_{get,put}_sync calls in place, reading > vbus status via /sys causes the following error: > > Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0ab060 > pgd = b333e822 > [fa0ab060]

Re: [PATCH v4 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

On Wed, Feb 21, 2018 at 9:55 AM, Andrzej Hajda wrote: > OF graph describes MHL data lanes between MHL and respective USB > connector. > > Signed-off-by: Andrzej Hajda > --- > v4: > - added missing reg property in connector's port node (Krzysztof) > --- >

[PATCH v4] usb: core: Add "quirks" parameter for usbcore

Trying quirks in usbcore needs to rebuild the driver or the entire kernel if it's builtin. It can save a lot of time if usbcore has similar ability like "usbhid.quirks=" and "usb-storage.quirks=". Rename the original quirk detection function to "static" as we introduce this new "dynamic"

Re: [PATCH 2/4] usb: dwc3: add dwc3 glue layer for UniPhier SoCs

Hi Felipe, 2018-01-24 21:58 GMT+09:00 Felipe Balbi : > > Hi, > > Kunihiko Hayashi writes: >> Hello Felipe, >> >> Thank you for your comments. >> >> On Tue, 23 Jan 2018 15:12:36 +0200 wrote: >> >>> >>> Hi, >>> >>> Kunihiko

usb transfer length

Hello, When performing usb transfer we request for maximum size of transfer, yet another size of message (shorter or longer) might be sent from device to host. Are both cases (shorter/longer) legal in usb standard ? In case both are legal: If it is shorter, I guess there is no issue at all. If

RE: [PATCH v2 03/12] staging: typec: tcpci: support port config passed via dt

Hi > -Original Message- > From: linux-usb-ow...@vger.kernel.org > [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Heikki Krogerus > Sent: 2018年2月26日 22:06 > To: Jun Li > Cc: gre...@linuxfoundation.org; robh...@kernel.org; li...@roeck-us.net; > a.ha...@samsung.com;

Re: Fwd: Re: Bug 198731 "USB devices not seen with newest kernel"

Am Dienstag, den 13.02.2018, 13:56 -0800 schrieb The Real Bev: > I went back to the distribution kernel for 64-bit 14.2 slackware -- > 4.14.18. During boot, dmesg displays the following errors: > > [   15.850711] xhci_hcd :09:00.0: not ready 4195ms after FLR; waiting > [   20.458401] xhci_hcd

Re: [PATCH v2 03/12] staging: typec: tcpci: support port config passed via dt

Hi, On Mon, Feb 26, 2018 at 07:49:10PM +0800, Li Jun wrote: > User can define the typec port properties in tcpci node to setup > the port config. > > Signed-off-by: Li Jun > --- > Changes for v2: > - Use infra APIs to get sink and source config. > - Improve the error message. >

Re: [PATCH v2 02/12] usb: typec: add API to get sink and source config

Hi, On Mon, Feb 26, 2018 at 07:49:09PM +0800, Li Jun wrote: > This patch add 2 APIs to get sink and source power config from firmware > description. > > Signed-off-by: Li Jun > --- > drivers/usb/typec/tcpm.c | 43 +++ >

Re: [PATCH v2 01/12] usb: typec: add API to get port type and preferred role

On Mon, Feb 26, 2018 at 07:49:08PM +0800, Li Jun wrote: > This patch add 2 APIs to get port type and preferred role from firmware > description. > > Signed-off-by: Li Jun > > --- > change for v2 > - Change the 2 APIs name and input para to be device_node pointer. Why? You are

Re: [RFC PATCH] drivers: use 'depends on MFD_SYSCON' instead of 'select MFD_SYSCON'

On Mon, Feb 26, 2018 at 12:53 PM, Masahiro Yamada wrote: > 2018-02-26 17:43 GMT+09:00 Arnd Bergmann : >> On Sat, Feb 24, 2018 at 3:50 PM, Masahiro Yamada >> wrote: >>> As Documentation/kbuild/kconfig-language.txt notes,

Re: [PATCH 1/2] [USB]/[misc]: Add waiting in transfer abortion

Am Samstag, den 17.02.2018, 23:01 +0200 schrieb kirill.kirillovich.kapra...@gmail.com: > From: Kirill Kapranov > > Add waiting for an URB transmit finish that let the last URB to be sent > (to be not discarded) during 'release' procedure. W/o this

[PATCH v2 10/12] dt-bindings: connector: add properties for typec power delivery

In case of usb-c-connector with power delivery support, add bingdings supported by current typec driver, so user can pass all those properties via dt. Signed-off-by: Li Jun --- Changes for v2: - Added typec properties are based on general usb connector bindings[1] proposed by

[PATCH v2 07/12] staging: typec: tcpci: correct drp toggling

Per tcpci spec 4.4.5.2 ROLE_CONTROL description: "the TCPM shall write B6 (DRP) =1b and the starting value of Rp/Rd to B3..0 (CC1/CC2) to indicate DRP autonomous toggling mode to the TCPC", so add CC1/CC2 setting, also we should issue COMMAND.Look4Connection to start it. Signed-off-by: Li Jun

[PATCH v2 12/12] staging: typec: tcpci: move tcpci driver out of staging

Move TCPCI(Typec port controller interface) driver out of staging. Signed-off-by: Li Jun --- drivers/staging/Kconfig| 2 -- drivers/staging/Makefile | 1 - drivers/staging/typec/Kconfig | 14 -- drivers/staging/typec/Makefile

[PATCH v2 11/12] dt-bindings: usb: add documentation for typec port controller(TCPCI)

TCPCI stands for typec port controller interface, its implementation has full typec port control with power delivery support, it's a standard i2c slave with GPIO input as irq interface, detail see spec "Universal Serial Bus Type-C Port Controller Interface Specification Revision 1.0, Version 1.1"

[PATCH v2 09/12] staging: typec: tcpci: Only touch target bit when enable vconn

We need regmap_update_bits to avoid touch any other bits when enable or disable vconn. Signed-off-by: Li Jun --- drivers/staging/typec/tcpci.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/staging/typec/tcpci.c

[PATCH v2 08/12] staging: typec: tcpci: keep the uncontact cc line open

While set polarity, we should keep the disconnected cc line to be open when attached. Signed-off-by: Li Jun --- Change for v2: - Set the uncontact cc line to be open when set polarity, this way, we don't need change set_cc api. drivers/staging/typec/tcpci.c | 15

[PATCH v2 01/12] usb: typec: add API to get port type and preferred role

This patch add 2 APIs to get port type and preferred role from firmware description. Signed-off-by: Li Jun --- change for v2 - Change the 2 APIs name and input para to be device_node pointer. drivers/usb/typec/typec.c | 46 ++

[PATCH v2 02/12] usb: typec: add API to get sink and source config

This patch add 2 APIs to get sink and source power config from firmware description. Signed-off-by: Li Jun --- drivers/usb/typec/tcpm.c | 43 +++ include/linux/usb/tcpm.h | 2 ++ 2 files changed, 45 insertions(+) diff --git

[PATCH v2 06/12] typec: tcpm: add starting value for drp toggling

As DRP port autonomously toggles the Rp/Rd need a start value to begin with, so add one parameter for it in tcpm_start_drp_toggling. Signed-off-by: Li Jun --- drivers/usb/typec/tcpm.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git

[PATCH v2 03/12] staging: typec: tcpci: support port config passed via dt

User can define the typec port properties in tcpci node to setup the port config. Signed-off-by: Li Jun --- Changes for v2: - Use infra APIs to get sink and source config. - Improve the error message. drivers/staging/typec/tcpci.c | 70

[PATCH v2 00/12] staging: typec: tcpci: move out of staging

This patch set attempts to move the tcpci driver out of staging by fix some tcpci driver issues and verified on NXP PTN5110, which is a standard tcpci typec port controller device with power delivery support, tested power source and sink with drp config. Main changes for v2: - Typec properties

[PATCH v2 05/12] staging: typec: tcpci: enable vbus detection

TCPCI implementation may need SW to enable VBUS detection to generate power status events. Signed-off-by: Li Jun --- Change for v2: - Directly enable vbus detect in tcpci_init rather than adding a API. drivers/staging/typec/tcpci.c | 6 ++ 1 file changed, 6 insertions(+)

[PATCH v2 04/12] staging: typec: tcpci: register port before request irq

With that we can clear any pending events and the port is registered so driver can be ready to handle typec events once we request irq. Signed-off-by: Peter Chen Signed-off-by: Li Jun --- drivers/staging/typec/tcpci.c | 11 +++ 1 file changed, 7

Re: [RFC PATCH] drivers: use 'depends on MFD_SYSCON' instead of 'select MFD_SYSCON'

2018-02-26 17:43 GMT+09:00 Arnd Bergmann : > On Sat, Feb 24, 2018 at 3:50 PM, Masahiro Yamada > wrote: >> As Documentation/kbuild/kconfig-language.txt notes, 'select' should be >> used with care - it forces a lower limit of another symbol, ignoring >>

Re: [PATCH v3 09/12] usb: roles: Add Intel xHCI USB role switch driver

On Mon, Feb 26, 2018 at 10:09:22AM +0100, Hans de Goede wrote: > Various Intel SoCs (Cherry Trail, Broxton and others) have an internal USB > role switch for swiching the OTG USB data lines between the xHCI host > controller and the dwc3 gadget controller. > > Note on some Cherry Trail systems

Re: [PATCH v3 00/12] USB Type-C device-connection, mux and switch support

On Mon, Feb 26, 2018 at 1:19 PM, Hans de Goede wrote: > On 26-02-18 11:59, Andy Shevchenko wrote: >> On Mon, Feb 26, 2018 at 11:09 AM, Hans de Goede >> wrote: >> Didn't have time to comment on v2, so here we are: >> you are using in even the same file

Re: [PATCH v3 00/12] USB Type-C device-connection, mux and switch support

Hi, On 26-02-18 11:59, Andy Shevchenko wrote: On Mon, Feb 26, 2018 at 11:09 AM, Hans de Goede wrote: Hi All, Here is version 3 of Heikki's and my USB Type-C device-connection, mux and switch support series. Version 2 and 3 bring various small code and style fixes based

Re: [PATCH v3 00/12] USB Type-C device-connection, mux and switch support

On Mon, Feb 26, 2018 at 11:09 AM, Hans de Goede wrote: > Hi All, > > Here is version 3 of Heikki's and my USB Type-C device-connection, mux and > switch support series. Version 2 and 3 bring various small code and style > fixes based on review (no major changes). > > Here is

[PATCH] usb: musb: call pm_runtime_{get,put}_sync before reading vbus registers

Without pm_runtime_{get,put}_sync calls in place, reading vbus status via /sys causes the following error: Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0ab060 pgd = b333e822 [fa0ab060] *pgd=48011452(bad) [] (musb_default_readb) from [] (musb_vbus_show+0x58/0xe4) []

Re: [PATCH] usb: serial: ftdi_sio: Add RT Systems VX-8 cable

On Fri, Feb 23, 2018 at 02:29:54PM -0600, Major Hayden wrote: > This patch adds a device ID for the RT Systems cable used to > program Yaesu VX-8R/VX-8DR handheld radios. It uses the main > FTDI VID instead of the common RT Systems VID. > > Signed-off-by: Major Hayden Now

Jmicron device 152d:0567 UAS off for some enclosure

Hi all I am currently using two multi-bay USB-SATA3 enclosure with JMicron JMS537 chipset 152d:0567 They are an Orico 9558ru3 and an Orico ns500rc3 According to the USB info they both use the JMS567 USBtoSATA bridge, I cannot tell anything about the NS500rc3 SATA multiport chipset, while the

Re: [PATCH RFC] ehci-omap: simple suspend implementation

Andreas, On 26/02/18 09:04, Andreas Kemnade wrote: > Hi, > > On Mon, 19 Feb 2018 11:41:36 +0200 > Roger Quadros wrote: > >> Andreas, >> >> On 16/02/18 20:35, Andreas Kemnade wrote: >>> On Fri, 16 Feb 2018 13:13:11 -0500 (EST) >>> Alan Stern wrote: >>>

[PATCH v3 00/12] USB Type-C device-connection, mux and switch support

Hi All, Here is version 3 of Heikki's and my USB Type-C device-connection, mux and switch support series. Version 2 and 3 bring various small code and style fixes based on review (no major changes). Here is the original cover-letter of v1: Some devices with an USB Type-C connector have a bunch

[PATCH v3 01/12] drivers: base: Unified device connection lookup

From: Heikki Krogerus Several frameworks - clk, gpio, phy, pmw, etc. - maintain lookup tables for describing connections and provide custom API for handling them. This introduces a single generic lookup table and API for the connections. The motivation for this

[PATCH v3 04/12] usb: common: Small class for USB role switches

From: Heikki Krogerus USB role switch is a device that can be used to choose the data role for USB connector. With dual-role capable USB controllers, the controller itself will be the switch, but on some platforms the USB host and device controllers are separate

[PATCH v3 07/12] xhci: Add option to get next extended capability in list by passing id = 0

From: Mathias Nyman Modify xhci_find_next_ext_cap(base, offset, id) to return the next capability offset if 0 is passed for id. Otherwise it will behave as previously and return the offset of the next capability with matching id capability id 0 is not used by xHCI

[PATCH v3 03/12] usb: typec: API for controlling USB Type-C Multiplexers

From: Heikki Krogerus USB Type-C connectors consist of various muxes and switches that route the pins on the connector to the right locations. The USB Type-C drivers need to be able to control the muxes, as they are the ones that know things like the cable plug

[PATCH v3 02/12] usb: typec: Start using ERR_PTR

From: Heikki Krogerus In order to allow the USB Type-C Class driver take care of things like muxes and other possible dependencies for the port drivers, returning ERR_PTR instead of NULL from the registration functions in case of failure. The reason for taking

[PATCH v3 08/12] xhci: Add Intel extended cap / otg phy mux handling

The xHCI controller on various Intel SoCs has an extended cap mmio-range which contains registers to control the muxing to the xHCI (host mode) or the dwc3 (device mode) and vbus-detection for the otg usb-phy. Having a role-sw driver included in the xHCI code (under drivers/usb/host) is not

[PATCH v3 05/12] usb: typec: tcpm: Set USB role switch to device mode when configured as such

Setting the mux to MUX_NONE and the switch to USB_SWITCH_DISCONNECT when the data-role is device is not correct. Plenty of devices support operating as USB device through a (separate) USB device controller. We really need 2 different versions of USB_SWITCH_CONNECT, USB_SWITCH_CONNECT_HOST and

[PATCH v3 09/12] usb: roles: Add Intel xHCI USB role switch driver

Various Intel SoCs (Cherry Trail, Broxton and others) have an internal USB role switch for swiching the OTG USB data lines between the xHCI host controller and the dwc3 gadget controller. Note on some Cherry Trail systems there is ACPI/AML code listening to edge interrupts on the id-pin (through

[PATCH v3 06/12] usb: typec: tcpm: Use new Type-C switch/mux and usb-role-switch functions

Remove the unused (not implemented anywhere) tcpc_mux_dev abstraction and replace it with calling the new typec_set_orientation, usb_role_switch_set and typec_set_mode functions. Reviewed-by: Heikki Krogerus Reviewed-by: Guenter Roeck

[PATCH v3 10/12] usb: typec: driver for Pericom PI3USB30532 Type-C cross switch

Add a driver for the Pericom PI3USB30532 Type-C cross switch / mux chip found on some devices with a Type-C port. Reviewed-by: Heikki Krogerus Signed-off-by: Hans de Goede --- Changes in v2: -Cleanup pi3usb30532_set_conf() error handling

[PATCH v3 12/12] extcon: axp288: Set USB role where necessary

The AXP288 BC1.2 charger detection / extcon code may seem like a strange place to add code to control the USB role-switch on devices with an AXP288, but there are 2 reasons to do this inside the axp288 extcon code: 1) On many devices the USB role is controlled by ACPI AML code, but the AML

[PATCH v3 11/12] platform/x86: intel_cht_int33fe: Add device connections for the Type-C port

We need to add device-connections for the Type-C mux/switch and usb-role code to be able to find the PI3USB30532 Type-C cross-switch and the device/host role-switch integrated in the CHT SoC. Acked-by: Andy Shevchenko Reviewed-by: Heikki Krogerus

Re: [RFC PATCH] drivers: use 'depends on MFD_SYSCON' instead of 'select MFD_SYSCON'

On Sat, Feb 24, 2018 at 3:50 PM, Masahiro Yamada wrote: > As Documentation/kbuild/kconfig-language.txt notes, 'select' should be > used with care - it forces a lower limit of another symbol, ignoring > the dependency. > > MFD_SYSCON depends on HAS_IOMEM, but several

Re: [PATCH v2 12/12] extcon: axp288: Set USB role where necessary

Hi, On 25-02-18 19:51, Randy Dunlap wrote: Hi, On 02/25/2018 07:25 AM, Hans de Goede wrote: diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig index a7bca4207f44..de15bf55895b 100644 --- a/drivers/extcon/Kconfig +++ b/drivers/extcon/Kconfig @@ -30,7 +30,8 @@ config EXTCON_ARIZONA