* sata_dwc_460ex build failures in -next [not found] <E1YAZyB-0007iE-CZ@debutante> @ 2015-01-12 12:36 ` Mark Brown 2015-01-12 12:50 ` Russell King - ARM Linux 0 siblings, 1 reply; 7+ messages in thread From: Mark Brown @ 2015-01-12 12:36 UTC (permalink / raw) To: Tejun Heo, Andy Shevchenko Cc: kernel-build-reports, linaro-kernel, linux-ide, linux-arm-kernel [-- Attachment #1: Type: text/plain, Size: 775 bytes --] On Mon, Jan 12, 2015 at 08:03:27AM +0000, Build bot for Mark Brown wrote: > arm64-allmodconfig > ../drivers/ata/sata_dwc_460ex.c:719:3: error: implicit declaration of function 'dma_cache_sync' [-Werror=implicit-function-declaration] > > arm-allmodconfig > ../drivers/ata/sata_dwc_460ex.c:719:3: error: implicit declaration of function 'dma_cache_sync' [-Werror=implicit-function-declaration] Since commit 84683a7e081ff60e (sata_dwc_460ex: enable COMPILE_TEST for the driver) the sata_dwc_460ex has been breaking the all*config builds for arm and arm64 as the driver uses dma_cache_sync() but this function is not provided on those architectures. Either a more specific dependency is needed or the function shouldn't be used, I've not looked at the code. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: sata_dwc_460ex build failures in -next 2015-01-12 12:36 ` sata_dwc_460ex build failures in -next Mark Brown @ 2015-01-12 12:50 ` Russell King - ARM Linux 0 siblings, 0 replies; 7+ messages in thread From: Russell King - ARM Linux @ 2015-01-12 12:50 UTC (permalink / raw) To: Mark Brown Cc: Tejun Heo, Andy Shevchenko, linux-ide, linaro-kernel, linux-arm-kernel, kernel-build-reports On Mon, Jan 12, 2015 at 12:36:55PM +0000, Mark Brown wrote: > On Mon, Jan 12, 2015 at 08:03:27AM +0000, Build bot for Mark Brown wrote: > > > arm64-allmodconfig > > ../drivers/ata/sata_dwc_460ex.c:719:3: error: implicit declaration of function 'dma_cache_sync' [-Werror=implicit-function-declaration] > > > > arm-allmodconfig > > ../drivers/ata/sata_dwc_460ex.c:719:3: error: implicit declaration of function 'dma_cache_sync' [-Werror=implicit-function-declaration] > > Since commit 84683a7e081ff60e (sata_dwc_460ex: enable COMPILE_TEST for > the driver) the sata_dwc_460ex has been breaking the all*config builds > for arm and arm64 as the driver uses dma_cache_sync() but this function > is not provided on those architectures. > > Either a more specific dependency is needed or the function shouldn't be > used, I've not looked at the code. The driver does look rather broken. Let's first read up when dma_cache_sync() should be used: void dma_cache_sync(struct device *dev, void *vaddr, size_t size, enum dma_data_direction direction) Do a partial sync of memory that was allocated by dma_alloc_noncoherent(), starting at virtual address vaddr and continuing on for size. Again, you *must* observe the cache line boundaries when doing this. Note "memory that was allocated by dma_alloc_noncoherent()". Now, let's look at the driver: static int map_sg_to_lli(struct scatterlist *sg, int num_elems, struct lli *lli, dma_addr_t dma_lli, void __iomem *dmadr_addr, int dir) { ... dma_cache_sync(NULL, lli, (sizeof(struct lli) * idx), DMA_BIDIRECTIONAL); } static int dma_dwc_xfer_setup(struct scatterlist *sg, int num_elems, struct lli *lli, dma_addr_t dma_lli, void __iomem *addr, int dir) { /* Convert SG list to linked list of items (LLIs) for AHB DMA */ num_lli = map_sg_to_lli(sg, num_elems, lli, dma_lli, addr, dir); } dma_chan = dma_dwc_xfer_setup(sg, qc->n_elem, hsdevp->llit[tag], hsdevp->llit_dma[tag], (void *__iomem)(&hsdev->sata_dwc_regs->\ dmadr), qc->dma_dir); for (i = 0; i < SATA_DWC_QCMD_MAX; i++) { hsdevp->llit[i] = dma_alloc_coherent(pdev, SATA_DWC_DMAC_LLI_TBL_SZ, &(hsdevp->llit_dma[i]), GFP_ATOMIC); So, hsdevp->llit[x] is allocated using dma_alloc_*coherent*(), not dma_alloc_*noncohernet*(), so dma_cache_sync() should not be used according to the DMA API documentation. Moreover, that GFP_ATOMIC flag looks mightily suspicious - we've done a previous allocation using kzalloc(, GFP_KERNEL), so we aren't in an atomic region, so why use GFP_ATOMIC there? It doesn't look like it'll pass sparse checks either: struct sata_dwc_device { u8 *reg_base; struct sata_dwc_regs *sata_dwc_regs; /* DW Synopsys SATA specific */ }; u8 *base = NULL; base = of_iomap(ofdev->dev.of_node, 0); hsdev->reg_base = base; hsdev->sata_dwc_regs = (void *__iomem)(base + SATA_DWC_REG_OFFSET); Maybe it should be moved to drivers/staging? :) -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 7+ messages in thread
* sata_dwc_460ex build failures in -next @ 2015-01-12 12:50 ` Russell King - ARM Linux 0 siblings, 0 replies; 7+ messages in thread From: Russell King - ARM Linux @ 2015-01-12 12:50 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jan 12, 2015 at 12:36:55PM +0000, Mark Brown wrote: > On Mon, Jan 12, 2015 at 08:03:27AM +0000, Build bot for Mark Brown wrote: > > > arm64-allmodconfig > > ../drivers/ata/sata_dwc_460ex.c:719:3: error: implicit declaration of function 'dma_cache_sync' [-Werror=implicit-function-declaration] > > > > arm-allmodconfig > > ../drivers/ata/sata_dwc_460ex.c:719:3: error: implicit declaration of function 'dma_cache_sync' [-Werror=implicit-function-declaration] > > Since commit 84683a7e081ff60e (sata_dwc_460ex: enable COMPILE_TEST for > the driver) the sata_dwc_460ex has been breaking the all*config builds > for arm and arm64 as the driver uses dma_cache_sync() but this function > is not provided on those architectures. > > Either a more specific dependency is needed or the function shouldn't be > used, I've not looked at the code. The driver does look rather broken. Let's first read up when dma_cache_sync() should be used: void dma_cache_sync(struct device *dev, void *vaddr, size_t size, enum dma_data_direction direction) Do a partial sync of memory that was allocated by dma_alloc_noncoherent(), starting at virtual address vaddr and continuing on for size. Again, you *must* observe the cache line boundaries when doing this. Note "memory that was allocated by dma_alloc_noncoherent()". Now, let's look at the driver: static int map_sg_to_lli(struct scatterlist *sg, int num_elems, struct lli *lli, dma_addr_t dma_lli, void __iomem *dmadr_addr, int dir) { ... dma_cache_sync(NULL, lli, (sizeof(struct lli) * idx), DMA_BIDIRECTIONAL); } static int dma_dwc_xfer_setup(struct scatterlist *sg, int num_elems, struct lli *lli, dma_addr_t dma_lli, void __iomem *addr, int dir) { /* Convert SG list to linked list of items (LLIs) for AHB DMA */ num_lli = map_sg_to_lli(sg, num_elems, lli, dma_lli, addr, dir); } dma_chan = dma_dwc_xfer_setup(sg, qc->n_elem, hsdevp->llit[tag], hsdevp->llit_dma[tag], (void *__iomem)(&hsdev->sata_dwc_regs->\ dmadr), qc->dma_dir); for (i = 0; i < SATA_DWC_QCMD_MAX; i++) { hsdevp->llit[i] = dma_alloc_coherent(pdev, SATA_DWC_DMAC_LLI_TBL_SZ, &(hsdevp->llit_dma[i]), GFP_ATOMIC); So, hsdevp->llit[x] is allocated using dma_alloc_*coherent*(), not dma_alloc_*noncohernet*(), so dma_cache_sync() should not be used according to the DMA API documentation. Moreover, that GFP_ATOMIC flag looks mightily suspicious - we've done a previous allocation using kzalloc(, GFP_KERNEL), so we aren't in an atomic region, so why use GFP_ATOMIC there? It doesn't look like it'll pass sparse checks either: struct sata_dwc_device { u8 *reg_base; struct sata_dwc_regs *sata_dwc_regs; /* DW Synopsys SATA specific */ }; u8 *base = NULL; base = of_iomap(ofdev->dev.of_node, 0); hsdev->reg_base = base; hsdev->sata_dwc_regs = (void *__iomem)(base + SATA_DWC_REG_OFFSET); Maybe it should be moved to drivers/staging? :) -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: sata_dwc_460ex build failures in -next 2015-01-12 12:50 ` Russell King - ARM Linux @ 2015-01-12 12:59 ` Andy Shevchenko -1 siblings, 0 replies; 7+ messages in thread From: Andy Shevchenko @ 2015-01-12 12:59 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Mark Brown, Tejun Heo, linux-ide, linaro-kernel, linux-arm-kernel, kernel-build-reports On Mon, 2015-01-12 at 12:50 +0000, Russell King - ARM Linux wrote: > On Mon, Jan 12, 2015 at 12:36:55PM +0000, Mark Brown wrote: > > On Mon, Jan 12, 2015 at 08:03:27AM +0000, Build bot for Mark Brown wrote: > > > > > arm64-allmodconfig > > > ../drivers/ata/sata_dwc_460ex.c:719:3: error: implicit declaration of function 'dma_cache_sync' [-Werror=implicit-function-declaration] > > > > > > arm-allmodconfig > > > ../drivers/ata/sata_dwc_460ex.c:719:3: error: implicit declaration of function 'dma_cache_sync' [-Werror=implicit-function-declaration] > > > > Since commit 84683a7e081ff60e (sata_dwc_460ex: enable COMPILE_TEST for > > the driver) the sata_dwc_460ex has been breaking the all*config builds > > for arm and arm64 as the driver uses dma_cache_sync() but this function > > is not provided on those architectures. > > > > Either a more specific dependency is needed or the function shouldn't be > > used, I've not looked at the code. > > The driver does look rather broken. Let's first read up when dma_cache_sync() > should be used: > > void > dma_cache_sync(struct device *dev, void *vaddr, size_t size, > enum dma_data_direction direction) > > Do a partial sync of memory that was allocated by > dma_alloc_noncoherent(), starting at virtual address vaddr and > continuing on for size. Again, you *must* observe the cache line > boundaries when doing this. > > Note "memory that was allocated by dma_alloc_noncoherent()". > > Now, let's look at the driver: > > static int map_sg_to_lli(struct scatterlist *sg, int num_elems, > struct lli *lli, dma_addr_t dma_lli, > void __iomem *dmadr_addr, int dir) > { > ... > dma_cache_sync(NULL, lli, (sizeof(struct lli) * idx), > DMA_BIDIRECTIONAL); > } > > static int dma_dwc_xfer_setup(struct scatterlist *sg, int num_elems, > struct lli *lli, dma_addr_t dma_lli, > void __iomem *addr, int dir) > { > /* Convert SG list to linked list of items (LLIs) for AHB DMA */ > num_lli = map_sg_to_lli(sg, num_elems, lli, dma_lli, addr, dir); > } > > dma_chan = dma_dwc_xfer_setup(sg, qc->n_elem, hsdevp->llit[tag], > hsdevp->llit_dma[tag], > (void *__iomem)(&hsdev->sata_dwc_regs->\ > dmadr), qc->dma_dir); > > for (i = 0; i < SATA_DWC_QCMD_MAX; i++) { > hsdevp->llit[i] = dma_alloc_coherent(pdev, > SATA_DWC_DMAC_LLI_TBL_SZ, > &(hsdevp->llit_dma[i]), > GFP_ATOMIC); > > So, hsdevp->llit[x] is allocated using dma_alloc_*coherent*(), not > dma_alloc_*noncohernet*(), so dma_cache_sync() should not be used > according to the DMA API documentation. > > Moreover, that GFP_ATOMIC flag looks mightily suspicious - we've done > a previous allocation using kzalloc(, GFP_KERNEL), so we aren't in an > atomic region, so why use GFP_ATOMIC there? > > It doesn't look like it'll pass sparse checks either: > > struct sata_dwc_device { > u8 *reg_base; > struct sata_dwc_regs *sata_dwc_regs; /* DW Synopsys SATA specific */ > }; > > u8 *base = NULL; > > base = of_iomap(ofdev->dev.of_node, 0); > hsdev->reg_base = base; > hsdev->sata_dwc_regs = (void *__iomem)(base + SATA_DWC_REG_OFFSET); > > Maybe it should be moved to drivers/staging? :) I'm working on it. My target is to remove private implementation of dw_dmac from this driver. It will make it mostly free of sparse / compiler warnings. Sorry, I didn't test on ARM platform since I have none. I just send a plug patch to disable compilation on ARMs. -- Andy Shevchenko <andriy.shevchenko@intel.com> Intel Finland Oy ^ permalink raw reply [flat|nested] 7+ messages in thread
* sata_dwc_460ex build failures in -next @ 2015-01-12 12:59 ` Andy Shevchenko 0 siblings, 0 replies; 7+ messages in thread From: Andy Shevchenko @ 2015-01-12 12:59 UTC (permalink / raw) To: linux-arm-kernel On Mon, 2015-01-12 at 12:50 +0000, Russell King - ARM Linux wrote: > On Mon, Jan 12, 2015 at 12:36:55PM +0000, Mark Brown wrote: > > On Mon, Jan 12, 2015 at 08:03:27AM +0000, Build bot for Mark Brown wrote: > > > > > arm64-allmodconfig > > > ../drivers/ata/sata_dwc_460ex.c:719:3: error: implicit declaration of function 'dma_cache_sync' [-Werror=implicit-function-declaration] > > > > > > arm-allmodconfig > > > ../drivers/ata/sata_dwc_460ex.c:719:3: error: implicit declaration of function 'dma_cache_sync' [-Werror=implicit-function-declaration] > > > > Since commit 84683a7e081ff60e (sata_dwc_460ex: enable COMPILE_TEST for > > the driver) the sata_dwc_460ex has been breaking the all*config builds > > for arm and arm64 as the driver uses dma_cache_sync() but this function > > is not provided on those architectures. > > > > Either a more specific dependency is needed or the function shouldn't be > > used, I've not looked at the code. > > The driver does look rather broken. Let's first read up when dma_cache_sync() > should be used: > > void > dma_cache_sync(struct device *dev, void *vaddr, size_t size, > enum dma_data_direction direction) > > Do a partial sync of memory that was allocated by > dma_alloc_noncoherent(), starting at virtual address vaddr and > continuing on for size. Again, you *must* observe the cache line > boundaries when doing this. > > Note "memory that was allocated by dma_alloc_noncoherent()". > > Now, let's look at the driver: > > static int map_sg_to_lli(struct scatterlist *sg, int num_elems, > struct lli *lli, dma_addr_t dma_lli, > void __iomem *dmadr_addr, int dir) > { > ... > dma_cache_sync(NULL, lli, (sizeof(struct lli) * idx), > DMA_BIDIRECTIONAL); > } > > static int dma_dwc_xfer_setup(struct scatterlist *sg, int num_elems, > struct lli *lli, dma_addr_t dma_lli, > void __iomem *addr, int dir) > { > /* Convert SG list to linked list of items (LLIs) for AHB DMA */ > num_lli = map_sg_to_lli(sg, num_elems, lli, dma_lli, addr, dir); > } > > dma_chan = dma_dwc_xfer_setup(sg, qc->n_elem, hsdevp->llit[tag], > hsdevp->llit_dma[tag], > (void *__iomem)(&hsdev->sata_dwc_regs->\ > dmadr), qc->dma_dir); > > for (i = 0; i < SATA_DWC_QCMD_MAX; i++) { > hsdevp->llit[i] = dma_alloc_coherent(pdev, > SATA_DWC_DMAC_LLI_TBL_SZ, > &(hsdevp->llit_dma[i]), > GFP_ATOMIC); > > So, hsdevp->llit[x] is allocated using dma_alloc_*coherent*(), not > dma_alloc_*noncohernet*(), so dma_cache_sync() should not be used > according to the DMA API documentation. > > Moreover, that GFP_ATOMIC flag looks mightily suspicious - we've done > a previous allocation using kzalloc(, GFP_KERNEL), so we aren't in an > atomic region, so why use GFP_ATOMIC there? > > It doesn't look like it'll pass sparse checks either: > > struct sata_dwc_device { > u8 *reg_base; > struct sata_dwc_regs *sata_dwc_regs; /* DW Synopsys SATA specific */ > }; > > u8 *base = NULL; > > base = of_iomap(ofdev->dev.of_node, 0); > hsdev->reg_base = base; > hsdev->sata_dwc_regs = (void *__iomem)(base + SATA_DWC_REG_OFFSET); > > Maybe it should be moved to drivers/staging? :) I'm working on it. My target is to remove private implementation of dw_dmac from this driver. It will make it mostly free of sparse / compiler warnings. Sorry, I didn't test on ARM platform since I have none. I just send a plug patch to disable compilation on ARMs. -- Andy Shevchenko <andriy.shevchenko@intel.com> Intel Finland Oy ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: sata_dwc_460ex build failures in -next 2015-01-12 12:59 ` Andy Shevchenko @ 2015-01-12 13:07 ` Mark Brown -1 siblings, 0 replies; 7+ messages in thread From: Mark Brown @ 2015-01-12 13:07 UTC (permalink / raw) To: Andy Shevchenko Cc: Russell King - ARM Linux, Tejun Heo, linux-ide, linaro-kernel, linux-arm-kernel, kernel-build-reports [-- Attachment #1: Type: text/plain, Size: 134 bytes --] On Mon, Jan 12, 2015 at 02:59:24PM +0200, Andy Shevchenko wrote: > I just send a plug patch to disable compilation on ARMs. Thanks. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* sata_dwc_460ex build failures in -next @ 2015-01-12 13:07 ` Mark Brown 0 siblings, 0 replies; 7+ messages in thread From: Mark Brown @ 2015-01-12 13:07 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jan 12, 2015 at 02:59:24PM +0200, Andy Shevchenko wrote: > I just send a plug patch to disable compilation on ARMs. Thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150112/12aead17/attachment.sig> ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-01-12 13:07 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <E1YAZyB-0007iE-CZ@debutante> 2015-01-12 12:36 ` sata_dwc_460ex build failures in -next Mark Brown 2015-01-12 12:50 ` Russell King - ARM Linux 2015-01-12 12:50 ` Russell King - ARM Linux 2015-01-12 12:59 ` Andy Shevchenko 2015-01-12 12:59 ` Andy Shevchenko 2015-01-12 13:07 ` Mark Brown 2015-01-12 13:07 ` Mark Brown
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.