Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp536206imm; Wed, 18 Jul 2018 06:35:29 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcQ4Bs+tE+smh9fDjSQxGqL0NmqbgG5bha2CJMHe6YV5+n1PJqL9/JDQjrdxIvOiuDg2PiD X-Received: by 2002:a62:11c4:: with SMTP id 65-v6mr5274737pfr.54.1531920929302; Wed, 18 Jul 2018 06:35:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531920929; cv=none; d=google.com; s=arc-20160816; b=TG544daXgK7dctR+g7DRwQXMh5+GhihUDORBFUcr9G8DM0aGXTrDbCu3yP+LsUrCYi ozN2GfGNM+jNEBWb1EdW1qQzO2FO4vEmz+dwgzL7Tmz822W5333pNdUmTCJj7FmWtm+J nEmSTK6nOXqUhoFj9CoeUlwSwEykaGx+J/3ocfz94awjsWgq91F3uvXxeI0z7G2OKnxb A6fwMZHGB7DTtQekddCgtjnUU1bJqpsiDyTeUrLMFYkmrVWdm/tQsnt/JlW8KFj5goEe iCgL2pt0TY342g1toVoPrgHRx/3vSHEG2XjYuyWVcL4LEHVbVuUeb8pnO4vdZnMhg4Zf AJYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :references:in-reply-to:date:cc:to:from:subject:message-id :arc-authentication-results; bh=bE15xqHqVKOZ1qMAJ38EZrJRu0dYlJ0chGPYl5us8Sw=; b=cZ5KyeRO6v32zifYtLEYkZeXy/OYLtS67snfGaIaIn1UlyfNAeXR7Gs2DrdyBykaVQ cOn7OEK3uj9ge9lXqzXdka4JNgrOlPZyRa2stKOMhBx/l1yZnE5qg/XO0p2HqIEELvtL cvqBDP6oA0noQMni5ksxSg0JilLzvtLR4ASuRVVMEofuztqm/GSAewHGlL5fMccUGlPF YbA0UJkISgVjtELotxZnrykxOfqPVF7Vmp5QNpwSHvR/hSHra0oicQw9Pppax0POLY6f //Ci+3Zhkl8ilAE+MEX3f/N+4YDrN34Gfl5ungA/AORR35ZFwubDLMoC9pZIYLCfr4CH jZgg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l26-v6si3385358pfj.188.2018.07.18.06.35.14; Wed, 18 Jul 2018 06:35:29 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731104AbeGROLd (ORCPT + 99 others); Wed, 18 Jul 2018 10:11:33 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:14322 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726990AbeGROLd (ORCPT ); Wed, 18 Jul 2018 10:11:33 -0400 X-UUID: c34cae72afa14a1a91fa2ccffa541892-20180718 Received: from mtkcas07.mediatek.inc [(172.21.101.84)] by mailgw02.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 2097678855; Wed, 18 Jul 2018 21:33:22 +0800 Received: from MTKMBS06N2.mediatek.inc (172.21.101.130) by mtkmbs02n1.mediatek.inc (172.21.101.77) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 18 Jul 2018 21:33:21 +0800 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs06n2.mediatek.inc (172.21.101.130) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 18 Jul 2018 21:33:20 +0800 Received: from [172.21.77.33] (172.21.77.33) by mtkcas08.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1210.3 via Frontend Transport; Wed, 18 Jul 2018 21:33:20 +0800 Message-ID: <1531920800.8953.151.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: Wed, 18 Jul 2018 21:33:20 +0800 In-Reply-To: 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> <1531757114.8953.12.camel@mtkswgap22> 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 Wed, 2018-07-18 at 14:14 +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]. > > it is generally useful so that it gets reported out in btmon and thus it can assign the correct vendor specific decoder. However you better set hdev->manufacturer = 70 in the probe() routine before calling hci_register_dev. You have a dedicated driver and thus will always know it. > > The core tries to figure this out at some point, but then you are missing btmon decoding for the earlier messages. See btusb.c and how other drivers set it early on. > thank for the point up, I will set hdev->manufacturer as 70 in probe routine before calling hci_register_dev in the next version. > Regards > > Marcel > > > _______________________________________________ > Linux-mediatek mailing list > Linux-mediatek@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek