Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1526848 > unrolled thread

Re: wl1251 & mac address & calibration data

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: wl1251 & mac address & calibration data Pali Rohár <pali.rohar@gmail.com> - 2016-11-21 17:00 +0100
    Re: wl1251 & mac address & calibration data Michal Kazior <michal.kazior@tieto.com> - 2016-11-22 16:30 +0100
      Re: wl1251 & mac address & calibration data Pali Rohár <pali.rohar@gmail.com> - 2016-11-22 16:40 +0100
        Re: wl1251 & mac address & calibration data Michal Kazior <michal.kazior@tieto.com> - 2016-11-22 17:30 +0100
          Re: wl1251 & mac address & calibration data Pali Rohár <pali.rohar@gmail.com> - 2016-11-22 19:10 +0100
            Re: wl1251 & mac address & calibration data Arend Van Spriel <arend.vanspriel@broadcom.com> - 2016-11-23 09:30 +0100
            Re: wl1251 & mac address & calibration data Pavel Machek <pavel@ucw.cz> - 2016-11-23 23:30 +0100
              Re: wl1251 & mac address & calibration data Pali Rohár <pali.rohar@gmail.com> - 2016-11-23 23:50 +0100
                Re: wl1251 & mac address & calibration data Pavel Machek <pavel@ucw.cz> - 2016-11-24 09:00 +0100
                  Re: wl1251 & mac address & calibration data Pali Rohár <pali.rohar@gmail.com> - 2016-11-24 09:40 +0100
                    Re: wl1251 & mac address & calibration data Pali Rohár <pali.rohar@gmail.com> - 2016-11-24 16:30 +0100
                      Re: wl1251 & mac address & calibration data Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> - 2016-11-24 16:40 +0100
                      Re: wl1251 & mac address & calibration data Sebastian Reichel <sre@kernel.org> - 2016-11-24 17:10 +0100
                        Re: wl1251 & mac address & calibration data Pali Rohár <pali.rohar@gmail.com> - 2016-11-24 17:50 +0100
                          Re: wl1251 & mac address & calibration data Sebastian Reichel <sre@kernel.org> - 2016-11-24 19:20 +0100
                            Re: wl1251 & mac address & calibration data Pali Rohár <pali.rohar@gmail.com> - 2016-11-24 19:40 +0100
                      Re: wl1251 & mac address & calibration data Aaro Koskinen <aaro.koskinen@iki.fi> - 2016-11-24 20:10 +0100
                    Re: wl1251 & mac address & calibration data Sebastian Reichel <sre@kernel.org> - 2016-11-24 16:30 +0100

#1526848 — Re: wl1251 & mac address & calibration data

On Friday 11 November 2016 18:20:50 Pali Rohár wrote:
> Hi! I will open discussion about mac address and calibration data for 
> wl1251 wireless chip again...
> 
> Problem: Mac address & calibration data for wl1251 chip on Nokia N900 
> are stored on second nand partition (mtd1) in special proprietary format 
> which is used only for Nokia N900 (probably on N8x0 and N9 too). 
> Wireless driver wl1251.ko cannot work without mac address and 
> calibration data.
> 
> Absence of mac address cause that driver generates random mac address at 
> every kernel boot which has couple of problems (unstable identifier of 
> wireless device due to udev permanent storage rules; unpredictable 
> behaviour for dhcp mac address assignment, mac address filtering, ...).
> 
> Currently there is no way to set (permanent) mac address for network 
> interface from userspace. And it does not make sense to implement in 
> linux kernel large parser for proprietary format of second nand 
> partition where is mac address stored only for one device -- Nokia N900.
> 
> Driver wl1251.ko loads calibration data via request_firmware() for file 
> wl1251-nvs.bin. There are some "example" calibration file in linux-
> firmware repository, but it is not suitable for normal usage as real 
> calibration data are per-device specific.
> 
> So questions are:
> 
> 1) How to set mac address from userspace for that wl1251 interface? In 
> userspace I can write parser for that proprietary format of nand 
> partition and extract mac address from it

Proposed solutions for 1)

* Introduce new IOCL for setting that permanent mac address from
  userspace. Currently we have IOCL for get request

* Use request_firmware() (with flag from 2)) to ask for mac address from
  userspace. This is already used by wl12xx driver (as mac address is
  part of calibration data firmware file)

* Allow to set mac address via sysfs file, e.g.
  /sys/class/ieee80211/phy0/macaddress

> 2) How to send calibration data to wl1251 driver? Those are again stored 
> in proprietary format and I can write userspace parser for it.

Proposed solution for 2)

Introduce new flag for request_firmware(), so it first try to use
userspace helper for loading firmware file with possibility to fallback
to direct VFS access.


So... what do you think about it?

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [next] | [standalone]

#1527598

On 21 November 2016 at 16:51, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Friday 11 November 2016 18:20:50 Pali Rohár wrote:
>> Hi! I will open discussion about mac address and calibration data for
>> wl1251 wireless chip again...
>>
>> Problem: Mac address & calibration data for wl1251 chip on Nokia N900
>> are stored on second nand partition (mtd1) in special proprietary format
>> which is used only for Nokia N900 (probably on N8x0 and N9 too).
>> Wireless driver wl1251.ko cannot work without mac address and
>> calibration data.

Same problem applies to some ath9k/ath10k supported routers. Some even
carry mac address as implicit offset from ethernet mac address. As far
as I understand OpenWRT cooks cal blobs on first boot prior to loading
modules.


>> Absence of mac address cause that driver generates random mac address at
>> every kernel boot which has couple of problems (unstable identifier of
>> wireless device due to udev permanent storage rules; unpredictable
>> behaviour for dhcp mac address assignment, mac address filtering, ...).
>>
>> Currently there is no way to set (permanent) mac address for network
>> interface from userspace. And it does not make sense to implement in
>> linux kernel large parser for proprietary format of second nand
>> partition where is mac address stored only for one device -- Nokia N900.
>>
>> Driver wl1251.ko loads calibration data via request_firmware() for file
>> wl1251-nvs.bin. There are some "example" calibration file in linux-
>> firmware repository, but it is not suitable for normal usage as real
>> calibration data are per-device specific.

