cted
>
> Memory state around the buggy address:
> 8881c9cf7480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> 8881c9cf7500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > 8881c9cf7580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>^
> 8881c9cf7600: fb
access that executes
after the marked access (as reflected in the ww-vis and wr-vis
relations).
With these changes, the LKMM gives the desired result for Herbert's
litmus test and other related ones.
Signed-off-by: Alan Stern
Reported-by: Herbert Xu
---
tools/memory-model
odel ought to know about these barriers.
This patch adds them into the memory model.
Signed-off-by: Alan Stern
---
tools/memory-model/linux-kernel.cat |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: usb-devel/tools/memory-model/linux-
.
This change should have no effect on the operation of the memory model.
Signed-off-by: Alan Stern
---
tools/memory-model/linux-kernel.cat | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
Index: usb-devel/tools/memory-model/linux-kernel.cat
Tejun and other workqueue maintainers:
On Tue, 18 Jun 2019, Oliver Neukum wrote:
> Am Dienstag, den 18.06.2019, 11:29 -0400 schrieb Alan Stern:
> > On Tue, 18 Jun 2019, Oliver Neukum wrote:
> >
> > > Hi,
> > >
> > > looking at those deadlocks
.urb_dequeue= vhci_urb_dequeue,
>
> .get_frame_number = vhci_get_frame_number,
> + .map_urb_for_dma = vhci_map_urb_for_dma,
>
> .hub_status_data = vhci_hub_status,
> .hub_control = vhci_hub_control,
If the goal is to avoid wasting CPU cycles, you probably should have a
vhci_unmap_urb_for_dma routine as well.
Alan Stern
On Tue, Jun 18, 2019 at 2:17 AM Greg Kroah-Hartman
wrote:
>
> On Sun, Jun 16, 2019 at 10:11:13PM -0500, Alan Tull wrote:
> > I'm moving on to a new position and stepping down as FPGA subsystem
> > maintainer. Moritz has graciously agreed to take over the
> > maintainer
* Some devices don't handle VPD pages correctly, so skip vpd
> + * pages if not forced by SCSI layer.
> + */
> + sdev->skip_vpd_pages = sdev->try_vpd_pages == 0;
>
> /* Do not attempt to use REPORT SUPPORTED OPERATION CODES *
On Sun, Jun 16, 2019 at 10:35 PM Moritz Fischer wrote:
Hi Moritz,
>
> Hi Alan,
>
> On Sun, Jun 16, 2019 at 10:11:13PM -0500, Alan Tull wrote:
> > I'm moving on to a new position and stepping down as FPGA subsystem
> > maintainer. Moritz has graciously agreed to take ove
I'm moving on to a new position and stepping down as FPGA subsystem
maintainer. Moritz has graciously agreed to take over the
maintainership.
Signed-off-by: Alan Tull
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 80e2bfa049d7..448730982545
the example should force the "*x =
1" store to execute before the "r0 = *y" load. But on current x86 it
doesn't force this, for the reason explained in the description.
Alan
t; [ 903.504475] ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue
> 14 failed to flush
Instead of reverting the original commit, can you prevent the problem
by adding local_irq_save() and local_irq_restore() to the URB
completion routines in that wireless driver?
Probably people who aren't already pretty familiar with the driver code
won't easily be able to locate the race. Still, a little overkill may
be an acceptable solution.
Alan Stern
capability,
> USBDEVFS_CAP_CONNINFO_EX, is introduced to help userspace in determining
> whether the kernel supports this new ioctl.
>
> Signed-off-by: Dmitry Torokhov
Acked-by: Alan Stern
On Sat, 8 Jun 2019, Paul E. McKenney wrote:
> On Thu, Jun 06, 2019 at 10:19:43AM -0400, Alan Stern wrote:
> > On Thu, 6 Jun 2019, Andrea Parri wrote:
> >
> > > This seems a sensible change to me: looking forward to seeing a patch,
> > > on top of -rcu/de
ce the RCU code and the informal doc
> will have settled in such direction).
Yes. Also for SRCU. That point had not escaped me.
Alan
ice_type usb_port_device_type = {
> >>>>> static struct device_driver usb_port_driver = {
> >>>>> .name = "usb",
> >>>>> .owner = THIS_MODULE,
> >>>>> + .shutdown = usb_port_shutdown,
> >>>>> }
in Linux
> + */
> + if (pdata->has_fsl_erratum_a006918) {
> + dev_warn(dev, "USB PHY clock invalid\n");
> + return -EINVAL;
> + }
> +
> case FSL_USB2_PHY_UTMI_DUAL:
This is bad. You g
t;%8x" to "%10d" in both cases.
major:minor is also more often seen formatted as "%d:%d": in
/proc/self/mountinfo, lsblk, and ls -l. I don't feel as strongly about
this one though.
Thanks
Alan
| \_ fs/cgroup 1a 10 t
On 28/05/2019 16:14, David Howells wrote:
+Then there are attributes that convey information about the mount topology:
+
+ * ``FSINFO_ATTR_MOUNT_INFO``
+
+This struct-type attribute conveys information about a mount topology node
+rather than a superblock. This includes the ID of the
On 28/05/2019 16:12, David Howells wrote:
Allow mount information, including information about the topology tree to
be queried with the fsinfo() system call. Usage of AT_FSINFO_MOUNTID_PATH
allows overlapping mounts to be queried.
To this end, four fsinfo() attributes are provided:
(1)
troy address
dependencies from volatile reads -- but we also warn that this
assumption may fail if the programmer does not follow some rules
described in one of Paul's documentation files.)
Alan
oes point out a weakness in the LKMM's handling of
data races. Herbert's litmus test is a great starting point:
C xu
{}
P0(int *a, int *b)
{
WRITE_ONCE(*a, 1);
synchronize_rcu();
*b = 2;
}
P1(int *a, int *b)
{
rcu_read_lock();
if (READ_ONCE(*a) == 0)
*b = 1;
rcu_read_unlock();
}
exists (~b=2)
Currently the LKMM says the test is allowed and there is a data race,
but this answer clearly is wrong since it would violate the RCU
guarantee.
The problem is that the LKMM currently requires all ordering/visibility
of plain accesses to be mediated by marked accesses. But in this case,
the visibility is mediated by RCU. Technically, we need to add a
relation like
([M] ; po ; rcu-fence ; po ; [M])
into the definitions of ww-vis, wr-vis, and rw-xbstar. Doing so
changes the litmus test's result to "not allowed" and no data race.
However, I'm not certain that this single change is the entire fix;
more thought is needed.
Alan
gt;> hardware assigns the address, and won't be the same as devnum.
> >>
> >> Here we have two patches.
> >> One is to add devaddr in struct usb_device for
> >> usb_hub_clear_tt_buffer() to use.
> >> Another is to invoke usb_hub_clear_tt_buffer() for halt processing.
> > Why did you resend patch series 11?
> Didn't get response in 2 or 3 days.
> Will be more patient next time.
>
> May I get patch v11 1/2 acked or reviewed by Alan?
Did I not do this already? Oh well, in any case:
Acked-by: Alan Stern
Alan Stern
On Sun, Jun 2, 2019 at 9:43 PM Kishon Vijay Abraham I wrote:
> Hi Alan,
> On 31/05/19 11:46 PM, Alan Mikhak wrote:
> > On Thu, May 30, 2019 at 10:08 PM Kishon Vijay Abraham I
> > wrote:
> >> Hi Alan,
> >>> Hi Kishon,
> >>
> >> I still hav
ll_bulk_urb() but the endpoint was actually interrupt. No doubt
this is related to the message a few lines above, about changing
endpoint 0x81 from Bulk to Interrupt. In any case, the driver should
check that the ep has the expected type before using it.
Alan Stern
> Kernel panic - not syn
On Thu, May 30, 2019 at 10:08 PM Kishon Vijay Abraham I wrote:
> Hi Alan,
> >
> > Hi Kishon,
> >
> > I have some improvements in mind for a v2 patch in response to
> > feedback from Gustavo Pimentel that the current implementation is HW
> > specific. I hesi
On Thu, May 30, 2019 at 9:37 PM Kishon Vijay Abraham I wrote:
>
> Hi Alan,
>
> On 25/05/19 12:20 AM, Alan Mikhak wrote:
> > Hi Kishon,
> >
> > Yes. This change is still applicable even when the platform specifies
> > that it only supports 64-bit BARs by se
nce counters, 'clock', 'cache', 'iommu' and 'fabric', user
> could read the performance counter via exposed sysfs interfaces.
> Please refer to sysfs doc for more details.
>
> Signed-off-by: Luwei Kang
> Signed-off-by: Xu Yilun
> Signed-off-by: Wu Hao
Acked-by: Alan Tull
On Wed, May 29, 2019 at 10:48 PM Kishon Vijay Abraham I wrote:
>
> +Vinod Koul
>
> Hi,
>
> >>> On Fri, May 24, 2019 at 1:59 AM Gustavo Pimentel
> >>> wrote:
> >>>>
> >>>> Hi Alan,
> >>>>
> >>>> T
Hi Greg,
Please take this FPGA fix. It have been reviewed on
the mailing list and applies cleanly on current
linux-next and char-misc-testing.
Thanks,
Alan
Moritz Fischer (1):
fpga: zynqmp-fpga: Correctly handle error pointer
drivers/fpga/zynqmp-fpga.c | 4 ++--
1 file changed, 2
not handle the EPROBE_DEFER value in a
special manner.
Fixes commit c09f7471127e ("fpga manager: Adding FPGA Manager support for
Xilinx zynqmp")
Reported-by: Dan Carpenter
Signed-off-by: Moritz Fischer
Acked-by: Alan Tull
---
drivers/fpga/zynqmp-fpga.c | 4 ++--
1 file changed, 2
On Mon, May 27, 2019 at 2:09 AM Gustavo Pimentel
wrote:
>
> On Fri, May 24, 2019 at 20:42:43, Alan Mikhak
> wrote:
>
> Hi Alan,
>
> > On Fri, May 24, 2019 at 1:59 AM Gustavo Pimentel
> > wrote:
> > >
> > > Hi Alan,
> > >
> >
a/0x4a0 drivers/staging/wlan-ng/prism2sta.c:471
> prism2sta_probe_usb.cold+0x1c8/0x49e
> drivers/staging/wlan-ng/prism2usb.c:112
The problem is that hfa384x_create() in hfa384x_usb.c assumes ep1-IN
and ep2-OUT exist and are bulk endpoints, without actually checking.
Since this function does not return an error code, it's not clear how
to respond when the expected endpoints do not exist.
Alan Stern
On Tue, 28 May 2019, Oliver Neukum wrote:
> Am Donnerstag, den 23.05.2019, 10:01 -0400 schrieb Alan Stern:
> > On Wed, 22 May 2019, Oliver Neukum wrote:
> >
> > > On Mi, 2019-05-22 at 10:56 -0400, Alan Stern wrote:
> > > > On Wed, 22 May 2019, Oliver Neuk
it refers only to
the driver. In fact, the line above is only a forward declaration --
the actual definition of p54u_driver was already in the source file.
Alan Stern
On Fri, May 24, 2019 at 1:59 AM Gustavo Pimentel
wrote:
>
> Hi Alan,
>
> This patch implementation is very HW implementation dependent and
> requires the DMA to exposed through PCIe BARs, which aren't always the
> case. Besides, you are defining some control bits on
> in
ing of PCI_BASE_ADDRESS_MEM_TYPE_64 in
epf_bar->flags to before the 'continue' statement to advance the 'bar'
loop index accordingly. The comment you see about 'pci_epc_set_bar()'
preceding the moved code is the original comment and was also moved
along with the code.
Regards,
Alan Mikhak
On Fri,
On Fri, 24 May 2019, Mauro Carvalho Chehab wrote:
> Em Tue, 7 May 2019 12:39:47 -0400 (EDT)
> Alan Stern escreveu:
>
> > The syzkaller USB fuzzer found a general-protection-fault bug in the
> > smsusb part of the Siano DVB driver. The fault occurs during probe
> >
+Bjorn Helgaas
On Thu, May 23, 2019 at 2:46 PM Alan Mikhak wrote:
>
> Set endpoint controller pointer to null in pci_epc_remove_epf()
> to avoid -EBUSY on subsequent call to pci_epc_add_epf().
>
> Requires checking for null endpoint function pointer.
>
> Signe
+Bjorn Helgaas, +Gustavo Pimentel, +Wen Yang, +Kangjie Lu
On Thu, May 23, 2019 at 2:48 PM Alan Mikhak wrote:
>
> PCI endpoint test function code should honor the .bar_fixed_size parameter
> from underlying endpoint controller drivers or results may be unexpected.
>
> In pci_epf_t
+Bjorn Helgaas, +Gustavo Pimentel, +Wen Yang, +Kangjie Lu
On Thu, May 23, 2019 at 2:55 PM Alan Mikhak wrote:
>
> Always skip odd bar when skipping 64bit BARs in pci_epf_test_set_bar()
> and pci_epf_test_alloc_space().
>
> Otherwise, pci_epf_test_set_bar() will call pci_epc_set_ba
+Bjorn Helgaas, +Gustavo Pimentel, +Wen Yang, +Kangjie Lu
On Thu, May 23, 2019 at 2:57 PM Alan Mikhak wrote:
>
> Associated pci_epf_bar structure is needed in pci_epc_clear_bar() but
> would be cleared in pci_epf_free_space(), if called first, and BAR
> would not get cleared.
&g
.
Signed-off-by: Alan Mikhak
---
drivers/misc/pci_endpoint_test.c| 72 +++-
drivers/pci/controller/dwc/pcie-designware-ep.c | 22 +++
drivers/pci/controller/dwc/pcie-designware.h| 13 ++
drivers/pci/endpoint/functions/pci-epf-test.c | 211 +++-
drivers/pci
Associated pci_epf_bar structure is needed in pci_epc_clear_bar() but
would be cleared in pci_epf_free_space(), if called first, and BAR
would not get cleared.
Signed-off-by: Alan Mikhak
---
drivers/pci/endpoint/functions/pci-epf-test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
for odd loop index when BAR is 64bit
but leaks on subsequent unbind by not calling pci_epf_free_space().
Signed-off-by: Alan Mikhak
Reviewed-by: Paul Walmsley
---
drivers/pci/endpoint/functions/pci-epf-test.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff
-off-by: Alan Mikhak
---
drivers/pci/endpoint/functions/pci-epf-test.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c
b/drivers/pci/endpoint/functions/pci-epf-test.c
index 27806987e93b..7d41e6684b87 100644
--- a/drivers/pci
Set endpoint controller pointer to null in pci_epc_remove_epf()
to avoid -EBUSY on subsequent call to pci_epc_add_epf().
Requires checking for null endpoint function pointer.
Signed-off-by: Alan Mikhak
---
drivers/pci/endpoint/pci-epc-core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion
ret : 1 - ret; /* return 0 if test succeeded */
pcitest.c: In function main:
pcitest.c:232:9: error: void value not ignored as it ought to be
return run_test(test);
Signed-off-by: Alan Mikhak
Fixes: fef31ecaaf2c ("tools: PCI: Fix compilation warnings")
Reviewed-by: Paul Walmsley
-
Fix the following compiler warning in pcitest:
pcitest.c: In function main:
pcitest.c:214:4: warning: too many arguments for
format [-Wformat-extra-args]
"usage: %s [options]\n"
Signed-off-by: Alan Mikhak
Fixes: fbca0b284bd0 ("tools: PCI: Add 'h' in optstring of getopt()"
This patchset fixes a compiler error and two warnings that resulted in a
broken compilation of pcitest.
tools/pci/pcitest.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
--
2.7.4
From: Alan Mikhak
Fixes: fbca0b284bd0 ("tools: PCI: Add 'h' in optstring of getopt()")
Fix the following compiler warning in pcitest:
pcitest.c: In function main:
pcitest.c:214:4: warning: too many arguments for
format [-Wformat-extra-args]
"usage: %s [options]\n"
From: Alan Mikhak
This patchset fixes a compiler error and two warnings that resulted in a
broken compilation of pcitest.
tools/pci/pcitest.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
--
2.7.4
From: Alan Mikhak
Fixes: fef31ecaaf2c ("tools: PCI: Fix compilation warnings")
pcitest is currently broken due to the following compiler error
and related warning. Fix by changing the run_test() function
signature to return an integer result.
pcitest.c: In function run_test:
pcite
like the 32bit sival_ptr.
>
> After a bunch of build BUG_ONs to verify my reasonable assumptions
> of but the siginfo layout are actually true, the code that generates
> the siginfo just copies a sigval_t to si_pid. And assumes the code
> in the usb stack placed the pointer in the proper part of the sigval_t
> when it read the information from userspace.
>
> I don't know if that helps make it easy to understand but I figured I
> would give it a shot.
I think I understand now. Thanks.
Alan
On Wed, 22 May 2019, Oliver Neukum wrote:
> On Mi, 2019-05-22 at 10:56 -0400, Alan Stern wrote:
> > On Wed, 22 May 2019, Oliver Neukum wrote:
> >
> > > I agree with the problem, but I fail to see why this issue would be
> > > specific to USB. Shouldn't this
(probably hopeless without seeing a diagram), the USB portions of the
patch look good and do what the patch description says.
Acked-by: Alan Stern
Alan Stern
the PME is signaled?
According to Kai, PME signalling doesn't work in D0 -- or at least, it
is _documented_ not to work in D0 -- even though it is enabled and the
device claims to support it.
In any case, I don't really see any point in "runtime suspending" a
device while leaving it in D0. We might as well just leave it alone.
Alan Stern
ocated are device managed?
Ah, I missed that fact. Okay, that's all right.
Alan Stern
On Wed, 22 May 2019, Oliver Neukum wrote:
> On Di, 2019-05-21 at 10:00 -0400, Alan Stern wrote:
> >
> > Changing configurations amounts to much the same as disconnecting,
> > because both operations destroy all the existing interfaces.
> >
> > Disconnec
rom [] (SyS_write+0x5c/0xbc)
[168374.817505] [] (SyS_write) from []
(ret_fast_syscall+0x0/0x1c)
[168374.825242] Code: e5943000 e592101c e351 0a06 (e5932034)
[168374.831584] ---[ end trace 91aec3f8a9835a40 ]---
Thanks
Al
On Tue, May 21, 2019 at 3:15 PM Kishon Vijay Abraham I wrote:
>
>
I'm seeing an issue on a system where I have a generic PHY that is
used by a USB XHCI driver. The XHCI driver does the phy_init() in
probe and the phy_exit() in remove. The problem happens when I use
sysfs to "unload" the PHY driver before doing an unload of the XHCI
driver. This is a result of
t necessary. The entire ohci_hcd structure is
initialized to 0 when it is first allocated.
> --- a/include/linux/usb/hcd.h
> +++ b/include/linux/usb/hcd.h
> @@ -216,6 +216,9 @@ struct usb_hcd {
> #define HC_IS_RUNNING(state) ((state) & __ACTIVE)
> #define HC_IS_SUSPENDED(state) ((state) & __SUSPEND)
>
> + /* allocator for HCs having local memory */
"allocator" is the wrong word -- an allocator is something that
allocates. Perhaps "memory area" or something along those lines.
Alan Stern
On Tue, 21 May 2019, Eric W. Biederman wrote:
> Alan Stern writes:
> >>req = (struct usb_ctrlrequest *) buf;
> >>req->bRequestType = USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_DEVICE;
> >>req->bRequest = USB_REQ_GET_DESCRIPTOR;
> >>
by byte copy of siginfo or a field by field copy of
> siginfo). The code also verifies that for a 64bit kernel and a 32bit
> userspace the 32bit pointer will fit in si_pid.
>
> I have used the usbsig.c program below written by Alan Stern and
> slightly tweaked by me to run on a big e
On Tue, 21 May 2019, Oliver Neukum wrote:
> On Mo, 2019-05-20 at 10:16 -0400, Alan Stern wrote:
> > On Mon, 20 May 2019, Christoph Hellwig wrote:
> >
> > > GFP_KERNEL if you can block, GFP_ATOMIC if you can't for a good reason,
> > > that is the allocation is fro
On Thu, May 16, 2019 at 11:27 PM Wu Hao wrote:
>
> On Thu, May 16, 2019 at 12:53:00PM -0500, Alan Tull wrote:
> > On Thu, May 16, 2019 at 12:36 PM Alan Tull wrote:
> > >
> > > On Mon, Apr 29, 2019 at 4:12 AM Wu Hao wrote:
> >
> > Hi Hao,
> >
>
ess, take a reference to the
USB interface instead of the USB device.
Don't take an unnecessary reference to the device during probe
(and then don't drop it during disconnect).
Signed-off-by: Alan Stern
Reported-and-tested-by: syzbot+200d4bb11b23d9
Reichl
> Suggested-by: Måns Rullgård
> Signed-off-by: Marek Szyprowski
> ---
> v5:
> - fixed error path handling as pointed by Alan
Acked-by: Alan Stern
This is assuming the whole approach makes sense in the first place --
I'll defer to other people's judgement on that.
Alan Stern
ver can handle only one I/O
operation at a time), and the current operation can't complete until
the old pages are swapped out. Result: deadlock.
Isn't that the whole reason for using GFP_NOIO in the first place?
Alan Stern
e/driver.c:584
> Read of size 8 at addr 88808fc31218 by task kworker/0:1/12
Now the bad access is in a different place. That's a good sign.
In this case it indicates that although udev is still hanging around,
intf has already been freed. We really should acquire a reference to
it instead.
On Sat, 18 May 2019, syzbot wrote:
> Hello,
>
> syzbot tried to test the proposed patch but build/boot failed:
One of these times I'll get it right...
Alan Stern
#syz test: https://github.com/google/kasan.git usb-fuzzer
drivers/net/wireless/intersil/p54/p54usb
On Thu, May 16, 2019 at 12:36 PM Alan Tull wrote:
>
> On Mon, Apr 29, 2019 at 4:12 AM Wu Hao wrote:
Hi Hao,
Most of this patchset looks ready to go upstream or nearly so with
pretty straightforward changes . Patches 17 and 18 need minor changes
and please change the scnprintf in the
ff-by: Wu Hao
Acked-by: Alan Tull
Thanks,
Alan
On Mon, Apr 29, 2019 at 4:12 AM Wu Hao wrote:
It looks like this addressed the review comments. Adding my Ack. Is
there anything else on this patch?
Alan
>
> In early partial reconfiguration private feature, it only
> supports 32bit data width when writing data to hardware for
>
On Mon, Apr 29, 2019 at 4:13 AM Wu Hao wrote:
Hi Hao,
>
> This patch adds support for performance reporting private feature
> for FPGA Management Engine (FME). Actually it supports 4 categories
> performance counters, 'clock', 'cache', 'iommu' and 'fabric', user
> could read the performance
> +static int rpmsg_tty_data_handler(struct rpmsg_device *rpdev, void *data,
> + int len, void *priv, u32 src)
> +{
> + struct rpmsg_tty_port *cport = dev_get_drvdata(>dev);
> + u8 *cbuf;
> + int space;
> +
> + dev_dbg(>dev, "msg(<- src 0x%x) len
r_tt_buffer() to use.
>
> Signed-off-by: Jim Lin
> ---
Aside from the "xhci:" part of the Subject line (it's not really
appropriate because this is a modification of the USB core more than of
the xhci-hcd driver),
Acked-by: Alan Stern
> v2: xhci_clear_tt_buffer_complete
==
> BUG: KASAN: slab-out-of-bounds in usb_get_bos_descriptor+0x8be/0x8fb
> drivers/usb/core/config.c:976
> Write of size 1 at addr 8880a48e38ec by task kworker/0:2/533
Insufficient descriptor size check.
Alan Stern
#syz test: https://github.com/google/kasan.git usb-fuzzer
drivers
* Cornelia Huck (coh...@redhat.com) wrote:
> On Thu, 9 May 2019 17:48:26 +0100
> "Dr. David Alan Gilbert" wrote:
>
> > * Cornelia Huck (coh...@redhat.com) wrote:
> > > On Thu, 9 May 2019 16:48:57 +0100
> > > "Dr. David Alan Gilbert" wrote
Acked-by: Alan Tull
---
drivers/fpga/dfl-afu-dma-region.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/fpga/dfl-afu-dma-region.c
b/drivers/fpga/dfl-afu-dma-region.c
index 0bbc7142f1dc..f7d268f45df0 100644
--- a/drivers/fpga/dfl-afu-dma-region.c
+++ b/drivers/fpga/dfl
nager driver")
Signed-off-by: Wen Yang
Cc: Alan Tull
Cc: Moritz Fischer
Cc: Nicolas Saenz Julienne
Cc: linux-f...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Moritz Fischer
Reviewed-by: Nicolas Saenz Julienne
Acked-by: Alan Tull
---
drivers/fpga/stratix10-soc.c | 6
Hi Greg,
Please take these four fpga fixes patches. They
have been reviewed on the mailing list and apply
cleanly on current linux-next and char-misc-testing.
Thanks,
Alan
Chengguang Xu (1):
fpga: dfl: expand minor range when registering chrdev region
Scott Wood (2):
fpga: dfl: afu: Pass
From: Chengguang Xu
Actually, total amount of available minor number
for a single major is MINORMASK + 1. So expand
minor range when registering chrdev region.
Signed-off-by: Chengguang Xu
Acked-by: Wu Hao
Acked-by: Alan Tull
---
drivers/fpga/dfl.c | 6 +++---
1 file changed, 3 insertions
ffe4cae0df0
[ 409.977115] R13: b680 R14: R15: 7ffe4cae0f60
Signed-off-by: Scott Wood
Acked-by: Wu Hao
Acked-by: Alan Tull
---
drivers/fpga/dfl.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/fpga/dfl.c b/drivers
* Cornelia Huck (coh...@redhat.com) wrote:
> On Thu, 9 May 2019 16:48:57 +0100
> "Dr. David Alan Gilbert" wrote:
>
> > * Cornelia Huck (coh...@redhat.com) wrote:
> > > On Tue, 7 May 2019 15:18:26 -0600
> > > Alex Williamson wrote:
> > >
&g
nterfaces to
> report different error detected by the hardware, and allow
> user to clear errors or inject error for testing purpose.
>
> Signed-off-by: Luwei Kang
> Signed-off-by: Ananda Ravuri
> Signed-off-by: Xu Yilun
> Signed-off-by: Wu Hao
Acked-by: Alan Tull
> ---
&g
>
> Signed-off-by: Xu Yilun
> Signed-off-by: Wu Hao
Acked-by: Alan Tull
Thanks!
Alan
> ---
> v2: add more error code description for error clear sysfs in doc.
> return -EINVAL instead of -EBUSY when input error code doesn't
> match in error clear sysfs.
>
one to
introduce the new field and one to implement Clear-TT-Buffer for xHCI.
Furthermore, update_devnum() in hub.c should do:
if (udev->devaddr == 0)
udev->devaddr = devnum;
Then the code usb_hub_clear_tt_buffer() can just use devaddr without
needing to check the HCD type.
Alan Stern
octl.
> >
> > Signed-off-by: Xu Yilun
> > Signed-off-by: Wu Hao
> Acked-by: Moritz Fischer
Acked-by: Alan Tull
Alan
> > ---
> > v2: clean up code split from patch 2 in v1 patchset.
> > ---
> > drivers/fpga/dfl-fme-pr.c | 3 ---
> > 1 file chang
; 1. removed 32 common part of version string
> (Alex Williamson)
> 2. do not register version attribute for GVT not supporting live
> migration.(Cornelia Huck)
> 3. for platforms out of gen8, gen9, return -EINVAL --> -ENODEV for
> incompatible. (Cornelia Huck)
>
> Cc: Alex Williamso
()
> error: 'eemi_ops' dereferencing possible ERR_PTR()
>
> Note: This does not handle the EPROBE_DEFER value in a
> special manner.
>
> Fixes commit c09f7471127e ("fpga manager: Adding FPGA Manager support for
> Xilinx zynqmp")
> Reported-by: Dan Carpenter
> Si
ger *mgr,
> char *kbuf;
> int ret;
>
> - if (!eemi_ops || !eemi_ops->fpga_load)
> + if (IS_ERR_OR_NULL(eemi_ops) || !eemi_ops->fpga_load)
This if statement also happens in fpga_mgr_states
zynqmp_fpga_ops_state(), so we'll need this fix there also.
> return -ENXIO;
>
> priv = mgr->priv;
> --
> 2.21.0
>
Alan
On Mon, Apr 29, 2019 at 4:13 AM Wu Hao wrote:
+ The hwmon people
>
> This patch adds support to thermal management private feature for DFL
> FPGA Management Engine (FME). This private feature driver registers
> a hwmon for thermal/temperature monitoring (hwmon temp1_input).
> If hardware
On Mon, Apr 29, 2019 at 4:13 AM Wu Hao wrote:
+ hwmon folks
>
> This patch adds support for power management private feature under
> FPGA Management Engine (FME). This private feature driver registers
> a hwmon for power (power1_input), thresholds information, e.g.
> (power1_cap / crit) and
initialization code, we can make
the appropriate checks early on and thus avoid the problem. If the
expected endpoints aren't present, the new code safely returns -ENODEV
from the probe routine.
Signed-off-by: Alan Stern
Reported-and-tested-by: syzbot+53f029db71c19a473...@syzkaller.appspotmail.com
CC
On Tue, 7 May 2019, Mathias Nyman wrote:
> On 6.5.2019 17.57, Alan Stern wrote:
> > On Mon, 6 May 2019, Jim Lin wrote:
> >
> >> USB 2.0 specification chapter 11.17.5 says "as part of endpoint halt
> >> processing for full-/low-speed endpoints connected via
to explain how these barriers differ from a RELEASE or
ACQUIRE ordering.
Signed-off-by: Alan Stern
CC: Peter Zijlstra
---
v2: Update the explanation: These barriers do provide order for
accesses on the far side of the atomic RMW operation.
Documentation/atomic_t.txt | 17
On Fri, 3 May 2019, Peter Zijlstra wrote:
> On Fri, May 03, 2019 at 12:19:21PM -0400, Alan Stern wrote:
> > On Fri, 3 May 2019, Peter Zijlstra wrote:
> >
> > > On Fri, May 03, 2019 at 07:53:26AM -0700, Paul E. McKenney wrote:
> > > > Hello, Alan,
> >
On Fri, 3 May 2019, Peter Zijlstra wrote:
> On Fri, May 03, 2019 at 07:53:26AM -0700, Paul E. McKenney wrote:
> > Hello, Alan,
> >
> > Just following up on the -rcu commit below. I believe that it needs
> > some adjustment given Peter Zijlstra's addition of "
about...". What is the question?
Also, given that your question concerns what happens when you write to
/sys/bus/pci/..., perhaps you should consider mailing it to some PCI
maintainers as well as to the USB maintainers.
Perhaps the reset was not meant to be used the way you are doing it.
A more conservative approach would be to unbind xhci-hcd from the
device before doing the reset and then rebind it afterward.
Alan Stern
701 - 800 of 20878 matches
Mail list logo
