Re: [PATCH v7 00/11] Add Enclustra Arria10 and Cyclone5 SoMs

[Dinh Nguyen <dinguyen@kernel.org>]

Hi Lothar,

On 10/18/25 07:11, Lothar Rubusch wrote:
> This series was already presented in November 2024.
> https://lkml.org/lkml/2024/11/16/198
> 
> Due to the ongoing complex situation with Intel's maintainership,
> the series likely did not progress further at the time. In early
> 2025, Tien Fong Chee (in CC) informed me that Altera is expected
> to resume maintainership in late 2025. I was referred to Matthew
> Gerlach (also CC'd), who, as I understand, is taking over at least
> part of the Intel/Altera-related responsibilities.
> 

I am actively monitoring and responding to patches. I will get to this
series as soon as I can. Trust me, I have a decent pile of patches to
work through. This series is on my radar.

> At this year’s OSS in Amsterdam, I had an encouraging discussion
> with Arnd Bergmann (CC’d), which motivated me to continue pursuing
> this patch series.
> 
> Hence, a slightly reworded update goes now again to the mailing lists
> and will drive the binding check bot crazy. While not all Altera
> bindings may be fully resolved yet, this series should not introduce
> any new issues.
> I’m submitting it based on prior acknowledgments and will wait a few
> weeks to see if a maintainer responds. If it remains orphaned, I’ll
> follow up with you, Arnd, as previously mentioned - this is just a
> heads-up for now.
> 
> I hope this approach is acceptable. Please let me know otherwise.
> Thank you for all the support in this so far.
> 
> Add device-tree support for the following SoMs:
> - Mercury SA1 (cyclone5)
> - Mercury+ SA2 (cyclone5)
> - Mercury+ AA1 (arria10)
> 
> Further add device-tree support for the corresponding carrier boards:
> - Mercury+ PE1
> - Mercury+ PE3
> - Mercury+ ST1
> 
> Finally, provide generic support for combinations of the above with
> one of the boot-modes
> - SD
> - eMMC
> - QSPI
> 
> All of the above elements can be freely combined, with the combinations
> specified in the provided .dts files. This renders the existing .dts file
> unnecessary. Any additional minor fixes to the dtbs_checks are applied
> separately.
> 
> This approach is also necessary for integrating with the corresponding
> bootloader using dts/upstream, which is one of the reasons for the .dtsi
> split.
> 
> Note: I used AI tools to help refine the wording of the commit messages.
> 

There were a slew of bindings check warnings from V6. I'm also working 
on fixing up the existing warnings as well.

Dinh