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  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:   Thu, 9 Nov 2017 11:20:49 +0100
From:   Arnd Bergmann <>
To:     Greentime Hu <>
Cc:     Greentime <>,
        Linux Kernel Mailing List <>,
        linux-arch <>,
        Thomas Gleixner <>,
        Jason Cooper <>,
        Marc Zyngier <>,
        Rob Herring <>,
        Networking <>,
        Vincent Chen <>,
Subject: Re: [PATCH 25/31] nds32: defconfig

On Thu, Nov 9, 2017 at 9:00 AM, Greentime Hu <> wrote:
> 2017-11-08 18:03 GMT+08:00 Arnd Bergmann <>:
>> On Wed, Nov 8, 2017 at 6:55 AM, Greentime Hu <> wrote:
>>> From: Greentime Hu <>
>>> Signed-off-by: Vincent Chen <>
>>> Signed-off-by: Greentime Hu <>
>>> ---
>>>  arch/nds32/configs/ae3xx_defconfig  |  110 +++++++++++++++++++++++++++++++++++
>>>  arch/nds32/configs/ag101p_defconfig |  109 ++++++++++++++++++++++++++++++++++
>> Are those two incompatible? I would recommend starting without board
>> specific defconfig
>> files, it just gets messy once you get more than a few machines you
>> want to support.
> Thanks.
> These 2 are incompatible.
> They use different drivers. I may still keep these 2 defconfigs.

Using different drivers doesn't make machines incompatible. For instance, the
x86 desktop machine has drivers for all kinds of devices, but it uses
one configuration
that works on basically any x86 machine.

Similarly, we only have one defconfig file on arm64, and it works across very
diverse machines (phone, home routers, large servers, etc.).

All drivers should be written in a way to allow being built into the
kernel without
doing any harm when you don't have the respective hardware.

>>> +CONFIG_FB=y
>>> +# CONFIG_VGA_CONSOLE is not set
>> You have a framebuffer console here, but no framebuffer driver?
> Thanks.
> I shall enable it when I push our framebuffer in the next time.
> I will disable it in the next version patch.

The fbdev subsystem is no longer recommended for new drivers, they
should be written on top of the DRM framework. You can use
CONFIG_DRM_FBDEV_EMULATION to get the framebuffer
console on top of that, but then you don't need to enable CONFIG_FB.

Please have a look at drivers/gpu/drm/tinydrm/ to see if you can either
use that directly, or take it as a skeleton for your own driver.


Powered by blists - more mailing lists