summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-04-13drm/amd/display: don't ignore alpha property on pre-multiplied modeMelissa Wen
"Pre-multiplied" is the default pixel blend mode for KMS/DRM, as documented in supported_modes of drm_plane_create_blend_mode_property(): https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/drm_blend.c In this mode, both 'pixel alpha' and 'plane alpha' participate in the calculation, as described by the pixel blend mode formula in KMS/DRM documentation: out.rgb = plane_alpha * fg.rgb + (1 - (plane_alpha * fg.alpha)) * bg.rgb Considering the blend config mechanisms we have in the driver so far, the alpha mode that better fits this blend mode is the _PER_PIXEL_ALPHA_COMBINED_GLOBAL_GAIN, where the value for global_gain is the plane alpha (global_alpha). With this change, alpha property stops to be ignored. It also addresses Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1734 v2: * keep the 8-bit value for global_alpha_value (Nicholas) * correct the logical ordering for combined global gain (Nicholas) * apply to dcn10 too (Nicholas) Signed-off-by: Melissa Wen <mwen@igalia.com> Tested-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Tested-by: Simon Ser <contact@emersion.fr> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2022-04-14Merge tag 'drm-intel-next-2022-04-13-1' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-next drm/i915 feature pull for v5.19: Features and functionality: - Add support for new Tile 4 format on DG2 (Stan) - Add support for new CCS clear color compression on DG2 (Mika, Juha-Pekka) - Add support for new render and media compression formats on DG2 (Matt) - Support multiple eDP and LVDS native mode refresh rates (Ville) - Support static DRRS (Ville) - ATS-M platform info (Matt) - RPL-S PCI IDs (Tejas) - Extend DP HDR support to HSW+ (Uma) - Bump ADL-P DMC version to v2.16 (Madhumitha) - Let users disable PSR2 while enabling PSR1 (José) Refactoring and cleanups: - Massive DRRS and panel fixed mode refactoring and cleanups (Ville) - Power well refactoring and cleanup (Imre) - Clean up and refactor crtc readout and compute config (Ville) - Use kernel string helpers (Lucas) - Refactor gmbus pin lookups and allocation (Jani) - PCH display cleanups (Ville) - DPLL and DPLL manager refactoring (Ville) - Include and header refactoring (Jani, Tvrtko) - DMC abstractions (Jani) - Non-x86 build refactoring (Casey) - VBT parsing refactoring (Ville) - Bigjoiner refactoring (Ville) - Optimize plane, pfit, scaler, etc. programming using unlocked writes (Ville) - Split several register writes in commit to noarm+arm pairs (Ville) - Clean up SAGV handling (Ville) - Clean up bandwidth and ddb allocation (Ville) - FBC cleanups (Ville) Fixes: - Fix native HDMI and DP HDMI DFP clock limits on deep color/4:2:0 (Ville) - Fix DMC firmware platform check (Lucas) - Fix cursor coordinates on bigjoiner secondary (Ville) - Fix MSO vs. bigjoiner timing confusion (Ville) - Fix ADL-P eDP voltage swing (José) - Fix VRR capability property update (Manasi) - Log DG2 SNPS PHY calibration errors (Matt, Lucas) - Fix PCODE request status checks (Stan) - Fix uncore unclaimed access warnings (Lucas) - Fix VBT new max TMDS clock parsing (Shawn) - Fix ADL-P non-existent underrun recovery (Swathi Dhanavanthri) - Fix ADL-N stepping info (Tejas) - Fix DPT mapping flags to contiguous (Stan) - Fix DG2 max display bandwidth (Vinod) - Fix DP low voltage SKU checks (Ankit) - Fix RPL-S VT-d translation enable via quirk (Tejas) - Fixes to PSR2 (José) - Fix PIPE_MBUS_DBOX_CTL programming (José) - Fix LTTPR capability read/check on DP 1.2 (Imre) - Fix ADL-P register corruption after DDI clock enabling (Imre) - Fix ADL-P MBUS DBOX BW and B credits (Caz) Merges: - Backmerge drm-next (Rodrigo, Jani) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/874k2xgewe.fsf@intel.com
2022-04-13perf tools: Fix segfault accessing sample_id xyarrayAdrian Hunter
perf_evsel::sample_id is an xyarray which can cause a segfault when accessed beyond its size. e.g. # perf record -e intel_pt// -C 1 sleep 1 Segmentation fault (core dumped) # That is happening because a dummy event is opened to capture text poke events accross all CPUs, however the mmap logic is allocating according to the number of user_requested_cpus. In general, perf sometimes uses the evsel cpus to open events, and sometimes the evlist user_requested_cpus. However, it is not necessary to determine which case is which because the opened event file descriptors are also in an xyarray, the size of whch can be used to correctly allocate the size of the sample_id xyarray, because there is one ID per file descriptor. Note, in the affected code path, perf_evsel fd array is subsequently used to get the file descriptor for the mmap, so it makes sense for the xyarrays to be the same size there. Fixes: d1a177595b3a824c ("libperf: Adopt perf_evlist__mmap()/munmap() from tools/perf") Fixes: 246eba8e9041c477 ("perf tools: Add support for PERF_RECORD_TEXT_POKE") Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Ian Rogers <irogers@google.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: stable@vger.kernel.org # 5.5+ Link: https://lore.kernel.org/r/20220413114232.26914-1-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2022-04-13perf stat: Fix error check return value of hashmap__new(), must use IS_ERR()Lv Ruyi
hashmap__new() returns ERR_PTR(-ENOMEM) when it fails, so we should use IS_ERR() to check it in error handling path. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Lv Ruyi <lv.ruyi@zte.com.cn> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Clark <james.clark@arm.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: https://lore.kernel.org/r/20220413093302.2538128-1-lv.ruyi@zte.com.cn Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2022-04-13fbcon: Fix delayed takeover lockingDaniel Vetter
I messed up the delayed takover path in the locking conversion in 6e7da3af008b ("fbcon: Move console_lock for register/unlink/unregister"). If CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER is enabled, fbcon take-over doesn't take place when calling fbcon_fb_registered(). Instead, is deferred using a workqueue and its fbcon_register_existing_fbs() function calls to fbcon_fb_registered() again for each registered fbcon fb. This leads to the console_lock tried to be held twice, causing a deadlock. Fix it by re-extracting the lockless function and using it in the delayed takeover path, where we need to hold the lock already to iterate over the list of already registered fb. Well the current code still is broken in there (since the list is protected by a registration_lock, which we can't take here because it nests the other way round with console_lock), but in the future this will be a list protected by console_lock when this is all sorted out. While reviewing the broken commit I realized that I've left some outdated comments about the locking behind. Fix those too. v2: Improve commit message (Javier) Reported-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Cc: Nathan Chancellor <nathan@kernel.org> Fixes: 6e7da3af008b ("fbcon: Move console_lock for register/unlink/unregister") Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Du Cheng <ducheng2@gmail.com> Cc: Claudio Suarez <cssk@net-c.es> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Matthew Wilcox <willy@infradead.org> Cc: Zheyu Ma <zheyuma97@gmail.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Helge Deller <deller@gmx.de> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220413082128.348186-1-daniel.vetter@ffwll.ch
2022-04-13cpu/hotplug: Remove the 'cpu' member of cpuhp_cpu_stateSteven Price
Currently the setting of the 'cpu' member of struct cpuhp_cpu_state in cpuhp_create() is too late as it is used earlier in _cpu_up(). If kzalloc_node() in __smpboot_create_thread() fails then the rollback will be done with st->cpu==0 causing CPU0 to be erroneously set to be dying, causing the scheduler to get mightily confused and throw its toys out of the pram. However the cpu number is actually available directly, so simply remove the 'cpu' member and avoid the problem in the first place. Fixes: 2ea46c6fc945 ("cpumask/hotplug: Fix cpu_dying() state tracking") Signed-off-by: Steven Price <steven.price@arm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20220411152233.474129-2-steven.price@arm.com
2022-04-13vfio/pci: Fix vf_token mechanism when device-specific VF drivers are usedJason Gunthorpe
get_pf_vdev() tries to check if a PF is a VFIO PF by looking at the driver: if (pci_dev_driver(physfn) != pci_dev_driver(vdev->pdev)) { However now that we have multiple VF and PF drivers this is no longer reliable. This means that security tests realted to vf_token can be skipped by mixing and matching different VFIO PCI drivers. Instead of trying to use the driver core to find the PF devices maintain a linked list of all PF vfio_pci_core_device's that we have called pci_enable_sriov() on. When registering a VF just search the list to see if the PF is present and record the match permanently in the struct. PCI core locking prevents a PF from passing pci_disable_sriov() while VF drivers are attached so the VFIO owned PF becomes a static property of the VF. In common cases where vfio does not own the PF the global list remains empty and the VF's pointer is statically NULL. This also fixes a lockdep splat from recursive locking of the vfio_group::device_lock between vfio_device_get_from_name() and vfio_device_get_from_dev(). If the VF and PF share the same group this would deadlock. Fixes: ff53edf6d6ab ("vfio/pci: Split the pci_driver code out of vfio_pci_core.c") Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/0-v3-876570980634+f2e8-vfio_vf_token_jgg@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2022-04-13dm zone: fix NULL pointer dereference in dm_zone_map_bioMike Snitzer
Commit 0fbb4d93b38b ("dm: add dm_submit_bio_remap interface") changed the alloc_io() function to delay the initialization of struct dm_io's orig_bio member, leaving it NULL until after the dm_io and associated user submitted bio is processed by __split_and_process_bio(). This change causes a NULL pointer dereference in dm_zone_map_bio() when the original user bio is inspected to detect the need for zone append command emulation. Fix this NULL pointer by updating dm_zone_map_bio() to not access ->orig_bio when the same info can be accessed from the clone of the ->orig_bio _before_ any ->map processing. Save off the bio_op() and bio_sectors() for the clone and then use the saved orig_bio_details as needed. Fixes: 0fbb4d93b38b ("dm: add dm_submit_bio_remap interface") Reported-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Signed-off-by: Mike Snitzer <snitzer@kernel.org>
2022-04-13dm mpath: only use ktime_get_ns() in historical selectorKhazhismel Kumykov
Mixing sched_clock() and ktime_get_ns() usage will give bad results. Switch hst_select_path() from using sched_clock() to ktime_get_ns(). Also rename path_service_time()'s 'sched_now' variable to 'now'. Fixes: 2613eab11996 ("dm mpath: add Historical Service Time Path Selector") Signed-off-by: Khazhismel Kumykov <khazhy@google.com> Signed-off-by: Mike Snitzer <snitzer@kernel.org>
2022-04-13cifs: potential buffer overflow in handling symlinksHarshit Mogalapalli
Smatch printed a warning: arch/x86/crypto/poly1305_glue.c:198 poly1305_update_arch() error: __memcpy() 'dctx->buf' too small (16 vs u32max) It's caused because Smatch marks 'link_len' as untrusted since it comes from sscanf(). Add a check to ensure that 'link_len' is not larger than the size of the 'link_str' buffer. Fixes: c69c1b6eaea1 ("cifs: implement CIFSParseMFSymlink()") Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com> Signed-off-by: Steve French <stfrench@microsoft.com>
2022-04-13ARM: dts: at91: fix pinctrl phandlesClaudiu Beznea
Commit bf781869e5cf ("ARM: dts: at91: add pinctrl-{names, 0} for all gpios") introduces pinctrl phandles for pins used by individual controllers to avoid failures due to commit 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges"). For SPI controllers available on SAMA5D4 and SAMA5D3 some of the pins are defined in SoC specific dtsi on behalf of pinctrl-0. Adding extra pinctrl phandles on board specific dts also on behalf of pinctrl-0 overwrite the pinctrl-0 phandle specified in SoC specific dtsi. Thus add the board specific pinctrl to pinctrl-1. Fixes: bf781869e5cf ("ARM: dts: at91: add pinctrl-{names, 0} for all gpios") Depends-on: 5c8b49852910 ("ARM: dts: at91: sama5d4_xplained: fix pinctrl phandle name") Reported-by: Ajay Kathat <ajay.kathat@microchip.com> Co-developed-by: Ajay Kathat <ajay.kathat@microchip.com> Signed-off-by: Ajay Kathat <ajay.kathat@microchip.com> Tested-by: Ajay Kathat <ajay.kathat@microchip.com> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20220331141323.194355-2-claudiu.beznea@microchip.com
2022-04-13ARM: dts: at91: sama5d4_xplained: fix pinctrl phandle nameClaudiu Beznea
Pinctrl phandle is for spi1 so rename it to reflect this. Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20220331141323.194355-1-claudiu.beznea@microchip.com
2022-04-13smp: Fix offline cpu check in flush_smp_call_function_queue()Nadav Amit
The check in flush_smp_call_function_queue() for callbacks that are sent to offline CPUs currently checks whether the queue is empty. However, flush_smp_call_function_queue() has just deleted all the callbacks from the queue and moved all the entries into a local list. This checks would only be positive if some callbacks were added in the short time after llist_del_all() was called. This does not seem to be the intention of this check. Change the check to look at the local list to which the entries were moved instead of the queue from which all the callbacks were just removed. Fixes: 8d056c48e4862 ("CPU hotplug, smp: flush any pending IPI callbacks before CPU offline") Signed-off-by: Nadav Amit <namit@vmware.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20220319072015.1495036-1-namit@vmware.com
2022-04-13ARM: dts: at91: Describe regulators on at91sam9g20ekMark Brown
The at91sam9g20ek has no software controllable regulators, only some fixed discrete regulators, but they are there and currently the wm8731 driver does try to use them. Show the supplies in the DT and map them for the wm8731 so things start up cleanly. Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20220404102806.581374-3-broonie@kernel.org
2022-04-13ARM: dts: at91: Map MCLK for wm8731 on at91sam9g20ekMark Brown
The MCLK of the WM8731 on the AT91SAM9G20-EK board is connected to the PCK0 output of the SoC and is expected to be set to 12MHz. Previously this was mapped using pre-common clock API calls in the audio machine driver but the conversion to the common clock framework broke that so describe things in the DT instead. Fixes: ff78a189b0ae55f ("ARM: at91: remove old at91-specific clock driver") Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20220404102806.581374-2-broonie@kernel.org
2022-04-13ARM: dts: at91: Fix boolean properties with valuesRob Herring
Boolean properties in DT are present or not present and don't take a value. A property such as 'foo = <0>;' evaluated to true. IOW, the value doesn't matter. It may have been intended that 0 values are false, but there is no change in behavior with this patch. Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/Yk3leykDEKGBN8rk@robh.at.kernel.org
2022-04-13ARM: dts: at91: use generic node name for dataflashKrzysztof Kozlowski
The node names should be generic, so use "flash" for dataflash nodes and for cfi-flash. Suggested-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20220412105013.249793-1-krzysztof.kozlowski@linaro.org
2022-04-13ARM: dts: at91: align SPI NOR node name with dtschemaKrzysztof Kozlowski
The node names should be generic and SPI NOR dtschema expects "flash". Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20220407143223.295344-1-krzysztof.kozlowski@linaro.org
2022-04-13ARM: dts: at91: sama7g5ek: Align the impedance of the QSPI0's HSIO and PCB linesTudor Ambarus
The impedance of the QSPI PCB lines on the sama7g5ek is 50 Ohms. Align the output impedance of the QSPI0 HSIOs by setting a medium drive strength which corresponds to an impedance of 56 Ohms when VDD is in the 3.0V - 3.6V range. The high drive strength setting corresponds to an output impedance of 42 Ohms on the QSPI0 HSIOs. Suggested-by: Mihai Sain <mihai.sain@microchip.com> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20220406130505.422042-1-tudor.ambarus@microchip.com
2022-04-13ARM: dts: at91: sama7g5ek: enable pull-up on flexcom3 console linesEugen Hristev
Flexcom3 is used as board console serial. There are no pull-ups on these lines on the board. This means that if a cable is not connected (that has pull-ups included), stray characters could appear on the console as the floating pins voltage levels are interpreted as incoming characters. To avoid this problem, enable the internal pull-ups on these lines. Fixes: 7540629e2fc7 ("ARM: dts: at91: add sama7g5 SoC DT and sama7g5-ek") Cc: stable@vger.kernel.org # v5.15+ Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20220307113827.2419331-1-eugen.hristev@microchip.com
2022-04-13dm integrity: fix memory corruption when tag_size is less than digest sizeMikulas Patocka
It is possible to set up dm-integrity in such a way that the "tag_size" parameter is less than the actual digest size. In this situation, a part of the digest beyond tag_size is ignored. In this case, dm-integrity would write beyond the end of the ic->recalc_tags array and corrupt memory. The corruption happened in integrity_recalc->integrity_sector_checksum->crypto_shash_final. Fix this corruption by increasing the tags array so that it has enough padding at the end to accomodate the loop in integrity_recalc() being able to write a full digest size for the last member of the tags array. Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@kernel.org>
2022-04-13ARM: dts: at91: sama7g5: Swap `rx` and `tx` for `i2c` nodesSergiu Moga
Swap `rx` and `tx` for the `dma-names` property of the `i2c` nodes in order to maintain consistency across Microchip/Atmel SoC files. Signed-off-by: Sergiu Moga <sergiu.moga@microchip.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20220310114553.184763-2-sergiu.moga@microchip.com
2022-04-13io_uring: fix poll error reportingPavel Begunkov
We should not return an error code in req->result in io_poll_check_events(), because it may get mangled and returned as success. Just return the error code directly, the callers will fail the request or proceed accordingly. Fixes: 6bf9c47a3989 ("io_uring: defer file assignment") Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://lore.kernel.org/r/5f03514ee33324dc811fb93df84aee0f695fb044.1649862516.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-04-13io_uring: fix poll file assign deadlockPavel Begunkov
We pass "unlocked" into io_assign_file() in io_poll_check_events(), which can lead to double locking. Fixes: 6bf9c47a3989 ("io_uring: defer file assignment") Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://lore.kernel.org/r/2476d4ae46554324b599ee4055447b105f20a75a.1649862516.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-04-13io_uring: use right issue_flags for splice/teePavel Begunkov
Pass right issue_flags into into io_file_get_fixed() instead of IO_URING_F_UNLOCKED. It's probably not a problem at the moment but let's do it safer. Fixes: 6bf9c47a3989 ("io_uring: defer file assignment") Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://lore.kernel.org/r/7d242daa9df5d776907686977cd29fbceb4a2d8d.1649862516.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-04-13e1000e: Fix possible overflow in LTR decodingSasha Neftin
When we decode the latency and the max_latency, u16 value may not fit the required size and could lead to the wrong LTR representation. Scaling is represented as: scale 0 - 1 (2^(5*0)) = 2^0 scale 1 - 32 (2^(5 *1))= 2^5 scale 2 - 1024 (2^(5 *2)) =2^10 scale 3 - 32768 (2^(5 *3)) =2^15 scale 4 - 1048576 (2^(5 *4)) = 2^20 scale 5 - 33554432 (2^(5 *4)) = 2^25 scale 4 and scale 5 required 20 and 25 bits respectively. scale 6 reserved. Replace the u16 type with the u32 type and allow corrected LTR representation. Cc: stable@vger.kernel.org Fixes: 44a13a5d99c7 ("e1000e: Fix the max snoop/no-snoop latency for 10M") Reported-by: James Hutchinson <jahutchinson99@googlemail.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=215689 Suggested-by: Dima Ruinskiy <dima.ruinskiy@intel.com> Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Naama Meir <naamax.meir@linux.intel.com> Tested-by: James Hutchinson <jahutchinson99@googlemail.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-04-13igc: Fix suspending when PTM is activeVinicius Costa Gomes
Some mainboard/CPU combinations, in particular, Alder Lake-S with a W680 mainboard, have shown problems (system hangs usually, no kernel logs) with suspend/resume when PCIe PTM is enabled and active. In some cases, it could be reproduced when removing the igc module. The best we can do is to stop PTM dialogs from the downstream/device side before the interface is brought down. PCIe PTM will be re-enabled when the interface is being brought up. Fixes: a90ec8483732 ("igc: Add support for PTP getcrosststamp()") Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Tested-by: Naama Meir <naamax.meir@linux.intel.com> Acked-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-04-13spi: atmel-quadspi: Fix the buswidth adjustment between spi-mem and controllerTudor Ambarus
Use the spi_mem_default_supports_op() core helper in order to take into account the buswidth specified by the user in device tree. Cc: <stable@vger.kernel.org> Fixes: 0e6aae08e9ae ("spi: Add QuadSPI driver for Atmel SAMA5D2") Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20220406133604.455356-1-tudor.ambarus@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-13igc: Fix BUG: scheduling while atomicSasha Neftin
Replace usleep_range() method with udelay() method to allow atomic contexts in low-level MDIO access functions. The following issue can be seen by doing the following: $ modprobe -r bonding $ modprobe -v bonding max_bonds=1 mode=1 miimon=100 use_carrier=0 $ ip link set bond0 up $ ifenslave bond0 eth0 eth1 [ 982.357308] BUG: scheduling while atomic: kworker/u64:0/9/0x00000002 [ 982.364431] INFO: lockdep is turned off. [ 982.368824] Modules linked in: bonding sctp ip6_udp_tunnel udp_tunnel mlx4_ib ib_uverbs ib_core mlx4_en mlx4_core nfp tls sunrpc intel_rapl_msr iTCO_wdt iTCO_vendor_support mxm_wmi dcdbas intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate intel_uncore pcspkr lpc_ich mei_me ipmi_ssif mei ipmi_si ipmi_devintf ipmi_msghandler wmi acpi_power_meter xfs libcrc32c sr_mod cdrom sd_mod t10_pi sg mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm ahci libahci crc32c_intel libata i2c_algo_bit tg3 megaraid_sas igc dm_mirror dm_region_hash dm_log dm_mod [last unloaded: bonding] [ 982.437941] CPU: 25 PID: 9 Comm: kworker/u64:0 Kdump: loaded Tainted: G W --------- - - 4.18.0-348.el8.x86_64+debug #1 [ 982.451333] Hardware name: Dell Inc. PowerEdge R730/0H21J3, BIOS 2.7.0 12/005/2017 [ 982.459791] Workqueue: bond0 bond_mii_monitor [bonding] [ 982.465622] Call Trace: [ 982.468355] dump_stack+0x8e/0xd0 [ 982.472056] __schedule_bug.cold.60+0x3a/0x60 [ 982.476919] __schedule+0x147b/0x1bc0 [ 982.481007] ? firmware_map_remove+0x16b/0x16b [ 982.485967] ? hrtimer_fixup_init+0x40/0x40 [ 982.490625] schedule+0xd9/0x250 [ 982.494227] schedule_hrtimeout_range_clock+0x10d/0x2c0 [ 982.500058] ? hrtimer_nanosleep_restart+0x130/0x130 [ 982.505598] ? hrtimer_init_sleeper_on_stack+0x90/0x90 [ 982.511332] ? usleep_range+0x88/0x130 [ 982.515514] ? recalibrate_cpu_khz+0x10/0x10 [ 982.520279] ? ktime_get+0xab/0x1c0 [ 982.524175] ? usleep_range+0x88/0x130 [ 982.528355] usleep_range+0xdd/0x130 [ 982.532344] ? console_conditional_schedule+0x30/0x30 [ 982.537987] ? igc_put_hw_semaphore+0x17/0x60 [igc] [ 982.543432] igc_read_phy_reg_gpy+0x111/0x2b0 [igc] [ 982.548887] igc_phy_has_link+0xfa/0x260 [igc] [ 982.553847] ? igc_get_phy_id+0x210/0x210 [igc] [ 982.558894] ? lock_acquire+0x34d/0x890 [ 982.563187] ? lock_downgrade+0x710/0x710 [ 982.567659] ? rcu_read_unlock+0x50/0x50 [ 982.572039] igc_check_for_copper_link+0x106/0x210 [igc] [ 982.577970] ? igc_config_fc_after_link_up+0x840/0x840 [igc] [ 982.584286] ? rcu_read_unlock+0x50/0x50 [ 982.588661] ? lock_release+0x591/0xb80 [ 982.592939] ? lock_release+0x591/0xb80 [ 982.597220] igc_has_link+0x113/0x330 [igc] [ 982.601887] ? lock_downgrade+0x710/0x710 [ 982.606362] igc_ethtool_get_link+0x6d/0x90 [igc] [ 982.611614] bond_check_dev_link+0x131/0x2c0 [bonding] [ 982.617350] ? bond_time_in_interval+0xd0/0xd0 [bonding] [ 982.623277] ? rcu_read_lock_held+0x62/0xc0 [ 982.627944] ? rcu_read_lock_sched_held+0xe0/0xe0 [ 982.633198] bond_mii_monitor+0x314/0x2500 [bonding] [ 982.638738] ? lock_contended+0x880/0x880 [ 982.643214] ? bond_miimon_link_change+0xa0/0xa0 [bonding] [ 982.649336] ? lock_acquire+0x34d/0x890 [ 982.653615] ? lock_downgrade+0x710/0x710 [ 982.658089] ? debug_object_deactivate+0x221/0x340 [ 982.663436] ? rcu_read_unlock+0x50/0x50 [ 982.667811] ? debug_print_object+0x2b0/0x2b0 [ 982.672672] ? __switch_to_asm+0x41/0x70 [ 982.677049] ? __switch_to_asm+0x35/0x70 [ 982.681426] ? _raw_spin_unlock_irq+0x24/0x40 [ 982.686288] ? trace_hardirqs_on+0x20/0x195 [ 982.690956] ? _raw_spin_unlock_irq+0x24/0x40 [ 982.695818] process_one_work+0x8f0/0x1770 [ 982.700390] ? pwq_dec_nr_in_flight+0x320/0x320 [ 982.705443] ? debug_show_held_locks+0x50/0x50 [ 982.710403] worker_thread+0x87/0xb40 [ 982.714489] ? process_one_work+0x1770/0x1770 [ 982.719349] kthread+0x344/0x410 [ 982.722950] ? kthread_insert_work_sanity_check+0xd0/0xd0 [ 982.728975] ret_from_fork+0x3a/0x50 Fixes: 5586838fe9ce ("igc: Add code for PHY support") Reported-by: Corinna Vinschen <vinschen@redhat.com> Suggested-by: Dima Ruinskiy <dima.ruinskiy@intel.com> Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Corinna Vinschen <vinschen@redhat.com> Tested-by: Naama Meir <naamax.meir@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-04-13igc: Fix infinite loop in release_swfw_syncSasha Neftin
An infinite loop may occur if we fail to acquire the HW semaphore, which is needed for resource release. This will typically happen if the hardware is surprise-removed. At this stage there is nothing to do, except log an error and quit. Fixes: c0071c7aa5fe ("igc: Add HW initialization code") Suggested-by: Dima Ruinskiy <dima.ruinskiy@intel.com> Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Naama Meir <naamax.meir@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-04-13drm/panel: lvds: Use bus_flags from DT panel-timing propertyMarek Vasut
This driver currently rewrites bus_flags based solely on the value of DT property 'data-mirror' and ignores bus_flags which might have been set in DT panel-timing node. Specificaly, the 'de-active' DT property sets DRM_BUS_FLAG_DE_ bus_flags. Since of_get_drm_panel_display_mode() conveniently parses the bus_flags out of DT panel-timing property, just ORR them with bus_flags inferred from 'data-mirror' DT property and use the result as panel bus_flags. This fixes handling of panels with 'panel-timing { de-active = <1>; };'. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> Signed-off-by: Marek Vasut <marex@denx.de> Cc: Christoph Niedermaier <cniedermaier@dh-electronics.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dmitry Osipenko <digetx@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> To: dri-devel@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20220401162154.295152-2-marex@denx.de
2022-04-13drm/panel: lvds: Simplify mode parsingMarek Vasut
The mode parsing is currently implemented in three steps: of_get_display_timing() - DT panel-timing to struct display_timing videomode_from_timing() - struct display_timing to struct videomode drm_display_mode_from_videomode() - struct videomode to struct drm_display_mode Replace all that with simple of_get_drm_panel_display_mode() call, which already populates struct drm_display_mode and then duplicate that mode in panel_lvds_get_modes() each time, since the mode does not change. Nice bonus is the bus_flags parsed by of_get_drm_panel_display_mode() out of panel-timing DT node, which is used in subsequent patch to fix handling of 'de-active' DT property. Tested-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> Signed-off-by: Marek Vasut <marex@denx.de> Cc: Christoph Niedermaier <cniedermaier@dh-electronics.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dmitry Osipenko <digetx@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> To: dri-devel@lists.freedesktop.org Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220401162154.295152-1-marex@denx.de
2022-04-13drm: bridge: icn6211: Convert to regmapMarek Vasut
To make debugging easier, convert driver to regmap. Implement read and write regmap tables for known registers, keep all known register readable and mark those which are obviously read-only as not writeable. Use common I2C regmap for the I2C configuration, implement custom regmap bus for DSI configuration. The later is mandatory as this chip requires one extra byte set to read access length between register address and data. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Mark Brown <broonie@kernel.org> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> To: dri-devel@lists.freedesktop.org Acked-by: Mark Brown <broonie@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220403171004.368464-1-marex@denx.de
2022-04-13drm/i915/fbc: Call intel_fbc_activate() directly from frontbuffer flushVille Syrjälä
Remove the pointless detour via __intel_fbc_post_update() during frontbuffer flush. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-8-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2022-04-13drm/i915/fbc: Introduce intel_fbc_sanitize()Ville Syrjälä
Let's make sure FBC is always disabled when we start to take over the hardware state. I suspect this should never really happen, since the only time when we really should be taking over with the display already active is when the previous state was progammed by the BIOS, which likely shouldn't use FBC. This could be driver init, or S4 resume when the boot kernel doesn't load i915. But I suppose no harm in keeping this code around for exra safety since it's quite trivial. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-7-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2022-04-13drm/i915/fbc: Remove intel_fbc_global_disable()Ville Syrjälä
By the time intel_fbc_global_disable() gets called during driver teardown we should have already disabled all the crtcs, so no way FBC should be enabled at this point. And I have no idea what the other user (i915_restore_display()) is even trying to achieve. So let's just throw intel_fbc_global_disable() into the bin. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-6-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2022-04-13drm/i915: Remove remaining locks from i9xx plane udpatesVille Syrjälä
Now that fbc no longer nukes while a flip is pending we can remove the last uncore.lock from the i9xx plane code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-5-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2022-04-13drm/i915/fbc: Skip nuke when flip is pendingVille Syrjälä
Don't issue a nuke from frontbuffer flush while a flip is pending. This avoids the DSPADDR/DSPSURF rmw abuse from the pre-snb nuke from racing with the DSPADDR/DSPSURF write being performed by the flip/plane update. The flip itself will already cause the nuke so a double nuke is redundant. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-4-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2022-04-13drm/i915/fbc: Streamline frontbuffer busy bits handlingVille Syrjälä
If the frontbuffer bits say this fbc instance isn't affected just skip the whole thing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-3-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2022-04-13drm/i915/fbc: Eliminate possible_framebuffer_bitsVille Syrjälä
Not sure what the point of this fbc->possible_frontbuffer_bits is. And especially don't see why it's returning all the bits when fbc is not even enabled. So let's just get rid of this and only say we are interested in the plane's frontbuffer bits when fbc is actually enabled. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-2-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com>
2022-04-13nfc: nci: add flush_workqueue to prevent uafLin Ma
Our detector found a concurrent use-after-free bug when detaching an NCI device. The main reason for this bug is the unexpected scheduling between the used delayed mechanism (timer and workqueue). The race can be demonstrated below: Thread-1 Thread-2 | nci_dev_up() | nci_open_device() | __nci_request(nci_reset_req) | nci_send_cmd | queue_work(cmd_work) nci_unregister_device() | nci_close_device() | ... del_timer_sync(cmd_timer)[1] | ... | Worker nci_free_device() | nci_cmd_work() kfree(ndev)[3] | mod_timer(cmd_timer)[2] In short, the cleanup routine thought that the cmd_timer has already been detached by [1] but the mod_timer can re-attach the timer [2], even it is already released [3], resulting in UAF. This UAF is easy to trigger, crash trace by POC is like below [ 66.703713] ================================================================== [ 66.703974] BUG: KASAN: use-after-free in enqueue_timer+0x448/0x490 [ 66.703974] Write of size 8 at addr ffff888009fb7058 by task kworker/u4:1/33 [ 66.703974] [ 66.703974] CPU: 1 PID: 33 Comm: kworker/u4:1 Not tainted 5.18.0-rc2 #5 [ 66.703974] Workqueue: nfc2_nci_cmd_wq nci_cmd_work [ 66.703974] Call Trace: [ 66.703974] <TASK> [ 66.703974] dump_stack_lvl+0x57/0x7d [ 66.703974] print_report.cold+0x5e/0x5db [ 66.703974] ? enqueue_timer+0x448/0x490 [ 66.703974] kasan_report+0xbe/0x1c0 [ 66.703974] ? enqueue_timer+0x448/0x490 [ 66.703974] enqueue_timer+0x448/0x490 [ 66.703974] __mod_timer+0x5e6/0xb80 [ 66.703974] ? mark_held_locks+0x9e/0xe0 [ 66.703974] ? try_to_del_timer_sync+0xf0/0xf0 [ 66.703974] ? lockdep_hardirqs_on_prepare+0x17b/0x410 [ 66.703974] ? queue_work_on+0x61/0x80 [ 66.703974] ? lockdep_hardirqs_on+0xbf/0x130 [ 66.703974] process_one_work+0x8bb/0x1510 [ 66.703974] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 66.703974] ? pwq_dec_nr_in_flight+0x230/0x230 [ 66.703974] ? rwlock_bug.part.0+0x90/0x90 [ 66.703974] ? _raw_spin_lock_irq+0x41/0x50 [ 66.703974] worker_thread+0x575/0x1190 [ 66.703974] ? process_one_work+0x1510/0x1510 [ 66.703974] kthread+0x2a0/0x340 [ 66.703974] ? kthread_complete_and_exit+0x20/0x20 [ 66.703974] ret_from_fork+0x22/0x30 [ 66.703974] </TASK> [ 66.703974] [ 66.703974] Allocated by task 267: [ 66.703974] kasan_save_stack+0x1e/0x40 [ 66.703974] __kasan_kmalloc+0x81/0xa0 [ 66.703974] nci_allocate_device+0xd3/0x390 [ 66.703974] nfcmrvl_nci_register_dev+0x183/0x2c0 [ 66.703974] nfcmrvl_nci_uart_open+0xf2/0x1dd [ 66.703974] nci_uart_tty_ioctl+0x2c3/0x4a0 [ 66.703974] tty_ioctl+0x764/0x1310 [ 66.703974] __x64_sys_ioctl+0x122/0x190 [ 66.703974] do_syscall_64+0x3b/0x90 [ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 66.703974] [ 66.703974] Freed by task 406: [ 66.703974] kasan_save_stack+0x1e/0x40 [ 66.703974] kasan_set_track+0x21/0x30 [ 66.703974] kasan_set_free_info+0x20/0x30 [ 66.703974] __kasan_slab_free+0x108/0x170 [ 66.703974] kfree+0xb0/0x330 [ 66.703974] nfcmrvl_nci_unregister_dev+0x90/0xd0 [ 66.703974] nci_uart_tty_close+0xdf/0x180 [ 66.703974] tty_ldisc_kill+0x73/0x110 [ 66.703974] tty_ldisc_hangup+0x281/0x5b0 [ 66.703974] __tty_hangup.part.0+0x431/0x890 [ 66.703974] tty_release+0x3a8/0xc80 [ 66.703974] __fput+0x1f0/0x8c0 [ 66.703974] task_work_run+0xc9/0x170 [ 66.703974] exit_to_user_mode_prepare+0x194/0x1a0 [ 66.703974] syscall_exit_to_user_mode+0x19/0x50 [ 66.703974] do_syscall_64+0x48/0x90 [ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0xae To fix the UAF, this patch adds flush_workqueue() to ensure the nci_cmd_work is finished before the following del_timer_sync. This combination will promise the timer is actually detached. Fixes: 6a2968aaf50c ("NFC: basic NCI protocol implementation") Signed-off-by: Lin Ma <linma@zju.edu.cn> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-04-13spi: cadence-quadspi: fix incorrect supports_op() return valueMatthias Schiffer
Since the conversion to spi-mem, the driver advertised support for various operations that cqspi_set_protocol() was never expected to handle correctly - in particuar all non-DTR operations with command or address buswidth > 1. For DTR, all operations except for 8-8-8 would fail, as cqspi_set_protocol() returns -EINVAL. In non-DTR mode, this resulted in data corruption for SPI-NOR flashes that support such operations. As a minimal fix that can be backported to stable kernels, simply disallow the unsupported operations again to avoid this issue. Fixes: a314f6367787 ("mtd: spi-nor: Convert cadence-quadspi to use spi-mem framework") Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Link: https://lore.kernel.org/r/20220406132832.199777-1-matthias.schiffer@ew.tq-group.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-13net: dsa: realtek: don't parse compatible string for RTL8366SAlvin Šipraga
This switch is not even supported, but if someone were to actually put this compatible string "realtek,rtl8366s" in their device tree, they would be greeted with a kernel panic because the probe function would dereference NULL. So let's just remove it. Link: https://lore.kernel.org/all/CACRpkdYdKZs0WExXc3=0yPNOwP+oOV60HRz7SRoGjZvYHaT=1g@mail.gmail.com/ Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-04-13net: dsa: realtek: fix Kconfig to assure consistent driver linkageAlvin Šipraga
The kernel test robot reported a build failure: or1k-linux-ld: drivers/net/dsa/realtek/realtek-smi.o:(.rodata+0x16c): undefined reference to `rtl8366rb_variant' ... with the following build configuration: CONFIG_NET_DSA_REALTEK=y CONFIG_NET_DSA_REALTEK_SMI=y CONFIG_NET_DSA_REALTEK_RTL8365MB=y CONFIG_NET_DSA_REALTEK_RTL8366RB=m The problem here is that the realtek-smi interface driver gets built-in, while the rtl8366rb switch subdriver gets built as a module, hence the symbol rtl8366rb_variant is not reachable when defining the OF device table in the interface driver. The Kconfig dependencies don't help in this scenario because they just say that the subdriver(s) depend on at least one interface driver. In fact, the subdrivers don't depend on the interface drivers at all, and can even be built even in their absence. Somewhat strangely, the interface drivers can also be built in the absence of any subdriver, BUT, if a subdriver IS enabled, then it must be reachable according to the linkage of the interface driver: effectively what the IS_REACHABLE() macro achieves. If it is not reachable, the above kind of linker error will be observed. Rather than papering over the above build error by simply using IS_REACHABLE(), we can do a little better and admit that it is actually the interface drivers that have a dependency on the subdrivers. So this patch does exactly that. Specifically, we ensure that: 1. The interface drivers' Kconfig symbols must have a value no greater than the value of any subdriver Kconfig symbols. 2. The subdrivers should by default enable both interface drivers, since most users probably want at least one of them; those interface drivers can be explicitly disabled however. What this doesn't do is prevent a user from building only a subdriver, without any interface driver. To that end, add an additional line of help in the menu to guide users in the right direction. Link: https://lore.kernel.org/all/202204110757.XIafvVnj-lkp@intel.com/ Reported-by: kernel test robot <lkp@intel.com> Fixes: aac94001067d ("net: dsa: realtek: add new mdio interface for drivers") Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-04-13dma-buf-map: remove renamed header fileKarol Herbst
commit 7938f4218168 ("dma-buf-map: Rename to iosys-map") already renamed this file, but it got brought back by a merge. Delete it for real this time. Fixes: 30424ebae8df ("Merge tag 'drm-intel-gt-next-2022-02-17' of git://anongit.freedesktop.org/drm/drm-intel into drm-intel-next") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Karol Herbst <kherbst@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220411134404.524776-1-kherbst@redhat.com
2022-04-13drm/amdkfd: Cleanup IO links during KFD device removalMukul Joshi
Currently, the IO-links to the device being removed from topology, are not cleared. As a result, there would be dangling links left in the KFD topology. This patch aims to fix the following: 1. Cleanup all IO links to the device being removed. 2. Ensure that node numbering in sysfs and nodes proximity domain values are consistent after the device is removed: a. Adding a device and removing a GPU device are made mutually exclusive. b. The global proximity domain counter is no longer required to be an atomic counter. A normal 32-bit counter can be used instead. 3. Update generation_count to let user-mode know that topology has changed due to device removal. CC: Shuotao Xu <shuotaoxu@microsoft.com> Reviewed-by: Shuotao Xu <shuotaoxu@microsoft.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Mukul Joshi <mukul.joshi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-04-13drm/amd/amdgpu: Not request init data for MS_HYPERV with vega10Yongqiang Sun
MS_HYPERV with vega10 doesn't have the interface to process request init data msg. Check hypervisor type to not send the request for MS_HYPERV. Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by: Alice Wong <shiwei.wong@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-04-13drm/amdkfd: shrink bitmap size in struct svm_validate_contextLang Yu
A MAX_GPU_INSTANCE bits bitmap will suffice. Signed-off-by: Lang Yu <Lang.Yu@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-04-13drm/amd/display: extract update stream allocation to link_hwssWenjing Liu
[why] Extract update stream allocation table into link hwss as part of the link hwss refactor work. Reviewed-by: George Shen <George.Shen@amd.com> Reviewed-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Acked-by: Pavle Kotarac <Pavle.Kotarac@amd.com> Signed-off-by: Wenjing Liu <wenjing.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-04-13drm/amd/display: implement shared PSR-SU sink validation helperDavid Zhang
[why] creating a generic helper for AMD specific PSR-SU sink validation. Moving the function to the power module to reference it across all OS. [how] - drop PSRSU specific sink validation helper and move to power module by reading PSR version and other PSR caps - call the new helper from linux DM (amdgpu_dm_psr) Acked-by: Pavle Kotarac <Pavle.Kotarac@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: David Zhang <dingchen.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>