On Mon, 2025-07-07 at 09:43 +0200, Krzysztof Kozlowski wrote:

On 07/07/2025 09:35, Krzysztof Kozlowski wrote:

quoted

On 07/07/2025 09:02, Haren Myneni wrote:

quoted

On Thu, 2025-07-03 at 09:00 +0200, Krzysztof Kozlowski wrote:

quoted

On 03/07/2025 00:14, Haren Myneni wrote:

quoted

+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.

quoted

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.

Yes, PAPR defines these interfaces. 

Best regards,
Krzysztof