linux.git/drivers/net/ethernet/apple, branch v6.8 Linux kernel source tree net: ethernet: apple: Convert to platform remove callback returning void 2023-09-20T08:06:37+00:00 Uwe Kleine-König u.kleine-koenig@pengutronix.de 2023-09-18T20:41:40+00:00 e5d0a380b2b470cee8c9af59a3dca2e2d9646b36 The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net> 
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() is renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
net/macmace: Replace zero-length array with DECLARE_FLEX_ARRAY() helper 2023-08-01T21:46:21+00:00 Atul Raut rauji.raut@gmail.com 2023-07-30T23:14:42+00:00 005c9600003eabcb22336f37e149eed08f0a946a Since zero-length arrays are deprecated, we are replacing them with C99 flexible-array members. As a result, instead of declaring a zero-length array, use the new DECLARE_FLEX_ARRAY() helper macro. This fixes warnings such as: ./drivers/net/ethernet/apple/macmace.c:80:4-8: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays) Signed-off-by: Atul Raut <rauji.raut@gmail.com> Link: https://lore.kernel.org/r/20230730231442.15003-1-rauji.raut@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
Since zero-length arrays are deprecated, we are replacing
them with C99 flexible-array members. As a result, instead
of declaring a zero-length array, use the new
DECLARE_FLEX_ARRAY() helper macro.

This fixes warnings such as:
./drivers/net/ethernet/apple/macmace.c:80:4-8: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays)

Signed-off-by: Atul Raut <rauji.raut@gmail.com>
Link: https://lore.kernel.org/r/20230730231442.15003-1-rauji.raut@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: apple: bmac: don't call dev_kfree_skb() under spin_lock_irqsave() 2022-12-12T09:53:10+00:00 Yang Yingliang yangyingliang@huawei.com 2022-12-08T13:37:35+00:00 5fe02e046e6422c4adfdbc50206ec7186077da24 It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with hardware interrupts being disabled. It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead. The difference between them is free reason, dev_kfree_skb_irq() means the SKB is dropped in error and dev_consume_skb_irq() means the SKB is consumed in normal. In this case, dev_kfree_skb() is called in bmac_tx_timeout() to drop the SKB, when tx timeout, so replace it with dev_kfree_skb_irq(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
It is not allowed to call kfree_skb() or consume_skb() from hardware
interrupt context or with hardware interrupts being disabled.

It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead.
The difference between them is free reason, dev_kfree_skb_irq() means
the SKB is dropped in error and dev_consume_skb_irq() means the SKB
is consumed in normal.

In this case, dev_kfree_skb() is called in bmac_tx_timeout() to drop
the SKB, when tx timeout, so replace it with dev_kfree_skb_irq().

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: apple: mace: don't call dev_kfree_skb() under spin_lock_irqsave() 2022-12-12T09:53:10+00:00 Yang Yingliang yangyingliang@huawei.com 2022-12-08T13:37:34+00:00 3dfe3486c1cd4f82b466b7d307f23777137b8acc It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with hardware interrupts being disabled. It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead. The difference between them is free reason, dev_kfree_skb_irq() means the SKB is dropped in error and dev_consume_skb_irq() means the SKB is consumed in normal. In this case, dev_kfree_skb() is called in mace_tx_timeout() to drop the SKB, when tx timeout, so replace it with dev_kfree_skb_irq(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net> 
It is not allowed to call kfree_skb() or consume_skb() from hardware
interrupt context or with hardware interrupts being disabled.

It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead.
The difference between them is free reason, dev_kfree_skb_irq() means
the SKB is dropped in error and dev_consume_skb_irq() means the SKB
is consumed in normal.

In this case, dev_kfree_skb() is called in mace_tx_timeout() to drop
the SKB, when tx timeout, so replace it with dev_kfree_skb_irq().

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: ethernet: Prepare cleanup of powerpc's asm/prom.h 2022-05-05T22:53:02+00:00 Christophe Leroy christophe.leroy@csgroup.eu 2022-05-04T11:32:17+00:00 6bff3ffcf6eed522cfc302e2d934b9a875d20cd2 powerpc's asm/prom.h includes some headers that it doesn't need itself. In order to clean powerpc's asm/prom.h up in a further step, first clean all files that include asm/prom.h Some files don't need asm/prom.h at all. For those ones, just remove inclusion of asm/prom.h Some files don't need any of the items provided by asm/prom.h, but need some of the headers included by asm/prom.h. For those ones, add the needed headers that are brought by asm/prom.h at the moment and remove asm/prom.h Some files really need asm/prom.h but also need some of the headers included by asm/prom.h. For those one, leave asm/prom.h but also add the needed headers so that they can be removed from asm/prom.h in a later step. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Link: https://lore.kernel.org/r/09a13d592d628de95d30943e59b2170af5b48110.1651663857.git.christophe.leroy@csgroup.eu Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
powerpc's asm/prom.h includes some headers that it doesn't
need itself.

