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: <3a1a566f-4237-4b77-acf5-030e6d5364c1@quicinc.com>
Date: Thu, 18 Dec 2025 17:02:15 +0530
From: Ram Prakash Gupta <quic_rampraka@...cinc.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        Ulf Hansson
	<ulf.hansson@...aro.org>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski
	<krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Bjorn Andersson
	<andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>,
        Adrian Hunter
	<adrian.hunter@...el.com>
CC: <linux-mmc@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
        <dmitry.baryshkov@....qualcomm.com>, <quic_pragalla@...cinc.com>,
        <quic_sayalil@...cinc.com>, <quic_nitirawa@...cinc.com>,
        <quic_bhaskarv@...cinc.com>, <kernel@....qualcomm.com>,
        Sachin Gupta
	<quic_sachgupt@...cinc.com>
Subject: Re: [PATCH v6 4/5] mmc: sdhci-msm: Add Device tree parsing logic for
 DLL settings


On 12/16/2025 7:59 PM, Konrad Dybcio wrote:
> On 12/15/25 1:00 PM, Ram Prakash Gupta wrote:
>> From: Sachin Gupta <quic_sachgupt@...cinc.com>
>>
>> This update introduces the capability to configure HS200
>> and HS400 DLL settings via the device tree and parsing it.
>>
>> Signed-off-by: Sachin Gupta <quic_sachgupt@...cinc.com>
>> Signed-off-by: Ram Prakash Gupta <quic_rampraka@...cinc.com>
>> ---
> [...]
>
>> +#define DLL_SIZE 10
>> +static int sdhci_msm_dt_parse_dll_info(struct device *dev, struct sdhci_msm_host *msm_host)
>> +{
>> +	u32 *dll_table = &msm_host->dll[0].dll_config;
>> +	int ret;
>> +
>> +	msm_host->artanis_dll = false;
>> +
>> +	ret = of_property_read_variable_u32_array(dev->of_node,
>> +						  "qcom,dll-presets",
>> +						  dll_table, DLL_SIZE, DLL_SIZE);
>> +	if (ret == DLL_SIZE)
>> +		msm_host->artanis_dll = true;
> This feels backwards.. can we first somehow determine whether this
> platform has the artanis_dll (whatever that is since you didn't explain)
> and then make decisions on what to retrieve from the DT & how to
> interpret it?

I checked document and with hardware designers, currently there is no
distinguishable hardware configuration which can be used, will have to
rely on dt only.

>
>> +	return ret;
>> +}
>> +
>>  static int sdhci_msm_probe(struct platform_device *pdev)
>>  {
>>  	struct sdhci_host *host;
>> @@ -2580,6 +2612,15 @@ static int sdhci_msm_probe(struct platform_device *pdev)
>>  
>>  	msm_host->saved_tuning_phase = INVALID_TUNING_PHASE;
>>  
>> +	/*
>> +	 * Parse HSR dll only when property is present in DT.
>> +	 */
> /* Parse ... */, it's short enough
>
> Probably also "DLL"
>
> Konrad

sure, will update.

Thanks,
Ram


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