Re: [PATCH v8 0/9] riscv: spacemit: enable SD card support with UHS modes for OrangePi RV2

[Krzysztof Kozlowski <krzk@kernel.org>]

On 16/04/2026 10:18, Iker Pedrosa wrote:
> El mar, 14 abr 2026 a las 10:16, Troy Mitchell
> (<troy.mitchell@linux.dev>) escribió:
>>
>> On Tue Apr 14, 2026 at 3:12 PM CST, Iker Pedrosa wrote:
>>> El lun, 13 abr 2026 a las 10:07, Krzysztof Kozlowski
>>> (<krzk@kernel.org>) escribió:
>>>>
>>>> On 13/04/2026 10:02, Iker Pedrosa wrote:
>>>>> This series enables complete SD card support for the Spacemit K1-based
>>>>> OrangePi RV2 board, including UHS (Ultra High Speed) modes for
>>>>> high-performance SD card operation.
>>>>>
>>>>> Background
>>>>>
>>>>> The Spacemit K1 SoC includes an SDHCI controller capable of supporting
>>>>> SD cards up to UHS-I speeds (SDR104 at 208MHz). However, mainline
>>>>> currently lacks basic SD controller configuration, SDHCI driver
>>>>> enhancements for voltage switching and tuning, and power management
>>>>> infrastructure.
>>>>>
>>>>> Implementation
>>>>>
>>>>> The series enables SD card support through coordinated layers:
>>>>>
>>>>> - Hardware infrastructure (patches 1-2): Device tree bindings for voltage
>>>>> switching hardware and essential clock infrastructure.
>>>>> - SDHCI driver enhancements (patches 3-7): Regulator framework
>>>>> integration, pinctrl state switching for voltage domains, AIB register
>>>>> programming, and comprehensive SDR tuning support for reliable UHS
>>>>> operation.
>>>>> - SoC and board integration (patches 8-10): Complete K1 SoC controller
>>>>> definitions, PMIC power infrastructure, and OrangePi RV2 board enablement
>>>>> with full UHS support.
>>>>>
>>>>> This transforms the OrangePi RV2 from having no SD card support to full
>>>>> UHS-I capability, enabling high-performance storage up to 208MHz.
>>>>>
>>>>> Tested-by: Michael Opdenacker <michael.opdenacker@rootcommit.com>
>>>>> Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
>>>>> ---
>>>>> Changes in v8:
>>>>> - Resending the series as v8. The v7 submission failed due to an SMTP
>>>>>   error during transit, which resulted in a broken thread on the mailing
>>>>>   list.
>>>>
>>>> Hm? Everything is here:
>>>> https://lore.kernel.org/all/20260413-orangepi-sd-card-uhs-v7-1-16650f49c022@gmail.com/
>>>>
>>>> You can send individual patches to fix up threading, use --in-reply-to.
>>>
>>> My apologies for the noise and the rapid resend.
>>>
>>> The reason for v8 was that the v7 cover letter (0/9) failed to reach
>>> the mailing list due to an SMTP error on my end. This left the v7
>>> thread "headless" in the archives without the changelog or the full
>>> context of the series. I was attempting to fix the threading
>>> immediately so that reviewers would have a complete set of patches to
>>> look at, but I realize now that resending the entire series on the
>>> same day was premature.
>> So that's why Krzysztof said you should send individual patch with --in-reply-to.
> 
> I see, thanks for the clarification. Just to clarify for my future
> workflow: is it acceptable for a series to be 'headless' (starting
> with Patch 1) if the cover letter is lost, or is the cover letter
> (Patch 0) strictly required as the thread root?
> 
> In such cases, would it be better to just send the missing cover
> letter as a reply to Patch 1 afterward to complete the thread without
> resending the whole series?

Replacing missed cover letter is tricky. If you patches have in-reply-to
with ID to a missing posting, but you could do that with a bit mangling
- you would need to send the cover letter with that exactly MessageID.

If patches do not have in-reply-too, then you can send cover letter as
reply to patch #1.

Best regards,
Krzysztof