[net-next 0/4 (V3)] stmmac & EEE support

[net-next 0/4 (V3)] stmmac & EEE support

[Giuseppe CAVALLARO]

These patches add the EEE support in the stmmac device driver.
I've tested it on ST STB with the IC+ 101G PHY device that has
this feature.
Initially the EEE for the stmmac has been written by Rayagond
but I reworked all his code adding new parts and especially
performing tests on a real hardware. Thx Rayagond!

In these patches, we can see that the stmmac supports the EEE
only if the DMA HW capability register says that this
feature is actually available. In that case, the driver can enter
in the Tx LPI mode by using a timer as recommended by Synopsys.
Note that EEE is supported in new chip generations; in particular
I used the 3.61a.

At any rate, further information about how the driver treats the EEE
can be found in the stmmac.txt file (there is a patch for that).

These patches also add a new option for ethtool to enable/disable
the EEE. There is a patch for the ethtool user space application;
I'm sending it too.

Another patch is for Physical Abstraction Layer now able to
manage the MMD registers (clause 45).
Maybe, I could directly add the EEE in the mdio driver.
I didn't that because I wanted to keep the stmmac able to access
to the phy registers through the Physical Abstraction Layer and
w/ having any links to the mdio.o.

Please Ben tells me if I well applied all your advice (when you
reviewed the ethtool/phy patches).

Regards
Peppe

Giuseppe CAVALLARO (1):
  stmmac: update the driver Documentation and add EEE

Giuseppe Cavallaro (3):
  net: ethtool: add the EEE support
  phy: add the EEE support and the way to access to the MMD regs
  stmmac: add the Energy Efficient Ethernet support

 Documentation/networking/stmmac.txt                |   36 ++++-
 drivers/net/ethernet/stmicro/stmmac/common.h       |   27 ++++-
 drivers/net/ethernet/stmicro/stmmac/dwmac1000.h    |   20 +++
 .../net/ethernet/stmicro/stmmac/dwmac1000_core.c   |  101 ++++++++++++-
 .../net/ethernet/stmicro/stmmac/dwmac100_core.c    |    4 +-
 drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h    |    1 +
 drivers/net/ethernet/stmicro/stmmac/stmmac.h       |    6 +
 .../net/ethernet/stmicro/stmmac/stmmac_ethtool.c   |   48 ++++++
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  |  156 +++++++++++++++++++-
 .../net/ethernet/stmicro/stmmac/stmmac_platform.c  |    2 +
 drivers/net/phy/phy_device.c                       |  138 +++++++++++++++++
 include/linux/ethtool.h                            |    6 +
 include/linux/mdio.h                               |    6 +-
 include/linux/mii.h                                |   11 ++
 include/linux/phy.h                                |    3 +
 net/core/ethtool.c                                 |   32 ++++
 16 files changed, 572 insertions(+), 25 deletions(-)

-- 
1.7.4.4

[net-next 1/4 (V3)] net: ethtool: add the EEE support

[Giuseppe CAVALLARO]

This patch adds two new functions to detect if Energy-Efficient
Ethernet (EEE) is supported and the way to enable/disable it.

As Ben said, it is certainly necessary to distinguish:

a. PHY is advertising EEE from
b. Link partner is advertising EEE
or
c. EEE will be used (= a && b)

The logic behind this code, is that .get_eee will pass
to the user-space if the EEE is actually used and available (so point c).
The .set_eee should used to force the MAC to disable/enable the EEE (if
actually supported by MAC+PHY).
I have also added the .set_eee because the Synopsys GMAC manages the TX LPI
path through a SW timer that in this case can be disabled via ethtool.
Indeed, no action should be taken by the user for the PHY side.
Maybe, the only thing that could be changed is the clock stop enable bit
(3.0.10).

Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
---
 include/linux/ethtool.h |    6 ++++++
 net/core/ethtool.c      |   32 ++++++++++++++++++++++++++++++++
 2 files changed, 38 insertions(+), 0 deletions(-)

diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 560a247..d0150c8 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -920,6 +920,8 @@ static inline u32 ethtool_rxfh_indir_default(u32 index, u32 n_rx_rings)
  * @get_ts_info: Get the time stamping and PTP hardware clock capabilities.
  *	Drivers supporting transmit time stamps in software should set this to
  *	ethtool_op_get_ts_info().
+ * @get_eee: Get Energy-Efficient Ethernet (EEE) supported and status.
+ * @set_eee: Set EEE status (enable/disable).
  *
  * All operations are optional (i.e. the function pointer may be set
  * to %NULL) and callers must take this into account.  Callers must
@@ -984,6 +986,8 @@ struct ethtool_ops {
 	int	(*set_dump)(struct net_device *, struct ethtool_dump *);
 	int	(*get_ts_info)(struct net_device *, struct ethtool_ts_info *);
 
+	int	(*get_eee) (struct net_device *, struct ethtool_value *);
+	int	(*set_eee) (struct net_device *, struct ethtool_value *);
 };
 #endif /* __KERNEL__ */
 
@@ -1058,6 +1062,8 @@ struct ethtool_ops {
 #define ETHTOOL_GET_DUMP_FLAG	0x0000003f /* Get dump settings */
 #define ETHTOOL_GET_DUMP_DATA	0x00000040 /* Get dump data */
 #define ETHTOOL_GET_TS_INFO	0x00000041 /* Get time stamping and PHC info */
+#define ETHTOOL_GEEE		0x00000042 /* Get EEE */
+#define ETHTOOL_SEEE		0x00000043 /* Set EEE */
 
 /* compatibility with older code */
 #define SPARC_ETH_GSET		ETHTOOL_GSET
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index beacdd9..c2374f9 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -729,6 +729,32 @@ static int ethtool_set_wol(struct net_device *dev, char __user *useraddr)
 	return dev->ethtool_ops->set_wol(dev, &wol);
 }
 
+static int ethtool_get_eee(struct net_device *dev, char __user *useraddr)
+{
+	struct ethtool_value edata;
+
+	if (!dev->ethtool_ops->get_eee)
+		return -EOPNOTSUPP;
+
+	dev->ethtool_ops->get_eee(dev, &edata);
+
+	if (copy_to_user(useraddr, &edata, sizeof(edata)))
+		return -EFAULT;
+	return 0;
+}
+
+static int ethtool_set_eee(struct net_device *dev, char __user *useraddr)
+{
+	struct ethtool_value edata;
+
+	if (!dev->ethtool_ops->set_eee)
+		return -EOPNOTSUPP;
+
+	if (copy_from_user(&edata, useraddr, sizeof(edata)))
+		return -EFAULT;
+
+	return dev->ethtool_ops->set_eee(dev, &edata);
+}
 static int ethtool_nway_reset(struct net_device *dev)
 {
 	if (!dev->ethtool_ops->nway_reset)
@@ -1420,6 +1446,12 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
 		rc = ethtool_set_value_void(dev, useraddr,
 				       dev->ethtool_ops->set_msglevel);
 		break;
+	case ETHTOOL_GEEE:
+		rc = ethtool_get_eee(dev, useraddr);
+		break;
+	case ETHTOOL_SEEE:
+		rc = ethtool_set_eee(dev, useraddr);
+		break;
 	case ETHTOOL_NWAY_RST:
 		rc = ethtool_nway_reset(dev);
 		break;
-- 
1.7.4.4

Re: [net-next 1/4 (V3)] net: ethtool: add the EEE support

[Ben Hutchings]

On Fri, 2012-04-06 at 11:29 +0200, Giuseppe CAVALLARO wrote:
> This patch adds two new functions to detect if Energy-Efficient
> Ethernet (EEE) is supported and the way to enable/disable it.
> 
> As Ben said, it is certainly necessary to distinguish:
> 
> a. PHY is advertising EEE from
> b. Link partner is advertising EEE
> or
> c. EEE will be used (= a && b)
> 
> The logic behind this code, is that .get_eee will pass
> to the user-space if the EEE is actually used and available (so point c).
> The .set_eee should used to force the MAC to disable/enable the EEE (if
> actually supported by MAC+PHY).
[...]

What I meant is that userland should be able to find out (a), and,
*separately*, either (b) or (c).  That is, there must be at least 2
separate flags for this.  In fact, I explicitly requested you define
supported/advertising/lp_advertising bitmasks for EEE link modes just
like we have for autonegotiation.  But you've made no substantive
changes in response to my review, aside from dropping the added field in
ethtool_cmd.

What you're submitting just isn't good enough for a generic interface,
as the ethtool API is supposed to be.  It's not even a good interface to
your driver.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: [net-next 1/4 (V3)] net: ethtool: add the EEE support

[Giuseppe CAVALLARO]

On 4/13/2012 12:26 AM, Ben Hutchings wrote:
> On Fri, 2012-04-06 at 11:29 +0200, Giuseppe CAVALLARO wrote:
>> This patch adds two new functions to detect if Energy-Efficient
>> Ethernet (EEE) is supported and the way to enable/disable it.
>>
>> As Ben said, it is certainly necessary to distinguish:
>>
>> a. PHY is advertising EEE from
>> b. Link partner is advertising EEE
>> or
>> c. EEE will be used (= a && b)
>>
>> The logic behind this code, is that .get_eee will pass
>> to the user-space if the EEE is actually used and available (so point c).
>> The .set_eee should used to force the MAC to disable/enable the EEE (if
>> actually supported by MAC+PHY).
> [...]
> 
> What I meant is that userland should be able to find out (a), and,
> *separately*, either (b) or (c).  That is, there must be at least 2
> separate flags for this.  In fact, I explicitly requested you define
> supported/advertising/lp_advertising bitmasks for EEE link modes just
> like we have for autonegotiation.  But you've made no substantive
> changes in response to my review, aside from dropping the added field in
> ethtool_cmd.

Sorry Ben but I believed that (c) was enough.

> What you're submitting just isn't good enough for a generic interface,
> as the ethtool API is supposed to be.  It's not even a good interface to
> your driver.

yes! I'll rework this and provide new patches asap.

peppe

> Ben.
> 

Re: [net-next 1/4 (V3)] net: ethtool: add the EEE support

[Giuseppe CAVALLARO]

Hello Ben,

On 4/16/2012 7:41 AM, Giuseppe CAVALLARO wrote:
[snip]
>> What I meant is that userland should be able to find out (a), and,
>> *separately*, either (b) or (c).  That is, there must be at least 2
>> separate flags for this.  In fact, I explicitly requested you define
>> supported/advertising/lp_advertising bitmasks for EEE link modes just
>> like we have for autonegotiation.  But you've made no substantive
>> changes in response to my review, aside from dropping the added field in
>> ethtool_cmd.
> 
> Sorry Ben but I believed that (c) was enough.
> 
>> What you're submitting just isn't good enough for a generic interface,
>> as the ethtool API is supposed to be.  It's not even a good interface to
>> your driver.
> 
> yes! I'll rework this and provide new patches asap.

sorry if I disturb you but I want to be sure to avoid to forget
something else in the next EEE patches (avoiding to continuously disturb
you).

I'm changing the code for getting/setting the EEE capability and trying
to follow your suggestions.

The "get" will show the following things; this is a bit different of the
points "a" "b" and "c" we had discussed. Maybe, this could also be a
more complete (*) .
The ethtool (see output below as example) could report the phy
(supported/advertised/lp_advertised) and mac eee capabilities separately.

The "set" will be useful for some eth devices (like the stmmac) that can
stop/enable internally the eee capability (at mac level).

What do you think?

Regards
Peppe

----

# ./ethtool  eth0
Settings for eth0:

[snip]

	Current message level: 0x0000003f (63)
			       drv probe link timer ifdown ifup
	Link detected: yes
	Energy-Efficient Ethernet:           -------------------------
		MAC supports: yes            |-> related to MAC side  |
		phy supports modes: ...      |-> from MMD 3.20        |
		phy advertising modes: ...   |-> from MMD 7.60        |
		LP advertising modes: ...    |-> from MMD 7.61        |
					     --------------------------
                                                    (*)
PS. The "..." above means that we can actually dump: 100BASE-TX EEE etc
for each advertising modes and also for phy support (reg 3.20).

> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [net-next 1/4 (V3)] net: ethtool: add the EEE support

[Yuval Mintz]

Hi Peppe,

> The "set" will be useful for some eth devices (like the stmmac) that can
> stop/enable internally the eee capability (at mac level).

If you're already implementing this interface, don't you think it might be
prudent to create an implementation that can do more than enable/disable
the interface?
I think users would like a method for configuring some of the EEE's variables,
mainly controlling the timers affecting the generation of an LPI request,
as such control might have a direct consequence on the effectiveness of their
energy savings (less time for generation ==> better energy savings, with a
possible latency penalty).

Thanks,
Yuval

Re: [net-next 1/4 (V3)] net: ethtool: add the EEE support

[Ben Hutchings]

On Thu, 2012-04-19 at 16:48 +0300, Yuval Mintz wrote:
> Hi Peppe,
> 
> > The "set" will be useful for some eth devices (like the stmmac) that can
> > stop/enable internally the eee capability (at mac level).
> 
> If you're already implementing this interface, don't you think it might be
> prudent to create an implementation that can do more than enable/disable
> the interface?
[...]

It's not necessary for anyone to *implement* all of this now, but the
interface should certainly cover any settings that users may reasonably
want to read and configure.  As with most ethtool 'set' operations, any
implementation (driver) can disallow changing any or all settings
(-EOPNOTSUPP or -EINVAL) if it's difficult or impossible to implement
them.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: [net-next 1/4 (V3)] net: ethtool: add the EEE support

[Ben Hutchings]

On Thu, 2012-04-19 at 14:58 +0200, Giuseppe CAVALLARO wrote:
> Hello Ben,
> 
> On 4/16/2012 7:41 AM, Giuseppe CAVALLARO wrote:
> [snip]
> >> What I meant is that userland should be able to find out (a), and,
> >> *separately*, either (b) or (c).  That is, there must be at least 2
> >> separate flags for this.  In fact, I explicitly requested you define
> >> supported/advertising/lp_advertising bitmasks for EEE link modes just
> >> like we have for autonegotiation.  But you've made no substantive
> >> changes in response to my review, aside from dropping the added field in
> >> ethtool_cmd.
> > 
> > Sorry Ben but I believed that (c) was enough.
> > 
> >> What you're submitting just isn't good enough for a generic interface,
> >> as the ethtool API is supposed to be.  It's not even a good interface to
> >> your driver.
> > 
> > yes! I'll rework this and provide new patches asap.
> 
> sorry if I disturb you but I want to be sure to avoid to forget
> something else in the next EEE patches (avoiding to continuously disturb
> you).
> 
> I'm changing the code for getting/setting the EEE capability and trying
> to follow your suggestions.
> 
> The "get" will show the following things; this is a bit different of the
> points "a" "b" and "c" we had discussed. Maybe, this could also be a
> more complete (*) .
> The ethtool (see output below as example) could report the phy
> (supported/advertised/lp_advertised) and mac eee capabilities separately.

Sounds reasonable.

> The "set" will be useful for some eth devices (like the stmmac) that can
> stop/enable internally the eee capability (at mac level).

I don't know much about EEE, but shouldn't the driver take care of
configuring the MAC for this whenever the PHY is set to advertise EEE
capability?

> What do you think?
> 
> Regards
> Peppe
> 
> ----
> 
> # ./ethtool  eth0
> Settings for eth0:
> 
> [snip]
> 
> 	Current message level: 0x0000003f (63)
> 			       drv probe link timer ifdown ifup
> 	Link detected: yes
> 	Energy-Efficient Ethernet:           -------------------------
> 		MAC supports: yes            |-> related to MAC side  |
> 		phy supports modes: ...      |-> from MMD 3.20        |
> 		phy advertising modes: ...   |-> from MMD 7.60        |
> 		LP advertising modes: ...    |-> from MMD 7.61        |
> 					     --------------------------
>                                                     (*)
> PS. The "..." above means that we can actually dump: 100BASE-TX EEE etc
> for each advertising modes and also for phy support (reg 3.20).

Yes, that's the sort of information I would expect to see (but try to be
consistent with the wording used for AN).

