[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7085302f-af69-484a-8558-2aa823379fbe@lunn.ch>
Date: Mon, 10 Feb 2025 14:37:29 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Paul Menzel <pmenzel@...gen.mpg.de>
Cc: Jedrzej Jagielski <jedrzej.jagielski@...el.com>,
intel-wired-lan@...ts.osuosl.org,
Anthony L Nguyen <anthony.l.nguyen@...el.com>,
netdev@...r.kernel.org, Simon Horman <horms@...nel.org>,
Przemyslaw Kitszel <przemyslaw.kitszel@...el.com>,
Mateusz Polchlopek <mateusz.polchlopek@...el.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v3] ixgbe: add support for
thermal sensor event reception
> > > > Then driver
> > > > logs appropriate message and closes the adapter instance.
> > > > The card remains in that state until the platform is rebooted.
> > >
> > > As a user I’d be interested what the threshold is, and what the measured
> > > temperature is. Currently, the log seems to be just generic?
> >
> > These details are FW internals.
> > Driver just gets info that such event has happened.
> > There's no additional information.
> >
> > In that case driver's job is just to inform user that such scenario
> > has happened and tell what should be the next steps.
>
> From a user perspective that is a suboptimal behavior, and shows another
> time that the Linux kernel should have all the control, and stuff like this
> should be moved *out* of the firmware and not into the firmware.
The older generations of hardware driven by this driver actually have
HWMON support for the temperature sensor. I can understand the
hardware protecting itself, and shutting down, but i agree with you,
all the infrastructure already exists to report the temperature so why
drop it? That actually seems like more work, and makes the device less
friendly.
Andrew
Powered by blists - more mailing lists