Message ID | 20250214173944.47506-7-james.quinlan@broadcom.com (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | PCI: brcmstb: Misc small tweaks and fixes | expand |
On 2/14/2025 9:39 AM, Jim Quinlan wrote: > The constants EXT_CFG_DATA and EXT_CFG_INDEX vary by SOC. One of the > map_bus methods used these constants, the other used different constants. > Fortunately there was no problem because the SoCs that used the latter > map_bus method all had the same register constants. > > Remove the redundant constants and adjust the code to use them. In > addition, update EXT_CFG_DATA to use the 4k-page based config space access > system, which is what the second map_bus method was already using. > > Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
On Fri, Feb 14, 2025 at 12:39:34PM -0500, Jim Quinlan wrote: > The constants EXT_CFG_DATA and EXT_CFG_INDEX vary by SOC. One of the > map_bus methods used these constants, the other used different constants. > Fortunately there was no problem because the SoCs that used the latter > map_bus method all had the same register constants. > > Remove the redundant constants and adjust the code to use them. In > addition, update EXT_CFG_DATA to use the 4k-page based config space access > system, which is what the second map_bus method was already using. > What is the effect of this change? Why is it required? Sounds like it got sneaked in. > Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com> > --- > drivers/pci/controller/pcie-brcmstb.c | 14 ++++++-------- > 1 file changed, 6 insertions(+), 8 deletions(-) > > diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c > index e1059e3365bd..923ac1a03f85 100644 > --- a/drivers/pci/controller/pcie-brcmstb.c > +++ b/drivers/pci/controller/pcie-brcmstb.c > @@ -150,9 +150,6 @@ > #define MSI_INT_MASK_SET 0x10 > #define MSI_INT_MASK_CLR 0x14 > > -#define PCIE_EXT_CFG_DATA 0x8000 > -#define PCIE_EXT_CFG_INDEX 0x9000 > - > #define PCIE_RGR1_SW_INIT_1_PERST_MASK 0x1 > #define PCIE_RGR1_SW_INIT_1_PERST_SHIFT 0x0 > > @@ -727,8 +724,8 @@ static void __iomem *brcm_pcie_map_bus(struct pci_bus *bus, > > /* For devices, write to the config space index register */ > idx = PCIE_ECAM_OFFSET(bus->number, devfn, 0); > - writel(idx, pcie->base + PCIE_EXT_CFG_INDEX); > - return base + PCIE_EXT_CFG_DATA + PCIE_ECAM_REG(where); > + writel(idx, base + IDX_ADDR(pcie)); > + return base + DATA_ADDR(pcie) + PCIE_ECAM_REG(where); > } > > static void __iomem *brcm7425_pcie_map_bus(struct pci_bus *bus, > @@ -1711,7 +1708,7 @@ static void brcm_pcie_remove(struct platform_device *pdev) > static const int pcie_offsets[] = { > [RGR1_SW_INIT_1] = 0x9210, > [EXT_CFG_INDEX] = 0x9000, > - [EXT_CFG_DATA] = 0x9004, > + [EXT_CFG_DATA] = 0x8000, > [PCIE_HARD_DEBUG] = 0x4204, > [PCIE_INTR2_CPU_BASE] = 0x4300, > }; > @@ -1719,7 +1716,7 @@ static const int pcie_offsets[] = { > static const int pcie_offsets_bcm7278[] = { > [RGR1_SW_INIT_1] = 0xc010, > [EXT_CFG_INDEX] = 0x9000, > - [EXT_CFG_DATA] = 0x9004, > + [EXT_CFG_DATA] = 0x8000, > [PCIE_HARD_DEBUG] = 0x4204, > [PCIE_INTR2_CPU_BASE] = 0x4300, > }; > @@ -1733,8 +1730,9 @@ static const int pcie_offsets_bcm7425[] = { > }; > > static const int pcie_offsets_bcm7712[] = { > + [RGR1_SW_INIT_1] = 0x9210, > [EXT_CFG_INDEX] = 0x9000, > - [EXT_CFG_DATA] = 0x9004, > + [EXT_CFG_DATA] = 0x8000, > [PCIE_HARD_DEBUG] = 0x4304, > [PCIE_INTR2_CPU_BASE] = 0x4400, > }; > -- > 2.43.0 >
On Tue, Mar 4, 2025 at 10:08 AM Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> wrote: > > On Fri, Feb 14, 2025 at 12:39:34PM -0500, Jim Quinlan wrote: > > The constants EXT_CFG_DATA and EXT_CFG_INDEX vary by SOC. One of the > > map_bus methods used these constants, the other used different constants. > > Fortunately there was no problem because the SoCs that used the latter > > map_bus method all had the same register constants. > > > > Remove the redundant constants and adjust the code to use them. In > > addition, update EXT_CFG_DATA to use the 4k-page based config space access > > system, which is what the second map_bus method was already using. > > > > What is the effect of this change? Why is it required? Sounds like it got > sneaked in. Hello, There is no functional difference with this commit -- the code will behave the same. A previous commit set up the "EXT_CFG_DATA" and "EXT_CFG_INDEX" constants in the offset table but one of the map_bus() methods did not use them, instead it relied on old generic #define constants. This commit uses them and gets rid of the old #defines. I didn't add a "Fixes" line because there is no functional change but I can if you want. Regards, Jim Quinlan Broadcom STB/CM > > > Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com> > > --- > > drivers/pci/controller/pcie-brcmstb.c | 14 ++++++-------- > > 1 file changed, 6 insertions(+), 8 deletions(-) > > > > diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c > > index e1059e3365bd..923ac1a03f85 100644 > > --- a/drivers/pci/controller/pcie-brcmstb.c > > +++ b/drivers/pci/controller/pcie-brcmstb.c > > @@ -150,9 +150,6 @@ > > #define MSI_INT_MASK_SET 0x10 > > #define MSI_INT_MASK_CLR 0x14 > > > > -#define PCIE_EXT_CFG_DATA 0x8000 > > -#define PCIE_EXT_CFG_INDEX 0x9000 > > - > > #define PCIE_RGR1_SW_INIT_1_PERST_MASK 0x1 > > #define PCIE_RGR1_SW_INIT_1_PERST_SHIFT 0x0 > > > > @@ -727,8 +724,8 @@ static void __iomem *brcm_pcie_map_bus(struct pci_bus *bus, > > > > /* For devices, write to the config space index register */ > > idx = PCIE_ECAM_OFFSET(bus->number, devfn, 0); > > - writel(idx, pcie->base + PCIE_EXT_CFG_INDEX); > > - return base + PCIE_EXT_CFG_DATA + PCIE_ECAM_REG(where); > > + writel(idx, base + IDX_ADDR(pcie)); > > + return base + DATA_ADDR(pcie) + PCIE_ECAM_REG(where); > > } > > > > static void __iomem *brcm7425_pcie_map_bus(struct pci_bus *bus, > > @@ -1711,7 +1708,7 @@ static void brcm_pcie_remove(struct platform_device *pdev) > > static const int pcie_offsets[] = { > > [RGR1_SW_INIT_1] = 0x9210, > > [EXT_CFG_INDEX] = 0x9000, > > - [EXT_CFG_DATA] = 0x9004, > > + [EXT_CFG_DATA] = 0x8000, > > [PCIE_HARD_DEBUG] = 0x4204, > > [PCIE_INTR2_CPU_BASE] = 0x4300, > > }; > > @@ -1719,7 +1716,7 @@ static const int pcie_offsets[] = { > > static const int pcie_offsets_bcm7278[] = { > > [RGR1_SW_INIT_1] = 0xc010, > > [EXT_CFG_INDEX] = 0x9000, > > - [EXT_CFG_DATA] = 0x9004, > > + [EXT_CFG_DATA] = 0x8000, > > [PCIE_HARD_DEBUG] = 0x4204, > > [PCIE_INTR2_CPU_BASE] = 0x4300, > > }; > > @@ -1733,8 +1730,9 @@ static const int pcie_offsets_bcm7425[] = { > > }; > > > > static const int pcie_offsets_bcm7712[] = { > > + [RGR1_SW_INIT_1] = 0x9210, > > [EXT_CFG_INDEX] = 0x9000, > > - [EXT_CFG_DATA] = 0x9004, > > + [EXT_CFG_DATA] = 0x8000, > > [PCIE_HARD_DEBUG] = 0x4304, > > [PCIE_INTR2_CPU_BASE] = 0x4400, > > }; > > -- > > 2.43.0 > > > > -- > மணிவண்ணன் சதாசிவம்
On Tue, Mar 04, 2025 at 11:37:14AM -0500, Jim Quinlan wrote: > On Tue, Mar 4, 2025 at 10:08 AM Manivannan Sadhasivam > <manivannan.sadhasivam@linaro.org> wrote: > > > > On Fri, Feb 14, 2025 at 12:39:34PM -0500, Jim Quinlan wrote: > > > The constants EXT_CFG_DATA and EXT_CFG_INDEX vary by SOC. One of the > > > map_bus methods used these constants, the other used different constants. > > > Fortunately there was no problem because the SoCs that used the latter > > > map_bus method all had the same register constants. > > > > > > Remove the redundant constants and adjust the code to use them. In > > > addition, update EXT_CFG_DATA to use the 4k-page based config space access > > > system, which is what the second map_bus method was already using. > > > > > > > What is the effect of this change? Why is it required? Sounds like it got > > sneaked in. > > Hello, > There is no functional difference with this commit -- the code will > behave the same. A previous commit set up the "EXT_CFG_DATA" and > "EXT_CFG_INDEX" constants in the offset table but one of the map_bus() > methods did not use them, instead it relied on old generic #define > constants. This commit uses them and gets rid of the old #defines. > My comment was about the change that modified the offset of EXT_CFG_DATA. This was not justified properly. - Mani
On Tue, Mar 4, 2025 at 11:58 AM Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> wrote: > > On Tue, Mar 04, 2025 at 11:37:14AM -0500, Jim Quinlan wrote: > > On Tue, Mar 4, 2025 at 10:08 AM Manivannan Sadhasivam > > <manivannan.sadhasivam@linaro.org> wrote: > > > > > > On Fri, Feb 14, 2025 at 12:39:34PM -0500, Jim Quinlan wrote: > > > > The constants EXT_CFG_DATA and EXT_CFG_INDEX vary by SOC. One of the > > > > map_bus methods used these constants, the other used different constants. > > > > Fortunately there was no problem because the SoCs that used the latter > > > > map_bus method all had the same register constants. > > > > > > > > Remove the redundant constants and adjust the code to use them. In > > > > addition, update EXT_CFG_DATA to use the 4k-page based config space access > > > > system, which is what the second map_bus method was already using. > > > > > > > > > > What is the effect of this change? Why is it required? Sounds like it got > > > sneaked in. > > > > Hello, > > There is no functional difference with this commit -- the code will > > behave the same. A previous commit set up the "EXT_CFG_DATA" and > > "EXT_CFG_INDEX" constants in the offset table but one of the map_bus() > > methods did not use them, instead it relied on old generic #define > > constants. This commit uses them and gets rid of the old #defines. > > > > My comment was about the change that modified the offset of EXT_CFG_DATA. This > was not justified properly. Okay, got it. You are referring to (for example) - [EXT_CFG_DATA] = 0x9004, + [EXT_CFG_DATA] = 0x8000, We have two ways of accessing the config space: (1) by writing a full index and reading a designated register (0x9004) and (2) by writing the index and then reading from a 4k register region (0x8000 + offset). We previously used (1). An update was made to use (2) but instead of updating EXT_CFG_DATA from 0x9004 to 0x8000, PCIE_EXT_CFG_DATA (0x8000) was used by the code of one of the map_bus methods. This commit changes the code in the offending map_bus method to use the offset table for (2) and updates the offset table EXT_CFG_DATA to its proper value. If you want me to expand the commit message with the above text I can do that. Regards, Jim Quiinlan Broadcom STB/CM > > - Mani > > -- > மணிவண்ணன் சதாசிவம்
On Tue, Mar 04, 2025 at 12:37:26PM -0500, Jim Quinlan wrote: > On Tue, Mar 4, 2025 at 11:58 AM Manivannan Sadhasivam > <manivannan.sadhasivam@linaro.org> wrote: > > > > On Tue, Mar 04, 2025 at 11:37:14AM -0500, Jim Quinlan wrote: > > > On Tue, Mar 4, 2025 at 10:08 AM Manivannan Sadhasivam > > > <manivannan.sadhasivam@linaro.org> wrote: > > > > > > > > On Fri, Feb 14, 2025 at 12:39:34PM -0500, Jim Quinlan wrote: > > > > > The constants EXT_CFG_DATA and EXT_CFG_INDEX vary by SOC. One of the > > > > > map_bus methods used these constants, the other used different constants. > > > > > Fortunately there was no problem because the SoCs that used the latter > > > > > map_bus method all had the same register constants. > > > > > > > > > > Remove the redundant constants and adjust the code to use them. In > > > > > addition, update EXT_CFG_DATA to use the 4k-page based config space access > > > > > system, which is what the second map_bus method was already using. > > > > > > > > > > > > > What is the effect of this change? Why is it required? Sounds like it got > > > > sneaked in. > > > > > > Hello, > > > There is no functional difference with this commit -- the code will > > > behave the same. A previous commit set up the "EXT_CFG_DATA" and > > > "EXT_CFG_INDEX" constants in the offset table but one of the map_bus() > > > methods did not use them, instead it relied on old generic #define > > > constants. This commit uses them and gets rid of the old #defines. > > > > > > > My comment was about the change that modified the offset of EXT_CFG_DATA. This > > was not justified properly. > > Okay, got it. You are referring to (for example) > - [EXT_CFG_DATA] = 0x9004, > + [EXT_CFG_DATA] = 0x8000, > > We have two ways of accessing the config space: (1) by writing a full > index and reading a designated register (0x9004) and (2) by writing > the index and then reading from a 4k register region (0x8000 + > offset). We previously used (1). An update was made to use (2) but > instead of updating EXT_CFG_DATA from 0x9004 to 0x8000, > PCIE_EXT_CFG_DATA (0x8000) was used by the code of one of the map_bus > methods. > > This commit changes the code in the offending map_bus method to use > the offset table for (2) and updates the offset table EXT_CFG_DATA to > its proper value. > Ok, this clarifies. > If you want me to expand the commit message with the above text I can do that. > No need. Krzysztof should be able to ammend the commit message for you. - Mani
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c index e1059e3365bd..923ac1a03f85 100644 --- a/drivers/pci/controller/pcie-brcmstb.c +++ b/drivers/pci/controller/pcie-brcmstb.c @@ -150,9 +150,6 @@ #define MSI_INT_MASK_SET 0x10 #define MSI_INT_MASK_CLR 0x14 -#define PCIE_EXT_CFG_DATA 0x8000 -#define PCIE_EXT_CFG_INDEX 0x9000 - #define PCIE_RGR1_SW_INIT_1_PERST_MASK 0x1 #define PCIE_RGR1_SW_INIT_1_PERST_SHIFT 0x0 @@ -727,8 +724,8 @@ static void __iomem *brcm_pcie_map_bus(struct pci_bus *bus, /* For devices, write to the config space index register */ idx = PCIE_ECAM_OFFSET(bus->number, devfn, 0); - writel(idx, pcie->base + PCIE_EXT_CFG_INDEX); - return base + PCIE_EXT_CFG_DATA + PCIE_ECAM_REG(where); + writel(idx, base + IDX_ADDR(pcie)); + return base + DATA_ADDR(pcie) + PCIE_ECAM_REG(where); } static void __iomem *brcm7425_pcie_map_bus(struct pci_bus *bus, @@ -1711,7 +1708,7 @@ static void brcm_pcie_remove(struct platform_device *pdev) static const int pcie_offsets[] = { [RGR1_SW_INIT_1] = 0x9210, [EXT_CFG_INDEX] = 0x9000, - [EXT_CFG_DATA] = 0x9004, + [EXT_CFG_DATA] = 0x8000, [PCIE_HARD_DEBUG] = 0x4204, [PCIE_INTR2_CPU_BASE] = 0x4300, }; @@ -1719,7 +1716,7 @@ static const int pcie_offsets[] = { static const int pcie_offsets_bcm7278[] = { [RGR1_SW_INIT_1] = 0xc010, [EXT_CFG_INDEX] = 0x9000, - [EXT_CFG_DATA] = 0x9004, + [EXT_CFG_DATA] = 0x8000, [PCIE_HARD_DEBUG] = 0x4204, [PCIE_INTR2_CPU_BASE] = 0x4300, }; @@ -1733,8 +1730,9 @@ static const int pcie_offsets_bcm7425[] = { }; static const int pcie_offsets_bcm7712[] = { + [RGR1_SW_INIT_1] = 0x9210, [EXT_CFG_INDEX] = 0x9000, - [EXT_CFG_DATA] = 0x9004, + [EXT_CFG_DATA] = 0x8000, [PCIE_HARD_DEBUG] = 0x4304, [PCIE_INTR2_CPU_BASE] = 0x4400, };
The constants EXT_CFG_DATA and EXT_CFG_INDEX vary by SOC. One of the map_bus methods used these constants, the other used different constants. Fortunately there was no problem because the SoCs that used the latter map_bus method all had the same register constants. Remove the redundant constants and adjust the code to use them. In addition, update EXT_CFG_DATA to use the 4k-page based config space access system, which is what the second map_bus method was already using. Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com> --- drivers/pci/controller/pcie-brcmstb.c | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-)