The "boxes" parameter points into userspace memory. It should be verified
like any other operation against user memory.
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Higher bits of the base address of framebuffers weren't being
programmed properly. This caused framebuffers that didn't happen to be
allocated at a low enough address to not be displayed properly.
Signed-off-by: Christopher Harvey <charvey@matrox.com>
Signed-off-by: Mathieu Larouche <mathieu.larouche@matrox.com>
Acked-by: Julia Lemire <jlemire@matrox.com>
Tested-by: Julia Lemire <jlemire@matrox.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Christopher Harvey <charvey@matrox.com>
Acked-by: Julia Lemire <jlemire@matrox.com>
Tested-by: Julia Lemire <jlemire@matrox.com>
Acked-by: Mathieu Larouche <mathieu.larouche@matrox.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The original line,
WREG_DAC(MGA1064_PIX_CLK_CTL_CLK_DIS, tmp);
wrote tmp into MGA1064_PIX_CLK_CTL_CLK_DIS, where
MGA1064_PIX_CLK_CTL_CLK_DIS is an offset into
MGA1064_PIX_CLK_CTL. Change the line to write properly into
MGA1064_PIX_CLK_CTL. There were other chunks of code nearby that use
the same pattern (but work correctly), so this patch updates them all
to use this new (slightly more efficient) write pattern. The WREG_DAC
macro was causing the DAC_INDEX register to be set to the same value
twice. WREG8(DAC_DATA, foo) takes advantage of the fact that DAC_INDEX
is already at the value we want.
Signed-off-by: Christopher Harvey <charvey@matrox.com>
Acked-by: Julia Lemire <jlemire@matrox.com>
Tested-by: Julia Lemire <jlemire@matrox.com>
Acked-by: Mathieu Larouche <mathieu.larouche@matrox.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Registers in indices below 0x18 are totally unrelated to modesetting,
so don't write 0's, or anything else into them on modeset. Most of
these registers are hardware cursor related, so this existing code
interferes with hardware cursor development.
Signed-off-by: Christopher Harvey <charvey@matrox.com>
Tested-by: Julia Lemire <jlemire@matrox.com>
Acked-by: Julia Lemire <jlemire@matrox.com>
Acked-by: Mathieu Larouche <mathieu.larouche@matrox.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Instead of just printing "status updated from 1 to 2", make those enum
numbers immediately readable.
v2: Also patch output_poll_execute() (Daniel Vetter)
v3: Use drm_get_connector_status_name (Ville Syrjälä)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (for v1)
Signed-off-by: Dave Airlie <airlied@redhat.com>
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Fix dev_pm_put_subsys_data() so that it doesn't call kfree() under
a spinlock and make it return 1 whenever it leaves NULL
power.subsys_data (regardless of the reason).
Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The driver can no longer be built as a module remove the compile fence
around cpufreq tracing call.
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Remove dead code from the driver.
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The ffmpeg benchmark in the phoronix test suite has threads on
multiple cores that rely on the progress on of threads on other cores
and ping pong back and forth fast enough to make the core appear less
busy than it "should" be. If the core has been at minimum p-state for
a while bump the pstate up to kick the core to see if it is in this
ping pong state. If the core is truly idle the p-state will be
reduced at the next sample time. If the core makes more progress it
will send more work to the thread bringing both threads out of the
ping pong scenario and the p-state will be selected normally.
This fixes a performance regression of approximately 30%
Cc: 3.9+ <stable@vger.kernel.org>
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There are two ways that the maximum p-state can be clamped, via a
policy change and via the sysfs file.
The acpi-thermal driver adjusts the p-state policy in response to
thermal events. These changes override the users settings at the
moment.
Use the lowest of the two requested values this ensures that we will
not exceed the requested pstate from either mechanism.
Reported-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Idle time is taken into account in the APERF/MPERF ratio calculation
there is no reason for the driver to track it seperately. This
reduces the work in the driver and makes the code more readable.
Removal of the tracking of sample duration removes the possibility of
the divide by zero exception when the duration is sub 1us
References: https://bugzilla.kernel.org/show_bug.cgi?id=56691
Reported-by: Mike Lothian <mike@fireburn.co.uk>
Cc: 3.9+ <stable@vger.kernel.org>
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Kconfig dependecies for ARM SA11xx drivers are incorrect, so fix
them.
[rjw: Changelog]
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This fixes usage of "depends on" and "select" options in Kconfig for ARM big
LITTLE cpufreq driver. Otherwise we get these warnings:
warning: (ARM_DT_BL_CPUFREQ) selects ARM_BIG_LITTLE_CPUFREQ which
has unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && ARM &&
ARM_CPU_TOPOLOGY)
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
We are freeing parent node in success cases but not in failure cases.
Let's do it.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
With commit 1e4b545, regulator_get will now return -EPROBE_DEFER
when the cpu0-supply node is present, but the regulator is not yet
registered.
It is possible for this to occur when the regulator registration
by itself might be defered due to some dependent interface not yet
instantiated. For example: an regulator which uses I2C and GPIO might
need both systems available before proceeding, in this case, the
regulator might defer it's registration.
However, the cpufreq-cpu0 driver assumes that any un-successful
return result is equivalent of failure.
When the regulator_get returns failure other than -EPROBE_DEFER, it
makes sense to assume that supply node is not present and proceed
with the assumption that only clock control is necessary in the
platform.
With this change, we can now handle the following conditions:
a) cpu0-supply binding is not present, regulator_get will return
appropriate error result, resulting in cpufreq-cpu0 driver
controlling just the clock.
b) cpu0-supply binding is present, regulator_get returns
-EPROBE_DEFER, we retry resulting in cpufreq-cpu0 driver
registering later once the regulator is available.
c) cpu0-supply binding is present, regulator_get returns
-EPROBE_DEFER, however, regulator never registers, we retry until
cpufreq-cpu0 driver fails to register pointing at device tree
information bug. However, in this case, the fact that
cpufreq-cpu0 operates with clock only when the DT binding clearly
indicates need of a supply is a bug of it's own.
d) cpu0-supply gets an regulator at probe - cpufreq-cpu0 driver
controls both the clock and regulator
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
We must call __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT) before
calling cpufreq_cpu_put(data), so that policy kobject have valid
fields. Otherwise, removing last online cpu of policy->cpus causes
this crash for ondemand/conservative governor.
[<c00fb076>] (sysfs_find_dirent+0xe/0xa8) from [<c00fb1bd>] (sysfs_get_dirent+0x21/0x58)
[<c00fb1bd>] (sysfs_get_dirent+0x21/0x58) from [<c00fc259>] (sysfs_remove_group+0x85/0xbc)
[<c00fc259>] (sysfs_remove_group+0x85/0xbc) from [<c02faad9>] (cpufreq_governor_dbs+0x369/0x4a0)
[<c02faad9>] (cpufreq_governor_dbs+0x369/0x4a0) from [<c02f66d7>] (__cpufreq_governor+0x2b/0x8c)
[<c02f66d7>] (__cpufreq_governor+0x2b/0x8c) from [<c02f6893>] (__cpufreq_remove_dev.isra.12+0x15b/0x250)
[<c02f6893>] (__cpufreq_remove_dev.isra.12+0x15b/0x250) from [<c03e91c7>] (cpufreq_cpu_callback+0x2f/0x3c)
[<c03e91c7>] (cpufreq_cpu_callback+0x2f/0x3c) from [<c0036fe1>] (notifier_call_chain+0x45/0x54)
[<c0036fe1>] (notifier_call_chain+0x45/0x54) from [<c001e611>] (__cpu_notify+0x1d/0x34)
[<c001e611>] (__cpu_notify+0x1d/0x34) from [<c03e5833>] (_cpu_down+0x63/0x1ac)
[<c03e5833>] (_cpu_down+0x63/0x1ac) from [<c03e5997>] (cpu_down+0x1b/0x30)
[<c03e5997>] (cpu_down+0x1b/0x30) from [<c03e60eb>] (store_online+0x27/0x54)
[<c03e60eb>] (store_online+0x27/0x54) from [<c0295629>] (dev_attr_store+0x11/0x18)
[<c0295629>] (dev_attr_store+0x11/0x18) from [<c00f9edd>] (sysfs_write_file+0xed/0x114)
[<c00f9edd>] (sysfs_write_file+0xed/0x114) from [<c00b42a9>] (vfs_write+0x65/0xd8)
[<c00b42a9>] (vfs_write+0x65/0xd8) from [<c00b4523>] (sys_write+0x2f/0x50)
[<c00b4523>] (sys_write+0x2f/0x50) from [<c000cdc1>] (ret_fast_syscall+0x1/0x52)
Of course this only impacted drivers which have
have_governor_per_policy set to true. i.e. big LITTLE cpufreq driver.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There are two types of INIT/EXIT activities that we need to do for
governors:
- Done only once per governor (doesn't depend how many instances of
the governor there are). eg: cpufreq_register_notifier() for
conservative governor.
- Done per governor instance, eg: sysfs_{create|remove}_group().
There were some corner cases where current code isn't able to handle
them separately and so failing for some test cases.
We use two separate variables now for keeping track of above two
requirements.
- governor->initialized for first one
- dbs_data->usage_count for per governor instance
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The message printed at the end of driver->init() doesn't include the
"cpufreq" string at all and so is difficult to find in dmesg. Add
function name to that message to clearly state where the message is
coming from.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The cpu_to_cluster() function may be used by glue drivers, so it's
better to keep it in arm_big_little.h.
[rjw: Changelog]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
If "/cpus" node isn't present or "clock-latency" isn't defined we are
returning error currently. Let's return CPUFREQ_ETERNAL instead, so
that we don't fail.
Flag appropriate messages to user in such cases.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
By mistake we are returning zero for successful call to
dt_get_transition_latency(), whereas we should return
transition_latency. Fix that.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The ARM big LITTLE cpufreq driver uses the OPP layer for its
functionality. Select it in Kconfig.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The Thinkpad e530's BIOS notifies the AC device first and then
sleeps for certain amount of time before doing real work in the
EC event handler (_Qxx):
Method (_Q27, 0, NotSerialized)
{
Notify (AC, 0x80)
Sleep (0x03E8)
Store (Zero, PWRS)
PNOT ()
}
This causes the AC driver to report an outdated AC state to user
space, because it reads the state information from the device while
the EC handler is sleeping.
Introduce a quirk to cause the AC driver to wait in acpi_ac_notify()
before calling acpi_ac_get_state() on systems known to have this
problem and add Thinkpad e530 to the list of quirky machines (with
a 1s delay which has been verified to be sufficient for that
machine).
[rjw: Changelog]
References: https://bugzilla.kernel.org/show_bug.cgi?id=45221
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The EC driver works abnormally with IBF flag always set.
IBF means "The host has written a byte of data to the command
or data port, but the embedded controller has not yet read it".
If IBF is set in the EC status and not cleared, this will cause
all subsequent EC requests to fail with a timeout error.
Change the EC driver so that it doesn't refuse to restart a
transaction if IBF is set in the status. Also increase the
number of transaction restarts to 5, as it turns out that 2
is not sufficient in some cases.
This bug happens on several different machines (Asus V1S,
Dell Latitude E6530, Samsung R719, Acer Aspire 5930G,
Sony Vaio SR19VN and others).
[rjw: Changelog]
References: https://bugzilla.kernel.org/show_bug.cgi?id=14733
References: https://bugzilla.kernel.org/show_bug.cgi?id=15560
References: https://bugzilla.kernel.org/show_bug.cgi?id=15946
References: https://bugzilla.kernel.org/show_bug.cgi?id=42945
References: https://bugzilla.kernel.org/show_bug.cgi?id=48221
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Cc: All <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
On HP 1000 lapops, BIOS reports minimum backlight on boot and
causes backlight to dim completely. This ignores the initial backlight
values and set to max brightness.
References:: https://bugs.launchpad.net/bugs/1167760
Signed-off-by: Alex Hung <alex.hung@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Fixes warning during compilation with clang.
[rjw: Subject and changelog]
Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The system suspend routine of the ACPI processor driver saves
the BUS_MASTER_RLD register and its resume routine restores it.
However, there can be only one such register in the system and it
really should be saved after non-boot CPUs have been offlined and
restored before they are put back online during resume.
For this reason, move the saving and restoration of BUS_MASTER_RLD
to syscore suspend and syscore resume, respectively, and drop the no
longer necessary suspend/resume callbacks from the ACPI processor
driver.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Prarit reported a crash on CPU offline/online. The reason is that on
CPU down the NOHZ related per cpu data of the dead cpu is not cleaned
up. If at cpu online an interrupt happens before the per cpu tick
device is registered the irq_enter() check potentially sees stale data
and dereferences a NULL pointer.
Cleanup the data after the cpu is dead.
Reported-by: Prarit Bhargava <prarit@redhat.com>
Cc: stable@vger.kernel.org
Cc: Mike Galbraith <bitbucket@online.de>
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1305031451561.2886@ionos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Overtemperature and hysteresis registers only exist for primary
temperature registers, not for alternates, so do not assign
those registers when initializing alternates.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
We forget to call dev_put() on error path in xfrm6_fill_dst(),
its caller doesn't handle this.
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There is a hole in struct ip6_tnl_parm2, so we have to
zero the struct on stack before copying it to user-space.
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since commit 82dc3c63c6 ("net: introduce NAPI_POLL_WEIGHT")
we warn drivers when they use napi weight higher than NAPI_POLL_WEIGHT,
but virtio_net still uses 128 by default. This patch makes its default
value to NAPI_POLL_WEIGHT.
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix EMAC soft reset on 460EX/GT to select the right PHY clock source
before and after the soft reset.
EMAC with PHY should use the clock from PHY during soft reset.
EMAC without PHY should use the internal clock during soft reset.
PPC460EX/GT Embedded Processor Advanced User's Manual
section 28.10.1 Mode Register 0 (EMACx_MR0) states:
Note: The PHY must provide a TX Clk in order to perform a soft reset
of the EMAC. If none is present, select the internal clock
(SDR0_ETH_CFG[EMACx_PHY_CLK] = 1).
After a soft reset, select the external clock.
Without the fix, 460EX/GT-based boards with RGMII PHYs attached to
EMACs experience EMAC interrupt storm and system watchdog reset when
issuing "ifconfig eth0 down" + "ifconfig eth0 up" a few times.
The system enters endless loop of serving emac_irq() with EMACx_ISR
register stuck at value 0x10000000 (Rx parity error).
With the fix, the above issue is no longer observed.
Signed-off-by: Petri Gynther <pgynther@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The driver wrongly claimed I/O ports at an address returned by pci_iomap() --
even if it was passed an MMIO address. Fix this by claiming/releasing all PCI
resources in the PCI driver's probe()/remove() methods instead and get rid of
'must_free_region' flag weirdness (why would Cardbus claim anything for us?).
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
kprobes up to par with the latest changes to ftrace (multi buffering
and the new function probes).
He also discovered and fixed some bugs in doing so. When pulling in his
patches, I also found a few minor bugs as well and fixed them.
This also includes a compile fix for some archs that select the ring buffer
but not tracing.
I based this off of the last patch you took from me that fixed the merge
conflict error, as that was the commit that had all the changes I needed
for this set of changes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAABAgAGBQJRjYnJAAoJEOdOSU1xswtMg9EH/iFs438FgrNMk2ZdQftmqcqA
cqcactHo1mmoHjAoLZT/oDBjEThhVUuqzMXrFRutSYcTh4PsQEC3arX0mpsC+T12
UEEV/tZS3TXH+GXEyrOit/O3kzntQcDHwJDV4+0n80IrJmw4IDZbnV3R8DWjS6wp
so+dq0A1pwehcG/upgpw1oTKsGv1G/p6vyf968B6W44icHEClLiph4JE2kzE6D3r
fzSpOLaQoBEvwIRf6xRKxi240VqIItXwfG7pwNpPpSC37gRLzm74zGr+Sj93/k1y
pARbZ/5XO7/pcVYQYupErRAoV5in+QMZ67k5G1vQIvyOS9r039catbQf/7PkzcI=
=EZCE
-----END PGP SIGNATURE-----
Merge tag 'trace-fixes-v3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull tracing/kprobes update from Steven Rostedt:
"The majority of these changes are from Masami Hiramatsu bringing
kprobes up to par with the latest changes to ftrace (multi buffering
and the new function probes).
He also discovered and fixed some bugs in doing so. When pulling in
his patches, I also found a few minor bugs as well and fixed them.
This also includes a compile fix for some archs that select the ring
buffer but not tracing.
I based this off of the last patch you took from me that fixed the
merge conflict error, as that was the commit that had all the changes
I needed for this set of changes."
* tag 'trace-fixes-v3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing/kprobes: Support soft-mode disabling
tracing/kprobes: Support ftrace_event_file base multibuffer
tracing/kprobes: Pass trace_probe directly from dispatcher
tracing/kprobes: Increment probe hit-count even if it is used by perf
tracing/kprobes: Use bool for retprobe checker
ftrace: Fix function probe when more than one probe is added
ftrace: Fix the output of enabled_functions debug file
ftrace: Fix locking in register_ftrace_function_probe()
tracing: Add helper function trace_create_new_event() to remove duplicate code
tracing: Modify soft-mode only if there's no other referrer
tracing: Indicate enabled soft-mode in enable file
tracing/kprobes: Fix to increment return event probe hit-count
ftrace: Cleanup regex_lock and ftrace_lock around hash updating
ftrace, kprobes: Fix a deadlock on ftrace_regex_lock
ftrace: Have ftrace_regex_write() return either read or error
tracing: Return error if register_ftrace_function_probe() fails for event_enable_func()
tracing: Don't succeed if event_enable_func did not register anything
ring-buffer: Select IRQ_WORK
If NO_DMA=y:
drivers/built-in.o: In function `cfv_destroy_genpool':
drivers/net/caif/caif_virtio.c:364: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `cfv_create_genpool':
drivers/net/caif/caif_virtio.c:397: undefined reference to `dma_alloc_coherent'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Dmitry Tarnyagin <dmitry.tarnyagin@lockless.no>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
If NO_DMA=y:
drivers/built-in.o: In function `macb_free_consistent':
drivers/net/ethernet/cadence/macb.c:878: undefined reference to `dma_free_coherent'
drivers/net/ethernet/cadence/macb.c:883: undefined reference to `dma_free_coherent'
drivers/net/ethernet/cadence/macb.c:888: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `macb_alloc_consistent':
drivers/net/ethernet/cadence/macb.c:905: undefined reference to `dma_alloc_coherent'
drivers/built-in.o: In function `macb_tx_interrupt':
drivers/net/ethernet/cadence/macb.c:515: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `macb_tx_error_task':
drivers/net/ethernet/cadence/macb.c:457: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `macb_start_xmit':
drivers/net/ethernet/cadence/macb.c:838: undefined reference to `dma_map_single'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If NO_DMA=y:
drivers/built-in.o: In function `at91ether_start':
drivers/net/ethernet/cadence/at91_ether.c:49: undefined reference to `dma_alloc_coherent'
drivers/net/ethernet/cadence/at91_ether.c:60: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `at91ether_interrupt':
drivers/net/ethernet/cadence/at91_ether.c:250: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `at91ether_start_xmit':
drivers/net/ethernet/cadence/at91_ether.c:169: undefined reference to `dma_map_single'
drivers/built-in.o: In function `at91ether_close':
drivers/net/ethernet/cadence/at91_ether.c:145: undefined reference to `dma_free_coherent'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If NO_DMA=y:
drivers/built-in.o: In function `ath9k_beacon_generate':
drivers/net/wireless/ath/ath9k/beacon.c:146: undefined reference to `dma_unmap_single'
drivers/net/wireless/ath/ath9k/beacon.c:174: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath9k/beacon.c:176: undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `ath9k_beacon_remove_slot':
drivers/net/wireless/ath/ath9k/beacon.c:252: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `ath_descdma_setup':
drivers/net/wireless/ath/ath9k/init.c:382: undefined reference to `dmam_alloc_coherent'
drivers/built-in.o: In function `ath_edma_get_buffers':
drivers/net/wireless/ath/ath9k/recv.c:616: undefined reference to `dma_sync_single_for_cpu'
drivers/built-in.o: In function `ath_get_next_rx_buf':
drivers/net/wireless/ath/ath9k/recv.c:740: undefined reference to `dma_sync_single_for_cpu'
drivers/built-in.o: In function `ath_rx_edma_cleanup':
drivers/net/wireless/ath/ath9k/recv.c:176: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `ath_rx_cleanup':
drivers/net/wireless/ath/ath9k/recv.c:340: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `ath_rx_edma_buf_link':
drivers/net/wireless/ath/ath9k/recv.c:122: undefined reference to `dma_sync_single_for_cpu'
drivers/built-in.o: In function `ath_rx_tasklet':
drivers/net/wireless/ath/ath9k/recv.c:1275: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath9k/recv.c:1277: undefined reference to `dma_mapping_error'
drivers/net/wireless/ath/ath9k/recv.c:1283: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `ath_rx_edma_init':
drivers/net/wireless/ath/ath9k/recv.c:226: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath9k/recv.c:229: undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `ath_rx_init':
drivers/net/wireless/ath/ath9k/recv.c:303: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath9k/recv.c:306: undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `ath_tx_complete_buf':
drivers/net/wireless/ath/ath9k/xmit.c:2088: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `ath_txstatus_setup':
drivers/net/wireless/ath/ath9k/xmit.c:2344: undefined reference to `dmam_alloc_coherent'
drivers/built-in.o: In function `ath_tx_set_retry':
drivers/net/wireless/ath/ath9k/xmit.c:307: undefined reference to `dma_sync_single_for_cpu'
drivers/built-in.o: In function `ath_tx_setup_buffer':
drivers/net/wireless/ath/ath9k/xmit.c:1887: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath9k/xmit.c:1889: undefined reference to `dma_mapping_error'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Cc: John W. Linville <linville@tuxdriver.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
If NO_DMA=y:
drivers/built-in.o: In function `dma_free_tx_skbufs':
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1141: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `dma_free_rx_skbufs':
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1120: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `free_dma_desc_resources':
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1159: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `stmmac_init_rx_buffers':
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:980: undefined reference to `dma_map_single'
drivers/built-in.o: In function `init_dma_desc_rings':
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1015: undefined reference to `dma_alloc_coherent'
drivers/built-in.o: In function `stmmac_tx_clean':
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1250: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `stmmac_rx':
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2044: undefined reference to `dma_unmap_single'
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2082: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `stmmac_rx_refill':
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1967: undefined reference to `dma_map_single'
drivers/built-in.o: In function `stmmac_xmit':
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1845: undefined reference to `dma_map_single'
drivers/built-in.o: In function `skb_frag_dma_map':
include/linux/skbuff.h:2184: undefined reference to `dma_map_page'
drivers/built-in.o: In function `stmmac_jumbo_frm':
drivers/net/ethernet/stmicro/stmmac/ring_mode.c:40: undefined reference to `dma_map_single'
drivers/built-in.o: In function `stmmac_jumbo_frm':
drivers/net/ethernet/stmicro/stmmac/chain_mode.c:48: undefined reference to `dma_map_single'
drivers/net/ethernet/stmicro/stmmac/chain_mode.c:55: undefined reference to `dma_map_single'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
If NO_DMA=y:
drivers/built-in.o: In function `xgmac_xmit':
drivers/net/ethernet/calxeda/xgmac.c:1102: undefined reference to `dma_mapping_error'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
We have seen multiple NULL dereferences in __inet6_lookup_established()
After analysis, I found that inet6_sk() could be NULL while the
check for sk_family == AF_INET6 was true.
Bug was added in linux-2.6.29 when RCU lookups were introduced in UDP
and TCP stacks.
Once an IPv6 socket, using SLAB_DESTROY_BY_RCU is inserted in a hash
table, we no longer can clear pinet6 field.
This patch extends logic used in commit fcbdf09d96
("net: fix nulls list corruptions in sk_prot_alloc")
TCP/UDP/UDPLite IPv6 protocols provide their own .clear_sk() method
to make sure we do not clear pinet6 field.
At socket clone phase, we do not really care, as cloning the parent (non
NULL) pinet6 is not adding a fatal race.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Kees Cook
Christopher Harvey
Lespiau, Damien
Wolfram Sang
Shuah Khan
Dirk Brandewie
Alexander Shiyan
Viresh Kumar
Nishanth Menon
Lan Tianyu
Alex Hung
Jan-Simon Möller
Rafael J. Wysocki
Thomas Gleixner
Guenter Roeck
Axel Lin
Cong Wang
Petri Gynther
Sergei Shtylyov
Linus Torvalds
Geert Uytterhoeven
Nicholas Bellinger
Eric Dumazet