All of lore.kernel.org
 help / color / mirror / Atom feed
From: clabbe.montjoie@gmail.com (Corentin Labbe)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 05/21] net-next: stmmac: Add dwmac-sun8i
Date: Fri, 17 Feb 2017 14:18:02 +0100	[thread overview]
Message-ID: <20170217131802.GB24993@Red> (raw)
In-Reply-To: <20170216190524.l2ddzhwabzdpdphx@lukather>

On Thu, Feb 16, 2017 at 08:05:24PM +0100, Maxime Ripard wrote:
> Hi,
> 

[...]
> > +
> > +struct emac_variant {
> > +	u32 default_syscon_value;
> 
> Why do you need a default value? Can't you read it from the syscon
> directly?
> 

Why not, but you can see the default value as "value for disabled state".
My fear is that something (uboot) modify it (keep it activated) before driver load.

[...]
> > +static void sun8i_dwmac_dump_regs(void __iomem *ioaddr)
> > +{
> > +	int i;
> > +
> > +	pr_info(" DMA registers\n");
> 
> Logging this as pr_info is bad already...
> 
> > +	for (i = 0; i < 0xC8; i += 4) {
> > +		if (i == 0x32 || i == 0x3C)
> > +			continue;
> > +		pr_err("Reg 0x%x: 0x%08x\n", i, readl(ioaddr + i));
> 
> ... But this is worse.
> 
> Why do you need to do that? Can't you create a file in debugfs
> instead?
> 

I just do as other glue does. But yes this is uglyi, no excuse.
Reworking all stmmac register dump (ethtool, stmmac_ops->dump_regs and stmmac_dma_ops->dump_regs) was on my todo list,
but I postponed it.

I will propose something better based on debugfs.

[...]
> > +static void sun8i_dwmac_dma_start_tx(void __iomem *ioaddr)
> > +{
> > +	u32 v;
> > +
> > +	v = readl(ioaddr + EMAC_TX_CTL0);
> > +	v |= EMAC_TX_TRANSMITTER_EN;
> > +	writel(v, ioaddr + EMAC_TX_CTL0);
> > +
> > +	v = readl(ioaddr + EMAC_TX_CTL1);
> > +	v |= EMAC_TX_DMA_START;
> > +	v |= EMAC_TX_DMA_EN;
> > +	writel(v, ioaddr + EMAC_TX_CTL1);
> 
> This is a bit worrying. There's not a single lock in your driver,
> while you have a significant number of read / modify / write.
> 
> Where is the locking handled?
> 

All thoses function are handled by the "stmmac_ops framework", all other glue drivers does not lock anything.
The few functions that need locking already got it on the calling stmmac side.

[...]
> > +static int sun8i_dwmac_init(struct platform_device *pdev, void *priv)
> > +{
> > +	struct sunxi_priv_data *gmac = priv;
> > +	int ret;
> > +
> > +	if (gmac->regulator) {
> > +		ret = regulator_enable(gmac->regulator);
> > +		if (ret) {
> > +			dev_err(&pdev->dev, "Fail to enable regulator\n");
> > +			return ret;
> > +		}
> > +	}
> > +
> > +	ret = clk_prepare_enable(gmac->tx_clk);
> > +	if (ret) {
> > +		dev_err(&pdev->dev, "Could not enable AHB clock\n");
> 
> If that call fails, you leave the regulator (if there was any) enabled.
> 

I will fix it

> > +		return ret;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static void sun8i_dwmac_core_init(struct mac_device_info *hw, int mtu)
> > +{
> > +	void __iomem *ioaddr = hw->pcsr;
> > +	u32 v;
> > +
> > +	v = (8 << 24);/* burst len */
> > +	writel(v, ioaddr + EMAC_BASIC_CTL1);
> 
> do you need an intermediate value? you should make a define for that
> too.
> 

I will fix it

[...]
> > +static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
> > +{
> > +	struct sunxi_priv_data *gmac = priv->plat->bsp_priv;
> > +	struct device_node *node = priv->device->of_node;
> > +	int ret;
> > +	u32 reg, val;
> > +
> > +	reg = gmac->variant->default_syscon_value;
> > +
> > +	if (gmac->variant->internal_phy) {
> > +		if (!gmac->use_internal_phy) {
> > +			/* switch to external PHY interface */
> > +			reg &= ~H3_EPHY_SELECT;
> > +		} else {
> > +			reg |= H3_EPHY_SELECT;
> > +			reg &= ~H3_EPHY_SHUTDOWN;
> > +			dev_info(priv->device, "Select internal_phy %x\n", reg);
> 
> The logging level is too high
> 

I will reduce it

> > +
> > +			if (of_property_read_bool(priv->plat->phy_node,
> > +						  "allwinner,leds-active-low"))
> > +				reg |= H3_EPHY_LED_POL;
> > +			else
> > +				reg &= ~H3_EPHY_LED_POL;
> > +
> > +			ret = of_mdio_parse_addr(priv->device,
> > +						 priv->plat->phy_node);
> > +			if (ret < 0) {
> > +				dev_err(priv->device, "Could not parse MDIO addr\n");
> > +				return ret;
> > +			}
> > +			/* of_mdio_parse_addr returns a valid (0 ~ 31) PHY
> > +			 * address. No need to mask it again.
> > +			 */
> > +			reg |= ret << H3_EPHY_ADDR_SHIFT;
> > +		}
> > +	}
> > +
> > +	if (!of_property_read_u32(node, "allwinner,tx-delay", &val)) {
> 
> How do you compute it? Can't this be done through auto-training?
> 

The value is the same as used in vendor BSP kernel.
I do not understand what you mean by auto-training.

> > +		dev_info(priv->device, "set tx-delay to %x\n", val);
> 
> change the logging level here too.
> 

I agree

> > +		if (val <= SYSCON_ETXDC_MASK) {
> > +			reg &= ~(SYSCON_ETXDC_MASK << SYSCON_ETXDC_SHIFT);
> > +			reg |= (val << SYSCON_ETXDC_SHIFT);
> > +		} else {
> > +			dev_warn(priv->device, "Invalid TX clock delay: %d\n",
> > +				 val);
> 
> If it's invalid, why don't you treat it as an error and return?
> 

Ok

[...]
> > +static struct mac_device_info *sun8i_dwmac_setup(void __iomem *ioaddr,
> > +						 int mcbins,
> > +						 int perfect_uc_entries,
> > +						 int *synopsys_id)
> > +{
> > +	struct mac_device_info *mac;
> > +
> > +	mac = kzalloc(sizeof(const struct mac_device_info), GFP_KERNEL);
> > +	if (!mac)
> > +		return NULL;
> 
> Do you ever free that memory?
> 

Good catch, I believed that the "stmmac framework" would free it.
I will send a fix for this memory leak.

[...]
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> > index 5ff6bc4..11db658 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> > @@ -450,6 +450,9 @@ static void stmmac_ethtool_gregs(struct net_device *dev,
> >  		for (i = 0; i < 22; i++)
> >  			reg_space[i + 55] =
> >  			    readl(priv->ioaddr + (DMA_BUS_MODE + (i * 4)));
> > +	} else if (priv->plat->has_sun8i) {
> 
> Surely we don't want to add a new flag to the common structure for
> every new platform supported.
> 
> Can't you base that on the compatible instead?

This part will be fixed with the debugfs speaked early in the mail.

But yes I have tried to avoid use of has_sun8i at maximum.

> 
> Thanks a lot for your work,
> Maxime
> 

Thanks for the review

Corentin Labbe

WARNING: multiple messages have this Message-ID (diff)
From: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Maxime Ripard
	<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Cc: peppe.cavallaro-qxv4g6HH51o@public.gmane.org,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	mark.rutland-5wv7dgnIgG8@public.gmane.org,
	wens-jdAy2FN1RRM@public.gmane.org,
	linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org,
	catalin.marinas-5wv7dgnIgG8@public.gmane.org,
	will.deacon-5wv7dgnIgG8@public.gmane.org,
	alexandre.torgue-qxv4g6HH51o@public.gmane.org,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
Subject: Re: [PATCH 05/21] net-next: stmmac: Add dwmac-sun8i
Date: Fri, 17 Feb 2017 14:18:02 +0100	[thread overview]
Message-ID: <20170217131802.GB24993@Red> (raw)
In-Reply-To: <20170216190524.l2ddzhwabzdpdphx@lukather>

On Thu, Feb 16, 2017 at 08:05:24PM +0100, Maxime Ripard wrote:
> Hi,
> 

[...]
> > +
> > +struct emac_variant {
> > +	u32 default_syscon_value;
> 
> Why do you need a default value? Can't you read it from the syscon
> directly?
> 

Why not, but you can see the default value as "value for disabled state".
My fear is that something (uboot) modify it (keep it activated) before driver load.

[...]
> > +static void sun8i_dwmac_dump_regs(void __iomem *ioaddr)
> > +{
> > +	int i;
> > +
> > +	pr_info(" DMA registers\n");
> 
> Logging this as pr_info is bad already...
> 
> > +	for (i = 0; i < 0xC8; i += 4) {
> > +		if (i == 0x32 || i == 0x3C)
> > +			continue;
> > +		pr_err("Reg 0x%x: 0x%08x\n", i, readl(ioaddr + i));
> 
> ... But this is worse.
> 
> Why do you need to do that? Can't you create a file in debugfs
> instead?
> 

I just do as other glue does. But yes this is uglyi, no excuse.
Reworking all stmmac register dump (ethtool, stmmac_ops->dump_regs and stmmac_dma_ops->dump_regs) was on my todo list,
but I postponed it.

I will propose something better based on debugfs.

[...]
> > +static void sun8i_dwmac_dma_start_tx(void __iomem *ioaddr)
> > +{
> > +	u32 v;
> > +
> > +	v = readl(ioaddr + EMAC_TX_CTL0);
> > +	v |= EMAC_TX_TRANSMITTER_EN;
> > +	writel(v, ioaddr + EMAC_TX_CTL0);
> > +
> > +	v = readl(ioaddr + EMAC_TX_CTL1);
> > +	v |= EMAC_TX_DMA_START;
> > +	v |= EMAC_TX_DMA_EN;
> > +	writel(v, ioaddr + EMAC_TX_CTL1);
> 
> This is a bit worrying. There's not a single lock in your driver,
> while you have a significant number of read / modify / write.
> 
> Where is the locking handled?
> 

All thoses function are handled by the "stmmac_ops framework", all other glue drivers does not lock anything.
The few functions that need locking already got it on the calling stmmac side.

[...]
> > +static int sun8i_dwmac_init(struct platform_device *pdev, void *priv)
> > +{
> > +	struct sunxi_priv_data *gmac = priv;
> > +	int ret;
> > +
> > +	if (gmac->regulator) {
> > +		ret = regulator_enable(gmac->regulator);
> > +		if (ret) {
> > +			dev_err(&pdev->dev, "Fail to enable regulator\n");
> > +			return ret;
> > +		}
> > +	}
> > +
> > +	ret = clk_prepare_enable(gmac->tx_clk);
> > +	if (ret) {
> > +		dev_err(&pdev->dev, "Could not enable AHB clock\n");
> 
> If that call fails, you leave the regulator (if there was any) enabled.
> 

I will fix it

> > +		return ret;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static void sun8i_dwmac_core_init(struct mac_device_info *hw, int mtu)
> > +{
> > +	void __iomem *ioaddr = hw->pcsr;
> > +	u32 v;
> > +
> > +	v = (8 << 24);/* burst len */
> > +	writel(v, ioaddr + EMAC_BASIC_CTL1);
> 
> do you need an intermediate value? you should make a define for that
> too.
> 

I will fix it

[...]
> > +static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
> > +{
> > +	struct sunxi_priv_data *gmac = priv->plat->bsp_priv;
> > +	struct device_node *node = priv->device->of_node;
> > +	int ret;
> > +	u32 reg, val;
> > +
> > +	reg = gmac->variant->default_syscon_value;
> > +
> > +	if (gmac->variant->internal_phy) {
> > +		if (!gmac->use_internal_phy) {
> > +			/* switch to external PHY interface */
> > +			reg &= ~H3_EPHY_SELECT;
> > +		} else {
> > +			reg |= H3_EPHY_SELECT;
> > +			reg &= ~H3_EPHY_SHUTDOWN;
> > +			dev_info(priv->device, "Select internal_phy %x\n", reg);
> 
> The logging level is too high
> 

I will reduce it

> > +
> > +			if (of_property_read_bool(priv->plat->phy_node,
> > +						  "allwinner,leds-active-low"))
> > +				reg |= H3_EPHY_LED_POL;
> > +			else
> > +				reg &= ~H3_EPHY_LED_POL;
> > +
> > +			ret = of_mdio_parse_addr(priv->device,
> > +						 priv->plat->phy_node);
> > +			if (ret < 0) {
> > +				dev_err(priv->device, "Could not parse MDIO addr\n");
> > +				return ret;
> > +			}
> > +			/* of_mdio_parse_addr returns a valid (0 ~ 31) PHY
> > +			 * address. No need to mask it again.
> > +			 */
> > +			reg |= ret << H3_EPHY_ADDR_SHIFT;
> > +		}
> > +	}
> > +
> > +	if (!of_property_read_u32(node, "allwinner,tx-delay", &val)) {
> 
> How do you compute it? Can't this be done through auto-training?
> 

The value is the same as used in vendor BSP kernel.
I do not understand what you mean by auto-training.

> > +		dev_info(priv->device, "set tx-delay to %x\n", val);
> 
> change the logging level here too.
> 

I agree

> > +		if (val <= SYSCON_ETXDC_MASK) {
> > +			reg &= ~(SYSCON_ETXDC_MASK << SYSCON_ETXDC_SHIFT);
> > +			reg |= (val << SYSCON_ETXDC_SHIFT);
> > +		} else {
> > +			dev_warn(priv->device, "Invalid TX clock delay: %d\n",
> > +				 val);
> 
> If it's invalid, why don't you treat it as an error and return?
> 

Ok

[...]
> > +static struct mac_device_info *sun8i_dwmac_setup(void __iomem *ioaddr,
> > +						 int mcbins,
> > +						 int perfect_uc_entries,
> > +						 int *synopsys_id)
> > +{
> > +	struct mac_device_info *mac;
> > +
> > +	mac = kzalloc(sizeof(const struct mac_device_info), GFP_KERNEL);
> > +	if (!mac)
> > +		return NULL;
> 
> Do you ever free that memory?
> 

Good catch, I believed that the "stmmac framework" would free it.
I will send a fix for this memory leak.

[...]
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> > index 5ff6bc4..11db658 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> > @@ -450,6 +450,9 @@ static void stmmac_ethtool_gregs(struct net_device *dev,
> >  		for (i = 0; i < 22; i++)
> >  			reg_space[i + 55] =
> >  			    readl(priv->ioaddr + (DMA_BUS_MODE + (i * 4)));
> > +	} else if (priv->plat->has_sun8i) {
> 
> Surely we don't want to add a new flag to the common structure for
> every new platform supported.
> 
> Can't you base that on the compatible instead?

This part will be fixed with the debugfs speaked early in the mail.

But yes I have tried to avoid use of has_sun8i at maximum.

> 
> Thanks a lot for your work,
> Maxime
> 

Thanks for the review

Corentin Labbe
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Corentin Labbe <clabbe.montjoie@gmail.com>
To: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: peppe.cavallaro@st.com, robh+dt@kernel.org, mark.rutland@arm.com,
	wens@csie.org, linux@armlinux.org.uk, catalin.marinas@arm.com,
	will.deacon@arm.com, alexandre.torgue@st.com,
	netdev@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com
Subject: Re: [PATCH 05/21] net-next: stmmac: Add dwmac-sun8i
Date: Fri, 17 Feb 2017 14:18:02 +0100	[thread overview]
Message-ID: <20170217131802.GB24993@Red> (raw)
In-Reply-To: <20170216190524.l2ddzhwabzdpdphx@lukather>

On Thu, Feb 16, 2017 at 08:05:24PM +0100, Maxime Ripard wrote:
> Hi,
> 

[...]
> > +
> > +struct emac_variant {
> > +	u32 default_syscon_value;
> 
> Why do you need a default value? Can't you read it from the syscon
> directly?
> 

Why not, but you can see the default value as "value for disabled state".
My fear is that something (uboot) modify it (keep it activated) before driver load.

[...]
> > +static void sun8i_dwmac_dump_regs(void __iomem *ioaddr)
> > +{
> > +	int i;
> > +
> > +	pr_info(" DMA registers\n");
> 
> Logging this as pr_info is bad already...
> 
> > +	for (i = 0; i < 0xC8; i += 4) {
> > +		if (i == 0x32 || i == 0x3C)
> > +			continue;
> > +		pr_err("Reg 0x%x: 0x%08x\n", i, readl(ioaddr + i));
> 
> ... But this is worse.
> 
> Why do you need to do that? Can't you create a file in debugfs
> instead?
> 

I just do as other glue does. But yes this is uglyi, no excuse.
Reworking all stmmac register dump (ethtool, stmmac_ops->dump_regs and stmmac_dma_ops->dump_regs) was on my todo list,
but I postponed it.

I will propose something better based on debugfs.

[...]
> > +static void sun8i_dwmac_dma_start_tx(void __iomem *ioaddr)
> > +{
> > +	u32 v;
> > +
> > +	v = readl(ioaddr + EMAC_TX_CTL0);
> > +	v |= EMAC_TX_TRANSMITTER_EN;
> > +	writel(v, ioaddr + EMAC_TX_CTL0);
> > +
> > +	v = readl(ioaddr + EMAC_TX_CTL1);
> > +	v |= EMAC_TX_DMA_START;
> > +	v |= EMAC_TX_DMA_EN;
> > +	writel(v, ioaddr + EMAC_TX_CTL1);
> 
> This is a bit worrying. There's not a single lock in your driver,
> while you have a significant number of read / modify / write.
> 
> Where is the locking handled?
> 

All thoses function are handled by the "stmmac_ops framework", all other glue drivers does not lock anything.
The few functions that need locking already got it on the calling stmmac side.

[...]
> > +static int sun8i_dwmac_init(struct platform_device *pdev, void *priv)
> > +{
> > +	struct sunxi_priv_data *gmac = priv;
> > +	int ret;
> > +
> > +	if (gmac->regulator) {
> > +		ret = regulator_enable(gmac->regulator);
> > +		if (ret) {
> > +			dev_err(&pdev->dev, "Fail to enable regulator\n");
> > +			return ret;
> > +		}
> > +	}
> > +
> > +	ret = clk_prepare_enable(gmac->tx_clk);
> > +	if (ret) {
> > +		dev_err(&pdev->dev, "Could not enable AHB clock\n");
> 
> If that call fails, you leave the regulator (if there was any) enabled.
> 

I will fix it

> > +		return ret;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static void sun8i_dwmac_core_init(struct mac_device_info *hw, int mtu)
> > +{
> > +	void __iomem *ioaddr = hw->pcsr;
> > +	u32 v;
> > +
> > +	v = (8 << 24);/* burst len */
> > +	writel(v, ioaddr + EMAC_BASIC_CTL1);
> 
> do you need an intermediate value? you should make a define for that
> too.
> 

I will fix it

[...]
> > +static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
> > +{
> > +	struct sunxi_priv_data *gmac = priv->plat->bsp_priv;
> > +	struct device_node *node = priv->device->of_node;
> > +	int ret;
> > +	u32 reg, val;
> > +
> > +	reg = gmac->variant->default_syscon_value;
> > +
> > +	if (gmac->variant->internal_phy) {
> > +		if (!gmac->use_internal_phy) {
> > +			/* switch to external PHY interface */
> > +			reg &= ~H3_EPHY_SELECT;
> > +		} else {
> > +			reg |= H3_EPHY_SELECT;
> > +			reg &= ~H3_EPHY_SHUTDOWN;
> > +			dev_info(priv->device, "Select internal_phy %x\n", reg);
> 
> The logging level is too high
> 

I will reduce it

> > +
> > +			if (of_property_read_bool(priv->plat->phy_node,
> > +						  "allwinner,leds-active-low"))
> > +				reg |= H3_EPHY_LED_POL;
> > +			else
> > +				reg &= ~H3_EPHY_LED_POL;
> > +
> > +			ret = of_mdio_parse_addr(priv->device,
> > +						 priv->plat->phy_node);
> > +			if (ret < 0) {
> > +				dev_err(priv->device, "Could not parse MDIO addr\n");
> > +				return ret;
> > +			}
> > +			/* of_mdio_parse_addr returns a valid (0 ~ 31) PHY
> > +			 * address. No need to mask it again.
> > +			 */
> > +			reg |= ret << H3_EPHY_ADDR_SHIFT;
> > +		}
> > +	}
> > +
> > +	if (!of_property_read_u32(node, "allwinner,tx-delay", &val)) {
> 
> How do you compute it? Can't this be done through auto-training?
> 

The value is the same as used in vendor BSP kernel.
I do not understand what you mean by auto-training.

> > +		dev_info(priv->device, "set tx-delay to %x\n", val);
> 
> change the logging level here too.
> 

I agree

> > +		if (val <= SYSCON_ETXDC_MASK) {
> > +			reg &= ~(SYSCON_ETXDC_MASK << SYSCON_ETXDC_SHIFT);
> > +			reg |= (val << SYSCON_ETXDC_SHIFT);
> > +		} else {
> > +			dev_warn(priv->device, "Invalid TX clock delay: %d\n",
> > +				 val);
> 
> If it's invalid, why don't you treat it as an error and return?
> 

Ok

[...]
> > +static struct mac_device_info *sun8i_dwmac_setup(void __iomem *ioaddr,
> > +						 int mcbins,
> > +						 int perfect_uc_entries,
> > +						 int *synopsys_id)
> > +{
> > +	struct mac_device_info *mac;
> > +
> > +	mac = kzalloc(sizeof(const struct mac_device_info), GFP_KERNEL);
> > +	if (!mac)
> > +		return NULL;
> 
> Do you ever free that memory?
> 

Good catch, I believed that the "stmmac framework" would free it.
I will send a fix for this memory leak.

[...]
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> > index 5ff6bc4..11db658 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> > @@ -450,6 +450,9 @@ static void stmmac_ethtool_gregs(struct net_device *dev,
> >  		for (i = 0; i < 22; i++)
> >  			reg_space[i + 55] =
> >  			    readl(priv->ioaddr + (DMA_BUS_MODE + (i * 4)));
> > +	} else if (priv->plat->has_sun8i) {
> 
> Surely we don't want to add a new flag to the common structure for
> every new platform supported.
> 
> Can't you base that on the compatible instead?

This part will be fixed with the debugfs speaked early in the mail.

But yes I have tried to avoid use of has_sun8i at maximum.

> 
> Thanks a lot for your work,
> Maxime
> 

Thanks for the review

Corentin Labbe

  reply	other threads:[~2017-02-17 13:18 UTC|newest]

Thread overview: 105+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-16 12:48 [PATCH 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver Corentin Labbe
2017-02-16 12:48 ` Corentin Labbe
2017-02-16 12:48 ` Corentin Labbe
2017-02-16 12:48 ` [PATCH 01/21] net-next: stmmac add optional init_phy function Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48 ` [PATCH 02/21] net-next: stmmac: export stmmac_set_mac_addr/stmmac_get_mac_addr Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48 ` [PATCH 03/21] net-next: stmmac: add optional setup function Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 20:38   ` [linux-sunxi] " Peter Korsgaard
2017-02-16 20:38     ` Peter Korsgaard
2017-02-16 20:38     ` Peter Korsgaard
2017-02-17  8:18     ` [linux-sunxi] " Corentin Labbe
2017-02-17  8:18       ` Corentin Labbe
2017-02-17  8:18       ` Corentin Labbe
2017-02-16 12:48 ` [PATCH 04/21] ARM: sun8i: dt: Add DT bindings documentation for Allwinner dwmac-sun8i Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 18:48   ` Maxime Ripard
2017-02-16 18:48     ` Maxime Ripard
2017-02-16 18:48     ` Maxime Ripard
2017-02-17 12:18     ` Corentin Labbe
2017-02-17 12:18       ` Corentin Labbe
2017-02-17 12:18       ` Corentin Labbe
2017-02-16 20:58   ` Florian Fainelli
2017-02-16 20:58     ` Florian Fainelli
2017-02-16 20:58     ` Florian Fainelli
2017-02-20 15:07     ` Corentin Labbe
2017-02-20 15:07       ` Corentin Labbe
2017-02-20 15:07       ` Corentin Labbe
2017-02-16 12:48 ` [PATCH 05/21] net-next: stmmac: Add dwmac-sun8i Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 19:05   ` Maxime Ripard
2017-02-16 19:05     ` Maxime Ripard
2017-02-16 19:05     ` Maxime Ripard
2017-02-17 13:18     ` Corentin Labbe [this message]
2017-02-17 13:18       ` Corentin Labbe
2017-02-17 13:18       ` Corentin Labbe
2017-02-21 22:22       ` Maxime Ripard
2017-02-21 22:22         ` Maxime Ripard
2017-02-21 22:22         ` Maxime Ripard
2017-02-16 12:48 ` [PATCH 06/21] ARM: dts: sun8i-h3: Add dt node for the syscon control module Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48 ` [PATCH 07/21] ARM: dts: sun8i-h3: add dwmac-sun8i ethernet driver Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48 ` [PATCH 08/21] ARM: dts: sun8i-h3: add dwmac-sun8i rgmii pins Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 19:06   ` Maxime Ripard
2017-02-16 19:06     ` Maxime Ripard
2017-02-16 19:06     ` Maxime Ripard
2017-02-17  9:14     ` Corentin Labbe
2017-02-17  9:14       ` Corentin Labbe
2017-02-17  9:14       ` Corentin Labbe
2017-02-16 12:48 ` [PATCH 09/21] ARM: dts: sun8i: Enable dwmac-sun8i on the Banana Pi M2+ Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48 ` [PATCH 10/21] ARM: dts: sun8i: Enable dwmac-sun8i on the Orange PI PC Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48 ` [PATCH 11/21] ARM: dts: sun8i: Enable dwmac-sun8i on the Orange Pi 2 Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48 ` [PATCH 12/21] ARM: dts: sun8i: Enable dwmac-sun8i on the Orange PI One Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48 ` [PATCH 13/21] ARM: dts: sun8i: Enable dwmac-sun8i on the Orange Pi plus Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48 ` [PATCH 14/21] ARM: dts: sun8i: orangepi-pc-plus: Set EMAC activity LEDs to active high Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48 ` [PATCH 15/21] ARM64: dts: sun50i-a64: Add dt node for the syscon control module Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48 ` [PATCH 16/21] ARM64: dts: sun50i-a64: add dwmac-sun8i Ethernet driver Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48 ` [PATCH 17/21] ARM: dts: sun50i-a64: enable dwmac-sun8i on pine64 Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48 ` [PATCH 18/21] ARM: dts: sun50i-a64: enable dwmac-sun8i on pine64 plus Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48 ` [PATCH 19/21] ARM: dts: sun50i-a64: enable dwmac-sun8i on the BananaPi M64 Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48 ` [PATCH 20/21] ARM: sunxi: Enable dwmac-sun8i driver on sunxi_defconfig Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 19:08   ` Maxime Ripard
2017-02-16 19:08     ` Maxime Ripard
2017-02-16 19:08     ` Maxime Ripard
2017-02-17  8:55     ` Corentin Labbe
2017-02-17  8:55       ` Corentin Labbe
2017-02-17  8:55       ` Corentin Labbe
2017-02-16 12:48 ` [PATCH 21/21] ARM: sunxi: Enable dwmac-sun8i driver on multi_v7_defconfig Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe
2017-02-16 12:48   ` Corentin Labbe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170217131802.GB24993@Red \
    --to=clabbe.montjoie@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.