Rockchip I2S commit possibly ignored

Mark Brown broonie at kernel.org
Tue Aug 16 20:23:20 CEST 2022


On Tue, Aug 16, 2022 at 02:54:22PM -0300, Geraldo Nascimento wrote:
> On Tue, Aug 16, 2022 at 04:22:37PM +0100, Mark Brown wrote:

> > There's absolutely no problem with reposting someone else's patch - just
> > add your Signed-off-by at the end of the signoff chain.

> Mark, I'm in no position to lecture anyone, least of who, you, hard-working
> ASoC maintainer that you are. But there are *tons* of problems with
> reposting someone else's patch, even if they had been previously given
> the green-light but misteriously vanished.

> You are assuming responsibility for someone else's work! Let's see in

Oh, sure - but TBH if you're chasing a patch via e-mail you're pretty
much going to be in a similar situation if that results in the patch
getting applied.  A big part of the goal behind getting things reposted
is to push them through the normal test/review cycle properly so if
there was some reason for it to not get applied the first time around
it's more likely that someone will notice than if it's just pulled out
of list archives or whatever.

> My main point is that without adding "resets" and "reset-names" to *at
> least* every Rockchip device tree that enables sound over HDMI, just an
> example, you get systems with non-working HDMI. I just tested it, I
> omitted "resets" and "reset-names" from my device tree and then had
> to SSH into the black screen to revert the changes to my boot partition.

> So it's not trivial to RESEND this. It amounts to device tree overhaul
> of arch/arm64/boot/dts/rockchip

> This would require community effort of say, equivalent to LibreELEC
> resources, which are not many, but they have enough patience to test
> every proposed change to Rockchip device trees, and could help upstream
> this.

Right, that's a problem.  Even with those changes if we start requiring
new properties that'd be an ABI break anyway which isn't something we
want for DT - ideally the patch should be reworked so that existing
systems continue to work even without DT updates.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20220816/9f41ca81/attachment.sig>


More information about the Alsa-devel mailing list