The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: "Uwe Kleine-König (The Capable Hub)" <u.kleine-koenig@baylibre.com>
To: Cezary Rojewski <cezary.rojewski@intel.com>
Cc: "Jaroslav Kysela" <perex@perex.cz>,
	"Takashi Iwai" <tiwai@suse.com>,
	"Lars-Peter Clausen" <lars@metafoo.de>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Srinivas Kandagatla" <srini@kernel.org>,
	"Shengjiu Wang" <shengjiu.wang@gmail.com>,
	"Xiubo Li" <Xiubo.Lee@gmail.com>,
	"Fabio Estevam" <festevam@gmail.com>,
	"Nicolin Chen" <nicoleotsuka@gmail.com>,
	"Frank Li" <Frank.Li@nxp.com>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"Pengutronix Kernel Team" <kernel@pengutronix.de>,
	"Peter Ujfalusi" <peter.ujfalusi@linux.intel.com>,
	"Bard Liao" <yung-chuan.liao@linux.intel.com>,
	"Kai Vehmanen" <kai.vehmanen@linux.intel.com>,
	"Pierre-Louis Bossart" <pierre-louis.bossart@linux.dev>,
	"Sylwester Nawrocki" <s.nawrocki@samsung.com>,
	"Charles Keepax" <ckeepax@opensource.cirrus.com>,
	"Kuninori Morimoto" <kuninori.morimoto.gx@renesas.com>,
	"Amadeusz Sławiński" <amadeuszx.slawinski@linux.intel.com>,
	linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	"Liam Girdwood" <lgirdwood@gmail.com>,
	"Mark Brown" <broonie@kernel.org>
Subject: Re: [PATCH v2 6/6] ASOC: Unify code style for platform_device_id arrays
Date: Thu, 23 Jul 2026 07:30:21 +0200	[thread overview]
Message-ID: <amGhHDDlwMdool_q@monoceros> (raw)
In-Reply-To: <0f625961-8e2d-4ed9-ab5a-fd95bcb4c87a@intel.com>

