Hi,
On Fri, 2019-01-11 at 14:31 +0100, Miquel Raynal wrote:
> Marvell Armada 3700 SoC has two USB controllers, each of them being
> wired to an internal UTMI PHY. Add a driver to control them.
>
> Igal Liberman worked on supporting the PHY, I took the while 'register
> configuration' from his work
Thanks for getting back to me Mauro.
So it works on MacOS via a hootoo USB-C dongle
https://s.natalian.org/2019-01-15/hootoo.jpeg
So since my T480s has two USB-C ports, I tried using the same dongle on my
Thinkpad. It works!
I discovered that I can reliably get the device working by using
From: Min Guo
These patches introduce the MediaTek MUSB controller driver.
The driver can be configured as Dual-Role Device (DRD),
Peripheral Only and Host Only modes. This has beed tested on
MT2701 with a variety of devices in host mode and with the
f_mass gadget driver in peripheral mode, plu
From: Min Guo
Add a common interface for set data toggle
Signed-off-by: Min Guo
---
drivers/usb/musb/musb_host.c | 37 +++--
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index b59ce9a
From: Min Guo
This adds support for MediaTek musb controller in
host, peripheral and otg mode.
There are some quirk of MediaTek musb controller, such as:
-W1C interrupt status registers
-Private data toggle registers
-No dedicated DMA interrupt line
Signed-off-by: Min Guo
Signed-off-by: Yong
From: Min Guo
Add musb nodes and usb2 phy nodes for MT2701
Signed-off-by: Min Guo
---
arch/arm/boot/dts/mt2701-evb.dts | 21 +
arch/arm/boot/dts/mt2701.dtsi| 33 +
2 files changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701-e
From: Min Guo
This adds support for MediaTek musb controller in
host, peripheral and otg mode.
Signed-off-by: Min Guo
---
.../devicetree/bindings/usb/mediatek,musb.txt | 43 ++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/m
Hi Minas and John,
I'm hoping that one of you can help me devise a fix to a system hang issue
caused by BNA interrupts on USB Endpoint 0.
Our system is using an Altera Cyclone V SoC FPGA on our board with linux kernel
4.14.44 and enabling the USB gadget for HID (keyboard and mouse) and mass
st
This fixes autoloading the module by the OF compatible string.
Fixes: 813e18b18a87f31c5b216ea7546127deac3ae1ae
Cc: sta...@vger.kernel.org # v4.19+
Signed-off-by: Lubomir Rintel
---
drivers/usb/host/ehci-mv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/host/ehci-mv.c b/drivers
Current GPIO code in cp210x fails to take USB autosuspend into account,
making it practically impossible to use GPIOs with autosuspend enabled
without user configuration. Fix this like for ftdi_sio in a previous patch.
Tested on a CP2102N.
Signed-off-by: Karoly Pados
---
drivers/usb/serial/cp210
Add nodes for USB and related PHYs.
Signed-off-by: Jeffrey Hugo
---
arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi | 22
arch/arm64/boot/dts/qcom/msm8998.dtsi | 92 +++
2 files changed, 114 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
Add a MSM8998 specific DT compatible so that we can properly bind to the
device and enable the USB controller.
Signed-off-by: Jeffrey Hugo
---
drivers/usb/dwc3/dwc3-qcom.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index a6d020
MSM8998 contains a single QMP v3 USB3 phy similar to the existing sdm845
support.
Signed-off-by: Jeffrey Hugo
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 140
drivers/phy/qualcomm/phy-qcom-qmp.h | 4 ++
2 files changed, 144 insertions(+)
diff --git a/drivers
MSM8998 contains one QUSB2 PHY which is very similar to the existing
sdm845 support.
Signed-off-by: Jeffrey Hugo
---
drivers/phy/qualcomm/phy-qcom-qusb2.c | 41 +++
1 file changed, 41 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c
b/drivers/phy
msm8998 USB has a dwc3 controller just like the existing sdm845 support
Signed-off-by: Jeffrey Hugo
---
Documentation/devicetree/bindings/usb/qcom,dwc3.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
b/Documentation/devicetree/bindings
USB on msm8998 utilizes the QUSB2 and QMP phys, similar to sdm845.
Signed-off-by: Jeffrey Hugo
---
Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 5 +
Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt | 1 +
2 files changed, 6 insertions(+)
diff --git a/Documentation/devi
This series provides basic USB support for MSM8998. Currently missing is
wiring up the Type-C detection logic so that the controller can correctly
switch between host and peripheral modes. Work to implement that is
ongoing, and expected to appear soon in followup patches. Also missing is
Display
On Mon, Jan 14, 2019 at 10:12:09AM -0500, Alan Stern wrote:
> On Mon, 14 Jan 2019, Johan Hovold wrote:
>
> > On Sun, Jan 13, 2019 at 07:14:23PM -0800, Marc MERLIN wrote:
> > > On Mon, Dec 31, 2018 at 12:34:31PM -0500, Alan Stern wrote:
> > > > > Just a small addition, many Intel xHCI controllers n
On Mon, 14 Jan 2019, Paul Elder wrote:
> > > > Can you check your uvc
> > > > changes using dummy_hcd with the patch below?
> > >
> > > I'm not sure what to make of the test results. I get the same results
> > > with or without the patch. Which I guess makes sense... in dummy_queue,
> > > this is
On Mon, Jan 14, 2019 at 02:48:21PM +0100, Johan Hovold wrote:
> On Mon, Jan 14, 2019 at 01:30:03PM +0100, Karoly Pados wrote:
> > There is a bug in the current GPIO code for ftdi_sio: it failed to take USB
> > autosuspend into account. If the device is in autosuspend, calls to
> > usb_control_msg()
On Mon, 14 Jan 2019, Johan Hovold wrote:
> On Sun, Jan 13, 2019 at 07:14:23PM -0800, Marc MERLIN wrote:
> > On Mon, Dec 31, 2018 at 12:34:31PM -0500, Alan Stern wrote:
> > > > Just a small addition, many Intel xHCI controllers now support 64
> > > > devices.
> > > >
> > > > It's possible to get
Am 14.01.19 um 11:48 schrieb Oliver Neukum:
> On Fr, 2019-01-11 at 19:49 +0100, Jan-Marek Glogowski wrote:
>>
>> Yup, but the device is just detected if its plugged in on boot / module load.
>> I now have recompiled 5.0-rc1 with xhci as a module.
>
> First of all, is this a regression? Did earlier
On Mon, Jan 14, 2019 at 01:30:03PM +0100, Karoly Pados wrote:
> There is a bug in the current GPIO code for ftdi_sio: it failed to take USB
> autosuspend into account. If the device is in autosuspend, calls to
> usb_control_msg() fail with -EHOSTUNREACH. Because the standard value for
> autosuspend
There is a bug in the current GPIO code for ftdi_sio: it failed to take USB
autosuspend into account. If the device is in autosuspend, calls to
usb_control_msg() fail with -EHOSTUNREACH. Because the standard value for
autosuspend timeout is usually 2-5 seconds, this made it almost impossible
to use
On Sun, Jan 13, 2019 at 07:14:23PM -0800, Marc MERLIN wrote:
> On Mon, Dec 31, 2018 at 12:34:31PM -0500, Alan Stern wrote:
> > > Just a small addition, many Intel xHCI controllers now support 64 devices.
> > >
> > > It's possible to get the max device slots xHCI hardware supports from a
> > > xHC
Em Mon, 14 Jan 2019 13:10:25 +0800
Kai Hendry escreveu:
> Archlinux user here. It doesn't matter whether I'm running LTS kernel
> 4.19.14-1-lts or 4.20.1.arch1-1, I get these very annoying USB issues with my
> Magewell XI100DUSB-HDMI. Most of the time it doesn't work. I seemingly have
> better
On Fr, 2019-01-11 at 19:49 +0100, Jan-Marek Glogowski wrote:
>
> Yup, but the device is just detected if its plugged in on boot / module load.
> I now have recompiled 5.0-rc1 with xhci as a module.
First of all, is this a regression? Did earlier kernels work?
>
> If I plug the device after the m
On Fri, Jan 11, 2019 at 10:13:28AM +, Karoly Pados wrote:
> As the next step I'm going to prepare a patch to fix this buggy
> interaction with PM. Assuming GPIO pin state is not lost in suspend
> (I'll test this explicitly later), which of the following two ways is
> the preferred solution?
>
Hi,
Minas Harutyunyan writes:
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 68ad75a7460d..55ef3cc2701b 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -261,7 +261,7 @@ static void dwc2_gadget_wkup_alert_handler(struct
Hi Filipe,
On 1/14/2019 12:15 PM, Felipe Balbi wrote:
>
> Hi,
>
> Minas Harutyunyan writes:
>> Hi Greg, Filipe,
>>
>> On 12/12/2018 4:44 PM, Minas Harutyunyan wrote:
>>> To clear GINTSTS2_WKUP_ALERT_INT bit in GINTSTS2 register
>>> require to write 1. This bit is implemented as "Write to clear"
From: Bo He
We see dwc3 endpoint stopped by unwanted irq during
suspend resume test, which is caused dwc3 ep can't be started
with error "No Resource".
Here, add synchronize_irq before suspend to sync the
pending IRQ handlers complete.
Signed-off-by: Bo He
Signed-off-by: Yu Wang
Signed-off-by
Hi,
Minas Harutyunyan writes:
> Hi Greg, Filipe,
>
> On 12/12/2018 4:44 PM, Minas Harutyunyan wrote:
>> To clear GINTSTS2_WKUP_ALERT_INT bit in GINTSTS2 register
>> require to write 1. This bit is implemented as "Write to clear".
>>
>> Fixes: 187c5298a122 ("usb: dwc2: gadget: Add handler for Wk
Hi,
Zeng Tao writes:
> We have already returned EAGAIN for bus-expiry, and it's designed to
> start with a future Frame number and start the transfer again. So we
> should not remove the request for that case.
>
> Signed-off-by: Zeng Tao
Do we need a Fixes tag here? How about Cc stable? Can yo
33 matches
Mail list logo
