mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Linus Walleij <linus.walleij@linaro.org>,
	kernel test robot <lkp@intel.com>,
	"linuxppc-dev@lists.ozlabs.org list"
	<linuxppc-dev@lists.ozlabs.org>, netdev <netdev@vger.kernel.org>
Cc: Stanislav Kinsburskii <stanislav.kinsburskii@gmail.com>,
	oe-kbuild-all@lists.linux.dev, linux-kernel@vger.kernel.org,
	Michael Ellerman <mpe@ellerman.id.au>
Subject: Re: drivers/net/ethernet/freescale/ucc_geth.c:2454:64: sparse: sparse: incorrect type in argument 1 (different address spaces)
Date: Fri, 8 Nov 2024 11:30:00 +0100	[thread overview]
Message-ID: <2010cc7a-7f49-4c5b-b684-8e08ff8d17ed@csgroup.eu> (raw)
In-Reply-To: <CACRpkdbW5kheaWPzKip9ucEwK2uv+Cmf5SwT1necfa3Ynct6Ag@mail.gmail.com>



Le 08/11/2024 à 09:18, Linus Walleij a écrit :
> On Wed, Oct 30, 2024 at 8:05 AM kernel test robot <lkp@intel.com> wrote:
> 
>> tree:   https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C5a1ff6cef1f642fba00a08dcffce0903%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638666507603442752%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2dgpku3%2BPjovwZxpedYowAAB%2BR%2FeyxOc0Ys3kE0KK6E%3D&reserved=0 master
>> head:   c1e939a21eb111a6d6067b38e8e04b8809b64c4e
>> commit: b28d1ccf921a4333be14017d82066386d419e638 powerpc/io: Expect immutable pointer in virt_to_phys() prototype
> 
> Ugh Stanislav do you have ideas around this one?
> 
>>     drivers/net/ethernet/freescale/ucc_geth.c:244:21: sparse:     got restricted __be32 [noderef] __iomem *
>>     drivers/net/ethernet/freescale/ucc_geth.c:405:22: sparse: sparse: incorrect type in argument 1 (different base types) @@     expected unsigned short volatile [noderef] [usertype] __iomem *addr @@     got restricted __be16 [noderef] [usertype] __iomem * @@
> 
> They all look the same, it's from this:
> 
> static void set_mac_addr(__be16 __iomem *reg, u8 *mac)
> {
>      out_be16(&reg[0], ((u16)mac[5] << 8) | mac[4]);
>      out_be16(&reg[1], ((u16)mac[3] << 8) | mac[2]);
>      out_be16(&reg[2], ((u16)mac[1] << 8) | mac[0]);
> }
> 
> Is it simply that we need a paranthesis extra around the thing casted
> to (u16) else it becomes u32?

Not at all. The one you point here are:

drivers/net/ethernet/freescale/ucc_geth.c:405:22: warning: incorrect 
type in argument 1 (different base types)
drivers/net/ethernet/freescale/ucc_geth.c:405:22:    expected unsigned 
short volatile [noderef] [usertype] __iomem *addr
drivers/net/ethernet/freescale/ucc_geth.c:405:22:    got restricted 
__be16 [noderef] [usertype] __iomem *
drivers/net/ethernet/freescale/ucc_geth.c:406:22: warning: incorrect 
type in argument 1 (different base types)
drivers/net/ethernet/freescale/ucc_geth.c:406:22:    expected unsigned 
short volatile [noderef] [usertype] __iomem *addr
drivers/net/ethernet/freescale/ucc_geth.c:406:22:    got restricted 
__be16 [noderef] [usertype] __iomem *
drivers/net/ethernet/freescale/ucc_geth.c:407:22: warning: incorrect 
type in argument 1 (different base types)
drivers/net/ethernet/freescale/ucc_geth.c:407:22:    expected unsigned 
short volatile [noderef] [usertype] __iomem *addr
drivers/net/ethernet/freescale/ucc_geth.c:407:22:    got restricted 
__be16 [noderef] [usertype] __iomem *
drivers/net/ethernet/freescale/ucc_geth.c:449:23: warning: incorrect 
type in argument 1 (different base types)
drivers/net/ethernet/freescale/ucc_geth.c:449:23:    expected restricted 
__be16 [noderef] [usertype] __iomem *reg
drivers/net/ethernet/freescale/ucc_geth.c:449:23:    got unsigned short 
[noderef] __iomem *

The problem is the __be16 in the function prototype.

	set_mac_addr(&p_82xx_addr_filt->taddr.h, p_enet_addr);

p_82xx_addr_filt->taddr.h is a u16
and out_be16() expects a u16*

So the following fixes the above warnings:

diff --git a/drivers/net/ethernet/freescale/ucc_geth.c 
b/drivers/net/ethernet/freescale/ucc_geth.c
index ab421243a419..bbfc289dd73c 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -400,7 +400,7 @@ static void put_enet_addr_container(struct 
enet_addr_container *enet_addr_cont)
  	kfree(enet_addr_cont);
  }

-static void set_mac_addr(__be16 __iomem *reg, u8 *mac)
+static void set_mac_addr(u16 __iomem *reg, u8 *mac)
  {
  	out_be16(&reg[0], ((u16)mac[5] << 8) | mac[4]);
  	out_be16(&reg[1], ((u16)mac[3] << 8) | mac[2]);



For the other ones, most of them are because out_beXX() expects uXX* not 
__beXX *.

It looks like the warnings go away if you replace out_be32() by 
iowrite32be(), which has been possible since commit 894fa235eb4c 
("powerpc: inline iomap accessors") (out_beXX/in_beXX should anyway not 
be used outside arch/powerpc/):

diff --git a/drivers/net/ethernet/freescale/ucc_geth.c 
b/drivers/net/ethernet/freescale/ucc_geth.c
index ab421243a419..625b58b3efc8 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -241,12 +241,12 @@ static struct sk_buff *get_new_skb(struct 
ucc_geth_private *ugeth,
  		    (((unsigned)skb->data) & (UCC_GETH_RX_DATA_BUF_ALIGNMENT -
  					      1)));

-	out_be32(&((struct qe_bd __iomem *)bd)->buf,
+	iowrite32be(
  		      dma_map_single(ugeth->dev,
  				     skb->data,
  				     ugeth->ug_info->uf_info.max_rx_buf_length +
  				     UCC_GETH_RX_DATA_BUF_ALIGNMENT,
-				     DMA_FROM_DEVICE));
+				     DMA_FROM_DEVICE), &((struct qe_bd __iomem *)bd)->buf);

  	out_be32((u32 __iomem *)bd,
  			(R_E | R_I | (in_be32((u32 __iomem*)bd) & R_W)));


Christophe

  reply	other threads:[~2024-11-08 10:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-30  7:04 kernel test robot
2024-11-08  8:18 ` Linus Walleij
2024-11-08 10:30   ` Christophe Leroy [this message]
2024-11-08 11:17     ` Christophe Leroy
2024-11-08 11:41     ` Linus Walleij
  -- strict thread matches above, loose matches on Subject: below --
2024-09-07 13:57 kernel test robot
2023-11-24  7:56 kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2010cc7a-7f49-4c5b-b684-8e08ff8d17ed@csgroup.eu \
    --to=christophe.leroy@csgroup.eu \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lkp@intel.com \
    --cc=mpe@ellerman.id.au \
    --cc=netdev@vger.kernel.org \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=stanislav.kinsburskii@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®