* li...@treblig.org (li...@treblig.org) wrote:
> From: "Dr. David Alan Gilbert"
>
> It doesn't look like this was ever used.
>
> Build tested only.
>
> Signed-off-by: Dr. David Alan Gilbert
Ping
> ---
> drivers/virt/acrn/irqfd.c | 2 --
> 1 file
* li...@treblig.org (li...@treblig.org) wrote:
> From: "Dr. David Alan Gilbert"
>
> Commit 8788ca164eb4b ("ftrace: Remove the legacy _ftrace_direct API")
> stopped setting the 'ftrace_direct_func_count' variable, but left
> it around. Clean it up.
>
&
* Steven Rostedt (rost...@goodmis.org) wrote:
> On Sat, 4 May 2024 13:35:26 +
> "Dr. David Alan Gilbert" wrote:
>
> > Hi,
> > I've just posted a patch 'ftrace: Remove unused list
> > 'ftrace_direct_funcs''
> > that clears out some old
our code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
/proc/2821/net/dev_snmp6/eth0
>
> This looks exactly like something coming from userspace and making it
> into /proc, so the filter function doesn't belong to kernel/module/internal.h
You mean like:
[24180.292204] tuxthe: renamed from tuxthe
root@dalek:/home/dg# ls /sys/class/net/
enp5s0 lo tuxthe tuxthe tuxthe virbr0 virbr1
?
Dave
>
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
to confirm.
> Signed-off-by: Masami Hiramatsu (Google)
Reviewed-by: Alan Maguire
> ---
> include/linux/btf.h| 24 +
> kernel/bpf/btf.c | 115 +
> kernel/tr
On 04/10/2023 22:43, Steven Rostedt wrote:
> On Wed, 4 Oct 2023 22:35:07 +0100
> Alan Maguire wrote:
>
>> One thing we've heard from some embedded folks [1] is that having
>> kernel BTF loadable as a separate module (rather than embedded in
>> vmlinux) would hel
t?
Not necessarily for this particular use-case (since there are
complications with trace data as you describe), but just trying to make
sure we can remove barriers to BTF adoption where possible.
Thanks!
Alan
[1]
https://lore.kernel.org/bpf/CAHBbfcUkr6fTm2X9GNsFNqV75fTG=abqxfx_8ayk+
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
Julienne
wrote:
>
> Hi Alan,
>
> On Thu, 2021-04-01 at 11:23 -0400, Alan Cooper wrote:
> > Nicolas,
> >
> > Sorry, I just noticed this thread.
> > This is a known bug in some newer Arasan cores.
> > The problem happens when the difference between the cor
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
>
Nicolas,
Sorry, I just noticed this thread.
This is a known bug in some newer Arasan cores.
The problem happens when the difference between the core clock and the
bus clock is too great.
Limiting the clock to 200KHz minimum should be a good fix.
In my experience, it's only eMMC that needs the
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
gt; [Fri Mar 12 18:36:50 2021] SCSI ioctl error, cmd 85, prog pool-udisksd
> [Fri Mar 12 18:36:50 2021] SCSI ioctl error, cmd 85, prog pool-udisksd
> [Fri Mar 12 18:36:50 2021] SCSI ioctl error, cmd 85, prog pool-udisksd
Although it's not conclusive, this log seems to indicate that ata_id
is t
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
scsi_autopm_put_device() and starts a timer. And then driver_probe_device()
> invoked from __device_attach_async_helper context reduces the
> link->rpm_active to 1 thus enabling the supplier to suspend before the
> consumer suspends.
> I don't see a way around this. Please let me know if you
>
On Mon, Mar 08, 2021 at 10:52:05AM +0800, Chunfeng Yun wrote:
> Add a new function to convert bInterval into the time expressed
> in 1us unit.
>
> Signed-off-by: Chunfeng Yun
> ---
> v2: move kerneldoc next to function's definition suggested by Alan
> ---
> drivers/
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
of device already has a quirk entry built
into the kernel. You can find it by searching for "174c" in the kernel
source file drivers/usb/storage/unusual_devs.h.
> Thanks Alan for all the hints and tips in the topic "usb-storage and
> quirks" and your patience.
You can try
gt;sdev_gendev,
> DL_FLAG_PM_RUNTIME|DL_FLAG_RPM_ACTIVE);
> I didn't expect this to resolve the issue anyway and it didn't.
>
> Another interesting point here is when I resume any of the above suspended
> consumers, it all goes back to normal, which is ki
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:
> > > &
ies whenever there is a
conditional branch, whether the branch is taken or not, and so they will
never reorder B before A.
One last thing to think about: My original assessment or Björn's problem
wasn't right, because the dep in (dep ; rfi) doesn't include control
dependencies. Only data and address. So I believe that the LKMM
wouldn't consider A to be ordered before B in this example even if x
was nonzero.
Alan
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
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
it in 5.11!).
The questions listed below are pretty self-contained, although the rest
of the discussion isn't. But I never received any answers.
Alan
; 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
e
sense to #define __kunit_fail_current_test() instead, i.e.
#define __kunit_fail_current_test(file, line, fmt, ...) \
do {\
kunit_set_failure(current->kunit_test); \
kunit_err(current->kunit_test, "%s:%d: " fmt, \
##__VA_ARGS__); \
} while (0)
> > + if (!buffer)
> > + return;
> > +
> > + va_start(args, fmt);
> > + vsnprintf(buffer, len, fmt, args);
> > + va_end(args);
> > +
> > + kunit_err(current->kunit_test, "%s:%d: %s", file, line, buffer);
To get kunit_err() to work, we'd need to "static inline"
kunit_log_append(). It's not a trivial function, but on the plus
side it doesn't call any other exported kunit functions AFAICT.
So while any of the above suggestions aren't intended to block
Daniel's work, does the above seem reasonable for a follow-up
series to get UBSAN working with module-based KUnit? Thanks!
Alan
pplying them
> previously and the series was reverted.
>
> This revives the series but makes the kunit_fail_current_test() function
> take a format string and logs the file and line number of the failing
> code, addressing Alan Maguire's comments on the previous version.
>
>
On Tue, 9 Feb 2021, Daniel Latypov wrote:
> On Tue, Feb 9, 2021 at 9:26 AM Alan Maguire wrote:
> >
> > On Fri, 5 Feb 2021, Daniel Latypov wrote:
> >
> > > From: Uriel Guajardo
> > >
> > > Add a kunit_fail_current_test() function to fail the cur
On Fri, 5 Feb 2021, Daniel Latypov wrote:
> From: Uriel Guajardo
>
> Add a kunit_fail_current_test() function to fail the currently running
> test, if any, with an error message.
>
> This is largely intended for dynamic analysis tools like UBSAN and for
> fakes.
> E.g. say I had a fake ops
/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,
> I just posted a new patch for this, please have a look and test it.
>
> Kind regards
> Uffe
I tested your new patch and it works.
Reviewed-and-tested-by: Al Cooper
Thanks
Al
On Tue, Jan 26, 2021 at 4:55 AM Ulf Hansson wrote:
>
> On Mon, 25 Jan 2021 at 18:40, Florian Fainelli wrote:
> >
>
- 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
1 - 100 of 20876 matches
Mail list logo
