> > Has anyone tried compiling the out-of-tree kernel network software
> > for the 'ice' driver on 32 bit i386? I tried it for the
> > long-term-support 5.10.197 kernel and got these compile time errors:
>
> Are those regressions?
> Have you tried 1.12.x?
> We will also soon release also 1.13.x

I just tried 1.11.14, 1.11.17.1, and 1.12.7. They all had similar
compile failures.

 > $ make ARCH=i386 CFLAGS_EXTRA="-DGNSS_SUPPORT"
> > make  ccflags-y="-DGNSS_SUPPORT -DUSE_INTEL_AUX_BUS" -C
> > "/lib/modules/5.10.197.i686-pentium4-mpentium4-lenovo/source"
> > CONFIG_ICE=m CONFIG_MODULE_SIG=n CONFIG_MODULE_SIG_ALL=
> > M="/tmp/ice-1.11.14/src"   NEED_AUX_BUS="2"  modules
> >    CC [M]  /tmp/ice-1.11.14/src/ice_main.o
> > In file included from /tmp/ice-1.11.14/src/kcompat.h:3351,
> >                   from /tmp/ice-1.11.14/src/ice.h:7,
> >                   from /tmp/ice-1.11.14/src/ice_main.c:8:
> > /tmp/ice-1.11.14/src/kcompat_impl.h:851:20: error: redefinition of
> > ‘eth_hw_addr_set’
> >    851 | static inline void eth_hw_addr_set(struct net_device *dev,
> > const u8 *addr)
> >        |                    ^~~~~~~~~~~~~~~
> > In file included from /tmp/ice-1.11.14/src/kcompat.h:16:
> > ./include/linux/etherdevice.h:309:20: note: previous definition of
> > ‘eth_hw_addr_set’ with type ‘void(struct net_device *, const u8 *)’
> > {aka ‘void(struct net_device *, const unsigned char *)’}
> >    309 | static inline void eth_hw_addr_set(struct net_device *dev,
> > const u8 *addr)
>
> That particular thing could be rather easily solved,
> for official fix, 1.14 would be the earliest, but let me know how it
> works with 1.12.x so I could prepare some patch for you.
>
> >        |                    ^~~~~~~~~~~~~~~
> > In file included from ./include/linux/bits.h:6,
> >                   from ./include/linux/bitops.h:5,
> >                   from ./include/linux/kernel.h:12,
> >                   from ./include/asm-generic/bug.h:20,
> >                   from ./arch/x86/include/asm/bug.h:93,
> >                   from ./include/linux/bug.h:5,
> >                   from ./include/linux/io.h:11,
> >                   from /tmp/ice-1.11.14/src/kcompat.h:13:
> > /tmp/ice-1.11.14/src/ice_main.c: In function ‘ice_pf_fwlog_is_input_valid’:
> > ./include/vdso/bits.h:7:40: warning: left shift count >= width of type
> > [-Wshift-count-overflow]
> >      7 | #define BIT(nr)                 (UL(1) << (nr))
> >        |                                        ^~
> > /tmp/ice-1.11.14/src/ice_main.c:5992:23: note: in expansion of macro ‘BIT’
> >   5992 |         if (events >= BIT(ICE_AQC_FW_LOG_ID_MAX)) {
> >        |                       ^~~
> > ./include/vdso/bits.h:7:40: warning: left shift count >= width of type
> > [-Wshift-count-overflow]
> >      7 | #define BIT(nr)                 (UL(1) << (nr))
> >        |                                        ^~
> > ./include/linux/dev_printk.h:112:39: note: in expansion of macro ‘BIT’
> >    112 |         _dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__)
> >        |                                       ^~~~~~~~~~~
> > /tmp/ice-1.11.14/src/ice_main.c:5993:17: note: in expansion of macro 
> > ‘dev_err’
> >   5993 |                 dev_err(ice_pf_to_dev(pf), "Invalid FW log
> > events 0x%lx, all FW log event bits >= 0x%lx are invalid\n",
> >        |                 ^~~~~~~
> > make[2]: *** [scripts/Makefile.build:286:
> > /tmp/ice-1.11.14/src/ice_main.o] Error 1
> > make[1]: *** [Makefile:1832: /tmp/ice-1.11.14/src] Error 2
> > make: *** [Makefile:149: all] Error 2
> >
> > I know 32bit is officially unsupported, but it seems like it should
> > not break the compile this badly.
>
> I would say it's better to fail at that stage that render out-of-bound
> writes or other errors.
>
> looks like Intel OOT BIT() macro assumes 64bit arch, perhaps this could
> be fixed in general, but I'm not promising anything here.
>

Maybe they should declare the variable as u64 instead of unsigned
long? The macro BIT in include/vdso/bits.h is defined as:

#define BIT(nr) (UL(1) << (nr))

So you get whatever an unsigned long is per architecture, which
obviously varies.

- Matthew
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

Reply via email to