Alex Elder says:
====================
net: ipa: fix two replenish bugs
This series contains two fixes for bugs in the IPA receive buffer
replenishing code. The (new) second patch defines a bitmap to
represent endpoint the replenish enabled flag. Its purpose is to
prepare for the third patch, which adds an additional flag.
Version 2 of this series uses bitmap operations in the second bug
fix rather than an atomic variable, as suggested by Jakub.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
We have seen cases where an endpoint RX completion interrupt arrives
while replenishing for the endpoint is underway. This causes another
instance of replenishing to begin as part of completing the receive
transaction. If this occurs it can lead to transaction corruption.
Use a new flag to ensure only one replenish instance for an endpoint
executes at a time.
Fixes: 84f9bd12d4 ("soc: qcom: ipa: IPA endpoints")
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Define a new replenish_flags bitmap to contain Boolean flags
associated with an endpoint's replenishing state. Replace the
replenish_enabled field with a flag in that bitmap. This is to
prepare for the next patch, which adds another flag.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
In ipa_endpoint_replenish(), if an error occurs when attempting to
replenish a receive buffer, we just quit and try again later. In
that case we increment the backlog count to reflect that the attempt
was unsuccessful. Then, if the add_one flag was true we increment
the backlog again.
This second increment is not included in the backlog local variable
though, and its value determines whether delayed work should be
scheduled. This is a bug.
Fix this by determining whether 1 or 2 should be added to the
backlog before adding it in a atomic_add_return() call.
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Fixes: 84f9bd12d4 ("soc: qcom: ipa: IPA endpoints")
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
It appears that there are some buffer overflows in EVT_TRANSACTION.
This happens because the length parameters that are passed to memcpy
come directly from skb->data and are not guarded in any way.
Signed-off-by: Jordy Zomer <jordy@pwning.systems>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Don't forget to release the device in sock_timestamping_bind_phc() after
it was used to get the vclock indices.
Fixes: d463126e23 ("net: sock: extend SO_TIMESTAMPING for PHC binding")
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
Cc: Yangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This reverts commit 9ed319e411.
We can already post process a nvmem cell value in a particular driver.
Instead of having yet another place to convert the values, the post
processing hook of the nvmem provider should be used in this case.
Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use down_read_nested() and down_write_nested() when taking the
ctrl->reset_lock rw-sem, passing the number of PCIe hotplug controllers in
the path to the PCI root bus as lock subclass parameter.
This fixes the following false-positive lockdep report when unplugging a
Lenovo X1C8 from a Lenovo 2nd gen TB3 dock:
pcieport 0000:06:01.0: pciehp: Slot(1): Link Down
pcieport 0000:06:01.0: pciehp: Slot(1): Card not present
============================================
WARNING: possible recursive locking detected
5.16.0-rc2+ #621 Not tainted
--------------------------------------------
irq/124-pciehp/86 is trying to acquire lock:
ffff8e5ac4299ef8 (&ctrl->reset_lock){.+.+}-{3:3}, at: pciehp_check_presence+0x23/0x80
but task is already holding lock:
ffff8e5ac4298af8 (&ctrl->reset_lock){.+.+}-{3:3}, at: pciehp_ist+0xf3/0x180
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&ctrl->reset_lock);
lock(&ctrl->reset_lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by irq/124-pciehp/86:
#0: ffff8e5ac4298af8 (&ctrl->reset_lock){.+.+}-{3:3}, at: pciehp_ist+0xf3/0x180
#1: ffffffffa3b024e8 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pciehp_unconfigure_device+0x31/0x110
#2: ffff8e5ac1ee2248 (&dev->mutex){....}-{3:3}, at: device_release_driver+0x1c/0x40
stack backtrace:
CPU: 4 PID: 86 Comm: irq/124-pciehp Not tainted 5.16.0-rc2+ #621
Hardware name: LENOVO 20U90SIT19/20U90SIT19, BIOS N2WET30W (1.20 ) 08/26/2021
Call Trace:
<TASK>
dump_stack_lvl+0x59/0x73
__lock_acquire.cold+0xc5/0x2c6
lock_acquire+0xb5/0x2b0
down_read+0x3e/0x50
pciehp_check_presence+0x23/0x80
pciehp_runtime_resume+0x5c/0xa0
device_for_each_child+0x45/0x70
pcie_port_device_runtime_resume+0x20/0x30
pci_pm_runtime_resume+0xa7/0xc0
__rpm_callback+0x41/0x110
rpm_callback+0x59/0x70
rpm_resume+0x512/0x7b0
__pm_runtime_resume+0x4a/0x90
__device_release_driver+0x28/0x240
device_release_driver+0x26/0x40
pci_stop_bus_device+0x68/0x90
pci_stop_bus_device+0x2c/0x90
pci_stop_and_remove_bus_device+0xe/0x20
pciehp_unconfigure_device+0x6c/0x110
pciehp_disable_slot+0x5b/0xe0
pciehp_handle_presence_or_link_change+0xc3/0x2f0
pciehp_ist+0x179/0x180
This lockdep warning is triggered because with Thunderbolt, hotplug ports
are nested. When removing multiple devices in a daisy-chain, each hotplug
port's reset_lock may be acquired recursively. It's never the same lock, so
the lockdep splat is a false positive.
Because locks at the same hierarchy level are never acquired recursively, a
per-level lockdep class is sufficient to fix the lockdep warning.
The choice to use one lockdep subclass per pcie-hotplug controller in the
path to the root-bus was made to conserve class keys because their number
is limited and the complexity grows quadratically with number of keys
according to Documentation/locking/lockdep-design.rst.
Link: https://lore.kernel.org/linux-pci/20190402021933.GA2966@mit.edu/
Link: https://lore.kernel.org/linux-pci/de684a28-9038-8fc6-27ca-3f6f2f6400d7@redhat.com/
Link: https://lore.kernel.org/r/20211217141709.379663-1-hdegoede@redhat.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=208855
Reported-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Lukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org
The vga16fb framebuffer driver only supports Enhanced Graphics Adapter
(EGA) and Video Graphics Array (VGA) 16 color graphic cards.
But it doesn't check if the adapter is one of those or if a VGA16 mode
is used. This means that the driver will be probed even if a VESA BIOS
Extensions (VBE) or Graphics Output Protocol (GOP) interface is used.
This issue has been present for a long time but it was only exposed by
commit d391c58271 ("drivers/firmware: move x86 Generic System
Framebuffers support") since the platform device registration to match
the {vesa,efi}fb drivers is done later as a consequence of that change.
All non-x86 architectures though treat orig_video_isVGA as a boolean so
only do the supported video mode check for x86 and not for other arches.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215001
Fixes: d391c58271 ("drivers/firmware: move x86 Generic System Framebuffers support")
Reported-by: Kris Karas <bugs-a21@moonlit-rail.com>
Cc: <stable@vger.kernel.org> # 5.15.x
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Tested-by: Kris Karas <bugs-a21@moonlit-rail.com>
Acked-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220110095625.278836-3-javierm@redhat.com
Battery status on Elan tablet driver is reported for the HP ENVY x360
15t-dr100. There is no separate battery for the Elan controller resulting in a
battery level report of 0% or 1% depending on whether a stylus has interacted
with the screen. These low battery level reports causes a variety of bad
behavior in desktop environments. This patch adds the appropriate quirk to
indicate that the batery status is unused for this target.
Cc: stable@vger.kernel.org
Signed-off-by: Karl Kurbjun <kkurbjun@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Use IRQF_NO_SUSPEND flag instead of enable_irq_wake to
support interrupt wake up from suspend.
Signed-off-by: Huang Yiwei <quic_hyiwei@quicinc.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Since hardware is supporting multiple IPCC instance,
use ipcc_%d instead of ipcc as the irq name to support
in driver.
Signed-off-by: Huang Yiwei <quic_hyiwei@quicinc.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Dynamic alloc for channel arrangement instead of static alloced
array, it is more flexible and can reduce memory usage.
Signed-off-by: Huang Yiwei <quic_hyiwei@quicinc.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
The Polarfire SoC is currently using two different compatible string
prefixes. Fix this by changing "polarfire-soc-*" strings to "mpfs-*" in
its system controller in order to match the compatible string used in
the soc binding and device tree.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Smatch static checker warns:
| drivers/mailbox/pcc.c:292 pcc_mbox_request_channel()
| error: uninitialized symbol 'dev'.
Fix the same by using pr_err instead of dev_err as the variable 'dev'
is uninitialized at that stage.
Fixes: ce028702dd ("mailbox: pcc: Move bulk of PCCT parsing into pcc_mbox_probe")
Cc: Jassi Brar <jassisinghbrar@gmail.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Fix following coccicheck warning:
WARNING: Function "for_each_child_of_node"
should have of_node_put() before return.
Early exits from for_each_child_of_node should decrement the
node reference counter.
Signed-off-by: Wang Qing <wangqing@vivo.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Fix following coccicheck warning:
WARNING: Function "for_each_available_child_of_node"
should have of_node_put() before return.
Early exits from for_each_available_child_of_node should decrement the
node reference counter.
Signed-off-by: Wang Qing <wangqing@vivo.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Convert hi3660 struct comments to kernel-doc notation and fix
other kernel-doc warnings:
drivers/mailbox/hi3660-mailbox.c:47: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Hi3660 mailbox channel information
drivers/mailbox/hi3660-mailbox.c:62: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Hi3660 mailbox controller data
hi3660-mailbox.c:53: warning: contents before sections
hi3660-mailbox.c:67: warning: contents before sections
Fixes: 41c0e939d7 ("mailbox: Add support for Hi3660 mailbox")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kernel test robot <lkp@intel.com>
Cc: Ruyi Wang <wangruyi@huawei.com>
Cc: Kaihua Zhong <zhongkaihua@huawei.com>
Reviewed-by: Leo Yan <leo.yan@linaro.org>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
To make sure the GCE request signal to SPM is not trigger by
other HW modules and cause suspend premature wake.
Set 0x7 (the bit 0~2 as 1) to GCE_GCTL_VALUE, to configure the
request signal control by SW and release the request to SPM.
Signed-off-by: jason-jh.lin <jason-jh.lin@mediatek.com>
Reviewed-by: Tzung-Bi Shih <tzungbi@google.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
As with other blocks, we intend to have drivers bind to generic
compatibles as long as there are no SoC-specific quirks. This allows
forward-compatibility with future SoCs.
No upstream DTs instantiate this yet, so it's still safe to make this
breaking change.
Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Sven Peter <sven@svenpeter.dev>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Much as we've done with other blocks, let's introduce generic
compatibles so drivers can bind to those and still work with future
SoCs, as long as the hardware remains the same. Also go ahead and add
compatibles for the new t600x SoCs (we group those as t6000).
Note that no DTs instantiate devices with this binding yet.
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Sven Peter <sven@svenpeter.dev>
Reviewed-by: Sven Peter <sven@svenpeter.dev>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Guillaume Nault says:
====================
ipv4: Fix accidental RTO_ONLINK flags passed to ip_route_output_key_hash()
The IPv4 stack generally uses the last bit of ->flowi4_tos as a flag
indicating link scope for route lookups (RTO_ONLINK). Therefore, we
have to be careful when copying a TOS value to ->flowi4_tos. In
particular, the ->tos field of IPv4 packets may have this bit set
because of ECN. Also tunnel keys generally accept any user value for
the tos.
This series fixes several places where ->flowi4_tos was set from
non-sanitised values and the flowi4 structure was later used by
ip_route_output_key_hash().
Note that the IPv4 stack usually clears the RTO_ONLINK bit using
RT_TOS(). However this macro is based on an obsolete interpretation of
the old IPv4 TOS field (RFC 1349) and clears the three high order bits
too. Since we don't need to clear these bits and since it doesn't make
sense to clear only one of the ECN bits, this patch series uses
INET_ECN_MASK instead.
All patches were compile tested only.
====================
Link: https://lore.kernel.org/r/cover.1641821242.git.gnault@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Mask the ECN bits before calling mlx5e_route_lookup_ipv4_get(). The
tunnel key might have the last ECN bit set. This interferes with the
route lookup process as ip_route_output_key_hash() interpretes this bit
specially (to restrict the route scope).
Found by code inspection, compile tested only.
Fixes: c7b9038d8a ("net/mlx5e: TC preparation refactoring for routing update event")
Fixes: 9a941117fb ("net/mlx5e: Maximize ip tunnel key usage on the TC offloading path")
Signed-off-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Mask the ECN bits before calling ip_route_output_ports(). The tos
variable might be passed directly from an IPv4 header, so it may have
the last ECN bit set. This interferes with the route lookup process as
ip_route_output_key_hash() interpretes this bit specially (to restrict
the route scope).
Found by code inspection, compile tested only.
Fixes: 804c2f3e36 ("libcxgb,iw_cxgb4,cxgbit: add cxgb_find_route()")
Signed-off-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Mask the ECN bits before initialising ->flowi4_tos. The tunnel key may
have the last ECN bit set, which will interfere with the route lookup
process as ip_route_output_key_hash() interpretes this bit specially
(to restrict the route scope).
Found by code inspection, compile tested only.
Fixes: 962924fa2b ("ip_gre: Refactor collect metatdata mode tunnel xmit to ip_md_tunnel_xmit")
Signed-off-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Similar to commit 94e2238969 ("xfrm4: strip ECN bits from tos field"),
clear the ECN bits from iph->tos when setting ->flowi4_tos.
This ensures that the last bit of ->flowi4_tos is cleared, so
ip_route_output_key_hash() isn't going to restrict the scope of the
route lookup.
Use ~INET_ECN_MASK instead of IPTOS_RT_MASK, because we have no reason
to clear the high order bits.
Found by code inspection, compile tested only.
Fixes: 4da3089f2b ("[IPSEC]: Use TOS when doing tunnel lookups")
Signed-off-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Current scheme of having userspace decompress kernel modules before
loading them into the kernel runs afoul of LoadPin security policy, as
it loses link between the source of kernel module on the disk and binary
blob that is being loaded into the kernel. To solve this issue let's
implement decompression in kernel, so that we can pass a file descriptor
of compressed module file into finit_module() which will keep LoadPin
happy.
To let userspace know what compression/decompression scheme kernel
supports it will create /sys/module/compression attribute. kmod can read
this attribute and decide if it can pass compressed file to
finit_module(). New MODULE_INIT_COMPRESSED_DATA flag indicates that the
kernel should attempt to decompress the data read from file descriptor
prior to trying load the module.
To simplify things kernel will only implement single decompression
method matching compression method selected when generating modules.
This patch implements gzip and xz; more can be added later,
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Luis has done a great job maintaining modules so far. As I'm planning to
take a break from work soon, I think we're ready to transition over fully.
Signed-off-by: Jessica Yu <jeyu@kernel.org>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Since commit e513cc1c07 ("module: Remove stop_machine from module
unloading") this comment is no longer correct. Remove it.
Signed-off-by: Yu Chen <chen.yu@easystack.cn>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
- Clock and reset driver for Toshiba Visconti SoCs
* clk-socfpga:
clk: socfpga: s10: Make use of the helper function devm_platform_ioremap_resource()
clk: socfpga: agilex: Make use of the helper function devm_platform_ioremap_resource()
clk: socfpga: remove redundant assignment after a mask operation
clk: socfpga: remove redundant assignment on division
* clk-toshiba:
clk: visconti: Remove pointless NULL check in visconti_pll_add_lookup()
MAINTAINERS: Add entries for Toshiba Visconti PLL and clock controller
clk: visconti: Add support common clock driver and reset driver
dt-bindings: clock: Add DT bindings for SMU of Toshiba Visconti TMPV770x SoC
dt-bindings: clock: Add DT bindings for PLL of Toshiba Visconti TMPV770x SoC
* clk-st:
clk: Drop unused COMMON_CLK_STM32MP157_SCMI config
clk: st: clkgen-mux: search reg within node or parent
clk: st: clkgen-fsyn: search reg within node or parent
* clk-bitmain:
clk: bm1880: remove kfrees on static allocations
* clk-x86:
clk: x86: Fix clk_gate_flags for RV_CLK_GATE
clk: x86: Use dynamic con_id string during clk registration
ACPI: APD: Add a fmw property clk-name
drivers: acpi: acpi_apd: Remove unused device property "is-rv"
x86: clk: clk-fch: Add support for newer family of AMD's SOC
clk: Introduce clk-tps68470 driver
platform/x86: int3472: Deal with probe ordering issues
platform/x86: int3472: Pass tps68470_regulator_platform_data to the tps68470-regulator MFD-cell
platform/x86: int3472: Pass tps68470_clk_platform_data to the tps68470-regulator MFD-cell
platform/x86: int3472: Add get_sensor_adev_and_name() helper
platform/x86: int3472: Split into 2 drivers
platform_data: Add linux/platform_data/tps68470.h file
i2c: acpi: Add i2c_acpi_new_device_by_fwnode() function
i2c: acpi: Use acpi_dev_ready_for_enumeration() helper
ACPI: delay enumeration of devices with a _DEP pointing to an INT3472 device
* clk-stm:
clk: stm32: Fix ltdc's clock turn off by clk_disable_unused() after system enter shell
* clk-amlogic:
clk: meson: gxbb: Fix the SDM_EN bit for MPLL0 on GXBB
* clk-allwinner:
clk: sunxi-ng: Add support for the D1 SoC clocks
clk: sunxi-ng: gate: Add macros for gates with fixed dividers
clk: sunxi-ng: mux: Add macros using clk_parent_data and clk_hw
clk: sunxi-ng: mp: Add macros using clk_parent_data and clk_hw
clk: sunxi-ng: div: Add macros using clk_parent_data and clk_hw
dt-bindings: clk: Add compatibles for D1 CCUs
clk: sunxi-ng: Allow the CCU core to be built as a module
clk: sunxi-ng: Convert early providers to platform drivers
clk: sunxi-ng: Allow drivers to be built as modules
clk: sunxi-ng: Export symbols used by CCU drivers
Pull locking updates from Borislav Petkov:
"Lots of cleanups and preparation. Highlights:
- futex: Cleanup and remove runtime futex_cmpxchg detection
- rtmutex: Some fixes for the PREEMPT_RT locking infrastructure
- kcsan: Share owner_on_cpu() between mutex,rtmutex and rwsem and
annotate the racy owner->on_cpu access *once*.
- atomic64: Dead-Code-Elemination"
[ Description above by Peter Zijlstra ]
* tag 'locking_core_for_v5.17_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
locking/atomic: atomic64: Remove unusable atomic ops
futex: Fix additional regressions
locking: Allow to include asm/spinlock_types.h from linux/spinlock_types_raw.h
x86/mm: Include spinlock_t definition in pgtable.
locking: Mark racy reads of owner->on_cpu
locking: Make owner_on_cpu() into <linux/sched.h>
lockdep/selftests: Adapt ww-tests for PREEMPT_RT
lockdep/selftests: Skip the softirq related tests on PREEMPT_RT
lockdep/selftests: Unbalanced migrate_disable() & rcu_read_lock().
lockdep/selftests: Avoid using local_lock_{acquire|release}().
lockdep: Remove softirq accounting on PREEMPT_RT.
locking/rtmutex: Add rt_mutex_lock_nest_lock() and rt_mutex_lock_killable().
locking/rtmutex: Squash self-deadlock check for ww_rt_mutex.
locking: Remove rt_rwlock_is_contended().
sched: Trigger warning if ->migration_disabled counter underflows.
futex: Fix sparc32/m68k/nds32 build regression
futex: Remove futex_cmpxchg detection
futex: Ensure futex_atomic_cmpxchg_inatomic() is present
kernel/locking: Use a pointer in ww_mutex_trylock().
