linux-kernel - Re: [PATCH v6 4/4] PCI: qcom: Add RX margining settings for 16.0 GT/s

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: <ZtlXH5yNe8LbZts-@hovoldconsulting.com>
Date: Thu, 5 Sep 2024 09:00:47 +0200
From: Johan Hovold <johan@...nel.org>
To: Shashank Babu Chinta Venkata <quic_schintav@...cinc.com>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
	Richard Zhu <hongxing.zhu@....com>,
	Lucas Stach <l.stach@...gutronix.de>,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Krzysztof Wilczyński <kw@...ux.com>,
	Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
	Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>,
	Jingoo Han <jingoohan1@...il.com>,
	Chuanhua Lei <lchuanhua@...linear.com>,
	Marek Vasut <marek.vasut+renesas@...il.com>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
	linux-pci@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	imx@...ts.linux.dev, linux-kernel@...r.kernel.org,
	linux-renesas-soc@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	abel.vesa@...aro.org, johan+linaro@...nel.org
Subject: Re: [PATCH v6 4/4] PCI: qcom: Add RX margining settings for 16.0 GT/s

On Wed, Sep 04, 2024 at 01:48:09PM -0700, Shashank Babu Chinta Venkata wrote:
> On 9/4/24 09:04, Manivannan Sadhasivam wrote:
> > On Wed, Sep 04, 2024 at 11:53:42AM +0200, Johan Hovold wrote:
> >> On Wed, Sep 04, 2024 at 12:42:00PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> >>> From: Shashank Babu Chinta Venkata <quic_schintav@...cinc.com>

> >>> +void qcom_pcie_common_set_16gt_rx_margining_settings(struct dw_pcie *pci)
> >>
> >> I'd try to find a shorter symbol name here, "settings" seems redundant
> >> after "set". Perhaps just
> >>
> >> 	qcom_pcie_common_enable_lane_margining()
> >>
> >> or
> >>
> >> 	qcom_pcie_common_enable_16gt_lane_margining()?
> >>
> > 
> > This one looks better. Since lane margining is implemented in the receiver, we
> > don't really need 'rx' in the function name.
> > 
> >> if these settings are indeed specific to 16 GT/s. But perhaps it's
> >> better to let the helper honour pci->max_link_speed if different
> >> settings will later be needed for higher speeds:
> >>
> >> 	if (pcie_link_speed[pci->max_link_speed] >= PCIE_SPEED_16_0GT)
> >> 		qcom_pcie_common_enable_lane_margining(pci)
> >>
> > 
> > I did thought about it during the review, but this setting claims to be for 16
> > GT/s only. So I wouldn't recommend applying it to other speeds without checking 
> > with Qcom.

Yeah, this was more an example of what the code may look like eventually
since IIUC anything above Gen4 will need lane margining.

> > Unfortunately, I'm on vacation for 2 weeks and have limited access to Qcom
> > internal docs/chat. So won't be able to check it soon. If Shashank could check
> > it, it is fine. But on the conservative side, let's stick to 16 GT/s only?

> Yes Mani I think we have to stick to 16 GT/s only for now as we
> haven't characterized 32 GT/s yet.

Sounds good. We can always generalise or rename these functions later
(e.g. when adding support for higher speeds).

> >>>  void qcom_pcie_common_set_16gt_eq_settings(struct dw_pcie *pci);
> >>> +void qcom_pcie_common_set_16gt_rx_margining_settings(struct dw_pcie *pci);

Perhaps just dropping "_settings" (and replacing "_rx") is enough for
now? So something like:

	qcom_pcie_common_set_16gt_equalization()
	qcom_pcie_common_set_16gt_lane_margining()

A bit shorter and pretty self-explaining.

Johan