[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <37b3b835-e992-0090-56e5-bd4d58e547a7@linaro.org>
Date: Thu, 23 Feb 2023 23:56:44 +0100
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: rafael@...nel.org
Cc: linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
Zhang Rui <rui.zhang@...el.com>, Len Brown <lenb@...nel.org>,
Damien Le Moal <damien.lemoal@...nsource.wdc.com>,
Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>,
NXP Linux Team <linux-imx@....com>,
Jean Delvare <jdelvare@...e.com>,
Guenter Roeck <linux@...ck-us.net>,
Jonathan Cameron <jic23@...nel.org>,
Lars-Peter Clausen <lars@...afoo.de>,
Chen-Yu Tsai <wens@...e.org>,
Jernej Skrabec <jernej.skrabec@...il.com>,
Samuel Holland <samuel@...lland.org>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Ido Schimmel <idosch@...dia.com>,
Petr Machata <petrm@...dia.com>,
Gregory Greenman <gregory.greenman@...el.com>,
Kalle Valo <kvalo@...nel.org>,
Sebastian Reichel <sre@...nel.org>,
Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>,
Miquel Raynal <miquel.raynal@...tlin.com>,
Amit Kucheria <amitk@...nel.org>,
Florian Fainelli <f.fainelli@...il.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@...adcom.com>,
Ray Jui <rjui@...adcom.com>,
Scott Branden <sbranden@...adcom.com>,
Markus Mayer <mmayer@...adcom.com>,
Support Opensource <support.opensource@...semi.com>,
Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Thara Gopinath <thara.gopinath@...il.com>,
Niklas Söderlund <niklas.soderlund@...natech.se>,
Heiko Stuebner <heiko@...ech.de>,
Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
Alim Akhtar <alim.akhtar@...sung.com>,
Orson Zhai <orsonzhai@...il.com>,
Baolin Wang <baolin.wang@...ux.alibaba.com>,
Chunyan Zhang <zhang.lyra@...il.com>,
Vasily Khoruzhick <anarsoul@...il.com>,
Yangtao Li <tiny.windzz@...il.com>,
Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>,
Talel Shenhar <talel@...zon.com>,
Eduardo Valentin <edubezval@...il.com>,
Keerthy <j-keerthy@...com>,
Kunihiko Hayashi <hayashi.kunihiko@...ionext.com>,
Masami Hiramatsu <mhiramat@...nel.org>,
Matthias Brugger <matthias.bgg@...il.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>,
Stefan Wahren <stefan.wahren@...e.com>,
Zheng Yongjun <zhengyongjun3@...wei.com>,
Yang Li <yang.lee@...ux.alibaba.com>,
Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
Daniel Golle <daniel@...rotopia.org>,
Balsam CHIHI <bchihi@...libre.com>,
Mikko Perttunen <mperttunen@...dia.com>,
linux-acpi@...r.kernel.org, linux-ide@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-hwmon@...r.kernel.org,
linux-iio@...r.kernel.org, linux-sunxi@...ts.linux.dev,
linux-input@...r.kernel.org, netdev@...r.kernel.org,
linux-wireless@...r.kernel.org,
linux-rpi-kernel@...ts.infradead.org,
linux-arm-msm@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
linux-rockchip@...ts.infradead.org,
linux-samsung-soc@...r.kernel.org, linux-tegra@...r.kernel.org,
linux-omap@...r.kernel.org, linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH v3 00/17] Self-encapsulate the thermal zone device
structure
On 23/02/2023 23:48, Daniel Lezcano wrote:
> The exported thermal headers expose the thermal core structure while those
> should be private to the framework. The initial idea was the thermal sensor
> drivers use the thermal zone device structure pointer to pass it around from
> the ops to the thermal framework API like a handler.
>
> Unfortunately, different drivers are using and abusing the internals of this
> structure to hook the associated struct device, read the internals values, take
> the lock, etc ...
>
> rn order to fix this situation, let's encapsulate the structure leaking the
> more in the different drivers: the thermal_zone_device structure.
>
> This series revisit the existing drivers using the thermal zone private
> structure internals to change the access to something else. For instance, the
> get_temp() ops is using the tz->dev to write a debug trace. Despite the trace
> is not helpful, we can check the return value for the get_temp() ops in the
> call site and show the message in this place.
>
> With this set of changes, the thermal_zone_device is almost self-encapsulated.
> As usual, the acpi driver needs a more complex changes, so that will come in a
> separate series along with the structure moved the private core headers.
>
> Changelog:
> - V3:
> - Collected more tags
> - Added missing changes for ->devdata in some drivers
> - Added a 'type' accessor
> - Replaced the 'type' to 'id' changes by the 'type' accessor
> - Used the 'type' accessor in the drivers
> - V2:
> - Collected tags
> - Added missing changes for ->devdata for the tsens driver
> - Renamed thermal_zone_device_get_data() to thermal_zone_priv()
> - Added stubs when CONFIG_THERMAL is not set
> - Dropped hwmon change where we remove the tz->lock usage
>
> Thank you all for your comments
The series has been blocked by gsmtp because the next patch has too many
Cc. I'll sort out this and resend.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
Powered by blists - more mailing lists