Hi Kiran,
> There is no standard HCI command to retrieve data path for transport.
> Add a new callback function to retrieve data path which is used
> in offload usecase.
>
> Signed-off-by: Kiran K <kiran.k@xxxxxxxxx>
> Reviewed-by: Chethan T N <chethan.tumkur.narayan@xxxxxxxxx>
> Reviewed-by: Srivatsa Ravishankar <ravishankar.srivatsa@xxxxxxxxx>
> ---
>
> This callback gets called when audio module queries codecs suppoted
> on SCO socket. For Intel controllers, data_path is always 1
>
> drivers/bluetooth/btintel.c | 8 ++++++++
> drivers/bluetooth/btintel.h | 6 ++++++
> drivers/bluetooth/btusb.c | 1 +
> include/net/bluetooth/hci_core.h | 1 +
> 4 files changed, 16 insertions(+)
>
> diff --git a/drivers/bluetooth/btintel.c b/drivers/bluetooth/btintel.c
> index e3ad19244054..8407e9736c62 100644
> --- a/drivers/bluetooth/btintel.c
> +++ b/drivers/bluetooth/btintel.c
> @@ -1300,6 +1300,14 @@ int btintel_read_offload_usecases(struct hci_dev *hdev)
> }
> EXPORT_SYMBOL_GPL(btintel_read_offload_usecases);
>
> +int btintel_get_data_path_id(struct hci_dev *hdev)
> +{
> + if (!test_bit(HCI_QUIRK_HFP_OFFLOAD_CODECS_SUPPORTED, &hdev->quirks))
> + return -EOPNOTSUPP;
> + return 1;
> +}
> +EXPORT_SYMBOL_GPL(btintel_get_data_path_id);
> +
actually lets not do it this way. Only set the get_data_path_id callback if offloading is supported and with that we don’t actually need to quirk either. If it is set, we know that we can offload.
Regards
Marcel
