summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-02-13clocksource/drivers/timer-microchip-pit64b: Add delay timerClaudiu Beznea
Add delay timer. Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/20230203130537.1921608-3-claudiu.beznea@microchip.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2023-02-13clocksource/drivers/timer-microchip-pit64b: Select driver only on ARMClaudiu Beznea
Microchip PIT64B is currently available on ARM based devices. Thus select it only for ARM. This allows implementing delay timer. Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/20230203130537.1921608-2-claudiu.beznea@microchip.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2023-02-13dt-bindings: timer: sifive,clint: add comaptibles for T-Head's C9xxIcenowy Zheng
T-Head C906/C910 CLINT is not compliant to SiFive ones (and even not compliant to the newcoming ACLINT spec) because of lack of mtime register. Add a compatible string formatted like the C9xx-specific PLIC compatible, and do not allow a SiFive one as fallback because they're not really compliant. Signed-off-by: Icenowy Zheng <uwu@icenowy.me> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Samuel Holland <samuel@sholland.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230202072814.319903-1-uwu@icenowy.me Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2023-02-13dt-bindings: timer: mediatek,mtk-timer: add MT8365Bernhard Rosenkränzer
Add binding description for mediatek,mt8365-systimer Signed-off-by: Bernhard Rosenkränzer <bero@baylibre.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230125143503.1015424-8-bero@baylibre.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2023-02-13clocksource/drivers/riscv: Get rid of clocksource_arch_init() callbackLad Prabhakar
Having a clocksource_arch_init() callback always sets vdso_clock_mode to VDSO_CLOCKMODE_ARCHTIMER if GENERIC_GETTIMEOFDAY is enabled, this is required for the riscv-timer. This works for platforms where just riscv-timer clocksource is present. On platforms where other clock sources are available we want them to register with vdso_clock_mode set to VDSO_CLOCKMODE_NONE. On the Renesas RZ/Five SoC OSTM block can be used as clocksource [0], to avoid multiple clock sources being registered as VDSO_CLOCKMODE_ARCHTIMER move setting of vdso_clock_mode in the riscv-timer driver instead of doing this in clocksource_arch_init() callback as done similarly for ARM/64 architecture. [0] drivers/clocksource/renesas-ostm.c Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Tested-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Samuel Holland <samuel@sholland.org> Link: https://lore.kernel.org/r/20221229224601.103851-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2023-02-13clocksource/drivers/sh_cmt: Mark driver as non-removableUwe Kleine-König
The comment in the remove callback suggests that the driver is not supposed to be unbound. However returning an error code in the remove callback doesn't accomplish that. Instead set the suppress_bind_attrs property (which makes it impossible to unbind the driver via sysfs). The only remaining way to unbind a sh_cmt device would be module unloading, but that doesn't apply here, as the driver cannot be built as a module. Also drop the useless remove callback. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230123220221.48164-1-u.kleine-koenig@pengutronix.de Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2023-02-13clocksource/drivers/timer-microchip-pit64b: Drop obsolete dependency on ↵Jean Delvare
COMPILE_TEST Since commit 0166dc11be91 ("of: make CONFIG_OF user selectable"), it is possible to test-build any driver which depends on OF on any architecture by explicitly selecting OF. Therefore depending on COMPILE_TEST as an alternative is no longer needed. Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Claudiu Beznea <claudiu.beznea@microchip.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/20230121182911.4e47a5ff@endymion.delvare Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2023-02-13clocksource/drivers/riscv: Increase the clock source ratingSamuel Holland
RISC-V provides an architectural clock source via the time CSR. This clock source exposes a 64-bit counter synchronized across all CPUs. Because it is accessed using a CSR, it is much more efficient to read than MMIO clock sources. For example, on the Allwinner D1, reading the sun4i timer in a loop takes 131 cycles/iteration, while reading the RISC-V time CSR takes only 5 cycles/iteration. Adjust the RISC-V clock source rating so it is preferred over the various platform-specific MMIO clock sources. Signed-off-by: Samuel Holland <samuel@sholland.org> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> Reviewed-by: Anup Patel <anup@brainfault.org> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20221228004444.61568-1-samuel@sholland.org Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org>
2023-02-13clocksource/drivers/timer-riscv: Set CLOCK_EVT_FEAT_C3STOP based on DTAnup Patel
We should set CLOCK_EVT_FEAT_C3STOP for a clock_event_device only when riscv,timer-cannot-wake-cpu DT property is present in the RISC-V timer DT node. This way CLOCK_EVT_FEAT_C3STOP feature is set for clock_event_device based on RISC-V platform capabilities rather than having it set for all RISC-V platforms. Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Link: https://lore.kernel.org/r/20230103141102.772228-4-apatel@ventanamicro.com Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org>
2023-02-13dt-bindings: timer: Add bindings for the RISC-V timer deviceAnup Patel
We add DT bindings for a separate RISC-V timer DT node which can be used to describe implementation specific behaviour (such as timer interrupt not triggered during non-retentive suspend). Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Link: https://lore.kernel.org/r/20230103141102.772228-3-apatel@ventanamicro.com Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org>
2023-02-13RISC-V: time: initialize hrtimer based broadcast clock event deviceConor Dooley
Similarly to commit 022eb8ae8b5e ("ARM: 8938/1: kernel: initialize broadcast hrtimer based clock event device"), RISC-V needs to initiate hrtimer based broadcast clock event device before C3STOP can be used. Otherwise, the introduction of C3STOP for the RISC-V arch timer in commit 232ccac1bd9b ("clocksource/drivers/riscv: Events are stopped during CPU suspend") leaves us without any broadcast timer registered. This prevents the kernel from entering oneshot mode, which breaks timer behaviour, for example clock_nanosleep(). A test app that sleeps each cpu for 6, 5, 4, 3 ms respectively, HZ=250 & C3STOP enabled, the sleep times are rounded up to the next jiffy: == CPU: 1 == == CPU: 2 == == CPU: 3 == == CPU: 4 == Mean: 7.974992 Mean: 7.976534 Mean: 7.962591 Mean: 3.952179 Std Dev: 0.154374 Std Dev: 0.156082 Std Dev: 0.171018 Std Dev: 0.076193 Hi: 9.472000 Hi: 10.495000 Hi: 8.864000 Hi: 4.736000 Lo: 6.087000 Lo: 6.380000 Lo: 4.872000 Lo: 3.403000 Samples: 521 Samples: 521 Samples: 521 Samples: 521 Link: https://lore.kernel.org/linux-riscv/YzYTNQRxLr7Q9JR0@spud/ Fixes: 232ccac1bd9b ("clocksource/drivers/riscv: Events are stopped during CPU suspend") Suggested-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Samuel Holland <samuel@sholland.org> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Link: https://lore.kernel.org/r/20230103141102.772228-2-apatel@ventanamicro.com Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org>
2023-02-13dt-bindings: timer: rk-timer: Add rktimer for rv1126Jagan Teki
Add rockchip timer compatible string for rockchip rv1126. Signed-off-by: Jagan Teki <jagan@edgeble.ai> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20221123183124.6911-3-jagan@edgeble.ai Signed-off-by: Daniel Lezcano <daniel.lezcano@kernel.org>
2023-02-13PCI/MSI: Provide missing stubs for CONFIG_PCI_MSI=nReinette Chatre
pci_msix_alloc_irq_at() and pci_msix_free_irq() are not declared when CONFIG_PCI_MSI is disabled. Users of these two calls do not yet exist but when users do appear (shown below is an attempt to use the new API in vfio-pci) the following errors will be encountered when compiling with CONFIG_PCI_MSI disabled: drivers/vfio/pci/vfio_pci_intrs.c:461:4: error: implicit declaration of\ function 'pci_msix_free_irq' is invalid in C99\ [-Werror,-Wimplicit-function-declaration] pci_msix_free_irq(pdev, msix_map); ^ drivers/vfio/pci/vfio_pci_intrs.c:511:15: error: implicit declaration of\ function 'pci_msix_alloc_irq_at' is invalid in C99\ [-Werror,-Wimplicit-function-declaration] msix_map = pci_msix_alloc_irq_at(pdev, vector, NULL); Provide definitions for pci_msix_alloc_irq_at() and pci_msix_free_irq() in preparation for users that need to compile when CONFIG_PCI_MSI is disabled. Reported-by: kernel test robot <lkp@intel.com> Fixes: 34026364df8e ("PCI/MSI: Provide post-enable dynamic allocation interfaces for MSI-X") Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/158e40e1cfcfc58ae30ecb2bbfaf86e5bba7a1ef.1675978686.git.reinette.chatre@intel.com
2023-02-13platform/x86: dell-ddv: Prefer asynchronous probingArmin Wolf
During probe, both sensor buffers need to be queried to initialize the hwmon channels. This might be slow on some machines, causing a unnecessary delay during boot. Mark the driver with PROBE_PREFER_ASYNCHRONOUS so that it can be probed asynchronously. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20230209211503.2739-3-W_Armin@gmx.de Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-13platform/x86: dell-ddv: Add hwmon supportArmin Wolf
Thanks to bugreport 216655 on bugzilla triggered by the dell-smm-hwmon driver, the contents of the sensor buffers could be almost completely decoded. Add an hwmon interface for exposing the fan and thermal sensor values. Since the WMI interface can be quite slow on some machines, the sensor buffers are cached for 1 second to lessen the performance impact. The debugfs interface remains in place to aid in reverse-engineering of unknown sensor types and the thermal buffer. Tested-by: Antonín Skala <skala.antonin@gmail.com> Tested-by: Gustavo Walbon <gustavowalbon@gmail.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20230209211503.2739-2-W_Armin@gmx.de Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-13Documentation/ABI: Add new attribute for mlxreg-io sysfs interfacesVadim Pasternak
Add description for new attributes added for rack manager switch and NG800 family systems. Attributes related to power converter board: - reset_pwr_converter_fail; - pwr_converter_prog_en; Attributes related to External Root of Trust (EROT) devices recovery: - erot1_ap_reset; - erot2_ap_reset; - erot1_recovery; - erot2_recovery; - erot1_reset; - erot2_reset; - erot1_wp; - erot2_wp; - spi_chnl_select; Attributes related to clock board failures and recovery: - clk_brd1_boot_fail; - clk_brd2_boot_fail; - clk_brd_fail; - clk_brd_prog_en; Attributes related to power failures: - reset_ac_ok_fail; - asic_pg_fail; Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Michael Shych <michaelsh@nvidia.com> Link: https://lore.kernel.org/r/20230208063331.15560-14-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-13platform: mellanox: mlx-platform: Move bus shift assignment out of the loopVadim Pasternak
Move assignment of bus shift setting out of the loop to avoid redundant operation. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Michael Shych <michaelsh@nvidia.com> Link: https://lore.kernel.org/r/20230208063331.15560-13-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-13platform: mellanox: mlx-platform: Add mux selection register to regmapVadim Pasternak
Extend writeable, readable, volatile registers of the 'regmap' object with for I2C mux selector registers. The motivation is to pass this object extended with selector registers to I2C mux driver working over ‘regmap’. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Michael Shych <michaelsh@nvidia.com> Link: https://lore.kernel.org/r/20230208063331.15560-12-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-13platform_data/mlxreg: Add field with mapped resource addressVadim Pasternak
Add field with PCIe remapped based address for passing it across relevant platform drivers sharing common system resources. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Michael Shych <michaelsh@nvidia.com> Link: https://lore.kernel.org/r/20230208063331.15560-11-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-13platform/mellanox: mlxreg-hotplug: Allow more flexible hotplug events ↵Vadim Pasternak
configuration Currently hotplug configuration in logic device assumes that all items are provided with no holes. Thus, any group of hotplug events, associated with the specific status/event/mask registers is configured in those registers successively from bit zero to bit #n (#n < 8). This logic is changed int order to allow non-successive definition to support configuration with the skipped bits – for example bits 3, 5, 7 in status/event/mask registers can be associated with hotplug events, while others can be skipped. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Michael Shych <michaelsh@nvidia.com> Link: https://lore.kernel.org/r/20230208063331.15560-10-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-13platform: mellanox: Extend all systems with I2C notification callbackVadim Pasternak
Motivation is to provide synchronization between I2C main bus and other platform drivers using this notification callback. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Michael Shych <michaelsh@nvidia.com> Link: https://lore.kernel.org/r/20230208063331.15560-9-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-13platform: mellanox: Split logic in init and exit flowVadim Pasternak
Split logic in mlxplat_init()/mlxplat_exit() routines. Separate initialization of I2C infrastructure and others platform drivers. Motivation is to provide synchronization between I2C bus and mux drivers and other drivers using this infrastructure. I2C main bus and MUX busses are implemented in FPGA logic. On some new systems the numbers allocated for these busses could be variable depending on order of initialization of I2C native busses. Since bus numbers are passed to some other platform drivers during initialization flow, it is necessary to synchronize completion of I2C infrastructure drivers and activation of rest of drivers. Thus initialization flow will be performed in synchronized order. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Michael Shych <michaelsh@nvidia.com> Link: https://lore.kernel.org/r/20230208063331.15560-8-vadimp@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-02-13m68k: /proc/hardware should depend on PROC_FSRandy Dunlap
When CONFIG_PROC_FS is not set, there is a build error for an unused function. Make PROC_HARDWARE depend on PROC_FS to prevent this error. In file included from ../arch/m68k/kernel/setup.c:3: ../arch/m68k/kernel/setup_mm.c:477:12: error: 'hardware_proc_show' defined but not used [-Werror=unused-function] 477 | static int hardware_proc_show(struct seq_file *m, void *v) | ^~~~~~~~~~~~~~~~~~ Fixes: 66d857b08b8c ("m68k: merge m68k and m68knommu arch directories") # v3.0 Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/r/20230209010825.24136-1-rdunlap@infradead.org Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2023-02-13bnxt_en: Fix mqprio and XDP ring checking logicMichael Chan
In bnxt_reserve_rings(), there is logic to check that the number of TX rings reserved is enough to cover all the mqprio TCs, but it fails to account for the TX XDP rings. So the check will always fail if there are mqprio TCs and TX XDP rings. As a result, the driver always fails to initialize after the XDP program is attached and the device will be brought down. A subsequent ifconfig up will also fail because the number of TX rings is set to an inconsistent number. Fix the check to properly account for TX XDP rings. If the check fails, set the number of TX rings back to a consistent number after calling netdev_reset_tc(). Fixes: 674f50a5b026 ("bnxt_en: Implement new method to reserve rings.") Reviewed-by: Hongguang Gao <hongguang.gao@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-02-13net: Fix unwanted sign extension in netdev_stats_to_stats64()Felix Riemann
When converting net_device_stats to rtnl_link_stats64 sign extension is triggered on ILP32 machines as 6c1c509778 changed the previous "ulong -> u64" conversion to "long -> u64" by accessing the net_device_stats fields through a (signed) atomic_long_t. This causes for example the received bytes counter to jump to 16EiB after having received 2^31 bytes. Casting the atomic value to "unsigned long" beforehand converting it into u64 avoids this. Fixes: 6c1c5097781f ("net: add atomic_long_t to net_device_stats fields") Signed-off-by: Felix Riemann <felix.riemann@sma.de> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-02-13net/usb: kalmia: Don't pass act_len in usb_bulk_msg error pathMiko Larsson
syzbot reported that act_len in kalmia_send_init_packet() is uninitialized when passing it to the first usb_bulk_msg error path. Jiri Pirko noted that it's pointless to pass it in the error path, and that the value that would be printed in the second error path would be the value of act_len from the first call to usb_bulk_msg.[1] With this in mind, let's just not pass act_len to the usb_bulk_msg error paths. 1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/ Fixes: d40261236e8e ("net/usb: Add Samsung Kalmia driver for Samsung GT-B3730") Reported-and-tested-by: syzbot+cd80c5ef5121bfe85b55@syzkaller.appspotmail.com Signed-off-by: Miko Larsson <mikoxyzzz@gmail.com> Reviewed-by: Alexander Duyck <alexanderduyck@fb.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-02-13net: openvswitch: fix possible memory leak in ovs_meter_cmd_set()Hangyu Hua
old_meter needs to be free after it is detached regardless of whether the new meter is successfully attached. Fixes: c7c4c44c9a95 ("net: openvswitch: expand the meters supported number") Signed-off-by: Hangyu Hua <hbh25y@gmail.com> Acked-by: Eelco Chaudron <echaudro@redhat.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-02-13af_key: Fix heap information leakHyunwoo Kim
Since x->encap of pfkey_msg2xfrm_state() is not initialized to 0, kernel heap data can be leaked. Fix with kzalloc() to prevent this. Signed-off-by: Hyunwoo Kim <v4bel@theori.io> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-02-13xen: Replace one-element array with flexible-array memberGustavo A. R. Silva
One-element arrays are deprecated, and we are replacing them with flexible array members instead. So, replace one-element array with flexible-array member in struct xen_page_directory. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [1]. This results in no differences in binary output. Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/255 Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1] Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/Y9xjN6Wa3VslgXeX@work Signed-off-by: Juergen Gross <jgross@suse.com>
2023-02-13tpm: add vendor flag to command code validationJulien Gomes
Some TPM 2.0 devices have support for additional commands which are not part of the TPM 2.0 specifications. These commands are identified with bit 29 of the 32 bits command codes. Contrarily to other fields of the TPMA_CC spec structure used to list available commands, the Vendor flag also has to be present in the command code itself (TPM_CC) when called. Add this flag to tpm_find_cc() mask to prevent blocking vendor command codes that can actually be supported by the underlying TPM device. Signed-off-by: Julien Gomes <julien@arista.com> Tested-by: Jarkko Sakkinen <jarkko@kernel.org> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-02-13tpm: Add reserved memory event logEddie James
Some platforms may desire to pass the event log up to Linux in the form of a reserved memory region. In particular, this is desirable for embedded systems or baseboard management controllers (BMCs) booting with U-Boot. IBM OpenBMC BMCs will be the first user. Add support for the reserved memory in the TPM core to find the region and map it. Signed-off-by: Eddie James <eajames@linux.ibm.com> [jarkko: removed spurious dev_info()'s from tpm_read_log_memory_region()] Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> [yang: return -ENOMEM when devm_memremap() fails] Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-02-13tpm: Use managed allocation for bios event logEddie James
Since the bios event log is freed in the device release function, let devres handle the deallocation. This will allow other memory allocation/mapping functions to be used for the bios event log. Signed-off-by: Eddie James <eajames@linux.ibm.com> Tested-by: Jarkko Sakkinen <jarkko@kernel.org> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-02-13tpm: tis_i2c: Convert to i2c's .probe_new()Uwe Kleine-König
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-02-13tpm: tpm_i2c_nuvoton: Convert to i2c's .probe_new()Uwe Kleine-König
.probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-02-13tpm: tpm_i2c_infineon: Convert to i2c's .probe_new()Uwe Kleine-König
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-02-13tpm: tpm_i2c_atmel: Convert to i2c's .probe_new()Uwe Kleine-König
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-02-13tpm: st33zp24: Convert to i2c's .probe_new()Uwe Kleine-König
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-02-13KEYS: asymmetric: Fix ECDSA use via keyctl uapiDenis Kenzior
When support for ECDSA keys was added, constraints for data & signature sizes were never updated. This makes it impossible to use such keys via keyctl API from userspace. Update constraint on max_data_size to 64 bytes in order to support SHA512-based signatures. Also update the signature length constraints per ECDSA signature encoding described in RFC 5480. Fixes: 299f561a6693 ("x509: Add support for parsing x509 certs with ECDSA keys") Signed-off-by: Denis Kenzior <denkenz@gmail.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-02-13certs: don't try to update blacklist keysThomas Weißschuh
When the same key is blacklisted repeatedly logging at pr_err() level is excessive as no functionality is impaired. When these duplicates are provided by buggy firmware there is nothing the user can do to fix the situation. Instead of spamming the bootlog with errors we use a warning that can still be seen by OEMs when testing their firmware. Link: https://lore.kernel.org/all/c8c65713-5cda-43ad-8018-20f2e32e4432@t-8ch.de/ Link: https://lore.kernel.org/all/20221104014704.3469-1-linux@weissschuh.net/ Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-02-13KEYS: Add new function key_create()Thomas Weißschuh
key_create() works like key_create_or_update() but does not allow updating an existing key, instead returning ERR_PTR(-EEXIST). key_create() will be used by the blacklist keyring which should not create duplicate entries or update existing entries. Instead a dedicated message with appropriate severity will be logged. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-02-13certs: make blacklisted hash available in klogThomas Weißschuh
One common situation triggering this log statement are duplicate hashes reported by the system firmware. These duplicates should be removed from the firmware. Without logging the blacklisted hash triggering the issue however the users can not report it properly to the firmware vendors and the firmware vendors can not easily see which specific hash is duplicated. While changing the log message also use the dedicated ERR_PTR format placeholder for the returned error value. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-02-13tpm_crb: Add support for CRB devices based on PlutonMatthew Garrett
Pluton is an integrated security processor present in some recent Ryzen parts. If it's enabled, it presents two devices - an MSFT0101 ACPI device that's broadly an implementation of a Command Response Buffer TPM2, and an MSFT0200 ACPI device whose functionality I haven't examined in detail yet. This patch only attempts to add support for the TPM device. There's a few things that need to be handled here. The first is that the TPM2 ACPI table uses a previously undefined start method identifier. The table format appears to include 16 bytes of startup data, which corresponds to one 64-bit address for a start message and one 64-bit address for a completion response. The second is that the ACPI tables on the Thinkpad Z13 I'm testing this on don't define any memory windows in _CRS (or, more accurately, there are two empty memory windows). This check doesn't seem strictly necessary, so I've skipped that. Finally, it seems like chip needs to be explicitly asked to transition into ready status on every command. Failing to do this means that if two commands are sent in succession without an idle/ready transition in between, everything will appear to work fine but the response is simply the original command. I'm working without any docs here, so I'm not sure if this is actually the required behaviour or if I'm missing something somewhere else, but doing this results in the chip working reliably. Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-02-13ALSA: hda/realtek - fixed wrong gpio assignedKailang Yang
GPIO2 PIN use for output. Mask Dir and Data need to assign for 0x4. Not 0x3. This fixed was for Lenovo Desktop(0x17aa1056). GPIO2 use for AMP enable. Signed-off-by: Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/8d02bb9ac8134f878cd08607fdf088fd@realtek.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2023-02-13crypto: certs: fix FIPS selftest dependencyArnd Bergmann
The selftest code is built into the x509_key_parser module, and depends on the pkcs7_message_parser module, which in turn has a dependency on the key parser, creating a dependency loop and a resulting link failure when the pkcs7 code is a loadable module: ld: crypto/asymmetric_keys/selftest.o: in function `fips_signature_selftest': crypto/asymmetric_keys/selftest.c:205: undefined reference to `pkcs7_parse_message' ld: crypto/asymmetric_keys/selftest.c:209: undefined reference to `pkcs7_supply_detached_data' ld: crypto/asymmetric_keys/selftest.c:211: undefined reference to `pkcs7_verify' ld: crypto/asymmetric_keys/selftest.c:215: undefined reference to `pkcs7_validate_trust' ld: crypto/asymmetric_keys/selftest.c:219: undefined reference to `pkcs7_free_message' Avoid this by only allowing the selftest to be enabled when either both parts are loadable modules, or both are built-in. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-02-13xen/grant-dma-iommu: Implement a dummy probe_device() callbackOleksandr Tyshchenko
Update stub IOMMU driver (which main purpose is to reuse generic IOMMU device-tree bindings by Xen grant DMA-mapping layer on Arm) according to the recent changes done in the following commit 57365a04c921 ("iommu: Move bus setup to IOMMU device registration"). With probe_device() callback being called during IOMMU device registration, the uninitialized callback just leads to the "kernel NULL pointer dereference" issue during boot. Fix that by adding a dummy callback. Looks like the release_device() callback is not mandatory to be implemented as IOMMU framework makes sure that callback is initialized before dereferencing. Reported-by: Viresh Kumar <viresh.kumar@linaro.org> Fixes: 57365a04c921 ("iommu: Move bus setup to IOMMU device registration") Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com> Tested-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Link: https://lore.kernel.org/r/20230208153649.3604857-1-olekstysh@gmail.com Signed-off-by: Juergen Gross <jgross@suse.com>
2023-02-13nvme-pci: add bogus ID quirk for ADATA SX6000PNPDaniel Wagner
Yet another device which needs a quirk: nvme nvme1: globally duplicate IDs for nsid 1 nvme nvme1: VID:DID 10ec:5763 model:ADATA SX6000PNP firmware:V9002s94 Link: http://bugzilla.opensuse.org/show_bug.cgi?id=1207827 Reported-by: Gustavo Freitas <freitasmgustavo@gmail.com> Signed-off-by: Daniel Wagner <dwagner@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de>
2023-02-13xen/pvcalls-back: fix permanently masked event channelVolodymyr Babchuk
There is a sequence of events that can lead to a permanently masked event channel, because xen_irq_lateeoi() is newer called. This happens when a backend receives spurious write event from a frontend. In this case pvcalls_conn_back_write() returns early and it does not clears the map->write counter. As map->write > 0, pvcalls_back_ioworker() returns without calling xen_irq_lateeoi(). This leaves the event channel in masked state, a backend does not receive any new events from a frontend and the whole communication stops. Move atomic_set(&map->write, 0) to the very beginning of pvcalls_conn_back_write() to fix this issue. Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> Reported-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20230119211037.1234931-1-volodymyr_babchuk@epam.com Signed-off-by: Juergen Gross <jgross@suse.com>
2023-02-13xen: Allow platform PCI interrupt to be sharedDavid Woodhouse
When we don't use the per-CPU vector callback, we ask Xen to deliver event channel interrupts as INTx on the PCI platform device. As such, it can be shared with INTx on other PCI devices. Set IRQF_SHARED, and make it return IRQ_HANDLED or IRQ_NONE according to whether the evtchn_upcall_pending flag was actually set. Now I can share the interrupt: 11: 82 0 IO-APIC 11-fasteoi xen-platform-pci, ens4 Drop the IRQF_TRIGGER_RISING. It has no effect when the IRQ is shared, and besides, the only effect it was having even beforehand was to trigger a debug message in both I/OAPIC and legacy PIC cases: [ 0.915441] genirq: No set_type function for IRQ 11 (IO-APIC) [ 0.951939] genirq: No set_type function for IRQ 11 (XT-PIC) Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/f9a29a68d05668a3636dd09acd94d970269eaec6.camel@infradead.org Signed-off-by: Juergen Gross <jgross@suse.com>
2023-02-13x86/xen/time: prefer tsc as clocksource when it is invariantKrister Johansen
Kvm elects to use tsc instead of kvm-clock when it can detect that the TSC is invariant. (As of commit 7539b174aef4 ("x86: kvmguest: use TSC clocksource if invariant TSC is exposed")). Notable cloud vendors[1] and performance engineers[2] recommend that Xen users preferentially select tsc over xen-clocksource due the performance penalty incurred by the latter. These articles are persuasive and tailored to specific use cases. In order to understand the tradeoffs around this choice more fully, this author had to reference the documented[3] complexities around the Xen configuration, as well as the kernel's clocksource selection algorithm. Many users may not attempt this to correctly configure the right clock source in their guest. The approach taken in the kvm-clock module spares users this confusion, where possible. Both the Intel SDM[4] and the Xen tsc documentation explain that marking a tsc as invariant means that it should be considered stable by the OS and is elibile to be used as a wall clock source. In order to obtain better out-of-the-box performance, and reduce the need for user tuning, follow kvm's approach and decrease the xen clock rating so that tsc is preferable, if it is invariant, stable, and the tsc will never be emulated. [1] https://aws.amazon.com/premiumsupport/knowledge-center/manage-ec2-linux-clock-source/ [2] https://www.brendangregg.com/blog/2021-09-26/the-speed-of-time.html [3] https://xenbits.xen.org/docs/unstable/man/xen-tscmode.7.html [4] Intel 64 and IA-32 Architectures Sofware Developer's Manual Volume 3b: System Programming Guide, Part 2, Section 17.17.1, Invariant TSC Signed-off-by: Krister Johansen <kjlx@templeofstupid.com> Code-reviewed-by: David Reaver <me@davidreaver.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20221216162118.GB2633@templeofstupid.com Signed-off-by: Juergen Gross <jgross@suse.com>
2023-02-13x86/xen: mark xen_pv_play_dead() as __noreturnJuergen Gross
Mark xen_pv_play_dead() and related to that xen_cpu_bringup_again() as "__noreturn". Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20221125063248.30256-3-jgross@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
generated by cgit (git 2.34.1) at 2025-09-11 17:00:24 +0000