Re: [PATCH 06/21] can: netlink: add can_validate_databittiming()

[Vincent Mailhol <mailhol@kernel.org>]

On 05/09/2025 at 03:46, kernel test robot wrote:
> Hi Vincent,
> 
> kernel test robot noticed the following build warnings:
> 
> [auto build test WARNING on 2fd4161d0d2547650d9559d57fc67b4e0a26a9e3]

OK. I will silence it in v2, but I don't think this is anyhow problematic.

> url:    https://github.com/intel-lab-lkp/linux/commits/Vincent-Mailhol/can-dev-move-struct-data_bittiming_params-to-linux-can-bittiming-h/20250903-170807
> base:   2fd4161d0d2547650d9559d57fc67b4e0a26a9e3
> patch link:    https://lore.kernel.org/r/20250903-canxl-netlink-prep-v1-6-904bd6037cd9%40kernel.org
> patch subject: [PATCH 06/21] can: netlink: add can_validate_databittiming()
> config: x86_64-kexec (https://download.01.org/0day-ci/archive/20250905/202509050259.NjPdQyAD-lkp@intel.com/config)
> compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250905/202509050259.NjPdQyAD-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/202509050259.NjPdQyAD-lkp@intel.com/
> 
> All warnings (new ones prefixed by >>):
> 
>>> drivers/net/can/dev/netlink.c:111:6: warning: variable 'is_on' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
>      111 |         if (ifla_can_data_bittiming == IFLA_CAN_DATA_BITTIMING) {
>          |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    drivers/net/can/dev/netlink.c:119:6: note: uninitialized use occurs here
>      119 |         if (is_on) {
>          |             ^~~~~
>    drivers/net/can/dev/netlink.c:111:2: note: remove the 'if' if its condition is always true

That's it. This if condition is always true at the moment because all the
callers specify ifla_can_data_bittiming as IFLA_CAN_DATA_BITTIMING. But I do not
want to remove the else branch because is serves to show to the reader what is
coming up next and help to understand the refactor logic.
>      111 |         if (ifla_can_data_bittiming == IFLA_CAN_DATA_BITTIMING) {
>          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>      112 |                 data_tdc = data[IFLA_CAN_TDC];
>      113 |                 tdc_flags = flags & CAN_CTRLMODE_FD_TDC_MASK;
>      114 |                 is_on = flags & CAN_CTRLMODE_FD;
>      115 |         } else {
>          |           ~~~~~~
>      116 |                 WARN_ON(1); /* Place holder for CAN XL */
>          |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The WARN_ON(1) was to point out that the else branch should never be reached.

I will change this to:

	return -EOPNOTSUPP; /* Place holder for CAN XL */

in v2. This will serve the same purpose as the current WARN_ON(1) but will
suppress the warning.

I will do the exact same on patches 11/21 and 18/21 on which the kernel test
robot also sent a similar report.


Yours sincerely,
Vincent Mailhol