From: Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: "John W. Linville" <linville@tuxdriver.com>,
"linux-wireless@vger.kernel.org Wireless"
<linux-wireless@vger.kernel.org>,
Johannes Berg <johannes@sipsolutions.net>,
"David S. Miller" <davem@davemloft.net>,
Network Development <netdev@vger.kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] allow setting wiphy.perm_addr after driver probe
Date: Mon, 11 Aug 2014 13:40:45 -0700 [thread overview]
Message-ID: <1407789645.28221.68.camel@chimera> (raw)
In-Reply-To: <54DF22CF-59D7-4633-A625-896F58C26A64@holtmann.org>
On Mon, 2014-08-11 at 13:25 -0700, Marcel Holtmann wrote:
> isn't this dangerous to just allow writing to wiphy.perm_addr via
> sysfs. We ran into the same issue with Bluetooth and ROM only devices
> that have to unique address. Doing this via sysfs seems the wrong
> approach. It is messy and full of potential race conditions. I clearly
> opted against the sysfs solution for Bluetooth. Instead we build an
> infrastructure that allowed doing it cleanly via the Bluetooth mgmt
> API. Controllers that have no unique address are brought up as
> unconfigured and userspace clearly knows that it has to take steps to
> get an address programmed into the controller.
My inclination is to agree; however, this does not exist for WiFi and
implementing it would require modifying every single driver.
> And I think something similar should be done for WiFi. It might be
> better to not create the initial wlan0 netdev interface if the
> hardware has not a single unique address available. That way the
> supplicant can just either get one from the flash filesystem or make
> up a proper random one before creating the netdev interface.
>
The initial wlan0 netdev interface is *not* created, but the PHY records
a MAC address that cannot be overriden at the level that this sysfs node
reads. Perhaps a compromise would be to create a single new syscall to
write to it?
next prev parent reply other threads:[~2014-08-11 20:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-11 18:04 [PATCH] allow setting wiphy.perm_addr after driver probe Daniel Gimpelevich
2014-08-11 20:25 ` Marcel Holtmann
2014-08-11 20:40 ` Daniel Gimpelevich [this message]
2014-08-11 20:56 ` Marcel Holtmann
2014-08-11 21:04 ` Daniel Gimpelevich
2014-08-11 22:41 ` Marcel Holtmann
2014-08-11 23:12 ` Daniel Gimpelevich
2014-08-11 23:56 ` Marcel Holtmann
[not found] ` <52896C9C-8560-4CE4-A1FB-C896D766EC87-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
2014-08-12 0:01 ` Daniel Gimpelevich
2014-08-12 7:59 ` Marcel Holtmann
[not found] ` <70001DBA-E1CE-49D6-9A37-6F7CE31B61E6-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
2014-08-12 8:43 ` Jonas Gorski
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=1407789645.28221.68.camel@chimera \
--to=daniel@gimpelevich.san-francisco.ca.us \
--cc=davem@davemloft.net \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=marcel@holtmann.org \
--cc=netdev@vger.kernel.org \
/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).