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  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, 18 Jan 2021 18:46:05 +0800
From:   Wei Xu <xuwei5@...ilicon.com>
To:     Arnd Bergmann <arnd@...nel.org>,
        "Leizhen (ThunderTown)" <thunder.leizhen@...wei.com>
CC:     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>, <xuwei5@...ilicon.com>
Subject: Re: [v2] Old platforms: bring out your dead

Hi Arnd,

On 2021/1/15 20:04, Arnd Bergmann wrote:
> 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.

I have aligned with Leizhen and as you suggested it is better to keep them 
for the moment.
Thanks!

Best Regards,
Wei

> 
>       Arnd
> .
> 

Powered by blists - more mailing lists