In order to clean powerpc's asm/prom.h up in a further step,
first clean all files that include asm/prom.h

Some files don't need asm/prom.h at all. For those ones,
just remove inclusion of asm/prom.h

Some files don't need any of the items provided by asm/prom.h,
but need some of the headers included by asm/prom.h. For those
ones, add the needed headers that are brought by asm/prom.h at
the moment and remove asm/prom.h

Some files really need asm/prom.h but also need some of the
headers included by asm/prom.h. For those one, leave asm/prom.h
but also add the needed headers so that they can be removed
from asm/prom.h in a later step.

Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/09a13d592d628de95d30943e59b2170af5b48110.1651663857.git.christophe.leroy@csgroup.eu
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: apple: bmac: Fix build since dev_addr constification 2022-01-14T11:22:57+00:00 Michael Ellerman mpe@ellerman.id.au 2022-01-14T03:13:16+00:00 ea938248557a52e231a31f338eac4baee36a8626 Since commit adeef3e32146 ("net: constify netdev->dev_addr") the bmac driver no longer builds with the following errors (pmac32_defconfig): linux/drivers/net/ethernet/apple/bmac.c: In function ‘bmac_probe’: linux/drivers/net/ethernet/apple/bmac.c:1287:20: error: assignment of read-only location ‘*(dev->dev_addr + (sizetype)j)’ 1287 | dev->dev_addr[j] = rev ? bitrev8(addr[j]): addr[j]; | ^ Fix it by making the modifications to a local macaddr variable and then passing that to eth_hw_addr_set(). We don't use the existing addr variable because the bitrev8() would mutate it, but it is already used unreversed later in the function. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
Since commit adeef3e32146 ("net: constify netdev->dev_addr") the bmac
driver no longer builds with the following errors (pmac32_defconfig):

  linux/drivers/net/ethernet/apple/bmac.c: In function ‘bmac_probe’:
  linux/drivers/net/ethernet/apple/bmac.c:1287:20: error: assignment of read-only location ‘*(dev->dev_addr + (sizetype)j)’
   1287 |   dev->dev_addr[j] = rev ? bitrev8(addr[j]): addr[j];
        |                    ^

Fix it by making the modifications to a local macaddr variable and then
passing that to eth_hw_addr_set().

