| Message ID | 20190107134510.32494-1-koen.vandeputte@ncentric.com (mailing list archive) |
|---|---|
| State | New, archived |
| Delegated to: | Bjorn Helgaas |
| Headers | show |
| Series | [v2,1/2] arm: cns3xxx: fix writing to wrong PCI registers after alignment | expand |
On Mon, Jan 07, 2019 at 02:45:09PM +0100, Koen Vandeputte wrote: > Originally, cns3xxx used it's own functions for mapping, reading and writing registers. > > Commit 802b7c06adc7 ("ARM: cns3xxx: Convert PCI to use generic config accessors") > removed the internal PCI config write function in favor of the generic one: > > cns3xxx_pci_write_config() --> pci_generic_config_write() > > cns3xxx_pci_write_config() expected aligned addresses, being produced by cns3xxx_pci_map_bus() > while the generic one pci_generic_config_write() actually expects the real address > as both the function and hardware are capable of byte-aligned writes. > > This currently leads to pci_generic_config_write() writing > to the wrong registers on some ocasions. > > First issue seen due to this: > > - driver ath9k gets loaded > - The driver wants to write value 0xA8 to register PCI_LATENCY_TIMER, located at 0x0D > - cns3xxx_pci_map_bus() aligns the address to 0x0C > - pci_generic_config_write() effectively writes 0xA8 into register 0x0C (CACHE_LINE_SIZE) > > This seems to cause some slight instability when certain PCI devices are used. > > Another issue example caused by this this is the PCI bus numbering, > where the primary bus is higher than the secondary, which is impossible. > > Before: > > 00:00.0 PCI bridge: Cavium, Inc. Device 3400 (rev 01) (prog-if 00 [Normal decode]) > Flags: bus master, fast devsel, latency 0, IRQ 255 > Bus: primary=02, secondary=01, subordinate=ff, sec-latency=0 > > After fix: > > 00:00.0 PCI bridge: Cavium, Inc. Device 3400 (rev 01) (prog-if 00 [Normal decode]) > Flags: bus master, fast devsel, latency 0, IRQ 255 > Bus: primary=00, secondary=01, subordinate=02, sec-latency=0 > > And very likely some more .. > > Fix all by omitting the alignment being done in the mapping function. > > Fixes: 802b7c06adc7 ("ARM: cns3xxx: Convert PCI to use generic config accessors") > Acked-by: Krzysztof Halasa <khalasa@piap.pl> > Acked-by: Tim Harvey <tharvey@gateworks.com> > Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com> > CC: Arnd Bergmann <arnd@arndb.de> > CC: Bjorn Helgaas <bhelgaas@google.com> > CC: Olof Johansson <olof@lixom.net> > CC: Robin Leblon <robin.leblon@ncentric.com> > CC: Rob Herring <robh@kernel.org> > CC: Russell King <linux@armlinux.org.uk> > CC: stable@vger.kernel.org # v4.0+ > --- > arch/arm/mach-cns3xxx/pcie.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) I have applied both patches to pci/arm-cns3xxx for v5.1, however I had to reformat and rewrite both logs (commit line wrappings, capitalization, etc.) so have a look. Thanks, Lorenzo > > > V2: > --> resend to be in sync with new second patch > --> added acked-by's based on patch comments > > diff --git a/arch/arm/mach-cns3xxx/pcie.c b/arch/arm/mach-cns3xxx/pcie.c > index 318394ed5c7a..5e11ad3164e0 100644 > --- a/arch/arm/mach-cns3xxx/pcie.c > +++ b/arch/arm/mach-cns3xxx/pcie.c > @@ -83,7 +83,7 @@ static void __iomem *cns3xxx_pci_map_bus(struct pci_bus *bus, > } else /* remote PCI bus */ > base = cnspci->cfg1_regs + ((busno & 0xf) << 20); > > - return base + (where & 0xffc) + (devfn << 12); > + return base + where + (devfn << 12); > } > > static int cns3xxx_pci_read_config(struct pci_bus *bus, unsigned int devfn, > -- > 2.17.1 >
On 24.01.19 12:56, Lorenzo Pieralisi wrote: > On Mon, Jan 07, 2019 at 02:45:09PM +0100, Koen Vandeputte wrote: >> Originally, cns3xxx used it's own functions for mapping, reading and writing registers. >> >> Commit 802b7c06adc7 ("ARM: cns3xxx: Convert PCI to use generic config accessors") >> removed the internal PCI config write function in favor of the generic one: >> >> cns3xxx_pci_write_config() --> pci_generic_config_write() >> >> cns3xxx_pci_write_config() expected aligned addresses, being produced by cns3xxx_pci_map_bus() >> while the generic one pci_generic_config_write() actually expects the real address >> as both the function and hardware are capable of byte-aligned writes. >> >> This currently leads to pci_generic_config_write() writing >> to the wrong registers on some ocasions. >> >> First issue seen due to this: >> >> - driver ath9k gets loaded >> - The driver wants to write value 0xA8 to register PCI_LATENCY_TIMER, located at 0x0D >> - cns3xxx_pci_map_bus() aligns the address to 0x0C >> - pci_generic_config_write() effectively writes 0xA8 into register 0x0C (CACHE_LINE_SIZE) >> >> This seems to cause some slight instability when certain PCI devices are used. >> >> Another issue example caused by this this is the PCI bus numbering, >> where the primary bus is higher than the secondary, which is impossible. >> >> Before: >> >> 00:00.0 PCI bridge: Cavium, Inc. Device 3400 (rev 01) (prog-if 00 [Normal decode]) >> Flags: bus master, fast devsel, latency 0, IRQ 255 >> Bus: primary=02, secondary=01, subordinate=ff, sec-latency=0 >> >> After fix: >> >> 00:00.0 PCI bridge: Cavium, Inc. Device 3400 (rev 01) (prog-if 00 [Normal decode]) >> Flags: bus master, fast devsel, latency 0, IRQ 255 >> Bus: primary=00, secondary=01, subordinate=02, sec-latency=0 >> >> And very likely some more .. >> >> Fix all by omitting the alignment being done in the mapping function. >> >> Fixes: 802b7c06adc7 ("ARM: cns3xxx: Convert PCI to use generic config accessors") >> Acked-by: Krzysztof Halasa <khalasa@piap.pl> >> Acked-by: Tim Harvey <tharvey@gateworks.com> >> Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com> >> CC: Arnd Bergmann <arnd@arndb.de> >> CC: Bjorn Helgaas <bhelgaas@google.com> >> CC: Olof Johansson <olof@lixom.net> >> CC: Robin Leblon <robin.leblon@ncentric.com> >> CC: Rob Herring <robh@kernel.org> >> CC: Russell King <linux@armlinux.org.uk> >> CC: stable@vger.kernel.org # v4.0+ >> --- >> arch/arm/mach-cns3xxx/pcie.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > I have applied both patches to pci/arm-cns3xxx for v5.1, however I had > to reformat and rewrite both logs (commit line wrappings, > capitalization, etc.) so have a look. > > Thanks, > Lorenzo Hi Lorenzo, Thank you for taking care of the wrappings etc. it seems my auto-wrap was disabled in my git tooling .. Your adaptions look more than fine. Purely for my information: Testing on a lot of devices here shows a huge improvement towards stability. Is it possible to get it merged sooner? Does "queued for 5.1" also mean that backporting to stables only will happen at 5.1_rc1 release? Thanks again! Koen
On Thu, Jan 24, 2019 at 04:23:05PM +0100, Koen Vandeputte wrote: > > On 24.01.19 12:56, Lorenzo Pieralisi wrote: > >On Mon, Jan 07, 2019 at 02:45:09PM +0100, Koen Vandeputte wrote: > >>Originally, cns3xxx used it's own functions for mapping, reading and writing registers. > >> > >>Commit 802b7c06adc7 ("ARM: cns3xxx: Convert PCI to use generic config accessors") > >>removed the internal PCI config write function in favor of the generic one: > >> > >>cns3xxx_pci_write_config() --> pci_generic_config_write() > >> > >>cns3xxx_pci_write_config() expected aligned addresses, being produced by cns3xxx_pci_map_bus() > >>while the generic one pci_generic_config_write() actually expects the real address > >>as both the function and hardware are capable of byte-aligned writes. > >> > >>This currently leads to pci_generic_config_write() writing > >>to the wrong registers on some ocasions. > >> > >>First issue seen due to this: > >> > >>- driver ath9k gets loaded > >>- The driver wants to write value 0xA8 to register PCI_LATENCY_TIMER, located at 0x0D > >>- cns3xxx_pci_map_bus() aligns the address to 0x0C > >>- pci_generic_config_write() effectively writes 0xA8 into register 0x0C (CACHE_LINE_SIZE) > >> > >>This seems to cause some slight instability when certain PCI devices are used. > >> > >>Another issue example caused by this this is the PCI bus numbering, > >>where the primary bus is higher than the secondary, which is impossible. > >> > >>Before: > >> > >>00:00.0 PCI bridge: Cavium, Inc. Device 3400 (rev 01) (prog-if 00 [Normal decode]) > >> Flags: bus master, fast devsel, latency 0, IRQ 255 > >> Bus: primary=02, secondary=01, subordinate=ff, sec-latency=0 > >> > >>After fix: > >> > >>00:00.0 PCI bridge: Cavium, Inc. Device 3400 (rev 01) (prog-if 00 [Normal decode]) > >> Flags: bus master, fast devsel, latency 0, IRQ 255 > >> Bus: primary=00, secondary=01, subordinate=02, sec-latency=0 > >> > >>And very likely some more .. > >> > >>Fix all by omitting the alignment being done in the mapping function. > >> > >>Fixes: 802b7c06adc7 ("ARM: cns3xxx: Convert PCI to use generic config accessors") > >>Acked-by: Krzysztof Halasa <khalasa@piap.pl> > >>Acked-by: Tim Harvey <tharvey@gateworks.com> > >>Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com> > >>CC: Arnd Bergmann <arnd@arndb.de> > >>CC: Bjorn Helgaas <bhelgaas@google.com> > >>CC: Olof Johansson <olof@lixom.net> > >>CC: Robin Leblon <robin.leblon@ncentric.com> > >>CC: Rob Herring <robh@kernel.org> > >>CC: Russell King <linux@armlinux.org.uk> > >>CC: stable@vger.kernel.org # v4.0+ > >>--- > >> arch/arm/mach-cns3xxx/pcie.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >I have applied both patches to pci/arm-cns3xxx for v5.1, however I had > >to reformat and rewrite both logs (commit line wrappings, > >capitalization, etc.) so have a look. > > > >Thanks, > >Lorenzo > > Hi Lorenzo, > > Thank you for taking care of the wrappings etc.?? it seems my auto-wrap was > disabled in my git tooling .. > Your adaptions look more than fine. > > > Purely for my information: > > Testing on a lot of devices here shows a huge improvement towards stability. > Is it possible to get it merged sooner? > Does "queued for 5.1" also mean that backporting to stables only will happen > at 5.1_rc1 release? Yes, I will ask Bjorn if we can send them for one of the upcoming -rc* (so effectively you will get them in v5.0 and propagated to stable earlier), I do not think it is that urgent either though, let me handle that. Thanks, Lorenzo
On Thu, Jan 24, 2019 at 5:29 PM Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote: > On Thu, Jan 24, 2019 at 04:23:05PM +0100, Koen Vandeputte wrote: > > On 24.01.19 12:56, Lorenzo Pieralisi wrote: > > >On Mon, Jan 07, 2019 at 02:45:09PM +0100, Koen Vandeputte wrote: > > > > Thank you for taking care of the wrappings etc.?? it seems my auto-wrap was > > disabled in my git tooling .. > > Your adaptions look more than fine. > > > > > > Purely for my information: > > > > Testing on a lot of devices here shows a huge improvement towards stability. > > Is it possible to get it merged sooner? > > Does "queued for 5.1" also mean that backporting to stables only will happen > > at 5.1_rc1 release? > > Yes, I will ask Bjorn if we can send them for one of the upcoming -rc* > (so effectively you will get them in v5.0 and propagated to stable > earlier), I do not think it is that urgent either though, let me handle > that. We can take them through the soc tree if that's easier, but going through Bjorn's tree is also fine. Arnd
On Wed, Jan 30, 2019 at 11:08:04PM +0100, Arnd Bergmann wrote: > On Thu, Jan 24, 2019 at 5:29 PM Lorenzo Pieralisi > <lorenzo.pieralisi@arm.com> wrote: > > On Thu, Jan 24, 2019 at 04:23:05PM +0100, Koen Vandeputte wrote: > > > On 24.01.19 12:56, Lorenzo Pieralisi wrote: > > > >On Mon, Jan 07, 2019 at 02:45:09PM +0100, Koen Vandeputte wrote: > > > Purely for my information: > > > > > > Testing on a lot of devices here shows a huge improvement towards stability. > > > Is it possible to get it merged sooner? > > > Does "queued for 5.1" also mean that backporting to stables only will happen > > > at 5.1_rc1 release? > > > > Yes, I will ask Bjorn if we can send them for one of the upcoming -rc* > > (so effectively you will get them in v5.0 and propagated to stable > > earlier), I do not think it is that urgent either though, let me handle > > that. > > We can take them through the soc tree if that's easier, but > going through Bjorn's tree is also fine. I have the following on my for-linus branch and I'll ask Linus to pull them this week, so they will appear in v5.0: b8b592a3a8d1 ARM: cns3xxx: use actual size reads for PCIe b3a32f359397 ARM: cns3xxx: fix writing to wrong PCI registers after alignment Neither is currently marked for stable, but I'll add that if you like. They're already both marked as: Fixes: 802b7c06adc7 ("ARM: cns3xxx: Convert PCI to use generic config accessors") which I think appeared in v4.0. Bjorn
On Thu, Jan 31, 2019 at 12:06 AM Bjorn Helgaas <helgaas@kernel.org> wrote: > > On Wed, Jan 30, 2019 at 11:08:04PM +0100, Arnd Bergmann wrote: > > On Thu, Jan 24, 2019 at 5:29 PM Lorenzo Pieralisi > > <lorenzo.pieralisi@arm.com> wrote: > > > On Thu, Jan 24, 2019 at 04:23:05PM +0100, Koen Vandeputte wrote: > > > > On 24.01.19 12:56, Lorenzo Pieralisi wrote: > > > > >On Mon, Jan 07, 2019 at 02:45:09PM +0100, Koen Vandeputte wrote: > > > > Purely for my information: > > > > > > > > Testing on a lot of devices here shows a huge improvement towards stability. > > > > Is it possible to get it merged sooner? > > > > Does "queued for 5.1" also mean that backporting to stables only will happen > > > > at 5.1_rc1 release? > > > > > > Yes, I will ask Bjorn if we can send them for one of the upcoming -rc* > > > (so effectively you will get them in v5.0 and propagated to stable > > > earlier), I do not think it is that urgent either though, let me handle > > > that. > > > > We can take them through the soc tree if that's easier, but > > going through Bjorn's tree is also fine. > > I have the following on my for-linus branch and I'll ask Linus to pull them > this week, so they will appear in v5.0: > > b8b592a3a8d1 ARM: cns3xxx: use actual size reads for PCIe > b3a32f359397 ARM: cns3xxx: fix writing to wrong PCI registers after alignment Ok, thanks! > Neither is currently marked for stable, but I'll add that if you like. Yes, I think that would be good, along with Acked-by: Arnd Bergmann <arnd@arndb.de> Arnd
On Thu, Jan 31, 2019 at 09:00:30AM +0100, Arnd Bergmann wrote: > On Thu, Jan 31, 2019 at 12:06 AM Bjorn Helgaas <helgaas@kernel.org> wrote: > > On Wed, Jan 30, 2019 at 11:08:04PM +0100, Arnd Bergmann wrote: > > > On Thu, Jan 24, 2019 at 5:29 PM Lorenzo Pieralisi > > > <lorenzo.pieralisi@arm.com> wrote: > > > > On Thu, Jan 24, 2019 at 04:23:05PM +0100, Koen Vandeputte wrote: > > > > > On 24.01.19 12:56, Lorenzo Pieralisi wrote: > > > > > >On Mon, Jan 07, 2019 at 02:45:09PM +0100, Koen Vandeputte wrote: > > > > > Purely for my information: > > > > > > > > > > Testing on a lot of devices here shows a huge improvement towards stability. > > > > > Is it possible to get it merged sooner? > > > > > Does "queued for 5.1" also mean that backporting to stables only will happen > > > > > at 5.1_rc1 release? > > > > > > > > Yes, I will ask Bjorn if we can send them for one of the upcoming -rc* > > > > (so effectively you will get them in v5.0 and propagated to stable > > > > earlier), I do not think it is that urgent either though, let me handle > > > > that. > > > > > > We can take them through the soc tree if that's easier, but > > > going through Bjorn's tree is also fine. > > > > I have the following on my for-linus branch and I'll ask Linus to pull them > > this week, so they will appear in v5.0: > > > > b8b592a3a8d1 ARM: cns3xxx: use actual size reads for PCIe > > b3a32f359397 ARM: cns3xxx: fix writing to wrong PCI registers after alignment > > Ok, thanks! > > > Neither is currently marked for stable, but I'll add that if you like. > > Yes, I think that would be good, along with > > Acked-by: Arnd Bergmann <arnd@arndb.de> Added, thanks! Actually I was mistaken: the "use actual size reads" patch *was* marked for stable, but the "fix writing" one was not. I suspect this was intended to be the other way around because AFAIK the "fix writing" patch fixes problems and it makes sense to put it in stable, while the "use actual size reads" patch is more of a cleanup and I don't think there's a benefit to putting *it* in stable. So I added your ack to both and marked only the "fix writing" patch for stable. Bjorn
diff --git a/arch/arm/mach-cns3xxx/pcie.c b/arch/arm/mach-cns3xxx/pcie.c index 318394ed5c7a..5e11ad3164e0 100644 --- a/arch/arm/mach-cns3xxx/pcie.c +++ b/arch/arm/mach-cns3xxx/pcie.c @@ -83,7 +83,7 @@ static void __iomem *cns3xxx_pci_map_bus(struct pci_bus *bus, } else /* remote PCI bus */ base = cnspci->cfg1_regs + ((busno & 0xf) << 20); - return base + (where & 0xffc) + (devfn << 12); + return base + where + (devfn << 12); } static int cns3xxx_pci_read_config(struct pci_bus *bus, unsigned int devfn,
Originally, cns3xxx used it's own functions for mapping, reading and writing registers. Commit 802b7c06adc7 ("ARM: cns3xxx: Convert PCI to use generic config accessors") removed the internal PCI config write function in favor of the generic one: cns3xxx_pci_write_config() --> pci_generic_config_write() cns3xxx_pci_write_config() expected aligned addresses, being produced by cns3xxx_pci_map_bus() while the generic one pci_generic_config_write() actually expects the real address as both the function and hardware are capable of byte-aligned writes. This currently leads to pci_generic_config_write() writing to the wrong registers on some ocasions. First issue seen due to this: - driver ath9k gets loaded - The driver wants to write value 0xA8 to register PCI_LATENCY_TIMER, located at 0x0D - cns3xxx_pci_map_bus() aligns the address to 0x0C - pci_generic_config_write() effectively writes 0xA8 into register 0x0C (CACHE_LINE_SIZE) This seems to cause some slight instability when certain PCI devices are used. Another issue example caused by this this is the PCI bus numbering, where the primary bus is higher than the secondary, which is impossible. Before: 00:00.0 PCI bridge: Cavium, Inc. Device 3400 (rev 01) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 255 Bus: primary=02, secondary=01, subordinate=ff, sec-latency=0 After fix: 00:00.0 PCI bridge: Cavium, Inc. Device 3400 (rev 01) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 255 Bus: primary=00, secondary=01, subordinate=02, sec-latency=0 And very likely some more .. Fix all by omitting the alignment being done in the mapping function. Fixes: 802b7c06adc7 ("ARM: cns3xxx: Convert PCI to use generic config accessors") Acked-by: Krzysztof Halasa <khalasa@piap.pl> Acked-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com> CC: Arnd Bergmann <arnd@arndb.de> CC: Bjorn Helgaas <bhelgaas@google.com> CC: Olof Johansson <olof@lixom.net> CC: Robin Leblon <robin.leblon@ncentric.com> CC: Rob Herring <robh@kernel.org> CC: Russell King <linux@armlinux.org.uk> CC: stable@vger.kernel.org # v4.0+ --- arch/arm/mach-cns3xxx/pcie.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) V2: --> resend to be in sync with new second patch --> added acked-by's based on patch comments