Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1183783 > unrolled thread

Re: [PATCH] rfkill-gpio: Add support for the Realtek 8723 BT

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] rfkill-gpio: Add support for the Realtek 8723 BT Marcel Holtmann <marcel@holtmann.org> - 2015-07-14 17:30 +0200
    Re: [PATCH] rfkill-gpio: Add support for the Realtek 8723 BT Bastien Nocera <hadess@hadess.net> - 2015-07-15 08:30 +0200

#1183783 — Re: [PATCH] rfkill-gpio: Add support for the Realtek 8723 BT

Hi Bastien,

> http://thread.gmane.org/gmane.linux.kernel.wireless.general/127706/focu
> s=127896
> 
> Signed-off-by: Bastien Nocera <hadess@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.

Regards

Marcel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1184304

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 <hadess@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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web