summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-07-14iommu/tegra241-cmdqv: import IOMMUFD module namespaceArnd Bergmann
The tegra variant of smmu-v3 now uses the iommufd mmap interface but is missing the corresponding import: ERROR: modpost: module arm_smmu_v3 uses symbol _iommufd_object_depend from namespace IOMMUFD, but does not import it. ERROR: modpost: module arm_smmu_v3 uses symbol iommufd_viommu_report_event from namespace IOMMUFD, but does not import it. ERROR: modpost: module arm_smmu_v3 uses symbol _iommufd_destroy_mmap from namespace IOMMUFD, but does not import it. ERROR: modpost: module arm_smmu_v3 uses symbol _iommufd_object_undepend from namespace IOMMUFD, but does not import it. ERROR: modpost: module arm_smmu_v3 uses symbol _iommufd_alloc_mmap from namespace IOMMUFD, but does not import it. Fixes: b135de24cfc0 ("iommu/tegra241-cmdqv: Add user-space use support") Link: https://patch.msgid.link/r/20250714205747.3475772-1-arnd@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2025-07-14drm/xe/lrc: Add table with LRC layoutLucas De Marchi
Add a table to document the LRC's BO layout to make it easier to visualize how each region stacks on top of each other. Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://lore.kernel.org/r/20250710-lrc-refactors-v2-4-a5e2ca03f6bd@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-14drm/xe: Waste fewer instructions in emit_wa_job()Tvrtko Ursulin
I was debugging some unrelated issue and noticed the current code was very verbose. We can improve it easily by using the more common batch buffer building pattern. Before: bb->cs[bb->len++] = MI_LOAD_REGISTER_REG | MI_LRR_DST_CS_MMIO; c4d: 41 8b 56 10 mov 0x10(%r14),%edx c51: 49 8b 4e 08 mov 0x8(%r14),%rcx c55: 8d 72 01 lea 0x1(%rdx),%esi c58: 41 89 76 10 mov %esi,0x10(%r14) c5c: c7 04 91 01 00 08 15 movl $0x15080001,(%rcx,%rdx,4) bb->cs[bb->len++] = entry->reg.addr; c63: 8b 08 mov (%rax),%ecx c65: 41 8b 56 10 mov 0x10(%r14),%edx c69: 49 8b 76 08 mov 0x8(%r14),%rsi c6d: 81 e1 ff ff 3f 00 and $0x3fffff,%ecx c73: 8d 7a 01 lea 0x1(%rdx),%edi c76: 41 89 7e 10 mov %edi,0x10(%r14) c7a: 89 0c 96 mov %ecx,(%rsi,%rdx,4) ..etc.. After: *cs++ = MI_LOAD_REGISTER_REG | MI_LRR_DST_CS_MMIO; c52: 41 c7 04 24 01 00 08 movl $0x15080001,(%r12) c59: 15 *cs++ = entry->reg.addr; c5a: 8b 10 mov (%rax),%edx ..etc.. Resulting in the following binary change: add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-348 (-348) Function old new delta xe_gt_record_default_lrcs.cold 304 296 -8 xe_gt_record_default_lrcs 2200 1860 -340 Total: Before=13554, After=13206, chg -2.57% Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250710-lrc-refactors-v2-7-a5e2ca03f6bd@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-14drm/xe/gt: Drop third submission for default contextLucas De Marchi
There's no need to submit the nop job again on the first queue. Any state needed is already saved when the first LRC is switched out. The comment is a little misleading regarding indirect W/A: first of all there's still no indirect W/A enabled and secondly, even after they are, there's no need to submit this job again for having their state propagated: the indirect W/A will actually run on every LRC switch. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250710-lrc-refactors-v2-6-a5e2ca03f6bd@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-14drm/xe/lrc: Remove leftover TODO/FIXMELucas De Marchi
There isn't anything to set for CTX_TIMESTAMP handling in the empty LRC: that is set on every LRC init since it should always start from 0 rather than the value saved in the image after first submission. The FIXME about perma-pinning also doesn't make much sense as we will always going to pin the lrc and the GGTT mapping has nothing to do with VM bind. Nuke these leftover comments. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250710-lrc-refactors-v2-5-a5e2ca03f6bd@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-14drm/xe/gt: Extract emit_job_sync()Lucas De Marchi
Both the nop and wa jobs are going through the same boiler plate calls to emit the job with a timeout and handling error for both bb and job. Extract emit_job_sync() so those functions create the bb, handling possible errors and delegate the part about really emitting the job and waiting for its completion. Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://lore.kernel.org/r/20250710-lrc-refactors-v2-3-a5e2ca03f6bd@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-14drm/xe: Count dwords before allocatingLucas De Marchi
The bb allocation in emit_wa_job() is wrong in 2 ways: first it's allocating enough space for the 3DSTATE or hardcoding 4k depending on the engine. In the first case it doesn't account for the WAs and in the former it may not be sufficient. Secondly it's using the size instead of number of dwords, causing the buffer to be 4x bigger than needed: xe_bb_new() receives number of dwords as parameter and its declaration was also not following its implementation. Lastly, reword the debug message since it's not only about the LRC WAs anymore as it also include the 3DSTATE for render. While it's unlikely this is causing any real issue, let's calculate the needed space and allocate just enough. Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://lore.kernel.org/r/20250710-lrc-refactors-v2-2-a5e2ca03f6bd@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-14drm/xe/lrc: Reduce scope of empty lrc dataLucas De Marchi
The only case in which new lrc data is created from scratch is when it's called prior to recording the default lrc. There's no need to check for NULL init_data since in that case the function already failed: just move the allocation where it's needed. Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250710-lrc-refactors-v2-1-a5e2ca03f6bd@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-14iio: Add driver for Nicera D3-323-AA PIR sensorWaqar Hameed
Nicera D3-323-AA is a PIR sensor for human detection. It has support for raw data measurements and detection notification. The communication protocol is custom made and therefore needs to be GPIO bit banged. The device has two main settings that can be configured: a threshold value for detection and a band-pass filter. The configurable parameters for the band-pass filter are the high-pass and low-pass cutoff frequencies and its peak gain. Map these settings to the corresponding parameters in the `iio` framework. Raw data measurements can be obtained from the device. However, since we rely on bit banging, it will be rather cumbersome with buffer support. The main reason being that the data protocol has strict timing requirements (it's serial like UART), and it's mainly used during debugging since in real-world applications only the event notification is of importance. Therefore, only add support for events (for now). Signed-off-by: Waqar Hameed <waqar.hameed@axis.com> Link: https://patch.msgid.link/29f84da1431f4a3f17fdeef27297a4ab14455404.1751636734.git.waqar.hameed@axis.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: dac: vf610: Simplify with devm_clk_get_enabled()Krzysztof Kozlowski
Driver is getting clock and almost immediately enabling it, with no relevant code executed between, thus the probe path and cleanups can be simplified with devm_clk_get_enabled(). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20250713-iio-clk-get-enabled-v1-4-70abc1f9ce6c@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: adc: vf610: Simplify with dev_err_probeKrzysztof Kozlowski
Use dev_err_probe() to make error code handling simpler and handle deferred probe nicely (avoid spamming logs). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20250713-iio-clk-get-enabled-v1-3-70abc1f9ce6c@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: adc: vf610: Drop -ENOMEM error messageKrzysztof Kozlowski
Core already prints detailed error messages on ENOMEM errors and drivers should avoid repeating it. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20250713-iio-clk-get-enabled-v1-2-70abc1f9ce6c@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: imu: bno055: make bno055_sysfs_attr constDavid Lechner
Add const qualifier to struct bno055_sysfs_attr and its array fields. All of this is read-only data so it can be made const. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250709-iio-const-data-19-v2-2-fb3fc9191251@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: imu: bno055: fix OOB access of hw_xlate arrayDavid Lechner
Fix a potential out-of-bounds array access of the hw_xlate array in bno055.c. In bno055_get_regmask(), hw_xlate was iterated over the length of the vals array instead of the length of the hw_xlate array. In the case of bno055_gyr_scale, the vals array is larger than the hw_xlate array, so this could result in an out-of-bounds access. In practice, this shouldn't happen though because a match should always be found which breaks out of the for loop before it iterates beyond the end of the hw_xlate array. By adding a new hw_xlate_len field to the bno055_sysfs_attr, we can be sure we are iterating over the correct length. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202507100510.rGt1YOOx-lkp@intel.com/ Fixes: 4aefe1c2bd0c ("iio: imu: add Bosch Sensortec BNO055 core driver") Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250709-iio-const-data-19-v2-1-fb3fc9191251@baylibre.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: accel: kionix-kx022a: Apply approximate iwyu principles to includesJonathan Cameron
Motivated by the W=1 warning about export.h that was introduced this cycle this is an attempt to apply an approximation of the principles of including whatever is used in the file directly. Helped by the include-what-you-use tool. Reasoning: - Drop linux/moduleparam.h as completely unused. - linux/array_size.h for ARRAY_SIZE() - linux/bitmap.h for for_each_set_bit - linux/errno.h for error codes. - linux/export.h for EXPORT_SYMBOL*() - linux/math64.h for do_div - alternative would be asm/div64.h - linux/minmax.h for min() - linux/sysfs.h for sysfs_emit() - linux/time64.h for USEC_PER_MSEC - linux/iio/buffer.h for iio_push_to_buffers_with_timestamp() - asm/byteorder.h for le16_to_cpu() Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20250629183649.184479-1-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: adc: ad4170-4: Add support for weigh scale, thermocouple, and RTD sensMarcelo Schmitt
The AD4170-4 design provides features to aid interfacing with weigh scales, thermocouples, and RTD sensors, which are set up with additional circuitry for proper sensor operation. A key characteristic of those sensors is that the circuit they are in must be excited with a single, a pair, or two pairs of signals. The external circuit can be excited either by a voltage supply or by AD4170-4 excitation signals. The sensor can then be read through a different pair of lines that are connected to the AD4170-4 ADC. Extend the ad4170-4 driver to handle external circuit sensors. Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com> Link: https://patch.msgid.link/52686943040ecad34cc89833d4d5d37f1a51f412.1751895245.git.marcelo.schmitt@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: adc: ad4170-4: Add support for internal temperature sensorMarcelo Schmitt
The AD4170-4 has an internal temperature sensor that can be read using the ADC. Whenever possible, configure an IIO channel to provide the chip's temperature. Reviewed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com> Link: https://patch.msgid.link/71ac994060cf79a6c49f39b0c7d04c6c9cbbab00.1751895245.git.marcelo.schmitt@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: adc: ad4170-4: Add GPIO controller supportMarcelo Schmitt
The AD4170-4 has four multifunctional pins that can be used as GPIOs. The GPIO functionality can be accessed when the AD4170-4 chip is not busy performing continuous data capture or handling any other register read/write request. Also, the AD4170-4 does not provide any interrupt based on GPIO pin states so AD4170-4 GPIOs can't be used as interrupt sources. Implement gpio_chip callbacks to make AD4170-4 GPIO pins controllable through the gpiochip interface. Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com> Link: https://patch.msgid.link/e031189d4b7e20cf02dd13220ab1ddf4798760c2.1751895245.git.marcelo.schmitt@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: adc: ad4170-4: Add clock provider supportMarcelo Schmitt
The AD4170-4 chip can use an externally supplied clock at the XTAL2 pin, or an external crystal connected to the XTAL1 and XTAL2 pins. Alternatively, the AD4170-4 can provide its 16 MHz internal clock at the XTAL2 pin. In addition, the chip has a programmable clock divider that allows dividing the external or internal clock frequency, however, control for that is not provided in this patch. Extend the AD4170-4 driver so it effectively uses the provided external clock, if any, or supplies its own clock as a clock provider. Reviewed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com> Link: https://patch.msgid.link/68697c7613b1a69d752e541caef28d08b3e59bc1.1751895245.git.marcelo.schmitt@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: adc: ad4170-4: Add timestamp channelMarcelo Schmitt
Add timestamp channel allowing to record the moment at which ADC samples are captured in buffered read mode. Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com> Link: https://patch.msgid.link/e0af7e5424898bee0f3edfbb017133624efc169d.1751895245.git.marcelo.schmitt@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: adc: ad4170-4: Add support for buffered data captureMarcelo Schmitt
Extend the AD4170-4 driver to allow buffered data capture in continuous read mode. In continuous read mode, the chip skips the instruction phase and outputs just ADC sample data, enabling faster sample rates to be reached. The internal channel sequencer always starts sampling from channel 0 and channel 0 must be enabled if more than one channel is selected for data capture. The scan mask validation callback checks if the aforementioned condition is met. Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com> Link: https://patch.msgid.link/10ed544d31aa86eb40f93ea947f151d3d9827952.1751895245.git.marcelo.schmitt@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: adc: ad4170-4: Add digital filter and sample frequency config supportMarcelo Schmitt
Add support for sinc3, sinc5, and averaged sinc5 digital filters along with sample frequency configuration. Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com> Link: https://patch.msgid.link/31f4226b4172b0bbb26daa054b74b25b1966c7b2.1751895245.git.marcelo.schmitt@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: adc: ad4170-4: Add support for calibration biasMarcelo Schmitt
Add support for ADC calibration bias/offset configuration. Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com> Link: https://patch.msgid.link/f240fce693d62ec8d587885074bf540e01919b31.1751895245.git.marcelo.schmitt@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: adc: ad4170-4: Add support for calibration gainMarcelo Schmitt
Add support for ADC calibration gain configuration. Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com> Link: https://patch.msgid.link/ea8d07cad9b7b6106f0b5664c403ed080b362a6b.1751895245.git.marcelo.schmitt@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: adc: Add basic support for AD4170-4Ana-Maria Cusco
The AD4170-4 is a multichannel, low noise, 24-bit precision sigma-delta analog to digital converter. The AD4170-4 design offers a flexible data acquisition solution with crosspoint multiplexed analog inputs, configurable ADC voltage reference inputs, ultra-low noise integrated PGA, digital filtering, wide range of configurable output data rates, internal oscillator and temperature sensor, four GPIOs, and integrated features for interfacing with load cell weigh scales, RTD, and thermocouple sensors. Add basic support for the AD4170-4 ADC with the following features: - Single-shot read. - Analog front end PGA configuration. - Differential and pseudo-differential input configuration. Signed-off-by: Ana-Maria Cusco <ana-maria.cusco@analog.com> Co-developed-by: Marcelo Schmitt <marcelo.schmitt@analog.com> Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com> Link: https://patch.msgid.link/ce3fd150bd63a2aed6eb6fe59aad6d60c0f9fb67.1751895245.git.marcelo.schmitt@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: imu: inv_icm42600: add wakeup functionality for Wake-on-MotionJean-Baptiste Maneyrol
When Wake-on-Motion is on, enable system wakeup and keep the chip on for waking up the system with an interrupt. Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com> Link: https://patch.msgid.link/20250630-losd-3-inv-icm42600-add-wom-support-v6-3-5bb0c84800d9@tdk.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: imu: inv_icm42600: add WoM supportJean-Baptiste Maneyrol
Add WoM as accel roc rising x|y|z event. Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com> Link: https://patch.msgid.link/20250630-losd-3-inv-icm42600-add-wom-support-v6-2-5bb0c84800d9@tdk.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: imu: inv_icm42600: reorganize DMA aligned buffers in structureJean-Baptiste Maneyrol
Move all DMA aligned buffers together at the end of the structure. 1. Timestamp anynomous structure is not used with DMA so it doesn't belong after __aligned(IIO_DMA_MINALIGN). 2. struct inv_icm42600_fifo contains it's own __aligned(IIO_DMA_MINALIGN) within it at the end so it should not be after __aligned(IIO_DMA_MINALIGN) in the outer struct either. 3. Normally 1 would have been considered a bug, but because of the extra alignment from 2, it actually was OK, but we shouldn't be relying on such quirks. Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com> Link: https://patch.msgid.link/20250630-losd-3-inv-icm42600-add-wom-support-v6-1-5bb0c84800d9@tdk.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: accel: adxl345: simplify reading the FIFOLothar Rubusch
Bulk FIFO reading can be streamlined by eliminating redundant variables and simplifying the process of reading x-, y-, and z-axis measurement sets. This is a refactoring change with no expected impact on functionality. Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Link: https://patch.msgid.link/20250702230315.19297-3-l.rubusch@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14iio: accel: adxl345: simplify interrupt mappingLothar Rubusch
Refactor the sensor interrupt mapping by utilizing regmap_assign_bits(), which accepts a boolean value directly. Introduce a helper function to streamline the identification of the configured interrupt line pin. Also, use identifiers from units.h to represent the full 8-bit register when setting bits. This is a purely refactoring change and does not affect functionality. Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20250702230315.19297-2-l.rubusch@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-07-14idpf: implement get LAN MMIO memory regionsJoshua Hay
The RDMA driver needs to map its own MMIO regions for the sake of performance, meaning the IDPF needs to avoid mapping portions of the BAR space. However, to be HW agnostic, the IDPF cannot assume where these are and must avoid mapping hard coded regions as much as possible. The IDPF maps the bare minimum to load and communicate with the control plane, i.e., the mailbox registers and the reset state registers. Because of how and when mailbox register offsets are initialized, it is easier to adjust the existing defines to be relative to the mailbox region starting address. Use a specific mailbox register write function that uses these relative offsets. The reset state register addresses are calculated the same way as for other registers, described below. The IDPF then calls a new virtchnl op to fetch a list of MMIO regions that it should map. The addresses for the registers in these regions are calculated by determining what region the register resides in, adjusting the offset to be relative to that region, and then adding the register's offset to that region's mapped address. If the new virtchnl op is not supported, the IDPF will fallback to mapping the whole bar. However, it will still map them as separate regions outside the mailbox and reset state registers. This way we can use the same logic in both cases to access the MMIO space. Reviewed-by: Madhu Chittim <madhu.chittim@intel.com> Signed-off-by: Joshua Hay <joshua.a.hay@intel.com> Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-07-14idpf: implement IDC vport aux driver MTU change handlerJoshua Hay
The only event an RDMA vport aux driver cares about right now is an MTU change on its underlying vport. Implement and plumb the handler to signal the pre MTU change event and post MTU change events to the RDMA vport aux driver. Reviewed-by: Madhu Chittim <madhu.chittim@intel.com> Signed-off-by: Joshua Hay <joshua.a.hay@intel.com> Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-07-14idpf: implement remaining IDC RDMA core callbacks and handlersJoshua Hay
Implement the idpf_idc_request_reset and idpf_idc_rdma_vc_send_sync callbacks for the rdma core auxiliary driver to issue reset events to the idpf and send (synchronous) virtchnl messages to the control plane respectively. Implement and plumb the reset handler for the opposite flow as well, i.e. when the idpf is resetiing and needs to notify the rdma core auxiliary driver. Reviewed-by: Madhu Chittim <madhu.chittim@intel.com> Signed-off-by: Joshua Hay <joshua.a.hay@intel.com> Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-07-14idpf: implement RDMA vport auxiliary dev create, init, and destroyJoshua Hay
Implement the functions to create, initialize, and destroy an RDMA vport auxiliary device. The vport aux dev creation is dependent on the core aux device to call idpf_idc_vport_dev_ctrl to signal that it is ready for vport aux devices. Implement that core callback to either create and initialize the vport aux dev or deinitialize. RDMA vport aux dev creation is also dependent on the control plane to tell us the vport is RDMA enabled. Add a flag in the create vport message to signal individual vport RDMA capabilities. Reviewed-by: Madhu Chittim <madhu.chittim@intel.com> Signed-off-by: Joshua Hay <joshua.a.hay@intel.com> Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-07-14idpf: implement core RDMA auxiliary dev create, init, and destroyJoshua Hay
Add the initial idpf_idc.c file with the functions to kick off the IDC initialization, create and initialize a core RDMA auxiliary device, and destroy said device. The RDMA core has a dependency on the vports being created by the control plane before it can be initialized. Therefore, once all the vports are up after a hard reset (either during driver load a function level reset), the core RDMA device info will be created. It is populated with the function type (as distinguished by the IDC initialization function pointer), the core idc_ops function points (just stubs for now), the reserved RDMA MSIX table, and various other info the core RDMA auxiliary driver will need. It is then plugged on to the bus. During a function level reset or driver unload, the device will be unplugged from the bus and destroyed. Reviewed-by: Madhu Chittim <madhu.chittim@intel.com> Signed-off-by: Joshua Hay <joshua.a.hay@intel.com> Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-07-14idpf: use reserved RDMA vectors from control planeJoshua Hay
Fetch the number of reserved RDMA vectors from the control plane. Adjust the number of reserved LAN vectors if necessary. Adjust the minimum number of vectors the OS should reserve to include RDMA; and fail if the OS cannot reserve enough vectors for the minimum number of LAN and RDMA vectors required. Create a separate msix table for the reserved RDMA vectors, which will just get handed off to the RDMA core device to do with what it will. Reviewed-by: Madhu Chittim <madhu.chittim@intel.com> Signed-off-by: Joshua Hay <joshua.a.hay@intel.com> Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-07-14drm/panel-edp: Add BOE NE14QDM panel for Dell Latitude 7455Val Packett
Cannot confirm which variant exactly it is, as the EDID alphanumeric data contains '0RGNR' <0x80> 'NE14QDM' and ends there; but it's 60 Hz and with touch. I do not have access to datasheets for these panels, so the timing is a guess that was tested to work fine on this laptop. Raw EDID dump: 00 ff ff ff ff ff ff 00 09 e5 1e 0b 00 00 00 00 10 20 01 04 a5 1e 13 78 07 fd 85 a7 53 4c 9b 25 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 a7 6d 00 a0 a0 40 78 60 30 20 36 00 2e bc 10 00 00 1a b9 57 00 a0 a0 40 78 60 30 20 36 00 2e bc 10 00 00 1a 00 00 00 fe 00 30 52 47 4e 52 80 4e 45 31 34 51 44 4d 00 00 00 00 00 02 41 31 a8 00 01 00 00 1a 41 0a 20 20 00 8f Signed-off-by: Val Packett <val@packett.cool> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250706205723.9790-7-val@packett.cool
2025-07-14cpufreq: Exit governor when failed to start old governorLifeng Zheng
Detect the result of starting old governor in cpufreq_set_policy(). If it fails, exit the governor and clear policy->governor. Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20250709104145.2348017-5-zhenglifeng1@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-07-14cpufreq: Move the check of cpufreq_driver->get into ↵Lifeng Zheng
cpufreq_verify_current_freq() Move the check of cpufreq_driver->get into cpufreq_verify_current_freq() in case of calling it without check. Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20250709104145.2348017-4-zhenglifeng1@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-07-14cpufreq: Init policy->rwsem before it may be possibly usedLifeng Zheng
In cpufreq_policy_put_kobj(), policy->rwsem is used. But in cpufreq_policy_alloc(), if freq_qos_add_notifier() returns an error, error path via err_kobj_remove or err_min_qos_notifier will be reached and cpufreq_policy_put_kobj() will be called before policy->rwsem is initialized. Thus, the calling of init_rwsem() should be moved to where before these two error paths can be reached. Fixes: 67d874c3b2c6 ("cpufreq: Register notifiers with the PM QoS framework") Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20250709104145.2348017-3-zhenglifeng1@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-07-14cpufreq: Initialize cpufreq-based frequency-invariance laterLifeng Zheng
The cpufreq-based invariance is enabled in cpufreq_register_driver(), but never disabled after registration fails. Move the invariance initialization to where all other initializations have been successfully done to solve this problem. Fixes: 874f63531064 ("cpufreq: report whether cpufreq supports Frequency Invariance (FI)") Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20250709104145.2348017-2-zhenglifeng1@huawei.com [ rjw: New subject ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-07-14cpufreq: Remove duplicate check in __cpufreq_offline()Lifeng Zheng
The has_target() checks in __cpufreq_offline() are duplicate. Remove one of them and put the operations of exiting governor together with storing last governor's name. Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20250623133402.3120230-5-zhenglifeng1@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-07-14cpufreq: Contain scaling_cur_freq.attr in cpufreq_attrsLifeng Zheng
After commit c034b02e213d ("cpufreq: expose scaling_cur_freq sysfs file for set_policy() drivers"), the file scaling_cur_freq is exposed to all drivers. No need to create this file separately. It's better to be contained in cpufreq_attrs. Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20250623133402.3120230-4-zhenglifeng1@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-07-14cpufreq: intel_pstate: Add Granite Rapids support in no-HWP modeLi RongQing
Users may disable HWP in firmware, in which case intel_pstate wouldn't load unless the CPU model is explicitly supported. Signed-off-by: Li RongQing <lirongqing@baidu.com> Link: https://patch.msgid.link/20250623105601.3924-1-lirongqing@baidu.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-07-14cpufreq: intel_pstate: Always use HWP_DESIRED_PERF in passive modeRafael J. Wysocki
In the passive mode, intel_cpufreq_update_pstate() sets HWP_MIN_PERF in accordance with the target frequency to ensure delivering adequate performance, but it sets HWP_DESIRED_PERF to 0, so the processor has no indication that the desired performance level is actually equal to the floor one. This may cause it to choose a performance point way above the desired level. Moreover, this is inconsistent with intel_cpufreq_adjust_perf() which actually sets HWP_DESIRED_PERF in accordance with the target performance value. Address this by adjusting intel_cpufreq_update_pstate() to pass target_pstate as both the minimum and the desired performance levels to intel_cpufreq_hwp_update(). Fixes: a365ab6b9dfb ("cpufreq: intel_pstate: Implement the ->adjust_perf() callback") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Shashank Balaji <shashank.mahadasyam@sony.com> Link: https://patch.msgid.link/6173276.lOV4Wx5bFT@rjwysocki.net
2025-07-14iommufd: Do not allow _iommufd_object_alloc_ucmd if abort op is setNicolin Chen
An abort op was introduced to allow its caller to invoke it within a lock in the caller's function. On the other hand, _iommufd_object_alloc_ucmd() would invoke the abort op in iommufd_object_abort_and_destroy() that must be outside the caller's lock. So, these two cannot work together. Add a validation in the _iommufd_object_alloc_ucmd(). Pick -EOPNOTSUPP to reject the function call, indicating that the object allocator is buggy. Link: https://patch.msgid.link/r/20250710202354.1658511-1-nicolinc@nvidia.com Suggested-by: Xu Yilun <yilun.xu@linux.intel.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Xu Yilun <yilun.xu@linux.intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2025-07-14wifi: iwlwifi: remove support of several iwl_ppag_table_cmd versionsMiri Korenblit
We only need to support version 1, 5 and 7. Remove versions 2, 3, 4 and 6. Reviewed-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250711183056.10d91f675505.Idd3a6da568261ee738918f290168a2ddaa87196b@changeid
2025-07-14wifi: iwlwifi: remove support of version 4 of iwl_wowlan_rsc_tsc_params_cmdMiri Korenblit
This are not used in any of our devices. Remove it. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250711183056.89156be9bc7f.I5ff5c1055eaf4fef9bd73233ea4d95504634ceed@changeid
2025-07-14wifi: iwlwifi: remove support of versions 4 and 5 of iwl_alive_ntfMiri Korenblit
These are not used in any of our devices. Remove them. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250711183056.dd784443be53.I4ff3b2392294f5df2625a71e2deee3364e9708f6@changeid
2025-07-14wifi: iwlwifi: mld: remove support for iwl_mcc_update_resp versionsMiri Korenblit
iwlmld was planned to be used for HR/GF, which has versions 5/6, but it was decided at the end to use iwlmvm for HR/GF, so iwlmld only needs to support version 8. Remove versions 5 and 6 support. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250711183056.9c64bfbb16cb.I109bee4d4bf455cbffbb8d2340023338bcab886d@changeid
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-04 05:58:41 +0000