linux-kernel - Re: [PATCH v14 02/10] mfd: qcom-spmi-pmic: expose the PMIC revid information to clients

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: <20220614114234.7e9dd1ac@jic23-huawei>
Date:   Tue, 14 Jun 2022 11:42:34 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Caleb Connolly <caleb.connolly@...aro.org>
Cc:     Lars-Peter Clausen <lars@...afoo.de>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Lee Jones <lee.jones@...aro.org>,
        Stephen Boyd <sboyd@...nel.org>, linux-iio@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org,
        Jami Kettunen <jami.kettunen@...ainline.org>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Subject: Re: [PATCH v14 02/10] mfd: qcom-spmi-pmic: expose the PMIC revid
 information to clients

On Sun, 1 May 2022 18:28:29 +0100
Jonathan Cameron <jic23@...nel.org> wrote:

> On Fri, 29 Apr 2022 23:08:57 +0100
> Caleb Connolly <caleb.connolly@...aro.org> wrote:
> 
> > Some PMIC functions such as the RRADC need to be aware of the PMIC
> > chip revision information to implement errata or otherwise adjust
> > behaviour, export the PMIC information to enable this.
> > 
> > This is specifically required to enable the RRADC to adjust
> > coefficients based on which chip fab the PMIC was produced in,
> > this can vary per unique device and therefore has to be read at
> > runtime.
> > 
> > Signed-off-by: Caleb Connolly <caleb.connolly@...aro.org>
> > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
> > Tested-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>  
> 
> ...
> 
> > +/**
> > + * qcom_pmic_get() - Get a pointer to the base PMIC device
> > + *
> > + * This function takes a struct device for a driver which is a child of a PMIC.
> > + * And locates the PMIC revision information for it.
> > + *
> > + * @dev: the pmic function device
> > + * @return: the struct qcom_spmi_pmic* pointer associated with the function device
> > + */
> > +inline const struct qcom_spmi_pmic *qcom_pmic_get(struct device *dev)
> > +{
> > +	struct spmi_device *sdev;
> > +	struct qcom_spmi_dev *spmi;
> > +
> > +	/*
> > +	 * Make sure the device is actually a child of a PMIC
> > +	 */
> > +	if (!of_match_device(pmic_spmi_id_table, dev->parent))
> > +		return ERR_PTR(-EINVAL);
> > +
> > +	sdev = qcom_pmic_get_base_usid(dev->parent);
> >  
> > -	if (subtype == PM8110_SUBTYPE)
> > -		minor = rev2;
> > +	if (IS_ERR(sdev))
> > +		return ERR_CAST(sdev);
> >  
> > -	dev_dbg(dev, "%x: %s v%d.%d\n", subtype, name, major, minor);
> > +	spmi = (struct qcom_spmi_dev *)dev_get_drvdata(&sdev->dev);  
> 
> Shouldn't need the cast as dev_get_drvdata() returns void * and you can
> implicitly cast that to any other pointer type.
> 
> If this is all that comes up in the series I can fixup whilst applying.
> 
> Jonathan

Hi Caleb,

Now Stephen has acked the spmi changes, only remaining ack needed
is Lee for mfd.  Given it's been a while, perhaps best bet is if you
do a v15 just wrapping up those minor tweaks and ping Lee to take a
look at it when he has time.  On off chance Lee just want's to pick it
up and push out an immutable branch (rather than me doing the same,
I'll give tags for the IIO effecting bits)

Thanks,

Jonathan

> 
> 
> > +
> > +	return &spmi->pmic;
> >  }
> > +EXPORT_SYMBOL(qcom_pmic_get);
> >    
>