Received-SPF: pass (google.com: domain of linux-bluetooth+bounces-4336-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <3475f0dd-6a0f-4319-9590-379eee33f504@penguintechs.org>
In-Reply-To: <3475f0dd-6a0f-4319-9590-379eee33f504@penguintechs.org>
From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date: Mon, 6 May 2024 15:49:22 -0400
Message-ID: <CABBYNZ+FBwFtrqg1Hj72Q7_6f8hDSwVTNtkofP0XgEd98DRf9A@mail.gmail.com>
Subject: Re: path to landing patch to fix warm boot issue for qca6390
To: Wren Turkal <wt@penguintechs.org>
Cc: linux-bluetooth@vger.kernel.org, 
	Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, Zijun Hu <quic_zijuhu@quicinc.com>, 
	Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Wren,

On Mon, May 6, 2024 at 3:24=E2=80=AFPM Wren Turkal <wt@penguintechs.org> wr=
ote:
>
> 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-g=
it-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.

Ive also objected to that change, in fact the whole shutdown sequence
is sort of bogus in my opinion and the driver shall really have some
means to find out what mode it is in when it reboots, regardless if
cold or warm boot, since otherwise we are in trouble if the user is
booting from another OS that doesn't do the expected shutdown
sequence.

--=20
Luiz Augusto von Dentz