Re: arm64: dts: blaize-blzp1600: Enable GPIO support

Re: arm64: dts: blaize-blzp1600: Enable GPIO support

[Krzysztof Kozlowski]

On 05/05/2025 16:14, Nikolaos Pasaloukos wrote:
> Blaize BLZP1600 uses the custom silicon provided from
> 
> VeriSilicon to add GPIO support.
> 
> This interface is used to control signals on many other
> 
> peripherals, such as Ethernet, USB, SD and eMMC.
> 
> 
> Signed-off-by: Nikolaos Pasaloukos <nikolaos.pasaloukos@blaize.com>

Entire patch is corrupted by your mail server. Please switch to b4 relay
if your mail server is not capable of sending emails (like Microsoft
Outlook).

Please use standard email subjects, so with the PATCH keyword in the
title. `git format-patch -vX` helps here to create proper versioned
patches. Another useful tool is b4. Skipping the PATCH keyword makes
filtering of emails more difficult thus making the review process less
convenient.

> 
> ---
> 
> I am re-sending the patch to include the soc list. The original patchset
> 
> has already been applied but not this patch.
> 
> Arnd, could you please apply or do I need someone to review?

Platform maintainers are responsible for the patches for their platform.
Any reason why this is not working for blaize?

Best regards,
Krzysztof

Re: arm64: dts: blaize-blzp1600: Enable GPIO support

[Nikolaos Pasaloukos]

On 05/05/2025 15:17, Krzysztof Kozlowski wrote:

> On 05/05/2025 16:14, Nikolaos Pasaloukos wrote:
>> Blaize BLZP1600 uses the custom silicon provided from
>>
>> VeriSilicon to add GPIO support.
>>
>> This interface is used to control signals on many other
>>
>> peripherals, such as Ethernet, USB, SD and eMMC.
>>
>>
>> Signed-off-by: Nikolaos Pasaloukos <nikolaos.pasaloukos@blaize.com>
> Entire patch is corrupted by your mail server. Please switch to b4 relay
> if your mail server is not capable of sending emails (like Microsoft
> Outlook).
>
> Please use standard email subjects, so with the PATCH keyword in the
> title. `git format-patch -vX` helps here to create proper versioned
> patches. Another useful tool is b4. Skipping the PATCH keyword makes
> filtering of emails more difficult thus making the review process less
> convenient.

I was expecting b4 to be able to send a single patch without a cover
letter but I couldn't find how to do it, so I decided to send the .eml
file produced by b4 with git send-email which obviously didn't work.
Apologies for that.

>
>> ---
>>
>> I am re-sending the patch to include the soc list. The original patchset
>>
>> has already been applied but not this patch.
>>
>> Arnd, could you please apply or do I need someone to review?
> Platform maintainers are responsible for the patches for their platform.
> Any reason why this is not working for blaize?
>
> Best regards,
> Krzysztof

I am the platform maintainer for blaize but I haven't created an account
yet on the kernel.org and according to Arnd it should be OK to submit the
patches for inclusion (until I get an account) by sending them to the
soc@lists.linux.dev.

So, what would be preferable? To send only this patch with b4 or resend
the v2 patchset which have been accepted and add the soc list?

Kind regards,
Nikolaos Pasaloukos

Re: arm64: dts: blaize-blzp1600: Enable GPIO support

[Krzysztof Kozlowski]

On 05/05/2025 16:43, Nikolaos Pasaloukos wrote:
>>
>>> ---
>>>
>>> I am re-sending the patch to include the soc list. The original patchset
>>>
>>> has already been applied but not this patch.
>>>
>>> Arnd, could you please apply or do I need someone to review?
>> Platform maintainers are responsible for the patches for their platform.
>> Any reason why this is not working for blaize?
>>
>> Best regards,
>> Krzysztof
> 
> I am the platform maintainer for blaize but I haven't created an account
> yet on the kernel.org and according to Arnd it should be OK to submit the
> patches for inclusion (until I get an account) by sending them to the
> soc@lists.linux.dev.
> 
> So, what would be preferable? To send only this patch with b4 or resend
> the v2 patchset which have been accepted and add the soc list?
soc@ is for applying patches, but your Cc list here suggest you send
something for review. These are two different processes, see soc
maintainer profile.

You need to handle the patches (collect them) after community review
*and then* you send these to soc@, without ccing again entire community.
See any other pull requests or patch-pull emails.

Best regards,
Krzysztof