The EEE advertising mask presumably should be changeable similarly to
the AN advertising mask ('ethtool -s <devname> eeeadv <mask>').  But I
don't know how the two advertising masks interact.  Is one supposed to
be a subset of the other?  Currently ethtool automatically changes the
AN advertising mask in response to a speed/duplex change; should it also
try to change the EEE advertising mask?

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: [net-next 1/4 (V3)] net: ethtool: add the EEE support

[Giuseppe CAVALLARO]

Hello Ben

On 4/19/2012 5:30 PM, Ben Hutchings wrote:
[snip]
>> I'm changing the code for getting/setting the EEE capability and trying
>> to follow your suggestions.
>>
>> The "get" will show the following things; this is a bit different of the
>> points "a" "b" and "c" we had discussed. Maybe, this could also be a
>> more complete (*) .
>> The ethtool (see output below as example) could report the phy
>> (supported/advertised/lp_advertised) and mac eee capabilities separately.
> 
> Sounds reasonable.
> 
>> The "set" will be useful for some eth devices (like the stmmac) that can
>> stop/enable internally the eee capability (at mac level).
> 
> I don't know much about EEE, but shouldn't the driver take care of
> configuring the MAC for this whenever the PHY is set to advertise EEE
> capability?

Yes indeed this can be done at driver level. So could I definitely
remove it from ethtool? What do you suggest?

In case of the stmmac I could add a specific driver option via sys to
enable/disable the eee and set timer.

>> [snip]
>>
>> 	Current message level: 0x0000003f (63)
>> 			       drv probe link timer ifdown ifup
>> 	Link detected: yes
>> 	Energy-Efficient Ethernet:           -------------------------
>> 		MAC supports: yes            |-> related to MAC side  |
>> 		phy supports modes: ...      |-> from MMD 3.20        |
>> 		phy advertising modes: ...   |-> from MMD 7.60        |
>> 		LP advertising modes: ...    |-> from MMD 7.61        |
>> 					     --------------------------
>>                                                     (*)
>> PS. The "..." above means that we can actually dump: 100BASE-TX EEE etc
>> for each advertising modes and also for phy support (reg 3.20).
> 
> Yes, that's the sort of information I would expect to see (but try to be
> consistent with the wording used for AN).:

e.g. SUPPORTED_100baseT_EEE ... ADVERTISED_<...>

> The EEE advertising mask presumably should be changeable similarly to
> the AN advertising mask ('ethtool -s <devname> eeeadv <mask>').  But I
> don't know how the two advertising masks interact.  Is one supposed to
> be a subset of the other?  Currently ethtool automatically changes the
> AN advertising mask in response to a speed/duplex change; should it also
> try to change the EEE advertising mask?

I've just verified the IEEE (Table 45–150a—EEE advertisement register
(Register 7.60) bit definitions) and sorry for my delay in reply but I
was in trouble because looking at the registers for the phy (I am using)
the reg 7.60 was in RO and I couldn't understand how to set the mask.
I confirm that the Adv reg from the std is R/W and the mask as you
suggest could be set according to the speed.
The EEE should work on duplex mode only.

I wonder so if if the final patch I should have no new option for the
ethtool command and EEE info are directly passed from the kernel like
speed and duplex when call get_settings.

Peppe

> 
> Ben.
> 

Re: [net-next 1/4 (V3)] net: ethtool: add the EEE support

[Ben Hutchings]

On Thu, 2012-04-26 at 09:48 +0200, Giuseppe CAVALLARO wrote:
> Hello Ben
> 
> On 4/19/2012 5:30 PM, Ben Hutchings wrote:
> [snip]
> >> I'm changing the code for getting/setting the EEE capability and trying
> >> to follow your suggestions.
> >>
> >> The "get" will show the following things; this is a bit different of the
> >> points "a" "b" and "c" we had discussed. Maybe, this could also be a
> >> more complete (*) .
> >> The ethtool (see output below as example) could report the phy
> >> (supported/advertised/lp_advertised) and mac eee capabilities separately.
> > 
> > Sounds reasonable.
> > 
> >> The "set" will be useful for some eth devices (like the stmmac) that can
> >> stop/enable internally the eee capability (at mac level).
> > 
> > I don't know much about EEE, but shouldn't the driver take care of
> > configuring the MAC for this whenever the PHY is set to advertise EEE
> > capability?
> 
> Yes indeed this can be done at driver level. So could I definitely
> remove it from ethtool? What do you suggest?
> 
> In case of the stmmac I could add a specific driver option via sys to
> enable/disable the eee and set timer.

Generally, ethtool doesn't distinguish MAC and PHY settings because they
have to be configured consistently for the device to do anything useful.
If there is some good use for enabling EEE in the MAC and not the PHY,
or vice versa, then this should be exposed in the ethtool interface.
But if not then I don't believe it needs to be in either an ethtool or a
driver-specific interface.  

> >> [snip]
> >>
> >> 	Current message level: 0x0000003f (63)
> >> 			       drv probe link timer ifdown ifup
> >> 	Link detected: yes
> >> 	Energy-Efficient Ethernet:           -------------------------
> >> 		MAC supports: yes            |-> related to MAC side  |
> >> 		phy supports modes: ...      |-> from MMD 3.20        |
> >> 		phy advertising modes: ...   |-> from MMD 7.60        |
> >> 		LP advertising modes: ...    |-> from MMD 7.61        |
> >> 					     --------------------------
> >>                                                     (*)
> >> PS. The "..." above means that we can actually dump: 100BASE-TX EEE etc
> >> for each advertising modes and also for phy support (reg 3.20).
> > 
> > Yes, that's the sort of information I would expect to see (but try to be
> > consistent with the wording used for AN).:
> 
> e.g. SUPPORTED_100baseT_EEE ... ADVERTISED_<...>

I meant the wording used in the ethtool output: 'supported',
'advertised', 'link partner advertised' rather than 'phy supports',
'phy advertising', 'LP advertising'.

