aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2022-06-09drm: Add support for the LogiCVC display controllerPaul Kocialkowski18-0/+2232
Introduces a driver for the LogiCVC display controller, a programmable logic controller optimized for use in Xilinx Zynq-7000 SoCs and other Xilinx FPGAs. The controller is mostly configured at logic synthesis time so only a subset of configuration is left for the driver to handle. The following features are implemented and tested: - LVDS 4-bit interface; - RGB565 pixel formats; - Multiple layers and hardware composition; - Layer-wide alpha mode; The following features are implemented but untested: - Other RGB pixel formats; - Layer framebuffer configuration for version 4; - Lowest-layer used as background color; - Per-pixel alpha mode. The following features are not implemented: - YUV pixel formats; - DVI, LVDS 3-bit, ITU656 and camera link interfaces; - External parallel input for layer; - Color-keying; - LUT-based alpha modes. Additional implementation-specific notes: - Panels are only enabled after the first page flip to avoid flashing a white screen. - Depth used in context of the LogiCVC driver only counts color components to match the definition of the synthesis parameters. Support is implemented for both version 3 and 4 of the controller. With version 3, framebuffers are stored in a dedicated contiguous memory area, with a base address hardcoded for each layer. This requires using a dedicated CMA pool registered at the base address and tweaking a few offset-related registers to try to use any buffer allocated from the pool. This is done on a best-effort basis to have the hardware cope with the DRM framebuffer allocation model and there is no guarantee that each buffer allocated by GEM CMA can be used for any layer. In particular, buffers allocated below the base address for a layer are guaranteed not to be configurable for that layer. See the implementation of logicvc_layer_buffer_find_setup for specifics. Version 4 allows configuring each buffer address directly, which guarantees that any buffer can be configured. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220520141555.1429041-2-paul.kocialkowski@bootlin.com
2022-06-09drm/i915/pvc: Add register steeringMatt Roper6-10/+71
Ponte Vecchio no longer has MSLICE or LNCF steering, but the bspec does document several new types of multicast register ranges. Fortunately, most of the different MCR types all provide valid values at instance (0,0) so there's no need to read fuse registers and calculate a non-terminated instance. We'll lump all of those range types (BSLICE, HALFBSLICE, TILEPSMI, CC, and L3BANK) into a single category called "INSTANCE0" to keep things simple. We'll also perform explicit steering for each of these multicast register types, even if the implicit steering setup for COMPUTE/DSS ranges would have worked too; this is based on guidance from our hardware architects who suggested that we move away from implicit steering and start explicitly steer all MCR register accesses on modern platforms (we'll work on transitioning COMPUTE/DSS to explicit steering in the future). Note that there's one additional MCR range type defined in the bspec (SQIDI) that we don't handle here. Those ranges use a different steering control register that we never touch; since instance 0 is also always a valid setting there, we can just ignore those ranges. Finally, we'll rename the HAS_MSLICES() macro to HAS_MSLICE_STEERING(). PVC hardware still has units referred to as mslices, but there's no register steering based on mslice for this platform. v2: - Rebase on other recent changes - Swap two table rows to keep table sorted & easy to read. (Harish) Bspec: 67609 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Harish Chegondi <harish.chegondi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220608170700.4026648-1-matthew.d.roper@intel.com
2022-06-09KVM: arm64: Move vcpu configuration flags into their own setMarc Zyngier2-10/+13
The KVM_ARM64_{GUEST_HAS_SVE,VCPU_SVE_FINALIZED,GUEST_HAS_PTRAUTH} flags are purely configuration flags. Once set, they are never cleared, but evaluated all over the code base. Move these three flags into the configuration set in one go, using the new accessors, and take this opportunity to drop the KVM_ARM64_ prefix which doesn't provide any help. Reviewed-by: Fuad Tabba <tabba@google.com> Reviewed-by: Reiji Watanabe <reijiw@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2022-06-09Merge tag 'kvmarm-fixes-5.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEADPaolo Bonzini14-74/+95
KVM/arm64 fixes for 5.19, take #1 - Properly reset the SVE/SME flags on vcpu load - Fix a vgic-v2 regression regarding accessing the pending state of a HW interrupt from userspace (and make the code common with vgic-v3) - Fix access to the idreg range for protected guests - Ignore 'kvm-arm.mode=protected' when using VHE - Return an error from kvm_arch_init_vm() on allocation failure - A bunch of small cleanups (comments, annotations, indentation)
2022-06-09Revert "fbdev: Prevent probing generic drivers if a FB is already registered"Daniel Vetter2-22/+0
This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee. With commit 27599aacbaefcbf2af7b06b0029459bbf682000d Author: Thomas Zimmermann <tzimmermann@suse.de> Date: Tue Jan 25 10:12:18 2022 +0100 fbdev: Hot-unplug firmware fb devices on forced removal this should be fixed properly and we can remove this somewhat hackish check here (e.g. this won't catch drm drivers if fbdev emulation isn't enabled). Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Zack Rusin <zackr@vmware.com> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Zack Rusin <zackr@vmware.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Ilya Trukhanov <lahvuun@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Cc: Peter Jones <pjones@redhat.com> Cc: linux-fbdev@vger.kernel.org Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220607182338.344270-5-javierm@redhat.com
2022-06-09fbdev: Disable sysfb device registration when removing conflicting FBsJavier Martinez Canillas1-0/+12
The platform devices registered by sysfb match with firmware-based DRM or fbdev drivers, that are used to have early graphics using a framebuffer provided by the system firmware. DRM or fbdev drivers later are probed and remove conflicting framebuffers, leading to these platform devices for generic drivers to be unregistered. But the current solution has a race, since the sysfb_init() function could be called after a DRM or fbdev driver is probed and request to unregister the devices for drivers with conflicting framebuffes. To prevent this, disable any future sysfb platform device registration by calling sysfb_disable(), if a driver requests to remove the conflicting framebuffers. Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220607182338.344270-4-javierm@redhat.com
2022-06-09firmware: sysfb: Add sysfb_disable() helper functionJavier Martinez Canillas3-6/+66
This can be used by subsystems to unregister a platform device registered by sysfb and also to disable future platform device registration in sysfb. Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220607182338.344270-3-javierm@redhat.com
2022-06-09firmware: sysfb: Make sysfb_create_simplefb() return a pdev pointerJavier Martinez Canillas3-15/+15
This function just returned 0 on success or an errno code on error, but it could be useful for sysfb_init() callers to have a pointer to the device. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220607182338.344270-2-javierm@redhat.com
2022-06-09ARM: s3c: Kconfig.s3c64xx: Fix indentationJuerg Haefliger1-8/+8
The convention for indentation seems to be a single tab. Help text is further indented by an additional two whitespaces. Fix the lines that violate these rules. Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com> Link: https://lore.kernel.org/r/20220609082154.115301-4-juerg.haefliger@canonical.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2022-06-09ARM: s3c: Kconfig.s3c24xx: Fix indentation and replace some tabsJuerg Haefliger1-14/+12
The convention for indentation seems to be a single tab. Help text is further indented by an additional two whitespaces. Fix the lines that violate these rules. While add it, replace tabs before comments with whitespaces (which seems to be more common), add a missing trailing endif comment and squeeze multiple empty lines. Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com> Link: https://lore.kernel.org/r/20220609082154.115301-3-juerg.haefliger@canonical.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2022-06-09ARM: s3c: Kconfig: Fix indentationJuerg Haefliger1-7/+7
The convention for indentation seems to be a single tab. Help text is further indented by an additional two whitespaces. Fix the lines that violate these rules. Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com> Link: https://lore.kernel.org/r/20220609082154.115301-2-juerg.haefliger@canonical.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2022-06-09drm/atomic: fix warning of unused variableGONG, Ruiqi1-0/+1
Fix the `unused-but-set-variable` warning as how other iteration wrappers do. Link: https://lore.kernel.org/all/202206071049.pofHsRih-lkp@intel.com/ Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: GONG, Ruiqi <gongruiqi1@huawei.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220607110848.941486-1-gongruiqi1@huawei.com
2022-06-099p: handling Rerror without copy_from_iter_full()Al Viro2-85/+35
p9_client_zc_rpc()/p9_check_zc_errors() are playing fast and loose with copy_from_iter_full(). Reading from file is done by sending Tread request. Response consists of fixed-sized header (including the amount of data actually read) followed by the data itself. For zero-copy case we arrange the things so that the first 11 bytes of reply go into the fixed-sized buffer, with the rest going straight into the pages we want to read into. What makes the things inconvenient is that sglist describing what should go where has to be set *before* the reply arrives. As the result, if reply is an error, the things get interesting. On success we get size[4] Rread tag[2] count[4] data[count] For error layout varies depending upon the protocol variant - in original 9P and 9P2000 it's size[4] Rerror tag[2] len[2] error[len] in 9P2000.U size[4] Rerror tag[2] len[2] error[len] errno[4] in 9P2000.L size[4] Rlerror tag[2] errno[4] The last case is nice and simple - we have an 11-byte response that fits into the fixed-sized buffer we hoped to get an Rread into. In other two, though, we get a variable-length string spill into the pages we'd prepared for the data to be read. Had that been in fixed-sized buffer (which is actually 4K), we would've dealt with that the same way we handle non-zerocopy case. However, for zerocopy it doesn't end up there, so we need to copy it from those pages. The trouble is, by the time we get around to that, the references to pages in question are already dropped. As the result, p9_zc_check_errors() tries to get the data using copy_from_iter_full(). Unfortunately, the iov_iter it's trying to read from might *NOT* be capable of that. It is, after all, a data destination, not data source. In particular, if it's an ITER_PIPE one, copy_from_iter_full() will simply fail. In ->zc_request() itself we do have those pages and dealing with the problem in there would be a simple matter of memcpy_from_page() into the fixed-sized buffer. Moreover, it isn't hard to recognize the (rare) case when such copying is needed. That way we get rid of p9_zc_check_errors() entirely - p9_check_errors() can be used instead both for zero-copy and non-zero-copy cases. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2022-06-09Merge tag 'kvm-riscv-fixes-5.19-1' of https://github.com/kvm-riscv/linux into HEADPaolo Bonzini12724-253510/+1036208
KVM/riscv fixes for 5.19, take #1 - Typo fix in arch/riscv/kvm/vmid.c - Remove broken reference pattern from MAINTAINERS entry
2022-06-09powerpc/32: Fix overread/overwrite of thread_struct via ptraceMichael Ellerman2-6/+17
The ptrace PEEKUSR/POKEUSR (aka PEEKUSER/POKEUSER) API allows a process to read/write registers of another process. To get/set a register, the API takes an index into an imaginary address space called the "USER area", where the registers of the process are laid out in some fashion. The kernel then maps that index to a particular register in its own data structures and gets/sets the value. The API only allows a single machine-word to be read/written at a time. So 4 bytes on 32-bit kernels and 8 bytes on 64-bit kernels. The way floating point registers (FPRs) are addressed is somewhat complicated, because double precision float values are 64-bit even on 32-bit CPUs. That means on 32-bit kernels each FPR occupies two word-sized locations in the USER area. On 64-bit kernels each FPR occupies one word-sized location in the USER area. Internally the kernel stores the FPRs in an array of u64s, or if VSX is enabled, an array of pairs of u64s where one half of each pair stores the FPR. Which half of the pair stores the FPR depends on the kernel's endianness. To handle the different layouts of the FPRs depending on VSX/no-VSX and big/little endian, the TS_FPR() macro was introduced. Unfortunately the TS_FPR() macro does not take into account the fact that the addressing of each FPR differs between 32-bit and 64-bit kernels. It just takes the index into the "USER area" passed from userspace and indexes into the fp_state.fpr array. On 32-bit there are 64 indexes that address FPRs, but only 32 entries in the fp_state.fpr array, meaning the user can read/write 256 bytes past the end of the array. Because the fp_state sits in the middle of the thread_struct there are various fields than can be overwritten, including some pointers. As such it may be exploitable. It has also been observed to cause systems to hang or otherwise misbehave when using gdbserver, and is probably the root cause of this report which could not be easily reproduced: https://lore.kernel.org/linuxppc-dev/dc38afe9-6b78-f3f5-666b-986939e40fc6@keymile.com/ Rather than trying to make the TS_FPR() macro even more complicated to fix the bug, or add more macros, instead add a special-case for 32-bit kernels. This is more obvious and hopefully avoids a similar bug happening again in future. Note that because 32-bit kernels never have VSX enabled the code doesn't need to consider TS_FPRWIDTH/OFFSET at all. Add a BUILD_BUG_ON() to ensure that 32-bit && VSX is never enabled. Fixes: 87fec0514f61 ("powerpc: PTRACE_PEEKUSR/PTRACE_POKEUSER of FPR registers in little endian builds") Cc: stable@vger.kernel.org # v3.13+ Reported-by: Ariel Miculas <ariel.miculas@belden.com> Tested-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220609133245.573565-1-mpe@ellerman.id.au
2022-06-09Revert "mtd: rawnand: add support for Toshiba TC58NVG0S3HTA00 NAND flash"Christian Lamparter1-3/+0
This reverts commit 3380557fc7e28d9bce7607e16d98f123d36da4ca. It turned out this "4-byte" ID might have been an honest mistake. Regrettably, the chip Andreas has might be a counterfeit or is damaged in some other way and shouldn't have ended up in a router. Andreas reported his chip is returning just four bytes: "98 f1 80 15 00 00 00 00". However, according to Kioxia/Toshiba's datasheet, there should have been at least another byte that would have contained the correct OOB size that Andreas needed. Miquel and Andreas are both favoring reverting the patch over further, possibly hacky modifications: "[Reverting] is the safest option here. Apart from this device, we do not know how many devices have these damaged/counterfeit chips. If it is just a couple and only on Fritzboxes, as suggested in the Github issue the patch could be carried through OpenWrt[...]" Thanks to several users on the openwrt forum and github issue, who stayed along for the ride: - Peter-vdL for reporting the issue and testing patches. - neg2led and Hannu Nyman who did all the datasheet digging and debugging. Cc: Andreas Boehler <dev@aboehler.at> Suggested-by: Andreas Boehler <dev@aboehler.at> Suggested-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://github.com/openwrt/openwrt/issues/9962 Signed-off-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220607185918.1048204-1-chunkeey@gmail.com
2022-06-09mtd: st_spi_fsm: Simplify error checking in .probe() a bitUwe Kleine-König1-7/+4
Instead of ending each if branch with the same check, do it once unconditionally after the if block. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220607152458.232847-5-u.kleine-koenig@pengutronix.de
2022-06-09mtd: st_spi_fsm: Disable clock only after device was unregisteredUwe Kleine-König1-2/+2
Until mtd_device_unregister() returns the device is expected to be operational. So only disable the clock after the mtd is unregistered. Fixes: 1fefc8ecb834 ("mtd: st_spi_fsm: add missing clk_disable_unprepare() in stfsm_remove()") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220607152458.232847-4-u.kleine-koenig@pengutronix.de
2022-06-09mtd: st_spi_fsm: Warn about failure to unregister mtd deviceUwe Kleine-König1-1/+3
mtd_device_unregister() shouldn't fail. Wail loudly if it does anyhow. This matches how other drivers (e.g. nand/raw/nandsim.c) use mtd_device_unregister(). By returning 0 in the platform remove callback a generic error message by the device core is suppressed, nothing else changes. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220607152458.232847-3-u.kleine-koenig@pengutronix.de
2022-06-09mtd: st_spi_fsm: Add a clk_disable_unprepare() in .probe()'s error pathUwe Kleine-König1-3/+5
For all but one error path clk_disable_unprepare() is already there. Add it to the one location where it's missing. Fixes: 481815a6193b ("mtd: st_spi_fsm: Handle clk_prepare_enable/clk_disable_unprepare.") Fixes: 69d5af8d016c ("mtd: st_spi_fsm: Obtain and use EMI clock") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220607152458.232847-2-u.kleine-koenig@pengutronix.de
2022-06-09mtd: rawnand: atmel: Warn about failure to unregister mtd deviceUwe Kleine-König1-1/+3
The Linux device core doesn't intend remove callbacks to fail. If an error code is returned the device is removed anyhow. So wail loudly if the atmel specific remove callback fails and return 0 anyhow to suppress the generic (and little helpful) error message by the device core. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220607062503.211345-1-u.kleine-koenig@pengutronix.de
2022-06-09mtd: physmap: Drop if with an always false conditionUwe Kleine-König1-4/+0
The remove callback is only called after probe completed successfully. In this case platform_set_drvdata() was called with a non-NULL argument and so info is never NULL. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220603210758.148493-15-u.kleine-koenig@pengutronix.de
2022-06-09mtd: physmap: Don't skip cleanup after mtd_device_unregister() failedUwe Kleine-König1-6/+3
If mtd_device_unregister() fails (which it doesn't when used correctly), the resources bound by the nand chip should be freed anyhow as returning an error value doesn't prevent the device getting unbound. Instead use WARN_ON on the return value similar to how other drivers do it. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220603210758.148493-14-u.kleine-koenig@pengutronix.de
2022-06-09mtd: rawnand: meson: Drop cleaning platform data in .remove()Uwe Kleine-König1-2/+0
The driver core cares for unsetting platform data (see device_unbind_cleanup()) on remove. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220603210758.148493-13-u.kleine-koenig@pengutronix.de
2022-06-09mtd: rawnand: meson: Don't skip cleanup after mtd_device_unregister() failedUwe Kleine-König1-11/+3
If mtd_device_unregister() fails (which it doesn't when used correctly), the resources bound by the nand chip should be freed anyhow as returning an error value doesn't prevent the device getting unbound. Instead use WARN_ON on the return value similar to how other drivers do it. Then meson_nfc_nand_chip_cleanup() returns 0 unconditionally and can be changed to return void which allows further simplification in the remove callback. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220603210758.148493-12-u.kleine-koenig@pengutronix.de
2022-06-09mtd: rawnand: tegra: Don't skip cleanup after mtd_device_unregister() failedUwe Kleine-König1-4/+1
If mtd_device_unregister() fails (which it doesn't when used correctly), the resources bound by the nand chip should be freed anyhow as returning an error value doesn't prevent the device getting unbound. Instead use WARN_ON on the return value similar to how other drivers do it. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220603210758.148493-11-u.kleine-koenig@pengutronix.de
2022-06-09mtd: rawnand: omap2: Suppress error message after WARN in .remove()Uwe Kleine-König1-4/+2
Returning an error value in a platform remove callback results in an error message being emitted by the platform core, but otherwise it doesn't make a difference. After the WARN splat this generic error message doesn't add any value, so return 0 unconditionally Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220603210758.148493-10-u.kleine-koenig@pengutronix.de
2022-06-09mtd: spear_smi: Drop if with an always false conditionUwe Kleine-König1-4/+0
The remove callback is only called after probe completed successfully. In this case platform_set_drvdata() was called with a non-NULL argument and so dev is never NULL. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220603210758.148493-8-u.kleine-koenig@pengutronix.de
2022-06-09mtd: spear_smi: Don't skip cleanup after mtd_device_unregister() failedUwe Kleine-König1-4/+2
If mtd_device_unregister() fails (which it doesn't when used correctly), the resources bound by the nand chip should be freed anyhow as returning an error value doesn't prevent the device getting unbound. Instead use WARN_ON on the return value similar to how other drivers do it. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220603210758.148493-7-u.kleine-koenig@pengutronix.de
2022-06-09mtd: lpddr2_nvm: Warn about failure to unregister mtd deviceUwe Kleine-König1-1/+3
mtd_device_unregister() shouldn't fail. Wail loudly if it does anyhow. This matches how other drivers (e.g. nand/raw/nandsim.c) use mtd_device_unregister(). By returning 0 in the platform remove callback a generic error message by the device core is suppressed, nothing else changes. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220603210758.148493-6-u.kleine-koenig@pengutronix.de
2022-06-09mtd: powernv_flash: Warn about failure to unregister mtd deviceUwe Kleine-König1-1/+3
mtd_device_unregister() shouldn't fail. Wail loudly if it does anyhow. This matches how other drivers (e.g. nand/raw/nandsim.c) use mtd_device_unregister(). By returning 0 in the platform remove callback a generic error message by the device core is suppressed, nothing else changes. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220603210758.148493-4-u.kleine-koenig@pengutronix.de
2022-06-09mtd: hyperbus: Make hyperbus_unregister_device() return voidUwe Kleine-König4-14/+9
The only thing that could theoretically fail in that function is mtd_device_unregister(). However it's not supposed to fail and when used correctly it doesn't. So wail loudly if it does anyhow. This matches how other drivers (e.g. nand/raw/nandsim.c) use mtd_device_unregister(). This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220603210758.148493-2-u.kleine-koenig@pengutronix.de
2022-06-09mtdchar: use kvmalloc() for potentially large allocationsMichał Kępień1-5/+5
mtdchar_write_ioctl() calls kmalloc() with the 'size' argument set to the smaller of two values: the write request's data/OOB length provided by user space and the erase block size of the MTD device. If the latter is large, kmalloc() may not be able to serve such allocation requests. Use kvmalloc() instead. Correspondingly, replace kfree() calls with kvfree() calls. Suggested-by: Richard Weinberger <richard@nod.at> Signed-off-by: Michał Kępień <kernel@kempniu.pl> Acked-by: Richard Weinberger <richard@nod.at> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220516070601.11428-3-kernel@kempniu.pl
2022-06-09mtdchar: prevent integer overflow in a safety checkMichał Kępień2-2/+5
Commit 6420ac0af95d ("mtdchar: prevent unbounded allocation in MEMWRITE ioctl") added a safety check to mtdchar_write_ioctl() which attempts to ensure that the write request sent by user space does not extend beyond the MTD device's size. However, that check contains an addition of two struct mtd_write_req fields, 'start' and 'len', both of which are u64 variables. The result of that addition can overflow, allowing the safety check to be bypassed. The arguably simplest fix - changing the data types of the relevant struct mtd_write_req fields - is not feasible as it would break user space. Fix by making mtdchar_write_ioctl() truncate the value provided by user space in the 'len' field of struct mtd_write_req, so that only the lower 32 bits of that field are used, preventing the overflow. While the 'ooblen' field of struct mtd_write_req is not currently used in any similarly flawed safety check, also truncate it to 32 bits, for consistency with the 'len' field and with other MTD routines handling OOB data. Update include/uapi/mtd/mtd-abi.h accordingly. Suggested-by: Richard Weinberger <richard@nod.at> Signed-off-by: Michał Kępień <kernel@kempniu.pl> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220516070601.11428-2-kernel@kempniu.pl
2022-06-09mtd: parsers: ofpart: Fix refcount leak in bcm4908_partitions_fw_offsetMiaoqian Lin1-0/+3
of_find_node_by_path() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: bb17230c61a6 ("mtd: parsers: ofpart: support BCM4908 fixed partitions") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220605070726.5979-1-linmq006@gmail.com
2022-06-09mtd: parsers: add support for Sercomm partitionsMikhail Zhilkin3-0/+258
This adds an MTD partition parser for the Sercomm partition table that is used in some Beeline, Netgear and Sercomm routers. The Sercomm partition map table contains real partition offsets, which may differ from device to device depending on the number and location of bad blocks on NAND. Original patch (proposed by NOGUCHI Hiroshi): Link: https://github.com/openwrt/openwrt/pull/1318#issuecomment-420607394 Signed-off-by: NOGUCHI Hiroshi <drvlabo@gmail.com> Signed-off-by: Mikhail Zhilkin <csharper2005@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220529110714.189732-1-csharper2005@gmail.com
2022-06-09mtd: partitions: Fix refcount leak in parse_redboot_ofMiaoqian Lin1-0/+1
of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: 237960880960 ("mtd: partitions: redboot: seek fis-index-block in the right node") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220526110652.64849-1-linmq006@gmail.com
2022-06-09mtd: sm_ftl: Fix deadlock caused by cancel_work_sync in sm_releaseDuoming Zhou1-1/+1
There is a deadlock between sm_release and sm_cache_flush_work which is a work item. The cancel_work_sync in sm_release will not return until sm_cache_flush_work is finished. If we hold mutex_lock and use cancel_work_sync to wait the work item to finish, the work item also requires mutex_lock. As a result, the sm_release will be blocked forever. The race condition is shown below: (Thread 1) | (Thread 2) sm_release | mutex_lock(&ftl->mutex) | sm_cache_flush_work | mutex_lock(&ftl->mutex) cancel_work_sync | ... This patch moves del_timer_sync and cancel_work_sync out of mutex_lock in order to mitigate deadlock. Fixes: 7d17c02a01a1 ("mtd: Add new SmartMedia/xD FTL") Signed-off-by: Duoming Zhou <duoming@zju.edu.cn> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220524044841.10517-1-duoming@zju.edu.cn
2022-06-09USB: serial: option: add support for Cinterion MV31 with new baselineSlark Xiao1-0/+6
Adding support for Cinterion device MV31 with Qualcomm new baseline. Use different PIDs to separate it from previous base line products. All interfaces settings keep same as previous. Below is test evidence: T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 6 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1e2d ProdID=00b8 Rev=04.14 S: Manufacturer=Cinterion S: Product=Cinterion PID 0x00B8 USB Mobile Broadband S: SerialNumber=90418e79 C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim I: If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option I: If#=0x3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option I: If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 7 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1e2d ProdID=00b9 Rev=04.14 S: Manufacturer=Cinterion S: Product=Cinterion PID 0x00B9 USB Mobile Broadband S: SerialNumber=90418e79 C: #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan I: If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option I: If#=0x3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option For PID 00b8, interface 3 is GNSS port which don't use serial driver. Signed-off-by: Slark Xiao <slark_xiao@163.com> Link: https://lore.kernel.org/r/20220601034740.5438-1-slark_xiao@163.com [ johan: rename defines using a "2" infix ] Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
2022-06-09exfat: use updated exfat_chain directly during renamingSungjong Seo1-1/+3
In order for a file to access its own directory entry set, exfat_inode_info(ei) has two copied values. One is ei->dir, which is a snapshot of exfat_chain of the parent directory, and the other is ei->entry, which is the offset of the start of the directory entry set in the parent directory. Since the parent directory can be updated after the snapshot point, it should be used only for accessing one's own directory entry set. However, as of now, during renaming, it could try to traverse or to allocate clusters via snapshot values, it does not make sense. This potential problem has been revealed when exfat_update_parent_info() was removed by commit d8dad2588add ("exfat: fix referencing wrong parent directory information after renaming"). However, I don't think it's good idea to bring exfat_update_parent_info() back. Instead, let's use the updated exfat_chain of parent directory diectly. Fixes: d8dad2588add ("exfat: fix referencing wrong parent directory information after renaming") Reported-by: Wang Yugui <wangyugui@e16-tech.com> Signed-off-by: Sungjong Seo <sj1557.seo@samsung.com> Tested-by: Wang Yugui <wangyugui@e16-tech.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
2022-06-09KVM: arm64: Drop stale commentMarc Zyngier1-5/+0
The layout of 'struct kvm_vcpu_arch' has evolved significantly since the initial port of KVM/arm64, so remove the stale comment suggesting that a prefix of the structure is used exclusively from assembly code. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220609121223.2551-7-will@kernel.org
2022-06-09KVM: arm64: Remove redundant hyp_assert_lock_held() assertionsWill Deacon1-4/+0
host_stage2_try() asserts that the KVM host lock is held, so there's no need to duplicate the assertion in its wrappers. Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220609121223.2551-6-will@kernel.org
2022-06-09KVM: arm64: Extend comment in has_vhe()Will Deacon1-0/+3
has_vhe() expands to a compile-time constant when evaluated from the VHE or nVHE code, alternatively checking a static key when called from elsewhere in the kernel. On face value, this looks like a case of premature optimization, but in fact this allows symbol references on VHE-specific code paths to be dropped from the nVHE object. Expand the comment in has_vhe() to make this clearer, hopefully discouraging anybody from simplifying the code. Cc: David Brazdil <dbrazdil@google.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220609121223.2551-5-will@kernel.org
2022-06-09KVM: arm64: Ignore 'kvm-arm.mode=protected' when using VHEWill Deacon3-11/+6
Ignore 'kvm-arm.mode=protected' when using VHE so that kvm_get_mode() only returns KVM_MODE_PROTECTED on systems where the feature is available. Cc: David Brazdil <dbrazdil@google.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220609121223.2551-4-will@kernel.org
2022-06-09KVM: arm64: Handle all ID registers trapped for a protected VMMarc Zyngier1-8/+34
A protected VM accessing ID_AA64ISAR2_EL1 gets punished with an UNDEF, while it really should only get a zero back if the register is not handled by the hypervisor emulation (as mandated by the architecture). Introduce all the missing ID registers (including the unallocated ones), and have them to return 0. Reported-by: Will Deacon <will@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220609121223.2551-3-will@kernel.org
2022-06-09KVM: arm64: Return error from kvm_arch_init_vm() on allocation failureWill Deacon1-1/+3
If we fail to allocate the 'supported_cpus' cpumask in kvm_arch_init_vm() then be sure to return -ENOMEM instead of success (0) on the failure path. Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220609121223.2551-2-will@kernel.org
2022-06-09USB: serial: io_ti: add Agilent E5805A supportRobert Eckelmann2-0/+3
Add support for Agilent E5805A (rebranded ION Edgeport/4) to io_ti. Signed-off-by: Robert Eckelmann <longnoserob@gmail.com> Link: https://lore.kernel.org/r/20220521230808.30931eca@octoberrain Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
2022-06-09libbpf: Fix uprobe symbol file offset calculation logicAndrii Nakryiko1-41/+22
Fix libbpf's bpf_program__attach_uprobe() logic of determining function's *file offset* (which is what kernel is actually expecting) when attaching uprobe/uretprobe by function name. Previously calculation was determining virtual address offset relative to base load address, which (offset) is not always the same as file offset (though very frequently it is which is why this went unnoticed for a while). Fixes: 433966e3ae04 ("libbpf: Support function name-based attach uprobes") Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Cc: Riham Selim <rihams@fb.com> Cc: Alan Maguire <alan.maguire@oracle.com> Link: https://lore.kernel.org/bpf/20220606220143.3796908-1-andrii@kernel.org
2022-06-09bpf, docs: Fix typo "BFP_ALU" to "BPF_ALU"Kosuke Fujimoto1-1/+1
"BFP" should be "BPF" Signed-off-by: Kosuke Fujimoto <fujimotokosuke0@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20220609083937.245749-1-fujimotoksouke0@gmail.com
2022-06-09bpftool: Fix bootstrapping during a cross compilationShahab Vahedi1-1/+1
This change adjusts the Makefile to use "HOSTAR" as the archive tool to keep the sanity of the build process for the bootstrap part in check. For the rationale, please continue reading. When cross compiling bpftool with buildroot, it leads to an invocation like: $ AR="/path/to/buildroot/host/bin/arc-linux-gcc-ar" \ CC="/path/to/buildroot/host/bin/arc-linux-gcc" \ ... make Which in return fails while building the bootstrap section: ----------------------------------8<---------------------------------- make: Entering directory '/src/bpftool-v6.7.0/src' ... libbfd: [ on ] ... disassembler-four-args: [ on ] ... zlib: [ on ] ... libcap: [ OFF ] ... clang-bpf-co-re: [ on ] <-- triggers bootstrap . . . LINK /src/bpftool-v6.7.0/src/bootstrap/bpftool /usr/bin/ld: /src/bpftool-v6.7.0/src/bootstrap/libbpf/libbpf.a: error adding symbols: archive has no index; run ranlib to add one collect2: error: ld returned 1 exit status make: *** [Makefile:211: /src/bpftool-v6.7.0/src/bootstrap/bpftool] Error 1 make: *** Waiting for unfinished jobs.... AR /src/bpftool-v6.7.0/src/libbpf/libbpf.a make[1]: Leaving directory '/src/bpftool-v6.7.0/libbpf/src' make: Leaving directory '/src/bpftool-v6.7.0/src' ---------------------------------->8---------------------------------- This occurs because setting "AR" confuses the build process for the bootstrap section and it calls "arc-linux-gcc-ar" to create and index "libbpf.a" instead of the host "ar". Signed-off-by: Shahab Vahedi <shahab@synopsys.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Quentin Monnet <quentin@isovalent.com> Cc: Jean-Philippe Brucker <jean-philippe@linaro.org> Link: https://lore.kernel.org/bpf/8d297f0c-cfd0-ef6f-3970-6dddb3d9a87a@synopsys.com
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.