You could hook up a script that cooks up the cal/mac file via
modprobe's install hook, no?


Michał

[toc] | [prev] | [next] | [standalone]

#1527605

On Tuesday 22 November 2016 16:22:57 Michal Kazior wrote:
> On 21 November 2016 at 16:51, Pali Rohár <pali.rohar@gmail.com> wrote:
> > On Friday 11 November 2016 18:20:50 Pali Rohár wrote:
> >> Hi! I will open discussion about mac address and calibration data for
> >> wl1251 wireless chip again...
> >>
> >> Problem: Mac address & calibration data for wl1251 chip on Nokia N900
> >> are stored on second nand partition (mtd1) in special proprietary format
> >> which is used only for Nokia N900 (probably on N8x0 and N9 too).
> >> Wireless driver wl1251.ko cannot work without mac address and
> >> calibration data.
> 
> Same problem applies to some ath9k/ath10k supported routers. Some even
> carry mac address as implicit offset from ethernet mac address. As far
> as I understand OpenWRT cooks cal blobs on first boot prior to loading
> modules.

So... wl1251 on Nokia N900 is not alone and this problem is there for
more drivers and devices. Which means we should come up with some
generic solution.

> >> Absence of mac address cause that driver generates random mac address at
> >> every kernel boot which has couple of problems (unstable identifier of
> >> wireless device due to udev permanent storage rules; unpredictable
> >> behaviour for dhcp mac address assignment, mac address filtering, ...).
> >>
> >> Currently there is no way to set (permanent) mac address for network
> >> interface from userspace. And it does not make sense to implement in
> >> linux kernel large parser for proprietary format of second nand
> >> partition where is mac address stored only for one device -- Nokia N900.
> >>
> >> Driver wl1251.ko loads calibration data via request_firmware() for file
> >> wl1251-nvs.bin. There are some "example" calibration file in linux-
> >> firmware repository, but it is not suitable for normal usage as real
> >> calibration data are per-device specific.
> 
> You could hook up a script that cooks up the cal/mac file via
> modprobe's install hook, no?

Via modprobe hook I can either pass custom module parameter or call any
other system (shell) commands.

As wl1251.ko does not accept mac_address as module parameter, such
modprobe hook does not help -- as there is absolutely no way from
userspace to set or change (permanent) mac address.

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

#1527664

On 22 November 2016 at 16:31, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Tuesday 22 November 2016 16:22:57 Michal Kazior wrote:
>> On 21 November 2016 at 16:51, Pali Rohár <pali.rohar@gmail.com> wrote:
>> > On Friday 11 November 2016 18:20:50 Pali Rohár wrote:
>> >> Hi! I will open discussion about mac address and calibration data for
>> >> wl1251 wireless chip again...
>> >>
>> >> Problem: Mac address & calibration data for wl1251 chip on Nokia N900
>> >> are stored on second nand partition (mtd1) in special proprietary format
>> >> which is used only for Nokia N900 (probably on N8x0 and N9 too).
>> >> Wireless driver wl1251.ko cannot work without mac address and
>> >> calibration data.
>>
>> Same problem applies to some ath9k/ath10k supported routers. Some even
>> carry mac address as implicit offset from ethernet mac address. As far
>> as I understand OpenWRT cooks cal blobs on first boot prior to loading
>> modules.
>
> So... wl1251 on Nokia N900 is not alone and this problem is there for
> more drivers and devices. Which means we should come up with some
> generic solution.

This isn't particularly a problem for ath9k/ath10k.

Let me give you more background on ath10k.

ath10k devices can come with caldata and macaddr stored in their
OTP/EEPROM. In that case a generic "template" board file is used.
Userspace doesn't need to do anything special.

Some vendors however decide to use flash partition to store caldata.
In that case ath10k expects userspace to prepare cal-$bus-$devname.bin
files, each for a different radio (you can have multiple radios on a
system).

Now translating this for wl1251 I would expect it should also use
something like wl1251-nvs-sdio-0x0001.bin for devices like N900 that
have caldata on flash partition (instead of the generic
wl1251-nvs.bin). I'm not sure if wl1251-nvs.bin is something
comparable to (the generic) board.bin ath10k has though. Maybe the
entire idea behind wl1251-nvs.bin is flawed as it's supposed to be
device specific and is oblivious to possibility of having multiple
wl1251 radios on one system (probably sane assumption from practical
standpoint but still).


>> >> Absence of mac address cause that driver generates random mac address at
>> >> every kernel boot which has couple of problems (unstable identifier of
>> >> wireless device due to udev permanent storage rules; unpredictable
>> >> behaviour for dhcp mac address assignment, mac address filtering, ...).
>> >>
>> >> Currently there is no way to set (permanent) mac address for network
>> >> interface from userspace. And it does not make sense to implement in
>> >> linux kernel large parser for proprietary format of second nand
>> >> partition where is mac address stored only for one device -- Nokia N900.
>> >>
>> >> Driver wl1251.ko loads calibration data via request_firmware() for file
>> >> wl1251-nvs.bin. There are some "example" calibration file in linux-
>> >> firmware repository, but it is not suitable for normal usage as real
>> >> calibration data are per-device specific.
>>
>> You could hook up a script that cooks up the cal/mac file via
>> modprobe's install hook, no?
>
> Via modprobe hook I can either pass custom module parameter or call any
> other system (shell) commands.
>
> As wl1251.ko does not accept mac_address as module parameter, such
> modprobe hook does not help -- as there is absolutely no way from
> userspace to set or change (permanent) mac address.

Quoting modprobe.d manual:

>       install modulename command...
>           This command instructs modprobe to run your
>           command instead of inserting the module in the
>           kernel as normal. The command can be any shell
>           command: this allows you to do any kind of
>           complex processing you might wish. [...]

You can hook up a script that cooks up wl1251-nvs.bin (caldata,
macaddr) and then insmod the actual wl1251.ko module. Or you can just
cook up the nvs on first device boot and store it in /lib/firmware
(possibly overwriting the "generic" wl1251 from linux-firmware).


Michal

[toc] | [prev] | [next] | [standalone]

#1527816

[Multipart message — attachments visible in raw view] — view raw

On Tuesday 22 November 2016 17:14:28 Michal Kazior wrote:
> On 22 November 2016 at 16:31, Pali Rohár <pali.rohar@gmail.com> wrote:
> > On Tuesday 22 November 2016 16:22:57 Michal Kazior wrote:
> >> On 21 November 2016 at 16:51, Pali Rohár <pali.rohar@gmail.com>
> >> wrote:
> >> > On Friday 11 November 2016 18:20:50 Pali Rohár wrote:
> >> >> Hi! I will open discussion about mac address and calibration
> >> >> data for wl1251 wireless chip again...
> >> >> 
> >> >> Problem: Mac address & calibration data for wl1251 chip on
> >> >> Nokia N900 are stored on second nand partition (mtd1) in
> >> >> special proprietary format which is used only for Nokia N900
> >> >> (probably on N8x0 and N9 too). Wireless driver wl1251.ko
> >> >> cannot work without mac address and calibration data.
> >> 
> >> Same problem applies to some ath9k/ath10k supported routers. Some
> >> even carry mac address as implicit offset from ethernet mac
> >> address. As far as I understand OpenWRT cooks cal blobs on first
> >> boot prior to loading modules.
> > 
> > So... wl1251 on Nokia N900 is not alone and this problem is there
> > for more drivers and devices. Which means we should come up with
> > some generic solution.
> 
> This isn't particularly a problem for ath9k/ath10k.
> 
> Let me give you more background on ath10k.
> 
> ath10k devices can come with caldata and macaddr stored in their
> OTP/EEPROM. In that case a generic "template" board file is used.
> Userspace doesn't need to do anything special.
> 
> Some vendors however decide to use flash partition to store caldata.
> In that case ath10k expects userspace to prepare
> cal-$bus-$devname.bin files, each for a different radio (you can
> have multiple radios on a system).
> 
> Now translating this for wl1251 I would expect it should also use
> something like wl1251-nvs-sdio-0x0001.bin for devices like N900 that
> have caldata on flash partition (instead of the generic
> wl1251-nvs.bin). I'm not sure if wl1251-nvs.bin is something
> comparable to (the generic) board.bin ath10k has though. Maybe the
> entire idea behind wl1251-nvs.bin is flawed as it's supposed to be
> device specific and is oblivious to possibility of having multiple
> wl1251 radios on one system (probably sane assumption from practical
> standpoint but still).

Basically nvs data are device specific, in ideal case they should be 
generated in factory by some calibration process (or so).

> >> >> Absence of mac address cause that driver generates random mac
> >> >> address at every kernel boot which has couple of problems
> >> >> (unstable identifier of wireless device due to udev permanent
> >> >> storage rules; unpredictable behaviour for dhcp mac address
> >> >> assignment, mac address filtering, ...).
> >> >> 
> >> >> Currently there is no way to set (permanent) mac address for
> >> >> network interface from userspace. And it does not make sense
> >> >> to implement in linux kernel large parser for proprietary
> >> >> format of second nand partition where is mac address stored
> >> >> only for one device -- Nokia N900.
> >> >> 
> >> >> Driver wl1251.ko loads calibration data via request_firmware()
> >> >> for file wl1251-nvs.bin. There are some "example" calibration
> >> >> file in linux- firmware repository, but it is not suitable for
> >> >> normal usage as real calibration data are per-device specific.
> >> 
> >> You could hook up a script that cooks up the cal/mac file via
> >> modprobe's install hook, no?
> > 
> > Via modprobe hook I can either pass custom module parameter or call
> > any other system (shell) commands.
> > 
> > As wl1251.ko does not accept mac_address as module parameter, such
> > modprobe hook does not help -- as there is absolutely no way from
> > userspace to set or change (permanent) mac address.
> 
> Quoting modprobe.d manual:
> >       install modulename command...
> >       
> >           This command instructs modprobe to run your
> >           command instead of inserting the module in the
> >           kernel as normal. The command can be any shell
> >           command: this allows you to do any kind of
> >           complex processing you might wish. [...]

I know. But this do not allow me to send mac address to kernel -- as 
kernel does not support such command yet (reason for my first question).

> You can hook up a script that cooks up wl1251-nvs.bin (caldata,
> macaddr) and then insmod the actual wl1251.ko module. Or you can just
> cook up the nvs on first device boot and store it in /lib/firmware
> (possibly overwriting the "generic" wl1251 from linux-firmware).

This is what I would like to prevent -- overwriting (possible readonly) 
system files with some device specific. It is really bad idea!

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

#1528183

On 22-11-2016 18:05, Pali Rohár wrote:
> On Tuesday 22 November 2016 17:14:28 Michal Kazior wrote:
>> On 22 November 2016 at 16:31, Pali Rohár <pali.rohar@gmail.com> wrote:
>>> On Tuesday 22 November 2016 16:22:57 Michal Kazior wrote:
>>>> On 21 November 2016 at 16:51, Pali Rohár <pali.rohar@gmail.com>
>>>> wrote:
>>>>> On Friday 11 November 2016 18:20:50 Pali Rohár wrote:
>>>>>> Hi! I will open discussion about mac address and calibration
>>>>>> data for wl1251 wireless chip again...
>>>>>>
>>>>>> Problem: Mac address & calibration data for wl1251 chip on
>>>>>> Nokia N900 are stored on second nand partition (mtd1) in
>>>>>> special proprietary format which is used only for Nokia N900
>>>>>> (probably on N8x0 and N9 too). Wireless driver wl1251.ko
>>>>>> cannot work without mac address and calibration data.
>>>>
>>>> Same problem applies to some ath9k/ath10k supported routers. Some
>>>> even carry mac address as implicit offset from ethernet mac
>>>> address. As far as I understand OpenWRT cooks cal blobs on first
>>>> boot prior to loading modules.
>>>
>>> So... wl1251 on Nokia N900 is not alone and this problem is there
>>> for more drivers and devices. Which means we should come up with
>>> some generic solution.
>>
>> This isn't particularly a problem for ath9k/ath10k.
>>
>> Let me give you more background on ath10k.
>>
>> ath10k devices can come with caldata and macaddr stored in their
>> OTP/EEPROM. In that case a generic "template" board file is used.
>> Userspace doesn't need to do anything special.
>>
>> Some vendors however decide to use flash partition to store caldata.
>> In that case ath10k expects userspace to prepare
>> cal-$bus-$devname.bin files, each for a different radio (you can
>> have multiple radios on a system).
>>
>> Now translating this for wl1251 I would expect it should also use
>> something like wl1251-nvs-sdio-0x0001.bin for devices like N900 that
>> have caldata on flash partition (instead of the generic
>> wl1251-nvs.bin). I'm not sure if wl1251-nvs.bin is something
>> comparable to (the generic) board.bin ath10k has though. Maybe the
>> entire idea behind wl1251-nvs.bin is flawed as it's supposed to be
>> device specific and is oblivious to possibility of having multiple
>> wl1251 radios on one system (probably sane assumption from practical
>> standpoint but still).
> 
> Basically nvs data are device specific, in ideal case they should be 
> generated in factory by some calibration process (or so).

For brcmfmac we have what we call nvram data, which is determined during
manufacturing. We use the firmware_class API to obtain that file, but on
router it may be stored in flash. So an API was created for that router
architecture and brcmfmac calls that API [1]. Not a generic solution but
it gets the job done. Personally, I would have liked this to be handled
behind the firmware_class API to hide the storage details from the driver.

Regards,
Arend

[1]
http://lxr.free-electrons.com/source/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c#L449

[toc] | [prev] | [next] | [standalone]

#1528804

[Multipart message — attachments visible in raw view] — view raw

Hi!

> > > As wl1251.ko does not accept mac_address as module parameter, such
> > > modprobe hook does not help -- as there is absolutely no way from
> > > userspace to set or change (permanent) mac address.
> > 
> > Quoting modprobe.d manual:
> > >       install modulename command...
> > >       
> > >           This command instructs modprobe to run your
> > >           command instead of inserting the module in the
> > >           kernel as normal. The command can be any shell
> > >           command: this allows you to do any kind of
> > >           complex processing you might wish. [...]
> 
> I know. But this do not allow me to send mac address to kernel -- as 
> kernel does not support such command yet (reason for my first
> question).

Plus, this does not really work for cases where wl1251 is not a
module.

> > You can hook up a script that cooks up wl1251-nvs.bin (caldata,
> > macaddr) and then insmod the actual wl1251.ko module. Or you can just
> > cook up the nvs on first device boot and store it in /lib/firmware
> > (possibly overwriting the "generic" wl1251 from linux-firmware).
> 
> This is what I would like to prevent -- overwriting (possible readonly) 
> system files with some device specific. It is really bad idea!

Agreed.

"ifconfig hw ether XX" normally sets the address. I guess that's
ioctl? And I guess we should use similar mechanism for permanent
address.

Best regards,

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1528818

[Multipart message — attachments visible in raw view] — view raw

On Wednesday 23 November 2016 23:23:35 Pavel Machek wrote:
> Hi!
> 
> > > > As wl1251.ko does not accept mac_address as module parameter,
> > > > such modprobe hook does not help -- as there is absolutely no
> > > > way from userspace to set or change (permanent) mac address.
> > > 
> > > Quoting modprobe.d manual:
> > > >       install modulename command...
> > > >       
> > > >           This command instructs modprobe to run your
> > > >           command instead of inserting the module in the
> > > >           kernel as normal. The command can be any shell
> > > >           command: this allows you to do any kind of
> > > >           complex processing you might wish. [...]
> > 
> > I know. But this do not allow me to send mac address to kernel --
> > as kernel does not support such command yet (reason for my first
> > question).
> 
> Plus, this does not really work for cases where wl1251 is not a
> module.

Yes, this is another problem.

> > > You can hook up a script that cooks up wl1251-nvs.bin (caldata,
> > > macaddr) and then insmod the actual wl1251.ko module. Or you can
> > > just cook up the nvs on first device boot and store it in
> > > /lib/firmware (possibly overwriting the "generic" wl1251 from
> > > linux-firmware).
> > 
> > This is what I would like to prevent -- overwriting (possible
> > readonly) system files with some device specific. It is really bad
> > idea!
> 
> Agreed.
> 
> "ifconfig hw ether XX" normally sets the address. I guess that's
> ioctl?

This sets temporary address and it is ioctl. IIRC same as what ethtool 
uses. (ifconfig is already deprecated).

> And I guess we should use similar mechanism for permanent
> address.

I'm not sure here... Above ioctl ↑↑↑ is for changing temporary mac 
address. But here we do not want to change permanent mac address. We 
want to tell kernel driver current permanent mac address which is stored 
in permanent mac address storage (in N900 case in mtd). Just like 
userspace helper as kernel driver do not have code which can read 
permanent mac address.

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

#1529047

[Multipart message — attachments visible in raw view] — view raw

Hi!

> > "ifconfig hw ether XX" normally sets the address. I guess that's
> > ioctl?
> 
> This sets temporary address and it is ioctl. IIRC same as what ethtool 
> uses. (ifconfig is already deprecated).
> 
> > And I guess we should use similar mechanism for permanent
> > address.
> 
> I'm not sure here... Above ioctl ↑↑↑ is for changing temporary mac 
> address. But here we do not want to change permanent mac address. We 
> want to tell kernel driver current permanent mac address which is
> stored

Well... I'd still use similar mechanism :-).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1529064

On Thursday 24 November 2016 08:51:04 Pavel Machek wrote:
> Hi!
> 
> > > "ifconfig hw ether XX" normally sets the address. I guess that's
> > > ioctl?
> > 
> > This sets temporary address and it is ioctl. IIRC same as what ethtool 
> > uses. (ifconfig is already deprecated).
> > 
> > > And I guess we should use similar mechanism for permanent
> > > address.
> > 
> > I'm not sure here... Above ioctl ↑↑↑ is for changing temporary mac 
> > address. But here we do not want to change permanent mac address. We 
> > want to tell kernel driver current permanent mac address which is
> > stored
> 
> Well... I'd still use similar mechanism :-).

Thats problematic, because in time when wlan0 interface is registered
into system and visible in ifconfig output it already needs to have
permanent mac address assigned.

