netdev - Re: [RFC PATCH 00/11] Removing Calxeda platform 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]

Message-ID: <f2b15018-2b88-01b8-14f1-a6c326b10b58@gmail.com>
Date:   Tue, 18 Feb 2020 10:51:17 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Rob Herring <robh@...nel.org>,
        Andre Przywara <andre.przywara@....com>
Cc:     Mark Langsdorf <mlangsdo@...hat.com>, kvm@...r.kernel.org,
        Viresh Kumar <viresh.kumar@...aro.org>,
        "open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers)" 
        <linux-ide@...r.kernel.org>, Will Deacon <will@...nel.org>,
        linux-clk <linux-clk@...r.kernel.org>, soc@...nel.org,
        Joerg Roedel <joro@...tes.org>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        devicetree@...r.kernel.org, Jon Loeliger <jdl@....com>,
        "open list:THERMAL" <linux-pm@...r.kernel.org>,
        Eric Auger <eric.auger@...hat.com>,
        Alex Williamson <alex.williamson@...hat.com>,
        Tony Luck <tony.luck@...el.com>,
        Alexander Graf <graf@...zon.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        linux-edac <linux-edac@...r.kernel.org>,
        Jens Axboe <axboe@...nel.dk>,
        Matthias Brugger <mbrugger@...e.com>,
        Stephen Boyd <sboyd@...nel.org>,
        netdev <netdev@...r.kernel.org>,
        Cornelia Huck <cohuck@...hat.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux IOMMU <iommu@...ts.linux-foundation.org>,
        Robert Richter <rrichter@...vell.com>,
        James Morse <james.morse@....com>,
        Borislav Petkov <bp@...en8.de>,
        Robin Murphy <robin.murphy@....com>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [RFC PATCH 00/11] Removing Calxeda platform support

On 2/18/20 10:40 AM, Rob Herring wrote:
> On Tue, Feb 18, 2020 at 12:14 PM Andre Przywara <andre.przywara@....com> wrote:
>>
>> On Tue, 18 Feb 2020 11:13:10 -0600
>> Rob Herring <robh@...nel.org> wrote:
>>
>> Hi,
>>
>>> Calxeda has been defunct for 6 years now. Use of Calxeda servers carried
>>> on for some time afterwards primarily as distro builders for 32-bit ARM.
>>> AFAIK, those systems have been retired in favor of 32-bit VMs on 64-bit
>>> hosts.
>>>
>>> The other use of Calxeda Midway I'm aware of was testing 32-bit ARM KVM
>>> support as there are few or no other systems with enough RAM and LPAE. Now
>>> 32-bit KVM host support is getting removed[1].
>>>
>>> While it's not much maintenance to support, I don't care to convert the
>>> Calxeda DT bindings to schema nor fix any resulting errors in the dts files
>>> (which already don't exactly match what's shipping in firmware).
>>
>> While every kernel maintainer seems always happy to take patches with a negative diffstat, I wonder if this is really justification enough to remove a perfectly working platform. I don't really know about any active users, but experience tells that some platforms really are used for quite a long time, even if they are somewhat obscure. N900 or Netwinder, anyone?
>>
>> So to not give the impression that actually *everyone* (from that small subset of people actively reading the kernel list) is happy with that, I think that having support for at least Midway would be useful. On the one hand it's a decent LPAE platform (with memory actually exceeding 4GB), and on the other hand it's something with capable I/O (SATA) and networking, so one can actually stress test the system. Which is the reason I was using that for KVM testing, but even with that probably going away now there remain still some use cases, and be it for general ARM(32) testing.
> 
> Does LPAE with more than 4GB actually need to work if there's not
> another platform out there?

There are ARCH_BRCMSTB platforms that are 32-bit only and have 6GB of
DRAM populated, and those continue to work just fine, though there is no
known use for KVM AFAICT.
-- 
Florian