00:40 <set_> !

08:17 <zmatt> rcn-ee: can you elaborate? the gpio-aggregator driver doesn't contain a single line of pinctrl-related code afaics

08:19 <zmatt> like, what do you declare in DT and what action results in a runtime pinmux change?

08:30 <zmatt> unless you just mean you're dynamically binding a driver to a DT node and trigger pinctrl as a consequence, but that has nothing to do with gpio-aggregator but works with any driver. if you want an "empty" driver you can dynamically attach to a DT node to activate its pinmux (or other DT features that are managed automatically, like assigned-clocks), the best choice I know of would be simple-pm-bus, ...

08:30 <zmatt> ...whose probe() function, when used attached using ...

08:30 <zmatt> ... driver_override, is just "return 0;"

08:31 <zmatt> argh, why do I have two line-splitters active again, I thought I fixed that

10:59 <zmatt> in a way, runtime dt overlays were the only "right" way to deal with dynamic reconfiguration of "platform" hardware, given that the normal mechanism to declare such hardware is through dt

10:59 <zmatt> unfortunately the kernel was just never designed to deal with platform devices changing at runtime