On Tue, 13 Jun 2017, Bjorn Helgaas wrote:
> [+cc Rafael, linux-pm]
>
> On Tue, Jun 13, 2017 at 12:21:15PM +0800, Kai-Heng Feng wrote:
> > On Mon, Jun 12, 2017 at 10:18 PM, Alan Stern
> > wrote:
> > > Let's get some help from people who understand PCI w
t;
> - if (retval < 0)
> + if (retval < 0) {
> + clk_disable_unprepare(pxa_ohci->clk);
> return retval;
> + }
>
> if (cpu_is_pxa3xx())
> pxa3xx_u2d_start_hc(&hcd->self);
Aside from that one issue,
Acked-by: Alan Stern
Alan Stern
xception
> Shutting down cpus with NMI
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
I guess the structure containing the spinlock was already deallocated
when gadgetfs_disconnect was called. But I don't see how that coul
y simple approach, just wait a fixed amount of time, like 10
seconds. Unless the system is highly loaded or probing takes a lot
longer than usual, that should be enough.
Alan Stern
> To mount and unmount gadgetfs right now I do:
> mount("none", "/dev/gadget", "gadgetfs", 0, NULL)
> umount2("/dev/gadget", MNT_FORCE | MNT_DETACH)
>
> Thanks!
clears dum->driver while the
second dereferences it, and neither access is protected by a lock.
It turns out this problem affects at least one other UDC driver
(net2280.c). Below is a patch that adds the missing lock (and removes
some unneeded unlocks) from these drivers. It turns out that the
/marc.info/?l=linux-usb&m=149570231732519&w=2
On Mon, 12 Jun 2017, Kai-Heng Feng wrote:
> On Mon, Jun 12, 2017 at 3:04 PM, Kai-Heng Feng
> wrote:
> > On Fri, Jun 9, 2017 at 10:43 PM, Alan Stern
> > wrote:
> >> On Fri, 9 Jun 2017, Kai-Heng Feng wrote:
> >&
= to_exynos_ehci(hcd);
> int ret;
>
> - clk_prepare_enable(exynos_ehci->clk);
> + ret = clk_prepare_enable(exynos_ehci->clk);
> + if (ret)
> + return ret;
>
> ret = exynos_ehci_phy_enable(dev);
> if (ret) {
Acked-by: Alan Stern
core/hub.c:5105 [inline]
> > hub_event+0xa0b/0x16e0 drivers/usb/core/hub.c:5189
> > process_one_work+0x1fb/0x4c0 kernel/workqueue.c:2097
> > process_scheduled_works kernel/workqueue.c:2157 [inline]
> > worker_thread+0x2ab/0x4c0 kernel/workqueue.c:2233
> > kthread+0x140/0x160 kernel/kthread.c:231
> > ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:424
> > Code: 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 0f 1f 44 00 00 ba
> > 01 00 00 00 8b 07 85 c0 75 0a f0 0f b1 17 85 c0 75 f2 5d c3 f3 90
> > ec 81 fe 00 01 00 00 0f 84 92 00 00 00 41 b8 01 01 00 00 b9
Alan Stern
ce drivers are
generally not supposed to enable or disable autosuspend -- that is a
policy decision left up to userspace. There are a few exceptions for
things like hubs, but this is generally true.
Why should the USB digital audio driver want to enable autosuspend?
Alan Stern
On Fri, 9 Jun 2017, Kai-Heng Feng wrote:
> As Alan Stern points out [1], the PME signal is not enabled when
> controller is in D3, therefore it's not being woken up when new deivces
> get plugged in.
>
> Workaround this bug by preventing the controller enters D3 power s
On Thu, 8 Jun 2017, Andrey Konovalov wrote:
> On Wed, Jun 7, 2017 at 11:20 PM, Alan Stern wrote:
> > On Wed, 7 Jun 2017, Andrey Konovalov wrote:
> >
> >> On Wed, Jun 7, 2017 at 4:43 PM, Alan Stern
> >> wrote:
> >> > On Wed, 7 Jun 20
e remote wakeup */
> - pci_back_from_sleep(pci_dev);
> + powermac_set_asic(to_pci_dev(dev), 1);
> return 0;
> }
Acked-by: Alan Stern
On Wed, 7 Jun 2017, Andrey Konovalov wrote:
> On Wed, Jun 7, 2017 at 4:43 PM, Alan Stern wrote:
> > On Wed, 7 Jun 2017, Andrey Konovalov wrote:
> >
> >> Hi,
> >>
> >> I've got the following error report while fuzzing the k
d.
Can you provide an strace or the equivalent?
Alan Stern
afael
> is waiting for USB MAINTAINERS's comments or ack. It resolves some
> USB HUB issues for several persons.
>
> Peter
>
> > Signed-off-by: Peter Chen
> > Tested-by Joshua Clayton
> > Tested-by: Maciej S. Szmigiero
>
I host not responding to stop
> endpoint command.
> [294504.576805] xhci_hcd :02:00.0: Assuming host is dying, halting host.
At this point you have reached the limit of my knowledge. The best
person to help is Mathias Nyman, the xHCI maintainer (CC'ed).
Is that WARNING at the start of the log connected with the later
events?
Alan Stern
On Tue, 2 May 2017, Gustavo A. R. Silva wrote:
> Add null check before dereferencing dev->regs pointer inside
> net2280_led_shutdown() function.
>
> Addresses-Coverity-ID: 101783
> Cc: Alan Stern
> Signed-off-by: Gustavo A. R. Silva
> ---
> Changes in v2:
>
On Tue, 2 May 2017, Gustavo A. R. Silva wrote:
> Remove unnecessary null check. udev->tt cannot ever be NULL when this
> section of code runs.
>
> Addresses-Coverity-ID: 100828
> Cc: Alan Stern
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/usb/host/ehci-sched
pdev, 0));
No, you must not move the iounmap() call, because an interrupt could
theoretically occur at any time.
Either just live with an extra test of dev->regs, or else move the
net2280_led_shutdown() call later.
Alan Stern
r sure, so in case dev->tt is NULL, a good strategy
> to properly update the _addr_ variable would be needed.
>
> What do you think?
>
> I would really appreciate any comment on this,
> Thank you!
You are right; udev->tt cannot ever be NULL when this section of code
runs. The test should be removed.
Alan Stern
On Mon, 1 May 2017, Thomas Fjellstrom wrote:
> On Monday, May 1, 2017 10:54:12 AM MDT Alan Stern wrote:
> > On Mon, 1 May 2017, Thomas Fjellstrom wrote:
> > > I've got a 970 Pro gaming aura motherboard with an Asmedia 1343 Usb 3.1
> > > controller. It's
nsistently is:
>
> usbfs: process did not claim interface 0 before use
This warning message is not related to the Asmedia controller. It
refers to some program running on the computer, and the same message
would appear no matter what sort of controller was being used.
Alan Stern
> Lat
hat
> urb->transfer_buffer is not a stack object.
>
> Signed-off-by: Florian Fainelli
> ---
> Changes in v2:
>
> - moved the check from usb_start_wait_urb() to usb_hcd_map_urb_for_dma()
You probably should add a similar check to the pathway that maps
urb->setup_packet, for
the DMA mapping (it might use PIO for some types of transfer). In
those cases we don't want to issue the warning. So perhaps
usb_hcd_map_urb_for_dma() would be better for both checks.
Alan Stern
On Sun, 23 Apr 2017, Greg Kroah-Hartman wrote:
> On Sat, Apr 22, 2017 at 05:31:27PM -0400, Alan Stern wrote:
> > On Sat, 22 Apr 2017, Florian Fainelli wrote:
> >
> > > We see a large number of fixes to several drivers to remove the usage of
> > > on-stack
urb->actual_length = 0;
Does this really help? I mean, don't we already get warnings when
the host controller drivers try to map on-stack buffers for DMA?
The only difference is that one wouldn't have to read as far back into
the stack trace. But that hardly seems like an important
consideration.
Alan Stern
refore the struct device
is located in dynamically allocated memory.
> Now, if this kzalloc() would be replaced with devm_kzalloc() wouldn't
> this result on a functionally equivalent execution to the patch I
> proposed above?
It would, and it would be equally wrong.
Alan Stern
ase callback, deallocating the private data structure without
> > giving the caller (i.e., the UDC driver) a chance to clean up.
>
> it won't deallocate anything :-) dev_set_drvdata() was never called,
> we will endup with kfree(NULL) which is safe and just silently returns.
But if you change gadget_release() to use the parent's drvdata field,
like you proposed earlier, and fix up the refcounting in
net2280_remove() so that the structure doesn't get deallocated too
quickly, then this does become a real problem.
And it can affect other UDC drivers, not just net2280.
Alan Stern
On Mon, 10 Apr 2017, Felipe Balbi wrote:
> Hi,
>
> Alan Stern writes:
> > On Wed, 5 Apr 2017, Felipe Balbi wrote:
> >
> >> >> >> --- a/drivers/usb/gadget/udc/core.c
> >> >> >> +++ b/drivers/usb/gadget/udc/core.c
> >&g
ng "dev"... IIRC, at one time he had a
line of code that went something like: dev->dev.dev = &pdev->dev !)
> >> I'm actually thinking that struct usb_gadget shouldn't have a struct
> >> device at all. Just a pointer to a device, that would solve all these
> >> issues.
> >
> > A pointer to which device? The UDC? That would change the directory
> > layout in sysfs.
>
> indeed. Would that be a problem?
Possibly for some userspace tool.
> > Or a pointer to a separate dynamically allocated device (the way struct
> > usb_hcd contains a pointer to the root hub device)? That would work.
> > If the UDC driver wanted to re-register the gadget, it would have to
> > allocate a new device.
>
> That could be done as well, if maintaining the directory structure is a
> must.
Alan Stern
On Tue, 4 Apr 2017, Felipe Balbi wrote:
> Hi,
>
> Alan Stern writes:
> > On Mon, 3 Apr 2017, Roger Quadros wrote:
> >
> >> allow usb_del_gadget_udc() and usb add_gadget_udc() to be called
> >> repeatedly on the same gadget->dev structure.
> >>
On Mon, 3 Apr 2017, Gustavo A. R. Silva wrote:
> Code refactoring to make the flow easier to follow.
>
> Cc: Alan Stern
> Cc: Greg Kroah-Hartman
> Signed-off-by: Gustavo A. R. Silva
> ---
> Changes in v2:
> Remove unfruitful changes in previous patch.
> Revert c
On Mon, 3 Apr 2017, Gustavo A. R. Silva wrote:
> Code refactoring to make the flow easier to follow.
>
> Cc: Alan Stern
> Cc: Greg Kroah-Hartman
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/usb/misc/usbtest.c | 67
> +---
hings in the same patch, please make these multiple
> patches. And do the "add missing continue" first, so it can be
> backported to other kernels easier please.
Also, make sure your patch does not contain gratuitous whitespace
changes.
Alan Stern
new memset will
oops.
In general, if an object relies on reference counting for its lifetime,
you cannot register and unregister it more than once. A typical issue
is that some code retains a reference to the old instance and tries to
use it after the new instance has been registered, thereby m
gt; > +#define SB800_PIIX4_SMB_IDX0xcd6
> > +#define SB800_PIIX4_SMB_DATA 0xcd7
> > +
> > +extern struct mutex sb800_mutex;
> > +
> > +#define enter_sb800() mutex_lock(&sb800_mutex)
> > +#define leave_sb800() mutex_unlock
On Fri, 24 Mar 2017, Dmitry Vyukov wrote:
> On Thu, Mar 23, 2017 at 4:22 PM, Dmitry Vyukov wrote:
> >> On Thu, 23 Mar 2017, Dmitry Vyukov wrote:
> >>
> >>> > Putting these together:
> >>> >
> >>> > The memory was allocated in usb_internal_control_msg() line 93.
> >>> > The later e
deallocated separately
for each call. You can see this very plainly by reading the source
code for usb_internal_control_msg() and usb_start_wait_urb().
It's possible that the same memory location was allocated and
deallocated for two different calls at different times. That wouldn't
fool syzkaller, would it?
Alan Stern
On Thu, 23 Mar 2017, Dmitry Vyukov wrote:
> Hello,
>
> I've got the following report while running syzkaller fuzzer on
> 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Not the preceding injected
> kmalloc failure, most likely it's the root cause.
I find this bug report puzzling. Maybe I don't unders
+418,7 @@ struct ohci_hcd {
> #define OHCI_QUIRK_AMD_PLL 0x200 /* AMD PLL
> quirk*/
> #define OHCI_QUIRK_AMD_PREFETCH 0x400 /* pre-fetch
> for ISO transfer */
> #define OHCI_QUIRK_GLOBAL_SUSPEND 0x800 /* must suspend
> ports */
> +#define OHCI_QUIRK_QEMU 0x1000 /* relax timing
> expectations */
>
> // there are also chip quirks/bugs in init logic
Signed-off-by: Alan Stern
> +
> dev_info(&udev->dev, "USB disconnect, device number %d\n",
> udev->devnum);
>
Very minor nit: I would place the pm_runtime_barrier() after the
dev_info(), so that we would know the device is going away if anything
should go wrong during the barrier call.
Aside from that,
Acked-by: Alan Stern
Alan Stern
hink the right thing to do is test udev->state at the start of
autosuspend_check(), much like the test at the start of
usb_suspend_both(). udev->state gets set to USB_STATE_NOTATTACHED in
usb_disconnect() before usb_disable_device() is called.
Then there will be no need for usb_disab
with interrupts disabled. You probably
should release the spinlock and enable interrupts during the handshake.
Have you seen any errors with the current 1000 us value? If you
haven't, there's no reason to change the code.
Alan Stern
s still accessible if the error returned
> from hub_port_status() is -EBUSY.
> v2: Instead of not triggering the hub wq after an error to submit an urb,
> implement a more complex error detection and handling. Do it in two
> places. Marked as RFC to determine if one (or both
n trying to resume from suspend.
>
> https://bugzilla.kernel.org/attachment.cgi?id=255309
I'm not an expert on xHCI. This should be CC'ed to the xhci-hcd
maintainer.
Alan Stern
>
> Please let me know if I should provide something else.
>
> Thanks,
> Diego
>
iego
> >>>
> >>> Hello,
> >>>
> >>> I've found something interesting and what it seems to be the cause of
> >>> my problem.
> >>>
> >>> As soon as I boot my system I can see this process being in the D-state:
>
}
> + }
> +
> if (udev || (portstatus & USB_PORT_STAT_CONNECTION))
> dev_dbg(&port_dev->dev, "status %04x change %04x\n",
> portstatus, portchange);
> @@ -1198,7 +1211,7 @@ static void hub_activate(struct usb_hub *hub, enum
> hub_activation_type type)
>
> /* Scan all ports that need attention */
> kick_hub_wq(hub);
> -
> +abort:
> if (type == HUB_INIT2 || type == HUB_INIT3) {
> /* Allow autosuspend if it was suppressed */
> disconnected:
On the whole, this looks very good.
Alan Stern
d code sets priv->pwr or priv->rst to NULL and continues;
the new code returns with an error.
The only way the patch could be equivalent to the existing code would
be if devm_reset_control_get_optional_shared() returns no errors other
than EPROBE_DEFER. But the patch description doesn't say this.
Alan Stern
- a/drivers/usb/host/ohci.h
> +++ b/drivers/usb/host/ohci.h
> @@ -418,6 +418,7 @@ struct ohci_hcd {
> #define OHCI_QUIRK_AMD_PLL 0x200 /* AMD PLL
> quirk*/
> #define OHCI_QUIRK_AMD_PREFETCH 0x400 /* pre-fetch
> for ISO transfer */
> #define OHCI_QUIRK_GLOBAL_SUSPEND 0x800 /* must suspend
> ports */
> +#define OHCI_QUIRK_QEMU 0x1000 /* relax timing
> expectations */
>
> // there are also chip quirks/bugs in init logic
Aside from that minor point,
Acked-by: Alan Stern
Alan Stern
On Mon, 13 Mar 2017, Samuel Thibault wrote:
> Alan Stern, on dim. 12 mars 2017 21:40:33 -0400, wrote:
> > On Sun, 12 Mar 2017, Dave Mielke wrote:
> > > [quoted lines by Alan Stern on 2017/03/12 at 21:31 -0400]
> > >
> > > >A device's speed is o
On Sun, 12 Mar 2017, Dave Mielke wrote:
> [quoted lines by Alan Stern on 2017/03/12 at 21:40 -0400]
>
> >No, I was wondering why an HID device would run at high speed. Both
> >you and Samuel implied that this was because it was a USB-2 device.
> >But that is not an ade
On Sun, 12 Mar 2017, Dave Mielke wrote:
> [quoted lines by Alan Stern on 2017/03/12 at 21:31 -0400]
>
> >A device's speed is only partially related to its USB version. A
> >USB-1.1 device can run at low speed or full speed. A USB-2 device can
> >run at low, full
On Sun, 12 Mar 2017, Dave Mielke wrote:
> [quoted lines by Alan Stern on 2017/03/12 at 17:18 -0400]
>
> >Interesting. This is a high-speed device that mistakenly uses the
> >low/full-speed encoding for an interrupt bInterval value?
>
> Yes.
>
> >That&#x
R_FRAME_INTR_BINTERVAL },
> + { USB_DEVICE(0x0904, 0x6102), .driver_info =
> + USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL },
> + { USB_DEVICE(0x0904, 0x6103), .driver_info =
> + USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL },
> +
> /* Keytouch QWERTY Panel keyboard */
> { USB_DEVICE(0x0926, 0x), .driver_info =
> USB_QUIRK_CONFIG_INTF_STRINGS },
Acked-by: Alan Stern
gt; + USB_QUIRK_MS_INTR_BINTERVAL },
> + { USB_DEVICE(0x0904, 0x6102), .driver_info =
> + USB_QUIRK_MS_INTR_BINTERVAL },
> + { USB_DEVICE(0x0904, 0x6103), .driver_info =
> + USB_QUIRK_MS_INTR_BINTERVAL },
You didn't read the comment at the start of the file.
(It would be interesting to know exactly at which point
usb_port_suspend fails during your test. And why didn't your system
mark the hub as disconnected when the host controller was unbound?)
An even worse problem is what to do when the device is working okay but
runtime suspend still fails (for example, if remote wakeup cannot be
enabled). How do we prevent the system from going into a similar loop
then?
Alan Stern
; [gregory.clem...@free-electrons.com: - reword commit and comments
>- fix error path in ehci_orion_drv_reset()
>- fix checkpatch warning]
> Signed-off-by: Hua Jing
> Signed-off-by: Gregory CLEMENT
> Reviewed-by
here's no good reason to add it.
> +
> + /*
> + * For SoC without hlock, need to program sbuscfg value to guarantee
> + * AHB master's burst would not overrun or underrun FIFO.
> + *
> + * sbuscfg reg has to be set after usb controller reset, otherwise
> + * t
>kref, release_usb_class);
> + mutex_unlock(&init_usb_class_mutex);
> }
>
> int usb_major_init(void)
> @@ -171,7 +173,10 @@ int usb_register_dev(struct usb_interface *intf,
> if (intf->minor >= 0)
> return -EADDRINUSE;
>
> + mutex_lock(&init_usb_class_mutex);
> retval = init_usb_class();
> + mutex_unlock(&init_usb_class_mutex);
> +
> if (retval)
> return retval;
Acked-by: Alan Stern
Alan Stern
does destroy_usb_class() have that "if (usb_class) "test?
Isn't it true that usb_class can never be NULL there?
Alan Stern
> thanks,
> ajay kaher
>
>
> Signed-off-by: Ajay Kaher
>
> ---
>
> drivers/usb/core/file.c |6 ++
> 1 file changed
On Wed, 1 Mar 2017, Avraham Shukron wrote:
> I thought fixing a driver that I actually use daily will be more satisfying.
Unless there are special reasons, you should not be using the usbkbd
driver. It is legacy code; everyone should now use usbhid instead.
Alan Stern
as per your inputs to prevent
> the race condition during simultaneously calling of init_usb_class().
> If you think there is scope to improve the patch, please share your inputs.
Under the circumstances, your patch is acceptable.
If you really want to make the point crystal clear, you could rep
On Tue, 28 Feb 2017, Felipe Balbi wrote:
>
> Hi,
>
> Alan Stern writes:
> >> So I am not sure how the Gadget driver can figure out that it needs to
> >> usb_ep_queue() another request for status stage when handling the
> >> no-data control?
> >
hase
> later.
>
> So I am not sure how the Gadget driver can figure out that it needs to
> usb_ep_queue() another request for status stage when handling the
> no-data control?
Gadget drivers already queue status-stage requests for no-data
control-OUT requests. The difficulty comes when you want to handle an
IN request or an OUT request with a data stage.
Alan Stern
On Tue, 21 Feb 2017, Gustavo A. R. Silva wrote:
> Code refactoring to make the flow easier to follow and add missing
> 'continue' for case USB_ENDPOINT_XFER_INT.
>
> Addresses-Coverity-ID: 1248733
> Cc: Alan Stern
> Signed-off-by: Gustavo A. R. Silva
> ---
>
till holding a reference to usb_class? And what if
the last reference gets dropped later on, while init_usb_class() is
running?
Maybe that's not possible here, but it is possible in general for
refcounted objects. So yes, this code is probably okay, but it isn't
good form.
Alan Stern
On Thu, 16 Feb 2017, Ajay Kaher wrote:
> > On Thu, 14 Feb 2017, Alan Stern wrote:
> >
> > I think Ajay's argument is correct and a patch is needed. But this
> > patch misses the race between init_usb_class() and release_usb_class().
>
> Thanks Alan for your
amp; (++waitcount <
> 10));
>
> if (result != USB_STOR_TRANSPORT_GOOD)
> usb_stor_dbg(us, "Gah! Waitcount = 10. Bad
> write!?\n");
>
This has already been reported and fixed. See
http://marc.info/?l=linux-usb&m=148604164024557&w=2
Alan Stern
I fixup... pass 3 done
> >
> > ...followed by hang. So yes, it looks USB related.
> >
> > (Sometimes it hangs with some kind backtrace involving secondary CPU
> > startup, unfortunately useful info is off screen at that point).
>
> Forgot to say, 1d.7 is EHCI controller.
>
> 00:1d.7 USB controller: Intel Corporation NM10/ICH7 Family USB2 EHCI
> Controller (rev 01)
So this looks like a problem in the PCI subsystem affecting a USB
controller.
Linus is right; bisection is the best approach now that you know a
reliable trigger.
Alan Stern
> ajay kaher
>
>
> Signed-off-by: Ajay Kaher
I think Ajay's argument is correct and a patch is needed. But this
patch misses the race between init_usb_class() and release_usb_class().
The basic problem is that reference counting doesn't work when you try
to use the same global pointer (usb_class) to refer to multiple
generations of a dynamically allocated entity. We had the same sort of
problem many years ago with the usb_interface structure (and we
ultimately fixed it by creating a separate usb_interface_cache
structure).
The best approach here would be to forget about all the reference
counting. Get rid of usb_class entirely, and create the "usbmisc"
class structure just once, when usbcore initializes. Or, if you
prefer, use a mutex to protect a routine that allocates the class
structure dynamically, just once. Either way, don't deallocate it
until usbcore is unloaded.
Alan Stern
On Mon, 13 Feb 2017, Paul E. McKenney wrote:
> On Mon, Feb 13, 2017 at 08:14:23PM +0100, Tobias Klausmann wrote:
> > Hi!
> >
> > On Mon, 13 Feb 2017, Paul E. McKenney wrote:
> > > On Mon, Feb 13, 2017 at 01:53:27PM -0500, bob smith wrote:
> > > > On 2/13/17 1:39 PM, Paul E. McKenney wrote:
> > >
return retval;
>
> you're changing return value here, are you sure there's nothing else
> depending on this error?
I bet you didn't look at the original code. :-) Just before the start
of the patch there is:
if (retval == -EPIPE) {
...
So no, the patch does not change the return value.
Alan Stern
On Mon, 6 Feb 2017, Richard Leitner wrote:
> On 02/06/2017 04:12 PM, Alan Stern wrote:
> > On Mon, 6 Feb 2017, Richard Leitner wrote:
> >
> >> For USB string descriptors we need to convert ASCII strings to UTF16-LE.
> >> Therefore make a simple helper f
ls_base.c.
Maybe it doesn't do exactly what you want, but it should be pretty
close. Adding another helper function to do essentially the same thing
seems unnecessary.
Alan Stern
e is keyboard plugged
> > in" but in "reboot" vs. "cold boot". I did not do a cold boot in quite
> > a while :-(.
> >
> > Booting to grub, then hitting ctrl-alt-del is enough to make it work. Ouch.
> >
> > It happens with current Linus'
could try to boot with CONFIG_USB=n, but that will be pretty useless
> configuration.
If necessary, you could disable EHCI in the BIOS. That also would be
pretty drastic, though.
What does the dmesg log in 4.10-rc6 say when the keyboard is plugged
into its original port?
No obvious explanations spring to mind. You may have to bisect.
Alan Stern
roblem. I am open to suggestions
> for a better fix.
The proper approach is to keep the allocation as it is, but _before_
deallocating the buffer, make sure that the interrupt buffer won't be
accessed any more. This may involve calling usb_kill_urb(), or
synchronize_irq(), or something similar.
Alan Stern
info->pba_to_lba[pba] = lba;
> info->lba_to_pba[lba] = pba;
> - isnew = 1;
> }
>
> if (pba == 1) {
Acked-by: Alan Stern
ng explicit status requests.
Implementing it will be a little tricky, because right now some status
requests already are explicit (those for length-0 OUT transfers) while
others are implicit.
(One possible approach would be to have the setup routine return
different values for explicit and implicit status stages -- for
example, return 1 if it wants to submit an explicit status request.
That wouldn't be very different from the current
USB_GADGET_DELAYED_STATUS approach.)
On the other hand, I am very doubtful about requiring explicit setup
requests.
Alan Stern
ge or status-stage
request before the UDC driver is ready to handle it (for example,
before or shortly after the setup routine returns).
To work properly, the UDC driver must be able to accept a request for
ep0 any time after it invokes the setup callback -- either before the
callback returns or after. It seems that this was the real problem
Baolin wanted to fix.
Alan Stern
ppening, but probably not today (testing stuff for -rc).
Does anything change if the host and peripheral are separate machines?
Alan Stern
a/drivers/usb/core/hcd.c
> > +++ b/drivers/usb/core/hcd.c
> > @@ -3017,6 +3017,7 @@ void usb_remove_hcd(struct usb_hcd *hcd)
> > }
> >
> > usb_put_invalidate_rhdev(hcd);
> > + hcd->flags = 0;
> > }
> > EXPORT_SYMBOL_GPL(usb_remove_hcd);
> >
> >
> I suggest to initialize hcd->flags to 0 in usb_add_hcd() instead.
>
> cheers,
> -roger
Roger, didn't you originally propose this very same patch in
http://marc.info/?l=linux-usb&m=146556415503583&w=2
(and of course, the earlier versions before v10)? What happened to it?
Alan Stern
ks really tailored to make PCI
> dwc3
> controllers with xhci support work.
>
> Was there some reason child devices can't automatically inherit the dma mask
> from the parents,
> forcing us to dig it from grandparents?
>
> Anyway, looks like the dwc3 part is already in 4.10-rc,
> If Greg and Alan want to take this series that's fine by me
I have no objections.
Alan Stern
> I haven't tested that it won't break anything on PCI XHCI controllers though
>
> -Mathias
err(dev,
> "Error retrieving usb2 phy: %d\n", ret);
> + of_node_put(child);
> return ret;
> }
> }
>
Acked-by: Alan Stern
err(dev,
> "Error retrieving usb2 phy: %d\n", ret);
> + of_node_put(child);
> return ret;
> }
> }
Acked-by: Alan Stern
On Tue, 27 Dec 2016, Felipe Balbi wrote:
>
> Hi,
>
> Alan Stern writes:
> > On Tue, 6 Dec 2016, Andrey Konovalov wrote:
> >
> >> Hi!
> >>
> >> I've got the following error report while running the syzkaller fuzzer.
> >>
/core/message.c:1030
> [] usb_set_configuration+0x1083/0x18d0
> drivers/usb/core/message.c:1937
Hi, Andrey:
Please check whether the patch below fixes this problem.
Alan Stern
Index: usb-4.x/drivers/usb/core/config.c
===
On Wed, 14 Dec 2016, Michal Hocko wrote:
> On Tue 13-12-16 08:33:34, Alan Stern wrote:
> > On Tue, 13 Dec 2016, Michal Hocko wrote:
> >
> > > > > That being said, what ep_write_iter does sounds quite stupit. It just
> > > > > allocates a large c
On Tue, 13 Dec 2016, Dmitry Vyukov wrote:
> On Tue, Dec 13, 2016 at 7:38 PM, Alan Stern wrote:
> > On Tue, 13 Dec 2016, Dmitry Vyukov wrote:
> >
> >> On Tue, Dec 13, 2016 at 4:52 PM, Alan Stern
> >> wrote:
> >> > On Tue, 13 Dec 2016, Dmitr
On Tue, 13 Dec 2016, Dmitry Vyukov wrote:
> On Tue, Dec 13, 2016 at 4:52 PM, Alan Stern wrote:
> > On Tue, 13 Dec 2016, Dmitry Vyukov wrote:
> >
> >> >> > If it is
> >> >> > not a bug in kernel source code, then it must not produce a WARNING.
&
ooking at these WARNINGs,
> and we will not spend your time by reporting these WARNINGs.
Maybe you should decide that ERROR messages indicate a kernel bug,
rather than WARNING messages. Even that is questionable, but you will
get far fewer false positives.
Even better, you should publicize this decision (in the kernel
documentation, on various mailing lists, on LWN, and so forth), and
enforce it by reducing existing ERROR severity levels to WARNINGs in
places where they do not indicate a kernel bug.
Alan Stern
really hard to imagine to deplete
> larger contiguous memory blocks (say PAGE_ALLOC_COSTLY_ORDER). Those are
> still causing the OOM killer and chances are that a controlled flood of
> these requests could completely DoS the system.
Putting a limit on the total size of a single transfer would prevent
this.
Alan Stern
er
and both a high-speed and a full-speed device plugged into the hub?
Do you end up forcing the high-speed device to run at full speed?
Alan Stern
On Mon, 12 Dec 2016, Alan Stern wrote:
> On Mon, 12 Dec 2016, Dmitry Vyukov wrote:
>
> > On Mon, Dec 12, 2016 at 10:05 PM, Alan Stern
> > wrote:
> > > On Mon, 12 Dec 2016, Andrey Konovalov wrote:
> > >
> > >> Hi!
> > >>
> >
On Mon, 12 Dec 2016, Dmitry Vyukov wrote:
> On Mon, Dec 12, 2016 at 10:05 PM, Alan Stern
> wrote:
> > On Mon, 12 Dec 2016, Andrey Konovalov wrote:
> >
> >> Hi!
> >>
> >> While running the syzkaller fuzzer I've g
ally want to prevent the driver from attempting to allocate a
large buffer, all that's needed is an upper limit on the total size.
For example, 64 KB.
Alan Stern
But is it really worthwhile? A
kernel warning isn't so bad when you're dealing with buggy device
firmware.
Alan Stern
d
I'm not an expert in this area, but it seems like length checking of
I/O operations should be done in a more central location, like the
VFS, rather than in a million different drivers.
Anyway, it's not a big deal if the memory allocation fails. Users who
try to transfer large amounts of data at once should expect that
sometimes it won't work.
Alan Stern
inline >] ep0_write drivers/usb/gadget/legacy/inode.c:1135
> [] dev_config+0x86f/0x1190
> drivers/usb/gadget/legacy/inode.c:1759
> [] __vfs_write+0x5d5/0x760 fs/read_write.c:510
> [] vfs_write+0x170/0x4e0 fs/read_write.c:560
> [< inline >] SYSC_write
ernel/sched/core.c:469
> [] futex_wake+0x5be/0x6c0 kernel/futex.c:1453
> [] do_futex+0x11bd/0x1f00 kernel/futex.c:3219
> [< inline >] SYSC_futex kernel/futex.c:3275
> [] SyS_futex+0x2fc/0x400 kernel/futex.c:3243
> [] entry_SYSCALL_64_fastpath+0x1f/0xc2
Can you test
901 - 1000 of 3133 matches
Mail list logo