> > The EEE advertising mask presumably should be changeable similarly to
> > the AN advertising mask ('ethtool -s <devname> eeeadv <mask>').  But I
> > don't know how the two advertising masks interact.  Is one supposed to
> > be a subset of the other?  Currently ethtool automatically changes the
> > AN advertising mask in response to a speed/duplex change; should it also
> > try to change the EEE advertising mask?
> 
> I've just verified the IEEE (Table 45–150a—EEE advertisement register
> (Register 7.60) bit definitions) and sorry for my delay in reply but I
> was in trouble because looking at the registers for the phy (I am using)
> the reg 7.60 was in RO and I couldn't understand how to set the mask.
> I confirm that the Adv reg from the std is R/W and the mask as you
> suggest could be set according to the speed.
> The EEE should work on duplex mode only.
> 
> I wonder so if if the final patch I should have no new option for the
> ethtool command and EEE info are directly passed from the kernel like
> speed and duplex when call get_settings.

Are you suggesting to define EEE mode flags in the existing supported,
advertising and lp_advertising masks?

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: [net-next 1/4 (V3)] net: ethtool: add the EEE support

[Giuseppe CAVALLARO]

On 4/26/2012 7:17 PM, Ben Hutchings wrote:
> On Thu, 2012-04-26 at 09:48 +0200, Giuseppe CAVALLARO wrote:
>> Hello Ben
>>
>> On 4/19/2012 5:30 PM, Ben Hutchings wrote:
>> [snip]
>>>> I'm changing the code for getting/setting the EEE capability and trying
>>>> to follow your suggestions.
>>>>
>>>> The "get" will show the following things; this is a bit different of the
>>>> points "a" "b" and "c" we had discussed. Maybe, this could also be a
>>>> more complete (*) .
>>>> The ethtool (see output below as example) could report the phy
>>>> (supported/advertised/lp_advertised) and mac eee capabilities separately.
>>>
>>> Sounds reasonable.
>>>
>>>> The "set" will be useful for some eth devices (like the stmmac) that can
>>>> stop/enable internally the eee capability (at mac level).
>>>
>>> I don't know much about EEE, but shouldn't the driver take care of
>>> configuring the MAC for this whenever the PHY is set to advertise EEE
>>> capability?
>>
>> Yes indeed this can be done at driver level. So could I definitely
>> remove it from ethtool? What do you suggest?
>>
>> In case of the stmmac I could add a specific driver option via sys to
>> enable/disable the eee and set timer.
> 
> Generally, ethtool doesn't distinguish MAC and PHY settings because they
> have to be configured consistently for the device to do anything useful.
> If there is some good use for enabling EEE in the MAC and not the PHY,
> or vice versa, then this should be exposed in the ethtool interface.
> But if not then I don't believe it needs to be in either an ethtool or a
> driver-specific interface.

Thanks Ben for this clarification: in case of the stmmac the option is
useful to stop a timer to enter in lpi state for the tx.
So it's worth having that and from ethtool.

> 
>>>> [snip]
>>>>
>>>> 	Current message level: 0x0000003f (63)
>>>> 			       drv probe link timer ifdown ifup
>>>> 	Link detected: yes
>>>> 	Energy-Efficient Ethernet:           -------------------------
>>>> 		MAC supports: yes            |-> related to MAC side  |
>>>> 		phy supports modes: ...      |-> from MMD 3.20        |
>>>> 		phy advertising modes: ...   |-> from MMD 7.60        |
>>>> 		LP advertising modes: ...    |-> from MMD 7.61        |
>>>> 					     --------------------------
>>>>                                                     (*)
>>>> PS. The "..." above means that we can actually dump: 100BASE-TX EEE etc
>>>> for each advertising modes and also for phy support (reg 3.20).
>>>
>>> Yes, that's the sort of information I would expect to see (but try to be
>>> consistent with the wording used for AN).:
>>
>> e.g. SUPPORTED_100baseT_EEE ... ADVERTISED_<...>
> 
> I meant the wording used in the ethtool output: 'supported',
> 'advertised', 'link partner advertised' rather than 'phy supports',
> 'phy advertising', 'LP advertising'.

ok :-)

> 
>>> The EEE advertising mask presumably should be changeable similarly to
>>> the AN advertising mask ('ethtool -s <devname> eeeadv <mask>').  But I
>>> don't know how the two advertising masks interact.  Is one supposed to
>>> be a subset of the other?  Currently ethtool automatically changes the
>>> AN advertising mask in response to a speed/duplex change; should it also
>>> try to change the EEE advertising mask?
>>
>> I've just verified the IEEE (Table 45–150a—EEE advertisement register
>> (Register 7.60) bit definitions) and sorry for my delay in reply but I
>> was in trouble because looking at the registers for the phy (I am using)
>> the reg 7.60 was in RO and I couldn't understand how to set the mask.
>> I confirm that the Adv reg from the std is R/W and the mask as you
>> suggest could be set according to the speed.
>> The EEE should work on duplex mode only.
>>
>> I wonder so if if the final patch I should have no new option for the
>> ethtool command and EEE info are directly passed from the kernel like
>> speed and duplex when call get_settings.
> 
> Are you suggesting to define EEE mode flags in the existing supported,
> advertising and lp_advertising masks?

Yes but I was wrong, I can use the existing flags.

Regards
Peppe

> 
> Ben.
> 

Re: [net-next 1/4 (V3)] net: ethtool: add the EEE support

[Yuval Mintz]

On 04/27/2012 05:11 PM, Giuseppe CAVALLARO wrote:

> On 4/26/2012 7:17 PM, Ben Hutchings wrote:
>> On Thu, 2012-04-26 at 09:48 +0200, Giuseppe CAVALLARO wrote:
>>> Hello Ben
>>>
>>> On 4/19/2012 5:30 PM, Ben Hutchings wrote:
>>> [snip]
>>>>> I'm changing the code for getting/setting the EEE capability and trying
>>>>> to follow your suggestions.
>>>>>
>>>>> The "get" will show the following things; this is a bit different of the
>>>>> points "a" "b" and "c" we had discussed. Maybe, this could also be a
>>>>> more complete (*) .
>>>>> The ethtool (see output below as example) could report the phy
>>>>> (supported/advertised/lp_advertised) and mac eee capabilities separately.
>>>> Sounds reasonable.
>>>>
>>>>> The "set" will be useful for some eth devices (like the stmmac) that can
>>>>> stop/enable internally the eee capability (at mac level).
>>>> I don't know much about EEE, but shouldn't the driver take care of
>>>> configuring the MAC for this whenever the PHY is set to advertise EEE
>>>> capability?
>>> Yes indeed this can be done at driver level. So could I definitely
>>> remove it from ethtool? What do you suggest?
>>>
>>> In case of the stmmac I could add a specific driver option via sys to
>>> enable/disable the eee and set timer.
>> Generally, ethtool doesn't distinguish MAC and PHY settings because they
>> have to be configured consistently for the device to do anything useful.
>> If there is some good use for enabling EEE in the MAC and not the PHY,
>> or vice versa, then this should be exposed in the ethtool interface.
>> But if not then I don't believe it needs to be in either an ethtool or a
>> driver-specific interface.
> Thanks Ben for this clarification: in case of the stmmac the option is
> useful to stop a timer to enter in lpi state for the tx.
> So it's worth having that and from ethtool.

How will a user turn off EEE support using this implementation?

Are you suggesting a "set" that works similarly to the control of the pause
parameters - that is, a user could either shutdown EEE or only Tx, which
will mean to the driver "don't enter Tx LPI mode"?

Keep in mind that if later an interface controlling the LPI timers would be
added (as a measure of user control to the power saving vs. latency issue),
it could make this 'partial' closure interface redundant.

Perhaps "set" should only turn the EEE feature on/off entirely (adv. them or
not, since clearly the link will have to be re-established afterwards), and
we should have a different function that prevents entry into LPI mode in Tx
- one whose functionality could later on be extended.

Regards,
Yuval

Re: [net-next 1/4 (V3)] net: ethtool: add the EEE support

[Ben Hutchings]

On Sun, 2012-04-29 at 12:20 +0300, Yuval Mintz wrote:
> On 04/27/2012 05:11 PM, Giuseppe CAVALLARO wrote:
> 
> > On 4/26/2012 7:17 PM, Ben Hutchings wrote:
> >> On Thu, 2012-04-26 at 09:48 +0200, Giuseppe CAVALLARO wrote:
> >>> Hello Ben
> >>>
> >>> On 4/19/2012 5:30 PM, Ben Hutchings wrote:
> >>> [snip]
> >>>>> I'm changing the code for getting/setting the EEE capability and trying
> >>>>> to follow your suggestions.
> >>>>>
> >>>>> The "get" will show the following things; this is a bit different of the
> >>>>> points "a" "b" and "c" we had discussed. Maybe, this could also be a
> >>>>> more complete (*) .
> >>>>> The ethtool (see output below as example) could report the phy
> >>>>> (supported/advertised/lp_advertised) and mac eee capabilities separately.
> >>>> Sounds reasonable.
> >>>>
> >>>>> The "set" will be useful for some eth devices (like the stmmac) that can
> >>>>> stop/enable internally the eee capability (at mac level).
> >>>> I don't know much about EEE, but shouldn't the driver take care of
> >>>> configuring the MAC for this whenever the PHY is set to advertise EEE
> >>>> capability?
> >>> Yes indeed this can be done at driver level. So could I definitely
> >>> remove it from ethtool? What do you suggest?
> >>>
> >>> In case of the stmmac I could add a specific driver option via sys to
> >>> enable/disable the eee and set timer.
> >> Generally, ethtool doesn't distinguish MAC and PHY settings because they
> >> have to be configured consistently for the device to do anything useful.
> >> If there is some good use for enabling EEE in the MAC and not the PHY,
> >> or vice versa, then this should be exposed in the ethtool interface.
> >> But if not then I don't believe it needs to be in either an ethtool or a
> >> driver-specific interface.
> > Thanks Ben for this clarification: in case of the stmmac the option is
> > useful to stop a timer to enter in lpi state for the tx.
> > So it's worth having that and from ethtool.

I think I finally get it.  If we negotiate a 100BASE-TX link (or one of
the various backplane modes) with EEE enabled, we allow the link partner
to assert LPI but we might still not want to assert it in the transmit
direction.  Right?  (Whereas for 1000BASE-T and 10GBASE-T this would be
useless, since both sides must assert LPI before any transition can
happen.)

> How will a user turn off EEE support using this implementation?

At the ethtool API level this would be done by clearing the EEE
advertising mask.  At the command-line level there could be a shortcut
for this, just as you can use 'autoneg on' and 'autoneg off' rather than
specifying a mask of link modes.

> Are you suggesting a "set" that works similarly to the control of the pause
> parameters - that is, a user could either shutdown EEE or only Tx, which
> will mean to the driver "don't enter Tx LPI mode"?
>
> Keep in mind that if later an interface controlling the LPI timers would be
> added (as a measure of user control to the power saving vs. latency issue),
> it could make this 'partial' closure interface redundant.
>
> Perhaps "set" should only turn the EEE feature on/off entirely (adv. them or
> not, since clearly the link will have to be re-established afterwards), and
> we should have a different function that prevents entry into LPI mode in Tx
> - one whose functionality could later on be extended.

It sounds like this might as well be included, even if not all
drivers/hardware would allow the values to be changed.  So the command
structure would have at least:

