* How to debug/show status of intel wifi card?
From: Tetsuji Rai @ 2019-06-10 6:22 UTC (permalink / raw)
To: linux-wireless
Hi all,
I installed kernel-5.2-rc4 and found my intel wireless-ac 7260 card
stops working a moment (some seconds or minutes) after some browsing on
chrome or receiving emails on thunderbird or any other file transfer.
After turning the wifi off and on again, it starts working again, a
short while. It doesn't happen with the stable kernel 5.1.8.
I filed it bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=203851
but I still can't grasp the status of my wifi card while it's locked.
ifconfig, iwconfig, ethtool, trace-cmd show nothing abnormal even when
the wifi card is locked. They say my wifi card detects radio signal
correctly, transfer mode is correct.
So will you tell me how to see what happens with my wifi card? It
should be something like a bug of the new kernel.
Thanks in advance!
-Tetsuji Rai
^ permalink raw reply
* Re: Should b44_init lead to WARN_ON in drivers/ssb/driver_gpio.c:464?
From: H Buus @ 2019-06-10 5:40 UTC (permalink / raw)
To: Larry Finger, Michael Büsch
Cc: Kalle Valo, Michael Chan, linux-wireless, netdev
In-Reply-To: <4fdd3b06-f3f7-87e0-93be-c5d6f2bf5ab4@lwfinger.net>
On 6/9/2019 8:13 PM, Larry Finger wrote:
> On 6/9/19 4:57 PM, Michael Büsch wrote:
>> On Sun, 9 Jun 2019 17:44:10 -0400
>> H Buus <ubuntu@hbuus.com> wrote:
>>
>>> I have an old 32 bit laptop with a BCM4401-B0 100Base-TX ethernet
>>> controller. For every kernel from 4.19-rc1 going forward, I get a
>>> warning and call trace within a few seconds of start up (see dmesg
>>> snippet below). I have traced it to a specific commit (see commit
>>> below). On the face of it, I would think it is a regression, but it
>>> doesn't seem to cause a problem, since networking over ethernet is
>>> working.
>>
>>
>> This warning is not a problem. The commit just exposes a warning, that
>> has always been there.
>> I suggest we just remove the WARN_ON from ssb_gpio_init and
>> ssb_gpio_unregister.
>> I don't see a reason to throw a warning in that case.
>
> Michael,
>
> I agree. Do you want to prepare the patch, or should I?
>
> Larry
Let me know if you would like me to verify a patch when/if it is
available. Since kernels 4.19 thru 5.1 are unstable on this laptop, I
would either need to test with a 4.18 or older kernel, or limit my
testing to recovery mode & verifying that the b44 module is initialized
without causing a warning & call trace. Unless I get lucky and figure
out what commit is making newer kernels unstable on this laptop.
^ permalink raw reply
* possible fix for broken cmac crypto support
From: Sebastian Gottschall @ 2019-06-10 5:11 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Ryder Lee, Felix Fietkau, Roy Luo, YF Luo, Yiwei Chung, Sean Wang,
Chih-Min Chen, linux-wireless, linux-mediatek,
Linux Kernel Mailing List
In-Reply-To: <0eea6d21-1de2-abc3-93f4-70ed04dac3df@newmedia-net.de>
this is no real patch for this mailing list since i havent cloned yet a
git tree. take it as a hint
this fixes the BUG WARN if SAE encryption is used (mandatory for mesh /
802.11s crypto)
that will not fix that mesh is not working (likelly just with other
vendors), but it will fix crypto at least
Sebastian
Index: main.c
===================================================================
--- main.c (revision 4584)
+++ main.c (revision 4585)
@@ -180,6 +180,20 @@ static int mt7615_set_key(struct ieee80211_hw *hw,
!(key->flags & IEEE80211_KEY_FLAG_PAIRWISE))
return -EOPNOTSUPP;
+ switch (key->cipher) {
+ case WLAN_CIPHER_SUITE_WEP40:
+ case WLAN_CIPHER_SUITE_WEP104:
+ case WLAN_CIPHER_SUITE_TKIP:
+ case WLAN_CIPHER_SUITE_CCMP:
+ case WLAN_CIPHER_SUITE_CCMP_256:
+ case WLAN_CIPHER_SUITE_GCMP:
+ case WLAN_CIPHER_SUITE_GCMP_256:
+ case WLAN_CIPHER_SUITE_SMS4:
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
if (cmd == SET_KEY) {
key->hw_key_idx = wcid->idx;
wcid->hw_key_idx = idx;
Am 09.06.2019 um 16:36 schrieb Sebastian Gottschall:
> by the way. this big fat kernel warning exists in all operation modes
> unless anything else but aes-128 ccmp is used. since the chipset is
> capable of doing gcmp etc. as well
> it would be nice if this issue can be fixed. otherwise encryption
> support can be defined as "broken" for mt7615
>
> Am 06.06.2019 um 18:19 schrieb Lorenzo Bianconi:
>>> i tested your patch against a qca 9984 chipset using SAE and without
>>> encryption. both did not work. the devices are connecting, but no data
>>> connection is possible
>> Hi Sebastian,
>>
>> I tested Ryder's patch using mt76x2 as mesh peer and it works fine
>> for me.
>> Could you please provide some more info?
>>
>> Regards,
>> Lorenzo
>>
>>>
>>> Sebastian
>>>
>>> Am 03.06.2019 um 08:08 schrieb Ryder Lee:
>>>> Enable NL80211_IFTYPE_MESH_POINT and update its path.
>>>>
>>>> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
>>>> ---
>>>> Changes since v3 - fix a wrong expression
>>>> Changes since v2 - remove unused definitions
>>>> ---
>>>> drivers/net/wireless/mediatek/mt76/mt7615/init.c | 6 ++++++
>>>> drivers/net/wireless/mediatek/mt76/mt7615/main.c | 1 +
>>>> drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 4 +++-
>>>> drivers/net/wireless/mediatek/mt76/mt7615/mcu.h | 6 ------
>>>> 4 files changed, 10 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
>>>> b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
>>>> index 59f604f3161f..f860af6a42da 100644
>>>> --- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
>>>> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
>>>> @@ -133,6 +133,9 @@ static const struct ieee80211_iface_limit
>>>> if_limits[] = {
>>>> {
>>>> .max = MT7615_MAX_INTERFACES,
>>>> .types = BIT(NL80211_IFTYPE_AP) |
>>>> +#ifdef CONFIG_MAC80211_MESH
>>>> + BIT(NL80211_IFTYPE_MESH_POINT) |
>>>> +#endif
>>>> BIT(NL80211_IFTYPE_STATION)
>>>> }
>>>> };
>>>> @@ -195,6 +198,9 @@ int mt7615_register_device(struct mt7615_dev *dev)
>>>> dev->mt76.antenna_mask = 0xf;
>>>>
>>>> wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
>>>> +#ifdef CONFIG_MAC80211_MESH
>>>> + BIT(NL80211_IFTYPE_MESH_POINT) |
>>>> +#endif
>>>> BIT(NL80211_IFTYPE_AP);
>>>>
>>>> ret = mt76_register_device(&dev->mt76, true, mt7615_rates,
>>>> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
>>>> b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
>>>> index b0bb7cc12385..585e67fa2728 100644
>>>> --- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
>>>> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
>>>> @@ -37,6 +37,7 @@ static int get_omac_idx(enum nl80211_iftype type,
>>>> u32 mask)
>>>>
>>>> switch (type) {
>>>> case NL80211_IFTYPE_AP:
>>>> + case NL80211_IFTYPE_MESH_POINT:
>>>> /* ap use hw bssid 0 and ext bssid */
>>>> if (~mask & BIT(HW_BSSID_0))
>>>> return HW_BSSID_0;
>>>> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
>>>> b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
>>>> index 43f70195244c..e82297048449 100644
>>>> --- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
>>>> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
>>>> @@ -754,6 +754,7 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev
>>>> *dev,
>>>>
>>>> switch (vif->type) {
>>>> case NL80211_IFTYPE_AP:
>>>> + case NL80211_IFTYPE_MESH_POINT:
>>>> tx_wlan_idx = mvif->sta.wcid.idx;
>>>> conn_type = CONNECTION_INFRA_AP;
>>>> break;
>>>> @@ -968,7 +969,7 @@ int mt7615_mcu_add_wtbl(struct mt7615_dev *dev,
>>>> struct ieee80211_vif *vif,
>>>> .rx_wtbl = {
>>>> .tag = cpu_to_le16(WTBL_RX),
>>>> .len = cpu_to_le16(sizeof(struct wtbl_rx)),
>>>> - .rca1 = vif->type != NL80211_IFTYPE_AP,
>>>> + .rca1 = vif->type == NL80211_IFTYPE_STATION,
>>>> .rca2 = 1,
>>>> .rv = 1,
>>>> },
>>>> @@ -1042,6 +1043,7 @@ static void sta_rec_convert_vif_type(enum
>>>> nl80211_iftype type, u32 *conn_type)
>>>> {
>>>> switch (type) {
>>>> case NL80211_IFTYPE_AP:
>>>> + case NL80211_IFTYPE_MESH_POINT:
>>>> if (conn_type)
>>>> *conn_type = CONNECTION_INFRA_STA;
>>>> break;
>>>> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
>>>> b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
>>>> index e96efb13fa4d..0915cb735699 100644
>>>> --- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
>>>> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
>>>> @@ -105,25 +105,19 @@ enum {
>>>> #define STA_TYPE_STA BIT(0)
>>>> #define STA_TYPE_AP BIT(1)
>>>> #define STA_TYPE_ADHOC BIT(2)
>>>> -#define STA_TYPE_TDLS BIT(3)
>>>> #define STA_TYPE_WDS BIT(4)
>>>> #define STA_TYPE_BC BIT(5)
>>>>
>>>> #define NETWORK_INFRA BIT(16)
>>>> #define NETWORK_P2P BIT(17)
>>>> #define NETWORK_IBSS BIT(18)
>>>> -#define NETWORK_MESH BIT(19)
>>>> -#define NETWORK_BOW BIT(20)
>>>> #define NETWORK_WDS BIT(21)
>>>>
>>>> #define CONNECTION_INFRA_STA (STA_TYPE_STA | NETWORK_INFRA)
>>>> #define CONNECTION_INFRA_AP (STA_TYPE_AP | NETWORK_INFRA)
>>>> #define CONNECTION_P2P_GC (STA_TYPE_STA | NETWORK_P2P)
>>>> #define CONNECTION_P2P_GO (STA_TYPE_AP | NETWORK_P2P)
>>>> -#define CONNECTION_MESH_STA (STA_TYPE_STA | NETWORK_MESH)
>>>> -#define CONNECTION_MESH_AP (STA_TYPE_AP | NETWORK_MESH)
>>>> #define CONNECTION_IBSS_ADHOC (STA_TYPE_ADHOC | NETWORK_IBSS)
>>>> -#define CONNECTION_TDLS (STA_TYPE_STA | NETWORK_INFRA
>>>> | STA_TYPE_TDLS)
>>>> #define CONNECTION_WDS (STA_TYPE_WDS | NETWORK_WDS)
>>>> #define CONNECTION_INFRA_BC (STA_TYPE_BC | NETWORK_INFRA)
>>>>
>
^ permalink raw reply
* Re: [PATCH] mt76: mt7615: add support for per-chain signal strength reporting
From: Sebastian Gottschall @ 2019-06-10 4:47 UTC (permalink / raw)
To: Ryder Lee
Cc: Sean Wang, Chih-Min Chen, YF Luo, linux-wireless, linux-kernel,
Yiwei Chung, linux-mediatek, Roy Luo, Lorenzo Bianconi,
Felix Fietkau
In-Reply-To: <1560140541.5606.12.camel@mtkswgap22>
okay. curious is, that my variant works with sane results too.
i will test your variant and check the results
Sebastian
Am 10.06.2019 um 06:22 schrieb Ryder Lee:
> On Mon, 2019-06-10 at 10:09 +0800, Ryder Lee wrote:
>> On Sun, 2019-06-09 at 16:44 +0200, Sebastian Gottschall wrote:
>>> according to my findings
>>>
>>> MT_RXV4_RCPI1 is part of rx descriptor 4 and not 3
>>> so it must be rxdg4 = rxd[4] etc.
>> RXV start from 1 in the code.
>>
>> That is: RXV1 <-> rxdg0, RXV2 <-> rxdg1 ...so RXV4 <-> rxdg3
>>
>>> however rxdg3 contains MT_RXV3_IB_RSSIRX which can be used for signal calculation.
>>> i already wrote a similar code for this driver which i sended to felix a long time ago.
>>> my variant looks like
>>> status->signal = (FIELD_GET(MT_RXV3_IB_RSSIRX, rxdg3) - 220) / 2;
>>> status->chain_signal[0] = (FIELD_GET(MT_RXV4_RCPI0, rxdg4) - 220) / 2;
>>> status->chain_signal[1] = (FIELD_GET(MT_RXV4_RCPI1, rxdg4) - 220) / 2;
>>> status->chain_signal[2] = (FIELD_GET(MT_RXV4_RCPI2, rxdg4) - 220) / 2;
>>> status->chain_signal[3] = (FIELD_GET(MT_RXV4_RCPI3, rxdg4) - 220) / 2;
> mt7615 actually doesn't use in-band RSSI for signal calculation, but it
> occurs to me that i should modify the code to compare per-chain's
> signal. Something like this:
>
> status->chain_signal[0] = to_rssi(MT_RXV4_RCPI0, rxdg3);
> status->chain_signal[1] = to_rssi(MT_RXV4_RCPI1, rxdg3);
> status->chain_signal[2] = to_rssi(MT_RXV4_RCPI2, rxdg3);
> status->chain_signal[3] = to_rssi(MT_RXV4_RCPI3, rxdg3);
> status->signal = status->chain_signal[0];
>
> switch (status->chains) {
> case 0xf:
> status->signal = max(status->signal,
> status->chain_signal[3]);
> case 0x7:
> status->signal = max(status->signal,
> status->chain_signal[2]);
> case 0x3:
> status->signal = max(status->signal,
> status->chain_signal[1]);
> break;
> default:
> break;
> }
>
>
> I could send a v2 or you can take care of that.
>
> Ryder
>
>
^ permalink raw reply
* Re: [PATCH] mt76: mt7615: add support for per-chain signal strength reporting
From: Ryder Lee @ 2019-06-10 4:22 UTC (permalink / raw)
To: Sebastian Gottschall
Cc: Sean Wang, Chih-Min Chen, YF Luo, linux-wireless, linux-kernel,
Yiwei Chung, linux-mediatek, Roy Luo, Lorenzo Bianconi,
Felix Fietkau
In-Reply-To: <1560132590.28258.5.camel@mtkswgap22>
On Mon, 2019-06-10 at 10:09 +0800, Ryder Lee wrote:
> On Sun, 2019-06-09 at 16:44 +0200, Sebastian Gottschall wrote:
> > according to my findings
> >
> > MT_RXV4_RCPI1 is part of rx descriptor 4 and not 3
> > so it must be rxdg4 = rxd[4] etc.
>
> RXV start from 1 in the code.
>
> That is: RXV1 <-> rxdg0, RXV2 <-> rxdg1 ...so RXV4 <-> rxdg3
>
> > however rxdg3 contains MT_RXV3_IB_RSSIRX which can be used for signal calculation.
> > i already wrote a similar code for this driver which i sended to felix a long time ago.
> > my variant looks like
> > status->signal = (FIELD_GET(MT_RXV3_IB_RSSIRX, rxdg3) - 220) / 2;
> > status->chain_signal[0] = (FIELD_GET(MT_RXV4_RCPI0, rxdg4) - 220) / 2;
> > status->chain_signal[1] = (FIELD_GET(MT_RXV4_RCPI1, rxdg4) - 220) / 2;
> > status->chain_signal[2] = (FIELD_GET(MT_RXV4_RCPI2, rxdg4) - 220) / 2;
> > status->chain_signal[3] = (FIELD_GET(MT_RXV4_RCPI3, rxdg4) - 220) / 2;
mt7615 actually doesn't use in-band RSSI for signal calculation, but it
occurs to me that i should modify the code to compare per-chain's
signal. Something like this:
status->chain_signal[0] = to_rssi(MT_RXV4_RCPI0, rxdg3);
status->chain_signal[1] = to_rssi(MT_RXV4_RCPI1, rxdg3);
status->chain_signal[2] = to_rssi(MT_RXV4_RCPI2, rxdg3);
status->chain_signal[3] = to_rssi(MT_RXV4_RCPI3, rxdg3);
status->signal = status->chain_signal[0];
switch (status->chains) {
case 0xf:
status->signal = max(status->signal,
status->chain_signal[3]);
case 0x7:
status->signal = max(status->signal,
status->chain_signal[2]);
case 0x3:
status->signal = max(status->signal,
status->chain_signal[1]);
break;
default:
break;
}
I could send a v2 or you can take care of that.
Ryder
^ permalink raw reply
* ath6k : Error: Connection activation failed: (7) Secrets were required, but not provided.
From: Ken Harris @ 2019-06-10 2:54 UTC (permalink / raw)
To: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 2172 bytes --]
Wizards :
I'm trying to get the wireless on this "Dell Venue 8 Pro (5830)" tablet working.
It has ath6k chip (dmesg attached) :
[ 12.661190] ath6kl: ar6004 hw 3.0 sdio fw 3.5.0.349-1 api 5
[ 12.661206] ath6kl: firmware supports:
64bit-rates,map-lp-endpoint,ratetable-mcs15,no-ip-checksum
[ 12.661849] ath6kl: Firmware lacks RSN-CAP-OVERRIDE, so HT
(802.11n) is disabled.
It used to work intermittently (like 30 minutes on, then 30 minutes
off). I posted about this, but never figured it out.
I noticed it stopped working altogether.
Maybe it stopped working because I updated the software on tablet
(currently Fedora 5.1.6-300.fc30.x86_64 )
Maybe because I updated the Wi-Fi AP (currently OpenWRT 18.06.2 on
ath9k dual band). I did enable 802.11w on the AP.
All the other Wi-Fi devices (Linux laptops, Windoze 10 laptop, Android
phones, OpenWRT clients) on the net work, no problems.
When I do "nmcli c up db120" on the tablet , I get :
Error: Connection activation failed: Secrets were required, but not
provided
Hint: use 'journalctl -xe
NM_CONNECTION=8a528dcf-6c61-41fa-ab78-9d56ff9e7f1b + NM_DEVICE=wlan0'
to get more details
Some journalctl output (details attached) :
NetworkManager[543]: <info> device (wlan0): Activation: (wifi)
access point 'db120' has security, but secrets are required.
NetworkManager[543]: <info> device (wlan0): Activation: (wifi)
connection 'db120' has security, and secrets exist. No new secrets
needed.
The key file ( /etc/sysconfig/network-scripts/keys-db120 ) has the right value.
On the Wi-Fi AP, I get messages :
Sun Jun 9 18:21:50 2019 daemon.info hostapd: wlan0: STA
88:12:4e:01:94:88 IEEE 802.11: authenticated
Sun Jun 9 18:21:50 2019 daemon.info hostapd: wlan0: STA
88:12:4e:01:94:88 IEEE 802.11: No WPA/RSN IE in association request
I tried deleting and setting up the connection again :
nmcli connection delete id db120
nmcli device wifi connect db120 password mumble
... but still got the same message.
I installed ath6k/AR6004/hw3.0 firmware manually (it's not in Fedora
linux-firmware for some reason).
If I use a USB wired ethernet, it works fine.
Any tips are appreciated.
Thanks,
Ken
[-- Attachment #2: journalctl-dv8p-wlan0.txt --]
[-- Type: text/plain, Size: 7006 bytes --]
[root@dv8p network-scripts]# journalctl -xe NM_CONNECTION=8a528dcf-6c61-41fa-ab78-9d56ff9e7f1b + NM_DEVICE=wlan0
Jun 09 18:22:34 dv8p NetworkManager[543]: <info> [1560129754.4650] device (wlan0): state change: config -> deactivating (reason 'new-activation', sys-iface-state: 'managed')
Jun 09 18:22:34 dv8p NetworkManager[543]: <info> [1560129754.4681] device (wlan0): disconnecting for new activation request.
Jun 09 18:22:34 dv8p NetworkManager[543]: <info> [1560129754.4685] device (wlan0): state change: deactivating -> disconnected (reason 'new-activation', sys-iface-state: 'managed')
Jun 09 18:22:34 dv8p NetworkManager[543]: <warn> [1560129754.4753] device (wlan0): set-hw-addr: failed to set MAC address to 22:3D:91:79:9C:F3 (scanning) (NME_UNSPEC)
Jun 09 18:22:34 dv8p NetworkManager[543]: <info> [1560129754.4798] device (wlan0): Activation: starting connection 'db120' (8a528dcf-6c61-41fa-ab78-9d56ff9e7f1b)
Jun 09 18:22:34 dv8p NetworkManager[543]: <info> [1560129754.5017] device (wlan0): supplicant interface state: scanning -> inactive
Jun 09 18:22:34 dv8p NetworkManager[543]: <info> [1560129754.5034] device (wlan0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Jun 09 18:22:34 dv8p NetworkManager[543]: <info> [1560129754.5062] device (wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Jun 09 18:22:34 dv8p NetworkManager[543]: <info> [1560129754.5074] device (wlan0): Activation: (wifi) access point 'db120' has security, but secrets are required.
Jun 09 18:22:34 dv8p NetworkManager[543]: <info> [1560129754.5075] device (wlan0): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed')
Jun 09 18:22:34 dv8p NetworkManager[543]: <info> [1560129754.5123] device (wlan0): state change: need-auth -> prepare (reason 'none', sys-iface-state: 'managed')
Jun 09 18:22:34 dv8p NetworkManager[543]: <info> [1560129754.5135] device (wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Jun 09 18:22:34 dv8p NetworkManager[543]: <info> [1560129754.5144] device (wlan0): Activation: (wifi) connection 'db120' has security, and secrets exist. No new secrets needed.
Jun 09 18:22:36 dv8p NetworkManager[543]: <info> [1560129756.5491] device (wlan0): supplicant interface state: inactive -> scanning
Jun 09 18:22:38 dv8p NetworkManager[543]: <info> [1560129758.1116] device (wlan0): supplicant interface state: scanning -> associating
Jun 09 18:22:48 dv8p NetworkManager[543]: <info> [1560129768.1314] device (wlan0): supplicant interface state: associating -> disconnected
Jun 09 18:22:58 dv8p NetworkManager[543]: <info> [1560129778.1418] device (wlan0): supplicant interface state: disconnected -> scanning
Jun 09 18:22:59 dv8p NetworkManager[543]: <warn> [1560129779.4716] device (wlan0): Activation: (wifi) association took too long
Jun 09 18:22:59 dv8p NetworkManager[543]: <info> [1560129779.4718] device (wlan0): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed')
Jun 09 18:22:59 dv8p NetworkManager[543]: <warn> [1560129779.4768] device (wlan0): Activation: (wifi) asking for new secrets
Jun 09 18:22:59 dv8p NetworkManager[543]: <info> [1560129779.4838] device (wlan0): state change: need-auth -> prepare (reason 'none', sys-iface-state: 'managed')
Jun 09 18:22:59 dv8p NetworkManager[543]: <info> [1560129779.4866] device (wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Jun 09 18:22:59 dv8p NetworkManager[543]: <info> [1560129779.4880] device (wlan0): Activation: (wifi) connection 'db120' has security, and secrets exist. No new secrets needed.
Jun 09 18:22:59 dv8p NetworkManager[543]: <info> [1560129779.6987] device (wlan0): supplicant interface state: scanning -> associating
Jun 09 18:23:09 dv8p NetworkManager[543]: <info> [1560129789.7016] device (wlan0): supplicant interface state: associating -> disconnected
Jun 09 18:23:19 dv8p NetworkManager[543]: <info> [1560129799.7029] device (wlan0): supplicant interface state: disconnected -> scanning
Jun 09 18:23:21 dv8p NetworkManager[543]: <info> [1560129801.2521] device (wlan0): supplicant interface state: scanning -> associating
Jun 09 18:23:24 dv8p NetworkManager[543]: <warn> [1560129804.4722] device (wlan0): Activation: (wifi) association took too long
Jun 09 18:23:24 dv8p NetworkManager[543]: <info> [1560129804.4724] device (wlan0): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed')
Jun 09 18:23:24 dv8p NetworkManager[543]: <warn> [1560129804.4791] device (wlan0): Activation: (wifi) asking for new secrets
Jun 09 18:23:24 dv8p NetworkManager[543]: <warn> [1560129804.4796] sup-iface[0x55e3158eb0e0,wlan0]: connection disconnected (reason -3)
Jun 09 18:23:24 dv8p NetworkManager[543]: <info> [1560129804.4817] device (wlan0): supplicant interface state: associating -> disconnected
Jun 09 18:23:24 dv8p NetworkManager[543]: <info> [1560129804.4853] device (wlan0): state change: need-auth -> prepare (reason 'none', sys-iface-state: 'managed')
Jun 09 18:23:24 dv8p NetworkManager[543]: <info> [1560129804.4866] device (wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Jun 09 18:23:24 dv8p NetworkManager[543]: <info> [1560129804.4876] device (wlan0): Activation: (wifi) connection 'db120' has security, and secrets exist. No new secrets needed.
Jun 09 18:23:24 dv8p NetworkManager[543]: <info> [1560129804.5153] device (wlan0): supplicant interface state: disconnected -> associating
Jun 09 18:23:34 dv8p NetworkManager[543]: <info> [1560129814.5371] device (wlan0): supplicant interface state: associating -> disconnected
Jun 09 18:23:44 dv8p NetworkManager[543]: <info> [1560129824.5442] device (wlan0): supplicant interface state: disconnected -> scanning
Jun 09 18:23:46 dv8p NetworkManager[543]: <info> [1560129826.1141] device (wlan0): supplicant interface state: scanning -> associating
Jun 09 18:23:49 dv8p NetworkManager[543]: <warn> [1560129829.4724] device (wlan0): Activation: (wifi) association took too long
Jun 09 18:23:49 dv8p NetworkManager[543]: <info> [1560129829.4727] device (wlan0): state change: config -> failed (reason 'no-secrets', sys-iface-state: 'managed')
Jun 09 18:23:49 dv8p NetworkManager[543]: <warn> [1560129829.4820] device (wlan0): Activation: failed for connection 'db120'
Jun 09 18:23:49 dv8p NetworkManager[543]: <warn> [1560129829.4822] sup-iface[0x55e3158eb0e0,wlan0]: connection disconnected (reason -3)
Jun 09 18:23:49 dv8p NetworkManager[543]: <info> [1560129829.4846] device (wlan0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
Jun 09 18:23:49 dv8p NetworkManager[543]: <warn> [1560129829.4886] device (wlan0): set-hw-addr: failed to set MAC address to 66:4F:93:A6:ED:9E (scanning) (NME_UNSPEC)
Jun 09 18:23:49 dv8p NetworkManager[543]: <info> [1560129829.4915] device (wlan0): supplicant interface state: associating -> disconnected
[-- Attachment #3: dmesg-5.1.6-300.fc30.x86_64-dv8p.txt --]
[-- Type: text/plain, Size: 47985 bytes --]
[ 0.000000] Linux version 5.1.6-300.fc30.x86_64 (mockbuild@bkernel04.phx2.fedoraproject.org) (gcc version 9.1.1 20190503 (Red Hat 9.1.1-1) (GCC)) #1 SMP Fri May 31 17:43:23 UTC 2019
[ 0.000000] Command line: BOOT_IMAGE=(hd0,gpt3)/vmlinuz-5.1.6-300.fc30.x86_64 root=UUID=6d7e5437-2e43-4e3c-bb9e-56f1d698c0d1 ro rhgb quiet
[ 0.000000] x86/fpu: x87 FPU will use FXSAVE
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000008efff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000008f000-0x000000000008ffff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x0000000000090000-0x000000000009dfff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001fffffff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000020000000-0x00000000200fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000020100000-0x0000000078d3afff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000078d3b000-0x0000000078d6afff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000078d6b000-0x0000000078d97fff] ACPI data
[ 0.000000] BIOS-e820: [mem 0x0000000078d98000-0x00000000795f8fff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x00000000795f9000-0x00000000799fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000079a00000-0x0000000079a07fff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000079a08000-0x0000000079a08fff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000079a09000-0x0000000079b71fff] usable
[ 0.000000] BIOS-e820: [mem 0x0000000079b72000-0x0000000079ff9fff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000079ffa000-0x0000000079ffffff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000e00f8000-0x00000000e00f8fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed01000-0x00000000fed01fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000ffa00000-0x00000000ffffffff] reserved
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] efi: EFI v2.31 by American Megatrends
[ 0.000000] efi: ACPI=0x78d97000 ACPI 2.0=0x78d97014 ESRT=0x78d6a000 SMBIOS=0x79a08190 TPMEventLog=0x52805010
[ 0.000000] secureboot: Secure boot disabled
[ 0.000000] SMBIOS 2.7 present.
[ 0.000000] DMI: Dell Inc. Venue 8 Pro 5830/09RP78, BIOS A14 01/28/2016
[ 0.000000] tsc: Detected 1332.800 MHz processor
[ 0.000030] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[ 0.000036] e820: remove [mem 0x000a0000-0x000fffff] usable
[ 0.000055] last_pfn = 0x7a000 max_arch_pfn = 0x400000000
[ 0.000063] MTRR default type: uncachable
[ 0.000065] MTRR fixed ranges enabled:
[ 0.000069] 00000-9FFFF write-back
[ 0.000073] A0000-FFFFF write-protect
[ 0.000076] MTRR variable ranges enabled:
[ 0.000080] 0 base 000000000 mask FC0000000 write-back
[ 0.000084] 1 base 040000000 mask FE0000000 write-back
[ 0.000088] 2 base 060000000 mask FF0000000 write-back
[ 0.000092] 3 base 070000000 mask FF8000000 write-back
[ 0.000096] 4 base 070000000 mask FF8000000 write-back
[ 0.000099] 5 base 078000000 mask FFC000000 write-back
[ 0.000103] 6 base 07B000000 mask FFF000000 uncachable
[ 0.000107] 7 base 07AE00000 mask FFFE00000 uncachable
[ 0.000397] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT
[ 0.009869] esrt: ESRT header is not in the memory map.
[ 0.009893] BRK [0x05e01000, 0x05e01fff] PGTABLE
[ 0.009898] BRK [0x05e02000, 0x05e02fff] PGTABLE
[ 0.009902] BRK [0x05e03000, 0x05e03fff] PGTABLE
[ 0.010105] BRK [0x05e04000, 0x05e04fff] PGTABLE
[ 0.010114] BRK [0x05e05000, 0x05e05fff] PGTABLE
[ 0.010908] BRK [0x05e06000, 0x05e06fff] PGTABLE
[ 0.011324] BRK [0x05e07000, 0x05e07fff] PGTABLE
[ 0.011547] BRK [0x05e08000, 0x05e08fff] PGTABLE
[ 0.011995] BRK [0x05e09000, 0x05e09fff] PGTABLE
[ 0.012144] RAMDISK: [mem 0x5280c000-0x537cdfff]
[ 0.012155] ACPI: Early table checksum verification disabled
[ 0.012162] ACPI: RSDP 0x0000000078D97014 000024 (v02 DELL )
[ 0.012171] ACPI: XSDT 0x0000000078D74188 0000CC (v01 DELL WN09 00000003 MSFT 0100000D)
[ 0.012184] ACPI: FACP 0x0000000078D92000 00010C (v05 DELL WN09 00000003 AMI 0100000D)
[ 0.012198] ACPI: DSDT 0x0000000078D82000 00BB03 (v02 DELL A M I 00000003 AMI 0100000D)
[ 0.012208] ACPI: TCPA 0x0000000078D95000 000032 (v02 00000000 00000000)
[ 0.012217] ACPI: UEFI 0x0000000079593000 000042 (v01 00000000 00000000)
[ 0.012226] ACPI: MSDM 0x0000000078D94000 000055 (v03 DELL WN09 01072009 AMI 00010013)
[ 0.012236] ACPI: DBG2 0x0000000078D93000 000072 (v00 DELL INTLDBG2 00000003 AMI 0100000D)
[ 0.012245] ACPI: HPET 0x0000000078D91000 000038 (v01 DELL WN09 00000003 AMI 0100000D)
[ 0.012254] ACPI: LPIT 0x0000000078D90000 000104 (v01 DELL 00000003 AMI 0100000D)
[ 0.012263] ACPI: APIC 0x0000000078D8F000 00006C (v03 DELL 00000003 AMI 0100000D)
[ 0.012273] ACPI: MCFG 0x0000000078D8E000 00003C (v01 DELL 00000003 AMI 0100000D)
[ 0.012282] ACPI: SSDT 0x0000000078D81000 000673 (v01 DELL CpuDptf 00000003 AMI 0100000D)
[ 0.012291] ACPI: SSDT 0x0000000078D7F000 001A12 (v01 DELL DptfTab 00000003 AMI 0100000D)
[ 0.012300] ACPI: SSDT 0x0000000078D7E000 000058 (v01 DELL LowPwrM 00000003 AMI 0100000D)
[ 0.012310] ACPI: SSDT 0x0000000078D7D000 0000FF (v01 DELL SoCDptf 00000003 AMI 0100000D)
[ 0.012319] ACPI: FPDT 0x0000000078D7C000 000044 (v01 A M I ALASKA 01072009 AMI 00010013)
[ 0.012328] ACPI: SSDT 0x0000000078D7B000 000763 (v01 PmRef CpuPm 00003000 INTL 20061109)
[ 0.012337] ACPI: SSDT 0x0000000078D7A000 000290 (v01 PmRef Cpu0Tst 00003000 INTL 20061109)
[ 0.012347] ACPI: SSDT 0x0000000078D79000 00017A (v01 PmRef ApTst 00003000 INTL 20061109)
[ 0.012356] ACPI: SSDT 0x0000000078D78000 000427 (v01 Intel_ Tpm2Tabl 00001000 INTL 20061109)
[ 0.012365] ACPI: TPM2 0x0000000078D77000 000034 (v03 00000000 00000000)
[ 0.012375] ACPI: BGRT 0x0000000078D76000 000038 (v00 DELL A M I 01072009 AMI 00010013)
[ 0.012384] ACPI: CSRT 0x0000000078D75000 00014C (v00 ALASKA WN09 00000005 MSFT 0100000D)
[ 0.012407] ACPI: Local APIC address 0xfee00000
[ 0.012694] No NUMA configuration found
[ 0.012697] Faking a node at [mem 0x0000000000000000-0x0000000079ffffff]
[ 0.012726] NODE_DATA(0) allocated [mem 0x78b31000-0x78b5bfff]
[ 0.024254] Zone ranges:
[ 0.024258] DMA [mem 0x0000000000001000-0x0000000000ffffff]
[ 0.024263] DMA32 [mem 0x0000000001000000-0x0000000079ffffff]
[ 0.024266] Normal empty
[ 0.024269] Device empty
[ 0.024272] Movable zone start for each node
[ 0.024283] Early memory node ranges
[ 0.024286] node 0: [mem 0x0000000000001000-0x000000000008efff]
[ 0.024289] node 0: [mem 0x0000000000090000-0x000000000009dfff]
[ 0.024291] node 0: [mem 0x0000000000100000-0x000000001fffffff]
[ 0.024294] node 0: [mem 0x0000000020100000-0x0000000078d3afff]
[ 0.024297] node 0: [mem 0x0000000079a00000-0x0000000079a07fff]
[ 0.024299] node 0: [mem 0x0000000079a09000-0x0000000079b71fff]
[ 0.024302] node 0: [mem 0x0000000079ffa000-0x0000000079ffffff]
[ 0.024581] Zeroed struct page in unavailable ranges: 4786 pages
[ 0.024586] Initmem setup node 0 [mem 0x0000000000001000-0x0000000079ffffff]
[ 0.024591] On node 0 totalpages: 494926
[ 0.024594] DMA zone: 64 pages used for memmap
[ 0.024597] DMA zone: 28 pages reserved
[ 0.024600] DMA zone: 3996 pages, LIFO batch:0
[ 0.024947] DMA32 zone: 7744 pages used for memmap
[ 0.024950] DMA32 zone: 490930 pages, LIFO batch:63
[ 0.065921] x86/hpet: Will disable the HPET for this platform because it's not reliable
[ 0.065931] Reserving Intel graphics memory at [mem 0x7af00000-0x7eefffff]
[ 0.065993] ACPI: Local APIC address 0xfee00000
[ 0.066023] IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-86
[ 0.066029] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 0.066034] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 0.066040] Using ACPI (MADT) for SMP configuration information
[ 0.066044] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[ 0.066070] smpboot: Allowing 4 CPUs, 0 hotplug CPUs
[ 0.066136] PM: Registered nosave memory: [mem 0x00000000-0x00000fff]
[ 0.066143] PM: Registered nosave memory: [mem 0x0008f000-0x0008ffff]
[ 0.066150] PM: Registered nosave memory: [mem 0x0009e000-0x0009ffff]
[ 0.066152] PM: Registered nosave memory: [mem 0x000a0000-0x000fffff]
[ 0.066158] PM: Registered nosave memory: [mem 0x20000000-0x200fffff]
[ 0.066164] PM: Registered nosave memory: [mem 0x78d3b000-0x78d6afff]
[ 0.066167] PM: Registered nosave memory: [mem 0x78d6b000-0x78d97fff]
[ 0.066169] PM: Registered nosave memory: [mem 0x78d98000-0x795f8fff]
[ 0.066172] PM: Registered nosave memory: [mem 0x795f9000-0x799fffff]
[ 0.066178] PM: Registered nosave memory: [mem 0x79a08000-0x79a08fff]
[ 0.066184] PM: Registered nosave memory: [mem 0x79b72000-0x79ff9fff]
[ 0.066189] [mem 0x7ef00000-0xe00f7fff] available for PCI devices
[ 0.066192] Booting paravirtualized kernel on bare hardware
[ 0.066200] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns
[ 0.492395] random: get_random_bytes called from start_kernel+0x8f/0x512 with crng_init=0
[ 0.492421] setup_percpu: NR_CPUS:1024 nr_cpumask_bits:4 nr_cpu_ids:4 nr_node_ids:1
[ 0.493267] percpu: Embedded 45 pages/cpu s147456 r8192 d28672 u524288
[ 0.493292] pcpu-alloc: s147456 r8192 d28672 u524288 alloc=1*2097152
[ 0.493296] pcpu-alloc: [0] 0 1 2 3
[ 0.493395] Built 1 zonelists, mobility grouping on. Total pages: 487090
[ 0.493398] Policy zone: DMA32
[ 0.493402] Kernel command line: BOOT_IMAGE=(hd0,gpt3)/vmlinuz-5.1.6-300.fc30.x86_64 root=UUID=6d7e5437-2e43-4e3c-bb9e-56f1d698c0d1 ro rhgb quiet
[ 0.510478] Memory: 1801688K/1979704K available (12291K kernel code, 1536K rwdata, 4088K rodata, 2212K init, 4636K bss, 178016K reserved, 0K cma-reserved)
[ 0.511011] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.511027] Kernel/User page tables isolation: enabled
[ 0.511070] ftrace: allocating 39296 entries in 154 pages
[ 0.549555] rcu: Hierarchical RCU implementation.
[ 0.549560] rcu: RCU restricting CPUs from NR_CPUS=1024 to nr_cpu_ids=4.
[ 0.549562] Tasks RCU enabled.
[ 0.549564] rcu: RCU calculated value of scheduler-enlistment delay is 100 jiffies.
[ 0.549567] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[ 0.560315] NR_IRQS: 65792, nr_irqs: 1024, preallocated irqs: 0
[ 0.560443] Console: colour dummy device 80x25
[ 0.560452] printk: console [tty0] enabled
[ 0.560502] ACPI: Core revision 20190215
[ 0.560927] APIC: Switch to symmetric I/O mode setup
[ 0.560980] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x133626f6b26, max_idle_ns: 440795214178 ns
[ 0.561007] Calibrating delay loop (skipped), value calculated using timer frequency.. 2665.60 BogoMIPS (lpj=1332800)
[ 0.561013] pid_max: default: 32768 minimum: 301
[ 0.561985] LSM: Security Framework initializing
[ 0.561985] Yama: becoming mindful.
[ 0.561985] SELinux: Initializing.
[ 0.561985] *** VALIDATE SELinux ***
[ 0.561985] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
[ 0.561985] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
[ 0.561985] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.561985] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.561985] *** VALIDATE proc ***
[ 0.561985] *** VALIDATE cgroup1 ***
[ 0.561985] *** VALIDATE cgroup2 ***
[ 0.561985] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
[ 0.561985] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)
[ 0.561985] mce: CPU0: Thermal monitoring enabled (TM1)
[ 0.561985] process: using mwait in idle threads
[ 0.561985] Last level iTLB entries: 4KB 48, 2MB 0, 4MB 0
[ 0.561985] Last level dTLB entries: 4KB 128, 2MB 16, 4MB 16, 1GB 0
[ 0.561985] Spectre V2 : Mitigation: Full generic retpoline
[ 0.561985] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
[ 0.561985] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
[ 0.561985] Freeing SMP alternatives memory: 36K
[ 0.561985] TSC deadline timer enabled
[ 0.561985] smpboot: CPU0: Intel(R) Atom(TM) CPU Z3740D @ 1.33GHz (family: 0x6, model: 0x37, stepping: 0x3)
[ 0.561985] Performance Events: PEBS fmt2+, 8-deep LBR, Silvermont events, 8-deep LBR, full-width counters, Intel PMU driver.
[ 0.561985] ... version: 3
[ 0.561985] ... bit width: 40
[ 0.561985] ... generic registers: 2
[ 0.561985] ... value mask: 000000ffffffffff
[ 0.561985] ... max period: 0000007fffffffff
[ 0.561985] ... fixed-purpose events: 3
[ 0.561985] ... event mask: 0000000700000003
[ 0.561985] rcu: Hierarchical SRCU implementation.
[ 0.562895] random: crng done (trusting CPU's manufacturer)
[ 0.563442] NMI watchdog: Enabled. Permanently consumes one hw-PMU counter.
[ 0.563673] smp: Bringing up secondary CPUs ...
[ 0.564067] x86: Booting SMP configuration:
[ 0.564070] .... node #0, CPUs: #1 #2 #3
[ 0.565470] smp: Brought up 1 node, 4 CPUs
[ 0.565470] smpboot: Max logical packages: 1
[ 0.565470] smpboot: Total of 4 processors activated (10662.40 BogoMIPS)
[ 0.566598] devtmpfs: initialized
[ 0.567105] x86/mm: Memory block size: 128MB
[ 0.567823] PM: Registering ACPI NVS region [mem 0x0008f000-0x0008ffff] (4096 bytes)
[ 0.567823] PM: Registering ACPI NVS region [mem 0x78d98000-0x795f8fff] (8785920 bytes)
[ 0.568532] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns
[ 0.568532] futex hash table entries: 1024 (order: 4, 65536 bytes)
[ 0.568532] pinctrl core: initialized pinctrl subsystem
[ 0.569111] PM: RTC time: 00:05:54, date: 2019-06-10
[ 0.569522] NET: Registered protocol family 16
[ 0.569682] audit: initializing netlink subsys (disabled)
[ 0.569709] audit: type=2000 audit(1560125154.008:1): state=initialized audit_enabled=0 res=1
[ 0.570103] cpuidle: using governor menu
[ 0.570227] ACPI: bus type PCI registered
[ 0.570231] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[ 0.570426] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[ 0.570461] PCI: not using MMCONFIG
[ 0.570465] PCI: Using configuration type 1 for base access
[ 0.575312] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[ 0.576016] cryptd: max_cpu_qlen set to 1000
[ 0.576216] ACPI: Added _OSI(Module Device)
[ 0.576219] ACPI: Added _OSI(Processor Device)
[ 0.576222] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 0.576224] ACPI: Added _OSI(Processor Aggregator Device)
[ 0.576228] ACPI: Added _OSI(Linux-Dell-Video)
[ 0.576231] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
[ 0.576233] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
[ 0.599798] ACPI: 9 ACPI AML tables successfully acquired and loaded
[ 0.606922] ACPI: Dynamic OEM Table Load:
[ 0.606941] ACPI: SSDT 0xFFFF9124363AC800 00045B (v01 PmRef Cpu0Ist 00003000 INTL 20061109)
[ 0.607961] ACPI: Dynamic OEM Table Load:
[ 0.607977] ACPI: SSDT 0xFFFF9124363A9800 000433 (v01 PmRef Cpu0Cst 00003001 INTL 20061109)
[ 0.609389] ACPI: Dynamic OEM Table Load:
[ 0.609405] ACPI: SSDT 0xFFFF912435C20A00 00015F (v01 PmRef ApIst 00003000 INTL 20061109)
[ 0.610064] ACPI: Dynamic OEM Table Load:
[ 0.610079] ACPI: SSDT 0xFFFF9124363DBCC0 00008D (v01 PmRef ApCst 00003000 INTL 20061109)
[ 0.613946] ACPI: Interpreter enabled
[ 0.613985] ACPI: (supports S0)
[ 0.613993] ACPI: Using IOAPIC for interrupt routing
[ 0.614101] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[ 0.624626] [Firmware Info]: PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] not reserved in ACPI motherboard resources
[ 0.624631] PCI: not using MMCONFIG
[ 0.624641] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 0.632057] ACPI: Power Resource [USBC] (on)
[ 0.632857] ACPI: Power Resource [WWPR] (off)
[ 0.639124] ACPI: Power Resource [PLPE] (on)
[ 0.649674] ACPI: Power Resource [CLK0] (on)
[ 0.649790] ACPI: Power Resource [CLK1] (on)
[ 0.650070] ACPI: Power Resource [P28X] (off)
[ 0.650182] ACPI: Power Resource [P18X] (off)
[ 0.652226] ACPI: Power Resource [TCPR] (off)
[ 0.659215] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[ 0.659228] acpi PNP0A08:00: _OSC: OS supports [ASPM ClockPM Segments MSI]
[ 0.659359] acpi PNP0A08:00: _OSC failed (AE_ERROR); disabling ASPM
[ 0.659389] acpi PNP0A08:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.
[ 0.660374] PCI host bridge to bus 0000:00
[ 0.660381] pci_bus 0000:00: root bus resource [io 0x0070-0x0077]
[ 0.660386] pci_bus 0000:00: root bus resource [io 0x0000-0x006f window]
[ 0.660391] pci_bus 0000:00: root bus resource [io 0x0078-0x0cf7 window]
[ 0.660395] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window]
[ 0.660400] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
[ 0.660404] pci_bus 0000:00: root bus resource [mem 0x000c0000-0x000dffff window]
[ 0.660408] pci_bus 0000:00: root bus resource [mem 0x000e0000-0x000fffff window]
[ 0.660412] pci_bus 0000:00: root bus resource [mem 0x90c00000-0x90ffffff window]
[ 0.660416] pci_bus 0000:00: root bus resource [mem 0x7af00001-0x7ef00000 window]
[ 0.660420] pci_bus 0000:00: root bus resource [mem 0x80000000-0x908ffffe window]
[ 0.660424] pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfed40fff window]
[ 0.660429] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 0.660445] pci 0000:00:00.0: [8086:0f00] type 00 class 0x060000
[ 0.660713] pci 0000:00:02.0: [8086:0f31] type 00 class 0x030000
[ 0.660734] pci 0000:00:02.0: reg 0x10: [mem 0x90000000-0x903fffff]
[ 0.660748] pci 0000:00:02.0: reg 0x18: [mem 0x80000000-0x8fffffff pref]
[ 0.660762] pci 0000:00:02.0: reg 0x20: [io 0x1000-0x1007]
[ 0.660789] pci 0000:00:02.0: BAR 2: assigned to efifb
[ 0.661046] pci 0000:00:14.0: [8086:0f35] type 00 class 0x0c0330
[ 0.661074] pci 0000:00:14.0: reg 0x10: [mem 0x90800000-0x9080ffff 64bit]
[ 0.661149] pci 0000:00:14.0: PME# supported from D3hot D3cold
[ 0.661396] pci 0000:00:1a.0: [8086:0f18] type 00 class 0x108000
[ 0.661425] pci 0000:00:1a.0: reg 0x10: [mem 0x90700000-0x907fffff]
[ 0.661439] pci 0000:00:1a.0: reg 0x14: [mem 0x90600000-0x906fffff]
[ 0.661535] pci 0000:00:1a.0: PME# supported from D0 D3hot
[ 0.661768] pci 0000:00:1f.0: [8086:0f1c] type 00 class 0x060100
[ 0.663139] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[ 0.663339] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[ 0.663536] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[ 0.663734] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[ 0.663932] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[ 0.664139] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[ 0.664339] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[ 0.664552] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 10 11 12 14 15) *0, disabled.
[ 0.667111] gpio gpiochip1: (INT33FC:01): detected irqchip that is shared with multiple gpiochips: please fix the driver.
[ 0.668207] gpio gpiochip2: (INT33FC:02): detected irqchip that is shared with multiple gpiochips: please fix the driver.
[ 0.680096] pci 0000:00:02.0: vgaarb: setting as boot VGA device
[ 0.680096] pci 0000:00:02.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none
[ 0.680096] pci 0000:00:02.0: vgaarb: bridge control possible
[ 0.680096] vgaarb: loaded
[ 0.680295] SCSI subsystem initialized
[ 0.680333] libata version 3.00 loaded.
[ 0.680333] ACPI: bus type USB registered
[ 0.680333] usbcore: registered new interface driver usbfs
[ 0.680333] usbcore: registered new interface driver hub
[ 0.680333] usbcore: registered new device driver usb
[ 0.828364] pps_core: LinuxPPS API ver. 1 registered
[ 0.828367] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 0.828377] PTP clock support registered
[ 0.828461] EDAC MC: Ver: 3.0.0
[ 0.828461] Registered efivars operations
[ 0.833052] PCI: Using ACPI for IRQ routing
[ 0.833057] PCI: pci_cache_line_size set to 64 bytes
[ 0.833082] Expanded resource Reserved due to conflict with PCI Bus 0000:00
[ 0.833087] e820: reserve RAM buffer [mem 0x0008f000-0x0008ffff]
[ 0.833091] e820: reserve RAM buffer [mem 0x0009e000-0x0009ffff]
[ 0.833093] e820: reserve RAM buffer [mem 0x78d3b000-0x7bffffff]
[ 0.833097] e820: reserve RAM buffer [mem 0x79a08000-0x7bffffff]
[ 0.833100] e820: reserve RAM buffer [mem 0x79b72000-0x7bffffff]
[ 0.833103] e820: reserve RAM buffer [mem 0x7a000000-0x7bffffff]
[ 0.833390] NetLabel: Initializing
[ 0.833393] NetLabel: domain hash size = 128
[ 0.833394] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO
[ 0.833437] NetLabel: unlabeled traffic allowed by default
[ 0.833451] clocksource: Switched to clocksource tsc-early
[ 0.878311] VFS: Disk quotas dquot_6.6.0
[ 0.878357] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[ 0.878427] *** VALIDATE hugetlbfs ***
[ 0.878516] pnp: PnP ACPI init
[ 0.878658] pnp 00:00: Plug and Play ACPI device, IDs PNP0b00 (active)
[ 0.878962] system 00:01: [io 0x0680-0x069f] has been reserved
[ 0.878968] system 00:01: [io 0x0400-0x047f] has been reserved
[ 0.878972] system 00:01: [io 0x0500-0x05fe] has been reserved
[ 0.878977] system 00:01: [io 0x0600-0x061f] has been reserved
[ 0.878982] system 00:01: [io 0x164e-0x164f] has been reserved
[ 0.879014] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 0.879301] pnp 00:02: Plug and Play ACPI device, IDs PNP0501 (active)
[ 0.883235] pnp: PnP ACPI: found 3 devices
[ 0.888857] pci_bus 0000:00: resource 4 [io 0x0070-0x0077]
[ 0.888863] pci_bus 0000:00: resource 5 [io 0x0000-0x006f window]
[ 0.888867] pci_bus 0000:00: resource 6 [io 0x0078-0x0cf7 window]
[ 0.888872] pci_bus 0000:00: resource 7 [io 0x0d00-0xffff window]
[ 0.888876] pci_bus 0000:00: resource 8 [mem 0x000a0000-0x000bffff window]
[ 0.888880] pci_bus 0000:00: resource 9 [mem 0x000c0000-0x000dffff window]
[ 0.888884] pci_bus 0000:00: resource 10 [mem 0x000e0000-0x000fffff window]
[ 0.888889] pci_bus 0000:00: resource 11 [mem 0x90c00000-0x90ffffff window]
[ 0.888893] pci_bus 0000:00: resource 12 [mem 0x7af00001-0x7ef00000 window]
[ 0.888897] pci_bus 0000:00: resource 13 [mem 0x80000000-0x908ffffe window]
[ 0.888901] pci_bus 0000:00: resource 14 [mem 0xfed40000-0xfed40fff window]
[ 0.889142] NET: Registered protocol family 2
[ 0.889602] tcp_listen_portaddr_hash hash table entries: 1024 (order: 2, 16384 bytes)
[ 0.889639] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
[ 0.889751] TCP bind hash table entries: 16384 (order: 6, 262144 bytes)
[ 0.889868] TCP: Hash tables configured (established 16384 bind 16384)
[ 0.889963] UDP hash table entries: 1024 (order: 3, 32768 bytes)
[ 0.890022] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
[ 0.890182] NET: Registered protocol family 1
[ 0.890202] NET: Registered protocol family 44
[ 0.890227] pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
[ 0.890665] PCI: CLS 0 bytes, default 64
[ 0.890797] Unpacking initramfs...
[ 1.623726] Freeing initrd memory: 16136K
[ 1.623874] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x133626f6b26, max_idle_ns: 440795214178 ns
[ 1.623921] clocksource: Switched to clocksource tsc
[ 1.630473] Initialise system trusted keyrings
[ 1.630501] Key type blacklist registered
[ 1.630618] workingset: timestamp_bits=36 max_order=19 bucket_order=0
[ 1.635325] zbud: loaded
[ 1.637329] Platform Keyring initialized
[ 2.281569] alg: No test for lzo-rle (lzo-rle-generic)
[ 2.284874] alg: No test for lzo-rle (lzo-rle-scomp)
[ 2.288246] alg: No test for 842 (842-generic)
[ 2.291481] alg: No test for 842 (842-scomp)
[ 2.398687] NET: Registered protocol family 38
[ 2.398695] Key type asymmetric registered
[ 2.398698] Asymmetric key parser 'x509' registered
[ 2.398731] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 244)
[ 2.398857] io scheduler mq-deadline registered
[ 2.398860] io scheduler kyber registered
[ 2.399034] io scheduler bfq registered
[ 2.399220] atomic64_test: passed for x86-64 platform with CX8 and with SSE
[ 2.399522] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[ 2.399604] efifb: probing for efifb
[ 2.399644] efifb: showing boot graphics
[ 2.401670] efifb: framebuffer at 0x80000000, using 4000k, total 4000k
[ 2.401674] efifb: mode is 800x1280x32, linelength=3200, pages=1
[ 2.401675] efifb: scrolling: redraw
[ 2.401679] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[ 2.401827] fbcon: Deferring console take-over
[ 2.401830] fb0: EFI VGA frame buffer device
[ 2.401856] intel_idle: MWAIT substates: 0x33000020
[ 2.401859] intel_idle: v0.4.1 model 0x37
[ 2.402649] intel_idle: lapic_timer_reliable_states 0xffffffff
[ 2.416758] ACPI: AC Adapter [ADP1] (off-line)
[ 2.423910] [Firmware Bug]: No valid trip found
[ 2.424636] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
[ 2.436693] battery: ACPI: Battery Slot [BATC] (battery present)
[ 2.444951] 00:02: ttyS0 at I/O 0x3f8 (irq = 31, base_baud = 115200) is a 16550A
[ 2.464511] 80860F0A:00: ttyS4 at MMIO 0x9094d000 (irq = 17, base_baud = 2764800) is a 16550A
[ 2.464706] serial serial0: tty port ttyS4 registered
[ 2.476914] 80860F0A:01: ttyS5 at MMIO 0x90953000 (irq = 18, base_baud = 2764800) is a 16550A
[ 2.478520] hpet: number irqs doesn't agree with number of timers
[ 2.478878] Non-volatile memory driver v1.3
[ 2.479041] Linux agpgart interface v0.103
[ 2.519466] libphy: Fixed MDIO Bus: probed
[ 2.519803] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 2.519826] ehci-pci: EHCI PCI platform driver
[ 2.519860] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 2.519869] ohci-pci: OHCI PCI platform driver
[ 2.519891] uhci_hcd: USB Universal Host Controller Interface driver
[ 2.520239] xhci_hcd 0000:00:14.0: xHCI Host Controller
[ 2.520457] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 1
[ 2.521554] xhci_hcd 0000:00:14.0: hcc params 0x200077c1 hci version 0x100 quirks 0x0000000000009810
[ 2.521563] xhci_hcd 0000:00:14.0: cache line size of 64 is not supported
[ 2.521932] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.01
[ 2.521937] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 2.521941] usb usb1: Product: xHCI Host Controller
[ 2.521945] usb usb1: Manufacturer: Linux 5.1.6-300.fc30.x86_64 xhci-hcd
[ 2.521948] usb usb1: SerialNumber: 0000:00:14.0
[ 2.522447] hub 1-0:1.0: USB hub found
[ 2.522475] hub 1-0:1.0: 6 ports detected
[ 3.606722] xhci_hcd 0000:00:14.0: xHCI Host Controller
[ 3.607091] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2
[ 3.607103] xhci_hcd 0000:00:14.0: Host supports USB 3.0 SuperSpeed
[ 3.607262] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.01
[ 3.607267] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 3.607271] usb usb2: Product: xHCI Host Controller
[ 3.607275] usb usb2: Manufacturer: Linux 5.1.6-300.fc30.x86_64 xhci-hcd
[ 3.607278] usb usb2: SerialNumber: 0000:00:14.0
[ 3.607757] hub 2-0:1.0: USB hub found
[ 3.607782] hub 2-0:1.0: 1 port detected
[ 3.608231] usbcore: registered new interface driver usbserial_generic
[ 3.608248] usbserial: USB Serial support registered for generic
[ 3.608310] i8042: PNP: No PS/2 controller found.
[ 3.608723] mousedev: PS/2 mouse device common for all mice
[ 3.609052] rtc_cmos 00:00: registered as rtc0
[ 3.609057] rtc_cmos 00:00: no alarms, 242 bytes nvram
[ 3.609194] device-mapper: uevent: version 1.0.3
[ 3.609447] device-mapper: ioctl: 4.40.0-ioctl (2019-01-18) initialised: dm-devel@redhat.com
[ 3.610044] intel_pstate: Intel P-state driver initializing
[ 3.612155] hidraw: raw HID events driver (C) Jiri Kosina
[ 3.612432] usbcore: registered new interface driver usbhid
[ 3.612437] usbhid: USB HID core driver
[ 3.613525] drop_monitor: Initializing network drop monitor service
[ 3.613883] Initializing XFRM netlink socket
[ 3.614862] NET: Registered protocol family 10
[ 3.635637] Segment Routing with IPv6
[ 3.635765] mip6: Mobile IPv6
[ 3.635777] NET: Registered protocol family 17
[ 3.638134] mce: Using 6 MCE banks
[ 3.638229] RAS: Correctable Errors collector initialized.
[ 3.638683] microcode: sig=0x30673, pf=0x2, revision=0x321
[ 3.639509] microcode: Microcode Update Driver: v2.2.
[ 3.639583] SSE version of gcm_enc/dec engaged.
[ 3.821617] sched_clock: Marking stable (3820966032, 612125)->(3840697504, -19119347)
[ 3.824161] registered taskstats version 1
[ 3.824213] Loading compiled-in X.509 certificates
[ 3.928912] Loaded X.509 cert 'Fedora kernel signing key: dbc76a31f4e0673968703a103109753cb34fdc40'
[ 3.929021] zswap: loaded using pool lzo/zbud
[ 3.931021] usb 1-2: new high-speed USB device number 2 using xhci_hcd
[ 3.963809] Key type big_key registered
[ 3.981621] Key type encrypted registered
[ 3.981852] integrity: Loading X.509 certificate: UEFI:db
[ 3.981943] integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4'
[ 3.981945] integrity: Loading X.509 certificate: UEFI:db
[ 3.982023] integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53'
[ 3.982025] integrity: Loading X.509 certificate: UEFI:db
[ 3.982066] integrity: Loaded X.509 cert 'Pegatron - Fabrikam Test OWN: bab9fccfe388de8e4270c21b8cdb7ea3'
[ 3.982832] ima: Allocated hash algorithm: sha1
[ 4.027376] No architecture policies found
[ 4.030647] PM: Magic number: 7:260:51
[ 4.030697] tpmrm tpmrm0: hash matches
[ 4.031557] rtc_cmos 00:00: setting system clock to 2019-06-10T00:05:57 UTC (1560125157)
[ 4.058199] usb 1-2: New USB device found, idVendor=0bda, idProduct=8153, bcdDevice=30.00
[ 4.058205] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[ 4.058208] usb 1-2: Product: USB 10/100/1000 LAN
[ 4.058211] usb 1-2: Manufacturer: Realtek
[ 4.058214] usb 1-2: SerialNumber: 000001000000
[ 4.058421] Freeing unused decrypted memory: 2040K
[ 4.060189] Freeing unused kernel image memory: 2212K
[ 4.067474] Write protecting the kernel read-only data: 18432k
[ 4.070313] Freeing unused kernel image memory: 2016K
[ 4.071622] Freeing unused kernel image memory: 8K
[ 4.105559] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[ 4.105569] rodata_test: all tests were successful
[ 4.106004] x86/mm: Checking user space page tables
[ 4.135431] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[ 4.135436] Run /init as init process
[ 4.168579] systemd[1]: systemd v241-8.git9ef65cb.fc30 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid)
[ 4.182022] systemd[1]: Detected architecture x86-64.
[ 4.182040] systemd[1]: Running in initial RAM disk.
[ 4.206668] systemd[1]: Set hostname to <dv8p>.
[ 4.451328] systemd[1]: Reached target Timers.
[ 4.451704] systemd[1]: Listening on Journal Socket (/dev/log).
[ 4.451939] systemd[1]: Listening on udev Control Socket.
[ 4.451972] systemd[1]: Reached target Swap.
[ 4.452029] systemd[1]: Reached target Slices.
[ 4.452332] systemd[1]: Listening on Journal Audit Socket.
[ 5.204697] audit: type=1130 audit(1560125158.672:2): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-journald comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 5.237235] audit: type=1130 audit(1560125158.705:3): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-tmpfiles-setup comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 5.451897] audit: type=1130 audit(1560125158.919:4): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-udevd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 5.739986] audit: type=1130 audit(1560125159.207:5): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-udev-trigger comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 5.743640] i2c_hid i2c-SMO91D0:00: i2c-SMO91D0:00 supply vdd not found, using dummy regulator
[ 5.743682] i2c_hid i2c-SMO91D0:00: i2c-SMO91D0:00 supply vddl not found, using dummy regulator
[ 5.771805] sdhci: Secure Digital Host Controller Interface driver
[ 5.771808] sdhci: Copyright(c) Pierre Ossman
[ 5.797733] mmc0: SDHCI controller on ACPI [80860F14:01] using ADMA
[ 5.798486] mmc1: SDHCI controller on ACPI [INT33BB:00] using ADMA
[ 5.810630] mmc2: SDHCI controller on ACPI [80860F14:00] using ADMA
[ 5.850751] mmc1: queuing unknown CIS tuple 0x01 (3 bytes)
[ 5.858608] mmc1: queuing unknown CIS tuple 0x1a (5 bytes)
[ 5.861775] mmc1: queuing unknown CIS tuple 0x1b (8 bytes)
[ 5.862447] mmc1: queuing unknown CIS tuple 0x14 (0 bytes)
[ 5.865169] mmc1: queuing unknown CIS tuple 0x80 (1 bytes)
[ 5.865245] mmc1: queuing unknown CIS tuple 0x81 (1 bytes)
[ 5.865329] mmc1: queuing unknown CIS tuple 0x82 (1 bytes)
[ 5.865366] mmc1: new high speed SDIO card at address 0001
[ 5.886165] hid-generic 0018:0483:91D1.0001: hidraw0: I2C HID v1.00 Device [SMO91D0:00 0483:91D1] on i2c-SMO91D0:00
[ 5.888450] mmc2: new HS200 MMC card at address 0001
[ 5.928462] mmcblk2: mmc2:0001 MBG4GC 29.1 GiB
[ 5.929295] mmcblk2boot0: mmc2:0001 MBG4GC partition 1 4.00 MiB
[ 5.930642] mmcblk2boot1: mmc2:0001 MBG4GC partition 2 4.00 MiB
[ 5.930778] mmcblk2rpmb: mmc2:0001 MBG4GC partition 3 4.00 MiB, chardev (240:0)
[ 5.937535] mmcblk2: p1 p2 p3 p4
[ 6.209247] i2c_hid i2c-SYNA7500:00: i2c-SYNA7500:00 supply vdd not found, using dummy regulator
[ 6.209309] i2c_hid i2c-SYNA7500:00: i2c-SYNA7500:00 supply vddl not found, using dummy regulator
[ 6.235825] input: SYNA7500:00 06CB:00F2 as /devices/platform/80860F41:05/i2c-5/i2c-SYNA7500:00/0018:06CB:00F2.0002/input/input0
[ 6.236612] input: SYNA7500:00 06CB:00F2 Touchscreen as /devices/platform/80860F41:05/i2c-5/i2c-SYNA7500:00/0018:06CB:00F2.0002/input/input1
[ 6.237262] hid-generic 0018:06CB:00F2.0002: input,hidraw1: I2C HID v1.00 Device [SYNA7500:00 06CB:00F2] on i2c-SYNA7500:00
[ 6.347047] audit: type=1130 audit(1560125159.814:6): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-fsck-root comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 6.376182] EXT4-fs (mmcblk2p4): mounted filesystem with ordered data mode. Opts: (null)
[ 6.595882] input: SYNA7500:00 06CB:00F2 as /devices/platform/80860F41:05/i2c-5/i2c-SYNA7500:00/0018:06CB:00F2.0002/input/input3
[ 6.596540] input: SYNA7500:00 06CB:00F2 as /devices/platform/80860F41:05/i2c-5/i2c-SYNA7500:00/0018:06CB:00F2.0002/input/input4
[ 6.597175] hid-multitouch 0018:06CB:00F2.0002: input,hidraw0: I2C HID v1.00 Device [SYNA7500:00 06CB:00F2] on i2c-SYNA7500:00
[ 6.864693] audit: type=1130 audit(1560125160.332:7): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=initrd-parse-etc comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 6.864720] audit: type=1131 audit(1560125160.332:8): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=initrd-parse-etc comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 6.912411] audit: type=1131 audit(1560125160.380:9): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-tmpfiles-setup comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 6.915701] audit: type=1131 audit(1560125160.382:10): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-sysctl comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 6.922228] audit: type=1131 audit(1560125160.389:11): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-udev-trigger comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 6.924235] audit: type=1130 audit(1560125160.392:12): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=initrd-cleanup comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 6.924245] audit: type=1131 audit(1560125160.392:13): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=initrd-cleanup comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 6.927690] audit: type=1131 audit(1560125160.395:14): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-udevd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 7.073745] systemd-journald[278]: Received SIGTERM from PID 1 (systemd).
[ 7.158223] printk: systemd: 22 output lines suppressed due to ratelimiting
[ 8.209700] SELinux: policy capability network_peer_controls=1
[ 8.209703] SELinux: policy capability open_perms=1
[ 8.209705] SELinux: policy capability extended_socket_class=1
[ 8.209706] SELinux: policy capability always_check_network=0
[ 8.209707] SELinux: policy capability cgroup_seclabel=1
[ 8.209709] SELinux: policy capability nnp_nosuid_transition=1
[ 8.256051] systemd[1]: Successfully loaded SELinux policy in 773.455ms.
[ 8.472733] systemd[1]: Relabelled /dev, /dev/shm, /run, /sys/fs/cgroup in 119.376ms.
[ 8.496131] systemd[1]: systemd v241-8.git9ef65cb.fc30 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid)
[ 8.509859] systemd[1]: Detected architecture x86-64.
[ 8.517336] systemd[1]: Set hostname to <dv8p>.
[ 8.780936] systemd[1]: /usr/lib/systemd/system/sssd.service:11: PIDFile= references path below legacy directory /var/run/, updating /var/run/sssd.pid → /run/sssd.pid; please update the unit file accordingly.
[ 9.023206] systemd[1]: initrd-switch-root.service: Succeeded.
[ 9.024615] systemd[1]: Stopped Switch Root.
[ 9.025485] systemd[1]: systemd-journald.service: Service has no hold-off time (RestartSec=0), scheduling restart.
[ 9.025658] systemd[1]: systemd-journald.service: Scheduled restart job, restart counter is at 1.
[ 9.025695] systemd[1]: Stopped Journal Service.
[ 9.030354] systemd[1]: Starting Journal Service...
[ 9.113308] EXT4-fs (mmcblk2p4): re-mounted. Opts: (null)
[ 9.337368] EXT4-fs (mmcblk2p3): mounted filesystem with ordered data mode. Opts: (null)
[ 9.799697] systemd-journald[390]: Received request to flush runtime journal from PID 1
[ 10.275951] int3401 thermal INT3401:00: Creating sysfs group for PROC_THERMAL_PLATFORM_DEV
[ 10.290536] dw_dmac INTL9C60:00: DesignWare DMA Controller, 8 channels
[ 10.316363] dw_dmac INTL9C60:01: DesignWare DMA Controller, 8 channels
[ 10.428424] mei_txe 0000:00:1a.0: can't derive routing for PCI INT A
[ 10.428428] mei_txe 0000:00:1a.0: PCI INT A: not connected
[ 10.490859] usbcore: registered new interface driver r8152
[ 10.522835] usbcore: registered new interface driver cdc_ether
[ 10.528141] i2c_hid i2c-SMO91D0:00: failed to retrieve report from device.
[ 10.528238] i2c_hid i2c-SMO91D0:00: failed to retrieve report from device.
[ 10.531665] i2c_hid i2c-SMO91D0:00: failed to retrieve report from device.
[ 10.532168] i2c_hid i2c-SMO91D0:00: failed to retrieve report from device.
[ 10.542669] i2c_hid i2c-SMO91D0:00: failed to retrieve report from device.
[ 10.542771] i2c_hid i2c-SMO91D0:00: failed to retrieve report from device.
[ 10.601017] intel_sst_acpi 80860F28:00: BYT-CR not detected
[ 10.602177] intel_sst_acpi 80860F28:00: LPE base: 0x90a00000 size:0x200000
[ 10.602181] intel_sst_acpi 80860F28:00: IRAM base: 0x90ac0000
[ 10.602232] intel_sst_acpi 80860F28:00: DRAM base: 0x90b00000
[ 10.602242] intel_sst_acpi 80860F28:00: SHIM base: 0x90b40000
[ 10.602253] intel_sst_acpi 80860F28:00: Mailbox base: 0x90b44000
[ 10.602261] intel_sst_acpi 80860F28:00: DDR base: 0x20000000
[ 10.603150] intel_sst_acpi 80860F28:00: Got drv data max stream 25
[ 10.611694] usb 1-2: reset high-speed USB device number 2 using xhci_hcd
[ 10.739148] dcdbas dcdbas: Dell Systems Management Base Driver (version 5.6.0-3.3)
[ 10.767929] r8152 1-2:1.0 eth0: v1.09.9
[ 10.826649] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 10.828140] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 10.828242] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 10.828246] cfg80211: failed to load regulatory.db
[ 10.964592] checking generic (80000000 3e8000) vs hw (80000000 10000000)
[ 10.964596] fb0: switching to inteldrmfb from EFI VGA
[ 10.968118] i915 0000:00:02.0: vgaarb: deactivate vga console
[ 10.968509] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 10.968510] [drm] Driver supports precise vblank timestamp query.
[ 10.969226] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 10.990654] [drm] Initialized i915 1.6.0 20190207 for 0000:00:02.0 on minor 0
[ 10.992398] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
[ 10.992871] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input6
[ 10.993243] [drm] HDaudio controller not detected, using LPE audio instead
[ 11.041794] input: gpio-keys as /devices/platform/gpio-keys.9.auto/input/input7
[ 11.042194] input: gpio-keys as /devices/platform/gpio-keys.10.auto/input/input8
[ 11.045436] fbcon: inteldrmfb (fb0) is primary device
[ 11.045439] fbcon: Deferring console take-over
[ 11.045446] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[ 11.098238] iTCO_vendor_support: vendor-support=0
[ 11.108032] mmc1: queuing unknown CIS tuple 0x01 (3 bytes)
[ 11.116038] mmc1: queuing unknown CIS tuple 0x1a (5 bytes)
[ 11.118485] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[ 11.118634] iTCO_wdt: Found a Bay Trail SoC TCO device (Version=3, TCOBASE=0x0460)
[ 11.119350] mmc1: queuing unknown CIS tuple 0x1b (8 bytes)
[ 11.119978] mmc1: queuing unknown CIS tuple 0x14 (0 bytes)
[ 11.120332] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[ 11.596969] bytcr_rt5640 bytcr_rt5640: quirk DMIC1_MAP enabled
[ 11.596975] bytcr_rt5640 bytcr_rt5640: quirk realtek,jack-detect-source 3
[ 11.596978] bytcr_rt5640 bytcr_rt5640: quirk realtek,over-current-threshold-microamp 2000
[ 11.596981] bytcr_rt5640 bytcr_rt5640: quirk realtek,over-current-scale-factor 1
[ 11.596984] bytcr_rt5640 bytcr_rt5640: quirk MONO_SPEAKER enabled
[ 11.597010] bytcr_rt5640 bytcr_rt5640: quirk MCLK_EN enabled
[ 11.599573] input: Intel HDMI/DP LPE Audio HDMI/DP,pcm=0 as /devices/pci0000:00/0000:00:02.0/hdmi-lpe-audio/sound/card1/input9
[ 11.599754] input: Intel HDMI/DP LPE Audio HDMI/DP,pcm=1 as /devices/pci0000:00/0000:00:02.0/hdmi-lpe-audio/sound/card1/input10
[ 11.602631] bytcr_rt5640 bytcr_rt5640: snd-soc-dummy-dai <-> media-cpu-dai mapping ok
[ 11.602693] bytcr_rt5640 bytcr_rt5640: snd-soc-dummy-dai <-> deepbuffer-cpu-dai mapping ok
[ 11.605073] bytcr_rt5640 bytcr_rt5640: rt5640-aif1 <-> ssp2-port mapping ok
[ 11.607896] input: bytcr-rt5640 Headset as /devices/platform/80860F28:00/bytcr_rt5640/sound/card0/input11
[ 12.191621] r8152 1-2:1.0 enp0s20u2: renamed from eth0
[ 12.236523] intel_rapl: Found RAPL domain package
[ 12.236530] intel_rapl: Found RAPL domain core
[ 12.377025] kauditd_printk_skb: 24 callbacks suppressed
[ 12.377028] audit: type=1130 audit(1560125165.844:39): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-backlight@backlight:intel_backlight comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 12.496508] audit: type=1130 audit(1560125165.964:40): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-journal-flush comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 12.661190] ath6kl: ar6004 hw 3.0 sdio fw 3.5.0.349-1 api 5
[ 12.661206] ath6kl: firmware supports: 64bit-rates,map-lp-endpoint,ratetable-mcs15,no-ip-checksum
[ 12.661849] ath6kl: Firmware lacks RSN-CAP-OVERRIDE, so HT (802.11n) is disabled.
[ 12.678378] audit: type=1130 audit(1560125166.146:41): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-tmpfiles-setup comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 12.698049] audit: type=1130 audit(1560125166.165:42): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 13.285033] Bluetooth: Core ver 2.22
[ 13.285279] NET: Registered protocol family 31
[ 13.285282] Bluetooth: HCI device and connection manager initialized
[ 13.285291] Bluetooth: HCI socket layer initialized
[ 13.285301] Bluetooth: L2CAP socket layer initialized
[ 13.285316] Bluetooth: SCO socket layer initialized
[ 20.913334] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s20u2: link becomes ready
[ 20.913541] r8152 1-2:1.0 enp0s20u2: carrier on
[ 21.171142] fbcon: Taking over console
[ 21.181763] Console: switching to colour frame buffer device 100x80
[ 66.874004] NOHZ: local_softirq_pending 08
[ 80.375146] NOHZ: local_softirq_pending 08
[ 107.897041] NOHZ: local_softirq_pending 08
[ 136.627861] NOHZ: local_softirq_pending 08
[ 184.662661] NOHZ: local_softirq_pending 08
[ 192.417816] NOHZ: local_softirq_pending 08
[ 198.668378] NOHZ: local_softirq_pending 08
[ 210.385733] NOHZ: local_softirq_pending 08
[ 216.931930] NOHZ: local_softirq_pending 08
[ 223.475175] NOHZ: local_softirq_pending 08
[ 1649.534597] xhci_hcd 0000:00:14.0: Refused to change power state, currently in D0
[ 9168.405550] ath6kl: req failed (status:-110, ep:1, len:14 creds:1)
[ 9168.405568] ath6kl: tx complete error: -110
^ permalink raw reply
* Re: [PATCH] mt76: mt7615: add support for per-chain signal strength reporting
From: Ryder Lee @ 2019-06-10 2:09 UTC (permalink / raw)
To: Sebastian Gottschall
Cc: Felix Fietkau, Lorenzo Bianconi, Sean Wang, Chih-Min Chen, YF Luo,
linux-wireless, linux-kernel, Yiwei Chung, linux-mediatek,
Roy Luo
In-Reply-To: <d6cfd2e9-4b2b-36ac-6cae-a34f74204801@newmedia-net.de>
On Sun, 2019-06-09 at 16:44 +0200, Sebastian Gottschall wrote:
> according to my findings
>
> MT_RXV4_RCPI1 is part of rx descriptor 4 and not 3
> so it must be rxdg4 = rxd[4] etc.
RXV start from 1 in the code.
That is: RXV1 <-> rxdg0, RXV2 <-> rxdg1 ...so RXV4 <-> rxdg3
> however rxdg3 contains MT_RXV3_IB_RSSIRX which can be used for signal calculation.
> i already wrote a similar code for this driver which i sended to felix a long time ago.
> my variant looks like
> status->signal = (FIELD_GET(MT_RXV3_IB_RSSIRX, rxdg3) - 220) / 2;
> status->chain_signal[0] = (FIELD_GET(MT_RXV4_RCPI0, rxdg4) - 220) / 2;
> status->chain_signal[1] = (FIELD_GET(MT_RXV4_RCPI1, rxdg4) - 220) / 2;
> status->chain_signal[2] = (FIELD_GET(MT_RXV4_RCPI2, rxdg4) - 220) / 2;
> status->chain_signal[3] = (FIELD_GET(MT_RXV4_RCPI3, rxdg4) - 220) / 2;
> Am 09.06.2019 um 11:09 schrieb Ryder Lee:
> > Fill in RX status->chain_signal to avoid empty value.
> >
> > Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> > ---
> > .../net/wireless/mediatek/mt76/mt7615/mac.c | 30 ++++++++++++++++++-
> > .../net/wireless/mediatek/mt76/mt7615/mac.h | 5 ++++
> > 2 files changed, 34 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
> > index b60d42b5923d..9ee83ea11b8c
> > --- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
> > @@ -13,6 +13,11 @@
> > #include "../dma.h"
> > #include "mac.h"
> >
> > +static inline s8 to_rssi(u32 field, u32 rxv)
> > +{
> > + return (FIELD_GET(field, rxv) - 220) / 2;
> > +}
> > +
> > static struct mt76_wcid *mt7615_rx_get_wcid(struct mt7615_dev *dev,
> > u8 idx, bool unicast)
> > {
> > @@ -120,6 +125,7 @@ int mt7615_mac_fill_rx(struct mt7615_dev *dev, struct sk_buff *skb)
> > if (rxd0 & MT_RXD0_NORMAL_GROUP_3) {
> > u32 rxdg0 = le32_to_cpu(rxd[0]);
> > u32 rxdg1 = le32_to_cpu(rxd[1]);
> > + u32 rxdg3 = le32_to_cpu(rxd[3]);
> > u8 stbc = FIELD_GET(MT_RXV1_HT_STBC, rxdg0);
> > bool cck = false;
> >
> > @@ -169,7 +175,29 @@ int mt7615_mac_fill_rx(struct mt7615_dev *dev, struct sk_buff *skb)
> >
> > status->enc_flags |= RX_ENC_FLAG_STBC_MASK * stbc;
> >
> > - /* TODO: RSSI */
> > + status->chains = dev->mt76.antenna_mask;
> > + status->chain_signal[0] = to_rssi(MT_RXV4_RCPI0, rxdg3);
> > + status->signal = status->chain_signal[0];
> > +
> > + switch (status->chains) {
> > + case 0x3:
> > + status->chain_signal[1] = to_rssi(MT_RXV4_RCPI1, rxdg3);
> > + status->signal = max(status->signal,
> > + status->chain_signal[1]);
> > + break;
> > + case 0x7:
> > + status->chain_signal[2] = to_rssi(MT_RXV4_RCPI2, rxdg3);
> > + status->signal = max(status->signal,
> > + status->chain_signal[2]);
> > + break;
> > + case 0xf:
> > + status->chain_signal[3] = to_rssi(MT_RXV4_RCPI3, rxdg3);
> > + status->signal = max(status->signal,
> > + status->chain_signal[3]);
> > + break;
> > + default:
> > + break;
> > + }
> > rxd += 6;
> > if ((u8 *)rxd - skb->data >= skb->len)
> > return -EINVAL;
> > diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.h b/drivers/net/wireless/mediatek/mt76/mt7615/mac.h
> > index 18ad4b8a3807..b00ce8db58e9
> > --- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.h
> > +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.h
> > @@ -98,6 +98,11 @@ enum rx_pkt_type {
> > #define MT_RXV2_GROUP_ID GENMASK(26, 21)
> > #define MT_RXV2_LENGTH GENMASK(20, 0)
> >
> > +#define MT_RXV4_RCPI3 GENMASK(31, 24)
> > +#define MT_RXV4_RCPI2 GENMASK(23, 16)
> > +#define MT_RXV4_RCPI1 GENMASK(15, 8)
> > +#define MT_RXV4_RCPI0 GENMASK(7, 0)
> > +
> > enum tx_header_format {
> > MT_HDR_FORMAT_802_3,
> > MT_HDR_FORMAT_CMD,
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: Should b44_init lead to WARN_ON in drivers/ssb/driver_gpio.c:464?
From: Larry Finger @ 2019-06-10 0:13 UTC (permalink / raw)
To: Michael Büsch, H Buus
Cc: Kalle Valo, Michael Chan, linux-wireless, netdev
In-Reply-To: <20190609235711.481bbac9@wiggum>
On 6/9/19 4:57 PM, Michael Büsch wrote:
> On Sun, 9 Jun 2019 17:44:10 -0400
> H Buus <ubuntu@hbuus.com> wrote:
>
>> I have an old 32 bit laptop with a BCM4401-B0 100Base-TX ethernet
>> controller. For every kernel from 4.19-rc1 going forward, I get a
>> warning and call trace within a few seconds of start up (see dmesg
>> snippet below). I have traced it to a specific commit (see commit
>> below). On the face of it, I would think it is a regression, but it
>> doesn't seem to cause a problem, since networking over ethernet is working.
>
>
> This warning is not a problem. The commit just exposes a warning, that
> has always been there.
> I suggest we just remove the WARN_ON from ssb_gpio_init and
> ssb_gpio_unregister.
> I don't see a reason to throw a warning in that case.
Michael,
I agree. Do you want to prepare the patch, or should I?
Larry
^ permalink raw reply
* Re: Should b44_init lead to WARN_ON in drivers/ssb/driver_gpio.c:464?
From: Michael Büsch @ 2019-06-09 21:57 UTC (permalink / raw)
To: H Buus; +Cc: Kalle Valo, Michael Chan, linux-wireless, netdev
In-Reply-To: <946c86bf-7e90-a981-b9fc-757adb98adfa@hbuus.com>
[-- Attachment #1: Type: text/plain, Size: 752 bytes --]
On Sun, 9 Jun 2019 17:44:10 -0400
H Buus <ubuntu@hbuus.com> wrote:
> I have an old 32 bit laptop with a BCM4401-B0 100Base-TX ethernet
> controller. For every kernel from 4.19-rc1 going forward, I get a
> warning and call trace within a few seconds of start up (see dmesg
> snippet below). I have traced it to a specific commit (see commit
> below). On the face of it, I would think it is a regression, but it
> doesn't seem to cause a problem, since networking over ethernet is working.
This warning is not a problem. The commit just exposes a warning, that
has always been there.
I suggest we just remove the WARN_ON from ssb_gpio_init and
ssb_gpio_unregister.
I don't see a reason to throw a warning in that case.
--
Michael
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Should b44_init lead to WARN_ON in drivers/ssb/driver_gpio.c:464?
From: H Buus @ 2019-06-09 21:44 UTC (permalink / raw)
To: Michael Buesch, Kalle Valo, Michael Chan, linux-wireless, netdev
I have an old 32 bit laptop with a BCM4401-B0 100Base-TX ethernet
controller. For every kernel from 4.19-rc1 going forward, I get a
warning and call trace within a few seconds of start up (see dmesg
snippet below). I have traced it to a specific commit (see commit
below). On the face of it, I would think it is a regression, but it
doesn't seem to cause a problem, since networking over ethernet is working.
I might not have noticed the warning except for the fact that something
in the 4.19 time frame is causing this laptop to be unstable. I still
have to identify the source of the instability. The laptop appears
stable with this commit but not with 4.19-rc7 or more recent kernels.
I thought I should at least ask if the following warning is an issue. If
it is, I am happy to help with creating a proper bug report as well as
debugging and testing. Is this an issue that should be addressed to the
netdev or linux-wireless lists, or both, since it appears to be an
interaction between the b44 driver which belongs to netdev and the ssb
driver which belongs to linux-wireless?
--- Begin dmesg snippet ---
[ 5.145764] ssb: Found chip with id 0x4318, rev 0x02 and package 0x02
[ 5.265914] b43-pci-bridge 0000:02:03.0: Sonics Silicon Backplane
found on PCI device 0000:02:03.0
[ 5.353718] ssb: Found chip with id 0x4401, rev 0x02 and package 0x00
[ 5.421787] WARNING: CPU: 0 PID: 157 at drivers/ssb/driver_gpio.c:464
ssb_gpio_init+0xa0/0xb0 [ssb]
[ 5.425679] Modules linked in: b44(+) psmouse pata_acpi ssb mii
[ 5.425679] CPU: 0 PID: 157 Comm: systemd-udevd Not tainted
4.19.31-041931-generic #201903231635
[ 5.425679] Hardware name: Dell Inc. ME051
/0DK344, BIOS A10 11/07/2006
[ 5.425679] EIP: ssb_gpio_init+0xa0/0xb0 [ssb]
[ 5.425679] Code: 00 31 c0 85 c9 0f 95 c0 31 c9 f7 d8 89 82 18 05 00
00 8d 82 d8 04 00 00 6a 00 e8 1b b6 17 dd 5a c9 c3 8d b4 26 00 00 00 00
90 <0f> 0b c9 b8 ff ff ff ff c3 8d b4 26 00 00 00 00 3e 8d 74 26 00 55
[ 5.425679] EAX: f58a3800 EBX: f58a3800 ECX: 00000000 EDX: f7e1ef94
[ 5.425679] ESI: 00000000 EDI: f58a3800 EBP: f585bc80 ESP: f585bc80
[ 5.425679] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010246
[ 5.425679] CR0: 80050033 CR2: b7ab702b CR3: 3586c000 CR4: 000006f0
[ 5.425679] Call Trace:
[ 5.425679] ssb_attach_queued_buses+0xe2/0x310 [ssb]
[ 5.425679] ssb_bus_register+0x167/0x1c0 [ssb]
[ 5.425679] ? ssb_pci_xtal+0x1d0/0x1d0 [ssb]
[ 5.425679] ssb_bus_pcibus_register+0x29/0x80 [ssb]
[ 5.425679] ssb_pcihost_probe+0xb7/0x110 [ssb]
[ 5.425679] ? ssb_pcihost_remove+0x40/0x40 [ssb]
[ 5.425679] pci_device_probe+0xc7/0x160
[ 5.425679] really_probe+0x1fe/0x390
[ 5.425679] driver_probe_device+0xe1/0x120
[ 5.425679] ? pci_match_device+0xde/0x110
[ 5.425679] ? _cond_resched+0x17/0x30
[ 5.425679] __driver_attach+0xd9/0x100
[ 5.425679] ? driver_probe_device+0x120/0x120
[ 5.425679] bus_for_each_dev+0x5b/0xa0
[ 5.425679] driver_attach+0x19/0x20
[ 5.425679] ? driver_probe_device+0x120/0x120
[ 5.425679] bus_add_driver+0x117/0x210
[ 5.425679] ? pci_bus_num_vf+0x20/0x20
[ 5.425679] driver_register+0x66/0xb0
[ 5.425679] ? 0xf8365000
[ 5.425679] __pci_register_driver+0x3d/0x40
[ 5.425679] ssb_pcihost_register+0x2c/0x30 [ssb]
[ 5.425679] b44_init+0x1d/0x1000 [b44]
[ 5.425679] do_one_initcall+0x42/0x19a
[ 5.425679] ? vunmap_page_range+0x1c9/0x260
[ 5.425679] ? free_pcp_prepare+0x5d/0xf0
[ 5.425679] ? _cond_resched+0x17/0x30
[ 5.425679] ? kmem_cache_alloc_trace+0x15f/0x1b0
[ 5.425679] ? do_init_module+0x21/0x210
[ 5.425679] ? do_init_module+0x21/0x210
[ 5.425679] do_init_module+0x50/0x210
[ 5.425679] load_module+0x1368/0x1630
[ 5.425679] ? security_kernel_post_read_file+0x54/0x60
[ 5.425679] sys_finit_module+0x8a/0xe0
[ 5.425679] do_fast_syscall_32+0x87/0x1e0
[ 5.425679] entry_SYSENTER_32+0x6b/0xbe
[ 5.425679] EIP: 0xb7eead61
[ 5.425679] Code: f6 ff ff 55 89 e5 8b 55 08 8b 80 5c cd ff ff 85 d2
74 02 89 02 5d c3 8b 04 24 c3 8b 1c 24 c3 90 90 51 52 55 89 e5 0f 34 cd
80 <5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90 8d 76
[ 5.425679] EAX: ffffffda EBX: 0000000d ECX: b7cfda15 EDX: 00000000
[ 5.425679] ESI: 00fcaf40 EDI: 00fcca40 EBP: 00000000 ESP: bfa404dc
[ 5.425679] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000296
[ 5.425679] ---[ end trace b0d87e1b3433e0ca ]---
[ 6.245890] b44 0000:02:00.0: Sonics Silicon Backplane found on PCI
device 0000:02:00.0
[ 6.260263] b44: Broadcom 44xx/47xx 10/100 PCI ethernet driver
version 2.0
[ 6.299684] b44 ssb1:0 eth0: Broadcom 44xx/47xx 10/100 PCI ethernet
driver 00:14:22:af:83:9b
[ 6.367622] random: fast init done
--- End dmesg snippet ---
--- Begin commit ---
commit 209b43759d65b2cc99ce7757249aacc82b03c4e2
Author: Michael Büsch <m@bues.ch>
Date: Tue Jul 31 22:15:09 2018 +0200
ssb: Remove SSB_WARN_ON, SSB_BUG_ON and SSB_DEBUG
Use the standard WARN_ON instead.
If a small kernel is desired, WARN_ON can be disabled globally.
Also remove SSB_DEBUG. Besides WARN_ON it only adds a tiny debug check.
Include this check unconditionally.
Signed-off-by: Michael Buesch <m@bues.ch>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
--- End commit ---
^ permalink raw reply
* [PATCH v3] ath9k: add loader for AR92XX (and older) pci(e)
From: Christian Lamparter @ 2019-06-09 20:36 UTC (permalink / raw)
To: linux-wireless, QCA ath9k Development; +Cc: Kalle Valo, Julian Calaby
Atheros cards with a AR92XX generation (and older) chip usually
store their pci(e) initialization vectors on an external eeprom chip.
However these chips technically don't need the eeprom chip attached,
the AR9280 Datasheet in section "6.1.2 DEVICE_ID" describes that
"... if the EEPROM content is not valid, a value of 0xFF1C returns
when read from the register". So, they will show up on the system's
pci bus. However in that state, ath9k can't load, since it relies
on having the correct pci-id, otherwise it doesn't know what chip it
actually is. This happens on many embedded devices like routers
and accesspoint since they want to keep the BOM low and store the
pci(e) initialization vectors together with the calibration data
on the system's FLASH, which is out of reach of the ath9k chip.
Furthermore, Some devices (like the Cisco Meraki Z1 Cloud Managed
Teleworker Gateway) need to be able to initialize the PCIe wifi device.
Normally, this should be done as a pci quirk during the early stages of
booting linux. However, this isn't possible for devices which have the
init code for the Atheros chip stored on NAND in an UBI volume.
Hence, this module can be used to initialize the chip when the
user-space is ready to extract the init code.
Martin Blumenstingl prodived the following fixes:
owl-loader: add support for OWL emulation PCI devices
owl-loader: don't re-scan the bus when ath9k_pci_fixup failed
owl-loader: use dev_* instead of pr_* logging functions
owl-loader: auto-generate the eeprom filename as fallback
owl-loader: add a debug message when swapping the eeprom data
owl-loader: add missing newlines in log messages
Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
v3: changed module description
v2: address Julian Calaby's comments:
- make it a separate driver again (much like OpenWrt)
- remove ar71xx leftovers (pdata)
---
drivers/net/wireless/ath/ath9k/Kconfig | 16 ++
drivers/net/wireless/ath/ath9k/Makefile | 2 +
.../wireless/ath/ath9k/ath9k_pci_owl_loader.c | 215 ++++++++++++++++++
3 files changed, 233 insertions(+)
create mode 100644 drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig
index a1ef8769983a..d6a87698a44a 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -157,6 +157,22 @@ config ATH9K_PCOEM
depends on ATH9K
default y
+config ATH9K_PCI_NO_EEPROM
+ tristate "Atheros ath9k pci loader for EEPROM-less chips"
+ depends on ATH9K_PCI
+ default n
+ help
+ This separate driver provides a loader in order to support the
+ AR500X to AR92XX-generation of ath9k PCI(e) WiFi chips, which have
+ their initialization data (which contains the real PCI Device ID
+ that ath9k will need) stored together with the calibration data out
+ of reach for the ath9k chip.
+
+ These devices are usually various network appliances, routers or
+ access Points and such.
+
+ If unsure say N.
+
config ATH9K_HTC
tristate "Atheros HTC based wireless cards support"
depends on USB && MAC80211
diff --git a/drivers/net/wireless/ath/ath9k/Makefile b/drivers/net/wireless/ath/ath9k/Makefile
index f71b2ad8275c..abd0f61370d9 100644
--- a/drivers/net/wireless/ath/ath9k/Makefile
+++ b/drivers/net/wireless/ath/ath9k/Makefile
@@ -77,3 +77,5 @@ ath9k_htc-y += htc_hst.o \
ath9k_htc-$(CONFIG_ATH9K_HTC_DEBUGFS) += htc_drv_debug.o
obj-$(CONFIG_ATH9K_HTC) += ath9k_htc.o
+
+obj-$(CONFIG_ATH9K_PCI_NO_EEPROM) += ath9k_pci_owl_loader.o
diff --git a/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
new file mode 100644
index 000000000000..717dee7b6c4c
--- /dev/null
+++ b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Initialize Owl Emulation Devices
+ *
+ * Copyright (C) 2016 Christian Lamparter <chunkeey@gmail.com>
+ * Copyright (C) 2016 Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+ *
+ * Some devices (like the Cisco Meraki Z1 Cloud Managed Teleworker Gateway)
+ * need to be able to initialize the PCIe wifi device. Normally, this is done
+ * during the early stages as a pci quirk.
+ * However, this isn't possible for devices which have the init code for the
+ * Atheros chip stored on UBI Volume on NAND. Hence, this module can be used to
+ * initialize the chip when the user-space is ready to extract the init code.
+ */
+#include <linux/module.h>
+#include <linux/version.h>
+#include <linux/completion.h>
+#include <linux/etherdevice.h>
+#include <linux/firmware.h>
+#include <linux/pci.h>
+#include <linux/delay.h>
+#include <linux/platform_device.h>
+#include <linux/ath9k_platform.h>
+
+struct owl_ctx {
+ struct completion eeprom_load;
+};
+
+#define EEPROM_FILENAME_LEN 100
+
+#define AR5416_EEPROM_MAGIC 0xa55a
+
+static int ath9k_pci_fixup(struct pci_dev *pdev, const u16 *cal_data,
+ size_t cal_len)
+{
+ void __iomem *mem;
+ const void *cal_end = (void *)cal_data + cal_len;
+ const struct {
+ u16 reg;
+ u16 low_val;
+ u16 high_val;
+ } __packed * data;
+ u16 cmd;
+ u32 bar0;
+ bool swap_needed = false;
+
+ if (*cal_data != AR5416_EEPROM_MAGIC) {
+ if (*cal_data != swab16(AR5416_EEPROM_MAGIC)) {
+ dev_err(&pdev->dev, "invalid calibration data\n");
+ return -EINVAL;
+ }
+
+ dev_dbg(&pdev->dev, "calibration data needs swapping\n");
+ swap_needed = true;
+ }
+
+ dev_info(&pdev->dev, "fixup device configuration\n");
+
+ mem = pcim_iomap(pdev, 0, 0);
+ if (!mem) {
+ dev_err(&pdev->dev, "ioremap error\n");
+ return -EINVAL;
+ }
+
+ pci_read_config_dword(pdev, PCI_BASE_ADDRESS_0, &bar0);
+ pci_write_config_dword(pdev, PCI_BASE_ADDRESS_0,
+ pci_resource_start(pdev, 0));
+ pci_read_config_word(pdev, PCI_COMMAND, &cmd);
+ cmd |= PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY;
+ pci_write_config_word(pdev, PCI_COMMAND, cmd);
+
+ /* set pointer to first reg address */
+ for (data = (const void *)(cal_data + 3);
+ (const void *)data <= cal_end && data->reg != (u16)~0;
+ data++) {
+ u32 val;
+ u16 reg;
+
+ reg = data->reg;
+ val = data->low_val;
+ val |= ((u32)data->high_val) << 16;
+
+ if (swap_needed) {
+ reg = swab16(reg);
+ val = swahb32(val);
+ }
+
+ __raw_writel(val, mem + reg);
+ usleep_range(100, 120);
+ }
+
+ pci_read_config_word(pdev, PCI_COMMAND, &cmd);
+ cmd &= ~(PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY);
+ pci_write_config_word(pdev, PCI_COMMAND, cmd);
+
+ pci_write_config_dword(pdev, PCI_BASE_ADDRESS_0, bar0);
+ pcim_iounmap(pdev, mem);
+
+ pci_disable_device(pdev);
+
+ return 0;
+}
+
+static void owl_fw_cb(const struct firmware *fw, void *context)
+{
+ struct pci_dev *pdev = (struct pci_dev *)context;
+ struct owl_ctx *ctx = (struct owl_ctx *)pci_get_drvdata(pdev);
+ struct pci_bus *bus;
+
+ complete(&ctx->eeprom_load);
+
+ if (!fw) {
+ dev_err(&pdev->dev, "no eeprom data received.\n");
+ goto release;
+ }
+
+ /* also note that we are doing *u16 operations on the file */
+ if (fw->size > 4096 || fw->size < 0x200 || (fw->size & 1) == 1) {
+ dev_err(&pdev->dev, "eeprom file has an invalid size.\n");
+ goto release;
+ }
+
+ if (ath9k_pci_fixup(pdev, (const u16 *)fw->data, fw->size))
+ goto release;
+
+ pci_lock_rescan_remove();
+ bus = pdev->bus;
+ pci_stop_and_remove_bus_device(pdev);
+ /* the device should come back with the proper
+ * ProductId. But we have to initiate a rescan.
+ */
+ pci_rescan_bus(bus);
+ pci_unlock_rescan_remove();
+
+release:
+ release_firmware(fw);
+}
+
+static const char *owl_get_eeprom_name(struct pci_dev *pdev)
+{
+ struct device *dev = &pdev->dev;
+ char *eeprom_name;
+
+ dev_dbg(dev, "using auto-generated eeprom filename\n");
+
+ eeprom_name = devm_kzalloc(dev, EEPROM_FILENAME_LEN, GFP_KERNEL);
+ if (!eeprom_name)
+ return NULL;
+
+ /* this should match the pattern used in ath9k/init.c */
+ scnprintf(eeprom_name, EEPROM_FILENAME_LEN, "ath9k-eeprom-pci-%s.bin",
+ dev_name(dev));
+
+ return eeprom_name;
+}
+
+static int owl_probe(struct pci_dev *pdev,
+ const struct pci_device_id *id)
+{
+ struct owl_ctx *ctx;
+ const char *eeprom_name;
+ int err = 0;
+
+ if (pcim_enable_device(pdev))
+ return -EIO;
+
+ pcim_pin_device(pdev);
+
+ eeprom_name = owl_get_eeprom_name(pdev);
+ if (!eeprom_name) {
+ dev_err(&pdev->dev, "no eeprom filename found.\n");
+ return -ENODEV;
+ }
+
+ ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
+ if (!ctx)
+ return -ENOMEM;
+
+ init_completion(&ctx->eeprom_load);
+
+ pci_set_drvdata(pdev, ctx);
+ err = request_firmware_nowait(THIS_MODULE, true, eeprom_name,
+ &pdev->dev, GFP_KERNEL, pdev, owl_fw_cb);
+ if (err)
+ dev_err(&pdev->dev, "failed to request caldata (%d).\n", err);
+
+ return err;
+}
+
+static void owl_remove(struct pci_dev *pdev)
+{
+ struct owl_ctx *ctx = pci_get_drvdata(pdev);
+
+ if (ctx) {
+ wait_for_completion(&ctx->eeprom_load);
+ pci_set_drvdata(pdev, NULL);
+ }
+}
+
+static const struct pci_device_id owl_pci_table[] = {
+ { PCI_VDEVICE(ATHEROS, 0xff1c) }, /* PCIe */
+ { PCI_VDEVICE(ATHEROS, 0xff1d) }, /* PCI */
+ { },
+};
+MODULE_DEVICE_TABLE(pci, owl_pci_table);
+
+static struct pci_driver owl_driver = {
+ .name = KBUILD_MODNAME,
+ .id_table = owl_pci_table,
+ .probe = owl_probe,
+ .remove = owl_remove,
+};
+module_pci_driver(owl_driver);
+MODULE_AUTHOR("Christian Lamparter <chunkeey@gmail.com>");
+MODULE_DESCRIPTION("External EEPROM data loader for Atheros AR500X to AR92XX");
+MODULE_LICENSE("GPL v2");
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 2/7] net/mac80211: move WEP handling to ARC4 library interface
From: Johannes Berg @ 2019-06-09 20:08 UTC (permalink / raw)
To: Ard Biesheuvel, linux-crypto
Cc: Herbert Xu, David S. Miller, Eric Biggers, linux-wireless,
John W. Linville
In-Reply-To: <20190609115509.26260-3-ard.biesheuvel@linaro.org>
Hi Ard,
In general, I have no objections to this.
However, with this
> - select CRYPTO_ARC4
> + select CRYPTO_LIB_ARC4
and this
> case WLAN_CIPHER_SUITE_WEP40:
> case WLAN_CIPHER_SUITE_TKIP:
> case WLAN_CIPHER_SUITE_WEP104:
> - if (IS_ERR(local->wep_tx_tfm))
> - return -EINVAL;
> - break;
there's one quirk that I worry about. Does this mean WEP is now *always*
available/enabled?
I had to dig in history a bit, but vaguely remembered this commit:
commit 3473187d2459a078e00e5fac8aafc30af69c57fa
Author: John W. Linville <linville@tuxdriver.com>
Date: Wed Jul 7 15:07:49 2010 -0400
mac80211: remove wep dependency
Since you create the new CRYPTO_LIB_ARC4 in patch 1, I wonder if
something is broken? I can't really seem to figure out how WEP is
disallowed in FIPS mode to start with though.
(This also is the reason for all the code that removes WEP/TKIP from the
list of permitted cipher suites when ARC4 isn't available...)
johannes
^ permalink raw reply
* Re: [PATCH] mt76: mt7615: add support for per-chain signal strength reporting
From: Sebastian Gottschall @ 2019-06-09 14:44 UTC (permalink / raw)
To: Ryder Lee, Felix Fietkau, Lorenzo Bianconi
Cc: Roy Luo, YF Luo, Yiwei Chung, Sean Wang, Chih-Min Chen,
linux-wireless, linux-mediatek, linux-kernel
In-Reply-To: <3912a2863e858f3623ced61737836e42c7b19149.1560071167.git.ryder.lee@mediatek.com>
according to my findings
MT_RXV4_RCPI1 is part of rx descriptor 4 and not 3
so it must be rxdg4 = rxd[4] etc.
however rxdg3 contains MT_RXV3_IB_RSSIRX which can be used for signal calculation.
i already wrote a similar code for this driver which i sended to felix a long time ago.
my variant looks like
status->signal = (FIELD_GET(MT_RXV3_IB_RSSIRX, rxdg3) - 220) / 2;
status->chain_signal[0] = (FIELD_GET(MT_RXV4_RCPI0, rxdg4) - 220) / 2;
status->chain_signal[1] = (FIELD_GET(MT_RXV4_RCPI1, rxdg4) - 220) / 2;
status->chain_signal[2] = (FIELD_GET(MT_RXV4_RCPI2, rxdg4) - 220) / 2;
status->chain_signal[3] = (FIELD_GET(MT_RXV4_RCPI3, rxdg4) - 220) / 2;
Am 09.06.2019 um 11:09 schrieb Ryder Lee:
> Fill in RX status->chain_signal to avoid empty value.
>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> ---
> .../net/wireless/mediatek/mt76/mt7615/mac.c | 30 ++++++++++++++++++-
> .../net/wireless/mediatek/mt76/mt7615/mac.h | 5 ++++
> 2 files changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
> index b60d42b5923d..9ee83ea11b8c
> --- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
> @@ -13,6 +13,11 @@
> #include "../dma.h"
> #include "mac.h"
>
> +static inline s8 to_rssi(u32 field, u32 rxv)
> +{
> + return (FIELD_GET(field, rxv) - 220) / 2;
> +}
> +
> static struct mt76_wcid *mt7615_rx_get_wcid(struct mt7615_dev *dev,
> u8 idx, bool unicast)
> {
> @@ -120,6 +125,7 @@ int mt7615_mac_fill_rx(struct mt7615_dev *dev, struct sk_buff *skb)
> if (rxd0 & MT_RXD0_NORMAL_GROUP_3) {
> u32 rxdg0 = le32_to_cpu(rxd[0]);
> u32 rxdg1 = le32_to_cpu(rxd[1]);
> + u32 rxdg3 = le32_to_cpu(rxd[3]);
> u8 stbc = FIELD_GET(MT_RXV1_HT_STBC, rxdg0);
> bool cck = false;
>
> @@ -169,7 +175,29 @@ int mt7615_mac_fill_rx(struct mt7615_dev *dev, struct sk_buff *skb)
>
> status->enc_flags |= RX_ENC_FLAG_STBC_MASK * stbc;
>
> - /* TODO: RSSI */
> + status->chains = dev->mt76.antenna_mask;
> + status->chain_signal[0] = to_rssi(MT_RXV4_RCPI0, rxdg3);
> + status->signal = status->chain_signal[0];
> +
> + switch (status->chains) {
> + case 0x3:
> + status->chain_signal[1] = to_rssi(MT_RXV4_RCPI1, rxdg3);
> + status->signal = max(status->signal,
> + status->chain_signal[1]);
> + break;
> + case 0x7:
> + status->chain_signal[2] = to_rssi(MT_RXV4_RCPI2, rxdg3);
> + status->signal = max(status->signal,
> + status->chain_signal[2]);
> + break;
> + case 0xf:
> + status->chain_signal[3] = to_rssi(MT_RXV4_RCPI3, rxdg3);
> + status->signal = max(status->signal,
> + status->chain_signal[3]);
> + break;
> + default:
> + break;
> + }
> rxd += 6;
> if ((u8 *)rxd - skb->data >= skb->len)
> return -EINVAL;
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.h b/drivers/net/wireless/mediatek/mt76/mt7615/mac.h
> index 18ad4b8a3807..b00ce8db58e9
> --- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.h
> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.h
> @@ -98,6 +98,11 @@ enum rx_pkt_type {
> #define MT_RXV2_GROUP_ID GENMASK(26, 21)
> #define MT_RXV2_LENGTH GENMASK(20, 0)
>
> +#define MT_RXV4_RCPI3 GENMASK(31, 24)
> +#define MT_RXV4_RCPI2 GENMASK(23, 16)
> +#define MT_RXV4_RCPI1 GENMASK(15, 8)
> +#define MT_RXV4_RCPI0 GENMASK(7, 0)
> +
> enum tx_header_format {
> MT_HDR_FORMAT_802_3,
> MT_HDR_FORMAT_CMD,
^ permalink raw reply
* Re: [PATCH v3 1/2] mt76: mt7615: enable support for mesh
From: Sebastian Gottschall @ 2019-06-09 14:36 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Ryder Lee, Felix Fietkau, Roy Luo, YF Luo, Yiwei Chung, Sean Wang,
Chih-Min Chen, linux-wireless, linux-mediatek,
Linux Kernel Mailing List
In-Reply-To: <CAJ0CqmVBogQrqf4Gckr5gQ6tCrdZG=p60ZiC+-WW-yxt93+40Q@mail.gmail.com>
by the way. this big fat kernel warning exists in all operation modes
unless anything else but aes-128 ccmp is used. since the chipset is
capable of doing gcmp etc. as well
it would be nice if this issue can be fixed. otherwise encryption
support can be defined as "broken" for mt7615
Am 06.06.2019 um 18:19 schrieb Lorenzo Bianconi:
>> i tested your patch against a qca 9984 chipset using SAE and without
>> encryption. both did not work. the devices are connecting, but no data
>> connection is possible
> Hi Sebastian,
>
> I tested Ryder's patch using mt76x2 as mesh peer and it works fine for me.
> Could you please provide some more info?
>
> Regards,
> Lorenzo
>
>>
>> Sebastian
>>
>> Am 03.06.2019 um 08:08 schrieb Ryder Lee:
>>> Enable NL80211_IFTYPE_MESH_POINT and update its path.
>>>
>>> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
>>> ---
>>> Changes since v3 - fix a wrong expression
>>> Changes since v2 - remove unused definitions
>>> ---
>>> drivers/net/wireless/mediatek/mt76/mt7615/init.c | 6 ++++++
>>> drivers/net/wireless/mediatek/mt76/mt7615/main.c | 1 +
>>> drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 4 +++-
>>> drivers/net/wireless/mediatek/mt76/mt7615/mcu.h | 6 ------
>>> 4 files changed, 10 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
>>> index 59f604f3161f..f860af6a42da 100644
>>> --- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
>>> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
>>> @@ -133,6 +133,9 @@ static const struct ieee80211_iface_limit if_limits[] = {
>>> {
>>> .max = MT7615_MAX_INTERFACES,
>>> .types = BIT(NL80211_IFTYPE_AP) |
>>> +#ifdef CONFIG_MAC80211_MESH
>>> + BIT(NL80211_IFTYPE_MESH_POINT) |
>>> +#endif
>>> BIT(NL80211_IFTYPE_STATION)
>>> }
>>> };
>>> @@ -195,6 +198,9 @@ int mt7615_register_device(struct mt7615_dev *dev)
>>> dev->mt76.antenna_mask = 0xf;
>>>
>>> wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
>>> +#ifdef CONFIG_MAC80211_MESH
>>> + BIT(NL80211_IFTYPE_MESH_POINT) |
>>> +#endif
>>> BIT(NL80211_IFTYPE_AP);
>>>
>>> ret = mt76_register_device(&dev->mt76, true, mt7615_rates,
>>> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
>>> index b0bb7cc12385..585e67fa2728 100644
>>> --- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
>>> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
>>> @@ -37,6 +37,7 @@ static int get_omac_idx(enum nl80211_iftype type, u32 mask)
>>>
>>> switch (type) {
>>> case NL80211_IFTYPE_AP:
>>> + case NL80211_IFTYPE_MESH_POINT:
>>> /* ap use hw bssid 0 and ext bssid */
>>> if (~mask & BIT(HW_BSSID_0))
>>> return HW_BSSID_0;
>>> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
>>> index 43f70195244c..e82297048449 100644
>>> --- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
>>> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
>>> @@ -754,6 +754,7 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev *dev,
>>>
>>> switch (vif->type) {
>>> case NL80211_IFTYPE_AP:
>>> + case NL80211_IFTYPE_MESH_POINT:
>>> tx_wlan_idx = mvif->sta.wcid.idx;
>>> conn_type = CONNECTION_INFRA_AP;
>>> break;
>>> @@ -968,7 +969,7 @@ int mt7615_mcu_add_wtbl(struct mt7615_dev *dev, struct ieee80211_vif *vif,
>>> .rx_wtbl = {
>>> .tag = cpu_to_le16(WTBL_RX),
>>> .len = cpu_to_le16(sizeof(struct wtbl_rx)),
>>> - .rca1 = vif->type != NL80211_IFTYPE_AP,
>>> + .rca1 = vif->type == NL80211_IFTYPE_STATION,
>>> .rca2 = 1,
>>> .rv = 1,
>>> },
>>> @@ -1042,6 +1043,7 @@ static void sta_rec_convert_vif_type(enum nl80211_iftype type, u32 *conn_type)
>>> {
>>> switch (type) {
>>> case NL80211_IFTYPE_AP:
>>> + case NL80211_IFTYPE_MESH_POINT:
>>> if (conn_type)
>>> *conn_type = CONNECTION_INFRA_STA;
>>> break;
>>> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
>>> index e96efb13fa4d..0915cb735699 100644
>>> --- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
>>> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
>>> @@ -105,25 +105,19 @@ enum {
>>> #define STA_TYPE_STA BIT(0)
>>> #define STA_TYPE_AP BIT(1)
>>> #define STA_TYPE_ADHOC BIT(2)
>>> -#define STA_TYPE_TDLS BIT(3)
>>> #define STA_TYPE_WDS BIT(4)
>>> #define STA_TYPE_BC BIT(5)
>>>
>>> #define NETWORK_INFRA BIT(16)
>>> #define NETWORK_P2P BIT(17)
>>> #define NETWORK_IBSS BIT(18)
>>> -#define NETWORK_MESH BIT(19)
>>> -#define NETWORK_BOW BIT(20)
>>> #define NETWORK_WDS BIT(21)
>>>
>>> #define CONNECTION_INFRA_STA (STA_TYPE_STA | NETWORK_INFRA)
>>> #define CONNECTION_INFRA_AP (STA_TYPE_AP | NETWORK_INFRA)
>>> #define CONNECTION_P2P_GC (STA_TYPE_STA | NETWORK_P2P)
>>> #define CONNECTION_P2P_GO (STA_TYPE_AP | NETWORK_P2P)
>>> -#define CONNECTION_MESH_STA (STA_TYPE_STA | NETWORK_MESH)
>>> -#define CONNECTION_MESH_AP (STA_TYPE_AP | NETWORK_MESH)
>>> #define CONNECTION_IBSS_ADHOC (STA_TYPE_ADHOC | NETWORK_IBSS)
>>> -#define CONNECTION_TDLS (STA_TYPE_STA | NETWORK_INFRA | STA_TYPE_TDLS)
>>> #define CONNECTION_WDS (STA_TYPE_WDS | NETWORK_WDS)
>>> #define CONNECTION_INFRA_BC (STA_TYPE_BC | NETWORK_INFRA)
>>>
^ permalink raw reply
* Re: [RFC PATCH v2] ath9k: add loader for AR92XX (and older) pci(e)
From: Julian Calaby @ 2019-06-09 13:28 UTC (permalink / raw)
To: Christian Lamparter
Cc: QCA ath9k Development, linux-wireless, Hauke Mehrtens,
Martin Blumenstingl
In-Reply-To: <20190608144947.744-2-chunkeey@gmail.com>
Hi Christian,
On Sun, Jun 9, 2019 at 12:49 AM Christian Lamparter <chunkeey@gmail.com> wrote:
>
> Atheros cards with a AR92XX generation (and older) chip usually
> store their pci(e) initialization vectors on an external eeprom chip.
> However these chips technically don't need the eeprom chip attached,
> the AR9280 Datasheet in section "6.1.2 DEVICE_ID" describes that
> "... if the EEPROM content is not valid, a value of 0XFF1C returns
> when read from the register". So the embedded devices like routers
> and accesspoint usually have the pci(e) initialization vectors
> stored on the system's FLASH, which is out of reach of the ath9k
> chip.
>
> Furthermore, Some devices (like the Cisco Meraki Z1 Cloud Managed
> Teleworker Gateway) need to be able to initialize the PCIe wifi device.
> Normally, this should be done as a pci quirk during the early stages of
> booting linux. However, this isn't possible for devices which have the
> init code for the Atheros chip stored on NAND in an UBI volume.
> Hence, this module can be used to initialize the chip when the
> user-space is ready to extract the init code.
>
> Martin Blumenstingl prodived the following fixes:
> owl-loader: add support for OWL emulation PCI devices
> owl-loader: don't re-scan the bus when ath9k_pci_fixup failed
> owl-loader: use dev_* instead of pr_* logging functions
> owl-loader: auto-generate the eeprom filename as fallback
> owl-loader: add a debug message when swapping the eeprom data
> owl-loader: add missing newlines in log messages
>
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
> v2: address Julian Calaby's comments:
> - make it a separate driver again (much like OpenWrt)
> - remove ar71xx leftovers (pdata)
This looks sane to me. Thanks for splitting it out.
Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
> ---
> drivers/net/wireless/ath/ath9k/Kconfig | 16 ++
> drivers/net/wireless/ath/ath9k/Makefile | 2 +
> .../wireless/ath/ath9k/ath9k_pci_owl_loader.c | 215 ++++++++++++++++++
> 3 files changed, 233 insertions(+)
> create mode 100644 drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
>
> diff --git a/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
> new file mode 100644
> index 000000000000..7ed495a9f1fe
> --- /dev/null
> +++ b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
> @@ -0,0 +1,215 @@
> +module_pci_driver(owl_driver);
> +MODULE_AUTHOR("Christian Lamparter <chunkeey@gmail.com>");
> +MODULE_DESCRIPTION("Initializes Atheros' Owl Emulation devices");
Tiniest nit: something like "External EEPROM data loader for Atheros
AR500X to AR92XX" would make more sense to someone who isn't familiar
with the hardware.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* [PATCH v2 3/7] net/lib80211: move WEP handling to ARC4 library code
From: Ard Biesheuvel @ 2019-06-09 11:55 UTC (permalink / raw)
To: linux-crypto
Cc: Ard Biesheuvel, Herbert Xu, David S. Miller, Eric Biggers,
linux-wireless, Johannes Berg
In-Reply-To: <20190609115509.26260-1-ard.biesheuvel@linaro.org>
The crypto API abstraction is not very useful for invoking ciphers
directly, especially in the case of arc4, which only has a generic
implementation in C. So let's invoke the library code directly.
Cc: linux-wireless@vger.kernel.org
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
net/wireless/Kconfig | 1 +
net/wireless/lib80211_crypt_wep.c | 43 ++++----------------
2 files changed, 9 insertions(+), 35 deletions(-)
diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index 6310ddede220..6d9c48cea07e 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -213,6 +213,7 @@ config LIB80211
config LIB80211_CRYPT_WEP
tristate
+ select CRYPTO_LIB_ARC4
config LIB80211_CRYPT_CCMP
tristate
diff --git a/net/wireless/lib80211_crypt_wep.c b/net/wireless/lib80211_crypt_wep.c
index 20c1ad63ad44..3db1b2e6a25a 100644
--- a/net/wireless/lib80211_crypt_wep.c
+++ b/net/wireless/lib80211_crypt_wep.c
@@ -22,7 +22,7 @@
#include <net/lib80211.h>
-#include <linux/crypto.h>
+#include <crypto/arc4.h>
#include <linux/crc32.h>
MODULE_AUTHOR("Jouni Malinen");
@@ -35,8 +35,8 @@ struct lib80211_wep_data {
u8 key[WEP_KEY_LEN + 1];
u8 key_len;
u8 key_idx;
- struct crypto_cipher *tx_tfm;
- struct crypto_cipher *rx_tfm;
+ struct crypto_arc4_ctx tx_ctx;
+ struct crypto_arc4_ctx rx_ctx;
};
static void *lib80211_wep_init(int keyidx)
@@ -45,41 +45,17 @@ static void *lib80211_wep_init(int keyidx)
priv = kzalloc(sizeof(*priv), GFP_ATOMIC);
if (priv == NULL)
- goto fail;
+ return NULL;
priv->key_idx = keyidx;
- priv->tx_tfm = crypto_alloc_cipher("arc4", 0, 0);
- if (IS_ERR(priv->tx_tfm)) {
- priv->tx_tfm = NULL;
- goto fail;
- }
-
- priv->rx_tfm = crypto_alloc_cipher("arc4", 0, 0);
- if (IS_ERR(priv->rx_tfm)) {
- priv->rx_tfm = NULL;
- goto fail;
- }
/* start WEP IV from a random value */
get_random_bytes(&priv->iv, 4);
return priv;
-
- fail:
- if (priv) {
- crypto_free_cipher(priv->tx_tfm);
- crypto_free_cipher(priv->rx_tfm);
- kfree(priv);
- }
- return NULL;
}
static void lib80211_wep_deinit(void *priv)
{
- struct lib80211_wep_data *_priv = priv;
- if (_priv) {
- crypto_free_cipher(_priv->tx_tfm);
- crypto_free_cipher(_priv->rx_tfm);
- }
kfree(priv);
}
@@ -160,10 +136,8 @@ static int lib80211_wep_encrypt(struct sk_buff *skb, int hdr_len, void *priv)
icv[2] = crc >> 16;
icv[3] = crc >> 24;
- crypto_cipher_setkey(wep->tx_tfm, key, klen);
-
- for (i = 0; i < len + 4; i++)
- crypto_cipher_encrypt_one(wep->tx_tfm, pos + i, pos + i);
+ crypto_arc4_set_key(&wep->tx_ctx, key, klen);
+ crypto_arc4_crypt(&wep->tx_ctx, pos, pos, len + 4);
return 0;
}
@@ -202,9 +176,8 @@ static int lib80211_wep_decrypt(struct sk_buff *skb, int hdr_len, void *priv)
/* Apply RC4 to data and compute CRC32 over decrypted data */
plen = skb->len - hdr_len - 8;
- crypto_cipher_setkey(wep->rx_tfm, key, klen);
- for (i = 0; i < plen + 4; i++)
- crypto_cipher_decrypt_one(wep->rx_tfm, pos + i, pos + i);
+ crypto_arc4_set_key(&wep->rx_ctx, key, klen);
+ crypto_arc4_crypt(&wep->rx_ctx, pos, pos, plen + 4);
crc = ~crc32_le(~0, pos, plen);
icv[0] = crc;
--
2.20.1
^ permalink raw reply related
* [PATCH v2 4/7] net/lib80211: move TKIP handling to ARC4 library code
From: Ard Biesheuvel @ 2019-06-09 11:55 UTC (permalink / raw)
To: linux-crypto
Cc: Ard Biesheuvel, Herbert Xu, David S. Miller, Eric Biggers,
linux-wireless, Johannes Berg
In-Reply-To: <20190609115509.26260-1-ard.biesheuvel@linaro.org>
The crypto API abstraction is not very useful for invoking ciphers
directly, especially in the case of arc4, which only has a generic
implementation in C. So let's invoke the library code directly.
Cc: linux-wireless@vger.kernel.org
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
net/wireless/lib80211_crypt_tkip.c | 42 ++++++--------------
1 file changed, 12 insertions(+), 30 deletions(-)
diff --git a/net/wireless/lib80211_crypt_tkip.c b/net/wireless/lib80211_crypt_tkip.c
index 11eaa5956f00..c19528a39563 100644
--- a/net/wireless/lib80211_crypt_tkip.c
+++ b/net/wireless/lib80211_crypt_tkip.c
@@ -29,6 +29,7 @@
#include <linux/ieee80211.h>
#include <net/iw_handler.h>
+#include <crypto/arc4.h>
#include <crypto/hash.h>
#include <linux/crypto.h>
#include <linux/crc32.h>
@@ -64,9 +65,9 @@ struct lib80211_tkip_data {
int key_idx;
- struct crypto_cipher *rx_tfm_arc4;
+ struct crypto_arc4_ctx rx_ctx_arc4;
+ struct crypto_arc4_ctx tx_ctx_arc4;
struct crypto_shash *rx_tfm_michael;
- struct crypto_cipher *tx_tfm_arc4;
struct crypto_shash *tx_tfm_michael;
/* scratch buffers for virt_to_page() (crypto API) */
@@ -99,24 +100,12 @@ static void *lib80211_tkip_init(int key_idx)
priv->key_idx = key_idx;
- priv->tx_tfm_arc4 = crypto_alloc_cipher("arc4", 0, 0);
- if (IS_ERR(priv->tx_tfm_arc4)) {
- priv->tx_tfm_arc4 = NULL;
- goto fail;
- }
-
priv->tx_tfm_michael = crypto_alloc_shash("michael_mic", 0, 0);
if (IS_ERR(priv->tx_tfm_michael)) {
priv->tx_tfm_michael = NULL;
goto fail;
}
- priv->rx_tfm_arc4 = crypto_alloc_cipher("arc4", 0, 0);
- if (IS_ERR(priv->rx_tfm_arc4)) {
- priv->rx_tfm_arc4 = NULL;
- goto fail;
- }
-
priv->rx_tfm_michael = crypto_alloc_shash("michael_mic", 0, 0);
if (IS_ERR(priv->rx_tfm_michael)) {
priv->rx_tfm_michael = NULL;
@@ -128,9 +117,7 @@ static void *lib80211_tkip_init(int key_idx)
fail:
if (priv) {
crypto_free_shash(priv->tx_tfm_michael);
- crypto_free_cipher(priv->tx_tfm_arc4);
crypto_free_shash(priv->rx_tfm_michael);
- crypto_free_cipher(priv->rx_tfm_arc4);
kfree(priv);
}
@@ -142,9 +129,7 @@ static void lib80211_tkip_deinit(void *priv)
struct lib80211_tkip_data *_priv = priv;
if (_priv) {
crypto_free_shash(_priv->tx_tfm_michael);
- crypto_free_cipher(_priv->tx_tfm_arc4);
crypto_free_shash(_priv->rx_tfm_michael);
- crypto_free_cipher(_priv->rx_tfm_arc4);
}
kfree(priv);
}
@@ -345,7 +330,6 @@ static int lib80211_tkip_encrypt(struct sk_buff *skb, int hdr_len, void *priv)
int len;
u8 rc4key[16], *pos, *icv;
u32 crc;
- int i;
if (tkey->flags & IEEE80211_CRYPTO_TKIP_COUNTERMEASURES) {
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
@@ -370,9 +354,9 @@ static int lib80211_tkip_encrypt(struct sk_buff *skb, int hdr_len, void *priv)
icv[2] = crc >> 16;
icv[3] = crc >> 24;
- crypto_cipher_setkey(tkey->tx_tfm_arc4, rc4key, 16);
- for (i = 0; i < len + 4; i++)
- crypto_cipher_encrypt_one(tkey->tx_tfm_arc4, pos + i, pos + i);
+ crypto_arc4_set_key(&tkey->tx_ctx_arc4, rc4key, 16);
+ crypto_arc4_crypt(&tkey->tx_ctx_arc4, pos, pos, len + 4);
+
return 0;
}
@@ -400,7 +384,6 @@ static int lib80211_tkip_decrypt(struct sk_buff *skb, int hdr_len, void *priv)
u8 icv[4];
u32 crc;
int plen;
- int i;
hdr = (struct ieee80211_hdr *)skb->data;
@@ -453,9 +436,8 @@ static int lib80211_tkip_decrypt(struct sk_buff *skb, int hdr_len, void *priv)
plen = skb->len - hdr_len - 12;
- crypto_cipher_setkey(tkey->rx_tfm_arc4, rc4key, 16);
- for (i = 0; i < plen + 4; i++)
- crypto_cipher_decrypt_one(tkey->rx_tfm_arc4, pos + i, pos + i);
+ crypto_arc4_set_key(&tkey->rx_ctx_arc4, rc4key, 16);
+ crypto_arc4_crypt(&tkey->rx_ctx_arc4, pos, pos, plen + 4);
crc = ~crc32_le(~0, pos, plen);
icv[0] = crc;
@@ -640,17 +622,17 @@ static int lib80211_tkip_set_key(void *key, int len, u8 * seq, void *priv)
struct lib80211_tkip_data *tkey = priv;
int keyidx;
struct crypto_shash *tfm = tkey->tx_tfm_michael;
- struct crypto_cipher *tfm2 = tkey->tx_tfm_arc4;
+ struct crypto_arc4_ctx *tfm2 = &tkey->tx_ctx_arc4;
struct crypto_shash *tfm3 = tkey->rx_tfm_michael;
- struct crypto_cipher *tfm4 = tkey->rx_tfm_arc4;
+ struct crypto_arc4_ctx *tfm4 = &tkey->rx_ctx_arc4;
keyidx = tkey->key_idx;
memset(tkey, 0, sizeof(*tkey));
tkey->key_idx = keyidx;
tkey->tx_tfm_michael = tfm;
- tkey->tx_tfm_arc4 = tfm2;
+ tkey->tx_ctx_arc4 = *tfm2;
tkey->rx_tfm_michael = tfm3;
- tkey->rx_tfm_arc4 = tfm4;
+ tkey->rx_ctx_arc4 = *tfm4;
if (len == TKIP_KEY_LEN) {
memcpy(tkey->key, key, TKIP_KEY_LEN);
tkey->key_set = 1;
--
2.20.1
^ permalink raw reply related
* [PATCH v2 2/7] net/mac80211: move WEP handling to ARC4 library interface
From: Ard Biesheuvel @ 2019-06-09 11:55 UTC (permalink / raw)
To: linux-crypto
Cc: Ard Biesheuvel, Herbert Xu, David S. Miller, Eric Biggers,
linux-wireless, Johannes Berg
In-Reply-To: <20190609115509.26260-1-ard.biesheuvel@linaro.org>
The WEP code in the mac80211 subsystem currently uses the crypto
API to access the arc4 (RC4) cipher, which is overly complicated,
and doesn't really have an upside in this particular case, since
ciphers are always synchronous and therefore always implemented in
software. Given that we have no accelerated software implementations
either, it is much more straightforward to invoke a generic library
interface directly.
Cc: linux-wireless@vger.kernel.org
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
net/mac80211/Kconfig | 2 +-
net/mac80211/cfg.c | 3 --
net/mac80211/ieee80211_i.h | 4 +-
net/mac80211/key.h | 1 +
net/mac80211/main.c | 48 ++------------------
net/mac80211/mlme.c | 2 -
net/mac80211/tkip.c | 8 ++--
net/mac80211/tkip.h | 4 +-
net/mac80211/wep.c | 47 ++++---------------
net/mac80211/wep.h | 4 +-
net/mac80211/wpa.c | 4 +-
11 files changed, 26 insertions(+), 101 deletions(-)
diff --git a/net/mac80211/Kconfig b/net/mac80211/Kconfig
index 0227cce9685e..0c93b1b7a826 100644
--- a/net/mac80211/Kconfig
+++ b/net/mac80211/Kconfig
@@ -3,7 +3,7 @@ config MAC80211
tristate "Generic IEEE 802.11 Networking Stack (mac80211)"
depends on CFG80211
select CRYPTO
- select CRYPTO_ARC4
+ select CRYPTO_LIB_ARC4
select CRYPTO_AES
select CRYPTO_CCM
select CRYPTO_GCM
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index a1973a26c7fc..9d8a8878a487 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -402,9 +402,6 @@ static int ieee80211_add_key(struct wiphy *wiphy, struct net_device *dev,
case WLAN_CIPHER_SUITE_WEP40:
case WLAN_CIPHER_SUITE_TKIP:
case WLAN_CIPHER_SUITE_WEP104:
- if (IS_ERR(local->wep_tx_tfm))
- return -EINVAL;
- break;
case WLAN_CIPHER_SUITE_CCMP:
case WLAN_CIPHER_SUITE_CCMP_256:
case WLAN_CIPHER_SUITE_AES_CMAC:
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 073a8235ae1b..b2862e73f1fc 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1258,8 +1258,8 @@ struct ieee80211_local {
struct rate_control_ref *rate_ctrl;
- struct crypto_cipher *wep_tx_tfm;
- struct crypto_cipher *wep_rx_tfm;
+ struct crypto_arc4_ctx wep_tx_ctx;
+ struct crypto_arc4_ctx wep_rx_ctx;
u32 wep_iv;
/* see iface.c */
diff --git a/net/mac80211/key.h b/net/mac80211/key.h
index f06fbd03d235..6c5bbaebd02c 100644
--- a/net/mac80211/key.h
+++ b/net/mac80211/key.h
@@ -14,6 +14,7 @@
#include <linux/list.h>
#include <linux/crypto.h>
#include <linux/rcupdate.h>
+#include <crypto/arc4.h>
#include <net/mac80211.h>
#define NUM_DEFAULT_KEYS 4
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 2b608044ae23..b339307035d2 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -733,8 +733,6 @@ EXPORT_SYMBOL(ieee80211_alloc_hw_nm);
static int ieee80211_init_cipher_suites(struct ieee80211_local *local)
{
- bool have_wep = !(IS_ERR(local->wep_tx_tfm) ||
- IS_ERR(local->wep_rx_tfm));
bool have_mfp = ieee80211_hw_check(&local->hw, MFP_CAPABLE);
int n_suites = 0, r = 0, w = 0;
u32 *suites;
@@ -757,31 +755,7 @@ static int ieee80211_init_cipher_suites(struct ieee80211_local *local)
if (ieee80211_hw_check(&local->hw, SW_CRYPTO_CONTROL) ||
local->hw.wiphy->cipher_suites) {
- /* If the driver advertises, or doesn't support SW crypto,
- * we only need to remove WEP if necessary.
- */
- if (have_wep)
- return 0;
-
- /* well if it has _no_ ciphers ... fine */
- if (!local->hw.wiphy->n_cipher_suites)
- return 0;
-
- /* Driver provides cipher suites, but we need to exclude WEP */
- suites = kmemdup(local->hw.wiphy->cipher_suites,
- sizeof(u32) * local->hw.wiphy->n_cipher_suites,
- GFP_KERNEL);
- if (!suites)
- return -ENOMEM;
-
- for (r = 0; r < local->hw.wiphy->n_cipher_suites; r++) {
- u32 suite = local->hw.wiphy->cipher_suites[r];
-
- if (suite == WLAN_CIPHER_SUITE_WEP40 ||
- suite == WLAN_CIPHER_SUITE_WEP104)
- continue;
- suites[w++] = suite;
- }
+ return 0;
} else if (!local->hw.cipher_schemes) {
/* If the driver doesn't have cipher schemes, there's nothing
* else to do other than assign the (software supported and
@@ -793,11 +767,6 @@ static int ieee80211_init_cipher_suites(struct ieee80211_local *local)
if (!have_mfp)
local->hw.wiphy->n_cipher_suites -= 4;
- if (!have_wep) {
- local->hw.wiphy->cipher_suites += 2;
- local->hw.wiphy->n_cipher_suites -= 2;
- }
-
/* not dynamically allocated, so just return */
return 0;
} else {
@@ -811,11 +780,7 @@ static int ieee80211_init_cipher_suites(struct ieee80211_local *local)
* We start counting ciphers defined by schemes, TKIP, CCMP,
* CCMP-256, GCMP, and GCMP-256
*/
- n_suites = local->hw.n_cipher_schemes + 5;
-
- /* check if we have WEP40 and WEP104 */
- if (have_wep)
- n_suites += 2;
+ n_suites = local->hw.n_cipher_schemes + 7;
/* check if we have AES_CMAC, BIP-CMAC-256, BIP-GMAC-128,
* BIP-GMAC-256
@@ -832,11 +797,8 @@ static int ieee80211_init_cipher_suites(struct ieee80211_local *local)
suites[w++] = WLAN_CIPHER_SUITE_TKIP;
suites[w++] = WLAN_CIPHER_SUITE_GCMP;
suites[w++] = WLAN_CIPHER_SUITE_GCMP_256;
-
- if (have_wep) {
- suites[w++] = WLAN_CIPHER_SUITE_WEP40;
- suites[w++] = WLAN_CIPHER_SUITE_WEP104;
- }
+ suites[w++] = WLAN_CIPHER_SUITE_WEP40;
+ suites[w++] = WLAN_CIPHER_SUITE_WEP104;
if (have_mfp) {
suites[w++] = WLAN_CIPHER_SUITE_AES_CMAC;
@@ -1301,7 +1263,6 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
fail_rate:
rtnl_unlock();
ieee80211_led_exit(local);
- ieee80211_wep_free(local);
fail_flows:
destroy_workqueue(local->workqueue);
fail_workqueue:
@@ -1358,7 +1319,6 @@ void ieee80211_unregister_hw(struct ieee80211_hw *hw)
destroy_workqueue(local->workqueue);
wiphy_unregister(local->hw.wiphy);
- ieee80211_wep_free(local);
ieee80211_led_exit(local);
kfree(local->int_scan_req);
}
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index b7a9fe3d5fcb..cf8b87cfd619 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -5038,8 +5038,6 @@ int ieee80211_mgd_auth(struct ieee80211_sub_if_data *sdata,
auth_alg = WLAN_AUTH_OPEN;
break;
case NL80211_AUTHTYPE_SHARED_KEY:
- if (IS_ERR(local->wep_tx_tfm))
- return -EOPNOTSUPP;
auth_alg = WLAN_AUTH_SHARED_KEY;
break;
case NL80211_AUTHTYPE_FT:
diff --git a/net/mac80211/tkip.c b/net/mac80211/tkip.c
index b3622823bad2..580b5c3e837e 100644
--- a/net/mac80211/tkip.c
+++ b/net/mac80211/tkip.c
@@ -222,7 +222,7 @@ EXPORT_SYMBOL(ieee80211_get_tkip_p2k);
* @payload_len is the length of payload (_not_ including IV/ICV length).
* @ta is the transmitter addresses.
*/
-int ieee80211_tkip_encrypt_data(struct crypto_cipher *tfm,
+int ieee80211_tkip_encrypt_data(struct crypto_arc4_ctx *ctx,
struct ieee80211_key *key,
struct sk_buff *skb,
u8 *payload, size_t payload_len)
@@ -231,7 +231,7 @@ int ieee80211_tkip_encrypt_data(struct crypto_cipher *tfm,
ieee80211_get_tkip_p2k(&key->conf, skb, rc4key);
- return ieee80211_wep_encrypt_data(tfm, rc4key, 16,
+ return ieee80211_wep_encrypt_data(ctx, rc4key, 16,
payload, payload_len);
}
@@ -239,7 +239,7 @@ int ieee80211_tkip_encrypt_data(struct crypto_cipher *tfm,
* beginning of the buffer containing IEEE 802.11 header payload, i.e.,
* including IV, Ext. IV, real data, Michael MIC, ICV. @payload_len is the
* length of payload, including IV, Ext. IV, MIC, ICV. */
-int ieee80211_tkip_decrypt_data(struct crypto_cipher *tfm,
+int ieee80211_tkip_decrypt_data(struct crypto_arc4_ctx *ctx,
struct ieee80211_key *key,
u8 *payload, size_t payload_len, u8 *ta,
u8 *ra, int only_iv, int queue,
@@ -297,7 +297,7 @@ int ieee80211_tkip_decrypt_data(struct crypto_cipher *tfm,
tkip_mixing_phase2(tk, &rx_ctx->ctx, iv16, rc4key);
- res = ieee80211_wep_decrypt_data(tfm, rc4key, 16, pos, payload_len - 12);
+ res = ieee80211_wep_decrypt_data(ctx, rc4key, 16, pos, payload_len - 12);
done:
if (res == TKIP_DECRYPT_OK) {
/*
diff --git a/net/mac80211/tkip.h b/net/mac80211/tkip.h
index a1bcbfbefe7c..42b300773c58 100644
--- a/net/mac80211/tkip.h
+++ b/net/mac80211/tkip.h
@@ -13,7 +13,7 @@
#include <linux/crypto.h>
#include "key.h"
-int ieee80211_tkip_encrypt_data(struct crypto_cipher *tfm,
+int ieee80211_tkip_encrypt_data(struct crypto_arc4_ctx *ctx,
struct ieee80211_key *key,
struct sk_buff *skb,
u8 *payload, size_t payload_len);
@@ -24,7 +24,7 @@ enum {
TKIP_DECRYPT_INVALID_KEYIDX = -2,
TKIP_DECRYPT_REPLAY = -3,
};
-int ieee80211_tkip_decrypt_data(struct crypto_cipher *tfm,
+int ieee80211_tkip_decrypt_data(struct crypto_arc4_ctx *ctx,
struct ieee80211_key *key,
u8 *payload, size_t payload_len, u8 *ta,
u8 *ra, int only_iv, int queue,
diff --git a/net/mac80211/wep.c b/net/mac80211/wep.c
index bfe9ed9f4c48..9aad40e28374 100644
--- a/net/mac80211/wep.c
+++ b/net/mac80211/wep.c
@@ -30,30 +30,9 @@ int ieee80211_wep_init(struct ieee80211_local *local)
/* start WEP IV from a random value */
get_random_bytes(&local->wep_iv, IEEE80211_WEP_IV_LEN);
- local->wep_tx_tfm = crypto_alloc_cipher("arc4", 0, 0);
- if (IS_ERR(local->wep_tx_tfm)) {
- local->wep_rx_tfm = ERR_PTR(-EINVAL);
- return PTR_ERR(local->wep_tx_tfm);
- }
-
- local->wep_rx_tfm = crypto_alloc_cipher("arc4", 0, 0);
- if (IS_ERR(local->wep_rx_tfm)) {
- crypto_free_cipher(local->wep_tx_tfm);
- local->wep_tx_tfm = ERR_PTR(-EINVAL);
- return PTR_ERR(local->wep_rx_tfm);
- }
-
return 0;
}
-void ieee80211_wep_free(struct ieee80211_local *local)
-{
- if (!IS_ERR(local->wep_tx_tfm))
- crypto_free_cipher(local->wep_tx_tfm);
- if (!IS_ERR(local->wep_rx_tfm))
- crypto_free_cipher(local->wep_rx_tfm);
-}
-
static inline bool ieee80211_wep_weak_iv(u32 iv, int keylen)
{
/*
@@ -131,21 +110,16 @@ static void ieee80211_wep_remove_iv(struct ieee80211_local *local,
/* Perform WEP encryption using given key. data buffer must have tailroom
* for 4-byte ICV. data_len must not include this ICV. Note: this function
* does _not_ add IV. data = RC4(data | CRC32(data)) */
-int ieee80211_wep_encrypt_data(struct crypto_cipher *tfm, u8 *rc4key,
+int ieee80211_wep_encrypt_data(struct crypto_arc4_ctx *ctx, u8 *rc4key,
size_t klen, u8 *data, size_t data_len)
{
__le32 icv;
- int i;
-
- if (IS_ERR(tfm))
- return -1;
icv = cpu_to_le32(~crc32_le(~0, data, data_len));
put_unaligned(icv, (__le32 *)(data + data_len));
- crypto_cipher_setkey(tfm, rc4key, klen);
- for (i = 0; i < data_len + IEEE80211_WEP_ICV_LEN; i++)
- crypto_cipher_encrypt_one(tfm, data + i, data + i);
+ crypto_arc4_set_key(ctx, rc4key, klen);
+ crypto_arc4_crypt(ctx, data, data, data_len + IEEE80211_WEP_ICV_LEN);
return 0;
}
@@ -184,7 +158,7 @@ int ieee80211_wep_encrypt(struct ieee80211_local *local,
/* Add room for ICV */
skb_put(skb, IEEE80211_WEP_ICV_LEN);
- return ieee80211_wep_encrypt_data(local->wep_tx_tfm, rc4key, keylen + 3,
+ return ieee80211_wep_encrypt_data(&local->wep_tx_ctx, rc4key, keylen + 3,
iv + IEEE80211_WEP_IV_LEN, len);
}
@@ -192,18 +166,13 @@ int ieee80211_wep_encrypt(struct ieee80211_local *local,
/* Perform WEP decryption using given key. data buffer includes encrypted
* payload, including 4-byte ICV, but _not_ IV. data_len must not include ICV.
* Return 0 on success and -1 on ICV mismatch. */
-int ieee80211_wep_decrypt_data(struct crypto_cipher *tfm, u8 *rc4key,
+int ieee80211_wep_decrypt_data(struct crypto_arc4_ctx *ctx, u8 *rc4key,
size_t klen, u8 *data, size_t data_len)
{
__le32 crc;
- int i;
-
- if (IS_ERR(tfm))
- return -1;
- crypto_cipher_setkey(tfm, rc4key, klen);
- for (i = 0; i < data_len + IEEE80211_WEP_ICV_LEN; i++)
- crypto_cipher_decrypt_one(tfm, data + i, data + i);
+ crypto_arc4_set_key(ctx, rc4key, klen);
+ crypto_arc4_crypt(ctx, data, data, data_len + IEEE80211_WEP_ICV_LEN);
crc = cpu_to_le32(~crc32_le(~0, data, data_len));
if (memcmp(&crc, data + data_len, IEEE80211_WEP_ICV_LEN) != 0)
@@ -256,7 +225,7 @@ static int ieee80211_wep_decrypt(struct ieee80211_local *local,
/* Copy rest of the WEP key (the secret part) */
memcpy(rc4key + 3, key->conf.key, key->conf.keylen);
- if (ieee80211_wep_decrypt_data(local->wep_rx_tfm, rc4key, klen,
+ if (ieee80211_wep_decrypt_data(&local->wep_rx_ctx, rc4key, klen,
skb->data + hdrlen +
IEEE80211_WEP_IV_LEN, len))
ret = -1;
diff --git a/net/mac80211/wep.h b/net/mac80211/wep.h
index 9615749d1f65..b63dda9dd442 100644
--- a/net/mac80211/wep.h
+++ b/net/mac80211/wep.h
@@ -18,12 +18,12 @@
int ieee80211_wep_init(struct ieee80211_local *local);
void ieee80211_wep_free(struct ieee80211_local *local);
-int ieee80211_wep_encrypt_data(struct crypto_cipher *tfm, u8 *rc4key,
+int ieee80211_wep_encrypt_data(struct crypto_arc4_ctx *ctx, u8 *rc4key,
size_t klen, u8 *data, size_t data_len);
int ieee80211_wep_encrypt(struct ieee80211_local *local,
struct sk_buff *skb,
const u8 *key, int keylen, int keyidx);
-int ieee80211_wep_decrypt_data(struct crypto_cipher *tfm, u8 *rc4key,
+int ieee80211_wep_decrypt_data(struct crypto_arc4_ctx *ctx, u8 *rc4key,
size_t klen, u8 *data, size_t data_len);
ieee80211_rx_result
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index 58d0b258b684..02e8ab7b2b4c 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -242,7 +242,7 @@ static int tkip_encrypt_skb(struct ieee80211_tx_data *tx, struct sk_buff *skb)
/* Add room for ICV */
skb_put(skb, IEEE80211_TKIP_ICV_LEN);
- return ieee80211_tkip_encrypt_data(tx->local->wep_tx_tfm,
+ return ieee80211_tkip_encrypt_data(&tx->local->wep_tx_ctx,
key, skb, pos, len);
}
@@ -293,7 +293,7 @@ ieee80211_crypto_tkip_decrypt(struct ieee80211_rx_data *rx)
if (status->flag & RX_FLAG_DECRYPTED)
hwaccel = 1;
- res = ieee80211_tkip_decrypt_data(rx->local->wep_rx_tfm,
+ res = ieee80211_tkip_decrypt_data(&rx->local->wep_rx_ctx,
key, skb->data + hdrlen,
skb->len - hdrlen, rx->sta->sta.addr,
hdr->addr1, hwaccel, rx->security_idx,
--
2.20.1
^ permalink raw reply related
* [PATCH] mt76: mt7615: add support for per-chain signal strength reporting
From: Ryder Lee @ 2019-06-09 9:09 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi
Cc: Roy Luo, YF Luo, Yiwei Chung, Sean Wang, Chih-Min Chen,
linux-wireless, linux-mediatek, linux-kernel, Ryder Lee
Fill in RX status->chain_signal to avoid empty value.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
---
.../net/wireless/mediatek/mt76/mt7615/mac.c | 30 ++++++++++++++++++-
.../net/wireless/mediatek/mt76/mt7615/mac.h | 5 ++++
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
index b60d42b5923d..9ee83ea11b8c
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
@@ -13,6 +13,11 @@
#include "../dma.h"
#include "mac.h"
+static inline s8 to_rssi(u32 field, u32 rxv)
+{
+ return (FIELD_GET(field, rxv) - 220) / 2;
+}
+
static struct mt76_wcid *mt7615_rx_get_wcid(struct mt7615_dev *dev,
u8 idx, bool unicast)
{
@@ -120,6 +125,7 @@ int mt7615_mac_fill_rx(struct mt7615_dev *dev, struct sk_buff *skb)
if (rxd0 & MT_RXD0_NORMAL_GROUP_3) {
u32 rxdg0 = le32_to_cpu(rxd[0]);
u32 rxdg1 = le32_to_cpu(rxd[1]);
+ u32 rxdg3 = le32_to_cpu(rxd[3]);
u8 stbc = FIELD_GET(MT_RXV1_HT_STBC, rxdg0);
bool cck = false;
@@ -169,7 +175,29 @@ int mt7615_mac_fill_rx(struct mt7615_dev *dev, struct sk_buff *skb)
status->enc_flags |= RX_ENC_FLAG_STBC_MASK * stbc;
- /* TODO: RSSI */
+ status->chains = dev->mt76.antenna_mask;
+ status->chain_signal[0] = to_rssi(MT_RXV4_RCPI0, rxdg3);
+ status->signal = status->chain_signal[0];
+
+ switch (status->chains) {
+ case 0x3:
+ status->chain_signal[1] = to_rssi(MT_RXV4_RCPI1, rxdg3);
+ status->signal = max(status->signal,
+ status->chain_signal[1]);
+ break;
+ case 0x7:
+ status->chain_signal[2] = to_rssi(MT_RXV4_RCPI2, rxdg3);
+ status->signal = max(status->signal,
+ status->chain_signal[2]);
+ break;
+ case 0xf:
+ status->chain_signal[3] = to_rssi(MT_RXV4_RCPI3, rxdg3);
+ status->signal = max(status->signal,
+ status->chain_signal[3]);
+ break;
+ default:
+ break;
+ }
rxd += 6;
if ((u8 *)rxd - skb->data >= skb->len)
return -EINVAL;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.h b/drivers/net/wireless/mediatek/mt76/mt7615/mac.h
index 18ad4b8a3807..b00ce8db58e9
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.h
@@ -98,6 +98,11 @@ enum rx_pkt_type {
#define MT_RXV2_GROUP_ID GENMASK(26, 21)
#define MT_RXV2_LENGTH GENMASK(20, 0)
+#define MT_RXV4_RCPI3 GENMASK(31, 24)
+#define MT_RXV4_RCPI2 GENMASK(23, 16)
+#define MT_RXV4_RCPI1 GENMASK(15, 8)
+#define MT_RXV4_RCPI0 GENMASK(7, 0)
+
enum tx_header_format {
MT_HDR_FORMAT_802_3,
MT_HDR_FORMAT_CMD,
--
2.18.0
^ permalink raw reply related
* [PATCH v3 20/33] docs: convert docs to ReST and rename to *.rst
From: Mauro Carvalho Chehab @ 2019-06-09 2:27 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Sebastian Reichel, Rafael J. Wysocki,
Viresh Kumar, Len Brown, Pavel Machek, Nishanth Menon,
Stephen Boyd, Liam Girdwood, Mark Brown, Mathieu Poirier,
Suzuki K Poulose, Harry Wei, Alex Shi, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, x86, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, David Airlie, Daniel Vetter,
Bjorn Helgaas, Johannes Berg, David S. Miller, linux-pm,
linux-arm-kernel, intel-gfx, dri-devel, linux-pci, linux-wireless,
netdev
In-Reply-To: <cover.1560045490.git.mchehab+samsung@kernel.org>
Convert the PM documents to ReST, in order to allow them to
build with Sphinx.
The conversion is actually:
- add blank lines and identation in order to identify paragraphs;
- fix tables markups;
- add some lists markups;
- mark literal blocks;
- adjust title markups.
At its new index.rst, let's add a :orphan: while this is not linked to
the main index.rst file, in order to avoid build warnings.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
.../ABI/testing/sysfs-class-powercap | 2 +-
.../admin-guide/kernel-parameters.txt | 6 +-
Documentation/cpu-freq/core.rst | 2 +-
Documentation/driver-api/pm/devices.rst | 6 +-
.../driver-api/usb/power-management.rst | 2 +-
.../power/{apm-acpi.txt => apm-acpi.rst} | 10 +-
...m-debugging.txt => basic-pm-debugging.rst} | 79 ++-
...harger-manager.txt => charger-manager.rst} | 101 +--
...rivers-testing.txt => drivers-testing.rst} | 15 +-
.../{energy-model.txt => energy-model.rst} | 101 +--
...ing-of-tasks.txt => freezing-of-tasks.rst} | 91 +--
Documentation/power/index.rst | 46 ++
.../power/{interface.txt => interface.rst} | 24 +-
Documentation/power/{opp.txt => opp.rst} | 175 +++--
Documentation/power/{pci.txt => pci.rst} | 87 ++-
...qos_interface.txt => pm_qos_interface.rst} | 127 ++--
...upply_class.txt => power_supply_class.rst} | 269 +++++---
.../powercap/{powercap.txt => powercap.rst} | 297 ++++----
.../regulator/{consumer.txt => consumer.rst} | 141 ++--
.../regulator/{design.txt => design.rst} | 9 +-
.../regulator/{machine.txt => machine.rst} | 47 +-
.../regulator/{overview.txt => overview.rst} | 57 +-
.../{regulator.txt => regulator.rst} | 18 +-
.../power/{runtime_pm.txt => runtime_pm.rst} | 234 ++++---
Documentation/power/{s2ram.txt => s2ram.rst} | 20 +-
...hotplug.txt => suspend-and-cpuhotplug.rst} | 42 +-
...errupts.txt => suspend-and-interrupts.rst} | 2 +
...ap-files.txt => swsusp-and-swap-files.rst} | 17 +-
...{swsusp-dmcrypt.txt => swsusp-dmcrypt.rst} | 120 ++--
.../power/{swsusp.txt => swsusp.rst} | 639 ++++++++++--------
.../power/{tricks.txt => tricks.rst} | 6 +-
...serland-swsusp.txt => userland-swsusp.rst} | 55 +-
Documentation/power/{video.txt => video.rst} | 156 +++--
Documentation/process/submitting-drivers.rst | 2 +-
Documentation/scheduler/sched-energy.txt | 6 +-
Documentation/trace/coresight-cpu-debug.txt | 2 +-
.../zh_CN/process/submitting-drivers.rst | 2 +-
MAINTAINERS | 4 +-
arch/x86/Kconfig | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/opp/Kconfig | 2 +-
drivers/power/supply/power_supply_core.c | 2 +-
include/linux/interrupt.h | 2 +-
include/linux/pci.h | 2 +-
include/linux/pm.h | 2 +-
kernel/power/Kconfig | 6 +-
net/wireless/Kconfig | 2 +-
47 files changed, 1730 insertions(+), 1311 deletions(-)
rename Documentation/power/{apm-acpi.txt => apm-acpi.rst} (87%)
rename Documentation/power/{basic-pm-debugging.txt => basic-pm-debugging.rst} (87%)
rename Documentation/power/{charger-manager.txt => charger-manager.rst} (78%)
rename Documentation/power/{drivers-testing.txt => drivers-testing.rst} (86%)
rename Documentation/power/{energy-model.txt => energy-model.rst} (74%)
rename Documentation/power/{freezing-of-tasks.txt => freezing-of-tasks.rst} (75%)
create mode 100644 Documentation/power/index.rst
rename Documentation/power/{interface.txt => interface.rst} (84%)
rename Documentation/power/{opp.txt => opp.rst} (78%)
rename Documentation/power/{pci.txt => pci.rst} (97%)
rename Documentation/power/{pm_qos_interface.txt => pm_qos_interface.rst} (62%)
rename Documentation/power/{power_supply_class.txt => power_supply_class.rst} (46%)
rename Documentation/power/powercap/{powercap.txt => powercap.rst} (40%)
rename Documentation/power/regulator/{consumer.txt => consumer.rst} (61%)
rename Documentation/power/regulator/{design.txt => design.rst} (86%)
rename Documentation/power/regulator/{machine.txt => machine.rst} (75%)
rename Documentation/power/regulator/{overview.txt => overview.rst} (79%)
rename Documentation/power/regulator/{regulator.txt => regulator.rst} (49%)
rename Documentation/power/{runtime_pm.txt => runtime_pm.rst} (89%)
rename Documentation/power/{s2ram.txt => s2ram.rst} (92%)
rename Documentation/power/{suspend-and-cpuhotplug.txt => suspend-and-cpuhotplug.rst} (90%)
rename Documentation/power/{suspend-and-interrupts.txt => suspend-and-interrupts.rst} (98%)
rename Documentation/power/{swsusp-and-swap-files.txt => swsusp-and-swap-files.rst} (83%)
rename Documentation/power/{swsusp-dmcrypt.txt => swsusp-dmcrypt.rst} (67%)
rename Documentation/power/{swsusp.txt => swsusp.rst} (20%)
rename Documentation/power/{tricks.txt => tricks.rst} (93%)
rename Documentation/power/{userland-swsusp.txt => userland-swsusp.rst} (85%)
rename Documentation/power/{video.txt => video.rst} (56%)
diff --git a/Documentation/ABI/testing/sysfs-class-powercap b/Documentation/ABI/testing/sysfs-class-powercap
index db3b3ff70d84..742dfd966592 100644
--- a/Documentation/ABI/testing/sysfs-class-powercap
+++ b/Documentation/ABI/testing/sysfs-class-powercap
@@ -5,7 +5,7 @@ Contact: linux-pm@vger.kernel.org
Description:
The powercap/ class sub directory belongs to the power cap
subsystem. Refer to
- Documentation/power/powercap/powercap.txt for details.
+ Documentation/power/powercap/powercap.rst for details.
What: /sys/class/powercap/<control type>
Date: September 2013
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 9789328f5e9d..df96a896fafa 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -13,7 +13,7 @@
For ARM64, ONLY "acpi=off", "acpi=on" or "acpi=force"
are available
- See also Documentation/power/runtime_pm.txt, pci=noacpi
+ See also Documentation/power/runtime_pm.rst, pci=noacpi
acpi_apic_instance= [ACPI, IOAPIC]
Format: <int>
@@ -223,7 +223,7 @@
acpi_sleep= [HW,ACPI] Sleep options
Format: { s3_bios, s3_mode, s3_beep, s4_nohwsig,
old_ordering, nonvs, sci_force_enable, nobl }
- See Documentation/power/video.txt for information on
+ See Documentation/power/video.rst for information on
s3_bios and s3_mode.
s3_beep is for debugging; it makes the PC's speaker beep
as soon as the kernel's real-mode entry point is called.
@@ -4128,7 +4128,7 @@
Specify the offset from the beginning of the partition
given by "resume=" at which the swap header is located,
in <PAGE_SIZE> units (needed only for swap files).
- See Documentation/power/swsusp-and-swap-files.txt
+ See Documentation/power/swsusp-and-swap-files.rst
resumedelay= [HIBERNATION] Delay (in seconds) to pause before attempting to
read the resume files
diff --git a/Documentation/cpu-freq/core.rst b/Documentation/cpu-freq/core.rst
index c719e3cb700c..003faebd42c2 100644
--- a/Documentation/cpu-freq/core.rst
+++ b/Documentation/cpu-freq/core.rst
@@ -89,7 +89,7 @@ flags flags of the cpufreq driver
3. CPUFreq Table Generation with Operating Performance Point (OPP)
==================================================================
-For details about OPP, see Documentation/power/opp.txt
+For details about OPP, see Documentation/power/opp.rst
dev_pm_opp_init_cpufreq_table
This function provides a ready to use conversion routine to translate
diff --git a/Documentation/driver-api/pm/devices.rst b/Documentation/driver-api/pm/devices.rst
index 30835683616a..f66c7b9126ea 100644
--- a/Documentation/driver-api/pm/devices.rst
+++ b/Documentation/driver-api/pm/devices.rst
@@ -225,7 +225,7 @@ system-wide transition to a sleep state even though its :c:member:`runtime_auto`
flag is clear.
For more information about the runtime power management framework, refer to
-:file:`Documentation/power/runtime_pm.txt`.
+:file:`Documentation/power/runtime_pm.rst`.
Calling Drivers to Enter and Leave System Sleep States
@@ -728,7 +728,7 @@ it into account in any way.
Devices may be defined as IRQ-safe which indicates to the PM core that their
runtime PM callbacks may be invoked with disabled interrupts (see
-:file:`Documentation/power/runtime_pm.txt` for more information). If an
+:file:`Documentation/power/runtime_pm.rst` for more information). If an
IRQ-safe device belongs to a PM domain, the runtime PM of the domain will be
disallowed, unless the domain itself is defined as IRQ-safe. However, it
makes sense to define a PM domain as IRQ-safe only if all the devices in it
@@ -795,7 +795,7 @@ so on) and the final state of the device must reflect the "active" runtime PM
status in that case.
During system-wide resume from a sleep state it's easiest to put devices into
-the full-power state, as explained in :file:`Documentation/power/runtime_pm.txt`.
+the full-power state, as explained in :file:`Documentation/power/runtime_pm.rst`.
[Refer to that document for more information regarding this particular issue as
well as for information on the device runtime power management framework in
general.]
diff --git a/Documentation/driver-api/usb/power-management.rst b/Documentation/driver-api/usb/power-management.rst
index 4a74cf6f2797..2525c3622cae 100644
--- a/Documentation/driver-api/usb/power-management.rst
+++ b/Documentation/driver-api/usb/power-management.rst
@@ -46,7 +46,7 @@ device is turned off while the system as a whole remains running, we
call it a "dynamic suspend" (also known as a "runtime suspend" or
"selective suspend"). This document concentrates mostly on how
dynamic PM is implemented in the USB subsystem, although system PM is
-covered to some extent (see ``Documentation/power/*.txt`` for more
+covered to some extent (see ``Documentation/power/*.rst`` for more
information about system PM).
System PM support is present only if the kernel was built with
diff --git a/Documentation/power/apm-acpi.txt b/Documentation/power/apm-acpi.rst
similarity index 87%
rename from Documentation/power/apm-acpi.txt
rename to Documentation/power/apm-acpi.rst
index 6cc423d3662e..5b90d947126d 100644
--- a/Documentation/power/apm-acpi.txt
+++ b/Documentation/power/apm-acpi.rst
@@ -1,5 +1,7 @@
+============
APM or ACPI?
-------------
+============
+
If you have a relatively recent x86 mobile, desktop, or server system,
odds are it supports either Advanced Power Management (APM) or
Advanced Configuration and Power Interface (ACPI). ACPI is the newer
@@ -28,5 +30,7 @@ and be sure that they are started sometime in the system boot process.
Go ahead and start both. If ACPI or APM is not available on your
system the associated daemon will exit gracefully.
- apmd: http://ftp.debian.org/pool/main/a/apmd/
- acpid: http://acpid.sf.net/
+ ===== =======================================
+ apmd http://ftp.debian.org/pool/main/a/apmd/
+ acpid http://acpid.sf.net/
+ ===== =======================================
diff --git a/Documentation/power/basic-pm-debugging.txt b/Documentation/power/basic-pm-debugging.rst
similarity index 87%
rename from Documentation/power/basic-pm-debugging.txt
rename to Documentation/power/basic-pm-debugging.rst
index 708f87f78a75..69862e759c30 100644
--- a/Documentation/power/basic-pm-debugging.txt
+++ b/Documentation/power/basic-pm-debugging.rst
@@ -1,12 +1,16 @@
+=================================
Debugging hibernation and suspend
+=================================
+
(C) 2007 Rafael J. Wysocki <rjw@sisk.pl>, GPL
1. Testing hibernation (aka suspend to disk or STD)
+===================================================
-To check if hibernation works, you can try to hibernate in the "reboot" mode:
+To check if hibernation works, you can try to hibernate in the "reboot" mode::
-# echo reboot > /sys/power/disk
-# echo disk > /sys/power/state
+ # echo reboot > /sys/power/disk
+ # echo disk > /sys/power/state
and the system should create a hibernation image, reboot, resume and get back to
the command prompt where you have started the transition. If that happens,
@@ -15,20 +19,21 @@ test at least a couple of times in a row for confidence. [This is necessary,
because some problems only show up on a second attempt at suspending and
resuming the system.] Moreover, hibernating in the "reboot" and "shutdown"
modes causes the PM core to skip some platform-related callbacks which on ACPI
-systems might be necessary to make hibernation work. Thus, if your machine fails
-to hibernate or resume in the "reboot" mode, you should try the "platform" mode:
+systems might be necessary to make hibernation work. Thus, if your machine
+fails to hibernate or resume in the "reboot" mode, you should try the
+"platform" mode::
-# echo platform > /sys/power/disk
-# echo disk > /sys/power/state
+ # echo platform > /sys/power/disk
+ # echo disk > /sys/power/state
which is the default and recommended mode of hibernation.
Unfortunately, the "platform" mode of hibernation does not work on some systems
with broken BIOSes. In such cases the "shutdown" mode of hibernation might
-work:
+work::
-# echo shutdown > /sys/power/disk
-# echo disk > /sys/power/state
+ # echo shutdown > /sys/power/disk
+ # echo disk > /sys/power/state
(it is similar to the "reboot" mode, but it requires you to press the power
button to make the system resume).
@@ -37,6 +42,7 @@ If neither "platform" nor "shutdown" hibernation mode works, you will need to
identify what goes wrong.
a) Test modes of hibernation
+----------------------------
To find out why hibernation fails on your system, you can use a special testing
facility available if the kernel is compiled with CONFIG_PM_DEBUG set. Then,
@@ -44,36 +50,38 @@ there is the file /sys/power/pm_test that can be used to make the hibernation
core run in a test mode. There are 5 test modes available:
freezer
-- test the freezing of processes
+ - test the freezing of processes
devices
-- test the freezing of processes and suspending of devices
+ - test the freezing of processes and suspending of devices
platform
-- test the freezing of processes, suspending of devices and platform
- global control methods(*)
+ - test the freezing of processes, suspending of devices and platform
+ global control methods [1]_
processors
-- test the freezing of processes, suspending of devices, platform
- global control methods(*) and the disabling of nonboot CPUs
+ - test the freezing of processes, suspending of devices, platform
+ global control methods [1]_ and the disabling of nonboot CPUs
core
-- test the freezing of processes, suspending of devices, platform global
- control methods(*), the disabling of nonboot CPUs and suspending of
- platform/system devices
+ - test the freezing of processes, suspending of devices, platform global
+ control methods\ [1]_, the disabling of nonboot CPUs and suspending
+ of platform/system devices
-(*) the platform global control methods are only available on ACPI systems
+.. [1]
+
+ the platform global control methods are only available on ACPI systems
and are only tested if the hibernation mode is set to "platform"
To use one of them it is necessary to write the corresponding string to
/sys/power/pm_test (eg. "devices" to test the freezing of processes and
suspending devices) and issue the standard hibernation commands. For example,
to use the "devices" test mode along with the "platform" mode of hibernation,
-you should do the following:
+you should do the following::
-# echo devices > /sys/power/pm_test
-# echo platform > /sys/power/disk
-# echo disk > /sys/power/state
+ # echo devices > /sys/power/pm_test
+ # echo platform > /sys/power/disk
+ # echo disk > /sys/power/state
Then, the kernel will try to freeze processes, suspend devices, wait a few
seconds (5 by default, but configurable by the suspend.pm_test_delay module
@@ -108,11 +116,12 @@ If the "devices" test fails, most likely there is a driver that cannot suspend
or resume its device (in the latter case the system may hang or become unstable
after the test, so please take that into consideration). To find this driver,
you can carry out a binary search according to the rules:
+
- if the test fails, unload a half of the drivers currently loaded and repeat
-(that would probably involve rebooting the system, so always note what drivers
-have been loaded before the test),
+ (that would probably involve rebooting the system, so always note what drivers
+ have been loaded before the test),
- if the test succeeds, load a half of the drivers you have unloaded most
-recently and repeat.
+ recently and repeat.
Once you have found the failing driver (there can be more than just one of
them), you have to unload it every time before hibernation. In that case please
@@ -146,6 +155,7 @@ indicates a serious problem that very well may be related to the hardware, but
please report it anyway.
b) Testing minimal configuration
+--------------------------------
If all of the hibernation test modes work, you can boot the system with the
"init=/bin/bash" command line parameter and attempt to hibernate in the
@@ -165,14 +175,15 @@ Again, if you find the offending module(s), it(they) must be unloaded every time
before hibernation, and please report the problem with it(them).
c) Using the "test_resume" hibernation option
+---------------------------------------------
/sys/power/disk generally tells the kernel what to do after creating a
hibernation image. One of the available options is "test_resume" which
causes the just created image to be used for immediate restoration. Namely,
-after doing:
+after doing::
-# echo test_resume > /sys/power/disk
-# echo disk > /sys/power/state
+ # echo test_resume > /sys/power/disk
+ # echo disk > /sys/power/state
a hibernation image will be created and a resume from it will be triggered
immediately without involving the platform firmware in any way.
@@ -190,6 +201,7 @@ to resume may be related to the differences between the restore and image
kernels.
d) Advanced debugging
+---------------------
In case that hibernation does not work on your system even in the minimal
configuration and compiling more drivers as modules is not practical or some
@@ -200,9 +212,10 @@ kernel messages using the serial console. This may provide you with some
information about the reasons of the suspend (resume) failure. Alternatively,
it may be possible to use a FireWire port for debugging with firescope
(http://v3.sk/~lkundrak/firescope/). On x86 it is also possible to
-use the PM_TRACE mechanism documented in Documentation/power/s2ram.txt .
+use the PM_TRACE mechanism documented in Documentation/power/s2ram.rst .
2. Testing suspend to RAM (STR)
+===============================
To verify that the STR works, it is generally more convenient to use the s2ram
tool available from http://suspend.sf.net and documented at
@@ -230,7 +243,8 @@ you will have to unload them every time before an STR transition (ie. before
you run s2ram), and please report the problems with them.
There is a debugfs entry which shows the suspend to RAM statistics. Here is an
-example of its output.
+example of its output::
+
# mount -t debugfs none /sys/kernel/debug
# cat /sys/kernel/debug/suspend_stats
success: 20
@@ -248,6 +262,7 @@ example of its output.
-16
last_failed_step: suspend
suspend
+
Field success means the success number of suspend to RAM, and field fail means
the failure number. Others are the failure number of different steps of suspend
to RAM. suspend_stats just lists the last 2 failed devices, error number and
diff --git a/Documentation/power/charger-manager.txt b/Documentation/power/charger-manager.rst
similarity index 78%
rename from Documentation/power/charger-manager.txt
rename to Documentation/power/charger-manager.rst
index 9ff1105e58d6..84fab9376792 100644
--- a/Documentation/power/charger-manager.txt
+++ b/Documentation/power/charger-manager.rst
@@ -1,4 +1,7 @@
+===============
Charger Manager
+===============
+
(C) 2011 MyungJoo Ham <myungjoo.ham@samsung.com>, GPL
Charger Manager provides in-kernel battery charger management that
@@ -55,41 +58,39 @@ Charger Manager supports the following:
notification to users with UEVENT.
2. Global Charger-Manager Data related with suspend_again
-========================================================
+=========================================================
In order to setup Charger Manager with suspend-again feature
(in-suspend monitoring), the user should provide charger_global_desc
-with setup_charger_manager(struct charger_global_desc *).
+with setup_charger_manager(`struct charger_global_desc *`).
This charger_global_desc data for in-suspend monitoring is global
as the name suggests. Thus, the user needs to provide only once even
if there are multiple batteries. If there are multiple batteries, the
multiple instances of Charger Manager share the same charger_global_desc
and it will manage in-suspend monitoring for all instances of Charger Manager.
-The user needs to provide all the three entries properly in order to activate
-in-suspend monitoring:
+The user needs to provide all the three entries to `struct charger_global_desc`
+properly in order to activate in-suspend monitoring:
-struct charger_global_desc {
-
-char *rtc_name;
- : The name of rtc (e.g., "rtc0") used to wakeup the system from
+`char *rtc_name;`
+ The name of rtc (e.g., "rtc0") used to wakeup the system from
suspend for Charger Manager. The alarm interrupt (AIE) of the rtc
should be able to wake up the system from suspend. Charger Manager
saves and restores the alarm value and use the previously-defined
alarm if it is going to go off earlier than Charger Manager so that
Charger Manager does not interfere with previously-defined alarms.
-bool (*rtc_only_wakeup)(void);
- : This callback should let CM know whether
+`bool (*rtc_only_wakeup)(void);`
+ This callback should let CM know whether
the wakeup-from-suspend is caused only by the alarm of "rtc" in the
same struct. If there is any other wakeup source triggered the
wakeup, it should return false. If the "rtc" is the only wakeup
reason, it should return true.
-bool assume_timer_stops_in_suspend;
- : if true, Charger Manager assumes that
+`bool assume_timer_stops_in_suspend;`
+ if true, Charger Manager assumes that
the timer (CM uses jiffies as timer) stops during suspend. Then, CM
assumes that the suspend-duration is same as the alarm length.
-};
+
3. How to setup suspend_again
=============================
@@ -109,26 +110,28 @@ if the system was woken up by Charger Manager and the polling
=============================================
For each battery charged independently from other batteries (if a series of
batteries are charged by a single charger, they are counted as one independent
-battery), an instance of Charger Manager is attached to it.
+battery), an instance of Charger Manager is attached to it. The following
-struct charger_desc {
+struct charger_desc elements:
-char *psy_name;
- : The power-supply-class name of the battery. Default is
+`char *psy_name;`
+ The power-supply-class name of the battery. Default is
"battery" if psy_name is NULL. Users can access the psy entries
at "/sys/class/power_supply/[psy_name]/".
-enum polling_modes polling_mode;
- : CM_POLL_DISABLE: do not poll this battery.
- CM_POLL_ALWAYS: always poll this battery.
- CM_POLL_EXTERNAL_POWER_ONLY: poll this battery if and only if
- an external power source is attached.
- CM_POLL_CHARGING_ONLY: poll this battery if and only if the
- battery is being charged.
+`enum polling_modes polling_mode;`
+ CM_POLL_DISABLE:
+ do not poll this battery.
+ CM_POLL_ALWAYS:
+ always poll this battery.
+ CM_POLL_EXTERNAL_POWER_ONLY:
+ poll this battery if and only if an external power
+ source is attached.
+ CM_POLL_CHARGING_ONLY:
+ poll this battery if and only if the battery is being charged.
-unsigned int fullbatt_vchkdrop_ms;
-unsigned int fullbatt_vchkdrop_uV;
- : If both have non-zero values, Charger Manager will check the
+`unsigned int fullbatt_vchkdrop_ms; / unsigned int fullbatt_vchkdrop_uV;`
+ If both have non-zero values, Charger Manager will check the
battery voltage drop fullbatt_vchkdrop_ms after the battery is fully
charged. If the voltage drop is over fullbatt_vchkdrop_uV, Charger
Manager will try to recharge the battery by disabling and enabling
@@ -136,50 +139,52 @@ unsigned int fullbatt_vchkdrop_uV;
condition) is needed to be implemented with hardware interrupts from
fuel gauges or charger devices/chips.
-unsigned int fullbatt_uV;
- : If specified with a non-zero value, Charger Manager assumes
+`unsigned int fullbatt_uV;`
+ If specified with a non-zero value, Charger Manager assumes
that the battery is full (capacity = 100) if the battery is not being
charged and the battery voltage is equal to or greater than
fullbatt_uV.
-unsigned int polling_interval_ms;
- : Required polling interval in ms. Charger Manager will poll
+`unsigned int polling_interval_ms;`
+ Required polling interval in ms. Charger Manager will poll
this battery every polling_interval_ms or more frequently.
-enum data_source battery_present;
- : CM_BATTERY_PRESENT: assume that the battery exists.
- CM_NO_BATTERY: assume that the battery does not exists.
- CM_FUEL_GAUGE: get battery presence information from fuel gauge.
- CM_CHARGER_STAT: get battery presence from chargers.
+`enum data_source battery_present;`
+ CM_BATTERY_PRESENT:
+ assume that the battery exists.
+ CM_NO_BATTERY:
+ assume that the battery does not exists.
+ CM_FUEL_GAUGE:
+ get battery presence information from fuel gauge.
+ CM_CHARGER_STAT:
+ get battery presence from chargers.
-char **psy_charger_stat;
- : An array ending with NULL that has power-supply-class names of
+`char **psy_charger_stat;`
+ An array ending with NULL that has power-supply-class names of
chargers. Each power-supply-class should provide "PRESENT" (if
battery_present is "CM_CHARGER_STAT"), "ONLINE" (shows whether an
external power source is attached or not), and "STATUS" (shows whether
the battery is {"FULL" or not FULL} or {"FULL", "Charging",
"Discharging", "NotCharging"}).
-int num_charger_regulators;
-struct regulator_bulk_data *charger_regulators;
- : Regulators representing the chargers in the form for
+`int num_charger_regulators; / struct regulator_bulk_data *charger_regulators;`
+ Regulators representing the chargers in the form for
regulator framework's bulk functions.
-char *psy_fuel_gauge;
- : Power-supply-class name of the fuel gauge.
+`char *psy_fuel_gauge;`
+ Power-supply-class name of the fuel gauge.
-int (*temperature_out_of_range)(int *mC);
-bool measure_battery_temp;
- : This callback returns 0 if the temperature is safe for charging,
+`int (*temperature_out_of_range)(int *mC); / bool measure_battery_temp;`
+ This callback returns 0 if the temperature is safe for charging,
a positive number if it is too hot to charge, and a negative number
if it is too cold to charge. With the variable mC, the callback returns
the temperature in 1/1000 of centigrade.
The source of temperature can be battery or ambient one according to
the value of measure_battery_temp.
-};
+
5. Notify Charger-Manager of charger events: cm_notify_event()
-=========================================================
+==============================================================
If there is an charger event is required to notify
Charger Manager, a charger device driver that triggers the event can call
cm_notify_event(psy, type, msg) to notify the corresponding Charger Manager.
diff --git a/Documentation/power/drivers-testing.txt b/Documentation/power/drivers-testing.rst
similarity index 86%
rename from Documentation/power/drivers-testing.txt
rename to Documentation/power/drivers-testing.rst
index 638afdf4d6b8..e53f1999fc39 100644
--- a/Documentation/power/drivers-testing.txt
+++ b/Documentation/power/drivers-testing.rst
@@ -1,7 +1,11 @@
+====================================================
Testing suspend and resume support in device drivers
+====================================================
+
(C) 2007 Rafael J. Wysocki <rjw@sisk.pl>, GPL
1. Preparing the test system
+============================
Unfortunately, to effectively test the support for the system-wide suspend and
resume transitions in a driver, it is necessary to suspend and resume a fully
@@ -14,19 +18,20 @@ the machine's BIOS.
Of course, for this purpose the test system has to be known to suspend and
resume without the driver being tested. Thus, if possible, you should first
resolve all suspend/resume-related problems in the test system before you start
-testing the new driver. Please see Documentation/power/basic-pm-debugging.txt
+testing the new driver. Please see Documentation/power/basic-pm-debugging.rst
for more information about the debugging of suspend/resume functionality.
2. Testing the driver
+=====================
Once you have resolved the suspend/resume-related problems with your test system
without the new driver, you are ready to test it:
a) Build the driver as a module, load it and try the test modes of hibernation
- (see: Documentation/power/basic-pm-debugging.txt, 1).
+ (see: Documentation/power/basic-pm-debugging.rst, 1).
b) Load the driver and attempt to hibernate in the "reboot", "shutdown" and
- "platform" modes (see: Documentation/power/basic-pm-debugging.txt, 1).
+ "platform" modes (see: Documentation/power/basic-pm-debugging.rst, 1).
c) Compile the driver directly into the kernel and try the test modes of
hibernation.
@@ -34,12 +39,12 @@ c) Compile the driver directly into the kernel and try the test modes of
d) Attempt to hibernate with the driver compiled directly into the kernel
in the "reboot", "shutdown" and "platform" modes.
-e) Try the test modes of suspend (see: Documentation/power/basic-pm-debugging.txt,
+e) Try the test modes of suspend (see: Documentation/power/basic-pm-debugging.rst,
2). [As far as the STR tests are concerned, it should not matter whether or
not the driver is built as a module.]
f) Attempt to suspend to RAM using the s2ram tool with the driver loaded
- (see: Documentation/power/basic-pm-debugging.txt, 2).
+ (see: Documentation/power/basic-pm-debugging.rst, 2).
Each of the above tests should be repeated several times and the STD tests
should be mixed with the STR tests. If any of them fails, the driver cannot be
diff --git a/Documentation/power/energy-model.txt b/Documentation/power/energy-model.rst
similarity index 74%
rename from Documentation/power/energy-model.txt
rename to Documentation/power/energy-model.rst
index a2b0ae4c76bd..90a345d57ae9 100644
--- a/Documentation/power/energy-model.txt
+++ b/Documentation/power/energy-model.rst
@@ -1,6 +1,6 @@
- ====================
- Energy Model of CPUs
- ====================
+====================
+Energy Model of CPUs
+====================
1. Overview
-----------
@@ -20,7 +20,7 @@ kernel, hence enabling to avoid redundant work.
The figure below depicts an example of drivers (Arm-specific here, but the
approach is applicable to any architecture) providing power costs to the EM
-framework, and interested clients reading the data from it.
+framework, and interested clients reading the data from it::
+---------------+ +-----------------+ +---------------+
| Thermal (IPA) | | Scheduler (EAS) | | Other |
@@ -58,15 +58,17 @@ micro-architectures.
2. Core APIs
------------
- 2.1 Config options
+2.1 Config options
+^^^^^^^^^^^^^^^^^^
CONFIG_ENERGY_MODEL must be enabled to use the EM framework.
- 2.2 Registration of performance domains
+2.2 Registration of performance domains
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Drivers are expected to register performance domains into the EM framework by
-calling the following API:
+calling the following API::
int em_register_perf_domain(cpumask_t *span, unsigned int nr_states,
struct em_data_callback *cb);
@@ -80,7 +82,8 @@ callback, and kernel/power/energy_model.c for further documentation on this
API.
- 2.3 Accessing performance domains
+2.3 Accessing performance domains
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Subsystems interested in the energy model of a CPU can retrieve it using the
em_cpu_get() API. The energy model tables are allocated once upon creation of
@@ -99,46 +102,46 @@ More details about the above APIs can be found in include/linux/energy_model.h.
This section provides a simple example of a CPUFreq driver registering a
performance domain in the Energy Model framework using the (fake) 'foo'
protocol. The driver implements an est_power() function to be provided to the
-EM framework.
+EM framework::
- -> drivers/cpufreq/foo_cpufreq.c
+ -> drivers/cpufreq/foo_cpufreq.c
-01 static int est_power(unsigned long *mW, unsigned long *KHz, int cpu)
-02 {
-03 long freq, power;
-04
-05 /* Use the 'foo' protocol to ceil the frequency */
-06 freq = foo_get_freq_ceil(cpu, *KHz);
-07 if (freq < 0);
-08 return freq;
-09
-10 /* Estimate the power cost for the CPU at the relevant freq. */
-11 power = foo_estimate_power(cpu, freq);
-12 if (power < 0);
-13 return power;
-14
-15 /* Return the values to the EM framework */
-16 *mW = power;
-17 *KHz = freq;
-18
-19 return 0;
-20 }
-21
-22 static int foo_cpufreq_init(struct cpufreq_policy *policy)
-23 {
-24 struct em_data_callback em_cb = EM_DATA_CB(est_power);
-25 int nr_opp, ret;
-26
-27 /* Do the actual CPUFreq init work ... */
-28 ret = do_foo_cpufreq_init(policy);
-29 if (ret)
-30 return ret;
-31
-32 /* Find the number of OPPs for this policy */
-33 nr_opp = foo_get_nr_opp(policy);
-34
-35 /* And register the new performance domain */
-36 em_register_perf_domain(policy->cpus, nr_opp, &em_cb);
-37
-38 return 0;
-39 }
+ 01 static int est_power(unsigned long *mW, unsigned long *KHz, int cpu)
+ 02 {
+ 03 long freq, power;
+ 04
+ 05 /* Use the 'foo' protocol to ceil the frequency */
+ 06 freq = foo_get_freq_ceil(cpu, *KHz);
+ 07 if (freq < 0);
+ 08 return freq;
+ 09
+ 10 /* Estimate the power cost for the CPU at the relevant freq. */
+ 11 power = foo_estimate_power(cpu, freq);
+ 12 if (power < 0);
+ 13 return power;
+ 14
+ 15 /* Return the values to the EM framework */
+ 16 *mW = power;
+ 17 *KHz = freq;
+ 18
+ 19 return 0;
+ 20 }
+ 21
+ 22 static int foo_cpufreq_init(struct cpufreq_policy *policy)
+ 23 {
+ 24 struct em_data_callback em_cb = EM_DATA_CB(est_power);
+ 25 int nr_opp, ret;
+ 26
+ 27 /* Do the actual CPUFreq init work ... */
+ 28 ret = do_foo_cpufreq_init(policy);
+ 29 if (ret)
+ 30 return ret;
+ 31
+ 32 /* Find the number of OPPs for this policy */
+ 33 nr_opp = foo_get_nr_opp(policy);
+ 34
+ 35 /* And register the new performance domain */
+ 36 em_register_perf_domain(policy->cpus, nr_opp, &em_cb);
+ 37
+ 38 return 0;
+ 39 }
diff --git a/Documentation/power/freezing-of-tasks.txt b/Documentation/power/freezing-of-tasks.rst
similarity index 75%
rename from Documentation/power/freezing-of-tasks.txt
rename to Documentation/power/freezing-of-tasks.rst
index cd283190855a..ef110fe55e82 100644
--- a/Documentation/power/freezing-of-tasks.txt
+++ b/Documentation/power/freezing-of-tasks.rst
@@ -1,13 +1,18 @@
+=================
Freezing of tasks
- (C) 2007 Rafael J. Wysocki <rjw@sisk.pl>, GPL
+=================
+
+(C) 2007 Rafael J. Wysocki <rjw@sisk.pl>, GPL
I. What is the freezing of tasks?
+=================================
The freezing of tasks is a mechanism by which user space processes and some
kernel threads are controlled during hibernation or system-wide suspend (on some
architectures).
II. How does it work?
+=====================
There are three per-task flags used for that, PF_NOFREEZE, PF_FROZEN
and PF_FREEZER_SKIP (the last one is auxiliary). The tasks that have
@@ -41,7 +46,7 @@ explicitly in suitable places or use the wait_event_freezable() or
wait_event_freezable_timeout() macros (defined in include/linux/freezer.h)
that combine interruptible sleep with checking if the task is to be frozen and
calling try_to_freeze(). The main loop of a freezable kernel thread may look
-like the following one:
+like the following one::
set_freezable();
do {
@@ -65,7 +70,7 @@ order to clear the PF_FROZEN flag for each frozen task. Then, the tasks that
have been frozen leave __refrigerator() and continue running.
-Rationale behind the functions dealing with freezing and thawing of tasks:
+Rationale behind the functions dealing with freezing and thawing of tasks
-------------------------------------------------------------------------
freeze_processes():
@@ -86,6 +91,7 @@ thaw_processes():
III. Which kernel threads are freezable?
+========================================
Kernel threads are not freezable by default. However, a kernel thread may clear
PF_NOFREEZE for itself by calling set_freezable() (the resetting of PF_NOFREEZE
@@ -93,37 +99,39 @@ directly is not allowed). From this point it is regarded as freezable
and must call try_to_freeze() in a suitable place.
IV. Why do we do that?
+======================
Generally speaking, there is a couple of reasons to use the freezing of tasks:
1. The principal reason is to prevent filesystems from being damaged after
-hibernation. At the moment we have no simple means of checkpointing
-filesystems, so if there are any modifications made to filesystem data and/or
-metadata on disks, we cannot bring them back to the state from before the
-modifications. At the same time each hibernation image contains some
-filesystem-related information that must be consistent with the state of the
-on-disk data and metadata after the system memory state has been restored from
-the image (otherwise the filesystems will be damaged in a nasty way, usually
-making them almost impossible to repair). We therefore freeze tasks that might
-cause the on-disk filesystems' data and metadata to be modified after the
-hibernation image has been created and before the system is finally powered off.
-The majority of these are user space processes, but if any of the kernel threads
-may cause something like this to happen, they have to be freezable.
+ hibernation. At the moment we have no simple means of checkpointing
+ filesystems, so if there are any modifications made to filesystem data and/or
+ metadata on disks, we cannot bring them back to the state from before the
+ modifications. At the same time each hibernation image contains some
+ filesystem-related information that must be consistent with the state of the
+ on-disk data and metadata after the system memory state has been restored
+ from the image (otherwise the filesystems will be damaged in a nasty way,
+ usually making them almost impossible to repair). We therefore freeze
+ tasks that might cause the on-disk filesystems' data and metadata to be
+ modified after the hibernation image has been created and before the
+ system is finally powered off. The majority of these are user space
+ processes, but if any of the kernel threads may cause something like this
+ to happen, they have to be freezable.
2. Next, to create the hibernation image we need to free a sufficient amount of
-memory (approximately 50% of available RAM) and we need to do that before
-devices are deactivated, because we generally need them for swapping out. Then,
-after the memory for the image has been freed, we don't want tasks to allocate
-additional memory and we prevent them from doing that by freezing them earlier.
-[Of course, this also means that device drivers should not allocate substantial
-amounts of memory from their .suspend() callbacks before hibernation, but this
-is a separate issue.]
+ memory (approximately 50% of available RAM) and we need to do that before
+ devices are deactivated, because we generally need them for swapping out.
+ Then, after the memory for the image has been freed, we don't want tasks
+ to allocate additional memory and we prevent them from doing that by
+ freezing them earlier. [Of course, this also means that device drivers
+ should not allocate substantial amounts of memory from their .suspend()
+ callbacks before hibernation, but this is a separate issue.]
3. The third reason is to prevent user space processes and some kernel threads
-from interfering with the suspending and resuming of devices. A user space
-process running on a second CPU while we are suspending devices may, for
-example, be troublesome and without the freezing of tasks we would need some
-safeguards against race conditions that might occur in such a case.
+ from interfering with the suspending and resuming of devices. A user space
+ process running on a second CPU while we are suspending devices may, for
+ example, be troublesome and without the freezing of tasks we would need some
+ safeguards against race conditions that might occur in such a case.
Although Linus Torvalds doesn't like the freezing of tasks, he said this in one
of the discussions on LKML (http://lkml.org/lkml/2007/4/27/608):
@@ -132,7 +140,7 @@ of the discussions on LKML (http://lkml.org/lkml/2007/4/27/608):
Linus: In many ways, 'at all'.
-I _do_ realize the IO request queue issues, and that we cannot actually do
+I **do** realize the IO request queue issues, and that we cannot actually do
s2ram with some devices in the middle of a DMA. So we want to be able to
avoid *that*, there's no question about that. And I suspect that stopping
user threads and then waiting for a sync is practically one of the easier
@@ -150,17 +158,18 @@ thawed after the driver's .resume() callback has run, so it won't be accessing
the device while it's suspended.
4. Another reason for freezing tasks is to prevent user space processes from
-realizing that hibernation (or suspend) operation takes place. Ideally, user
-space processes should not notice that such a system-wide operation has occurred
-and should continue running without any problems after the restore (or resume
-from suspend). Unfortunately, in the most general case this is quite difficult
-to achieve without the freezing of tasks. Consider, for example, a process
-that depends on all CPUs being online while it's running. Since we need to
-disable nonboot CPUs during the hibernation, if this process is not frozen, it
-may notice that the number of CPUs has changed and may start to work incorrectly
-because of that.
+ realizing that hibernation (or suspend) operation takes place. Ideally, user
+ space processes should not notice that such a system-wide operation has
+ occurred and should continue running without any problems after the restore
+ (or resume from suspend). Unfortunately, in the most general case this
+ is quite difficult to achieve without the freezing of tasks. Consider,
+ for example, a process that depends on all CPUs being online while it's
+ running. Since we need to disable nonboot CPUs during the hibernation,
+ if this process is not frozen, it may notice that the number of CPUs has
+ changed and may start to work incorrectly because of that.
V. Are there any problems related to the freezing of tasks?
+===========================================================
Yes, there are.
@@ -172,11 +181,12 @@ may be undesirable. That's why kernel threads are not freezable by default.
Second, there are the following two problems related to the freezing of user
space processes:
+
1. Putting processes into an uninterruptible sleep distorts the load average.
2. Now that we have FUSE, plus the framework for doing device drivers in
-userspace, it gets even more complicated because some userspace processes are
-now doing the sorts of things that kernel threads do
-(https://lists.linux-foundation.org/pipermail/linux-pm/2007-May/012309.html).
+ userspace, it gets even more complicated because some userspace processes are
+ now doing the sorts of things that kernel threads do
+ (https://lists.linux-foundation.org/pipermail/linux-pm/2007-May/012309.html).
The problem 1. seems to be fixable, although it hasn't been fixed so far. The
other one is more serious, but it seems that we can work around it by using
@@ -201,6 +211,7 @@ requested early enough using the suspend notifier API described in
Documentation/driver-api/pm/notifiers.rst.
VI. Are there any precautions to be taken to prevent freezing failures?
+=======================================================================
Yes, there are.
@@ -226,6 +237,8 @@ So, to summarize, use [un]lock_system_sleep() instead of directly using
mutex_[un]lock(&system_transition_mutex). That would prevent freezing failures.
V. Miscellaneous
+================
+
/sys/power/pm_freeze_timeout controls how long it will cost at most to freeze
all user space processes or all freezable kernel threads, in unit of millisecond.
The default value is 20000, with range of unsigned integer.
diff --git a/Documentation/power/index.rst b/Documentation/power/index.rst
new file mode 100644
index 000000000000..20415f21e48a
--- /dev/null
+++ b/Documentation/power/index.rst
@@ -0,0 +1,46 @@
+:orphan:
+
+================
+Power Management
+================
+
+.. toctree::
+ :maxdepth: 1
+
+ apm-acpi
+ basic-pm-debugging
+ charger-manager
+ drivers-testing
+ energy-model
+ freezing-of-tasks
+ interface
+ opp
+ pci
+ pm_qos_interface
+ power_supply_class
+ runtime_pm
+ s2ram
+ suspend-and-cpuhotplug
+ suspend-and-interrupts
+ swsusp-and-swap-files
+ swsusp-dmcrypt
+ swsusp
+ video
+ tricks
+
+ userland-swsusp
+
+ powercap/powercap
+
+ regulator/consumer
+ regulator/design
+ regulator/machine
+ regulator/overview
+ regulator/regulator
+
+.. only:: subproject and html
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/power/interface.txt b/Documentation/power/interface.rst
similarity index 84%
rename from Documentation/power/interface.txt
rename to Documentation/power/interface.rst
index 27df7f98668a..8d270ed27228 100644
--- a/Documentation/power/interface.txt
+++ b/Documentation/power/interface.rst
@@ -1,4 +1,6 @@
+===========================================
Power Management Interface for System Sleep
+===========================================
Copyright (c) 2016 Intel Corp., Rafael J. Wysocki <rafael.j.wysocki@intel.com>
@@ -11,10 +13,10 @@ mounted at /sys).
Reading from it returns a list of supported sleep states, encoded as:
-'freeze' (Suspend-to-Idle)
-'standby' (Power-On Suspend)
-'mem' (Suspend-to-RAM)
-'disk' (Suspend-to-Disk)
+- 'freeze' (Suspend-to-Idle)
+- 'standby' (Power-On Suspend)
+- 'mem' (Suspend-to-RAM)
+- 'disk' (Suspend-to-Disk)
Suspend-to-Idle is always supported. Suspend-to-Disk is always supported
too as long the kernel has been configured to support hibernation at all
@@ -32,18 +34,18 @@ Specifically, it tells the kernel what to do after creating a hibernation image.
Reading from it returns a list of supported options encoded as:
-'platform' (put the system into sleep using a platform-provided method)
-'shutdown' (shut the system down)
-'reboot' (reboot the system)
-'suspend' (trigger a Suspend-to-RAM transition)
-'test_resume' (resume-after-hibernation test mode)
+- 'platform' (put the system into sleep using a platform-provided method)
+- 'shutdown' (shut the system down)
+- 'reboot' (reboot the system)
+- 'suspend' (trigger a Suspend-to-RAM transition)
+- 'test_resume' (resume-after-hibernation test mode)
The currently selected option is printed in square brackets.
The 'platform' option is only available if the platform provides a special
mechanism to put the system to sleep after creating a hibernation image (ACPI
does that, for example). The 'suspend' option is available if Suspend-to-RAM
-is supported. Refer to Documentation/power/basic-pm-debugging.txt for the
+is supported. Refer to Documentation/power/basic-pm-debugging.rst for the
description of the 'test_resume' option.
To select an option, write the string representing it to /sys/power/disk.
@@ -71,7 +73,7 @@ If /sys/power/pm_trace contains '1', the fingerprint of each suspend/resume
event point in turn will be stored in the RTC memory (overwriting the actual
RTC information), so it will survive a system crash if one occurs right after
storing it and it can be used later to identify the driver that caused the crash
-to happen (see Documentation/power/s2ram.txt for more information).
+to happen (see Documentation/power/s2ram.rst for more information).
Initially it contains '0' which may be changed to '1' by writing a string
representing a nonzero integer into it.
diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.rst
similarity index 78%
rename from Documentation/power/opp.txt
rename to Documentation/power/opp.rst
index 0c007e250cd1..b3cf1def9dee 100644
--- a/Documentation/power/opp.txt
+++ b/Documentation/power/opp.rst
@@ -1,20 +1,23 @@
+==========================================
Operating Performance Points (OPP) Library
==========================================
(C) 2009-2010 Nishanth Menon <nm@ti.com>, Texas Instruments Incorporated
-Contents
---------
-1. Introduction
-2. Initial OPP List Registration
-3. OPP Search Functions
-4. OPP Availability Control Functions
-5. OPP Data Retrieval Functions
-6. Data Structures
+.. Contents
+
+ 1. Introduction
+ 2. Initial OPP List Registration
+ 3. OPP Search Functions
+ 4. OPP Availability Control Functions
+ 5. OPP Data Retrieval Functions
+ 6. Data Structures
1. Introduction
===============
+
1.1 What is an Operating Performance Point (OPP)?
+-------------------------------------------------
Complex SoCs of today consists of a multiple sub-modules working in conjunction.
In an operational system executing varied use cases, not all modules in the SoC
@@ -28,16 +31,19 @@ the device will support per domain are called Operating Performance Points or
OPPs.
As an example:
+
Let us consider an MPU device which supports the following:
{300MHz at minimum voltage of 1V}, {800MHz at minimum voltage of 1.2V},
{1GHz at minimum voltage of 1.3V}
We can represent these as three OPPs as the following {Hz, uV} tuples:
-{300000000, 1000000}
-{800000000, 1200000}
-{1000000000, 1300000}
+
+- {300000000, 1000000}
+- {800000000, 1200000}
+- {1000000000, 1300000}
1.2 Operating Performance Points Library
+----------------------------------------
OPP library provides a set of helper functions to organize and query the OPP
information. The library is located in drivers/base/power/opp.c and the header
@@ -46,9 +52,10 @@ CONFIG_PM_OPP from power management menuconfig menu. OPP library depends on
CONFIG_PM as certain SoCs such as Texas Instrument's OMAP framework allows to
optionally boot at a certain OPP without needing cpufreq.
-Typical usage of the OPP library is as follows:
-(users) -> registers a set of default OPPs -> (library)
-SoC framework -> modifies on required cases certain OPPs -> OPP layer
+Typical usage of the OPP library is as follows::
+
+ (users) -> registers a set of default OPPs -> (library)
+ SoC framework -> modifies on required cases certain OPPs -> OPP layer
-> queries to search/retrieve information ->
OPP layer expects each domain to be represented by a unique device pointer. SoC
@@ -57,8 +64,9 @@ list is expected to be an optimally small number typically around 5 per device.
This initial list contains a set of OPPs that the framework expects to be safely
enabled by default in the system.
-Note on OPP Availability:
-------------------------
+Note on OPP Availability
+^^^^^^^^^^^^^^^^^^^^^^^^
+
As the system proceeds to operate, SoC framework may choose to make certain
OPPs available or not available on each device based on various external
factors. Example usage: Thermal management or other exceptional situations where
@@ -88,7 +96,8 @@ registering the OPPs is maintained by OPP library throughout the device
operation. The SoC framework can subsequently control the availability of the
OPPs dynamically using the dev_pm_opp_enable / disable functions.
-dev_pm_opp_add - Add a new OPP for a specific domain represented by the device pointer.
+dev_pm_opp_add
+ Add a new OPP for a specific domain represented by the device pointer.
The OPP is defined using the frequency and voltage. Once added, the OPP
is assumed to be available and control of it's availability can be done
with the dev_pm_opp_enable/disable functions. OPP library internally stores
@@ -96,9 +105,11 @@ dev_pm_opp_add - Add a new OPP for a specific domain represented by the device p
used by SoC framework to define a optimal list as per the demands of
SoC usage environment.
- WARNING: Do not use this function in interrupt context.
+ WARNING:
+ Do not use this function in interrupt context.
+
+ Example::
- Example:
soc_pm_init()
{
/* Do things */
@@ -125,12 +136,15 @@ Callers of these functions shall call dev_pm_opp_put() after they have used the
OPP. Otherwise the memory for the OPP will never get freed and result in
memleak.
-dev_pm_opp_find_freq_exact - Search for an OPP based on an *exact* frequency and
+dev_pm_opp_find_freq_exact
+ Search for an OPP based on an *exact* frequency and
availability. This function is especially useful to enable an OPP which
is not available by default.
Example: In a case when SoC framework detects a situation where a
higher frequency could be made available, it can use this function to
- find the OPP prior to call the dev_pm_opp_enable to actually make it available.
+ find the OPP prior to call the dev_pm_opp_enable to actually make
+ it available::
+
opp = dev_pm_opp_find_freq_exact(dev, 1000000000, false);
dev_pm_opp_put(opp);
/* dont operate on the pointer.. just do a sanity check.. */
@@ -141,27 +155,34 @@ dev_pm_opp_find_freq_exact - Search for an OPP based on an *exact* frequency and
dev_pm_opp_enable(dev,1000000000);
}
- NOTE: This is the only search function that operates on OPPs which are
- not available.
+ NOTE:
+ This is the only search function that operates on OPPs which are
+ not available.
-dev_pm_opp_find_freq_floor - Search for an available OPP which is *at most* the
+dev_pm_opp_find_freq_floor
+ Search for an available OPP which is *at most* the
provided frequency. This function is useful while searching for a lesser
match OR operating on OPP information in the order of decreasing
frequency.
- Example: To find the highest opp for a device:
+ Example: To find the highest opp for a device::
+
freq = ULONG_MAX;
opp = dev_pm_opp_find_freq_floor(dev, &freq);
dev_pm_opp_put(opp);
-dev_pm_opp_find_freq_ceil - Search for an available OPP which is *at least* the
+dev_pm_opp_find_freq_ceil
+ Search for an available OPP which is *at least* the
provided frequency. This function is useful while searching for a
higher match OR operating on OPP information in the order of increasing
frequency.
- Example 1: To find the lowest opp for a device:
+ Example 1: To find the lowest opp for a device::
+
freq = 0;
opp = dev_pm_opp_find_freq_ceil(dev, &freq);
dev_pm_opp_put(opp);
- Example 2: A simplified implementation of a SoC cpufreq_driver->target:
+
+ Example 2: A simplified implementation of a SoC cpufreq_driver->target::
+
soc_cpufreq_target(..)
{
/* Do stuff like policy checks etc. */
@@ -184,12 +205,15 @@ fine grained dynamic control of which sets of OPPs are operationally available.
These functions are intended to *temporarily* remove an OPP in conditions such
as thermal considerations (e.g. don't use OPPx until the temperature drops).
-WARNING: Do not use these functions in interrupt context.
+WARNING:
+ Do not use these functions in interrupt context.
-dev_pm_opp_enable - Make a OPP available for operation.
+dev_pm_opp_enable
+ Make a OPP available for operation.
Example: Lets say that 1GHz OPP is to be made available only if the
SoC temperature is lower than a certain threshold. The SoC framework
- implementation might choose to do something as follows:
+ implementation might choose to do something as follows::
+
if (cur_temp < temp_low_thresh) {
/* Enable 1GHz if it was disabled */
opp = dev_pm_opp_find_freq_exact(dev, 1000000000, false);
@@ -201,10 +225,12 @@ dev_pm_opp_enable - Make a OPP available for operation.
goto try_something_else;
}
-dev_pm_opp_disable - Make an OPP to be not available for operation
+dev_pm_opp_disable
+ Make an OPP to be not available for operation
Example: Lets say that 1GHz OPP is to be disabled if the temperature
exceeds a threshold value. The SoC framework implementation might
- choose to do something as follows:
+ choose to do something as follows::
+
if (cur_temp > temp_high_thresh) {
/* Disable 1GHz if it was enabled */
opp = dev_pm_opp_find_freq_exact(dev, 1000000000, true);
@@ -223,11 +249,13 @@ information from the OPP structure is necessary. Once an OPP pointer is
retrieved using the search functions, the following functions can be used by SoC
framework to retrieve the information represented inside the OPP layer.
-dev_pm_opp_get_voltage - Retrieve the voltage represented by the opp pointer.
+dev_pm_opp_get_voltage
+ Retrieve the voltage represented by the opp pointer.
Example: At a cpufreq transition to a different frequency, SoC
framework requires to set the voltage represented by the OPP using
the regulator framework to the Power Management chip providing the
- voltage.
+ voltage::
+
soc_switch_to_freq_voltage(freq)
{
/* do things */
@@ -239,10 +267,12 @@ dev_pm_opp_get_voltage - Retrieve the voltage represented by the opp pointer.
/* do other things */
}
-dev_pm_opp_get_freq - Retrieve the freq represented by the opp pointer.
+dev_pm_opp_get_freq
+ Retrieve the freq represented by the opp pointer.
Example: Lets say the SoC framework uses a couple of helper functions
we could pass opp pointers instead of doing additional parameters to
- handle quiet a bit of data parameters.
+ handle quiet a bit of data parameters::
+
soc_cpufreq_target(..)
{
/* do things.. */
@@ -264,9 +294,11 @@ dev_pm_opp_get_freq - Retrieve the freq represented by the opp pointer.
/* do things.. */
}
-dev_pm_opp_get_opp_count - Retrieve the number of available opps for a device
+dev_pm_opp_get_opp_count
+ Retrieve the number of available opps for a device
Example: Lets say a co-processor in the SoC needs to know the available
- frequencies in a table, the main processor can notify as following:
+ frequencies in a table, the main processor can notify as following::
+
soc_notify_coproc_available_frequencies()
{
/* Do things */
@@ -289,54 +321,59 @@ dev_pm_opp_get_opp_count - Retrieve the number of available opps for a device
==================
Typically an SoC contains multiple voltage domains which are variable. Each
domain is represented by a device pointer. The relationship to OPP can be
-represented as follows:
-SoC
- |- device 1
- | |- opp 1 (availability, freq, voltage)
- | |- opp 2 ..
- ... ...
- | `- opp n ..
- |- device 2
- ...
- `- device m
+represented as follows::
+
+ SoC
+ |- device 1
+ | |- opp 1 (availability, freq, voltage)
+ | |- opp 2 ..
+ ... ...
+ | `- opp n ..
+ |- device 2
+ ...
+ `- device m
OPP library maintains a internal list that the SoC framework populates and
accessed by various functions as described above. However, the structures
representing the actual OPPs and domains are internal to the OPP library itself
to allow for suitable abstraction reusable across systems.
-struct dev_pm_opp - The internal data structure of OPP library which is used to
+struct dev_pm_opp
+ The internal data structure of OPP library which is used to
represent an OPP. In addition to the freq, voltage, availability
information, it also contains internal book keeping information required
for the OPP library to operate on. Pointer to this structure is
provided back to the users such as SoC framework to be used as a
identifier for OPP in the interactions with OPP layer.
- WARNING: The struct dev_pm_opp pointer should not be parsed or modified by the
- users. The defaults of for an instance is populated by dev_pm_opp_add, but the
- availability of the OPP can be modified by dev_pm_opp_enable/disable functions.
+ WARNING:
+ The struct dev_pm_opp pointer should not be parsed or modified by the
+ users. The defaults of for an instance is populated by
+ dev_pm_opp_add, but the availability of the OPP can be modified
+ by dev_pm_opp_enable/disable functions.
-struct device - This is used to identify a domain to the OPP layer. The
+struct device
+ This is used to identify a domain to the OPP layer. The
nature of the device and it's implementation is left to the user of
OPP library such as the SoC framework.
Overall, in a simplistic view, the data structure operations is represented as
-following:
+following::
-Initialization / modification:
- +-----+ /- dev_pm_opp_enable
-dev_pm_opp_add --> | opp | <-------
- | +-----+ \- dev_pm_opp_disable
- \-------> domain_info(device)
+ Initialization / modification:
+ +-----+ /- dev_pm_opp_enable
+ dev_pm_opp_add --> | opp | <-------
+ | +-----+ \- dev_pm_opp_disable
+ \-------> domain_info(device)
-Search functions:
- /-- dev_pm_opp_find_freq_ceil ---\ +-----+
-domain_info<---- dev_pm_opp_find_freq_exact -----> | opp |
- \-- dev_pm_opp_find_freq_floor ---/ +-----+
+ Search functions:
+ /-- dev_pm_opp_find_freq_ceil ---\ +-----+
+ domain_info<---- dev_pm_opp_find_freq_exact -----> | opp |
+ \-- dev_pm_opp_find_freq_floor ---/ +-----+
-Retrieval functions:
-+-----+ /- dev_pm_opp_get_voltage
-| opp | <---
-+-----+ \- dev_pm_opp_get_freq
+ Retrieval functions:
+ +-----+ /- dev_pm_opp_get_voltage
+ | opp | <---
+ +-----+ \- dev_pm_opp_get_freq
-domain_info <- dev_pm_opp_get_opp_count
+ domain_info <- dev_pm_opp_get_opp_count
diff --git a/Documentation/power/pci.txt b/Documentation/power/pci.rst
similarity index 97%
rename from Documentation/power/pci.txt
rename to Documentation/power/pci.rst
index 8eaf9ee24d43..0e2ef7429304 100644
--- a/Documentation/power/pci.txt
+++ b/Documentation/power/pci.rst
@@ -1,4 +1,6 @@
+====================
PCI Power Management
+====================
Copyright (c) 2010 Rafael J. Wysocki <rjw@sisk.pl>, Novell Inc.
@@ -9,14 +11,14 @@ management. Based on previous work by Patrick Mochel <mochel@transmeta.com>
This document only covers the aspects of power management specific to PCI
devices. For general description of the kernel's interfaces related to device
power management refer to Documentation/driver-api/pm/devices.rst and
-Documentation/power/runtime_pm.txt.
+Documentation/power/runtime_pm.rst.
----------------------------------------------------------------------------
+.. contents:
-1. Hardware and Platform Support for PCI Power Management
-2. PCI Subsystem and Device Power Management
-3. PCI Device Drivers and Power Management
-4. Resources
+ 1. Hardware and Platform Support for PCI Power Management
+ 2. PCI Subsystem and Device Power Management
+ 3. PCI Device Drivers and Power Management
+ 4. Resources
1. Hardware and Platform Support for PCI Power Management
@@ -24,6 +26,7 @@ Documentation/power/runtime_pm.txt.
1.1. Native and Platform-Based Power Management
-----------------------------------------------
+
In general, power management is a feature allowing one to save energy by putting
devices into states in which they draw less power (low-power states) at the
price of reduced functionality or performance.
@@ -67,6 +70,7 @@ mechanisms have to be used simultaneously to obtain the desired result.
1.2. Native PCI Power Management
--------------------------------
+
The PCI Bus Power Management Interface Specification (PCI PM Spec) was
introduced between the PCI 2.1 and PCI 2.2 Specifications. It defined a
standard interface for performing various operations related to power
@@ -134,6 +138,7 @@ sufficiently active to generate a wakeup signal.
1.3. ACPI Device Power Management
---------------------------------
+
The platform firmware support for the power management of PCI devices is
system-specific. However, if the system in question is compliant with the
Advanced Configuration and Power Interface (ACPI) Specification, like the
@@ -194,6 +199,7 @@ enabled for the device to be able to generate wakeup signals.
1.4. Wakeup Signaling
---------------------
+
Wakeup signals generated by PCI devices, either as native PCI PMEs, or as
a result of the execution of the _DSW (or _PSW) ACPI control method before
putting the device into a low-power state, have to be caught and handled as
@@ -265,14 +271,15 @@ the native PCI Express PME signaling cannot be used by the kernel in that case.
2.1. Device Power Management Callbacks
--------------------------------------
+
The PCI Subsystem participates in the power management of PCI devices in a
number of ways. First of all, it provides an intermediate code layer between
the device power management core (PM core) and PCI device drivers.
Specifically, the pm field of the PCI subsystem's struct bus_type object,
pci_bus_type, points to a struct dev_pm_ops object, pci_dev_pm_ops, containing
-pointers to several device power management callbacks:
+pointers to several device power management callbacks::
-const struct dev_pm_ops pci_dev_pm_ops = {
+ const struct dev_pm_ops pci_dev_pm_ops = {
.prepare = pci_pm_prepare,
.complete = pci_pm_complete,
.suspend = pci_pm_suspend,
@@ -290,7 +297,7 @@ const struct dev_pm_ops pci_dev_pm_ops = {
.runtime_suspend = pci_pm_runtime_suspend,
.runtime_resume = pci_pm_runtime_resume,
.runtime_idle = pci_pm_runtime_idle,
-};
+ };
These callbacks are executed by the PM core in various situations related to
device power management and they, in turn, execute power management callbacks
@@ -299,9 +306,9 @@ involving some standard configuration registers of PCI devices that device
drivers need not know or care about.
The structure representing a PCI device, struct pci_dev, contains several fields
-that these callbacks operate on:
+that these callbacks operate on::
-struct pci_dev {
+ struct pci_dev {
...
pci_power_t current_state; /* Current operating state. */
int pm_cap; /* PM capability offset in the
@@ -315,13 +322,14 @@ struct pci_dev {
unsigned int wakeup_prepared:1; /* Device prepared for wake up */
unsigned int d3_delay; /* D3->D0 transition time in ms */
...
-};
+ };
They also indirectly use some fields of the struct device that is embedded in
struct pci_dev.
2.2. Device Initialization
--------------------------
+
The PCI subsystem's first task related to device power management is to
prepare the device for power management and initialize the fields of struct
pci_dev used for this purpose. This happens in two functions defined in
@@ -348,10 +356,11 @@ during system-wide transitions to a sleep state and back to the working state.
2.3. Runtime Device Power Management
------------------------------------
+
The PCI subsystem plays a vital role in the runtime power management of PCI
devices. For this purpose it uses the general runtime power management
-(runtime PM) framework described in Documentation/power/runtime_pm.txt.
-Namely, it provides subsystem-level callbacks:
+(runtime PM) framework described in Documentation/power/runtime_pm.rst.
+Namely, it provides subsystem-level callbacks::
pci_pm_runtime_suspend()
pci_pm_runtime_resume()
@@ -425,13 +434,14 @@ to the given subsystem before the next phase begins. These phases always run
after tasks have been frozen.
2.4.1. System Suspend
+^^^^^^^^^^^^^^^^^^^^^
When the system is going into a sleep state in which the contents of memory will
be preserved, such as one of the ACPI sleep states S1-S3, the phases are:
prepare, suspend, suspend_noirq.
-The following PCI bus type's callbacks, respectively, are used in these phases:
+The following PCI bus type's callbacks, respectively, are used in these phases::
pci_pm_prepare()
pci_pm_suspend()
@@ -492,6 +502,7 @@ this purpose). PCI device drivers are not encouraged to do that, but in some
rare cases doing that in the driver may be the optimum approach.
2.4.2. System Resume
+^^^^^^^^^^^^^^^^^^^^
When the system is undergoing a transition from a sleep state in which the
contents of memory have been preserved, such as one of the ACPI sleep states
@@ -500,7 +511,7 @@ S1-S3, into the working state (ACPI S0), the phases are:
resume_noirq, resume, complete.
The following PCI bus type's callbacks, respectively, are executed in these
-phases:
+phases::
pci_pm_resume_noirq()
pci_pm_resume()
@@ -539,6 +550,7 @@ The pci_pm_complete() routine only executes the device driver's pm->complete()
callback, if defined.
2.4.3. System Hibernation
+^^^^^^^^^^^^^^^^^^^^^^^^^
System hibernation is more complicated than system suspend, because it requires
a system image to be created and written into a persistent storage medium. The
@@ -551,7 +563,7 @@ to be free) in the following three phases:
prepare, freeze, freeze_noirq
-that correspond to the PCI bus type's callbacks:
+that correspond to the PCI bus type's callbacks::
pci_pm_prepare()
pci_pm_freeze()
@@ -580,7 +592,7 @@ back to the fully functional state and this is done in the following phases:
thaw_noirq, thaw, complete
-using the following PCI bus type's callbacks:
+using the following PCI bus type's callbacks::
pci_pm_thaw_noirq()
pci_pm_thaw()
@@ -608,7 +620,7 @@ three phases:
where the prepare phase is exactly the same as for system suspend. The other
two phases are analogous to the suspend and suspend_noirq phases, respectively.
-The PCI subsystem-level callbacks they correspond to
+The PCI subsystem-level callbacks they correspond to::
pci_pm_poweroff()
pci_pm_poweroff_noirq()
@@ -618,6 +630,7 @@ although they don't attempt to save the device's standard configuration
registers.
2.4.4. System Restore
+^^^^^^^^^^^^^^^^^^^^^
System restore requires a hibernation image to be loaded into memory and the
pre-hibernation memory contents to be restored before the pre-hibernation system
@@ -653,7 +666,7 @@ phases:
The first two of these are analogous to the resume_noirq and resume phases
described above, respectively, and correspond to the following PCI subsystem
-callbacks:
+callbacks::
pci_pm_restore_noirq()
pci_pm_restore()
@@ -671,6 +684,7 @@ resume.
3.1. Power Management Callbacks
-------------------------------
+
PCI device drivers participate in power management by providing callbacks to be
executed by the PCI subsystem's power management routines described above and by
controlling the runtime power management of their devices.
@@ -698,6 +712,7 @@ defined, though, they are expected to behave as described in the following
subsections.
3.1.1. prepare()
+^^^^^^^^^^^^^^^^
The prepare() callback is executed during system suspend, during hibernation
(when a hibernation image is about to be created), during power-off after
@@ -716,6 +731,7 @@ preallocated earlier, for example in a suspend/hibernate notifier as described
in Documentation/driver-api/pm/notifiers.rst).
3.1.2. suspend()
+^^^^^^^^^^^^^^^^
The suspend() callback is only executed during system suspend, after prepare()
callbacks have been executed for all devices in the system.
@@ -742,6 +758,7 @@ operations relying on the driver's ability to handle interrupts should be
carried out in this callback.
3.1.3. suspend_noirq()
+^^^^^^^^^^^^^^^^^^^^^^
The suspend_noirq() callback is only executed during system suspend, after
suspend() callbacks have been executed for all devices in the system and
@@ -753,6 +770,7 @@ suspend_noirq() can carry out operations that would cause race conditions to
arise if they were performed in suspend().
3.1.4. freeze()
+^^^^^^^^^^^^^^^
The freeze() callback is hibernation-specific and is executed in two situations,
during hibernation, after prepare() callbacks have been executed for all devices
@@ -770,6 +788,7 @@ or put it into a low-power state. Still, either it or freeze_noirq() should
save the device's standard configuration registers using pci_save_state().
3.1.5. freeze_noirq()
+^^^^^^^^^^^^^^^^^^^^^
The freeze_noirq() callback is hibernation-specific. It is executed during
hibernation, after prepare() and freeze() callbacks have been executed for all
@@ -786,6 +805,7 @@ The difference between freeze_noirq() and freeze() is analogous to the
difference between suspend_noirq() and suspend().
3.1.6. poweroff()
+^^^^^^^^^^^^^^^^^
The poweroff() callback is hibernation-specific. It is executed when the system
is about to be powered off after saving a hibernation image to a persistent
@@ -802,6 +822,7 @@ into a low-power state, respectively, but it need not save the device's standard
configuration registers.
3.1.7. poweroff_noirq()
+^^^^^^^^^^^^^^^^^^^^^^^
The poweroff_noirq() callback is hibernation-specific. It is executed after
poweroff() callbacks have been executed for all devices in the system.
@@ -814,6 +835,7 @@ The difference between poweroff_noirq() and poweroff() is analogous to the
difference between suspend_noirq() and suspend().
3.1.8. resume_noirq()
+^^^^^^^^^^^^^^^^^^^^^
The resume_noirq() callback is only executed during system resume, after the
PM core has enabled the non-boot CPUs. The driver's interrupt handler will not
@@ -827,6 +849,7 @@ it should only be used for performing operations that would lead to race
conditions if carried out by resume().
3.1.9. resume()
+^^^^^^^^^^^^^^^
The resume() callback is only executed during system resume, after
resume_noirq() callbacks have been executed for all devices in the system and
@@ -837,6 +860,7 @@ device and bringing it back to the fully functional state. The device should be
able to process I/O in a usual way after resume() has returned.
3.1.10. thaw_noirq()
+^^^^^^^^^^^^^^^^^^^^
The thaw_noirq() callback is hibernation-specific. It is executed after a
system image has been created and the non-boot CPUs have been enabled by the PM
@@ -851,6 +875,7 @@ freeze() and freeze_noirq(), so in general it does not need to modify the
contents of the device's registers.
3.1.11. thaw()
+^^^^^^^^^^^^^^
The thaw() callback is hibernation-specific. It is executed after thaw_noirq()
callbacks have been executed for all devices in the system and after device
@@ -860,6 +885,7 @@ This callback is responsible for restoring the pre-freeze configuration of
the device, so that it will work in a usual way after thaw() has returned.
3.1.12. restore_noirq()
+^^^^^^^^^^^^^^^^^^^^^^^
The restore_noirq() callback is hibernation-specific. It is executed in the
restore_noirq phase of hibernation, when the boot kernel has passed control to
@@ -875,6 +901,7 @@ For the vast majority of PCI device drivers there is no difference between
resume_noirq() and restore_noirq().
3.1.13. restore()
+^^^^^^^^^^^^^^^^^
The restore() callback is hibernation-specific. It is executed after
restore_noirq() callbacks have been executed for all devices in the system and
@@ -888,14 +915,17 @@ For the vast majority of PCI device drivers there is no difference between
resume() and restore().
3.1.14. complete()
+^^^^^^^^^^^^^^^^^^
The complete() callback is executed in the following situations:
+
- during system resume, after resume() callbacks have been executed for all
devices,
- during hibernation, before saving the system image, after thaw() callbacks
have been executed for all devices,
- during system restore, when the system is going back to its pre-hibernation
state, after restore() callbacks have been executed for all devices.
+
It also may be executed if the loading of a hibernation image into memory fails
(in that case it is run after thaw() callbacks have been executed for all
devices that have drivers in the boot kernel).
@@ -904,6 +934,7 @@ This callback is entirely optional, although it may be necessary if the
prepare() callback performs operations that need to be reversed.
3.1.15. runtime_suspend()
+^^^^^^^^^^^^^^^^^^^^^^^^^
The runtime_suspend() callback is specific to device runtime power management
(runtime PM). It is executed by the PM core's runtime PM framework when the
@@ -915,6 +946,7 @@ put into a low-power state, but it must allow the PCI subsystem to perform all
of the PCI-specific actions necessary for suspending the device.
3.1.16. runtime_resume()
+^^^^^^^^^^^^^^^^^^^^^^^^
The runtime_resume() callback is specific to device runtime PM. It is executed
by the PM core's runtime PM framework when the device is about to be resumed
@@ -927,6 +959,7 @@ The device is expected to be able to process I/O in the usual way after
runtime_resume() has returned.
3.1.17. runtime_idle()
+^^^^^^^^^^^^^^^^^^^^^^
The runtime_idle() callback is specific to device runtime PM. It is executed
by the PM core's runtime PM framework whenever it may be desirable to suspend
@@ -939,6 +972,7 @@ PCI subsystem will call pm_runtime_suspend() for the device, which in turn will
cause the driver's runtime_suspend() callback to be executed.
3.1.18. Pointing Multiple Callback Pointers to One Routine
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Although in principle each of the callbacks described in the previous
subsections can be defined as a separate function, it often is convenient to
@@ -962,6 +996,7 @@ dev_pm_ops to indicate that one suspend routine is to be pointed to by the
be pointed to by the .resume(), .thaw(), and .restore() members.
3.1.19. Driver Flags for Power Management
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The PM core allows device drivers to set flags that influence the handling of
power management for the devices by the core itself and by middle layer code
@@ -1007,6 +1042,7 @@ it.
3.2. Device Runtime Power Management
------------------------------------
+
In addition to providing device power management callbacks PCI device drivers
are responsible for controlling the runtime power management (runtime PM) of
their devices.
@@ -1073,22 +1109,27 @@ device the PM core automatically queues a request to check if the device is
idle), device drivers are generally responsible for queuing power management
requests for their devices. For this purpose they should use the runtime PM
helper functions provided by the PM core, discussed in
-Documentation/power/runtime_pm.txt.
+Documentation/power/runtime_pm.rst.
Devices can also be suspended and resumed synchronously, without placing a
request into pm_wq. In the majority of cases this also is done by their
drivers that use helper functions provided by the PM core for this purpose.
For more information on the runtime PM of devices refer to
-Documentation/power/runtime_pm.txt.
+Documentation/power/runtime_pm.rst.
4. Resources
============
PCI Local Bus Specification, Rev. 3.0
+
PCI Bus Power Management Interface Specification, Rev. 1.2
+
Advanced Configuration and Power Interface (ACPI) Specification, Rev. 3.0b
+
PCI Express Base Specification, Rev. 2.0
+
Documentation/driver-api/pm/devices.rst
-Documentation/power/runtime_pm.txt
+
+Documentation/power/runtime_pm.rst
diff --git a/Documentation/power/pm_qos_interface.txt b/Documentation/power/pm_qos_interface.rst
similarity index 62%
rename from Documentation/power/pm_qos_interface.txt
rename to Documentation/power/pm_qos_interface.rst
index 19c5f7b1a7ba..945fc6d760c9 100644
--- a/Documentation/power/pm_qos_interface.txt
+++ b/Documentation/power/pm_qos_interface.rst
@@ -1,4 +1,6 @@
-PM Quality Of Service Interface.
+===============================
+PM Quality Of Service Interface
+===============================
This interface provides a kernel and user mode interface for registering
performance expectations by drivers, subsystems and user space applications on
@@ -11,6 +13,7 @@ memory_bandwidth.
constraints and PM QoS flags.
Each parameters have defined units:
+
* latency: usec
* timeout: usec
* throughput: kbs (kilo bit / sec)
@@ -18,6 +21,7 @@ Each parameters have defined units:
1. PM QoS framework
+===================
The infrastructure exposes multiple misc device nodes one per implemented
parameter. The set of parameters implement is defined by pm_qos_power_init()
@@ -37,38 +41,39 @@ reading the aggregated value does not require any locking mechanism.
From kernel mode the use of this interface is simple:
void pm_qos_add_request(handle, param_class, target_value):
-Will insert an element into the list for that identified PM QoS class with the
-target value. Upon change to this list the new target is recomputed and any
-registered notifiers are called only if the target value is now different.
-Clients of pm_qos need to save the returned handle for future use in other
-pm_qos API functions.
+ Will insert an element into the list for that identified PM QoS class with the
+ target value. Upon change to this list the new target is recomputed and any
+ registered notifiers are called only if the target value is now different.
+ Clients of pm_qos need to save the returned handle for future use in other
+ pm_qos API functions.
void pm_qos_update_request(handle, new_target_value):
-Will update the list element pointed to by the handle with the new target value
-and recompute the new aggregated target, calling the notification tree if the
-target is changed.
+ Will update the list element pointed to by the handle with the new target value
+ and recompute the new aggregated target, calling the notification tree if the
+ target is changed.
void pm_qos_remove_request(handle):
-Will remove the element. After removal it will update the aggregate target and
-call the notification tree if the target was changed as a result of removing
-the request.
+ Will remove the element. After removal it will update the aggregate target and
+ call the notification tree if the target was changed as a result of removing
+ the request.
int pm_qos_request(param_class):
-Returns the aggregated value for a given PM QoS class.
+ Returns the aggregated value for a given PM QoS class.
int pm_qos_request_active(handle):
-Returns if the request is still active, i.e. it has not been removed from a
-PM QoS class constraints list.
+ Returns if the request is still active, i.e. it has not been removed from a
+ PM QoS class constraints list.
int pm_qos_add_notifier(param_class, notifier):
-Adds a notification callback function to the PM QoS class. The callback is
-called when the aggregated value for the PM QoS class is changed.
+ Adds a notification callback function to the PM QoS class. The callback is
+ called when the aggregated value for the PM QoS class is changed.
int pm_qos_remove_notifier(int param_class, notifier):
-Removes the notification callback function for the PM QoS class.
+ Removes the notification callback function for the PM QoS class.
From user mode:
+
Only processes can register a pm_qos request. To provide for automatic
cleanup of a process, the interface requires the process to register its
parameter requests in the following way:
@@ -89,6 +94,7 @@ node.
2. PM QoS per-device latency and flags framework
+================================================
For each device, there are three lists of PM QoS requests. Two of them are
maintained along with the aggregated targets of resume latency and active
@@ -107,73 +113,80 @@ the aggregated value does not require any locking mechanism.
From kernel mode the use of this interface is the following:
int dev_pm_qos_add_request(device, handle, type, value):
-Will insert an element into the list for that identified device with the
-target value. Upon change to this list the new target is recomputed and any
-registered notifiers are called only if the target value is now different.
-Clients of dev_pm_qos need to save the handle for future use in other
-dev_pm_qos API functions.
+ Will insert an element into the list for that identified device with the
+ target value. Upon change to this list the new target is recomputed and any
+ registered notifiers are called only if the target value is now different.
+ Clients of dev_pm_qos need to save the handle for future use in other
+ dev_pm_qos API functions.
int dev_pm_qos_update_request(handle, new_value):
-Will update the list element pointed to by the handle with the new target value
-and recompute the new aggregated target, calling the notification trees if the
-target is changed.
+ Will update the list element pointed to by the handle with the new target
+ value and recompute the new aggregated target, calling the notification
+ trees if the target is changed.
int dev_pm_qos_remove_request(handle):
-Will remove the element. After removal it will update the aggregate target and
-call the notification trees if the target was changed as a result of removing
-the request.
+ Will remove the element. After removal it will update the aggregate target
+ and call the notification trees if the target was changed as a result of
+ removing the request.
s32 dev_pm_qos_read_value(device):
-Returns the aggregated value for a given device's constraints list.
+ Returns the aggregated value for a given device's constraints list.
enum pm_qos_flags_status dev_pm_qos_flags(device, mask)
-Check PM QoS flags of the given device against the given mask of flags.
-The meaning of the return values is as follows:
- PM_QOS_FLAGS_ALL: All flags from the mask are set
- PM_QOS_FLAGS_SOME: Some flags from the mask are set
- PM_QOS_FLAGS_NONE: No flags from the mask are set
- PM_QOS_FLAGS_UNDEFINED: The device's PM QoS structure has not been
- initialized or the list of requests is empty.
+ Check PM QoS flags of the given device against the given mask of flags.
+ The meaning of the return values is as follows:
+
+ PM_QOS_FLAGS_ALL:
+ All flags from the mask are set
+ PM_QOS_FLAGS_SOME:
+ Some flags from the mask are set
+ PM_QOS_FLAGS_NONE:
+ No flags from the mask are set
+ PM_QOS_FLAGS_UNDEFINED:
+ The device's PM QoS structure has not been initialized
+ or the list of requests is empty.
int dev_pm_qos_add_ancestor_request(dev, handle, type, value)
-Add a PM QoS request for the first direct ancestor of the given device whose
-power.ignore_children flag is unset (for DEV_PM_QOS_RESUME_LATENCY requests)
-or whose power.set_latency_tolerance callback pointer is not NULL (for
-DEV_PM_QOS_LATENCY_TOLERANCE requests).
+ Add a PM QoS request for the first direct ancestor of the given device whose
+ power.ignore_children flag is unset (for DEV_PM_QOS_RESUME_LATENCY requests)
+ or whose power.set_latency_tolerance callback pointer is not NULL (for
+ DEV_PM_QOS_LATENCY_TOLERANCE requests).
int dev_pm_qos_expose_latency_limit(device, value)
-Add a request to the device's PM QoS list of resume latency constraints and
-create a sysfs attribute pm_qos_resume_latency_us under the device's power
-directory allowing user space to manipulate that request.
+ Add a request to the device's PM QoS list of resume latency constraints and
+ create a sysfs attribute pm_qos_resume_latency_us under the device's power
+ directory allowing user space to manipulate that request.
void dev_pm_qos_hide_latency_limit(device)
-Drop the request added by dev_pm_qos_expose_latency_limit() from the device's
-PM QoS list of resume latency constraints and remove sysfs attribute
-pm_qos_resume_latency_us from the device's power directory.
+ Drop the request added by dev_pm_qos_expose_latency_limit() from the device's
+ PM QoS list of resume latency constraints and remove sysfs attribute
+ pm_qos_resume_latency_us from the device's power directory.
int dev_pm_qos_expose_flags(device, value)
-Add a request to the device's PM QoS list of flags and create sysfs attribute
-pm_qos_no_power_off under the device's power directory allowing user space to
-change the value of the PM_QOS_FLAG_NO_POWER_OFF flag.
+ Add a request to the device's PM QoS list of flags and create sysfs attribute
+ pm_qos_no_power_off under the device's power directory allowing user space to
+ change the value of the PM_QOS_FLAG_NO_POWER_OFF flag.
void dev_pm_qos_hide_flags(device)
-Drop the request added by dev_pm_qos_expose_flags() from the device's PM QoS list
-of flags and remove sysfs attribute pm_qos_no_power_off from the device's power
-directory.
+ Drop the request added by dev_pm_qos_expose_flags() from the device's PM QoS list
+ of flags and remove sysfs attribute pm_qos_no_power_off from the device's power
+ directory.
Notification mechanisms:
+
The per-device PM QoS framework has a per-device notification tree.
int dev_pm_qos_add_notifier(device, notifier):
-Adds a notification callback function for the device.
-The callback is called when the aggregated value of the device constraints list
-is changed (for resume latency device PM QoS only).
+ Adds a notification callback function for the device.
+ The callback is called when the aggregated value of the device constraints list
+ is changed (for resume latency device PM QoS only).
int dev_pm_qos_remove_notifier(device, notifier):
-Removes the notification callback function for the device.
+ Removes the notification callback function for the device.
Active state latency tolerance
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This device PM QoS type is used to support systems in which hardware may switch
to energy-saving operation modes on the fly. In those systems, if the operation
diff --git a/Documentation/power/power_supply_class.txt b/Documentation/power/power_supply_class.rst
similarity index 46%
rename from Documentation/power/power_supply_class.txt
rename to Documentation/power/power_supply_class.rst
index 300d37896e51..3f2c3fe38a61 100644
--- a/Documentation/power/power_supply_class.txt
+++ b/Documentation/power/power_supply_class.rst
@@ -1,3 +1,4 @@
+========================
Linux power supply class
========================
@@ -56,112 +57,155 @@ Quoting include/linux/power_supply.h:
Attributes/properties detailed
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-~ ~ ~ ~ ~ ~ ~ Charge/Energy/Capacity - how to not confuse ~ ~ ~ ~ ~ ~ ~
-~ ~
-~ Because both "charge" (µAh) and "energy" (µWh) represents "capacity" ~
-~ of battery, this class distinguish these terms. Don't mix them! ~
-~ ~
-~ CHARGE_* attributes represents capacity in µAh only. ~
-~ ENERGY_* attributes represents capacity in µWh only. ~
-~ CAPACITY attribute represents capacity in *percents*, from 0 to 100. ~
-~ ~
-~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
++--------------------------------------------------------------------------+
+| **Charge/Energy/Capacity - how to not confuse** |
++--------------------------------------------------------------------------+
+| **Because both "charge" (µAh) and "energy" (µWh) represents "capacity" |
+| of battery, this class distinguish these terms. Don't mix them!** |
+| |
+| - `CHARGE_*` |
+| attributes represents capacity in µAh only. |
+| - `ENERGY_*` |
+| attributes represents capacity in µWh only. |
+| - `CAPACITY` |
+| attribute represents capacity in *percents*, from 0 to 100. |
++--------------------------------------------------------------------------+
Postfixes:
-_AVG - *hardware* averaged value, use it if your hardware is really able to
-report averaged values.
-_NOW - momentary/instantaneous values.
-STATUS - this attribute represents operating status (charging, full,
-discharging (i.e. powering a load), etc.). This corresponds to
-BATTERY_STATUS_* values, as defined in battery.h.
-
-CHARGE_TYPE - batteries can typically charge at different rates.
-This defines trickle and fast charges. For batteries that
-are already charged or discharging, 'n/a' can be displayed (or
-'unknown', if the status is not known).
-
-AUTHENTIC - indicates the power supply (battery or charger) connected
-to the platform is authentic(1) or non authentic(0).
-
-HEALTH - represents health of the battery, values corresponds to
-POWER_SUPPLY_HEALTH_*, defined in battery.h.
-
-VOLTAGE_OCV - open circuit voltage of the battery.
-
-VOLTAGE_MAX_DESIGN, VOLTAGE_MIN_DESIGN - design values for maximal and
-minimal power supply voltages. Maximal/minimal means values of voltages
-when battery considered "full"/"empty" at normal conditions. Yes, there is
-no direct relation between voltage and battery capacity, but some dumb
-batteries use voltage for very approximated calculation of capacity.
-Battery driver also can use this attribute just to inform userspace
-about maximal and minimal voltage thresholds of a given battery.
-
-VOLTAGE_MAX, VOLTAGE_MIN - same as _DESIGN voltage values except that
-these ones should be used if hardware could only guess (measure and
-retain) the thresholds of a given power supply.
-
-VOLTAGE_BOOT - Reports the voltage measured during boot
-
-CURRENT_BOOT - Reports the current measured during boot
-
-CHARGE_FULL_DESIGN, CHARGE_EMPTY_DESIGN - design charge values, when
-battery considered full/empty.
-
-ENERGY_FULL_DESIGN, ENERGY_EMPTY_DESIGN - same as above but for energy.
-
-CHARGE_FULL, CHARGE_EMPTY - These attributes means "last remembered value
-of charge when battery became full/empty". It also could mean "value of
-charge when battery considered full/empty at given conditions (temperature,
-age)". I.e. these attributes represents real thresholds, not design values.
-
-ENERGY_FULL, ENERGY_EMPTY - same as above but for energy.
-
-CHARGE_COUNTER - the current charge counter (in µAh). This could easily
-be negative; there is no empty or full value. It is only useful for
-relative, time-based measurements.
-
-PRECHARGE_CURRENT - the maximum charge current during precharge phase
-of charge cycle (typically 20% of battery capacity).
-CHARGE_TERM_CURRENT - Charge termination current. The charge cycle
-terminates when battery voltage is above recharge threshold, and charge
-current is below this setting (typically 10% of battery capacity).
-
-CONSTANT_CHARGE_CURRENT - constant charge current programmed by charger.
-CONSTANT_CHARGE_CURRENT_MAX - maximum charge current supported by the
-power supply object.
-
-CONSTANT_CHARGE_VOLTAGE - constant charge voltage programmed by charger.
-CONSTANT_CHARGE_VOLTAGE_MAX - maximum charge voltage supported by the
-power supply object.
-
-INPUT_CURRENT_LIMIT - input current limit programmed by charger. Indicates
-the current drawn from a charging source.
-
-CHARGE_CONTROL_LIMIT - current charge control limit setting
-CHARGE_CONTROL_LIMIT_MAX - maximum charge control limit setting
-
-CALIBRATE - battery or coulomb counter calibration status
-
-CAPACITY - capacity in percents.
-CAPACITY_ALERT_MIN - minimum capacity alert value in percents.
-CAPACITY_ALERT_MAX - maximum capacity alert value in percents.
-CAPACITY_LEVEL - capacity level. This corresponds to
-POWER_SUPPLY_CAPACITY_LEVEL_*.
-
-TEMP - temperature of the power supply.
-TEMP_ALERT_MIN - minimum battery temperature alert.
-TEMP_ALERT_MAX - maximum battery temperature alert.
-TEMP_AMBIENT - ambient temperature.
-TEMP_AMBIENT_ALERT_MIN - minimum ambient temperature alert.
-TEMP_AMBIENT_ALERT_MAX - maximum ambient temperature alert.
-TEMP_MIN - minimum operatable temperature
-TEMP_MAX - maximum operatable temperature
-
-TIME_TO_EMPTY - seconds left for battery to be considered empty (i.e.
-while battery powers a load)
-TIME_TO_FULL - seconds left for battery to be considered full (i.e.
-while battery is charging)
+_AVG
+ *hardware* averaged value, use it if your hardware is really able to
+ report averaged values.
+_NOW
+ momentary/instantaneous values.
+
+STATUS
+ this attribute represents operating status (charging, full,
+ discharging (i.e. powering a load), etc.). This corresponds to
+ `BATTERY_STATUS_*` values, as defined in battery.h.
+
+CHARGE_TYPE
+ batteries can typically charge at different rates.
+ This defines trickle and fast charges. For batteries that
+ are already charged or discharging, 'n/a' can be displayed (or
+ 'unknown', if the status is not known).
+
+AUTHENTIC
+ indicates the power supply (battery or charger) connected
+ to the platform is authentic(1) or non authentic(0).
+
+HEALTH
+ represents health of the battery, values corresponds to
+ POWER_SUPPLY_HEALTH_*, defined in battery.h.
+
+VOLTAGE_OCV
+ open circuit voltage of the battery.
+
+VOLTAGE_MAX_DESIGN, VOLTAGE_MIN_DESIGN
+ design values for maximal and minimal power supply voltages.
+ Maximal/minimal means values of voltages when battery considered
+ "full"/"empty" at normal conditions. Yes, there is no direct relation
+ between voltage and battery capacity, but some dumb
+ batteries use voltage for very approximated calculation of capacity.
+ Battery driver also can use this attribute just to inform userspace
+ about maximal and minimal voltage thresholds of a given battery.
+
+VOLTAGE_MAX, VOLTAGE_MIN
+ same as _DESIGN voltage values except that these ones should be used
+ if hardware could only guess (measure and retain) the thresholds of a
+ given power supply.
+
+VOLTAGE_BOOT
+ Reports the voltage measured during boot
+
+CURRENT_BOOT
+ Reports the current measured during boot
+
+CHARGE_FULL_DESIGN, CHARGE_EMPTY_DESIGN
+ design charge values, when battery considered full/empty.
+
+ENERGY_FULL_DESIGN, ENERGY_EMPTY_DESIGN
+ same as above but for energy.
+
+CHARGE_FULL, CHARGE_EMPTY
+ These attributes means "last remembered value of charge when battery
+ became full/empty". It also could mean "value of charge when battery
+ considered full/empty at given conditions (temperature, age)".
+ I.e. these attributes represents real thresholds, not design values.
+
+ENERGY_FULL, ENERGY_EMPTY
+ same as above but for energy.
+
+CHARGE_COUNTER
+ the current charge counter (in µAh). This could easily
+ be negative; there is no empty or full value. It is only useful for
+ relative, time-based measurements.
+
+PRECHARGE_CURRENT
+ the maximum charge current during precharge phase of charge cycle
+ (typically 20% of battery capacity).
+
+CHARGE_TERM_CURRENT
+ Charge termination current. The charge cycle terminates when battery
+ voltage is above recharge threshold, and charge current is below
+ this setting (typically 10% of battery capacity).
+
+CONSTANT_CHARGE_CURRENT
+ constant charge current programmed by charger.
+
+
+CONSTANT_CHARGE_CURRENT_MAX
+ maximum charge current supported by the power supply object.
+
+CONSTANT_CHARGE_VOLTAGE
+ constant charge voltage programmed by charger.
+CONSTANT_CHARGE_VOLTAGE_MAX
+ maximum charge voltage supported by the power supply object.
+
+INPUT_CURRENT_LIMIT
+ input current limit programmed by charger. Indicates
+ the current drawn from a charging source.
+
+CHARGE_CONTROL_LIMIT
+ current charge control limit setting
+CHARGE_CONTROL_LIMIT_MAX
+ maximum charge control limit setting
+
+CALIBRATE
+ battery or coulomb counter calibration status
+
+CAPACITY
+ capacity in percents.
+CAPACITY_ALERT_MIN
+ minimum capacity alert value in percents.
+CAPACITY_ALERT_MAX
+ maximum capacity alert value in percents.
+CAPACITY_LEVEL
+ capacity level. This corresponds to POWER_SUPPLY_CAPACITY_LEVEL_*.
+
+TEMP
+ temperature of the power supply.
+TEMP_ALERT_MIN
+ minimum battery temperature alert.
+TEMP_ALERT_MAX
+ maximum battery temperature alert.
+TEMP_AMBIENT
+ ambient temperature.
+TEMP_AMBIENT_ALERT_MIN
+ minimum ambient temperature alert.
+TEMP_AMBIENT_ALERT_MAX
+ maximum ambient temperature alert.
+TEMP_MIN
+ minimum operatable temperature
+TEMP_MAX
+ maximum operatable temperature
+
+TIME_TO_EMPTY
+ seconds left for battery to be considered empty
+ (i.e. while battery powers a load)
+TIME_TO_FULL
+ seconds left for battery to be considered full
+ (i.e. while battery is charging)
Battery <-> external power supply interaction
@@ -193,8 +237,11 @@ for naming consistency between sysfs attributes and battery node properties.
QA
~~
-Q: Where is POWER_SUPPLY_PROP_XYZ attribute?
-A: If you cannot find attribute suitable for your driver needs, feel free
+
+Q:
+ Where is POWER_SUPPLY_PROP_XYZ attribute?
+A:
+ If you cannot find attribute suitable for your driver needs, feel free
to add it and send patch along with your driver.
The attributes available currently are the ones currently provided by the
@@ -204,20 +251,24 @@ A: If you cannot find attribute suitable for your driver needs, feel free
etc.
-Q: I have some very specific attribute (e.g. battery color), should I add
+Q:
+ I have some very specific attribute (e.g. battery color), should I add
this attribute to standard ones?
-A: Most likely, no. Such attribute can be placed in the driver itself, if
+A:
+ Most likely, no. Such attribute can be placed in the driver itself, if
it is useful. Of course, if the attribute in question applicable to
large set of batteries, provided by many drivers, and/or comes from
some general battery specification/standard, it may be a candidate to
be added to the core attribute set.
-Q: Suppose, my battery monitoring chip/firmware does not provides capacity
+Q:
+ Suppose, my battery monitoring chip/firmware does not provides capacity
in percents, but provides charge_{now,full,empty}. Should I calculate
percentage capacity manually, inside the driver, and register CAPACITY
attribute? The same question about time_to_empty/time_to_full.
-A: Most likely, no. This class is designed to export properties which are
+A:
+ Most likely, no. This class is designed to export properties which are
directly measurable by the specific hardware available.
Inferring not available properties using some heuristics or mathematical
diff --git a/Documentation/power/powercap/powercap.txt b/Documentation/power/powercap/powercap.rst
similarity index 40%
rename from Documentation/power/powercap/powercap.txt
rename to Documentation/power/powercap/powercap.rst
index 1e6ef164e07a..7ae3b44c7624 100644
--- a/Documentation/power/powercap/powercap.txt
+++ b/Documentation/power/powercap/powercap.rst
@@ -1,12 +1,14 @@
+=======================
Power Capping Framework
-==================================
+=======================
The power capping framework provides a consistent interface between the kernel
and the user space that allows power capping drivers to expose the settings to
user space in a uniform way.
Terminology
-=========================
+===========
+
The framework exposes power capping devices to user space via sysfs in the
form of a tree of objects. The objects at the root level of the tree represent
'control types', which correspond to different methods of power capping. For
@@ -27,121 +29,121 @@ capping to a set of devices together using the parent power zone and if more
fine grained control is required, it can be applied through the subzones.
-Example sysfs interface tree:
+Example sysfs interface tree::
-/sys/devices/virtual/powercap
-??? intel-rapl
- ??? intel-rapl:0
- ? ??? constraint_0_name
- ? ??? constraint_0_power_limit_uw
- ? ??? constraint_0_time_window_us
- ? ??? constraint_1_name
- ? ??? constraint_1_power_limit_uw
- ? ??? constraint_1_time_window_us
- ? ??? device -> ../../intel-rapl
- ? ??? energy_uj
- ? ??? intel-rapl:0:0
- ? ? ??? constraint_0_name
- ? ? ??? constraint_0_power_limit_uw
- ? ? ??? constraint_0_time_window_us
- ? ? ??? constraint_1_name
- ? ? ??? constraint_1_power_limit_uw
- ? ? ??? constraint_1_time_window_us
- ? ? ??? device -> ../../intel-rapl:0
- ? ? ??? energy_uj
- ? ? ??? max_energy_range_uj
- ? ? ??? name
- ? ? ??? enabled
- ? ? ??? power
- ? ? ? ??? async
- ? ? ? []
- ? ? ??? subsystem -> ../../../../../../class/power_cap
- ? ? ??? uevent
- ? ??? intel-rapl:0:1
- ? ? ??? constraint_0_name
- ? ? ??? constraint_0_power_limit_uw
- ? ? ??? constraint_0_time_window_us
- ? ? ??? constraint_1_name
- ? ? ??? constraint_1_power_limit_uw
- ? ? ??? constraint_1_time_window_us
- ? ? ??? device -> ../../intel-rapl:0
- ? ? ??? energy_uj
- ? ? ??? max_energy_range_uj
- ? ? ??? name
- ? ? ??? enabled
- ? ? ??? power
- ? ? ? ??? async
- ? ? ? []
- ? ? ??? subsystem -> ../../../../../../class/power_cap
- ? ? ??? uevent
- ? ??? max_energy_range_uj
- ? ??? max_power_range_uw
- ? ??? name
- ? ??? enabled
- ? ??? power
- ? ? ??? async
- ? ? []
- ? ??? subsystem -> ../../../../../class/power_cap
- ? ??? enabled
- ? ??? uevent
- ??? intel-rapl:1
- ? ??? constraint_0_name
- ? ??? constraint_0_power_limit_uw
- ? ??? constraint_0_time_window_us
- ? ??? constraint_1_name
- ? ??? constraint_1_power_limit_uw
- ? ??? constraint_1_time_window_us
- ? ??? device -> ../../intel-rapl
- ? ??? energy_uj
- ? ??? intel-rapl:1:0
- ? ? ??? constraint_0_name
- ? ? ??? constraint_0_power_limit_uw
- ? ? ??? constraint_0_time_window_us
- ? ? ??? constraint_1_name
- ? ? ??? constraint_1_power_limit_uw
- ? ? ??? constraint_1_time_window_us
- ? ? ??? device -> ../../intel-rapl:1
- ? ? ??? energy_uj
- ? ? ??? max_energy_range_uj
- ? ? ??? name
- ? ? ??? enabled
- ? ? ??? power
- ? ? ? ??? async
- ? ? ? []
- ? ? ??? subsystem -> ../../../../../../class/power_cap
- ? ? ??? uevent
- ? ??? intel-rapl:1:1
- ? ? ??? constraint_0_name
- ? ? ??? constraint_0_power_limit_uw
- ? ? ??? constraint_0_time_window_us
- ? ? ??? constraint_1_name
- ? ? ??? constraint_1_power_limit_uw
- ? ? ??? constraint_1_time_window_us
- ? ? ??? device -> ../../intel-rapl:1
- ? ? ??? energy_uj
- ? ? ??? max_energy_range_uj
- ? ? ??? name
- ? ? ??? enabled
- ? ? ??? power
- ? ? ? ??? async
- ? ? ? []
- ? ? ??? subsystem -> ../../../../../../class/power_cap
- ? ? ??? uevent
- ? ??? max_energy_range_uj
- ? ??? max_power_range_uw
- ? ??? name
- ? ??? enabled
- ? ??? power
- ? ? ??? async
- ? ? []
- ? ??? subsystem -> ../../../../../class/power_cap
- ? ??? uevent
- ??? power
- ? ??? async
- ? []
- ??? subsystem -> ../../../../class/power_cap
- ??? enabled
- ??? uevent
+ /sys/devices/virtual/powercap
+ └──intel-rapl
+ ├──intel-rapl:0
+ │ ├──constraint_0_name
+ │ ├──constraint_0_power_limit_uw
+ │ ├──constraint_0_time_window_us
+ │ ├──constraint_1_name
+ │ ├──constraint_1_power_limit_uw
+ │ ├──constraint_1_time_window_us
+ │ ├──device -> ../../intel-rapl
+ │ ├──energy_uj
+ │ ├──intel-rapl:0:0
+ │ │ ├──constraint_0_name
+ │ │ ├──constraint_0_power_limit_uw
+ │ │ ├──constraint_0_time_window_us
+ │ │ ├──constraint_1_name
+ │ │ ├──constraint_1_power_limit_uw
+ │ │ ├──constraint_1_time_window_us
+ │ │ ├──device -> ../../intel-rapl:0
+ │ │ ├──energy_uj
+ │ │ ├──max_energy_range_uj
+ │ │ ├──name
+ │ │ ├──enabled
+ │ │ ├──power
+ │ │ │ ├──async
+ │ │ │ []
+ │ │ ├──subsystem -> ../../../../../../class/power_cap
+ │ │ └──uevent
+ │ ├──intel-rapl:0:1
+ │ │ ├──constraint_0_name
+ │ │ ├──constraint_0_power_limit_uw
+ │ │ ├──constraint_0_time_window_us
+ │ │ ├──constraint_1_name
+ │ │ ├──constraint_1_power_limit_uw
+ │ │ ├──constraint_1_time_window_us
+ │ │ ├──device -> ../../intel-rapl:0
+ │ │ ├──energy_uj
+ │ │ ├──max_energy_range_uj
+ │ │ ├──name
+ │ │ ├──enabled
+ │ │ ├──power
+ │ │ │ ├──async
+ │ │ │ []
+ │ │ ├──subsystem -> ../../../../../../class/power_cap
+ │ │ └──uevent
+ │ ├──max_energy_range_uj
+ │ ├──max_power_range_uw
+ │ ├──name
+ │ ├──enabled
+ │ ├──power
+ │ │ ├──async
+ │ │ []
+ │ ├──subsystem -> ../../../../../class/power_cap
+ │ ├──enabled
+ │ ├──uevent
+ ├──intel-rapl:1
+ │ ├──constraint_0_name
+ │ ├──constraint_0_power_limit_uw
+ │ ├──constraint_0_time_window_us
+ │ ├──constraint_1_name
+ │ ├──constraint_1_power_limit_uw
+ │ ├──constraint_1_time_window_us
+ │ ├──device -> ../../intel-rapl
+ │ ├──energy_uj
+ │ ├──intel-rapl:1:0
+ │ │ ├──constraint_0_name
+ │ │ ├──constraint_0_power_limit_uw
+ │ │ ├──constraint_0_time_window_us
+ │ │ ├──constraint_1_name
+ │ │ ├──constraint_1_power_limit_uw
+ │ │ ├──constraint_1_time_window_us
+ │ │ ├──device -> ../../intel-rapl:1
+ │ │ ├──energy_uj
+ │ │ ├──max_energy_range_uj
+ │ │ ├──name
+ │ │ ├──enabled
+ │ │ ├──power
+ │ │ │ ├──async
+ │ │ │ []
+ │ │ ├──subsystem -> ../../../../../../class/power_cap
+ │ │ └──uevent
+ │ ├──intel-rapl:1:1
+ │ │ ├──constraint_0_name
+ │ │ ├──constraint_0_power_limit_uw
+ │ │ ├──constraint_0_time_window_us
+ │ │ ├──constraint_1_name
+ │ │ ├──constraint_1_power_limit_uw
+ │ │ ├──constraint_1_time_window_us
+ │ │ ├──device -> ../../intel-rapl:1
+ │ │ ├──energy_uj
+ │ │ ├──max_energy_range_uj
+ │ │ ├──name
+ │ │ ├──enabled
+ │ │ ├──power
+ │ │ │ ├──async
+ │ │ │ []
+ │ │ ├──subsystem -> ../../../../../../class/power_cap
+ │ │ └──uevent
+ │ ├──max_energy_range_uj
+ │ ├──max_power_range_uw
+ │ ├──name
+ │ ├──enabled
+ │ ├──power
+ │ │ ├──async
+ │ │ []
+ │ ├──subsystem -> ../../../../../class/power_cap
+ │ ├──uevent
+ ├──power
+ │ ├──async
+ │ []
+ ├──subsystem -> ../../../../class/power_cap
+ ├──enabled
+ └──uevent
The above example illustrates a case in which the Intel RAPL technology,
available in Intel® IA-64 and IA-32 Processor Architectures, is used. There is one
@@ -158,10 +160,12 @@ power value, there is no power_uw attribute.
In addition to that, each power zone contains a name attribute, allowing the
part of the system represented by that zone to be identified.
-For example:
+For example::
+
+ cat /sys/class/power_cap/intel-rapl/intel-rapl:0/name
-cat /sys/class/power_cap/intel-rapl/intel-rapl:0/name
package-0
+---------
The Intel RAPL technology allows two constraints, short term and long term,
with two different time windows to be applied to each power zone. Thus for
@@ -169,7 +173,8 @@ each zone there are 2 attributes representing the constraint names, 2 power
limits and 2 attributes representing the sizes of the time windows. Such that,
constraint_j_* attributes correspond to the jth constraint (j = 0,1).
-For example:
+For example::
+
constraint_0_name
constraint_0_power_limit_uw
constraint_0_time_window_us
@@ -178,50 +183,66 @@ For example:
constraint_1_time_window_us
Power Zone Attributes
-=================================
+=====================
+
Monitoring attributes
-----------------------
+---------------------
-energy_uj (rw): Current energy counter in micro joules. Write "0" to reset.
-If the counter can not be reset, then this attribute is read only.
+energy_uj (rw)
+ Current energy counter in micro joules. Write "0" to reset.
+ If the counter can not be reset, then this attribute is read only.
-max_energy_range_uj (ro): Range of the above energy counter in micro-joules.
+max_energy_range_uj (ro)
+ Range of the above energy counter in micro-joules.
-power_uw (ro): Current power in micro watts.
+power_uw (ro)
+ Current power in micro watts.
-max_power_range_uw (ro): Range of the above power value in micro-watts.
+max_power_range_uw (ro)
+ Range of the above power value in micro-watts.
-name (ro): Name of this power zone.
+name (ro)
+ Name of this power zone.
It is possible that some domains have both power ranges and energy counter ranges;
however, only one is mandatory.
Constraints
-----------------
-constraint_X_power_limit_uw (rw): Power limit in micro watts, which should be
-applicable for the time window specified by "constraint_X_time_window_us".
+-----------
-constraint_X_time_window_us (rw): Time window in micro seconds.
+constraint_X_power_limit_uw (rw)
+ Power limit in micro watts, which should be applicable for the
+ time window specified by "constraint_X_time_window_us".
-constraint_X_name (ro): An optional name of the constraint
+constraint_X_time_window_us (rw)
+ Time window in micro seconds.
-constraint_X_max_power_uw(ro): Maximum allowed power in micro watts.
+constraint_X_name (ro)
+ An optional name of the constraint
-constraint_X_min_power_uw(ro): Minimum allowed power in micro watts.
+constraint_X_max_power_uw(ro)
+ Maximum allowed power in micro watts.
-constraint_X_max_time_window_us(ro): Maximum allowed time window in micro seconds.
+constraint_X_min_power_uw(ro)
+ Minimum allowed power in micro watts.
-constraint_X_min_time_window_us(ro): Minimum allowed time window in micro seconds.
+constraint_X_max_time_window_us(ro)
+ Maximum allowed time window in micro seconds.
+
+constraint_X_min_time_window_us(ro)
+ Minimum allowed time window in micro seconds.
Except power_limit_uw and time_window_us other fields are optional.
Common zone and control type attributes
-----------------------------------------
+---------------------------------------
+
enabled (rw): Enable/Disable controls at zone level or for all zones using
a control type.
Power Cap Client Driver Interface
-==================================
+=================================
+
The API summary:
Call powercap_register_control_type() to register control type object.
diff --git a/Documentation/power/regulator/consumer.txt b/Documentation/power/regulator/consumer.rst
similarity index 61%
rename from Documentation/power/regulator/consumer.txt
rename to Documentation/power/regulator/consumer.rst
index e51564c1a140..0cd8cc1275a7 100644
--- a/Documentation/power/regulator/consumer.txt
+++ b/Documentation/power/regulator/consumer.rst
@@ -1,3 +1,4 @@
+===================================
Regulator Consumer Driver Interface
===================================
@@ -8,73 +9,77 @@ Please see overview.txt for a description of the terms used in this text.
1. Consumer Regulator Access (static & dynamic drivers)
=======================================================
-A consumer driver can get access to its supply regulator by calling :-
+A consumer driver can get access to its supply regulator by calling ::
-regulator = regulator_get(dev, "Vcc");
+ regulator = regulator_get(dev, "Vcc");
The consumer passes in its struct device pointer and power supply ID. The core
then finds the correct regulator by consulting a machine specific lookup table.
If the lookup is successful then this call will return a pointer to the struct
regulator that supplies this consumer.
-To release the regulator the consumer driver should call :-
+To release the regulator the consumer driver should call ::
-regulator_put(regulator);
+ regulator_put(regulator);
Consumers can be supplied by more than one regulator e.g. codec consumer with
-analog and digital supplies :-
+analog and digital supplies ::
-digital = regulator_get(dev, "Vcc"); /* digital core */
-analog = regulator_get(dev, "Avdd"); /* analog */
+ digital = regulator_get(dev, "Vcc"); /* digital core */
+ analog = regulator_get(dev, "Avdd"); /* analog */
The regulator access functions regulator_get() and regulator_put() will
usually be called in your device drivers probe() and remove() respectively.
2. Regulator Output Enable & Disable (static & dynamic drivers)
-====================================================================
+===============================================================
-A consumer can enable its power supply by calling:-
-int regulator_enable(regulator);
+A consumer can enable its power supply by calling::
-NOTE: The supply may already be enabled before regulator_enabled() is called.
-This may happen if the consumer shares the regulator or the regulator has been
-previously enabled by bootloader or kernel board initialization code.
+ int regulator_enable(regulator);
-A consumer can determine if a regulator is enabled by calling :-
+NOTE:
+ The supply may already be enabled before regulator_enabled() is called.
+ This may happen if the consumer shares the regulator or the regulator has been
+ previously enabled by bootloader or kernel board initialization code.
-int regulator_is_enabled(regulator);
+A consumer can determine if a regulator is enabled by calling::
+
+ int regulator_is_enabled(regulator);
This will return > zero when the regulator is enabled.
-A consumer can disable its supply when no longer needed by calling :-
+A consumer can disable its supply when no longer needed by calling::
-int regulator_disable(regulator);
+ int regulator_disable(regulator);
-NOTE: This may not disable the supply if it's shared with other consumers. The
-regulator will only be disabled when the enabled reference count is zero.
+NOTE:
+ This may not disable the supply if it's shared with other consumers. The
+ regulator will only be disabled when the enabled reference count is zero.
-Finally, a regulator can be forcefully disabled in the case of an emergency :-
+Finally, a regulator can be forcefully disabled in the case of an emergency::
-int regulator_force_disable(regulator);
+ int regulator_force_disable(regulator);
-NOTE: this will immediately and forcefully shutdown the regulator output. All
-consumers will be powered off.
+NOTE:
+ this will immediately and forcefully shutdown the regulator output. All
+ consumers will be powered off.
3. Regulator Voltage Control & Status (dynamic drivers)
-======================================================
+=======================================================
Some consumer drivers need to be able to dynamically change their supply
voltage to match system operating points. e.g. CPUfreq drivers can scale
voltage along with frequency to save power, SD drivers may need to select the
correct card voltage, etc.
-Consumers can control their supply voltage by calling :-
+Consumers can control their supply voltage by calling::
-int regulator_set_voltage(regulator, min_uV, max_uV);
+ int regulator_set_voltage(regulator, min_uV, max_uV);
Where min_uV and max_uV are the minimum and maximum acceptable voltages in
microvolts.
@@ -84,47 +89,50 @@ when enabled, then the voltage changes instantly, otherwise the voltage
configuration changes and the voltage is physically set when the regulator is
next enabled.
-The regulators configured voltage output can be found by calling :-
+The regulators configured voltage output can be found by calling::
-int regulator_get_voltage(regulator);
+ int regulator_get_voltage(regulator);
-NOTE: get_voltage() will return the configured output voltage whether the
-regulator is enabled or disabled and should NOT be used to determine regulator
-output state. However this can be used in conjunction with is_enabled() to
-determine the regulator physical output voltage.
+NOTE:
+ get_voltage() will return the configured output voltage whether the
+ regulator is enabled or disabled and should NOT be used to determine regulator
+ output state. However this can be used in conjunction with is_enabled() to
+ determine the regulator physical output voltage.
4. Regulator Current Limit Control & Status (dynamic drivers)
-===========================================================
+=============================================================
Some consumer drivers need to be able to dynamically change their supply
current limit to match system operating points. e.g. LCD backlight driver can
change the current limit to vary the backlight brightness, USB drivers may want
to set the limit to 500mA when supplying power.
-Consumers can control their supply current limit by calling :-
+Consumers can control their supply current limit by calling::
-int regulator_set_current_limit(regulator, min_uA, max_uA);
+ int regulator_set_current_limit(regulator, min_uA, max_uA);
Where min_uA and max_uA are the minimum and maximum acceptable current limit in
microamps.
-NOTE: this can be called when the regulator is enabled or disabled. If called
-when enabled, then the current limit changes instantly, otherwise the current
-limit configuration changes and the current limit is physically set when the
-regulator is next enabled.
+NOTE:
+ this can be called when the regulator is enabled or disabled. If called
+ when enabled, then the current limit changes instantly, otherwise the current
+ limit configuration changes and the current limit is physically set when the
+ regulator is next enabled.
-A regulators current limit can be found by calling :-
+A regulators current limit can be found by calling::
-int regulator_get_current_limit(regulator);
+ int regulator_get_current_limit(regulator);
-NOTE: get_current_limit() will return the current limit whether the regulator
-is enabled or disabled and should not be used to determine regulator current
-load.
+NOTE:
+ get_current_limit() will return the current limit whether the regulator
+ is enabled or disabled and should not be used to determine regulator current
+ load.
5. Regulator Operating Mode Control & Status (dynamic drivers)
-=============================================================
+==============================================================
Some consumers can further save system power by changing the operating mode of
their supply regulator to be more efficient when the consumers operating state
@@ -135,9 +143,9 @@ Regulator operating mode can be changed indirectly or directly.
Indirect operating mode control.
--------------------------------
Consumer drivers can request a change in their supply regulator operating mode
-by calling :-
+by calling::
-int regulator_set_load(struct regulator *regulator, int load_uA);
+ int regulator_set_load(struct regulator *regulator, int load_uA);
This will cause the core to recalculate the total load on the regulator (based
on all its consumers) and change operating mode (if necessary and permitted)
@@ -153,12 +161,13 @@ consumers.
Direct operating mode control.
------------------------------
+
Bespoke or tightly coupled drivers may want to directly control regulator
operating mode depending on their operating point. This can be achieved by
-calling :-
+calling::
-int regulator_set_mode(struct regulator *regulator, unsigned int mode);
-unsigned int regulator_get_mode(struct regulator *regulator);
+ int regulator_set_mode(struct regulator *regulator, unsigned int mode);
+ unsigned int regulator_get_mode(struct regulator *regulator);
Direct mode will only be used by consumers that *know* about the regulator and
are not sharing the regulator with other consumers.
@@ -166,24 +175,26 @@ are not sharing the regulator with other consumers.
6. Regulator Events
===================
+
Regulators can notify consumers of external events. Events could be received by
consumers under regulator stress or failure conditions.
-Consumers can register interest in regulator events by calling :-
+Consumers can register interest in regulator events by calling::
-int regulator_register_notifier(struct regulator *regulator,
- struct notifier_block *nb);
+ int regulator_register_notifier(struct regulator *regulator,
+ struct notifier_block *nb);
-Consumers can unregister interest by calling :-
+Consumers can unregister interest by calling::
-int regulator_unregister_notifier(struct regulator *regulator,
- struct notifier_block *nb);
+ int regulator_unregister_notifier(struct regulator *regulator,
+ struct notifier_block *nb);
Regulators use the kernel notifier framework to send event to their interested
consumers.
7. Regulator Direct Register Access
===================================
+
Some kinds of power management hardware or firmware are designed such that
they need to do low-level hardware access to regulators, with no involvement
from the kernel. Examples of such devices are:
@@ -199,20 +210,20 @@ to it. The regulator framework provides the following helpers for querying
these details.
Bus-specific details, like I2C addresses or transfer rates are handled by the
-regmap framework. To get the regulator's regmap (if supported), use :-
+regmap framework. To get the regulator's regmap (if supported), use::
-struct regmap *regulator_get_regmap(struct regulator *regulator);
+ struct regmap *regulator_get_regmap(struct regulator *regulator);
To obtain the hardware register offset and bitmask for the regulator's voltage
-selector register, use :-
+selector register, use::
-int regulator_get_hardware_vsel_register(struct regulator *regulator,
- unsigned *vsel_reg,
- unsigned *vsel_mask);
+ int regulator_get_hardware_vsel_register(struct regulator *regulator,
+ unsigned *vsel_reg,
+ unsigned *vsel_mask);
To convert a regulator framework voltage selector code (used by
regulator_list_voltage) to a hardware-specific voltage selector that can be
-directly written to the voltage selector register, use :-
+directly written to the voltage selector register, use::
-int regulator_list_hardware_vsel(struct regulator *regulator,
- unsigned selector);
+ int regulator_list_hardware_vsel(struct regulator *regulator,
+ unsigned selector);
diff --git a/Documentation/power/regulator/design.txt b/Documentation/power/regulator/design.rst
similarity index 86%
rename from Documentation/power/regulator/design.txt
rename to Documentation/power/regulator/design.rst
index fdd919b96830..3b09c6841dc4 100644
--- a/Documentation/power/regulator/design.txt
+++ b/Documentation/power/regulator/design.rst
@@ -1,3 +1,4 @@
+==========================
Regulator API design notes
==========================
@@ -14,7 +15,9 @@ Safety
have different power requirements, and not all components with power
requirements are visible to software.
- => The API should make no changes to the hardware state unless it has
+.. note::
+
+ The API should make no changes to the hardware state unless it has
specific knowledge that these changes are safe to perform on this
particular system.
@@ -28,6 +31,8 @@ Consumer use cases
- Many of the power supplies in the system will be shared between many
different consumers.
- => The consumer API should be structured so that these use cases are
+.. note::
+
+ The consumer API should be structured so that these use cases are
very easy to handle and so that consumers will work with shared
supplies without any additional effort.
diff --git a/Documentation/power/regulator/machine.txt b/Documentation/power/regulator/machine.rst
similarity index 75%
rename from Documentation/power/regulator/machine.txt
rename to Documentation/power/regulator/machine.rst
index eff4dcaaa252..22fffefaa3ad 100644
--- a/Documentation/power/regulator/machine.txt
+++ b/Documentation/power/regulator/machine.rst
@@ -1,10 +1,11 @@
+==================================
Regulator Machine Driver Interface
-===================================
+==================================
The regulator machine driver interface is intended for board/machine specific
initialisation code to configure the regulator subsystem.
-Consider the following machine :-
+Consider the following machine::
Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V]
|
@@ -13,31 +14,31 @@ Consider the following machine :-
The drivers for consumers A & B must be mapped to the correct regulator in
order to control their power supplies. This mapping can be achieved in machine
initialisation code by creating a struct regulator_consumer_supply for
-each regulator.
+each regulator::
-struct regulator_consumer_supply {
+ struct regulator_consumer_supply {
const char *dev_name; /* consumer dev_name() */
const char *supply; /* consumer supply - e.g. "vcc" */
-};
+ };
-e.g. for the machine above
+e.g. for the machine above::
-static struct regulator_consumer_supply regulator1_consumers[] = {
+ static struct regulator_consumer_supply regulator1_consumers[] = {
REGULATOR_SUPPLY("Vcc", "consumer B"),
-};
+ };
-static struct regulator_consumer_supply regulator2_consumers[] = {
+ static struct regulator_consumer_supply regulator2_consumers[] = {
REGULATOR_SUPPLY("Vcc", "consumer A"),
-};
+ };
This maps Regulator-1 to the 'Vcc' supply for Consumer B and maps Regulator-2
to the 'Vcc' supply for Consumer A.
Constraints can now be registered by defining a struct regulator_init_data
for each regulator power domain. This structure also maps the consumers
-to their supply regulators :-
+to their supply regulators::
-static struct regulator_init_data regulator1_data = {
+ static struct regulator_init_data regulator1_data = {
.constraints = {
.name = "Regulator-1",
.min_uV = 3300000,
@@ -46,7 +47,7 @@ static struct regulator_init_data regulator1_data = {
},
.num_consumer_supplies = ARRAY_SIZE(regulator1_consumers),
.consumer_supplies = regulator1_consumers,
-};
+ };
The name field should be set to something that is usefully descriptive
for the board for configuration of supplies for other regulators and
@@ -57,9 +58,9 @@ name is provided then the subsystem will choose one.
Regulator-1 supplies power to Regulator-2. This relationship must be registered
with the core so that Regulator-1 is also enabled when Consumer A enables its
supply (Regulator-2). The supply regulator is set by the supply_regulator
-field below and co:-
+field below and co::
-static struct regulator_init_data regulator2_data = {
+ static struct regulator_init_data regulator2_data = {
.supply_regulator = "Regulator-1",
.constraints = {
.min_uV = 1800000,
@@ -69,11 +70,11 @@ static struct regulator_init_data regulator2_data = {
},
.num_consumer_supplies = ARRAY_SIZE(regulator2_consumers),
.consumer_supplies = regulator2_consumers,
-};
+ };
-Finally the regulator devices must be registered in the usual manner.
+Finally the regulator devices must be registered in the usual manner::
-static struct platform_device regulator_devices[] = {
+ static struct platform_device regulator_devices[] = {
{
.name = "regulator",
.id = DCDC_1,
@@ -88,9 +89,9 @@ static struct platform_device regulator_devices[] = {
.platform_data = ®ulator2_data,
},
},
-};
-/* register regulator 1 device */
-platform_device_register(®ulator_devices[0]);
+ };
+ /* register regulator 1 device */
+ platform_device_register(®ulator_devices[0]);
-/* register regulator 2 device */
-platform_device_register(®ulator_devices[1]);
+ /* register regulator 2 device */
+ platform_device_register(®ulator_devices[1]);
diff --git a/Documentation/power/regulator/overview.txt b/Documentation/power/regulator/overview.rst
similarity index 79%
rename from Documentation/power/regulator/overview.txt
rename to Documentation/power/regulator/overview.rst
index 721b4739ec32..ee494c70a7c4 100644
--- a/Documentation/power/regulator/overview.txt
+++ b/Documentation/power/regulator/overview.rst
@@ -1,3 +1,4 @@
+=============================================
Linux voltage and current regulator framework
=============================================
@@ -13,26 +14,30 @@ regulators (where voltage output is controllable) and current sinks (where
current limit is controllable).
(C) 2008 Wolfson Microelectronics PLC.
+
Author: Liam Girdwood <lrg@slimlogic.co.uk>
Nomenclature
============
-Some terms used in this document:-
+Some terms used in this document:
- o Regulator - Electronic device that supplies power to other devices.
+ - Regulator
+ - Electronic device that supplies power to other devices.
Most regulators can enable and disable their output while
some can control their output voltage and or current.
Input Voltage -> Regulator -> Output Voltage
- o PMIC - Power Management IC. An IC that contains numerous regulators
- and often contains other subsystems.
+ - PMIC
+ - Power Management IC. An IC that contains numerous
+ regulators and often contains other subsystems.
- o Consumer - Electronic device that is supplied power by a regulator.
+ - Consumer
+ - Electronic device that is supplied power by a regulator.
Consumers can be classified into two types:-
Static: consumer does not change its supply voltage or
@@ -44,46 +49,48 @@ Some terms used in this document:-
current limit to meet operation demands.
- o Power Domain - Electronic circuit that is supplied its input power by the
+ - Power Domain
+ - Electronic circuit that is supplied its input power by the
output power of a regulator, switch or by another power
domain.
- The supply regulator may be behind a switch(s). i.e.
+ The supply regulator may be behind a switch(s). i.e.::
- Regulator -+-> Switch-1 -+-> Switch-2 --> [Consumer A]
- | |
- | +-> [Consumer B], [Consumer C]
- |
- +-> [Consumer D], [Consumer E]
+ Regulator -+-> Switch-1 -+-> Switch-2 --> [Consumer A]
+ | |
+ | +-> [Consumer B], [Consumer C]
+ |
+ +-> [Consumer D], [Consumer E]
That is one regulator and three power domains:
- Domain 1: Switch-1, Consumers D & E.
- Domain 2: Switch-2, Consumers B & C.
- Domain 3: Consumer A.
+ - Domain 1: Switch-1, Consumers D & E.
+ - Domain 2: Switch-2, Consumers B & C.
+ - Domain 3: Consumer A.
and this represents a "supplies" relationship:
Domain-1 --> Domain-2 --> Domain-3.
A power domain may have regulators that are supplied power
- by other regulators. i.e.
+ by other regulators. i.e.::
- Regulator-1 -+-> Regulator-2 -+-> [Consumer A]
- |
- +-> [Consumer B]
+ Regulator-1 -+-> Regulator-2 -+-> [Consumer A]
+ |
+ +-> [Consumer B]
This gives us two regulators and two power domains:
- Domain 1: Regulator-2, Consumer B.
- Domain 2: Consumer A.
+ - Domain 1: Regulator-2, Consumer B.
+ - Domain 2: Consumer A.
and a "supplies" relationship:
Domain-1 --> Domain-2
- o Constraints - Constraints are used to define power levels for performance
+ - Constraints
+ - Constraints are used to define power levels for performance
and hardware protection. Constraints exist at three levels:
Regulator Level: This is defined by the regulator hardware
@@ -141,7 +148,7 @@ relevant to non SoC devices and is split into the following four interfaces:-
limit. This also compiles out if not in use so drivers can be reused in
systems with no regulator based power control.
- See Documentation/power/regulator/consumer.txt
+ See Documentation/power/regulator/consumer.rst
2. Regulator driver interface.
@@ -149,7 +156,7 @@ relevant to non SoC devices and is split into the following four interfaces:-
operations to the core. It also has a notifier call chain for propagating
regulator events to clients.
- See Documentation/power/regulator/regulator.txt
+ See Documentation/power/regulator/regulator.rst
3. Machine interface.
@@ -160,7 +167,7 @@ relevant to non SoC devices and is split into the following four interfaces:-
allows the creation of a regulator tree whereby some regulators are
supplied by others (similar to a clock tree).
- See Documentation/power/regulator/machine.txt
+ See Documentation/power/regulator/machine.rst
4. Userspace ABI.
diff --git a/Documentation/power/regulator/regulator.txt b/Documentation/power/regulator/regulator.rst
similarity index 49%
rename from Documentation/power/regulator/regulator.txt
rename to Documentation/power/regulator/regulator.rst
index b17e5833ce21..794b3256fbb9 100644
--- a/Documentation/power/regulator/regulator.txt
+++ b/Documentation/power/regulator/regulator.rst
@@ -1,3 +1,4 @@
+==========================
Regulator Driver Interface
==========================
@@ -8,23 +9,24 @@ regulator drivers to register their services with the core framework.
Registration
============
-Drivers can register a regulator by calling :-
+Drivers can register a regulator by calling::
-struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
- const struct regulator_config *config);
+ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
+ const struct regulator_config *config);
This will register the regulator's capabilities and operations to the regulator
core.
-Regulators can be unregistered by calling :-
+Regulators can be unregistered by calling::
-void regulator_unregister(struct regulator_dev *rdev);
+ void regulator_unregister(struct regulator_dev *rdev);
Regulator Events
================
+
Regulators can send events (e.g. overtemperature, undervoltage, etc) to
-consumer drivers by calling :-
+consumer drivers by calling::
-int regulator_notifier_call_chain(struct regulator_dev *rdev,
- unsigned long event, void *data);
+ int regulator_notifier_call_chain(struct regulator_dev *rdev,
+ unsigned long event, void *data);
diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.rst
similarity index 89%
rename from Documentation/power/runtime_pm.txt
rename to Documentation/power/runtime_pm.rst
index 937e33c46211..2c2ec99b5088 100644
--- a/Documentation/power/runtime_pm.txt
+++ b/Documentation/power/runtime_pm.rst
@@ -1,10 +1,15 @@
+==================================================
Runtime Power Management Framework for I/O Devices
+==================================================
(C) 2009-2011 Rafael J. Wysocki <rjw@sisk.pl>, Novell Inc.
+
(C) 2010 Alan Stern <stern@rowland.harvard.edu>
+
(C) 2014 Intel Corp., Rafael J. Wysocki <rafael.j.wysocki@intel.com>
1. Introduction
+===============
Support for runtime power management (runtime PM) of I/O devices is provided
at the power management core (PM core) level by means of:
@@ -33,16 +38,17 @@ fields of 'struct dev_pm_info' and the core helper functions provided for
runtime PM are described below.
2. Device Runtime PM Callbacks
+==============================
-There are three device runtime PM callbacks defined in 'struct dev_pm_ops':
+There are three device runtime PM callbacks defined in 'struct dev_pm_ops'::
-struct dev_pm_ops {
+ struct dev_pm_ops {
...
int (*runtime_suspend)(struct device *dev);
int (*runtime_resume)(struct device *dev);
int (*runtime_idle)(struct device *dev);
...
-};
+ };
The ->runtime_suspend(), ->runtime_resume() and ->runtime_idle() callbacks
are executed by the PM core for the device's subsystem that may be either of
@@ -112,7 +118,7 @@ low-power state during the execution of the suspend callback, it is expected
that remote wakeup will be enabled for the device. Generally, remote wakeup
should be enabled for all input devices put into low-power states at run time.
-The subsystem-level resume callback, if present, is _entirely_ _responsible_ for
+The subsystem-level resume callback, if present, is **entirely responsible** for
handling the resume of the device as appropriate, which may, but need not
include executing the device driver's own ->runtime_resume() callback (from the
PM core's point of view it is not necessary to implement a ->runtime_resume()
@@ -197,95 +203,96 @@ rules:
except for scheduled autosuspends.
3. Runtime PM Device Fields
+===========================
The following device runtime PM fields are present in 'struct dev_pm_info', as
defined in include/linux/pm.h:
- struct timer_list suspend_timer;
+ `struct timer_list suspend_timer;`
- timer used for scheduling (delayed) suspend and autosuspend requests
- unsigned long timer_expires;
+ `unsigned long timer_expires;`
- timer expiration time, in jiffies (if this is different from zero, the
timer is running and will expire at that time, otherwise the timer is not
running)
- struct work_struct work;
+ `struct work_struct work;`
- work structure used for queuing up requests (i.e. work items in pm_wq)
- wait_queue_head_t wait_queue;
+ `wait_queue_head_t wait_queue;`
- wait queue used if any of the helper functions needs to wait for another
one to complete
- spinlock_t lock;
+ `spinlock_t lock;`
- lock used for synchronization
- atomic_t usage_count;
+ `atomic_t usage_count;`
- the usage counter of the device
- atomic_t child_count;
+ `atomic_t child_count;`
- the count of 'active' children of the device
- unsigned int ignore_children;
+ `unsigned int ignore_children;`
- if set, the value of child_count is ignored (but still updated)
- unsigned int disable_depth;
+ `unsigned int disable_depth;`
- used for disabling the helper functions (they work normally if this is
equal to zero); the initial value of it is 1 (i.e. runtime PM is
initially disabled for all devices)
- int runtime_error;
+ `int runtime_error;`
- if set, there was a fatal error (one of the callbacks returned error code
as described in Section 2), so the helper functions will not work until
this flag is cleared; this is the error code returned by the failing
callback
- unsigned int idle_notification;
+ `unsigned int idle_notification;`
- if set, ->runtime_idle() is being executed
- unsigned int request_pending;
+ `unsigned int request_pending;`
- if set, there's a pending request (i.e. a work item queued up into pm_wq)
- enum rpm_request request;
+ `enum rpm_request request;`
- type of request that's pending (valid if request_pending is set)
- unsigned int deferred_resume;
+ `unsigned int deferred_resume;`
- set if ->runtime_resume() is about to be run while ->runtime_suspend() is
being executed for that device and it is not practical to wait for the
suspend to complete; means "start a resume as soon as you've suspended"
- enum rpm_status runtime_status;
+ `enum rpm_status runtime_status;`
- the runtime PM status of the device; this field's initial value is
RPM_SUSPENDED, which means that each device is initially regarded by the
PM core as 'suspended', regardless of its real hardware status
- unsigned int runtime_auto;
+ `unsigned int runtime_auto;`
- if set, indicates that the user space has allowed the device driver to
power manage the device at run time via the /sys/devices/.../power/control
- interface; it may only be modified with the help of the pm_runtime_allow()
+ `interface;` it may only be modified with the help of the pm_runtime_allow()
and pm_runtime_forbid() helper functions
- unsigned int no_callbacks;
+ `unsigned int no_callbacks;`
- indicates that the device does not use the runtime PM callbacks (see
Section 8); it may be modified only by the pm_runtime_no_callbacks()
helper function
- unsigned int irq_safe;
+ `unsigned int irq_safe;`
- indicates that the ->runtime_suspend() and ->runtime_resume() callbacks
will be invoked with the spinlock held and interrupts disabled
- unsigned int use_autosuspend;
+ `unsigned int use_autosuspend;`
- indicates that the device's driver supports delayed autosuspend (see
Section 9); it may be modified only by the
pm_runtime{_dont}_use_autosuspend() helper functions
- unsigned int timer_autosuspends;
+ `unsigned int timer_autosuspends;`
- indicates that the PM core should attempt to carry out an autosuspend
when the timer expires rather than a normal suspend
- int autosuspend_delay;
+ `int autosuspend_delay;`
- the delay time (in milliseconds) to be used for autosuspend
- unsigned long last_busy;
+ `unsigned long last_busy;`
- the time (in jiffies) when the pm_runtime_mark_last_busy() helper
function was last called for this device; used in calculating inactivity
periods for autosuspend
@@ -293,37 +300,38 @@ defined in include/linux/pm.h:
All of the above fields are members of the 'power' member of 'struct device'.
4. Runtime PM Device Helper Functions
+=====================================
The following runtime PM helper functions are defined in
drivers/base/power/runtime.c and include/linux/pm_runtime.h:
- void pm_runtime_init(struct device *dev);
+ `void pm_runtime_init(struct device *dev);`
- initialize the device runtime PM fields in 'struct dev_pm_info'
- void pm_runtime_remove(struct device *dev);
+ `void pm_runtime_remove(struct device *dev);`
- make sure that the runtime PM of the device will be disabled after
removing the device from device hierarchy
- int pm_runtime_idle(struct device *dev);
+ `int pm_runtime_idle(struct device *dev);`
- execute the subsystem-level idle callback for the device; returns an
error code on failure, where -EINPROGRESS means that ->runtime_idle() is
already being executed; if there is no callback or the callback returns 0
then run pm_runtime_autosuspend(dev) and return its result
- int pm_runtime_suspend(struct device *dev);
+ `int pm_runtime_suspend(struct device *dev);`
- execute the subsystem-level suspend callback for the device; returns 0 on
success, 1 if the device's runtime PM status was already 'suspended', or
error code on failure, where -EAGAIN or -EBUSY means it is safe to attempt
to suspend the device again in future and -EACCES means that
'power.disable_depth' is different from 0
- int pm_runtime_autosuspend(struct device *dev);
+ `int pm_runtime_autosuspend(struct device *dev);`
- same as pm_runtime_suspend() except that the autosuspend delay is taken
- into account; if pm_runtime_autosuspend_expiration() says the delay has
+ `into account;` if pm_runtime_autosuspend_expiration() says the delay has
not yet expired then an autosuspend is scheduled for the appropriate time
and 0 is returned
- int pm_runtime_resume(struct device *dev);
+ `int pm_runtime_resume(struct device *dev);`
- execute the subsystem-level resume callback for the device; returns 0 on
success, 1 if the device's runtime PM status was already 'active' or
error code on failure, where -EAGAIN means it may be safe to attempt to
@@ -331,17 +339,17 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
checked additionally, and -EACCES means that 'power.disable_depth' is
different from 0
- int pm_request_idle(struct device *dev);
+ `int pm_request_idle(struct device *dev);`
- submit a request to execute the subsystem-level idle callback for the
device (the request is represented by a work item in pm_wq); returns 0 on
success or error code if the request has not been queued up
- int pm_request_autosuspend(struct device *dev);
+ `int pm_request_autosuspend(struct device *dev);`
- schedule the execution of the subsystem-level suspend callback for the
device when the autosuspend delay has expired; if the delay has already
expired then the work item is queued up immediately
- int pm_schedule_suspend(struct device *dev, unsigned int delay);
+ `int pm_schedule_suspend(struct device *dev, unsigned int delay);`
- schedule the execution of the subsystem-level suspend callback for the
device in future, where 'delay' is the time to wait before queuing up a
suspend work item in pm_wq, in milliseconds (if 'delay' is zero, the work
@@ -351,58 +359,58 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
->runtime_suspend() is already scheduled and not yet expired, the new
value of 'delay' will be used as the time to wait
- int pm_request_resume(struct device *dev);
+ `int pm_request_resume(struct device *dev);`
- submit a request to execute the subsystem-level resume callback for the
device (the request is represented by a work item in pm_wq); returns 0 on
success, 1 if the device's runtime PM status was already 'active', or
error code if the request hasn't been queued up
- void pm_runtime_get_noresume(struct device *dev);
+ `void pm_runtime_get_noresume(struct device *dev);`
- increment the device's usage counter
- int pm_runtime_get(struct device *dev);
+ `int pm_runtime_get(struct device *dev);`
- increment the device's usage counter, run pm_request_resume(dev) and
return its result
- int pm_runtime_get_sync(struct device *dev);
+ `int pm_runtime_get_sync(struct device *dev);`
- increment the device's usage counter, run pm_runtime_resume(dev) and
return its result
- int pm_runtime_get_if_in_use(struct device *dev);
+ `int pm_runtime_get_if_in_use(struct device *dev);`
- return -EINVAL if 'power.disable_depth' is nonzero; otherwise, if the
runtime PM status is RPM_ACTIVE and the runtime PM usage counter is
nonzero, increment the counter and return 1; otherwise return 0 without
changing the counter
- void pm_runtime_put_noidle(struct device *dev);
+ `void pm_runtime_put_noidle(struct device *dev);`
- decrement the device's usage counter
- int pm_runtime_put(struct device *dev);
+ `int pm_runtime_put(struct device *dev);`
- decrement the device's usage counter; if the result is 0 then run
pm_request_idle(dev) and return its result
- int pm_runtime_put_autosuspend(struct device *dev);
+ `int pm_runtime_put_autosuspend(struct device *dev);`
- decrement the device's usage counter; if the result is 0 then run
pm_request_autosuspend(dev) and return its result
- int pm_runtime_put_sync(struct device *dev);
+ `int pm_runtime_put_sync(struct device *dev);`
- decrement the device's usage counter; if the result is 0 then run
pm_runtime_idle(dev) and return its result
- int pm_runtime_put_sync_suspend(struct device *dev);
+ `int pm_runtime_put_sync_suspend(struct device *dev);`
- decrement the device's usage counter; if the result is 0 then run
pm_runtime_suspend(dev) and return its result
- int pm_runtime_put_sync_autosuspend(struct device *dev);
+ `int pm_runtime_put_sync_autosuspend(struct device *dev);`
- decrement the device's usage counter; if the result is 0 then run
pm_runtime_autosuspend(dev) and return its result
- void pm_runtime_enable(struct device *dev);
+ `void pm_runtime_enable(struct device *dev);`
- decrement the device's 'power.disable_depth' field; if that field is equal
to zero, the runtime PM helper functions can execute subsystem-level
callbacks described in Section 2 for the device
- int pm_runtime_disable(struct device *dev);
+ `int pm_runtime_disable(struct device *dev);`
- increment the device's 'power.disable_depth' field (if the value of that
field was previously zero, this prevents subsystem-level runtime PM
callbacks from being run for the device), make sure that all of the
@@ -411,7 +419,7 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
necessary to execute the subsystem-level resume callback for the device
to satisfy that request, otherwise 0 is returned
- int pm_runtime_barrier(struct device *dev);
+ `int pm_runtime_barrier(struct device *dev);`
- check if there's a resume request pending for the device and resume it
(synchronously) in that case, cancel any other pending runtime PM requests
regarding it and wait for all runtime PM operations on it in progress to
@@ -419,10 +427,10 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
necessary to execute the subsystem-level resume callback for the device to
satisfy that request, otherwise 0 is returned
- void pm_suspend_ignore_children(struct device *dev, bool enable);
+ `void pm_suspend_ignore_children(struct device *dev, bool enable);`
- set/unset the power.ignore_children flag of the device
- int pm_runtime_set_active(struct device *dev);
+ `int pm_runtime_set_active(struct device *dev);`
- clear the device's 'power.runtime_error' flag, set the device's runtime
PM status to 'active' and update its parent's counter of 'active'
children as appropriate (it is only valid to use this function if
@@ -430,61 +438,61 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
zero); it will fail and return error code if the device has a parent
which is not active and the 'power.ignore_children' flag of which is unset
- void pm_runtime_set_suspended(struct device *dev);
+ `void pm_runtime_set_suspended(struct device *dev);`
- clear the device's 'power.runtime_error' flag, set the device's runtime
PM status to 'suspended' and update its parent's counter of 'active'
children as appropriate (it is only valid to use this function if
'power.runtime_error' is set or 'power.disable_depth' is greater than
zero)
- bool pm_runtime_active(struct device *dev);
+ `bool pm_runtime_active(struct device *dev);`
- return true if the device's runtime PM status is 'active' or its
'power.disable_depth' field is not equal to zero, or false otherwise
- bool pm_runtime_suspended(struct device *dev);
+ `bool pm_runtime_suspended(struct device *dev);`
- return true if the device's runtime PM status is 'suspended' and its
'power.disable_depth' field is equal to zero, or false otherwise
- bool pm_runtime_status_suspended(struct device *dev);
+ `bool pm_runtime_status_suspended(struct device *dev);`
- return true if the device's runtime PM status is 'suspended'
- void pm_runtime_allow(struct device *dev);
+ `void pm_runtime_allow(struct device *dev);`
- set the power.runtime_auto flag for the device and decrease its usage
counter (used by the /sys/devices/.../power/control interface to
effectively allow the device to be power managed at run time)
- void pm_runtime_forbid(struct device *dev);
+ `void pm_runtime_forbid(struct device *dev);`
- unset the power.runtime_auto flag for the device and increase its usage
counter (used by the /sys/devices/.../power/control interface to
effectively prevent the device from being power managed at run time)
- void pm_runtime_no_callbacks(struct device *dev);
+ `void pm_runtime_no_callbacks(struct device *dev);`
- set the power.no_callbacks flag for the device and remove the runtime
PM attributes from /sys/devices/.../power (or prevent them from being
added when the device is registered)
- void pm_runtime_irq_safe(struct device *dev);
+ `void pm_runtime_irq_safe(struct device *dev);`
- set the power.irq_safe flag for the device, causing the runtime-PM
callbacks to be invoked with interrupts off
- bool pm_runtime_is_irq_safe(struct device *dev);
+ `bool pm_runtime_is_irq_safe(struct device *dev);`
- return true if power.irq_safe flag was set for the device, causing
the runtime-PM callbacks to be invoked with interrupts off
- void pm_runtime_mark_last_busy(struct device *dev);
+ `void pm_runtime_mark_last_busy(struct device *dev);`
- set the power.last_busy field to the current time
- void pm_runtime_use_autosuspend(struct device *dev);
+ `void pm_runtime_use_autosuspend(struct device *dev);`
- set the power.use_autosuspend flag, enabling autosuspend delays; call
pm_runtime_get_sync if the flag was previously cleared and
power.autosuspend_delay is negative
- void pm_runtime_dont_use_autosuspend(struct device *dev);
+ `void pm_runtime_dont_use_autosuspend(struct device *dev);`
- clear the power.use_autosuspend flag, disabling autosuspend delays;
decrement the device's usage counter if the flag was previously set and
power.autosuspend_delay is negative; call pm_runtime_idle
- void pm_runtime_set_autosuspend_delay(struct device *dev, int delay);
+ `void pm_runtime_set_autosuspend_delay(struct device *dev, int delay);`
- set the power.autosuspend_delay value to 'delay' (expressed in
milliseconds); if 'delay' is negative then runtime suspends are
prevented; if power.use_autosuspend is set, pm_runtime_get_sync may be
@@ -493,7 +501,7 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
changed to or from a negative value; if power.use_autosuspend is clear,
pm_runtime_idle is called
- unsigned long pm_runtime_autosuspend_expiration(struct device *dev);
+ `unsigned long pm_runtime_autosuspend_expiration(struct device *dev);`
- calculate the time when the current autosuspend delay period will expire,
based on power.last_busy and power.autosuspend_delay; if the delay time
is 1000 ms or larger then the expiration time is rounded up to the
@@ -503,36 +511,37 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
It is safe to execute the following helper functions from interrupt context:
-pm_request_idle()
-pm_request_autosuspend()
-pm_schedule_suspend()
-pm_request_resume()
-pm_runtime_get_noresume()
-pm_runtime_get()
-pm_runtime_put_noidle()
-pm_runtime_put()
-pm_runtime_put_autosuspend()
-pm_runtime_enable()
-pm_suspend_ignore_children()
-pm_runtime_set_active()
-pm_runtime_set_suspended()
-pm_runtime_suspended()
-pm_runtime_mark_last_busy()
-pm_runtime_autosuspend_expiration()
+- pm_request_idle()
+- pm_request_autosuspend()
+- pm_schedule_suspend()
+- pm_request_resume()
+- pm_runtime_get_noresume()
+- pm_runtime_get()
+- pm_runtime_put_noidle()
+- pm_runtime_put()
+- pm_runtime_put_autosuspend()
+- pm_runtime_enable()
+- pm_suspend_ignore_children()
+- pm_runtime_set_active()
+- pm_runtime_set_suspended()
+- pm_runtime_suspended()
+- pm_runtime_mark_last_busy()
+- pm_runtime_autosuspend_expiration()
If pm_runtime_irq_safe() has been called for a device then the following helper
functions may also be used in interrupt context:
-pm_runtime_idle()
-pm_runtime_suspend()
-pm_runtime_autosuspend()
-pm_runtime_resume()
-pm_runtime_get_sync()
-pm_runtime_put_sync()
-pm_runtime_put_sync_suspend()
-pm_runtime_put_sync_autosuspend()
+- pm_runtime_idle()
+- pm_runtime_suspend()
+- pm_runtime_autosuspend()
+- pm_runtime_resume()
+- pm_runtime_get_sync()
+- pm_runtime_put_sync()
+- pm_runtime_put_sync_suspend()
+- pm_runtime_put_sync_autosuspend()
5. Runtime PM Initialization, Device Probing and Removal
+========================================================
Initially, the runtime PM is disabled for all devices, which means that the
majority of the runtime PM helper functions described in Section 4 will return
@@ -608,6 +617,7 @@ manage the device at run time, the driver may confuse it by using
pm_runtime_forbid() this way.
6. Runtime PM and System Sleep
+==============================
Runtime PM and system sleep (i.e., system suspend and hibernation, also known
as suspend-to-RAM and suspend-to-disk) interact with each other in a couple of
@@ -647,9 +657,9 @@ brought back to full power during resume, then its runtime PM status will have
to be updated to reflect the actual post-system sleep status. The way to do
this is:
- pm_runtime_disable(dev);
- pm_runtime_set_active(dev);
- pm_runtime_enable(dev);
+ - pm_runtime_disable(dev);
+ - pm_runtime_set_active(dev);
+ - pm_runtime_enable(dev);
The PM core always increments the runtime usage counter before calling the
->suspend() callback and decrements it after calling the ->resume() callback.
@@ -705,66 +715,66 @@ Subsystems may wish to conserve code space by using the set of generic power
management callbacks provided by the PM core, defined in
driver/base/power/generic_ops.c:
- int pm_generic_runtime_suspend(struct device *dev);
+ `int pm_generic_runtime_suspend(struct device *dev);`
- invoke the ->runtime_suspend() callback provided by the driver of this
device and return its result, or return 0 if not defined
- int pm_generic_runtime_resume(struct device *dev);
+ `int pm_generic_runtime_resume(struct device *dev);`
- invoke the ->runtime_resume() callback provided by the driver of this
device and return its result, or return 0 if not defined
- int pm_generic_suspend(struct device *dev);
+ `int pm_generic_suspend(struct device *dev);`
- if the device has not been suspended at run time, invoke the ->suspend()
callback provided by its driver and return its result, or return 0 if not
defined
- int pm_generic_suspend_noirq(struct device *dev);
+ `int pm_generic_suspend_noirq(struct device *dev);`
- if pm_runtime_suspended(dev) returns "false", invoke the ->suspend_noirq()
callback provided by the device's driver and return its result, or return
0 if not defined
- int pm_generic_resume(struct device *dev);
+ `int pm_generic_resume(struct device *dev);`
- invoke the ->resume() callback provided by the driver of this device and,
if successful, change the device's runtime PM status to 'active'
- int pm_generic_resume_noirq(struct device *dev);
+ `int pm_generic_resume_noirq(struct device *dev);`
- invoke the ->resume_noirq() callback provided by the driver of this device
- int pm_generic_freeze(struct device *dev);
+ `int pm_generic_freeze(struct device *dev);`
- if the device has not been suspended at run time, invoke the ->freeze()
callback provided by its driver and return its result, or return 0 if not
defined
- int pm_generic_freeze_noirq(struct device *dev);
+ `int pm_generic_freeze_noirq(struct device *dev);`
- if pm_runtime_suspended(dev) returns "false", invoke the ->freeze_noirq()
callback provided by the device's driver and return its result, or return
0 if not defined
- int pm_generic_thaw(struct device *dev);
+ `int pm_generic_thaw(struct device *dev);`
- if the device has not been suspended at run time, invoke the ->thaw()
callback provided by its driver and return its result, or return 0 if not
defined
- int pm_generic_thaw_noirq(struct device *dev);
+ `int pm_generic_thaw_noirq(struct device *dev);`
- if pm_runtime_suspended(dev) returns "false", invoke the ->thaw_noirq()
callback provided by the device's driver and return its result, or return
0 if not defined
- int pm_generic_poweroff(struct device *dev);
+ `int pm_generic_poweroff(struct device *dev);`
- if the device has not been suspended at run time, invoke the ->poweroff()
callback provided by its driver and return its result, or return 0 if not
defined
- int pm_generic_poweroff_noirq(struct device *dev);
+ `int pm_generic_poweroff_noirq(struct device *dev);`
- if pm_runtime_suspended(dev) returns "false", run the ->poweroff_noirq()
callback provided by the device's driver and return its result, or return
0 if not defined
- int pm_generic_restore(struct device *dev);
+ `int pm_generic_restore(struct device *dev);`
- invoke the ->restore() callback provided by the driver of this device and,
if successful, change the device's runtime PM status to 'active'
- int pm_generic_restore_noirq(struct device *dev);
+ `int pm_generic_restore_noirq(struct device *dev);`
- invoke the ->restore_noirq() callback provided by the device's driver
These functions are the defaults used by the PM core, if a subsystem doesn't
@@ -781,6 +791,7 @@ UNIVERSAL_DEV_PM_OPS macro defined in include/linux/pm.h (possibly setting its
last argument to NULL).
8. "No-Callback" Devices
+========================
Some "devices" are only logical sub-devices of their parent and cannot be
power-managed on their own. (The prototype example is a USB interface. Entire
@@ -807,6 +818,7 @@ parent must take responsibility for telling the device's driver when the
parent's power state changes.
9. Autosuspend, or automatically-delayed suspends
+=================================================
Changing a device's power state isn't free; it requires both time and energy.
A device should be put in a low-power state only when there's some reason to
@@ -832,8 +844,8 @@ registration the length should be controlled by user space, using the
In order to use autosuspend, subsystems or drivers must call
pm_runtime_use_autosuspend() (preferably before registering the device), and
-thereafter they should use the various *_autosuspend() helper functions instead
-of the non-autosuspend counterparts:
+thereafter they should use the various `*_autosuspend()` helper functions
+instead of the non-autosuspend counterparts::
Instead of: pm_runtime_suspend use: pm_runtime_autosuspend;
Instead of: pm_schedule_suspend use: pm_request_autosuspend;
@@ -858,7 +870,7 @@ The implementation is well suited for asynchronous use in interrupt contexts.
However such use inevitably involves races, because the PM core can't
synchronize ->runtime_suspend() callbacks with the arrival of I/O requests.
This synchronization must be handled by the driver, using its private lock.
-Here is a schematic pseudo-code example:
+Here is a schematic pseudo-code example::
foo_read_or_write(struct foo_priv *foo, void *data)
{
diff --git a/Documentation/power/s2ram.txt b/Documentation/power/s2ram.rst
similarity index 92%
rename from Documentation/power/s2ram.txt
rename to Documentation/power/s2ram.rst
index 4685aee197fd..d739aa7c742c 100644
--- a/Documentation/power/s2ram.txt
+++ b/Documentation/power/s2ram.rst
@@ -1,7 +1,9 @@
- How to get s2ram working
- ~~~~~~~~~~~~~~~~~~~~~~~~
- 2006 Linus Torvalds
- 2006 Pavel Machek
+========================
+How to get s2ram working
+========================
+
+2006 Linus Torvalds
+2006 Pavel Machek
1) Check suspend.sf.net, program s2ram there has long whitelist of
"known ok" machines, along with tricks to use on each one.
@@ -12,8 +14,8 @@
3) You can use Linus' TRACE_RESUME infrastructure, described below.
- Using TRACE_RESUME
- ~~~~~~~~~~~~~~~~~~
+Using TRACE_RESUME
+~~~~~~~~~~~~~~~~~~
I've been working at making the machines I have able to STR, and almost
always it's a driver that is buggy. Thank God for the suspend/resume
@@ -27,7 +29,7 @@ machine that doesn't boot) is:
- enable PM_DEBUG, and PM_TRACE
- - use a script like this:
+ - use a script like this::
#!/bin/sh
sync
@@ -38,7 +40,7 @@ machine that doesn't boot) is:
- if it doesn't come back up (which is usually the problem), reboot by
holding the power button down, and look at the dmesg output for things
- like
+ like::
Magic number: 4:156:725
hash matches drivers/base/power/resume.c:28
@@ -52,7 +54,7 @@ machine that doesn't boot) is:
If no device matches the hash (or any matches appear to be false positives),
the culprit may be a device from a loadable kernel module that is not loaded
until after the hash is checked. You can check the hash against the current
- devices again after more modules are loaded using sysfs:
+ devices again after more modules are loaded using sysfs::
cat /sys/power/pm_trace_dev_match
diff --git a/Documentation/power/suspend-and-cpuhotplug.txt b/Documentation/power/suspend-and-cpuhotplug.rst
similarity index 90%
rename from Documentation/power/suspend-and-cpuhotplug.txt
rename to Documentation/power/suspend-and-cpuhotplug.rst
index a8751b8df10e..9df664f5423a 100644
--- a/Documentation/power/suspend-and-cpuhotplug.txt
+++ b/Documentation/power/suspend-and-cpuhotplug.rst
@@ -1,10 +1,15 @@
+====================================================================
Interaction of Suspend code (S3) with the CPU hotplug infrastructure
+====================================================================
- (C) 2011 - 2014 Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
+(C) 2011 - 2014 Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
-I. How does the regular CPU hotplug code differ from how the Suspend-to-RAM
- infrastructure uses it internally? And where do they share common code?
+I. Differences between CPU hotplug and Suspend-to-RAM
+======================================================
+
+How does the regular CPU hotplug code differ from how the Suspend-to-RAM
+infrastructure uses it internally? And where do they share common code?
Well, a picture is worth a thousand words... So ASCII art follows :-)
@@ -16,13 +21,13 @@ of describing where they take different paths and where they share code.
What happens when regular CPU hotplug and Suspend-to-RAM race with each other
is not depicted here.]
-On a high level, the suspend-resume cycle goes like this:
+On a high level, the suspend-resume cycle goes like this::
-|Freeze| -> |Disable nonboot| -> |Do suspend| -> |Enable nonboot| -> |Thaw |
-|tasks | | cpus | | | | cpus | |tasks|
+ |Freeze| -> |Disable nonboot| -> |Do suspend| -> |Enable nonboot| -> |Thaw |
+ |tasks | | cpus | | | | cpus | |tasks|
-More details follow:
+More details follow::
Suspend call path
-----------------
@@ -87,7 +92,9 @@ More details follow:
Resuming back is likewise, with the counterparts being (in the order of
execution during resume):
-* enable_nonboot_cpus() which involves:
+
+* enable_nonboot_cpus() which involves::
+
| Acquire cpu_add_remove_lock
| Decrease cpu_hotplug_disabled, thereby enabling regular cpu hotplug
| Call _cpu_up() [for all those cpus in the frozen_cpus mask, in a loop]
@@ -101,7 +108,7 @@ execution during resume):
It is to be noted here that the system_transition_mutex lock is acquired at the very
beginning, when we are just starting out to suspend, and then released only
-after the entire cycle is complete (i.e., suspend + resume).
+after the entire cycle is complete (i.e., suspend + resume)::
@@ -152,16 +159,16 @@ with the 'tasks_frozen' argument set to 1.
Important files and functions/entry points:
-------------------------------------------
+-------------------------------------------
-kernel/power/process.c : freeze_processes(), thaw_processes()
-kernel/power/suspend.c : suspend_prepare(), suspend_enter(), suspend_finish()
-kernel/cpu.c: cpu_[up|down](), _cpu_[up|down](), [disable|enable]_nonboot_cpus()
+- kernel/power/process.c : freeze_processes(), thaw_processes()
+- kernel/power/suspend.c : suspend_prepare(), suspend_enter(), suspend_finish()
+- kernel/cpu.c: cpu_[up|down](), _cpu_[up|down](), [disable|enable]_nonboot_cpus()
II. What are the issues involved in CPU hotplug?
- -------------------------------------------
+------------------------------------------------
There are some interesting situations involving CPU hotplug and microcode
update on the CPUs, as discussed below:
@@ -243,8 +250,11 @@ d. Handling microcode update during suspend/hibernate:
cycles).
-III. Are there any known problems when regular CPU hotplug and suspend race
- with each other?
+III. Known problems
+===================
+
+Are there any known problems when regular CPU hotplug and suspend race
+with each other?
Yes, they are listed below:
diff --git a/Documentation/power/suspend-and-interrupts.txt b/Documentation/power/suspend-and-interrupts.rst
similarity index 98%
rename from Documentation/power/suspend-and-interrupts.txt
rename to Documentation/power/suspend-and-interrupts.rst
index 8afb29a8604a..4cda6617709a 100644
--- a/Documentation/power/suspend-and-interrupts.txt
+++ b/Documentation/power/suspend-and-interrupts.rst
@@ -1,4 +1,6 @@
+====================================
System Suspend and Device Interrupts
+====================================
Copyright (C) 2014 Intel Corp.
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
diff --git a/Documentation/power/swsusp-and-swap-files.txt b/Documentation/power/swsusp-and-swap-files.rst
similarity index 83%
rename from Documentation/power/swsusp-and-swap-files.txt
rename to Documentation/power/swsusp-and-swap-files.rst
index f281886de490..a33a2919dbe4 100644
--- a/Documentation/power/swsusp-and-swap-files.txt
+++ b/Documentation/power/swsusp-and-swap-files.rst
@@ -1,4 +1,7 @@
+===============================================
Using swap files with software suspend (swsusp)
+===============================================
+
(C) 2006 Rafael J. Wysocki <rjw@sisk.pl>
The Linux kernel handles swap files almost in the same way as it handles swap
@@ -21,20 +24,20 @@ units.
In order to use a swap file with swsusp, you need to:
-1) Create the swap file and make it active, eg.
+1) Create the swap file and make it active, eg.::
-# dd if=/dev/zero of=<swap_file_path> bs=1024 count=<swap_file_size_in_k>
-# mkswap <swap_file_path>
-# swapon <swap_file_path>
+ # dd if=/dev/zero of=<swap_file_path> bs=1024 count=<swap_file_size_in_k>
+ # mkswap <swap_file_path>
+ # swapon <swap_file_path>
2) Use an application that will bmap the swap file with the help of the
FIBMAP ioctl and determine the location of the file's swap header, as the
offset, in <PAGE_SIZE> units, from the beginning of the partition which
holds the swap file.
-3) Add the following parameters to the kernel command line:
+3) Add the following parameters to the kernel command line::
-resume=<swap_file_partition> resume_offset=<swap_file_offset>
+ resume=<swap_file_partition> resume_offset=<swap_file_offset>
where <swap_file_partition> is the partition on which the swap file is located
and <swap_file_offset> is the offset of the swap header determined by the
@@ -46,7 +49,7 @@ OR
Use a userland suspend application that will set the partition and offset
with the help of the SNAPSHOT_SET_SWAP_AREA ioctl described in
-Documentation/power/userland-swsusp.txt (this is the only method to suspend
+Documentation/power/userland-swsusp.rst (this is the only method to suspend
to a swap file allowing the resume to be initiated from an initrd or initramfs
image).
diff --git a/Documentation/power/swsusp-dmcrypt.txt b/Documentation/power/swsusp-dmcrypt.rst
similarity index 67%
rename from Documentation/power/swsusp-dmcrypt.txt
rename to Documentation/power/swsusp-dmcrypt.rst
index b802fbfd95ef..426df59172cd 100644
--- a/Documentation/power/swsusp-dmcrypt.txt
+++ b/Documentation/power/swsusp-dmcrypt.rst
@@ -1,13 +1,15 @@
+=======================================
+How to use dm-crypt and swsusp together
+=======================================
+
Author: Andreas Steinmetz <ast@domdv.de>
-How to use dm-crypt and swsusp together:
-========================================
Some prerequisites:
You know how dm-crypt works. If not, visit the following web page:
http://www.saout.de/misc/dm-crypt/
-You have read Documentation/power/swsusp.txt and understand it.
+You have read Documentation/power/swsusp.rst and understand it.
You did read Documentation/admin-guide/initrd.rst and know how an initrd works.
You know how to create or how to modify an initrd.
@@ -29,23 +31,23 @@ a way that the swap device you suspend to/resume from has
always the same major/minor within the initrd as well as
within your running system. The easiest way to achieve this is
to always set up this swap device first with dmsetup, so that
-it will always look like the following:
+it will always look like the following::
-brw------- 1 root root 254, 0 Jul 28 13:37 /dev/mapper/swap0
+ brw------- 1 root root 254, 0 Jul 28 13:37 /dev/mapper/swap0
Now set up your kernel to use /dev/mapper/swap0 as the default
-resume partition, so your kernel .config contains:
+resume partition, so your kernel .config contains::
-CONFIG_PM_STD_PARTITION="/dev/mapper/swap0"
+ CONFIG_PM_STD_PARTITION="/dev/mapper/swap0"
Prepare your boot loader to use the initrd you will create or
modify. For lilo the simplest setup looks like the following
-lines:
+lines::
-image=/boot/vmlinuz
-initrd=/boot/initrd.gz
-label=linux
-append="root=/dev/ram0 init=/linuxrc rw"
+ image=/boot/vmlinuz
+ initrd=/boot/initrd.gz
+ label=linux
+ append="root=/dev/ram0 init=/linuxrc rw"
Finally you need to create or modify your initrd. Lets assume
you create an initrd that reads the required dm-crypt setup
@@ -53,66 +55,66 @@ from a pcmcia flash disk card. The card is formatted with an ext2
fs which resides on /dev/hde1 when the card is inserted. The
card contains at least the encrypted swap setup in a file
named "swapkey". /etc/fstab of your initrd contains something
-like the following:
+like the following::
-/dev/hda1 /mnt ext3 ro 0 0
-none /proc proc defaults,noatime,nodiratime 0 0
-none /sys sysfs defaults,noatime,nodiratime 0 0
+ /dev/hda1 /mnt ext3 ro 0 0
+ none /proc proc defaults,noatime,nodiratime 0 0
+ none /sys sysfs defaults,noatime,nodiratime 0 0
/dev/hda1 contains an unencrypted mini system that sets up all
of your crypto devices, again by reading the setup from the
pcmcia flash disk. What follows now is a /linuxrc for your
initrd that allows you to resume from encrypted swap and that
continues boot with your mini system on /dev/hda1 if resume
-does not happen:
+does not happen::
-#!/bin/sh
-PATH=/sbin:/bin:/usr/sbin:/usr/bin
-mount /proc
-mount /sys
-mapped=0
-noresume=`grep -c noresume /proc/cmdline`
-if [ "$*" != "" ]
-then
- noresume=1
-fi
-dmesg -n 1
-/sbin/cardmgr -q
-for i in 1 2 3 4 5 6 7 8 9 0
-do
- if [ -f /proc/ide/hde/media ]
+ #!/bin/sh
+ PATH=/sbin:/bin:/usr/sbin:/usr/bin
+ mount /proc
+ mount /sys
+ mapped=0
+ noresume=`grep -c noresume /proc/cmdline`
+ if [ "$*" != "" ]
then
+ noresume=1
+ fi
+ dmesg -n 1
+ /sbin/cardmgr -q
+ for i in 1 2 3 4 5 6 7 8 9 0
+ do
+ if [ -f /proc/ide/hde/media ]
+ then
+ usleep 500000
+ mount -t ext2 -o ro /dev/hde1 /mnt
+ if [ -f /mnt/swapkey ]
+ then
+ dmsetup create swap0 /mnt/swapkey > /dev/null 2>&1 && mapped=1
+ fi
+ umount /mnt
+ break
+ fi
usleep 500000
- mount -t ext2 -o ro /dev/hde1 /mnt
- if [ -f /mnt/swapkey ]
+ done
+ killproc /sbin/cardmgr
+ dmesg -n 6
+ if [ $mapped = 1 ]
+ then
+ if [ $noresume != 0 ]
then
- dmsetup create swap0 /mnt/swapkey > /dev/null 2>&1 && mapped=1
+ mkswap /dev/mapper/swap0 > /dev/null 2>&1
fi
- umount /mnt
- break
+ echo 254:0 > /sys/power/resume
+ dmsetup remove swap0
fi
- usleep 500000
-done
-killproc /sbin/cardmgr
-dmesg -n 6
-if [ $mapped = 1 ]
-then
- if [ $noresume != 0 ]
- then
- mkswap /dev/mapper/swap0 > /dev/null 2>&1
- fi
- echo 254:0 > /sys/power/resume
- dmsetup remove swap0
-fi
-umount /sys
-mount /mnt
-umount /proc
-cd /mnt
-pivot_root . mnt
-mount /proc
-umount -l /mnt
-umount /proc
-exec chroot . /sbin/init $* < dev/console > dev/console 2>&1
+ umount /sys
+ mount /mnt
+ umount /proc
+ cd /mnt
+ pivot_root . mnt
+ mount /proc
+ umount -l /mnt
+ umount /proc
+ exec chroot . /sbin/init $* < dev/console > dev/console 2>&1
Please don't mind the weird loop above, busybox's msh doesn't know
the let statement. Now, what is happening in the script?
diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.rst
similarity index 20%
rename from Documentation/power/swsusp.txt
rename to Documentation/power/swsusp.rst
index 236d1fb13640..d000312f6965 100644
--- a/Documentation/power/swsusp.txt
+++ b/Documentation/power/swsusp.rst
@@ -1,68 +1,76 @@
+============
+Swap suspend
+============
+
Some warnings, first.
- * BIG FAT WARNING *********************************************************
- *
- * If you touch anything on disk between suspend and resume...
- * ...kiss your data goodbye.
- *
- * If you do resume from initrd after your filesystems are mounted...
- * ...bye bye root partition.
- * [this is actually same case as above]
- *
- * If you have unsupported (*) devices using DMA, you may have some
- * problems. If your disk driver does not support suspend... (IDE does),
- * it may cause some problems, too. If you change kernel command line
- * between suspend and resume, it may do something wrong. If you change
- * your hardware while system is suspended... well, it was not good idea;
- * but it will probably only crash.
- *
- * (*) suspend/resume support is needed to make it safe.
- *
- * If you have any filesystems on USB devices mounted before software suspend,
- * they won't be accessible after resume and you may lose data, as though
- * you have unplugged the USB devices with mounted filesystems on them;
- * see the FAQ below for details. (This is not true for more traditional
- * power states like "standby", which normally don't turn USB off.)
+.. warning::
+
+ **BIG FAT WARNING**
+
+ If you touch anything on disk between suspend and resume...
+ ...kiss your data goodbye.
+
+ If you do resume from initrd after your filesystems are mounted...
+ ...bye bye root partition.
+
+ [this is actually same case as above]
+
+ If you have unsupported ( ) devices using DMA, you may have some
+ problems. If your disk driver does not support suspend... (IDE does),
+ it may cause some problems, too. If you change kernel command line
+ between suspend and resume, it may do something wrong. If you change
+ your hardware while system is suspended... well, it was not good idea;
+ but it will probably only crash.
+
+ ( ) suspend/resume support is needed to make it safe.
+
+ If you have any filesystems on USB devices mounted before software suspend,
+ they won't be accessible after resume and you may lose data, as though
+ you have unplugged the USB devices with mounted filesystems on them;
+ see the FAQ below for details. (This is not true for more traditional
+ power states like "standby", which normally don't turn USB off.)
Swap partition:
-You need to append resume=/dev/your_swap_partition to kernel command
-line or specify it using /sys/power/resume.
+ You need to append resume=/dev/your_swap_partition to kernel command
+ line or specify it using /sys/power/resume.
Swap file:
-If using a swapfile you can also specify a resume offset using
-resume_offset=<number> on the kernel command line or specify it
-in /sys/power/resume_offset.
+ If using a swapfile you can also specify a resume offset using
+ resume_offset=<number> on the kernel command line or specify it
+ in /sys/power/resume_offset.
-After preparing then you suspend by
+After preparing then you suspend by::
-echo shutdown > /sys/power/disk; echo disk > /sys/power/state
+ echo shutdown > /sys/power/disk; echo disk > /sys/power/state
-. If you feel ACPI works pretty well on your system, you might try
+- If you feel ACPI works pretty well on your system, you might try::
-echo platform > /sys/power/disk; echo disk > /sys/power/state
+ echo platform > /sys/power/disk; echo disk > /sys/power/state
-. If you would like to write hibernation image to swap and then suspend
-to RAM (provided your platform supports it), you can try
+- If you would like to write hibernation image to swap and then suspend
+ to RAM (provided your platform supports it), you can try::
-echo suspend > /sys/power/disk; echo disk > /sys/power/state
+ echo suspend > /sys/power/disk; echo disk > /sys/power/state
-. If you have SATA disks, you'll need recent kernels with SATA suspend
-support. For suspend and resume to work, make sure your disk drivers
-are built into kernel -- not modules. [There's way to make
-suspend/resume with modular disk drivers, see FAQ, but you probably
-should not do that.]
+- If you have SATA disks, you'll need recent kernels with SATA suspend
+ support. For suspend and resume to work, make sure your disk drivers
+ are built into kernel -- not modules. [There's way to make
+ suspend/resume with modular disk drivers, see FAQ, but you probably
+ should not do that.]
-If you want to limit the suspend image size to N bytes, do
+If you want to limit the suspend image size to N bytes, do::
-echo N > /sys/power/image_size
+ echo N > /sys/power/image_size
before suspend (it is limited to around 2/5 of available RAM by default).
-. The resume process checks for the presence of the resume device,
-if found, it then checks the contents for the hibernation image signature.
-If both are found, it resumes the hibernation image.
+- The resume process checks for the presence of the resume device,
+ if found, it then checks the contents for the hibernation image signature.
+ If both are found, it resumes the hibernation image.
+
+- The resume process may be triggered in two ways:
-. The resume process may be triggered in two ways:
1) During lateinit: If resume=/dev/your_swap_partition is specified on
the kernel command line, lateinit runs the resume process. If the
resume device has not been probed yet, the resume process fails and
@@ -73,26 +81,28 @@ If both are found, it resumes the hibernation image.
read-only) otherwise data may be corrupted.
Article about goals and implementation of Software Suspend for Linux
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+====================================================================
+
Author: Gábor Kuti
Last revised: 2003-10-20 by Pavel Machek
Idea and goals to achieve
+-------------------------
Nowadays it is common in several laptops that they have a suspend button. It
saves the state of the machine to a filesystem or to a partition and switches
to standby mode. Later resuming the machine the saved state is loaded back to
ram and the machine can continue its work. It has two real benefits. First we
save ourselves the time machine goes down and later boots up, energy costs
-are real high when running from batteries. The other gain is that we don't have to
-interrupt our programs so processes that are calculating something for a long
+are real high when running from batteries. The other gain is that we don't have
+to interrupt our programs so processes that are calculating something for a long
time shouldn't need to be written interruptible.
swsusp saves the state of the machine into active swaps and then reboots or
powerdowns. You must explicitly specify the swap partition to resume from with
-``resume='' kernel option. If signature is found it loads and restores saved
-state. If the option ``noresume'' is specified as a boot parameter, it skips
-the resuming. If the option ``hibernate=nocompress'' is specified as a boot
+`resume=` kernel option. If signature is found it loads and restores saved
+state. If the option `noresume` is specified as a boot parameter, it skips
+the resuming. If the option `hibernate=nocompress` is specified as a boot
parameter, it saves hibernation image without compression.
In the meantime while the system is suspended you should not add/remove any
@@ -104,151 +114,173 @@ Sleep states summary
There are three different interfaces you can use, /proc/acpi should
work like this:
-In a really perfect world:
-echo 1 > /proc/acpi/sleep # for standby
-echo 2 > /proc/acpi/sleep # for suspend to ram
-echo 3 > /proc/acpi/sleep # for suspend to ram, but with more power conservative
-echo 4 > /proc/acpi/sleep # for suspend to disk
-echo 5 > /proc/acpi/sleep # for shutdown unfriendly the system
+In a really perfect world::
-and perhaps
-echo 4b > /proc/acpi/sleep # for suspend to disk via s4bios
+ echo 1 > /proc/acpi/sleep # for standby
+ echo 2 > /proc/acpi/sleep # for suspend to ram
+ echo 3 > /proc/acpi/sleep # for suspend to ram, but with more power conservative
+ echo 4 > /proc/acpi/sleep # for suspend to disk
+ echo 5 > /proc/acpi/sleep # for shutdown unfriendly the system
+
+and perhaps::
+
+ echo 4b > /proc/acpi/sleep # for suspend to disk via s4bios
Frequently Asked Questions
==========================
-Q: well, suspending a server is IMHO a really stupid thing,
-but... (Diego Zuccato):
+Q:
+ well, suspending a server is IMHO a really stupid thing,
+ but... (Diego Zuccato):
-A: You bought new UPS for your server. How do you install it without
-bringing machine down? Suspend to disk, rearrange power cables,
-resume.
-
-You have your server on UPS. Power died, and UPS is indicating 30
-seconds to failure. What do you do? Suspend to disk.
+A:
+ You bought new UPS for your server. How do you install it without
+ bringing machine down? Suspend to disk, rearrange power cables,
+ resume.
+ You have your server on UPS. Power died, and UPS is indicating 30
+ seconds to failure. What do you do? Suspend to disk.
-Q: Maybe I'm missing something, but why don't the regular I/O paths work?
-A: We do use the regular I/O paths. However we cannot restore the data
-to its original location as we load it. That would create an
-inconsistent kernel state which would certainly result in an oops.
-Instead, we load the image into unused memory and then atomically copy
-it back to it original location. This implies, of course, a maximum
-image size of half the amount of memory.
+Q:
+ Maybe I'm missing something, but why don't the regular I/O paths work?
-There are two solutions to this:
+A:
+ We do use the regular I/O paths. However we cannot restore the data
+ to its original location as we load it. That would create an
+ inconsistent kernel state which would certainly result in an oops.
+ Instead, we load the image into unused memory and then atomically copy
+ it back to it original location. This implies, of course, a maximum
+ image size of half the amount of memory.
-* require half of memory to be free during suspend. That way you can
-read "new" data onto free spots, then cli and copy
+ There are two solutions to this:
-* assume we had special "polling" ide driver that only uses memory
-between 0-640KB. That way, I'd have to make sure that 0-640KB is free
-during suspending, but otherwise it would work...
+ * require half of memory to be free during suspend. That way you can
+ read "new" data onto free spots, then cli and copy
-suspend2 shares this fundamental limitation, but does not include user
-data and disk caches into "used memory" by saving them in
-advance. That means that the limitation goes away in practice.
+ * assume we had special "polling" ide driver that only uses memory
+ between 0-640KB. That way, I'd have to make sure that 0-640KB is free
+ during suspending, but otherwise it would work...
-Q: Does linux support ACPI S4?
+ suspend2 shares this fundamental limitation, but does not include user
+ data and disk caches into "used memory" by saving them in
+ advance. That means that the limitation goes away in practice.
-A: Yes. That's what echo platform > /sys/power/disk does.
+Q:
+ Does linux support ACPI S4?
-Q: What is 'suspend2'?
+A:
+ Yes. That's what echo platform > /sys/power/disk does.
-A: suspend2 is 'Software Suspend 2', a forked implementation of
-suspend-to-disk which is available as separate patches for 2.4 and 2.6
-kernels from swsusp.sourceforge.net. It includes support for SMP, 4GB
-highmem and preemption. It also has a extensible architecture that
-allows for arbitrary transformations on the image (compression,
-encryption) and arbitrary backends for writing the image (eg to swap
-or an NFS share[Work In Progress]). Questions regarding suspend2
-should be sent to the mailing list available through the suspend2
-website, and not to the Linux Kernel Mailing List. We are working
-toward merging suspend2 into the mainline kernel.
+Q:
+ What is 'suspend2'?
-Q: What is the freezing of tasks and why are we using it?
+A:
+ suspend2 is 'Software Suspend 2', a forked implementation of
+ suspend-to-disk which is available as separate patches for 2.4 and 2.6
+ kernels from swsusp.sourceforge.net. It includes support for SMP, 4GB
+ highmem and preemption. It also has a extensible architecture that
+ allows for arbitrary transformations on the image (compression,
+ encryption) and arbitrary backends for writing the image (eg to swap
+ or an NFS share[Work In Progress]). Questions regarding suspend2
+ should be sent to the mailing list available through the suspend2
+ website, and not to the Linux Kernel Mailing List. We are working
+ toward merging suspend2 into the mainline kernel.
+
+Q:
+ What is the freezing of tasks and why are we using it?
-A: The freezing of tasks is a mechanism by which user space processes and some
-kernel threads are controlled during hibernation or system-wide suspend (on some
-architectures). See freezing-of-tasks.txt for details.
+A:
+ The freezing of tasks is a mechanism by which user space processes and some
+ kernel threads are controlled during hibernation or system-wide suspend (on some
+ architectures). See freezing-of-tasks.txt for details.
-Q: What is the difference between "platform" and "shutdown"?
+Q:
+ What is the difference between "platform" and "shutdown"?
A:
+ shutdown:
+ save state in linux, then tell bios to powerdown
-shutdown: save state in linux, then tell bios to powerdown
+ platform:
+ save state in linux, then tell bios to powerdown and blink
+ "suspended led"
-platform: save state in linux, then tell bios to powerdown and blink
- "suspended led"
+ "platform" is actually right thing to do where supported, but
+ "shutdown" is most reliable (except on ACPI systems).
-"platform" is actually right thing to do where supported, but
-"shutdown" is most reliable (except on ACPI systems).
+Q:
+ I do not understand why you have such strong objections to idea of
+ selective suspend.
-Q: I do not understand why you have such strong objections to idea of
-selective suspend.
+A:
+ Do selective suspend during runtime power management, that's okay. But
+ it's useless for suspend-to-disk. (And I do not see how you could use
+ it for suspend-to-ram, I hope you do not want that).
-A: Do selective suspend during runtime power management, that's okay. But
-it's useless for suspend-to-disk. (And I do not see how you could use
-it for suspend-to-ram, I hope you do not want that).
+ Lets see, so you suggest to
-Lets see, so you suggest to
+ * SUSPEND all but swap device and parents
+ * Snapshot
+ * Write image to disk
+ * SUSPEND swap device and parents
+ * Powerdown
-* SUSPEND all but swap device and parents
-* Snapshot
-* Write image to disk
-* SUSPEND swap device and parents
-* Powerdown
+ Oh no, that does not work, if swap device or its parents uses DMA,
+ you've corrupted data. You'd have to do
-Oh no, that does not work, if swap device or its parents uses DMA,
-you've corrupted data. You'd have to do
+ * SUSPEND all but swap device and parents
+ * FREEZE swap device and parents
+ * Snapshot
+ * UNFREEZE swap device and parents
+ * Write
+ * SUSPEND swap device and parents
-* SUSPEND all but swap device and parents
-* FREEZE swap device and parents
-* Snapshot
-* UNFREEZE swap device and parents
-* Write
-* SUSPEND swap device and parents
+ Which means that you still need that FREEZE state, and you get more
+ complicated code. (And I have not yet introduce details like system
+ devices).
-Which means that you still need that FREEZE state, and you get more
-complicated code. (And I have not yet introduce details like system
-devices).
+Q:
+ There don't seem to be any generally useful behavioral
+ distinctions between SUSPEND and FREEZE.
-Q: There don't seem to be any generally useful behavioral
-distinctions between SUSPEND and FREEZE.
+A:
+ Doing SUSPEND when you are asked to do FREEZE is always correct,
+ but it may be unnecessarily slow. If you want your driver to stay simple,
+ slowness may not matter to you. It can always be fixed later.
-A: Doing SUSPEND when you are asked to do FREEZE is always correct,
-but it may be unnecessarily slow. If you want your driver to stay simple,
-slowness may not matter to you. It can always be fixed later.
+ For devices like disk it does matter, you do not want to spindown for
+ FREEZE.
-For devices like disk it does matter, you do not want to spindown for
-FREEZE.
+Q:
+ After resuming, system is paging heavily, leading to very bad interactivity.
-Q: After resuming, system is paging heavily, leading to very bad interactivity.
+A:
+ Try running::
-A: Try running
+ cat /proc/[0-9]*/maps | grep / | sed 's:.* /:/:' | sort -u | while read file
+ do
+ test -f "$file" && cat "$file" > /dev/null
+ done
-cat /proc/[0-9]*/maps | grep / | sed 's:.* /:/:' | sort -u | while read file
-do
- test -f "$file" && cat "$file" > /dev/null
-done
+ after resume. swapoff -a; swapon -a may also be useful.
-after resume. swapoff -a; swapon -a may also be useful.
+Q:
+ What happens to devices during swsusp? They seem to be resumed
+ during system suspend?
-Q: What happens to devices during swsusp? They seem to be resumed
-during system suspend?
+A:
+ That's correct. We need to resume them if we want to write image to
+ disk. Whole sequence goes like
-A: That's correct. We need to resume them if we want to write image to
-disk. Whole sequence goes like
+ **Suspend part**
- Suspend part
- ~~~~~~~~~~~~
running system, user asks for suspend-to-disk
user processes are stopped
suspend(PMSG_FREEZE): devices are frozen so that they don't interfere
- with state snapshot
+ with state snapshot
state snapshot: copy of whole used memory is taken with interrupts disabled
@@ -260,18 +292,19 @@ disk. Whole sequence goes like
turn the power off
- Resume part
- ~~~~~~~~~~~
+ **Resume part**
+
(is actually pretty similar)
running system, user asks for suspend-to-disk
- user processes are stopped (in common case there are none, but with resume-from-initrd, no one knows)
+ user processes are stopped (in common case there are none,
+ but with resume-from-initrd, no one knows)
read image from disk
suspend(PMSG_FREEZE): devices are frozen so that they don't interfere
- with image restoration
+ with image restoration
image restoration: rewrite memory with image
@@ -279,87 +312,103 @@ disk. Whole sequence goes like
thaw all user processes
-Q: What is this 'Encrypt suspend image' for?
-
-A: First of all: it is not a replacement for dm-crypt encrypted swap.
-It cannot protect your computer while it is suspended. Instead it does
-protect from leaking sensitive data after resume from suspend.
-
-Think of the following: you suspend while an application is running
-that keeps sensitive data in memory. The application itself prevents
-the data from being swapped out. Suspend, however, must write these
-data to swap to be able to resume later on. Without suspend encryption
-your sensitive data are then stored in plaintext on disk. This means
-that after resume your sensitive data are accessible to all
-applications having direct access to the swap device which was used
-for suspend. If you don't need swap after resume these data can remain
-on disk virtually forever. Thus it can happen that your system gets
-broken in weeks later and sensitive data which you thought were
-encrypted and protected are retrieved and stolen from the swap device.
-To prevent this situation you should use 'Encrypt suspend image'.
-
-During suspend a temporary key is created and this key is used to
-encrypt the data written to disk. When, during resume, the data was
-read back into memory the temporary key is destroyed which simply
-means that all data written to disk during suspend are then
-inaccessible so they can't be stolen later on. The only thing that
-you must then take care of is that you call 'mkswap' for the swap
-partition used for suspend as early as possible during regular
-boot. This asserts that any temporary key from an oopsed suspend or
-from a failed or aborted resume is erased from the swap device.
-
-As a rule of thumb use encrypted swap to protect your data while your
-system is shut down or suspended. Additionally use the encrypted
-suspend image to prevent sensitive data from being stolen after
-resume.
-
-Q: Can I suspend to a swap file?
-
-A: Generally, yes, you can. However, it requires you to use the "resume=" and
-"resume_offset=" kernel command line parameters, so the resume from a swap file
-cannot be initiated from an initrd or initramfs image. See
-swsusp-and-swap-files.txt for details.
-
-Q: Is there a maximum system RAM size that is supported by swsusp?
-
-A: It should work okay with highmem.
-
-Q: Does swsusp (to disk) use only one swap partition or can it use
-multiple swap partitions (aggregate them into one logical space)?
-
-A: Only one swap partition, sorry.
-
-Q: If my application(s) causes lots of memory & swap space to be used
-(over half of the total system RAM), is it correct that it is likely
-to be useless to try to suspend to disk while that app is running?
-
-A: No, it should work okay, as long as your app does not mlock()
-it. Just prepare big enough swap partition.
-
-Q: What information is useful for debugging suspend-to-disk problems?
-
-A: Well, last messages on the screen are always useful. If something
-is broken, it is usually some kernel driver, therefore trying with as
-little as possible modules loaded helps a lot. I also prefer people to
-suspend from console, preferably without X running. Booting with
-init=/bin/bash, then swapon and starting suspend sequence manually
-usually does the trick. Then it is good idea to try with latest
-vanilla kernel.
-
-Q: How can distributions ship a swsusp-supporting kernel with modular
-disk drivers (especially SATA)?
-
-A: Well, it can be done, load the drivers, then do echo into
-/sys/power/resume file from initrd. Be sure not to mount
-anything, not even read-only mount, or you are going to lose your
-data.
-
-Q: How do I make suspend more verbose?
-
-A: If you want to see any non-error kernel messages on the virtual
-terminal the kernel switches to during suspend, you have to set the
-kernel console loglevel to at least 4 (KERN_WARNING), for example by
-doing
+Q:
+ What is this 'Encrypt suspend image' for?
+
+A:
+ First of all: it is not a replacement for dm-crypt encrypted swap.
+ It cannot protect your computer while it is suspended. Instead it does
+ protect from leaking sensitive data after resume from suspend.
+
+ Think of the following: you suspend while an application is running
+ that keeps sensitive data in memory. The application itself prevents
+ the data from being swapped out. Suspend, however, must write these
+ data to swap to be able to resume later on. Without suspend encryption
+ your sensitive data are then stored in plaintext on disk. This means
+ that after resume your sensitive data are accessible to all
+ applications having direct access to the swap device which was used
+ for suspend. If you don't need swap after resume these data can remain
+ on disk virtually forever. Thus it can happen that your system gets
+ broken in weeks later and sensitive data which you thought were
+ encrypted and protected are retrieved and stolen from the swap device.
+ To prevent this situation you should use 'Encrypt suspend image'.
+
+ During suspend a temporary key is created and this key is used to
+ encrypt the data written to disk. When, during resume, the data was
+ read back into memory the temporary key is destroyed which simply
+ means that all data written to disk during suspend are then
+ inaccessible so they can't be stolen later on. The only thing that
+ you must then take care of is that you call 'mkswap' for the swap
+ partition used for suspend as early as possible during regular
+ boot. This asserts that any temporary key from an oopsed suspend or
+ from a failed or aborted resume is erased from the swap device.
+
+ As a rule of thumb use encrypted swap to protect your data while your
+ system is shut down or suspended. Additionally use the encrypted
+ suspend image to prevent sensitive data from being stolen after
+ resume.
+
+Q:
+ Can I suspend to a swap file?
+
+A:
+ Generally, yes, you can. However, it requires you to use the "resume=" and
+ "resume_offset=" kernel command line parameters, so the resume from a swap file
+ cannot be initiated from an initrd or initramfs image. See
+ swsusp-and-swap-files.txt for details.
+
+Q:
+ Is there a maximum system RAM size that is supported by swsusp?
+
+A:
+ It should work okay with highmem.
+
+Q:
+ Does swsusp (to disk) use only one swap partition or can it use
+ multiple swap partitions (aggregate them into one logical space)?
+
+A:
+ Only one swap partition, sorry.
+
+Q:
+ If my application(s) causes lots of memory & swap space to be used
+ (over half of the total system RAM), is it correct that it is likely
+ to be useless to try to suspend to disk while that app is running?
+
+A:
+ No, it should work okay, as long as your app does not mlock()
+ it. Just prepare big enough swap partition.
+
+Q:
+ What information is useful for debugging suspend-to-disk problems?
+
+A:
+ Well, last messages on the screen are always useful. If something
+ is broken, it is usually some kernel driver, therefore trying with as
+ little as possible modules loaded helps a lot. I also prefer people to
+ suspend from console, preferably without X running. Booting with
+ init=/bin/bash, then swapon and starting suspend sequence manually
+ usually does the trick. Then it is good idea to try with latest
+ vanilla kernel.
+
+Q:
+ How can distributions ship a swsusp-supporting kernel with modular
+ disk drivers (especially SATA)?
+
+A:
+ Well, it can be done, load the drivers, then do echo into
+ /sys/power/resume file from initrd. Be sure not to mount
+ anything, not even read-only mount, or you are going to lose your
+ data.
+
+Q:
+ How do I make suspend more verbose?
+
+A:
+ If you want to see any non-error kernel messages on the virtual
+ terminal the kernel switches to during suspend, you have to set the
+ kernel console loglevel to at least 4 (KERN_WARNING), for example by
+ doing::
# save the old loglevel
read LOGLEVEL DUMMY < /proc/sys/kernel/printk
@@ -387,60 +436,66 @@ doing
echo $LOGLEVEL > /proc/sys/kernel/printk
exit $RET
-Q: Is this true that if I have a mounted filesystem on a USB device and
-I suspend to disk, I can lose data unless the filesystem has been mounted
-with "sync"?
-
-A: That's right ... if you disconnect that device, you may lose data.
-In fact, even with "-o sync" you can lose data if your programs have
-information in buffers they haven't written out to a disk you disconnect,
-or if you disconnect before the device finished saving data you wrote.
-
-Software suspend normally powers down USB controllers, which is equivalent
-to disconnecting all USB devices attached to your system.
-
-Your system might well support low-power modes for its USB controllers
-while the system is asleep, maintaining the connection, using true sleep
-modes like "suspend-to-RAM" or "standby". (Don't write "disk" to the
-/sys/power/state file; write "standby" or "mem".) We've not seen any
-hardware that can use these modes through software suspend, although in
-theory some systems might support "platform" modes that won't break the
-USB connections.
-
-Remember that it's always a bad idea to unplug a disk drive containing a
-mounted filesystem. That's true even when your system is asleep! The
-safest thing is to unmount all filesystems on removable media (such USB,
-Firewire, CompactFlash, MMC, external SATA, or even IDE hotplug bays)
-before suspending; then remount them after resuming.
-
-There is a work-around for this problem. For more information, see
-Documentation/driver-api/usb/persist.rst.
-
-Q: Can I suspend-to-disk using a swap partition under LVM?
-
-A: Yes and No. You can suspend successfully, but the kernel will not be able
-to resume on its own. You need an initramfs that can recognize the resume
-situation, activate the logical volume containing the swap volume (but not
-touch any filesystems!), and eventually call
-
-echo -n "$major:$minor" > /sys/power/resume
-
-where $major and $minor are the respective major and minor device numbers of
-the swap volume.
-
-uswsusp works with LVM, too. See http://suspend.sourceforge.net/
-
-Q: I upgraded the kernel from 2.6.15 to 2.6.16. Both kernels were
-compiled with the similar configuration files. Anyway I found that
-suspend to disk (and resume) is much slower on 2.6.16 compared to
-2.6.15. Any idea for why that might happen or how can I speed it up?
-
-A: This is because the size of the suspend image is now greater than
-for 2.6.15 (by saving more data we can get more responsive system
-after resume).
-
-There's the /sys/power/image_size knob that controls the size of the
-image. If you set it to 0 (eg. by echo 0 > /sys/power/image_size as
-root), the 2.6.15 behavior should be restored. If it is still too
-slow, take a look at suspend.sf.net -- userland suspend is faster and
-supports LZF compression to speed it up further.
+Q:
+ Is this true that if I have a mounted filesystem on a USB device and
+ I suspend to disk, I can lose data unless the filesystem has been mounted
+ with "sync"?
+
+A:
+ That's right ... if you disconnect that device, you may lose data.
+ In fact, even with "-o sync" you can lose data if your programs have
+ information in buffers they haven't written out to a disk you disconnect,
+ or if you disconnect before the device finished saving data you wrote.
+
+ Software suspend normally powers down USB controllers, which is equivalent
+ to disconnecting all USB devices attached to your system.
+
+ Your system might well support low-power modes for its USB controllers
+ while the system is asleep, maintaining the connection, using true sleep
+ modes like "suspend-to-RAM" or "standby". (Don't write "disk" to the
+ /sys/power/state file; write "standby" or "mem".) We've not seen any
+ hardware that can use these modes through software suspend, although in
+ theory some systems might support "platform" modes that won't break the
+ USB connections.
+
+ Remember that it's always a bad idea to unplug a disk drive containing a
+ mounted filesystem. That's true even when your system is asleep! The
+ safest thing is to unmount all filesystems on removable media (such USB,
+ Firewire, CompactFlash, MMC, external SATA, or even IDE hotplug bays)
+ before suspending; then remount them after resuming.
+
+ There is a work-around for this problem. For more information, see
+ Documentation/driver-api/usb/persist.rst.
+
+Q:
+ Can I suspend-to-disk using a swap partition under LVM?
+
+A:
+ Yes and No. You can suspend successfully, but the kernel will not be able
+ to resume on its own. You need an initramfs that can recognize the resume
+ situation, activate the logical volume containing the swap volume (but not
+ touch any filesystems!), and eventually call::
+
+ echo -n "$major:$minor" > /sys/power/resume
+
+ where $major and $minor are the respective major and minor device numbers of
+ the swap volume.
+
+ uswsusp works with LVM, too. See http://suspend.sourceforge.net/
+
+Q:
+ I upgraded the kernel from 2.6.15 to 2.6.16. Both kernels were
+ compiled with the similar configuration files. Anyway I found that
+ suspend to disk (and resume) is much slower on 2.6.16 compared to
+ 2.6.15. Any idea for why that might happen or how can I speed it up?
+
+A:
+ This is because the size of the suspend image is now greater than
+ for 2.6.15 (by saving more data we can get more responsive system
+ after resume).
+
+ There's the /sys/power/image_size knob that controls the size of the
+ image. If you set it to 0 (eg. by echo 0 > /sys/power/image_size as
+ root), the 2.6.15 behavior should be restored. If it is still too
+ slow, take a look at suspend.sf.net -- userland suspend is faster and
+ supports LZF compression to speed it up further.
diff --git a/Documentation/power/tricks.txt b/Documentation/power/tricks.rst
similarity index 93%
rename from Documentation/power/tricks.txt
rename to Documentation/power/tricks.rst
index a1b8f7249f4c..ca787f142c3f 100644
--- a/Documentation/power/tricks.txt
+++ b/Documentation/power/tricks.rst
@@ -1,5 +1,7 @@
- swsusp/S3 tricks
- ~~~~~~~~~~~~~~~~
+================
+swsusp/S3 tricks
+================
+
Pavel Machek <pavel@ucw.cz>
If you want to trick swsusp/S3 into working, you might want to try:
diff --git a/Documentation/power/userland-swsusp.txt b/Documentation/power/userland-swsusp.rst
similarity index 85%
rename from Documentation/power/userland-swsusp.txt
rename to Documentation/power/userland-swsusp.rst
index bbfcd1bbedc5..a0fa51bb1a4d 100644
--- a/Documentation/power/userland-swsusp.txt
+++ b/Documentation/power/userland-swsusp.rst
@@ -1,4 +1,7 @@
+=====================================================
Documentation for userland software suspend interface
+=====================================================
+
(C) 2006 Rafael J. Wysocki <rjw@sisk.pl>
First, the warnings at the beginning of swsusp.txt still apply.
@@ -30,13 +33,16 @@ called.
The ioctl() commands recognized by the device are:
-SNAPSHOT_FREEZE - freeze user space processes (the current process is
+SNAPSHOT_FREEZE
+ freeze user space processes (the current process is
not frozen); this is required for SNAPSHOT_CREATE_IMAGE
and SNAPSHOT_ATOMIC_RESTORE to succeed
-SNAPSHOT_UNFREEZE - thaw user space processes frozen by SNAPSHOT_FREEZE
+SNAPSHOT_UNFREEZE
+ thaw user space processes frozen by SNAPSHOT_FREEZE
-SNAPSHOT_CREATE_IMAGE - create a snapshot of the system memory; the
+SNAPSHOT_CREATE_IMAGE
+ create a snapshot of the system memory; the
last argument of ioctl() should be a pointer to an int variable,
the value of which will indicate whether the call returned after
creating the snapshot (1) or after restoring the system memory state
@@ -45,48 +51,59 @@ SNAPSHOT_CREATE_IMAGE - create a snapshot of the system memory; the
has been created the read() operation can be used to transfer
it out of the kernel
-SNAPSHOT_ATOMIC_RESTORE - restore the system memory state from the
+SNAPSHOT_ATOMIC_RESTORE
+ restore the system memory state from the
uploaded snapshot image; before calling it you should transfer
the system memory snapshot back to the kernel using the write()
operation; this call will not succeed if the snapshot
image is not available to the kernel
-SNAPSHOT_FREE - free memory allocated for the snapshot image
+SNAPSHOT_FREE
+ free memory allocated for the snapshot image
-SNAPSHOT_PREF_IMAGE_SIZE - set the preferred maximum size of the image
+SNAPSHOT_PREF_IMAGE_SIZE
+ set the preferred maximum size of the image
(the kernel will do its best to ensure the image size will not exceed
this number, but if it turns out to be impossible, the kernel will
create the smallest image possible)
-SNAPSHOT_GET_IMAGE_SIZE - return the actual size of the hibernation image
+SNAPSHOT_GET_IMAGE_SIZE
+ return the actual size of the hibernation image
-SNAPSHOT_AVAIL_SWAP_SIZE - return the amount of available swap in bytes (the
+SNAPSHOT_AVAIL_SWAP_SIZE
+ return the amount of available swap in bytes (the
last argument should be a pointer to an unsigned int variable that will
contain the result if the call is successful).
-SNAPSHOT_ALLOC_SWAP_PAGE - allocate a swap page from the resume partition
+SNAPSHOT_ALLOC_SWAP_PAGE
+ allocate a swap page from the resume partition
(the last argument should be a pointer to a loff_t variable that
will contain the swap page offset if the call is successful)
-SNAPSHOT_FREE_SWAP_PAGES - free all swap pages allocated by
+SNAPSHOT_FREE_SWAP_PAGES
+ free all swap pages allocated by
SNAPSHOT_ALLOC_SWAP_PAGE
-SNAPSHOT_SET_SWAP_AREA - set the resume partition and the offset (in <PAGE_SIZE>
+SNAPSHOT_SET_SWAP_AREA
+ set the resume partition and the offset (in <PAGE_SIZE>
units) from the beginning of the partition at which the swap header is
located (the last ioctl() argument should point to a struct
resume_swap_area, as defined in kernel/power/suspend_ioctls.h,
containing the resume device specification and the offset); for swap
partitions the offset is always 0, but it is different from zero for
- swap files (see Documentation/power/swsusp-and-swap-files.txt for
+ swap files (see Documentation/power/swsusp-and-swap-files.rst for
details).
-SNAPSHOT_PLATFORM_SUPPORT - enable/disable the hibernation platform support,
+SNAPSHOT_PLATFORM_SUPPORT
+ enable/disable the hibernation platform support,
depending on the argument value (enable, if the argument is nonzero)
-SNAPSHOT_POWER_OFF - make the kernel transition the system to the hibernation
+SNAPSHOT_POWER_OFF
+ make the kernel transition the system to the hibernation
state (eg. ACPI S4) using the platform (eg. ACPI) driver
-SNAPSHOT_S2RAM - suspend to RAM; using this call causes the kernel to
+SNAPSHOT_S2RAM
+ suspend to RAM; using this call causes the kernel to
immediately enter the suspend-to-RAM state, so this call must always
be preceded by the SNAPSHOT_FREEZE call and it is also necessary
to use the SNAPSHOT_UNFREEZE call after the system wakes up. This call
@@ -98,10 +115,11 @@ SNAPSHOT_S2RAM - suspend to RAM; using this call causes the kernel to
The device's read() operation can be used to transfer the snapshot image from
the kernel. It has the following limitations:
+
- you cannot read() more than one virtual memory page at a time
- read()s across page boundaries are impossible (ie. if you read() 1/2 of
- a page in the previous call, you will only be able to read()
- _at_ _most_ 1/2 of the page in the next call)
+ a page in the previous call, you will only be able to read()
+ **at most** 1/2 of the page in the next call)
The device's write() operation is used for uploading the system memory snapshot
into the kernel. It has the same limitations as the read() operation.
@@ -143,8 +161,10 @@ preferably using mlockall(), before calling SNAPSHOT_FREEZE.
The suspending utility MUST check the value stored by SNAPSHOT_CREATE_IMAGE
in the memory location pointed to by the last argument of ioctl() and proceed
in accordance with it:
+
1. If the value is 1 (ie. the system memory snapshot has just been
created and the system is ready for saving it):
+
(a) The suspending utility MUST NOT close the snapshot device
_unless_ the whole suspend procedure is to be cancelled, in
which case, if the snapshot image has already been saved, the
@@ -158,6 +178,7 @@ in accordance with it:
called. However, it MAY mount a file system that was not
mounted at that time and perform some operations on it (eg.
use it for saving the image).
+
2. If the value is 0 (ie. the system state has just been restored from
the snapshot image), the suspending utility MUST close the snapshot
device. Afterwards it will be treated as a regular userland process,
diff --git a/Documentation/power/video.txt b/Documentation/power/video.rst
similarity index 56%
rename from Documentation/power/video.txt
rename to Documentation/power/video.rst
index 3e6272bc4472..337a2ba9f32f 100644
--- a/Documentation/power/video.txt
+++ b/Documentation/power/video.rst
@@ -1,7 +1,8 @@
+===========================
+Video issues with S3 resume
+===========================
- Video issues with S3 resume
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~
- 2003-2006, Pavel Machek
+2003-2006, Pavel Machek
During S3 resume, hardware needs to be reinitialized. For most
devices, this is easy, and kernel driver knows how to do
@@ -41,37 +42,37 @@ There are a few types of systems where video works after S3 resume:
(1) systems where video state is preserved over S3.
(2) systems where it is possible to call the video BIOS during S3
- resume. Unfortunately, it is not correct to call the video BIOS at
- that point, but it happens to work on some machines. Use
- acpi_sleep=s3_bios.
+ resume. Unfortunately, it is not correct to call the video BIOS at
+ that point, but it happens to work on some machines. Use
+ acpi_sleep=s3_bios.
(3) systems that initialize video card into vga text mode and where
- the BIOS works well enough to be able to set video mode. Use
- acpi_sleep=s3_mode on these.
+ the BIOS works well enough to be able to set video mode. Use
+ acpi_sleep=s3_mode on these.
(4) on some systems s3_bios kicks video into text mode, and
- acpi_sleep=s3_bios,s3_mode is needed.
+ acpi_sleep=s3_bios,s3_mode is needed.
(5) radeon systems, where X can soft-boot your video card. You'll need
- a new enough X, and a plain text console (no vesafb or radeonfb). See
- http://www.doesi.gmxhome.de/linux/tm800s3/s3.html for more information.
- Alternatively, you should use vbetool (6) instead.
+ a new enough X, and a plain text console (no vesafb or radeonfb). See
+ http://www.doesi.gmxhome.de/linux/tm800s3/s3.html for more information.
+ Alternatively, you should use vbetool (6) instead.
(6) other radeon systems, where vbetool is enough to bring system back
- to life. It needs text console to be working. Do vbetool vbestate
- save > /tmp/delme; echo 3 > /proc/acpi/sleep; vbetool post; vbetool
- vbestate restore < /tmp/delme; setfont <whatever>, and your video
- should work.
+ to life. It needs text console to be working. Do vbetool vbestate
+ save > /tmp/delme; echo 3 > /proc/acpi/sleep; vbetool post; vbetool
+ vbestate restore < /tmp/delme; setfont <whatever>, and your video
+ should work.
(7) on some systems, it is possible to boot most of kernel, and then
- POSTing bios works. Ole Rohne has patch to do just that at
- http://dev.gentoo.org/~marineam/patch-radeonfb-2.6.11-rc2-mm2.
+ POSTing bios works. Ole Rohne has patch to do just that at
+ http://dev.gentoo.org/~marineam/patch-radeonfb-2.6.11-rc2-mm2.
-(8) on some systems, you can use the video_post utility and or
- do echo 3 > /sys/power/state && /usr/sbin/video_post - which will
- initialize the display in console mode. If you are in X, you can switch
- to a virtual terminal and back to X using CTRL+ALT+F1 - CTRL+ALT+F7 to get
- the display working in graphical mode again.
+(8) on some systems, you can use the video_post utility and or
+ do echo 3 > /sys/power/state && /usr/sbin/video_post - which will
+ initialize the display in console mode. If you are in X, you can switch
+ to a virtual terminal and back to X using CTRL+ALT+F1 - CTRL+ALT+F7 to get
+ the display working in graphical mode again.
Now, if you pass acpi_sleep=something, and it does not work with your
bios, you'll get a hard crash during resume. Be careful. Also it is
@@ -87,99 +88,126 @@ chance of working.
Table of known working notebooks:
+
+=============================== ===============================================
Model hack (or "how to do it")
-------------------------------------------------------------------------------
+=============================== ===============================================
Acer Aspire 1406LC ole's late BIOS init (7), turn off DRI
Acer TM 230 s3_bios (2)
Acer TM 242FX vbetool (6)
Acer TM C110 video_post (8)
-Acer TM C300 vga=normal (only suspend on console, not in X), vbetool (6) or video_post (8)
+Acer TM C300 vga=normal (only suspend on console, not in X),
+ vbetool (6) or video_post (8)
Acer TM 4052LCi s3_bios (2)
Acer TM 636Lci s3_bios,s3_mode (4)
-Acer TM 650 (Radeon M7) vga=normal plus boot-radeon (5) gets text console back
-Acer TM 660 ??? (*)
-Acer TM 800 vga=normal, X patches, see webpage (5) or vbetool (6)
-Acer TM 803 vga=normal, X patches, see webpage (5) or vbetool (6)
+Acer TM 650 (Radeon M7) vga=normal plus boot-radeon (5) gets text
+ console back
+Acer TM 660 ??? [#f1]_
+Acer TM 800 vga=normal, X patches, see webpage (5)
+ or vbetool (6)
+Acer TM 803 vga=normal, X patches, see webpage (5)
+ or vbetool (6)
Acer TM 803LCi vga=normal, vbetool (6)
Arima W730a vbetool needed (6)
-Asus L2400D s3_mode (3)(***) (S1 also works OK)
+Asus L2400D s3_mode (3) [#f2]_ (S1 also works OK)
Asus L3350M (SiS 740) (6)
Asus L3800C (Radeon M7) s3_bios (2) (S1 also works OK)
-Asus M6887Ne vga=normal, s3_bios (2), use radeon driver instead of fglrx in x.org
+Asus M6887Ne vga=normal, s3_bios (2), use radeon driver
+ instead of fglrx in x.org
Athlon64 desktop prototype s3_bios (2)
-Compal CL-50 ??? (*)
+Compal CL-50 ??? [#f1]_
Compaq Armada E500 - P3-700 none (1) (S1 also works OK)
Compaq Evo N620c vga=normal, s3_bios (2)
Dell 600m, ATI R250 Lf none (1), but needs xorg-x11-6.8.1.902-1
Dell D600, ATI RV250 vga=normal and X, or try vbestate (6)
-Dell D610 vga=normal and X (possibly vbestate (6) too, but not tested)
-Dell Inspiron 4000 ??? (*)
-Dell Inspiron 500m ??? (*)
+Dell D610 vga=normal and X (possibly vbestate (6) too,
+ but not tested)
+Dell Inspiron 4000 ??? [#f1]_
+Dell Inspiron 500m ??? [#f1]_
Dell Inspiron 510m ???
Dell Inspiron 5150 vbetool needed (6)
-Dell Inspiron 600m ??? (*)
-Dell Inspiron 8200 ??? (*)
-Dell Inspiron 8500 ??? (*)
-Dell Inspiron 8600 ??? (*)
-eMachines athlon64 machines vbetool needed (6) (someone please get me model #s)
-HP NC6000 s3_bios, may not use radeonfb (2); or vbetool (6)
-HP NX7000 ??? (*)
-HP Pavilion ZD7000 vbetool post needed, need open-source nv driver for X
+Dell Inspiron 600m ??? [#f1]_
+Dell Inspiron 8200 ??? [#f1]_
+Dell Inspiron 8500 ??? [#f1]_
+Dell Inspiron 8600 ??? [#f1]_
+eMachines athlon64 machines vbetool needed (6) (someone please get
+ me model #s)
+HP NC6000 s3_bios, may not use radeonfb (2);
+ or vbetool (6)
+HP NX7000 ??? [#f1]_
+HP Pavilion ZD7000 vbetool post needed, need open-source nv
+ driver for X
HP Omnibook XE3 athlon version none (1)
HP Omnibook XE3GC none (1), video is S3 Savage/IX-MV
HP Omnibook XE3L-GF vbetool (6)
HP Omnibook 5150 none (1), (S1 also works OK)
-IBM TP T20, model 2647-44G none (1), video is S3 Inc. 86C270-294 Savage/IX-MV, vesafb gets "interesting" but X work.
-IBM TP A31 / Type 2652-M5G s3_mode (3) [works ok with BIOS 1.04 2002-08-23, but not at all with BIOS 1.11 2004-11-05 :-(]
+IBM TP T20, model 2647-44G none (1), video is S3 Inc. 86C270-294
+ Savage/IX-MV, vesafb gets "interesting"
+ but X work.
+IBM TP A31 / Type 2652-M5G s3_mode (3) [works ok with
+ BIOS 1.04 2002-08-23, but not at all with
+ BIOS 1.11 2004-11-05 :-(]
IBM TP R32 / Type 2658-MMG none (1)
-IBM TP R40 2722B3G ??? (*)
+IBM TP R40 2722B3G ??? [#f1]_
IBM TP R50p / Type 1832-22U s3_bios (2)
IBM TP R51 none (1)
-IBM TP T30 236681A ??? (*)
+IBM TP T30 236681A ??? [#f1]_
IBM TP T40 / Type 2373-MU4 none (1)
IBM TP T40p none (1)
IBM TP R40p s3_bios (2)
IBM TP T41p s3_bios (2), switch to X after resume
IBM TP T42 s3_bios (2)
IBM ThinkPad T42p (2373-GTG) s3_bios (2)
-IBM TP X20 ??? (*)
+IBM TP X20 ??? [#f1]_
IBM TP X30 s3_bios, s3_mode (4)
-IBM TP X31 / Type 2672-XXH none (1), use radeontool (http://fdd.com/software/radeon/) to turn off backlight.
-IBM TP X32 none (1), but backlight is on and video is trashed after long suspend. s3_bios,s3_mode (4) works too. Perhaps that gets better results?
+IBM TP X31 / Type 2672-XXH none (1), use radeontool
+ (http://fdd.com/software/radeon/) to
+ turn off backlight.
+IBM TP X32 none (1), but backlight is on and video is
+ trashed after long suspend. s3_bios,
+ s3_mode (4) works too. Perhaps that gets
+ better results?
IBM Thinkpad X40 Type 2371-7JG s3_bios,s3_mode (4)
-IBM TP 600e none(1), but a switch to console and back to X is needed
-Medion MD4220 ??? (*)
+IBM TP 600e none(1), but a switch to console and
+ back to X is needed
+Medion MD4220 ??? [#f1]_
Samsung P35 vbetool needed (6)
Sharp PC-AR10 (ATI rage) none (1), backlight does not switch off
Sony Vaio PCG-C1VRX/K s3_bios (2)
-Sony Vaio PCG-F403 ??? (*)
+Sony Vaio PCG-F403 ??? [#f1]_
Sony Vaio PCG-GRT995MP none (1), works with 'nv' X driver
-Sony Vaio PCG-GR7/K none (1), but needs radeonfb, use radeontool (http://fdd.com/software/radeon/) to turn off backlight.
-Sony Vaio PCG-N505SN ??? (*)
+Sony Vaio PCG-GR7/K none (1), but needs radeonfb, use
+ radeontool (http://fdd.com/software/radeon/)
+ to turn off backlight.
+Sony Vaio PCG-N505SN ??? [#f1]_
Sony Vaio vgn-s260 X or boot-radeon can init it (5)
-Sony Vaio vgn-S580BH vga=normal, but suspend from X. Console will be blank unless you return to X.
+Sony Vaio vgn-S580BH vga=normal, but suspend from X. Console will
+ be blank unless you return to X.
Sony Vaio vgn-FS115B s3_bios (2),s3_mode (4)
Toshiba Libretto L5 none (1)
Toshiba Libretto 100CT/110CT vbetool (6)
Toshiba Portege 3020CT s3_mode (3)
Toshiba Satellite 4030CDT s3_mode (3) (S1 also works OK)
Toshiba Satellite 4080XCDT s3_mode (3) (S1 also works OK)
-Toshiba Satellite 4090XCDT ??? (*)
-Toshiba Satellite P10-554 s3_bios,s3_mode (4)(****)
+Toshiba Satellite 4090XCDT ??? [#f1]_
+Toshiba Satellite P10-554 s3_bios,s3_mode (4)[#f3]_
Toshiba M30 (2) xor X with nvidia driver using internal AGP
-Uniwill 244IIO ??? (*)
+Uniwill 244IIO ??? [#f1]_
+=============================== ===============================================
Known working desktop systems
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+=================== ============================= ========================
Mainboard Graphics card hack (or "how to do it")
-------------------------------------------------------------------------------
+=================== ============================= ========================
Asus A7V8X nVidia RIVA TNT2 model 64 s3_bios,s3_mode (4)
+=================== ============================= ========================
-(*) from https://wiki.ubuntu.com/HoaryPMResults, not sure
- which options to use. If you know, please tell me.
+.. [#f1] from https://wiki.ubuntu.com/HoaryPMResults, not sure
+ which options to use. If you know, please tell me.
-(***) To be tested with a newer kernel.
+.. [#f2] To be tested with a newer kernel.
-(****) Not with SMP kernel, UP only.
+.. [#f3] Not with SMP kernel, UP only.
diff --git a/Documentation/process/submitting-drivers.rst b/Documentation/process/submitting-drivers.rst
index 58bc047e7b95..1acaa14903d6 100644
--- a/Documentation/process/submitting-drivers.rst
+++ b/Documentation/process/submitting-drivers.rst
@@ -117,7 +117,7 @@ PM support:
implemented") error. You should also try to make sure that your
driver uses as little power as possible when it's not doing
anything. For the driver testing instructions see
- Documentation/power/drivers-testing.txt and for a relatively
+ Documentation/power/drivers-testing.rst and for a relatively
complete overview of the power management issues related to
drivers see :ref:`Documentation/driver-api/pm/devices.rst <driverapi_pm_devices>`.
diff --git a/Documentation/scheduler/sched-energy.txt b/Documentation/scheduler/sched-energy.txt
index 197d81f4b836..d97207b9accb 100644
--- a/Documentation/scheduler/sched-energy.txt
+++ b/Documentation/scheduler/sched-energy.txt
@@ -22,7 +22,7 @@ the highest.
The actual EM used by EAS is _not_ maintained by the scheduler, but by a
dedicated framework. For details about this framework and what it provides,
-please refer to its documentation (see Documentation/power/energy-model.txt).
+please refer to its documentation (see Documentation/power/energy-model.rst).
2. Background and Terminology
@@ -81,7 +81,7 @@ through the arch_scale_cpu_capacity() callback.
The rest of platform knowledge used by EAS is directly read from the Energy
Model (EM) framework. The EM of a platform is composed of a power cost table
-per 'performance domain' in the system (see Documentation/power/energy-model.txt
+per 'performance domain' in the system (see Documentation/power/energy-model.rst
for futher details about performance domains).
The scheduler manages references to the EM objects in the topology code when the
@@ -352,7 +352,7 @@ could be amended in the future if proven otherwise.
EAS uses the EM of a platform to estimate the impact of scheduling decisions on
energy. So, your platform must provide power cost tables to the EM framework in
order to make EAS start. To do so, please refer to documentation of the
-independent EM framework in Documentation/power/energy-model.txt.
+independent EM framework in Documentation/power/energy-model.rst.
Please also note that the scheduling domains need to be re-built after the
EM has been registered in order to start EAS.
diff --git a/Documentation/trace/coresight-cpu-debug.txt b/Documentation/trace/coresight-cpu-debug.txt
index f07e38094b40..1a660a39e3c0 100644
--- a/Documentation/trace/coresight-cpu-debug.txt
+++ b/Documentation/trace/coresight-cpu-debug.txt
@@ -151,7 +151,7 @@ At the runtime you can disable idle states with below methods:
It is possible to disable CPU idle states by way of the PM QoS
subsystem, more specifically by using the "/dev/cpu_dma_latency"
-interface (see Documentation/power/pm_qos_interface.txt for more
+interface (see Documentation/power/pm_qos_interface.rst for more
details). As specified in the PM QoS documentation the requested
parameter will stay in effect until the file descriptor is released.
For example:
diff --git a/Documentation/translations/zh_CN/process/submitting-drivers.rst b/Documentation/translations/zh_CN/process/submitting-drivers.rst
index 72c6cd935821..f1c3906c69a8 100644
--- a/Documentation/translations/zh_CN/process/submitting-drivers.rst
+++ b/Documentation/translations/zh_CN/process/submitting-drivers.rst
@@ -97,7 +97,7 @@ Linux 2.6:
函数定义成返回 -ENOSYS（功能未实现）错误。你还应该尝试确
保你的驱动在什么都不干的情况下将耗电降到最低。要获得驱动
程序测试的指导，请参阅
- Documentation/power/drivers-testing.txt。有关驱动程序电
+ Documentation/power/drivers-testing.rst。有关驱动程序电
源管理问题相对全面的概述，请参阅
Documentation/driver-api/pm/devices.rst。
diff --git a/MAINTAINERS b/MAINTAINERS
index cc11aea722c8..65448dae1467 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6478,7 +6478,7 @@ M: "Rafael J. Wysocki" <rjw@rjwysocki.net>
M: Pavel Machek <pavel@ucw.cz>
L: linux-pm@vger.kernel.org
S: Supported
-F: Documentation/power/freezing-of-tasks.txt
+F: Documentation/power/freezing-of-tasks.rst
F: include/linux/freezer.h
F: kernel/freezer.c
@@ -11804,7 +11804,7 @@ S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git
F: drivers/opp/
F: include/linux/pm_opp.h
-F: Documentation/power/opp.txt
+F: Documentation/power/opp.rst
F: Documentation/devicetree/bindings/opp/
OPL4 DRIVER
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2057254c6c8a..420d488822b4 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2447,7 +2447,7 @@ menuconfig APM
machines with more than one CPU.
In order to use APM, you will need supporting software. For location
- and more information, read <file:Documentation/power/apm-acpi.txt>
+ and more information, read <file:Documentation/power/apm-acpi.rst>
and the Battery Powered Linux mini-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dfe4b11ee423..79072c44a873 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1069,7 +1069,7 @@ struct skl_wm_params {
* to be disabled. This shouldn't happen and we'll print some error messages in
* case it happens.
*
- * For more, read the Documentation/power/runtime_pm.txt.
+ * For more, read the Documentation/power/runtime_pm.rst.
*/
struct i915_runtime_pm {
atomic_t wakeref_count;
diff --git a/drivers/opp/Kconfig b/drivers/opp/Kconfig
index fe54d349d2e1..35dfc7e80f92 100644
--- a/drivers/opp/Kconfig
+++ b/drivers/opp/Kconfig
@@ -11,4 +11,4 @@ config PM_OPP
OPP layer organizes the data internally using device pointers
representing individual voltage domains and provides SOC
implementations a ready to use framework to manage OPPs.
- For more information, read <file:Documentation/power/opp.txt>
+ For more information, read <file:Documentation/power/opp.rst>
diff --git a/drivers/power/supply/power_supply_core.c b/drivers/power/supply/power_supply_core.c
index 136e8f64848a..b55cdfe22a2e 100644
--- a/drivers/power/supply/power_supply_core.c
+++ b/drivers/power/supply/power_supply_core.c
@@ -606,7 +606,7 @@ int power_supply_get_battery_info(struct power_supply *psy,
/* The property and field names below must correspond to elements
* in enum power_supply_property. For reasoning, see
- * Documentation/power/power_supply_class.txt.
+ * Documentation/power/power_supply_class.rst.
*/
of_property_read_u32(battery_np, "energy-full-design-microwatt-hours",
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index c7eef32e7739..5b8328a99b2a 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -52,7 +52,7 @@
* irq line disabled until the threaded handler has been run.
* IRQF_NO_SUSPEND - Do not disable this IRQ during suspend. Does not guarantee
* that this interrupt will wake the system from a suspended
- * state. See Documentation/power/suspend-and-interrupts.txt
+ * state. See Documentation/power/suspend-and-interrupts.rst
* IRQF_FORCE_RESUME - Force enable it on resume even if IRQF_NO_SUSPEND is set
* IRQF_NO_THREAD - Interrupt cannot be threaded
* IRQF_EARLY_RESUME - Resume IRQ early during syscore instead of at device
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 44d254548ca7..41c5673aba2f 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -808,7 +808,7 @@ struct module;
* @suspend_late: Put device into low power state.
* @resume_early: Wake device from low power state.
* @resume: Wake device from low power state.
- * (Please see Documentation/power/pci.txt for descriptions
+ * (Please see Documentation/power/pci.rst for descriptions
* of PCI Power Management and the related functions.)
* @shutdown: Hook into reboot_notifier_list (kernel/sys.c).
* Intended to stop any idling DMA operations.
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 345d74a727e3..220e2008467d 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -271,7 +271,7 @@ typedef struct pm_message {
* actions to be performed by a device driver's callbacks generally depend on
* the platform and subsystem the device belongs to.
*
- * Refer to Documentation/power/runtime_pm.txt for more information about the
+ * Refer to Documentation/power/runtime_pm.rst for more information about the
* role of the @runtime_suspend(), @runtime_resume() and @runtime_idle()
* callbacks in device runtime power management.
*/
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index ff8592ddedee..d3667b4075c1 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -66,7 +66,7 @@ config HIBERNATION
need to run mkswap against the swap partition used for the suspend.
It also works with swap files to a limited extent (for details see
- <file:Documentation/power/swsusp-and-swap-files.txt>).
+ <file:Documentation/power/swsusp-and-swap-files.rst>).
Right now you may boot without resuming and resume later but in the
meantime you cannot use the swap partition(s)/file(s) involved in
@@ -75,7 +75,7 @@ config HIBERNATION
MOUNT any journaled filesystems mounted before the suspend or they
will get corrupted in a nasty way.
- For more information take a look at <file:Documentation/power/swsusp.txt>.
+ For more information take a look at <file:Documentation/power/swsusp.rst>.
config ARCH_SAVE_PAGE_KEYS
bool
@@ -256,7 +256,7 @@ config APM_EMULATION
notification of APM "events" (e.g. battery status change).
In order to use APM, you will need supporting software. For location
- and more information, read <file:Documentation/power/apm-acpi.txt>
+ and more information, read <file:Documentation/power/apm-acpi.rst>
and the Battery Powered Linux mini-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index 6310ddede220..cc70f5932773 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -166,7 +166,7 @@ config CFG80211_DEFAULT_PS
If this causes your applications to misbehave you should fix your
applications instead -- they need to register their network
- latency requirement, see Documentation/power/pm_qos_interface.txt.
+ latency requirement, see Documentation/power/pm_qos_interface.rst.
config CFG80211_DEBUGFS
bool "cfg80211 DebugFS entries"
--
2.21.0
^ permalink raw reply related
* Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook
From: Larry Finger @ 2019-06-08 21:52 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Aaro Koskinen, Christian Zigotzky, Michael Ellerman, linux-kernel,
linux-wireless, linuxppc-dev
In-Reply-To: <20190607172902.GA8183@lst.de>
On 6/7/19 12:29 PM, Christoph Hellwig wrote:
> I don't think we should work around this in the driver, we need to fix
> it in the core. I'm curious why my previous patch didn't work. Can
> you throw in a few printks what failed? I.e. did dma_direct_supported
> return false? Did the actual allocation fail?
Routine dma_direct_supported() returns true.
The failure is in routine dma_set_mask() in the following if test:
if (!dev->dma_mask || !dma_supported(dev, mask))
return -EIO;
For b43legacy, dev->dma_mask is 0xc265684800000000.
dma_supported(dev, mask) is 0xc08b000000000000, mask is 0x3fffffff, and the
routine returns -EIO.
For b43, dev->dma_mask is 0xc265684800000001,
dma_supported(dev, mask) is 0xc08b000000000000, mask is 0x77777777, and the
routine returns 0.
Thus far I have not found what sets the low-order bit of dev->dma_mask.
Suggestions are welcome.
These tests have all been with your patch that sets ARCH_ZONE_DMA_BITS to 30.
Larry
^ permalink raw reply
* Re: [RFC PATCH 0/3] move WEP implementation to skcipher interface
From: Ard Biesheuvel @ 2019-06-08 15:51 UTC (permalink / raw)
To: Sandy Harris
Cc: Denis Kenzior, Eric Biggers, Marcel Holtmann,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE, Herbert Xu,
Johannes Berg, open list:NFC SUBSYSTEM, David S. Miller
In-Reply-To: <CAKv+Gu8Ex63n-YV7aaQEz7VBZ137vi113jv5NCPjbxP8=9Q=qQ@mail.gmail.com>
On Sat, 8 Jun 2019 at 16:37, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
> On Sat, 8 Jun 2019 at 15:03, Sandy Harris <sandyinchina@gmail.com> wrote:
> >
> > First off, it is not clear we should implement WEP at all since it is
> > fatally flawed. This has been known for about a decade, there have
> > been at least two better algorithms added to the standards, & the only
> > reason anyone would need WEP today would be to connect to an old
> > router in an obviously insecure way.
> > https://www.schneier.com/blog/archives/2007/04/breaking_wep_in.html
> > https://www.tomshardware.com/reviews/wireless-security-hack,2981-4.html
> >
> > Twenty years ago the FreeS/WAN project implemented IPsec for Linux &
> > deliberately did not include things like single DES which were known
> > to be insecure:
> > https://www.freeswan.org/freeswan_trees/freeswan-1.99/doc/compat.html#dropped
> > I think a similar policy was would be a fine idea for the kernel today
> > & WEP is hopelessly insecure.
> >
>
> It is actually pretty clear that we should implement WEP, simply
> because we already do. We all know how broken it is, but that does not
> mean we should be the ones policing its use. People may have good
> reasons to stick with WEP in their particular use case, or maybe they
> have bad reasons, but the bottom line is that it does not really
> matter: if it works today, we can't just remove it.
>
> What we can do is make the existing code less of an eyesore than it
> already is, and in the context of what I want to achieve for the
> crypto API, this involves moving it from the cipher API to something
> else.
>
> > > > As I am attempting to explain, ecb(arc4) does not implement this API correctly
> > > > because it updates the *key* after each operation, not the IV. I doubt this is
> > > > documented anywhere, but this can only be changed if people aren't relying on it
> > > > already.
> >
> > It is more the case that the API does not apply to arc4, or more
> > generally to stream ciphers, than that "ecb(arc4) does not implement
> > this API correctly".
> >
> > ECB (electronic code book) is a mode of operation for block ciphers
> > https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation
> > Stream ciphers do not have those modes.
> >
>
> This is exactly the point Eric was making. Our skcipher abstraction
> deals with stream ciphers fine, but the way the arc4 code is exposed
> as ecb(arc4) and updates the key in the process makes absolutely no
> sense.
>
> > For that matter, not all block cipher modes use an IV. The very common
> > CBC mode -- the only mode used in IPsec, for example -- does, but
> > others including ECB do not. I do not know of any mode that ever
> > updates the IV. CBC uses the IV with the first block & on all other
> > blocks uses the ciphertext from the previous block the same way; one
> > might call that updating the IV I suppose, but I do not see why one
> > would want to.
> >
>
> If you want to split up a CBC transformation into several invocations
> of the underlying API, then the last ciphertext block of the first
> call serves as the IV for the next call. Arguing that we should not be
> calling this an IV serves little purpose, since the code already
> treats it exactly the same. In fact, our CTS template relies on this
> feature as well, so a CBC implementation that does not return the last
> ciphertext block in the IV buffer is broken wrt our API requirements.
>
> > > It sounds to me like it was broken and should be fixed. So our vote /
> > > preference is to have ARC4 fixed to follow the proper semantics.
> >
> > As I see it, those are clearly not "he proper semantics" for a stream
> > cipher & the question of forcing it into them should not even arise.
> >
> > One alternative would be to drop arc4. That would make sense if WEP is
> > the only usage & we elect to drop WEP. One could also argue the arc4
> > itself is insecure & should go, but I'm not sure that is accurate.
> > Certainly there have been some published attacks & other stream
> > ciphers are now generally preferrred, but I have not followed things
> > closely enough to know if RC$ should be considered fatally flawed.
> >
> > A better choice might be to change the interface, defining a new
> > interface for stream ciphers and/or generalising the interface so it
> > works for either stream ciphers or block ciphers.
>
> Dropping WEP is out of the question, and apparently, there are
> userspace dependencies on the ecb(arc4) cipher as well, so
> unfortunately, we have already painted ourselves into a corner here.
>
> skcipher works fine for block ciphers wrapped in CTR mode, and for
> chacha/salsa as well, so I don't think there is a problem with the API
> for other stream ciphers we care about. Calling the rc4 skcipher
> 'ecb(arc4)' was obviously a mistake, but it seems we're stuck with
> that as well :-(
As it turns out, we have other users of ecb(arc4) in the MPPE code,
the kerberos code and some realtek code in the staging tree. More
interestingly, the code this series changes was recently converted
from skcipher to cipher, while I am doing the opposite.
Given Eric's analysis that few of these users actually take advantage
of the crypto API (i.e., they all use the sync variety and hardcode
the algo name), we can simplify them to use library calls instead. The
only remaining skcipher user would be the Kerberos code, which
dynamically instantiates skciphers with a parameterized algo name.
^ permalink raw reply
* [RFC PATCH v2] ath9k: add loader for AR92XX (and older) pci(e)
From: Christian Lamparter @ 2019-06-08 14:49 UTC (permalink / raw)
To: ath9k-devel, linux-wireless
Cc: Hauke Mehrtens, Martin Blumenstingl, Julian Calaby
In-Reply-To: <20190608144947.744-1-chunkeey@gmail.com>
Atheros cards with a AR92XX generation (and older) chip usually
store their pci(e) initialization vectors on an external eeprom chip.
However these chips technically don't need the eeprom chip attached,
the AR9280 Datasheet in section "6.1.2 DEVICE_ID" describes that
"... if the EEPROM content is not valid, a value of 0XFF1C returns
when read from the register". So the embedded devices like routers
and accesspoint usually have the pci(e) initialization vectors
stored on the system's FLASH, which is out of reach of the ath9k
chip.
Furthermore, Some devices (like the Cisco Meraki Z1 Cloud Managed
Teleworker Gateway) need to be able to initialize the PCIe wifi device.
Normally, this should be done as a pci quirk during the early stages of
booting linux. However, this isn't possible for devices which have the
init code for the Atheros chip stored on NAND in an UBI volume.
Hence, this module can be used to initialize the chip when the
user-space is ready to extract the init code.
Martin Blumenstingl prodived the following fixes:
owl-loader: add support for OWL emulation PCI devices
owl-loader: don't re-scan the bus when ath9k_pci_fixup failed
owl-loader: use dev_* instead of pr_* logging functions
owl-loader: auto-generate the eeprom filename as fallback
owl-loader: add a debug message when swapping the eeprom data
owl-loader: add missing newlines in log messages
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
v2: address Julian Calaby's comments:
- make it a separate driver again (much like OpenWrt)
- remove ar71xx leftovers (pdata)
---
drivers/net/wireless/ath/ath9k/Kconfig | 16 ++
drivers/net/wireless/ath/ath9k/Makefile | 2 +
.../wireless/ath/ath9k/ath9k_pci_owl_loader.c | 215 ++++++++++++++++++
3 files changed, 233 insertions(+)
create mode 100644 drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig
index a1ef8769983a..d6a87698a44a 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -157,6 +157,22 @@ config ATH9K_PCOEM
depends on ATH9K
default y
+config ATH9K_PCI_NO_EEPROM
+ tristate "Atheros ath9k pci loader for EEPROM-less chips"
+ depends on ATH9K_PCI
+ default n
+ help
+ This separate driver provides a loader in order to support the
+ AR500X to AR92XX-generation of ath9k PCI(e) WiFi chips, which have
+ their initialization data (which contains the real PCI Device ID
+ that ath9k will need) stored together with the calibration data out
+ of reach for the ath9k chip.
+
+ These devices are usually various network appliances, routers or
+ access Points and such.
+
+ If unsure say N.
+
config ATH9K_HTC
tristate "Atheros HTC based wireless cards support"
depends on USB && MAC80211
diff --git a/drivers/net/wireless/ath/ath9k/Makefile b/drivers/net/wireless/ath/ath9k/Makefile
index f71b2ad8275c..abd0f61370d9 100644
--- a/drivers/net/wireless/ath/ath9k/Makefile
+++ b/drivers/net/wireless/ath/ath9k/Makefile
@@ -77,3 +77,5 @@ ath9k_htc-y += htc_hst.o \
ath9k_htc-$(CONFIG_ATH9K_HTC_DEBUGFS) += htc_drv_debug.o
obj-$(CONFIG_ATH9K_HTC) += ath9k_htc.o
+
+obj-$(CONFIG_ATH9K_PCI_NO_EEPROM) += ath9k_pci_owl_loader.o
diff --git a/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
new file mode 100644
index 000000000000..7ed495a9f1fe
--- /dev/null
+++ b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Initialize Owl Emulation Devices
+ *
+ * Copyright (C) 2016 Christian Lamparter <chunkeey@gmail.com>
+ * Copyright (C) 2016 Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+ *
+ * Some devices (like the Cisco Meraki Z1 Cloud Managed Teleworker Gateway)
+ * need to be able to initialize the PCIe wifi device. Normally, this is done
+ * during the early stages as a pci quirk.
+ * However, this isn't possible for devices which have the init code for the
+ * Atheros chip stored on UBI Volume on NAND. Hence, this module can be used to
+ * initialize the chip when the user-space is ready to extract the init code.
+ */
+#include <linux/module.h>
+#include <linux/version.h>
+#include <linux/completion.h>
+#include <linux/etherdevice.h>
+#include <linux/firmware.h>
+#include <linux/pci.h>
+#include <linux/delay.h>
+#include <linux/platform_device.h>
+#include <linux/ath9k_platform.h>
+
+struct owl_ctx {
+ struct completion eeprom_load;
+};
+
+#define EEPROM_FILENAME_LEN 100
+
+#define AR5416_EEPROM_MAGIC 0xa55a
+
+static int ath9k_pci_fixup(struct pci_dev *pdev, const u16 *cal_data,
+ size_t cal_len)
+{
+ void __iomem *mem;
+ const void *cal_end = (void *)cal_data + cal_len;
+ const struct {
+ u16 reg;
+ u16 low_val;
+ u16 high_val;
+ } __packed * data;
+ u16 cmd;
+ u32 bar0;
+ bool swap_needed = false;
+
+ if (*cal_data != AR5416_EEPROM_MAGIC) {
+ if (*cal_data != swab16(AR5416_EEPROM_MAGIC)) {
+ dev_err(&pdev->dev, "invalid calibration data\n");
+ return -EINVAL;
+ }
+
+ dev_dbg(&pdev->dev, "calibration data needs swapping\n");
+ swap_needed = true;
+ }
+
+ dev_info(&pdev->dev, "fixup device configuration\n");
+
+ mem = pcim_iomap(pdev, 0, 0);
+ if (!mem) {
+ dev_err(&pdev->dev, "ioremap error\n");
+ return -EINVAL;
+ }
+
+ pci_read_config_dword(pdev, PCI_BASE_ADDRESS_0, &bar0);
+ pci_write_config_dword(pdev, PCI_BASE_ADDRESS_0,
+ pci_resource_start(pdev, 0));
+ pci_read_config_word(pdev, PCI_COMMAND, &cmd);
+ cmd |= PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY;
+ pci_write_config_word(pdev, PCI_COMMAND, cmd);
+
+ /* set pointer to first reg address */
+ for (data = (const void *)(cal_data + 3);
+ (const void *)data <= cal_end && data->reg != (u16)~0;
+ data++) {
+ u32 val;
+ u16 reg;
+
+ reg = data->reg;
+ val = data->low_val;
+ val |= ((u32)data->high_val) << 16;
+
+ if (swap_needed) {
+ reg = swab16(reg);
+ val = swahb32(val);
+ }
+
+ __raw_writel(val, mem + reg);
+ usleep_range(100, 120);
+ }
+
+ pci_read_config_word(pdev, PCI_COMMAND, &cmd);
+ cmd &= ~(PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY);
+ pci_write_config_word(pdev, PCI_COMMAND, cmd);
+
+ pci_write_config_dword(pdev, PCI_BASE_ADDRESS_0, bar0);
+ pcim_iounmap(pdev, mem);
+
+ pci_disable_device(pdev);
+
+ return 0;
+}
+
+static void owl_fw_cb(const struct firmware *fw, void *context)
+{
+ struct pci_dev *pdev = (struct pci_dev *)context;
+ struct owl_ctx *ctx = (struct owl_ctx *)pci_get_drvdata(pdev);
+ struct pci_bus *bus;
+
+ complete(&ctx->eeprom_load);
+
+ if (!fw) {
+ dev_err(&pdev->dev, "no eeprom data received.\n");
+ goto release;
+ }
+
+ /* also note that we are doing *u16 operations on the file */
+ if (fw->size > 4096 || fw->size < 0x200 || (fw->size & 1) == 1) {
+ dev_err(&pdev->dev, "eeprom file has an invalid size.\n");
+ goto release;
+ }
+
+ if (ath9k_pci_fixup(pdev, (const u16 *)fw->data, fw->size))
+ goto release;
+
+ pci_lock_rescan_remove();
+ bus = pdev->bus;
+ pci_stop_and_remove_bus_device(pdev);
+ /* the device should come back with the proper
+ * ProductId. But we have to initiate a rescan.
+ */
+ pci_rescan_bus(bus);
+ pci_unlock_rescan_remove();
+
+release:
+ release_firmware(fw);
+}
+
+static const char *owl_get_eeprom_name(struct pci_dev *pdev)
+{
+ struct device *dev = &pdev->dev;
+ char *eeprom_name;
+
+ dev_dbg(dev, "using auto-generated eeprom filename\n");
+
+ eeprom_name = devm_kzalloc(dev, EEPROM_FILENAME_LEN, GFP_KERNEL);
+ if (!eeprom_name)
+ return NULL;
+
+ /* this should match the pattern used in ath9k/init.c */
+ scnprintf(eeprom_name, EEPROM_FILENAME_LEN, "ath9k-eeprom-pci-%s.bin",
+ dev_name(dev));
+
+ return eeprom_name;
+}
+
+static int owl_probe(struct pci_dev *pdev,
+ const struct pci_device_id *id)
+{
+ struct owl_ctx *ctx;
+ const char *eeprom_name;
+ int err = 0;
+
+ if (pcim_enable_device(pdev))
+ return -EIO;
+
+ pcim_pin_device(pdev);
+
+ eeprom_name = owl_get_eeprom_name(pdev);
+ if (!eeprom_name) {
+ dev_err(&pdev->dev, "no eeprom filename found.\n");
+ return -ENODEV;
+ }
+
+ ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
+ if (!ctx)
+ return -ENOMEM;
+
+ init_completion(&ctx->eeprom_load);
+
+ pci_set_drvdata(pdev, ctx);
+ err = request_firmware_nowait(THIS_MODULE, true, eeprom_name,
+ &pdev->dev, GFP_KERNEL, pdev, owl_fw_cb);
+ if (err)
+ dev_err(&pdev->dev, "failed to request caldata (%d).\n", err);
+
+ return err;
+}
+
+static void owl_remove(struct pci_dev *pdev)
+{
+ struct owl_ctx *ctx = pci_get_drvdata(pdev);
+
+ if (ctx) {
+ wait_for_completion(&ctx->eeprom_load);
+ pci_set_drvdata(pdev, NULL);
+ }
+}
+
+static const struct pci_device_id owl_pci_table[] = {
+ { PCI_VDEVICE(ATHEROS, 0xff1c) }, /* PCIe */
+ { PCI_VDEVICE(ATHEROS, 0xff1d) }, /* PCI */
+ { },
+};
+MODULE_DEVICE_TABLE(pci, owl_pci_table);
+
+static struct pci_driver owl_driver = {
+ .name = KBUILD_MODNAME,
+ .id_table = owl_pci_table,
+ .probe = owl_probe,
+ .remove = owl_remove,
+};
+module_pci_driver(owl_driver);
+MODULE_AUTHOR("Christian Lamparter <chunkeey@gmail.com>");
+MODULE_DESCRIPTION("Initializes Atheros' Owl Emulation devices");
+MODULE_LICENSE("GPL v2");
--
2.20.1
^ permalink raw reply related
* [PATCH v2] carl9170: fix misuse of device driver API
From: Christian Lamparter @ 2019-06-08 14:49 UTC (permalink / raw)
To: linux-wireless, linux-usb; +Cc: Alan Stern, Kalle Valo
In-Reply-To: <20190608144947.744-1-chunkeey@gmail.com>
This patch follows Alan Stern's recent patch:
"p54: Fix race between disconnect and firmware loading"
that overhauled carl9170 buggy firmware loading and driver
unbinding procedures.
Since the carl9170 code was adapted from p54 it uses the
same functions and is likely to have the same problem, but
it's just that the syzbot hasn't reproduce them (yet).
a summary from the changes (copied from the p54 patch):
* Call usb_driver_release_interface() rather than
device_release_driver().
* Lock udev (the interface's parent) before unbinding the
driver instead of locking udev->parent.
* During the firmware loading process, take a reference
to the USB interface instead of the USB device.
* Don't take an unnecessary reference to the device during
probe (and then don't drop it during disconnect).
and
* Make sure to prevent use-after-free bugs by explicitly
setting the driver context to NULL after signaling the
completion.
Cc: <stable@vger.kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
v2: Alan Stern's comments
- fixed possible use-after-free
---
drivers/net/wireless/ath/carl9170/usb.c | 39 +++++++++++--------------
1 file changed, 17 insertions(+), 22 deletions(-)
diff --git a/drivers/net/wireless/ath/carl9170/usb.c b/drivers/net/wireless/ath/carl9170/usb.c
index e7c3f3b8457d..99f1897a775d 100644
--- a/drivers/net/wireless/ath/carl9170/usb.c
+++ b/drivers/net/wireless/ath/carl9170/usb.c
@@ -128,6 +128,8 @@ static const struct usb_device_id carl9170_usb_ids[] = {
};
MODULE_DEVICE_TABLE(usb, carl9170_usb_ids);
+static struct usb_driver carl9170_driver;
+
static void carl9170_usb_submit_data_urb(struct ar9170 *ar)
{
struct urb *urb;
@@ -966,32 +968,28 @@ static int carl9170_usb_init_device(struct ar9170 *ar)
static void carl9170_usb_firmware_failed(struct ar9170 *ar)
{
- struct device *parent = ar->udev->dev.parent;
- struct usb_device *udev;
-
- /*
- * Store a copy of the usb_device pointer locally.
- * This is because device_release_driver initiates
- * carl9170_usb_disconnect, which in turn frees our
- * driver context (ar).
+ /* Store a copies of the usb_interface and usb_device pointer locally.
+ * This is because release_driver initiates carl9170_usb_disconnect,
+ * which in turn frees our driver context (ar).
*/
- udev = ar->udev;
+ struct usb_interface *intf = ar->intf;
+ struct usb_device *udev = ar->udev;
complete(&ar->fw_load_wait);
+ /* at this point 'ar' could be already freed. Don't use it anymore */
+ ar = NULL;
/* unbind anything failed */
- if (parent)
- device_lock(parent);
-
- device_release_driver(&udev->dev);
- if (parent)
- device_unlock(parent);
+ usb_lock_device(udev);
+ usb_driver_release_interface(&carl9170_driver, intf);
+ usb_unlock_device(udev);
- usb_put_dev(udev);
+ usb_put_intf(intf);
}
static void carl9170_usb_firmware_finish(struct ar9170 *ar)
{
+ struct usb_interface *intf = ar->intf;
int err;
err = carl9170_parse_firmware(ar);
@@ -1009,7 +1007,7 @@ static void carl9170_usb_firmware_finish(struct ar9170 *ar)
goto err_unrx;
complete(&ar->fw_load_wait);
- usb_put_dev(ar->udev);
+ usb_put_intf(intf);
return;
err_unrx:
@@ -1052,7 +1050,6 @@ static int carl9170_usb_probe(struct usb_interface *intf,
return PTR_ERR(ar);
udev = interface_to_usbdev(intf);
- usb_get_dev(udev);
ar->udev = udev;
ar->intf = intf;
ar->features = id->driver_info;
@@ -1094,15 +1091,14 @@ static int carl9170_usb_probe(struct usb_interface *intf,
atomic_set(&ar->rx_anch_urbs, 0);
atomic_set(&ar->rx_pool_urbs, 0);
- usb_get_dev(ar->udev);
+ usb_get_intf(intf);
carl9170_set_state(ar, CARL9170_STOPPED);
err = request_firmware_nowait(THIS_MODULE, 1, CARL9170FW_NAME,
&ar->udev->dev, GFP_KERNEL, ar, carl9170_usb_firmware_step2);
if (err) {
- usb_put_dev(udev);
- usb_put_dev(udev);
+ usb_put_intf(intf);
carl9170_free(ar);
}
return err;
@@ -1131,7 +1127,6 @@ static void carl9170_usb_disconnect(struct usb_interface *intf)
carl9170_release_firmware(ar);
carl9170_free(ar);
- usb_put_dev(udev);
}
#ifdef CONFIG_PM
--
2.20.1
^ permalink raw reply related
* [PATCH] carl9170: fix enum compare splat
From: Christian Lamparter @ 2019-06-08 14:49 UTC (permalink / raw)
To: linux-wireless; +Cc: Kalle Valo
This patch fixes a noisy warning triggered by -Wenum-compare
|main.c:1390:31: warning: comparison between ‘enum nl80211_ac’
| and ‘enum ar9170_txq’ [-Wenum-compare]
| BUILD_BUG_ON(NL80211_NUM_ACS > __AR9170_NUM_TXQ);
| ^
| [...]
This is a little bit unfortunate, since the number of queues
(hence NL80211_NUM_ACS) is a constant based on the IEEE 802.11
(much like IEEE80211_NUM_ACS) and __AR9170_NUM_TXQ is more or
less defined by the AR9170 hardware.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
drivers/net/wireless/ath/carl9170/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/carl9170/main.c b/drivers/net/wireless/ath/carl9170/main.c
index eaea08581cea..acc881bd7f9f 100644
--- a/drivers/net/wireless/ath/carl9170/main.c
+++ b/drivers/net/wireless/ath/carl9170/main.c
@@ -1387,7 +1387,7 @@ static int carl9170_op_conf_tx(struct ieee80211_hw *hw,
int ret;
BUILD_BUG_ON(ARRAY_SIZE(ar9170_qmap) != __AR9170_NUM_TXQ);
- BUILD_BUG_ON(NL80211_NUM_ACS > __AR9170_NUM_TXQ);
+ BUILD_BUG_ON((size_t)NL80211_NUM_ACS > (size_t)__AR9170_NUM_TXQ);
mutex_lock(&ar->mutex);
memcpy(&ar->edcf[ar9170_qmap[queue]], param, sizeof(*param));
ret = carl9170_set_qos(ar);
--
2.20.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox