Lines Matching defs:driver
58 * The perimeter is however held across a down call to the driver to make the
65 * changes in the mac layer and the call to the underlying driver to say add a
78 * call driver's mi_multicst
90 * obtained from a mac_open/mac_client_open. Similarly MAC driver means
92 * mac_register. An entity could be both client and driver but on different
94 * i.e. mac driver interface or mac client interface as appropriate for that
160 * the driver or via upcall pointers into layers above. The mac perimeter may
162 * a mi_* driver enty point to provide atomicity of the operation.
165 * mac driver interfaces, the MAC layer must provide a cut out for control
173 * R10. MAC driver interfaces must not block since the driver could call them
185 * sure that any pointers (such as mac ring pointers) it passes to the driver
189 * must not expose underlying driver rings or driver data structures/pointers
192 * MAC driver rules
200 * R15. MAC driver interfaces don't block and so the action may be done
202 * The driver must not assume that the action is complete when the call
210 * R17 Similarly mi_stop is another synchronization point and the driver must
214 * R18. The driver may assume that all set/modify control operations via
233 * client to driver. In the case of clients that explictly use the mac provided
273 * it is structured, and the path of an mblk_t between a driver and a mac
452 * leaves half of the 32-bit minors available for driver private use.
497 * Initialize a GLDv3 driver's device ops. A driver that manages its own ops
506 * By returning on error below, we are not letting the driver continue
825 * happens in mac_unregister and that implies the driver must make
1456 * used by the aggr driver to access and control the underlying HW Rx group
1457 * and rings. In this case, the aggr driver has exclusive control of the
1907 * from increasing. Upcalls from the driver that come through hardware
1910 * sure there aren't any upcall threads from the driver through hardware
1912 * classification rule in the driver.
2514 * don't do anything. In any case the mip has to be valid. The driver
2563 * driver's m_multicst entry point.
2581 * driver's m_promisc entry point.
2951 * plugin from unregistering while a MAC driver is attempting to
3152 * mac_set_prop() sets MAC or hardware driver properties:
3157 * itself and not passed down to the driver. For resource control
3164 * driver, such as MTU, through the driver's mc_setprop() entry point.
3223 /* For other driver properties, call driver's callback */
3233 * mac_get_prop() gets MAC or device driver properties.
3235 * If the property is a driver property, mac_get_prop() calls driver's callback
3342 /* If driver property, request from driver */
3379 * A property is read/write by default unless the driver says
3390 * involve the driver.
3493 * Get the property info from the driver if it implements the
3505 * this value until the driver returns from its
3507 * this number of range as the driver defines
3511 * were defined by the driver from its mc_propinfo()
3515 * the number of ranges specified by the driver on
3546 * ranges for properties if the driver does not provide a
3647 * illegal access to the ring structure coming from the driver will panic
3817 * ring index exchanged with the driver (e.g. during mr_rget)
3833 /* Query ring information from driver */
4004 /* Query group information from driver */
4088 /* Cache driver-supplied information */
4402 * movement is initiated by the framework), or specified through a driver
4403 * index (for example when the ring is added by the driver.
4442 * a driver to add a ring to an existing group, for example
4443 * from the aggregation driver. Allocate a new mac_ring_t
4453 * the underlying driver to support dynamic grouping,
4472 * Add the driver level hardware ring if the process was not
4473 * initiated by the driver, and the target group is not the
4827 * Remove the driver level hardware ring.
5225 * If driver advertises RINGS capability, it shouldn't have initialized
5869 * groups according to information gathered from the driver through
6195 * We need a better way for a driver to indicate this,
6506 * the rings from the driver, let's populate
6593 * the rings from the driver, let's populate
7065 * the rings from the driver, let's populate
7100 * driver, let's populate the property for the client now.
8052 * The driver set a flag that we don't know about. In this case,
8056 dev_err(mip->mi_dip, CE_WARN, "driver set transceiver "
8140 dev_err(mip->mi_dip, CE_PANIC, "driver wrote %lu bytes into "
8159 dev_err(mip->mi_dip, CE_WARN, "driver set led capability "
8167 dev_err(mip->mi_dip, CE_WARN, "driver set led capability "
8193 * the underlying driver at a time. As such, we end up multiplexing all
8194 * requested states and picking one to send down to the driver.
8200 mac_led_mode_t driver;
8218 * Catch both values that we don't know about and those that the driver
8234 * Based on the desired value, determine what to send to the driver. We
8235 * only will send a single bit to the driver at any given time. IDENT
8240 driver = MAC_LED_IDENT;
8242 driver = MAC_LED_OFF;
8244 driver = MAC_LED_ON;
8246 driver = MAC_LED_DEFAULT;
8249 if ((ret = mip->mi_led.mcl_set(mip->mi_driver, driver, 0)) == 0) {