[PATCH 7/8] reset: amlogic: add auxiliary reset driver support
Jerome Brunet
jbrunet at baylibre.com
Thu Jul 18 00:05:52 PDT 2024
On Mon 15 Jul 2024 at 12:30, Stephen Boyd <sboyd at kernel.org> wrote:
>> >> +int devm_meson_rst_aux_register(struct device *dev,
>> >> + struct regmap *map,
>> >> + const char *adev_name);
>> >> +#else
>> >> +static inline int devm_meson_rst_aux_register(struct device *dev,
>> >> + struct regmap *map,
>> >> + const char *adev_name)
>> >> +{
>> >> + return -EOPNOTSUPP;
>> >
>> > Shouldn't this be 'return 0' so that the clk driver doesn't have to care
>> > about the config?
>>
>> I don't think the system (in general) would be able function without the reset
>> driver, so the question is rather phylosophical.
>>
>> Let's say it could, if this returns 0, consumers of the reset controller
>> will defer indefinitely ... which is always a bit more difficult to sort
>> out.
>>
>> If it returns an error, the problem is pretty obvious, helping people
>> solve it quickly.
>>
>> Also the actual device we trying to register provides clocks and reset.
>> It is not like the reset is an optional part we don't care about.
>>
>> On this instance it starts from clock, but it could have been the other
>> way around. Both are equally important.
>>
>> I'd prefer if it returns an error when the registration can't even start.
>>
>
> Ok. Fair enough.
Actually, thinking about it more I changed my mind and I tend to agree
on 'return 0' which I'll use in the next version.
The initial request was to de-couple clk and reset. I was planning on
having clk 'imply' reset to have a weak dependency. That does not make
sense if an error is returned above. I would have to use 'depends on' and
don't like it in that case, sooo weak dependency it is.
It remains fairly easy to change later on if necessary
--
Jerome
More information about the linux-amlogic
mailing list