unshare_userns(new_cred) does *new_cred = prepare_creds() before
create_user_ns() which can fail. However, the caller expects that
it doesn't need to take care of new_cred if unshare_userns() fails.
We could change the single caller, sys_unshare(), but I think it
would be more clean to avoid the side effects on failure, so with
this patch unshare_userns() does put_cred() itself and initializes
*new_cred only if create_user_ns() succeeeds.
Cc: stable@vger.kernel.org
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
regmap.h requires linux/err.h if CONFIG_REGMAP is not defined. Without it I get
error.
CC drivers/media/platform/exynos4-is/fimc-reg.o
In file included from drivers/media/platform/exynos4-is/fimc-reg.c:14:0:
include/linux/regmap.h: In function ‘regmap_write’:
include/linux/regmap.h:525:10: error: ‘EINVAL’ undeclared (first use in this function)
include/linux/regmap.h:525:10: note: each undeclared identifier is reported only once for each function it appears in
Signed-off-by: Mateusz Krawczuk <m.krawczuk@partner.samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: stable@kernel.org
Beep Volume Min/Max was backwards.
Change to SOC_SONGLE_SX_TLV for correct volume representation
Signed-off-by: Brian Austin <brian.austin@cirrus.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: stable@kernel.org
The PAR was exported as CRn == 7 and CRm == 0, but in fact the primary
coprocessor register number was determined by CRm for 64-bit coprocessor
registers as the user space API was modeled after the coprocessor
access instructions (see the ARM ARM rev. C - B3-1445).
However, just changing the CRn to CRm breaks the sorting check when
booting the kernel, because the internal kernel logic always treats CRn
as the primary register number, and it makes the table sorting
impossible to understand for humans.
Alternatively we could change the logic to always have CRn == CRm, but
that becomes unclear in the number of ways we do look up of a coprocessor
register. We could also have a separate 64-bit table but that feels
somewhat over-engineered. Instead, keep CRn the primary representation
of the primary coproc. register number in-kernel and always export the
primary number as CRm as per the existing user space ABI.
Note: The TTBR registers just magically worked because they happened to
follow the CRn(0) regs and were considered CRn(0) in the in-kernel
representation.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
The physical_node_id_bitmap in struct acpi_device is only used for
looking up the first currently unused dependent phyiscal node ID
by acpi_bind_one(). It is not really necessary, however, because
acpi_bind_one() walks the entire physical_node_list of the given
device object for sanity checking anyway and if that list is always
sorted by node_id, it is straightforward to find the first gap
between the currently used node IDs and use that number as the ID
of the new list node.
This also removes the artificial limit of the maximum number of
dependent physical devices per ACPI device object, which now depends
only on the capacity of unsigend int. As a result, it fixes a
regression introduced by commit e2ff394 (ACPI / memhotplug: Bind
removable memory blocks to ACPI device nodes) that caused
acpi_memory_enable_device() to fail when the number of 128 MB blocks
within one removable memory module was greater than 32.
Reported-and-tested-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
The original implementation of the Smack IPv6 port based
local controls works most of the time using a sockaddr as
a temporary variable, but not always as it overflows in
some circumstances. The correct data is a sockaddr_in6.
A struct sockaddr isn't as large as a struct sockaddr_in6.
There would need to be casting one way or the other. This
patch gets it the right way.
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
If scheduling an important time event fails, or if we get
an unexpected notification from the firmware, there isn't
much we can do to recover, so just drop the connection and
let higher layers retry it.
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This reverts commit a53ee0a308.
This fix causes a worse HW Error when entering RF-Kill.
Signed-off-by: Guy Cohen <guy.cohen@intel.com>
Signed-off-by: Dor Shaish <dor.shaish@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There is no need for the kernel to time out the AF_LOCAL connection to
the rpcbind socket, and doing so is problematic because when it is
time to reconnect, our process may no longer be using the same mount
namespace.
Reported-by: Nix <nix@esperi.org.uk>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Jeff Layton <jlayton@redhat.com>
Cc: stable@vger.kernel.org # 3.9.x
The list of physical devices corresponding to an ACPI device
object is walked by acpi_system_wakeup_device_seq_show() and
physical_device_enable_wakeup() without taking that object's
physical_node_lock mutex. Since each of those functions may be
run at any time as a result of a user space action, the lack of
appropriate locking in them may lead to a kernel crash if that
happens during device hot-add or hot-remove involving the device
object in question.
Fix the issue by modifying acpi_system_wakeup_device_seq_show() and
physical_device_enable_wakeup() to use physical_node_lock as
appropriate.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: All <stable@vger.kernel.org>
Currently we are reading an uninitialized value for the max_delay
variable when snooping an MLD query message of invalid length and would
update our timers with that.
Fixing this by simply ignoring such broken MLD queries (just like we do
for IGMP already).
This is a regression introduced by:
"bridge: disable snooping if there is no querier" (b00589af3b)
Reported-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Linus Lüssing <linus.luessing@web.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
AddressSanitizer [1] dynamic checker pointed a potential
out of bound access in leaf_walk_rcu()
We could allocate one more slot in tnode_new() to leave the prefetch()
in-place but it looks not worth the pain.
Bug added in commit 82cfbb0085 ("[IPV4] fib_trie: iterator recode")
[1] :
https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Otherwise, on neighbour creation, bond_neigh_init() will be called with a
foreign netdev.
Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
dev->ndo_neigh_setup() might need some of the values of neigh_parms, so
populate them before calling it.
Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 91657eafb ("xfrm: take net hdr len into account for esp payload
size calculation") introduced a possible interger overflow in
esp{4,6}_get_mtu() handlers in case of x->props.mode equals
XFRM_MODE_TUNNEL. Thus, the following expression will overflow
unsigned int net_adj;
...
<case ipv{4,6} XFRM_MODE_TUNNEL>
net_adj = 0;
...
return ((mtu - x->props.header_len - crypto_aead_authsize(esp->aead) -
net_adj) & ~(align - 1)) + (net_adj - 2);
where (net_adj - 2) would be evaluated as <foo> + (0 - 2) in an unsigned
context. Fix it by simply removing brackets as those operations here
do not need to have special precedence.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Benjamin Poirier <bpoirier@suse.de>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Acked-by: Benjamin Poirier <bpoirier@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vlan devices are LLTX and don't update their own trans_start, so if
dev_trans_start has to be called with a vlan device then 0 or a stale
value will be returned. Currently the bonding is the only such user, and
it's needed for proper arp monitoring when the slaves are vlans.
Fix this by extracting the vlan's real device trans_start.
Suggested-by: David Miller <davem@davemloft.net>
Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
Acked-by: Veaceslav Falico <vfalico@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Sometimes we might have stacked vlans on top of each other, and we're
interested in the first non-vlan real device on the path, so transform
vlan_dev_real_dev to go over the stacked vlans and extract the first
non-vlan device.
Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Firstly, nlmclnt_setlockargs can be called from a reclaimer thread, in
which case we're in entirely the wrong namespace.
Secondly, commit 8aac62706a (move
exit_task_namespaces() outside of exit_notify()) now means that
exit_task_work() is called after exit_task_namespaces(), which
triggers an Oops when we're freeing up the locks.
Fix this by ensuring that we initialise the nlm_host's rpc_client at mount
time, so that the cl_nodename field is initialised to the value of
utsname()->nodename that the net namespace uses. Then replace the
lockd callers of utsname()->nodename.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Toralf Förster <toralf.foerster@gmx.de>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Nix <nix@esperi.org.uk>
Cc: Jeff Layton <jlayton@redhat.com>
Cc: stable@vger.kernel.org # 3.10.x
There's an underlying race condition with the unjoin_work() call that is
sometimes triggered depending on scheduling order and the phase of the
moon. This doesn't fix the race condition, but it does remove the
ill-advised BUG_ON() call in an easily-recoverable situation.
Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Drop the semicolon at the end of the list_for_each_entry loop header.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Remove this code, per Dave Miller's request, since it is not being used
anywhere in the kernel.
Signed-off-by: Eli Cohen <eli@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit df8ef8f3aa
macvlan: add FDB bridge ops and macvlan flags
added a flags field to macvlan, which can be
controlled from userspace.
The idea is to make the interface future-proof
so we can add flags and not new fields.
However, flags value isn't validated, as a result,
userspace can't detect which flags are supported.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: John Fastabend <john.r.fastabend@intel.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
These structs have a "_pad" member. Also the "phw" structs have an 8
byte "hw_addr[]" array but sometimes only the first 6 bytes are
initialized.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
regcache_sync_block_raw_flush() expects the address of the register after last
register that needs to be synced as its parameter. But the last call to
regcache_sync_block_raw_flush() in regcache_sync_block_raw() passes the address
of the last register in the block. This effectively always skips over the last
register in a block, even if it needs to be synced. In order to fix it increase
the address by one register.
The issue was introduced in commit 75a5f89 ("regmap: cache: Write consecutive
registers in a single block write").
Cc: stable@vger.kernel.org # 3.10+
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
As comment in include/uapi/asm-generic/fcntl.h described, when
introducing new O_* bits, we need to check its uniqueness in
fcntl_init(). But __O_TMPFILE bit is missing. So fix it.
Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Every now and then someone proposes a new flink syscall, and this spawns
a long discussion of whether it would be a security problem. I think
that this is missing the point: flink is *already* allowed without
privilege as long as /proc is mounted -- it's called AT_SYMLINK_FOLLOW.
Now that O_TMPFILE is here, the ability to create a file with O_TMPFILE,
write it, and link it in is very convenient. The only problem is that
it requires that /proc be mounted so that you can do:
linkat(AT_FDCWD, "/proc/self/fd/<tmpfd>", dfd, path, AT_SYMLINK_NOFOLLOW)
This sucks -- it's much nicer to do:
linkat(tmpfd, "", dfd, path, AT_EMPTY_PATH)
Let's allow it.
If this turns out to be excessively scary, it we could instead require
that the inode in question be I_LINKABLE, but this seems pointless given
the /proc situation
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
O_TMPFILE, like O_CREAT, should respect the requested mode and should
create regular files.
This fixes two bugs: O_TMPFILE required privilege (because the mode
ended up as 000) and it produced bogus inodes with no type.
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Since remove_proc_entry() started to wait for IO in progress (i.e.
since 2007 or so), the locking in fs/reiserfs/proc.c became wrong;
if procfs read happens between the moment when umount() locks the
victim superblock and removal of /proc/fs/reiserfs/<device>/*,
we'll get a deadlock - read will wait for s_umount (in sget(),
called by r_start()), while umount will wait in remove_proc_entry()
for that read to finish, holding s_umount all along.
Fortunately, the same change allows a much simpler race avoidance -
all we need to do is remove the procfs entries in the very beginning
of reiserfs ->kill_sb(); that'll guarantee that pointer to superblock
will remain valid for the duration for procfs IO, so we don't need
sget() to keep the sucker alive. As the matter of fact, we can
get rid of the home-grown iterator completely, and use single_open()
instead.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
The hardware interrupt routing for boot CPU != 0 is wrong because it
will route all the hardware interrupts to TP0 which is not the one we
booted from. Fix this by properly checking which boot CPU we are booting
from and updating the right interrupt mask for the boot CPU. This fixes
booting on BCM3368 with bmips_smp_emabled = 0.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Cc: linux-mips@linux-mips.org
Cc: blogic@openwrt.org
Cc: jogo@openwrt.org
Cc: cernekee@gmail.com
Patchwork: https://patchwork.linux-mips.org/patch/5650/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The PNX8335_PCI_ETHERNET_INT macro is defined in
arch/mips/include/asm/mach-pnx833x/irq-mapping.h
only if CONFIG_SOC_PNX8335 is selected.
Fixes the following randconfig problem:
arch/mips/pnx833x/common/platform.c:210:12:
error: 'PNX8335_PIC_ETHERNET_INT' undeclared here
(not in a function)
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Acked-by: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5585/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
When CONFIG_PREEMPT is enabled, Linux will not be able to boot and warn:
[ 4.127825] ------------[ cut here ]------------
[ 4.133376] WARNING: at init/main.c:699 do_one_initcall+0x150/0x158()
[ 4.140738] initcall xen_init_events+0x0/0x10c returned with preemption imbalance
This is because xen_percpu_init uses get_cpu but doesn't have the corresponding
put_cpu.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
John McCalpin reports that the "drs_data" and "ncb_data" QPI
uncore events are missing the "extra bit" and always return zero
values unless the bit is properly set.
More details from him:
According to the Xeon E5-2600 Product Family Uncore Performance
Monitoring Guide, Table 2-94, about 1/2 of the QPI Link Layer events
(including the ones that "perf" calls "drs_data" and "ncb_data") require
that the "extra bit" be set.
This was confusing for a while -- a note at the bottom of page 94 says
that the "extra bit" is bit 16 of the control register.
Unfortunately, Table 2-86 clearly says that bit 16 is reserved and must
be zero. Looking around a bit, I found that bit 21 appears to be the
correct "extra bit", and further investigation shows that "perf" actually
agrees with me:
[root@c560-003.stampede]# cat /sys/bus/event_source/devices/uncore_qpi_0/format/event
config:0-7,21
So the command
# perf -e "uncore_qpi_0/event=drs_data/"
Is the same as
# perf -e "uncore_qpi_0/event=0x02,umask=0x08/"
While it should be
# perf -e "uncore_qpi_0/event=0x102,umask=0x08/"
I confirmed that this last version gives results that agree with the
amount of data that I expected the STREAM benchmark to move across the QPI
link in the second (cross-chip) test of the original script.
Reported-by: John McCalpin <mccalpin@tacc.utexas.edu>
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Cc: zheng.z.yan@intel.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Cc: Paul Mackerras <paulus@samba.org>
Cc: <stable@kernel.org>
Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1308021037280.26119@vincent-weaver-1.um.maine.edu
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Add some necessary braces that have been removed during driver cleanup.
This fixes the I2C prescaler calculation.
Signed-off-by: Michael Brunner <michael.brunner@kontron.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Recently we have been seing some reports about PIO mode not working properly.
- http://www.spinics.net/lists/linux-i2c/msg11985.html
- http://marc.info/?l=linux-i2c&m=137235593101385&w=2
- https://lkml.org/lkml/2013/6/24/430
Let's use DMA mode even for small transfers.
Without this patch, i2c reads the incorrect sgtl5000 version on a mx28evk when
touchscreen is enabled:
[ 5.856270] sgtl5000 0-000a: Device with ID register 0 is not a sgtl5000
[ 9.877307] sgtl5000 0-000a: ASoC: failed to probe CODEC -19
[ 9.883528] mxs-sgtl5000 sound.12: ASoC: failed to instantiate card -19
[ 9.892955] mxs-sgtl5000 sound.12: snd_soc_register_card failed (-19)
Cc: <stable@vger.kernel.org>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Lucas Stach <l.stach@pengutronix.de>
Acked-by: Marek Vasut <marex@denx.de>
[wsa: we have a proper solution for -next, so this non intrusive
solution is OK for now]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The following is needed as well to fix warning/error about shifting a 32 bit
value 32 bits which occurs if building on 32 bit platform caused by conversion
to using dma_addr_t
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
1) Fix a long term race in the IIO trigger handling.
This only effects cases where a single trigger is in use
by multiple devices.
2) ti_am335x fix an issue with incorrect data due to reading before
the sequencer is finished.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iQIcBAABAgAGBQJR/oKnAAoJEFSFNJnE9BaItqYP/0V7a+3mVr2mCGq0McyUmY+P
jQJ6+jg6Vv0RKajOKadv150qgQwrmCwE2Zgev8dmdrTajd/Ww0PiowUgmDSmacnE
L+Tl5YDCG2arcZs6QiuccSTbssH/U8JOraFkKtlAw3dObWzMagg5eFHOXmnduHEp
aY5O0v0eLySF1/1HaVkPFZ6zvWQnUh9ylnijqgZTT2JtUifuy2oR4Ib806G3ObU/
gUJFN+FbUgbSKSy5GeBVWGEAG5YS8Io6GcWtCI5gzIlwfOoL6G0cCSueuTqD1/WZ
R2uHi9irjNTmdysOlONvXRiKyZqPIFY2Th8DsfbrI5y5cm/hAXM0LeZLGmEosqKM
qYqdA3AIVCaVRguyqtwO4q5t/taPS+D08TfnpiKr75JfB4BO6w9fm6RLSxeBtzoQ
dAQhW/T4qooefDfe/x8Ol7AElVV5vNkJ82U2zoIOhWIcAHIFdUNGFI3Y4EAirEsh
aFFQRaHCInwWtIEISlEvHWc3e1LbMXQajHuSU6UKvOrcI4d9NJSGDzNb6xyRIKSb
zxeC8fxKLeJAtXj9iUrBBBn41cx5DZueGJzsuCtCUvApi/jujXWrxfDK0DaAodZ3
6anolfW59YfWuEaXDBa0Y041qG4NI/fOZbrd43sY+9Bg6ZlGq2jss0u9rvI2Xtn7
xhg2F75nFKKnv7JF7cRZ
=U1lS
-----END PGP SIGNATURE-----
Merge tag 'iio-fixes-for-3.11b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
Second round of IIO fixes for the 3.11 cycle.
1) Fix a long term race in the IIO trigger handling.
This only effects cases where a single trigger is in use
by multiple devices.
2) ti_am335x fix an issue with incorrect data due to reading before
the sequencer is finished.
There are several drivers in drivers/net/usb/ that
do not have specific MAINTAINERS that should have
emails forwarded to the linux-usb mailing list.
Add a section for those drivers.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hi Greg,
Here's two small fixes for 3.11. The first patch fixes a 5 second hang in
khubd after a USB device disconnect on some xHCI hosts. The second fixes a
build warning.
Sarah Sharp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJR+VdHAAoJEBMGWMLi1Gc54VsQAJojRfFC/mY5PUqapziInwcV
UF0Of17K4vTj+yByuAINLI+uvNSaTnSSb1nb9lu/K8jzpfO0Nx/pYEPZJ2WUeSOA
mBnY3ohbBG+GNvfMTuMpBw+PnM0BKoUcI/B+GwXwOCOjlqMcz0p1Ocgc3QYdI5Zg
sYDA/eLf9lUQw9wqdBh5YHVqNboeVy1E+f04aKsR52GSHxE2v/q4pAIV4ScuchlM
nxuiLucEM+uVkh4LtJHt1CHINH5dRqi7TQObw4wcn5YDFzj2ykiiHOe5bzvj1z4/
qTja4r8M+uCe27cTbd6DY4ZUrUgjhsEcBOQG+/20jgb8X1UtjEMYeOjykjypKqnC
L6JAJCEkLQH3Xt3BkJ8lMM4VlAdPIskc3GZGOzvU2cvlarI5nLISpmf/iZdD7uh0
HfPMbFyLnR8YCI/zcVrGcesCJxNwYQOFsoiyY3iWLAJArEWIHq9gkiy5hOcba9Vm
REZq5dd0bPxadUm6c4goM9EQYyogpLkwo3bMQDoqNBd0qQ1aqvDOcYindqdCD25F
k+Tdo58k7MnqqX2fjQXBFMJzvSRbQaXQQDreTSra9M3behckNoUc2aWRHQj4mWn5
oDdID4qYOgjTOcv8OxC/nIdEBzSOioxvHewr9RA5dRzv09w6ydkuRVkyF3hVaD83
S1YbGmEAW1RVVcu7buJm
=sAz1
-----END PGP SIGNATURE-----
Merge tag 'for-usb-linus-2013-07-31' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus
Sarah writes:
xhci: Misc bug fixes for 3.11.
Hi Greg,
Here's two small fixes for 3.11. The first patch fixes a 5 second hang in
khubd after a USB device disconnect on some xHCI hosts. The second fixes a
build warning.
Sarah Sharp
When renaming ll_poll to busy poll, I introduced a typo
in the name of the do-nothing placeholder for sk_busy_loop
and called it sk_busy_poll.
This broke compile when busy poll was not configured.
Cong Wang submitted a patch to fixed that.
This patch removes the now redundant, misspelled placeholder.
Signed-off-by: Eliezer Tamir <eliezer.tamir@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This old driver never checked for DMA mapping errors.
Causing splats with the new DMA mapping checks:
WARNING: at lib/dma-debug.c:937 check_unmap+0x47b/0x930()
skge 0000:01:09.0: DMA-API: device driver failed to check map
Add checks and unwind code.
Reported-by: poma <pomidorabelisima@gmail.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
If the _BCL package ordering is descending, the first level
(br->levels[2]) is likely to be 0, and if the number of levels
matches the number of steps, we might confuse a returned level to
mean the index.
For example:
current_level = max_level = 100
test_level = 0
returned level = 100
In this case 100 means the level, not the index, and _BCM failed.
Still, if the _BCL package ordering is descending, the index of
level 0 is also 100, so we assume _BQC is indexed, when it's not.
This causes all _BQC calls to return bogus values causing weird
behavior from the user's perspective. For example:
xbacklight -set 10; xbacklight -set 20;
would flash to 90% and then slowly down to the desired level (20).
The solution is simple; test anything other than the first level
(e.g. 1).
[rjw: Changelog]
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This was missed when splitting out the phy from the controller node in
commit 9dffe3be3f (ARM: tegra: modify ULPI reset GPIO properties).
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
This patch removes sti_secondary_start from _INIT section, there are 2
reason for this removal.
1. discarding such a small code does not save much, given the RAM
sizes.
2. Having this code discarded, creates corruption issue when we boot
smp-kernel with nrcpus=1 or with single cpu node in DT.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
This patch fixes cpu nodes with device_type = "cpu". This change was not
necessary before 3.10-rc7.
Without this patch STi SOCs does not boot as SMP.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
* Lager board: do not annotate gpio_buttons as __initdata
- This avoids accessing uninitialised memory if keys are pressed
after kernel initialisation completes.
- Bug introduced in gpio-keys were enabled in v3.11-rc1
* Bock-W board: fix SDHI0 PFC settings
- Allow detection of SD card
- Bug introduced in SDHI support was added in v3.11-rc1
* shdma: fixup sh_dmae_get_partial() calculation error
- Bug introduced in 2.6.34-rc1.
* armadillo800eva board: Don't request GPIO 166 in board code
- Allow use of touchscreen
- Bug introduced in v3.11-rc1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJR+GejAAoJENfPZGlqN0++NgAP/ie/7VKbb3gHzryz2biUufNQ
3dfr13qOXJoxf2FqM6X7lSeTYJrzIavJZkMvGVv3m6bo/EQnF8PuHOXA6HgcNiRD
EfXJDTS+1XUEf5cst+MqUeKLxmssRUKAFYGdGFjIShCtaZ3gBHDq3tM88kmK7V7e
nnDKRoSYg5nooGLP+8C7fife/aqlxqGB1IckEDYkS678sn1Qf66b564bo5ycijjS
xcQQMXsapfNtT97SRbXngPXUYMuwIA+zlhI7pCPA4OEgjByjtg99C/F/6+TqHH3J
vO7cMkTILUl3YpNnE4w8RDjFfRwe2GbnbEJziaQ0J8qblazSS+C/sRAV0OTMwpj2
/TepZSLP1oEngx2M4IPPDCHde4pLQDIdhmFwU3X/qIQlDXTj3PwbIK58D0Ap3uOW
rwjrtk+e+HVZ3yewOxnTj7itgZuDx4ItXzkmmzPftHF26mnyj1CdZ4DZPfXzIbZf
e/QEcgTLSUylgCTYNBpOmMMewVoHKAyaTixBa+XGQUgBP540DXFjvpMrYFsBVTQh
10ueUIEBicAFoQFkW4PJ61vqW4f9CzTUpnKZ4fLWr3pE/q6yPZ3/vQtqhJuT2jfz
AnfP1atxwH6wq1fknx+y2/6o0BtlJWzsyJ98nAb+K8+8MoqzF26qnr7kgXnZjFpz
4XQZK/HAKqi5wGTXqtT/
=B1WZ
-----END PGP SIGNATURE-----
Merge tag 'renesas-fixes2-for-v3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes
From Simon Horman:
Second round of Renesas ARM based SoC fixes for v3.11
* Lager board: do not annotate gpio_buttons as __initdata
- This avoids accessing uninitialised memory if keys are pressed
after kernel initialisation completes.
- Bug introduced in gpio-keys were enabled in v3.11-rc1
* Bock-W board: fix SDHI0 PFC settings
- Allow detection of SD card
- Bug introduced in SDHI support was added in v3.11-rc1
* shdma: fixup sh_dmae_get_partial() calculation error
- Bug introduced in 2.6.34-rc1.
* armadillo800eva board: Don't request GPIO 166 in board code
- Allow use of touchscreen
- Bug introduced in v3.11-rc1
* tag 'renesas-fixes2-for-v3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
ARM: shmobile: lager: do not annotate gpio_buttons as __initdata
ARM: shmobile: BOCK-W: fix SDHI0 PFC settings
shdma: fixup sh_dmae_get_partial() calculation error
ARM: shmobile: armadillo800eva: Don't request GPIO 166 in board code
Signed-off-by: Olof Johansson <olof@lixom.net>
