summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'drm-next-2018-11-02' of git://anongit.freedesktop.org/drm/drmLinus Torvalds2018-11-0232-175/+364
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull drm fixes from Dave Airlie: "Pretty much a normal fixes pull pre-rc1, mostly amdgpu fixes, one i915 link training regression fix, and a couple of minor panel/bridge fixes and a panel quirk" * tag 'drm-next-2018-11-02' of git://anongit.freedesktop.org/drm/drm: (37 commits) drm/amdgpu: revert "enable gfxoff in non-sriov and stutter mode by default" drm/amd/pp: Print warning if od_sclk/mclk out of range drm/amd/pp: Fix pp_sclk/mclk_od not work on Vega10 drm/amd/pp: Fix pp_sclk/mclk_od not work on smu7 drm/amd/powerplay: no MGPU fan boost enablement on DPM disabled drm/amdgpu: Fix skipping hangged job reset during gpu recover. drm/amd/powerplay: revise Vega20 pptable version check drm/amd/display: set backlight level limit to 1 drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1 dt-bindings: drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1 drm/bridge: ti-sn65dsi86: Remove the mystery delay drm/panel: simple: Add "no-hpd" delay for Innolux TV123WAM drm/panel: simple: Support panels with HPD where HPD isn't connected dt-bindings: drm/panel: simple: Add no-hpd property drm/edid: Add 6 bpc quirk for BOE panel. drm/amdgpu: fix reporting of failed msg sent to SMU (v2) drm/amdgpu: Fix compute ring 1.0.0 failure after reset drm/amdgpu: fix VM leaf walking drm/amdgpu: fix amdgpu_vm_fini drm/amd/powerplay: commonize the API for retrieving current clocks ...
| * Merge tag 'drm-intel-next-fixes-2018-10-25' of ↵Dave Airlie2018-11-026-35/+110
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-intel into drm-next - Fix to avoid link retraining workaround on eDP (the other is a comment change) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181025131836.GA2296@jlahtine-desk.ger.corp.intel.com
| | * drm/i915/dp: Restrict link retrain workaround to external monitorsDhinakaran Pandiyan2018-10-241-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit '3cf71bc9904d ("drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"")' applies a work around for sinks that don't signal link loss. The work around does not need to have to be that broad as the issue was seen with only one particular monitor; limit this only for external displays as eDP features like PSR turn off the link and the driver ends up retraining the link seeeing that link is not synchronized. Cc: Lyude Paul <lyude@redhat.com> Cc: Jan-Marek Glogowski <glogow@fbihome.de> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> References: 3cf71bc9904d ("drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"") Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180927205735.16651-2-dhinakaran.pandiyan@intel.com (cherry picked from commit f24f6eb95807bca0dbd8dc5b2f3a4099000f4472) Fixes: 399334708b4f ("drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"") Cc: stable@vger.kernel.org Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
| | * drm/i915/dp: Fix link retraining comment in intel_dp_long_pulse()Dhinakaran Pandiyan2018-10-241-10/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Comment claims link needs to be retrained because the connected sink raised a long pulse to indicate link loss. If the sink did so, intel_dp_hotplug() would have handled link retraining. Looking at the logs in Bugzilla referenced in commit '3cf71bc9904d ("drm/i915: Re-apply Perform link quality check, unconditionally during long pulse"")', the issue is that the sink does not trigger an interrupt. What we want is ->detect() from user space to check link status and retrain. Ville's review for the original patch also indicates the same root cause. So, rewrite the comment. v2: Patch split and rewrote comment. Cc: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jan-Marek Glogowski <glogow@fbihome.de> References: 3cf71bc9904d ("drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"") Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180927205735.16651-1-dhinakaran.pandiyan@intel.com (cherry picked from commit 9ebd8202393dde9d3678c9ec162c1aa63ba17eac) Fixes: 399334708b4f ("drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"") Cc: stable@vger.kernel.org Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
| | * drm/nouveau: Fix nv50_mstc->best_encoder()Lyude Paul2018-10-191-10/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As mentioned in the previous commit, we currently prevent new modesets on recently-removed MST connectors by returning no encoder from our ->best_encoder() callback once the MST port has disappeared. This is wrong however, because it prevents legacy modesetting users from being able to disable CRTCs on MST connectors after the connector's respective topology has disappeared. So, fix this by instead by just always returning a valid encoder. Changes since v2: - Remove usage of atomic MST helper for now, since that got replaced with a much simpler solution Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20181008232437.5571-3-lyude@redhat.com (cherry picked from commit e87b0bbc9f0380d403f8f2f6abba0d51c74d944f) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
| | * drm/atomic_helper: Stop modesets on unregistered connectors harderLyude Paul2018-10-195-33/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unfortunately, it appears our fix in: commit b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors") Which attempted to work around the problems introduced by: commit 4d80273976bf ("drm/atomic_helper: Disallow new modesets on unregistered connectors") Is still not the right solution, as modesets can still be triggered outside of drm_atomic_set_crtc_for_connector(). So in order to fix this, while still being careful that we don't break modesets that a driver may perform before being registered with userspace, we replace connector->registered with a tristate member, connector->registration_state. This allows us to keep track of whether or not a connector is still initializing and hasn't been exposed to userspace, is currently registered and exposed to userspace, or has been legitimately removed from the system after having once been present. Using this info, we can prevent userspace from performing new modesets on unregistered connectors while still allowing the driver to perform modesets on unregistered connectors before the driver has finished being registered. Changes since v1: - Fix WARN_ON() in drm_connector_cleanup() that CI caught with this patchset in igt@drv_module_reload@basic-reload-inject and igt@drv_module_reload@basic-reload by checking if the connector is registered instead of unregistered, as calling drm_connector_cleanup() on a connector that hasn't been registered with userspace yet should stay valid. - Remove unregistered_connector_check(), and just go back to what we were doing before in commit 4d80273976bf ("drm/atomic_helper: Disallow new modesets on unregistered connectors") except replacing READ_ONCE(connector->registered) with drm_connector_is_unregistered(). This gets rid of the behavior of allowing DPMS On<->Off, but that should be fine as it's more consistent with the UAPI we had before - danvet - s/drm_connector_unregistered/drm_connector_is_unregistered/ - danvet - Update documentation, fix some typos. Fixes: b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: stable@vger.kernel.org Cc: David Airlie <airlied@linux.ie> Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181016203946.9601-1-lyude@redhat.com (cherry picked from commit 39b50c603878f4f8ae541ac4088a805d588abc79) Fixes: e96550956fbc ("drm/atomic_helper: Disallow new modesets on unregistered connectors") Fixes: 34ca26a98ad6 ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors") Cc: stable@vger.kernel.org Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
| | * drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectorsLyude Paul2018-10-192-20/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It appears when testing my previous fix for some of the legacy modesetting issues with MST, I misattributed some kernel splats that started appearing on my machine after a rebase as being from upstream. But it appears they actually came from my patch series: [ 2.980512] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for [CONNECTOR:65:eDP-1] [ 2.980516] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CONNECTOR:65:eDP-1] is not registered [ 2.980516] ------------[ cut here ]------------ [ 2.980519] Could not determine valid watermarks for inherited state [ 2.980553] WARNING: CPU: 3 PID: 551 at drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x14d7/0x19f0 [i915] [ 2.980556] Modules linked in: i915(O+) i2c_algo_bit drm_kms_helper(O) syscopyarea sysfillrect sysimgblt fb_sys_fops drm(O) intel_rapl x86_pkg_temp_thermal iTCO_wdt wmi_bmof coretemp crc32_pclmul psmouse i2c_i801 mei_me mei i2c_core lpc_ich mfd_core tpm_tis tpm_tis_core wmi tpm thinkpad_acpi pcc_cpufreq video ehci_pci crc32c_intel serio_raw ehci_hcd xhci_pci xhci_hcd [ 2.980577] CPU: 3 PID: 551 Comm: systemd-udevd Tainted: G O 4.19.0-rc7Lyude-Test+ #1 [ 2.980579] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET63WW (1.27 ) 11/10/2016 [ 2.980605] RIP: 0010:intel_modeset_init+0x14d7/0x19f0 [i915] [ 2.980607] Code: 89 df e8 ec 27 02 00 e9 24 f2 ff ff be 03 00 00 00 48 89 df e8 da 27 02 00 e9 26 f2 ff ff 48 c7 c7 c8 d1 34 a0 e8 23 cf dc e0 <0f> 0b e9 7c fd ff ff f6 c4 04 0f 85 37 f7 ff ff 48 8b 83 60 08 00 [ 2.980611] RSP: 0018:ffffc90000287988 EFLAGS: 00010282 [ 2.980614] RAX: 0000000000000000 RBX: ffff88031b488000 RCX: 0000000000000006 [ 2.980617] RDX: 0000000000000007 RSI: 0000000000000086 RDI: ffff880321ad54d0 [ 2.980620] RBP: ffffc90000287a10 R08: 000000000000040a R09: 0000000000000065 [ 2.980623] R10: ffff88030ebb8f00 R11: ffffffff81416590 R12: ffff88031b488000 [ 2.980626] R13: ffff88031b4883a0 R14: ffffc900002879a8 R15: ffff880319099800 [ 2.980630] FS: 00007f475620d180(0000) GS:ffff880321ac0000(0000) knlGS:0000000000000000 [ 2.980633] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2.980636] CR2: 00007f9ef28018a0 CR3: 000000031b72c001 CR4: 00000000003606e0 [ 2.980639] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 2.980642] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 2.980645] Call Trace: [ 2.980675] i915_driver_load+0xb0e/0xdc0 [i915] [ 2.980681] ? kernfs_add_one+0xe7/0x130 [ 2.980709] i915_pci_probe+0x46/0x60 [i915] [ 2.980715] pci_device_probe+0xd4/0x150 [ 2.980719] really_probe+0x243/0x3b0 [ 2.980722] driver_probe_device+0xba/0x100 [ 2.980726] __driver_attach+0xe4/0x110 [ 2.980729] ? driver_probe_device+0x100/0x100 [ 2.980733] bus_for_each_dev+0x74/0xb0 [ 2.980736] driver_attach+0x1e/0x20 [ 2.980739] bus_add_driver+0x159/0x230 [ 2.980743] ? 0xffffffffa0393000 [ 2.980746] driver_register+0x70/0xc0 [ 2.980749] ? 0xffffffffa0393000 [ 2.980753] __pci_register_driver+0x57/0x60 [ 2.980780] i915_init+0x55/0x58 [i915] [ 2.980785] do_one_initcall+0x4a/0x1c4 [ 2.980789] ? do_init_module+0x27/0x210 [ 2.980793] ? kmem_cache_alloc_trace+0x131/0x190 [ 2.980797] do_init_module+0x60/0x210 [ 2.980800] load_module+0x2063/0x22e0 [ 2.980804] ? vfs_read+0x116/0x140 [ 2.980807] ? vfs_read+0x116/0x140 [ 2.980811] __do_sys_finit_module+0xbd/0x120 [ 2.980814] ? __do_sys_finit_module+0xbd/0x120 [ 2.980818] __x64_sys_finit_module+0x1a/0x20 [ 2.980821] do_syscall_64+0x5a/0x110 [ 2.980824] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 2.980826] RIP: 0033:0x7f4754e32879 [ 2.980828] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f7 45 2c 00 f7 d8 64 89 01 48 [ 2.980831] RSP: 002b:00007fff43fd97d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 2.980834] RAX: ffffffffffffffda RBX: 0000559a44ca64f0 RCX: 00007f4754e32879 [ 2.980836] RDX: 0000000000000000 RSI: 00007f475599f4cd RDI: 0000000000000018 [ 2.980838] RBP: 00007f475599f4cd R08: 0000000000000000 R09: 0000000000000000 [ 2.980839] R10: 0000000000000018 R11: 0000000000000246 R12: 0000000000000000 [ 2.980841] R13: 0000559a44c92fd0 R14: 0000000000020000 R15: 0000000000000000 [ 2.980881] WARNING: CPU: 3 PID: 551 at drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x14d7/0x19f0 [i915] [ 2.980884] ---[ end trace 5eb47a76277d4731 ]--- The cause of this appears to be due to the fact that if there's pre-existing display state that was set by the BIOS when i915 loads, it will attempt to perform a modeset before the driver is registered with userspace. Since this happens before the driver's registered with userspace, it's connectors are also unregistered and thus-states which would turn on DPMS on a connector end up getting rejected since the connector isn't registered. These bugs managed to get past Intel's CI partially due to the fact it never ran a full test on my patches for some reason, but also because all of the tests unload the GPU once before running. Since this bug is only really triggered when the drivers tries to perform a modeset before it's been fully registered with userspace when coming from whatever display configuration the firmware left us with, it likely would never have been picked up by CI in the first place. After some discussion with vsyrjala, we decided the best course of action would be to just move the unregistered connector checks out of update_connector_routing() and into drm_atomic_set_crtc_for_connector(). The reason for this being that legacy modesetting isn't going to be expecting failures anywhere (at least this is the case with X), so ideally we want to ensure that any DPMS changes will still work even on unregistered connectors. Instead, we now only reject new modesets which would change the current CRTC assigned to an unregistered connector unless no new CRTC is being assigned to replace the connector's previous one. Signed-off-by: Lyude Paul <lyude@redhat.com> Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: 4d80273976bf ("drm/atomic_helper: Disallow new modesets on unregistered connectors") Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181009204424.21462-1-lyude@redhat.com (cherry picked from commit b5d29843d8ef86d4cde4742e095b81b7fd41e688) Fixes: e96550956fbc ("drm/atomic_helper: Disallow new modesets on unregistered connectors") Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
| | * drm/atomic_helper: Disallow new modesets on unregistered connectorsLyude Paul2018-10-191-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the exception of modesets which would switch the DPMS state of a connector from on to off, we want to make sure that we disallow all modesets which would result in enabling a new monitor or a new mode configuration on a monitor if the connector for the display in question is no longer registered. This allows us to stop userspace from trying to enable new displays on connectors for an MST topology that were just removed from the system, without preventing userspace from disabling DPMS on those connectors. Changes since v5: - Fix typo in comment, nothing else Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20181008232437.5571-2-lyude@redhat.com (cherry picked from commit 4d80273976bf880c4bed9359b8f2d45663140c86) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
| * | Merge branch 'drm-next-4.20' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie2018-11-0221-115/+207
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-next - Fix flickering at low backlight levels on some systems - Fix some overclocking regressions - Vega20 updates for - GPU recovery fixes - Disable gfxoff on RV as some sbios/fw combinations are not stable yet Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181101151939.2828-1-alexander.deucher@amd.com
| | * | drm/amdgpu: revert "enable gfxoff in non-sriov and stutter mode by default"Christian König2018-11-012-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is still completely breaking my Raven system. This reverts commit cdf2f910fa969adca1b0e3ad2b487821233dc038. Revert until we sort out the sbios and firmware combinations that work correctly. bug: https://bugs.freedesktop.org/show_bug.cgi?id=108606 Cc: stable@vger.kernel.org # v4.19 Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | drm/amd/pp: Print warning if od_sclk/mclk out of rangeRex Zhu2018-11-011-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | print warning in dmesg to notify user the setting for sclk_od/mclk_od out of range that vbios can support Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | drm/amd/pp: Fix pp_sclk/mclk_od not work on Vega10Rex Zhu2018-11-011-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | not update dpm table with user's setting. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | drm/amd/pp: Fix pp_sclk/mclk_od not work on smu7Rex Zhu2018-11-011-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | not update the dpm table with user's setting Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | drm/amd/powerplay: no MGPU fan boost enablement on DPM disabledEvan Quan2018-11-011-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As MGPU fan boost feature will be definitely not needed when DPM is disabled. So, there is no need to error out. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | drm/amdgpu: Fix skipping hangged job reset during gpu recover.Andrey Grodzovsky2018-11-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: During GPU recover DAL would hang in amdgpu_pm_compute_clocks->amdgpu_fence_wait_empty Fix: Turns out there was a typo introduced by 3320b8d drm/amdgpu: remove job->ring which caused skipping amdgpu_fence_driver_force_completion and so the hangged job was never force signaled and this would cause the hang later in DAL. Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | drm/amd/powerplay: revise Vega20 pptable version checkEvan Quan2018-10-301-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tell the version numbers when the pptable versions do not match. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | drm/amd/display: set backlight level limit to 1Guttula, Suresh2018-10-301-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch will work as workaround for silicon limitation related to PWM dutycycle when the backlight level goes to 0. Actually PWM value is 16 bit value and valid range from 1-65535. when ever user requested to set this PWM value to 0 which is not fall in the range, in VBIOS taken care this by limiting to 1. This patch here will do the same. Either driver or VBIOS can not pass 0 value as it is not a valid range for PWM and it will give a high PWM pulse which is not the intended behaviour as per HW constraints. Signed-off-by: suresh guttula <suresh.guttula@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | drm/amdgpu: fix reporting of failed msg sent to SMU (v2)Shirish S2018-10-261-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently send_msg_to_smc_async() only report which message failed, but the actual failing message is the previous one, which SMU is unable to service. This patch reads the contents of register where the SMU is stuck and report appropriately. v2: fix the build (Alex) Signed-off-by: Shirish S <shirish.s@amd.com> Reviewed-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | drm/amdgpu: Fix compute ring 1.0.0 failure after resetAndrey Grodzovsky2018-10-261-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: After GPU reset on dGPUs with gfx8 compute ring 1.0.0 fails to pass the ring test. Ring registers inspection shows that it's active and no hang is observed (rptr == wptr) No significant diffs were observed between CP_HQD* registers for the ring in good and bad shape. Fix: No clear reason why but reversing the order of ring tests fixes the problem. Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | drm/amdgpu: fix VM leaf walkingChristian König2018-10-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make sure we don't try to go down further after the leave walk already ended. This fixes a crash with a new VM test. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Tested-by: Rex Zhu Rex.Zhu@amd.com Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | drm/amdgpu: fix amdgpu_vm_finiChristian König2018-10-251-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We should not remove mappings in rbtree_postorder_for_each_entry_safe because that rebalances the tree. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | drm/amd/powerplay: commonize the API for retrieving current clocksEvan Quan2018-10-251-29/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So that it can be shared between all clocks. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Feifei Xu<Feifei.Xu@amd.com> Reviewed-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | drm/amd/powerplay: correct the clocks for DAL to be Khz unitEvan Quan2018-10-251-11/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the clocks reported are in 10Khz unit. Correct them as Khz unit as DAL wanted. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Feifei Xu<Feifei.Xu@amd.com> Reviewed-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | drm/amd/display: Disable 4k 60 HDMI on DCE11David Francis2018-10-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Why] Carrizo and Stoney have severe corruption when trying to power 4k 60 monitors over HDMI connectors that support 4k 60. Carrizo and Stoney require retimers and redrivers to support 4k 60 over HDMI. This driver does not currently support these. Thus, 4k 60 HDMI (and all other modes requiring over 300MHz) should be disabled. [How] Reduce the dce11 HDMI pixel clock cap to 300000kHz. Signed-off-by: David Francis <David.Francis@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | drm/amdgpu: Fix null point errorRex Zhu2018-10-244-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | need to check adev->powerplay.pp_funcs first, becasue from AI, the smu ip can be disabled by user, and the pp_handle is null in this case. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | drm/amd/display: Fix Null point error if smu ip was disabledRex Zhu2018-10-241-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | from AI, SMU Ip is not indispensable to driver and can be disabled by user via module parameter ip_block_mask. so the pp_handle may be NULL. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | drm/amd/powerplay: commit get_performance_level API as DAL neededEvan Quan2018-10-242-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This can suppress the error reported on driver loading. Also these are empty APIs as Vega12/Vega20 has no performance levels. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | drm/amd/powerplay: bump the PPtable version supportedEvan Quan2018-10-222-30/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As the matching VBIOS is already ready. Also drop the temporary workarounds applied before. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | drm/amd/powerplay: drop highest UCLK setting after display configuration changeEvan Quan2018-10-221-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The UCLK is forced to highest at the start of display configuration change. Downgrade the UCLK from highest after display configuration change. Otherwise, we may see the UCLK stuck in the highest in some cases. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | drm/amd/pp: enable power limit increase in OD modeJoseph Greathouse2018-10-221-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OverDrive mode allows users to increase the maximum SCLK and MCLK frequencies beyond the default on the GPU. However, this may not results in large performance gains if the GPU then runs into its TDP power limit. This patch adds the capability to increase the power limit of a GPU above its default maximum. This is only allowed when overdrive is enabled in the ppfeaturemask, since this is an overdrive feature. The TDPODLimit value from the VBIOS describes how how much higher the TDP should be allowed to go over its default, in percentage. v2: Moved dereference of hwmgr to after its validity check Signed-off-by: Joseph Greathouse <Joseph.Greathouse@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | powerplay: Respect units on max dcfclk watermarkDavid Francis2018-10-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In a refactor, the watermark clock inputs to powerplay from DC were changed from units of 10kHz to kHz clocks. One division by 100 was not converted into a division by 1000. Signed-off-by: David Francis <David.Francis@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | drm/amdgpu: Fix null pointer amdgpu_device_fw_loadingEmily Deng2018-10-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Need to check adev->powerplay.pp_funcs. Signed-off-by: Emily Deng <Emily.Deng@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | drm/amd/powerplay: error out when force clock level under auto dpm mode V2Evan Quan2018-10-222-7/+19
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Forcing clock level is supported under manual dpm mode only. Error out when trying to set under manual mode. Instead of doing nothing and reporting success. V2: update for mclk/pcie clock level settings also Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * | Merge tag 'drm-misc-next-fixes-2018-10-31' of ↵Dave Airlie2018-11-025-25/+47
| |\ \ | | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-misc into drm-next - Properly label Innolux TV123WAM as P120ZDG-BF1 (Doug) - Add optional delay for panels without hpd hooked up (which solves the mystery delay for TI SN65DSI86 bridge) (Doug) - Another 6bpc quirk for BOE panel 0x0771 (Shawn) Cc: Doug Anderson <dianders@chromium.org> Cc: Lee, Shawn C <shawn.c.lee@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com> From: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20181031201944.GA262020@art_vandelay
| | * drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1Douglas Anderson2018-10-291-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As far as I can tell the panel that was added in commit da50bd4258db ("drm/panel: simple: Add Innolux TV123WAM panel driver support") wasn't actually an Innolux TV123WAM but was actually an Innolux P120ZDG-BF1. As far as I can tell the Innolux TV123WAM isn't a real panel and but it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1. Let's unmosh. Here's my evidence: * Searching for TV123WAM on the Internet turns up a TI panel. While it's possible that an Innolux panel has the same model number as the TI Panel, it seems a little doubtful. Looking up the datasheet from the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm. * As far as I know, the patch adding the Innolux Panel was supposed to be for the board that's sitting in front of me as I type this (support for that board is not yet upstream). On the back of that panel I see Innolux P120ZDZ-EZ1 rev B1. * Someone pointed me at a datasheet that's supposed to be for the panel in front of me (sorry, I can't share the datasheet). That datasheet has the string "p120zdg-bf1" * If I search for "P120ZDG-BF1" on the Internet I get hits for panels that are 2160x1440. They don't have datasheets, but the fact that the resolution matches is a good sign. In any case, let's update the name and also the physical size to match the correct panel. Fixes: da50bd4258db ("drm/panel: simple: Add Innolux TV123WAM panel driver support") Cc: Sandeep Panda <spanda@codeaurora.org> Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-6-dianders@chromium.org
| | * dt-bindings: drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1Douglas Anderson2018-10-291-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As far as I can tell the bindings that were added in commit 9c04400f7ea6 ("dt-bindings: drm/panel: Document Innolux TV123WAM panel bindings") weren't actually for Innolux TV123WAM but were actually for Innolux P120ZDG-BF1. As far as I can tell the Innolux TV123WAM isn't a real panel and but it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1. Let's unmosh. Here's my evidence: * Searching for TV123WAM on the Internet turns up a TI panel. While it's possible that an Innolux panel has the same model number as the TI Panel, it seems a little doubtful. Looking up the datasheet from the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm. * As far as I know, the patch adding the Innolux Panel was supposed to be for the board that's sitting in front of me as I type this (support for that board is not yet upstream). On the back of that panel I see Innolux P120ZDZ-EZ1 rev B1. * Someone pointed me at a datasheet that's supposed to be for the panel in front of me (sorry, I can't share the datasheet). That datasheet has the string "p120zdg-bf1" * If I search for "P120ZDG-BF1" on the Internet I get hits for panels that are 2160x1440. They don't have datasheets, but the fact that the resolution matches is a good sign. While we doing the rename, also mention that no-hpd can be used with this panel. See the previous patch in this series ("drm/panel: simple: Add "no-hpd" delay for Innolux TV123WAM"). Fixes: 9c04400f7ea6 ("dt-bindings: drm/panel: Document Innolux TV123WAM panel bindings") Cc: Sandeep Panda <spanda@codeaurora.org> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-5-dianders@chromium.org
| | * drm/bridge: ti-sn65dsi86: Remove the mystery delayDouglas Anderson2018-10-291-13/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Let's solve the mystery of commit bf1178c98930 ("drm/bridge: ti-sn65dsi86: Add mystery delay to enable()"). Specifically the reason we needed that mystery delay is that we weren't paying attention to HPD. Looking at the datasheet for the same panel that was tested for the original commit, I see there's a timing "t3" that times from power on to the aux channel being operational. This time is specced as 0 - 200 ms. The datasheet says that the aux channel is operational at exactly the same time that HPD is asserted. Scoping the signals on this board showed that HPD was asserted 84 ms after power was asserted. That very closely matches the magic 70 ms delay that we had. ...and actually, in my testing the 70 ms wasn't quite enough of a delay and some percentage of the time the display didn't come up until I bumped it to 100 ms (presumably 84 ms would have worked too). To solve this, we tried to hook up the HPD signal in the bridge. ...but in doing so we found that that the bridge didn't report that HPD was asserted until ~280 ms after we powered it (!). This is explained by looking at the sn65dsi86 datasheet section "8.4.5.1 HPD (Hot Plug/Unplug Detection)". Reading there we see that the bridge isn't even intended to report HPD until 100 ms after it's asserted. ...but that would have left us at 184 ms. The extra 100 ms (presumably) comes from this part in the datasheet: > The HPD state machine operates off an internal ring oscillator. The > ring oscillator frequency will vary [ ... ]. The min/max range in > the HPD State Diagram refers to the possible times based off > variation in the ring oscillator frequency. Given that the 280 ms we'll end up delaying if we hook up HPD is _slower_ than the 200 ms we could just hardcode, for now we'll solve the problem by just hardcoding a 200 ms delay in the panel driver using the patch in this series ("drm/panel: simple: Support panels with HPD where HPD isn't connected"). If we later find a panel that needs to use this bridge where we need HPD then we'll have to come up with some new code to handle it. Given the silly debouncing in the bridge chip, though, it seems unlikely. One last note is that I tried to solve this through another way: In ti_sn_bridge_enable() I tried to use various combinations of dp_dpcd_writeb() and dp_dpcd_readb() to detect when the aux channel was up. In theory that would let me detect _exactly_ when I could continue and do link training. Unfortunately even if I did an aux transfer w/out waiting I couldn't see any errors. Possibly I could keep looping over link training until it came back with success, but that seemed a little overly hacky to me. Reviewed-by: Sean Paul <sean@poorly.run> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-4-dianders@chromium.org
| | * drm/panel: simple: Add "no-hpd" delay for Innolux TV123WAMDouglas Anderson2018-10-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the HPD signal isn't hooked up to this panel we need a 200 ms delay. In the datasheet this is shown as the maximum time that HPD will take to be asserted after power is given to the panel. Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-3-dianders@chromium.org
| | * drm/panel: simple: Support panels with HPD where HPD isn't connectedDouglas Anderson2018-10-291-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some eDP panels that are designed to be always connected to a board use their HPD signal to signal that they've finished powering on and they're ready to be talked to. However, for various reasons it's possible that the HPD signal from the panel isn't actually hooked up. In the case where the HPD isn't hooked up you can look at the timing diagram on the panel datasheet and insert a delay for the maximum amount of time that the HPD might take to come up. Let's add support in simple-panel for this concept. At the moment we will co-opt the existing "prepare" delay to keep track of the delay and we'll use a boolean to specify that a given panel should only apply the delay if the "no-hpd" property was specified. Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-2-dianders@chromium.org
| | * dt-bindings: drm/panel: simple: Add no-hpd propertyDouglas Anderson2018-10-291-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some eDP panels that are designed to be always connected to a board use their HPD signal to signal that they've finished powering on and they're ready to be talked to. However, for various reasons it's possible that the HPD signal from the panel isn't actually hooked up. In the case where the HPD isn't hooked up you can look at the timing diagram on the panel datasheet and insert a delay for the maximum amount of time that the HPD might take to come up. Let's add a property in the device tree for this concept. Reviewed-by: Sean Paul <sean@poorly.run> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-1-dianders@chromium.org
| | * drm/edid: Add 6 bpc quirk for BOE panel.Lee, Shawn C2018-10-291-0/+3
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BOE panel (ID: 0x0771) that reports "DFP 1.x compliant TMDS". But it's 6bpc panel only instead of 8 bpc. Add panel ID to edid quirk list and set 6 bpc as default to work around this issue. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Cooper Chiou <cooper.chiou@intel.com> Signed-off-by: Lee, Shawn C <shawn.c.lee@intel.com>> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1540792173-7288-1-git-send-email-shawn.c.lee@intel.com
* | Merge tag 'apparmor-pr-2018-11-01' of ↵Linus Torvalds2018-11-0212-17/+291
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor Pull apparmor updates from John Johansen: "Features/Improvements: - replace spin_is_locked() with lockdep - add base support for secmark labeling and matching Cleanups: - clean an indentation issue, remove extraneous space - remove no-op permission check in policy_unpack - fix checkpatch missing spaces error in Parse secmark policy - fix network performance issue in aa_label_sk_perm Bug fixes: - add #ifdef checks for secmark filtering - fix an error code in __aa_create_ns() - don't try to replace stale label in ptrace checks - fix failure to audit context info in build_change_hat - check buffer bounds when mapping permissions mask - fully initialize aa_perms struct when answering userspace query - fix uninitialized value in aa_split_fqname" * tag 'apparmor-pr-2018-11-01' of git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor: apparmor: clean an indentation issue, remove extraneous space apparmor: fix checkpatch error in Parse secmark policy apparmor: add #ifdef checks for secmark filtering apparmor: Fix uninitialized value in aa_split_fqname apparmor: don't try to replace stale label in ptraceme check apparmor: Replace spin_is_locked() with lockdep apparmor: Allow filtering based on secmark policy apparmor: Parse secmark policy apparmor: Add a wildcard secid apparmor: don't try to replace stale label in ptrace access check apparmor: Fix network performance issue in aa_label_sk_perm
| * | apparmor: clean an indentation issue, remove extraneous spaceColin Ian King2018-11-011-1/+1
| | | | | | | | | | | | | | | | | | | | | Trivial fix to clean up an indentation issue, remove space Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
| * | apparmor: fix checkpatch error in Parse secmark policyJohn Johansen2018-11-011-1/+1
| | | | | | | | | | | | | | | | | | | | | Fix missed spacing error reported by checkpatch for 9caafbe2b4cf ("Parse secmark policy") Signed-off-by: John Johansen <john.johansen@canonical.com>
| * | apparmor: add #ifdef checks for secmark filteringArnd Bergmann2018-10-122-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The newly added code fails to build when either SECMARK or NETFILTER are disabled: security/apparmor/lsm.c: In function 'apparmor_socket_sock_rcv_skb': security/apparmor/lsm.c:1138:12: error: 'struct sk_buff' has no member named 'secmark'; did you mean 'mark'? security/apparmor/lsm.c:1671:21: error: 'struct nf_hook_state' declared inside parameter list will not be visible outside of this definition or declaration [-Werror] Add a set of #ifdef checks around it to only enable the code that we can compile and that makes sense in that configuration. Fixes: ab9f2115081a ("apparmor: Allow filtering based on secmark policy") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: John Johansen <john.johansen@canonical.com>
| * | apparmor: Fix uninitialized value in aa_split_fqnameZubin Mithra2018-10-031-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Syzkaller reported a OOB-read with the stacktrace below. This occurs inside __aa_lookupn_ns as `n` is not initialized. `n` is obtained from aa_splitn_fqname. In cases where `name` is invalid, aa_splitn_fqname returns without initializing `ns_name` and `ns_len`. Fix this by always initializing `ns_name` and `ns_len`. __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113 print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412 __asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430 memcmp+0xe3/0x160 lib/string.c:861 strnstr+0x4b/0x70 lib/string.c:934 __aa_lookupn_ns+0xc1/0x570 security/apparmor/policy_ns.c:209 aa_lookupn_ns+0x88/0x1e0 security/apparmor/policy_ns.c:240 aa_fqlookupn_profile+0x1b9/0x1010 security/apparmor/policy.c:468 fqlookupn_profile+0x80/0xc0 security/apparmor/label.c:1844 aa_label_strn_parse+0xa3a/0x1230 security/apparmor/label.c:1908 aa_label_parse+0x42/0x50 security/apparmor/label.c:1943 aa_change_profile+0x513/0x3510 security/apparmor/domain.c:1362 apparmor_setprocattr+0xaa4/0x1150 security/apparmor/lsm.c:658 security_setprocattr+0x66/0xc0 security/security.c:1298 proc_pid_attr_write+0x301/0x540 fs/proc/base.c:2555 __vfs_write+0x119/0x9f0 fs/read_write.c:485 vfs_write+0x1fc/0x560 fs/read_write.c:549 ksys_write+0x101/0x260 fs/read_write.c:598 __do_sys_write fs/read_write.c:610 [inline] __se_sys_write fs/read_write.c:607 [inline] __x64_sys_write+0x73/0xb0 fs/read_write.c:607 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Fixes: 3b0aaf5866bf ("apparmor: add lib fn to find the "split" for fqnames") Reported-by: syzbot+61e4b490d9d2da591b50@syzkaller.appspotmail.com Signed-off-by: Zubin Mithra <zsm@chromium.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: John Johansen <john.johansen@canonical.com>
| * | apparmor: don't try to replace stale label in ptraceme checkJann Horn2018-10-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | begin_current_label_crit_section() must run in sleepable context because when label_is_stale() is true, aa_replace_current_label() runs, which uses prepare_creds(), which can sleep. Until now, the ptraceme access check (which runs with tasklist_lock held) violated this rule. Fixes: b2d09ae449ced ("apparmor: move ptrace checks to using labels") Reported-by: Cyrill Gorcunov <gorcunov@gmail.com> Reported-by: kernel test robot <rong.a.chen@intel.com> Signed-off-by: Jann Horn <jannh@google.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
| * | apparmor: Replace spin_is_locked() with lockdepLance Roy2018-10-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | lockdep_assert_held() is better suited to checking locking requirements, since it won't get confused when someone else holds the lock. This is also a step towards possibly removing spin_is_locked(). Signed-off-by: Lance Roy <ldr709@gmail.com> Cc: John Johansen <john.johansen@canonical.com> Cc: James Morris <jmorris@namei.org> Cc: "Serge E. Hallyn" <serge@hallyn.com> Cc: <linux-security-module@vger.kernel.org> Signed-off-by: John Johansen <john.johansen@canonical.com>
| * | apparmor: Allow filtering based on secmark policyMatthew Garrett2018-10-032-1/+177
| | | | | | | | | | | | | | | | | | | | | | | | Add support for dropping or accepting packets based on their secmark tags. Signed-off-by: Matthew Garrett <mjg59@google.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
| * | apparmor: Parse secmark policyMatthew Garrett2018-10-034-0/+77
| | | | | | | | | | | | | | | | | | | | | | | | Add support for parsing secmark policy provided by userspace, and store that in the overall policy. Signed-off-by: Matthew Garrett <mjg59@google.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-18 10:58:50 +0000