Some devices support MSI interrupts. Let's at least try to use them in
platforms that provide MSI capability.
Signed-off-by: Andy Shevchenko <[email protected]>
---
drivers/mfd/intel-lpss-pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/intel-lpss-pci.c b/drivers/mfd/intel-lpss-pci.c
index 8c00e0c695c5..c36a101df7be 100644
--- a/drivers/mfd/intel-lpss-pci.c
+++ b/drivers/mfd/intel-lpss-pci.c
@@ -54,7 +54,7 @@ static int intel_lpss_pci_probe(struct pci_dev *pdev,
if (ret)
return ret;
- ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_LEGACY);
+ ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_ALL_TYPES);
if (ret < 0)
return ret;
--
2.43.0.rc1.1.gbec44491f096
On Tue, 12 Mar 2024 18:59:05 +0200, Andy Shevchenko wrote:
> Some devices support MSI interrupts. Let's at least try to use them in
> platforms that provide MSI capability.
>
>
Applied, thanks!
[1/1] mfd: intel-lpss: Switch over to MSI interrupts
commit: c3bb2ec530c7dd358222838c3fdc04c178237db3
--
Lee Jones [李琼斯]
[+bcc Mateusz]
On Tue, Mar 12, 2024 at 06:59:05PM +0200, Andy Shevchenko wrote:
> Some devices support MSI interrupts. Let's at least try to use them in
> platforms that provide MSI capability.
>
> Signed-off-by: Andy Shevchenko <[email protected]>
> ---
> drivers/mfd/intel-lpss-pci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/intel-lpss-pci.c b/drivers/mfd/intel-lpss-pci.c
> index 8c00e0c695c5..c36a101df7be 100644
> --- a/drivers/mfd/intel-lpss-pci.c
> +++ b/drivers/mfd/intel-lpss-pci.c
> @@ -54,7 +54,7 @@ static int intel_lpss_pci_probe(struct pci_dev *pdev,
> if (ret)
> return ret;
>
> - ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_LEGACY);
> + ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_ALL_TYPES);
> if (ret < 0)
> return ret;
I guess at least some of these devices do support INTx, since we
always used INTx previously, right?
There are a bunch of bug reports complaining about a lack of _PRT
entries for them, e.g., these from
https://bugzilla.kernel.org/show_bug.cgi?id=212261#c24:
intel-lpss 0000:00:15.0: enabling device (0004 -> 0006)
intel-lpss 0000:00:15.0: can't derive routing for PCI INT A
intel-lpss 0000:00:15.0: PCI INT A: not connected
intel-lpss: probe of 0000:00:15.0 failed with error -22
intel-lpss 0000:00:15.2: enabling device (0004 -> 0006)
intel-lpss 0000:00:15.2: can't derive routing for PCI INT C
intel-lpss 0000:00:15.2: PCI INT C: not connected
intel-lpss: probe of 0000:00:15.2 failed with error -22
intel-lpss 0000:00:19.0: enabling device (0004 -> 0006)
intel-lpss 0000:00:19.0: can't derive routing for PCI INT A
intel-lpss 0000:00:19.0: PCI INT A: not connected
intel-lpss: probe of 0000:00:19.0 failed with error -22
intel-lpss 0000:00:19.1: enabling device (0004 -> 0006)
intel-lpss 0000:00:19.1: can't derive routing for PCI INT B
intel-lpss 0000:00:19.1: PCI INT B: not connected
intel-lpss: probe of 0000:00:19.1 failed with error -22
intel-lpss 0000:00:1e.0: enabling device (0004 -> 0006)
intel-lpss 0000:00:1e.0: can't derive routing for PCI INT A
intel-lpss 0000:00:1e.0: PCI INT A: not connected
intel-lpss: probe of 0000:00:1e.0 failed with error -22
intel-lpss 0000:00:1e.3: enabling device (0004 -> 0006)
intel-lpss 0000:00:1e.3: can't derive routing for PCI INT D
intel-lpss 0000:00:1e.3: PCI INT D: not connected
intel-lpss: probe of 0000:00:1e.3 failed with error -22
I don't know if these are a _PRT bug (I think if a device advertises a
non-zero Interrupt Pin, the _PRT should tell us how it is routed), or
possibly a device bug (advertises Interrupt Pin == INTA when it should
advertise "no INTx used"), or something else.
Bjorn
I tried the patch that changes PCI_IRQ_LEGACY into PCI_IRQ_ALL_TYPES
and it seems I get some other error now
[ 1.477341] intel-lpss 0000:00:15.0: enabling device (0004 -> 0006)
[ 1.477466] intel-lpss 0000:00:15.0: can't derive routing for PCI INT A
[ 1.477468] intel-lpss 0000:00:15.0: PCI INT A: not connected
[ 1.477488] intel-lpss 0000:00:15.0: probe with driver intel-lpss
failed with error -2147483648
[ 1.489572] intel-lpss 0000:00:15.2: enabling device (0004 -> 0006)
[ 1.489688] intel-lpss 0000:00:15.2: can't derive routing for PCI INT C
[ 1.489689] intel-lpss 0000:00:15.2: PCI INT C: not connected
[ 1.489715] intel-lpss 0000:00:15.2: probe with driver intel-lpss
failed with error -2147483648
[ 1.501886] intel-lpss 0000:00:19.0: enabling device (0004 -> 0006)
[ 1.502034] intel-lpss 0000:00:19.0: can't derive routing for PCI INT A
[ 1.502036] intel-lpss 0000:00:19.0: PCI INT A: not connected
[ 1.502067] intel-lpss 0000:00:19.0: probe with driver intel-lpss
failed with error -2147483648
[ 1.514288] intel-lpss 0000:00:19.1: enabling device (0004 -> 0006)
[ 1.514535] intel-lpss 0000:00:19.1: can't derive routing for PCI INT B
[ 1.514538] intel-lpss 0000:00:19.1: PCI INT B: not connected
[ 1.514570] intel-lpss 0000:00:19.1: probe with driver intel-lpss
failed with error -2147483648
[ 1.526291] intel-lpss 0000:00:1e.0: enabling device (0004 -> 0006)
[ 1.526555] intel-lpss 0000:00:1e.0: can't derive routing for PCI INT A
[ 1.526557] intel-lpss 0000:00:1e.0: PCI INT A: not connected
[ 1.526604] intel-lpss 0000:00:1e.0: probe with driver intel-lpss
failed with error -2147483648
[ 1.538130] intel-lpss 0000:00:1e.3: enabling device (0004 -> 0006)
[ 1.538233] intel-lpss 0000:00:1e.3: can't derive routing for PCI INT D
[ 1.538235] intel-lpss 0000:00:1e.3: PCI INT D: not connected
[ 1.538253] intel-lpss 0000:00:1e.3: probe with driver intel-lpss
failed with error -2147483648
Mateusz
On Mon, Mar 25, 2024 at 10:19 PM Bjorn Helgaas <[email protected]> wrote:
>
> [+bcc Mateusz]
>
> On Tue, Mar 12, 2024 at 06:59:05PM +0200, Andy Shevchenko wrote:
> > Some devices support MSI interrupts. Let's at least try to use them in
> > platforms that provide MSI capability.
> >
> > Signed-off-by: Andy Shevchenko <[email protected]>
> > ---
> > drivers/mfd/intel-lpss-pci.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/mfd/intel-lpss-pci.c b/drivers/mfd/intel-lpss-pci.c
> > index 8c00e0c695c5..c36a101df7be 100644
> > --- a/drivers/mfd/intel-lpss-pci.c
> > +++ b/drivers/mfd/intel-lpss-pci.c
> > @@ -54,7 +54,7 @@ static int intel_lpss_pci_probe(struct pci_dev *pdev,
> > if (ret)
> > return ret;
> >
> > - ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_LEGACY);
> > + ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_ALL_TYPES);
> > if (ret < 0)
> > return ret;
>
> I guess at least some of these devices do support INTx, since we
> always used INTx previously, right?
>
> There are a bunch of bug reports complaining about a lack of _PRT
> entries for them, e.g., these from
> https://bugzilla.kernel.org/show_bug.cgi?id=212261#c24:
>
> intel-lpss 0000:00:15.0: enabling device (0004 -> 0006)
> intel-lpss 0000:00:15.0: can't derive routing for PCI INT A
> intel-lpss 0000:00:15.0: PCI INT A: not connected
> intel-lpss: probe of 0000:00:15.0 failed with error -22
> intel-lpss 0000:00:15.2: enabling device (0004 -> 0006)
> intel-lpss 0000:00:15.2: can't derive routing for PCI INT C
> intel-lpss 0000:00:15.2: PCI INT C: not connected
> intel-lpss: probe of 0000:00:15.2 failed with error -22
> intel-lpss 0000:00:19.0: enabling device (0004 -> 0006)
> intel-lpss 0000:00:19.0: can't derive routing for PCI INT A
> intel-lpss 0000:00:19.0: PCI INT A: not connected
> intel-lpss: probe of 0000:00:19.0 failed with error -22
> intel-lpss 0000:00:19.1: enabling device (0004 -> 0006)
> intel-lpss 0000:00:19.1: can't derive routing for PCI INT B
> intel-lpss 0000:00:19.1: PCI INT B: not connected
> intel-lpss: probe of 0000:00:19.1 failed with error -22
> intel-lpss 0000:00:1e.0: enabling device (0004 -> 0006)
> intel-lpss 0000:00:1e.0: can't derive routing for PCI INT A
> intel-lpss 0000:00:1e.0: PCI INT A: not connected
> intel-lpss: probe of 0000:00:1e.0 failed with error -22
> intel-lpss 0000:00:1e.3: enabling device (0004 -> 0006)
> intel-lpss 0000:00:1e.3: can't derive routing for PCI INT D
> intel-lpss 0000:00:1e.3: PCI INT D: not connected
> intel-lpss: probe of 0000:00:1e.3 failed with error -22
>
> I don't know if these are a _PRT bug (I think if a device advertises a
> non-zero Interrupt Pin, the _PRT should tell us how it is routed), or
> possibly a device bug (advertises Interrupt Pin == INTA when it should
> advertise "no INTx used"), or something else.
>
> Bjorn
On Tue, Mar 26, 2024 at 11:06:38AM +0100, Mateusz K wrote:
> I tried the patch that changes PCI_IRQ_LEGACY into PCI_IRQ_ALL_TYPES
> and it seems I get some other error now
>
> [ 1.477341] intel-lpss 0000:00:15.0: enabling device (0004 -> 0006)
> [ 1.477466] intel-lpss 0000:00:15.0: can't derive routing for PCI INT A
> [ 1.477468] intel-lpss 0000:00:15.0: PCI INT A: not connected
> [ 1.477488] intel-lpss 0000:00:15.0: probe with driver intel-lpss
> failed with error -2147483648
> [ 1.489572] intel-lpss 0000:00:15.2: enabling device (0004 -> 0006)
> [ 1.489688] intel-lpss 0000:00:15.2: can't derive routing for PCI INT C
> [ 1.489689] intel-lpss 0000:00:15.2: PCI INT C: not connected
> [ 1.489715] intel-lpss 0000:00:15.2: probe with driver intel-lpss
> failed with error -2147483648
> [ 1.501886] intel-lpss 0000:00:19.0: enabling device (0004 -> 0006)
> [ 1.502034] intel-lpss 0000:00:19.0: can't derive routing for PCI INT A
> [ 1.502036] intel-lpss 0000:00:19.0: PCI INT A: not connected
> [ 1.502067] intel-lpss 0000:00:19.0: probe with driver intel-lpss
> failed with error -2147483648
> [ 1.514288] intel-lpss 0000:00:19.1: enabling device (0004 -> 0006)
> [ 1.514535] intel-lpss 0000:00:19.1: can't derive routing for PCI INT B
> [ 1.514538] intel-lpss 0000:00:19.1: PCI INT B: not connected
> [ 1.514570] intel-lpss 0000:00:19.1: probe with driver intel-lpss
> failed with error -2147483648
> [ 1.526291] intel-lpss 0000:00:1e.0: enabling device (0004 -> 0006)
> [ 1.526555] intel-lpss 0000:00:1e.0: can't derive routing for PCI INT A
> [ 1.526557] intel-lpss 0000:00:1e.0: PCI INT A: not connected
> [ 1.526604] intel-lpss 0000:00:1e.0: probe with driver intel-lpss
> failed with error -2147483648
> [ 1.538130] intel-lpss 0000:00:1e.3: enabling device (0004 -> 0006)
> [ 1.538233] intel-lpss 0000:00:1e.3: can't derive routing for PCI INT D
> [ 1.538235] intel-lpss 0000:00:1e.3: PCI INT D: not connected
> [ 1.538253] intel-lpss 0000:00:1e.3: probe with driver intel-lpss
> failed with error -2147483648
Hmm... I have a unique board to test :-)
Let's revert it then.
Bjorn, in such case your tree should keep conversion one.
Lee, do you prefer a revert or can you simply drop this from the queue?
--
With Best Regards,
Andy Shevchenko
Maybe it's much to ask, but I would really appreciate it if someone
looked into intel-lpss supporting these devices.
Been using a laptop without a functional touchpad over months now.
If that helps, there is another thread here
https://bugzilla.kernel.org/show_bug.cgi?id=218444 with perhaps more
details on the problem.
Battery and speaker are not a big deal, but the not working touchpad,
which I believe should be handled by an intel-lpss driver, is kind of
painful.
If you need any help from my side, testing patches, don't hesitate to
contact me.
Regards,
Mateusz
On Tue, Mar 26, 2024 at 3:41 PM Andy Shevchenko
<[email protected]> wrote:
>
> On Tue, Mar 26, 2024 at 11:06:38AM +0100, Mateusz K wrote:
> > I tried the patch that changes PCI_IRQ_LEGACY into PCI_IRQ_ALL_TYPES
> > and it seems I get some other error now
> >
> > [ 1.477341] intel-lpss 0000:00:15.0: enabling device (0004 -> 0006)
> > [ 1.477466] intel-lpss 0000:00:15.0: can't derive routing for PCI INT A
> > [ 1.477468] intel-lpss 0000:00:15.0: PCI INT A: not connected
> > [ 1.477488] intel-lpss 0000:00:15.0: probe with driver intel-lpss
> > failed with error -2147483648
> > [ 1.489572] intel-lpss 0000:00:15.2: enabling device (0004 -> 0006)
> > [ 1.489688] intel-lpss 0000:00:15.2: can't derive routing for PCI INT C
> > [ 1.489689] intel-lpss 0000:00:15.2: PCI INT C: not connected
> > [ 1.489715] intel-lpss 0000:00:15.2: probe with driver intel-lpss
> > failed with error -2147483648
> > [ 1.501886] intel-lpss 0000:00:19.0: enabling device (0004 -> 0006)
> > [ 1.502034] intel-lpss 0000:00:19.0: can't derive routing for PCI INT A
> > [ 1.502036] intel-lpss 0000:00:19.0: PCI INT A: not connected
> > [ 1.502067] intel-lpss 0000:00:19.0: probe with driver intel-lpss
> > failed with error -2147483648
> > [ 1.514288] intel-lpss 0000:00:19.1: enabling device (0004 -> 0006)
> > [ 1.514535] intel-lpss 0000:00:19.1: can't derive routing for PCI INT B
> > [ 1.514538] intel-lpss 0000:00:19.1: PCI INT B: not connected
> > [ 1.514570] intel-lpss 0000:00:19.1: probe with driver intel-lpss
> > failed with error -2147483648
> > [ 1.526291] intel-lpss 0000:00:1e.0: enabling device (0004 -> 0006)
> > [ 1.526555] intel-lpss 0000:00:1e.0: can't derive routing for PCI INT A
> > [ 1.526557] intel-lpss 0000:00:1e.0: PCI INT A: not connected
> > [ 1.526604] intel-lpss 0000:00:1e.0: probe with driver intel-lpss
> > failed with error -2147483648
> > [ 1.538130] intel-lpss 0000:00:1e.3: enabling device (0004 -> 0006)
> > [ 1.538233] intel-lpss 0000:00:1e.3: can't derive routing for PCI INT D
> > [ 1.538235] intel-lpss 0000:00:1e.3: PCI INT D: not connected
> > [ 1.538253] intel-lpss 0000:00:1e.3: probe with driver intel-lpss
> > failed with error -2147483648
>
> Hmm... I have a unique board to test :-)
> Let's revert it then.
>
> Bjorn, in such case your tree should keep conversion one.
>
> Lee, do you prefer a revert or can you simply drop this from the queue?
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
Please, do not top post in the mailing lists!
On Tue, Mar 26, 2024 at 03:50:37PM +0100, Mateusz K wrote:
> Maybe it's much to ask, but I would really appreciate it if someone
> looked into intel-lpss supporting these devices.
> Been using a laptop without a functional touchpad over months now.
> If that helps, there is another thread here
> https://bugzilla.kernel.org/show_bug.cgi?id=218444 with perhaps more
> details on the problem.
> Battery and speaker are not a big deal, but the not working touchpad,
> which I believe should be handled by an intel-lpss driver, is kind of
> painful.
> If you need any help from my side, testing patches, don't hesitate to
> contact me.
I will look at the report closer, but I can't guarantee anything.
> On Tue, Mar 26, 2024 at 3:41 PM Andy Shevchenko
> <[email protected]> wrote:
> >
> > On Tue, Mar 26, 2024 at 11:06:38AM +0100, Mateusz K wrote:
> > > I tried the patch that changes PCI_IRQ_LEGACY into PCI_IRQ_ALL_TYPES
> > > and it seems I get some other error now
> > >
> > > [ 1.477341] intel-lpss 0000:00:15.0: enabling device (0004 -> 0006)
> > > [ 1.477466] intel-lpss 0000:00:15.0: can't derive routing for PCI INT A
> > > [ 1.477468] intel-lpss 0000:00:15.0: PCI INT A: not connected
> > > [ 1.477488] intel-lpss 0000:00:15.0: probe with driver intel-lpss
> > > failed with error -2147483648
> > > [ 1.489572] intel-lpss 0000:00:15.2: enabling device (0004 -> 0006)
> > > [ 1.489688] intel-lpss 0000:00:15.2: can't derive routing for PCI INT C
> > > [ 1.489689] intel-lpss 0000:00:15.2: PCI INT C: not connected
> > > [ 1.489715] intel-lpss 0000:00:15.2: probe with driver intel-lpss
> > > failed with error -2147483648
> > > [ 1.501886] intel-lpss 0000:00:19.0: enabling device (0004 -> 0006)
> > > [ 1.502034] intel-lpss 0000:00:19.0: can't derive routing for PCI INT A
> > > [ 1.502036] intel-lpss 0000:00:19.0: PCI INT A: not connected
> > > [ 1.502067] intel-lpss 0000:00:19.0: probe with driver intel-lpss
> > > failed with error -2147483648
> > > [ 1.514288] intel-lpss 0000:00:19.1: enabling device (0004 -> 0006)
> > > [ 1.514535] intel-lpss 0000:00:19.1: can't derive routing for PCI INT B
> > > [ 1.514538] intel-lpss 0000:00:19.1: PCI INT B: not connected
> > > [ 1.514570] intel-lpss 0000:00:19.1: probe with driver intel-lpss
> > > failed with error -2147483648
> > > [ 1.526291] intel-lpss 0000:00:1e.0: enabling device (0004 -> 0006)
> > > [ 1.526555] intel-lpss 0000:00:1e.0: can't derive routing for PCI INT A
> > > [ 1.526557] intel-lpss 0000:00:1e.0: PCI INT A: not connected
> > > [ 1.526604] intel-lpss 0000:00:1e.0: probe with driver intel-lpss
> > > failed with error -2147483648
> > > [ 1.538130] intel-lpss 0000:00:1e.3: enabling device (0004 -> 0006)
> > > [ 1.538233] intel-lpss 0000:00:1e.3: can't derive routing for PCI INT D
> > > [ 1.538235] intel-lpss 0000:00:1e.3: PCI INT D: not connected
> > > [ 1.538253] intel-lpss 0000:00:1e.3: probe with driver intel-lpss
> > > failed with error -2147483648
> >
> > Hmm... I have a unique board to test :-)
> > Let's revert it then.
> >
> > Bjorn, in such case your tree should keep conversion one.
> >
> > Lee, do you prefer a revert or can you simply drop this from the queue?
--
With Best Regards,
Andy Shevchenko
On Tue, Mar 26, 2024 at 04:41:01PM +0200, Andy Shevchenko wrote:
> On Tue, Mar 26, 2024 at 11:06:38AM +0100, Mateusz K wrote:
> > I tried the patch that changes PCI_IRQ_LEGACY into PCI_IRQ_ALL_TYPES
> > and it seems I get some other error now
> >
> > [ 1.477341] intel-lpss 0000:00:15.0: enabling device (0004 -> 0006)
> > [ 1.477466] intel-lpss 0000:00:15.0: can't derive routing for PCI INT A
> > [ 1.477468] intel-lpss 0000:00:15.0: PCI INT A: not connected
> > [ 1.477488] intel-lpss 0000:00:15.0: probe with driver intel-lpss
> > failed with error -2147483648
> > [ 1.489572] intel-lpss 0000:00:15.2: enabling device (0004 -> 0006)
> > [ 1.489688] intel-lpss 0000:00:15.2: can't derive routing for PCI INT C
> > [ 1.489689] intel-lpss 0000:00:15.2: PCI INT C: not connected
> > [ 1.489715] intel-lpss 0000:00:15.2: probe with driver intel-lpss
> > failed with error -2147483648
> > [ 1.501886] intel-lpss 0000:00:19.0: enabling device (0004 -> 0006)
> > [ 1.502034] intel-lpss 0000:00:19.0: can't derive routing for PCI INT A
> > [ 1.502036] intel-lpss 0000:00:19.0: PCI INT A: not connected
> > [ 1.502067] intel-lpss 0000:00:19.0: probe with driver intel-lpss
> > failed with error -2147483648
> > [ 1.514288] intel-lpss 0000:00:19.1: enabling device (0004 -> 0006)
> > [ 1.514535] intel-lpss 0000:00:19.1: can't derive routing for PCI INT B
> > [ 1.514538] intel-lpss 0000:00:19.1: PCI INT B: not connected
> > [ 1.514570] intel-lpss 0000:00:19.1: probe with driver intel-lpss
> > failed with error -2147483648
> > [ 1.526291] intel-lpss 0000:00:1e.0: enabling device (0004 -> 0006)
> > [ 1.526555] intel-lpss 0000:00:1e.0: can't derive routing for PCI INT A
> > [ 1.526557] intel-lpss 0000:00:1e.0: PCI INT A: not connected
> > [ 1.526604] intel-lpss 0000:00:1e.0: probe with driver intel-lpss
> > failed with error -2147483648
> > [ 1.538130] intel-lpss 0000:00:1e.3: enabling device (0004 -> 0006)
> > [ 1.538233] intel-lpss 0000:00:1e.3: can't derive routing for PCI INT D
> > [ 1.538235] intel-lpss 0000:00:1e.3: PCI INT D: not connected
> > [ 1.538253] intel-lpss 0000:00:1e.3: probe with driver intel-lpss
> > failed with error -2147483648
>
> Hmm... I have a unique board to test :-)
> Let's revert it then.
>
> Bjorn, in such case your tree should keep conversion one.
>
> Lee, do you prefer a revert or can you simply drop this from the queue?
Hold on, but IIUC this is the report about new hardware that never had
a support by Linux before.
--
With Best Regards,
Andy Shevchenko
On Mon, Mar 25, 2024 at 04:19:15PM -0500, Bjorn Helgaas wrote:
> On Tue, Mar 12, 2024 at 06:59:05PM +0200, Andy Shevchenko wrote:
..
> > - ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_LEGACY);
> > + ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_ALL_TYPES);
> > if (ret < 0)
> > return ret;
>
> I guess at least some of these devices do support INTx, since we
> always used INTx previously, right?
>
> There are a bunch of bug reports complaining about a lack of _PRT
> entries for them, e.g., these from
> https://bugzilla.kernel.org/show_bug.cgi?id=212261#c24:
But this is not related to my patch, and the mentioned bug report seems about
all AMD and Intel platforms.
Can you, please, elaborate what the relation to my patch?
--
With Best Regards,
Andy Shevchenko
On Tue, Mar 26, 2024 at 06:21:47PM +0200, Andy Shevchenko wrote:
> On Mon, Mar 25, 2024 at 04:19:15PM -0500, Bjorn Helgaas wrote:
> > On Tue, Mar 12, 2024 at 06:59:05PM +0200, Andy Shevchenko wrote:
>
> ...
>
> > > - ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_LEGACY);
> > > + ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_ALL_TYPES);
> > > if (ret < 0)
> > > return ret;
> >
> > I guess at least some of these devices do support INTx, since we
> > always used INTx previously, right?
> >
> > There are a bunch of bug reports complaining about a lack of _PRT
> > entries for them, e.g., these from
> > https://bugzilla.kernel.org/show_bug.cgi?id=212261#c24:
>
> But this is not related to my patch, and the mentioned bug report seems about
> all AMD and Intel platforms.
>
> Can you, please, elaborate what the relation to my patch?
Right, sorry I didn't make that clear; I didn't mean that it was
related to your patch. I was just looking at this old bug report
about not being able to figure out INTx routing.
Your patch had to do with interrupts, so I just wondered whether you
had insight into whether these devices actually used INTx. My guess
is that at least some of them *do* use INTx, because prior to your
patch, the driver *only* tried to use INTx.
If it happend that they never use INTx, but advertise INTA via
Interrupt Pin, I think that would be a device defect that we might
consider a quirk for.
If they *do* use INTx, and the _PRT doesn't tell us how it's routed, I
think that would be a firmware defect, and ... I dunno what we would
do. I guess just avoid using INTx because we don't know where the
interupt goes.
Bjorn
On Tue, Mar 26, 2024 at 04:01:07PM -0500, Bjorn Helgaas wrote:
> On Tue, Mar 26, 2024 at 06:21:47PM +0200, Andy Shevchenko wrote:
> > On Mon, Mar 25, 2024 at 04:19:15PM -0500, Bjorn Helgaas wrote:
> > > On Tue, Mar 12, 2024 at 06:59:05PM +0200, Andy Shevchenko wrote:
..
> > > > - ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_LEGACY);
> > > > + ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_ALL_TYPES);
> > > > if (ret < 0)
> > > > return ret;
> > >
> > > I guess at least some of these devices do support INTx, since we
> > > always used INTx previously, right?
> > >
> > > There are a bunch of bug reports complaining about a lack of _PRT
> > > entries for them, e.g., these from
> > > https://bugzilla.kernel.org/show_bug.cgi?id=212261#c24:
> >
> > But this is not related to my patch, and the mentioned bug report seems about
> > all AMD and Intel platforms.
> >
> > Can you, please, elaborate what the relation to my patch?
>
> Right, sorry I didn't make that clear; I didn't mean that it was
> related to your patch. I was just looking at this old bug report
> about not being able to figure out INTx routing.
>
> Your patch had to do with interrupts, so I just wondered whether you
> had insight into whether these devices actually used INTx. My guess
> is that at least some of them *do* use INTx, because prior to your
> patch, the driver *only* tried to use INTx.
>
> If it happend that they never use INTx, but advertise INTA via
> Interrupt Pin, I think that would be a device defect that we might
> consider a quirk for.
>
> If they *do* use INTx, and the _PRT doesn't tell us how it's routed, I
> think that would be a firmware defect, and ... I dunno what we would
> do. I guess just avoid using INTx because we don't know where the
> interupt goes.
Okay, so the revert after all is not required, do you agree?
--
With Best Regards,
Andy Shevchenko
On Tue, Mar 26, 2024 at 11:22:16PM +0200, Andy Shevchenko wrote:
> On Tue, Mar 26, 2024 at 04:01:07PM -0500, Bjorn Helgaas wrote:
> > On Tue, Mar 26, 2024 at 06:21:47PM +0200, Andy Shevchenko wrote:
> > > On Mon, Mar 25, 2024 at 04:19:15PM -0500, Bjorn Helgaas wrote:
> > > > On Tue, Mar 12, 2024 at 06:59:05PM +0200, Andy Shevchenko wrote:
>
> ...
>
> > > > > - ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_LEGACY);
> > > > > + ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_ALL_TYPES);
> > > > > if (ret < 0)
> > > > > return ret;
> > > >
> > > > I guess at least some of these devices do support INTx, since we
> > > > always used INTx previously, right?
> > > >
> > > > There are a bunch of bug reports complaining about a lack of _PRT
> > > > entries for them, e.g., these from
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=212261#c24:
> > >
> > > But this is not related to my patch, and the mentioned bug report seems about
> > > all AMD and Intel platforms.
> > >
> > > Can you, please, elaborate what the relation to my patch?
> >
> > Right, sorry I didn't make that clear; I didn't mean that it was
> > related to your patch. I was just looking at this old bug report
> > about not being able to figure out INTx routing.
> >
> > Your patch had to do with interrupts, so I just wondered whether you
> > had insight into whether these devices actually used INTx. My guess
> > is that at least some of them *do* use INTx, because prior to your
> > patch, the driver *only* tried to use INTx.
> >
> > If it happend that they never use INTx, but advertise INTA via
> > Interrupt Pin, I think that would be a device defect that we might
> > consider a quirk for.
> >
> > If they *do* use INTx, and the _PRT doesn't tell us how it's routed, I
> > think that would be a firmware defect, and ... I dunno what we would
> > do. I guess just avoid using INTx because we don't know where the
> > interupt goes.
>
> Okay, so the revert after all is not required, do you agree?
Yes, I agree! No indication of problems with your patch, AFAICS.
If you have any opinions or ideas on the "can't derive routing for PCI
INT A" stuff, I'd still be interested, because it really annoys users.
Bjorn
On Tue, Mar 26, 2024 at 05:09:53PM -0500, Bjorn Helgaas wrote:
> On Tue, Mar 26, 2024 at 11:22:16PM +0200, Andy Shevchenko wrote:
> > On Tue, Mar 26, 2024 at 04:01:07PM -0500, Bjorn Helgaas wrote:
> > > On Tue, Mar 26, 2024 at 06:21:47PM +0200, Andy Shevchenko wrote:
> > > > On Mon, Mar 25, 2024 at 04:19:15PM -0500, Bjorn Helgaas wrote:
> > > > > On Tue, Mar 12, 2024 at 06:59:05PM +0200, Andy Shevchenko wrote:
..
> > > > > > - ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_LEGACY);
> > > > > > + ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_ALL_TYPES);
> > > > > > if (ret < 0)
> > > > > > return ret;
> > > > >
> > > > > I guess at least some of these devices do support INTx, since we
> > > > > always used INTx previously, right?
> > > > >
> > > > > There are a bunch of bug reports complaining about a lack of _PRT
> > > > > entries for them, e.g., these from
> > > > > https://bugzilla.kernel.org/show_bug.cgi?id=212261#c24:
> > > >
> > > > But this is not related to my patch, and the mentioned bug report seems about
> > > > all AMD and Intel platforms.
> > > >
> > > > Can you, please, elaborate what the relation to my patch?
> > >
> > > Right, sorry I didn't make that clear; I didn't mean that it was
> > > related to your patch. I was just looking at this old bug report
> > > about not being able to figure out INTx routing.
> > >
> > > Your patch had to do with interrupts, so I just wondered whether you
> > > had insight into whether these devices actually used INTx. My guess
> > > is that at least some of them *do* use INTx, because prior to your
> > > patch, the driver *only* tried to use INTx.
> > >
> > > If it happend that they never use INTx, but advertise INTA via
> > > Interrupt Pin, I think that would be a device defect that we might
> > > consider a quirk for.
> > >
> > > If they *do* use INTx, and the _PRT doesn't tell us how it's routed, I
> > > think that would be a firmware defect, and ... I dunno what we would
> > > do. I guess just avoid using INTx because we don't know where the
> > > interupt goes.
> >
> > Okay, so the revert after all is not required, do you agree?
>
> Yes, I agree! No indication of problems with your patch, AFAICS.
>
> If you have any opinions or ideas on the "can't derive routing for PCI
> INT A" stuff, I'd still be interested, because it really annoys users.
Got it, thank you for clarification!
--
With Best Regards,
Andy Shevchenko
On Wed, Mar 27, 2024 at 01:17:11PM +0000, Lee Jones wrote:
> On Tue, 26 Mar 2024, Andy Shevchenko wrote:
> > On Tue, Mar 26, 2024 at 04:41:01PM +0200, Andy Shevchenko wrote:
..
> > Hold on, but IIUC this is the report about new hardware that never had
> > a support by Linux before.
>
> So a revert is no longer required?
No, it seems an old issue unrelated to this patch.
--
With Best Regards,
Andy Shevchenko
On Tue, 26 Mar 2024, Andy Shevchenko wrote:
> On Tue, Mar 26, 2024 at 04:41:01PM +0200, Andy Shevchenko wrote:
> > On Tue, Mar 26, 2024 at 11:06:38AM +0100, Mateusz K wrote:
> > > I tried the patch that changes PCI_IRQ_LEGACY into PCI_IRQ_ALL_TYPES
> > > and it seems I get some other error now
> > >
> > > [ 1.477341] intel-lpss 0000:00:15.0: enabling device (0004 -> 0006)
> > > [ 1.477466] intel-lpss 0000:00:15.0: can't derive routing for PCI INT A
> > > [ 1.477468] intel-lpss 0000:00:15.0: PCI INT A: not connected
> > > [ 1.477488] intel-lpss 0000:00:15.0: probe with driver intel-lpss
> > > failed with error -2147483648
> > > [ 1.489572] intel-lpss 0000:00:15.2: enabling device (0004 -> 0006)
> > > [ 1.489688] intel-lpss 0000:00:15.2: can't derive routing for PCI INT C
> > > [ 1.489689] intel-lpss 0000:00:15.2: PCI INT C: not connected
> > > [ 1.489715] intel-lpss 0000:00:15.2: probe with driver intel-lpss
> > > failed with error -2147483648
> > > [ 1.501886] intel-lpss 0000:00:19.0: enabling device (0004 -> 0006)
> > > [ 1.502034] intel-lpss 0000:00:19.0: can't derive routing for PCI INT A
> > > [ 1.502036] intel-lpss 0000:00:19.0: PCI INT A: not connected
> > > [ 1.502067] intel-lpss 0000:00:19.0: probe with driver intel-lpss
> > > failed with error -2147483648
> > > [ 1.514288] intel-lpss 0000:00:19.1: enabling device (0004 -> 0006)
> > > [ 1.514535] intel-lpss 0000:00:19.1: can't derive routing for PCI INT B
> > > [ 1.514538] intel-lpss 0000:00:19.1: PCI INT B: not connected
> > > [ 1.514570] intel-lpss 0000:00:19.1: probe with driver intel-lpss
> > > failed with error -2147483648
> > > [ 1.526291] intel-lpss 0000:00:1e.0: enabling device (0004 -> 0006)
> > > [ 1.526555] intel-lpss 0000:00:1e.0: can't derive routing for PCI INT A
> > > [ 1.526557] intel-lpss 0000:00:1e.0: PCI INT A: not connected
> > > [ 1.526604] intel-lpss 0000:00:1e.0: probe with driver intel-lpss
> > > failed with error -2147483648
> > > [ 1.538130] intel-lpss 0000:00:1e.3: enabling device (0004 -> 0006)
> > > [ 1.538233] intel-lpss 0000:00:1e.3: can't derive routing for PCI INT D
> > > [ 1.538235] intel-lpss 0000:00:1e.3: PCI INT D: not connected
> > > [ 1.538253] intel-lpss 0000:00:1e.3: probe with driver intel-lpss
> > > failed with error -2147483648
> >
> > Hmm... I have a unique board to test :-)
> > Let's revert it then.
> >
> > Bjorn, in such case your tree should keep conversion one.
> >
> > Lee, do you prefer a revert or can you simply drop this from the queue?
>
> Hold on, but IIUC this is the report about new hardware that never had
> a support by Linux before.
So a revert is no longer required?
--
Lee Jones [李琼斯]
On Wed, Mar 27, 2024 at 02:12:29PM +0000, Lee Jones wrote:
> On Wed, 27 Mar 2024, Andy Shevchenko wrote:
> > On Wed, Mar 27, 2024 at 01:17:11PM +0000, Lee Jones wrote:
> > > On Tue, 26 Mar 2024, Andy Shevchenko wrote:
> > > > On Tue, Mar 26, 2024 at 04:41:01PM +0200, Andy Shevchenko wrote:
..
> > > > Hold on, but IIUC this is the report about new hardware that never had
> > > > a support by Linux before.
> > >
> > > So a revert is no longer required?
> >
> > No, it seems an old issue unrelated to this patch.
>
> Very well, consider it *not* done. :)
Thank you!
--
With Best Regards,
Andy Shevchenko
On Wed, 27 Mar 2024, Andy Shevchenko wrote:
> On Wed, Mar 27, 2024 at 01:17:11PM +0000, Lee Jones wrote:
> > On Tue, 26 Mar 2024, Andy Shevchenko wrote:
> > > On Tue, Mar 26, 2024 at 04:41:01PM +0200, Andy Shevchenko wrote:
>
> ...
>
> > > Hold on, but IIUC this is the report about new hardware that never had
> > > a support by Linux before.
> >
> > So a revert is no longer required?
>
> No, it seems an old issue unrelated to this patch.
Very well, consider it *not* done. :)
--
Lee Jones [李琼斯]