6:10 p.m.
On Thu, Sep 17, 2020 at 11:10 PM kernel test robot <lkp(a)intel.com> wrote:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head: 860461e4fcaa76200d2d1a53523e0ff7be92e6e8
commit: 98c2922ec8f0601321428be8c59ae1df255478d1 [1797/8629] ARM: s3c24xx: simplify
mach/io.h
config: arm-randconfig-s031-20200917 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-201-g24bdaac6-dirty
git checkout 98c2922ec8f0601321428be8c59ae1df255478d1
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp(a)intel.com>
sparse warnings: (new ones prefixed by >>)
drivers/tty/ipwireless/hardware.c:431:25: sparse: sparse: cast from restricted __le16
drivers/tty/ipwireless/hardware.c:445:25: sparse: sparse: cast from restricted __le16
>> drivers/tty/ipwireless/hardware.c:872:43: sparse: sparse: incorrect type in
initializer (different base types) @@ expected restricted __le16 [usertype] raw_data
@@ got unsigned short [usertype] __v @@
drivers/tty/ipwireless/hardware.c:872:43: sparse: expected restricted __le16
[usertype] raw_data
>> drivers/tty/ipwireless/hardware.c:872:43: sparse: got unsigned short
[usertype] __v
drivers/tty/ipwireless/hardware.c:889:43: sparse: sparse: incorrect type in
initializer (different base types) @@ expected restricted __le16 [usertype] raw_data
@@ got unsigned short [usertype] __v @@
drivers/tty/ipwireless/hardware.c:889:43: sparse: expected restricted __le16
[usertype] raw_data
drivers/tty/ipwireless/hardware.c:889:43: sparse: got unsigned short [usertype]
__v
I think it's a preexisting bug that we already get a warning for in other
configurations, now the same warning also appears on s3c24xx.
The bug was already in the original merge of the driver:
+ for (i = 0; i < len; i += 2) {
+ __le16 raw_data = inw(hw->base_port + IODMADPR);
+ unsigned short data = le16_to_cpu(raw_data);
+
+ pkt[i] = (unsigned char) data;
+ pkt[i + 1] = (unsigned char) (data >> 8);
+ }
This reimplements the insw() function with a total of three byte swaps on
big-endian machines. I assume an even number of byte swaps (as done
by inw) would have been needed to make it work on big-endian, but this
depends on the actual hardware implementation.
It seems unlikely that there are any big-endian machines with pc-card
slots that would want to use this hardware.
Arnd