On Tue, 2015-07-14 at 17:29 +0200, Marcel Holtmann wrote: > Hi Bastien, > > > http://thread.gmane.org/gmane.linux.kernel.wireless.general/127706/ > > focu > > s=127896 > > > > Signed-off-by: Bastien Nocera <had...@hadess.net> > > > > --- > > net/rfkill/rfkill-gpio.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c > > index d5d58d9..9471024 100644 > > --- a/net/rfkill/rfkill-gpio.c > > +++ b/net/rfkill/rfkill-gpio.c > > @@ -168,6 +168,7 @@ static const struct acpi_device_id > > rfkill_acpi_match[] = { > > { "BCM2E3D", RFKILL_TYPE_BLUETOOTH }, > > { "BCM2E40", RFKILL_TYPE_BLUETOOTH }, > > { "BCM2E64", RFKILL_TYPE_BLUETOOTH }, > > + { "OBDA8723", RFKILL_TYPE_BLUETOOTH }, > > { "BCM4752", RFKILL_TYPE_GPS }, > > { "LNV4752", RFKILL_TYPE_GPS }, > > { }, > > while this is most likely a good start to get people going and > testing the hardware, I think long-term some these IDs have to move > out of this driver and into a Realtek specific UART slave driver > (once we get such a thing upstream). > > I think one example would be what Fred is currently doing for the > Broadcom UART devices. Essentially we are currently misusing the > RFKILL switch for an on/off switch of the GPIO lines. This would be > better handled by the Bluetooth subsystem itself when you power on > the controller.
Duly noted. I'll postpone that until I have time to do hardware enablement on the Bluetooth side of that chipset. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
