linux-kernel - Re: [PATCH] Bluetooth: btrsi: rework dependencies

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] [day] [month] [year] [list]

Date:   Thu, 15 Mar 2018 17:03:52 +0100
From:   Marcel Holtmann <marcel@...tmann.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Johan Hedberg <johan.hedberg@...il.com>,
        Kalle Valo <kvalo@...eaurora.org>,
        Linux Bluetooth mailing list 
        <linux-bluetooth@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-wireless <linux-wireless@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>
Subject: Re: [PATCH] Bluetooth: btrsi: rework dependencies

Hi Arnd,

>>> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
>>> index 03cfc1b20c4a..9e8d22712ff3 100644
>>> --- a/drivers/bluetooth/Makefile
>>> +++ b/drivers/bluetooth/Makefile
>>> @@ -28,7 +28,7 @@ obj-$(CONFIG_BT_QCA)                += btqca.o
>>> 
>>> obj-$(CONFIG_BT_HCIUART_NOKIA)        += hci_nokia.o
>>> 
>>> -obj-$(CONFIG_BT_HCIRSI)              += btrsi.o
>>> +obj-$(CONFIG_BT_HCIRSI_MODULE)       += btrsi.o
>> 
>> do we need this new option? I have avoided these kind of complex things multi config entries. Can we not just select the RSI_91X?
>> 
> 
> I couldn't come up with a simpler way to do this.
> Selecting RSI_91X is not possible unless we make the BT
> driver 'depend on WLAN_VENDOR_RSI && MAC80211',
> which is even more backwards.
> 
> The problem here is that it's actually a reverse dependency:
> the wlan driver calls into the bt driver.
> 
> What we could do is to make BT_HCIRSI a silent symbol
> and have that selected by RSI_COEX, which can then
> be user-visible. With that, the Kconfig structure would follow
> what the code does.

that sounds a bit better to me. If the RSI driver maintainers don’t like that, then they should re-architect the code to make this more dynamic and flexible.

Regards

Marcel