The kernel stack overflow is checked in stack_overflow_check(),
which may wrongly detect the overflow if the stack pointer in
user space points to the kernel stack intentionally or
accidentally. So, the actual overflow is never detected after
this misdetection because WARN_ONCE() is used on the detection
of it.
This patch adds user-mode-vm checking before it to avoid this
problem and bails out early if the user stack is used.
Signed-off-by: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
Cc: yrl.pp-manager.tt@hitachi.com
Cc: Randy Dunlap <rdunlap@xenotime.net>
Link: http://lkml.kernel.org/r/20111129060821.11076.55315.stgit@ltc219.sdl.hitachi.co.jp
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Commit 30765b92 ("slab, lockdep: Annotate the locks before using
them") moves the init_lock_keys() call from after g_cpucache_up =
FULL, to before it. And overlooks the fact that init_node_lock_keys()
tests for it and ignores everything !FULL.
Introduce a LATE stage and change the lockdep test to be <LATE.
Acked-by: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: stable@kernel.org
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
When you do:
$ perf record -e cycles,cycles,cycles noploop 10
You expect about 10,000 samples for each event, i.e., 10s at
1000samples/sec. However, this is not what's happening. You
get much fewer samples, maybe 3700 samples/event:
$ perf report -D | tail -15
Aggregated stats:
TOTAL events: 10998
MMAP events: 66
COMM events: 2
SAMPLE events: 10930
cycles stats:
TOTAL events: 3644
SAMPLE events: 3644
cycles stats:
TOTAL events: 3642
SAMPLE events: 3642
cycles stats:
TOTAL events: 3644
SAMPLE events: 3644
On a Intel Nehalem or even AMD64, there are 4 counters capable
of measuring cycles, so there is plenty of space to measure those
events without multiplexing (even with the NMI watchdog active).
And even with multiplexing, we'd expect roughly the same number
of samples per event.
The root of the problem was that when the event that caused the buffer
to become full was not the first event passed on the cmdline, the user
notification would get lost. The notification was sent to the file
descriptor of the overflowed event but the perf tool was not polling
on it. The perf tool aggregates all samples into a single buffer,
i.e., the buffer of the first event. Consequently, it assumes
notifications for any event will come via that descriptor.
The seemingly straight forward solution of moving the waitq into the
ringbuffer object doesn't work because of life-time issues. One could
perf_event_set_output() on a fd that you're also blocking on and cause
the old rb object to be freed while its waitq would still be
referenced by the blocked thread -> FAIL.
Therefore link all events to the ringbuffer and broadcast the wakeup
from the ringbuffer object to all possible events that could be waited
upon. This is rather ugly, and we're open to better solutions but it
works for now.
Reported-by: Stephane Eranian <eranian@google.com>
Finished-by: Stephane Eranian <eranian@google.com>
Reviewed-by: Stephane Eranian <eranian@google.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20111126014731.GA7030@quad
Signed-off-by: Ingo Molnar <mingo@elte.hu>
On AMD family 10h we see firmware bug messages like the following:
[Firmware Bug]: cpu 6, try to use APIC500 (LVT offset 0) for vector 0x10400, but the register is already in use for vector 0xf9 on another cpu
[Firmware Bug]: cpu 6, IBS interrupt offset 0 not available (MSRC001103A=0x0000000000000100)
[Firmware Bug]: using offset 1 for IBS interrupts
[Firmware Bug]: workaround enabled for IBS LVT offset
perf: AMD IBS detected (0x00000007)
We always see this, since the offsets are not assigned by the BIOS for
this family. Force LVT offset assignment in this case. If the OS
assignment fails, fallback to BIOS settings and try to setup this.
The fallback to BIOS settings weakens the family check since
force_ibs_eilvt_setup() may fail e.g. in case of virtual machines.
But setup may still succeed if BIOS offsets are correct.
Other families don't have a workaround implemented that assigns LVT
offsets. It's ok, to drop calling force_ibs_eilvt_setup() for that
families.
With the patch the [Firmware Bug] messages vanish. We see now:
IBS: LVT offset 1 assigned
perf: AMD IBS detected (0x00000007)
Signed-off-by: Robert Richter <robert.richter@amd.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20111109162225.GO12451@erda.amd.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Transitioning through an IEEE DCBX version from a CEE DCBX
and back (CEE->IEEE->CEE) may leave IEEE attributes programmed
in the hardware. DCB uses a bit field in the set routines to
determine which attributes PG, PFC, APP need to be reprogrammed.
This is needed because user flow allows queueing a series
of changes and then reprogramming the hardware with the
entire set in one operation.
When transitioning from IEEE DCBX mode back into CEE DCBX
mode the PG and PFC bits need to be set so the possibly
different CEE attributes get programmed into the device.
This patch fixes broken logic that was evaluating to 0
and never setting any bits. Further this removes some
checks for num_tc in set routines. This logic only worked
when the number of traffic classes and user priorities
were equal. This is no longer the case for X540 devices.
Besides we can trust user input in this case if the
device is incorrectly configured the DCB bandwidths will
be incorrectly mapped but no OOPs, BUG, or hardware
failure will occur.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
The order of operations is important in DCBnl set_all(). When FCoE
is configured it uses the up2tc map to learn which queues to configure
the hardware offloads on. Therefore we need to setup the map before
configuring FCoE.
This is only seen when the both up2tc mappings and APP info are
configured simultaneously.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
This patch updates the DMA Coalescing feature parameters to account for
larger MTUs. Previously, sufficient space may not have been allocated in
the receive buffer, causing packet drop.
Signed-off-by: Matthew Vick <matthew.vick@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Based on a patch from Mike McElroy created against the out-of-tree e1000e
driver:
Hitting the BUG_ON in napi_enable(). Code inspection shows that this can
only be triggered by calling napi_enable() twice without an intervening
napi_disable().
I saw the following sequence of events in the stack trace:
1) We simulated a cable pull using an Extreme switch.
2) e1000_tx_timeout() was entered.
3) e1000_reset_task() was called. Saw the message from e_err() in the
console log.
4) e1000_reinit_locked was called. This function calls e1000_down() and
e1000_up(). These functions call napi_disable() and napi_enable()
respectively.
5) Then on another thread, a monitor task saw carrier was down and executed
'ip set link down' and 'ip set link up' commands.
6) Saw the '_E1000_RESETTING'warning fron the e1000_close function.
7) Either the e1000_open() executed between the e1000_down() and e1000_up()
calls in step 4 or the e1000_open() call executed after the e1000_up()
call. In either case, napi_enable() is called twice which triggers the
BUG_ON.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Cc: Mike McElroy <mike.mcelroy@stratus.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Based on the original patch submitted my Michael Wang
<wangyun@linux.vnet.ibm.com>.
Descriptors may not be write-back while checking TX hang with flag
FLAG2_DMA_BURST on.
So when we detect hang, we just flush the descriptor and detect
again for once.
-v2 change 1 to true and 0 to false and remove extra ()
CC: Michael Wang <wangyun@linux.vnet.ibm.com>
CC: Flavio Leitner <fbl@redhat.com>
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Allow logical channels to specify the physical channel they want to use.
This is needed to avoid two peripherals operating on the same physical
channel during some special use-cases. (like mmc and usb during a
usb mass storage case).
Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
Signed-off-by: Narayanan G <narayanan.gopalakrishnan@stericsson.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
Currently, if plchan->phychan is true, we return immediately from
prep_phy_chan(). We must configure txd->ccfg and increment phychan_hold before
returning. Otherwise, request line number wouldn't be configured in this txd.
Reported-by: Rajeev Kumar <rajeev-dlh.kumar@st.com>
Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
This patch converts the drivers in drivers/dma/* to use the
module_platform_driver() macro which makes the code smaller and a bit
simpler.
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Piotr Ziecik <kosmo@semihalf.com>
Cc: Rongjun Ying <rongjun.ying@csr.com>
Cc: Barry Song <21cnbao@gmail.com>
Cc: Pelagicore AB <info@pelagicore.com>
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
When we use the SDMA in the UART driver(such as imx6q), we will
meet one situation:
Assume we set 64 bytes for the RX DMA buffer.
The RX DMA buffer has received some data, but not full.
An Aging DMA request will be received by the SDMA controller if we enable the
IDDMAEN(UCR4[6]) in this case.
So the UART driver needs to know the count of the real received bytes,
and push them to upper layer.
Add two new fields to sdmac, and update the `residue` in sdma_tx_status().
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
Setting the flags in case of IDE didn't have any effect since the control
register is overwritten few lines below. So move these to be after the control
register is initialized.
Signed-off-by: Rafal Prylowski <prylowski@metasoft.pl>
Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
SND_SOC_MX27VIS_AIC32X4 selects SND_SOC_TLV320AIC32X4,
but SND_SOC_TLV320AIC32X4 needs CONFIG_I2C.
So we need to make SND_SOC_MX27VIS_AIC32X4 depend on I2C.
otherwise I got below build error if CONFIG_I2C is not selected.
CC sound/soc/codecs/tlv320aic32x4.o
sound/soc/codecs/tlv320aic32x4.c: In function 'aic32x4_read':
sound/soc/codecs/tlv320aic32x4.c:323: error: implicit declaration of function 'i2c_smbus_read_byte_data'
sound/soc/codecs/tlv320aic32x4.c: In function 'aic32x4_probe':
sound/soc/codecs/tlv320aic32x4.c:641: error: 'i2c_master_send' undeclared (first use in this function)
sound/soc/codecs/tlv320aic32x4.c:641: error: (Each undeclared identifier is reported only once
sound/soc/codecs/tlv320aic32x4.c:641: error: for each function it appears in.)
sound/soc/codecs/tlv320aic32x4.c: In function 'aic32x4_modinit':
sound/soc/codecs/tlv320aic32x4.c:763: error: implicit declaration of function 'i2c_add_driver'
sound/soc/codecs/tlv320aic32x4.c: In function 'aic32x4_exit':
sound/soc/codecs/tlv320aic32x4.c:774: error: implicit declaration of function 'i2c_del_driver'
make[3]: *** [sound/soc/codecs/tlv320aic32x4.o] Error 1
make[2]: *** [sound/soc/codecs] Error 2
make[1]: *** [sound/soc] Error 2
make: *** [sound] Error 2
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
SND_SOC_RAUMFELD selects SND_SOC_CS4270 which needs CONFIG_I2C,
and also selects SND_SOC_AK4104 which needs SPI_MASTER.
Thus make SND_SOC_RAUMFELD depend on I2C && SPI_MASTER.
Add depend on SPI_MASTER to fix below build error if CONFIG_SPI_MASTER
is not selected.
LD .tmp_vmlinux1
sound/built-in.o: In function `ak4104_spi_write':
last.c:(.text+0x290cc): undefined reference to `spi_sync'
sound/built-in.o: In function `ak4104_probe':
last.c:(.text+0x292a0): undefined reference to `spi_write_then_read'
sound/built-in.o: In function `ak4104_spi_probe':
last.c:(.text+0x29398): undefined reference to `spi_setup'
sound/built-in.o: In function `ak4104_init':
last.c:(.init.text+0x4ec): undefined reference to `spi_register_driver'
make: *** [.tmp_vmlinux1] Error 1
Add depend on I2C to fix below build error if CONFIG_I2C is not selected:
CC sound/soc/codecs/cs4270.o
sound/soc/codecs/cs4270.c: In function 'cs4270_i2c_probe':
sound/soc/codecs/cs4270.c:657: error: implicit declaration of function 'i2c_smbus_read_byte_data'
sound/soc/codecs/cs4270.c: In function 'cs4270_init':
sound/soc/codecs/cs4270.c:730: error: implicit declaration of function 'i2c_add_driver'
sound/soc/codecs/cs4270.c: In function 'cs4270_exit':
sound/soc/codecs/cs4270.c:736: error: implicit declaration of function 'i2c_del_driver'
make[3]: *** [sound/soc/codecs/cs4270.o] Error 1
make[2]: *** [sound/soc/codecs] Error 2
make[1]: *** [sound/soc] Error 2
make: *** [sound] Error 2
SND_PXA2XX_SOC_HX4700 selects SND_SOC_AK4641 which needs CONFIG_I2C.
Thus make SND_PXA2XX_SOC_HX4700 depend on I2C.
Add depend on I2C to fix below build error if CONFIG_I2C is not selected:
CC sound/soc/codecs/ak4641.o
sound/soc/codecs/ak4641.c: In function 'ak4641_modinit':
sound/soc/codecs/ak4641.c:646: error: implicit declaration of function 'i2c_add_driver'
sound/soc/codecs/ak4641.c: In function 'ak4641_exit':
sound/soc/codecs/ak4641.c:656: error: implicit declaration of function 'i2c_del_driver'
make[3]: *** [sound/soc/codecs/ak4641.o] Error 1
make[2]: *** [sound/soc/codecs] Error 2
make[1]: *** [sound/soc] Error 2
make: *** [sound] Error 2
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Return proper error for uda1380_modinit if i2c_add_driver() fails.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
like rt6_lookup, but allows caller to pass in flowi6 structure.
Will be used by the upcoming ipv6 netfilter reverse path filter
match.
Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
This tries to do the same thing as fib_validate_source(), but differs
in several aspects.
The most important difference is that the reverse path filter built into
fib_validate_source uses the oif as iif when performing the reverse
lookup. We do not do this, as the oif is not yet known by the time the
PREROUTING hook is invoked.
We can't wait until FORWARD chain because by the time FORWARD is invoked
ipv4 forward path may have already sent icmp messages is response
to to-be-discarded-via-rpfilter packets.
To avoid the such an additional lookup in PREROUTING, Patrick McHardy
suggested to attach the path information directly in the match
(i.e., just do what the standard ipv4 path does a bit earlier in PREROUTING).
This works, but it also has a few caveats. Most importantly, when using
marks in PREROUTING to re-route traffic based on the nfmark, -m rpfilter
would have to be used after the nfmark has been set; otherwise the nfmark
would have no effect (because the route is already attached).
Another problem would be interaction with -j TPROXY, as this target sets an
nfmark and uses ACCEPT instead of continue, i.e. such a version of
-m rpfilter cannot be used for the initial to-be-intercepted packets.
In case in turns out that the oif is required, we can add Patricks
suggestion with a new match option (e.g. --rpf-use-oif) to keep ruleset
compatibility.
Another difference to current builtin ipv4 rpfilter is that packets subject to ipsec
transformation are not automatically excluded. If you want this, simply
combine -m rpfilter with the policy match.
Packets arriving on loopback interfaces always match.
Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
The reverse path filter module will use fib_lookup.
If CONFIG_IP_MULTIPLE_TABLES is not set, fib_lookup is
only a static inline helper that calls fib_table_lookup,
so export that too.
Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
People with old AMD chips are getting hung boots, because commit
bcb80e5387 ("x86, microcode, AMD: Add microcode revision to
/proc/cpuinfo") moved the microcode detection too early into
"early_init_amd()".
At that point we are *so* early in the booth that the exception tables
haven't even been set up yet, so the whole
rdmsr_safe(MSR_AMD64_PATCH_LEVEL, &c->microcode, &dummy);
doesn't actually work: if the rdmsr does a GP fault (due to non-existant
MSR register on older CPU's), we can't fix it up yet, and the boot fails.
Fix it by simply moving the code to a slightly later point in the boot
(init_amd() instead of early_init_amd()), since the kernel itself
doesn't even really care about the microcode patchlevel at this point
(or really ever: it's made available to user space in /proc/cpuinfo, and
updated if you do a microcode load).
Reported-tested-and-bisected-by: Larry Finger <Larry.Finger@lwfinger.net>
Tested-by: Bob Tracy <rct@gherkin.frus.com>
Acked-by: Borislav Petkov <borislav.petkov@amd.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch converts the drivers in drivers/sbus/char/* to use the
module_platform_driver() macro which makes the code smaller and a bit
simpler.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The semantic patch that makes this change is available
in scripts/coccinelle/api/memdup.cocci.
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
If our TCP_PAGE(sk) is not shared (page_count() == 1), we can set page
offset to 0.
This permits better filling of the pages on small to medium tcp writes.
"tbench 16" results on my dev server (2x4x2 machine) :
Before : 3072 MB/s
After : 3146 MB/s (2.4 % gain)
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We discovered that TCP stack could retransmit misaligned skbs if a
malicious peer acknowledged sub MSS frame. This currently can happen
only if output interface is non SG enabled : If SG is enabled, tcp
builds headless skbs (all payload is included in fragments), so the tcp
trimming process only removes parts of skb fragments, header stay
aligned.
Some arches cant handle misalignments, so force a head reallocation and
shrink headroom to MAX_TCP_HEADER.
Dont care about misaligments on x86 and PPC (or other arches setting
NET_IP_ALIGN to 0)
This patch introduces __pskb_copy() which can specify the headroom of
new head, and pskb_copy() becomes a wrapper on top of __pskb_copy()
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jenkins disables PCI so asm-generic provides inline
stubs for these, we don't need offline stubs as well.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The pci_iomap variant that arch/mn10300/unit-asb2305/pci-iomap.c
uses differs from the generic one in that it does
not use ioremap_nocache for PCI addresses.
However, it turns out that PCI addresses are
automatically noncached, so switching to ioremap_nocache
and to the generic implementation is safe.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
frv uses a version of pci_iomap that simply
casts and returns back the start address.
Looking closely, both ioremap and ioport_map seem to
do this on this platform, so the generic pci_iomap
will DTRT automatically.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
tile now has working stubs for ioport_map and ioremap
such that the generic pci_iomap will DTRT: cast to
pointer on memory and return NULL and log message on IO map.
Switch it over to GENERIC_PCI_IOMAP.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
I think panic on iomap is there just for debugging.
If we return NULL instead, the generic pci_iomap will
DTRT so we don't need to roll our own.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
sparc copied pci_iomap from generic code, probably to avoid
pulling the rest of iomap.c in. Since that's in
a separate file now, we can reuse the common implementation.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The advantage of kcalloc is, that will prevent integer overflows which could
result from the multiplication of number of elements and size and it is also
a bit nicer to read.
The semantic patch that makes this change is available
in https://lkml.org/lkml/2011/11/25/107
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
The advantage of kcalloc is, that will prevent integer overflows which could
result from the multiplication of number of elements and size and it is also
a bit nicer to read.
The semantic patch that makes this change is available
in https://lkml.org/lkml/2011/11/25/107
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
The advantage of kcalloc is, that will prevent integer overflows which could
result from the multiplication of number of elements and size and it is also
a bit nicer to read.
The semantic patch that makes this change is available
in https://lkml.org/lkml/2011/11/25/107
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
The advantage of kcalloc is, that will prevent integer overflows which could
result from the multiplication of number of elements and size and it is also
a bit nicer to read.
The semantic patch that makes this change is available
in https://lkml.org/lkml/2011/11/25/107
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Denys Fedoryshchenko reported that SYN+FIN attacks were bringing his
linux machines to their limits.
Dont call conn_request() if the TCP flags includes SYN flag
Reported-by: Denys Fedoryshchenko <denys@visp.net.lb>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
SND_SOC_LITTLEMILL selects SND_SOC_WM8994, but SND_SOC_WM8994 needs MFD_WM8994.
Thus we need to select MFD_WM8994 to fix below build error:
LD .tmp_vmlinux1
sound/built-in.o: In function `wm8994_write':
sound/soc/codecs/wm8994.c:201: undefined reference to `wm8994_reg_write'
sound/built-in.o: In function `wm8994_read':
sound/soc/codecs/wm8994.c:222: undefined reference to `wm8994_reg_read'
sound/built-in.o: In function `wm8994_resume':
sound/soc/codecs/wm8994.c:2847: undefined reference to `wm8994_reg_read'
sound/built-in.o: In function `wm8994_codec_probe':
sound/soc/codecs/wm8994.c:3501: undefined reference to `wm8994_reg_read'
sound/soc/codecs/wm8994.c:3660: undefined reference to `wm8994_reg_read'
sound/soc/codecs/wm8994.c:3672: undefined reference to `wm8994_reg_read'
sound/built-in.o: In function `wm8958_dsp2_fw':
sound/soc/codecs/wm8958-dsp2.c:154: undefined reference to `wm8994_bulk_write'
make: *** [.tmp_vmlinux1] Error 1
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
It's only used in net/ipv6/route.c and the NULL device check is
superfluous for all of the existing call sites.
Just expand the __ndisc_lookup_errno() call at each location.
Signed-off-by: David S. Miller <davem@davemloft.net>
1) x == NULL --> !x
2) x != NULL --> x
3) (x&BIT) --> (x & BIT)
4) (BIT1|BIT2) --> (BIT1 | BIT2)
5) proper argument and struct member alignment
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch fixes the checkpatch errors listed below:
ERROR: do not initialise statics to 0 or NULL
WARNING: Use #include <linux/io.h> instead of <asm/io.h>
WARNING: braces {} are not necessary for single statement blocks
WARNING: braces {} are not necessary for any arm of this statement
WARNING: static char array declaration should probably be static const char
WARNING: line over 80 characters
WARNING: msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.txt
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
