linux-kernel - Re: [PATCH v8 2/7] phy: qcom: Introduce PCIe UNIPHY 28LP driver

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: <60d02c55-0d18-4704-9126-8b8ffef5bd68@oss.qualcomm.com>
Date: Mon, 27 Jan 2025 16:16:32 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Varadarajan Narayanan <quic_varada@...cinc.com>, lpieralisi@...nel.org,
        kw@...ux.com, manivannan.sadhasivam@...aro.org, robh@...nel.org,
        bhelgaas@...gle.com, krzk+dt@...nel.org, conor+dt@...nel.org,
        vkoul@...nel.org, kishon@...nel.org, andersson@...nel.org,
        konradybcio@...nel.org, p.zabel@...gutronix.de,
        dmitry.baryshkov@...aro.org, quic_nsekar@...cinc.com,
        linux-arm-msm@...r.kernel.org, linux-pci@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-phy@...ts.infradead.org
Subject: Re: [PATCH v8 2/7] phy: qcom: Introduce PCIe UNIPHY 28LP driver

On 27.01.2025 8:28 AM, Varadarajan Narayanan wrote:
> From: Nitheesh Sekar <quic_nsekar@...cinc.com>
> 
> Add Qualcomm PCIe UNIPHY 28LP driver support present
> in Qualcomm IPQ5332 SoC and the phy init sequence.
> 
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
> Signed-off-by: Nitheesh Sekar <quic_nsekar@...cinc.com>
> Signed-off-by: Varadarajan Narayanan <quic_varada@...cinc.com>
> ---

[...]

> +	usleep_range(CLK_EN_DELAY_MIN_US, CLK_EN_DELAY_MAX_US);
> +
> +	qcom_uniphy_pcie_init(phy);
> +	return 0;

Please add a newline before the return statement

[...]

> +static int qcom_uniphy_pcie_probe(struct platform_device *pdev)
> +{
> +	struct phy_provider *phy_provider;
> +	struct device *dev = &pdev->dev;
> +	struct qcom_uniphy_pcie *phy;
> +	struct phy *generic_phy;
> +	int ret;
> +
> +	phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
> +	if (!phy)
> +		return -ENOMEM;
> +
> +	platform_set_drvdata(pdev, phy);
> +	phy->dev = &pdev->dev;
> +
> +	phy->data = of_device_get_match_data(dev);
> +	if (!phy->data)
> +		return -EINVAL;
> +
> +	phy->lanes = 1;
> +	if (of_property_read_u32(dev_of_node(dev), "num-lanes", &phy->lanes))
> +		dev_info(dev, "Not able to get num-lanes. Assuming 1\n");

return dev_err_probe(dev, ret, "Couldn't read num-lanes\n");

And please make num-lanes required in bindings there

We don't want silent fallbacks in such cases, as it's easy to miss those and
e.g. ship a product which would then run the PCIe link at half the speed

Konrad