| Message ID | 20240820071100.211622-2-rick.wertenbroek@gmail.com (mailing list archive) |
|---|---|
| State | Under Review |
| Delegated to: | Krzysztof Wilczyński |
| Headers | show |
| Series | PCI: endpoint: pci-epf-test: Call | expand |
On 8/20/24 16:10, Rick Wertenbroek wrote: > The pci-epf-test PCI endpoint function /drivers/pci/endpoint/function/pci-epf_test.c > is meant to be used in a PCI endpoint device connected to a host computer > with the host side driver: /drivers/misc/pci_endpoint_test.c. > > The host side driver can request read/write/copy transactions from the > endpoint function and expects an IRQ from the endpoint function once > the read/write/copy transaction is finished. These can be issued with or > without DMA enabled. If the host side driver requests a read/write/copy > transaction with DMA enabled and the endpoint function does not support > DMA, the endpoint would only print an error message and wait for further > commands without sending an IRQ because pci_epf_test_raise_irq() is > skipped in pci_epf_test_cmd_handler(). This results in the host side > driver hanging indefinitely waiting for the IRQ. > > Call pci_epf_test_raise_irq() when a transfer with DMA is requested but > DMA is unsupported. The host side driver will no longer hang but report > an error on transfer (printing "NOT OKAY") thanks to the checksum because > no data was moved. > > Clarify the error message in the endpoint function as "Cannot ..." is > vague and does not state the reason why it cannot be done. > > Signed-off-by: Rick Wertenbroek <rick.wertenbroek@gmail.com> > --- > drivers/pci/endpoint/functions/pci-epf-test.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c > index 7c2ed6eae53a..b02193cef06e 100644 > --- a/drivers/pci/endpoint/functions/pci-epf-test.c > +++ b/drivers/pci/endpoint/functions/pci-epf-test.c > @@ -649,7 +649,8 @@ static void pci_epf_test_cmd_handler(struct work_struct *work) > > if ((READ_ONCE(reg->flags) & FLAG_USE_DMA) && > !epf_test->dma_supported) { > - dev_err(dev, "Cannot transfer data using DMA\n"); > + dev_err(dev, "DMA transfer not supported\n"); Should we set the FAIL status flag here ? E.g.: reg->status |= STATUS_READ_FAIL; Note: I have no idea why the status flags are different for the different operations. We should really have a single SUCCESS/FAIL flag common to all operations. So I think we could just do: reg->status |= STATUS_READ_FAIL | STATUS_WRITE_FAIL | STATUS_COPY_FAIL; here, or go back to your v1 and handle the failure in each operation function to set the correct flag. > + pci_epf_test_raise_irq(epf_test, reg); > goto reset_handler; > } >
On Tue, Aug 20, 2024 at 10:18 AM Damien Le Moal <dlemoal@kernel.org> wrote: > > On 8/20/24 16:10, Rick Wertenbroek wrote: > > The pci-epf-test PCI endpoint function /drivers/pci/endpoint/function/pci-epf_test.c > > is meant to be used in a PCI endpoint device connected to a host computer > > with the host side driver: /drivers/misc/pci_endpoint_test.c. > > > > The host side driver can request read/write/copy transactions from the > > endpoint function and expects an IRQ from the endpoint function once > > the read/write/copy transaction is finished. These can be issued with or > > without DMA enabled. If the host side driver requests a read/write/copy > > transaction with DMA enabled and the endpoint function does not support > > DMA, the endpoint would only print an error message and wait for further > > commands without sending an IRQ because pci_epf_test_raise_irq() is > > skipped in pci_epf_test_cmd_handler(). This results in the host side > > driver hanging indefinitely waiting for the IRQ. > > > > Call pci_epf_test_raise_irq() when a transfer with DMA is requested but > > DMA is unsupported. The host side driver will no longer hang but report > > an error on transfer (printing "NOT OKAY") thanks to the checksum because > > no data was moved. > > > > Clarify the error message in the endpoint function as "Cannot ..." is > > vague and does not state the reason why it cannot be done. > > > > Signed-off-by: Rick Wertenbroek <rick.wertenbroek@gmail.com> > > --- > > drivers/pci/endpoint/functions/pci-epf-test.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c > > index 7c2ed6eae53a..b02193cef06e 100644 > > --- a/drivers/pci/endpoint/functions/pci-epf-test.c > > +++ b/drivers/pci/endpoint/functions/pci-epf-test.c > > @@ -649,7 +649,8 @@ static void pci_epf_test_cmd_handler(struct work_struct *work) > > > > if ((READ_ONCE(reg->flags) & FLAG_USE_DMA) && > > !epf_test->dma_supported) { > > - dev_err(dev, "Cannot transfer data using DMA\n"); > > + dev_err(dev, "DMA transfer not supported\n"); > > Should we set the FAIL status flag here ? > E.g.: > reg->status |= STATUS_READ_FAIL; > > Note: I have no idea why the status flags are different for the different > operations. We should really have a single SUCCESS/FAIL flag common to all > operations. So I think we could just do: > > reg->status |= STATUS_READ_FAIL | STATUS_WRITE_FAIL | > STATUS_COPY_FAIL; > > here, or go back to your v1 and handle the failure in each operation function to > set the correct flag. > Good catch, indeed with the check outside of the functions, the status FAIL bits are not set. I think setting the status as a combined fail flag makes sense, however, it conveys the idea that read/write/copy failed whereas only one of them actually failed. I agree that a single status SUCCESS/FAIL flag would be simpler. But changing this would require changes on both sides (EP & RC) and will reduce compatibility between EP and RC side driver versions, so I would refrain from changing this. I think I still prefer the v1/v2 code because even as it has a little bit of duplication it is clear and sets the correct FAIL bit without extra logic whereas here we either set all FAIL bits or have to add extra logic. Thank you for spotting this. > > + pci_epf_test_raise_irq(epf_test, reg); > > goto reset_handler; > > } > > > > -- > Damien Le Moal > Western Digital Research > Best regards, Rick
On 8/20/24 17:43, Rick Wertenbroek wrote: > On Tue, Aug 20, 2024 at 10:18 AM Damien Le Moal <dlemoal@kernel.org> wrote: >> >> On 8/20/24 16:10, Rick Wertenbroek wrote: >>> The pci-epf-test PCI endpoint function /drivers/pci/endpoint/function/pci-epf_test.c >>> is meant to be used in a PCI endpoint device connected to a host computer >>> with the host side driver: /drivers/misc/pci_endpoint_test.c. >>> >>> The host side driver can request read/write/copy transactions from the >>> endpoint function and expects an IRQ from the endpoint function once >>> the read/write/copy transaction is finished. These can be issued with or >>> without DMA enabled. If the host side driver requests a read/write/copy >>> transaction with DMA enabled and the endpoint function does not support >>> DMA, the endpoint would only print an error message and wait for further >>> commands without sending an IRQ because pci_epf_test_raise_irq() is >>> skipped in pci_epf_test_cmd_handler(). This results in the host side >>> driver hanging indefinitely waiting for the IRQ. >>> >>> Call pci_epf_test_raise_irq() when a transfer with DMA is requested but >>> DMA is unsupported. The host side driver will no longer hang but report >>> an error on transfer (printing "NOT OKAY") thanks to the checksum because >>> no data was moved. >>> >>> Clarify the error message in the endpoint function as "Cannot ..." is >>> vague and does not state the reason why it cannot be done. >>> >>> Signed-off-by: Rick Wertenbroek <rick.wertenbroek@gmail.com> >>> --- >>> drivers/pci/endpoint/functions/pci-epf-test.c | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c >>> index 7c2ed6eae53a..b02193cef06e 100644 >>> --- a/drivers/pci/endpoint/functions/pci-epf-test.c >>> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c >>> @@ -649,7 +649,8 @@ static void pci_epf_test_cmd_handler(struct work_struct *work) >>> >>> if ((READ_ONCE(reg->flags) & FLAG_USE_DMA) && >>> !epf_test->dma_supported) { >>> - dev_err(dev, "Cannot transfer data using DMA\n"); >>> + dev_err(dev, "DMA transfer not supported\n"); >> >> Should we set the FAIL status flag here ? >> E.g.: >> reg->status |= STATUS_READ_FAIL; >> >> Note: I have no idea why the status flags are different for the different >> operations. We should really have a single SUCCESS/FAIL flag common to all >> operations. So I think we could just do: >> >> reg->status |= STATUS_READ_FAIL | STATUS_WRITE_FAIL | >> STATUS_COPY_FAIL; >> >> here, or go back to your v1 and handle the failure in each operation function to >> set the correct flag. >> > > Good catch, indeed with the check outside of the functions, the status > FAIL bits are not set. I think setting the status as a combined fail > flag makes sense, however, it conveys the idea that read/write/copy > failed whereas only one of them actually failed. > > I agree that a single status SUCCESS/FAIL flag would be simpler. But > changing this would require changes on both sides (EP & RC) and will > reduce compatibility between EP and RC side driver versions, so I > would refrain from changing this. > > I think I still prefer the v1/v2 code because even as it has a little > bit of duplication it is clear and sets the correct FAIL bit without > extra logic whereas here we either set all FAIL bits or have to add > extra logic. > > Thank you for spotting this. Agree, v1 is cleaner in that respect, despite the duplicated checks. So my review tag stands :) Mani ? Thoughts ? > >>> + pci_epf_test_raise_irq(epf_test, reg); >>> goto reset_handler; >>> } >>> >> >> -- >> Damien Le Moal >> Western Digital Research >> > > Best regards, > Rick
On Tue, Aug 20, 2024 at 10:43:56AM +0200, Rick Wertenbroek wrote: > On Tue, Aug 20, 2024 at 10:18 AM Damien Le Moal <dlemoal@kernel.org> wrote: > > > > On 8/20/24 16:10, Rick Wertenbroek wrote: > > > The pci-epf-test PCI endpoint function /drivers/pci/endpoint/function/pci-epf_test.c > > > is meant to be used in a PCI endpoint device connected to a host computer > > > with the host side driver: /drivers/misc/pci_endpoint_test.c. > > > > > > The host side driver can request read/write/copy transactions from the > > > endpoint function and expects an IRQ from the endpoint function once > > > the read/write/copy transaction is finished. These can be issued with or > > > without DMA enabled. If the host side driver requests a read/write/copy > > > transaction with DMA enabled and the endpoint function does not support > > > DMA, the endpoint would only print an error message and wait for further > > > commands without sending an IRQ because pci_epf_test_raise_irq() is > > > skipped in pci_epf_test_cmd_handler(). This results in the host side > > > driver hanging indefinitely waiting for the IRQ. > > > > > > Call pci_epf_test_raise_irq() when a transfer with DMA is requested but > > > DMA is unsupported. The host side driver will no longer hang but report > > > an error on transfer (printing "NOT OKAY") thanks to the checksum because > > > no data was moved. > > > > > > Clarify the error message in the endpoint function as "Cannot ..." is > > > vague and does not state the reason why it cannot be done. > > > > > > Signed-off-by: Rick Wertenbroek <rick.wertenbroek@gmail.com> > > > --- > > > drivers/pci/endpoint/functions/pci-epf-test.c | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c > > > index 7c2ed6eae53a..b02193cef06e 100644 > > > --- a/drivers/pci/endpoint/functions/pci-epf-test.c > > > +++ b/drivers/pci/endpoint/functions/pci-epf-test.c > > > @@ -649,7 +649,8 @@ static void pci_epf_test_cmd_handler(struct work_struct *work) > > > > > > if ((READ_ONCE(reg->flags) & FLAG_USE_DMA) && > > > !epf_test->dma_supported) { > > > - dev_err(dev, "Cannot transfer data using DMA\n"); > > > + dev_err(dev, "DMA transfer not supported\n"); > > > > Should we set the FAIL status flag here ? > > E.g.: > > reg->status |= STATUS_READ_FAIL; > > > > Note: I have no idea why the status flags are different for the different > > operations. We should really have a single SUCCESS/FAIL flag common to all > > operations. So I think we could just do: > > > > reg->status |= STATUS_READ_FAIL | STATUS_WRITE_FAIL | > > STATUS_COPY_FAIL; > > > > here, or go back to your v1 and handle the failure in each operation function to > > set the correct flag. > > > > Good catch, indeed with the check outside of the functions, the status > FAIL bits are not set. I think setting the status as a combined fail > flag makes sense, however, it conveys the idea that read/write/copy > failed whereas only one of them actually failed. > > I agree that a single status SUCCESS/FAIL flag would be simpler. But > changing this would require changes on both sides (EP & RC) and will > reduce compatibility between EP and RC side driver versions, so I > would refrain from changing this. > I think it is OK to change the status flags and do the right thing. If someone reports a test failure, then we can ask them to upgrade their kernel. Given that this this just a test application, I don't think it is a big deal. - Mani > I think I still prefer the v1/v2 code because even as it has a little > bit of duplication it is clear and sets the correct FAIL bit without > extra logic whereas here we either set all FAIL bits or have to add > extra logic. > > Thank you for spotting this. > > > > + pci_epf_test_raise_irq(epf_test, reg); > > > goto reset_handler; > > > } > > > > > > > -- > > Damien Le Moal > > Western Digital Research > > > > Best regards, > Rick
diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c index 7c2ed6eae53a..b02193cef06e 100644 --- a/drivers/pci/endpoint/functions/pci-epf-test.c +++ b/drivers/pci/endpoint/functions/pci-epf-test.c @@ -649,7 +649,8 @@ static void pci_epf_test_cmd_handler(struct work_struct *work) if ((READ_ONCE(reg->flags) & FLAG_USE_DMA) && !epf_test->dma_supported) { - dev_err(dev, "Cannot transfer data using DMA\n"); + dev_err(dev, "DMA transfer not supported\n"); + pci_epf_test_raise_irq(epf_test, reg); goto reset_handler; }
The pci-epf-test PCI endpoint function /drivers/pci/endpoint/function/pci-epf_test.c is meant to be used in a PCI endpoint device connected to a host computer with the host side driver: /drivers/misc/pci_endpoint_test.c. The host side driver can request read/write/copy transactions from the endpoint function and expects an IRQ from the endpoint function once the read/write/copy transaction is finished. These can be issued with or without DMA enabled. If the host side driver requests a read/write/copy transaction with DMA enabled and the endpoint function does not support DMA, the endpoint would only print an error message and wait for further commands without sending an IRQ because pci_epf_test_raise_irq() is skipped in pci_epf_test_cmd_handler(). This results in the host side driver hanging indefinitely waiting for the IRQ. Call pci_epf_test_raise_irq() when a transfer with DMA is requested but DMA is unsupported. The host side driver will no longer hang but report an error on transfer (printing "NOT OKAY") thanks to the checksum because no data was moved. Clarify the error message in the endpoint function as "Cannot ..." is vague and does not state the reason why it cannot be done. Signed-off-by: Rick Wertenbroek <rick.wertenbroek@gmail.com> --- drivers/pci/endpoint/functions/pci-epf-test.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)