| /OK3568_Linux_fs/external/xserver/hw/dmx/doc/ |
| H A D | scaled.xml | 80 All primitives drawn to scaled window would be
171 A better solution would be to cache all updates to the
173 damaged area to the X display with XPutImage. This would
199 Extension, so this would not provide an immediate solution
220 so that XvPutImage would be the only method for
276 Video can be implemented that would support XvPutImage
277 and little else. This would require support for the
312 XPutImage. This pathway would have poor
330 Extension in DMX, one obvious solution would be to
333 call available under Windows. This call would scale RGB
[all …]
|
| /OK3568_Linux_fs/kernel/block/partitions/ |
| H A D | Kconfig | 8 Say Y here if you would like to use hard disks under Linux which
29 Say Y here if you would like to use hard disks under Linux which
42 Say Y here if you would like to use hard disks under Linux which
75 Say Y here if you would like to be able to read the hard disk
87 Say Y here if you would like to use hard disks under Linux which
94 Say Y here if you would like to use hard disks under Linux which
101 Say Y here if you would like to use hard disks under Linux which
108 Say Y here if you would like to be able to read the hard disk
116 Say Y here if you would like to use hard disks under Linux which
180 Say Y here if you would like to use hard disks under Linux which
[all …]
|
| /OK3568_Linux_fs/u-boot/drivers/usb/eth/ |
| H A D | Kconfig | 4 Say Y here if you would like to enable support for USB Ethernet
13 Say Y here if you would like to support ASIX AX8817X based USB 2.0
20 Say Y here if you would like to support ASIX AX88179 based USB 3.0
27 Say Y here if you would like to support Microchip LAN75XX Hi-Speed
36 Say Y here if you would like to support Microchip LAN78XX USB 3.1
45 Say Y here if you would like to support MOSCHIP MCS7830 based
52 Say Y here if you would like to support Realtek RTL8152B/RTL8153 base
60 Say Y here if you would like to support SMSC LAN95xx based USB 2.0
|
| /OK3568_Linux_fs/kernel/Documentation/filesystems/ |
| H A D | directory-locking.rst | 77 the parent of object and it would have to lock the parent).
110 Otherwise the set of contended objects would be infinite - each of them
111 would have a contended child and we had assumed that no object is its
117 would again have an infinite set of contended objects). But that
128 source), such loop would have to contain these objects and the rest of it
129 would have to exist before rename(). I.e. at the moment of loop creation
130 rename() responsible for that would be holding filesystem lock and new parent
131 would have to be equal to or a descendent of source. But that means that
133 we had acquired filesystem lock and rename() would fail with -ELOOP in that
139 also preserved by all operations (cross-directory rename on a tree that would
[all …]
|
| H A D | ocfs2-online-filecheck.rst | 13 necessary, since turning the filesystem read-only would affect other running
15 Then, a mount option (errors=continue) is introduced, which would return the
34 the offline fsck should/would be recommended.
43 by the inode number which caused the error. This inode number would be the
51 mounted. The file above would accept inode numbers. This could be used to
91 On receiving the inode, the filesystem would read the inode and the
92 file metadata. In case of errors, the filesystem would fix the errors
97 small linked list buffer which would contain the last (N) inodes
|
| H A D | fsverity.rst | 35 subject to the caveat that reads which would violate the hash will
60 accessed on a particular device. It would be slow and wasteful to
274 to be authenticated against the file digest that would be returned by
331 would circumvent the data verification.
553 are marked Uptodate. Merely hooking ``->read_iter()`` would be
620 direct I/O would bypass fs-verity. (They also do the same for
690 then you could simply do sha256(file) instead. That would be much
695 first read. However, it would be inefficient because every time a
722 :A: Write support would be very difficult and would require a
724 fs-verity. Write support would require:
[all …]
|
| /OK3568_Linux_fs/kernel/Documentation/w1/masters/ |
| H A D | ds2490.rst | 32 was added to the API. The name is just a suggestion. It would take
52 clear the entire bulk in buffer. It would be possible to read the
60 with a OHCI controller, ds2490 running in the guest would operate
64 would fail. qemu sets a 50ms timeout and the bulk in would timeout
65 even when the status shows data available. A bulk out write would
66 show a successful completion, but the ds2490 status register would
68 reattaching would clear the problem. usbmon output in the guest and
|
| /OK3568_Linux_fs/kernel/Documentation/networking/ |
| H A D | snmp_counter.rst | 44 multicast packets, and would always be updated together with
137 would be increased even if the ICMP packet has an invalid type. The
139 IcmpOutMsgs would still be updated if the IP header is constructed by
207 IcmpMsgOutType8 would increase 1. And if kernel gets an ICMP Echo Reply
208 packet, IcmpMsgInType0 would increase 1.
215 IcmpInMsgs would be updated but none of IcmpMsgInType[N] would be updated.
225 counters would be updated. The receiving packet path use IcmpInErrors
227 is increased, IcmpInErrors would always be increased too.
263 packets would be delivered to the TCP layer, but the TCP layer will discard
266 counter would only increase 1.
[all …]
|
| /OK3568_Linux_fs/kernel/Documentation/RCU/ |
| H A D | UP.rst | 26 from softirq, the list scan would find itself referencing a newly freed
47 its arguments would cause it to fail to make the fundamental guarantee
61 call_rcu() were to directly invoke the callback, the result would
64 In some cases, it would possible to restructure to code so that
69 the same critical section, then the code would need to create
81 or API changes would be required.
127 the process-context critical section. This would result in
141 simply immediately returned, it would prematurely signal the
142 end of the grace period, which would come as a nasty shock to
|
| /OK3568_Linux_fs/kernel/Documentation/bpf/ |
| H A D | ringbuf.rst | 27 would solve the second problem automatically.
36 One way would be to, similar to ``BPF_MAP_TYPE_PERF_EVENT_ARRAY``, make
38 enforce "same CPU only" rule. This would be more familiar interface compatible
39 with existing perf buffer use in BPF, but would fail if application needed more
42 Additionally, given the performance of BPF ringbuf, many use cases would just
44 approach would be an overkill.
48 with lookup/update/delete operations. This approach would add a lot of extra
50 would also add another concept that BPF developers would have to familiarize
51 themselves with, new syntax in libbpf, etc. But then would really provide no
60 ring buffer for all CPUs, it's as simple and straightforward, as would be with
[all …]
|
| /OK3568_Linux_fs/u-boot/disk/ |
| H A D | Kconfig | 30 Say Y here if you would like to use device under U-Boot which
66 Say Y here if you would like to use device under U-Boot which
80 Say Y here if you would like to use device under U-Boot which
143 Say Y here if you would like to use ENV partition table.
150 Say Y here if you would like to use ENV partition table in SPL.
156 Say Y here if you would like to use device under U-Boot which
164 Say Y here if you would like to use device under U-Boot which
|
| /OK3568_Linux_fs/kernel/drivers/net/wireless/intel/iwlwifi/cfg/ |
| H A D | 22000.c | 322 * HT size; mac80211 would otherwise pick the HE max (256) by default.
334 * HT size; mac80211 would otherwise pick the HE max (256) by default.
384 * HT size; mac80211 would otherwise pick the HE max (256) by default.
397 * HT size; mac80211 would otherwise pick the HE max (256) by default.
410 * HT size; mac80211 would otherwise pick the HE max (256) by default.
422 * HT size; mac80211 would otherwise pick the HE max (256) by default.
435 * HT size; mac80211 would otherwise pick the HE max (256) by default.
448 * HT size; mac80211 would otherwise pick the HE max (256) by default.
460 * HT size; mac80211 would otherwise pick the HE max (256) by default.
474 * HT size; mac80211 would otherwise pick the HE max (256) by default.
[all …]
|
| /OK3568_Linux_fs/kernel/Documentation/firmware-guide/acpi/ |
| H A D | osi.rst | 73 The ACPI BIOS flow would include an evaluation of _OS, and the AML
74 interpreter in the kernel would return to it a string identifying the OS:
86 of every possible version of the OS that would run on it, and needed to know
87 all the quirks of those OS's. Certainly it would make more sense
94 that anybody would install those old operating systems
107 eg. _OSI("3.0 Thermal Model") would return TRUE if the OS knows how
109 An old OS that doesn't know about those extensions would answer FALSE,
124 and its successors. To do otherwise would virtually guarantee breaking
159 which would increment, based on the version of the spec supported.
161 Unfortunately, _REV was also misused. eg. some BIOS would check
|
| /OK3568_Linux_fs/kernel/Documentation/admin-guide/device-mapper/ |
| H A D | log-writes.rst | 31 The log would show the following:
36 cases where a power failure at a particular point in time would create an
42 Any REQ_OP_DISCARD requests are treated like WRITE requests. Otherwise we would
48 If we logged DISCARD when it completed, the replay would look like this:
82 we're fsck'ing something reasonable, you would do something like
89 This would allow you to replay the log up to the mkfs mark and
104 Say you want to test fsync on your file system. You would do something like
|
| /OK3568_Linux_fs/u-boot/doc/ |
| H A D | README.unaligned-memory-access.txt | 19 reading 4 bytes of data from address 0x10005 would be an unaligned memory
50 to architecture. It would be easy to write a whole document on the differences
88 starting at address 0x10000. With a basic level of understanding, it would
89 not be unreasonable to expect that accessing field2 would cause an unaligned
95 above case it would insert 2 bytes of padding in between field1 and field2.
110 where padding would otherwise be inserted, and hence reduce the overall
120 For a natural alignment scheme, the compiler would only have to add a single
166 Think about what would happen if addr1 was an odd address such as 0x10003.
210 To avoid the unaligned memory access, you would rewrite it as follows:
|
| /OK3568_Linux_fs/kernel/Documentation/scsi/ |
| H A D | lpfc.rst | 36 the LLDD would simply be queued for a short duration, allowing the device
38 to the system. If the driver did not hide these conditions, i/o would be
39 errored by the driver, the mid-layer would exhaust its retries, and the
40 device would be taken offline. Manual intervention would be required to
|
| /OK3568_Linux_fs/yocto/meta-openembedded/meta-oe/recipes-graphics/openbox/files/ |
| H A D | 0001-openbox-xdg-autostart-convert-to-python3.patch | 84 - print " --list Show a list of the files which would be run"
85 - print " Files which would be run are marked with an asterix"
86 - print " symbol [*]. For files which would not be run,"
107 + print(" --list Show a list of the files which would be run")
108 + print(" Files which would be run are marked with an asterix")
109 + print(" symbol [*]. For files which would not be run,")
|
| /OK3568_Linux_fs/kernel/Documentation/admin-guide/LSM/ |
| H A D | SafeSetID.rst | 36 program would still need CAP_SETUID to do any kind of transition, but the
37 additional restrictions imposed by this LSM would mean it is a "safer" version
53 For candidate applications that would like to have restricted setid capabilities
54 as implemented in this LSM, an alternative option would be to simply take away
58 number of semantics around process spawning that would be affected by this, such
63 userspace would likely be less appealing to incorporate into existing projects
68 Another possible approach would be to run a given process tree in its own user
|
| /OK3568_Linux_fs/kernel/drivers/block/paride/ |
| H A D | Transition-notes | 63 the thread was holding pd_lock and found pd_busy not set, which would
73 we would have to be called for the PIA that got ->claimed_cont
85 But that code does not reset pd_busy, so pd_busy would have to be
87 we were acquiring the lock, (1) would be already false, since
88 the thread that had reset it would be in the area simulateously.
89 If it was 0 before we tried to acquire pd_lock, (2) would be
108 point, we would have violated either (2.1) (if it was set while ps_set_intr()
|
| /OK3568_Linux_fs/yocto/poky/meta/recipes-core/glibc/glibc/ |
| H A D | 0002-localedef-fix-ups-hardlink-to-make-it-compile.patch | 64 - _("Would link: ") :
66 + ("Would link: ") :
69 - _("Would save: ") :
71 + ("Would save: ") :
174 - (ctl->no_link ? _("Would link") : _("Linked")),
176 + (ctl->no_link ? ("Would link") : ("Linked")),
182 - (ctl->no_link ? _("Would link") : _("Linked")),
184 + (ctl->no_link ? ("Would link") : ("Linked")),
186 - (ctl->no_link ? _("would save") : _("saved")),
187 + (ctl->no_link ? ("would save") : ("saved")),
|
| /OK3568_Linux_fs/kernel/Documentation/core-api/ |
| H A D | unaligned-memory-access.rst | 25 reading 4 bytes of data from address 0x10005 would be an unaligned memory
56 to architecture. It would be easy to write a whole document on the differences
94 starting at address 0x10000. With a basic level of understanding, it would
95 not be unreasonable to expect that accessing field2 would cause an unaligned
101 above case it would insert 2 bytes of padding in between field1 and field2.
116 where padding would otherwise be inserted, and hence reduce the overall
126 For a natural alignment scheme, the compiler would only have to add a single
172 Think about what would happen if addr1 was an odd address such as 0x10003.
218 To avoid the unaligned memory access, you would rewrite it as follows::
|
| /OK3568_Linux_fs/kernel/tools/memory-model/Documentation/ |
| H A D | explanation.txt | 157 Some predictions are trivial. For instance, no sane memory model would
170 unconditionally then we would instead have r1 = 0 and r2 = 1.)
173 If this were to occur it would mean the driver contains a bug, because
174 incorrect data would get sent to the user: 0 instead of 1. As it
203 would be 1 since a load obtains its value from the most recent
213 Consistency memory model; doing so would rule out too many valuable
266 Z ordered before X, because this would mean that X is ordered before
278 if those accesses would form a cycle, then the memory model predicts
410 Given this version of the code, the LKMM would predict that the load
620 If the final value stored in x after this code ran was 17, you would
[all …]
|
| /OK3568_Linux_fs/prebuilts/gcc/linux-x86/aarch64/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu/lib/gcc/aarch64-none-linux-gnu/10.3.1/plugin/include/ |
| H A D | color-macros.h | 35 (which is the behavior the user would instinctively expect
46 user would instinctively expect of HT (but is ok for CHT).
47 The instinctive behavior would include clearing the terminal
57 behavior of an HT in default background color that would
77 It would be impractical for GCC to become a full-fledged
|
| /OK3568_Linux_fs/prebuilts/gcc/linux-x86/arm/gcc-arm-10.3-2021.07-x86_64-arm-none-linux-gnueabihf/lib/gcc/arm-none-linux-gnueabihf/10.3.1/plugin/include/ |
| H A D | color-macros.h | 35 (which is the behavior the user would instinctively expect
46 user would instinctively expect of HT (but is ok for CHT).
47 The instinctive behavior would include clearing the terminal
57 behavior of an HT in default background color that would
77 It would be impractical for GCC to become a full-fledged
|
| /OK3568_Linux_fs/kernel/Documentation/block/ |
| H A D | biovecs.rst | 11 More specifically, old code that needed to partially complete a bio would
13 ended up partway through a biovec, it would increment bv_offset and decrement
85 It used to be the case that submitting a partially completed bio would work
87 norm, not all drivers would respect bi_idx and those would break. Now,
96 where previously you would have used bi_idx you'd now use a bvec_iter,
|