I noticed that when debugging some USB clocking issue that there weren't
many ways to tell what the state of the USB clocking system was. This
adds a few logging statements to see what the relevant code is trying to
do.
Signed-off-by: Marcin Ziemianowicz
---
drivers/clk/at91/clk-pll.c | 6 +++
On Sun, Apr 08, 2018 at 05:43:30AM -0400, Marcin wrote:
> I noticed that when debugging some USB clocking issue that there weren't
> many ways to tell what the state of the USB clocking system was. This
> adds a few logging statements to see what the relevant code is trying to
> do.
>
> Signed-off
On Sun, Apr 08, 2018 at 11:54:49AM +0200, Greg Kroah-Hartman wrote:
> On Sun, Apr 08, 2018 at 05:43:30AM -0400, Marcin wrote:
> > I noticed that when debugging some USB clocking issue that there weren't
> > many ways to tell what the state of the USB clocking system was. This
> > adds a few logging
Fix kernel documentation no longer building due to un-escaped ascii-art
in Documentation/driver-api/usb/typec.rst.
Fixes: bdecb33af34f ("usb: typec: API for controlling USB Type-C ...")
Signed-off-by: Hans de Goede
---
Documentation/driver-api/usb/typec.rst | 2 ++
1 file changed, 2 insertions(+
On Sun, 8 Apr 2018, Marcin wrote:
> I noticed that when debugging some USB clocking issue that there weren't
> many ways to tell what the state of the USB clocking system was. This
> adds a few logging statements to see what the relevant code is trying to
> do.
>
> Signed-off-by: Marcin Ziemianow
On Sun, Apr 08, 2018 at 03:45:19PM +0200, Hans de Goede wrote:
> Fix kernel documentation no longer building due to un-escaped ascii-art
> in Documentation/driver-api/usb/typec.rst.
>
> Fixes: bdecb33af34f ("usb: typec: API for controlling USB Type-C ...")
> Signed-off-by: Hans de Goede
> ---
>
If the USB controller can wake up the system (which is the case for
example with the Mediatek USB3 IP) then we must not call phy_exit during
suspend to ensure that the USB controller doesn't have to re-enumerate
the devices during resume.
However, if the USB controller cannot wake up the system (wh
usb_phy_roothub_exit() should return the error code from the phy_exit()
call if exiting the PHY failed.
However, since a wrong variable is used usb_phy_roothub_exit() currently
always returns 0, even if one of the phy_exit calls returned an error.
Clang also reports this bug:
kernel/drivers/usb/cor
Before this patch usb_phy_roothub_init served two purposes (from a
caller's point of view - like hcd.c):
- parsing the PHYs and allocating the list entries
- calling phy_init on each list entry
While this worked so far it has one disadvantage: if we need to call
phy_init for each PHY instance then
This clarifies the license of the code. While here also add an include
guard to the header file.
Fixes: 07dbff0ddbd86c ("usb: core: add a wrapper for the USB PHYs on the HCD")
Suggested-by: Masahiro Yamada
Signed-off-by: Martin Blumenstingl
---
drivers/usb/core/phy.h | 12
1 file c
If the generic PHY support is disabled the stub of devm_of_phy_get_by_index
returns ENOSYS. This corner case isn't handled properly by
usb_phy_roothub_add_phy and at least breaks USB support on Raspberry Pi
(bcm2835_defconfig):
dwc2 2098.usb: dwc2_hcd_init() FAILED, returning -38
dwc2:
Currently hcd.c is the only consumer of the usb_phy_roothub logic. This
already includes the required header files so struct device is known.
However, future consumers might not know about struct device.
Add a forward declaration for struct device to fix potential future
consumers which don't inclu
This is a follow-up to my previous series "initialize (multiple) PHYs
for a HCD": [0].
Roger Quadros reported [1] that it "is breaking low power cases on TI
SoCs when USB is in host mode". He further explains that "Not doing the
phy_exit() here [when entering suspend] leaves the clocks enabled on
From: ShuFan Lee
Add device tree binding document for Richtek RT1711H Type-C chip driver
Signed-off-by: ShuFan Lee
---
.../devicetree/bindings/usb/richtek,rt1711h.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/rich
From: ShuFan Lee
This patch series add rt1711h typec chip driver and dt-bindings
changelogs between v1 & v2
- use gpiod_* instead of gpio_*
changelogs between v2 & v3
- add dt-bindings for rt1711h typec driver
changelogs between v3 & v4
- add definition of RT1711H_VID and RT1711H_PID
- modify
From: ShuFan Lee
Richtek RT1711H Type-C chip driver that works with
Type-C Port Controller Manager to provide USB PD and
USB Type-C functionalities.
Add definition of TCPC_CC_STATUS_TOGGLING.
Signed-off-by: ShuFan Lee
Reviewed-by: Heikki Krogerus
Reviewed-by: Guenter Roeck
---
drivers/stagin
Hi
> -Original Message-
> From: Hans de Goede [mailto:hdego...@redhat.com]
> Sent: 2018年4月3日 23:17
> To: Jun Li ; gre...@linuxfoundation.org; robh...@kernel.org;
> mark.rutl...@arm.com; heikki.kroge...@linux.intel.com
> Cc: li...@roeck-us.net; rmf...@gmail.com; yueyao@gmail.com;
> linux
17 matches
Mail list logo