| /linux/Documentation/hid/ |
| H A D | hid-transport.rst | 86 channels, but they can also provide acknowledgement reports, automatic
100 reports. No management commands or data acknowledgements are sent on this
111 Outgoing reports are usually sent on the ctrl channel via synchronous
114 Communication between devices and HID core is mostly done via HID reports. A
117 - INPUT Report: Input reports provide data from device to host. This
122 - OUTPUT Report: Output reports change device states. They are sent from host
124 reports are never sent from device to host, but a host can retrieve their
126 Hosts may choose to send output reports either continuously or only on
128 - FEATURE Report: Feature reports are used for specific static device features
131 Feature reports are never sent without requests. A host must explicitly set
[all …]
|
| H A D | hidraw.rst | 6 Interface Devices (HIDs). It differs from hiddev in that reports sent and
12 reports manually. This is often the case when making userspace drivers for
17 descriptors. Because hiddev parses reports which are sent and received
45 devices, the reports read using read() are the reports sent from the device
51 On a device which uses numbered reports, the first byte of the returned data
53 byte. For devices which do not use numbered reports, the report data
64 number. If the device does not use numbered reports, the first byte should
115 specification, feature reports are always sent using the control endpoint.
117 which do not use numbered reports, set the first byte to 0. The report data
127 reports, set the first byte to 0. The returned report buffer will contain the
[all …]
|
| H A D | hidintro.rst | 37 exactly what *HID reports* may be sent between the device and the host
38 and the meaning of each individual bit in those reports. For example,
43 without any extra meta information. Note that HID reports may be sent
44 from the device ("Input Reports", i.e. input events), to the device
45 ("Output Reports" to e.g. change LEDs) or used for device configuration
46 ("Feature reports"). A device may support one or more HID reports.
109 to record and replay the raw HID reports and to debug
234 2, releases button 1, and finally releases button 2, the reports are::
249 Output, Input and Feature Reports
252 HID devices can have Input Reports, like in the mouse example, Output
[all …]
|
| /linux/Documentation/ABI/testing/ |
| H A D | sysfs-pps | 21 The /sys/class/pps/ppsX/assert file reports the assert events
33 The /sys/class/pps/ppsX/clear file reports the clear events
45 The /sys/class/pps/ppsX/mode file reports the functioning
55 The /sys/class/pps/ppsX/echo file reports if the X-th does
62 The /sys/class/pps/ppsX/name file reports the name of the
69 The /sys/class/pps/ppsX/path file reports the path name of
|
| H A D | sysfs-bus-iio-bno055 | 49 Reports the binary calibration data blob for the IMU sensors.
55 Reports the autocalibration status for the accelerometer sensor.
63 Reports the autocalibration status for the gyroscope sensor.
71 Reports the autocalibration status for the magnetometer sensor.
79 Reports the status for the IMU overall autocalibration.
|
| H A D | sysfs-class-remoteproc | 6 Reports the name of the firmware currently loaded to the
17 Reports the state of the remote processor, which will be one of:
58 Reports the name of the remote processor. This can be used by
67 Reports the coredump configuration of the remote processor,
91 Reports the recovery mechanism of the remote processor,
|
| H A D | sysfs-class-regulator | 7 state. This reports the regulator enable control, for
33 "status". This reports the current regulator status, for
380 under_voltage. This indicates if the device reports an
389 over_current. This indicates if the device reports an
398 regulation_out. This indicates if the device reports an
407 fail. This indicates if the device reports an output failure
416 over_temp. This indicates if the device reports an
425 under_voltage_warn. This indicates if the device reports an
434 over_current_warn. This indicates if the device reports an
443 over_voltage_warn. This indicates if the device reports an
[all …]
|
| H A D | sysfs-driver-input-exc3000 | 4 Description: Reports the firmware version provided by the touchscreen, for example "00_T6" on a …
13 Description: Reports the model identification provided by the touchscreen, for example "Orion_13…
22 Description: Reports the type identification provided by the touchscreen, for example "PCAP82H80 Se…
|
| H A D | sysfs-amd-pmc | 4 Description: Reading this file reports the version of the firmware loaded to
11 Description: Reading this file reports the program corresponding to the SMU
|
| /linux/drivers/hid/usbhid/ |
| H A D | hid-pidff.c | 25 /* Report usage table used to put reports into an array */
196 struct hid_report *reports[ARRAY_SIZE(pidff_reports)]; member
460 hid_hw_request(pidff->hid, pidff->reports[PID_SET_ENVELOPE], in pidff_set_envelope_report()
499 hid_hw_request(pidff->hid, pidff->reports[PID_SET_CONSTANT], in pidff_set_constant_report()
549 hid_hw_request(pidff->hid, pidff->reports[PID_SET_EFFECT], in pidff_set_effect_report()
582 hid_hw_request(pidff->hid, pidff->reports[PID_SET_PERIODIC], in pidff_set_periodic_report()
599 * Send condition effect reports to the device
629 hid_hw_request(pidff->hid, pidff->reports[PID_SET_CONDITION], in pidff_set_condition_report()
670 hid_hw_request(pidff->hid, pidff->reports[PID_SET_RAMP], in pidff_set_ramp_report()
692 hid_hw_request(pidff->hid, pidff->reports[PID_DEVICE_GAIN], in pidff_set_gain_report()
[all …]
|
| /linux/drivers/usb/serial/ |
| H A D | keyspan_usa90msg.h | 156 u8 msr, // reports the actual MSR register
157 cts, // reports CTS pin
158 dcd, // reports DCD pin
159 dsr, // reports DSR pin
160 ri, // reports RI pin
162 rxBreak, // reports break state
|
| H A D | keyspan_usa26msg.h | 209 hskia_cts, // USA26: reports HSKIA pin
210 // USA17: reports CTS pin
211 gpia_dcd, // USA26: reports GPIA pin
212 // USA17: reports DCD pin
213 dsr, // USA17: reports DSR pin
214 ri, // USA17: reports RI pin
|
| /linux/mm/kmsan/ |
| H A D | kmsan_test.c | 4 * For each test case checks the presence (or absence) of generated reports.
5 * Relies on 'console' tracepoint to capture reports as they appear in the
184 kunit_info(test, "initialized kmalloc test (no reports)\n"); in test_init_kmalloc()
197 kunit_info(test, "initialized kzalloc test (no reports)\n"); in test_init_kzalloc()
220 kunit_info(test, "initialized stack variable (no reports)\n"); in test_init_stack_var()
295 * Test case: ensure kmsan_check_memory() reports an error when checking
323 kunit_info(test, "pages initialized via vmap (no reports)\n"); in test_init_kmsan_vmap_vunmap()
353 kunit_info(test, "vmalloc buffer can be initialized (no reports)\n"); in test_init_vmalloc()
497 "memcpy()ing aligned initialized src to aligned dst (no reports)\n"); in test_init_memcpy()
526 * aligned 4-byte values. This test case checks that KMSAN correctly reports an
[all …]
|
| /linux/arch/loongarch/ |
| H A D | Kconfig.debug | 13 traces. It scans the stack and reports every kernel text address it
14 finds. Some of the addresses it reports may be incorrect.
26 Some of the addresses it reports may be incorrect (but better than the
|
| /linux/tools/testing/selftests/hid/tests/ |
| H A D | base.py | 198 def debug_reports(cls, reports, uhdev=None, events=None): argument
199 data = [" ".join([f"{v:02x}" for v in r]) for r in reports]
204 for r in reports
216 reports = data
218 if len(reports) == 1:
221 print(f"sending {len(reports)} reports:")
222 for report in reports:
|
| /linux/drivers/hid/ |
| H A D | hid-gfrm.c | 63 * Convert GFRM100 Search key reports into Consumer.0221 (Key.Search) in gfrm_raw_event()
64 * reports. Ignore audio data. in gfrm_raw_event()
111 * key reports. Thus, we need to add it manually here, so that in gfrm_probe()
112 * those reports reach gfrm_raw_event() from hid_input_report(). in gfrm_probe()
|
| /linux/Documentation/dev-tools/ |
| H A D | kasan.rst | 96 To include alloc and free stack traces of affected slab objects into reports,
108 effectively disables ``panic_on_warn`` for KASAN reports.
142 only reports tag faults during these checks.
169 Error reports
278 Generic KASAN also reports up to two auxiliary call stack traces. These stack
368 dedicated ``brk`` handler is used to print bug reports.
402 Hardware Tag-Based KASAN only reports the first found bug. After that, MTE tag
478 Normally, KASAN detects and reports such accesses, but in some cases (e.g.,
503 For software KASAN modes, to disable KASAN reports in a part of the kernel code
506 disables the reports for indirect accesses that happen through function calls.
[all …]
|
| /linux/drivers/gpu/drm/i915/ |
| H A D | i915_perf.c | 75 * the constraints on HW configuration require reports to be filtered before it
114 * The OA unit writes reports of counters into a circular buffer, without
134 * feature and forwarded OA reports to userspace via perf's 'raw' sample
138 * them. For Mesa it's also convenient to be forwarded raw, periodic reports
139 * for combining with the side-band raw reports it captures using
169 * attach GPU timestamps to our OA samples. We were shoehorning OA reports
240 * Although this can be observed explicitly while copying reports to userspace
241 * by checking for a zeroed report-id field in tail reports, we want to account
245 * We workaround this issue in oa_buffer_check_unlocked() by reading the reports
261 * non-periodic reports (such as on context switch) or the OA unit may be
[all …]
|
| /linux/Documentation/userspace-api/media/rc/ |
| H A D | lirc-set-wideband-receiver.rst | 47 carrier reports. In that case it will be disabled as soon as you disable
48 carrier reports. Trying to disable wide band receiver while carrier
49 reports are active will do nothing.
|
| /linux/arch/arm64/boot/dts/rockchip/ |
| H A D | rk3588-jaguar-pre-ict-tester.dtso | 108 * soldering issue on GPIO3_B2 reports HIGH but proper
109 * soldering reports LOW.
125 * on GPIO3_C6 or VCC_1V8_S0_1 reports LOW but proper
126 * soldering reports HIGH.
|
| /linux/drivers/block/ |
| H A D | ps3vram.c | 77 void __iomem *reports; member
101 static u32 __iomem *ps3vram_get_notifier(void __iomem *reports, int notifier) in ps3vram_get_notifier() argument
103 return reports + DMA_NOTIFIER_OFFSET_BASE + in ps3vram_get_notifier()
110 u32 __iomem *notify = ps3vram_get_notifier(priv->reports, NOTIFIER); in ps3vram_notifier_reset()
121 u32 __iomem *notify = ps3vram_get_notifier(priv->reports, NOTIFIER); in ps3vram_notifier_wait()
700 priv->reports = ioremap(reports_lpar, reports_size); in ps3vram_probe()
701 if (!priv->reports) { in ps3vram_probe()
702 dev_err(&dev->core, "ioremap REPORTS failed\n"); in ps3vram_probe()
762 iounmap(priv->reports); in ps3vram_probe()
791 iounmap(priv->reports); in ps3vram_remove()
|
| /linux/tools/testing/selftests/net/rds/ |
| H A D | run.sh | 71 echo "INFO: CONFIG_GCOV_PROFILE_RDS should be enabled for coverage reports"
75 echo "INFO: CONFIG_GCOV_KERNEL should be enabled for coverage reports"
79 echo "INFO: CONFIG_GCOV_PROFILE_ALL should be disabled for coverage reports"
84 echo "To enable gcov reports, please run "\
|
| /linux/Documentation/trace/ |
| H A D | osnoise-tracer.rst | 22 interrupts and reports the max observed gap between the reads. It also
80 - The RUNTIME IN US reports the amount of time in microseconds that
82 - The NOISE IN US reports the sum of noise in microseconds observed
84 - The % OF CPU AVAILABLE reports the percentage of CPU available for
86 - The MAX SINGLE NOISE IN US reports the maximum single noise observed
|
| /linux/drivers/gpu/drm/i915/display/ |
| H A D | intel_tv_regs.h | 56 /* Read-only state that reports all features enabled */
58 /* Read-only state that reports that Macrovision is disabled in hardware*/
60 /* Read-only state that reports that TV-out is disabled in hardware. */
85 * Reports that DAC state change logic has reported change (RO).
91 /* Reports that DAC A voltage is above the detect threshold */
93 /* Reports that DAC B voltage is above the detect threshold */
95 /* Reports that DAC C voltage is above the detect threshold */
|
| /linux/Documentation/process/ |
| H A D | handling-regressions.rst | 24 * Forward or bounce any reports submitted in bug trackers to the list.
29 * For mailed reports, check if the reporter included a line like ``#regzbot
36 * When forwarding reports from a bug tracker to the regressions list (see
64 What to do when receiving regression reports
84 * For mailed reports, check if the reporter included a "regzbot command" like
125 both of these equivalently and considers the linked reports as resolved.
137 reports for regression with changes resolving them.
234 * When receiving reports about regressions in recent stable or longterm kernel
284 list about the risk, so everyone has the change on the radar in case reports
334 The bot watches for replies to reports of tracked regressions. Additionally,
[all …]
|