Re: [PATCH v3 3/5] misc: pci_endpoint_test: Fix irq_type to convey the correct type

From: Niklas Cassel
Date: Thu Feb 13 2025 - 08:26:59 EST


On Thu, Feb 13, 2025 at 07:21:45PM +0900, Kunihiko Hayashi wrote:
> Hi Niklas,
>
> On 2025/02/11 1:01, Niklas Cassel wrote:
> > On Mon, Feb 10, 2025 at 04:58:10PM +0900, Kunihiko Hayashi wrote:
> > > There are two variables that indicate the interrupt type to be used
> > > in the next test execution, "irq_type" as global and test->irq_type.
> > >
> > > The global is referenced from pci_endpoint_test_get_irq() to preserve
> > > the current type for ioctl(PCITEST_GET_IRQTYPE).
> > >
> > > The type set in this function isn't reflected in the global "irq_type",
> > > so ioctl(PCITEST_GET_IRQTYPE) returns the previous type.
> > > As a result, the wrong type will be displayed in "pcitest" as follows:
> > >
> > > # pcitest -i 0
> > > SET IRQ TYPE TO LEGACY: OKAY
> > > # pcitest -I
> > > GET IRQ TYPE: MSI
> > >
> > > Fix this issue by propagating the current type to the global "irq_type".
> > >
> > > Cc: stable@xxxxxxxxxxxxxxx
> > > Fixes: b2ba9225e031 ("misc: pci_endpoint_test: Avoid using module
> > parameter to determine irqtype")
> > > Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@xxxxxxxxxxxxx>
> > > ---
> > > drivers/misc/pci_endpoint_test.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/misc/pci_endpoint_test.c
> > b/drivers/misc/pci_endpoint_test.c
> > > index f13fa32ef91a..6a0972e7674f 100644
> > > --- a/drivers/misc/pci_endpoint_test.c
> > > +++ b/drivers/misc/pci_endpoint_test.c
> > > @@ -829,6 +829,7 @@ static int pci_endpoint_test_set_irq(struct
> > pci_endpoint_test *test,
> > > return ret;
> > > }
> > > + irq_type = test->irq_type;
> >
> > It feels a bit silly to add this line, when you remove this exact line in
> > the next patch. Perhaps just drop this patch?
>
> This fix will be removed in patch 4/5, so it seems no means.
> However, there is an issue in the stable version, as mentioned in the
> commit message, so I fix it here.

Ok. Having a small fix first that can be backported, which is then followed
by a bigger cleanup, makes sense in this case.

Reviewed-by: Niklas Cassel <cassel@xxxxxxxxxx>