+ Rob
Hi Chunfeng Yun,
Thanks for the feedback.
> Subject: Re: [PATCH v6 4/7] usb: gadget: udc: renesas_usb3: Add dual role
> switch support
>
> On Wed, 2019-05-15 at 13:09 +0100, Biju Das wrote:
> > The RZ/G2E cat874 board has a type-c connector connected to hd3ss3220
> > usb type-c drp port c
On Mi, 2019-05-15 at 16:15 +0200, starost...@gmail.com wrote:
> Dne 15.5.2019 v 15:54 Oliver Neukum napsal(a):
> > 1. Determine whether the bug depends on the use of an IOMMU
>
> No, bug not depends on the use of an IOMMU. System crash on both cases.
Interesting.
> > 2.Send a new report to the
Dne 16.5.2019 v 9:58 Oliver Neukum napsal(a):
2.Send a new report to the corresponding mailing list
Which mailing list is correct?
In that case linux-usb@vger.kernel.org
HTH
Oliver
Is there some rules how to send bug report? Or I can send report with
"my amateur descr
On Do, 2019-05-16 at 10:20 +0200, starost...@gmail.com wrote:
> Dne 16.5.2019 v 9:58 Oliver Neukum napsal(a):
> > > > 2.Send a new report to the corresponding mailing list
> > >
> > > Which mailing list is correct?
> >
> > In that case linux-usb@vger.kernel.org
> >
> > HTH
> >
On Thu, 2019-05-16 at 12:09 +0530, Nagarjuna Kristam wrote:
> This patch adds UDC driver for tegra XUSB 3.0 device mode controller.
> XUSB device mode controller supports SS, HS and FS modes
>
> Based on work by:
> Mark Kuo
> Andrew Bresticker
>
> Signed-off-by: Nagarjuna Kristam
> ---
>
Hi Fredrik,
Thanks very much for taking the time to look into this. Please see
comments inline.
On 15.05.2019 19:28, Fredrik Noring wrote:
> Hi Lauretniu,
>
>> I think that any recent kernel will do, so I'd say your current branch
>> should be fine.
>
> The kernel oopses with "unable to handle
From: Laurentiu Tudor
For HCs that have local memory, replace the current DMA API usage
with a genalloc generic allocator to manage the mappings for these
devices.
This is in preparation for dropping the existing "coherent" dma
mem declaration APIs. Current implementation was relying on a short
c
Hi Fredrick,
On 15.05.2019 19:28, Fredrik Noring wrote:
> Hi Lauretniu,
>
>> I think that any recent kernel will do, so I'd say your current branch
>> should be fine.
>
> The kernel oopses with "unable to handle kernel paging request at virtual
> address 000aba0b" in hcd_alloc_coherent via usb_h
From: Laurentiu Tudor
In preparation for dropping the existing "coherent" dma mem declaration
APIs, replace the current dma_declare_coherent_memory() based mechanism
with the creation of a genalloc pool that will be used in the OHCI
subsystem as replacement for the DMA APIs.
For context, see thr
From: Laurentiu Tudor
In preparation for dropping the existing "coherent" dma mem declaration
APIs, replace the current dma_declare_coherent_memory() based mechanism
with the creation of a genalloc pool that will be used in the OHCI
subsystem as replacement for the DMA APIs.
For context, see thr
From: Laurentiu Tudor
For HCs that have local memory, replace the current DMA API usage
with a genalloc generic allocator to manage the mappings for these
devices.
This is in preparation for dropping the existing "coherent" dma
mem declaration APIs. Current implementation was relying on a short
c
Dne 16.5.2019 v 10:34 Oliver Neukum napsal(a):
Mention
1. kernel version
2. whether this is known to be a regression
Sorry for question, can you more specify what you mean?
3. include the log with iommu disabled and mention that you disabled
the IOMMU
4. Include the output of lsusb
H
From: Naveen Kumar Parna
This fixes checkpatch.pl warning "WARNING: Prefer 'unsigned int' to
bare use of 'unsigned'".
Signed-off-by: Naveen Kumar Parna
---
drivers/usb/serial/mos7840.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/serial/mos7840.c b/drivers/us
On Do, 2019-05-16 at 14:29 +0200, starost...@gmail.com wrote:
> Dne 16.5.2019 v 10:34 Oliver Neukum napsal(a):
> > Mention
> >
> > 1. kernel version
> > 2. whether this is known to be a regression
>
> Sorry for question, can you more specify what you mean?
You will be asked whether this worked
Hello,
when I try to read EEPROM memory from FT232R chip (USB to serial
converter), system crash after a seconds.
1) Configuration
ASUS PRIME A320M-K, latest bios version 4801, default settings.
Ubuntu server 19.04 with kernel 5.1.1-050101-generic:
https://kernel.ubuntu.com/~kernel-ppa/mainlin
Dne 16.5.2019 v 15:11 Oliver Neukum napsal(a):
You will be asked whether this worked in earlier version of the
kernel. The answer would be: yes, no, unknown (why)
HTH
Oliver
Thank you, I sent new report.
starosta
Hi Laurentiu,
> > The kernel oopses with "unable to handle kernel paging request at virtual
> > address 000aba0b" in hcd_alloc_coherent via usb_hcd_map_urb_for_dma.
>
> By any chance, does this address looks like the dma_addr that the device
> should target?
Yes, that looks like a typical devi
On Thu, May 16, 2019 at 03:35:42PM +0200, starost...@gmail.com wrote:
> Hello,
> when I try to read EEPROM memory from FT232R chip (USB to serial
> converter), system crash after a seconds.
You should mention that you're using libusb and the vendor's ftdi
library. Specifically, the kernels ftdi_s
On 16.5.2019 16.56, Johan Hovold wrote:
On Thu, May 16, 2019 at 03:35:42PM +0200, starost...@gmail.com wrote:
Hello,
when I try to read EEPROM memory from FT232R chip (USB to serial
converter), system crash after a seconds.
You should mention that you're using libusb and the vendor's ftdi
libr
USB 2.0 specification chapter 11.17.5 says "as part of endpoint halt
processing for full-/low-speed endpoints connected via a TT, the host
software must use the Clear_TT_Buffer request to the TT to ensure
that the buffer is not in the busy state".
In our case, a full-speed speaker (ConferenceCam)
The Clear_TT_Buffer request sent to the hub includes the address of
the LS/FS child device in wValue field. usb_hub_clear_tt_buffer()
uses udev->devnum to set the address wValue. This won't work for
devices connected to xHC.
For other host controllers udev->devnum is the same as the address of
the
USB 2.0 specification chapter 11.17.5 says "as part of endpoint halt
processing for full-/low-speed endpoints connected via a TT, the host
software must use the Clear_TT_Buffer request to the TT to ensure
that the buffer is not in the busy state".
In our case, a full-speed speaker (ConferenceCam)
On Thu, 16 May 2019, Jim Lin wrote:
> The Clear_TT_Buffer request sent to the hub includes the address of
> the LS/FS child device in wValue field. usb_hub_clear_tt_buffer()
> uses udev->devnum to set the address wValue. This won't work for
> devices connected to xHC.
>
> For other host controlle
Without USB_QUIRK_NO_LPM ethernet will not work and rtl8152 will
complain with
r8152 : Stop submitting intr, status -71
Adding the quirk resolves this. As the dock is externally powered, this
should not have any drawbacks.
Signed-off-by: Maximilian Luz
---
drivers/usb/core/quirks.c | 3 +++
Hi Laurentiu,
> I took your code, added the missing mapping and placed it in a patch.
> Please see attached (compile tested only).
Thanks! Unfortunately, the OHCI fails with errors such as
usb 1-1: device descriptor read/64, error -12
that I tracked down to the calls
hub_po
From: Naveen Kumar Parna
This patch removes following checkpatch.pl error in usb/host/ohci-pci.c file.
ERROR: space prohibited before open square bracket '['
Signed-off-by: Naveen Kumar Parna
---
drivers/usb/host/ohci-pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dr
We want to be able to wake from USB if a device is plugged in that
wants remote wakeup. Enable it on both dwc2 controllers.
NOTE: this is added specifically to veyron and not to rk3288 in
general since it's not known whether all rk3288 boards are designed to
support USB wakeup. It is plausible t
Some SoCs with a dwc2 USB controller may need to keep the PHY on to
support remote wakeup. Allow specifying this as a device tree
property.
Signed-off-by: Douglas Anderson
---
For relevant prior discussion on this patch, see:
https://lkml.kernel.org/r/1435017144-2971-3-git-send-email-diand...@c
If the 'snps,need-phy-for-wake' is set in the device tree then:
- We know that we can wakeup, so call device_set_wakeup_capable().
The USB core will use this knowledge to enable wakeup by default.
- We know that we should keep the PHY on during suspend if something
on our root hub needs remote
This is a re-post of the last 3 patches of a series I posted earlier
at:
https://lkml.kernel.org/r/20190418001356.124334-1-diand...@chromium.org
The first two patches were applied but the last three weren't because
they didn't apply at the time. They apply fine now so are ready to
land.
Change
30 matches
Mail list logo
