summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2016-06-08drm/i915/kbl: Add WaClearSlmSpaceAtContextSwitchMika Kuoppala
This workaround for bdw and chv, is also needed for kbl A0. References: HSD#1911519, BSID#569 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465309159-30531-24-git-send-email-mika.kuoppala@intel.com
2016-06-08drm/i915/skl: Extend WaDisableChickenBitTSGBarrierAckForFFSliceCSMika Kuoppala
There is ambiguity in the documentation between D0 and E0. Extend this workaround to E0. References: BSID#779 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465309159-30531-23-git-send-email-mika.kuoppala@intel.com
2016-06-08drm/i915/gen9: Add WaEnableChickenDCPRMika Kuoppala
Workaround for display underrun issues with Y & Yf Tiling. Set this on all gen9 as stated by bspec. v2: proper workaround name References: HSD#2136383, BSID#857 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465309159-30531-22-git-send-email-mika.kuoppala@intel.com
2016-06-08drm/i915/kbl: Add WaDisableSbeCacheDispatchPortSharingMika Kuoppala
This is needed for all kbl revision. v2: Don't add revid checks to generic gen9 init (Arun) References: HSD#2135593 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465309159-30531-21-git-send-email-mika.kuoppala@intel.com
2016-06-08drm/i915/kbl: Add WaDisableGafsUnitClkGatingMika Kuoppala
We need to disable clock gating in this unit to work around hardware issue causing possible corruption/hang. v2: name the bit (Ville) v3: leave the fix enabled for 2227050 and set correct bit (Matthew) v4: Split out the skl part in separate commit for easier backport References: HSD#2227156, HSD#2227050 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465309159-30531-20-git-send-email-mika.kuoppala@intel.com
2016-06-08drm/i915/kbl: Add WaForGAMHangMika Kuoppala
Add this workaround for A0 and B0 revisions References: HSD#2226935 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465309159-30531-19-git-send-email-mika.kuoppala@intel.com
2016-06-08drm/i915/skl: Add WAC6entrylatencyMika Kuoppala
This workaround is for fbc working with rc6 on skylake. Bspec states that setting this bit needs to be coordinated with uncore but offers no further details. v2: rebase References: HSD#4712857 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465309159-30531-18-git-send-email-mika.kuoppala@intel.com
2016-06-08drm/i915/gen9: Add WaDisableSkipCachingMika Kuoppala
Make sure that we never enable skip caching on gen9 by accident. References: HSD#2134698 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465309159-30531-17-git-send-email-mika.kuoppala@intel.com
2016-06-08drm/i915: Add WaInsertDummyPushConstP for bxt and kblMika Kuoppala
Add this workaround for both bxt and kbl up to until rev B0. References: HSD#2136703 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465309159-30531-16-git-send-email-mika.kuoppala@intel.com
2016-06-08drm/i915/kbl: Add WaDisableDynamicCreditSharingMika Kuoppala
Bspec states that we need to turn off dynamic credit sharing on kbl revid a0 and b0. This happens by writing bit 28 on 0x4ab8. References: HSD#2225601, HSD#2226938, HSD#2225763 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465309159-30531-15-git-send-email-mika.kuoppala@intel.com
2016-06-08drm/i915/kbl: Add WaDisableGamClockGatingMika Kuoppala
According to bspec we need to disable gam unit clock gating on on kbl revids A0 and B0. References: HSD#2226858, HSD#1944358 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465309159-30531-14-git-send-email-mika.kuoppala@intel.com
2016-06-08drm/i915/gen9: Enable must set chicken bits in config0 regMika Kuoppala
The bspec states that these must be set in CONFIG0 for all gen9. v2: rebase v3: fix spacing (Matthew) References: HSD#2134995 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465309159-30531-13-git-send-email-mika.kuoppala@intel.com
2016-06-08drm/i915/kbl: Add WaDisableLSQCROPERFforOCLMika Kuoppala
Extend the scope of this workaround, already used in skl, to also take effect in kbl. v2: Fix KBL_REVID_E0 (Matthew) References: HSD#2132677 Cc: Matthew Auld <matthew.william.auld@gmail.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465309159-30531-12-git-send-email-mika.kuoppala@intel.com
2016-06-08drm/i915/edp: Add WaKVMNotificationOnConfigChange:bdwMika Kuoppala
According to bspec this workaround helps to reduce lag and improve performance on edp. Documentation suggests this for bdw and all gen9. However evidence shows that this register is missing on gen9 and causing unclaimed mmio access if we access it. So apply to bdw only where the reg exists and can hold its value. v2: drop skl References: HSD#2134579 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465309159-30531-11-git-send-email-mika.kuoppala@intel.com
2016-06-08drm/i915/kbl: Add WaDisableSDEUnitClockGatingMika Kuoppala
Add this workaround until upto kbl revid B0. References: HSD#1802092 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465309159-30531-10-git-send-email-mika.kuoppala@intel.com
2016-06-08drm/i915/kbl: Add WaDisableFenceDestinationToSLM for A0Mika Kuoppala
Add this workaround for kbl revid A0 only. v2: rebase v3: carve out a non related workaround (Chris) References: HSD#1911714 Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465309159-30531-9-git-send-email-mika.kuoppala@intel.com
2016-06-08drm/i915/kbl: Add WaEnableGapsTsvCreditFixMika Kuoppala
We need this crucial workaround from skl also to all kbl revisions. Lack of it was causing system hangs on skl enabling so this is a must have. v2: Don't add revid checks to gen9 init workarounds (Arun) References: HSD#2126660 Cc: Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465309159-30531-8-git-send-email-mika.kuoppala@intel.com
2016-06-08drm/i915: Mimic skl with WaForceEnableNonCoherentMika Kuoppala
Past evidence with system hangs and hsds tie WaForceEnableNonCoherent and WaDisableHDCInvalidation to WaForceContextSaveRestoreNonCoherent. Documentation states that WaForceContextSaveRestoreNonCoherent would not be needed on skl past E0 but evidence proved otherwise. See commit <510650e8b2ab> ("drm/i915/skl: Fix spurious gpu hang with gt3/gt4 revs"). In this scope consider kbl to be skl with a bigger revision than E0 so play it safe and bind these two workarounds to the WaForceContextSaveRestoreNonCoherent, and apply to all gen9. v2: fix comment (Matthew) References: HSD#2134449, HSD#2131413 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465309159-30531-7-git-send-email-mika.kuoppala@intel.com
2016-06-08drm/i915/gen9: Always apply WaForceContextSaveRestoreNonCoherentMika Kuoppala
The revision id range for this workaround has changed. So apply it to all revids on all gen9. References: HSD#2134449 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465309159-30531-6-git-send-email-mika.kuoppala@intel.com
2016-06-08drm/i915/kbl: Add WaSkipStolenMemoryFirstPage for A0Mika Kuoppala
We need this for kbl a0 boards. Note that this should be also for bxt A0 but we omit that on purpose as bxt A0's are out of fashion already. References: HSD#1912158, HSD#4393097 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465309159-30531-5-git-send-email-mika.kuoppala@intel.com
2016-06-08drm/i915/kbl: Add REVID macroMika Kuoppala
Add REVID macro for kbl to limit wa applicability to particular revision range. Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465309159-30531-4-git-send-email-mika.kuoppala@intel.com
2016-06-08drm/i915/kbl: Init gen9 workaroundsMika Kuoppala
Kabylake is part of gen9 family so init the generic gen9 workarounds for it. v2: rebase Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465309159-30531-3-git-send-email-mika.kuoppala@intel.com
2016-06-08drm/i915/skl: Add WaDisableGafsUnitClkGatingMika Kuoppala
We need to disable clock gating in this unit to work around hardware issue causing possible corruption/hang. v2: name the bit (Ville) v3: leave the fix enabled for 2227050 and set correct bit (Matthew) References: HSD#2227156, HSD#2227050 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465309159-30531-2-git-send-email-mika.kuoppala@intel.com
2016-06-08drivers: of: Fix of_pci.h header guardRobin Murphy
The compilation of of_pci.c is governed by CONFIG_OF_PCI, but the corresponding declarations in of_pci.h are inconsistently guarded by CONFIG_OF, with the result that if CONFIG_PCI is disabled for an OF platform, the dangling external declarations are still active and the inline stub definitions not. So far this has managed to go unnoticed since it happens that the only references to these functions are from code which itself depends on CONFIG_PCI or CONFIG_OF_PCI. Fix this with the appropriate config guard so that any new callers outside PCI-specific code don't start unexpectedly breaking under certain configs. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Rob Herring <robh@kernel.org>
2016-06-08dt-bindings: Add vendor prefix for TechNexionFabio Estevam
TechNexion designs and manufactures embedded computing systems: http://www.technexion.com/ Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by: Rob Herring <robh@kernel.org>
2016-06-08sched/debug: Fix 'schedstats=enable' cmdline optionJosh Poimboeuf
The 'schedstats=enable' option doesn't work, and also produces the following warning during boot: WARNING: CPU: 0 PID: 0 at /home/jpoimboe/git/linux/kernel/jump_label.c:61 static_key_slow_inc+0x8c/0xa0 static_key_slow_inc used before call to jump_label_init Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 4.7.0-rc1+ #25 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.8.1-20150318_183358- 04/01/2014 0000000000000086 3ae3475a4bea95d4 ffffffff81e03da8 ffffffff8143fc83 ffffffff81e03df8 0000000000000000 ffffffff81e03de8 ffffffff810b1ffb 0000003d00000096 ffffffff823514d0 ffff88007ff197c8 0000000000000000 Call Trace: [<ffffffff8143fc83>] dump_stack+0x85/0xc2 [<ffffffff810b1ffb>] __warn+0xcb/0xf0 [<ffffffff810b207f>] warn_slowpath_fmt+0x5f/0x80 [<ffffffff811e9c0c>] static_key_slow_inc+0x8c/0xa0 [<ffffffff810e07c6>] static_key_enable+0x16/0x40 [<ffffffff8216d633>] setup_schedstats+0x29/0x94 [<ffffffff82148a05>] unknown_bootoption+0x89/0x191 [<ffffffff810d8617>] parse_args+0x297/0x4b0 [<ffffffff82148d61>] start_kernel+0x1d8/0x4a9 [<ffffffff8214897c>] ? set_init_arg+0x55/0x55 [<ffffffff82148120>] ? early_idt_handler_array+0x120/0x120 [<ffffffff821482db>] x86_64_start_reservations+0x2f/0x31 [<ffffffff82148427>] x86_64_start_kernel+0x14a/0x16d The problem is that it tries to update the 'sched_schedstats' static key before jump labels have been initialized. Changing jump_label_init() to be called earlier before parse_early_param() wouldn't fix it: it would still fail trying to poke_text() because mm isn't yet initialized. Instead, just create a temporary '__sched_schedstats' variable which can be copied to the static key later during sched_init() after jump labels have been initialized. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: cb2517653fcc ("sched/debug: Make schedstats a runtime tunable that is disabled by default") Link: http://lkml.kernel.org/r/453775fe3433bed65731a583e228ccea806d18cd.1465322027.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-06-08sched/debug: Fix /proc/sched_debug regressionJosh Poimboeuf
Commit: cb2517653fcc ("sched/debug: Make schedstats a runtime tunable that is disabled by default") ... introduced a bug when CONFIG_SCHEDSTATS is enabled and the runtime tunable is disabled (which is the default). The wait-time, sum-exec, and sum-sleep fields are missing from the /proc/sched_debug file in the runnable_tasks section. Fix it with a new schedstat_val() macro which returns the field value when schedstats is enabled and zero otherwise. The macro works with both SCHEDSTATS and !SCHEDSTATS. I put the macro in stats.h since it might end up being useful in other places. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Mel Gorman <mgorman@techsingularity.net> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: cb2517653fcc ("sched/debug: Make schedstats a runtime tunable that is disabled by default") Link: http://lkml.kernel.org/r/bcda7c2790cf2ccbe586a28c02dd7b6fe7749a2b.1464994423.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-06-08perf/core: Remove a redundant checkAlexander Shishkin
There is no way to end up in _free_event() with event::pmu being NULL. The latter is initialized in event allocation path and remains set forever. In case of allocation failure, the error path doesn't use _free_event(). Having the check, however, suggests that it is possible to have a event::pmu==NULL situation in _free_event() and confuses the robots. This patch gets rid of the check. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: eranian@google.com Cc: vince@deater.net Link: http://lkml.kernel.org/r/1465303455-26032-1-git-send-email-alexander.shishkin@linux.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-06-08locking/qspinlock: Fix spin_unlock_wait() some morePeter Zijlstra
While this prior commit: 54cf809b9512 ("locking,qspinlock: Fix spin_is_locked() and spin_unlock_wait()") ... fixes spin_is_locked() and spin_unlock_wait() for the usage in ipc/sem and netfilter, it does not in fact work right for the usage in task_work and futex. So while the 2 locks crossed problem: spin_lock(A) spin_lock(B) if (!spin_is_locked(B)) spin_unlock_wait(A) foo() foo(); ... works with the smp_mb() injected by both spin_is_locked() and spin_unlock_wait(), this is not sufficient for: flag = 1; smp_mb(); spin_lock() spin_unlock_wait() if (!flag) // add to lockless list // iterate lockless list ... because in this scenario, the store from spin_lock() can be delayed past the load of flag, uncrossing the variables and loosing the guarantee. This patch reworks spin_is_locked() and spin_unlock_wait() to work in both cases by exploiting the observation that while the lock byte store can be delayed, the contender must have registered itself visibly in other state contained in the word. It also allows for architectures to override both functions, as PPC and ARM64 have an additional issue for which we currently have no generic solution. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Boqun Feng <boqun.feng@gmail.com> Cc: Davidlohr Bueso <dave@stgolabs.net> Cc: Giovanni Gherdovich <ggherdovich@suse.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Pan Xinhui <xinhui.pan@linux.vnet.ibm.com> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Waiman Long <waiman.long@hpe.com> Cc: Will Deacon <will.deacon@arm.com> Cc: stable@vger.kernel.org # v4.2 and later Fixes: 54cf809b9512 ("locking,qspinlock: Fix spin_is_locked() and spin_unlock_wait()") Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-06-08gpio: bcm-kona: fix bcm_kona_gpio_reset() warningsBen Dooks
The bcm_kona_gpio_reset() calls bcm_kona_gpio_write_lock_regs() with what looks like the wrong parameter. The write_lock_regs function takes a pointer to the registers, not the bcm_kona_gpio structure. Fix the warning, and probably bug by changing the function to pass reg_base instead of kona_gpio, fixing the following warning: drivers/gpio/gpio-bcm-kona.c:550:47: warning: incorrect type in argument 1 (different address spaces) expected void [noderef] <asn:2>*reg_base got struct bcm_kona_gpio *kona_gpio warning: incorrect type in argument 1 (different address spaces) expected void [noderef] <asn:2>*reg_base got struct bcm_kona_gpio *kona_gpio Cc: stable@vger.kernel.org Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Acked-by: Ray Jui <ray.jui@broadcom.com> Reviewed-by: Markus Mayer <mmayer@broadcom.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-06-08x86/cpu/AMD: Extend X86_FEATURE_TOPOEXT workaround to newer modelsBorislav Petkov
We need to reenable the topology extensions CPUID leafs on newer models too, if BIOS has disabled them, as we rely on them to get proper compute unit topology. Make the printk a once thing, while at it. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rui Huang <ray.huang@amd.com> Cc: Sherry Hurwitz <sherry.hurwitz@amd.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-hwmon@vger.kernel.org Link: http://lkml.kernel.org/r/1464775468-23355-1-git-send-email-bp@alien8.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-06-08gpio: select ANON_INODESLinus Walleij
The build servers found that gpiolib is using ANON_INODES but has forgotten to select it. Fix this. Reported-by: kbuild test robot <fengguang.wu@intel.com> Fixes: 521a2ad6f862 ("gpio: add userspace ABI for GPIO line information") Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-06-08regulator: qcom_smd: add regulator ops for pm8941 lnldoSrinivas Kandagatla
After "regulator: qcom_smd: add list_voltage callback" patch adding pm8941 lnldo regulators would bug on list_voltages as it is a fixed regulator without any linear range. This patch fixes that issue by adding dedicated ops for pm8941 lnldo without list_voltages callback. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org # v4.6
2016-06-08regulator: qcom_smd: add list_voltage callbackSrinivas Kandagatla
This patch adds support to list_voltage callback, so that consumers like mmc core, can get information of supported voltage range. Without this patch there is no way for mmc core to know this voltage range. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org # v4.6
2016-06-08x86/cpu/intel: Introduce macros for Intel family numbersDave Hansen
Problem: We have a boatload of open-coded family-6 model numbers. Half of them have these model numbers in hex and the other half in decimal. This makes grepping for them tons of fun, if you were to try. Solution: Consolidate all the magic numbers. Put all the definitions in one header. The names here are closely derived from the comments describing the models from arch/x86/events/intel/core.c. We could easily make them shorter by doing things like s/SANDYBRIDGE/SNB/, but they seemed fine even with the longer versions to me. Do not take any of these names too literally, like "DESKTOP" or "MOBILE". These are all colloquial names and not precise descriptions of everywhere a given model will show up. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Darren Hart <dvhart@infradead.org> Cc: Dave Hansen <dave@sr71.net> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Doug Thompson <dougthompson@xmission.com> Cc: Eduardo Valentin <edubezval@gmail.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> Cc: Kan Liang <kan.liang@intel.com> Cc: Len Brown <lenb@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com> Cc: Souvik Kumar Chakravarty <souvik.k.chakravarty@intel.com> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Vishwanath Somayaji <vishwanath.somayaji@intel.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: jacob.jun.pan@intel.com Cc: linux-acpi@vger.kernel.org Cc: linux-edac@vger.kernel.org Cc: linux-mmc@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: platform-driver-x86@vger.kernel.org Link: http://lkml.kernel.org/r/20160603001927.F2A7D828@viggo.jf.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-06-08leds: handle suspend/resume in heartbeat triggerLinus Walleij
The following phenomena was observed: when suspending the system, sometimes the heartbeat LED was left on, glowing and wasting power while the rest of the system is asleep, also disturbing power dissapation measures on the odd suspend cycle when it's left on. Clearly this is not how we want the heartbeat trigger to work: it should turn off and leave the LED off during system suspend. This removes the heartbeat trigger when preparing suspend and restores it during resume. The trigger code will make sure all LEDs are left in OFF state after removing the trigger, and will re-enable the trigger on all LEDs after resuming. Cc: linux-pm@vger.kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-06-08leds: core: Fix brightness setting upon hardware blinking enabledTony Makkiel
Commit 76931edd54f8 ("leds: fix brightness changing when software blinking is active") changed the semantics of led_set_brightness() which according to the documentation should disable blinking upon any brightness setting. Moreover it made it different for soft blink case, where it was possible to change blink brightness, and for hardware blink case, where setting any brightness greater than 0 was ignored. While the change itself is against the documentation claims, it was driven also by the fact that timer trigger remained active after turning blinking off. Fixing that would have required major refactoring in the led-core, led-class, and led-triggers because of cyclic dependencies. Finally, it has been decided that allowing for brightness change during blinking is beneficial as it can be accomplished without disturbing blink rhythm. The change in brightness setting semantics will not affect existing LED class drivers that implement blink_set op thanks to the LED_BLINK_SW flag introduced by this patch. The flag state will be from now on checked in led_set_brightness() which will allow to distinguish between software and hardware blink mode. In the latter case the control will be passed directly to the drivers which apply their semantics on brightness set, which is disable the blinking in case of most such drivers. New drivers will apply new semantics and just change the brightness while hardware blinking is on, if possible. The issue was smuggled by subsequent LED core improvements, which modified the code that originally introduced the problem. Fixes: f1e80c07416a ("leds: core: Add two new LED_BLINK_ flags") Signed-off-by: Tony Makkiel <tony.makkiel@daqri.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-06-08arm64: mm: always take dirty state from new pte in ptep_set_access_flagsWill Deacon
Commit 66dbd6e61a52 ("arm64: Implement ptep_set_access_flags() for hardware AF/DBM") ensured that pte flags are updated atomically in the face of potential concurrent, hardware-assisted updates. However, Alex reports that: | This patch breaks swapping for me. | In the broken case, you'll see either systemd cpu time spike (because | it's stuck in a page fault loop) or the system hang (because the | application owning the screen is stuck in a page fault loop). It turns out that this is because the 'dirty' argument to ptep_set_access_flags is always 0 for read faults, and so we can't use it to set PTE_RDONLY. The failing sequence is: 1. We put down a PTE_WRITE | PTE_DIRTY | PTE_AF pte 2. Memory pressure -> pte_mkold(pte) -> clear PTE_AF 3. A read faults due to the missing access flag 4. ptep_set_access_flags is called with dirty = 0, due to the read fault 5. pte is then made PTE_WRITE | PTE_DIRTY | PTE_AF | PTE_RDONLY (!) 6. A write faults, but pte_write is true so we get stuck The solution is to check the new page table entry (as would be done by the generic, non-atomic definition of ptep_set_access_flags that just calls set_pte_at) to establish the dirty state. Cc: <stable@vger.kernel.org> # 4.3+ Fixes: 66dbd6e61a52 ("arm64: Implement ptep_set_access_flags() for hardware AF/DBM") Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Reported-by: Alexander Graf <agraf@suse.de> Tested-by: Alexander Graf <agraf@suse.de> Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-06-08gpio: include <linux/io-mapping.h> in gpiolib-ofLinus Walleij
When enabling the gpiolib for all archs a build robot came up with this: All errors (new ones prefixed by >>): drivers/gpio/gpiolib-of.c: In function 'of_mm_gpiochip_add_data': >> drivers/gpio/gpiolib-of.c:317:2: error: implicit declaration of function 'iounmap' [-Werror=implicit-function-declaration] iounmap(mm_gc->regs); ^~~~~~~ cc1: some warnings being treated as errors Fix this by including <linux/io-mapping.h> explicitly. Fixes: 296ad4acb8ef ("gpio: remove deps on ARCH_[WANT_OPTIONAL|REQUIRE]_GPIOLIB") Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-06-08gpiolib: Fix unaligned used of reference countersRicardo Ribalda Delgado
gpiolib relies on the reference counters to clean up the gpio_device structure. Although the number of get/put is properly aligned on gpiolib.c itself, it does not take into consideration how the referece counters are affected by other external functions such as cdev_add and device_add. Because of this, after the last call to put_device, the reference counter has a value of +3, therefore never calling gpiodevice_release. Due to the fact that some of the device has already been cleaned on gpiochip_remove, the library will end up OOPsing the kernel (e.g. a call to of_gpiochip_find_and_xlate). Cc: stable@vger.kernel.org Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-06-08gpiolib: Fix NULL pointer deferenceRicardo Ribalda Delgado
Under some circumstances, a gpiochip might be half cleaned from the gpio_device list. This patch makes sure that the chip pointer is still valid, before calling the match function. [ 104.088296] BUG: unable to handle kernel NULL pointer dereference at 0000000000000090 [ 104.089772] IP: [<ffffffff813d2045>] of_gpiochip_find_and_xlate+0x15/0x80 [ 104.128273] Call Trace: [ 104.129802] [<ffffffff813d2030>] ? of_parse_own_gpio+0x1f0/0x1f0 [ 104.131353] [<ffffffff813cd910>] gpiochip_find+0x60/0x90 [ 104.132868] [<ffffffff813d21ba>] of_get_named_gpiod_flags+0x9a/0x120 ... [ 104.141586] [<ffffffff8163d12b>] gpio_led_probe+0x11b/0x360 Cc: stable@vger.kernel.org Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-06-08gpio: zynq: initialize clock even without CONFIG_PMHelmut Grohne
When the PM initialization was moved in the commit referenced below, the code enabling the clock was removed from the probe function. On CONFIG_PM=y kernels, this is not a problem as the pm resume hook enables the clock, but when power management is disabled, all those pm_* functions are noops and the clock is never enabled resulting in a dysfunctional gpio controller. Put the clock initialization back to support CONFIG_PM=n. Cc: stable@vger.kernel.org Signed-off-by: Helmut Grohne <h.grohne@intenta.de> Fixes: 3773c195d387 ("gpio: zynq: Do PM initialization earlier to support gpio hogs") Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-06-08gpio: 104-dio-48e: Fix control port offset computation off-by-one errorWilliam Breathitt Gray
There are only two control ports, each controlling three distinct I/O ports. To compute the control port address offset for a respective I/O port, the I/O port address offset should be divided by 3; dividing by 2 may result in not only the wrong address offset but possibly also an out-of-bounds array memory access for a non-existent third control port. Fixes: 1b06d64f7374 ("gpio: Add GPIO support for the ACCES 104-DIO-48E") Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-06-08net-sysfs: fix missing <linux/of_net.h>Ben Dooks
The of_find_net_device_by_node() function is defined in <linux/of_net.h> but not included in the .c file that implements it. Fix the following warning by including the header: net/core/net-sysfs.c:1494:19: warning: symbol 'of_find_net_device_by_node' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-08bridge: Don't insert unnecessary local fdb entry on changing mac addressToshiaki Makita
The missing br_vlan_should_use() test caused creation of an unneeded local fdb entry on changing mac address of a bridge device when there is a vlan which is configured on a bridge port but not on the bridge device. Fixes: 2594e9064a57 ("bridge: vlan: add per-vlan struct and move to rhashtables") Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-06-07Merge tag 'iio-fixes-for-4.7a' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus Jonathan writes: First round of iio fixes for the 4.7 cycle. A slightly bumper set due to travel delaying the pull request and a fair few issues with the recent merge window patches. Patches all over the place. The st-sensors one is probably the most involved, but definitly solves the issues seen. Note there are some other issues around that handler (and the fact that a lot of boards tie a level interrupt chip to an edge interrupt only irq chip). These are not regressions however, so will turn up the slow route. * core - iio_trigger_attach_pollfunc had some really badly wrong error handling. Another nasty triggered whilst chasing down issues with the st sensors rework below. * ad5592r - fix an off by one error when allocating channels. * am2315 - a stray mutex unlock before we ever take the lock. * apds9960 - missing a parent in the driver model (which should be the i2c device). Result is it doesn't turn up under /sys/bus/i2c/devices which some userspace code uses for repeatable device identification. * as3935 - ABI usage bug which meant a processed value was reported as raw. Now reporting scale as well to ensure userspace has the info it needs. - Don't return processed value via the buffer - it doesn't conform to the ABI and will overflow in some cases. - Fix a wrongly sized buffer which would overflow trashing part of the stack. Also move it onto the heap as part of the fix. * bh1780 - a missing return after write in debugfs lead to an incorrect read and a null pointer dereference. - dereferencing the wrong pointer in suspend and resume leading to unpredictable results. - assign a static name to avoid accidentally ending up with no name if loaded via device tree. * bmi160 - output data rate for the accelerometer was incorrectly reported. Fix it. - writing the output data rate was also wrong due to reverse parameters. * bmp280 - error message for wrong chip ID gave the wrong expected value. * hdc100x - mask for writing the integration time was wrong allowin g us to get 'stuck' in a particular value with no way back. - temperature reported in celsius rather than millicelsius as per the ABI. - Get rid of some incorrect data shifting which lead to readings being rather incorrect. * max44000 - drop scale attribute for proximity as it is an unscaled value (depends on what is in range rather than anything knowable at the detector). * st-pressure - ABI compliance fixes - units were wrong. * st-sensors - We introduced some nasty issues with the recent switch over to a a somewhat threaded handler in that we broke using a software trigger with these devices. Now do it properly. It's a larger patch than ideal for a fix, but the logic is straight forward. - Make sure the trigger is initialized before requesting the interrupt. This matters now the interrupt can be shared. Before it was ugly and wrong but short of flakey hardware could not be triggered. - Hammer down the dataready pin at boot - otherwise with really unlucky timing things could get interestingly wedged requiring a hard power down of the chip.
2016-06-07usb: echi-hcd: Add ehci_setup check before echi_shutdownSrinivas Kandagatla
This patch protects system from crashing at shutdown in cases where usb host is not added yet from OTG controller driver. As ehci_setup() not done yet, so stop accessing registers or variables initialized as part of ehci_setup(). The use case is simple, for boards like DB410c where the usb host or device functionality is decided based on the micro-usb cable presence. If the board boots up with micro-usb connected, the OTG driver like echi-msm would not add the usb host by default. However a system shutdown would go and access registers and uninitialized variables, resulting in below crash. Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = ffffffc034581000 [00000008] *pgd=0000000000000000, *pud=0000000000000000 CPU: 2 PID: 1957 Comm: reboot Not tainted 4.6.0+ #99 task: ffffffc034bc0000 ti: ffffffc0345cc000 task.ti: ffffffc0345cc000 PC is at ehci_halt+0x54/0x108 LR is at ehci_halt+0x38/0x108 pc : [<ffffff800869837c>] lr : [<ffffff8008698360>] pstate: a00001c5 sp : ffffffc0345cfc60 x29: ffffffc0345cfc60 x28: ffffffc0345cc000 x27: ffffff8008a4d000 x26: 000000000000008e x25: ffffff8008d86cb0 x24: ffffff800908b040 x23: ffffffc036068870 x22: ffffff8009d0a000 x21: ffffffc03512a410 x20: ffffffc03512a410 x19: ffffffc03512a338 x18: 00000000000065ba x17: ffffff8009b16b80 x16: 0000000000000003 x15: 00000000000065b9 x14: 00000000000065b6 x13: 0000000000000000 x12: 0000000000000000 x11: 000000000000003d x10: ffffffc0345cf9e0 x9 : 0000000000000001 x8 : ffffffc0345cc000 x7 : ffffff8008698360 x6 : 0000000000000000 x5 : 0000000000000080 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000008 x0 : ffffffc034bc0000 Process reboot (pid: 1957, stack limit = 0xffffffc0345cc020) Stack: (0xffffffc0345cfc60 to 0xffffffc0345d0000) fc60: ffffffc0345cfc90 ffffff8008698448 ffffffc03512a338 ffffffc03512a338 fc80: ffffffc03512a410 ffffff8008a3bbfc ffffffc0345cfcc0 ffffff8008698548 fca0: ffffffc03512a338 ffffffc03512a000 ffffffc03512a410 ffffff8009d0a000 fcc0: ffffffc0345cfcf0 ffffff800865d2bc ffffffc036068828 ffffffc036068810 fce0: ffffffc036003810 ffffff800853f43c ffffffc0345cfd00 ffffff800854338c fd00: ffffffc0345cfd10 ffffff800853f45c ffffffc0345cfd60 ffffff80080e0f48 fd20: 0000000000000000 0000000001234567 ffffff8008f8c000 ffffff8008f8c060 fd40: 0000000000000000 0000000000000015 0000000000000120 ffffff80080e0f30 fd60: ffffffc0345cfd70 ffffff80080e1020 ffffffc0345cfd90 ffffff80080e12fc fd80: 0000000000000000 0000000001234567 0000000000000000 ffffff8008085e70 fda0: 0000000000000000 0000005592905000 ffffffffffffffff 0000007f79daf1cc fdc0: 0000000000000000 0000000000000000 0000007ffcbb1198 000000000000000a fde0: 00000055928d3f58 0000000000000001 ffffffc034900000 00000000fffffffe fe00: ffffffc034900000 0000007f79da902c ffffffc0345cfe40 ffffff800820af38 fe20: 0000000000000000 0000007ffcbb1078 ffffffffffffffff ffffff80081e9b38 fe40: ffffffc0345cfe60 ffffff80081eb410 ffffffc0345cfe60 ffffff80081eb444 fe60: ffffffc0345cfec0 ffffff80081ec4f4 0000000000000000 0000007ffcbb1078 fe80: ffffffffffffffff 0000000000000015 ffffffc0345cfec0 0000007ffcbb1078 fea0: 0000000000000002 000000000000000a ffffffffffffffff 0000000000000000 fec0: 0000000000000000 ffffff8008085e70 fffffffffee1dead 0000000028121969 fee0: 0000000001234567 0000000000000000 ffffffffffffffff 8080800000800000 ff00: 0000800000808080 0000007ffcbb10f0 000000000000008e fefeff54918cb8c7 ff20: 7f7f7f7fffffffff 0101010101010101 0000000000000010 0000000000000000 ff40: 0000000000000000 0000007f79e33588 0000005592905eb8 0000007f79daf1b0 ff60: 0000007ffcbb1340 0000005592906000 0000005592905000 0000005592906000 ff80: 0000005592907000 0000000000000002 0000007ffcbb1d98 0000005592906000 ffa0: 00000055928d2000 0000000000000000 0000000000000000 0000007ffcbb1aa0 ffc0: 00000055928b819c 0000007ffcbb1aa0 0000007f79daf1cc 0000000000000000 ffe0: fffffffffee1dead 000000000000008e 05ef555057155555 d555544d55d775d3 Call trace: Exception stack(0xffffffc0345cfaa0 to 0xffffffc0345cfbc0) Set corner to 6 faa0: ffffffc03512a338 ffffffc03512a410 ffffffc0345cfc60 ffffff800869837c fac0: ffffff8008114210 0000000100000001 ffffff8009ce1b20 ffffff8009ce5f20 fae0: ffffffc0345cfb80 ffffff80081145a8 ffffffc0345cfc10 ffffff800810b924 fb00: ffffffc0345cc000 00000000000001c0 ffffffc03512a410 ffffff8009d0a000 fb20: ffffffc036068870 ffffff800908b040 ffffff8008d86cb0 000000000000008e fb40: ffffffc034bc0000 0000000000000008 0000000000000000 0000000000000000 fb60: 0000000000000001 0000000000000080 0000000000000000 ffffff8008698360 fb80: ffffffc0345cc000 0000000000000001 ffffffc0345cf9e0 000000000000003d fba0: 0000000000000000 0000000000000000 00000000000065b6 00000000000065b9 [<ffffff800869837c>] ehci_halt+0x54/0x108 [<ffffff8008698448>] ehci_silence_controller+0x18/0xcc [<ffffff8008698548>] ehci_shutdown+0x4c/0x64 [<ffffff800865d2bc>] usb_hcd_platform_shutdown+0x1c/0x24 [<ffffff800854338c>] platform_drv_shutdown+0x20/0x28 [<ffffff800853f45c>] device_shutdown+0xf4/0x1b0 [<ffffff80080e0f48>] kernel_restart_prepare+0x34/0x3c [<ffffff80080e1020>] kernel_restart+0x14/0x74 [<ffffff80080e12fc>] SyS_reboot+0x110/0x21c [<ffffff8008085e70>] el0_svc_naked+0x24/0x28 Code: 53001c42 350000a2 d5033e9f 91002021 (b9000022) Fixes 4bb3cad7125b ("usb: host: ehci-msm: Register usb shutdown function") Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: Pramod Gurav <pramod.gurav@linaro.org> Tested-by: Andy Gross <andy.gross@linaro.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-07usb: host: ehci-msm: Conditionally call ehci suspend/resumeAndy Gross
This patch fixes a suspend/resume issue where the driver is blindly calling ehci_suspend/resume functions when the ehci hasn't been setup. This results in a crash during suspend/resume operations. Signed-off-by: Andy Gross <andy.gross@linaro.org> Tested-by: Pramod Gurav <pramod.gurav@linaro.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-07MAINTAINERS: Add file patterns for usb device tree bindingsGeert Uytterhoeven
Submitters of device tree binding documentation may forget to CC the subsystem maintainer if this is missing. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-usb@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-07usb: host: ehci-tegra: Avoid getting the same reset twiceThierry Reding
Starting with commit 0b52297f2288 ("reset: Add support for shared reset controls") there is a reference count for reset control assertions. The goal is to allow resets to be shared by multiple devices and an assert will take effect only when all instances have asserted the reset. In order to preserve backwards-compatibility, all reset controls become exclusive by default. This is to ensure that reset_control_assert() can immediately assert in hardware. However, this new behaviour triggers the following warning in the EHCI driver for Tegra: [ 3.365019] ------------[ cut here ]------------ [ 3.369639] WARNING: CPU: 0 PID: 1 at drivers/reset/core.c:187 __of_reset_control_get+0x16c/0x23c [ 3.382151] Modules linked in: [ 3.385214] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc6-next-20160503 #140 [ 3.392769] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree) [ 3.399046] [<c010fa50>] (unwind_backtrace) from [<c010b120>] (show_stack+0x10/0x14) [ 3.406787] [<c010b120>] (show_stack) from [<c0347dcc>] (dump_stack+0x90/0xa4) [ 3.414007] [<c0347dcc>] (dump_stack) from [<c011f4fc>] (__warn+0xe8/0x100) [ 3.420964] [<c011f4fc>] (__warn) from [<c011f5c4>] (warn_slowpath_null+0x20/0x28) [ 3.428525] [<c011f5c4>] (warn_slowpath_null) from [<c03cc8cc>] (__of_reset_control_get+0x16c/0x23c) [ 3.437648] [<c03cc8cc>] (__of_reset_control_get) from [<c0526858>] (tegra_ehci_probe+0x394/0x518) [ 3.446600] [<c0526858>] (tegra_ehci_probe) from [<c04516d8>] (platform_drv_probe+0x4c/0xb0) [ 3.455029] [<c04516d8>] (platform_drv_probe) from [<c044fe78>] (driver_probe_device+0x1ec/0x330) [ 3.463892] [<c044fe78>] (driver_probe_device) from [<c0450074>] (__driver_attach+0xb8/0xbc) [ 3.472320] [<c0450074>] (__driver_attach) from [<c044e1ec>] (bus_for_each_dev+0x68/0x9c) [ 3.480489] [<c044e1ec>] (bus_for_each_dev) from [<c044f338>] (bus_add_driver+0x1a0/0x218) [ 3.488743] [<c044f338>] (bus_add_driver) from [<c0450768>] (driver_register+0x78/0xf8) [ 3.496738] [<c0450768>] (driver_register) from [<c010178c>] (do_one_initcall+0x40/0x170) [ 3.504909] [<c010178c>] (do_one_initcall) from [<c0c00ddc>] (kernel_init_freeable+0x158/0x1f8) [ 3.513600] [<c0c00ddc>] (kernel_init_freeable) from [<c0810784>] (kernel_init+0x8/0x114) [ 3.521770] [<c0810784>] (kernel_init) from [<c0107778>] (ret_from_fork+0x14/0x3c) [ 3.529361] ---[ end trace 4bda87dbe4ecef8a ]--- The reason is that Tegra SoCs have three EHCI controllers, each with a separate reset line. However the first controller contains UTMI pads configuration registers that are shared with its siblings and that are reset as part of the first controller's reset. There is special code in the driver to assert and deassert this shared reset at probe time, and it does so irrespective of which controller is probed first to ensure that these shared registers are reset before any of the controllers are initialized. Unfortunately this means that if the first controller gets probed first, it will request its own reset line and will subsequently request the same reset line again (temporarily) to perform the reset. This used to work fine before the above-mentioned commit, but now triggers the new WARN. Work around this by making sure we reuse the controller's reset if the controller happens to be the first controller. Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit (git 2.34.1) at 2025-09-14 08:34:21 +0000