Message-ID: <CAFXKEHYUKSFVyyZS7v2tUeAuBkS8+_p9qCXOzfvMsUQGNHf2Aw@mail.gmail.com>
Date: Tue, 21 Oct 2025 14:40:35 +0200
From: Lothar Rubusch <l.rubusch@...il.com>
To: Dinh Nguyen <dinguyen@...nel.org>
Cc: robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org, 
	martin.petersen@...cle.com, pabeni@...hat.com, rostedt@...dmis.org, 
	bhelgaas@...gle.com, arnd@...db.de, matthew.gerlach@...era.com, 
	tien.fong.chee@...era.com, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 00/11] Add Enclustra Arria10 and Cyclone5 SoMs

Hi Dinh!

On Mon, Oct 20, 2025 at 6:11 PM Dinh Nguyen <dinguyen@...nel.org> wrote:
>
> 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.
>

What a great news that you're carrying on with Altera. I really
appreciate, that you came
back and answered to this request here. Pls, take your time, no stress
for this series.

> > 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.
>

Yes, that's what I saw, too. Since there were still bindings in TXT
form and no real way of accepting changes, it felt like a deadlock.
I became aware how difficult the situation for Intel & CO maintenance
seemed to have been during
past months. So, my actually old cyclone5 patches were really not top prio ;o)

Anyway, is there anything I can help you with converting bindings?
Anything to have a look into?
I'm aware that also getting into would probably request more time than
to help out, but if there is
anything I might be helpful, just let me know. I might give it a try.

Best,
L

Powered by blists - more mailing lists