linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthias Kaehlcke <mka@chromium.org>
To: Marcel Holtmann <marcel@holtmann.org>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sinan Kaya <okaya@codeaurora.org>,
	Balakrishna Godavarthi <bgodavar@codeaurora.org>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Marcin Wojtas <mw@semihalf.com>,
	Andy Shevchenko Andy Shevchenko <andy.shevchenko@gmail.com>,
	Johan Hedberg <johan.hedberg@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Bluez mailing list <linux-bluetooth@vger.kernel.org>,
	Loic Poulain <loic.poulain@linaro.org>,
	Brian Norris <briannorris@chromium.org>
Subject: Re: [PATCH v4 1/2] Bluetooth: Add device_get_bd_address()
Date: Mon, 15 Oct 2018 11:51:28 -0700	[thread overview]
Message-ID: <20181015185128.GT22824@google.com> (raw)
In-Reply-To: <9B742DB5-F584-4A47-A04B-4F72EB17519C@holtmann.org>

On Mon, Oct 15, 2018 at 08:06:02PM +0200, Marcel Holtmann wrote:
> Hi Matthias,
> 
> >>>>  void bt_sock_reclassify_lock(struct sock *sk, int proto);
> >>>> 
> >>>> +int device_get_bd_address(struct device *dev, bdaddr_t *bd_addr);
> >>> 
> >>> Maybe change the API name to start with bt_ and get rid of device_?
> >> 
> >> device_ indicates that we get the BD_ADDR for a 'struct device' and
> >> not for e.g. a 'struct fwnode_handle'.
> >> 
> >> Anyway with this version of the patch fwnode_get_bd_address() has been
> >> scrapped and it might never be introduced again, so I'm open to change
> >> the name to bt_ if there is a general preference for it.
> > 
> > Marcel, can you live with this being added to the Bluetooth code base
> > instead of property? Also if you'd prefer the function to be named
> > bt_get_bd_address() let me know.
> 
> 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.

Thanks

Matthias

  reply	other threads:[~2018-10-15 18:51 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-27  0:48 [PATCH v4 0/2] Add API to retrieve the Bluetooth Device Address (BD_ADDR) Matthias Kaehlcke
2018-09-27  0:48 ` [PATCH v4 1/2] Bluetooth: Add device_get_bd_address() Matthias Kaehlcke
2018-09-27  6:50   ` Sakari Ailus
2018-09-27 16:41   ` Balakrishna Godavarthi
2018-09-27 16:47     ` Sinan Kaya
2018-09-27 17:13       ` Matthias Kaehlcke
2018-10-04 17:33         ` Matthias Kaehlcke
2018-10-15 18:03           ` Matthias Kaehlcke
2018-10-15 18:06           ` Marcel Holtmann
2018-10-15 18:51             ` Matthias Kaehlcke [this message]
2018-10-16  6:52               ` Marcel Holtmann
2018-10-16 21:02                 ` Matthias Kaehlcke
2018-10-22 21:07                 ` Pavel Machek
2018-09-27  0:48 ` [PATCH v4 2/2] Bluetooth: btqcomsmd: Get the BD address with device_get_bd_address() Matthias Kaehlcke
2018-09-27 16:43   ` Balakrishna Godavarthi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181015185128.GT22824@google.com \
    --to=mka@chromium.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=bgodavar@codeaurora.org \
    --cc=briannorris@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=johan.hedberg@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=loic.poulain@linaro.org \
    --cc=marcel@holtmann.org \
    --cc=mw@semihalf.com \
    --cc=okaya@codeaurora.org \
    --cc=rafael@kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).