linux-kernel - Re: [PATCH v7 06/10] iio: adc: Support ROHM BD79124 ADC

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] [day] [month] [year] [list]

Message-ID: <d360c0a8-2d21-496f-8ed2-9d3417527d78@gmail.com>
Date: Mon, 31 Mar 2025 10:51:41 +0300
From: Matti Vaittinen <mazziesaccount@...il.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
 Jonathan Cameron <jic23@...nel.org>
Cc: Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
 Lars-Peter Clausen <lars@...afoo.de>, Nuno Sa <nuno.sa@...log.com>,
 David Lechner <dlechner@...libre.com>,
 Javier Carrasco <javier.carrasco.cruz@...il.com>,
 Olivier Moysan <olivier.moysan@...s.st.com>,
 Guillaume Stols <gstols@...libre.com>,
 Dumitru Ceclan <mitrutzceclan@...il.com>,
 Trevor Gamblin <tgamblin@...libre.com>,
 Matteo Martelli <matteomartelli3@...il.com>,
 Alisa-Dariana Roman <alisadariana@...il.com>,
 João Paulo Gonçalves <joao.goncalves@...adex.com>,
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org
Subject: Re: [PATCH v7 06/10] iio: adc: Support ROHM BD79124 ADC

On 31/03/2025 10:37, Andy Shevchenko wrote:
> On Sun, Mar 30, 2025 at 05:04:36PM +0100, Jonathan Cameron wrote:
>> On Mon, 17 Mar 2025 13:24:07 +0200
>> Matti Vaittinen <mazziesaccount@...il.com> wrote:
>>> On 16/03/2025 13:02, Jonathan Cameron wrote:
>>>> On Thu, 13 Mar 2025 09:19:03 +0200
>>>> Matti Vaittinen <mazziesaccount@...il.com> wrote:
> 
> ...
> 
>>>>> +	return (data->alarm_monitored[chan->channel] & BIT(dir));
>>>>
>>>> Drop the outer brackets as not adding anything.
>>>
>>> I just noticed that the integer returned from here is directly provided
>>> to the user-space. I don't know the history, but it feels a bit off to
>>> me. I mean, I would expect the read from sysfs file "*_en" to return '1'
>>> or '0' - not 0x04.
>>>
>>> Oh well, I suppose it's too late to change this in the IIO core - but
>>> I'll do:
>>> 	return !!(data->alarm_monitored[chan->channel] & BIT(dir));
>>
>> Agreed it should be returning 1 or 0.
>>
>> This stuff is a little bit messy.  I'd not be against that ABI
>> cleanup if we squashed the values to 0,1 in the core as a follow up.
>>
>> I doubt anyone relies on getting 0x4 as that would be very driver
>> specific userspace code!
> 
> FWIW, the time this discussion was held, I looked at the code and it seems
> we have such drivers. I doubt we can change it without potential breakage of
> (some) user space tools.

Thanks for the check, and for sharing the results Andy.

I was considering this for a while but eventually I didn't want to take 
a chance of breaking things. I have a feeling that majority of 
application writers, who happen to be writing something using a specific 
sensor, would just make their code to match what-ever they see kernel 
retuning via sysfs.

I know younger me would in the early 2000s. If I got a board where I was 
able to read values from sysfs, I would have just written the code which 
matches whatever I saw in sysfs when testing out things. I would have 
tried reading the file and then making my application to expect exactly 
the value "0x4" - assuming other values may have some other, unknown to 
me, meaning. I wouldn't have gone after a documentation, much less to 
send a question or a patch upstream :)

So, I wouldn't be surprized if someone else had done just this same, and 
they might be upset if we break their app(s).

Yours,
	-- Matti