On 2/27/23 09:38, Alexander Stein wrote:
[...]
+/**
+ * devm_clk_hw_register_gate - register a gate clock with the clock
framework + * @dev: device that is registering this clock
+ * @name: name of this clock
+ * @parent_data: parent clk data
+ * @flags: framework-specific flags for this clock
+ * @reg: register address to control gating of this clock
+ * @bit_idx: which bit in the register controls gating of this clock
+ * @clk_gate_flags: gate-specific flags for this clock
+ * @lock: shared register lock for this clock
+ */
+#define devm_clk_hw_register_gate_parent_data(dev, name, parent_data,
flags, \ + reg,
bit_idx, clk_gate_flags, \
+ lock)
\
+ __devm_clk_hw_register_gate((dev), NULL, (name), NULL, NULL, \
+ (parent_data), (flags), (reg),
(bit_idx), \
+ (clk_gate_flags), (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);
Is it worth to add the parent_data paremeter into existing
devm_clk_hw_register_gate macro? Just adding this new macro for setting
parent_data instead of parent_name seems a bit too much. What if someone wants
to set parent_hw? Add another macro?
Yes, another macro seems to be the accepted practice here.
