Re: [PATCH v1 13/17] mlxsw: core_thermal: Use the .should_bind() thermal zone callback

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 31, 2024 at 3:01 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
>
> On Wed, Jul 31, 2024 at 2:43 PM Ido Schimmel <idosch@xxxxxxxxxx> wrote:
> >
> > On Tue, Jul 30, 2024 at 08:34:45PM +0200, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> > >
> > > Make the mlxsw core_thermal driver use the .should_bind() thermal zone
> > > callback to provide the thermal core with the information on whether or
> > > not to bind the given cooling device to the given trip point in the
> > > given thermal zone.  If it returns 'true', the thermal core will bind
> > > the cooling device to the trip and the corresponding unbinding will be
> > > taken care of automatically by the core on the removal of the involved
> > > thermal zone or cooling device.
> > >
> > > It replaces the .bind() and .unbind() thermal zone callbacks (in 3
> > > places) which assumed the same trip points ordering in the driver
> > > and in the thermal core (that may not be true any more in the
> > > future).  The .bind() callbacks used loops over trip point indices
> > > to call thermal_zone_bind_cooling_device() for the same cdev (once
> > > it had been verified) and all of the trip points, but they passed
> > > different 'upper' and 'lower' values to it for each trip.
> > >
> > > To retain the original functionality, the .should_bind() callbacks
> > > need to use the same 'upper' and 'lower' values that would be used
> > > by the corresponding .bind() callbacks when they are about about to
> >
> > Nit: s/about about/about/
>
> Yes, thanks!
>
> > > return 'true'.  To that end, the 'priv' field of each trip is set
> > > during the thermal zone initialization to point to the corresponding
> > > 'state' object containing the maximum and minimum cooling states of
> > > the cooling device.
> > >
> > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> >
> > Please see more comments below, but this patch is going to conflict with
> > the series at [1] which is currently under review. How do you want to
> > handle that?
> >
> > https://lore.kernel.org/netdev/cover.1722345311.git.petrm@xxxxxxxxxx/
>
> I may be missing something, but I don't see conflicts between this
> patch and the series above that would be hard to resolve at merge
> time.
>
> Anyway, I'll try to apply the above series locally and merge it with
> this patch, thanks for the heads up!

So there is only one merge conflict that's straightforward to resolve
(as far as I'm concerned).  My resolution of it is attached, FWIW.

In my view the changes in the series above and this patch are mostly
independent of each other.

Thanks!
diff --cc drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
index 303d2ce4dc1e,0c50a0cc316d..e746cd9c68ed
--- a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
@@@ -450,8 -389,12 +388,9 @@@ mlxsw_thermal_module_init(struct mlxsw_
  			  struct mlxsw_thermal_area *area, u8 module)
  {
  	struct mlxsw_thermal_module *module_tz;
+ 	int i;
  
  	module_tz = &area->tz_module_arr[module];
 -	/* Skip if parent is already set (case of port split). */
 -	if (module_tz->parent)
 -		return;
  	module_tz->module = module;
  	module_tz->slot_index = area->slot_index;
  	module_tz->parent = thermal;
@@@ -461,8 -404,8 +400,10 @@@
  	       sizeof(thermal->trips));
  	memcpy(module_tz->cooling_states, default_cooling_states,
  	       sizeof(thermal->cooling_states));
+ 	for (i = 0; i < MLXSW_THERMAL_NUM_TRIPS; i++)
+ 		module_tz->trips[i].priv = &module_tz->cooling_states[i];
 +
 +	return mlxsw_thermal_module_tz_init(module_tz);
  }
  
  static void mlxsw_thermal_module_fini(struct mlxsw_thermal_module *module_tz)

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]
  Powered by Linux