summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-02-20bootconfig: Set CONFIG_BOOT_CONFIG=n by defaultMasami Hiramatsu
Set CONFIG_BOOT_CONFIG=n by default. This also warns user if CONFIG_BOOT_CONFIG=n but "bootconfig" is given in the kernel command line. Link: http://lkml.kernel.org/r/158220111291.26565.9036889083940367969.stgit@devnote2 Suggested-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2020-02-20tracing: Clear trace_state when starting traceMasami Hiramatsu
Clear trace_state data structure when starting trace in __synth_event_trace_start() internal function. Currently trace_state is initialized only in the synth_event_trace_start() API, but the trace_state in synth_event_trace() and synth_event_trace_array() are on the stack without initialization. This means those APIs will see wrong parameters and wil skip closing process in __synth_event_trace_end() because trace_state->disabled may be !0. Link: http://lkml.kernel.org/r/158193315899.8868.1781259176894639952.stgit@devnote2 Reviewed-by: Tom Zanussi <zanussi@kernel.org> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2020-02-20bootconfig: Mark boot_config_checksum() staticQiujun Huang
In fact, this function is only used in this file, so mark it with 'static'. Link: http://lkml.kernel.org/r/1581852511-14163-1-git-send-email-hqjagain@gmail.com Acked-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Qiujun Huang <hqjagain@gmail.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2020-02-20tracing: Disable trace_printk() on post poned testsSteven Rostedt (VMware)
The tracing seftests checks various aspects of the tracing infrastructure, and one is filtering. If trace_printk() is active during a self test, it can cause the filtering to fail, which will disable that part of the trace. To keep the selftests from failing because of trace_printk() calls, trace_printk() checks the variable tracing_selftest_running, and if set, it does not write to the tracing buffer. As some tracers were registered earlier in boot, the selftest they triggered would fail because not all the infrastructure was set up for the full selftest. Thus, some of the tests were post poned to when their infrastructure was ready (namely file system code). The postpone code did not set the tracing_seftest_running variable, and could fail if a trace_printk() was added and executed during their run. Cc: stable@vger.kernel.org Fixes: 9afecfbb95198 ("tracing: Postpone tracer start-up tests till the system is more robust") Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2020-02-20tracing: Have synthetic event test use raw_smp_processor_id()Steven Rostedt (VMware)
The test code that tests synthetic event creation pushes in as one of its test fields the current CPU using "smp_processor_id()". As this is just something to see if the value is correctly passed in, and the actual CPU used does not matter, use raw_smp_processor_id(), otherwise with debug preemption enabled, a warning happens as the smp_processor_id() is called without preemption enabled. Link: http://lkml.kernel.org/r/20200220162950.35162579@gandalf.local.home Reviewed-by: Tom Zanussi <zanussi@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2020-02-20xen: Enable interrupts when calling _cond_resched()Thomas Gleixner
xen_maybe_preempt_hcall() is called from the exception entry point xen_do_hypervisor_callback with interrupts disabled. _cond_resched() evades the might_sleep() check in cond_resched() which would have caught that and schedule_debug() unfortunately lacks a check for irqs_disabled(). Enable interrupts around the call and use cond_resched() to catch future issues. Fixes: fdfd811ddde3 ("x86/xen: allow privcmd hypercalls to be preempted") Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/878skypjrh.fsf@nanos.tec.linutronix.de Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2020-02-20ASoC: pcm512x: Fix unbalanced regulator enable call in probe error pathMatthias Reichl
When we get a clock error during probe we have to call regulator_bulk_disable before bailing out, otherwise we trigger a warning in regulator_put. Fix this by using "goto err" like in the error cases above. Fixes: 5a3af1293194d ("ASoC: pcm512x: Add PCM512x driver") Signed-off-by: Matthias Reichl <hias@horus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20200220202956.29233-1-hias@horus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-02-20tracing: Fix number printing bug in print_synth_event()Tom Zanussi
Fix a varargs-related bug in print_synth_event() which resulted in strange output and oopses on 32-bit x86 systems. The problem is that trace_seq_printf() expects the varargs to match the format string, but print_synth_event() was always passing u64 values regardless. This results in unspecified behavior when unpacking with va_arg() in trace_seq_printf(). Add a function that takes the size into account when calling trace_seq_printf(). Before: modprobe-1731 [003] .... 919.039758: gen_synth_test: next_pid_field=777(null)next_comm_field=hula hoops ts_ns=1000000 ts_ms=1000 cpu=3(null)my_string_field=thneed my_int_field=598(null) After: insmod-1136 [001] .... 36.634590: gen_synth_test: next_pid_field=777 next_comm_field=hula hoops ts_ns=1000000 ts_ms=1000 cpu=1 my_string_field=thneed my_int_field=598 Link: http://lkml.kernel.org/r/a9b59eb515dbbd7d4abe53b347dccf7a8e285657.1581720155.git.zanussi@kernel.org Reported-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Tom Zanussi <zanussi@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2020-02-20tracing: Check that number of vals matches number of synth event fieldsTom Zanussi
Commit 7276531d4036('tracing: Consolidate trace() functions') inadvertently dropped the synth_event_trace() and synth_event_trace_array() checks that verify the number of values passed in matches the number of fields in the synthetic event being traced, so add them back. Link: http://lkml.kernel.org/r/32819cac708714693669e0dfe10fe9d935e94a16.1581720155.git.zanussi@kernel.org Signed-off-by: Tom Zanussi <zanussi@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2020-02-20tracing: Make synth_event trace functions endian-correctTom Zanussi
synth_event_trace(), synth_event_trace_array() and __synth_event_add_val() write directly into the trace buffer and need to take endianness into account, like trace_event_raw_event_synth() does. Link: http://lkml.kernel.org/r/2011354355e405af9c9d28abba430d1f5ff7771a.1581720155.git.zanussi@kernel.org Signed-off-by: Tom Zanussi <zanussi@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2020-02-20tracing: Make sure synth_event_trace() example always uses u64Tom Zanussi
synth_event_trace() is the varargs version of synth_event_trace_array(), which takes an array of u64, as do synth_event_add_val() et al. To not only be consistent with those, but also to address the fact that synth_event_trace() expects every arg to be of the same type since it doesn't also pass in e.g. a format string, the caller needs to make sure all args are of the same type, u64. u64 is used because it needs to accomodate the largest type available in synthetic events, which is u64. This fixes the bug reported by the kernel test robot/Rong Chen. Link: https://lore.kernel.org/lkml/20200212113444.GS12867@shao2-debian/ Link: http://lkml.kernel.org/r/894c4e955558b521210ee0642ba194a9e603354c.1581720155.git.zanussi@kernel.org Fixes: 9fe41efaca084 ("tracing: Add synth event generation test module") Reported-by: kernel test robot <rong.a.chen@intel.com> Signed-off-by: Tom Zanussi <zanussi@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2020-02-20drm/i915/tgl: Program MBUS_ABOX{1,2}_CTL during display initMatt Roper
On gen11 we only needed to program MBus credits into MBUS_ABOX_CTL during display initialization, but on gen12 we're now supposed to program the same values into MBUS_ABOX1_CTL and MBUS_ABOX2_CTL as well. v2: - Program registers with rmw to preserve contents of unrelated bits. - Switch to the new display uncore helpers. Bspec: 49213 Bspec: 50096 Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200204011032.582737-2-matthew.d.roper@intel.com Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
2020-02-20drm/i915: Program MBUS with rmw during initializationMatt Roper
It wasn't terribly clear from the bspec's wording, but after discussion with the hardware folks, it turns out that we need to preserve the pre-existing contents of the MBUS ABOX control register when initializing a few specific bits. Bspec: 49213 Bspec: 50096 Fixes: 4cb4585e5a7f ("drm/i915/icl: initialize MBus during display init") Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200204011032.582737-1-matthew.d.roper@intel.com Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
2020-02-20drm/i915: Use intel_de_write_fw() for skl+ scaler registersVille Syrjälä
We have to write quite a few registers when programming the pipe scaler. Let's use intel_de_write_fw() for these to reduce the lockdep overhead a bit. All plane registers (including plane scaler) already do this. We already had a few accidental intel_de_write_fw() in there. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200212161738.28141-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-02-20drm/i915: Parametrize PFIT_PIPEVille Syrjälä
Make the PFIT_PIPE stuff less ugly via parametrization. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200212161738.28141-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-02-20drm/i915: Mark all HPD capabled connectors as suchVille Syrjälä
Currently we only set the DRM_CONNECTOR_POLL_{DISCONNECT,CONNECT} bits in intel_connector->polled (the base setting), leading to some confusing looking code to reset drm_connector->polled (the actual setting) to DRM_CONNECTOR_POLL_HPD. Let's set intel_connector->polled = DRM_CONNECTOR_POLL_HPD for all hpd capable connectors, and then we don't need so many special cases in the hotplug code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200205183546.9291-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-02-20drm/i915/hpd: Replace the loop-within-loop with two independent loopsVille Syrjälä
No point in looping over all connectors for each hpd pin. Just loop over each connector first and deal with each one's hpd pin. Then loop over all the hpd pins to mark them as enabled again. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200205183546.9291-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-02-20drm/i915: Add i9xx_lut_8()Ville Syrjälä
We have a nice little helper to compute a single LUT entry for everything except the 8bpc legacy gamma mode. Let's complete the set. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191107151725.10507-5-ville.syrjala@linux.intel.com Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
2020-02-21Merge tag 'drm-misc-next-2020-02-10' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 5.7: UAPI Changes: - lima: Add support for heap buffers Cross-subsystem Changes: Core Changes: - Implement mode_config mode_valid for memory constrained drivers - Bus format negociation between bridges - Consolidate fake vblank events for drivers without vblank interrupts - drm/bufs: dma_alloc related cleanups - drm/dp_mst: Various fixes - drm/print: New drm_device based print helpers - Thomas is a drm-misc maintainer now! Driver Changes: - DPMS cleanups for atomic drivers - Removal of owner field in SPI tinydrm drivers - Removal of explicit dependency on DT for tinydrm drivers - Conversion to YAML schemas for DT bindings - tidss: New driver - virtio: various reworks and fixes - Our usual dozen or so new panels or bridges Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20200210093421.xu4sofldm6wm6xq6@gilmour.lan
2020-02-20Merge branch 's390-fixes'David S. Miller
Julian Wiedmann says: ==================== s390/qeth: fixes 2020-02-20 please apply the following patch series for qeth to netdev's net tree. This corrects three minor issues: 1) return a more fitting errno when VNICC cmds are not supported, 2) remove a bogus WARN in the NAPI code, and 3) be _very_ pedantic about the RX copybreak. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-02-20s390/qeth: fix off-by-one in RX copybreak checkJulian Wiedmann
The RX copybreak is intended as the _max_ value where the frame's data should be copied. So for frame_len == copybreak, don't build an SG skb. Fixes: 4a71df50047f ("qeth: new qeth device driver") Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-02-20s390/qeth: don't warn for napi with 0 budgetJulian Wiedmann
Calling napi->poll() with 0 budget is a legitimate use by netpoll. Fixes: a1c3ed4c9ca0 ("qeth: NAPI support for l2 and l3 discipline") Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-02-20s390/qeth: vnicc Fix EOPNOTSUPP precedenceAlexandra Winter
When getting or setting VNICC parameters, the error code EOPNOTSUPP should have precedence over EBUSY. EBUSY is used because vnicc feature and bridgeport feature are mutually exclusive, which is a temporary condition. Whereas EOPNOTSUPP indicates that the HW does not support all or parts of the vnicc feature. This issue causes the vnicc sysfs params to show 'blocked by bridgeport' for HW that does not support VNICC at all. Fixes: caa1f0b10d18 ("s390/qeth: add VNICC enable/disable support") Signed-off-by: Alexandra Winter <wintera@linux.ibm.com> Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-02-20openvswitch: Distribute switch variables for initializationKees Cook
Variables declared in a switch statement before any case statements cannot be automatically initialized with compiler instrumentation (as they are not part of any execution flow). With GCC's proposed automatic stack variable initialization feature, this triggers a warning (and they don't get initialized). Clang's automatic stack variable initialization (via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also doesn't initialize such variables[1]. Note that these warnings (or silent skipping) happen before the dead-store elimination optimization phase, so even when the automatic initializations are later elided in favor of direct initializations, the warnings remain. To avoid these problems, move such variables into the "case" where they're used or lift them up into the main function body. net/openvswitch/flow_netlink.c: In function ‘validate_set’: net/openvswitch/flow_netlink.c:2711:29: warning: statement will never be executed [-Wswitch-unreachable] 2711 | const struct ovs_key_ipv4 *ipv4_key; | ^~~~~~~~ [1] https://bugs.llvm.org/show_bug.cgi?id=44916 Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-02-20net: ip6_gre: Distribute switch variables for initializationKees Cook
Variables declared in a switch statement before any case statements cannot be automatically initialized with compiler instrumentation (as they are not part of any execution flow). With GCC's proposed automatic stack variable initialization feature, this triggers a warning (and they don't get initialized). Clang's automatic stack variable initialization (via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also doesn't initialize such variables[1]. Note that these warnings (or silent skipping) happen before the dead-store elimination optimization phase, so even when the automatic initializations are later elided in favor of direct initializations, the warnings remain. To avoid these problems, move such variables into the "case" where they're used or lift them up into the main function body. net/ipv6/ip6_gre.c: In function ‘ip6gre_err’: net/ipv6/ip6_gre.c:440:32: warning: statement will never be executed [-Wswitch-unreachable] 440 | struct ipv6_tlv_tnl_enc_lim *tel; | ^~~ net/ipv6/ip6_tunnel.c: In function ‘ip6_tnl_err’: net/ipv6/ip6_tunnel.c:520:32: warning: statement will never be executed [-Wswitch-unreachable] 520 | struct ipv6_tlv_tnl_enc_lim *tel; | ^~~ [1] https://bugs.llvm.org/show_bug.cgi?id=44916 Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-02-20net: core: Distribute switch variables for initializationKees Cook
Variables declared in a switch statement before any case statements cannot be automatically initialized with compiler instrumentation (as they are not part of any execution flow). With GCC's proposed automatic stack variable initialization feature, this triggers a warning (and they don't get initialized). Clang's automatic stack variable initialization (via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also doesn't initialize such variables[1]. Note that these warnings (or silent skipping) happen before the dead-store elimination optimization phase, so even when the automatic initializations are later elided in favor of direct initializations, the warnings remain. To avoid these problems, move such variables into the "case" where they're used or lift them up into the main function body. net/core/skbuff.c: In function ‘skb_checksum_setup_ip’: net/core/skbuff.c:4809:7: warning: statement will never be executed [-Wswitch-unreachable] 4809 | int err; | ^~~ [1] https://bugs.llvm.org/show_bug.cgi?id=44916 Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-02-20ARM: dts: dra7-l4: mark timer13-16 as pwm capableGrygorii Strashko
DMTimers 13 - 16 are PWM capable and also can be used for CPTS input signals generation. Hence, mark them as "ti,timer-pwm". Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-02-20ARM: dts: dra7xx-clocks: Fixup IPU1 mux clock parent sourceSuman Anna
The IPU1 functional clock is the output of a mux clock (represented by ipu1_gfclk_mux previously) and the clock source for this has been updated to be sourced from dpll_core_h22x2_ck in commit 39879c7d963e ("ARM: dts: dra7xx-clocks: Source IPU1 functional clock from CORE DPLL"). ipu1_gfclk_mux is an obsolete clock now with the clkctrl conversion, and this clock source parenting is lost during the new clkctrl layout conversion. Remove this stale clock and fix up the clock source for this mux clock using the latest equivalent clkctrl clock. This restores the previous logic and ensures that the IPU1 continues to run at the same frequency of IPU2 and independent of the ABE DPLL. Fixes: b5f8ffbb6fad ("ARM: dts: dra7: convert to use new clkctrl layout") Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-02-20ARM: dts: am437x-idk-evm: Fix incorrect OPP node namesSuman Anna
The commit 337c6c9a69af ("ARM: dts: am437x-idk-evm: Disable OPP50 for MPU") adjusts couple of OPP nodes defined in the common am4372.dtsi file, but used outdated node names. This results in these getting treated as new OPP nodes with missing properties. Fix this properly by using the correct node names as updated in commit b9cb2ba71848 ("ARM: dts: Use - instead of @ for DT OPP entries for TI SoCs"). Reported-by: Roger Quadros <rogerq@ti.com> Fixes: 337c6c9a69af ("ARM: dts: am437x-idk-evm: Disable OPP50 for MPU") Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-02-20drm/i915/uc: consolidate firmware cleanupDaniele Ceraolo Spurio
We are quite trigger happy in cleaning up the firmware blobs, as we do so from several error/fini paths in GuC/HuC/uC code. We do have the __uc_cleanup_firmwares cleanup function, which unwinds __uc_fetch_firmwares and is already called both from the error path of gem_init and from gem_driver_release, so let's stop cleaning up from all the other paths. The fact that we're not cleaning the firmware immediately means that we can't consider firmware availability as an indication of initialization success. A "LOADABLE" status has been added to indicate that the initialization was successful, to be used to selectively load HuC only if HuC init has completed (HuC init failure is not considered a fatal error). v2: s/ready_to_load/loadable (Michal), only run guc/huc_fini if the fw is in loadable state Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> #v1 Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-9-daniele.ceraolospurio@intel.com
2020-02-20drm/i915/uc: Abort early on uc_init failureDaniele Ceraolo Spurio
Now that we can differentiate wants vs uses GuC/HuC, intel_uc_init is restricted to running only if we have successfully fetched the required blob(s) and are committed to using the microcontroller(s). The only remaining thing that can go wrong in uc_init is the allocation of GuC/HuC related objects; if we get such a failure better to bail out immediately instead of wedging later, like we do for e.g. intel_engines_init, since without objects we can't use the HW, including not being able to attempt the firmware load. While at it, remove the unneeded fw_cleanup call (this is handled outside of gt_init) and add a probe failure injection point for testing. Also, update the logs for <g/h>uc_init failures to probe_failure() since they will cause the driver load to fail. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Fernando Pacheco <fernando.pacheco@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-8-daniele.ceraolospurio@intel.com
2020-02-20drm/i915/guc: Apply new uC status tracking to GuC submission as wellDaniele Ceraolo Spurio
To be able to differentiate the before and after of our commitment to GuC submission, which will be used in follow-up patches to early set-up the submission structures. v2: move functions to guc_submission.h (Michal) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-7-daniele.ceraolospurio@intel.com
2020-02-20drm/i915/uc: Improve tracking of uC init statusDaniele Ceraolo Spurio
To be able to setup GuC submission functions during engine init we need to commit to using GuC as soon as possible. Currently, the only thing that can stop us from using the microcontrollers once we've fetched the blobs is a fundamental error (e.g. OOM); given that if we hit such an error we can't really fall-back to anything, we can "officialize" the FW fetching completion as the moment at which we're committing to using GuC. To better differentiate this case, the uses_guc check, which indicates that GuC is supported and was selected in modparam, is renamed to wants_guc and a new uses_guc is introduced to represent the case were we're committed to using the GuC. Note that uses_guc does still not imply that the blob is actually loaded on the HW (is_running is the check for that). Also, since we need to have attempted the fetch for the result of uses_guc to be meaningful, we need to make sure we've moved away from INTEL_UC_FIRMWARE_SELECTED. All the GuC changes have been mirrored on the HuC for coherency. v2: split fetch return changes and new macros to their own patches, support HuC only if GuC is wanted, improve "used" state description (Michal) v3: s/wants_huc/uses_huc in uc_init_wopcm Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Fernando Pacheco <fernando.pacheco@intel.com> #v1 Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-6-daniele.ceraolospurio@intel.com
2020-02-20drm/i915/uc: autogenerate uC checker functionsDaniele Ceraolo Spurio
We want to map uC-level checks to GuC/HuC-level ones. The mapping from the uC state to the GuC/HuC one follows the same pattern for all the functions: uc_xxx_guc() -> guc_is_yyy() So we can easily use a macro to autogenerate the functions via macros by passing in the 2 mapped states. v2: Split this change to its own patch (Michal) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-5-daniele.ceraolospurio@intel.com
2020-02-20drm/i915/uc: Update the FW status on injected fetch errorDaniele Ceraolo Spurio
In a follow up patch we will rely on the fact that the status always moves away from "SELECTED" after the fetch is attempted to decide what to do with the GuC. v2: Split this change to its own patch (Michal) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-4-daniele.ceraolospurio@intel.com
2020-02-20drm/i915/guc: Kill USES_GUC_SUBMISSION macroDaniele Ceraolo Spurio
use intel_uc_uses_guc_submission() directly instead, to be consistent in the way we check what we want to do with the GuC. v2: do not go through ctx->vm->gt, use i915->gt instead Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> #v1 Reviewed-by: Andi Shyti <andi.shyti@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-3-daniele.ceraolospurio@intel.com
2020-02-20drm/i915/guc: Kill USES_GUC macroDaniele Ceraolo Spurio
use intel_uc_uses_guc() directly instead, to be consistent in the way we check what we want to do with the GuC. v2: split guc_log_info changes to their own patch (Michal) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-2-daniele.ceraolospurio@intel.com
2020-02-20drm/i915/debugfs: Pass guc_log struct to i915_guc_log_infoDaniele Ceraolo Spurio
The log struct is the only thing the function needs (apart from the seq_file), so we can pass just that instead of the whole dev_priv. v2: Split this change to its own patch (Michal) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-1-daniele.ceraolospurio@intel.com
2020-02-20ARM: dts: dra7-evm: Rename evm_3v3 regulator to vsys_3v3Peter Ujfalusi
On the new schematics it is renamed and the same name is used on other dra7 boards. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-02-20drm/sun4i: tcon: Support LVDS output on Allwinner A20Andrey Lebedev
A20 SoC (found in Cubieboard 2 among others) requires different LVDS set up procedure than A33. Timing controller (tcon) driver only implements sun6i-style procedure, that doesn't work on A20 (sun7i). Signed-off-by: Andrey Lebedev <andrey@lebedev.lt> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20200219180858.4806-6-andrey.lebedev@gmail.com
2020-02-20drm/sun4i: tcon: Separate quirks for tcon0 and tcon1 on A20Andrey Lebedev
Timing controllers on A20 are not equivalent: tcon0 on A20 supports LVDS output and tcon1 does not. Separate the capabilities by introducing independent set of quirks for each of the tcons. Signed-off-by: Andrey Lebedev <andrey@lebedev.lt> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20200219180858.4806-3-andrey.lebedev@gmail.com
2020-02-20dt-bindings: display: sun4i: New compatibles for A20 tconsAndrey Lebedev
Document new compatibles used to differentiate between timing controllers on A20 (sun7i) Signed-off-by: Andrey Lebedev <andrey@lebedev.lt> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20200219180858.4806-5-andrey.lebedev@gmail.com
2020-02-20RDMA/rw: Fix error flow during RDMA context initializationMax Gurtovoy
In case the SGL was mapped for P2P DMA operation, we must unmap it using pci_p2pdma_unmap_sg during the error unwind of rdma_rw_ctx_init() Fixes: 7f73eac3a713 ("PCI/P2PDMA: Introduce pci_p2pdma_unmap_sg()") Link: https://lore.kernel.org/r/20200220100819.41860-1-maxg@mellanox.com Signed-off-by: Max Gurtovoy <maxg@mellanox.com> Reviewed-by: Leon Romanovsky <leonro@mellanox.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2020-02-20kvm/emulate: fix a -Werror=cast-function-typeQian Cai
arch/x86/kvm/emulate.c: In function 'x86_emulate_insn': arch/x86/kvm/emulate.c:5686:22: error: cast between incompatible function types from 'int (*)(struct x86_emulate_ctxt *)' to 'void (*)(struct fastop *)' [-Werror=cast-function-type] rc = fastop(ctxt, (fastop_t)ctxt->execute); Fix it by using an unnamed union of a (*execute) function pointer and a (*fastop) function pointer. Fixes: 3009afc6e39e ("KVM: x86: Use a typedef for fastop functions") Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Qian Cai <cai@lca.pw> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-02-20KVM: x86: fix incorrect comparison in trace eventPaolo Bonzini
The "u" field in the event has three states, -1/0/1. Using u8 however means that comparison with -1 will always fail, so change to signed char. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-02-20drm/sun4i: tcon: Introduce LVDS setup routine settingAndrey Lebedev
Different sunxi flavors require slightly different sequence for enabling LVDS output. This allows to differentiate between them. Signed-off-by: Andrey Lebedev <andrey@lebedev.lt> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20200219180858.4806-2-andrey.lebedev@gmail.com
2020-02-20x86/xen: Distribute switch variables for initializationKees Cook
Variables declared in a switch statement before any case statements cannot be automatically initialized with compiler instrumentation (as they are not part of any execution flow). With GCC's proposed automatic stack variable initialization feature, this triggers a warning (and they don't get initialized). Clang's automatic stack variable initialization (via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also doesn't initialize such variables[1]. Note that these warnings (or silent skipping) happen before the dead-store elimination optimization phase, so even when the automatic initializations are later elided in favor of direct initializations, the warnings remain. To avoid these problems, move such variables into the "case" where they're used or lift them up into the main function body. arch/x86/xen/enlighten_pv.c: In function ‘xen_write_msr_safe’: arch/x86/xen/enlighten_pv.c:904:12: warning: statement will never be executed [-Wswitch-unreachable] 904 | unsigned which; | ^~~~~ [1] https://bugs.llvm.org/show_bug.cgi?id=44916 Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20200220062318.69299-1-keescook@chromium.org Reviewed-by: Juergen Gross <jgross@suse.com> [boris: made @which an 'unsigned int'] Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2020-02-20selftests/rseq: Fix out-of-tree compilationMichael Ellerman
Currently if you build with O=... the rseq tests don't build: $ make O=$PWD/output -C tools/testing/selftests/ TARGETS=rseq make: Entering directory '/linux/tools/testing/selftests' ... make[1]: Entering directory '/linux/tools/testing/selftests/rseq' gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L./ -Wl,-rpath=./ -shared -fPIC rseq.c -lpthread -o /linux/output/rseq/librseq.so gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L./ -Wl,-rpath=./ basic_test.c -lpthread -lrseq -o /linux/output/rseq/basic_test /usr/bin/ld: cannot find -lrseq collect2: error: ld returned 1 exit status This is because the library search path points to the source directory, not the output. We can fix it by changing the library search path to $(OUTPUT). Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2020-02-20selftests: Install settings files to fix TIMEOUT failuresMichael Ellerman
Commit 852c8cbf34d3 ("selftests/kselftest/runner.sh: Add 45 second timeout per test") added a 45 second timeout for tests, and also added a way for tests to customise the timeout via a settings file. For example the ftrace tests take multiple minutes to run, so they were given longer in commit b43e78f65b1d ("tracing/selftests: Turn off timeout setting"). This works when the tests are run from the source tree. However if the tests are installed with "make -C tools/testing/selftests install", the settings files are not copied into the install directory. When the tests are then run from the install directory the longer timeouts are not applied and the tests timeout incorrectly. So add the settings files to TEST_FILES of the appropriate Makefiles to cause the settings files to be installed using the existing install logic. Fixes: 852c8cbf34d3 ("selftests/kselftest/runner.sh: Add 45 second timeout per test") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2020-02-20selftest/lkdtm: Don't pollute 'git status'Christophe Leroy
Commit 46d1a0f03d66 ("selftests/lkdtm: Add tests for LKDTM targets") added generation of lkdtm test scripts. Ignore those generated scripts when performing 'git status' Fixes: 46d1a0f03d66 ("selftests/lkdtm: Add tests for LKDTM targets") Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
generated by cgit (git 2.34.1) at 2025-09-20 20:10:50 +0000