linux-kernel - Re: [v2] Old platforms: bring out your dead

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:   Fri, 15 Jan 2021 13:04:51 +0100
From:   Arnd Bergmann <arnd@...nel.org>
To:     "Leizhen (ThunderTown)" <thunder.leizhen@...wei.com>
Cc:     Wei Xu <xuwei5@...ilicon.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Krzysztof Adamski <krzysztof.adamski@...ia.com>,
        Oleksij Rempel <o.rempel@...gutronix.de>,
        Baruch Siach <baruch@...s.co.il>,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        Daniel Tang <dt.tangr@...il.com>,
        Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>, Jamie Iles <jamie@...ieiles.com>,
        Barry Song <song.bao.hua@...ilicon.com>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Jonas Jensen <jonas.jensen@...il.com>,
        Marc Gonzalez <marc.w.gonzalez@...e.fr>,
        Hartley Sweeten <hsweeten@...ionengravers.com>,
        Lubomir Rintel <lkundrak@...sk>,
        Neil Armstrong <narmstrong@...libre.com>,
        Shawn Guo <shawnguo@...nel.org>, Alex Elder <elder@...aro.org>,
        Alexander Shiyan <shc_work@...l.ru>,
        Koen Vandeputte <koen.vandeputte@...ntric.com>,
        Hans Ulli Kroll <ulli.kroll@...glemail.com>,
        Vladimir Zapolskiy <vz@...ia.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        Mark Salter <msalter@...hat.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Tony Prisk <linux@...sktech.co.nz>,
        Krzysztof Halasa <khalasa@...p.pl>
Subject: Re: [v2] Old platforms: bring out your dead

On Fri, Jan 15, 2021 at 12:09 PM Leizhen (ThunderTown)
<thunder.leizhen@...wei.com> wrote:
> On 2021/1/15 17:26, Arnd Bergmann wrote:
> > On Fri, Jan 15, 2021 at 8:08 AM Wei Xu <xuwei5@...ilicon.com> wrote:
> >> On 2021/1/14 0:14, Arnd Bergmann wrote:
> >>> On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <arnd@...nel.org> wrote:
> >>> * mmp -- added in 2009, DT support is active, but board files might go
> >>> * cns3xxx -- added in 2010, last fixed in 2019, probably no users left
> >>> * hisi (hip01/hip05) -- servers added in 2013, replaced with arm64 in 2016
> >>
> >> I think it is OK to drop the support of the hip01(arm32) and hip05(arm64).
> >> Could you also help to drop the support of the hip04(arm32) which I think nobody use as well?
> >
> > Thank you for your reply! I actually meant to write hip04 instead of hip05,
> > so I was only asking about the two 32-bit targets. I would expect that
> > hip05 still has a few users, but wouldn't mind removing that as well if you
> > are sure there are none.
> >
> > Since Zhen Lei is starting to upstream Kunpeng506 and Kunpeng509
> > support, can you clarify how much reuse of IP blocks there is between
> > hip04 and those? In particular, hip04 has custom code for (at least)
> > platmcpm, clk, irqchip, ethernet, and hw_rng, probably more as those
> > were only the ones I see on a quick grep.
> >
> > If we remove hip04, should we remove all these drivers right away,
> > or keep some of them around?
>
> I think the drivers should be kept.

Ok, will do.

> Currently, at least hip04_eth.c and irq-hip04.c are used. These drivers
> were originally written for Hip04, but the drivers used by other boards
> maybe similar to them. Therefore, these drivers are extended without
> adding new drivers.

Right, so the other chips just use compatible="hisilicon,hip04-intc"
etc. in their device trees? Is there a public copy of the dts files
somewhere that I can use for cross-referencing? Sorry if I'm
messing up the timeline for your upstreaming plans.

It might actually be easier to leave hip01 and hip04 in the
tree for the moment until you have upstreamed the other SoC
support, and then we clean up by removing the unused bits
afterwards. I'll leave it to you both to tell me which way is easier
for you.

      Arnd