| Message ID | 1386494714-21070-16-git-send-email-pali.rohar@gmail.com |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | David Miller |
| Headers | show |
Pali Rohár <pali.rohar@gmail.com> writes: > Driver wl1251 generating mac address randomly at startup and there is no way to > set permanent mac address via SET_IEEE80211_PERM_ADDR. This patch export sysfs > file which can set permanent mac address by userspace helper program. Patch is > needed for devices which do not store mac address in internal wl1251 eeprom. > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com> We have ioctl() command for setting the mac address.
On Tuesday 10 December 2013 16:49:23 Kalle Valo wrote: > Pali Rohár <pali.rohar@gmail.com> writes: > > Driver wl1251 generating mac address randomly at startup and > > there is no way to set permanent mac address via > > SET_IEEE80211_PERM_ADDR. This patch export sysfs file which > > can set permanent mac address by userspace helper program. > > Patch is needed for devices which do not store mac address > > in internal wl1251 eeprom. > > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com> > > We have ioctl() command for setting the mac address. Really? Is there ioctl for setting permanent mac address? Can you show me it?
On Tuesday 10 December 2013 17:10:50 Pali Rohár wrote: > On Tuesday 10 December 2013 16:49:23 Kalle Valo wrote: > > Pali Rohár <pali.rohar@gmail.com> writes: > > > Driver wl1251 generating mac address randomly at startup > > > and there is no way to set permanent mac address via > > > SET_IEEE80211_PERM_ADDR. This patch export sysfs file > > > which can set permanent mac address by userspace helper > > > program. Patch is needed for devices which do not store > > > mac address in internal wl1251 eeprom. > > > > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com> > > > > We have ioctl() command for setting the mac address. > > Really? Is there ioctl for setting permanent mac address? > Can you show me it? Now I looked at it again and I did not found any ioctl for it. There is only ioctl cmd for getting address, not setting it. #define SIOCETHTOOL 0x8946 /* Get permanent hardware address */ #define ETHTOOL_GPERMADDR 0x00000020
On Tue, 2013-12-10 at 18:14 +0100, Pali Rohár wrote: > On Tuesday 10 December 2013 17:10:50 Pali Rohár wrote: > > On Tuesday 10 December 2013 16:49:23 Kalle Valo wrote: > > > Pali Rohár <pali.rohar@gmail.com> writes: > > > > Driver wl1251 generating mac address randomly at startup > > > > and there is no way to set permanent mac address via > > > > SET_IEEE80211_PERM_ADDR. This patch export sysfs file > > > > which can set permanent mac address by userspace helper > > > > program. Patch is needed for devices which do not store > > > > mac address in internal wl1251 eeprom. > > > > > > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com> > > > > > > We have ioctl() command for setting the mac address. > > > > Really? Is there ioctl for setting permanent mac address? > > Can you show me it? > > Now I looked at it again and I did not found any ioctl for it. > There is only ioctl cmd for getting address, not setting it. > > #define SIOCETHTOOL 0x8946 > > /* Get permanent hardware address */ > #define ETHTOOL_GPERMADDR 0x00000020 Yeah, because it's supposed to be permanent and unchanging. Which means if there was an ioctl for it, that would be contrary to the purpose of a permanent MAC address. I realize the N900 stores the WiFi MAC address completely differently than many other systems, and that's why this sysfs file was created. I don't really have a great converged solution for that, other than what you've currently got, or perhaps adding SPERMADDR to ethtool. One thing I *would* like though, is a restriction on the sysfs file such that if the permanent MAC is already set, it cannot be set again. Otherwise the permanent MAC address isn't permanent at all. Dan -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 10 December 2013 18:49:22 Dan Williams wrote: > On Tue, 2013-12-10 at 18:14 +0100, Pali Rohár wrote: > > On Tuesday 10 December 2013 17:10:50 Pali Rohár wrote: > > > On Tuesday 10 December 2013 16:49:23 Kalle Valo wrote: > > > > Pali Rohár <pali.rohar@gmail.com> writes: > > > > > Driver wl1251 generating mac address randomly at > > > > > startup and there is no way to set permanent mac > > > > > address via SET_IEEE80211_PERM_ADDR. This patch > > > > > export sysfs file which can set permanent mac address > > > > > by userspace helper program. Patch is needed for > > > > > devices which do not store mac address in internal > > > > > wl1251 eeprom. > > > > > > > > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com> > > > > > > > > We have ioctl() command for setting the mac address. > > > > > > Really? Is there ioctl for setting permanent mac address? > > > Can you show me it? > > > > Now I looked at it again and I did not found any ioctl for > > it. There is only ioctl cmd for getting address, not > > setting it. > > > > #define SIOCETHTOOL 0x8946 > > > > /* Get permanent hardware address */ > > #define ETHTOOL_GPERMADDR 0x00000020 > > Yeah, because it's supposed to be permanent and unchanging. > Which means if there was an ioctl for it, that would be > contrary to the purpose of a permanent MAC address. > > I realize the N900 stores the WiFi MAC address completely > differently than many other systems, and that's why this > sysfs file was created. I don't really have a great > converged solution for that, other than what you've currently > got, or perhaps adding SPERMADDR to ethtool. One thing I > *would* like though, is a restriction on the sysfs file such > that if the permanent MAC is already set, it cannot be set > again. Otherwise the permanent MAC address isn't permanent > at all. > > Dan Maybe another way could be to use request_firmware to load address from userspace... Or what do you think?
On Tue, 2013-12-10 at 18:52 +0100, Pali Rohár wrote: > On Tuesday 10 December 2013 18:49:22 Dan Williams wrote: > > On Tue, 2013-12-10 at 18:14 +0100, Pali Rohár wrote: > > > On Tuesday 10 December 2013 17:10:50 Pali Rohár wrote: > > > > On Tuesday 10 December 2013 16:49:23 Kalle Valo wrote: > > > > > Pali Rohár <pali.rohar@gmail.com> writes: > > > > > > Driver wl1251 generating mac address randomly at > > > > > > startup and there is no way to set permanent mac > > > > > > address via SET_IEEE80211_PERM_ADDR. This patch > > > > > > export sysfs file which can set permanent mac address > > > > > > by userspace helper program. Patch is needed for > > > > > > devices which do not store mac address in internal > > > > > > wl1251 eeprom. > > > > > > > > > > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com> > > > > > > > > > > We have ioctl() command for setting the mac address. > > > > > > > > Really? Is there ioctl for setting permanent mac address? > > > > Can you show me it? > > > > > > Now I looked at it again and I did not found any ioctl for > > > it. There is only ioctl cmd for getting address, not > > > setting it. > > > > > > #define SIOCETHTOOL 0x8946 > > > > > > /* Get permanent hardware address */ > > > #define ETHTOOL_GPERMADDR 0x00000020 > > > > Yeah, because it's supposed to be permanent and unchanging. > > Which means if there was an ioctl for it, that would be > > contrary to the purpose of a permanent MAC address. > > > > I realize the N900 stores the WiFi MAC address completely > > differently than many other systems, and that's why this > > sysfs file was created. I don't really have a great > > converged solution for that, other than what you've currently > > got, or perhaps adding SPERMADDR to ethtool. One thing I > > *would* like though, is a restriction on the sysfs file such > > that if the permanent MAC is already set, it cannot be set > > again. Otherwise the permanent MAC address isn't permanent > > at all. > > > > Dan > > Maybe another way could be to use request_firmware to load address > from userspace... Or what do you think? That sounds like a great idea to try. A number of devices either need stub firmware to read the MAC from EEPROM, or do use request_firmware() to load firmware before they read the MAC. You may have to use request_firmware() synchronously though to ensure that the MAC is read before registering with mac80211. Dan -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 10 December 2013 20:22:19 Dan Williams wrote: > On Tue, 2013-12-10 at 18:52 +0100, Pali Rohár wrote: > > On Tuesday 10 December 2013 18:49:22 Dan Williams wrote: > > > On Tue, 2013-12-10 at 18:14 +0100, Pali Rohár wrote: > > > > On Tuesday 10 December 2013 17:10:50 Pali Rohár wrote: > > > > > On Tuesday 10 December 2013 16:49:23 Kalle Valo wrote: > > > > > > Pali Rohár <pali.rohar@gmail.com> writes: > > > > > > > Driver wl1251 generating mac address randomly at > > > > > > > startup and there is no way to set permanent mac > > > > > > > address via SET_IEEE80211_PERM_ADDR. This patch > > > > > > > export sysfs file which can set permanent mac > > > > > > > address by userspace helper program. Patch is > > > > > > > needed for devices which do not store mac address > > > > > > > in internal wl1251 eeprom. > > > > > > > > > > > > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com> > > > > > > > > > > > > We have ioctl() command for setting the mac address. > > > > > > > > > > Really? Is there ioctl for setting permanent mac > > > > > address? Can you show me it? > > > > > > > > Now I looked at it again and I did not found any ioctl > > > > for it. There is only ioctl cmd for getting address, > > > > not setting it. > > > > > > > > #define SIOCETHTOOL 0x8946 > > > > > > > > /* Get permanent hardware address */ > > > > #define ETHTOOL_GPERMADDR 0x00000020 > > > > > > Yeah, because it's supposed to be permanent and > > > unchanging. Which means if there was an ioctl for it, > > > that would be contrary to the purpose of a permanent MAC > > > address. > > > > > > I realize the N900 stores the WiFi MAC address completely > > > differently than many other systems, and that's why this > > > sysfs file was created. I don't really have a great > > > converged solution for that, other than what you've > > > currently got, or perhaps adding SPERMADDR to ethtool. > > > One thing I *would* like though, is a restriction on the > > > sysfs file such that if the permanent MAC is already set, > > > it cannot be set again. Otherwise the permanent MAC > > > address isn't permanent at all. > > > > > > Dan > > > > Maybe another way could be to use request_firmware to load > > address from userspace... Or what do you think? > > That sounds like a great idea to try. A number of devices > either need stub firmware to read the MAC from EEPROM, or do > use request_firmware() to load firmware before they read the > MAC. You may have to use request_firmware() synchronously > though to ensure that the MAC is read before registering with > mac80211. > > Dan So, if you like this idea, can you help me how to write udev rule which will run my own program (it print mac address) and send mac address when driver ask for mac address in request_firmware? Problem is that default udev rule for firmware trying to load data from /lib/firmware/... but in this case mac address first must be read from special location and converted to correct format.
On Tue, 2013-12-10 at 18:52 +0100, Pali Rohár wrote: > On Tuesday 10 December 2013 18:49:22 Dan Williams wrote: > > On Tue, 2013-12-10 at 18:14 +0100, Pali Rohár wrote: > > > On Tuesday 10 December 2013 17:10:50 Pali Rohár wrote: > > > > On Tuesday 10 December 2013 16:49:23 Kalle Valo wrote: > > > > > Pali Rohár <pali.rohar@gmail.com> writes: > > > > > > Driver wl1251 generating mac address randomly at > > > > > > startup and there is no way to set permanent mac > > > > > > address via SET_IEEE80211_PERM_ADDR. This patch > > > > > > export sysfs file which can set permanent mac address > > > > > > by userspace helper program. Patch is needed for > > > > > > devices which do not store mac address in internal > > > > > > wl1251 eeprom. > > > > > > > > > > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com> > > > > > > > > > > We have ioctl() command for setting the mac address. > > > > > > > > Really? Is there ioctl for setting permanent mac address? > > > > Can you show me it? > > > > > > Now I looked at it again and I did not found any ioctl for > > > it. There is only ioctl cmd for getting address, not > > > setting it. > > > > > > #define SIOCETHTOOL 0x8946 > > > > > > /* Get permanent hardware address */ > > > #define ETHTOOL_GPERMADDR 0x00000020 > > > > Yeah, because it's supposed to be permanent and unchanging. > > Which means if there was an ioctl for it, that would be > > contrary to the purpose of a permanent MAC address. > > > > I realize the N900 stores the WiFi MAC address completely > > differently than many other systems, and that's why this > > sysfs file was created. I don't really have a great > > converged solution for that, other than what you've currently > > got, or perhaps adding SPERMADDR to ethtool. One thing I > > *would* like though, is a restriction on the sysfs file such > > that if the permanent MAC is already set, it cannot be set > > again. Otherwise the permanent MAC address isn't permanent > > at all. I'm really uncomfortable with the idea of involving userland in establishing the 'permanent' MAC address. (And from what I gather, the Nokia software never did that but only used SIOCSIFHWADDR.) It ought to be set before the interface is ever registered. > > Dan > > Maybe another way could be to use request_firmware to load address > from userspace... Or what do you think? I think that's an even worse idea. This is not firmware and it already exists in separate storage. I think that rx51_init_wl1251() in arch/arm/mach-omap2/board-rx51-peripherals.c should either copy the MAC address out of NVRAM, or if it's too early to do that, then schedule a function to run later and only then set up wl1251 platform data. Ben.
On Tue, 2013-12-10 at 20:31 +0100, Pali Rohár wrote: [...] > So, if you like this idea, can you help me how to write udev rule > which will run my own program (it print mac address) and send mac > address when driver ask for mac address in request_firmware? > Problem is that default udev rule for firmware trying to load data > from /lib/firmware/... but in this case mac address first must be > read from special location and converted to correct format. Unfortunately, udev no longer supports firmware loading during module loading (unless that was fixed - I don't think it has been). Loading firmware *files* still works because the kernel can read those directly rather than requesting them from udev. Ben.
On Wed, 2013-12-11 at 21:17 +0000, Ben Hutchings wrote: > On Tue, 2013-12-10 at 18:52 +0100, Pali Rohár wrote: [...] > > Maybe another way could be to use request_firmware to load address > > from userspace... Or what do you think? > > I think that's an even worse idea. This is not firmware and it already > exists in separate storage. [...] Actually, as it seems you meant to do some kind of dynamic conversion, I think it's not so bad. Unfortunately I don't think it can work as I explained in my other email. Ben.
On 11.12.2013 23:17, Ben Hutchings wrote: > I think that's an even worse idea. This is not firmware and it already > exists in separate storage. > > I think that rx51_init_wl1251() in > arch/arm/mach-omap2/board-rx51-peripherals.c should either copy the MAC > address out of NVRAM, or if it's too early to do that, then schedule a > function to run later and only then set up wl1251 platform data. > > Ben. > And how will that work with DT when board files will be in the history? Ivo -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2013-12-11 at 23:35 +0200, Ivajlo Dimitrov wrote: > On 11.12.2013 23:17, Ben Hutchings wrote: > > I think that's an even worse idea. This is not firmware and it already > > exists in separate storage. > > > > I think that rx51_init_wl1251() in > > arch/arm/mach-omap2/board-rx51-peripherals.c should either copy the MAC > > address out of NVRAM, or if it's too early to do that, then schedule a > > function to run later and only then set up wl1251 platform data. > > > > Ben. > > > > And how will that work with DT when board files will be in the history? 1. Boot loader reads the MAC address from NVRAM and puts it in the DT node. or 2. NVRAM reading is done by a tiny driver that is loaded based on the platform name and updates the DT node in memory. (But I don't know how wl1251 should decide to defer probing if it's probed before that other driver.) Ben.
On 12.12.2013 00:15, Ben Hutchings wrote: > 2. NVRAM reading is done by a tiny driver that is loaded based on the > platform name and updates the DT node in memory. (But I don't know how > wl1251 should decide to defer probing if it's probed before that other > driver.) > > Ben. > Maybe a "hwmac" property with a value of XX:XX:XX:XX:XX:XX (or some other invalid value) set in DT could be used to tell the driver to defer until that value changes to something sane? Ivo -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2013-12-11 at 22:15 +0000, Ben Hutchings wrote: > On Wed, 2013-12-11 at 23:35 +0200, Ivajlo Dimitrov wrote: > > On 11.12.2013 23:17, Ben Hutchings wrote: > > > I think that's an even worse idea. This is not firmware and it already > > > exists in separate storage. > > > > > > I think that rx51_init_wl1251() in > > > arch/arm/mach-omap2/board-rx51-peripherals.c should either copy the MAC > > > address out of NVRAM, or if it's too early to do that, then schedule a > > > function to run later and only then set up wl1251 platform data. > > > > > > Ben. > > > > > > > And how will that work with DT when board files will be in the history? > > 1. Boot loader reads the MAC address from NVRAM and puts it in the DT > node. > or > 2. NVRAM reading is done by a tiny driver that is loaded based on the > platform name and updates the DT node in memory. (But I don't know how > wl1251 should decide to defer probing if it's probed before that other > driver.) I'm uncomfortable with it too, and yes the permanent MAC should really be known before the interface is even registered, but... Imagine if the MAC address for your ethernet device was stored in /etc/my-mac-addr.txt, except that /etc was a read-only protected partition from a very small SSD. That's essentially the N900; it's stored in a file in a normal ext2/ext3 (?) filesystem on a partition of the internal flash. It seems like overkill to write a small driver that duplicates the ext3 + MTD drivers just to read the MAC. There's got to be a better way to do this than having it set from userspace though, but I don't know what that is. The request_firmware() method would probably run into race conditions, since who knows if the partition gets mounted before the WiFi gets initialized? I suppose the firmware helper could block until it did, and while that's ugly, it's the best approach I've seen yet that doesn't violate the "permanent" idea here. Dan -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed 2013-12-11 21:17:34, Ben Hutchings wrote: > On Tue, 2013-12-10 at 18:52 +0100, Pali Rohár wrote: > > On Tuesday 10 December 2013 18:49:22 Dan Williams wrote: > > > On Tue, 2013-12-10 at 18:14 +0100, Pali Rohár wrote: > > > > On Tuesday 10 December 2013 17:10:50 Pali Rohár wrote: > > > > > On Tuesday 10 December 2013 16:49:23 Kalle Valo wrote: > > > > > > Pali Rohár <pali.rohar@gmail.com> writes: > > > > > > > Driver wl1251 generating mac address randomly at > > > > > > > startup and there is no way to set permanent mac > > > > > > > address via SET_IEEE80211_PERM_ADDR. This patch > > > > > > > export sysfs file which can set permanent mac address > > > > > > > by userspace helper program. Patch is needed for > > > > > > > devices which do not store mac address in internal > > > > > > > wl1251 eeprom. > > > > > > > > > > > > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com> > > > > > > > > > > > > We have ioctl() command for setting the mac address. > > > > > > > > > > Really? Is there ioctl for setting permanent mac address? > > > > > Can you show me it? > > > > > > > > Now I looked at it again and I did not found any ioctl for > > > > it. There is only ioctl cmd for getting address, not > > > > setting it. > > > > > > > > #define SIOCETHTOOL 0x8946 > > > > > > > > /* Get permanent hardware address */ > > > > #define ETHTOOL_GPERMADDR 0x00000020 > > > > > > Yeah, because it's supposed to be permanent and unchanging. > > > Which means if there was an ioctl for it, that would be > > > contrary to the purpose of a permanent MAC address. > > > > > > I realize the N900 stores the WiFi MAC address completely > > > differently than many other systems, and that's why this > > > sysfs file was created. I don't really have a great > > > converged solution for that, other than what you've currently > > > got, or perhaps adding SPERMADDR to ethtool. One thing I > > > *would* like though, is a restriction on the sysfs file such > > > that if the permanent MAC is already set, it cannot be set > > > again. Otherwise the permanent MAC address isn't permanent > > > at all. > > I'm really uncomfortable with the idea of involving userland in > establishing the 'permanent' MAC address. (And from what I gather, the > Nokia software never did that but only used SIOCSIFHWADDR.) It ought to > be set before the interface is ever registered. Which is hard to do on n900. What is the problem with userland setting permanent mac address? It is not used for security or anything... Pavel
Hello. On 12-12-2013 2:36, Ivajlo Dimitrov wrote: >> 2. NVRAM reading is done by a tiny driver that is loaded based on the >> platform name and updates the DT node in memory. (But I don't know how >> wl1251 should decide to defer probing if it's probed before that other >> driver.) >> Ben. > Maybe a "hwmac" property with a value of XX:XX:XX:XX:XX:XX (or some other > invalid value) set in DT could be used to tell the driver to defer until that > value changes to something sane? The standard property name for that is "local-mac-address". There's also non-standard "mac-address" variation. > Ivo WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2013-12-11 at 16:53 -0600, Dan Williams wrote: > On Wed, 2013-12-11 at 22:15 +0000, Ben Hutchings wrote: > > On Wed, 2013-12-11 at 23:35 +0200, Ivajlo Dimitrov wrote: > > > On 11.12.2013 23:17, Ben Hutchings wrote: > > > > I think that's an even worse idea. This is not firmware and it already > > > > exists in separate storage. > > > > > > > > I think that rx51_init_wl1251() in > > > > arch/arm/mach-omap2/board-rx51-peripherals.c should either copy the MAC > > > > address out of NVRAM, or if it's too early to do that, then schedule a > > > > function to run later and only then set up wl1251 platform data. > > > > > > > > Ben. > > > > > > > > > > And how will that work with DT when board files will be in the history? > > > > 1. Boot loader reads the MAC address from NVRAM and puts it in the DT > > node. > > or > > 2. NVRAM reading is done by a tiny driver that is loaded based on the > > platform name and updates the DT node in memory. (But I don't know how > > wl1251 should decide to defer probing if it's probed before that other > > driver.) > > I'm uncomfortable with it too, and yes the permanent MAC should really > be known before the interface is even registered, but... > > Imagine if the MAC address for your ethernet device was stored > in /etc/my-mac-addr.txt, except that /etc was a read-only protected > partition from a very small SSD. That's essentially the N900; it's > stored in a file in a normal ext2/ext3 (?) filesystem on a partition of > the internal flash. Oh, from my quick look I got the impression that this 'CAL' was stored directly in a specific flash partition. > It seems like overkill to write a small driver that > duplicates the ext3 + MTD drivers just to read the MAC. [...] I don't see that anything would need to be duplicated. But reading files from the kernel is really ugly, and deciding when to read the file would be another problem (as you noted). Ben
On 12.12.2013 21:55, Ben Hutchings wrote: > On Wed, 2013-12-11 at 16:53 -0600, Dan Williams wrote: >> On Wed, 2013-12-11 at 22:15 +0000, Ben Hutchings wrote: >>> On Wed, 2013-12-11 at 23:35 +0200, Ivajlo Dimitrov wrote: >>>> On 11.12.2013 23:17, Ben Hutchings wrote: >>>>> I think that's an even worse idea. This is not firmware and it already >>>>> exists in separate storage. >>>>> >>>>> I think that rx51_init_wl1251() in >>>>> arch/arm/mach-omap2/board-rx51-peripherals.c should either copy the MAC >>>>> address out of NVRAM, or if it's too early to do that, then schedule a >>>>> function to run later and only then set up wl1251 platform data. >>>>> >>>>> Ben. >>>>> >>>> And how will that work with DT when board files will be in the history? >>> 1. Boot loader reads the MAC address from NVRAM and puts it in the DT >>> node. >>> or >>> 2. NVRAM reading is done by a tiny driver that is loaded based on the >>> platform name and updates the DT node in memory. (But I don't know how >>> wl1251 should decide to defer probing if it's probed before that other >>> driver.) >> I'm uncomfortable with it too, and yes the permanent MAC should really >> be known before the interface is even registered, but... >> >> Imagine if the MAC address for your ethernet device was stored >> in /etc/my-mac-addr.txt, except that /etc was a read-only protected >> partition from a very small SSD. That's essentially the N900; it's >> stored in a file in a normal ext2/ext3 (?) filesystem on a partition of >> the internal flash. > Oh, from my quick look I got the impression that this 'CAL' was stored > directly in a specific flash partition. > >> It seems like overkill to write a small driver that >> duplicates the ext3 + MTD drivers just to read the MAC. > [...] > > I don't see that anything would need to be duplicated. But reading > files from the kernel is really ugly, and deciding when to read the file > would be another problem (as you noted). > > Ben > Yes, CAL is stored in /dev/mtd1, a dedicated partition in the NAND flash. But reading the data stored in it from the kernel is not a trivial task, as it uses its own pseudo-fs format etc. Not impossible (I RE-ed libcal a while ago [0], so there is a code that could be reused, calvaria works too afaik), but still doesn't sound like a very good idea. [0] https://gitorious.org/community-ssu/libcal/source/d4c5fd9293ddb693c9b032b4c084cd0343b3ea26: Ivo -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/wireless/ti/wl1251/main.c b/drivers/net/wireless/ti/wl1251/main.c index 42730b7..a69b741 100644 --- a/drivers/net/wireless/ti/wl1251/main.c +++ b/drivers/net/wireless/ti/wl1251/main.c @@ -1377,6 +1377,46 @@ static const struct ieee80211_ops wl1251_ops = { .get_survey = wl1251_op_get_survey, }; +static ssize_t wl1251_sysfs_show_address(struct device *dev, + struct device_attribute *attr, + char *buf) +{ + struct wl1251 *wl = dev_get_drvdata(dev); + ssize_t len; + + /* FIXME: what's the maximum length of buf? page size?*/ + len = 500; + + len = snprintf(buf, len, "%.2x:%.2x:%.2x:%.2x:%.2x:%.2x\n", + wl->mac_addr[0], wl->mac_addr[1], wl->mac_addr[2], + wl->mac_addr[3], wl->mac_addr[4], wl->mac_addr[5]); + + return len; +} + +static ssize_t wl1251_sysfs_store_address(struct device *dev, + struct device_attribute *attr, + const char *buf, size_t count) +{ + struct wl1251 *wl = dev_get_drvdata(dev); + unsigned int addr[6]; + int ret, i; + + ret = sscanf(buf, "%2x:%2x:%2x:%2x:%2x:%2x\n", + &addr[0], &addr[1], &addr[2], + &addr[3], &addr[4], &addr[5]); + + if (ret != 6) + return -EINVAL; + + for (i = 0; i < 6; i++) + wl->mac_addr[i] = addr[i] & 0xff; + + SET_IEEE80211_PERM_ADDR(wl->hw, wl->mac_addr); + + return count; +} + static ssize_t wl1251_sysfs_show_tx_mgmt_frm_rate(struct device *dev, struct device_attribute *attr, char *buf) @@ -1586,6 +1626,10 @@ out: return count; } +static DEVICE_ATTR(address, S_IRUGO | S_IWUSR, + wl1251_sysfs_show_address, + wl1251_sysfs_store_address); + static DEVICE_ATTR(tx_mgmt_frm_rate, S_IRUGO | S_IWUSR, wl1251_sysfs_show_tx_mgmt_frm_rate, wl1251_sysfs_store_tx_mgmt_frm_rate); @@ -1730,6 +1774,14 @@ int wl1251_init_ieee80211(struct wl1251 *wl) } dev_set_drvdata(&wl1251_device.dev, wl); + /* Create sysfs file address */ + ret = device_create_file(&wl1251_device.dev, + &dev_attr_address); + if (ret < 0) { + wl1251_error("failed to create sysfs file address"); + goto out; + } + /* Create sysfs file tx_mgmt_frm_rate */ ret = device_create_file(&wl1251_device.dev, &dev_attr_tx_mgmt_frm_rate);
Driver wl1251 generating mac address randomly at startup and there is no way to set permanent mac address via SET_IEEE80211_PERM_ADDR. This patch export sysfs file which can set permanent mac address by userspace helper program. Patch is needed for devices which do not store mac address in internal wl1251 eeprom. Signed-off-by: Pali Rohár <pali.rohar@gmail.com> --- drivers/net/wireless/ti/wl1251/main.c | 52 +++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+)