| Age | Commit message (Collapse) | Author |
|---|
|
This allows to modify TFD_TX_CMD_SLOTS to a power of 2
which is smaller than 256.
Note that we still need to set values to wrap at 256
into the scheduler's write pointer, but all the rest of
the code can use shorter transmit queues.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
The firmware now adds more information about time sharing
with the Bluetooth core.
Adapt the API structures and add the new fields in the
debugfs hooks.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
The iwl_wait_notification() function removes the wait entry from the
list. To make it clearer that it's doing the same thing as
iwl_remove_notification(), call the latter instead of having duplicate
code.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
There's no need to differentiate an INIT that ended early because of
RFKILL from one that succeded. Additionally, if INIT fails later,
during calibration, due to RFKILL, we can just return success and
continue as if we were already in RFKILL to start with.
Remove this unnecessary differentiation and do some other small
clean-ups while at it.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
The corunning block was supposed to help in coex scenarios.
It required the driver to configure the firmware based on
the coupling between the two antennas of the devices.
This was never in use and the configuration sent by the
driver has always been blank.
Remove all that code.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
The hardlockup detector on x86 uses a performance counter based on unhalted
CPU cycles and a periodic hrtimer. The hrtimer period is about 2/5 of the
performance counter period, so the hrtimer should fire 2-3 times before the
performance counter NMI fires. The NMI code checks whether the hrtimer
fired since the last invocation. If not, it assumess a hard lockup.
The calculation of those periods is based on the nominal CPU
frequency. Turbo modes increase the CPU clock frequency and therefore
shorten the period of the perf/NMI watchdog. With extreme Turbo-modes (3x
nominal frequency) the perf/NMI period is shorter than the hrtimer period
which leads to false positives.
A simple fix would be to shorten the hrtimer period, but that comes with
the side effect of more frequent hrtimer and softlockup thread wakeups,
which is not desired.
Implement a low pass filter, which checks the perf/NMI period against
kernel time. If the perf/NMI fires before 4/5 of the watchdog period has
elapsed then the event is ignored and postponed to the next perf/NMI.
That solves the problem and avoids the overhead of shorter hrtimer periods
and more frequent softlockup thread wakeups.
Fixes: 58687acba592 ("lockup_detector: Combine nmi_watchdog and softlockup detector")
Reported-and-tested-by: Kan Liang <Kan.liang@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: dzickus@redhat.com
Cc: prarit@redhat.com
Cc: ak@linux.intel.com
Cc: babu.moger@oracle.com
Cc: peterz@infradead.org
Cc: eranian@google.com
Cc: acme@redhat.com
Cc: stable@vger.kernel.org
Cc: atomlin@redhat.com
Cc: akpm@linux-foundation.org
Cc: torvalds@linux-foundation.org
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1708150931310.1886@nanos
|
|
irq_modify_status starts by clearing the trigger settings from
irq_data before applying the new settings, but doesn't restore them,
leaving them to IRQ_TYPE_NONE.
That's pretty confusing to the potential request_irq() that could
follow. Instead, snapshot the settings before clearing them, and restore
them if the irq_modify_status() invocation was not changing the trigger.
Fixes: 1e2a7d78499e ("irqdomain: Don't set type when mapping an IRQ")
Reported-and-tested-by: jeffy <jeffy.chen@rock-chips.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Jon Hunter <jonathanh@nvidia.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20170818095345.12378-1-marc.zyngier@arm.com
|
|
Commit b6a1d093f96b ("PM / Domains: Extend generic power domain
debugfs") now creates a debugfs directory for each genpd based on the
name of the genpd. Currently no name is given to the genpd created by
ti_sci_pm_domains driver so because of this we see a NULL pointer
dereferences when it is accessed on boot when the debugfs entry creation
is attempted.
Give the genpd a name before registering it to avoid this.
Fixes: 52835d59fc6c ("soc: ti: Add ti_sci_pm_domains driver")
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Santosh Shilimkar <ssantosh@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into fixes
Pull "i.MX fixes for 4.13, round 3" from Shawn Guo:
- Fix PCIe reset GPIO of imx6qdl-nitrogen6_som2 board, which was
a bad copy from nitrogen6_max device tree.
* tag 'imx-fixes-4.13-3' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
ARM: dts: imx6qdl-nitrogen6_som2: fix PCIe reset
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into fixes
Pull "Allwinner fixes for 4.13, round 2" from Chen-Yu Tsai:
Three fixes adding a missing alias for the Ethernet controller on A64
boards. One adding a missing interrupt for the pin controller.
* tag 'sunxi-fixes-for-4.13-2' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
arm64: allwinner: h5: fix pinctrl IRQs
arm64: allwinner: a64: sopine: add missing ethernet0 alias
arm64: allwinner: a64: pine64: add missing ethernet0 alias
arm64: allwinner: a64: bananapi-m64: add missing ethernet0 alias
|
|
attribute_groups are not supposed to change at runtime and none of the
groups is modified.
Mark the non-const structs as const.
[ tglx: Folded into one big patch ]
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: tony.luck@intel.com
Cc: bp@alien8.de
Link: http://lkml.kernel.org/r/1500550238-15655-2-git-send-email-arvind.yadav.cs@gmail.com
|
|
Jason's irqchip tree does not seem to have been updated for many months
now, remove it from the list of trees to avoid any possible confusion.
Jason says:
"Unfortunately, when I have time for irqchip, I don't always have the
time to properly follow up with pull-requests. So, for the time being,
I'll stick to reviewing as I can."
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Cc: marc.zyngier@arm.com
Link: http://lkml.kernel.org/r/20170727224733.8288-1-f.fainelli@gmail.com
|
|
The commit d42fe63d5839 ("ALSA: emu10k1: Get rid of set_fs() usage")
converted the user-space copy hack with set_fs() to the direct
memcpy(), but one place was forgotten. This resulted in the error
from snd_emu10k1_init_efx(), eventually failed to load the driver.
Fix the missing piece.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196687
Fixes: d42fe63d5839 ("ALSA: emu10k1: Get rid of set_fs() usage")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Add DSD support for new Amanero Combo384 firmware version with a new
PID. This firmware uses DSD_U32_BE.
Fixes: 3eff682d765b ("ALSA: usb-audio: Support both DSD LE/BE Amanero firmware versions")
Signed-off-by: Jussi Laako <jussi@sonarnerd.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Fixes: 920d13a884 ("nvme-pci: factor out the cqe reading mechanics from __nvme_process_cq")
Reported-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
There is no guarantee that the various isync's involved with
the context switch will order the update of the CPU mask with
the first TLB entry for the new context being loaded by the HW.
Be safe here and add a memory barrier to order any subsequent
load/store which may bring entries into the TLB.
The corresponding barrier on the other side already exists as
pte updates use pte_xchg() which uses __cmpxchg_u64 which has
a sync after the atomic operation.
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
[mpe: Add comments in the code]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
Previous value was a bad copy of nitrogen6_max device tree.
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
Fixes: 3faa1bb2e89c ("ARM: dts: imx: add Boundary Devices Nitrogen6_SOM2 support")
Cc: <stable@vger.kernel.org>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
git://people.freedesktop.org/~airlied/linux
Pull drm fixes from Dave Airlie:
"Seems to be slowing down nicely, just one amdgpu fix, and a bunch of
i915 fixes"
* tag 'drm-fixes-for-v4.13-rc6' of git://people.freedesktop.org/~airlied/linux:
drm/amdgpu: save list length when fence is signaled
drm/i915: Avoid the gpu reset vs. modeset deadlock
drm/i915: Suppress switch_mm emission between the same aliasing_ppgtt
drm/i915: Return correct EDP voltage swing table for 0.85V
drm/i915/cnl: Add slice and subslice information to debugfs.
drm/i915: Perform an invalidate prior to executing golden renderstate
drm/i915: remove unused function declaration
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management fixes from Rafael Wysocki:
"These fix two issues related to exposing the current CPU frequency to
user space on x86.
Specifics:
- Disable interrupts around reading IA32_APERF and IA32_MPERF in
aperfmperf_snapshot_khz() (introduced recently) to avoid excessive
delays between the reads that may result from interrupt handling
(Doug Smythies).
- Fix the computation of the CPU frequency to be reported through the
pstate_sample tracepoint in intel_pstate (Doug Smythies)"
* tag 'pm-4.13-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
cpufreq: x86: Disable interrupts during MSRs reading
cpufreq: intel_pstate: report correct CPU frequencies during trace
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull input fixes from Dmitry Torokhov.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: elan_i2c - Add antoher Lenovo ACPI ID for upcoming Lenovo NB
Input: elan_i2c - add ELAN0608 to the ACPI table
Input: trackpoint - assume 3 buttons when buttons detection fails
|
|
The Broadcom controller on the Raspberry Pi3 sends an empty packet with
packet type 0x00 after launching the firmware. This will cause logging
of errors.
Bluetooth: hci0: Frame reassembly failed (-84)
Since this seems to be an intented behaviour of the controller, handle
it gracefully by parsing that empty packet with packet type 0x00 and
then just simply report it as diagnostic packet.
With that change no errors are logging and the packet itself is actually
recorded in the Bluetooth monitor traces.
< HCI Command: Broadcom Launch RAM (0x3f|0x004e) plen 4
Address: 0xffffffff
> HCI Event: Command Complete (0x0e) plen 4
Broadcom Launch RAM (0x3f|0x004e) ncmd 1
Status: Success (0x00)
= Vendor Diagnostic (len 0)
< HCI Command: Broadcom Update UART Baud Rate (0x3f|0x0018) plen 6
00 00 00 10 0e 00 ......
> HCI Event: Command Complete (0x0e) plen 4
Broadcom Update UART Baud Rate (0x3f|0x0018) ncmd 1
Status: Success (0x00)
< HCI Command: Reset (0x03|0x0003) plen 0
> HCI Event: Command Complete (0x0e) plen 4
Reset (0x03|0x0003) ncmd 1
Status: Success (0x00)
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
Add binding document for serial bluetooth chips using
Broadcom protocol.
Signed-off-by: Loic Poulain <loic.poulain@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
into drm-fixes
single amdgpu fix.
* 'drm-fixes-4.13' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: save list length when fence is signaled
|
|
Add basic support for Broadcom serial slave devices.
Probe the serial device, retrieve its maximum speed and
register a new hci uart device.
Tested/compatible with bcm43438 (RPi3).
Signed-off-by: Loic Poulain <loic.poulain@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
git://anongit.freedesktop.org/git/drm-intel into drm-fixes
drm/i915 fixes for v4.13-rc6
"Chris' "drm/i915: Perform an invalidate prior to executing golden renderstate" and Daniel's
"drm/i915: Avoid the gpu reset vs. modeset deadlock" seem like the most important ones.
* tag 'drm-intel-fixes-2017-08-16' of git://anongit.freedesktop.org/git/drm-intel:
drm/i915: Avoid the gpu reset vs. modeset deadlock
drm/i915: Suppress switch_mm emission between the same aliasing_ppgtt
drm/i915: Return correct EDP voltage swing table for 0.85V
drm/i915/cnl: Add slice and subslice information to debugfs.
drm/i915: Perform an invalidate prior to executing golden renderstate
drm/i915: remove unused function declaration
|
|
If we fail a mount on account of cow recovery errors, it's possible that
a previous quotacheck left some dquots in memory. The bailout clause of
xfs_mountfs forgets to purge these, and so we leak them. Fix that.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
|
|
Way back when we established inode block-map redo log items, it was
discovered that we needed to prevent the VFS from evicting inodes during
log recovery because any given inode might be have bmap redo items to
replay even if the inode has no link count and is ultimately deleted,
and any eviction of an unlinked inode causes the inode to be truncated
and freed too early.
To make this possible, we set MS_ACTIVE so that inodes would not be torn
down immediately upon release. Unfortunately, this also results in the
quota inodes not being released at all if a later part of the mount
process should fail, because we never reclaim the inodes. So, set
MS_ACTIVE right before we do the last part of log recovery and clear it
immediately after we finish the log recovery so that everything
will be torn down properly if we abort the mount.
Fixes: 17c12bcd30 ("xfs: when replaying bmap operations, don't let unlinked inodes get reaped")
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
|
|
* intel_pstate-fix:
cpufreq: intel_pstate: report correct CPU frequencies during trace
* cpufreq-x86-fix:
cpufreq: x86: Disable interrupts during MSRs reading
|
|
Commit 2a5708409e4e (ACPI / EC: Fix a gap that ECDT EC cannot handle
EC events) introduced acpi_ec_ecdt_start(), but that function is
invoked before acpi_ec_query_init(), which is too early. This causes
the kernel to crash if an EC event occurs after boot, when ec_query_wq
is not valid:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000102
...
Workqueue: events acpi_ec_event_handler
task: ffff9f539790dac0 task.stack: ffffb437c0e10000
RIP: 0010:__queue_work+0x32/0x430
Normally, the DSDT EC should always be valid, so acpi_ec_ecdt_start()
is actually a no-op in the majority of cases. However, commit
c712bb58d827 (ACPI / EC: Add support to skip boot stage DSDT probe)
caused the probing of the DSDT EC as the "boot EC" to be skipped when
the ECDT EC is valid and uncovered the bug.
Fix this issue by invoking acpi_ec_ecdt_start() after acpi_ec_query_init()
in acpi_ec_init().
Link: https://jira01.devtools.intel.com/browse/LCK-4348
Fixes: 2a5708409e4e (ACPI / EC: Fix a gap that ECDT EC cannot handle EC events)
Fixes: c712bb58d827 (ACPI / EC: Add support to skip boot stage DSDT probe)
Reported-by: Wang Wendy <wendy.wang@intel.com>
Tested-by: Feng Chenzhou <chenzhoux.feng@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux
Pull parisc fixes from Helge Deller:
- Fix PCI memory bar assignments with 64-bit kernels on machines with
Dino/Cujo PCI chipsets. This makes PCI graphic cards work on such
machines (from Thomas Bogendoerfer).
- Fix documentation to be more clear about the difference between %pF
and %pS printk format usage. There are still many places in the
kernel which have it wrong (from Petr Mladek, Sergey Senozhatsky &
me).
* 'parisc-4.13-5' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
printk-formats.txt: Better describe the difference between %pS and %pF
parisc: pci memory bar assignment fails with 64bit kernels on dino/cujo
|
|
Daniel Borkmann says:
====================
Two BPF smap related followups
Fixing preemption imbalance and consolidating prologue
generation. Thanks!
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Given both program types are effecitvely doing the same in the
prologue, just reuse the one that we had for tc and only adapt
to the corresponding drop verdict value. That way, we don't need
to have the duplicate from 8a31db561566 ("bpf: add access to sock
fields and pkt data from sk_skb programs") to maintain.
Reported-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In smap_do_verdict(), the fall-through branch leads to call
preempt_enable() twice for the SK_REDIRECT, which creates an
imbalance. Only enable it for all remaining cases again.
Fixes: 174a79ff9515 ("bpf: sockmap with sk redirect support")
Reported-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
vio_device_id are not supposed to change at runtime. All functions
working with vio_device_id provided by <asm/vio.h> work with
const vio_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
vio_device_id are not supposed to change at runtime. All functions
working with vio_device_id provided by <asm/vio.h> work with
const vio_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
We are guaranteed to have a NULL ri->map in this branch since
we test for it earlier, so we don't need to reset it here.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Using parent->regs[] when propagating REG_LIVE_READ for spilled regs
doesn't work since parent->regs[] denote the set of normal registers
but not spilled ones. Propagate to the correct regs.
Fixes: dc503a8ad984 ("bpf/verifier: track liveness for pruning")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The sysctl documentation states that the JIT is only available on
x86_64, which is no longer correct.
Update the list, and break it out to indicate which architectures
support the cBPF JIT (via HAVE_CBPF_JIT) or the eBPF JIT
(HAVE_EBPF_JIT).
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Media type is only set if h->ae_algo->ops->get_media_type is called
so there is a possibility that media_type is uninitialized when it is
used a switch statement. Fix this by initializing media_type to
HNAE3_MEDIA_TYPE_UNKNOWN.
Detected by CoverityScan, CID#1452624("Uninitialized scalar variable")
Fixes: 496d03e960ae ("net: hns3: Add Ethtool support to HNS3 driver")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Trivial fix to spelling mistake in dev_info message
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Only print the specified options that are not recognized, instead
of the whole list of options.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Max Gurtovoy <maxg@mellanox.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs
Pull quota fix from Jan Kara:
"A fix of a check for quota limit"
* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
quota: correct space limit check
|
|
Christian Brauner reported that if you use the TIOCGPTPEER ioctl() to
get a slave pty file descriptor, the resulting file descriptor doesn't
look right in /proc/<pid>/fd/<fd>. In particular, he wanted to use
readlink() on /proc/self/fd/<fd> to get the pathname of the slave pty
(basically implementing "ptsname{_r}()").
The reason for that was that we had generated the wrong 'struct path'
when we create the pty in ptmx_open().
In particular, the dentry was correct, but the vfsmount pointed to the
mount of the ptmx node. That _can_ be correct - in case you use
"/dev/pts/ptmx" to open the master - but usually is not. The normal
case is to use /dev/ptmx, which then looks up the pts/ directory, and
then the vfsmount of the ptmx node is obviously the /dev directory, not
the /dev/pts/ directory.
We actually did have the right vfsmount available, but in the wrong
place (it gets looked up in 'devpts_acquire()' when we get a reference
to the pts filesystem), and so ptmx_open() used the wrong mnt pointer.
The end result of this confusion was that the pty worked fine, but when
if you did TIOCGPTPEER to get the slave side of the pty, end end result
would also work, but have that dodgy 'struct path'.
And then when doing "d_path()" on to get the pathname, the vfsmount
would not match the root of the pts directory, and d_path() would return
an empty pathname thinking that the entry had escaped a bind mount into
another mount.
This fixes the problem by making devpts_acquire() return the vfsmount
for the pts filesystem, allowing ptmx_open() to trivially just use the
right mount for the pts dentry, and create the proper 'struct path'.
Reported-by: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: Eric Biederman <ebiederm@xmission.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
I2C slave controller must be powered and active all the time when I2C
slave backend is registered in order to let master address and
communicate with us.
Now if the controller is runtime PM capable it will be suspended after
probe and cannot ever respond to the master or generate interrupts.
Fix this by resuming the controller when I2C slave backend is registered
and let it suspend after unregistering.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
I guess pm_runtime_put_noidle() call in i2c_dw_probe_slave() was copied
by accident from similar master mode adapter registration code. It is
unbalanced due missing pm_runtime_get_noresume() but harmless since it
doesn't decrease dev->power.usage_count below zero.
In theory we can hit similar needless runtime suspend/resume cycle
during slave mode adapter registration that was happening when
registering the master mode adapter. See commit cd998ded5c12 ("i2c:
designware: Prevent runtime suspend during adapter registration").
However, since we are slave, we can consider it as a wrong configuration
if we have other slaves attached under this adapter and can omit the
pm_runtime_get_noresume()/pm_runtime_put_noidle() calls for simplicity.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
C-Media devices (at least some models) mute the playback stream when
volumes are set to the minimum value. But this isn't informed via TLV
and the user-space, typically PulseAudio, gets confused as if it's
still played in a low volume.
This patch adds the new flag, min_mute, to struct usb_mixer_elem_info
for indicating that the mixer element is with the minimum-mute volume.
This flag is set for known C-Media devices in
snd_usb_mixer_fu_apply_quirk() in turn.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196669
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The commands that read the basic vendor information about the Broadcom
controller are duplicated for UART and USB devices. Combine them into a
single function to reduce the code complexity.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes
Pull "Fourth Round of Renesas ARM Based SoC Fixes for v4.13" from Simon Horman:
* Avoid audio_clkout naming conflict for salvator boards using
Renesas R-Car Gen 3 SoCs
Morimoto-san says "The clock name of "audio_clkout" is used by the
Renesas sound driver. This duplicated naming breaks its clock
registering/unregistering. Especially when unbind/bind it can't handle
clkout correctly. This patch renames "audio_clkout" to "audio-clkout" to
avoid the naming conflict."
* tag 'renesas-fixes4-for-v4.13' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
arm64: renesas: salvator-common: avoid audio_clkout naming conflict
|
|
Historically, DMA masks have suffered some ambiguity between whether
they represent the range of physical memory a device can access, or the
address bits a device is capable of driving, particularly since on many
platforms the two are equivalent. Whilst there are some stragglers left
(dma_max_pfn(), I'm looking at you...), the majority of DMA code has
been cleaned up to follow the latter definition, not least since it is
the only one which makes sense once IOMMUs are involved.
In this respect, of_dma_configure() has always done the wrong thing in
how it generates initial masks based on "dma-ranges". Although rounding
down did not affect the TI Keystone platform where dma_addr + size is
already a power of two, in any other case it results in a mask which is
at best unnecessarily constrained and at worst unusable.
BCM2837 illustrates the problem nicely, where we have a DMA base of 3GB
and a size of 1GB - 16MB, giving dma_addr + size = 0xff000000 and a
resultant mask of 0x7fffffff, which is then insufficient to even cover
the necessary offset, effectively making all DMA addresses out-of-range.
This has been hidden until now (mostly because we don't yet prevent
drivers from simply overwriting this initial mask later upon probe), but
due to recent changes elsewhere now shows up as USB being broken on
Raspberry Pi 3.
Make it right by rounding up instead of down, such that the mask
correctly correctly describes all possisble bits the device needs to
emit.
Fixes: 9a6d7298b083 ("of: Calculate device DMA masks based on DT dma-range size")
Reported-by: Stefan Wahren <stefan.wahren@i2se.com>
Reported-by: Andreas Färber <afaerber@suse.de>
Reported-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
|
|
__startup_64() is normally using fixup_pointer() to access globals in a
position-independent fashion. However 'next_early_pgt' was accessed
directly, which wasn't guaranteed to work.
Luckily GCC was generating a R_X86_64_PC32 PC-relative relocation for
'next_early_pgt', but Clang emitted a R_X86_64_32S, which led to
accessing invalid memory and rebooting the kernel.
Signed-off-by: Alexander Potapenko <glider@google.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michael Davidson <md@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: c88d71508e36 ("x86/boot/64: Rewrite startup_64() in C")
Link: http://lkml.kernel.org/r/20170816190808.131748-1-glider@google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