1. EEE link mode supported flags (get-only)
2. EEE link mode advertising flags (get/set)
3. Ditto for link partner (get-only)
4. TX LPI enable flag (get/set)
5. TX LPI timer values (get/set but driver may reject changes)

But if it's not yet clear exactly what timer parameters will be useful,
we could leave some reserved space and then later define them along with
flags to indicate whether the driver understands them.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: [net-next 1/4 (V3)] net: ethtool: add the EEE support

[Giuseppe CAVALLARO]

Hello Ben

On 4/29/2012 11:56 PM, Ben Hutchings wrote:
> On Sun, 2012-04-29 at 12:20 +0300, Yuval Mintz wrote:
>> On 04/27/2012 05:11 PM, Giuseppe CAVALLARO wrote:
>>
>>> On 4/26/2012 7:17 PM, Ben Hutchings wrote:
>>>> On Thu, 2012-04-26 at 09:48 +0200, Giuseppe CAVALLARO wrote:
>>>>> Hello Ben
>>>>>
>>>>> On 4/19/2012 5:30 PM, Ben Hutchings wrote:
>>>>> [snip]
>>>>>>> I'm changing the code for getting/setting the EEE capability and trying
>>>>>>> to follow your suggestions.
>>>>>>>
>>>>>>> The "get" will show the following things; this is a bit different of the
>>>>>>> points "a" "b" and "c" we had discussed. Maybe, this could also be a
>>>>>>> more complete (*) .
>>>>>>> The ethtool (see output below as example) could report the phy
>>>>>>> (supported/advertised/lp_advertised) and mac eee capabilities separately.
>>>>>> Sounds reasonable.
>>>>>>
>>>>>>> The "set" will be useful for some eth devices (like the stmmac) that can
>>>>>>> stop/enable internally the eee capability (at mac level).
>>>>>> I don't know much about EEE, but shouldn't the driver take care of
>>>>>> configuring the MAC for this whenever the PHY is set to advertise EEE
>>>>>> capability?
>>>>> Yes indeed this can be done at driver level. So could I definitely
>>>>> remove it from ethtool? What do you suggest?
>>>>>
>>>>> In case of the stmmac I could add a specific driver option via sys to
>>>>> enable/disable the eee and set timer.
>>>> Generally, ethtool doesn't distinguish MAC and PHY settings because they
>>>> have to be configured consistently for the device to do anything useful.
>>>> If there is some good use for enabling EEE in the MAC and not the PHY,
>>>> or vice versa, then this should be exposed in the ethtool interface.
>>>> But if not then I don't believe it needs to be in either an ethtool or a
>>>> driver-specific interface.
>>> Thanks Ben for this clarification: in case of the stmmac the option is
>>> useful to stop a timer to enter in lpi state for the tx.
>>> So it's worth having that and from ethtool.
> 
> I think I finally get it.  If we negotiate a 100BASE-TX link (or one of
> the various backplane modes) with EEE enabled, we allow the link partner
> to assert LPI but we might still not want to assert it in the transmit
> direction.  Right?  (Whereas for 1000BASE-T and 10GBASE-T this would be
> useless, since both sides must assert LPI before any transition can
> happen.)
> 
>> How will a user turn off EEE support using this implementation?
> 
> At the ethtool API level this would be done by clearing the EEE
> advertising mask.  At the command-line level there could be a shortcut
> for this, just as you can use 'autoneg on' and 'autoneg off' rather than
> specifying a mask of link modes.
> 
>> Are you suggesting a "set" that works similarly to the control of the pause
>> parameters - that is, a user could either shutdown EEE or only Tx, which
>> will mean to the driver "don't enter Tx LPI mode"?
>>
>> Keep in mind that if later an interface controlling the LPI timers would be
>> added (as a measure of user control to the power saving vs. latency issue),
>> it could make this 'partial' closure interface redundant.
>>
>> Perhaps "set" should only turn the EEE feature on/off entirely (adv. them or
>> not, since clearly the link will have to be re-established afterwards), and
>> we should have a different function that prevents entry into LPI mode in Tx
>> - one whose functionality could later on be extended.
> 
> It sounds like this might as well be included, even if not all
> drivers/hardware would allow the values to be changed.  So the command
> structure would have at least:
> 
> 1. EEE link mode supported flags (get-only)
> 2. EEE link mode advertising flags (get/set)
> 3. Ditto for link partner (get-only)
> 4. TX LPI enable flag (get/set)
> 5. TX LPI timer values (get/set but driver may reject changes)

Ok I'll try to rework all following the points above. Just a note for
the timer and point 5 below.

> But if it's not yet clear exactly what timer parameters will be useful,
> we could leave some reserved space and then later define them along with
> flags to indicate whether the driver understands them.

I can use and test the LPI timer parameters that I intends, in case of
the stmmac d.d., the values added in a mac core register. These two timers:
1) specify the minimum time for which the link-status from the PHY
   should be up. The default value 1 sec as defined in the IEEE
   standard.
2) specify the minimum time for which the MAC waits after it has
   stopped transmitting the LPI pattern to the PHY

Peppe

> 
> Ben.
> 

[net-next 2/4 (V3)] phy: add the EEE support and the way to access to the MMD regs

[Giuseppe CAVALLARO]

This patch adds the initial support for the Energy-Efficient
Ethernet (EEE). It has been tested on IC+101G device on ST STB.

To support the EEE we have to access to the MMD registers 3.20 and
3.60/61. So I added two new functions to read/write the MMD
registers (clause 45)

The upper-layer will invoke the phy_check_eee to properly check
if the EEE is supported by the PHYs.
The phy_get_eee_err reports the number of time where the PHY
failed to complete its normal wake sequence.

Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
---
 drivers/net/phy/phy_device.c |  138 ++++++++++++++++++++++++++++++++++++++++++
 include/linux/mdio.h         |    6 ++-
 include/linux/mii.h          |   11 +++
 include/linux/phy.h          |    3 +
 4 files changed, 157 insertions(+), 1 deletions(-)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index e8c42d6..4231baa 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -30,6 +30,7 @@
 #include <linux/mii.h>
 #include <linux/ethtool.h>
 #include <linux/phy.h>
+#include <linux/mdio.h>
 
 #include <asm/io.h>
 #include <asm/irq.h>
@@ -898,6 +899,143 @@ int genphy_resume(struct phy_device *phydev)
 }
 EXPORT_SYMBOL(genphy_resume);
 
+static inline void mmd_phy_indirect(struct mii_bus *bus, int prtad, int devad,
+				    int addr)
+{
+	/* Write the desired MMD Devad */
+	bus->write(bus, addr, MII_MMD_CTRL, devad);
+
+	/* Write the desired MMD register address */
+	bus->write(bus, addr, MII_MMD_DATA, prtad);
+
+	/* Select the Function : DATA with no post increment */
+	bus->write(bus, addr, MII_MMD_CTRL,
+		   (devad | MII_MMD_CTRL_FUNC_DATA_NOINCR));
+}
+
+/**
+ * phy_read_mmd_indirect - reads data from the MMC register (clause 22 to
+ * access to clause 45)
+ * @bus: the target MII bus
+ * @prtad: MMD Address
+ * @devad: MMD DEVAD
+ * @addr: PHY address on the MII bus
+ *
+ * Description: Reads data from the MMD regisetrs of the
+ * phy addr. To read these register we have:
+ * 1) Write reg 13 // DEVAD
+ * 2) Write reg 14 // MMD Address
+ * 3) Write reg 13 // MMD Data Command for MMD DEVAD
+ * 3) Read  reg 14 // Read MMD data
+ */
+static int phy_read_mmd_indirect(struct mii_bus *bus, int prtad, int devad,
+				 int addr)
+{
+	u32 ret;
+
+	mmd_phy_indirect(bus, prtad, devad, addr);
+
+	/* Read the content of the MMD's selected register */
+	ret = bus->read(bus, addr, MII_MMD_DATA);
+	if (ret < 0)
+		return -EIO;
+
+	return ret;
+}
+
+/**
+ * phy_write_mmd_indirect - writes data to the MMC register (clause 22 to
+ * access to clause 45)
+ * @bus: the target MII bus
+ * @prtad: MMD Address
+ * @devad: MMD DEVAD
+ * @addr: PHY address on the MII bus
+ * @data: data to write in the MMD register
+ *
+ * Description: Reads data from the MMD regisetrs of the
+ * phy addr. To read these register we have:
+ * 1) Write reg 13 // DEVAD
+ * 2) Write reg 14 // MMD Address
+ * 3) Write reg 13 // MMD Data Command for MMD DEVAD
+ * 3) Write reg 14 // Write MMD data
+ */
+static void phy_write_mmd_indirect(struct mii_bus *bus, int prtad, int devad,
+				   int addr, u32 data)
+{
+	mmd_phy_indirect(bus, prtad, devad, addr);
+
+	/* Write the data into MMD's selected register */
+	bus->write(bus, addr, MII_MMD_DATA, data);
+}
+
+/* phy_check_eee
+ * @dev: device to probe and init
+ *
+ * Description: check if the Energy-Efficient Ethernet (EEE)
+ * is supported by looking at the MMD registers 3.20 and 3.60/61
+ */
+int phy_check_eee(struct phy_device *phydev)
+{
+	int ret = -EPROTONOSUPPORT;
+
+	/* According to 802.3az,the EEE is supported only in full duplex-mode.
+	 * Also EEE feature is active when core is operating with MII, GMII
+	 * or RGMII */
+	if ((phydev->duplex == DUPLEX_FULL) &&
+	    ((phydev->interface == PHY_INTERFACE_MODE_MII) ||
+	    (phydev->interface == PHY_INTERFACE_MODE_GMII) ||
+	    (phydev->interface == PHY_INTERFACE_MODE_RGMII))) {
+		int eee_cap, eee_link;
+
+		/* EEE ability must be supported in both local and remote
+		 * PHY devices. */
+		eee_cap = phy_read_mmd_indirect(phydev->bus, MDIO_AN_EEE_LPABLE,
+						MDIO_MMD_AN, phydev->addr);
+		if (eee_cap < 0)
+			return eee_cap;
+
+		eee_link = phy_read_mmd_indirect(phydev->bus, MDIO_PCS_EEE_ABLE,
+						 MDIO_MMD_PCS, phydev->addr);
+		if (eee_link < 0)
+			return eee_link;
+
+		if (eee_cap && eee_link) {
+			/* Configure the PHY to stop receiving xMII clock
+			 * while it is signaling LPI */
+			int pcs_ctrl = phy_read_mmd_indirect(phydev->bus,
+							     MDIO_CTRL1,
+							     MDIO_MMD_PCS,
+							     phydev->addr);
+			if (pcs_ctrl < 0)
+				return pcs_ctrl;
+
+			pcs_ctrl |= MDIO_PCS_CTRL1_CLKSTOP_EN;
+			phy_write_mmd_indirect(phydev->bus, MDIO_CTRL1,
+					       MDIO_MMD_PCS,
+					       phydev->addr, pcs_ctrl);
+
+			ret = 0; /* EEE supported */
+		}
+	}
+
+	return ret;
+}
+EXPORT_SYMBOL(phy_get_eee_err);
+
+/* phy_get_eee_err
+ * @dev: device to probe and init
+ *
+ * Description: it is to report the number of time where the PHY
+ * failed to complete its normal wake sequence.
+ */
+int phy_get_eee_err(struct phy_device *phydev)
+{
+	return phy_read_mmd_indirect(phydev->bus, MDIO_PCS_EEE_WK_ERR,
+				     MDIO_MMD_PCS, phydev->addr);
+
+}
+EXPORT_SYMBOL(phy_check_eee);
+
 /**
  * phy_probe - probe and init a PHY device
  * @dev: device to probe and init
diff --git a/include/linux/mdio.h b/include/linux/mdio.h
index dfb9479..49c9a13 100644
--- a/include/linux/mdio.h
+++ b/include/linux/mdio.h
@@ -43,7 +43,11 @@
 #define MDIO_PKGID2		15
 #define MDIO_AN_ADVERTISE	16	/* AN advertising (base page) */
 #define MDIO_AN_LPA		19	/* AN LP abilities (base page) */
