linux-kernel - Re: [PATCH] link up validation moved to pcie-designware

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: <20160208164104.GA17268@localhost>
Date:	Mon, 8 Feb 2016 10:41:04 -0600
From:	Bjorn Helgaas <helgaas@...nel.org>
To:	Joao Pinto <Joao.Pinto@...opsys.com>
Cc:	arnd@...db.de, linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org, CARLOS.PALMINHA@...opsys.com
Subject: Re: [PATCH] link up validation moved to pcie-designware

On Mon, Feb 08, 2016 at 12:43:58PM +0000, Joao Pinto wrote:
> This patch goal is to centralize in pcie-designware the link up
> validation. A new function was added to pci-designware that is
> responsible for doing such a task. This was implemented in a form that
> permits flexibility for all SoCs.
> 
> Signed-off-by: Joao Pinto <jpinto@...opsys.com>
> ---
>  drivers/pci/host/pci-dra7xx.c      | 11 +++--------
>  drivers/pci/host/pci-exynos.c      | 11 ++---------
>  drivers/pci/host/pci-imx6.c        | 11 +++--------
>  drivers/pci/host/pcie-designware.c | 20 ++++++++++++++++++++
>  drivers/pci/host/pcie-designware.h |  2 ++
>  drivers/pci/host/pcie-spear13xx.c  | 12 ++----------
>  6 files changed, 32 insertions(+), 35 deletions(-)

> +int dw_pcie_check_link_is_up(struct pcie_port *pp, int max_ret, int sleep_min,
> +								int sleep_max)

I think "dw_pcie_wait_for_link()" would be a more descriptive name.

I doubt that the variations between drivers in number of retries and
amount of time to wait are meaningful.  I suspect most of those
numbers are made up or copied from other drivers.  So we might not
need the max_ret, sleep_min, and sleep_max parameters at all.

Even if there really are important differences, I suspect the only
important thing is the total time we're prepared to wait, and we can
leave it up to dw_pcie_wait_for_link() to decide how to split that up
into sleep ranges and retries.

> +{
> +	int retries;
> +
> +	/* check if the link is up or not */
> +	for (retries = 0; retries < max_ret; retries++) {
> +		if (dw_pcie_link_up(pp)) {
> +			dev_info(pp->dev, "link up\n");
> +			return 0;
> +		}
> +		usleep_range(sleep_min, sleep_max);
> +	}
> +
> +	dev_err(pp->dev, "phy link never came up\n");
> +
> +	return 1;
> +}