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

[Haren Myneni]

On Mon, 2025-07-07 at 09:43 +0200, Krzysztof Kozlowski wrote:
> 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.

Yes, PAPR defines these interfaces. 

> 
> Best regards,
> Krzysztof