Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1641336 > unrolled thread

Re: [RFC] regulator: Shared regulators (configured by bootloader)

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC] regulator: Shared regulators (configured by bootloader) Mark Brown <broonie@kernel.org> - 2017-05-15 10:00 +0200
    Re: [RFC] regulator: Shared regulators (configured by bootloader) Viresh Kumar <viresh.kumar@linaro.org> - 2017-05-15 12:50 +0200

#1641336 — Re: [RFC] regulator: Shared regulators (configured by bootloader)

[Multipart message — attachments visible in raw view] — view raw

On Mon, May 08, 2017 at 03:51:02PM +0530, Viresh Kumar wrote:

> I am looking to solve a problem faced by some of the Qualcomm
> platforms and want your suggestions on how should we fix it. One of my
> ex-colleague tried to solve [1] this problem but that thread never
> concluded (and I don't really agree with the solution it offered).

Please engage with the feedback I offered then.  I see no point in
repeating myself here, I'm just going to provide the same feedback as
before and if I'm going to be ignored (which appears to be the case) it
doesn't seem like it's worth the effort.

[toc] | [next] | [standalone]

#1641528

On 14-05-17, 18:30, Mark Brown wrote:
> On Mon, May 08, 2017 at 03:51:02PM +0530, Viresh Kumar wrote:
> 
> > I am looking to solve a problem faced by some of the Qualcomm
> > platforms and want your suggestions on how should we fix it. One of my
> > ex-colleague tried to solve [1] this problem but that thread never
> > concluded (and I don't really agree with the solution it offered).
> 
> Please engage with the feedback I offered then.  I see no point in
> repeating myself here, I'm just going to provide the same feedback as
> before and if I'm going to be ignored (which appears to be the case) it
> doesn't seem like it's worth the effort.

I didn't ignore any of that. Most of the discussions then happened around the
solution which Pingbo tried to implement (boot-protection flag). And that had
obvious flaws as it depended on the state of the kernel to be known
(booting/booted). And that will never work, as you pointed out then, because of
the way kernel works (specially with modules).

You said this in one of the replies [1]:

> I think you need to be looking at some combination of getting the
> devices you're interested in started up early and more precisely
> describing the end result you're trying to achieve.  The issues with
> probe deferral do seem related here, it's another symptom of not really
> making any decisions about init ordering and so sometimes making bad
> ones.

I don't think we should depend on the order in which the devices get added. This
is going to break for sure.

I have some idea about the end-result we want to achieve (will take LCD as an
example here):
- The regulator should always fulfill the requirement of the LCD device set from
  the bootloader, until a point where the kernel driver has taken over.
- If the LCD kernel driver never turns up, then the regulator shall continue
  satisfying the requirements set from the bootloader. Even if that means that
  some devices may not get what they request for and perform badly. Someone
  needs to fix the LCD driver and make sure it comes up.


I failed to find any other workable solution that anyone may have suggested in
those email threads. Can you please point me to those (if any)?

Thanks.

-- 
viresh

[1] https://marc.info/?l=linux-kernel&m=146540618625247

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web