Hi Guillaume,
[...]
> +struct amlogic_thermal {
> + struct platform_device *pdev;
> + const struct amlogic_thermal_data *data;
> + struct regmap *regmap;
> + struct regmap *sec_ao_map;
> + struct clk *clk;
> + struct thermal_zone_device *tzd;
> + u32 trim_info;
> + void __iomem *base;
nit-pick: this is only used in _probe() so you could make it a local
variable there
[...]
> +static const struct of_device_id of_amlogic_thermal_match[] = {
> + {
> + .compatible = "amlogic,g12-ddr-thermal",
> + .data = &amlogic_thermal_g12_ddr_param,
> + },
> + {
> + .compatible = "amlogic,g12-cpu-thermal",
> + .data = &amlogic_thermal_g12_cpu_param,
> + },
I assume you are using "g12" to indicate that it's valid for both,
G12A and G12B?
meson-g12-common.dtsi currently does not use any other "amlogic,g12-*"
compatible string (there are some meson-axg-*, meson-gx-* and
meson-g12a-* ones, but no g12-*)
I would like to hear Kevin's and Neil's opinion on this one whether we
should introduce that "amlogic,g12-*" prefix or stick to
"amlogic,g12a-*"
[...]
> + ret = amlogic_thermal_enable(pdata);
> + if (ret)
> + clk_disable_unprepare(pdata->clk);
amlogic_thermal_enable only returns an error-code if clk_prepare_enable() fails
in that case the clock is neither prepared nor enabled so we must not
call clk_disable_unprepare
apart from that it looks good to me (as someone who doesn't know the
thermal framework)
Martin
