Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

Do you think that the appropriate patches could be copied to the appropriate people please? On Thu, Jan 11, 2018 at 04:46:24PM -0800, Dan Williams wrote: > Changes since v1 [1]: > * fixup the ifence definition to use alternative_2 per recent AMD > changes in tip/x86/pti (Tom) > > * drop

Re: [PATCH v3 07/12] scsi/ncr5380: Store IO ports and addresses in host private data

On Mon, Oct 10, 2016 at 12:46:53AM -0400, Finn Thain wrote: > The various 5380 drivers inconsistently store register pointers > either in the Scsi_Host struct "legacy crap" area or in special, > board-specific members of the NCR5380_hostdata struct. Uniform > use of the latter struct makes for

Re: [PATCH v3 08/12] scsi/ncr5380: Use correct types for device register accessors

On Mon, Oct 10, 2016 at 12:46:53AM -0400, Finn Thain wrote: > For timeout values adopt unsigned long, which is the type of jiffies etc. > > For chip register values and bit masks pass u8, which is the return type > of readb, inb etc. > > For device register offsets adopt unsigned int, as it is

Re: [PATCH v3 02/12] scsi/cumana_1: Remove unused cumanascsi_setup() function

On Mon, Oct 10, 2016 at 12:46:52AM -0400, Finn Thain wrote: > Signed-off-by: Finn Thain > Reviewed-by: Hannes Reinecke Thanks. Acked-by: Russell King -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/

Re: [PATCH v3 10/12] scsi/ncr5380: Expedite register polling

On Mon, Oct 10, 2016 at 12:46:53AM -0400, Finn Thain wrote: > Avoid the call to NCR5380_poll_politely2() when possible. The call is > easily short-circuited on the PIO fast path, using the inline wrapper. > This requires that the NCR5380_read macro be made available before > any #include

Re: [PATCH v3 11/12] scsi/ncr5380: Use correct types for DMA routines

On Mon, Oct 10, 2016 at 12:46:53AM -0400, Finn Thain wrote: > Apply prototypes to get consistent function signatures for the DMA > functions implemented in the board-specific drivers. To avoid using > macros to alter actual parameters, some of those functions are reworked > slightly. > > This is

Re: [PATCH, resend] scsi: advansys: fix big-endian builds

On Mon, Nov 16, 2015 at 05:49:23PM +0100, Arnd Bergmann wrote: > It turns out that the commit that introduced this used the cpu_to_le32() > incorrectly on an 8-bit field, which results in the sense_len to always > be set to zero, as the SCSI_SENSE_BUFFERSIZE value gets moved to upper > byte of the

Re: [PATCH v1] ata: ahci_xgene: Add AHCI Support for second generation of APM X-Gene SoC

On Wed, Apr 01, 2015 at 12:31:16PM -0400, Tejun Heo wrote: On Wed, Apr 01, 2015 at 12:13:36PM -0400, Tejun Heo wrote: Signed-off-by : Suman Tripathi stripa...@apm.com Applied to libata/for-4.1 w/ minor edit. Reverted due to build failure from missing asm/cputype.h. I'm guessing this

Re: [PATCH v1] ata: ahci_xgene: Add AHCI Support for second generation of APM X-Gene SoC

On Wed, Apr 01, 2015 at 06:00:33PM +0100, Catalin Marinas wrote: On Wed, Apr 01, 2015 at 05:39:56PM +0100, Russell King - ARM Linux wrote: On Wed, Apr 01, 2015 at 12:31:16PM -0400, Tejun Heo wrote: On Wed, Apr 01, 2015 at 12:13:36PM -0400, Tejun Heo wrote: Signed-off-by : Suman Tripathi

Re: [PATCH] scsi: arm: cumana_1.c: Remove unused function

On Sat, Dec 20, 2014 at 08:50:45AM -0800, Jeremiah Mahler wrote: On Sat, Dec 20, 2014 at 05:36:15PM +0100, Rickard Strandqvist wrote: Remove the function cumanascsi_setup() that is not used anywhere. This was partially found by using a static code analysis program called cppcheck.

Re: [PATCH] scsi: arm: cumana_1.c: Remove unused function

On Sat, Dec 20, 2014 at 09:35:53AM -0800, James Bottomley wrote: On Sat, 2014-12-20 at 16:58 +, Russell King - ARM Linux wrote: On Sat, Dec 20, 2014 at 08:50:45AM -0800, Jeremiah Mahler wrote: On Sat, Dec 20, 2014 at 05:36:15PM +0100, Rickard Strandqvist wrote: Remove the function

