Re: [PATCH v2 2/3] musb: sunxi: Remove custom babble handling

Hi, On 09/22/2016 04:54 PM, Bin Liu wrote: Hi, On Thu, Sep 22, 2016 at 02:19:00PM +0300, Hans de Goede wrote: The musb-core now a days always treats babble errors in host mode I don't think this statement is accurate. You might want to change it to "The musb core already handles b

Re: [PATCH v2 4/7] phy-sun4i-usb: Add support for phy_set_mode

HI, On 18-08-16 09:40, Felipe Balbi wrote: Hi, Hans de Goede <hdego...@redhat.com> writes: Hi, On 08/16/2016 03:48 PM, Sergei Shtylyov wrote: Hello. On 08/15/2016 10:21 PM, Hans de Goede wrote: Together with some musb sunxi glue changes this allows run-time dr_mode switching suppo

[PATCH v4 7/7] musb: sunxi: Add support for platform_set_mode

This allows run-time dr_mode switching support via the "mode" musb sysfs attribute. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- Changes in v2: -No changes Changes in v3: -Fix switch-case code style Changes in v4: -Call musb_root_disconnect() before role change to make s

Re: [PATCH v2 7/7] musb: sunxi: Add support for platform_set_mode

Hi, On 22-08-16 18:10, Bin Liu wrote: On Mon, Aug 22, 2016 at 05:55:50PM +0200, Hans de Goede wrote: Hi, On 22-08-16 17:38, Bin Liu wrote: On Mon, Aug 22, 2016 at 05:32:57PM +0200, Hans de Goede wrote: When switching from host to peripheral mode, if an usb device is still plugged

Re: [PATCH v3 6/7] phy-sun4i-usb: Add "allwinner,usb0-usb-a-connector" dt property

Hi, On 08/23/2016 08:00 PM, Rob Herring wrote: On Sun, Aug 21, 2016 at 02:16:38PM +0200, Hans de Goede wrote: On some devices the musb otg controller can be used in both device and host mode, but requires software mode switching since there is no id pin connected. The usb0 phy code

Re: [PATCH 1/2] usb: dwc3-pci: Fix dr_mode misspelling

Hi, On 27-12-16 12:14, Felipe Balbi wrote: Hi, Hans de Goede <hdego...@redhat.com> writes: usb_get_dr_mode() expects the device-property to be spelled "dr_mode" not "dr-mode". Spelling it properly fixes the following warning showing up in dmesg: [ 870

Re: JMS56x not working reliably with uas driver

USB_SC_DEVICE, USB_PR_DEVICE, NULL, +US_FL_NO_REPORT_OPCODES), + /* Reported-by: Hans de Goede <hdego...@redhat.com> */ UNUSUAL_DEV(0x2109, 0x0711, 0x, 0x, "VIA", ->8 2) On disconnect I am seeing the follo

Re: JMS56x not working reliably with uas driver

Hi, On 21-12-16 12:42, Oliver Neukum wrote: On Wed, 2016-12-21 at 17:09 +0530, George Cherian wrote: Hi Oliver, I was working with this JMicron device and using the uas driver. I am seeing the following 2 issues. 1) On connect I see the following messages. Thanks. Do you want to submit it

Re: JMS56x not working reliably with uas driver

Hi, On 21-12-16 13:07, George Cherian wrote: On 12/21/2016 05:12 PM, Oliver Neukum wrote: On Wed, 2016-12-21 at 17:09 +0530, George Cherian wrote: Hi Oliver, I was working with this JMicron device and using the uas driver. I am seeing the following 2 issues. 1) On connect I see the

Re: [PATCH 0/2] Intel cherrytrail xhci extended cap phy/mux support

HI, On 22-12-16 17:28, Mathias Nyman wrote: On 22.12.2016 14:45, Hans de Goede wrote: Hi, On 22-12-16 13:11, Felipe Balbi wrote: Hi, Hans de Goede <hdego...@redhat.com> writes: Hi All, Here are 2 patches which can and should be merged separately, but which do belong together, as to

Re: [PATCH 2/2] phy: Add new Intel Cherrytrail USB OTG phy driver

