On Fri, Jun 12, 2020 at 5:48 AM Kevin P. Fleming <kevin+linux@xxxxxxx> wrote: > > On Wed, Jun 10, 2020 at 11:16 AM Alexandre Belloni > <alexandre.belloni@xxxxxxxxxxx> wrote: > > When working with RTCs, there is one issue though: boolean properties > > are not working well because there is no way to express the 3 different > > conditions: > > 1/ the capacitor is present, set the register > > 2/ the capacitor is absent, clear the register > > 3/ the device tree didn't have this property until not and the register > > may have been set or cleared using another mean, don't touch it. > > > > As your patch is written, it only handles 1 and 3 which is probably the > > safest option but then we will never have a way to clear it from the > > driver. I'd say that this is not an issue but it is also something we > > will never be able to change without breaking some setups. > > I agree. I could implement this as an enumerated string option which > accepts 'yes' or 'no'. Those would cover cases 1 and 2, and the > absence of the property would be case 3. I looked through the bindings > that exist and didn't see any examples of properties configured this > way, but I think it would be understandable to users. It's a solved problem: foo-feature = 0; //disable foo-feature = 1; //enable <no prop> // Leave feature configured as-is Rob
