linux-kernel - Re: [PATCH 0/8] Generic serial earlycon

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]

Date:	Sat, 22 Mar 2014 23:01:30 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Rob Herring <robherring2@...il.com>
Cc:	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-serial@...r.kernel.org,
	"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
	Jiri Slaby <jslaby@...e.cz>,
	Catalin Marinas <catalin.marinas@....com>,
	Russell King <linux@....linux.org.uk>,
	Will Deacon <will.deacon@....com>,
	"x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH 0/8] Generic serial earlycon

On Saturday 22 March 2014, Rob Herring wrote:
> I think this series stands on its own. It is largely refactoring
> existing code and supporting existing command line options (arm64 just
> changes from earlyprintk= to earlycon=). There will be cases where
> changing the kernel command line is the only way to setup the
> earlycon. Also, I think we would still want the kernel command line to
> control whether or not we enable the earlycon (i.e. earlycon=dt).
> There's not a standard way for how bootloaders would decide to set
> "linux,stdout-path" or not.
> 
> The DT support won't be all that quick to implement. The challenge
> with the DT parsing is we have to do it on the flattened DT. I have
> something functioning, but it doesn't do any address translation which
> is the hard part.

Ah, I hadn't realized that we call parse_early_param() twice, both
in start_kernel() and before that in setup_arch(). You are right
that the first one of these can only look at the flat device tree
at the moment. I wonder if that's out of necessity or just coincidence
though.

There is relatively little going on between the first parse_early_param()
and the call to unflatten_device_tree(), so it may be possible to move
the former down, or the latter up.

        parse_early_param();

        sort(&meminfo.bank, meminfo.nr_banks, sizeof(meminfo.bank[0]), meminfo_cmp, NULL);

        early_paging_init(mdesc, lookup_processor_type(read_cpuid_id()));
        setup_dma_zone(mdesc);  
        sanity_check_meminfo();
        arm_memblock_init(&meminfo, mdesc);
                                
        paging_init(mdesc);
        request_standard_resources(mdesc);
                
        if (mdesc->restart)
                arm_pm_restart = mdesc->restart;
        
        unflatten_device_tree();

On powerpc, unflatten_device_tree is called way before paging_init, so I assume
it has to be possible, but it might end up being harder to do than what you
have in mind with parsing the flat device tree.

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