Hi, On 23-12-16 02:04, Lu Baolu wrote: Hi, On 12/22/2016 07:47 PM, Hans de Goede wrote: +static int intel_cht_usb_phy_probe(struct platform_device *pdev) +{ + struct intel_cht_usb_phy *phy; + struct device *dev = >dev; + struct resource *res; + resource_size_t s

Re: [PATCH 0/2] Intel cherrytrail xhci extended cap phy/mux support

HI, On 23-12-16 02:25, Lu Baolu wrote: Hi, On 12/22/2016 09:18 PM, Felipe Balbi wrote: Hi, Hans de Goede <hdego...@redhat.com> writes: Matthias, assuming Felipe is ok with putting this in drivers/misc (minus the phy bindings), are you ok with the xhci blurb which registers the pl

[PATCH 1/2] usb: dwc3-pci: Fix dr_mode misspelling

usb_get_dr_mode() expects the device-property to be spelled "dr_mode" not "dr-mode". Spelling it properly fixes the following warning showing up in dmesg: [ 8704.500545] dwc3 dwc3.2.auto: Configuration mismatch. dr_mode forced to gadget Signed-off-by: Hans de Goede

[PATCH 2/2] usb: dwc3-pci: Do not use PLATFORM_DEVID_AUTO for platform child-device id

allocator, so that the name will always be dwc3.0 for the first (and most likely only) dwc3 controller enumerated. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/usb/dwc3/dwc3-pci.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/usb/dwc

[PATCH 0/2] Intel cherrytrail xhci extended cap phy/mux support

Hi All, Here are 2 patches which can and should be merged separately, but which do belong together, as together they add support for the usb-phy / mux bits found in the Intel Cherrytrail xhci vendor defined extended capabilities registers. I did not want to hide an entire phy driver inside the

[PATCH 2/2] phy: Add new Intel Cherrytrail USB OTG phy driver

ich points to the Intel Vendor Defined XHCI extended capabilities region. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/phy/Kconfig | 10 ++ drivers/phy/Makefile| 1 + drivers/phy/phy-intel-cht-usb.c | 367 3 fi

[PATCH 1/2] usb: xhci: Add Intel cherrytrail extended cap / otg phy mux handling

. So this commit adds a simple handler for this extended capability, which creates a platform device with the caps mmio region as resource, this allows us to write a separate platform phy driver for the mux. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/usb/host/Ma

Re: [PATCH 0/2] Intel cherrytrail xhci extended cap phy/mux support

Hi, On 22-12-16 13:11, Felipe Balbi wrote: Hi, Hans de Goede <hdego...@redhat.com> writes: Hi All, Here are 2 patches which can and should be merged separately, but which do belong together, as together they add support for the usb-phy / mux bits found in the Intel Cherrytrail xhci

Re: [PATCH 0/2] Intel cherrytrail xhci extended cap phy/mux support

Hi, On 22-12-16 17:28, Mathias Nyman wrote: On 22.12.2016 14:45, Hans de Goede wrote: Hi, On 22-12-16 13:11, Felipe Balbi wrote: Hi, Hans de Goede <hdego...@redhat.com> writes: Hi All, Here are 2 patches which can and should be merged separately, but which do belong together, as to

[PATCH] usb: xhci: Disable streams on Intel Cherrytrail controllers

, so lets disable streams on cherrytrail until we can find a better workaround. Cc: sta...@vger.kernel.org Cc: Oliver Neukum <oneu...@suse.com> Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/usb/host/xhci-pci.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/driv

Re: [PATCH 0/2] Intel cherrytrail xhci extended cap phy/mux support

Hi, On 22-12-16 14:18, Felipe Balbi wrote: Hans de Goede <hdego...@redhat.com> writes: Baolu has worked on this for months but it turned out that several folks said 'no' to his patchset. You're not really dealing with a PHY, it's just a portmux which can generate some UTMI messages t

Re: [PATCH 0/6] ACPI / PM: Suspend-to-idle rework to deal with spurious ACPI wakeups

Hi, On 08-06-17 02:00, Rafael J. Wysocki wrote: Hi All, This series is a replacement for commit eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle) which is still there in 4.12-rc4 but will be reverted shortly, because it triggered issues on quite a few systems. The

Re: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works

Hi, First of all lets add the HID subsys maintainers to the To list (done). On 08-06-17 22:17, Linus Torvalds wrote: On Thu, Jun 8, 2017 at 12:49 PM, Alan Stern wrote: So maybe CONFIG_HID_ASUS should default to Y? I'll leave it up to Hans to straighten this out.

Re: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works

Hi, On 09-06-17 10:52, Bjørn Mork wrote: Greg KH writes: On Fri, Jun 09, 2017 at 10:21:47AM +0200, Jiri Kosina wrote: Longer-term, we'd ideally make 'generic' driver special and let it attach as a 'last resort driver' if none of the specific driver picked the device up

Re: [PATCH] HID: let generic driver yield control iff specific driver has been enabled (was Re: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works)

Hi, On 09-06-17 13:25, Jiri Kosina wrote: On Fri, 9 Jun 2017, Jiri Kosina wrote: This is something I've been wanting to fix for ages, but never really got to it. So let's take this as the final impulse to do it. So I'd suggest to go with something like the below for 4.12-rc. Hmm? From:

