Hi Fred,
> This allows user space application to set the correct vendor specific
> setup function.
>
> Signed-off-by: Frederic Danis <frederic.danis@xxxxxxxxxxxxxxx>
> ---
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
