Date: Fri, 17 Apr 2015 15:02:24 +0200
From: Jean Delvare <jdelvare@suse.de>
To: "Ivan.khoronzhuk" <ivan.khoronzhuk@globallogic.com>
Cc: linux-kernel@vger.kernel.org, matt.fleming@intel.com,
        ard.biesheuvel@linaro.org, grant.likely@linaro.org,
        linux-api@vger.kernel.org, linux-doc@vger.kernel.org, mikew@google.com,
        dmidecode-devel@nongnu.org, leif.lindholm@linaro.org,
        msalter@redhat.com, roy.franz@linaro.org
Subject: Re: [Patch 2/3] firmware: dmi_scan: add SBMIOS entry and DMI tables
Message-ID: <20150417150224.50202bcb@endymion.delvare>
In-Reply-To: <552FF0E4.709@gmail.com>
References: <1427979423-22767-1-git-send-email-ivan.khoronzhuk@globallogic.com>
	<1427979423-22767-3-git-send-email-ivan.khoronzhuk@globallogic.com>
	<20150416115252.7dc964a3@endymion.delvare>
	<552FB18D.6080207@globallogic.com>
	<1429199064.4386.93.camel@chaos.site>
	<552FF0E4.709@gmail.com>
Organization: SUSE Linux
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2682
Lines: 61

On Thu, 16 Apr 2015 20:27:00 +0300, subscivan wrote:
> On 16.04.15 18:44, Jean Delvare wrote:
> > Le Thursday 16 April 2015 à 15:56 +0300, Ivan.khoronzhuk a écrit :
> >> We cannot be sure that firmware_kobj created at time of dmi_init().
> >> The sources don't oblige you to call it at core level,
> >> for instance like it was done for arm64. For x86, dmi_init() can be called
> >> before firmware_kobj is created.
> > Looking at the code, it seems that firmware_kobj is created very, very
> > early in the boot process. In do_basic_setup(), you can see that
> > driver_init() (which in turn calls firmware_init(), creating
> > firmware_kobj) is called before do_initcalls(). So firmware_kobj must be
> > defined before dmi_scan_machine() or dmi_init() is called.
> 
> No. Not must, rather should. See below.
> 
> > Oh, and this wasn't even my point ;-) I'm fine with you checking if
> > firmware_kobj is defined. My question was about the dmi_available check
> > above. But that question was silly anyway, sorry. I confused
> > dmi_available with dmi_initialized. Checking for dmi_available is
> > perfectly reasonable, please scratch my objection.
> >
> >> And if I call it from dmi_init() I suppose
> >> I would face an error. As I can't call it in dmi_init I can't be sure that
> >> DMI is available at all. So, no, we have to check dmi_available here and
> >> call it at subsys layer, where it's supposed to be.
> > I can't parse that, I suspect you wrote dmi_init where you actually
> > meant dmi_scan_machine? Given how early firmware_kobj is created, I
> > think the code currently in dmi_init could in fact go at the end of
> > dmi_scan_machine.
> 
> Actually, dmi_scan_machine can be called even earlier.
> As I've sad, for x86, it's called before firmware_kobj is created.
> 
> kernel_start()
>      setup_arch()
>          dmi_scan_machine()
> 
> And for firmware_init(), as you noticed already:
> 
> start_kernel()
>      rest_init()
>          kernel_init()
>              kernel_init_freeable()
>                  do_basic_setup()
>                      driver_init()
>                          firmware_init()
> 
> Pay attentions that setup_arch() is called much earlier than rest_init().
> So dmi_init couldn't in fact go at the end of dmi_scan_machine.

Yeah, you're right, sorry. Somehow I thought that setup_arch was an
arch_initcall, but it is not, so I got the order all wrong.

-- 
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/