Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200430145105.Bluez.v1.1.I86c1e0e8933d92d8d76dcd95036bf325cfaeced0@changeid>
 <CABBYNZL_rOVYs-3W8DZn_ugh-c23r+H4qjmBi55t3Rd-iZCW-Q@mail.gmail.com>
In-Reply-To: <CABBYNZL_rOVYs-3W8DZn_ugh-c23r+H4qjmBi55t3Rd-iZCW-Q@mail.gmail.com>
From:   Archie Pusaka <apusaka@google.com>
Date:   Tue, 5 May 2020 12:37:15 +0800
Message-ID: <CAJQfnxEjQzLZVOG5nWnSdK_gxgat7BCdywoz1gNsocNRNHSOxg@mail.gmail.com>
Subject: Re: [Bluez PATCH v1] tools/l2cap-tester: Add test for waiting
 disconnection response
To:     Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc:     linux-bluetooth <linux-bluetooth@vger.kernel.org>,
        Marcel Holtmann <marcel@holtmann.org>,
        Archie Pusaka <apusaka@chromium.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Luiz,

> Id make the test abort if cannot be disconnected properly, but it
> looks like we don't have any means to detect if the kernel has support
> for it or not, but perhaps it is fine since this is trying to test the
> right behavior.
>
Yeah, currently we have no way of knowing whether the kernel supports
this behavior or not. If we really want to, perhaps we can add
something to query that, but I doubt that is worth the hassle.