[PATCH RFC 7/9] powerpc/pseries: Enable HVPIPE event message interrupt

[Krzysztof Kozlowski]

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