Pull hw lockdown support from David Howells:
"Annotation of module parameters that configure hardware resources
including ioports, iomem addresses, irq lines and dma channels.
This allows a future patch to prohibit the use of such module
parameters to prevent that hardware from being abused to gain access
to the running kernel image as part of locking the kernel down under
UEFI secure boot conditions.
Annotations are made by changing:
module_param(n, t, p)
module_param_named(n, v, t, p)
module_param_array(n, t, m, p)
to:
module_param_hw(n, t, hwtype, p)
module_param_hw_named(n, v, t, hwtype, p)
module_param_hw_array(n, t, hwtype, m, p)
where the module parameter refers to a hardware setting
hwtype specifies the type of the resource being configured. This can
be one of:
ioport Module parameter configures an I/O port
iomem Module parameter configures an I/O mem address
ioport_or_iomem Module parameter could be either (runtime set)
irq Module parameter configures an I/O port
dma Module parameter configures a DMA channel
dma_addr Module parameter configures a DMA buffer address
other Module parameter configures some other value
Note that the hwtype is compile checked, but not currently stored (the
lockdown code probably won't require it). It is, however, there for
future use.
A bonus is that the hwtype can also be used for grepping.
The intention is for the kernel to ignore or reject attempts to set
annotated module parameters if lockdown is enabled. This applies to
options passed on the boot command line, passed to insmod/modprobe or
direct twiddling in /sys/module/ parameter files.
The module initialisation then needs to handle the parameter not being
set, by (1) giving an error, (2) probing for a value or (3) using a
reasonable default.
What I can't do is just reject a module out of hand because it may
take a hardware setting in the module parameters. Some important
modules, some ipmi stuff for instance, both probe for hardware and
allow hardware to be manually specified; if the driver is aborts with
any error, you don't get any ipmi hardware.
Further, trying to do this entirely in the module initialisation code
doesn't protect against sysfs twiddling.
[!] Note that in and of itself, this series of patches should have no
effect on the the size of the kernel or code execution - that is
left to a patch in the next series to effect. It does mark
annotated kernel parameters with a KERNEL_PARAM_FL_HWPARAM flag in
an already existing field"
* tag 'hwparam-20170420' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs: (38 commits)
Annotate hardware config module parameters in sound/pci/
Annotate hardware config module parameters in sound/oss/
Annotate hardware config module parameters in sound/isa/
Annotate hardware config module parameters in sound/drivers/
Annotate hardware config module parameters in fs/pstore/
Annotate hardware config module parameters in drivers/watchdog/
Annotate hardware config module parameters in drivers/video/
Annotate hardware config module parameters in drivers/tty/
Annotate hardware config module parameters in drivers/staging/vme/
Annotate hardware config module parameters in drivers/staging/speakup/
Annotate hardware config module parameters in drivers/staging/media/
Annotate hardware config module parameters in drivers/scsi/
Annotate hardware config module parameters in drivers/pcmcia/
Annotate hardware config module parameters in drivers/pci/hotplug/
Annotate hardware config module parameters in drivers/parport/
Annotate hardware config module parameters in drivers/net/wireless/
Annotate hardware config module parameters in drivers/net/wan/
Annotate hardware config module parameters in drivers/net/irda/
Annotate hardware config module parameters in drivers/net/hamradio/
Annotate hardware config module parameters in drivers/net/ethernet/
...
Pull input subsystem updates from Dmitry Torokhov: - a big update from Mauro converting input documentation to ReST format - Synaptics PS/2 is now aware of SMBus companion devices, which means that we can now use native RMI4 protocol to handle touchpads, instead of relying on legacy PS/2 mode. - we removed support from BMA180 accelerometer from input devices as it is now handled properly by IIO - update to TSC2007 to corretcly report pressure - other miscellaneous driver fixes. * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: (152 commits) Input: ar1021_i2c - use BIT to check for a bit Input: twl4030-pwrbutton - use input_set_capability() helper Input: twl4030-pwrbutton - use correct device for irq request Input: ar1021_i2c - enable touch mode during open Input: add uinput documentation dt-bindings: input: add bindings document for ar1021_i2c driver dt-bindings: input: rotary-encoder: fix typo Input: xen-kbdfront - add module parameter for setting resolution ARM: pxa/raumfeld: fix compile error in rotary controller resources Input: xpad - do not suggest writing to Dominic Input: xpad - don't use literal blocks inside footnotes Input: xpad - note that usb/devices is now at /sys/kernel/debug/ Input: docs - freshen up introduction Input: docs - split input docs into kernel- and user-facing Input: docs - note that MT-A protocol is obsolete Input: docs - update joystick documentation a bit Input: docs - remove disclaimer/GPL notice Input: fix "Game console" heading level in joystick documentation Input: rotary-encoder - remove references to platform data from docs Input: move documentation for Amiga CD32 ...
Pull MFD updates from Lee Jones: "New Drivers: - Freescale MXS Low Resolution ADC - Freescale i.MX23/i.MX28 LRADC touchscreen - Motorola CPCAP Power Button - TI LMU (Lighting Management Unit) - Atmel SMC (Static Memory Controller) New Device Support: - Add support for X-Powers AXP803 to axp20x - Add support for Dialog Semi DA9061 to da9062-core - Add support for Intel Cougar Mountain to lpc_ich - Add support for Intel Gemini Lake to lpc_ich New Functionality: - Add Device Tree support; wm831x-*, axp20x, ti-lmu, da9062, sun4i-gpadc - Add IRQ sense support; motorola-cpcap - Add ACPI support; cros_ec - Add Reset support; altera-a10sr - Add ADC support; axp20x - Add AC Power support; axp20x - Add Runtime PM support; atmel-ebi, exynos-lpass - Add Battery Power Supply support; axp20x - Add Clock support; exynos-lpass, hi655x-pmic Fix-ups: - Implicitly specify required headers; motorola-cpcap, intel_soc_pmic_bxtwc - Add .remove() method; stm32-timers, exynos-lpass - Remove unused code; intel_soc_pmic_core, intel-lpss-acpi, ipaq-micro, atmel-smc, menelaus - Rename variables for clarity; axp20x - Convert pr_warning() to pr_warn(); db8500-prcmu, sta2x11-mfd, twl4030-power - Improve formatting; arizona-core, axp20x - Use raw_spinlock_*() variants; asic3, t7l66xb, tc6393xb - Simplify/refactor code; arizona-core, atmel-ebi - Improve error checking; intel_soc_pmic_core Bug Fixes: - Ensure OMAP3630/3730 boards can successfully reboot; twl4030-power - Correct max-register value; stm32-timers - Extend timeout to account for clock stretching; cros_ec_spi - Use correct IRQ trigger type; motorola-cpcap - Fix bad use of IRQ sense register; motorola-cpcap - Logic error "||" should be "&&"; mxs-lradc-ts" * tag 'mfd-next-4.12' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (79 commits) input: touchscreen: mxs-lradc: || vs && typos dt-bindings: Add AXP803's regulator info mfd: axp20x: Support AXP803 variant dt-bindings: Add device tree binding for X-Powers AXP803 PMIC dt-bindings: Make AXP20X compatible strings one per line mfd: intel_soc_pmic_core: Fix unchecked return value mfd: menelaus: Remove obsolete local_irq_disable() and local_irq_enable() mfd: omap-usb-tll: Configure ULPIAUTOIDLE mfd: omap-usb-tll: Fix inverted bit use for USB TLL mode mfd: palmas: Fixed spelling mistake in error message mfd: lpc_ich: Add support for Intel Gemini Lake SoC mfd: hi655x: Add the clock cell to provide WiFi and Bluetooth mfd: intel_soc_pmic: Fix a mess with compilation units mfd: exynos-lpass: Add runtime PM support mfd: exynos-lpass: Add missing remove() function mfd: exynos-lpass: Add support for clocks mfd: exynos-lpass: Remove pad retention control iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs mfd: cpcap: Fix bad use of IRQ sense register mfd: cpcap: Use ack_invert interrupts ...
The MSB for the first byte of touch data transmission is always 1. Make it a little more obvious we're testing this bit by using BIT(7). Signed-off-by: Martin Kepplinger <martink@posteo.de> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The device could as well be in command mode, in which this driver cannot handle the device. When opening the device, let's make sure the device will be in the mode we expect it to be for this driver. Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
These tests are meaningless as is because "adapt" can't possibly be both
less than 1 and greater than 32.
Fixes: d81ca730e3e4 ("input: touchscreen: mxs-lradc: Add support for touchscreen")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/input/. Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk> Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> cc: linux-input@vger.kernel.org
ar1021_i2c also supports the ar1020 device I'm using. This is tested. They also share the same datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/40001393C.pdf So let users see that they have a compatible in front of them by adding AR1020 to the driver's description. Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
We should not be forcing edge triggered interrupt, but rather let platform decide the kind of trigger it needs to use. Also, the driver is not quite safe with regard to edge-triggered interrupts as it does not try to kick the controller after requesting/enabling IRQ. Reviewed-By: Christian Gmeiner <christian.gmeiner@gmail.com> Tested-by: Martin Kepplinger <martin.kepplinger@ginzinger.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The name field in structure i2c_device_id is 20 characters, and we expect
it to be NULL-terminated, however we are trying to stuff it with 21 bytes
and thus NULL-terminator is lost. This causes issues when one creates
device with name "MICROCHIP_AR1021_I2C" as i2c core cuts off the last "C",
and automatic module loading by alias does not work as result.
The -I2C suffix in the device name is superfluous, we know what bus we are
dealing with, so let's drop it. Also, no other driver uses capitals, and
the manufacturer name is normally not included, except in very rare cases
of incompatible name collisions.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116211
Fixes: dd4cae8bf166 ("Input: Add Microchip AR1021 i2c touchscreen")
Reviewed-By: Christian Gmeiner <christian.gmeiner@gmail.com>
Tested-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>