Applied to for-usb-next for 3.14.
Thanks,
Sarah Sharp
On Mon, Sep 09, 2013 at 09:03:09PM +0300, Xenia Ragiadakou wrote:
> This patch converts TRB_CYCLE to le32 to update correctly the Cycle Bit in
> 'control' field of the link TRB.
> This bug was found using sparse.
>
> Signed-off-by: Xenia Ragi
Applied to for-usb-next for 3.14.
Thanks,
Sarah Sharp
On Mon, Sep 09, 2013 at 09:03:07PM +0300, Xenia Ragiadakou wrote:
> The fields 'add_flags' and 'drop_flags' in struct xhci_input_control_ctx
> have type __le32 and need to be converted to CPU byteorder before being
> used to derive the number
Applied to for-usb-next for 3.14.
Thanks,
Sarah Sharp
On Mon, Sep 09, 2013 at 09:03:12PM +0300, Xenia Ragiadakou wrote:
> This patch fixes the following sparse warnings:
> drivers/usb/host/./xhci-trace.h:116:1: warning: cast to restricted __le32
> drivers/usb/host/./xhci-trace.h:116:1: warning: c
Applied to for-usb-next for 3.14.
Thanks,
Sarah Sharp
On Mon, Sep 09, 2013 at 09:03:11PM +0300, Xenia Ragiadakou wrote:
> This patch fixes the retrieval of the DMA address of the TRB that generated
> the event by converting the field[0] (low address bits) and field[1] (high
> address bits) to CPU
Applied to for-usb-next for 3.14.
Thanks,
Sarah Sharp
On Mon, Sep 09, 2013 at 09:03:10PM +0300, Xenia Ragiadakou wrote:
> This patch converts Event TRB's 3rd field, which has type le32, to CPU
> byteorder before using it to retrieve the Slot ID with TRB_TO_SLOT_ID macro.
> This bug was found usin
On Thu, Nov 14, 2013 at 01:13:31PM -0800, Sarah Sharp wrote:
> On Thu, Nov 14, 2013 at 11:04:14PM +0200, Xenia Ragiadakou wrote:
> > On 11/14/2013 10:52 PM, Sarah Sharp wrote:
> > >Hi Xenia,
> > >
> > >This patch doesn't apply any more either, could you resend when you have
> > >time?
> > >
> > >Th
On Thu, Oct 17, 2013 at 10:42:44AM -0700, Dan Williams wrote:
> On Wed, Oct 16, 2013 at 3:58 PM, Sarah Sharp
> wrote:
> > Hi Dan,
> >
> > I'm attempting to put my queue together for usb-next, and this patch
> > doesn't apply, due to conflicts in the USB core. Can you rebase this
> > patchset on t
On Wed, Oct 09, 2013 at 05:19:28PM +0200, Hans de Goede wrote:
> This is a preparation patch for adding support for bulk streams.
This patch seems to have the (unintended?) side effect of enabling
scatter gather for interrupt transfers over 16384 bytes (USB_SG_SIZE):
switch(uurb->type) {
DWC2 driver should be in good enough shape to move out of staging
Signed-off-by: Paul Zimmerman
---
Greg, is this the proper method for moving a driver out of staging?
drivers/staging/Kconfig | 2 --
drivers/staging/Makefile | 1 -
drivers/usb/Kconfig
DWC2 driver should be in good enough shape to move out of staging
Signed-off-by: Paul Zimmerman
---
Greg, is this the proper method for moving a driver out of staging?
v2: Also update the MAINTAINERS entry
MAINTAINERS | 2 +-
drivers/staging/Kconfig
All right, this patchset looks sane other than the one small bug I
mentioned, and the couple comments I have below.
Have you talked to the other libusb or libusbX developers about adding
streams support to libusb? ISTR that you said you needed libusb changes
in order to get the virtualized UAS de
On Thu, Nov 07, 2013 at 10:32:33AM -0500, Alan Stern wrote:
> On Wed, 6 Nov 2013, Julius Werner wrote:
>
> > > What if the device is in USB_STATE_SUSPENDED?
> >
> > I'm not sure that is possible at that point in hub_events(), I don't
> > know of a way that could lead to this situation. I could st
Good day! Please acknowledge our message in the attachment. Thanks.
Happy Child Charity Foundation.docx
Description: Binary data
On Wed, Nov 13, 2013 at 11:11:12AM -0500, Alan Stern wrote:
> On Tue, 12 Nov 2013, Sarah Sharp wrote:
>
> > > No, but that last one can be subdivided into:
> > > - implement hotplug vs hardwired policy
> >
> > I think the original agreement when the USB 2.0 port power off work
> > went in was th
The field 'dev_info' in struct xhci_slot_ctx has type __le32 and it needs
to be converted to CPU byteorder for the correct retrieval of its subfield
'Context Entries'. This field is used by the trace event 'xhci_address_ctx'
to trace only the contexts of valid endpoints.
This bug was found using sp
This patch removes the to_pci_dev() conversion performed to generic struct
device since it is not actually useful (the pointer to the generic device
can be used directly rather through a conversion to pci_dev) and it is pci
bus specific.
Signed-off-by: Xenia Ragiadakou
---
Changes from v1:
* f
On 11/15/2013 02:37 AM, Tony Lindgren wrote:
> * Chen Gang [131023 02:57]:
>> When CONFIG_NOP_USB_XCEIV is as 'm', usb_nop_xceiv_register() will be
>> exported when the related module is loaded. So for built-in source
>> code, still need use the empty one.
>>
>> Or it will can not pass compiling,
> >
> > If it is an external USB PHY, the clock entry should be added at phy
> node.
> > If it is a USB HUB's reset/clock pin, there is no good place to
> > put them, only platform code is available now.
> >
> > Alan, if there is an external USB HUB, but clock and reset pin needs to
> > be contr
>
> If on the board file I just do this:
>
> +&usbh1 {
> + vbus-supply = <®_usb_h1_vbus>;
> + clocks = <&clks 201>; /* USB2514 clock comes from mx6 clko2 pin
> */
> + status = "okay";
> +};
> +
>
> without touching any kernel code, then the USB hub clock is turned on
> an
On Fri, Nov 15, 2013 at 02:21:36AM +, Peter Chen wrote:
> > If on the board file I just do this:
> >
> > +&usbh1 {
> > + vbus-supply = <®_usb_h1_vbus>;
> > + clocks = <&clks 201>; /* USB2514 clock comes from mx6 clko2 pin
> > */
> > + status = "okay";
> > +};
> > +
> >
> >
Function xhci_readl() is used to read 32bit xHC registers residing in MMIO
address space. It takes as first argument a pointer to the xhci_hcd although
it does not use it. xhci_readl() internally simply calls readl(). This creates
an illusion that xhci_readl() is an xhci specific function that has
Function xhci_writel() is used to write a 32bit value in xHC registers residing
in MMIO address space. It takes as first argument a pointer to the xhci_hcd
although it does not use it. xhci_writel() internally simply calls writel().
This creates an illusion that xhci_writel() is an xhci specific fu
Function xhci_read_64() is used to read 64bit xHC registers residing in MMIO.
On 32bit systems, xHC registers need to be read with 32bit accesses by
reading first the lower 32bits and then the higher 32bits.
Replace all calls to xhci_read_64() with calls to readq() and include
asm-generic/io-64-no
Changes from v1:
* create one patch per type of conversion instead of multiple patches
associated with specific xhci files
* change commit messages to be more readable and to reflect the above change
* add an empty line between #include
and the rest of the headers to improve readabil
Function xhci_write_64() is used to write 64bit xHC registers residing in MMIO.
On 32bit systems, xHC registers need to be written with 32bit accesses by
writing first the lower 32bits and then the higher 32bits. The header file
asm-generic/io-64-nonatomic-lo-hi.h ensures that on 32bit systems writ
Hi,
Patch "usb: dwc3: gadget: drop dwc3 manual phy control" says
"Recent versions of the core, can suspend and resume the PHYs
automatically, so we don't need to fiddle with dwc3's Global PHY
registers at all."
First part of the statement is true, but only when bit 17 of
GUSB3PIPECTL and bit 6 o
On Thu, Nov 14, 2013 at 02:50:24PM -0800, Paul Zimmerman wrote:
> DWC2 driver should be in good enough shape to move out of staging
>
> Signed-off-by: Paul Zimmerman
> ---
> Greg, is this the proper method for moving a driver out of staging?
Yes, that's the way to do it.
But, are all of the TOD
The maximum packet number which a tx aggregation buffer could contain
is the buffer size / (packet size + descriptor size).
If the tx buffer is empty and the tx queue length is more than the
maximum value which is defined above, stop the tx queue. Wake the tx
queue after any queued packet is fille
101 - 128 of 128 matches
Mail list logo
