[U-Boot] [PATCH] pinctrl: move dm_scan_fdt_node() out of pinctrl uclass

[Masahiro Yamada]

Hi Simon,




2015-09-04 23:14 GMT+09:00 Simon Glass <sjg at chromium.org>:
> Hi Masahiro,
>
> On 4 September 2015 at 01:47, Masahiro Yamada
> <yamada.masahiro at socionext.com> wrote:
>> Hi Simon,
>>
>>
>> 2015-09-04 13:03 GMT+09:00 Simon Glass <sjg at chromium.org>:
>>> Hi Masahiro,
>>>
>>> On 3 September 2015 at 21:43, Masahiro Yamada
>>> <yamada.masahiro at socionext.com> 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