rtwn: print out the firmware file being loaded

[adrian]

Summary

The firmware version isn't enough; different firmware is loaded
for different revisions of a given chip. So print out the file too;
it'll make handling reports much easier.

[emaste]

Do you have a sample of the full message?

[bz]

Given this is a RTWN_DPRINTF I don't see how that will help any reports.
But if you boot -v (bootverbose) you'll get reports like:

firmware: 'rtwn-rtl8821aufw' version 111: 27804 bytes loaded at 0xffffffff83878000

Is that helpful? Maybe we should add a if (bootverbose) to print this information like other drivers do?

[adrian]

In D48067#1097443, @bz wrote:

Given this is a RTWN_DPRINTF I don't see how that will help any reports.
But if you boot -v (bootverbose) you'll get reports like:

firmware: 'rtwn-rtl8821aufw' version 111: 27804 bytes loaded at 0xffffffff83878000

Is that helpful? Maybe we should add a if (bootverbose) to print this information like other drivers do?

Ah, yes. So, the firmware gets loaded when the NIC is brought up, so you CAN set a debug flag before you start wifi.

Honestly though, I think having the wifi firmware version and some basic NIC information available even without bootverbose would be good. bootverbose gets VERY verbose for the whole boot, and stuff like the PCI enumeration, audio mux setup, etc quickly swamps everything else.

[imp]

In D48067#1098384, @adrian wrote:

In D48067#1097443, @bz wrote:

Given this is a RTWN_DPRINTF I don't see how that will help any reports.
But if you boot -v (bootverbose) you'll get reports like:

firmware: 'rtwn-rtl8821aufw' version 111: 27804 bytes loaded at 0xffffffff83878000

Is that helpful? Maybe we should add a if (bootverbose) to print this information like other drivers do?

Ah, yes. So, the firmware gets loaded when the NIC is brought up, so you CAN set a debug flag before you start wifi.

Honestly though, I think having the wifi firmware version and some basic NIC information available even without bootverbose would be good. bootverbose gets VERY verbose for the whole boot, and stuff like the PCI enumeration, audio mux setup, etc quickly swamps everything else.

Maybe we want add a general firmware sysctl for that? And some per device type specials like toy suggested.

[bz]

In D48067#1098384, @adrian wrote:

In D48067#1097443, @bz wrote:

Given this is a RTWN_DPRINTF I don't see how that will help any reports.
But if you boot -v (bootverbose) you'll get reports like:

firmware: 'rtwn-rtl8821aufw' version 111: 27804 bytes loaded at 0xffffffff83878000

Is that helpful? Maybe we should add a if (bootverbose) to print this information like other drivers do?

Ah, yes. So, the firmware gets loaded when the NIC is brought up, so you CAN set a debug flag before you start wifi.

Honestly though, I think having the wifi firmware version and some basic NIC information available even without bootverbose would be good.

Right but then DPRINTF seems to be the wrong thing to use for printing the extra information.

[fuz]

This looks reasonable.

[adrian]

In D48067#1098399, @bz wrote:

Honestly though, I think having the wifi firmware version and some basic NIC information available even without bootverbose would be good.

Right but then DPRINTF seems to be the wrong thing to use for printing the extra information.

*nod* I don't mind turning this into "just print the firmware info always" with the filename too, what do you think?

[imp]

In D48067#1099602, @adrian wrote:

In D48067#1098399, @bz wrote:

Honestly though, I think having the wifi firmware version and some basic NIC information available even without bootverbose would be good.

Right but then DPRINTF seems to be the wrong thing to use for printing the extra information.

*nod* I don't mind turning this into "just print the firmware info always" with the filename too, what do you think?

I think that's acceptable. However, that suggests that we also want a firmware_filename sysctl to report this out. IIRC, many other NIC drivers do this.

[adrian]

In D48067#1099605, @imp wrote:

In D48067#1099602, @adrian wrote:

*nod* I don't mind turning this into "just print the firmware info always" with the filename too, what do you think?

I think that's acceptable. However, that suggests that we also want a firmware_filename sysctl to report this out. IIRC, many other NIC drivers do this.

do you have an example in mind i should follow?

[bz]

In D48067#1099605, @imp wrote:

I think that's acceptable. However, that suggests that we also want a firmware_filename sysctl to report this out. IIRC, many other NIC drivers do this.

A lot of drivers also "remove" the firmware again from memory once downloaded to the chip (in the .ko times that also meant unload the module again). Does that mean we'd need to cache the information somewhere?

[adrian]

Note: this is useful information /with/ the build info, and perhaps some chipset specific stuff like the mac ID / chip revision ID that identifies chip versions / production lines. This stuff will all aid in figuring out regressions / bugs when things work for A but not for B.

[emaste]

Open questions about printing always, having a sysctl etc. but regardless of that this is an incremental improvement.

[adrian]

Yeah let's land this and then figure out some further useful diagnostics for bug reports. thanks.