On Tue, Feb 18, 2020 at 12:14 PM Andre Przywara <[email protected]> wrote: > > On Tue, 18 Feb 2020 11:13:10 -0600 > Rob Herring <[email protected]> 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? > I don't particularly care about the more optional parts like EDAC, cpuidle, > or cpufreq, but I wonder if keeping in at least the rather small SATA and > XGMAC drivers and basic platform support is feasible. cpuidle isn't actually stable from what I remember. I think without cpufreq, we default to 1.1GHz instead of 1.4. > If YAML DT bindings are used as an excuse, I am more than happy to convert > those over. Thanks! > > And if anyone has any particular gripes with some code, maybe there is a way > to fix that instead of removing it? I was always wondering if we could get > rid of the mach-highbank directory, for instance. I think most of it is > Highbank (Cortex-A9) related. All the reset/suspend/poweroff and coherency parts are shared. The SCU and L2 parts could be removed, but not really worth the surgery IMO. Rob _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
