linux-kernel - Re: [PATCH v6 1/3] drm_bridge: register content protect property

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] [day] [month] [year] [list]

Date:   Thu, 17 Nov 2022 09:25:44 -0800
From:   Doug Anderson <dianders@...omium.org>
To:     Hsin-Yi Wang <hsinyi@...omium.org>
Cc:     Sean Paul <seanpaul@...omium.org>,
        Robert Foss <robert.foss@...aro.org>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Daniel Vetter <daniel@...ll.ch>,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        Allen Chen <allen.chen@....com.tw>,
        David Airlie <airlied@...il.com>
Subject: Re: [PATCH v6 1/3] drm_bridge: register content protect property

Hi,

On Thu, Nov 17, 2022 at 9:12 AM Hsin-Yi Wang <hsinyi@...omium.org> wrote:
>
> On Thu, Nov 17, 2022 at 11:57 PM Doug Anderson <dianders@...omium.org> wrote:
> >
> > Hi,
> >
> > On Thu, Nov 17, 2022 at 3:08 AM Hsin-Yi Wang <hsinyi@...omium.org> wrote:
> > >
> > > Some bridges are able to update HDCP status from userspace request if
> > > they support HDCP.
> > >
> > > HDCP property is the same as other connector properties that needs to be
> > > created after the connecter is initialized and before the connector is
> > > registered.
> > >
> > > If there exists a bridge that supports HDCP, add the property to the
> > > bridge connector.
> > >
> > > Signed-off-by: Hsin-Yi Wang <hsinyi@...omium.org>
> > > Reviewed-by: Sean Paul <seanpaul@...omium.org>
> > > Reported-by: kernel test robot <lkp@...el.com>
> >
> > Not sure it's worth spinning for, but FWIW I wouldn't put
> > "Reported-by: kernel test robot <lkp@...el.com>". The emails from that
> > bot are always a bit confusing in this regards, but I think they mean
> > "if the patch has already landed and you're sending a separate patch
> > with a fix then please add the "Reported-by" tag". ...but adding it to
> > the original patch just doesn't make a lot of sense.
>
> Got it, thanks. I think I'll wait for a while to see if there's other
> comments. Otherwise should I send another version to remove the tag?

I don't think it's necessary. Someone could just remove it when they
land the patch.

Speaking of which, I'm OK with landing the first two patches with
Sean's Reviewed-by, but ideally we'd get a non-Google review from
someone that maintains the bridge stuff on the patches. That being
said, in another email thread [1] it was pointed out that the bridge
subsystem is mainly under maintained. When I got committer access for
drm-misc access I was told in IRC that part of my job would be to deal
with landing ChromeOS-related stuff assuming it was properly reviewed.

I'm about to head on vacation for ~1 week and don't want to land and
run, so how about this? Let's see if you can get Sean to review the
3rd patch in the series. If he's happy with it and things aren't on
fire when I get back, I'll send another email to the list saying that
I'll give that patch another ~1 week on the list and then land it if
there are no objections. This way folks will have plenty of warning if
they want to review the series, but if not then it won't sit waiting
forever. Assuming everything with v6 still looks good and there is no
other reason to spin, I'm happy removing the extra Reported-by tag
when I land.

[1] https://lore.kernel.org/r/20221117143411.5sdyrx6v2nunql5n@houat