+#define MDIO_PCS_EEE_ABLE	20	/* EEE Capability register */
+#define MDIO_PCS_EEE_WK_ERR	22	/* EEE wake error counter */
 #define MDIO_PHYXS_LNSTAT	24	/* PHY XGXS lane state */
+#define MDIO_AN_EEE_ADV		60	/* EEE advertisement */
+#define MDIO_AN_EEE_LPABLE	61	/* EEE link partner ability */
 
 /* Media-dependent registers. */
 #define MDIO_PMA_10GBT_SWAPPOL	130	/* 10GBASE-T pair swap & polarity */
@@ -56,7 +60,6 @@
 #define MDIO_PCS_10GBRT_STAT2	33	/* 10GBASE-R/-T PCS status 2 */
 #define MDIO_AN_10GBT_CTRL	32	/* 10GBASE-T auto-negotiation control */
 #define MDIO_AN_10GBT_STAT	33	/* 10GBASE-T auto-negotiation status */
-#define MDIO_AN_EEE_ADV		60	/* EEE advertisement */
 
 /* LASI (Link Alarm Status Interrupt) registers, defined by XENPAK MSA. */
 #define MDIO_PMA_LASI_RXCTRL	0x9000	/* RX_ALARM control */
@@ -82,6 +85,7 @@
 #define MDIO_AN_CTRL1_RESTART		BMCR_ANRESTART
 #define MDIO_AN_CTRL1_ENABLE		BMCR_ANENABLE
 #define MDIO_AN_CTRL1_XNP		0x2000	/* Enable extended next page */
+#define MDIO_PCS_CTRL1_CLKSTOP_EN	0x400	/* Stop the clock during LPI */
 
 /* 10 Gb/s */
 #define MDIO_CTRL1_SPEED10G		(MDIO_CTRL1_SPEEDSELEXT | 0x00)
diff --git a/include/linux/mii.h b/include/linux/mii.h
index 2783eca..35ddda1 100644
--- a/include/linux/mii.h
+++ b/include/linux/mii.h
@@ -21,6 +21,8 @@
 #define MII_EXPANSION		0x06	/* Expansion register          */
 #define MII_CTRL1000		0x09	/* 1000BASE-T control          */
 #define MII_STAT1000		0x0a	/* 1000BASE-T status           */
+#define	MII_MMD_CTRL		0x0d	/* MMD Access Control Register */
+#define	MII_MMD_DATA		0x0e	/* MMD Access Data Register */
 #define MII_ESTATUS		0x0f	/* Extended Status             */
 #define MII_DCOUNTER		0x12	/* Disconnect counter          */
 #define MII_FCSCOUNTER		0x13	/* False carrier counter       */
@@ -141,6 +143,15 @@
 #define FLOW_CTRL_TX		0x01
 #define FLOW_CTRL_RX		0x02
 
