Intelligent small switch Rfkill in Linux

Intelligent Small Switch rfkill in Linux

rfkill , where rf Yes radio frequency ( RF ) Span style= "Font-family:times New Roman" >) android mobile phone's notification bar can be easily switched airplane/bt/wifi/data/gps android system upper layer unified implementation, corresponding to linux The kernel was previously without a unified implementation, As the situation increases, there are specialized subsystems to centralize this functionality. This is the work of rfkill

In several of these control examples, perhaps each of these functions was invented as a revolution, the principle or even configuration may be quite complex, but for the end user, the most used is the "switch".

Use the example to monitor the wireless network card hardware changes:

$ rfkill

Usage:rfkill [Options] Command

Options:

--version Show Version (0.4-1UBUNTU3 (Ubuntu))

Commands:

Help

Event

list [IDENTIFIER]

Block IDENTIFIER

Unblock IDENTIFIER

Where IDENTIFIER is the index No. of an rfkill switch or one of:

<idx> all WiFi WLAN bluetooth UWB ultrawideband WiMAX WWAN GPS FM

$ Rfkill Event

1412007426.882932:idx 0 Type 1 op 0 soft 0 Hard 0

1412007465.911313:idx 0 Type 1 op 2 soft 0 hard 1

1412007605.911553:idx 0 Type 1 op 2 soft 0 hard 0

1412007705.911463:idx 0 Type 1 op 2 soft 0 hard 1

1412007715.911449:idx 0 Type 1 op 2 soft 0 hard 0

$

After the driver has realized the complex characteristic, it is better to perfect a rfkill driver. the Rfkill principle is nothing more than a classin a new sys file system . Located in /sys/class/rfkill/. Because it is small, so the said thing is not particularly many, but because it caused a period of experience to people worried, the focus of writing down.

Write in the back:

The source of this research is a strange phenomenon that occurs when a BT driver is transplanted. Because only the system version is upgraded (from Android4.2 to Android4.4), you can be sure that the hardware is intact. The corresponding driver is first configured, and the BT test is normal after burning the system . Out of the "Don't fool" mentality, I decided to reverse test, in the kernel after the bt - related options are removed, the test results BT really can not be used Again, adding the drive configuration unexpectedly will still not open properly. Then immediately fallback to the version, the test before the normal kernel, the result is successfully opened the device. I began to think,BT IC is my use of software configuration is broken? When this strange incident, the answer is usually in the toilet or on the way to the toilet, I have to go there to find, by the way, wash the face, find the probability will be higher.

The toilet still gave me some advice, first confirm BT hardware IC in the End There is no problem, the system completely burned back to the Android4.2 System, the test results are normal. I was relieved, and then using the second test of the weird event, the previous system image was burned in turn, and the first machine was the same. It's time to be smart at this moment: once the image is running without a BT Drive, then burning the driver with BT Drive will not open the drive --BT The chip does not reset!!! This is my guess, immediately completely power off again, originally contains bt driver can not normally open the system image of BT can open normally.

Considering the previous verification results as the starting point, I re-burn the system image by pressing the "Restart key" (called Reset key on the hardware) for a system restart, and now find that it will cause a problem.BTWhy not reset when the reset button is pressed? This is also just hypothetical, multimeter waiting! First, no matter how the circuit is connected, direct testingBTReset PIN, the voltage does not change from high to low when the reset key is pressed. Once this is confirmed, check the schematic to learn that the originalBTThe reset pin is not connected to the total reset key, but is connected to theCPUof aGPIOon, and then according to thisGPIOthe name is isolated onAndroid4.2in the kernel driver is to be registered as aRfkillinBTof theResetof the PIN. After doing all the problems were solved.

I had the impression that all of the IC 's reset pins on a circuit board are uniformly connected to the user's reset switch! This time I have known all along is only the familiar rfkill. The original BT IC has been no power and RESET caused no way to open normally.

Intelligent small switch Rfkill in Linux