summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-05-16can: isotp: isotp_bind(): return -EINVAL on incorrect CAN ID formattingOliver Hartkopp
Commit 3ea566422cbd ("can: isotp: sanitize CAN ID checks in isotp_bind()") checks the given CAN ID address information by sanitizing the input values. This check (silently) removes obsolete bits by masking the given CAN IDs. Derek Will suggested to give a feedback to the application programmer when the 'sanitizing' was actually needed which means the programmer provided CAN ID content in a wrong format (e.g. SFF CAN IDs with a CAN ID > 0x7FF). Link: https://lore.kernel.org/all/20220515181633.76671-1-socketcan@hartkopp.net Suggested-by: Derek Will <derekrobertwill@gmail.com> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-05-16can: isotp: add support for transmission without flow controlOliver Hartkopp
Usually the ISO 15765-2 protocol is a point-to-point protocol to transfer segmented PDUs to a dedicated receiver. This receiver sends a flow control message to specify protocol options and timings (e.g. block size / STmin). The so called functional addressing communication allows a 1:N communication but is limited to a single frame length. This new CAN_ISOTP_CF_BROADCAST allows an unconfirmed 1:N communication with PDU length that would not fit into a single frame. This feature is not covered by the ISO 15765-2 standard. Link: https://lore.kernel.org/all/20220507115558.19065-1-socketcan@hartkopp.net Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-05-16can: raw: add support for SO_TXTIME/SCM_TXTIMEMarc Kleine-Budde
This patch calls into sock_cmsg_send() to parse the user supplied control information into a struct sockcm_cookie. Then assign the requested transmit time to the skb. This makes it possible to use the Earliest TXTIME First (ETF) packet scheduler with the CAN_RAW protocol. The user can send a CAN_RAW frame with a TXTIME and the kernel (with the ETF scheduler) will take care of sending it to the network interface. Link: https://lore.kernel.org/all/20220502091946.1916211-3-mkl@pengutronix.de Acked-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-05-16can: raw: raw_sendmsg(): remove not needed setting of skb->skMarc Kleine-Budde
The skb in raw_sendmsg() is allocated with sock_alloc_send_skb(), which subsequently calls sock_alloc_send_pskb() -> skb_set_owner_w(), which assigns "skb->sk = sk". This patch removes the not needed setting of skb->sk. Link: https://lore.kernel.org/all/20220502091946.1916211-2-mkl@pengutronix.de Acked-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-05-16net: phy: micrel: Use the kszphy probe/suspend/resumeFabio Estevam
Now that it is possible to use .probe without having .driver_data, let KSZ8061 use the kszphy specific hooks for probe,suspend and resume, which is preferred. Switch to using the dedicated kszphy probe/suspend/resume functions. Signed-off-by: Fabio Estevam <festevam@denx.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20220513114613.762810-2-festevam@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-05-16net: phy: micrel: Allow probing without .driver_dataFabio Estevam
Currently, if the .probe element is present in the phy_driver structure and the .driver_data is not, a NULL pointer dereference happens. Allow passing .probe without .driver_data by inserting NULL checks for priv->type. Signed-off-by: Fabio Estevam <festevam@denx.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20220513114613.762810-1-festevam@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-05-16kselftests/ir : Improve readability of modprobe error messageGautam Menghani
Improve the readability of error message which says module not found. The new behaviour is consistent with the modprobe command. Signed-off-by: Gautam Menghani <gautammenghani201@gmail.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-05-16kunit: tool: update riscv QEMU config with new serial dependencyBrendan Higgins
The config for the serial console for riscv, CONFIG_SERIAL_EARLYCON_RISCV_SBI, added a dependency, CONFIG_RISCV_SBI_V01, at some point, so add that in to the base arch config. Signed-off-by: Brendan Higgins <brendanhiggins@google.com> Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-05-16kcsan: test: use new suite_{init,exit} supportMarco Elver
Use the newly added suite_{init,exit} support for suite-wide init and cleanup. This avoids the unsupported method by which the test used to do suite-wide init and cleanup (avoiding issues such as missing TAP headers, and possible future conflicts). Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-05-16kunit: tool: Add list of all valid test configs on UMLDavid Gow
It's often desirable (particularly in test automation) to run as many tests as possible. This config enables all the tests which work as builtins under UML at present, increasing the total tests run from 156 to 342 (not counting 36 'skipped' tests). They can be run with: ./tools/testing/kunit/kunit.py run --kunitconfig=./tools/testing/kunit/configs/all_tests_uml.config This acts as an in-between point between the KUNIT_ALL_TESTS config (which enables only tests whose dependencies are already enabled), and the kunit_tool --alltests option, which tries to use allyesconfig, taking a very long time to build and breaking very often. Signed-off-by: David Gow <davidgow@google.com> Tested-by: Daniel Latypov <dlatypov@google.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-05-16kunit: take `kunit_assert` as `const`Miguel Ojeda
The `kunit_do_failed_assertion` function passes its `struct kunit_assert` argument to `kunit_fail`. This one, in turn, calls its `format` field passing the assert again as a `const` pointer. Therefore, the whole chain may be made `const`. Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Daniel Latypov <dlatypov@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-05-16kunit: tool: misc cleanupsDaniel Latypov
This primarily comes from running pylint over kunit tool code and ignoring some warnings we don't care about. If we ever got a fully clean setup, we could add this to run_checks.py, but we're not there yet. Fix things like * Drop unused imports * check `is None`, not `== None` (see PEP 8) * remove redundant parens around returns * remove redundant `else` / convert `elif` to `if` where appropriate * rename make_arch_qemuconfig() param to base_kunitconfig (this is the name used in the subclass, and it's a better one) * kunit_tool_test: check the exit code for SystemExit (could be 0) Signed-off-by: Daniel Latypov <dlatypov@google.com> Reviewed-by: David Gow <davidgow@google.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-05-16kunit: tool: minor cosmetic cleanups in kunit_parser.pyDaniel Latypov
There should be no behavioral changes from this patch. This patch removes redundant comment text, inlines a function used in only one place, and other such minor tweaks. Signed-off-by: Daniel Latypov <dlatypov@google.com> Reviewed-by: David Gow <davidgow@google.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-05-16kunit: tool: make parser stop overwriting status of suites w/ no_testsDaniel Latypov
Consider this invocation $ ./tools/testing/kunit/kunit.py parse <<EOF TAP version 14 1..2 ok 1 - suite # Subtest: no_tests_suite # catastrophic error! not ok 1 - no_tests_suite EOF It will have a 0 exit code even though there's a "not ok". Consider this one: $ ./tools/testing/kunit/kunit.py parse <<EOF TAP version 14 1..2 ok 1 - suite not ok 1 - no_tests_suite EOF It will a non-zero exit code. Why? We have this line in the kunit_parser.py > parent_test = parse_test_header(lines, test) where we have special handling when we see "# Subtest" and we ignore the explicit reported "not ok 1" status! Also, NO_TESTS at a suite-level only results in a non-zero status code where then there's only one suite atm. This change is the minimal one to make sure we don't overwrite it. Signed-off-by: Daniel Latypov <dlatypov@google.com> Reviewed-by: David Gow <davidgow@google.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-05-16kunit: tool: remove dead parse_crash_in_log() logicDaniel Latypov
This logic depends on the kernel logging a message containing 'kunit test case crashed', but there is no corresponding logic to do so. This is likely a relic of the revision process KUnit initially went through when being upstreamed. Delete it given 1) it's been missing for years and likely won't get implemented 2) the parser has been moving to be a more general KTAP parser, kunit-only magic like this isn't how we'd want to implement it. Signed-off-by: Daniel Latypov <dlatypov@google.com> Reviewed-by: David Gow <davidgow@google.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-05-16arm64: kdump: Do not allocate crash low memory if not neededZhen Lei
When "crashkernel=X,high" is specified, the specified "crashkernel=Y,low" memory is not required in the following corner cases: 1. If both CONFIG_ZONE_DMA and CONFIG_ZONE_DMA32 are disabled, it means that the devices can access any memory. 2. If the system memory is small, the crash high memory may be allocated from the DMA zones. If that happens, there's no need to allocate another crash low memory because there's already one. Add condition '(crash_base >= CRASH_ADDR_LOW_MAX)' to determine whether the 'high' memory is allocated above DMA zones. Note: when both CONFIG_ZONE_DMA and CONFIG_ZONE_DMA32 are disabled, the entire physical memory is DMA accessible, CRASH_ADDR_LOW_MAX equals 'PHYS_MASK + 1'. Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Acked-by: Baoquan He <bhe@redhat.com> Link: https://lore.kernel.org/r/20220511032033.426-1-thunder.leizhen@huawei.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-05-16ASoC: fsl_sai: Add support for i.MX8MM, MP, ULPMark Brown
Merge series from Shengjiu Wang <shengjiu.wang@nxp.com>: ASoC: fsl_sai: Add support for i.MX8MM, MP, ULP platforms
2022-05-16firmware: mtk: add adsp ipc protocol for SOFMark Brown
Merge series from Tinghan Shen <tinghan.shen@mediatek.com>: This patch provides mediatek adsp ipc support for SOF. ADSP IPC protocol offers (send/recv) interfaces using mediatek-mailbox APIs. This patch was tested and confirmed to work with SOF fw on MT8195 cherry board and MT8186 krabby board. changes since v8: - fix patchset 2 and 3. move "depends on MTK_ADSP_IPC" from SND_SOC_SOF_MTK_COMMON to SND_SOC_SOF_MT8195/MT8186 to prevent generating wrong config. changes since v7: - rebase to linux-next/next-22020504 - use EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL in mtk-adsp-ipc.c - move mtk-adsp-ipc.c out from driver/firmware/mediatek - add user of mtk-adsp-ipc.h in patchset 2 and 3. changes since v6: - rebase to matthias.bgg/linux.git, v5.18-next/soc - Prefer "GPL" over "GPL v2" for MODULE_LICENSE changes since v5: - fix WARNING: modpost: missing MODULE_LICENSE() in drivers/mailbox /mtk-adsp-mailbox.o. Add MODULE_LICENSE in the last line. - Due to WARNING: Missing or malformed SPDX-License-Identifier tag in line 1 in checkpatch, we don't remove SPDX-License in line 1. changes since v4: - add error message for wrong mbox chan changes since v3: - rebase on v5.16-rc8 - update reviewers changes since v2: - add out tag for two memory free phases changes since v1: - add comments for mtk_adsp_ipc_send and mtk_adsp_ipc_recv - remove useless MODULE_LICENSE - change label name to out_free Allen-KH Cheng (1): ASoC: SOF: mediatek: Add ipc support for mt8195 TingHan Shen (1): firmware: mediatek: add adsp ipc protocol interface Tinghan Shen (1): ASoC: SOF: mediatek: Add mt8186 ipc support drivers/firmware/Kconfig | 9 + drivers/firmware/Makefile | 1 + drivers/firmware/mtk-adsp-ipc.c | 157 ++++++++++++++++++ .../linux/firmware/mediatek/mtk-adsp-ipc.h | 65 ++++++++ sound/soc/sof/mediatek/Kconfig | 2 + sound/soc/sof/mediatek/adsp_helper.h | 12 +- sound/soc/sof/mediatek/mt8186/mt8186-loader.c | 5 + sound/soc/sof/mediatek/mt8186/mt8186.c | 141 ++++++++++++++++ sound/soc/sof/mediatek/mt8195/mt8195.c | 138 ++++++++++++++- 9 files changed, 519 insertions(+), 11 deletions(-) create mode 100644 drivers/firmware/mtk-adsp-ipc.c create mode 100644 include/linux/firmware/mediatek/mtk-adsp-ipc.h -- 2.18.0
2022-05-16arm64/sve: Generate ZCR definitionsMark Brown
Convert the various ZCR instances to automatic generation, no functional changes expected. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20220510161208.631259-13-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-05-16arm64/sme: Generate defintions for SVCRMark Brown
Convert SVCR to automatic generation, no functional change. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20220510161208.631259-12-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-05-16arm64/sme: Generate SMPRI_EL1 definitionsMark Brown
Convert SMPRI_EL1 to be generated. No functional change. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20220510161208.631259-11-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-05-16arm64/sme: Automatically generate SMPRIMAP_EL2 definitionsMark Brown
No functional change should be seen from converting SMPRIMAP_EL2 to be generated. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20220510161208.631259-10-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-05-16arm64/sme: Automatically generate SMIDR_EL1 definesMark Brown
Automatically generate the defines for SMIDR_EL1, no functional change. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20220510161208.631259-9-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-05-16arm64/sme: Automatically generate defines for SMCRMark Brown
Convert SMCR to use the register definition code, no functional change. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20220510161208.631259-8-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-05-16arm64/sysreg: Support generation of RAZ fieldsMark Brown
Add a statement for RAZ bitfields to the automatic register generation script. Nothing is emitted to the header for these fields. Signed-off-by: Mark Brown <broonie@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20220510161208.631259-7-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-05-16arm64/sme: Remove _EL0 from name of SVCR - FIXME sysreg.hMark Brown
The defines for SVCR call it SVCR_EL0 however the architecture calls the register SVCR with no _EL0 suffix. In preparation for generating the sysreg definitions rename to match the architecture, no functional change. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220510161208.631259-6-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-05-16arm64/sme: Standardise bitfield names for SVCRMark Brown
The bitfield definitions for SVCR have a SYS_ added to the names of the constant which will be a problem for automatic generation. Remove the prefixes, no functional change. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220510161208.631259-5-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-05-16arm64/sme: Drop SYS_ from SMIDR_EL1 definesMark Brown
We currently have a non-standard SYS_ prefix in the constants generated for SMIDR_EL1 bitfields. Drop this in preparation for automatic register definition generation, no functional change. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220510161208.631259-4-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-05-16arm64/fp: Rename SVE and SME LEN field name to _WIDTHMark Brown
The SVE and SVE length configuration field LEN have constants specifying their width called _SIZE rather than the more normal _WIDTH, in preparation for automatic generation rename to _WIDTH. No functional change. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220510161208.631259-3-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-05-16arm64/fp: Make SVE and SME length register definition match architectureMark Brown
Currently (as of DDI0487H.a) the architecture defines the vector length control field in ZCR and SMCR as being 4 bits wide with an additional 5 bits reserved above it marked as RAZ/WI for future expansion. The kernel currently attempts to anticipate such expansion by treating these extra bits as part of the LEN field but this will be inconvenient when we start generating the defines and would cause problems in the event that the architecture goes a different direction with these fields. Let's instead change the defines to reflect the currently defined architecture, we can update in future as needed. No change in behaviour should be seen in any system, even emulated systems using the maximum allowed vector length for the current architecture. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220510161208.631259-2-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-05-16Merge branch 'for-next/sme' into for-next/sysreg-genCatalin Marinas
* for-next/sme: (29 commits) : Scalable Matrix Extensions support. arm64/sve: Make kernel FPU protection RT friendly arm64/sve: Delay freeing memory in fpsimd_flush_thread() arm64/sme: More sensibly define the size for the ZA register set arm64/sme: Fix NULL check after kzalloc arm64/sme: Add ID_AA64SMFR0_EL1 to __read_sysreg_by_encoding() arm64/sme: Provide Kconfig for SME KVM: arm64: Handle SME host state when running guests KVM: arm64: Trap SME usage in guest KVM: arm64: Hide SME system registers from guests arm64/sme: Save and restore streaming mode over EFI runtime calls arm64/sme: Disable streaming mode and ZA when flushing CPU state arm64/sme: Add ptrace support for ZA arm64/sme: Implement ptrace support for streaming mode SVE registers arm64/sme: Implement ZA signal handling arm64/sme: Implement streaming SVE signal handling arm64/sme: Disable ZA and streaming mode when handling signals arm64/sme: Implement traps and syscall handling for SME arm64/sme: Implement ZA context switching arm64/sme: Implement streaming SVE context switching arm64/sme: Implement SVCR context switching ...
2022-05-16mce: fix set_mce_nospec to always unmap the whole pageJane Chu
The set_memory_uc() approach doesn't work well in all cases. As Dan pointed out when "The VMM unmapped the bad page from guest physical space and passed the machine check to the guest." "The guest gets virtual #MC on an access to that page. When the guest tries to do set_memory_uc() and instructs cpa_flush() to do clean caches that results in taking another fault / exception perhaps because the VMM unmapped the page from the guest." Since the driver has special knowledge to handle NP or UC, mark the poisoned page with NP and let driver handle it when it comes down to repair. Please refer to discussions here for more details. https://lore.kernel.org/all/CAPcyv4hrXPb1tASBZUg-GgdVs0OOFKXMXLiHmktg_kFi7YBMyQ@mail.gmail.com/ Now since poisoned page is marked as not-present, in order to avoid writing to a not-present page and trigger kernel Oops, also fix pmem_do_write(). Fixes: 284ce4011ba6 ("x86/memory_failure: Introduce {set, clear}_mce_nospec()") Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Jane Chu <jane.chu@oracle.com> Acked-by: Tony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/r/165272615484.103830.2563950688772226611.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2022-05-16x86/mce: relocate set{clear}_mce_nospec() functionsJane Chu
Relocate the twin mce functions to arch/x86/mm/pat/set_memory.c file where they belong. While at it, fixup a function name in a comment. Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Jane Chu <jane.chu@oracle.com> Acked-by: Borislav Petkov <bp@suse.de> Cc: Stephen Rothwell <sfr@canb.auug.org.au> [sfr: gate {set,clear}_mce_nospec() by CONFIG_X86_64] Link: https://lore.kernel.org/r/165272527328.90175.8336008202048685278.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2022-05-16acpi/nfit: rely on mce->misc to determine poison granularityJane Chu
nfit_handle_mec() hardcode poison granularity at L1_CACHE_BYTES. Instead, let the driver rely on mce->misc register to determine the poison granularity. Suggested-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Jane Chu <jane.chu@oracle.com> Link: https://lore.kernel.org/r/20220422224508.440670-2-jane.chu@oracle.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2022-05-16kselftest/arm64: Explicitly build no BTI tests with BTI disabledMark Brown
In case a distribution enables branch protection by default do as we do for the main kernel and explicitly disable branch protection when building the test case for having BTI disabled to ensure it doesn't get turned on by the toolchain defaults. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220516182213.727589-1-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-05-16spi: spi-mem: Convert Aspeed SMC driver to spi-memMark Brown
Merge series from Cédric Le Goater <clg@kaod.org>: This series adds a new SPI driver using the spi-mem interface for the Aspeed static memory controllers of the AST2600, AST2500 and AST2400 SoCs. * AST2600 Firmware SPI Memory Controller (FMC) * AST2600 SPI Flash Controller (SPI1 and SPI2) * AST2500 Firmware SPI Memory Controller (FMC) * AST2500 SPI Flash Controller (SPI1 and SPI2) * AST2400 New Static Memory Controller (also referred as FMC) * AST2400 SPI Flash Controller (SPI) It is based on the current OpenBMC kernel driver [1], using directly the MTD SPI-NOR interface and on a patchset [2] previously proposed adding support for the AST2600 only. This driver takes a slightly different approach to cover all 6 controllers. It does not make use of the controller register disabling Address and Data byte lanes because is not available on the AST2400 SoC. We could introduce a specific handler for new features available on recent SoCs if needed. As there is not much difference on performance, the driver chooses the common denominator: "User mode" which has been heavily tested in [1]. "User mode" is also used as a fall back method when flash device mapping window is too small. Problems to address with spi-mem were the configuration of the mapping windows and the calibration of the read timings. The driver handles them in the direct mapping handler when some knowledge on the size of the flash device is know. It is not perfect but not incorrect either. The algorithm is one from [1] because it doesn't require the DMA registers which are not available on all controllers. Direct mapping for writes is not supported (yet). I have seen some corruption with writes and I preferred to use the safer and proven method of the initial driver [1]. We can improve that later. The driver supports Quad SPI RX transfers on the AST2600 SoC but it didn't have the expected results. Therefore it is not activated yet. There are some issues on the pinctrl to investigate first. Tested on: * OpenPOWER Palmetto (AST2400) * Facebook Wedge 100 BMC (AST2400) by Tao Ren <rentao.bupt@gmail.com> * Evaluation board (AST2500) * Inspur FP5280G2 BMC (AST2500) by John Wang <wangzq.jn@gmail.com> * Facebook Backpack CMM BMC (AST2500) by Tao Ren <rentao.bupt@gmail.com> * OpenPOWER Witherspoon (AST2500) * Evaluation board (AST2600 A0 and A3) * Rainier board (AST2600) [1] https://github.com/openbmc/linux/blob/dev-5.15/drivers/mtd/spi-nor/controllers/aspeed-smc.c [2] https://patchwork.ozlabs.org/project/linux-aspeed/list/?series=212394
2022-05-16drm/amd/pm: consistent approach for smartshiftSathishkumar S
create smartshift sysfs attributes from dGPU device even on smartshift 1.0 platform to be consistent. Do not populate the attributes on platforms that have APU only but not dGPU or vice versa. V2: avoid checking for the number of VGA/DISPLAY devices (Lijo) move code to read from dGPU or APU into a function and reuse (Lijo) Suggested-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sathishkumar S <sathishkumar.sundararaju@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-05-16drm/amd/display: clean up some inconsistent indentingJiapeng Chong
Eliminate the follow smatch warning: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9687 amdgpu_dm_atomic_commit_tail() warn: inconsistent indenting. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-05-16arm64/sve: Make kernel FPU protection RT friendlySebastian Andrzej Siewior
Non RT kernels need to protect FPU against preemption and bottom half processing. This is achieved by disabling bottom halves via local_bh_disable() which implictly disables preemption. On RT kernels this protection mechanism is not sufficient because local_bh_disable() does not disable preemption. It serializes bottom half related processing via a CPU local lock. As bottom halves are running always in thread context on RT kernels disabling preemption is the proper choice as it implicitly prevents bottom half processing. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220505163207.85751-3-bigeasy@linutronix.de Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-05-16arm64/sve: Delay freeing memory in fpsimd_flush_thread()Sebastian Andrzej Siewior
fpsimd_flush_thread() invokes kfree() via sve_free()+sme_free() within a preempt disabled section which is not working on -RT. Delay freeing of memory until preemption is enabled again. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220505163207.85751-2-bigeasy@linutronix.de Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-05-16arm64: mm: Make arch_faults_on_old_pte() check for migratabilityValentin Schneider
arch_faults_on_old_pte() relies on the calling context being non-preemptible. CONFIG_PREEMPT_RT turns the PTE lock into a sleepable spinlock, which doesn't disable preemption once acquired, triggering the warning in arch_faults_on_old_pte(). It does however disable migration, ensuring the task remains on the same CPU during the entirety of the critical section, making the read of cpu_has_hw_af() safe and stable. Make arch_faults_on_old_pte() check cant_migrate() instead of preemptible(). Cc: Valentin Schneider <vschneid@redhat.com> Suggested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Valentin Schneider <valentin.schneider@arm.com> Link: https://lore.kernel.org/r/20220127192437.1192957-1-valentin.schneider@arm.com Acked-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20220505163207.85751-4-bigeasy@linutronix.de Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-05-16arm64: mte: Clean up user tag accessorsRobin Murphy
Invoking user_ldst to explicitly add a post-increment of 0 is silly. Just use a normal USER() annotation and save the redundant instruction. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Tong Tiangen <tongtiangen@huawei.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20220420030418.3189040-6-tongtiangen@huawei.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-05-16kselftest/arm64: bti: force static linkingAndre Przywara
The "bti" selftests are built with -nostdlib, which apparently automatically creates a statically linked binary, which is what we want and need for BTI (to avoid interactions with the dynamic linker). However this is not true when building a PIE binary, which some toolchains (Ubuntu) configure as the default. When compiling btitest with such a toolchain, it will create a dynamically linked binary, which will probably fail some tests, as the dynamic linker might not support BTI: =================== TAP version 13 1..18 not ok 1 nohint_func/call_using_br_x0 not ok 2 nohint_func/call_using_br_x16 not ok 3 nohint_func/call_using_blr .... =================== To make sure we create static binaries, add an explicit -static on the linker command line. This forces static linking even if the toolchain defaults to PIE builds, and fixes btitest runs on BTI enabled machines. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Mark Brown <broonie@kernel.org> Fixes: 314bcbf09f14 ("kselftest: arm64: Add BTI tests") Link: https://lore.kernel.org/r/20220511172129.2078337-1-andre.przywara@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-05-16block, bfq: make bfq_has_work() more accurateYu Kuai
bfq_has_work() is using busy_queues currently, which is not accurate because bfq_queue is busy doesn't represent that it has requests. Since bfqd aready has a counter 'queued' to record how many requests are in bfq, use it instead of busy_queues. Noted that bfq_has_work() can be called with 'bfqd->lock' held, thus the lock can't be held in bfq_has_work() to protect 'bfqd->queued'. Signed-off-by: Yu Kuai <yukuai3@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20220513023507.2625717-3-yukuai3@huawei.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-05-16block, bfq: protect 'bfqd->queued' by 'bfqd->lock'Yu Kuai
If bfq_schedule_dispatch() is called from bfq_idle_slice_timer_body(), then 'bfqd->queued' is read without holding 'bfqd->lock'. This is wrong since it can be wrote concurrently. Fix the problem by holding 'bfqd->lock' in such case. Signed-off-by: Yu Kuai <yukuai3@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Link: https://lore.kernel.org/r/20220513023507.2625717-2-yukuai3@huawei.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-05-16block: cleanup the VM accounting in submit_bioChristoph Hellwig
submit_bio uses some extremely convoluted checks and confusing comments to only account REQ_OP_READ/REQ_OP_WRITE comments. Just switch to the plain obvious checks instead. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20220516063654.2782792-1-hch@lst.de [axboe: fixup WRITE -> REQ_OP_WRITE] Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-05-16pinctrl: lynxpoint: make irq_chip immutableAndy Shevchenko
Since recently, the kernel is nagging about mutable irq_chips: "not an immutable chip, please consider fixing it!" Drop the unneeded copy, flag it as IRQCHIP_IMMUTABLE, add the new helper functions and call the appropriate gpiolib functions. While at it, switch hwirq variable to use the correct type for the sake of consistency. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-05-16pinctrl: cherryview: make irq_chip immutableAndy Shevchenko
Since recently, the kernel is nagging about mutable irq_chips: "not an immutable chip, please consider fixing it!" Drop the unneeded copy, flag it as IRQCHIP_IMMUTABLE, add the new helper functions and call the appropriate gpiolib functions. While at it, switch to use hwirq variable instead of pin for the sake of consistency. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-05-16pinctrl: baytrail: make irq_chip immutableAndy Shevchenko
Since recently, the kernel is nagging about mutable irq_chips: "not an immutable chip, please consider fixing it!" Drop the unneeded copy, flag it as IRQCHIP_IMMUTABLE, add the new helper functions and call the appropriate gpiolib functions. While at it, switch to use hwirq variable instead of offset for the sake of consistency. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-05-16Documentation: gpio: Advertise irqd_to_hwirq() helper in the examplesAndy Shevchenko
Instead of direct dereferencing the IRQ data in order to get HW IRQ number use the irqd_to_hwirq() helper. Fixes: 5644b66a9c63 ("Documentation: Update the recommended pattern for GPIO irqchips") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
generated by cgit (git 2.34.1) at 2025-09-22 06:10:44 +0000