From gd78059@sac.sfbay.sun.com Fri May 22 22:38:11 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4N5cA2O007533 for ; Fri, 22 May 2009 22:38:10 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4N5c8GX014970; Fri, 22 May 2009 23:38:10 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KK3007010YKBI00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 22 May 2009 22:37:32 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KK300B7C0YJ7B30@nwk-avmta-1.sfbay.Sun.COM>; Fri, 22 May 2009 22:37:31 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4N5bVVx008575; Fri, 22 May 2009 22:37:31 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4N5bUOh007528; Fri, 22 May 2009 22:37:30 -0700 (PDT) Received: (from gd78059@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n4N5bTHK007524; Fri, 22 May 2009 22:37:29 -0700 (PDT) Date: Fri, 22 May 2009 22:37:29 -0700 (PDT) From: "Garrett D'Amore - sun microsystems" Subject: MII & GMII Common Layer [PSARC/2009/319 FastTrack timeout 06/01/2009] To: PSARC-ext@sun.com Cc: brussels-dev@sun.com, sstallion@gmail.com Message-id: <200905230537.n4N5bTHK007524@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 16813 I'm sponsoring this on my own behalf. I think it qualifies for a fast track, but it might be pushing the limits. I won't be offended if a member decides otherwise and derails. :-) (Just don't expect *me* to derail it. :-) And to answer any questions: Yes, I do have a working prototype of this available. Check out http://cr.opensolaris.org/~gdamore/mii/ for code. Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: MII & GMII Common Layer 1.2. Name of Document Author/Supplier: Author: Garrett D'Amore 1.3 Date of This Document: 22 May, 2009 4. Technical Description MII & GMII proposal =================== Author: Garrett D'Amore Date: Fri May 22, 2009 FastTrack: MII & GMII Common Layer Release Binding: Minor OVERVIEW -------- We propose to provide a replacement for the legacy x86 only mii module that supports both SPARC and x86, and supports the various 10, 100, and 1000 base MII and GMII registers (see 802.3-2008 clauses 22, 28, and 37). 10G interfaces use a different management interface, which can support some of these same registers, but which is different in non-trivial ways, and therefore we do not intend at this time to support 10G interfaces. The new module should be able to support the existing MII consumers with modest change, plus all of the current 10/100/1000 drivers which support MII or GMII access to transceivers. Additionally, we want to have flexibility to support the various vendor specific hacks that are necessary with many transceivers. Support is also present (but untested) for 100Base-T2, 100Base-T4, and 1000Base-X links. The MII module will fully support Brussels (PSARC 2007/429) and GLDv3 statistics routines, but this support will only be available for GLDv3 based drivers. The MII module also supports PHY internal and external loopback modes, and the netlbtest SunVTS test, thus greatly expanding upon the set of devices supported by this test. COMMITMENT & BINDING -------------------- All of the interfaces detailed in this proposal are intended (at least initially) to be Consolidation Private. Once GLDv3 is given a public commitment, and once we have some more experience with these interfaces, it will probably be appropriate to raise their commitment level. We're seeking Minor binding at the moment, as we have concrete plans to backport this. We do believe that at some point in the future it may be useful to have this in an earlier release to facilitate backporting of certain other MAC drivers, but some significant modication will need to be made to replace the generic Brussels interfaces with interfaces more appropriate for Solaris 10 (i.e. ndd support.) (Unless Brussels itself is backported.) Hence, we feel that if a backport is desired, another case should be opened to address the issues associated with such. COMPATIBILITY ------------- As indicated, the new MII module should be able to support any reasonable MII consumers. However, some legacy consumers use semi-private legacy interface for MII. These drivers will need some small attention to make them work -- they are dnet, elxl, and iprb. I've already converted iprb (which gains a lot of new functionality as a result) and elxl (which does not, because it is still a GLDv2 driver). Fixing dnet might be more work than it is worth, in which case the legacy mii.c file and supporting headers will just be moved into a private dnet directory (and suitably renamed of course!) so that it can continue to operate with no risk. Note that drivers that are GLDv3 can benefit the most, but it is not strictly required that drivers be GLDv3 to use the MII module. (Although some of the APIs, such as those for aiding implementation of the mc_setprop and mc_getprop entry points, will be uselss in a driver that is not GLDv3 based.) We'll be breaking support for a few ancient hacks (which we think are no longer needed -- workarounds for errata for specific problems that we believe are no longer relevant), and some of the "device-specific" legacy properties for setting link parameters. (The drivers will now be able to use the uniform dladm interface to manage link settings.) API --- 1. Compilation Drivers access the new API by #include (and optionally also .) The driver will need to depend upon misc/mii using the LDFLAGS of -dy -Nmisc/mii 2. Entry Points. Drivers shall supply the following entry points: struct mii_ops { int mii_version; uint16_t mii_read(); void mii_write(); void mii_notify(); void mii_reset }; int mii_version; This should be assigned to the value MII_VERSION. It is intended to allow for future extensions to the ops structure. (When the structure grows, the version number will be incremented. More detail about how this will be accomplished will be specified when such extensions are necessary.) uint16_t mii_read(void *state, uint8_t phy_addr, uint8_t reg_num); Reads a register, and stores the 16-bit register value in valuep. Returns the value on success, or 0xffff on failure. Note that the register and phy addresses are constrained to values 0-31 per IEEE 802.3 clause 22. The state value is an opaque pointer to the mac driver's soft state. void mii_write(void *state, uint8_t phy_addr, uint8_t reg_num, uint16_t value); Writes the 16-bit value to the named phy and register. Returns 0 on success, or an errno on failure. void mii_notify(void *state, link_state_t state); When the MII module detects a change in the link state on the active PHY, it will call the link notification routine, which will allow the mac driver to do any required reprogramming. Note that the mac driver should call mac_link_update() as appropriate. 3. Functions For Drivers typedef struct mii_handle mii_handle_t; Opaque to drivers, a simple handle to reference the MII state. mii_handle_t *mii_alloc(void *private, dev_info_t*dip, mii_ops_t *ops); Allocate an MII handle. Called during driver's attach(9e) handling, this routine is valid in kernel context only. The "private" argument points to a driver private state structure, which will be passed back to the driver as the first argument to each of its entry points supplied in the ops entry point. The dip is the dev_info node for the MAC instance structure. On success a valid MII handle is returned, otherwise NULL may be returned. void mii_free(mii_handle_t *mii); Free an MII handle and associated resources. Call from detach(9e) handling, this routine is valid in kernel context only. void mii_set_instance(mii_handle_t *mii, uint_t instance); Sets the instance (PPA) of the MAC associated with the MII. Optional, but if called, must be done after mii_alloc(), and before the first time mii_start() is called. If not called, a default instance using ddi_get_instance() from the dev_info node was supplied to mii_alloc will be used. (This function is only needed for drivers that override the value of m_instance in the mac_register structure.) void mii_set_pauseable(mii_handle_t *mii, boolean_t cap, boolean_t asym); Lets the MII know if the MAC layer can support pause or asymetric pause capabilities. The MII layer will use this to determine what capabilities should be negotiated for (along with user preferences, of course.) If not called, the MII will assume the device has no support for flow control. void mii_start(mii_handle_t *mii); Starts monitoring of the MII bus. Normally this is called as a result of a driver's mac_start() entry point, but it may also be called when a PHY needs to be reset or during handling of DDI_RESUME. This function may be called in any context except high level interrupt, but must be called without any locks held. void mii_stop(mii_handle_t *mii); Stops monitoring of the MII bus. Normally this is called as a result of a driver's mac_stop() entry point, but may also be called during DDI_SUSPEND handling. As a side effect, also isolates and powers down any active PHY. On return, the MII layer is guaranteed not to be executing any code in the MII entry points. This function may be called in any context except high level interrupt, but must be called without any locks held. void mii_probe(mii_handle_t *mii); Used to reset the entire MII bus and probe for PHYs. This routine should be called if the driver has reason to believe that PHYs have changed. This is implicitly executed the first time monitoring is started on the MII bus, and normally need not be explicitly called. This function may only be called in any context except high level interrupt, but must be called without any locks held. void mii_check(mii_handle_t *mii); Used to alert the MII layer that it should check for changes. This can be called by drivers in response to link status interrupts, for example, giving a quicker response to link status changes without waiting for the MII timer to expire. This function may be called in any context except high level interrupt, but must be called without any locks held. int mii_get_addr(mii_handle_t *mii); Used to get the PHY address that is currently active for the MII bus. This function may be called in any context. The returned address will be a number 0 to 31 if a PHY is present and in use, or -1 otherwise. uint32_t mii_get_id(mii_handle_t *mii); Used to get the identifier of the active PHY. This function may be called in any context. The PHY identifier register contents, encoded with the high order (PHYIDH) bits in the upper word and the low order bits in the lower word are returned. If no PHY is active, the value -1 will be returned. Note that it is perfectly reasonable for a PHY to have no ID registers, in which case a value of either 0 or (uint32_t)-1 may be returned. int mii_get_speed(mii_handle_t *mii); Used to get the speed of the active PHY. This function may be called in any context. The returned value is the speed, in Mbps, if the active PHY has link (10, 100, or 1000), otherwise 0. link_duplex_t mii_get_duplex(mii_handle_t *mii); Used to get the duplex of the active PHY. This function may be called in any context. The returned value will be the duplex, if the active PHY has link (LINK_DUPLEX_FULL or LINK_DUPLEX_HALF), otherwise LINK_DUPLEX_UNKNOWN. link_state_t mii_get_state(mii_handle_t *mii); Used to get the state of the link on the active PHY. This function may be called in any context. The returned value indicates the link state, one of LINK_STATE_UP, LINK_STATE_DOWN, or LINK_STATE_UNKNOWN. link_flowctrl_t mii_get_flowctrl(mii_handle_t *mii); Used to get the state of the negotiated flow control on the active PHY. This function may be called in any context. Note that the name of returned value indicates the direction of the pause frame, not the direction of the flow. Hence, LINK_FLOWCTRL_RX indicates that the local station may receive pause frames (which ultimately should cause it to defer transmission), and LINK_FLOWCTRL_TX indicates that the local station may send pause frames when it is unable to process any further received packets. LINK_FLOWCTRL_BI indicates that pause frames may be sent either from or to the station, and LINK_FLOWCTRL_NONE means that no pause frames should be sent or handled specially. int mii_get_loopmodes(mii_handle_t *mii, lb_property_t *modes); #define MII_LOOPBACK_MAX 16 #define MII_LOOPBACK_NONE 0 This function is used to support the LB_GET_INFO_SIZE and LB_GET_INFO ioctls. It probably should not be used outside of that context. The modes supplied are supported by the MII/PHY. Drivers may wish to add modes for MAC internal loopbacks as well. See for more information. Note that the first item in the modes array will always be the mode to disable the MII/PHY loopback, and will have the value MII_LOOPBACK_NONE. The modes pointer may be NULL, to retrieve just the count of the number modes that would be returned, otherwise it must point to a location with enough room to hold all the modes. The return value indicates the number of loopback modes returned, which will in no case be more than MII_LOOPBACK_MAX. (Hence, drivers may use a scratch array with MII_LOOPBACK_MAX lb_property_t's in it without concern about overrunning the array.) int mii_set_loopback(mii_handle_t *mii, uint32_t mode); Sets the loopback mode, intended for use in support of the LB_SET_MODE ioctl. The mode value will be one of the values returned in the modes array (see mii_get_loopmodes), or the special value MII_LOOPBACK_NONE to return to normal operation. Returns zero on succes, or EINVAL if the requested mode is invalid or unsupported. uint32_t mii_get_loopback(mii_handle_t *mii); Queries the current loopback mode, intended for use in support of the LB_GET_MODE ioctl, but may be useful in programming device settings that are sensitive to loopback setting. boolean_t mii_m_loop_ioctl(mii_handle_t *mii, queue_t *wq, mblk_t *msg); Used to support the driver's mc_ioctl() for loopback ioctls. If the driver is going to use the loopback optons from the PHY, and isn't adding any MAC level loopback, then this function can handle the entire set of ioctls, further simplifying the MAC driver. Ultimately, this is a very reasonable thing to do, since the PHY level loopback should exercise all of the same MAC level circuitry that a MAC internal loopback would do. (Hence there should be little need to add support for a MAC level loopback.) The wq and msg are passed directly from the mc_ioctl entry point. Returns B_TRUE if the MII layer recognized and processed the ioctl, or B_FALSE otherwise. If B_TRUE is returned, the driver can simply terminate ioctl processing. If B_FALSE is returned, the driver will need to process and ack or nak the ioctl. int mii_m_getprop(mii_handle_t *mii, const char *name, mac_prop_id_t id, uint_t flags, uint_t sz, void *val, uint_t *perm); Used to support the driver's mc_getprop() mac callback, and only to be called from that function (and without any locks held). This routine will process all of the properties that are relevant to MII on behalf of the driver. The arguments (except for the mii handle) are exactly as for the GLDv3 mc_getprop() entry point. On success, it returns 0. If ENOTSUP is returned, the property wasn't one recognized by the MII, and the MAC driver can either process it or return ENOTSUP back to the GLDv3. If any other error is encountered, EINVAL is returned. int mii_m_setprop(mii_handle_t *mii, const char *name, mac_prop_id_t id, uint_t sz, const void *val); Used to support the driver's mc_setprop() mac callback, and only to be called from that function (and without any locks held). This routine will process all of the properties that are relevant to MII on behalf of the driver. This will often result in the PHY being reset. On success, it returns 0. If ENOTSUP is returned, the property wasn't one recognized by the MII, and the MAC driver can either process it or return ENOTSUP back to the GLDv3. If any other error is encountered, EINVAL is returned. int mii_m_getstat(mii_handle_t *mii, uint_t stat, uint64_t *val); Used to support the driver's mc_getstat() mac callback for statistic collection, and only to be called from that function (without any locks held). This routine will process all of the statistics that are relevant to MII on behalf of the driver. Returns 0 if the statistic was processed, or ENOTSUP if the MII does not recognize the statistic. 4. Functions for Phy Specific Overrides Some PHYs require vendor specific tweaks or adjustments. Rather than run separate drivers with different PHYs for each type, we are going to simply compile all the overrides into one binary. All of the interfaces between the vendor specific PHY modules and the MII core are hence Project Private and not covered here. (However, see the private miipriv.h header if interested in the details.) 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Darren.Reed@sun.com Tue May 26 01:27:20 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4Q8RKp2010596 for ; Tue, 26 May 2009 01:27:20 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4Q8RI8p013798; Tue, 26 May 2009 09:27:19 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KK800003STILA00@brm-avmta-1.central.sun.com>; Tue, 26 May 2009 02:27:18 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KK800F6ISTHF780@brm-avmta-1.central.sun.com>; Tue, 26 May 2009 02:27:18 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4Q8RHnX015537; Tue, 26 May 2009 08:27:17 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KK800K00SIIWR00@fe-emea-10.sun.com>; Tue, 26 May 2009 09:27:17 +0100 (BST) Received: from [129.157.18.122] ([unknown] [129.157.18.122]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KK800433ST20V20@fe-emea-10.sun.com>; Tue, 26 May 2009 09:27:02 +0100 (BST) Date: Tue, 26 May 2009 10:27:00 +0200 From: Darren Reed Subject: Re: MII & GMII Common Layer [PSARC/2009/319 FastTrack timeout 06/01/2009] In-reply-to: <200905230537.n4N5bTHK007524@sac.sfbay.sun.com> Sender: Darren.Reed@sun.com To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com, brussels-dev@sun.com, sstallion@gmail.com Message-id: <4A1BA7D4.8070605@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905230537.n4N5bTHK007524@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Status: RO Content-Length: 668 Garrett D'Amore - sun microsystems wrote: > ... > We're seeking Minor binding at the moment, as we have concrete plans > to backport this. If you have concrete plans to backport it, shouldn't you be asking for patch/micro? Or did you mean to say that you don't have concrete plans? I'm not exactly sure how relevant this is to the current case but it somehow seems important/relevant... Now that you've broken out the PHY code into specific files, is there any reason to not pursue an architecture that supports pluggable PHYs? Or if when MII comes back for a higher commitment level, is this something that we should be looking for and expecting then? Darren From carlsonj@phorcys.east.sun.com Tue May 26 04:27:54 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4QBRrrc010470 for ; Tue, 26 May 2009 04:27:53 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n4QBRiVq016838; Tue, 26 May 2009 19:27:52 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KK90060B16F8N00@nwk-avmta-2.sfbay.sun.com>; Tue, 26 May 2009 04:27:51 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KK9000QO16FLB50@nwk-avmta-2.sfbay.sun.com>; Tue, 26 May 2009 04:27:51 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4QBRne4049795; Tue, 26 May 2009 07:27:49 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4QBQmAE014300; Tue, 26 May 2009 07:26:48 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n4QBQmfI014297; Tue, 26 May 2009 07:26:48 -0400 (EDT) Date: Tue, 26 May 2009 07:26:48 -0400 From: James Carlson Subject: Re: MII & GMII Common Layer [PSARC/2009/319 FastTrack timeout 06/01/2009] In-reply-to: <200905230537.n4N5bTHK007524@sac.sfbay.sun.com> To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com, brussels-dev@sun.com, sstallion@gmail.com Message-id: <18971.53752.362421.215071@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905230537.n4N5bTHK007524@sac.sfbay.sun.com> Status: RO Content-Length: 3526 Garrett D'Amore - sun microsystems writes: > We're seeking Minor binding at the moment, as we have concrete plans > to backport this. We do believe that at some point in the future it As Darren noted, there's a 'not' missing somewhere. > struct mii_ops { > int mii_version; > uint16_t mii_read(); > void mii_write(); > void mii_notify(); > void mii_reset > }; Is mii_reset a function? It's not described. > uint16_t mii_read(void *state, uint8_t phy_addr, uint8_t reg_num); > > Reads a register, and stores the 16-bit register value in valuep. > Returns the value on success, or 0xffff on failure. Note that > the register and phy addresses are constrained to values 0-31 per > IEEE 802.3 clause 22. The state value is an opaque pointer to > the mac driver's soft state. It might be a good idea to return a value outside the 0-0xffff range for error. I'd use 'int' as the return type and -1 for error. > void mii_write(void *state, uint8_t phy_addr, uint8_t reg_num, uint16_t value); > > Writes the 16-bit value to the named phy and register. Returns 0 > on success, or an errno on failure. Was this supposed to be 'int' instead of 'void'? Or can't it fail? Missing from here are context details. Can any of these functions be called due to an interrupt (such as a timer) thread? Are any locks held? Are there restrictions on what functions the driver's callback can call? Could the driver's callback block? > mii_handle_t *mii_alloc(void *private, dev_info_t*dip, mii_ops_t *ops); > > Allocate an MII handle. Called during driver's attach(9e) > handling, this routine is valid in kernel context only. The > "private" argument points to a driver private state structure, > which will be passed back to the driver as the first argument to > each of its entry points supplied in the ops entry point. The dip > is the dev_info node for the MAC instance structure. On success a > valid MII handle is returned, otherwise NULL may be returned. You don't have to do it for a private interface, but having allocator and free functions for mii_ops_t will simplify updates in the future. Does the MII module make a copy of the 'ops' vector, or does it need to remain allocated for the time that the mii_handle_t is allocated? (Are you assuming that mii_ops_t is in static duration storage?) > void mii_set_instance(mii_handle_t *mii, uint_t instance); > > Sets the instance (PPA) of the MAC associated with the MII. > Optional, but if called, must be done after mii_alloc(), and > before the first time mii_start() is called. If not called, a > default instance using ddi_get_instance() from the dev_info node > was supplied to mii_alloc will be used. (This function is only > needed for drivers that override the value of m_instance in the > mac_register structure.) When would this be used? m_instance isn't often overridden, at least in the current code, and I don't see this function in the example code you provided. > active, the value -1 will be returned. Note that it is perfectly > reasonable for a PHY to have no ID registers, in which case a > value of either 0 or (uint32_t)-1 may be returned. Either is possible in that one case? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From gdamore@sun.com Tue May 26 08:31:45 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4QFViEg012667 for ; Tue, 26 May 2009 08:31:45 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4QFVd7W027891; Tue, 26 May 2009 16:31:43 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KK900J0FCGVRV00@brm-avmta-1.central.sun.com>; Tue, 26 May 2009 09:31:43 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KK900B6PCGU1X80@brm-avmta-1.central.sun.com>; Tue, 26 May 2009 09:31:42 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4QFVgNA006156; Tue, 26 May 2009 08:31:42 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KK900900BXEVS00@fe-sfbay-10.sun.com>; Tue, 26 May 2009 08:31:42 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KK9007ZMCGSZDB0@fe-sfbay-10.sun.com>; Tue, 26 May 2009 08:31:40 -0700 (PDT) Date: Tue, 26 May 2009 08:31:39 -0700 From: "Garrett D'Amore" Subject: Re: MII & GMII Common Layer [PSARC/2009/319 FastTrack timeout 06/01/2009] In-reply-to: <4A1BA7D4.8070605@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren Reed Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, brussels-dev@sun.com, sstallion@gmail.com Message-id: <4A1C0B5B.5020105@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905230537.n4N5bTHK007524@sac.sfbay.sun.com> <4A1BA7D4.8070605@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1728 Darren Reed wrote: > Garrett D'Amore - sun microsystems wrote: >> ... >> We're seeking Minor binding at the moment, as we have concrete plans >> to backport this. > > If you have concrete plans to backport it, shouldn't you be asking for > patch/micro? > > Or did you mean to say that you don't have concrete plans? Yes, I forgot to add the "no" in that statement. Sorry! > > I'm not exactly sure how relevant this is to the current case but it > somehow seems important/relevant... > > Now that you've broken out the PHY code into specific files, is there > any reason to not pursue an architecture that supports pluggable PHYs? > > Or if when MII comes back for a higher commitment level, is this > something that we should be looking for and expecting then? What do you mean by pluggable PHYs? Do you mean separate PHY-specific "drivers"? We could do this now, but I didn't think it was strictly necessary -- most PHYs are standard compliant so overrides are only necessary for PHYs that need extra help. Furthermore, there seems to be little innovation in this area at present, as all the real engineering work is happening for 10Gb XGMII type PHYs, which are not supported by this work. (Reading the 802.3 specs for 10G -- and also some other specs such as subscriber access ethernet -- it appears that a new MDIO architecture is needed for those interfaces. That will be a significant new effort, and probably should be handled as a different common module in the future. But not as part of this case.) As far as this case, I have no plan to raise the commitment level of the PHY interface. I *do* hope to raise the commitment level of the MAC interface to MI though. - Garrett > > Darren > From gdamore@sun.com Tue May 26 08:48:52 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4QFmqiY013207 for ; Tue, 26 May 2009 08:48:52 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4QFmoGV008312; Tue, 26 May 2009 08:48:52 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KK900K0DD9FIH00@nwk-avmta-2.sfbay.sun.com>; Tue, 26 May 2009 08:48:51 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KK900F5TD9EFB70@nwk-avmta-2.sfbay.sun.com>; Tue, 26 May 2009 08:48:50 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4QFmoTt008379; Tue, 26 May 2009 08:48:50 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KK900M00D995O00@fe-sfbay-10.sun.com>; Tue, 26 May 2009 08:48:50 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KK900LB9D9CA600@fe-sfbay-10.sun.com>; Tue, 26 May 2009 08:48:48 -0700 (PDT) Date: Tue, 26 May 2009 08:48:47 -0700 From: "Garrett D'Amore" Subject: Re: MII & GMII Common Layer [PSARC/2009/319 FastTrack timeout 06/01/2009] In-reply-to: <18971.53752.362421.215071@gargle.gargle.HOWL> Sender: Garrett.Damore@sun.com To: James Carlson Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, brussels-dev@sun.com, sstallion@gmail.com Message-id: <4A1C0F5F.5040901@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905230537.n4N5bTHK007524@sac.sfbay.sun.com> <18971.53752.362421.215071@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 6129 James Carlson wrote: > Garrett D'Amore - sun microsystems writes: > >> We're seeking Minor binding at the moment, as we have concrete plans >> to backport this. We do believe that at some point in the future it >> > > As Darren noted, there's a 'not' missing somewhere. > > >> struct mii_ops { >> int mii_version; >> uint16_t mii_read(); >> void mii_write(); >> void mii_notify(); >> void mii_reset >> }; >> > > Is mii_reset a function? It's not described. > Yes, sorry, I forgot to finish the structure apparently. mii_reset() is called *after* the PHY has been reset (i.e. after the BMCR reset bit has been toggled.) The point of this function is to allow MAC drivers which require additional related logic to hook on this. Most drivers shouldn't need it. afe needs it due to an "internal" PHY that needs some specific programming if a fiber type device is used. Actually, I consider the need for this function a bit of an architectural weakness -- its one of the reasons I'm not ready to raise the level of commitment for this yet. > >> uint16_t mii_read(void *state, uint8_t phy_addr, uint8_t reg_num); >> >> Reads a register, and stores the 16-bit register value in valuep. >> Returns the value on success, or 0xffff on failure. Note that >> the register and phy addresses are constrained to values 0-31 per >> IEEE 802.3 clause 22. The state value is an opaque pointer to >> the mac driver's soft state. >> > > It might be a good idea to return a value outside the 0-0xffff range > for error. I'd use 'int' as the return type and -1 for error. > I could do that. The problem is that usually an error is reported by the hardware as 0xffff. (E.g. if you try to read a register that is not present or a PHY that is not present.) So adding a different error return (-1) would add confusion. > >> void mii_write(void *state, uint8_t phy_addr, uint8_t reg_num, uint16_t value); >> >> Writes the 16-bit value to the named phy and register. Returns 0 >> on success, or an errno on failure. >> > > Was this supposed to be 'int' instead of 'void'? Or can't it fail? > For most hardware types, it can't fail. (There are some devices that have "shared" access to the MII bus where the MAC driver could time out waiting to grant direct access to the MII bus. Most drivers don't have or need that, though.) I believe the better solution to handling a failure here is through the use of FMA. That said, if a write failed, its almost certain that the MII reads would also be failing, with the situation that the MII would be left in a state of link failure -- so this would be reported via the normal link failure mechanism. So no return is given back to the caller -- the void is intentional. > Missing from here are context details. Can any of these functions be > called due to an interrupt (such as a timer) thread? Are any locks > held? Are there restrictions on what functions the driver's callback > can call? Could the driver's callback block? > Good point. The functions are called from a taskq, but the driver should not block. Internal MII locks are held. The framework guarantees for mii_notify() and mii_reset() that it is safe to callback into the framework. mii_read() and mii_write() must not call back into the framework, however. > >> mii_handle_t *mii_alloc(void *private, dev_info_t*dip, mii_ops_t *ops); >> >> Allocate an MII handle. Called during driver's attach(9e) >> handling, this routine is valid in kernel context only. The >> "private" argument points to a driver private state structure, >> which will be passed back to the driver as the first argument to >> each of its entry points supplied in the ops entry point. The dip >> is the dev_info node for the MAC instance structure. On success a >> valid MII handle is returned, otherwise NULL may be returned. >> > > You don't have to do it for a private interface, but having allocator > and free functions for mii_ops_t will simplify updates in the future. > Maybe. I am following more along the lines of dev_ops, where the ops structure is versioned, and can only grow. I believe this will be sufficient. I don't expect a lot of change in this interface. > Does the MII module make a copy of the 'ops' vector, or does it need > to remain allocated for the time that the mii_handle_t is allocated? > (Are you assuming that mii_ops_t is in static duration storage?) > I make a private copy in the mii_handle structure. > >> void mii_set_instance(mii_handle_t *mii, uint_t instance); >> >> Sets the instance (PPA) of the MAC associated with the MII. >> Optional, but if called, must be done after mii_alloc(), and >> before the first time mii_start() is called. If not called, a >> default instance using ddi_get_instance() from the dev_info node >> was supplied to mii_alloc will be used. (This function is only >> needed for drivers that override the value of m_instance in the >> mac_register structure.) >> > > When would this be used? m_instance isn't often overridden, at least > in the current code, and I don't see this function in the example code > you provided. > I've changed the code a bit since writing this. I've removed the function altogether, and added a new argument (instance) to mii_alloc(). This was done because I needed the instance number to formulate a unique name for the taskq that I create at allocation. The new signature of mii_alloc() is: mii_handle_t *mii_alloc(void *private, dev_info_t*dip, int instance, mii_ops_t *ops); Drivers that have PPA == ddi_get_instance() may just supply 0 for the instance. > >> active, the value -1 will be returned. Note that it is perfectly >> reasonable for a PHY to have no ID registers, in which case a >> value of either 0 or (uint32_t)-1 may be returned. >> > > Either is possible in that one case? > Yes. The hardware may return either value. (I've seen both cases.) -- Garrett From carlsonj@phorcys.east.sun.com Tue May 26 08:56:22 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4QFuMUa013718 for ; Tue, 26 May 2009 08:56:22 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4QFuEmd016360; Tue, 26 May 2009 08:56:21 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KK900E5JDLWPA00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 26 May 2009 08:56:20 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KK9005VCDLVPAA0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 26 May 2009 08:56:20 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4QFuGOp063649; Tue, 26 May 2009 11:56:16 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4QFtE2d015485; Tue, 26 May 2009 11:55:14 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n4QFtEsN015482; Tue, 26 May 2009 11:55:14 -0400 (EDT) Date: Tue, 26 May 2009 11:55:14 -0400 From: James Carlson Subject: Re: MII & GMII Common Layer [PSARC/2009/319 FastTrack timeout 06/01/2009] In-reply-to: <4A1C0F5F.5040901@sun.com> To: "Garrett D'Amore" Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, brussels-dev@sun.com, sstallion@gmail.com Message-id: <18972.4322.496047.83370@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905230537.n4N5bTHK007524@sac.sfbay.sun.com> <18971.53752.362421.215071@gargle.gargle.HOWL> <4A1C0F5F.5040901@sun.com> Status: RO Content-Length: 2852 Garrett D'Amore writes: > > It might be a good idea to return a value outside the 0-0xffff range > > for error. I'd use 'int' as the return type and -1 for error. > > > > I could do that. The problem is that usually an error is reported by > the hardware as 0xffff. (E.g. if you try to read a register that is not > present or a PHY that is not present.) So adding a different error > return (-1) would add confusion. Ah, ok. As long as none of the registers can ever legitimately have 0xffff in them, I guess it's ok. > >> void mii_write(void *state, uint8_t phy_addr, uint8_t reg_num, uint16_t value); > >> > >> Writes the 16-bit value to the named phy and register. Returns 0 > >> on success, or an errno on failure. > >> > > > > Was this supposed to be 'int' instead of 'void'? Or can't it fail? > > > > For most hardware types, it can't fail. (There are some devices that > have "shared" access to the MII bus where the MAC driver could time out > waiting to grant direct access to the MII bus. Most drivers don't have > or need that, though.) I believe the better solution to handling a > failure here is through the use of FMA. That said, if a write failed, > its almost certain that the MII reads would also be failing, with the > situation that the MII would be left in a state of link failure -- so > this would be reported via the normal link failure mechanism. So no > return is given back to the caller -- the void is intentional. The text says that it returns 0 or errno. :-> > > When would this be used? m_instance isn't often overridden, at least > > in the current code, and I don't see this function in the example code > > you provided. > > > > I've changed the code a bit since writing this. I've removed the > function altogether, and added a new argument (instance) to > mii_alloc(). This was done because I needed the instance number to > formulate a unique name for the taskq that I create at allocation. The > new signature of mii_alloc() is: > > mii_handle_t *mii_alloc(void *private, dev_info_t*dip, int instance, mii_ops_t *ops); OK. > Drivers that have PPA == ddi_get_instance() may just supply 0 for the > instance. So you can't override and specify (otherwise legal) instance 0? > >> active, the value -1 will be returned. Note that it is perfectly > >> reasonable for a PHY to have no ID registers, in which case a > >> value of either 0 or (uint32_t)-1 may be returned. > >> > > > > Either is possible in that one case? > > > > Yes. The hardware may return either value. (I've seen both cases.) "ick." -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From gdamore@sun.com Tue May 26 09:17:15 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4QGHFK5014520 for ; Tue, 26 May 2009 09:17:15 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4QGHE0g046509; Tue, 26 May 2009 10:17:14 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KK90000JEKQTS00@brm-avmta-1.central.sun.com>; Tue, 26 May 2009 10:17:14 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KK900BW1EKP1PB0@brm-avmta-1.central.sun.com>; Tue, 26 May 2009 10:17:13 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4QGHD6X004445; Tue, 26 May 2009 09:17:13 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KK900700E8KEG00@fe-sfbay-10.sun.com>; Tue, 26 May 2009 09:17:13 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KK900L29EK8A6C0@fe-sfbay-10.sun.com>; Tue, 26 May 2009 09:16:57 -0700 (PDT) Date: Tue, 26 May 2009 09:16:56 -0700 From: "Garrett D'Amore" Subject: Re: MII & GMII Common Layer [PSARC/2009/319 FastTrack timeout 06/01/2009] In-reply-to: <18972.4322.496047.83370@gargle.gargle.HOWL> Sender: Garrett.Damore@sun.com To: James Carlson Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, brussels-dev@sun.com, sstallion@gmail.com Message-id: <4A1C15F8.5090201@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905230537.n4N5bTHK007524@sac.sfbay.sun.com> <18971.53752.362421.215071@gargle.gargle.HOWL> <4A1C0F5F.5040901@sun.com> <18972.4322.496047.83370@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 3775 James Carlson wrote: > Garrett D'Amore writes: > >>> It might be a good idea to return a value outside the 0-0xffff range >>> for error. I'd use 'int' as the return type and -1 for error. >>> >>> >> I could do that. The problem is that usually an error is reported by >> the hardware as 0xffff. (E.g. if you try to read a register that is not >> present or a PHY that is not present.) So adding a different error >> return (-1) would add confusion. >> > > Ah, ok. As long as none of the registers can ever legitimately have > 0xffff in them, I guess it's ok. > Well, I suppose some register *could*, but I've yet to see it. The spec say that unimplemented registers should return this value. > >>>> void mii_write(void *state, uint8_t phy_addr, uint8_t reg_num, uint16_t value); >>>> >>>> Writes the 16-bit value to the named phy and register. Returns 0 >>>> on success, or an errno on failure. >>>> >>>> >>> Was this supposed to be 'int' instead of 'void'? Or can't it fail? >>> >>> >> For most hardware types, it can't fail. (There are some devices that >> have "shared" access to the MII bus where the MAC driver could time out >> waiting to grant direct access to the MII bus. Most drivers don't have >> or need that, though.) I believe the better solution to handling a >> failure here is through the use of FMA. That said, if a write failed, >> its almost certain that the MII reads would also be failing, with the >> situation that the MII would be left in a state of link failure -- so >> this would be reported via the normal link failure mechanism. So no >> return is given back to the caller -- the void is intentional. >> > > The text says that it returns 0 or errno. :-> > I guess I should fix the text then. :-) At one point I had a separate return, but it complicated things, and offered (from what I could see) no real value, so I removed it. > >>> When would this be used? m_instance isn't often overridden, at least >>> in the current code, and I don't see this function in the example code >>> you provided. >>> >>> >> I've changed the code a bit since writing this. I've removed the >> function altogether, and added a new argument (instance) to >> mii_alloc(). This was done because I needed the instance number to >> formulate a unique name for the taskq that I create at allocation. The >> new signature of mii_alloc() is: >> >> mii_handle_t *mii_alloc(void *private, dev_info_t*dip, int instance, mii_ops_t *ops); >> > > OK. > > >> Drivers that have PPA == ddi_get_instance() may just supply 0 for the >> instance. >> > > So you can't override and specify (otherwise legal) instance 0? > No. I've never seen a situation where this was desireable. Every case I've ever seen only has PPA zero when ddi_get_instance() is also zero. That said, I'm thinking that a better way to do this might be to use an allocator for the mac_ops as you originally suggested, and then supply an instance number there. Then I could initialize to -1 and thereby shield drivers from even knowing about this if they don't need it. The problem with that approach is that it adds additional complexity to the driver's attach routine, because it has to free the structure as well. Its probably worth it though. > >>>> active, the value -1 will be returned. Note that it is perfectly >>>> reasonable for a PHY to have no ID registers, in which case a >>>> value of either 0 or (uint32_t)-1 may be returned. >>>> >>>> >>> Either is possible in that one case? >>> >>> >> Yes. The hardware may return either value. (I've seen both cases.) >> > > "ick." > > Yeah. :-) - Garrett From carlsonj@phorcys.east.sun.com Tue May 26 09:26:52 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4QGQpw9015090 for ; Tue, 26 May 2009 09:26:51 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4QGQnBk001660; Tue, 26 May 2009 09:26:51 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KK900105F0QQT00@brm-avmta-1.central.sun.com>; Tue, 26 May 2009 10:26:50 -0600 (MDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KK900B4NF0Q1VA0@brm-avmta-1.central.sun.com>; Tue, 26 May 2009 10:26:50 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4QGQlH2016513; Tue, 26 May 2009 12:26:47 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4QGPjYP015658; Tue, 26 May 2009 12:25:45 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n4QGPjp5015655; Tue, 26 May 2009 12:25:45 -0400 (EDT) Date: Tue, 26 May 2009 12:25:45 -0400 From: James Carlson Subject: Re: MII & GMII Common Layer [PSARC/2009/319 FastTrack timeout 06/01/2009] In-reply-to: <4A1C15F8.5090201@sun.com> To: "Garrett D'Amore" Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, brussels-dev@sun.com, sstallion@gmail.com Message-id: <18972.6153.600870.999505@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905230537.n4N5bTHK007524@sac.sfbay.sun.com> <18971.53752.362421.215071@gargle.gargle.HOWL> <4A1C0F5F.5040901@sun.com> <18972.4322.496047.83370@gargle.gargle.HOWL> <4A1C15F8.5090201@sun.com> Status: RO Content-Length: 1500 Garrett D'Amore writes: > James Carlson wrote: > > Ah, ok. As long as none of the registers can ever legitimately have > > 0xffff in them, I guess it's ok. > > > > Well, I suppose some register *could*, but I've yet to see it. The spec > say that unimplemented registers should return this value. Good point; that does it. > >> Drivers that have PPA == ddi_get_instance() may just supply 0 for the > >> instance. > >> > > > > So you can't override and specify (otherwise legal) instance 0? > > > > No. I've never seen a situation where this was desireable. Every case > I've ever seen only has PPA zero when ddi_get_instance() is also zero. That's weird, but ok ... > That said, I'm thinking that a better way to do this might be to use an > allocator for the mac_ops as you originally suggested, and then supply > an instance number there. Then I could initialize to -1 and thereby > shield drivers from even knowing about this if they don't need it. Yep; that's a possibility. > The problem with that approach is that it adds additional complexity to > the driver's attach routine, because it has to free the structure as well. > > Its probably worth it though. Yes, that part's a little annoying. Fortunately, we do it in many places now. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From gdamore@sun.com Tue May 26 13:06:11 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4QK6Ae4021134 for ; Tue, 26 May 2009 13:06:11 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n4QK69xu026519; Wed, 27 May 2009 04:06:10 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KK900B1JP68D400@nwk-avmta-2.sfbay.sun.com>; Tue, 26 May 2009 13:06:08 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KK9002TFP67RQB0@nwk-avmta-2.sfbay.sun.com>; Tue, 26 May 2009 13:06:07 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4QK67bh016750; Tue, 26 May 2009 13:06:07 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KK900600OZ3EU00@fe-sfbay-09.sun.com>; Tue, 26 May 2009 13:06:07 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KK900G29P661N60@fe-sfbay-09.sun.com>; Tue, 26 May 2009 13:06:06 -0700 (PDT) Date: Tue, 26 May 2009 13:06:06 -0700 From: "Garrett D'Amore" Subject: Re: MII & GMII Common Layer [PSARC/2009/319 FastTrack timeout 06/01/2009] In-reply-to: <18972.6153.600870.999505@gargle.gargle.HOWL> Sender: Garrett.Damore@sun.com To: James Carlson Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, brussels-dev@sun.com, sstallion@gmail.com Message-id: <4A1C4BAE.6010801@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905230537.n4N5bTHK007524@sac.sfbay.sun.com> <18971.53752.362421.215071@gargle.gargle.HOWL> <4A1C0F5F.5040901@sun.com> <18972.4322.496047.83370@gargle.gargle.HOWL> <4A1C15F8.5090201@sun.com> <18972.6153.600870.999505@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1687 James Carlson wrote: > >>>> Drivers that have PPA == ddi_get_instance() may just supply 0 for the >>>> instance. >>>> >>>> >>> So you can't override and specify (otherwise legal) instance 0? >>> >>> >> No. I've never seen a situation where this was desireable. Every case >> I've ever seen only has PPA zero when ddi_get_instance() is also zero. >> So, I've been thinking about this some more. I believe that have a seperate allocation routine -- e.g. mac_ops_alloc() -- is probably not warranted. There are five possible ways -- all of which are significantly simpler -- to solve this -- I'm open to suggestions: 1) Leave it as I've specified it. In all likelihood this will be good enough for all foreseeable devices, even if there is the *theoretical* possibility of a device for which this is inconvenient. 2) Change the 0 to -1. I.e. supply -1 if you want the framework to use ddi_get_instance(). This will work, it just "looks funny", at least to me. 3) Remove the "implicit" semantic altogether, and make drivers supply their PPA explicitly. 4) Add a flags field to the ops vector which specifies that an instance override is in use. This seems ugly to me, though. 5) Add a separate function, mii_alloc_instance() that takes the instance number, and remove the explicit instance number from mii_alloc()'s signature. So you have mii_handle_t mii_alloc(void *prv, dev_info_t *dip, mii_ops_t *ops) { return (mii_alloc_instance(prv, dip, ddi_get_instance(dip), ops); } Frankly, this last approach seems the cleanest to me. Any strong opinions one way or the other? - Garrett From carlsonj@phorcys.east.sun.com Tue May 26 13:13:35 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4QKDXrc021342 for ; Tue, 26 May 2009 13:13:33 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4QKDUVZ008255; Tue, 26 May 2009 21:13:31 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KK900B31PIIS300@nwk-avmta-2.sfbay.sun.com>; Tue, 26 May 2009 13:13:30 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KK9002FJPIHRPB0@nwk-avmta-2.sfbay.sun.com>; Tue, 26 May 2009 13:13:30 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4QKDRGF026514; Tue, 26 May 2009 16:13:27 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4QKCPVh016701; Tue, 26 May 2009 16:12:25 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n4QKCPSY016694; Tue, 26 May 2009 16:12:25 -0400 (EDT) Date: Tue, 26 May 2009 16:12:10 -0400 From: James Carlson Subject: Re: MII & GMII Common Layer [PSARC/2009/319 FastTrack timeout 06/01/2009] In-reply-to: <4A1C4BAE.6010801@sun.com> To: "Garrett D'Amore" Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, brussels-dev@sun.com, sstallion@gmail.com Message-id: <18972.19738.763276.971136@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905230537.n4N5bTHK007524@sac.sfbay.sun.com> <18971.53752.362421.215071@gargle.gargle.HOWL> <4A1C0F5F.5040901@sun.com> <18972.4322.496047.83370@gargle.gargle.HOWL> <4A1C15F8.5090201@sun.com> <18972.6153.600870.999505@gargle.gargle.HOWL> <4A1C4BAE.6010801@sun.com> Status: RO Content-Length: 486 Garrett D'Amore writes: > Frankly, this last approach seems the cleanest to me. > > Any strong opinions one way or the other? I like the -1 answer, but the two-functions approach works fine as well. I don't think either really has architectural implications. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From gdamore@sun.com Tue May 26 22:25:38 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4R5PcZO025505 for ; Tue, 26 May 2009 22:25:38 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4R5PbHo050479; Tue, 26 May 2009 23:25:38 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKA00E0ZF2PNX00@brm-avmta-1.central.sun.com>; Tue, 26 May 2009 23:25:37 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKA0021RF2OD050@brm-avmta-1.central.sun.com>; Tue, 26 May 2009 23:25:37 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4R5PaPP002164; Tue, 26 May 2009 22:25:36 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKA00900EZYQQ00@fe-sfbay-10.sun.com>; Tue, 26 May 2009 22:25:36 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKA002XQF2NJ5A0@fe-sfbay-10.sun.com>; Tue, 26 May 2009 22:25:36 -0700 (PDT) Date: Tue, 26 May 2009 22:25:35 -0700 From: "Garrett D'Amore" Subject: Re: MII & GMII Common Layer [PSARC/2009/319 FastTrack timeout 06/01/2009] In-reply-to: <18972.19738.763276.971136@gargle.gargle.HOWL> Sender: Garrett.Damore@sun.com To: James Carlson Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, brussels-dev@sun.com, sstallion@gmail.com Message-id: <4A1CCECF.7070002@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905230537.n4N5bTHK007524@sac.sfbay.sun.com> <18971.53752.362421.215071@gargle.gargle.HOWL> <4A1C0F5F.5040901@sun.com> <18972.4322.496047.83370@gargle.gargle.HOWL> <4A1C15F8.5090201@sun.com> <18972.6153.600870.999505@gargle.gargle.HOWL> <4A1C4BAE.6010801@sun.com> <18972.19738.763276.971136@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 16457 James Carlson wrote: > Garrett D'Amore writes: > >> Frankly, this last approach seems the cleanest to me. >> >> Any strong opinions one way or the other? >> > > I like the -1 answer, but the two-functions approach works fine as > well. I don't think either really has architectural implications. > > Okay, I'm taking the two-functions approach. The following is the revised specification, which addresses all of the issues that you've pointed out so far (I hope). MII & GMII proposal =================== Author: Garrett D'Amore Date: Tue May 26, 2009 FastTrack: MII & GMII Common Layer Release Binding: Minor OVERVIEW -------- We propose to provide a replacement for the legacy x86 only mii module that supports both SPARC and x86, and supports the various 10, 100, and 1000 base MII and GMII registers (see 802.3-2008 clauses 22, 28, and 37). 10G interfaces use a different management interface, which can support some of these same registers, but which is different in non-trivial ways, and therefore we do not intend at this time to support 10G interfaces. The new module should be able to support the existing MII consumers with modest change, plus all of the current 10/100/1000 drivers which support MII or GMII access to transceivers. Additionally, we want to have flexibility to support the various vendor specific hacks that are necessary with many transceivers. Support is also present (but untested) for 100Base-T2, 100Base-T4, and 1000Base-X links. The MII module will fully support Brussels (PSARC 2007/429) and GLDv3 statistics routines, but this support will only be available for GLDv3 based drivers. The MII module also supports PHY internal and external loopback modes, and the netlbtest SunVTS test, thus greatly expanding upon the set of devices supported by this test. COMMITMENT & BINDING -------------------- All of the interfaces detailed in this proposal are intended (at least initially) to be Consolidation Private. Once GLDv3 is given a public commitment, and once we have some more experience with these interfaces, it will probably be appropriate to raise their commitment level. We're seeking Minor binding at the moment, as we have concrete plans to backport this. We do believe that at some point in the future it may be useful to have this in an earlier release to facilitate backporting of certain other MAC drivers, but some significant modication will need to be made to replace the generic Brussels interfaces with interfaces more appropriate for Solaris 10 (i.e. ndd support.) (Unless Brussels itself is backported.) Hence, we feel that if a backport is desired, another case should be opened to address the issues associated with such. COMPATIBILITY ------------- As indicated, the new MII module should be able to support any reasonable MII consumers. However, some legacy consumers use semi-private legacy interface for MII. These drivers will need some small attention to make them work -- they are dnet, elxl, and iprb. I've already converted iprb (which gains a lot of new functionality as a result) and elxl (which does not, because it is still a GLDv2 driver). Fixing dnet might be more work than it is worth, in which case the legacy mii.c file and supporting headers will just be moved into a private dnet directory (and suitably renamed of course!) so that it can continue to operate with no risk. Note that drivers that are GLDv3 can benefit the most, but it is not strictly required that drivers be GLDv3 to use the MII module. (Although some of the APIs, such as those for aiding implementation of the mc_setprop and mc_getprop entry points, will be uselss in a driver that is not GLDv3 based.) We'll be breaking support for a few ancient hacks (which we think are no longer needed -- workarounds for errata for specific problems that we believe are no longer relevant), and some of the "device-specific" legacy properties for setting link parameters. (The drivers will now be able to use the uniform dladm interface to manage link settings.) API --- 1. Compilation Drivers access the new API by #include (and optionally also .) The driver will need to depend upon misc/mii using the LDFLAGS of -dy -Nmisc/mii 2. Entry Points. Drivers shall supply the following entry points: struct mii_ops { int mii_version; uint16_t mii_read(); void mii_write(); void mii_notify(); void mii_reset(); }; int mii_version; This should be assigned to the value MII_VERSION. It is intended to allow for future extensions to the ops structure. (When the structure grows, the version number will be incremented. More detail about how this will be accomplished will be specified when such extensions are necessary.) uint16_t mii_read(void *state, uint8_t phy_addr, uint8_t reg_num); Reads a register, and stores the 16-bit register value in valuep. Returns the value on success, or 0xffff on failure. Note that the register and phy addresses are constrained to values 0-31 per IEEE 802.3 clause 22. The state value is an opaque pointer to the mac driver's soft state. Must adhere to the same restrictions as for soft interrupt handlers. Additionally, drivers may not call back into the MII framework, as the MII framework may hold locks when this is called. void mii_write(void *state, uint8_t phy_addr, uint8_t reg_num, uint16_t value); Writes the 16-bit value to the named phy and register. Must adhere to the same restrictions as for soft interrupt handlers. Additionally, drivers may not call back into the MII framework, as the MII framework may hold locks when this is called. void mii_notify(void *state, link_state_t state); When the MII module detects a change in the link state on the active PHY, it will call the link notification routine, which will allow the mac driver to do any required reprogramming. Note that the mac driver should call mac_link_update() as appropriate. Must adhere to the same restrictions as for soft interrupt handlers. The function may safely call back into the MII framework. void mii_reset(void *state); This optional function is called after the MII module resets the PHY, in order to give the MAC driver the opportunity to perform any specific programming which must be done after reset. Most drivers should just set this field to NULL. Must adhere to the same restrictions as for soft interrupt handlers. The function may safely call back into the MII framework. 3. Functions For Drivers typedef struct mii_handle mii_handle_t; Opaque to drivers, a simple handle to reference the MII state. mii_handle_t *mii_alloc(void *private, dev_info_t *dip, mii_ops_t *ops); Allocate an MII handle. Called during driver's attach(9e) handling, this routine is valid in kernel context only. The "private" argument points to a driver private state structure, which will be passed back to the driver as the first argument to each of its entry points supplied in the ops entry point. The dip is the dev_info node for the MAC instance structure. On success a valid MII handle is returned, otherwise NULL may be returned. mii_handle_t *mii_alloc_instance(void *private, dev_info_t *dip, int instance, mii_ops_t *ops); Allocate an MII handle, but provide an override for the default instance assumed by mii_alloc(). This is used by drivers which override the PPA in mac->m_instance or gld->gldm_ppa to something other than the value returned by ddi_get_instance(). In all other respects behaves identically to mii_alloc(). void mii_free(mii_handle_t *mii); Free an MII handle and associated resources. Call from detach(9e) handling, this routine is valid in kernel context only. void mii_set_pauseable(mii_handle_t *mii, boolean_t cap, boolean_t asym); Lets the MII know if the MAC layer can support pause or asymetric pause capabilities. The MII layer will use this to determine what capabilities should be negotiated for (along with user preferences, of course.) If not called, the MII will assume the device has no support for flow control. void mii_start(mii_handle_t *mii); Starts monitoring of the MII bus. Normally this is called as a result of a driver's mac_start() entry point, but it may also be called when a PHY needs to be reset or during handling of DDI_RESUME. This function may be called in any context except high level interrupt, but must be called without any locks held. void mii_stop(mii_handle_t *mii); Stops monitoring of the MII bus. Normally this is called as a result of a driver's mac_stop() entry point, but may also be called during DDI_SUSPEND handling. As a side effect, also isolates and powers down any active PHY. On return, the MII layer is guaranteed not to be executing any code in the MII entry points. This function may be called in any context except high level interrupt, but must be called without any locks held. void mii_probe(mii_handle_t *mii); Used to reset the entire MII bus and probe for PHYs. This routine should be called if the driver has reason to believe that PHYs have changed. This is implicitly executed the first time monitoring is started on the MII bus, and normally need not be explicitly called. This function may only be called in any context except high level interrupt, but must be called without any locks held. void mii_check(mii_handle_t *mii); Used to alert the MII layer that it should check for changes. This can be called by drivers in response to link status interrupts, for example, giving a quicker response to link status changes without waiting for the MII timer to expire. This function may be called in any context except high level interrupt, but must be called without any locks held. int mii_get_addr(mii_handle_t *mii); Used to get the PHY address that is currently active for the MII bus. This function may be called in any context. The returned address will be a number 0 to 31 if a PHY is present and in use, or -1 otherwise. uint32_t mii_get_id(mii_handle_t *mii); Used to get the identifier of the active PHY. This function may be called in any context. The PHY identifier register contents, encoded with the high order (PHYIDH) bits in the upper word and the low order bits in the lower word are returned. If no PHY is active, the value -1 will be returned. Note that it is perfectly reasonable for a PHY to have no ID registers, in which case a value of either 0 or (uint32_t)-1 may be returned. int mii_get_speed(mii_handle_t *mii); Used to get the speed of the active PHY. This function may be called in any context. The returned value is the speed, in Mbps, if the active PHY has link (10, 100, or 1000), otherwise 0. link_duplex_t mii_get_duplex(mii_handle_t *mii); Used to get the duplex of the active PHY. This function may be called in any context. The returned value will be the duplex, if the active PHY has link (LINK_DUPLEX_FULL or LINK_DUPLEX_HALF), otherwise LINK_DUPLEX_UNKNOWN. link_state_t mii_get_state(mii_handle_t *mii); Used to get the state of the link on the active PHY. This function may be called in any context. The returned value indicates the link state, one of LINK_STATE_UP, LINK_STATE_DOWN, or LINK_STATE_UNKNOWN. link_flowctrl_t mii_get_flowctrl(mii_handle_t *mii); Used to get the state of the negotiated flow control on the active PHY. This function may be called in any context. Note that the name of returned value indicates the direction of the pause frame, not the direction of the flow. Hence, LINK_FLOWCTRL_RX indicates that the local station may receive pause frames (which ultimately should cause it to defer transmission), and LINK_FLOWCTRL_TX indicates that the local station may send pause frames when it is unable to process any further received packets. LINK_FLOWCTRL_BI indicates that pause frames may be sent either from or to the station, and LINK_FLOWCTRL_NONE means that no pause frames should be sent or handled specially. int mii_get_loopmodes(mii_handle_t *mii, lb_property_t *modes); #define MII_LOOPBACK_MAX 16 #define MII_LOOPBACK_NONE 0 This function is used to support the LB_GET_INFO_SIZE and LB_GET_INFO ioctls. It probably should not be used outside of that context. The modes supplied are supported by the MII/PHY. Drivers may wish to add modes for MAC internal loopbacks as well. See for more information. Note that the first item in the modes array will always be the mode to disable the MII/PHY loopback, and will have the value MII_LOOPBACK_NONE. The modes pointer may be NULL, to retrieve just the count of the number modes that would be returned, otherwise it must point to a location with enough room to hold all the modes. The return value indicates the number of loopback modes returned, which will in no case be more than MII_LOOPBACK_MAX. (Hence, drivers may use a scratch array with MII_LOOPBACK_MAX lb_property_t's in it without concern about overrunning the array.) int mii_set_loopback(mii_handle_t *mii, uint32_t mode); Sets the loopback mode, intended for use in support of the LB_SET_MODE ioctl. The mode value will be one of the values returned in the modes array (see mii_get_loopmodes), or the special value MII_LOOPBACK_NONE to return to normal operation. Returns zero on succes, or EINVAL if the requested mode is invalid or unsupported. uint32_t mii_get_loopback(mii_handle_t *mii); Queries the current loopback mode, intended for use in support of the LB_GET_MODE ioctl, but may be useful in programming device settings that are sensitive to loopback setting. boolean_t mii_m_loop_ioctl(mii_handle_t *mii, queue_t *wq, mblk_t *msg); Used to support the driver's mc_ioctl() for loopback ioctls. If the driver is going to use the loopback optons from the PHY, and isn't adding any MAC level loopback, then this function can handle the entire set of ioctls, further simplifying the MAC driver. Ultimately, this is a very reasonable thing to do, since the PHY level loopback should exercise all of the same MAC level circuitry that a MAC internal loopback would do. (Hence there should be little need to add support for a MAC level loopback.) The wq and msg are passed directly from the mc_ioctl entry point. Returns B_TRUE if the MII layer recognized and processed the ioctl, or B_FALSE otherwise. If B_TRUE is returned, the driver can simply terminate ioctl processing. If B_FALSE is returned, the driver will need to process and ack or nak the ioctl. int mii_m_getprop(mii_handle_t *mii, const char *name, mac_prop_id_t id, uint_t flags, uint_t sz, void *val, uint_t *perm); Used to support the driver's mc_getprop() mac callback, and only to be called from that function (and without any locks held). This routine will process all of the properties that are relevant to MII on behalf of the driver. The arguments (except for the mii handle) are exactly as for the GLDv3 mc_getprop() entry point. On success, it returns 0. If ENOTSUP is returned, the property wasn't one recognized by the MII, and the MAC driver can either process it or return ENOTSUP back to the GLDv3. If any other error is encountered, EINVAL is returned. int mii_m_setprop(mii_handle_t *mii, const char *name, mac_prop_id_t id, uint_t sz, const void *val); Used to support the driver's mc_setprop() mac callback, and only to be called from that function (and without any locks held). This routine will process all of the properties that are relevant to MII on behalf of the driver. This will often result in the PHY being reset. On success, it returns 0. If ENOTSUP is returned, the property wasn't one recognized by the MII, and the MAC driver can either process it or return ENOTSUP back to the GLDv3. If any other error is encountered, EINVAL is returned. int mii_m_getstat(mii_handle_t *mii, uint_t stat, uint64_t *val); Used to support the driver's mc_getstat() mac callback for statistic collection, and only to be called from that function (without any locks held). This routine will process all of the statistics that are relevant to MII on behalf of the driver. Returns 0 if the statistic was processed, or ENOTSUP if the MII does not recognize the statistic. 4. Functions for Phy Specific Overrides Some PHYs require vendor specific tweaks or adjustments. Rather than run separate drivers with different PHYs for each type, we are going to simply compile all the overrides into one binary. All of the interfaces between the vendor specific PHY modules and the MII core are hence Project Private and not covered here. (However, see the private miipriv.h header if interested in the details.) From carlsonj@phorcys.east.sun.com Wed May 27 04:21:34 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4RBLXLS026018 for ; Wed, 27 May 2009 04:21:33 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4RBLTgY046060; Wed, 27 May 2009 05:21:33 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKA00D03VJWZK00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 27 May 2009 04:21:32 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKA00BOVVJV1870@nwk-avmta-1.sfbay.Sun.COM>; Wed, 27 May 2009 04:21:31 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4RBLTOr003815; Wed, 27 May 2009 07:21:29 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4RBKQFX018316; Wed, 27 May 2009 07:20:26 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n4RBKQVr018313; Wed, 27 May 2009 07:20:26 -0400 (EDT) Date: Wed, 27 May 2009 07:20:26 -0400 From: James Carlson Subject: Re: MII & GMII Common Layer [PSARC/2009/319 FastTrack timeout 06/01/2009] In-reply-to: <4A1CCECF.7070002@sun.com> To: "Garrett D'Amore" Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, brussels-dev@sun.com, sstallion@gmail.com Message-id: <18973.8698.560937.308466@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905230537.n4N5bTHK007524@sac.sfbay.sun.com> <18971.53752.362421.215071@gargle.gargle.HOWL> <4A1C0F5F.5040901@sun.com> <18972.4322.496047.83370@gargle.gargle.HOWL> <4A1C15F8.5090201@sun.com> <18972.6153.600870.999505@gargle.gargle.HOWL> <4A1C4BAE.6010801@sun.com> <18972.19738.763276.971136@gargle.gargle.HOWL> <4A1CCECF.7070002@sun.com> Status: RO Content-Length: 491 Garrett D'Amore writes: > Okay, I'm taking the two-functions approach. The following is the > revised specification, which addresses all of the issues that you've > pointed out so far (I hope). +1 (with the understanding that there's _no_ commitment to backport). -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From gdamore@sun.com Wed May 27 08:10:20 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4RFAKKV027010 for ; Wed, 27 May 2009 08:10:20 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4RFAJTA045083; Wed, 27 May 2009 09:10:20 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKB00403657IU00@brm-avmta-1.central.sun.com>; Wed, 27 May 2009 09:10:19 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKB000LQ6535V30@brm-avmta-1.central.sun.com>; Wed, 27 May 2009 09:10:15 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4RFAFSq027392; Wed, 27 May 2009 08:10:15 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKB0000042OCB00@fe-sfbay-09.sun.com>; Wed, 27 May 2009 08:10:15 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKB00EDK652OF10@fe-sfbay-09.sun.com>; Wed, 27 May 2009 08:10:14 -0700 (PDT) Date: Wed, 27 May 2009 08:10:13 -0700 From: "Garrett D'Amore" Subject: Re: MII & GMII Common Layer [PSARC/2009/319 FastTrack timeout 06/01/2009] In-reply-to: <18973.8698.560937.308466@gargle.gargle.HOWL> Sender: Garrett.Damore@sun.com To: James Carlson Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, brussels-dev@sun.com, sstallion@gmail.com Message-id: <4A1D57D5.4030500@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905230537.n4N5bTHK007524@sac.sfbay.sun.com> <18971.53752.362421.215071@gargle.gargle.HOWL> <4A1C0F5F.5040901@sun.com> <18972.4322.496047.83370@gargle.gargle.HOWL> <4A1C15F8.5090201@sun.com> <18972.6153.600870.999505@gargle.gargle.HOWL> <4A1C4BAE.6010801@sun.com> <18972.19738.763276.971136@gargle.gargle.HOWL> <4A1CCECF.7070002@sun.com> <18973.8698.560937.308466@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 357 James Carlson wrote: > Garrett D'Amore writes: > >> Okay, I'm taking the two-functions approach. The following is the >> revised specification, which addresses all of the issues that you've >> pointed out so far (I hope). >> > > +1 (with the understanding that there's _no_ commitment to backport). > > Thank you! (And a big *doh*!) - Garrett From garrett@damore.org Wed May 27 11:16:59 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4RIGwfx008210 for ; Wed, 27 May 2009 11:16:58 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4RIGeHn026229 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 27 May 2009 19:16:57 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKB00H0NES10100@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 27 May 2009 11:16:49 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKB00L5BES0RI80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 27 May 2009 11:16:48 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4RI6TTL004755 for ; Wed, 27 May 2009 18:16:47 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay43i.sun.com with ESMTP id BT-MMP-4873133 for PSARC-ext@sun.com; Wed, 27 May 2009 18:16:47 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-3640994 for PSARC-ext@sun.com; Wed, 27 May 2009 18:16:47 +0000 (Z) Received: from outbound-mail-25.bluehost.com ([69.89.21.20] [69.89.21.20]) by relay4i.sun.com id BT-MMP-4176641 for PSARC-ext@sun.com; Wed, 27 May 2009 18:16:23 +0000 (Z) Received: (qmail 19679 invoked by uid 0); Wed, 27 May 2009 18:15:21 +0000 Received: from unknown (HELO box374.bluehost.com) (69.89.31.174) by outboundproxy2.bluehost.com with SMTP; Wed, 27 May 2009 18:15:21 +0000 Received: from sca-ea-fw-1.sun.com ([192.18.43.225] helo=[10.7.251.172]) by box374.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M9Ner-0006P7-K7 for PSARC-ext@sun.com; Wed, 27 May 2009 12:15:21 -0600 Date: Wed, 27 May 2009 11:15:20 -0700 From: "Garrett D'Amore" Subject: PSARC 2009/319 MII & GMII Common Layer To: PSARC-ext Message-id: <4A1D8338.2090706@damore.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=damore.org; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=A2rRFK9E5FZbmNf0GY8WtoIDtcmTh5Yg/Kg/dqzkstof/DvTVemn8s5TY3X/CpDeb96M5t7zprIperQHZyLpmS9Thjlbhx/Wx5gHniK4P/8WGzqnNZ1svY7N/WdRWAiu; X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Identified-User: {2225:box374.bluehost.com:damoreor:damore.org} {sentby:smtp auth 192.18.43.225 authed with garrett+damore.org} X-Antispam: No, score=1.0/5.0, scanned in 0.228sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 54 This case was approved at PSARC today. - Garrett From sstallion@gmail.com Wed May 27 15:41:25 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4RMfO5B011633 for ; Wed, 27 May 2009 15:41:25 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n4RMfN3S023191 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 28 May 2009 06:41:24 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKB00F0FR0ZJU00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 27 May 2009 15:41:23 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKB00A50R0W9M40@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 27 May 2009 15:41:22 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4RMfKPu020029 for ; Wed, 27 May 2009 22:41:20 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay13i.sun.com with ESMTP id BT-MMP-1011417 for psarc-ext@sun.com; Wed, 27 May 2009 22:41:19 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-201681 for psarc-ext@sun.com; Wed, 27 May 2009 22:41:19 +0000 (Z) Received: from mta11.charter.net ([216.33.127.80] [216.33.127.80]) by relay1i.sun.com with ESMTP id BT-MMP-25090534 for psarc-ext@sun.com; Wed, 27 May 2009 22:41:19 +0000 (Z) Received: from imp10 ([10.20.200.10]) by mta11.charter.net (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090527224119.SOWK22327.mta11.charter.net@imp10>; Wed, 27 May 2009 18:41:19 -0400 Received: from mail.arf.ubound.org ([24.217.33.94]) by imp10 with smtp.charter.net id wmhJ1b00Q21rTw805mhJLb; Wed, 27 May 2009 18:41:19 -0400 Received: from mail.arf.ubound.org (mail [10.8.0.14]) by mail.arf.ubound.org (Postfix) with ESMTP id B410B80DD; Wed, 27 May 2009 17:41:18 -0500 (CDT) Date: Wed, 27 May 2009 17:41:18 -0500 From: Steven Stallion Subject: Re: PSARC 2009/319 MII & GMII Common Layer In-reply-to: <4A1D8338.2090706@damore.org> X-Sender: sstallion@gmail.com To: "Garrett D'Amore" Cc: PSARC-ext Message-id: <31aeb12970f88b58d4e5bef1a6b0d4af@mail.arf.ubound.org> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.060sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4A1D8338.2090706@damore.org> User-Agent: RoundCube Webmail/0.2.1 Status: RO Content-Length: 314 On Wed, 27 May 2009 11:15:20 -0700, "Garrett D'Amore" wrote: > This case was approved at PSARC today. > > - Garrett Congrats! -- 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. From garrett@damore.org Wed May 27 22:11:31 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4S5BVo5012467 for ; Wed, 27 May 2009 22:11:31 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4S5BT7h028386 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 27 May 2009 22:11:31 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKC00N0X9354V00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 27 May 2009 23:11:29 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKC00LH6935PHA0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 27 May 2009 23:11:29 -0600 (MDT) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4S59LAc018035 for ; Thu, 28 May 2009 05:11:29 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay41i.sun.com with ESMTP id BT-MMP-4923584 for PSARC-ext@sun.com; Thu, 28 May 2009 05:11:29 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-4459550 for PSARC-ext@sun.com; Thu, 28 May 2009 05:11:28 +0000 (Z) Received: from outbound-mail-30.bluehost.com ([69.89.17.212] [69.89.17.212]) by relay4i.sun.com id BT-MMP-5110081 for PSARC-ext@sun.com; Thu, 28 May 2009 05:11:28 +0000 (Z) Received: (qmail 3371 invoked by uid 0); Thu, 28 May 2009 05:11:28 +0000 Received: from unknown (HELO box374.bluehost.com) (69.89.31.174) by outboundproxy2.bluehost.com with SMTP; Thu, 28 May 2009 05:11:28 +0000 Received: from sca-ea-fw-1.sun.com ([192.18.43.225] helo=[10.7.251.172]) by box374.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M9Xtn-0005iU-Uo for PSARC-ext@sun.com; Wed, 27 May 2009 23:11:28 -0600 Date: Wed, 27 May 2009 22:11:26 -0700 From: "Garrett D'Amore" Subject: PSARC 2009/319 MII & GMII Common Layer (update) To: PSARC-ext Message-id: <4A1E1CFE.3060706@damore.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=damore.org; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=296dwFPI5G3FRaBZA9q2CA3hrgGo7h1Z5AGKEZGItLR/bXq/vyyBlWdLcBKs6wdijgGco5a9qxHsj9PIgkxJAUt7l2dwb3pZ0CX+/uupNdyOumhzDpBrOqM7+XcY5o2/; X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Identified-User: {2225:box374.bluehost.com:damoreor:damore.org} {sentby:smtp auth 192.18.43.225 authed with garrett+damore.org} X-Antispam: No, score=0.0/5.0, scanned in 0.124sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2082 I need to add a couple of functions that were missing from the review, due to discovery of a SUSPEND/RESUME race during careful code review of my prototype... rather than run this as a separate self-review case, I think its easiest just to update the case here. If anyone would like more complete review let me know. Essentially, I need to add three functions for mac drivers: /* * mii_reset * * Schedules a reset of the MII bus. Normally not needed, but * can be used to perform a full master reset, including * rescanning for PHYs. This function may be called in any * context except high level interrupt context, but must be * called without any locks held. The reset will probably not * be complete until sometime after the call returns. * * Note that if mii_start has not been called, then the reset * will not be performed until _after_ the MII is started. */ void mii_reset(mii_handle_t mii); /* * mii_suspend * * Suspends monitoring of the MII bus. Normally this is called * as a part of a driver's DDI_SUSPEND handling. On return, the * MII layer is guaranteed not to be executing any code in the * MII entry points. This function may be called in any context * except high level interrupt context, but must be called * without any locks held. */ void mii_suspend(mii_handle_t mii); /* * mii_resume * * Starts monitoring of the MII bus. Normally this is called as * a part of a driver's DDI_RESUME handling. This function may * be called in any context except high level interrupt context, * but must be called without any locks held. */ void mii_resume(mii_handle_t mii); The upshot of these functions is that the MII layer will only be monitoring the MII bus if *both* the MII has been started with mii_start() AND the MII has not been suspended with mii_suspend(). If anyone wants more explanation or details as to why this separation from mii_start() and mii_stop() are necessary, let me know and I'll be happy to provide more explanation. Thanks. - Garrett