Re: [PATCH] ahci_xgene: Fix the error print invalid resource for APM X-Gene SoC AHCI SATA Host Controller driver.

On Mon, Sep 15, 2014 at 04:44:52PM +0900, Tejun Heo wrote: On Mon, Sep 15, 2014 at 01:10:01PM +0530, Suman Tripathi wrote: [suman] : So the posted version is acceptable ? Any others comments on this patch ? I'm suggesting setting ctx-cs_mux to NULL on failure. IOW, if (res) {

Re: [PATCH] acornscsi: remove linked command support

On Wed, May 28, 2014 at 06:26:44PM +0400, James Bottomley wrote: On Wed, 2014-05-28 at 03:41 -0700, Christoph Hellwig wrote: Looks good, Reviewed-by: Christoph Hellwig h...@lst.de And I have to disagree with James here, removing code that isn't even compiled always is an

Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig

On Sat, Mar 22, 2014 at 03:59:11PM -0700, James Bottomley wrote: On Sat, 2014-03-22 at 22:52 +, Russell King - ARM Linux wrote: And I'm disagreeing with that statement which implies that it's something that is an architecture wide property for any particular architecture. Right now

Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig

On Sat, Mar 22, 2014 at 02:31:21PM -0700, James Bottomley wrote: Perhaps now might be the time to ask which are the remaining architectures that cannot do SG chaining and then we can fix them and pull the whole thing out. Not quite. You're making the assumption that we can be sure that all

Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig

On Sat, Mar 22, 2014 at 03:37:40PM -0700, James Bottomley wrote: On Sat, 2014-03-22 at 22:23 +, Russell King - ARM Linux wrote: On Sat, Mar 22, 2014 at 02:31:21PM -0700, James Bottomley wrote: Perhaps now might be the time to ask which are the remaining architectures that cannot do SG

Re: [GIT PULL] ARM fixes

On Tue, Feb 18, 2014 at 03:49:03PM -0800, Linus Torvalds wrote: On Mon, Feb 17, 2014 at 3:46 PM, Russell King r...@arm.linux.org.uk wrote: One fix touches code outside of arch/arm, which is related to sorting out the DMA masks correctly. There is a long standing issue with the conversion

Re: [PATCH] Fix uses of dma_max_pfn() when converting to a limiting address

On Thu, Feb 13, 2014 at 08:01:12PM +, Russell King - ARM Linux wrote: On Thu, Feb 13, 2014 at 10:07:01AM -0800, James Bottomley wrote: On Thu, 2014-02-13 at 17:11 +, Russell King - ARM Linux wrote: On Thu, Feb 13, 2014 at 08:58:10AM -0800, James Bottomley wrote: This doesn't

Re: [PATCH] Fix uses of dma_max_pfn() when converting to a limiting address

On Thu, Feb 13, 2014 at 08:58:10AM -0800, James Bottomley wrote: This doesn't really look like the right fix. You replaced dev-dma_mask with a calculation on dev_max_pfn(). Since dev-dma_mask is always u64 and dev_max_pfn is supposed to be returning the pfn of the dma_mask, it should

Re: [PATCH] Fix uses of dma_max_pfn() when converting to a limiting address

On Thu, Feb 13, 2014 at 10:07:01AM -0800, James Bottomley wrote: On Thu, 2014-02-13 at 17:11 +, Russell King - ARM Linux wrote: On Thu, Feb 13, 2014 at 08:58:10AM -0800, James Bottomley wrote: This doesn't really look like the right fix. You replaced dev-dma_mask with a calculation

Re: [PATCH 19/51] DMA-API: media: dt3155v4l: replace dma_set_mask()+dma_set_coherent_mask() with new helper

On Thu, Oct 31, 2013 at 09:46:40AM -0200, Mauro Carvalho Chehab wrote: Hi Russell, Em Mon, 30 Sep 2013 13:57:47 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On 09/19/2013 11:44 PM, Russell King wrote: Replace the following sequence: dma_set_mask(dev, mask);

Re: [PATCH 00/51] DMA mask changes

On Thu, Sep 26, 2013 at 10:23:08PM +0200, Rafał Miłecki wrote: 2013/9/19 Russell King - ARM Linux li...@arm.linux.org.uk: This email is only being sent to the mailing lists in question, not to anyone personally. The list of individuals is far to great to do that. I'm hoping no mailing

Re: [alsa-devel] [PATCH 43/51] DMA-API: dma: edma.c: no need to explicitly initialize DMA masks

