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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220218132037.GA345784@bhelgaas>
Date:   Fri, 18 Feb 2022 07:20:37 -0600
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Kishon Vijay Abraham I <kishon@...com>
Cc:     Christian Gmeiner <christian.gmeiner@...il.com>,
        linux-kernel@...r.kernel.org, Tom Joseph <tjoseph@...ence.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Rob Herring <robh@...nel.org>,
        Krzysztof WilczyƄski <kw@...ux.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>, linux-pci@...r.kernel.org
Subject: Re: [PATCH] PCI: cadence: respond to received PTM Requests

On Fri, Feb 18, 2022 at 04:26:48PM +0530, Kishon Vijay Abraham I wrote:
> Hi Bjorn,
> 
> On 01/02/22 3:35 am, Bjorn Helgaas wrote:
> > Update subject line to match previous conventions ("git log --oneline
> > drivers/pci/controller/cadence/pcie-cadence-host.c" to see).
> > 
> > On Mon, Jan 31, 2022 at 01:08:27PM +0100, Christian Gmeiner wrote:
> >> This enables the Controller [RP] to automatically respond
> >> with Response/ResponseD messages.
> > 

> >> +static void cdns_pcie_host_enable_ptm_response(struct cdns_pcie *pcie)
> >> +{
> >> +	u32 val;
> >> +
> >> +	val = cdns_pcie_readl(pcie, CDNS_PCIE_LM_PTM_CTRL);
> >> +	cdns_pcie_writel(pcie, CDNS_PCIE_LM_PTM_CTRL, val | CDNS_PCIE_LM_TPM_CTRL_PTMRSEN);
> > 
> > I assume this is some device-specific enable bit that is effectively
> > ANDed with PCI_PTM_CTRL_ENABLE in the Precision Time Measurement
> > Capability?
> 
> That's correct. This bit enables Controller [RP] to respond to the
> received PTM Requests.

Great!  Christian, can you update the commit log to reflect that
both this bit *and* PCI_PTM_CTRL_ENABLE must be set for the RP to
respond to received PTM Requests?

When CDNS_PCIE_LM_TPM_CTRL_PTMRSEN is cleared, do PCI_PTM_CAP_ROOT
and the PTM Responder Capable bit (for which we don't have a #define)
read as zero?

I think that would be the correct behavior per PCIe r6.0, sec
7.9.15.2, and it would avoid the confusion of having the PTM
Capability register advertise functionality that cannot be enabled via
the PTM Control register.

> >> +/* PTM Control Register */
> >> +#define CDNS_PCIE_LM_PTM_CTRL 	(CDNS_PCIE_LM_BASE + 0x0DA8)

Other #defines in this file use lower-case hex.

Bjorn

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