From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9A3A6ECDFB3 for ; Mon, 16 Jul 2018 16:05:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5DDB02083E for ; Mon, 16 Jul 2018 16:05:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5DDB02083E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729969AbeGPQdZ (ORCPT ); Mon, 16 Jul 2018 12:33:25 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:50766 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1727405AbeGPQdZ (ORCPT ); Mon, 16 Jul 2018 12:33:25 -0400 X-UUID: 579e710ad74b4db68e3c8ae25753d0ee-20180717 Received: from mtkcas06.mediatek.inc [(172.21.101.30)] by mailgw02.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 909834281; Tue, 17 Jul 2018 00:05:16 +0800 Received: from MTKMBS06N2.mediatek.inc (172.21.101.130) by mtkmbs08n2.mediatek.inc (172.21.101.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 17 Jul 2018 00:05:14 +0800 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs06n2.mediatek.inc (172.21.101.130) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 17 Jul 2018 00:05:14 +0800 Received: from [172.21.77.33] (172.21.77.33) by mtkcas07.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1210.3 via Frontend Transport; Tue, 17 Jul 2018 00:05:14 +0800 Message-ID: <1531757114.8953.12.camel@mtkswgap22> Subject: Re: [PATCH v5 4/7] Bluetooth: Add new quirk for non-persistent setup settings From: Sean Wang To: Marcel Holtmann CC: , , Johan Hedberg , , , , , Date: Tue, 17 Jul 2018 00:05:14 +0800 In-Reply-To: <6571C864-B2EC-4806-BC5D-F531792737F6@holtmann.org> References: <4b188c8a508340598dda233f6d49a16c9ac8784e.1531150733.git.sean.wang@mediatek.com> <2825B722-E75C-4A3C-8110-879205E46C0E@holtmann.org> <1531638169.3955.5.camel@mtkswgap22> <6571C864-B2EC-4806-BC5D-F531792737F6@holtmann.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2018-07-16 at 14:56 +0200, Marcel Holtmann wrote: > Hi Sean, > > >>> Add a new quirk HCI_QUIRK_NON_PERSISTENT_SETUP allowing that a quirk that > >>> runs setup() after every open() and not just after the first open(). > >>> > >>> Signed-off-by: Sean Wang > >>> --- > >>> include/net/bluetooth/hci.h | 9 +++++++++ > >>> net/bluetooth/hci_core.c | 3 ++- > >>> 2 files changed, 11 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h > >>> index 73e48be..d3ec5b2a8 100644 > >>> --- a/include/net/bluetooth/hci.h > >>> +++ b/include/net/bluetooth/hci.h > >>> @@ -183,6 +183,15 @@ enum { > >>> * during the hdev->setup vendor callback. > >>> */ > >>> HCI_QUIRK_NON_PERSISTENT_DIAG, > >>> + > >>> + /* When this quirk is set, setup() would be run after every > >>> + * open() and not just after the first open(). > >>> + * > >>> + * This quirk can be set before hci_register_dev is called or > >>> + * during the hdev->setup vendor callback. > >>> + * > >>> + */ > >>> + HCI_QUIRK_NON_PERSISTENT_SETUP, > >>> }; > >>> > >>> /* HCI device flags */ > >>> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c > >>> index f5c21004..0111280 100644 > >>> --- a/net/bluetooth/hci_core.c > >>> +++ b/net/bluetooth/hci_core.c > >>> @@ -1396,7 +1396,8 @@ static int hci_dev_do_open(struct hci_dev *hdev) > >>> atomic_set(&hdev->cmd_cnt, 1); > >>> set_bit(HCI_INIT, &hdev->flags); > >>> > >>> - if (hci_dev_test_flag(hdev, HCI_SETUP)) { > >>> + if (hci_dev_test_flag(hdev, HCI_SETUP) || > >>> + test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) { > >>> hci_sock_dev_event(hdev, HCI_DEV_SETUP); > >> > >> can you include the extract of btmon on how the HCI_DEV_SETUP event shows up in the traces? I remember that I asked about something like that. > >> > >> Regards > >> > >> Marcel > >> > > > > No, I cannot see any event about HCI_DEV_SETUP in btmon trace, the trace I posted as below is doing some rounds of power off and then on > > it will result in this: > > case HCI_DEV_SETUP: > if (hdev->manufacturer == 0xffff) > return NULL; > > case HCI_DEV_UP: > skb = bt_skb_alloc(HCI_MON_INDEX_INFO_SIZE, GFP_ATOMIC); > > So we will see extra index info events, but I assume that is just fine this we also see them on DEV_UP. They also do not hurt as long as not magically the manufacturer information changes. > > I do wonder though if this quirk is set, then hdev->manufacturer needs to be reset and allow hdev->setup() to reset it. This goes with a log of other information as well. Maybe just a look if there are no races here. > > Regards > > Marcel > I didn't set a value to hdev->manufacture. Should I set it in hdev->setup() ? MediaTek is 0x46 according to [1]. [1] https://www.bluetooth.com/specifications/assigned-numbers/company-identifiers > > _______________________________________________ > Linux-mediatek mailing list > Linux-mediatek@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Wang Subject: Re: [PATCH v5 4/7] Bluetooth: Add new quirk for non-persistent setup settings Date: Tue, 17 Jul 2018 00:05:14 +0800 Message-ID: <1531757114.8953.12.camel@mtkswgap22> References: <4b188c8a508340598dda233f6d49a16c9ac8784e.1531150733.git.sean.wang@mediatek.com> <2825B722-E75C-4A3C-8110-879205E46C0E@holtmann.org> <1531638169.3955.5.camel@mtkswgap22> <6571C864-B2EC-4806-BC5D-F531792737F6@holtmann.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <6571C864-B2EC-4806-BC5D-F531792737F6@holtmann.org> Sender: linux-kernel-owner@vger.kernel.org To: Marcel Holtmann Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Johan Hedberg , linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org, robh+dt@kernel.org, linux-mediatek@lists.infradead.org, linux-arm-kernel@lists.infradead.org List-Id: devicetree@vger.kernel.org On Mon, 2018-07-16 at 14:56 +0200, Marcel Holtmann wrote: > Hi Sean, > > >>> Add a new quirk HCI_QUIRK_NON_PERSISTENT_SETUP allowing that a quirk that > >>> runs setup() after every open() and not just after the first open(). > >>> > >>> Signed-off-by: Sean Wang > >>> --- > >>> include/net/bluetooth/hci.h | 9 +++++++++ > >>> net/bluetooth/hci_core.c | 3 ++- > >>> 2 files changed, 11 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h > >>> index 73e48be..d3ec5b2a8 100644 > >>> --- a/include/net/bluetooth/hci.h > >>> +++ b/include/net/bluetooth/hci.h > >>> @@ -183,6 +183,15 @@ enum { > >>> * during the hdev->setup vendor callback. > >>> */ > >>> HCI_QUIRK_NON_PERSISTENT_DIAG, > >>> + > >>> + /* When this quirk is set, setup() would be run after every > >>> + * open() and not just after the first open(). > >>> + * > >>> + * This quirk can be set before hci_register_dev is called or > >>> + * during the hdev->setup vendor callback. > >>> + * > >>> + */ > >>> + HCI_QUIRK_NON_PERSISTENT_SETUP, > >>> }; > >>> > >>> /* HCI device flags */ > >>> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c > >>> index f5c21004..0111280 100644 > >>> --- a/net/bluetooth/hci_core.c > >>> +++ b/net/bluetooth/hci_core.c > >>> @@ -1396,7 +1396,8 @@ static int hci_dev_do_open(struct hci_dev *hdev) > >>> atomic_set(&hdev->cmd_cnt, 1); > >>> set_bit(HCI_INIT, &hdev->flags); > >>> > >>> - if (hci_dev_test_flag(hdev, HCI_SETUP)) { > >>> + if (hci_dev_test_flag(hdev, HCI_SETUP) || > >>> + test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) { > >>> hci_sock_dev_event(hdev, HCI_DEV_SETUP); > >> > >> can you include the extract of btmon on how the HCI_DEV_SETUP event shows up in the traces? I remember that I asked about something like that. > >> > >> Regards > >> > >> Marcel > >> > > > > No, I cannot see any event about HCI_DEV_SETUP in btmon trace, the trace I posted as below is doing some rounds of power off and then on > > it will result in this: > > case HCI_DEV_SETUP: > if (hdev->manufacturer == 0xffff) > return NULL; > > case HCI_DEV_UP: > skb = bt_skb_alloc(HCI_MON_INDEX_INFO_SIZE, GFP_ATOMIC); > > So we will see extra index info events, but I assume that is just fine this we also see them on DEV_UP. They also do not hurt as long as not magically the manufacturer information changes. > > I do wonder though if this quirk is set, then hdev->manufacturer needs to be reset and allow hdev->setup() to reset it. This goes with a log of other information as well. Maybe just a look if there are no races here. > > Regards > > Marcel > I didn't set a value to hdev->manufacture. Should I set it in hdev->setup() ? MediaTek is 0x46 according to [1]. [1] https://www.bluetooth.com/specifications/assigned-numbers/company-identifiers > > _______________________________________________ > Linux-mediatek mailing list > Linux-mediatek@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek From mboxrd@z Thu Jan 1 00:00:00 1970 From: sean.wang@mediatek.com (Sean Wang) Date: Tue, 17 Jul 2018 00:05:14 +0800 Subject: [PATCH v5 4/7] Bluetooth: Add new quirk for non-persistent setup settings In-Reply-To: <6571C864-B2EC-4806-BC5D-F531792737F6@holtmann.org> References: <4b188c8a508340598dda233f6d49a16c9ac8784e.1531150733.git.sean.wang@mediatek.com> <2825B722-E75C-4A3C-8110-879205E46C0E@holtmann.org> <1531638169.3955.5.camel@mtkswgap22> <6571C864-B2EC-4806-BC5D-F531792737F6@holtmann.org> Message-ID: <1531757114.8953.12.camel@mtkswgap22> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, 2018-07-16 at 14:56 +0200, Marcel Holtmann wrote: > Hi Sean, > > >>> Add a new quirk HCI_QUIRK_NON_PERSISTENT_SETUP allowing that a quirk that > >>> runs setup() after every open() and not just after the first open(). > >>> > >>> Signed-off-by: Sean Wang > >>> --- > >>> include/net/bluetooth/hci.h | 9 +++++++++ > >>> net/bluetooth/hci_core.c | 3 ++- > >>> 2 files changed, 11 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h > >>> index 73e48be..d3ec5b2a8 100644 > >>> --- a/include/net/bluetooth/hci.h > >>> +++ b/include/net/bluetooth/hci.h > >>> @@ -183,6 +183,15 @@ enum { > >>> * during the hdev->setup vendor callback. > >>> */ > >>> HCI_QUIRK_NON_PERSISTENT_DIAG, > >>> + > >>> + /* When this quirk is set, setup() would be run after every > >>> + * open() and not just after the first open(). > >>> + * > >>> + * This quirk can be set before hci_register_dev is called or > >>> + * during the hdev->setup vendor callback. > >>> + * > >>> + */ > >>> + HCI_QUIRK_NON_PERSISTENT_SETUP, > >>> }; > >>> > >>> /* HCI device flags */ > >>> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c > >>> index f5c21004..0111280 100644 > >>> --- a/net/bluetooth/hci_core.c > >>> +++ b/net/bluetooth/hci_core.c > >>> @@ -1396,7 +1396,8 @@ static int hci_dev_do_open(struct hci_dev *hdev) > >>> atomic_set(&hdev->cmd_cnt, 1); > >>> set_bit(HCI_INIT, &hdev->flags); > >>> > >>> - if (hci_dev_test_flag(hdev, HCI_SETUP)) { > >>> + if (hci_dev_test_flag(hdev, HCI_SETUP) || > >>> + test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) { > >>> hci_sock_dev_event(hdev, HCI_DEV_SETUP); > >> > >> can you include the extract of btmon on how the HCI_DEV_SETUP event shows up in the traces? I remember that I asked about something like that. > >> > >> Regards > >> > >> Marcel > >> > > > > No, I cannot see any event about HCI_DEV_SETUP in btmon trace, the trace I posted as below is doing some rounds of power off and then on > > it will result in this: > > case HCI_DEV_SETUP: > if (hdev->manufacturer == 0xffff) > return NULL; > > case HCI_DEV_UP: > skb = bt_skb_alloc(HCI_MON_INDEX_INFO_SIZE, GFP_ATOMIC); > > So we will see extra index info events, but I assume that is just fine this we also see them on DEV_UP. They also do not hurt as long as not magically the manufacturer information changes. > > I do wonder though if this quirk is set, then hdev->manufacturer needs to be reset and allow hdev->setup() to reset it. This goes with a log of other information as well. Maybe just a look if there are no races here. > > Regards > > Marcel > I didn't set a value to hdev->manufacture. Should I set it in hdev->setup() ? MediaTek is 0x46 according to [1]. [1] https://www.bluetooth.com/specifications/assigned-numbers/company-identifiers > > _______________________________________________ > Linux-mediatek mailing list > Linux-mediatek at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek