Hi Thomas, On Mon, 25 Aug 2008 09:58:16 +0800, Zhang Rui wrote: > On Mon, 2008-08-25 at 06:11 +0800, Thomas Renninger wrote: > > diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c > > index fe07462..51a7077 100644 > > --- a/drivers/thermal/thermal_sys.c > > +++ b/drivers/thermal/thermal_sys.c > > @@ -371,8 +371,15 @@ thermal_add_hwmon_sysfs(struct > > thermal_zone_device *tz) > > tz->hwmon = hwmon; > > hwmon->count++; > > > > - snprintf(tz->temp_input.name, THERMAL_NAME_LENGTH, > > - "temp%d_input", hwmon->count); > > + /* > > + * What happens if we get duplicate zone names from the BIOS? > > + * Is that allowed? If not, should we still just add the > > + * hwmon count at the end? > > + * tz->temp_input.name is char[16], this is ugly to do... > > + */ > > + if (!tz->temp_input.name) > > + snprintf(tz->temp_input.name, THERMAL_NAME_LENGTH, > > + "temp%d_input", hwmon->count); > > we should create a new attribute here rather than replacing the old one. > the new hwmon sysfs I/F should be like: > temp1_input: current temperature > temp1_crit: critical threshold > temp1_label: string like "Processor Thermal Zone" Rui is correct here, you don't want to use the string as a file name (what your patch is currently doing) but provide it to libsensors (amongst others) as the contents of a separate file (tempN_label.) libsensors needs these standard file names, otherwise it can't guess which is what. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