Re: [PATCH] HID: let generic driver yield control iff specific driver has been enabled (was Re: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works)

good to me. Note I've *not* checked that all the VID:PID pairs in the hid_have_special_driver[] list are in the right #if IS_ENABLED block, with that caveat this patch is: Acked-by: Hans de Goede <hdego...@redhat.com> If you want I can make some time to double check that all the VID:PID

Re: [PATCH] HID: let generic driver yield control iff specific driver has been enabled (was Re: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works)

Hi, On 09-06-17 15:00, Benjamin Tissoires wrote: On Jun 09 2017 or thereabouts, Jiri Kosina wrote: On Fri, 9 Jun 2017, Jiri Kosina wrote: This is something I've been wanting to fix for ages, but never really got to it. So let's take this as the final impulse to do it. So I'd suggest to go

Re: [PATCH v2 10/11] staging: typec: fusb302: Hook up mux support using tcpc_gen_mux support

Hi, On 13-09-17 17:07, Rob Herring wrote: On Wed, Sep 13, 2017 at 9:06 AM, Hans de Goede <hdego...@redhat.com> wrote: Hi, On 13-09-17 15:38, Rob Herring wrote: On Wed, Sep 13, 2017 at 3:56 AM, Hans de Goede <hdego...@redhat.com> wrote: Hi, On 13-09-17 00:20, Rob H

Re: [PATCH v2 03/11] mux: core: Add usb.h header with MUX_USB_* and and MUX_TYPEC_* state constants

Hi, On 10-09-17 23:36, Peter Rosin wrote: On 2017-09-08 19:07, Hans de Goede wrote: Hi, On 08-09-17 17:47, Peter Rosin wrote: On 2017-09-05 18:42, Hans de Goede wrote: Add MUX_USB_* and MUX_TYPEC_* state constant defines, which can be used by USB device/host, resp. Type-C polarity/role

Re: [PATCH v2 04/11] usb: xhci: Add Intel cherrytrail extended cap / otg phy mux handling

Hi, On 19-09-17 14:40, Mathias Nyman wrote: Hi, sorry about the long delay On 07.09.2017 18:49, Hans de Goede wrote: Hi, On 07-09-17 15:14, Mathias Nyman wrote: On 05.09.2017 19:42, Hans de Goede wrote: The Intel cherrytrail xhci controller has an extended cap mmio-range which contains

Re: [PATCH v2 08/11] staging: typec: tcpm: Set mux to device mode when configured as such

Hi, On 09/11/2017 12:56 AM, Guenter Roeck wrote: On 09/05/2017 09:42 AM, Hans de Goede wrote: Setting the mux to TYPEC_MUX_NONE, TCPC_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

[PATCH v3 14/14] platform/x86: intel_cht_int33fe: Add mux mappings for the Type-C port

We need to add mappings for the mux subsys to be able to find the muxes for the fusb302 driver to be able to control the PI3USB30532 Type-C mux and the device/host mux integrated in the CHT SoC. Signed-off-by: Hans de Goede <hdego...@redhat.com> Acked-by: Andy Shevchenko <and

[PATCH v3 13/14] staging: typec: fusb302: Hook up mux support using tcpc_gen_mux support

mark.rutl...@arm.com> Cc: devicet...@vger.kernel.org Signed-off-by: Hans de Goede <hdego...@redhat.com> --- Changes in v3: -Drop devicetree bindings documentation, since this is only used with device-properties set by platform code on X86/ACPI now, we don't need bindings yet --- drivers

[PATCH v3 08/14] mux: Add Intel Cherrytrail USB mux driver

the Intel Vendor Defined XHCI extended capabilities region. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- Changes in v2: -Complete rewrite as a stand-alone platform-driver rather then as a phy driver, since this is just a mux, not a phy Changes in v3: -Make this a mux subsys driver inst

[PATCH v3 11/14] staging: typec: tcpm: Set mux to device mode when configured as such

, TCPC_USB_SWITCH_DISCONNECT) so that the mux does _not_ stay in its last mode after a detach. Signed-off-by: Hans de Goede <hdego...@redhat.com> Reviewed-by: Guenter Roeck <li...@roeck-us.net> --- Changes in v3: -Improve / reword last paragraph of the commit message -Add Guenter's Reviewed-by ---

[PATCH v3 10/14] extcon: intel-int3496: Add support for controlling the USB-role mux

handle for the mux and set the mux through the mux-subsys rather then through a GPIO. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- Changes in v2: -Drop || COMPILE_TEST from Kconfig depends on, as we will now fail to compile on !X86 -Minor code style tweaks --- drivers/extcon/K

[PATCH v3 09/14] mux: Add Pericom PI3USB30532 Type-C mux driver

