netdev - Re: [PATCH 3/8] dt-bindings: net: bluetooth: Add rtl8723bs-bluetooth

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: <CAFBinCDFY+fZs2unV1T5Mhh_VVSUfxK75zZXKdanLKG+arRX5g@mail.gmail.com>
Date:   Sat, 2 Mar 2019 17:43:58 +0100
From:   Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To:     陆朱伟 <alex_lu@...lsil.com.cn>
Cc:     "anarsoul@...il.com" <anarsoul@...il.com>,
        "beagleboard@...idjohnsummers.uk" <beagleboard@...idjohnsummers.uk>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "johan.hedberg@...il.com" <johan.hedberg@...il.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-bluetooth@...r.kernel.org" <linux-bluetooth@...r.kernel.org>,
        "marcel@...tmann.org" <marcel@...tmann.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "maxime.ripard@...tlin.com" <maxime.ripard@...tlin.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "robh@...nel.org" <robh@...nel.org>,
        "stefan.wahren@...e.com" <stefan.wahren@...e.com>,
        "wens@...e.org" <wens@...e.org>
Subject: Re: [PATCH 3/8] dt-bindings: net: bluetooth: Add rtl8723bs-bluetooth

Hi Alex,

On Sat, Mar 2, 2019 at 10:30 AM 陆朱伟 <alex_lu@...lsil.com.cn> wrote:
>
> Hi Martin,
> Thanks for your information.
thank you for the quick reply!

> The config is related to eFuse in chips. I'm sorry that the details can't be open.
> Only some special configurations are related to the host platforms, such as UART working baudrate, hardware flow control, PCM settings, etc. These are the settings for HCI UART and PCM Interface.
> Most of configurations are only relevant to chips.
please let me repeat this with my own words to see if I understand the
"config blob" correctly. Feel free to correct me if anything is wrong:
- the data in the config blob "patches" eFuse values at runtime (non-persistent)
- we know the offsets of the UART_CONFIG, PCM_SETTING and BD_ADDR -
these can be "board specific" (like baud rate, flow control, ...)
- most other values from the "config blob" are "chip specific" -
meaning they are identical for each board and they only depend on the
chip

do you have any suggestions how we can support multiple boards (the
main goal of this whole discussion is: how to do this "correct")?
so far different approaches were discussed (not only in this thread,
but also in the past):
- use a separate config blob for each board. this means that whenever
a new board is supported (for example by adding a .dts for it to the
mainline kernel) then Bluetooth won't work out-of-the-box unless a
config is provided.
- specify the properties of the connection to the chip (for example by
adding a device-tree property for the speed, flow control, ...) and
generate the config based on the device-tree properties.
- (I am open for other suggestions, please let us know if you have any)

I would like to hear your opinion on this topic and especially the
reasons behind your suggestions.


Best regards
Martin