linux-kernel - Re: [PATCH] iio: light: apds9960: Fix iio_event

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]

Date:   Fri, 11 Nov 2022 21:44:48 +0800
From:   Subhajit Ghosh <subhajit.ghosh@...technology.com>
To:     Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        Matt Ranostay <matt.ranostay@...sulko.com>
Cc:     jic23@...nel.org, lars@...afoo.de, linux-kernel@...r.kernel.org,
        linux-iio@...r.kernel.org
Subject: Re: [PATCH] iio: light: apds9960: Fix iio_event_spec structures

> Hmm.  Given that event enables often cover a couple of different things
> (as done here) it isn't unknown for those to not be as easily covered
> as you have done.  As such, we have drivers were the ABI allows for
> enabling one event to end up enabling several others (even though they
> have separate enable attributes).  It's always been permitted for one
> IIO attribute write to have an effect on other attributes simply because
> we can't represent all dependencies.
> 
> Now the bigger complexity / surprise here is the return of the either
> direction in response to enabling either rising or falling. 
> That is going to rather surprise your average writer of userspace cod This is where the inconsistency was found. When an ALS threshold rising 
value was given and as soon as it was enabled, interrupts started firing
in low light conditions as there was some value present in the ALS falling 
threshold(reset value is not defined in the datasheet for this register), 
but falling threshold value was neither fed nor enabled!

> So patch covers what we should definitely have had in the first place.
> Hence it's a question of risk of someone running code that will be affected
> by the ABI change.  One of those fingers crossed moments...
I understand that breaking existing userspace applications is not the best
thing to do.

> 
> Jonathan

Thank you for your time and comments.

Regards,
Subhajit Ghosh

-- 
This email is confidential. If you have received this email in error please 
notify us immediately by return email and delete this email and any 
attachments. Vix accepts no liability for any damage caused by this email 
or any attachments due to viruses, interference, interception, corruption 
or unauthorised access.