linux-kernel - Re: [PATCH v5 0/8] Support ROHM BU27034 ALS sensor

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: <ZBrgXgJ8AooUSRVW@smile.fi.intel.com>
Date:   Wed, 22 Mar 2023 13:02:54 +0200
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Matti Vaittinen <mazziesaccount@...il.com>
Cc:     Javier Martinez Canillas <javierm@...hat.com>,
        Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
        Noralf Trønnes <noralf@...nnes.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        Shreeya Patel <shreeya.patel@...labora.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Jonathan Cameron <jic23@...nel.org>,
        devicetree@...r.kernel.org, Zhigang Shi <Zhigang.Shi@...eon.com>,
        Maxime Ripard <mripard@...nel.org>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Paul Gazzillo <paul@...zz.com>,
        Maxime Ripard <maxime@...no.tech>,
        Maíra Canal <mcanal@...lia.com>,
        Rob Herring <robh+dt@...nel.org>,
        Dmitry Osipenko <dmitry.osipenko@...labora.com>,
        linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, kunit-dev@...glegroups.com,
        Stephen Boyd <sboyd@...nel.org>, Emma Anholt <emma@...olt.net>,
        Liam Beguin <liambeguin@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Daniel Vetter <daniel@...ll.ch>,
        David Gow <davidgow@...gle.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Brendan Higgins <brendan.higgins@...ux.dev>,
        David Airlie <airlied@...il.com>,
        linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v5 0/8] Support ROHM BU27034 ALS sensor

On Wed, Mar 22, 2023 at 12:59:33PM +0200, Matti Vaittinen wrote:
> On 3/22/23 12:34, Javier Martinez Canillas wrote:
> > > On Wed, Mar 22, 2023 at 11:05:23AM +0200, Matti Vaittinen wrote:

...

> > > > - copy code from DRM test helper instead of moving it to simplify
> > > >    merging
> > > 
> > > 1) Why do you think this is a problem?
> > > 2) How would we avoid spreading more copies of the same code in the future?
> > > 
> > > 
> > > 1) Merge conflicts is not a bad thing. It shows that people tested their code
> > > in isolation and stabilized it before submitting to the upper maintainer.
> > > 
> > > https://yarchive.net/comp/linux/git_merges_from_upstream.html
> > > 
> > > 2) Spreading the same code when we _know_ this, should be very well justified.
> > > Merge conflict is an administrative point, and not a technical obstacle to
> > > avoid.
> 
> I definitely agree. This is also why I did the renaming and not copying in
> the first version. In this version I did still add the subsequent patch 2/8
> - which drops the duplicates from DRM tree.
> 
> > I believe this was suggested by Maxime and the rationale is that by just
> > copying the helpers for now, that would make it easier to land instead of
> > requiring coordination between different subystems.
> 
> This is correct.
> 
> > Otherwise the IIO tree will need to provide an inmutable branch for the
> > DRM tree to merge and so on.
> 
> Or, if we carry the patch 1/8 via self-test tree, then we get even more
> players here.
> 
> Still, I am not opposing immutable branch because that would allow fast
> applying of the patch 2/8 as well. Longer that is delayed, more likely we
> will see more users of the DRM helpers and harder it gets to remove the
> duplicates later.
> 
> > I agree with Maxime that a little bit of duplication (that can be cleaned
> > up by each subsystem at their own pace) is the path of least resistance.
> 
> I'd say this depends. It probably is the path of least resistance for people
> maintaining the trees. It can also be the path of least resistance in
> general - but it depends on if there will be no new users for those DRM
> helpers while waiting the new APIs being merged in DRM tree. More users we
> see in DRM, more effort the clean-up requires.
> 
> I have no strong opinion on this specific case. I'd just be happy to see the
> IIO tests getting in preferably sooner than later - although 'soon' and
> 'late' does also depend on other factors besides these helpers...

Since I'm not a maintainer of either, and one of them requires something,
I can't oppose.

-- 
With Best Regards,
Andy Shevchenko