commit a077e81ec6 upstream.
the enum of "DAC Polarity" should be wm8960_enum[1].
Signed-off-by: Zidan Wang <zidan.wang@freescale.com>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 9136291f1d upstream.
This patch fixes a bug in the XOR driver where the cleanup function can be
called and free descriptors that never been processed by the engine (which
result in data errors).
The cleanup function will free descriptors based on the ownership bit in
the descriptors.
Fixes: ff7b04796d ("dmaengine: DMA engine driver for Marvell XOR engine")
Signed-off-by: Lior Amsalem <alior@marvell.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Ofer Heifetz <oferh@marvell.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
[ luis: backported to 3.16:
- function rename: mv_xor_slot_cleanup() -> __mv_xor_slot_cleanup()
- adjusted context ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 93563a6a71 upstream.
For TX transactions, the TXCOMP bit in the Status Register is cleared
when the first data is written into the Transmit Holding Register.
In the lines from at91_do_twi_transfer():
at91_twi_write_data_dma(dev);
at91_twi_write(dev, AT91_TWI_IER, AT91_TWI_TXCOMP);
the TXCOMP interrupt may be enabled before the DMA controller has
actually started to write into the THR. In such a case, the TXCOMP bit
is still set into the Status Register so the interrupt is triggered
immediately. The driver understands that a transaction completion has
occurred but this transaction hasn't started yet. Hence the TXCOMP
interrupt is no longer enabled by at91_do_twi_transfer() but instead
by at91_twi_write_data_dma_callback().
Also, the TXCOMP bit in the Status Register in not a clear on read flag
but a snapshot of the transmission state at the time the Status
Register is read.
When a NACK error is dectected by the I2C controller, the TXCOMP, NACK
and TXRDY bits are set together to 1 in the SR. If enabled, the TXCOMP
interrupt is triggered at the same time. Also setting the TXRDY to 1
triggers the DMA controller to write the next data into the THR. Such
a write resets the TXCOMP bit to 0 in the SR. So depending on when the
interrupt handler reads the SR, it may fail to detect the NACK error
if it relies on the TXCOMP bit. The NACK bit and its interrupt should
be used instead.
For RX transactions, the TXCOMP bit in the Status Register is cleared
when the START bit is set into the Control Register. However to unify
the management of the TXCOMP bit when the DMA controller is used, the
TXCOMP interrupt is now enabled by the DMA callbacks for both TX and
RX transfers.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 27e7cd0165 upstream.
The pinctrl_gpio_range[] array described a first bank of 32 GPIOs and
a second one of 27 GPIOs. However, since there is a total of 60 MPP
pins that can be muxed as GPIOs, the second bank really has 28 GPIOs.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes: ca6d9a084b ("pinctrl: mvebu: add pin-muxing driver for the Marvell Armada 380/385")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit d538990ee1 upstream.
There was an incorrect space in the definition of the function of one
pin in the Armada 375 pinctrl driver, which this commit fixes.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes: ce3ed59dcd ("pinctrl: mvebu: add pin-muxing driver for the Marvell Armada 375")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit ea78b9511a upstream.
There was a mistake in the definition of the functions for MPP48 on
Marvell Armada XP. The second function is dev(clkout), and not tclk.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes: 463e270f76 ("pinctrl: mvebu: add pinctrl driver for Armada XP")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 80b3d04fea upstream.
The latest version of the Armada XP datasheet no longer documents the
VDD cpu_pd functions, which might indicate they are not working and/or
not supported. This commit ensures the pinctrl driver matches the
datasheet.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes: 463e270f76 ("pinctrl: mvebu: add pinctrl driver for Armada XP")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit bc99357f36 upstream.
After updating to a more recent version of the Armada XP datasheet, we
realized that some of the pins documented as having a NAND-related
functionality in fact did not have such functionality. This commit
updates the pinctrl driver accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes: 463e270f76 ("pinctrl: mvebu: add pinctrl driver for Armada XP")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit e5447d2609 upstream.
After updating to a more recent version of the Armada 375, we realized
that some of the pins documented as having a NAND-related
functionality in fact did not have such functionality. This commit
updates the pinctrl driver accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes: ce3ed59dcd ("pinctrl: mvebu: add pin-muxing driver for the Marvell Armada 375")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 438881dfdd upstream.
Due to a mistake, the CS0 and CS1 SPI0 functions were incorrectly
named "spi0-1" instead of just "spi0". This commit fixes that.
This DT binding change does not affect any of the in-tree users.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes: 5f597bb2be ("pinctrl: mvebu: add pinctrl driver for Armada 370")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 331642fbf2 upstream.
A new revision of the Marvell Armada 38x hardware datasheet unveiled
that the definition of some of the PCIe functions were not
correct. This commit fixes the pinctrl driver accordingly.
Some PCIe functions simply do not exist, some of the PCIe functions in
fact were corresponding to other functions, and some PCIe functions
have been added.
Note: the seemingly unrelated removal of spi(cs2) on MPP47 is related:
this function is in fact implemented on MPP43, instead of a PCIe
function.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes: ca6d9a084b ("pinctrl: mvebu: add pin-muxing driver for the Marvell Armada 380/385")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 1dace0116d upstream.
The Foxconn K8M890-8237A has two PCI host bridges, and we can't assign
resources correctly without the information from _CRS that tells us which
address ranges are claimed by which bridge. In the bugs mentioned below,
we incorrectly assign a sound card address (this example is from 1033299):
bus: 00 index 2 [mem 0x80000000-0xfcffffffff]
ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7f])
pci_root PNP0A08:00: host bridge window [mem 0x80000000-0xbfefffff] (ignored)
pci_root PNP0A08:00: host bridge window [mem 0xc0000000-0xdfffffff] (ignored)
pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0xfebfffff] (ignored)
ACPI: PCI Root Bridge [PCI1] (domain 0000 [bus 80-ff])
pci_root PNP0A08:01: host bridge window [mem 0xbff00000-0xbfffffff] (ignored)
pci 0000:80:01.0: [1106:3288] type 0 class 0x000403
pci 0000:80:01.0: reg 10: [mem 0xbfffc000-0xbfffffff 64bit]
pci 0000:80:01.0: address space collision: [mem 0xbfffc000-0xbfffffff 64bit] conflicts with PCI Bus #00 [mem 0x80000000-0xfcffffffff]
pci 0000:80:01.0: BAR 0: assigned [mem 0xfd00000000-0xfd00003fff 64bit]
BUG: unable to handle kernel paging request at ffffc90000378000
IP: [<ffffffffa0345f63>] azx_create+0x37c/0x822 [snd_hda_intel]
We assigned 0xfd_0000_0000, but that is not in any of the host bridge
windows, and the sound card doesn't work.
Turn on pci=use_crs automatically for this system.
Link: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/931368
Link: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1033299
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 3d56402d3f upstream.
Add missing invocation of pm_generic_complete() to
acpi_subsys_complete() to allow ->complete callbacks provided
by the drivers of devices using the ACPI PM domain to be executed
during system resume.
Fixes: f25c0ae2b4 (ACPI / PM: Avoid resuming devices in ACPI PM domain during system suspend)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit a7068e3932 upstream.
The buffer for condtraints debug isn't big enough to hold the output
in all cases. So fix this issue by increasing the buffer.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 15bf722e6f upstream.
ATOL FPrint fiscal printers require usb_clear_halt to be executed
to work properly. Add quirk to fix the issue.
Signed-off-by: Alexey Sokolov <sokolov@7pikes.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 90f91b1298 upstream.
It seems Broadcom released two devices with conflicting device id. There
are for sure 14e4:4321 PCI devices with BCM4321 (N-PHY) chipset, they
can be found in routers, e.g. Netgear WNR834Bv2. However, according to
Broadcom public sources 0x4321 is also used for 5 GHz BCM4306 (G-PHY).
It's unsure if they meant PCI device id, or "virtual" id (from SPROM).
To distinguish these devices lets check PHY type (G vs. N).
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 300f77c08d upstream.
AR93xx and newer needs to stop rx before tx to avoid getting the DMA
engine or MAC into a stuck state.
This should reduce/fix the occurence of "Failed to stop Tx DMA" logspam.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit ecffc80478 upstream.
The SKB returned from the Intel specific version information command is
missing a kfree_skb.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 9fc2b4b436 upstream.
Before calling into the filesystem, vfs_setxattr calls
security_inode_setxattr, which ends up calling selinux_inode_setxattr in
our case. That returns -EOPNOTSUPP whenever SBLABEL_MNT is not set.
SBLABEL_MNT was supposed to be set by sb_finish_set_opts, which sets it
only if selinux_is_sblabel_mnt returns true.
The selinux_is_sblabel_mnt logic was broken by eadcabc697 "SELinux: do
all flags twiddling in one place", which didn't take into the account
the SECURITY_FS_USE_NATIVE behavior that had been introduced for nfs
with eb9ae68650 "SELinux: Add new labeling type native labels".
This caused setxattr's of security labels over NFSv4.2 to fail.
Cc: Eric Paris <eparis@redhat.com>
Cc: David Quigley <dpquigl@davequigley.com>
Reported-by: Richard Chan <rc556677@outlook.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
[PM: added the stable dependency]
Signed-off-by: Paul Moore <pmoore@redhat.com>
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 8451cc964c upstream.
If the function fails reference counter to the object is not decremented
causing leaks.
This is hard to spot as it happens only on very low memory situations.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 2fa19535ca upstream.
If objects are moved back from system memory to VRAM (and spice id
created again) memory is already initialized so we need to set flag
to not clear memory.
If you don't do it after a while using desktop many images turns to
black or transparents.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 8c6cf9cc82 upstream.
Ignore an existing mount if the locked readonly, nodev or atime
attributes are less permissive than the desired attributes
of the new mount.
On success ensure the new mount locks all of the same readonly, nodev and
atime attributes as the old mount.
The nosuid and noexec attributes are not checked here as this change
is destined for stable and enforcing those attributes causes a
regression in lxc and libvirt-lxc where those applications will not
start and there are no known executables on sysfs or proc and no known
way to create exectuables without code modifications
Fixes: e51db73532 ("userns: Better restrictions on when proc and sysfs can be mounted")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 8a70cefa30 upstream.
The AF_IEEE802154 sockaddr looks like this:
struct sockaddr_ieee802154 {
sa_family_t family; /* AF_IEEE802154 */
struct ieee802154_addr_sa addr;
};
struct ieee802154_addr_sa {
int addr_type;
u16 pan_id;
union {
u8 hwaddr[IEEE802154_ADDR_LEN];
u16 short_addr;
};
};
On most architectures there will be implicit structure padding here,
in two different places:
* In struct sockaddr_ieee802154, two bytes of padding between 'family'
(unsigned short) and 'addr', so that 'addr' starts on a four byte
boundary.
* In struct ieee802154_addr_sa, two bytes at the end of the structure,
to make the structure 16 bytes.
When calling recvmsg(2) on a PF_IEEE802154 SOCK_DGRAM socket, the
ieee802154 stack constructs a struct sockaddr_ieee802154 on the
kernel stack without clearing these padding fields, and, depending
on the addr_type, between four and ten bytes of uncleared kernel
stack will be copied to userspace.
We can't just insert two 'u16 __pad's in the right places and zero
those before copying an address to userspace, as not all architectures
insert this implicit padding -- from a quick test it seems that avr32,
cris and m68k don't insert this padding, while every other architecture
that I have cross compilers for does insert this padding.
The easiest way to plug the leak is to just memset the whole struct
sockaddr_ieee802154 before filling in the fields we want to fill in,
and that's what this patch does.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Acked-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
[ luis: backported to 3.16:
- file rename: net/ieee802154/socket.c -> net/ieee802154/dgram.c ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 45c44b5ff9 upstream.
Increase the default init stage change timeout from 15 seconds to 30 seconds.
This resolves issues we have seen with some adapters not transitioning
to the first init stage within 15 seconds, which results in adapter
initialization failures.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 72e349f112 upstream.
When we take a PMU exception or a software event we call
perf_read_regs(). This overloads regs->result with a boolean that
describes if we should use the sampled instruction address register
(SIAR) or the regs.
If the exception is in kernel, we start with the kernel regs and
backtrace through the kernel stack. At this point we switch to the
userspace regs and backtrace the user stack with perf_callchain_user().
Unfortunately these regs have not got the perf_read_regs() treatment,
so regs->result could be anything. If it is non zero,
perf_instruction_pointer() decides to use the SIAR, and we get issues
like this:
0.11% qemu-system-ppc [kernel.kallsyms] [k] _raw_spin_lock_irqsave
|
---_raw_spin_lock_irqsave
|
|--52.35%-- 0
| |
| |--46.39%-- __hrtimer_start_range_ns
| | kvmppc_run_core
| | kvmppc_vcpu_run_hv
| | kvmppc_vcpu_run
| | kvm_arch_vcpu_ioctl_run
| | kvm_vcpu_ioctl
| | do_vfs_ioctl
| | sys_ioctl
| | system_call
| | |
| | |--67.08%-- _raw_spin_lock_irqsave <--- hi mum
| | | |
| | | --100.00%-- 0x7e714
| | | 0x7e714
Notice the bogus _raw_spin_irqsave when we transition from kernel
(system_call) to userspace (0x7e714). We inserted what was in the SIAR.
Add a check in regs_use_siar() to check that the regs in question
are from a PMU exception. With this fix the backtrace makes sense:
0.47% qemu-system-ppc [kernel.vmlinux] [k] _raw_spin_lock_irqsave
|
---_raw_spin_lock_irqsave
|
|--53.83%-- 0
| |
| |--44.73%-- hrtimer_try_to_cancel
| | kvmppc_start_thread
| | kvmppc_run_core
| | kvmppc_vcpu_run_hv
| | kvmppc_vcpu_run
| | kvm_arch_vcpu_ioctl_run
| | kvm_vcpu_ioctl
| | do_vfs_ioctl
| | sys_ioctl
| | system_call
| | __ioctl
| | 0x7e714
| | 0x7e714
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 4fa9dabcff upstream.
Lenovo G30-50 does not have a hardware wireless switch and wireless
is always blocked.
BugLink: https://bugs.launchpad.net/bugs/1397021
Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
Signed-off-by: Philippe Coval <philippe.coval@open.eurogiciel.org>
[dvhart@linux.intel.com: Reordered dmi id per Phillippe's later version]
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit e8d975e73e upstream.
Problem: When an operation like WRITE receives a BAD_STATEID, even though
recovery code clears the RECLAIM_NOGRACE recovery flag before recovering
the open state, because of clearing delegation state for the associated
inode, nfs_inode_find_state_and_recover() gets called and it makes the
same state with RECLAIM_NOGRACE flag again. As a results, when we restart
looking over the open states, we end up in the infinite loop instead of
breaking out in the next test of state flags.
Solution: unset the RECLAIM_NOGRACE set because of
calling of nfs_inode_find_state_and_recover() after returning from calling
recover_open() function.
Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit b5eeed8cb6 upstream.
There is a small chance that pRD->pRDInfo->skb could go NULL
while the interrupt is processing.
Put NULL check on loop to break out.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit fb6d1f7df5 upstream.
Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset.
Dissolve the function hub_port_finish_reset() completely and divide the
actions to be taken into those which need to be done after each reset
attempt and those which need to be done after the full procedure is
complete, and place them in the appropriate places in hub_port_reset().
Also, remove an unneeded forward declaration of hub_port_reset().
Verbose Problem Description:
USB 3.0 devices may be "lost for good" during a hub port reset.
This makes Linux unable to boot from USB 3.0 devices in certain
constellations of host controllers and devices, because the USB device is
lost during initialization, preventing the rootfs from being mounted.
The underlying problem is that in the affected constellations, during the
processing inside hub_port_reset(), the hub link state goes from 0 to
SS.inactive after the initial reset, and back to 0 again only after the
following "warm" reset.
However, hub_port_finish_reset() is called after each reset attempt and
sets the state the connected USB device based on the "preliminary" status
of the hot reset to USB_STATE_NOTATTACHED due to SS.inactive, yet when
the following warm reset is complete and hub_port_finish_reset() is
called again, its call to set the device to USB_STATE_DEFAULT is blocked
by usb_set_device_state() which does not allow taking USB devices out of
USB_STATE_NOTATTACHED state.
Thanks to Alan Stern for guiding me to the proper solution and how to
submit it.
Link: http://lkml.kernel.org/r/trinity-25981484-72a9-4d46-bf17-9c1cf9301a31-1432073240136%20()%203capp-gmx-bs27
Signed-off-by: Robert Schlabbach <robert_s@gmx.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit cab462140f upstream.
With an RTL8191SU USB adaptor, sometimes the hints for a fragmented
packet are set, but the packet length is too large. Allocate enough
space to prevent memory corruption and a resulting kernel panic [1].
[1] http://www.spinics.net/lists/linux-wireless/msg136546.html
Signed-off-by: Haggai Eran <haggai.eran@gmail.com>
ACKed-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit e18b7975c8 upstream.
In case of non-Isochronous transfers, we don't
want to clear DWC3_EP_BUSY flag until XferComplete
event. That's because XferInProgress was only enabled
so we can recycle TRBs and usb_requests quicker, but
there are still other pending requests being transferred.
In order to make sure we don't allow for another StartTransfer
command while the HW is still processing other transfers,
we must keep DWC3_EP_BUSY flag set and this what this patch
does.
Fixes: f3af36511e (usb: dwc3: gadget: always enable IOC on
bulk/interrupt transfers)
Reported-by: sundeep subbaraya <sundeep.lkml@gmail.com>
Tested-by: sundeep subbaraya <sundeep.lkml@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 15575ed544 upstream.
The Arizona codec drivers had an incorrect dB scaling for the
noise generator gain that started at 0dB and went upwards.
Actually the highest setting is 0dB.
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 6e91f8cb13 upstream.
If, at the time __rcu_process_callbacks() is invoked, there are callbacks
in Tiny RCU's callback list, but none of them are ready to be invoked,
the current list-management code will knit the non-ready callbacks out
of the list. This can result in hangs and possibly worse. This commit
therefore inserts a check for there being no callbacks that can be
invoked immediately.
This bug is unlikely to occur -- you have to get a new callback between
the time rcu_sched_qs() or rcu_bh_qs() was called, but before we get to
__rcu_process_callbacks(). It was detected by the addition of RCU-bh
testing to rcutorture, which in turn was instigated by Iftekhar Ahmed's
mutation testing. Although this bug was made much more likely by
915e8a4fe4 (rcu: Remove fastpath from __rcu_process_callbacks()), this
did not cause the bug, but rather made it much more probable. That
said, it takes more than 40 hours of rcutorture testing, on average,
for this bug to appear, so this fix cannot be considered an emergency.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 891b1dc022 upstream.
We need to return error to caller if command is not sent to
controller succesfully.
Signed-off-by: Subbaraya Sundeep Bhatta <sbhatta@xilinx.com>
Fixes: b09bb64239 (usb: dwc3: gadget: implement Global Command support)
Signed-off-by: Felipe Balbi <balbi@ti.com>
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 39fa10f7e2 upstream.
Since we are messing with state in the worker.
v2: drop the changes in the mst worker
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit f7134eea05 upstream.
A temperature conversion can take 750 ms and when possible the
w1_therm slave driver drops the bus_mutex to allow other bus
operations, but that includes operations such as a periodic slave
search, which can remove this slave when it is no longer detected.
If that happens the sl->family_data will be freed and set to NULL
causing w1_slave_show to crash when it wakes up.
Signed-off-by: David Fries <David@Fries.net>
Reported-By: Thorsten Bschorr <thorsten@bschorr.de>
Tested-by: Thorsten Bschorr <thorsten@bschorr.de>
Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 69a1220060 upstream.
The argument to KVM_GET_DIRTY_LOG is a memslot id; it may not match the
position in the memslots array, which is sorted by gfn.
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[ luis: backported to 3.16:
- file rename: arch/mips/kvm/mips.c -> arch/mips/kvm/kvm_mips.c ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 535fb90622 upstream.
Avoid that srp_terminate_io() can get invoked while srp_queuecommand()
is in progress. This patch avoids that an I/O timeout can trigger the
following kernel warning:
WARNING: at drivers/infiniband/ulp/srp/ib_srp.c:1447 srp_terminate_io+0xef/0x100 [ib_srp]()
Call Trace:
[<ffffffff814c65a2>] dump_stack+0x4e/0x68
[<ffffffff81051f71>] warn_slowpath_common+0x81/0xa0
[<ffffffff8105204a>] warn_slowpath_null+0x1a/0x20
[<ffffffffa075f51f>] srp_terminate_io+0xef/0x100 [ib_srp]
[<ffffffffa07495da>] __rport_fail_io_fast+0xba/0xc0 [scsi_transport_srp]
[<ffffffffa0749a90>] rport_fast_io_fail_timedout+0xe0/0xf0 [scsi_transport_srp]
[<ffffffff8106e09b>] process_one_work+0x1db/0x780
[<ffffffff8106e75b>] worker_thread+0x11b/0x450
[<ffffffff81073c64>] kthread+0xe4/0x100
[<ffffffff814cf26c>] ret_from_fork+0x7c/0xb0
See also patch "scsi_transport_srp: Add transport layer error
handling" (commit ID 29c1732480).
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: James Bottomley <JBottomley@Odin.com>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: Sebastian Parschauer <sebastian.riemer@profitbricks.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit be34c62ddf upstream.
Introduce the helper function srp_wait_for_queuecommand().
Move the definition of scsi_request_fn_active(). Add a comment
above srp_wait_for_queuecommand() that support for scsi-mq needs
to be added.
This patch does not change any functionality. A second call to
srp_wait_for_queuecommand() will be introduced in the next patch.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: James Bottomley <JBottomley@Odin.com>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: Sebastian Parschauer <sebastian.riemer@profitbricks.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 12c3500505 upstream.
WM8955_K_8_0_MASK bits is controlled by WM8955_PLL_CONTROL_3 rather than
WM8955_PLL_CONTROL_2.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 1b852bceb0 upstream.
Fresh mounts of proc and sysfs are a very special case that works very
much like a bind mount. Unfortunately the current structure can not
preserve the MNT_LOCK... mount flags. Therefore refactor the logic
into a form that can be modified to preserve those lock bits.
Add a new filesystem flag FS_USERNS_VISIBLE that requires some mount
of the filesystem be fully visible in the current mount namespace,
before the filesystem may be mounted.
Move the logic for calling fs_fully_visible from proc and sysfs into
fs/namespace.c where it has greater access to mount namespace state.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit ebb6ad73e6 upstream.
VMID Control 0 BIT[2:1] is VMID Divider Enable and Select
00 = VMID disabled (for OFF mode)
01 = 2 x 50kΩ divider (for normal operation)
10 = 2 x 250kΩ divider (for low power standby)
11 = 2 x 5kΩ divider (for fast start-up)
So WM8903_VMID_RES_250K should be 2 << 1, which is 4.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 14ba3ec1de upstream.
According to the datasheet:
R10 (0Ah) VMID Impedance Control
BIT 3:2 VMIDSEL DEFAULT 00
DESCRIPTION: VMID impedance selection control
00: 75kΩ output
01: 300kΩ output
10: 2.5kΩ output
WM8737_VMIDSEL_MASK is 0xC (VMIDSEL - [3:2]),
so it needs to left shift WM8737_VMIDSEL_SHIFT bits for setting these bits.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 63781394c5 upstream.
request_any_context_irq() returns a negative value on failure.
It returns either IRQC_IS_HARDIRQ or IRQC_IS_NESTED on success.
So fix testing return value of request_any_context_irq().
Also fixup the return value of devm_request_any_context_irq() to make it
consistent with request_any_context_irq().
Fixes: 0668d30651 ("genirq: Add devm_request_any_context_irq()")
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Link: http://lkml.kernel.org/r/1431334978.17783.4.camel@ingics.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 69d9cd8c59 upstream.
This reverts commit 7291a932c6.
The conversion to be16_add_cpu() is incorrect in case cryptlen is
negative due to premature (i.e. before addition / subtraction)
implicit conversion of cryptlen (int -> u16) leading to sign loss.
Cc: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Horia Geanta <horia.geanta@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 5fa7dadc89 upstream.
Fixes: 1d11911a8c ("crypto: talitos - fix warning: 'alg' may be used uninitialized in this function")
Signed-off-by: Horia Geanta <horia.geanta@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit 084609bf72 upstream.
Setting a dev_pm_ops suspend/resume pair of callbacks but not a set of
hibernation callbacks means those pm functions will not be
called upon hibernation - that leads to system crash on ARM during
freezing if gpio-led is used in combination with CPU led trigger.
It may happen after freeze_noirq stage (GPIO is suspended)
and before syscore_suspend stage (CPU led trigger is suspended)
- usually when disable_nonboot_cpus() is called.
Log:
PM: noirq freeze of devices complete after 1.425 msecs
Disabling non-boot CPUs ...
^ system may crash or stuck here with message (TI AM572x)
WARNING: CPU: 0 PID: 3100 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x22c/0x370()
44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in Supervisor mode during Functional access
CPU1: shutdown
^ or here
Fix this by using SIMPLE_DEV_PM_OPS, which appropriately
assigns the suspend and hibernation callbacks and move
led_suspend/led_resume under CONFIG_PM_SLEEP to avoid
build warnings.
Fixes: 73e1ab41a8 (leds: Convert led class driver from legacy pm ops to dev_pm_ops)
Signed-off-by: Grygorii Strashko <Grygorii.Strashko@linaro.org>
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
