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 table and then use
this table to look things up.
This commit adds support for getting a mux cont
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 dev
Currently the mux_control_get implementation only deals with getting
mux controllers on DT platforms. This commit renames the current
implementation to of_mux_control_get to reflect this and makes
mux_control_get a wrapper around of_mux_control_get.
This is a preparation patch for adding support f
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
---
include/linux/mux/consumer.h | 16 ++
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 this mux is controlled through
AML code reacting on a GPIO IRQ connected to the USB OTG id pin (through
an _AIE ACPI me
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
---
drivers/mux/Kconfig | 10 +
drivers/mux/Makefile | 2 +
drivers/mux/pi3usb30532.c | 97 ++
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.
So this commit instead splits out TYPEC_MUX_USB into TYPEC_MUX_USB_HOST
and TYPEC_MUX_USB_DEVICE
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
---
drivers/stagi
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-subsys to control this mux, this
commit adds support to the intel-int3496 driver to get a mux_controller
han
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 tcpc_mux_dev code in
our devicetree bindings.
Cc: Rob Herring
Cc: Mark Rutland
Cc: devicet...@vger.kernel.org
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
---
drivers/platform/x86/Kconfig | 1 +
drivers/platform/x8
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.
Having a mux driver included in the xhci code (or under drivers/usb/host)
is not desirable.
On Tue, Jan 17, 2017 at 1:29 AM, Jim Lin wrote:
> When gadget is disconnected, running sequence is like this.
> . composite_disconnect
> . Call trace:
> usb_string_copy+0xd0/0x128
> gadget_config_name_configuration_store+0x4
> gadget_config_name_attr_store+0x40/0x50
> configfs_write_file+0
On Mon, Aug 28, 2017 at 04:20:12PM +0200, Amelie Delaunay wrote:
> This patch adds binding documentation for DWC2 controller in HS mode found
> on STMicroelectronics STM32F7 SoC.
>
> Signed-off-by: Amelie Delaunay
> ---
> Documentation/devicetree/bindings/usb/dwc2.txt | 2 ++
> 1 file changed, 2
On Fri, Sep 01, 2017 at 04:11:36PM +0200, Johan Hovold wrote:
> The following changes since commit ef954844c7ace62f773f4f23e28d2d915adc419f:
>
> Linux 4.13-rc5 (2017-08-13 16:01:32 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-
(apprently didn't post; take 2)
Upgrading from a working linux64 kernel-default 4.12.7x instance to ->
kernel-default 4.12.8x breaks USB devices (non-responsive) on AMD
SB700 motherboards.
I reported @ distro
Bug 1055044 - kernel-stable upgrade from 4.12.7 -> 4.12.[8,9,10]
causes USB device
The following changes since commit ef954844c7ace62f773f4f23e28d2d915adc419f:
Linux 4.13-rc5 (2017-08-13 16:01:32 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git
tags/usb-serial-4.14-rc1
for you to fetch changes up to b5fdde2
On 01.09.2017 09:21, Felipe Balbi wrote:
Hi,
Jim Dickerson writes:
Servers were emitting failed handoff messages but were not
waiting the full 1 second as designated in section 4.22.1 of
the eXtensible Host Controller Interface specifications. The
handshake was using wrong units so calls were
On 30.08.2017 14:34, Chunfeng Yun wrote:
The xhci-mtk driver is a generic driver for MediaTek xHCI IP, add
a generic compatible to avoid confusion when support new SoCs but
use a compatible with specific SoC's name "mt8173".
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk.c |1 +
19 matches
Mail list logo
