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
