Loading CREDITS +8 −0 Original line number Diff line number Diff line Loading @@ -1507,6 +1507,14 @@ S: 312/107 Canberra Avenue S: Griffith, ACT 2603 S: Australia N: Andreas Herrmann E: herrmann.der.user@gmail.com E: herrmann.der.user@googlemail.com D: Key developer of x86/AMD64 D: Author of AMD family 15h processor power monitoring driver D: Maintainer of AMD Athlon 64 and Opteron processor frequency driver S: Germany N: Sebastian Hetze E: she@lunetix.de D: German Linux Documentation, Loading Documentation/ABI/testing/sysfs-class-net-cdc_ncm +19 −0 Original line number Diff line number Diff line Loading @@ -19,6 +19,25 @@ Description: Set to 0 to pad all frames. Set greater than tx_max to disable all padding. What: /sys/class/net/<iface>/cdc_ncm/ndp_to_end Date: Dec 2015 KernelVersion: 4.5 Contact: Bjørn Mork <bjorn@mork.no> Description: Boolean attribute showing the status of the "NDP to end" quirk. Defaults to 'N', except for devices already known to need it enabled. The "NDP to end" quirk makes the driver place the NDP (the packet index table) after the payload. The NCM specification does not mandate this, but some devices are known to be more restrictive. Write 'Y' to this attribute for temporary testing of a suspect device failing to work with the default driver settings. A device entry should be added to the driver if this quirk is found to be required. What: /sys/class/net/<iface>/cdc_ncm/rx_max Date: May 2014 KernelVersion: 3.16 Loading Documentation/ABI/testing/sysfs-class-net-mesh +2 −2 Original line number Diff line number Diff line Loading @@ -8,7 +8,7 @@ Description: What: /sys/class/net/<mesh_iface>/mesh/<vlan_subdir>/ap_isolation Date: May 2011 Contact: Antonio Quartulli <antonio@meshcoding.com> Contact: Antonio Quartulli <a@unstable.cc> Description: Indicates whether the data traffic going from a wireless client to another wireless client will be Loading Loading @@ -70,7 +70,7 @@ Description: What: /sys/class/net/<mesh_iface>/mesh/isolation_mark Date: Nov 2013 Contact: Antonio Quartulli <antonio@meshcoding.com> Contact: Antonio Quartulli <a@unstable.cc> Description: Defines the isolation mark (and its bitmask) which is used to classify clients as "isolated" by the Loading Documentation/ABI/testing/sysfs-class-net-qmi 0 → 100644 +23 −0 Original line number Diff line number Diff line What: /sys/class/net/<iface>/qmi/raw_ip Date: Dec 2015 KernelVersion: 4.4 Contact: Bjørn Mork <bjorn@mork.no> Description: Boolean. Default: 'N' Set this to 'Y' to change the network device link framing from '802.3' to 'raw-ip'. The netdev will change to reflect the link framing mode. The netdev is an ordinary ethernet device in '802.3' mode, and the driver expects to exchange frames with an ethernet header over the USB link. The netdev is a headerless p-t-p device in 'raw-ip' mode, and the driver expects to echange IPv4 or IPv6 packets without any L2 header over the USB link. Userspace is in full control of firmware configuration through the delegation of the QMI protocol. Userspace is responsible for coordination of driver and firmware link framing mode, changing this setting to 'Y' if the firmware is configured for 'raw-ip' mode. Documentation/DocBook/device-drivers.tmpl +16 −68 Original line number Diff line number Diff line Loading @@ -238,78 +238,26 @@ X!Isound/sound_firmware.c !Iinclude/media/videobuf2-memops.h </sect1> <sect1><title>Digital TV (DVB) devices</title> !Idrivers/media/dvb-core/dvb_ca_en50221.h !Idrivers/media/dvb-core/dvb_frontend.h <sect1><title>Digital TV Common functions</title> !Idrivers/media/dvb-core/dvb_math.h !Idrivers/media/dvb-core/dvb_ringbuffer.h !Idrivers/media/dvb-core/dvbdev.h <sect1><title>Digital TV Demux API</title> <para>The kernel demux API defines a driver-internal interface for registering low-level, hardware specific driver to a hardware independent demux layer. It is only of interest for Digital TV device driver writers. The header file for this API is named <constant>demux.h</constant> and located in <constant>drivers/media/dvb-core</constant>.</para> <para>The demux API should be implemented for each demux in the system. It is used to select the TS source of a demux and to manage the demux resources. When the demux client allocates a resource via the demux API, it receives a pointer to the API of that resource.</para> <para>Each demux receives its TS input from a DVB front-end or from memory, as set via this demux API. In a system with more than one front-end, the API can be used to select one of the DVB front-ends as a TS source for a demux, unless this is fixed in the HW platform. The demux API only controls front-ends regarding to their connections with demuxes; the APIs used to set the other front-end parameters, such as tuning, are not defined in this document.</para> <para>The functions that implement the abstract interface demux should be defined static or module private and registered to the Demux core for external access. It is not necessary to implement every function in the struct <constant>dmx_demux</constant>. For example, a demux interface might support Section filtering, but not PES filtering. The API client is expected to check the value of any function pointer before calling the function: the value of NULL means that the “function is not available”.</para> <para>Whenever the functions of the demux API modify shared data, the possibilities of lost update and race condition problems should be addressed, e.g. by protecting parts of code with mutexes.</para> <para>Note that functions called from a bottom half context must not sleep. Even a simple memory allocation without using GFP_ATOMIC can result in a kernel thread being put to sleep if swapping is needed. For example, the Linux kernel calls the functions of a network device interface from a bottom half context. Thus, if a demux API function is called from network device code, the function must not sleep. </para> </sect1> <section id="demux_callback_api"> <title>Demux Callback API</title> <para>This kernel-space API comprises the callback functions that deliver filtered data to the demux client. Unlike the other DVB kABIs, these functions are provided by the client and called from the demux code.</para> <para>The function pointers of this abstract interface are not packed into a structure as in the other demux APIs, because the callback functions are registered and used independent of each other. As an example, it is possible for the API client to provide several callback functions for receiving TS packets and no callbacks for PES packets or sections.</para> <para>The functions that implement the callback API need not be re-entrant: when a demux driver calls one of these functions, the driver is not allowed to call the function again before the original call returns. If a callback is triggered by a hardware interrupt, it is recommended to use the Linux “bottom half” mechanism or start a tasklet instead of making the callback function call directly from a hardware interrupt.</para> <para>This mechanism is implemented by <link linkend='API-dmx-ts-cb'>dmx_ts_cb()</link> and <link linkend='API-dmx-section-cb'>dmx_section_cb()</link>.</para> </section> <sect1><title>Digital TV Frontend kABI</title> !Pdrivers/media/dvb-core/dvb_frontend.h Digital TV Frontend !Idrivers/media/dvb-core/dvb_frontend.h </sect1> <sect1><title>Digital TV Demux kABI</title> !Pdrivers/media/dvb-core/demux.h Digital TV Demux <sect1><title>Demux Callback API</title> !Pdrivers/media/dvb-core/demux.h Demux Callback </sect1> !Idrivers/media/dvb-core/demux.h </sect1> <sect1><title>Digital TV Conditional Access kABI</title> !Idrivers/media/dvb-core/dvb_ca_en50221.h </sect1> </sect1> <sect1><title>Remote Controller devices</title> !Iinclude/media/rc-core.h !Iinclude/media/lirc_dev.h Loading Loading
CREDITS +8 −0 Original line number Diff line number Diff line Loading @@ -1507,6 +1507,14 @@ S: 312/107 Canberra Avenue S: Griffith, ACT 2603 S: Australia N: Andreas Herrmann E: herrmann.der.user@gmail.com E: herrmann.der.user@googlemail.com D: Key developer of x86/AMD64 D: Author of AMD family 15h processor power monitoring driver D: Maintainer of AMD Athlon 64 and Opteron processor frequency driver S: Germany N: Sebastian Hetze E: she@lunetix.de D: German Linux Documentation, Loading
Documentation/ABI/testing/sysfs-class-net-cdc_ncm +19 −0 Original line number Diff line number Diff line Loading @@ -19,6 +19,25 @@ Description: Set to 0 to pad all frames. Set greater than tx_max to disable all padding. What: /sys/class/net/<iface>/cdc_ncm/ndp_to_end Date: Dec 2015 KernelVersion: 4.5 Contact: Bjørn Mork <bjorn@mork.no> Description: Boolean attribute showing the status of the "NDP to end" quirk. Defaults to 'N', except for devices already known to need it enabled. The "NDP to end" quirk makes the driver place the NDP (the packet index table) after the payload. The NCM specification does not mandate this, but some devices are known to be more restrictive. Write 'Y' to this attribute for temporary testing of a suspect device failing to work with the default driver settings. A device entry should be added to the driver if this quirk is found to be required. What: /sys/class/net/<iface>/cdc_ncm/rx_max Date: May 2014 KernelVersion: 3.16 Loading
Documentation/ABI/testing/sysfs-class-net-mesh +2 −2 Original line number Diff line number Diff line Loading @@ -8,7 +8,7 @@ Description: What: /sys/class/net/<mesh_iface>/mesh/<vlan_subdir>/ap_isolation Date: May 2011 Contact: Antonio Quartulli <antonio@meshcoding.com> Contact: Antonio Quartulli <a@unstable.cc> Description: Indicates whether the data traffic going from a wireless client to another wireless client will be Loading Loading @@ -70,7 +70,7 @@ Description: What: /sys/class/net/<mesh_iface>/mesh/isolation_mark Date: Nov 2013 Contact: Antonio Quartulli <antonio@meshcoding.com> Contact: Antonio Quartulli <a@unstable.cc> Description: Defines the isolation mark (and its bitmask) which is used to classify clients as "isolated" by the Loading
Documentation/ABI/testing/sysfs-class-net-qmi 0 → 100644 +23 −0 Original line number Diff line number Diff line What: /sys/class/net/<iface>/qmi/raw_ip Date: Dec 2015 KernelVersion: 4.4 Contact: Bjørn Mork <bjorn@mork.no> Description: Boolean. Default: 'N' Set this to 'Y' to change the network device link framing from '802.3' to 'raw-ip'. The netdev will change to reflect the link framing mode. The netdev is an ordinary ethernet device in '802.3' mode, and the driver expects to exchange frames with an ethernet header over the USB link. The netdev is a headerless p-t-p device in 'raw-ip' mode, and the driver expects to echange IPv4 or IPv6 packets without any L2 header over the USB link. Userspace is in full control of firmware configuration through the delegation of the QMI protocol. Userspace is responsible for coordination of driver and firmware link framing mode, changing this setting to 'Y' if the firmware is configured for 'raw-ip' mode.
Documentation/DocBook/device-drivers.tmpl +16 −68 Original line number Diff line number Diff line Loading @@ -238,78 +238,26 @@ X!Isound/sound_firmware.c !Iinclude/media/videobuf2-memops.h </sect1> <sect1><title>Digital TV (DVB) devices</title> !Idrivers/media/dvb-core/dvb_ca_en50221.h !Idrivers/media/dvb-core/dvb_frontend.h <sect1><title>Digital TV Common functions</title> !Idrivers/media/dvb-core/dvb_math.h !Idrivers/media/dvb-core/dvb_ringbuffer.h !Idrivers/media/dvb-core/dvbdev.h <sect1><title>Digital TV Demux API</title> <para>The kernel demux API defines a driver-internal interface for registering low-level, hardware specific driver to a hardware independent demux layer. It is only of interest for Digital TV device driver writers. The header file for this API is named <constant>demux.h</constant> and located in <constant>drivers/media/dvb-core</constant>.</para> <para>The demux API should be implemented for each demux in the system. It is used to select the TS source of a demux and to manage the demux resources. When the demux client allocates a resource via the demux API, it receives a pointer to the API of that resource.</para> <para>Each demux receives its TS input from a DVB front-end or from memory, as set via this demux API. In a system with more than one front-end, the API can be used to select one of the DVB front-ends as a TS source for a demux, unless this is fixed in the HW platform. The demux API only controls front-ends regarding to their connections with demuxes; the APIs used to set the other front-end parameters, such as tuning, are not defined in this document.</para> <para>The functions that implement the abstract interface demux should be defined static or module private and registered to the Demux core for external access. It is not necessary to implement every function in the struct <constant>dmx_demux</constant>. For example, a demux interface might support Section filtering, but not PES filtering. The API client is expected to check the value of any function pointer before calling the function: the value of NULL means that the “function is not available”.</para> <para>Whenever the functions of the demux API modify shared data, the possibilities of lost update and race condition problems should be addressed, e.g. by protecting parts of code with mutexes.</para> <para>Note that functions called from a bottom half context must not sleep. Even a simple memory allocation without using GFP_ATOMIC can result in a kernel thread being put to sleep if swapping is needed. For example, the Linux kernel calls the functions of a network device interface from a bottom half context. Thus, if a demux API function is called from network device code, the function must not sleep. </para> </sect1> <section id="demux_callback_api"> <title>Demux Callback API</title> <para>This kernel-space API comprises the callback functions that deliver filtered data to the demux client. Unlike the other DVB kABIs, these functions are provided by the client and called from the demux code.</para> <para>The function pointers of this abstract interface are not packed into a structure as in the other demux APIs, because the callback functions are registered and used independent of each other. As an example, it is possible for the API client to provide several callback functions for receiving TS packets and no callbacks for PES packets or sections.</para> <para>The functions that implement the callback API need not be re-entrant: when a demux driver calls one of these functions, the driver is not allowed to call the function again before the original call returns. If a callback is triggered by a hardware interrupt, it is recommended to use the Linux “bottom half” mechanism or start a tasklet instead of making the callback function call directly from a hardware interrupt.</para> <para>This mechanism is implemented by <link linkend='API-dmx-ts-cb'>dmx_ts_cb()</link> and <link linkend='API-dmx-section-cb'>dmx_section_cb()</link>.</para> </section> <sect1><title>Digital TV Frontend kABI</title> !Pdrivers/media/dvb-core/dvb_frontend.h Digital TV Frontend !Idrivers/media/dvb-core/dvb_frontend.h </sect1> <sect1><title>Digital TV Demux kABI</title> !Pdrivers/media/dvb-core/demux.h Digital TV Demux <sect1><title>Demux Callback API</title> !Pdrivers/media/dvb-core/demux.h Demux Callback </sect1> !Idrivers/media/dvb-core/demux.h </sect1> <sect1><title>Digital TV Conditional Access kABI</title> !Idrivers/media/dvb-core/dvb_ca_en50221.h </sect1> </sect1> <sect1><title>Remote Controller devices</title> !Iinclude/media/rc-core.h !Iinclude/media/lirc_dev.h Loading
