| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Pull x86 updates from Thomas Gleixner:
"A pile of regression fixes and updates:
- address the fallout of the patches which made the cpuid - nodeid
relation permanent: Handling of invalid APIC ids and preventing
pointless warning messages.
- force eager FPU when protection keys are enabled. Protection keys
are not generating FPU exceptions so they cannot work with the lazy
FPU mechanism.
- prevent force migration of interrupts which are not part of the CPU
vector domain.
- handle the fact that APIC ids are not updated in the ACPI/MADT
tables on physical CPU hotplug
- remove bash-isms from syscall table generator script
- use the hypervisor supplied APIC frequency when running on VMware"
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/pkeys: Make protection keys an "eager" feature
x86/apic: Prevent pointless warning messages
x86/acpi: Prevent LAPIC id 0xff from being accounted
arch/x86: Handle non enumerated CPU after physical hotplug
x86/unwind: Fix oprofile module link error
x86/vmware: Skip lapic calibration on VMware
x86/syscalls: Remove bash-isms in syscall table generator
x86/irq: Prevent force migration of irqs which are not in the vector domain
|
|
looking for duplicate ->iov_base makes sense only for
iovec-backed iterators; for kvec-backed ones it's pointless,
for bvec-backed ones it's pointless and broken on 32bit (we
walk through an array of struct bio_vec accessing them as if
they were struct iovec; works by accident on 64bit, but on
32bit it'll blow up) and for pipe-backed ones it's pointless
and ends up oopsing.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
by making sure we call iov_iter_advance() on original
iov_iter even if direct_IO (done on its copy) has returned 0.
It's a no-op for old iov_iter flavours and does the right thing
(== truncation of the stuff we'd allocated, but not filled) in
ITER_PIPE case. Failures (e.g. -EIO) get caught and dealt with
by cleanup in generic_file_read_iter().
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
Pull perf tooling updates from Thomas Gleixner:
- handle uretprobe placement proper on little endian PPC64
- fix buffer handling in libtraceevent
- add a missing pointer derefence in perf probe
- fix the build of host tools in cross builds
- fix Intel PT timestamp handling
- synchronize memcpy, cpufeatures and bpf headers with the kernel headers
- support for vendor supplied JSON files describing PMU events
- a new set of tool tips
- initial work for clang/llvm support
- address some style issues found by cppcheck
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (35 commits)
tools build: Add feature detection for g++
tools build: Support compiling C++ source file
perf top/report: Add tips about a list option
perf report/top: Add a tip about system-wide collection from all CPUs
perf report/top: Add a tip about source line numbers with overhead
tools: Synchronize tools/include/uapi/linux/bpf.h
tools: Synchronize tools/arch/x86/include/asm/cpufeatures.h
perf bench mem: Sync memcpy assembly sources with the kernel
perf jevents: Fix Intel JSON fixed counter conversions
tools lib traceevent: Fix kbuffer_read_at_offset()
perf intel-pt: Fix MTC timestamp calculation for large MTC periods
perf intel-pt: Fix estimated timestamps for cycle-accurate mode
perf uretprobe ppc64le: Fix probe location
perf pmu-events: Add Skylake frontend MSR support
perf pmu-events: Fix fixed counters on Intel
perf tools: Make alias matching case-insensitive
perf tools: Allow period= in perf stat CPU event descriptions.
perf tools: Add README for info on parsing JSON/map files
perf list jevents: Add support for event list topics
perf list: Support long jevents descriptions
...
|
|
Pull scheduler fix from Thomas Gleixner:
"A revert of a commit which pointelessly widened a preempt disabled
section which in turn caused might_sleep() to trigger.
The patch intended to prevent usage of smp_processor_id() in
preemptible context, but the usage in that case is fine because the
thread is pinned on a single cpu and therefore cannot be migrated off"
* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
Revert "sched/core: Do not use smp_processor_id() with preempt enabled in smpboot_thread_fn()"
|
|
Pull irq fixes from Thomas Gleixner:
"Two small kerneldoc fixes from Julia Lawall"
* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
irqchip/metag-ext: Improve function-level documentation
irqchip/vic: Improve function-level documentation
|
|
Pull timer fix from Thomas Gleixner:
"A single fix for a regression introduced in 4.8 which causes the
trace/perf clock to return random nonsense if CONFIG_DEBUG_TIMEKEEPING
is set"
* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
timekeeping: Fix __ktime_get_fast_ns() regression
|
|
Merge my system logging cleanups, triggered by the broken '\n' patches.
The line continuation handling has been broken basically forever, and
the code to handle the system log records was both confusing and
dubious. And it would do entirely the wrong thing unless you always had
a terminating newline, partly because it couldn't actually see whether a
message was marked KERN_CONT or not (but partly because the LOG_CONT
handling in the recording code was rather confusing too).
This re-introduces a real semantically meaningful KERN_CONT, and fixes
the few places I noticed where it was missing. There are probably more
missing cases, since KERN_CONT hasn't actually had any semantic meaning
for at least four years (other than the checkpatch meaning of "no log
level necessary, this is a continuation line").
This also allows the combination of KERN_CONT and a log level. In that
case the log level will be ignored if the merging with a previous line
is successful, but if a new record is needed, that new record will now
get the right log level.
That also means that you can at least in theory combine KERN_CONT with
the "pr_info()" style helpers, although any use of pr_fmt() prefixing
would make that just result in a mess, of course (the prefix would end
up in the middle of a continuing line).
* printk-cleanups:
printk: make reading the kernel log flush pending lines
printk: re-organize log_output() to be more legible
printk: split out core logging code into helper function
printk: reinstate KERN_CONT for printing continuation lines
|
|
After backporting commit ee44b4bc054a ("dlm: use sctp 1-to-1 API")
series to a kernel with an older workqueue which didn't use RCU yet, it
was noticed that we are freeing the workqueues in dlm_lowcomms_stop()
too early as free_conn() will try to access that memory for canceling
the queued works if any.
This issue was introduced by commit 0d737a8cfd83 as before it such
attempt to cancel the queued works wasn't performed, so the issue was
not present.
This patch fixes it by simply inverting the free order.
Cc: stable@vger.kernel.org
Fixes: 0d737a8cfd83 ("dlm: fix race while closing connections")
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David Teigland <teigland@redhat.com>
|
|
Merge the crypto tree to pull in vmx ghash fix.
|
|
Pull blk-mq CPU hotplug update from Jens Axboe:
"This is the conversion of blk-mq to the new hotplug state machine"
* 'for-4.9/block-smp' of git://git.kernel.dk/linux-block:
blk-mq: fixup "Convert to new hotplug state machine"
blk-mq: Convert to new hotplug state machine
blk-mq/cpu-notif: Convert to new hotplug state machine
|
|
Pull blk-mq irq/cpu mapping updates from Jens Axboe:
"This is the block-irq topic branch for 4.9-rc. It's mostly from
Christoph, and it allows drivers to specify their own mappings, and
more importantly, to share the blk-mq mappings with the IRQ affinity
mappings. It's a good step towards making this work better out of the
box"
* 'for-4.9/block-irq' of git://git.kernel.dk/linux-block:
blk_mq: linux/blk-mq.h does not include all the headers it depends on
blk-mq: kill unused blk_mq_create_mq_map()
blk-mq: get rid of the cpumask in struct blk_mq_tags
nvme: remove the post_scan callout
nvme: switch to use pci_alloc_irq_vectors
blk-mq: provide a default queue mapping for PCI device
blk-mq: allow the driver to pass in a queue mapping
blk-mq: remove ->map_queue
blk-mq: only allocate a single mq_map per tag_set
blk-mq: don't redistribute hardware queues on a CPU hotplug event
|
|
Pull device mapper updates from Mike Snitzer:
- various fixes and cleanups for request-based DM core
- add support for delaying the requeue of requests; used by DM
multipath when all paths have failed and 'queue_if_no_path' is
enabled
- DM cache improvements to speedup the loading metadata and the writing
of the hint array
- fix potential for a dm-crypt crash on device teardown
- remove dm_bufio_cond_resched() and just using cond_resched()
- change DM multipath to return a reservation conflict error
immediately; rather than failing the path and retrying (potentially
indefinitely)
* tag 'dm-4.9-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: (24 commits)
dm mpath: always return reservation conflict without failing over
dm bufio: remove dm_bufio_cond_resched()
dm crypt: fix crash on exit
dm cache metadata: switch to using the new cursor api for loading metadata
dm array: introduce cursor api
dm btree: introduce cursor api
dm cache policy smq: distribute entries to random levels when switching to smq
dm cache: speed up writing of the hint array
dm array: add dm_array_new()
dm mpath: delay the requeue of blk-mq requests while all paths down
dm mpath: use dm_mq_kick_requeue_list()
dm rq: introduce dm_mq_kick_requeue_list()
dm rq: reduce arguments passed to map_request() and dm_requeue_original_request()
dm rq: add DM_MAPIO_DELAY_REQUEUE to delay requeue of blk-mq requests
dm: convert wait loops to use autoremove_wake_function()
dm: use signal_pending_state() in dm_wait_for_completion()
dm: rename task state function arguments
dm: add two lockdep_assert_held() statements
dm rq: simplify dm_old_stop_queue()
dm mpath: check if path's request_queue is dying in activate_path()
...
|
|
Pull main rdma updates from Doug Ledford:
"This is the main pull request for the rdma stack this release. The
code has been through 0day and I had it tagged for linux-next testing
for a couple days.
Summary:
- updates to mlx5
- updates to mlx4 (two conflicts, both minor and easily resolved)
- updates to iw_cxgb4 (one conflict, not so obvious to resolve,
proper resolution is to keep the code in cxgb4_main.c as it is in
Linus' tree as attach_uld was refactored and moved into
cxgb4_uld.c)
- improvements to uAPI (moved vendor specific API elements to uAPI
area)
- add hns-roce driver and hns and hns-roce ACPI reset support
- conversion of all rdma code away from deprecated
create_singlethread_workqueue
- security improvement: remove unsafe ib_get_dma_mr (breaks lustre in
staging)"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma: (75 commits)
staging/lustre: Disable InfiniBand support
iw_cxgb4: add fast-path for small REG_MR operations
cxgb4: advertise support for FR_NSMR_TPTE_WR
IB/core: correctly handle rdma_rw_init_mrs() failure
IB/srp: Fix infinite loop when FMR sg[0].offset != 0
IB/srp: Remove an unused argument
IB/core: Improve ib_map_mr_sg() documentation
IB/mlx4: Fix possible vl/sl field mismatch in LRH header in QP1 packets
IB/mthca: Move user vendor structures
IB/nes: Move user vendor structures
IB/ocrdma: Move user vendor structures
IB/mlx4: Move user vendor structures
IB/cxgb4: Move user vendor structures
IB/cxgb3: Move user vendor structures
IB/mlx5: Move and decouple user vendor structures
IB/{core,hw}: Add constant for node_desc
ipoib: Make ipoib_warn ratelimited
IB/mlx4/alias_GUID: Remove deprecated create_singlethread_workqueue
IB/ipoib_verbs: Remove deprecated create_singlethread_workqueue
IB/ipoib: Remove deprecated create_singlethread_workqueue
...
|
|
Pull more rdma updates from Doug Ledford:
"Minor updates for rxe driver"
[ Starting to do merge window pulls again - the current -git tree does
appear to have some netfilter use-after-free issues, but I've sent
off the report to the proper channels, and I don't want to delay merge
window activity any more ]
* tag 'for-linus-2' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma:
IB/rxe: improved debug prints & code cleanup
rdma_rxe: Ensure rdma_rxe init occurs at correct time
IB/rxe: Properly honor max IRD value for rd/atomic.
IB/{rxe,core,rdmavt}: Fix kernel crash for reg MR
IB/rxe: Fix sending out loopback packet on netdev interface.
IB/rxe: Avoid scheduling tasklet for userspace QP
|
|
That will mean that any possible subsequent continuation will now be
broken up onto a line of its own (since reading the log has finalized
the beginning og the line), but if user space has activated system
logging (or if there's a kernel message dump going on) that is the right
thing to do.
And now that we actually get the continuation flags _right_ for this
all, the user space logger that is reading the kernel messages can
actually see the continuation marker. Not that anybody seems to really
bother with it (or care), but in theory user space can do its own
message stitching.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Avoid some duplicate logic now that we can return early, and update the
comments for the new LOG_CONT world order.
This also stops the continuation flushing from just using random record
flags for the flushing action, instead taking the flags from the proper
original line and updating them as we add continuations to it.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
The code that actually decides how to log the message (whether to put it
directly into the record log, whether to append it to an existing
buffered log, or whether to start a new buffered log) is fairly
non-obvious code in the middle of the vprintk_emit() function.
Splitting that code up into a helper function makes it easier to
understand, but perhaps more importantly also allows for the code to
just return early out of the helper function once it has made the
decision about where the new log content goes.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Long long ago the kernel log buffer was a buffered stream of bytes, very
much like stdio in user space. It supported log levels by scanning the
stream and noticing the log level markers at the beginning of each line,
but if you wanted to print a partial line in multiple chunks, you just
did multiple printk() calls, and it just automatically worked.
Except when it didn't, and you had very confusing output when different
lines got all mixed up with each other. Then you got fragment lines
mixing with each other, or with non-fragment lines, because it was
traditionally impossible to tell whether a printk() call was a
continuation or not.
To at least help clarify the issue of continuation lines, we added a
KERN_CONT marker back in 2007 to mark continuation lines:
474925277671 ("printk: add KERN_CONT annotation").
That continuation marker was initially an empty string, and didn't
actuall make any semantic difference. But it at least made it possible
to annotate the source code, and have check-patch notice that a printk()
didn't need or want a log level marker, because it was a continuation of
a previous line.
To avoid the ambiguity between a continuation line that had that
KERN_CONT marker, and a printk with no level information at all, we then
in 2009 made KERN_CONT be a real log level marker which meant that we
could now reliably tell the difference between the two cases.
5fd29d6ccbc9 ("printk: clean up handling of log-levels and newlines")
and we could take advantage of that to make sure we didn't mix up
continuation lines with lines that just didn't have any loglevel at all.
Then, in 2012, the kernel log buffer was changed to be a "record" based
log, where each line was a record that has a loglevel and a timestamp.
You can see the beginning of that conversion in commits
e11fea92e13f ("kmsg: export printk records to the /dev/kmsg interface")
7ff9554bb578 ("printk: convert byte-buffer to variable-length record buffer")
with a number of follow-up commits to fix some painful fallout from that
conversion. Over all, it took a couple of months to sort out most of
it. But the upside was that you could have concurrent readers (and
writers) of the kernel log and not have lines with mixed output in them.
And one particular pain-point for the record-based kernel logging was
exactly the fragmentary lines that are generated in smaller chunks. In
order to still log them as one recrod, the continuation lines need to be
attached to the previous record properly.
However the explicit continuation record marker that is actually useful
for this exact case was actually removed in aroundm the same time by commit
61e99ab8e35a ("printk: remove the now unnecessary "C" annotation for KERN_CONT")
due to the incorrect belief that KERN_CONT wasn't meaningful. The
ambiguity between "is this a continuation line" or "is this a plain
printk with no log level information" was reintroduced, and in fact
became an even bigger pain point because there was now the whole
record-level merging of kernel messages going on.
This patch reinstates the KERN_CONT as a real non-empty string marker,
so that the ambiguity is fixed once again.
But it's not a plain revert of that original removal: in the four years
since we made KERN_CONT an empty string again, not only has the format
of the log level markers changed, we've also had some usage changes in
this area.
For example, some ACPI code seems to use KERN_CONT _together_ with a log
level, and now uses both the KERN_CONT marker and (for example) a
KERN_INFO marker to show that it's an informational continuation of a
line.
Which is actually not a bad idea - if the continuation line cannot be
attached to its predecessor, without the log level information we don't
know what log level to assign to it (and we traditionally just assigned
it the default loglevel). So having both a log level and the KERN_CONT
marker is not necessarily a bad idea, but it does mean that we need to
actually iterate over potentially multiple markers, rather than just a
single one.
Also, since KERN_CONT was still conceptually needed, and encouraged, but
didn't actually _do_ anything, we've also had the reverse problem:
rather than having too many annotations it has too few, and there is bit
rot with code that no longer marks the continuation lines with the
KERN_CONT marker.
So this patch not only re-instates the non-empty KERN_CONT marker, it
also fixes up the cases of bit-rot I noticed in my own logs.
There are probably other cases where KERN_CONT will be needed to be
added, either because it is new code that never dealt with the need for
KERN_CONT, or old code that has bitrotted without anybody noticing.
That said, we should strive to avoid the need for KERN_CONT. It does
result in real problems for logging, and should generally not be seen as
a good feature. If we some day can get rid of the feature entirely,
because nobody does any fragmented printk calls, that would be lovely.
But until that point, let's at mark the code that relies on the hacky
multi-fragment kernel printk's. Not only does it avoid the ambiguity,
it also annotates code as "maybe this would be good to fix some day".
(That said, particularly during single-threaded bootup, the downsides of
KERN_CONT are very limited. Things get much hairier when you have
multiple threads going on and user level reading and writing logs too).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Sriharsha Basavapatna says:
====================
be2net: patch-set
The following patch set contains a few bug fixes.
Please consider applying this to the net-next tree.
Thanks.
Patch-1 Obtains proper PF number for BEx chips
Patch-2 Fixes a FW update issue seen with BEx chips
Patch-3 Updates copyright string
Patch-4 Fixes TX stats for TSO packets
Patch-5 Enables VF link state setting for BE3
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The VF link state setting feature now works on BE3 chips too from
FW ver 11.1.192.0 onwards.
Signed-off-by: Suresh Reddy <suresh.reddy@broadcom.com>
Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
TX stats update does not take into account headers which get duplicated
when the TSO packet is split into segments by HW. Fix this for both
tunneled (vxlan) and non-tunneled TSO packets.
Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch updates the year and company name in the copyright string
in be_hw.h.
Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The driver has a check to ensure that NCSI FW section is updated only
if the current FW version in the card supports it. This FW version check
is done using memcmp() which obviously fails in some cases. Fix this by
breaking up the version string into integer version components and
comparing them.
Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The driver gets the pf_num for Skyhawk and Lancer using
GET_FUNC_CONFIG FW command. But since that command is not
supported in BEx, we need to get it from some other command.
Otherwise TPE recovery would fail since all NIC PFs would
end up with a func num of 0. There's a pci function number
field in the response of GET_CNTL_ATTRIBUTES command that
can be read to get the same info for BEx adapters.
Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Introduction of the MTD pairing scheme concept.
|
|
|
|
|
|
|
|
|
|
Johan Hedberg says:
====================
pull request: bluetooth 2016-10-08
Here are a couple of Bluetooth fixes for the 4.9 kernel:
- Firmware download fix for Atheros controllers
- Fixes to the content of LE scan response
- New USB ID for a Marvell chipset
Please let me know if there are any issues pulling. Thanks.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Our XSAVE features are divided into two categories: those that
generate FPU exceptions, and those that do not. MPX and pkeys do
not generate FPU exceptions and thus can not be used lazily. We
disable them when lazy mode is forced on.
We have a pair of masks to collect these two sets of features, but
XFEATURE_MASK_PKRU was added to the wrong mask: XFEATURE_MASK_LAZY.
Fix it by moving the feature to XFEATURE_MASK_EAGER.
Note: this only causes problem if you boot with lazy FPU mode
(eagerfpu=off) which is *not* the default. It also only affects
hardware which is not currently publicly available. It looks like
eager mode is going away, but we still need this patch applied
to any kernel that has protection keys and lazy mode, which is 4.6
through 4.8 at this point, and 4.9 if the lazy removal isn't sent
to Linus for 4.9.
Fixes: c8df40098451 ("x86/fpu, x86/mm/pkeys: Add PKRU xsave fields and data structures")
Signed-off-by: Dave Hansen <dave.hansen@intel.com>
Cc: Dave Hansen <dave@sr71.net>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20161007162342.28A49813@viggo.jf.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
Markus reported that he sees new warnings:
APIC: NR_CPUS/possible_cpus limit of 4 reached. Processor 4/0x84 ignored.
APIC: NR_CPUS/possible_cpus limit of 4 reached. Processor 5/0x85 ignored.
This comes from the recent persistant cpuid - nodeid changes. The code
which emits the warning has been called prior to these changes only for
enabled processors. Now it's called for disabled processors as well to get
the possible cpu accounting correct. So if the kernel is compiled for the
number of actual available/enabled CPUs and the BIOS reports disabled CPUs
as well then the above warnings are printed.
That's a pointless exercise as it only makes sense if there are more CPUs
enabled than the kernel supports.
Nake the warning conditional on enabled processors so we are back to the
state before these changes.
Fixes: 8f54969dc8d6 ("x86/acpi: Introduce persistent storage for cpuid <-> apicid mapping")
Reported-and-tested-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: Dou Liyang <douly.fnst@cn.fujitsu.com>
Cc: linux-acpi@vger.kernel.org
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1610071549330.19804@nanos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
Yinghai reported that the recent changes to make the cpuid - nodeid
relationship permanent causes a cpuid ordering regression on a system which
has 2apic enabled..
The reason is that the ACPI local APIC parser has no sanity check for
apicid 0xff, which is an invalid id. So a CPU id for this invalid local
APIC id is allocated and therefor breaks the cpuid ordering.
Add a sanity check to acpi_parse_lapic() which ignores the invalid id.
Fixes: 8f54969dc8d6 ("x86/acpi: Introduce persistent storage for cpuid <-> apicid mapping")
Reported-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Gu Zheng <guz.fnst@cn.fujitsu.com>,
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: douly.fnst@cn.fujitsu.com,
Cc: zhugh.fnst@cn.fujitsu.com
Cc: Tony Luck <tony.luck@intel.com>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: Lv Zheng <lv.zheng@intel.com>,
Cc: robert.moore@intel.com
Cc: linux-acpi@vger.kernel.org
Link: https://lkml.kernel.org/r/CAE9FiQVQx6FRXT-RdR7Crz4dg5LeUWHcUSy1KacjR+JgU_vGJg@mail.gmail.com
|
|
Merge updates from Andrew Morton:
- fsnotify updates
- ocfs2 updates
- all of MM
* emailed patches from Andrew Morton <akpm@linux-foundation.org>: (127 commits)
console: don't prefer first registered if DT specifies stdout-path
cred: simpler, 1D supplementary groups
CREDITS: update Pavel's information, add GPG key, remove snail mail address
mailmap: add Johan Hovold
.gitattributes: set git diff driver for C source code files
uprobes: remove function declarations from arch/{mips,s390}
spelling.txt: "modeled" is spelt correctly
nmi_backtrace: generate one-line reports for idle cpus
arch/tile: adopt the new nmi_backtrace framework
nmi_backtrace: do a local dump_stack() instead of a self-NMI
nmi_backtrace: add more trigger_*_cpu_backtrace() methods
min/max: remove sparse warnings when they're nested
Documentation/filesystems/proc.txt: add more description for maps/smaps
mm, proc: fix region lost in /proc/self/smaps
proc: fix timerslack_ns CAP_SYS_NICE check when adjusting self
proc: add LSM hook checks to /proc/<tid>/timerslack_ns
proc: relax /proc/<tid>/timerslack_ns capability requirements
meminfo: break apart a very long seq_printf with #ifdefs
seq/proc: modify seq_put_decimal_[u]ll to take a const char *, not char
proc: faster /proc/*/status
...
|
|
Pull ARM SoC late DT updates from Arnd Bergmann:
"These updates have been kept in a separate branch mostly because they
rely on updates to the respective clk drivers to keep the shared
header files in sync.
- The Renesas r8a7796 (R-Car M3-W) platform gets added, this is an
automotive SoC similar to the ⅹ8a7795 chip we already support, but
the dts changes rely on a clock driver change that has been merged
for v4.9 through the clk tree.
- The Amlogic meson-gxbb (S905) platform gains support for a few
drivers merged through our tree, in particular the network and usb
driver changes are required and included here, and also the clk
tree changes.
- The Allwinner platforms have seen a large-scale change to their clk
drivers and the dts file updates must come after that. This
includes the newly added Nextthing GR8 platform, which is derived
from sun5i/A13.
- Some integrator (arm32) changes rely on clk driver changes.
- A single patch for lpc32xx has no such dependency but wasn't added
until just before the merge window"
* tag 'armsoc-late' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (99 commits)
ARM: dts: lpc32xx: add device node for IRAM on-chip memory
ARM: dts: sun8i: Add accelerometer to polaroid-mid2407pxe03
ARM: dts: sun8i: enable UART1 for iNet D978 Rev2 board
ARM: dts: sun8i: add pinmux for UART1 at PG
dts: sun8i-h3: add I2C0-2 peripherals to H3 SOC
dts: sun8i-h3: add pinmux definitions for I2C0-2
dts: sun8i-h3: associate exposed UARTs on Orange Pi Boards
dts: sun8i-h3: split off RTS/CTS for UART1 in seperate pinmux
dts: sun8i-h3: add pinmux definitions for UART2-3
ARM: dts: sun9i: a80-optimus: Disable EHCI1
ARM: dts: sun9i: cubieboard4: Add AXP806 PMIC device node and regulators
ARM: dts: sun9i: a80-optimus: Add AXP806 PMIC device node and regulators
ARM: dts: sun9i: cubieboard4: Declare AXP809 SW regulator as unused
ARM: dts: sun9i: a80-optimus: Declare AXP809 SW regulator as unused
ARM: dts: sun8i: Add touchscreen node for sun8i-a33-ga10h
ARM: dts: sun8i: Add touchscreen node for sun8i-a23-polaroid-mid2809pxe04
ARM: dts: sun8i: Add touchscreen node for sun8i-a23-polaroid-mid2407pxe03
ARM: dts: sun8i: Add touchscreen node for sun8i-a23-inet86dz
ARM: dts: sun8i: Add touchscreen node for sun8i-a23-gt90h
ARM64: dts: meson-gxbb-vega-s95: Enable USB Nodes
...
|
|
Pull ARM 64-bit DT updates from Arnd Bergmann:
"The 64-bit DT changes are surprisingly small this time, we only add
two SoC platforms: the ZTE ZX296718 Set-top-box SoC and the SocioNext
UniPhier LD11 TV SoC, each with their reference boards.
There are three new machines added for existing SoC platforms:
- The Marvell Armada 8040 development board is an impressive
quad-core Cortex-A72 machine with three 10gbit ethernet interfaces
- Qualcomms DragonBoard 820c single-board computer is their current
high-end phone platform in the 96boards form factor
- Rockchip: Tronsmart Orion r86 set-top-box is a popular mid-range
Android box based on the 8-core rk3368 SoC"
* tag 'armsoc-dt64' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (91 commits)
arm64: dts: berlin4ct: Add L2 cache topology
arm64: dts: berlin4ct: enable all wdt nodes unconditionally
arm64: dts: berlin4ct: switch to Cortex-A53 specific pmu nodes
arm64: dts: Add ZTE ZX296718 SoC dts and Makefile
arm64: dts: apm: Add DT node for APM X-Gene 2 CPU clocks
arm64: dts: apm: Add X-Gene SoC hwmon to device tree
arm64: dts: apm: Fix interrupt polarity for X-Gene PCIe legacy interrupts
arm64: dts: apm: Add APM X-Gene v2 SoC PMU DTS entries
arm64: dts: apm: Add APM X-Gene SoC PMU DTS entries
arm64: dts: marvell: enable MSI for PCIe on Armada 7K/8K
arm64: dts: ls2080a: Add 'dma-coherent' for ls2080a PCI nodes
arm64: dts: rockchip: add Type-C phy for RK3399
arm64: dts: rockchip: enable the gmac for rk3399 evb board
arm64: dts: rockchip: add the gmac needed node for rk3399
arm64: dts: rockchip: support the pmu node for rk3399
arm64: dts: rockchip: change all interrupts cells to 4 on rk3399 SoCs
arm64: dts: rockchip: add the tcpc for rk3399 power domain
arm64: dts: rockchip: add efuse0 device node for rk3399
arm64: dts: rockchip: configure PCIe support for rk3399-evb
arm64: dts: rockchip: add the PCIe controller support for RK3399
...
|
|
Pull ARM DT updates from Arnd Bergmann:
"These are as usual a very large number of mostly boring updates to
enable devices in existing machines, or to fix minor bugs. Notably, an
ongoing treewide effort to fix warnings caused by an update to the
device tree compiler. These are enabled with "make W=1" at the moment
but can hopefully become the default once all issues have been
addressed.
No new SoC platform is added this time around (Armada 395 and Orion
mv88f5181 are slight variations of existing ones), but a significant
number of new dts files are added, which I list by platform:
- Allwinner: Empire Electronix M712 and iNet d978 Rev2 tablets,
Orange Pi PC Plus, Orange Pi 2, Orange Pi Plus 2E, Orange Pi Lite,
Olimex A33-Olinuxino, and Nano Pi Neo single-board computers
- ARM Realview: all supported machines (ported from board files)
- Broadcom: BCM958525er, BCM958522er, BCM988312hr, BCM958623hr and
BCM958622hr reference boards for Northstar platform, Raspberry Pi
Zero single-board computer
- Marvell EBU: Netgear WNR854T router (ported from board file),
Armada 395 SoC platform and GP board Armada 390 DB development
board
- NXP i.MX: imx7s Warp7 reference board, Gateworks Ventana GW553x
single-board computer, Technologic Systems TS-4900 and Engicam
IMX6UL GEA M6UL computer-on-module, Inverse Path USB armory board
- Qualcomm: LG Nexus 5 Phone
- Renesas: r8a7792/wheat and r7s72100/rskrza1 development boards
- Rockchip: Rockchip RK3288 Fennec reference board, Firefly RK3288
Reload platform
- ST Microelectronics STi: B2260 (96boards) single-board computer
- TI Davinci: OMAP-L138 LCDK Development kit
- TI OMAP: beagleboard-x15 rev B1 single-board computer"
* tag 'armsoc-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (390 commits)
ARM: dts: sony-nsz-gs7: add missing unit name to /memory node
ARM: dts: chromecast: add missing unit name to /memory node
ARM: dts: berlin2q-marvell-dmp: add missing unit name to /memory node
ARM: dts: berlin2: Add missing unit name to /soc node
ARM: dts: berlin2cd: Add missing unit name to /soc node
ARM: dts: berlin2q: Add missing unit name to /soc node
ARM: dts: berlin2: Remove skeleton.dtsi inclusion
ARM: dts: berlin2cd: Remove skeleton.dtsi inclusion
ARM: dts: berlin2q: Remove skeleton.dtsi inclusion
arm: dts: berlin2q: enable all wdt nodes unconditionally
arm: dts: berlin2: enable all wdt nodes unconditionally
ARM: dts: omap5-igep0050.dts: Use tabs for indentation
ARM: dts: Fix igepv5 power button GPIO direction
ARM: dts: am335x-evmsk: Add blue-and-red-wiring -property to lcdc node
ARM: dts: am335x-evmsk: Whitespace cleanup of lcdc related nodes
ARM: dts: am335x-evm: Add blue-and-red-wiring -property to lcdc node
ARM: dts: s3c64xx: Use macros for pinctrl configuration
ARM: dts: s3c2416: Use macros for pinctrl configuration
ARM: dts: s5pv210: Use macros for pinctrl configuration
ARM: dts: s3c64xx: Use common macros for pinctrl configuration
...
|
|
Pull ARM SoC driver updates from Arnd Bergmann:
"Driver updates for ARM SoCs, including a couple of newly added
drivers:
- The Qualcomm external bus interface 2 (EBI2), used in some of their
mobile phone chips for connecting flash memory, LCD displays or
other peripherals
- Secure monitor firmware for Amlogic SoCs, and an NVMEM driver for
the EFUSE based on that firmware interface.
- Perf support for the AppliedMicro X-Gene performance monitor unit
- Reset driver for STMicroelectronics STM32
- Reset driver for SocioNext UniPhier SoCs
Aside from these, there are minor updates to SoC-specific bus,
clocksource, firmware, pinctrl, reset, rtc and pmic drivers"
* tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (50 commits)
bus: qcom-ebi2: depend on HAS_IOMEM
pinctrl: mvebu: orion5x: Generalise mv88f5181l support for 88f5181
clk: mvebu: Add clk support for the orion5x SoC mv88f5181
dt-bindings: EXYNOS: Add Exynos5433 PMU compatible
clocksource: exynos_mct: Add the support for ARM64
perf: xgene: Add APM X-Gene SoC Performance Monitoring Unit driver
Documentation: Add documentation for APM X-Gene SoC PMU DTS binding
MAINTAINERS: Add entry for APM X-Gene SoC PMU driver
bus: qcom: add EBI2 driver
bus: qcom: add EBI2 device tree bindings
rtc: rtc-pm8xxx: Add support for pm8018 rtc
nvmem: amlogic: Add Amlogic Meson EFUSE driver
firmware: Amlogic: Add secure monitor driver
soc: qcom: smd: Reset rx tail rather than tx
memory: atmel-sdramc: fix a possible NULL dereference
reset: hi6220: allow to compile test driver on other architectures
reset: zynq: add driver Kconfig option
reset: sunxi: add driver Kconfig option
reset: stm32: add driver Kconfig option
reset: socfpga: add driver Kconfig option
...
|
|
Pull ARM SoC 64-bit updates from Arnd Bergmann:
"Changes to platform code for 64-bit ARM platforms.
Nearly all of these are defconfig updates to enable new drivers or old
drivers still used on these 64-bit platforms.
Aside from that, we gain initial support for two set-top-box
platforms, both of which already have 32-bit support in arch/arm:
- Broadcom adds abstract support for the bcm7xxx/brcmstb platform,
presumably the respective dts files and more information will
follow at a later point.
- The ZTE ZX296718 SoC for set-top-boxes, a relative of the 32-bit
ZX296702 SoC that we already support"
* tag 'armsoc-arm64' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
arm64: add ZTE ZX SoC family
arm64: defconfig: enable ZTE ZX related config
arm64: defconfig: enable common modules for power management
arm64: defconfig: enable meson I2C
arm64: defconfig: enable meson SPI as module
arm64: defconfig: enable meson WDT as modules
arm64: defconfig: enable HW random as module
arm64: defconfig: Enable SDHI and GPIO_REGULATOR
arm64: configs: enable PCIe driver for Aardvark
Kconfig: ARCH_HISI: Add PINCTRL to HISI platform
arm64: defconfig: enable bluetooth supports as modules
arm64: defconfig: enable CONFIG_INPUT_HISI_POWERKEY for HiKey
arm64: defconfig: Enable HiSilicon kirin drm, adv7533 for HiKey
arm64: defconfig: Enable Hisi SAS and HNS
arm64: defconfig: Enable QDF2432 config options
arm64: sunxi: Kconfig: add essential pinctrl driver
arm64: defconfig: Add Renesas R-Car HSUSB driver support as module
arm64: Add Broadcom Set Top Box Kconfig entry point
arm64: defconfig: enable xhci-platform
|
|
Pull ARM SoC defconfig updates from Arnd Bergmann:
"Defconfig additions, removals, etc. Most of these are small changes
adding the options for newly upstreamed drivers, or drivers needed for
new board support. Nothing specifically sticks out this time"
* tag 'armsoc-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (25 commits)
ARM: multi_v7_defconfig: enable CONFIG_EFI
ARM: multi_v7_defconfig: Build Atmel maXTouch driver as a module
ARM: defconfig: update the Integrator defconfig
ARM: keystone: defconfig: Fix USB configuration
ARM: imx_v6_v7_defconfig: Select the wm8960 codec driver
ARM: omap2plus_defconfig: switch to the IIO BMP085 driver
ARM: mvebu_v5_defconfig: use MV88E6XXX
ARM: davinci_all_defconfig: Enable some UBI modules
ARM: davinci_all_defconfig: Enable AEMIF as a module
ARM: multi_v7_defconfig: Enable SECCOMP
ARM: exynos_defconfig: Enable SECCOMP
ARM: imx_v6_v7_defconfig: Add CONFIG_MPL3115
ARM: imx_v6_v7_defconfig: Enable GPU support
ARM: s3c2410_defconfig: Remove CONFIG_IPV6_PRIVACY
ARM: exynos_defconfig: Enable PM_DEBUG
ARM: exynos_defconfig: Enable bus frequency scaling with devfreq
ARM: imx_v6_v7_defconfig: enable more USB configurations
ARM: davinci_all_defconfig: enable SMSC ethernet PHY
ARM: davinci_all_defconfig: enable RTC driver as module
ARM: multi_v7_defconfig: Enable ARM_IMX6Q_CPUFREQ
...
|
|
Pull ARM SoC platform updates from Arnd Bergmann:
"These are updates for platform specific code on 32-bit ARM machines,
essentially anything that can not (yet) be expressed using DT files.
Noteworthy changes include:
- We get support for running in big-endian mode on two platforms:
sunxi (Allwinner) and s3c24xx (old Samsung).
- The recently added Uniphier platform now uses standard PSCI methods
for SMP booting and we remove support for old bootloader versions
that did not support it yet.
- In sunxi, we gain support for the "Nextthing GR8" SoC, which is a
close relative of the Allwinner A13 and R8 chips.
- PXA completes its move over to the generic dmaengine framework and
removes its old private API
- mach-bcm gains support for BCM47189/BCM53573, their first ARM SoC
with integrated 802.11ac wireless networking"
* tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (54 commits)
ARM: imx legacy: pca100: move peripheral initialization to .init_late
ARM: imx legacy: mx27ads: move peripheral initialization to .init_late
ARM: imx legacy: mx21ads: move peripheral initialization to .init_late
ARM: imx legacy: pcm043: move peripheral initialization to .init_late
ARM: imx legacy: mx35-3ds: move peripheral initialization to .init_late
ARM: imx legacy: mx27-3ds: move peripheral initialization to .init_late
ARM: imx legacy: imx27-visstrim-m10: move peripheral initialization to .init_late
ARM: imx legacy: vpr200: move peripheral initialization to .init_late
ARM: imx legacy: mx31moboard: move peripheral initialization to .init_late
ARM: imx legacy: armadillo5x0: move peripheral initialization to .init_late
ARM: imx legacy: qong: move peripheral initialization to .init_late
ARM: imx legacy: mx31-3ds: move peripheral initialization to .init_late
ARM: imx legacy: pcm037: move peripheral initialization to .init_late
ARM: imx legacy: mx31lilly: move peripheral initialization to .init_late
ARM: imx legacy: mx31ads: move peripheral initialization to .init_late
ARM: imx legacy: mx31lite: move peripheral initialization to .init_late
ARM: imx legacy: kzm: move peripheral initialization to .init_late
MAINTAINERS: update list of Oxnas maintainers
ARM: orion5x: remove extraneous NO_IRQ
ARM: orion: simplify orion_ge00_switch_init
...
|
|
Pull ARM SoC cleanups from Arnd Bergmann:
"The cleanups for v4.9 are a little larger that usual, but thankfully
that is almost exclusively due to removing a significant number of
files that have become obsolete after the still ongoing conversion of
old board files to devicetree.
- for mach-omap2, which is still the largest platform in arch/arm/,
the conversion to DT is finally complete after the Nokia N900 is
now fully supported there, along with the omap3 LDP, and we can
remove those two board files. If no regressions are found, another
large cleanup for the platform will happen as a follow-up, removing
dead code and restructuring the platform based on being DT-only.
- In mach-imx, similar work is ongoing, but has not come that far.
This time, we remove the obsolete board file for the i.MX1
generation, which like i.MX25, i.MX5, i.MX6, and i.MX7 is now
DT-only. The remaining board files are for i.MX2 and i.MX3 machines
based on old ARM926 or ARM1136 cores that should work with DT in
principle.
- realview has just been converted from board files to DT, and a lot
of code gets removed in the process. This is the last
ARM/Keil/Versatile derived platform that was still using board
files, the other ones being integrator, versatile and vexpress. We
can probably merge the remaining code into a single directory in
the near future.
- clps711x had completed the conversion in v4.8, but we accidentally
left the files in place that should have been deleted then"
* tag 'armsoc-cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (21 commits)
ARM: select PCI_DOMAINS config from ARCH_MULTIPLATFORM
ARM: stop *MIGHT_HAVE_PCI* config from being selected redundantly
ARM: imx: (trivial) fix typo and grammar
ARM: clps711x: remove extraneous files
ARM: imx: use IS_ENABLED() instead of checking for built-in or module
ARM: OMAP2+: use IS_ENABLED() instead of checking for built-in or module
ARM: OMAP1: use IS_ENABLED() instead of checking for built-in or module
ARM: imx: remove platform-mxc_rnga
ARM: realview: imply device tree boot
ARM: realview: no need to select SMP_ON_UP explicitly
ARM: realview: delete the RealView board files
ARM: imx: no need to select SMP_ON_UP explicitly
ARM: i.MX: Move SOC_IMX1 into 'Device tree only'
ARM: i.MX: Remove i.MX1 non-DT support
ARM: i.MX: Remove i.MX1 Synertronixx SCB9328 board support
ARM: i.MX: Remove i.MX1 Armadeus APF9328 board support
ARM: mxs: remove obsolete startup code for TX28
ARM: i.MX31 iomux: remove duplicates with alternate name
ARM: i.MX31 iomux: remove plain duplicates
ARM: OMAP2+: Drop legacy board file for LDP
...
|
|
Size used with 'dma_alloc_coherent()' and 'dma_free_coherent()' should be
consistent.
Here, the size of a pointer is used in dma_alloc... and the size of the
pointed structure is used in dma_free...
This has been spotted with coccinelle, using the following script:
////////////////////
@r@
expression x0, x1, y0, y1, z0, z1, t0, t1, ret;
@@
* ret = dma_alloc_coherent(x0, y0, z0, t0);
...
* dma_free_coherent(x1, y1, ret, t1);
@script:python@
y0 << r.y0;
y1 << r.y1;
@@
if y1.find(y0) == -1:
print "WARNING: sizes look different: '%s' vs '%s'" % (y0, y1)
////////////////////
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
To ensure the dev->phydev pointer is not used after becoming invalid in
mdiobus_unregister, set it to NULL. This happens when removing the macb
driver without first taking its interface down, since unregister_netdev
will end up calling macb_close.
Signed-off-by: Xander Huff <xander.huff@ni.com>
Signed-off-by: Nathan Sullivan <nathan.sullivan@ni.com>
Signed-off-by: Brad Mouring <brad.mouring@ni.com>
Reviewed-by: Moritz Fischer <moritz.fischer@ettus.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In the case when a frontend only negotiates a single queue with xen-
netback it is possible for a skbuff with a s/w hash to result in a
hash extra_info segment being sent to the frontend even when no hash
algorithm has been configured. (The ndo_select_queue() entry point makes
sure the hash is not set if no algorithm is configured, but this entry
point is not called when there is only a single queue). This can result
in a frontend that is unable to handle extra_info segments being given
such a segment, causing it to crash.
This patch fixes the problem by clearing the hash in ndo_start_xmit()
instead, which is clearly guaranteed to be called irrespective of the
number of queues.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Roundrobin runner of team driver uses 'unsigned int' variable to count
the number of sent_packets. Later it is passed to a subroutine
team_num_to_port_index(struct team *team, int num) as 'num' and when
we reach MAXINT (2**31-1), 'num' becomes negative.
This leads to using incorrect hash-bucket for port lookup
and as a result, packets are dropped. The fix consists of changing
'int num' to 'unsigned int num'. Testing of a fixed kernel shows that
there is no packet drop anymore.
Signed-off-by: Alex Sidorenko <alexandre.sidorenko@hpe.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Pull parisc updates from Helge Deller:
"Changes include:
- Fix boot of 32bit SMP kernel (initial kernel mapping was too small)
- Added hardened usercopy checks
- Drop bootmem and switch to memblock and NO_BOOTMEM implementation
- Drop the BROKEN_RODATA config option (and thus remove the relevant
code from the generic headers and files because parisc was the last
architecture which used this config option)
- Improve segfault reporting by printing human readable error strings
- Various smaller changes, e.g. dwarf debug support for assembly
code, update comments regarding copy_user_page_asm, switch to
kmalloc_array()"
* 'parisc-4.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc: Increase KERNEL_INITIAL_SIZE for 32-bit SMP kernels
parisc: Drop bootmem and switch to memblock
parisc: Add hardened usercopy feature
parisc: Add cfi_startproc and cfi_endproc to assembly code
parisc: Move hpmc stack into page aligned bss section
parisc: Fix self-detected CPU stall warnings on Mako machines
parisc: Report trap type as human readable string
parisc: Update comment regarding implementation of copy_user_page_asm
parisc: Use kmalloc_array() in add_system_map_addresses()
parisc: Check return value of smp_boot_one_cpu()
parisc: Drop BROKEN_RODATA config option
|
|
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
Linus Torvalds
Al Viro
Marcelo Ricardo Leitner
Herbert Xu
David S. Miller
Suresh Reddy
Sriharsha Basavapatna
Brian Norris
Dave Hansen
Thomas Gleixner
Christophe Jaillet
Nathan Sullivan
Paul Durrant
Alex Sidorenko