[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <b4dc6d96-b268-7da4-e41f-cc922ae6941c@linux.intel.com>
Date: Fri, 13 Jun 2025 18:25:50 +0300 (EEST)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: Geraldo Nascimento <geraldogabriel@...il.com>
cc: linux-rockchip@...ts.infradead.org, Shawn Lin <shawn.lin@...k-chips.com>,
Lorenzo Pieralisi <lpieralisi@...nel.org>,
Krzysztof Wilczyński <kw@...ux.com>,
Manivannan Sadhasivam <mani@...nel.org>, Rob Herring <robh@...nel.org>,
Bjorn Helgaas <bhelgaas@...gle.com>, Heiko Stuebner <heiko@...ech.de>,
Vinod Koul <vkoul@...nel.org>, Kishon Vijay Abraham I <kishon@...nel.org>,
linux-phy@...ts.infradead.org, linux-pci@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v4 2/5] PCI: rockchip: Drop unused custom registers
and bitfields
On Fri, 13 Jun 2025, Geraldo Nascimento wrote:
> On Fri, Jun 13, 2025 at 06:03:14PM +0300, Ilpo Järvinen wrote:
> > On Fri, 13 Jun 2025, Geraldo Nascimento wrote:
> >
> > > Since we are now using standard PCIe defines, drop
> > > unused custom-defined ones, which are now referenced
> > > from offset at added Capabilities Register.
> >
> > These are quite short lines, please reflow the changelog paragraphs to the
> > usual length.
>
> Hi Ilpo,
>
> I'll reflow for v5.
>
> >
> > > Suggested-By: Bjorn Helgaas <bhelgaas@...gle.com>
> > > Signed-off-by: Geraldo Nascimento <geraldogabriel@...il.com>
> > > ---
> > > drivers/pci/controller/pcie-rockchip.h | 11 +----------
> > > 1 file changed, 1 insertion(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/pcie-rockchip.h b/drivers/pci/controller/pcie-rockchip.h
> > > index 5864a20323f2..f611599988d7 100644
> > > --- a/drivers/pci/controller/pcie-rockchip.h
> > > +++ b/drivers/pci/controller/pcie-rockchip.h
> > > @@ -155,16 +155,7 @@
> > > #define PCIE_EP_CONFIG_DID_VID (PCIE_EP_CONFIG_BASE + 0x00)
> > > #define PCIE_EP_CONFIG_LCS (PCIE_EP_CONFIG_BASE + 0xd0)
> > > #define PCIE_RC_CONFIG_RID_CCR (PCIE_RC_CONFIG_BASE + 0x08)
> > > -#define PCIE_RC_CONFIG_DCR (PCIE_RC_CONFIG_BASE + 0xc4)
> > > -#define PCIE_RC_CONFIG_DCR_CSPL_SHIFT 18
> > > -#define PCIE_RC_CONFIG_DCR_CSPL_LIMIT 0xff
> > > -#define PCIE_RC_CONFIG_DCR_CPLS_SHIFT 26
> > > -#define PCIE_RC_CONFIG_DCSR (PCIE_RC_CONFIG_BASE + 0xc8)
> > > -#define PCIE_RC_CONFIG_DCSR_MPS_MASK GENMASK(7, 5)
> > > -#define PCIE_RC_CONFIG_DCSR_MPS_256 (0x1 << 5)
> > > -#define PCIE_RC_CONFIG_LINK_CAP (PCIE_RC_CONFIG_BASE + 0xcc)
> > > -#define PCIE_RC_CONFIG_LINK_CAP_L0S BIT(10)
> > > -#define PCIE_RC_CONFIG_LCS (PCIE_RC_CONFIG_BASE + 0xd0)
> > > +#define PCIE_RC_CONFIG_CR (PCIE_RC_CONFIG_BASE + 0xc0)
> >
> > This will cause a build failure because PCIE_RC_CONFIG_CR is used in 1/5
> > but only introduced here so you'll need to do this in the same patch as
> > any step within a series must build too. IMO it would anyway make sense to
> > combine patches 1 & 2.
>
> Ah, interesting angle. I'll fix it.
>
> >
> > > #define PCIE_EP_CONFIG_LCS (PCIE_EP_CONFIG_BASE + 0xd0)
> >
> > Aren't you going to convert this as well?
>
> I can, but I can't test it however! But I'll Cc: someone who hopefully
> can.
TBH, the risk getting it wrong / changing the resulting object is pretty
low. :-)
It might be that scripts/objdiff tool could prove there were no changes in
the binary code output as it looks just a pre-preprocessor change.
--
i.
Powered by blists - more mailing lists