ave access to the system where the original issue
> was reported but chances we're fixing it are very good IMO as just the
> second patch alone was reported to be sufficient.
>
> Reported-by: Dr. David Alan Gilbert
Oh nice, I was just going to bump the magic number :-)
Anyway, this seems
On Tue, Sep 15, 2020 at 01:01:11PM +0200, Greg KH wrote:
> On Tue, Sep 15, 2020 at 11:45:31AM +0200, Eugeniu Rosca wrote:
> > Dear Alan,
> > Dear Greg,
> >
> > On Fri, Sep 11, 2020 at 11:12:28AM -0400, Alan Stern wrote:
> >
> > > The thing is, I'm a
On Tue, Sep 15, 2020 at 11:45:31AM +0200, Eugeniu Rosca wrote:
> Dear Alan,
> Dear Greg,
>
> On Fri, Sep 11, 2020 at 11:12:28AM -0400, Alan Stern wrote:
>
> > The thing is, I'm afraid that without these retry loops, some devices
> > will stop working. If that h
led autosuspend support
See https://marc.info/?l=linux-usb=159914635920888=2 and the
accompanying submissions. You'll probably want to include those updates
in your driver.
Alan Stern
On Mon, Sep 14, 2020 at 05:37:49PM +0200, Greg Kroah-Hartman wrote:
> There are a few calls to usb_control_msg() that can be converted to use
> usb_control_msg_send() instead, so do that in order to make the error
> checking a bit simpler and the code smaller.
>
> Cc: Alan Ster
f the array).
>
> I wasn't sure if I should add a new property or somehow detect the affected
> host controller. I settled on using of_device_is_compatible() as that seemed
> the simplest thing to do.
>
> Changes in v2:
> - move workaround to ehci_platform_reset
> - cosmetic chan
For quirk OHCI_QUIRK_AMD756 or OHCI_QUIRK_HUB_POWER power switching
> remains at none, while over-current protection is now guaranteed to be
> set to per-port rather than the previous behaviour where it was either
> none or global over-current protection depending on the value
On Fri, Sep 11, 2020 at 09:25:12AM +1200, Hamish Martin wrote:
> The 'distrust_firmware' module parameter dates from 2004 and the USB
> subsystem is a lot more mature and reliable now than it was then.
> Alter the default to false now.
>
> Suggested-by: Alan Stern
> Signed-off
ice_is_compatible(dev->dev.of_node, "brcm,xgs-iproc-ehci"))
> + ehci_writel(ehci, BCM_USB_FIFO_THRESHOLD,
> + ehci->regs->bcm_iproc_insnreg01);
In theory, this should go before the usb_add_hcd() call because
afterward the controller is
dirty page. I understood it would be faster
> to use LDGM, but we'd need a new ioctl for that. So I was proposing we
> just piggyback on a new dirty-log ioctl instead.
That feels a bad idea to me; there's a couple of different ways dirty
page checking work; lets keep extracting the tags separate.
Dave
> Thanks,
> drew
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
On Wed, Sep 09, 2020 at 09:44:05PM +0800, YueHaibing wrote:
> commit b35c5009bbf6 ("USB: EHCI: create per-TT bandwidth tables")
> left behind this, remove it.
>
> Signed-off-by: YueHaibing
Acked-by: Alan Stern
e previous behaviour where it was either
> none or global over-current protection depending on the value at
> function entry.
Also consider renaming OHCI_QUIRK_HUB_POWER to something like
OHCI_QUIRK_PORT_POWER_ALWAYS_ON.
> Suggested-by: Alan Stern
> Signed-off-by: Hamish Martin
&
On Mon, Sep 07, 2020 at 04:16:34PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Sep 03, 2020 at 09:32:30AM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Sep 02, 2020 at 08:45:53PM -0400, Alan Stern wrote:
> > > Since this routine is used in only one place in the entire kernel
| 15 +++
> arch/arm64/kvm/reset.c | 8
> arch/arm64/kvm/sys_regs.c | 20 +++-
> 8 files changed, 66 insertions(+), 7 deletions(-)
>
> --
> 2.20.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
On Mon, Sep 07, 2020 at 04:51:01PM +0200, Greg Kroah-Hartman wrote:
> There are a few calls to usb_control_msg() that can be converted to use
> usb_control_msg_send() instead, so do that in order to make the error
> checking a bit simpler and the code smaller.
>
> Cc: Alan Ster
n_lock *sl, int *x)
{
spin_lock(sl);
WRITE_ONCE(x, 1);
spin_unlock(sl);
}
This will always run to completion. But if the loop in P0 is moved into
the critical section, the test may never end. Again, you don't need
fancy memory models to understand this; you just need to know that
critical sections are mutually exclusive.
But if this example didn't have a loop, allowing the memory access to
leak into the critical section would be fine.
Alan
right, for two reasons. First, isn't per-port
overcurrent protection the default?
Second, RH_A_OCPM doesn't do anything unless RH_A_NOCP is clear.
Alan Stern
> ohci_writel (ohci, RH_HS_LPSC, >regs->roothub.status);
> ohci_writel (ohci, (val & RH_A_NPS) ? 0 : RH_B_PPCM
ci-platform",
> - .pm = _platform_pm_ops,
> + .pm = pm_ptr(_platform_pm_ops),
> .of_match_table = vt8500_ehci_ids,
> .acpi_match_table = ACPI_PTR(ehci_acpi_match),
> }
> --
> 2.28.0
For patches 2 - 4:
Acked-by: Alan Stern
OHCI_BIG_ENDIAN_DESC not set\n");
> err = -EINVAL;
> goto err_reset;
> }
> -#endif
>
> pm_runtime_set_active(>dev);
> pm_runtime_enable(>dev);
The changes above don't seem to have any connection with the patch
description.
=
> + USB_QUIRK_IGNORE_REMOTE_WAKEUP },
> +
> /* Realtek hub in Dell WD19 (Type-C) */
> { USB_DEVICE(0x0bda, 0x0487), .driver_info = USB_QUIRK_NO_LPM },
Please follow the instructions at the start of the file about keeping
the entries sorted by vendor ID and product ID.
Alan Stern
ch the existing
> usb_urb_ep_type_check() call, which now uses this function.
>
> Cc: Jaroslav Kysela
> Cc: Takashi Iwai
> Cc: "Gustavo A. R. Silva"
> Cc: Eli Billauer
> Cc: Emiliano Ingrassia
> Cc: Alan Stern
> Cc: Alexander Tsoy
> Cc: "Geoffrey D. Benn
o?
Sigh. That never occurred to me, but of course it is right.
Acked-by: Alan Stern
Alan Stern
> Signed-off-by: Pavel Machek (CIP)
>
> diff --git a/drivers/usb/misc/yurex.c b/drivers/usb/misc/yurex.c
> index 785080f79073..5fbbb57e6e95 100644
> --- a/drivers/usb/misc/yurex
On Wed, Sep 02, 2020 at 01:01:06PM +0200, Greg Kroah-Hartman wrote:
> There are a few calls to usb_control_msg() that can be converted to use
> usb_control_msg_send() instead, so do that in order to make the error
> checking a bit simpler and the code smaller.
>
> Cc: Alan Ster
n the driver somewhere and should be solved.
Correction: You're using two different drivers. Although it's not
impossible, it seems very unlikely that they both contain the same bug.
Alan Stern
On Tue, Sep 01, 2020 at 10:04:21AM -0700, Paul E. McKenney wrote:
> On Mon, Aug 31, 2020 at 09:45:04PM -0400, Alan Stern wrote:
> > The question is, what are you trying to accomplish in this section? Are
> > you trying to demonstrate that it isn't safe to allow arbitrary co
On Tue, Sep 01, 2020 at 11:00:16AM -0600, Khalid Aziz wrote:
> On 9/1/20 10:36 AM, Alan Stern wrote:
> > On Tue, Sep 01, 2020 at 09:15:46AM -0700, Khalid Aziz wrote:
> >> On 8/31/20 8:31 PM, Alan Stern wrote:
> >>> Can you collect a usbmon trace show
On Tue, Sep 01, 2020 at 09:15:46AM -0700, Khalid Aziz wrote:
> On 8/31/20 8:31 PM, Alan Stern wrote:
> > Can you collect a usbmon trace showing an example of this problem?
> >
>
> I have attached usbmon traces for when USB hub with keyboards and mouse
> is plugged in
t will help clear this up.
Or maybe the hubs you are testing don't work right. That's the only
reason I can think of for the failures you see with the USB-3
controller; the way it operates is very different from the way EHCI
does.
Alan Stern
it you referenced above specifically
mentions that when MMF is set and the PID code is IN then it is not a
STALL.
> Removing the code that returns EPROTO for such case solves the
> problem on my machine (as in the RFC patch)
It certainly can't solve the problem for any USB-3 connections, because
the patch doesn't touch any of the USB-3 driver code.
> but that probably is not
> the right solution. I do not understand USB protocol well enough to
> propose a better solution. Does anyone have a better idea?
Can you collect a usbmon trace showing an example of this problem?
One possibility is to introduce a special quirk for the NEC uPD72010x
EHCI controller. But we should hold off on that until we know exactly
what is happening.
Alan Stern
On Mon, Aug 31, 2020 at 02:47:38PM -0700, Paul E. McKenney wrote:
> On Mon, Aug 31, 2020 at 04:17:01PM -0400, Alan Stern wrote:
> > Is this discussion perhaps overkill?
> >
> > Let's put it this way: Suppose we have the following code:
> >
turning RMW operations whose names end in
> + _acquire. These operations order their own load against
> + all of the CPU's prior memory accesses.
-^
Double-oops!
Alan
mething();
spin_unlock(lck);
}
P1(int *x, int *lck)
{
while (READ_ONCE(*x) == 0)
;
spin_lock(lck);
do_something_else();
spin_unlock(lck);
}
It's obvious that this test won't deadlock. But if P1 is changed to:
P1(int *x, int *lck)
{
spin_lock(lck);
while (READ_ONCE(*x) == 0)
;
do_something_else();
spin_unlock(lck);
}
then it's equally obvious that the test can deadlock. No need for
fancy memory models or litmus tests or anything else.
Alan
a %s req %p\n", ep->ep.name, req);
> + BUG_ON(!req);
There's no point in adding this. If the function goes on to dereference
a NULL pointer, you'll get the same effect in any case -- an oops.
If you want to make the point that req had better not be NULL, just get
rid of the "if" test entirely. You could even change the list_entry to
list_first_entry.
Alan Stern
On Sat, Aug 29, 2020 at 11:50:03AM +0200, Salvatore Bonaccorso wrote:
> Hi Alan,
>
> I'm following up on this thread because a user in Debian (Dirk, Cc'ed)
> as well encountered the same/similar issue:
>
> On Tue, Jul 21, 2020 at 10:33:25AM -0400, Alan Stern wrote:
> > On
. Neither of those calls
do_proc_bulk() or usb_bulk_msg(), so how did those routines end up in
the stack trace?
In fact, do_proc_bulk() is called only for USBDEVFS_BULK. But the test
doesn't use that ioctl!
What's going on? Am I missing part of the test?
Alan Stern
aligment
> > it can work with and let guest kernel automatically choose a mapping
> > size which meets that min_alignment contraint.
> >
> > B.Send all the mapping sizes supported by kernel to device and then
> > device chooses an alignment as it sees fit. We could probably send
> > a 64bit field and set a bit for every size we support as dax mapping.
> > If we were to go down this path, I think in that case client should
> > respond back with exact mapping size we should use (and not with
> > minimum alignment).
> >
> > I thought intent behind this patch was to implement A.
> >
> > Stefan/David, this patch came from you folks. What do you think?
>
> Yes, I agree with Vivek.
>
> The FUSE server is telling the client the minimum alignment for
> foffset/moffset. The client can map any size it likes as long as
> foffset/moffset meet the alignment constraint. I can't think of a reason
> to do two-way negotiation.
Agreed, because there's not much that the server can do about it if the
client would like a smaller granularity - the servers granularity might
be dictated by it's mmap/pagesize/filesystem. If the client wants a
larger granularity that's it's choice when it sends the setupmapping
calls.
Dave
> Stefan
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
On Tue, Aug 25, 2020 at 11:46 AM Rob Herring wrote:
>
> +Linus W
>
> On Tue, Aug 25, 2020 at 6:26 AM Alan Cooper wrote:
> >
> > On Mon, Aug 24, 2020 at 7:30 PM Rob Herring wrote:
> > >
> > > On Wed, Aug 12, 2020 at 04:20:16PM -0400, Al Cooper wrote:
&g
ncfg = dev->descriptor.bNumConfigurations;
...
if (ncfg > USB_MAXCONFIG) {
dev_warn(ddev, "too many configurations: %d, "
"using maximum allowed: %d\n", ncfg, USB_MAXCONFIG);
dev->descriptor.bNumConfigurations = ncfg = USB_MAXCONFIG;
}
If you want to fix the bug, you need to figure out why this isn't
working.
Alan Stern
converting everything
> over to a sane, and checkable, api and remove a bunch of wrapper
> functions as well.
Suggestion: _read and _send are not a natural pair. Consider instead
_read and _write. _recv and _send don't feel right either, because it
both cases the host sends the control message -- the difference lies
in who sends the data.
Alan Stern
On Mon, Aug 24, 2020 at 7:30 PM Rob Herring wrote:
>
> On Wed, Aug 12, 2020 at 04:20:16PM -0400, Al Cooper wrote:
> > Add DT bindings for the Broadcom USB pin map driver. This driver allows
> > some USB input and output signals to be mapped to any GPIO instead
> > of the normal dedicated pins
>
> > In my experience it's generally frowned upon for functions to store
> > results in error paths.
>
> Then maybe v1 is more appropriate.
>
> Else i can spin a v3.
>
> My preference is v1 as it doesn't add any runtime if-checks.
If you really want to get rid of the runtime check (both the one you
added and the one already present), you can audit all the callers of
this routine to make certain that none of them pass a NULL pointer for
act_len.
Alan Stern
static analyzer objects
to.
> In my experience it's generally frowned upon for functions to store
> results in error paths.
I don't see any reason for such an attitude, at least not here. It
makes perfectly good sense, if an error prevents transmission of an
entire data buffer, to store the amount of data that did get
transmitted.
Alan Stern
sure that its runtime-resume callbacks will not be confused by that
> + * change in case they are invoked going forward.
> */
> - if (pm_runtime_barrier(dev) && device_may_wakeup(dev))
> - pm_wakeup_event(dev, 0);
> + pm_runtime_barrier(dev);
>
> if (pm_wakeup_pending()) {
> dev->power.direct_complete = false;
Acked-by: Alan Stern
I'm going to re-spin the patch with this code simplification
> and updated changelog.
>
> > Will this fix the reported bug?
>
> I think so.
Okay, we'll see!
Alan Stern
usb_stor_bulk_transfer_sglist(): Make it store 0 to *act_len at the
start.
That way you change only one localized piece of code, instead of
changing multiple callers and leaving a possibility of more errors being
added in the future.
Alan Stern
t:
pm_runtime_barrier(dev);
Will this fix the reported bug? It seems likely to me that the actual
problem with the failure scenario in the patch description was that
turning on an ACPI power resource causes runtime-resume requests to be
queued for all devices sharing that resource. Wouldn't it make more
sense to resume only the device that requested it and leave the others
in runtime suspend?
Alan Stern
right thing without constant checking.
Alan Stern
On Wed, Aug 19, 2020 at 08:41:05PM +0800, Chunfeng Yun wrote:
> Use readl_poll_timeout_atomic() to simplify code
>
> Cc: Alan Stern
> Cc: Felipe Balbi
> Signed-off-by: Chunfeng Yun
> ---
> drivers/usb/gadget/udc/net2280.c | 21 ++---
> 1 file chang
On Tue, Aug 18, 2020 at 11:54:51AM +0100, Jim Baxter wrote:
> On 17/08/2020 19:47, Alan Stern wrote:
> >
> > Unplugging a R/W USB drive without unmounting it first is a great way to
> > corrupt the data.
> >
> Thank you, post development we will only mount the U
On Fri, 14 Aug 2020, Alexei Starovoitov wrote:
> On Fri, Aug 14, 2020 at 02:06:37PM +0100, Alan Maguire wrote:
> > On Wed, 12 Aug 2020, Alexei Starovoitov wrote:
> >
> > > On Thu, Aug 06, 2020 at 03:42:23PM +0100, Alan Maguire wrote:
> > > >
>
re
workqueues. Workqueues are allowed to spawn multiple threads; they are
supposed to resize themselves dynamically as required.
Alan Stern
the block and filesystem layers.)
> I guess it may be waiting for a time-out during the operation without the
> unmount.
That seems very unlikely. When a USB device gets unplugged the system
realizes it. Any I/O meant for that device is immediately cancelled;
there are no timeouts.
(Okay, not strictly true; there is a fraction-of-a-second timeout during
which the system waits to see whether the disconnect was permanent or
just a temporary glitch. But you're talking about 6-second long
delays.)
Alan Stern
drivers. They must make sure that their disconnect
routines block until all outstanding calls to usb_set_interface return
(in fact, until all outstanding device accesses have finished).
For instance, in the log extract you showed, it's obvious that the
uvc_start_streaming routine was running after the disconnect routine had
returned, which looks like a bug in itself: Once the disconnect routine
returns, the driver is not supposed to try to access the device at all
because some other driver may now be bound to it.
We can't just call usb_lock_device from within usb_set_interface,
because usb_set_interface is often called with that lock already held.
Alan Stern
On Wed, 12 Aug 2020, Alexei Starovoitov wrote:
> On Thu, Aug 06, 2020 at 03:42:23PM +0100, Alan Maguire wrote:
> >
> > The bpf_trace_printk tracepoint is augmented with a "trace_id"
> > field; it is used to allow tracepoint filtering as typed display
> > i
On Wed, Aug 5, 2020 at 4:28 AM Ulf Hansson wrote:
>
> On Mon, 27 Jul 2020 at 15:07, Alan Cooper wrote:
> >
> > On Fri, Jul 24, 2020 at 7:03 AM Ulf Hansson wrote:
> > >
> > > On Tue, 21 Jul 2020 at 21:18, Al Cooper wrote:
> > > >
> > &g
On Thu, Aug 13, 2020 at 1:40 AM Greg Kroah-Hartman
wrote:
>
> On Wed, Aug 12, 2020 at 04:20:18PM -0400, Al Cooper wrote:
> > From: Al Cooper
> >
> > Add Kconfig and Makefile changes to build brcmstb-usb-pinmap and
> > update MAINTAINERS for the new driver.
>
> This can be part of the previous
"something I want to track across multiple
test case execution".
Again I'm not trying to put you on the hook for any of
the above suggestions (having lockdep support like this is
fantastic!), but I think it'd be good to see if there's a
pattern here we could potentially exploit in other use cases.
Thanks!
Alan
On Tue, Aug 11, 2020 at 11:54:28AM -0700, Tom Rix wrote:
>
> On 8/11/20 10:53 AM, Alan Stern wrote:
> >>> Instead of changing all these call sites, wouldn't it be a lot easier
> >>> just to change rts51x_read_mem() to make it always return a negative
> >
On Tue, Aug 11, 2020 at 10:29:29AM -0700, Tom Rix wrote:
>
> On 8/11/20 9:03 AM, Alan Stern wrote:
> > On Tue, Aug 11, 2020 at 08:15:05AM -0700, t...@redhat.com wrote:
> >> From: Tom Rix
> >>
> >> clang static analysis reports this representative proble
return -EIO;
Instead of changing all these call sites, wouldn't it be a lot easier
just to change rts51x_read_mem() to make it always return a negative
value (such as -EIO) when there's an error?
Alan Stern
On Tue, Aug 11, 2020 at 09:55:54AM +0200, Martin Kepplinger wrote:
> On 10.08.20 16:13, Alan Stern wrote:
> > This may not matter... but it's worth pointing out that
> > expecting_media_change doesn't get cleared if ++scmd->retries >
> > scmd->allowed.
>
> a
of better names, I'm hopeless haha)
How about usb_gadget_enable_endpoints()?
Alan Stern
_write+0x3ea/0x820 drivers/usb/misc/yurex.c:495
This patch changes the call to use GFP_ATOMIC instead of GFP_KERNEL.
Reported-and-tested-by: syzbot+c2c3302f9c601a4b1...@syzkaller.appspotmail.com
Signed-off-by: Alan Stern
CC:
---
[as1940]
drivers/usb/misc/yurex.c |2 +-
1 file changed, 1 ins
ot;);
> + usb_stor_dbg(us, " Not removable media, just report
> okay\n");
> srb->result = SAM_STAT_GOOD;
> sendToTransport = 0;
> }
> --
Acked-by: Alan Stern
b+0xb4e/0x13e0 drivers/usb/core/urb.c:570
> yurex_write+0x3ea/0x820 drivers/usb/misc/yurex.c:495
The yurex driver shouldn't use GFP_KERNEL in a context where the current
state isn't TASK_RUNNING.
Alan Stern
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
449dc8c9
I
On Mon, Aug 10, 2020 at 02:03:17PM +0200, Martin Kepplinger wrote:
> On 09.08.20 17:26, Alan Stern wrote:
> > This is a somewhat fragile approach. You don't know for certain that
> > scsi_noretry_cmd will be called. Also, scsi_noretry_cmd can be called
> > from other plac
On Sun, Aug 09, 2020 at 11:20:22AM +0200, Martin Kepplinger wrote:
> Hey Alan, I'm really glad for that, I suspected some of this but I have
> little experience in scsi/block layers, so that is super helpful.
>
> I'd appreciate an opinion on the below workaround that *seems* to work
On Sat, Aug 08, 2020 at 08:59:09AM +0200, Martin Kepplinger wrote:
> On 07.08.20 16:30, Alan Stern wrote:
> > On Fri, Aug 07, 2020 at 11:51:21AM +0200, Martin Kepplinger wrote:
> >> it's really strange: below is the change I'm trying. Of course that's
> >> only fo
Are you saying that scmd->allowed is set to 0? Or is scsi_notry_cmd()
returning a nonzero value? Whichever is true, why does it happen that
way?
What is the failing command? Is it a READ(10)?
> How can this be? What am I missing?
It's kind of hard to tell without seeing the error messages or
22 [inline]
> __wake_up+0xb8/0x150 kernel/sched/wait.c:142
> __usb_hcd_giveback_urb+0x340/0x4b0 drivers/usb/core/hcd.c:1653
It looks like xpad_disconnect() fails to call xpad_stop_input() if the
hardware isn't an Xbox 360W.
Alan Stern
On Thu, 6 Aug 2020, Uriel Guajardo wrote:
> Adds an API to allow dynamic analysis tools to fail the currently
> running KUnit test case.
>
> - Always places the kunit test in the task_struct to allow other tools
> to access the currently running KUnit test.
>
> - Creates a new header file to
stead of
trace_printk()")
Signed-off-by: Alan Maguire
---
Documentation/bpf/bpf_design_QA.rst | 11 ---
1 file changed, 11 deletions(-)
diff --git a/Documentation/bpf/bpf_design_QA.rst
b/Documentation/bpf/bpf_design_QA.rst
index 12a246f..2df7b06 100644
--- a/Documentation/bpf/bpf_design_QA
Basic tests verifying various flag combinations for bpf_trace_btf()
using a tp_btf program to trace skb data.
Signed-off-by: Alan Maguire
---
tools/testing/selftests/bpf/prog_tests/trace_btf.c | 45 ++
.../selftests/bpf/progs/netif_receive_skb.c| 43
on members;
they are not displayed by default
Signed-off-by: Alan Maguire
---
include/linux/bpf.h| 1 +
include/linux/btf.h| 9 ++--
include/uapi/linux/bpf.h | 63 +
kernel/bpf/core.c | 5 ++
kernel/bpf
h is either all zeros or all 0xff values; the idea is this
exercises the "skip if zero" and "print everything" cases.
- added support in BPF for using the %pT format specifier in
bpf_trace_printk()
- added BPF tests which ensure %pT format specifier use works (Alexei).
Ala
t;
field; it is used to allow tracepoint filtering as typed display
information can easily be interspersed with other tracing data,
making it hard to read. Specifying a trace_id will allow users
to selectively trace data, eliminating noise.
Signed-off-by: Alan Maguire
---
include/linux/bpf.h
It will be used later for BPF structure display support
Signed-off-by: Alan Maguire
---
include/linux/bpf.h | 2 ++
kernel/bpf/verifier.c | 18 --
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index cef4ef0..55eb67d
vior.
>
> Some of them are similar to each other with subtle differences only
> and the behavior of some of them may appear as counter-intuitive, so
> clarify all that to avoid confusion.
>
> Signed-off-by: Rafael J. Wysocki
Acked-by: Alan Stern
releasing the IRQ line. When synchronize_irq() returns, you'll know any
IRQ handlers have finished running, so you won't receive any more
disconnect notifications. Then it will be safe to acquire the spinlock
and set mtu->gadget_driver to NULL.
Alan Stern
On Thu, Jul 30, 2020 at 10:05:50AM +0200, Martin Kepplinger wrote:
> On 29.06.20 18:15, Alan Stern wrote:
> > On Mon, Jun 29, 2020 at 11:42:59AM +0200, Martin Kepplinger wrote:
> >>
> >>
> >> On 26.06.20 17:44, Alan Stern wrote:
> >>> Martin's b
unsigned set_dbd_for_ms:1; /* Set "DBD" field in mode sense */
That's pretty much what James was suggesting, except for one thing: You
must not set sdkp->device->expecting_media_change to 1 for all devices
in sd_runtime_resume(). Only for devices which may generate a spurious
Unit Attention following runtime resume -- and maybe not even for all of
them, depending on what the user wants.
Alan Stern
n Wed, 2020-07-29 at 07:46 -0700, James Bottomley wrote:
> >> > > On Wed, 2020-07-29 at 10:32 -0400, Alan Stern wrote:
> >[...]
> >> > > > This error report comes from the SCSI layer, not the block
> >> > > > layer.
> >> > >
On Wed, Jul 29, 2020 at 08:49:34AM -0700, James Bottomley wrote:
> On Wed, 2020-07-29 at 11:40 -0400, Alan Stern wrote:
> > On Wed, Jul 29, 2020 at 07:53:52AM -0700, James Bottomley wrote:
> > > On Wed, 2020-07-29 at 07:46 -0700, James Bottomley wrote:
> [...]
> >
On Wed, Jul 29, 2020 at 07:53:52AM -0700, James Bottomley wrote:
> On Wed, 2020-07-29 at 07:46 -0700, James Bottomley wrote:
> > On Wed, 2020-07-29 at 10:32 -0400, Alan Stern wrote:
> > > On Wed, Jul 29, 2020 at 04:12:22PM +0200, Martin Kepplinger wrote:
> > > > On 28
On Wed, Jul 29, 2020 at 10:44:26AM -0400, Martin K. Petersen wrote:
>
> Alan,
>
> >> [ 77.474632] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result:
> >> hostbyte=0x00 driverbyte=0x08 cmd_age=0s
> >> [ 77.474647] sd 0:0:0:0: [sda] tag#0 Sense Key : 0x6 [cur
On Wed, Jul 29, 2020 at 04:12:22PM +0200, Martin Kepplinger wrote:
> On 28.07.20 22:02, Alan Stern wrote:
> > On Tue, Jul 28, 2020 at 09:02:44AM +0200, Martin Kepplinger wrote:
> >> Hi Alan,
> >>
> >> Any API cleanup is of course welcome. I just wanted to
On Tue, Jul 28, 2020 at 09:02:44AM +0200, Martin Kepplinger wrote:
> Hi Alan,
>
> Any API cleanup is of course welcome. I just wanted to remind you that
> the underlying problem: broken block device runtime pm. Your initial
> proposed fix "almost" did it and mounting wor
On Mon, Jul 27, 2020 at 05:59:17PM +0100, Matthew Wilcox wrote:
> On Mon, Jul 27, 2020 at 12:31:49PM -0400, Alan Stern wrote:
> > On Mon, Jul 27, 2020 at 04:28:27PM +0100, Matthew Wilcox wrote:
> > > On Mon, Jul 27, 2020 at 11:17:46AM -0400, Alan Stern wrote:
> > > >
On Mon, Jul 27, 2020 at 04:28:27PM +0100, Matthew Wilcox wrote:
> On Mon, Jul 27, 2020 at 11:17:46AM -0400, Alan Stern wrote:
> > Given a type "T", an object x of type pointer-to-T, and a function
> > "func" that takes various arguments and returns a pointer-to-
ies
on a single mutex for all the different possible x's, it might lead to
locking conflicts (if func had to call once_func() recursively, for
example). In most reasonable situations such conflicts would not
arise.
Alan Stern
On Fri, Jul 24, 2020 at 7:03 AM Ulf Hansson wrote:
>
> On Tue, 21 Jul 2020 at 21:18, Al Cooper wrote:
> >
> > When using eMMC as the boot device, some Micron eMMC devices will
> > cause reboot to hang. This is a result of the eMMC device not going
> > into boot mode after the hardware sends CMD0
it seems reasonable
to leave this as a "gentlemen's agreement" in userspace for the time
being instead of adding it to the kernel.
Alan Stern
On Wed, Jul 22, 2020 at 10:18:17PM -0600, Alex Williamson wrote:
> On Thu, 23 Jul 2020 02:59:55 +
> "Weitao Wang(BJ-RD)" wrote:
>
> > On , Jul 22, 2020 at 02:44:14PM +0200, Alan wrote:
> > > On Wed, Jul 22, 2020 at 02:44:14PM +0200, Greg KH wrote:
> >
On Thu, Jul 23, 2020 at 10:59:06AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2020-07-22 at 22:56 +0300, Evgeny Novikov wrote:
> > Hi Alan,
> >
> > I have neither an appropriate hardware nor an experience to deal with
> > issues that you mentioned. Our framewo
On Wed, Jul 22, 2020 at 10:56:09PM +0300, Evgeny Novikov wrote:
> Hi Alan,
>
> I have neither an appropriate hardware nor an experience to deal with
> issues that you mentioned. Our framework does not allow to detect them
> as well at the moment. At last, it seems that rather m
lly, I imagine.
The only way to make this work at all is to unbind both uhci-hcd and
ehci-hcd first. Then after both are finished you can safely bind
vfio-pci to the EHCI controller and the UHCI controllers (in that
order).
Alan Stern
ng this memset? It's hard to
imagine that it does any good.
Similarly, net2280_remove() calls usb_del_gadget_udc(>gadget) at
its start, and so dev must be a stale pointer for the entire remainder
of the routine. But it gets used repeatedly. Surely we ought to have
a device_get() and device_put() in there.
Alan Stern
On Tue, Jul 21, 2020 at 06:00:25PM +0200, Michal Hocko wrote:
> On Tue 21-07-20 10:33:25, Alan Stern wrote:
> [...]
>
> Thanks a lot for your analysis. The laptop is slowly dying so this can
> be related.
>
> > So yes, this looks like a hardware design error. Turn
2a0 -- the same as what the debugging log says.
So yes, this looks like a hardware design error. Turning off
autosuspend by writing to the sysfs power/control file is probably the
best way to handle the problem.
Alan Stern
On Tue, Jul 21, 2020 at 5:33 AM Felipe Balbi wrote:
>
>
> Hi,
>
> Al Cooper writes:
> > Updates and fixes to the Broadcom USB BDC driver.
> >
> > Al Cooper (4):
> > dt-bindings: usb: bdc: Update compatible strings
> > usb: bdc: Add compatible string for new style USB DT nodes
> > usb: bdc:
301 - 400 of 20878 matches
Mail list logo
