aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2022-09-06ice: add helper function to check FW API versionPaul Greenwalt1-28/+29
Several functions in ice_common.c check the firmware API version to see if the current API version meets some minimum requirement. Improve the readability of these checks by introducing ice_is_fw_api_min_ver, a helper function to perform that check. Signed-off-by: Paul Greenwalt <paul.greenwalt@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-09-06ice: Check if reset in progress while waiting for offsetsMichal Michalik1-0/+3
Occasionally while waiting to valid offsets from hardware we get reset. Add check for reset before proceeding to execute scheduled work. Co-developed-by: Karol Kolacinski <karol.kolacinski@intel.com> Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com> Signed-off-by: Michal Michalik <michal.michalik@intel.com> Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-09-06ice: Allow operation with reduced device MSI-XTony Nguyen1-81/+96
The driver currently takes an all or nothing approach for device MSI-X vectors. Meaning if it does not get its full allocation, it will fail and not load. There is no reason it can't work with a reduced number of MSI-X vectors. Take a similar approach as commit 741106f7bd8d ("ice: Improve MSI-X fallback logic") and, instead, adjust the MSI-X request to make use of what is available. Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Petr Oros <poros@redhat.com> Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
2022-09-06i40e: add description and modify interrupts configuration procedureJaroslaw Gawin2-21/+27
Add description for values written into registers QINT_XXXX and small cosmetic changes for MSI/LEGACY interrupts configuration in the same way as for MSI-X. Descriptions confirm the code is written correctly and make the code clear. Small cosmetic changes for MSI/LEGACY interrupts make code clear in the same manner as for MSI-X interrupts. Signed-off-by: Jaroslaw Gawin <jaroslawx.gawin@intel.com> Signed-off-by: Andrii Staikov <andrii.staikov@intel.com> Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-09-06drm/i915: Don't try to disable host RPS when this was never enabled.Rodrigo Vivi1-0/+3
Specially in GT reset case this could be triggered and try to disable things that had never been enabled. Let's add some protection here. Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220902095126.373036-1-rodrigo.vivi@intel.com
2022-09-06Bluetooth: hci_sync: Fix hci_read_buffer_size_syncLuiz Augusto von Dentz1-6/+6
hci_read_buffer_size_sync shall not use HCI_OP_LE_READ_BUFFER_SIZE_V2 sinze that is LE specific, instead it is hci_le_read_buffer_size_sync version that shall use it. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216382 Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2022-09-06Bluetooth: Add experimental wrapper for MGMT based meshBrian Gix2-8/+105
This introduces a "Mesh UUID" and an Experimental Feature bit to the hdev mask, and depending all underlying Mesh functionality on it. Signed-off-by: Brian Gix <brian.gix@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2022-09-06Bluetooth: Implement support for MeshBrian Gix11-46/+760
The patch adds state bits, storage and HCI command chains for sending and receiving Bluetooth Mesh advertising packets, and delivery to requesting user space processes. It specifically creates 4 new MGMT commands and 2 new MGMT events: MGMT_OP_SET_MESH_RECEIVER - Sets passive scan parameters and a list of AD Types which will trigger Mesh Packet Received events MGMT_OP_MESH_READ_FEATURES - Returns information on how many outbound Mesh packets can be simultaneously queued, and what the currently queued handles are. MGMT_OP_MESH_SEND - Command to queue a specific outbound Mesh packet, with the number of times it should be sent, and the BD Addr to use. Discrete advertisments are added to the ADV Instance list. MGMT_OP_MESH_SEND_CANCEL - Command to cancel a prior outbound message request. MGMT_EV_MESH_DEVICE_FOUND - Event to deliver entire received Mesh Advertisement packet, along with timing information. MGMT_EV_MESH_PACKET_CMPLT - Event to indicate that an outbound packet is no longer queued for delivery. Signed-off-by: Brian Gix <brian.gix@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2022-09-06coresight: cti-sysfs: Mark coresight_cti_reg_store() as __maybe_unusedNathan Chancellor1-3/+3
When building without CONFIG_CORESIGHT_CTI_INTEGRATION_REGS, there is a warning about coresight_cti_reg_store() being unused in the file: drivers/hwtracing/coresight/coresight-cti-sysfs.c:184:16: warning: 'coresight_cti_reg_store' defined but not used [-Wunused-function] 184 | static ssize_t coresight_cti_reg_store(struct device *dev, | ^~~~~~~~~~~~~~~~~~~~~~~ This is expected as coresight_cti_reg_store() is only used in the coresight_cti_reg_rw macro, which is only used in a block guarded by CONFIG_CORESIGHT_CTI_INTEGRATION_REGS. Mark coresight_cti_reg_store() as __maybe_unused to clearly indicate that the function may be unused depending on the configuration. Fixes: fbca79e55429 ("coresight: cti-sysfs: Re-use same functions for similar sysfs register accessors") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: James Clark <james.clark@arm.com> Link: https://lore.kernel.org/r/20220901195055.1932340-1-nathan@kernel.org Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2022-09-06drm/scheduler: quieten kernel-doc warningsRandy Dunlap2-5/+7
Fix kernel-doc warnings in gpu_scheduler.h and sched_main.c. Quashes these warnings: include/drm/gpu_scheduler.h:332: warning: missing initial short description on line: * struct drm_sched_backend_ops include/drm/gpu_scheduler.h:412: warning: missing initial short description on line: * struct drm_gpu_scheduler include/drm/gpu_scheduler.h:461: warning: Function parameter or member 'dev' not described in 'drm_gpu_scheduler' drivers/gpu/drm/scheduler/sched_main.c:201: warning: missing initial short description on line: * drm_sched_dependency_optimized drivers/gpu/drm/scheduler/sched_main.c:995: warning: Function parameter or member 'dev' not described in 'drm_sched_init' Fixes: 2d33948e4e00 ("drm/scheduler: add documentation") Fixes: 8ab62eda177b ("drm/sched: Add device pointer to drm_gpu_scheduler") Fixes: 542cff7893a3 ("drm/sched: Avoid lockdep spalt on killing a processes") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Cc: Nayan Deshmukh <nayan26deshmukh@gmail.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Jiawei Gu <Jiawei.Gu@amd.com> Cc: dri-devel@lists.freedesktop.org Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220404213040.12912-1-rdunlap@infradead.org
2022-09-06i40e: Add basic support for I710 devicesStanislaw Grzeszczak3-1/+7
Intel introduces a new line of 1G ethernet adapters with Device ID 0x0DD2 Signed-off-by: Stanislaw Grzeszczak <stanislaw.a.grzeszczak@intel.com> Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com> Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-09-06cgroup: Remove CFTYPE_PRESSURETejun Heo2-27/+36
CFTYPE_PRESSURE is used to flag PSI related files so that they are not created if PSI is disabled during boot. It's a bit weird to use a generic flag to mark a specific file type. Let's instead move the PSI files into its own cftypes array and add/rm them conditionally. This is a bit more code but cleaner. No userland visible changes. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Johannes Weiner <hannes@cmpxchg.org>
2022-09-06cgroup: Improve cftype add/rm error handlingTejun Heo2-7/+21
Let's track whether a cftype is currently added or not using a new flag __CFTYPE_ADDED so that duplicate operations can be failed safely and consistently allow using empty cftypes. Signed-off-by: Tejun Heo <tj@kernel.org>
2022-09-06Merge tag 'erofs-for-6.0-rc5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofsLinus Torvalds3-39/+14
Pull erofs fixes from Gao Xiang: - Fix return codes in erofs_fscache_{meta_,}read_folio error paths - Fix potential wrong pcluster sizes for later non-4K lclusters - Fix in-memory pcluster use-after-free on UP platforms * tag 'erofs-for-6.0-rc5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs: erofs: fix pcluster use-after-free on UP platforms erofs: avoid the potentially wrong m_plen for big pcluster erofs: fix error return code in erofs_fscache_{meta_,}read_folio
2022-09-06drm/i915: consider HAS_FLAT_CCS() in needs_ccs_pagesMatthew Auld2-1/+4
Just move the HAS_FLAT_CCS() check into needs_ccs_pages. This also then fixes i915_ttm_memcpy_allowed() which was incorrectly reporting true on DG1, even though it doesn't have small-BAR or flat-CCS. References: https://gitlab.freedesktop.org/drm/intel/-/issues/6605 Fixes: efeb3caf4341 ("drm/i915/ttm: disallow CPU fallback mode for ccs pages") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220905105329.41455-1-matthew.auld@intel.com (cherry picked from commit 873fef8833ea794526b7f4179088e565078fe0e8) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2022-09-06drm/i915: Implement WaEdpLinkRateDataReloadVille Syrjälä1-0/+22
A lot of modern laptops use the Parade PS8461E MUX for eDP switching. The MUX can operate in jitter cleaning mode or redriver mode, the first one resulting in higher link quality. The jitter cleaning mode needs to know the link rate used and the MUX achieves this by snooping the LINK_BW_SET, LINK_RATE_SELECT and SUPPORTED_LINK_RATES DPCD accesses. When the MUX is powered down (seems this can happen whenever the display is turned off) it loses track of the snooped link rates so when we do the LINK_RATE_SELECT write it no longer knowns which link rate we're selecting, and thus it falls back to the lower quality redriver mode. This results in unstable high link rates (eg. usually 8.1Gbps link rate no longer works correctly). In order to avoid all that let's re-snoop SUPPORTED_LINK_RATES from the sink at the start of every link training. Unfortunately we don't have a way to detect the presence of the MUX. It looks like the set of laptops equipped with this MUX is fairly large and contains devices from multiple manufacturers. It may also still be growing with new models. So a quirk doesn't seem like a very easily maintainable option, thus we shall attempt to do this unconditionally on all machines that use LINK_RATE_SELECT. Hopefully this extra DPCD read doesn't cause issues for any unaffected machine. If that turns out to be the case we'll need to convert this into a quirk in the future. Cc: stable@vger.kernel.org Cc: Jason A. Donenfeld <Jason@zx2c4.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6205 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220902070319.15395-1-ville.syrjala@linux.intel.com Tested-by: Aaron Ma <aaron.ma@canonical.com> Tested-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 25899c590cb5ba9b9f284c6ca8e7e9086793d641) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2022-09-06drm/i915/slpc: Let's fix the PCODE min freq table setup for SLPCRodrigo Vivi3-10/+61
We need to inform PCODE of a desired ring frequencies so PCODE update the memory frequencies to us. rps->min_freq and rps->max_freq are the frequencies used in that request. However they were unset when SLPC was enabled and PCODE never updated the memory freq. v2 (as Suggested by Ashutosh): if SLPC is in use, let's pick the right frequencies from the get_ia_constants instead of the fake init of rps' min and max. v3: don't forget the max <= min return v4: Move all the freq conversion to intel_rps.c. And the max <= min check to where it belongs. v5: (Ashutosh) Fix old comment s/50 HZ/50 MHz and add a doc explaining the "raw format" Fixes: 7ba79a671568 ("drm/i915/guc/slpc: Gate Host RPS when SLPC is enabled") Cc: <stable@vger.kernel.org> # v5.15+ Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Tested-by: Sushma Venkatesh Reddy <sushma.venkatesh.reddy@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220831214538.143950-1-rodrigo.vivi@intel.com (cherry picked from commit 018a7bdbb090b9155a6509a0d1a684db4afaa5b1) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2022-09-06drm/i915/bios: Copy the whole MIPI sequence blockVille Syrjälä1-0/+7
Turns out the MIPI sequence block version number and new block size fields are considered part of the block header and are not included in the reported new block size field itself. Bump up the block size appropriately so that we'll copy over the last five bytes of the block as well. For this particular machine those last five bytes included parts of the GPIO op for the backlight on sequence, causing the backlight no longer to turn back on: Sequence 6 - MIPI_SEQ_BACKLIGHT_ON Delay: 20000 us - GPIO index 0, number 0, set 0 (0x00) + GPIO index 1, number 70, set 1 (0x01) Cc: stable@vger.kernel.org Fixes: e163cfb4c96d ("drm/i915/bios: Make copies of VBT data blocks") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6652 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220829135834.8585-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit a06289f3f72431f3777af95ea1226b5b0abdc426) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2022-09-06Input: xpad - add support for XBOX One Elite paddlesChristopher Crockett1-60/+192
An effort has been made to support every official model and firmware version I could track down info on. The following controllers _should_ have working paddles with this PR: - Xbox Elite (**untested**) - Xbox Elite Series 2 on early firmwares (**untested**) - Xbox Elite Series 2 on v4 firmwares (Tested v4.8.1908.0) - Xbox Elite Series 2 on v5 pre-BLE firmwares (**untested**) - Xbox Elite Series 2 on v5 post-BLE firmwares (Tested v5.13.3143.0) This patch also introduces correct handling for the Elite 1 controller and properly suppresses paddle inputs when using a custom profile slot. Starting with firmware v5.11, certain inputs for the Elite 2 were moved to an extra packet that is not enabled by default. We must first manually enable this extra packet in order to correctly process paddle input data with these later firmwares. Signed-off-by: Christopher Crockett <chaorace@gmail.com> Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com> Tested-by: Bastien Nocera <hadess@hadess.net> Link: https://lore.kernel.org/r/20220818154411.510308-5-rojtberg@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-09-06Input: xpad - Poweroff XBOX360W on mode button long pressSantosh De Massari1-0/+24
Newer gamepads turn themselves off when the mode button is held down. For XBOX360W gamepads we must do this in the driver. Do not use BIT() macro for consistency within the file. Signed-off-by: Santosh De Massari <s.demassari@gmail.com> Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com> Link: https://lore.kernel.org/r/20220818154411.510308-4-rojtberg@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-09-06Input: xpad - fix wireless 360 controller breaking after suspendCameron Gutman1-1/+0
Suspending and resuming the system can sometimes cause the out URB to get hung after a reset_resume. This causes LED setting and force feedback to break on resume. To avoid this, just drop the reset_resume callback so the USB core rebinds xpad to the wireless pads on resume if a reset happened. A nice side effect of this change is the LED ring on wireless controllers is now set correctly on system resume. Cc: stable@vger.kernel.org Fixes: 4220f7db1e42 ("Input: xpad - workaround dead irq_out after suspend/ resume") Signed-off-by: Cameron Gutman <aicommander@gmail.com> Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com> Link: https://lore.kernel.org/r/20220818154411.510308-3-rojtberg@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-09-06Input: xpad - add supported devices as contributed on githubPavel Rojtberg1-0/+19
This is based on multiple commits at https://github.com/paroj/xpad Cc: stable@vger.kernel.org Signed-off-by: Jasper Poppe <jgpoppe@gmail.com> Signed-off-by: Jeremy Palmer <jpalmer@linz.govt.nz> Signed-off-by: Ruineka <ruinairas1992@gmail.com> Signed-off-by: Cleber de Mattos Casali <clebercasali@gmail.com> Signed-off-by: Kyle Gospodnetich <me@kylegospodneti.ch> Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com> Link: https://lore.kernel.org/r/20220818154411.510308-2-rojtberg@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2022-09-06arm64/sysreg: Add hwcap for SVE EBF16Mark Brown5-0/+7
SVE has a separate identification register indicating support for BFloat16 operations. Add a hwcap identifying support for EBF16 in this register, mirroring what we did for the non-SVE case. While there is currently an architectural requirement for BF16 support to be the same in SVE and non-SVE contexts there are separate identification registers this separate hwcap helps avoid issues if that requirement were to be relaxed in the future, we have already chosen to have a separate capability for base BF16 support. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220829154815.832347-1-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-09-06arm64/sve: Document our actual ABI for clearing registers on syscallMark Brown1-1/+1
Currently our ABI documentation says that the state of the bits in the Z registers not shared with the V registers becomes undefined on syscall but our actual implementation unconditionally clears these bits. Taking advantage of the flexibility of our documented ABI would be a change in the observable ABI so there is concern around doing so, instead document the actual behaviour so that it is more discoverable for userspace programmers who might be able to take advantage of it and to record our decision about not changing the kernel ABI. This makes qemu's user mode implementation buggy since it does not clear these bits. Signed-off-by: Mark Brown <broonie@kernel.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20220829162502.886816-3-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-09-06kselftest/arm64: Count SIGUSR2 deliveries in FP stress testsMark Brown4-0/+46
Currently the floating point stress tests mostly support testing that the data they are checking can be disrupted from a signal handler triggered by SIGUSR1. This is not properly implemented for all the tests and in testing is frequently modified to just handle the signal without corrupting data in order to ensure that signal handling does not corrupt data. Directly support this usage by installing a SIGUSR2 handler which simply counts the signal delivery. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220829154452.824870-3-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-09-06kselftest/arm64: Always encourage preemption for za-testMark Brown1-6/+1
Since we now have an explicit test for the syscall ABI there is no need for za-test to cover getpid() so just unconditionally do sched_yield() like we do in fpsimd-test. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220829154452.824870-2-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-09-06kselftest/arm64: Add simple hwcap validationMark Brown3-1/+190
Add some trivial hwcap validation which checks that /proc/cpuinfo and AT_HWCAP agree with each other and can verify that for extensions that can generate a SIGILL due to adding new instructions one appears or doesn't appear as expected. I've added SVE and SME, other capabilities can be added later if this gets merged. This isn't super exciting but on the other hand took very little time to write and should be handy when verifying that you wired up AT_HWCAP properly. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220829154602.827275-1-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-09-06cpuset: Add Waiman Long as a cpuset maintainerTejun Heo1-0/+1
Waiman has been very active with cpuset recently and I've been cc'ing him for cpuset related changes for a while now. Let's make him a cpuset maintainer. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Zefan Li <lizefan.x@bytedance.com> Cc: Waiman Long <longman@redhat.com>
2022-09-06btrfs: fix the max chunk size and stripe length calculationQu Wenruo2-1/+4
[BEHAVIOR CHANGE] Since commit f6fca3917b4d ("btrfs: store chunk size in space-info struct"), btrfs no longer can create larger data chunks than 1G: mkfs.btrfs -f -m raid1 -d raid0 $dev1 $dev2 $dev3 $dev4 mount $dev1 $mnt btrfs balance start --full $mnt btrfs balance start --full $mnt umount $mnt btrfs ins dump-tree -t chunk $dev1 | grep "DATA|RAID0" -C 2 Before that offending commit, what we got is a 4G data chunk: item 6 key (FIRST_CHUNK_TREE CHUNK_ITEM 9492758528) itemoff 15491 itemsize 176 length 4294967296 owner 2 stripe_len 65536 type DATA|RAID0 io_align 65536 io_width 65536 sector_size 4096 num_stripes 4 sub_stripes 1 Now what we got is only 1G data chunk: item 6 key (FIRST_CHUNK_TREE CHUNK_ITEM 6271533056) itemoff 15491 itemsize 176 length 1073741824 owner 2 stripe_len 65536 type DATA|RAID0 io_align 65536 io_width 65536 sector_size 4096 num_stripes 4 sub_stripes 1 This will increase the number of data chunks by the number of devices, not only increase system chunk usage, but also greatly increase mount time. Without a proper reason, we should not change the max chunk size. [CAUSE] Previously, we set max data chunk size to 10G, while max data stripe length to 1G. Commit f6fca3917b4d ("btrfs: store chunk size in space-info struct") completely ignored the 10G limit, but use 1G max stripe limit instead, causing above shrink in max data chunk size. [FIX] Fix the max data chunk size to 10G, and in decide_stripe_size_regular() we limit stripe_size to 1G manually. This should only affect data chunks, as for metadata chunks we always set the max stripe size the same as max chunk size (256M or 1G depending on fs size). Now the same script result the same old result: item 6 key (FIRST_CHUNK_TREE CHUNK_ITEM 9492758528) itemoff 15491 itemsize 176 length 4294967296 owner 2 stripe_len 65536 type DATA|RAID0 io_align 65536 io_width 65536 sector_size 4096 num_stripes 4 sub_stripes 1 Reported-by: Wang Yugui <wangyugui@e16-tech.com> Fixes: f6fca3917b4d ("btrfs: store chunk size in space-info struct") Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2022-09-06Revert "drm: Add missing DP DSC extended capability definitions."Jani Nikula1-9/+1
This reverts commit 797e2c3f2762c356aadcdb53dd6bb8b8d966f7b5. Part of a series where patches were modified while applying to resolve conflicts, leading to further conflicts between drm-misc-next and drm-intel-next, resulting in build failures in drm-tip. To be applied again on a baseline with drm-misc-next and drm-intel-next in sync. Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2022-09-06Revert "drm/i915: Fix intel_dp_mst_compute_link_config"Jani Nikula1-14/+2
This reverts commit c6266862de1665b8c8006f58612db2dea66a29f6. Part of a series where patches were modified while applying to resolve conflicts, leading to further conflicts between drm-misc-next and drm-intel-next, resulting in build failures in drm-tip. To be applied again on a baseline with drm-misc-next and drm-intel-next in sync. Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2022-09-06Revert "drm/i915: Extract drm_dp_atomic_find_vcpi_slots cycle to separate function"Jani Nikula1-41/+13
This reverts commit 7ae5ab441402b8165de4658ba9398d8378f7dd1e. Part of a series where patches were modified while applying to resolve conflicts, leading to further conflicts between drm-misc-next and drm-intel-next, resulting in build failures in drm-tip. To be applied again on a baseline with drm-misc-next and drm-intel-next in sync. Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2022-09-06Revert "drm/i915: Add DSC support to MST path"Jani Nikula3-174/+42
This reverts commit e1a84ba850128b3984973786829e610ae4ee0e2e. Part of a series where patches were modified while applying to resolve conflicts, leading to further conflicts between drm-misc-next and drm-intel-next, resulting in build failures in drm-tip. To be applied again on a baseline with drm-misc-next and drm-intel-next in sync. Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2022-09-06binder: fix binder_alloc kernel-doc warningsCarlos Llamas1-3/+2
Update the kernel-doc section of struct binder_alloc to fix the following warnings reported by ./scripts/kernel-doc: warning: Function parameter or member 'mutex' not described in 'binder_alloc' warning: Function parameter or member 'vma_addr' not described in 'binder_alloc' No functional changes in this patch. Reviewed-by: Christian Brauner (Microsoft) <brauner@kernel.org> Acked-by: Todd Kjos <tkjos@google.com> Signed-off-by: Carlos Llamas <cmllamas@google.com> Link: https://lore.kernel.org/r/20220906135948.3048225-4-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-06binder: remove binder_alloc_set_vma()Carlos Llamas1-23/+2
The mmap_locked asserts here are not needed since this is only called back from the mmap stack in ->mmap() and ->close() which always acquire the lock first. Remove these asserts along with binder_alloc_set_vma() altogether since it's trivial enough to be consumed by callers. Cc: Liam R. Howlett <Liam.Howlett@oracle.com> Signed-off-by: Carlos Llamas <cmllamas@google.com> Link: https://lore.kernel.org/r/20220906135948.3048225-3-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-06binder: rename alloc->vma_vm_mm to alloc->mmCarlos Llamas2-19/+19
Rename ->vma_vm_mm to ->mm to reflect the fact that we no longer cache this reference from vma->vm_mm but from current->mm instead. No functional changes in this patch. Reviewed-by: Christian Brauner (Microsoft) <brauner@kernel.org> Acked-by: Todd Kjos <tkjos@google.com> Signed-off-by: Carlos Llamas <cmllamas@google.com> Link: https://lore.kernel.org/r/20220906135948.3048225-2-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-06arm64: dts: qcom: msm8916-samsung-serranove: Add magnetometerJakob Hauser1-0/+9
Add magnetometer Yamaha YAS537 to the DeviceTree of samsung-serranove. The YAS537 variant was recently added to the Yamaha YAS magnetometers driver [1]. In the DeviceTree of samsung-serranove for the Android kernel, there is unfortunately no information on interrupts or pinctrl [2]. In the Android kernel driver for magnetometer Yamaha YAS537, there is a device-specific matrix to correct an ellipsoid shape of the measure values into a sphere shape [3]. This could be converted and applied to a mount-matrix. However, the current state of the mainline Yamaha YAS537 driver needs post-process calibration in userspace anyway, as it lacks a formula to center the measure values around zero. The correction of the ellipsoid into a sphere can be done in the post-process calibration as well. A mount-matrix is needed nonetheless. When putting samsung-serranove flat on a table in portrait orientation heading north, the Yamaha YAS537 magnetometer axes natively point X+ to north, Y+ to east and Z+ into the ground, which corresponds to a common way to define the Earth's magnetic field coordinate system [4]. According to the IIO definition, it should be Y+ to north, X+ to east and Z+ upwards [5], which corresponds to a common device coordinate system and eases sensor fusing. [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/iio/magnetometer/yamaha-yas530.c?id=65f79b501030678393eae0ae03d60a8151fbef55 [2] https://github.com/msm8916-mainline/android_kernel_qcom_msm8916/blob/GT-I9195I/arch/arm/boot/dts/samsung/msm8916/msm8916-sec-serranovelte-eur-r03.dtsi#L318-L321 [3] https://github.com/msm8916-mainline/android_kernel_qcom_msm8916/blob/GT-I9195I/drivers/iio/magnetometer/yas_mag_drv-yas537.c#L105-L106 [4] https://en.wikipedia.org/wiki/Earth%27s_magnetic_field#Characteristics [5] https://github.com/torvalds/linux/blob/v5.19/Documentation/devicetree/bindings/iio/mount-matrix.txt#L93-L126 Cc: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Jakob Hauser <jahau@rocketmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220904214935.31032-1-jahau@rocketmail.com
2022-09-06arm64: dts: qcom: sc8280xp-pmics: Remove reg entry & use correct node name for pmc8280c_lpg nodeBhupesh Sharma1-2/+1
Commit eeca7d46217c ("arm64: dts: qcom: pm8350c: Drop PWM reg declaration") dropped PWM reg declaration for pm8350c pwm(s), but there is a leftover 'reg' entry inside the lpg/pwm node in sc8280xp dts file. Remove the same. While at it, also remove the unused unit address in the node label. Also, since dt-bindings expect LPG/PWM node name to be "pwm", use correct node name as well, to fix the following error reported by 'make dtbs_check': 'lpg' does not match any of the regexes Fixes: eeca7d46217c ("arm64: dts: qcom: pm8350c: Drop PWM reg declaration") Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Cc: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Cc: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220905070240.1634997-1-bhupesh.sharma@linaro.org
2022-09-06arm64: dts: qcom: sm7225-fairphone-fp4: Add pm7250b PMICLuca Weiss1-0/+67
The PM7250B is primarily used for charger and fuel gauge on Fairphone 4 but also has some thermal zones that we can configure already. Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220902111055.106814-3-luca.weiss@fairphone.com
2022-09-06arm64: dts: qcom: Add pm7250b PMICLuca Weiss1-0/+149
PM7250B is a PMIC primarily used for charging and fuel gauge but also has some of the standard functionality like temp-alarm, adc, etc. Add the .dtsi with some of the functionality added. Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20220902111055.106814-2-luca.weiss@fairphone.com
2022-09-06misc: microchip: pci1xxxx: fix dependency issues in building the pci1xxxx's aux bus driver.Kumaravel Thiagarajan1-1/+3
build errors and warnings listed below and reported by kernel test robot <lkp@intel.com> on the char-misc-next branch are fixed in this add-on patch. errors: ERROR: modpost: "auxiliary_device_init" [drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.ko] undefined! ERROR: modpost: "__auxiliary_device_add" [drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.ko] undefined! ERROR: modpost: "auxiliary_driver_unregister" [drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gpio.ko] undefined! ERROR: modpost: "__auxiliary_driver_register" [drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gpio.ko] undefined! ia64-linux-ld: drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.o: in function `gp_aux_bus_probe.part.0': mchp_pci1xxxx_gp.c:(.text+0x342): undefined reference to `auxiliary_device_init' ia64-linux-ld: mchp_pci1xxxx_gp.c:(.text+0x392): undefined reference to `__auxiliary_device_add' ia64-linux-ld: mchp_pci1xxxx_gp.c:(.text+0x5c2): undefined reference to `auxiliary_device_init' ia64-linux-ld: mchp_pci1xxxx_gp.c:(.text+0x612): undefined reference to `__auxiliary_device_add' ia64-linux-ld: drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gpio.o: in function `pci1xxxx_gpio_driver_init': mchp_pci1xxxx_gpio.c:(.init.text+0x42): undefined reference to `__auxiliary_driver_register' warnings: unmet direct dependencies detected for GPIOLIB_IRQCHIP when selected by GP_PCI1XXXX Fixes: 393fc2f5948f ("misc: microchip: pci1xxxx: load auxiliary bus driver for the PIO function in the multi-function endpoint of pci1xxxx device.") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Kumaravel Thiagarajan <kumaravel.thiagarajan@microchip.com> Link: https://lore.kernel.org/r/20220906124951.696776-1-kumaravel.thiagarajan@microchip.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-06drm/i915: split out i915_gem.c declarations to i915_gem.hJani Nikula2-36/+43
Declutter i915_drv.h by splitting out the declarations for i915_gem.[ch]. Add a fixme comment about the rest of the stuff in i915_gem.h that doesn't really belong there. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/82a353c5c4b52df2354f9413b547c7619a45d92d.1662390010.git.jani.nikula@intel.com
2022-09-06drm/i915: un-inline i915_gem_drain_freed_objects()Jani Nikula2-16/+16
I can't idenfity a single hot path that would require i915_gem_drain_freed_objects() to be inline. Un-inline it. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6c289c55afee0d9a3067122db63277b8d60cf74f.1662390010.git.jani.nikula@intel.com
2022-09-06drm/i915: un-inline i915_gem_drain_workqueue()Jani Nikula2-21/+23
i915_gem_drain_workqueue() is not used on any hot paths. Un-unline it. Replace the do-while with a for loop while at it. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/2c89e7e0a3528caf7ba9ffa29b2bb9f13f2357d1.1662390010.git.jani.nikula@intel.com
2022-09-06drm/i915: remove unused i915_gem_set_global_seqno() declarationJani Nikula1-2/+0
The function was removed four years ago in commit 6faf5916e6be ("drm/i915: Remove HW semaphores for gen7 inter-engine synchronisation"). Finish the job. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/0f88380416c1bd457af58bb31aeb297749a6fb9e.1662390010.git.jani.nikula@intel.com
2022-09-06drm/i915: remove unused macro I915_GTT_OFFSET_NONEJani Nikula1-2/+0
Apparently the last user of the macro was removed in commit 9c4ce97d8025 ("drm/i915/display: Be explicit in handling the preallocated vma"). Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b28b183457cf8871b1b070cbbbc3473bd5288210.1662390010.git.jani.nikula@intel.com
2022-09-06perf c2c: Prevent potential memory leak in c2c_he_zalloc()Shang XiaoJing1-3/+9
Free allocated resources when zalloc() fails for members in c2c_he, to prevent potential memory leak in c2c_he_zalloc(). Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com> Reviewed-by: Leo Yan <leo.yan@linaro.org> Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20220906032906.21395-4-shangxiaojing@huawei.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2022-09-06perf genelf: Switch deprecated openssl MD5_* functions to new EVP APIZixuan Tan1-9/+11
Switch to the flavored EVP API like in test-libcrypto.c, and remove the bad gcc #pragma. Inspired-by: 5b245985a6de5ac1 ("tools build: Switch to new openssl API for test-libcrypto") Signed-off-by: Zixuan Tan <tanzixuan.me@gmail.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/CABwm_eTnARC1GwMD-JF176k8WXU1Z0+H190mvXn61yr369qt6g@mail.gmail.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2022-09-06tools/perf: Fix out of bound access to cpu mask arrayAthira Rajeev1-6/+20
The cpu mask init code in "record__mmap_cpu_mask_init" function access "bits" array part of "struct mmap_cpu_mask". The size of this array is the value from cpu__max_cpu().cpu. This array is used to contain the cpumask value for each cpu. While setting bit for each cpu, it calls "set_bit" function which access index in "bits" array. If we provide a command line option to -C which is greater than the number of CPU's present in the system, the set_bit could access an array member which is out-of the array size. This is because currently, there is no boundary check for the CPU. This will result in seg fault: <<>> ./perf record -C 12341234 ls Perf can support 2048 CPUs. Consider raising MAX_NR_CPUS Segmentation fault (core dumped) <<>> Debugging with gdb, points to function flow as below: <<>> set_bit record__mmap_cpu_mask_init record__init_thread_default_masks record__init_thread_masks cmd_record <<>> Fix this by adding boundary check for the array. After the patch: <<>> ./perf record -C 12341234 ls Perf can support 2048 CPUs. Consider raising MAX_NR_CPUS Failed to initialize parallel data streaming masks <<>> With this fix, if -C is given a non-exsiting CPU, perf record will fail with: <<>> ./perf record -C 50 ls Failed to initialize parallel data streaming masks <<>> Reported-by: Nageswara R Sastry <rnsastry@linux.ibm.com> Signed-off-by: Athira Jajeev <atrajeev@linux.vnet.ibm.com> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kajol Jain <kjain@linux.ibm.com> Cc: Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Link: https://lore.kernel.org/r/20220905141929.7171-2-atrajeev@linux.vnet.ibm.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2022-09-06perf affinity: Fix out of bound access to "sched_cpus" maskAthira Rajeev1-1/+7
The affinity code in "affinity_set" function access array named "sched_cpus". The size for this array is allocated in affinity_setup function which is nothing but value from get_cpu_set_size. This is used to contain the cpumask value for each cpu. While setting bit for each cpu, it calls "set_bit" function which access index in sched_cpus array. If we provide a command-line option to -C which is more than the number of CPU's present in the system, the set_bit could access an array member which is out-of the array size. This is because currently, there is no boundary check for the CPU. This will result in seg fault: <<>> ./perf stat -C 12323431 ls Perf can support 2048 CPUs. Consider raising MAX_NR_CPUS Segmentation fault (core dumped) <<>> Fix this by adding boundary check for the array. After the fix from powerpc system: <<>> ./perf stat -C 12323431 ls 1>out Perf can support 2048 CPUs. Consider raising MAX_NR_CPUS Performance counter stats for 'CPU(s) 12323431': <not supported> msec cpu-clock <not supported> context-switches <not supported> cpu-migrations <not supported> page-faults <not supported> cycles <not supported> instructions <not supported> branches <not supported> branch-misses 0.001192373 seconds time elapsed <<>> Reported-by: Nageswara R Sastry <rnsastry@linux.ibm.com> Signed-off-by: Athira Jajeev <atrajeev@linux.vnet.ibm.com> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kajol Jain <kjain@linux.ibm.com> Cc: Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Link: https://lore.kernel.org/r/20220905141929.7171-1-atrajeev@linux.vnet.ibm.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.