Re: [PATCH 0/6] platform/x86: x86-android-tablets: fix Arizona and Crystal Cove GPIO lookups

[Hans de Goede <hansg@kernel.org>]

Hi Dmitry.

On 31-Aug-26 14:47, Dmitry Torokhov wrote:
> On Mon, Aug 31, 2026 at 11:42:06AM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 30-Aug-26 1:15 PM, Dmitry Torokhov wrote:
>>> When gpiolib dropped name-against-label matching in favor of firmware node
>>> identity mapping, lookups referencing unattached software nodes (such as
>>> arizona and gpio_crystalcove in x86-android-tablets) stopped working.
>>>
>>> This series fixes the lookups and cleans up redundant software node
>>> registrations on Lenovo tablets:
>>> - Point Arizona GPIO property entries directly to the codec device software
>>>   node, which is attached to the parent device.
>>> - Hold a device reference in gpio_secondary_fwnode_init() to ensure safety
>>>   during devres action teardown.
>>> - Generalize gpio_secondary_fwnode_init() to accept a node group argument
>>>   and use it to attach crystalcove_gpiochip_node as a secondary firmware
>>>   node to INT33FD:00 on Lenovo Yoga Tab 2 models.
>>> - Drop redundant swnode group registrations on Lenovo Yoga Tab 3 and
>>>   Yoga Tab 2 models where codec software nodes are already registered when
>>>   attached to their respective devices.
>>>
>>> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>>
>> So I've given this a test on a Yoga Tablet 3 (yt3) tablet yesterday and
>> there everything works.
>>
>> Then I also tested this on a Lenovo Yoga Tablet 2 1380 since the YT3 does
>> not cover the crystal_cove GPIO case and there things do not work.
>>
>> It seems that trying to get the crystal_cove GPIOs indefinetely returns
>> -EPROBE_DEFER. I'll try to debug thus further this evening.
> 
> I wonder if the patch below will help.

No that does not fix things since I've crystalcove_gpio builtin (1).

Still a good catch though and worthwhile to send out as a standalone
patch.

Regards,

Hans

1) The i915 driver uses CrystalCove PMIC GPIOs for panel on/off on
some drivers and it cannot handle EPROBE_DEFER gracefully at the point
where it is requesting the GPIOs. So this driver must be builtin for
the i915 driver to work correctly on relevant models.