From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: Nicolas Porcel <nicolasporcel06@gmail.com>,
Mark Brown <broonie@kernel.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Liam Girdwood <lgirdwood@gmail.com>,
alsa-devel@alsa-project.org
Subject: Re: [PATCH v2] ASoC: Intel: byt-max98090: Add GPIO ACPI mapping table
Date: Sun, 11 Jun 2017 20:02:07 +0300 [thread overview]
Message-ID: <1497200527.22624.113.camel@linux.intel.com> (raw)
In-Reply-To: <s5hr2yq1ne9.wl-tiwai@suse.de>
On Sun, 2017-06-11 at 18:48 +0200, Takashi Iwai wrote:
> On Sun, 11 Jun 2017 16:01:13 +0200,
> Andy Shevchenko wrote:
> > On Sat, 2017-06-10 at 21:41 +0200, Takashi Iwai wrote:
> > > On Sat, 10 Jun 2017 18:37:41 +0200,
> > > Andy Shevchenko wrote:
> > > >
> > > > +static const struct acpi_gpio_params hp_gpios = { 0, 0, false
> > > > };
> > > > +static const struct acpi_gpio_params mic_gpios = { 1, 0, false
> > > > };
> > > > +
> > > > +static const struct acpi_gpio_mapping acpi_byt_max98090_gpios[]
> > > > = {
> > > > + { "hp-gpios", &hp_gpios, 1 },
> > > > + { "mic-gpios", &mic_gpios, 1 },
> > >
> > > Better to use C99 style init?
> >
> > Here it makes a little advantage over more uglified code.
> >
> > > I'm not always a fan of it, but this
> > > seems deserving. From the above, it's difficult to know which
> > > zero is
> > > for what.
> >
> > I'm not sure it makes sense. Those fields are filed according to
> > ACPI
> > specification and applies to the platform in question. Usually you
> > don't
> > need to look into them on regular basis, perhaps one time per each
> > platform which uses such combination of SoC + ASoC + Codec which is
> > quite unlikely to be more than once twice per year(?).
> >
> > So, for over few dozens of drivers which are using GPIO ACPI mapping
> > tables this is the first request like this I see.
>
> It's a proof showing that people are just too lazy and copy the first
> implementation pattern :)
>
> > Thus, if you insist, I can do it, but my vote is "it doesn't worth
> > of
> > doing it at all".
>
> Well, I'm not insisting to change that, but I still think that your
> argument is rather weak from the code quality POV.
> The C99 style initialization is definitely an improvement for
> understanding the code. The most important question is not about how
> often changing the code, but about how better a reader can understand
> and how it give less errors.
In general I certainly agree with you. In this particular case
uglification vs. clearness not in the right balance (to me at least).
> It results in more lines? Yes. It's uglier? Depends.
> So what? It makes clearer and less error-prone.
Again, above case one has to file all members no matter what, since it's
a mapping and explicit better than implicit there. Taking above into
consideration the C99 style just adds a noise here for my POV.
> Hrm, must I do that? No, it's still a kind of matter of taste.
So, let's agree not to touch this particular case(s)?
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
next prev parent reply other threads:[~2017-06-11 17:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-10 16:37 [PATCH v2] ASoC: Intel: byt-max98090: Add GPIO ACPI mapping table Andy Shevchenko
2017-06-10 19:41 ` Takashi Iwai
2017-06-11 14:01 ` Andy Shevchenko
2017-06-11 16:48 ` Takashi Iwai
2017-06-11 17:02 ` Andy Shevchenko [this message]
2017-06-11 17:08 ` Takashi Iwai
2017-06-11 17:18 ` Andy Shevchenko
2017-06-12 8:54 ` Andy Shevchenko
2017-06-13 21:08 ` Applied "ASoC: Intel: byt-max98090: Add GPIO ACPI mapping table" to the asoc tree Mark Brown
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=1497200527.22624.113.camel@linux.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=lgirdwood@gmail.com \
--cc=nicolasporcel06@gmail.com \
--cc=tiwai@suse.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).