linux-kernel - Re: [PATCH] thermal: imx: interpret fsl,tempmon-data through nvmem

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]

Date:   Wed, 5 Jul 2017 15:33:05 +0300
From:   Leonard Crestez <leonard.crestez@....com>
To:     Eduardo Valentin <edubezval@...il.com>
CC:     Shawn Guo <shawnguo@...nel.org>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Zhang Rui <rui.zhang@...el.com>,
        "Rob Herring" <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Lothar Waßmann <LW@...O-electronics.de>,
        Fabio Estevam <fabio.estevam@....com>,
        Bai Ping <ping.bai@....com>, Anson Huang <Anson.Huang@....com>,
        Dong Aisheng <aisheng.dong@....com>,
        "Octavian Purdila" <octavian.purdila@....com>,
        <devicetree@...r.kernel.org>, <linux-pm@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] thermal: imx: interpret fsl,tempmon-data through nvmem

On Tue, 2017-07-04 at 11:54 -0700, Eduardo Valentin wrote:
> On Mon, Jun 19, 2017 at 04:40:43PM +0300, Leonard Crestez wrote:
> > 
> > On imx6sx accessing the ocotp memory area directly is wrong because the
> > ocotp clock needs to be enabled first. Fix this by reinterpreting the
> > fsl,tempmon-data phandle as a reference to a nvmem_device and doing all
> > the read through that.
> > 
> > @@ -347,29 +348,39 @@ static struct thermal_zone_device_ops imx_tz_ops = {
> >  static int imx_get_sensor_data(struct platform_device *pdev)
> >  {
> >  	struct imx_thermal_data *data = platform_get_drvdata(pdev);
> > -	struct regmap *map;
> > +	struct device_node *ocotp_np;
> > +	struct nvmem_device *ocotp;
> >  	int t1, n1;
> >  	int ret;
> >  	u32 val;
> >  	u64 temp64;
> >  
> > -	map = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
> > -					      "fsl,tempmon-data");
> > -	if (IS_ERR(map)) {
> > -		ret = PTR_ERR(map);
> > -		dev_err(&pdev->dev, "failed to get sensor regmap: %d\n", ret);
> > +	ocotp_np = of_parse_phandle(pdev->dev.of_node, "fsl,tempmon-data", 0);
> > +	if (IS_ERR(ocotp_np)) {
> > +		ret = PTR_ERR(ocotp_np);
> > +		dev_err(&pdev->dev, "failed to parse fsl,tempmon-data phandle: %d\n", ret);
> > +		return ret;
> > +	}
> > +	ocotp = of_nvmem_device_phandle_get(ocotp_np);
> > +	of_node_put(ocotp_np);
> > +	if (IS_ERR(ocotp)) {
> > +		ret = PTR_ERR(ocotp);
> > +		if (ret != -EPROBE_DEFER)
> > +			dev_err(&pdev->dev, "failed to get fsl,tempmon-data nvmem device: %d\n", ret);
> >  		return ret;
> >  	}
> >  
> > @@ -404,10 +415,11 @@ static int imx_get_sensor_data(struct platform_device *pdev)
> >  	data->c2 = n1 * data->c1 + 1000 * t1;
> >  
> >  	/* use OTP for thermal grade */
> > -	ret = regmap_read(map, OCOTP_MEM0, &val);
> > -	if (ret) {
> > -		dev_err(&pdev->dev, "failed to read temp grade: %d\n", ret);
> > -		return ret;

> I see a few other occurences of regmap_read() in this driver, for
> example, inside imx_get_temp(). Do they also get affect by the reported
> bug? Should they be replaced with nvmem_device_read() too?

No, most of the code uses regmap to read from the tempmon device
itself.

It is only imx_get_sensor_data which uses syscon_regmap_lookup to fetch
the regmap for another device (ocotp) in order to read calibration data
and thermal grading at probe time. Perhaps this function should be
renamed to something like imx_tempmon_init_calib.

The problem is that on newer imx SOCs reading directly from OCOTP like
that doesn't work if the ocotp clock is not enabled.

--
Regards,
Leonard