Re: [RFC 1/5] Bluetooth: hci_uart: Add HCIUARTSETDEVTYPE ioctl

[Marcel Holtmann <marcel@holtmann.org>]

Hi Fred,

> This allows user space application to set the correct vendor specific
> setup function.
> 
> Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com>
> ---
> drivers/bluetooth/hci_ldisc.c | 50 +++++++++++++++++++++++++++++++++++++++++++
> drivers/bluetooth/hci_uart.h  |  4 ++++
> 2 files changed, 54 insertions(+)
> 
> diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
> index 1363dc6..cb7fcc6 100644
> --- a/drivers/bluetooth/hci_ldisc.c
> +++ b/drivers/bluetooth/hci_ldisc.c
> @@ -467,9 +467,19 @@ static int hci_uart_register_dev(struct hci_uart *hu)
> 	return 0;
> }
> 
> +struct hci_uart_devtype_t {
> +	char type[HCI_UART_DEVTYPE_SIZE];
> +	int (*setup)(struct hci_uart *hu);
> +};
> +
> +struct hci_uart_devtype_t devtypes[] = {
> +		{ "", 0 }
> +};
> +

I am actually not in favor of this and I do not think this is needed.

If you want a different hdev->setup function, then you need to implement a new protocol. We already have the HCIUARTSETPROTO ioctl and that should be the main selection point on which driver/vendor is attached to the TTY.

Lets focus on just using HCIUARTSETPROTO for now and when needed just introduce a new driver/vendor in case we want to add special setup code. We can have generic_* type of helpers in hci_ldisc.c for generic H:4 stuff in case it is just a H:4 driver. We can use select in Kconfig to ensure that hci_h4.c gets include when another driver/vendor needs it.

Regards

Marcel