Date:   Mon, 6 Mar 2023 13:21:43 +0200
From:   Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To:     Matti Vaittinen <mazziesaccount@gmail.com>
Cc:     Jonathan Cameron <jic23@kernel.org>,
        Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>,
        Lars-Peter Clausen <lars@metafoo.de>,
        Paul Gazzillo <paul@pgazz.com>,
        Zhigang Shi <Zhigang.Shi@liteon.com>,
        Shreeya Patel <shreeya.patel@collabora.com>,
        Dmitry Osipenko <dmitry.osipenko@collabora.com>,
        linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org
Subject: Re: [PATCH v2 5/6] iio: light: ROHM BU27034 Ambient Light Sensor
Message-ID: <ZAXMx9orQMoNnWr8@smile.fi.intel.com>
References: <cover.1677750859.git.mazziesaccount@gmail.com>
 <874d59be98703bb58a98fea72138de5b94d71a52.1677750859.git.mazziesaccount@gmail.com>
 <20230304201720.2d554f07@jic23-huawei>
 <4beef812-8f4f-3857-c814-efd9173d49e6@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4beef812-8f4f-3857-c814-efd9173d49e6@gmail.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Precedence: bulk

On Sun, Mar 05, 2023 at 03:10:38PM +0200, Matti Vaittinen wrote:
> On 3/4/23 22:17, Jonathan Cameron wrote:
> > On Thu, 2 Mar 2023 12:58:59 +0200
> > Matti Vaittinen <mazziesaccount@gmail.com> wrote:
> > 
> > As per other branch of the thread.
> > 
> > 	ch0 = max(1, le16_to_cpu(res[0]);
> >  > would be cleaner.
> 
> I tried this out. Comparing u16 to literal 1 results comparison of values
> with different sizes:
> 
> ./include/linux/minmax.h:20:28: warning: comparison of distinct pointer
> types lacks a cast
>   (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
>                             ^
> ./include/linux/minmax.h:26:4: note: in expansion of macro ‘__typecheck’
>    (__typecheck(x, y) && __no_side_effects(x, y))
>     ^~~~~~~~~~~
> ./include/linux/minmax.h:36:24: note: in expansion of macro ‘__safe_cmp’
>   __builtin_choose_expr(__safe_cmp(x, y), \
>                         ^~~~~~~~~~
> ./include/linux/minmax.h:74:19: note: in expansion of macro ‘__careful_cmp’
>  #define max(x, y) __careful_cmp(x, y, >)
>                    ^~~~~~~~~~~~~
> drivers/iio/light/rohm-bu27034.c:1057:8: note: in expansion of macro ‘max’
>   ch0 = max(1, ch0);
> 
> 
> I could work around this by doing:
> 
> const u16 min_ch_val = 1;
> 
> ...
> 
> ch0 = max(min_ch_val, le16_to_cpu(res[0]));
> 
> but I think that would really be obfuscating the meaning. I assume
> 
> ch0 = max((u16)1, le16_to_cpu(res[0]));
> 
> might work too - but to me it's pretty ugly.

That's why we have max_t() and clamp_val().
And you know that.

> 
> The more I am looking at this, the stronger I feel we should really just
> write this as it was. Check if res[0] contains the only unsafe data
> "!res[0]" - and if yes, set it to 1. The comment above it will clarify it to
> a reader wondering what happens.
> 
> I will leave it like it was in v2 for v3. If you still feel strong about it
> then we need to continue rubbing it.

You need to convert bit ordering first, then check for 0. It would at least
make more sense. (Today is 0 you are comparing with, tomorrow it might be
0xfffe, which is different to 0x7fff).

-- 
With Best Regards,
Andy Shevchenko