[PATCH] net: aquantia: fix aq_ndev_start_xmit()'s return type

[PATCH] net: aquantia: fix aq_ndev_start_xmit()'s return type

[Luc Van Oostenryck]

The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, but the implementation in this
driver returns an 'int'.

Fix this by returning 'netdev_tx_t' in this driver too.

Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
---
 drivers/net/ethernet/aquantia/atlantic/aq_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_main.c b/drivers/net/ethernet/aquantia/atlantic/aq_main.c
index ba5fe8c41..79b0a4d41 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_main.c
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_main.c
@@ -73,7 +73,7 @@ static int aq_ndev_close(struct net_device *ndev)
 	return err;
 }
 
-static int aq_ndev_start_xmit(struct sk_buff *skb, struct net_device *ndev)
+static netdev_tx_t aq_ndev_start_xmit(struct sk_buff *skb, struct net_device *ndev)
 {
 	struct aq_nic_s *aq_nic = netdev_priv(ndev);
 
-- 
2.17.0

Re: [PATCH] net: aquantia: fix aq_ndev_start_xmit()'s return type

[David Miller]

Luc please don't submit such a huge number of patches all at one time.

Also, please fix the indentation of the functions whose arguments
span multiple lines as has been pointed out to you in patch feedback.

Finally, make this a true patch series.  It is so much easier for
maintainers to work with a set of changes all doing the same thing if
you make them a proper patch series with an appropriate "[PATCH 0/N] ..."
header posting.

Thank you.

Re: [PATCH] net: aquantia: fix aq_ndev_start_xmit()'s return type

[Luc Van Oostenryck]

On Tue, Apr 24, 2018 at 10:42:50AM -0400, David Miller wrote:
> 
> Luc please don't submit such a huge number of patches all at one time.
> 
> ...
> 
> Finally, make this a true patch series.  It is so much easier for
> maintainers to work with a set of changes all doing the same thing if
> you make them a proper patch series with an appropriate "[PATCH 0/N] ..."
> header posting.
> 
> Thank you.

I suppose these sort of patches are as much a PITA for the sender
than for the receivers.

I hesitated between a single patch, a series or separated patches.
In a sense, the single patch would have been the easier for both sides
but I guessed it would not have been very well welcomed. Since for a
series, you're supposed to CC the whole series to everyone involved,
it would have been, or at least at thought so, maximaly noisy for no
good reasons. Finally, as all of these patches are totally independent,
I thought it would be the best to send them as separated patches, 
each drivers maintainers being then free to accept, reject or ignore
the patch(es) concerning him/her. It seems it was a bad guess, and
yes, I see the point of having a series for this.

I'll remember all this for the next time (if next time there is,
of course, I was already quite hesitant to spend time to prepare
and send patches for these issues with enum/integer mix-up).

Sorry for the annoyance,
-- Luc