From: zhangsenchuan <zhangsenchuan@eswincomputing.com>
To: "Bjorn Helgaas" <helgaas@kernel.org>
Cc: bhelgaas@google.com, mani@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, lpieralisi@kernel.org,
kwilczynski@kernel.org, robh@kernel.org, p.zabel@pengutronix.de,
jingoohan1@gmail.com, gustavo.pimentel@synopsys.com,
linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, christian.bruel@foss.st.com,
mayank.rana@oss.qualcomm.com, shradha.t@samsung.com,
krishna.chundru@oss.qualcomm.com, thippeswamy.havalige@amd.com,
inochiama@gmail.com, Frank.li@nxp.com, ningyu@eswincomputing.com,
linmin@eswincomputing.com, pinkesh.vaghela@einfochips.com,
ouyanghui@eswincomputing.com, "Niklas Cassel" <cassel@kernel.org>
Subject: Re: Re: [PATCH v9 2/2] PCI: eic7700: Add Eswin PCIe host controller driver
Date: Tue, 6 Jan 2026 20:43:11 +0800 (GMT+08:00) [thread overview]
Message-ID: <3c8d6749.1f49.19b93552d97.Coremail.zhangsenchuan@eswincomputing.com> (raw)
In-Reply-To: <20260105223037.GA332950@bhelgaas>
> Subject: Re: [PATCH v9 2/2] PCI: eic7700: Add Eswin PCIe host controller driver
>
> [+cc Niklas, list vs array of ports]
>
> On Mon, Dec 29, 2025 at 07:32:07PM +0800, zhangsenchuan@eswincomputing.com wrote:
> > From: Senchuan Zhang <zhangsenchuan@eswincomputing.com>
> >
> > Add driver for the Eswin EIC7700 PCIe host controller, which is based on
> > the DesignWare PCIe core, IP revision 5.96a. The PCIe Gen.3 controller
> > supports a data rate of 8 GT/s and 4 channels, support INTx and MSI
> > interrupts.
>
> > +config PCIE_EIC7700
> > + tristate "Eswin EIC7700 PCIe controller"
>
> > +/* Vendor and device ID value */
> > +#define PCI_VENDOR_ID_ESWIN 0x1fe1
> > +#define PCI_DEVICE_ID_ESWIN 0x2030
>
> Usually the device name is a little more than just the vendor. What
> if Eswin ever makes a second device?
Okey, thanks.
Perhaps it's a problem. Maybe PCI_DEVICE_ID_EIC7700 is better?
>
> > +static int eic7700_pcie_parse_port(struct eic7700_pcie *pcie,
> > + struct device_node *node)
> > +{
> > + struct device *dev = pcie->pci.dev;
> > + struct eic7700_pcie_port *port;
> > +
> > + port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
> > + if (!port)
> > + return -ENOMEM;
> > +
> > + port->perst = of_reset_control_get_exclusive(node, "perst");
> > + if (IS_ERR(port->perst)) {
> > + dev_err(dev, "Failed to get PERST# reset\n");
> > + return PTR_ERR(port->perst);
> > + }
> > +
> > + /*
> > + * TODO: Since the Root Port node is separated out by pcie devicetree,
> > + * the DWC core initialization code can't parse the num-lanes attribute
> > + * in the Root Port. Before entering the DWC core initialization code,
> > + * the platform driver code parses the Root Port node. The EIC7700 only
> > + * supports one Root Port node, and the num-lanes attribute is suitable
> > + * for the case of one Root Port.
> > + */
> > + if (!of_property_read_u32(node, "num-lanes", &port->num_lanes))
> > + pcie->pci.num_lanes = port->num_lanes;
> > +
> > + INIT_LIST_HEAD(&port->list);
> > + list_add_tail(&port->list, &pcie->ports);
>
> Niklas raised an interesting question about whether a list or an array
> is the best data structure for the set of Root Ports:
>
> https://lore.kernel.org/r/aVvkmkd5mWPmxeiS@ryzen
>
> Might have to iterate over the child nodes twice (once to count, again
> for eic7700_pcie_parse_port()), but otherwise the array is probably
> simpler code.
After reading patch's comments, lists and arrays seem to be good choices,
I don't have any particularly good ideas for the time being. Anyway, this
is a very good patch that supports multiple Root Ports resolutions.
>
> > + return 0;
> > +}
> > +
> > +static int eic7700_pcie_parse_ports(struct eic7700_pcie *pcie)
> > +{
> > + struct eic7700_pcie_port *port, *tmp;
> > + struct device *dev = pcie->pci.dev;
> > + int ret;
> > +
> > + for_each_available_child_of_node_scoped(dev->of_node, of_port) {
> > + ret = eic7700_pcie_parse_port(pcie, of_port);
> > + if (ret)
> > + goto err_port;
> > + }
> > +
> > + return 0;
> > +
> > +err_port:
> > + list_for_each_entry_safe(port, tmp, &pcie->ports, list)
> > + list_del(&port->list);
>
> Is some kind of reset_control_put() needed to match the
> of_reset_control_get_exclusive() above?
I only considered that there is currently only one Root Port. Maybe
there will be multiple Root Ports in the future.
Perhaps this is the best:
list_for_each_entry_safe(port, tmp, &pcie->ports, list){
if (!IS_ERR_OR_NULL(port->perst))
reset_control_put(port->perst);
list_del(&port->list);
}
>
> > +static struct platform_driver eic7700_pcie_driver = {
> > + .probe = eic7700_pcie_probe,
>
> This driver is tristate but has no .remove() callback. Seems like it
> should have one?
In v2 patch, I referred to Mani's comments and removed the .remove()
callback, as follows:
"Since this controller implements irqchip using the DWC core driver,
it is not safe to remove it during runtime."
https://lore.kernel.org/linux-pci/jghozurjqyhmtunivotitgs67h6xo4sb46qcycnbbwyvjcm4ek@vgq75olazmoi/
In addition, remove .remove() callback, because this driver has been
modified to builtin_platform_driver and does not support HotPlug,
therefore, the .remove() callback is not needed. Do you have any
better suggestions?
Kind regards,
Senchuan Zhang
>
> > + .driver = {
> > + .name = "eic7700-pcie",
> > + .of_match_table = eic7700_pcie_of_match,
> > + .suppress_bind_attrs = true,
> > + .pm = &eic7700_pcie_pm,
> > + .probe_type = PROBE_PREFER_ASYNCHRONOUS,
> > + },
> > +};
> > +builtin_platform_driver(eic7700_pcie_driver);
next prev parent reply other threads:[~2026-01-06 12:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-29 11:30 [PATCH v9 0/2] Add driver support for Eswin EIC7700 SoC PCIe controller zhangsenchuan
2025-12-29 11:31 ` [PATCH v9 1/2] dt-bindings: PCI: eic7700: Add Eswin PCIe host controller zhangsenchuan
2025-12-29 11:32 ` [PATCH v9 2/2] PCI: eic7700: Add Eswin PCIe host controller driver zhangsenchuan
2025-12-29 12:28 ` Christophe JAILLET
2025-12-30 12:21 ` zhangsenchuan
2026-01-05 22:30 ` Bjorn Helgaas
2026-01-06 12:43 ` zhangsenchuan [this message]
2026-01-06 13:19 ` Manivannan Sadhasivam
2026-01-06 17:43 ` Bjorn Helgaas
2026-01-09 11:22 ` zhangsenchuan
2026-01-21 12:00 ` zhangsenchuan
2026-01-21 13:12 ` Manivannan Sadhasivam
2026-01-21 13:08 ` Manivannan Sadhasivam
2026-01-21 12:51 ` Manivannan Sadhasivam
2026-01-09 11:23 ` zhangsenchuan
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=3c8d6749.1f49.19b93552d97.Coremail.zhangsenchuan@eswincomputing.com \
--to=zhangsenchuan@eswincomputing.com \
--cc=Frank.li@nxp.com \
--cc=bhelgaas@google.com \
--cc=cassel@kernel.org \
--cc=christian.bruel@foss.st.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gustavo.pimentel@synopsys.com \
--cc=helgaas@kernel.org \
--cc=inochiama@gmail.com \
--cc=jingoohan1@gmail.com \
--cc=krishna.chundru@oss.qualcomm.com \
--cc=krzk+dt@kernel.org \
--cc=kwilczynski@kernel.org \
--cc=linmin@eswincomputing.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=mayank.rana@oss.qualcomm.com \
--cc=ningyu@eswincomputing.com \
--cc=ouyanghui@eswincomputing.com \
--cc=p.zabel@pengutronix.de \
--cc=pinkesh.vaghela@einfochips.com \
--cc=robh@kernel.org \
--cc=shradha.t@samsung.com \
--cc=thippeswamy.havalige@amd.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