linux-kernel - Re: Rule for bridge yaml dt binding maintainers?

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: <9a32f150f85f851d04afd148b2a9a5cf203f7ce1.camel@perches.com>
Date:   Wed, 22 Apr 2020 16:43:03 -0700
From:   Joe Perches <joe@...ches.com>
To:     Rob Herring <robh+dt@...nel.org>, Sam Ravnborg <sam@...nborg.org>
Cc:     Adrian Ratiu <adrian.ratiu@...labora.com>,
        devicetree@...r.kernel.org,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>,
        Neil Armstrong <narmstrong@...libre.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andrzej Hajda <a.hajda@...sung.com>,
        Collabora Kernel ML <kernel@...labora.com>
Subject: Re: Rule for bridge yaml dt binding maintainers?

On Wed, 2020-04-22 at 15:02 -0500, Rob Herring wrote:
> On Mon, Apr 20, 2020 at 12:59 PM Sam Ravnborg <sam@...nborg.org> wrote:
> > Hi Adrian
> > 
> > On Mon, Apr 20, 2020 at 02:19:24PM +0300, Adrian Ratiu wrote:
> > > Hello,
> > > 
> > > I got confused while doing the txt -> yaml conversion at [1] and it's still
> > > not clear to me who should be added in the "maintainers" field.  Clearly not
> > > the maintainers as returned by get_maintainer.pl. :)
> > > 
> > > Rob mentioned that "owners" should be manintainers but I also have trouble
> > > picking the persons who should be owners / yaml maintainers.
> > > 
> > > Looking at the completed bridge conversions in the latest linux-next, I
> > > couldn't find a rule and the majority of bindings are still txt:
> > > 
> > > $ find ./devicetree/bindings/display/bridge/ -name *txt | wc -l
> > > 23
> > > $ find ./devicetree/bindings/display/bridge/ -name *yaml | wc -l
> > > 5
> > > 
> > > So my questions are:
> > > 1. Is there a general rule for assigning yaml file owners/maintainers?
> > > 
> > > 2. Is this vagueness specific to the bridge dt bindings only?
> > > 
> > > 3. Who should step up and maintain these bindings? Original/new authors,
> > > SoC, bridge, DRM maintainers etc.?
> > > 
> > > It would be useful to have a rule to make it easier to do these conversions.
> > > We (Collabora) are considering doing the conversion work.
> > 
> > For the panel conversion I did recently it was simple:
> > 1) If listed in MAINTAINERS - use this info
> > 2) Otherwise use the person(s) that authored the original .txt file.
> >    Using git log --follow foo.txt
> > 3) In a few cases I may have decided otherwise, but the above covers the
> >    majority.
> 
> Yes.
> 
> > I would also be great if you or someone else could:
> > - teach get_maintainers about .yaml file listed maintainers
> 
> It already does to some extent. IIRC, there's a mode to extract email
> addresses from files.

--file-emails

> I was hoping that the MAINTAINERS file split happens sometime and we
> can just generate a MAINTAINERS file for bindings.

I don't see the value really.

> > - teach checkpatch that it is OK to convert .txt to .yaml

I suppose that get_maintainer _could_ enable --file-emails
for .yaml files.

something like this (more comments below too)
---
 scripts/get_maintainer.pl | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 6cbcd1..9d947a0 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -527,7 +527,7 @@ foreach my $file (@ARGV) {
 	$file =~ s/^\Q${cur_path}\E//;	#strip any absolute path
 	$file =~ s/^\Q${lk_path}\E//;	#or the path to the lk tree
 	push(@files, $file);
-	if ($file ne "MAINTAINERS" && -f $file && ($keywords || $file_emails)) {
+	if ($file ne "MAINTAINERS" && -f $file && ($keywords || $file_emails || $file =~ /\.yaml$/)) {
 	    open(my $f, '<', $file)
 		or die "$P: Can't open $file: $!\n";
 	    my $text = do { local($/) ; <$f> };
@@ -539,7 +539,7 @@ foreach my $file (@ARGV) {
 		    }
 		}
 	    }
-	    if ($file_emails) {
+	    if ($file_emails || $file =~ /\.yaml$/) {
 		my @poss_addr = $text =~ m$[A-Za-zÀ-ÿ\"\' \,\.\+-]*\s*[\,]*\s*[\(\<\{]{0,1}[A-Za-z0-9_\.\+-]+\@[A-Za-z0-9\.-]+\.[A-Za-z0-9]+[\)\>\}]{0,1}$g;
 		push(@file_emails, clean_file_emails(@poss_addr));
 	    }

---

> Yeah, I should fix my bug.
> 
> > - teach checkpatch about some simple yaml validation (maybe)
> 
> I don't see checkpatch being able to check much of what comes up in
> review. Maybe indentation.

Likely better done with another external tool.

Could be added to checkpatch as an external
call like spdxcheck.py