16:11 <NishanthMenon> arnd: would like your thoughts on https://lore.kernel.org/all/20220321155417.13267-1-bb@ti.com/

16:13 <arnd> NishanthMenon: do you mean the concept of having a skeleton dts file in general, or something more specific about it?

16:14 <NishanthMenon> arnd: the concept of skeleton dts file - bare min for folks to get started.. if this direction is OK, we'd like to scale it over to all k3 SoCs..

16:14 <arnd> My initial reaction would be that this should probably be done the other way round: make the optional nodes disabled by default, and enable the ones that are actually used in the board specific files

16:15 <arnd> if there is a skeleton file, I'd try to make that as small as possible

16:15 <NishanthMenon> arnd: yep.. there has been back and forth on the topic.. https://lore.kernel.org/all/YiizsYnKB0X9bDY2@atomide.com/ i was hoping to get some debate on the list to help conclude the direction

16:15 <arnd> regarding the contents inside of it, I think the bootargs certainly need to go, no board

16:16 <arnd> I think you should only need the stdout-path

16:17 <NishanthMenon> arnd: Thanks. would be awesome if you could add your thoughts on the list.. hoping to get the discussion sorted out before our next window so that we can set the stage for the dts re-orgs if any needed

16:19 <arnd> I'm still not sure if it actually improves things to have a skeleton file, at least for drivers we have generally stopped doing those, and instead try to refer to actual drivers as examples

16:21 <NishanthMenon> arnd: the trouble is people trying to find a minimal system to get started on a new board. in a audit we did with various support teams, that seems to cost a quite a bit of time with customers atm. balancing that against the "default" definition of a node as "always enabled" has been a bit confusing..

16:23 <NishanthMenon> example: "anything with external pinctrl" should be default disabled is a view.. but then, there is counter argument that drivers should be able to handle that.

16:23 <NishanthMenon> also, "remote processors" and "hardware accelerators" somehow fall out of that set, but is not needed for minimal configuration either.

17:17 <tmlind> my suggestion for some kind of policy here is to tag problem causing devices as disabled and add a comment explaining it like "unconfigured i2c pins cause boot time warnings" :)

17:18 <tmlind> that should lead into least amount of dts related status enabled/disabled changes across the board files

19:05 <ujfalusi> Other pow is that the board dts file describes the board, what is wired up and how. The dts enable/wire up peripherals ajd it is not the the one which should bendisabling what is not used.

19:06 <ujfalusi> Sorry, Android keyboard...