On 16.04.2025 16:12, Daniel P. Smith wrote:
> On 4/16/25 09:41, Jan Beulich wrote:
>> On 16.04.2025 15:37, Daniel P. Smith wrote:
>>> On 4/10/25 08:03, Jan Beulich wrote:
>>>> On 08.04.2025 18:07, Alejandro Vallejo wrote:
>>>>> @@ -212,6 +213,39 @@ static int __init process_domain_node(
>>>>> else
>>>>> printk("PV\n");
>>>>> }
>>>>> + else if ( strncmp(prop_name, "memory", name_len) == 0 )
>>>>> + {
>>>>> + uint64_t kb;
>>>>> + if ( fdt_prop_as_u64(prop, &kb) != 0 )
>>>>
>>>> Nit (you know what I have to say here, and again below.)
>>>>
>>>>> + {
>>>>> + printk(" failed processing memory for domain %s\n",
>>>>> name);
>>>>> + return -EINVAL;
>>>>
>>>> Any reason to override fdt_prop_as_u64()'s return value here?
>>>
>>> IMHO this should be a function that libfdt should provide, but altering
>>> libftd directly would make uprev'ing it challenging. The least I could
>>> do is make the function behave like the rest of libfdt's helper functions.
>>
>> How's this related to the question that I raised? I didn't question the
>> function, but a particular aspect of the specific use that is being made
>> of it here.
>
> Your question was, "Any reason to override fdt_prop_as_u64()'s return
> value here?"
>
> And my answer was, I copied libfdt's behavior for its helper functions.
> IOW, to have the helper behave like libfdt's other helper functions.
I'm sorry, but no. It meanwhile feels like you're intentionally
misunderstanding. We're in process_domain_node() here. That's not a libfdt-
like helper function? And the question was why this function throws away
the return value it got from fdt_prop_as_u64().
Jan
