From patchwork Tue Apr 23 07:22:34 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?UTF-8?q?Jo=C3=A3o=20Paulo=20Rechi=20Vita?= X-Patchwork-Id: 1089108 Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="EFaacJws"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 44pFKm3VZCz9s9G for ; Tue, 23 Apr 2019 17:23:24 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726045AbfDWHXB (ORCPT ); Tue, 23 Apr 2019 03:23:01 -0400 Received: from mail-pf1-f196.google.com ([209.85.210.196]:32911 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725888AbfDWHXB (ORCPT ); Tue, 23 Apr 2019 03:23:01 -0400 Received: by mail-pf1-f196.google.com with SMTP id h5so7015475pfo.0; Tue, 23 Apr 2019 00:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=8xa1xSFB3woawtkgAJlIMcQ2+F4nty/W9uui7RIpeaU=; b=EFaacJwsUk+vTVfhJB7Q885rzGo/I3oqbznSZEDuRxAfKvo/IQ75lK4fj6hnEBAkOp IPH1JD+HpJFvby3TxLbhZT0DriGU33IpVAaV9wfA+i+DRimjyzPu5tbUzhd543iWGzQ+ JZI3c+17H/erXdOi+cu0Vo7Zsmv9rOOFkAayU38a7+9wz/cyHYZ6yS3bh4AP2g0Mx+iX JxlYwzQYH591RwCgOfnrQseiHmkYmUBhki4Cn4aUvAH9OhOBN/Wel1w5ZeNwk/pnQrwR FVUgmVgMZwSYGzgV0P7GT5fiqtMyKZSq8LD4WPrwVkJhRdrz7DOQOM/AIoHF7dByiBJC 6u7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=8xa1xSFB3woawtkgAJlIMcQ2+F4nty/W9uui7RIpeaU=; b=HZ6zsgk8yW/eB57klpCzLj+RfvhykXSXag7Hb6oCrxF3gwpLNVglQVqVVH1klJU0hC Ou5uP9jb+/jTfKu65A/oZ2bgcOn/RGKa3OJBeZfEo2ymE9bK9/7jYxwSDL12tgt48gc7 KmvTIadi8LBwddJpFwKOj+VrQx7xABszK2SmjU5ubrn6oKKpw0n0BvGC6/Xp9x840sxz Bui/SLTYfXvhx+8a7bfzAhxAGRpvO4WpeAhjEeFD8kCqQl99nrcxvfGv4iii+38nj5P/ WBMs9O+88jjQ4JtjSGxyTjyyEAAALOhuxHQZDTQn8fSEiPIWxN6qe6ND1TpAHIqwItTX MWdw== X-Gm-Message-State: APjAAAUhB+B+dFkblUzIZeO4iYPGLsT8/ujeRf76oBGu/3YdPP3SIMpy AdpYZhrVD0Ec3NbdolSQlEo= X-Google-Smtp-Source: APXvYqybzLnEa5MjKxK0gPyTtQNZd/ryYQVqjH+s1Q9TxU4c7EdfvW1Xbg35crtrCoU5JccmELHC/Q== X-Received: by 2002:aa7:9465:: with SMTP id t5mr25309442pfq.247.1556004178993; Tue, 23 Apr 2019 00:22:58 -0700 (PDT) Received: from localhost.localdomain (123-204-46-122.static.seed.net.tw. [123.204.46.122]) by smtp.gmail.com with ESMTPSA id p20sm12560594pgj.86.2019.04.23.00.22.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Apr 2019 00:22:58 -0700 (PDT) From: "=?UTF-8?q?Jo=C3=A3o=20Paulo=20Rechi=20Vita?=" X-Google-Original-From: =?utf-8?q?Jo=C3=A3o_Paulo_Rechi_Vita?= To: Marcel Holtmann , Johan Hedberg Cc: bgodavar@codeaurora.org, ytkim@qca.qualcomm.com, "David S . Miller" , linux-bluetooth@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux@endlessm.com, =?utf-8?q?Jo=C3=A3o_Paulo_Rechi_Vita?= Subject: [PATCH 0/2] Quirk to enable QCA9377 to discover BLE devices Date: Tue, 23 Apr 2019 15:22:34 +0800 Message-Id: <20190423072236.24999-1-jprvita@endlessm.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org As reported previously on [1], it is currently not possible to discover BLE devices with QCA9377 controllers. When trying to start an active scanning procedure with this controller, three commands are queued, LE_SET_RANDOM_ADDR, LE_SET_SCAN_PARAM and LE_SET_SCAN_ENABLE. After the first command is sent to the controller, a command complete event for it is received, and the second command is sent, an extra command complete for the first command is received. At this point the kernel sends the next command and fails to process the command complete event for the LE_SET_SCAN_PARAM command, because when it arrives it does not match the last command that was sent. This makes hdev->le_scan_type never be updated and the kernel behaves as if a passive scanning procedure was being performed, thus no device found events are sent to userspace. [1] https://www.spinics.net/lists/linux-bluetooth/msg79102.html I have received no replies on the previous report and on further attempts to contact the QCA addresses that have submitted Bluetooth firmware blobs to linux-firmware upstream. This series avoids the problem described above, but I believe ideally the controller should not be sending this extra command complete event. I'm not 100% sure if the approach taken here is the best way to work around this problem in the kernel, as I am not super familiar with the HCI layer. I'll be happy to hear suggestions of better approaches. Full logs from btmon can be found bellow this message, and the extra command complete event can be seen at timestamp 27.420131. Best regards, João Paulo Rechi Vita (2): Bluetooth: Create new HCI_QUIRK_WAIT_FOR_MATCHING_CC Bluetooth: Set HCI_QUIRK_WAIT_FOR_MATCHING_CC for QCA9377 drivers/bluetooth/btusb.c | 9 +++++++++ include/net/bluetooth/hci.h | 4 ++++ include/net/bluetooth/hci_core.h | 1 + net/bluetooth/hci_core.c | 3 +++ net/bluetooth/hci_event.c | 4 ++++ 5 files changed, 21 insertions(+)