ACPICA commit 06198cfd96ef271f554a50f1830a5975468c39ac
ACPICA commit 8a3c1df1edb5f9fc5c940500c598c0107d30df71
Version 20150410.
Link: https://github.com/acpica/acpica/commit/06198cfd
Link: https://github.com/acpica/acpica/commit/8a3c1df1
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 6853da4c0a99b49d62d6c58d22956cd6ff5759a9
The following commit has fixed local printf issue in width.prec:
Commit: 3589b8b8af
Subject: ACPICA: Utilities: Fix local printf issue.
But this commit only resets width/precision/quialifier to fix the reported
issue and doesn't fix other states issues. So now we still can see breakage
in format types and integer bases.
This patch resets format type/base states for local printf to fix this
issue. Lv Zheng.
Linux kernel is not affected by this patch as acpi_ut_vsnprintf() hasn't
been enabled in the kernel.
Link: https://github.com/acpica/acpica/commit/6853da4c
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 330e3b7ec96fbd2e0677b786c09d86be36dd5673
Cleanup of LPIT table output (Dean Nelson)
Split some long lines.
Link: https://github.com/acpica/acpica/commit/330e3b7e
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit a2c590ce9bff850e3abf4fd430cede860a3cb1fa
This is the Microsoft Data Management table.
MSDM table is not used in the Linux kernel.
Link: https://github.com/acpica/acpica/commit/a2c590ce
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit c73195e13d6ad53dd7f03f86cea03c7dec72ffd3
Update to latest table definition, which contains major changes.
SLIC table is not used in the Linux kernel.
Link: https://github.com/acpica/acpica/commit/c73195e1
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 657dc227672709895df3192fa5ea59a649b9a76f
Updates the dump buffer utility to comment out the ASCII part
of buffer dump. Prevents some tools from getting confused.
Link: https://github.com/acpica/acpica/commit/657dc227
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 3ec867764b079a98d8097d705c9f7b68270c04ec
This patch removes unused AML_INT_STATICSTRING_OP. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/3ec86776
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 7af00219681ab35ebe57d64a9189fd04a5a026d8
Windows uses a value of 2, and has no plans to ever change this. So, _REV is
essentially useless for its primary purpose.
Worse, some BIOS vendors have used the difference in _REV values between
Windows and ACPICA to indicate which one is running.
It has been decided by the ACPI community to deprecate this method, and return
1 for ACPI 1.0 (32-bit integers) and 2 for ACPI 2.0 and greater (both 32-bit
and 64-bit integers.
ACPICA is changed to reflect this.
Link: https://github.com/acpica/acpica/commit/7af00219
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit b293f602a67da478ae0bec129e68bd99787d9908
This change adds this string for Windows 10.
Link: https://github.com/acpica/acpica/commit/b293f602
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit d115fe2ffdab449d6107d58580c5afd0a81d65fe
This change adds the basic low-level infrastructure for the External
AML opcode. The interpreter will simply ignore this op, as the op
is intended for use by the disassembler only.
Note that External() opcode is useful for disassembler, interpreter
can simply ignore it and still return exceptions for unknown control
methods so the kernel part only includes the grammar definition of
External() opcode in order to ignore it but doesn't interpret it.
Link: https://github.com/acpica/acpica/commit/d115fe2f
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 4f9e950d41cd6f6c704d5d6cf518647620d65e99
Add support to fold expressions with a target operand -- these are
folded and converted to a Store operator:
Add (4, 3, INT1) --> Store (7, INT1)
Also supports ASL+ constructs:
INT1 = 4 + 3 --> Store (7, INT1)
Linux kernel is not affected by this patch.
Link: https://github.com/acpica/acpica/commit/4f9e950d
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit f5d2ff3fa05341d9fe27250fcb2e14c7f871432c
For dynamically loaded tables that have unknown ACPI signatures,
this option (-df) forces the disassembler to treat the table as if
it contains valid AML code (like a DSDT or SSDT). Otherwise, the
disassembler will treat the table as an unkown data table and
simply do a hex dump of the table.
Linux kernel is not affected by this patch.
Link: https://github.com/acpica/acpica/commit/f5d2ff3f
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit f65d0e5b880860a6da0c336b7c48139d1469f5b4
- Remove unused variables
- Update to use standard naming/capitalization convention.
Linux kernel is not affected by this patch.
Link: https://github.com/acpica/acpica/commit/f65d0e5b
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 184f3cc4d162a6b6b2005eacd8be2fe55f19a245
- Change global #ifdef to check for ACPI_DEBUGGER only.
- Cleanup some long lines and misaligned code.
Link: https://github.com/acpica/acpica/commit/184f3cc4
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 84f3569db7accc576ace2dae81d101467254fe9d
Was using %d instead of properly using %u.
This patch only affects acpidump tool.
Link: https://github.com/acpica/acpica/commit/84f3569d
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 46dc081e570b1363af1e368980201cbb65c4100f
Update for some recent changes, detected by MSVC and FreeBSD builds.
Link: https://github.com/acpica/acpica/commit/46dc081e
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit f92a08512b0b35dce4a7fc6a73216674a3c2541b
Some conditional compilation definitions are wrong across header and source
files. This patch corrects them for the resources component.
NOTE that a further patch in this patchset cleans up all ACPI_EXEC_APP,
converting them into ACPI_DEBUGGER, including part of this change.
Link: https://github.com/acpica/acpica/commit/f92a0851
Reported-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 9a5982afbebc56289c4834b5f6dac87e0f04af14
Some conditional compilation definitions are wrong across header and source
files. This patch corrects them for the utilities component.
Link: https://github.com/acpica/acpica/commit/9a5982af
Reported-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 6eb364d790dd103bd4990f808e0095a421c437cb
acpi_tb_store_table() implements a logic that is only correct to iasl. So it
won't be used by any other utilities except iasl. This function is
complained by the kernel users as an unused function. The best choice to
stop releasing it to the Linux kernel should be moving it to adisasm.c.
ACPI table manager can use both struct acpi_table_desc (direct referencing)
and table index (indirect referencing) as the descriptor to the table, so
acpi_tb_get_next_root_index() is extended to return both of them to allow
maximum usability from the callers. NOTE that indirect referencing is a
design result to meet the boot stage static allocation requirement for the
table descriptors.
This is a linuxized acpi_tb_store_table() removing result, there should be
no functional changes introduced to the Linux kernel by this patch except
the additonal kernel unused argument for acpi_tb_get_next_root_index()
(renamed to acpi_tb_get_next_root_index()). This argument is used in the
ACPICA upstream.
Link: https://github.com/acpica/acpica/commit/6eb364d7
Reported-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 2a9ebd974aee41391f4b0edcd4f0cc5ee23ec2f8
Remove the function acpi_ut_create_pkg_state_and_push() that is not used anywhere.
This was partially found by using a static code analysis program called cppcheck.
Link: https://github.com/acpica/acpica/commit/2a9ebd97
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 3d9fb6d1f216a78ad098d3ad23f1304376c2f4ef
The macro __DATE__ and friends is not allowed in the Linux kernel. Also,
including the build time in output doesn't seem to provide any value.
Link: https://github.com/acpica/acpica/commit/3d9fb6d1
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Acked-by: David E. Box <david.e.box@linux.intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit e25d791e4b3d5b9f4ead298269610cb05f89749a
There is a facility in Linux, developers can obtain GPE and fixed event
status via /sys/firmware/interrupts/. This is implemented using
acpi_get_event_status() and acpi_get_gpe_status(). Recently while debugging some
GPE race issues, it is found that the facility is lacking in the ability to
obtain real hardware register values, the confusing information makes
debugging difficult.
This patch modifies acpi_get_gpe_status() to return EN register values to fix
this gap. Then flags returned from acpi_get_event_status() and
acpi_get_gpe_status() are also cleaned up to reflect this change.
The old ACPI_EVENT_FLAG_SET is carefully kept to avoid regressions. It can
be deleted after we can make sure all its references are removed from OSPM
code. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/e25d791e
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit c70434d4da13e65b6163c79a5aa16b40193631c7
ACPI_MTX_TABLES is acquired and released by the callers of
acpi_tb_install_standard_table() so releasing it in the function itself is
causing the following error in Linux kernel if the table is reloaded:
ACPI Error: Mutex [0x2] is not acquired, cannot release (20141107/utmutex-321)
Call Trace:
[<ffffffff81b0bd48>] dump_stack+0x4f/0x7b
[<ffffffff81546bf5>] acpi_ut_release_mutex+0x47/0x67
[<ffffffff81544357>] acpi_load_table+0x73/0xcb
Link: https://github.com/acpica/acpica/commit/c70434d4
Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit aacf863cfffd46338e268b7415f7435cae93b451
It is reported that on a physically 64-bit addressed machine, 32-bit kernel
can trigger crashes in accessing the memory regions that are beyond the
32-bit boundary. The region field's start address should still be 32-bit
compliant, but after a calculation (adding some offsets), it may exceed the
32-bit boundary. This case is rare and buggy, but there are real BIOSes
leaked with such issues (see References below).
This patch fixes this gap by always defining IO addresses as 64-bit, and
allows OSPMs to optimize it for a real 32-bit machine to reduce the size of
the internal objects.
Internal acpi_physical_address usages in the structures that can be fixed
by this change include:
1. struct acpi_object_region:
acpi_physical_address address;
2. struct acpi_address_range:
acpi_physical_address start_address;
acpi_physical_address end_address;
3. struct acpi_mem_space_context;
acpi_physical_address address;
4. struct acpi_table_desc
acpi_physical_address address;
See known issues 1 for other usages.
Note that acpi_io_address which is used for ACPI_PROCESSOR may also suffer
from same problem, so this patch changes it accordingly.
For iasl, it will enforce acpi_physical_address as 32-bit to generate
32-bit OSPM compatible tables on 32-bit platforms, we need to define
ACPI_32BIT_PHYSICAL_ADDRESS for it in acenv.h.
Known issues:
1. Cleanup of mapped virtual address
In struct acpi_mem_space_context, acpi_physical_address is used as a virtual
address:
acpi_physical_address mapped_physical_address;
It is better to introduce acpi_virtual_address or use acpi_size instead.
This patch doesn't make such a change. Because this should be done along
with a change to acpi_os_map_memory()/acpi_os_unmap_memory().
There should be no functional problem to leave this unchanged except
that only this structure is enlarged unexpectedly.
Link: https://github.com/acpica/acpica/commit/aacf863c
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=87971
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=79501
Reported-and-tested-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reported-and-tested-by: Sial Nije <sialnije@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit b60612373a4ef63b64a57c124576d7ddb6d8efb6
For physical addresses, since the address may exceed 32-bit address range
after calculation, we should use 0x%8.8X%8.8X instead of ACPI_PRINTF_UINT
and ACPI_FORMAT_UINT64() instead of
ACPI_FORMAT_NATIVE_UINT()/ACPI_FORMAT_TO_UINT().
This patch also removes above replaced macros as there are no users.
This is a preparation to switch acpi_physical_address to 64-bit on 32-bit
kernel builds.
Link: https://github.com/acpica/acpica/commit/b6061237
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 7f06739db43a85083a70371c14141008f20b2198
For physical addresses, since the address may exceed 32-bit address range
after calculation, we should use %8.8X%8.8X (see ACPI_FORMAT_UINT64()) to
convert the %p formats.
This is a preparation to switch acpi_physical_address to 64-bit on 32-bit
kernel builds.
Link: https://github.com/acpica/acpica/commit/7f06739d
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 154f6d074dd38d6ebc0467ad454454e6c5c9ecdf
There are code pieces converting pointers using "(acpi_physical_address) x"
or "ACPI_CAST_PTR (t, x)" formats, this patch cleans up them.
Known issues:
1. Cleanup of "(ACPI_PHYSICAL_ADDRRESS) x" for a table field
For the conversions around the table fields, it is better to fix it with
alignment also fixed. So this patch doesn't modify such code. There
should be no functional problem by leaving them unchanged.
Link: https://github.com/acpica/acpica/commit/154f6d07
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit c327986430b7eb170c17d0f45735fe71bb62a810
The conversion converts an acpi_physical_address to acpi_physical_address,
this patch thus removes such useless conversion.
Link: https://github.com/acpica/acpica/commit/c3279864
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 9e2d8180f4d5e61949b17513bae8aff6412f62dd
The offset calculation needn't convert a pointer to a special integer type.
So this patch uses ACPI_TO_INTEGER() instead.
This patch only affects acpidump tool.
Link: https://github.com/acpica/acpica/commit/9e2d8180
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 7d9fd64397d7c38899d3dc497525f6e6b044e0e3
OSPMs like Linux expect an acpi_physical_address returning value from
acpi_find_root_pointer(). This triggers warnings if sizeof (acpi_size) doesn't
equal to sizeof (acpi_physical_address):
drivers/acpi/osl.c:275:3: warning: passing argument 1 of 'acpi_find_root_pointer' from incompatible pointer type [enabled by default]
In file included from include/acpi/acpi.h:64:0,
from include/linux/acpi.h:36,
from drivers/acpi/osl.c:41:
include/acpi/acpixf.h:433:1: note: expected 'acpi_size *' but argument is of type 'acpi_physical_address *'
This patch corrects acpi_find_root_pointer().
Link: https://github.com/acpica/acpica/commit/7d9fd643
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch reduces source code differences between the Linux kernel and the
ACPICA upstream so that the linuxized ACPICA 20150410 release can be
applied with reduced human intervention.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Pull vfs and fs fixes from Al Viro:
"Several AIO and OCFS2 fixes"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
ocfs2: _really_ sync the right range
ocfs2_file_write_iter: keep return value and current position update in sync
[regression] ocfs2: do *not* increment ->ki_pos twice
ioctx_alloc(): fix vma (and file) leak on failure
fix mremap() vs. ioctx_kill() race
Pull last minute thermal-SoC management fixes from Eduardo Valentin:
"Specifics:
- Minor fixes on ST and RCAR thermal drivers.
- Avoid flooding kernel log when driver returns -EAGAIN.
Note: I am sending this pull on Rui's behalf while he fixes issues in
his Linux box"
* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal:
drivers: thermal: st: remove several sparse warnings
thermal: constify of_device_id array
thermal: Do not log an error if thermal_zone_get_temp returns -EAGAIN
thermal: rcar: Fix typo in r8a73a4 SoC name
This patch backs out a change that came in during the merge window which
selects a configuration for GPIO4 on pcm512x CODECs that may not be
suitable for all systems using the device. Changes for v4.1 will make
this properly configurable but for now it's safest to revert to the
v3.19 behaviour and leave the pin configuration alone.
Sorry for sending this direct at the last minute but due to the GPIO
misuse it'd be really good to get it in the release and I'd not realised
it hadn't been sent yet - between some travel, a job change and other
non-urgent fixes coming in I'd lost track of the urgency. It's been in
-next for several weeks now, is isolated to the driver and fairly clear
to inspection.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJVKY6pAAoJECTWi3JdVIfQkeAH/1d9FBe2VEqkDR8uJ8T7STsM
1PWg4pT2dLCRiqqhFgrZkKGqdyVCUWbXFz/ksGoK3bip8VMy8naBen1xKdyWgcQT
ZZuGQfywFGxOQSI0vdZSXdr1XyQO47AFRiJ2H9NQEOIMOzCRsjpAtihhkZL8rrCn
AwwViO6TFg09gijkQdbVsm6fxCBlDHM46/EhxP+Xo2K4TEOEeT+ZKxX6IpcJNmA5
Sw6TgyeQwu8LfHwNREczcojmk1wapytZvVivbNedNw7B6I1ujdPIsmnHWFWbiWv5
lfhcM77VLKmv3mwB/v1yRBEf3lNCgqn523N+S8Al9SjDkdLyibhuAWqZXUzsjqY=
=TbSp
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v4.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound
Pull last-minute ASoC fix from Mark Brown:
"This patch backs out a change that came in during the merge window
which selects a configuration for GPIO4 on pcm512x CODECs that may not
be suitable for all systems using the device. Changes for v4.1 will
make this properly configurable but for now it's safest to revert to
the v3.19 behaviour and leave the pin configuration alone.
Sorry for sending this direct at the last minute but due to the GPIO
misuse it'd be really good to get it in the release and I'd not
realised it hadn't been sent yet - between some travel, a job change
and other non-urgent fixes coming in I'd lost track of the urgency.
It's been in -next for several weeks now, is isolated to the driver
and fairly clear to inspection"
* tag 'asoc-fix-v4.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound:
ASoC: pcm512x: Remove hardcoding of pll-lock to GPIO4
Currently GPIO4 is hardcoded to output the pll-lock signal.
Unfortunately this is after the pll-out GPIO is configured which
is selectable in the device tree. Therefore it is not possible to
use GPIO4 for pll-out. Therefore this patch removes the
configuration of GPIO4.
Signed-off-by: Howard Mitchell <hm@hmbedded.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
This reverts commit ecc19d1786.
It added a new warning to try to encourage driver writers to set the
device capabities properly, but drivers haven't been updated and in the
meantime it just generaters a scary message that users cannot actually
do anything about.
Warnings like these are appropriate if you actually expect to fix the
code that causes them. They are not appropriate for releases.
Requested-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Jan Engelhardt reports a strange oops with an invalid ->sense_buffer
pointer in scsi_init_cmd_errh() with the blk-mq code.
The sense_buffer pointer should have been initialized by the call to
scsi_init_request() from blk_mq_init_rq_map(), but there seems to be
some non-repeatable memory corruptor.
This patch makes sure we initialize the whole struct request allocation
(and the associated 'struct scsi_cmnd' for the SCSI case) to zero, by
using __GFP_ZERO in the allocation. The old code initialized a couple
of individual fields, leaving the rest undefined (although many of them
are then initialized in later phases, like blk_mq_rq_ctx_init() etc.
It's not entirely clear why this matters, but it's the rigth thing to do
regardless, and with 4.0 imminent this is the defensive "let's just make
sure everything is initialized properly" patch.
Tested-by: Jan Engelhardt <jengelh@inai.de>
Acked-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull dmaengine fix from Vinod Koul:
"I have one more fix to fix the boot warning on cppi driver due to
missing capabilities"
* 'fixes' of git://git.infradead.org/users/vkoul/slave-dma:
dmaengine: cppi41: add missing bitfields
fixed before 4.0 is released.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEABECAAYFAlUogwcACgkQIXnXXONXERfnbACgjUM1MSXOSFDqcJ8tk7v5ZWX5
3XQAoKgd/AXtjjrIIh5j9CWlf/pvbA/T
=c2uq
-----END PGP SIGNATURE-----
Merge tag 'for-linus-4.0-1' of git://git.code.sf.net/p/openipmi/linux-ipmi
Pull late ipmi fixes from Corey Minyard:
"Some annoying issues in the IPMI driver that would be good to have
fixed before 4.0 is released.
These got reported or discovered late, but they will avoid some
situations that would cause lots of log spam and in one case a
deadlock"
* tag 'for-linus-4.0-1' of git://git.code.sf.net/p/openipmi/linux-ipmi:
ipmi_ssif: Use interruptible completion for waiting in the thread
ipmi/powernv: Fix minor locking bug
ipmi: Handle BMCs that don't allow clearing the rcv irq bit
Add missing directions, residue_granularity,
srd_addr_widths and dst_addr_widths bitfields.
Without those we will see a kernel WARN()
when loading musb on am335x devices.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
The code was using an normal completion, but that caused stuck
task errors after a while. Use an interruptible one to avoid that.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
If ipmi_powernv_recv(...) is called without a current message it
prints a warning and returns. However it fails to release the message
lock causing the system to dead lock during any subsequent IPMI
operations.
This error path should never normally be taken unless there are bugs
elsewhere in the system.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Some BMCs don't let you clear the receive irq bit in the global
enables. This is kind of silly, but they give an error if you
try to clear it. Compensate for this by detecting the situation
and working around it.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Tested-by: Thomas D <whissi@whissi.de>
Reviewed-by: Thomas D <whissi@whissi.de>
This is our remaining set of three fixes for 4.0: two oops fixes(one for cable
pulls triggering oopses and the other be2iscsi specific) and one warn on in
sysfs on multipath devices using enclosures.
Signed-off-by: James Bottomley <JBottomley@Odin.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAABAgAGBQJVKFlCAAoJEDeqqVYsXL0MjOsH/j0DIeMOa7p5JdryKZNY+LY4
HHfVgAK4T+bNZQUOCq/Dctn19CltuJGoDGkY2P4m1YG+mz8NLCm2aEAKp9efhho6
6cLv0An/PlQhFuurbzo9BXsEb93ZENf6ng0WJZ3iOyqD9FA9X+0mDAfXDfJ4mwH3
aGa0NE4bbqhNotWjpdFPIDqU2uwk4pV3M/BRx3JmeIIR2BtaWXkKxTq5tmLo9DDN
22Seu/RJqV7O3WdphLLoN+615eCcroOru54DnQtKQ3/pQeC+6gyHcjkq02KjJ9D+
wBNltUrtqzreDrgF2D6uaxT3NkQFFPlkzjD6Ma5tq5637sT9Tch8/UNTMzs5UgU=
=AbF2
-----END PGP SIGNATURE-----
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"This is our remaining set of three fixes for 4.0: two oops fixes(one
for cable pulls triggering oopses and the other be2iscsi specific) and
one warn on in sysfs on multipath devices using enclosures"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
Defer processing of REQ_PREEMPT requests for blocked devices
be2iscsi: Fix kernel panic when device initialization fails
enclosure: fix WARN_ON removing an adapter in multi-path devices
Pull SCSI target fixes from Nicholas Bellinger:
"Just a few small fixes:
Two from Andy, the first addresses a v4.0 target specific regression
to a user visible configfs attribute, and the second adds a set of
missing brackets around IPv6 discovery portal information within
iscsi-target.
And one from Mike that fixes an OOPs regression in traditional
iscsi-target when an iovec allocation fails, that has been present
since v3.10.y code. (CC'd to stable)"
* git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
iscsi target: fix oops when adding reject pdu
iscsi-target: TargetAddress in SendTargets should bracket ipv6 addresses
target: Allow userspace to write 1 to attrib/emulate_fua_write
This fixes a oops due to a double list add when adding a reject PDU for
iscsit_allocate_iovecs allocation failures. The cmd has already been
added to the conn_cmd_list in iscsit_setup_scsi_cmd, so this has us call
iscsit_reject_cmd.
Note that for ERL0 the reject PDU is not actually sent, so this patch
is not completely tested. Just verified we do not oops. The problem is the
add reject functions return -1 which is returned all the way up to
iscsi_target_rx_thread which for ERL0 will drop the connection.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Cc: <stable@vger.kernel.org> # v3.10+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Here are fixes gathered for 4.0-final; one FireFire endian fix, two
USB-audio quirks, and three HD-audio quirks.
All relatively small and device-specific fixes, should be pretty safe
to apply.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJVJ6tVAAoJEGwxgFQ9KSmkJ58QAJx99DJpHAXNSodOX9oEtvO7
FttZpUWUL+sx+k0H6f5VLC6IuUVM3gdCQiBw+R3ZPvu6zEg/PuoQPvuD1vYEjg4O
vK61OwI8LEvuTGvjRuu5apSZBlEitbJc0gevNSVU3C0XZRrSPmPpTa2172mdsdbW
xlYG4M8eFy3ljMqKp41obA1/zo5tZFZ8G3c0Y7zFMz0P0p0LXLXU7E4BcZ6Lwfi/
TJZjUIcbwbiHgNlIhSHt0ONMauG9PlvbmaBQCrHhbOY8mhxAOeW7KZmYoCQCfa5T
d1vLHT3yXw4Y1mkC9g5D60ncNMmMZdyqtESh8/R9EEvKHzpCsfUWaPL7uXbAWoL7
36muciYXL3VGEhQfEPS5yEJU1dFRcBkI6TYQ4jYJqnTwg3oZAslHThnxcdECNs3N
vsp4JeizNFOfnoj5fA3nBhTnnwlhw7iBQ+t2mZJoFTKIedwu78ZdJCfO2JhrowED
NnRvk4j9SkkzDdvj0rEqZCpVh2+72h1a02MaSq+HQsxjRguEsdbJ8NVtiNlJxJ17
CUKrif8iGIbZb2SEswh05NQCDJzmBDZvDyyk/sQNLWWatRqF2JxcTef8zoY4bc9e
t7GNKJSjdGn1kQako7pRfnCWnAdHJa88Z4NBR5tdtbtAXGn1tsr70TJq4TTBSeT/
1+wFD8DvNl82lSjU3bpc
=hSdz
-----END PGP SIGNATURE-----
Merge tag 'sound-4.0' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"Here are fixes gathered for 4.0-final; one FireFire endian fix, two
USB-audio quirks, and three HD-audio quirks.
All relatively small and device-specific fixes, should be pretty safe
to apply"
* tag 'sound-4.0' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: usb - Creative USB X-Fi Pro SB1095 volume knob support
ALSA: hda - Fix headphone pin config for Lifebook T731
ALSA: bebob: fix to processing in big-endian machine for sending cue
ALSA: hda/realtek - Make more stable to get pin sense for ALC283
ALSA: usb-audio: don't try to get Benchmark DAC1 sample rate
ALSA: hda/realtek - Support Dell headset mode for ALC256
Remove the end address checking for flushda function. We need to flush
each address line for flushda instruction, from start to end address.
This is because flushda instruction only flush the cache if tag and line
fields are matched.
Change to use ldwio instruction (bypass cache) to load the instruction
that causing trap. Our interest is the actual instruction that executed
by the processor, this should be uncached.
Note, EA address might be an userspace cached address.
Signed-off-by: Ley Foon Tan <lftan@altera.com>