[-- Attachment #1: Type: text/plain, Size: 2944 bytes --]

Hello Cezary,

On Wed, Jul 22, 2026 at 07:55:26PM +0200, Cezary Rojewski wrote:
> On 7/20/2026 8:23 AM, Uwe Kleine-König (The Capable Hub) wrote:
> 
> >   sound/soc/au1x/db1200.c                |  2 +-
> >   sound/soc/codecs/adau7118-hw.c         |  2 +-
> >   sound/soc/codecs/bt-sco.c              | 10 +++-------
> >   sound/soc/codecs/wcd934x.c             |  6 ++----
> >   sound/soc/fsl/imx-pcm-rpmsg.c          |  6 +++---
> >   sound/soc/intel/avs/boards/da7219.c    |  6 ++----
> >   sound/soc/intel/avs/boards/dmic.c      |  6 ++----
> >   sound/soc/intel/avs/boards/es8336.c    |  6 ++----
> >   sound/soc/intel/avs/boards/hdaudio.c   |  6 ++----
> >   sound/soc/intel/avs/boards/i2s_test.c  |  6 ++----
> >   sound/soc/intel/avs/boards/max98357a.c |  6 ++----
> >   sound/soc/intel/avs/boards/max98373.c  |  6 ++----
> >   sound/soc/intel/avs/boards/max98927.c  |  6 ++----
> >   sound/soc/intel/avs/boards/nau8825.c   |  6 ++----
> >   sound/soc/intel/avs/boards/pcm3168a.c  |  6 ++----
> >   sound/soc/intel/avs/boards/probe.c     |  2 +-
> >   sound/soc/intel/avs/boards/rt274.c     |  2 +-
> >   sound/soc/intel/avs/boards/rt286.c     |  2 +-
> >   sound/soc/intel/avs/boards/rt298.c     |  2 +-
> >   sound/soc/intel/avs/boards/rt5514.c    |  2 +-
> >   sound/soc/intel/avs/boards/rt5640.c    |  2 +-
> >   sound/soc/intel/avs/boards/rt5663.c    |  2 +-
> >   sound/soc/intel/avs/boards/rt5682.c    |  2 +-
> >   sound/soc/intel/avs/boards/ssm4567.c   |  2 +-
> >   sound/soc/samsung/i2s.c                |  2 +-
> 
> This change is outstanding when compared to patches 1-4 which follow the
> per-driver approach.  I'd expect one driver per scope e.g.: Intel's avs
> split away from the rest.

Well, patches 1 and 2 primarily follow the one patch per type of change
approach that happen to only affect one driver each. In the v1 thread I
was asked to split out split out the amd/acp bits which resulted in
patches 3 and 4. (And just now I notice you also replied and asked to
split out intel/avs, too, which I missed. Sorry!)

Conceptually I think one commit per driver is the right approach[1] but
most maintainers/reviewers seem to favour one commit adapting one thing
for all drivers in a subsystem. And in my experience no matter how you
make it, you get a reply to change.

Will split out intel/avs for v3 and maybe hit the sweet spot then.

> Nitpick: s/ASOC/ASoC/

Fixed in my tree, so will be correct in v3.

Best regards
Uwe

[1] My reason for that is the "one atomic change per patch" philosophy
    that allows to document who reviewed/acked what in a fine-grained
    way and allows selective reverting and backporting as needed.
    The downside is that the number of patches explodes, but git is able
    to handle that just fine in my experience. "commit count" is missing
    in https://markcarrigan.net/2026/06/18/the-museum-of-meaningless-metrics/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

      reply	other threads:[~2026-07-23  5:30 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-20  6:23 [PATCH v2 0/6] ASoC: Use named initializers for platform_device_id arrays Uwe Kleine-König (The Capable Hub)
2026-07-20  6:23 ` [PATCH v2 1/6] ASoC: codecs: mt6357: Drop unused assignment of platform_device_id driver data Uwe Kleine-König (The Capable Hub)
2026-07-20  6:23 ` [PATCH v2 2/6] ASoC: renesas: fsi: Drop platform probing metadata Uwe Kleine-König (The Capable Hub)
2026-07-20 23:12   ` Kuninori Morimoto
2026-07-20  6:23 ` [PATCH v2 3/6] ASoC: amd: acp: Use named initializers for platform_device_id arrays Uwe Kleine-König (The Capable Hub)
2026-07-21  3:48   ` Mukunda,Vijendar
2026-07-20  6:23 ` [PATCH v2 4/6] ASoC: amd: acp: Unify code style for platform_device_id array Uwe Kleine-König (The Capable Hub)
2026-07-20  7:05   ` Cezary Rojewski
2026-07-20 11:32     ` Uwe Kleine-König (The Capable Hub)
2026-07-21  3:49   ` Mukunda,Vijendar
2026-07-20  6:23 ` [PATCH v2 5/6] ASoC: Use named initializers for platform_device_id arrays Uwe Kleine-König (The Capable Hub)
2026-07-20  8:23   ` Charles Keepax
2026-07-20  6:23 ` [PATCH v2 6/6] ASOC: Unify code style " Uwe Kleine-König (The Capable Hub)
2026-07-22 17:55   ` Cezary Rojewski
2026-07-23  5:30     ` Uwe Kleine-König (The Capable Hub) [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=amGhHDDlwMdool_q@monoceros \
    --to=u.kleine-koenig@baylibre.com \
    --cc=Frank.Li@nxp.com \
    --cc=Xiubo.Lee@gmail.com \
    --cc=amadeuszx.slawinski@linux.intel.com \
    --cc=broonie@kernel.org \
    --cc=cezary.rojewski@intel.com \
    --cc=ckeepax@opensource.cirrus.com \
    --cc=festevam@gmail.com \
    --cc=imx@lists.linux.dev \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=kernel@pengutronix.de \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=lars@metafoo.de \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=nicoleotsuka@gmail.com \
    --cc=nuno.sa@analog.com \
    --cc=perex@perex.cz \
    --cc=peter.ujfalusi@linux.intel.com \
    --cc=pierre-louis.bossart@linux.dev \
    --cc=s.hauer@pengutronix.de \
    --cc=s.nawrocki@samsung.com \
    --cc=shengjiu.wang@gmail.com \
    --cc=srini@kernel.org \
    --cc=tiwai@suse.com \
    --cc=yung-chuan.liao@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox