Re: [PATCH] ASoC: rt5670: Fix GPIO headset detection regression

From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: Oder Chiou <oder_chiou@realtek.com>,
	Bard Liao <bardliao@realtek.com>,
	alsa-devel@alsa-project.org, Mark Brown <broonie@kernel.org>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Subject: Re: [PATCH] ASoC: rt5670: Fix GPIO headset detection regression
Date: Tue, 22 Aug 2017 12:22:41 +0300	[thread overview]
Message-ID: <1503393761.25945.38.camel@linux.intel.com> (raw)
In-Reply-To: <s5hk21wt2d5.wl-tiwai@suse.de>

On Tue, 2017-08-22 at 10:48 +0200, Takashi Iwai wrote:
> On Tue, 22 Aug 2017 10:33:22 +0200,
> Andy Shevchenko wrote:
> > 
> > On Tue, 2017-08-22 at 07:44 +0200, Takashi Iwai wrote:
> > > RT5670 codec driver and its machine driver for Intel CHT assume
> > > the
> > > implicit GPIO mapping on the index 0 while BIOS on most devices
> > > don't
> > > provide it.  The recent commit f10e4bf6632b ("gpio: acpi: Even
> > > more
> > > tighten up ACPI GPIO lookups") restricts such cases and it
> > > resulted in
> > > a regression where the headset jack setup fails like:
> > > 
> > >   rt5670 i2c-10EC5672:00: ASoC: Cannot get gpio at index 0: -2
> > >   rt5670 i2c-10EC5672:00: Adding jack GPIO failed
> > > 
> > > For fixing this, we need to provide the GPIO mapping explicitly in
> > > the
> > > machine driver.  Also this patch corrects the string to be passed
> > > to
> > > gpiolib to match with the pre-given mapping, too.
> > > 
> > > Fixes: f10e4bf6632b ("gpio: acpi: Even more tighten up ACPI GPIO
> > > lookups")
> > 
> > I don't think it fixes that exact commit. with this mapping the
> > driver
> > will work pretty much well for previous versions of kernel (that do
> > not
> > have mentioned commit).
> > 
> > So, for my opinion it should have referred to the initial commit of
> > that
> > board file which brings GPIO request in the first place.
> 
> Yeah, it's a bit unclear which commit should be pointed as "fixes" in
> such a case.  Clearly, the regression came by the mentioned commit, so
> I picked it up for fixes-tag as the indicator to which kernel it
> should be backported -- in the case when it slipped from 4.13 cycle.
> We don't have to apply the fix for patches older than 4.12, it just
> works.  The original GPIO code had some implicit assumption and it
> worked somehow -- no matter whether it's the right thing or not.
> 
> So, while I'm fine to change the fixes tag to point another commit,
> it becomes slightly apart from the "regression fix" that the commit
> was intended for.
> 
> That said, this comes from the multiple usages of fixes tag: it can
> point to a regression point that the patch fixes, and it can point to
> the original commit the (potential) issue was introduced.

It depends on two things:
1) which commit was first: the mentioned one or the board file;
2) how we formulate the patch: fix a "regression" or make it robust
against changes.

Okay, briefly looking seems like GPIO commit comes later, so, it's a
good point to leave fixes as is now. I missed those files since I have
checked a list against modules that have both ACPI ID table and one of
*gpiod_get*() function. I forgot to check against specific sound GPIO
helper.

So, take my tag disregarding on my comment.
Thanks!

P.S. All ASoC board files that are used for ACPI enabled platforms have
to be fixed accordingly.

-- 
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