On Fri, Sep 15, 2023 at 09:02:48AM +0800, Linyu Yuan wrote:
>
> On 9/14/2023 10:54 PM, Alan Stern wrote:
> > You didn't include the version number in the Subject: line. Undoubtedly
> > Greg's automatic error checker will warn you about this. Unless the
> > version
if
Greg will think this change is worth merging, but at least now it's
possible to read the code and understand what's going on.
Alan Stern
--
You might mention that this is essentially a reversion of commit
d18dcfe9860e ("USB: gadgetfs: Fix race between mounting and
unmounting").
Alan Stern
> drivers/usb/gadget/legacy/inode.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/usb/ga
06,6 +406,7 @@ static const struct usb_device_id usb_quirk_list[] = {
>
> /* Realtek hub in Dell WD19 (Type-C) */
> { USB_DEVICE(0x0bda, 0x0487), .driver_info = USB_QUIRK_NO_LPM },
> + { USB_DEVICE(0x0bda, 0x5487), .driver_info = USB_QUIRK_RESET_RESUME },
>
>
On Tue, Apr 20, 2021 at 03:14:56PM +0800, Chris Chiu wrote:
> On Mon, Apr 19, 2021 at 10:19 PM Alan Stern wrote:
> >
> > On Mon, Apr 19, 2021 at 01:11:38AM -0400, Chris Chiu wrote:
> > > Sorry that I didn't make myself clear. I found that if I applied
> &
y: Colin Ian King
> ---
Acked-by: Alan Stern
> drivers/usb/storage/datafab.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/usb/storage/datafab.c b/drivers/usb/storage/datafab.c
> index 588818483f4b..bcc4a2fad863 100644
> --- a/drivers/usb/storage/datafab
work for all devices connected to the hub either.
> Is that right? If what I proposed in the patch can not get better
> result than existing
> quirk, I think using the RESET_RESUME would be a better option. Any
> suggestions?
Try the RESET_RESUME quirk and see how well it works with runtime
suspend.
Alan Stern
fix this, move the synchronize_irq() emulation code to dummy_pullup
> so that it runs before unbind. Also, add a comment explaining why it is
> necessary to have it there.
>
> Suggested-by: Alan Stern
> Reported-by: syzbot+eb4674092e6cc8d9e...@syzkaller.appspotmail.com
>
On Sat, Apr 17, 2021 at 02:48:22PM +0800, liulongfang wrote:
> On 2021/4/16 23:20, Alan Stern wrote:
> > On Fri, Apr 16, 2021 at 10:03:21AM +0800, liulongfang wrote:
> >> The current method is an improved method of the above patch.
> >> This patch just make it skip
On Fri, Apr 16, 2021 at 10:35:20PM +0530, Anirudh Rayabharam wrote:
> On Fri, Apr 16, 2021 at 11:27:34AM -0400, Alan Stern wrote:
> > Actually, I wanted to move this emulation code into a new subroutine and
> > then call that subroutine from _both_ places. Would you like to w
On Fri, Apr 16, 2021 at 09:24:30AM +0800, Chris Chiu wrote:
> On Fri, Apr 16, 2021 at 2:46 AM Alan Stern wrote:
> >
> > On Fri, Apr 16, 2021 at 12:13:43AM +0800, Chris Chiu wrote:
> > > One thing worth mentioning here, I never hit the hub_ext_port_status -71
> > >
On Fri, Apr 16, 2021 at 09:21:12AM +0200, Dmitry Vyukov wrote:
> On Thu, Apr 15, 2021 at 10:59 PM Alan Stern wrote:
> >
> > On Tue, Apr 13, 2021 at 07:11:11PM +0200, Dmitry Vyukov wrote:
> > > Yes, this is possible:
> > > http://bit.do/syzbot#syzkaller-reproducers
On Fri, Apr 16, 2021 at 11:10:35AM +0530, Anirudh Rayabharam wrote:
> On Tue, Apr 13, 2021 at 12:13:11PM -0400, Alan Stern wrote:
> > Maybe we can test this reasoning by putting a delay just before the call
> > to dum->driver->setup. That runs in the timer handler, so it's
On Fri, Apr 16, 2021 at 10:03:21AM +0800, liulongfang wrote:
> On 2021/4/15 22:43, Alan Stern wrote:
> > On Thu, Apr 15, 2021 at 08:22:38PM +0800, Longfang Liu wrote:
> >> When the number of ports on the USB hub is 0, skip the registration
> >> operation of the USB
On Tue, Apr 13, 2021 at 07:11:11PM +0200, Dmitry Vyukov wrote:
> On Tue, Apr 13, 2021 at 6:57 PM Alan Stern wrote:
> >
> > On Tue, Apr 13, 2021 at 06:47:47PM +0200, Dmitry Vyukov wrote:
> > > On Tue, Apr 13, 2021 at 6:13 PM Alan Stern
> > > wrote:
> > >
I don't know how to SetPortFeature() with setting the status change bit only.
You can't. Only the hub itself can set the wPortChange bits.
> Or maybe it's just some kind of timing issue of the
> idle/suspend/resume signaling.
Not timing. It's because you woke the system up from the attached
keyboard.
Alan Stern
do what the
description says. The patch doesn't remove the call to usb_add_hcd
for the USB-3 bus. If you simply skipped that call (and the
corresponding call to usb_remove_hcd) when there are no
ports on the root hub, none of the stuff in this patch would be needed.
Alan Stern
> ---
> d
d has already looked at this:
https://marc.info/?t=15882824021=1=2
I thought we had arrived at an acceptable (though not great) solution,
but he never posted any finished patches. :-(
Alan Stern
> UBSAN: array-index-out-of-bounds in drivers/usb/host/ehci-hub.c:893:16
> index 1 i
eup_enabled_descendants(udev) > 0)
- status = set_port_feature(hub->hdev, port1,
- USB_PORT_FEAT_SUSPEND);
- else {
+ else if (PMSG_IS_AUTO(msg) || usb_wakeup_enabled_descendants(udev) > 0)
{
+ if (hub->hdev->quirks & USB_QUIRK_NO_SUSPEND)
+ status = -EIO;
+ else
+ status = set_port_feature(hub->hdev, port1,
+ USB_PORT_FEAT_SUSPEND);
+ } else {
really_suspend = false;
status = 0;
}
But I would prefer to find a way to make port suspend actually work,
instead of giving up on it.
Alan Stern
On Tue, Apr 13, 2021 at 06:47:47PM +0200, Dmitry Vyukov wrote:
> On Tue, Apr 13, 2021 at 6:13 PM Alan Stern wrote:
> > Hopefully this patch will make the race a lot more likely to occur. Is
> > there any way to tell syzkaller to test it, despite the fact that
> > syzkaller
is reasoning by putting a delay just before the call
to dum->driver->setup. That runs in the timer handler, so it's not a
good place to delay, but it may be okay just for testing purposes.
Hopefully this patch will make the race a lot more likely to occur. Is
there any way to tell syzk
On Tue, Apr 13, 2021 at 03:52:14PM +0800, Chris Chiu wrote:
> On Mon, Apr 12, 2021 at 11:12 PM Alan Stern wrote:
> >
> > On Mon, Apr 12, 2021 at 11:00:06PM +0800, chris.c...@canonical.com wrote:
> > > The USB_PORT_FEAT_SUSPEND is not really necessary due to the
> >
t; - USB_PORT_FEAT_SUSPEND);
> + if (udev->quirks & USB_QUIRK_NO_SET_FEAT_SUSPEND)
You should test hub->hdev->quirks, here, not udev->quirks. The quirk
belongs to the Realtek hub, not to the device that's plugged into the
hub.
Alan Stern
for a root hub,
> we can fix it easily without affect other root hub
>
> Signed-off-by: Chunfeng Yun
Acked-by: Alan Stern
> ---
> drivers/usb/core/hub.h | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/core/hub.h b/driv
spend some time figuring out what is really going wrong. I have already
explained why this patch is not the right thing to do.
You have to determine why the poweroff callback in hcd-pci.c (which
points to hcd_pci_suspend) isn't getting called. That's the real
explanation for your problem.
Al
oller of Kunpeng920 needs to skip
> the read operation of the SBRN register.
>
> Signed-off-by: Longfang Liu
> ---
Acked-by: Alan Stern
> Changes in v4:
> - Modify the code implementation.
>
> Changes in v3:
> - Fix some code style issues.
> -
ith an associated lookup
routine, when there are only two entries. The total amount of code will
be smaller if you just add a check for the Kunpeng920 controller to
the existing check for the STMICRO controller.
Alan Stern
leep
> wake up in S4 mode for a long time that this problem no longer occurs.
Something else must be happeneing, something you don't understand.
Alan Stern
> Signed-off-by: Longfang Liu
> ---
> drivers/usb/core/hcd-pci.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletio
On Wed, Mar 31, 2021 at 02:03:08PM -0700, syzbot wrote:
> syzbot has bisected this issue to:
>
> commit 416dacb819f59180e4d86a5550052033ebb6d72c
> Author: Alan Stern
> Date: Wed Aug 21 17:27:12 2019 +
>
> HID: hidraw: Fix invalid read in hidraw_ioctl
>
On Wed, Mar 31, 2021 at 08:20:56PM +0200, Maciej S. Szmigiero wrote:
> On 29.03.2021 17:22, Alan Stern wrote:
> > On Sat, Mar 27, 2021 at 04:55:20PM +0100, Maciej S. Szmigiero wrote:
> > > Hi,
> > >
> > > Is there any specific reason that URBs without U
On Tue, Mar 30, 2021 at 12:07:35PM +0300, Heikki Krogerus wrote:
> On Mon, Mar 29, 2021 at 02:49:46PM -0400, Alan Stern wrote:
> > On Mon, Mar 29, 2021 at 11:44:25AM +0300, Heikki Krogerus wrote:
> > > Introducing usb_for_each_port(). It works the same way as
> > > usb_
er_mutex);
I have a feeling that it would be better to take and release this mutex
in usb_for_each_port (or its caller), so that it is held over the whole
loop.
Alan Stern
> +
> + return ret;
> +}
> +
> +/**
> + * usb_for_each_port - interate over all USB ports in the sy
On Mon, Mar 29, 2021 at 04:38:10PM +0800, liulongfang wrote:
> On 2021/3/26 23:28, Alan Stern wrote:
> > On Fri, Mar 26, 2021 at 04:54:56PM +0800, Longfang Liu wrote:
> >> When OHCI enters the S4 sleep state, the USB sleep process will call
> >> check_root_hub_sus
l try to find time to work on it.
I would appreciate any effort you could make toward checking the code
in qh_completions(); I suspect that the checks it does involving
EHCI_LIST_END may not be right. At the very least, they should be
encapsulated in a macro so that they are easier to understand.
Alan Stern
t allow us to work around this problem:
In fact, as far as I know _all_ USB SD card readers send Media Changed
notifications on resume. Maybe there are some that don't, but I haven't
heard of any.
Alan Stern
lags);
> + spin_unlock_irqrestore(>lock, flags);
This is completely wrong. The hardware certainly remains accessible
when the root hub stops running. The HW_ACCESSIBLE flag should not be
cleared here.
And if the Master Interrupt Enable bit is cleared, how will the driver
ever
On Thu, Mar 25, 2021 at 05:14:42PM +0200, Heikki Krogerus wrote:
> On Thu, Mar 25, 2021 at 10:41:09AM -0400, Alan Stern wrote:
> > On Thu, Mar 25, 2021 at 03:29:21PM +0300, Heikki Krogerus wrote:
> > > Introducing usb_for_each_port(). It works the same way as
> > > usb_
)
> + return ret;
> + }
> +
> + return 0;
> +}
Don't you need some sort of locking or refcounting here? What would
happen if this hub got removed while the routine was running?
Alan Stern
t;
> But you can not have a USB3 hub with no ports, isn't that against
> against the USB spec? How does this device pass the USB-IF
> certification?
>
> > thanks, therefore, in order to reduce the severity of the log,
> > we hope to lower the level of this log.
>
> You did not reduce the severity at all, everyone can still see it.
>
> Please try fixing your hardware :
Alternatively, you could change the xhci-hcd driver. Make it skip
registering the USB-3 root hub if that hub has no ports.
But don't change these log messages. They describe real errors, so they
should be actual error messages.
Alan Stern
On Mon, Mar 22, 2021 at 05:59:17PM +0100, Sebastian Andrzej Siewior wrote:
> On 2021-03-22 12:42:00 [-0400], Alan Stern wrote:
> > What happens on RT systems? Are they smart enough to avoid the whole
> > problem by enabling interrupts during _all_ callbacks?
>
> tl;dr: Yes.
;threadirqs").
What happens on RT systems? Are they smart enough to avoid the whole
problem by enabling interrupts during _all_ callbacks?
Alan Stern
> okay to have a bit clunky workaround for it.
>
> Fixes: c3590c7656fb ("usb: host: ehci-tegra: Remove the driver")
> Reported-by: kernel test robot
> Signed-off-by: Dmitry Osipenko
Acked-by: Alan Stern
> ---
> drivers/usb/host/Kconfig | 1 +
> 1 file cha
On Wed, Mar 17, 2021 at 05:25:20PM +0900, taehyun cho wrote:
> On Mon, Mar 15, 2021 at 10:13:35AM -0400, Alan Stern wrote:
> > On Mon, Mar 15, 2021 at 04:43:17PM +0900, taehyun cho wrote:
> > > 'pm_runtime_set_active' sets a flag to describe rumtime status.
> > > Thi
e error.
You need to determine why the parent platform device .usb isn't
active when the dwc3 probe and resume routines are called. It seems
likely that there is a bug in the platform device's driver.
Alan Stern
> Signed-off-by: taehyun cho
> ---
> drivers/usb/dwc3/core.c
On Fri, Mar 12, 2021 at 07:26:31PM +0100, Sedat Dilek wrote:
> On Fri, Mar 12, 2021 at 7:05 PM Alan Stern wrote:
> > Although it's not conclusive, this log seems to indicate that ata_id
> > is the only program causing resets. Have you tried preventing the
> > ata_id
he only program causing resets. Have you tried preventing the
ata_id program from running (for example, by renaming it)?
> Your diff now should say; s/SCSI ioctl error/SCSI ioctl info'.
No, it shouldn't. The log message itself is an info, but the event it
reports is an error.
> Alan, so "t" flags should be added as a quirks to linux-kernel sources...
>
> t = NO_ATA_1X (don't allow ATA(12) and ATA(16) commands, uas only);
>
> ...for my ASMedia USB-3.0 controller?
That's not at all clear. This is a very common and popular device,
and nobody else has reported these problems. It could be that
something is odd about your particular drive or computer, not these
drives in general.
Alan Stern
On Tue, Mar 09, 2021 at 08:04:53PM -0800, Asutosh Das (asd) wrote:
> On 3/9/2021 7:14 PM, Alan Stern wrote:
> > On Tue, Mar 09, 2021 at 07:04:34PM -0800, Asutosh Das (asd) wrote:
> > > Hello
> > > I & Can (thanks CanG) debugged this further:
> > >
> &g
; (@Alan/@Bart/@Adrian) have any thoughts on this.
How about changing the SCSI core so that it does a runtime_get before
starting an async probe, and the async probe routine does a
runtime_put when it is finished? In other words, don't allow a device
to go into runtime suspend while it is waiting to be probed.
I don't think that would be too intrusive.
Alan Stern
usb/common/common.c | 41 +
> drivers/usb/core/devices.c | 21 ---
> drivers/usb/core/endpoint.c | 35 ---
> include/linux/usb/ch9.h | 3 +++
> 4 files changed, 52 insertions(+), 48 deletions(-)
Acked-by: Alan Stern
On Sun, Mar 07, 2021 at 05:57:39PM +0100, Sedat Dilek wrote:
> On Sun, Mar 7, 2021 at 4:46 PM Alan Stern wrote:
> >
> > On Sat, Mar 06, 2021 at 09:49:00PM +0100, Sedat Dilek wrote:
> >
> > > For testing purposes, I stopped these systemd services:
n configure it so that it won't send
the problem-causing commands.
Alan Stern
building a 5.11 kernel with the patch below. I don't know
whether it will show anything in the dmesg log when one of these resets
occurs, but it might.
If that doesn't work out, another possibility is to use git bisect to
find the commit between 5.10 and 5.11 which caused the problem t
seem to have isolated a bug in
the power management subsystem (supplier goes into runtime suspend
even when one of its consumers is still active), you did not CC the
power management maintainer or mailing list.
I have added the appropriate CC's.
Alan Stern
On Fri, Mar 05, 2021 at 08:41:40PM +0100, Sedat Dilek wrote:
> On Fri, Mar 5, 2021 at 8:30 PM Alan Stern wrote:
> > Okay, that indicates the ATA commands are being sent not by the kernel
> > but by some program. I'm not sure how you can easily find out which
> > program; pr
is turn them off one by one until
you find the one responsible.
Alan Stern
On Fri, Mar 05, 2021 at 08:05:49PM +0100, Sedat Dilek wrote:
> On Fri, Mar 5, 2021 at 5:07 PM Alan Stern wrote:
> > Don't worry about trying to decode the output. To me it looks like the
> > drive crashes and needs to be reset at times when the computer sends it
> > an A
On Fri, Mar 05, 2021 at 10:26:50AM -0800, Paul E. McKenney wrote:
> On Fri, Mar 05, 2021 at 04:41:49PM +0100, Björn Töpel wrote:
> > On 2021-03-05 16:36, Alan Stern wrote:
> > > On Fri, Mar 05, 2021 at 11:28:23AM +0100, Björn Töpel wrote:
> > > > From: Björn Töpel
On Fri, Mar 05, 2021 at 09:12:30AM +0800, Boqun Feng wrote:
> On Thu, Mar 04, 2021 at 11:11:42AM -0500, Alan Stern wrote:
> > Forget about local variables for the time being and just consider
> >
> > dep ; [Plain] ; rfi
> >
> > For example:
> >
>
On Fri, Mar 05, 2021 at 01:09:16PM +0100, Sedat Dilek wrote:
> On Mon, Mar 1, 2021 at 4:53 PM Alan Stern wrote:
> [ ... ]
> > You can use usbmon on bus 4 to record the USB traffic. It may indicate
> > why the resets occur.
> >
>
> Hi Alan,
>
> I followe
On Fri, Mar 05, 2021 at 11:28:23AM +0100, Björn Töpel wrote:
> From: Björn Töpel
>
> A misspelled invokation of git-grep, revealed that
---^
Smetimes my brain is a little slow... Do you confirm that this is a
joke?
Alan
the endpoint
> + * @speed: The speed that the endpoint works as
> + *
> + * Function returns the interval expressed in 1us unit for servicing
> + * endpoint for data transfers.
> + */
> +unsigned int usb_decode_interval(const struct usb_endpoint_descriptor *epd,
> + enum usb_device_speed speed);
As a general rule, I believe people expect to find the kerneldoc for a
function next to the function's definition, not next to the declaration
in a header file.
Alan Stern
On Thu, Mar 04, 2021 at 11:05:15AM -0800, Paul E. McKenney wrote:
> On Thu, Mar 04, 2021 at 10:35:24AM -0500, Alan Stern wrote:
> > On Wed, Mar 03, 2021 at 09:04:07PM -0800, Paul E. McKenney wrote:
> > > On Wed, Mar 03, 2021 at 10:21:01PM -0500, Alan Stern wrote:
> > > &
On Thu, Mar 04, 2021 at 02:33:32PM +0800, Boqun Feng wrote:
> Right, I was thinking about something unrelated.. but how about the
> following case:
>
> local_v =
> r1 = READ_ONCE(*x); // f
>
> if (r1 == 1) {
> local_v = // e
> } else {
>
On Wed, Mar 03, 2021 at 09:04:07PM -0800, Paul E. McKenney wrote:
> On Wed, Mar 03, 2021 at 10:21:01PM -0500, Alan Stern wrote:
> > On Wed, Mar 03, 2021 at 02:03:48PM -0800, Paul E. McKenney wrote:
> > > On Wed, Mar 03, 2021 at 03:22:46PM -0500, Alan Stern wrote:
>
On Wed, Mar 03, 2021 at 02:03:48PM -0800, Paul E. McKenney wrote:
> On Wed, Mar 03, 2021 at 03:22:46PM -0500, Alan Stern wrote:
> > On Wed, Mar 03, 2021 at 09:40:22AM -0800, Paul E. McKenney wrote:
> > > On Wed, Mar 03, 2021 at 12:12:21PM -0500, Alan Stern wrote:
> >
On Thu, Mar 04, 2021 at 09:26:31AM +0800, Boqun Feng wrote:
> On Wed, Mar 03, 2021 at 03:22:46PM -0500, Alan Stern wrote:
> > Which brings us back to the case of the
> >
> > dep ; rfi
> >
> > dependency relation, where the accesses in the middle are plain an
On Wed, Mar 03, 2021 at 06:37:36PM +0100, maranget wrote:
>
>
> > On 3 Mar 2021, at 18:12, Alan Stern wrote:
> >
> > On Tue, Mar 02, 2021 at 03:50:19PM -0800, Paul E. McKenney wrote:
> >> On Tue, Mar 02, 2021 at 04:14:46PM -0500, Alan Stern wrote:
> >
On Wed, Mar 03, 2021 at 09:40:22AM -0800, Paul E. McKenney wrote:
> On Wed, Mar 03, 2021 at 12:12:21PM -0500, Alan Stern wrote:
> > Local variables absolutely should be treated just like CPU registers, if
> > possible. In fact, the compiler has the option of keeping local
>
On Tue, Mar 02, 2021 at 03:50:19PM -0800, Paul E. McKenney wrote:
> On Tue, Mar 02, 2021 at 04:14:46PM -0500, Alan Stern wrote:
> > This result is wrong, apparently because of a bug in herd7. There
> > should be control dependencies from each of the two loads in P0 to each
ether this really is a bug and
if it is, fix it.
> In commit c7f2e3cd6c1f ("perf: Optimize ring-buffer write by depending
> on control dependencies") removes the corresponding smp_mb(), and also
> the circular buffer in circular-buffers.txt (pre commit 6c43c091bdc5
> ("documentation: Update circular buffer for
> load-acquire/store-release")) is missing the smp_mb() at the
> producer-side.
>
> I'm trying to wrap my head around why it's OK to remove the smp_mb()
> in the cases above? I'm worried that the current XDP socket ring
> implementation (which is missing smp_mb()) might be broken.
Because of the control dependencies, the smp_mb isn't needed. The
dependencies will order both of the stores after both of the loads.
Alan Stern
On Fri, Feb 26, 2021 at 06:53:52AM +0100, Christoph Hellwig wrote:
> On Thu, Feb 25, 2021 at 11:35:57AM -0500, Alan Stern wrote:
> > This thread seems to have fallen through the cracks. Maybe now would be
> > a good time to address the problem (since we originally planned to fix
t;
> For the first time I used badblocks from e2fsprogs Debian package:
>
> root# LC_ALL=C badblocks -v -p 1 -s /dev/sdc -o
> badblocks-v-p-1-s_dev-sdc_$(uname -r).txt
> Checking blocks 0 to 976762583
> Checking for bad blocks (read-only test): done
> Pass completed, 0 bad blocks found. (0/0/0 errors)
>
> Good, there is no file-system corruption or badblocks or even a hardware
> damage.
>
> Anyway, feedback is much appreciated.
>
> Thanks.
You can use usbmon on bus 4 to record the USB traffic. It may indicate
why the resets occur.
Alan Stern
On Sat, Feb 27, 2021 at 11:38:08AM +0800, liulongfang wrote:
> On 2021/2/27 0:30, Alan Stern wrote:
> > On Fri, Feb 26, 2021 at 04:21:37PM +0800, Longfang Liu wrote:
> >> Our current XHCI hardware controller has been customized to only
> >> support USB 2.0 ports. When us
hat sentence makes no sense at all. An EHCI controller device is a
piece of hardware. How can an xHCI driver, which is a piece of
software, create a piece of hardware?
Alan Stern
On Fri, Feb 26, 2021 at 02:13:36PM +0600, Sabyrzhan Tasbolatov wrote:
> On Thu, 25 Feb 2021 10:59:14 -0500, Alan Stern wrote:
> > Won't this cause silent errors?
>
> Agree. But there are already such as cases like in:
>
> // net/bluetooth/hidp/core.c
> static
Stern
On Mon, Nov 30, 2020 at 03:36:18PM -0500, Alan Stern wrote:
> [Added linux-scsi to CC: list. When discussing code in a particular
> subsystem, it's a good idea to include that subsystem's mailing list in
> the CC:.]
>
> On Tue, Dec 01, 2020 at 03:01:56AM +0800
; 0);
> + u32 len = ((report->size - 1) >> 3) + 1 + (report->id > 0);
> +
> + return len > HID_MAX_BUFFER_SIZE ? HID_MAX_BUFFER_SIZE : len;
Won't this cause silent errors?
How about instead just rejecting any device which includes a report
whose length is too big (along with an line in the system log explaining
what's wrong)?
Alan Stern
as
> ---
> v2: change flag name and improve documentation as suggested by Alan Stern.
>
> drivers/usb/host/ehci-platform.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/usb/host/ehci-platform.c
> b/drivers/usb/host/ehci-platform.c
> index a48dd3f
On Tue, Feb 23, 2021 at 05:04:57PM +0100, Álvaro Fernández Rojas wrote:
> Hi Alan,
>
> > El 23 feb 2021, a las 16:54, Alan Stern
> > escribió:
> >
> > On Tue, Feb 23, 2021 at 04:50:04PM +0100, Álvaro Fernández Rojas wrote:
> >> Over-current repo
se it.
When you say that the bcm63xx doesn't support over-current reporting,
what exactly do you mean? Do you mean that sometimes the hardware turns
on the over-current bit when an over-current isn't actually present? Or
do you mean something else?
Alan Stern
> +
>needs-reset-on-resum
On Tue, Feb 16, 2021 at 10:30:52AM +0900, Jung Daehwan wrote:
> Hello, Alan
>
> On Mon, Feb 15, 2021 at 12:41:45PM -0500, Alan Stern wrote:
> > On Mon, Feb 15, 2021 at 11:38:58AM +0900, Daehwan Jung wrote:
> > > It seems pm_runtime_put calls runtime_idle call
you think it is better? The advantage of pm_runtime_put is that
it allows the suspend to occur at a later time in a workqueue thread, so
the caller doesn't have to wait for the device to go into suspend.
Alan Stern
> Signed-off-by: Daehwan Jung
> ---
> drivers/usb/dwc3/gadget.c | 2 +-
&g
/0x4a0 drivers/usb/core/message.c:153
> go7007_usb_onboard_write_interrupt+0x26a/0x340
> drivers/media/usb/go7007/go7007-usb.c:735
It looks like the go7007 driver isn't very careful about checking that
the endpoints it uses have the right types. In particular, this bug was
caused by not checking that ep2 is a control endpoint (highly unusual to
have a control endpoint other than 0, but allowed).
Alan Stern
len, USB_CTRL_GET_TIMEOUT);
> - if (retval != len) {
> + retval = usb_control_msg_recv(udev, 0,
> + 0x5c, USB_DIR_IN|USB_TYPE_VENDOR,
> + 0, 0, buf, len,
- that one could stand to be
cleaned up as well.
For instance, how about putting the HAS_DMA part into a separate line,
since it's unrelated to the other stuff? And the rest looks like it
could be changed to:
depends on USB_EHCI_HCD || USB_GADGET
although that probably isn't quite valid. Still, can't it be changed to
something simpler than
(USB_EHCI_HCD && USB_GADGET) || (USB_EHCI_HCD && !USB_GADGET) ||
(!USB_EHCI_HCD && USB_GADGET)
?
Alan Stern
nline int usb_gadget_frame_number(struct usb_gadget *gadget)
> { return 0; }
Don't you also need an entry for the case where CONFIG_USB_GADGET isn't
enabled?
Alan Stern
driver will get invalid memory accesses if
fsg_unbind returns too early. fsg will be deallocated, but
fsg_set_interface will continue to use it. This patch completely
ignores that issue.
Was there any real reason for writing this patch? Does it solve a
real-world problem? Did you encounter a situation where the wait_event
call would wait for more than 1/4 second?
Alan Stern
urb_suitable_for_idt(urb) ||
> + (usb_endpoint_xfer_control(>ep->desc)))
> return 0;
Would this affect the map/unmap operations for the DATA packets in a
control transfer, along with the SETUP packet?
Alan Stern
On Tue, Jan 12, 2021 at 09:20:10PM -0800, syzbot wrote:
> syzbot suspects this issue was fixed by commit:
>
> commit c318840fb2a42ce25febc95c4c19357acf1ae5ca
> Author: Alan Stern
> Date: Wed Dec 30 16:20:44 2020 +
>
> USB: Gadget: dummy-hcd: Fix shift-out-of-boun
>
> so, when the driver goes to sleep and changes the system state to
> suspend, the interrupt flag needs to be cleared.
>
> Signed-off-by: Longfang Liu
Acked-by: Alan Stern
> ---
>
> Changes in v2:
> - updated cleared registers
>
> drivers/usb/host/ehci-hub.c | 4 ++
ported any problems caused by
that patch, so adding it to the stable branches should be safe enough.
> What do you think?
We could even do both. That would help if, for example, somebody
decided to set ohci_hcd.distrust_firmware=true explicitly.
Greg, in the meantime can we have commit c4
ut these subsystems to evaluate this. Can you
take a look at it?
Thank,
Alan Stern
On Tue, Dec 29, 2020 at 08:33:39AM -0800, syzbot wrote:
> > #syz test: upstream e37b12e4
>
> "upstream" does not look like a valid git repo address.
I thought syzbot had been changed to recognize "upstream" as a valid
repo name.
Alan Stern
#syz test: https://git
003
> RBP: 006ce018 R08: R09: 004002e0
> R10: 000f R11: 0246 R12: 00401bb0
> R13: 00401c40 R14: R15:
> ====
The cause is pret
IA Tegra SoCs. The controllers are EHCI compliant.
It doesn't really make sense to say "... the driver was removed..."
and then in the next paragraph say "This driver enables...". You
should change the second paragraph to begin: "Enable support for...".
That's a minor matter, though, and you can easily fix it in the next
patch version. Everything else is okay.
Acked-by: Alan Stern
Alan Stern
On Wed, Dec 16, 2020 at 08:09:51PM +0300, Dmitry Osipenko wrote:
> 16.12.2020 19:45, Alan Stern пишет:
> > On Tue, Dec 15, 2020 at 11:21:12PM +0300, Dmitry Osipenko wrote:
> >> The ChipIdea driver now provides USB2 host mode support for NVIDIA Tegra
> >> SoCs. The ehci-t
the internal USB Host Controllers
> - found in NVIDIA Tegra SoCs. The controllers are EHCI compliant.
For people upgrading from earlier kernel versions, do you think it
would help to add a pointer here telling them which Kconfig option
they need to enable now in order to get this functionality?
Alan Stern
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 9270e1a744f8ed953009b0e94b26ed0912d9ec1c
Gitweb:
https://git.kernel.org/tip/9270e1a744f8ed953009b0e94b26ed0912d9ec1c
Author:Alan Stern
AuthorDate:Sat, 03 Oct 2020 21:40:22 -04:00
Committer
re
which might select CONFIG_EHCI_BIG_ENDIAN_MMIO, as used in ehci.h.
Otherwise we're left in the unfortunate position of having to provide
definitions for these functions, but _only_ on architectures that don't
already make their own definitions -- basically an impossible task.
Alan Stern
fore the queue is unfrozen.
> > */
> > - if ((pm && q->rpm_status != RPM_SUSPENDED) ||
> > - !blk_queue_pm_only(q)) {
> > + if ((pm && !rq_suspended(q)) || !blk_queue_pm_only(q))
> > success = true;
> > - } else {
> > + else
> > percpu_ref_put(>q_usage_counter);
> > - }
> > }
> > rcu_read_unlock();
Yes, that certainly is the proper fix. It's all to easy to miss these
issues that depend on your kernel configuration.
Bart, can you fold it into a new version of the patch?
Alan Stern
1 - 100 of 5703 matches
Mail list logo
