summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2015-04-13Merge branch 'acpi-scan'Rafael J. Wysocki
* acpi-scan: ACPI / scan: Rework modalias creation when "compatible" is present ACPI / scan: Take the PRP0001 position in the list of IDs into account ACPI / scan: Simplify acpi_match_device() ACPI / scan: Generalize of_compatible matching ACPI / scan: fix fixed event handler return value
2015-04-13Merge branches 'acpi-pm', 'acpi-enumeration' and 'acpi-sysfs'Rafael J. Wysocki
* acpi-pm: ACPI / PM: Enable all wakeup GPEs in suspend-to-idle ACPI / sleep: Drop acpi_suspend() which is not used * acpi-enumeration: ACPI: Add acpi_device_uid() for convenience ACPI: Update GPIO documentation to mention _DSD * acpi-sysfs: ACPI / sysfs: Treat the count field of counter_show() as unsigned
2015-04-13ACPI / scan: Rework modalias creation when "compatible" is presentRafael J. Wysocki
Currently, the ACPI modalias creation covers two mutually exclusive cases: If the PRP0001 device ID is present in the device's list of ACPI/PNP IDs and the "compatible" property is present in _DSD, the created modalias will follow the OF rules of modalias creation. Otherwise, ACPI rules are used. However, that is not really desirable, because the presence of PRP0001 in the list of device IDs generally does not preclude using other ACPI/PNP IDs with that device and those other IDs may be of higher priority. In those cases, the other IDs should take preference over PRP0001 and therefore they also should be present in the modalias. For this reason, rework the modalias creation for ACPI so that it shows both the ACPI-style and OF-style modalias strings if the device has a non-empty list of ACPI/PNP IDs (other than PRP0001) and a valid "compatible" property at the same time. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2015-04-12Linux 4.0v4.0Linus Torvalds
2015-04-12sparc: Fix execution domain removalGuenter Roeck
ksp must be 8-byte aligned. Cc: Richard Weinberger <richard@nod.at> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12Remove rest of exec domains.Richard Weinberger
It is gone from all archs, now we can remove the final bits. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12arch: Remove exec_domain from remaining archsRichard Weinberger
Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12arc: Remove signal translation and exec_domainRichard Weinberger
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12xtensa: Remove signal translation and exec_domainRichard Weinberger
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12xtensa: Autogenerate offsets in struct thread_infoRichard Weinberger
Maintaining offsets by hand is no fun. Reported-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12x86: Remove signal translation and exec_domainRichard Weinberger
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12unicore32: Remove signal translation and exec_domainRichard Weinberger
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12um: Remove signal translation and exec_domainRichard Weinberger
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12tile: Remove signal translation and exec_domainRichard Weinberger
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12sparc: Remove signal translation and exec_domainRichard Weinberger
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at> Acked-by: David S. Miller <davem@davemloft.net>
2015-04-12sh: Remove signal translation and exec_domainRichard Weinberger
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12s390: Remove signal translation and exec_domainRichard Weinberger
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12mn10300: Remove signal translation and exec_domainRichard Weinberger
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12microblaze: Remove signal translation and exec_domainRichard Weinberger
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12m68k: Remove signal translation and exec_domainRichard Weinberger
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12m32r: Remove signal translation and exec_domainRichard Weinberger
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12m32r: Autogenerate offsets in struct thread_infoRichard Weinberger
Maintaining offsets by hand is no fun. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12frv: Remove signal translation and exec_domainRichard Weinberger
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12blackfin: Remove exec_domain usageRichard Weinberger
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12blackfin: Autogenerate offsets in struct thread_infoRichard Weinberger
Maintaining offsets by hand is no fun. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12arm64: Remove signal translation and exec_domainRichard Weinberger
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12arm: Remove signal translation and exec_domainRichard Weinberger
As execution domain support is gone we can remove signal translation from the signal code and remove exec_domain from thread_info. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12Remove execution domain supportRichard Weinberger
All users of exec_domain are gone, now we can get rid of that abandoned feature. To not break existing userspace we keep a dummy /proc/execdomains file which will always contain "0-0 Linux [kernel]". Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12ia64: Remove Linux/x86 exec domain supportRichard Weinberger
As this series removes exec domain support we can get rid of this hack. Signed-off-by: Richard Weinberger <richard@nod.at>
2015-04-12arm: Remove RISC OS personalityRichard Weinberger
The RISC OS personality seems to be unused and untested for a long time. It is doubtful whether this personality worked ever as expected. Let's rip it out. Signed-off-by: Richard Weinberger <richard@nod.at> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-04-12Merge remote-tracking branches 'asoc/topic/wm2200', 'asoc/topic/wm5100', ↵Mark Brown
'asoc/topic/wm8731', 'asoc/topic/wm8804' and 'asoc/topic/wm8996' into asoc-next
2015-04-12Merge remote-tracking branches 'asoc/topic/tegra', 'asoc/topic/tlv320aic23' ↵Mark Brown
and 'asoc/topic/ux500' into asoc-next
2015-04-12Merge remote-tracking branches 'asoc/topic/rt5641', 'asoc/topic/rt5677' and ↵Mark Brown
'asoc/topic/sh-cleanup' into asoc-next
2015-04-12Merge remote-tracking branches 'asoc/topic/omap', 'asoc/topic/qcom', ↵Mark Brown
'asoc/topic/rcar' and 'asoc/topic/rt286' into asoc-next
2015-04-12Merge remote-tracking branches 'asoc/topic/link-param', ↵Mark Brown
'asoc/topic/max98090', 'asoc/topic/max98925' and 'asoc/topic/nuc900' into asoc-next
2015-04-12Merge remote-tracking branches 'asoc/topic/jack', 'asoc/topic/jz4740' and ↵Mark Brown
'asoc/topic/kirkwood' into asoc-next
2015-04-12Merge remote-tracking branches 'asoc/topic/dmaengine', 'asoc/topic/fsi', ↵Mark Brown
'asoc/topic/fsl' and 'asoc/topic/fsl-ssi' into asoc-next
2015-04-12Merge remote-tracking branches 'asoc/topic/cx20442' and 'asoc/topic/davinci' ↵Mark Brown
into asoc-next
2015-04-12Merge remote-tracking branches 'asoc/topic/4554', 'asoc/topic/ab8500', ↵Mark Brown
'asoc/topic/ak4642', 'asoc/topic/arizona' and 'asoc/topic/atmel' into asoc-next
2015-04-12Merge remote-tracking branch 'asoc/topic/rt5645' into asoc-nextMark Brown
2015-04-12Merge remote-tracking branch 'asoc/topic/intel' into asoc-nextMark Brown
2015-04-12Merge remote-tracking branch 'asoc/topic/dapm' into asoc-nextMark Brown
2015-04-12Merge remote-tracking branch 'asoc/topic/core' into asoc-nextMark Brown
2015-04-12Merge tag 'asoc-v4.1' into asoc-nextMark Brown
ASoC: Changes for v4.1 A selection of changes for v4.1 so far. The main things are: - Move of jack registration to the card where it belongs. - Support for DAPM routes specified by both the machine driver and DT. # gpg: Signature made Thu 05 Mar 2015 01:10:27 GMT using RSA key ID 5D5487D0 # gpg: WARNING: digest algorithm MD5 is deprecated # gpg: please see https://gnupg.org/faq/weak-digest-algos.html for more information # gpg: Oops: keyid_from_fingerprint: no pubkey # gpg: Good signature from "Mark Brown <broonie@sirena.org.uk>" # gpg: aka "Mark Brown <broonie@debian.org>" # gpg: aka "Mark Brown <broonie@kernel.org>" # gpg: aka "Mark Brown <broonie@tardis.ed.ac.uk>" # gpg: aka "Mark Brown <broonie@linaro.org>" # gpg: aka "Mark Brown <Mark.Brown@linaro.org>"
2015-04-12Merge remote-tracking branch 'asoc/fix/wm8741' into asoc-linusMark Brown
2015-04-12Merge remote-tracking branches 'asoc/fix/ak4642', 'asoc/fix/atmel', ↵Mark Brown
'asoc/fix/cs4271', 'asoc/fix/davinci' and 'asoc/fix/rcar' into asoc-linus
2015-04-12Merge remote-tracking branch 'asoc/fix/pcm512x' into asoc-linusMark Brown
2015-04-12Merge remote-tracking branch 'asoc/fix/intel' into asoc-linusMark Brown
2015-04-12Merge tag 'asoc-fix-v4.0-rc7' into asoc-linusMark Brown
ASoC: Last minute fix for v4.0 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. # gpg: Signature made Sat 11 Apr 2015 22:14:17 BST using RSA key ID 5D5487D0 # gpg: WARNING: digest algorithm MD5 is deprecated # gpg: please see https://gnupg.org/faq/weak-digest-algos.html for more information # gpg: Oops: keyid_from_fingerprint: no pubkey # gpg: Good signature from "Mark Brown <broonie@sirena.org.uk>" # gpg: aka "Mark Brown <broonie@debian.org>" # gpg: aka "Mark Brown <broonie@kernel.org>" # gpg: aka "Mark Brown <broonie@tardis.ed.ac.uk>" # gpg: aka "Mark Brown <broonie@linaro.org>" # gpg: aka "Mark Brown <Mark.Brown@linaro.org>"
2015-04-12ASoC: Intel: fix array_size.cocci warningskbuild test robot
sound/soc/intel/haswell/sst-haswell-ipc.c:646:28-29: WARNING: Use ARRAY_SIZE Use ARRAY_SIZE instead of dividing sizeof array with sizeof an element Semantic patch information: This makes an effort to find cases where ARRAY_SIZE can be used such as where there is a division of sizeof the array by the sizeof its first element or by any indexed element or the element type. It replaces the division of the two sizeofs by ARRAY_SIZE. Generated by: scripts/coccinelle/misc/array_size.cocci CC: Jie Yang <yang.jie@intel.com> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>