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

[Christophe Leroy]

Le 08/11/2024 à 11:30, Christophe Leroy a écrit :
> Le 08/11/2024 à 09:18, Linus Walleij a écrit :
> > On Wed, Oct 30, 2024 at 8:05 AM kernel test robot <lkp@xxxxxxxxx> 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:

...

Note however that there is work in progress on this driver that will 
impact hundreds of lines, so maybe wait until that is done ? See 
https://patchwork.kernel.org/project/netdevbpf/cover/20241107170255.1058124-1-maxime.chevallier@xxxxxxxxxxx/

Christophe