[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <30b09e71-6790-4ab2-8945-e011996ee85f@remarkable.no>
Date: Tue, 14 Jan 2025 15:09:32 +0100
From: Johan Korsnes <johan.korsnes@...arkable.no>
To: Neeraj Sanjay Kale <neeraj.sanjaykale@....com>,
"marcel@...tmann.org" <marcel@...tmann.org>,
"luiz.dentz@...il.com" <luiz.dentz@...il.com>,
"robh@...nel.org" <robh@...nel.org>, "krzk+dt@...nel.org"
<krzk+dt@...nel.org>, "conor+dt@...nel.org" <conor+dt@...nel.org>
Cc: "linux-bluetooth@...r.kernel.org" <linux-bluetooth@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
Amitkumar Karwar <amitkumar.karwar@....com>, Sherry Sun
<sherry.sun@....com>, Luke Wang <ziniu.wang_1@....com>,
"kristian.krohn@...arkable.no" <kristian.krohn@...arkable.no>,
Manjeet Gupta <manjeet.gupta@....com>
Subject: Re: [PATCH v2 2/2] Bluetooth: btnxpuart: Add support for set BD
address
On 1/14/25 3:07 PM, Neeraj Sanjay Kale wrote:
>
> Hi Johan,
>
>>
>> On 1/14/25 2:35 PM, Neeraj Sanjay Kale wrote:
>>> This adds support for setting BD address during hci registration. NXP
>>> FW does not allow vendor commands unless it receives a reset command
>>> after FW download and initialization done.
>>> As a workaround, the .set_bdaddr callback function will first send the
>>> HCI reset command, followed by the actual vendor command to set BD
>>> address.
>>>
>>
>> Hi Neeraj,
>>
>> If NXP firmware does not allow vendor commands prior to this reset, would it
>> not be better to perform this reset during probe/init?
>>
> HCI reset is already part of kernel init sequence hci_init0_sync().
> However, .set_bdaddr() is called immediately after FW download is complete, but before this init sequence.
>
> Also, if local-bd-address property is not defined in the DTB, sending HCI reset command in probe does not add any value.
>
> With current implementation, if local-bd-address is defined, driver sends HCI reset, followed by set BD address vendor command, and kernel continues with the HCI init sequence.
>
Thanks for clarifying, that makes sense :-)
Kind regards,
Johan
> Thanks,
> Neeraj
Powered by blists - more mailing lists