summaryrefslogtreecommitdiff
path: root/sig.h
blob: 10627b81ed3499d232f84ea89da44fb4ee67ed3b (plain)
1
2
3
4
5
6
7
#ifndef SIG_H
#define SIG_H

extern void register_signal(int signal, void (*handler)(int));
extern void register_signal_f(int signal, void (*handler)(int), int flags);

#endif /* SIG_H */
emode:
authorMika Westerberg <mika.westerberg@linux.intel.com>2016-07-04 17:18:15 +0300
committerMark Brown <broonie@kernel.org>2016-07-04 16:28:52 +0200
commitcf9f4327a306be58df6c0b3817d7ef06a2a3da03 (patch)
tree5eef0fca251233c13da8fc04db14bad541a87dff
parent1a695a905c18548062509178b98bc91e67510864 (diff)
spi: spidev: Add ACPI probing support
Some IoT and maker software stacks are using spidev to perform raw access to the SPI bus instead of relying existing drivers provided by the kernel. They then implement their own "drivers" in userspace on top of the spidev raw interface. This is far from being an ideal solution but we do not want to prevent using mainline Linux in these devices. Now, it turns out that Windows has similar SPI devices than spidev which allow raw access on the SPI bus to userspace programs as described in the link below: https://msdn.microsoft.com/windows/hardware/drivers/spb/spi-tests-in-mitt These SPI test devices are also meant to be used during development and testing. In order to allow usage of spidev for development and testing in Linux, add those same ACPI IDs to the spidev driver (which is Linux counterpart of the Windows SPI test devices), but complain loudly so that users know it is not good idea to use it in production systems. Instead they should be using proper drivers for peripherals connected to the SPI bus. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
Diffstat