On Mon, Sep 23, 2013 at 03:55:33PM +0530, Vinod Koul wrote: On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote: register_platform_device_full() can setup the DMA mask provided the appropriate member is set in struct platform_device_info. So lets make that be the case. This

Re: [PATCH 36/51] DMA-API: usb: use dma_set_coherent_mask()

On Mon, Sep 23, 2013 at 02:27:39PM -0400, Alan Stern wrote: On Thu, 19 Sep 2013, Russell King wrote: The correct way for a driver to specify the coherent DMA mask is not to directly access the field in the struct device, but to use dma_set_coherent_mask(). Only arch and bus code should

Re: [PATCH 24/51] DMA-API: dma: pl330: add dma_set_mask_and_coherent() call

On Fri, Sep 20, 2013 at 07:26:27PM +0200, Heiko Stübner wrote: Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King: The DMA API requires drivers to call the appropriate dma_set_mask() functions before doing any DMA mapping. Add this required call to the AMBA PL08x driver.

Re: [PATCH 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing with dma masks

On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote: Hi, On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote: Use platform_device_register_full() for those drivers which can, to avoid messing directly with DMA masks. This can only be done when the driver does not need

Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()

On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote: On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote: The correct way for a driver to specify the coherent DMA mask is not to directly access the field in the struct device, but to use dma_set_coherent_mask(). Only arch and

Re: [PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks

On Fri, Sep 20, 2013 at 02:21:37AM +0100, Ben Hutchings wrote: On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote: [...] -dma_set_coherent_mask() will always be able to set the same or a -smaller mask as dma_set_mask(). However for the rare case that a +The coherent coherent mask will

[PATCH 00/51] DMA mask changes

This started out as a request to look at the DMA mask situation, and how to solve the issues which we have on ARM - notably how the DMA mask should be setup. However, I started off reviewing how the dma_mask and coherent_dma_mask was being used, and what I found was rather messy, and in some

Re: [PATCH 1/2] ufs-pltfrm: initialize DMA mask for device-tree probed device

On Wed, Aug 21, 2013 at 12:03:50AM +0900, Akinobu Mita wrote: The discussion in that thread is useful. Also, I found that Russell King proposed replacing the boilerplate by using dma_coerce_mask_and_coherent() in his patch set Preview of DMA mask changes.

Re: [PATCH RFC 00/51] Preview of DMA mask changes

On Thu, Aug 01, 2013 at 10:34:20PM +0100, Russell King - ARM Linux wrote: So, this patch set is a preview of the DMA mask changes which I currently have in my tree. Looking at the comments which this patch set has received, I see very little in the way of feedback. So I think it's time to move

[PATCH RFC 00/51] Preview of DMA mask changes

So, this patch set is a preview of the DMA mask changes which I currently have in my tree. This started out as a request to look at the DMA mask situation, and how to solve the issues which we have on ARM. One of those issues is how to deal with the DT side of things, which I haven't yet

Re: [RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes

On Fri, Jul 26, 2013 at 12:28:26PM -0400, Santosh Shilimkar wrote: On Friday 26 July 2013 11:10 AM, Russell King - ARM Linux wrote: On Fri, Jul 12, 2013 at 05:48:09PM -0400, Santosh Shilimkar wrote: The series is an attempt to move ARM port to NO_BOOTMEM. As discussed on list NO_BOOTMEM

Re: [RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes

On Mon, Jul 29, 2013 at 09:26:44AM -0400, Santosh Shilimkar wrote: On Monday 29 July 2013 07:15 AM, Russell King - ARM Linux wrote: Would you mind putting them all in the patch system, I can add the acks should anyone supply them later, and I'll repost them along with my set of dma-mask

Re: [RFC/RFT PATCH 0/5] mm: ARM nobootmem and few dma_mask fixes

On Fri, Jul 12, 2013 at 05:48:09PM -0400, Santosh Shilimkar wrote: The series is an attempt to move ARM port to NO_BOOTMEM. As discussed on list NO_BOOTMEM move needed updates to max*pfn meaning to be maximum PFNs but that breaks the dma_mask for few block layer drivers since ARM start of

Re: [RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations

On Sat, Jul 13, 2013 at 01:55:58AM +0400, Sergei Shtylyov wrote: Hello. On 07/13/2013 01:48 AM, Santosh Shilimkar wrote: DMA bounce limit is the maximum direct DMA'able memory beyond which bounce buffers has to be used to perform dma operations. SCSI driver relies on dma_mask but its

Re: [RFC/RFT PATCH 3/5] scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations

On Sat, Jul 13, 2013 at 03:42:55AM +0400, Sergei Shtylyov wrote: diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index 86d5220..e8275fa 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -1668,7 +1668,7 @@ u64 scsi_calculate_bounce_limit(struct Scsi_Host

Re: [PATCH v2 1/1] block: blk-merge: don't merge the pages with non-contiguous descriptors

On Thu, Jan 17, 2013 at 09:11:20AM +, James Bottomley wrote: On Wed, 2013-01-16 at 15:18 -0800, Tejun Heo wrote: On Wed, Jan 16, 2013 at 10:32:35AM +, James Bottomley wrote: diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c index 6b2fb87..ab88c5b 100644 ---

Re: [PATCH v2 1/1] block: blk-merge: don't merge the pages with non-contiguous descriptors

On Thu, Jan 17, 2013 at 10:37:42AM +, Russell King - ARM Linux wrote: On Thu, Jan 17, 2013 at 09:11:20AM +, James Bottomley wrote: I'd actually prefer page = pfn_to_page(page_to_pfn(page) + 1); because it makes the code look like the hack it is. The preferred form for all iterators

Re: [PATCH v2 1/1] block: blk-merge: don't merge the pages with non-contiguous descriptors

On Thu, Jan 17, 2013 at 11:01:47AM +, James Bottomley wrote: On Thu, 2013-01-17 at 10:47 +, Russell King - ARM Linux wrote: Also, couldn't the addition of the scatterlist offset to the page also be buggy too? No, fortunately, offset must be within the first page from the point

Re: [PATCH v2 1/1] block: blk-merge: don't merge the pages with non-contiguous descriptors

On Thu, Jan 17, 2013 at 11:19:21AM +, James Bottomley wrote: On Thu, 2013-01-17 at 11:04 +, Russell King - ARM Linux wrote: On Thu, Jan 17, 2013 at 11:01:47AM +, James Bottomley wrote: On Thu, 2013-01-17 at 10:47 +, Russell King - ARM Linux wrote: Also, couldn't

Re: [PATCH v2 1/1] block: blk-merge: don't merge the pages with non-contiguous descriptors

On Wed, Jan 16, 2013 at 10:32:35AM +, James Bottomley wrote: On Wed, 2013-01-16 at 12:07 +0530, Subhash Jadavani wrote: Now consider this call stack from MMC block driver (this is on the ARmv7 based board): [ 98.918174] [c001b50c] (v7_dma_inv_range+0x30/0x48) from

Re: [PATCH 097/493] scsi: remove use of __devexit_p

On Mon, Nov 19, 2012 at 01:20:46PM -0500, Bill Pemberton wrote: drivers/scsi/arm/acornscsi.c | 2 +- drivers/scsi/arm/arxescsi.c | 2 +- drivers/scsi/arm/cumana_1.c | 2 +- drivers/scsi/arm/cumana_2.c | 2 +- drivers/scsi/arm/eesox.c

Re: [PATCH 192/493] scsi: remove use of __devinit

On Mon, Nov 19, 2012 at 01:22:21PM -0500, Bill Pemberton wrote: drivers/scsi/arm/acornscsi.c | 2 +- drivers/scsi/arm/arxescsi.c | 2 +- drivers/scsi/arm/cumana_1.c | 2 +- drivers/scsi/arm/cumana_2.c | 2 +- drivers/scsi/arm/eesox.c

Re: [PATCH 22/24] scsi: eesox: use __iomem pointers for MMIO

On Sat, Sep 15, 2012 at 10:30:43AM +, Arnd Bergmann wrote: On Saturday 15 September 2012, Russell King - ARM Linux wrote: On Sat, Sep 15, 2012 at 08:00:35AM +, Arnd Bergmann wrote: On Friday 14 September 2012, Russell King - ARM Linux wrote: On Fri, Sep 14, 2012 at 11:34:50PM

Re: [PATCH 22/24] scsi: eesox: use __iomem pointers for MMIO

On Sat, Sep 15, 2012 at 08:00:35AM +, Arnd Bergmann wrote: On Friday 14 September 2012, Russell King - ARM Linux wrote: On Fri, Sep 14, 2012 at 11:34:50PM +0200, Arnd Bergmann wrote: ARM is moving to stricter checks on readl/write functions, so we need to use the correct types

Re: [PATCH 22/24] scsi: eesox: use __iomem pointers for MMIO

On Fri, Sep 14, 2012 at 11:34:50PM +0200, Arnd Bergmann wrote: ARM is moving to stricter checks on readl/write functions, so we need to use the correct types everywhere. There's nothing wrong with const iomem pointers. If you think otherwise, patch x86 not to use const in its accessor