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]
Message-ID: <20230908124404.GA292360@bhelgaas>
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;
> > > +}

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