A regression in linux-next causes Bluetooth functionality to fail during
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.

Fix this by moving runtime PM enablement and uart_add_one_port() after
wakeup IRQ registration, ensuring proper initialization order.

Reported-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Closes:
https://lore.kernel.org/all/20251110101043.2108414-4-praveen.talari@oss.qualcomm.com/
Fixes: 10904d725f6e ("serial: qcom-geni: Enable PM runtime for serial driver")
Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
---
 drivers/tty/serial/qcom_geni_serial.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c
index 6ce6528f5c10..46a9c71630d5 100644
--- a/drivers/tty/serial/qcom_geni_serial.c
+++ b/drivers/tty/serial/qcom_geni_serial.c
@@ -1888,12 +1888,6 @@ static int qcom_geni_serial_probe(struct platform_device *pdev)
 	if (ret)
 		goto error;
 
-	devm_pm_runtime_enable(port->se.dev);
-
-	ret = uart_add_one_port(drv, uport);
-	if (ret)
-		goto error;
-
 	if (port->wakeup_irq > 0) {
 		device_init_wakeup(&pdev->dev, true);
 		ret = dev_pm_set_dedicated_wake_irq(&pdev->dev,
@@ -1906,6 +1900,12 @@ static int qcom_geni_serial_probe(struct platform_device *pdev)
 		}
 	}
 
+	devm_pm_runtime_enable(port->se.dev);
+
+	ret = uart_add_one_port(drv, uport);
+	if (ret)
+		goto error;
+
 	return 0;
 
 error:

base-commit: 6cd6c12031130a349a098dbeb19d8c3070d2dfbe
-- 
2.34.1

On Wed, Jan 07, 2026 at 12:18:34PM +0530, Praveen Talari wrote:
> A regression in linux-next causes Bluetooth functionality to fail during
> 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.
> 
> Fix this by moving runtime PM enablement and uart_add_one_port() after
> wakeup IRQ registration, ensuring proper initialization order.
> 
> Reported-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Closes:
> https://lore.kernel.org/all/20251110101043.2108414-4-praveen.talari@oss.qualcomm.com/

No line wrapping for tags please.

thanks,

greg k-h

On Wed, Jan 07, 2026 at 12:18:34PM +0530, Praveen Talari wrote:
> A regression in linux-next causes Bluetooth functionality to fail during
> bootup on the RB2 platform, preventing proper BT initialization. However,
> BT works correctly after bootup completes.

You mean "6.19-rc1", not "linux-next" here.

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


>
> Fix this by moving runtime PM enablement and uart_add_one_port() after
> wakeup IRQ registration, ensuring proper initialization order.
>
> Reported-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Closes:
> https://lore.kernel.org/all/20251110101043.2108414-4-praveen.talari@oss.qualcomm.com/
> Fixes: 10904d725f6e ("serial: qcom-geni: Enable PM runtime for serial driver")
> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
> ---
>  drivers/tty/serial/qcom_geni_serial.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
>

Tested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

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

Thanks,
Praveen Talari
> 
> 
>>
>> Fix this by moving runtime PM enablement and uart_add_one_port() after
>> wakeup IRQ registration, ensuring proper initialization order.
>>
>> Reported-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>> Closes:
>> https://lore.kernel.org/all/20251110101043.2108414-4-praveen.talari@oss.qualcomm.com/
>> Fixes: 10904d725f6e ("serial: qcom-geni: Enable PM runtime for serial driver")
>> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
>> ---
>>   drivers/tty/serial/qcom_geni_serial.c | 12 ++++++------
>>   1 file changed, 6 insertions(+), 6 deletions(-)
>>
> 
> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> 
>

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?

