Searched full:our (Results 1 – 25 of 167) sorted by relevance
1234567
| /Documentation/process/ |
| D | kernel-enforcement-statement.rst | 6 As developers of the Linux kernel, we have a keen interest in how our software
7 is used and how the license for our software is enforced. Compliance with the
9 sustainability of our software and community.
12 contributions made to our community, we share an interest in ensuring that
13 individual enforcement actions are conducted in a manner that benefits our
15 growth of our software ecosystem. In order to deter unhelpful enforcement
16 actions, we agree that it is in the best interests of our development
18 on behalf of ourselves and any successors to our copyright interests:
21 it is in the best interests of our development community to adopt the
22 following provisions of GPL-3.0 as additional permissions under our
[all …]
|
| D | code-of-conduct.rst | 6 Our Pledge
10 contributors and maintainers pledge to making participation in our project and
11 our community a harassment-free experience for everyone, regardless of age, body
16 Our Standards
41 Our Responsibilities
|
| D | index.rst | 14 to learn about how our community works. Reading these documents will make
76 The documents below describe our policies around the handling of a couple
|
| D | code-of-conduct-interpretation.rst | 41 That being said, our community is vast and broad, and there is no new
54 reach out to our conflict mediator, Joanna Lee <jlee@linuxfoundation.org>.
62 Our goal of creating a robust and technically advanced operating system
|
| D | embargoed-hardware-issues.rst | 36 according to our documented process.
62 The encrypted mailing-lists which are used in our process are hosted on
108 effective deterrent in our community. In case a violation happens the
174 From our experience, the technical documentation of these issues is usually
316 understand and support our process fully and is ideally well-connected in
|
| /Documentation/gpu/amdgpu/display/ |
| D | index.rst | 8 reason, our Display Core Driver is divided into two pieces:
23 repository has integration tests with our Internal Linux CI farm, and we run a
25 and APUs). Our CI also checks ARM64/32, PPC64/32, and x86_64/32 compilation
33 * Ensure that every patch compiles and the entire series pass our set of IGT
35 * Prepare a branch with those patches for our validation team. If there is an
44 seriously, and we never merge anything that fails our validation. Follows an
45 overview of our test set:
70 Notice that someone from our test team will always reply to the cover letter
85 If you want to learn more about our driver details, take a look at the below
|
| D | dcn-overview.rst | 5 To equip our readers with the basic knowledge of how AMD Display Core Next
32 * **Display Output (DIO)**: Codify the output to the display connected to our
54 the SDP as the element from our Data Fabric that feeds the display pipe.
59 want to drive an 8k@60Hz with a DSC enabled, our DCN may require 4 DPP and 2
79 that HUBP accesses a surface using a specific format read from memory, and our
184 configuration parameters for multiple scenarios supported by our hardware.
204 based on a large number of parameters and ensure our hardware is able to feed
|
| /Documentation/networking/device_drivers/ethernet/wangxun/ |
| D | ngbe.rst | 12 If you have problems with the software or hardware, please contact our
13 customer support team via email at nic-support@net-swift.com or check our website
|
| /Documentation/driver-api/usb/ |
| D | writing_usb_driver.rst | 167 the program tries to open the device for I/O. We increment our private
168 usage count and save a pointer to our internal structure in the file
173 /* increment our usage count for the device */
176 /* save our object in the file's private structure */
193 /* copy the data from user space into our urb */
196 /* set up our urb */
216 to call our own ``skel_write_bulk_callback`` function. This function is
219 do very much processing at that time. Our implementation of
256 this function we decrement our private usage count and wait for possible
259 /* decrement our usage count for the device */
|
| /Documentation/filesystems/bcachefs/ |
| D | CodingStyle.rst | 6 Good development is like gardening, and codebases are our gardens. Tend to them
23 Assertions are one of our most important tools for writing reliable code. If in
55 can still incorporate that kind of thinking into our code and document the
171 The most important tools (besides the compiler and our text editor) are the
174 errors in our thinking by running our code and seeing what happens. If your
|
| /Documentation/devicetree/bindings/i2c/ |
| D | i2c-arb-gpio-challenge.yaml | 58 our-claim-gpios:
95 - our-claim-gpios
109 our-claim-gpios = <&gpf0 3 GPIO_ACTIVE_LOW>;
|
| D | i2c-gpio.yaml | 59 description: this means that something outside of our control has put
66 description: this means that something outside of our control has put the
|
| /Documentation/scheduler/ |
| D | sched-domains.rst | 42 sched domains our CPU is on, starting from its base domain and going up the ->parent
50 that group. If it manages to find such a runqueue, it locks both our initial
52 to our runqueue. The exact number of tasks amounts to an imbalance previously
|
| /Documentation/ABI/testing/ |
| D | sysfs-driver-tegra-fuse | 1 What: /sys/devices/*/<our-device>/fuse
|
| D | sysfs-driver-jz4780-efuse | 1 What: /sys/devices/*/<our-device>/nvmem
|
| /Documentation/driver-api/iio/ |
| D | triggers.rst | 39 trigger with our device by writing the trigger's name in the
54 /* first, allocate memory for our trigger */
|
| /Documentation/dev-tools/kunit/ |
| D | run_wrapper.rst | 191 our system.
195 website to a directory in our home directory called toolchains.
214 non-default configuration; then we can write our own``QemuConfig``.
238 be useful for our test environment. Below are the most commonly used
292 our system.
296 website to a specified path in our home directory called toolchains.
|
| D | run_manual.rst | 26 tests can also be built by enabling their config options in our
38 Once we have built our kernel (and/or modules), it is simple to run
|
| /Documentation/arch/openrisc/ |
| D | todo.rst | 8 that are due for investigation shortly, i.e. our TODO list:
|
| /Documentation/driver-api/driver-model/ |
| D | design-patterns.rst | 41 called. This is our state container for this instance of the device driver.
114 We can see here that we avoid having global pointers to our struct foo *
|
| /Documentation/doc-guide/ |
| D | contributing.rst | 25 There is an endless list of tasks that need to be carried out to get our
193 mislead readers and casts doubt on our documentation as a whole. Anything
216 should do that anyway. Extra cruft in our documentation helps nobody.
227 That way, at least our long-suffering readers have been warned that the
270 Edward Tufte would be unimpressed. That requires tweaking our stylesheets
|
| /Documentation/devicetree/bindings/ufs/ |
| D | snps,tc-dwc-g210.yaml | 12 # Select only our matches, not all jedec,ufs
|
| D | cdns,ufshc.yaml | 12 # Select only our matches, not all jedec,ufs-2.0
|
| /Documentation/input/ |
| D | uinput.rst | 90 * to send. This pause is only needed in our example code!
153 * to send. This pause is only needed in our example code!
224 * to send. This pause is only needed in our example code!
|
| /Documentation/arch/arm/nwfpe/ |
| D | notes.rst | 4 There seems to be a problem with exp(double) and our emulator. I haven't
|
1234567