Re: [PATCH v2 6/6] ASOC: Unify code style for platform_device_id arrays
Cezary Rojewski <[email protected]>
| Newsgroups | dev.linux.lists.imx,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-kernel,org.kernel.vger.linux-sound,org.ozlabs.lists.linuxppc-dev |
|---|---|
| Message-ID | <[email protected]> |
On 7/23/2026 7:30 AM, Uwe Kleine-König (The Capable Hub) wrote: > 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. Couldn't agree more with the last one. Happens to us all :) > Will split out intel/avs for v3 and maybe hit the sweet spot then. Thank you.