Lines Matching refs:the
6 From the CAPI 2.0 specification:
15 requesting association with a CAPI device. Kernel CAPI then dispatches the
16 application registration to an available device, forwarding it to the
18 directions between the application and the hardware driver.
20 Format and semantics of CAPI messages are specified in the CAPI 2.0 standard.
26 CAPI drivers optionally register themselves with Kernel CAPI by calling the
28 capi_driver. This structure must be filled with the name and revision of the
30 registration can be revoked by calling the function unregister_capi_driver()
31 with a pointer to the same struct capi_driver.
33 CAPI drivers must register each of the ISDN devices they control with Kernel
34 CAPI by calling the Kernel CAPI function attach_capi_ctr() with a pointer to a
36 the names of the driver and controller, and a number of callback function
37 pointers which are subsequently used by Kernel CAPI for communicating with the
38 driver. The registration can be revoked by calling the function
39 detach_capi_ctr() with a pointer to the same struct capi_ctr.
41 Before the device can be actually used, the driver must fill in the device
42 information fields 'manu', 'version', 'profile' and 'serial' in the capi_ctr
43 structure of the device, and signal its readiness by calling capi_ctr_ready().
44 From then on, Kernel CAPI may call the registered callback functions for the
47 If the device becomes unusable for any reason (shutdown, disconnect ...), the
48 driver has to call capi_ctr_down(). This will prevent further calls to the
57 allocated by Kernel CAPI and passed to register_appl() along with the
58 parameter structure provided by the application. This is analogous to the
61 After a successful return from register_appl(), CAPI messages from the
62 application may be passed to the driver for the device via calls to the
63 send_message() callback function. Conversely, the driver may call Kernel
68 forwarded as calls to the release_appl() callback function, passing the same
70 messages for that application may be passed to or from the device anymore.
77 This structure describes a Kernel CAPI driver itself. It is used in the
79 the following non-private fields, all to be set by the driver before calling
83 the name of the driver, as a zero-terminated ASCII string
85 the revision number of the driver, as a zero-terminated ASCII string
93 driver. After registration via the attach_capi_ctr() function it is passed to
95 identify the controller to operate on.
97 It contains the following non-private fields:
99 - to be set by the driver before calling attach_capi_ctr():
102 pointer to the driver module owning the device
108 the name of the controller, as a zero-terminated ASCII string
111 the name of the driver, as a zero-terminated ASCII string
115 configuration data to the device
116 The function may return before the operation has completed.
122 (optional) pointer to a callback function for stopping the device,
124 The function may return before the operation has completed.
132 applications with the device
137 pointer to a callback function for sending a CAPI message to the
140 If the method returns 0 (CAPI_NOERROR) the driver has taken ownership
141 of the skb and the caller may no longer access it. If it returns a
142 non-zero (error) value then ownership of the skb returns to the caller
145 to accepting or queueing the message. Errors occurring during the
146 actual processing of the message should be signaled with an
153 pointer to a callback function returning the entry for the device in
154 the CAPI controller info table, /proc/capi/controller
157 pointers to callback functions for the device's proc file
158 system entry, /proc/capi/controllers/<n>; pointer to the device's
182 CAPI messages are passed between Kernel CAPI and the driver via send_message()
183 and capi_ctr_handle_message(), stored in the data portion of a socket buffer
184 (skb). Each skb contains a single CAPI message coded according to the CAPI 2.0
187 For the data transfer messages, DATA_B3_REQ and DATA_B3_IND, the actual
188 payload data immediately follows the CAPI message itself within the same skb.
190 parameter may be omitted by setting the length field of the CAPI message to 22
198 The _cmsg structure stores the contents of a CAPI 2.0 message in an easily
200 including subparameters of the Additional Info and B Protocol structured
201 parameters, with the following exceptions:
212 Only those parameters appearing in the message type currently being processed
215 Members are named after the CAPI 2.0 standard names of the parameters they
216 represent. See <linux/isdn/capiutil.h> for the exact spelling. Member data
226 The member is a pointer to a buffer containing the parameter in
229 Subparameters are stored in encoded form within the content part.
232 (used only for the 'Additional Info' and 'B Protocol' parameters)
233 The representation is a single byte containing one of the values:
236 Subparameter values are stored individually in the corresponding
240 messages between their transport encoding described in the CAPI 2.0 standard
242 not know or check the size of its destination buffer. The caller must make
243 sure it is big enough to accommodate the resulting CAPI message.
269 for forwarding to the specified application
309 Assembles a CAPI 2.0 message from the parameters in *cmsg, storing the
313 Disassembles the CAPI 2.0 message in *msg, storing the parameters in
318 Fills the header part and address field of the _cmsg structure *cmsg
319 with the given values, zeroing the remainder of the structure so only
321 the message.
324 Sets the low bit of the Subcommand field in *cmsg, thereby converting
328 Returns the CAPI 2.0 message name corresponding to the given command
330 be NULL if the command/subcommand is not one of those defined in the
337 debugging output produced by the module. It can only be set when the module is
338 loaded, via a parameter "showcapimsgs=<n>" to the modprobe command, either on
339 the command line or in the configuration file.
341 If the lowest bit of showcapimsgs is set, kernelcapi logs controller and
346 logged. The traceflag parameter is initialized with the value of the
347 showcapimsgs parameter when the controller is registered, but can later be
348 changed via the MANUFACTURER_REQ command KCAPI_CMD_TRACE.
350 If the value of traceflag is non-zero, CAPI messages are logged.
351 DATA_B3 messages are only logged if the value of traceflag is > 2.
353 If the lowest bit of traceflag is set, only the command/subcommand and message
355 the entire message.