Re: [PATCH v1] serial: qcom_geni: Fix BT failure regression on RB2 platform

[Praveen Talari <praveen.talari@oss.qualcomm.com>]

Hi Konrad,

On 1/7/2026 4:16 PM, Konrad Dybcio wrote:
> On 1/7/26 10:24 AM, Praveen Talari wrote:
>> Hi
>>
>> On 1/7/2026 12:52 PM, Dmitry Baryshkov wrote:
>>> On Wed, 7 Jan 2026 at 09:06, Praveen Talari
>>> <praveen.talari@oss.qualcomm.com> wrote:
>>>>
>>>> Hi Dmistry,
>>>>
>>>> On 1/7/2026 12:24 PM, Dmitry Baryshkov wrote:
>>>>> On Wed, 7 Jan 2026 at 08:48, Praveen Talari
>>>>> <praveen.talari@oss.qualcomm.com> wrote:
>>>>>>
>>>>>> A regression in linux-next causes Bluetooth functionality to fail during
>>>>>
>>>>> linux-next is an ephemeral thing. Please reference the exact commit.
>>>>>
>>>>>> bootup on the RB2 platform, preventing proper BT initialization. However,
>>>>>> BT works correctly after bootup completes.
>>>>>>
>>>>>> The issue occurs when runtime PM is enabled and uart_add_one_port() is
>>>>>> called before wakeup IRQ setup. The uart_add_one_port() call activates the
>>>>>> device through runtime PM, which configures GPIOs to their default state.
>>>>>> When wakeup IRQ registration happens afterward, it conflicts with these
>>>>>> GPIO settings, causing state corruption that breaks Bluetooth
>>>>>> functionality.
>>>>>
>>>>> How does it "conflict with GPIO settings", what is "state corruption"?
>>>>
>>>> I mean the issue occurs because the GPIO state is being altered during
>>>> the wakeup source registration process..
>>>
>>> Altered how?
>>
>> During the runtime resume of devices, GPIOs are configured to QUP mode. However, when registering the wakeup IRQ using dev_pm_set_dedicated_wake_irq(), these GPIOs are reset back to FUNC mode, which impacts the RX GPIO and leads to Bluetooth failures
> 
> "QUP mode" and "FUNC mode" are tough to swallow even for an insider.. How
> about:
> 
> "qup_x" and "gpio" pinmux functions

Yes, you are right. I am talking about "qup_x" and "gpio" pinmux functions

Thanks,
Praveen Talari
> 
> ?
> 
> Konrad