On 07/07/2025 09:35, Krzysztof Kozlowski wrote:
> On 07/07/2025 09:02, Haren Myneni wrote:
>> On Thu, 2025-07-03 at 09:00 +0200, Krzysztof Kozlowski wrote:
>>> On 03/07/2025 00:14, Haren Myneni wrote:
>>>> +static int __init enable_hvpipe_IRQ(void)
>>>> +{
>>>> + struct device_node *np;
>>>> +
>>>> + hvpipe_check_exception_token =
>>>> rtas_function_token(RTAS_FN_CHECK_EXCEPTION);
>>>> + if (hvpipe_check_exception_token == RTAS_UNKNOWN_SERVICE)
>>>> + return -ENODEV;
>>>> +
>>>> + /* hvpipe events */
>>>> + np = of_find_node_by_path("/event-sources/ibm,hvpipe-msg-
>>>> events");
>>>
>>> Undocumented ABI, NAK. Plus node names should not be used at all as
>>> ABI... and naming does not follow DT spec/style, not sure if you care
>>> about it, though.
>>
>> These new interfaces are documented in new version of PAPR. Please note
>
> Which version? PAPR defines standard, but not the kernel ABI. You still
> need to document kernel ABI, just like every other OF usage.
>
>
>> that /proc/device-tree/event-sources node is different which will not
>> have ibm,phandle unlike in some other node. event-sources already has
>> several event messages such as io, EPOW, hot-plug, internal-errors
>> events and adding hvpipe-msg events now. We can see the similar
>> of_find_node_by_path() usage in the current code.
>>
>> io_event_irq.c: np = of_find_node_by_path("/event-sources/ibm,io-
>> events");
>> ras.c: np = of_find_node_by_path("/event-sources/hot-plug-events");
>> ras.c np = of_find_node_by_path("/event-sources/internal-errors");
>> ras.c: np = of_find_node_by_path("/event-sources/epow-events");
>
> So you find more issues. Are you going to fix them? What are such
> arguments proving? Nothing. If these are bugs, are you allowed to do the
> same? Obviously not.
>
> Bring argument about the ABI - ABI is documented here or ABI is does not
> need documentation, because of something, or this is not ABI because of
> something (although it is). I don't see usage of these in DTS, so
> probably there is something I don't get, but your arguments are not
> helping at all.
Although probably if you do not have any DTS, or let's say in-kernel DTS
for these, it is indeed enough that PAPR spec defines it and no need to
document it twice.
Best regards,
Krzysztof
