space I can
> cut memory usage by about 75%.
>
> Signed-off-by: Lorenz Bauer
For the series,
Tested-by: Alan Maguire
Tested with 4k and 64k page size on aarch64; all worked perfectly. Thanks!
evel/pahole/pahole.git
...prior to that, that would be great. Thanks!
Alan
* li...@treblig.org (li...@treblig.org) wrote:
> From: "Dr. David Alan Gilbert"
>
> The last use of paravirt_disable_iospace() was removed in 2015 by
> commit d1c29465b8a5 ("lguest: don't disable iospace.")
>
> Remove it.
>
> Note the comment ab
* Alison Schofield (alison.schofi...@intel.com) wrote:
> On Thu, Feb 20, 2025 at 12:45:36AM +, li...@treblig.org wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > Hi,
> > A couple of nvdimm dead coding patches; they just
> > remove entirely unuse
* Stefan Schmidt (ste...@datenfreihafen.org) wrote:
> Hello Dave,
>
> On 30.12.24 18:44, Dr. David Alan Gilbert wrote:
> > * Stefan Schmidt (ste...@datenfreihafen.org) wrote:
> > > Hello li...@treblig.org.
> > >
> > > On Wed, 25 Dec 20
een thinking I had to wait for net-next to reopen.
Dave
> [1/1] net: mac802154: Remove unused ieee802154_mlme_tx_one
> https://git.kernel.org/wpan/wpan-next/c/bddfe23be8f8
>
> regards,
> Stefan Schmidt
--
-Open up your eyes, open up your mind, open up your code
On Oct 24, 2024, at 00:40, Paul E. McKenney wrote:
>
> On Wed, Oct 23, 2024 at 02:58:07PM +0800, Alan Huang wrote:
>> On Oct 22, 2024, at 22:26, Paul E. McKenney wrote:
>>>
>>> On Tue, Oct 22, 2024 at 12:13:12AM -0700, Christoph Hellwig wrote:
>>>>
On Oct 24, 2024, at 00:34, Andrii Nakryiko wrote:
>
> On Tue, Oct 22, 2024 at 11:40 PM Christoph Hellwig wrote:
>>
>> On Tue, Oct 22, 2024 at 10:29:13AM -0700, Andrii Nakryiko wrote:
Would this work?
#define SRCU_INVALID_INDEX -1
>>>
>>> But why?
>>
>> Becaue it ve
On Oct 22, 2024, at 22:26, Paul E. McKenney wrote:
>
> On Tue, Oct 22, 2024 at 12:13:12AM -0700, Christoph Hellwig wrote:
>> On Tue, Oct 22, 2024 at 09:10:18AM +0200, Peter Zijlstra wrote:
>>> Ah, well, the thing that got us here is that we (Andrii and me) wanted
>>> to use -1 as an 'invalid' val
to respond to this critique.
Alan
> Possibly something like:
> c = b;
> OPTIMISER_HIDE_VAR(c);
> if (a == c) {
> *b
> will ensure that there isn't a speculative load from *a.
> You'll get at least one register-register move - but they ar
On Wed, Oct 02, 2024 at 08:13:15AM +, David Laight wrote:
> From: 'Alan Stern'
> > Sent: 01 October 2024 23:57
> >
> > On Tue, Oct 01, 2024 at 05:11:05PM +, David Laight wrote:
> > > From: Alan Stern
> > > > Sent: 30 September 2024 19:5
On Tue, Oct 01, 2024 at 05:11:05PM +, David Laight wrote:
> From: Alan Stern
> > Sent: 30 September 2024 19:53
> >
> > On Mon, Sep 30, 2024 at 07:05:06PM +0200, Jonas Oberhauser wrote:
> > >
> > >
> > > Am 9/30/2024 um 6:43 PM schrieb Alan S
On Mon, Sep 30, 2024 at 07:05:06PM +0200, Jonas Oberhauser wrote:
>
>
> Am 9/30/2024 um 6:43 PM schrieb Alan Stern:
> > On Mon, Sep 30, 2024 at 01:26:53PM +0200, Jonas Oberhauser wrote:
> > >
> > >
> > > Am 9/28/2024 um 4:49 PM schrieb Alan Stern:
&g
On Mon, Sep 30, 2024 at 01:26:53PM +0200, Jonas Oberhauser wrote:
>
>
> Am 9/28/2024 um 4:49 PM schrieb Alan Stern:
> > On Sat, Sep 28, 2024 at 09:51:27AM -0400, Mathieu Desnoyers wrote:
> > > Compiler CSE and SSA GVN optimizations can cause the address dependency
> &
On Sep 30, 2024, at 17:33, Jonas Oberhauser
wrote:
>
>
>
> Am 9/30/2024 um 11:27 AM schrieb Alan Huang:
>> 2024年9月30日 17:15，Alan Huang 写道：
>>>
>>> 2024年9月30日 16:57，Jonas Oberhauser 写道：
>>>>
>>>>
>>>>
>>
2024年9月30日 17:15，Alan Huang 写道：
>
> 2024年9月30日 16:57，Jonas Oberhauser 写道：
>>
>>
>>
>> Am 9/29/2024 um 12:26 AM schrieb Alan Huang:
>>> 2024年9月28日 23:55，Mathieu Desnoyers wrote：
>>>>
>>>> On 2024-09-28 17:49, Alan Stern
2024年9月30日 16:57，Jonas Oberhauser 写道：
>
>
>
> Am 9/29/2024 um 12:26 AM schrieb Alan Huang:
>> 2024年9月28日 23:55，Mathieu Desnoyers wrote：
>>>
>>> On 2024-09-28 17:49, Alan Stern wrote:
>>>> On Sat, Sep 28, 2024 at 11:32:18AM -0400, Mathieu Desnoy
ch better. Thank you.
Acked-by: Alan Stern
Alan Stern
2024年9月29日 07:55，Boqun Feng wrote：
>
>
>
> On Sun, Sep 29, 2024, at 6:26 AM, Alan Huang wrote:
>> 2024年9月28日 23:55，Mathieu Desnoyers wrote：
>>>
>>> On 2024-09-28 17:49, Alan Stern wrote:
>>>> On Sat, Sep 28, 2024 at 11:32:18AM -0400, Mathieu
2024年9月29日 06:10，Alan Huang wrote：
>
> 2024年9月28日 06:18，Jonas Oberhauser wrote：
>>
>>
>>
>> Am 9/27/2024 um 10:10 PM schrieb Mathieu Desnoyers:
>>> On 2024-09-27 21:23, Jonas Oberhauser wrote:
>>> [...]
>>>> That idea seems to be co
2024年9月28日 23:55，Mathieu Desnoyers wrote：
>
> On 2024-09-28 17:49, Alan Stern wrote:
>> On Sat, Sep 28, 2024 at 11:32:18AM -0400, Mathieu Desnoyers wrote:
>>> On 2024-09-28 16:49, Alan Stern wrote:
>>>> On Sat, Sep 28, 2024 at 09:51:27AM -0400, Mathieu Desnoyers
2024年9月28日 06:18，Jonas Oberhauser wrote：
>
>
>
> Am 9/27/2024 um 10:10 PM schrieb Mathieu Desnoyers:
>> On 2024-09-27 21:23, Jonas Oberhauser wrote:
>> [...]
>>> That idea seems to be confirmed by this (atrocious, not to be copied!)
>>> example:
>>>
>>> int fct_escape_address_of_b(void)
>>> {
On Sat, Sep 28, 2024 at 11:55:22AM -0400, Mathieu Desnoyers wrote:
> On 2024-09-28 17:49, Alan Stern wrote:
> > On Sat, Sep 28, 2024 at 11:32:18AM -0400, Mathieu Desnoyers wrote:
> > > On 2024-09-28 16:49, Alan Stern wrote:
> > > > On Sat, Sep 28, 2024 at 09:51:27AM
On Sat, Sep 28, 2024 at 11:32:18AM -0400, Mathieu Desnoyers wrote:
> On 2024-09-28 16:49, Alan Stern wrote:
> > On Sat, Sep 28, 2024 at 09:51:27AM -0400, Mathieu Desnoyers wrote:
> > > equality, which does not preserve address dependencies and allows the
> > > followi
rcu_dereference() against another pointer.
>
> Signed-off-by: Mathieu Desnoyers
> Cc: Greg Kroah-Hartman
> Cc: Sebastian Andrzej Siewior
> Cc: "Paul E. McKenney"
> Cc: Will Deacon
> Cc: Peter Zijlstra
> Cc: Boqun Feng
> Cc: Alan Stern
> Cc: John St
Suggested-by: Linus Torvalds
> Suggested-by: Boqun Feng
> Signed-off-by: Mathieu Desnoyers
> Reviewed-by: Boqun Feng
> Acked-by: "Paul E. McKenney"
> Cc: Greg Kroah-Hartman
> Cc: Sebastian Andrzej Siewior
> Cc: "Paul E. McKenney"
> Cc: Will D
2024年9月27日 12:28，Boqun Feng wrote：
>
> On Fri, Sep 27, 2024 at 09:37:50AM +0800, Boqun Feng wrote:
>>
>>
>> On Fri, Sep 27, 2024, at 9:30 AM, Mathieu Desnoyers wrote:
>>> On 2024-09-27 02:01, Boqun Feng wrote:
#define ADDRESS_EQ(var, expr) \
({ \
bool _cmp_res = (unsigned lon
2024年9月20日 02:58，Boqun Feng wrote：
>
> On Thu, Sep 19, 2024 at 09:57:12PM +0800, Alan Huang wrote:
> [...]
>>>
>>> I think you're right. (Although the node will be eventually deleted at
>>> cleanup_hazptr_context(), however there could be a lo
2024年9月19日 15:10，Boqun Feng wrote：
>
> On Thu, Sep 19, 2024 at 02:39:13PM +0800, Lai Jiangshan wrote:
>> On Tue, Sep 17, 2024 at 10:34 PM Boqun Feng wrote:
>>
>>> +static void hazptr_context_snap_readers_locked(struct hazptr_reader_tree
>>> *tree,
>>> +
2024年9月19日 15:10，Boqun Feng wrote：
>
> On Thu, Sep 19, 2024 at 02:39:13PM +0800, Lai Jiangshan wrote:
>> On Tue, Sep 17, 2024 at 10:34 PM Boqun Feng wrote:
>>
>>> +static void hazptr_context_snap_readers_locked(struct hazptr_reader_tree
>>> *tree,
>>> +
2024年9月19日 15:10，Boqun Feng wrote：
>
> On Thu, Sep 19, 2024 at 02:39:13PM +0800, Lai Jiangshan wrote:
>> On Tue, Sep 17, 2024 at 10:34 PM Boqun Feng wrote:
>>
>>> +static void hazptr_context_snap_readers_locked(struct hazptr_reader_tree
>>> *tree,
>>> +
2024年9月17日 22:33，Boqun Feng wrote：
>
> Hazard pointers [1] provide a way to dynamically distribute refcounting
> and can be used to improve the scalability of refcounting without
> significant space cost.
>
> Hazard pointers are similar to RCU: they build the synchronization
> between two part,
* Li, Fei1 (fei1...@intel.com) wrote:
> > -Original Message-
> > From: Dr. David Alan Gilbert
> > Sent: Friday, July 19, 2024 1:44 AM
> > To: Li, Fei1
> > Cc: linux-kernel@vger.kernel.org; virtualizat...@lists.linux.dev
> > Subject: Re: [PA
* Fei Li (fei1...@intel.com) wrote:
> On 2024-05-18 at 00:12:46 +, Dr. David Alan Gilbert wrote:
> > * li...@treblig.org (li...@treblig.org) wrote:
> > > From: "Dr. David Alan Gilbert"
> > >
> > > It doesn't look like this was ever used.
* 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 f
* 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 u
:
>
> /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 |___/
would be good to confirm.
> Signed-off-by: Masami Hiramatsu (Google)
Reviewed-by: Alan Maguire
> ---
> include/linux/btf.h| 24 +
> kernel/bpf/btf.c | 115 +
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 h
n the to-do list?
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=a
--
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
> expect the runtime PM to 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
bind
> callback.
>
> To 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
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 re
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 writ
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&#x
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:
> > >
t; 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
t actually 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
&
Arnd has already looked at this:
https://marc.info/?t=15882824021&r=1&w=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
- else if (PMSG_IS_AUTO(msg) || usb_wakeup_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 d
ze_irq emulation code in dummy_pullup.
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 not a
good place to delay, but it may be okay just for testing purposes.
Hopefully this patch will make the
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
> >
hdev, port1,
> - 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 pr
controller 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.
>
t, along with 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
Saenz 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 th
, it is verified by the stress test of sleep
> 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 ++-
>
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 cloc
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_
mutex_unlock(&usb_port_peer_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 - inter
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
, that would be great.
Otherwise, I'll 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
least 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
+ clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
> + spin_unlock_irqrestore(&ohci->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
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_
+ if (ret)
> + 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
rmally.
>
> 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
hence it's
> 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 +
&
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.
> > &
alls won't fix the 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
>
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
r, 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
> [Fri Mar 12 18:36:50 2021] SCSI ioctl error, cmd 85, prog pool-udisksd
Although it's not conclusive, this log
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
m_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 yo
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
> ---
> dri
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
at type 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.
Yo
onsumers, it all goes back to normal, which is kind of expected. I tried
> resuming the consumer and the supplier is resumed and the supplier is
> suspended when all the consumers are suspended.
>
> Any pointers on this issue please?
>
> @Bart/@Alan - Do you've any pointer
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
> > progra
st thing to do 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
> >
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
1 - 100 of 8863 matches
Mail list logo
