On Thu, Nov 17, 2022 at 10:31:49PM -0800, Dmitry Torokhov wrote: > On Thu, Nov 17, 2022 at 11:34:06AM +0000, Mark Brown wrote: > > 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). My comments were more generic ones about the whole series since all the patches seemed to be doing the same thing with flipping the polarity - some of the GPIOs were labelled as things like reset which is active high if it's not nRESET or something even though we want to pull it low while using the device. > > 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. There are practical systems which ship DTs as part of the firmware, and frankly things like this do contribute to the issue. The systems that just ship their DTs are obviously a lot less visible, but that's the whole goal here. It's most common with more server type systems using EDK2 for the firmware, ACPI isn't always a good fit for them.
Attachment:
signature.asc
Description: PGP signature
