of_amba_device_create() uses irq_of_parse_and_map() to translate
a DT interrupt specification into a Linux virtual interrupt number.
But it doesn't properly handle the case where the interrupt controller
is not yet available, eg, when pl011 interrupt is connected to MBIGEN
interrupt controller, because the mbigen initialization is too late,
which will lead to no IRQ due to no IRQ domain found, log is shown below,
"irq: no irq domain found for uart0 !"
use of_irq_get() to return -EPROBE_DEFER as above, and in the function
amba_device_try_add()/amba_device_add(), it will properly handle in such
case, also return 0 in other fail cases to be consistent as before.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Reported-by: Ruizhe Lin <linruizhe@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
After commit 77a7300aba ("of/irq: Get rid of NO_IRQ usage"),
no irq case has been removed, irq_of_parse_and_map() will return
0 in all cases when get error from parse and map an interrupt into
linux virq space.
amba_device_register() is only used on no-DT initialization, see
s3c64xx_pl080_init() arch/arm/mach-s3c/pl080.c
ep93xx_init_devices() arch/arm/mach-ep93xx/core.c
They won't set -1 to irq[0], so no need the warn.
This reverts commit 2eac58d502.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
No one use the following functions, kill them.
amba_aphb_device_add()
amba_apb_device_add()
amba_apb_device_add_res()
amba_ahb_device_add()
amba_ahb_device_add_res()
Cc: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Commit 344179fc7e ("ARM: 9106/1: traps: use get_kernel_nofault instead
of set_fs()") replaced an occurrence of __get_user() with
get_kernel_nofault(), but inverted the sense of the conditional in the
process, resulting in no values to be printed at all.
I.e., every exception stack now looks like this:
Exception stack(0xc18d1fb0 to 0xc18d1ff8)
1fa0: ???????? ???????? ???????? ????????
1fc0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ????????
1fe0: ???????? ???????? ???????? ???????? ???????? ????????
which is rather unhelpful.
Fixes: 344179fc7e ("ARM: 9106/1: traps: use get_kernel_nofault instead of set_fs()")
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
On Windows systems, ASUS laptops uses the "turn display off" key
(usually fn+f6) to turn both display and keyboard backlit off. On Linux
systems, this key has no effect at all since most desktop enviroments
don't deal with KEY_DISPLAY_OFF. By mapping it to KEY_SCREENLOCK
instead, would enable desktop environments to handle this key as a
screen lock intent from the user, out of the box.
Signed-off-by: Vinícius Angiolucci Reis <angiolucci@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The Microchip Icicle kit uses SiFive E51 and U54 cores, so it looks that
also Core Local Interruptor and Platform-Level Interrupt Controller are
coming from SiFive. Add proper compatibles to silence dtbs_check
warnings:
clint@2000000: compatible:0: 'sifive,clint0' is not one of ['sifive,fu540-c000-clint', 'canaan,k210-clint']
interrupt-controller@c000000: compatible:0: 'sifive,plic-1.0.0' is not one of ['sifive,fu540-c000-plic', 'canaan,k210-plic']
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20210920130412.145231-1-krzysztof.kozlowski@canonical.com
The DTSI file defines soc node and address/size cells, so there is no
point in duplicating it in DTS file.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Reviewed-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
Tested-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
Link: https://lore.kernel.org/r/20210920130248.145058-3-krzysztof.kozlowski@canonical.com
Add missing sifive,fu540 compatible to fix dtbs_check warnings:
arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dt.yaml: /: compatible: 'oneOf' conditional failed, one must be fixed:
['sifive,hifive-unleashed-a00', 'sifive,fu540-c000'] is too short
'sifive,hifive-unleashed-a00' is not one of ['sifive,hifive-unmatched-a00']
'sifive,fu740-c000' was expected
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Reviewed-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
Tested-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
Link: https://lore.kernel.org/r/20210920130248.145058-2-krzysztof.kozlowski@canonical.com
Some Apple ISO keyboards have a quirk where the backtick/tilde key is
swapped with the less-than/greater-than key. Unfortunately, there is no
perfectly reliable way to detect whether a keyboard has the quirk or
not, but the quirk appears to only be present on models that support
Bluetooth, and the affected keyboards usually report country code 13 in
the HID descriptor.
Therefore, the best we can do is to change
/sys/module/hid_apple/parameters/iso_layout to a ternary:
0 = Not ISO or ISO and not quirky
1 = ISO and quirky
-1 = Guess based on product ID and country code
Table of keyboards that José, Julian and I have tested:
Product Model Shape Labels Bus Country Quirky
=========================================================
05ac:0201 M2452 ANSI Usonian USB 0 No
05ac:020b A1048 ANSI Usonian USB 0 No
05ac:020c A1048 ISO Québécois USB 13 No
05ac:0221 A1243 ISO Norwegian USB 13 No
05ac:0221 A1243 ISO Portuguese USB 13 No
05ac:0221 A1243 ISO Swedish USB 13 No
05ac:0221 A1243 ISO Swiss USB 13 No
05ac:022c A1255 ANSI Usonian BT 33 No
05ac:022d A1255 ISO Hebrew BT 13 Yes
05ac:022d A1255 ISO Québécois BT 13 Yes
05ac:022d A1255 ISO Spanish BT 13 Yes
05ac:023a A1314 ISO Russian BT 13 Yes
05ac:023a A1314 ISO Swiss BT 13 Yes
05ac:024f A1243 ANSI Usonian USB 0 No
05ac:0250 A1243 ISO British USB 13 No
05ac:0250 A1243 ISO German USB 13 No
05ac:0250 A1243 ISO Italian USB 13 No
05ac:0250 A1243 ISO Québécois USB 13 No
05ac:0251 A1243 JIS Japanese USB 15 No
05ac:0255 A1314 ANSI Usonian BT 33 No
05ac:0255 A1314 ANSI Taiwanese BT 33 No
05ac:0255 A1314 ANSI Thai BT 33 No
05ac:0256 A1314 ISO Arabic BT 13 Yes
05ac:0256 A1314 ISO French BT 13 Yes
05ac:0256 A1314 ISO German BT 13 Yes
05ac:0256 A1314 ISO Norwegian BT 13 Yes
05ac:0256 A1314 ISO Spanish BT 13 Yes
05ac:0256 A1314 ISO Swiss BT 13 Yes
05ac:0257 A1314 JIS Japanese BT 15 No
05ac:0267 A1644 ANSI Usonian USB 33 No
004c:0267 A1644 ANSI Usonian BT 0 No
05ac:0267 A1644 ISO British USB 13 Yes
004c:0267 A1644 ISO British BT 0 Yes
05ac:0267 A1644 ISO Finnish USB 13 Yes
004c:0267 A1644 ISO Finnish BT 0 Yes
05ac:0267 A1644 ISO Québécois USB 13 Yes
004c:0267 A1644 ISO Québécois BT 0 Yes
05ac:0267 A1644 ISO Spanish USB 13 Yes
004c:0267 A1644 ISO Spanish BT 0 Yes
05ac:0267 A1644 ISO Swiss USB 13 Yes
004c:0267 A1644 ISO Swiss BT 0 Yes
05ac:0267 A1644 JIS Japanese USB 15 No
004c:0267 A1644 JIS Japanese BT 0 No
05ac:029c A2450 ANSI Usonian USB 33 No
004c:029c A2450 ANSI Usonian BT 0 No
05ac:029c A2450 ISO Spanish USB 13 Yes
004c:029c A2450 ISO Spanish BT 0 Yes
05ac:029c A2450 JIS Japanese USB 15 No
004c:029c A2450 JIS Japanese BT 0 No
Reported-by: José Expósito <jose.exposito89@gmail.com>
Tested-by: José Expósito <jose.exposito89@gmail.com>
Tested-by: Julian Weigt <juw@posteo.de>
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The ANSI, ISO, and JIS variants of this keyboard all have the same
product ID.
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
A new 'chassis-type' root node property has recently been approved for
the device-tree specification.
Add this property for end-user devices (such as laptops,
smartphones and tablets) based on Samsung S5Pv210 ARM SoCs.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20211017101228.19478-3-krzysztof.kozlowski@canonical.com
A new 'chassis-type' root node property has recently been approved for
the device-tree specification.
Add this property for end-user devices (such as laptops,
smartphones and tablets) based on Samsung Exynos ARM SoCs.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20211017101228.19478-2-krzysztof.kozlowski@canonical.com
A new 'chassis-type' root node property has recently been approved for
the device-tree specification.
Add this property for end-user devices (such as laptops,
smartphones and tablets) based on Samsung Exynos ARM64 SoCs.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20211017101228.19478-1-krzysztof.kozlowski@canonical.com
Add new registers to support systems with multiply cooling devices.
Modular systems support up-to four cooling devices. This capability
is detected according to the registers initial setting.
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reviewed-by: Michael <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20211002093609.3771576-1-vadimp@nvidia.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add documentation for the new attributes for line cards:
- CPLDs versioning.
- Write protection control for 'nvram' devices.
- Line card reset reasons.
- Enabling burning of FPGA and CPLDs.
- Enabling burning of FPGA and gearbox SPI flashes,
- Enabling power of whole line card.
- Enabling power of QSFP ports equipped on line card.
- The maximum powered required for line card feeding.
- Line card configuration Id.
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reviewed-by: Michael Shych <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20211002093238.3771419-10-vadimp@nvidia.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add documentation for the new attributes:
- "bios_active_image"; "bios_auth_fail"; "bios_upgrade_fail";
"bios_safe_mode" to represent various BIOS statuses.
- "lc{n}_enable" - for put/release the line card to/from enable state.
- "lc{n}_pwr" - for power on/off the line card.
- "lc{n}_rst_mask" - for line card reset state enforced by ASIC, when
it sets it due to some abnormal ASIC behavior.
- "psu3_on"; "psu4_on" - for connection/disconnection power supply unit
to/from the power source.
- "pm_mgmt_en" - for setting power management control ownership. When
power management control is provided by hardware, it means that
hardware will automatically power off one or more line cards in case
system power budget is under power required for feeding all powered
on line cards. It could be a case, when some of power units lost
power good state.
- "shutdown_unlock" - for unlocking system after hardware or firmware
thermal shutdown, which causes locking of the all interfaces to ASIC.
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reviewed-by: Michael Shych <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20211002093238.3771419-9-vadimp@nvidia.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Provide support for the Nvidia MSN4800-XX line cards for MSN4800
Ethernet modular switch system, providing a high performance switching
solution for Enterprise Data Centers (EDC) for building Ethernet based
clusters, High-Performance Computing (HPC) and embedded environments.
Initial version provides support for line card type MSN4800-C16. This
type of line card is equipped with:
- Lattice CPLD device, used for system and ports control.
- four Nvidia gearbox devices, used for port splitting.
- FPGA device, used for gearboxes management.
- 16x100G QSFP28 ports.
- hotpswap controllers, voltage regulators, analog-to-digital
convertors, nvram devices.
- status LED.
During initialization driver creates:
- line card's I2C tree through "i2c-mux-mlxcpd" driver.
- line card's LED objects through "leds-mlxreg" driver.
- line card's CPLD register space input / output "hwmon" attributes for
line control and monitoring through "mlxreg-io" driver. These
attributes provide CPLD and FPAG versioning, control for upgradable
components burning, NVRAM devices write protection, line card
revision, line card power consuming, line card reset cause
indication, etcetera.
Lattice CPLD device and nvram devices are feeding from auxiliary power
domain and accessible, when line card is powered off. These devices
are connected by line card driver probing routine, invoked after line
card security verification is done by hardware and event lc#n_verified
is received for line card located in slot #n.
Gearboxes, FPGA, hotpswap controllers, voltage regulators,
analog-to-digital convertors are feeding from main power domain. These
devices are connected after power good event "lc#n_powered" is received
for line card located in slot #n.
The driver 'mlxreg-lc' is driven by 'mlxreg-hotplug' driver following
relevant "hotplug" events.
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reviewed-by: Michael Shych <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20211002093238.3771419-8-vadimp@nvidia.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Extend structure 'mlxreg_core_data' with the field "secured". The
purpose of this field is to restrict access to some attributes, if
kernel is configured with security options, like:
LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY.
Access to some attributes, which for example, allow burning of some
hardware components, like FPGA, CPLD, SPI, etcetera can break the
system. In case user does not want to allow such access, it can disable
it by setting security options.
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reviewed-by: Michael Shych <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20211002093238.3771419-7-vadimp@nvidia.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Extend maximum number of the attributes, exposed to 'sysfs'.
It is requires in order to support modular systems, which
provide more attributes for system control, statuses and info.
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reviewed-by: Michael Shych <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20211002093238.3771419-6-vadimp@nvidia.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add event notifier callbacks for modular system line cards. These
callbacks are to be passed to "mlxreg-hotplug" driver by line card
driver during probing. Then, when any line card related hotplug event
is received (insertion ,power, synch, ready), hotplug driver will
invoke callback for the relevant line card.
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reviewed-by: Michael Shych <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20211002093238.3771419-5-vadimp@nvidia.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Extend the structure 'mlxreg_hotplug_device" with platform device field
to allow transition of the register map and system interrupt line number
to underlying hotplug devices, sharing the same register map and
same interrupt line with 'mlxreg-hotplug' driver.
Extend logic for hotplug devices creation and removing according to
the action associated with the hotplug device description. Previously
hotplug driver was capable to attach / de-attach upon hotplug events
only I2C devices handled by simple I2C drivers. Now it should be able
to attach also devices handled by the platform drivers.
The motivation is to allow transition of platform data like:
- system interrupt line number, sharing with 'mlxreg-hotplug' to
underlying hotplug devices.
- shared register map of programmable devices on main board to
underlying hotplug devices.
Additioanlly the number of 'sysfs' attributes is increased, since
modular system defines more 'sysfs' attributes.
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reviewed-by: Michael Shych <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20211002093238.3771419-4-vadimp@nvidia.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add initial chassis management support for Nvidia modular Ethernet
switch systems MSN4800, providing a high performance switching solution
for Enterprise Data Centers (EDC) for building Ethernet based clusters,
High-Performance Computing (HPC) and embedded environments.
This system could be equipped with the different types of replaceable
line cards and management board. The first system flavor will support
the line card type MSN4800-C16 equipped with Lattice CPLD devices aimed
for system and ASIC control, one Nvidia FPGA for gearboxes (PHYs)
management, and four Nvidia gearboxes for the port control and with
16x100GbE QSFP28 ports and also with various devices for electrical
control.
The system is equipped with eight slots for line cards, four slots for
power supplies and six slots for fans. It could be configured as fully
populated or with even only one line card. The line cards are
hot-pluggable.
In the future when more line card flavors are to be available (for
example line cards with 8x200Gb Eth port, with 4x400 Eth ports, or with
some kind of smart cards for offloading purpose), any type of line card
could be inserted at any slot.
The system is based on Nvidia Spectrum-3 ASIC. The switch height is
4U and it fits standard rack size.
System could be configured as fully populated or with even only one
line card. The line cards are hot-pluggable.
Line cards are connected to the chassis through I2C interface for the
chassis management operations and through PCIe for the networking
operations. Future line cards could be connected to the chassis through
InfiniBand fabric, instead of PCIe.
The first type of line card supports 16x100GbE QSFP28 Ethernet ports.
Those line cards equipped with the programmable devices aimed for
system control of Nvidia Ethernet switch ASIC control, Nvidia FPGA,
Nvidia gearboxes (PHYs).
The next coming card generations are supposed to support:
- Line cards with 8x200Gbe QSFP28 Ethernet ports.
- Line cards with 4x400Gbe QSFP-DD Ethernet ports.
- Smart cards equipped with Nvidia ARM CPU for offloading and for fast
access to the storage (EBoF).
- Fabric cards for inter-connection.
The basic system initialization flow with input signals from the
programmable device to kernel hotplug driver and with OS response
to some of these signals is depicted below.
lc#n_prsnt *-> Input: line card presence in/out events.
Informational event. Required action - 'udev' event
generation for logging.
lc#n_verified *-> Input: line card verification status events coming
after line card security signature validation by
hardware. Required action - connect line card
driver and initialized line card devices feeding
from system auxiliary power domain.
lc#n_pwr <-* Output: line card power on / off from OS. Action
should be performed by platform power management
driver.
lc#n_powered *-> Input: line card power on/off events coming after
line card "power good" on/off events, mean that
line card power up sequence has been successfully
completed or line card "power good" status has been
dropped. Required action - connect line card
devices feeding from system main power domain.
lc#n_synced *-> Input: line card synchronization events, coming
after hardware-firmware synchronization handshake.
Required action - to enable line card, in case
lc#n_ready has been received before.
lc#n_ready *-> Input: line card ready events, indicating line card
PHYs ready / unready states. Required action -
enable line card, in case lc#n_synced has been
received before.
lc#n_enable <-* Output: line card enable from OS - release FPGA and
PHYs line card devices from reset state. Action
should be performed by platform power management
driver.
lc#n_active *-> Input: when line card "active event" is received
for particular line card, its network, hardware
monitoring and thermal interfaces should be
configured according to the configuration obtained
from the firmware. When opposite "inactive event"
is received all the above interfaces should be
teared down. Required action - connect / disconnect
the above line card interfaces through ASIC I2C
chassis management driver.
For initial support:
- Define new system type 'VMOD0011' to support new modular system.
- Provide initial platform configuration for new system type.
- Extend the registers definitions.
- Add support for modular system registers related to line card
specific events - insertion/removal, power on/off, verification
and activation.
- Add hotplug configuration for the above events.
- Add configurations for hotplug actions for the modular system.
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reviewed-by: Michael Shych <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20211002093238.3771419-3-vadimp@nvidia.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add new types for the Nvidia modular systems MSN4800 which could
be equipped with the different types of replaceable line cards.
Add new type to specify the kind of hotplug events for the line cards.
The line card events are generated by the programmable device located
on the main board. This device implements interrupt controller logic.
Line card interrupts are associated with different line cards states
during its initialization: insertion, security signature validation,
power good state, security validation, hardware-firmware
synchronization state, line card PHYs readiness state, firmware
availability for line card ports. Also under some circumstances
hardware can generate thermal shutdown for particular line card.
Add new type specifying the action, which should be performed when
particular hotplug event is received. This action defines in which way
hotplug event should be handled by hotplug driver. There are the next
actions types:
- Connect I2C device with empty 'platform_data' field according to the
platform topology, if device is configured (for example, power unit
micro-controller driver, when power unit is connected to power source
(this is what is currently supported).
- Connect device with 'platform_data' field set according to the
platform topology. The purpose is to pass 'platform_data' through
hotplug driver to underlying device (for example line card driver).
- No device is associated with hotplug event - just send "udev" event
(this is what is currently supported).
Extend structure 'mlxreg_hotplug_device' with hotplug action field.
Extend structure 'mlxreg_core_data' with:
- Registers for line card power and enabling control.
- Slot number field, to indicate at which physical slot replaceable
line card device is located.
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reviewed-by: Michael Shych <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20211002093238.3771419-2-vadimp@nvidia.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The branch is a stable branch shared with ARM maintainers for the
first 13th patches of the series:
It is based on v5.14-rc3.
As stated by the changelog:
" [... ] enabling ARMv8.6 support for timer subsystem, and was prompted by a
discussion with Oliver around the fact that an ARMv8.6 implementation
must have a 1GHz counter, which leads to a number of things to break
in the timer code:
- the counter rollover can come pretty quickly as we only advertise a
56bit counter,
- the maximum timer delta can be remarkably small, as we use the
countdown interface which is limited to 32bit...
Thankfully, there is a way out: we can compute the minimal width of
the counter based on the guarantees that the architecture gives us,
and we can use the 64bit comparator interface instead of the countdown
to program the timer.
Finally, we start making use of the ARMv8.6 ECV features by switching
accesses to the counters to a self-synchronising register, removing
the need for an ISB. Hopefully, implementations will *not* just stick
an invisible ISB there...
A side effect of the switch to CVAL is that XGene-1 breaks. I have
added a workaround to keep it alive.
I have added Oliver's original patch[0] to the series and tweaked a
couple of things. Blame me if I broke anything.
The whole things has been tested on Juno (sysreg + MMIO timers),
XGene-1 (broken sysreg timers), FVP (FEAT_ECV, CNT*CTSS_EL0).
"
Link: https://lore.kernel.org/r/20211017124225.3018098-1-maz@kernel.org
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
This memory frequency calculated is only used to check if it is zero,
what is not useful as it will never actually be zero.
Also the calculation is wrong, we should be checking other bit to
select the appropriate frequency multiplier while this code is stuck
with a fixed multiplier.
So here dropping it as whole.
v2:
- Also remove memory frequency calculation for gen9 LP platforms
Cc: Yakui Zhao <yakui.zhao@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Fixes: 5d0c938ec9 ("drm/i915/gen11+: Only load DRAM information from pcode")
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211013010046.91858-1-jose.souza@intel.com
(cherry picked from commit 83f52364b1)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
In the counter subsystem, we are already using sysfs_emit(), but there
were a few places where we were still using sprintf() in *_show()
functions. For consistency and added protections, use sysfs_emit()
everywhere.
Suggested-by: Greg KH <gregkh@linuxfoundation.org>
Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: David Lechner <david@lechnology.com>
Link: https://lore.kernel.org/r/20211017190106.3472645-1-david@lechnology.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When endpoint_alloc() return failed in xillyusb_setup_base_eps(),
'xdev->msg_ep' will be freed but not set to NULL. That lets program
enter fail handling to cleanup_dev() in xillyusb_probe(). Check for
'xdev->msg_ep' is invalid in cleanup_dev() because 'xdev->msg_ep' did
not set to NULL when was freed. So the UAF problem for 'xdev->msg_ep'
is triggered.
==================================================================
BUG: KASAN: use-after-free in fifo_mem_release+0x1f4/0x210
CPU: 0 PID: 166 Comm: kworker/0:2 Not tainted 5.15.0-rc5+ #19
Call Trace:
dump_stack_lvl+0xe2/0x152
print_address_description.constprop.0+0x21/0x140
? fifo_mem_release+0x1f4/0x210
kasan_report.cold+0x7f/0x11b
? xillyusb_probe+0x530/0x700
? fifo_mem_release+0x1f4/0x210
fifo_mem_release+0x1f4/0x210
? __sanitizer_cov_trace_pc+0x1d/0x50
endpoint_dealloc+0x35/0x2b0
cleanup_dev+0x90/0x120
xillyusb_probe+0x59a/0x700
...
Freed by task 166:
kasan_save_stack+0x1b/0x40
kasan_set_track+0x1c/0x30
kasan_set_free_info+0x20/0x30
__kasan_slab_free+0x109/0x140
kfree+0x117/0x4c0
xillyusb_probe+0x606/0x700
Set 'xdev->msg_ep' to NULL after being freed in xillyusb_setup_base_eps()
to fix the UAF problem.
Fixes: a53d1202ae ("char: xillybus: Add driver for XillyUSB (Xillybus variant for USB)")
Cc: stable <stable@vger.kernel.org>
Acked-by: Eli Billauer <eli.billauer@gmail.com>
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
Link: https://lore.kernel.org/r/20211016052047.1611983-1-william.xuanziyang@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When freeing txn buffers, binder_transaction_buffer_release()
attempts to detect whether the current context is the target by
comparing current->group_leader to proc->tsk. This is an unreliable
test. Instead explicitly pass an 'is_failure' boolean.
Detecting the sender was being used as a way to tell if the
transaction failed to be sent. When cleaning up after
failing to send a transaction, there is no need to close
the fds associated with a BINDER_TYPE_FDA object. Now
'is_failure' can be used to accurately detect this case.
Fixes: 44d8047f1d ("binder: use standard functions to allocate fds")
Cc: stable <stable@vger.kernel.org>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Todd Kjos <tkjos@google.com>
Link: https://lore.kernel.org/r/20211015233811.3532235-1-tkjos@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
- Add a new uAPI (under the memory ioctl) to request from the driver
to export a DMA-BUF object that represents a memory region on
the device's DRAM. This is needed to enable peer-to-peer over PCIe
between habana device and an RDMA adapter (e.g. mlnx5 or efa
rdma adapter).
- Add debugfs node to dynamically configure CS timeout. Up until now,
it was only configurable through kernel module parameter.
- Fetch more comprehensive power information from the firmware.
- Always take timestamp when waiting for user interrupt, as the user
needs that information to optimize the graph runtime compilation.
- Modify user interrupt to look on 64-bit user value as fence, instead
of 32-bit.
- Bypass reset in case of repeated h/w error event after device reset.
This is to prevent endless loop of resets to the device.
- Fix several bugs in multi CS completion code.
- Fix race condition in fd close/open.
- Update to latest firmware headers
- Add select CRC32 in kconfig
- Small fixes, cosmetics
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE7TEboABC71LctBLFZR1NuKta54AFAmFtPa4ACgkQZR1NuKta
54A9NAf/QJOc72XhqinNm62RvUoZQehNyDFHcYYBORqIpC+/NsggWwy0VdrDHSeg
uXmt6qwRUCc1+tOjOcFD/b6pnwz16mEqQrmVO8XiZOiCvIGcDEapq0HqGfEXwYtv
NcQ+k682qqXlza6SCZS9/webJzRuhHwxdFP9HTEYLhKmHoOgBza63F6dreku/fEG
mCDVtnMbo8Sa98657Jz3yTElhA+JPsDYO6PycZUTGdPn38mzz5Y5o6Ds8SshIXbr
ZQQxHope7NkqcnfYQ8nIoyl7bPLBv2NaqNz216+sBVVy+kHx6f1+FJ4hJM+PHi20
CuOiUgVBRKp2LJ2k0HoITy5XiXe/Cg==
=bzK+
-----END PGP SIGNATURE-----
Merge tag 'misc-habanalabs-next-2021-10-18' of https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux into char-misc-next
Oded writes:
This tag contains habanalabs driver changes for v5.16:
- Add a new uAPI (under the memory ioctl) to request from the driver
to export a DMA-BUF object that represents a memory region on
the device's DRAM. This is needed to enable peer-to-peer over PCIe
between habana device and an RDMA adapter (e.g. mlnx5 or efa
rdma adapter).
- Add debugfs node to dynamically configure CS timeout. Up until now,
it was only configurable through kernel module parameter.
- Fetch more comprehensive power information from the firmware.
- Always take timestamp when waiting for user interrupt, as the user
needs that information to optimize the graph runtime compilation.
- Modify user interrupt to look on 64-bit user value as fence, instead
of 32-bit.
- Bypass reset in case of repeated h/w error event after device reset.
This is to prevent endless loop of resets to the device.
- Fix several bugs in multi CS completion code.
- Fix race condition in fd close/open.
- Update to latest firmware headers
- Add select CRC32 in kconfig
- Small fixes, cosmetics
* tag 'misc-habanalabs-next-2021-10-18' of https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/linux: (25 commits)
habanalabs: refactor fence handling in hl_cs_poll_fences
habanalabs: context cleanup cosmetics
habanalabs: simplify wait for interrupt with timestamp flow
habanalabs: initialize hpriv fields before adding new node
habanalabs: Unify frequency set/get functionality
habanalabs: select CRC32
habanalabs: add support for dma-buf exporter
habanalabs: define uAPI to export FD for DMA-BUF
habanalabs: fix NULL pointer dereference
habanalabs: fix race condition in multi CS completion
habanalabs: use only u32
habanalabs: update firmware files
habanalabs: bypass reset for continuous h/w error event
habanalabs: take timestamp on wait for interrupt
habanalabs: prevent race between fd close/open
habanalabs: refactor reset log message
habanalabs: define soft-reset as inference op
habanalabs: fix debugfs device memory MMU VA translation
habanalabs: add support for a long interrupt target value
habanalabs: remove redundant cs validity checks
...
Currently, we check the wb_err too early for directories, before all of
the unsafe child requests have been waited on. In order to fix that we
need to check the mapping->wb_err later nearer to the end of ceph_fsync.
We also have an overly-complex method for tracking errors after
blocklisting. The errors recorded in cleanup_session_requests go to a
completely separate field in the inode, but we end up reporting them the
same way we would for any other error (in fsync).
There's no real benefit to tracking these errors in two different
places, since the only reporting mechanism for them is in fsync, and
we'd need to advance them both every time.
Given that, we can just remove i_meta_err, and convert the places that
used it to instead just use mapping->wb_err instead. That also fixes
the original problem by ensuring that we do a check_and_advance of the
wb_err at the end of the fsync op.
Cc: stable@vger.kernel.org
URL: https://tracker.ceph.com/issues/52864
Reported-by: Patrick Donnelly <pdonnell@redhat.com>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Xiubo Li <xiubli@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Currently when mounting, we may end up finding an existing superblock
that corresponds to a blocklisted MDS client. This means that the new
mount ends up being unusable.
If we've found an existing superblock with a client that is already
blocklisted, and the client is not configured to recover on its own,
fail the match. Ditto if the superblock has been forcibly unmounted.
While we're in here, also rename "other" to the more conventional "fsc".
Cc: stable@vger.kernel.org
URL: https://bugzilla.redhat.com/show_bug.cgi?id=1901499
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Remove the redundant first 'if' statement of two identical ones.
In rtw_cmd_thread() there are two identical 'if' statement, one
immediately after the other. They check whether or not the device is
removed or the driver is stopped and, if true, they break a 'while'
loop.
The only noteworthy context difference is that the second statement is
within a block labelled "_next". The code has a 'goto' to the "_next"
label so that the checking is performed each time the above directive
is encountered. Instead, the first 'if' is before the "_next" label.
One of the two must be removed and that it must be the one before the
label because "bSurpriseRemoved" as well as "bDriverStopped" may be
changed asynchronously by other code of the driver and so they should be
checked at each jump to "_next".
Tested with "ASUSTek Computer, Inc. Realtek 8188EUS [USB-N10 Nano]".
Acked-by: Martin Kaiser <martin@kaiser.cx>
Acked-by: Phillip Potter <phil@philpotter.co.uk>
Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
Link: https://lore.kernel.org/r/20211018162006.5527-4-fmdefrancesco@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rtw_enqueue_cmd() uses a semaphore to notify rtw_cmd_thread() that it
has enqueued commands. rtw_cmd_thread() "down(s)" in interruptible mode
to wait to be notified.
Use completion variables because they are better suited for the purpose.
In rtw_cmd_thread(), wait in uninterruptible mode, even if the original
code uses down_interruptible(), because the interruption of
rtw_cmd_thread() is not allowed and unwanted.
Tested with "ASUSTek Computer, Inc. Realtek 8188EUS [USB-N10 Nano]".
Acked-by: Phillip Potter <phil@philpotter.co.uk>
Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
Link: https://lore.kernel.org/r/20211018162006.5527-3-fmdefrancesco@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rtw_cmd_thread() "up(s)" a semaphore twice, first to notify callers when
its execution is started and then to notify when it is about to end.
It makes the same semaphore go "up" twice in the same thread. This
construct makes Smatch to warn of duplicate "up(s)".
This thread uses interruptible semaphores where instead completions are
more suitable. For this purpose it calls an helper (_rtw_down_sema())
that returns values that are never checked. It may lead to bugs.
To address the above-mentioned issues, use two completions variables
instead of semaphores. Use the uninterruptible versions of
wake_for_completion*() because the interruptible / killable versions are
not necessary.
Tested with "ASUSTek Computer, Inc. Realtek 8188EUS [USB-N10 Nano]".
Acked-by: Phillip Potter <phil@philpotter.co.uk>
Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
Link: https://lore.kernel.org/r/20211018162006.5527-2-fmdefrancesco@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Replace strncpy with strlcpy to fix the following gcc warning.
drivers/staging/r8188eu/os_dep/ioctl_linux.c: In function 'rtw_wx_set_enc_ext':
drivers/staging/r8188eu/os_dep/ioctl_linux.c:1929:9: warning: 'strncpy' specified bound 16 equals destination size [-Wstringop-truncation]
1929 | strncpy((char *)param->u.crypt.alg, alg_name, IEEE_CRYPT_ALG_NAME_LEN);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The destination buffer size is IEEE_CRYPT_ALG_NAME_LEN and the length
of the string to copy is always < IEEE_CRYPT_ALG_NAME_LEN. So strlcpy
will never truncate the string.
Acked-by: Phillip Potter <phil@philpotter.co.uk>
Signed-off-by: Michael Straube <straube.linux@gmail.com>
Link: https://lore.kernel.org/r/20211018221231.7837-1-straube.linux@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nodes for 'i2s' and 'nand' have no driver present inside the linux tree.
The normal approach for a dts file to be mainlined is start with those stuff
which is already mainlined and get rid of the other stuff. If needed it will
be properly added afterwards together with the suitable device driver. Hence,
remove both nodes from the device tree include file.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20211018170206.11959-1-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Without CONFIG_PM_SLEEP, the runtime suspend/resume functions
are unused, producing a warning:
drivers/iio/adc/imx8qxp-adc.c:433:12: error: 'imx8qxp_adc_runtime_resume' defined but not used [-Werror=unused-function]
433 | static int imx8qxp_adc_runtime_resume(struct device *dev)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/iio/adc/imx8qxp-adc.c:419:12: error: 'imx8qxp_adc_runtime_suspend' defined but not used [-Werror=unused-function]
419 | static int imx8qxp_adc_runtime_suspend(struct device *dev)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
Mark them as __maybe_unused to shut up the compiler.
Fixes: 1e23dcaa1a ("iio: imx8qxp-adc: Add driver support for NXP IMX8QXP ADC")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Cai Huoqing <caihuoqing@baidu.com>
Link: https://lore.kernel.org/r/20211013144338.2261316-1-arnd@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Up to now ms5611_remove() returns zero unconditionally. Make it return
void instead which makes it easier to see in the callers that there is
no error to handle.
Also the return value of i2c and spi remove callbacks is ignored anyway.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20211013203223.2694577-16-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The only effect of returning an error in an spi .remove() callback is
that the spi core issues a generic warning message. Instead emit a more
specific error message and return 0 to not report the same issue twice.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20211013203223.2694577-15-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Up to now hmc5843_common_remove() returns zero unconditionally. Make it
return void instead which makes it easier to see in the callers that
there is no error to handle.
Also the return value of i2c and spi remove callbacks is ignored anyway.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20211013203223.2694577-14-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The only effect of returning an error in an spi .remove() callback is
that the spi core issues another warning message. Don't report the same
problem twice and return 0 unconditionally instead. Also degrade the log
level to warning, as nothing really bad is expected from a failure to
put the device in suspend mode.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20211013203223.2694577-12-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Up to now ad5686_remove() returns zero unconditionally. Make it return
void instead which makes it easier to see in the callers that there is
no error to handle.
Also the return value of i2c and spi remove callbacks is ignored anyway.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20211013203223.2694577-11-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Up to now ad5592r_remove() returns zero unconditionally. Make it return
void instead which makes it easier to see in the callers that there is
no error to handle.
Also the return value of i2c and spi remove callbacks is ignored anyway.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20211013203223.2694577-10-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Up to now ad5446_remove() returns zero unconditionally. Make it return
void instead which makes it easier to see in the callers that there is
no error to handle.
Also the return value of i2c and spi remove callbacks is ignored anyway.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20211013203223.2694577-9-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Up to now ad5380_remove() returns zero unconditionally. Make it return
void instead which makes it easier to see in the callers that there is
no error to handle.
Also the return value of i2c and spi remove callbacks is ignored anyway.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20211013203223.2694577-8-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Up to now mma7455_core_remove() returns zero unconditionally. Make it
return void instead which makes it easier to see in the callers that
there is no error to handle.
Also the return value of i2c and spi remove callbacks is ignored anyway.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20211013203223.2694577-6-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Up to now kxsd9_common_remove() returns zero unconditionally. Make it
return void instead which makes it easier to see in the callers that
there is no error to handle.
Also the return value of i2c and spi remove callbacks is ignored anyway.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20211013203223.2694577-5-u.kleine-koenig@pengutronix.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