Add a driver for the Pericom PI3USB30532 Type-C cross switch / mux chip found on some devices with a Type-C port. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- Changes in v2: -Adjust for new MUX_TYPEC_foo state defines -Add MAINTAINERS entry -Various code-style fixes Changes in v3

[PATCH v3 12/14] staging: typec: Add Generic TCPC mux driver using the mux subsys

So far the mux functionality of the tcpm code has not been hooked up in any tcpc drivers. This commit adds a generic TCPC mux driver using the mux subsys, which tcpc drivers can use to provide mux functionality in cases where an external my is used. Signed-off-by: Hans de Goede <hd

[PATCH v3 07/14] xhci: Add Intel cherrytrail extended cap / otg phy mux handling

(), it is added here because xhci_ext_cap_init() must be called only once. If in the future we also want to handle ext-caps on non pci XHCI HCDs from xhci_ext_cap_init() a call to it should also be added to other bus probe paths. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- Changes

[PATCH v3 04/14] mux: core: Add support for getting a mux controller on a non DT platform

controller on a non DT platform following this pattern. It is based on a simplified version of the pwm subsys lookup code, the dev_id and mux_name parts of a lookup table entry are mandatory in the mux-core implementation. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- Changes in v2:

[PATCH v3 05/14] mux: core: Add usb.h header with MUX_USB_* and and MUX_TYPEC_* state constants

Add MUX_USB_* and MUX_TYPEC_* state constant defines, which can be used by USB device/host, resp. Type-C polarity/role/altmode mux drivers and consumers to ensure that they agree on the meaning of the mux_control_select() state argument. Signed-off-by: Hans de Goede <hdego...@redhat.

[PATCH v3 03/14] mux: core: Add of_mux_control_get helper function

for getting muxes on non DT platforms. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/mux/core.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/mux/core.c b/drivers/mux/core.c index d0ad56abca2a..8c0a4c83cdc5 100644 --- a/drivers/mux/

[PATCH v3 01/14] mux: core: Add mux_control_get_optional() API

gh, so add a mux_control_get_optional() API that allows the driver to differentiate errors getting the mux from there not being a mux for the driver to use at all. Signed-off-by: Stephen Boyd <stephen.b...@linaro.org> Signed-off-by: Hans de Goede <hdego...@redhat.com> --- Document

[PATCH v3 02/14] mux: core: Add explicit hook to leave the mux as-is on init/registration

nsumer can access it and set a state that destroys booting all the same. 2. The mux controller might linger in a state that is not the preferred idle state indefinitely, if no mux consumer ever selects and then deselects the mux. Signed-off-by: Hans de Goede <hdego...@redhat.com> ---

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

y xhci (reserved) This is useful when we want to loop through all capabilities. Signed-off-by: Mathias Nyman <mathias.ny...@linux.intel.com> Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/usb/host/xhci-ext-caps.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deleti

Re: [PATCH v2 05/11] mux: Add Intel Cherrytrail USB mux driver

Hi, Thank you for the reviews and patches! On 09/08/2017 05:45 PM, Peter Rosin wrote: On 2017-09-05 18:42, Hans de Goede wrote: Intel Cherrytrail SoCs have an internal USB mux for muxing the otg-port USB data lines between the xHCI host controller and the dwc3 gadget controller. On some

Re: [PATCH 1/2] mux: add mux_control_get_optional() API

Hi, On 09/08/2017 05:54 PM, Peter Rosin wrote: On 2017-09-08 17:45, Peter Rosin wrote: From: Stephen Boyd Sometimes drivers only use muxes under certain scenarios. For example, the chipidea usb controller may be connected to a usb switch on some platforms, and

[PATCH 4.14 REGRESSION fix] USB: devio: Revert "USB: devio: Don't corrupt user memory"

uxfoundation.org> Cc: sta...@vger.kernel.org Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/usb/core/devio.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c index 4664e543cf2f..e9326f31db8d 100644

Re: [PATCH v2 03/11] mux: core: Add usb.h header with MUX_USB_* and and MUX_TYPEC_* state constants

Hi, On 08-09-17 17:47, Peter Rosin wrote: On 2017-09-05 18:42, Hans de Goede wrote: Add MUX_USB_* and MUX_TYPEC_* state constant defines, which can be used by USB device/host, resp. Type-C polarity/role/altmode mux drivers and consumers to ensure that they agree on the meaning

[PATCH v2 01/11] mux: core: Add of_mux_control_get helper function

for getting muxes on non DT platforms. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/mux/core.c | 26 ++ 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/drivers/mux/core.c b/drivers/mux/core.c index 6e5cf9d9cd99..99d29f982c0e

[PATCH v2 11/11] platform/x86: intel_cht_int33fe: Add mux mappings for the Type-C port

