(sorry, the previous one got sent in HTML by accident)
On 17/06/2024 12:55, Jacobe Zang wrote:
You refer to wlan in the commit message, but there is nothing wlan
related in the patch itself. Update the commit message perhaps?
At that time, I want to describe that wlan and bluetooth were from the module named BCM43438. But, it's true that wlan do not be metioned in the code. I will update it in next version.
I thought you'd need to also reference the respective GPIO to be able to trigger its
state, not just switch the pinctrl configuration to GPIO.
You means the shutdown-gpios? I configure it in the bluetooth node, it can't be configure in rfkill node at the same time.
In Documentation/devicetree/bindings/net/rfkill-gpio.yaml shutdown-gpios
is listed as a required property, did you try building the sources with
CHECK_DTBS=1 in make arguments?
If you already control this GPIO from elsewhere (such as from the
bluetooth driver), then perhaps you don't need to define a separate
rfkill device at all.
I'm also wondering if bt_reset_pin is the right one to use here. On my
Rock 5B I had to trigger bt_wake_pin to get Bluetooth up and running.
Yes, I try to configure bt_reset_pin, bt_wake_host_irq and bt_wake_pin in pinctrl separately. Each of them works well. After I connected a BT device to Edge2, I input rfkill block 1, bluetooth function failed. Then I input rfkill unblock 1, it can rework. So at last I only configure the bt_reset_pin.
That doesn't necessarily mean that the hardware gets an rfkill signal,
what you describe above could also come from the software alone. It
would be great to somehow check if the physical pin state gets triggered
once you switch rfkill state from userspace, and then that the bluetooth
device handles it appropriately (e.g. gets into a hardware-disable state
somehow).
Best regards,
Alexey
