#
# RMI4 configuration
#
config RMI4_CORE
tristate "Synaptics RMI4 bus support"
help
Say Y here if you want to support the Synaptics RMI4 bus. This is
required for all RMI4 device support.
If unsure, say Y.
config RMI4_I2C
tristate "RMI4 I2C Support"
depends on RMI4_CORE && I2C
help
Say Y here if you want to support RMI4 devices connected to an I2C
bus.
If unsure, say Y.
config RMI4_SPI
tristate "RMI4 SPI Support"
depends on RMI4_CORE && SPI
help
Say Y here if you want to support RMI4 devices connected to a SPI
bus.
If unsure, say N.
config RMI4_SMB
tristate "RMI4 SMB Support"
depends on RMI4_CORE && I2C
help
Say Y here if you want to support RMI4 devices connected to an SMB
bus.
If unsure, say N.
To compile this driver as a module, choose M here: the module will be
called rmi_smbus.
config RMI4_F03
bool "RMI4 Function 03 (PS2 Guest)"
depends on RMI4_CORE
depends on SERIO=y || RMI4_CORE=SERIO
help
Say Y here if you want to add support for RMI4 function 03.
Function 03 provides PS2 guest support for RMI4 devices. This
includes support for TrackPoints on TouchPads.
config RMI4_2D_SENSOR
bool
depends on RMI4_CORE
config RMI4_F11
bool "RMI4 Function 11 (2D pointing)"
select RMI4_2D_SENSOR
depends on RMI4_CORE
help
Say Y here if you want to add support for RMI4 function 11.
Function 11 provides 2D multifinger pointing for touchscreens and
touchpads. For sensors that support relative pointing, F11 also
provides mouse input.
config RMI4_F12
bool "RMI4 Function 12 (2D pointing)"
select RMI4_2D_SENSOR
depends on RMI4_CORE
help
Say Y here if you want to add support for RMI4 function 12.
Function 12 provides 2D multifinger pointing for touchscreens and
touchpads. For sensors that support relative pointing, F12 also
provides mouse input.
config RMI4_F30
bool "RMI4 Function 30 (GPIO LED)"
depends on RMI4_CORE
help
Say Y here if you want to add support for RMI4 function 30.
Function 30 provides GPIO and LED support for RMI4 devices. This
includes support for buttons on TouchPads and ClickPads.
config RMI4_F34
bool "RMI4 Function 34 (Device reflash)"
depends on RMI4_CORE
select FW_LOADER
help
Say Y here if you want to add support for RMI4 function 34.
Function 34 provides support for upgrading the firmware on the RMI4
device via the firmware loader interface. This is triggered using a
sysfs attribute.
config RMI4_F54
bool "RMI4 Function 54 (Analog diagnostics)"
depends on RMI4_CORE
depends on VIDEO_V4L2=y || (RMI4_CORE=m && VIDEO_V4L2=m)
select VIDEOBUF2_VMALLOC
select RMI4_F55
help
Say Y here if you want to add support for RMI4 function 54
Function 54 provides access to various diagnostic features in certain
RMI4 touch sensors.
config RMI4_F55
bool "RMI4 Function 55 (Sensor tuning)"
depends on RMI4_CORE
help
Say Y here if you want to add support for RMI4 function 55
Function 55 provides access to the RMI4 touch sensor tuning
mechanism.
&id=54791b276b4000b307339f269d3bf7db877d536f'>net/sched/cls_route.c
Merge branch 'sparc64-non-resumable-user-error-recovery'
Liam R. Howlett says:
====================
sparc64: Recover from userspace non-resumable PIO & MEM errors
A non-resumable error from userspace is able to cause a kernel panic or trap
loop due to the setup and handling of the queued traps once in the kernel.
This patch series addresses both of these issues.
The queues are fixed by simply zeroing the memory before use.
PIO errors from userspace will result in a SIGBUS being sent to the user
process.
The MEM errors form userspace will result in a SIGKILL and also cause the
offending pages to be claimed so they are no longer used in future tasks.
SIGKILL is used to ensure that the process does not try to coredump and result
in an attempt to read the memory again from within kernel space. Although
there is a HV call to scrub the memory (mem_scrub), there is no easy way to
guarantee that the real memory address(es) are not used by other tasks.
Clearing the error with mem_scrub would zero the memory and cause the other
processes to proceed with bad data.
The handling of other non-resumable errors remain unchanged and will cause a
panic.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>