| /linux/tools/perf/pmu-events/arch/x86/broadwellx/ |
| H A D | uncore-power.json | 178 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
187 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
196 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
205 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
214 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
223 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
232 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
241 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
250 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
259 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
[all …]
|
| /linux/tools/perf/pmu-events/arch/x86/broadwellde/ |
| H A D | uncore-power.json | 178 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
187 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
196 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
205 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
214 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
223 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
232 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
241 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
250 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
259 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
[all …]
|
| /linux/tools/perf/pmu-events/arch/x86/haswellx/ |
| H A D | uncore-power.json | 178 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
187 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
196 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
205 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
214 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
223 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
232 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
241 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
250 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
259 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
[all …]
|
| /linux/tools/perf/pmu-events/arch/x86/ivytown/ |
| H A D | uncore-power.json | 286 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
295 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
304 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
313 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
322 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
331 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
340 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
349 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
358 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
367 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
[all …]
|
| /linux/Documentation/driver-api/usb/ |
| H A D | persist.rst | 29 though they had disconnected. This is always safe and it is the
39 devices. The effect is exactly the same as if the device really had
40 been unplugged while the system was suspended. If you had a mounted
52 it's as though you had unplugged all the USB devices. Yes, it's
78 reset or otherwise had lost power) then it applies a persistence check
87 kernel treats the device as though it had merely been reset instead of
97 behaves as though the old device had been unplugged and a new device
|
| /linux/tools/perf/pmu-events/arch/x86/jaketown/ |
| H A D | uncore-power.json | 88 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
97 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
106 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
115 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
124 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
133 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
142 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
151 …"PublicDescription": "Counts the number of times when a configurable cores had a C-state demotion",
249 …of threads in C0 to estimate the performance impact that frequency transitions had on the system.",
|
| /linux/Documentation/arch/arm/nwfpe/ |
| H A D | notes.rst | 16 f4 had been converted to an extended value in the emulator.
18 This is a side effect of the stfe instruction. The double in f4 had to be
19 converted to extended, then stored. If an lfm/sfm combination had been used,
|
| /linux/arch/mips/include/asm/octeon/ |
| H A D | cvmx-wqe.h | 333 * than allowed and had an FCS error.
338 * and had an FCS error (100M and 10M only).
340 * than allowed and had an FCS error.
341 * - 7 = GMX FCS error: the RGMII packet had an FCS
345 * - 9 = extend error: the RGMII packet had an extend
347 * - 10 = length mismatch error: the RGMII packet had
351 * packet had one or more data reception errors
352 * (RXERR) or the SPI4 packet had one or more
359 * RGMII packet had a studder error (data not
362 * - 16 = FCS error: a SPI4.2 packet had an FCS error.
|
| /linux/Documentation/filesystems/ |
| H A D | directory-locking.rst | 192 if all operations had been of the "lock parent, then child" sort
195 have changed since the moment directory locks had been acquired,
211 all of them had been stable.
224 It can't be a parent and its child; otherwise we would've had
247 in between (all of those would fail with -ENOTEMPTY, had they ever gotten
257 had its parent changed. In other words, the loop must be passing through
264 not have passed through the node itself, or we would've had a loop before
|
| H A D | porting.rst | 148 FS_SINGLE is gone (actually, that had happened back when ->get_sb()
237 ->revalidate() is gone. If your filesystem had it - provide ->getattr()
238 and let it call whatever you had as ->revlidate() + (for symlinks that
239 had ->revalidate()) add calls in ->follow_link()/->readlink().
249 * we know that parent had been locked (e.g. we are looking at
256 had been relying on BKL and that's prone to screwups. Old tree had quite
355 if it's zero is not *and* *never* *had* *been* enough. Final unlink() and iput()
399 via rcu-walk path walk (basically, if the file can have had a path name in the
667 it's a symlink. Checking ->i_mode is really needed now. In-tree we had
1002 the superblock had been removed from the list of superblocks of the
[all …]
|
| /linux/include/net/ |
| H A D | inet_frag.h | 175 #define IPFRAG_ECN_NOT_ECT 0x01 /* one frag had ECN_NOT_ECT */
176 #define IPFRAG_ECN_ECT_1 0x02 /* one frag had ECN_ECT_1 */
177 #define IPFRAG_ECN_ECT_0 0x04 /* one frag had ECN_ECT_0 */
178 #define IPFRAG_ECN_CE 0x08 /* one frag had ECN_CE */
|
| /linux/fs/btrfs/tests/ |
| H A D | extent-buffer-tests.c | 19 char *value = "mary had a little lamb"; in test_btrfs_split_item()
20 char *split1 = "mary had a little"; in test_btrfs_split_item()
23 char *split4 = " had a little"; in test_btrfs_split_item()
87 * 'mary had a little' in test_btrfs_split_item()
|
| /linux/Documentation/ABI/removed/ |
| H A D | video1394 | 7 alternative to raw1394's isochronous I/O functionality which had
8 performance issues in its first generation. Any video1394 user had
|
| /linux/Documentation/block/ |
| H A D | biovecs.rst | 55 it had to walk two different bios at the same time, keeping both bi_idx and
63 * Before, any code that might need to use the biovec after the bio had been
65 it somewhere else if there was an error) had to save the entire bvec array
85 bcache) had some ugly workarounds for this.
|
| /linux/Documentation/process/ |
| H A D | stable-api-nonsense.rst | 60 Assuming that we had a stable kernel source interface for the kernel, a
132 which have had to maintain their older USB interfaces over time. This
139 relatively little pain. If Linux had to ensure that it will preserve a
141 the older, broken one would have had to be maintained over time, leading
|
| /linux/drivers/media/platform/mediatek/vcodec/common/ |
| H A D | mtk_vcodec_cmn_drv.h | 95 * @MTK_STATE_HEADER: vdec had sps/pps header parsed or venc
96 * had sps/pps header encoded
|
| /linux/drivers/media/test-drivers/vidtv/ |
| H A D | vidtv_common.c | 45 …pr_err_ratelimited("overflow detected, skipping. Try increasing the buffer size. Needed %zu, had %… in vidtv_memcpy()
81 …pr_err_ratelimited("overflow detected, skipping. Try increasing the buffer size. Needed %zu, had %… in vidtv_memset()
|
| /linux/drivers/base/firmware_loader/ |
| H A D | sysfs.h | 21 * as if one had enabled CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y.
25 * This emulates the behaviour as if we had set the kernel
|
| /linux/drivers/net/wireless/ath/ath9k/ |
| H A D | common-debug.h | 22 may have had errors.
24 may have had errors.
|
| /linux/Documentation/sound/soc/ |
| H A D | overview.rst | 9 had some limitations:-
13 Linux had different wm8731 drivers for 4 different SoC platforms.
|
| /linux/drivers/net/ethernet/freescale/ |
| H A D | ucc_geth.h | 89 successfully that had destination address
101 that had destination address equal to the
534 u32 removevlan; /* total frames that had their VLAN tag removed
536 u32 replacevlan; /* total frames that had their VLAN tag
538 u32 insertvlan; /* total frames that had their VLAN tag
733 u32 removevlan; /* total frames that had their VLAN tag removed
735 u32 replacevlan; /* total frames that had their VLAN tag
737 u32 insertvlan; /* total frames that had their VLAN tag
774 successfully that had destination address
786 that had destination address equal to the
|
| /linux/Documentation/networking/ |
| H A D | tls.rst | 267 this will look like TLS records had been tampered with and will result
279 If the record decrypted turns out to had been padded or is not a data
310 number of RX records which had to be re-decrypted due to
315 number of data RX records which had to be re-decrypted due to
|
| /linux/arch/powerpc/lib/ |
| H A D | strlen_32.S | 21 * 0 byte must have had no incoming carry (otherwise it's not the least
39 * iff that byte had one of its low 7 bits set. We can then just see
|
| /linux/tools/testing/selftests/powerpc/stringloops/ |
| H A D | strlen_32.S | 21 * 0 byte must have had no incoming carry (otherwise it's not the least
39 * iff that byte had one of its low 7 bits set. We can then just see
|
| /linux/Documentation/locking/ |
| H A D | lockstat.rst | 53 - number of lock acquisitions that had to wait
56 - shortest (non-0) time we ever had to wait for a lock
58 - longest time we ever had to wait for a lock
81 that had to wait on lock acquisition.
|