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
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
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
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
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
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
> ---
>
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
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, 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
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
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 +++
17 matches
Mail list logo