[PATCH v5 0/8] add Voyager board support

[Arnd Bergmann]

On Wed, Jun 11, 2025, at 18:21, Conor Dooley wrote:
> On Thu, Jun 12, 2025 at 12:13:16AM +0800, Ben Zong-You Xie wrote:
>> On Mon, Jun 09, 2025 at 05:17:50PM +0100, Conor Dooley wrote:
>> > > > > 
>> > > > > Ball is in your court now, after rc1 make a tree and get it in
>> > > > > linux-next, and then send a pr to soc at kernel.org with this new content.
>> > > > > Perhaps the defconfig should go separately, I can take that one if you
>> > > > > want.
>
>> > > > Thanks for your guidance on these patches. I will send a PR to
>> > > > soc at kernel.org as you suggested.
>> > > > 
>> > > > For the defconfig patch, I'm happy for you to handle it. Just let me
>> > > > know if there's anything specific you'd like me to include.
>> > > 
>> > > Okay, I picked it up on the basis that you'll send this all to Arnd for
>> > > 6.17
>> > 
>> > Sorry, I think that was really poorly worded. I picked it up on the
>> > basis that you're going to send the other patches in the series to Arnd
>> > for 6.17.
>> 
>> According to the SoC maintainer documentation [1], I should send a
>> patchset (not a PR) to soc at kernel.org. Since I'm not a submaintainer yet.
>> I think I should not sent a PR to the main SoC maintainer. Is that right?
>
> I think you can send a PR and not worry about it.
>
>> Further, I have two questions about sending a patchset:   
>> 1. Should I send v5 or start a new patchset?
>> 2. Should I continue excluding the defconfig patch, as we discussed
>>    previously? I think it should be included now.
>
> Arnd, you okay with a defconfig in the same branch as the dts/core
> bindings for a new platform? I'll happily drop it from by branch if it
> can all go as one.

Sorry I missed your question earlier, I finally got to it now as
I am going through the pull requests in patchwork.

Having the defconfig, MAINTAINERS and Kconfig updates in the branch
for a new platform is fine, in this case it makes sense to keep
everything together.

I'm also planning to have multiple new SoC targets in 6.17 and
would put them into a separate branch that does not contain the
dts changes for the existing SoCs.

For the pull request that Ben sent, there were a couple of
mistakes, I'll reply on that separately. It probably would made
more sense to send the patches to soc at lists.linux.dev (note
that the soc at kernel.org address got renamed but they still
both work) than to send a pull request this time.

     Arnd