RE: [PATCH] bfa: remove VLA

> > - sizeof(wwn_t[iocmd->nports])) != BFA_STATUS_OK) { > > + sizeof(wwn_t) * iocmd->nports) != BFA_STATUS_OK) { > > These parentheses made me blurry eyed but it's actually OK. iocmd->nports * sizeof(wwn_t)) != BFA_STATUS_OK) { is easier to focus on :-)

RE: [PATCH] scsi: resolve COMMAND_SIZE at compile time

From: Stephen Kitt > Sent: 09 March 2018 22:34 > > COMMAND_SIZE currently uses an array of values in block/scsi_ioctl.c. > A number of device_handler functions use this to initialise arrays, > and this is flagged by -Wvla. > > This patch replaces COMMAND_SIZE with a variant using a formula which

RE: [PATCH] scsi: lpfc: use memcpy_toio instead of writeq

From: Andy Shevchenko > Sent: 23 February 2018 17:13 > To: David Laight > Cc: Arnd Bergmann; James Smart; Dick Kennedy; James E.J. Bottomley; Martin K. > Petersen; Hannes > Reinecke; Johannes Thumshirn; linux-scsi@vger.kernel.org; > linux-ker...@vger.kernel.org > Subject: R

RE: [PATCH] scsi: lpfc: use memcpy_toio instead of writeq

From: Andy Shevchenko > Sent: 23 February 2018 16:51 > On Fri, Feb 23, 2018 at 6:41 PM, David Laight <david.lai...@aculab.com> wrote: > > From: Arnd Bergmann > >> Sent: 23 February 2018 15:37 > >> > >> 32-bit architectures generally cannot use

RE: [PATCH] scsi: lpfc: use memcpy_toio instead of writeq

From: Arnd Bergmann > Sent: 23 February 2018 15:37 > > 32-bit architectures generally cannot use writeq(), so we now get a build > failure for the lpfc driver: > > drivers/scsi/lpfc/lpfc_sli.c: In function 'lpfc_sli4_wq_put': > drivers/scsi/lpfc/lpfc_sli.c:145:4: error: implicit declaration of

RE: [PATCH 04/22] scsi: fusion: fix string overflow warning

From: Arnd Bergmann > Sent: 14 July 2017 13:07 > gcc points out a theorerical string overflow: > > drivers/message/fusion/mptbase.c: In function 'mpt_detach': > drivers/message/fusion/mptbase.c:2103:17: error: '%s' directive writing up to > 31 bytes into a region > of size 28

RE: remove dma_alloc_noncoherent

From: Christoph Hellwig > Sent: 16 June 2017 08:17 > > For many years we've had the dma_alloc_attrs API that is more flexible > than dma_alloc_noncoherent. This series moves the remaining users over > to the attrs API. And most of the callers probably only want to specify 'noncoherent'. Grepping

RE: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

From: Logan Gunthorpe > Sent: 13 April 2017 23:05 > Straightforward conversion to the new helper, except due to > the lack of error path, we have to warn if unmapable memory > is ever present in the sgl. > > Signed-off-by: Logan Gunthorpe > --- >

RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] > Sent: 28 September 2015 15:27 > On Mon, 2015-09-28 at 08:58 +, David Laight wrote: > > From: Rafael J. Wysocki > > > Sent: 27 September 2015 15:09 > > ... > > > > > Say you have thr

RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

From: James Bottomley > Sent: 28 September 2015 16:12 > > > > The x86 cpus will also do 32bit wide rmw cycles for the 'bit' > > > > operations. > > > > > > That's different: it's an atomic RMW operation. The problem with the > > > alpha was that the operation wasn't atomic (meaning that it

RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

From: Rafael J. Wysocki > Sent: 27 September 2015 15:09 ... > > > Say you have three adjacent fields in a structure, x, y, z, each one byte > > > long. > > > Initially, all of them are equal to 0. > > > > > > CPU A writes 1 to x and CPU B writes 2 to y at the same time. > > > > > > What's the

RE: [PATCH v2 12/30] cxlflash: Refine host/device attributes

