Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3577171imu; Fri, 18 Jan 2019 12:53:43 -0800 (PST) X-Google-Smtp-Source: ALg8bN6NlONF4dhBZLWiKtWFBfBDMJflgrCRYJK8eoKbd47K/KDyJXNNXK8TVomXBTw5gQZpYF/h X-Received: by 2002:a63:5664:: with SMTP id g36mr19048577pgm.313.1547844823472; Fri, 18 Jan 2019 12:53:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547844823; cv=none; d=google.com; s=arc-20160816; b=x1D0FmQPO22paRqalVlzqVGNdJTBQCBHZly3E9z2XIP2a61fWgP+a55Mx3kkwoephO Wj7AaLPDUFHIsm3EPxoz0kHYREvZzX3BtOu/HNcyGvquruuPrgM7Pt/sPmi/0q/qmW8H V+P56bimVtuYdC/cZh2tt2QFoA4PXxc9j6b4iiKne7L4We+lf+Yn1y19UaXe4xHh/w0C JgBddjYw0QeV+y54iGeCcZ0oZKwYzn9vcCQFK+kLUcIYKlx3xM/x26ubghVj2nmetblr LOKfG+LVUNeExm96tQil3tpik3YJDL4kVeWNCODB4rllsxrWdJzhDvlBxG1qbvgUR5/O tvMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=d55kv1Odtp4wUVXwmNpwnomEyVkO6+qn4xgL1ctrvlE=; b=aP+r25wUIXnyPKnveiO6ix3w5Cv4uoeYnDzvfzPenbU4lb9wJ9yKmVJs3FM5bTmg3z kBKel0tAeJQ7WWwuz/8RXj/9TOWlfx2wCKEa+0P0VrQiCib0eFPSet4OUpCjDrUm4grz Rcl+drCSFCNGIAEckS9XdLeGdjMz67MRSZWCIVpjO57QwG7ScQ4DBsFXBRhIvkentzGl 8x263EAl15MPN2hV3i1TVG6CqCzZuwd3ASeXexRS95L8bhhUyuJmXK65DBc//Gu8XkV9 GM1chxRgj0q5bA0YIKItfyaqPFeWbuDr+OW11RcFRQUzIns95FP19nfb3wV5ToV8e4lW 1fqg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=mT7wLWq+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z31si5470797plb.402.2019.01.18.12.53.27; Fri, 18 Jan 2019 12:53:43 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=mT7wLWq+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729579AbfARUwK (ORCPT + 99 others); Fri, 18 Jan 2019 15:52:10 -0500 Received: from mail-lf1-f66.google.com ([209.85.167.66]:41410 "EHLO mail-lf1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729506AbfARUwJ (ORCPT ); Fri, 18 Jan 2019 15:52:09 -0500 Received: by mail-lf1-f66.google.com with SMTP id c16so11447920lfj.8 for ; Fri, 18 Jan 2019 12:52:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=d55kv1Odtp4wUVXwmNpwnomEyVkO6+qn4xgL1ctrvlE=; b=mT7wLWq+OspjuepeD9b5H8I/yhIMHHSjXy16IdNJYxfURPj67q7P61Iv8gILMgjo7u IhnfcsusSO46GMzdjxdvx69W1Q2qDZJ9Am58wqkWBbUSZcygFvaXoLMFKbpFDANMyqXl zTYKjTdhv0Fp/rJ3Wmfr/WQakT3wDkQlE3vXZnF89PQ0gEbsENt9iOzGBCw0DU7tCNFw 3hw6RSiqyi0c0xIwJoQWmNgYh1ya+ewfrBahKUkLDBTfKVKy/FWWSvdSsheXM2P87TVy K118ebZW5hpNonFaQAr8W8GIU7ipNZxSpDP9O5U8VahOumzpPMHW47i+Rer5oHk6BY/R lquQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=d55kv1Odtp4wUVXwmNpwnomEyVkO6+qn4xgL1ctrvlE=; b=q2CEJkyQ+zey6I+/RfpjtRR+icaxzP7rGTxbe3CgOSqfmdqvb1m+EC83Q2KFEFFT9E ykuGNEoV/Mv0QokivUFTGZij467cXuSCFG2kdGgf1cJuC96MSu+RcWlZjovTiKPePXzH 9MAj39hjSVnUZ5Z6ARVzOtveInuQgOapmevaoaS14GZOLzO+lQyzE8gLIIfH9nqQm/Y8 07LSp5Nw0z2dWVaPLRLNVhg7Yr1UbUiGjgKZD814tKt5EYgNyDYPxuP3LoOKTYvrLduh 8tk8al4gEXBBFiDm8XGaBQ19XeDTjaLyIRAKlOEr15VqMq4OeEVPyNZwUVfVTRYREjWc BmWA== X-Gm-Message-State: AJcUukc8tf3plT89MVznT7Jd7I/p4wOrh9xWwkvoXPeR2+FzTEdRlqb9 KuPCRueUqYpNSiI+o5bnRF0iKEZi/xvWc4SPSvRU0g== X-Received: by 2002:a19:c995:: with SMTP id z143mr12162960lff.79.1547844726265; Fri, 18 Jan 2019 12:52:06 -0800 (PST) MIME-Version: 1.0 References: <20181117010748.24347-1-rajatja@google.com> <20181121235020.29461-1-rajatja@google.com> <20181121235020.29461-5-rajatja@google.com> In-Reply-To: From: Rajat Jain Date: Fri, 18 Jan 2019 12:51:29 -0800 Message-ID: Subject: Re: [PATCH v3 5/5] Bluetooth: btusb: Use the hw_reset method to allow resetting the BT chip To: Marcel Holtmann Cc: Johan Hedberg , Greg Kroah-Hartman , "David S. Miller" , Dmitry Torokhov , Alex Hung , linux-bluetooth@vger.kernel.org, Linux Kernel Mailing List , linux-usb@vger.kernel.org, netdev@vger.kernel.org, Rajat Jain , Dmitry Torokhov , raghuram.hegde@intel.com, chethan.tumkur.narayan@intel.com, "Ghorai, Sukumar" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Marcel, Thanks for your review. On Fri, Jan 18, 2019 at 3:04 AM Marcel Holtmann wrote= : > > Hi Rajat, > > > If the platform provides it, use the reset gpio to reset the BT > > chip (requested by the HCI core if needed). This has been found helpful > > on some of Intel bluetooth controllers where the firmware gets stuck an= d > > the only way out is a hard reset pin provided by the platform. > > > > Signed-off-by: Rajat Jain > > --- > > v3: Better error handling for gpiod_get_optional() > > v2: Handle the EPROBE_DEFER case. > > > > drivers/bluetooth/btusb.c | 40 +++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 40 insertions(+) > > > > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c > > index e8e148480c91..e7631f770fae 100644 > > --- a/drivers/bluetooth/btusb.c > > +++ b/drivers/bluetooth/btusb.c > > @@ -29,6 +29,7 @@ > > #include > > #include > > #include > > +#include > > #include > > > > #include > > @@ -475,6 +476,8 @@ struct btusb_data { > > struct usb_endpoint_descriptor *diag_tx_ep; > > struct usb_endpoint_descriptor *diag_rx_ep; > > > > + struct gpio_desc *reset_gpio; > > + > > __u8 cmdreq_type; > > __u8 cmdreq; > > > > @@ -490,6 +493,26 @@ struct btusb_data { > > int oob_wake_irq; /* irq for out-of-band wake-on-bt */ > > }; > > > > + > > +static void btusb_hw_reset(struct hci_dev *hdev) > > +{ > > + struct btusb_data *data =3D hci_get_drvdata(hdev); > > + struct gpio_desc *reset_gpio =3D data->reset_gpio; > > + > > + /* > > + * Toggle the hard reset line if the platform provides one. The r= eset > > + * is going to yank the device off the USB and then replug. So do= ing > > + * once is enough. The cleanup is handled correctly on the way ou= t > > + * (standard USB disconnect), and the new device is detected clea= nly > > + * and bound to the driver again like it should be. > > + */ > > + bt_dev_dbg(hdev, "%s: Initiating HW reset via gpio", __func__); > > No __func__ here. That bt_dev_dbg does all of that via dynamic debug alre= ady. Will fix. > > > + clear_bit(HCI_QUIRK_HW_RESET_ON_TIMEOUT, &hdev->quirks); > > + gpiod_set_value(reset_gpio, 1); > > + mdelay(100); > > + gpiod_set_value(reset_gpio, 0); > > +} > > + > > static inline void btusb_free_frags(struct btusb_data *data) > > { > > unsigned long flags; > > @@ -2917,6 +2940,7 @@ static int btusb_probe(struct usb_interface *intf= , > > const struct usb_device_id *id) > > { > > struct usb_endpoint_descriptor *ep_desc; > > + struct gpio_desc *reset_gpio; > > struct btusb_data *data; > > struct hci_dev *hdev; > > unsigned ifnum_base; > > @@ -3030,6 +3054,16 @@ static int btusb_probe(struct usb_interface *int= f, > > > > SET_HCIDEV_DEV(hdev, &intf->dev); > > > > + reset_gpio =3D gpiod_get_optional(&data->udev->dev, "reset", > > + GPIOD_OUT_LOW); > > + if (IS_ERR(reset_gpio)) { > > + err =3D PTR_ERR(reset_gpio); > > + goto out_free_dev; > > + } else if (reset_gpio) { > > + data->reset_gpio =3D reset_gpio; > > + hdev->hw_reset =3D btusb_hw_reset; > > + } > > + > > How do we ensure that this is the right =E2=80=9Creset=E2=80=9D line. And= it also needs to be bound to some hardware unless > we can guarantee that this is always the same. The BIOS / ACPI ensures that. The kernel driver just uses the ACPI provided reset line. > > > hdev->open =3D btusb_open; > > hdev->close =3D btusb_close; > > hdev->flush =3D btusb_flush; > > @@ -3085,6 +3119,7 @@ static int btusb_probe(struct usb_interface *intf= , > > set_bit(HCI_QUIRK_STRICT_DUPLICATE_FILTER, &hdev->quirks)= ; > > set_bit(HCI_QUIRK_SIMULTANEOUS_DISCOVERY, &hdev->quirks); > > set_bit(HCI_QUIRK_NON_PERSISTENT_DIAG, &hdev->quirks); > > + set_bit(HCI_QUIRK_HW_RESET_ON_TIMEOUT, &hdev->quirks); > > You are not messing with the quirks here please. Clearing quirks is crazy= . Use the data->flags since this should be all btusb.c specific. Do I understand it right that you do not want me to clear the quirks in btusb_hw_reset() and use data->flags instead? Sure, I will do that. But I'm not sure if that's all you meant, because you commented on btusb_probe() code where I'm setting the quirk (not clearing it) so that the hci core can call the hw_reset() callback on timeout. Thanks, Rajat > > > > > if (id->driver_info & BTUSB_INTEL) { > > hdev->setup =3D btusb_setup_intel; > > @@ -3225,6 +3260,8 @@ static int btusb_probe(struct usb_interface *intf= , > > return 0; > > > > out_free_dev: > > + if (data->reset_gpio) > > + gpiod_put(data->reset_gpio); > > hci_free_dev(hdev); > > return err; > > } > > @@ -3268,6 +3305,9 @@ static void btusb_disconnect(struct usb_interface= *intf) > > if (data->oob_wake_irq) > > device_init_wakeup(&data->udev->dev, false); > > > > + if (data->reset_gpio) > > + gpiod_put(data->reset_gpio); > > + > > hci_free_dev(hdev); > > } > > Regards > > Marcel >