We need to add mappings for the mux subsys to be able to find the muxes for the fusb302 driver to be able to control the PI3USB30532 Type-C mux and the device/host mux integrated in the CHT SoC. Signed-off-by: Hans de Goede <hdego...@redhat.com> Acked-by: Andy Shevchenko <and

[PATCH v2 03/11] mux: core: Add usb.h header with MUX_USB_* and and MUX_TYPEC_* state constants

Add MUX_USB_* and MUX_TYPEC_* state constant defines, which can be used by USB device/host, resp. Type-C polarity/role/altmode mux drivers and consumers to ensure that they agree on the meaning of the mux_control_select() state argument. Signed-off-by: Hans de Goede <hdego...@redhat.

[PATCH v2 04/11] usb: xhci: Add Intel cherrytrail extended cap / otg phy mux handling

. So this commit adds a simple handler for this extended capability, which creates a platform device with the caps mmio region as resource, this allows us to write a separate platform mux driver for the mux. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- Changes in v2: -Check xHCI cont

[PATCH v2 05/11] mux: Add Intel Cherrytrail USB mux driver

the Intel Vendor Defined XHCI extended capabilities region. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- Changes in v2: -Complete rewrite as a stand-alone platform-driver rather then as a phy driver, since this is just a mux, not a phy Changes in v3: -Make this a mux subsys driver inst

[PATCH v2 02/11] mux: core: Add support for getting a mux controller on a non DT platform

controller on a non DT platform following this pattern. It is based on a simplified version of the pwm subsys lookup code, the dev_id and mux_name parts of a lookup table entry are mandatory in the mux-core implementation. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- Changes in v2:

[PATCH v2 00/11] mux/typec: Add USB / TypeC mux drivers and hook them up on some x86 systems

Hi All, Here is v2 of my USB / Type-C mux series, addressing various comments from the reviews of v1. See the per patch changelogs for details. For reference here the cover letter of v1: This series consists of 4 parts: 1) Core mux changes to add support for getting mux-controllers on non

[PATCH v2 10/11] staging: typec: fusb302: Hook up mux support using tcpc_gen_mux support

mark.rutl...@arm.com> Cc: devicet...@vger.kernel.org Signed-off-by: Hans de Goede <hdego...@redhat.com> --- Documentation/devicetree/bindings/usb/fcs,fusb302.txt | 3 +++ drivers/staging/typec/fusb302/fusb302.c | 11 ++- 2 files changed, 13 insertions(+), 1 delet

[PATCH v2 09/11] staging: typec: Add Generic TCPC mux driver using the mux subsys

So far the mux functionality of the tcpm code has not been hooked up in any tcpc drivers. This commit adds a generic TCPC mux driver using the mux subsys, which tcpc drivers can use to provide mux functionality in cases where an external my is used. Signed-off-by: Hans de Goede <hd

[PATCH v2 08/11] staging: typec: tcpm: Set mux to device mode when configured as such

, TCPC_USB_SWITCH_DISCONNECT so that it does not and up staying in host (and with this commit also device) mode after a detach. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/staging/typec/tcpm.c | 7 --- drivers/staging/typec/tcpm.h | 22 ++ 2 files changed, 18 inse

[PATCH v2 06/11] mux: Add Pericom PI3USB30532 Type-C mux driver

Add a driver for the Pericom PI3USB30532 Type-C cross switch / mux chip found on some devices with a Type-C port. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- Changes in v2: -Adjust for new MUX_TYPEC_foo state defines -Add MAINTAINERS entry -Various code-style fixes --- MAINT

Re: [PATCH v2 04/11] usb: xhci: Add Intel cherrytrail extended cap / otg phy mux handling

Hi, On 07-09-17 15:14, Mathias Nyman wrote: On 05.09.2017 19:42, Hans de Goede wrote: The Intel cherrytrail xhci controller 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

Re: [PATCH v2 10/11] staging: typec: fusb302: Hook up mux support using tcpc_gen_mux support

Hi, On 13-09-17 00:20, Rob Herring wrote: On Tue, Sep 05, 2017 at 06:42:20PM +0200, Hans de Goede wrote: Add mux support to the fusb302 driver, call devm_tcpc_gen_mux_create() to let the generic tcpc_mux_dev code create a tcpc_mux_dev for us. Also document the mux-names used by the generic

Re: [PATCH v2 10/11] staging: typec: fusb302: Hook up mux support using tcpc_gen_mux support

Hi, On 13-09-17 15:38, Rob Herring wrote: On Wed, Sep 13, 2017 at 3:56 AM, Hans de Goede <hdego...@redhat.com> wrote: Hi, On 13-09-17 00:20, Rob Herring wrote: On Tue, Sep 05, 2017 at 06:42:20PM +0200, Hans de Goede wrote: Add mux support to the fusb302 driver

