- 14 Jul, 2020 3 commits
-
-
Alex Deucher authored
Prevents a warning in the MST create connector case. v2: create global fake encoders rather per connector fake encoders to avoid running out of encoder indices. v3: use the actual number of crtcs on the asic rather than the max to conserve encoders. v4: v3 plus missing hunk I forgot to git add. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1108 Fixes: c6385e50 ("drm/amdgpu: drop legacy drm load and unload callbacks") Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 5.7.x
-
Jack Xiao authored
Remove signaled jobs from job list and ensure the job was indeed preempted. Signed-off-by: Jack Xiao <Jack.Xiao@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Jack Xiao authored
During preemption test for gfx10, it uses kiq to trigger gfx preemption, which would result in race condition with flushing TLB for kiq. Signed-off-by: Jack Xiao <Jack.Xiao@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
- 09 Jul, 2020 10 commits
-
-
Dave Airlie authored
Merge tag 'amd-drm-fixes-5.8-2020-07-09' of git://people.freedesktop.org/~agd5f/linux into drm-fixes amd-drm-fixes-5.8-2020-07-09: amdgpu: - Fix a suspend/resume issue with PSP - Backlight fix for Renoir - Fix for gpu recovery debugging radeon: - Fix a double free in error path Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200709185221.44895-1-alexander.deucher@amd.com
-
Dave Airlie authored
Merge tag 'drm-intel-fixes-2020-07-08' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes One display's fbc patch fixing fence_y_offset calculation from Ville and 4 patches from Chris on GEM: 1 fixing a debugfs panic and others fixing vma construction and pin under vm->mutex. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200708190654.GA3924867@intel.com
-
git://github.com/skeggsb/linuxDave Airlie authored
- SVM fixes - display fixes Signed-off-by: Dave Airlie <airlied@redhat.com> From: Ben Skeggs <skeggsb@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/ <CACAvsv5i-dc0Onbk8FWzd-PTgXHHWi6jcE3O0hVx8+V5qEOeqg@mail.gmail.com
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
* meson: OSD burst-length fixes * hibmc: fix runtime warning by setting up generic fbdev after registering device Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20200708121050.GA29420@linux-uq9g
-
Dave Airlie authored
Merge tag 'mediatek-drm-fixes-5.8' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-fixes Mediatek DRM Fixes for Linux 5.8 This include fixup for cmdq, mmsys, visibility checking and some refinement. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Chun-Kuang Hu <chunkuang.hu@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200707153944.604-1-chunkuang.hu@kernel.org
-
Marek Olšák authored
It's impossible to debug shader hangs with soft recovery. Signed-off-by: Marek Olšák <marek.olsak@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
Tom Rix authored
clang static analysis flags this error drivers/gpu/drm/radeon/ci_dpm.c:5652:9: warning: Use of memory after it is freed [unix.Malloc] kfree(rdev->pm.dpm.ps[i].ps_priv); ^~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/radeon/ci_dpm.c:5654:2: warning: Attempt to free released memory [unix.Malloc] kfree(rdev->pm.dpm.ps); ^~~~~~~~~~~~~~~~~~~~~~ problem is reported in ci_dpm_fini, with these code blocks. for (i = 0; i < rdev->pm.dpm.num_ps; i++) { kfree(rdev->pm.dpm.ps[i].ps_priv); } kfree(rdev->pm.dpm.ps); The first free happens in ci_parse_power_table where it cleans up locally on a failure. ci_dpm_fini also does a cleanup. ret = ci_parse_power_table(rdev); if (ret) { ci_dpm_fini(rdev); return ret; } So remove the cleanup in ci_parse_power_table and move the num_ps calculation to inside the loop so ci_dpm_fini will know how many array elements to free. Fixes: cc8dbbb4 ("drm/radeon: add dpm support for CI dGPUs (v2)") Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
Aaron Ma authored
RENOIR loads dmub fw not dmcu, check dmcu only will prevent loading iram, it breaks backlight control. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=208277Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Aaron Ma <aaron.ma@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
Huang Rui authored
TMR is required to be destoried with GFX_CMD_ID_DESTROY_TMR while the system goes to suspend. Otherwise, PSP may return the failure state (0xFFFF007) on Gfx-2-PSP command GFX_CMD_ID_SETUP_TMR after do multiple times suspend/resume. Signed-off-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
Huang Rui authored
Unload ASD function in suspend phase. Signed-off-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 08 Jul, 2020 6 commits
-
-
Zenghui Yu authored
The HiSilicon hibmc driver triggers a splat at boot time as below [ 14.137806] ------------[ cut here ]------------ [ 14.142405] hibmc-drm 0000:0a:00.0: Device has not been registered. [ 14.148661] WARNING: CPU: 0 PID: 496 at drivers/gpu/drm/drm_fb_helper.c:2233 drm_fbdev_generic_setup+0x15c/0x1b8 [ 14.158787] [...] [ 14.278307] Call trace: [ 14.280742] drm_fbdev_generic_setup+0x15c/0x1b8 [ 14.285337] hibmc_pci_probe+0x354/0x418 [ 14.289242] local_pci_probe+0x44/0x98 [ 14.292974] work_for_cpu_fn+0x20/0x30 [ 14.296708] process_one_work+0x1c4/0x4e0 [ 14.300698] worker_thread+0x2c8/0x528 [ 14.304431] kthread+0x138/0x140 [ 14.307646] ret_from_fork+0x10/0x18 [ 14.311205] ---[ end trace a2000ec2d838af4d ]--- This turned out to be due to the fbdev device hasn't been registered when drm_fbdev_generic_setup() is invoked. Let's fix the splat by moving it down after drm_dev_register() which will follow the "Display driver example" documented by commit de99f060 ("drm/drv: DOC: Add driver example code"). Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Xinliang Liu <xinliang.liu@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200706144713.1123-1-yuzenghui@huawei.com
-
Ralph Campbell authored
If system memory is migrated to device private memory and no GPU MMU page table entry exists, the GPU will fault and call hmm_range_fault() to get the PFN for the page. Since the .dev_private_owner pointer in struct hmm_range is not set, hmm_range_fault returns an error which results in the GPU program stopping with a fatal fault. Fix this by setting .dev_private_owner appropriately. Fixes: 08ddddda ("mm/hmm: check the device private page owner in hmm_range_fault()") Cc: stable@vger.kernel.org Signed-off-by: Ralph Campbell <rcampbell@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ralph Campbell authored
The patch to add zero page migration to GPU memory inadvertently included part of a future change which broke normal page migration to GPU memory by copying too much data and corrupting GPU memory. Fix this by only copying one page instead of a byte count. Fixes: 9d4296a7 ("drm/nouveau/nouveau/hmm: fix migrate zero page to GPU") Signed-off-by: Ralph Campbell <rcampbell@nvidia.com> Reviewed-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Tegra TRM says worst-case reply time is 1216us, and this should fix some spurious timeouts that have been popping up. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Prevents "snd_hda_codec_hdmi hdaudioC1D0: HDMI: pin nid 5 not registered" that occur on some configurations. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Chris Wilson authored
On eviction, we acquire the vm->mutex and then wait on the vma->active. Therefore when binding and pinning the vma, we must follow the same sequence, lock/pin the vma then mark it active. Otherwise, we mark the vma as active, then wait for the vm->mutex, and meanwhile the evictor holding the mutex waits upon us to complete our activity. Fixes: 8ccfc20a ("drm/i915/gt: Mark ring->vma as active while pinned") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> # v5.6+ Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200706170138.8993-1-chris@chris-wilson.co.uk (cherry picked from commit 8567774e) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
- 07 Jul, 2020 4 commits
-
-
Chris Wilson authored
Not only do we need to release the vm.ref we acquired for the vma on the duplicate insert branch, but also for the normal error paths, so roll them all into one. Reported-by: Andi Shyti <andi.shyti@intel.com> Suggested-by: Andi Shyti <andi.shyti@intel.com> Fixes: 2850748e ("drm/i915: Pull i915_vma_pin under the vm->mutex") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andi Shyti <andi.shyti@intel.com> Cc: <stable@vger.kernel.org> # v5.5+ Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200702211015.29604-1-chris@chris-wilson.co.uk (cherry picked from commit 03fca66b) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Chris Wilson authored
As we allow for parallel threads to create the same vma instance concurrently, and we only filter out the duplicates upon reacquiring the spinlock for the rbtree, we have to free the loser of the constructors' race. When freeing, we should also drop any resource references acquired for the redundant vma. Fixes: 2850748e ("drm/i915: Pull i915_vma_pin under the vm->mutex") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> # v5.5+ Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200702083225.20044-1-chris@chris-wilson.co.uk (cherry picked from commit 2377427c) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Ville Syrjälä authored
The current fence_y_offset calculation is broken. I think it more or less used to do the right thing, but then I changed the plane code to put the final x/y source offsets back into the src rectangle so now it's just subtraacting the same value from itself. The code would never have worked if we allowed the framebuffer to have a non-zero offset. Let's do this in a better way by just calculating the fence_y_offset from the final plane surface offset. Note that we don't align the plane surface address to fence rows so with horizontal panning there's often a horizontal offset from the fence start to the surface address as well. We have no way to tell the hardware about that so we just ignore it. Based on some quick tests the invlidation still happens correctly. I presume due to the invalidation nuking at least the full line (or a segment of multiple lines). Fixes: 54d4d719 ("drm/i915: Overcome display engine stride limits via GTT remapping") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200429101034.8208-4-ville.syrjala@linux.intel.comReviewed-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit 5331889b) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Chris Wilson authored
As we close a handle GEM object, we update the drm_file's idr with an error^W NULL pointer to indicate the in-progress closure, and finally removing it. If we read the idr directly, we may then see an invalid object pointer, and in our debugfs per_file_stats() we therefore need to protect against the entry being invalid. [ 1016.651637] RIP: 0010:per_file_stats+0xe/0x16e [ 1016.651646] Code: d2 41 0f b6 8e 69 8c 00 00 48 89 df 48 c7 c6 7b 74 8c be 31 c0 e8 0c 89 cf ff eb d2 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 53 <8b> 06 85 c0 0f 84 4d 01 00 00 49 89 d6 48 89 f3 3d ff ff ff 7f 73 [ 1016.651651] RSP: 0018:ffffad3a01337ba0 EFLAGS: 00010293 [ 1016.651656] RAX: 0000000000000018 RBX: ffff96fe040d65e0 RCX: 0000000000000002 [ 1016.651660] RDX: ffffad3a01337c50 RSI: 0000000000000000 RDI: 00000000000001e8 [ 1016.651663] RBP: ffffad3a01337bb8 R08: 0000000000000000 R09: 00000000000001c0 [ 1016.651667] R10: 0000000000000000 R11: ffffffffbdbe5fce R12: 0000000000000000 [ 1016.651671] R13: ffffffffbdbe5fce R14: ffffad3a01337c50 R15: 0000000000000001 [ 1016.651676] FS: 00007a597e2d7480(0000) GS:ffff96ff3bb00000(0000) knlGS:0000000000000000 [ 1016.651680] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1016.651683] CR2: 0000000000000000 CR3: 0000000171fc2001 CR4: 00000000003606e0 [ 1016.651687] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1016.651690] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1016.651693] Call Trace: [ 1016.651693] Call Trace: [ 1016.651703] idr_for_each+0x8a/0xe8 [ 1016.651711] i915_gem_object_info+0x2a3/0x3eb [ 1016.651720] seq_read+0x162/0x3ca [ 1016.651727] full_proxy_read+0x5b/0x8d [ 1016.651733] __vfs_read+0x45/0x1bb [ 1016.651741] vfs_read+0xc9/0x15e [ 1016.651746] ksys_read+0x7e/0xde [ 1016.651752] do_syscall_64+0x54/0x68 [ 1016.651758] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Reported-by: Guenter Roeck <linux@roeck-us.net> Fixes: a8c15954 ("drm/i915: Protect debugfs per_file_stats with RCU lock") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: stable@vger.kernel.org Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200630152724.3734-1-chris@chris-wilson.co.uk (cherry picked from commit c1b9fd3d) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
-
- 05 Jul, 2020 14 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
Using a mutex for "print this warning only once" is so overdesigned as to be actively offensive to my sensitive stomach. Just use "pr_info_once()" that already does this, although in a (harmlessly) racy manner that can in theory cause the message to be printed twice if more than one CPU races on that "is this the first time" test. [ If somebody really cares about that harmless data race (which sounds very unlikely indeed), that person can trivially fix printk_once() by using a simple atomic access, preferably with an optimistic non-atomic test first before even bothering to treat the pointless "make sure it is _really_ just once" case. A mutex is most definitely never the right primitive to use for something like this. ] Yes, this is a small and meaningless detail in a code path that hardly matters. But let's keep some code quality standards here, and not accept outrageously bad code. Link: https://lore.kernel.org/lkml/CAHk-=wgV9toS7GU3KmNpj8hCS9SeF+A0voHS8F275_mgLhL4Lw@mail.gmail.com/ Cc: Andy Lutomirski <luto@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Thomas Gleixner: "A series of fixes for x86: - Reset MXCSR in kernel_fpu_begin() to prevent using a stale user space value. - Prevent writing MSR_TEST_CTRL on CPUs which are not explicitly whitelisted for split lock detection. Some CPUs which do not support it crash even when the MSR is written to 0 which is the default value. - Fix the XEN PV fallout of the entry code rework - Fix the 32bit fallout of the entry code rework - Add more selftests to ensure that these entry problems don't come back. - Disable 16 bit segments on XEN PV. It's not supported because XEN PV does not implement ESPFIX64" * tag 'x86-urgent-2020-07-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/ldt: Disable 16-bit segments on Xen PV x86/entry/32: Fix #MC and #DB wiring on x86_32 x86/entry/xen: Route #DB correctly on Xen PV x86/entry, selftests: Further improve user entry sanity checks x86/entry/compat: Clear RAX high bits on Xen PV SYSENTER selftests/x86: Consolidate and fix get/set_eflags() helpers selftests/x86/syscall_nt: Clear weird flags after each test selftests/x86/syscall_nt: Add more flag combinations x86/entry/64/compat: Fix Xen PV SYSENTER frame setup x86/entry: Move SYSENTER's regs->sp and regs->flags fixups into C x86/entry: Assert that syscalls are on the right stack x86/split_lock: Don't write MSR_TEST_CTRL on CPUs that aren't whitelisted x86/fpu: Reset MXCSR to default in kernel_fpu_begin()
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull irq fixes from Thomas Gleixner: "A set of interrupt chip driver fixes: - Ensure the atomicity of affinity updates in the GIC driver - Don't try to sleep in atomic context when waiting for the GICv4.1 to respond. Use polling instead. - Typo fixes in Kconfig and warnings" * tag 'irq-urgent-2020-07-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/gic: Atomically update affinity irqchip/riscv-intc: Fix a typo in a pr_warn() irqchip/gic-v4.1: Use readx_poll_timeout_atomic() to fix sleep in atomic irqchip/loongson-pci-msi: Fix a typo in Kconfig
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull rcu fixlet from Thomas Gleixner: "A single fix for a printk format warning in RCU" * tag 'core-urgent-2020-07-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: rcuperf: Fix printk format warning
-
Linus Torvalds authored
Merge tag 'kbuild-fixes-v5.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild fixes frin Masahiro Yamada: - fix various bugs in xconfig - fix some issues in cross-compilation using Clang - fix documentation * tag 'kbuild-fixes-v5.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: .gitignore: Do not track `defconfig` from `make savedefconfig` kbuild: make Clang build userprogs for target architecture kbuild: fix CONFIG_CC_CAN_LINK(_STATIC) for cross-compilation with Clang kconfig: qconf: parse newer types at debug info kconfig: qconf: navigate menus on hyperlinks kconfig: qconf: don't show goback button on splitMode kconfig: qconf: simplify the goBack() logic kconfig: qconf: re-implement setSelected() kconfig: qconf: make debug links work again kconfig: qconf: make search fully work again on split mode kconfig: qconf: cleanup includes docs: kbuild: fix ReST formatting gcc-plugins: fix gcc-plugins directory path in documentation
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds authored
Pull SCSI fixes from James Bottomley: "Four small fixes in three drivers. The mptfusion one has actually caused user visible issues in certain kernel configurations" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: mptfusion: Don't use GFP_ATOMIC for larger DMA allocations scsi: libfc: Skip additional kref updating work event scsi: libfc: Handling of extra kref scsi: qla2xxx: Fix a condition in qla2x00_find_all_fabric_devs()
-
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull block fixes from Jens Axboe: - NVMe fixes from Christoph: - Fix crash in multi-path disk add (Christoph) - Fix ignore of identify error (Sagi) - Fix a compiler complaint that a function should be static (Wei) * tag 'block-5.8-2020-07-05' of git://git.kernel.dk/linux-block: block: make function __bio_integrity_free() static nvme: fix a crash in nvme_mpath_add_disk nvme: fix identify error status silent ignore
-
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull io_uring fix from Jens Axboe: "Andres reported a regression with the fix that was merged earlier this week, where his setup of using signals to interrupt io_uring CQ waits no longer worked correctly. Fix this, and also limit our use of TWA_SIGNAL to the case where we need it, and continue using TWA_RESUME for task_work as before. Since the original is marked for 5.7 stable, let's flush this one out early" * tag 'io_uring-5.8-2020-07-05' of git://git.kernel.dk/linux-block: io_uring: fix regression with always ignoring signals in io_cqring_wait()
-
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxLinus Torvalds authored
Pull i2c fixes from Wolfram Sang: "The usual driver fixes and documentation updates" * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: mlxcpld: check correct size of maximum RECV_LEN packet i2c: add Kconfig help text for slave mode i2c: slave-eeprom: update documentation i2c: eg20t: Load module automatically if ID matches i2c: designware: platdrv: Set class based on DMI i2c: algo-pca: Add 0x78 as SCL stuck low status for PCA9665
-
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linuxLinus Torvalds authored
Pull MIPS fixes from Thomas Bogendoerfer: - fix for missing hazard barrier - DT fix for ingenic - DT fix of GPHY names for lantiq - fix usage of smp_processor_id() while preemption is enabled * tag 'mips_fixes_5.8_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: MIPS: Do not use smp_processor_id() in preemptible code MIPS: Add missing EHB in mtc0 -> mfc0 sequence for DSPen MIPS: ingenic: gcw0: Fix HP detection GPIO. MIPS: lantiq: xway: sysctrl: fix the GPHY clock alias names
-
Xingxing Su authored
Use preempt_disable() to fix the following bug under CONFIG_DEBUG_PREEMPT. [ 21.915305] BUG: using smp_processor_id() in preemptible [00000000] code: qemu-system-mip/1056 [ 21.923996] caller is do_ri+0x1d4/0x690 [ 21.927921] CPU: 0 PID: 1056 Comm: qemu-system-mip Not tainted 5.8.0-rc2 #3 [ 21.934913] Stack : 0000000000000001 ffffffff81370000 ffffffff8071cd60 a80f926d5ac95694 [ 21.942984] a80f926d5ac95694 0000000000000000 98000007f0043c88 ffffffff80f2fe40 [ 21.951054] 0000000000000000 0000000000000000 0000000000000001 0000000000000000 [ 21.959123] ffffffff802d60cc 98000007f0043dd8 ffffffff81f4b1e8 ffffffff81f60000 [ 21.967192] ffffffff81f60000 ffffffff80fe0000 ffff000000000000 0000000000000000 [ 21.975261] fffffffff500cce1 0000000000000001 0000000000000002 0000000000000000 [ 21.983331] ffffffff80fe1a40 0000000000000006 ffffffff8077f940 0000000000000000 [ 21.991401] ffffffff81460000 98000007f0040000 98000007f0043c80 000000fffba8cf20 [ 21.999471] ffffffff8071cd60 0000000000000000 0000000000000000 0000000000000000 [ 22.007541] 0000000000000000 0000000000000000 ffffffff80212ab4 a80f926d5ac95694 [ 22.015610] ... [ 22.018086] Call Trace: [ 22.020562] [<ffffffff80212ab4>] show_stack+0xa4/0x138 [ 22.025732] [<ffffffff8071cd60>] dump_stack+0xf0/0x150 [ 22.030903] [<ffffffff80c73f5c>] check_preemption_disabled+0xf4/0x100 [ 22.037375] [<ffffffff80213b84>] do_ri+0x1d4/0x690 [ 22.042198] [<ffffffff8020b828>] handle_ri_int+0x44/0x5c [ 24.359386] BUG: using smp_processor_id() in preemptible [00000000] code: qemu-system-mip/1072 [ 24.368204] caller is do_ri+0x1a8/0x690 [ 24.372169] CPU: 4 PID: 1072 Comm: qemu-system-mip Not tainted 5.8.0-rc2 #3 [ 24.379170] Stack : 0000000000000001 ffffffff81370000 ffffffff8071cd60 a80f926d5ac95694 [ 24.387246] a80f926d5ac95694 0000000000000000 98001007ef06bc88 ffffffff80f2fe40 [ 24.395318] 0000000000000000 0000000000000000 0000000000000001 0000000000000000 [ 24.403389] ffffffff802d60cc 98001007ef06bdd8 ffffffff81f4b818 ffffffff81f60000 [ 24.411461] ffffffff81f60000 ffffffff80fe0000 ffff000000000000 0000000000000000 [ 24.419533] fffffffff500cce1 0000000000000001 0000000000000002 0000000000000000 [ 24.427603] ffffffff80fe0000 0000000000000006 ffffffff8077f940 0000000000000020 [ 24.435673] ffffffff81460020 98001007ef068000 98001007ef06bc80 000000fffbbbb370 [ 24.443745] ffffffff8071cd60 0000000000000000 0000000000000000 0000000000000000 [ 24.451816] 0000000000000000 0000000000000000 ffffffff80212ab4 a80f926d5ac95694 [ 24.459887] ... [ 24.462367] Call Trace: [ 24.464846] [<ffffffff80212ab4>] show_stack+0xa4/0x138 [ 24.470029] [<ffffffff8071cd60>] dump_stack+0xf0/0x150 [ 24.475208] [<ffffffff80c73f5c>] check_preemption_disabled+0xf4/0x100 [ 24.481682] [<ffffffff80213b58>] do_ri+0x1a8/0x690 [ 24.486509] [<ffffffff8020b828>] handle_ri_int+0x44/0x5c Signed-off-by: Xingxing Su <suxingxing@loongson.cn> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
-
Hauke Mehrtens authored
This resolves the hazard between the mtc0 in the change_c0_status() and the mfc0 in configure_exception_vector(). Without resolving this hazard configure_exception_vector() could read an old value and would restore this old value again. This would revert the changes change_c0_status() did. I checked this by printing out the read_c0_status() at the end of per_cpu_trap_init() and the ST0_MX is not set without this patch. The hazard is documented in the MIPS Architecture Reference Manual Vol. III: MIPS32/microMIPS32 Privileged Resource Architecture (MD00088), rev 6.03 table 8.1 which includes: Producer | Consumer | Hazard ----------|----------|---------------------------- mtc0 | mfc0 | any coprocessor 0 register I saw this hazard on an Atheros AR9344 rev 2 SoC with a MIPS 74Kc CPU. There the change_c0_status() function would activate the DSPen by setting ST0_MX in the c0_status register. This was reverted and then the system got a DSP exception when the DSP registers were saved in save_dsp() in the first process switch. The crash looks like this: [ 0.089999] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [ 0.097796] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [ 0.107070] Kernel panic - not syncing: Unexpected DSP exception [ 0.113470] Rebooting in 1 seconds.. We saw this problem in OpenWrt only on the MIPS 74Kc based Atheros SoCs, not on the 24Kc based SoCs. We only saw it with kernel 5.4 not with kernel 4.19, in addition we had to use GCC 8.4 or 9.X, with GCC 8.3 it did not happen. In the kernel I bisected this problem to commit 9012d011 ("compiler: allow all arches to enable CONFIG_OPTIMIZE_INLINING"), but when this was reverted it also happened after commit 172dcd93 ("MIPS: Always allocate exception vector for MIPSr2+"). Commit 0b24cae4 ("MIPS: Add missing EHB in mtc0 -> mfc0 sequence.") does similar changes to a different file. I am not sure if there are more places affected by this problem. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Cc: <stable@vger.kernel.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
-
Paul Menzel authored
Running `make savedefconfig` creates by default `defconfig`, which is, currently, on git’s radar, for example, `git status` lists this file as untracked. So, add the file to `.gitignore`, so it’s ignored by git. Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
-
- 04 Jul, 2020 3 commits
-
-
Enric Balletbo i Serra authored
Equivalent information can be nowadays obtained using function tracer Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
-
Enric Balletbo i Serra authored
There are some `static const u8` variables that are not used, this triggers a warning building with `make W=1`, it is safe to remove them, so do it and make the compiler more happy. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
-
Matthias Brugger authored
The driver will be loaded by via a platform device. So we will need to get the device_node from the parent device. Depending on this we will set the driver data. As all this is done later already, just delete the call to of_device_get_match_data. Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
-