This is not the right place for the patch, but I haven't made contact with the right people on the kernel list to find out where is should go.
Here is an RFC dated Jul-15-2016 from Larry Finger, the author of the r8723bs_bt Bluetooth driver. He suggests that the device should be added to the acpi_device_id table (where I am adding it), but is told 'it should not be added here. Since most likely more is needed. For example within the hci_bcm.c and hci_intel.c drivers we handle the GPIO when attaching the UART to the Bluetooth subsystem. This means at minimum some sort of hci_rtl.c is needed. Can be for the beginning just an enhanced hci_h4.c.'.
Here is another RFC from Hans de Goode dated Apr-08-2017. This one received the response: 'NAK. We are integrating these with hci_bcm.c or hci_intel.c drivers.' from Marcel Holtmann. Additional nuggets from this RFC:
Larry Finger: As Hans stated, the current BT driver runs in userspace. Until we actually produce hci_rtk, having this one line patch will be helpful.Marcel Holtmann: I dislike RFKILL switches for Bluetooth device power control. It creates nasty userspace hacks. I have seen them and it is not a good idea. And I have seen the modified hciattach to make this devices work. That one itself is such a nasty hack. Frankly once you see struct sk_buff you should run away scared ;). Lets get hci_rtk.c upstream. Even if it has limited support at the beginning. Also we are moving towards serdev right now and these chips will benefit greatly here
I had also submitted my patch on Jul-08-2017, and I received the following response from Marcel Holtmann: it does not belong in rfkill-gpio.c since this controls the power of the Bluetooth device. This belongs in the Bluetooth driver. We already moved all the Intel and Broadcom ones into hci_intel.c and respectively hci_bcm.c. So have the staging driver deal with the power GPIO.
Currently I apply my patch while remastering, but need to track upstream to see what the resolution is.
It is a single-line patch to net/rfkill/rfkill-gpio.c:
This is not the right place for the patch, but I haven't made contact with the right people on the kernel list to find out where is should go.
Here is an RFC dated Jul-15-2016 from Larry Finger, the author of the r8723bs_bt Bluetooth driver. He suggests that the device should be added to the acpi_device_id table (where I am adding it), but is told 'it should not be added here. Since most likely more is needed. For example within the hci_bcm.c and hci_intel.c drivers we handle the GPIO when attaching the UART to the Bluetooth subsystem. This means at minimum some sort of hci_rtl.c is needed. Can be for the beginning just an enhanced hci_h4.c.'.
Here is another RFC from Hans de Goode dated Apr-08-2017. This one received the response: 'NAK. We are integrating these with hci_bcm.c or hci_intel.c drivers.' from Marcel Holtmann. Additional nuggets from this RFC:
Larry Finger: As Hans stated, the current BT driver runs in userspace. Until we actually produce hci_rtk, having this one line patch will be helpful. Marcel Holtmann: I dislike RFKILL switches for Bluetooth device power control. It creates nasty userspace hacks. I have seen them and it is not a good idea. And I have seen the modified hciattach to make this devices work. That one itself is such a nasty hack. Frankly once you see struct sk_buff you should run away scared ;). Lets get hci_rtk.c upstream. Even if it has limited support at the beginning. Also we are moving towards serdev right now and these chips will benefit greatly here
I had also submitted my patch on Jul-08-2017, and I received the following response from Marcel Holtmann: it does not belong in rfkill-gpio.c since this controls the power of the Bluetooth device. This belongs in the Bluetooth driver. We already moved all the Intel and Broadcom ones into hci_intel.c and respectively hci_bcm.c. So have the staging driver deal with the power GPIO.
Currently I apply my patch while remastering, but need to track upstream to see what the resolution is.