> From: Mathias Nyman
> Sent: 03 May 2016 12:11
...
> > @@ -109,7 +109,7 @@ static int last_trb(struct xhci_hcd *xhci, struct
> > xhci_ring *ring,
> > struct xhci_segment *seg, union xhci_trb *trb)
> > {
> > if (ring == xhci->event_ring)
> > - return trb == &seg->trbs[T
From: Felipe Balbi
> Sent: 19 May 2016 10:57
...
> queue it to the command ring
>
> > if (ret) {
> > spin_unlock_irqrestore(&xhci->lock, flags);
> > mutex_unlock(&xhci->mutex);
> > xhci_dbg(xhci, "FIXME: allocate a command ring segment\n");
> > k
From: Andrey Ryabinin
> Sent: 18 May 2016 13:21
...
> >> $ 6.5.6.8
> >>"If both the pointer operand and the result point to elements of
> >> the same array object,
> >> or one past the last element of the array object, the evaluation
> >> shall not produce an overflow;
> >> otherwise,
From: Alan Stern
> Sent: 10 June 2016 19:43
> Hans de Goede has reported a difficulty in the Linux port of libusb.
> When a device is removed, the poll() system call in usbfs starts
> returning POLLERR as soon as udev->state is set to
> USB_STATE_NOTATTACHED, but the outstanding URBs are not availa
From: Michael Walle
...
> What comes directly to my mind is the handling of the break condition.
> Can't look into that at the moment. But if break conditions are
> translated into status-only packets, how are two consecutive breaks
> recognized. Ie. if the break condition flag is sticky (until a n
From: Alexandre Belloni
> Sent: 01 December 2016 10:27
> Use devm_kasprintf instead of simple kasprintf to free the allocated memory
> when needed.
s/when needed/when the device is freed/
> Suggested-by: Peter Rosin
> Signed-off-by: Alexandre Belloni
> ---
> drivers/usb/gadget/udc/atmel_usba_u
From: Alexandre Belloni
> Sent: 02 December 2016 16:19
> On 02/12/2016 at 15:59:57 +, David Laight wrote :
> > From: Alexandre Belloni
> > > Sent: 01 December 2016 10:27
> > > Use devm_kasprintf instead of simple kasprintf to free the allocated
> > > m
From: Andy Lutomirski
> Sent: 12 December 2016 20:53
> The driver put a constant buffer of all zeros on the stack and
> pointed a scatterlist entry at it in two places. This doesn't work
> with virtual stacks. Use a static 16-byte buffer of zeros instead.
...
I didn't think you could dma from st
From: Mathias Nyman
> Sent: 20 January 2017 14:47
> Instead of storing a zero length array of td pointers, and then
> allocate memory both for the td pointer array and the td's, just
> use a zero length array of actual td's in urb private data.
This reminds me of an old patch that got reverted be
From: Mathias Nyman
> Sent: 20 January 2017 14:47
> From: Felipe Balbi
>
> If we add that newline, the output will like like the following:
>
> kworker/2:1-42[002] 169.811435: xhci_address_ctx:
> ctx_64=0, ctx_type=2, ctx_dma=@153fbd000, ctx_va=@880153fbd000
>
> We would rat
From: David Laight
> Sent: 23 January 2017 11:58
> From: Mathias Nyman
> > Sent: 20 January 2017 14:47
>
> > Instead of storing a zero length array of td pointers, and then
> > allocate memory both for the td pointer array and the td's, just
> > use a z
From: Mathias Nyman
> Sent: 20 January 2017 14:47
> Remove duplicate code by using trb_to_noop() when
> handling Aborted commads
^n
...
> xhci_dbg(xhci, "Turn aborted command %p to no-op\n",
>i_cmd->command_trb);
> - /* get c
From: Mathias Nyman
> Sent: 23 January 2017 12:20
> If we just provide a helper to convert completion code to string, we can
> combine all debugging messages into a single print.
...
> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> index aa63e38..ebdd920 100644
> --- a/drivers/usb
From: Of Vincent Pelletier
> Sent: 23 January 2017 14:41
> It is allowed by the USB specification to enabled same-address, opposite-
> direction endpoints simultaneously, which means 30 non-zero endpoints
> are allowed. So double eps_addrmap length to 30.
> The original code only accepted 14 descri
From: Felipe Balbi
> Sent: 24 January 2017 10:50
> David Laight writes:
> > From: Of Vincent Pelletier
> >> Sent: 23 January 2017 14:41
> >> It is allowed by the USB specification to enabled same-address, opposite-
> >> direction endpoints simultaneo
From: Janusz Dziedzic
> Sent: 24 January 2017 12:06
> On 23 January 2017 at 13:20, Mathias Nyman
> wrote:
> > From: Felipe Balbi
> >
> > If we just provide a helper to convert completion code to string, we can
> > combine all debugging messages into a single print.
> >
> > [keep the old debug mes
From: Johan Hovold
> Sent: 25 January 2017 14:35
> Since commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY
> flag") the FTDI driver has been using a receive latency-timer value of
> 1 ms instead of the device default of 16 ms.
>
> The latency timer is used to periodically empty a non-full
From: Wolfgang Breyha [mailto:wbre...@gmx.net]
> Sent: 08 September 2016 14:27
> David Laight wrote on 07/09/16 18:25:
> > I'd expect files much smaller than 500MB to fail if the problem was
> > actually to do with a 64 sector limit.
> >
> > So I'm guessi
From: Wolfgang Breyha
> Sent: 08 September 2016 16:32
> David Laight wrote on 08/09/16 15:30:
> > Try with raw writes to the disk, rather than going through the filesystem.
> > That will remove effects caused by the alignment of the filesystem and the
> > size of the files
From: Nobuo Iwata
> Sent: 30 September 2016 06:44
> This patch removes checking of socket descriptor value in daemons.
>
> It was checked to be less than FD_SETSIZE(1024 usually) but it's not
> correct.
>
> To be exact, the maximum value of descriptor comes from
> rlimit(RLIMIT_NOFILE).
>
> Foll
From: Bryan Paluch
> Sent: 17 October 2016 13:55
> Increase ohci watchout delay to 275 ms. Previous delay was 250 ms
> with 20 ms of slack, after removing slack time some ohci controllers don't
> respond in time. Logs from systems with controllers that have the
> issue would show "HcDoneHead not wr
From: John Youn
> Sent: 08 November 2016 22:30
...
> >> Also make it __packed.
> >
> > why are you making it packed? Does it _have_ to be packed? If it must,
> > why wasn't it before?
>
> We want to guarantee that it reflects the exact descriptor structure
> in memory, so probably yes. It was over
From: John Youn
> Sent: 10 November 2016 03:28
> From: Vahram Aharonyan
>
> Make the DMA descriptor structure packed to guarantee alignment and size
> in memory.
>
> Signed-off-by: John Youn
> ---
> drivers/usb/dwc2/hw.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a
From: Felipe Balbi
> Sent: 11 November 2016 10:45
> Hi,
>
> John Youn writes:
> > On 11/10/2016 4:28 AM, David Laight wrote:
> >> From: John Youn
> >>> Sent: 10 November 2016 03:28
> >>> From: Vahram Aharonyan
> >>>
> >>&g
From: Felipe Balbi
> Sent: 10 December 2015 15:14
> "Geyslan G. Bem" writes:
>
> > This patch removes redundant conditions.
> >
> > - (!A || (A && B)) is the same as (!A || B).
> > - (length && length > 5) can be reduced to a single evaluation.
> >
> > Caught by: cppcheck
> >
> > Signed-off-by:
From: Alan Stern
> Sent: 14 December 2015 15:28
...
> I thought of something else, a more serious problem. According to the
> man page for munmap(2), closing the file descriptor does not unmap the
> region. Therefore we need to explicitly make sure that the usbcore
> module cannot be unloaded whi
From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: 14 December 2015 17:59
> On Mon, 14 Dec 2015, David Laight wrote:
>
> > From: Alan Stern
> > > Sent: 14 December 2015 15:28
> > ...
> > > I thought of something else, a more serious problem. Accor
From: Alan Stern
> Sent: 15 December 2015 15:13
...
> > I was thinking that some side effect of dma_free_coherent() would
> > find the user mapping for the pages, force unmap them and invalidate
> > the user PTE (although the address range would have to remain reserved).
> > Maybe that is wishful t
From: Bin Liu
> Sent: 17 December 2015 15:55
...
> >> drivers/usb/common/built-in.o: In function `of_usb_get_dr_mode_by_phy':
> (.text+0x0): multiple definition of `of_usb_get_dr_mode_by_phy'
> >> drivers/usb/chipidea/built-in.o:(.text+0xd61): first defined here
> >
> >
> > seems like
From: Steinar H. Gunderson [mailto:se...@google.com]
> Sent: 26 November 2015 00:19
There is still a problem with this code, not sure how to fix it.
...
> +static void dec_usb_memory_use_count(struct usb_memory *usbm, int *count)
> +{
> + struct usb_dev_state *ps = usbm->ps;
> + unsigned
From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: 05 January 2016 15:58
> On Tue, 5 Jan 2016, David Laight wrote:
>
> > From: Steinar H. Gunderson [mailto:se...@google.com]
> > > Sent: 26 November 2015 00:19
> >
> > There is still a problem wi
From: Bjørn Mork
> Sent: 13 July 2016 23:23
...
> Or how about the more generic?:
>
> if (bp[0] & 0x02)
> eth_hw_addr_random(net);
> else
> ether_addr_copy(net->dev_addr, bp);
>
> That would catch similar screwups from other vendors too.
Not really, that
From: Felipe Balbi
> Sent: 29 July 2016 01:30
...
> > - maxp = usb_endpoint_maxp(&endpoint->desc) & 0x07ff;
>
> usb_endpoint_maxp() should probably be updated to return only maximum
> packet size. Then we would need to introduce usb_endpoint_mult() or
> something along those lines to tak
From: Randy Li
> Sent: 03 September 2016 22:55
...
> + if (of_device_is_compatible(np, "rockchip,rk3288-usb")
> + && (NULL != hsotg->phy->ops->reset))
> + hsotg->phy->ops->reset(hsotg->phy);
> +
Is this the only pl
From: Wolfgang Breyha
> Sent: 07 September 2016 17:10
> I purchased a Kingston DT100G3/32GB and it corrupts large files (> ~500MB) on
> write with plain "cp". I already filed a bug at
> https://bugzilla.redhat.com/show_bug.cgi?id=1371183
> with detailed descriptions how I tested the device.
>
> Ki
From: John Ogness
> Sent: 04 March 2016 10:51
> On 2016-03-04, John Ogness wrote:
> > Using v4.5-rc6, I modified musb_h_tx_flush_fifo() to allow infinite
> > looping and kept a log of the number of loops that were executed. For
> > my test I am regularly seeing 3000-3200 loops (with a max so far o
From: Sedat Dilek
...
> Did someone look at the next/follow-ups in this thread?
> For example: D6629 "x86: Emit LAHF/SAHF instead of PUSHF/POPF" [2]?
LAHF and SAHF come with the following note:
This instruction executes as described above in compatibility mode and legacy
mode.
It is valid in 64-
From: Felipe Balbi
> Sent: 08 March 2016 13:48
...
> wonder if we should provide a generic static inline for that. Seems like
> that will replicate on many drivers. How about:
>
> static inline int dma_try_mask_and_coherent(struct device *dev)
> {
> int ret;
>
> ret = dma_set_mask
From: Felipe Balbi
> Bin Liu writes:
> > [ text/plain ]
> > Hi,
> >
> > On Fri, Mar 11, 2016 at 6:54 AM, Felipe Balbi
> > wrote:
> >> previously we were using a maximum of 32 TRBs per
> >> endpoint. With each TRB being 16 bytes long, we were
> >> using 512 bytes of memory for each endpoint.
> >>
From: David Lechner
> Sent: 23 March 2016 18:07
> On 03/23/2016 12:21 PM, Sekhar Nori wrote:
> >> +/* DA8xx CFGCHIP2 (USB PHY Control) register bits */
> >> +#define PHYCLKGD (1 << 17)
> >> +#define VBUSSENSE (1 << 16)
> >> +#define RESET (1 << 15)
> >> +#define
From: Felipe Balbi
> Sent: 06 April 2016 14:25
> If we _know_ length is 0, we can just return 1 early.
Does that happen often enough to be an optimisation?
Looks like a mispredicted branch to me.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of
From: Pavel Machek
> Sent: 18 April 2016 11:40
...
> > >> > Actually, less is not stupid. Charging li-ion battery from li-ion
> > >> > battery might
> > >> > be stupid. Imagine I'm on train, with device like N900 (50% battery)
> > >> > and power bank
> > >> > (3Ah). I'm actively using the device.
From: Konstantin Shkolnyy
> Sent: 30 April 2016 03:22
> Replaced magic numbers used in the CRTSCTS flag code with symbolic names
> from the chip specification.
>
> Signed-off-by: Konstantin Shkolnyy
> ---
> Changes in v2:
> Improved CRTSCTS fix based on feedback. Dropped get_termios error handlin
> interesting. We actually found a similar issue with XHCI. scatterlist
> has to be aligned to wMaxPacketSize but only before a link TRB. Mathias
> has been working on a solution which involves memcpy()ing enough bytes
> to align to wMaxPacketSize before the link TRB (it's very infrequent as
> we h
From: Petko Manolov
> Sent: 06 February 2017 12:51
...
> I suspect getting the buffer allocation in usb_control_msg() will help with
> two
> things in the same time:
>
> - allocate in DMA-able memory;
> - code reduction;
Is there code around there to do 'bounce buffer' allocation
for systems w
From: Ben Hutchings
> Sent: 04 February 2017 16:57
> Allocating USB buffers on the stack is not portable, and no longer
> works on x86_64 (with VMAP_STACK enabled as per default).
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Ben Hutchings
> ---
> drivers/net/usb/rtl8150.c | 34 +
From: Greg KH
> Sent: 07 February 2017 10:52
> To: Petko Manolov
> Cc: Ben Hutchings; David Laight; net...@vger.kernel.org;
> linux-usb@vger.kernel.org
> Subject: Re: [PATCH net 2/4] rtl8150: Use heap buffers for all register access
>
> On Tue, Feb 07, 2017 at 12:34:52PM
From: Petko Manolov
> Sent: 07 February 2017 13:21
...
> > > Would you consider what David proposed (usb_control_msg_with_malloc())
> > > for 4.11,
> > > for example? I for one will use something like that in all my drivers.
> >
> > Sure, but you might want to make it a bit smaller of a function
From: Gustavo A. R. Silva
> Sent: 17 February 2017 00:17
> The type of variable 'sel' is unsigned int. Such variable is being used
> multiple times in a context that expects an expression of type unsigned
> long long. So, to avoid any potential integer overflow, a cast to type
> unsigned long long
From: Vardan Mikayelyan
> Sent: 20 February 2017 15:15
> dwc2_clear_force_mode() can be called in hibernation exit flow which
> can occur in interrupt context.
>
> Signed-off-by: Vardan Mikayelyan
> ---
> drivers/usb/dwc2/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -
From: Ian Abbott
> Sent: 28 February 2017 12:51
> The 'store' function for the "event_char" device attribute currently
> expects a base 10 value. The value is composed of an enable bit in bit
> 8 and an 8-bit "event character" code in bits 7 to 0. It seems
> reasonable to allow hexadecimal and oc
From: Mason
> Sent: 06 March 2017 13:50
> On 06/03/2017 13:42, Mason wrote:
>
> > So the kernel panics in xhci_find_next_ext_cap()
> > ( drivers/usb/host/xhci-ext-caps.h:122 )
> > http://lxr.free-electrons.com/source/drivers/usb/host/xhci-ext-caps.h?v=4.9#L122
> >
> > Any idea how this can happen?
> From: Mason
> Sent: 06 March 2017 15:46
...
> >> The issue was that, on this platform, the PCI configuration space
> >> and memory space are multiplexed; in other words they reside at
> >> the same physical address, with a bit in MMIO to choose one or
> >> the other.
> >
> > Time to shoot another
From: Robin Murphy
> Sent: 10 March 2017 13:16
> On 09/03/17 23:43, Mason wrote:
> > On 08/03/2017 16:17, Bjorn Helgaas wrote:
> > [snip excellent in-depth overview]
> >
> > I think I'm making progress, in that I now have a better
> > idea of what I don't understand. So I'm able to ask
> > (hopeful
From: Mason
> Sent: 10 March 2017 15:06
...
> My RC drops packets not targeting its BAR0.
I suspect the fpga/cpld logic supports RC and endpoint modes
and is using much the same names for the registers (and logic
implementation).
If your cpu support more than 1GB of memory but only part is
PCIe a
From: Robin Murphy
> Sent: 10 March 2017 15:23
...
> >> So you have 128MB (max) of system memory that has cpu physical
> >> addresses 0x8000 upwards.
> >> I'd expect it all to be accessible from any PCIe card at some PCIe
> >> address, it might be at address 0, 0x8000 or any other offset.
From: Mason
> Sent: 13 March 2017 21:58
...
> I'd like to push support for this PCIe controller upstream.
>
> Is the code I posted on the right track?
> Maybe I can post a RFC patch tomorrow?
I think you need to resolve the problem of config space (and IO) cycles
before the driver can be deemed u
From: Mason
> Sent: 14 March 2017 12:06
> On 14/03/2017 11:23, David Laight wrote:
>
> > Mason wrote:
> >
> >> I'd like to push support for this PCIe controller upstream.
> >>
> >> Is the code I posted on the right track?
> >> Mayb
From: Hayes Wang
> Sent: 16 March 2017 06:28
> Replace &tp->napi with napi and tp->netdev with netdev.
>
> Signed-off-by: Hayes Wang
> ---
> drivers/net/usb/r8152.c | 44 +++-
> 1 file changed, 27 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/ne
From: Hayes Wang
> Sent: 17 March 2017 03:00
> To: David Laight; net...@vger.kernel.org
> Cc: nic_swsd; linux-ker...@vger.kernel.org; linux-usb@vger.kernel.org
> Subject: RE: [PATCH net-next] r8152: simply the arguments
>
> David Laight [mailto:david.lai...@aculab.com]
> &g
From: Mauro Carvalho Chehab
> Sent: 30 March 2017 11:28
...
> While debugging this issue, I saw *a lot* of network-generated URB
> traffic from RPi3 Ethernet port drivers that were using non-aligned
> buffers and were subject to the temporary buffer conversion.
Buffers from the network stack will
> > +struct ax88179_rx_pkt_header {
> > + u8 l4_csum_err:1,
> > + l3_csum_err:1,
> > + l4_type:3,
> > + l3_type:2,
> > + ce:1;
> > +
> > + u8 vlan_ind:3,
> > + rx_ok:1,
> > + pri:3,
> > + bmc:1;
> > +
> > + u16
> Subject: Re: [PATCH 0/2] fs: supply inode uid/gid setting interface
>
> On 2013/8/23 12:10, Greg KH wrote:
> > On Fri, Aug 23, 2013 at 10:48:36AM +0800, Rui Xiang wrote:
> >> This patchset implements an accessor functions to set uid/gid
> >> in inode struct. Just finish code clean up.
> >
> > Wh
> On Wed, Sep 11, 2013 at 8:56 PM, David Laight wrote:
> >> > > 2) If 'length % dev->maxpacket == 0' for a multi-fragment packet then
> >> > >the extra byte isn't added correctly (the code probably falls off
> >> > >t
> I also believe it would be nice to move the initialisation of can_dma_sg
> away from the minidriver and into usbnet_probe. It's confusing that
> this field is used "uninitialized" (well, defaulting to zero) in all but
> one minidriver. It would much nicer if the logic was more like
>
> usbnet_
> I wonder what the gain of that really is? Yes, I can see the advantage
> of making the class drivers more effective. But padding is only
> relevant for the ECM class, isn't it? And are there any ECM class
> devices where SG support matters?
AFAICT the requirement for avoiding ZLP is a property
> Anything that breaks a previously unbroken argument list will reduce the
> readability in my opinion. The lines can of course not be unlimited,
> but there is no need to set the limit as low as 80 columns. Feedback
> I've got from developers using e.g. 80 column braille devices is that
> longer
We are seeing complete lockups of the transmit side when using
the smsc95xx driver connected to a USB3 port on an i7 (Ivybridge) cpu.
These errors are very intermittent - less than once a day, and
it isn't actually clear that they are related to traffic load.
Most of the systems are running the 3.
> From: Sarah Sharp [mailto:sarah.a.sh...@linux.intel.com]
Thanks for taking an interest.
> On Tue, Oct 15, 2013 at 10:59:18AM +0100, David Laight wrote:
> > We are seeing complete lockups of the transmit side when using
> > the smsc95xx driver connected to a USB3 port on an
> It's not too hard. Here's some directions:
> http://kernelnewbies.org/KernelBuild
I can build it easily enough but ...
Is there a .config file with a sane list of modules anywhere?
(and builtin drivers for disk boot)
The defconfig one doesn't seem to contain enough to be useful,
and the allmo
> Have you tried the latest stable kernel or the latest -rc kernel?
I've built a kernel based on Linus's tree from last Friday, 3.12-rc6 ish.
Commented out the trace for short reads - happens all the time.
I've not seen an error on a Bo yet, the failure rate is depressingly low.
I have had an err
> > We are seeing complete lockups of the transmit side when using
> > the smsc95xx driver connected to a USB3 port on an i7 (Ivybridge) cpu.
> > These errors are very intermittent - less than once a day, and
> > it isn't actually clear that they are related to traffic load.
...
> I would suggest y
I can't see any code in xhci-ring.c that ensures that a LINK
TRB is always correctly aligned when a transfer descriptor
has a link TRB in the middle of a chain of data TRBs.
See section 4.11.7.1 of the 1.0 version of the xhci specification.
I don't think we are seeing such issues, but any code th
> Wouldn't it be simpler and safer to just do this unconditionally? Sure,
> you need it for DWC3 because the controller refuses to do an OUT transfer
> at all if the transfer size is less than maxpacketsize. But it's possible
> that other controllers allow the transfer, and it works in most cases,
Only receive TD can have a transfer length less than the transfer size,
so rename COMP_SHORT_TX to COMP_SHORT_RX, XHCI_TRUST_TX_LENGTH to
XHCI_TRUST_RX_LENGTH.
handle_tx_event() is called for both receive and transmit completions
so rename to handle_data_event().
In process_bulk_intr_td():
-
Convert TRB_CYCLE to LE when initialising the ring entries.
---
drivers/usb/host/xhci-mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 83bcd13..79cdcc2 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/us
Code was recently added to the xhci driver to dynamically add extra ring
segments if there is insufficient space for all the fragments of the
URB being sent.
ISTM that it would be better to just queue the URB (on the ring)
and process it when space becomes available.
This wouldn't solve the probl
> Subject: Re: [PATCH] usb: xhci: Less verbose tracing of short receives
>
> On Thu, 31 Oct 2013, David Laight wrote:
>
> > Only receive TD can have a transfer length less than the transfer size,
>
> Without commenting on the patch itself, let me point out that this
&
Replace the array of pointers to transfer descriptors with
the transfer descriptors themselves.
This saves a kzalloc() call on every transfer and some memory
indirections.
The only possible downside is for isochronous tranfers with 64 td
when the allocate is 8+4096 bytes (on 64bit systems) so req
In many cases the constant 1 is used for values that eventually
get written to the hardware ring. Replace all of these with the
symbolic constant TRB_CYCLE.
This makes it clear that the ring->cycle_state value is used when
writing to the actual ring itself.
Always use ^= TRB_CYCLE to invert the b
keyboard and the smsc95xx ethernet driver.
Signed-off-by: David Laight
---
I hope this patch (and the others I've sent recently) are properly formatted.
They are the first Linux patches I've written.
I think this one depends on the earlier s/1/TRB_CYCLE/ change.
David
drivers/usb
o longer fail.
Delete the (possibly dubious) 'cleanup' code and change the return
type to void.
Signed-off-by: David Laight
---
This is compile tested only because I don't have an isoc device.
However it should be ok.
I've just ordered a cheap USB 'sound card' - presum
> -Original Message-
> From: Andiry Xu [mailto:and...@gmail.com]
> Sent: 05 November 2013 17:40
> To: David Laight
> Cc: Linux-USB; Sarah Sharp
> Subject: Re: [PATCH] usb: xhci: Optimise setup of isochronous transfers
>
> On Tue, Nov 5, 2013 at 6:21
> By performing iterative port suspend and resume (which results in function
> suspend and resume), ring expansion failure is observed. Attached device
> has multiple interfaces for which interface host drivers are unlinking the
> urbs during function suspend and submitting urbs during resume.
>
>
> > I just did a diff of registers in exynos 4210 and 4212 PHY drivers [1]
> > and couldn't find that big a difference in register layout. Of course
> > there are a few changes in HSIC bit fields and PHYFSEL but that's only
> > minimal and could well be handled in a single driver.
> >
> > [1] -> ht
> 256 hard coded value has been replaced by two defined
> constants MAX_LENGTH and MAX_PATH_LENGTH
Think of better names.
David
--
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://v
> Subject: xhci message rate control needed
>
> fedora kernel 3.9.10-100.fc17.x86_64
>
> xhci_hcd :12:00.0: ERROR Transfer event TRB DMA ptr not part of
> current TD
>
> i got this message about every 200 MICROseconds after a warm boot.
> unplugging the usb3 cables silenced it. plugging back
> Sounds like a bug. Why num_trbs_in_deq_seg becomes high? How many urbs
> are submitted during resume? Normally only isoc transfer triggers ring
> expansion with multiple trbs per urb.
I've seen the number of free ring entries go down after a sequence
where all the active urb got cancelled.
Not l
> xhci_hcd :12:00.0: ERROR Transfer event TRB DMA ptr not part of
> current TD
This seems to happen if the hardware rejects a TRB with status TRB_ERROR (5).
In this case the 'address' field is that of the broken TRB not that
of some dma buffer.
While the TRB_ERROR status shouldn't happen, the
to
gso and tso enabled so it passes a lot of fragmented skb to the USB stack.
Signed-off-by: David Laight
---
Although I've got a USB2 analyser its trigger and trace stuff is almost
unusable! In any case this fails much faster on USB3 (Intel i7 cpu).
diff --git a/drivers/usb/host/xhci-ring.
> From: Sarah Sharp [mailto:sarah.a.sh...@linux.intel.com]
> On Thu, Nov 07, 2013 at 05:20:49PM -, David Laight wrote:
> >
> > Section 4.11.7.1 of rev 1.0 of the xhci specification states that a link TRB
> > can only occur at a boundary between underlying USB frames
> While this change improves things a lot (it runs for 20 minutes rather than
> a few seconds), there is still something else wrong.
Almost certainly caused by an unrelated local change.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a mess
> ... The Moxa
> UPORT only has one pair for data transfer and places a header on each
> transfer over the endpoint indicating for which port the transfer
> relates to. There is a second endpoint pair for events, such as modem
> control lines changing state, setting baud rates etc. Again, a
> multi
> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: 08 November 2013 16:46
> To: Sarah Sharp
> Cc: David Laight; net...@vger.kernel.org; linux-usb@vger.kernel.org
> Subject: Re: [PATCH] usb: xhci: Link TRB must not occur with a USB payload
op sending (while still receiving)
when running a netperf tcp transmit test with (say) and 8k buffer.
This should be a candidate for stable, the ax88179_178a driver defaults to
gso and tso enabled so it passes a lot of fragmented skb to the USB stack.
Signed-off-by: David Laight
---
Changes for v2:
1
"TRB error".
Signed-off-by: David Laight
---
drivers/usb/host/xhci-ring.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index c1342dc..ace586c 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/d
g the logic as well.
In particular we note that the number of TRB passed to prepare_ring()
need only be an upper limit on the number required. However we do try
to only request 1 TRB when we know one is sufficient.
Signed-off-by: David Laight
---
This patch is basically a rewrite of xhci_queue_bi
> As my below test on ax99179_178a, I believe the patch should fix padding
> for dma sg, but need a little update, and I will send out v1 later:
>
>$ping -s 974 another_machine #from host with ax99179_178a attached
>
> If FLAG_SEND_ZLP is set for ax99179_178a, the above ping won't wo
This makes it clear that the ring->cycle_state value is used when
writing to the actual ring itself.
Always use ^= TRB_CYCLE to invert the bit.
Signed-off-by: David Laight
---
Changes for v2:
1 Adjusted so that it should apply to HEAD.
(One of the ?: had been changed to ^=.)
2 Added Sig
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> On Fri, 8 Nov 2013, David Laight wrote:
>
...
> GET_MAX_PACKET always returns MaxPacketSize, and for USB-3 bulk
> endpoints, MaxPacketSize is always 1024. MaxBurstSize can be anything
> from 1 to 16.
I've just read s
1 - 100 of 515 matches
Mail list logo
