| 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
| ||
|
Message-ID: <20190521080515.qlni2lnmcwh7itl7@flea>
Date: Tue, 21 May 2019 10:05:15 +0200
From: Maxime Ripard <maxime.ripard@...tlin.com>
To: Frank Lee <tiny.windzz@...il.com>
Cc: rui.zhang@...el.com, Eduardo Valentin <edubezval@...il.com>,
Daniel Lezcano <daniel.lezcano@...aro.org>, robh+dt@...nel.org,
Mark Rutland <mark.rutland@....com>,
Chen-Yu Tsai <wens@...e.org>, catalin.marinas@....com,
will.deacon@....com, David Miller <davem@...emloft.net>,
Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jonathan.Cameron@...wei.com,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
paulmck@...ux.ibm.com, Andy Gross <andy.gross@...aro.org>,
olof@...om.net, bjorn.andersson@...aro.org,
Jagan Teki <jagan@...rulasolutions.com>,
marc.w.gonzalez@...e.fr, stefan.wahren@...e.com,
enric.balletbo@...labora.com, Linux PM <linux-pm@...r.kernel.org>,
devicetree@...r.kernel.org,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/3] thermal: sun50i: add thermal driver for h6
On Sat, May 18, 2019 at 01:27:39AM +0800, Frank Lee wrote:
> On Fri, May 17, 2019 at 3:36 PM Maxime Ripard <maxime.ripard@...tlin.com> wrote:
> >
> > On Fri, May 17, 2019 at 01:51:56AM +0800, Frank Lee wrote:
> > > > > +struct sun50i_thermal_chip {
> > > > > + int sensor_num;
> > > > > + int offset;
> > > > > + int scale;
> > > > > + int ft_deviation;
> > > > > + int temp_calib_base;
> > > > > + int temp_data_base;
> > > > > + int (*enable)(struct tsens_device *tmdev);
> > > > > + int (*disable)(struct tsens_device *tmdev);
> > > > > +};
> > > >
> > > > I'm not super fond of having a lot of quirks that are not needed. If
> > > > we ever need those quirks when adding support for a new SoC, then
> > > > yeah, we should totally have some, but only when and if it's needed.
> > > >
> > > > Otherwise, the driver is more complicated for no particular reason.
> > >
> > > This is unavoidable because of the difference in soc.
> >
> > I know, but this isn't my point.
> >
> > My point is that at this time of the driver development, we don't know
> > what is going to be needed to support all of those SoCs.
> >
> > Some of the parameters you added might not be needed, some parameters
> > might be missing, we don't know. So let's keep it simple for now.
> >
> > > > > +static int tsens_probe(struct platform_device *pdev)
> > > > > +{
> > > > > + struct tsens_device *tmdev;
> > > > > + struct device *dev = &pdev->dev;
> > > > > + int ret;
> > > > > +
> > > > > + tmdev = devm_kzalloc(dev, sizeof(*tmdev), GFP_KERNEL);
> > > > > + if (!tmdev)
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + tmdev->dev = dev;
> > > > > + tmdev->chip = of_device_get_match_data(&pdev->dev);
> > > > > + if (!tmdev->chip)
> > > > > + return -EINVAL;
> > > > > +
> > > > > + ret = tsens_init(tmdev);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > +
> > > > > + ret = tsens_register(tmdev);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > +
> > > > > + ret = tmdev->chip->enable(tmdev);
> > > > > + if (ret)
> > > > > + return ret;
> > > > >
> > > > > + platform_set_drvdata(pdev, tmdev);
> > > >
> > > > Your registration should be the very last thing you do. Otherwise, you
> > > > have a small window where the get_temp callback can be called, but the
> > > > driver will not be functional yet.
> > >
> > > No. Anyway, ths data qcquisition is ms level.
> >
> > That's kind of irrelevant. There's nothing preventing get_temp to be
> > called right away.
>
> As Ondřej said,
>
> Registration after enabling will lead to call tz update on non-registered tz
> from an interrupt handler.
I'm probably missing something but you're not using the interrupts, so
how could an interrupt handler call it?
Also, other drivers seem to be doing that just fine (mtk_thermal for
example), so surely there's a way?
> > > > > + ret = tsens_calibrate(tmdev);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > +
> > > > > + /*
> > > > > + * clkin = 24MHz
> > > > > + * T acquire = clkin / (SUN50I_THS_CTRL0_T_ACQ + 1)
> > > > > + * = 20us
> > > > > + */
> > > > > + regmap_write(tmdev->regmap, SUN50I_THS_CTRL0,
> > > > > + SUN50I_THS_CTRL0_T_ACQ(479));
> > > > > + /* average over 4 samples */
> > > > > + regmap_write(tmdev->regmap, SUN50I_H6_THS_MFC,
> > > > > + SUN50I_THS_FILTER_EN |
> > > > > + SUN50I_THS_FILTER_TYPE(1));
> > > > > + /* period = (SUN50I_H6_THS_PC_TEMP_PERIOD + 1) * 4096 / clkin; ~10ms */
> > > > > + regmap_write(tmdev->regmap, SUN50I_H6_THS_PC,
> > > > > + SUN50I_H6_THS_PC_TEMP_PERIOD(58));
> > > > > + /* enable sensor */
> > > > > + val = GENMASK(tmdev->chip->sensor_num - 1, 0);
> > > > > + regmap_write(tmdev->regmap, SUN50I_H6_THS_ENABLE, val);
> > > > > +
> > > > > + return 0;
> > > > > +
> > > > > +assert_reset:
> > > > > + reset_control_assert(tmdev->reset);
> > > > > +
> > > > > + return ret;
> > > >
> > > > Can't we do that with runtime_pm?
> > >
> > > Saving energy doesn't make much sense compared to system security.
> >
> > I'm not sure what you mean by security.
>
> Protect system hardware from damage.
The point of runtime_pm is to keep the device on as long as it is
used, so it wouldn't change anything there.
I mean, you can even enable it in the probe if you want, my point is
that the hooks that you have are exact equivalents to the one provided
by runtime_pm already, so there's no need to define them in the first
place.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists