summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
2023-12-19block: remove support for the host aware zone modelChristoph Hellwig
When zones were first added the SCSI and ATA specs, two different models were supported (in addition to the drive managed one that is invisible to the host): - host managed where non-conventional zones there is strict requirement to write at the write pointer, or else an error is returned - host aware where a write point is maintained if writes always happen at it, otherwise it is left in an under-defined state and the sequential write preferred zones behave like conventional zones (probably very badly performing ones, though) Not surprisingly this lukewarm model didn't prove to be very useful and was finally removed from the ZBC and SBC specs (NVMe never implemented it). Due to to the easily disappearing write pointer host software could never rely on the write pointer to actually be useful for say recovery. Fortunately only a few HDD prototypes shipped using this model which never made it to mass production. Drop the support before it is too late. Note that any such host aware prototype HDD can still be used with Linux as we'll now treat it as a conventional HDD. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Link: https://lore.kernel.org/r/20231217165359.604246-4-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-12-19bpf: move subprog call logic back to verifier.cAndrii Nakryiko
Subprog call logic in btf_check_subprog_call() currently has both a lot of BTF parsing logic (which is, presumably, what justified putting it into btf.c), but also a bunch of register state checks, some of each utilize deep verifier logic helpers, necessarily exported from verifier.c: check_ptr_off_reg(), check_func_arg_reg_off(), and check_mem_reg(). Going forward, btf_check_subprog_call() will have a minimum of BTF-related logic, but will get more internal verifier logic related to register state manipulation. So move it into verifier.c to minimize amount of verifier-specific logic exposed to btf.c. We do this move before refactoring btf_check_func_arg_match() to preserve as much history post-refactoring as possible. No functional changes. Acked-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/r/20231215011334.2307144-5-andrii@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2023-12-19bpf: prepare btf_prepare_func_args() for handling static subprogsAndrii Nakryiko
Generalize btf_prepare_func_args() to support both global and static subprogs. We are going to utilize this property in the next patch, reusing btf_prepare_func_args() for subprog call logic instead of reparsing BTF information in a completely separate implementation. btf_prepare_func_args() now detects whether subprog is global or static makes slight logic adjustments for static func cases, like not failing fatally (-EFAULT) for conditions that are allowable for static subprogs. Somewhat subtle (but major!) difference is the handling of pointer arguments. Both global and static functions need to handle special context arguments (which are pointers to predefined type names), but static subprogs give up on any other pointers, falling back to marking subprog as "unreliable", disabling the use of BTF type information altogether. For global functions, though, we are assuming that such pointers to unrecognized types are just pointers to fixed-sized memory region (or error out if size cannot be established, like for `void *` pointers). This patch accommodates these small differences and sets up a stage for refactoring in the next patch, eliminating a separate BTF-based parsing logic in btf_check_func_arg_match(). Acked-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/r/20231215011334.2307144-4-andrii@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2023-12-19bpf: reuse btf_prepare_func_args() check for main program BTF validationAndrii Nakryiko
Instead of btf_check_subprog_arg_match(), use btf_prepare_func_args() logic to validate "trustworthiness" of main BPF program's BTF information, if it is present. We ignored results of original BTF check anyway, often times producing confusing and ominously-sounding "reg type unsupported for arg#0 function" message, which has no apparent effect on program correctness and verification process. All the -EFAULT returning sanity checks are already performed in check_btf_info_early(), so there is zero reason to have this duplication of logic between btf_check_subprog_call() and btf_check_subprog_arg_match(). Dropping btf_check_subprog_arg_match() simplifies btf_check_func_arg_match() further removing `bool processing_call` flag. One subtle bit that was done by btf_check_subprog_arg_match() was potentially marking main program's BTF as unreliable. We do this explicitly now with a dedicated simple check, preserving the original behavior, but now based on well factored btf_prepare_func_args() logic. Acked-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/r/20231215011334.2307144-3-andrii@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2023-12-19bpf: abstract away global subprog arg preparation logic from reg state setupAndrii Nakryiko
btf_prepare_func_args() is used to understand expectations and restrictions on global subprog arguments. But current implementation is hard to extend, as it intermixes BTF-based func prototype parsing and interpretation logic with setting up register state at subprog entry. Worse still, those registers are not completely set up inside btf_prepare_func_args(), requiring some more logic later in do_check_common(). Like calling mark_reg_unknown() and similar initialization operations. This intermixing of BTF interpretation and register state setup is problematic. First, it causes duplication of BTF parsing logic for global subprog verification (to set up initial state of global subprog) and global subprog call sites analysis (when we need to check that whatever is being passed into global subprog matches expectations), performed in btf_check_subprog_call(). Given we want to extend global func argument with tags later, this duplication is problematic. So refactor btf_prepare_func_args() to do only BTF-based func proto and args parsing, returning high-level argument "expectations" only, with no regard to specifics of register state. I.e., if it's a context argument, instead of setting register state to PTR_TO_CTX, we return ARG_PTR_TO_CTX enum for that argument as "an argument specification" for further processing inside do_check_common(). Similarly for SCALAR arguments, PTR_TO_MEM, etc. This allows to reuse btf_prepare_func_args() in following patches at global subprog call site analysis time. It also keeps register setup code consistently in one place, do_check_common(). Besides all this, we cache this argument specs information inside env->subprog_info, eliminating the need to redo these potentially expensive BTF traversals, especially if BPF program's BTF is big and/or there are lots of global subprog calls. Acked-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/r/20231215011334.2307144-2-andrii@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2023-12-19drm/xe: Fix some formatting issues in uAPIFrancois Dugast
Fix spacing, alignment, and repeated words in the documentation. Reported-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Group engine related structsFrancois Dugast
Move the definition of drm_xe_engine_class_instance to group it with other engine related structs and to follow the ioctls order. Reported-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Use SPDX-License-Identifier instead of license textFrancois Dugast
Replace the license text with its SPDX-License-Identifier for quick identification of the license and consistency with the rest of the driver. Reported-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Memory allocations are tile-based, not GT-basedMatt Roper
Since memory and address spaces are a tile concept rather than a GT concept, we need to plumb tile-based handling through lots of memory-related code. Note that one remaining shortcoming here that will need to be addressed before media GT support can be re-enabled is that although the address space is shared between a tile's GTs, each GT caches the PTEs independently in their own TLB and thus TLB invalidation should be handled at the GT level. v2: - Fix kunit test build. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230601215244.678611-13-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Add explicit padding to uAPI definitionChristopher Snowhill
Pad the uAPI definition so that it would align identically between 64-bit and 32-bit uarch, so consumers using this header will work correctly from 32-bit compat userspace on a 64-bit kernel. Do it in a minimally invasive way, so that 64-bit userspace will still work with the previous header, and so that no fields suddenly change sizes. Originally inspired by mlankhorst. Signed-off-by: Christopher Snowhill <kode54@gmail.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Add max engine priority to xe queryJosé Roberto de Souza
Intel Vulkan driver needs to know what is the maximum priority to fill a device info struct for applications. Right now we getting this information by creating a engine and setting priorities from min to high to know what is the maximum priority for running process but this leads to info messages to be printed to dmesg: xe 0000:03:00.0: [drm] Ioctl argument check failed at drivers/gpu/drm/xe/xe_engine.c:178: value == DRM_SCHED_PRIORITY_HIGH && !capable(CAP_SYS_NICE) It does not cause any harm but when executing a test suite like crucible it causes thousands of those messages to be printed. So here adding one more property to drm_xe_query_config to fetch the max engine priority. Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Replace i915 with xe in uapiLucas De Marchi
All structs and defines had already been renamed to "xe", but some comments with "i915" were left over. Rename them. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://lore.kernel.org/r/20230313211628.2492587-1-lucas.demarchi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Update the list of devices to add even more TGL devicesCarlos Santa
The list of GTs got splitted a while back between GT1 and GT2 on TGL. References: https://patchwork.freedesktop.org/patch/388414/ CC: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Carlos Santa <carlos.santa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe/uapi: Add XE_ENGINE_GET_PROPERTY uAPIJosé Roberto de Souza
This is intended to get some properties that are of interest of UMDs like the ban state. Cc: Matthew Brost <matthew.brost@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe/uapi: Rename XE_ENGINE_PROPERTY_X to XE_ENGINE_SET_PROPERTY_XJosé Roberto de Souza
Engine property get uAPI will be added, so to avoid ambiguity here renaming XE_ENGINE_PROPERTY_X to XE_ENGINE_SET_PROPERTY_X. No changes in behavior. Cc: Matthew Brost <matthew.brost@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19clk: fixed-rate: fix clk_hw_register_fixed_rate_with_accuracy_parent_hwThéo Lebrun
Add missing comma and remove extraneous NULL argument. The macro is currently used by no one which explains why the typo slipped by. Fixes: 2d34f09e79c9 ("clk: fixed-rate: Add support for specifying parents via DT/pointers") Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Link: https://lore.kernel.org/r/20231218-mbly-clk-v1-1-44ce54108f06@bootlin.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2023-12-19Merge tag 'md-next-20231219' of ↵Jens Axboe
https://git.kernel.org/pub/scm/linux/kernel/git/song/md into for-6.8/block Pull MD updates from Song: "1. Remove deprecated flavors, by Song Liu; 2. raid1 read error check support, by Li Nan; 3. Better handle events off-by-1 case, by Alex Lyakas." * tag 'md-next-20231219' of https://git.kernel.org/pub/scm/linux/kernel/git/song/md: md: Remove deprecated CONFIG_MD_FAULTY md: Remove deprecated CONFIG_MD_MULTIPATH md: Remove deprecated CONFIG_MD_LINEAR md/raid1: support read error check md: factor out a helper exceed_read_errors() to check read_errors md: Whenassemble the array, consult the superblock of the freshest device md/raid1: remove unnecessary null checking
2023-12-20Merge tag 'drm-msm-next-2023-12-15' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/msm into drm-next Updates for v6.8: Core: - Add support for SDM670, SM8650 - Handle the CFG interconnect to fix the obscure hangs / timeouts on register write - Kconfig fix for QMP dependency - DT schema fixes DPU: - Add support for SDM670, SM8650 - Enable SmartDMA on SM8350 and SM8450 - Correct UBWC settings for SC8280XP - Fix catalog settings for SC8180X - Actually make use of the version to switch between QSEED3/3LITE/4 scalers - Use devres-managed and drm-managed allocations where appropriate - misc other fixes - Enabled YUV writeback on SC7280, SM8250 - Enabled writeback on SM8350, SM8450 - CRC fix when encoder is selected as the input source - other misc fixes MDP4: - Use devres-managed and drm-managed allocations where appropriate - flush vblank event on CRTC disable MDP5: - Use devres-managed and drm-managed allocations where appropriate DP: - Add support for SM8650 - Enable PM runtime support - Merge msm-specific debugfs dir with the generic one - Described DisplayPort on SM8150 in DeviceTree bindings - Moved dp_display_get_next_bridge() to probe() DSI: - Add support for SM8650 - Enable PM runtime support GPU/GEM: - demote userspace triggerable warnings to debug - add GEM object metadata UAPI - move GPU devcoredumps to GPU device - fix hangcheck to skip retired submits - expose UBWC config to userspace - fix a680 chip-id - drm_exec conversion - drm/ci: remove rebase-merge directory (to unblock CI) [airlied: fix drm_exec/amd interaction] Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGs9auYqmo-7NSd9FsbNBCDf7aBevd=4xkcF3A5G_OGvMQ@mail.gmail.com
2023-12-20Merge tag 'amd-drm-next-6.8-2023-12-15' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.8-2023-12-15: amdgpu: - Suspend fixes - Misc code cleanups - JPEG fix - Add AMD specific color management (protected by AMD_PRIVATE_COLOR) - UHBR13.5 cable fixes - Misc display fixes - Display WB fixes - PSR fixes - XGMI fix - ACPI WBRF support for handling potential RF interference from GPU clocks - Enable tunneling on high priority compute queues - drm_edid.h include cleanup - VPE DPM support - SMU 13 fixes - Fix possible double frees in error paths - Misc fixes amdkfd: - Support import and export of dma-bufs using GEM handles - MES shader debugger fixes - SVM fixes radeon: - drm_edid.h include cleanup - Misc code cleanups - Fix possible memory leak in error path drm: - Increase max objects to accomodate new color props - Make replace_property_blob_from_id a DRM helper - Track color management changes per plane platform-x86: - Merge immutable branch from Hans for platform dependencies for WBRF to coordinate merge of WBRF feature across wifi, platform, and GPU Signed-off-by: Dave Airlie <airlied@redhat.com> # -----BEGIN PGP SIGNATURE----- # # iHUEABYKAB0WIQQgO5Idg2tXNTSZAr293/aFa7yZ2AUCZXygTgAKCRC93/aFa7yZ # 2EW1AQCILfGTtDWXzgLSpUBtt9jOooHqaSrah19Cfw0HlA3QIQD+OCohXH1LLZo1 # tYHyfsLv0LsNawI198qABzB1PwptSAI= # =M1AO # -----END PGP SIGNATURE----- # gpg: Signature made Sat 16 Dec 2023 04:51:58 AEST # gpg: using EDDSA key 203B921D836B5735349902BDBDDFF6856BBC99D8 # gpg: Can't check signature: No public key From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231215193519.5040-1-alexander.deucher@amd.com
2023-12-19io_uring: drop any code related to SCM_RIGHTSJens Axboe
This is dead code after we dropped support for passing io_uring fds over SCM_RIGHTS, get rid of it. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-12-19io_uring/unix: drop usage of io_uring socketJens Axboe
Since we no longer allow sending io_uring fds over SCM_RIGHTS, move to using io_is_uring_fops() to detect whether this is a io_uring fd or not. With that done, kill off io_uring_get_socket() as nobody calls it anymore. This is in preparation to yanking out the rest of the core related to unix gc with io_uring. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-12-19Merge branch 'v6.8/vfio/virtio' into v6.8/vfio/nextAlex Williamson
2023-12-19vfio/pci: Expose vfio_pci_core_iowrite/read##size()Yishai Hadas
Expose vfio_pci_core_iowrite/read##size() to let it be used by drivers. This functionality is needed to enable direct access to some physical BAR of the device with the proper locks/checks in place. The next patches from this series will use this functionality on a data path flow when a direct access to the BAR is needed. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Link: https://lore.kernel.org/r/20231219093247.170936-9-yishaih@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2023-12-19vfio/pci: Expose vfio_pci_core_setup_barmap()Yishai Hadas
Expose vfio_pci_core_setup_barmap() to be used by drivers. This will let drivers to mmap a BAR and re-use it from both vfio and the driver when it's applicable. This API will be used in the next patches by the vfio/virtio coming driver. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Link: https://lore.kernel.org/r/20231219093247.170936-8-yishaih@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2023-12-19virtio-pci: Introduce APIs to execute legacy IO admin commandsYishai Hadas
Introduce APIs to execute legacy IO admin commands. It includes: io_legacy_read/write for both common and the device configuration, io_legacy_notify_info. In addition, exposing an API to check whether the legacy IO commands are supported. (i.e. virtio_pci_admin_has_legacy_io()). Those APIs will be used by the next patches from this series. Note: Unlike modern drivers which support hardware virtio devices, legacy drivers assume software-based devices: e.g. they don't use proper memory barriers on ARM, use big endian on PPC, etc. X86 drivers are mostly ok though, more or less by chance. For now, only support legacy IO on X86. Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Link: https://lore.kernel.org/r/20231219093247.170936-7-yishaih@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2023-12-19virtio-pci: Introduce admin commandsFeng Liu
Introduces admin commands, as follow: The "list query" command can be used by the driver to query the set of admin commands supported by the virtio device. The "list use" command is used to inform the virtio device which admin commands the driver will use. The "legacy common cfg rd/wr" commands are used to read from/write into the legacy common configuration structure. The "legacy dev cfg rd/wr" commands are used to read from/write into the legacy device configuration structure. The "notify info" command is used to query the notification region information. Signed-off-by: Feng Liu <feliu@nvidia.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Link: https://lore.kernel.org/r/20231219093247.170936-5-yishaih@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2023-12-19virtio-pci: Introduce admin command sending functionFeng Liu
Add support for sending admin command through admin virtqueue interface. Abort any inflight admin commands once device reset completes. Activate admin queue when device becomes ready; deactivate on device reset. To comply to the below specification statement [1], the admin virtqueue is activated for upper layer users only after setting DRIVER_OK status. [1] The driver MUST NOT send any buffer available notifications to the device before setting DRIVER_OK. Signed-off-by: Feng Liu <feliu@nvidia.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Link: https://lore.kernel.org/r/20231219093247.170936-4-yishaih@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2023-12-19virtio-pci: Introduce admin virtqueueFeng Liu
Introduce support for the admin virtqueue. By negotiating VIRTIO_F_ADMIN_VQ feature, driver detects capability and creates one administration virtqueue. Administration virtqueue implementation in virtio pci generic layer, enables multiple types of upper layer drivers such as vfio, net, blk to utilize it. Signed-off-by: Feng Liu <feliu@nvidia.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Link: https://lore.kernel.org/r/20231219093247.170936-3-yishaih@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2023-12-19virtio: Define feature bit for administration virtqueueFeng Liu
Introduce VIRTIO_F_ADMIN_VQ which is used for administration virtqueue support. Signed-off-by: Feng Liu <feliu@nvidia.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Link: https://lore.kernel.org/r/20231219093247.170936-2-yishaih@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2023-12-19md: Remove deprecated CONFIG_MD_FAULTYSong Liu
md-faulty has been marked as deprecated for 2.5 years. Remove it. Cc: Christoph Hellwig <hch@lst.de> Cc: Jens Axboe <axboe@kernel.dk> Cc: Neil Brown <neilb@suse.de> Cc: Guoqing Jiang <guoqing.jiang@linux.dev> Cc: Mateusz Grzonka <mateusz.grzonka@intel.com> Cc: Jes Sorensen <jes@trained-monkey.org> Signed-off-by: Song Liu <song@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hannes Reinecke <hare@suse.de> Link: https://lore.kernel.org/r/20231214222107.2016042-4-song@kernel.org
2023-12-19md: Remove deprecated CONFIG_MD_MULTIPATHSong Liu
md-multipath has been marked as deprecated for 2.5 years. Remove it. Cc: Christoph Hellwig <hch@lst.de> Cc: Jens Axboe <axboe@kernel.dk> Cc: Neil Brown <neilb@suse.de> Cc: Guoqing Jiang <guoqing.jiang@linux.dev> Cc: Mateusz Grzonka <mateusz.grzonka@intel.com> Cc: Jes Sorensen <jes@trained-monkey.org> Signed-off-by: Song Liu <song@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hannes Reinecke <hare@suse.de> Link: https://lore.kernel.org/r/20231214222107.2016042-3-song@kernel.org
2023-12-19md: Remove deprecated CONFIG_MD_LINEARSong Liu
md-linear has been marked as deprecated for 2.5 years. Remove it. Cc: Christoph Hellwig <hch@lst.de> Cc: Jens Axboe <axboe@kernel.dk> Cc: Neil Brown <neilb@suse.de> Cc: Guoqing Jiang <guoqing.jiang@linux.dev> Cc: Mateusz Grzonka <mateusz.grzonka@intel.com> Cc: Jes Sorensen <jes@trained-monkey.org> Signed-off-by: Song Liu <song@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hannes Reinecke <hare@suse.de> Link: https://lore.kernel.org/r/20231214222107.2016042-2-song@kernel.org
2023-12-19Merge tag 'for-netdev' of ↵Paolo Abeni
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next Daniel Borkmann says: ==================== pull-request: bpf-next 2023-12-19 Hi David, hi Jakub, hi Paolo, hi Eric, The following pull-request contains BPF updates for your *net-next* tree. We've added 2 non-merge commits during the last 1 day(s) which contain a total of 40 files changed, 642 insertions(+), 2926 deletions(-). The main changes are: 1) Revert all of BPF token-related patches for now as per list discussion [0], from Andrii Nakryiko. [0] https://lore.kernel.org/bpf/CAHk-=wg7JuFYwGy=GOMbRCtOL+jwSQsdUaBsRWkDVYbxipbM5A@mail.gmail.com 2) Fix a syzbot-reported use-after-free read in nla_find() triggered from bpf_skb_get_nlattr_nest() helper, from Jakub Kicinski. bpf-next-for-netdev * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: Revert BPF token-related functionality bpf: Use nla_ok() instead of checking nla_len directly ==================== Link: https://lore.kernel.org/r/20231219170359.11035-1-daniel@iogearbox.net Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-12-19ACPI: utils: Introduce helper for _DEP list lookupRafael J. Wysocki
The ACPI LPSS driver and the Surface platform driver code use almost the same code pattern for checking if one ACPI device is present in the list returned by _DEP for another ACPI device. To reduce the resulting code duplication, introduce a helper for that called acpi_device_dep() and invoke it from both places. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-12-19wifi: cfg80211: introduce cfg80211_ssid_eq()Dmitry Antipov
Since SSIDs comparison is commonly used across many drivers, introduce generic 'cfg80211_ssid_eq()' to replace driver-private implementations. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Link: https://msgid.link/20231215123859.196350-1-dmantipov@yandex.ru [fix kernel-doc return docs] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-12-19Revert BPF token-related functionalityAndrii Nakryiko
This patch includes the following revert (one conflicting BPF FS patch and three token patch sets, represented by merge commits): - revert 0f5d5454c723 "Merge branch 'bpf-fs-mount-options-parsing-follow-ups'"; - revert 750e785796bb "bpf: Support uid and gid when mounting bpffs"; - revert 733763285acf "Merge branch 'bpf-token-support-in-libbpf-s-bpf-object'"; - revert c35919dcce28 "Merge branch 'bpf-token-and-bpf-fs-based-delegation'". Link: https://lore.kernel.org/bpf/CAHk-=wg7JuFYwGy=GOMbRCtOL+jwSQsdUaBsRWkDVYbxipbM5A@mail.gmail.com Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
2023-12-19regulator: Reuse LINEAR_RANGE() in REGULATOR_LINEAR_RANGE()Andy Shevchenko
REGULATOR_LINEAR_RANGE() repeats what LINEAR_RANGE() provides. Deduplicate the former by using the latter. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://msgid.link/r/20231219154012.2478688-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-12-19devlink: add a command to set notification filter and use it for multicastsJiri Pirko
Currently the user listening on a socket for devlink notifications gets always all messages for all existing instances, even if he is interested only in one of those. That may cause unnecessary overhead on setups with thousands of instances present. User is currently able to narrow down the devlink objects replies to dump commands by specifying select attributes. Allow similar approach for notifications. Introduce a new devlink NOTIFY_FILTER_SET which the user passes the select attributes. Store these per-socket and use them for filtering messages during multicast send. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-12-19genetlink: introduce helpers to do filtered multicastJiri Pirko
Currently it is possible for netlink kernel user to pass custom filter function to broadcast send function netlink_broadcast_filtered(). However, this is not exposed to multicast send and to generic netlink users. Extend the api and introduce a netlink helper nlmsg_multicast_filtered() and a generic netlink helper genlmsg_multicast_netns_filtered() to allow generic netlink families to specify filter function while sending multicast messages. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-12-19netlink: introduce typedef for filter functionJiri Pirko
Make the code using filter function a bit nicer by consolidating the filter function arguments using typedef. Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-12-19genetlink: introduce per-sock family private storageJiri Pirko
Introduce an xarray for Generic netlink family to store per-socket private. Initialize this xarray only if family uses per-socket privs. Introduce genl_sk_priv_get() to get the socket priv pointer for a family and initialize it in case it does not exist. Introduce __genl_sk_priv_get() to obtain socket priv pointer for a family under RCU read lock. Allow family to specify the priv size, init() and destroy() callbacks. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-12-19drm: using mul_u32_u32() requires linux/math64.hStephen Rothwell
Some pending include file cleanups produced this error: In file included from include/linux/kernel.h:27, from drivers/gpu/ipu-v3/ipu-dp.c:7: include/drm/drm_color_mgmt.h: In function 'drm_color_lut_extract': include/drm/drm_color_mgmt.h:45:46: error: implicit declaration of function 'mul_u32_u32' [-Werror=implicit-function-declaration] 45 | return DIV_ROUND_CLOSEST_ULL(mul_u32_u32(user_input, (1 << bit_precision) - 1), | ^~~~~~~~~~~ Fixes: c6fbb6bca108 ("drm: Fix color LUT rounding") Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231219145734.13e40e1e@canb.auug.org.au
2023-12-19ASoC: soc.h: don't create dummy Component via COMP_DUMMY()Kuninori Morimoto
Many ASoC drivers define CPU/Codec/Platform dai_link by below macro. SND_SOC_DAILINK_DEFS(link, (A) DAILINK_COMP_ARRAY(COMP_CPU("cpu_dai")), (B) DAILINK_COMP_ARRAY(COMP_CODEC("codec", "dai1"), (B) COMP_CODEC("codec", "dai2")), (C) DAILINK_COMP_ARRAY(COMP_EMPTY())); In this case, this macro will be converted to like below [o] = static struct snd_soc_dai_link_component (A) [o] link_cpus[] = {{ .dai_name = "cpu_dai" }}; (B) [o] link_codecs[] = {{ .dai_name = "dai1", .name = "codec" }, { .dai_name = "dai2", .name = "codec" }} (C) [o] link_platforms[] = {{ }}; CPU and Codec info will be filled by COMP_CPU() / COMP_CODEC (= A,B), and Platform will have empty data by COMP_EMPTY() (= C) in this case. Platform empty info will be filled when driver probe() (most of case, CPU info will be copied to use soc-generic-dmaengine-pcm). For example in case of DPCM FE/BE, it will be like below. Codec will be dummy Component / DAI in this case (X). SND_SOC_DAILINK_DEFS(link, DAILINK_COMP_ARRAY(COMP_CPU(...)), (X) DAILINK_COMP_ARRAY(COMP_DUMMY()), DAILINK_COMP_ARRAY(COMP_EMPTY())); (X) part will converted like below [o] link_codecs[] = {{ .name = "snd-soc-dummy", .dai_name = "snd-soc-dummy-dai", }} Even though we already have common asoc_dummy_dlc for dummy Component / DAI, this macro will re-create new dummy dlc. Some drivers defines many dai_link info via SND_SOC_DAILINK_DEFS(), this means many dummy dlc also will be re-created. This is waste of memory. If we can use existing common asoc_dummy_dlc at (X), we can avoid to re-creating dummy dlc, then, we can save the memory. At that time, we want to keep existing code as much as possible, because too many drivers are using this macro. But because of its original style, using common asoc_dummy_dlc from it is very difficult or impossible. So let's change the mind. The macro is used like below SND_SOC_DAILINK_DEFS(link, DAILINK_COMP_ARRAY(COMP_CPU(...)), (x) DAILINK_COMP_ARRAY(COMP_DUMMY()), DAILINK_COMP_ARRAY(COMP_EMPTY())); static struct snd_soc_dai_link dai_links[] = { { .name = ..., .stream_name = ..., (y) SND_SOC_DAILINK_REG(link), }, (y) part will be like below static struct snd_soc_dai_link dai_links[] = { { .name = ..., .stream_name = ..., ^ ... | .codecs = link_codecs, (y) .num_codecs = ARRAY_SIZE(link_codecs), v ... } This patch try to use trick on COMP_DUMMY() - #define COMP_DUMMY() { .name = "snd-soc-dummy", .dai_name = "snd-soc-dummy-dai", } + #define COMP_DUMMY() By this tric, (x) part will be like below. before [o] link_codecs[] = {{ .name = "snd-soc-dummy", .dai_name = "snd-soc-dummy-dai", }} after [o] link_codecs[] = { }; This is same as below [o] link_codecs[0]; This means it has pointer (link_codecs), but the array size is 0. (y) part will be like below. static struct snd_soc_dai_link dai_links[] = { { ... .codecs = link_codecs, .num_codecs = 0, ... }, This is very special settings that normal use usually not do, but new macro do. We can find this special settings on soc-core.c and fill it as "dummy DAI" (= asoc_dummy_dlc). By this tric, we can avoid to re-create dummy dlc and save the memory. This patch add tric at COMP_DUMMY() and add snd_soc_fill_dummy_dai() to fill dummy DAI. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://msgid.link/r/871qbi93qu.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-12-19accel/habanalabs/gaudi2: add signed dev info uAPIMoti Haimovski
User will provide a nonce via the INFO ioctl, and will retrieve the signed device info generated using given nonce. Signed-off-by: Moti Haimovski <mhaimovski@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
2023-12-19Merge tag 'mhi-for-v6.8' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/mani/mhi into char-misc-next Manivannan writes: MHI Host ======== - Added alignment check for event ring read pointer to avoid the potential buffer corruption issue. - Added support for SDX75 modem which takes longer time to enter READY state. - Added spinlock to protect concurrent access while queuing transfer ring elements. - Dropped the read channel lock before invoking the client callback as the client can potentially queue buffers thus ending up wtih soft lockup. MHI Endpoint ============ - Used kzalloc() to allocate event ring elements instead of allocating the elements on the stack, as the endpoint controller trying to queue them may not be able to use vmalloc memory (using DMA). - Used slab allocator for allocting the memory for objects used frequently and are of fixed size. - Added support for interrupt moderation timer feature which is used by the host to limit the number of interrupts raised by the device for an event ring. - Added async read/write DMA support for transferring data between host and the endpoint. So far MHI EP stack assumed that the data will be transferred synchronously (i.e., it sends completion once the transfer APIs are returned). But this impacts the throughput if the controller is using DMA to do the transfer. So to add async suport, existing sync transfer APIs are renamed to {read/write}_sync and also introduced two new APIs {read/write}_async for carrying out the async transfer. Controllers implementing the async APIs should queue the buffers and return immediately without waiting for transfer completion. Once the transfer completion happens later, they should invoke the completion callback so that the MHI EP stack can send the completion event to the host. The controller driver patches (PCI EPF) for this async support are also merged to the MHI tree with Acks from PCI maintainers. - Fixed the DMA channel direction in error path of the PCI EPF driver. * tag 'mhi-for-v6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/mani/mhi: bus: mhi: host: Drop chan lock before queuing buffers bus: mhi: host: Add spinlock to protect WP access when queueing TREs PCI: epf-mhi: Fix the DMA data direction of dma_unmap_single() bus: mhi: ep: Add checks for read/write callbacks while registering controllers bus: mhi: ep: Add support for async DMA read operation bus: mhi: ep: Add support for async DMA write operation PCI: epf-mhi: Enable MHI async read/write support PCI: epf-mhi: Add support for DMA async read/write operation PCI: epf-mhi: Simulate async read/write using iATU bus: mhi: ep: Introduce async read/write callbacks bus: mhi: ep: Rename read_from_host() and write_to_host() APIs bus: mhi: ep: Pass mhi_ep_buf_info struct to read/write APIs bus: mhi: ep: Add support for interrupt moderation timer bus: mhi: ep: Use slab allocator where applicable bus: mhi: host: Add alignment check for event ring read pointer bus: mhi: host: pci_generic: Add SDX75 based modem support bus: mhi: host: Add a separate timeout parameter for waiting ready bus: mhi: ep: Do not allocate event ring element on stack
2023-12-19Revert "iio: hid-sensor-als: Add light color temperature support"Srinivas Pandruvada
This reverts commit 5f05285df691b1e82108eead7165feae238c95ef. This commit assumes that every HID descriptor for ALS sensor has presence of usage id ID HID_USAGE_SENSOR_LIGHT_COLOR_TEMPERATURE. When the above usage id is absent, driver probe fails. This breaks ALS sensor functionality on many platforms. Till we have a good solution, revert this commit. Reported-by: Thomas Weißschuh <thomas@t-8ch.de> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218223 Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: <stable@vger.kernel.org> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20231217200703.719876-3-srinivas.pandruvada@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-19Revert "iio: hid-sensor-als: Add light chromaticity support"Srinivas Pandruvada
This reverts commit ee3710f39f9d0ae5137a866138d005fe1ad18132. This commit assumes that every HID descriptor for ALS sensor has presence of usage id ID HID_USAGE_SENSOR_LIGHT_CHROMATICITY_X and HID_USAGE_SENSOR_LIGHT_CHROMATICITY_Y. When the above usage ids are absent, driver probe fails. This breaks ALS sensor functionality on many platforms. Till we have a good solution, revert this commit. Reported-by: Thomas Weißschuh <thomas@t-8ch.de> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218223 Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: <stable@vger.kernel.org> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20231217200703.719876-2-srinivas.pandruvada@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-19Merge tag 'drm-misc-next-2023-12-14' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for $kernel-version: UAPI Changes: Cross-subsystem Changes: - A few fixes for usb/typec Core Changes: - ci: Updates to the defconfig, igt version, etc. - writeback: Move the atomic_check helper from the encoder to connector Driver Changes: - rockchip: Add support for rk3588 - xe: Update the TODO list - panel: - nv3052c: Register documentation, init sequence improvements and support for the Fascontek FS035VG158 - st7701: Add support for the Anbernic RG-ARC - new driver: Synaptics R63353 panel controller, Ilitek ILI9805 panel controller - new panel: AUO G156HAN04.0 Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/aqpn5miejmkks7pbcfex7b6u63uwsruywxsnr3x5ljs45qatin@nbkkej2elk46
2023-12-18trace_seq: Increase the buffer size to almost two pagesSteven Rostedt (Google)
Now that trace_marker can hold more than 1KB string, and can write as much as the ring buffer can hold, the trace_seq is not big enough to hold writes: ~# a="1234567890" ~# cnt=4080 ~# s="" ~# while [ $cnt -gt 10 ]; do ~# s="${s}${a}" ~# cnt=$((cnt-10)) ~# done ~# echo $s > trace_marker ~# cat trace # tracer: nop # # entries-in-buffer/entries-written: 2/2 #P:8 # # _-----=> irqs-off/BH-disabled # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / _-=> migrate-disable # |||| / delay # TASK-PID CPU# ||||| TIMESTAMP FUNCTION # | | | ||||| | | <...>-860 [002] ..... 105.543465: tracing_mark_write[LINE TOO BIG] <...>-860 [002] ..... 105.543496: tracing_mark_write: 789012345678901234567890 By increasing the trace_seq buffer to almost two pages, it can now print out the first line. This also subtracts the rest of the trace_seq fields from the buffer, so that the entire trace_seq is now PAGE_SIZE aligned. Link: https://lore.kernel.org/linux-trace-kernel/20231209175220.19867af4@gandalf.local.home Cc: Mark Rutland <mark.rutland@arm.com> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2023-12-18tracing: Allow for max buffer data size trace_marker writesSteven Rostedt (Google)
Allow a trace write to be as big as the ring buffer tracing data will allow. Currently, it only allows writes of 1KB in size, but there's no reason that it cannot allow what the ring buffer can hold. Link: https://lore.kernel.org/linux-trace-kernel/20231212131901.5f501e72@gandalf.local.home Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
generated by cgit (git 2.34.1) at 2025-09-14 18:48:09 +0000