Received-SPF: pass (google.com: domain of linux-bluetooth+bounces-4334-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <3475f0dd-6a0f-4319-9590-379eee33f504@penguintechs.org>
Date: Mon, 6 May 2024 12:21:32 -0700
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: linux-bluetooth@vger.kernel.org,
 Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Zijun Hu <quic_zijuhu@quicinc.com>,
 Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
From: Wren Turkal <wt@penguintechs.org>
Subject: path to landing patch to fix warm boot issue for qca6390
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Krzysztof,

I am reaching out to you as you had the most important objections to the 
change to fix qca6390 for the warm boot/module reload bug that I am 
experiencing.

For context, the problem is that the hci_uart module will send specific 
vendor specfic commands during shutdown of the hardware under most 
situations. These VSCs put the bluetooth device into a non-working state 
on my Dell XPS 13 9310 with qca6390 bluetooth hardware.

Zijun's proposed fix is to not send these commands when it's not 
appropriate for the hardware. The vendor commands should be avoided when 
the hardware does not have persistent configuration or when the device 
is in setup state (indicating that is has never been setup and should 
not be sent the VSCs on the shutdown path). This is what Zijun's patch 
implements.

In addition, Zijun's change removes the influence of both
the QCA_BT_OFF qca flag and and HCI_RUNNING hdev flag. Zijun asserts 
that those flags should not influence the sending of the VSCs in the 
shutdown path. If I understand KK's objections properly, this is where 
his objection is stemming from. KK, is this correct?

Zijun's proposed fix can be seen here: 
https://patchwork.kernel.org/project/bluetooth/patch/1713932807-19619-3-git-send-email-quic_zijuhu@quicinc.com/

I'm wondering if we can resolve this impasse by splitting the change 
into two changes, as follows:

1. Change that removes the influence of the QCA_BT_OFF and HCI_RUNNING 
flags in the shutdown path.
2. Add the quirk from Zijun's patch that fixes my hardward configuration.

I'm hoping that better clearer descriptions for #1 can help get that 
landed since the logic current appears to be at odds with how the 
hardware works.

Also, I am happy to split the patches into the two patches, or (maybe 
more ideally) just modify the commit message to better indicate the 
reason the change. I just need guidance from maintainers so that 
whatever work I do leads to something acceptable for y'all.

So, please help me get this done. I am just a user with broken hardware 
and a fondness for Linux. I would love to help do what's needed to get 
this fix landed.

Please help me get there,
Wren T
-- 
You're more amazing than you think!