All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Vaussard <florian.vaussard-p8DiymsW2f8@public.gmane.org>
To: Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
Cc: Andy Whitcroft <apw-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>,
	Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v2 2/2] checkpatch: fix spurious vendor compatible warnings
Date: Wed, 05 Mar 2014 14:58:02 +0100	[thread overview]
Message-ID: <53172D6A.9050900@epfl.ch> (raw)
In-Reply-To: <1393869097.13719.88.camel@joe-AO722>

Hi,

On 03/03/2014 06:51 PM, Joe Perches wrote:
> On Mon, 2014-03-03 at 11:44 +0100, Florian Vaussard wrote:
>> Looking at the current documentation, the list of these generic
>> placeholders is pretty short:
>>
>> $ git grep ',<.*>-' Documentation/devicetree/bindings/ | \
>>   grep -P -o ',<.*?>-' | grep -P -o '<.*>' | sort | uniq
>>
>> <board>
>> <chip>
>> <chip name>
>> <mcu-chip>
>> <processor>
>> <soc>
>> <SOC>
>> <soc-family>
>>
>> so '[a-zA-Z0-9-]+' seems more reasonable indeed.
> 
> The <mcu-chip> use seems as if it's 2 wildcards
> 
> 	fsl,<mcu-chip>-<board>
> 
> I'm not sure that could work with the current
> checkpatch code.
> 

I don't think it is desirable to make it work with the current
checkpatch code, as it is not enough constrained. For example, it allows
any compatible "fsl,foo-bar" to match, which opens the door for abuse.
We should have at least one fixed pattern.

> There's a space in "<chip name>" that should
> probably be replaced by "<chip-name>" or just
> "<chip>" for consistency.
> 

Sure, some cleaning could be necessary. I will see what I can do.

>> $compat2 =~ s/\,[a-zA-Z0-9]*\-/<\.\*>\-/g;
> 
> hand-escaped, not necessary if using "\Q$compat2\E"
> 

I wasn't aware of this, thanks.

> Anyway, if either you or Rob think it appropriate to
> submit a patch for either of the things I mentioned
> in the first place:
> 
>> o Look for ".compatible = "foo" strings in .c and .h files
>> o Improve the vendor name match in vendor-prefix.txt by only
>>   matching the exact vendor name at the beginning of lines.
> 
> or any of the stuff above here, please do.
> 

As you already sent a patch for these, I will include it in the v3 of
this series.

I see another problem: with the current regexp patterns, we have
enforced the use of a limited character set. But if one uses an exotic
character (even a simple space ' '), no warning will be produced at all.
We may check that we have at least one matching test, and throw a
warning otherwise. But this opens the question of enforcing the
characters used in compatible strings, where there is no strict
guideline AFAIK.

Regards,
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Florian Vaussard <florian.vaussard@epfl.ch>
To: Joe Perches <joe@perches.com>
Cc: Andy Whitcroft <apw@canonical.com>, Rob Herring <robh@kernel.org>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] checkpatch: fix spurious vendor compatible warnings
Date: Wed, 05 Mar 2014 14:58:02 +0100	[thread overview]
Message-ID: <53172D6A.9050900@epfl.ch> (raw)
In-Reply-To: <1393869097.13719.88.camel@joe-AO722>

Hi,

On 03/03/2014 06:51 PM, Joe Perches wrote:
> On Mon, 2014-03-03 at 11:44 +0100, Florian Vaussard wrote:
>> Looking at the current documentation, the list of these generic
>> placeholders is pretty short:
>>
>> $ git grep ',<.*>-' Documentation/devicetree/bindings/ | \
>>   grep -P -o ',<.*?>-' | grep -P -o '<.*>' | sort | uniq
>>
>> <board>
>> <chip>
>> <chip name>
>> <mcu-chip>
>> <processor>
>> <soc>
>> <SOC>
>> <soc-family>
>>
>> so '[a-zA-Z0-9-]+' seems more reasonable indeed.
> 
> The <mcu-chip> use seems as if it's 2 wildcards
> 
> 	fsl,<mcu-chip>-<board>
> 
> I'm not sure that could work with the current
> checkpatch code.
> 

I don't think it is desirable to make it work with the current
checkpatch code, as it is not enough constrained. For example, it allows
any compatible "fsl,foo-bar" to match, which opens the door for abuse.
We should have at least one fixed pattern.

> There's a space in "<chip name>" that should
> probably be replaced by "<chip-name>" or just
> "<chip>" for consistency.
> 

Sure, some cleaning could be necessary. I will see what I can do.

>> $compat2 =~ s/\,[a-zA-Z0-9]*\-/<\.\*>\-/g;
> 
> hand-escaped, not necessary if using "\Q$compat2\E"
> 

I wasn't aware of this, thanks.

> Anyway, if either you or Rob think it appropriate to
> submit a patch for either of the things I mentioned
> in the first place:
> 
>> o Look for ".compatible = "foo" strings in .c and .h files
>> o Improve the vendor name match in vendor-prefix.txt by only
>>   matching the exact vendor name at the beginning of lines.
> 
> or any of the stuff above here, please do.
> 

As you already sent a patch for these, I will include it in the v3 of
this series.

I see another problem: with the current regexp patterns, we have
enforced the use of a limited character set. But if one uses an exotic
character (even a simple space ' '), no warning will be produced at all.
We may check that we have at least one matching test, and throw a
warning otherwise. But this opens the question of enforcing the
characters used in compatible strings, where there is no strict
guideline AFAIK.

Regards,
Florian

  reply	other threads:[~2014-03-05 13:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-28 16:25 [PATCH v2 0/2] checkpatch: fixes for vendor compatible check Florian Vaussard
2014-02-28 16:25 ` [PATCH v2 1/2] checkpatch: check vendor compatible with dashes Florian Vaussard
     [not found] ` <1393604742-14317-1-git-send-email-florian.vaussard-p8DiymsW2f8@public.gmane.org>
2014-02-28 16:25   ` [PATCH v2 2/2] checkpatch: fix spurious vendor compatible warnings Florian Vaussard
2014-02-28 16:25     ` Florian Vaussard
2014-02-28 21:06     ` Joe Perches
2014-03-03 10:44       ` Florian Vaussard
2014-03-03 10:44         ` Florian Vaussard
     [not found]         ` <53145D21.4080101-p8DiymsW2f8@public.gmane.org>
2014-03-03 17:51           ` Joe Perches
2014-03-03 17:51             ` Joe Perches
2014-03-05 13:58             ` Florian Vaussard [this message]
2014-03-05 13:58               ` Florian Vaussard
2014-03-03 13:50       ` Rob Herring
2014-03-03 13:50         ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53172D6A.9050900@epfl.ch \
    --to=florian.vaussard-p8diymsw2f8@public.gmane.org \
    --cc=apw-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.