* 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.