linux-kernel - Re: [PATCH v4 1/2] Bluetooth: Add device_get_bd

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:   Mon, 22 Oct 2018 23:07:07 +0200
From:   Pavel Machek <pavel@....cz>
To:     Marcel Holtmann <marcel@...tmann.org>
Cc:     Matthias Kaehlcke <mka@...omium.org>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Sinan Kaya <okaya@...eaurora.org>,
        Balakrishna Godavarthi <bgodavar@...eaurora.org>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Marcin Wojtas <mw@...ihalf.com>,
        Andy Shevchenko Andy Shevchenko <andy.shevchenko@...il.com>,
        Johan Hedberg <johan.hedberg@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Bluez mailing list <linux-bluetooth@...r.kernel.org>,
        Loic Poulain <loic.poulain@...aro.org>,
        Brian Norris <briannorris@...omium.org>
Subject: Re: [PATCH v4 1/2] Bluetooth: Add device_get_bd_address()

Hi!

> >> explain to me again why this is useful?
> > 
> > The official binding for providing the BD_ADDR through the device tree
> > is the property 'local-bd-address'. device_get_bd_address() provides a
> > common API to retrieve the BD_ADDR instead of requiring BT drivers to
> > use the lower level fwnode_property_read_u8_array(). It also avoids
> > repeating the check for an all zeroes BD_ADDR in multiple drivers.
> > 
> >> I am failing to see the benefit if this is not part of the property.h API.
> > 
> > My understanding is that the intention of property.h it to provide an
> > API for common property types used by drivers from different
> > subsystems, hence the implementation 'lives' in drivers/base.
> > Obtaining the BD_ADDR is clearly limited to the Bluetooth subsystem,
> > and drivers/base doesn't seem to be the right place for it. It's true,
> > device_get_mac_address() lives in the common property code, but that
> > doesn't necessarily mean it really should be there and we should do
> > the same. I agree with Sakari that the the approach taken by V4L2
> > (drivers/media/v4l2-core/v4l2-fwnode.c) seems more appropriate.
> > 
> > That said I wouldn't raise opposition if the maintainers of
> > drivers/base agreed to add device_get_mac_address() there, however so
> > far several recent authors of property.[ch] have raised objections.
> 
> so if this is not in drivers/base/ then what is the point in making each driver do this? If it is a common property, then it can be well handled in the Bluetooth core when setting up the hardware.
> 
> This whole BD_ADDR via DT is stupid anyway. Just so that is clear
> up-front. It has been a total hack and fully relies on boot
> loaders doing too much magic and then using DT to hide this magic.

Can you wrap lines at around 72 characters in the emails?

We do ethernet addresses via DT. I don't know if doing that in
bootloader is a hack or not, but if bootloader is already doing that
for ethernet, bluettoth address in DT kind of makes sense.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)