linux-kernel - Re: [PATCH RFC 7/7] pci: pwrctl: Add power control driver for qps615

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: <0b60cd30-3337-46a0-87ca-4c75b7f1ef29@linaro.org>
Date: Wed, 26 Jun 2024 17:37:19 +0200
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Krishna chaitanya chundru <quic_krichai@...cinc.com>,
 Bartosz Golaszewski <brgl@...ev.pl>,
 Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
 Lorenzo Pieralisi <lpieralisi@...nel.org>,
 Krzysztof Wilczyński <kw@...ux.com>,
 Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Bjorn Andersson <andersson@...nel.org>,
 Jingoo Han <jingoohan1@...il.com>
Cc: quic_vbadigan@...cinc.com, quic_skananth@...cinc.com,
 quic_nitegupt@...cinc.com, linux-arm-msm@...r.kernel.org,
 linux-pci@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 7/7] pci: pwrctl: Add power control driver for qps615

On 26.06.2024 2:37 PM, Krishna chaitanya chundru wrote:
> QPS615 switch needs to configured after powering on and before
> PCIe link was up.
> 
> As the PCIe controller driver already enables the PCIe link training
> at the host side, stop the link training.
> Otherwise the moment we turn on the switch it will participate in
> the link training and link may come before switch is configured through
> i2c.
> 
> The switch can be configured different ways like changing de-emphasis
> settings of the switch, disabling unused ports etc and these settings
> can vary from board to board, for that reason the sequence is taken
> from the firmware file which contains the address of the slave, to address
> and data to be written to the switch. The driver reads the firmware file
> and parses them to apply those configurations to the switch.
> 
> Signed-off-by: Krishna chaitanya chundru <quic_krichai@...cinc.com>
> ---

[...]

> +static int qcom_qps615_pwrctl_init(struct qcom_qps615_pwrctl_ctx *ctx)
> +{
> +	struct device *dev = ctx->pwrctl.dev;
> +	struct qcom_qps615_pwrctl_i2c_setting *set;
> +	const struct firmware *fw;
> +	const u8 *pos, *eof;
> +	int ret;
> +	u32 val;
> +
> +	ret = request_firmware(&fw, "qcom/qps615.bin", dev);

Is this driver only going to serve one model of the device, that will use
this specific firmware file, ever?

In other words, is QPS615 super special and no other chip like it will be
ever made?

[...]

> +
> +	bridge->ops->stop_link(bus);

This is turbo intrusive. What if there are more devices on this bus?

Konrad