We should assign permanent mac address before wlan0 of wl1251 is
registered into system.

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

#1529433

On Thursday 24 November 2016 16:13:17 Sebastian Reichel wrote:
> Hi,
> 
> On Thu, Nov 24, 2016 at 09:33:29AM +0100, Pali Rohár wrote:
> > On Thursday 24 November 2016 08:51:04 Pavel Machek wrote:
> > > Hi!
> > > 
> > > > > "ifconfig hw ether XX" normally sets the address. I guess that's
> > > > > ioctl?
> > > > 
> > > > This sets temporary address and it is ioctl. IIRC same as what ethtool 
> > > > uses. (ifconfig is already deprecated).
> > > > 
> > > > > And I guess we should use similar mechanism for permanent
> > > > > address.
> > > > 
> > > > I'm not sure here... Above ioctl ↑↑↑ is for changing temporary mac 
> > > > address. But here we do not want to change permanent mac address. We 
> > > > want to tell kernel driver current permanent mac address which is
> > > > stored
> > > 
> > > Well... I'd still use similar mechanism :-).
> > 
> > Thats problematic, because in time when wlan0 interface is registered
> > into system and visible in ifconfig output it already needs to have
> > permanent mac address assigned.
> > 
> > We should assign permanent mac address before wlan0 of wl1251 is
> > registered into system.
> 
> You can just add the MAC address to the NVS data, which is also
> required for the device initialization.

NVS data file has fixed size, there is IIRC no place for it.

But one of my suggestion was to use another request_firmware for MAC
address. So this is similar to what you are proposing, as NVS data are
loaded by request_firmware too...

> I wonder if those information could be put into DT. Iirc some
> network devices get their MAC address from DT. Maybe we can add
> all NVS info to DT? How much data is it?

Proprietary, signed and closed bootloader NOLO does not support DT. So
for booting you need to append DTS file to kernel image.

U-Boot is optional and can be used as intermediate bootloader between
NOLO and kernel. But still it has problems with reading from nand, so
cannot read NVS data nor MAC address.

> Userspace application can add all those information to the DT
> using a DT overlay. Also the u-boot could parse and add it at
> some point in the future.

In case when wl1251 is statically linked into kernel image, it is loaded
and initialized before even userspace applications starts.

So no... adding NVS data or MAC address into DT or DT overlay is not a
solution.

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

#1529459

Hi,

On 24.11.2016 17:20, Pali Rohár wrote:
>
> In case when wl1251 is statically linked into kernel image, it is loaded
> and initialized before even userspace applications starts.
>

Which leaves no option, but integrating libcal into kernel :).

Ivo

[toc] | [prev] | [next] | [standalone]

#1529527

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> On Thursday 24 November 2016 16:13:17 Sebastian Reichel wrote:
> > On Thu, Nov 24, 2016 at 09:33:29AM +0100, Pali Rohár wrote:
> > > On Thursday 24 November 2016 08:51:04 Pavel Machek wrote:
> > > > > > "ifconfig hw ether XX" normally sets the address. I guess that's
> > > > > > ioctl?
> > > > > 
> > > > > This sets temporary address and it is ioctl. IIRC same as what ethtool 
> > > > > uses. (ifconfig is already deprecated).
> > > > > 
> > > > > > And I guess we should use similar mechanism for permanent
> > > > > > address.
> > > > > 
> > > > > I'm not sure here... Above ioctl ↑↑↑ is for changing temporary mac 
> > > > > address. But here we do not want to change permanent mac address. We 
> > > > > want to tell kernel driver current permanent mac address which is
> > > > > stored
> > > > 
> > > > Well... I'd still use similar mechanism :-).
> > > 
> > > Thats problematic, because in time when wlan0 interface is registered
> > > into system and visible in ifconfig output it already needs to have
> > > permanent mac address assigned.
> > > 
> > > We should assign permanent mac address before wlan0 of wl1251 is
> > > registered into system.
> > 
> > You can just add the MAC address to the NVS data, which is also
> > required for the device initialization.
> 
> NVS data file has fixed size, there is IIRC no place for it.
> 
> But one of my suggestion was to use another request_firmware for MAC
> address. So this is similar to what you are proposing, as NVS data are
> loaded by request_firmware too...

Just append it to NVS data and modify the size check accordingly?

> > I wonder if those information could be put into DT. Iirc some
> > network devices get their MAC address from DT. Maybe we can add
> > all NVS info to DT? How much data is it?
> 
> Proprietary, signed and closed bootloader NOLO does not support DT. So
> for booting you need to append DTS file to kernel image.

Yeah, so NOLO without U-Boot will depend on userspace to fixup DT.

> U-Boot is optional and can be used as intermediate bootloader between
> NOLO and kernel. But still it has problems with reading from nand, so
> cannot read NVS data nor MAC address.

It may in the future?

> > Userspace application can add all those information to the DT
> > using a DT overlay. Also the u-boot could parse and add it at
> > some point in the future.
> 
> In case when wl1251 is statically linked into kernel image, it is loaded
> and initialized before even userspace applications starts.
>
> So no... adding NVS data or MAC address into DT or DT overlay is not a
> solution.

Actually with data loaded from DT you *can* load data quite early in
the boot process, while your suggestions always require userspace.
So you argument against yourself?

-- Sebastian

[toc] | [prev] | [next] | [standalone]

#1529565

[Multipart message — attachments visible in raw view] — view raw

On Thursday 24 November 2016 17:08:30 Sebastian Reichel wrote:
> Hi,
> 
> On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> > On Thursday 24 November 2016 16:13:17 Sebastian Reichel wrote:
> > > On Thu, Nov 24, 2016 at 09:33:29AM +0100, Pali Rohár wrote:
> > > > On Thursday 24 November 2016 08:51:04 Pavel Machek wrote:
> > > > > > > "ifconfig hw ether XX" normally sets the address. I guess
> > > > > > > that's ioctl?
> > > > > > 
> > > > > > This sets temporary address and it is ioctl. IIRC same as
> > > > > > what ethtool uses. (ifconfig is already deprecated).
> > > > > > 
> > > > > > > And I guess we should use similar mechanism for permanent
> > > > > > > address.
> > > > > > 
> > > > > > I'm not sure here... Above ioctl ↑↑↑ is for changing
> > > > > > temporary mac address. But here we do not want to change
> > > > > > permanent mac address. We want to tell kernel driver
> > > > > > current permanent mac address which is stored
> > > > > 
> > > > > Well... I'd still use similar mechanism :-).
> > > > 
> > > > Thats problematic, because in time when wlan0 interface is
> > > > registered into system and visible in ifconfig output it
> > > > already needs to have permanent mac address assigned.
> > > > 
> > > > We should assign permanent mac address before wlan0 of wl1251
> > > > is registered into system.
> > > 
> > > You can just add the MAC address to the NVS data, which is also
> > > required for the device initialization.
> > 
> > NVS data file has fixed size, there is IIRC no place for it.
> > 
> > But one of my suggestion was to use another request_firmware for
> > MAC address. So this is similar to what you are proposing, as NVS
> > data are loaded by request_firmware too...
> 
> Just append it to NVS data and modify the size check accordingly?

First that would mean to have request_firmware() function which will not 
use direct VFS access, but instead use userspace helper.

NVS data file with some default values (not suitable for usage) is 
already present in linux-firmware and available in /lib/firmware/...

Also I'm not sure if such thing is allowed by license:
https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/LICENCE.ti-connectivity

> > > I wonder if those information could be put into DT. Iirc some
> > > network devices get their MAC address from DT. Maybe we can add
> > > all NVS info to DT? How much data is it?
> > 
> > Proprietary, signed and closed bootloader NOLO does not support DT.
> > So for booting you need to append DTS file to kernel image.
> 
> Yeah, so NOLO without U-Boot will depend on userspace to fixup DT.
> 
> > U-Boot is optional and can be used as intermediate bootloader
> > between NOLO and kernel. But still it has problems with reading
> > from nand, so cannot read NVS data nor MAC address.
> 
> It may in the future?

I already tried that, but I failed. I was not able to access N900's nand 
from u-boot. No idea where was problem...

And if somebody fix onenand in u-boot, then needs to reimplement Nokia's 
proprietary parser of that partition where is stored NVS and mac address 
&& make this support in upstream u-boot.

So... I doubt it will be in any future.

+ no men power

> > > Userspace application can add all those information to the DT
> > > using a DT overlay. Also the u-boot could parse and add it at
> > > some point in the future.
> > 
> > In case when wl1251 is statically linked into kernel image, it is
> > loaded and initialized before even userspace applications starts.
> > 
> > So no... adding NVS data or MAC address into DT or DT overlay is
> > not a solution.
> 
> Actually with data loaded from DT you *can* load data quite early in
> the boot process, while your suggestions always require userspace.
> So you argument against yourself?

You cannot add DTS in uboot (no support). And if you modify DTS on 
running kernel from userspace, then it is too late when wl1251 is 
statically linked into kernel image.

wl1251 will not wait until some userspace modify DTS and add data...

But request_firmware() in fallback mode *can* wait for userspace so 
wl1251 can postpone its operation until mdev/udev/whatever starts 
listening for events and push needed firmware data to kernel.

So no, there is no argument against... request_firmware() in fallback 
mode with userspace helper is by design blocking and waiting for 
userspace. But waiting for some change in DST in kernel is just 
nonsense.

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

#1529605

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Thu, Nov 24, 2016 at 05:49:33PM +0100, Pali Rohár wrote:
> On Thursday 24 November 2016 17:08:30 Sebastian Reichel wrote:
> > On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> > > On Thursday 24 November 2016 16:13:17 Sebastian Reichel wrote:
> > > > On Thu, Nov 24, 2016 at 09:33:29AM +0100, Pali Rohár wrote:
> > > > > On Thursday 24 November 2016 08:51:04 Pavel Machek wrote:
> > > > > > > > "ifconfig hw ether XX" normally sets the address. I guess
> > > > > > > > that's ioctl?
> > > > > > > 
> > > > > > > This sets temporary address and it is ioctl. IIRC same as
> > > > > > > what ethtool uses. (ifconfig is already deprecated).
> > > > > > > 
> > > > > > > > And I guess we should use similar mechanism for permanent
> > > > > > > > address.
> > > > > > > 
> > > > > > > I'm not sure here... Above ioctl ↑↑↑ is for changing
> > > > > > > temporary mac address. But here we do not want to change
> > > > > > > permanent mac address. We want to tell kernel driver
> > > > > > > current permanent mac address which is stored
> > > > > > 
> > > > > > Well... I'd still use similar mechanism :-).
> > > > > 
> > > > > Thats problematic, because in time when wlan0 interface is
> > > > > registered into system and visible in ifconfig output it
> > > > > already needs to have permanent mac address assigned.
> > > > > 
> > > > > We should assign permanent mac address before wlan0 of wl1251
> > > > > is registered into system.
> > > > 
> > > > You can just add the MAC address to the NVS data, which is also
> > > > required for the device initialization.
> > > 
> > > NVS data file has fixed size, there is IIRC no place for it.
> > > 
> > > But one of my suggestion was to use another request_firmware for
> > > MAC address. So this is similar to what you are proposing, as NVS
> > > data are loaded by request_firmware too...
> > 
> > Just append it to NVS data and modify the size check accordingly?
> 
> First that would mean to have request_firmware() function which will not 
> use direct VFS access, but instead use userspace helper.

Permanent MAC is device specific init data, NVS is device specific
init data => load together.

The userspace helper stuff is only needed to get the data from
the NAND calibration area on the fly.

> NVS data file with some default values (not suitable for usage) is 
> already present in linux-firmware and available in /lib/firmware/...

You mentioned NVS data is fixed size, so this should be enough?

switch(loaded_size)
    case IMAGE_SIZE + MAC_SIZE:
        /* extract mac */
        /* fallthrough */
    case IMAGE_SIZE:
        /* load NVS */
        break;
    default:
        /* fail */
}

> Also I'm not sure if such thing is allowed by license:
> https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/LICENCE.ti-connectivity

concating data is not a modification, otherwise you can't
put the file in a filesystem.

