linux-kernel - Re: [PATCH] iio: ti-adc128s052: Drop variable vref

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e0f8a39e-195d-4b72-8787-36769c1e62c8@gmail.com>
Date: Mon, 28 Apr 2025 16:10:47 +0300
From: Matti Vaittinen <mazziesaccount@...il.com>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
 Jonathan Cameron <jic23@...nel.org>, David Lechner <dlechner@...libre.com>,
 Nuno Sá <nuno.sa@...log.com>,
 Andy Shevchenko <andy@...nel.org>, linux-iio@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] iio: ti-adc128s052: Drop variable vref

On 28/04/2025 12:49, Andy Shevchenko wrote:
> On Mon, Apr 28, 2025 at 12:45 PM Matti Vaittinen
> <mazziesaccount@...il.com> wrote:
>> On 28/04/2025 10:08, Andy Shevchenko wrote:
>>> On Mon, Apr 28, 2025 at 10:02 AM Matti Vaittinen
>>> <mazziesaccount@...il.com> wrote:
> 
> ...
> 
>>>> +       int vref_mv;
>>>
>>> vref_mV please. And yes, I know historical and other reasons for them
>>> all being small, but let's try to be more scientific in these crazy
>>> days.
>>
>> Sorry Andy but I see zero reason to use capital letters here. In my
>> opinion, this is perfectly clear as it is. Capital letters in variables
>> are ugly (to me) and absolutely not needed to explain the meaning.
> 
> And I see zero reason to not use the correct scientific unitis there.

I find this ridiculous reason. There is zero confusion what the vref_mv 
stands for, and I prefer variables in lower case.

> Note, that regulator framework

Actually, the regulator framework uses _both_ lower and upper case in 
some places, and I believe the reason is that bikeshedding over the 
capitalization isn't Mark's cup of tea.

> and some other drivers are using that
> and I consider this is the correct way to go.
> 
> ...
> 
>>> Or actually a time to introduce MILLIVOLT_PER_VOLT in units.h ?
>>
>> I really fail to see the benefit. Do you think we should add
>> MILLIx_PER_x for each unit we can imagine/use?
>>
>> That doesn't really scale or make sense to me. We have MILLI. It does
>> not really matter if it is volts, amps, ohms or horse heads - it's still
>> 1000. It just gets cumbersome to search the headers to see if we have
>> some fancy define for unit we have at our hands.
> 
> In some contexts this gives the understanding of the units and how big
> the value is. Even with some defined constants it's not possible to
> describe in their names everything that this definition adds. I do see
> a benefit of it.

You can suggest adding it if you wish. I still find it silly as I don't 
see why one wouldn't then end up adding base SI units too.

MILLIVOLT_PER_VOLT
MILLIKILOGRAM_PER_KILOGRAM
MILLIMETER_PER_METER
MILLISECOND_PER_SECON
MILLIAMPERE_PER_AMPERE
MILLIKELVIN_PER_KELVIN
MILLIMOLE_PER_MOLE
MILLICANDELA_PER_CANDELA

Oh, and because Volt is added, then also:

Newton, Heryz, Coulomb, Henry, Farad, Ohm, Siemens, Weber, Tesla, Joule, 
Watt, Radian, Bequerel and Lumen.

And, sure adding Kelvin warrants adding Celsius and Fahrenheit. Oh, 
probably also imperial units, right?

All being the same MILLI.

No thanks. I am opposing this as it will only make life of a code writer 
(and maybe also reader) harder. I'm not suggesting a patch adding 
something I feel is rather silly.

Yours,
	-- Matti