On Wed, Mar 24 2021, Klemens Nanni wrote:
> On Wed, Mar 24, 2021 at 12:49:51AM +0100, Jeremie Courreges-Anglas wrote:
>
>> >> > @@ -202,6 +217,12 @@ cwfg_attach(struct device *parent, struc
>> >> >
>> >> > sensor_task_register(sc, cwfg_update_sensors, 5);
>> >> >
>> >> > +#if NAPM >
On Wed, Mar 24, 2021 at 12:49:51AM +0100, Jeremie Courreges-Anglas wrote:
> >> > @@ -202,6 +217,12 @@ cwfg_attach(struct device *parent, struc
> >> >
> >> > sensor_task_register(sc, cwfg_update_sensors, 5);
> >> >
> >> > +#if NAPM > 0
> >> > +/* make sure we have the apm
On Mon, Mar 22 2021, Klemens Nanni wrote:
> Better diff at the end thanks to jca's eyeballing, see comments inline.
>
> kettenis: I see room for improvement in our subsystems and their
> interactions, but I don't think the current situation is bad enough to
> leave those bits out for now.
>
>
Better diff at the end thanks to jca's eyeballing, see comments inline.
kettenis: I see room for improvement in our subsystems and their
interactions, but I don't think the current situation is bad enough to
leave those bits out for now.
Feedback? OK?
On Mon, Mar 22, 2021 at 01:21:02AM +0100,
Klemens Nanni wrote:
> > So which is better:
> >
> > (1) try to emit some information for the people who quicky-use the apm
> > interface
> >
> > (2) change apm to not print those lines on architectures where we are
> > unsure.
> >
> > I think (1) is acceptable for a tool which has never
On Sun, Mar 21 2021, Mark Kettenis wrote:
>> Date: Sun, 21 Mar 2021 17:22:05 +0100
>> From: Klemens Nanni
>>
>> On Sun, Mar 21, 2021 at 02:02:00PM +0100, Mark Kettenis wrote:
>> > > Date: Sun, 21 Mar 2021 01:02:53 +0100
>> > > From: Klemens Nanni
>> > >
>> > > apm(4/arm64) merely provides an
On Sun, Mar 21, 2021 at 11:56:42AM -0600, Theo de Raadt wrote:
> The sensor framework generally does not know where a sensor is. A
> sensor could reside on some device which has been plugged in, rather
> than be the primary sensor.
>
> But the users of apm are only hoping for best effort.
>
>
On Sun, Mar 21 2021, Klemens Nanni wrote:
> apm(4/arm64) merely provides an all zero/unknown stub for those values,
> e.g. apm(8) output is useless.
>
> Hardware sensors however provide the information:
>
> $ sysctl hw.sensors
> hw.sensors.rktemp0.temp0=32.22 degC (CPU)
>
The sensor framework generally does not know where a sensor is. A
sensor could reside on some device which has been plugged in, rather
than be the primary sensor.
But the users of apm are only hoping for best effort.
meaning "some information", not "perfect information". Many PC BIOS
have lied
> Date: Sun, 21 Mar 2021 17:22:05 +0100
> From: Klemens Nanni
>
> On Sun, Mar 21, 2021 at 02:02:00PM +0100, Mark Kettenis wrote:
> > > Date: Sun, 21 Mar 2021 01:02:53 +0100
> > > From: Klemens Nanni
> > >
> > > apm(4/arm64) merely provides an all zero/unknown stub for those values,
> > > e.g.
On Sun, Mar 21, 2021 at 02:02:00PM +0100, Mark Kettenis wrote:
> > Date: Sun, 21 Mar 2021 01:02:53 +0100
> > From: Klemens Nanni
> >
> > apm(4/arm64) merely provides an all zero/unknown stub for those values,
> > e.g. apm(8) output is useless.
> >
> > Hardware sensors however provide the
> Date: Sun, 21 Mar 2021 01:02:53 +0100
> From: Klemens Nanni
>
> apm(4/arm64) merely provides an all zero/unknown stub for those values,
> e.g. apm(8) output is useless.
>
> Hardware sensors however provide the information:
>
> $ sysctl hw.sensors
> hw.sensors.rktemp0.temp0=32.22
apm(4/arm64) merely provides an all zero/unknown stub for those values,
e.g. apm(8) output is useless.
Hardware sensors however provide the information:
$ sysctl hw.sensors
hw.sensors.rktemp0.temp0=32.22 degC (CPU)
hw.sensors.rktemp0.temp1=33.89 degC (GPU)
13 matches
Mail list logo
