Acked-by: Michal Nazarewicz
2018-07-04 5:51 GMT+01:00 Jaejoong Kim :
> The kref used to be needed because sharing of fsg_common among multiple USB
> function instances was handled by fsg. Now this is managed by configfs, we
> don't need it anymore. So let's eliminate kref from this driver.
>
> Si
Hi,
Posting this query again as I received some mail delivery failure
notification on the previous attempt.
I am running usbtest test cases and facing following issues:
Setup:
I am using two custom board running on Linux. One is configured as
host and loaded with usbtest.ko module. Another one
On Wed, Jul 04, 2018 at 05:18:34PM +0100, Chris Jakob wrote:
> Thanks.
> Apologies I may have been a little premature as the device still does
> not seem to be working (although it is now recognised)
>
> dmesg provides:
> [6.864734] kl5kusb105: loading out-of-tree module taints kernel.
> [
Hi
I have started playing around with a board based on the DragonBoard
820c and I cannot manage to get the USB2 working as host.
If I connect a mouse, before I start the board I can see how the
system powers up the port (vbus) and enumerates the device, just to
kill it a couple of seconds later.
Hi,
On Fri, Jun 29, 2018 at 10:26:46PM +0200, Timur Krist?f wrote:
> Hi Heikki,
>
> On Fri, 2018-06-29 at 14:42 +0300, Heikki Krogerus wrote:
> > Hi Tim,
> >
> > On Tue, Jun 26, 2018 at 02:10:57PM +0200, Timur Krist?f wrote:
> > > > Can you send the dmesg output after you have plugged the powere
On Wed, Jul 04, 2018 at 09:25:43AM +, Wei Yongjun wrote:
> Add the missing unlock before return from function
> dp_altmode_activate() in the error handling case.
>
> Fixes: 0e3bb7d6894d ("usb: typec: Add driver for DisplayPort alternate mode")
> Signed-off-by: Wei Yongjun
> ---
> drivers/usb
[ Adding linux-usb as other may be interested in this. ]
On Thu, Jul 05, 2018 at 01:57:29PM +0100, Antonio Santagiuliana wrote:
> Thank you for the information.
> What I don't understand is that if I use the CP2105 are its GPIOs usable by
> this driver ?
Yes, they should be. But if I remember cor
On Wed, 4 Jul 2018, Jaejoong Kim wrote:
> The kref used to be needed because sharing of fsg_common among multiple USB
> function instances was handled by fsg. Now this is managed by configfs, we
> don't need it anymore. So let's eliminate kref from this driver.
>
> Signed-off-by: Jaejoong Kim
A
On Wed, 4 Jul 2018, R0b0t1 wrote:
> On Sun, Jul 1, 2018 at 9:12 AM, Alan Stern wrote:
> > On Sat, 30 Jun 2018, R0b0t1 wrote:
> >
> >> The problem seems more noticeable when using the Python libusb
> >> bindings but it still exists when using libusb directly. Can anyone
> >> suggest what to look i
The commit 3bc04e28a030 ("usb: dwc2: host: Get aligned DMA in a more
supported way") introduced a common way to align DMA allocations.
The code in the commit aligns the struct dma_aligned_buffer but the
actual DMA address pointed by data[0] gets aligned to an offset from
the allocated boundary by t
Here are two patches that improve DMA alignment handling of the dwc2
driver significantly.
The first one ("usb: dwc2: Fix DMA alignment to start at allocated
boundary") fixes an actual crash regression on some platforms introduced
by commit 3bc04e28a030 ("usb: dwc2: host: Get aligned DMA in a more
Make sure only to copy any actual data rather than the whole buffer,
when releasing the temporary buffer used for unaligned non-isochronous
transfers.
Taken directly from commit 0efd937e27d5e ("USB: ehci-tegra: fix inefficient
copy of unaligned buffers")
Tested with Lantiq xRX200 (MIPS) and RPi M
Older cp210x devices only support a fixed set of line speeds to which a
requested speed is mapped. Reimplement this mapping using a table
instead of a long if-else construct.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/cp210x.c | 99 +
1 file changed, 5
This cleans up the current line-speed handling somewhat, while avoiding
requesting an unsupported line speed (which can lead to undefined
behaviour) by determining the maximum speed supported by the device type
in question.
Karoly, how did your line-speed tests with cp2102n go? I think we should
j
Newer cp210x devices support higher line speeds than the older ones
which supported a discrete set of speeds up to 921.6 kbaud.
To support these higher speeds, we have for some time mapped speeds
lower than 1 Mbaud to the speeds supported by older devices, while
allowing the device to pick the clo
On Thu, 5 Jul 2018, Pradeep Das wrote:
> Hi,
>
> Posting this query again as I received some mail delivery failure
> notification on the previous attempt.
>
> I am running usbtest test cases and facing following issues:
>
> Setup:
> I am using two custom board running on Linux. One is configur
Hi,
> Karoly, how did your line-speed tests with cp2102n go?
I indeed tested this. I first built a version of the module where I skip
calling cp210x_quantise_baudrate(). Then I attached a scope to the TX
line of my UART adapter and looked at various non-standard values in both
low (<10k) and high
Thanks, Alan Stern for a quick reply.
Can you please suggest a probable area to look out for the failure of
the endpoint halt test case for the superspeed devices.
On Thu, Jul 5, 2018 at 8:31 PM Alan Stern wrote:
>
> On Thu, 5 Jul 2018, Pradeep Das wrote:
>
> > Hi,
> >
> > Posting this query agai
18 matches
Mail list logo
