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]
Message-Id: <2C74C837-A6D3-47C9-BE59-CCA594289B94@goldelico.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