Cast kvm_x86_ops.func to 'void *' when updating KVM static calls that are
conditionally patched to __static_call_return0(). clang complains about
using mismatching pointers in the ternary operator, which breaks the
build when compiling with CONFIG_KVM_WERROR=y.
>> arch/x86/include/asm/kvm-x86-ops.h:82:1: warning: pointer type mismatch
('bool (*)(struct kvm_vcpu *)' and 'void *') [-Wpointer-type-mismatch]
Fixes: 5be2226f41 ("KVM: x86: allow defining return-0 static calls")
Reported-by: Like Xu <like.xu.linux@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Reviewed-by: David Dunn <daviddunn@google.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Message-Id: <20220223162355.3174907-1-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
VM worker kthreads can linger in the VM process's cgroup for sometime
after KVM terminates the VM process.
KVM terminates the worker kthreads by calling kthread_stop() which waits
on the 'exited' completion, triggered by exit_mm(), via mm_release(), in
do_exit() during the kthread's exit. However, these kthreads are
removed from the cgroup using the cgroup_exit() which happens after the
exit_mm(). Therefore, A VM process can terminate in between the
exit_mm() and cgroup_exit() calls, leaving only worker kthreads in the
cgroup.
Moving worker kthreads back to the original cgroup (kthreadd_task's
cgroup) makes sure that the cgroup is empty as soon as the main VM
process is terminated.
Signed-off-by: Vipin Sharma <vipinsh@google.com>
Suggested-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20220222054848.563321-1-vipinsh@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
From: Peng Hao <flyingpeng@tencent.com>
Remove a redundant 'cpu' declaration from inside an if-statement that
that shadows an identical declaration at function scope. Both variables
are used as scratch variables in for_each_*_cpu() loops, thus there's no
harm in sharing a variable.
Reviewed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Peng Hao <flyingpeng@tencent.com>
Message-Id: <20220222103954.70062-1-flyingpeng@tencent.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Fix a comment documenting the memory barrier related to clearing a
loaded_vmcs; loaded_vmcs tracks the host CPU the VMCS is loaded on via
the field 'cpu', it doesn't have a 'vcpu' field.
Reviewed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Peng Hao <flyingpeng@tencent.com>
Message-Id: <20220222104029.70129-1-flyingpeng@tencent.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Make sure nested_vmx_hardware_setup/unsetup() are called in pairs under
the same conditions. Calling nested_vmx_hardware_unsetup() when nested
is false "works" right now because it only calls free_page() on zero-
initialized pointers, but it's possible that more code will be added to
nested_vmx_hardware_unsetup() in the future.
Reviewed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Peng Hao <flyingpeng@tencent.com>
Message-Id: <20220222104054.70286-1-flyingpeng@tencent.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The reference taken by 'of_find_device_by_node()' must be released when
not needed anymore. Add put_device() call to fix this.
Fixes: e94236cde4 ("drm/tegra: dsi: Add ganged mode support")
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This patch adds the CRC hashing feature supported by some recent hardware
versions of the LTDC. This is useful for test suite such as IGT-GPU-tools
[1] where a CRTC output frame can be compared to a test reference frame
thanks to their respective CRC hash.
[1] https://cgit.freedesktop.org/drm/igt-gpu-tools
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220211104620.421177-1-raphael.gallais-pou@foss.st.com
Clang warns:
drivers/gpu/drm/stm/ltdc.c:625:2: warning: variable 'val' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized]
default:
^~~~~~~
drivers/gpu/drm/stm/ltdc.c:635:2: note: uninitialized use occurs here
val |= LxPCR_YCEN;
^~~
drivers/gpu/drm/stm/ltdc.c:600:9: note: initialize the variable 'val' to silence this warning
u32 val;
^
= 0
1 warning generated.
Use a return instead of break in the default case to fix the warning.
Add an error message so that this return is not silent, which could hide
issues in the future.
Fixes: 484e72d314 ("drm/stm: ltdc: add support of ycbcr pixel formats")
Link: https://github.com/ClangBuiltLinux/linux/issues/1575
Acked-by: Yannick Fertre <yannick.fertre@foss.st.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220222152045.484610-1-nathan@kernel.org
Enable the Tegra RTC alarm and power key wake-ups for Tegra234
Signed-off-by: kartik <kkartik@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Checking by >= DISPLAY_VER(12) made sense when the support for Tiger
Lake was added. However now it only leads to wrong behavior when adding
more platforms since it's expected they either don't have DMC to load
or they have their own blob.
Logs from DG2 loading on a CFL host, without having a DMC firmware
defined:
<6>[ 0.000000] DMI: Intel Corporation CoffeeLake Client Platform/CoffeeLake S UDIMM RVP, BIOS CNLSFWR1.R00.X220.B00.2103302221 03/30/2021
...
<6>[ 2.706607] pci 0000:03:00.0: [8086:56a0] type 00 class 0x030000
...
<7>[ 6.340397] i915 0000:03:00.0: [drm:intel_dmc_ucode_init [i915]] Loading i915/tgl_dmc_ver2_12.bin
<7>[ 6.341841] i915 0000:03:00.0: [drm:intel_fbc_init [i915]] Sanitized enable_fbc value: 1
<3>[ 6.342432] genirq: Flags mismatch irq 0. 00000080 (i915) vs. 00015a00 (timer)
<6>[ 6.346283] i915 0000:03:00.0: [drm] Finished loading DMC firmware i915/tgl_dmc_ver2_12.bin (v2.12)
<3>[ 6.385756] i915 0000:03:00.0: Device initialization failed (-16)
<5>[ 6.385778] i915 0000:03:00.0: Please file a bug on drm/i915; see https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs for details.
<4>[ 6.385782] i915: probe of 0000:03:00.0 failed with error -16
TGL is the only platform left with DISPLAY_VER() == 12 that is not
handled already in the if/else ladder, so handle it specifically.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220223210933.3049143-1-lucas.demarchi@intel.com
The arch_timer and vgic_irq kselftests assume that they can create a
vgic-v3, using the library function vgic_v3_setup() which aborts with a
test failure if it is not possible to do so. Since vgic-v3 can only be
instantiated on systems where the host has GICv3 this leads to false
positives on older systems where that is not the case.
Fix this by changing vgic_v3_setup() to return an error if the vgic can't
be instantiated and have the callers skip if this happens. We could also
exit flagging a skip in vgic_v3_setup() but this would prevent future test
cases conditionally deciding which GIC to use or generally doing more
complex output.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Tested-by: Ricardo Koller <ricarkol@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220223131624.1830351-1-broonie@kernel.org
The definition of ETH_ALEN in ieee80211.h is redundant as it is an
in-kernel constant. Remove it.
Signed-off-by: Michael Straube <straube.linux@gmail.com>
Link: https://lore.kernel.org/r/20220225120843.10674-5-straube.linux@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
EepromAddressSize in struct adapter is set but not used. Remove it and
remove the now unused function GetEEPROMSize8188E().
Signed-off-by: Michael Straube <straube.linux@gmail.com>
Link: https://lore.kernel.org/r/20220225120843.10674-2-straube.linux@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a device node for the Pin Function Controller on the Renesas R-Car
S4-8 (R8A779F0) SoC.
Note that the register block does not include registers for banks 4-7,
as they can only be accessed from the Control Domain.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/cf4d261ba1253879e117f1598b9f47798cbda635.1645458249.git.geert+renesas@glider.be
wfx_bh_request_tx() send HIF request asynchronously through bh_work().
Then the caller will run wfx_bh_poll_irq() to poll the answer.
However it useless to burn CPU cycles for the polling while the request
has yet been sent. Worse, wfx_bh_poll_irq() may get the CPU and prevent
wfx_bh_request_tx() to run. This problem has been observed on mono core
architecture.
This first exchange is correct:
kworker/u2:1-24 [000] .... : io_read32: CONTROL: 00003000
kworker/u2:1-24 [000] .... : io_read32: CONTROL: 00003000
kworker/u2:1-24 [000] .... : io_read32: CONTROL: 00003004
kworker/u2:1-24 [000] .... : io_read32: CONTROL: 00003004
kworker/0:1H-40 [000] .... : io_read: QUEUE: 08 00 09 0c 00 00 00 00 3a 7b 00 30 (12 bytes)
kworker/0:1H-40 [000] .... : piggyback: CONTROL: 00003000
kworker/0:1H-40 [000] .... : hif_recv: 0:2:CNF_CONFIGURATION: 00 00 00 00 (8 bytes)
kworker/0:1H-40 [000] .... : io_read32: CONFIG: 03010200
kworker/0:1H-40 [000] .... : bh_stats: IND/REQ/CNF: 0/ 0/ 1, REQ in progress: 0, WUP: release
... while the following is not:
kworker/u2:1-24 [000] .... : io_read32: CONTROL: 00003000
kworker/u2:1-24 [000] .... : io_read32: CONTROL: 00003000
kworker/u2:1-24 [000] .... : io_read32: CONTROL: 00003000
[...loop until timeout...]
wfx-sdio mmc0:0001:1: time out while polling control register
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20220225112405.355599-10-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When possible it is better to wait for an explicit event instead of wait
an arbitrary amount of time.
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20220225112405.355599-9-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We need to calculate the max file size accurately if the total blocks
that can address by block tree exceed the upper_limit. But this check is
not correct now, it only compute the total data blocks but missing
metadata blocks are needed. So in the case of "data blocks < upper_limit
&& total blocks > upper_limit", we will get wrong result. Fortunately,
this case could not happen in reality, but it's confused and better to
correct the computing.
bits data blocks metadatablocks upper_limit
10 16843020 66051 2147483647
11 134480396 263171 1073741823
12 1074791436 1050627 536870911 (*)
13 8594130956 4198403 268435455 (*)
14 68736258060 16785411 134217727 (*)
15 549822930956 67125251 67108863 (*)
16 4398314962956 268468227 33554431 (*)
[*] Need to calculate in depth.
Fixes: 1c2d14212b ("ext2: Fix underflow in ext2_max_size()")
Link: https://lore.kernel.org/r/20220212050532.179055-1-yi.zhang@huawei.com
Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Check if operation is valid before changing any
settings in hardware. Otherwise it results in
changes being made despite it not being a valid
operation.
Fixes: 78eab33bb6 ("net: sparx5: add vlan support")
Signed-off-by: Casper Andersson <casper.casan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The function pci_find_capability() in t3_prep_adapter() can fail, so its
return value should be checked.
Fixes: 4d22de3e6c ("Add support for the latest 1G/10G Chelsio adapter, T3")
Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Russell King says:
====================
net: dsa: sja1105: phylink updates
This series updates the phylink implementation in sja1105 to use the
supported_interfaces bitmap, convert to the mac_select_pcs() interface,
mark as non-legacy, and get rid of the validation method.
As a final step, enable switching between SGMII and 2500BASE-X as it
is a feature that Vladimir desires.
Specifically, the patches in this series:
1. Populates the supported_interfaces bitmap.
2. As a result of the supported_interfaces bitmap being populated,
sja1105 no longer needs to check the interface mode as phylink
will do this.
3. Switch away from using phylink_set_pcs(), using the mac_select_pcs()
method instead.
4. Mark the driver as not-legacy
5. Fill in mac_capabilities using _exactly_ the same conditions as is
currently used to decide which link modes to support, and convert
to use phylink_generic_validate()
6. Add brand new support to permit switching between SGMII and
2500BASE-X modes of operation as per Vladimir's single patch that
performs steps 1, 2, 5 and 6 in one go.
There are some additional changes in Vladimir's single patch that I
have not included:
* validation of priv->phy_mode[] in sja1105_phylink_get_caps(). The
driver has already validated the phy_mode for each port in
sja1105_init_mii_settings(), and a failure here will prevent the
driver reaching sja1105_phylink_get_caps().
* Changing the decisions on which mac_capabilities to set. Vladimir's
patch always sets MAC_10FD | MAC_100FD | MAC_1000FD despite the
current code clearly making the 1G speed conditional on the
xmii_mode for the port. The change in decision making may be
visible when in PHY_INTERFACE_MODE_INTERNAL mode, for which
the phylink_generic_validate() will pass through all the MAC
capabilities as ethtool link modes.
Hence, if we have PHY_INTERFACE_MODE_INTERNAL but supports_rgmii[]
or supports_sgmii[] is non-zero, currently we do not get 1G speeds.
With Vladimir's additional change, we will get 1G speeds.
While it is not clear whether that can happen, I feel changing the
decision making should be a separate patch.
* The decision for MAC_2500FD is made differently -
sja1105_init_mii_settings() allows PHY_INTERFACE_MODE_2500BASEX
when supports_2500basex[] is non-zero, and is not based on any other
condition such as supports_sgmii[] or supports_rgmii[]. Vladimir's
patch makes it additionally conditional on those supports_.gmii[]
settings, which is a functional change that should be made in a
separate patch - and if desired, then sja1105_init_mii_settings()
should also be updated at the same time.
Consequently, I believe that my previous objections to Vladimir's
single patch approach are well founded and justified, even through
Vladimir is the maintainer of this driver. I have no objection to
the additional changes, I just don't think they should all be wrapped
up into a single patch that converts the way validation is done _and_
also makes a bunch of other functional changes.
RFC->non-RFC: added Vladimir's Reviewed-by's, fixed the typo in the
commit message of patch 6, and removed the phrase at the end of a
comment as requested.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean suggests that sja1105 can support switching between
SGMII and 2500BASE-X modes. Augment sja1105_phylink_get_caps() to
fill in both interface modes if they can be supported.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Populate the MAC capabilities for the SJA1105 DSA switch using the same
decision making which sja1105_phylink_validate() uses. Remove the now
obsolete sja1105_phylink_validate() implementation to allow DSA to use
phylink_generic_validate() for this switch driver.
As noted by Vladimir, this fixes an inconsequential bug which allowed
gigabit and lower interface modes to be indicated when operating in
2500base-X mode.
Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
The sja1105 DSA driver does not have a phylink_mac_config() method
implementation, it is safe to mark this as a non-legacy driver.
Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Convert the PCS selection to use mac_select_pcs, which allows the PCS
to perform any validation it needs, and removes the need to set the PCS
in the mac_config() callback, delving into the higher DSA levels to do
so.
Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
When the supported interfaces bitmap is populated, phylink will itself
check that the interface mode is present in this bitmap. Drivers no
longer need to perform this check themselves. Remove these checks.
Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Populate the supported interfaces bitmap for the SJA1105 DSA switch.
This switch only supports a static model of configuration, so we
restrict the interface modes to the configured setting.
Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Vladimir Oltean <vladimir. │
Signed-off-by: David S. Miller <davem@davemloft.net>
Add pins, groups, and function for the Clock-Synchronized Serial
Interfaces with FIFO (MSIOF) on the Renesas R-Car S4-8 (R8A779F0) SoC.
Based on a larger patch in the BSP by LUU HOAI.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/c625769714b1027a756dd2ed4a017eb24708a041.1645457792.git.geert+renesas@glider.be
Add pins, groups, and functions for the High Speed Serial Communication
Interfaces with FIFO (HSCIF) on the Renesas R-Car S4-8 (R8A779F0) SoC.
Based on a larger patch in the BSP by LUU HOAI.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/2b85b8857c1189fa6ee33e2f57fe746d740481d1.1645457792.git.geert+renesas@glider.be
Add pins, groups, and functions for the Serial Communication Interfaces
with FIFO (SCIF) on the Renesas R-Car S4-8 (R8A779F0) SoC.
Extracted from a larger patch in the BSP by LUU HOAI.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/6369359a53483291ee536787c8a232462ff1b3a9.1645457792.git.geert+renesas@glider.be
Add initial Pin Function Controller (PFC) support for the Renesas R-Car
S4-8 (R8A779F0) SoC, including bias, drive strength and voltage control.
Based on a larger patch in the BSP by LUU HOAI.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/fd8201da404b7b0897130b254380ffc97f437266.1645457792.git.geert+renesas@glider.be