From: Brian King > Sent: 18 September 2015 22:35 ... > > + for (i = 0; i < CXLFLASH_NUM_VLUNS; i++, buf += 22) > > Rather than this bug prone hard coded 22, how about never incrementing buf > and do something > similar to this: > > > + bytes += scnprintf(buf, PAGE_SIZE, "%03d:

RE: [PATCH v2 09/30] cxlflash: Fix to stop interrupt processing on remove

From: Linuxppc-dev Matthew R. Ochs > Sent: 16 September 2015 22:28 > Interrupt processing can run in parallel to a remove operation. This > can lead to a condition where the interrupt handler is processing with > memory that has been freed. > > To avoid processing an interrupt while memory may be

RE: [PATCH] USB: storage: add no SYNCHRONIZE CACHE quirk

From: Of James Bottomley Sent: 22 June 2015 18:36 To: Alan Stern ... Obviously, for a disk with a writeback cache that can't do flush, that window is much wider and the real solution should be to try to switch the cache to write through. I agree. Doing the switch manually (by

RE: Large disk drives

From: Norman Diamond ... By the way, I've seen some USB bridges that lie about whether they performed various SAT commands (ATA passthrough), but told the truth about performing an ATA IDENTIFY DEVICE through SAT.  So we could attempt ATA passthrough with an IDENTIFY DEVICE command, and if it

RE: [PATCH fix for 3.17] uas: Add a quirk for rejecting ATA_12 and ATA_16 commands

From: Alan Stern ... p = quirks; while (*p) { @@ -543,6 +544,9 @@ void usb_stor_adjust_quirks(struct usb_device *udev, unsigned long *fflags) case 's': f |= US_FL_SINGLE_LUN; break; + case 't': +

RE: RES: RES: AS2105-based enclosure size issues with 2TB HDDs

From: Alan Stern On Mon, 25 Aug 2014, Alfredo Dal Ava Junior wrote: Well, it is causing problems anyway... from user perspective, it's a Linux compatibility issue, as it works fine on Windows. I'm not an expert, but I'm wondering that if usb-storage could set capacity as UNDETERMINED/

RE: RES: RES: AS2105-based enclosure size issues with 2TB HDDs

From Oliver Neukum [mailto:oneu...@suse.de] On Tue, 2014-08-26 at 09:58 +, David Laight wrote: Part of the problem is that usb-storage has no way to know that anything strange is going on. It's normal for READ CAPACITY(16) to fail (this depend on the SCSI level), and it's normal

RE: dummy scsi read or scsi command periodically for external USB Hard Disk

From: loody ... but what it really do is read sector, not media_change or test_unit_ready. Maybe one of the programs that reads the mbr partition table can be persuaded to do a direct read? David

RE: dummy scsi read or scsi command periodically for external USB Hard Disk

From: Lars Melin ... sgread is not included in BusyBox but you should have touch. Create a dummy file on the disk and let cron touch it every 4 minutes. You don't need 'touch' a shell redirect eg : file will do open(..., O_CREAT|O_TRUNC). However that still might not force an actual disc

RE: [PATCH 0/10] use safer test on the result of find_first_zero_bit

From: Julia Lawall On Wed, 4 Jun 2014, Geert Uytterhoeven wrote: Hi Julia, On Wed, Jun 4, 2014 at 11:07 AM, Julia Lawall julia.law...@lip6.fr wrote: Find_first_zero_bit considers BITS_PER_LONG bits at a time, and thus may return a larger number than the maximum position argument if

RE: [PATCH 0/10] use safer test on the result of find_first_zero_bit

From: Julia Lawall On Wed, 4 Jun 2014, Geert Uytterhoeven wrote: Hi Julia, On Wed, Jun 4, 2014 at 1:00 PM, Julia Lawall julia.law...@lip6.fr wrote: OK, thanks. I was only looking at the C code. But the C code contains a loop that is followed by: if (!size)

RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst [NEW HARDWARE]

From: walt On 01/21/2014 01:51 AM, David Laight wrote: From: Sarah Sharp On Mon, Jan 20, 2014 at 11:21:14AM +, David Laight wrote: ... A guess... In queue_bulk_sg_tx() try calling xhci_v1_0_td_remainder() instead of xhci_td_remainder(). David, I tried the one-liner below

RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst [NEW HARDWARE]

From: Sarah Sharp On Mon, Jan 20, 2014 at 11:21:14AM +, David Laight wrote: ... A guess... In queue_bulk_sg_tx() try calling xhci_v1_0_td_remainder() instead of xhci_td_remainder(). Why? Walt has a 0.96 xHCI host controller, and the format for how to calculate the TD remainder

RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst [NEW HARDWARE]

From: On 01/17/2014 06:34 AM, David Laight wrote: Can you try the patch I posted that stops the ownership on LINK TRBs being changed before that on the linked-to TRB? Sadly, the patch didn't fix the ASMedia lockup behavior, however :( I did notice that the lockup occurred only when

RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst [NEW HARDWARE]

From: walt On 01/17/2014 06:34 AM, David Laight wrote: Can you try the patch I posted that stops the ownership on LINK TRBs being changed before that on the linked-to TRB? Please disregard my earlier post about the patch not applying cleanly. That was the usual html corruption, so I

RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst [NEW HARDWARE]

From: walt Oy, Sarah! ;) I put the ASMedia adapter in my older amd64 machine, and, well, the stupid thing Just Works(TM) with kernel 3.12.7! (Yes, with the same disk docking station, too.) I can't believe the adapter works perfectly in a different computer. Have you seen this kind of

RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst [NEW HARDWARE]

From: walt On 01/09/2014 03:50 PM, Sarah Sharp wrote: On Tue, Jan 07, 2014 at 03:57:00PM -0800, walt wrote: I've wondered if my xhci problems might be caused by hardware quirks, and wondering why I seem to be the only one who has this problem. Maybe I could take one for the team by

RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst

From: walt In the meantime, try this patch, which is something of a long shot. No difference. But I notice the code enables the TRB quirk only if the xhci_version is specifically 0x95. My debug messages claim that xHCI doesn't need link TRB QUIRK so I'm wondering if adding my asmedia

RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst

From: walt ... I'm still wondering if I'm suffering from hardware quirks. From the first day I installed my usb3 adapter card and the usb3 disk docking station I've noticed some quirky behavior. Ah - this isn't an 'on chip' usb3 adapter. Some kind of PCIe card ? e.g. I boot the machine

RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst

From: Sarah Sharp On Tue, Jan 07, 2014 at 03:57:00PM -0800, walt wrote: On 01/07/2014 01:21 PM, Sarah Sharp wrote: Can you please try the attached patch, on top of the previous three patches, and send me dmesg? Hi Sarah, I just now finished running 0001-More-debugging.patch for the

RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst

From: Alan Stern This may be a foolish question, but why is xhci-hcd using no-op TRBs in the first place? Because it can't write in a link TRB because other parts of the code use link TRBs to detect the end of the ring. The problem is that it can't put a link TRB in the middle of a chain of

RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst

From: Alan Stern On Wed, 8 Jan 2014, David Laight wrote: From: Alan Stern This may be a foolish question, but why is xhci-hcd using no-op TRBs in the first place? Because it can't write in a link TRB because other parts of the code use link TRBs to detect the end of the ring

RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst

From: walt ... Thanks Sarah. dmesg0 is from the diagnostic patch only. dmesg1 has all three patches applied. Some of the messages in dmesg1 fell off the end of the kernel buffer, so I may need to make the buffer larger next time but I'll need a reminder of how to do it. As you

RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst

The dmesg contains: [ 538.728064] EXT4-fs warning (device dm-0): ext4_end_bio:316: I/O error writing to inode 23330865 (offset 0 size 8388608 starting block 812628) An 8MB transfer will need at least 128 ring entries (TRB) even if the request is a single contiguous memory block. Are you using

RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst

From: walt ... /* Accept arbitrarily long scatter-gather lists */ - hcd-self.sg_tablesize = ~0; + hcd-self.sg_tablesize = 31; Even if that reduces the number of fragments passed to the xhci driver it may not be enough to limit the actual number of fragments that need to be

RE: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern

It seems to me that a more useful interface would take a minimum and maximum number of vectors from the driver. This wouldn't allow the driver to specify that it could only accept, say, any even number within a certain range, but you could still leave the current functions available for

RE: [PATCH v2 net-next 05/22] cxgb4: Add T5 write combining support

This patch implements a low latency Write Combining (aka Write Coalescing) work request path. PCIE maps User Space Doorbell BAR2 region writes to the new interface to SGE. SGE pulls a new message from PCIE new interface and if its a coalesced write work request then pushes it for processing.

RE: [PATCH net-next 05/22] cxgb4: Add T5 write combining support

+ writel(n, adap-bar2 + q-udb + 8); +#if defined(CONFIG_X86_32) || defined(CONFIG_X86_64) + asm volatile(sfence : : : memory); +#endif There is absolutely no way I'm letting anyone put crap like this into a driver. Use a portable inteface,