linux-kernel - Re: drivers/net/ethernet/freescale/ucc_geth.c:2454:64: sparse: sparse: incorrect type in argument 1 (different address spaces)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRpkdbW5kheaWPzKip9ucEwK2uv+Cmf5SwT1necfa3Ynct6Ag@mail.gmail.com>
Date: Fri, 8 Nov 2024 09:18:45 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: kernel test robot <lkp@...el.com>, 
	"linuxppc-dev@...ts.ozlabs.org list" <linuxppc-dev@...ts.ozlabs.org>, netdev <netdev@...r.kernel.org>
Cc: Stanislav Kinsburskii <stanislav.kinsburskii@...il.com>, oe-kbuild-all@...ts.linux.dev, 
	linux-kernel@...r.kernel.org, Michael Ellerman <mpe@...erman.id.au>
Subject: Re: drivers/net/ethernet/freescale/ucc_geth.c:2454:64: sparse:
 sparse: incorrect type in argument 1 (different address spaces)

On Wed, Oct 30, 2024 at 8:05 AM kernel test robot <lkp@...el.com> wrote:

> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 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?

I.e. change:

out_be16(&reg[0], ((u16)mac[5] << 8) | mac[4]);

to:

out_be16(&reg[0], ((u16)(mac[5] << 8) | mac[4]));

everywhere in this driver?

In that case it's a straight-forward fix (and the code is buggy to begin with).

Yours,
Linus Walleij