All, I had a question about the expected behavior of m_getprop and m_setprop prior to plumbing an interface (and the corresponding m_start call).
Currently, I am initializing the PHY as a part of attach (re`re_init) and taking the interface out of loopback in m_start. This makes starting and stopping the interface very quick, and since the configuration is always static (the device predates MII so there is no autoneg behavior), there seems to be no harm in this approach. Question: Is it appropriate for the device to report its status even though the interface has not yet been plumbed? Most devices seem to report default values when an interface is unplumbed: [EMAIL PROTECTED]:/export/ws/driver-gate/re> dladm show-phys eri0 LINK MEDIA STATE SPEED DUPLEX DEVICE eri0 Ethernet unknown 0 unknown eri0 Versus: [EMAIL PROTECTED]:/export/ws/driver-gate/re> dladm show-phys re0 LINK MEDIA STATE SPEED DUPLEX DEVICE re0 Ethernet unknown 10 full re0 And: [EMAIL PROTECTED]:/export/ws/driver-gate/re> dladm show-linkprop re0 LINK PROPERTY VALUE DEFAULT POSSIBLE re0 speed 10 -- -- re0 autopush -- -- -- re0 zone -- -- -- re0 duplex full -- half,full re0 state unknown up up,down re0 adv_autoneg_cap ? 1 1,0 re0 mtu 1500 1500 -- re0 flowctrl bi bi no,tx,rx,bi re0 adv_1000fdx_cap ? -- 1,0 re0 en_1000fdx_cap ? -- 1,0 re0 adv_1000hdx_cap ? -- 1,0 re0 en_1000hdx_cap ? -- 1,0 re0 adv_100fdx_cap ? -- 1,0 re0 en_100fdx_cap ? -- 1,0 re0 adv_100hdx_cap ? -- 1,0 re0 en_100hdx_cap ? -- 1,0 re0 adv_10fdx_cap 1 1 1,0 re0 en_10fdx_cap 1 1 1,0 re0 adv_10hdx_cap 1 1 1,0 re0 en_10hdx_cap 1 1 1,0 If this not correct behavior, then it is going to be difficult to report accurate property values for the en_* and adv_* properties before the phy is initialized. Looking at existing drivers, this seems to be acceptable, however I wanted to verify this before I change my initialization so radically. TIA, Steve -- Yet magic and hierarchy arise from the same source, and this source has a null pointer. Reference the NULL within NULL, it is the gateway to all wizardry. _______________________________________________ driver-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/driver-discuss