>
> Thanks,
> Praveen Talari
> >
> >
> >>
> >> Fix this by moving runtime PM enablement and uart_add_one_port() after
> >> wakeup IRQ registration, ensuring proper initialization order.
> >>
> >> Reported-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> >> Closes:
> >> https://lore.kernel.org/all/20251110101043.2108414-4-praveen.talari@oss.qualcomm.com/
> >> Fixes: 10904d725f6e ("serial: qcom-geni: Enable PM runtime for serial driver")
> >> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
> >> ---
> >>   drivers/tty/serial/qcom_geni_serial.c | 12 ++++++------
> >>   1 file changed, 6 insertions(+), 6 deletions(-)
> >>
> >
> > Tested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> >
> >
>


-- 
With best wishes
Dmitry

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

Thanks,
Praveen
> 
>>
>> Thanks,
>> Praveen Talari
>>>
>>>
>>>>
>>>> Fix this by moving runtime PM enablement and uart_add_one_port() after
>>>> wakeup IRQ registration, ensuring proper initialization order.
>>>>
>>>> Reported-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>>> Closes:
>>>> https://lore.kernel.org/all/20251110101043.2108414-4-praveen.talari@oss.qualcomm.com/
>>>> Fixes: 10904d725f6e ("serial: qcom-geni: Enable PM runtime for serial driver")
>>>> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
>>>> ---
>>>>    drivers/tty/serial/qcom_geni_serial.c | 12 ++++++------
>>>>    1 file changed, 6 insertions(+), 6 deletions(-)
>>>>
>>>
>>> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>>
>>>
>>
> 
>

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

?

Konrad

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

On Wed, Jan 07, 2026 at 04:28:22PM +0530, Praveen Talari wrote:
> 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

=> commit message, please.

> 
> Thanks,
> Praveen Talari
> > 
> > ?
> > 
> > Konrad
> 

-- 
With best wishes
Dmitry

Hi Dmistry,

On 1/7/2026 5:05 PM, Dmitry Baryshkov wrote:
> On Wed, Jan 07, 2026 at 04:28:22PM +0530, Praveen Talari wrote:
>> 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
> 
> => commit message, please.

I hope the commit text below should be appropriate

serial: qcom-geni: Fix BT failure regression on RB2 platform

A regression in 6.19-rc1 causes Bluetooth functionality to fail during 
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 the "qup_x"
pinmux function during runtime resume. When wakeup IRQ registration
happens afterward using dev_pm_set_dedicated_wake_irq(), these GPIOs
are reset back to the "gpio" pinmux function, which impacts the RX GPIO
and leads to Bluetooth failures.

Fix this by ensuring wakeup IRQ setup is completed before calling
uart_add_one_port() to prevent the pinmux function conflict.

Thanks,
Praveen

> 
>>
>> Thanks,
>> Praveen Talari
>>>
>>> ?
>>>
>>> Konrad
>>
>

On Wed, Jan 07, 2026 at 07:38:10PM +0530, Praveen Talari wrote:
> Hi Dmistry,
> 
> On 1/7/2026 5:05 PM, Dmitry Baryshkov wrote:
> > On Wed, Jan 07, 2026 at 04:28:22PM +0530, Praveen Talari wrote:
> > > 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
> > 
> > => commit message, please.
> 
> I hope the commit text below should be appropriate
> 
> serial: qcom-geni: Fix BT failure regression on RB2 platform
> 
> A regression in 6.19-rc1 causes Bluetooth functionality to fail during

Commit abcdefaa ("Foo Bar baz") caused BT init to fail....

Otherwise LGTM.

> 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 the "qup_x"
> pinmux function during runtime resume. When wakeup IRQ registration
> happens afterward using dev_pm_set_dedicated_wake_irq(), these GPIOs
> are reset back to the "gpio" pinmux function, which impacts the RX GPIO
> and leads to Bluetooth failures.
> 
> Fix this by ensuring wakeup IRQ setup is completed before calling
> uart_add_one_port() to prevent the pinmux function conflict.
> 
> Thanks,
> Praveen
> 
> > 
> > > 
> > > Thanks,
> > > Praveen Talari
> > > > 
> > > > ?
> > > > 
> > > > Konrad
> > > 
> > 
> 

-- 
With best wishes
Dmitry