netdev - Re: [PATCH/RFC 2/2] ravb: Add GbEthernet driver support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMuHMdW-NeDqiNDzQzzqnmQB2qL0Bc1-m+NQu9v8bK+_+7HxWQ@mail.gmail.com>
Date:   Thu, 15 Jul 2021 12:13:06 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Biju Das <biju.das.jz@...renesas.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Sergei Shtylyov <sergei.shtylyov@...il.com>,
        Sergey Shtylyov <s.shtylyov@...russia.ru>,
        Adam Ford <aford173@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
        Andrew Gabbasov <andrew_gabbasov@...tor.com>,
        Yuusuke Ashizuka <ashiduka@...itsu.com>,
        netdev <netdev@...r.kernel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        Chris Paterson <Chris.Paterson2@...esas.com>,
        Biju Das <biju.das@...renesas.com>,
        Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH/RFC 2/2] ravb: Add GbEthernet driver support

Hi Biju,

On Wed, Jul 14, 2021 at 4:54 PM Biju Das <biju.das.jz@...renesas.com> wrote:
> Add Gigabit Ethernet driver support.
>
> The Gigabit Etherner IP consists of Ethernet controller (E-MAC),
> Internal TCP/IP Offload Engine (TOE) and Dedicated Direct memory
> access controller (DMAC).
>
> Signed-off-by: Biju Das <biju.das.jz@...renesas.com>

Thanks for your patch!

> --- a/drivers/net/ethernet/renesas/ravb.h
> +++ b/drivers/net/ethernet/renesas/ravb.h

> @@ -986,6 +1068,7 @@ struct ravb_ptp {
>  enum ravb_chip_id {
>         RCAR_GEN2,
>         RCAR_GEN3,
> +       RZ_G2L,
>  };

Instead of adding another chip type, it may be better to replace
the chip type by a structure with feature bits, values, and function
pointers (see examples below).

BTW given the ravb driver is based on the sh_eth driver ("Ethernet
AVB includes an Gigabit Ethernet controller (E-MAC) that is basically
compatible with SuperH Gigabit Ethernet E-MAC"), and seeing the amount
of changes, I'm wondering if rgeth is closer to sh_eth? ;-)

> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c

> @@ -247,8 +288,12 @@ static void ravb_ring_free(struct net_device *ndev, int q)
>         int ring_size;
>         int i;
>
> -       if (priv->rx_ring[q]) {
> -               ravb_ring_free_ex(ndev, q);
> +       if (priv->chip_id == RZ_G2L) {
> +               if (priv->rgeth_rx_ring[q])
> +                       rgeth_ring_free_ex(ndev, q);
> +       } else {
> +               if (priv->rx_ring[q])
> +                       ravb_ring_free_ex(ndev, q);
>         }

Could be called through a function pointer instead.

> @@ -356,7 +434,7 @@ static void ravb_ring_format(struct net_device *ndev, int q)
>  static int ravb_ring_init(struct net_device *ndev, int q)
>  {
>         struct ravb_private *priv = netdev_priv(ndev);
> -       size_t skb_sz = RX_BUF_SZ;
> +       size_t skb_sz = (priv->chip_id == RZ_G2L) ? RGETH_RCV_BUFF_MAX : RX_BUF_SZ;

Could use a value in the structure.

> @@ -730,7 +1054,7 @@ static void ravb_emac_interrupt_unlocked(struct net_device *ndev)
>         ecsr = ravb_read(ndev, ECSR);
>         ravb_write(ndev, ecsr, ECSR);   /* clear interrupt */
>
> -       if (ecsr & ECSR_MPD)
> +       if (priv->chip_id != RZ_G2L && (ecsr & ECSR_MPD))

Could use a feature bit.

> @@ -2104,11 +2578,19 @@ static int ravb_probe(struct platform_device *pdev)
>         priv = netdev_priv(ndev);
>         priv->chip_id = chip_id;
>
> -       ndev->features = NETIF_F_RXCSUM;
> -       ndev->hw_features = NETIF_F_RXCSUM;
> -
> -       pm_runtime_enable(&pdev->dev);
> -       pm_runtime_get_sync(&pdev->dev);
> +       if (chip_id == RZ_G2L) {
> +               ndev->hw_features |= (NETIF_F_HW_CSUM | NETIF_F_RXCSUM);
> +               priv->rstc = devm_reset_control_get(&pdev->dev, NULL);

R-Car Gen2 and Gen3 describe a reset in DT, too.
Does it hurt to always use the reset?

> +               if (IS_ERR(priv->rstc)) {
> +                       dev_err(&pdev->dev, "failed to get cpg reset\n");

dev_err_probe(), to avoid printing an error on -EPROBE_DEFER.

> +                       free_netdev(ndev);
> +                       return PTR_ERR(priv->rstc);
> +               }
> +               reset_control_deassert(priv->rstc);
> +       } else {
> +               ndev->features = NETIF_F_RXCSUM;
> +               ndev->hw_features = NETIF_F_RXCSUM;
> +       }


Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds