public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Inochi Amaoto <inochiama@gmail.com>
Cc: "Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
	"Rob Herring" <robh@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Chen Wang" <unicorn_wang@outlook.com>,
	"Philipp Zabel" <p.zabel@pengutronix.de>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Niklas Cassel" <cassel@kernel.org>,
	"Shashank Babu Chinta Venkata" <quic_schintav@quicinc.com>,
	linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
	sophgo@lists.linux.dev, linux-kernel@vger.kernel.org,
	linux-riscv@lists.infradead.org, "Yixun Lan" <dlan@gentoo.org>,
	"Longbin Li" <looong.bin@gmail.com>
Subject: Re: [PATCH 2/2] PCI: sophgo-dwc: Add Sophgo SG2044 PCIe driver
Date: Fri, 21 Feb 2025 17:49:58 -0600	[thread overview]
Message-ID: <20250221234958.GA372914@bhelgaas> (raw)
In-Reply-To: <20250221013758.370936-3-inochiama@gmail.com>

On Fri, Feb 21, 2025 at 09:37:56AM +0800, Inochi Amaoto wrote:
> Add support for DesignWare-based PCIe controller in SG2044 SoC.

> @@ -341,6 +341,16 @@ config PCIE_ROCKCHIP_DW_EP
>  	  Enables support for the DesignWare PCIe controller in the
>  	  Rockchip SoC (except RK3399) to work in endpoint mode.
>  
> +config PCIE_SOPHGO_DW
> +	bool "SOPHGO DesignWare PCIe controller"

What's the canonical styling of "SOPHGO"?  I see "Sophgo" in the
subject line and in Chen Wang's SG2042 series.  Pick the official
styling and use it consistently.

Reorder this so the menuconfig menu items remain alphabetically
sorted.

> +	depends on ARCH_SOPHGO || COMPILE_TEST
> +	depends on PCI_MSI
> +	depends on OF
> +	select PCIE_DW_HOST
> +	help
> +	  Enables support for the DesignWare PCIe controller in the
> +	  SOPHGO SoC.
> +
>  config PCI_EXYNOS
>  	tristate "Samsung Exynos PCIe controller"
>  	depends on ARCH_EXYNOS || COMPILE_TEST

> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * PCIe host controller driver for Sophgo SoCs.

Looks too generic, since Chen Wang's series says Sophgo SG2042 SoC is
Cadence-based, so this driver apparently doesn't cover all Sophgo
SoCs.

> + *

Spurious blank line.

> + */
> +
> +#include <linux/clk.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/irqchip/chained_irq.h>
> +#include <linux/irqdomain.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/phy/phy.h>
> +#include <linux/property.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/reset.h>
> +
> +#include "pcie-designware.h"
> +
> +#define to_sophgo_pcie(x)		dev_get_drvdata((x)->dev)
> +
> +#define PCIE_INT_SIGNAL			0xc48
> +#define PCIE_INT_EN			0xca0
> +
> +#define PCIE_SIGNAL_INTX_SHIFT		5
> +#define PCIE_INT_EN_INTX_SHIFT		1

Define masks with GENMASK() and get rid of the _SHIFT #defines.

> +#define PCIE_INT_EN_INT_SII		BIT(0)
> +#define PCIE_INT_EN_INT_INTA		BIT(1)
> +#define PCIE_INT_EN_INT_INTB		BIT(2)
> +#define PCIE_INT_EN_INT_INTC		BIT(3)
> +#define PCIE_INT_EN_INT_INTD		BIT(4)

These are unused, drop them.

> +#define PCIE_INT_EN_INT_MSI		BIT(5)
> +
> +struct sophgo_pcie {
> +	struct dw_pcie pci;
> +	void __iomem *app_base;
> +	struct clk_bulk_data *clks;
> +	unsigned int clk_cnt;
> +	struct reset_control *rst;
> +	struct irq_domain *irq_domain;

Indent the member names to align vertically as most other drivers do.

> +};
> +
> +static int sophgo_pcie_readl_app(struct sophgo_pcie *sophgo, u32 reg)
> +{
> +	return readl_relaxed(sophgo->app_base + reg);
> +}
> +
> +static void sophgo_pcie_writel_app(struct sophgo_pcie *sophgo, u32 val, u32 reg)
> +{
> +	writel_relaxed(val, sophgo->app_base + reg);
> +}
> +
> +static void sophgo_pcie_intx_handler(struct irq_desc *desc)
> +{
> +	struct dw_pcie_rp *pp = irq_desc_get_handler_data(desc);
> +	struct irq_chip *chip = irq_desc_get_chip(desc);
> +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> +	struct sophgo_pcie *sophgo = to_sophgo_pcie(pci);
> +	unsigned long hwirq = PCIE_SIGNAL_INTX_SHIFT;
> +	unsigned long reg;
> +
> +	chained_irq_enter(chip, desc);
> +
> +	reg = sophgo_pcie_readl_app(sophgo, PCIE_INT_SIGNAL);
> +
> +	for_each_set_bit_from(hwirq, &reg, PCI_NUM_INTX + PCIE_SIGNAL_INTX_SHIFT)

Use FIELD_GET() here and iterate through PCI_NUM_INTX.  Then you don't
need for_each_set_bit_from() and shouldn't need PCIE_SIGNAL_INTX_SHIFT
here and below.

> +		generic_handle_domain_irq(sophgo->irq_domain,
> +					  hwirq - PCIE_SIGNAL_INTX_SHIFT);
> +
> +	chained_irq_exit(chip, desc);
> +}
> +
> +static void sophgo_intx_mask(struct irq_data *d)
> +{
> +	struct dw_pcie_rp *pp = irq_data_get_irq_chip_data(d);
> +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> +	struct sophgo_pcie *sophgo = to_sophgo_pcie(pci);
> +	unsigned long flags;
> +	u32 val;
> +
> +	raw_spin_lock_irqsave(&pp->lock, flags);
> +
> +	val = sophgo_pcie_readl_app(sophgo, PCIE_INT_EN);
> +	val &= ~BIT(d->hwirq + PCIE_INT_EN_INTX_SHIFT);

FIELD_PREP().

> +	sophgo_pcie_writel_app(sophgo, val, PCIE_INT_EN);
> +
> +	raw_spin_unlock_irqrestore(&pp->lock, flags);
> +};
> +
> +static void sophgo_intx_unmask(struct irq_data *d)
> +{
> +	struct dw_pcie_rp *pp = irq_data_get_irq_chip_data(d);
> +	struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> +	struct sophgo_pcie *sophgo = to_sophgo_pcie(pci);
> +	unsigned long flags;
> +	u32 val;
> +
> +	raw_spin_lock_irqsave(&pp->lock, flags);
> +
> +	val = sophgo_pcie_readl_app(sophgo, PCIE_INT_EN);
> +	val |= BIT(d->hwirq + PCIE_INT_EN_INTX_SHIFT);

Ditto.

> +	sophgo_pcie_writel_app(sophgo, val, PCIE_INT_EN);
> +
> +	raw_spin_unlock_irqrestore(&pp->lock, flags);
> +};
> +
> +static void sophgo_intx_eoi(struct irq_data *d)
> +{
> +}
> +
> +static struct irq_chip sophgo_intx_irq_chip = {
> +	.name			= "INTx",
> +	.irq_mask		= sophgo_intx_mask,
> +	.irq_unmask		= sophgo_intx_unmask,
> +	.irq_eoi		= sophgo_intx_eoi,

Name these ending with the irq_chip field names, e.g.,
sophgo_intx_irq_mask(), to make them easier to find with grep.

Bjorn

  parent reply	other threads:[~2025-02-21 23:49 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-21  1:37 [PATCH 0/2] riscv: sophgo Add PCIe support to Sophgo SG2044 SoC Inochi Amaoto
2025-02-21  1:37 ` [PATCH 1/2] dt-bindings: pci: Add Sophgo SG2044 PCIe host Inochi Amaoto
2025-02-21 17:01   ` Conor Dooley
2025-02-22  0:34     ` Inochi Amaoto
2025-02-24 18:54       ` Conor Dooley
2025-02-24 23:48         ` Inochi Amaoto
2025-02-25 23:35           ` Conor Dooley
2025-02-28  6:34             ` Inochi Amaoto
2025-02-28  8:46               ` Inochi Amaoto
2025-02-28  9:20                 ` Inochi Amaoto
2025-03-03 17:04                   ` Conor Dooley
2025-03-04  0:36                     ` Inochi Amaoto
2025-03-05  4:43                     ` Inochi Amaoto
2025-03-05 16:32                       ` Conor Dooley
2025-02-21  1:37 ` [PATCH 2/2] PCI: sophgo-dwc: Add Sophgo SG2044 PCIe driver Inochi Amaoto
2025-02-21  9:07   ` Philipp Zabel
2025-02-22  0:30     ` Inochi Amaoto
2025-02-21 23:49   ` Bjorn Helgaas [this message]
2025-02-22  0:43     ` Inochi Amaoto
2025-02-24 19:47       ` Bjorn Helgaas
2025-02-24 23:39         ` Inochi Amaoto
  -- strict thread matches above, loose matches on Subject: below --
2025-03-04  7:12 [PATCH 0/2] riscv: sophgo Add PCIe support to Sophgo SG2044 SoC Inochi Amaoto
2025-03-04  7:12 ` [PATCH 2/2] PCI: sophgo-dwc: Add Sophgo SG2044 PCIe driver Inochi Amaoto
2025-03-04 17:36   ` Bjorn Helgaas
2025-03-05  5:09     ` Inochi Amaoto
2025-03-04 23:57   ` Chen Wang
2025-03-05  5:18     ` Inochi Amaoto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250221234958.GA372914@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=bhelgaas@google.com \
    --cc=cassel@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlan@gentoo.org \
    --cc=inochiama@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=kw@linux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=looong.bin@gmail.com \
    --cc=lpieralisi@kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=p.zabel@pengutronix.de \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=quic_schintav@quicinc.com \
    --cc=robh@kernel.org \
    --cc=sophgo@lists.linux.dev \
    --cc=unicorn_wang@outlook.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox