Re: [PATCH] scsi: lpfc: Switch memcpy_fromio() to __read32_copy()

problem)? Huacai -- Original -- From: "James Smart"; Date: Mon, Mar 5, 2018 11:37 PM To: "陈华才"; "Dick Kennedy"; Cc: "James E . J . Bottomley"; "Martin K . Petersen"; "Fuxin Zhang"; "linux-scsi&q

Re: [PATCH] scsi: lpfc: Switch memcpy_fromio() to __read32_copy()

Hi, James, At least on MIPS (Loongson-3), we found that this patch is necessary. Huacai -- Original -- From: "James Smart"<james.sm...@broadcom.com>; Date: Mon, Mar 5, 2018 11:37 PM To: "陈华才"<che...@lemote.com>; "Dick Ke

Re:[PATCH] scsi: lpfc: Switch memcpy_fromio() to __read32_copy()

No one has the same problem? Or this patch need improve? Huacai -- Original -- From: "陈华才"<che...@lemote.com>; Date: Thu, Mar 1, 2018 01:59 PM To: "James Smart"<james.sm...@broadcom.com>; "Dick Kennedy"<

Re:[PATCH] scsi: lpfc: Switch memcpy_fromio() to __read32_copy()

Ping? -- Original -- From: "Huacai Chen"; Date: Fri, Jan 26, 2018 08:53 PM To: "James Smart"; "Dick Kennedy"; Cc: "James E . J . Bottomley"; "Martin K .

Re: [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()

But in b44_init(), there is no device instances. -- Original -- From: "Christoph Hellwig"; Date: Fri, Nov 10, 2017 08:30 PM To: "Huacai Chen"; Cc: "Christoph Hellwig"; "Marek

Re: [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()

Only patch 4 can be merged to stable, please ignore cc-stable in the rest. -- Original -- From: "Christoph Hellwig"<h...@lst.de>; Date: Fri, Nov 3, 2017 01:14 PM To: "陈华才"<che...@lemote.com>; Cc: "Marek Szyprowski&q

Re: [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()

Why this is still un-merged? Should I remove the cc-stable and resend this series? Huacai -- Original -- From: "陈华才"<che...@lemote.com>; Date: Thu, Oct 26, 2017 02:33 PM To: "Marek Szyprowski"<m.szyprow...@samsung.com>;

Re: [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()

Maybe my first version is suitable for stable. Huacai -- Original -- From: "Marek Szyprowski"<m.szyprow...@samsung.com>; Date: Wed, Oct 25, 2017 03:21 PM To: "陈华才"<che...@lemote.com>; "Christoph Hellwig"<

Re: [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()

Hi, Marek Patch3 is needed for stable, but Patch3 depend on Patch1 and Patch2. Huacai -- Original -- From: "Marek Szyprowski"; Date: Tue, Oct 24, 2017 09:30 PM To: "Huacai Chen"; "Christoph Hellwig";

Re: [PATCH V8 5/5] libata: Align DMA buffer todma_get_cache_alignment()

Hi, Matt, I found that 4ee34ea3a12396f35b26d90a094c75db ("libata: Align ata_device's id on a cacheline") can resolve everything. Because the size of id[ATA_ID_WORDS] is already aligned and devslp_timing needn't to be aligned. So, In V9 of this series I will drop this patch. Why I had problems

Re: [PATCH V8 4/5] libsas: Align SMP req/resp todma_get_cache_alignment()

Hi, Marek, Yes, I know in include/linux/slab.h, there is #define KMALLOC_MIN_SIZE ARCH_DMA_MINALIGN But I observed that the req/resp isn't aligned to ARCH_DMA_MINALIGN and I don't know why. Problems I experienced is: In non-coherent mode, mvsas with an expander cannot detect any disks.

Re: [PATCH V8 5/5] libata: Align DMA buffer todma_get_cache_alignment()

Hi, Sergei, Without this patch, in non-coherent mode, ata_do_set_mode() return with "no PIO support", and disk detection fails. Huacai -- Original -- From: "Sergei Shtylyov"; Date: Tue, Oct 17, 2017 05:43 PM To: "Huacai

Re: [PATCH V7 1/2] dma-mapping: Rework dma_get_cache_alignment()

Hi, Christoph, Can I put the declaration in asm/dma-coherence.h? And, last time you said it is OK to pass a NULL to dma_get_cache_alignment() and cc all driver maintainers. I have do so. Huacai -- Original -- From: "Christoph Hellwig"; Date: Mon,

Re: [PATCH V7 1/2] dma-mapping: Rework dma_get_cache_alignment()

Hi, Robin, Can ARM/ARM64 use the same implementation as MIPS? Or I just do MIPS things is OK? Huacai -- Original -- From: "Robin Murphy"; Date: Mon, Sep 25, 2017 08:57 PM To: "Huacai Chen"; "Christoph

Re: [PATCH V6 1/3] dma-mapping: Introduce device_is_coherent() as ahelper

Hi, Robin, Before 2.6.36 dma_get_cache_alignment is arch-dependent, and it is unified in commit 4565f0170dfc849b3629c27d7 ("dma-mapping: unify dma_get_cache_alignment implementations"). Should we revert to the old implementation? Huacai -- Original -- From:

Re: [PATCH V6 2/3] dma-mapping: Rework dma_get_cache_alignment()function

Hi, Christoph, I have changed dma_get_cache_alignment's return value, and I don't know whether those drivers want to return ARCH_DMA_MINALIGN unconditionally. So I pass a NULL for those drivers, in order to keep their old behavior. Huacai -- Original -- From:

Re: [PATCH V5 3/3] scsi: Align queue to ARCH_DMA_MINALIGN innon-coherent DMA mode

Hi, Christoph, I don't think dma_get_cache_alignment is the "absolute minimum alignment" in all cases. At least on MIPS/Loongson, if we use I/O coherent mode (Cached DMA mode), align block queue to 4Bytes is enough. If we align block queue to dma_get_cache_alignment in I/O coherent mode,

Re: [PATCH 2/2] scsi: Align queue to ARCH_DMA_MINALIGN innon-coherent DMA mode

Hi, Christoph I think we cannot modify dma_get_cache_alignment(), because existing callers may want to unconditionally return ARCH_DMA_MINALIGN. Huacai -- Original -- From: "Christoph Hellwig"; Date: Mon, Sep 11, 2017 03:39 PM To: