Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <GV0P278MB0129C9B8851F33EE8C3BA54095B99@GV0P278MB0129.CHEP278.PROD.OUTLOOK.COM>
In-Reply-To: <GV0P278MB0129C9B8851F33EE8C3BA54095B99@GV0P278MB0129.CHEP278.PROD.OUTLOOK.COM>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Mon, 27 Jun 2022 15:21:25 -0700
Message-ID: <CABBYNZLtL=MTCDka3xhMfhxfEHpzaY=bSn_Zat_=HD54=JhRVg@mail.gmail.com>
Subject: Re: BlueZ bluetooth qualification
To:     Isak Westin <karl.westin@loytec.com>
Cc:     "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>,
        Tedd Ho-Jeong An <hj.tedd.an@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Isak,

On Mon, Jun 27, 2022 at 5:32 AM Isak Westin <karl.westin@loytec.com> wrote:
>
> Hi,
>
> My company wants to release a product where the BlueZ daemons are running as a host subsystem (both bluetoothd and bluetooth-meshd). So the product needs to be qualified.
> I have looked on the web-page and searched in the archive of this mailing list but didn't really find any up-to-date information about this. So I wanted to ask if you have some new information that could help.
> What are the general guidelines to qualify a product that is using the BlueZ stack? Is there a version that is already qualified that can be referred to? Or is the best way to qualify it ourselves using PTS testing?

Upstream don't qualify BlueZ by itself, usually it is the individual
companies that qualify it based on the kernel and userspace version
they intend to use. That said we do want to properly support the likes
of auto-pts with BlueZ to automate the process of qualifying with PTS,
and perhaps in the future even use it with our CI if we managed to
emulate the PTS environment inside github.

@Tedd Ho-Jeong An can you update Isak where we stand regarding using
auto-pts with BlueZ?

-- 
Luiz Augusto von Dentz