[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <61fd78e4-d583-42f2-9886-7f657585b9d4@quicinc.com>
Date: Tue, 24 Dec 2024 16:29:53 +0800
From: "Cheng Jiang (IOE)" <quic_chejiang@...cinc.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
Marcel Holtmann
<marcel@...tmann.org>,
Luiz Augusto von Dentz <luiz.dentz@...il.com>,
"Rob
Herring" <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
"Conor
Dooley" <conor+dt@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
"Konrad Dybcio" <konradybcio@...nel.org>,
Balakrishna Godavarthi
<quic_bgodavar@...cinc.com>,
Rocky Liao <quic_rjliao@...cinc.com>
CC: <linux-bluetooth@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
<quic_jiaymao@...cinc.com>, <quic_shuaz@...cinc.com>,
<quic_zijuhu@...cinc.com>, <quic_mohamull@...cinc.com>
Subject: Re: [PATCH v5 2/4] Bluetooth: qca: Update firmware-name to support
board specific nvm
On 12/23/2024 7:46 PM, Konrad Dybcio wrote:
> On 23.12.2024 3:47 AM, Cheng Jiang (IOE) wrote:
>> Hi Konrad,
>>
>> On 12/20/2024 9:46 PM, Konrad Dybcio wrote:
>>> On 13.12.2024 8:05 AM, Cheng Jiang (IOE) wrote:
>>>
>>> [...]
>>>
>>>>> /*
>>>>> * If the board-specific file is missing, try loading the default
>>>>> * one, unless that was attempted already
>>>>> */
>>>>>
>>>>> But, even more importantly:
>>>>>
>>>>> a) do we want to load the "incorrect" file?
>>>> Normally, there is a default NVM file ending with .bin, which is suitable
>>>> for most boards. However, some boards have different configurations that
>>>> require a specific NVM. If a board-specific NVM is not found, a default
>>>> NVM is preferred over not loading any NVM.
>>>
>>> So, if one is specified, but not found, this should either be a loud error,
>>> or a very loud warning & fallback. Otherwise, the device may provide subpar
>>> user experience without the user getting a chance to know the reason.
>>>
>>> I think failing is better here, as that sends a clearer message, and would
>>> only happen if the DT has a specific path (meaning the user put some
>>> intentions behind that choice)
>>>
>> In the existing BT driver implementation, even if the rampatch/nvm are not found,
>> BT still works with ROM code only. No fails, just a warning in the dmesg. For this
>> new approach, we use the similar logic.
>>
>> The fallback to load a default nvm file is due to each board has a unique board
>> id, it's not necessary to upstream all the board-specific nvm since most of them
>> may be the same, the default nvm file is suitable for them. But we can't set the
>> default nvm file name in the DT, since the platform can attach different
>> connectivity boards. This is a reasonable way to approach this.
>
> Okay, let's do it this way then.
>
Ack.
>>>>> b) why would we want to specify the .bin file if it's the default anyway?
>>>> The default NVM directory is the root of qca. The 'firmware-name' property
>>>> can specify an NVM file in another directory. This can be either a default
>>>> NVM like 'QCA6698/hpnv21.bin' or a board-specific NVM like 'QCA6698/hpnv21.b205'.
>>>
>>> Do we expect QCA6698/hpnv21.bin and QCAabcd/hpnv21.bin to be compatible?
>>>
>> No. It may be different.
>
> That's a bit disappointing considering the filename implies it's suitable
> for a family of chips.. But I guess there's nothing we can change here.
>
They are different generations, so the nvm file may be not compatible. Yes,
there is nothing we can change here.
> Konrad
Powered by blists - more mailing lists