| /Linux-v6.1/drivers/edac/ |
| D | Kconfig | 4 # Licensed and distributed under the GPL
13 tristate "EDAC (Error Detection And Correction) reporting"
40 levels are 0-4 (from low to high) and by default it is set to 2.
69 It should be noticed that keeping both GHES and a hardware-driven
82 Support for error detection and correction of DRAM ECC errors on
88 AMD CPUs up to and excluding family 0x17 provide for Memory
90 module allows the operator/user to inject Uncorrectable and
100 In addition, there are two control files, inject_read and inject_write,
101 which trigger the DRAM ECC Read and Write respectively.
107 Support for error detection and correction for Amazon's Annapurna
[all …]
|
| /Linux-v6.1/drivers/pinctrl/intel/ |
| D | Kconfig | 12 platforms. Supports 3 banks with 102, 28 and 44 gpios.
19 tristate "Intel Cherryview/Braswell pinctrl and GPIO driver"
24 allows configuring of SoC pins and using them as GPIOs.
27 tristate "Intel Lynxpoint pinctrl and GPIO driver"
36 provides an interface that allows configuring of PCH pins and
47 interface that allows configuring of SoC pins and using them as
59 tristate "Intel Alder Lake pinctrl and GPIO driver"
64 of Intel Alder Lake PCH pins and using them as GPIOs.
67 tristate "Intel Broxton pinctrl and GPIO driver"
72 configuring of SoC pins and using them as GPIOs.
[all …]
|
| /Linux-v6.1/Documentation/timers/ |
| D | hrtimers.rst | 9 back and forth trying to integrate high-resolution and high-precision
10 features into the existing timer framework, and after testing various
14 to solve this'), and spent a considerable effort trying to integrate
18 - the forced handling of low-resolution and high-resolution timers in
19 the same way leads to a lot of compromises, macro magic and #ifdef
20 mess. The timers.c code is very "tightly coded" around jiffies and
21 32-bitness assumptions, and has been honed and micro-optimized for a
23 for many years - and thus even small extensions to it easily break
25 code is very good and tight code, there's zero problems with it in its
45 error conditions in various I/O paths, such as networking and block
[all …]
|
| /Linux-v6.1/Documentation/userspace-api/media/v4l/ |
| D | hist-v4l2.rst | 12 and began to work on documentation, example drivers and applications.
15 another four years and two stable kernel releases until the new API was
28 meaningless ``O_TRUNC`` :c:func:`open()` flag, and the
29 aliases ``O_NONCAP`` and ``O_NOIO`` were defined. Applications can set
32 identifiers are now ordinals instead of flags, and the
33 ``video_std_construct()`` helper function takes id and
40 struct ``video_standard`` and the color subcarrier fields were
53 and ``V4L2_PIX_FMT_RGB32`` changed to ``V4L2_PIX_FMT_BGR32``. Audio
55 :ref:`VIDIOC_G_CTRL <VIDIOC_G_CTRL>` and
59 module. The ``YUV422`` and ``YUV411`` planar image formats were added.
[all …]
|
| D | v4l2.rst | 39 Revision and Copyright
50 - Documented libv4l, designed and added v4l2grab example, Remote Controller chapter.
54 - Original author of the V4L2 API and documentation.
63 - Original author of the V4L2 API and documentation.
76 - Designed and documented the multi-planar API.
84 - Introduce HSV formats and other minor changes.
88 - Designed and documented the VIDIOC_ENUM_FRAMESIZES and VIDIOC_ENUM_FRAMEINTERVALS ioctls.
96 …ned and documented the VIDIOC_LOG_STATUS ioctl, the extended control ioctls, major parts of the sl…
101 part can be used and distributed without restrictions.
115 ctrl_class and which. Which is used to select the current value of the
[all …]
|
| /Linux-v6.1/LICENSES/dual/ |
| D | CC-BY-4.0 | 19 Creative Commons Corporation ("Creative Commons") is not a law firm and
22 other relationship. Creative Commons makes its licenses and related
25 terms and conditions, or any related information. Creative Commons
31 Creative Commons public licenses provide a standard set of terms and
32 conditions that creators and other rights holders may use to share
33 original works of authorship and other material subject to copyright
34 and certain other rights specified in the public license below. The
36 exhaustive, and do not form part of our licenses.
41 copyright and certain other rights. Our licenses are
42 irrevocable. Licensors should read and understand the terms
[all …]
|
| D | Apache-2.0 | 20 TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
24 "License" shall mean the terms and conditions for use, reproduction, and
30 "Legal Entity" shall mean the union of the acting entity and all other
43 and configuration files.
47 object code, generated documentation, and conversions to other media types.
55 that is based on (or derived from) the Work and for which the editorial
59 merely link (or bind by name) to the interfaces of, the Work and Derivative
63 version of the Work and any modifications or additions to that Work or
70 mailing lists, source code control systems, and issue tracking systems that
72 and improving the Work, but excluding communication that is conspicuously
[all …]
|
| /Linux-v6.1/Documentation/networking/ |
| D | af_xdp.rst | 13 This document assumes that the reader is familiar with BPF and XDP. If
24 syscall. Associated with each XSK are two rings: the RX ring and the
25 TX ring. A socket can receive packets on the RX ring and it can send
26 packets on the TX ring. These rings are registered and sized with the
27 setsockopts XDP_RX_RING and XDP_TX_RING, respectively. It is mandatory
30 UMEM. RX and TX can share the same UMEM so that a packet does not have
31 to be copied between RX and TX. Moreover, if a packet needs to be kept
33 to that packet can be changed to point to another and reused right
42 UMEM also has two rings: the FILL ring and the COMPLETION ring. The
47 kernel has transmitted completely and can now be used again by user
[all …]
|
| /Linux-v6.1/Documentation/core-api/ |
| D | workqueue.rst | 14 is needed and the workqueue (wq) API is the most commonly used
20 queue is called workqueue and the thread is called worker.
32 worker thread per CPU and a single threaded (ST) wq had one worker
35 wq users over the years and with the number of CPU cores continuously
40 provided was unsatisfactory. The limitation was common to both ST and
47 The tension between the provided level of concurrency and resource
49 choosing to use ST wq for polling PIOs and accepting an unnecessary
64 * Automatically regulate worker pool and level of concurrency so that
77 item pointing to that function and queue that work item on a
86 subsystems and drivers queue work items on and the backend mechanism
[all …]
|
| /Linux-v6.1/Documentation/scsi/ |
| D | ChangeLog.lpfc | 12 for fabric and nport logins out of lpfc_cmpl_els_flogi.
18 PRLI...) are errored back and scan() terminates.
28 find command in both TX and TX completion queues. Return ERROR
62 - kill struct lpfc_scsi_dma_buf and embedded the two members
67 ever used by the driver, just reported to userspace (and that in
72 32bit and 64bit defines on some archs.
82 * Revise TRANSPORT_PATCHES_V2 so that lpfc_target is removed and
84 * Changed RW attributes of scan_down, max_luns and fcp_bind_method
88 list and marked for ADISC.
102 * Use DMA_64BIT_MASK and DMA_32BIT_MASK defines instead of
[all …]
|
| /Linux-v6.1/Documentation/fb/ |
| D | api.rst | 12 with frame buffer devices. In-kernel APIs between device drivers and the frame
16 behaviours differ in subtle (and not so subtle) ways. This document describes
24 Device and driver capabilities are reported in the fixed screen information
34 expect from the device and driver.
43 2. Types and visuals
50 Formats are described by frame buffer types and visuals. Some visuals require
52 bits_per_pixel, grayscale, red, green, blue and transp fields.
54 Visuals describe how color information is encoded and assembled to create
56 types and visuals are supported.
64 Padding at end of lines may be present and is then reported through the fixed
[all …]
|
| /Linux-v6.1/drivers/hwmon/ |
| D | Kconfig | 14 sensors and various additional features such as the ability to
16 should say Y here and also to the specific driver(s) for your
36 a problem with I2C support and want to see more of what is going
46 and second revision of the Abit uGuru chip. The voltage and frequency
49 Abit motherboards from before end 2005). For more info and a list
62 and their settings is supported. The third revision of the Abit
64 2005). For more info and a list of which motherboards have which
71 tristate "Analog Devices AD7314 and compatibles"
75 AD7314, ADT7301 and ADT7302 temperature sensors.
91 tristate "Analog Devices AD7416, AD7417 and AD7418"
[all …]
|
| /Linux-v6.1/LICENSES/deprecated/ |
| D | GPL-1.0 | 18 Everyone is permitted to copy and distribute verbatim copies
25 License is intended to guarantee your freedom to share and change free
28 software and to any other program whose authors commit to using it.
36 programs; and that you know you can do these things.
46 source code. And you must tell them their rights.
48 We protect your rights with two steps: (1) copyright the software, and
50 distribute and/or modify the software.
52 Also, for each author's protection and ours, we want to make certain
54 software. If the software is modified by someone else and passed on, we
59 The precise terms and conditions for copying, distribution and
[all …]
|
| /Linux-v6.1/Documentation/admin-guide/mm/damon/ |
| D | usage.rst | 14 virtual and physical address spaces monitoring. For more detail, please
20 features by reading from and writing to special sysfs files. Therefore,
21 you can write and use your personalized DAMON sysfs wrapper programs that
24 supports both virtual and physical address spaces monitoring. Note that this
34 users can utilize every feature of DAMON most flexibly and efficiently by
45 creates multiple directories and files under its sysfs directory,
46 ``<sysfs>/kernel/mm/damon/``. You can control DAMON by writing to and reading
64 directory is having ``/`` suffix, and files in each directory are separated by
98 The root of the DAMON sysfs interface is ``<sysfs>/kernel/mm/damon/``, and it
106 The monitoring-related information including request specifications and results
[all …]
|
| /Linux-v6.1/Documentation/usb/ |
| D | CREDITS | 31 Linux USB driver effort and writing much of the larger uusbd driver.
35 and offering suggestions and sharing implementation experiences.
37 Additional thanks to the following companies and people for donations
38 of hardware, support, time and development (this is from the original
44 - 3Com GmbH for donating a ISDN Pro TA and supporting me
45 in technical questions and with test equipment. I'd never
52 Operating System and supports this project with
74 protocol. They've also donated a F-23 digital joystick and a
79 leading manufacturer for active and passive ISDN Controllers
80 and CAPI 2.0-based software. The active design of the AVM B1
[all …]
|
| /Linux-v6.1/Documentation/x86/ |
| D | intel_txt.rst | 15 - Measurement and verification of launched environment
17 Intel TXT is part of the vPro(TM) brand and is also available some
19 based on the Q35, X38, Q45, and Q43 Express chipsets (e.g. Dell
20 Optiplex 755, HP dc7800, etc.) and mobile systems based on the GM45,
21 PM45, and GS45 Express chipsets.
47 uses Intel TXT to perform a measured and verified launch of an OS
55 w/ TXT support since v3.2), and now Linux kernels.
61 While there are many products and technologies that attempt to
64 Measurement Architecture (IMA) and Linux Integrity Module interface
69 starting at system reset and requires measurement of all code
[all …]
|
| /Linux-v6.1/Documentation/driver-api/surface_aggregator/ |
| D | internal.rst | 49 and Surface Serial Hub (SSH) driver. For the API documentation, refer to:
66 the packet transport logic and handles things like packet validation, packet
67 acknowledgment (ACKing), packet (retransmission) timeouts, and relaying
72 responses of the EC to those requests, and events (sent from EC to host).
74 responses to their corresponding requests, and implements request timeouts.
76 The *controller* layer is building on top of this and essentially decides
77 how request responses and, especially, events are dealt with. It provides an
79 workqueue for event and asynchronous request completion, and also manages
86 native SSAM devices, i.e. devices that are not defined in ACPI and not
87 implemented as platform devices, via |ssam_device| and |ssam_device_driver|
[all …]
|
| /Linux-v6.1/drivers/gpio/ |
| D | TODO | 8 to move away from the global GPIO numberspace and toward a descriptor-based
9 approach. This means that GPIO consumers, drivers and machine descriptions
24 and treat GPIO lines as abstract entities.
28 such as probe ordering and the introduction of -EPROBE_DEFER making probe
48 numberspace accessors from <linux/gpio.h> and eventually delete
54 This header and helpers appeared at one point when there was no proper
55 driver infrastructure for doing simpler MMIO GPIO devices and there was
58 the device tree back-end. It is legacy and should not be used in new code.
68 #include <linux/gpio/consumer.h> and stop doing custom parsing of the
69 GPIO lines from the device tree. This can be tricky and often ivolves
[all …]
|
| /Linux-v6.1/tools/perf/pmu-events/arch/x86/westmereep-dp/ |
| D | memory.json | 11 "BriefDescription": "REQUEST = ANY_DATA read and RESPONSE = ANY_DRAM AND REMOTE_FWD",
22 "BriefDescription": "REQUEST = ANY_DATA read and RESPONSE = ANY_LLC_MISS",
33 "BriefDescription": "REQUEST = ANY_DATA read and RESPONSE = OTHER_LOCAL_DRAM",
44 "BriefDescription": "REQUEST = ANY_DATA read and RESPONSE = REMOTE_DRAM",
55 "BriefDescription": "REQUEST = ANY IFETCH and RESPONSE = ANY_DRAM AND REMOTE_FWD",
66 "BriefDescription": "REQUEST = ANY IFETCH and RESPONSE = ANY_LLC_MISS",
77 "BriefDescription": "REQUEST = ANY IFETCH and RESPONSE = OTHER_LOCAL_DRAM",
88 "BriefDescription": "REQUEST = ANY IFETCH and RESPONSE = REMOTE_DRAM",
99 "BriefDescription": "REQUEST = ANY_REQUEST and RESPONSE = ANY_DRAM AND REMOTE_FWD",
110 "BriefDescription": "REQUEST = ANY_REQUEST and RESPONSE = ANY_LLC_MISS",
[all …]
|
| /Linux-v6.1/tools/usb/usbip/ |
| D | COPYING | 6 Everyone is permitted to copy and distribute verbatim copies
12 freedom to share and change it. By contrast, the GNU General Public
13 License is intended to guarantee your freedom to share and change free
16 Foundation's software and to any other program whose authors commit to
23 have the freedom to distribute copies of free software (and charge for
26 in new free programs; and that you know you can do these things.
36 source code. And you must show them these terms so they know their
39 We protect your rights with two steps: (1) copyright the software, and
41 distribute and/or modify the software.
43 Also, for each author's protection and ours, we want to make certain
[all …]
|
| /Linux-v6.1/LICENSES/preferred/ |
| D | GPL-2.0 | 25 Everyone is permitted to copy and distribute verbatim copies
31 freedom to share and change it. By contrast, the GNU General Public
32 License is intended to guarantee your freedom to share and change free
35 Foundation's software and to any other program whose authors commit to
42 have the freedom to distribute copies of free software (and charge for
45 in new free programs; and that you know you can do these things.
55 source code. And you must show them these terms so they know their
58 We protect your rights with two steps: (1) copyright the software, and
60 distribute and/or modify the software.
62 Also, for each author's protection and ours, we want to make certain
[all …]
|
| D | LGPL-2.0 | 21 Everyone is permitted to copy and distribute verbatim copies of this
30 share and change it. By contrast, the GNU General Public Licenses are
31 intended to guarantee your freedom to share and change free software--to
35 designated Free Software Foundation software, and to any other libraries
40 to distribute copies of free software (and charge for this service if you
42 can change the software or use pieces of it in new free programs; and that
55 changes to the library and recompiling it. And you must show them these
59 library, and (2) offer you this license which gives you legal permission to
60 copy, distribute and/or modify the library.
64 the library is modified by someone else and passed on, we want its
[all …]
|
| /Linux-v6.1/Documentation/driver-api/usb/ |
| D | gadget.rst | 12 within peripherals and other USB devices that embed Linux. It provides
13 an overview of the API structure, and shows how that fits into a system
26 and alternate interface settings.
31 - Sharing data structures and API models with the Linux-USB host side
32 API. This helps the OTG support, and looks forward to more-symmetric
33 frameworks (where the same I/O model is used by both host and device
47 driver is the master (or "client driver") and the gadget driver is the
51 queues of request objects to package I/O buffers, and those requests may
53 USB *Chapter 9* messages, structures, and constants. Also, both APIs
54 bind and unbind drivers to devices. The APIs differ in detail, since the
[all …]
|
| /Linux-v6.1/Documentation/admin-guide/media/ |
| D | vivid.rst | 7 output, vbi capture and output, metadata capture and output, radio receivers and
8 transmitters, touch capture and a software defined radio receiver. In addition a
9 simple framebuffer device is available for testing capture and output overlays.
11 Up to 64 vivid instances can be created, each with up to 16 inputs and 16 outputs.
17 These inputs and outputs act exactly as a real hardware device would behave. This
23 - Support for read()/write(), MMAP, USERPTR and DMABUF streaming I/O.
24 - A large list of test patterns and variations thereof
25 - Working brightness, contrast, saturation and hue controls
29 - Support for various pixel aspect ratios and video aspect ratios
31 - Supports crop/compose/scale in any combination for both input and output
[all …]
|
| /Linux-v6.1/Documentation/process/ |
| D | code-of-conduct-interpretation.rst | 8 open-source community is unique and the Linux kernel is no exception.
11 to be static over time, and will adjust it as needed.
14 to "traditional" ways of developing software. Your contributions and
16 critique and criticism. The review will almost always require
21 system kernel ever, and we do not want to do anything to cause the
22 quality of submission and eventual result to ever decrease.
29 subsystem, driver, or file, and is listed in the MAINTAINERS file in the
35 The Code of Conduct mentions rights and responsibilities for
36 maintainers, and this needs some further clarifications.
38 First and foremost, it is a reasonable expectation to have maintainers
[all …]
|
