All of lore.kernel.org
 help / color / mirror / Atom feed
From: Darren Hart <dvhart@infradead.org>
To: "Michał Kępień" <kernel@kempniu.pl>
Cc: Jonathan Woithe <jwoithe@just42.net>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	Andy Shevchenko <andy@infradead.org>,
	Platform Driver <platform-driver-x86@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/7] platform/x86: fujitsu-laptop: Define constants for FUNC operations
Date: Mon, 5 Mar 2018 15:16:50 -0800	[thread overview]
Message-ID: <20180305231650.GA25693@fury> (raw)
In-Reply-To: <20180304194426.GA1428@kmp-mobile.hq.kempniu.pl>

On Sun, Mar 04, 2018 at 08:44:26PM +0100, Michał Kępień wrote:
> > On Wed, Feb 28, 2018 at 06:08:52PM +0200, Andy Shevchenko wrote:
> > > On Tue, Feb 27, 2018 at 11:15 PM, Micha?? K??pie?? <kernel@kempniu.pl> wrote:
> > > > Various functions exposed by the firmware through the FUNC interface
> > > > tend to use a consistent set of integers for denoting the type of
> > > > operation to be performed for a specified feature.  Use named constants
> > > > instead of integers in each call_fext_func() invocation in order to more
> > > > clearly convey the intent of each call.
> > > >
> > > > Note that FUNC_FLAGS is a bit peculiar:
> > > 
> > > > +/* FUNC interface - operations */
> > > > +#define OP_GET                         BIT(1)
> > > > +#define OP_GET_CAPS                    0
> > > > +#define OP_GET_EVENTS                  BIT(0)
> > > > +#define OP_GET_EXT                     BIT(2)
> > > > +#define OP_SET                         BIT(0)
> > > > +#define OP_SET_EXT                     (BIT(2) | BIT(0))
> > > 
> > > Hmm... this looks unordered a bit.
> > 
> > It seems to be ordered alphabetically on the identifier.  Andy, is it
> > preferred to order defines like this based on resolved numeric order?
>  
> Just to expand on what Jonathan wrote above: if you take a peek at the
> end result of the patch series, you will notice a pattern: constants in
> each section are ordered alphabetically by their name.  I wanted all
> sections to be consistently ordered.  If you would rather have me order
> things by the bit index, sure, no problem, just please note that the
> order above is not accidental.

Hrm. In my experience it is more typical to order by value (bit), that's a
little less obvious when using the BIT()|BIT() macros though. So long as it's
consistent, I think that's what matters most.

-- 
Darren Hart
VMware Open Source Technology Center

  parent reply	other threads:[~2018-03-05 23:16 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-27 21:15 [PATCH 0/7] fujitsu-laptop: Consistent naming of constants Michał Kępień
2018-02-27 21:15 ` [PATCH 1/7] platform/x86: fujitsu-laptop: Define constants for FUNC operations Michał Kępień
2018-02-28 16:08   ` Andy Shevchenko
2018-03-04  5:08     ` Jonathan Woithe
2018-03-04 19:44       ` Michał Kępień
2018-03-04 22:49         ` Jonathan Woithe
2018-03-05 23:16         ` Darren Hart [this message]
2018-03-06  9:37           ` Andy Shevchenko
2018-03-06 20:59             ` Michał Kępień
2018-03-07 12:34               ` Andy Shevchenko
2018-03-10 20:10                 ` Michał Kępień
2018-03-12  9:27                   ` Andy Shevchenko
2018-02-27 21:15 ` [PATCH 2/7] platform/x86: fujitsu-laptop: Define constants for FUNC features Michał Kępień
2018-02-27 21:15 ` [PATCH 3/7] platform/x86: fujitsu-laptop: Define constants for FUNC feature states Michał Kępień
2018-02-27 21:15 ` [PATCH 4/7] platform/x86: fujitsu-laptop: Rename constants defining hotkey codes Michał Kępień
2018-02-27 21:15 ` [PATCH 5/7] platform/x86: fujitsu-laptop: Tweak how constants are commented and laid out Michał Kępień
2018-02-27 21:15 ` [PATCH 6/7] platform/x86: fujitsu-laptop: More accurately represent the hotkey ring buffer managed by firmware Michał Kępień
2018-02-28 16:13   ` Andy Shevchenko
2018-03-04 19:57     ` Michał Kępień
2018-02-27 21:15 ` [PATCH 7/7] platform/x86: fujitsu-laptop: Introduce fext_*() helper functions Michał Kępień
2018-03-04  5:37 ` [PATCH 0/7] fujitsu-laptop: Consistent naming of constants Jonathan Woithe
2018-03-21 23:25 ` Darren Hart

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=20180305231650.GA25693@fury \
    --to=dvhart@infradead.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=andy@infradead.org \
    --cc=jwoithe@just42.net \
    --cc=kernel@kempniu.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.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.