Messages in this thread | | | From | "Kweh, Hock Leong" <> | Subject | RE: [PATCH] thermal: intel Quark SoC X1000 DTS thermal driver | Date | Mon, 23 Feb 2015 07:38:53 +0000 |
| |
> -----Original Message----- > From: Ong, Boon Leong > Sent: Monday, February 23, 2015 9:39 AM > Subject: RE: [PATCH] thermal: intel Quark SoC X1000 DTS thermal driver > > >Just to bring out for discussion, do you think we should put a "safety range" > >for reporting out the critical trip temperature value (mean the value from > >register minus 1 or 2 degree)? > > > >Just wondering if this is needed for the software to have the sufficient > >shutdown time before the HW make a hard power cut off when the > >critical trip point is reached. > > I assume that the suggestion is meant for the case where thermal register is > not locked by BIOS. It is not a bad idea to have some protection against > wrong configuration on critical trip point by user. > Looking through the data-sheet in Quark, I could not find an recommended > temperature. So, I propose that we use the same value set by BIOS today > - 105C as the maximum.
What I mean here is that even the BIOS locks it and used the maximum value 105 °C for the critical trip point, should we -1 or -2 (104/103 °C) in this driver to let the system shut down before the actual trip point hit, in case the HW performs a HW power cut off before the Linux kernel has enough time to shut down properly?
> > > > +static struct soc_sensor_entry *alloc_soc_dts(void) > > > +{ > > > + struct soc_sensor_entry *aux_entry; > > > + int err; > > > + u32 out; > > > + int wr_mask; > > > + > > > + aux_entry = kzalloc(sizeof(*aux_entry), GFP_KERNEL); > > > >Wondering is it possible to use the resource-managed functions (for e.g. > >devm_kzalloc())? This could help the driver looks more neat and clean > >where the resource-managed framework will help you take care all the > >kfree(). > > > >Understand that the flow here is to call the thermal_zone_device_register() > >function after this aux_entry allocation. > > > >But thinking would it also working if change the flow to call > >thermal_zone_device_register() function 1st to obtain the > >thermal_zone_device > >then later on perform devm_kzalloc() and assign it back to devdata. > > > Ok, it is worth exploring on this devm_kzalloc() for neatness. > Thanks!
| |