| Message ID | 1337754964-21754-1-git-send-email-peppe.cavallaro@st.com |
|---|---|
| State | Deferred, archived |
| Delegated to: | David Miller |
| Headers | show |
You really need to post your patches properly. In particular, you need to indicate, either in an initial "[PATCH 0/N]" posting, or in the subject lines of that patch, exactly what tree you are targetting. And if this is meant for net-next, I told you specifically that net-next is not open right now and you need to submit this later when I make the announcement here that it is open. We are in the middle of the merge window, and therefore you should only be submitting bug fixes against the 'net' tree. It is extremely irritating that, when I go out of my way to make announcements here on this list, multiple times, about what kind of patches are appropriate and what kinds are not, and yet people still do not listen and they still submit any old crap they feel like submitting. People need to stop this, now. Pay attention to the development state, and follow the rules, otherwise you'll royally piss me off and I'll ignore your patches completely. Thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 5/23/2012 8:42 AM, David Miller wrote: > > You really need to post your patches properly. > > In particular, you need to indicate, either in an initial "[PATCH 0/N]" > posting, or in the subject lines of that patch, exactly what tree > you are targetting. > > And if this is meant for net-next, I told you specifically that net-next > is not open right now and you need to submit this later when I make > the announcement here that it is open. > > We are in the middle of the merge window, and therefore you should only > be submitting bug fixes against the 'net' tree. Previous ones were for net-next and in fact in the subject I indeed used: [net-next X/N] stmmac: .... After your comment I re-sent them for net.git (pls see my previous email where I clarified that). I have always posted all my patches for net-next adding its suffix in the subject. For all the patches for net.git I've never added the suffix but I'll do that. I agree with you that the suffix should be added and I had understood (and always used and fixed in my subjectprefix) that these were the format of the patches in this mailing list [PATCH] ... =>>> for net.git [PATCH net-next] =>>> for net-next.git So I'll use starting from now: [PATCH (net.git)] =>>> for net.git [PATCH (net-next)] =>>> for net-next.git > It is extremely irritating that, when I go out of my way to make > announcements here on this list, multiple times, about what kind of > patches are appropriate and what kinds are not, and yet people still > do not listen and they still submit any old crap they feel like > submitting. > > People need to stop this, now. > > Pay attention to the development state, and follow the rules, > otherwise you'll royally piss me off and I'll ignore your patches > completely. > > Thanks. > > > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index 7096633..0caae72 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -677,7 +677,7 @@ static void stmmac_tx(struct stmmac_priv *priv) priv->hw->desc->release_tx_desc(p); - entry = (++priv->dirty_tx) % txsize; + priv->dirty_tx++; } if (unlikely(netif_queue_stopped(priv->dev) && stmmac_tx_avail(priv) > STMMAC_TX_THRESH(priv))) { @@ -1307,7 +1307,6 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit) display_ring(priv->dma_rx, rxsize); } #endif - count = 0; while (!priv->hw->desc->get_rx_owner(p)) { int status;
This patch removes two useful initialisation in the stmmac_rx and stmmac_tx function. In the former, count var was already reset and in the stmmac_tx we only need to increment the dirty pointer w/o setting the entry var. Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-)