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: <20200401221320.12105-1-sonnysasaka@chromium.org>
 <6A574E50-BBF3-4967-9C93-6F4B6DAFB47D@holtmann.org> <CAO271m=Rqq7QS6R362xLQWjbo6_ZLYPo-ttvevJmjqJ73HbAVQ@mail.gmail.com>
 <68C2E4A8-29E0-44D8-9D2F-F4E2354DE419@holtmann.org>
In-Reply-To: <68C2E4A8-29E0-44D8-9D2F-F4E2354DE419@holtmann.org>
From:   Sonny Sasaka <sonnysasaka@chromium.org>
Date:   Tue, 19 May 2020 16:12:48 -0700
Message-ID: <CAOxioNkw8g90tVwQjqgdpX38__f17JHHTTsqBZwCjEkjME0Zyg@mail.gmail.com>
Subject: Re: [PATCH] device: Add device type property
To:     Marcel Holtmann <marcel@holtmann.org>
Cc:     Bluez mailing list <linux-bluetooth@vger.kernel.org>,
        Eric Caruso <ejcaruso@chromium.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Marcel,

After giving it more thought, I would like to propose that this
additional property corresponds with Device Type as defined in Generic
Access Profile:

As stated in Bluetooth Core Specification Version 5.2, Vol 3, Part C
(Generic Access Profile):
This profile defines three device types based on the supported Core
Configurations as defined in [Vol 0] Part B, Section 3.1. The device
types are shown in Table 1.1:
* BR/EDR
* LE only
* BR/EDR/LE

Therefore, to be as close to the spec as possible, I propose that the
property be named GAPDeviceType, and the possible values be "br/edr",
"le-only", "br/edr/le".

What do you think? Thanks for reviewing this proposal!

On Thu, Apr 9, 2020 at 11:51 PM Marcel Holtmann <marcel@holtmann.org> wrote=
:
>
> Hi Sonny,
>
> > Thanks for the feedback, Marcel. Will come back with the modified
> > patches based on your suggestions.
>
> I also meant to write that the name =E2=80=9CBearer=E2=80=9D might not be=
 the best either. I am open for suggestions. Also if it is an array, it nee=
ds to be plural of course. If we start exposing BR/EDR vs LE or its combina=
tion (and we might also consider HS even while not used these days), then w=
e need to be consistent with our terminology across the APIs.
>
> Regards
>
> Marcel
>