We intended || here instead of &&. The original code potentially leads
to a NULL dereference.
Fixes: 2889099eb8 ('ASoC: hdac_hdmi: Register chmap controls and ops')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewd-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Tested-by: Sachin Mokashi <sachinx.mokashi@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Pretty much all of these hasn't seen any action singe 2008 at the very
least. Barring the occasional buildfix and DRM-wide refactoring of
course.
Note: some distributions have stopped shipping their userspace
counterparts for a while. Although some still do.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Almost exclusively done by Dave Airlie.
Explicitly list him as a maintainer and classify them as "Odd Fixes" as I
doubt he's got much time for them these days.
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1461279842-28695-14-git-send-email-emil.l.velikov@gmail.com
Thomas is one of the original authors of the driver, with recent
contributions from Sinclair and Brian.
v2: Add Sinclair as maintainer. Add Sinclair+Thomas's tree, use
Supported as status.
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Brian Paul <brianp@vmware.com>
Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1462230939-26389-1-git-send-email-emil.l.velikov@gmail.com
Rob and Archit are the main developers behind the driver.
v2: Removing Archit for now, correcting the status and adding
linux-arm-msm@ mailing list.
Cc: Rob Clark <robdclark@gmail.com>
Cc: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1462230888-26319-1-git-send-email-emil.l.velikov@gmail.com
Ben has been the maintainer of the driver even before it got included in
the kernel.
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1461279842-28695-11-git-send-email-emil.l.velikov@gmail.com
Without this there was a double free of the metadata,
which ended up freeing the fd table for me here, and taking
out the machine more often than not.
I reproduced with X.org + modesetting DDX + latest llvm/mesa,
also required using dri3.
Cc: stable@vger.kernel.org
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Add driver for the PCI Express Downstream Port Containment extended
capability. DPC is an optional capability to contain uncorrectable errors
below a port.
For more information on DPC, please see PCI Express Base Specification
Revision 4, section 7.31, or view the PCI-SIG DPC ECN here:
https://pcisig.com/sites/default/files/specification_documents/ECN_DPC_2012-02-09_finalized.pdf
When a DPC event is triggered, the hardware disables downstream links, so
the DPC driver schedules removal for all devices below this port. This may
happen concurrently with a PCIe hotplug driver if enabled. When all
downstream devices are removed and the link state transitions to disabled,
the DPC driver clears the DPC status and interrupt bits so the link may
retrain for a newly connected device.
[bhelgaas: clear (not set) DPC_CTL bits on remove, whitespace cleanup]
Signed-off-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Lukas Wunner <lukas@wunner.de>
Add the Downstream Port Containment (PCIE_PORT_SERVICE_DPC) portdrv service
type, available if the device has the DPC extended capability.
[bhelgaas: split to separate patch, changelog]
Signed-off-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
blk_account_io_start does not need to be wrapped with blk_do_io_stat
ais it already checks for that condition.
Signed-off-by: Michael Callahan <michaelcallahan@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Guest should only trust data to be valid when version haven't changed
before and after reads of steal time. Besides not changing, it has to
be an even number. Hypervisor may write an odd number to version field
to indicate that an update is in progress.
kvm_steal_clock() in guest has already done the read side, make write
side in hypervisor more robust by following the above rule.
Reviewed-by: Wincy Van <fanwenyi0529@gmail.com>
Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
This reverts commit ded9db380d.
Thierry Reding writes:
This causes a boot regression on at least one board, caused by
one of the drivers looking at driver data to check whether or
not the driver has properly loaded. If the code encounters a
non-NULL pointer it tries to dereference it, but because it's
already been freed there is no memory backing it and things
crash.
I don't think keeping stale pointers around is a good idea. The
whole point of setting this to NULL in the core is so that probe
failures result in the same starting conditions no matter what.
Can we please get this reverted?
Reported-by: Thierry Reding <thierry.reding@gmail.com>
Cc: Yi Zhang <yizhang_hust@163.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The names of port service devices previously used one nibble to encode the
port type and another nibble to encode the service type. We're about to
add a fifth service type, so change device names to use one *byte* to
encode the service type.
For example, a hotplug port service on a downstream bridge was previously
called "pcie24" and is now called "pcie204". The "2" encodes the device
type (PCI_EXP_TYPE_DOWNSTREAM - 4), and the "4" (now "04") encodes the
service (PCIE_PORT_SERVICE_HP).
Based on Lukas Wunner's patch:
b688d6e487
[bhelgaas: split to separate patch, expand changelog]
Based-on-patch-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The MVME16x RTC driver doesn't use any MC146818-specific definitions,
hence include the generic <linux/rtc.h> instead of
<linux/mc146818rtc.h>.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
The BVME6000 RTC driver doesn't use any MC146818-specific definitions,
hence include the generic <linux/rtc.h> instead of
<linux/mc146818rtc.h>.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
While browsing BSpec I bumped into a note saying we need to tune these
values based on actual measurements done after initial enabling. I've
checked that it indeed improves things on BXT. I haven't checked this on
CHV, but here it is if someone wants to give it a go.
v2:
- Add note about the discrepancy wrt. to the spec in the formula
calculating the credit encodings. (Mika, Ville)
- Move the WA comment to the new function. (Ville)
v3:
- Keep the comment about the SQC WA in the caller. (Ville)
CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
CC: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1462280061-1457-4-git-send-email-imre.deak@intel.com
No need for hard-coding the register value, the corresponding fields are
defined properly in BSpec.
No functional change.
v2:
- Rebased on BXT L3 SQC tuning patch merged meanwhile.
CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Link: http://patchwork.freedesktop.org/patch/msgid/1462280061-1457-3-git-send-email-imre.deak@intel.com
The driver for Micrel PHYs is required for the Apalis iMX6 module
plugged into a Ixora carrier board featuring an on-module Micrel
KSZ9031 Gigabit PHY.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The GPIO-based bitbanging I2C driver is required to make HDMI work on
the Apalis iMX6 module plugged into a Ixora carrier board featuring a
DDC channel to read a screen's EDID being hooked up to regular GPIOs.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
imx6ul-14x14-evk has a wm8960 codec connected via SAI2 port.
Add support for it.
Thanks to Petr Kulhavy <brain@jikos.cz> for the hint on initializing
the PLL4 frequency to get a correct MCLK.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The following build warnings are seen when building with 'W=1' option:
Warning (unit_address_vs_reg): Node /soc/aips-bus@02000000/anatop@020c8000/regulator-1p1@110 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /soc/aips-bus@02000000/anatop@020c8000/regulator-3p0@120 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /soc/aips-bus@02000000/anatop@020c8000/regulator-2p5@130 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /soc/aips-bus@02000000/anatop@020c8000/regulator-vddcore@140 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /soc/aips-bus@02000000/anatop@020c8000/regulator-vddpu@140 has a unit name, but no reg property
Warning (unit_address_vs_reg): Node /soc/aips-bus@02000000/anatop@020c8000/regulator-vddsoc@140 has a unit name, but no reg property
Fix them by removing the unneeded unit-addresses.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
When I was writing an atomic wrapper for rmfb, I ran into the
following backtrace from lockdep:
=============================================
[ INFO: possible recursive locking detected ]
4.5.0-patser+ #4696 Tainted: G U
---------------------------------------------
kworker/2:2/2608 is trying to acquire lock:
(crtc_ww_class_mutex){+.+.+.}, at: [<ffffffffc00c9ddc>] drm_modeset_lock+0x7c/0x120 [drm]
but task is already holding lock:
(crtc_ww_class_mutex){+.+.+.}, at: [<ffffffffc00c98cd>] modeset_backoff+0x8d/0x220 [drm]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(crtc_ww_class_mutex);
lock(crtc_ww_class_mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by kworker/2:2/2608:
#0: ("events"){.+.+.+}, at: [<ffffffff810a5eea>] process_one_work+0x15a/0x6c0
#1: ((&arg.work)){+.+.+.}, at: [<ffffffff810a5eea>] process_one_work+0x15a/0x6c0
#2: (crtc_ww_class_acquire){+.+.+.}, at: [<ffffffffc004532a>] drm_atomic_helper_remove_fb+0x4a/0x1d0 [drm_kms_helper]
#3: (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffffc00c98cd>] modeset_backoff+0x8d/0x220 [drm]
While lockdep probably catches this bug when it happens, it's better
to explicitly warn when state->acquire_ctx is not set.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1462266751-29123-1-git-send-email-maarten.lankhorst@linux.intel.com
The clock parent of the AHB root clock when using mux option 1
is the SYS PLL 270MHz clock. This is specified in Table 5-11
Clock Root Table of the i.MX 7Dual Applications Processor
Reference Manual.
While it could be a documentation error, the 270MHz parent is
also mentioned in the boot ROM configuration in Table 6-28: The
clock is by default at 135MHz due to a POST_PODF value of 1
(=> divider of 2).
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
checkpatch requires that declarations be separated from code by a blank
line. Add one for readability and to silence the warning.
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The PWM framework has clarified the concept of reference PWM config (the
platform dependent config retrieved from the DT or the PWM lookup table)
and real PWM state.
Use pwm_get_args() when the PWM user wants to retrieve this reference
config and not the current state.
This is part of the rework allowing the PWM framework to support
hardware readout and expose real PWM state even when the PWM has just
been requested (before the user calls pwm_config/enable/disable()).
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Currently the PWM core mixes the current PWM state with the per-platform
reference config (specified through the PWM lookup table, DT definition
or directly hardcoded in PWM drivers).
Create a struct pwm_args to store this reference configuration, so that
PWM users can differentiate between the current and reference
configurations.
Patch all places where pwm->args should be initialized. We keep the
pwm_set_polarity/period() calls until all PWM users are patched to use
pwm_args instead of pwm_get_period/polarity().
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
[thierry.reding@gmail.com: reword kerneldoc comments]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
The only call of arch_timer_get_timecounter (in KVM) has been removed.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Currently, the firmware tables are parsed 2 times: once in the GIC
drivers, the other time when initializing the vGIC. It means code
duplication and make more tedious to add the support for another
firmware table (like ACPI).
Use the recently introduced helper gic_get_kvm_info() to get
information about the virtual GIC.
With this change, the virtual GIC becomes agnostic to the firmware
table and KVM will be able to initialize the vGIC on ACPI.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
The firmware table is currently parsed by the virtual timer code in
order to retrieve the virtual timer interrupt. However, this is already
done by the arch timer driver.
To avoid code duplication, use the newly function arch_timer_get_kvm_info()
which return all the information required by the virtual timer code.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Fill up the recently introduced gic_kvm_info with the hardware
information used for virtualization.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
The ACPI code requires to use global variables in order to collect
information from the tables.
To make clear those variables are ACPI specific, gather all of them in a
single structure.
Furthermore, even if some of the variables are not marked with
__initdata, they are all only used during the initialization. Therefore,
the new variable, which hold the structure, can be marked with
__initdata.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Currently, most of the pr_* messages in the GICv3 driver don't have a
prefix. Add one to make clear where the messages come from.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
For now, the firmware tables are parsed 2 times: once in the GIC
drivers, the other timer when initializing the vGIC. It means code
duplication and make more tedious to add the support for another
firmware table (like ACPI).
Introduce a new structure and set of helpers to get/set the virtual GIC
information. Also fill up the structure for GICv2.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
The ACPI code requires to use global variables in order to collect
information from the tables.
For now, a single global variable is used, but more will be added in a
subsequent patch. To make clear they are ACPI specific, gather all the
information in a single structure.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Acked-by: Christofer Dall <christoffer.dall@linaro.org>
Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Currently, the firmware table is parsed by the virtual timer code in
order to retrieve the virtual timer interrupt. However, this is already
done by the arch timer driver.
To avoid code duplication, extend arch_timer_kvm_info to get the virtual
IRQ.
Note that the KVM code will be modified in a subsequent patch.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Introduce a structure which are filled up by the arch timer driver and
used by the virtual timer in KVM.
The first member of this structure will be the timecounter. More members
will be added later.
A stub for the new helper isn't introduced because KVM requires the arch
timer for both ARM64 and ARM32.
The function arch_timer_get_timecounter is kept for the time being and
will be dropped in a subsequent patch.
Signed-off-by: Julien Grall <julien.grall@arm.com>
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
