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: <8fe9fea1-b7b8-ee46-9534-de7e2b1726f9@gmail.com>
Date:   Wed, 22 Mar 2023 12:59:33 +0200
From:   Matti Vaittinen <mazziesaccount@...il.com>
To:     Javier Martinez Canillas <javierm@...hat.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     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 3/22/23 12:34, Javier Martinez Canillas wrote:
> Andy Shevchenko <andriy.shevchenko@...ux.intel.com> writes:
> 
> Hello Andy,
> 
>> On Wed, Mar 22, 2023 at 11:05:23AM +0200, Matti Vaittinen wrote:
>>
>>> Revision history:
>>> v4 => v5: Mostly fixes to review comments from Andy and Jonathan.
>>> - more accurate change-log in individual patches
>>
>>> - 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...

Yours,
	-- Matti

-- 
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~