[PATCH 5/9] arm: configs: remove obsolete assignments to SND_SOC_ROCKCHIP

[Krzysztof Kozlowski]

On 25/03/2026 12:27, Vincent Mailhol (Arm) wrote:
> +CC: soc at lists.linux.dev

Please don't. This is not a patch review mailing list.

> 
> On 3/17/26 12:28, Krzysztof Kozlowski wrote:
>> On 17/03/2026 10:13, Vincent Mailhol (Arm) wrote:
>>> CONFIG_SND_SOC_ROCKCHIP was removed in commit cae3cc435db5 ("ASoC:
>>> rockchip: Standardize ASoC menu"). However it is still referenced in
>>> some defconfigs.
>>>
>>> Remove any references to CONFIG_SND_SOC_ROCKCHIP.
>>>
>>> FYI, the suppressions were done using:
>>>
>>>   git ls-files -z 'arch/*/configs/*defconfig' |\
>>>     xargs -0 sed -i -E '/^CONFIG_SND_SOC_ROCKCHIP/d'
>>>
>>> Fixes: cae3cc435db5 ("ASoC: rockchip: Standardize ASoC menu")
>>> Signed-off-by: Vincent Mailhol (Arm) <mailhol at kernel.org>
>>> ---
>>>  arch/arm/configs/multi_v7_defconfig | 1 -
>>>  arch/arm64/configs/defconfig        | 1 -
>>
>> This was already posted:
>> https://lore.kernel.org/all/20260313-rockchip-snd-cleanup-v1-1-77d9a953fd1b@schnwalter.eu/
>> but just like that patch you did not send it to soc@ (if I am not
>> mistaken... CC list is enormous).
> 
> OK, I will add soc at lists.linux.dev to the recipient list in v2.

Could be, but isn't this specific to given SoC? defconfigs go via SoC
platform trees (maintainer soc profile).

> 
>> I think you are mixing here independent works, like kconfig and per-arch
>> defconfig changes. Please split these per arch defconfig maintainers -
>> patches and patchset, so you won't be Cc-ing 50 addresses.
> 
> The config issues which I am addressing are transversal problems so I
> was expecting to just get the Acked-by from the other architecture and

Well, sure, IMO this only stalls the patchset but fine with me.

> have all this go through the same tree.

But which tree?


> 
> As I explained in my cover letter, this is not doing any functional changes.
> 
> But if this is not acceptable, I will just reduce the scope to arm/arm64
> then. Doing a per arch split as you suggested would be too much overhead
> (more than what I am ready to invest on this clean-up).

The first thing your cover letter should explain is the
merging/dependencies or other expectations you have. That's the most
important thing when maintainers give your patchset 15 seconds in their
mailbox. Or when you want to optimize maintainers process, making also
your patchset easier to get in.

There is a lot of text in the cover letter but nothing explaining what
you wrote here.

Best regards,
Krzysztof