> > > > I wonder if those information could be put into DT. Iirc some
> > > > network devices get their MAC address from DT. Maybe we can add
> > > > all NVS info to DT? How much data is it?
> > > 
> > > Proprietary, signed and closed bootloader NOLO does not support DT.
> > > So for booting you need to append DTS file to kernel image.
> > 
> > Yeah, so NOLO without U-Boot will depend on userspace to fixup DT.
> > 
> > > U-Boot is optional and can be used as intermediate bootloader
> > > between NOLO and kernel. But still it has problems with reading
> > > from nand, so cannot read NVS data nor MAC address.
> > 
> > It may in the future?
> 
> I already tried that, but I failed. I was not able to access N900's nand 
> from u-boot. No idea where was problem...
>
> And if somebody fix onenand in u-boot, then needs to reimplement Nokia's 
> proprietary parser of that partition where is stored NVS and mac address 
> && make this support in upstream u-boot.

Are we talking about this?

https://github.com/community-ssu/libcal/blob/master/cal.c

That's ~1k loc for read-only. Getting NAND working looks harder than
porting this to me.

> So... I doubt it will be in any future.
> 
> + no men power

yeah :(

But with that reasoning you should just extract the NVS data
from NAND and put it in your rootfs.

> > > > Userspace application can add all those information to the DT
> > > > using a DT overlay. Also the u-boot could parse and add it at
> > > > some point in the future.
> > > 
> > > In case when wl1251 is statically linked into kernel image, it is
> > > loaded and initialized before even userspace applications starts.
> > > 
> > > So no... adding NVS data or MAC address into DT or DT overlay is
> > > not a solution.
> > 
> > Actually with data loaded from DT you *can* load data quite early in
> > the boot process, while your suggestions always require userspace.
> > So you argument against yourself?
> 
> You cannot add DTS in uboot (no support).

AFAIK that's supported:

http://www.denx.de/wiki/DULG/LinuxFDTBlob

"Note that U-Boot makes some automatic modifications to the blob
before passing it to the kernel - mainly adding and modifying
information that is learnt at run-time."

> And if you modify DTS on running kernel from userspace, then it is
> too late when wl1251 is statically linked into kernel image.
> 
> wl1251 will not wait until some userspace modify DTS and add data...

if (nvs info missing)
    return -EPROBE_DEFER;

> But request_firmware() in fallback mode *can* wait for userspace so 
> wl1251 can postpone its operation until mdev/udev/whatever starts 
> listening for events and push needed firmware data to kernel.

As you said one workaround is waiting. That's not a solution, that
only works with request_firmware().

> So no, there is no argument against... request_firmware() in fallback 
> mode with userspace helper is by design blocking and waiting for 
> userspace. But waiting for some change in DTS in kernel is just 
> nonsense.

I would just mark the wlan device with status = "disabled" and
enable it in the overlay together with adding the NVS & MAC info.

-- Sebastian

[toc] | [prev] | [next] | [standalone]

#1529615

[Multipart message — attachments visible in raw view] — view raw

On Thursday 24 November 2016 19:11:39 Sebastian Reichel wrote:
> Hi,
> 
> On Thu, Nov 24, 2016 at 05:49:33PM +0100, Pali Rohár wrote:
> > On Thursday 24 November 2016 17:08:30 Sebastian Reichel wrote:
> > > On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> > > > On Thursday 24 November 2016 16:13:17 Sebastian Reichel wrote:
> > > > > On Thu, Nov 24, 2016 at 09:33:29AM +0100, Pali Rohár wrote:
> > > > > > On Thursday 24 November 2016 08:51:04 Pavel Machek wrote:
> > > > > > > > > "ifconfig hw ether XX" normally sets the address. I
> > > > > > > > > guess that's ioctl?
> > > > > > > > 
> > > > > > > > This sets temporary address and it is ioctl. IIRC same
> > > > > > > > as what ethtool uses. (ifconfig is already
> > > > > > > > deprecated).
> > > > > > > > 
> > > > > > > > > And I guess we should use similar mechanism for
> > > > > > > > > permanent address.
> > > > > > > > 
> > > > > > > > I'm not sure here... Above ioctl ↑↑↑ is for changing
> > > > > > > > temporary mac address. But here we do not want to
> > > > > > > > change permanent mac address. We want to tell kernel
> > > > > > > > driver current permanent mac address which is stored
> > > > > > > 
> > > > > > > Well... I'd still use similar mechanism :-).
> > > > > > 
> > > > > > Thats problematic, because in time when wlan0 interface is
> > > > > > registered into system and visible in ifconfig output it
> > > > > > already needs to have permanent mac address assigned.
> > > > > > 
> > > > > > We should assign permanent mac address before wlan0 of
> > > > > > wl1251 is registered into system.
> > > > > 
> > > > > You can just add the MAC address to the NVS data, which is
> > > > > also required for the device initialization.
> > > > 
> > > > NVS data file has fixed size, there is IIRC no place for it.
> > > > 
> > > > But one of my suggestion was to use another request_firmware
> > > > for MAC address. So this is similar to what you are proposing,
> > > > as NVS data are loaded by request_firmware too...
> > > 
> > > Just append it to NVS data and modify the size check accordingly?
> > 
> > First that would mean to have request_firmware() function which
> > will not use direct VFS access, but instead use userspace helper.
> 
> Permanent MAC is device specific init data, NVS is device specific
> init data => load together.
> 
> The userspace helper stuff is only needed to get the data from
> the NAND calibration area on the fly.

But it is needed... and currently request_firmware() prefer direct VFS 
access...

> > NVS data file with some default values (not suitable for usage) is
> > already present in linux-firmware and available in
> > /lib/firmware/...
> 
> You mentioned NVS data is fixed size, so this should be enough?
> 
> switch(loaded_size)
>     case IMAGE_SIZE + MAC_SIZE:
>         /* extract mac */
>         /* fallthrough */
>     case IMAGE_SIZE:
>         /* load NVS */
>         break;
>     default:
>         /* fail */
> }
> 
> > Also I'm not sure if such thing is allowed by license:
> > https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmwar
> > e.git/tree/LICENCE.ti-connectivity
> 
> concating data is not a modification, otherwise you can't
> put the file in a filesystem.

Ok, if net maintainers agree.

