From: Subhajit Ghosh <subhajit.ghosh@vixtechnology.com>
To: Jonathan Cameron <Jonathan.Cameron@Huawei.com>,
Matt Ranostay <matt.ranostay@konsulko.com>
Cc: jic23@kernel.org, lars@metafoo.de, linux-kernel@vger.kernel.org,
linux-iio@vger.kernel.org
Subject: Re: [PATCH] iio: light: apds9960: Fix iio_event_spec structures
Date: Fri, 11 Nov 2022 21:44:48 +0800 [thread overview]
Message-ID: <380ae3c3-14c2-db1a-954c-caf8180746f0@vixtechnology.com> (raw)
In-Reply-To: <20221111111049.0000467f@Huawei.com>
> 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.
next prev parent reply other threads:[~2022-11-11 13:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-10 10:12 [PATCH] iio: light: apds9960: Fix iio_event_spec structures Subhajit Ghosh
2022-11-10 13:29 ` Matt Ranostay
2022-11-10 14:45 ` Subhajit Ghosh
2022-11-11 2:50 ` Matt Ranostay
2022-11-11 7:04 ` Subhajit Ghosh
2022-11-11 11:10 ` Jonathan Cameron
2022-11-11 13:44 ` Subhajit Ghosh [this message]
2022-11-12 17:47 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=380ae3c3-14c2-db1a-954c-caf8180746f0@vixtechnology.com \
--to=subhajit.ghosh@vixtechnology.com \
--cc=Jonathan.Cameron@Huawei.com \
--cc=jic23@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt.ranostay@konsulko.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox