public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nishanth Menon <nm@ti.com>
To: Shawn Guo <shawn.guo@linaro.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	"cpufreq@vger.kernel.org" <cpufreq@vger.kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Carlos Hernandez <ceh@ti.com>
Subject: Re: [PATCH] cpufreq: cpufreq-cpu0: Use a sane boot frequency when booting with a mismatched bootloader configuration
Date: Mon, 18 Nov 2013 10:41:36 -0600	[thread overview]
Message-ID: <528A4340.3020508@ti.com> (raw)
In-Reply-To: <20131118155753.GU11014@S2101-09.ap.freescale.net>

On 11/18/2013 09:57 AM, Shawn Guo wrote:
> On Mon, Nov 18, 2013 at 08:45:12AM -0600, Nishanth Menon wrote:
> <snip>
>> I do not agree about this stance - device tree describes hardware
>> capabilities to kernel -> I agree with that statement. Kernel should
>> not care if that is provided by bootloader/firmware/fused into
>> flash/ROM etc.
> 
> Yea, ideally kernel should just believe that the device tree is always
> the correct one.  But the following text in your commit log suggests
> that might not be always the case.
> 
> | a) older or default bootloader in development platform without latest
> | updates
> | b) SoC documentation update that may have occurred in kernel
> | c) kernel definitions are out of date Vs bootloader which is updated
> | etc..
> | 
> | In these cases, we should assume from a kernel perspective, the only
> | safe frequency that the system can be on is the ones available in the
> | OPP table. This may not handle case (c), but, that is a different
> | kernel bug of it's own.
> 
> It says that the device tree might be wrong as well.  That's why I
> think the best/safest thing that kernel can do when seeing a mismatch
> is to throw out an error message and fail out.

In the case of mismatch, to consider that device tree may be wrong in
driver is also to assume that hardware was always configured correctly
and we assume description is the flawed data. That is just plain
wrong. we need to assume device tree is the correct description of the
hardware and any mismatch must be assumed as bad configuration - and
this is what the patch does.

Now, if the description is wrong, that is a dts bug of it's own.

If the suggestion is to improve my commit message, I am more than
happy to do so - please suggest how I could improve the same.

> 
> Shawn
> 
>>
>> If we agree with that statement, the moment kernel sees device
>> operating in a configuration that is not hardware capability, it is
>> our job to switch to the right configuration if it is possible for us
>> to do so (which in this case, we can). to give a comparison - if i2c
>> bus was configured for 3.4MHz and device tree describes the bus to
>> operate at 100KHz, do we ignore device tree recommended configuration?
>> No. we would switch to 100KHz. as far as kernel is concerned, it can
>> detect invalid configuration and switch back to a valid configuration
>> based on hardware description provided by device tree.
>>
>>
>>
>> -- 
>> Regards,
>> Nishanth Menon
> 


-- 
Regards,
Nishanth Menon

  reply	other threads:[~2013-11-18 16:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-16  2:22 [PATCH] cpufreq: cpufreq-cpu0: Use a sane boot frequency when booting with a mismatched bootloader configuration Nishanth Menon
2013-11-16 13:44 ` Shawn Guo
2013-11-17  4:02   ` Viresh Kumar
2013-11-18 14:45     ` Nishanth Menon
2013-11-18 15:57       ` Shawn Guo
2013-11-18 16:41         ` Nishanth Menon [this message]
2013-11-19  2:21           ` Shawn Guo
2013-11-19  3:46             ` Viresh Kumar
2013-11-19 14:16               ` Nishanth Menon
2013-11-19 14:26                 ` Viresh Kumar
2013-11-19 14:59                   ` Nishanth Menon
2013-11-19 15:32                     ` Viresh Kumar
2013-11-19 15:48                       ` Nishanth Menon
2013-11-19 17:10                         ` Viresh Kumar
2013-11-19 17:43                           ` Nishanth Menon
2013-11-20  5:24                             ` viresh kumar
2013-11-20 14:59                               ` Nishanth Menon
2013-11-21  7:41                                 ` Viresh Kumar

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=528A4340.3020508@ti.com \
    --to=nm@ti.com \
    --cc=ceh@ti.com \
    --cc=cpufreq@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=shawn.guo@linaro.org \
    --cc=viresh.kumar@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox