Re: Re: [PATCH v2 15/16] wl1251: Add sysfs file address for setting permanent mac address
On Wed, 2013-12-11 at 16:53 -0600, Dan Williams wrote: > On Wed, 2013-12-11 at 22:15 +, 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 -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH v2 15/16] wl1251: Add sysfs file address for setting permanent mac address
On Wed, 2013-12-11 at 16:53 -0600, Dan Williams wrote: On Wed, 2013-12-11 at 22:15 +, 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 -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH v2 15/16] wl1251: Add sysfs file address for setting permanent mac address
On Wed, 2013-12-11 at 22:15 +, 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 linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH v2 15/16] wl1251: Add sysfs file address for setting permanent mac address
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. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH v2 15/16] wl1251: Add sysfs file address for setting permanent mac address
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 linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH v2 15/16] wl1251: Add sysfs file address for setting permanent mac address
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 linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH v2 15/16] wl1251: Add sysfs file address for setting permanent mac address
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. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH v2 15/16] wl1251: Add sysfs file address for setting permanent mac address
On Wed, 2013-12-11 at 22:15 +, 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 linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
