Set the CODEC driver's suspend_bias_off flag rather than manually going to
SND_SOC_BIAS_OFF in suspend and SND_SOC_BIAS_STANDBY in resume. This makes
the code a bit shorter and cleaner.
Since the ASoC core now takes care of setting the bias level to
SND_SOC_BIAS_OFF when removing the CODEC there is no need to do it manually
anymore either.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Since the ASoC core now takes care of setting the bias level to
SND_SOC_BIAS_OFF when removing the CODEC there is no need to do it manually
anymore.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Since the ASoC core now takes care of setting the bias level to
SND_SOC_BIAS_OFF when removing the CODEC there is no need to do it manually
anymore.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Since the ASoC core now takes care of setting the bias level to
SND_SOC_BIAS_OFF when removing the CODEC there is no need to do it manually
anymore.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Set the CODEC driver's suspend_bias_off flag rather than manually going to
SND_SOC_BIAS_OFF in suspend and SND_SOC_BIAS_STANDBY in resume. This makes
the code a bit shorter and cleaner.
Since the ASoC core now takes care of setting the bias level to
SND_SOC_BIAS_OFF when removing the CODEC there is no need to do it manually
anymore either.
The manual transition to SND_SOC_BIAS_STANDBY at the end of CODEC probe()
can also be removed as the core will automatically do this after the CODEC
has been probed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Set the CODEC driver's suspend_bias_off flag rather than manually going to
SND_SOC_BIAS_OFF in suspend and SND_SOC_BIAS_STANDBY in resume. This makes
the code a bit shorter and cleaner.
Since the ASoC core now takes care of setting the bias level to
SND_SOC_BIAS_OFF when removing the CODEC there is no need to do it manually
anymore either.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Set the CODEC driver's suspend_bias_off flag rather than manually going to
SND_SOC_BIAS_OFF in suspend and SND_SOC_BIAS_STANDBY in resume. This makes
the code a bit shorter and cleaner.
Since the ASoC core now takes care of setting the bias level to
SND_SOC_BIAS_OFF when removing the CODEC there is no need to do it manually
anymore either.
The manual transition to SND_SOC_BIAS_STANDBY at the end of CODEC probe()
can also be removed as the core will automatically do this after the CODEC
has been probed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Since the ASoC core now takes care of setting the bias level to
SND_SOC_BIAS_OFF when removing the CODEC there is no need to do it manually
anymore.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Since the ASoC core now takes care of setting the bias level to
SND_SOC_BIAS_OFF when removing the CODEC there is no need to do it manually
anymore.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove the manual transition back to SND_SOC_BIAS_STANDBY in resume. This
is already be automatically handled by the ASoC core.
Since the ASoC core now takes care of setting the bias level to
SND_SOC_BIAS_OFF when removing the CODEC there is no need to do it manually
anymore either.
The manual transition to SND_SOC_BIAS_STANDBY at the end of CODEC probe()
can also be removed as the core will automatically do this after the CODEC
has been probed. While we are at it also remove the unused codec field from
the cq93vc struct so the whole probe function can be removed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
While two of the fields in the cq93vc driver state struct are initialized
none of them are ever acutally read again. So remove the whole struct.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
On Broadwell, the ADSP FW don't support loopback record volume tuning,
so here remove this control.
Signed-off-by: Jie Yang <yang.jie@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The "changed" variable should be set to false at the start.
Fixes: a35daac77a ('ASoC: sigmadsp: Add support for fw v2')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
We must ensure that the clocking configuration is valid as rapidly as possible.
And do software reset before the others registers updates, or the registers
will be reset to the default state.
Signed-off-by: Zidan Wang <b50113@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
In olden times the snd_hda_param_read() function always set "*start_id"
but in 2007 we introduced a new return and it causes uninitialized data
bugs in a couple of the callers: print_codec_info() and
hdmi_parse_codec().
Fixes: e8a7f136f5 ('[ALSA] hda-intel - Improve HD-audio codec probing robustness')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
one fix for PX laptops.
* 'drm-fixes-3.18' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: report disconnected for LVDS/eDP with PX if ddc fails
If ddc fails, presumably the i2c mux (and hopefully the signal
mux) are switched to the other GPU so don't fetch the edid from
the vbios so that the connector reports disconnected.
bug:
https://bugzilla.opensuse.org/show_bug.cgi?id=904417
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
I used some 64 bit instructions when adding the 32 bit getcpu VDSO
function. Fix it.
Fixes: 18ad51dd34 ("powerpc: Add VDSO version of getcpu")
Cc: stable@vger.kernel.org
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
The flag passed to ioda_eeh_phb_reset() should be EEH_RESET_DEACTIVATE,
which is translated to OPAL_DEASSERT_RESET or something else by the
EEH backend accordingly.
The patch replaces OPAL_DEASSERT_RESET with EEH_RESET_DEACTIVATE for
ioda_eeh_phb_reset().
Cc: stable@vger.kernel.org
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Obviously I had wrong format given to the PE state output from
/sys/bus/pci/devices/xxxx/eeh_pe_state with some typoes, which
was introduced by commit 2013add4ce. The patch fixes it up.
Fixes: 2013add4ce ("powerpc/eeh: Show hex prefix for PE state sysfs")
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
On pseries system (LPAR) xmon failed to enter when running in LE mode,
system is hunging. Inititating xmon will lead to such an output on the
console:
SysRq : Entering xmon
cpu 0x15: Vector: 0 at [c0000003f39ffb10]
pc: c00000000007ed7c: sysrq_handle_xmon+0x5c/0x70
lr: c00000000007ed7c: sysrq_handle_xmon+0x5c/0x70
sp: c0000003f39ffc70
msr: 8000000000009033
current = 0xc0000003fafa7180
paca = 0xc000000007d75e80 softe: 0 irq_happened: 0x01
pid = 14617, comm = bash
Bad kernel stack pointer fafb4b0 at eca7cc4
cpu 0x15: Vector: 300 (Data Access) at [c000000007f07d40]
pc: 000000000eca7cc4
lr: 000000000eca7c44
sp: fafb4b0
msr: 8000000000001000
dar: 10000000
dsisr: 42000000
current = 0xc0000003fafa7180
paca = 0xc000000007d75e80 softe: 0 irq_happened: 0x01
pid = 14617, comm = bash
cpu 0x15: Exception 300 (Data Access) in xmon, returning to main loop
xmon: WARNING: bad recursive fault on cpu 0x15
The root cause is that xmon is calling RTAS to turn off the surveillance
when entering xmon, and RTAS is requiring big endian parameters.
This patch is byte swapping the RTAS arguments when running in LE mode.
Cc: stable@vger.kernel.org
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
The current HMI event structure is an ABI and carries a version field to
accommodate future changes without affecting/rearranging current structure
members that are valid for previous versions.
The current version check "if (hmi_evt->version != OpalHMIEvt_V1)"
doesn't accomodate the fact that the version number may change in
future.
If firmware starts returning an HMI event with version > 1, this check
will fail and no HMI information will be printed on older kernels.
This patch fixes this issue.
Cc: stable@vger.kernel.org # 3.17+
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
[mpe: Reword changelog]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
In commit fadbe0cd52 entitled "staging:
rtl8188eu:Remove rtw_zmalloc(), wrapper for kzalloc()", the author failed
to note that the original code in the wrapper tested whether the caller
could sleep, and set the flags argument to kzalloc() appropriately.
After the patch, GFP_KERNEL is used unconditionally. Unfortunately, several
of the routines may be entered from an interrupt routine and generate
a BUG splat for every such call. Routine rtw_sitesurvey_cmd() is used in the
example below:
BUG: sleeping function called from invalid context at mm/slub.c:1240
in_atomic(): 1, irqs_disabled(): 0, pid: 756, name: wpa_supplicant
INFO: lockdep is turned off.
CPU: 2 PID: 756 Comm: wpa_supplicant Tainted: G WC O 3.18.0-rc4+ #34
Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS Version 4.20 04/17/2014
ffffc90005557000 ffff880216fafaa8 ffffffff816b0bbf 0000000000000000
ffff8800c3b58000 ffff880216fafac8 ffffffff8107af77 0000000000000001
0000000000000010 ffff880216fafb18 ffffffff811b06ce 0000000000000000
Call Trace:
[<ffffffff816b0bbf>] dump_stack+0x4e/0x71
[<ffffffff8107af77>] __might_sleep+0xf7/0x120
[<ffffffff811b06ce>] kmem_cache_alloc_trace+0x4e/0x1f0
[<ffffffffa0888226>] ? rtw_sitesurvey_cmd+0x56/0x2a0 [r8188eu]
[<ffffffffa0888226>] rtw_sitesurvey_cmd+0x56/0x2a0 [r8188eu]
[<ffffffffa088f00d>] rtw_do_join+0x22d/0x370 [r8188eu]
[<ffffffffa088f6e8>] rtw_set_802_11_ssid+0x218/0x3d0 [r8188eu]
[<ffffffffa08c3ca5>] rtw_wx_set_essid+0x1e5/0x410 [r8188eu]
[<ffffffffa08c3ac0>] ? rtw_wx_get_rate+0x50/0x50 [r8188eu]
[<ffffffff816938f1>] ioctl_standard_iw_point+0x151/0x3f0
[<ffffffff81693d52>] ioctl_standard_call+0xb2/0xe0
[<ffffffff81597df7>] ? rtnl_lock+0x17/0x20
[<ffffffff816945a0>] ? iw_handler_get_private+0x70/0x70
[<ffffffff81693ca0>] ? call_commit_handler+0x40/0x40
[<ffffffff81693256>] wireless_process_ioctl+0x176/0x1c0
[<ffffffff81693e79>] wext_handle_ioctl+0x69/0xc0
[<ffffffff8159fe79>] dev_ioctl+0x309/0x5e0
[<ffffffff810be9c7>] ? call_rcu+0x17/0x20
[<ffffffff8156a472>] sock_ioctl+0x142/0x2e0
[<ffffffff811e0c70>] do_vfs_ioctl+0x300/0x520
[<ffffffff81101514>] ? __audit_syscall_entry+0xb4/0x110
[<ffffffff81101514>] ? __audit_syscall_entry+0xb4/0x110
[<ffffffff810102bc>] ? do_audit_syscall_entry+0x6c/0x70
[<ffffffff811e0f11>] SyS_ioctl+0x81/0xa0
[<ffffffff816ba1d2>] system_call_fastpath+0x12/0x17
Additional routines that generate this BUG are rtw_joinbss_cmd(),
rtw_dynamic_chk_wk_cmd(), rtw_lps_ctrl_wk_cmd(), rtw_rpt_timer_cfg_cmd(),
rtw_ps_cmd(), report_survey_event(), report_join_res(), survey_timer_hdl(),
and rtw_check_bcn_info().
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: navin patidar <navin.patidar@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
John W. Linville says:
====================
pull request: wireless 2014-11-26
Please pull this little batch of fixes intended for the 3.18 stream...
For the iwlwifi one, Emmanuel says:
"Not all the firmware know how to handle the HOT_SPOT_CMD.
Make sure that the firmware will know this command before
sending it. This avoids a firmware crash."
Along with that, Larry sends a pair of rtlwifi fixes to address some
discrepancies from moving drivers out of staging. Larry says:
"These two patches are needed to fix a regression introduced when
driver rtl8821ae was moved from staging to the regular wireless tree."
Please let me know if there are problems!
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
TCP timestamping introduced MSG_ERRQUEUE handling for TCP sockets.
If the socket is of family AF_INET6, call ipv6_recv_error instead
of ip_recv_error.
This change is more complex than a single branch due to the loadable
ipv6 module. It reuses a pre-existing indirect function call from
ping. The ping code is safe to call, because it is part of the core
ipv6 module and always present when AF_INET6 sockets are active.
Fixes: 4ed2d765 (net-timestamp: TCP timestamping)
Signed-off-by: Willem de Bruijn <willemb@google.com>
----
It may also be worthwhile to add WARN_ON_ONCE(sk->family == AF_INET6)
to ip_recv_error.
Signed-off-by: David S. Miller <davem@davemloft.net>
Thomas Graf says:
====================
bridge: Fix missing Netlink message validations
Adds various missing length checks in the bridging code for Netlink
messages and corresponding attributes provided by user space.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Only search for IFLA_EXT_MASK if the message actually carries a
ifinfomsg header and validate minimal length requirements for
IFLA_EXT_MASK.
Fixes: 6cbdceeb ("bridge: Dump vlan information from a bridge port")
Cc: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fixes: c2d3babf ("bridge: implement multicast fast leave")
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
ndo_bridge_setlink() is currently only called on the slave if
IFLA_AF_SPEC is set but this is a very fragile assumption and may
change in the future.
Cc: Ajit Khaparde <ajit.khaparde@emulex.com>
Cc: John Fastabend <john.r.fastabend@intel.com>
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Payload is currently accessed blindly and may exceed valid message
boundaries.
Fixes: a77dcb8c8 ("be2net: set and query VEB/VEPA mode of the PF interface")
Fixes: 815cccbf1 ("ixgbe: add setlink, getlink support to ixgbe and ixgbevf")
Cc: Ajit Khaparde <ajit.khaparde@emulex.com>
Cc: John Fastabend <john.r.fastabend@intel.com>
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: John Fastabend <john.r.fastabend@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Payload is currently accessed blindly and may exceed valid message
boundaries.
Fixes: 407af3299 ("bridge: Add netlink interface to configure vlans on bridge ports")
Cc: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
affects nothing but ARM.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAABAgAGBQJUddkVAAoJEL/70l94x66D0awIAK+Zy4CnoLdtEpWFZsuoK2YO
TXOUg3z0WNR4sD/dFMlh1jLxiBG5f/JkDHBBecSZTi+L9PcU15mrAeS+k1F4rDkw
0GNwRQas+WDElD9rRnqIeBF8A83BmunsVnCsOmn3w+xeXuB8L0HBy6Pgh/wnfHbQ
+G4gODi0JMDVcvEujN2NNBf60LcM/G3U0VIFXHHGblEIOUtNCUy9mnGRBCg75vwb
CORpMC+8JV7gFF7jVnqurYc2SyN9a6fzun1evIQJWlFN+ohU8XjkVn4JsrsHpv+E
6Eqy1wgEWLW1TQhApsh5EYkIRTvvGLgdKm5KCBu15xUw/i3OTOc1BQ0VrSEPs/Y=
=rEqk
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull kvm fixes from Paolo Bonzini:
"Last minute KVM/ARM fixes; even the generic change actually affects
nothing but ARM"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
kvm: fix kvm_is_mmio_pfn() and rename to kvm_is_reserved_pfn()
arm/arm64: kvm: drop inappropriate use of kvm_is_mmio_pfn()
arm/arm64: KVM: vgic: Fix error code in kvm_vgic_create()
arm64: KVM: Handle traps of ICC_SRE_EL1 as RAZ/WI
arm64: KVM: fix unmapping with 48-bit VAs
Most of these are fairly standard little fixes, a bmc150 and bmg160 patch
is to make an ABI change to indicated a specific axis in an event rather
than the generic option in the original drivers. As both of these drivers
are new in this cycle it would be ideal to push this minor change through
even though it isn't strictly a fix. A couple of other 'fixes' change
defaults for some settings on these new drivers to more intuitive calues.
Looks like some useful feedback has been coming in for this driver
since it was applied.
* IIO_EVENT_CODE_EXTRACT_DIR bit mask was wrong and has been for a while
0xCF clearly doesn't give a contiguous bitmask.
* kxcjk-1013 range setting was failing to mask out the previous value
in the register and hence was 'enable only'.
* men_z188 device id table wasn't null terminated.
* bmg160 and bmc150 both failed to correctly handling an error in mode
setting.
* bmg160 and bmc150 both had a bug in setting the event direction in the
event spec (leads to an attribute name being incorrect)
* bmg160 defaulted to an open drain output for the interrupt - as a default
this obviously only works with some interrupt chips - hence change the
default to push-pull (note this is a new driver so we aren't going to
cause any regressions with this change).
* bmc150 had an unintuitive default for the rate of change (motion detector)
so change it to 0 (new driver so change of default won't cause any
regressions).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJUaRGrAAoJEFSFNJnE9BaIrWgP/jdxYsA7l7gAamjkK6Dm+jmR
FIDaD1eJ0ZMRS43guIwaGJ90OC2Mxc7xIAgbE3xurI0r/73YagTwWtUwzUOGRnE1
kqRKyo8NEu3+BZtasoigEZfm9pHmsmkdD+lQLAnLlDeVFhYpTbsr/j9qeMD7L8CN
b+hTwQBsObnpJ/tN61KLSjlx57D8c47ghCgqEaGqXrfR4r/wMItMN6cB1xbM4yU4
tHJQBBbOv03vZI5oaxJ3+Q4aBGf4TdrL3z/P/vrmMUyyQrmbS6jCBjUlmjcylVSn
Yz2mr5oPyRgRRzH/KcMT/S+i8BELxBuC5nURBAkO35YqHhXvZENgg29edEWX4s4c
KOTC+FgbEEPEu5wcUl5NuFPP3D8NNuOxDl677bLz9I6ufhwFLCNtyN6vGsqAMPA+
s/eviz/W8u2L90/+ryiEV+UESXjqLszWU7xpfdheo4Z6jokpWi9ZT65m11Z+aJ79
QldzeniUxR9ycH6O6z9GxkdhXV79OACjkvoNZgh33MfmuX7jLMIodWfrI/Xn2+Pb
N0hpWzcADcd2KfXoXRvuN8t3Wgz09T7CuodOSBsAOjhvkUiufj+iOhwU96rNnNzl
ZWtYAbRr+DmKks+bzoobyCypaH/0hPuC/YUSBUALlg80P8ozGiIs+E1phiZze+rB
fHyT8lUFg4a0syWOfx8s
=IPMl
-----END PGP SIGNATURE-----
Merge tag 'iio-fixes-for-3.18c' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
Third set of IIO fixes for the 3.18 cycle.
Most of these are fairly standard little fixes, a bmc150 and bmg160 patch
is to make an ABI change to indicated a specific axis in an event rather
than the generic option in the original drivers. As both of these drivers
are new in this cycle it would be ideal to push this minor change through
even though it isn't strictly a fix. A couple of other 'fixes' change
defaults for some settings on these new drivers to more intuitive calues.
Looks like some useful feedback has been coming in for this driver
since it was applied.
* IIO_EVENT_CODE_EXTRACT_DIR bit mask was wrong and has been for a while
0xCF clearly doesn't give a contiguous bitmask.
* kxcjk-1013 range setting was failing to mask out the previous value
in the register and hence was 'enable only'.
* men_z188 device id table wasn't null terminated.
* bmg160 and bmc150 both failed to correctly handling an error in mode
setting.
* bmg160 and bmc150 both had a bug in setting the event direction in the
event spec (leads to an attribute name being incorrect)
* bmg160 defaulted to an open drain output for the interrupt - as a default
this obviously only works with some interrupt chips - hence change the
default to push-pull (note this is a new driver so we aren't going to
cause any regressions with this change).
* bmc150 had an unintuitive default for the rate of change (motion detector)
so change it to 0 (new driver so change of default won't cause any
regressions).
The commit 3b57de958e brought the support for a different amount of
the filter bins, but didn't update the platform driver that without
CONFIG_OF.
Fixes: 3b57de958e (net: stmmac: Support devicetree configs for mcast
and ucast filter entries)
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some VF drivers use the upper byte of "param1" (the qp count field)
in mlx4_qp_reserve_range() to pass flags which are used to optimize
the range allocation.
Under the current code, if any of these flags are set, the 32-bit
count field yields a count greater than 2^24, which is out of range,
and this VF fails.
As these flags represent a "best-effort" allocation hint anyway, they may
safely be ignored. Therefore, the PF driver may simply mask out the bits.
Fixes: c82e9aa0a8 "mlx4_core: resource tracking for HCA resources used by guests"
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Florian Fainelli says:
====================
net: dsa: bcm_sf2: misc bugfixes
This patch series contains two bug fixes:
- first patch fixes an issue on the error path of the driver where we could
have left some of our registers mapped
- second patch enforces the use of a software reset of the switch to guarantee
the HW is in a consistent state prior to software initialization
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Our boot agent may have left the switch in an certain configuration
state, make sure we issue a software reset prior to configuring the
switch in order to ensure the HW is in a consistent state, in particular
transmit queues and internal buffers.
Fixes: 246d7f773c ("net: dsa: add Broadcom SF2 switch driver")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In case we fail to ioremap() one of our registers, we would be leaking
existing mappings, unwind those accordingly on errors.
Fixes: 246d7f773c ("net: dsa: add Broadcom SF2 switch driver")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Adding machine driver to instantiate I2S based realtek's ALC5631
sound card on Arndale board.
There are other variants of Audio Daughter Cards for Arndale
Board for which support already exists but there is no support for
Realtek's alc5631 codec hence support for ALC5631 based machine
driver is being added.
This patch also documents the device tree binding for the Arndale
board based machine driver.
Signed-off-by: Claude Youn <claude.youn@gmail.com>
Signed-off-by: Krishna Mohan Dani <krishna.md@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This reverts commit 85c8555ff0 ("KVM: check for !is_zero_pfn() in
kvm_is_mmio_pfn()") and renames the function to kvm_is_reserved_pfn.
The problem being addressed by the patch above was that some ARM code
based the memory mapping attributes of a pfn on the return value of
kvm_is_mmio_pfn(), whose name indeed suggests that such pfns should
be mapped as device memory.
However, kvm_is_mmio_pfn() doesn't do quite what it says on the tin,
and the existing non-ARM users were already using it in a way which
suggests that its name should probably have been 'kvm_is_reserved_pfn'
from the beginning, e.g., whether or not to call get_page/put_page on
it etc. This means that returning false for the zero page is a mistake
and the patch above should be reverted.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Instead of using kvm_is_mmio_pfn() to decide whether a host region
should be stage 2 mapped with device attributes, add a new static
function kvm_is_device_pfn() that disregards RAM pages with the
reserved bit set, as those should usually not be mapped as device
memory.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
If we detect another vCPU is running we just exit and return 0 as if we
succesfully created the VGIC, but the VGIC wouldn't actual be created.
This shouldn't break in-kernel behavior because the kernel will not
observe the failed the attempt to create the VGIC, but userspace could
be rightfully confused.
Cc: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When running on a system with a GICv3, we currenly don't allow the guest
to access the system register interface of the GICv3. We do this by
clearing the ICC_SRE_EL2.Enable, which causes all guest accesses to
ICC_SRE_EL1 to trap to EL2 and causes all guest accesses to other ICC_
registers to cause an undefined exception in the guest.
However, we currently don't handle the trap of guest accesses to
ICC_SRE_EL1 and will spill out a warning. The trap just needs to handle
the access as RAZ/WI, and a guest that tries to prod this register and
set ICC_SRE_EL1.SRE=1, must read back the value (which Linux already
does) to see if it succeeded, and will thus observe that ICC_SRE_EL1.SRE
was not set.
Add the simple trap handler in the sorted table of the system registers.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
[ardb: added cp15 handling]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
memblock_is_region_reserved() returns true in the case of a partial
overlap, meaning that the current code fails to reserve the
non-overlapping portion.
This call was introduced as part of d1552ce449 "of/fdt: move
memreserve and dtb memory reservations into core" which went into
v3.16.
I observed this causing a Midway system with a buggy fdt (the header
declares itself to be larger than it really is) failing to boot
because the over-inflated size of the fdt was causing it to seem to
run into the swapper_pg_dir region, meaning the DT wasn't reserved.
The symptoms were failing to find an disks or network and failing to
boot.
However given the ambiguity of whether things like the initrd are
covered by /memreserve/ and similar I think it is best to also
register the region rather than just ignoring it.
Since memblock_reserve() handles overlaps just fine lets just warn and
carry on.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: stable@vger.kernel.org # v3.16+
Currently we just make sure vdd is off before suspending, but we don't
cancel the vdd off work. The work wil not touch vdd if
want_panel_vdd==false so in theory this is fine.
In the past that was perfectly fine since the vdd off work didn't do
anything when want_panel_vdd==false, so even if the work would have been
run during system resume before i915 has resumed, nothing would happen.
However since pps_lock() will now grab the power domain references before
it can check want_panel_vdd, we may end up toggling the power wells on/off
already before the driver has resumed. That is not really acceptable, so
cancel the vdd off work when suspending the encoder.
The problem appeared when pps_lock() was introduced in:
commit 773538e860
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Thu Sep 4 14:54:56 2014 +0300
drm/i915: Reset power sequencer pipe tracking when disp2d is off
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