Re: [PATCH v2 10/11] staging: typec: fusb302: Hook up mux support using tcpc_gen_mux support

Hi, On 25-09-17 15:45, Peter Rosin wrote: On 2017-09-25 13:35, Hans de Goede wrote: Hi, On 25-09-17 12:34, Peter Rosin wrote: On 2017-09-13 17:48, Hans de Goede wrote: Hi, On 13-09-17 17:07, Rob Herring wrote: On Wed, Sep 13, 2017 at 9:06 AM, Hans de Goede <hdego...@redhat.com> wrot

Re: [PATCH v2 10/11] staging: typec: fusb302: Hook up mux support using tcpc_gen_mux support

Hi, On 25-09-17 12:34, Peter Rosin wrote: On 2017-09-13 17:48, Hans de Goede wrote: Hi, On 13-09-17 17:07, Rob Herring wrote: On Wed, Sep 13, 2017 at 9:06 AM, Hans de Goede <hdego...@redhat.com> wrote: Hi, On 13-09-17 15:38, Rob Herring wrote: On Wed, Sep 13, 2017 at 3:56 AM, H

Re: [PATCH 07/11] extcon: intel-int3496: Add support for controlling the USB-role mux

Hi, On 02-09-17 12:39, Andy Shevchenko wrote: On Sat, Sep 2, 2017 at 12:48 AM, Hans de Goede <hdego...@redhat.com> wrote: Cherry Trail SoCs have a built-in USB-role mux for switching between the host and device controllers, rather then using an external mux controller by

Re: [PATCH 11/11] platform/x86: intel_cht_int33fe: Add mux mappings for the Type-C port

Hi, On 02-09-17 12:42, Andy Shevchenko wrote: On Sat, Sep 2, 2017 at 12:48 AM, Hans de Goede <hdego...@redhat.com> wrote: We need to add mappings for the mux subsys to be able to find the muxes for the fusb302 driver to be able to control the PI3USB30532 Type-C mux and the device/ho

Re: [PATCH 02/11] mux: core: Add support for getting a mux controller on a non DT platform

Hi, On 02-09-17 21:13, sathya wrote: Hi, On 09/01/2017 02:48 PM, Hans de Goede wrote: On non DT platforms we cannot get the mux_chip by pnode. Other subsystems (regulator, clock, pwm) have the same problem and solve this by allowing platform / board-setup code to add entries to a lookup

Re: [PATCH 05/11] mux: Add Intel Cherrytrail USB mux driver

Hi, Thank you for the reviews! On 02-09-17 12:19, Andy Shevchenko wrote: On Sat, Sep 2, 2017 at 12:48 AM, Hans de Goede <hdego...@redhat.com> wrote: Intel Cherrytrail SoCs have an internal USB mux for muxing the otg-port USB data lines between the xHCI host controller and the dwc3

[PATCH 06/11] mux: Add Pericom PI3USB30532 Type-C mux driver

Add a driver for the Pericom PI3USB30532 Type-C cross switch / mux chip found on some devices with a Type-C port. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/mux/Kconfig | 10 + drivers/mux/Makefile | 2 + drivers/mux/pi3usb30532.

[PATCH 05/11] mux: Add Intel Cherrytrail USB mux driver

the Intel Vendor Defined XHCI extended capabilities region. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- Changes in v2: -Complete rewrite as a stand-alone platform-driver rather then as a phy driver, since this is just a mux, not a phy Changes in v3: -Make this a mux subsys driver inst

[PATCH 09/11] staging: typec: Add Generic TCPC mux driver using the mux subsys

So far the mux functionality of the tcpm code has not been hooked up in any tcpc drivers. This commit adds a generic TCPC mux driver using the mux subsys, which tcpc drivers can use to provide mux functionality in cases where an external my is used. Signed-off-by: Hans de Goede <hd

[PATCH 07/11] extcon: intel-int3496: Add support for controlling the USB-role mux

handle for the mux and set the mux through the mux-subsys rather then through a GPIO. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/extcon/Kconfig| 1 + drivers/extcon/extcon-intel-int3496.c | 59 ++- 2 files changed, 59 inse

[PATCH 08/11] staging: typec: tcpm: Set mux to device mode when configured as such

, TCPC_USB_SWITCH_DISCONNECT so that it does not and up staying in host (and with this commit also device) mode after a detach. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/staging/typec/tcpm.c | 7 --- drivers/staging/typec/tcpm.h | 22 ++ 2 files changed, 18 inse

[PATCH 02/11] mux: core: Add support for getting a mux controller on a non DT platform

controller on a non DT platform following this pattern. It is based on a simplified version of the pwm subsys lookup code, the dev_id and mux_name parts of a lookup table entry are mandatory in the mux-core implementation. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/mux/

