Hi Simon,
2015-09-04 23:14 GMT+09:00 Simon Glass <[email protected]>: > Hi Masahiro, > > On 4 September 2015 at 01:47, Masahiro Yamada > <[email protected]> wrote: >> Hi Simon, >> >> >> 2015-09-04 13:03 GMT+09:00 Simon Glass <[email protected]>: >>> Hi Masahiro, >>> >>> On 3 September 2015 at 21:43, Masahiro Yamada >>> <[email protected]> wrote: >>>> Commit c5acf4a2b3c6 ("pinctrl: Add the concept of peripheral IDs") >>>> added some additional change that was not mentioned in the git-log. >>>> >>>> That commit added dm_scan_fdt_node() in the pinctrl uclass binding. >>>> It should be handled by the simple-bus driver, and it is totally >>>> unrelated to pinctrl in the first place. >>> >>> Actually you mentioned this before I never got back to it, sorry. >> >> And, I was not tracking it after I mentioned that. Sorry. >> >> >> >>> Do you mean that pinctrl is not supposed to have child nodes with >>> their own compatible strings? >> >> I do not mean that. >> >> It is OK for a pinctrl device to have child nodes with compatible strings. >> This should not be restricted. >> >> >> But, it is not the feature of the pinctrl framework. >> The pinctrl is not a bus. >> >> >> Binding child devices should be a task for a bus, in this case, the >> simple-bus. > > Hmm, so here we want to do some simple-bus processing as well as > something else, using the list of compatible strings. > > Is this something we can arrange within the existing driver model approach? After some consideration, I think we should not do this (at least until we find a good solution). Doing it could screw up our DM approach. The Rockchip's pinctrl looks like a container of some GPIO banks, so I think it makes sense to have dm_scan_fdt_node() in rk3288_pinctrl_bind(). -- Best Regards Masahiro Yamada _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
