Re: [PATCH v7] regulator: fixed: Convert to use GPIO descriptor only

[Marcel Ziswiler <marcel.ziswiler@toradex.com>]

Hi Linus

On Thu, 2018-10-11 at 16:00 +0100, Jon Hunter wrote:
> Hi Linus,
> 
> On 11/10/18 10:29, Linus Walleij wrote:
> > On Thu, Oct 11, 2018 at 11:01 AM Marek Szyprowski
> > <m.szyprowski@samsung.com> wrote:
> > 
> > > I've just noticed that this patch causes regression on Samsung
> > > Exynos4412-based Trats2 board. Conversion to GPIO descriptor
> > > breaks
> > > operation when regulators used shared GPIO:  sii9234 i2c driver
> > > is not able to get vcc33mhl regulator (it uses shared GPIO enable
> > > line with vsil12 regulator).
> > 
> > So I guess this means that this physical GPIO line will enable the
> > vcc33mhl and the vsil12 regulators at the same time?
> > 
> > > This issue has been already pointed in case of commits:
> > > 37fa23dbccbd97663acc085bd79246f427e603a1
> > > d1dae72fab2c377ff463742eefd8ac0f9e99b7b9
> > > ab4d11e2c2329cf7cb7be31ff22489aae4dee5dc
> > 
> > A big sorry for my ignorance, I guess the information overload
> > on the mailing list just makes me miss the important points.
> > I'll try to be better, sadly I constantly fail to keep everything
> > in mind and constantly break things like this.
> > 
> > > Maybe it would be better to first solve the handling of shared
> > > enable
> > > GPIO in the descriptor-based interface before converting more
> > > regulators
> > > and stepping into this issue again?
> > 
> > I am trying to solve it, but I just don't have systems to reproduce
> > all
> > kinds of things. It's a bit stressful since this is one of those
> > runtime
> > things that is hard to test when devising a patch for systems I
> > don't
> > have.
> 
> This also appears to be causing a regression on the Tegra124 Jetson
> TK1
> that also uses a shared GPIO for two regulators. The 2nd regulator
> that
> uses the GPIO now fails to probe [0] ...
> 
> [    0.680021] +5V_SATA: supplied by +5V_SYS
> [    0.683964] reg-fixed-voltage: probe of regulators:regulator@14
> failed with error -16
> 
> Not sure if you have one of these, but otherwise I can help test.

I guess that is also what broke HDMI on Apalis/Colibri T30 causing me
to submit a fix [1]. I may also help testing.

BTW: Is it only me or is today's -next completely broken now?

[    0.691258] Unable to handle kernel NULL pointer dereference at
virtual address 000001f8
[    0.699704] pgd = (ptrval)
[    0.702515] [000001f8] *pgd=00000000
[    0.706236] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[    0.711749] Modules linked in:
[    0.714930] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.0-rc7-
next-20181011-dirty #3
[    0.723245] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
[    0.729765] PC is at gpiod_hog+0x2c/0x150
[    0.733933] LR is at of_gpiochip_add+0x34c/0x510

This has been observed on Apalis TK1.

> Cheers
> Jon
> 
> [0] https://storage.kernelci.org/next/master/next-20181011/arm/tegra_
> defconfig/lab-baylibre-seattle/boot-tegra124-jetson-tk1.html 

Cheers

Marcel

[1] https://lore.kernel.org/lkml/20181009152523.3771-4-marcel@ziswiler.com