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.