On 07/19/2017 01:52 AM, Stephen Boyd wrote:
> On 07/18, Vladimir Zapolskiy wrote:
>> On 07/18/2017 10:53 AM, gabriel.fernandez@xxxxxx wrote:
>>> From: Gabriel Fernandez <gabriel.fernandez@xxxxxx>
>>> }
>>> +EXPORT_SYMBOL_GPL(clk_gate_is_enabled);
>>>
>>> const struct clk_ops clk_gate_ops = {
>>> .enable = clk_gate_enable,
>>> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
>>> index c59c625..e9587ab 100644
>>> --- a/include/linux/clk-provider.h
>>> +++ b/include/linux/clk-provider.h
>>> @@ -343,6 +343,7 @@ struct clk_hw *clk_hw_register_gate(struct device *dev, const char *name,
>>> u8 clk_gate_flags, spinlock_t *lock);
>>> void clk_unregister_gate(struct clk *clk);
>>> void clk_hw_unregister_gate(struct clk_hw *hw);
>>> +int clk_gate_is_enabled(struct clk_hw *hw);
>>
>> Here the prefix does not reflect the type of its argument, it might be
>> acceptable for a veiled function, but it is not wanted for the exported
>> function. Something like clk_hw_gate_is_enabled() is expected here, but
>> again, let's firstly come to an agreement, that the export is needed.
>>
>
> I'd prefer clk_gate_is_enabled() as it's not a struct clk_hw_gate,
> it's a struct clk_gate
Formally it's a 'struct clk_hw', and 'struct clk_hw_gate' does not exist.
> and there isn't any requirement for function names to reflect the type
> of the argument. That's what we have type analysis for.
Sure, a function name can be selected arbitrary, however because in this
particular case type analysis operates on 'struct clk_hw', it would fail
to separate 'struct clk_gate' from 'struct clk_divider', a little hint
in the naming may be helpful.
I don't insist on my preference, of course your acceptance is sufficient.
--
With best wishes,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
