On Wed, Nov 16, 2022 at 11:07:48AM -0800, Dmitry Torokhov wrote: > On Wed, Nov 16, 2022 at 10:36:27AM +0000, Mark Brown wrote: > > How are we ensuring that people have described signals as active > > low/high in existing DTs, and are we positive that the signal is > > described as active low for all devices? In particular if the > > signal is described as a reset signal then it's active high even > > if we want it low while the device is actually in use. > I have been going through in-kernel DTSes and adjusting ones that are > incorrect. For external ones I think we should take a pragmatic approach > and say that if driver has last non-mechanical update in 2014 and there > are no users submitted to mainline since then (as this one), then it is > highly unlikely that devices currently using this component/codec will > be updated to the 6.2+ kernel even if they are still in service. And if > this does happen the breakage will be immediately obvious as we'll keep > the codec in reset state. > But if you really want to I can add quirk(s) to gpiolib forcing this > line to be treated as active-low regardless of what specified in DTS. > This kind of negates benefit of going to gpiod though. That doesn't address the bit about checking that the device describes the signal as active low in hardware - it's assuming that the signal is described by the device as an active low reset and not for example as a shutdown signal. TBH I'm not thrilled about just randomly breaking ABI compatibility for neatness reasons, it's really not helping people take device tree ABI compatibility seriously.
Attachment:
signature.asc
Description: PGP signature
