From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eduardo Valentin Subject: Re: [PATCH] hwmon/sensors: fix SENSORS_LM75 dependencies Date: Tue, 7 Jan 2014 11:28:55 -0400 Message-ID: <52CC1D37.40604@ti.com> References: <20140106204020.b47e53cc3ead8f90164ef5b7@canb.auug.org.au> <52CB0948.6030702@infradead.org> <20140106203209.GA21630@roeck-us.net> <52CB53DC.4030901@infradead.org> <52CB65DA.2010103@roeck-us.net> <20140107130401.23bffcd2@endymion.delvare> <52CBF1CF.2000603@ti.com> <744357E9AAD1214791ACBA4B0B909263011BC64C@SHSMSX101.ccr.corp.intel.com> <52CC15F0.6020209@ti.com> <20140107160738.4a76a6d0@endymion.delvare> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QgwbA2aqk28CVpiw55qa319MSVul2MVnC" Return-path: Received: from comal.ext.ti.com ([198.47.26.152]:44959 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751631AbaAGPbc (ORCPT ); Tue, 7 Jan 2014 10:31:32 -0500 In-Reply-To: <20140107160738.4a76a6d0@endymion.delvare> Sender: linux-next-owner@vger.kernel.org List-ID: To: Jean Delvare Cc: Eduardo Valentin , "Zhang, Rui" , Guenter Roeck , Randy Dunlap , Stephen Rothwell , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, lm-sensors@lm-sensors.org, linux-pm@vger.kernel.org --QgwbA2aqk28CVpiw55qa319MSVul2MVnC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07-01-2014 11:07, Jean Delvare wrote: > On Tue, 7 Jan 2014 10:57:52 -0400, Eduardo Valentin wrote: >> On 07-01-2014 10:05, Zhang, Rui wrote: >>> BTW, I've been thinking of make CONFIG_THERMAL a bool since long time= ago, the only thing that blocks me is that Thermal subsystem needs to re= gister a hwmon device for each thermal zone and CONFIG_HWMON is a tristat= e. >> >> I agree with the move of having CONFIG_THERMAL as bool. Unless you hav= e >> use cases where users are dynamically loading and unloading thermal pe= r >> user demand, which I doubt. >=20 > Modularity is not only about reloading modules (although this can be > useful for developers in particular.) It's also about enabling many > features in a generic distribution kernel and each feature only gets > loaded/used on the hardware which needs it. This is why, as a In fact, no one has said anything different than the above. I definitely agree with you. Except that this needs to be taken with a bit of care. > distribution kernel maintainer, I keep complaining when I see boolean > options which might easily be tristates. Well, I would say it is not that 'easy' and not that straight forward. there a couple of items to be considered in the thermal case, the boot requirements and API provisioning are two, just to mention. There are use cases that waiting for init to be loaded and modules to be linked is just no go for thermal constraints, in case the system is already booted 'hot'. Besides, hiding APIs when a component is build is module is not very 'modular', even considering the statements you brought above. >=20 --=20 You have got to be excited about what you are doing. (L. Lamport) Eduardo Valentin --QgwbA2aqk28CVpiw55qa319MSVul2MVnC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLMHTcACgkQCXcVR3XQvP2L/AEA4/uDi0hCpifWJeYLb+YQgufP 1lslHDJXpn5p02CzRyIBAMydMpbvxLHckrsoQvd6xF4hkIcsPxG+sAZIWRpRMghc =XGl3 -----END PGP SIGNATURE----- --QgwbA2aqk28CVpiw55qa319MSVul2MVnC--