MC_SETPROP(9E) | Driver Entry Points | MC_SETPROP(9E) |
mc_setprop
— set
device properties
#include
<sys/mac_provider.h>
int
prefix_m_setprop
(void *driver,
const char *pr_name, mac_prop_id_t
pr_num, uint_t pr_valsize, const
void *pr_val);
illumos DDI specific
The
mc_setprop
()
entry point is used to set the value of a given device's property from the
copy stored in pr_val.
When the
mc_setprop
()
entry point is called, the driver needs to first identify the property. The
set of possible properties and their meaning is listed in the
PROPERTIES
section of mac(9E). It should identify
the property based on the value of pr_num. Most
drivers will use a
switch
statement and for any property that it supports it should then check if the
value in pr_valsize is sufficient for the property,
comparing it to the minimum size listed for the property in
mac(9E). If it is not, then it should
return an error. Otherwise, it should update the property based on the value
in pr_val. When an unknown or unsupported property is
encountered, generally the
default
case of the switch statement, the device driver should return an error.
The special property MAC_PROP_PRIVATE indicates that this is a device driver specific private property. The device driver must then look at the value of the pr_name argument and use strcmp(9F) on it, comparing it to each of its private properties to identify which one it is.
Not all properties are supposed to be writable. Some devices may opt to not allow a property that is designated as read/write to be set. When such a property is encountered, the driver should return the appropriate error.
The device driver can access its device soft state by casting the device pointer to the appropriate structure. As this may be called while other operations are ongoing, the device driver should employ the appropriate locking while writing the properties.
Upon successful completion, the device driver should have copied the value of the property into pr_val and return 0. Otherwise, a positive error should be returned to indicate failure.
The following examples shows how a device driver might structure
its mc_setprop
() entry point.
#include <sys/mac_provider.h> /* * Note, this example merely shows the structure of this function. * Different devices will manage their state in different ways. Like other * examples, this assumes that the device has state in a structure called * example_t and that there is a lock which keeps track of that state. * * For the purpose of this example, we assume that this device supports 100 Mb, * 1 GB, and 10 Gb full duplex speeds. */ static int example_m_setprop(void *arg, const char *pr_name, mac_prop_id_t pr_num, uint_t pr_valsize, const void *pr_val) { uint32_t new_mtu; int ret = 0; example_t *ep = arg; mutex_enter(&ep->ep_lock); switch (pr_num) { /* * These represent properties that can never be changed, regardless of * the type of PHY on the device (copper, fiber, etc.) */ case MAC_PROP_DUPLEX: case MAC_PROP_SPEED: case MAC_PROP_STATUS: case MAC_PROP_ADV_100FDX_CAP: case MAC_PROP_ADV_1000FDX_CAP: case MAC_PROP_ADV_10GFDX_CAP: ret = ENOTSUP; break; /* * These EN properties are used to control the advertised speeds of the * device. For this example, we assume that this device does not have a * copper phy, at which point auto-negotiation and the speeds in * question cannot be changed. These are called out separately as they * should be controllable for copper based devices or it may need to be * conditional depending on the type of phy present. */ case MAC_PROP_EN_100FDX_CAP: case MAC_PROP_EN_1000FDX_CAP: case MAC_PROP_EN_10GFDX_CAP: case MAC_PROP_AUTONEG: ret = ENOTSUP; break; case MAC_PROP_MTU: if (pr_valsize < sizeof (uint32_t)) { ret = EOVERFLOW; break; } bcopy(&new_mtu, pr_val, sizeof (uint32_t)); if (new_mtu < ep->ep_min_mtu || new_mtu > ep->ep_max_mtu) { ret = EINVAL; break; } /* * We first ask MAC to update the MTU before we do anything. * This may fail. It returns zero on success. The * example_update_mtu function does device specific updates to * ensure that the MTU on the device is updated and any internal * data structures are up to date. */ ret = mac_maxdsu_update(&ep->ep_mac_hdl, new_mtu); if (ret == 0) { example_update_mtu(ep, new_mtu); } break; /* * Devices may have their own private properties. If they do, they * should not return ENOTSUP, but instead see if it's a property they * recognize and handle it similar to those above. If it doesn't * recognize the name, then it should return ENOTSUP. */ case MAC_PROP_PRIVATE: ret = ENOTSUP; break; default: ret = ENOTSUP; break; } mutex_exit(&ep->ep_lock); return (ret); }
The device driver may return one of the following errors. While this list is not intended to be exhaustive, it is recommended to use one of these if possible.
EINVAL
ENOTSUP
EOVERFLOW
EBUSY
ECANCELLED
February 15, 2020 | OmniOS |