This patch will add support for OTG host initialization. This will
help OTG drivers to populate their host subsystem.
Signed-off-by: Manish Narani
---
drivers/usb/host/xhci-plat.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/drivers/usb/host/xhci-p
Promote a variable keeping track of USB transfer memory usage to a
wider data type and allow for higher bandwidth transfers from a large
number of USB devices connected to a single host.
Signed-off-by: Mateusz Berezecki
---
drivers/usb/core/devio.c | 43 --
On Thu, Dec 15, 2016 at 12:25:08AM +0530, Manish Narani wrote:
> This patch will add support for OTG host initialization. This will
> help OTG drivers to populate their host subsystem.
>
> Signed-off-by: Manish Narani
> ---
> drivers/usb/host/xhci-plat.c | 35 ++
This patch will add support for OTG host initialization. This will
help OTG drivers to populate their host subsystem.
Signed-off-by: Manish Narani
---
drivers/usb/host/xhci-plat.c | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/drivers/
The stop_activity() routine in dummy-hcd is supposed to unlink all
active requests for every endpoint, among other things. But it
doesn't handle ep0. As a result, fuzz testing can generate a WARNING
like the following:
WARNING: CPU: 0 PID: 4410 at drivers/usb/gadget/udc/dummy_hcd.c:672
dummy_fr
Based on the musb ug, force_host bit is allowed to be set along with
force_hs or force_fs bit.
It could help to implement forced host mode via testmode on Nokia N900.
Signed-off-by: Pali Rohár
---
drivers/usb/musb/musb_debugfs.c | 44 +--
1 file changed, 28
On Wed, 2016-12-14 at 11:36 -0500, Alan Stern wrote:
> On Wed, 14 Dec 2016, Todd Brandt wrote:
>
> > Add a kernel parameter that replaces the USB_RESUME_TIMEOUT
> > and other hardcoded delay numbers with the USB spec minimums.
> >
> > The USB subsystem currently uses heavily padded values for TDR
Andy Lutomirski wrote:
> David, are these encrypted keys ever exported anywhere? If not, could
> the code use a mode that doesn't need padding?
ecryptfs uses them, I think.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.
On Tue, Dec 13, 2016 at 08:40:00AM -0800, Andy Lutomirski wrote:
> But I think this is rather silly. Joerg, Linus, etc: would it be okay
> to change lib/dma-debug.c to allow DMA *from* rodata?
Yeah, this would be fine for DMA_TO_DEVICE mappings. At least I can't
think of a reason right now to not
On Wed, 2016-12-14 at 10:33 -0500, Alan Stern wrote:
> On Wed, 14 Dec 2016, Todd Brandt wrote:
>
> > add debugfs support for experimenting with USB timing delay
> > values on the fly. Values are read/written from debugfs at
> > /sys/kernel/debug/usb/timing.
> >
> > Signed-off-by: Todd Brandt
> >
On Wed, Dec 14, 2016 at 03:47:57PM +0100, Pali Rohár wrote:
> Signed-off-by: Pali Rohár
> ---
> drivers/usb/musb/musb_debugfs.c | 44
> +--
> 1 file changed, 28 insertions(+), 16 deletions(-)
I don't accept patches without any changelog information, nor wou
On Wed, 14 Dec 2016, Michal Hocko wrote:
> On Tue 13-12-16 08:33:34, Alan Stern wrote:
> > On Tue, 13 Dec 2016, Michal Hocko wrote:
> >
> > > > > That being said, what ep_write_iter does sounds quite stupit. It just
> > > > > allocates a large continuous buffer which seems to be under user
> > >
On Wed, 14 Dec 2016, Todd Brandt wrote:
> Add a kernel parameter that replaces the USB_RESUME_TIMEOUT
> and other hardcoded delay numbers with the USB spec minimums.
>
> The USB subsystem currently uses heavily padded values for TDRSMDN
> and TRSTRCY. This patch keeps the current values by defaul
On Wed, Dec 14, 2016 at 12:37 AM, David Howells wrote:
> Andy Lutomirski wrote:
>
>> > - sg_set_buf(&sg_out[1], pad, sizeof pad);
>> > + sg_set_buf(&sg_out[1], empty_zero_page, 16);
>>
>> My fix here is obviously bogus (I meant to use ZERO_PAGE(0)), but what
>> exactly is the code try
On Wed 14-12-16 11:13:11, Alan Stern wrote:
> On Wed, 14 Dec 2016, Michal Hocko wrote:
>
> > On Tue 13-12-16 08:33:34, Alan Stern wrote:
> > > On Tue, 13 Dec 2016, Michal Hocko wrote:
[...]
> > > > Well, my point was that it is not really hard to imagine to deplete
> > > > larger contiguous memory
Hi Krzysztof,
Thanks for the patch.
On 12/13/2016 12:52 PM, Krzysztof Opasiak wrote:
> Update README file:
> - remove outdated parts
> - clarify terminology and general structure
> - add some description of vUDC
>
> Signed-off-by: Krzysztof Opasiak
> ---
> tools/usb/usbip/README | 56
> ++
On Tue, 13 Dec 2016, Mateusz Berezecki wrote:
> Promote a variable keeping track of USB transfer memory usage to a
> wider data type and allow for higher bandwidth transfers from a large
> number of USB devices connected to a single host.
>
> Signed-off-by: Mateusz Berezecki
> ---
...
> /* Ch
On Wednesday 14 December 2016 16:34:31 Tony Lindgren wrote:
> * Pali Rohár [161214 06:48]:
>
> We need this because and this allows debugging problems related
> to ...?
Hi! We have already discussion about it, search for older email with
Message-Id: <201601231357.32629@pali>
After that in
* Pali Rohár [161214 07:40]:
> On Wednesday 14 December 2016 16:34:31 Tony Lindgren wrote:
> > * Pali Rohár [161214 06:48]:
> >
> > We need this because and this allows debugging problems related
> > to ...?
>
> Hi! We have already discussion about it, search for older email with
> Messag
Make sure to stop the interrupt URB before returning on errors during
open.
Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CTS")
Cc: stable
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ch341.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --g
A recent change added support for modifying the default line-control
settings, but did not make sure that the modified settings were used as
part of reconfiguration after a device has been reset during resume.
This caused a port that was open before suspend to be unusable until
being closed and re
* Pali Rohár [161214 06:48]:
We need this because and this allows debugging problems related to
...?
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/ma
On Wed, 14 Dec 2016, Todd Brandt wrote:
> add debugfs support for experimenting with USB timing delay
> values on the fly. Values are read/written from debugfs at
> /sys/kernel/debug/usb/timing.
>
> Signed-off-by: Todd Brandt
> ---
> v2 changes:
> - moved the debug code from hub.c to usb.c
> -
On Mon, Dec 12, 2016 at 04:15:29PM -0800, Russell Senior wrote:
> On Mon, Dec 12, 2016 at 10:19 AM, Johan Hovold wrote:
> > Can you try also the below diagnostics patch on top of usb-next (not
> > usb-linus this time)?
> >
> > It seems we should be able to revert to setting the divisors and lcr
>
Rename the shadow modem-control register currently named "line_control"
to the less confusing "mcr".
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ch341.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/serial/ch341.c b/drivers/
A short control transfer would currently fail to be detected, something
which could lead to stale buffer data being used as valid input.
Check for short transfers, and make sure to log any transfer errors.
Fixes: 6ce76104781a ("USB: Driver for CH341 USB-serial adaptor")
Signed-off-by: Johan Hovol
Fix reset-resume handling which failed to resubmit the read and
interrupt URBs, thereby leaving a port that was open before suspend in a
broken state until closed and reopened.
Fixes: 1ded7ea47b88 ("USB: ch341 serial: fix port number changed after
resume")
Fixes: 2bfd1c96a9fb ("USB: serial: ch341:
Some CH341 devices appear to require the use of the init vendor command
to set the baud rate and line-control register. Specifically, while
using direct register updates for speed and LCR seem to update those
settings correctly, not using the init command causes received data to
be buffered until a
Clean up the control-transfer debug messages by dropping redundant
information and unnecessary casts.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ch341.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/serial/ch341.c b/drivers/usb/serial/ch341.c
in
The modem-status register was read as part of device configuration at
port_probe and then again at open (and reset-resume). During open (and
reset-resume) the MSR was read before submitting the interrupt URB,
something which could lead to an MSR-change going unnoticed when it
races with open (reset
The ch341 driver is based on reverse-engineering and contains some bits
which appear to be redundant and some which appear incompatible which
certain devices.
Specifically, some CH340 devices seem unable to change the initial line
settings, which have so far been set to 5N1. Let's use a more reaso
Rename the shadow modem-status register currently named "line_status" to
the less confusing "msr".
Also rename the helper function used to parse the interrupt data.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ch341.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
DTR and RST will be asserted by the tty-layer when the port is opened
and deasserted on close (if HUPCL is set). Make sure the initial state
is not-asserted before the port is first opened as well.
Fixes: 6ce76104781a ("USB: Driver for CH341 USB-serial adaptor")
Cc: stable
Signed-off-by: Johan Ho
The modem-control signals are managed by the tty-layer during open and
should not be asserted prematurely when set_termios is called from
driver open.
Also make sure that the signals are asserted only when changing speed
from B0.
Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CT
This series fixes a number of problems with the ch341 driver, and adds
support for a class of CH340 devices which does not seem to support
the new method of configuring the line settings (using the init vendor
command).
These patches have been verified against CH340G and CH341A, but I need
help wi
The private baud_rate variable is used to configure the port at open and
reset-resume, which means it must never be set to (and left at) zero or
reset-resume and all further open attempts will fail.
Fixes: 664d5df92e88 ("USB: usb-serial ch341: support for DTR/RTS/CTS")
Cc: stable
Signed-off-by: J
Signed-off-by: Pali Rohár
---
drivers/usb/musb/musb_debugfs.c | 44 +--
1 file changed, 28 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c
index 9b22d94..62c13a2 100644
--- a/drivers/usb/musb/musb
If CONFIG_PM=n:
drivers/usb/core/hub.c:107: warning: ‘hub_usb3_port_prepare_disable’
declared inline after being called
drivers/usb/core/hub.c:107: warning: previous declaration of
‘hub_usb3_port_prepare_disable’ was here
To fix this, move hub_port_disable() after
hub_usb3_port_prepare_
On 14.12.2016 12:58, Michal Necasek wrote:
prior to the endpoint reset. SetFeature(CLEAR_HALT) resets the toggle
on the device, but not on the host. But we know for a fact that the
device sends a packet (with data toggle 0) which the host USB stack
never sees, and a data toggle mismatch explains
Mathias Nyman writes:
> On 14.12.2016 01:40, OGAWA Hirofumi wrote:
>> ping about [PATCH 1/3, 2/3, 3/3]?
>>
>
> 1/3 and 2/3 will be sent to 4.10 usb-linus after rc1,
> 3/3 maybe to usb-next after that
Thanks.
--
OGAWA Hirofumi
--
To unsubscribe from this list: send the line "unsubscribe linux-u
On 14.12.2016 01:40, OGAWA Hirofumi wrote:
ping about [PATCH 1/3, 2/3, 3/3]?
1/3 and 2/3 will be sent to 4.10 usb-linus after rc1,
3/3 maybe to usb-next after that
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kern
The USB resume code in the kernel currently uses a set of hard coded
delay values that are defined in the USB 2.0 spec. Specifically these
three have the most effect on resume time:
- tdrsmdn: resume signal time (20ms - infinity) usb 2.0 spec 7.1.7.7
- trsmrcy: resume recovery time (10ms) usb 2.
Add a kernel parameter that replaces the USB_RESUME_TIMEOUT
and other hardcoded delay numbers with the USB spec minimums.
The USB subsystem currently uses heavily padded values for TDRSMDN
and TRSTRCY. This patch keeps the current values by default, but if
the kernel is booted with usb_timing_mini
add debugfs support for experimenting with USB timing delay
values on the fly. Values are read/written from debugfs at
/sys/kernel/debug/usb/timing.
Signed-off-by: Todd Brandt
---
v2 changes:
- moved the debug code from hub.c to usb.c
- use debugfs instead of /sys/kernel/usb
drivers/usb/core/
Hi!
On 17/11/16 12:43, Sriram Dash wrote:
> From: Arnd Bergmann
>
> For xhci-hcd platform device, all the DMA parameters are not
> configured properly, notably dma ops for dwc3 devices.
>
> The idea here is that you pass in the parent of_node along with
> the child device pointer, so it would b
Hi,
Jerry Huang writes:
> hi, Balbi,
> sorry to disturb you.
>
> some NXP platforms need dma-coherent property.
>
> I want to add "dma-coherent" into usb node in DTS file like other
> platform done
> (e.g. arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi).
>
> Could you please give some comme
With gcc 4.1.2:
drivers/usb/serial/f81534.c: In function ‘f81534_port_probe’:
drivers/usb/serial/f81534.c:1250: warning: comparison is always false due
to limited range of data type
f81534_logic_to_phy_port() may return a negative error value, which is
ignored by assigning it to u8 f8153
Hi Mathias,
We have run into a problem with a USB printer which we're quite confident is a
bug in the Linux xHCI driver. There is no problem when the same printer is
plugged into a port managed by the EHCI driver.
The core problem is that xhci_reset_endpoint() doesn't do anything, and mo
On Tue 13-12-16 08:33:34, Alan Stern wrote:
> On Tue, 13 Dec 2016, Michal Hocko wrote:
>
> > > > That being said, what ep_write_iter does sounds quite stupit. It just
> > > > allocates a large continuous buffer which seems to be under user
> > > > control... Aka no good! It should do that per pag
Andy Lutomirski wrote:
> > - sg_set_buf(&sg_out[1], pad, sizeof pad);
> > + sg_set_buf(&sg_out[1], empty_zero_page, 16);
>
> My fix here is obviously bogus (I meant to use ZERO_PAGE(0)), but what
> exactly is the code trying to do? The old code makes no sense. It's
> setting the *o
merged into cifs-2.6.git for-next
On Tue, Dec 13, 2016 at 7:07 AM, Jeff Layton wrote:
> On Mon, 2016-12-12 at 12:54 -0800, Andy Lutomirski wrote:
>> smbencrypt() points a scatterlist to the stack, which is breaks if
>> CONFIG_VMAP_STACK=y.
>>
>> Fix it by switching to crypto_cipher_encrypt_one().
On 12/14/2016 6:25 AM, John Stultz wrote:
> On Tue, Dec 13, 2016 at 3:51 PM, John Youn wrote:
>> On 12/13/2016 3:23 PM, John Stultz wrote:
>>> I've found trying to boot Linus' HEAD today on HiKey, I'm hitting the
>>> following WARNINGS/panics, which I bisected down to being introduced
>>> with 5f5
On Wed, Dec 14, 2016 at 01:04:04PM +0800, Herbert Xu wrote:
> On Tue, Dec 13, 2016 at 06:53:03PM -0800, Andy Lutomirski wrote:
> > On Tue, Dec 13, 2016 at 6:48 PM, Andy Lutomirski wrote:
> > > The driver put a constant buffer of all zeros on the stack and
> > > pointed a scatterlist entry at it in
Hi Todd,
[auto build test ERROR on linus/master]
[also build test ERROR on next-20161214]
[cannot apply to usb/usb-testing balbi-usb/next v4.9]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits
54 matches
Mail list logo