+/* MMD Access Control register fields */
+#define MII_MMD_CTRL_DEVAD_MASK			0x1f	/* Mask MMD DEVAD*/
+#define MII_MMD_CTRL_FUNC_ADDR			0x0000	/* Address */
+#define MII_MMD_CTRL_FUNC_DATA_NOINCR		0x4000	/* no post increment */
+#define MII_MMD_CTRL_FUNC_DATA_INCR_ON_RDWT	0x8000	/* post increment on
+							 * reads & writes */
+#define MII_MMD_CTRL_FUNC_DATA_INCR_ON_WT	0xC000	/* post increment on
+							 * writes only */
+
 /* This structure is used in all SIOCxMIIxxx ioctl calls */
 struct mii_ioctl_data {
 	__u16		phy_id;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index f092032..a5d7d0d 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -533,6 +533,9 @@ int phy_register_fixup_for_uid(u32 phy_uid, u32 phy_uid_mask,
 		int (*run)(struct phy_device *));
 int phy_scan_fixups(struct phy_device *phydev);
 
+int phy_check_eee(struct phy_device *phydev);
+int phy_get_eee_err(struct phy_device *phydev);
+
 int __init mdio_bus_init(void);
 void mdio_bus_exit(void);
 
-- 
1.7.4.4

[net-next 3/4 (V3)] stmmac: add the Energy Efficient Ethernet support

[Giuseppe CAVALLARO]

This patch adds the Energy Efficient Ethernet support.
Please see the driver's documentation for further
information about this support in the driver.

Signed-off-by: Rayagond Kokatanur <rayagond@vayavyalabs.com>
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
 drivers/net/ethernet/stmicro/stmmac/common.h       |   27 ++++-
 drivers/net/ethernet/stmicro/stmmac/dwmac1000.h    |   20 +++
 .../net/ethernet/stmicro/stmmac/dwmac1000_core.c   |  101 ++++++++++++-
 .../net/ethernet/stmicro/stmmac/dwmac100_core.c    |    4 +-
 drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h    |    1 +
 drivers/net/ethernet/stmicro/stmmac/stmmac.h       |    6 +
 .../net/ethernet/stmicro/stmmac/stmmac_ethtool.c   |   48 ++++++
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  |  156 +++++++++++++++++++-
 .../net/ethernet/stmicro/stmmac/stmmac_platform.c  |    2 +
 9 files changed, 347 insertions(+), 18 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
index 9e42b5d..fbeaed3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -95,6 +95,16 @@ struct stmmac_extra_stats {
 	unsigned long poll_n;
 	unsigned long sched_timer_n;
 	unsigned long normal_irq_n;
+	unsigned long mmc_tx_irq_n;
+	unsigned long mmc_rx_irq_n;
+	unsigned long mmc_rx_csum_offload_irq_n;
+	/* EEE */
+	unsigned long irq_receive_pmt_irq_n;
+	unsigned long irq_tx_path_in_lpi_mode_n;
+	unsigned long irq_tx_path_exit_lpi_mode_n;
+	unsigned long irq_rx_path_in_lpi_mode_n;
+	unsigned long irq_rx_path_exit_lpi_mode_n;
+	unsigned long phy_eee_wakeup_error_n;
 };
 
 /* CSR Frequency Access Defines*/
@@ -161,6 +171,17 @@ enum tx_dma_irq_status {
 	handle_tx_rx = 3,
 };
 
+enum core_specific_irq_mask {
+	core_mmc_tx_irq = 1,
+	core_mmc_rx_irq = 2,
+	core_mmc_rx_csum_offload_irq = 4,
+	core_irq_receive_pmt_irq = 8,
+	core_irq_tx_path_in_lpi_mode = 16,
+	core_irq_tx_path_exit_lpi_mode = 32,
+	core_irq_rx_path_in_lpi_mode = 64,
+	core_irq_rx_path_exit_lpi_mode = 128,
+};
+
 /* DMA HW capabilities */
 struct dma_features {
 	unsigned int mbps_10_100;
@@ -277,7 +298,7 @@ struct stmmac_ops {
 	/* Dump MAC registers */
 	void (*dump_regs) (void __iomem *ioaddr);
 	/* Handle extra events on specific interrupts hw dependent */
-	void (*host_irq_status) (void __iomem *ioaddr);
+	int (*host_irq_status) (void __iomem *ioaddr);
 	/* Multicast filter setting */
 	void (*set_filter) (struct net_device *dev);
 	/* Flow control setting */
@@ -290,6 +311,10 @@ struct stmmac_ops {
 			       unsigned int reg_n);
 	void (*get_umac_addr) (void __iomem *ioaddr, unsigned char *addr,
 			       unsigned int reg_n);
+	void (*set_eee_mode) (void __iomem *ioaddr);
+	void (*reset_eee_mode) (void __iomem *ioaddr);
+	void (*set_eee_timer) (void __iomem *ioaddr, int ls, int tw);
+	void (*set_eee_pls) (void __iomem *ioaddr, int link);
 };
 
 struct mac_link {
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h b/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
index 54339a7..3e4265d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
@@ -36,6 +36,7 @@
 
 #define GMAC_INT_STATUS		0x00000038	/* interrupt status register */
 enum dwmac1000_irq_status {
+	lpiis_irq = 0x400,
 	time_stamp_irq = 0x0200,
 	mmc_rx_csum_offload_irq = 0x0080,
 	mmc_tx_irq = 0x0040,
@@ -60,6 +61,25 @@ enum power_event {
 	power_down = 0x00000001,
 };
 
+/* Energy Efficient Ethernet (EEE)
+ *
+ * LPI status, timer and control register offset
+ */
+#define LPI_CTRL_STATUS	0x0030
+#define LPI_TIMER_CTRL	0x0034
+
+/* LPI control and status defines */
+#define LPI_CTRL_STATUS_LPITXA	0x00080000	/* Enable LPI TX Automate */
+#define LPI_CTRL_STATUS_PLSEN	0x00040000	/* Enable PHY Link Status */
+#define LPI_CTRL_STATUS_PLS	0x00020000	/* PHY Link Status */
+#define LPI_CTRL_STATUS_LPIEN	0x00010000	/* LPI Enable */
+#define LPI_CTRL_STATUS_RLPIST	0x00000200	/* Receive LPI state */
+#define LPI_CTRL_STATUS_TLPIST	0x00000100	/* Transmit LPI state */
+#define LPI_CTRL_STATUS_RLPIEX	0x00000008	/* Receive LPI Exit */
+#define LPI_CTRL_STATUS_RLPIEN	0x00000004	/* Receive LPI Entry */
+#define LPI_CTRL_STATUS_TLPIEX	0x00000002	/* Transmit LPI Exit */
+#define LPI_CTRL_STATUS_TLPIEN	0x00000001	/* Transmit LPI Entry */
+
 /* GMAC HW ADDR regs */
 #define GMAC_ADDR_HIGH(reg)		(0x00000040+(reg * 8))
 #define GMAC_ADDR_LOW(reg)		(0x00000044+(reg * 8))
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index e7cbcd9..1b3a344 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -187,26 +187,107 @@ static void dwmac1000_pmt(void __iomem *ioaddr, unsigned long mode)
 }
 
 
-static void dwmac1000_irq_status(void __iomem *ioaddr)
+static int dwmac1000_irq_status(void __iomem *ioaddr)
 {
 	u32 intr_status = readl(ioaddr + GMAC_INT_STATUS);
+	int status = 0;
 
 	/* Not used events (e.g. MMC interrupts) are not handled. */
-	if ((intr_status & mmc_tx_irq))
-		CHIP_DBG(KERN_DEBUG "GMAC: MMC tx interrupt: 0x%08x\n",
+	if ((intr_status & mmc_tx_irq)) {
+		CHIP_DBG(KERN_INFO "GMAC: MMC tx interrupt: 0x%08x\n",
 		    readl(ioaddr + GMAC_MMC_TX_INTR));
-	if (unlikely(intr_status & mmc_rx_irq))
-		CHIP_DBG(KERN_DEBUG "GMAC: MMC rx interrupt: 0x%08x\n",
+		status |= core_mmc_tx_irq;
+	}
+	if (unlikely(intr_status & mmc_rx_irq)) {
+		CHIP_DBG(KERN_INFO "GMAC: MMC rx interrupt: 0x%08x\n",
 		    readl(ioaddr + GMAC_MMC_RX_INTR));
-	if (unlikely(intr_status & mmc_rx_csum_offload_irq))
-		CHIP_DBG(KERN_DEBUG "GMAC: MMC rx csum offload: 0x%08x\n",
+		status |= core_mmc_rx_irq;
+	}
+	if (unlikely(intr_status & mmc_rx_csum_offload_irq)) {
+		CHIP_DBG(KERN_INFO "GMAC: MMC rx csum offload: 0x%08x\n",
 		    readl(ioaddr + GMAC_MMC_RX_CSUM_OFFLOAD));
+		status |= core_mmc_rx_csum_offload_irq;
+	}
 	if (unlikely(intr_status & pmt_irq)) {
-		CHIP_DBG(KERN_DEBUG "GMAC: received Magic frame\n");
+		CHIP_DBG(KERN_INFO "GMAC: received Magic frame\n");
 		/* clear the PMT bits 5 and 6 by reading the PMT
 		 * status register. */
 		readl(ioaddr + GMAC_PMT);
+		status |= core_irq_receive_pmt_irq;
 	}
+	/* MAC trx/rx EEE LPI entry/exit interrupts */
+	if (intr_status & lpiis_irq) {
+		/* Clean LPI interrupt by reading the Reg 12 */
+		u32 lpi_status = readl(ioaddr + LPI_CTRL_STATUS);
+
+		if (lpi_status & LPI_CTRL_STATUS_TLPIEN) {
+			CHIP_DBG(KERN_INFO "GMAC TX entered in LPI\n");
+			status |= core_irq_tx_path_in_lpi_mode;
+		}
+		if (lpi_status & LPI_CTRL_STATUS_TLPIEX) {
+			CHIP_DBG(KERN_INFO "GMAC TX exit from LPI\n");
+			status |= core_irq_tx_path_exit_lpi_mode;
+		}
+		if (lpi_status & LPI_CTRL_STATUS_RLPIEN) {
+			CHIP_DBG(KERN_INFO "GMAC RX entered in LPI\n");
+			status |= core_irq_rx_path_in_lpi_mode;
+		}
+		if (lpi_status & LPI_CTRL_STATUS_RLPIEX) {
+			CHIP_DBG(KERN_INFO "GMAC RX exit from LPI\n");
+			status |= core_irq_rx_path_exit_lpi_mode;
+		}
+	}
+
+	return status;
+}
+
+static void  dwmac1000_set_eee_mode(void __iomem *ioaddr)
+{
+	u32 value;
+
+	/* Enable the link status receive on RGMII, SGMII ore SMII
+	 * receive path and instruct the transmit to enter in LPI
+	 * state. */
+	value = readl(ioaddr + LPI_CTRL_STATUS);
+	value |= LPI_CTRL_STATUS_LPIEN | LPI_CTRL_STATUS_LPITXA;
+	writel(value, ioaddr + LPI_CTRL_STATUS);
+}
+
+static void  dwmac1000_reset_eee_mode(void __iomem *ioaddr)
+{
+	u32 value;
+
+	value = readl(ioaddr + LPI_CTRL_STATUS);
+	value &= ~(LPI_CTRL_STATUS_LPIEN | LPI_CTRL_STATUS_LPITXA);
+	writel(value, ioaddr + LPI_CTRL_STATUS);
+}
+
+static void  dwmac1000_set_eee_pls(void __iomem *ioaddr, int link)
+{
+	u32 value;
+
+	value = readl(ioaddr + LPI_CTRL_STATUS);
+
+	if (link)
+		value |= LPI_CTRL_STATUS_PLS;
+	else
+		value &= ~LPI_CTRL_STATUS_PLS;
+
+	writel(value, ioaddr + LPI_CTRL_STATUS);
+}
+
+static void  dwmac1000_set_eee_timer(void __iomem *ioaddr, int ls, int tw)
+{
+	int value = ((tw & 0xffff)) | ((ls & 0x7ff) << 16);
+
+	/* Program the timers in the LPI timer control register:
+	 * LS: minimum time (ms) for which the link
+	 *  status from PHY should be ok before transmitting
+	 *  the LPI pattern.
+	 * TW: minimum time (us) for which the core waits
+	 *  after it has stopped transmitting the LPI pattern.
+	 */
+	writel(value, ioaddr + LPI_TIMER_CTRL);
 }
 
 static const struct stmmac_ops dwmac1000_ops = {
@@ -219,6 +300,10 @@ static const struct stmmac_ops dwmac1000_ops = {
 	.pmt = dwmac1000_pmt,
 	.set_umac_addr = dwmac1000_set_umac_addr,
 	.get_umac_addr = dwmac1000_get_umac_addr,
+	.set_eee_mode =  dwmac1000_set_eee_mode,
+	.reset_eee_mode =  dwmac1000_reset_eee_mode,
+	.set_eee_timer =  dwmac1000_set_eee_timer,
+	.set_eee_pls =  dwmac1000_set_eee_pls,
 };
 
 struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
index efde50f..a566903 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
@@ -72,9 +72,9 @@ static int dwmac100_rx_ipc_enable(void __iomem *ioaddr)
 	return 0;
 }
 
-static void dwmac100_irq_status(void __iomem *ioaddr)
+static int dwmac100_irq_status(void __iomem *ioaddr)
 {
-	return;
+	return 0;
 }
 
 static void dwmac100_set_umac_addr(void __iomem *ioaddr, unsigned char *addr,
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h b/drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h
index 6e0360f..e678ce3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac_dma.h
@@ -70,6 +70,7 @@
 #define DMA_INTR_DEFAULT_MASK	(DMA_INTR_NORMAL | DMA_INTR_ABNORMAL)
 
 /* DMA Status register defines */
+#define DMA_STATUS_GLPII	0x40000000	/* GMAC LPI interrupt */
 #define DMA_STATUS_GPI		0x10000000	/* PMT interrupt */
 #define DMA_STATUS_GMI		0x08000000	/* MMC interrupt */
 #define DMA_STATUS_GLI		0x04000000	/* GMAC Line interface int */
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 9f2435c..04af6e4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -85,6 +85,10 @@ struct stmmac_priv {
 	struct clk *stmmac_clk;
 #endif
 	int clk_csr;
+	struct timer_list eee_ctrl_timer;
+	bool tx_path_in_lpi_mode;
+	bool eee_enabled;
+	int lpi_irq;
 };
 
 extern int phyaddr;
@@ -103,6 +107,8 @@ int stmmac_dvr_remove(struct net_device *ndev);
 struct stmmac_priv *stmmac_dvr_probe(struct device *device,
 				     struct plat_stmmacenet_data *plat_dat,
 				     void __iomem *addr);
+void stmmac_disable_eee_mode(struct stmmac_priv *priv);
+bool stmmac_eee_init(struct stmmac_priv *priv);
 
 #ifdef CONFIG_HAVE_CLK
 static inline int stmmac_clk_enable(struct stmmac_priv *priv)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index ce43184..0bf411f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -93,6 +93,16 @@ static const struct stmmac_stats stmmac_gstrings_stats[] = {
 	STMMAC_STAT(poll_n),
 	STMMAC_STAT(sched_timer_n),
 	STMMAC_STAT(normal_irq_n),
+	STMMAC_STAT(normal_irq_n),
+	STMMAC_STAT(mmc_tx_irq_n),
+	STMMAC_STAT(mmc_rx_irq_n),
+	STMMAC_STAT(mmc_rx_csum_offload_irq_n),
+	STMMAC_STAT(irq_receive_pmt_irq_n),
+	STMMAC_STAT(irq_tx_path_in_lpi_mode_n),
+	STMMAC_STAT(irq_tx_path_exit_lpi_mode_n),
+	STMMAC_STAT(irq_rx_path_in_lpi_mode_n),
+	STMMAC_STAT(irq_rx_path_exit_lpi_mode_n),
+	STMMAC_STAT(phy_eee_wakeup_error_n),
 };
 #define STMMAC_STATS_LEN ARRAY_SIZE(stmmac_gstrings_stats)
 
@@ -366,6 +376,11 @@ static void stmmac_get_ethtool_stats(struct net_device *dev,
 					     (*(u32 *)p);
 			}
 		}
+		if (priv->eee_enabled) {
+			int val = phy_get_eee_err(priv->phydev);
+			if (val)
+				priv->xstats.phy_eee_wakeup_error_n = val;
+		}
 	}
 	for (i = 0; i < STMMAC_STATS_LEN; i++) {
 		char *p = (char *)priv + stmmac_gstrings_stats[i].stat_offset;
@@ -464,6 +479,37 @@ static int stmmac_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
 	return 0;
 }
 
+static int stmmac_ethtool_op_get_eee(struct net_device *dev,
+				     struct ethtool_value *eee)
+{
+	struct stmmac_priv *priv = netdev_priv(dev);
+
+	if (!priv->dma_cap.eee)
+		return -EOPNOTSUPP;
+
+	eee->data = priv->eee_enabled;
+
+	return 0;
+}
+
+static int stmmac_ethtool_op_set_eee(struct net_device *dev,
+				     struct ethtool_value *eee)
+{
+	struct stmmac_priv *priv = netdev_priv(dev);
+
+	if ((!eee->data) && (priv->eee_enabled)) {
+		stmmac_disable_eee_mode(priv);
+		priv->eee_enabled = eee->data;
+	} else if ((eee->data) && (!priv->eee_enabled))
+		/* We are asking for enabling the EEE but this
+		 * has to be verified by invoking the eee_init function.
+		 * For this reason we cannot set eee_enabled to
+		 * eee->data, directly. */
+		priv->eee_enabled = stmmac_eee_init(priv);
+
+	return 0;
+}
+
 static const struct ethtool_ops stmmac_ethtool_ops = {
 	.begin = stmmac_check_if_running,
 	.get_drvinfo = stmmac_ethtool_getdrvinfo,
@@ -480,6 +526,8 @@ static const struct ethtool_ops stmmac_ethtool_ops = {
 	.get_strings = stmmac_get_strings,
 	.get_wol = stmmac_get_wol,
 	.set_wol = stmmac_set_wol,
+	.get_eee = stmmac_ethtool_op_get_eee,
+	.set_eee = stmmac_ethtool_op_set_eee,
 	.get_sset_count	= stmmac_get_sset_count,
 	.get_ts_info = ethtool_op_get_ts_info,
 };
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 90d5c4c..39928fe 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -133,6 +133,11 @@ static const u32 default_msg_level = (NETIF_MSG_DRV | NETIF_MSG_PROBE |
 				      NETIF_MSG_LINK | NETIF_MSG_IFUP |
 				      NETIF_MSG_IFDOWN | NETIF_MSG_TIMER);
 
+static int eee_timer = 1000;
+module_param(eee_timer, int, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(eee_timer, "LPI tx expiration time in msec");
+#define STMMAC_LPI_TIMER(x) (jiffies + msecs_to_jiffies(x))
+
 static irqreturn_t stmmac_interrupt(int irq, void *dev_id);
 
 #ifdef CONFIG_STMMAC_DEBUG_FS
@@ -226,6 +231,82 @@ static inline void stmmac_hw_fix_mac_speed(struct stmmac_priv *priv)
 					  phydev->speed);
 }
 
+static void stmmac_enable_eee_mode(struct stmmac_priv *priv)
+{
+	/* Check and enter in LPI mode */
+	if ((priv->dirty_tx == priv->cur_tx) &&
+	    (priv->tx_path_in_lpi_mode == false))
+		priv->hw->mac->set_eee_mode(priv->ioaddr);
+}
+
+void stmmac_disable_eee_mode(struct stmmac_priv *priv)
+{
+	/* Exit and disable EEE in case of we are are in LPI state. */
+	priv->hw->mac->reset_eee_mode(priv->ioaddr);
+	del_timer_sync(&priv->eee_ctrl_timer);
+	priv->tx_path_in_lpi_mode = false;
+}
+
+/**
+ * stmmac_eee_ctrl_timer
+ * @arg : data hook
+ * Description:
+ *  If there is no data transfer and if we are not in LPI state,
+ *  then MAC Transmitter can be moved to LPI state.
+ */
+static void stmmac_eee_ctrl_timer(unsigned long arg)
+{
+	struct stmmac_priv *priv = (struct stmmac_priv *)arg;
+
+	stmmac_enable_eee_mode(priv);
+	mod_timer(&priv->eee_ctrl_timer, STMMAC_LPI_TIMER(eee_timer));
+}
+
+/**
+ * stmmac_eee_init
+ * @priv: private device pointer
+ * Description:
+ *  If the EEE support has been enabled while configuring the driver,
+ *  if the GMAC actually supports the EEE (from the HW cap reg) and the
+ *  phy can also manage EEE, so enable the LPI state and start the timer
+ *  to verify if the tx path can enter in LPI state.
+ */
+bool stmmac_eee_init(struct stmmac_priv *priv)
+{
+	bool ret = false;
+
+	/* MAC core supports the EEE feature. */
+	if (priv->dma_cap.eee) {
+
+		/* Check if the PHY supports EEE*/
+		if (phy_check_eee(priv->phydev))
+			goto out;
+
+		init_timer(&priv->eee_ctrl_timer);
+		priv->eee_ctrl_timer.function = stmmac_eee_ctrl_timer;
+		priv->eee_ctrl_timer.data = (unsigned long)priv;
+		priv->eee_ctrl_timer.expires = STMMAC_LPI_TIMER(eee_timer);
+		add_timer(&priv->eee_ctrl_timer);
+
+		priv->hw->mac->set_eee_timer(priv->ioaddr, 0x3e8, 0);
+
+		pr_info("stmmac: Energy-Efficient Ethernet initialized\n");
+
+		ret = true;
+	}
+out:
+	return ret;
+}
+
+static void stmmac_eee_adjust(struct stmmac_priv *priv)
+{
+	/* When the EEE has been already initialised we have to
+	 * modify the PLS bit in the LPI ctrl & status reg according
+	 * to the PHY link status. For this reason. */
+	if (priv->eee_enabled)
+		priv->hw->mac->set_eee_pls(priv->ioaddr, priv->phydev->link);
+}
+
 /**
  * stmmac_adjust_link
  * @dev: net device structure
@@ -246,6 +327,7 @@ static void stmmac_adjust_link(struct net_device *dev)
 	    phydev->addr, phydev->link);
 
 	spin_lock_irqsave(&priv->lock, flags);
+
 	if (phydev->link) {
 		u32 ctrl = readl(priv->ioaddr + MAC_CTRL_REG);
 
@@ -312,6 +394,8 @@ static void stmmac_adjust_link(struct net_device *dev)
 	if (new_state && netif_msg_link(priv))
 		phy_print_status(phydev);
 
+	stmmac_eee_adjust(priv);
+
 	spin_unlock_irqrestore(&priv->lock, flags);
 
 	DBG(probe, DEBUG, "stmmac_adjust_link: exiting\n");
@@ -329,7 +413,7 @@ static int stmmac_init_phy(struct net_device *dev)
 {
 	struct stmmac_priv *priv = netdev_priv(dev);
 	struct phy_device *phydev;
-	char phy_id[MII_BUS_ID_SIZE + 3];
+	char phy_id_fmt[MII_BUS_ID_SIZE + 3];
 	char bus_id[MII_BUS_ID_SIZE];
 	int interface = priv->plat->interface;
 	priv->oldlink = 0;
@@ -343,11 +427,12 @@ static int stmmac_init_phy(struct net_device *dev)
 		snprintf(bus_id, MII_BUS_ID_SIZE, "stmmac-%x",
 				priv->plat->bus_id);
 
-	snprintf(phy_id, MII_BUS_ID_SIZE + 3, PHY_ID_FMT, bus_id,
+	snprintf(phy_id_fmt, MII_BUS_ID_SIZE + 3, PHY_ID_FMT, bus_id,
 		 priv->plat->phy_addr);
-	pr_debug("stmmac_init_phy:  trying to attach to %s\n", phy_id);
+	pr_debug("stmmac_init_phy:  trying to attach to %s\n", phy_id_fmt);
 
-	phydev = phy_connect(dev, phy_id, &stmmac_adjust_link, 0, interface);
+	phydev = phy_connect(dev, phy_id_fmt, &stmmac_adjust_link, 0,
+			     interface);
 
 	if (IS_ERR(phydev)) {
 		pr_err("%s: Could not attach to PHY\n", dev->name);
@@ -686,6 +771,11 @@ static void stmmac_tx(struct stmmac_priv *priv)
 		}
 		netif_tx_unlock(priv->dev);
 	}
+
+	if ((priv->eee_enabled) && (!priv->tx_path_in_lpi_mode)) {
+		stmmac_enable_eee_mode(priv);
+		mod_timer(&priv->eee_ctrl_timer, STMMAC_LPI_TIMER(eee_timer));
+	}
 	spin_unlock(&priv->tx_lock);
 }
 
@@ -1016,6 +1106,17 @@ static int stmmac_open(struct net_device *dev)
 		}
 	}
 
+	/* Request the IRQ lines */
+	if (priv->lpi_irq != -ENXIO) {
+		ret = request_irq(priv->lpi_irq, stmmac_interrupt, IRQF_SHARED,
+				  dev->name, dev);
+		if (unlikely(ret < 0)) {
+			pr_err("%s: ERROR: allocating the LPI IRQ %d (%d)\n",
+			       __func__, priv->lpi_irq, ret);
+			goto open_error_lpiirq;
+		}
+	}
+
 	/* Enable the MAC Rx/Tx */
 	stmmac_set_mac(priv->ioaddr, true);
 
@@ -1051,12 +1152,18 @@ static int stmmac_open(struct net_device *dev)
 	if (priv->phydev)
 		phy_start(priv->phydev);
 
+	priv->eee_enabled = stmmac_eee_init(priv);
+
 	napi_enable(&priv->napi);
 	skb_queue_head_init(&priv->rx_recycle);
 	netif_start_queue(dev);
 
 	return 0;
 
+open_error_lpiirq:
+	if (priv->wol_irq != dev->irq)
+		free_irq(priv->wol_irq, dev);
+
 open_error_wolirq:
 	free_irq(dev->irq, dev);
 
@@ -1082,6 +1189,9 @@ static int stmmac_release(struct net_device *dev)
 {
 	struct stmmac_priv *priv = netdev_priv(dev);
 
+	if (priv->eee_enabled)
+		del_timer_sync(&priv->eee_ctrl_timer);
+
 	/* Stop and disconnect the PHY */
 	if (priv->phydev) {
 		phy_stop(priv->phydev);
@@ -1104,6 +1214,8 @@ static int stmmac_release(struct net_device *dev)
 	free_irq(dev->irq, dev);
 	if (priv->wol_irq != dev->irq)
 		free_irq(priv->wol_irq, dev);
+	if (priv->lpi_irq != -ENXIO)
+		free_irq(priv->lpi_irq, dev);
 
 	/* Stop TX/RX DMA and clear the descriptors */
 	priv->hw->dma->stop_tx(priv->ioaddr);
@@ -1154,6 +1266,9 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	spin_lock(&priv->tx_lock);
 
+	if (priv->tx_path_in_lpi_mode)
+		stmmac_disable_eee_mode(priv);
+
 	entry = priv->cur_tx % txsize;
 
 #ifdef STMMAC_XMIT_DEBUG
@@ -1531,10 +1646,37 @@ static irqreturn_t stmmac_interrupt(int irq, void *dev_id)
 		return IRQ_NONE;
 	}
 
-	if (priv->plat->has_gmac)
-		/* To handle GMAC own interrupts */
-		priv->hw->mac->host_irq_status((void __iomem *) dev->base_addr);
+	/* To handle GMAC own interrupts */
+	if (priv->plat->has_gmac) {
+		int status = priv->hw->mac->host_irq_status((void __iomem *)
+							    dev->base_addr);
+		if (unlikely(status)) {
+			if (status & core_mmc_tx_irq)
+				priv->xstats.mmc_tx_irq_n++;
+			if (status & core_mmc_rx_irq)
+				priv->xstats.mmc_rx_irq_n++;
+			if (status & core_mmc_rx_csum_offload_irq)
+				priv->xstats.mmc_rx_csum_offload_irq_n++;
+			if (status & core_irq_receive_pmt_irq)
+				priv->xstats.irq_receive_pmt_irq_n++;
+
+			/* For LPI we need to save the tx status */
+			if (status & core_irq_tx_path_in_lpi_mode) {
+				priv->xstats.irq_tx_path_in_lpi_mode_n++;
+				priv->tx_path_in_lpi_mode = true;
+			}
+			if (status & core_irq_tx_path_exit_lpi_mode) {
+				priv->xstats.irq_tx_path_exit_lpi_mode_n++;
+				priv->tx_path_in_lpi_mode = false;
+			}
+			if (status & core_irq_rx_path_in_lpi_mode)
+				priv->xstats.irq_rx_path_in_lpi_mode_n++;
+			if (status & core_irq_rx_path_exit_lpi_mode)
+				priv->xstats.irq_rx_path_exit_lpi_mode_n++;
+		}
+	}
 
+	/* To handle DMA interrupts */
 	stmmac_dma_interrupt(priv);
 
 	return IRQ_HANDLED;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 116529a..06d699e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -157,6 +157,8 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
 	if (priv->wol_irq == -ENXIO)
 		priv->wol_irq = priv->dev->irq;
 
+	priv->lpi_irq = platform_get_irq_byname(pdev, "eth_lpi");
+
 	platform_set_drvdata(pdev, priv->dev);
 
 	pr_debug("STMMAC platform driver registration completed");
-- 
1.7.4.4

Re: [net-next 3/4 (V3)] stmmac: add the Energy Efficient Ethernet support

[David Miller]

From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Fri,  6 Apr 2012 11:29:17 +0200

> +static int stmmac_ethtool_op_set_eee(struct net_device *dev,
> +				     struct ethtool_value *eee)
> +{
> +	struct stmmac_priv *priv = netdev_priv(dev);
> +
> +	if ((!eee->data) && (priv->eee_enabled)) {
> +		stmmac_disable_eee_mode(priv);
> +		priv->eee_enabled = eee->data;
> +	} else if ((eee->data) && (!priv->eee_enabled))
> +		/* We are asking for enabling the EEE but this
> +		 * has to be verified by invoking the eee_init function.
> +		 * For this reason we cannot set eee_enabled to
> +		 * eee->data, directly. */
> +		priv->eee_enabled = stmmac_eee_init(priv);
> +
> +	return 0;

If stmmac_eee_init() determines that it cannot enable eee, you should
return an appropriate error code here so that ethtool can report that
fact.

Re: [net-next 3/4 (V3)] stmmac: add the Energy Efficient Ethernet support

[Giuseppe CAVALLARO]

On 4/12/2012 10:32 PM, David Miller wrote:
> From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
> Date: Fri,  6 Apr 2012 11:29:17 +0200
> 
>> +static int stmmac_ethtool_op_set_eee(struct net_device *dev,
>> +				     struct ethtool_value *eee)
>> +{
>> +	struct stmmac_priv *priv = netdev_priv(dev);
>> +
>> +	if ((!eee->data) && (priv->eee_enabled)) {
>> +		stmmac_disable_eee_mode(priv);
>> +		priv->eee_enabled = eee->data;
>> +	} else if ((eee->data) && (!priv->eee_enabled))
>> +		/* We are asking for enabling the EEE but this
>> +		 * has to be verified by invoking the eee_init function.
>> +		 * For this reason we cannot set eee_enabled to
>> +		 * eee->data, directly. */
>> +		priv->eee_enabled = stmmac_eee_init(priv);
>> +
>> +	return 0;
> 
> If stmmac_eee_init() determines that it cannot enable eee, you should
> return an appropriate error code here so that ethtool can report that
> fact.

Ok, thanks

peppe

[net-next 4/4 (V3)] stmmac: update the driver Documentation and add EEE

[Giuseppe CAVALLARO]

From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>

This patch updates the stmmac's documentation adding
some missing files in the secstion to describe the
driver's structure. Also the patch adds a new section
for the EEE support.

Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
 Documentation/networking/stmmac.txt |   36 +++++++++++++++++++++++++++++-----
 1 files changed, 30 insertions(+), 6 deletions(-)

diff --git a/Documentation/networking/stmmac.txt b/Documentation/networking/stmmac.txt
index ab1e8d7..1cc8b75 100644
--- a/Documentation/networking/stmmac.txt
+++ b/Documentation/networking/stmmac.txt
@@ -251,9 +251,11 @@ reset procedure etc).
  o Makefile
  o stmmac_main.c: main network device driver;
  o stmmac_mdio.c: mdio functions;
+ o stmmac_pci: PCI driver;
+ o stmmac_platform.c: platform driver
  o stmmac_ethtool.c: ethtool support;
  o stmmac_timer.[ch]: timer code used for mitigating the driver dma interrupts
-		      Only tested on ST40 platforms based.
+		      (only tested on ST40 platforms based);
  o stmmac.h: private driver structure;
  o common.h: common definitions and VFTs;
  o descs.h: descriptor structure definitions;
@@ -263,9 +265,11 @@ reset procedure etc).
  o dwmac100_core: MAC 100 core and dma code;
  o dwmac100_dma.c: dma funtions for the MAC chip;
  o dwmac1000.h: specific header file for the MAC;
- o dwmac_lib.c: generic DMA functions shared among chips
- o enh_desc.c: functions for handling enhanced descriptors
- o norm_desc.c: functions for handling normal descriptors
+ o dwmac_lib.c: generic DMA functions shared among chips;
+ o enh_desc.c: functions for handling enhanced descriptors;
+ o norm_desc.c: functions for handling normal descriptors;
+ o chain_mode.c/ring_mode.c:: functions to manage RING/CHAINED modes;
+ o mmc_core.c/mmc.h: Management MAC Counters;
 
 5) Debug Information
 
@@ -298,7 +302,27 @@ All these are only useful during the developing stage
 and should never enabled inside the code for general usage.
 In fact, these can generate an huge amount of debug messages.
 
-6) TODO:
+6) Energy Efficient Ethernet
+
+Energy Efficient Ethernet(EEE) enables IEEE 802.3 MAC sublayer along
+with a family of Physical layer to operate in the Low power Idle(LPI)
+mode. The EEE mode supports the IEEE 802.3 MAC operation at 100Mbps,
+1000Mbps & 10Gbps.
+
+The LPI mode allows power saving by switching off parts of the
+communication device functionality when there is no data to be
+transmitted & received. The system on both the side of the link can
+disable some functionalities & save power during the period of low-link
+utilization. The MAC controls whether the system should enter or exit
+the LPI mode & communicate this to PHY.
+
+As soon as the interface is opened, the driver verifies if the EEE can
+be supported. This is done by looking at both the DMA HW capability
+register and the PHY devices MCD registers.
+To enter in Tx LPI mode the driver needs to have a software timer
+that enable and disable the LPI mode when there is nothing to be
+transmitted.
+
+7) TODO:
  o XGMAC is not supported.
- o Add the EEE - Energy Efficient Ethernet
  o Add the PTP - precision time protocol
-- 
1.7.4.4

[PATCH] ethtool: add the EEE option

[Giuseppe CAVALLARO]

This patch adds a new option to enable/disable the
Energy Efficient Ethernet support: below some example:

bash-3.00# ethtool -s eth0 eee on
stmmac: Energy-Efficient Ethernet initialized

bash-3.00# ./ethtool eth0
Settings for eth0:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
[snip]
	Wake-on: d
	Current message level: 0x0000003f (63)
			       drv probe link timer ifdown ifup
	Link detected: yes
	Energy-Efficient Ethernet: Enabled

Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
 ethtool-copy.h |    3 +++
 ethtool.c      |   45 ++++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 47 insertions(+), 1 deletions(-)

diff --git a/ethtool-copy.h b/ethtool-copy.h
index d904c1a..e17ae37 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -40,6 +40,7 @@ struct ethtool_cmd {
 	__u8	eth_tp_mdix;
 	__u8	reserved2;
 	__u32	lp_advertising;	/* Features the link partner advertises */
+	__u32	eee;		/* Energy-Efficient Etehrnet */
 	__u32	reserved[2];
 };
 
@@ -786,6 +787,8 @@ enum ethtool_sfeatures_retval_bits {
 #define ETHTOOL_SET_DUMP	0x0000003e /* Set dump settings */
 #define ETHTOOL_GET_DUMP_FLAG	0x0000003f /* Get dump settings */
 #define ETHTOOL_GET_DUMP_DATA	0x00000040 /* Get dump data */
+#define ETHTOOL_GEEE		0x00000041 /* Get EEE */
+#define ETHTOOL_SEEE		0x00000042 /* Set EEE */
 
 /* compatibility with older code */
 #define SPARC_ETH_GSET		ETHTOOL_GSET
diff --git a/ethtool.c b/ethtool.c
index d0cc7d4..9e63973 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -1840,6 +1840,18 @@ static int do_gset(struct cmd_context *ctx)
 	} else if (errno != EOPNOTSUPP) {
 		perror("Cannot get link status");
 	}
+	edata.cmd = ETHTOOL_GEEE;
+	err = send_ioctl(ctx, &edata);
+	if (err == 0) {
+		fprintf(stdout, "	Energy-Efficient Ethernet: %s\n",
+			edata.data ? "enabled" : "disabled");
+		allfail = 0;
+	} else if (errno != EOPNOTSUPP) {
+		perror("Cannot get EEE feature");
+	} else if (errno == EOPNOTSUPP) {
+		fprintf(stdout, "	Energy-Efficient Ethernet:"
+				" not supported\n");
+	}
 
 	if (allfail) {
 		fprintf(stdout, "No data available\n");
@@ -1857,6 +1869,8 @@ static int do_sset(struct cmd_context *ctx)
 	int phyad_wanted = -1;
 	int xcvr_wanted = -1;
 	int advertising_wanted = -1;
+	int eee_wanted = -1;
+	int eee_changed = 0;
 	int gset_changed = 0; /* did anything in GSET change? */
 	u32 wol_wanted = 0;
 	int wol_change = 0;
@@ -1983,6 +1997,17 @@ static int do_sset(struct cmd_context *ctx)
 					ARRAY_SIZE(cmdline_msglvl));
 				break;
 			}
+		} else if (!strcmp(argp[i], "eee")) {
+			eee_changed = 1;
+			i++;
+			if (i >= argc)
+				exit_bad_args();
+			if (!strcmp(argp[i], "on"))
+				eee_wanted = 1;
+			else if (!strcmp(argp[i], "off"))
+				eee_wanted = 0;
+			else
+				exit_bad_args();
 		} else {
 			exit_bad_args();
 		}
