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] [day] [month] [year] [list]
Message-ID: <20250713143149.60763b52@jic23-huawei>
Date: Sun, 13 Jul 2025 14:31:49 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Jishnu Prakash <jishnu.prakash@....qualcomm.com>
Cc: robh@...nel.org, krzysztof.kozlowski@...aro.org, krzk+dt@...nel.org,
 conor+dt@...nel.org, agross@...nel.org, andersson@...nel.org,
 lumag@...nel.org, dmitry.baryshkov@....qualcomm.com,
 konradybcio@...nel.org, daniel.lezcano@...aro.org, sboyd@...nel.org,
 amitk@...nel.org, thara.gopinath@...il.com, lee@...nel.org,
 rafael@...nel.org, subbaraman.narayanamurthy@....qualcomm.com,
 david.collins@....qualcomm.com, anjelique.melendez@....qualcomm.com,
 quic_kamalw@...cinc.com, rui.zhang@...el.com, lukasz.luba@....com,
 devicetree@...r.kernel.org, linux-arm-msm@...r.kernel.org,
 linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-pm@...r.kernel.org, cros-qcom-dts-watchers@...omium.org,
 quic_skakitap@...cinc.com, neil.armstrong@...aro.org,
 stephan.gerhold@...aro.org
Subject: Re: [PATCH V6 4/5] iio: adc: Add support for QCOM PMIC5 Gen3 ADC

On Thu, 10 Jul 2025 12:14:13 +0530
Jishnu Prakash <jishnu.prakash@....qualcomm.com> wrote:

> Hi Jonathan,
> 
> On 6/28/2025 10:01 PM, Jonathan Cameron wrote:
> > 
> >   
> >>>> +	.hw_settle_1 = (unsigned int [VADC_HW_SETTLE_SAMPLES_MAX])
> >>>> +				{ 15, 100, 200, 300, 400, 500, 600, 700,
> >>>> +				  1000, 2000, 4000, 8000, 16000, 32000,
> >>>> +				  64000, 128000 },    
> >>> Andy often points this out, but I'll do it this time. Fixed numbers (typically power of 2)
> >>> elements per line make it much easier to see which element is which in these arrays.
> >>> Reduce the indent a little to allow that here.    
> 
> ...
> 
> >>>
> >>> It was never worth bothering with release until we had devm managed form but
> >>> now we do the code complexity cost is low enough to make it reasonable.
> >>>     
> >>>> +	indio_dev->name = pdev->name;    
> >>>
> >>> Just to check.  Does that end up as a part number or similar?    
> >>
> >> I printed this name and it appeared like this:
> >>
> >> indio_dev->name: c426000.spmi:pmic@0:adc@...0
> >>
> >> It only gets the DT node names, which are generic, there are 
> >> no part numbers in this name.  
> > I thought it might be something along those lines.
> > 
> > indio_dev->name should be the part number so hard code it rather than
> > getting it from the pdev->name
> >   
> 
> Actually there would be more than one PMIC which can function as the master PMIC
> for Gen3 ADC functionality, so I don't think I can simply hard code a name here
> based on PMK8550, if we want to keep the part number correct.
> 
> Since we can't get the part number directly from the DT node names, we
> could try one of the following ways to add it:
> 
> 1. Add a devicetree property for the part number
>    This would be simple, but I'm not sure if this is the best way, 
>    if the below method looks good.
Nope as if you need a part number, that's should be via the compatible.
> 
> 2. Add a string in the compatible property for the part number.
>    This means updating the compatible from "qcom,spmi-adc5-gen3"
>    to something like this for PMK8550:
> 
>    compatible = "qcom,pmk8550-adc5-gen3", "qcom,spmi-adc5-gen3";
> 
>    and then extracting the part number from the first string.

Do it via a compatible lookup + data in relevant tables rather
than messing with string break up.  Sometimes we'll get the
part number of the fallback compatible but I don't really care.
However, see below - I think spmi-adc5-gen3 is effectively the
part number for the IP. It just happens to be inside a PMIC
that has another name.

> 
> Please let me know which method you would prefer.
> 
> In addition, does the below string look fine, to assign to
> indio_dev->name for PMK8550?
> 
> pmk8550_adc

That's ok, though given it's an ADC anyway, pmk8550 should be sufficient
for this IIO specific name.
If it makes no practical difference what PMIC it is for this driver
then simply use spmi-adc5-gem3 or something along those lines.
So kind of a generic part number for the IP rather than specifics of
which PMIC it is implemented in.

Jonathan


> 
> Please let me know if you want a different format here.
> 
> Thanks,
> Jishnu
> 
> > 
> > Jonathan  
> 
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