> 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.
