MC_SETPROP(9E) Driver Entry Points MC_SETPROP(9E)

mc_setpropset device properties

#include <sys/mac_provider.h>

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

A pointer to the driver's private data that was passed in via the member of the mac_register(9S) structure to the mac_register(9F) function.
A null-terminated string that contains the name of the property.
A constant that is used to identify the property.
A value that indicates the size in bytes of pr_val.
A pointer to a pr_valsize byte buffer that contains the new value of the property.

The () entry point is used to set the value of a given device's property from the copy stored in pr_val.

When the () entry point is called, the driver needs to first identify the property. The set of possible properties and their meaning is listed in the section of mac(9E). It should identify the property based on the value of pr_num. Most drivers will use a 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 case of the switch statement, the device driver should return an error.

The special property 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 . 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;

	switch (pr_num) {
	 * These represent properties that can never be changed, regardless of
	 * the type of PHY on the device (copper, fiber, etc.)
		ret = ENOTSUP;

	 * 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_1000FDX_CAP:
		ret = ENOTSUP;

		if (pr_valsize < sizeof (uint32_t)) {
			ret = EOVERFLOW;
		bcopy(&new_mtu, pr_val, sizeof (uint32_t));

		if (new_mtu < ep->ep_min_mtu ||
		    new_mtu > ep->ep_max_mtu) {
			ret = EINVAL;

		 * 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);

	 * 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.
		ret = ENOTSUP;

		ret = ENOTSUP;

	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.

The contents of pr_val are outside the valid range for the property.
This error should be used whenever an unknown or unsupported property is encountered. It should also be used when the property is not writable.
This error should be used when pr_valsize is smaller than the required size for a given value.
This error should be used when a property can't be set because the device has started. Note that device driver writers are encouraged to design device drivers such that this error is not possible.
The device is in a state that does not allow it to handle data; for example, it's suspended.

mac(9E), mac_register(9F), strcmp(9F), mac_register(9S)

February 15, 2020 OmniOS