All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
	linux-kernel@vger.kernel.org, linaro-kernel@lists.linaro.org,
	atull@opensource.altera.com
Subject: Re: [PATCH] regulator: of: Lower the severity of the error with no container
Date: Wed, 8 Oct 2014 17:05:55 -0700	[thread overview]
Message-ID: <20141009000555.GA27476@roeck-us.net> (raw)
In-Reply-To: <20141008234541.GQ4609@sirena.org.uk>

On Thu, Oct 09, 2014 at 12:45:41AM +0100, Mark Brown wrote:
> On Wed, Oct 08, 2014 at 03:59:12PM -0700, Guenter Roeck wrote:
> 
> > There is a log message "no parameters" for each regulator. This is printed
> > unconditionally from print_constraints().
> 
> > Looking through the code again, looks like this is on purpose. It is just a bit
> > annoying to get lots of those messages. One of the systems I am dealing with has
> > 17 LTC2978 chips in it, with 8 channels each. That results in 136 times "no
> > parameters" in the boot log. And that is not even a fully populated system;
> > if fully populated, there can be more than 60 of those chips. 500+ lines of 
> > similar log messages is really a bit on the high side.
> 
> > It might help if there was a way to silence the messages, ie to make
> > "print_constraints" optional. 
> 
> Ah, from the constraints rather than from the DT parsing.  I do like
> having it there since it's enormously helpful in debugging and that is
> a...  specialist number of regulators you have in your system.  We can

Yes, this is a pretty large backbone switch. Kind of amazing how many
sensors are in those systems.

> definitely at least add a boot argument or something to suppress them,
> let me have a think if we want to do that by default.

It is a nuisance, so I might just disable it in our tree if we don't
find some other solution.

Did you notice the problem with debugfs I had mentioned earlier ?
With all those regulators, not all of them being used, I end up with
many having the same name. This causes issues with debugfs, which is
trying to create the same file several times.

Any idea how we could solve this ? The constraints message is annoying,
but this one is a real issue.

Thanks,
Guenter

  reply	other threads:[~2014-10-09  0:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-08 22:09 [PATCH] regulator: of: Lower the severity of the error with no container Mark Brown
2014-10-08 22:34 ` Guenter Roeck
2014-10-08 22:36   ` Mark Brown
2014-10-08 22:59     ` Guenter Roeck
2014-10-08 23:45       ` Mark Brown
2014-10-09  0:05         ` Guenter Roeck [this message]
2014-10-09  0:12           ` Mark Brown
2014-10-09  0:25             ` Guenter Roeck
2014-10-09 15:54               ` Mark Brown
2014-10-09 16:14                 ` Guenter Roeck
2014-10-09 17:49                 ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141009000555.GA27476@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=atull@opensource.altera.com \
    --cc=broonie@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.