| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Function gfs2_glock_dq_wait is supposed to dequeue a glock and then
wait for the lock to be demoted. The problem is, if this is a shared
lock, its demote will depend on the other holders, which means you
might end up waiting forever because the other process is blocked.
This problem is especially apparent when dealing with nested flocks.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI and power management fixes from Rafael Wysocki:
"These are fixes mostly (ia64 regression related to the ACPI
enumeration of devices, cpufreq regressions, fix for I2C controllers
included in Intel SoCs, mvebu cpuidle driver fix related to sysfs)
plus additional kernel command line arguments from Kees to make it
possible to build kernel images with hibernation and the kernel
address space randomization included simultaneously, a new ACPI
battery driver quirk for a system with a broken BIOS and a couple of
ACPI core cleanups.
Specifics:
- Fix for an ia64 regression introduced during the 3.11 cycle by a
commit that modified the hardware initialization ordering and made
device discovery fail on some systems.
- Fix for a build problem on systems where the cpufreq-cpu0 driver is
built-in and the cpu-thermal driver is modular from Arnd Bergmann.
- Fix for a recently introduced computational mistake in the
intel_pstate driver that leads to excessive rounding errors from
Doug Smythies.
- Fix for a failure code path in cpufreq_update_policy() that fails
to unlock the locks acquired previously from Aaron Plattner.
- Fix for the cpuidle mvebu driver to use shorter state names which
will prevent the sysfs interface from returning mangled strings.
From Gregory Clement.
- ACPI LPSS driver fix to make sure that the I2C controllers included
in BayTrail SoCs are not held in the reset state while they are
being probed from Mika Westerberg.
- New kernel command line arguments making it possible to build
kernel images with hibernation and kASLR included at the same time
and to select which of them will be used via the command line (they
are still functionally mutually exclusive, though). From Kees
Cook.
- ACPI battery driver quirk for Acer Aspire V5-573G that fails to
send battery status change notifications timely from Alexander
Mezin.
- Two ACPI core cleanups from Christoph Jaeger and Fabian Frederick"
* tag 'pm+acpi-3.16-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
cpuidle: mvebu: Fix the name of the states
cpufreq: unlock when failing cpufreq_update_policy()
intel_pstate: Correct rounding in busy calculation
ACPI: use kstrto*() instead of simple_strto*()
ACPI / processor replace __attribute__((packed)) by __packed
ACPI / battery: add quirk for Acer Aspire V5-573G
ACPI / battery: use callback for setting up quirks
ACPI / LPSS: Take I2C host controllers out of reset
x86, kaslr: boot-time selectable with hibernation
PM / hibernate: introduce "nohibernate" boot parameter
cpufreq: cpufreq-cpu0: fix CPU_THERMAL dependency
ACPI / ia64 / sba_iommu: Restore the working initialization ordering
|
| | |\ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* pm-cpufreq:
cpufreq: unlock when failing cpufreq_update_policy()
intel_pstate: Correct rounding in busy calculation
cpufreq: cpufreq-cpu0: fix CPU_THERMAL dependency
* pm-cpuidle:
cpuidle: mvebu: Fix the name of the states
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The length name of the states 2 was too long to fit in the allocated
string (limited to 16 bytes). This lead to improper string displayed
through sysfs.
This patch shorten the name by removing the reference to Marvell and
to the CPU as both are implicit. For coherency the same change have
been done for the states 1.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Commit bd0fa9bb455d introduced a failure path to cpufreq_update_policy() if
cpufreq_driver->get(cpu) returns NULL. However, it jumps to the 'no_policy'
label, which exits without unlocking any of the locks the function acquired
earlier. This causes later calls into cpufreq to hang.
Fix this by creating a new 'unlock' label and jumping to that instead.
Fixes: bd0fa9bb455d ("cpufreq: Return error if ->get() failed in cpufreq_update_policy()")
Link: https://devtalk.nvidia.com/default/topic/751903/kernel-3-15-and-nv-drivers-337-340-failed-to-initialize-the-nvidia-kernel-module-gtx-550-ti-/
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Cc: 3.15+ <stable@vger.kernel.org> # 3.15+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
There was a mistake in the actual rounding portion this previous patch:
f0fe3cd7e12d (intel_pstate: Correct rounding in busy calculation) such that
the rounding was asymetric and incorrect.
Severity: Not very serious, but can increase target pstate by one extra value.
For real world work flows the issue should self correct (but I have no proof).
It is the equivalent of different PID gains for positive and negative numbers.
Examples:
-3.000000 used to round to -4, rounds to -3 with this patch.
-3.503906 used to round to -5, rounds to -4 with this patch.
Fixes: f0fe3cd7e12d (intel_pstate: Correct rounding in busy calculation)
Signed-off-by: Doug Smythies <dsmythies@telus.net>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| | | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
5fbfbcd3e842d ("cpufreq: cpufreq-cpu0: remove dependency on THERMAL and
REGULATOR") was a little too quick in completely removing the dependency
on the THERMAL driver.
The problem is that while there are inline wrappers to turn the thermal
API calls into empty functions, those do not help if the cpu-thermal
driver is a loadable module and cpufreq-cpu0 is builtin.
Since CONFIG_CPU_THERMAL is a bool option that decides whether the cpu
code is built into the thermal module or not, we have to use a dependency
on the thermal driver itself. However, if CPU_THERMAL is disabled, we
don't need the dependency, hence the strange '!CPU_THERMAL || THERMAL'
construct.
Fixes: 5fbfbcd3e842d ("cpufreq: cpufreq-cpu0: remove dependency on THERMAL and REGULATOR")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| | |\ \
| | | |
| | | |
| | | |
| | | |
| | | | |
* pm-sleep:
x86, kaslr: boot-time selectable with hibernation
PM / hibernate: introduce "nohibernate" boot parameter
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Changes kASLR from being compile-time selectable (blocked by
CONFIG_HIBERNATION), to being boot-time selectable (with hibernation
available by default) via the "kaslr" kernel command line.
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| | | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
To support using kernel features that are not compatible with hibernation,
this creates the "nohibernate" kernel boot parameter to disable both
hibernation and resume. This allows hibernation support to be a boot-time
choice instead of only a compile-time choice.
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| | | | | |
| | | \ | |
| | | \ | |
| | | \ | |
| | | \ | |
| | | \ | |
| | |\ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
* acpi-general:
ACPI: use kstrto*() instead of simple_strto*()
* acpi-processor:
ACPI / processor replace __attribute__((packed)) by __packed
* acpi-lpss:
ACPI / LPSS: Take I2C host controllers out of reset
* acpi-battery:
ACPI / battery: add quirk for Acer Aspire V5-573G
ACPI / battery: use callback for setting up quirks
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
On Acer Aspire V5-573G battery notifications are sometimes
triggered too early. For example, when AC is unplugged and
notification is triggered, battery state is still reported as
"Full", and changes to "Discharging" only after short delay,
without any notification.
This patch solves the problem by adding 1 second sleep.
Similar quirk is already implemented in AC driver for other laptop.
Signed-off-by: Alexander Mezin <mezin.alexander@gmail.com>
Acked-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| | | | | | |/
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Use callback for setting up quirk instead of checking return code
of dmi_check_system(). This change will allow using bat_dmi_table
for other quirks.
Signed-off-by: Alexander Mezin <mezin.alexander@gmail.com>
Acked-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| | | | | |/
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
On Intel Baytrail, some I2C host controllers are held in reset when the OS
gets control. This causes the driver to fail to detect the hardware
properly.
Fix this so that we make sure that the I2C host controller is not in reset
when the driver gets probe'd.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| | | | |/
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This patch fixes checkpatch warnings:
"WARNING: __packed is preferred over __attribute__((packed))"
Signed-off-by: Fabian Frederick <fabf@skynet.be>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| | | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
simple_strto*() are obsolete; use kstrto*() instead. Add proper error
checking.
Signed-off-by: Christoph Jaeger <christophjaeger@linux.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Commit 66345d5f79fc (ACPI / ia64 / sba_iommu: Use ACPI scan handler
for device discovery) changed the ordering of SBA (System Bus Adapter)
IOMMU initialization with respect to the PCI host bridge initialization
which broke things inadvertently, because the SBA IOMMU initialization
code has to run after the PCI host bridge has been initialized.
Fix that by reworking the SBA IOMMU ACPI scan handler so that it
claims the discovered matching ACPI device objects without attempting
to initialize anything and move the entire SBA IOMMU initialization
to sba_init() that runs after the PCI bus has been enumerated.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=76691
Fixes: 66345d5f79fc (ACPI / ia64 / sba_iommu: Use ACPI scan handler for device discovery)
Reported-and-tested-by: Émeric Maschino <emeric.maschino@gmail.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: 3.11+ <stable@vger.kernel.org> # 3.11+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"The significant part here is a few security fixes for ALSA core
control API by Lars. Besides that, there are a few fixes for ASoC
sigmadsp (again by Lars) for building properly, and small fixes for
ASoC rsnd, MMP, PXA and FSL, in addition to a fix for bogus WARNING in
i915/HD-audio binding"
* tag 'sound-3.16-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: control: Make sure that id->index does not overflow
ALSA: control: Handle numid overflow
ALSA: control: Don't access controls outside of protected regions
ALSA: control: Fix replacing user controls
ALSA: control: Protect user controls against concurrent access
drm/i915, HD-audio: Don't continue probing when nomodeset is given
ASoC: fsl: Fix build problem
ASoC: rsnd: fixup index of src/dst mod when capture
ASoC: fsl_spdif: Fix integer overflow when calculating divisors
ASoC: fsl_spdif: Fix incorrect usage of regmap_read()
ASoC: dapm: Make sure register value is in sync with DAPM kcontrol state
ASoC: sigmadsp: Split regmap and I2C support into separate modules
ASoC: MMP audio needs sram support
ASoC: pxa: add I2C dependencies as needed
|
| | |\ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The ALSA control code expects that the range of assigned indices to a control is
continuous and does not overflow. Currently there are no checks to enforce this.
If a control with a overflowing index range is created that control becomes
effectively inaccessible and unremovable since snd_ctl_find_id() will not be
able to find it. This patch adds a check that makes sure that controls with a
overflowing index range can not be created.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Each control gets automatically assigned its numids when the control is created.
The allocation is done by incrementing the numid by the amount of allocated
numids per allocation. This means that excessive creation and destruction of
controls (e.g. via SNDRV_CTL_IOCTL_ELEM_ADD/REMOVE) can cause the id to
eventually overflow. Currently when this happens for the control that caused the
overflow kctl->id.numid + kctl->count will also over flow causing it to be
smaller than kctl->id.numid. Most of the code assumes that this is something
that can not happen, so we need to make sure that it won't happen
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
A control that is visible on the card->controls list can be freed at any time.
This means we must not access any of its memory while not holding the
controls_rw_lock. Otherwise we risk a use after free access.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
There are two issues with the current implementation for replacing user
controls. The first is that the code does not check if the control is actually a
user control and neither does it check if the control is owned by the process
that tries to remove it. That allows userspace applications to remove arbitrary
controls, which can cause a user after free if a for example a driver does not
expect a control to be removed from under its feed.
The second issue is that on one hand when a control is replaced the
user_ctl_count limit is not checked and on the other hand the user_ctl_count is
increased (even though the number of user controls does not change). This allows
userspace, once the user_ctl_count limit as been reached, to repeatedly replace
a control until user_ctl_count overflows. Once that happens new controls can be
added effectively bypassing the user_ctl_count limit.
Both issues can be fixed by instead of open-coding the removal of the control
that is to be replaced to use snd_ctl_remove_user_ctl(). This function does
proper permission checks as well as decrements user_ctl_count after the control
has been removed.
Note that by using snd_ctl_remove_user_ctl() the check which returns -EBUSY at
beginning of the function if the control already exists is removed. This is not
a problem though since the check is quite useless, because the lock that is
protecting the control list is released between the check and before adding the
new control to the list, which means that it is possible that a different
control with the same settings is added to the list after the check. Luckily
there is another check that is done while holding the lock in snd_ctl_add(), so
we'll rely on that to make sure that the same control is not added twice.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
| | | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The user-control put and get handlers as well as the tlv do not protect against
concurrent access from multiple threads. Since the state of the control is not
updated atomically it is possible that either two write operations or a write
and a read operation race against each other. Both can lead to arbitrary memory
disclosure. This patch introduces a new lock that protects user-controls from
concurrent access. Since applications typically access controls sequentially
than in parallel a single lock per card should be fine.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
| | |\ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v3.16
Quite a few build coverage fixes in here among the usual small driver
fixes includling the sigmadsp change from Lars - moving the driver to
separate modules per bus (which is basically just code motion) avoids
issues with some combinations of buses being enabled.
|
| | | | \ | |
| | | | \ | |
| | | | \ | |
| | | | \ | |
| | | | \ | |
| | | | \ | |
| | | | \ | |
| | | | \ | |
| | | |\ \ \ \ \ \
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
'asoc/fix/pxa', 'asoc/fix/rcar' and 'asoc/fix/sigmadsp' into asoc-linus
|
| | | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
When the SigmaDSP module is built-in, but the I2C core is build as a module
we'll get a undefined reference:
sound/built-in.o: In function `sigma_action_write_i2c':
:(.text+0x5d8d4): undefined reference to `i2c_master_send'
This can happen if a audio driver that is using the regmap SigmaDSP interface is
built into the kernel, but core I2C support is build as a module. To fix this
split the SigmaDSP module into three modules, one module providing the core
infrastructure and two small modules implementing the regmap and I2C interfaces.
This allows e.g. the core infrastructure and regmap support to be built into the
kernel while I2C support can still be build as a module.
Fixes: dab464b60 ("ASoC: Add ADAU1361/ADAU1761 audio CODEC support")
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
| | | | | | | |/ /
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Index of dma name should use -1, not +1 when capture case.
Thank you Dan.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
From e7a94bb7fb871c73cc85712d89c1f48d0271c1be Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Thu, 5 Jun 2014 12:31:28 +0200
Subject: [PATCH] ASoC: MMP audio needs sram support
Building the pxa/mmp audio driver without support for the mmp
sram driver enabled results in this link error:
sound/built-in.o: In function `mmp_pcm_free_dma_buffers':
:(.text+0x3e734): undefined reference to `sram_get_gpool'
sound/built-in.o: In function `mmp_pcm_new':
:(.text+0x3e7c0): undefined reference to `sram_get_gpool'
The sram driver is cannot be manually enabled and needs to
be turned on by selecting MMP_SRAM from each module that
needs it, which is what this patch does.
Ideally, MMP should move over to the generic SRAM support, but
for the moment, we can avoid the build error.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Qiao Zhou <zhouqiao@marvell.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
We have in the past added 'depends on I2C' for some of the PXA boards
after hitting randconfig build bugs. I have seens a couple of new
bugs in this area during the linux-next cycle for 3.16, after it
became possible to build some more PXA machines with I2C disabled.
To shut this up for good, this adds the dependency to every board
that uses I2C as the interface to the codec. I have gone through
all board files and verified that they all either use AC97 or
I2C, and this annotates the latter. Some of these already enable
I2C from mach-pxa/Kconfig, but since that can change it's better
to be explicit here.
The link error that can result otherwise happens when CONFIG_I2C
is set to 'm' and the codec driver is built-in as a result of being
selected by the platform specific glue.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
The calculation code does
u64 = (u32 - u32) * 100000;
The 64 bits are of no help here as the type is casted only after the
multiplication, and therefore the result may overflow, possibly causing
inoptimal or wrong clock setup in an unfortunate case (the maximum
result value of the first substraction is currently 47999).
Fix the code to cast before multiplication.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Acked-by: Nicolin Chen <Guangyu.Chen@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
| | | | | | |/ /
| | | | |/| |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
We should not copy the return value into this val since it's supposed to
get the value of the register not the success result of regmap_read().
Thus fix it.
Signed-off-by: Nicolin Chen <Guangyu.Chen@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
| | | | |/ / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Commit 432481220 (ASoC: fsl-ssi: Use regmap) removed struct ccsr_ssi.
Unfortunately, the structure is still used. This causes
mpc85xx_smp_defconfig and mpc85xx_defconfig builds to fail with
sound/soc/fsl/fsl_dma.c:926:50:
error: invalid use of undefined type 'struct ccsr_ssi'
dma->ssi_stx_phys = res.start + offsetof(struct ccsr_ssi, stx0);
ound/soc/fsl/fsl_dma.c:927:50:
error: invalid use of undefined type 'struct ccsr_ssi'
dma->ssi_srx_phys = res.start + offsetof(struct ccsr_ssi, srx0);
Fix by using constants, similar to original commit.
Cc: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
| | | |\ \ \ \
| | | |_|_|/
| | |/| | | |
|
| | | | |/ /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Commit c9e065c27fe9 ("ASoC: dapm: Make sure to always update the DAPM graph
in _put_volsw()") stopped updating register values in those cases where
initial after boot state of kcontrol appears to not change but where
register value still needs update because it is not in sync with the
kcontrol state.
Fix this by doing snd_soc_test_bits() unconditionally as it was before but
by using separate flags for kcontrol and register state changes. This allow
both DAPM graph to be updated when disabling auto-muted control and update
register if it is out-of-sync in respect of kcontrol state.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When a machine is booted with nomodeset option, i915 driver skips the
whole initialization. Meanwhile, HD-audio tries to bind wth i915 just
by request_symbol() without knowing that the initialization was
skipped, and eventually it hits WARN_ON() in i915_request_power_well()
and i915_release_power_well() wrongly but still continues probing,
even though it doesn't work at all.
In this patch, both functions are changed to return an error in case
of uninitialized state instead of WARN_ON(), so that HD-audio driver
can give up HDMI controller initialization at the right time.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: <stable@vger.kernel.org> [3.15]
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Pull drm fixes from Dave Airlie:
"This looks bigger than it is, as one of the nouveau firmware fixes
("drm/gf100-/gr: report class data to host on fwmthd failure")
regenerates a bunch of the firmware files after changing the assembly
by a few lines, without that, its more of a
36 files changed, 370 insertions(+), 129 deletions(-)
It contains some vt.c fixes acked by Greg, for rare hard hangs on i915
loading, that also fixes hangs on reload and spurious register write
errors.
drm core: one fix for uninit memory
nouveau: displayport rework caused a few regressions, Ben has been
fixing them as the appear, along with some other fixes
radeon: pageflipping regression fix, deep color fix, mode validation
fixes
i915: fbc disable, vga console kick off, backlight fix, divide-by-zero
fix"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (33 commits)
drm: fix uninitialized acquire_ctx fields (v2)
drm/radeon: Fix radeon_irq_kms_pflip_irq_get/put() imbalance
Revert "drm/radeon: remove drm_vblank_get|put from pflip handling"
drm/radeon: improve dvi_mode_valid
drm/radeon: update mode_valid testing for DP
drm/radeon: Use dce5/6 hdmi deep color clock setup also on dce8+
drm/nouveau/disp: fix oops in destructor with headless cards
drm/gf117/i2c: no aux channels on this chipset
drm/nouveau/doc: update the thermal documentation
drm/nouveau/pwr: fix typo in fifo wrap handling
drm/nv50/disp: fix a potential oops in supervisor handling
drm/nouveau/disp/dp: don't touch link config after success
drm/nouveau/kms: reference vblank for crtc during pageflip.
drm/gk104/fb/ram: fixups from an earlier search+replace
drm/nv50/gr: remove an unneeded write while initialising PGRAPH
drm/nv50/gr: fix overlap while zeroing zcull regions
drm/gf100-/gr: report class data to host on fwmthd failure
drm/gk104/ibus: increase various random timeouts
drm/gk104/clk: only touch divider for mode we'll be using
drm/radeon: Bypass hw lut's for > 8 bpc framebuffer scanout.
...
|
| | |\ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
git://anongit.freedesktop.org/drm-intel into drm-next
First round of fixes for 3.16-rc, mostly cc: stable, and the vt/vgacon
fixes from Daniel [1] to avoid hangs and unclaimed register errors on
module load/reload.
* tag 'drm-intel-fixes-2014-06-17' of git://anongit.freedesktop.org/drm-intel:
drm/i915/bdw: remove erroneous chv specific workarounds from bdw code
drm/i915: fix possible refcount leak when resetting forcewake
drm/i915: Reorder semaphore deadlock check
drm/i95: Initialize active ring->pid to -1
drm/i915: set backlight duty cycle after backlight enable for gen4
drm/i915: Avoid div-by-zero when pixel_multiplier is zero
drm/i915: Disable FBC by default also on Haswell and later
drm/i915: Kick out vga console
drm/i915: Fixup global gtt cleanup
vt: Don't ignore unbind errors in vt_unbind
vt: Fix up unregistration of vt drivers
vt: Fix replacement console check when unbinding
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Correct a merge mishap in
commit e4443e459ccf43f2c139358400365fd6a839d40d
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Wed Apr 9 13:28:41 2014 +0300
drm/i915/chv: Add a bunch of pre production workarounds
Remove the the chv specific workarounds from bdw code, specifically
gen8_enable_rps().
Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Jani: extract hunk #1 for 3.16 from Tom's patch, clarify commit message]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
All, I intend to push this to drm-intel-fixes, any objections?
Jani.
|
| | | |\ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
drm-intel-fixes
vt/vgacon fixes to avoid hangs, unclaimed register errors on module
load, reload:
vt: Fix replacement console check when unbinding
vt: Fix up unregistration of vt drivers
vt: Don't ignore unbind errors in vt_unbind
drm/i915: Fixup global gtt cleanup
drm/i915: Kick out vga console
Link: http://lkml.kernel.org/r/1401980308-5116-1-git-send-email-daniel.vetter@ffwll.ch
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Touching the VGA resources on an IVB EFI machine causes hard hangs when
we then kick out the efifb. Ouch.
Apparently this also prevents unclaimed register errors on hsw and
hard machine hangs on my i855gm when trying to unbind fbcon.
Also, we want this to make I915_FBDEV=n safe.
v2: Rebase and pimp commit message.
v3: We also need to unregister the vga console, otherwise the unbind
of the fb console before module unload might resurrect it again.
v4: Ignore errors when the vga console is already unregistered - this
can happen when e.g. reloading i915.ko.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The global gtt is setup up in 2 parts, so we need to be careful
with the cleanup. For consistency shovel it all into the ->cleanup
callback, like with ppgtt.
Noticed because it blew up in the out_gtt: cleanup code while
fiddling with the vgacon code.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Otherwise the loop will never stop since we don't make any
forward progress. Noticed while breaking this accidentally
in a painful attempt to make vga_con unregistering work.
With this patch we'll bail out on the first attempt, which
at least leaves a useful enough system behind for debugging.
Livelocks on console_lock just aren't fun.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
A bunch of issues:
- We should not kick out the default console (which is tracked in
conswitchp), so check for that.
- Add better error codes so callers can differentiate between "something
went wrong" and "your driver isn't registered already". i915 needs
that so it doesn't fall over when reloading the driver and hence
vga_con is already unregistered.
- There's a mess with the driver flags: What we need to check for is
that the driver isn't used any more, i.e. unbound completely (FLAG_INIT).
And not whether it's the boot console or not (which is the only one
which doesn't have FLAG_MODULE). Otherwise there's no way to kick
out the boot console, which i915 wants to do to prevent havoc with
vga_con interferring (which tends to hang machines).
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
I don't fully understand the magic of the vt register/unregister
logic, but apparently everything but the inital console (as set
in the conswitchp pointer) is marked with FLAG_MODULE. Which means
if something unregistered the boot vt driver (e.g. i915.ko kicking
out vga_con) there's nothing left when trying to unbind e.g. fbcon
through sysfs.
But in most cases have the dummy console hanging around besides the
boot console, so this test is fairly dubious. What we actually want is
simply a different console than the one we want to unbind.
v2: Correct the commit message to clarify that the dummy console isn't
always around, but only in most cases (David).
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
If the timer putting the last forcewake refcount was pending and we
canceled it, we'll leak the corresponding forcewake and RPM references.
v2:
- do the ptr casting at the caller instead of adding a separate helper
for this (Chris)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
If a semaphore is waiting on another ring, which in turn happens to be
waiting on the first ring, but that second semaphore has been signalled,
we will be able to kick the second ring and so can treat the first ring
as a valid WAIT and not as HUNG.
v2: Be paranoid and cap the potential recursion depth whilst visiting
the semaphore signallers. (Mika)
References: https://bugs.freedesktop.org/show_bug.cgi?id=54226
References: https://bugs.freedesktop.org/show_bug.cgi?id=75502
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Otherwise we print out spurious processes on unused rings in the error
state.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
For reasons I can't claim to fully understand gen4 seems to require
backlight duty cycle setting after the backlight has been enabled, or
else black screen follows. I don't have documentation for the correct
sequence on gen4 either. Confirmed on Dell Latitude D630 and MacBook4,1.
This fixes a regression introduced by
commit b35684b8fa94e04f55fd38bf672b737741d2f9e2
Author: Jani Nikula <jani.nikula@intel.com>
Date: Thu Nov 14 12:13:41 2013 +0200
drm/i915: do full backlight setup at enable time
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=75791
Reported-and-tested-by: mcy@lm7.fr
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79423
Reported-and-tested-by: Marc Milgram <mmilgram@redhat.com>
Cc: Stable <stable@vger.kernel.org> # 3.14+
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
On certain platforms pixel_multiplier is read out in
.get_pipe_config(), but it also gets used to calculate the
pixel clock in intel_sdvo_get_config(). If the pipe is disable
but some SDVO outputs are active, we may end up dividing by zero
in intel_sdvo_get_config().
To avoid the problem simply check for zero pixel_multiplier and skip
the division. Another attempt at fixing this involved populating
pixel_multiplier to 1 even for disabled pipes, but that triggered a
WARN because SDVO_CMD_GET_CLOCK_RATE_MULT command failed and thus
encoder_pixel_multiplier was left at zero and didn't match
pipe_config->pixel_multiplier.
The "divide by pixel_multiplier" operation got introduced here:
commit 18442d08786472c63a0a80c27f92b033dffc26de
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Sep 13 16:00:08 2013 +0300
drm/i915: Fix port_clock and adjusted_mode.clock readout all over
and it has caused a regression on certain machines since they would
hit the div-by-zero during resume.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76520
Cc: <stable@vger.kernel.org> # 3.13+
Tested-by: Tim Richardson <tim@tim-richardson.net>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
