From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Bolle Subject: Re: [PATCH v3 5/7] mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources Date: Tue, 17 Jun 2014 18:43:51 +0200 Message-ID: <1403023431.1984.37.camel@x220> References: <1398879850-9111-1-git-send-email-dianders@chromium.org> <1398879850-9111-6-git-send-email-dianders@chromium.org> <20140520084602.GF24991@lee--X1> <1402483068.3798.82.camel@x220> <1402646902.28881.15.camel@x220> <1402995202.1984.22.camel@x220> <53A06AD4.3000704@wwwdotorg.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53A06AD4.3000704-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Stephen Warren Cc: Doug Anderson , Bill Richardson , Simon Glass , Lee Jones , Stephen Warren , Wolfram Sang , Andrew Bresticker , Dylan Reid , Olof Johansson , Samuel Ortiz , linux-samsung-soc , "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: linux-tegra@vger.kernel.org On Tue, 2014-06-17 at 10:20 -0600, Stephen Warren wrote: > On 06/17/2014 02:53 AM, Paul Bolle wrote: > > So, in summary, while we're apparently only discussing a single comment, > > I would appreciate it if it could be reworded, preferably by dropping > > that the CONFIG_ prefix. But other people might care very little, as > > they don't share this particular pet peeve. > > Can't your tool maintain a whitelist or ignore list? Sure it can. But I do think I should try to fix the (in my view, at least) problems I find before adding stuff to a whitelist or (whatever). > There are many > cases where the kernel can pull in headers/data from other projects > (Firmware interfaces to an arbitrarily large set of HW, Device trees, > IO/network protocools, perhaps more). It feels quite unreasonable for > the kernel to decide that it exclusively owns the CONFIG_* namespace > even in comments, and that every other project it interacts with must > not use that namespace. As I said, this is more my peeve. Then again, referring to a macro from some other project is likely to confuse people. Paul Bolle