We don't use the existing addr variable because the bitrev8() would
mutate it, but it is already used unreversed later in the function.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: apple: mace: Fix build since dev_addr constification 2022-01-14T11:22:57+00:00 Michael Ellerman mpe@ellerman.id.au 2022-01-14T03:12:52+00:00 6c8dc12cd925e5fa8c152633338b2b35c4c89258 Since commit adeef3e32146 ("net: constify netdev->dev_addr") the mace driver no longer builds with various errors (pmac32_defconfig): linux/drivers/net/ethernet/apple/mace.c: In function ‘mace_probe’: linux/drivers/net/ethernet/apple/mace.c:170:20: error: assignment of read-only location ‘*(dev->dev_addr + (sizetype)j)’ 170 | dev->dev_addr[j] = rev ? bitrev8(addr[j]): addr[j]; | ^ linux/drivers/net/ethernet/apple/mace.c: In function ‘mace_reset’: linux/drivers/net/ethernet/apple/mace.c:349:32: warning: passing argument 2 of ‘__mace_set_address’ discards ‘const’ qualifier from pointer target type 349 | __mace_set_address(dev, dev->dev_addr); | ~~~^~~~~~~~~~ linux/drivers/net/ethernet/apple/mace.c:93:62: note: expected ‘void *’ but argument is of type ‘const unsigned char *’ 93 | static void __mace_set_address(struct net_device *dev, void *addr); | ~~~~~~^~~~ linux/drivers/net/ethernet/apple/mace.c: In function ‘__mace_set_address’: linux/drivers/net/ethernet/apple/mace.c:388:36: error: assignment of read-only location ‘*(dev->dev_addr + (sizetype)i)’ 388 | out_8(&mb->padr, dev->dev_addr[i] = p[i]); | ^ Fix it by making the modifications to a local macaddr variable and then passing that to eth_hw_addr_set(), as well as adding some missing const qualifiers. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
Since commit adeef3e32146 ("net: constify netdev->dev_addr") the mace
driver no longer builds with various errors (pmac32_defconfig):

  linux/drivers/net/ethernet/apple/mace.c: In function ‘mace_probe’:
  linux/drivers/net/ethernet/apple/mace.c:170:20: error: assignment of read-only location ‘*(dev->dev_addr + (sizetype)j)’
    170 |   dev->dev_addr[j] = rev ? bitrev8(addr[j]): addr[j];
        |                    ^
  linux/drivers/net/ethernet/apple/mace.c: In function ‘mace_reset’:
  linux/drivers/net/ethernet/apple/mace.c:349:32: warning: passing argument 2 of ‘__mace_set_address’ discards ‘const’ qualifier from pointer target type
    349 |     __mace_set_address(dev, dev->dev_addr);
        |                             ~~~^~~~~~~~~~
  linux/drivers/net/ethernet/apple/mace.c:93:62: note: expected ‘void *’ but argument is of type ‘const unsigned char *’
     93 | static void __mace_set_address(struct net_device *dev, void *addr);
        |                                                        ~~~~~~^~~~
  linux/drivers/net/ethernet/apple/mace.c: In function ‘__mace_set_address’:
  linux/drivers/net/ethernet/apple/mace.c:388:36: error: assignment of read-only location ‘*(dev->dev_addr + (sizetype)i)’
    388 |  out_8(&mb->padr, dev->dev_addr[i] = p[i]);
        |                                    ^

Fix it by making the modifications to a local macaddr variable and then
passing that to eth_hw_addr_set(), as well as adding some missing const
qualifiers.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
apple: macmace: use eth_hw_addr_set() 2021-11-19T11:05:21+00:00 Jakub Kicinski kuba@kernel.org 2021-11-19T07:10:31+00:00 e217fc4affc8c7392e4db48488b36d2a5d446e9d Byte by byte assignments. Fixes build on m68k. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
Byte by byte assignments.

Fixes build on m68k.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
ethernet: replace netdev->dev_addr assignment loops 2021-10-14T16:22:25+00:00 Jakub Kicinski kuba@kernel.org 2021-10-13T20:44:34+00:00 562ef98a666eef8e32a6057af37a577163ab6946 A handful of drivers contains loops assigning the mac addr byte by byte. Convert those to eth_hw_addr_set(). Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
A handful of drivers contains loops assigning the mac
addr byte by byte. Convert those to eth_hw_addr_set().

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ethernet: constify references to netdev->dev_addr in drivers 2021-10-14T16:22:11+00:00 Jakub Kicinski kuba@kernel.org 2021-10-14T14:24:31+00:00 766607570becbd26cab6d66a544dd8d0d964df5a This big patch sprinkles const on local variables and function arguments which may refer to netdev->dev_addr. Commit 406f42fa0d3c ("net-next: When a bond have a massive amount of VLANs...") introduced a rbtree for faster Ethernet address look up. To maintain netdev->dev_addr in this tree we need to make all the writes to it got through appropriate helpers. Some of the changes here are not strictly required - const is sometimes cast off but pointer is not used for writing. It seems like it's still better to add the const in case the code changes later or relevant -W flags get enabled for the build. No functional changes. Link: https://lore.kernel.org/r/20211014142432.449314-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
This big patch sprinkles const on local variables and
function arguments which may refer to netdev->dev_addr.

Commit 406f42fa0d3c ("net-next: When a bond have a massive amount
of VLANs...") introduced a rbtree for faster Ethernet address look
up. To maintain netdev->dev_addr in this tree we need to make all
the writes to it got through appropriate helpers.

Some of the changes here are not strictly required - const
is sometimes cast off but pointer is not used for writing.
It seems like it's still better to add the const in case
the code changes later or relevant -W flags get enabled
for the build.

No functional changes.

Link: https://lore.kernel.org/r/20211014142432.449314-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>