On 2017-09-04 13:19, Peter Rosin wrote:
> Hi!
>
> One comment inline...
Oh, and one more small nit, I think you should do
s/pi3usb30532_mux/pi3usb30532/g
to shorten the identifiers a bit. The _mux suffix (or infix) is kind of
selfevident from where the file lives anyway. pi3usb30532_mux_set_mux
gcc-8 points out two comparisons that are clearly bogus
and almost certainly not what the author intended to write:
drivers/usb/gadget/udc/dummy_hcd.c: In function 'set_link_state_by_speed':
drivers/usb/gadget/udc/dummy_hcd.c:379:31: error: bitwise comparison always
evaluates to false [-Werror=ta
Commit e0429362ab15
("usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e")
introduced quirk to workaround an issue with some Logitech webcams.
The workaround is introducing delay for some USB operations.
According to our testing, delay introduced by original commit
is not long enoug
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-detect
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 mux
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 to add
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 t
On 24.08.2017 05:53, Thang Q. Nguyen wrote:
On Sat, Aug 19, 2017 at 10:43 AM, Thang Q. Nguyen wrote:
From: "Thang Q. Nguyen"
For commit 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA
configuration"), sysdev points to devices known to the system firmware
or hardware for DMA parameters.
Howe
On 31.08.2017 20:54, Adam Wallis wrote:
Currently, xhci_plat is not set up properly when the parent device is an
ACPI node. The conditions that xhci_plat_probe should satisfy are
1. xhci_plat comes from firmware
2. xhci_plat is child of a device from firmware (dwc3-plat)
3. xhci_plat is grandchi
9634556022.doc
Description: MS-Word document
Currently, xhci_plat is not set up properly when the parent device is an
ACPI node. The conditions that xhci_plat_probe should satisfy are
1. xhci_plat comes from firmware
2. xhci_plat is child of a device from firmware (dwc3-plat)
3. xhci_plat is grandchild of a pci device (dwc3-pci)
Case 2 is c
On Tue, Sep 05, 2017 at 09:57:29AM -0400, Adam Wallis wrote:
> Currently, xhci_plat is not set up properly when the parent device is an
> ACPI node. The conditions that xhci_plat_probe should satisfy are
>
> 1. xhci_plat comes from firmware
> 2. xhci_plat is child of a device from firmware (dwc3-p
These patches fix a couple of bugs introduced by the recent runtime-PM
work.
Note that the external abort was due to the irq work never being flushed
on suspend, and that we may need similar fixes for the delayed reset and
resume work which are likewise never cancelled on suspend.
Johan
Johan
The musb delayed irq work was never flushed on suspend, something which
since 4.9 can lead to an external abort if the work is scheduled after
the grandparent's clock has been disabled:
PM: Suspending system (mem)
PM: suspend of devices complete after 125.224 msecs
PM: suspend devices took 0.132 s
The current session-bit quirk implementation does not prevent the retry
counter from underflowing, something which could break runtime PM and
keep the device active for a very long time (about 2^32 seconds) after a
disconnect.
This notably breaks the B-device timeout case, but could potentially
ca
On 9/5/2017 10:16 AM, Greg Kroah-Hartman wrote:
> On Tue, Sep 05, 2017 at 09:57:29AM -0400, Adam Wallis wrote:
>> Currently, xhci_plat is not set up properly when the parent device is an
>> ACPI node. The conditions that xhci_plat_probe should satisfy are
>>
>> 1. xhci_plat comes from firmware
>> 2
On 01.09.2017 04:41, Lu Baolu wrote:
Hi Mathias,
Xhci driver handles USB transaction errors on transfer events,
but transaction errors are possible on address device command
completion events as well.
The xHCI specification (section 4.6.5) says: A USB Transaction
Error Completion Code for an Ad
On Tue, 5 Sep 2017, Arnd Bergmann wrote:
> gcc-8 points out two comparisons that are clearly bogus
> and almost certainly not what the author intended to write:
>
> drivers/usb/gadget/udc/dummy_hcd.c: In function 'set_link_state_by_speed':
> drivers/usb/gadget/udc/dummy_hcd.c:379:31: error: bitwi
On Tue, Sep 05, 2017 at 10:25:19AM -0400, Adam Wallis wrote:
> On 9/5/2017 10:16 AM, Greg Kroah-Hartman wrote:
> > On Tue, Sep 05, 2017 at 09:57:29AM -0400, Adam Wallis wrote:
> >> Currently, xhci_plat is not set up properly when the parent device is an
> >> ACPI node. The conditions that xhci_plat
On 9/5/2017 10:31 AM, Greg Kroah-Hartman wrote:
> On Tue, Sep 05, 2017 at 10:25:19AM -0400, Adam Wallis wrote:
>> On 9/5/2017 10:16 AM, Greg Kroah-Hartman wrote:
>>> On Tue, Sep 05, 2017 at 09:57:29AM -0400, Adam Wallis wrote:
Currently, xhci_plat is not set up properly when the parent device
On Tue, Sep 05, 2017 at 10:38:03AM -0400, Adam Wallis wrote:
> On 9/5/2017 10:31 AM, Greg Kroah-Hartman wrote:
> > On Tue, Sep 05, 2017 at 10:25:19AM -0400, Adam Wallis wrote:
> >> On 9/5/2017 10:16 AM, Greg Kroah-Hartman wrote:
> >>> On Tue, Sep 05, 2017 at 09:57:29AM -0400, Adam Wallis wrote:
> >
Commit 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA configuration")
updated the method determining DMA for XHCI from sysdev. However, this
patch broke the ability to enumerate the FWNODE from parent ACPI devices
from the child plat XHCI device.
Currently, xhci_plat is not set up properly when
From: Thomas Gleixner
The bh tasklet is used in invoke the hrtimer (cdc_ncm_tx_timer_cb) in
softirq context. This can be also achieved without the tasklet but with
CLOCK_MONOTONIC_SOFT as hrtimer base.
Signed-off-by: Thomas Gleixner
Signed-off-by: Anna-Maria Gleixner
Cc: Oliver Neukum
Cc: Gre
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
---
Changes in v2:
-Start numb
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
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
Acked-by: Andy Shevchenko
---
drivers/platform/x86/Kconfig
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
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
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
---
Changes in v2:
-Adjust for new MUX_TYPEC_foo state defines
-Add MAINTAINERS entry
-Various code-style fixes
---
MAINTAINERS | 5 +++
d
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
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
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 DT
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
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, Sep 05, 2017 at 11:40:56AM +0300, Dmitry Fleytman wrote:
> Commit e0429362ab15
> ("usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e")
> introduced quirk to workaround an issue with some Logitech webcams.
>
> The workaround is introducing delay for some USB operations.
>
>
I've added a USB 3.0 card that should support super speed to a server I
have, but it's not working at super-speed speeds for the external hard
drives I connect, and a having a hard time diagnosing why (hardware
issue/quirk? driver issue?)
Before installing the card, xhci wasn't ever used, now
Hi,
I found a way to reliably trigger this bug:
- Boot laptop
- Plug in dock (with external display connected to dock)
- Send output to external display
- Suspend
I did a bisect between 4.12.3 and 4.12.4 and here is the result:
5cc9b698a494827b15f74ef70a31d7911d00e52a is the first bad commit
comm
On 06.09.2017 06:47, Thang Q. Nguyen wrote:
On Tue, Sep 5, 2017 at 6:14 PM, Mathias Nyman mailto:mathias.ny...@linux.intel.com>> wrote:
On 24.08.2017 05 :53, Thang Q. Nguyen wrote:
On Sat, Aug 19, 2017 at 10:43 AM, Thang Q. Nguyen mailto:tqngu...@apm.com>> wrote:
From
39 matches
Mail list logo
