linux-kernel - Re: [PATCH v4 0/5] MFD/ASoC: Add support for Intel Bay Trail boards with WM5102 codec

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210204164826.GF4288@sirena.org.uk>
Date:   Thu, 4 Feb 2021 16:48:26 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Lee Jones <lee.jones@...aro.org>
Cc:     Hans de Goede <hdegoede@...hat.com>,
        Cezary Rojewski <cezary.rojewski@...el.com>,
        Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
        Jie Yang <yang.jie@...ux.intel.com>,
        patches@...nsource.cirrus.com, linux-kernel@...r.kernel.org,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Charles Keepax <ckeepax@...nsource.cirrus.com>,
        alsa-devel@...a-project.org
Subject: Re: [PATCH v4 0/5] MFD/ASoC: Add support for Intel Bay Trail boards
 with WM5102 codec

On Thu, Feb 04, 2021 at 03:21:24PM +0000, Lee Jones wrote:

> The default point-of-view is; if a patch was submitted as part of a
> set, it's likely that it makes the most sense to merge it as a set.

Blocking the whole series is itself not ideal since it means the whole
large series keeps on getting resent for minor changes in individual
patches where it's only a small number of leaf patches that have issues, 
with a lot of these serieses the reason they're bundled together is that
there's some constants being added in one of the early patches that gets
used everywhere else, not that there's a really a particularly strong
relationship.

> Very often sets will have inter-dependencies (usually headers) which
> would otherwise require the base patches to be applied (perhaps the
> MFD core and the headers) in one release, followed by the accompanying
> child device changes during a subsequent release.  This doesn't scale
> well and puts the contributor in an unfair position.

You had been sharing pull requests for the common bits in the past which
had resolved the dependency issues?

> This is how we usually work together.  Why is ASoC so different?

Like I say we've got active work that ends up doing subsystem wide
interface changes on a fairly frequent basis which then creates issues
if a new user pops up that's still trying to use the old API.  Often
it's fine but coordinating near the time is safer than just acking with
a potentially long lead time on things actually going through.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)