On Thu, Nov 17, 2022 at 11:34:06AM +0000, Mark Brown wrote:
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.
Huh? If we add a quirk to gpiolib to treat the signal as active low (i.e. preserve current driver behavior - I am talking about this particular peripheral here, not treating everything as active low of course).
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.
Yes, I freely admit I do not take device tree ABI compatibility seriously. IMO, with the exception of a few peripherals, it is a solution in search of a problem, and we declared stability of it too early, before we came up with reasonable rules for how resources should be described. I strongly believe that in vast majority of cases devices with out-of-tree DTs will not be updated to upstream kernels as this requires significant engineering effort and vendors usually not interested in doing that.
Thanks.