[PATCH 00/11] mux/typec: Add USB / TypeC mux drivers and hook them up on some x86 systems

Hi All, This series consists of 4 parts: 1) Core mux changes to add support for getting mux-controllers on non DT platforms and to add some standardised state values for USB 2) Add Intel CHT USB mux and Pericom-PI3USB30532 Type-C mux drivers 3) Hookup the Intel CHT USB mux driver for CHT

[PATCH 01/11] mux: core: Add of_mux_control_get helper function

for getting muxes on non DT platforms. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/mux/core.c | 26 ++ 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/drivers/mux/core.c b/drivers/mux/core.c index e75d5adc5949..6142493c327b

[PATCH 03/11] mux: consumer.h: Add MUX_USB_* state constant defines

Add MUX_USB_* state constant defines, which can be used by USB device/host and Type-C polarity/role/altmode mux drivers and consumers to ensure that they agree on the meaning of the mux_control_select() state argument. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- include/lin

[PATCH 11/11] platform/x86: intel_cht_int33fe: Add mux mappings for the Type-C port

We need to add mappings for the mux subsys to be able to find the muxes for the fusb302 driver to be able to control the PI3USB30532 Type-C mux and the device/host mux integrated in the CHT SoC. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/platform/x86/Kconfig

[PATCH 10/11] staging: typec: fusb302: Hook up mux support using tcpc_gen_mux support

mark.rutl...@arm.com> Cc: devicet...@vger.kernel.org Signed-off-by: Hans de Goede <hdego...@redhat.com> --- Documentation/devicetree/bindings/usb/fcs,fusb302.txt | 3 +++ drivers/staging/typec/fusb302/fusb302.c | 11 ++- 2 files changed, 13 insertions(+), 1 delet

[PATCH 04/11] usb: xhci: Add Intel cherrytrail extended cap / otg phy mux handling

. So this commit adds a simple handler for this extended capability, which creates a platform device with the caps mmio region as resource, this allows us to write a separate platform mux driver for the mux. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- Changes in v2: -Check xHCI cont

Re: [PATCH 03/11] mux: consumer.h: Add MUX_USB_* state constant defines

Hi, On 02-09-17 12:10, Andy Shevchenko wrote: On Sat, Sep 2, 2017 at 12:48 AM, Hans de Goede <hdego...@redhat.com> wrote: Add MUX_USB_* state constant defines, which can be used by USB device/host and Type-C polarity/role/altmode mux drivers and consumers to ensure that they

Re: [PATCH 03/11] mux: consumer.h: Add MUX_USB_* state constant defines

Hi, On 02-09-17 16:59, Guenter Roeck wrote: On 09/01/2017 02:48 PM, Hans de Goede wrote: Add MUX_USB_* state constant defines, which can be used by USB device/host and Type-C polarity/role/altmode mux drivers and consumers to ensure that they agree on the meaning of the mux_control_select

Re: [PATCH 03/11] mux: consumer.h: Add MUX_USB_* state constant defines

Hi, On 02-09-17 21:06, Guenter Roeck wrote: On Sat, Sep 02, 2017 at 05:59:14PM +0200, Hans de Goede wrote: Hi, On 02-09-17 16:59, Guenter Roeck wrote: On 09/01/2017 02:48 PM, Hans de Goede wrote: Add MUX_USB_* state constant defines, which can be used by USB device/host and Type-C polarity

Re: [PATCH 04/11] usb: xhci: Add Intel cherrytrail extended cap / otg phy mux handling

Hi, On 04-09-17 09:31, Heikki Krogerus wrote: Hi, On Fri, Sep 01, 2017 at 11:48:38PM +0200, Hans de Goede wrote: The Intel cherrytrail xhci controller 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

Re: [PATCH 00/11] mux/typec: Add USB / TypeC mux drivers and hook them up on some x86 systems

Hi Peter, On 04-09-17 13:18, Peter Rosin wrote: On 2017-09-01 23:48, Hans de Goede wrote: Hi All, This series consists of 4 parts: 1) Core mux changes to add support for getting mux-controllers on non DT platforms and to add some standardised state values for USB 2) Add Intel CHT USB

Re: [PATCH 02/11] mux: core: Add support for getting a mux controller on a non DT platform

Hi, On 04-09-17 13:19, Peter Rosin wrote: Hi! Some comments inline... On 2017-09-01 23:48, Hans de Goede wrote: On non DT platforms we cannot get the mux_chip by pnode. Other subsystems (regulator, clock, pwm) have the same problem and solve this by allowing platform / board-setup code

Re: [PATCH 05/11] mux: Add Intel Cherrytrail USB mux driver

