Am 12.11.24 um 14:46 schrieb Rob Herring: > On Tue, Nov 12, 2024 at 12:41 AM Josua Mayer <josua@xxxxxxxxxxxxx> wrote: >> Boolean type properties are usually considered true if present and false >> when they do not exist. This works well for many in-tree board dts and >> existing drivers. >> >> When users need to overrride boolean values from included dts, >> /delete-property/ is recommend. This however does not work in overlays >> (addons). > As soon as someone needs to delete a non-boolean property, we're back > to the same problem. Properties can be reassigned any value, e.g. a driver default if needed. It should never be necessary to delete a property, since a suitable value may be specified instead. Booleans have two valid values, true and false, but somehow we cannot assign false, we can just delete the property. > If you want to fix it, you need to fix it for any > property. /delete-property/ is a language keyword used during compilation. When inspecting a .dtbo no trace of /delete-property/ is left. Hence we can't "fix" deleting properties through overlays. We can only "fix" (re-)assigning false to a boolean property. > > >> Geert pointed out [1] that there are several invitations for using >> strings "true" and "false" on boolean properties: [1], [2], [3]. > There's always bad examples... > >> Add support for a string value "false" to be considered false on boolean >> properties by changing of_property_read_bool implementation. > Any existing s/w will treat 'foo = "false"' as true. It's an ABI. I was reading through the device-tree specification, it makes absolutely no mention of a boolean type. I believe of_property_read_bool should be capable of deriving false from a present property. What is up to now called bool in the kernel / device-tree, is actually of_property_present, or conversationally of_node_has_flag. sincerely Josua Mayer
