linux-kernel - Re: [PATCH v2 1/2] PCI: altera: refactor driver for supporting new platform

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 8 Sep 2023 07:44:04 -0500
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     "D M, Sharath Kumar" <sharath.kumar.d.m@...el.com>
Cc:     "lpieralisi@...nel.org" <lpieralisi@...nel.org>,
        "kw@...ux.com" <kw@...ux.com>, "robh@...nel.org" <robh@...nel.org>,
        "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "dinguyen@...nel.org" <dinguyen@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] PCI: altera: refactor driver for supporting new
 platform

On Fri, Sep 08, 2023 at 09:09:34AM +0000, D M, Sharath Kumar wrote:
> > -----Original Message-----
> > From: Bjorn Helgaas <helgaas@...nel.org>
> > ...

> > > +	int (*ep_read_cfg)(struct altera_pcie *pcie, u8 busno,
> > > +			unsigned int devfn, int where, int size, u32 *value);
> > > +	int (*ep_write_cfg)(struct altera_pcie *pcie, u8 busno,
> > > +			unsigned int devfn, int where, int size, u32 value);
> > 
> > "ep_read_cfg" isn't the ideal name because it suggests "endpoint", but it may
> > be either an endpoint or a switch upstream port.  The rockchip driver uses
> > "other", which isn't super descriptive either but might be better.
> > 
> Ok will change to "nonrp_read_cfg" ?

I think the important point is not whether it's a Root Port or not,
but whether it's on the root *bus* or not.  In other words, I think
the driver has to determine whether to generate a Type 0 (targeting
something on the root bus) or a Type 1 (targeting something below a
bridge) config transaction (see PCI-to-PCI Bridge spec r1.2, sec
3.1.2.1).

There can be non-Root Ports on the root bus, so "nonrp" doesn't seem
quite right.  "Other" would be OK, since that's already used by other
drivers.  Maybe "type0" and "type1" would be better and would fit well
with the root_bus_nr check you use to distinguish them?

> > > +static int _altera_pcie_cfg_read(struct altera_pcie *pcie, u8 busno,
> > > +				 unsigned int devfn, int where, int size,
> > > +				 u32 *value)
> > > +{
> > > +	if (busno == pcie->root_bus_nr && pcie->pcie_data->ops-
> > >rp_read_cfg)
> > > +		return pcie->pcie_data->ops->rp_read_cfg(pcie, busno,
> > devfn,
> > > +							where, size, value);
> > > +
> > > +	if (pcie->pcie_data->ops->ep_read_cfg)
> > > +		return pcie->pcie_data->ops->ep_read_cfg(pcie, busno,
> > devfn,
> > > +							where, size, value);
> > > +	return PCIBIOS_FUNC_NOT_SUPPORTED;
> > > +}