RE: [RFCv2 00/10] xhci: re-work command queue management

From: Dan Williams > Yes, but I think we need to centralize the context under which > commands are submitted. The complicating factor is the mix of > synchronous command submission and interrupt driven asynchronous > command queuing. I think we can simplify it by making it all > submitted from a

RE: [PATCH v3] tools: usb: aio example applications

From: Michal Nazarewicz > On Tue, Feb 04 2014, Robert Baldyga wrote: > > This code is an example. Don't you think it would be better to keep it > > simple? > > PS. Of course another approach is to use two threads one for ep0 and the > other for transfers. Yet another, is to add AIO to ep0 in the

RE: xhci and other woes

From: Sarah> Sharp > On Wed, Feb 05, 2014 at 09:44:20AM +, David Laight wrote: > > From: Mark Lord > > > >> Which means that the controller is obeying the rules, and the software > > > >> is wrong. > > > .. > > > > In this

RE: [PATCH] net: asix: fix bad header length bug

From: Emil Goode > The AX88772B occasionally send rx packets that cross urb boundaries > and the remaining partial packet is sent with no header. > When the buffer with a partial packet is of less number of octets > than the value of hard_header_len the buffer is discarded by the > usbnet module. T

RE: [PATCH] net: asix: fix bad header length bug

From: Igor Gnatenko > On Thu, 2014-02-06 at 13:56 +0100, Emil Goode wrote: > > The AX88772B occasionally send rx packets that cross urb boundaries > > and the remaining partial packet is sent with no header. > > When the buffer with a partial packet is of less number of octets > > than the value of

RE: AX88179_178A USB3 ethernet adapter performance issue

From: Daniel J Blueman > Hi Freddy et al, I've copied this to linux-usb. > I'm experiencing poor network performance using an ASIX AX88179_178A > USB3 to ethernet adapter using any recent linux kernel (eg 3.11), > using an Intel XHCI USB3 controller. There a several problems with the xhci driver

RE: AX88179_178A USB3 ethernet adapter performance issue

From: Sarah Sharp > > I have seem line rate Ge from my ax88179 card, but only with a > > patched kernel. > > David, did you mean you have the same line rate as Daniel? No I meant I've seen it saturate a Ge link (with sufficiently large frames). With very small frames the tx rate gets limited to

RE: [PATCH] net: asix: fix bad header length bug

From: Emil Goode > On Fri, Feb 07, 2014 at 10:38:04AM +0100, Bjørn Mork wrote: > > Emil Goode writes: > > > On Thu, Feb 06, 2014 at 03:28:13PM +, David Laight wrote: > > >> From: Igor Gnatenko > > >> > On Thu, 2014-02-06 at 13:56 +0100, Emil Good

RE: USB/IP

From: Peter Stuge > konst...@ngs.ru wrote: > > If so, which linux distro is worth being chosen for > > building and testing that custom kernel and, especially, > > usbip, in particular, and does distro really matter? > > It depends on how much "value add" the distribution has around the > kernel.

RE: [PATCH 1/2 v2] usbnet: fix bad header length bug

From: Oliver Neukum > . Oh well. But how about merging it with FLAG_MULTI_PACKET? > I really don't want to add more flags. There is a point where enough > flags make absurd having a common code. We are closing in on that point. Any sub-driver that supports multi-packet either has to use stupidly l

RE: USB/IP

From: Greg KH > > I found it much easier to build a non-initrd kernel (ie one that > > has all the devices needed to boot builtin) than to work out > > how to build one that contains an initrd image. > > Then you are using the wrong distro, as a simple 'make install' in the > kernel directory shou

RE: Large disk drives

From: Boaz Harrosh > On 11/06/2014 05:53 PM, Alan Stern wrote: > >> But just the simple case of read-capacity failure should we then? > > > > That's a separate question. As far as I know, the case you are > > describing has not come up. > > > > BTW: what we should do is when the partition parser

RE: Large disk drives

From: Norman Diamond ... > By the way, I've seen some USB bridges that lie about whether they > performed various SAT commands (ATA passthrough), but told the truth > about performing an ATA IDENTIFY DEVICE through SAT.  So we could attempt > ATA passthrough with an IDENTIFY DEVICE command, and if

RE: [PATCHv2 1/4] xhci: don't start a halted endpoint before its new dequeue is set

From: Mathias Nyman > A halted endpoint ring must first be reset, then move the ring > dequeue pointer past the problematic TRB. If we start the ring too > early after reset, but before moving the dequeue pointer we > will end up executing the same problematic TRB again. > > As we always issue a s

RE: [PATCH 4/4] usb: xhci: rework root port wake bits if controller isn't allowed to wakeup

From: Felipe Balbi > > On Fri, Nov 14, 2014 at 07:23:52PM +0200, Mathias Nyman wrote: > > From: Lu Baolu > > > > When system is being suspended, if host device is not allowed to do wakeup, > > xhci_suspend() needs to clear all root port wake on bits. Otherwise, some > > platforms may generate spu

RE: [RFC PATCH] usb: musb: cppi41: replace TX-complete-timer by TX-FIFO-EMPTY interrupt

From: Sebastian Andrzej Siewior > The TX-interrupt fires (sometimes) too early and therefore we have the > early_tx timer to check periodically if the transfer is done. Initially > I started I started with a 150us delay which seemed to work well. > This value was reduced further, because depending

RE: [PATCH] usb: hcd: get/put device and hcd for hcd_buffers()

From: Greg Kroah-Hartman > On Fri, Dec 05, 2014 at 09:03:57PM +0100, Sebastian Andrzej Siewior wrote: > > Consider the following scenario: > > - plugin a webcam > > - play the stream via gst-launch-0.10 v4l2src device=/dev/video0 > > - remove the USB-HCD during playback via "rmmod $HCD" > > > > and

RE: [PATCH 0/4] phy: samsung-usb2: Add support for Vbus regulator

From: Vivek Gautam > This has been on my to-do list for sometime. > Until now the host controller (specifically ehci-exynos) is responsible > for enabling VBUS supply. This opens up one more issue which is, when > only ohci-exynos is enabled and ehci-exynosis disabled then VBUS was > never enabled

RE: [PATCH 4/4] usb: atmel_usba_udc: mask status with enabled irqs

From: Sergei Shtylyov > Hello. > > On 12/15/2014 4:03 PM, Boris Brezillon wrote: > > > Avoid interpreting useless status flags when we're not waiting for such > > events by masking the status variable with the interrupt enabled register > > value. > > > Reported-by: Patrice VILCHEZ > > Signed-o

RE: [PATCH 4/4] usb: atmel_usba_udc: mask status with enabled irqs

From: Boris Brezillon > Hi David, > > On Mon, 15 Dec 2014 13:34:56 +0000 > David Laight wrote: > > > From: Sergei Shtylyov > > > Hello. > > > > > > On 12/15/2014 4:03 PM, Boris Brezillon wrote: > > > > > > > Avoid interpretin

RE: [PATCH] usb/musb: debugfs, fix copy_from_user argument

From: Markus Pargmann > The first arugment has to be a pointer to the memory. buf is a char > array and already a pointer itself. The current code passes a pointer to > a char array to copy_from_user() which is not correct. It doesn't matter, while the type of the argument is subtly different the

RE: [PATCH] usbnet: remove generic hard_header_len check

From: Emil Goode > > > int rndis_rx_fixup(struct usbnet *dev, struct sk_buff *skb) > > > { > > > + /* This check is no longer done by usbnet */ > > > + if (skb->len < dev->net->hard_header_len) > > > + return 0; > > > + > > > > Wouldn't it be better to test against ETH_HLEN, since that is

RE: [PATCH v2] usbnet: remove generic hard_header_len check

From: Of Emil Goode > This patch removes a generic hard_header_len check from the usbnet > module that is causing dropped packages under certain circumstances > for devices that send rx packets that cross urb boundaries. > > One example is the AX88772B which occasionally send rx packets that > cro

RE: [EHCI Debug Port] Linux fails to setup EHCI debug port

> It is quite possible that the debug port on this motherboard is not > wired to a USB connector. If that's true, the only way you will get > the debug device to work is by connecting it directly to a header on > the motherboard. Is that likely to be the single USB header on many motherboards?

RE: sisusb: Use static const, fix typo

From: Joe Perches > Reduce text a bit by using static const. If you want to save a few bytes remove the pointers. (and the fixed RAM text to get below 7 chars). eg: > - const char *ramtypetext2[] = { "SDR SDRAM", "SDR SGRAM", > - "DDR SDRAM", "DDR SGRAM" }

RE: sisusb: Use static const, fix typo

From: Joe Perches [ > On Mon, 2014-02-24 at 10:26 +0000, David Laight wrote: > > From: Joe Perches > > > Reduce text a bit by using static const. > > > > If you want to save a few bytes remove the pointers. > > (and the fixed RAM text to get belo

RE: [PATCH] net/usb: Add Lenovo ThinkPad OneLink GigaLAN USB ID to ax88179 driver

From: Keith Packard > The Lenovo OneLink dock includes a USB ethernet adapter using the > AX88179 chip, but with a different USB ID. Add this new USB id to the > driver so that it will autodetect the adapter correctly. > > Signed-off-by: Keith Packard > Tested-by: Carl Worth > --- > drivers/net

RE: 3.13-rc1 regression: Scatter-gather list issues at SuperSpeed only

From: Alan Stern > > When testing 3.14-rc1 with a USB 3.0 Lexar flash drive, the drive fails > > to be mounted. ... > > That revealed the SCSI request fails because the USB core is rejecting a > > scatter-gather list with an entry that isn't aligned to the max packet size: > > > Feb 28 09:45:30 xa

ax88179_178a problems on AMD platform with ASMedia xhci controller

I've just installed the latest 3.14.0-rc5 kernel on an AMD box that has the ASMedia 1042 xhci controller and an ASX ax88179 USB3 Ge card. This is still working as badly as it did last time I tried it. (When I added a lot of diagnostics to try to find out what was wrong.) When I ran 'ifconfig eth1

RE: 3.13-rc1 regression: Scatter-gather list issues at SuperSpeed only

From: Sarah Sharp > Greg, Dave, Freddy, question about cross-subsystem reverts below: > > On Fri, Feb 28, 2014 at 04:15:12PM -0500, Alan Stern wrote: > > On Fri, 28 Feb 2014, Sarah Sharp wrote: > > > > > When testing 3.14-rc1 with a USB 3.0 Lexar flash drive, the drive fails > > > to be mounted.

RE: some question about xhci TRB_INTR_TARGET

From: vichy > hi all: > from xhci spec, Interrupter Target is the value between 0 and MaxIntrs-1. > But why the parameter pass to TRB_INTR_TARGTRB_INTR_TARGET is always 0. > > Does that mean so far xhci host didn't support multi-interrupt as > MSI-X suggested? AFAIK The Linux USB stack doesn't su

RE: [PATCH net-next 08/12] r8152: support TSO

From: Hayes Wang > Support scatter gather and TSO. > > Adjust the tx checksum function and set the max gso size to fix the > size of the tx aggregation buffer. There is little point supporting TSO unless the usb host controller supports arbitrary aligned scatter-gather. All you do is require that

RE: [PATCH net-next 08/12] r8152: support TSO

From: hayeswang > David Laight [mailto:david.lai...@aculab.com] > > Sent: Tuesday, March 04, 2014 8:12 PM > > To: 'Hayes Wang'; net...@vger.kernel.org > > Cc: nic_s...@realtek.com; linux-ker...@vger.kernel.org; > > linux-usb@vger.kernel.org > > Subject

RE: 3.13-rc1 regression: Scatter-gather list issues at SuperSpeed only

From: Bjørn Mork > > If xHCI won't plan to support arbitrary-length scatter-gather any more, that > > is fine to revert the commit forever. Otherwise, it should be better to > > just > > clear no_sg_constraint in xhcd, shouldn't it? > > No, that's what's currently causing bugs with the storage d

RE: [PATCH net-next 08/12] r8152: support TSO

From: Eric Dumazet > On Tue, 2014-03-04 at 14:35 +0000, David Laight wrote: > > > Does that mean you are splitting the 64k 'ethernet packet' from TCP > > is software? I've looked at the ax88179 where the hardware can do it. > > > > Is there really a g

RE: ax88179_178a problems on AMD platform with ASMedia xhci controller

From: renev...@internode.on.net > Not only that though, I moved to a SandyBridge platform and... > The nic stops working very quickly when using an onboard Etron controller. > The nic also stops working quickly when using an addon card with Renesas > controller. What I found was that the nic's tr

RE: 3.13-rc1 regression: Scatter-gather list issues at SuperSpeed only

From: Alan Stern > There are only two reasonable ways to fix this: Add appropriate TRB > fragment handling into xhci-hcd, or use bounce buffers for non-aligned > requests. > > In theory the block layer could be taught about the need for these > bounce buffers, but that would be only a partial solu

RE: 3.13-rc1 regression: Scatter-gather list issues at SuperSpeed only

From: Sarah Sharp ... > The block layer may submit scatter-gather lists with entries that > are multiples of 512-byte blocks. That's fine for USB 2.0 devices, > where the bulk endpoint max packet size is 512 bytes. But USB 3.0 > devices have bulk endpoints with a 1024 byte max packet size. > > T

RE: ax88179_178a problems on AMD platform with ASMedia xhci controller

From: Of David Laight > I've just installed the latest 3.14.0-rc5 kernel on an AMD box that > has the ASMedia 1042 xhci controller and an ASX ax88179 USB3 Ge card. > > This is still working as badly as it did last time I tried it. > (When I added a lot of diagnostics to try

RE: [PATCH 2/2] Revert "USBNET: ax88179_178a: enable tso if usb host supports sg dma"

From: Mathias Nyman > This reverts commit 3804fad45411b48233b48003e33a78f290d227c8. > > This commit, together with commit 247bf557273dd775505fb9240d2d152f4f20d304 > "xhci 1.0: Limit arbitrarily-aligned scatter gather." were > origially added to get xHCI 1.0 hosts and usb ethernet ax88179_178a devi

RE: [PATCH 1/2] Revert "xhci 1.0: Limit arbitrarily-aligned scatter gather."

From: Mathias Nyman > This reverts commit 247bf557273dd775505fb9240d2d152f4f20d304. You need to revert further. Just don’t set hcd->self.no_sg_constraint ever - since it just doesn't work. That will stop the ax88179_178a driver sending fragmented packets. With the check for aligned non-terminal f

RE: [PATCH 33/76] uas: Pack iu struct definitions

From: Of Sarah Sharp > From: Hans de Goede > > The iu struct definitions are usb packet definitions, so no alignment should > happen. Notice that assuming 32 bit alignment this does not make any > difference at all. > > Signed-off-by: Hans de Goede > Signed-off-by: Sarah Sharp > --- > include

RE: [PATCH 2/2] Revert "USBNET: ax88179_178a: enable tso if usb host supports sg dma"

From: Alan Stern > On Fri, 7 Mar 2014, David Laight wrote: > > > From: Mathias Nyman > > > This reverts commit 3804fad45411b48233b48003e33a78f290d227c8. > > > > > > This commit, together with commit 247bf557273dd775505fb9240d2d152f4f20d304 > > &

RE: [PATCH 1/2] Revert "xhci 1.0: Limit arbitrarily-aligned scatter gather."

From: Alan Stern > On Fri, 7 Mar 2014, David Laight wrote: > > > From: Mathias Nyman > > > This reverts commit 247bf557273dd775505fb9240d2d152f4f20d304. > > > > You need to revert further. > > Just don?t set hcd->self.no_sg_constraint ever - since it ju

RE: [PATCH 2/2] Revert "USBNET: ax88179_178a: enable tso if usb host supports sg dma"

From: > On Fri, 7 Mar 2014, David Laight wrote: > > > From: Alan Stern > > > On Fri, 7 Mar 2014, David Laight wrote: > > > > > > > From: Mathias Nyman > > > > > This reverts commit 3804fad45411b48233b48003e33a78f290d227

RE: MAX3421E: device giving NAKs forever?

From: Felipe Balbi > On Mon, Mar 10, 2014 at 02:15:36PM -0600, David Mosberger wrote: > > I was thinking of the Salea Logic ($150). > > Are you aware of any limitations for this one that would get in the way? > > for full-speed USB it should work, I guess. Never trie

RE: [PATCH 3/3] usb: phy-fsm: change "|" to "||" for condition OTG_STATE_A_WAIT_BCON at statemachine

From: Peter Chen > It is should be condition "or" not bit "or". > > Signed-off-by: Peter Chen > --- > drivers/usb/phy/phy-fsm-usb.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/usb/phy/phy-fsm-usb.c b/drivers/usb/phy/phy-fsm-usb.c > index 0021839..bf5c3

RE: [PATCH net-next v2 1/2] r8152: add RTL8152_EARLY_AGG_TIMEOUT_SUPER

From: Hayes Wang > For slow CPU, the frequent bulk transfer would cause poor throughput. > One solution is to increase the timeout of the aggregation. It let > the hw could complete the bulk transfer later and fill more packets > into the buffer. Besides, it could reduce the frequency of the bulk >

RE: [PATCH net-next v3 1/2] r8152: add RTL8152_EARLY_AGG_TIMEOUT_SUPER

From: Hayes Wang ... I should have spotted this before. > /* USB_RX_EARLY_AGG */ > -#define EARLY_AGG_SUPPER 0x0e832981 > +#define EARLY_AGG_SUPER rx_buf_sz - 1522) / 4) << 16) | \ > + (u32)(CONFIG_RTL8152_EARLY_AGG_TIMEOUT_SUPER <= 0 ? 85 * 125 : \ > + min(CONFIG_RTL8152_EA

RE: [PATCH 3/6] libusbg: Remove fixed-size buffers from usbg_config.

From: Krzysztof Opasiak > Path and name length should not be placed in constant > size buffer but in allocated memory. > > Use also PATH_MAX macro from limits.h instead of internal > library macro. There might be some sense in keeping USBG_MAX_PATH_LENGTH but defaulting to PATH_MAX. ... > -

RE: usbnet OOM handling - possible CPU starvation?

From: Bjørn Mork > Hello Oliver & other clueful gurus! > > I started looking at how to improve the OOM handling in usbnet, but have > to admit that this is way over my head. I don't think I dare touching > it... > > I've seen a few reports clearly showing that we do have a problem. One > example

RE: [PATCH] staging: octeon-usb: prevent memory corruption

From: Aaro Koskinen > octeon-hcd will crash the kernel when SLOB is used. This usually happens > after the 18-byte control transfer when a device descriptor is read. > The DMA engine is always transfering full 32-bit words and if the > transfer is shorter, some random garbage appears after the buff

RE: usb 3.0 problems with NEC Controller

From: Of Sarah Sharp > Cc'ing Mathias Nyman, who is taking over as xHCI driver maintainer. Do you need to repost these mails to the list just so that Mathias gets a private copy? Maybe Mathias could filter mails to linux_usb@ that are also addressed to Sarah into his 'interesting' emails folder.

RE: [PATCH 2/5] libusbg: Fix wrong malloc sizes in allocate functions.

From: Krzysztof Opasiak > Functions usbg_allocate_function() and usbg_allocate_binding() > had allocated sizeof(usbg_config) instead of usbg_function > and usbg_binding. ... > usbg_function *f; > > - f = malloc(sizeof(usbg_config)); > + f = malloc(sizeof(usbg_function)); Use the muc

RE: [PATCH 4/5] libusbg: Replace usage of function name with type and instance.

From: Opasiak > User of library should not use directly function name but > only type of the function and name of instance. Using this > will separate user for naming convention on Config FS. Personally I'd have thought it much better to pass in a string name rather than a function number. Far les

RE: Fwd: Isochronos audio

From: Alan Stern ... > Furthermore, I clearly recall Sarah Sharp (the original maintainer for > xhci-hcd) saying that the support for isochronous transfers needed > attention. This may well be an example. You also definitely don't want to cancel an isoc urb. Doing so is likely to corrupt the kern

RE: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'

From: Sergei Shtylyov > It doesn't do any pin muxing. It switches SoC internal USB signals between > USB controllers. The pins remain the same. Doesn't something like that already happen for the companion USB1 controllers for USB2 ports? That also doesn't sound like you are changing the PHY.

RE: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'

From: Ben Dooks > On 10/04/14 11:49, Sergei Shtylyov wrote: > > On 10-04-2014 13:20, David Laight wrote: > > > >>> It doesn't do any pin muxing. It switches SoC internal USB > >>> signals between > >>> USB controllers. The pins remai

RE: [PATCH] USB: io_ti: fix firmware download on big-endian machines

From: Johan Hovold > During firmware download the device expects memory addresses in > big-endian byte order. As the wIndex parameter which hold the address is > sent in little-endian byte order regardless of host byte order, we need > to use swab16 rather than cpu_to_be16. That doesn't sound corr

RE: [PATCH 2/3] usb: dwc3: gadget: pretty print link states

From: Felipe Balbi ... > +static const char *dwc3_gadget_link_string(enum dwc3_link_state link_state) > +{ > + switch (link_state) { > + case DWC3_LINK_STATE_U0: > + return "U0"; > + case DWC3_LINK_STATE_U1: > + return "U1"; > + case DWC3_LINK_STATE_U2: > +

RE: [PATCH v8 08/18] usb: make usb_port flags atomic

From: Dan Williams > Before we add another 2 bitfields to the port state, convert it to an > unsigned long and use bitops helpers to manipulate it. This later > enables setting bits to request action without worrying about colliding > updates. In particular, a flag to request that the child devic

RE: [RFC 0/9] cdc_ncm: add buffer tuning and stats using ethtool

From: Bjørn Mork > I have got quite a few reports from frustrated users of OpenWRT > hosts trying to use some powerful LTE modem, but not achieving > full speed. This is typically caused by a combination of > big buffers and little memory, giving in allocation errors and > bad performance as a res

RE: [PATCH/RFC] usb: gadget: CONFIG_USB_S3C_HSOTG should depend on HAS_DMA

From: Geert Uytterhoeven > If NO_DMA=y: > > drivers/built-in.o: In function `s3c_hsotg_map_dma': > s3c-hsotg.c:(.text+0x375b2c): undefined reference to `usb_gadget_map_request' > drivers/built-in.o: In function `s3c_hsotg_unmap_dma': > s3c-hsotg.c:(.text+0x376a32): undefined reference to > `usb_g

RE: [PATCH 03/10] usb: catch attempts to submit urbs with a vmalloc'd transfer buffer

From: Mathias Nyman > From: Dan Williams > > Save someone else the debug cycles of figuring out why a driver's > transfer request is failing or causing undefined system behavior. > Buffers submitted for dma must come from GFP allocated / DMA-able > memory. > > Return -EAGAIN matching the return

RE: xhci dmesg flood on short packet

From: Of Parag Warudkar > I see a continuous flood of below messages on plugging in/using my USB > token. (The comp code wasn't in the original message - I added it.) From > what I can tell the device continues to work as expected. > > Should the warning be disabled for COMP_SHORT_TX like it is fo

RE: [PATCH 3/5] usb: gadget: net2280: Use BIT() macro

From: Ricardo Ribalda Delgado > Improves readability of the code Personally I don't find macros like BIT() improve the readability at all. What next? Maybe: #define ADD(a, b) ((a) + (b)) David -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a mes

RE: [PATCH 3/5] usb: gadget: net2280: Pass checkpacth.pl test

From: Alan Stern ... > > -static struct usb_request * > > -net2280_alloc_request (struct usb_ep *_ep, gfp_t gfp_flags) > > +static struct usb_request *net2280_alloc_request(struct usb_ep *_ep, > > + gfp_t gfp_flags) > > What's with the extreme inde

RE: ASMedia AS2105 interface on USB 3.0 corrupts data

From: Alan Stern > On Thu, 22 May 2014, Heinz Diehl wrote: > > > On 21.05.2014, Alan Stern wrote: > > > > > In that case, I have no idea what else could be causing the problem. > > > > Thanks for your efforts! > > > > If somebody of the developers is interested in debugging this, I'm > > willi

RE: skbuff truesize incorrect.

From: Eric Dumazet > On Thu, 2014-05-22 at 20:07 +0100, Jim Baxter wrote: > > > > > I have been investigating a network issue with bursts of network traffic > > over USB CDC-NCM, the issue is that the kernel is dropping packets > > because sk_rcvqueues_full() returns true due to skb2->truesize is

RE: skbuff truesize incorrect.

From: Jim Baxter > On 22/05/14 21:58, David Miller wrote: > > From: Jim Baxter > > Date: Thu, 22 May 2014 21:21:55 +0100 > > > >> If there are multiple clones for an skb all pointing at the same data, > >> will that distort the memory used when they all have the same truesize? > > > > What is dist

RE: skbuff truesize incorrect.

From: Bjørn Mork [mailto:bj...@mork.no] > David Laight writes: ... > > Note that some of the usb ethernet drivers allocate large skb then > > lie about the truesize. > > Hmm, which drivers are these? $ grep truesize linux/drivers/net/usb/* asix_88179_178a, smsc95xx, sr9700. David

RE: skbuff truesize incorrect.

From: Eric Dumazet ... > TCP stack uses fast clones, and current stack gives them a truesize of > 2048 + sizeof(sk_buff), while it really should be 2048 + > 2*sizeof(sk_buff) > > Luckily, GSO/TSO tends to reduce the error, as skbs overhead is lower. Doesn't that affect the tx side - where the tru

RE: skbuff truesize incorrect.

From: David Miller > From: David Laight > Date: Fri, 23 May 2014 08:52:13 + > > > The hardware will put multiple ethernet frames into a single USB bulk data > > message. To handle this the driver generates a URB that is (hopefully) long > > enough for the longest

RE: [PATCH v2 net-next 3/8] net: cdc_ncm: inform usbnet when rx buffers are reduced

From: Bjørn Mork > It doesn't matter whether the buffer size goes up or down. We have to > keep usbnet and device syncronized to be able to split transfers at the > correct boundaries. The spec allow skipping short packets when using > max sized transfers. If we don't tell usbnet about our new e

RE: [PATCH v2 net-next 3/8] net: cdc_ncm: inform usbnet when rx buffers are reduced

From: Bjørn Mork > David Laight writes: > > From: Bjørn Mork > >> It doesn't matter whether the buffer size goes up or down. We have to > >> keep usbnet and device syncronized to be able to split transfers at the > >> correct boundaries. The spec allow s

RE: [PATCH v2 net-next 3/8] net: cdc_ncm: inform usbnet when rx buffers are reduced

From: Bjørn Mork ... > > Since you are now copying the data out of the URB's skb before > > passing the ethernet packet upstream, is there ever any real > > requirement to use a small rx_max? or ever change rx_max? > > Yes. usbnet doesn't currently recycle skbs. Continuously allocating 32 > kB s

RE: disable VBUS?

> The reason is > that even though you don't really put any load on the bus, the PHY still > samples VBUS levels to know when the session is valid (VBUS > 4.4V). Hmmm that might be the cause of some 'random' USB disconnects we were seeing. We 'fixed' them by cutting the wire in the usb cable

RE: [PATCH v1 3/3] usb: gadget: NCM: Stop RX TCP Bursts getting dropped.

From: Jim Baxter > On 30/05/14 12:25, Jim Baxter wrote: > > On 29/05/14 20:04, Eric Dumazet wrote: > >> On Thu, 2014-05-29 at 18:12 +0100, Jim Baxter wrote: > >> > >> Note the patch is OK, but changelog a bit misleading ;) > >> > >> Kernel was not running out of memory, because truesize was correct

RE: [PATCH] usb: gadget: composite: unlock spinlock before usb_gadget_disconnect()

From: Robert Baldyga > usb_gadget_disconnect() shouldn't be called under spinlock to avoid > spinlock recursion. Function usb_gadget_disconnect() calls pullup(), > which is callback from UDC driver, usually calling composite_disconnect(). > This function wants to lock spinlock used in usb_function_

RE: xhci handling ring expansion

From: vichy > hi all: > I use kernel 3.8.0 > And when I plug in webcam in my platform xhci host, I get below message: > > platform-xhci platform-xhci.0: ERROR no room on ep ring, try ring expansion > platform-xhci platform-xhci.0: ring expansion succeed, now has 4 segments > platform-xhci platfor

RE: [PATCH v5 02/46] usb: gadget: add endpoint capabilities flags

From: Robert Baldyga > Sent: 31 July 2015 15:00 > Introduce struct usb_ep_caps which contains information about capabilities > of usb endpoints - supported transfer types and directions. This structure > should be filled by UDC driver for each of its endpoints, and will be > used in epautoconf in n

RE: [PATCH v2 3/3] power: wm831x_power: Support USB charger current limit management

From: Baolin Wang > Sent: 14 August 2015 10:48 > +/* In miliamps */ Spelling police: "milliamps" > +static unsigned int wm831x_usb_limits[] = { > + 0, > + 2, > + 100, > + 500, > + 900, > + 1500, > + 1800, > + 550, > +}; David -- To unsubscribe from this l

RE: [PATCH] usb: gadget: f_uac1: Convert use of __constant_cpu_to_le16 to cpu_to_le16

From: Vaishali Thakkar > Sent: 19 August 2015 06:31 > To: Felipe Balbi > Cc: Greg Kroah-Hartman; linux-usb@vger.kernel.org; > linux-ker...@vger.kernel.org > Subject: [PATCH] usb: gadget: f_uac1: Convert use of __constant_cpu_to_le16 > to cpu_to_le16 > > In big endian cases, macro cpu_to_le16 unf

RE: [PATCH] usb: gadget: f_uac1: Convert use of __constant_cpu_to_le16 to cpu_to_le16

From: Vaishali Thakkar [mailto:vthakkar1...@gmail.com] > Sent: 22 August 2015 02:57 ... > >> - .bcdADC = __constant_cpu_to_le16(0x0100), > >> - .wTotalLength = __constant_cpu_to_le16(UAC_DT_TOTAL_LENGTH), > >> + .bcdADC = cpu_to_le16(0x0100), > >> +

RE: v4.1.4 xhci: 50%~66% chance of "HC died; cleaning up" on boot

From: Mathias Nyman > Sent: 24 August 2015 10:48 > On 23.08.2015 09:37, Vincent Pelletier wrote: > > > > I have one machine which fails to get a working USB bus on at least > > every other boot. This machine having no PS2 ports, bus failure means > > no keyboard, and a forced power cycle (sadly, th

RE: First kernel patch (optimization)

From: Austin S Hemmelgarn > Sent: 16 September 2015 12:46 > On 2015-09-15 20:09, Steve Calfee wrote: > > On Tue, Sep 15, 2015 at 12:53 PM, Eric Curtin > > wrote: > >> Signed-off-by: Eric Curtin > >> > >> diff --git a/tools/usb/usbip/src/usbip_detach.c > >> b/tools/usb/usbip/src/usbip_detach.c >

RE: tools: usbip: detach: avoid calling strlen() at each iteration

From: Aaro Koskinen > Sent: 15 September 2015 21:56 ... > > - for (unsigned int i = 0; i < strlen(port); i++) > > + unsigned int port_len = strlen(port); > > + > > + for (unsigned int i = 0; i < port_len; i++) > > port is read only in this function, so maybe just use "const" and the > compil

RE: First kernel patch (optimization)

From: Jaime Arrocha > Sent: 17 September 2015 02:50 .. > One interesting observation I found was that in O0 and O2, it does make > a call to strlen while in O1 it calculates > the length of the string using: > You want an 'xor %rcx,%rcx' here. > repnz scas%es:(%rdi),%al > not%

RE: ax88179_178a hang over xhci

> On Wed, Aug 20, 2014 at 04:12:49PM +0200, Andrea Arcangeli wrote: > > Hi Sarah, > > > > just a short followup on this. I still had 1gbps hangs with the > > 0b95:1790 ASIX Electronics Corp device using xhci. But it seems now > > stable for the last 12 hours under heavy load after I removed all > >

RE: [PATCH 2/9] libusbg: Always add '\0' at end of string

From: Krzysztof Opasiak > strncpy() may not append trailing '\0' so let's append > it always at end of string to avoid getting into troubles. Silently truncating strings just gives other errors. You really need to verify that it doesn't matter. ... > diff --git a/src/usbg.c b/src/usbg.c > index 0c

RE: [PATCH fix for 3.17] uas: Add a quirk for rejecting ATA_12 and ATA_16 commands

From: Alan Stern ... > > p = quirks; > > while (*p) { > > @@ -543,6 +544,9 @@ void usb_stor_adjust_quirks(struct usb_device *udev, > > unsigned long *fflags) > > case 's': > > f |= US_FL_SINGLE_LUN; > > break; > > + case 't': >

RE: Question about calculate trbs in xhci

From: vichy > hi all: > for iso transactions, we use below function to calculate trbs >addr = (u64) (urb->transfer_dma + urb->iso_frame_desc[i].offset); > td_len = urb->iso_frame_desc[i].length; > num_trbs = DIV_ROUND_UP(td_len + (addr & (TRB_MAX_BUFF_SIZE - 1)), >

RE: Question about calculate trbs in xhci

From: vichy [mailto:vichy@gmail.com] > hi David: > > > Because the trb buffers can't cross a 64k physical address boundary. > > Is it only specific to iso scheduling or bulk also need to take care? > from your kind explanation, the trb buffer for Bulk also need to take > care crossing 64k ph

RE: Question about calculate trbs in xhci

From: vichy > hi David and All: > >> > Because the trb buffers can't cross a 64k physical address boundary. > >> > >> Is it only specific to iso scheduling or bulk also need to take care? > >> from your kind explanation, the trb buffer for Bulk also need to take > >> care crossing 64k physical boun

RE: Question about calculate trbs in xhci

From: Mathias Nyman > On 10/01/2014 05:50 PM, vichy wrote: > > hi Mathias: > > > >> > >> In xhci-ring.c, static int xhci_queue_isoc_tx(): > >> > >> /* Calculate TRB length */ > >> trb_buff_len = TRB_MAX_BUFF_SIZE - (addr & ((1 << TRB_MAX_BUFF_SHIFT) - > >> 1)); > >> > >> where addr = start_add

RE: Question about calculate trbs in xhci

From: Paul Zimmerman ... > > The xhi hardware doesn't have that constraint, but has the different > > constraints: > > 1) A buffer must not cross a 64k address boundary. > > 2) A LINK TRB (at the end of the ring) must only occur at a USB message > > boundary > >(actually it is a slightly tigh

RE: Question about calculate trbs in xhci

From: vichy > hi Mathias: > > As I understood it, it is ok to cross page boundaries as long as the buffer > > is physically > contiguous. As our dma case should be. > > xhci specification section 3.2.8 says that: > > > > "Note that no constraints are placed on the TRB Length fields in a > > Scatt

RE: RCU bug with v3.17-rc3 ?

From: Nathan Lynch > On 10/10/2014 11:25 AM, Russell King - ARM Linux wrote: > > > > Right, so GCC 4.8.{1,2} are totally unsuitable for kernel building (and > > it seems that this has been known about for some time.) > > Looking at http://gcc.gnu.org/PR58854 it seems that all 4.8.x for x < 3 > are

RE: [PATCH v3 2/2] usb: dwc2: gadget: modify return statement

From: Of Sudip Mukherjee > modified the function to have a single return statement at the end > instead of multiple return statement in the middle of the function > to improve the readability of the code. Many of us would disagree with you there. Early returns actually make the code easier to read

RE: [PATCH 18/28] usb: dwc3: ep0: fix Data Phase for transfer sizes aligned to wMaxPacketSize

From: Felipe Balbi > According to Section 8.5.3.2 of the USB 2.0 specification, > a USB device must terminate a Data Phase with either a > short packet or a ZLP (if the previous transfer was > a multiple of wMaxPacketSize). > > For reference, here's what the USB 2.0 specification, section > 8.5.3.

<    1   2   3   4   5   6   >