These changes build upon the existing Android kernel wakeup reason code
to:
* improve the positioning of suspend abort logging calls in suspend flow
* add logging of abnormal wakeup reasons like unexpected HW IRQs and
IRQs configured as both wake-enabled and no-suspend
* add support for capturing deferred-processing threaded nested IRQs as
wakeup reasons rather than their synchronously-processed parents
Bug: 150970830
Bug: 140217217
Bug: 120445600
Signed-off-by: Kelly Rossmoyer <krossmo@google.com>
Change-Id: I903b811a0fe11a605a25815c3a341668a23de700
The cpufreq_global_kobject is only used internally by cpufreq.c
after commit 2361be2366 ("cpufreq: Don't create empty
/sys/devices/system/cpu/cpufreq directory").
Make it static.
Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
[ rjw: Add empty line after cpufreq_global_kobject definition ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 183edb20e60a73925bf3b60e2f4796898167262f)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ib3f1ca9000266c968ddb1af9f8df8e9c974a11dc
dma_buf_vmap() on ION buffers returns -EOPNOTSUPP
if the heap of ION buffer does not implement its own
vmap callback. Even the default system heap does not
implement vmap callback, so vmap attempt of ION buffer
will always fail. However vmap of ION buffer is much
more reasonable to be supported by default than errors,
so this patch implements vmap callback.
Bug: 150258007
Signed-off-by: Hyesoo Yu <hyesoo.yu@samsung.com>
Change-Id: I243eb7ded49843e719532ad1b1cb7ab37e84460d
Comparing ABI against expected definition (abi_gki_aarch64.xml)
========================================================
ABI report has been created at /home/docker/repo/out_abi/android-5.4/dist/abi.report
ABI DIFFERENCES HAVE BEEN DETECTED! (RC=8)
========================================================
Leaf changes summary: 2 artifacts changed
Changed leaf types summary: 1 leaf type changed
Removed/Changed/Added functions summary: 1 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
1 Removed function:
[D] 'function bool pcie_aspm_enabled(pci_dev*)'
'struct pci_dev at pci.h:291:1' changed:
type size changed from 16448 to 16384 (in bits)
2 data member deletions:
'unsigned int pci_dev::ltr_path', at offset 31 (in bits) at pci.h:363:1
'pcie_link_state* pci_dev::link_state', at offset 1216 (in bits) at pci.h:362:1
there are data member changes:
'unsigned int pci_dev::eetlp_prefix_path' offset changed from 30 to 31 (in bits) (by +1 bits)
'pci_channel_state_t pci_dev::error_state' offset changed from 1312 to 1216 (in bits) (by -96 bits)
'device pci_dev::dev' offset changed from 1344 to 1280 (in bits) (by -64 bits)
'int pci_dev::cfg_size' offset changed from 8128 to 8064 (in bits) (by -64 bits)
'unsigned int pci_dev::irq' offset changed from 8160 to 8096 (in bits) (by -64 bits)
'resource pci_dev::resource[11]' offset changed from 8192 to 8128 (in bits) (by -64 bits)
'bool pci_dev::match_driver' offset changed from 13824 to 13760 (in bits) (by -64 bits)
'unsigned int pci_dev::reset_fn' offset changed from 13824 to 13760 (in bits) (by -64 bits)
'pci_dev_flags_t pci_dev::dev_flags' offset changed from 13872 to 13808 (in bits) (by -64 bits)
'atomic_t pci_dev::enable_cnt' offset changed from 13888 to 13824 (in bits) (by -64 bits)
'u32 pci_dev::saved_config_space[16]' offset changed from 13920 to 13856 (in bits) (by -64 bits)
'hlist_head pci_dev::saved_cap_space' offset changed from 14464 to 14400 (in bits) (by -64 bits)
'bin_attribute* pci_dev::rom_attr' offset changed from 14528 to 14464 (in bits) (by -64 bits)
'int pci_dev::rom_attr_enabled' offset changed from 14592 to 14528 (in bits) (by -64 bits)
'bin_attribute* pci_dev::res_attr[11]' offset changed from 14656 to 14592 (in bits) (by -64 bits)
'bin_attribute* pci_dev::res_attr_wc[11]' offset changed from 15360 to 15296 (in bits) (by -64 bits)
'const attribute_group** pci_dev::msi_irq_groups' offset changed from 16064 to 16000 (in bits) (by -64 bits)
'pci_vpd* pci_dev::vpd' offset changed from 16128 to 16064 (in bits) (by -64 bits)
'phys_addr_t pci_dev::rom' offset changed from 16192 to 16128 (in bits) (by -64 bits)
'size_t pci_dev::romlen' offset changed from 16256 to 16192 (in bits) (by -64 bits)
'char* pci_dev::driver_override' offset changed from 16320 to 16256 (in bits) (by -64 bits)
'unsigned long int pci_dev::priv_flags' offset changed from 16384 to 16320 (in bits) (by -64 bits)
76 impacted interfaces
========================================================
Bug: 153142844
Signed-off-by: John Stultz <john.stultz@linaro.org>
Change-Id: I44bfe45daf181d3116974f46e8a0ad79f0bd8ac8
PCIEPORTBUS is causing trouble for some vendors so
drop it for now.
Bug: 153142844
Signed-off-by: John Stultz <john.stultz@linaro.org>
Change-Id: I6680ad8ba9caa938554735d07a4c6cb4cfb6c5f9
Add HEALTH_WARM, HEALTH_COOL and HEALTH_HOT to the health enum.
Bug: 149071038
Test: Builds
Link: https://lore.kernel.org/linux-pm/20200116175039.1317-3-dmurphy@ti.com/
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Tested-by: Guru Das Srinagesh <gurus@codeaurora.org>
Signed-off-by: Sandeep Patil <sspatil@google.com>
Change-Id: I5a99577e8c8c38c2ea10a339223c177d18c93d37
Leaf changes summary: 3 artifacts changed
Changed leaf types summary: 3 leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
'struct mmc_host at host.h:271:1' changed:
type size hasn't changed
1 data member insertion:
'bool mmc_host::hsq_enabled', at offset 12272 (in bits) at host.h:467:1
86 impacted interfaces:
function int __mmc_claim_host(mmc_host*, mmc_ctx*, atomic_t*)
function int __mmc_send_status(mmc_card*, u32*, unsigned int)
function int __sdhci_add_host(sdhci_host*)
function int mmc_add_host(mmc_host*)
function mmc_host* mmc_alloc_host(int, device*)
function int mmc_app_cmd(mmc_host*, mmc_card*)
function unsigned int mmc_calc_max_discard(mmc_card*)
function int mmc_can_erase(mmc_card*)
function bool mmc_can_gpio_cd(mmc_host*)
function int mmc_can_sanitize(mmc_card*)
function int mmc_can_secure_erase_trim(mmc_card*)
function int mmc_can_trim(mmc_card*)
function int mmc_cmdq_disable(mmc_card*)
function int mmc_cmdq_enable(mmc_card*)
function void mmc_cqe_post_req(mmc_host*, mmc_request*)
function int mmc_cqe_recovery(mmc_host*)
function int mmc_cqe_start_req(mmc_host*, mmc_request*)
function int mmc_detect_card_removed(mmc_host*)
function void mmc_detect_change(mmc_host*, unsigned long int)
function int mmc_erase(mmc_card*, unsigned int, unsigned int, unsigned int)
function int mmc_erase_group_aligned(mmc_card*, unsigned int, unsigned int)
function int mmc_flush_cache(mmc_card*)
function void mmc_free_host(mmc_host*)
function void mmc_get_card(mmc_card*, mmc_ctx*)
function int mmc_get_ext_csd(mmc_card*, unsigned char**)
function int mmc_gpio_get_cd(mmc_host*)
function int mmc_gpio_get_ro(mmc_host*)
function int mmc_gpiod_request_cd(mmc_host*, const char*, unsigned int, bool, unsigned int, bool*)
function void mmc_gpiod_request_cd_irq(mmc_host*)
function int mmc_gpiod_request_ro(mmc_host*, const char*, unsigned int, unsigned int, bool*)
function int mmc_hw_reset(mmc_host*)
function int mmc_of_parse(mmc_host*)
function void mmc_put_card(mmc_card*, mmc_ctx*)
function int mmc_register_driver(mmc_driver*)
function int mmc_regulator_get_supply(mmc_host*)
function int mmc_regulator_set_ocr(mmc_host*, regulator*, unsigned short int)
function int mmc_regulator_set_vqmmc(mmc_host*, mmc_ios*)
function void mmc_release_host(mmc_host*)
function void mmc_remove_host(mmc_host*)
function void mmc_request_done(mmc_host*, mmc_request*)
function void mmc_retune_pause(mmc_host*)
function void mmc_retune_release(mmc_host*)
function void mmc_retune_unpause(mmc_host*)
function void mmc_run_bkops(mmc_card*)
function int mmc_send_status(mmc_card*, unsigned int*)
function int mmc_send_tuning(mmc_host*, u32, int*)
function void mmc_set_data_timeout(mmc_data*, const mmc_card*)
function int mmc_start_request(mmc_host*, mmc_request*)
function int mmc_switch(mmc_card*, unsigned char, unsigned char, unsigned char, unsigned int)
function void mmc_unregister_driver(mmc_driver*)
function int mmc_wait_for_cmd(mmc_host*, mmc_command*, int)
function void mmc_wait_for_req(mmc_host*, mmc_request*)
function int sdhci_add_host(sdhci_host*)
function void sdhci_cleanup_host(sdhci_host*)
function void sdhci_enable_clk(sdhci_host*, u16)
function void sdhci_enable_v4_mode(sdhci_host*)
function sdhci_host* sdhci_pltfm_init(platform_device*, const sdhci_pltfm_data*, size_t)
function void sdhci_remove_host(sdhci_host*, int)
function void sdhci_request(mmc_host*, mmc_request*)
function void sdhci_reset(sdhci_host*, u8)
function int sdhci_runtime_resume_host(sdhci_host*, int)
function int sdhci_runtime_suspend_host(sdhci_host*)
function void sdhci_set_bus_width(sdhci_host*, int)
function int sdhci_setup_host(sdhci_host*)
function void sdio_claim_host(sdio_func*)
function int sdio_claim_irq(sdio_func*, sdio_irq_handler_t*)
function int sdio_disable_func(sdio_func*)
function int sdio_enable_func(sdio_func*)
function unsigned char sdio_f0_readb(sdio_func*, unsigned int, int*)
function void sdio_f0_writeb(sdio_func*, unsigned char, unsigned int, int*)
function mmc_pm_flag_t sdio_get_host_pm_caps(sdio_func*)
function int sdio_memcpy_fromio(sdio_func*, void*, unsigned int, int)
function int sdio_memcpy_toio(sdio_func*, unsigned int, void*, int)
function u8 sdio_readb(sdio_func*, unsigned int, int*)
function u32 sdio_readl(sdio_func*, unsigned int, int*)
function int sdio_readsb(sdio_func*, void*, unsigned int, int)
function int sdio_register_driver(sdio_driver*)
function void sdio_release_host(sdio_func*)
function int sdio_release_irq(sdio_func*)
function int sdio_set_block_size(sdio_func*, unsigned int)
function int sdio_set_host_pm_flags(sdio_func*, mmc_pm_flag_t)
function void sdio_signal_irq(mmc_host*)
function void sdio_unregister_driver(sdio_driver*)
function void sdio_writeb(sdio_func*, u8, unsigned int, int*)
function void sdio_writel(sdio_func*, u32, unsigned int, int*)
function int sdio_writesb(sdio_func*, unsigned int, void*, int)
'struct sdhci_host at sdhci.h:372:1' changed:
type size hasn't changed
1 data member insertion:
'bool sdhci_host::always_defer_done', at offset 5400 (in bits) at sdhci.h:538:1
12 impacted interfaces:
function int __sdhci_add_host(sdhci_host*)
function int sdhci_add_host(sdhci_host*)
function void sdhci_cleanup_host(sdhci_host*)
function void sdhci_enable_clk(sdhci_host*, u16)
function void sdhci_enable_v4_mode(sdhci_host*)
function sdhci_host* sdhci_pltfm_init(platform_device*, const sdhci_pltfm_data*, size_t)
function void sdhci_remove_host(sdhci_host*, int)
function void sdhci_reset(sdhci_host*, u8)
function int sdhci_runtime_resume_host(sdhci_host*, int)
function int sdhci_runtime_suspend_host(sdhci_host*)
function void sdhci_set_bus_width(sdhci_host*, int)
function int sdhci_setup_host(sdhci_host*)
'struct sdhci_ops at sdhci.h:611:1' changed:
type size changed from 1728 to 1792 (in bits)
1 data member insertion:
'void ()* sdhci_ops::request_done', at offset 1728 (in bits) at sdhci.h:650:1
12 impacted interfaces:
function int __sdhci_add_host(sdhci_host*)
function int sdhci_add_host(sdhci_host*)
function void sdhci_cleanup_host(sdhci_host*)
function void sdhci_enable_clk(sdhci_host*, u16)
function void sdhci_enable_v4_mode(sdhci_host*)
function sdhci_host* sdhci_pltfm_init(platform_device*, const sdhci_pltfm_data*, size_t)
function void sdhci_remove_host(sdhci_host*, int)
function void sdhci_reset(sdhci_host*, u8)
function int sdhci_runtime_resume_host(sdhci_host*, int)
function int sdhci_runtime_suspend_host(sdhci_host*)
function void sdhci_set_bus_width(sdhci_host*, int)
function int sdhci_setup_host(sdhci_host*)
Bug: 151514181
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I08c570140f576438d01c26aca41f5ffb3525628d
The Spreadtrum host controller supports HW busy detection for commands with
R1B responses, but also for I/O operations. This means when the host gets a
transfer complete event, that always indicates the busy signal is released.
Let's inform the mmc core about this, via setting the corresponding
MMC_CAP_WAIT_WHILE_BUSY flag, as to remove some redundant software busy
polling.
bug: 151514181
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/96f16647f6a6e8cb058c44e46c61b122df027059.1582535202.git.baolin.wang7@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit 55fc7d93a55b70c016982f9d9cba02ac789d88c6)
Change-Id: I3d7bc139aa5dd6f3949ce2f59626f426e7271708
Add missing MODULE_LICENSE() and MODULE_DESCRIPTION() in hsq driver to
fix below warning when compiling the hsq as a module.
"WARNING: modpost: missing MODULE_LICENSE() in drivers/mmc/host/mmc_hsq.o".
bug: 151514181
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/98ce471185f037fce57520763621590588766381.1582161803.git.baolin.wang7@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit d1709abb8cc39640e9647b3c0df4451d71bf2841)
Change-Id: Iab828050cccfc59d9a1005554943f32859599acd
When using the host software queue, it will trigger the next request in
irq handler without a context switch. But the sdhci_request() can not be
called in interrupt context when using host software queue for some host
drivers, due to the get_cd() ops can be sleepable.
But for some host drivers, such as Spreadtrum host driver, the card is
nonremovable, so the get_cd() ops is not sleepable, which means we can
complete the data request and trigger the next request in irq handler
to remove the context switch for the Spreadtrum host driver.
As suggested by Adrian, we should introduce a request_atomic() API to
indicate that a request can be called in interrupt context to remove
the context switch when using mmc host software queue. But this should
be done in another thread to convert the users of mmc host software queue.
Thus we can introduce a variable in struct sdhci_host to indicate that
we will always to defer to complete requests when using the host software
queue.
bug: 151514181
Suggested-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/e693e7a29beb3c1922b333f4603ea81f43d5c5b1.1581478568.git.baolin.wang7@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit 4730831c7d2e28c2e912b2c71066b9cf072f7625)
Change-Id: I81195265143e9bb8c850614950cdea0fe8032d6e
Add request_done ops for struct sdhci_ops as a preparation in case some
host controllers have different method to complete one request, such as
supporting request completion of MMC software queue.
bug: 151514181
Suggested-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/1539c801c8bbdbcd1d86f8c2dab375f5803c765a.1581478568.git.baolin.wang7@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit 1774b0021405b4d312499095f6d3919b5bdf3e3b)
Change-Id: Ida382cff72fb6352be3fefc7ccf3166f48eb72fd
Enable the MMC host software queue for the SD card if the host controller
supports the MMC host software queue.
On my Spreadtrum platform, I did not see any obvious performance changes
in 4K block size when changing to use hsq for the SD cards, I think the
reason is the SD card works at a low speed on my platform, and most of
time is spent in the hardware. But we can see some obvious improvements
when enabling the packed request based on hsq, that's why we still add hsq
support for the SD cards.
bug: 151514181
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/0065b4631fef2d61c3b89d14a4ea4f2b7499ea56.1581478568.git.baolin.wang7@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit 045d705dc1fba0d881fe22ad76ebe1b44647cdac)
Change-Id: Ib3a9b3b4363d168950981b0fb7c2cbaa4810dd00
Now the MMC read/write stack will always wait for previous request is
completed by mmc_blk_rw_wait(), before sending a new request to hardware,
or queue a work to complete request, that will bring context switching
overhead and spend some extra time to poll the card for busy completion
for I/O writes via sending CMD13, especially for high I/O per second
rates, to affect the IO performance.
Thus this patch introduces MMC software queue interface based on the
hardware command queue engine's interfaces, which is similar with the
hardware command queue engine's idea, that can remove the context
switching. Moreover we set the default queue depth as 64 for software
queue, which allows more requests to be prepared, merged and inserted
into IO scheduler to improve performance, but we only allow 2 requests
in flight, that is enough to let the irq handler always trigger the
next request without a context switch, as well as avoiding a long latency.
Moreover the host controller should support HW busy detection for I/O
operations when enabling the host software queue. That means, the host
controller must not complete a data transfer request, until after the
card stops signals busy.
From the fio testing data in cover letter, we can see the software
queue can improve some performance with 4K block size, increasing
about 16% for random read, increasing about 90% for random write,
though no obvious improvement for sequential read and write.
Moreover we can expand the software queue interface to support MMC
packed request or packed command in future.
bug: 151514181
Change-Id: Ib343d80bf060c2c6543e6038b474f3c5bf93dbb2
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/4409c1586a9b3ed20d57ad2faf6c262fc3ccb6e2.1581478568.git.baolin.wang7@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit 511ce378e16f07b66ab78118587b7cc6ac197364)
When doing Clang builds of the kernel, it is possible to link with
either ld.bfd (binutils) or ld.lld (LLVM), but it is not possible to
discover this from a running kernel. Add the "$LD -v" output to
/proc/version.
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Fangrui Song <maskray@google.com>
Reviewed-by: Sedat Dilek <sedat.dilek@gmail.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Bug: 153484457
(cherry picked from commit 6f04f056df3c
https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
for-next)
Change-Id: Ifa5a98fe159392862e8d07a733c0f141fa9c7715
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
GENKSYMS shouldn't care about the __must_check compiler flag. So strip
it out for GENKSYMS.
Signed-off-by: Will McVicker <willmcvicker@google.com>
Bug: 153478475
Test: compile, check crc
Change-Id: I512639a4f719037728ffbfa48e7b766510c7d726
(cherry picked from commit a4923652a413e10e66d4802637c9e433e6944fc7)
The Spreadtrum SC27XX series PMICs supply the USB charger type detection
function, and related registers are located on the PMIC global registers
region, thus we implement and export this function in the MFD driver for
users to get the USB charger type.
bug: 153500755
Change-Id: I18ef05b27c61ad915c86ddf26420fe92c8516552
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
(cherry picked from commit 2a7e7274f3d43d2a072cab25c0035dc994903bb9)
This reverts commit 0f5cb8cc27.
This commit will cause below warnings, since our EIC controller can support
differnt banks on different Spreadtrum SoCs, and each bank has its own base
address, we will get invalid resource warning if the bank number is less than
SPRD_EIC_MAX_BANK on some Spreadtrum SoCs.
So we should not use devm_platform_ioremap_resource() here to remove the
warnings.
[ 1.118508] sprd-eic 40210000.gpio: invalid resource
[ 1.118535] sprd-eic 40210000.gpio: invalid resource
[ 1.119034] sprd-eic 40210080.gpio: invalid resource
[ 1.119055] sprd-eic 40210080.gpio: invalid resource
[ 1.119462] sprd-eic 402100a0.gpio: invalid resource
[ 1.119482] sprd-eic 402100a0.gpio: invalid resource
[ 1.119893] sprd-eic 402100c0.gpio: invalid resource
[ 1.119913] sprd-eic 402100c0.gpio: invalid resource
bug: 153500755
Change-Id: Iee84dfa1c7720cf53a13db8611650291f7e23b92
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/8d3579f4b49bb675dc805035960f24852898be28.1585734060.git.baolin.wang7@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 4ed7d7dd4890bb8120a3e77c16191a695fdfcc5a)
For Spreadtrum pin controller, it will be the high impedance
mode if disable input and output mode for a pin. Thus add
PIN_CONFIG_BIAS_HIGH_IMPEDANCE configuration to support it.
bug: 153500755
Change-Id: Ia5e1104a569da2a015d72a7db546ecc23bec5790
Signed-off-by: Linhua Xu <linhua.xu@unisoc.com>
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/3bdac4c2673b54c940e511f3fa569ee33b87b8d5.1585124562.git.baolin.wang7@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 1592c4b9935fa8a3b7c297955bb872a357e5a3b6)
The Spreadtrum pin controller did not supply registers to set high level
or low level for output mode, instead we should let the pin controller
current configuration drive values on the line. So we should use the
PIN_CONFIG_OUTPUT_ENABLE configuration to enable or disable the output
mode.
bug: 153500755
Change-Id: I290165a7239ddf75281d9a4eaf357cd576f1d009
[Baolin Wang changes the commit message]
Fixes: 41d32cfce1 ("pinctrl: sprd: Add Spreadtrum pin control driver")
Signed-off-by: Linhua Xu <linhua.xu@unisoc.com>
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/8a6f91b49c17beb218e46b23084f59a7c7260f86.1585124562.git.baolin.wang7@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit bb0f472f96fa2bda2c3e412cd84f16b15d992a56)
We've saved the double data flag in the device data, so we should
use it when programming a block.
bug: 153500755
Change-Id: I2d37f5ffcdc2a22c7cefa2d49d0c32001fb489e8
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20200323150007.7487-4-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 4bd5a15d933c1703910c756d961dbbd2e6d52181)
We have some cases that will programme the eFuse block partially multiple
times, so we should allow the block to be programmed again if it was
programmed partially. But we should lock the block if the whole block
was programmed. Thus add a condition to validate if we need lock the
block or not.
Moreover we only enable the auto-check function when locking the block.
bug: 153500755
Change-Id: Ia019890c01781a298c6676ede19a6b2da2728000
Signed-off-by: Freeman Liu <freeman.liu@unisoc.com>
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20200323150007.7487-3-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 5af25388ba250ae9624a22587cc98685dc6d4e9e)
According to the Spreadtrum eFuse specification, we should write 0 to
the block to trigger the lock operation.
bug: 153500755
Fixes: 096030e7f449 ("nvmem: sprd: Add Spreadtrum SoCs eFuse support")
Change-Id: I4080e4a4ed1de45f79ce2fbadd1b66aa53b8495b
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Freeman Liu <freeman.liu@unisoc.com>
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20200323150007.7487-2-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit c66ebde4d988b592e8f0008e04c47cc4950a49d3)
On new Spreadtrum platforms, when the CPU enters idle, it will close
the DMA controllers' clock to save power if the DMA controller is not
busy. Moreover the DMA controller's busy signal depends on the DMA
enable flag and the request pending flag.
When DMA controller starts to transfer data, which means we already
set the DMA enable flag, but now we should also set the request pending
flag, in case the DMA clock will be closed accidentally if the CPU
can not detect the DMA controller's busy signal.
bug: 153500755
Change-Id: I9123685be01312db4caa47a742e6e6d0c8ef4e08
Signed-off-by: Zhenfang Wang <zhenfang.wang@unisoc.com>
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/02adbe4364ec436ec2c5bc8fd2386bab98edd884.1584019223.git.baolin.wang7@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
(cherry picked from commit d0f19a48a185dab592afe1e18bf31a9d6790620d)
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl6NeIEACgkQONu9yGCS
aT6MYhAAl32aRPkceCidQx1xxOtwPHj/to5aKlqlJZL83wUHtyKI7QYZ6/xE4nAO
hT668KM//KKg3UYeuAizfVUIQk703iDZvfQtffkZ1GP9WtyTWq0Iv4nZm7ohzUNH
rTTyF+g1DJwewn+9qpkW2hqUviSsu6dGzIgmmO82M1Egu6Dcc03DxMIlUO+2fCLC
j9R1vDeyzigmrO7o5lHngor3Re1TI5uLTonNZTdlhJIe7qc9z3aajoucGG4QcwuO
99k08F64dwXK+JV2SJQ+E0NBQlwbYLer0HTCyO6xTGT90WfH6tDYDM7zi4UT42qi
UwDhChmxr3ezffuNnNttIt+xt3PTuCjBJOgMSt1F1jb7IA0a1H2GOTUJUBn4S8ol
ocTqpHymDJEgJ1fBjLHbN+ZZrsCeTgWyBu/FL71Pw5CtoY+Z/EsN64XBrbO4uMB8
rB48d+TksikLLZ/qBja0bSXUUh2wVdBZ5EbjcPTetqmeOmvl5xGLxRks0HT62BuD
BAT3nJ3rOMgc7INK2WJL3QlGqnJLXKu3wPtbq29ADfgLnbOt8WAPs4KooZKZpeh2
fkiLUQ2UEFkEOiXjmh/JAHR8mUVa7NXbb0IILDpMW9vZINT69gFeXs43RRcZ1O+8
G369xEweZg0T30sj1KLOLzgxP/K1EPXdq1FvvByUynsRuCFBVk8=
=Bu2+
-----END PGP SIGNATURE-----
Merge 5.4.31 into android-5.4
Changes in 5.4.31
nvme-rdma: Avoid double freeing of async event data
kconfig: introduce m32-flag and m64-flag
drm/amd/display: Add link_rate quirk for Apple 15" MBP 2017
drm/bochs: downgrade pci_request_region failure from error to warning
initramfs: restore default compression behavior
drm/amdgpu: fix typo for vcn1 idle check
tools/power turbostat: Fix gcc build warnings
tools/power turbostat: Fix missing SYS_LPI counter on some Chromebooks
tools/power turbostat: Fix 32-bit capabilities warning
net/mlx5e: kTLS, Fix TCP seq off-by-1 issue in TX resync flow
XArray: Fix xa_find_next for large multi-index entries
padata: fix uninitialized return value in padata_replace()
brcmfmac: abort and release host after error
misc: rtsx: set correct pcr_ops for rts522A
misc: pci_endpoint_test: Fix to support > 10 pci-endpoint-test devices
misc: pci_endpoint_test: Avoid using module parameter to determine irqtype
PCI: sysfs: Revert "rescan" file renames
coresight: do not use the BIT() macro in the UAPI header
mei: me: add cedar fork device ids
nvmem: check for NULL reg_read and reg_write before dereferencing
extcon: axp288: Add wakeup support
power: supply: axp288_charger: Add special handling for HP Pavilion x2 10
Revert "dm: always call blk_queue_split() in dm_process_bio()"
ALSA: hda/ca0132 - Add Recon3Di quirk to handle integrated sound on EVGA X99 Classified motherboard
soc: mediatek: knows_txdone needs to be set in Mediatek CMDQ helper
net/mlx5e: kTLS, Fix wrong value in record tracker enum
iwlwifi: consider HE capability when setting LDPC
iwlwifi: yoyo: don't add TLV offset when reading FIFOs
iwlwifi: dbg: don't abort if sending DBGC_SUSPEND_RESUME fails
rxrpc: Fix sendmsg(MSG_WAITALL) handling
IB/hfi1: Ensure pq is not left on waitlist
tcp: fix TFO SYNACK undo to avoid double-timestamp-undo
watchdog: iTCO_wdt: Export vendorsupport
watchdog: iTCO_wdt: Make ICH_RES_IO_SMI optional
i2c: i801: Do not add ICH_RES_IO_SMI for the iTCO_wdt device
net: Fix Tx hash bound checking
padata: always acquire cpu_hotplug_lock before pinst->lock
mm: mempolicy: require at least one nodeid for MPOL_PREFERRED
Linux 5.4.31
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9c87409ae13ad2da7a90be98586a85904a5cdb33
commit aa9f7d5172fac9bf1f09e678c35e287a40a7b7dd upstream.
Using an empty (malformed) nodelist that is not caught during mount option
parsing leads to a stack-out-of-bounds access.
The option string that was used was: "mpol=prefer:,". However,
MPOL_PREFERRED requires a single node number, which is not being provided
here.
Add a check that 'nodes' is not empty after parsing for MPOL_PREFERRED's
nodeid.
Fixes: 095f1fc4eb ("mempolicy: rework shmem mpol parsing and display")
Reported-by: Entropy Moe <3ntr0py1337@gmail.com>
Reported-by: syzbot+b055b1a6b2b958707a21@syzkaller.appspotmail.com
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Tested-by: syzbot+b055b1a6b2b958707a21@syzkaller.appspotmail.com
Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
Link: http://lkml.kernel.org/r/89526377-7eb6-b662-e1d8-4430928abde9@infradead.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 38228e8848cd7dd86ccb90406af32de0cad24be3 upstream.
lockdep complains when padata's paths to update cpumasks via CPU hotplug
and sysfs are both taken:
# echo 0 > /sys/devices/system/cpu/cpu1/online
# echo ff > /sys/kernel/pcrypt/pencrypt/parallel_cpumask
======================================================
WARNING: possible circular locking dependency detected
5.4.0-rc8-padata-cpuhp-v3+ #1 Not tainted
------------------------------------------------------
bash/205 is trying to acquire lock:
ffffffff8286bcd0 (cpu_hotplug_lock.rw_sem){++++}, at: padata_set_cpumask+0x2b/0x120
but task is already holding lock:
ffff8880001abfa0 (&pinst->lock){+.+.}, at: padata_set_cpumask+0x26/0x120
which lock already depends on the new lock.
padata doesn't take cpu_hotplug_lock and pinst->lock in a consistent
order. Which should be first? CPU hotplug calls into padata with
cpu_hotplug_lock already held, so it should have priority.
Fixes: 6751fb3c0e ("padata: Use get_online_cpus/put_online_cpus")
Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com>
Cc: Eric Biggers <ebiggers@kernel.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6e11d1578fba8d09d03a286740ffcf336d53928c upstream.
Fixes the lower and upper bounds when there are multiple TCs and
traffic is on the the same TC on the same device.
The lower bound is represented by 'qoffset' and the upper limit for
hash value is 'qcount + qoffset'. This gives a clean Rx to Tx queue
mapping when there are multiple TCs, as the queue indices for upper TCs
will be offset by 'qoffset'.
v2: Fixed commit description based on comments.
Fixes: 1b837d489e ("net: Revoke export for __skb_tx_hash, update it to just be static skb_tx_hash")
Fixes: eadec877ce ("net: Add support for subordinate traffic classes to netdev_pick_tx")
Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com>
Reviewed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Reviewed-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 04bbb97d1b732b2d197f103c5818f5c214a4cf81 upstream.
Martin noticed that nct6775 driver does not load properly on his system
in v5.4+ kernels. The issue was bisected to commit b84398d6d7 ("i2c:
i801: Use iTCO version 6 in Cannon Lake PCH and beyond") but it is
likely not the culprit because the faulty code has been in the driver
already since commit 9424693035 ("i2c: i801: Create iTCO device on
newer Intel PCHs"). So more likely some commit that added PCI IDs of
recent chipsets made the driver to create the iTCO_wdt device on Martins
system.
The issue was debugged to be PCI configuration access to the PMC device
that is not present. This returns all 1's when read and this caused the
iTCO_wdt driver to accidentally request resourses used by nct6775.
It turns out that the SMI resource is only required for some ancient
systems, not the ones supported by this driver. For this reason do not
populate the SMI resource at all and drop all the related code. The
driver now always populates the main I/O resource and only in case of SPT
(Intel Sunrisepoint) compatible devices it adds another resource for the
NO_REBOOT bit. These two resources are of different types so
platform_get_resource() used by the iTCO_wdt driver continues to find
the both resources at index 0.
Link: https://lore.kernel.org/linux-hwmon/CAM1AHpQ4196tyD=HhBu-2donSsuogabkfP03v1YF26Q7_BgvgA@mail.gmail.com/
Fixes: 9424693035 ("i2c: i801: Create iTCO device on newer Intel PCHs")
[wsa: complete fix needs all of http://patchwork.ozlabs.org/project/linux-i2c/list/?series=160959&state=*]
Reported-by: Martin Volf <martin.volf.42@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e42b0c24389d5a1602e77db4f6def0d5a19e3e43 upstream.
The iTCO_wdt driver only needs ICH_RES_IO_SMI I/O resource when either
turn_SMI_watchdog_clear_off module parameter is set to match ->iTCO_version
(or higher), and when legacy iTCO_vendorsupport is set. Modify the driver
so that ICH_RES_IO_SMI is optional if the two conditions are not met.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7ca6ee38909109751bfab79e9f6c570d2ed258c6 upstream.
In preparation for making ->smi_res optional the iTCO_wdt driver needs
to know whether vendorsupport is being set to non-zero. For this reason
export the variable.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dad8cea7add96a353fa1898b5ccefbb72da66f29 upstream.
In a rare corner case the new logic for undo of SYNACK RTO could
result in triggering the warning in tcp_fastretrans_alert() that says:
WARN_ON(tp->retrans_out != 0);
The warning looked like:
WARNING: CPU: 1 PID: 1 at net/ipv4/tcp_input.c:2818 tcp_ack+0x13e0/0x3270
The sequence that tickles this bug is:
- Fast Open server receives TFO SYN with data, sends SYNACK
- (client receives SYNACK and sends ACK, but ACK is lost)
- server app sends some data packets
- (N of the first data packets are lost)
- server receives client ACK that has a TS ECR matching first SYNACK,
and also SACKs suggesting the first N data packets were lost
- server performs TS undo of SYNACK RTO, then immediately
enters recovery
- buggy behavior then performed a *second* undo that caused
the connection to be in CA_Open with retrans_out != 0
Basically, the incoming ACK packet with SACK blocks causes us to first
undo the cwnd reduction from the SYNACK RTO, but then immediately
enters fast recovery, which then makes us eligible for undo again. And
then tcp_rcv_synrecv_state_fastopen() accidentally performs an undo
using a "mash-up" of state from two different loss recovery phases: it
uses the timestamp info from the ACK of the original SYNACK, and the
undo_marker from the fast recovery.
This fix refines the logic to only invoke the tcp_try_undo_loss()
inside tcp_rcv_synrecv_state_fastopen() if the connection is still in
CA_Loss. If peer SACKs triggered fast recovery, then
tcp_rcv_synrecv_state_fastopen() can't safely undo.
Fixes: 794200d662 ("tcp: undo cwnd on Fast Open spurious SYNACK retransmit")
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9a293d1e21a6461a11b4217b155bf445e57f4131 upstream.
The following warning can occur when a pq is left on the dmawait list and
the pq is then freed:
WARNING: CPU: 47 PID: 3546 at lib/list_debug.c:29 __list_add+0x65/0xc0
list_add corruption. next->prev should be prev (ffff939228da1880), but was ffff939cabb52230. (next=ffff939cabb52230).
Modules linked in: mmfs26(OE) mmfslinux(OE) tracedev(OE) 8021q garp mrp ib_isert iscsi_target_mod target_core_mod crc_t10dif crct10dif_generic opa_vnic rpcrdma ib_iser libiscsi scsi_transport_iscsi ib_ipoib(OE) bridge stp llc iTCO_wdt iTCO_vendor_support intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypass crct10dif_pclmul crct10dif_common crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd ast ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm pcspkr joydev drm_panel_orientation_quirks i2c_i801 mei_me lpc_ich mei wmi ipmi_si ipmi_devintf ipmi_msghandler nfit libnvdimm acpi_power_meter acpi_pad hfi1(OE) rdmavt(OE) rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_core binfmt_misc numatools(OE) xpmem(OE) ip_tables
nfsv3 nfs_acl nfs lockd grace sunrpc fscache igb ahci libahci i2c_algo_bit dca libata ptp pps_core crc32c_intel [last unloaded: i2c_algo_bit]
CPU: 47 PID: 3546 Comm: wrf.exe Kdump: loaded Tainted: G W OE ------------ 3.10.0-957.41.1.el7.x86_64 #1
Hardware name: HPE.COM HPE SGI 8600-XA730i Gen10/X11DPT-SB-SG007, BIOS SBED1229 01/22/2019
Call Trace:
[<ffffffff91f65ac0>] dump_stack+0x19/0x1b
[<ffffffff91898b78>] __warn+0xd8/0x100
[<ffffffff91898bff>] warn_slowpath_fmt+0x5f/0x80
[<ffffffff91a1dabe>] ? ___slab_alloc+0x24e/0x4f0
[<ffffffff91b97025>] __list_add+0x65/0xc0
[<ffffffffc03926a5>] defer_packet_queue+0x145/0x1a0 [hfi1]
[<ffffffffc0372987>] sdma_check_progress+0x67/0xa0 [hfi1]
[<ffffffffc03779d2>] sdma_send_txlist+0x432/0x550 [hfi1]
[<ffffffff91a20009>] ? kmem_cache_alloc+0x179/0x1f0
[<ffffffffc0392973>] ? user_sdma_send_pkts+0xc3/0x1990 [hfi1]
[<ffffffffc0393e3a>] user_sdma_send_pkts+0x158a/0x1990 [hfi1]
[<ffffffff918ab65e>] ? try_to_del_timer_sync+0x5e/0x90
[<ffffffff91a3fe1a>] ? __check_object_size+0x1ca/0x250
[<ffffffffc0395546>] hfi1_user_sdma_process_request+0xd66/0x1280 [hfi1]
[<ffffffffc034e0da>] hfi1_aio_write+0xca/0x120 [hfi1]
[<ffffffff91a4245b>] do_sync_readv_writev+0x7b/0xd0
[<ffffffff91a4409e>] do_readv_writev+0xce/0x260
[<ffffffff918df69f>] ? pick_next_task_fair+0x5f/0x1b0
[<ffffffff918db535>] ? sched_clock_cpu+0x85/0xc0
[<ffffffff91f6b16a>] ? __schedule+0x13a/0x860
[<ffffffff91a442c5>] vfs_writev+0x35/0x60
[<ffffffff91a4447f>] SyS_writev+0x7f/0x110
[<ffffffff91f78ddb>] system_call_fastpath+0x22/0x27
The issue happens when wait_event_interruptible_timeout() returns a value
<= 0.
In that case, the pq is left on the list. The code continues sending
packets and potentially can complete the current request with the pq still
on the dmawait list provided no descriptor shortage is seen.
If the pq is torn down in that state, the sdma interrupt handler could
find the now freed pq on the list with list corruption or memory
corruption resulting.
Fix by adding a flush routine to ensure that the pq is never on a list
after processing a request.
A follow-up patch series will address issues with seqlock surfaced in:
https://lore.kernel.org/r/20200320003129.GP20941@ziepe.ca
The seqlock use for sdma will then be converted to a spin lock since the
list_empty() doesn't need the protection afforded by the sequence lock
currently in use.
Fixes: a0d406934a ("staging/rdma/hfi1: Add page lock limit check for SDMA requests")
Link: https://lore.kernel.org/r/20200320200200.23203.37777.stgit@awfm-01.aw.intel.com
Reviewed-by: Kaike Wan <kaike.wan@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 498b577660f08cef5d9e78e0ed6dcd4c0939e98c upstream.
Fix the handling of sendmsg() with MSG_WAITALL for userspace to round the
timeout for when a signal occurs up to at least two jiffies as a 1 jiffy
timeout may end up being effectively 0 if jiffies wraps at the wrong time.
Fixes: bc5e3a546d ("rxrpc: Use MSG_WAITALL to tell sendmsg() to temporarily ignore signals")
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 699b760bd29edba736590fffef7654cb079c753e upstream.
If the firmware is in a bad state or not initialized fully, sending
the DBGC_SUSPEND_RESUME command fails but we can still collect logs.
Instead of aborting the entire dump process, simply ignore the error.
By removing the last callpoint that was checking the return value, we
can also convert the function to return void.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Fixes: 576058330f ("iwlwifi: dbg: support debug recording suspend resume command")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200306151129.dcec37b2efd4.I8dcd190431d110a6a0e88095ce93591ccfb3d78d@changeid
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a5688e600e78f9fc68102bf0fe5c797fc2826abe upstream.
The TLV offset is only used to read registers, while the offset used for
the FIFO addresses are hard coded in the driver and not given by the
TLV.
If we try to apply the TLV offset when reading the FIFOs, we'll read
from invalid addresses, causing the driver to hang.
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
Fixes: 8d7dea25ad ("iwlwifi: dbg_ini: implement Rx fifos dump")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200306151129.fbab869c26fa.I4ddac20d02f9bce41855a816aa6855c89bc3874e@changeid
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit cb377dfda1755b3bc01436755d866c8e5336a762 upstream.
The AP may set the LDPC capability only in HE (IEEE80211_HE_PHY_CAP1),
but we were checking it only in the HT capabilities.
If we don't use this capability when required, the DSP gets the wrong
configuration in HE and doesn't work properly.
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
Fixes: befebbb30a ("iwlwifi: rs: consider LDPC capability in case of HE")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200306151128.492d167c1a25.I1ad1353dbbf6c99ae57814be750f41a1c9f7f4ac@changeid
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f28ca65efa87b3fb8da3d69ca7cb1ebc0448de66 upstream.
Fix to match the HW spec: TRACKING state is 1, SEARCHING is 2.
No real issue for now, as these values are not currently used.
Fixes: d2ead1f360 ("net/mlx5e: Add kTLS TX HW offload support")
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Reviewed-by: Boris Pismenny <borisp@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ce35e21d82bcac8b3fd5128888f9e233f8444293 upstream.
Mediatek CMDQ driver have a mechanism to do TXDONE_BY_ACK,
so we should set knows_txdone.
Fixes:576f1b4bc802 ("soc: mediatek: Add Mediatek CMDQ helper")
Cc: stable@vger.kernel.org # v5.0+
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e9097e47e349b747dee50f935216de0ffb662962 upstream.
I have a system which has an EVGA X99 Classified motherboard. The pin
assignments for the HD Audio controller are not correct under Linux.
Windows 10 works fine and informs me that it's using the Recon3Di
driver, and on Linux, `cat
/sys/class/sound/card0/device/subsystem_{vendor,device}` yields
0x3842
0x1038
This patch adds a corresponding entry to the quirk list.
Signed-off-by: Geoffrey Allott <geoffrey@allott.email>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/a6cd56b678c00ce2db3685e4278919f2584f8244.camel@allott.email
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 120c9257f5f19e5d1e87efcbb5531b7cd81b7d74 upstream.
This reverts commit effd58c95f.
blk_queue_split() is causing excessive IO splitting -- because
blk_max_size_offset() depends on 'chunk_sectors' limit being set and
if it isn't (as is the case for DM targets!) it falls back to
splitting on a 'max_sectors' boundary regardless of offset.
"Fix" this by reverting back to _not_ using blk_queue_split() in
dm_process_bio() for normal IO (reads and writes). Long-term fix is
still TBD but it should focus on training blk_max_size_offset() to
call into a DM provided hook (to call DM's max_io_len()).
Test results from simple misaligned IO test on 4-way dm-striped device
with chunksize of 128K and stripesize of 512K:
xfs_io -d -c 'pread -b 2m 224s 4072s' /dev/mapper/stripe_dev
before this revert:
253,0 21 1 0.000000000 2206 Q R 224 + 4072 [xfs_io]
253,0 21 2 0.000008267 2206 X R 224 / 480 [xfs_io]
253,0 21 3 0.000010530 2206 X R 224 / 256 [xfs_io]
253,0 21 4 0.000027022 2206 X R 480 / 736 [xfs_io]
253,0 21 5 0.000028751 2206 X R 480 / 512 [xfs_io]
253,0 21 6 0.000033323 2206 X R 736 / 992 [xfs_io]
253,0 21 7 0.000035130 2206 X R 736 / 768 [xfs_io]
253,0 21 8 0.000039146 2206 X R 992 / 1248 [xfs_io]
253,0 21 9 0.000040734 2206 X R 992 / 1024 [xfs_io]
253,0 21 10 0.000044694 2206 X R 1248 / 1504 [xfs_io]
253,0 21 11 0.000046422 2206 X R 1248 / 1280 [xfs_io]
253,0 21 12 0.000050376 2206 X R 1504 / 1760 [xfs_io]
253,0 21 13 0.000051974 2206 X R 1504 / 1536 [xfs_io]
253,0 21 14 0.000055881 2206 X R 1760 / 2016 [xfs_io]
253,0 21 15 0.000057462 2206 X R 1760 / 1792 [xfs_io]
253,0 21 16 0.000060999 2206 X R 2016 / 2272 [xfs_io]
253,0 21 17 0.000062489 2206 X R 2016 / 2048 [xfs_io]
253,0 21 18 0.000066133 2206 X R 2272 / 2528 [xfs_io]
253,0 21 19 0.000067507 2206 X R 2272 / 2304 [xfs_io]
253,0 21 20 0.000071136 2206 X R 2528 / 2784 [xfs_io]
253,0 21 21 0.000072764 2206 X R 2528 / 2560 [xfs_io]
253,0 21 22 0.000076185 2206 X R 2784 / 3040 [xfs_io]
253,0 21 23 0.000077486 2206 X R 2784 / 2816 [xfs_io]
253,0 21 24 0.000080885 2206 X R 3040 / 3296 [xfs_io]
253,0 21 25 0.000082316 2206 X R 3040 / 3072 [xfs_io]
253,0 21 26 0.000085788 2206 X R 3296 / 3552 [xfs_io]
253,0 21 27 0.000087096 2206 X R 3296 / 3328 [xfs_io]
253,0 21 28 0.000093469 2206 X R 3552 / 3808 [xfs_io]
253,0 21 29 0.000095186 2206 X R 3552 / 3584 [xfs_io]
253,0 21 30 0.000099228 2206 X R 3808 / 4064 [xfs_io]
253,0 21 31 0.000101062 2206 X R 3808 / 3840 [xfs_io]
253,0 21 32 0.000104956 2206 X R 4064 / 4096 [xfs_io]
253,0 21 33 0.001138823 0 C R 4096 + 200 [0]
after this revert:
253,0 18 1 0.000000000 4430 Q R 224 + 3896 [xfs_io]
253,0 18 2 0.000018359 4430 X R 224 / 256 [xfs_io]
253,0 18 3 0.000028898 4430 X R 256 / 512 [xfs_io]
253,0 18 4 0.000033535 4430 X R 512 / 768 [xfs_io]
253,0 18 5 0.000065684 4430 X R 768 / 1024 [xfs_io]
253,0 18 6 0.000091695 4430 X R 1024 / 1280 [xfs_io]
253,0 18 7 0.000098494 4430 X R 1280 / 1536 [xfs_io]
253,0 18 8 0.000114069 4430 X R 1536 / 1792 [xfs_io]
253,0 18 9 0.000129483 4430 X R 1792 / 2048 [xfs_io]
253,0 18 10 0.000136759 4430 X R 2048 / 2304 [xfs_io]
253,0 18 11 0.000152412 4430 X R 2304 / 2560 [xfs_io]
253,0 18 12 0.000160758 4430 X R 2560 / 2816 [xfs_io]
253,0 18 13 0.000183385 4430 X R 2816 / 3072 [xfs_io]
253,0 18 14 0.000190797 4430 X R 3072 / 3328 [xfs_io]
253,0 18 15 0.000197667 4430 X R 3328 / 3584 [xfs_io]
253,0 18 16 0.000218751 4430 X R 3584 / 3840 [xfs_io]
253,0 18 17 0.000226005 4430 X R 3840 / 4096 [xfs_io]
253,0 18 18 0.000250404 4430 Q R 4120 + 176 [xfs_io]
253,0 18 19 0.000847708 0 C R 4096 + 24 [0]
253,0 18 20 0.000855783 0 C R 4120 + 176 [0]
Fixes: effd58c95f ("dm: always call blk_queue_split() in dm_process_bio()")
Cc: stable@vger.kernel.org
Reported-by: Andreas Gruenbacher <agruenba@redhat.com>
Tested-by: Barry Marson <bmarson@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9c80662a74cd2a5d1113f5c69d027face963a556 upstream.
Some HP Pavilion x2 10 models use an AXP288 for charging and fuel-gauge.
We use a native power_supply / PMIC driver in this case, because on most
models with an AXP288 the ACPI AC / Battery code is either completely
missing or relies on custom / proprietary ACPI OpRegions which Linux
does not implement.
The native drivers mostly work fine, but there are 2 problems:
1. These model uses a Type-C connector for charging which the AXP288 does
not support. As long as a Type-A charger (which uses the USB data pins for
charger type detection) is used everything is fine. But if a Type-C
charger is used (such as the charger shipped with the device) then the
charger is not recognized.
So we end up slowly discharging the device even though a charger is
connected, because we are limiting the current from the charger to 500mA.
To make things worse this happens with the device's official charger.
Looking at the ACPI tables HP has "solved" the problem of the AXP288 not
being able to recognize Type-C chargers by simply always programming the
input-current-limit at 3000mA and relying on a Vhold setting of 4.7V
(normally 4.4V) to limit the current intake if the charger cannot handle
this.
2. If no charger is connected when the machine boots then it boots with the
vbus-path disabled. On other devices this is done when a 5V boost converter
is active to avoid the PMIC trying to charge from the 5V boost output.
This is done when an OTG host cable is inserted and the ID pin on the
micro-B receptacle is pulled low, the ID pin has an ACPI event handler
associated with it which re-enables the vbus-path when the ID pin is pulled
high when the OTG cable is removed. The Type-C connector has no ID pin,
there is no ID pin handler and there appears to be no 5V boost converter,
so we end up not charging because the vbus-path is disabled, until we
unplug the charger which automatically clears the vbus-path disable bit and
then on the second plug-in of the adapter we start charging.
The HP Pavilion x2 10 models with an AXP288 do have mostly working ACPI
AC / Battery code which does not rely on custom / proprietary ACPI
OpRegions. So one possible solution would be to blacklist the AXP288
native power_supply drivers and add the HP Pavilion x2 10 with AXP288
DMI ids to the list of devices which should use the ACPI AC / Battery
code even though they have an AXP288 PMIC. This would require changes to
4 files: drivers/acpi/ac.c, drivers/power/supply/axp288_charger.c,
drivers/acpi/battery.c and drivers/power/supply/axp288_fuel_gauge.c.
Beside needing adding the same DMI matches to 4 different files, this
approach also triggers problem 2. from above, but then when suspended,
during suspend the machine will not wakeup because the vbus path is
disabled by the AML code when not charging, so the Vbus low-to-high
IRQ is not triggered, the CPU never wakes up and the device does not
charge even though the user likely things it is charging, esp. since
the charge status LED is directly coupled to an adapter being plugged
in and does not reflect actual charging.
This could be worked by enabling vbus-path explicitly from say the
axp288_charger driver's suspend handler.
So neither situation is ideal, in both cased we need to explicitly enable
the vbus-path to work around different variants of problem 2 above, this
requires a quirk in the axp288_charger code.
If we go the route of using the ACPI AC / Battery drivers then we need
modifications to 3 other drivers; and we need to partially disable the
axp288_charger code, while at the same time keeping it around to enable
vbus-path on suspend.
OTOH we can copy the hardcoding of 3A input-current-limit (we never touch
Vhold, so that would stay at 4.7V) to the axp288_charger code, which needs
changes regardless, then we concentrate all special handling of this
interesting device model in the axp288_charger code. That is what this
commit does.
Cc: stable@vger.kernel.org
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1791098
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9c94553099efb2ba873cbdddfd416a8a09d0e5f1 upstream.
On devices with an AXP288, we need to wakeup from suspend when a charger
is plugged in, so that we can do charger-type detection and so that the
axp288-charger driver, which listens for our extcon events, can configure
the input-current-limit accordingly.
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3c91ef69a3e94f78546b246225ed573fbf1735b4 upstream.
Return -EPERM if reg_read is NULL in bin_attr_nvmem_read() or if
reg_write is NULL in bin_attr_nvmem_write().
This prevents NULL dereferences such as the one described in
03cd45d2e219 ("thunderbolt: Prevent crash if non-active NVMem file is
read")
Signed-off-by: Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20200310132257.23358-10-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 99397d33b763dc554d118aaa38cc5abc6ce985de upstream.
Add Cedar Fork (CDF) device ids, those belongs to the cannon point family.
Cc: <stable@vger.kernel.org>
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Link: https://lore.kernel.org/r/20200324210730.17672-1-tomas.winkler@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9b6eaaf3db5e5888df7bca7fed7752a90f7fd871 upstream.
The BIT() macro definition is not available for the UAPI headers
(moreover, it can be defined differently in the user space); replace
its usage with the _BITUL() macro that is defined in <linux/const.h>.
Fixes: 237483aa5c ("coresight: stm: adding driver for CoreSight STM component")
Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20200324042213.GA10452@asgard.redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bd641fd8303a371e789e924291086268256766b0 upstream.
We changed these sysfs filenames:
.../pci_bus/<domain:bus>/rescan -> .../pci_bus/<domain:bus>/bus_rescan
.../<domain🚌dev.fn>/rescan -> .../<domain🚌dev.fn>/dev_rescan
and Ruslan reported [1] that this broke a userspace application.
Revert these name changes so both files are named "rescan" again.
Note that we have to use __ATTR() to assign custom C symbols, i.e.,
"struct device_attribute <symbol>".
[1] https://lore.kernel.org/r/CAB=otbSYozS-ZfxB0nCiNnxcbqxwrHOSYxJJtDKa63KzXbXgpw@mail.gmail.com
[bhelgaas: commit log, use __ATTR() both places so we don't have to rename
the attributes]
Fixes: 8bdfa145f5 ("PCI: sysfs: Define device attributes with DEVICE_ATTR*()")
Fixes: 4e2b79436e ("PCI: sysfs: Change DEVICE_ATTR() to DEVICE_ATTR_WO()")
Link: https://lore.kernel.org/r/20200325151708.32612-1-skunberg.kelsey@gmail.com
Signed-off-by: Kelsey Skunberg <kelsey.skunberg@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org # v5.4+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b2ba9225e0313b1de631a44b7b48c109032bffec upstream.
commit e03327122e ("pci_endpoint_test: Add 2 ioctl commands")
uses module parameter 'irqtype' in pci_endpoint_test_set_irq()
to check if IRQ vectors of a particular type (MSI or MSI-X or
LEGACY) is already allocated. However with multi-function devices,
'irqtype' will not correctly reflect the IRQ type of the PCI device.
Fix it here by adding 'irqtype' for each PCI device to show the
IRQ type of a particular PCI device.
Fixes: e03327122e ("pci_endpoint_test: Add 2 ioctl commands")
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: stable@vger.kernel.org # v4.19+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
