Hi Simon,
On 02/25/2018 11:54 PM, Simon Glass wrote:
> Hi Kever,
>
> On 23 February 2018 at 19:08, Kever Yang <kever.y...@rock-chips.com> wrote:
>> Hi Simon,
>>
>>
>> On 02/12/2018 10:35 PM, Simon Glass wrote:
>>> Hi Kever,
>>>
>>> On 8 February 2018 at 19:56, Kever Yang <kever.y...@rock-chips.com> wrote:
>>>> Add api for who can not get phandle from a device property.
>>> Can you please add a motivation to the commit message? It is not
>>> obvious to me when this function would be used.
>> Here is the example why I need this, see the dts node here:
>> lvds@ff2e0000 {
>> ...
>> rockchip,grf = <&grf>;
>> port {
>> port@0 {
>> endpoint@0 {
>> remote-endpoint = <&vopl_out_lvds>;
>> }
>> }
>> }
>> }
>>
>> We can only get 'grf' udevice by uclass_get_device_by_phandle(),
>> but we not able to get udevice 'vopl_out_lvds', other driver like
>> rockchip pinctrl
>> also need to get udevice by a phandle which is not one of direct property of
>> another device node.
> OK I see. This sort of info is useful in the commit message. It helps
> to know two things about a patch:
>
> - why it is needed
> - what it does
>
> In this case see rk_display_init() for how it handles the
> 'remote-endpoint' property. I think it would be better to have
> something like:
>
> ofnode ofnode_lookup_phandle(ofnode node, const char *prop_name);
Yes, this is enough for "remote-endpoint" case, but not for pinctrl case:
1199 pinctrl: pinctrl {
2095 pwm0
{
2096 pwm0_pin: pwm0-pin
{
2097 rockchip,pins
=
2098 <0 RK_PB7 RK_FUNC_1
&pcfg_pull_none>;
2099
};
2100 };
I think ofnode_lookup_phandle() still not able to find node for
'pcfg_pull_none'.
Thanks,
- Kever
>
> This should meet your needs without needing to decoding the phandle
> property in the caller.
>
> Regards,
> Simon
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
