=
> + USB_SS_PORT_LS_POLLING))
> + need_debounce_delay = true;
> +
> /* Clear status-change flags; we'll debounce later */
> if (portchange & USB_PORT_STAT_C_CONNECTION) {
> need_debounce_delay = true;
Acked-by: Alan Stern
gt; like usb_lock_device/usb_unlock_device calls around remote-wake and usbfs
> ioctl
> should help with race condition, right?
No, they will not help. This is not a race between two different parts
of the kernel both trying to communicate with the device; it is a race
between the kernel and the user. usb_lock_device doesn't prevent the
user from interacting with the device. :-)
Alan Stern
er ioctl to the usbfs device file
descriptor). When usbfs gets an ioctl, it will automatically wake up
the device by incrementing the runtime PM usage counter.
Alan Stern
On Mon, 12 Nov 2018, Mayuresh Kulkarni wrote:
> On Fri, 2018-11-09 at 10:33 -0500, Alan Stern wrote:
> > On Fri, 9 Nov 2018, Mayuresh Kulkarni wrote:
> >
> > >
> > > >
> > > > The driver has no way to tell whether the resume was caused by the
med anyway, when the user interacts with it.
> Here the "get PM ref-count" should cause the resume of root-hub and its port
> followed by resume of device, right?
> As I understand, as a result of this operation, the host controller should
> bring
> back the link to L0.
Righ
On Thu, 8 Nov 2018, Mayuresh Kulkarni wrote:
> On Wed, 24 Oct 2018 10:10:32 -0400
> Alan Stern wrote:
>
> > On Wed, 24 Oct 2018, Mayuresh Kulkarni wrote:
> >
> > > On Mon, 22 Oct 2018 10:24:46 -0400
> > > Alan Stern wrote:
> > >
dma_pool_destroy (ohci->ed_cache);
> - ohci->ed_cache = NULL;
> - }
> + dma_pool_destroy(ohci->td_cache);
> + ohci->td_cache = NULL;
> + dma_pool_destroy(ohci->ed_cache);
> + ohci->ed_cache = NULL;
> }
>
> /*-*/
Acked-by: Alan Stern
On Thu, 1 Nov 2018, Mayuresh Kulkarni wrote:
> On Mon, 22 Oct 2018 10:24:46 -0400
> Alan Stern wrote:
>
> Apologies for late response on this thread, had been on PTOs and also
> checking internally about the pros/cons of suggested approach.
>
> > On Mon, 22 Oct 2
On Fri, 26 Oct 2018, Mathias Nyman wrote:
> On 25.10.2018 20:28, Alan Stern wrote:
> > On Thu, 25 Oct 2018, Mathias Nyman wrote:
> >
> >> On 25.10.2018 12:52, Hao Wei Tee wrote:
> >>> On 25/10/18 4:45 PM, Mathias Nyman wrote:
> >>>> Reproduc
er the higher-layer driver
has had a chance to unlink the URBs that may be in the endpoint queue.
The driver may even want to reset the device.
> There is a patch in usb-next that might help.
> f8f80be xhci: Use soft retry to recover faster from transaction errors
>
> It soft resets the halted host side endpoint, clears the halt without
> clearing the sequence number.
>
> -Mathias
Alan Stern
er. It does
> wrap, maybe you are seeing a reading after a wrap?
The value won't wrap from 12318 to 12292 (the values reported by
Daniel). In fact, it won't wrap until it gets above at least 16383,
since values that high are required for calculating the SOF number.
Alan Stern
50] ehci-pci :00:0a.1: request c302d23e would overflow
> (4104+288 >= 4096)
>
> The backwards jump screws up periodic scheduling and culminates in the
> EFBIG error I've been seeing. I'm suspecting buggy EHCI hardware, but
> my question is... could anything else cause this?
Not
_delay" based on connected device as well as current
> use-case running in the user-space we are targeting (which is
> Android, FYI).
It's possible that Android has made some changes to the way autosuspend
is handled.
Alan Stern
On Wed, 24 Oct 2018, Mayuresh Kulkarni wrote:
> On Mon, 22 Oct 2018 10:24:46 -0400
> Alan Stern wrote:
>
> > On Mon, 22 Oct 2018, Oliver Neukum wrote:
> >
> > > On Do, 2018-10-18 at 13:42 -0400, Alan Stern wrote:
> > > > On
On Mon, 22 Oct 2018, Oliver Neukum wrote:
> On Do, 2018-10-18 at 13:42 -0400, Alan Stern wrote:
> > On Thu, 18 Oct 2018, Mayuresh Kulkarni wrote:
> >
> > > > The only way to make the ioctl work properly is to have it do a
> > > > runtime-PM put at the
; >
> > ##enable Generic eMMC Flasher:
> > ##make sure, these tools are installed: dosfstools rsync
> > #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh
> >
> > #jmmt disable dma for musb
> > cmdline=musb_hdrc.use_dma=0
The "musb_hdrc.use_dma=0" should have been appended to the earlier
entry, not added separately.
Alan Stern
e a matter of the ARM processor clock frequency? Beagle
> features ARM TI AM335x at 1GHz
I do not know.
Alan Stern
-121 errors indicate times when the amount
of data received was less than that. For example, sometimes the camera
only sent 8836 bytes, or 4228, or 14468, or 11396. At least, that's
what the BeagleBone thinks it received.
Alan Stern
> Let see if this info suggests you or Bin any actions to check
&g
ner for that driver.
>
> Ok, could you please provide me the e-mail address where to write?
The maintainer is Bin Liu (CC'ed). And you should also remember to CC
the linux-usb mailing list.
Alan Stern
> Thanks
>
>
> On Thu, Oct 18, 2018 at 9:44 PM Alan Stern wrote:
> >
plug the device
into a standard PC rather than the BeagleBone?
Second question: Have you tried looking at usbmon traces to see where
the communication starts to fail?
> Should I load different usb modules in the system kernel? Should I
> modify a given module?
It certainly looks like a problem in the musb-hdrc driver. You might
try asking the maintainer for that driver.
Alan Stern
ed (failed suspend)
4. Device did suspend but a signal was received before the device
resumed.
> * In any of above cases, we need to resume device.
> */
> usb_autoresume_device(dev);
>
> ps->resume_done = false;
>
> "ps->resume_done = true;" will be done by the runtime resume call-back.
Exactly. You got it. Will that let you accomplish what you want?
Alan Stern
rminated by the device resuming after a
suspend.
In the end, though, do you really care whether the device suspended?
Alan Stern
On Wed, 17 Oct 2018, Oliver Neukum wrote:
> On Di, 2018-10-16 at 10:46 -0400, Alan Stern wrote:
> > On Tue, 16 Oct 2018, Mayuresh Kulkarni wrote:
> >
> > > 1. User space decides when it is time to suspend the device and calls
> > > this ioctl. The implmenta
On Tue, 16 Oct 2018, Oliver Neukum wrote:
> On Mo, 2018-10-15 at 09:50 -0400, Alan Stern wrote:
> >
> > It seems that a better approach would be to have an ioctl which would:
> >
> > fail if there are any active user URBs;
> >
> > drop t
ng else.
> Apologies if this is implied but I am just trying to get my head
> around with the proposal, hence being verbose.
Perfectly okay. As Oliver mentioned, it's foolish to design an API
that doesn't do what the user wants.
Alan Stern
On Tue, 16 Oct 2018, Mayuresh Kulkarni wrote:
> > How about instead having a mechanism whereby your usrspace driver can
> > tell when the device does a remote wakeup? At that point it could
> > submit an URB via usbfs and receive the async notification.
> >
> >
transfers down after is_in has been set to the correct value.
Signed-off-by: Alan Stern
Reported-and-tested-by: syzbot+24a30223a4b609bb8...@syzkaller.appspotmail.com
Fixes: 7a68d9fb8510 ("USB: usbdevfs: sanitize flags more")
CC: Oliver Neukum
CC:
---
[as1880]
drivers/usb/core/de
On Mon, 15 Oct 2018, Oliver Neukum wrote:
> On Do, 2018-10-11 at 14:29 -0400, Alan Stern wrote:
> > On Thu, 11 Oct 2018, Mayuresh Kulkarni wrote:
> [..]
> > > We are looking into closing the device instance during normal operation
> > > i.e.: only
_coherent() with dma_addr instead of
> remap_pfn_range(), however, I did not get it to work. Can anyone help
> out?
This is question is more about the kernel's architecture-specific
design than about USB. You should ask on the
linux-a...@vger.kernel.org, linux-arm-ker...@lists.infradead.org, and
linux-ker...@vger.kernel.org mailing lists.
Alan Stern
Queue an URB -> suspend (L2)
> * Device does remote wake & sends async notification
> * URB above returns with that notification
It won't work like that. When a device goes into suspend there can't
be any outstanding URBs.
How about instead having a mechanism whereby your usrspace driver can
tell when the device does a remote wakeup? At that point it could
submit an URB via usbfs and receive the async notification.
Alan Stern
On Tue, 9 Oct 2018, Christoph Groth wrote:
> On Tue, 9 Oct 2018, Alan Stern wrote:
>
> > On Mon, 8 Oct 2018, Christoph Groth wrote:
> >
> > > On Sun, 7 Oct 2018, Alan Stern wrote:
> > >
> > > > On Fri, 5 Oct 2018, Christoph Groth wrote:
> &
be "enabled"?
>
> I don't see anything regarding this in specification (also I cannot find
> anything like this in linux xhci driver).
See the description of the Route String and the Root Hub Port Number
entries in the slot context.
Alan Stern
> Motivation is just s
On Mon, 8 Oct 2018, Christoph Groth wrote:
> On Sun, 7 Oct 2018, Alan Stern wrote:
>
> > On Fri, 5 Oct 2018, Christoph Groth wrote:
> >
> > > I would be grateful for hints on how solve or further debug this
> > > problem.
> >
> > A good start woul
gt; open/close and appropriate ioctl calls, with special handling for async URB
> > submission)?
>
> Technically this is possible, but it is a bad idea.
>
> > 3. Will (2) break any known existing device(s)?
>
> Yes, it would and that makes it a bad idea.
In theory we could add ioctls to perform the runtime PM put and get
operations.
Alan Stern
On Sun, 7 Oct 2018, Klaus Kusche wrote:
> Hello,
>
> On 03/10/2018 16:02, Alan Stern wrote:
> > Well, what happens if you add only US_FL_BROKEN_FUA without
> > US_FL_IGNORE_UAS? Does it work?
>
> Tried all four combinations with gentoo 4.18.12.
> Just US_FL_I
uld be grateful for hints on how solve or further debug this
> problem.
A good start would be to post a usbmon trace showing what happens when
you plug in the Garmin device. Also you could post the dmesg log,
because it might contain some useful information about what happened
during the failure.
Alan Stern
On Wed, 3 Oct 2018, Klaus Kusche wrote:
> Hello,
>
> On 09/09/2018 21:28, Alan Stern wrote:
> > On Sun, 9 Sep 2018, Klaus Kusche wrote:
> >
> >> Hello,
> >>
> >> On 01/09/2018 17:38, Alan Stern wrote:
> >>> However, the USB layer d
The net2280 UDC driver invokes the gadget driver's ->disconnect()
callback routine when the net2280_pullup() routine turns off the D+
pullup. This is now unnecessary, because the gadget core performs the
callback on our behalf. This patch removes the unneeded callback.
Signed-off-by: Alan St
e them, as they are now unnecessary. Until all those
patches are merged gadget drivers may receive extra ->disconnect()
callbacks, but this should be harmless.
Signed-off-by: Alan Stern
---
[as1874]
drivers/usb/gadget/udc/core.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
Index
On Tue, 2 Oct 2018, Felipe Balbi wrote:
> Hi,
>
> Alan Stern writes:
> > Felipe:
> >
> > The following patches concern ->disconnect() callbacks made when a
> > gadget's D+ pullup is turned off. Currently we don't have a fixed rule
> > for suc
re/driver.c:513:21: warning:
> > variable 'udev' set but not used [-Wunused-but-set-variable]
> >
> > Signed-off-by: YueHaibing
> > Acked-by: Alan Stern
> > ---
> > drivers/usb/core/driver.c | 3 ---
> > 1 file changed, 3 deletions(-)
>
> This patch breaks the
/sys/bus/usb/devices/.../(hub
> interface)/usbY-portX/quirks
Ditto
> Date:May 2018
> Contact: Nicolas Boichat
> Description:
> @@ -211,7 +221,7 @@ Description:
> used to help make enumeration work better on some high speed
> devic
524,8 +523,6 @@ int usb_driver_claim_interface(struct usb_driver *driver,
> if (!iface->authorized)
> return -ENODEV;
>
> - udev = interface_to_usbdev(iface);
> -
> dev->driver = >drvwrap.driver;
> usb_set_intfdata(iface, priv);
> iface->needs_binding = 0;
Acked-by: Alan Stern
fix" this? I have verified the USB reader
> (FCR-HS3) is running the latest
> firmware from Kingston.
>
> I am running Linux v4.19-rc4-89-g6ad49fa1993d.
There's no easy way to tell what the cause is, but you can get a little
more information by collecting a usbmon trace while plugging in the
media reader.
Alan Stern
e_ to do it. It is a small optimization; an attempt to
avoid schedule collisions between interrupt transactions and
isochronous transactions. The effect of the "-" is that the code tries
frames in backward order when it is scheduling isochronous URBs -- as
opposed to trying frames in forward order when scheduling periodic
URBs.
It isn't important.
Alan Stern
On Sat, 15 Sep 2018, Alistair Buxton wrote:
> On 15 September 2018 at 21:11, Alan Stern wrote:
> > On Sat, 15 Sep 2018, Alistair Buxton wrote:
>
> > Wrong -- bInterval is a maximum value only and the host is free to poll
> > more quickly.
>
> I can only say that
r data, and under method 2. I can only be informed that the host
> asked for data
> *after* the data has been sent, at which point it is too late.
>
> So am I missing something here or is this just not possible from userspace?
It is not possible to know when the host has asked for data until after
the data has been sent. This is true for kernel drivers as well as for
userspace drivers.
Alan Stern
, available for use in many
places, we want to to be more robust. This patch makes it return NULL
whenever the config argument is NULL.
Signed-off-by: Alan Stern
Reported-by: syzbot+19c3aaef85a89d451...@syzkaller.appspotmail.com
CC:
---
[as1879]
drivers/usb/core/usb.c |2 ++
1 file changed
passed back to the caller, the iface->dev.driver pointer remains set
and iface->condition remains equal to USB_INTERFACE_BOUND.
This patch adds proper error handling to usb_driver_claim_interface().
Signed-off-by: Alan Stern
Reported-by: syzbot+f84aa7209ccec8295...@syzkaller.appspotmail.
returning.
Signed-off-by: Alan Stern
Fixes: 8306095fd2c1 ("USB: Disable USB 3.0 LPM in critical sections.")
CC:
---
[as1877]
drivers/usb/core/driver.c | 15 ---
1 file changed, 15 deletions(-)
Index: usb-4.x/drivers/usb/cor
On Sun, 9 Sep 2018, Klaus Kusche wrote:
> Hello,
>
> On 01/09/2018 17:38, Alan Stern wrote:
> > However, the USB layer does set certain quirk bits which can cause
> > those other parts to avoid sending certain commands. Perhaps your
> > controller needs the BROKEN
usb 3-1: SerialNumber: 12345
As you can see, it shows that the computer failed to communicate with
the usb 3-1 device the first time it tried, but it succeeded the second
time. There's nothing wrong with this. In particular, it isn't a bug.
Alan Stern
t makes orking systems fail.
> >
> > Ah, good point.
>
> Well, but do we want to do this in the next major release even if we
> cannot do it in a stable release?
>
> > I guess they were hitting the same dev_WARN() messages
> > today anyway, right?
>
> Y
you think g_hid doesn't support
feature reports?
> Is it planned to be added ?
I doubt that anybody is planning to modify g_hid. But I could be
wrong; people don't always announce their plans on the mailing list.
Alan Stern
freeing dropped endpoint ring buffers.
> + * Make sure the interface endpoints are flushed before that
> + */
> + usb_disable_interface(dev, iface, false);
>
> /* Make sure we have enough bandwidth for this alternate interface.
>* Remove the current alt setting and add the new alt setting.
Acked-by: Alan Stern
ignore the ->zero flag in cases where the
message length isn't an exact multiple of wMaxPacketSize. This is what
makes gadgetfs's behavior correct.
Alan Stern
dev_err(dev, "PCI post-resume error %d!\n", retval);
> - if (hcd->shared_hcd)
> - usb_hc_died(hcd->shared_hcd);
> usb_hc_died(hcd);
> }
> }
Acked-by: Alan Stern
On Tue, 4 Sep 2018, Johan Hovold wrote:
> On Tue, Sep 04, 2018 at 12:21:09PM +0200, Oliver Neukum wrote:
> > On Di, 2018-09-04 at 11:31 +0200, Johan Hovold wrote:
> > > On Tue, Sep 04, 2018 at 10:44:41AM +0200, Oliver Neukum wrote:
> > > > For those people who run with panic_on_warn a WARN()
certain quirk bits which can cause
those other parts to avoid sending certain commands. Perhaps your
controller needs the BROKEN_FUA flag (see the existing entries in
drivers/usb/storage/unusual_devs.h with that flag).
Alan Stern
> > Have you tried running e2fsck -f on the ext4 filesyste
for this alternate interface.
>* Remove the current alt setting and add the new alt setting.
>*/
Please also update the kerneldoc for this function. It should now
specify that if the request fails, the original interface altsetting
may be disabled. Drivers cannot rely on any particular alternate
setting being in effect after a failure.
Alan Stern
On Fri, 31 Aug 2018, Andrey Konovalov wrote:
> On Thu, Aug 30, 2018 at 10:50 PM, Alan Stern
> wrote:
> > On Thu, 30 Aug 2018, Andrey Konovalov wrote:
> >
> >> Hi Alan,
> >>
> >> I have a few questions about gadgetfs.
> >>
> >&
g drivers into the kernel (modprobe'ing
them) and creating nodes under /dev. But a driver that is already
present in the kernel doesn't need to be modprobe'd, and the files
under /sys are created automatically by the kernel rather than by udev.
Does that answer your questions?
Alan Stern
ests a few times, and some code will fail right away.
> The questions arose when I started implementing a gadgetfs like
> interface, that allows to respond to every USB packet (including the
> initial control requests) from a userspace app.
>
> Thanks!
You're welcome.
Alan Stern
On Wed, 29 Aug 2018, Klaus Kusche wrote:
> Hello,
>
> On 24/08/2018 19:28, Alan Stern wrote:
> > On Fri, 24 Aug 2018, Klaus Kusche wrote:
> >> On 24/08/2018 17:39, Alan Stern wrote:
> >>> On Fri, 24 Aug 2018, Klaus Kusche wrote:
> >>>> On 24/
On Tue, 28 Aug 2018, Nuno Gonçalves wrote:
> On Mon, Aug 20, 2018 at 4:23 PM Alan Stern wrote:
> > It is expected. No notifications for host-initiated ejects were ever
> > put into the f_mass_storage driver.
> >
> > I have never tried to use f_mass_storage under confi
.
Without the delay, there is no remaining incentive for skipping the
reset when the controller is already in the RESET state. This patch
removes the test, issuing the command unconditionally, and removes the
following delay.
Signed-off-by: Alan Stern
Suggested-by: Paul Menzel
Tested-by: Paul
On Sat, 25 Aug 2018, Paul Menzel wrote:
> Dear Alan,
>
>
> Am 03.07.2018 um 20:40 schrieb Alan Stern:
> > I no longer have suitable hardware for testing this patch. If anyone
> > with an OHCI host controller could try it out, I would like to hear if
> > it ca
effect
at all? Strictly speaking, the device should NAK until it is ready and
then it should precede. The number and timing of the NAKs should not
change this.
Alan Stern
On Fri, 24 Aug 2018, Klaus Kusche wrote:
>
> On 24/08/2018 17:39, Alan Stern wrote:
> > On Fri, 24 Aug 2018, Klaus Kusche wrote:
> >> On 24/08/2018 16:15, Alan Stern wrote:
> >>> On Fri, 24 Aug 2018, Klaus Kusche wrote:
> >>>> I entered the
On Fri, 24 Aug 2018, Klaus Kusche wrote:
> Hello,
>
> On 24/08/2018 16:15, Alan Stern wrote:
> > On Fri, 24 Aug 2018, Klaus Kusche wrote:
> >
> >> Hello,
> >>
> >> I entered the following USB bug into kernel bugzilla yesterday:
> >>
h other controllers."
>
> Many thanks in advance for any help!
Please provide the output from "dmesg".
Alan Stern
re ever
put into the f_mass_storage driver.
I have never tried to use f_mass_storage under configfs. When you do,
does the driver create its normal sysfs files?
Alan Stern
> Any insight?
>
> Thanks!
> Nuno
>
>
On Wed, 15 Aug 2018, Martin Hicks wrote:
> On Fri, Aug 03, 2018 at 12:56:37PM -0400, Alan Stern wrote:
> > On Fri, 3 Aug 2018, Martin Hicks wrote:
> >
> > >
> > > Hi,
> > >
> > > I've run into a huge performance gap between running a g_mass_
04
These messages indicate the device is electronically detaching itself
from the bus and then reattaching itself, over and over again, about
four times per second.
Have you tried using this device on another computer? Do you have
another full-speed device you can try plugging into that port?
Alan Stern
/gadget/udc/Kconfig
> @@ -193,6 +193,7 @@ config USB_RENESAS_USB3
> tristate 'Renesas USB3.0 Peripheral controller'
> depends on ARCH_RENESAS || COMPILE_TEST
> depends on EXTCON
> + depends on USB || !USB
Is this some weird standard idiom? It looks really strange.
Alan Stern
The net2280 UDC driver invokes the gadget driver's ->disconnect()
callback routine when the net2280_pullup() routine turns off the D+
pullup. This is now unnecessary, because the gadget core performs the
callback on our behalf. This patch removes the unneeded callback.
Signed-off-by: Alan St
e them, as they are now unnecessary. Until all those
patches are merged gadget drivers may receive extra ->disconnect()
callbacks, but this should be harmless.
Signed-off-by: Alan Stern
---
[as1874]
drivers/usb/gadget/udc/core.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
Index
ers don't need
to worry about it.
The second patch removes a callback from net2280's pullup routine,
because it is now unneeded.
Other UDC drivers may also need to have their callbacks removed; the
only one I have checked is dummy-hcd (which is okay).
Alan Stern
0x, 0x,
> + "DJI",
> + "CineSSD",
> + USB_SC_DEVICE, USB_PR_DEVICE, NULL,
> + US_FL_NO_ATA_1X),
> +
> /*
> * Reported by Frederic Marchal
> * Mio Moov 330
Acked-by: Alan Stern
to reduce zconf parser
> workload a little.
>
> Dependencies of USB_UAS build option are left aside deliberately.
>
> Signed-off-by: Vladimir Zapolskiy
> ---
For both patches in this series:
Acked-by: Alan Stern
--
To unsubscribe from this list: send the line "unsubscri
On Thu, 9 Aug 2018, Felipe Balbi wrote:
>
> Hi,
>
> Alan Stern writes:
> >> Alan Stern writes:
> >> > Felipe:
> >> >
> >> > The documentation doesn't state whether a gadget driver's
> >> > ->disconnect() callback will
ent from all the other
entries in this file. They are sub-drivers for usb-storage, whereas
uas is an almost totally separate driver. Yes, it does depend on
usb-storage now, but that's subject to change in the future since the
overlap between the two drivers is quite small.
Just put the UA
ler.
Finally, the patch changes where the ->disconnect() callback is
invoked when net2280_pullup() turns the pullup off. Rather than
making the callback from within stop_activity() at a time when dropping
the private lock could be unsafe, the callback is moved to a point
after the lock has a
; Event SUSPEND
> Event DISABLE
> Event ENABLE
> ev=in; ret=2112
> ev=out; ret=0
> submit: in
> submit: out
> Event SUSPEND
> Event DISABLE
Thank you for testing. I will submit the patch.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb&q
On Wed, 8 Aug 2018, Felipe Balbi wrote:
>
> Hi,
>
> Alan Stern writes:
> > Felipe:
> >
> > The documentation doesn't state whether a gadget driver's
> > ->disconnect() callback will be invoked when usb_gadget_disconnect()
> > runs. Probab
problem
in net2280 remained.
I think the patch below (which is mostly a reversion of the relevant
parts of f16443a034c7) should fix it. Can you please test the patch
and let me know?
Alan Stern
Index: usb-4.x/drivers/usb/gadget/udc/net2280.c
=
ent feeling is that ->disconnect() should be
invoked only when Vbus turns off, but I can't guarantee that all UDCs
will do this.
How do you feel about documenting this ambiguity as in the patch below?
If you think this is okay, I'll submit it formally.
Alan Stern
Index: usb-4.x/drivers/usb/gadg
On Mon, 6 Aug 2018, Nick Desaulniers wrote:
> On Mon, Aug 6, 2018 at 11:27 AM Alan Stern wrote:
> >
> > On Mon, 6 Aug 2018, Nick Desaulniers wrote:
> >
> > > On Mon, Jul 30, 2018 at 1:24 PM Alan Stern
> > > wrote:
> > > >
On Mon, 6 Aug 2018, Nick Desaulniers wrote:
> On Mon, Jul 30, 2018 at 1:24 PM Alan Stern wrote:
> >
> > On Mon, 30 Jul 2018, Nick Desaulniers wrote:
> >
> > > Hello,
> > > Today my usb keyboard stopped working:
> > >
> > > [513672.83
On Sat, 4 Aug 2018, Muni Sekhar wrote:
> On Fri, Aug 3, 2018 at 1:15 AM, Alan Stern wrote:
> > On Thu, 2 Aug 2018, Muni Sekhar wrote:
> >
> >> I see that CONFIG_PM_RUNTIME & CONFIG_USB_SUSPEND are not enabled. Is that
> >> fine?
> >
> > The
aw partition accesses. You're better off asking the
people responsible for the block layer about that.
Alan Stern
--
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
ll depends on how the driver is written. But if you
unload the driver then the device certainly ought to go into runtime
suspend.
Alan Stern
--
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
On Thu, 2 Aug 2018, Muni Sekhar wrote:
> On Thu, Aug 2, 2018 at 7:08 PM, Alan Stern wrote:
> > On Thu, 2 Aug 2018, Muni Sekhar wrote:
> >
> >> [ Please keep me in CC as I'm not subscribed to the list]
> >>
> >>
> >> Hello All,
> >>
nalyzer)?
cat /sys/bus/usb/devices/.../power/runtime_status
will tell you whether or not the device is currently suspended.
Alan Stern
--
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
he keyboard that's causing it to misreport the idProduct?
Probably it lost some of its firmware.
Alan Stern
--
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
put_noidle()
correctly.
The basic idea is to use these when you know beforehand that the device
is already at full power (for _get_noresume) and the usage count will
not go to 0 (for _put_noidle). If you aren't certain of these
requirements then you should call pm_runtime_get_sync() and
pm_runtim
k(struct work_struct *work)
> host->set_param(host, MEMSTICK_POWER, MEMSTICK_POWER_OFF);
>
> mutex_unlock(>lock);
> +
> + pm_runtime_put_noidle(host->dev.parent);
> dev_dbg(>dev, "memstick_check finished\n");
> }
This should be pm_runt
are about it, I recommend option 2. If you do want the CD
interface, I recommend option 1.
> If you answer 1, I'd like to know the appropriate API layer to hook
> into, and how to probe for the device and such...
Write a subdriver for usb-storage. See the various subdrivers already
USB_PORT_STAT_OVERCURRENT))
> + (portstatus & USB_PORT_STAT_OVERCURRENT) ||
> + (portchange & USB_PORT_STAT_C_OVERCURRENT))
> set_bit(port1, hub->change_bits);
>
> } else if (po
Again, use usbmon to make sure your assumptions are correct. If usbmon
shows that everything is working correctly on the host side then the
problem has to lie in the device.
Alan Stern
--
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
1 - 100 of 6100 matches
Mail list logo
