Re: drivers/net/wireless/microchip/wilc1000/cfg80211.c:361:42: sparse: sparse: incorrect type in assignment (different base types)

Kalle Valo
2023-08-29T08:31:04Z

Kalle Valo <kvalo@kernel.org> writes:

> kernel test robot <lkp@intel.com> writes:
>
>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>> head: 727dbda16b83600379061c4ca8270ef3e2f51922
>> commit: c5b331d4f550fb78bf1a553b2517616a5ea913d6 wifi: wilc1000: add WPA3 SAE support
>> date: 1 year, 3 months ago
>> config: i386-randconfig-063-20230829 (https://download.01.org/0day-ci/archive/20230829/202308290615.lUTIgqUl-lkp@intel.com/config)
>> compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
>> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20230829/202308290615.lUTIgqUl-lkp@intel.com/reproduce)
>>
>> If you fix the issue in a separate patch/commit (i.e. not just a new version of
>> the same patch/commit), kindly add following tags
>> | Reported-by: kernel test robot <lkp@intel.com>
>> | Closes: https://lore.kernel.org/oe-kbuild-all/202308290615.lUTIgqUl-lkp@intel.com/
>>
>> sparse warnings: (new ones prefixed by >>)
>>>> drivers/net/wireless/microchip/wilc1000/cfg80211.c:361:42: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned int key_mgmt_suite @@ got restricted __be32 [usertype] @@
>> drivers/net/wireless/microchip/wilc1000/cfg80211.c:361:42: sparse: expected unsigned int key_mgmt_suite
>> drivers/net/wireless/microchip/wilc1000/cfg80211.c:361:42: sparse: got restricted __be32 [usertype]
>
> Yeah, this is an old issue but we really should try to fix this,
> especially so as I would like to make wireless code sparse warning free
> in the near future. IIRC there were some problems with nl80211 interface
> as well so this might not be simple fix still.

For reference here's the old discussion:

https://patchwork.kernel.org/project/linux-wireless/patch/20220720160302.231516-1-ajay.kathat@microchip.com/

Any volunteers to help fix this? I would prefers fixes for issues like
this compared to questionable random cleanups we always get.

Maybe we should come up with a todo list somewhere and advocate the
"cleaners" to work on those items instead?

--