It's always very enlightening to see how we are so different in this DIY hack-your-own-device philosophy.

AFAICR RPi was based on the ideology of making cool HW easily accessible to the general public, including kids. So just as a kid with a hammer, knife or fire will learn early on how easily it is to destroy something, or get burnt, that should not prevent us from allowing kids to use those most basic tools of life. Or making it harder for them to use and learn about them. So IMO and in this particular case, I simply don't see how the cmdline option obtained from proper documentation (with all above and beyond warnings) would possibly make this worse, than for people trying to force feed extra voltage to their RPis, using for example the far more dangerous, USB back-powering method, or double feeding from different sources. Not to mention how easy it is to abuse the GPIO's. Thus I find the above arguments for "making it more difficult"to implement, as exceptionally lame.

As a side note, for whoever happen to come across this thread.

I just added the boot config.txtoption: avoid_warnings=2and my god, finally all that kernel/dmesg garbage is gone! In addition it seem that the device is running smoother. Yes, it is throttled to 600 MHz, which I guess is by the firmware, but already running better. I still have to do some proper performance tests, but I really do think there is a performance hit, when those messages are enabled. The IO reaction just seem more jumpy and laggy while the kernel logs are spammed. (NB. I am still on 4.4.14.30 and not yet on the 4.14.34, where there were some sysfs and log fixes.) What is mysterious though, is why vcgencmd get_throttleis returning 0x0, when clearly the device is throttled.-- [EDIT] Thatoption turn off the throttling too, so the normal ondemandkernel (?) CPU governor is working as it should.

And then of course we have the highly entertaining car analogy. Today allcars are using the CAN BUS and most (even very old ones) have ODB2 access that can be used for all sorts of diagnostics, including to disable various warning lights. You can use your own $12 ODB2 BT dongle and disable any warning with your own phone. And anyone who has had an Audi, VW or BMW also know that some of those engine warning lights come on for absolutely no other reason than annoyance, in order to ask the owner to take the car to their own service centers for checkup after some X miles and force you to pump in extra $$$ for the vendors. (A strategy very similar to having to buy the RPi foundation's magic 5.4V/2.5A power supply.)

Optional Step: Turn off Power Management 

If you have any issues with your Wi-Fi adapter dropping connections or becoming unresponsive, it may be the driver's power management setting causing you problems.

You can turn off power management by simply creating a new file with a line of text inside it.

Enter the following command to create this new file:

sudo nano /etc/modprobe.d/8192cu.conf

Then enter the following line of text:

options 8192cu rtw_power_mgnt=0 rtw_enusbss=0 rtw_ips_mode=1

Once again exit the file using Ctrl+X and save under the same name.

Reboot Your Raspberry Pi 

That's everything you need to do to set up a Wi-Fi adapter, so now we need to reboot the Pi to put all of these changes into effect.

Type the following command in the terminal to reboot, then hit Enter:

sudo reboot

Your Pi should restart and connect to your network within a minute or so.

There's four parms listed in the document you cite.

Code: Select all

rtw_power_mgnt=0|1|2

• 0 == disable power saving
• 1 == power saving on, minPS
• 2 == power saving on, maxPS

Code: Select all

rtw_enusbss=0|1

• 0 == disable auto suspend
• 1 == enable auto suspend

Code: Select all

rtw_hwpwrp_detect=0|1

• 0 == disable HW power pin detection
• 1 == enable HW power pin detection

Code: Select all

rtw_ips_mode=0|1

• 0 == low power, IPS_NORMAL
• 1 == higher power, IPS_LEVEL2

The conventional wisdom, because we're running our RPis as server systems not clients, is to set rtw_power_mgnt=0 and rtw_enusbss=0 to prevent the dongle going into power saving and to ignore the other two parms because they don't make any difference. If the server goes into power saving we'd need a process to wake it up. That's different from a client system where interaction from a keyboard user will trigger a request to wake up and associate the dongle.