Hi Andreas,
[auto build test ERROR on staging/staging-testing]
[cannot apply to v4.13-rc7 next-20170901]
[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/linux/commits/Andreas-Ziegler/staging-r8822be-Fix-typo-f
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/r
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 table and then use
this table to look things
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/role/altmode mux drivers and consu
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()
sta
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()
state argument.
Signed-off-by: Hans de Goede
--
Hi,
On 02-09-17 12:10, Andy Shevchenko wrote:
On Sat, Sep 2, 2017 at 12:48 AM, 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_
On Sat, Sep 2, 2017 at 12:48 AM, Hans de Goede 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/host mux integrated in the CHT SoC.
>
I suppose it will go via not PDx86 tree,
On Sat, Sep 2, 2017 at 12:48 AM, 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-subsys to control this mux, this
> commit ad
On Sat, Sep 2, 2017 at 12:48 AM, 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 this mux is controlled through
> AML code reacting on a GP
On Sat, Sep 2, 2017 at 12:48 AM, 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()
> state argument.
> +/*
> + * Mux
11 matches
Mail list logo
