Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20200401221320.12105-1-sonnysasaka@chromium.org> <6A574E50-BBF3-4967-9C93-6F4B6DAFB47D@holtmann.org>
In-Reply-To: <6A574E50-BBF3-4967-9C93-6F4B6DAFB47D@holtmann.org>
From:   Sonny Sasaka <sonnysasaka@chromium.org>
Date:   Thu, 9 Apr 2020 14:05:40 -0700
Message-ID: <CAO271m=Rqq7QS6R362xLQWjbo6_ZLYPo-ttvevJmjqJ73HbAVQ@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

Thanks for the feedback, Marcel. Will come back with the modified
patches based on your suggestions.

On Thu, Apr 9, 2020 at 11:12 AM Marcel Holtmann <marcel@holtmann.org> wrote=
:
>
> Hi Sonny,
>
> > This allows us to gather information about whether a device
> > supports BR/EDR, BLE, or both. It appears as DBus Property
> > "Type" on the org.bluez.Device1 interface.
> > ---
> > doc/device-api.txt |  5 +++++
> > src/device.c       | 31 +++++++++++++++++++++++++++++++
> > 2 files changed, 36 insertions(+)
>
> my preference is not to combine API documentation patches with code.
>
> >
> > diff --git a/doc/device-api.txt b/doc/device-api.txt
> > index 65d8fee37..ceb68d2f6 100644
> > --- a/doc/device-api.txt
> > +++ b/doc/device-api.txt
> > @@ -158,6 +158,11 @@ Properties       string Address [readonly]
> >
> >                       The Bluetooth class of device of the remote devic=
e.
> >
> > +             string Type [readonly, optional]
> > +
> > +                     The carriers supported by this remote device. If =
it
> > +                     exists, it can be one of "BR/EDR", "LE", or "DUAL=
".
> > +
>
> So all values need to be lower case. That is just how we design all API.
>
> If we do this, then I think the name =E2=80=9CBearer=E2=80=9D might be be=
tter. Also it might be better as array{string} actually.
>
> Regards
>
> Marcel
>