From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Subject: Re: [PATCH AUTOSEL 5.7 004/388] ASoC: tegra: tegra_wm8903: Support nvidia, headset property Date: Mon, 22 Jun 2020 18:57:27 +0100 Message-ID: <20200622175727.GP4560@sirena.org.uk> References: <20200618010805.600873-1-sashal@kernel.org> <20200618010805.600873-4-sashal@kernel.org> <20200618110023.GB5789@sirena.org.uk> <20200618143046.GT1931@sasha-vm> <20200618143930.GI5789@sirena.org.uk> <20200621233352.GA1931@sasha-vm> <20200622112321.GB4560@sirena.org.uk> <20200622123118.GF1931@sasha-vm> <20200622132757.GG4560@sirena.org.uk> <20200622144402.GH1931@sasha-vm> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WOTjKnJ88wpJKlWH" Return-path: Content-Disposition: inline In-Reply-To: <20200622144402.GH1931@sasha-vm> Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Sasha Levin Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Dmitry Osipenko , alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org, linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-tegra@vger.kernel.org --WOTjKnJ88wpJKlWH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jun 22, 2020 at 10:44:02AM -0400, Sasha Levin wrote: > On Mon, Jun 22, 2020 at 02:27:57PM +0100, Mark Brown wrote: > > On Mon, Jun 22, 2020 at 08:31:18AM -0400, Sasha Levin wrote: > > > How come? This is one of the things stable rules explicitly call for: > > > "New device IDs and quirks are also accepted". > > I would expect that to be data only additions, I would not expect that > > to be adding new code. > These come hand in hand. Take a look at the more complex cases such as > sound/pci/hda/patch_* There are more complex cases, I'm just not sure how good an idea backporting them. > > It would be much better to not have to watch stable constantly like we > > currently do - we're seeing people report breakage often enough to be a > > concern as things are, we don't need to be trying to pile extra stuff in > > there because there's some keywords in a changelog or whatever. The > > testing coverage for drivers is weak, increasing the change rate puts > > more stress on that. > Shouldn't we instead improve testing here? nvidia for example already > provides Tegra testing for stable releases, if the coverage isn't > sufficient then let's work on making it better. Obviously it'd be good to improve the test coverage, but I think that's something that needs doing before backporting loads of stuff rather than after. For this automated stuff I'd much rather see positive confirmation that the change had been tested on relevant systems (not just something with a similar SoC), especially on the edges where we're getting to board specific things. --WOTjKnJ88wpJKlWH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl7w8QYACgkQJNaLcl1U h9DC6wf/TsaPFLd+NPMuG4vVND70Z7iQQxL5/z/PyV7fUPbBpUUTkNGsq2Zuue1U aWOE4ExbeVUHmEoMtMCfYzkuigz2/cIm2zXvQC82I8EoUMLj2aG4vBhXhxNVv3Fi l4aBCgJTHyK3+mbu1lvaGykxUFLe3tjWj1I45GNV6mVX2jwNeyNRtwIgYtvvFw2J S9RzsRjKgm8GW9/JzJsY18MwkcxalIZIpsmzBkuQw/79/XjtbzC0aI3fbt2KCkha Cfu8PWJdRx276cbDQbGrCMJUZP36TA3Bve09TUx6OdB2nvxiODjAp0xn7VstW/xn m52d3uSB3K57NZFW0BuFGabvwFrHmw== =8po3 -----END PGP SIGNATURE----- --WOTjKnJ88wpJKlWH-- 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=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 01FEFC433E0 for ; Mon, 22 Jun 2020 17:57:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D53D020738 for ; Mon, 22 Jun 2020 17:57:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592848651; bh=Lt1P6AdsHmbhP2XV63ccQ6jG8uBCvmShpdyEWEYmjI8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=cmhDrg27PGd+mmZ3fAPvbbptdLAVyJay6hK8JofELOlr1DdZQCR7mXDEmIsRIr9Rd eBwoAkgVvpubLn39uko0hG+nRKghMde9YBKNNlJAypvx7+ODYFelp1KOCVGHQOOPQg E8uD8oHvuzhM91/E0vgUZ/sb6m3hoObC6wYNsHnM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730253AbgFVR5a (ORCPT ); Mon, 22 Jun 2020 13:57:30 -0400 Received: from mail.kernel.org ([198.145.29.99]:55752 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730241AbgFVR5a (ORCPT ); Mon, 22 Jun 2020 13:57:30 -0400 Received: from localhost (fw-tnat.cambridge.arm.com [217.140.96.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id F0D7D2075A; Mon, 22 Jun 2020 17:57:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592848649; bh=Lt1P6AdsHmbhP2XV63ccQ6jG8uBCvmShpdyEWEYmjI8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=wYyb/N05uI8WHgJV1KE7C0JnHCvn8PQh/8jSeAnsF3wIXS0NFdG+HIvSMbEQntwyc m0VTgK20TYgLFCjQGJvgv1fwj38lNGON955q7nVUEKiyWYTE/VT/FjL2ToS69m/h0v KhEzV90KgXeSAL2ZgjrVRwu5NVwWO4/x27gjwhV0= Date: Mon, 22 Jun 2020 18:57:27 +0100 From: Mark Brown To: Sasha Levin Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, Dmitry Osipenko , alsa-devel@alsa-project.org, linux-tegra@vger.kernel.org Subject: Re: [PATCH AUTOSEL 5.7 004/388] ASoC: tegra: tegra_wm8903: Support nvidia, headset property Message-ID: <20200622175727.GP4560@sirena.org.uk> References: <20200618010805.600873-1-sashal@kernel.org> <20200618010805.600873-4-sashal@kernel.org> <20200618110023.GB5789@sirena.org.uk> <20200618143046.GT1931@sasha-vm> <20200618143930.GI5789@sirena.org.uk> <20200621233352.GA1931@sasha-vm> <20200622112321.GB4560@sirena.org.uk> <20200622123118.GF1931@sasha-vm> <20200622132757.GG4560@sirena.org.uk> <20200622144402.GH1931@sasha-vm> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WOTjKnJ88wpJKlWH" Content-Disposition: inline In-Reply-To: <20200622144402.GH1931@sasha-vm> X-Cookie: laser, n.: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --WOTjKnJ88wpJKlWH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jun 22, 2020 at 10:44:02AM -0400, Sasha Levin wrote: > On Mon, Jun 22, 2020 at 02:27:57PM +0100, Mark Brown wrote: > > On Mon, Jun 22, 2020 at 08:31:18AM -0400, Sasha Levin wrote: > > > How come? This is one of the things stable rules explicitly call for: > > > "New device IDs and quirks are also accepted". > > I would expect that to be data only additions, I would not expect that > > to be adding new code. > These come hand in hand. Take a look at the more complex cases such as > sound/pci/hda/patch_* There are more complex cases, I'm just not sure how good an idea backporting them. > > It would be much better to not have to watch stable constantly like we > > currently do - we're seeing people report breakage often enough to be a > > concern as things are, we don't need to be trying to pile extra stuff in > > there because there's some keywords in a changelog or whatever. The > > testing coverage for drivers is weak, increasing the change rate puts > > more stress on that. > Shouldn't we instead improve testing here? nvidia for example already > provides Tegra testing for stable releases, if the coverage isn't > sufficient then let's work on making it better. Obviously it'd be good to improve the test coverage, but I think that's something that needs doing before backporting loads of stuff rather than after. For this automated stuff I'd much rather see positive confirmation that the change had been tested on relevant systems (not just something with a similar SoC), especially on the edges where we're getting to board specific things. --WOTjKnJ88wpJKlWH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl7w8QYACgkQJNaLcl1U h9DC6wf/TsaPFLd+NPMuG4vVND70Z7iQQxL5/z/PyV7fUPbBpUUTkNGsq2Zuue1U aWOE4ExbeVUHmEoMtMCfYzkuigz2/cIm2zXvQC82I8EoUMLj2aG4vBhXhxNVv3Fi l4aBCgJTHyK3+mbu1lvaGykxUFLe3tjWj1I45GNV6mVX2jwNeyNRtwIgYtvvFw2J S9RzsRjKgm8GW9/JzJsY18MwkcxalIZIpsmzBkuQw/79/XjtbzC0aI3fbt2KCkha Cfu8PWJdRx276cbDQbGrCMJUZP36TA3Bve09TUx6OdB2nvxiODjAp0xn7VstW/xn m52d3uSB3K57NZFW0BuFGabvwFrHmw== =8po3 -----END PGP SIGNATURE----- --WOTjKnJ88wpJKlWH-- 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=-2.5 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 39749C433DF for ; Mon, 22 Jun 2020 17:58:29 +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 BCFA720738 for ; Mon, 22 Jun 2020 17:58:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="LdZqWNac"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="wYyb/N05" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BCFA720738 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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 4F8CF16F7; Mon, 22 Jun 2020 19:57:37 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 4F8CF16F7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1592848707; bh=Lt1P6AdsHmbhP2XV63ccQ6jG8uBCvmShpdyEWEYmjI8=; h=Date:From:To:Subject:References:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=LdZqWNacysnmP2wUs99b6pFUdmDjADjUVRD4wDNAvtNfUfQ9qg7dlh4dwwXtijSKH qks3TW1hSpT19RaKr2kxr5CAGEWfcYlZHREdIimhmIUiY3O1gxVvX78La3Gof48P1B 4Refg0Fmg66HM5oEg5RShnA3s2o6KJ+nWUGt3quY= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id E1EADF8015A; Mon, 22 Jun 2020 19:57:36 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id B15A1F8015B; Mon, 22 Jun 2020 19:57:35 +0200 (CEST) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id F267FF8010D for ; Mon, 22 Jun 2020 19:57:31 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz F267FF8010D Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="wYyb/N05" Received: from localhost (fw-tnat.cambridge.arm.com [217.140.96.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id F0D7D2075A; Mon, 22 Jun 2020 17:57:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592848649; bh=Lt1P6AdsHmbhP2XV63ccQ6jG8uBCvmShpdyEWEYmjI8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=wYyb/N05uI8WHgJV1KE7C0JnHCvn8PQh/8jSeAnsF3wIXS0NFdG+HIvSMbEQntwyc m0VTgK20TYgLFCjQGJvgv1fwj38lNGON955q7nVUEKiyWYTE/VT/FjL2ToS69m/h0v KhEzV90KgXeSAL2ZgjrVRwu5NVwWO4/x27gjwhV0= Date: Mon, 22 Jun 2020 18:57:27 +0100 From: Mark Brown To: Sasha Levin Subject: Re: [PATCH AUTOSEL 5.7 004/388] ASoC: tegra: tegra_wm8903: Support nvidia, headset property Message-ID: <20200622175727.GP4560@sirena.org.uk> References: <20200618010805.600873-1-sashal@kernel.org> <20200618010805.600873-4-sashal@kernel.org> <20200618110023.GB5789@sirena.org.uk> <20200618143046.GT1931@sasha-vm> <20200618143930.GI5789@sirena.org.uk> <20200621233352.GA1931@sasha-vm> <20200622112321.GB4560@sirena.org.uk> <20200622123118.GF1931@sasha-vm> <20200622132757.GG4560@sirena.org.uk> <20200622144402.GH1931@sasha-vm> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WOTjKnJ88wpJKlWH" Content-Disposition: inline In-Reply-To: <20200622144402.GH1931@sasha-vm> X-Cookie: laser, n.: User-Agent: Mutt/1.10.1 (2018-07-13) Cc: linux-tegra@vger.kernel.org, Dmitry Osipenko , alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org 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: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" --WOTjKnJ88wpJKlWH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jun 22, 2020 at 10:44:02AM -0400, Sasha Levin wrote: > On Mon, Jun 22, 2020 at 02:27:57PM +0100, Mark Brown wrote: > > On Mon, Jun 22, 2020 at 08:31:18AM -0400, Sasha Levin wrote: > > > How come? This is one of the things stable rules explicitly call for: > > > "New device IDs and quirks are also accepted". > > I would expect that to be data only additions, I would not expect that > > to be adding new code. > These come hand in hand. Take a look at the more complex cases such as > sound/pci/hda/patch_* There are more complex cases, I'm just not sure how good an idea backporting them. > > It would be much better to not have to watch stable constantly like we > > currently do - we're seeing people report breakage often enough to be a > > concern as things are, we don't need to be trying to pile extra stuff in > > there because there's some keywords in a changelog or whatever. The > > testing coverage for drivers is weak, increasing the change rate puts > > more stress on that. > Shouldn't we instead improve testing here? nvidia for example already > provides Tegra testing for stable releases, if the coverage isn't > sufficient then let's work on making it better. Obviously it'd be good to improve the test coverage, but I think that's something that needs doing before backporting loads of stuff rather than after. For this automated stuff I'd much rather see positive confirmation that the change had been tested on relevant systems (not just something with a similar SoC), especially on the edges where we're getting to board specific things. --WOTjKnJ88wpJKlWH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl7w8QYACgkQJNaLcl1U h9DC6wf/TsaPFLd+NPMuG4vVND70Z7iQQxL5/z/PyV7fUPbBpUUTkNGsq2Zuue1U aWOE4ExbeVUHmEoMtMCfYzkuigz2/cIm2zXvQC82I8EoUMLj2aG4vBhXhxNVv3Fi l4aBCgJTHyK3+mbu1lvaGykxUFLe3tjWj1I45GNV6mVX2jwNeyNRtwIgYtvvFw2J S9RzsRjKgm8GW9/JzJsY18MwkcxalIZIpsmzBkuQw/79/XjtbzC0aI3fbt2KCkha Cfu8PWJdRx276cbDQbGrCMJUZP36TA3Bve09TUx6OdB2nvxiODjAp0xn7VstW/xn m52d3uSB3K57NZFW0BuFGabvwFrHmw== =8po3 -----END PGP SIGNATURE----- --WOTjKnJ88wpJKlWH--