Hi Philipp,
Am Dienstag, 25. Juni 2013, 11:04:34 schrieb Philipp Zabel:
> Hi Heiko,
>
> Am Dienstag, den 25.06.2013, 10:46 +0200 schrieb Heiko Stübner:
> > The pool is created thru devm_gen_pool_create, so the call to
> > gen_pool_destroy is not necessary.
> > Instead the sram-clock must be turned off again if it exists.
> >
> > Signed-off-by: Heiko Stuebner <he...@sntech.de>
> > ---
> >
> > drivers/misc/sram.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
> > index d87cc91..afe66571 100644
> > --- a/drivers/misc/sram.c
> > +++ b/drivers/misc/sram.c
> > @@ -68,7 +68,8 @@ static int sram_probe(struct platform_device *pdev)
> >
> > ret = gen_pool_add_virt(sram->pool, (unsigned long)virt_base,
> >
> > res->start, size, -1);
> >
> > if (ret < 0) {
> >
> > - gen_pool_destroy(sram->pool);
>
> Right, thanks.
>
> > + if (sram->clk)
> > + clk_disable_unprepare(sram->clk);
> >
> > return ret;
> >
> > }
>
> In light of the following patch, I'd rather move the
> clk_prepare_enable() call after gen_pool_add_virt() and its error path.
I'm not sure, but isn't moving the clock enablement below the pool allocation
producing a race condition?
I.e. can the case happen that some other part wants to allocate part of the
newly generated pool already, while the subsequent gen_pool_add_virt calls
from the following patch are still running? ... And what will happen in this
case, when the sram clock is still disabled?
Thanks
Heiko
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
