[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200323183659.GU1922688@smile.fi.intel.com>
Date: Mon, 23 Mar 2020 20:36:59 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Sergey.Semin@...kalelectronics.ru
Cc: Hoan Tran <hoan@...amperecomputing.com>,
Linus Walleij <linus.walleij@...aro.org>,
Bartosz Golaszewski <bgolaszewski@...libre.com>,
Serge Semin <fancer.lancer@...il.com>,
Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Paul Burton <paulburton@...nel.org>,
Ralf Baechle <ralf@...ux-mips.org>,
"Enrico Weigelt, metux IT consult" <info@...ux.net>,
Thomas Gleixner <tglx@...utronix.de>,
Kate Stewart <kstewart@...uxfoundation.org>,
linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 4/6] gpio: dwapb: Use optional-clocks interface for
APB ref-clock
On Mon, Mar 23, 2020 at 09:06:30PM +0300, Sergey.Semin@...kalelectronics.ru wrote:
> From: Serge Semin <Sergey.Semin@...kalelectronics.ru>
>
> The common clocks kernel framework provides a generic way to use
> an optional reference clock sources. If it's utilized there is no
> need in checking whether the clock descriptor pointer is actually a
> negative error at the moment of the prepare/unprepare clocks method
> calling. So if the corresponding clock source is provided, then
> getting an error shall actually terminate the device probe procedure.
> If it isn't specified then the driver shall proceed with further
> initializations.
>
> We'll use the optional clocks getting method to handle the APB reference
> clock, which can be provided for instance in the device of-node with
> "bus" clock-name.
> - if (!IS_ERR(gpio->clk))
> - clk_prepare_enable(gpio->clk);
> + clk_prepare_enable(gpio->clk);
Perhaps it makes sense now to consider error code returned by above.
Maybe it's material for a separate patch (up to you).
The rest looks good.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists