| Age | Commit message (Collapse) | Author |
|---|
|
Not all architectures (in particular, sparc64) have empty_zero_page.
So instead of copying from empty_zero_page, use memset to clear the
inline data by signalling to ext4_xattr_set_entry() via a magic
pointer value, EXT4_ZERO_ATTR_VALUE, which is defined by casting -1 to
a pointer.
This fixes a build failure on sparc64, and the memset() should be more
efficient than using memcpy() anyway.
Signed-off-by: Tao Ma <boyu.mt@taobao.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
This commit changes the CMA early initialization code to use phys_addr_t
for representing physical addresses instead of unsigned long.
Without this change, among other things, dma_declare_contiguous() simply
discards any memory regions whose address is not representable as unsigned
long.
This is a problem on 32-bit PAE machines where unsigned long is 32-bit
but physical address space is larger.
Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Cyril Chemparathy <cyril@ti.com>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
|
|
dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
regardless the flags provided by the caller. This causes excessive
pruning of emergency memory pools without any good reason. Additionaly,
on ARM architecture any driver which is using dmapools will sooner or
later trigger the following error:
"ERROR: 256 KiB atomic DMA coherent pool is too small!
Please increase it with coherent_pool= kernel parameter!".
Increasing the coherent pool size usually doesn't help much and only
delays such error, because all GFP_ATOMIC DMA allocations are always
served from the special, very limited memory pool.
This patch changes the dmapool code to correctly use gfp flags provided
by the dmapool caller.
Reported-by: Soeren Moch <smoch@web.de>
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Soeren Moch <smoch@web.de>
Cc: stable@vger.kernel.org
|
|
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
|
Some gate clocks have special needs which must be handled during the
disable-unused clocks sequence. These needs might be driven by software
due to the fact that we're disabling a clock outside of the normal
clk_disable path and a clk's enable_count will not be accurate. On the
other hand a specific hardware programming sequence might need to be
followed for this corner case.
This change is needed for the upcoming OMAP port to the common clock
framework. Specifically, it is undesirable to treat the disable-unused
path identically to the normal clk_disable path since other software
layers are involved. In this case OMAP's clockdomain code throws WARNs
and bails early due to the clock's enable_count being set to zero. A
custom callback mitigates this problem nicely.
Cc: Paul Walmsley <paul@pwsan.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
|
Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
This patch modifies the DVS register read function to select correct DVS1
register. This change is required because the GPIO select pin is 000 in
unintialized state and hence selects the DVS1 register.
Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The arch/arm64/Makefile was not passing the right target to the
boot/dts/Makefile.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
|
|
'warnings' into for-next
|
|
The REALVIEW EB board can host tiles with multiple cores thus needs
to be able to initialise SMP. There is, however, no .smp entry in
the MACHINE_START struct for REALVIEW_EB.
This patch adds the appropriate .smp entry to this struct.
Signed-off-by: Steve Capper <steve.capper@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
The kernel can only be entered on HYP mode on CPUs which actually
support it, i.e. >= ARMv7. pre-v6 platform support cannot coexist
in the same kernel as support for v7 and higher, so there is no
advantage in having the HYP mode check on pre-v6 hardware.
At least one pre-v6 board is known to fail when the HYP mode check
code is present, although the exact cause remains unknown and may
be unrelated. [1]
This patch restores the old behaviour for pre-v6 platforms, whereby
the CPSR is forced directly to SVC mode with IRQs and FIQs masked.
All kernels capable of booting on v7 hardware will retain the
check, so this should not impair functionality.
[1] http://lists.arm.linux.org.uk/lurker/message/20121130.013814.19218413.en.html
([ARM] head.S change broke platform device registration?)
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
The offset must be multiplied by 4 to be sure to access the correct
32bit word in the stack scratch space.
For instance, a store at scratch memory cell #1 was generating the
following:
st r4, [sp, #1]
While the correct code for this is:
st r4, [sp, #4]
To reproduce the bug (assuming your system has a NIC with the mac
address 52:54:00:12:34:56):
echo 0 > /proc/sys/net/core/bpf_jit_enable
tcpdump -ni eth0 "ether[1] + ether[2] - ether[3] * ether[4] - ether[5] \
== -0x3AA" # this will capture packets as expected
echo 1 > /proc/sys/net/core/bpf_jit_enable
tcpdump -ni eth0 "ether[1] + ether[2] - ether[3] * ether[4] - ether[5] \
== -0x3AA" # this will not.
This bug was present since the original inclusion of bpf_jit for ARM
(ddecdfce: ARM: 7259/3: net: JIT compiler for packet filters).
Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
syscall_trace_exit is currently doing things back-to-front; invoking
the audit hook *after* signalling the debugger, which presents an
opportunity for the registers to be re-written by userspace in order to
bypass auditing constaints.
This patch fixes the ordering by moving the audit code first and the
tracehook code last. On the face of it, it looks like
current_thread_info()->syscall may be incorrect for the sys_exit
tracepoint, but that's actually not an issue because it will have been
set during syscall entry and cannot have changed since then.
Reported-by: Andrew Gabbasov <Andrew_Gabbasov@mentor.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Not all the architectures have readsl/writesl,
use the more portable ioread32_rep/iowrite32_rep functions instead.
Signed-off-by: Davide Ciminaghi <ciminaghi@gnudd.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Official prototype for kzalloc is:
void *kzalloc(size_t, gfp_t);
The ARM bpf_jit code was having the assumption that it was:
void *kzalloc(gfp_t, size);
This was resulting the use of some random GFP flags depending on the
size requested and some random overflows once the really needed size
was more than the value of GFP_KERNEL.
This bug was present since the original inclusion of bpf_jit for ARM
(ddecdfce: ARM: 7259/3: net: JIT compiler for packet filters).
Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
The matrix-keymap module is currently lacking a proper module license,
add one so we don't have this module tainting the entire kernel. This
issue has been present since commit 1932811f426f ("Input: matrix-keymap
- uninline and prepare for device tree support")
Signed-off-by: Florian Fainelli <florian@openwrt.org>
CC: stable@vger.kernel.org # v3.5+
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Pull networking fixes from David Miller:
1) Netlink socket dumping had several missing verifications and checks.
In particular, address comparisons in the request byte code
interpreter could access past the end of the address in the
inet_request_sock.
Also, address family and address prefix lengths were not validated
properly at all.
This means arbitrary applications can read past the end of certain
kernel data structures.
Fixes from Neal Cardwell.
2) ip_check_defrag() operates in contexts where we're in the process
of, or about to, input the packet into the real protocols
(specifically macvlan and AF_PACKET snooping).
Unfortunately, it does a pskb_may_pull() which can modify the
backing packet data which is not legal if the SKB is shared. It
very much can be shared in this context.
Deal with the possibility that the SKB is segmented by using
skb_copy_bits().
Fix from Johannes Berg based upon a report by Eric Leblond.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
ipv4: ip_check_defrag must not modify skb before unsharing
inet_diag: validate port comparison byte code to prevent unsafe reads
inet_diag: avoid unsafe and nonsensical prefix matches in inet_diag_bc_run()
inet_diag: validate byte code to prevent oops in inet_diag_bc_run()
inet_diag: fix oops for IPv4 AF_INET6 TCP SYN-RECV state
|
|
* pci/mjg-pci-roms-from-efi:
PCI: Use phys_addr_t for physical ROM address
|
|
Since the aemif driver conversion to DT along with
its movement to drivers/ folder is not yet done,
fix NAND binding documentation to have NAND specific
DT details only.
Signed-off-by: Kumar, Anil <anilkumar.v@ti.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
into drm-next
Alex writes:
"adds support for the
asynchronous DMA engines on r6xx-SI. These engines are used
for ttm bo moves and VM page table updates currently. They
could also be exposed via the CS ioctl for userspace use,
but I haven't had a chance to add proper CS checker patches
for them yet. These patches have been tested extensively
internally for months, so they should be pretty solid."
* 'drm-next-3.8' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: use DMA engine for VM page table updates on SI
drm/radeon: add dma engine support for vm pt updates on si (v2)
drm/radeon: use DMA engine for VM page table updates on cayman/TN
drm/radeon: add dma engine support for vm pt updates on ni (v5)
drm/radeon: use async dma for ttm buffer moves on 6xx-SI
drm/radeon/kms: add support for dma rings to radeon_test_moves()
drm/radeon/kms: Add initial support for async DMA on SI
drm/radeon/kms: Add initial support for async DMA on cayman/TN
drm/radeon/kms: Add initial support for async DMA on evergreen
drm/radeon/kms: Add initial support for async DMA on r6xx/r7xx
|
|
The spi support code works on SPARC too. No reason to exclude it from
the party.
Signed-off-by: Andreas Larsson <andreas@gaisler.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
DMA engine has special packets to facilitate this and it also keeps
the 3D engine free for other things.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Async DMA has a special packet for contiguous pt updates
which saves overhead.
v2: rebase
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
DMA engine has special packets to facilitate this and it also keeps
the 3D engine free for other things.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Async DMA has a special packet for contiguous pt updates
which saves overhead.
v2: leave the CP method enabled for now as doing the updates
in the DMA rings is not working properly yet.
v3: update for 2 level pts
v4: rebase
v5: drop pte/pde packet. doesn't seem to work on NI.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The description for tcp_fin_timeout should be tigher and more clear.
In addition to being tighter, we should make the spelling of the
state name consistent with what utilities report, remove the now
dated reference to 2.2 and put the default in the consistent place.
Signed-off-by: Rick Jones <rick.jones2@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Pretty much the same as cayman. Some changes to the copy
packets.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
There are 2 async DMA engines on cayman, one at 0xd000 and
one at 0xd800. The programming interface is the same as
evergreen however there are some changes to the commands
for using vmids.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Pretty similar to 6xx/7xx except the count field increased in the
packet header and the max IB size increased.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Uses the new multi-ring infrastucture. 6xx/7xx has a single
async DMA ring.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Instead of updating stats before sending a packet,
update them after processing the packet's status.
This makes minstrel in line with minstrel_ht.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The support was already written, but the binding documentation was
lacking.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
This can lead to a panic if the driver isn't ready to
handle them. Since our interrupt line is shared, we can get
an interrupt at any time (and CONFIG_DEBUG_SHIRQ checks
that even when the interrupt is being freed).
If the op_mode has gone away, we musn't call it. To avoid
this the transport disables the interrupts when the hw is
stopped and the op_mode is leaving.
If there is an event that would cause an interrupt the INTA
register is updated regardless of the enablement of the
interrupts: even if the interrupts are disabled, the INTA
will be changed, but the device won't issue an interrupt.
But the ISR can be called at any time, so we ought ignore
the value in the INTA otherwise we can call the op_mode
after it was freed.
I found this bug when the op_mode_start failed, and called
iwl_trans_stop_hw(trans, true). Then I played with the
RFKILL button, and removed the module.
While removing the module, the IRQ is freed, and the ISR is
called (CONFIG_DEBUG_SHIRQ enabled). Panic.
Cc: stable@vger.kernel.org
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
We know that we have issues with the fw in the reclaim path.
This is why iwl_reclaim doesn't complain too loud when it
happens since it is recoverable. Somehow, the caller of
iwl_reclaim however WARNed when it happens. This doesn't
make any sense.
When I digged into the history of that code, I discovered
that this bug occurs only when we receive a BA notification.
So move the W/A in the BA notification handling code where
it was before.
This patch addresses:
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2387
Cc: stable@vger.kernel.org
Reported-by: Florian Reitmeir <florian@reitmeir.org>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The WARN_ON_ONCE() check for scan_request will not correctly detect
a NULL pointer for scan_type == IWL_SCAN_NORMAL. Make it explicit
that the check only applies to normal scans.
Convert WARN_ON_ONCE to WARN_ON since priv->scan_request really _can't_
be NULL for normal scans. If it is then we should emit frequent warnings.
This smatch warning led to scrutiny of iwlagn_request_scan():
drivers/net/wireless/iwlwifi/dvm/scan.c:894 iwlagn_request_scan() error: we previously assumed 'priv->scan_request' could be null (see line 792)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Flags being used by atomic operations in inode flags (e.g.
ext4_test_inode_flag(), should be consistent with that actually stored
in inodes, i.e.: EXT4_XXX_FL.
It ensures that this consistency is checked at build-time, not at
run-time.
Currently, the flags consistency are being checked at run-time, but,
there is no real reason to not do a build-time check instead of a
run-time check. The code is comparing macro defined values with enum
type variables, where both are constants, so, there is no problem in
comparing constants at build-time.
enum variables are treated as constants by the C compiler, according
to the C99 specs (see www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
sec. 6.2.5, item 16), so, there is no real problem in comparing an
enumeration type at build time
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
Ted has sent out a RFC about removing this feature. Eric and Jan
confirmed that both RedHat and SUSE enable this feature in all their
product. David also said that "As far as I know, it's enabled in all
Android kernels that use ext4." So it seems OK for us.
And what's more, as inline data depends its implementation on xattr,
and to be frank, I don't run any test again inline data enabled while
xattr disabled. So I think we should add inline data and remove this
config option in the same release.
[ The savings if you disable CONFIG_EXT4_FS_XATTR is only 27k, which
isn't much in the grand scheme of things. Since no one seems to be
testing this configuration except for some automated compile farms, on
balance we are better removing this config option, and so that it is
effectively always enabled. -- tytso ]
Cc: David Brown <davidb@codeaurora.org>
Cc: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Tao Ma <boyu.mt@taobao.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
We've originally added this in
commit 291427f5fdadec6e4be2924172e83588880e1539
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Fri Jul 29 12:42:37 2011 -0700
drm/i915: apply phase pointer override on SNB+ too
and then copy-pasted it over to ivb/ppt. The w/a was originally added
for ilk/ibx in
commit 5b2adf897146edeac6a1e438fb67b5a53dbbdf34
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Thu Oct 7 16:01:15 2010 -0700
drm/i915: add Ironlake clock gating workaround for FDI link training
and fixed up a bit in
commit 6f06ce184c765fd8d50669a8d12fdd566c920859
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Tue Jan 4 15:09:38 2011 -0800
drm/i915: set phase sync pointer override enable before setting phase sync pointer
It turns out that this w/a isn't actually required on cpt/ppt and
positively harmful on ivb/ppt when using fdi B/C links - it results in
a black screen occasionally, with seemingfully everything working as
it should. The only failure indication I've found in the hw is that
eventually (but not right after the modeset completes) a pipe underrun
is signalled.
Big thanks to Arthur Runyan for all the ideas for registers to check
and changes to test, otherwise I couldn't ever have tracked this down!
Cc: "Runyan, Arthur J" <arthur.j.runyan@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
ieee80211_free_txskb() needs to be used instead of dev_kfree_skb_any for
tx packets passed to the driver from mac80211
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
ieee80211_free_txskb() needs to be used instead of dev_kfree_skb_any for
tx packets passed to the driver from mac80211
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
