Re: [PATCH] Revert "thermal: rockchip: fix up the tsadc pinctrl setting error"

[Heiko Stuebner <heiko@sntech.de>]

Am Freitag, 24. Mai 2019, 04:20:43 CEST schrieb Eduardo Valentin:
> On Wed, May 22, 2019 at 08:34:34AM -0700, Doug Anderson wrote:
> > Hi,
> > 
> > On Wed, May 22, 2019 at 7:12 AM Heiko Stuebner <heiko@sntech.de> wrote:
> > >
> > > This reverts commit 28694e009e512451ead5519dd801f9869acb1f60.
> > >
> > > The commit causes multiple issues in that:
> > > - the added call to ->control does potentially run unclocked
> > >   causing a hang of the machine
> > > - the added pinctrl-states are undocumented in the binding
> > > - the added pinctrl-states are not backwards compatible, breaking
> > >   old devicetrees.
> > >
> > > Fixes: 28694e009e51 ("thermal: rockchip: fix up the tsadc pinctrl setting error")
> > > Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> > > ---
> > >  drivers/thermal/rockchip_thermal.c | 36 +++---------------------------
> > >  1 file changed, 3 insertions(+), 33 deletions(-)
> > 
> > In case it helps with the urgency, there are lots of people who have
> > all independently needed to identify which commit stopped their boards
> > from booting mainline or broke temperature reading.  I'm aware of at
> > least these reports:
> > 
> > Reported-by: kernelci.org bot <bot@kernelci.org>
> > Reported-by: Enric Balletbo Serra <eballetbo@gmail.com>
> > Reported-by: Vicente Bergas <vicencb@gmail.com>
> > Reported-by: Jack Mitchell <ml@embed.me.uk>
> > Reported-by: Douglas Anderson <dianders@chromium.org>
> > 
> > I can confirm that my board boots again after this revert, thus:
> > 
> > Tested-by: Douglas Anderson <dianders@chromium.org>
> 
> I see. I can collect this revert if that is what unblocks you guys.
>
> Elaine, do you mind checking why these pinctrl changes are causing
> boot issues?

The pinctrl issue is secondary, it makes the thermal driver fail to
probe, due to not handling existing devicetrees properly.
Hence the driver needs to stay backwards compatible with existing
devicetrees.

The hang is caused by the call to the per-soc ->control callback before
the clocks get enabled, relying on it being on at boot and that isn't the
case everywhere.

Heiko