linux-kernel - Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib

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]

Date:   Fri, 17 Nov 2023 13:13:05 +0100
From:   Maxime Ripard <mripard@...nel.org>
To:     Sui Jingfeng <sui.jingfeng@...ux.dev>
Cc:     Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Phong LE <ple@...libre.com>,
        Neil Armstrong <neil.armstrong@...aro.org>,
        Sui Jingfeng <suijingfeng@...ngson.cn>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
        Thomas Zimmermann <tzimmermann@...e.de>
Subject: Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib

On Fri, Nov 17, 2023 at 12:24:22PM +0800, Sui Jingfeng wrote:
> Hi,
> 
> On 2023/11/16 23:23, Dmitry Baryshkov wrote:
> > > > > Then you will need some way (fwnode?) to
> > > > > discover the bridge chain. And at the last point you will get into the
> > > > > device data and/or properties business.
> > > > > 
> > > > No, leave that chance to a more better programmer and forgive me please,
> > > > too difficult, I'm afraid of not able to solve. Thanks a lot for the
> > > > trust!
> >  From my point of view: no.
>
> I respect the fact that the community prefer generic mechanisms.
> If our approach is not what the community want, can I switch back
> to my previous solution?

By your previous solution, you mean rolling your own bridge driver? If
so, then no, it's not acceptable either.

> I can reduce the duplication of our localized it66121 driver to a
> minimal, rewrite it until it meets the community's requirement. I know
> our device looks weird and our approach is not elegant.

I'm glad we agree then :)

> But at the very least, we could not mess the community's design up by
> localize. Otherwise, I don't know what is the better approach to solve
> such a problem.

I think there's a gap between what we want from you and what you want
from us.

What we really care about is maintenance. In other words, it's mostly
about two things:

  - Once you and/or your company have moved on to other things, how easy
    it will be for us to keep that driver in good shape, and how much it
    will hold back any future development.

  - If we want to do a big rework, how much your driver will stand in
    the way.

That's pretty much all that we care about, and we will very much prefer
not to merge a driver in the first place than to have to maintain it for
10y while it stands in our way and we don't have any real documentation
or help.

So by making it "not weird" or "elegant" or whatever we can call it, you
effectively remove any concern we might have about merging your driver,
and there's only an upside (more hardware support and company
involvement is good!). So you're making it easy for you too.

Maxime

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