Hi, On 04-09-17 13:19, Peter Rosin wrote: Hi! Some comments inline... On 2017-09-01 23:48, Hans de Goede wrote: Intel Cherrytrail SoCs have an internal USB mux for muxing the otg-port USB data lines between the xHCI host controller and the dwc3 gadget controller. On some Cherrytrail systems

Re: [PATCH v3 10/14] extcon: intel-int3496: Add support for controlling the USB-role mux

Hi, On 18-10-17 04:33, Chanwoo Choi wrote: Hi Hans, On 2017년 09월 23일 03:37, Hans de Goede wrote: Cherry Trail SoCs have a built-in USB-role mux for switching between the host and device controllers, rather then using an external mux controller by a GPIO. There is a driver using the mux

Re: [PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device

Hi, On 13-11-17 07:14, Jérôme Carretero wrote: On Mon, 13 Nov 2017 07:01:30 +0300 Andrey Astafyev <1...@246060.ru> wrote: 13.11.2017 00:42, Jérôme Carretero пишет: Nov 12 16:20:59 Bidule kernel: sd 22:0:0:0: [sdaa] tag#2 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD OUT [...] Do you see

Re: [PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device

Hi, On 15-11-17 10:06, Oliver Neukum wrote: Am Dienstag, den 14.11.2017, 18:44 +0100 schrieb Hans de Goede: Greg, please do no merge the 2 recent uas seagate quirks I send then. I will submit a patch with the new approach right away. Hi, I am afraid in that case we will need a way

Re: [RFC PATCH 0/2] usb: typec: alternate mode bus

Hi Heiko, On 28-09-17 13:35, Heikki Krogerus wrote: Hi guys, The bus allows SVID specific communication with the partners to be handled in separate drivers for each alternate mode. Alternate mode handling happens with two separate logical devices: 1. Partner alternate mode devices which

[PATCH] uas: Remove US_FL_NO_ATA_1X unusual device entries for Seagate devices

Since commit 7fee72d5e8f1 ("uas: Always apply US_FL_NO_ATA_1X quirk to Seagate devices"), the US_FL_NO_ATA_1X is always set for Seagate devices, so the per device unusual_uas.h entries for Seagate devices can be removed. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- dri

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

Hi, On 11/24/2017 01:19 PM, Heikki Krogerus wrote: Hi, On Tue, Nov 14, 2017 at 11:44:47AM +, Adam Thomson wrote: diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c index 78983e1..7c26c3d 100644 --- a/drivers/usb/typec/tcpm.c +++ b/drivers/usb/typec/tcpm.c @@ -12,6 +12,7 @@

Re: [PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device

Hi, On 14-11-17 15:00, Hans de Goede wrote: Just like all previous UAS capable Seagate disk enclosures, this one needs a US_FL_NO_ATA_1X quirk. Cc: sta...@vger.kernel.org # 3.16 Reported-by: Wido <wido...@gmail.com> Signed-off-by: Hans de Goede <hdego...@redhat.com> So far we've

[PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device

Just like all previous UAS capable Seagate disk enclosures, this one needs a US_FL_NO_ATA_1X quirk. Cc: sta...@vger.kernel.org # 3.16 Reported-by: Wido <wido...@gmail.com> Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/usb/storage/unusual_uas.h | 7 +++ 1 fil

Re: [PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device

Hi, On 11/14/2017 04:25 PM, Alan Stern wrote: On Tue, 14 Nov 2017, Hans de Goede wrote: Hi, On 14-11-17 15:00, Hans de Goede wrote: Just like all previous UAS capable Seagate disk enclosures, this one needs a US_FL_NO_ATA_1X quirk. Cc: sta...@vger.kernel.org # 3.16 Reported-by: Wido <w

[PATCH] uas: Always apply US_FL_NO_ATA_1X quirk to Seagate devices

We've been adding this as a quirk on a per device basis hoping that newer disk enclosures would do better, but that has not happened, so simply apply this quirk to all Seagate devices. Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/usb/storage/uas-detect.h | 4

[PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device

Just like all previous UAS capable Seagate disk enclosures, this one needs a US_FL_NO_ATA_1X quirk. Cc: sta...@vger.kernel.org # 3.16 Signed-off-by: Andrey Astafyev <1...@246060.ru> Signed-off-by: Hans de Goede <hdego...@redhat.com> --- drivers/usb/storage/unusual_uas.h | 7 +++

Re: Seagate Backup Plus UAS patch

Hi, On 05-11-17 13:00, Andrey Astafyev wrote: Hello. Please, add Seagate Backup Plus entry to unusual devices list. As Greg already mentioned you need to submit this as a proper patch following the kernel's patch-submission guidelines. If you don't know how to do that I can do this for you,

<    5   6   7   8   9   10   11   12   >