summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-06-27media: stv0297: fix frequency range limitMauro Carvalho Chehab
There was a typo at the lower frequency limit for a DVB-C card, causing the driver to fail while tuning channels at the VHF range. https://bugzilla.kernel.org/show_bug.cgi?id=202083 Fixes: f1b1eabff0eb ("media: dvb: represent min/max/step/tolerance freqs in Hz") Reported-by: Ari Kohtamäki <ari.kohtamaki@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-06-27media: rc: Prefer KEY_NUMERIC_* for number buttons on remotesBastien Nocera
Prefer KEY_NUMERIC_* for number buttons on remotes. Now all the remotes use KEY_NUMERIC_[0-9] for the number buttons rather than keys that could be affected by modifiers (Caps-Lock, or Num-Lock) or regional keymaps. Created using: sed -i 's/KEY_\([0-9]\) /KEY_NUMERIC_\1 /' *.c sed -i 's/KEY_\([0-9]\)}/KEY_NUMERIC_\1}/' *.c sed -i 's/``KEY_\([0-9]\)/``KEY_NUMERIC_\1/' Documentation/media/uapi/rc/rc-tables.rst Signed-off-by: Bastien Nocera <hadess@hadess.net> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-06-27media: dvb_frontend: split dvb_frontend_handle_ioctl functionArnd Bergmann
Over time, dvb_frontend_handle_ioctl() has grown to the point where we now get a warning from the compiler about excessive stack usage: drivers/media/dvb-core/dvb_frontend.c: In function 'dvb_frontend_handle_ioctl': drivers/media/dvb-core/dvb_frontend.c:2692:1: error: the frame size of 1048 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] Almost all of this is used by the dtv_frontend_properties structure in the FE_GET_PROPERTY and FE_GET_FRONTEND commands. Splitting those into separate function reduces the stack usage of the main function to just 136 bytes, the others are under 500 each. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-06-27pinctrl: mediatek: Update cur_mask in mask/mask opsNicolas Boichat
During suspend/resume, mtk_eint_mask may be called while wake_mask is active. For example, this happens if a wake-source with an active interrupt handler wakes the system: irq/pm.c:irq_pm_check_wakeup would disable the interrupt, so that it can be handled later on in the resume flow. However, this may happen before mtk_eint_do_resume is called: in this case, wake_mask is loaded, and cur_mask is restored from an older copy, re-enabling the interrupt, and causing an interrupt storm (especially for level interrupts). Step by step, for a line that has both wake and interrupt enabled: 1. cur_mask[irq] = 1; wake_mask[irq] = 1; EINT_EN[irq] = 1 (interrupt enabled at hardware level) 2. System suspends, resumes due to that line (at this stage EINT_EN == wake_mask) 3. irq_pm_check_wakeup is called, and disables the interrupt => EINT_EN[irq] = 0, but we still have cur_mask[irq] = 1 4. mtk_eint_do_resume is called, and restores EINT_EN = cur_mask, so it reenables EINT_EN[irq] = 1 => interrupt storm as the driver is not yet ready to handle the interrupt. This patch fixes the issue in step 3, by recording all mask/unmask changes in cur_mask. This also avoids the need to read the current mask in eint_do_suspend, and we can remove mtk_eint_chip_read_mask function. The interrupt will be re-enabled properly later on, sometimes after mtk_eint_do_resume, when the driver is ready to handle it. Fixes: 58a5e1b64bb0 ("pinctrl: mediatek: Implement wake handler and suspend resume") Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Acked-by: Sean Wang <sean.wang@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-06-27media: mceusb: disable "nonsensical irdata" messagesA Sun
mceusb device 2304:0225, and likely others, produces numerous [ 4231.111310] mceusb 1-1.1.2:1.0: nonsensical irdata 80 with duration 0 [ 4381.493597] mceusb 1-1.1.2:1.0: nonsensical irdata 80 with duration 0 [ 4410.247568] mceusb 1-1.1.2:1.0: nonsensical irdata 80 with duration 0 ... [60153.264064] mceusb 1-1.1.2:1.0: nonsensical irdata 00 with duration 0 ... due to reception of ambient IR noise. Change these warning messages to debug messages. Signed-off-by: A Sun <as1033x@comcast.net> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-06-27media: rc: remove redundant dev_err messageDing Xiang
devm_ioremap_resource already contains error message, so remove the redundant dev_err message Signed-off-by: Ding Xiang <dingxiang@cmss.chinamobile.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-06-27media: cec-notifier: add new notifier functionsHans Verkuil
In order to support multiple CEC devices for an HDMI connector, and to support cec_connector_info, drivers should use either a cec_notifier_conn_(un)register pair of functions (HDMI drivers) or a cec_notifier_cec_adap_(un)register pair (CEC adapter drivers). This replaces cec_notifier_get_conn/cec_notifier_put. For CEC adapters it is also no longer needed to call cec_notifier_register, cec_register_cec_notifier and cec_notifier_unregister. This is now all handled internally by the new functions. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-06-27media: cec: add struct cec_connector_info supportDariusz Marcinkiewicz
Define struct cec_connector_info in media/cec.h and define CEC_CAP_CONNECTOR_INFO. In a later patch this will be moved to uapi/linux/cec.h. The CEC_CAP_CONNECTOR_INFO capability can be set by drivers, but cec_allocate_adapter() will remove it again until the public API for this can be enabled once all drm drivers wire this up correctly. Also add the cec_fill_conn_info_from_drm and cec_s_conn_info functions, which are needed by drm drivers to fill in the cec_connector info based on a drm_connector. The cec_notifier_(un)register and cec_register_cec_notifier prototypes were moved from cec-notifier.h to cec.h since cec.h no longer includes cec-notifier.h. These headers included each other before, which caused various problems. Due to these changes the seco-cec driver was changed as well: it should include cec-notifier.h, not cec.h. Signed-off-by: Dariusz Marcinkiewicz <darekm@google.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-06-27media: cec-notifier: rename variables, check kstrdup and n->conn_nameHans Verkuil
dev -> hdmi_dev conn -> conn_name Check if n->conn_name is not NULL before calling strcmp. Check the result of kstrdup, and clean up on error. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-06-27mt76: mt7603: fix sparse warnings: warning: incorrect type in assignment ↵Lorenzo Bianconi
(different base types) Fix the following sparse warning in mt7603_mcu_set_eeprom: drivers/net/wireless/mediatek/mt76/mt7603/mcu.c:376:30: sparse: warning: incorrect type in assignment (different base types) drivers/net/wireless/mediatek/mt76/mt7603/mcu.c:376:30: sparse: expected unsigned short [usertype] addr drivers/net/wireless/mediatek/mt76/mt7603/mcu.c:376:30: sparse: got restricted __le16 [usertype] Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt7615: fix sparse warnings: warning: cast from restricted __le16Lorenzo Bianconi
Do not convert {tx,rx}_mcs_map to little-endian since it is already done by mac80211. This patch fix the following sparse warning: drivers/net/wireless/mediatek/mt76/mt7615/mcu.c:1497:25: sparse: warning: cast from restricted __le16 drivers/net/wireless/mediatek/mt76/mt7615/mcu.c:1499:25: sparse: warning: cast from restricted __le16 Fixes: 04b8e65922f6 ("mt76: add mac80211 driver for MT7615 PCIe-based chipsets") Fixes: 3ca0a6f6e9df ("mt7615: mcu: use standard signature for mt7615_mcu_msg_send") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt7615: fix sparse warnings: incorrect type in assignment (different ↵Lorenzo Bianconi
base types) Fix the following sparse warning in mt7615_mcu_bss_info_ext_header: drivers/net/wireless/mediatek/mt76/mt7615/mcu.c:728:30: sparse: sparse: incorrect type in assignment (different base types) drivers/net/wireless/mediatek/mt76/mt7615/mcu.c:728:30: sparse: expected restricted __le32 [usertype] mbss_tsf_offset Reported-by: kbuild test robot <lkp@intel.com> Fixes: 04b8e65922f6 ("mt76: add mac80211 driver for MT7615 PCIe-based chipsets") Fixes: 7339fbc0caa5 ("mt7615: mcu: do not use function pointers whenever possible") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt76u: get rid of {out,in}_max_packetLorenzo Bianconi
Remove {out,in}_max_packet from mt76_usb data structure since they just track last usb endpoint and they are not actually used Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: move nl80211_dfs_regions in mt76_dev data structureLorenzo Bianconi
Move dfs region field in mt76_dev data structure since it is used by all drivers. This is a preliminary patch to add DFS support to mt7615 driver Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt7615: remove cfg80211_chan_def from mt7615_set_channel signatureLorenzo Bianconi
Simplify mt7615_set_channel signature removing cfg80211_chan_def parameter since it is not actually used Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt76u: reduce rx memory footprintLorenzo Bianconi
Reduce rx memory footprint allocating just one SG buffer since for the moment we support just 3839B as maximal size of an A-MSDU. Introduce different SG_MAX_SIZE definitions for TX and RX sides. Moreover set q->buf_size to PAGE_SIZE even for SG case. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt7615: update peer's bssid when state transition occursRyder Lee
This makes sure that the driver update peer's bssid when state transition occurs. Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt7615: fix incorrect settings in mesh modeRyder Lee
Fix wrong settings that will drop packets due to hardware's RX table searching flow. Fixes: f072c7ba2150 ("mt76: mt7615: enable support for mesh") Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt76x02u: fix sparse warnings: should it be static?Lorenzo Bianconi
Fix following sparse warnings in mt76x02_usb_core.c drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c:29:6: warning: symbol 'mt76x02u_tx_complete_skb' was not declared. Should it be static? drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c:37:5: warning: symbol 'mt76x02u_skb_dma_info' was not declared. Should it be static? drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c:96:52: warning: restricted __le16 degrades to integer drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c:74:5: warning: symbol 'mt76x02u_tx_prepare_skb' was not declared. Should it be static? drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c:244:6: warning: symbol 'mt76x02u_init_beacon_config' was not declared. Should it be static? drivers/net/wireless/mediatek/mt76/mt76x02_usb_core.c:262:6: warning: symbol 'mt76x02u_exit_beacon_config' was not declared. Should it be static? Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt7615: take into account extPA when configuring tx powerLorenzo Bianconi
When TSSI calibration is disabled (which it means the device has been equipped with an external power amplifier) we need to refer to different eeprom fields in order to properly configure tx power Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt7615: init per-channel target powerLorenzo Bianconi
Set per-channel target power as the minimum between the regulatory tx power and the value configured in the eeprom Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt7615: add support for per-chain signal strength reportingRyder Lee
Fill in RX status->chain_signal to avoid empty value. Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt7615: simplify mt7615_mcu_set_sta_rec routineLorenzo Bianconi
Move conn_type configuration directly in mt7615_mcu_set_sta_rec and remove sta_rec_convert_vif_type since it is actually used just in mt7615_mcu_set_sta_rec Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt7603: improve hardware rate switching configurationFelix Fietkau
Now that tx status reporting can figure out the first attempted rate, we can make switching from lower rates to higher rates more conservative. This reduces retries under bad link conditions and ensures that fallback rates get more test coverage Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt7603: rework and fix tx status reportingFelix Fietkau
Tx status reporting on mt7603 has a number of issues: - the hardware can alter the first rate index, but it is not reported to the driver - probing is very imprecise, because it alters the per-client rate set, but only considers info->status.rates for rate selection of a single probe packet - short/long GI selection has limitations, which are not accurately reported to mac80211 - if rates are changed while packets are in flight, tx status reports for the old rate set might be processed based on the new selection This led to very suboptimal rate selection with minstrel_ht. This patch completely reworks tx status reporting to get rid of these limitations: - Store the previous and current rate set in the driver + the TSF value at the time of the switch. - Use the tx status TSF value to determine which rate set needs to be used as reference. - Report only short or long GI rates for a single status event, not a mix. - The hardware reports the last used rate index. Use it along with the retry count to figure out what rate was used for the first attempt. - Use the same retry count value for all rate slots to make this calculation work. - Derive the probe rate from the current rateset instead of the skb cb - Do not wait for a status report for the probe frame before removing the probe rate from the rate table. Do it immediately after it was referenced in a tx status report. - Use the first half of the first rate retry budget for the probe rate in order to avoid using too many retries on that rate With this patch, throughput under bad link conditions is improved significantly, and there is a lot less rate fluctuation going on. Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt76x0: fix RF frontend initialization for external PAFelix Fietkau
When loading EEPROM data from flash, the RF frontend settings need to be initialized from flash data. Without this, the chip loads the wrong values from its internal eFuse ROM. Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt7615: remove key check in mt7615_mcu_set_wtbl_keyLorenzo Bianconi
Do not check key pointer in mt7615_mcu_set_wtbl_key since if set_key_cmd is SET_KEY, key will be always not NULL. This patch will address a false positive reported by Coverity-Scan Addresses-Coverity-ID: 1445463 ("Dereference after null check") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt7615: remove unused variable in mt7615_mcu_set_bcnLorenzo Bianconi
Remove tim_len in mt7615_mcu_set_bcn since it is not actually used and ieee80211_beacon_get_tim checks if tim_length is NULL Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt7615: fix slow performance when enable encryptionRyder Lee
Fix wrong WCID assignment and add RKV (RX Key of this entry is valid) flag to check if peer uses the same configuration with previous handshaking. If the configuration is mismatch, WTBL indicates a “cipher mismatch” to stop SEC decryption to prevent the packet from damage. Suggested-by: YF Luo <yf.luo@mediatek.com> Suggested-by: Yiwei Chung <yiwei.chung@mediatek.com> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt7615: enable support for meshRyder Lee
Enable NL80211_IFTYPE_MESH_POINT and update its path. Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: Remove set but not used variables 'pid' and 'final_mpdu'YueHaibing
Fixes gcc '-Wunused-but-set-variable' warnings: drivers/net/wireless/mediatek/mt76/mt7603/mac.c: In function mt7603_fill_txs: drivers/net/wireless/mediatek/mt76/mt7603/mac.c:969:5: warning: variable pid set but not used [-Wunused-but-set-variable] drivers/net/wireless/mediatek/mt76/mt7603/mac.c:961:7: warning: variable final_mpdu set but not used [-Wunused-but-set-variable] drivers/net/wireless/mediatek/mt76/mt7615/mac.c: In function mt7615_fill_txs: drivers/net/wireless/mediatek/mt76/mt7615/mac.c:555:5: warning: variable pid set but not used [-Wunused-but-set-variable] drivers/net/wireless/mediatek/mt76/mt7615/mac.c:552:19: warning: variable final_mpdu set but not used [-Wunused-but-set-variable] They are never used, so can be removed. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: move mt76_get_rate in mt76-moduleLorenzo Bianconi
Move mt7603_get_rate in mac80211.c and rename it to mt76_get_rate since it is shared between mt7603 and mt7615 drivers Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt7615: rearrange locking in mt7615_configLorenzo Bianconi
Since all the routines in mt7615_config grub mt76.mutex moves mutex_lock/mutex_unlock at the beginning/end of mt7615_config Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt7615: init get_txpower mac80211 callbackLorenzo Bianconi
Initialize get_txpower mac80211 callback to mt76_get_txpower in order to report the configured tx power to mac80211 Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt7615: add the capability to configure tx powerLorenzo Bianconi
Introduce mt7615_mcu_set_tx_power routine in order to cap tx power according to the value configured by the user Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: generalize mt76_get_txpower for 4x4:4 devicesLorenzo Bianconi
Genralize mt76_get_txpower routine for 4x4:4 capable devices in order to be reused in mt7615 driver Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt7615: select wifi band according to eepromLorenzo Bianconi
Select supported band according to the value read from eeprom mtd/otp partition Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt7615: add support for mtd eeprom parsingLorenzo Bianconi
Calibration data are often available on a specific mtd partition on embedded devices. Take into account eeprom calibration data if available. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: move mt76_insert_ccmp_hdr in mt76-moduleLorenzo Bianconi
Move mt7615_insert_ccmp_hdr in mac80211.c and rename it in mt76_insert_ccmp_hdr since it is shared between mt7603 and mt7615 drivers Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt76x02: fix tx reordering on rate control probing without a-mpduFelix Fietkau
To avoid aggregating rate control probing packets with other traffic, and to ensure that the probing rate gets used, probing packets get assigned a different internal queueing priority. This causes packets to be transmitted in a different order, which is compensated by the receiver side reordering. However, if A-MPDU is disabled, this reordering can become visible to upper layers on the receiver side. Disable the priority change if A-MPDU is disabled. Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt76x02: fix tx status reporting issuesFelix Fietkau
When the hardware falls back to lower rates for a transmit attempt, only the first status report will show the number of retries correctly. The frames that follow will report the correct final rate, but number of retries set to 0. This can cause the rate control module to vastly underestimate the number of retransmissions per rate. To fix this, we need to keep track of the initial requested tx rate per packet and pass it to the status information. For frames with tx status requested, this is simple: use the rate configured in info->control.rates[0] as reference. For no-skb tx status information, we have to encode the requested tx rate in the packet id (and make it possible to distinguish it from real packet ids). To do that, reduce the packet id field size by one bit, and use that bit to indicate packet id vs rate. This change also improves reporting by filling the status rate array with rates from first rate to final rate, taking the same steps as the hardware fallback table. This matters in corner cases like MCS8 on HT, where the fallback target is MCS0, not MCS7. Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: fix setting chan->max_powerFelix Fietkau
When setting chan->max_power after registering the wiphy, chan->max_reg_power needs to be used as a limit Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27mt76: mt7603: fix reading target tx power from eepromFelix Fietkau
For the external PA (TSSI OFF) case, the target power needs to be read from a different location in EEPROM Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-06-27PCI: PM/ACPI: Refresh all stale power state data in pci_pm_complete()Rafael J. Wysocki
In pci_pm_complete() there are checks to decide whether or not to resume devices that were left in runtime-suspend during the preceding system-wide transition into a sleep state. They involve checking the current power state of the device and comparing it with the power state of it set before the preceding system-wide transition, but the platform component of the device's power state is not handled correctly in there. Namely, on platforms with ACPI, the device power state information needs to be updated with care, so that the reference counters of power resources used by the device (if any) are set to ensure that the refreshed power state of it will be maintained going forward. To that end, introduce a new ->refresh_state() platform PM callback for PCI devices, for asking the platform to refresh the device power state data and ensure that the corresponding power state will be maintained going forward, make it invoke acpi_device_update_power() (for devices with ACPI PM) on platforms with ACPI and make pci_pm_complete() use it, through a new pci_refresh_power_state() wrapper function. Fixes: a0d2a959d3da (PCI: Avoid unnecessary resume after direct-complete) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-06-27PCI / ACPI: Add _PR0 dependent devicesMika Westerberg
If otherwise unrelated PCI devices share ACPI power resources turning them on causes the devices to enter D0uninitialized power state which may cause problems. For example in Intel Ice Lake two root ports (RP0 and RP1), Thunderbolt controller (NHI) and xHCI controller all share power resources as can be ween in the topology below where power resources are marked with []: Host bridge | +- RP0 ---\ +- RP1 ---|--+--> [TBT] +- NHI --/ | | | | v +- xHCI --> [D3C] In a situation where all devices sharing the power resources are in D3cold (the power resources are turned off) and for example the Thunderbolt controller is runtime resumed resulting that the power resources are turned on. This means that the other devices sharing them (RP0, RP1 and xHCI) are transitioned into D0uninitialized state. If they were configured to trigger wake (PME) on a certain event that configuration gets lost after reset so we would need to re-initialize them to get the wakeup working as expected again. To do so we would need to runtime resume all of them to make sure their registers get restored properly before we can runtime suspend them again. Since we just added concept of "_PR0 dependent device" we can solve this by calling the relevant add/remove functions when the PCI device is bind to its ACPI representation. If it has power resources the PCI device will be added as dependent device to them and runtime resumed whenever they are physically turned on. This should make sure PCI core can reconfigure wakes after the device is transitioned into D0uninitialized. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-06-27ACPI / PM: Introduce concept of a _PR0 dependent deviceMika Westerberg
If there are shared power resources between otherwise unrelated devices turning them on causes the other devices sharing them to be powered up as well. In case of PCI devices go into D0uninitialized state meaning that if they were configured to trigger wake that configuration is lost at this point. For this reason introduce a concept of "_PR0 dependent device" that can be added to any ACPI device that has power resources. The dependent device will be included in a list of dependent devices for all power resources returned by the ACPI device's _PR0 (assuming it has one). Whenever a power resource having dependent devices is turned physically on (its _ON method is called) we runtime resume all of them to allow their driver or in case of PCI the PCI core to re-initialize the device and its wake configuration. This adds two functions that can be used to add and remove these dependent devices. Note the dependent device does not necessary need share power resources so this functionality can be used to add "software dependencies" as well if needed. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-06-27PCI / ACPI: Use cached ACPI device state to get PCI device power stateMika Westerberg
The ACPI power state returned by acpi_device_get_power() may depend on the configuration of ACPI power resources in the system which may change any time after acpi_device_get_power() has returned, unless the reference counters of the ACPI power resources in question are set to prevent that from happening. Thus it is invalid to use acpi_device_get_power() in acpi_pci_get_power_state() the way it is done now and the value of the ->power.state field in the corresponding struct acpi_device objects (which reflects the ACPI power resources reference counting, among other things) should be used instead. As an example where this becomes an issue is Intel Ice Lake where the Thunderbolt controller (NHI), two PCIe root ports (RP0 and RP1) and xHCI all share the same power resources. The following picture with power resources marked with [] shows the topology: Host bridge | +- RP0 ---\ +- RP1 ---|--+--> [TBT] +- NHI --/ | | | | v +- xHCI --> [D3C] Here TBT and D3C are the shared ACPI power resources. ACPI _PR3() method of the devices in question returns either TBT or D3C or both. Say we runtime suspend first the root ports RP0 and RP1, then NHI. Now since the TBT power resource is still on when the root ports are runtime suspended their dev->current_state is set to D3hot. When NHI is runtime suspended TBT is finally turned off but state of the root ports remain to be D3hot. Now when the xHCI is runtime suspended D3C gets also turned off. PCI core thus has power states of these devices cached in their dev->current_state as follows: RP0 -> D3hot RP1 -> D3hot NHI -> D3cold xHCI -> D3cold If the user now runs lspci for instance, the result is all 1's like in the below output (00:07.0 is the first root port, RP0): 00:07.0 PCI bridge: Intel Corporation Device 8a1d (rev ff) (prog-if ff) !!! Unknown header type 7f Kernel driver in use: pcieport In short the hardware state is not in sync with the software state anymore. The exact same thing happens with the PME polling thread which ends up bringing the root ports back into D0 after they are runtime suspended. For this reason, modify acpi_pci_get_power_state() so that it uses the ACPI device power state that was cached by the ACPI core. This makes the PCI device power state match the ACPI device power state regardless of state of the shared power resources which may still be on at this point. Link: https://lore.kernel.org/r/20190618161858.77834-2-mika.westerberg@linux.intel.com Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-06-27ACPI: PM: Allow transitions to D0 to occur in special casesRafael J. Wysocki
If a device with ACPI PM is left in D0 during a system-wide transition to the S3 (suspend-to-RAM) or S4 (hibernation) sleep state, the actual state of the device need not be D0 during resume from it, although its power.state value will still reflect D0 (that is, the power state from before the system-wide transition). In that case, the acpi_device_set_power() call made to ensure that the power state of the device will be D0 going forward has no effect, because the new state (D0) is equal to the one reflected by the device's power.state value. That does not affect power resources, which are taken care of by acpi_resume_power_resources() called from acpi_pm_finish() during resume from system-wide sleep states, but it still may be necessary to invoke _PS0 for the device on top of that in order to finalize its transition to D0. For this reason, modify acpi_device_set_power() to allow transitions to D0 to occur even if D0 is the current power state of the device according to its power.state value. That will not affect power resources, which are assumed to be in the right configuration already (as reflected by the current values of their reference counters), but it may cause _PS0 to be evaluated for the device. However, evaluating _PS0 for a device already in D0 may lead to confusion in general, so invoke _PSC (if present) to check the device's current power state upfront and only evaluate _PS0 for it if _PSC has returned a power state different from D0. [If _PSC is not present or the evaluation of it fails, the power state of the device is assumed to be D0 at this point.] Fixes: 20dacb71ad28 (ACPI / PM: Rework device power management to follow ACPI 6) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-06-27ACPI: PM: Avoid evaluating _PS3 on transitions from D3hot to D3coldRafael J. Wysocki
If the power state of a device with ACPI PM is changed from D3hot to D3cold, it merely is a matter of dropping references to additional power resources (specifically, those in the list returned by _PR3), and the _PS3 method should not be invoked for the device then (as it has already been evaluated during the previous transition to D3hot). Fixes: 20dacb71ad28 (ACPI / PM: Rework device power management to follow ACPI 6) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-06-27proc: remove useless d_is_dir() checkChristian Brauner
Remove the d_is_dir() check from tgid_pidfd_to_pid(). It is pointless since you should never get &proc_tgid_base_operations for f_op on a non-directory. Suggested-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Christian Brauner <christian@brauner.io>
generated by cgit (git 2.34.1) at 2025-09-19 12:25:09 +0000