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:
signature.asc
Description: PGP signature
