linux-kernel - Re: [RFC/RFT v3 04/14] clk: meson: eeclk: add setup callback

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 26 Jul 2019 16:50:41 +0200
From:   Neil Armstrong <narmstrong@...libre.com>
To:     Jerome Brunet <jbrunet@...libre.com>, khilman@...libre.com
Cc:     linux-arm-kernel@...ts.infradead.org,
        linux-amlogic@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-clk@...r.kernel.org, martin.blumenstingl@...glemail.com,
        linux-gpio@...r.kernel.org
Subject: Re: [RFC/RFT v3 04/14] clk: meson: eeclk: add setup callback

On 03/07/2019 16:17, Jerome Brunet wrote:
> On Mon 01 Jul 2019 at 11:12, Neil Armstrong <narmstrong@...libre.com> wrote:
> 
>> Add a setup() callback in the eeclk structure, to call an optional
>> call() function at end of eeclk probe to setup clocks.
>>
>> It's used for the G12A clock controller to setup the CPU clock
>> notifiers.
> 
> I'd prefer if you implement the probe function in the related controller
> have this probe function call meson_eeclkc_probe() for the common part
> 
> In your case, I suppose it means implementing the g12a controller probe
> to deal with the notifiers

Sure, but with this eeclk setup callback I can provide a different setup() callback
for g12a and g12b (and later sm1), without this means adding a top data struct
containing a setup() callback pointer and the soc meson_eeclkc_data struct to be able
to call a setup() for each family like done actually, but this will broke eeclk since
the match_data data won't be a meson_eeclkc_data() struct anymore.

If you still prefer this, I can rework it like that.

I'm rebasing all the stuff on v5.3-rc1 and plan to repost an updated version
shortly, solving this would be easier.

Neil

> 
>>
>> Signed-off-by: Neil Armstrong <narmstrong@...libre.com>
>> ---
>>  drivers/clk/meson/meson-eeclk.c | 6 ++++++
>>  drivers/clk/meson/meson-eeclk.h | 1 +
>>  2 files changed, 7 insertions(+)
>>
>> diff --git a/drivers/clk/meson/meson-eeclk.c b/drivers/clk/meson/meson-eeclk.c
>> index 6ba2094be257..81fd2abcd173 100644
>> --- a/drivers/clk/meson/meson-eeclk.c
>> +++ b/drivers/clk/meson/meson-eeclk.c
>> @@ -61,6 +61,12 @@ int meson_eeclkc_probe(struct platform_device *pdev)
>>  		}
>>  	}
>>  
>> +	if (data->setup) {
>> +		ret = data->setup(pdev);
>> +		if (ret)
>> +			return ret;
>> +	}
>> +
>>  	return devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get,
>>  					   data->hw_onecell_data);
>>  }
>> diff --git a/drivers/clk/meson/meson-eeclk.h b/drivers/clk/meson/meson-eeclk.h
>> index 9ab5d6fa7ccb..7fdf424f71a6 100644
>> --- a/drivers/clk/meson/meson-eeclk.h
>> +++ b/drivers/clk/meson/meson-eeclk.h
>> @@ -20,6 +20,7 @@ struct meson_eeclkc_data {
>>  	const struct reg_sequence	*init_regs;
>>  	unsigned int			init_count;
>>  	struct clk_hw_onecell_data	*hw_onecell_data;
>> +	int				(*setup)(struct platform_device *pdev);
>>  };
>>  
>>  int meson_eeclkc_probe(struct platform_device *pdev);
>> -- 
>> 2.21.0