linux-kernel - Re: Regulator probe

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1473091312.11323.20.camel@linux.intel.com>
Date:   Mon, 05 Sep 2016 19:01:52 +0300
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Hunter, Adrian" <adrian.hunter@...el.com>
Subject: Re: Regulator probe

On Thu, 2016-09-01 at 18:02 +0100, Mark Brown wrote:
> On Thu, Sep 01, 2016 at 07:15:16PM +0300, Andy Shevchenko wrote:
> > 
> > On Thu, 2016-09-01 at 16:38 +0100, Mark Brown wrote:
> > > 
> > > On Thu, Sep 01, 2016 at 05:53:43PM +0300, Andy Shevchenko wrote:
> 
> > 
> > > 
> > > The device isn't registered and it's saying it isn't registered,
> > > this
> > > is
> > > normal.  Since this is an ACPI system
> 
> > 
> > Nope, it's SFI. Which basically means we have everything in board
> > files.
> 
> Ugh, I'd been assured that SFI had been killed off :(

Yes, though devices are flying around (I dunno what is used in latest
MID SoC [Annidale] on Asus and Lenovo phone, I'm pretty sure it's still
SFI).

> 
> Anyway if that's the case then it should all be working already then
> unless SFI goes down the ACPI code paths or someone changed SFI since
> SFI won't flag as having full costraints and therefore any missing
> regulator will report as deferring.

But it's a real burden to describe in platform code _every_ regulators
that device driver may need (for example, "vqmmc" is optional and even
"vmmc" is optional for 2 out of 3 SDHCI host controllers!).

>   If that is indeed the case you've
> probably got a broken consumer driver that's not handing probe
> deferrals.

It has, but see above, for 3 SDHCI controllers I have to provide 5 dummy
regulators and 1 real vs. just 1 real.

> > >  we are expecting the firmware or
> > > whatever else registers devices and their supplies to do that, if
> > > the
> > > supplies aren't being mapped at device registration time then
> > > you're
> > > telling the core not to expect any.  If you had mapped the supply
> > > and
> > > it
> > > wasn't available the consumer would get an -EPROBE_DEFER.
> 
> > 
> > Basically you mean we have not call
> > regulator_has_full_constraints()?
> > In that case we have to provide stubs for all expected regulators,
> > in
> > case of SDHCI one real and one dummy, who knows how many them in the
> > drivers, but for each we have to provide that. Am I right? 
> 
> You have to either not call regulator_has_full_constraints() or supply
> all the mappings for device supplies before you register a device.  If
> you don't call regulator_has_full_constraints() missing regulators
> will
> always defer so you would need to provide a fixed voltage regulator
> for
> it.

It would be plenty of dummy regulators.

>   If it's really absent you'll need to provide full constraints, we
> can't tell otherwise.
> 
> > 
> > > 
> > > As I keep saying with all these problems if you want to
> > > reimplement DT
> > > instead of using it you need to reimplement *all* of DT, it's
> > > there
> > > for
> > > a reason.  It would be a lot quicker and simpler to just use DT
> > > for
> > > these systems.
> 
> > 
> > Here we have platform code. It might be possible to switch to DT for
> > it,
> > with no firmware support, but I can consider it as a far away from
> > now.
> 
> It would be a lot more sensible than SFI, it's so limited you're
> basically just using board files but with the limitations of having to
> do bits of it through firmware and then join the two up which seems
> like
> the worst of both worlds.

I dunno if DT has any means of coexistence with e820 BIOS where PCI
devices are enumerated natively.

So, in other words is there any example of something like following:

pinctrl: pinctrl@ {
	// platform device of pinctrl
}

pci: {
	// anonymous bus ?
	gpio: gpio@...1 {
		// GPIO device which is enumerated via PCI
		???
	}
	sdhci: sdhci@...2 {
		// SDHCI which requires vmmc@...2 to be present
		???
	}
}

regulator: vmmc@...2 {
	// Fixed regulator with GPIO provided by gpio@...1
}

For now I hardly imagine how it should look like or work.

-- 
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Intel Finland Oy