| Age | Commit message (Collapse) | Author |
|---|
|
As previously reported, some userspace applications depend on bogomips
showed by /proc/cpuinfo. Although there is much less legacy impact on
aarch64 than arm, it does break libvirt.
This patch reverts commit 326b16db9f69 ("arm64: delay: don't bother
reporting bogomips in /proc/cpuinfo"), but with some tweak due to
context change and without the pr_info().
Fixes: 326b16db9f69 ("arm64: delay: don't bother reporting bogomips in /proc/cpuinfo")
Signed-off-by: Yang Shi <yang.shi@linaro.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: <stable@vger.kernel.org> # 3.12+
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
Set substream player private data.
substream player private data is used in uni_player_irq_handler to lock,
stop & unlock the stream when interrupt indicates underflow/overflow.
If not set, then segmentation fault occurs.
Signed-off-by: Moise Gergaud <moise.gergaud@st.com>
Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
"st," prefix has been added for ST proprietary DT properties.
Signed-off-by: Moise Gergaud <moise.gergaud@st.com>
Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Signed-off-by: Moise Gergaud <moise.gergaud@st.com>
Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
On some host errors storvsc module tries to remove sdev by scheduling a job
which does the following:
sdev = scsi_device_lookup(wrk->host, 0, 0, wrk->lun);
if (sdev) {
scsi_remove_device(sdev);
scsi_device_put(sdev);
}
While this code seems correct the following crash is observed:
general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
RIP: 0010:[<ffffffff81169979>] [<ffffffff81169979>] bdi_destroy+0x39/0x220
...
[<ffffffff814aecdc>] ? _raw_spin_unlock_irq+0x2c/0x40
[<ffffffff8127b7db>] blk_cleanup_queue+0x17b/0x270
[<ffffffffa00b54c4>] __scsi_remove_device+0x54/0xd0 [scsi_mod]
[<ffffffffa00b556b>] scsi_remove_device+0x2b/0x40 [scsi_mod]
[<ffffffffa00ec47d>] storvsc_remove_lun+0x3d/0x60 [hv_storvsc]
[<ffffffff81080791>] process_one_work+0x1b1/0x530
...
The problem comes with the fact that many such jobs (for the same device)
are being scheduled simultaneously. While scsi_remove_device() uses
shost->scan_mutex and scsi_device_lookup() will fail for a device in
SDEV_DEL state there is no protection against someone who did
scsi_device_lookup() before we actually entered __scsi_remove_device(). So
the whole scenario looks like that: two callers do simultaneous (or
preemption happens) calls to scsi_device_lookup() ant these calls succeed
for both of them, after that they try doing scsi_remove_device().
shost->scan_mutex only serializes their calls to __scsi_remove_device()
and we end up doing the cleanup path twice.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
If cdev_add() returns an error, the code calls
cdev_del() passing the STm->cdevs[rew] pointer as parameter;
the problem is that the pointer has not been initialized yet.
This patch fixes the problem by moving the STm->cdevs[rew] pointer
initialization before the call to cdev_add().
It also sets STm->devs[rew] and STm->cdevs[rew] to NULL in
case of failure.
Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
Some host adapters (e.g. Hyper-V storvsc) are known for not respecting
the SPC-2/3/4 requirement for 'INQUIRY data (see table ...) shall
contain at least 36 bytes'. As a result we get tons on 'scsi 0:7:1:1:
scsi scan: INQUIRY result too short (5), using 36' messages on
console. This can be problematic for slow consoles. Introduce
short_inquiry flag in struct Scsi_Host to print the message once per
host.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into kvm-master
KVM: s390: Fixes for 4.4
1. disallow changing the SIMD mode when CPUs have been created.
it allowed userspace to corrupt kernel memory
2. Fix vCPU lookup. Until now the vCPU number equals the vCPU id. Some
kernel code places relied on that. This might
a: cause guest failures
b: allow userspace to corrupt kernel memory
3. Fencing of the PFMF instruction should use the guest facilities
and not the host facilities.
|
|
For making the speakers on Acer Aspire One Cloudbook 14 to work, we
need the as same quirk as for another Chromebook. This patch adds the
corresponding fixup entry.
Reported-by: Patrick <epictetus@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
For SKL, only the HDMI codec is in the display power well while the
HD-A controller isn't. So the codec flag 'link_power_control' is
set to request/release the display power via bus link_power ops.
For BXT, the power well design is the same as SKL, so the patch
should be applied to BXT too.
Signed-off-by: Lu, Han <han.lu@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Add HD Audio Device PCI ID for the Intel Broxton platform.
It is an HDA Intel PCH controller.
Signed-off-by: Lu, Han <han.lu@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The scpi_clock driver can be built-in when CONFIG_COMPILE_TEST
is set even when ARM_SCPI_PROTOCOL is a loadable module, and
that results in a link error:
drivers/built-in.o: In function `scpi_clocks_probe':
(.text+0x14453c): undefined reference to `get_scpi_ops'
Using #if IS_REACHABLE() around the get_scpi_ops() declaration
makes it build successfully in this case for compile-testing,
but the effect is the same as when ARM_SCPI_PROTOCOL is
disabled, as the code will not be used.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Punit Agrawal <punit.agrawal@arm.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91 into fixes
Merge "First fixes for 4.4" from Nicolas Ferre:
- removal of a useless defconfig option
- removal of some legacy DT pieces
- use of the proper watchdog compatible string
- addition of some sama5d2 Xplained nodes now that the MFD include is in place
- update of the MAINTAINERS entries for some Atmel drivers
* tag 'at91-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91:
MAINTAINERS: Atmel drivers: change NAND and ISI entries
ARM: at91/dt: sama5d2 Xplained: add several devices
ARM: at91/dt: remove bootargs
ARM: at91/dt: remove leftovers clock definition
ARM: at91/dt: replace gpio-key,wakeup with wakeup-source property
ARM: at91/dt: sama5d4: change watchdog compatible
ARM: at91/defconfig: remove CONFIG_SSB from Atmel defconfigs
|
|
The newly added zx power domain code causes build errors in
some configurations:
warning: (PM_RMOBILE && SOC_ZX296702) selects PM_GENERIC_DOMAINS which has unmet direct dependencies (PM)
warning: (ARCH_EXYNOS) selects EXYNOS_THERMAL which has unmet direct dependencies (THERMAL && (ARCH_EXYNOS || COMPILE_TEST) && THERMAL_OF)
power/domain.c: In function 'genpd_queue_power_off_work':
power/domain.c:192:13: error: 'pm_wq' undeclared (first use in this function)
queue_work(pm_wq, &genpd->power_off_work);
^
power/domain.c:192:13: note: each undeclared identifier is reported only once for each function it appears in
This ensures we don't try to enable it when CONFIG_PM is
disabled, mirroring what we do on most other platforms.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: f15107f41282 ("ARM: zx: Add power domains for ZX296702")
Reviewed-by: Jun Nie <jun.nie@linaro.org>
|
|
The patches that were applied to add PWM lookup tables for legacy boards
were from v1 of the series instead of the revised v2 where the resulting
build errors had already been fixed.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
This was totally lost when I originally created the atomic helpers.
We probably should also check possible_clones in the helpers, but
since the legacy ones didn't do that this is for a separate patch.
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Stone <daniels@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447868808-10266-1-git-send-email-daniel.vetter@ffwll.ch
|
|
For now, VCPUs were always created sequentially with incrementing
VCPU ids. Therefore, the index in the VCPUs array matched the id.
As sequential creation might change with cpu hotplug, let's use
the correct lookup function to find a VCPU by id, not array index.
Let's also use kvm_lookup_vcpu() for validation of the sending VCPU
on external call injection.
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: stable@vger.kernel.org # db27a7a KVM: Provide function for VCPU lookup by id
|
|
Commit 383d0b050106 ("KVM: s390: handle pending local interrupts via
bitmap") introduced a possible memory overwrite from user space.
User space could pass an invalid emergency signal code (sending VCPU)
and therefore exceed the bitmap. Let's take care of this case and
check that the id is in the valid range.
Reviewed-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org # v3.19+ db27a7a KVM: Provide function for VCPU lookup by id
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
|
|
Let's provide a function to lookup a VCPU by id.
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
[split patch from refactoring patch]
|
|
For primary plane initialization failure cases, ipu_plane_init() may return
a pointer encoded by ERR_PTR(). So, we should bailout instead of using that
pointer blindly.
Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
Use drm_universal_plane_init to create the planes, create the primary
plane first and use drm_crtc_init_with_planes to associate it with
the crtc.
This gets rid of the unused fallback primary plane previously created
by drm_crtc_init and fixes a NULL pointer dereference issue that can
be triggered by a modeset from userspace when fbdev helpers are
enabled [1].
[1] https://lkml.org/lkml/2015/11/4/107
Reported-by: Liu Ying <Ying.Liu@freescale.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Liu Ying <Ying.Liu@freescale.com>
|
|
The "reg" entry in the "poweroff" section of "kirkwood-ts219.dtsi"
addressed the wrong uart (0 = console). This patch changes the address
to select uart 1, which is the uart connected to the pic
microcontroller, which can switch the device off.
Signed-off-by: Helmut Klein <hgkr.klein@gmail.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Fixes: 4350a47bbac3 ("ARM: Kirkwood: Make use of the QNAP Power off driver.")
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
|
|
The pfmf intercept handler should check if the EDAT 1 facility
is installed in the guest, not if it is installed in the host.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
|
|
We should never allow to enable/disable any facilities for the guest
when other VCPUs were already created.
kvm_arch_vcpu_(load|put) relies on SIMD not changing during runtime.
If somebody would create and run VCPUs and then decides to enable
SIMD, undefined behaviour could be possible (e.g. vector save area
not being set up).
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: stable@vger.kernel.org # 4.1+
|
|
There appears to be no formal statement of what pv_irq_ops.save_fl() is
supposed to return precisely. Native returns the full flags, while lguest and
Xen only return the Interrupt Flag, and both have comments by the
implementations stating that only the Interrupt Flag is looked at. This may
have been true when initially implemented, but no longer is.
To make matters worse, the Xen PVOP leaves the upper bits undefined, making
the BUG_ON() undefined behaviour. Experimentally, this now trips for 32bit PV
guests on Broadwell hardware. The BUG_ON() is consistent for an individual
build, but not consistent for all builds. It has also been a sitting timebomb
since SMAP support was introduced.
Use native_save_fl() instead, which will obtain an accurate view of the AC
flag.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Tested-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: <lguest@lists.ozlabs.org>
Cc: Xen-devel <xen-devel@lists.xen.org>
CC: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1433323874-6927-1-git-send-email-andrew.cooper3@citrix.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
There was a confusion between update_ftrace_function() and static
function tracing trampoline regarding 3rd parameter (ftrace_ops).
Add a comment for clarification.
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Cc: H. Peter Anvin <hpa@linux.intel.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/1447721004-2551-1-git-send-email-namhyung@kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
This reverts
commit 6764e9f8724f1231b4deac53b9a82286ac0830e7
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date: Thu Aug 27 15:44:06 2015 +0200
drm/i915: skip modeset if compatible for everyone.
Bring back the i915.fastboot module parameter, disabled by default, due
to backlight regression on Chromebook Pixel 2015.
Apparently the firmware of the Chromebook in question enables the panel
but disables backlight to avoid a brief garbage scanout upon loading the
kernel/module. With fastboot, we leave the backlight untouched, in this
case disabled. The user would have to do a modeset (i.e. not just crank
up the brightness) to enable the backlight.
There is no clean fix readily available, so get back to the drawing
board by reverting.
[N.B. The reference below is for when the thread was included on public
lists, and some of the context had already been dropped by then.]
Reported-and-tested-by: Olof Johansson <olof@lixom.net>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
References: http://marc.info/?i=CAKMK7uES7xk05ki92oeX6gmvZWAh9f2vL7yz=6T+fGK9J3X7cQ@mail.gmail.com
Fixes: 6764e9f8724f ("drm/i915: skip modeset if compatible for everyone.")
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447921590-3785-1-git-send-email-jani.nikula@intel.com
|
|
Add the "init" anf "sleep" pinctrl as the OTP gpio state.
We need the OTP pin is gpio state before resetting the TSADC controller,
since the tshut polarity will generate a high signal.
"init" pinctrl property is defined by Doug's Patch[0].
Patch[0]:
https://patchwork.kernel.org/patch/7454311/
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The eMMC of the minnie Chromebook doesn't like our current method of
tuning and while there are solutions on the horizon, they still need
investigating. Other Chromebooks tune just fine with the emmc, so
simply disable tuning on Minnie for now.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
When a passive TCP is created, we eventually call tcp_md5_do_add()
with sk pointing to the child. It is not owner by the user yet (we
will add this socket into listener accept queue a bit later anyway)
But we do own the spinlock, so amend the lockdep annotation to avoid
following splat :
[ 8451.090932] net/ipv4/tcp_ipv4.c:923 suspicious rcu_dereference_protected() usage!
[ 8451.090932]
[ 8451.090932] other info that might help us debug this:
[ 8451.090932]
[ 8451.090934]
[ 8451.090934] rcu_scheduler_active = 1, debug_locks = 1
[ 8451.090936] 3 locks held by socket_sockopt_/214795:
[ 8451.090936] #0: (rcu_read_lock){.+.+..}, at: [<ffffffff855c6ac1>] __netif_receive_skb_core+0x151/0xe90
[ 8451.090947] #1: (rcu_read_lock){.+.+..}, at: [<ffffffff85618143>] ip_local_deliver_finish+0x43/0x2b0
[ 8451.090952] #2: (slock-AF_INET){+.-...}, at: [<ffffffff855acda5>] sk_clone_lock+0x1c5/0x500
[ 8451.090958]
[ 8451.090958] stack backtrace:
[ 8451.090960] CPU: 7 PID: 214795 Comm: socket_sockopt_
[ 8451.091215] Call Trace:
[ 8451.091216] <IRQ> [<ffffffff856fb29c>] dump_stack+0x55/0x76
[ 8451.091229] [<ffffffff85123b5b>] lockdep_rcu_suspicious+0xeb/0x110
[ 8451.091235] [<ffffffff8564544f>] tcp_md5_do_add+0x1bf/0x1e0
[ 8451.091239] [<ffffffff85645751>] tcp_v4_syn_recv_sock+0x1f1/0x4c0
[ 8451.091242] [<ffffffff85642b27>] ? tcp_v4_md5_hash_skb+0x167/0x190
[ 8451.091246] [<ffffffff85647c78>] tcp_check_req+0x3c8/0x500
[ 8451.091249] [<ffffffff856451ae>] ? tcp_v4_inbound_md5_hash+0x11e/0x190
[ 8451.091253] [<ffffffff85647170>] tcp_v4_rcv+0x3c0/0x9f0
[ 8451.091256] [<ffffffff85618143>] ? ip_local_deliver_finish+0x43/0x2b0
[ 8451.091260] [<ffffffff856181b6>] ip_local_deliver_finish+0xb6/0x2b0
[ 8451.091263] [<ffffffff85618143>] ? ip_local_deliver_finish+0x43/0x2b0
[ 8451.091267] [<ffffffff85618d38>] ip_local_deliver+0x48/0x80
[ 8451.091270] [<ffffffff85618510>] ip_rcv_finish+0x160/0x700
[ 8451.091273] [<ffffffff8561900e>] ip_rcv+0x29e/0x3d0
[ 8451.091277] [<ffffffff855c74b7>] __netif_receive_skb_core+0xb47/0xe90
Fixes: a8afca0329988 ("tcp: md5: protects md5sig_info with RCU")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Thomas reports
"
4gsystems sells two total different LTE-surfsticks under the same name.
..
The newer version of XS Stick W100 is from "omega"
..
Under windows the driver switches to the same ID, and uses MI03\6 for
network and MI01\6 for modem.
..
echo "1c9e 9b01" > /sys/bus/usb/drivers/qmi_wwan/new_id
echo "1c9e 9b01" > /sys/bus/usb-serial/drivers/option1/new_id
T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 4 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1c9e ProdID=9b01 Rev=02.32
S: Manufacturer=USB Modem
S: Product=USB Modem
S: SerialNumber=
C: #Ifs= 5 Cfg#= 1 Atr=80 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
I: If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
Now all important things are there:
wwp0s29f7u2i3 (net), ttyUSB2 (at), cdc-wdm0 (qmi), ttyUSB1 (at)
There is also ttyUSB0, but it is not usable, at least not for at.
The device works well with qmi and ModemManager-NetworkManager.
"
Reported-by: Thomas Schäfer <tschaefer@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
During code review, I noticed we were passing a bad buffer pointer
to bpf_load_pointer helper function called by jitted code.
Point to the buffer allocated by JIT, so we don't silently corrupt
other parts of the stack.
Signed-off-by: Zi Shen Lim <zlim.lnx@gmail.com>
Acked-by: Yang Shi <yang.shi@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The machine hang completely with the following message on the console:
[ 487.777538] BUG: unable to handle kernel NULL pointer dereference at 0000000000000060
[ 487.777554] IP: [<ffffffff8158aaee>] _raw_spin_lock+0xe/0x30
[ 487.777557] PGD 42e9f7067 PUD 42f2fa067 PMD 0
[ 487.777560] Oops: 0002 [#1] SMP
...
[ 487.777618] CPU: 21 PID: 3190 Comm: Xorg Tainted: G E 4.4.0-rc1-3-default+ #6
[ 487.777620] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS BRHSXSD1.86B.0059.R00.1501081238 01/08/2015
[ 487.777621] task: ffff880853ae4680 ti: ffff8808696d4000 task.ti: ffff8808696d4000
[ 487.777625] RIP: 0010:[<ffffffff8158aaee>] [<ffffffff8158aaee>] _raw_spin_lock+0xe/0x30
[ 487.777627] RSP: 0018:ffff8808696d79c0 EFLAGS: 00010246
[ 487.777628] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 487.777629] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000060
[ 487.777630] RBP: ffff8808696d79e0 R08: 0000000000000000 R09: ffff88086924a780
[ 487.777631] R10: 000000000001bb40 R11: 0000000000003246 R12: 0000000000000000
[ 487.777632] R13: ffff880463a27360 R14: ffff88046ca50218 R15: 0000000000000080
[ 487.777634] FS: 00007f3f81c5a8c0(0000) GS:ffff88086f060000(0000) knlGS:0000000000000000
[ 487.777635] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 487.777636] CR2: 0000000000000060 CR3: 000000042e678000 CR4: 00000000001406e0
[ 487.777638] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 487.777639] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 487.777639] Stack:
[ 487.777642] ffffffffa00eb5fa ffff8808696d7b60 ffff88086b87d800 0000000000000000
[ 487.777644] ffff8808696d7ac8 ffffffffa01694b6 ffff8808696d7ae8 ffffffff8109c8d5
[ 487.777647] ffff880469158740 ffff880463a27000 ffff88086b87d800 ffff88086b87d800
[ 487.777647] Call Trace:
[ 487.777674] [<ffffffffa00eb5fa>] ? drm_gem_object_lookup+0x1a/0xa0 [drm]
[ 487.777681] [<ffffffffa01694b6>] mga_crtc_cursor_set+0xc6/0xb60 [mgag200]
[ 487.777691] [<ffffffff8109c8d5>] ? find_busiest_group+0x35/0x4a0
[ 487.777696] [<ffffffff81086294>] ? __might_sleep+0x44/0x80
[ 487.777699] [<ffffffff815888c2>] ? __ww_mutex_lock+0x22/0x9c
[ 487.777722] [<ffffffffa0104f64>] ? drm_modeset_lock+0x34/0xf0 [drm]
[ 487.777733] [<ffffffffa0148d9e>] restore_fbdev_mode+0xee/0x2a0 [drm_kms_helper]
[ 487.777742] [<ffffffffa014afce>] drm_fb_helper_restore_fbdev_mode_unlocked+0x2e/0x70 [drm_kms_helper]
[ 487.777748] [<ffffffffa014b037>] drm_fb_helper_set_par+0x27/0x50 [drm_kms_helper]
[ 487.777752] [<ffffffff8134560c>] fb_set_var+0x18c/0x3f0
[ 487.777777] [<ffffffffa02a9b0a>] ? __ext4_handle_dirty_metadata+0x8a/0x210 [ext4]
[ 487.777783] [<ffffffff8133cb97>] fbcon_blank+0x1b7/0x2b0
[ 487.777790] [<ffffffff813be2a3>] do_unblank_screen+0xb3/0x1c0
[ 487.777795] [<ffffffff813b5aba>] vt_ioctl+0x118a/0x1210
[ 487.777801] [<ffffffff813a8fe0>] tty_ioctl+0x3f0/0xc90
[ 487.777808] [<ffffffff81172018>] ? kzfree+0x28/0x30
[ 487.777813] [<ffffffff811e053f>] ? mntput+0x1f/0x30
[ 487.777817] [<ffffffff811d3f5d>] do_vfs_ioctl+0x30d/0x570
[ 487.777822] [<ffffffff8107ed3a>] ? task_work_run+0x8a/0xa0
[ 487.777825] [<ffffffff811d4234>] SyS_ioctl+0x74/0x80
[ 487.777829] [<ffffffff8158aeae>] entry_SYSCALL_64_fastpath+0x12/0x71
[ 487.777851] Code: 65 ff 0d ce 02 a8 7e 5d c3 ba 01 00 00 00 f0 0f b1 17 85 c0 75 e8 b0 01 5d c3 0f 1f 00 65 ff 05 b1 02 a8 7e 31 c0 ba 01 00 00 00 <f0> 0f b1 17 85 c0 75 01 c3 55 89 c6 48 89 e5 e8 4e f5 b1 ff 5d
[ 487.777854] RIP [<ffffffff8158aaee>] _raw_spin_lock+0xe/0x30
[ 487.777855] RSP <ffff8808696d79c0>
[ 487.777856] CR2: 0000000000000060
[ 487.777860] ---[ end trace 672a2cd555e0ebd3 ]---
The cursor code may be entered with file_priv == NULL && handle == NULL.
The problem was introduced by:
"bf89209 drm/mga200g: Hold a proper reference for cursor_set"
which calls drm_gem_object_lookup(dev, file_priv...). Previously this wasn't
a problem because we checked the handle. Move the check early in the function
can fix the problem.
Signed-off-by: Rui Wang <rui.y.wang@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Here are a few little VC4 fixes for 4.4 that I didn't get in to you
before the -next pull request. I dropped the feature-ish one I'd
mentioned, and also droppped the one I saw you included in the last
-fixes pull request.
* 'drm-vc4-fixes' of git://github.com/anholt/linux:
drm/vc4: Make sure that planes aren't scaled.
drm/vc4: Fix some failure to track __iomem decorations on pointers.
drm/vc4: checking for NULL instead of IS_ERR
drm/vc4: fix itnull.cocci warnings
drm/vc4: fix platform_no_drv_owner.cocci warnings
drm/vc4: vc4_plane_duplicate_state() can be static
|
|
into drm-fixes
Radeon and amdgpu fixes for 4.4. A bit more the usual since I missed
last week. Misc fixes all over the place. The big changes are the
tiling configuration fixes for Fiji.
* 'drm-fixes-4.4' of git://people.freedesktop.org/~agd5f/linux: (35 commits)
drm/amdgpu: reserve/unreserve objects out of map/unmap operations
drm/amdgpu: move bo_reserve out of amdgpu_vm_clear_bo
drm/amdgpu: add lock for interval tree in vm
drm/amdgpu: keep the owner for VMIDs
drm/amdgpu: move VM manager clean into the VM code again
drm/amdgpu: cleanup VM coding style
drm/amdgpu: remove unused VM manager field
drm/amdgpu: cleanup scheduler command submission
drm/amdgpu: fix typo in firmware name
drm/amdgpu: remove the unnecessary parameter adev for amdgpu_sa_bo_new()
drm/amdgpu: wait interruptible when semaphores are disabled v2
drm/amdgpu: update pd while updating vm as well
drm/amdgpu: fix handling order in scheduler CS
drm/amdgpu: fix incorrect mutex usage v3
drm/amdgpu: cleanup scheduler fence get/put dance
drm/amdgpu: add command submission workflow tracepoint
drm/amdgpu: update Fiji's tiling mode table
drm/amdgpu: fix bug that can't enter thermal interrupt for bonaire.
drm/amdgpu: fix seq_printf format string
drm/radeon: fix quirk for MSI R7 370 Armor 2X
...
|
|
When the R8A7795 support was added to the driver, little attention was paid
to the ravb_open() error path: free_irq() for the EMAC interrupt was called
uncoditionally, unlike request_irq(), and in a wrong order as well...
As a result, on the R-Car gen2 SoCs I started getting the following in case
of a device opening error:
WARNING: CPU: 0 PID: 1 at kernel/irq/manage.c:1448 __free_irq+0x8c/0x228()
Trying to free already-free IRQ 0
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc1-dirty #1005
Hardware name: Generic R8A7791 (Flattened Device Tree)
Backtrace:
[<c0013818>] (dump_backtrace) from [<c00139b4>] (show_stack+0x18/0x1c)
r6:c063cdd6 r5:00000009 r4:00000000 r3:00204140
[<c001399c>] (show_stack) from [<c022a578>] (dump_stack+0x74/0x90)
[<c022a504>] (dump_stack) from [<c0025f04>] (warn_slowpath_common+0x8c/0xb8)
r4:ef04fd38 r3:c0714770
[<c0025e78>] (warn_slowpath_common) from [<c0025fd4>] (warn_slowpath_fmt+0x38/0x40)
r8:ee8ad800 r7:ef0030a0 r6:00000000 r5:00000000 r4:ef003040
[<c0025fa0>] (warn_slowpath_fmt) from [<c0064cc0>] (__free_irq+0x8c/0x228)
r3:00000000 r2:c063ce9f
[<c0064c34>] (__free_irq) from [<c0064ecc>] (free_irq+0x70/0xa4)
r10:0000016b r8:00000000 r7:00000000 r6:ee8ad800 r5:00000000 r4:ef003040
[<c0064e5c>] (free_irq) from [<c033472c>] (ravb_open+0x224/0x274)
r7:fffffffe r6:00000000 r5:fffffffe r4:ee8ad800
[<c0334508>] (ravb_open) from [<c041ac78>] (__dev_open+0x84/0x104)
r7:ee8ad830 r6:c0566334 r5:00000000 r4:ee8ad800
[<c041abf4>] (__dev_open) from [<c041af08>] (__dev_change_flags+0x94/0x13c)
r7:00001002 r6:00000001 r5:00001003 r4:ee8ad800
[<c041ae74>] (__dev_change_flags) from [<c041afe8>] (dev_change_flags+0x20/0x50)
r7:c072e6e0 r6:00000138 r5:00001002 r4:ee8ad800
[<c041afc8>] (dev_change_flags) from [<c06ec06c>] (ip_auto_config+0x174/0xfb8)
r8:00001002 r7:c072e6e0 r6:c0703344 r5:00000001 r4:ee8ad800 r3:00000101
[<c06ebef8>] (ip_auto_config) from [<c000a810>] (do_one_initcall+0x100/0x1cc)
r10:c06fb83c r9:00000000 r8:c06ebef8 r7:c0736000 r6:c0710918 r5:c0710918
r4:ef2f8f80
[<c000a710>] (do_one_initcall) from [<c06ccddc>] (kernel_init_freeable+0x11c/0x1
ec)
r10:c06fb83c r9:00000000 r8:0000009a r7:c0736000 r6:c0706bf0 r5:c06fb834
r4:00000007
[<c06cccc0>] (kernel_init_freeable) from [<c0514c54>] (kernel_init+0x14/0xec)
r10:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c0514c40 r4:c0736000
[<c0514c40>] (kernel_init) from [<c0010458>] (ret_from_fork+0x14/0x3c)
r4:00000000 r3:ef04e000
Fix up the free_irq() call order and add a new label on the error path.
Fixes: 22d4df8ff3a3 ("ravb: Add support for r8a7795 SoC")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Get parent clk names in of_gpio_clk_setup() and store the names
in struct clk_gpio_delayed_register_data instead of doing it from
the clk provider's get() callback. of_clk_get_parent_name() can't
be called in struct of_clk_provider's get() callback since it may
make a call to of_clk_get_from_provider() and this in turn tries
to recursively lock of_clk_mutex.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Cc: Sergej Sawazki <ce3a@gmx.de>
Fixes: 0a4807c2f9a4 ("clk: Make of_clk_get_parent_name() robust with #clock-cells = 1")
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
|
|
DAX handling of COW faults has wrong locking sequence:
dax_fault does i_mmap_lock_read
do_cow_fault does i_mmap_unlock_write
Ross's commit[1] missed a fix[2] that Kirill added to Matthew's
commit[3].
Original COW locking logic was introduced by Matthew here[4].
This should be applied to v4.3 as well.
[1] 0f90cc6609c7 mm, dax: fix DAX deadlocks
[2] 52a2b53ffde6 mm, dax: use i_mmap_unlock_write() in do_cow_fault()
[3] 843172978bb9 dax: fix race between simultaneous faults
[4] 2e4cdab0584f mm: allow page fault handlers to perform the COW
Cc: <stable@vger.kernel.org>
Cc: Boaz Harrosh <boaz@plexistor.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Dave Chinner <dchinner@redhat.com>
Cc: Jan Kara <jack@suse.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Matthew Wilcox <matthew.r.wilcox@intel.com>
Acked-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Yigal Korman <yigal@plexistor.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
The commit fd88d16c58c2 ("selftests/seccomp: Be more precise with
syscall arguments.") use PAGE_SIZE directly which lead to build
failure on arm64.
Replace it with generic interface(sysconf(_SC_PAGESIZE)) to fix this
failure.
Build and test successful on x86_64 and arm64.
Signed-off-by: Bamvor Jian Zhang <bamvor.zhangjian@linaro.org>
Acked-by: Kees Cook <keescook@chromium.org>
Tested-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
|
|
Revert commit 053f56def57b (Documentation: kernel_parameters for Intel P
state driver) as the code documented by it has been reverted already.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The recently added mt8173 cpufreq driver relies on the cpu topology
that is always present on ARM64 but optional on ARM32:
drivers/cpufreq/mt8173-cpufreq.c: In function 'mtk_cpufreq_init':
drivers/cpufreq/mt8173-cpufreq.c:441:30: error: 'cpu_topology' undeclared (first use in this function)
cpumask_copy(policy->cpus, &cpu_topology[policy->cpu].core_sibling);
This refines the Kconfig dependencies so that we can still build on
ARM32, but only if COMPILE_TEST is selected and the CPU topology
code is present.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
There are two flavors of Atom cores to be supported by intel_pstate,
Silvermont and Airmont, so make the driver distinguish between them by
adding separate frequency tables.
Separate the CPU defaults params for each of them and match the CPU IDs
against them as appropriate.
Signed-off-by: Philippe Longepe <philippe.longepe@linux.intel.com>
Signed-off-by: Stephane Gasparini <stephane.gasparini@linux.intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
[ rjw: Subject and changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Rename symbol and function names starting with "BYT" or "byt" to
start with "ATOM" or "atom", respectively, so as to make it clear
that they may apply to Atom in general and not just to Baytrail
(the goal is to support several Atoms architectures eventually).
This should not lead to any functional changes.
Signed-off-by: Philippe Longepe <philippe.longepe@linux.intel.com>
Signed-off-by: Stephane Gasparini <stephane.gasparini@linux.intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
[ rjw : Changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Revert commit 37afb0003242 (cpufreq: intel_pstate: Use ACPI perf
configuration) that is reported to cause a regression to happen
on a system where invalid data are returned by the ACPI _PSS object.
Since that commit makes assumptions regarding the _PSS output
correctness that may turn out to be overly optimistic in general,
there is a concern that it may introduce regression on more
systems, so it's better to revert it now and we'll revisit the
underlying issue in the next cycle with a more robust solution.
Conflicts:
drivers/cpufreq/intel_pstate.c
Fixes: 37afb0003242 (cpufreq: intel_pstate: Use ACPI perf configuration)
Reported-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Revert commit 4ef451487019 (cpufreq: intel_pstate: Avoid calculation for
max/min) as it depends on commit 37afb0003242 (cpufreq: intel_pstate: Use
ACPI perf configuration) that causes problems to happen and needs to be
reverted.
Conflicts:
drivers/cpufreq/intel_pstate.c
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Changes the definition of the pointer _expiry from time_t to
time64_t. This is to handle the Y2038 problem where time_t
will overflow in the year 2038. The change is safe because
the kernel subsystems that call dns_query pass NULL.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Aya Mahfouz <mahfouz.saif.elyazal@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
the commit cdf3464e6c6b ("ipv6: Fix dst_entry refcnt bugs in ip6_tunnel")
introduced percpu storage for ip6_tunnel dst cache, but while clearing
such cache it used raw_cpu_ptr to walk the per cpu entries, so cached
dst on non current cpu are not actually reset.
This patch replaces raw_cpu_ptr with per_cpu_ptr, properly cleaning
such storage.
Fixes: cdf3464e6c6b ("ipv6: Fix dst_entry refcnt bugs in ip6_tunnel")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The source and destination pointers are misplaced.
This will be like,
ether_addr_copy(data, bssid + ADDR2);
-> ether_addr_copy(bssid, data + ADDR2);
and also to use ether_addr_copy, it has to be proved that src/dst address are
properly aligned(2).
I revert this as author agree to drop this patch.
This reverts commit d4622f68db8095dd54179e3134e97812727f6b89.
Signed-off-by: Glen Lee <glen.lee@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Adding myself as co-maintainer of nand controller driver
for the Broadcom SoCs.
Signed-off-by: Kamal Dasu <kdasu.kdev@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
ssh://ra.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
First set of IIO fixes for the 4.4 cycle.
This set does not include those for issues introduced during the merge
window. Fixes of those will follow in a future series.
* ad5064
- Make sure the local i2c_write returns 0 on success rather than the
number of bytes transfered. Otherwise we report an error on all writes.
- Fix a shift for ad5629 and ad5669 which gives incorrect DAC output on
these parts.
* ad7793
- The product ID on the datasheet is wrong. Fix it in the driver.
* IIO_DUMMY_EVGEN
- select IRQ_WORK as a dependency.
* lpc32xx
- make sure clock is prepared before enabling.
* si7020
- data byte order was reversed. Fix it.
* vf610
- Internal temperature calculation was wrong if a different
reference voltage was used. Now use a linear interpolation
function to make it work over the full range.
- Fix a division by zero in the case of a device tree property
not being present (same issue two fixes).
* xilinx XADC
- VREFN scale was wrong - fix it.
|
