Searched full:probe (Results 1 – 25 of 248) sorted by relevance
12345678910
| /Documentation/trace/ |
| D | kprobes.rst | 16 6. Probe Overhead
38 any instruction in the kernel. A return probe fires when a specified
45 the probe is to be inserted and what handler is to be called when
46 the probe is hit.
87 Since kprobes can probe into a running kernel code, it can change the
107 How Does a Return Probe Work?
112 probe is hit, Kprobes saves a copy of the return address, and replaces
118 passes to the trampoline and that probe is hit. Kprobes' trampoline
138 zero when the return probe is registered, and is incremented every
140 object available for establishing the return probe.
[all …]
|
| D | tracepoints.rst | 10 connect probe functions to them and provides some examples of probe
16 A tracepoint placed in code provides a hook to call a function (probe)
17 that you can provide at runtime. A tracepoint can be "on" (a probe is
18 connected to it) or "off" (no probe is attached). When a tracepoint is
93 Connecting a function (probe) to a tracepoint is done by providing a
94 probe (function to call) for the specific tracepoint through
95 register_trace_subsys_eventname(). Removing a probe is done through
96 unregister_trace_subsys_eventname(); it will remove the probe.
100 the probe. This, and the fact that preemption is disabled around the
101 probe call, make sure that probe removal and module unload are safe.
[all …]
|
| D | kprobetrace.rst | 10 this is based on kprobes (kprobe and kretprobe). So it can probe wherever
11 kprobes can probe (this means, all functions except those with
19 current_tracer. Instead of that, add probe points via
31 p[:[GRP/][EVENT]] [MOD:]SYM[+offs]|MEMADDR [FETCHARGS] : Set a probe
32 r[MAXACTIVE][:[GRP/][EVENT]] [MOD:]SYM[+0] [FETCHARGS] : Set a return probe
33 p[:[GRP/][EVENT]] [MOD:]SYM[+0]%return [FETCHARGS] : Set a return probe
34 -:[GRP/][EVENT] : Clear a probe
40 SYM[+offs] : Symbol+offset where the probe is inserted.
42 MEMADDR : Address where the probe is inserted.
47 FETCHARGS : Arguments. Each probe can have up to 128 args.
[all …]
|
| D | uprobetracer.rst | 14 current_tracer. Instead of that, add probe points via
38 OFFSET : Offset where the probe is inserted.
39 OFFSET%return : Offset where the return probe is inserted.
41 FETCHARGS : Arguments. Each probe can have up to 128 args.
56 (\*1) only for return probe.
81 You can check the total number of probe hits per event via
83 the second is the event name, the third is the number of probe hits.
87 * Add a probe as a new uprobe event, write a new definition to uprobe_events
92 * Add a probe as a new uretprobe event::
109 at the probed text address. Probe zfree function in /bin/zsh::
[all …]
|
| D | fprobetrace.rst | 12 Fprobe event is similar to the kprobe event, but limited to probe on
16 This document also covers tracepoint probe events (tprobe) since this
21 As same as other dynamic events, fprobe events and tracepoint probe
28 f[:[GRP1/][EVENT1]] SYM [FETCHARGS] : Probe on function entry
29 f[MAXACTIVE][:[GRP1/][EVENT1]] SYM%return [FETCHARGS] : Probe on function exit
30 t[:[GRP2/][EVENT2]] TRACEPOINT [FETCHARGS] : Probe on tracepoint
43 FETCHARGS : Arguments. Each probe can have up to 128 args.
62 (\*2) only for the probe on function entry (offs == 0). Note, this argument access
65 (\*3) only for return probe. Note that this is also best effort. Depending on the
75 Function arguments can be accessed at exit probe using $arg<N> fetcharg. This
[all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-devices-waiting_for_supplier | 12 before the device can probe.
15 to be added before it can probe. A value of 1 means the device
17 probe.
|
| /Documentation/firmware-guide/acpi/ |
| D | non-d0-probe.rst | 19 probe. The support for _DSC requires support from the kernel bus type if the
20 bus driver normally sets the device in D0 state for probe.
24 first user will find out the device doesn't work, instead of a failure at probe
33 the device will not be powered on (put in D0 state) for probe.
59 System the device should remain powered off during probe looks like this. Some
|
| /Documentation/driver-api/usb/ |
| D | callbacks.rst | 17 - @probe:
73 The probe() callback
78 int (*probe) (struct usb_interface *intf,
146 No callbacks other than probe will be invoked for an interface
149 Probe will never be called for an interface bound to a driver.
150 Hence following a successful probe, disconnect will be called
151 before there is another probe for the same interface.
|
| D | hotplug.rst | 17 device driver's probe() routine.
133 .probe = my_probe,
146 choosing drivers to probe(). The thread doing new device processing checks
148 and device descriptors for the device. It will only call ``probe()`` if there
149 is a match, and the third argument to ``probe()`` will be the entry that
153 probed for each new device; the third parameter to ``probe()`` will be
|
| /Documentation/driver-api/driver-model/ |
| D | driver.rst | 35 .probe = eepro100_probe,
67 .probe = eepro100_probe,
149 int (*probe) (struct device *dev);
151 The probe() entry is called in task context, with the bus's rwsem locked
153 container_of() to convert "dev" to a bus-specific type, both in probe()
163 When the driver has successfully bound itself to that device, then probe()
167 A driver's probe() may return a negative errno value to indicate that
171 Optionally, probe() may return -EPROBE_DEFER if the driver depends on
174 deferred probe list and will try to call it again later. If a driver
180 -EPROBE_DEFER must not be returned if probe() has already created
[all …]
|
| D | platform.rst | 39 provide probe() and remove() methods. They support power management
43 int (*probe)(struct platform_device *);
54 Note that probe() should in general verify that the specified device hardware
63 the probe() routine can live in an init section to reduce the driver's
67 int (*probe)(struct platform_device *))
125 original IBM PCs, rely on error-prone "probe-the-hardware" models for hardware
172 driver probe() after finding a match between device and driver. If the
173 probe() succeeds, the driver and device are bound as usual. There are
239 6. Inside the early platform driver probe()
243 in the probe() function can use is_early_platform_device() to check if
|
| /Documentation/driver-api/ |
| D | device_link.rst | 19 another one can probe or function correctly.
57 device ``->probe`` callback or a boot-time PCI quirk.
61 ``->probe`` callback while the supplier hasn't started to probe yet: Had the
66 ``->probe`` callback while the supplier is still probing, but the consumer must
72 is added in the ``->probe`` callback of the supplier or consumer driver, it is
87 link is added from the consumer's ``->probe`` callback: ``DL_FLAG_RPM_ACTIVE``
91 probe or later unbinds.
93 Similarly, when the device link is added from supplier's ``->probe`` callback,
95 purged when the supplier fails to probe or later unbinds.
99 to probe for a driver for the consumer driver on the link automatically after
[all …]
|
| D | eisa.rst | 17 detection code is generally also used to probe ISA cards). Moreover,
38 implements the necessary callbacks to probe and release devices
60 int force_probe; /* Probe even when no slot 0 */
71 slots max slot number to probe
72 force_probe Probe even when slot 0 is empty (no EISA mainboard)
107 .probe and .remove members are mandatory.
122 .probe = vortex_eisa_probe,
130 The sysfs framework calls .probe and .remove functions upon device
197 Force the probing code to probe EISA slots even when it cannot find an
216 expect to have explored the whole machine when they exit their probe
|
| D | isa.rst | 11 finding their hardware due to a probe() error not being passed up
43 struct device_driver, the normal probe/remove/shutdown/suspend/resume
60 of the old .probe in .match, which would only keep them registered after
64 do everything in .probe() as before.
70 values have been passed in) and .probe() for everything else. This is
|
| /Documentation/i2c/ |
| D | old-module-parameters.rst | 12 control how the driver would probe I2C buses and attach to devices. These
13 parameters were known as ``probe`` (to let the driver probe for an extra
31 # modprobe <driver> probe=1,0x2d
|
| D | fault-codes.rst | 38 Also, codes returned by adapter probe methods follow rules which are
81 Returned by driver probe() methods. This is a bit more
86 about probe faults other than ENXIO and ENODEV.)
98 Returned by driver probe() methods to indicate that they
|
| D | writing-clients.rst | 49 .probe = foo_probe,
81 to NULL in remove() or if probe() failed anymore. The i2c-core does this
127 protocol to probe device presence. Another was that devices and their drivers
128 can be sufficiently configured using only such probe primitives.
149 kind of driver in Linux: they provide a probe() method to bind to
162 The probe function is called when an entry in the id_table name field
163 matches the device's name. If the probe function needs that entry, it
178 will take care of finding the right driver and will call its probe() method.
189 of possible I2C addresses to probe. A device is created for the first
|
| /Documentation/sound/soc/ |
| D | machine.rst | 21 int (*probe)(struct platform_device *pdev);
40 probe()/remove()
42 probe/remove are optional. Do any machine specific probe here.
|
| /Documentation/networking/ |
| D | mac80211-auth-assoc-deauth.txt | 30 alt no probe request data known
31 mac80211->driver: TX directed probe request
32 driver->mac80211: RX probe response
|
| /Documentation/devicetree/bindings/iio/adc/ |
| D | adi,ad7780.yaml | 46 specified, it will be asserted during driver probe. As the
54 driver probe. As the line is active low, it should be marked
62 during driver probe. As the line is active low, it should be
|
| /Documentation/devicetree/bindings/devfreq/event/ |
| D | samsung,exynos-nocp.yaml | 7 title: Samsung Exynos NoC (Network on Chip) Probe
14 The Samsung Exynos542x SoC has a NoC (Network on Chip) Probe for NoC bus.
|
| /Documentation/driver-api/fpga/ |
| D | fpga-region.rst | 40 An example of usage can be seen in the probe function of [#f2]_.
59 The FPGA region's probe function will need to get a reference to the FPGA
61 during the region's probe function.
69 the FPGA. The region driver can build a list of bridges during probe time
|
| /Documentation/driver-api/mei/ |
| D | mei-client-bus.rst | 38 int (*probe)(struct mei_cl_device *dev, const struct mei_cl_id *id);
98 .probe = contact_probe,
123 And the driver's simplified probe routine would look like that:
137 In the probe routine the driver first enable the MEI device and then registers
|
| /Documentation/devicetree/bindings/pinctrl/ |
| D | semtech,sx1501q.yaml | 42 semtech,probe-reset:
43 description: Will trigger a reset of the GPIO expander on probe
101 semtech,probe-reset: false
|
| /Documentation/admin-guide/blockdev/ |
| D | paride.rst | 120 All parports and all protocol drivers are probed automatically unless probe=0
133 mode mode number (protocol-specific) or -1 for probe
145 Probe all parports with all protocols::
149 Probe parport0 using protocol epat and mode 4 (EPP-16)::
153 Probe parport0 using all protocols::
157 Probe all parports using protoocol epat::
|
12345678910