From: Michael Buesch <mb@bu3sch.de>
To: Larry Finger <Larry.Finger@lwfinger.net>
Cc: John W Linville <linville@tuxdriver.com>,
bcm43xx-dev@lists.berlios.de, linux-wireless@vger.kernel.org
Subject: Re: [PATCH V3] ssb: Implement virtual SPROM
Date: Tue, 23 Mar 2010 23:09:26 +0100 [thread overview]
Message-ID: <201003232309.26527.mb@bu3sch.de> (raw)
In-Reply-To: <4ba912f2./S7YyAUZdz6Kx4tH%Larry.Finger@lwfinger.net>
On Tuesday 23 March 2010 20:13:54 Larry Finger wrote:
> Some recent BCM43XX devices lack an on-board SPROM. The pertinent data
> from the SPROM could be included in the kernel; however, this presents
> a problem in the generation of a unique, reproducible MAC address. The
> solution is to use a file in /lib/firmware/ssb, which has some "random"
> information generated by /bin/dbus-uuidgen. This file is loaded using the
> asynchronous firmware facility and a MAC address is generated from those
> data. To prevent multiple devices in a single box from having the same
> MAC address, the last two digits are replaced by the bus numbers of the
> device.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
>
> John,
>
> Unless someone comes up with a unique way to generate a MAC address using
> only udev rules, I think this is ready.
Please take a look at Calvin Walton's RFC.
It would avoid the need for abusing the firmware loading mechanism.
> + /* Input MAC address data in ASCII - get low nibble in binary */
> + for (i = 0 ; i < 8; i++) {
> + u8 tmp = ascii_to_bin(fw->data[2 * i]);
> + u8 tmp1 = ascii_to_bin(fw->data[2 * i + 1]);
> + buf2[i] = tmp << 4 | tmp1;
> + }
You would basically initialize the mac address to FFFFFFFFFFFF here and
udev would take care of the rest.
> static int ssb_pci_sprom_get(struct ssb_bus *bus,
> struct ssb_sprom *sprom)
> {
> @@ -620,8 +735,18 @@ static int ssb_pci_sprom_get(struct ssb_
> int err = -ENOMEM;
> u16 *buf;
>
> - if (!ssb_is_sprom_available(bus))
> - return -ENODEV;
> + if (!ssb_is_sprom_available(bus)) {
> + /* This device has no SPROM. Try for a random MAC address */
> + err = request_firmware_nowait(THIS_MODULE,
> + FW_ACTION_HOTPLUG, "ssb/mac_addr",
> + &bus->host_pci->dev, GFP_KERNEL, bus,
> + ssb_get_vsprom);
Well, I'm not sure how this is supposed to work. What happens if a part of ssb
or b43 uses the SPROM data structure, but ssb_get_vsprom() didn't run, yet?
So: Get rid of the firmware fetching stuff completely and do it via udev.
It reduces the headache by a few magnitudes of headachenesses.
> + if (err) {
> + ssb_vsprom_load_failed();
> + return err;
> + }
> + return 0;
> + }
>
> buf = kcalloc(SSB_SPROMSIZE_WORDS_R123, sizeof(u16), GFP_KERNEL);
> if (!buf)
--
Greetings, Michael.
prev parent reply other threads:[~2010-03-23 22:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-23 19:13 [PATCH V3] ssb: Implement virtual SPROM Larry Finger
2010-03-23 22:09 ` Michael Buesch [this message]
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=201003232309.26527.mb@bu3sch.de \
--to=mb@bu3sch.de \
--cc=Larry.Finger@lwfinger.net \
--cc=bcm43xx-dev@lists.berlios.de \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.