Re: [PATCH v7 12/34] i2c: tegra: Use clk-bulk helpers

[Thierry Reding]

On Thu, Sep 17, 2020 at 04:54:28PM +0300, Andy Shevchenko wrote:
> On Thu, Sep 17, 2020 at 2:38 PM Thierry Reding <thierry.reding@xxxxxxxxx> wrote:
> > On Wed, Sep 09, 2020 at 01:39:44AM +0300, Dmitry Osipenko wrote:
> > > Use clk-bulk helpers and factor out clocks initialization into separate
> > > function in order to make code cleaner.
> > >
> > > The clocks initialization now performed after reset-control initialization
> > > in order to avoid a noisy -PROBE_DEFER errors on T186+ from the clk-bulk
> > > helper which doesn't silence this error code. Hence reset_control_get()
> > > now may return -EPROBE_DEFER on newer Tegra SoCs because they use BPMP
> > > driver that provides reset controls and BPMP doesn't come up early during
> > > boot. Previously rst was protected by the clocks retrieval and now this
> > > patch makes dev_err_probe() to be used for the rst error handling.
> > >
> > > Suggested-by: Andy Shevchenko <andy.shevchenko@xxxxxxxxx>
> > > Signed-off-by: Dmitry Osipenko <digetx@xxxxxxxxx>
> > > ---
> > >  drivers/i2c/busses/i2c-tegra.c | 187 ++++++++++++---------------------
> > >  1 file changed, 67 insertions(+), 120 deletions(-)
> >
> > This is tempting from a diffstat point of view, but the downside is that
> > we can now no longer validate that all of the necessary clocks are given
> > in device tree.
> >
> > Previously the driver would fail to probe the I2C controller if any of
> > the expected clocks were not defined in device tree, but now it's just
> > going to continue without it and not give any indication as to what's
> > wrong.
> 
> You may print an error in the error path as previously. Since both
> clocks are mandatory (as far as I understood the code) user will need
> to check DT in any case.

The problem is that the number of required clocks depends on the variant
of the IP block that's implemented. Some require just one clock and
others require two or three. With this patch the driver is just going to
pick whatever clocks are given in device tree, but it removes any
possibility of detecting whether the device trees contain the correct
clocks. So we may very well run into a situation where the driver now
successfully probes but then malfunctions because one or more of the
clocks were not specified in device tree.

Thierry

Attachment: signature.asc
Description: PGP signature