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

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.

Best regards,
Krzysztof