Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751947AbbBWHjA (ORCPT ); Mon, 23 Feb 2015 02:39:00 -0500 Received: from mga09.intel.com ([134.134.136.24]:41203 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751142AbbBWHi6 convert rfc822-to-8bit (ORCPT ); Mon, 23 Feb 2015 02:38:58 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,629,1418112000"; d="scan'208";a="670042419" From: "Kweh, Hock Leong" To: "Ong, Boon Leong" , "Zhang, Rui" , "edubezval@gmail.com" CC: "linux-pm@vger.kernel.org" , LKML , "Bryan O'Donoghue" Subject: RE: [PATCH] thermal: intel Quark SoC X1000 DTS thermal driver Thread-Topic: [PATCH] thermal: intel Quark SoC X1000 DTS thermal driver Thread-Index: AQHQRhthue+lW/FBiEKybiZlya5HaJzsNOnQgAAkD6CAESm0MIAAYxjw Date: Mon, 23 Feb 2015 07:38:53 +0000 Message-ID: References: <1423673509-11195-1-git-send-email-boon.leong.ong@intel.com> <1423673509-11195-2-git-send-email-boon.leong.ong@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.20.206] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2411 Lines: 57 > -----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! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/