linux-kernel - Re: [PATCH v8 00/11] arm64: sunxi: Initial Allwinner H616 SoC 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]

Date:   Mon, 2 Aug 2021 01:38:51 +0100
From:   Andre Przywara <andre.przywara@....com>
To:     Maxime Ripard <maxime@...no.tech>
Cc:     Chen-Yu Tsai <wens@...e.org>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Rob Herring <robh@...nel.org>, Icenowy Zheng <icenowy@...c.io>,
        Samuel Holland <samuel@...lland.org>,
        linux-arm-kernel@...ts.infradead.org, linux-sunxi@...glegroups.com,
        linux-sunxi@...ts.linux.dev, linux-kernel@...r.kernel.org,
        Ondrej Jirman <megous@...ous.com>
Subject: Re: [PATCH v8 00/11] arm64: sunxi: Initial Allwinner H616 SoC
 support

On Mon, 26 Jul 2021 16:52:30 +0200
Maxime Ripard <maxime@...no.tech> wrote:

Hi,

> On Fri, Jul 23, 2021 at 04:38:27PM +0100, Andre Przywara wrote:
> > Hi,
> > 
> > another try on the basic Allwinner H616 support, now on top of 5.14-rc1.
> > 
> > This time I dropped the USB support from the basic series, to split off
> > the discussion, and simplify the core SoC support. I will post the USB
> > series soon, to be applied on top.
> > I kept the RTC support in, even though this is still under discussion,
> > because this is important to keep future DT files compatible with this
> > kernel.  
> 
> Honestly, I don't want to support something we don't guarantee if it's
> at the expense of making something we do guarantee more complicated.

I don't ask for or provide guarantees, but I think we can at least *try*
to keep this compatible. This version works at the moment, and should
also work with future DTs - within the limits of the current driver, so
only using the RC clock. It allows to later improve the accuracy by
adding better input clocks - and later DT/driver combinations can make
use of this.

> Delaying the clock tree description to sometime in the future will only
> further complicate the probe part of the driver, and there's far too
> many special cases already.

I don't see how this would complicate probing beyond what Allwinner
brought upon us already anyway: no LOSC crystal input in this package
version, but having this pin in some other SoC sharing this die
(according to some BSP) sources. We can't expect a super clean driver
with those HW design choices.

If we really cannot keep the DT compatible, fair enough: that's what
it is (there is no guarantee!), but at least we have tried.

Cheers,
Andre