#
# 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 <file:Documentation/networking/irda.txt>.  You also want to
	  read the IR-HOWTO, available at
	  <http://www.tldp.org/docs.html#howto>.

	  If you want to exchange bits of data (vCal, vCard) with a PDA, you
	  will need to install some OBEX application, such as OpenObex :
	  <http://sourceforge.net/projects/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"

 name='context' onchange='this.form.submit();'><option value='1'>1</option><option value='2'>2</option><option value='3' selected='selected'>3</option><option value='4'>4</option><option value='5'>5</option><option value='6'>6</option><option value='7'>7</option><option value='8'>8</option><option value='9'>9</option><option value='10'>10</option><option value='15'>15</option><option value='20'>20</option><option value='25'>25</option><option value='30'>30</option><option value='35'>35</option><option value='40'>40</option></select></td></tr><tr><td class='label'>space:</td><td class='ctrl'><select name='ignorews' onchange='this.form.submit();'><option value='0' selected='selected'>include</option><option value='1'>ignore</option></select></td></tr><tr><td class='label'>mode:</td><td class='ctrl'><select name='dt' onchange='this.form.submit();'><option value='0' selected='selected'>unified</option><option value='1'>ssdiff</option><option value='2'>stat only</option></select></td></tr><tr><td/><td class='ctrl'><noscript><input type='submit' value='reload'/></noscript></td></tr></table></form></div><table summary='commit info' class='commit-info'>
<tr><th>author</th><td>Marc Zyngier &lt;marc.zyngier@arm.com&gt;</td><td class='right'>2017-01-17 16:00:48 +0000</td></tr>
<tr><th>committer</th><td>Thomas Gleixner &lt;tglx@linutronix.de&gt;</td><td class='right'>2017-01-30 15:18:56 +0100</td></tr>
<tr><th>commit</th><td colspan='2' class='oid'><a href='/cgit.cgi/linux/net-next.git/commit/include/rdma/opa_smi.h?id=08d85f3ea99f1eeafc4e8507936190e86a16ee8c'>08d85f3ea99f1eeafc4e8507936190e86a16ee8c</a> (<a href='/cgit.cgi/linux/net-next.git/patch/include/rdma/opa_smi.h?id=08d85f3ea99f1eeafc4e8507936190e86a16ee8c'>patch</a>)</td></tr>
<tr><th>tree</th><td colspan='2' class='oid'><a href='/cgit.cgi/linux/net-next.git/tree/?id=08d85f3ea99f1eeafc4e8507936190e86a16ee8c'>410bb1acd0cd7dcfaad37ae7b63ff243b7fa4bee</a> /<a href='/cgit.cgi/linux/net-next.git/tree/include/rdma/opa_smi.h?id=08d85f3ea99f1eeafc4e8507936190e86a16ee8c'>include/rdma/opa_smi.h</a></td></tr>
<tr><th>parent</th><td colspan='2' class='oid'><a href='/cgit.cgi/linux/net-next.git/commit/include/rdma/opa_smi.h?id=566cf877a1fcb6d6dc0126b076aad062054c2637'>566cf877a1fcb6d6dc0126b076aad062054c2637</a> (<a href='/cgit.cgi/linux/net-next.git/diff/include/rdma/opa_smi.h?id=08d85f3ea99f1eeafc4e8507936190e86a16ee8c&amp;id2=566cf877a1fcb6d6dc0126b076aad062054c2637'>diff</a>)</td></tr></table>
<div class='commit-subject'>irqdomain: Avoid activating interrupts more than once</div><div class='commit-msg'>Since commit f3b0946d629c ("genirq/msi: Make sure PCI MSIs are
activated early"), we can end-up activating a PCI/MSI twice (once
at allocation time, and once at startup time).

This is normally of no consequences, except that there is some
HW out there that may misbehave if activate is used more than once
(the GICv3 ITS, for example, uses the activate callback
to issue the MAPVI command, and the architecture spec says that
"If there is an existing mapping for the EventID-DeviceID
combination, behavior is UNPREDICTABLE").

While this could be worked around in each individual driver, it may
make more sense to tackle the issue at the core level. In order to
avoid getting in that situation, let's have a per-interrupt flag
to remember if we have already activated that interrupt or not.

Fixes: f3b0946d629c ("genirq/msi: Make sure PCI MSIs are activated early")
Reported-and-tested-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1484668848-24361-1-git-send-email-marc.zyngier@arm.com
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;

</div><div class='diffstat-header'><a href='/cgit.cgi/linux/net-next.git/diff/?id=08d85f3ea99f1eeafc4e8507936190e86a16ee8c'>Diffstat</a> (limited to 'include/rdma/opa_smi.h')</div><table summary='diffstat' class='diffstat'>