H6 expands the number of channels in each direction to 16, so the slot
number fields need to be expanded from 3 to 4 bits each.
R329/D1 expand that further by allowing each of the 16 slots to map to
any of 4 data pins. For TX, the configuration of each pin is
independent, so there is a copy of the mapping registers for each pin.
For RX, each of the 16 slots can map to only one pin, so the registers
were changed to add the pin selection inline with the channel mapping.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220203020116.12279-3-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
R329 contains I2S controllers which are similar to, but are incompatible
with, the H6 variant, because they change the layout of the RX channel
mapping registers. The D1 contains I2S controllers which appear to be
identical to those in the R329.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220203020116.12279-2-samuel@sholland.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Without this patch, module init sections are disabled by patching their
names in arch-specific code when they're loaded (which prevents code in
layout_sections from finding init sections). This patch uses the new
arch-specific module_init_section instead.
This allows modules that have .init_array sections to have the
initialisers properly called (on load, before init). Without this patch,
the initialisers are not called because .init_array is renamed to
_init_array, and thus isn't found by code in find_module_sections().
Signed-off-by: Wedson Almeida Filho <wedsonaf@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220202055123.2144842-1-wedsonaf@google.com
's3_wmi.input' is a managed resource, so there should be no need to free it
explicitly.
Moreover, 's3_wmi' is a global variable. 's3_wmi.input' should be NULL
when this error handling path is executed, because it has not been
assigned yet.
All this is puzzling. So simplify it and remove a few lines of code to have
it be more straightforward.
Fixes: 3dda3b3798 ("platform/x86: Add custom surface3 platform device for controlling LID")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/8b1a6d05036d5d9527241b2345482b369331ce5c.1643531799.git.christophe.jaillet@wanadoo.fr
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Replace acpi_bus_get_device() that is going to be dropped with
acpi_fetch_acpi_dev().
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/5805278.lOV4Wx5bFT@kreacher
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Replace acpi_bus_get_device() that is going to be dropped with
acpi_fetch_acpi_dev().
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/2631712.mvXUDI8C0e@kreacher
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The ThinkPad T15g Gen 2 has 2 fan, add a TPACPI_FAN_2CTL quirk entry for
it to the fan_quirk_table[] so that both fans can be controllerd.
Reported-and-tested-by: David Dreschner <david@dreschner.net>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220203103302.49401-1-hdegoede@redhat.com
Add support for reporting PCI_EXP_LNKSTA_DLLLA bit in Link Control register
on emulated bridge via PCIE_STAT_OFF reg. Function mvebu_pcie_link_up()
already parses this register and returns if Data Link is Active or not.
Also correctly indicate DLLLA capability via PCI_EXP_LNKCAP_DLLLARC bit in
Link Control Capability register which is required for reporting DLLLA bit.
Link: https://lore.kernel.org/r/20220104153529.31647-12-pali@kernel.org
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Logic and code for clearing PCI_EXP_LNKCTL_CLKREQ_EN bit is correct, but
comment describing it is misleading. PCI_EXP_LNKCTL_CLKREQ_EN bit should be
hardwired to zero but mvebu hw allows to change it.
Link: https://lore.kernel.org/r/20220104153529.31647-11-pali@kernel.org
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reason for clearing this bit is because mvebu hw returns incorrectly this bit set to 1.
Link: https://lore.kernel.org/r/20220104153529.31647-10-pali@kernel.org
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
With this change also PCI vendor id is read from mvebu registers.
Link: https://lore.kernel.org/r/20220104153529.31647-9-pali@kernel.org
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
This will make PCI bridge to return zeros when accessing IO base and limit
registers, as required by PCIe base specification.
This allows to remove adhoc checks around mvebu_pcie_handle_iobase_change()
function for unsupported IO ranges. PCI_BRIDGE_EMUL_NO_IO_FORWARD ensures
that there will be no non-zeros write to IO registers when IO is not
supported.
Link: https://lore.kernel.org/r/20220104153529.31647-8-pali@kernel.org
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Member pcie->nports is initialized to correct value before the previous
for-loop. There is not need to initialize it more times.
Link: https://lore.kernel.org/r/20220104153529.31647-7-pali@kernel.org
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
There is no description for CONFIG_PCI_MVEBU option. Add it.
Link: https://lore.kernel.org/r/20220104153529.31647-6-pali@kernel.org
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Like PCI_BRIDGE_EMUL_NO_PREFMEM_FORWARD, this new flag specifies that
emulated PCI bridge does not support forwarding of IO requests in given
range between primary and secondary buses. This flag should be used as
argument for pci_bridge_emul_init() for hardware setup without IO support.
Setting this flag cause that IO base and limit registers are read-only.
Link: https://lore.kernel.org/r/20220104153529.31647-5-pali@kernel.org
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
This flag describe whether PCI bridge supports forwarding of prefetchable
memory requests in given range between primary and secondary buses. It does
not specify if bridge has support for prefetchable memory BAR (moreover
this pci-bridge-emul.c driver does not provide support for BARs).
So change name of this flag to be less misleading and add comment.
Link: https://lore.kernel.org/r/20220104153529.31647-4-pali@kernel.org
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
It is read-only constant structure, so properly mark it with const keyword.
Link: https://lore.kernel.org/r/20220104153529.31647-3-pali@kernel.org
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Other uses of &gang->aff_list_head, eg in spufs_assert_affinity, indicate
that the list elements have type spu_context, not spu as used here. Change
the type of tmp accordingly.
This has no impact on the execution, because tmp is not used in the body of
the loop.
Fixes: c5fc8d2a92 ("[CELL] cell: add placement computation for scheduling of affinity contexts")
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Reviewed-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1588929176-28527-1-git-send-email-Julia.Lawall@inria.fr
The ThinkPad T15g Gen 2 has 2 fan, add a TPACPI_FAN_2CTL quirk entry for
it to the fan_quirk_table[] so that both fans can be controllerd.
Reported-and-tested-by: David Dreschner <david@dreschner.net>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220203103302.49401-1-hdegoede@redhat.com
When figuring out the number of threads, the debug message prints "1
thread" for the first iteration of the loop, instead of the actual
number of threads calculated from the length of the
"ibm,ppc-interrupt-server#s" property.
* /cpus/PowerPC,POWER8@20...
ibm,ppc-interrupt-server#s -> 1 threads <--- WRONG
thread 0 -> cpu 0 (hard id 32)
thread 1 -> cpu 1 (hard id 33)
thread 2 -> cpu 2 (hard id 34)
thread 3 -> cpu 3 (hard id 35)
thread 4 -> cpu 4 (hard id 36)
thread 5 -> cpu 5 (hard id 37)
thread 6 -> cpu 6 (hard id 38)
thread 7 -> cpu 7 (hard id 39)
* /cpus/PowerPC,POWER8@28...
ibm,ppc-interrupt-server#s -> 8 threads
thread 0 -> cpu 8 (hard id 40)
thread 1 -> cpu 9 (hard id 41)
thread 2 -> cpu 10 (hard id 42)
thread 3 -> cpu 11 (hard id 43)
thread 4 -> cpu 12 (hard id 44)
thread 5 -> cpu 13 (hard id 45)
thread 6 -> cpu 14 (hard id 46)
thread 7 -> cpu 15 (hard id 47)
(...)
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210120181847.952106-1-farosas@linux.ibm.com
Cortex-A510's erratum #2077057 causes SPSR_EL2 to be corrupted when
single-stepping authenticated ERET instructions. A single step is
expected, but a pointer authentication trap is taken instead. The
erratum causes SPSR_EL1 to be copied to SPSR_EL2, which could allow
EL1 to cause a return to EL2 with a guest controlled ELR_EL2.
Because the conditions require an ERET into active-not-pending state,
this is only a problem for the EL2 when EL2 is stepping EL1. In this case
the previous SPSR_EL2 value is preserved in struct kvm_vcpu, and can be
restored.
Cc: stable@vger.kernel.org # 53960faf2b: arm64: Add Cortex-A510 CPU part definition
Cc: stable@vger.kernel.org
Signed-off-by: James Morse <james.morse@arm.com>
[maz: fixup cpucaps ordering]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220127122052.1584324-5-james.morse@arm.com
Prior to commit defe21f49b ("KVM: arm64: Move PC rollback on SError to
HYP"), when an SError is synchronised due to another exception, KVM
handles the SError first. If the guest survives, the instruction that
triggered the original exception is re-exectued to handle the first
exception. HVC is treated as a special case as the instruction wouldn't
normally be re-exectued, as its not a trap.
Commit defe21f49b didn't preserve the behaviour of the 'return 1'
that skips the rest of handle_exit().
Since commit defe21f49b, KVM will try to handle the SError and the
original exception at the same time. When the exception was an HVC,
fixup_guest_exit() has already rolled back ELR_EL2, meaning if the
guest has virtual SError masked, it will execute and handle the HVC
twice.
Restore the original behaviour.
Fixes: defe21f49b ("KVM: arm64: Move PC rollback on SError to HYP")
Cc: stable@vger.kernel.org
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220127122052.1584324-4-james.morse@arm.com
When any exception other than an IRQ occurs, the CPU updates the ESR_EL2
register with the exception syndrome. An SError may also become pending,
and will be synchronised by KVM. KVM notes the exception type, and whether
an SError was synchronised in exit_code.
When an exception other than an IRQ occurs, fixup_guest_exit() updates
vcpu->arch.fault.esr_el2 from the hardware register. When an SError was
synchronised, the vcpu esr value is used to determine if the exception
was due to an HVC. If so, ELR_EL2 is moved back one instruction. This
is so that KVM can process the SError first, and re-execute the HVC if
the guest survives the SError.
But if an IRQ synchronises an SError, the vcpu's esr value is stale.
If the previous non-IRQ exception was an HVC, KVM will corrupt ELR_EL2,
causing an unrelated guest instruction to be executed twice.
Check ARM_EXCEPTION_CODE() before messing with ELR_EL2, IRQs don't
update this register so don't need to check.
Fixes: defe21f49b ("KVM: arm64: Move PC rollback on SError to HYP")
Cc: stable@vger.kernel.org
Reported-by: Steven Price <steven.price@arm.com>
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220127122052.1584324-3-james.morse@arm.com
Architectures others than x86 have a stub implementation calling
WARN_ON_ONCE(). The appropriate headers need to be included, otherwise
the header-test target will fail with:
HDRTEST drivers/gpu/drm/i915/i915_mm.h
In file included from <command-line>:
./drivers/gpu/drm/i915/i915_mm.h: In function ‘remap_io_mapping’:
./drivers/gpu/drm/i915/i915_mm.h:26:2: error: implicit declaration of function ‘WARN_ON_ONCE’ [-Werror=implicit-function-declaration]
26 | WARN_ON_ONCE(1);
| ^~~~~~~~~~~~
v2: Do not include <linux/printk.h> since call to pr_err() has been
removed
Fixes: 67c430bbaa ("drm/i915: Skip remap_io_mapping() for non-x86 platforms")
Cc: Siva Mullati <siva.mullati@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Siva Mullati <siva.mullati@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220131165926.3230642-3-lucas.demarchi@intel.com
Following what was done in drm_cache.c, when the stub for
remap_io_mapping() was added in commit 67c430bbaa ("drm/i915: Skip
remap_io_mapping() for non-x86 platforms"), it included a log message
with pr_err(). However just the warning is already enough and switching
to WARN_ONCE() allows us to keep the log message while avoiding log
spam.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220131165926.3230642-4-lucas.demarchi@intel.com
SAR GEO offsets are not supported on 3160 devices. The code was
refactored and caused us to start sending the command anyway, which
causes a FW assertion failure. Fix that only considering this feature
supported on FW API with major version is 17 if the device is not
3160.
Additionally, fix the caller of iwl_mvm_sar_geo_init() so that it
checks for the return value, which it was ignoring.
Reported-by: Len Brown <lenb@kernel.org>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Fixes: 78a19d5285 ("iwlwifi: mvm: Read the PPAG and SAR tables at INIT stage")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20220128144623.96f683a89b42.I14e2985bfd7ddd8a8d83eb1869b800c0e7f30db4@changeid
This feature has been deprecated and should not be used anymore. With
newer firmwares, namely *-67.ucode and above, trying to use it causes an
assertion failure in the FW, similar to this:
[Tue Jan 11 20:05:24 2022] iwlwifi 0000:04:00.0: 0x00001062 | ADVANCED_SYSASSERT
In order to prevent this feature from being used, remove it entirely
and get rid of the Kconfig option that
enables it (IWLWIFI_BCAST_FILTERING).
Fixes: cbaa6aeede ("iwlwifi: bump FW API to 67 for AX devices")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215488
Cc: stable@vger.kernel.org # 5.16.x
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20220128144623.9241e049f13e.Ia4f282813ca2ddd24c13427823519113f2bbebf2@changeid
The OF node pointer is always NULL, get rid of unused parameter in
orion_gpio_init(). As a side effect it will allow to switch GPIO
library to the fwnode API, as well as in case of resurrecting it here
it should be fwnode_handle anyways.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
When we register and we are in link protection passive, meaning
that the host can't touch the device, report RFKILL immediately
upon register() and don't wait for the CSME firmware to let us
know again about the link protection state.
What happens if we wait is that the host will not see RFKILL soon
enough and we'll have a window of time during which it can bring
up the device which will request ownership.
Fixes: 2da4366f9e ("iwlwifi: mei: add the driver to allow cooperation with CSME")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20220128142706.a136f9f46336.Ief7506dc3b1813a1943a5a639aa45d8e5f284f31@changeid
iwlmei can trigger a hardware RFKILL when the CSME firmware
does not want the host to touch the device.
But then, iwlmvm reports RFKILL which makes cfg80211 update
iwlmvm about RFKILL. iwlmvm then thinks there is a change in
the _software_ rfkill and it calls rfkill_blocked() to fetch
the RFKILL state. This returns that RFKILL is blocked (because
of iwlmei) and iwlmvm tells iwlmei that _software_ RFKILL is
asserted.
This is a bug of course.
Fix this by checking explicitly the software RFKILL state and
not the overall RFKILL state.
Fixes: 7ce1f2157e ("iwlwifi: mvm: read the rfkill state and feed it to iwlmei")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Fixes: 7ce1f2157e ("iwlwifi: mvm: read the rfkill state and feed it to iwlmei")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20220128142706.f293861a3f92.I9553d27df1de6fd5756a43ea5f8b89d06fa1a6f2@changeid
The shared area is a DMA memory allocated in the host and
mapped so that the host and the CSME firmware can
exchange data. It is mapped through a dedicated PCI device
that is driven by the mei bus driver.
The bus driver is in charge of allocating and mapping this
memory. It also needs to configure the CSME firmware with
a specific set of commands, so that the CSME firmware will
know that this memory is meant to be used by its internal
WLAN module.
For this, the CSME firmware first needs to completely
initialize its WLAN module and only then get the mapping
request.
The problem is that the mei bus enumeration completes
before the WLAN is completely ready. This means that
the WLAN module's initialization is racing with iwlmei's
allocation and mapping flow.
Testing showed a problem in resume flows where iwlmei
was too fast and the DMA mapping failed.
Add a retry mechanism to make sure that we will succeed
to map the memory.
Fixes: 2da4366f9e ("iwlwifi: mei: add the driver to allow cooperation with CSME")
Fixes: bcbddc4f9d ("iwlwifi: mei: wait before mapping the shared area")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20220128142706.cc51e6a6d635.I4b74a082eb8d89f9e4f556a27c4339c15444dc6c@changeid
The check makes sure that we can look at the ip header.
We first need to check that the basic ip header (20 bytes)
can be pulled before we look at the field that will teach
us how long is the ip header. This is why there are two
checks.
The second check was wrong and smatch pointed that
sizeof(ip_hdrlen(skb) - sizeof(*iphdr)) can't be right.
Looking at the code again made me think that we really
need ip_hdrlen(skb) since we want to make sure all the
IP header is in the buffer header. This will allow us
to set the transport offset and from there to look
at the transport header (TCP / UDP).
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Fixes: 2da4366f9e ("iwlwifi: mei: add the driver to allow cooperation with CSME")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20220128142706.6d9fcf82691e.I449b1e21c5b5478f2ac218522570479918f49f9d@changeid
There are a couple of bugs in this function:
1. It is declared as a non-static function, even though
it's only used in one file.
2. Its return value should be of type u32 but it returns
(in some cases) -1.
Fix them by making this function static and returning an
error value of type unsigned.
In addition, we're assigning the return value of this function
as the legacy rate even if the function returned an error value.
Fix this by assigning the lowest rate in this case.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reported-by: Ye Guojin <ye.guojin@zte.com.cn>
Reported-by: Zeal Robot <zealci@zte.com.cn>
Fixes: 9998f81e4b ("iwlwifi: mvm: convert old rate & flags to the new format.")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20220128142706.5612eeb9d6d0.I992e10d93fc22919b2bc42daad087ee1b5d6f014@changeid
We're checking the FW version of TX_CMD in order to decide whether to
convert rate_n_flags from the old format to the new one. If the API
is smaller or equal to 6 we should convert it. Currently we're
converting if the API version is greater than 6. Fix it.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Fixes: dc52fac37c ("iwlwifi: mvm: Support new TX_RSP and COMPRESSED_BA_RES versions")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20220128142706.a264ac51d106.I228ba1317cdcbfef931c09d280d701fcad9048d2@changeid
Backmerge to bring in 5.17-rc2 to introduce a common baseline
to merge i915_regs changes from drm-intel-next.
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
This started out with me noticing that "dom0_max_vcpus=<N>" with <N>
larger than the number of physical CPUs reported through ACPI tables
would not bring up the "excess" vCPU-s. Addressing this is the primary
purpose of the change; CPU maps handling is being tidied only as far as
is necessary for the change here (with the effect of also avoiding the
setting up of too much per-CPU infrastructure, i.e. for CPUs which can
never come online).
Noticing that xen_fill_possible_map() is called way too early, whereas
xen_filter_cpu_maps() is called too late (after per-CPU areas were
already set up), and further observing that each of the functions serves
only one of Dom0 or DomU, it looked like it was better to simplify this.
Use the .get_smp_config hook instead, uniformly for Dom0 and DomU.
xen_fill_possible_map() can be dropped altogether, while
xen_filter_cpu_maps() is re-purposed but not otherwise changed.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Link: https://lore.kernel.org/r/2dbd5f0a-9859-ca2d-085e-a02f7166c610@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
--------------cKY3Ggs6VDUCSn4I6iN78sHA
Content-Type: multipart/mixed; boundary="------------g0T69ASidFiPhh4eOY4XzIg1"
--------------g0T69ASidFiPhh4eOY4XzIg1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
The current implementation of gntdev guarantees that the first call to
IOCTL_GNTDEV_MAP_GRANT_REF will set @index to 0. This is required to
use gntdev for Wayland, which is a future desire of Qubes OS.
Additionally, requesting zero grants results in an error, but this was
not documented either. Document both of these.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/f66c5a4e-2034-00b5-a635-6983bd999c07@gmail.com
Signed-off-by: Juergen Gross <jgross@suse.com>
It is better/preferred not to include file names in source files
because (a) they are not needed and (b) they can be incorrect,
so just delete this incorrect file name.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Juergen Gross <jgross@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org
Link: https://lore.kernel.org/r/20220130191705.24971-1-rdunlap@infradead.org
Signed-off-by: Juergen Gross <jgross@suse.com>
After commit 2fd3fb0be1d1 ("kasan, vmalloc: unpoison VM_ALLOC pages
after mapping"), non-VM_ALLOC mappings will be marked as accessible
in __get_vm_area_node() when KASAN is enabled. But now the flag for
ringbuf area is VM_ALLOC, so KASAN will complain out-of-bound access
after vmap() returns. Because the ringbuf area is created by mapping
allocated pages, so use VM_MAP instead.
After the change, info in /proc/vmallocinfo also changes from
[start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmalloc user
to
[start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmap user
Fixes: 457f44363a ("bpf: Implement BPF ring buffer and verifier support for it")
Reported-by: syzbot+5ad567a418794b9b5983@syzkaller.appspotmail.com
Signed-off-by: Hou Tao <houtao1@huawei.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20220202060158.6260-1-houtao1@huawei.com
if_id will be always 0, because it was not yet initialized.
Fixes: 8dce439195 ("xfrm: interface with if_id 0 should return error")
Reported-by: Pavel Machek <pavel@denx.de>
Signed-off-by: Antony Antony <antony.antony@secunet.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
