From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0E78ECA9EC0 for ; Mon, 28 Oct 2019 14:24:06 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0D76B20659 for ; Mon, 28 Oct 2019 14:24:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="KIjVN3Pp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0D76B20659 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 816F11F43; Mon, 28 Oct 2019 15:23:12 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 816F11F43 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1572272642; bh=tkFHz/b8etdQHPKI1g3JIMeP1QHtkHiOIEsg2p6AzDQ=; h=Date:From:To:In-Reply-To:References:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=KIjVN3Pp72AWRjPhRLCBI5naRiuRxQq6GHEWXgR2sjrRp6i+0hFRCetEzO/UCBSOq QIlIk14v2f3QIiuY5jsLvsFjO55LbMVYEV4MnykEPf3SDPUHt4ht/6NYl7xLAWA8K+ 49DA0vU8d/m/D7oBtwUIbL5vJZWGF63Ybp5MobFo= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 1518EF802BD; Mon, 28 Oct 2019 15:23:12 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 53CA4F80361; Mon, 28 Oct 2019 15:23:11 +0100 (CET) Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 02B74F800E7 for ; Mon, 28 Oct 2019 15:23:08 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 02B74F800E7 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id AB60EB57C; Mon, 28 Oct 2019 14:23:07 +0000 (UTC) Date: Mon, 28 Oct 2019 15:23:07 +0100 Message-ID: From: Takashi Iwai To: Jaroslav Kysela In-Reply-To: <149b2b82-f204-00ac-b3e4-6a1dd7de07ee@perex.cz> References: <20191025123038.19728-1-perex@perex.cz> <9403a6a7-9b7e-c2a4-5acf-50d6cbaea7c7@perex.cz> <83e4dc16-07e7-aafb-db43-01a89e31270b@perex.cz> <12c5e861-dd78-99cc-b16f-5ddc2ad0e33b@perex.cz> <149b2b82-f204-00ac-b3e4-6a1dd7de07ee@perex.cz> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Cc: ALSA development , Mark Brown , Pierre-Louis Bossart , Kai Vehmanen Subject: Re: [alsa-devel] [PATCH] ASoC: change 'HDMI/DP, pcm=' to 'HDMI/DP, pcm=' Jack control names X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Sat, 26 Oct 2019 19:11:27 +0200, Jaroslav Kysela wrote: > > Dne 26. 10. 19 v 9:37 Takashi Iwai napsal(a): > > On Fri, 25 Oct 2019 23:03:26 +0200, > > Jaroslav Kysela wrote: > >> > >> Dne 25. 10. 19 v 20:02 Kai Vehmanen napsal(a): > >>> Hi Jaroslav and all, > >>> > >>> On Fri, 25 Oct 2019, Jaroslav Kysela wrote: > >>> > >>>> the single user. Another problem is that we are not able to review all those > >>>> mistakes at the merge time. It is not a complain but a true fact. > >>> > >>> but the strings are in kernel patches, so even if all UCM files don't > >>> go through the list, we can always review when the strings are added > >>> in kernel, right? > >> > >> My point is that we already did this incomplete review (the wrong > >> strings are in the current kernel). We cannot prevent to avoid those > >> code merges, we are just human. I just don't think that the driver / > >> control names should be part of the don't-break-the-userspace policy. > > > > It's a similar situation like the long-time discussion of tracing: > > when the kernel broke latencytop by changing the tracing format, we > > had to revert it in the end although the tracing format itself isn't > > strictly a "standard kernel ABI". The consensus is: if upgrading the > > kernel breaks anything *significant*, it's a regression and no-go. > > It's not about whether it's a part of ABI or not. > > > > In our particular case, the strings you wanted to fix are the ones > > that are actually hard-coded by the UCM profiles that are known to be > > really used on major systems. That's the only reason of NAK. If it > > were for some other minor kcontrol elements, it would have been OK. > > > > Kai's work to integrate SOF to the legacy HDMI driver would be also OK > > because it provides the compatibility mode. That is, we have some > > excuse that it's not us but users (distros) who actually breaks by > > choosing the kernel configuration explicitly (and even there can be a > > workaround with a module option). > > We can add another kernel option for this fix, too. If you like to move > in this direction, I'll modify my patch. I don't think it's worth for that. With Kai's patch set, we're going to move (back) to the legacy HDMI codec driver in most cases, so these strings will be specifically to the SST driver -- which are used by only limited number of devices like Chromebook or such. That said, if the reason for the change is just about consistency, the best recipe is to forget it. > The question is, if the kernel should provide a hint to the user space > (UCM), that something *significant* changed. Perhaps, the component > field in the control API might be used for this purpose as I already > proposed. In this way, we can support both kernels (with old and new > control names). I'm afraid that the current UCM profile cannot handle any extension as of now. We may need to introduce some incompatible extensibility at first to UCM profile syntax. This can be a good topic for the next meeting. thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel