On Wed, 2023-01-18 at 22:01 +0100, Daniel Lezcano wrote:
On 18/01/2023 21:53, srinivas pandruvada wrote:Yes it is. But I can add a mutex locally here to solve.
On Wed, 2023-01-18 at 21:00 +0100, Daniel Lezcano wrote:
On 18/01/2023 20:16, srinivas pandruvada wrote:
[ ... ]
But we'd better wait for the thermald test result from
Srinvias.
A quick test show that things still work with thermald and
these
changes.
But I have a question. In some devices trip point temperature
is
not
static. When hardware changes, we get notification. For example
INT3403_PERF_TRIP_POINT_CHANGED for INT3403 drivers.
Currently get_trip can get the latest changed value. But if we
preregister, we need some mechanism to update them.
When the notification INT3403_PERF_TRIP_POINT_CHANGED happens, we
call
int340x_thermal_read_trips() which in turn updates the trip
points.
Not sure how we handle concurrency here when driver can freely
update
trips while thermal core is using trips.
Don't we have the same race without this patch ? The thermal core can
call get_trip_temp() while there is an update, no ?
But not any longer.
I think you need some thermal_zone_read_lock/unlock() in core, which
can use rcu. Even mutex is fine as there will be no contention as
updates to trips will be rare.