| Age | Commit message (Collapse) | Author |
|---|
|
Commits fcf8058 (cpufreq: Simplify cpufreq_add_dev()) and aa77a52
(cpufreq: acpi-cpufreq: Don't set policy->related_cpus from .init())
changed the contents of the "related_cpus" sysfs attribute on systems
where acpi-cpufreq is used and user space can't get the list of CPUs
which are in the same hardware coordination CPU domain (provided by
the ACPI AML method _PSD) via "related_cpus" any more.
To make up for that loss add a new sysfs attribute "freqdomian_cpus"
for the acpi-cpufreq driver which exposes the list of CPUs in the
same domain regardless of whether it is coordinated by hardware or
software.
[rjw: Changelog, documentation]
References: https://bugzilla.kernel.org/show_bug.cgi?id=58761
Reported-by: Jean-Philippe Halimi <jean-philippe.halimi@exascale-computing.eu>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Whenever we are changing frequency of a cpu, we are calling PRECHANGE and
POSTCHANGE notifiers. They must be serialized. i.e. PRECHANGE or POSTCHANGE
shouldn't be called twice contiguously.
This can happen due to bugs in users of __cpufreq_driver_target() or actual
cpufreq drivers who are sending these notifiers.
This patch adds some protection against this. Now, we keep track of the last
transaction and see if something went wrong.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
* pm-cpufreq-arm:
cpufreq: tegra: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: s3c64xx: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: omap: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: imx6q: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: exynos: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: dbx500: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: davinci: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: arm-big-little: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: s3c2416: fix forgotten driver_data conversions
|
|
* pm-cpufreq-assorted: (21 commits)
cpufreq: powernow-k8: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: pcc: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: e_powersaver: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: ACPI: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: make __cpufreq_notify_transition() static
cpufreq: Fix minor formatting issues
cpufreq: Fix governor start/stop race condition
cpufreq: Simplify userspace governor
cpufreq: powerpc: move cpufreq driver to drivers/cpufreq
cpufreq: kirkwood: Select CPU_FREQ_TABLE option
cpufreq: big.LITTLE needs cpufreq table
cpufreq: SPEAr needs cpufreq table
cpufreq: powerpc: Add cpufreq driver for Freescale e500mc SoCs
cpufreq: remove unnecessary cpufreq_cpu_{get|put}() calls
cpufreq: MAINTAINERS: Add git tree path for ARM specific updates
cpufreq: rename index as driver_data in cpufreq_frequency_table
cpufreq: Don't create empty /sys/devices/system/cpu/cpufreq directory
cpufreq: Move get_cpu_idle_time() to cpufreq.c
cpufreq: governors: Move get_governor_parent_kobj() to cpufreq.c
cpufreq: Add EXPORT_SYMBOL_GPL for have_governor_per_policy
...
|
|
* pm-cpufreq-Kconfig:
cpufreq: X86_AMD_FREQ_SENSITIVITY: select CPU_FREQ_TABLE
cpufreq: tegra: create CONFIG_ARM_TEGRA_CPUFREQ
cpufreq: S3C2416/S3C64XX: select CPU_FREQ_TABLE
cpufreq: pxa: select CPU_FREQ_TABLE
cpufreq: powerpc: CBE_RAS: select CPU_FREQ_TABLE
cpufreq: imx: select CPU_FREQ_TABLE
cpufreq: highbank: remove select CPU_FREQ_TABLE
cpufreq: exynos: select CPU_FREQ_TABLE
cpufreq: davinci: select CPU_FREQ_TABLE
cpufreq: cris: select CPU_FREQ_TABLE
cpufreq: blackfin: enable driver for CONFIG_BFIN_CPU_FREQ
|
|
git://git.linaro.org/people/vireshk/linux into pm-cpufreq-arm
Pull ARM cpufreq updates from Viresh Kumar.
* 'cpufreq-fix-notification-arm' of git://git.linaro.org/people/vireshk/linux:
cpufreq: tegra: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: s3c64xx: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: omap: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: imx6q: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: exynos: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: dbx500: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: davinci: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: arm-big-little: call CPUFREQ_POSTCHANGE notfier in error cases
|
|
PRECHANGE and POSTCHANGE notifiers must be called in groups, i.e either both
should be called or both shouldn't be.
In case we have started PRECHANGE notifier and found an error, we must call
POSTCHANGE notifier with freqs.new = freqs.old to guarantee that sequence of
calling notifiers is complete.
This patch fixes it.
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
PRECHANGE and POSTCHANGE notifiers must be called in groups, i.e either both
should be called or both shouldn't be.
In case we have started PRECHANGE notifier and found an error, we must call
POSTCHANGE notifier with freqs.new = freqs.old to guarantee that sequence of
calling notifiers is complete.
This patch fixes it.
Cc: Mark Brown <broonie@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
PRECHANGE and POSTCHANGE notifiers must be called in groups, i.e either both
should be called or both shouldn't be.
In case we have started PRECHANGE notifier and found an error, we must call
POSTCHANGE notifier with freqs.new = freqs.old to guarantee that sequence of
calling notifiers is complete.
Omap driver was taking care of it well, but wasn't restoring freqs.new to
freqs.old in some cases. I wasn't required to add code for it as moving
PRECHANGE notifier down was a better option, so that we call it just before
starting frequency transition.
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
PRECHANGE and POSTCHANGE notifiers must be called in groups, i.e either both
should be called or both shouldn't be.
In case we have started PRECHANGE notifier and found an error, we must call
POSTCHANGE notifier with freqs.new = freqs.old to guarantee that sequence of
calling notifiers is complete.
This patch fixes it.
This also moves PRECHANGE notifier down so that we call it just before starting
frequency transition.
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
PRECHANGE and POSTCHANGE notifiers must be called in groups, i.e either both
should be called or both shouldn't be.
In case we have started PRECHANGE notifier and found an error, we must call
POSTCHANGE notifier with freqs.new = freqs.old to guarantee that sequence of
calling notifiers is complete.
This patch fixes it.
Cc: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
PRECHANGE and POSTCHANGE notifiers must be called in groups, i.e either both
should be called or both shouldn't be.
In case we have started PRECHANGE notifier and found an error, we must call
POSTCHANGE notifier with freqs.new = freqs.old to guarantee that sequence of
calling notifiers is complete.
This patch fixes it.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
PRECHANGE and POSTCHANGE notifiers must be called in groups, i.e either both
should be called or both shouldn't be.
In case we have started PRECHANGE notifier and found an error, we must call
POSTCHANGE notifier with freqs.new = freqs.old to guarantee that sequence of
calling notifiers is complete.
Davinci driver was taking care of it but frequency isn't restored to freqs.old.
This patch fixes it.
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
PRECHANGE and POSTCHANGE notifiers must be called in groups, i.e either both
should be called or both shouldn't be.
In case we have started PRECHANGE notifier and found an error, we must call
POSTCHANGE notifier with freqs.new = freqs.old to guarantee that sequence of
calling notifiers is complete.
This patch fixes it.
This also removes code setting policy->cur as this is also done by POSTCHANGE
notifier.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
PRECHANGE and POSTCHANGE notifiers must be called in groups, i.e.
either both should be called or both shouldn't be.
In case we have started PRECHANGE notifier and found an error, we
must call POSTCHANGE notifier with freqs.new = freqs.old to guarantee
that sequence of calling notifiers is complete.
This patch fixes it.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
PRECHANGE and POSTCHANGE notifiers must be called in groups, i.e
either both should be called or both shouldn't be.
In case we have started PRECHANGE notifier and found an error, we
must call POSTCHANGE notifier with freqs.new = freqs.old to guarantee
that the sequence of calling notifiers is complete.
This patch fixes it.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
In case we have started PRECHANGE notifier and found an error, we
must call POSTCHANGE notifier with freqs.new = freqs.old.
This driver does take care of it, but the POSTCHANGE is called with
freqs.new on errors too, which is incorrect, so fix it.
[rjw: Changelog]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
PRECHANGE and POSTCHANGE notifiers must be called in groups, i.e either both
should be called or both shouldn't be.
In case we have started PRECHANGE notifier and found an error, we
must call POSTCHANGE notifier with freqs.new = freqs.old to
guarantee that the sequence of calling notifiers is complete.
This patch fixes it.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Commit 5070158804b5 (cpufreq: rename index as driver_data in
cpufreq_frequency_table) renamed the index field to driver_data.
But it seems some uses in the s3c2416 driver were forgotten.
So convert the last index users to read driver_data.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Arnd Bergmann:
"These are two fixes that came in this week, one for a regression we
introduced in 3.10 in the GIC interrupt code, and the other one fixes
a typo in newly introduced code"
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
irqchip: gic: call gic_cpu_init() as well in CPU_STARTING_FROZEN case
ARM: dts: Correct the base address of pinctrl_3 on Exynos5250
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core fix from Greg Kroah-Hartman:
"Here's a single patch for the firmware core that resolves a reported
oops in the firmware core that people have been hitting."
* tag 'driver-core-3.10-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
firmware loader: fix use-after-free by double abort
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg Kroah-Hartman:
"Here are two USB patches for 3.10.
One updates the Kconfig wording for CONFIG_USB_PHY to make it,
hopefully, more obvious what this option is (I know you complained
about this when it hit the tree.) The other is a new device id for a
driver"
* tag 'usb-3.10-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
USB: serial: ti_usb_3410_5052: new device id for Abbot strip port cable
usb: phy: Improve Kconfig help for CONFIG_USB_PHY
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pul tty fixes from Greg Kroah-Hartman:
"Here are two tty core fixes that resolve some regressions that have
been reported recently. Both tiny fixes, but needed"
* tag 'tty-3.10-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
tty: Fix transient pty write() EIO
tty/vt: Return EBUSY if deallocating VT1 and it is busy
|
|
Pull SCSI target fixes from Nicholas Bellinger:
"Included is the recent tcm_qla2xxx residual underrun length fix from
Roland, along with Joern's iscsi-target patch for session_lock
breakage within iscsit_stop_time2retain_timer() code. Both are CC'ed
to stable.
The remaining two are specific to recent iscsi-target + iser
conversion changes. One drops some left-over debug noise, and Andy's
patch fixes configfs attribute handling during an explicit network
portal feature bit disable when iser-target is unsupported."
* git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
iscsi-target: Remove left over v3.10-rc debug printks
target/iscsi: Fix op=disable + error handling cases in np_store_iser
tcm_qla2xxx: Fix residual for underrun commands that fail
target/iscsi: don't corrupt bh_count in iscsit_stop_time2retain_timer()
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media fixes from Mauro Carvalho Chehab:
"Another set of fixes for Kernel 3.10.
This series contain:
- two Kbuild fixes for randconfig
- a buffer overflow when using rtl28xuu with r820t tuner
- one clk fixup on exynos4-is driver"
* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
[media] Fix build when drivers are builtin and frontend modules
[media] s5p makefiles: don't override other selections on obj-[ym]
[media] exynos4-is: Fix FIMC-IS clocks initialization
[media] rtl28xxu: fix buffer overflow when probing Rafael Micro r820t tuner
|
|
Pull drm radeon fixes from Dave Airlie:
"One core fix, but mostly radeon fixes for s/r and big endian UVD
support, and a fix to stop the GPU being reset for no good reason, and
crashing people's machines."
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/radeon: update lockup tracking when scheduling in empty ring
drm/prime: Honor requested file flags when exporting a buffer
drm/radeon: fix UVD on big endian
drm/radeon: fix write back suspend regression with uvd v2
drm/radeon: do not try to uselessly update virtual memory pagetable
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI fixes from Rafael Wysocki:
- Fix for a regression causing a failure to turn on some devices on
some systems during initialization introduced by a recent revert of
an ACPI PM change that broke something else. Fortunately, we know
exactly what devices are affected, so we can add a fix just for them
leaving everyone else alone.
- ACPI power resources initialization fix preventing a NULL pointer
from being dereferenced in the acpi_add_power_resource() error code
path.
- ACPI dock station driver fix that adds missing locking to
write_undock().
- ACPI resources allocation fix changing the scope of an old workaround
so that it doesn't affect systems that aren't actually buggy. This
was reported a couple of days ago to fix DMA problems on some new
platforms so we need it in -stable. From Mika Westerberg.
* tag 'acpi-3.10-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI / LPSS: Power up LPSS devices during enumeration
ACPI / PM: Fix error code path for power resources initialization
ACPI / dock: Take ACPI scan lock in write_undock()
ACPI / resources: call acpi_get_override_irq() only for legacy IRQ resources
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client
Pull Ceph fix from Sage Weil:
"This fixes a problem preventing the kernel and userland librbd
libraries from sharing data with the new format 2 images"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client:
rbd: use the correct length for format 2 object names
|
|
Reported-by: Andy Grover <agrover@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
|
|
Writing 0 when iser was not previously enabled, so succeed but do
nothing so that user-space code doesn't need a try: catch block
when ib_isert logic is not available.
Also, return actual error from add_network_portal using PTR_ERR
during op=enable failure.
Signed-off-by: Andy Grover <agrover@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
|
|
__cpufreq_notify_transition() is used only in cpufreq.c,
make it static.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
There were a few noticeable formatting issues in core cpufreq code.
This cleans them up to make code look better. The changes include:
- Whitespace cleanup.
- Rearrangements of code.
- Multiline comments fixes.
- Formatting changes to fit 80 columns.
Copyright information in cpufreq.c is also updated to include my name
for 2013.
[rjw: Changelog]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Cpufreq governors' stop and start operations should be carried out
in sequence. Otherwise, there will be unexpected behavior, like in
the example below.
Suppose there are 4 CPUs and policy->cpu=CPU0, CPU1/2/3 are linked
to CPU0. The normal sequence is:
1) Current governor is userspace. An application tries to set the
governor to ondemand. It will call __cpufreq_set_policy() in
which it will stop the userspace governor and then start the
ondemand governor.
2) Current governor is userspace. The online of CPU3 runs on CPU0.
It will call cpufreq_add_policy_cpu() in which it will first
stop the userspace governor, and then start it again.
If the sequence of the above two cases interleaves, it becomes:
1) Application stops userspace governor
2) Hotplug stops userspace governor
which is a problem, because the governor shouldn't be stopped twice
in a row. What happens next is:
3) Application starts ondemand governor
4) Hotplug starts a governor
In step 4, the hotplug is supposed to start the userspace governor,
but now the governor has been changed by the application to ondemand,
so the ondemand governor is started once again, which is incorrect.
The solution is to prevent policy governors from being stopped
multiple times in a row. A governor should only be stopped once for
one policy. After it has been stopped, no more governor stop
operations should be executed.
Also add a mutex to serialize governor operations.
[rjw: Changelog. And you owe me a beverage of my choice.]
Signed-off-by: Xiaoguang Chen <chenxg@marvell.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
into drm-fixes
One user visible fix to stop misreport GPU hangs and subsequent resets.
* 'drm-fixes-3.10' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: update lockup tracking when scheduling in empty ring
|
|
There might be issue with lockup detection when scheduling on an
empty ring that have been sitting idle for a while. Thus update
the lockup tracking data when scheduling new work in an empty ring.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Tested-by: Andy Lutomirski <luto@amacapital.net>
Cc: stable@vger.kernel.org
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
There are a large number of reports that the media build is
not compiling when some drivers are compiled as builtin, while
the needed frontends are compiled as module.
On the last one of such reports:
From: kbuild test robot <fengguang.wu@intel.com>
Subject: saa7134-dvb.c:undefined reference to `zl10039_attach'
The .config file has:
CONFIG_VIDEO_SAA7134=y
CONFIG_VIDEO_SAA7134_DVB=y
# CONFIG_MEDIA_ATTACH is not set
CONFIG_DVB_ZL10039=m
And it produces all those errors:
drivers/built-in.o: In function `set_type':
tuner-core.c:(.text+0x2f263e): undefined reference to `tea5767_attach'
tuner-core.c:(.text+0x2f273e): undefined reference to `tda9887_attach'
drivers/built-in.o: In function `tuner_probe':
tuner-core.c:(.text+0x2f2d20): undefined reference to `tea5767_autodetection'
drivers/built-in.o: In function `av7110_attach':
av7110.c:(.text+0x330bda): undefined reference to `ves1x93_attach'
av7110.c:(.text+0x330bf7): undefined reference to `stv0299_attach'
av7110.c:(.text+0x330c63): undefined reference to `tda8083_attach'
av7110.c:(.text+0x330d09): undefined reference to `ves1x93_attach'
av7110.c:(.text+0x330d33): undefined reference to `tda8083_attach'
av7110.c:(.text+0x330d5d): undefined reference to `stv0297_attach'
av7110.c:(.text+0x330dbe): undefined reference to `stv0299_attach'
drivers/built-in.o: In function `tuner_attach_dtt7520x':
ngene-cards.c:(.text+0x3381cb): undefined reference to `dvb_pll_attach'
drivers/built-in.o: In function `demod_attach_lg330x':
ngene-cards.c:(.text+0x33828a): undefined reference to `lgdt330x_attach'
drivers/built-in.o: In function `demod_attach_stv0900':
ngene-cards.c:(.text+0x3383d5): undefined reference to `stv090x_attach'
drivers/built-in.o: In function `cineS2_probe':
ngene-cards.c:(.text+0x338b7f): undefined reference to `drxk_attach'
drivers/built-in.o: In function `configure_tda827x_fe':
saa7134-dvb.c:(.text+0x346ae7): undefined reference to `tda10046_attach'
drivers/built-in.o: In function `dvb_init':
saa7134-dvb.c:(.text+0x347283): undefined reference to `mt352_attach'
saa7134-dvb.c:(.text+0x3472cd): undefined reference to `mt352_attach'
saa7134-dvb.c:(.text+0x34731c): undefined reference to `tda10046_attach'
saa7134-dvb.c:(.text+0x34733c): undefined reference to `tda10046_attach'
saa7134-dvb.c:(.text+0x34735c): undefined reference to `tda10046_attach'
saa7134-dvb.c:(.text+0x347378): undefined reference to `tda10046_attach'
saa7134-dvb.c:(.text+0x3473db): undefined reference to `tda10046_attach'
drivers/built-in.o:saa7134-dvb.c:(.text+0x347502): more undefined references to `tda10046_attach' follow
drivers/built-in.o: In function `dvb_init':
saa7134-dvb.c:(.text+0x347812): undefined reference to `mt352_attach'
saa7134-dvb.c:(.text+0x347951): undefined reference to `mt312_attach'
saa7134-dvb.c:(.text+0x3479a9): undefined reference to `mt312_attach'
>> saa7134-dvb.c:(.text+0x3479c1): undefined reference to `zl10039_attach'
This is happening because a builtin module can't use directly a symbol
found on a module. By enabling CONFIG_MEDIA_ATTACH, the configuration
becomes valid, as dvb_attach() macro loads the module if needed, making
the symbol available to the builtin module.
While this bug started to appear after the patches that use IS_DEFINED
macro (like changeset 7b34be71db533f3e0cf93d53cf62d036cdb5418a), this
bug is a way ancient than that.
The thing is that, before the IS_DEFINED() patches, the logic used to be:
&& defined(MODULE))
struct dvb_frontend *zl10039_attach(struct dvb_frontend *fe,
u8 i2c_addr,
struct i2c_adapter *i2c);
static inline struct dvb_frontend *zl10039_attach(struct dvb_frontend *fe,
u8 i2c_addr,
struct i2c_adapter *i2c)
{
printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
return NULL;
}
The above code, with the .config file used, was evoluting to FALSE
(instead of TRUE as it should be, as CONFIG_DVB_ZL10039 is 'm'),
and were adding the static inline code at saa7134-dvb, instead
of the external call. So, while it weren't producing any compilation
error, the code weren't working either.
So, as the overhead for using CONFIG_MEDIA_ATTACH is minimal, just
enable it, if MODULES is defined.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Commit c011470 (irqchip: gic: Perform the gic_secondary_init() call via
CPU notifier) moves gic_secondary_init() that used to be called in
.smp_secondary_init hook into a notifier call. But it changes the
system behavior a little bit. Before the commit, gic_cpu_init()
is called not only when kernel brings up the secondary cores but also
when system resuming procedure hot-plugs the cores back to kernel.
While after the commit, the function will not be called in the latter
case, where the 'action' will not be CPU_STARTING but
CPU_STARTING_FROZEN. This behavior difference at least causes the
following suspend/resume regression on imx6q.
$ echo mem > /sys/power/state
PM: Syncing filesystems ... done.
PM: Preparing system for mem sleep
mmc1: card e624 removed
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
PM: Entering mem sleep
PM: suspend of devices complete after 5.930 msecs
PM: suspend devices took 0.010 seconds
PM: late suspend of devices complete after 0.343 msecs
PM: noirq suspend of devices complete after 0.828 msecs
Disabling non-boot CPUs ...
CPU1: shutdown
CPU2: shutdown
CPU3: shutdown
Enabling non-boot CPUs ...
CPU1: Booted secondary processor
INFO: rcu_sched detected stalls on CPUs/tasks: { 1 2 3} (detected by 0, t=2102 jiffies, g=4294967169, c=4294967168, q=17)
Task dump for CPU 1:
swapper/1 R running 0 0 1 0x00000000
Backtrace:
[<bf895ff4>] (0xbf895ff4) from [<00000000>] ( (null))
Backtrace aborted due to bad frame pointer <8007ccdc>
Task dump for CPU 2:
swapper/2 R running 0 0 1 0x00000000
Backtrace:
[<8075dbdc>] (0x8075dbdc) from [<00000000>] ( (null))
Backtrace aborted due to bad frame pointer <00000002>
Task dump for CPU 3:
swapper/3 R running 0 0 1 0x00000000
Backtrace:
[<8075dbdc>] (0x8075dbdc) from [<00000000>] ( (null))
Fix the regression by checking 'action' being CPU_STARTING_FROZEN to
have gic_cpu_init() called for secondary cores when system resumes.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Joseph Lo <josephl@nvidia.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The $obj-m/$obj-y vars should be adding new modules to build, not
overriding it. So, it should never use
$obj-y := foo.o
instead, it should use:
$obj-y += foo.o
Failing to do that is very bad, as it will suppress needed modules.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
Add product id for Abbott strip port cable for Precision meter which
uses the TI 3410 chip.
Signed-off-by: Anders Hammarquist <iko@iko.pp.se>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit 7cd8407 (ACPI / PM: Do not execute _PS0 for devices without
_PSC during initialization) introduced a regression on some systems
with Intel Lynxpoint Low-Power Subsystem (LPSS) where some devices
need to be powered up during initialization, but their device objects
in the ACPI namespace have _PS0 and _PS3 only (without _PSC or power
resources).
To work around this problem, make the ACPI LPSS driver power up
devices it knows about by using a new helper function
acpi_device_fix_up_power() that does all of the necessary
sanity checks and calls acpi_dev_pm_explicit_set() to put the
device into D0.
Reported-and-tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Commit 781d737 (ACPI: Drop power resources driver) introduced a
bug in the power resources initialization error code path causing
a NULL pointer to be referenced in acpi_release_power_resource()
if there's an error triggering a jump to the 'err' label in
acpi_add_power_resource(). This happens because the list_node
field of struct acpi_power_resource has not been initialized yet
at this point and doing a list_del() on it is a bad idea.
To prevent this problem from occuring, initialize the list_node
field of struct acpi_power_resource upfront.
Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
|
Since commit 3757b94 (ACPI / hotplug: Fix concurrency issues and
memory leaks) acpi_bus_scan() and acpi_bus_trim() must always be
called under acpi_scan_lock, but currently the following scenario
violating that requirement is possible:
write_undock()
handle_eject_request()
hotplug_dock_devices()
dock_remove_acpi_device()
acpi_bus_trim()
Fix that by making write_undock() acquire acpi_scan_lock before
calling handle_eject_request() as appropriate (begin_undock() is
under the lock too in analogy with acpi_dock_deferred_cb()).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Acked-by: Toshi Kani <toshi.kani@hp.com>
|
|
acpi_get_override_irq() was added because there was a problem with
buggy BIOSes passing wrong IRQ() resource for the RTC IRQ. The
commit that added the workaround was 61fd47e0c8476 (ACPI: fix two
IRQ8 issues in IOAPIC mode).
With ACPI 5 enumerated devices there are typically one or more
extended IRQ resources per device (and these IRQs can be shared).
However, the acpi_get_override_irq() workaround forces all IRQs in
range 0 - 15 (the legacy ISA IRQs) to be edge triggered, active high
as can be seen from the dmesg below:
ACPI: IRQ 6 override to edge, high
ACPI: IRQ 7 override to edge, high
ACPI: IRQ 7 override to edge, high
ACPI: IRQ 13 override to edge, high
Also /proc/interrupts for the I2C controllers (INT33C2 and INT33C3) shows
the same thing:
7: 4 0 0 0 IO-APIC-edge INT33C2:00, INT33C3:00
The _CSR method for INT33C2 (and INT33C3) device returns following
resource:
Interrupt (ResourceConsumer, Level, ActiveLow, Shared,,, )
{
0x00000007,
}
which states that this is supposed to be level triggered, active low,
shared IRQ instead.
Fix this by making sure that acpi_get_override_irq() gets only called
when we are dealing with legacy IRQ() or IRQNoFlags() descriptors.
While we are there, correct pr_warning() to print the right triggering
value.
This change turns out to be necessary to make DMA work correctly on
systems based on the Intel Lynxpoint PCH (Platform Controller Hub).
[rjw: Changelog]
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The ISP clock register content is not preserved over the ISP power domain
off/on cycle. Instead of setting the clock frequencies once at probe time
the clock rates set up is moved to the runtime_resume handler, which is
invoked after the related power domain is already enabled, ensuring the
clocks are properly configured when the device is actively used.
This fixes the FIMC-IS malfunctions and STREAM ON timeout errors accuring
on some boards:
[ 59.860000] fimc_is_general_irq_handler:583 ISR_NDONE: 5: 0x800003e8, IS_ERROR_UNKNOWN
[ 59.860000] fimc_is_general_irq_handler:586 IS_ERROR_TIME_OUT
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
into drm-fixes
Alex writes:
Remove some harmless but confusing VM related error messages
fix a regression with suspend and UVD,
fix UVD on big endian.
* 'drm-fixes-3.10' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: fix UVD on big endian
drm/radeon: fix write back suspend regression with uvd v2
drm/radeon: do not try to uselessly update virtual memory pagetable
|
|
The DRM PRIME API passes file flags to the driver for the exported
buffer. Honor them instead of hardcoding 0600.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Userspace governor has got more code than what it needs for its
functioning, so simplify it.
Portions of code removed are:
- Extra header files which aren't required anymore (rearrange them
as well).
- cpu_{max|min|cur|set}_freq, as they are always the same as
policy->{max|min|cur}.
- userspace_cpufreq_notifier_block as we don't need to set
cpu_cur_freq anymore.
- cpus_using_userspace_governor as it was for the notifier code.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The C8000 workstation (64 bit kernel only) has a somewhat different
serial port configuration than other models.
Thomas Bogendoerfer sent a patch to fix this in September 2010, which
was now minimally modified by me.
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
fw_priv->buf is accessed in both request_firmware_load() and
writing to sysfs file of 'loading' context, but not protected
by 'fw_lock' entirely. The patch makes sure that access on
'fw_priv->buf' is protected by the lock.
So fixes the double abort problem reported by nirinA raseliarison:
http://lkml.org/lkml/2013/6/14/188
Reported-and-tested-by: nirinA raseliarison <nirina.raseliarison@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable <stable@vger.kernel.org> # 3.9
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The previous text confused users by not describing the very common
(e.g. x86 PC) sitations where no PHY driver is necessary.
Signed-off-by: George Spelvin <linux@horizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
