linux-kernel - Re: [22/26] MIPS: generic: Introduce generic DT-based board support

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]

Message-ID: <5e88e3d4-3c4b-b5eb-0b32-d0c0902e14c2@roeck-us.net>
Date:   Mon, 20 Nov 2017 06:03:21 -0800
From:   Guenter Roeck <linux@...ck-us.net>
To:     James Hogan <james.hogan@...s.com>
Cc:     Paul Burton <paul.burton@...tec.com>, linux-mips@...ux-mips.org,
        Ralf Baechle <ralf@...ux-mips.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [22/26] MIPS: generic: Introduce generic DT-based board support

On 11/20/2017 02:25 AM, James Hogan wrote:
> On Sat, Nov 18, 2017 at 07:43:25PM -0800, Guenter Roeck wrote:
>> On Fri, Aug 26, 2016 at 04:37:21PM +0100, Paul Burton wrote:
>>> Introduce a "generic" platform, which aims to be board-agnostic by
>>> making use of device trees passed by the boot protocol defined in the
>>> MIPS UHI (Universal Hosting Interface) specification. Provision is made
>>> for supporting boards which use a legacy boot protocol that can't be
>>> changed, but adding support for such boards or any others is left to
>>> followon patches.
>>>
>>> Right now the built kernels expect to be loaded to 0x80100000, ie. in
>>> kseg0. This is fine for the vast majority of MIPS platforms, but
>>> nevertheless it would be good to remove this limitation in the future by
>>> mapping the kernel via the TLB such that it can be loaded anywhere & map
>>> itself appropriately.
>>>
>>> Configuration is handled by dynamically generating configs using
>>> scripts/kconfig/merge_config.sh, somewhat similar to the way powerpc
>>> makes use of it. This allows for variations upon the configuration, eg.
>>> differing architecture revisions or subsets of driver support for
>>> differing boards, to be handled without having a large number of
>>> defconfig files.
>>>
>>> Signed-off-by: Paul Burton <paul.burton@...tec.com>
>>
>> Guess it is known that this patch causes failures when building
>> "allmodconfig" on test systems such as 0day; it was reported by 0day
>> some two months ago. nevertheless, the patch found its way into mainline
>> without fix. Does anyone care, or should I simply disable "allmodconfig"
>> test builds for mips ?
> 
> Hi Guenter,
> 
> I can't find any emails from 0day in relation to this patch (I've also
> dug about on the kbuild-all archives without success). Could you link to
> or quote the build failure you're referring to.
> 
> Thanks
> James
> 

It was much older than two months, actually.

https://lkml.org/lkml/2016/12/15/33

Guenter