* [PATCH] net: fec: set dma_coherent_mask
@ 2018-03-26 13:36 Greg Ungerer
2018-03-27 12:59 ` Geert Uytterhoeven
2018-03-27 13:24 ` Lino Sanfilippo
0 siblings, 2 replies; 9+ messages in thread
From: Greg Ungerer @ 2018-03-26 13:36 UTC (permalink / raw)
To: netdev, linux-m68k; +Cc: Greg Ungerer
As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
coherent_dma_mask") the Freescale FEC driver is issuing the following
warning on driver initialization on ColdFire systems:
WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 0x40159e20
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc7-dirty #4
Stack from 41833dd8:
41833dd8 40259c53 40025534 40279e26 00000003 00000000 4004e514 41827000
400255de 40244e42 00000204 40159e20 00000009 00000000 00000000 4024531d
40159e20 40244e42 00000204 00000000 00000000 00000000 00000007 00000000
00000000 40279e26 4028d040 40226576 4003ae88 40279e26 418273f6 41833ef8
7fffffff 418273f2 41867028 4003c9a2 4180ac6c 00000004 41833f8c 4013e71c
40279e1c 40279e26 40226c16 4013ced2 40279e26 40279e58 4028d040 00000000
Call Trace:
[<40025534>] 0x40025534
[<4004e514>] 0x4004e514
[<400255de>] 0x400255de
[<40159e20>] 0x40159e20
[<40159e20>] 0x40159e20
It is not fatal, the driver and the system continue to function normally.
As per the warning the coherent_dma_mask is not set on this device.
There is nothing special about the DMA memory coherency on this hardware
so we can just set the mask to 32bits during probe.
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
---
drivers/net/ethernet/freescale/fec_main.c | 2 ++
1 file changed, 2 insertions(+)
Is this the best way to handle this problem?
Comments welcome...
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index d4604bc..3cb130a 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2702,6 +2702,8 @@ static int fec_enet_alloc_queue(struct net_device *ndev)
int ret = 0;
struct fec_enet_priv_tx_q *txq;
+ dma_set_coherent_mask(&fep->pdev->dev, DMA_BIT_MASK(32));
+
for (i = 0; i < fep->num_tx_queues; i++) {
txq = kzalloc(sizeof(*txq), GFP_KERNEL);
if (!txq) {
--
1.9.1
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] net: fec: set dma_coherent_mask
2018-03-26 13:36 [PATCH] net: fec: set dma_coherent_mask Greg Ungerer
@ 2018-03-27 12:59 ` Geert Uytterhoeven
2018-03-28 3:04 ` Andy Duan
2018-03-28 7:27 ` Greg Ungerer
2018-03-27 13:24 ` Lino Sanfilippo
1 sibling, 2 replies; 9+ messages in thread
From: Geert Uytterhoeven @ 2018-03-27 12:59 UTC (permalink / raw)
To: Greg Ungerer; +Cc: netdev, Linux/m68k
Hi Greg,
On Mon, Mar 26, 2018 at 3:36 PM, Greg Ungerer <gerg@linux-m68k.org> wrote:
> As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
> coherent_dma_mask") the Freescale FEC driver is issuing the following
> warning on driver initialization on ColdFire systems:
>
> WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 0x40159e20
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc7-dirty #4
> Stack from 41833dd8:
> 41833dd8 40259c53 40025534 40279e26 00000003 00000000 4004e514 41827000
> 400255de 40244e42 00000204 40159e20 00000009 00000000 00000000 4024531d
> 40159e20 40244e42 00000204 00000000 00000000 00000000 00000007 00000000
> 00000000 40279e26 4028d040 40226576 4003ae88 40279e26 418273f6 41833ef8
> 7fffffff 418273f2 41867028 4003c9a2 4180ac6c 00000004 41833f8c 4013e71c
> 40279e1c 40279e26 40226c16 4013ced2 40279e26 40279e58 4028d040 00000000
> Call Trace:
> [<40025534>] 0x40025534
> [<4004e514>] 0x4004e514
> [<400255de>] 0x400255de
> [<40159e20>] 0x40159e20
> [<40159e20>] 0x40159e20
>
> It is not fatal, the driver and the system continue to function normally.
>
> As per the warning the coherent_dma_mask is not set on this device.
> There is nothing special about the DMA memory coherency on this hardware
> so we can just set the mask to 32bits during probe.
>
> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Thanks for your patch!
> ---
> drivers/net/ethernet/freescale/fec_main.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> Is this the best way to handle this problem?
> Comments welcome...
>
> diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
> index d4604bc..3cb130a 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -2702,6 +2702,8 @@ static int fec_enet_alloc_queue(struct net_device *ndev)
> int ret = 0;
> struct fec_enet_priv_tx_q *txq;
>
> + dma_set_coherent_mask(&fep->pdev->dev, DMA_BIT_MASK(32));
> +
> for (i = 0; i < fep->num_tx_queues; i++) {
> txq = kzalloc(sizeof(*txq), GFP_KERNEL);
> if (!txq) {
As per your other email, this does not trigger on iMX systems using DT.
Hence I'm wondering if the Coldfire platform code shouldn't just do the
same what drivers/of/device.c does, cfr.
https://www.spinics.net/lists/linux-m68k/msg10929.html?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] net: fec: set dma_coherent_mask
2018-03-26 13:36 [PATCH] net: fec: set dma_coherent_mask Greg Ungerer
2018-03-27 12:59 ` Geert Uytterhoeven
@ 2018-03-27 13:24 ` Lino Sanfilippo
1 sibling, 0 replies; 9+ messages in thread
From: Lino Sanfilippo @ 2018-03-27 13:24 UTC (permalink / raw)
Cc: netdev, linux-m68k, Greg Ungerer
Hi,
>
> + dma_set_coherent_mask(&fep->pdev->dev, DMA_BIT_MASK(32));
> +
> for (i = 0; i < fep->num_tx_queues; i++) {
> txq = kzalloc(sizeof(*txq), GFP_KERNEL);
> if (!txq) {
dma_set_coherent_mask() can fail, so the return value should be checked and
a failure be handled accordingly.
Regards,
Lino
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [PATCH] net: fec: set dma_coherent_mask
2018-03-27 12:59 ` Geert Uytterhoeven
@ 2018-03-28 3:04 ` Andy Duan
2018-03-28 7:06 ` Geert Uytterhoeven
2018-03-28 7:27 ` Greg Ungerer
1 sibling, 1 reply; 9+ messages in thread
From: Andy Duan @ 2018-03-28 3:04 UTC (permalink / raw)
To: Geert Uytterhoeven, Greg Ungerer; +Cc: netdev, Linux/m68k
From: Geert Uytterhoeven <geert@linux-m68k.org> Sent: 2018年3月27日 20:59
> Hi Greg,
>
> On Mon, Mar 26, 2018 at 3:36 PM, Greg Ungerer <gerg@linux-m68k.org> wrote:
> > As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
> > coherent_dma_mask") the Freescale FEC driver is issuing the following
> > warning on driver initialization on ColdFire systems:
> >
> > WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 0x40159e20
> > Modules linked in:
> > CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc7-dirty #4 Stack from
> > 41833dd8:
> > 41833dd8 40259c53 40025534 40279e26 00000003 00000000
> 4004e514 41827000
> > 400255de 40244e42 00000204 40159e20 00000009 00000000
> 00000000 4024531d
> > 40159e20 40244e42 00000204 00000000 00000000 00000000
> 00000007 00000000
> > 00000000 40279e26 4028d040 40226576 4003ae88 40279e26
> 418273f6 41833ef8
> > 7fffffff 418273f2 41867028 4003c9a2 4180ac6c 00000004 41833f8c
> 4013e71c
> > 40279e1c 40279e26 40226c16 4013ced2 40279e26 40279e58
> 4028d040
> > 00000000 Call Trace:
> > [<40025534>] 0x40025534
> > [<4004e514>] 0x4004e514
> > [<400255de>] 0x400255de
> > [<40159e20>] 0x40159e20
> > [<40159e20>] 0x40159e20
> >
> > It is not fatal, the driver and the system continue to function normally.
> >
> > As per the warning the coherent_dma_mask is not set on this device.
> > There is nothing special about the DMA memory coherency on this
> > hardware so we can just set the mask to 32bits during probe.
> >
> > Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
>
> Thanks for your patch!
>
> > ---
> > drivers/net/ethernet/freescale/fec_main.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > Is this the best way to handle this problem?
> > Comments welcome...
> >
> > diff --git a/drivers/net/ethernet/freescale/fec_main.c
> > b/drivers/net/ethernet/freescale/fec_main.c
> > index d4604bc..3cb130a 100644
> > --- a/drivers/net/ethernet/freescale/fec_main.c
> > +++ b/drivers/net/ethernet/freescale/fec_main.c
> > @@ -2702,6 +2702,8 @@ static int fec_enet_alloc_queue(struct net_device
> *ndev)
> > int ret = 0;
> > struct fec_enet_priv_tx_q *txq;
> >
> > + dma_set_coherent_mask(&fep->pdev->dev, DMA_BIT_MASK(32));
> > +
> > for (i = 0; i < fep->num_tx_queues; i++) {
> > txq = kzalloc(sizeof(*txq), GFP_KERNEL);
> > if (!txq) {
>
> As per your other email, this does not trigger on iMX systems using DT.
> Hence I'm wondering if the Coldfire platform code shouldn't just do the same what
> drivers/of/device.c does, cfr.
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.s
> pinics.net%2Flists%2Flinux-m68k%2Fmsg10929.html&data=02%7C01%7Cfugan
> g.duan%40nxp.com%7C3db2dbadf1154965370608d593e294b2%7C686ea1d3
> bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636577523756185995&sdata=bsO
> F%2BnSeXTP7C%2F55JLO3Pv8YybPahMaZDyqB16f9ySA%3D&reserved=0?
>
> Gr{oetje,eeting}s,
>
> Geert
>
It is better to use of_dma_configure(&pdev->dev, np), it iommu support, device also can allocate memory from 64bit space.
Andy
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] net: fec: set dma_coherent_mask
2018-03-28 3:04 ` Andy Duan
@ 2018-03-28 7:06 ` Geert Uytterhoeven
2018-03-28 7:15 ` Andy Duan
0 siblings, 1 reply; 9+ messages in thread
From: Geert Uytterhoeven @ 2018-03-28 7:06 UTC (permalink / raw)
To: Andy Duan; +Cc: Greg Ungerer, netdev, Linux/m68k
Hi Andy,
On Wed, Mar 28, 2018 at 5:04 AM, Andy Duan <fugang.duan@nxp.com> wrote:
> From: Geert Uytterhoeven <geert@linux-m68k.org> Sent: 2018年3月27日 20:59
>> On Mon, Mar 26, 2018 at 3:36 PM, Greg Ungerer <gerg@linux-m68k.org> wrote:
>> > As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
>> > coherent_dma_mask") the Freescale FEC driver is issuing the following
>> > warning on driver initialization on ColdFire systems:
>> >
>> > WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 0x40159e20
>> > Modules linked in:
>> > CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc7-dirty #4 Stack from
>> > 41833dd8:
>> > 41833dd8 40259c53 40025534 40279e26 00000003 00000000
>> 4004e514 41827000
>> > 400255de 40244e42 00000204 40159e20 00000009 00000000
>> 00000000 4024531d
>> > 40159e20 40244e42 00000204 00000000 00000000 00000000
>> 00000007 00000000
>> > 00000000 40279e26 4028d040 40226576 4003ae88 40279e26
>> 418273f6 41833ef8
>> > 7fffffff 418273f2 41867028 4003c9a2 4180ac6c 00000004 41833f8c
>> 4013e71c
>> > 40279e1c 40279e26 40226c16 4013ced2 40279e26 40279e58
>> 4028d040
>> > 00000000 Call Trace:
>> > [<40025534>] 0x40025534
>> > [<4004e514>] 0x4004e514
>> > [<400255de>] 0x400255de
>> > [<40159e20>] 0x40159e20
>> > [<40159e20>] 0x40159e20
>> >
>> > It is not fatal, the driver and the system continue to function normally.
>> >
>> > As per the warning the coherent_dma_mask is not set on this device.
>> > There is nothing special about the DMA memory coherency on this
>> > hardware so we can just set the mask to 32bits during probe.
>> >
>> > Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
>>
>> Thanks for your patch!
>>
>> > ---
>> > drivers/net/ethernet/freescale/fec_main.c | 2 ++
>> > 1 file changed, 2 insertions(+)
>> >
>> > Is this the best way to handle this problem?
>> > Comments welcome...
>> >
>> > diff --git a/drivers/net/ethernet/freescale/fec_main.c
>> > b/drivers/net/ethernet/freescale/fec_main.c
>> > index d4604bc..3cb130a 100644
>> > --- a/drivers/net/ethernet/freescale/fec_main.c
>> > +++ b/drivers/net/ethernet/freescale/fec_main.c
>> > @@ -2702,6 +2702,8 @@ static int fec_enet_alloc_queue(struct net_device
>> *ndev)
>> > int ret = 0;
>> > struct fec_enet_priv_tx_q *txq;
>> >
>> > + dma_set_coherent_mask(&fep->pdev->dev, DMA_BIT_MASK(32));
>> > +
>> > for (i = 0; i < fep->num_tx_queues; i++) {
>> > txq = kzalloc(sizeof(*txq), GFP_KERNEL);
>> > if (!txq) {
>>
>> As per your other email, this does not trigger on iMX systems using DT.
>> Hence I'm wondering if the Coldfire platform code shouldn't just do the same what
>> drivers/of/device.c does, cfr.
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.s
>> pinics.net%2Flists%2Flinux-m68k%2Fmsg10929.html&data=02%7C01%7Cfugan
>> g.duan%40nxp.com%7C3db2dbadf1154965370608d593e294b2%7C686ea1d3
>> bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636577523756185995&sdata=bsO
>> F%2BnSeXTP7C%2F55JLO3Pv8YybPahMaZDyqB16f9ySA%3D&reserved=0?
>>
>> Gr{oetje,eeting}s,
>>
>> Geert
>>
> It is better to use of_dma_configure(&pdev->dev, np), it iommu support, device also can allocate memory from 64bit space.
At first sight, it indeed looks like of_dma_configure() would do the
right thing,
even on platforms without DT like Coldfire.
Unfortunately of_dma_configure() is replaced by a dummy if !CONFIG_OF.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [PATCH] net: fec: set dma_coherent_mask
2018-03-28 7:06 ` Geert Uytterhoeven
@ 2018-03-28 7:15 ` Andy Duan
0 siblings, 0 replies; 9+ messages in thread
From: Andy Duan @ 2018-03-28 7:15 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Greg Ungerer, netdev, Linux/m68k
From: Geert Uytterhoeven <geert@linux-m68k.org> Sent: 2018年3月28日 15:07
> Hi Andy,
>
> On Wed, Mar 28, 2018 at 5:04 AM, Andy Duan <fugang.duan@nxp.com> wrote:
> > From: Geert Uytterhoeven <geert@linux-m68k.org> Sent: 2018年3月27日
> 20:59
> >> On Mon, Mar 26, 2018 at 3:36 PM, Greg Ungerer <gerg@linux-m68k.org>
> wrote:
> >> > As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
> >> > coherent_dma_mask") the Freescale FEC driver is issuing the
> >> > following warning on driver initialization on ColdFire systems:
> >> >
> >> > WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516
> >> > 0x40159e20 Modules linked in:
> >> > CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc7-dirty #4 Stack
> >> > from
> >> > 41833dd8:
> >> > 41833dd8 40259c53 40025534 40279e26 00000003 00000000
> >> 4004e514 41827000
> >> > 400255de 40244e42 00000204 40159e20 00000009 00000000
> >> 00000000 4024531d
> >> > 40159e20 40244e42 00000204 00000000 00000000 00000000
> >> 00000007 00000000
> >> > 00000000 40279e26 4028d040 40226576 4003ae88 40279e26
> >> 418273f6 41833ef8
> >> > 7fffffff 418273f2 41867028 4003c9a2 4180ac6c 00000004
> >> > 41833f8c
> >> 4013e71c
> >> > 40279e1c 40279e26 40226c16 4013ced2 40279e26 40279e58
> >> 4028d040
> >> > 00000000 Call Trace:
> >> > [<40025534>] 0x40025534
> >> > [<4004e514>] 0x4004e514
> >> > [<400255de>] 0x400255de
> >> > [<40159e20>] 0x40159e20
> >> > [<40159e20>] 0x40159e20
> >> >
> >> > It is not fatal, the driver and the system continue to function normally.
> >> >
> >> > As per the warning the coherent_dma_mask is not set on this device.
> >> > There is nothing special about the DMA memory coherency on this
> >> > hardware so we can just set the mask to 32bits during probe.
> >> >
> >> > Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
> >>
> >> Thanks for your patch!
> >>
> >> > ---
> >> > drivers/net/ethernet/freescale/fec_main.c | 2 ++
> >> > 1 file changed, 2 insertions(+)
> >> >
> >> > Is this the best way to handle this problem?
> >> > Comments welcome...
> >> >
> >> > diff --git a/drivers/net/ethernet/freescale/fec_main.c
> >> > b/drivers/net/ethernet/freescale/fec_main.c
> >> > index d4604bc..3cb130a 100644
> >> > --- a/drivers/net/ethernet/freescale/fec_main.c
> >> > +++ b/drivers/net/ethernet/freescale/fec_main.c
> >> > @@ -2702,6 +2702,8 @@ static int fec_enet_alloc_queue(struct
> >> > net_device
> >> *ndev)
> >> > int ret = 0;
> >> > struct fec_enet_priv_tx_q *txq;
> >> >
> >> > + dma_set_coherent_mask(&fep->pdev->dev, DMA_BIT_MASK(32));
> >> > +
> >> > for (i = 0; i < fep->num_tx_queues; i++) {
> >> > txq = kzalloc(sizeof(*txq), GFP_KERNEL);
> >> > if (!txq) {
> >>
> >> As per your other email, this does not trigger on iMX systems using DT.
> >> Hence I'm wondering if the Coldfire platform code shouldn't just do
> >> the same what drivers/of/device.c does, cfr.
> >> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> >> w.s
> >>
> pinics.net%2Flists%2Flinux-m68k%2Fmsg10929.html&data=02%7C01%7Cfugan
> >>
> g.duan%40nxp.com%7C3db2dbadf1154965370608d593e294b2%7C686ea1d3
> >>
> bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636577523756185995&sdata=bsO
> >> F%2BnSeXTP7C%2F55JLO3Pv8YybPahMaZDyqB16f9ySA%3D&reserved=0?
> >>
> >> Gr{oetje,eeting}s,
> >>
> >> Geert
> >>
> > It is better to use of_dma_configure(&pdev->dev, np), it iommu support, device
> also can allocate memory from 64bit space.
>
> At first sight, it indeed looks like of_dma_configure() would do the right thing,
> even on platforms without DT like Coldfire.
>
> Unfortunately of_dma_configure() is replaced by a dummy if !CONFIG_OF.
>
> Gr{oetje,eeting}s,
>
> Geert
Yes, it only supports DT.
Andy
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] net: fec: set dma_coherent_mask
2018-03-27 12:59 ` Geert Uytterhoeven
2018-03-28 3:04 ` Andy Duan
@ 2018-03-28 7:27 ` Greg Ungerer
2018-03-28 7:57 ` Geert Uytterhoeven
1 sibling, 1 reply; 9+ messages in thread
From: Greg Ungerer @ 2018-03-28 7:27 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: netdev, Linux/m68k
Hi Geert,
On 27/03/18 22:59, Geert Uytterhoeven wrote:
> On Mon, Mar 26, 2018 at 3:36 PM, Greg Ungerer <gerg@linux-m68k.org> wrote:
>> As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
>> coherent_dma_mask") the Freescale FEC driver is issuing the following
>> warning on driver initialization on ColdFire systems:
>>
>> WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 0x40159e20
>> Modules linked in:
>> CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc7-dirty #4
>> Stack from 41833dd8:
>> 41833dd8 40259c53 40025534 40279e26 00000003 00000000 4004e514 41827000
>> 400255de 40244e42 00000204 40159e20 00000009 00000000 00000000 4024531d
>> 40159e20 40244e42 00000204 00000000 00000000 00000000 00000007 00000000
>> 00000000 40279e26 4028d040 40226576 4003ae88 40279e26 418273f6 41833ef8
>> 7fffffff 418273f2 41867028 4003c9a2 4180ac6c 00000004 41833f8c 4013e71c
>> 40279e1c 40279e26 40226c16 4013ced2 40279e26 40279e58 4028d040 00000000
>> Call Trace:
>> [<40025534>] 0x40025534
>> [<4004e514>] 0x4004e514
>> [<400255de>] 0x400255de
>> [<40159e20>] 0x40159e20
>> [<40159e20>] 0x40159e20
>>
>> It is not fatal, the driver and the system continue to function normally.
>>
>> As per the warning the coherent_dma_mask is not set on this device.
>> There is nothing special about the DMA memory coherency on this hardware
>> so we can just set the mask to 32bits during probe.
>>
>> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
>
> Thanks for your patch!
>
>> ---
>> drivers/net/ethernet/freescale/fec_main.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> Is this the best way to handle this problem?
>> Comments welcome...
>>
>> diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
>> index d4604bc..3cb130a 100644
>> --- a/drivers/net/ethernet/freescale/fec_main.c
>> +++ b/drivers/net/ethernet/freescale/fec_main.c
>> @@ -2702,6 +2702,8 @@ static int fec_enet_alloc_queue(struct net_device *ndev)
>> int ret = 0;
>> struct fec_enet_priv_tx_q *txq;
>>
>> + dma_set_coherent_mask(&fep->pdev->dev, DMA_BIT_MASK(32));
>> +
>> for (i = 0; i < fep->num_tx_queues; i++) {
>> txq = kzalloc(sizeof(*txq), GFP_KERNEL);
>> if (!txq) {
>
> As per your other email, this does not trigger on iMX systems using DT.
> Hence I'm wondering if the Coldfire platform code shouldn't just do the
> same what drivers/of/device.c does, cfr.
> https://www.spinics.net/lists/linux-m68k/msg10929.html?
I had been thinking that all along, but I couldn't see how to set this when
there was no real bus involved that would have configured this. Turns out
for platform devices you can set it as part of the platform setup. So now
the patch becomes specific to the ColdFire and FEC ethernet devices.
Regards
Greg
---
[PATCH] m68k: set dma and coherent masks for platform FEC ethernets
As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
coherent_dma_mask") the Freescale FEC driver is issuing the following
warning on driver initialization on ColdFire systems:
WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 0x40159e20
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc7-dirty #4
Stack from 41833dd8:
41833dd8 40259c53 40025534 40279e26 00000003 00000000 4004e514 41827000
400255de 40244e42 00000204 40159e20 00000009 00000000 00000000 4024531d
40159e20 40244e42 00000204 00000000 00000000 00000000 00000007 00000000
00000000 40279e26 4028d040 40226576 4003ae88 40279e26 418273f6 41833ef8
7fffffff 418273f2 41867028 4003c9a2 4180ac6c 00000004 41833f8c 4013e71c
40279e1c 40279e26 40226c16 4013ced2 40279e26 40279e58 4028d040 00000000
Call Trace:
[<40025534>] 0x40025534
[<4004e514>] 0x4004e514
[<400255de>] 0x400255de
[<40159e20>] 0x40159e20
[<40159e20>] 0x40159e20
It is not fatal, the driver and the system continue to function normally.
As per the warning the coherent_dma_mask is not set on this device.
There is nothing special about the DMA memory coherency on this hardware
so we can just set the mask to 32bits in the platform data for the FEC
ethernet devices.
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
---
arch/m68k/coldfire/device.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/m68k/coldfire/device.c b/arch/m68k/coldfire/device.c
index 84938fd..f93e0e5 100644
--- a/arch/m68k/coldfire/device.c
+++ b/arch/m68k/coldfire/device.c
@@ -130,12 +130,18 @@
},
};
+static u64 mcf_dma_mask = DMA_BIT_MASK(32);
+
static struct platform_device mcf_fec0 = {
.name = FEC_NAME,
.id = 0,
.num_resources = ARRAY_SIZE(mcf_fec0_resources),
.resource = mcf_fec0_resources,
- .dev.platform_data = FEC_PDATA,
+ .dev = {
+ .dma_mask = &mcf_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = FEC_PDATA,
+ }
};
#ifdef MCFFEC_BASE1
@@ -167,7 +173,11 @@
.id = 1,
.num_resources = ARRAY_SIZE(mcf_fec1_resources),
.resource = mcf_fec1_resources,
- .dev.platform_data = FEC_PDATA,
+ .dev = {
+ .dma_mask = &mcf_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = FEC_PDATA,
+ }
};
#endif /* MCFFEC_BASE1 */
#endif /* CONFIG_FEC */
--
1.9.1
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] net: fec: set dma_coherent_mask
2018-03-28 7:27 ` Greg Ungerer
@ 2018-03-28 7:57 ` Geert Uytterhoeven
2018-03-28 12:29 ` Greg Ungerer
0 siblings, 1 reply; 9+ messages in thread
From: Geert Uytterhoeven @ 2018-03-28 7:57 UTC (permalink / raw)
To: Greg Ungerer; +Cc: netdev, Linux/m68k
Hi Greg,
On Wed, Mar 28, 2018 at 9:27 AM, Greg Ungerer <gerg@linux-m68k.org> wrote:
> On 27/03/18 22:59, Geert Uytterhoeven wrote:
>> On Mon, Mar 26, 2018 at 3:36 PM, Greg Ungerer <gerg@linux-m68k.org> wrote:
>>> As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
>>> coherent_dma_mask") the Freescale FEC driver is issuing the following
>>> warning on driver initialization on ColdFire systems:
>>>
>>> WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 0x40159e20
>>> Modules linked in:
>>> CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc7-dirty #4
>>> Stack from 41833dd8:
>>> 41833dd8 40259c53 40025534 40279e26 00000003 00000000 4004e514 41827000
>>> 400255de 40244e42 00000204 40159e20 00000009 00000000 00000000 4024531d
>>> 40159e20 40244e42 00000204 00000000 00000000 00000000 00000007 00000000
>>> 00000000 40279e26 4028d040 40226576 4003ae88 40279e26 418273f6 41833ef8
>>> 7fffffff 418273f2 41867028 4003c9a2 4180ac6c 00000004 41833f8c 4013e71c
>>> 40279e1c 40279e26 40226c16 4013ced2 40279e26 40279e58 4028d040 00000000
>>> Call Trace:
>>> [<40025534>] 0x40025534
>>> [<4004e514>] 0x4004e514
>>> [<400255de>] 0x400255de
>>> [<40159e20>] 0x40159e20
>>> [<40159e20>] 0x40159e20
>>>
>>> It is not fatal, the driver and the system continue to function normally.
>>>
>>> As per the warning the coherent_dma_mask is not set on this device.
>>> There is nothing special about the DMA memory coherency on this hardware
>>> so we can just set the mask to 32bits during probe.
>>>
>>> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
>>
>> Thanks for your patch!
>>
>>> ---
>>> drivers/net/ethernet/freescale/fec_main.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> Is this the best way to handle this problem?
>>> Comments welcome...
>>>
>>> diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
>>> index d4604bc..3cb130a 100644
>>> --- a/drivers/net/ethernet/freescale/fec_main.c
>>> +++ b/drivers/net/ethernet/freescale/fec_main.c
>>> @@ -2702,6 +2702,8 @@ static int fec_enet_alloc_queue(struct net_device *ndev)
>>> int ret = 0;
>>> struct fec_enet_priv_tx_q *txq;
>>>
>>> + dma_set_coherent_mask(&fep->pdev->dev, DMA_BIT_MASK(32));
>>> +
>>> for (i = 0; i < fep->num_tx_queues; i++) {
>>> txq = kzalloc(sizeof(*txq), GFP_KERNEL);
>>> if (!txq) {
>>
>> As per your other email, this does not trigger on iMX systems using DT.
>> Hence I'm wondering if the Coldfire platform code shouldn't just do the
>> same what drivers/of/device.c does, cfr.
>> https://www.spinics.net/lists/linux-m68k/msg10929.html?
>
> I had been thinking that all along, but I couldn't see how to set this when
> there was no real bus involved that would have configured this. Turns out
> for platform devices you can set it as part of the platform setup. So now
> the patch becomes specific to the ColdFire and FEC ethernet devices.
>
> Regards
> Greg
>
> ---
>
> [PATCH] m68k: set dma and coherent masks for platform FEC ethernets
>
> As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
> coherent_dma_mask") the Freescale FEC driver is issuing the following
> warning on driver initialization on ColdFire systems:
>
> WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 0x40159e20
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc7-dirty #4
> Stack from 41833dd8:
> 41833dd8 40259c53 40025534 40279e26 00000003 00000000 4004e514 41827000
> 400255de 40244e42 00000204 40159e20 00000009 00000000 00000000 4024531d
> 40159e20 40244e42 00000204 00000000 00000000 00000000 00000007 00000000
> 00000000 40279e26 4028d040 40226576 4003ae88 40279e26 418273f6 41833ef8
> 7fffffff 418273f2 41867028 4003c9a2 4180ac6c 00000004 41833f8c 4013e71c
> 40279e1c 40279e26 40226c16 4013ced2 40279e26 40279e58 4028d040 00000000
> Call Trace:
> [<40025534>] 0x40025534
> [<4004e514>] 0x4004e514
> [<400255de>] 0x400255de
> [<40159e20>] 0x40159e20
> [<40159e20>] 0x40159e20
>
> It is not fatal, the driver and the system continue to function normally.
>
> As per the warning the coherent_dma_mask is not set on this device.
> There is nothing special about the DMA memory coherency on this hardware
> so we can just set the mask to 32bits in the platform data for the FEC
> ethernet devices.
>
> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
> ---
> arch/m68k/coldfire/device.c | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/arch/m68k/coldfire/device.c b/arch/m68k/coldfire/device.c
> index 84938fd..f93e0e5 100644
> --- a/arch/m68k/coldfire/device.c
> +++ b/arch/m68k/coldfire/device.c
> @@ -130,12 +130,18 @@
> },
> };
>
> +static u64 mcf_dma_mask = DMA_BIT_MASK(32);
> +
> static struct platform_device mcf_fec0 = {
> .name = FEC_NAME,
> .id = 0,
> .num_resources = ARRAY_SIZE(mcf_fec0_resources),
> .resource = mcf_fec0_resources,
> - .dev.platform_data = FEC_PDATA,
> + .dev = {
> + .dma_mask = &mcf_dma_mask,
Can you make this &mcf_fec0.dev.coherent_dma_mask, removing the need for
mcf_dma_mask, or doesn't C allow that?
> + .coherent_dma_mask = DMA_BIT_MASK(32),
> + .platform_data = FEC_PDATA,
> + }
> };
>
> #ifdef MCFFEC_BASE1
> @@ -167,7 +173,11 @@
> .id = 1,
> .num_resources = ARRAY_SIZE(mcf_fec1_resources),
> .resource = mcf_fec1_resources,
> - .dev.platform_data = FEC_PDATA,
> + .dev = {
> + .dma_mask = &mcf_dma_mask,
Likewise.
> + .coherent_dma_mask = DMA_BIT_MASK(32),
> + .platform_data = FEC_PDATA,
> + }
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] net: fec: set dma_coherent_mask
2018-03-28 7:57 ` Geert Uytterhoeven
@ 2018-03-28 12:29 ` Greg Ungerer
0 siblings, 0 replies; 9+ messages in thread
From: Greg Ungerer @ 2018-03-28 12:29 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: netdev, Linux/m68k
Hi Geert,
On 28/03/18 17:57, Geert Uytterhoeven wrote:
[skip]
>> [PATCH] m68k: set dma and coherent masks for platform FEC ethernets
>>
>> As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
>> coherent_dma_mask") the Freescale FEC driver is issuing the following
>> warning on driver initialization on ColdFire systems:
>>
>> WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 0x40159e20
>> Modules linked in:
>> CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc7-dirty #4
>> Stack from 41833dd8:
>> 41833dd8 40259c53 40025534 40279e26 00000003 00000000 4004e514 41827000
>> 400255de 40244e42 00000204 40159e20 00000009 00000000 00000000 4024531d
>> 40159e20 40244e42 00000204 00000000 00000000 00000000 00000007 00000000
>> 00000000 40279e26 4028d040 40226576 4003ae88 40279e26 418273f6 41833ef8
>> 7fffffff 418273f2 41867028 4003c9a2 4180ac6c 00000004 41833f8c 4013e71c
>> 40279e1c 40279e26 40226c16 4013ced2 40279e26 40279e58 4028d040 00000000
>> Call Trace:
>> [<40025534>] 0x40025534
>> [<4004e514>] 0x4004e514
>> [<400255de>] 0x400255de
>> [<40159e20>] 0x40159e20
>> [<40159e20>] 0x40159e20
>>
>> It is not fatal, the driver and the system continue to function normally.
>>
>> As per the warning the coherent_dma_mask is not set on this device.
>> There is nothing special about the DMA memory coherency on this hardware
>> so we can just set the mask to 32bits in the platform data for the FEC
>> ethernet devices.
>>
>> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
>> ---
>> arch/m68k/coldfire/device.c | 14 ++++++++++++--
>> 1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/m68k/coldfire/device.c b/arch/m68k/coldfire/device.c
>> index 84938fd..f93e0e5 100644
>> --- a/arch/m68k/coldfire/device.c
>> +++ b/arch/m68k/coldfire/device.c
>> @@ -130,12 +130,18 @@
>> },
>> };
>>
>> +static u64 mcf_dma_mask = DMA_BIT_MASK(32);
>> +
>> static struct platform_device mcf_fec0 = {
>> .name = FEC_NAME,
>> .id = 0,
>> .num_resources = ARRAY_SIZE(mcf_fec0_resources),
>> .resource = mcf_fec0_resources,
>> - .dev.platform_data = FEC_PDATA,
>> + .dev = {
>> + .dma_mask = &mcf_dma_mask,
>
> Can you make this &mcf_fec0.dev.coherent_dma_mask, removing the need for
> mcf_dma_mask, or doesn't C allow that?
Yes, sure can. Looks like some other architectures do that too.
I'll change it. Thanks.
Regards
Greg
>> + .coherent_dma_mask = DMA_BIT_MASK(32),
>> + .platform_data = FEC_PDATA,
>> + }
>> };
>>
>> #ifdef MCFFEC_BASE1
>> @@ -167,7 +173,11 @@
>> .id = 1,
>> .num_resources = ARRAY_SIZE(mcf_fec1_resources),
>> .resource = mcf_fec1_resources,
>> - .dev.platform_data = FEC_PDATA,
>> + .dev = {
>> + .dma_mask = &mcf_dma_mask,
>
> Likewise.
>
>> + .coherent_dma_mask = DMA_BIT_MASK(32),
>> + .platform_data = FEC_PDATA,
>> + }
>
> Gr{oetje,eeting}s,
>
> Geert
>
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2018-03-28 12:29 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-26 13:36 [PATCH] net: fec: set dma_coherent_mask Greg Ungerer
2018-03-27 12:59 ` Geert Uytterhoeven
2018-03-28 3:04 ` Andy Duan
2018-03-28 7:06 ` Geert Uytterhoeven
2018-03-28 7:15 ` Andy Duan
2018-03-28 7:27 ` Greg Ungerer
2018-03-28 7:57 ` Geert Uytterhoeven
2018-03-28 12:29 ` Greg Ungerer
2018-03-27 13:24 ` Lino Sanfilippo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).