Re: [PATCH v6 2/2] clk: wpcm450: Add Nuvoton WPCM450 clock/reset controller driver

["Jonathan Neuschäfer" <j.neuschaefer@gmx.net>]

[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]

On Thu, Apr 20, 2023 at 07:32:07AM +0200, Christophe JAILLET wrote:
> Le 19/04/2023 à 23:52, Jonathan Neuschäfer a écrit :
> > On Sat, Apr 15, 2023 at 02:16:09PM +0200, Christophe JAILLET wrote:
> > > Le 15/04/2023 à 13:13, Jonathan Neuschäfer a écrit :
[...]
> > > > +	// Enables/gates
> > > > +	for (i = 0; i < ARRAY_SIZE(clken_data); i++) {
> > > > +		const struct wpcm450_clken_data *data = &clken_data[i];
> > > > +
> > > > +		hw = clk_hw_register_gate_parent_data(NULL, data->name, &data->parent, data->flags,
> > > > +						      clk_base + REG_CLKEN, data->bitnum,
> > > > +						      data->flags, &wpcm450_clk_lock);
> > > 
> > > If an error occures in the 'for' loop or after it, should this be
> > > clk_hw_unregister_gate()'ed somewhere?
> > 
> > Ideally yes —
> > 
> > in this case, if the clock driver fails, the system is arguably in such
> > a bad state that there isn't much point in bothering.
> > 
> 
> Ok, but below we care about freeing clk_data->hws in the error handling
> path.
> 
> Why do we handle just half of the resources?
> Shouldn't it be all (to be clean, if it makes sense) or nothing (to reduce
> the LoC and have a smaller driver)?

I thought about it for a bit, and I think I'm ok with reducing the
deallocation in this driver to nothing. I'll spin a new version.

Conversely, if I were to implement proper error handling here, I'd
convert it into a platform driver and use devm_* functions, because
dealing with all the little clock objects is just too painful and
fragile for my taste.


Thanks,
Jonathan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]