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: <e17afc7e-c070-6134-29cb-9fa7b855bf96@xilinx.com>
Date:   Mon, 24 Feb 2020 11:43:38 +0100
From:   Michal Simek <michal.simek@...inx.com>
To:     Jolly Shah <jolly.shah@...inx.com>, ard.biesheuvel@...aro.org,
        mingo@...nel.org, gregkh@...uxfoundation.org,
        matt@...eblueprint.co.uk, sudeep.holla@....com,
        hkallweit1@...il.com, keescook@...omium.org,
        dmitry.torokhov@...il.com, michal.simek@...inx.com
Cc:     rajanv@...inx.com, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, Tejas Patel <tejas.patel@...inx.com>
Subject: Re: [PATCH 2/2] arch: arm64: xilinx: Make zynqmp_firmware driver
 optional

On 09. 01. 20 20:06, Jolly Shah wrote:
> From: Tejas Patel <tejas.patel@...inx.com>
> 
> Zynqmp firmware driver requires firmware to be present in system.
> Zynqmp firmware driver will crash if firmware is not present in system.
> For example single arch QEMU, may not have firmware, with such setup
> Linux booting fails.


I think that moving it to firmware Kconfig is good solution. What it is
wrong is that description above where I agree with Sudeep.
It means.
1. User should have option to disable zynqmp firmware driver which is
what this patch allows. It means if someone decides to use different
firmware mechanism it can do it directly by simply y/n option.

2. Autodetection of PMUFW presence is another feature which could be
implemented to have this driver enabled but different mechanism can be
used.

3. Doing this because of missing feature in QEMU is IMHO wrong. QEMU
should be fixed and then you don't have any issue if this should be used
or not.

Just a summary. Remove that QEMU example from commit message and talk to
Edgar to fix single QEMU solution to have that regs mapped all the time.

Thanks,
Michal

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