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: <Z5hqKufgEsbF12Tr@hu-varada-blr.qualcomm.com>
Date: Tue, 28 Jan 2025 10:54:58 +0530
From: Varadarajan Narayanan <quic_varada@...cinc.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
CC: <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 Mon, Jan 27, 2025 at 04:16:32PM +0100, Konrad Dybcio wrote:
> 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

Sure, will post a new version.

Thanks
Varada

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