Age | Commit message (Collapse) | Author |
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc.git
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
Intel Lynxpoint PCH Low Power Subsystem has two general purpose SPI
controllers that are LPSS_SSP compatible. These controllers are enumerated
from ACPI namespace with ACPI IDs INT33C0 and INT33C1.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Lu Cao <lucao@marvell.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Intel LPSS SPI is pretty much the same as the PXA27xx SPI except that it
has few additional features over the original:
o FIFO depth is 256 entries
o RX FIFO has one watermark
o TX FIFO has two watermarks, low and high
o chip select can be controlled by writing to a register
The new FIFO registers follow immediately the PXA27xx registers but then there
are some additional LPSS private registers at offset 1k or 2k from the base
address. For these private registers we add new accessors that take advantage
of drv_data->lpss_base once it is resolved.
We add a new type LPSS_SSP that can be used to distinguish the LPSS devices
from others.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Lu Cao <lucao@marvell.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
This is useful when testing the functionality of the controller from userspace
and there aren't any real SPI slave devices connected to the bus.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Lu Cao <lucao@marvell.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
Drivers should put the device into low power states proactively whenever the
device is not in use. Thus implement support for runtime PM and use the
autosuspend feature to make sure that we can still perform well in case we see
lots of SPI traffic within short period of time.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Lu Cao <lucao@marvell.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
To be able to use DMA with this driver on non-PXA platforms we implement
support for the generic DMA engine API. This lets user to use different DMA
engines with little or no modification to the driver.
Request lines and channel numbers can be passed to the driver from the
platform specific data.
The DMA engine implementation will be selected by default even on PXA
platform. User can select the legacy DMA API by enabling Kconfig option
CONFIG_SPI_PXA2XX_PXADMA.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Lu Cao <lucao@marvell.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
The PXA SPI driver uses PXA platform specific private DMA implementation
which does not work on non-PXA platforms. In order to use this driver on
other platforms we break out the private DMA implementation into a separate
file that gets compiled only when CONFIG_SPI_PXA2XX_PXADMA is set. The DMA
functions are stubbed out if there is no DMA implementation selected (i.e
we are building on non-PXA platform).
While we are there we can kill the dummy DMA bits in pxa2xx_spi.h as they
are not needed anymore for CE4100.
Once this is done we can add the generic DMA engine support to the driver
that allows usage of any DMA controller that implements DMA engine API.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Lu Cao <lucao@marvell.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
The SPI controller of the AR7xxx/AR9xxx SoCs
have a special mode which allows the SoC to
directly read data from SPI flash chips. In
this mode, the content of the SPI flash chip
can be accessed via a memory mapped region.
During early init time, the kernel expects
that the flash chip is accessible through
that memory region because it reads board
specific values (e.g. MAC address, WiFi
calibration data) from the flash on various
boards.
This is working if the kernel is loaded
directly by the bootloader because that
leaves the SPI controller in the special
mode. However it is not working in a kexec'd
kernel because the SPI driver does not restore
the special mode during shutdown.
The patch adds a shutdown handler to fix this
issue.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
Due to hardware limitations of the spi/flash frontend of the EBU we need to set
the SPI_MASTER_HALF_DUPLEX flag.
Signed-off-by: Thomas Langer <thomas.langer@lantiq.com>
Signed-off-by: John Crispin <blogic@openwrt.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
Rather than calling m->complete() directly we choose the sane way and call
spi_finalize_current_message instead.
Signed-off-by: Thomas Langer <thomas.langer@lantiq.com>
Signed-off-by: John Crispin <blogic@openwrt.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
This SPI controller does not support keeping CS asserted after sending
a transfer.
Since messages expected on this SPI controller are rather short, we can
work around it for normal use cases by sending all transfers at once in
a big full duplex stream.
This means that we cannot change the speed between transfers if they
require CS to be kept asserted, but these would have been rejected
before anyway because of the inability of keeping CS asserted.
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
With RT pre-empt patch applied to Linux kernel, the irq handler will be
force converted to an irq thread. spi driver can get back to back messages
from the slave device. In such cases, IRQ thread doesn't get a chance to
run to read the slave data. Hence the irq handler must be run in hard irq
context to read/write data from slave device. Otherwise, the kernel goes
into a deadlock. This patch fixes this issue when PREEMPT_RT_FULL is
enabled in the kernel. A dummy thread function is provided to satisfy the
request_threaded_irq() API. Passing a NULL for function also causes the
irq handler to be executed in the thread context.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
This patch reduces and simplifies initalization code by
using module_platform_driver().
With this change it's necessary to remove the __init annotation
to avoid section mismatch warnings.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
The hardware does not support keeping CS asserted after sending one
FIFO buffer worth of data, so reject transfers requiring CS being kept
asserted, either between transers or for a certain time after it,
or exceeding the FIFO size.
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
Acked-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
Use GFP_DMA in order to ensure that the memory we allocate for transfers
in spi_write_then_read() can be DMAed. On most platforms this will have
no effect.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
The driver should setup mode bits it supports, otherwise
adding an SPI device might fail even if the driver supports
the requested SPI mode.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
Remove deprecated cell-index property and use spi alias to
obtain the SPI PSC number used for SPI bus id.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
Some of the spi driver module remove hooks were annotated with __exit
and referenced with __exit_p(). Presumably these were supposed to be
__devinit, __devexit and __devexit_p() since __init/__exit for a
probe/remove hook has never been correct. They also got missed during
the big __devinit/__devexit purge since they didn't match the pattern.
Remove then now to be rid of it.
v2: purge __init also
Reported-by: Arnd Bergmann <arnd@arndb.de>
[Arnd set a patch cleaning up one, and then I found more]
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
Fix checkpatch warnings and error as below:
ERROR: "foo * bar" should be "foo *bar"
WARNING: please, no space before tabs
WARNING: quoted string split across lines
WARNING: msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.txt
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
Use devm_clk_get() and devm_request_irq() rather than clk_get() and
request_irq() to make cleanup paths more simple.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
Add an entry for MODULE_ALIAS().
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
SPI core make sure that all transfer has proper speed set
before calling low level spi transfer. Hence, it is not
require to have check in spi driver.
Remove the check for speed validity from transfer and use it directly.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
When spi client does the spi transfer and if it does not set
the speed for each transfer then set it as default
of spi device in spi core before calling low level transfer.
This will remove the extra check in low level driver for setting
speed.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
Currently we are initializing the SPI controller in
the chip select line function, and that function is
called once for each SPI device on the bus. If a
board has multiple SPI devices, the controller will
be initialized multiple times.
Introduce ath79_spi_{en,dis}able helper functions,
and call those from probe/response in order to avoid
the mutliple initialization of the controller.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
Use gpio_request_one() instead of multiple gpiolib calls.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
The spi_bitbang driver calls the chipselect function
of the driver from spi_bitbang_setup in order to
deselect the given SPI chip, so we don't have to
initialize the CS line here.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
The 'ath79_spi_txrx_mode0' function does not
set the SCK signal to LOW at the end of a word
transfer. This causes communications errors with
certain devices (e.g. the PCF2123 RTC chip).
The patch ensures that the SCK signal will be LOW.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
The driver uses the "as fast as it can" approach
to drive the SCK signal. However this does not
work with certain low speed SPI chips (e.g. the
PCF2123 RTC chip).
The patch adds per-bit slowdowns in order to be
able to use the driver with such chips as well.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
On MX23 the XFER_COUNT part in ctrl0 field in DMA descriptor was
improperly OR'd during the construction of DMA descriptor chain, instead
of being freshly set. Because of that too many bytes were being
expected from SPI during the last DMA cycle. This caused a timeout
(SSP_TIMEOUT) to happen in the processing of the last DMA descriptor,
and thus reads and writes were failing. This is a fix for the problem,
by clearing XFER_COUNT bytes in ctrl0 before setting the new XFER_COUNT
for DMA descriptor.
Signed-off-by: Juha Lumme <juha.lumme@gmail.com>
Acked-by: Marek Vasut <marex@denx.de>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
the driver is also compatible with SiRFmarco except SiRFprimaII,
so simply add "sirf,marco-spi" to OF match table.
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare
calls as required by common clock framework.
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc.git
Minor features and bug fixes for PXA, OMAP and GPIO deivce drivers and a
cosmetic change to the bitbang driver.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
The spi core make sure that each transfer structure have the proper
setting for bits_per_word before calling low level transfer APIs.
Hence it is no more require to check again in low level driver for
this field whether this is set correct or not. Removing such code
from low level driver.
The txx9 change also removes a test for bits_per_word set to 0, and
forcing it to 8 in that case. This can also be removed now since
spi_setup() ensures spi->bits_per_word is not zero.
if (!spi->bits_per_word)
spi->bits_per_word = 8;
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
Linux assigns a number to each spi_master in the system, but when the
platform used the device tree, the numbers are dynamically assigned and
are not predictable. In general this shouldn't matter since the kernel
doesn't use the bus number for anything other than matching a bus to
spi_boardinfo (not used for DT). However, sometimes userspace needs to
figure out which bus is which, so it makes sense to use the global
/aliases namespace to choose a specific bus number.
It is safe to derive the bus number from an alias because aliases will
never cause two buses to try and use the same bus number. (At one time
the cell-index property was used for this purpose, but cell-index has
the risk of an id collision).
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
This adds the capability to retrieve setup data from the device tree
node. The usage of platform data is still available.
Signed-off-by: Bastian Hecht <hechtb+renesas@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
This adds OF support to DaVinci SPI controller to configure platform
data through device bindings. Also replaces clk_enable() with
of clk_prepare_enable() as well as clk_disable() with
clk_disable_unprepare().
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
No actual errors have been found for completing
before disabling DMA request lines, but it just
looks more semantically correct that on our DMA
callback we quiesce the whole thing before stating
transfer is finished.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm
Pull more device-mapper fixes from Alasdair G Kergon:
"A fix for stacked dm thin devices and a fix for the new dm WRITE SAME
support."
* tag 'dm-3.8-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm:
dm: fix write same requests counting
dm thin: fix queue limits stacking
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid
PullHID fixes from Jiri Kosina:
- fix i2c-hid and hidraw interaction, by Benjamin Tissoires
- a quirk to make a particular device (Formosa IR receiver) work
properly, by Nicholas Santos
* 'for-3.8/upstream-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
HID: i2c-hid: fix i2c_hid_output_raw_report
HID: usbhid: quirk for Formosa IR receiver
HID: remove x bit from sensor doc
|
|
i2c_hid_output_raw_report is used by hidraw to forward set_report requests.
The current implementation of i2c_hid_set_report needs to take the
report_id as an argument. The report_id is stored in the first byte
of the buffer in argument of i2c_hid_output_raw_report.
Not removing the report_id from the given buffer adds this byte 2 times
in the command, leading to a non working command.
Reported-by: Andrew Duggan <aduggan@synaptics.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
When processing write same requests, fix dm to send the configured
number of WRITE SAME requests to the target rather than the number of
discards, which is not always the same.
Device-mapper WRITE SAME support was introduced by commit
23508a96cd2e857d57044a2ed7d305f2d9daf441 ("dm: add WRITE SAME support").
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Acked-by: Mike Snitzer <snitzer@redhat.com>
|
|
thin_io_hints() is blindly copying the queue limits from the thin-pool
which can lead to incorrect limits being set. The fix here simply
deletes the thin_io_hints() hook which leaves the existing stacking
infrastructure to set the limits correctly.
When a thin-pool uses an MD device for the data device a thin device
from the thin-pool must respect MD's constraints about disallowing a bio
from spanning multiple chunks. Otherwise we can see problems. If the raid0
chunksize is 1152K and thin-pool chunksize is 256K I see the following
md/raid0 error (with extra debug tracing added to thin_endio) when
mkfs.xfs is executed against the thin device:
md/raid0:md99: make_request bug: can't convert block across chunks or bigger than 1152k 6688 127
device-mapper: thin: bio sector=2080 err=-5 bi_size=130560 bi_rw=17 bi_vcnt=32 bi_idx=0
This extra DM debugging shows that the failing bio is spanning across
the first and second logical 1152K chunk (sector 2080 + 255 takes the
bio beyond the first chunk's boundary of sector 2304). So the bio
splitting that DM is doing clearly isn't respecting the MD limits.
max_hw_sectors_kb is 127 for both the thin-pool and thin device
(queue_max_hw_sectors returns 255 so we'll excuse sysfs's lack of
precision). So this explains why bi_size is 130560.
But the thin device's max_hw_sectors_kb should be 4 (PAGE_SIZE) given
that it doesn't have a .merge function (for bio_add_page to consult
indirectly via dm_merge_bvec) yet the thin-pool does sit above an MD
device that has a compulsory merge_bvec_fn. This scenario is exactly
why DM must resort to sending single PAGE_SIZE bios to the underlying
layer. Some additional context for this is available in the header for
commit 8cbeb67a ("dm: avoid unsupported spanning of md stripe boundaries").
Long story short, the reason a thin device doesn't properly get
configured to have a max_hw_sectors_kb of 4 (PAGE_SIZE) is that
thin_io_hints() is blindly copying the queue limits from the thin-pool
device directly to the thin device's queue limits.
Fix this by eliminating thin_io_hints. Doing so is safe because the
block layer's queue limits stacking already enables the upper level thin
device to inherit the thin-pool device's discard and minimum_io_size and
optimal_io_size limits that get set in pool_io_hints. But avoiding the
queue limits copy allows the thin and thin-pool limits to be different
where it is important, namely max_hw_sectors_kb.
Reported-by: Daniel Browning <db@kavod.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 EFI fixes from Peter Anvin:
"This is a collection of fixes for the EFI support. The controversial
bit here is a set of patches which bumps the boot protocol version as
part of fixing some serious problems with the EFI handover protocol,
used when booting under EFI using a bootloader as opposed to directly
from EFI. These changes should also make it a lot saner to support
cross-mode 32/64-bit EFI booting in the future. Getting these changes
into 3.8 means we avoid presenting an inconsistent ABI to bootloaders.
Other changes are display detection and fixing efivarfs."
* 'x86-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86, efi: remove attribute check from setup_efi_pci
x86, build: Dynamically find entry points in compressed startup code
x86, efi: Fix PCI ROM handing in EFI boot stub, in 32-bit mode
x86, efi: Fix 32-bit EFI handover protocol entry point
x86, efi: Fix display detection in EFI boot stub
x86, boot: Define the 2.12 bzImage boot protocol
x86/boot: Fix minor fd leakage in tools/relocs.c
x86, efi: Set runtime_version to the EFI spec revision
x86, efi: fix 32-bit warnings in setup_efi_pci()
efivarfs: Delete dentry from dcache in efivarfs_file_write()
efivarfs: Never return ENOENT from firmware
efi, x86: Pass a proper identity mapping in efi_call_phys_prelog
efivarfs: Drop link count of the right inode
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Peter Anvin:
"This is a collection of miscellaneous fixes, the most important one is
the fix for the Samsung laptop bricking issue (auto-blacklisting the
samsung-laptop driver); the efi_enabled() changes you see below are
prerequisites for that fix.
The other issues fixed are booting on OLPC XO-1.5, an UV fix, NMI
debugging, and requiring CAP_SYS_RAWIO for MSR references, just as
with I/O port references."
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
samsung-laptop: Disable on EFI hardware
efi: Make 'efi_enabled' a function to query EFI facilities
smp: Fix SMP function call empty cpu mask race
x86/msr: Add capabilities check
x86/dma-debug: Bump PREALLOC_DMA_DEBUG_ENTRIES
x86/olpc: Fix olpc-xo1-sci.c build errors
arch/x86/platform/uv: Fix incorrect tlb flush all issue
x86-64: Fix unwind annotations in recent NMI changes
x86-32: Start out cr0 clean, disable paging before modifying cr3/4
|
|
Various urgent EFI fixes and some warning cleanups for v3.8
* EFI boot stub fix for Macbook Pro's from Maarten Lankhorst
* Fix an oops in efivarfs from Lingzhu Xiang
* 32-bit warning cleanups from Jan Beulich
* Patch to Boot on >512GB RAM systems from Nathan Zimmer
* Set efi.runtime_version correctly
* efivarfs updates
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
|
It has been reported that running this driver on some Samsung laptops
with EFI can cause those machines to become bricked as detailed in the
following report,
https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
There have also been reports of this driver causing Machine Check
Exceptions on recent EFI-enabled Samsung laptops,
https://bugzilla.kernel.org/show_bug.cgi?id=47121
So disable it if booting from EFI since this driver relies on
grovelling around in the BIOS memory map which isn't going to work.
Cc: Corentin Chary <corentincj@iksaif.net>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Steve Langasek <steve.langasek@canonical.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
|
Originally 'efi_enabled' indicated whether a kernel was booted from
EFI firmware. Over time its semantics have changed, and it now
indicates whether or not we are booted on an EFI machine with
bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.
The immediate motivation for this patch is the bug report at,
https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
which details how running a platform driver on an EFI machine that is
designed to run under BIOS can cause the machine to become
bricked. Also, the following report,
https://bugzilla.kernel.org/show_bug.cgi?id=47121
details how running said driver can also cause Machine Check
Exceptions. Drivers need a new means of detecting whether they're
running on an EFI machine, as sadly the expression,
if (!efi_enabled)
hasn't been a sufficient condition for quite some time.
Users actually want to query 'efi_enabled' for different reasons -
what they really want access to is the list of available EFI
facilities.
For instance, the x86 reboot code needs to know whether it can invoke
the ResetSystem() function provided by the EFI runtime services, while
the ACPI OSL code wants to know whether the EFI config tables were
mapped successfully. There are also checks in some of the platform
driver code to simply see if they're running on an EFI machine (which
would make it a bad idea to do BIOS-y things).
This patch is a prereq for the samsung-laptop fix patch.
Cc: David Airlie <airlied@linux.ie>
Cc: Corentin Chary <corentincj@iksaif.net>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Olof Johansson <olof@lixom.net>
Cc: Peter Jones <pjones@redhat.com>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Steve Langasek <steve.langasek@canonical.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: <stable@vger.kernel.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
|
Pull EDAC fixlets from Borislav Petkov:
"Two minor correctness fixlets from Dan Carpenter and Joe Perches each."
* tag 'edac_for_3.8' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp:
EDAC: Fix kcalloc argument order
EDAC: Test correct variable in ->store function
|
|
First number, then size.
Signed-off-by: Joe Perches <joe@perches.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
|
|
We're testing for ->show but calling ->store().
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: stable@vger.kernel.org
Signed-off-by: Borislav Petkov <bp@suse.de>
|