Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20221117110804.1431024-1-hsinyi@chromium.org> <CAD=FV=VEC=GzkDfaOqauBB5Y79teS1ENA5wFUHZmnTRkg6Z4tg@mail.gmail.com>
 <CAJMQK-gQj83N1MBu1s+_YDJ4qbqN4McSqCnOwWAq4iaNXo5Sfg@mail.gmail.com>
In-Reply-To: <CAJMQK-gQj83N1MBu1s+_YDJ4qbqN4McSqCnOwWAq4iaNXo5Sfg@mail.gmail.com>
From:   Doug Anderson <dianders@chromium.org>
Date:   Thu, 17 Nov 2022 09:25:44 -0800
Message-ID: <CAD=FV=VoF5PyeNWX+4_3sseyRemZVsr5WtQVeg-8mhfgm40w3g@mail.gmail.com>
Subject: Re: [PATCH v6 1/3] drm_bridge: register content protect property
To:     Hsin-Yi Wang <hsinyi@chromium.org>
Cc:     Sean Paul <seanpaul@chromium.org>,
        Robert Foss <robert.foss@linaro.org>,
        Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
        Maxime Ripard <mripard@kernel.org>,
        Thomas Zimmermann <tzimmermann@suse.de>,
        Daniel Vetter <daniel@ffwll.ch>,
        dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
        Allen Chen <allen.chen@ite.com.tw>,
        David Airlie <airlied@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi,

On Thu, Nov 17, 2022 at 9:12 AM Hsin-Yi Wang <hsinyi@chromium.org> wrote:
>
> On Thu, Nov 17, 2022 at 11:57 PM Doug Anderson <dianders@chromium.org> wrote:
> >
> > Hi,
> >
> > On Thu, Nov 17, 2022 at 3:08 AM Hsin-Yi Wang <hsinyi@chromium.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@chromium.org>
> > > Reviewed-by: Sean Paul <seanpaul@chromium.org>
> > > Reported-by: kernel test robot <lkp@intel.com>
> >
> > Not sure it's worth spinning for, but FWIW I wouldn't put
> > "Reported-by: kernel test robot <lkp@intel.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