Lines Matching full:via

87 implemented as platform devices, via |ssam_device| and |ssam_device_driver|
100 The packet transport layer is represented via |ssh_ptl| and is structured
109 Packets to be transmitted by the SSAM core are represented via |ssh_packet|
111 structure and are managed entirely via the raw |ssh_frame|).
117 lifetime (accessible via |ssh_packet_get| and |ssh_packet_put|). When this
118 counter reaches zero, the ``release()`` callback provided to the packet via
131 The state of a packet is managed via its ``state`` flags
161 this queue via |ssh_ptl_submit|. Note that this includes control packets
208 to the corresponding pending packet (via sequence ID) and completing it, as
216 Any payload data is forwarded via a callback to the next upper layer, i.e.
228 This timeout is handled via a dedicated reaper task, which is essentially a
291 The request transport layer is represented via |ssh_rtl| and builds on top
295 via a |ssh_command| payload. While responses are handled in this layer,
296 events are relayed to the next upper layer, i.e. the controller layer, via
311 reference counter inside the packet struct (which can be accessed via
316 Requests can have an optional response that is equally sent via a SSH
323 provided via its request ops reference and is guaranteed to be completed
325 layer via |ssh_rtl_submit|. For a request without a response, successful
330 via its request ID (which happens on the packet layer's data-received
335 The state of a request is again managed via its ``state`` flags
365 submitted to this queue via |ssh_rtl_submit|. Once submitted, requests may
407 being received by the underlying packet transport layer via a data-type
426 transport layer, handled via a dedicated reaper task. This task is
472 delivery and registration via the (event) completion system (|ssam_cplt|).
479 be the exception). This is done via an event-enable request (similarly,
480 events should be disabled via an event-disable request once no longer
483 The specific request used to enable (or disable) an event is given via an
504 controller has to manage access to these events. It does so via reference
511 the next section) via the top-level |ssam_notifier_register| and
517 To receive events, a client driver has to register an event notifier via
524 category (provided via the event ID; NB: there is a fixed known number of
528 from target category and instance ID given via the event ID.
534 target ID (provided via the event registry) and instance ID (provided via
539 completion workqueue. After an event has been received via the callback