> > > > > I wonder if those information could be put into DT. Iirc some
> > > > > network devices get their MAC address from DT. Maybe we can
> > > > > add all NVS info to DT? How much data is it?
> > > > 
> > > > Proprietary, signed and closed bootloader NOLO does not support
> > > > DT. So for booting you need to append DTS file to kernel
> > > > image.
> > > 
> > > Yeah, so NOLO without U-Boot will depend on userspace to fixup
> > > DT.
> > > 
> > > > U-Boot is optional and can be used as intermediate bootloader
> > > > between NOLO and kernel. But still it has problems with reading
> > > > from nand, so cannot read NVS data nor MAC address.
> > > 
> > > It may in the future?
> > 
> > I already tried that, but I failed. I was not able to access N900's
> > nand from u-boot. No idea where was problem...
> > 
> > And if somebody fix onenand in u-boot, then needs to reimplement
> > Nokia's proprietary parser of that partition where is stored NVS
> > and mac address && make this support in upstream u-boot.
> 
> Are we talking about this?
> 
> https://github.com/community-ssu/libcal/blob/master/cal.c
> 
> That's ~1k loc for read-only.

Yes. There is also read-only alternative library:
https://github.com/pali/0xFFFF/blob/master/src/cal.c

But still, this is proprietary format useful only for one device (or 
two) and I do not know if such thing could be accepted by u-boot 
developers...

> Getting NAND working looks harder than porting this to me.

Right.

> > So... I doubt it will be in any future.
> > 
> > + no men power
> 
> yeah :(
> 
> But with that reasoning you should just extract the NVS data
> from NAND and put it in your rootfs.

Not a clean solution. Some rootfs parts can used as readonly. And 
normally rootfs is flashed into nand, so I still will say that roofs 
(image) should not contain any device specific data.

> > > > > Userspace application can add all those information to the DT
> > > > > using a DT overlay. Also the u-boot could parse and add it at
> > > > > some point in the future.
> > > > 
> > > > In case when wl1251 is statically linked into kernel image, it
> > > > is loaded and initialized before even userspace applications
> > > > starts.
> > > > 
> > > > So no... adding NVS data or MAC address into DT or DT overlay
> > > > is not a solution.
> > > 
> > > Actually with data loaded from DT you *can* load data quite early
> > > in the boot process, while your suggestions always require
> > > userspace. So you argument against yourself?
> > 
> > You cannot add DTS in uboot (no support).
> 
> AFAIK that's supported:
> 
> http://www.denx.de/wiki/DULG/LinuxFDTBlob
> 
> "Note that U-Boot makes some automatic modifications to the blob
> before passing it to the kernel - mainly adding and modifying
> information that is learnt at run-time."

I mean we do not have support for due to n900 nand.

> > And if you modify DTS on running kernel from userspace, then it is
> > too late when wl1251 is statically linked into kernel image.
> > 
> > wl1251 will not wait until some userspace modify DTS and add
> > data...
> 
> if (nvs info missing)
>     return -EPROBE_DEFER;

Forever? Only N times? How long? Only N second?

Here we do not know if userspace is going to send data or not.

My guess is that such code will not be accepted into net/wireless 
subsystem or drivers by maintainers.

> > But request_firmware() in fallback mode *can* wait for userspace so
> > wl1251 can postpone its operation until mdev/udev/whatever starts
> > listening for events and push needed firmware data to kernel.
> 
> As you said one workaround is waiting. That's not a solution, that
> only works with request_firmware().

Yes, but request_firmware() uses interaction with userspace. Your 
proposed solution does not do any interaction with userspace that some 
process needs to fill missing data into DT.

And request_firmware() is already used for loading NVS data.

> > So no, there is no argument against... request_firmware() in
> > fallback mode with userspace helper is by design blocking and
> > waiting for userspace. But waiting for some change in DTS in
> > kernel is just nonsense.
> 
> I would just mark the wlan device with status = "disabled" and
> enable it in the overlay together with adding the NVS & MAC info.

So if you think that this solution make sense, we can wait what net 
wireless maintainers say about it...

For me it looks like that solution can be:

extending request_firmware() to use only userspace helper

and load mac address also via request_firmware() either by appending it 
into NVS data or via separate call

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [prev] | [next] | [standalone]

#1529627

Hi,

On Thu, Nov 24, 2016 at 04:20:45PM +0100, Pali Rohár wrote:
> Proprietary, signed and closed bootloader NOLO does not support DT. So
> for booting you need to append DTS file to kernel image.
> 
> U-Boot is optional and can be used as intermediate bootloader between
> NOLO and kernel. But still it has problems with reading from nand, so
> cannot read NVS data nor MAC address.

You could use kexec to pass the fixed DT.

A.

[toc] | [prev] | [next] | [standalone]

#1529446

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Thu, Nov 24, 2016 at 09:33:29AM +0100, Pali Rohár wrote:
> On Thursday 24 November 2016 08:51:04 Pavel Machek wrote:
> > Hi!
> > 
> > > > "ifconfig hw ether XX" normally sets the address. I guess that's
> > > > ioctl?
> > > 
> > > This sets temporary address and it is ioctl. IIRC same as what ethtool 
> > > uses. (ifconfig is already deprecated).
> > > 
> > > > And I guess we should use similar mechanism for permanent
> > > > address.
> > > 
> > > I'm not sure here... Above ioctl ↑↑↑ is for changing temporary mac 
> > > address. But here we do not want to change permanent mac address. We 
> > > want to tell kernel driver current permanent mac address which is
> > > stored
> > 
> > Well... I'd still use similar mechanism :-).
> 
> Thats problematic, because in time when wlan0 interface is registered
> into system and visible in ifconfig output it already needs to have
> permanent mac address assigned.
> 
> We should assign permanent mac address before wlan0 of wl1251 is
> registered into system.

You can just add the MAC address to the NVS data, which is also
required for the device initialization.

I wonder if those information could be put into DT. Iirc some
network devices get their MAC address from DT. Maybe we can add
all NVS info to DT? How much data is it?

Userspace application can add all those information to the DT
using a DT overlay. Also the u-boot could parse and add it at
some point in the future.

-- Sebastian

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web