[PATCH] ARM: dts: stm32: Configure Buck3 voltage per PMIC NVM on Avenger96

Patrick DELAUNAY patrick.delaunay at foss.st.com
Tue May 17 17:32:15 CEST 2022


On 5/17/22 16:32, Marek Vasut wrote:
> On 5/17/22 15:43, Patrick DELAUNAY wrote:
>> Hi,
>
> Hi,
>
>>>>> +static int board_get_regulator_buck3_nvm_uv_av96(int *uv)
>>>>> +{
>>>>> +    const void *fdt = gd->fdt_blob;
>>>>> +    struct udevice *dev;
>>>>> +    u8 bucks_vout = 0;
>>>>> +    const char *prop;
>>>>> +    int len, ret;
>>>>> +
>>>>> +    /* Check whether this is Avenger96 board. */
>>>>> +    prop = fdt_getprop(fdt, 0, "compatible", &len);
>>>>
>>>>
>>>> This API is not compatible with CONFIG_OF_LIVE
>>>>
>>>> consider replacement with ofnode_read_prop or with 
>>>> of_machine_is_compatible, for example
>>>>
>>>> if (!of_machine_is_compatible(prop, "arrow,stm32mp15xx-avenger96"))
>>>>      return -EINVAL;
>>>
>>> I explicitly don't want to use of_machine_is_compatible, I need to 
>>> search for the avenger96 substring in the machine compatible, since 
>>> the stm32mp15xx can be anything (15{1,3,7}{a,d}) and it might not 
>>> even have the arrow prefix.
>>
>>
>> Ok, I check on existing DT and I found only on compatible with 
>> "avenger96" string.
>>
>> arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts:15:
>>
>>      compatible = "arrow,stm32mp15xx-avenger96", "st,stm32mp15x";
>>
>> But you can forget my proposal with of_machine_is_compatible, consider:
>>
>>     prop = ofnode_read_prop(ofnode_root(), "compatible", &len);
>>
>>
>> But it is just minor remark.
>
> There are multiple other fdt_getprop() calls in both board/st/ and 
> board/dh , maybe if you want to do OF_LIVE enablement (do you?), let's 
> convert them all at once ?


Ok. It is more a minor remark linked to checkpatch warning for all the 
added code:

"Use the livetree API (dev_read_...)"


I let you handle OF_LIVE  for your boards (code & defconfig),

FYI: it is already enable for STMicroelectronics boards (defconfig and 
in driver, mach-stm32mp and board code).


>
>> Do you expect this patch for next pull-request for v2022.07 or for 
>> next ?
>
> Ideally 2022.07.


Ok, I plan that.


Patrick



More information about the U-Boot mailing list