Re: [PATCH] net: stmicro: fix LS field mask in EEE configuration

[Rayagond Kokatanur]

Acked-by:Rayagond Kokatanur <rayag...@vayavyalabs.com>

On Fri, Jan 20, 2017 at 9:30 PM, Joao Pinto <joao.pi...@synopsys.com> wrote:
> This patch fixes the LS mask when setting EEE timer.
> LS field is 10 bits long and not 11 as currently.
>
> Signed-off-by: Joao Pinto <jpi...@synopsys.com>
> Reported-By: Rayagond Kokatanur <rayag...@vayavyalabs.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c 
> b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> index 834f40f..202216c 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> @@ -184,7 +184,7 @@ static void dwmac4_set_eee_pls(struct mac_device_info 
> *hw, int link)
>  static void dwmac4_set_eee_timer(struct mac_device_info *hw, int ls, int tw)
>  {
> void __iomem *ioaddr = hw->pcsr;
> -   int value = ((tw & 0x)) | ((ls & 0x7ff) << 16);
> +   int value = ((tw & 0x)) | ((ls & 0x3ff) << 16);
>
> /* Program the timers in the LPI timer control register:
>  * LS: minimum time (ms) for which the link
> --
> 2.9.3
>



-- 
wwr
Rayagond

Re: [PATCH] stmmac: adding EEE to GMAC4

[Rayagond Kokatanur]

On Thu, Dec 29, 2016 at 10:40 PM, Joao Pinto  wrote:
> This patch adds Energy Efficiency Ethernet to GMAC4.
>
> Signed-off-by: Joao Pinto 
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac4.h  | 12 +
>  drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 59 
> +++
>  2 files changed, 71 insertions(+)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h 
> b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
> index b524598..73d1dab 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
> @@ -90,6 +90,18 @@ enum power_event {
> power_down = 0x0001,
>  };
>
> +/* Energy Efficient Ethernet (EEE) for GMAC4
> + *
> + * LPI status, timer and control register offset
> + */
> +#define GMAC4_LPI_CTRL_STATUS  0xd0
> +#define GMAC4_LPI_TIMER_CTRL   0xd4
> +
> +/* LPI control and status defines */
> +#define GMAC4_LPI_CTRL_STATUS_LPITXA   BIT(19) /* Enable LPI TX Automate */
> +#define GMAC4_LPI_CTRL_STATUS_PLS  BIT(17) /* PHY Link Status */
> +#define GMAC4_LPI_CTRL_STATUS_LPIENBIT(16) /* LPI Enable */
> +
>  /* MAC Debug bitmap */
>  #define GMAC_DEBUG_TFCSTS_MASK GENMASK(18, 17)
>  #define GMAC_DEBUG_TFCSTS_SHIFT17
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c 
> b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> index ecfbf57..02eab79 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> @@ -137,6 +137,61 @@ static void dwmac4_get_umac_addr(struct mac_device_info 
> *hw,
>GMAC_ADDR_LOW(reg_n));
>  }
>
> +static void dwmac4_set_eee_mode(struct mac_device_info *hw)
> +{
> +   void __iomem *ioaddr = hw->pcsr;
> +   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 + GMAC4_LPI_CTRL_STATUS);
> +   value |= GMAC4_LPI_CTRL_STATUS_LPIEN | GMAC4_LPI_CTRL_STATUS_LPITXA;
> +
> +   writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
> +}
> +
> +static void dwmac4_reset_eee_mode(struct mac_device_info *hw)
> +{
> +   void __iomem *ioaddr = hw->pcsr;
> +   u32 value;
> +
> +   value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
> +   value &= ~(GMAC4_LPI_CTRL_STATUS_LPIEN | 
> GMAC4_LPI_CTRL_STATUS_LPITXA);
> +   writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
> +}
> +
> +static void dwmac4_set_eee_pls(struct mac_device_info *hw, int link)
> +{
> +   void __iomem *ioaddr = hw->pcsr;
> +   u32 value;
> +
> +   value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
> +
> +   if (link)
> +   value |= GMAC4_LPI_CTRL_STATUS_PLS;
> +   else
> +   value &= ~GMAC4_LPI_CTRL_STATUS_PLS;
> +
> +   writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
> +}
> +
> +static void dwmac4_set_eee_timer(struct mac_device_info *hw, int ls, int tw)
> +{
> +   void __iomem *ioaddr = hw->pcsr;
> +   int value = ((tw & 0x)) | ((ls & 0x7ff) << 16);

If I am not wrong, LS field is 10 bits wide not 11 bits, hence we
should AND 0x3ff.

int value = ((tw & 0x)) | ((ls & 0x3ff) << 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 + GMAC4_LPI_TIMER_CTRL);
> +}
> +
>  static void dwmac4_set_filter(struct mac_device_info *hw,
>   struct net_device *dev)
>  {
> @@ -410,6 +465,10 @@ static const struct stmmac_ops dwmac4_ops = {
> .pmt = dwmac4_pmt,
> .set_umac_addr = dwmac4_set_umac_addr,
> .get_umac_addr = dwmac4_get_umac_addr,
> +   .set_eee_mode = dwmac4_set_eee_mode,
> +   .reset_eee_mode = dwmac4_reset_eee_mode,
> +   .set_eee_timer = dwmac4_set_eee_timer,
> +   .set_eee_pls = dwmac4_set_eee_pls,
> .pcs_ctrl_ane = dwmac4_ctrl_ane,
> .pcs_rane = dwmac4_rane,
> .pcs_get_adv_lp = dwmac4_get_adv_lp,
> --
> 2.9.3
>



-- 
wwr
Rayagond

Re: [PATCH] net: ethernet: stmmac: add ARP management

[Rayagond Kokatanur]

On Tue, Jan 17, 2017 at 10:26 PM, Christophe Roullier
 wrote:
>
> DWC_ether_qos supports the Address Recognition
> Protocol (ARP) Offload for IPv4 packets. This feature
> allows the processing of the IPv4 ARP request packet
> in the receive path and generating corresponding ARP
> response packet in the transmit path. DWC_ether_qos
> generates the ARP reply packets for appropriate ARP
> request packets.
>
> Signed-off-by: Christophe Roullier 
> ---
>  drivers/net/ethernet/stmicro/stmmac/common.h   |  4 
>  drivers/net/ethernet/stmicro/stmmac/dwmac4.h   |  3 +++
>  drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c  | 15 ++
>  drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c   | 23 
> ++
>  drivers/net/ethernet/stmicro/stmmac/stmmac.h   |  1 +
>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  | 13 
>  .../net/ethernet/stmicro/stmmac/stmmac_platform.c  |  1 +
>  include/linux/stmmac.h |  1 +
>  8 files changed, 61 insertions(+)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h 
> b/drivers/net/ethernet/stmicro/stmmac/common.h
> index 75e2666..1d1c815 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/common.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/common.h
> @@ -306,6 +306,7 @@ struct dma_features {
> unsigned int pmt_remote_wake_up;
> unsigned int pmt_magic_frame;
> unsigned int rmon;
> +   unsigned int arpoffsel;
> /* IEEE 1588-2002 */
> unsigned int time_stamp;
> /* IEEE 1588-2008 */
> @@ -447,6 +448,7 @@ struct stmmac_dma_ops {
> void (*set_rx_tail_ptr)(void __iomem *ioaddr, u32 tail_ptr, u32 chan);
> void (*set_tx_tail_ptr)(void __iomem *ioaddr, u32 tail_ptr, u32 chan);
> void (*enable_tso)(void __iomem *ioaddr, bool en, u32 chan);
> +   void (*set_arp_addr)(void __iomem *ioaddr, bool en, u32 addr);
>  };
>
>  struct mac_device_info;
> @@ -459,6 +461,8 @@ struct stmmac_ops {
> int (*rx_ipc)(struct mac_device_info *hw);
> /* Enable RX Queues */
> void (*rx_queue_enable)(struct mac_device_info *hw, u32 queue);
> +   /* Enable and verify that the ARP feature is supported */
> +   int (*arp_en)(struct mac_device_info *hw);
> /* Dump MAC registers */
> void (*dump_regs)(struct mac_device_info *hw);
> /* Handle extra events on specific interrupts hw dependent */
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h 
> b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
> index db45134..d1e2e37 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
> @@ -35,6 +35,7 @@
>  #define GMAC_HW_FEATURE2   0x0124
>  #define GMAC_MDIO_ADDR 0x0200
>  #define GMAC_MDIO_DATA 0x0204
> +#define GMAC_ARP_ADDR  0x0210
>  #define GMAC_ADDR_HIGH(reg)(0x300 + reg * 8)
>  #define GMAC_ADDR_LOW(reg) (0x304 + reg * 8)
>
> @@ -116,6 +117,7 @@ enum power_event {
>  #define GMAC_DEBUG_RPESTS  BIT(0)
>
>  /* MAC config */
> +#define GMAC_CONFIG_ARPEN  BIT(31)
>  #define GMAC_CONFIG_IPCBIT(27)
>  #define GMAC_CONFIG_2K BIT(22)
>  #define GMAC_CONFIG_ACSBIT(20)
> @@ -135,6 +137,7 @@ enum power_event {
>  #define GMAC_HW_FEAT_TXCOSEL   BIT(14)
>  #define GMAC_HW_FEAT_EEESELBIT(13)
>  #define GMAC_HW_FEAT_TSSEL BIT(12)
> +#define GMAC_HW_FEAT_ARPOFFSEL BIT(9)
>  #define GMAC_HW_FEAT_MMCSELBIT(8)
>  #define GMAC_HW_FEAT_MGKSELBIT(7)
>  #define GMAC_HW_FEAT_RWKSELBIT(6)
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c 
> b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> index 834f40f..33d0fb3 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> @@ -102,6 +102,20 @@ static int dwmac4_rx_ipc_enable(struct mac_device_info 
> *hw)
> return !!(value & GMAC_CONFIG_IPC);
>  }
>
> +static int dwmac4_arp_enable(struct mac_device_info *hw)
> +{
> +   void __iomem *ioaddr = hw->pcsr;
> +   u32 value = readl(ioaddr + GMAC_CONFIG);
> +
> +   value |= GMAC_CONFIG_ARPEN;
> +
> +   writel(value, ioaddr + GMAC_CONFIG);
> +
> +   value = readl(ioaddr + GMAC_CONFIG);
> +
> +   return !!(value & GMAC_CONFIG_ARPEN);
> +}
> +
>  static void dwmac4_pmt(struct mac_device_info *hw, unsigned long mode)
>  {
> void __iomem *ioaddr = hw->pcsr;
> @@ -463,6 +477,7 @@ static void dwmac4_debug(void __iomem *ioaddr, struct 
> stmmac_extra_stats *x)
> .core_init = dwmac4_core_init,
> .rx_ipc = dwmac4_rx_ipc_enable,
> .rx_queue_enable = dwmac4_rx_queue_enable,
> +   .arp_en = dwmac4_arp_enable,
> 

[PATCH] net:ethernet:samsung:initialize cur_rx_qnum

[Rayagond Kokatanur]

This patch initialize the cur_rx_qnum upon occurence of rx interrupt,
without this initialization driver will not work with multiple rx queues 
configurations.

NOTE: This patch is not tested on actual hw.
---
 drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c 
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
index ea44a24..580a1a4 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
@@ -1681,6 +1681,7 @@ static irqreturn_t sxgbe_rx_interrupt(int irq, void 
*dev_id)
struct sxgbe_rx_queue *rxq = (struct sxgbe_rx_queue *)dev_id;
struct sxgbe_priv_data *priv = rxq->priv_ptr;
 
+   priv->cur_rx_qnum = rxq->queue_no;
/* get the channel status */
status = priv->hw->dma->rx_dma_int_status(priv->ioaddr, rxq->queue_no,
  >xstats);
-- 
1.9.1

Re: Synopsys Ethernet QoS Driver

[Rayagond Kokatanur]

On Sat, Nov 19, 2016 at 7:26 PM, Rabin Vincent  wrote:
> On Fri, Nov 18, 2016 at 02:20:27PM +, Joao Pinto wrote:
>> For now we are interesting in improving the synopsys QoS driver under
>> /nect/ethernet/synopsys. For now the driver structure consists of a single 
>> file
>> called dwc_eth_qos.c, containing synopsys ethernet qos common ops and 
>> platform
>> related stuff.
>>
>> Our strategy would be:
>>
>> a) Implement a platform glue driver (dwc_eth_qos_pltfm.c)
>> b) Implement a pci glue driver (dwc_eth_qos_pci.c)
>> c) Implement a "core driver" (dwc_eth_qos.c) that would only have Ethernet 
>> QoS
>> related stuff to be reused by the platform / pci drivers
>> d) Add a set of features to the "core driver" that we have available 
>> internally
>
> Note that there are actually two drivers in mainline for this hardware:
>
>  drivers/net/ethernet/synopsis/
>  drivers/net/ethernet/stmicro/stmmac/

Yes the later driver (drivers/net/ethernet/stmicro/stmmac/) supports
both 3.x and 4.x. It has glue layer for pci, platform, core etc,
please refer this driver once before you start.

You can start adding missing feature of 4.x in stmmac driver.

>
> (See http://lists.openwall.net/netdev/2016/02/29/127)
>
> The former only supports 4.x of the hardware.
>
> The later supports 4.x and 3.x and already has a platform glue driver
> with support for several platforms, a PCI glue driver, and a core driver
> with several features not present in the former (for example: TX/RX
> interrupt coalescing, EEE, PTP).
>
> Have you evaluated both drivers?  Why have you decided to work on the
> former rather than the latter?



-- 
wwr
Rayagond

Re: [PATCH (net.git) 2/3] stmmac: fix PTP support for GMAC4

[Rayagond Kokatanur]

On Wed, Nov 2, 2016 at 12:04 PM, Giuseppe CAVALLARO
<peppe.cavall...@st.com> wrote:
> Hello Rayagond
>
> if patches are ok, can we consider you Acked-by ?
Yes.

>
> Thx
> Peppe
>
>
> On 10/27/2016 12:51 PM, Rayagond Kokatanur wrote:
>>
>> On Thu, Oct 27, 2016 at 4:02 PM, Giuseppe CAVALLARO
>> <peppe.cavall...@st.com> wrote:
>>>
>>> Hello Rayagond !
>>>
>>> On 10/27/2016 12:25 PM, Rayagond Kokatanur wrote:
>>>>>
>>>>>
>>>>> +static int dwmac4_wrback_get_rx_timestamp_status(void *desc, u32 ats)
>>>>>>
>>>>>>  {
>>>>>> struct dma_desc *p = (struct dma_desc *)desc;
>>>>>> +   int ret = -EINVAL;
>>>>>> +
>>>>>> +   /* Get the status from normal w/b descriptor */
>>>>>> +   if (likely(p->des3 & TDES3_RS1V)) {
>>>>>> +   if (likely(p->des1 & RDES1_TIMESTAMP_AVAILABLE)) {
>>>>>> +   int i = 0;
>>>>>> +
>>>>>> +   /* Check if timestamp is OK from context
>>>>>> descriptor */
>>>>>> +   do {
>>>>>> +   ret = dwmac4_rx_check_timestamp(desc);
>>>>
>>>>
>>>> Here, "desc" is not pointing to next descriptor (ie context
>>>> descriptor). Driver should check the context descriptor.
>>>
>>>
>>>
>>> you are right and this is done by the caller:  stmmac_get_rx_hwtstamp
>>
>>
>> Yes.
>>
>>>
>>> Cheers
>>> peppe
>>>
>>
>>
>>
>



-- 
wwr
Rayagond

Re: [PATCH (net.git) 0/3] stmmac: fix PTP support

[Rayagond Kokatanur]

On Wed, Oct 26, 2016 at 2:28 PM, Richard Cochran
<richardcoch...@gmail.com> wrote:
> On Wed, Oct 26, 2016 at 08:56:01AM +0200, Giuseppe Cavallaro wrote:
>> This subset of patches aim to fix the PTP support
>> for the stmmac and especially for 4.x chip series.
>> While setting PTP on an ST box with 4.00a Ethernet
>> core, the kernel panics due to a broken settings
>> of the descriptors. The patches review the
>> register configuration, the algo used for configuring
>> the protocol, the way to get the timestamp inside
>> the RX/TX descriptors and, in the end, the statistics
>> displayed by ethtool.
>>
>> Giuseppe Cavallaro (3):
>>   stmmac: update the PTP header file
>>   stmmac: fix PTP support for GMAC4
>>   stmmac: fix PTP type ethtool stats
>
> Acked-by: Richard Cochran <richardcoch...@gmail.com>

Acked-by: Rayagond Kokatanur <rayag...@vayavyalabs.com>



-- 
wwr
Rayagond

Re: [PATCH (net.git) 2/3] stmmac: fix PTP support for GMAC4

[Rayagond Kokatanur]

On Thu, Oct 27, 2016 at 4:02 PM, Giuseppe CAVALLARO
<peppe.cavall...@st.com> wrote:
> Hello Rayagond !
>
> On 10/27/2016 12:25 PM, Rayagond Kokatanur wrote:
>>>
>>> +static int dwmac4_wrback_get_rx_timestamp_status(void *desc, u32 ats)
>>> >  {
>>> > struct dma_desc *p = (struct dma_desc *)desc;
>>> > +   int ret = -EINVAL;
>>> > +
>>> > +   /* Get the status from normal w/b descriptor */
>>> > +   if (likely(p->des3 & TDES3_RS1V)) {
>>> > +   if (likely(p->des1 & RDES1_TIMESTAMP_AVAILABLE)) {
>>> > +   int i = 0;
>>> > +
>>> > +   /* Check if timestamp is OK from context
>>> > descriptor */
>>> > +   do {
>>> > +   ret = dwmac4_rx_check_timestamp(desc);
>>
>> Here, "desc" is not pointing to next descriptor (ie context
>> descriptor). Driver should check the context descriptor.
>
>
> you are right and this is done by the caller:  stmmac_get_rx_hwtstamp

Yes.

>
> Cheers
> peppe
>



-- 
wwr
Rayagond

Re: [PATCH (net.git) 2/3] stmmac: fix PTP support for GMAC4

[Rayagond Kokatanur]

Hi Giuseppe,

On Wed, Oct 26, 2016 at 12:26 PM, Giuseppe Cavallaro
<peppe.cavall...@st.com> wrote:
> Due to bad management of the descriptors, when use ptp4l,
> kernel panics as shown below:
> ---
>  Unable to handle kernel NULL pointer dereference at virtual
>  address 01ac
>  ...
>  Internal error: Oops: 17 [#1] SMP ARM
>  ...
>  Hardware name: STi SoC with Flattened Device Tree
>  task: c0c05e80 task.stack: c0c0
>  PC is at dwmac4_wrback_get_tx_timestamp_status+0x0/0xc
>  LR is at stmmac_tx_clean+0x2f8/0x4d4
> ---
>
> In case of GMAC4 the extended descriptor pointers were
> used for getting the timestamp. These are NULL for this HW,
> and the normal ones must be used.
>
> The PTP also had problems on this chip due to the bad
> register management and issues on the algo adopted to
> setup the PTP and getting the timestamp values from the
> descriptors.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavall...@st.com>
> Cc: Alexandre TORGUE <alexandre.tor...@st.com>
> Cc: Rayagond Kokatanur <rayag...@vayavyalabs.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/common.h   |  5 +-
>  drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c | 68 ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.h |  4 +
>  drivers/net/ethernet/stmicro/stmmac/stmmac.h   |  1 +
>  .../net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c  | 43 --
>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  | 97 
> +++---
>  drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c   |  9 +-
>  7 files changed, 154 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h 
> b/drivers/net/ethernet/stmicro/stmmac/common.h
> index d3292c4..6fc214c 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/common.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/common.h
> @@ -482,11 +482,12 @@ struct stmmac_ops {
>  /* PTP and HW Timer helpers */
>  struct stmmac_hwtimestamp {
> void (*config_hw_tstamping) (void __iomem *ioaddr, u32 data);
> -   u32 (*config_sub_second_increment) (void __iomem *ioaddr, u32 
> clk_rate);
> +   u32 (*config_sub_second_increment)(void __iomem *ioaddr, u32 
> ptp_clock,
> +  int gmac4);
> int (*init_systime) (void __iomem *ioaddr, u32 sec, u32 nsec);
> int (*config_addend) (void __iomem *ioaddr, u32 addend);
> int (*adjust_systime) (void __iomem *ioaddr, u32 sec, u32 nsec,
> -  int add_sub);
> +  int add_sub, int gmac4);
>  u64(*get_systime) (void __iomem *ioaddr);
>  };
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c 
> b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
> index a1b17cd..2ef2f0c 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
> @@ -204,14 +204,18 @@ static void dwmac4_rd_enable_tx_timestamp(struct 
> dma_desc *p)
>
>  static int dwmac4_wrback_get_tx_timestamp_status(struct dma_desc *p)
>  {
> -   return (p->des3 & TDES3_TIMESTAMP_STATUS)
> -   >> TDES3_TIMESTAMP_STATUS_SHIFT;
> +   /* Context type from W/B descriptor must be zero */
> +   if (p->des3 & TDES3_CONTEXT_TYPE)
> +   return -EINVAL;
> +
> +   /* Tx Timestamp Status is 1 so des0 and des1'll have valid values */
> +   if (p->des3 & TDES3_TIMESTAMP_STATUS)
> +   return 0;
> +
> +   return 1;
>  }
>
> -/*  NOTE: For RX CTX bit has to be checked before
> - *  HAVE a specific function for TX and another one for RX
> - */
> -static u64 dwmac4_wrback_get_timestamp(void *desc, u32 ats)
> +static inline u64 dwmac4_get_timestamp(void *desc, u32 ats)
>  {
> struct dma_desc *p = (struct dma_desc *)desc;
> u64 ns;
> @@ -223,12 +227,54 @@ static u64 dwmac4_wrback_get_timestamp(void *desc, u32 
> ats)
> return ns;
>  }
>
> -static int dwmac4_context_get_rx_timestamp_status(void *desc, u32 ats)
> +static int dwmac4_rx_check_timestamp(void *desc)
> +{
> +   struct dma_desc *p = (struct dma_desc *)desc;
> +   u32 own, ctxt;
> +   int ret = 1;
> +
> +   own = p->des3 & RDES3_OWN;
> +   ctxt = ((p->des3 & RDES3_CONTEXT_DESCRIPTOR)
> +   >> RDES3_CONTEXT_DESCRIPTOR_SHIFT);
> +
> +   if (likely(!own && ctxt)) {
> +   if ((p->des0 == 0x) && (p->des1 == 0x))
> +   /* Co

Re: stmmac: Reporting ethtool_ts_info

[Rayagond Kokatanur]

On Tue, Oct 27, 2015 at 11:41 AM, Phil Reid  wrote:
> G'day All,
>
> The stmmac driver checks (priv->hwts_tx_en) && (priv->hwts_rx_en) before
> reporting WHTSTAMP capabilities.
> No other driver seems to do this. hwts_*_en indicate if timestamping is
> enabled, not if the interface is capable of it.
> Instead they check there capabilities. Which would be
> (priv->dma_cap.time_stamp || priv->dma_cap.atime_stamp)

Yes true.

priv->hwts_*_en indicate if timestamping is enabled/disabled at run
time. But  priv->dma_cap.time_stamp  and priv->dma_cap.atime_stamp
indicates HW is support for PTPv1/PTPv2.

We should use  - (priv->dma_cap.time_stamp ||
priv->dma_cap.atime_stamp) in ethtool_ts_ops.

wwr
Rayagond
>
> Does this seem reasonable?
>
>
> --
> Regards
> Phil Reid
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html