[v2,net,2/2] net: fec: restructuring the functions to avoid forward declarations
Commit Message
The patch reorganizes functions related to XDP frame transmission, moving
them above the fec_enet_run_xdp implementation. This eliminates the need
for forward declarations of these functions.
Fixes: 6d6b39f180b8 ("net: fec: add initial XDP support")
Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
---
drivers/net/ethernet/freescale/fec_main.c | 216 +++++++++++-----------
1 file changed, 108 insertions(+), 108 deletions(-)
Comments
On Tue, May 02, 2023 at 05:08:18PM -0500, Shenwei Wang wrote:
> The patch reorganizes functions related to XDP frame transmission, moving
> them above the fec_enet_run_xdp implementation. This eliminates the need
> for forward declarations of these functions.
I'm confused. Are these two patches in the wrong order?
The reason that i asked you to fix the forward declaration in net-next
is that it makes your fix two patches. Sometimes that is not obvious
to people back porting patches, and one gets lost, causing build
problems. So it is better to have a single patch which is maybe not
100% best practice merged to stable, and then a cleanup patch merged
to the head of development.
Andrew
> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Tuesday, May 2, 2023 6:19 PM
> To: Shenwei Wang <shenwei.wang@nxp.com>
> Cc: Wei Fang <wei.fang@nxp.com>; David S. Miller <davem@davemloft.net>;
> Eric Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>;
> Paolo Abeni <pabeni@redhat.com>; Clark Wang <xiaoning.wang@nxp.com>; dl-
> linux-imx <linux-imx@nxp.com>; Alexei Starovoitov <ast@kernel.org>; Daniel
> Borkmann <daniel@iogearbox.net>; Jesper Dangaard Brouer
> <hawk@kernel.org>; John Fastabend <john.fastabend@gmail.com>; Alexander
> Lobakin <alexandr.lobakin@intel.com>; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; imx@lists.linux.dev
> Subject: [EXT] Re: [PATCH v2 net 2/2] net: fec: restructuring the functions to
> avoid forward declarations
>
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report this
> email' button
>
>
> On Tue, May 02, 2023 at 05:08:18PM -0500, Shenwei Wang wrote:
> > The patch reorganizes functions related to XDP frame transmission,
> > moving them above the fec_enet_run_xdp implementation. This eliminates
> > the need for forward declarations of these functions.
>
> I'm confused. Are these two patches in the wrong order?
>
> The reason that i asked you to fix the forward declaration in net-next is that it
> makes your fix two patches. Sometimes that is not obvious to people back
> porting patches, and one gets lost, causing build problems. So it is better to have
> a single patch which is maybe not 100% best practice merged to stable, and then
> a cleanup patch merged to the head of development.
>
If that is the case, we should forgo the second patch. Its purpose was to reorganize
function order such that the subsequent patch to net-next enabling XDP_TX would not
encounter forward declaration issues.
Thanks,
Shenwei
> Andrew
On Wed, May 03, 2023 at 12:53:57PM +0000, Shenwei Wang wrote:
>
>
> > -----Original Message-----
> > From: Andrew Lunn <andrew@lunn.ch>
> > Sent: Tuesday, May 2, 2023 6:19 PM
> > To: Shenwei Wang <shenwei.wang@nxp.com>
> > Cc: Wei Fang <wei.fang@nxp.com>; David S. Miller <davem@davemloft.net>;
> > Eric Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>;
> > Paolo Abeni <pabeni@redhat.com>; Clark Wang <xiaoning.wang@nxp.com>; dl-
> > linux-imx <linux-imx@nxp.com>; Alexei Starovoitov <ast@kernel.org>; Daniel
> > Borkmann <daniel@iogearbox.net>; Jesper Dangaard Brouer
> > <hawk@kernel.org>; John Fastabend <john.fastabend@gmail.com>; Alexander
> > Lobakin <alexandr.lobakin@intel.com>; netdev@vger.kernel.org; linux-
> > kernel@vger.kernel.org; imx@lists.linux.dev
> > Subject: [EXT] Re: [PATCH v2 net 2/2] net: fec: restructuring the functions to
> > avoid forward declarations
> >
> > Caution: This is an external email. Please take care when clicking links or
> > opening attachments. When in doubt, report the message using the 'Report this
> > email' button
> >
> >
> > On Tue, May 02, 2023 at 05:08:18PM -0500, Shenwei Wang wrote:
> > > The patch reorganizes functions related to XDP frame transmission,
> > > moving them above the fec_enet_run_xdp implementation. This eliminates
> > > the need for forward declarations of these functions.
> >
> > I'm confused. Are these two patches in the wrong order?
> >
> > The reason that i asked you to fix the forward declaration in net-next is that it
> > makes your fix two patches. Sometimes that is not obvious to people back
> > porting patches, and one gets lost, causing build problems. So it is better to have
> > a single patch which is maybe not 100% best practice merged to stable, and then
> > a cleanup patch merged to the head of development.
> >
>
> If that is the case, we should forgo the second patch. Its purpose was to
> reorganize function order such that the subsequent patch to net-next
> enabling XDP_TX would not encounter forward declaration issues.
I think a good plan would be, as I understood Andrew's original suggestion,
to:
1. Only have patch 2/2, targeted at 'net', for now
2. Later, once that patch has been accepted into 'net', 'net-next' has
reopened, and that patch is present in 'net-next', then follow-up
with patch 1/2, which is a cleanup.
> -----Original Message-----
> From: Simon Horman <horms@kernel.org>
> Sent: Wednesday, May 3, 2023 10:34 AM
> To: Shenwei Wang <shenwei.wang@nxp.com>
> Cc: Andrew Lunn <andrew@lunn.ch>; Wei Fang <wei.fang@nxp.com>; David S.
> Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; Clark Wang
> <xiaoning.wang@nxp.com>; dl-linux-imx <linux-imx@nxp.com>; Alexei
> Starovoitov <ast@kernel.org>; Daniel Borkmann <daniel@iogearbox.net>;
> Jesper Dangaard Brouer <hawk@kernel.org>; John Fastabend
> <john.fastabend@gmail.com>; Alexander Lobakin
> <alexandr.lobakin@intel.com>; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; imx@lists.linux.dev
> Subject: Re: [EXT] Re: [PATCH v2 net 2/2] net: fec: restructuring the functions to
> avoid forward declarations
>
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report this
> email' button
>
>
> On Wed, May 03, 2023 at 12:53:57PM +0000, Shenwei Wang wrote:
> >
> >
> > > -----Original Message-----
> > > From: Andrew Lunn <andrew@lunn.ch>
> > > Sent: Tuesday, May 2, 2023 6:19 PM
> > > To: Shenwei Wang <shenwei.wang@nxp.com>
> > > Cc: Wei Fang <wei.fang@nxp.com>; David S. Miller
> > > <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> > > Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; Clark
> > > Wang <xiaoning.wang@nxp.com>; dl- linux-imx <linux-imx@nxp.com>;
> > > Alexei Starovoitov <ast@kernel.org>; Daniel Borkmann
> > > <daniel@iogearbox.net>; Jesper Dangaard Brouer <hawk@kernel.org>;
> > > John Fastabend <john.fastabend@gmail.com>; Alexander Lobakin
> > > <alexandr.lobakin@intel.com>; netdev@vger.kernel.org; linux-
> > > kernel@vger.kernel.org; imx@lists.linux.dev
> > > Subject: [EXT] Re: [PATCH v2 net 2/2] net: fec: restructuring the
> > > functions to avoid forward declarations
> > >
> > > Caution: This is an external email. Please take care when clicking
> > > links or opening attachments. When in doubt, report the message
> > > using the 'Report this email' button
> > >
> > >
> > > On Tue, May 02, 2023 at 05:08:18PM -0500, Shenwei Wang wrote:
> > > > The patch reorganizes functions related to XDP frame transmission,
> > > > moving them above the fec_enet_run_xdp implementation. This
> > > > eliminates the need for forward declarations of these functions.
> > >
> > > I'm confused. Are these two patches in the wrong order?
> > >
> > > The reason that i asked you to fix the forward declaration in
> > > net-next is that it makes your fix two patches. Sometimes that is
> > > not obvious to people back porting patches, and one gets lost,
> > > causing build problems. So it is better to have a single patch which
> > > is maybe not 100% best practice merged to stable, and then a cleanup patch
> merged to the head of development.
> > >
> >
> > If that is the case, we should forgo the second patch. Its purpose was
> > to reorganize function order such that the subsequent patch to
> > net-next enabling XDP_TX would not encounter forward declaration issues.
>
> I think a good plan would be, as I understood Andrew's original suggestion,
> to:
>
> 1. Only have patch 2/2, targeted at 'net', for now 2. Later, once that patch has
> been accepted into 'net', 'net-next' has
> reopened, and that patch is present in 'net-next', then follow-up
> with patch 1/2, which is a cleanup.
So should I re-submit the patch? Or you just take the 1st patch and drop the 2nd one?
Thanks,
Shenwei
On Wed, May 03, 2023 at 06:41:59PM +0000, Shenwei Wang wrote:
...
> > > > On Tue, May 02, 2023 at 05:08:18PM -0500, Shenwei Wang wrote:
> > > > > The patch reorganizes functions related to XDP frame transmission,
> > > > > moving them above the fec_enet_run_xdp implementation. This
> > > > > eliminates the need for forward declarations of these functions.
> > > >
> > > > I'm confused. Are these two patches in the wrong order?
> > > >
> > > > The reason that i asked you to fix the forward declaration in
> > > > net-next is that it makes your fix two patches. Sometimes that is
> > > > not obvious to people back porting patches, and one gets lost,
> > > > causing build problems. So it is better to have a single patch which
> > > > is maybe not 100% best practice merged to stable, and then a cleanup patch
> > merged to the head of development.
> > > >
> > >
> > > If that is the case, we should forgo the second patch. Its purpose was
> > > to reorganize function order such that the subsequent patch to
> > > net-next enabling XDP_TX would not encounter forward declaration issues.
> >
> > I think a good plan would be, as I understood Andrew's original suggestion,
> > to:
> >
> > 1. Only have patch 2/2, targeted at 'net', for now 2. Later, once that patch has
> > been accepted into 'net', 'net-next' has
> > reopened, and that patch is present in 'net-next', then follow-up
> > with patch 1/2, which is a cleanup.
>
> So should I re-submit the patch? Or you just take the 1st patch and drop
> the 2nd one?
net and net-next work on a granularity of patch-sets.
So I would suggest re-submitting only patch 2/2 for 'net'.
I would also suggest waiting 24h between posting v2 and v3,
as per https://kernel.org/doc/html/next/process/maintainer-netdev.html
> -----Original Message-----
> From: Simon Horman <horms@kernel.org>
> Sent: Wednesday, May 3, 2023 2:07 PM
> To: Shenwei Wang <shenwei.wang@nxp.com>
> Cc: Andrew Lunn <andrew@lunn.ch>; Wei Fang <wei.fang@nxp.com>; David S.
> Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; Clark Wang
> <xiaoning.wang@nxp.com>; dl-linux-imx <linux-imx@nxp.com>; Alexei
> Starovoitov <ast@kernel.org>; Daniel Borkmann <daniel@iogearbox.net>;
> Jesper Dangaard Brouer <hawk@kernel.org>; John Fastabend
> <john.fastabend@gmail.com>; Alexander Lobakin
> <alexandr.lobakin@intel.com>; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; imx@lists.linux.dev
> Subject: Re: [EXT] Re: [PATCH v2 net 2/2] net: fec: restructuring the functions to
> avoid forward declarations
>
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report this
> email' button
>
>
> On Wed, May 03, 2023 at 06:41:59PM +0000, Shenwei Wang wrote:
>
> ...
>
> > > > > On Tue, May 02, 2023 at 05:08:18PM -0500, Shenwei Wang wrote:
> > > > > > The patch reorganizes functions related to XDP frame
> > > > > > transmission, moving them above the fec_enet_run_xdp
> > > > > > implementation. This eliminates the need for forward declarations of
> these functions.
> > > > >
> > > > > I'm confused. Are these two patches in the wrong order?
> > > > >
> > > > > The reason that i asked you to fix the forward declaration in
> > > > > net-next is that it makes your fix two patches. Sometimes that
> > > > > is not obvious to people back porting patches, and one gets
> > > > > lost, causing build problems. So it is better to have a single
> > > > > patch which is maybe not 100% best practice merged to stable,
> > > > > and then a cleanup patch
> > > merged to the head of development.
> > > > >
> > > >
> > > > If that is the case, we should forgo the second patch. Its purpose
> > > > was to reorganize function order such that the subsequent patch to
> > > > net-next enabling XDP_TX would not encounter forward declaration issues.
> > >
> > > I think a good plan would be, as I understood Andrew's original
> > > suggestion,
> > > to:
> > >
> > > 1. Only have patch 2/2, targeted at 'net', for now 2. Later, once
> > > that patch has been accepted into 'net', 'net-next' has
> > > reopened, and that patch is present in 'net-next', then follow-up
> > > with patch 1/2, which is a cleanup.
> >
> > So should I re-submit the patch? Or you just take the 1st patch and
> > drop the 2nd one?
>
> net and net-next work on a granularity of patch-sets.
> So I would suggest re-submitting only patch 2/2 for 'net'.
>
Hi Simon,
I'm a bit confused.
Are you suggesting that I submit the following restructuring patch for 'net' at this time?
[PATCH v2 net 2/2] net: fec: restructuring the functions to avoid forward declarations
Thanks,
Shenwei
> I would also suggest waiting 24h between posting v2 and v3, as per
> https://kernel.or/
> g%2Fdoc%2Fhtml%2Fnext%2Fprocess%2Fmaintainer-
> netdev.html&data=05%7C01%7Cshenwei.wang%40nxp.com%7Ca451f7a0cf674
> 0b0561d08db4c09a558%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7
> C638187376528990151%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> &sdata=wBrPt7eKO2Y8ve%2B%2BG8STtZZVS9YdQR11YUL6wcwJ29M%3D&rese
> rved=0
>
> Hi Simon,
>
> I'm a bit confused.
>
> Are you suggesting that I submit the following restructuring patch for 'net' at this time?
> [PATCH v2 net 2/2] net: fec: restructuring the functions to avoid forward declarations
>
> Thanks,
> Shenwei
Submit the fix to 'net'. But only the fix.
Once a week, net gets merged to net-next, so the fix will also appear
in net-next. You can then do the cleanup in net-next.
Andrew
On Wed, May 03, 2023 at 09:40:30PM +0200, Andrew Lunn wrote:
> > Hi Simon,
> >
> > I'm a bit confused.
> >
> > Are you suggesting that I submit the following restructuring patch for 'net' at this time?
> > [PATCH v2 net 2/2] net: fec: restructuring the functions to avoid forward declarations
> >
> > Thanks,
> > Shenwei
>
> Submit the fix to 'net'. But only the fix.
Yes, that is what I meant.
> Once a week, net gets merged to net-next, so the fix will also appear
> in net-next. You can then do the cleanup in net-next.
@@ -1511,6 +1511,114 @@ static void fec_enet_update_cbd(struct fec_enet_priv_rx_q *rxq,
bdp->cbd_bufaddr = cpu_to_fec32(phys_addr);
}
+static int
+fec_enet_xdp_get_tx_queue(struct fec_enet_private *fep, int index)
+{
+ if (unlikely(index < 0))
+ return 0;
+
+ return (index % fep->num_tx_queues);
+}
+
+static int fec_enet_txq_xmit_frame(struct fec_enet_private *fep,
+ struct fec_enet_priv_tx_q *txq,
+ struct xdp_frame *frame)
+{
+ unsigned int index, status, estatus;
+ struct bufdesc *bdp, *last_bdp;
+ dma_addr_t dma_addr;
+ int entries_free;
+
+ entries_free = fec_enet_get_free_txdesc_num(txq);
+ if (entries_free < MAX_SKB_FRAGS + 1) {
+ netdev_err(fep->netdev, "NOT enough BD for SG!\n");
+ xdp_return_frame(frame);
+ return NETDEV_TX_BUSY;
+ }
+
+ /* Fill in a Tx ring entry */
+ bdp = txq->bd.cur;
+ last_bdp = bdp;
+ status = fec16_to_cpu(bdp->cbd_sc);
+ status &= ~BD_ENET_TX_STATS;
+
+ index = fec_enet_get_bd_index(bdp, &txq->bd);
+
+ dma_addr = dma_map_single(&fep->pdev->dev, frame->data,
+ frame->len, DMA_TO_DEVICE);
+ if (dma_mapping_error(&fep->pdev->dev, dma_addr))
+ return FEC_ENET_XDP_CONSUMED;
+
+ status |= (BD_ENET_TX_INTR | BD_ENET_TX_LAST);
+ if (fep->bufdesc_ex)
+ estatus = BD_ENET_TX_INT;
+
+ bdp->cbd_bufaddr = cpu_to_fec32(dma_addr);
+ bdp->cbd_datlen = cpu_to_fec16(frame->len);
+
+ if (fep->bufdesc_ex) {
+ struct bufdesc_ex *ebdp = (struct bufdesc_ex *)bdp;
+
+ if (fep->quirks & FEC_QUIRK_HAS_AVB)
+ estatus |= FEC_TX_BD_FTYPE(txq->bd.qid);
+
+ ebdp->cbd_bdu = 0;
+ ebdp->cbd_esc = cpu_to_fec32(estatus);
+ }
+
+ index = fec_enet_get_bd_index(last_bdp, &txq->bd);
+ txq->tx_skbuff[index] = NULL;
+
+ /* Send it on its way. Tell FEC it's ready, interrupt when done,
+ * it's the last BD of the frame, and to put the CRC on the end.
+ */
+ status |= (BD_ENET_TX_READY | BD_ENET_TX_TC);
+ bdp->cbd_sc = cpu_to_fec16(status);
+
+ /* If this was the last BD in the ring, start at the beginning again. */
+ bdp = fec_enet_get_nextdesc(last_bdp, &txq->bd);
+
+ txq->bd.cur = bdp;
+
+ return 0;
+}
+
+static int fec_enet_xdp_xmit(struct net_device *dev,
+ int num_frames,
+ struct xdp_frame **frames,
+ u32 flags)
+{
+ struct fec_enet_private *fep = netdev_priv(dev);
+ struct fec_enet_priv_tx_q *txq;
+ int cpu = smp_processor_id();
+ unsigned int sent_frames = 0;
+ struct netdev_queue *nq;
+ unsigned int queue;
+ int i;
+
+ queue = fec_enet_xdp_get_tx_queue(fep, cpu);
+ txq = fep->tx_queue[queue];
+ nq = netdev_get_tx_queue(fep->netdev, queue);
+
+ __netif_tx_lock(nq, cpu);
+
+ for (i = 0; i < num_frames; i++) {
+ if (fec_enet_txq_xmit_frame(fep, txq, frames[i]) != 0)
+ break;
+ sent_frames++;
+ }
+
+ /* Make sure the update to bdp and tx_skbuff are performed. */
+ wmb();
+
+ /* Trigger transmission start */
+ writel(0, txq->bd.reg_desc_active);
+
+ __netif_tx_unlock(nq);
+
+ return sent_frames;
+}
+
static u32
fec_enet_run_xdp(struct fec_enet_private *fep, struct bpf_prog *prog,
struct xdp_buff *xdp, struct fec_enet_priv_rx_q *rxq, int index)
@@ -3777,114 +3885,6 @@ static int fec_enet_bpf(struct net_device *dev, struct netdev_bpf *bpf)
}
}
-static int
-fec_enet_xdp_get_tx_queue(struct fec_enet_private *fep, int index)
-{
- if (unlikely(index < 0))
- return 0;
-
- return (index % fep->num_tx_queues);
-}
-
-static int fec_enet_txq_xmit_frame(struct fec_enet_private *fep,
- struct fec_enet_priv_tx_q *txq,
- struct xdp_frame *frame)
-{
- unsigned int index, status, estatus;
- struct bufdesc *bdp, *last_bdp;
- dma_addr_t dma_addr;
- int entries_free;
-
- entries_free = fec_enet_get_free_txdesc_num(txq);
- if (entries_free < MAX_SKB_FRAGS + 1) {
- netdev_err(fep->netdev, "NOT enough BD for SG!\n");
- xdp_return_frame(frame);
- return NETDEV_TX_BUSY;
- }
-
- /* Fill in a Tx ring entry */
- bdp = txq->bd.cur;
- last_bdp = bdp;
- status = fec16_to_cpu(bdp->cbd_sc);
- status &= ~BD_ENET_TX_STATS;
-
- index = fec_enet_get_bd_index(bdp, &txq->bd);
-
- dma_addr = dma_map_single(&fep->pdev->dev, frame->data,
- frame->len, DMA_TO_DEVICE);
- if (dma_mapping_error(&fep->pdev->dev, dma_addr))
- return FEC_ENET_XDP_CONSUMED;
-
- status |= (BD_ENET_TX_INTR | BD_ENET_TX_LAST);
- if (fep->bufdesc_ex)
- estatus = BD_ENET_TX_INT;
-
- bdp->cbd_bufaddr = cpu_to_fec32(dma_addr);
- bdp->cbd_datlen = cpu_to_fec16(frame->len);
-
- if (fep->bufdesc_ex) {
- struct bufdesc_ex *ebdp = (struct bufdesc_ex *)bdp;
-
- if (fep->quirks & FEC_QUIRK_HAS_AVB)
- estatus |= FEC_TX_BD_FTYPE(txq->bd.qid);
-
- ebdp->cbd_bdu = 0;
- ebdp->cbd_esc = cpu_to_fec32(estatus);
- }
-
- index = fec_enet_get_bd_index(last_bdp, &txq->bd);
- txq->tx_skbuff[index] = NULL;
-
- /* Send it on its way. Tell FEC it's ready, interrupt when done,
- * it's the last BD of the frame, and to put the CRC on the end.
- */
- status |= (BD_ENET_TX_READY | BD_ENET_TX_TC);
- bdp->cbd_sc = cpu_to_fec16(status);
-
- /* If this was the last BD in the ring, start at the beginning again. */
- bdp = fec_enet_get_nextdesc(last_bdp, &txq->bd);
-
- txq->bd.cur = bdp;
-
- return 0;
-}
-
-static int fec_enet_xdp_xmit(struct net_device *dev,
- int num_frames,
- struct xdp_frame **frames,
- u32 flags)
-{
- struct fec_enet_private *fep = netdev_priv(dev);
- struct fec_enet_priv_tx_q *txq;
- int cpu = smp_processor_id();
- unsigned int sent_frames = 0;
- struct netdev_queue *nq;
- unsigned int queue;
- int i;
-
- queue = fec_enet_xdp_get_tx_queue(fep, cpu);
- txq = fep->tx_queue[queue];
- nq = netdev_get_tx_queue(fep->netdev, queue);
-
- __netif_tx_lock(nq, cpu);
-
- for (i = 0; i < num_frames; i++) {
- if (fec_enet_txq_xmit_frame(fep, txq, frames[i]) != 0)
- break;
- sent_frames++;
- }
-
- /* Make sure the update to bdp and tx_skbuff are performed. */
- wmb();
-
- /* Trigger transmission start */
- writel(0, txq->bd.reg_desc_active);
-
- __netif_tx_unlock(nq);
-
- return sent_frames;
-}
-
static const struct net_device_ops fec_netdev_ops = {
.ndo_open = fec_enet_open,
.ndo_stop = fec_enet_close,