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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Mon, 12 Nov 2018 22:19:02 +0100
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Andreas Kemnade <andreas@...nade.info>
Cc:     Sebastian Reichel <sebastian.reichel@...labora.com>,
        devicetree <devicetree@...r.kernel.org>,
        Johan Hedberg <johan.hedberg@...il.com>,
        Marcel Holtmann <marcel@...tmann.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "open list:BLUETOOTH DRIVERS" <linux-bluetooth@...r.kernel.org>,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>
Subject: Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via serdev/devicetree

> Am 12.11.2018 um 21:59 schrieb Andreas Kemnade <andreas@...nade.info>:
> 
> Hi,
> 
> On Sun, 11 Nov 2018 03:46:48 +0100
> Sebastian Reichel <sebastian.reichel@...labora.com> wrote:
> 
>> Hi,
>> 
>> 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.

And, shouldn't there be a vendor prefix anyways?

I.e. something like "bluetooth,h4"? Because it seems to be defined in
https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=41266

On the other hand, with hci-ll protocol the compatible strings are chip variants.
Well, this seems to be required to decide which firmware to download.

So it boils down to if DT compatibility should be compatible to generic
functions or specific chips? AFAI see this is more or less random and
there seems to be no general rule.

Just some thoughts but no strong preference.

BR,
Nikolaus