Message ID | 20230221180710.2781027-1-daniel.lezcano@linaro.org |
---|---|
Headers | show |
Series | Self-encapsulate the thermal zone device structure | expand |
Dne torek, 21. februar 2023 ob 19:06:55 CET je Daniel Lezcano napisal(a): > The thermal zone device structure is exposed to the different drivers > and obviously they access the internals while that should be > restricted to the core thermal code. > > In order to self-encapsulate the thermal core code, we need to prevent > the drivers accessing directly the thermal zone structure and provide > accessor functions to deal with. > > Provide an accessor to the 'devdata' structure and make use of it in > the different drivers. > > No functional changes intended. > > Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> > Acked-by: Guenter Roeck <linux@roeck-us.net> #hwmon > Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> #R-Car > Acked-by: Mark Brown <broonie@kernel.org> > Reviewed-by: Ido Schimmel <idosch@nvidia.com> #mlxsw > Reviewed-by: AngeloGioacchino Del Regno > <angelogioacchino.delregno@collabora.com> #MediaTek auxadc and lvts > Reviewed-by: Balsam CHIHI <bchihi@baylibre.com> #Mediatek lvts > Acked-by: Gregory Greenman <gregory.greenman@intel.com> #iwlwifi > Reviewed-by: Adam Ward <DLG-Adam.Ward.opensource@dm.renesas.com> #da9062 > Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> #spread > Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> #power_supply > --- > drivers/acpi/thermal.c | 16 ++++++++-------- > drivers/ata/ahci_imx.c | 2 +- > drivers/hwmon/hwmon.c | 4 ++-- > drivers/hwmon/pmbus/pmbus_core.c | 2 +- > drivers/hwmon/scmi-hwmon.c | 2 +- > drivers/hwmon/scpi-hwmon.c | 2 +- > drivers/iio/adc/sun4i-gpadc-iio.c | 2 +- > drivers/input/touchscreen/sun4i-ts.c | 2 +- > .../net/ethernet/chelsio/cxgb4/cxgb4_thermal.c | 2 +- > .../net/ethernet/mellanox/mlxsw/core_thermal.c | 14 +++++++------- > drivers/net/wireless/intel/iwlwifi/mvm/tt.c | 4 ++-- > drivers/power/supply/power_supply_core.c | 2 +- > drivers/regulator/max8973-regulator.c | 2 +- > drivers/thermal/armada_thermal.c | 4 ++-- > drivers/thermal/broadcom/bcm2711_thermal.c | 2 +- > drivers/thermal/broadcom/bcm2835_thermal.c | 2 +- > drivers/thermal/broadcom/brcmstb_thermal.c | 4 ++-- > drivers/thermal/broadcom/ns-thermal.c | 2 +- > drivers/thermal/broadcom/sr-thermal.c | 2 +- > drivers/thermal/da9062-thermal.c | 2 +- > drivers/thermal/dove_thermal.c | 2 +- > drivers/thermal/hisi_thermal.c | 2 +- > drivers/thermal/imx8mm_thermal.c | 2 +- > drivers/thermal/imx_sc_thermal.c | 2 +- > drivers/thermal/imx_thermal.c | 6 +++--- > drivers/thermal/intel/intel_pch_thermal.c | 2 +- > drivers/thermal/intel/intel_soc_dts_iosf.c | 13 +++++-------- > drivers/thermal/intel/x86_pkg_temp_thermal.c | 4 ++-- > drivers/thermal/k3_bandgap.c | 2 +- > drivers/thermal/k3_j72xx_bandgap.c | 2 +- > drivers/thermal/kirkwood_thermal.c | 2 +- > drivers/thermal/max77620_thermal.c | 2 +- > drivers/thermal/mediatek/auxadc_thermal.c | 2 +- > drivers/thermal/mediatek/lvts_thermal.c | 4 ++-- > drivers/thermal/qcom/qcom-spmi-adc-tm5.c | 4 ++-- > drivers/thermal/qcom/qcom-spmi-temp-alarm.c | 4 ++-- > drivers/thermal/qoriq_thermal.c | 2 +- > drivers/thermal/rcar_gen3_thermal.c | 4 ++-- > drivers/thermal/rcar_thermal.c | 3 +-- > drivers/thermal/rockchip_thermal.c | 4 ++-- > drivers/thermal/rzg2l_thermal.c | 2 +- > drivers/thermal/samsung/exynos_tmu.c | 4 ++-- > drivers/thermal/spear_thermal.c | 8 ++++---- > drivers/thermal/sprd_thermal.c | 2 +- > drivers/thermal/sun8i_thermal.c | 2 +- For sun8i_thermal: Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Best regards, Jernej > drivers/thermal/tegra/tegra-bpmp-thermal.c | 6 ++++-- > drivers/thermal/tegra/tegra30-tsensor.c | 4 ++-- > drivers/thermal/thermal-generic-adc.c | 2 +- > drivers/thermal/thermal_core.c | 6 ++++++ > drivers/thermal/thermal_mmio.c | 2 +- > .../thermal/ti-soc-thermal/ti-thermal-common.c | 4 ++-- > drivers/thermal/uniphier_thermal.c | 2 +- > include/linux/thermal.h | 7 +++++++ > 53 files changed, 102 insertions(+), 91 deletions(-)
Il 21/02/23 19:07, Daniel Lezcano ha scritto: > Some drivers are directly using the thermal zone's 'device' structure > field. > > Use the driver device pointer instead of the thermal zone device when > it is available. > > Remove the traces when they are duplicate with the traces in the core > code. > > Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> > Reviewed-by: Balsam CHIHI <bchihi@baylibre.com> #Mediatek LVTS Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> #MediaTek LVTS
On 2/21/23 10:06, Daniel Lezcano wrote: > The thermal zone device structure is exposed to the different drivers > and obviously they access the internals while that should be > restricted to the core thermal code. > > In order to self-encapsulate the thermal core code, we need to prevent > the drivers accessing directly the thermal zone structure and provide > accessor functions to deal with. > > Provide an accessor to the 'devdata' structure and make use of it in > the different drivers. > > No functional changes intended. > > Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> > Acked-by: Guenter Roeck <linux@roeck-us.net> #hwmon > Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> #R-Car > Acked-by: Mark Brown <broonie@kernel.org> > Reviewed-by: Ido Schimmel <idosch@nvidia.com> #mlxsw > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> #MediaTek auxadc and lvts > Reviewed-by: Balsam CHIHI <bchihi@baylibre.com> #Mediatek lvts > Acked-by: Gregory Greenman <gregory.greenman@intel.com> #iwlwifi > Reviewed-by: Adam Ward <DLG-Adam.Ward.opensource@dm.renesas.com> #da9062 > Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> #spread > Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> #power_supply Acked-by: Florian Fainelli <f.fainelli@gmail.com> #Broadcom
On Wed, Feb 22, 2023 at 9:00 PM Daniel Lezcano <daniel.lezcano@linaro.org> wrote: > > On 22/02/2023 20:43, Rafael J. Wysocki wrote: > > On Tue, Feb 21, 2023 at 7:07 PM Daniel Lezcano > > <daniel.lezcano@linaro.org> wrote: > >> > >> Some drivers are directly using the thermal zone's 'device' structure > >> field. > >> > >> Use the driver device pointer instead of the thermal zone device when > >> it is available. > >> > >> Remove the traces when they are duplicate with the traces in the core > >> code. > >> > >> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> > >> Reviewed-by: Balsam CHIHI <bchihi@baylibre.com> #Mediatek LVTS > >> --- > > [ ... ] > > >> thermal_zone_device_update(data->ti_thermal, THERMAL_EVENT_UNSPECIFIED); > >> > >> - dev_dbg(&data->ti_thermal->device, "updated thermal zone %s\n", > >> + dev_dbg(data->bgp->dev, "updated thermal zone %s\n", > >> data->ti_thermal->type); > > > > The code before the change is more consistent, because it refers to > > the same object in both instances. > > > > It looks like a type field accessor is needed, eg. thermal_zone_device_type()? > > > > Or move the debug message to thermal_zone_device_update()? > > Actually it is done on purpose because the patch 9 replaces the accesses > to 'type' by 'id', the thermal_zone_device_type() accessor won't be needed. Cool. However, this is a change in behavior (albeit small) which doesn't appear to be necessary. What would be wrong with having a tz->type accessor too?
On 22/02/2023 21:06, Rafael J. Wysocki wrote: > On Wed, Feb 22, 2023 at 9:00 PM Daniel Lezcano > <daniel.lezcano@linaro.org> wrote: >> >> On 22/02/2023 20:43, Rafael J. Wysocki wrote: >>> On Tue, Feb 21, 2023 at 7:07 PM Daniel Lezcano >>> <daniel.lezcano@linaro.org> wrote: >>>> >>>> Some drivers are directly using the thermal zone's 'device' structure >>>> field. >>>> >>>> Use the driver device pointer instead of the thermal zone device when >>>> it is available. >>>> >>>> Remove the traces when they are duplicate with the traces in the core >>>> code. >>>> >>>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> >>>> Reviewed-by: Balsam CHIHI <bchihi@baylibre.com> #Mediatek LVTS >>>> --- >> >> [ ... ] >> >>>> thermal_zone_device_update(data->ti_thermal, THERMAL_EVENT_UNSPECIFIED); >>>> >>>> - dev_dbg(&data->ti_thermal->device, "updated thermal zone %s\n", >>>> + dev_dbg(data->bgp->dev, "updated thermal zone %s\n", >>>> data->ti_thermal->type); >>> >>> The code before the change is more consistent, because it refers to >>> the same object in both instances. >>> >>> It looks like a type field accessor is needed, eg. thermal_zone_device_type()? >>> >>> Or move the debug message to thermal_zone_device_update()? >> >> Actually it is done on purpose because the patch 9 replaces the accesses >> to 'type' by 'id', the thermal_zone_device_type() accessor won't be needed. > > Cool. > > However, this is a change in behavior (albeit small) which doesn't > appear to be necessary. > > What would be wrong with having a tz->type accessor too? I can add the 'type' accessor but from my point of view it is not correct because the information belongs to the thermal framework and it is used to export the information in the sysfs which is along with the directory name giving the id of the thermal zone. Actually, the useful information is the id of the thermal zone, not the type. This one can be duplicate, for instance: cat /sys/class/thermal/thermal_zone*/type acpitz acpitz Given there are few places where 'type' is used in the drivers, I prefer to directly change that to 'id' in the next patch instead of creating the accessor for 'type', then send another series removing it.
On Thu, Feb 23, 2023 at 10:56 AM Daniel Lezcano <daniel.lezcano@linaro.org> wrote: > > On 22/02/2023 21:06, Rafael J. Wysocki wrote: > > On Wed, Feb 22, 2023 at 9:00 PM Daniel Lezcano > > <daniel.lezcano@linaro.org> wrote: > >> > >> On 22/02/2023 20:43, Rafael J. Wysocki wrote: > >>> On Tue, Feb 21, 2023 at 7:07 PM Daniel Lezcano > >>> <daniel.lezcano@linaro.org> wrote: > >>>> > >>>> Some drivers are directly using the thermal zone's 'device' structure > >>>> field. > >>>> > >>>> Use the driver device pointer instead of the thermal zone device when > >>>> it is available. > >>>> > >>>> Remove the traces when they are duplicate with the traces in the core > >>>> code. > >>>> > >>>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> > >>>> Reviewed-by: Balsam CHIHI <bchihi@baylibre.com> #Mediatek LVTS > >>>> --- > >> > >> [ ... ] > >> > >>>> thermal_zone_device_update(data->ti_thermal, THERMAL_EVENT_UNSPECIFIED); > >>>> > >>>> - dev_dbg(&data->ti_thermal->device, "updated thermal zone %s\n", > >>>> + dev_dbg(data->bgp->dev, "updated thermal zone %s\n", > >>>> data->ti_thermal->type); > >>> > >>> The code before the change is more consistent, because it refers to > >>> the same object in both instances. > >>> > >>> It looks like a type field accessor is needed, eg. thermal_zone_device_type()? > >>> > >>> Or move the debug message to thermal_zone_device_update()? > >> > >> Actually it is done on purpose because the patch 9 replaces the accesses > >> to 'type' by 'id', the thermal_zone_device_type() accessor won't be needed. > > > > Cool. > > > > However, this is a change in behavior (albeit small) which doesn't > > appear to be necessary. > > > > What would be wrong with having a tz->type accessor too? > > I can add the 'type' accessor but from my point of view it is not > correct because the information belongs to the thermal framework and it > is used to export the information in the sysfs which is along with the > directory name giving the id of the thermal zone. I'm not sure what you mean here. Surely, the 'type' is provided by whoever registers the thermal zone, so I'm not sure in what way it "belongs" to the framework. > Actually, the useful information is the id of the thermal zone, not the > type. This one can be duplicate, for instance: > > cat /sys/class/thermal/thermal_zone*/type > acpitz > acpitz That's correct, but in the particular case of DT-based systems it comes from the DT (AFAICT) and so it allows to connect the kernel message with the DT contents. The id could be used for that, but that involves an extra sysfs lookup. > Given there are few places where 'type' is used in the drivers, I prefer > to directly change that to 'id' in the next patch instead of creating > the accessor for 'type', then send another series removing it. So you are going to change the behavior of those few places with the only reason being aesthetics AFAICS. Is this really a good enough reason to do that?
On 23/02/2023 12:43, Rafael J. Wysocki wrote: > On Thu, Feb 23, 2023 at 10:56 AM Daniel Lezcano > <daniel.lezcano@linaro.org> wrote: >> >> On 22/02/2023 21:06, Rafael J. Wysocki wrote: >>> On Wed, Feb 22, 2023 at 9:00 PM Daniel Lezcano >>> <daniel.lezcano@linaro.org> wrote: >>>> >>>> On 22/02/2023 20:43, Rafael J. Wysocki wrote: >>>>> On Tue, Feb 21, 2023 at 7:07 PM Daniel Lezcano >>>>> <daniel.lezcano@linaro.org> wrote: >>>>>> >>>>>> Some drivers are directly using the thermal zone's 'device' structure >>>>>> field. >>>>>> >>>>>> Use the driver device pointer instead of the thermal zone device when >>>>>> it is available. >>>>>> >>>>>> Remove the traces when they are duplicate with the traces in the core >>>>>> code. >>>>>> >>>>>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> >>>>>> Reviewed-by: Balsam CHIHI <bchihi@baylibre.com> #Mediatek LVTS >>>>>> --- >>>> >>>> [ ... ] >>>> >>>>>> thermal_zone_device_update(data->ti_thermal, THERMAL_EVENT_UNSPECIFIED); >>>>>> >>>>>> - dev_dbg(&data->ti_thermal->device, "updated thermal zone %s\n", >>>>>> + dev_dbg(data->bgp->dev, "updated thermal zone %s\n", >>>>>> data->ti_thermal->type); >>>>> >>>>> The code before the change is more consistent, because it refers to >>>>> the same object in both instances. >>>>> >>>>> It looks like a type field accessor is needed, eg. thermal_zone_device_type()? >>>>> >>>>> Or move the debug message to thermal_zone_device_update()? >>>> >>>> Actually it is done on purpose because the patch 9 replaces the accesses >>>> to 'type' by 'id', the thermal_zone_device_type() accessor won't be needed. >>> >>> Cool. >>> >>> However, this is a change in behavior (albeit small) which doesn't >>> appear to be necessary. >>> >>> What would be wrong with having a tz->type accessor too? >> >> I can add the 'type' accessor but from my point of view it is not >> correct because the information belongs to the thermal framework and it >> is used to export the information in the sysfs which is along with the >> directory name giving the id of the thermal zone. > > I'm not sure what you mean here. > > Surely, the 'type' is provided by whoever registers the thermal zone, > so I'm not sure in what way it "belongs" to the framework. I meant the goal of 'type' is to be exported to sysfs, nothing else. That is the reason why I used the word 'belongs', because it was introduced to stay in the scope of the thermal framework, but then its usage has been diverted to a name. Anyway, from my POV having traces in the ops is not a good thing, so I'll propose later to remove them and add a single message in the call sites. Meanwhile, I'll provide the accessor for 'type' and hopefully we do not end up with a plethora of accessors to be used in the core code.