lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c0fd52a2-56a8-47cc-ad40-8c14c269445b@oss.qualcomm.com>
Date: Wed, 7 Jan 2026 11:46:17 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Praveen Talari <praveen.talari@....qualcomm.com>,
        Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
        bryan.odonoghue@...aro.org, andersson@...nel.org, psodagud@...cinc.com,
        djaggi@...cinc.com, quic_msavaliy@...cinc.com,
        quic_vtanuku@...cinc.com, quic_arandive@...cinc.com,
        quic_shazhuss@...cinc.com, quic_cchiluve@...cinc.com
Subject: Re: [PATCH v1] serial: qcom_geni: Fix BT failure regression on RB2
 platform

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