Searched full:they (Results 1 – 25 of 3996) sorted by relevance
12345678910>>...160
| /openbmc/linux/Documentation/process/ |
| D | management-style.rst | |
| D | 6.Followthrough.rst | |
| /openbmc/linux/tools/perf/pmu-events/arch/x86/rocketlake/ |
| D | floating-point.json | |
| /openbmc/linux/tools/perf/pmu-events/arch/x86/icelake/ |
| D | floating-point.json | |
| /openbmc/linux/tools/perf/pmu-events/arch/x86/tigerlake/ |
| D | floating-point.json | |
| /openbmc/linux/tools/perf/pmu-events/arch/x86/icelakex/ |
| D | floating-point.json | |
| /openbmc/qemu/docs/devel/ |
| H A D | kconfig.rst | 11 card, even though the boards use different PCI host bridges, and they
26 to list the components they need, and the compiled executable will
52 symbols; they are only visible in the Makefile. Each configurable component
56 falsehood is written ``n``. They are defined in a Kconfig
113 if more than one default is present, they will have different
148 Subsystems always default to false (they have no ``default`` directive)
150 up to other symbols to ``select`` whatever subsystems they require.
152 They sometimes have ``select`` directives to bring in other required
166 Devices are the most complex of the five. They can have a variety
170 Devices *depend on* the bus that they lie on, for example a PCI
[all …]
|
| H A D | maintainers.rst | 7 They come from a wide range of backgrounds from unpaid hobbyists
16 They are also human and subject to the same pressures as everyone else
17 including overload and burnout. Like everyone else they are subject
45 - It has a maintainer but they don't have time to do
53 it does not mean they are paid to support you. This is open source and
76 asked by others to keep an eye on an area of code. They have generally
78 reviews, that they have a good understanding of the subsystem. They
96 GPG is used to sign pull requests so they can be identified as really
|
| H A D | code-provenance.rst | 10 patch submissions they make to the project. To put it another way,
11 contributors must indicate that they are legally permitted to contribute to
62 If the person sending the mail is not one of the patch authors, they are
73 * The non-primary author's contributions were so trivial that they can be
93 When multiple ``Signed-off-by`` tags are present, they should be strictly kept
103 mailing list, if they consider the patch acceptable, they should send an
105 review a patch should add this even if they are also adding their
110 queue it and send a pull request, they would send a mail containing a
113 maintainer wants to indicate they have done a full review they should use
117 behaviour of the patch in some manner, they should send an email reply
[all …]
|
| /openbmc/linux/tools/perf/pmu-events/arch/x86/sapphirerapids/ |
| D | floating-point.json | |
| /openbmc/linux/tools/perf/pmu-events/arch/x86/alderlake/ |
| D | floating-point.json | |
| /openbmc/linux/tools/perf/pmu-events/arch/x86/meteorlake/ |
| D | floating-point.json | |
| /openbmc/linux/Documentation/core-api/ |
| D | errseq.rst | |
| /openbmc/linux/tools/perf/pmu-events/arch/x86/broadwellde/ |
| D | floating-point.json | |
| /openbmc/linux/tools/perf/pmu-events/arch/x86/broadwellx/ |
| D | floating-point.json | |
| /openbmc/linux/tools/perf/pmu-events/arch/x86/broadwell/ |
| D | floating-point.json | |
| /openbmc/linux/tools/perf/pmu-events/arch/x86/skylakex/ |
| D | floating-point.json | |
| /openbmc/linux/tools/perf/pmu-events/arch/x86/snowridgex/ |
| D | uncore-memory.json | |
| /openbmc/linux/arch/hexagon/include/asm/ |
| D | tlbflush.h | |
| /openbmc/openbmc/poky/documentation/dev-manual/ |
| H A D | security-subjects.rst | 7 used in numerous products. They assemble multiple other open-source projects,
88 vulnerability reports before they are released.
112 are individuals selected by merit and do not represent the companies they work
113 for. They do not share information about confidential issues outside of the team
123 vulnerability, they quickly analyze and notify the reporter of the result.
124 They might also request more information.
126 If the issue is confirmed and affects the code maintained by the YP, they
132 If they deem it a real security problem in their software, they develop and
133 release a fix following their security policy. They may want to include the
147 problem. If they deem it a real security problem in their software, they
[all …]
|
| /openbmc/linux/Documentation/locking/ |
| D | spinlocks.rst | |
| /openbmc/linux/tools/perf/pmu-events/arch/x86/cascadelakex/ |
| D | floating-point.json | |
| /openbmc/entity-manager/configurations/ |
| H A D | VENDORS.md | 3 To simplify the organization and ownership of configuration files, they can be
23 which they exclusively label and sell, such as a server chassis, they are the
37 claims to be the vendor of a device, they probably are, unless there is strong
38 evidence they are not.
|
| /openbmc/linux/Documentation/input/ |
| D | gamepad.rst | |
| /openbmc/phosphor-ipmi-flash/bmc/firmware-handler/ |
| H A D | firmware_handler.cpp | 140 /* They are requesting information about the generic blob_id. */ in stat()
310 /* 2a) are they opening the active image? this can only happen if they in open()
313 /* 2b) are they opening the active hash? this can only happen if they in open()
319 /* Check that they've opened for writing - read back not currently in open()
327 /* Because canHandleBlob is called before open, we know that if they try to in open()
328 * open the verifyBlobId, they're in a state where it's present. in open()
341 * aren't open because of the fileOpen() check. They can still open in open()
363 /* When in this state, they can only open the updateBlobId */ in open()
385 /* To support multiple firmware options, we need to make sure they're in open()
386 * opening the one they already opened during this update sequence, or it's in open()
[all …]
|
12345678910>>...160