aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2022-06-07drm/amd/display: pass panel instance in DMUB dirty rect commandDavid Zhang1-0/+5
[Why] In cases where there are multiple eDP instances, DMUB needs to know which instance the command is for. Today, the field for specifying the panel_inst exists in both dmub_cmd_update_dirty_rect_data and dmub_cmd_update_cursor_info_data. For cursor updates, we already specify the panel_inst, but that's not the case for dirty_rect updates. Today, a value of '0' is used (due to initial memsetting of the cmd struct to 0) [how] In dc_dmub_update_dirty_rect(), Call dc_get_edp_link_panel_inst() to get the panel_inst, and fill it in the DMUB cmd struct. v2: Update commit message for clarity. Signed-off-by: Mikita Lipski <mikita.lipski@amd.com> Signed-off-by: David Zhang <dingchen.zhang@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07drm/amd/display: Add PSR-SU-RC support in DCDavid Zhang6-0/+60
[Why] PSR-SU Rate Control - or PSR-SU-RC - enables PSR-SU panels to work with variable refresh rate to allow for more power savings. Lowering the refresh rate can increase PSR residency by expanding the eDP main link shut down duration. It can also lower panel power consumption. There is a complication with PSR, since the eDP main link can be shut down. Therefore, the timing controller (TCON) on the eDP sink nees to be able to scan out its remote buffer independent of the main link. To allow the eDP source to specify the sink's refresh rate while the link is off, vendor-specific DPCD registers are used. This allows the eDP source to then "Rate Control" the panel during PSR active. [How] Add DC support to communicate with PSR-SU-RC supported eDP sinks. The sink will need to know the desired VTotal during PSR active. This change only adds support to DC, support in amdgpu_dm is still pending to enable this fully. Signed-off-by: David Zhang <dingchen.zhang@amd.com> Signed-off-by: Leo Li <sunpeng.li@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07drm/amd/display: expose AMD specific DPCD for PSR-SU-RC supportDavid Zhang1-0/+4
[why & how] Expose vendor specific DPCD registers for rate controlling the eDP sink TCON's refresh rate during PSR active. When used in combination with PSR-SU and Freesync, it is called PSR-SU Rate Contorol, or PSR-SU-RC for short. v2: Add all DPCD registers required Signed-off-by: David Zhang <dingchen.zhang@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07drm/amd/display: 3.2.189Aric Cyr1-1/+1
This version brings along the following: - DPP DTO fix - Transient encoder fix - Restrict the reading of LTTPR capabilities in LTTPR mode - Increase maximum stages for BB - Distinguish HDMI DTO from DP DTO Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Aric Cyr <aric.cyr@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07drm/amd/display: Add HDMI member to DTOChris Park1-0/+1
[Why] For Pixel Rate control, when on HDMI, HDMI DTO should be selected instead of DP DTO. [How] Add HDMI member to dtbclk_dto_params, so it can be used tell apart HDMI and DP DTO in the future. Reviewed-by: Alvin Lee <Alvin.Lee2@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Chris Park <chris.park@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07drm/amd/display: Extend soc BB capabilitiyLei, Jun2-1/+2
[why] Some parts are consuming dangerously close to maximum number of states supported when updating the BB (i.e. 8). [how] Change maximum stages from 9 to 20. Reviewed-by: Alvin Lee <Alvin.Lee2@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Jun Lei <jun.lei@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07drm/amd/display: Fix entry into transient encoder assignment mode.Jimmy Kizito5-8/+69
[Why] In some scenarios it is possible for the encoder assignment module to be set to "transient" mode even though there are no new encoder assignments. This can lead to incorrect results when querying encoder assignment, which in turn can cause incorrect displays to be manipulated. [How] Only allow encoder assignment to be in transient mode of operation when there are valid new encoder assignments. Reviewed-by: Meenakshikumar Somasundaram <Meenakshikumar.Somasundaram@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07drm/amd/display: Fix dpp dto for disabled pipesDuncan Ma1-0/+4
[Why] When switching from 1 pipe to 4to1 mpc combine, DppDtoClk aren't enabled for the disabled pipes pior to programming the pipes. Upon optimizing bandwidth, DppDto are enabled causing intermittent underflow. [How] Update dppclk dto whenever pipe are flagged to enable. Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Reviewed-by: Hansen Dsouza <Hansen.Dsouza@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Duncan Ma <duncan.ma@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07drm/amd/display: 3.2.188Aric Cyr1-1/+1
This version brings along the following: - Optimized blank calculations - More robust DP MST hotplug support - eDP bug fix relating to ODM - Revert a patch that caused a regression with DP - min comp buffer size fix - Make DP easier to debug - Calculate the maximum OLED brightness correctly - 3 plane MPO. Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Aric Cyr <aric.cyr@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07drm/amd/display: [FW Promotion] Release 0.0.119.0Anthony Koo1-0/+1
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Anthony Koo <Anthony.Koo@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07drm/amd/display: Enable 3 plane MPOHansen Dsouza2-6/+6
[why and how] 3 plane MPO is a new feature missing in a few resource files Enable 3 plane MPO by setting slave planes to 2 Reviewed-by: Krunoslav Kovac <Krunoslav.Kovac@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Hansen Dsouza <Hansen.Dsouza@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07drm/amd/display: Cap OLED brightness per max frame-average luminanceRoman Li1-4/+4
[Why] For OLED eDP the Display Manager uses max_cll value as a limit for brightness control. max_cll defines the content light luminance for individual pixel. Whereas max_fall defines frame-average level luminance. The user may not observe the difference in brightness in between max_fall and max_cll. That negatively impacts the user experience. [How] Use max_fall value instead of max_cll as a limit for brightness control. Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Roman Li <roman.li@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07drm/amd/display: add DP sanity checks during enable streamWenjing Liu4-6/+15
[why] 1. When HPD deassertion is pulled in the middle of enabe stream link training, we will abort current training and turn off PHY. This causes current link settings to be zeroed this causes later stream enablement sequence to fail as we prefer to carry on enablement process despite of link training failure for SST. 2. When HPD is toggled after detection before before the enable stream sequence as a result. There could be a race condition where we could end up enable stream based on the previous link even though the link is updated after the HPD toggle. This causes an issue where our link bandwidth is no longer enough to accommodate the timing therefore causes us to oversubscribe MST payload time slots. As discussed we decided to add basic sanity check to make sure that our code can handle the oversubscription failure silently without system hang. [how] 1. Keep PHY powered on when HPD is deasserted during enable stream and wait for the detection sequence to power it off later. 2. Do not allocate payload if the required timeslot for current timing is greater than 64 timeslots. Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Reviewed-by: George Shen <George.Shen@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Wenjing Liu <wenjing.liu@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07drm/amd/display: Correct min comp buffer sizeDuncan Ma1-1/+2
[Why] In 3-way mpo pipes, there is a case that we overbook the CRB buffer size. At rare instances, overbooking the crb will cause underflow. This only happens when det_size changes dynamically based on pipe_cnt. [How] Set min compbuff size to 1 segment when preparing BW. Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Duncan Ma <duncan.ma@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07drm/amd/display: Blank eDP on enable drv if odm enabledDuncan Ma4-0/+44
[Why] For panels with pixel clock > 1200MHz that require ODM in pre-OS, when driver is disabled in OS, odm is enabled. Upon driver enablement, corruption is seen if odm was originally enabled. DP_PIXEL_COMBINE and pixelclk must be programmed prior to programming the optc-odm registers. However, eDP displays aren't blanked prior to initializing odm in this case. [How] Upon driver enablement, check whether odm is enabled, if so, blank eDP prior to programming optc-odm registers. Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Duncan Ma <duncan.ma@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07drm/amd/display: Avoid reading LTTPR caps in non-LTTPR mode.Jimmy Kizito1-13/+31
[Why] LTTPR capable devices on the DisplayPort path may assume that extended LTTPR AUX timeouts will be used after LTTPR capabilities are read. When DPTX operates in non-LTTPR mode, AUX timeouts are not extended and this can result in AUX transactions timing out. [How] Use shared helper function to determine LTTPR mode and do not read LTTPR capabilities in non-LTTPR mode. Reviewed-by: Mustapha Ghaddar <Mustapha.Ghaddar@amd.com> Reviewed-by: Meenakshikumar Somasundaram <Meenakshikumar.Somasundaram@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07Revert "drm/amd/display: Pass the new context into disable OTG WA"Nicholas Kazlauskas3-12/+12
This reverts commit 8440f57532496d398a461887e56ca6f45089fbcf. Causes a hang when hotplugging DP, shutting down system, or enabling dual eDP. Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07Revert "drm/amdgpu: Ensure the DMA engine is deactivated during set ups"Guchun Chen1-64/+45
This reverts commit b992a19085885c096b19625a85c674cb89829ca1. This causes regression in GPU reset related test. Cc: Alexander Deucher <Alexander.Deucher@amd.com> Cc: ricetons@gmail.com Signed-off-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-07selinux: add __randomize_layout to selinux_audit_dataGONG, Ruiqi1-1/+1
Randomize the layout of struct selinux_audit_data as suggested in [1], since it contains a pointer to struct selinux_state, an already randomized strucure. [1]: https://github.com/KSPP/linux/issues/188 Signed-off-by: GONG, Ruiqi <gongruiqi1@huawei.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2022-06-07audit: remove redundant data_len checkShreenidhi Shedi1-1/+1
data_len is already getting checked if it's less than 2 earlier in this function. Signed-off-by: Shreenidhi Shedi <sshedi@vmware.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
2022-06-07regulator: qcom_smd: add get_voltage to MP5496Robert Marko1-0/+1
Add the get_voltage OP to MP5496 ops using the generic rpm_reg_get_voltage. Signed-off-by: Robert Marko <robimarko@gmail.com> Link: https://lore.kernel.org/r/20220604193300.125758-1-robimarko@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-07regulator: qcom_smd: correct MP5496 rangesRobert Marko1-4/+4
Currently set MP5496 Buck and LDO ranges dont match its datasheet[1]. According to the datasheet: Buck range is 0.6-2.1875V with a 12.5mV step LDO range is 0.8-3.975V with a 25mV step. So, correct the ranges according to the datasheet[1]. [1] https://www.monolithicpower.com/en/documentview/productdocument/index/version/2/document_type/Datasheet/lang/en/sku/MP5496GR/document_id/6906/ Signed-off-by: Robert Marko <robimarko@gmail.com> Link: https://lore.kernel.org/r/20220604193300.125758-2-robimarko@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-07ASoC: ops: Fix off by one in range control validationMark Brown1-2/+2
We currently report that range controls accept a range of 0..(max-min) but accept writes in the range 0..(max-min+1). Remove that extra +1. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220604105246.4055214-1-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-07ASoC: codecs: rt700/rt711/rt711-sdca: resume bus/codec in .set_jack_detectPierre-Louis Bossart3-26/+40
The .set_jack_detect() codec component callback is invoked during card registration, which happens when the machine driver is probed. The issue is that this callback can race with the bus suspend/resume, and IO timeouts can happen. This can be reproduced very easily if the machine driver is 'blacklisted' and manually probed after the bus suspends. The bus and codec need to be re-initialized using pm_runtime helpers. Previous contributions tried to make sure accesses to the bus during the .set_jack_detect() component callback only happen when the bus is active. This was done by changing the regcache status on a component remove. This is however a layering violation, the regcache status should only be modified on device probe, suspend and resume. The component probe/remove should not modify how the device regcache is handled. This solution also didn't handle all the possible race conditions, and the RT700 headset codec was not handled. This patch tries to resume the codec device before handling the jack initializations. In case the codec has not yet been initialized, pm_runtime may not be enabled yet, so we don't squelch the -EACCES error code and only stop the jack information. When the codec reports as attached, the jack initialization will proceed as usual. BugLink: https://github.com/thesofproject/linux/issues/3643 Fixes: 7ad4d237e7c4a ('ASoC: rt711-sdca: Add RT711 SDCA vendor-specific driver') Fixes: 899b12542b089 ('ASoC: rt711: add snd_soc_component remove callback') Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20220606203752.144159-8-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-07ASoC: codecs: rt700/rt711/rt711-sdca: initialize workqueues in probePierre-Louis Bossart3-21/+13
The workqueues are initialized in the io_init functions, which isn't quite right. In some tests, this leads to warnings throw from __queue_delayed_work() WARN_ON_FUNCTION_MISMATCH(timer->function, delayed_work_timer_fn); Move all the initializations to the probe functions. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20220606203752.144159-7-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-07ASoC: rt7*-sdw: harden jack_detect_handlerPierre-Louis Bossart3-3/+3
Realtek headset codec drivers typically check if the card is instantiated before proceeding with the jack detection. The rt700, rt711 and rt711-sdca are however missing a check on the card pointer, which can lead to NULL dereferences encountered in driver bind/unbind tests. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20220606203752.144159-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-07ASoC: rt711: fix calibrate mutex initializationPierre-Louis Bossart2-1/+4
Follow the same flow as rt711-sdca and initialize all mutexes at probe time. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20220606203752.144159-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-07ASoC: Intel: sof_sdw: handle errors on card registrationPierre-Louis Bossart1-22/+29
If the card registration fails, typically because of deferred probes, the device properties added for headset codecs are not removed, which leads to kernel oopses in driver bind/unbind tests. We already clean-up the device properties when the card is removed, this code can be moved as a helper and called upon card registration errors. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20220606203752.144159-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-07ASoC: rt711-sdca-sdw: fix calibrate mutex initializationPierre-Louis Bossart2-1/+4
In codec driver bind/unbind test, the following warning is thrown: DEBUG_LOCKS_WARN_ON(lock->magic != lock) ... [ 699.182495] rt711_sdca_jack_init+0x1b/0x1d0 [snd_soc_rt711_sdca] [ 699.182498] rt711_sdca_set_jack_detect+0x3b/0x90 [snd_soc_rt711_sdca] [ 699.182500] snd_soc_component_set_jack+0x24/0x50 [snd_soc_core] A quick check in the code shows that the 'calibrate_mutex' used by this driver are not initialized at probe time. Moving the initialization to the probe removes the issue. BugLink: https://github.com/thesofproject/linux/issues/3644 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20220606203752.144159-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-07ASoC: Realtek/Maxim SoundWire codecs: disable pm_runtime on removePierre-Louis Bossart9-5/+76
When binding/unbinding codec drivers, the following warnings are thrown: [ 107.266879] rt715-sdca sdw:3:025d:0714:01: Unbalanced pm_runtime_enable! [ 306.879700] rt711-sdca sdw:0:025d:0711:01: Unbalanced pm_runtime_enable! Add a remove callback for all Realtek/Maxim SoundWire codecs and remove this warning. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20220606203752.144159-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-07Merge tag 'v5.19-rc1' into asoc-5.19Mark Brown13218-258049/+1038580
Linux 5.19-rc1
2022-06-07drm/i915: remove noisy logs in intel_dp_dsc_get_output_bpp()Luca Coelho1-5/+0
The intel_dp_dsc_get_output_bpp() function outputs two lines of unconditional logs, which was okay when it was called only once. But now, we also call this function from intel_dp_mode_valid(), which is in turn called for every mode we need to validate. This causes a lot of useless noise. Remove the unconditional prints to avoid spamming the logs. Also remove one more print that is not unconditional, but is related. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220607074433.1202917-1-luca@coelho.fi
2022-06-07drm/i915/utils: throw out unused stuffJani Nikula1-40/+0
Remove some of the unused helpers from i915_utils.h. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220607094207.536699-3-jani.nikula@intel.com
2022-06-07drm/i915/drv: drop intel_bios.h includeJani Nikula1-1/+0
No longer needed after panel data was moved. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220607094207.536699-2-jani.nikula@intel.com
2022-06-07drm/i915/tasklet: separate local hacks around struct tasklet_structJani Nikula4-34/+45
Add a dedicated file for the local functions around struct tasklet_struct. Far from ideal, but better placed in a dedicated file than i915_gem.h. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220607094207.536699-1-jani.nikula@intel.com
2022-06-07drm/i915/client: only include what's neededJani Nikula1-1/+1
Only the uapi header is required. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220607092207.476653-1-jani.nikula@intel.com
2022-06-07ixgbe: fix unexpected VLAN Rx in promisc mode on VFOlivier Matz1-2/+2
When the promiscuous mode is enabled on a VF, the IXGBE_VMOLR_VPE bit (VLAN Promiscuous Enable) is set. This means that the VF will receive packets whose VLAN is not the same than the VLAN of the VF. For instance, in this situation: ┌────────┐ ┌────────┐ ┌────────┐ │ │ │ │ │ │ │ │ │ │ │ │ │ VF0├────┤VF1 VF2├────┤VF3 │ │ │ │ │ │ │ └────────┘ └────────┘ └────────┘ VM1 VM2 VM3 vf 0: vlan 1000 vf 1: vlan 1000 vf 2: vlan 1001 vf 3: vlan 1001 If we tcpdump on VF3, we see all the packets, even those transmitted on vlan 1000. This behavior prevents to bridge VF1 and VF2 in VM2, because it will create a loop: packets transmitted on VF1 will be received by VF2 and vice-versa, and bridged again through the software bridge. This patch remove the activation of VLAN Promiscuous when a VF enables the promiscuous mode. However, the IXGBE_VMOLR_UPE bit (Unicast Promiscuous) is kept, so that a VF receives all packets that has the same VLAN, whatever the destination MAC address. Fixes: 8443c1a4b192 ("ixgbe, ixgbevf: Add new mbox API xcast mode") Cc: stable@vger.kernel.org Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: Olivier Matz <olivier.matz@6wind.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-06-07ixgbe: fix bcast packets Rx on VF after promisc removalOlivier Matz1-2/+2
After a VF requested to remove the promiscuous flag on an interface, the broadcast packets are not received anymore. This breaks some protocols like ARP. In ixgbe_update_vf_xcast_mode(), we should keep the IXGBE_VMOLR_BAM bit (Broadcast Accept) on promiscuous removal. This flag is already set by default in ixgbe_set_vmolr() on VF reset. Fixes: 8443c1a4b192 ("ixgbe, ixgbevf: Add new mbox API xcast mode") Cc: stable@vger.kernel.org Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: Olivier Matz <olivier.matz@6wind.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-06-07kernel/reboot: Fix powering off using a non-syscall code pathsDmitry Osipenko1-20/+26
There are other methods of powering off machine than the reboot syscall. Previously we missed to cover those methods and it created power-off regression for some machines, like the PowerPC e500. Fix this problem by moving the legacy sys-off handler registration to the latest phase of power-off process and making the kernel_can_power_off() check the legacy pm_power_off presence. Tested-by: Michael Ellerman <mpe@ellerman.id.au> # ppce500 Reported-by: Michael Ellerman <mpe@ellerman.id.au> # ppce500 Fixes: da007f171fc9 ("kernel/reboot: Change registration order of legacy power-off handler") Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-06-07selftests/bpf: Add selftest for calling global functions from freplaceToke Høiland-Jørgensen2-0/+32
Add a selftest that calls a global function with a context object parameter from an freplace function to check that the program context type is correctly converted to the freplace target when fetching the context type from the kernel BTF. v2: - Trim includes - Get rid of global function - Use __noinline Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> Link: https://lore.kernel.org/r/20220606075253.28422-2-toke@redhat.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-06-07bpf: Fix calling global functions from BPF_PROG_TYPE_EXT programsToke Høiland-Jørgensen1-1/+2
The verifier allows programs to call global functions as long as their argument types match, using BTF to check the function arguments. One of the allowed argument types to such global functions is PTR_TO_CTX; however the check for this fails on BPF_PROG_TYPE_EXT functions because the verifier uses the wrong type to fetch the vmlinux BTF ID for the program context type. This failure is seen when an XDP program is loaded using libxdp (which loads it as BPF_PROG_TYPE_EXT and attaches it to a global XDP type program). Fix the issue by passing in the target program type instead of the BPF_PROG_TYPE_EXT type to bpf_prog_get_ctx() when checking function argument compatibility. The first Fixes tag refers to the latest commit that touched the code in question, while the second one points to the code that first introduced the global function call verification. v2: - Use resolve_prog_type() Fixes: 3363bd0cfbb8 ("bpf: Extend kfunc with PTR_TO_CTX, PTR_TO_MEM argument support") Fixes: 51c39bb1d5d1 ("bpf: Introduce function-by-function verification") Reported-by: Simon Sundberg <simon.sundberg@kau.se> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> Link: https://lore.kernel.org/r/20220606075253.28422-1-toke@redhat.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-06-07bpf: Use safer kvmalloc_array() where possibleDan Carpenter1-4/+4
The kvmalloc_array() function is safer because it has a check for integer overflows. These sizes come from the user and I was not able to see any bounds checking so an integer overflow seems like a realistic concern. Fixes: 0dcac2725406 ("bpf: Add multi kprobe link") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/Yo9VRVMeHbALyjUH@kili Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-06-07bpf, arm64: Clear prog->jited_len along prog->jitedEric Dumazet1-0/+1
syzbot reported an illegal copy_to_user() attempt from bpf_prog_get_info_by_fd() [1] There was no repro yet on this bug, but I think that commit 0aef499f3172 ("mm/usercopy: Detect vmalloc overruns") is exposing a prior bug in bpf arm64. bpf_prog_get_info_by_fd() looks at prog->jited_len to determine if the JIT image can be copied out to user space. My theory is that syzbot managed to get a prog where prog->jited_len has been set to 43, while prog->bpf_func has ben cleared. It is not clear why copy_to_user(uinsns, NULL, ulen) is triggering this particular warning. I thought find_vma_area(NULL) would not find a vm_struct. As we do not hold vmap_area_lock spinlock, it might be possible that the found vm_struct was garbage. [1] usercopy: Kernel memory exposure attempt detected from vmalloc (offset 792633534417210172, size 43)! kernel BUG at mm/usercopy.c:101! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 25002 Comm: syz-executor.1 Not tainted 5.18.0-syzkaller-10139-g8291eaafed36 #0 Hardware name: linux,dummy-virt (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usercopy_abort+0x90/0x94 mm/usercopy.c:101 lr : usercopy_abort+0x90/0x94 mm/usercopy.c:89 sp : ffff80000b773a20 x29: ffff80000b773a30 x28: faff80000b745000 x27: ffff80000b773b48 x26: 0000000000000000 x25: 000000000000002b x24: 0000000000000000 x23: 00000000000000e0 x22: ffff80000b75db67 x21: 0000000000000001 x20: 000000000000002b x19: ffff80000b75db3c x18: 00000000fffffffd x17: 2820636f6c6c616d x16: 76206d6f72662064 x15: 6574636574656420 x14: 74706d6574746120 x13: 2129333420657a69 x12: 73202c3237313031 x11: 3237313434333533 x10: 3336323937207465 x9 : 657275736f707865 x8 : ffff80000a30c550 x7 : ffff80000b773830 x6 : ffff80000b773830 x5 : 0000000000000000 x4 : ffff00007fbbaa10 x3 : 0000000000000000 x2 : 0000000000000000 x1 : f7ff000028fc0000 x0 : 0000000000000064 Call trace: usercopy_abort+0x90/0x94 mm/usercopy.c:89 check_heap_object mm/usercopy.c:186 [inline] __check_object_size mm/usercopy.c:252 [inline] __check_object_size+0x198/0x36c mm/usercopy.c:214 check_object_size include/linux/thread_info.h:199 [inline] check_copy_size include/linux/thread_info.h:235 [inline] copy_to_user include/linux/uaccess.h:159 [inline] bpf_prog_get_info_by_fd.isra.0+0xf14/0xfdc kernel/bpf/syscall.c:3993 bpf_obj_get_info_by_fd+0x12c/0x510 kernel/bpf/syscall.c:4253 __sys_bpf+0x900/0x2150 kernel/bpf/syscall.c:4956 __do_sys_bpf kernel/bpf/syscall.c:5021 [inline] __se_sys_bpf kernel/bpf/syscall.c:5019 [inline] __arm64_sys_bpf+0x28/0x40 kernel/bpf/syscall.c:5019 __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline] invoke_syscall+0x48/0x114 arch/arm64/kernel/syscall.c:52 el0_svc_common.constprop.0+0x44/0xec arch/arm64/kernel/syscall.c:142 do_el0_svc+0xa0/0xc0 arch/arm64/kernel/syscall.c:206 el0_svc+0x44/0xb0 arch/arm64/kernel/entry-common.c:624 el0t_64_sync_handler+0x1ac/0x1b0 arch/arm64/kernel/entry-common.c:642 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:581 Code: aa0003e3 d00038c0 91248000 97fff65f (d4210000) Fixes: db496944fdaa ("bpf: arm64: add JIT support for multi-function programs") Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Song Liu <songliubraving@fb.com> Link: https://lore.kernel.org/bpf/20220531215113.1100754-1-eric.dumazet@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-06-07Add support for PolarFire SoC's spi controllersMark Brown4-0/+643
Merge series from Conor Dooley <conor.dooley@microchip.com>: Add support for the PolatFire SoC SPI controller, the DT binding was added previously.
2022-06-07iavf: Add waiting for response from PF in set macMateusz Palczewski3-21/+174
Make iavf_set_mac synchronous by waiting for a response from a PF. Without this iavf_set_mac is always returning success even though set_mac can be rejected by a PF. This ensures that when set_mac exits netdev MAC is updated. This is needed for sending ARPs with correct MAC after changing VF's MAC. This is also needed by bonding module. Signed-off-by: Sylwester Dziedziuch <sylwesterx.dziedziuch@intel.com> Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-06-07i40e: Add VF VLAN pruningMateusz Palczewski4-6/+147
VFs by default are able to see all tagged traffic regardless of trust and VLAN filters configured. Add new private flag vf-vlan-pruning that allows changing of default VF behavior for tagged traffic. When the flag is turned on untrusted VF will only be able to receive untagged traffic or traffic with VLAN tags it has created interfaces for The flag is off by default and can only be changed if there are no VFs spawned on the PF. This flag will only be effective when no PVID is set on VF and VF is not trusted. Add new function that computes the correct VLAN ID for VF VLAN filters based on trust, PVID, vf-vlan-prune-disable flag and current VLAN ID. Testing Hints: Test 1: vf-vlan-pruning == off ============================== 1. Set the private flag > ethtool --set-priv-flag eth0 vf-vlan-pruning off (default setting) 2. Use scapy to send any VLAN tagged traffic and make sure the VF receives all VLAN tagged traffic that matches its destination MAC filters (unicast, multicast, and broadcast). Test 2: vf-vlan-pruning == on ============================== 1. Set the private flag > ethtool --set-priv-flag eth0 vf-vlan-pruning on 2. Use scapy to send any VLAN tagged traffic and make sure the VF does not receive any VLAN tagged traffic that matches its destination MAC filters (unicast, multicast, and broadcast). 3. Add a VLAN filter on the VF netdev > ip link add link eth0v0 name vlan10 type vlan id 10 4. Bring the VLAN netdev up > ip link set vlan10 up 4. Use scapy to send traffic with VLAN 10, VLAN 11 (anything not VLAN 10), and untagged traffic. Make sure the VF only receives VLAN 10 and untagged traffic when the link partner is sending. Test 3: vf-vlan-pruning == off && VF is in a port VLAN ============================== 1. Set the private flag > ethtool --set-priv-flag eth0 vf-vlan-pruning off (default setting) 2. Create a VF > echo 1 > sriov_numvfs 3. Put the VF in a port VLAN > ip link set eth0 vf 0 vlan 10 4. Use scapy to send traffic with VLAN 10 and VLAN 11 (anything not VLAN 10) and make sure the VF only receives untagged traffic when the link partner is sending VLAN 10 tagged traffic as the VLAN tag is expected to be stripped by HW for port VLANs and not visible to the VF. Test 4: Change vf-vlan-pruning while VFs are created ============================== echo 0 > sriov_numvfs ethtool --set-priv-flag eth0 vf-vlan-pruning off echo 1 > sriov_numvfs ethtool --set-priv-flag eth0 vf-vlan-pruning on (expect failure) Signed-off-by: Sylwester Dziedziuch <sylwesterx.dziedziuch@intel.com> Signed-off-by: Przemyslaw Patynowski <przemyslawx.patynowski@intel.com> Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-06-07Merge branch 'bpf: Add 64bit enum value support'Alexei Starovoitov29-190/+1217
Yonghong Song says: ==================== Currently, btf only supports upto 32bit enum value with BTF_KIND_ENUM. But in kernel, some enum has 64bit values, e.g., in uapi bpf.h, we have enum { BPF_F_INDEX_MASK = 0xffffffffULL, BPF_F_CURRENT_CPU = BPF_F_INDEX_MASK, BPF_F_CTXLEN_MASK = (0xfffffULL << 32), }; With BTF_KIND_ENUM, the value for BPF_F_CTXLEN_MASK will be encoded as 0 which is incorrect. To solve this problem, BTF_KIND_ENUM64 is proposed in this patch set to support enum 64bit values. Also, since sometimes there is a need to generate C code from btf, e.g., vmlinux.h, btf kflag support is also added for BTF_KIND_ENUM and BTF_KIND_ENUM64 to indicate signedness, helping proper value printout. Changelog: v4 -> v5: - skip newly-added enum64 C test if clang version <= 14. v3 -> v4: - rename btf_type_is_any_enum() to btf_is_any_enum() to favor consistency in libbpf. - fix sign extension issue in btf_dump_get_enum_value(). - fix BPF_CORE_FIELD_SIGNED signedness issue in bpf_core_calc_field_relo(). v2 -> v3: - Implement separate btf_equal_enum()/btf_equal_enum64() and btf_compat_enum()/btf_compat_enum64(). - Add a new enum64 placeholder type dynamicly for enum64 sanitization. - For bpftool output and unit selftest, printed out signed/unsigned encoding as well. - fix some issues with BTF_KIND_ENUM is doc and clarified sign extension rules for enum values. v1 -> v2: - Changed kflag default from signed to unsigned - Fixed sanitization issue - Broke down libbpf related patches for easier review - Added more tests - More code refactorization - Corresponding llvm patch (to support enum64) is also updated ==================== Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-06-07docs/bpf: Update documentation for BTF_KIND_ENUM64 supportYonghong Song1-6/+37
Add BTF_KIND_ENUM64 documentation in btf.rst. Also fixed a typo for section number for BTF_KIND_TYPE_TAG from 2.2.17 to 2.2.18, and fixed a type size issue for BTF_KIND_ENUM. Acked-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/r/20220607062724.3728215-1-yhs@fb.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-06-07selftests/bpf: Add a test for enum64 value relocationsYonghong Song7-0/+218
Add a test for enum64 value relocations. The test will be skipped if clang version is 14 or lower since enum64 is only supported from version 15. Acked-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/r/20220607062718.3726307-1-yhs@fb.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2022-06-07selftests/bpf: Test BTF_KIND_ENUM64 for deduplicationYonghong Song1-2/+95
Add a few unit tests for BTF_KIND_ENUM64 deduplication. Acked-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/r/20220607062713.3725409-1-yhs@fb.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.