Re: [PATCH] mmc: sdhci: Avoid needless loop while handling SDIO interrupts in sdhci_irq()
[yet another patch ping] On Tuesday, November 05, 2013 07:40:36 PM Alexey Neyman wrote: > Ignore Card Interrupt bit in the interrupt status if we already know that > mmc_signal_sdio_irq() is going to be called at the end of sdhci_irq(). This > avoids a needless loop in sdhci_irq() repeatedly reading interrupt status > and doing nothing. > > Signed-off-by: Alexey Neyman > Acked-by: Dong Aisheng > --- > drivers/mmc/host/sdhci.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c > index 7a7fb4f..a83cd1b 100644 > --- a/drivers/mmc/host/sdhci.c > +++ b/drivers/mmc/host/sdhci.c > @@ -2491,6 +2491,14 @@ again: > result = IRQ_HANDLED; > > intmask = sdhci_readl(host, SDHCI_INT_STATUS); > + > + /* > + * If we know we'll call the driver to signal SDIO IRQ, disregard > + * further indications of Card Interrupt in the status to avoid a > + * needless loop. > + */ > + if (cardint) > + intmask &= ~SDHCI_INT_CARD_INT; > if (intmask && --max_loops) > goto again; > out: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: sdhci: Avoid needless loop while handling SDIO interrupts in sdhci_irq()
[yet another patch ping] On Tuesday, November 05, 2013 07:40:36 PM Alexey Neyman wrote: Ignore Card Interrupt bit in the interrupt status if we already know that mmc_signal_sdio_irq() is going to be called at the end of sdhci_irq(). This avoids a needless loop in sdhci_irq() repeatedly reading interrupt status and doing nothing. Signed-off-by: Alexey Neyman sti...@att.net Acked-by: Dong Aisheng b29...@freescale.com --- drivers/mmc/host/sdhci.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 7a7fb4f..a83cd1b 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -2491,6 +2491,14 @@ again: result = IRQ_HANDLED; intmask = sdhci_readl(host, SDHCI_INT_STATUS); + + /* + * If we know we'll call the driver to signal SDIO IRQ, disregard + * further indications of Card Interrupt in the status to avoid a + * needless loop. + */ + if (cardint) + intmask = ~SDHCI_INT_CARD_INT; if (intmask --max_loops) goto again; out: -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mmc: sdhci: Avoid needless loop while handling SDIO interrupts in sdhci_irq()
Ignore Card Interrupt bit in the interrupt status if we already know that mmc_signal_sdio_irq() is going to be called at the end of sdhci_irq(). This avoids a needless loop in sdhci_irq() repeatedly reading interrupt status and doing nothing. Signed-off-by: Alexey Neyman Acked-by: Dong Aisheng --- drivers/mmc/host/sdhci.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 7a7fb4f..a83cd1b 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -2491,6 +2491,14 @@ again: result = IRQ_HANDLED; intmask = sdhci_readl(host, SDHCI_INT_STATUS); + + /* +* If we know we'll call the driver to signal SDIO IRQ, disregard +* further indications of Card Interrupt in the status to avoid a +* needless loop. +*/ + if (cardint) + intmask &= ~SDHCI_INT_CARD_INT; if (intmask && --max_loops) goto again; out: -- 1.8.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Avoid needless loop in sdhci_irq()
Ignore Card Interrupt bit in the interrupt status if we already know that mmc_signal_sdio_irq() is going to be called at the end of sdhci_irq(). This avoids a needless loop in sdhci_irq() repeatedly reading interrupt status and doing nothing. Signed-off-by: Alexey Neyman --- drivers/mmc/host/sdhci.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 7a7fb4f..a83cd1b 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -2491,6 +2491,14 @@ again: result = IRQ_HANDLED; intmask = sdhci_readl(host, SDHCI_INT_STATUS); + + /* +* If we know we'll call the driver to signal SDIO IRQ, disregard +* further indications of Card Interrupt in the status to avoid a +* needless loop. +*/ + if (cardint) + intmask &= ~SDHCI_INT_CARD_INT; if (intmask && --max_loops) goto again; out: -- 1.8.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Avoid needless loop in sdhci_irq()
Ignore Card Interrupt bit in the interrupt status if we already know that mmc_signal_sdio_irq() is going to be called at the end of sdhci_irq(). This avoids a needless loop in sdhci_irq() repeatedly reading interrupt status and doing nothing. Signed-off-by: Alexey Neyman sti...@att.net --- drivers/mmc/host/sdhci.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 7a7fb4f..a83cd1b 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -2491,6 +2491,14 @@ again: result = IRQ_HANDLED; intmask = sdhci_readl(host, SDHCI_INT_STATUS); + + /* +* If we know we'll call the driver to signal SDIO IRQ, disregard +* further indications of Card Interrupt in the status to avoid a +* needless loop. +*/ + if (cardint) + intmask = ~SDHCI_INT_CARD_INT; if (intmask --max_loops) goto again; out: -- 1.8.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mmc: sdhci: Avoid needless loop while handling SDIO interrupts in sdhci_irq()
Ignore Card Interrupt bit in the interrupt status if we already know that mmc_signal_sdio_irq() is going to be called at the end of sdhci_irq(). This avoids a needless loop in sdhci_irq() repeatedly reading interrupt status and doing nothing. Signed-off-by: Alexey Neyman sti...@att.net Acked-by: Dong Aisheng b29...@freescale.com --- drivers/mmc/host/sdhci.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 7a7fb4f..a83cd1b 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -2491,6 +2491,14 @@ again: result = IRQ_HANDLED; intmask = sdhci_readl(host, SDHCI_INT_STATUS); + + /* +* If we know we'll call the driver to signal SDIO IRQ, disregard +* further indications of Card Interrupt in the status to avoid a +* needless loop. +*/ + if (cardint) + intmask = ~SDHCI_INT_CARD_INT; if (intmask --max_loops) goto again; out: -- 1.8.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Avoid needless loop in sdhci_irq() for Card Interrupt
[Patch ping #3: anyone interested in making sdhci_irq a bit faster?] Hi all, I've discovered that the sdhci_irq() function needlessly iterates re-reading the interrupt status and doing nothing (until it runs out of max_loops) when it handles the "Card Interrupt" status in the interrupt status register. The reason is that the "Card Interrupt" bit is not cleared until the sdhci_irq() calls mmc_signal_sdio_irq(), so if Card Interrupt was asserted, re-reading the interrupt status will find this bit set over and over, even if no other bits are reported. The fix: ignore Card Interrupt bits in the interrupt status if we already know that mmc_signal_sdio_irq() is going to be called at the end of sdhci_irq(). Signed-off-by: Alexey Neyman commit 7f23315b344ca51ddf22a78f326f88404fa8c81d Author: Alexey Neyman Date: Wed Oct 9 22:23:54 2013 -0700 Avoid a loop in sdhci.c. diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 7a7fb4f..a83cd1b 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -2491,6 +2491,14 @@ again: result = IRQ_HANDLED; intmask = sdhci_readl(host, SDHCI_INT_STATUS); + + /* + * If we know we'll call the driver to signal SDIO IRQ, disregard + * further indications of Card Interrupt in the status to avoid a + * needless loop. + */ + if (cardint) + intmask &= ~SDHCI_INT_CARD_INT; if (intmask && --max_loops) goto again; out:
Avoid needless loop in sdhci_irq() for Card Interrupt
[Patch ping #3: anyone interested in making sdhci_irq a bit faster?] Hi all, I've discovered that the sdhci_irq() function needlessly iterates re-reading the interrupt status and doing nothing (until it runs out of max_loops) when it handles the Card Interrupt status in the interrupt status register. The reason is that the Card Interrupt bit is not cleared until the sdhci_irq() calls mmc_signal_sdio_irq(), so if Card Interrupt was asserted, re-reading the interrupt status will find this bit set over and over, even if no other bits are reported. The fix: ignore Card Interrupt bits in the interrupt status if we already know that mmc_signal_sdio_irq() is going to be called at the end of sdhci_irq(). Signed-off-by: Alexey Neyman sti...@att.netcommit 7f23315b344ca51ddf22a78f326f88404fa8c81d Author: Alexey Neyman sti...@att.net Date: Wed Oct 9 22:23:54 2013 -0700 Avoid a loop in sdhci.c. diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 7a7fb4f..a83cd1b 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -2491,6 +2491,14 @@ again: result = IRQ_HANDLED; intmask = sdhci_readl(host, SDHCI_INT_STATUS); + + /* + * If we know we'll call the driver to signal SDIO IRQ, disregard + * further indications of Card Interrupt in the status to avoid a + * needless loop. + */ + if (cardint) + intmask = ~SDHCI_INT_CARD_INT; if (intmask --max_loops) goto again; out:
Avoid needless loop in sdhci_irq() for Card Interrupt
[Patch ping #2] Hi all, I've discovered that the sdhci_irq() function needlessly iterates re-reading the interrupt status and doing nothing (until it runs out of max_loops) when it handles the "Card Interrupt" status in the interrupt status register. The reason is that the "Card Interrupt" bit is not cleared until the sdhci_irq() calls mmc_signal_sdio_irq(), so if Card Interrupt was asserted, re-reading the interrupt status will find this bit set over and over, even if no other bits are reported. The fix: ignore Card Interrupt bits in the interrupt status if we already know that mmc_signal_sdio_irq() is going to be called at the end of sdhci_irq(). Signed-off-by: Alexey Neyman commit 7f23315b344ca51ddf22a78f326f88404fa8c81d Author: Alexey Neyman Date: Wed Oct 9 22:23:54 2013 -0700 Avoid a loop in sdhci.c. diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 7a7fb4f..a83cd1b 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -2491,6 +2491,14 @@ again: result = IRQ_HANDLED; intmask = sdhci_readl(host, SDHCI_INT_STATUS); + + /* + * If we know we'll call the driver to signal SDIO IRQ, disregard + * further indications of Card Interrupt in the status to avoid a + * needless loop. + */ + if (cardint) + intmask &= ~SDHCI_INT_CARD_INT; if (intmask && --max_loops) goto again; out:
Avoid needless loop in sdhci_irq() for Card Interrupt
[Patch ping #2] Hi all, I've discovered that the sdhci_irq() function needlessly iterates re-reading the interrupt status and doing nothing (until it runs out of max_loops) when it handles the Card Interrupt status in the interrupt status register. The reason is that the Card Interrupt bit is not cleared until the sdhci_irq() calls mmc_signal_sdio_irq(), so if Card Interrupt was asserted, re-reading the interrupt status will find this bit set over and over, even if no other bits are reported. The fix: ignore Card Interrupt bits in the interrupt status if we already know that mmc_signal_sdio_irq() is going to be called at the end of sdhci_irq(). Signed-off-by: Alexey Neyman sti...@att.netcommit 7f23315b344ca51ddf22a78f326f88404fa8c81d Author: Alexey Neyman sti...@att.net Date: Wed Oct 9 22:23:54 2013 -0700 Avoid a loop in sdhci.c. diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 7a7fb4f..a83cd1b 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -2491,6 +2491,14 @@ again: result = IRQ_HANDLED; intmask = sdhci_readl(host, SDHCI_INT_STATUS); + + /* + * If we know we'll call the driver to signal SDIO IRQ, disregard + * further indications of Card Interrupt in the status to avoid a + * needless loop. + */ + if (cardint) + intmask = ~SDHCI_INT_CARD_INT; if (intmask --max_loops) goto again; out:
Avoid needless loop in sdhci_irq() for Card Interrupt
[Patch ping] Hi all, I've discovered that the sdhci_irq() function needlessly iterates re-reading the interrupt status and doing nothing (until it runs out of max_loops) when it handles the "Card Interrupt" status in the interrupt status register. The reason is that the "Card Interrupt" bit is not cleared until the sdhci_irq() calls mmc_signal_sdio_irq(), so if Card Interrupt was asserted, re-reading the interrupt status will find this bit set over and over, even if no other bits are reported. The fix: ignore Card Interrupt bits in the interrupt status if we already know that mmc_signal_sdio_irq() is going to be called at the end of sdhci_irq(). Signed-off-by: Alexey Neyman commit 7f23315b344ca51ddf22a78f326f88404fa8c81d Author: Alexey Neyman Date: Wed Oct 9 22:23:54 2013 -0700 Avoid a loop in sdhci.c. diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 7a7fb4f..a83cd1b 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -2491,6 +2491,14 @@ again: result = IRQ_HANDLED; intmask = sdhci_readl(host, SDHCI_INT_STATUS); + + /* + * If we know we'll call the driver to signal SDIO IRQ, disregard + * further indications of Card Interrupt in the status to avoid a + * needless loop. + */ + if (cardint) + intmask &= ~SDHCI_INT_CARD_INT; if (intmask && --max_loops) goto again; out:
Avoid needless loop in sdhci_irq() for Card Interrupt
[Patch ping] Hi all, I've discovered that the sdhci_irq() function needlessly iterates re-reading the interrupt status and doing nothing (until it runs out of max_loops) when it handles the Card Interrupt status in the interrupt status register. The reason is that the Card Interrupt bit is not cleared until the sdhci_irq() calls mmc_signal_sdio_irq(), so if Card Interrupt was asserted, re-reading the interrupt status will find this bit set over and over, even if no other bits are reported. The fix: ignore Card Interrupt bits in the interrupt status if we already know that mmc_signal_sdio_irq() is going to be called at the end of sdhci_irq(). Signed-off-by: Alexey Neyman sti...@att.netcommit 7f23315b344ca51ddf22a78f326f88404fa8c81d Author: Alexey Neyman sti...@att.net Date: Wed Oct 9 22:23:54 2013 -0700 Avoid a loop in sdhci.c. diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 7a7fb4f..a83cd1b 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -2491,6 +2491,14 @@ again: result = IRQ_HANDLED; intmask = sdhci_readl(host, SDHCI_INT_STATUS); + + /* + * If we know we'll call the driver to signal SDIO IRQ, disregard + * further indications of Card Interrupt in the status to avoid a + * needless loop. + */ + if (cardint) + intmask = ~SDHCI_INT_CARD_INT; if (intmask --max_loops) goto again; out:
Avoid needless loop in sdhci_irq() for Card Interrupt
Hi all, I've discovered that the sdhci_irq() function needlessly iterates re-reading the interrupt status and doing nothing (until it runs out of max_loops) when it handles the "Card Interrupt" status in the interrupt status register. The reason is that the "Card Interrupt" bit is not cleared until the sdhci_irq() calls mmc_signal_sdio_irq(), so if Card Interrupt was asserted, re-reading the interrupt status will find this bit set over and over, even if no other bits are reported. The fix: ignore Card Interrupt bits in the interrupt status if we already know that mmc_signal_sdio_irq() is going to be called at the end of sdhci_irq(). Signed-off-by: Alexey Neyman commit 7f23315b344ca51ddf22a78f326f88404fa8c81d Author: Alexey Neyman Date: Wed Oct 9 22:23:54 2013 -0700 Avoid a loop in sdhci.c. diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 7a7fb4f..a83cd1b 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -2491,6 +2491,14 @@ again: result = IRQ_HANDLED; intmask = sdhci_readl(host, SDHCI_INT_STATUS); + + /* + * If we know we'll call the driver to signal SDIO IRQ, disregard + * further indications of Card Interrupt in the status to avoid a + * needless loop. + */ + if (cardint) + intmask &= ~SDHCI_INT_CARD_INT; if (intmask && --max_loops) goto again; out:
Re: [PATCH] Fix coalescing host bridge windows in arch/x86/pci/acpi.c
[Patch ping #5] On Thursday, October 03, 2013 04:16:07 pm Alexey Neyman wrote: > On Thursday, October 03, 2013 12:14:38 pm Bjorn Helgaas wrote: > > On Mon, Sep 23, 2013 at 12:15 AM, Alexey Neyman wrote: > > > [Resending due to no response to the original message in a week] > > > > > > Hi all, > > > > > > I have a board with a BIOS bug that reports the following I/O port > > > regions in _CRS on one of the host bridges: > > > > > > 0x-0x03af // #0 > > > 0x03e0-0x0cf7 // #1 > > > 0x03b0-0x03bb // #2 > > > 0x03c0-0x03df // #3 > > > 0x-0xdfff // #4 > > > 0xf000-0x // #5 > > > > > > Obviously, region number #4 is erroneous as it overlaps with regions > > > #0..3. The code in coalesce_windows() in arch/x86/pci/acpi.c attempts > > > to recover from such kind of BIOS bugs by merging the overlapping > > > regions. Current code expands region #0 to 0x-0xd and makes > > > region #4 ignored. As a result, overlap of the expanded region #0 with > > > regions #1..3 remains undetected (as the inner loop already compared > > > them with region #0). As a result, regions #1..3 are inserted into the > > > resource tree even though they overlap with adjusted region #0 - which > > > later results in resource conflicts for PCI devices with IO ports in > > > one of those regions (e.g., for an PCI IDE controller in legacy mode - > > > which has port 0x3f6). The kernel then refuses to initialize these > > > devices. > > > > > > The fix: instead of expanding res1 and ignoring res2, do the opposite. > > > The res2 window is yet to be compared against all windows between res1 > > > and res2 (regions #1..3 in the above example), so the resulting > > > resource map will include just the expanded region - and will ignore > > > any overlapping ones. > > > > > > Signed-off-by: Alexey Neyman > > > > Can you please open a report at http://bugzilla.kernel.org, assign it > > to drivers/pci, and attach a complete dmesg log? > > https://bugzilla.kernel.org/show_bug.cgi?id=62511 > > I am not at liberty to disclose full hardware configuration of the board, > as it is a proprietary prototype board not in production. I've provided > the relevant messages from dmesg though. Could anybody review/commit? Regards, Alexey. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix coalescing host bridge windows in arch/x86/pci/acpi.c
[Patch ping #5] On Thursday, October 03, 2013 04:16:07 pm Alexey Neyman wrote: On Thursday, October 03, 2013 12:14:38 pm Bjorn Helgaas wrote: On Mon, Sep 23, 2013 at 12:15 AM, Alexey Neyman sti...@att.net wrote: [Resending due to no response to the original message in a week] Hi all, I have a board with a BIOS bug that reports the following I/O port regions in _CRS on one of the host bridges: 0x-0x03af // #0 0x03e0-0x0cf7 // #1 0x03b0-0x03bb // #2 0x03c0-0x03df // #3 0x-0xdfff // #4 0xf000-0x // #5 Obviously, region number #4 is erroneous as it overlaps with regions #0..3. The code in coalesce_windows() in arch/x86/pci/acpi.c attempts to recover from such kind of BIOS bugs by merging the overlapping regions. Current code expands region #0 to 0x-0xd and makes region #4 ignored. As a result, overlap of the expanded region #0 with regions #1..3 remains undetected (as the inner loop already compared them with region #0). As a result, regions #1..3 are inserted into the resource tree even though they overlap with adjusted region #0 - which later results in resource conflicts for PCI devices with IO ports in one of those regions (e.g., for an PCI IDE controller in legacy mode - which has port 0x3f6). The kernel then refuses to initialize these devices. The fix: instead of expanding res1 and ignoring res2, do the opposite. The res2 window is yet to be compared against all windows between res1 and res2 (regions #1..3 in the above example), so the resulting resource map will include just the expanded region - and will ignore any overlapping ones. Signed-off-by: Alexey Neyman sti...@att.net Can you please open a report at http://bugzilla.kernel.org, assign it to drivers/pci, and attach a complete dmesg log? https://bugzilla.kernel.org/show_bug.cgi?id=62511 I am not at liberty to disclose full hardware configuration of the board, as it is a proprietary prototype board not in production. I've provided the relevant messages from dmesg though. Could anybody review/commit? Regards, Alexey. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Avoid needless loop in sdhci_irq() for Card Interrupt
Hi all, I've discovered that the sdhci_irq() function needlessly iterates re-reading the interrupt status and doing nothing (until it runs out of max_loops) when it handles the Card Interrupt status in the interrupt status register. The reason is that the Card Interrupt bit is not cleared until the sdhci_irq() calls mmc_signal_sdio_irq(), so if Card Interrupt was asserted, re-reading the interrupt status will find this bit set over and over, even if no other bits are reported. The fix: ignore Card Interrupt bits in the interrupt status if we already know that mmc_signal_sdio_irq() is going to be called at the end of sdhci_irq(). Signed-off-by: Alexey Neyman sti...@att.net commit 7f23315b344ca51ddf22a78f326f88404fa8c81d Author: Alexey Neyman sti...@att.net Date: Wed Oct 9 22:23:54 2013 -0700 Avoid a loop in sdhci.c. diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 7a7fb4f..a83cd1b 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -2491,6 +2491,14 @@ again: result = IRQ_HANDLED; intmask = sdhci_readl(host, SDHCI_INT_STATUS); + + /* + * If we know we'll call the driver to signal SDIO IRQ, disregard + * further indications of Card Interrupt in the status to avoid a + * needless loop. + */ + if (cardint) + intmask = ~SDHCI_INT_CARD_INT; if (intmask --max_loops) goto again; out:
Re: [PATCH] Fix coalescing host bridge windows in arch/x86/pci/acpi.c
On Thursday, October 03, 2013 12:14:38 pm Bjorn Helgaas wrote: > On Mon, Sep 23, 2013 at 12:15 AM, Alexey Neyman wrote: > > [Resending due to no response to the original message in a week] > > > > Hi all, > > > > I have a board with a BIOS bug that reports the following I/O port > > regions in _CRS on one of the host bridges: > > > > 0x-0x03af // #0 > > 0x03e0-0x0cf7 // #1 > > 0x03b0-0x03bb // #2 > > 0x03c0-0x03df // #3 > > 0x-0xdfff // #4 > > 0xf000-0x // #5 > > > > Obviously, region number #4 is erroneous as it overlaps with regions > > #0..3. The code in coalesce_windows() in arch/x86/pci/acpi.c attempts to > > recover from such kind of BIOS bugs by merging the overlapping regions. > > Current code expands region #0 to 0x-0xd and makes region #4 > > ignored. As a result, overlap of the expanded region #0 with regions > > #1..3 remains undetected (as the inner loop already compared them with > > region #0). As a result, regions #1..3 are inserted into the resource > > tree even though they overlap with adjusted region #0 - which later > > results in resource conflicts for PCI devices with IO ports in one of > > those regions (e.g., for an PCI IDE controller in legacy mode - which > > has port 0x3f6). The kernel then refuses to initialize these devices. > > > > The fix: instead of expanding res1 and ignoring res2, do the opposite. > > The res2 window is yet to be compared against all windows between res1 > > and res2 (regions #1..3 in the above example), so the resulting resource > > map will include just the expanded region - and will ignore any > > overlapping ones. > > > > Signed-off-by: Alexey Neyman > > Can you please open a report at http://bugzilla.kernel.org, assign it > to drivers/pci, and attach a complete dmesg log? https://bugzilla.kernel.org/show_bug.cgi?id=62511 I am not at liberty to disclose full hardware configuration of the board, as it is a proprietary prototype board not in production. I've provided the relevant messages from dmesg though. Regards, Alexey. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix coalescing host bridge windows in arch/x86/pci/acpi.c
[Patch ping #4...]
On Tuesday, September 24, 2013 11:47:21 AM Yijing Wang wrote:
> On 2013/9/23 14:15, Alexey Neyman wrote:
> > [Resending due to no response to the original message in a week]
> >
> > Hi all,
> >
> > I have a board with a BIOS bug that reports the following I/O port regions
> > in _CRS on one of the host bridges:
> >
> > 0x-0x03af // #0
> > 0x03e0-0x0cf7 // #1
> > 0x03b0-0x03bb // #2
> > 0x03c0-0x03df // #3
> > 0x-0xdfff // #4
> > 0xf000-0x // #5
> >
> > Obviously, region number #4 is erroneous as it overlaps with regions
> > #0..3.
> > The code in coalesce_windows() in arch/x86/pci/acpi.c attempts to recover
> > from such kind of BIOS bugs by merging the overlapping regions. Current
> > code expands region #0 to 0x-0xd and makes region #4 ignored. As
> > a result, overlap of the expanded region #0 with regions #1..3 remains
> > undetected (as the inner loop already compared them with region #0). As a
> > result, regions #1..3 are inserted into the resource tree even though
> > they overlap with adjusted region #0 - which later results in resource
> > conflicts for PCI devices with IO ports in one of those regions (e.g.,
> > for an PCI IDE controller in legacy mode - which has port 0x3f6). The
> > kernel then refuses to initialize these devices.
> >
> > The fix: instead of expanding res1 and ignoring res2, do the opposite. The
> > res2 window is yet to be compared against all windows between res1 and
> > res2
> > (regions #1..3 in the above example), so the resulting resource map will
> > include just the expanded region - and will ignore any overlapping ones.
> >
> > Signed-off-by: Alexey Neyman
>
> It looks fine to me, but I have no platform to test it. :)
Thanks for a review. Could anybody push it into the tree? :)
For convenience, patch attached again.
Regards,
Alexey.diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index b30e937..7fb24e5 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -354,12 +354,12 @@ static void coalesce_windows(struct pci_root_info *info, unsigned long type)
* the kernel resource tree doesn't allow overlaps.
*/
if (resource_overlaps(res1, res2)) {
-res1->start = min(res1->start, res2->start);
-res1->end = max(res1->end, res2->end);
+res2->start = min(res1->start, res2->start);
+res2->end = max(res1->end, res2->end);
dev_info(>bridge->dev,
"host bridge window expanded to %pR; %pR ignored\n",
- res1, res2);
-res2->flags = 0;
+ res2, res1);
+res1->flags = 0;
}
}
}
Re: [PATCH] Fix coalescing host bridge windows in arch/x86/pci/acpi.c
[Patch ping #4...]
On Tuesday, September 24, 2013 11:47:21 AM Yijing Wang wrote:
On 2013/9/23 14:15, Alexey Neyman wrote:
[Resending due to no response to the original message in a week]
Hi all,
I have a board with a BIOS bug that reports the following I/O port regions
in _CRS on one of the host bridges:
0x-0x03af // #0
0x03e0-0x0cf7 // #1
0x03b0-0x03bb // #2
0x03c0-0x03df // #3
0x-0xdfff // #4
0xf000-0x // #5
Obviously, region number #4 is erroneous as it overlaps with regions
#0..3.
The code in coalesce_windows() in arch/x86/pci/acpi.c attempts to recover
from such kind of BIOS bugs by merging the overlapping regions. Current
code expands region #0 to 0x-0xd and makes region #4 ignored. As
a result, overlap of the expanded region #0 with regions #1..3 remains
undetected (as the inner loop already compared them with region #0). As a
result, regions #1..3 are inserted into the resource tree even though
they overlap with adjusted region #0 - which later results in resource
conflicts for PCI devices with IO ports in one of those regions (e.g.,
for an PCI IDE controller in legacy mode - which has port 0x3f6). The
kernel then refuses to initialize these devices.
The fix: instead of expanding res1 and ignoring res2, do the opposite. The
res2 window is yet to be compared against all windows between res1 and
res2
(regions #1..3 in the above example), so the resulting resource map will
include just the expanded region - and will ignore any overlapping ones.
Signed-off-by: Alexey Neyman sti...@att.net
It looks fine to me, but I have no platform to test it. :)
Thanks for a review. Could anybody push it into the tree? :)
For convenience, patch attached again.
Regards,
Alexey.diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index b30e937..7fb24e5 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -354,12 +354,12 @@ static void coalesce_windows(struct pci_root_info *info, unsigned long type)
* the kernel resource tree doesn't allow overlaps.
*/
if (resource_overlaps(res1, res2)) {
-res1-start = min(res1-start, res2-start);
-res1-end = max(res1-end, res2-end);
+res2-start = min(res1-start, res2-start);
+res2-end = max(res1-end, res2-end);
dev_info(info-bridge-dev,
host bridge window expanded to %pR; %pR ignored\n,
- res1, res2);
-res2-flags = 0;
+ res2, res1);
+res1-flags = 0;
}
}
}
Re: [PATCH] Fix coalescing host bridge windows in arch/x86/pci/acpi.c
On Thursday, October 03, 2013 12:14:38 pm Bjorn Helgaas wrote: On Mon, Sep 23, 2013 at 12:15 AM, Alexey Neyman sti...@att.net wrote: [Resending due to no response to the original message in a week] Hi all, I have a board with a BIOS bug that reports the following I/O port regions in _CRS on one of the host bridges: 0x-0x03af // #0 0x03e0-0x0cf7 // #1 0x03b0-0x03bb // #2 0x03c0-0x03df // #3 0x-0xdfff // #4 0xf000-0x // #5 Obviously, region number #4 is erroneous as it overlaps with regions #0..3. The code in coalesce_windows() in arch/x86/pci/acpi.c attempts to recover from such kind of BIOS bugs by merging the overlapping regions. Current code expands region #0 to 0x-0xd and makes region #4 ignored. As a result, overlap of the expanded region #0 with regions #1..3 remains undetected (as the inner loop already compared them with region #0). As a result, regions #1..3 are inserted into the resource tree even though they overlap with adjusted region #0 - which later results in resource conflicts for PCI devices with IO ports in one of those regions (e.g., for an PCI IDE controller in legacy mode - which has port 0x3f6). The kernel then refuses to initialize these devices. The fix: instead of expanding res1 and ignoring res2, do the opposite. The res2 window is yet to be compared against all windows between res1 and res2 (regions #1..3 in the above example), so the resulting resource map will include just the expanded region - and will ignore any overlapping ones. Signed-off-by: Alexey Neyman sti...@att.net Can you please open a report at http://bugzilla.kernel.org, assign it to drivers/pci, and attach a complete dmesg log? https://bugzilla.kernel.org/show_bug.cgi?id=62511 I am not at liberty to disclose full hardware configuration of the board, as it is a proprietary prototype board not in production. I've provided the relevant messages from dmesg though. Regards, Alexey. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix coalescing host bridge windows in arch/x86/pci/acpi.c
On Tuesday, September 24, 2013 11:47:21 AM Yijing Wang wrote:
> On 2013/9/23 14:15, Alexey Neyman wrote:
> > [Resending due to no response to the original message in a week]
> >
> > Hi all,
> >
> > I have a board with a BIOS bug that reports the following I/O port regions
> > in _CRS on one of the host bridges:
> >
> > 0x-0x03af // #0
> > 0x03e0-0x0cf7 // #1
> > 0x03b0-0x03bb // #2
> > 0x03c0-0x03df // #3
> > 0x-0xdfff // #4
> > 0xf000-0x // #5
> >
> > Obviously, region number #4 is erroneous as it overlaps with regions
> > #0..3.
> > The code in coalesce_windows() in arch/x86/pci/acpi.c attempts to recover
> > from such kind of BIOS bugs by merging the overlapping regions. Current
> > code expands region #0 to 0x-0xd and makes region #4 ignored. As
> > a result, overlap of the expanded region #0 with regions #1..3 remains
> > undetected (as the inner loop already compared them with region #0). As a
> > result, regions #1..3 are inserted into the resource tree even though
> > they overlap with adjusted region #0 - which later results in resource
> > conflicts for PCI devices with IO ports in one of those regions (e.g.,
> > for an PCI IDE controller in legacy mode - which has port 0x3f6). The
> > kernel then refuses to initialize these devices.
> >
> > The fix: instead of expanding res1 and ignoring res2, do the opposite. The
> > res2 window is yet to be compared against all windows between res1 and
> > res2
> > (regions #1..3 in the above example), so the resulting resource map will
> > include just the expanded region - and will ignore any overlapping ones.
> >
> > Signed-off-by: Alexey Neyman
>
> It looks fine to me, but I have no platform to test it. :)
Thanks for a review. Could anybody push it into the tree? :)
For convenience, patch attached again.
Regards,
Alexey.diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index b30e937..7fb24e5 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -354,12 +354,12 @@ static void coalesce_windows(struct pci_root_info *info, unsigned long type)
* the kernel resource tree doesn't allow overlaps.
*/
if (resource_overlaps(res1, res2)) {
-res1->start = min(res1->start, res2->start);
-res1->end = max(res1->end, res2->end);
+res2->start = min(res1->start, res2->start);
+res2->end = max(res1->end, res2->end);
dev_info(>bridge->dev,
"host bridge window expanded to %pR; %pR ignored\n",
- res1, res2);
-res2->flags = 0;
+ res2, res1);
+res1->flags = 0;
}
}
}
Re: [PATCH] Fix coalescing host bridge windows in arch/x86/pci/acpi.c
On Tuesday, September 24, 2013 11:47:21 AM Yijing Wang wrote:
On 2013/9/23 14:15, Alexey Neyman wrote:
[Resending due to no response to the original message in a week]
Hi all,
I have a board with a BIOS bug that reports the following I/O port regions
in _CRS on one of the host bridges:
0x-0x03af // #0
0x03e0-0x0cf7 // #1
0x03b0-0x03bb // #2
0x03c0-0x03df // #3
0x-0xdfff // #4
0xf000-0x // #5
Obviously, region number #4 is erroneous as it overlaps with regions
#0..3.
The code in coalesce_windows() in arch/x86/pci/acpi.c attempts to recover
from such kind of BIOS bugs by merging the overlapping regions. Current
code expands region #0 to 0x-0xd and makes region #4 ignored. As
a result, overlap of the expanded region #0 with regions #1..3 remains
undetected (as the inner loop already compared them with region #0). As a
result, regions #1..3 are inserted into the resource tree even though
they overlap with adjusted region #0 - which later results in resource
conflicts for PCI devices with IO ports in one of those regions (e.g.,
for an PCI IDE controller in legacy mode - which has port 0x3f6). The
kernel then refuses to initialize these devices.
The fix: instead of expanding res1 and ignoring res2, do the opposite. The
res2 window is yet to be compared against all windows between res1 and
res2
(regions #1..3 in the above example), so the resulting resource map will
include just the expanded region - and will ignore any overlapping ones.
Signed-off-by: Alexey Neyman sti...@att.net
It looks fine to me, but I have no platform to test it. :)
Thanks for a review. Could anybody push it into the tree? :)
For convenience, patch attached again.
Regards,
Alexey.diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index b30e937..7fb24e5 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -354,12 +354,12 @@ static void coalesce_windows(struct pci_root_info *info, unsigned long type)
* the kernel resource tree doesn't allow overlaps.
*/
if (resource_overlaps(res1, res2)) {
-res1-start = min(res1-start, res2-start);
-res1-end = max(res1-end, res2-end);
+res2-start = min(res1-start, res2-start);
+res2-end = max(res1-end, res2-end);
dev_info(info-bridge-dev,
host bridge window expanded to %pR; %pR ignored\n,
- res1, res2);
-res2-flags = 0;
+ res2, res1);
+res1-flags = 0;
}
}
}
[PATCH] Fix coalescing host bridge windows in arch/x86/pci/acpi.c
[Resending due to no response to the original message in a week]
Hi all,
I have a board with a BIOS bug that reports the following I/O port regions in
_CRS on one of the host bridges:
0x-0x03af // #0
0x03e0-0x0cf7 // #1
0x03b0-0x03bb // #2
0x03c0-0x03df // #3
0x-0xdfff // #4
0xf000-0x // #5
Obviously, region number #4 is erroneous as it overlaps with regions #0..3.
The code in coalesce_windows() in arch/x86/pci/acpi.c attempts to recover from
such kind of BIOS bugs by merging the overlapping regions. Current code
expands region #0 to 0x-0xd and makes region #4 ignored. As a result,
overlap of the expanded region #0 with regions #1..3 remains undetected (as
the inner loop already compared them with region #0). As a result, regions
#1..3 are inserted into the resource tree even though they overlap with
adjusted region #0 - which later results in resource conflicts for PCI devices
with IO ports in one of those regions (e.g., for an PCI IDE controller in
legacy mode - which has port 0x3f6). The kernel then refuses to initialize
these devices.
The fix: instead of expanding res1 and ignoring res2, do the opposite. The
res2 window is yet to be compared against all windows between res1 and res2
(regions #1..3 in the above example), so the resulting resource map will
include just the expanded region - and will ignore any overlapping ones.
Signed-off-by: Alexey Neyman diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index b30e937..7fb24e5 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -354,12 +354,12 @@ static void coalesce_windows(struct pci_root_info *info, unsigned long type)
* the kernel resource tree doesn't allow overlaps.
*/
if (resource_overlaps(res1, res2)) {
-res1->start = min(res1->start, res2->start);
-res1->end = max(res1->end, res2->end);
+res2->start = min(res1->start, res2->start);
+res2->end = max(res1->end, res2->end);
dev_info(>bridge->dev,
"host bridge window expanded to %pR; %pR ignored\n",
- res1, res2);
-res2->flags = 0;
+ res2, res1);
+res1->flags = 0;
}
}
}
[PATCH] Fix coalescing host bridge windows in arch/x86/pci/acpi.c
[Resending due to no response to the original message in a week]
Hi all,
I have a board with a BIOS bug that reports the following I/O port regions in
_CRS on one of the host bridges:
0x-0x03af // #0
0x03e0-0x0cf7 // #1
0x03b0-0x03bb // #2
0x03c0-0x03df // #3
0x-0xdfff // #4
0xf000-0x // #5
Obviously, region number #4 is erroneous as it overlaps with regions #0..3.
The code in coalesce_windows() in arch/x86/pci/acpi.c attempts to recover from
such kind of BIOS bugs by merging the overlapping regions. Current code
expands region #0 to 0x-0xd and makes region #4 ignored. As a result,
overlap of the expanded region #0 with regions #1..3 remains undetected (as
the inner loop already compared them with region #0). As a result, regions
#1..3 are inserted into the resource tree even though they overlap with
adjusted region #0 - which later results in resource conflicts for PCI devices
with IO ports in one of those regions (e.g., for an PCI IDE controller in
legacy mode - which has port 0x3f6). The kernel then refuses to initialize
these devices.
The fix: instead of expanding res1 and ignoring res2, do the opposite. The
res2 window is yet to be compared against all windows between res1 and res2
(regions #1..3 in the above example), so the resulting resource map will
include just the expanded region - and will ignore any overlapping ones.
Signed-off-by: Alexey Neyman sti...@att.netdiff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index b30e937..7fb24e5 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -354,12 +354,12 @@ static void coalesce_windows(struct pci_root_info *info, unsigned long type)
* the kernel resource tree doesn't allow overlaps.
*/
if (resource_overlaps(res1, res2)) {
-res1-start = min(res1-start, res2-start);
-res1-end = max(res1-end, res2-end);
+res2-start = min(res1-start, res2-start);
+res2-end = max(res1-end, res2-end);
dev_info(info-bridge-dev,
host bridge window expanded to %pR; %pR ignored\n,
- res1, res2);
-res2-flags = 0;
+ res2, res1);
+res1-flags = 0;
}
}
}
Re: [PATCH PING] Fix coalescing of host bridge windows in arch/x86/pci/acpi.c
[Resending without HTML part - sorry for possible duplicates]
As requested by Peter, resending the patch with ACPI/x86 maintainers CC'ed.
Short description:
Make coalesce_windows() handle multiple resource overlaps.
Signed-off-by: Alexey Neyman
Regards,
Alexey.
On Monday, September 16, 2013 07:31:58 PM Peter Hurley wrote:
> [ +cc Bjorn Helgaas, Rafael Wysocki, linux-acpi ]
>
> On 09/16/2013 12:41 PM, Alexey Neyman wrote:
> > Hi all,
> >
> > Could anybody review/commit the patch?
>
> LKML is a pretty general list and maintainers don't typically
> trawl the list for more work to do. The get_maintainer script
> can be used to help determine to whom to address a patch.
>
> peter@thor:~/src/kernels/next$ ./scripts/get_maintainer.pl -f
> arch/x86/pci/acpi.c Thomas Gleixner (maintainer:X86
> ARCHITECTURE...) Ingo Molnar (maintainer:X86
> ARCHITECTURE...)
> "H. Peter Anvin" (maintainer:X86 ARCHITECTURE...)
> x...@kernel.org (maintainer:X86 ARCHITECTURE...)
> Bjorn Helgaas (commit_signer:5/8=62%)
> "Rafael J. Wysocki" (commit_signer:3/8=38%)
> Feng Tang (commit_signer:1/8=12%)
> Yijing Wang (commit_signer:1/8=12%)
> Mike Yoknis (commit_signer:1/8=12%)
> linux-kernel@vger.kernel.org (open list)
>
> Regards,
> Peter Hurley
>
> PS - You'll want to inline your patch as well because as you can see
> replies don't include it.
>
> > Regards,
> > Alexey.
> >
> > On Thursday, September 12, 2013 05:19:16 pm Alexey Neyman wrote:
> >> Hi all,
> >>
> >> I have a board with a BIOS bug that reports the following I/O port
> >> regions
> >> in _CRS on one of the host bridges:
> >>
> >> 0x-0x03af // #0
> >> 0x03e0-0x0cf7 // #1
> >> 0x03b0-0x03bb // #2
> >> 0x03c0-0x03df // #3
> >> 0x-0xdfff // #4
> >> 0xf000-0x // #5
> >>
> >> Obviously, region number #4 is erroneous as it overlaps with regions
> >> #0..3.
> >> However, code in coalesce_windows() in arch/x86/pci/acpi.c attempts to
> >> recover from such kind of BIOS bugs by merging the overlapping regions.
> >> Current code expands region #0 to 0x-0xd and makes region #4
> >> ignored. As a result, overlap of the expanded region #0 with regions
> >> #1..3
> >> remains undetected. As a result, regions #1..3 are inserted into the
> >> resource tree as if they were consumers of the 0x-0xdfff regions, and
> >> devices that have resources in one of these regions (e.g. 0x3f6 for
> >> legacy
> >> IDE) have a resource conflict - the kernel does not initialize them.
> >>
> >> The attached patch makes the code in coalesce_windows() instead ignore
> >> res1
> >> (which is already dealt with), possibly expanding res2 instead. As res2
> >> has
> >> not been reached in the outer loop in coalesce_windows(), the code will
> >> then check for overlaps of the just-expanded resource with the rest of
> >> the
> >> resources.
> >>
> >> Regards,
> >> Alexey.--- arch/x86/pci/acpi.c.orig 2013-09-12 16:23:06.113813150 -0700
+++ arch/x86/pci/acpi.c 2013-09-12 16:23:56.605813117 -0700
@@ -357,12 +357,12 @@
* the kernel resource tree doesn't allow overlaps.
*/
if (resource_overlaps(res1, res2)) {
-res1->start = min(res1->start, res2->start);
-res1->end = max(res1->end, res2->end);
+res2->start = min(res1->start, res2->start);
+res2->end = max(res1->end, res2->end);
dev_info(>bridge->dev,
"host bridge window expanded to %pR; %pR ignored\n",
- res1, res2);
-res2->flags = 0;
+ res2, res1);
+res1->flags = 0;
}
}
}
Re: [PATCH PING] Fix coalescing of host bridge windows in arch/x86/pci/acpi.c
[Resending without HTML part - sorry for possible duplicates]
As requested by Peter, resending the patch with ACPI/x86 maintainers CC'ed.
Short description:
Make coalesce_windows() handle multiple resource overlaps.
Signed-off-by: Alexey Neyman sti...@att.net
Regards,
Alexey.
On Monday, September 16, 2013 07:31:58 PM Peter Hurley wrote:
[ +cc Bjorn Helgaas, Rafael Wysocki, linux-acpi ]
On 09/16/2013 12:41 PM, Alexey Neyman wrote:
Hi all,
Could anybody review/commit the patch?
LKML is a pretty general list and maintainers don't typically
trawl the list for more work to do. The get_maintainer script
can be used to help determine to whom to address a patch.
peter@thor:~/src/kernels/next$ ./scripts/get_maintainer.pl -f
arch/x86/pci/acpi.c Thomas Gleixner t...@linutronix.de (maintainer:X86
ARCHITECTURE...) Ingo Molnar mi...@redhat.com (maintainer:X86
ARCHITECTURE...)
H. Peter Anvin h...@zytor.com (maintainer:X86 ARCHITECTURE...)
x...@kernel.org (maintainer:X86 ARCHITECTURE...)
Bjorn Helgaas bhelg...@google.com (commit_signer:5/8=62%)
Rafael J. Wysocki rafael.j.wyso...@intel.com (commit_signer:3/8=38%)
Feng Tang feng.t...@intel.com (commit_signer:1/8=12%)
Yijing Wang wangyij...@huawei.com (commit_signer:1/8=12%)
Mike Yoknis mike.yok...@hp.com (commit_signer:1/8=12%)
linux-kernel@vger.kernel.org (open list)
Regards,
Peter Hurley
PS - You'll want to inline your patch as well because as you can see
replies don't include it.
Regards,
Alexey.
On Thursday, September 12, 2013 05:19:16 pm Alexey Neyman wrote:
Hi all,
I have a board with a BIOS bug that reports the following I/O port
regions
in _CRS on one of the host bridges:
0x-0x03af // #0
0x03e0-0x0cf7 // #1
0x03b0-0x03bb // #2
0x03c0-0x03df // #3
0x-0xdfff // #4
0xf000-0x // #5
Obviously, region number #4 is erroneous as it overlaps with regions
#0..3.
However, code in coalesce_windows() in arch/x86/pci/acpi.c attempts to
recover from such kind of BIOS bugs by merging the overlapping regions.
Current code expands region #0 to 0x-0xd and makes region #4
ignored. As a result, overlap of the expanded region #0 with regions
#1..3
remains undetected. As a result, regions #1..3 are inserted into the
resource tree as if they were consumers of the 0x-0xdfff regions, and
devices that have resources in one of these regions (e.g. 0x3f6 for
legacy
IDE) have a resource conflict - the kernel does not initialize them.
The attached patch makes the code in coalesce_windows() instead ignore
res1
(which is already dealt with), possibly expanding res2 instead. As res2
has
not been reached in the outer loop in coalesce_windows(), the code will
then check for overlaps of the just-expanded resource with the rest of
the
resources.
Regards,
Alexey.--- arch/x86/pci/acpi.c.orig 2013-09-12 16:23:06.113813150 -0700
+++ arch/x86/pci/acpi.c 2013-09-12 16:23:56.605813117 -0700
@@ -357,12 +357,12 @@
* the kernel resource tree doesn't allow overlaps.
*/
if (resource_overlaps(res1, res2)) {
-res1-start = min(res1-start, res2-start);
-res1-end = max(res1-end, res2-end);
+res2-start = min(res1-start, res2-start);
+res2-end = max(res1-end, res2-end);
dev_info(info-bridge-dev,
host bridge window expanded to %pR; %pR ignored\n,
- res1, res2);
-res2-flags = 0;
+ res2, res1);
+res1-flags = 0;
}
}
}
Re: [PATCH PING] Fix coalescing of host bridge windows in arch/x86/pci/acpi.c
Hi all,
Could anybody review/commit the patch?
Regards,
Alexey.
On Thursday, September 12, 2013 05:19:16 pm Alexey Neyman wrote:
> Hi all,
>
> I have a board with a BIOS bug that reports the following I/O port regions
> in _CRS on one of the host bridges:
>
> 0x-0x03af // #0
> 0x03e0-0x0cf7 // #1
> 0x03b0-0x03bb // #2
> 0x03c0-0x03df // #3
> 0x-0xdfff // #4
> 0xf000-0x // #5
>
> Obviously, region number #4 is erroneous as it overlaps with regions #0..3.
> However, code in coalesce_windows() in arch/x86/pci/acpi.c attempts to
> recover from such kind of BIOS bugs by merging the overlapping regions.
> Current code expands region #0 to 0x-0xd and makes region #4
> ignored. As a result, overlap of the expanded region #0 with regions #1..3
> remains undetected. As a result, regions #1..3 are inserted into the
> resource tree as if they were consumers of the 0x-0xdfff regions, and
> devices that have resources in one of these regions (e.g. 0x3f6 for legacy
> IDE) have a resource conflict - the kernel does not initialize them.
>
> The attached patch makes the code in coalesce_windows() instead ignore res1
> (which is already dealt with), possibly expanding res2 instead. As res2 has
> not been reached in the outer loop in coalesce_windows(), the code will
> then check for overlaps of the just-expanded resource with the rest of the
> resources.
>
> Regards,
> Alexey.
--- arch/x86/pci/acpi.c.orig 2013-09-12 16:23:06.113813150 -0700
+++ arch/x86/pci/acpi.c 2013-09-12 16:23:56.605813117 -0700
@@ -357,12 +357,12 @@
* the kernel resource tree doesn't allow overlaps.
*/
if (resource_overlaps(res1, res2)) {
-res1->start = min(res1->start, res2->start);
-res1->end = max(res1->end, res2->end);
+res2->start = min(res1->start, res2->start);
+res2->end = max(res1->end, res2->end);
dev_info(>bridge->dev,
"host bridge window expanded to %pR; %pR ignored\n",
- res1, res2);
-res2->flags = 0;
+ res2, res1);
+res1->flags = 0;
}
}
}
Re: [PATCH PING] Fix coalescing of host bridge windows in arch/x86/pci/acpi.c
Hi all,
Could anybody review/commit the patch?
Regards,
Alexey.
On Thursday, September 12, 2013 05:19:16 pm Alexey Neyman wrote:
Hi all,
I have a board with a BIOS bug that reports the following I/O port regions
in _CRS on one of the host bridges:
0x-0x03af // #0
0x03e0-0x0cf7 // #1
0x03b0-0x03bb // #2
0x03c0-0x03df // #3
0x-0xdfff // #4
0xf000-0x // #5
Obviously, region number #4 is erroneous as it overlaps with regions #0..3.
However, code in coalesce_windows() in arch/x86/pci/acpi.c attempts to
recover from such kind of BIOS bugs by merging the overlapping regions.
Current code expands region #0 to 0x-0xd and makes region #4
ignored. As a result, overlap of the expanded region #0 with regions #1..3
remains undetected. As a result, regions #1..3 are inserted into the
resource tree as if they were consumers of the 0x-0xdfff regions, and
devices that have resources in one of these regions (e.g. 0x3f6 for legacy
IDE) have a resource conflict - the kernel does not initialize them.
The attached patch makes the code in coalesce_windows() instead ignore res1
(which is already dealt with), possibly expanding res2 instead. As res2 has
not been reached in the outer loop in coalesce_windows(), the code will
then check for overlaps of the just-expanded resource with the rest of the
resources.
Regards,
Alexey.
--- arch/x86/pci/acpi.c.orig 2013-09-12 16:23:06.113813150 -0700
+++ arch/x86/pci/acpi.c 2013-09-12 16:23:56.605813117 -0700
@@ -357,12 +357,12 @@
* the kernel resource tree doesn't allow overlaps.
*/
if (resource_overlaps(res1, res2)) {
-res1-start = min(res1-start, res2-start);
-res1-end = max(res1-end, res2-end);
+res2-start = min(res1-start, res2-start);
+res2-end = max(res1-end, res2-end);
dev_info(info-bridge-dev,
host bridge window expanded to %pR; %pR ignored\n,
- res1, res2);
-res2-flags = 0;
+ res2, res1);
+res1-flags = 0;
}
}
}
[PATCH] Fix coalescing of host bridge windows in arch/x86/pci/acpi.c
Hi all,
I have a board with a BIOS bug that reports the following I/O port regions in
_CRS on one of the host bridges:
0x-0x03af // #0
0x03e0-0x0cf7 // #1
0x03b0-0x03bb // #2
0x03c0-0x03df // #3
0x-0xdfff // #4
0xf000-0x // #5
Obviously, region number #4 is erroneous as it overlaps with regions #0..3.
However, code in coalesce_windows() in arch/x86/pci/acpi.c attempts to recover
from such kind of BIOS bugs by merging the overlapping regions. Current code
expands region #0 to 0x-0xd and makes region #4 ignored. As a result,
overlap of the expanded region #0 with regions #1..3 remains undetected. As a
result, regions #1..3 are inserted into the resource tree as if they were
consumers of the 0x-0xdfff regions, and devices that have resources in one
of these regions (e.g. 0x3f6 for legacy IDE) have a resource conflict - the
kernel does not initialize them.
The attached patch makes the code in coalesce_windows() instead ignore res1
(which is already dealt with), possibly expanding res2 instead. As res2 has
not been reached in the outer loop in coalesce_windows(), the code will then
check for overlaps of the just-expanded resource with the rest of the
resources.
Regards,
Alexey.
--- arch/x86/pci/acpi.c.orig 2013-09-12 16:23:06.113813150 -0700
+++ arch/x86/pci/acpi.c 2013-09-12 16:23:56.605813117 -0700
@@ -357,12 +357,12 @@
* the kernel resource tree doesn't allow overlaps.
*/
if (resource_overlaps(res1, res2)) {
-res1->start = min(res1->start, res2->start);
-res1->end = max(res1->end, res2->end);
+res2->start = min(res1->start, res2->start);
+res2->end = max(res1->end, res2->end);
dev_info(>bridge->dev,
"host bridge window expanded to %pR; %pR ignored\n",
- res1, res2);
-res2->flags = 0;
+ res2, res1);
+res1->flags = 0;
}
}
}
[PATCH] Fix coalescing of host bridge windows in arch/x86/pci/acpi.c
Hi all,
I have a board with a BIOS bug that reports the following I/O port regions in
_CRS on one of the host bridges:
0x-0x03af // #0
0x03e0-0x0cf7 // #1
0x03b0-0x03bb // #2
0x03c0-0x03df // #3
0x-0xdfff // #4
0xf000-0x // #5
Obviously, region number #4 is erroneous as it overlaps with regions #0..3.
However, code in coalesce_windows() in arch/x86/pci/acpi.c attempts to recover
from such kind of BIOS bugs by merging the overlapping regions. Current code
expands region #0 to 0x-0xd and makes region #4 ignored. As a result,
overlap of the expanded region #0 with regions #1..3 remains undetected. As a
result, regions #1..3 are inserted into the resource tree as if they were
consumers of the 0x-0xdfff regions, and devices that have resources in one
of these regions (e.g. 0x3f6 for legacy IDE) have a resource conflict - the
kernel does not initialize them.
The attached patch makes the code in coalesce_windows() instead ignore res1
(which is already dealt with), possibly expanding res2 instead. As res2 has
not been reached in the outer loop in coalesce_windows(), the code will then
check for overlaps of the just-expanded resource with the rest of the
resources.
Regards,
Alexey.
--- arch/x86/pci/acpi.c.orig 2013-09-12 16:23:06.113813150 -0700
+++ arch/x86/pci/acpi.c 2013-09-12 16:23:56.605813117 -0700
@@ -357,12 +357,12 @@
* the kernel resource tree doesn't allow overlaps.
*/
if (resource_overlaps(res1, res2)) {
-res1-start = min(res1-start, res2-start);
-res1-end = max(res1-end, res2-end);
+res2-start = min(res1-start, res2-start);
+res2-end = max(res1-end, res2-end);
dev_info(info-bridge-dev,
host bridge window expanded to %pR; %pR ignored\n,
- res1, res2);
-res2-flags = 0;
+ res2, res1);
+res1-flags = 0;
}
}
}
