00:36 <digetx> hi, which drivers?

00:37 <digetx> you can email original author, if you won't get answer, then just send it

08:20 <DavidHeidelberg> I'm thinking about making PR against dt_bindings (lot of commits, my point is to leave it visible in grate-driver PR, until all get merged?). Currently only advantages, that `make dtbs_check` pass there, so it'll be easier to see new regressions.

08:20 <DavidHeidelberg> Another option would be manage it as branch in grate-driver (but I'm afraid it'll generate too much noise). This option (if you digetx would make git rebase origin/master on dt_bindings) would be able fire useful dtbs warnings while not poluting master with many WIP commits.

08:20 <DavidHeidelberg> Last option is to keep it under my repo as it is now, but not sure if someone looking into it ever :)

14:20 <DavidHeidelberg> * PR against grate - branch dt_bindings (lot

16:19 <digetx> DavidHeidelberg: the bindings look okay; some bindings have extra blank lines, some are missing necessary blanks; it's probably not necessary to document pinctrl-* properties because they standard?

16:19 <DavidHeidelberg> yeah, I just got a mail in different binding about pinctrl

16:19 <DavidHeidelberg> I'll be removing comment about it :)

16:35 <DavidHeidelberg> digetx about blank lines, is there anything describing how it should be? In some cases I group properties, when they're not related, not more like few, I mostly put empty line between them

16:36 <digetx> use a single blank line everywhere

16:48 <digetx> DavidHeidelberg: you shouldn't document anything that is specific to OS, bindings are about hardware description solely

16:49 <digetx> bindings are OS-independent, they are hosted in kernel just for convenience, that is why they are BSD-licensed

16:53 <digetx> https://github.com/okias/linux/commit/f5c946ec6d95bc201e3f62521d4dad8c5b9e978f#diff-57c19e7bac43ebf8de77ef84065704388254d711d625752f982c8a7047e88bb9R42 blank line

16:54 <digetx> for an example

16:54 <digetx> don't group properties, it's not very readable

17:08 <digetx> for an example that WARN_ON shouldn't be documented https://github.com/okias/linux/commit/5f08dabccd431b7593cde29e1dfa571e1300155d#diff-8a39018971d4895d829c51dbe1a6a168d2c23c59c1e2984e2ba60deb3901c84eR50 it's OS-specific

17:26 <DavidHeidelberg> digetx for elan, after space adjustments, can I add you acked-by?

17:29 <DavidHeidelberg> I'm slowly sending them to ML's https://lists.sr.ht/~okias/devicetree/patches

17:29 <digetx> acked-by usually is given by maintainers for other maintainers, you can add my reviewed-by; ping me after corrections, I'll look again

17:32 <DavidHeidelberg> digetx " description: Time to wait before device gets shutdown" sounds resonable instead WARN_ON?

17:32 <DavidHeidelberg> maybe gets powered-off

17:35 <DavidHeidelberg> better "Device should power-off within this timeout limit."

17:35 <digetx> yes

17:35 <digetx> but that binding is odd, perhaps it's an ancient binding

17:35 <DavidHeidelberg> or another take "Time needed for device to power-off."

17:36 <DavidHeidelberg> *for the

17:36 <DavidHeidelberg> well, yeah, gpio poweroff is not likely much used these days

17:36 <digetx> is it used at all?

17:37 <DavidHeidelberg> a lot for arm32 devices

17:38 <DavidHeidelberg> arch/arm/boot/dts/tegra20-trimslice.dts and also some network devices

17:38 <digetx> okay

17:38 <DavidHeidelberg> which variant of desc, last or the one you reacted with "yes"? :)

17:38 <DavidHeidelberg> ur english is better than mine, so I'll leave decision up to u

17:38 <digetx> although, I now see that you copied text from original binding, maybe it's okay to keep it as-is then

17:39 <DavidHeidelberg> but I looked into code. The dropping WARN_ON make sense.

17:39 <DavidHeidelberg> WARN_ON is just consequence

17:40 <digetx> doubt that my english is better, I'm periodically getting complains about it

17:41 <DavidHeidelberg> :D

17:48 <DavidHeidelberg> digetx https://github.com/okias/linux/commits/dt_bindings

18:11 <DavidHeidelberg> properties u8 -> u32; done

18:20 <digetx> elan binding looks okay

18:21 <digetx> you may wait for comments to gpio-poweroff binding before resending it, maybe nobody will complain since it was a direct conversion of old binding

18:24 <DavidHeidelberg> ok

18:25 <DavidHeidelberg> on Elan, can I sent w/ your R-b?

18:25 <digetx> yes

18:27 <DavidHeidelberg> btw. maintainer email (original author) doesn't exist

18:27 <DavidHeidelberg> should it go to Rob then?

18:28 <digetx> input/ subsystem maintainer

18:30 <DavidHeidelberg> thx