@@ -2129,6 +2154,23 @@ static int do_sset(struct cmd_context *ctx)
 		}
 	}
 
+	if (eee_changed) {
+		struct ethtool_value edata;
+
+		edata.cmd = ETHTOOL_GEEE;
+		err = send_ioctl(ctx, &edata);
+		if (err < 0)
+			perror("Cannot get current EEE settings");
+		else {
+			edata.cmd = ETHTOOL_SEEE;
+			edata.data = eee_wanted;
+			err = send_ioctl(ctx, &edata);
+			if (err < 0)
+				fprintf(stderr, "Cannot turn %s the EEE",
+					(eee_wanted ? "on" : "off"));
+		}
+	}
+
 	if (msglvl_changed) {
 		struct ethtool_value edata;
 
@@ -3129,7 +3171,8 @@ static const struct option {
 	  "		[ xcvr internal|external ]\n"
 	  "		[ wol p|u|m|b|a|g|s|d... ]\n"
 	  "		[ sopass %x:%x:%x:%x:%x:%x ]\n"
-	  "		[ msglvl %d | msglvl type on|off ... ]\n" },
+	  "		[ msglvl %d | msglvl type on|off ]\n"
+	  "		[ eee on|off ... ]\n" },
 	{ "-a|--show-pause", 1, do_gpause, "Show pause options" },
 	{ "-A|--pause", 1, do_spause, "Set pause options",
 	  "		[ autoneg on|off ]\n"
-- 
1.7.4.4