linux-kernel - Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via serdev/devicetree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 13 Nov 2018 17:01:28 +0100
From:   Andreas Kemnade <andreas@...nade.info>
To:     Rob Herring <robh@...nel.org>
Cc:     sebastian.reichel@...labora.com, hns@...delico.com,
        devicetree@...r.kernel.org, johan.hedberg@...il.com,
        marcel@...tmann.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-bluetooth@...r.kernel.org, letux-kernel@...nphoenux.org
Subject: Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via
 serdev/devicetree

On Mon, 12 Nov 2018 18:17:38 -0600
Rob Herring <robh@...nel.org> wrote:

> On Mon, Nov 12, 2018 at 4:27 PM Sebastian Reichel
> <sebastian.reichel@...labora.com> wrote:
> >
> > Hi,
> >
> > On Mon, Nov 12, 2018 at 10:19:02PM +0100, H. Nikolaus Schaller wrote:  
> > > > Am 12.11.2018 um 21:59 schrieb Andreas Kemnade <andreas@...nade.info>:
> > > > On Sun, 11 Nov 2018 03:46:48 +0100
> > > > Sebastian Reichel <sebastian.reichel@...labora.com> wrote:  
> > > >> On Sun, Nov 11, 2018 at 12:20:34AM +0100, Andreas Kemnade wrote:  
> > > >>> This is a first try to be able to use h4 devices specified in
> > > >>> the devicetree, so you do not need to call hciattach and
> > > >>> it can be automatically probed.
> > > >>>
> > > >>> Of course, proper devicetree bindings documentation is
> > > >>> missing. And also you would extend that by regulator/
> > > >>> enable gpio settings.
> > > >>>
> > > >>> But before proceeding further it should be checked if the
> > > >>> general way of doing things is right.
> > > >>>
> > > >>> Signed-off-by: Andreas Kemnade <andreas@...nade.info>
> > > >>> ---  
> > > >>
> > > >> Patch looks good to me, just one note
> > > >>  
> > > > I found one thing myself:
> > > > Shouldn't we have a generic compatible string like "generic-h4".
> > > > ehci-platform.c has for example:
> > > >        { .compatible = "generic-ehci", },  
> > >
> > > There might be differences in h4 compatible devices (e.g. default
> > > baud rate) so that I would not bet there a "generic-h4" suffices
> > > in the long run.  
> 
> It will not because that doesn't define clocks, resets, gpios,
> supplies, etc. and the interactions of all those.
> 
well, we need a simple supply being on when the device is on.
Nothing more.

> > My suggestion is to use this in DT:
> >
> > compatible = "wi2wi,w2cbw003-bluetooth", "<something generic>";
> >
That would be my slight preference here.

> > The driver can start with supporting just the generic compatible
> > string. If somebody finds some incompatible differences, the driver
> > can add a custom handler for the wi2wi chip without breaking DT
> > ABI.  
> 
> Any idea how many H4 devices there are? Somehow I doubt there are that
> many to be unmanageable.
> 
Well, many devices are h4 devices with some more or less important
vendor-specific commands. Well, "hciattach any" uses simple h4 protocol.

those firmware download commands and they have their own drivers.
Most devices I had used bluetooth uart from the command line with, were
simple enough. The other question is whether those devices will run a
modern kernel.

No strong opinion here. 

Regards,
Andreas

Content of type "application/pgp-signature" skipped