Hi,
Alan Stern writes:
>> I agree with Alan that the spinlock must be dropped before calling
>> usb_ep_queue. An example can be found in the ep0_queue function of
>> the f_mass_storage driver.
>
> Thanks for the note of support, but you must be looking at a different
> version of the f_mass_sto
Hi,
Benjamin Herrenschmidt writes:
> +static int ast_vhub_rep_desc(struct ast_vhub_ep *ep,
> + u8 desc_type, u16 len)
> +{
> + const void *desc;
> + size_t dsize;
> +
> + EPDBG(ep, "GET_DESCRIPTOR(type:%d)\n", desc_type);
> + switch(desc_type) {
> +
On Tue, 2018-03-27 at 10:30 +0300, Felipe Balbi wrote:
> Hi,
>
> Benjamin Herrenschmidt writes:
>
>
>
> > +static int ast_vhub_rep_desc(struct ast_vhub_ep *ep,
> > +u8 desc_type, u16 len)
> > +{
> > + const void *desc;
> > + size_t dsize;
> > +
> > + EPDBG(ep, "GE
On 26/03/18 23:38, Martin Blumenstingl wrote:
> Before this patch usb_phy_roothub_init served two purposes (from a
> caller's point of view - like hcd.c):
> - parsing the PHYs and allocating the list entries
> - calling phy_init on each list entry
>
> While this worked so far it has one disadvanta
On 26/03/18 23:38, Martin Blumenstingl wrote:
> If the USB controller can wake up the system (which is the case for
> example with the Mediatek USB3 IP) then we must not call phy_exit during
> suspend to ensure that the USB controller doesn't have to re-enumerate
> the devices during resume.
> Howe
On Tue, Mar 27, 2018 at 11:24:08AM +0300, Roger Quadros wrote:
> On 26/03/18 23:38, Martin Blumenstingl wrote:
> > Before this patch usb_phy_roothub_init served two purposes (from a
> > caller's point of view - like hcd.c):
> > - parsing the PHYs and allocating the list entries
> > - calling phy_in
On 25.03.2018 14:31, Juho Tykkälä wrote:
Hello,
Similar panic occurs on manually compiled 4.14.0.
However, same issue occurs like bellow on 4.9.82 (debian compiled with package
linux-image-4.9.0-6-amd64)
One failure behavior:
[70684.574901] xhci_hcd :00:14.0: ERROR Transfer event for dis
From: Anurag Kumar Vulisha
The code logic in dwc3_prepare_one_trb() incorrectly uses the address
and length fields present in req packet for mapping TRB's instead of
using the address and length fields of scattergather lists. This patch
correct's the code to use sg->address and sg->length when sc
From: Anurag Kumar Vulisha
The present code correctly fetches the req which were previously not
queued from the started_list but fails to continue queuing from the sg
where it previously stopped queuing (because of the unavailable TRB's).
This patch correct's the code to continue queuing from the
On Tue, 27 Mar 2018, Felipe Balbi wrote:
>
> Hi,
>
> Alan Stern writes:
> > On Mon, 26 Mar 2018, Felipe Balbi wrote:
> >
> >> Mention that ->complete() should never be called from within
> >> usb_ep_queue().
> >>
> >> Signed-off-by: Felipe Balbi
> >> ---
> >> drivers/usb/gadget/udc/core.c |
Improve the kerneldoc for usb_ep_queue() to note explicitly that the
request's completion routine will be called if and only if the return
value is 0. The corresponding fact about usb_submit_urb() for the
host-side API has long been documented, and this has always been the
intention for the gadget
Hi Rob,
2018-03-27 6:23 GMT+08:00 Rob Herring :
> On Tue, Mar 20, 2018 at 05:15:04PM +0800, ShuFan Lee wrote:
>> From: ShuFan Lee
>>
>> Add device tree binding document for Richtek RT1711H Type-C chip driver
>>
>> Signed-off-by: ShuFan Lee
>> ---
>> .../devicetree/bindings/usb/richtek,rt1711h.t
On 2018-03-27 13:20, Mathias Nyman wrote:
Could you enable xhci traces with 4.14 or later, and send me the
output:
mount -t debugfs none /sys/kernel/debug
echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable
Then send me the /sys/ker
On Mon, 26 Mar 2018, Jonathan Liu wrote:
> > I am experiencing a USB function call hang from userspace with OCHI
> > (full speed USB device) after updating from Linux 4.14.15 to 4.14.24
> > and noticed this commit.
> >
> > Here is the Linux 4.14.24 kernel stack trace (extracted from SysRq+w
> > an
Hi all,
This is a follow up mail from the discussion of thread
https://marc.info/?l=linux-usb&m=149485247607564&w=2
Our working group "VISA for Linux" (IVI Foundation, www.ivifoundation.org)
wants to extend the Linux USBTMC driver (linux/drivers/usb/class/usbtmc.c)
that can communicate with th
This is a follow-up to my previous series "initialize (multiple) PHYs
for a HCD": [0].
Roger Quadros reported [1] that it "is breaking low power cases on TI
SoCs when USB is in host mode". He further explains that "Not doing the
phy_exit() here [when entering suspend] leaves the clocks enabled on
Before this patch usb_phy_roothub_init served two purposes (from a
caller's point of view - like hcd.c):
- parsing the PHYs and allocating the list entries
- calling phy_init on each list entry
While this worked so far it has one disadvantage: if we need to call
phy_init for each PHY instance then
If the USB controller can wake up the system (which is the case for
example with the Mediatek USB3 IP) then we must not call phy_exit during
suspend to ensure that the USB controller doesn't have to re-enumerate
the devices during resume.
However, if the USB controller cannot wake up the system (wh
On Tue, Mar 27, 2018 at 08:57:27PM +0200, guido.kie...@rohde-schwarz.com wrote:
> Hi all,
>
> This is a follow up mail from the discussion of thread
> https://marc.info/?l=linux-usb&m=149485247607564&w=2
>
> Our working group "VISA for Linux" (IVI Foundation, www.ivifoundation.org)
>
> wants t
19 matches
Mail list logo
