On 01.12.2015 17:47, Alan Stern wrote:
On Mon, 30 Nov 2015, Mathias Nyman wrote:
usb2 ports need to signal resume for 20ms before moving to U0 state.
Both device and host can initiate resume.
On host initated resume port is set to resume state, sleep 20ms,
and finally set port to U0 state.
T
Thank you all for your help on this.
Adrien
--
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/majordomo-info.html
Hi Felipe,
> IMHO, this should be creating a child device instead of calling
> intel_usb_mux_register() directly. That way, your mux driver could
> actually _be_ a driver. Seems like all you need to do from this point is
> a register a simple platform_device which is a child of xhci, see
> platfor
Hi,
> > @@ -1029,9 +1030,36 @@ static void quirk_usb_handoff_xhci(struct pci_dev
> > *pdev)
> > writel(val, base + ext_cap_offset + XHCI_LEGACY_CONTROL_OFFSET);
> >
> > hc_init:
> > - if (pdev->vendor == PCI_VENDOR_ID_INTEL)
> > + if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
> >
Hi David,
> > +void intel_usb_mux_unregister(struct intel_usb_mux *mux)
> > +{
>
> There are still 2 pending comments for this unregister function:
>
> 1) How about a protection against unbalanced unregistering? In case an
> user mistakenly unregisters twice or unregisters without a previous
>
On Tue, Dec 01, 2015 at 06:17:54PM -0800, Greg KH wrote:
> On Wed, Dec 02, 2015 at 01:02:28AM +, Rogan Dawes wrote:
> > Thanks Greg.
> >
> > At a high level, what is needed to implement a new type of USB device
> > gadget,
> > such as a display link device?
>
> A lot of work :)
>
Heh! Ok,
On Wed, Dec 2, 2015 at 7:29 AM, Rogan Dawes wrote:
> On Tue, Dec 01, 2015 at 06:17:54PM -0800, Greg KH wrote:
>> On Wed, Dec 02, 2015 at 01:02:28AM +, Rogan Dawes wrote:
>> > Thanks Greg.
>> >
>> > At a high level, what is needed to implement a new type of USB device
>> > gadget,
>> > such as
Thanks for the pointers, Chris!
I'll check them all out. It sounds like the USBProxy is going to be the way to
go.
Rogan
On Wed, Dec 02, 2015 at 09:10:10AM -0500, Chris McClimans wrote:
> On Wed, Dec 2, 2015 at 7:29 AM, Rogan Dawes wrote:
> > On Tue, Dec 01, 2015 at 06:17:54PM -0800, Greg KH
Hi,
Heikki Krogerus writes:
> Hi Felipe,
>
>> IMHO, this should be creating a child device instead of calling
>> intel_usb_mux_register() directly. That way, your mux driver could
>> actually _be_ a driver. Seems like all you need to do from this point is
>> a register a simple platform_device w
On Tue, 1 Dec 2015, Alan Cooper wrote:
> I agree that for USB suspend modes, VBUS must be on, and our hardware
> behaves that way for runtime suspend. The question is for system wide
> suspend (S3/STR) can the system shut down the USB hardware entirely.
Oh, okay, I misunderstood.
> The ACPI spec
On Wed, 2 Dec 2015, Rogan Dawes wrote:
> Hi folks,
>
> I'm wondering if it is possible/reasonable to try to turn a linux
> device with host and OTG ports into something that looks and acts
> like a USB hub?
Besides all the other responses you received, here's a short answer to
your first questi
On Wed, Dec 02, 2015 at 02:29:23PM +0200, Rogan Dawes wrote:
> On Tue, Dec 01, 2015 at 06:17:54PM -0800, Greg KH wrote:
> > On Wed, Dec 02, 2015 at 01:02:28AM +, Rogan Dawes wrote:
> > > Thanks Greg.
> > >
> > > At a high level, what is needed to implement a new type of USB device
> > > gadge
On Wed, Dec 02, 2015 at 09:08:06AM +0530, Saurabh Sengar wrote:
> On 2 December 2015 at 04:05, Greg KH wrote:
> > On Fri, Nov 06, 2015 at 05:46:30PM +0530, Saurabh Sengar wrote:
> >> added iounmap inorder to free memory mapped to base before returning
> >>
> >> Signed-off-by: Saurabh Sengar
> >>
On Tue, 1 Dec 2015, Steinar H. Gunderson wrote:
> >> + usbm->mem = mem;
> >> + usbm->offset = virt_to_phys(mem);
> >> + usbm->size = size;
> >> + usbm->ps = ps;
> >> + spin_lock_irqsave(&ps->lock, flags);
> >> + list_add_tail(&usbm->memlist, &ps->memory_list);
> >> + spin_unlock_irqrestore(
Hi Greg,
I am little unclear.
Now, shall I resend my patch on top of usb.git tree or linux.git tree.
Regards,
Saurabh
On 2 December 2015 at 21:15, Greg KH wrote:
> On Wed, Dec 02, 2015 at 09:08:06AM +0530, Saurabh Sengar wrote:
>> On 2 December 2015 at 04:05, Greg KH wrote:
>> > On Fri, Nov 06
On Wed, Dec 02, 2015 at 09:25:53PM +0530, Saurabh Sengar wrote:
> Hi Greg,
>
> I am little unclear.
> Now, shall I resend my patch on top of usb.git tree or linux.git tree.
The usb-next branch of the usb.git tree please.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
t
From: Thierry Reding
These new helpers simplify implementing multi-driver modules and
properly handle failure to register one driver by unregistering all
previously registered drivers.
Signed-off-by: Thierry Reding
---
drivers/usb/gadget/udc/dummy_hcd.c | 17 -
1 file changed,
Currently usb_port_resume waits for up to 2 seconds for CONNECT
status for SS devices only. This change will do the same thing for
non-SS devices even though the reason is a little different. This
will fix an issue where VBUS is turned off during system wide
"suspend to ram" and some 2.0 devices ta
So far, dwc3 has always missed request->zero
handling for every endpoint. Let's implement
that so we can handle cases where transfer must
be finished with a ZLP.
Note that dwc3 is a little special. Even though
we're dealing with a ZLP, we still need a buffer
of wMaxPacketSize bytes; to hide that d
On 12/02/2015 01:29 PM, Rogan Dawes wrote:
On Tue, Dec 01, 2015 at 06:17:54PM -0800, Greg KH wrote:
On Wed, Dec 02, 2015 at 01:02:28AM +, Rogan Dawes wrote:
Thanks Greg.
At a high level, what is needed to implement a new type of USB device gadget,
such as a display link device?
A lot o
On Wed, 2 Dec 2015, Al Cooper wrote:
> Currently usb_port_resume waits for up to 2 seconds for CONNECT
> status for SS devices only. This change will do the same thing for
> non-SS devices even though the reason is a little different. This
> will fix an issue where VBUS is turned off during system
added iounmap inorder to free memory mapped to base before returning
Signed-off-by: Saurabh Sengar
---
v2: changed logic a bit, because of recent patches pushed to usb-next
drivers/usb/host/pci-quirks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/pci-quir
Krzysztof Opasiak writes:
> That's why we will try to improve udl driver. Currently we try to
> setup machine at university which will run linux and then windows in
> virtual machine. We would like to connect dl to this computer, pass it
> to virtual machine and then use usbmon + wireshark and tr
On 12/02/2015 06:34 PM, Bjørn Mork wrote:
Krzysztof Opasiak writes:
That's why we will try to improve udl driver. Currently we try to
setup machine at university which will run linux and then windows in
virtual machine. We would like to connect dl to this computer, pass it
to virtual machine
On Wed, Dec 02, 2015 at 10:12:26AM -0500, Alan Stern wrote:
> On Wed, 2 Dec 2015, Rogan Dawes wrote:
>
> > Hi folks,
> >
> > I'm wondering if it is possible/reasonable to try to turn a linux
> > device with host and OTG ports into something that looks and acts
> > like a USB hub?
>
> Besides al
On Wed, Dec 02, 2015 at 06:00:21PM +0100, Krzysztof Opasiak wrote:
>
>
> On 12/02/2015 01:29 PM, Rogan Dawes wrote:
> >As mentioned originally, I'm trying to come up with an IP KVM, as
> >inexpensively as possible. Realising that the approach that I am following
> >will not allow me to interact
Hi Heikki,
On Wed, Dec 02, 2015 at 12:27:10PM +0200, Heikki Krogerus wrote:
> Hi David,
>
>
>
> > > +void intel_usb_mux_unregister(struct intel_usb_mux *mux)
> > > +{
> >
> > There are still 2 pending comments for this unregister function:
> >
> > 1) How about a protection against unbalanced
Hi Peter,
On 01/12/2015 at 18:17:16 +0100, Peter Rosin wrote :
> [] (ohci_hcd_at91_overcurrent_irq) from []
> (handle_irq_event_percpu+0x78/0x140)
> [] (handle_irq_event_percpu) from []
> (handle_irq_event+0x2c/0x40)
> [] (handle_irq_event) from []
> (handle_simple_irq+0x6c/0x80)
> [] (handle_s
Felipe Balbi writes:
> So far, dwc3 has always missed request->zero
> handling for every endpoint. Let's implement
> that so we can handle cases where transfer must
> be finished with a ZLP.
>
> Note that dwc3 is a little special. Even though
> we're dealing with a ZLP, we still need a buffer
> o
So far, dwc3 has always missed request->zero
handling for every endpoint. Let's implement
that so we can handle cases where transfer must
be finished with a ZLP.
Note that dwc3 is a little special. Even though
we're dealing with a ZLP, we still need a buffer
of wMaxPacketSize bytes; to hide that d
This series includes patches that were submitted earlier by Douglas
Anderson and Yunzhi Li to reduce delays during probe and get the
correct reset values of the hardware configuration registers. These
are patches 1-6 in this series.
I have additionally added patches to clean up the code around tha
Renamed dwc2_core_reset() to dwc2_core_reset_and_force_mode(). This
describes what it is doing more accurately. This is in preparation of
introducing a plain dwc2_core_reset() function that only performs the
reset and doesn't force the mode.
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c
dwc2_core_reset() was previously renamed to
dwc2_core_reset_and_force_mode(). Now add back dwc2_core_reset() which
performs only a basic core reset without forcing the mode.
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 22 ++
drivers/usb/dwc2/core.h | 1 +
2 files
From: Douglas Anderson
Calls to dwc2_core_reset() are currently very slow, taking at least
150ms (possibly more). It behooves us to take as many of these calls
out as possible.
It turns out that the calls in dwc2_fs_phy_init() and dwc2_hs_phy_init()
should (as documented in the code) only be ne
From: Yunzhi Li
We initiate dwc2 usb controller in BIOS, dwc2_core_reset() should
be called before dwc2_get_hwparams() to reset core registers to
default value. Without this the FIFO setting might be incorrect
because calculating FIFO size need power-on value of
GRXFSIZ/GNPTXFSIZ/HPTXFSIZ registe
From: Yunzhi Li
I found that the probe function of dwc2 driver takes much time
when kernel boot up. There are many long delays in the probe
function these take almost 1 second.
This patch trying to reduce unnecessary delay time.
In dwc2_core_reset() I see it use two at least 20ms delays to
wait
The dr_mode parameter was being checked against how the dwc2 module
was being configured at compile time. But it wasn't checked against
the hardware capabilities, nor were the hardware capabilities checked
against the compilation parameters.
This commit adds those checks and adjusts dr_mode to an
The reset is required to get reset values of the hardware parameters but
the force mode is not. Move the base reset into dwc2_get_hwparams() and
do the reset and force mode afterwards.
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 5 +
drivers/usb/dwc2/platform.c | 8 ++--
2
Added functions to query the GHWCFG2.OTG_MODE. This tells us whether the
controller hardware is configured for OTG, device-only, or host-only.
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 37 +
drivers/usb/dwc2/core.h | 13 +
2 files chan
These functions should go in core.h where they can be called from core,
device, or host.
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.h | 12
drivers/usb/dwc2/hcd.h | 12
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/d
From: Douglas Anderson
In (usb: dwc2: reset dwc2 core before dwc2_get_hwparams()) we added an
extra reset to the probe path for the dwc2 USB controllers. This
allowed proper detection of parameters even if the firmware had already
used the USB part.
Unfortunately, this extra reset is quite slow
According to the databook, the core soft reset should be done before
checking for AHBIDLE. The gadget version of core reset had it correct
but the hcd version did not. This fixes the hcd version.
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 17 +
1 file changed, 9 inser
From: Douglas Anderson
Previously dwc2_get_hwparams() was changing GUSBCFG and not putting it
back the way it was (specifically it set and cleared FORCEHOSTMODE).
Since we want to move dwc2_core_reset() _before_ dwc2_get_hwparams() we
should make sure dwc2_get_hwparams() isn't messing with things
From: Douglas Anderson
On some host-only DWC2 ports (like the one in rk3288) when we set
GUSBCFG_FORCEHOSTMODE in GUSBCFG and then read back, we don't see the
bit set. Presumably that's because the port is always forced to HOST
mode so there's no reason to implement these status bits.
Since we
Added functions to set force mode for host and device. These functions
will check the current mode and only force if needed.
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 54 +
1 file changed, 54 insertions(+)
diff --git a/drivers/usb/dwc
The gadget was using its own version of core reset. Use the common one
in core.c.
Signed-off-by: John Youn
---
drivers/usb/dwc2/gadget.c | 52 ++-
1 file changed, 2 insertions(+), 50 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dw
This commit adds separate functions for getting the host and device
specific hardware params. These functions check whether the parameters
need to be read at all, depending on dr_mode, and they force the mode
only if necessary. This saves some delays during probe.
Signed-off-by: John Youn
---
dr
The forcing of device mode is not needed in the gadget init. This is
already taken care of in the probe just before this is called.
Signed-off-by: John Youn
---
drivers/usb/dwc2/gadget.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/
The delay for force mode is only 25ms according to the databook.
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 91d63a8..a6fddbf 100644
--- a/drivers/usb/dwc2/core.c
On Wed, Dec 02, 2015 at 06:47:43PM +0100, Krzysztof Opasiak wrote:
>
>
> On 12/02/2015 06:34 PM, Bjørn Mork wrote:
> >Krzysztof Opasiak writes:
> >
> >>That's why we will try to improve udl driver. Currently we try to
> >>setup machine at university which will run linux and then windows in
> >>v
Hi Alexandre,
On 2015-12-02 19:20, Alexandre Belloni wrote:
> Hi Peter,
>
> On 01/12/2015 at 18:17:16 +0100, Peter Rosin wrote :
>> [] (ohci_hcd_at91_overcurrent_irq) from []
>> (handle_irq_event_percpu+0x78/0x140)
>> [] (handle_irq_event_percpu) from []
>> (handle_irq_event+0x2c/0x40)
>> [] (h
The interrupt handler, ohci_hcd_at91_overcurrent_irq may be called right
after registration. At that time, pdev->dev.platform_data is not yet set,
leading to a NULL pointer dereference.
Fixes: e4df92279fd9 (USB: host: ohci-at91: merge loops in
ohci_hcd_at91_drv_probe)
Reported-by: Peter Rosin
Te
On Wed, 2 Dec 2015, Rogan Dawes wrote:
> I have read the documentation for the USB gadgets (multi, hid,
> printer, serial), but noted that there seem to be quite a few more
> gadgets available in the source nowadays. e.g. audio, webcam . Are
> there any plans to document these at some stage?
You'
Currently usb_port_resume waits for up to 2 seconds for CONNECT
status for SS devices only. This change will do the same thing for
non-SS devices even though the reason is a little different. This
will fix an issue where VBUS is turned off during system wide
"suspend to ram" and some 2.0 devices ta
On 12/01/2015 11:44 PM, Rafał Miłecki wrote:
> On 1 December 2015 at 23:28, Greg KH wrote:
>> On Fri, Oct 23, 2015 at 11:36:56PM +0200, Hauke Mehrtens wrote:
>>> This patch adds support for the USB 3.0 controller in the bcm53xx Northstar
>>> SoC.
>>> These patches are based on top of usb-next.
>>
On Wed, 2 Dec 2015, Al Cooper wrote:
> Currently usb_port_resume waits for up to 2 seconds for CONNECT
> status for SS devices only. This change will do the same thing for
> non-SS devices even though the reason is a little different. This
> will fix an issue where VBUS is turned off during system
On Wed, Dec 02, 2015 at 02:48:38PM -0500, Alan Stern wrote:
> On Wed, 2 Dec 2015, Rogan Dawes wrote:
>
> > I have read the documentation for the USB gadgets (multi, hid,
> > printer, serial), but noted that there seem to be quite a few more
> > gadgets available in the source nowadays. e.g. audio,
Replace dma_pool_alloc and memset with a single call to dma_pool_zalloc.
Caught by coccinelle.
Signed-off-by: Geyslan G. Bem
---
drivers/usb/host/uhci-q.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/host/uhci-q.c b/drivers/usb/host/uhci-q.c
index da6f56d..c
Replace dma_pool_alloc and memset with a single call to dma_pool_zalloc.
Caught by coccinelle.
Signed-off-by: Geyslan G. Bem
---
drivers/usb/host/whci/qset.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/host/whci/qset.c b/drivers/usb/host/whci/qset.c
index d
Replace dma_pool_alloc and memset with a single call to dma_pool_zalloc.
Caught by coccinelle.
Signed-off-by: Geyslan G. Bem
---
drivers/usb/host/xhci-mem.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index
On Wed, 2 Dec 2015, Rogan Dawes wrote:
> > > Also, I saw "dummy_hcd.c", which sounds interesting.
> >
> > It is. It's meant for testing more than anything else; it provides an
> > emulated host and device controller pair, so you can test a gadget
> > driver even on a computer that doesn't have
Get rid of bool explicit comparisons.
Caught by Coccinelle.
Signed-off-by: Geyslan G. Bem
---
drivers/usb/host/fhci-tds.c | 2 +-
drivers/usb/host/whci/qset.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/fhci-tds.c b/drivers/usb/host/fhci-tds.c
index
When bool use true or false instead of 1 or 0.
Caught by coccinelle.
Signed-off-by: Geyslan G. Bem
---
drivers/usb/host/ehci-hcd.c | 2 +-
drivers/usb/host/ohci-hcd.c | 4 ++--
drivers/usb/host/u132-hcd.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/eh
On Wed, Dec 02, 2015 at 06:50:41PM -0300, Geyslan G. Bem wrote:
> When bool use true or false instead of 1 or 0.
>
> Caught by coccinelle.
>
> Signed-off-by: Geyslan G. Bem
> ---
> drivers/usb/host/ehci-hcd.c | 2 +-
> drivers/usb/host/ohci-hcd.c | 4 ++--
> drivers/usb/host/u132-hcd.c | 2 +-
>
2015-12-02 18:58 GMT-03:00 Greg Kroah-Hartman :
> On Wed, Dec 02, 2015 at 06:50:41PM -0300, Geyslan G. Bem wrote:
>> When bool use true or false instead of 1 or 0.
>>
>> Caught by coccinelle.
>>
>> Signed-off-by: Geyslan G. Bem
>> ---
>> drivers/usb/host/ehci-hcd.c | 2 +-
>> drivers/usb/host/ohc
When declaring/initializing bool use true instead of 1. If it's false,
there's no need to explicit initialize it, once it's default.
Caught by coccinelle.
Signed-off-by: Geyslan G. Bem
---
drivers/usb/host/ehci-hcd.c | 2 +-
drivers/usb/host/ohci-hcd.c | 4 ++--
drivers/usb/host/u132-hcd.c | 2
On Wed, Dec 02, 2015 at 07:09:19PM -0300, Geyslan G. Bem wrote:
> When declaring/initializing bool use true instead of 1. If it's false,
> there's no need to explicit initialize it, once it's default.
>
> Caught by coccinelle.
>
> Signed-off-by: Geyslan G. Bem
> ---
> drivers/usb/host/ehci-hcd.
Replace BUG() with BUG_ON().
Caught by coccinelle.
Signed-off-by: Geyslan G. Bem
---
drivers/usb/host/oxu210hp-hcd.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/oxu210hp-hcd.c b/drivers/usb/host/oxu210hp-hcd.c
index 1f139d8..bc74aca 100644
--- a/
2015-12-02 19:16 GMT-03:00 Greg Kroah-Hartman :
> On Wed, Dec 02, 2015 at 07:09:19PM -0300, Geyslan G. Bem wrote:
>> When declaring/initializing bool use true instead of 1. If it's false,
>> there's no need to explicit initialize it, once it's default.
>>
>> Caught by coccinelle.
>>
>> Signed-off-b
When assigning bool use true instead of 1. If declaring it as static and
it's false there's no need to initialize it, since static variables are
zeroed by default.
Caught by coccinelle.
Signed-off-by: Geyslan G. Bem
---
drivers/usb/host/ehci-hcd.c | 2 +-
drivers/usb/host/ohci-hcd.c | 4 ++--
d
2015-12-02 19:23 GMT-03:00 Geyslan G. Bem :
> 2015-12-02 19:16 GMT-03:00 Greg Kroah-Hartman :
>> On Wed, Dec 02, 2015 at 07:09:19PM -0300, Geyslan G. Bem wrote:
>>> When declaring/initializing bool use true instead of 1. If it's false,
>>> there's no need to explicit initialize it, once it's defaul
On Wed, Dec 02, 2015 at 10:54:52AM -0500, Alan Stern wrote:
>> [ 28.796244] DMAR: Allocating domain for 2-2 failed
> I don't know what the reason is for that. It may be that your kernel
> isn't configured to allocate as much coherent memory as you are asking
> for. We'll have to investigate
On Thu, Dec 03, 2015 at 12:51:14AM +0100, Steinar H. Gunderson wrote:
> I'm thinking; maybe should the memory not be allocated against the USB
> device, but against the controller it hangs on? (Note that it complains about
> allocating the _domain_, not the memory itself.) Do you know if that's
> p
On 11/29/2015 9:29 PM, changbin...@intel.com wrote:
> From: "Du, Changbin"
>
> With the first patch, enable a enabled ep will return -EBUSY.
> The second patch forbid queuing on disabled ep to avoid panic.
The usb_ep->enabled flag was added in 4.4.
It looks like these same checks are also adde
> On 11/29/2015 9:29 PM, changbin...@intel.com wrote:
> > From: "Du, Changbin"
> >
> > With the first patch, enable a enabled ep will return -EBUSY.
> > The second patch forbid queuing on disabled ep to avoid panic.
>
>
> The usb_ep->enabled flag was added in 4.4.
>
> It looks like these same c
if a full speed hub connects to a high speed hub which
supports MTT, the MTT field of its slot context will be set
to 1 when xHCI driver setups an xHCI virtual device in
xhci_setup_addressable_virt_dev(); once usb core fetch its
hub descriptor, and need to update the xHC's internal data
structures
when a LS or FS device doesn't connect though a HS hub,
the @bPkts field of its periodic endpoint context should
be set to 1.
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk-sch.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhc
77 matches
Mail list logo