# # IrDA protocol configuration # menuconfig IRDA depends on NET && !S390 tristate "IrDA (infrared) subsystem support" select CRC_CCITT ---help--- Say Y here if you want to build support for the IrDA (TM) protocols. The Infrared Data Associations (tm) specifies standards for wireless infrared communication and is supported by most laptops and PDA's. To use Linux support for the IrDA (tm) protocols, you will also need some user-space utilities like irattach. For more information, see the file . You also want to read the IR-HOWTO, available at . If you want to exchange bits of data (vCal, vCard) with a PDA, you will need to install some OBEX application, such as OpenObex : To compile this support as a module, choose M here: the module will be called irda. comment "IrDA protocols" depends on IRDA source "net/irda/irlan/Kconfig" source "net/irda/irnet/Kconfig" source "net/irda/ircomm/Kconfig" config IRDA_ULTRA bool "Ultra (connectionless) protocol" depends on IRDA help Say Y here to support the connectionless Ultra IRDA protocol. Ultra allows to exchange data over IrDA with really simple devices (watch, beacon) without the overhead of the IrDA protocol (no handshaking, no management frames, simple fixed header). Ultra is available as a special socket : socket(AF_IRDA, SOCK_DGRAM, 1); comment "IrDA options" depends on IRDA config IRDA_CACHE_LAST_LSAP bool "Cache last LSAP" depends on IRDA help Say Y here if you want IrLMP to cache the last LSAP used. This makes sense since most frames will be sent/received on the same connection. Enabling this option will save a hash-lookup per frame. If unsure, say Y. config IRDA_FAST_RR bool "Fast RRs (low latency)" depends on IRDA ---help--- Say Y here is you want IrLAP to send fast RR (Receive Ready) frames when acting as a primary station. Disabling this option will make latency over IrDA very bad. Enabling this option will make the IrDA stack send more packet than strictly necessary, thus reduce your battery life (but not that much). Fast RR will make IrLAP send out a RR frame immediately when receiving a frame if its own transmit queue is currently empty. This will give a lot of speed improvement when receiving much data since the secondary station will not have to wait the max. turn around time (usually 500ms) before it is allowed to transmit the next time. If the transmit queue of the secondary is also empty, the primary will start backing-off before sending another RR frame, waiting longer each time until the back-off reaches the max. turn around time. This back-off increase in controlled via /proc/sys/net/irda/fast_poll_increase If unsure, say Y. config IRDA_DEBUG bool "Debug information" depends on IRDA help Say Y here if you want the IrDA subsystem to write debug information to your syslog. You can change the debug level in /proc/sys/net/irda/debug . When this option is enabled, the IrDA also perform many extra internal verifications which will usually prevent the kernel to crash in case of bugs. If unsure, say Y (since it makes it easier to find the bugs). source "drivers/net/irda/Kconfig" b307339f269d3bf7db877d536f'>arch/x86/westmereep-sp
diff options
context:
space:
mode:
authorDavid S. Miller <davem@davemloft.net>2017-01-30 14:28:22 -0800
committerDavid S. Miller <davem@davemloft.net>2017-01-30 14:28:22 -0800
commit54791b276b4000b307339f269d3bf7db877d536f (patch)
tree1c2616bd373ce5ea28aac2a53e32f5b5834901ce /tools/perf/pmu-events/arch/x86/westmereep-sp
parent5d0e7705774dd412a465896d08d59a81a345c1e4 (diff)
parent047487241ff59374fded8c477f21453681f5995c (diff)
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>
Diffstat (limited to 'tools/perf/pmu-events/arch/x86/westmereep-sp')