/* controller is already having an operational firmware */
- if (ver.fw_variant == 0x23)
+ if (ver.fw_variant == 0x23) {
+ if (force_load_fw) {
+ btintel_reset_to_bootloader(hdev);
+ force_load_fw = false;
+ return -EAGAIN;
+ }
+ bt_dev_info(hdev, "already in operational mode, not load
fw. Set force_load_fw=1 to load fw forcibly");
goto finish;
+ }
I don’t like this approach. I rather do this in a more generic way
that resets the controller and puts it into boot loader support if
support. We can use the experimental mgmt setting for this.
OK, got it, will investigate it. Thanks.
Hi Marcel,
Do you mean use experimental features in the mgmt? Recently I read the
mgmt exp_features related code, looks like the userspace tool btmgmt
only supports 2 commands so far, they are expinfo and exp-debug, it
looks like expinfo read some info from kernel, exp-debug set one bool
value to kernel, but exp-debug sends the hard-coded uuid to kernel, my
understanding is this could only set FEATURE_DEBUG. If i add a new
feature like reset_controller_to_bootloader, I can't call it through
expinfo or exp-debug.
And the kernel commit (cbbdfa6f3319 Bluetooth: Enable controller RPA
resolution using Experimental feature) add a new feature, how to set
this feature via expinfo and exp-debug or some userspace tool?
Thanks,
Hui.
Regards
Marcel
