linux-kernel - Re: [PATCH v1 3/3] PCI: brcmstb: Allow setting the completion timeout

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: <09926d3d-2f1f-d060-af0f-bbc5b02d3664@i2se.com>
Date:   Thu, 6 Apr 2023 17:59:18 +0200
From:   Stefan Wahren <stefan.wahren@...e.com>
To:     Jim Quinlan <jim2101024@...il.com>, linux-pci@...r.kernel.org,
        Nicolas Saenz Julienne <nsaenz@...nel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Cyril Brulebois <kibi@...ian.org>,
        Phil Elwell <phil@...pberrypi.com>,
        bcm-kernel-feedback-list@...adcom.com, james.quinlan@...adcom.com
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>,
        Krzysztof Wilczyński <kw@...ux.com>,
        Rob Herring <robh@...nel.org>,
        "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" 
        <linux-rpi-kernel@...ts.infradead.org>,
        "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 3/3] PCI: brcmstb: Allow setting the completion timeout

Hi Jim,

Am 06.04.23 um 14:46 schrieb Jim Quinlan:
> Since the STB PCIe HW will cause a CPU abort on a completion timeout abort,
> we might as well extend the timeout limit.  Further, different devices and
> systems may requires a larger or smaller amount for L1SS exit.
> 
> Signed-off-by: Jim Quinlan <jim2101024@...il.com>
> ---
>   drivers/pci/controller/pcie-brcmstb.c | 24 ++++++++++++++++++++++++
>   1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
> index 129eee7bdbc1..92d78f4dfaae 100644
> --- a/drivers/pci/controller/pcie-brcmstb.c
> +++ b/drivers/pci/controller/pcie-brcmstb.c
> @@ -1080,6 +1080,29 @@ static void brcm_config_clkreq(struct brcm_pcie *pcie)
>   	writel(clkreq_set, pcie->base + PCIE_MISC_HARD_PCIE_HARD_DEBUG);
>   }
>   
> +static void brcm_config_completion_timeout(struct brcm_pcie *pcie)
> +{
> +	/* TIMEOUT register is two registers before RGR1_SW_INIT_1 */
> +	const unsigned int REG_OFFSET = PCIE_RGR1_SW_INIT_1(pcie) - 8;
> +	u32 timeout, timeout_msec = 1000;
> +	u64 tmp64;
> +	int ret;
> +
> +	ret = of_property_read_u32(pcie->np, "brcm,completion-abort-msecs",
> +				   &timeout_msec);
> +
> +	if (ret && ret != -EINVAL)
> +		dev_err(pcie->dev, "bad 'brcm,completion-abort-msecs' prop\n");

i'm not sure about the error behavior. If we want to proceed with 
defaults in such a case, i would make this a warning and mention the 
used defaults.

> +
> +	/* Each unit in timeout register is 1/216,000,000 seconds */
> +	tmp64 = (u64)216000 * timeout_msec;
> +
> +	/* Clamp the requested value before writing it */
> +	timeout = tmp64 > 0xffffffff ? 0xffffffff : tmp64;
> +	timeout = timeout < 0xffff ? 0xffff : timeout;

Personally i'm not a huge fan of silently clamping wrong DT values.

Best regards

> +	writel(timeout, pcie->base + REG_OFFSET);
> +}
> +
>   static int brcm_pcie_start_link(struct brcm_pcie *pcie)
>   {
>   	struct device *dev = pcie->dev;
> @@ -1110,6 +1133,7 @@ static int brcm_pcie_start_link(struct brcm_pcie *pcie)
>   		return -ENODEV;
>   	}
>   
> +	brcm_config_completion_timeout(pcie);
>   	brcm_config_clkreq(pcie);
>   
>   	if (pcie->gen)