* Re: [PATCH] mac80211: Remove unused 'struct rate_control_ref' variable
From: Johannes Berg @ 2016-11-22 7:30 UTC (permalink / raw)
To: Kirtika Ruchandani
Cc: Arnd Bergmann, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Maxim Altshul
In-Reply-To: <20161122065416.GA3565-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
On Mon, 2016-11-21 at 22:54 -0800, Kirtika Ruchandani wrote:
> Commit 3b17fbf87d5d introduced sta_get_expected_throughput()
> leaving variable 'struct rate_control_ref* ref' set but unused.
> Compiling with W=1 gives the following warning, fix it.
>
> net/mac80211/sta_info.c: In function ‘sta_set_sinfo’:
> net/mac80211/sta_info.c:2052:27: warning: variable ‘ref’ set but not
> used [-Wunused-but-set-variable]
Applied all three of these, thanks Kirtika.
johannes
^ permalink raw reply
* [Patch net] net: revert "net: l2tp: Treat NET_XMIT_CN as success in l2tp_eth_dev_xmit"
From: Cong Wang @ 2016-11-22 7:24 UTC (permalink / raw)
To: netdev; +Cc: Cong Wang, Gao Feng
This reverts commit 7c6ae610a1f0, because l2tp_xmit_skb() never
returns NET_XMIT_CN, it ignores the return value of l2tp_xmit_core().
Cc: Gao Feng <gfree.wind@gmail.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
net/l2tp/l2tp_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
index 3dc97b4..965f7e3 100644
--- a/net/l2tp/l2tp_eth.c
+++ b/net/l2tp/l2tp_eth.c
@@ -97,7 +97,7 @@ static int l2tp_eth_dev_xmit(struct sk_buff *skb, struct net_device *dev)
unsigned int len = skb->len;
int ret = l2tp_xmit_skb(session, skb, session->hdr_len);
- if (likely(ret == NET_XMIT_SUCCESS || ret == NET_XMIT_CN)) {
+ if (likely(ret == NET_XMIT_SUCCESS)) {
atomic_long_add(len, &priv->tx_bytes);
atomic_long_inc(&priv->tx_packets);
} else {
--
1.8.4.5
^ permalink raw reply related
* Re: [PATCH] bnxt_en: Fix a VXLAN vs GENEVE issue
From: Michael Chan @ 2016-11-22 7:15 UTC (permalink / raw)
To: Christophe JAILLET
Cc: David Miller, Prashant Sreedharan, Netdev, kernel-janitors
In-Reply-To: <20161122051440.9748-1-christophe.jaillet@wanadoo.fr>
On Mon, Nov 21, 2016 at 9:14 PM, Christophe JAILLET
<christophe.jaillet@wanadoo.fr> wrote:
> Knowing that:
> #define TUNNEL_DST_PORT_FREE_REQ_TUNNEL_TYPE_VXLAN (0x1UL << 0)
> #define TUNNEL_DST_PORT_FREE_REQ_TUNNEL_TYPE_GENEVE (0x5UL << 0)
> and that 'bnxt_hwrm_tunnel_dst_port_alloc()' is only called with one of
> these 2 constants, the TUNNEL_DST_PORT_ALLOC_REQ_TUNNEL_TYPE_GENEVE can not
> trigger.
>
> Replace the bit test that overlap by an equality test, just as in
> 'bnxt_hwrm_tunnel_dst_port_free()' above.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Thanks.
Acked-by: Michael Chan <michael.chan@broadcom.com>
^ permalink raw reply
* [PATCH] mac80211: Remove unused 'struct rate_control_ref' variable
From: Kirtika Ruchandani @ 2016-11-22 6:54 UTC (permalink / raw)
To: Johannes Berg
Cc: Arnd Bergmann, linux-wireless, netdev, Maxim Altshul,
Johannes Berg
Commit 3b17fbf87d5d introduced sta_get_expected_throughput()
leaving variable 'struct rate_control_ref* ref' set but unused.
Compiling with W=1 gives the following warning, fix it.
net/mac80211/sta_info.c: In function ‘sta_set_sinfo’:
net/mac80211/sta_info.c:2052:27: warning: variable ‘ref’ set but not used [-Wunused-but-set-variable]
Fixes: 3b17fbf87d5d ("mac80211: mesh: Add support for HW RC implementation")
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: Maxim Altshul <maxim.altshul@ti.com>
Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
---
net/mac80211/sta_info.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 1711bae..4ab75a9 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -2049,16 +2049,12 @@ void sta_set_sinfo(struct sta_info *sta, struct station_info *sinfo)
{
struct ieee80211_sub_if_data *sdata = sta->sdata;
struct ieee80211_local *local = sdata->local;
- struct rate_control_ref *ref = NULL;
u32 thr = 0;
int i, ac, cpu;
struct ieee80211_sta_rx_stats *last_rxstats;
last_rxstats = sta_get_last_rx_stats(sta);
- if (test_sta_flag(sta, WLAN_STA_RATE_CONTROL))
- ref = local->rate_ctrl;
-
sinfo->generation = sdata->local->sta_generation;
/* do before driver, so beacon filtering drivers have a
^ permalink raw reply related
* Re: [PATCH net 1/1] net: l2tp: Treat NET_XMIT_CN as success in l2tp_eth_dev_xmit
From: Gao Feng @ 2016-11-22 6:32 UTC (permalink / raw)
To: Cong Wang
Cc: Eric Dumazet, David Miller, javier,
Linux Kernel Network Developers
In-Reply-To: <CAM_iQpX-z8Eja4rPg5dzAXLXd6v3nwMMPev-gk+wM9XLBNYK1A@mail.gmail.com>
Hi Cong,
On Tue, Nov 22, 2016 at 1:29 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Sun, Nov 20, 2016 at 4:56 PM, <fgao@ikuai8.com> wrote:
>> From: Gao Feng <gfree.wind@gmail.com>
>>
>> The tc could return NET_XMIT_CN as one congestion notification, but
>> it does not mean the packe is lost. Other modules like ipvlan,
>> macvlan, and others treat NET_XMIT_CN as success too.
>> So l2tp_eth_dev_xmit should add the NET_XMIT_CN check.
>>
>> Signed-off-by: Gao Feng <gfree.wind@gmail.com>
>> ---
>> net/l2tp/l2tp_eth.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
>> index 965f7e3..3dc97b4 100644
>> --- a/net/l2tp/l2tp_eth.c
>> +++ b/net/l2tp/l2tp_eth.c
>> @@ -97,7 +97,7 @@ static int l2tp_eth_dev_xmit(struct sk_buff *skb, struct net_device *dev)
>> unsigned int len = skb->len;
>> int ret = l2tp_xmit_skb(session, skb, session->hdr_len);
>>
>> - if (likely(ret == NET_XMIT_SUCCESS)) {
>> + if (likely(ret == NET_XMIT_SUCCESS || ret == NET_XMIT_CN)) {
>
> How could l2tp_xmit_skb() possibly return NET_XMIT_CN?
> Note It ignores the return value of l2tp_xmit_core().
You are right. I didn't think about it.
Regards
Feng
^ permalink raw reply
* Re: [mm PATCH v3 21/23] mm: Add support for releasing multiple instances of a page
From: Andrew Morton @ 2016-11-22 6:28 UTC (permalink / raw)
To: Alexander Duyck
Cc: Alexander Duyck, linux-mm, Netdev, linux-kernel@vger.kernel.org
In-Reply-To: <CAKgT0UfoS-JC66hHV14E-hgmrhGdz4oYpmHve=01A1X8o8O=rw@mail.gmail.com>
On Mon, 21 Nov 2016 08:21:39 -0800 Alexander Duyck <alexander.duyck@gmail.com> wrote:
> >> + __free_pages_ok(page, order);
> >> + }
> >> +}
> >> +EXPORT_SYMBOL(__page_frag_drain);
> >
> > It's an exported-to-modules library function. It should be documented,
> > please? The page-frag API is only partially documented, but that's no
> > excuse.
>
> Okay. I assume you want the documentation as a follow-up patch since
> I received a notice that the patch was added to -mm?
Yes please. Or a replacement patch which I'll temporarily turn into a
delta, either is fine.
> If you would like I could look at doing a couple of renaming patches
> so that we make the API a bit more consistent. I could move the
> __alloc and __free to what you have suggested, and then take a look at
> trying to rename the refill/drain to be a bit more consistent in terms
> of what they are supposed to work on and how they are supposed to be
> used.
I think that would be better - it's hardly high-priority but a bit of
attention to the documentation and naming conventions would help tidy
things up. When you can't find anything else to do ;)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH] ipv6:ipv6_pinfo dereferenced after NULL check
From: Manjeet Pawar @ 2016-11-22 6:27 UTC (permalink / raw)
To: davem, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
Cc: pankaj.m, ajeet.y, Rohit Thapliyal, Manjeet Pawar
From: Rohit Thapliyal <r.thapliyal@samsung.com>
np checked for NULL and then dereferenced. It should be modified
for NULL case.
Signed-off-by: Rohit Thapliyal <r.thapliyal@samsung.com>
Signed-off-by: Manjeet Pawar <manjeet.p@samsung.com>
---
net/ipv6/ip6_output.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 1dfc402..c2afa14 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -205,14 +205,15 @@ int ip6_xmit(const struct sock *sk, struct sk_buff *skb, struct flowi6 *fl6,
/*
* Fill in the IPv6 header
*/
- if (np)
+ if (np) {
hlimit = np->hop_limit;
+ ip6_flow_hdr(
+ hdr, tclass, ip6_make_flowlabel(
+ net, skb, fl6->flowlabel,
+ np->autoflowlabel, fl6));
+ }
if (hlimit < 0)
hlimit = ip6_dst_hoplimit(dst);
- ip6_flow_hdr(hdr, tclass, ip6_make_flowlabel(net, skb, fl6->flowlabel,
- np->autoflowlabel, fl6));
-
hdr->payload_len = htons(seg_len);
hdr->nexthdr = proto;
hdr->hop_limit = hlimit;
--
1.9.1
^ permalink raw reply related
* [net] rtnetlink: fix the wrong minimal dump size getting from rtnl_calcit()
From: Zhang Shengju @ 2016-11-22 6:14 UTC (permalink / raw)
To: netdev, davem; +Cc: roopa
For RT netlink, calcit() function should return the minimal size for
netlink dump message. This will make sure that dump message for every
network device can be stored.
Currently, rtnl_calcit() function doesn't account the size of header of
netlink message, this patch will fix it.
Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
---
net/core/rtnetlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index f4b9350..09e115b 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2734,7 +2734,7 @@ static u16 rtnl_calcit(struct sk_buff *skb, struct nlmsghdr *nlh)
ext_filter_mask));
}
- return min_ifinfo_dump_size;
+ return nlmsg_total_size(min_ifinfo_dump_size);
}
static int rtnl_dump_all(struct sk_buff *skb, struct netlink_callback *cb)
--
1.8.3.1
^ permalink raw reply related
* [PATCH] mac80211: Remove unused 'rates_idx' variable
From: Kirtika Ruchandani @ 2016-11-22 6:04 UTC (permalink / raw)
To: Johannes Berg
Cc: Arnd Bergmann, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Felix Fietkau, Johannes Berg
Commit f027c2aca0cf introduced 'rates_idx' in
ieee80211_tx_status_noskb but did not use it. Compiling with W=1
gives the following warning, fix it.
mac80211/status.c: In function ‘ieee80211_tx_status_noskb’:
mac80211/status.c:636:6: warning: variable ‘rates_idx’ set but not used [-Wunused-but-set-variable]
This is a harmless warning, and is only being fixed to reduce the
noise generated with W=1.
Fixes: f027c2aca0cf ("mac80211: add ieee80211_tx_status_noskb")
Cc: Johannes Berg <johannes.berg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Felix Fietkau <nbd-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
Signed-off-by: Kirtika Ruchandani <kirtika-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
---
net/mac80211/status.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index ddf71c6..f7c5ae5 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -633,10 +633,9 @@ void ieee80211_tx_status_noskb(struct ieee80211_hw *hw,
struct ieee80211_local *local = hw_to_local(hw);
struct ieee80211_supported_band *sband;
int retry_count;
- int rates_idx;
bool acked, noack_success;
- rates_idx = ieee80211_tx_get_rates(hw, info, &retry_count);
+ ieee80211_tx_get_rates(hw, info, &retry_count);
sband = hw->wiphy->bands[info->band];
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH] mac80211: Remove unused 'struct ieee80211_rx_status' ptr
From: Kirtika Ruchandani @ 2016-11-22 5:44 UTC (permalink / raw)
To: Johannes Berg
Cc: Arnd Bergmann, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Commit 554891e63a29 introduced 'struct ieee80211_rx_status' in
ieee80211_rx_h_defragment but did not use it. Compiling with W=1
gives the following warning, fix it.
net/mac80211/rx.c: In function ‘ieee80211_rx_h_defragment’:
net/mac80211/rx.c:1911:30: warning: variable ‘status’ set but not used [-Wunused-but-set-variable]
Fixes: 554891e63a29 ("mac80211: move packet flags into packet")
Cc: Johannes Berg <johannes.berg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: John W. Linville <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Signed-off-by: Kirtika Ruchandani <kirtika-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
---
net/mac80211/rx.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index eeab725..d2a00f2 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1908,7 +1908,6 @@ ieee80211_rx_h_defragment(struct ieee80211_rx_data *rx)
unsigned int frag, seq;
struct ieee80211_fragment_entry *entry;
struct sk_buff *skb;
- struct ieee80211_rx_status *status;
hdr = (struct ieee80211_hdr *)rx->skb->data;
fc = hdr->frame_control;
@@ -2034,9 +2033,6 @@ ieee80211_rx_h_defragment(struct ieee80211_rx_data *rx)
dev_kfree_skb(skb);
}
- /* Complete frame has been reassembled - process it now */
- status = IEEE80211_SKB_RXCB(rx->skb);
^ permalink raw reply related
* Re: [RFC PATCH net v2 2/3] dt: bindings: add ethernet phy eee-disable-advert option documentation
From: Florian Fainelli @ 2016-11-22 5:35 UTC (permalink / raw)
To: Andrew Lunn, Jerome Brunet
Cc: netdev, devicetree, Alexandre TORGUE, Neil Armstrong,
Martin Blumenstingl, Kevin Hilman, linux-kernel, Andre Roth,
linux-amlogic, Carlo Caione, Giuseppe Cavallaro, linux-arm-kernel
In-Reply-To: <20161121164733.GG1922@lunn.ch>
Le 21/11/2016 à 08:47, Andrew Lunn a écrit :
>> What I did not realize when doing this patch for the realtek driver is
>> that there is already 6 valid modes defined in the kernel
>>
>> #define MDIO_EEE_100TX MDIO_AN_EEE_ADV_100TX /*
>> 100TX EEE cap */
>> #define MDIO_EEE_1000T MDIO_AN_EEE_ADV_1000T /*
>> 1000T EEE cap */
>> #define MDIO_EEE_10GT 0x0008 /* 10GT EEE cap */
>> #define MDIO_EEE_1000KX 0x0010 /* 1000KX EEE cap
>> */
>> #define MDIO_EEE_10GKX4 0x0020 /* 10G KX4 EEE cap
>> */
>> #define MDIO_EEE_10GKR 0x0040 /* 10G KR EEE cap
>> */
>>
>> I took care of only 2 in the case of realtek.c since it only support
>> MDIO_EEE_100TX and MDIO_EEE_1000T.
>>
>> Defining a property for each is certainly doable but it does not look
>> very nice either. If it extends in the future, it will get even more
>> messier, especially if you want to disable everything.
>
> Yes, agreed.
One risk with the definition a group of advertisement capabilities
(under the form of a bitmask for instance) to enable/disable is that we
end up with Device Tree contain some kind of configuration policy as
opposed to just flagging particular hardware features as broken.
Fortunately, there does not seem to be a ton of PHYs out there which
require EEE to be disabled to function properly so having individual
properties vs. bitmasks/groups is kind of speculative here.
Another approach to solving this problem could be to register a PHY
fixup which disables EEE at the PHY level, and which is only called for
specific boards affected by this problem (of_machine_is_compatible()).
This code can leave in arch/*/* when that is possible, or it can just be
somewhere where it is relevant, e.g; in the PHY driver for instance
(similarly to how PCI fixups are done).
--
Florian
^ permalink raw reply
* Re: [PATCH net 1/1] net: l2tp: Treat NET_XMIT_CN as success in l2tp_eth_dev_xmit
From: Cong Wang @ 2016-11-22 5:29 UTC (permalink / raw)
To: fgao
Cc: Eric Dumazet, David Miller, javier,
Linux Kernel Network Developers, Feng Gao
In-Reply-To: <1479689781-2125-1-git-send-email-fgao@ikuai8.com>
On Sun, Nov 20, 2016 at 4:56 PM, <fgao@ikuai8.com> wrote:
> From: Gao Feng <gfree.wind@gmail.com>
>
> The tc could return NET_XMIT_CN as one congestion notification, but
> it does not mean the packe is lost. Other modules like ipvlan,
> macvlan, and others treat NET_XMIT_CN as success too.
> So l2tp_eth_dev_xmit should add the NET_XMIT_CN check.
>
> Signed-off-by: Gao Feng <gfree.wind@gmail.com>
> ---
> net/l2tp/l2tp_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
> index 965f7e3..3dc97b4 100644
> --- a/net/l2tp/l2tp_eth.c
> +++ b/net/l2tp/l2tp_eth.c
> @@ -97,7 +97,7 @@ static int l2tp_eth_dev_xmit(struct sk_buff *skb, struct net_device *dev)
> unsigned int len = skb->len;
> int ret = l2tp_xmit_skb(session, skb, session->hdr_len);
>
> - if (likely(ret == NET_XMIT_SUCCESS)) {
> + if (likely(ret == NET_XMIT_SUCCESS || ret == NET_XMIT_CN)) {
How could l2tp_xmit_skb() possibly return NET_XMIT_CN?
Note It ignores the return value of l2tp_xmit_core().
^ permalink raw reply
* Re: [PATCH net 1/1] net sched filters: pass netlink message flags in event notification
From: Cong Wang @ 2016-11-22 5:23 UTC (permalink / raw)
To: Roman Mashak
Cc: David Miller, Linux Kernel Network Developers, Jamal Hadi Salim
In-Reply-To: <CAM_iQpU_ivg4eBV=88DH6qEcomrq0+G5M=c9rafLszf09PAP_w@mail.gmail.com>
On Thu, Nov 17, 2016 at 1:02 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Wed, Nov 16, 2016 at 2:16 PM, Roman Mashak <mrv@mojatatu.com> wrote:
>> Userland client should be able to read an event, and reflect it back to
>> the kernel, therefore it needs to extract complete set of netlink flags.
>>
>> For example, this will allow "tc monitor" to distinguish Add and Replace
>> operations.
>>
>> Signed-off-by: Roman Mashak <mrv@mojatatu.com>
>> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
>> ---
>> net/sched/cls_api.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
>> index 2b2a797..8e93d4a 100644
>> --- a/net/sched/cls_api.c
>> +++ b/net/sched/cls_api.c
>> @@ -112,7 +112,7 @@ static void tfilter_notify_chain(struct net *net, struct sk_buff *oskb,
>>
>> for (it_chain = chain; (tp = rtnl_dereference(*it_chain)) != NULL;
>> it_chain = &tp->next)
>> - tfilter_notify(net, oskb, n, tp, 0, event, false);
>> + tfilter_notify(net, oskb, n, tp, n->nlmsg_flags, event, false);
>
>
> I must miss something, why does it make sense to pass n->nlmsg_flags
> as 'fh' to tfilter_notify()??
Ping... Any response?
It still doesn't look correct to me. I will send a fix unless someone could
explain this.
^ permalink raw reply
* [PATCH] bnxt_en: Fix a VXLAN vs GENEVE issue
From: Christophe JAILLET @ 2016-11-22 5:14 UTC (permalink / raw)
To: davem, michael.chan, prashant.sreedharan
Cc: netdev, kernel-janitors, Christophe JAILLET
Knowing that:
#define TUNNEL_DST_PORT_FREE_REQ_TUNNEL_TYPE_VXLAN (0x1UL << 0)
#define TUNNEL_DST_PORT_FREE_REQ_TUNNEL_TYPE_GENEVE (0x5UL << 0)
and that 'bnxt_hwrm_tunnel_dst_port_alloc()' is only called with one of
these 2 constants, the TUNNEL_DST_PORT_ALLOC_REQ_TUNNEL_TYPE_GENEVE can not
trigger.
Replace the bit test that overlap by an equality test, just as in
'bnxt_hwrm_tunnel_dst_port_free()' above.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
Compile-tested only
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index d313b02485a1..25d9ffe51825 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -3210,11 +3210,17 @@ static int bnxt_hwrm_tunnel_dst_port_alloc(struct bnxt *bp, __be16 port,
goto err_out;
}
- if (tunnel_type & TUNNEL_DST_PORT_ALLOC_REQ_TUNNEL_TYPE_VXLAN)
+ switch (tunnel_type) {
+ case TUNNEL_DST_PORT_ALLOC_REQ_TUNNEL_TYPE_VXLAN:
bp->vxlan_fw_dst_port_id = resp->tunnel_dst_port_id;
-
- else if (tunnel_type & TUNNEL_DST_PORT_ALLOC_REQ_TUNNEL_TYPE_GENEVE)
+ break;
+ case TUNNEL_DST_PORT_ALLOC_REQ_TUNNEL_TYPE_GENEVE:
bp->nge_fw_dst_port_id = resp->tunnel_dst_port_id;
+ break;
+ default:
+ break;
+ }
+
err_out:
mutex_unlock(&bp->hwrm_cmd_lock);
return rc;
--
2.9.3
^ permalink raw reply related
* Re: [RFC PATCH net v2 1/3] net: phy: add an option to disable EEE advertisement
From: Anand Moon @ 2016-11-22 5:04 UTC (permalink / raw)
To: Jerome Brunet
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree, Florian Fainelli,
Alexandre TORGUE, Neil Armstrong, Martin Blumenstingl,
Kevin Hilman, Linux Kernel, Andre Roth,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Carlo Caione,
Giuseppe Cavallaro, linux-arm-kernel
In-Reply-To: <1479742524-30222-2-git-send-email-jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Hi Jerome,
On 21 November 2016 at 21:05, Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
> This patch adds an option to disable EEE advertisement in the generic PHY
> by providing a mask of prohibited modes corresponding to the value found in
> the MDIO_AN_EEE_ADV register.
>
> On some platforms, PHY Low power idle seems to be causing issues, even
> breaking the link some cases. The patch provides a convenient way for these
> platforms to disable EEE advertisement and work around the issue.
>
> Signed-off-by: Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> drivers/net/phy/phy.c | 3 ++
> drivers/net/phy/phy_device.c | 80 +++++++++++++++++++++++++++++++++++++++-----
> include/linux/phy.h | 3 ++
> 3 files changed, 77 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index f424b867f73e..a44ee14bd953 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -1348,6 +1348,9 @@ int phy_ethtool_set_eee(struct phy_device *phydev, struct ethtool_eee *data)
> {
> int val = ethtool_adv_to_mmd_eee_adv_t(data->advertised);
>
> + /* Mask prohibited EEE modes */
> + val &= ~phydev->eee_advert_disabled;
> +
> phy_write_mmd_indirect(phydev, MDIO_AN_EEE_ADV, MDIO_MMD_AN, val);
>
> return 0;
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 1a4bf8acad78..74c628e046cb 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -1116,6 +1116,43 @@ static int genphy_config_advert(struct phy_device *phydev)
> }
>
> /**
> + * genphy_config_eee_advert - disable unwanted eee mode advertisement
> + * @phydev: target phy_device struct
> + *
> + * Description: Writes MDIO_AN_EEE_ADV after disabling unsupported energy
> + * efficent ethernet modes. Returns 0 if the PHY's advertisement hasn't
> + * changed, and 1 if it has changed.
> + */
> +static int genphy_config_eee_advert(struct phy_device *phydev)
> +{
> + u32 disabled = phydev->eee_advert_disabled;
> + u32 old_adv, adv;
> +
> + /* Nothing to disable */
> + if (!disabled)
> + return 0;
> +
> + /* If the following call fails, we assume that EEE is not
> + * supported by the phy. If we read 0, EEE is not advertised
> + * In both case, we don't need to continue
> + */
> + adv = phy_read_mmd_indirect(phydev, MDIO_AN_EEE_ADV, MDIO_MMD_AN);
> + if (adv <= 0)
> + return 0;
> +
> + old_adv = adv;
> + adv &= ~disabled;
> +
> + /* Advertising remains unchanged with the ban */
> + if (old_adv == adv)
> + return 0;
> +
> + phy_write_mmd_indirect(phydev, MDIO_AN_EEE_ADV, MDIO_MMD_AN, adv);
> +
> + return 1;
> +}
> +
> +/**
> * genphy_setup_forced - configures/forces speed/duplex from @phydev
> * @phydev: target phy_device struct
> *
> @@ -1173,15 +1210,20 @@ EXPORT_SYMBOL(genphy_restart_aneg);
> */
> int genphy_config_aneg(struct phy_device *phydev)
> {
> - int result;
> + int err, changed;
> +
> + changed = genphy_config_eee_advert(phydev);
>
> if (AUTONEG_ENABLE != phydev->autoneg)
> return genphy_setup_forced(phydev);
>
> - result = genphy_config_advert(phydev);
> - if (result < 0) /* error */
> - return result;
> - if (result == 0) {
> + err = genphy_config_advert(phydev);
> + if (err < 0) /* error */
> + return err;
> +
> + changed |= err;
> +
> + if (changed == 0) {
> /* Advertisement hasn't changed, but maybe aneg was never on to
> * begin with? Or maybe phy was isolated?
> */
> @@ -1191,16 +1233,16 @@ int genphy_config_aneg(struct phy_device *phydev)
> return ctl;
>
> if (!(ctl & BMCR_ANENABLE) || (ctl & BMCR_ISOLATE))
> - result = 1; /* do restart aneg */
> + changed = 1; /* do restart aneg */
> }
>
> /* Only restart aneg if we are advertising something different
> * than we were before.
> */
> - if (result > 0)
> - result = genphy_restart_aneg(phydev);
> + if (changed > 0)
> + return genphy_restart_aneg(phydev);
>
> - return result;
> + return 0;
> }
> EXPORT_SYMBOL(genphy_config_aneg);
>
> @@ -1558,6 +1600,21 @@ static void of_set_phy_supported(struct phy_device *phydev)
> __set_phy_supported(phydev, max_speed);
> }
>
> +static void of_set_phy_eee_disable(struct phy_device *phydev)
> +{
> + struct device_node *node = phydev->mdio.dev.of_node;
> + u32 disabled;
> +
> + if (!IS_ENABLED(CONFIG_OF_MDIO))
> + return;
> +
> + if (!node)
> + return;
> +
> + if (!of_property_read_u32(node, "eee-advert-disable", &disabled))
> + phydev->eee_advert_disabled = disabled;
> +}
> +
> /**
> * phy_probe - probe and init a PHY device
> * @dev: device to probe and init
> @@ -1595,6 +1652,11 @@ static int phy_probe(struct device *dev)
> of_set_phy_supported(phydev);
> phydev->advertising = phydev->supported;
>
> + /* Get the EEE modes we want to prohibit. We will ask
> + * the PHY stop advertising these mode later on
> + */
> + of_set_phy_eee_disable(phydev);
> +
> /* Set the state to READY by default */
> phydev->state = PHY_READY;
>
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index e25f1830fbcf..7f2ea0af16d1 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -401,6 +401,9 @@ struct phy_device {
> u32 advertising;
> u32 lp_advertising;
>
> + /* Energy efficient ethernet modes which should be prohibited */
> + u32 eee_advert_disabled;
> +
> int autoneg;
>
> int link_timeout;
> --
> 2.7.4
>
iperf3 tcp test summary at my end
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-100.00 sec 10.9 GBytes 936 Mbits/sec 0 sender
[ 4] 0.00-100.00 sec 10.9 GBytes 936 Mbits/sec receiver
CPU Utilization: local/sender 5.7% (0.2%u/5.5%s), remote/receiver
11.9% (0.9%u/11.0%s)
iperf3 udp test summary at my end.
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Jitter
Lost/Total Datagrams
[ 4] 0.00-100.00 sec 12.5 MBytes 1.05 Mbits/sec 0.025 ms 0/1599 (0%)
[ 4] Sent 1599 datagrams
CPU Utilization: local/sender 0.1% (0.0%u/0.1%s), remote/receiver 0.0%
(0.0%u/0.0%s)
Best Regards
-Anand Moon
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
--
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
^ permalink raw reply
* RE: [PATCH] net: ioctl SIOCSIFADDR minor cleanup
From: YUAN Linyu @ 2016-11-22 4:30 UTC (permalink / raw)
To: Cong Wang; +Cc: David Miller, cugyly@163.com, netdev@vger.kernel.org
In-Reply-To: <CAM_iQpW0SnpXfN-DjBm-72_23KxtzH8kXbbc3FiQn=VChdX3Ww@mail.gmail.com>
I think there are newbie include me still use ifconfig utility.
So when I check this code, it can be optimized.
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Cong Wang
> Sent: Tuesday, November 22, 2016 12:20 PM
> To: YUAN Linyu
> Cc: David Miller; cugyly@163.com; netdev@vger.kernel.org
> Subject: Re: [PATCH] net: ioctl SIOCSIFADDR minor cleanup
>
> On Tue, Nov 15, 2016 at 7:57 PM, YUAN Linyu
> <Linyu.Yuan@alcatel-sbell.com.cn> wrote:
> > No, this patch will not change dev->name,
> > It's care about ifa->ifa_label.
> >> - if (colon)
> >> - memcpy(ifa->ifa_label, ifr.ifr_name,
> IFNAMSIZ);
> >> - else
> >> - memcpy(ifa->ifa_label, dev->name,
> IFNAMSIZ);
> > When ifr.ifr_name have no colon, dev->name must equal to ifr.ifr_name.
> > So we change to
> >> - else
> >> - memcpy(ifa->ifa_label, ifr.ifr_name,
> IFNAMSIZ);
> > Then if and else do same thing. Just one line is enough,
> > memcpy(ifa->ifa_label, ifr.ifr_name, IFNAMSIZ);
> >
>
> I don't understand why you try to optimize a slow path and some kind of
> obsolete code.
^ permalink raw reply
* Re: [PATCH] net: ioctl SIOCSIFADDR minor cleanup
From: Cong Wang @ 2016-11-22 4:20 UTC (permalink / raw)
To: YUAN Linyu; +Cc: David Miller, cugyly@163.com, netdev@vger.kernel.org
In-Reply-To: <8729016553E3654398EA69218DA29EEF0E42F7ED@cnshjmbx02>
On Tue, Nov 15, 2016 at 7:57 PM, YUAN Linyu
<Linyu.Yuan@alcatel-sbell.com.cn> wrote:
> No, this patch will not change dev->name,
> It's care about ifa->ifa_label.
>> - if (colon)
>> - memcpy(ifa->ifa_label, ifr.ifr_name, IFNAMSIZ);
>> - else
>> - memcpy(ifa->ifa_label, dev->name, IFNAMSIZ);
> When ifr.ifr_name have no colon, dev->name must equal to ifr.ifr_name.
> So we change to
>> - else
>> - memcpy(ifa->ifa_label, ifr.ifr_name, IFNAMSIZ);
> Then if and else do same thing. Just one line is enough,
> memcpy(ifa->ifa_label, ifr.ifr_name, IFNAMSIZ);
>
I don't understand why you try to optimize a slow path and some kind of
obsolete code.
^ permalink raw reply
* [PATCH] netdevice.h: fix kernel-doc warning
From: Randy Dunlap @ 2016-11-22 2:28 UTC (permalink / raw)
To: netdev@vger.kernel.org, David Miller
From: Randy Dunlap <rdunlap@infradead.org>
Fix kernel-doc warning in <linux/netdevice.h> (missing ':'):
..//include/linux/netdevice.h:1904: warning: No description found for parameter 'prio_tc_map[TC_BITMASK + 1]'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
include/linux/netdevice.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- lnx-49-rc6.orig/include/linux/netdevice.h
+++ lnx-49-rc6/include/linux/netdevice.h
@@ -1619,7 +1619,7 @@ enum netdev_priv_flags {
* @dcbnl_ops: Data Center Bridging netlink ops
* @num_tc: Number of traffic classes in the net device
* @tc_to_txq: XXX: need comments on this one
- * @prio_tc_map XXX: need comments on this one
+ * @prio_tc_map: XXX: need comments on this one
*
* @fcoe_ddp_xid: Max exchange id for FCoE LRO by ddp
*
^ permalink raw reply
* [PATCH net 1/1] driver: macvlan: Check if need rollback multicast setting in macvlan_open
From: fgao @ 2016-11-22 1:54 UTC (permalink / raw)
To: davem, kaber, netdev, gfree.wind; +Cc: Gao Feng
From: Gao Feng <fgao@ikuai8.com>
When dev_set_promiscuity failed in macvlan_open, it always invokes
dev_set_allmulti without checking if necessary.
Now check the IFF_ALLMULTI flag firstly before rollback the multicast
setting in the error handler.
Signed-off-by: Gao Feng <fgao@ikuai8.com>
---
drivers/net/macvlan.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index d2d6f12..26d6f0b 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -623,7 +623,8 @@ static int macvlan_open(struct net_device *dev)
return 0;
clear_multi:
- dev_set_allmulti(lowerdev, -1);
+ if (dev->flags & IFF_ALLMULTI)
+ dev_set_allmulti(lowerdev, -1);
del_unicast:
dev_uc_del(lowerdev, dev->dev_addr);
out:
--
1.9.1
^ permalink raw reply related
* Re: [RFC 02/10] IB/hfi-vnic: Virtual Network Interface Controller (VNIC) Bus driver
From: Vishwanathapura, Niranjana @ 2016-11-22 1:53 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Dennis Dalessandro
In-Reply-To: <20161121233118.GA31132-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On Mon, Nov 21, 2016 at 04:31:18PM -0700, Jason Gunthorpe wrote:
>> >>>>+ ida_init(&hfi_vnic_ctrl_ida);
>> >>>>+ idr_init(&hfi_vnic_idr);
>> >>>>+
>> >>>>+ rc = bus_register(&hfi_vnic_bus);
>> >>>
>> >>>Why on earth do we need this? Didn't I give you enough grief for the
>> >>>psm stuff and now you want to create an entire subystem hidden away!?
>> >>>
>> >>>Use some netlink scheme to control your vnic like the rest of the net
>> >>>stack..
>> >>>
>> >>
>> >>The hfi_vnic_bus is only abstracting the HW independent functionality (like
>> >>Ethernet interface, encapsulation, IB MAD interface etc) with the HW
>> >>dependent functionality (sending/receiving packets on the wire).
>> >>Thus providing a cleaner interface between HW independent hfi_vnic Ethernet
>> >>and Control drivers and the HW dependent HFI1 driver.
>> >
>> >That doesn't explain anything, sound like you don't need it so get rid
>> >of it.
>
>> >>There is no other User interface here other than the standard Ethernet
>> >>interface through network stack.
>> >
>> >Good, then this isn't needed, because it doesn't provide a user interface.
>> >
>>
>> Can you explain what exactly you are asking to get rid of here and why?
>
>Get rid of the bus_register/etc as drivers do not get to call this.
>
There are many example drivers in kernel which are using bus_register() in
an initcall.
We could add a custom Interface between HFI1 driver and hfi_vnic drivers
without involving a bus.
But using the existing bus model gave a lot of in-built flexibility in
decoupling devices from the drivers.
Niranjana
>Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH ethtool v3 2/2] Ethtool: Implements ETHTOOL_PHY_GTUNABLE/ETHTOOL_PHY_STUNABLE and PHY downshift
From: Florian Fainelli @ 2016-11-22 1:51 UTC (permalink / raw)
To: Allan W. Nielsen, netdev; +Cc: andrew, raju.lakkaraju
In-Reply-To: <1479384480-31201-3-git-send-email-allan.nielsen@microsemi.com>
On 11/17/2016 04:08 AM, Allan W. Nielsen wrote:
> From: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
>
> Add ethtool get and set tunable to access PHY drivers.
>
> Ethtool Help: ethtool -h for PHY tunables
> ethtool --set-phy-tunable DEVNAME Set PHY tunable
> [ downshift on|off [count N] ]
> ethtool --get-phy-tunable DEVNAME Get PHY tunable
> [ downshift ]
>
> Ethtool ex:
> ethtool --set-phy-tuanble eth0 downshift on
> ethtool --set-phy-tuanble eth0 downshift off
> ethtool --set-phy-tuanble eth0 downshift on count 2
s/tunable/tunable/
Since this will be used as examples for people testing this feature,
this is kind of important to get the example right ;)
Other than that:
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
>
> ethtool --get-phy-tunable eth0 downshift
>
> Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
> Signed-off-by: Allan W. Nielsen <allan.nielsen@microsemi.com>
> ---
> +.B downshift
> +For operation in cabling environments that are incompatible with 1000BASE-T,
> +PHY device provides an automatic link speed downshift operation.
Might be worth mentioning that this is particularly useful if you are
using a cable which does not have the 4 pairs for instance.
--
Florian
^ permalink raw reply
* Re: linux-next: build warnings after merge of the net-next tree
From: Florian Fainelli @ 2016-11-22 1:28 UTC (permalink / raw)
To: Stephen Rothwell, David Miller, Networking
Cc: linux-next, linux-kernel, Thomas Petazzoni, Gregory Clement
In-Reply-To: <20161122122216.575b1793@canb.auug.org.au>
+Thomas, Gregory,
On 11/21/2016 05:22 PM, Stephen Rothwell wrote:
[snip]
>
> Introduced by commit
>
> a0627f776a45 ("net: marvell: Allow drivers to be built with COMPILE_TEST")
>
> "a few warnings" is a matter of perception. :-(
Thomas, based on our IRC conversation, do you already have patches for
mvneta and mvpp2 to build without warning on 64-bit or should I prepare
patches for these?
--
Florian
^ permalink raw reply
* linux-next: build warnings after merge of the net-next tree
From: Stephen Rothwell @ 2016-11-22 1:22 UTC (permalink / raw)
To: David Miller, Networking; +Cc: Florian Fainelli, linux-next, linux-kernel
Hi all,
After merging the net-next tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:
drivers/net/ethernet/marvell/mvneta_bm.c: In function 'mvneta_bm_construct':
drivers/net/ethernet/marvell/mvneta_bm.c:103:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
*(u32 *)buf = (u32)buf;
^
In file included from include/linux/clk.h:16:0,
from drivers/net/ethernet/marvell/mvneta_bm.c:13:
drivers/net/ethernet/marvell/mvneta_bm.c: In function 'mvneta_bm_pool_create':
drivers/net/ethernet/marvell/mvneta_bm.c:128:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
if (!IS_ALIGNED((u32)bm_pool->virt_addr, MVNETA_BM_POOL_PTR_ALIGN)) {
^
include/linux/kernel.h:51:30: note: in definition of macro 'IS_ALIGNED'
#define IS_ALIGNED(x, a) (((x) & ((typeof(x))(a) - 1)) == 0)
^
drivers/net/ethernet/marvell/mvneta_bm.c:128:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
if (!IS_ALIGNED((u32)bm_pool->virt_addr, MVNETA_BM_POOL_PTR_ALIGN)) {
^
include/linux/kernel.h:51:44: note: in definition of macro 'IS_ALIGNED'
#define IS_ALIGNED(x, a) (((x) & ((typeof(x))(a) - 1)) == 0)
^
drivers/net/ethernet/marvell/mvneta.c: In function 'mvneta_rx_refill':
drivers/net/ethernet/marvell/mvneta.c:1802:42: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
mvneta_rx_desc_fill(rx_desc, phys_addr, (u32)data);
^
drivers/net/ethernet/marvell/mvneta.c: In function 'mvneta_rxq_drop_pkts':
drivers/net/ethernet/marvell/mvneta.c:1864:16: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
void *data = (void *)rx_desc->buf_cookie;
^
drivers/net/ethernet/marvell/mvneta.c: In function 'mvneta_rx_swbm':
drivers/net/ethernet/marvell/mvneta.c:1902:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
data = (unsigned char *)rx_desc->buf_cookie;
^
drivers/net/ethernet/marvell/mvneta.c: In function 'mvneta_rx_hwbm':
drivers/net/ethernet/marvell/mvneta.c:2023:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
data = (unsigned char *)rx_desc->buf_cookie;
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_prs_mac_promisc_set':
drivers/net/ethernet/marvell/mvpp2.c:524:33: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define MVPP2_PRS_RI_L2_UCAST ~(BIT(9) | BIT(10))
^
drivers/net/ethernet/marvell/mvpp2.c:1459:33: note: in expansion of macro 'MVPP2_PRS_RI_L2_UCAST'
mvpp2_prs_sram_ri_update(&pe, MVPP2_PRS_RI_L2_UCAST,
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_prs_dsa_tag_set':
drivers/net/ethernet/marvell/mvpp2.c:517:34: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define MVPP2_PRS_RI_VLAN_NONE ~(BIT(2) | BIT(3))
^
drivers/net/ethernet/marvell/mvpp2.c:1572:34: note: in expansion of macro 'MVPP2_PRS_RI_VLAN_NONE'
mvpp2_prs_sram_ri_update(&pe, MVPP2_PRS_RI_VLAN_NONE,
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_prs_dsa_tag_ethertype_set':
drivers/net/ethernet/marvell/mvpp2.c:517:34: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define MVPP2_PRS_RI_VLAN_NONE ~(BIT(2) | BIT(3))
^
drivers/net/ethernet/marvell/mvpp2.c:1642:34: note: in expansion of macro 'MVPP2_PRS_RI_VLAN_NONE'
mvpp2_prs_sram_ri_update(&pe, MVPP2_PRS_RI_VLAN_NONE,
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_prs_etype_init':
drivers/net/ethernet/marvell/mvpp2.c:529:30: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define MVPP2_PRS_RI_L3_UN ~(BIT(12) | BIT(13) | BIT(14))
^
drivers/net/ethernet/marvell/mvpp2.c:2477:32: note: in expansion of macro 'MVPP2_PRS_RI_L3_UN'
mvpp2_prs_sram_ri_update(&pe, MVPP2_PRS_RI_L3_UN,
^
drivers/net/ethernet/marvell/mvpp2.c:529:30: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define MVPP2_PRS_RI_L3_UN ~(BIT(12) | BIT(13) | BIT(14))
^
drivers/net/ethernet/marvell/mvpp2.c:2488:42: note: in expansion of macro 'MVPP2_PRS_RI_L3_UN'
mvpp2_prs_shadow_ri_set(priv, pe.index, MVPP2_PRS_RI_L3_UN,
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_prs_vlan_init':
drivers/net/ethernet/marvell/mvpp2.c:517:34: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define MVPP2_PRS_RI_VLAN_NONE ~(BIT(2) | BIT(3))
^
drivers/net/ethernet/marvell/mvpp2.c:2563:32: note: in expansion of macro 'MVPP2_PRS_RI_VLAN_NONE'
mvpp2_prs_sram_ri_update(&pe, MVPP2_PRS_RI_VLAN_NONE,
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_prs_pppoe_init':
drivers/net/ethernet/marvell/mvpp2.c:529:30: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define MVPP2_PRS_RI_L3_UN ~(BIT(12) | BIT(13) | BIT(14))
^
drivers/net/ethernet/marvell/mvpp2.c:2669:32: note: in expansion of macro 'MVPP2_PRS_RI_L3_UN'
mvpp2_prs_sram_ri_update(&pe, MVPP2_PRS_RI_L3_UN,
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_prs_ip4_init':
drivers/net/ethernet/marvell/mvpp2.c:537:33: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define MVPP2_PRS_RI_L3_UCAST ~(BIT(15) | BIT(16))
^
drivers/net/ethernet/marvell/mvpp2.c:2755:32: note: in expansion of macro 'MVPP2_PRS_RI_L3_UCAST'
mvpp2_prs_sram_ri_update(&pe, MVPP2_PRS_RI_L3_UCAST,
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_prs_ip6_init':
drivers/net/ethernet/marvell/mvpp2.c:529:30: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define MVPP2_PRS_RI_L3_UN ~(BIT(12) | BIT(13) | BIT(14))
^
drivers/net/ethernet/marvell/mvpp2.c:2823:32: note: in expansion of macro 'MVPP2_PRS_RI_L3_UN'
mvpp2_prs_sram_ri_update(&pe, MVPP2_PRS_RI_L3_UN |
^
drivers/net/ethernet/marvell/mvpp2.c:537:33: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define MVPP2_PRS_RI_L3_UCAST ~(BIT(15) | BIT(16))
^
drivers/net/ethernet/marvell/mvpp2.c:2887:32: note: in expansion of macro 'MVPP2_PRS_RI_L3_UCAST'
mvpp2_prs_sram_ri_update(&pe, MVPP2_PRS_RI_L3_UCAST,
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_prs_mac_da_accept':
drivers/net/ethernet/marvell/mvpp2.c:524:33: warning: large integer implicitly truncated to unsigned type [-Woverflow]
#define MVPP2_PRS_RI_L2_UCAST ~(BIT(9) | BIT(10))
^
drivers/net/ethernet/marvell/mvpp2.c:3100:8: note: in expansion of macro 'MVPP2_PRS_RI_L2_UCAST'
ri = MVPP2_PRS_RI_L2_UCAST | MVPP2_PRS_RI_MAC_ME_MASK;
^
In file included from drivers/net/ethernet/marvell/mvpp2.c:13:0:
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_bm_pool_create':
drivers/net/ethernet/marvell/mvpp2.c:3375:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
if (!IS_ALIGNED((u32)bm_pool->virt_addr, MVPP2_BM_POOL_PTR_ALIGN)) {
^
include/linux/kernel.h:51:30: note: in definition of macro 'IS_ALIGNED'
#define IS_ALIGNED(x, a) (((x) & ((typeof(x))(a) - 1)) == 0)
^
drivers/net/ethernet/marvell/mvpp2.c:3375:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
if (!IS_ALIGNED((u32)bm_pool->virt_addr, MVPP2_BM_POOL_PTR_ALIGN)) {
^
include/linux/kernel.h:51:44: note: in definition of macro 'IS_ALIGNED'
#define IS_ALIGNED(x, a) (((x) & ((typeof(x))(a) - 1)) == 0)
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_bm_bufs_free':
drivers/net/ethernet/marvell/mvpp2.c:3433:21: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
dev_kfree_skb_any((struct sk_buff *)vaddr);
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_bm_bufs_add':
drivers/net/ethernet/marvell/mvpp2.c:3647:47: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
mvpp2_pool_refill(port, bm, (u32)phys_addr, (u32)skb);
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_rx_refill':
drivers/net/ethernet/marvell/mvpp2.c:5011:46: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
mvpp2_pool_refill(port, bm, (u32)phys_addr, (u32)skb);
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_buff_hdr_rx':
drivers/net/ethernet/marvell/mvpp2.c:5066:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
skb = (struct sk_buff *)buff_virt_addr;
^
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_rx':
drivers/net/ethernet/marvell/mvpp2.c:5136:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
skb = (struct sk_buff *)rx_desc->buf_cookie;
^
Introduced by commit
a0627f776a45 ("net: marvell: Allow drivers to be built with COMPILE_TEST")
"a few warnings" is a matter of perception. :-(
Please fix these up.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: [PATCH ethtool v3 1/2] ethtool-copy.h:sync with net
From: Florian Fainelli @ 2016-11-22 1:03 UTC (permalink / raw)
To: Allan W. Nielsen, netdev; +Cc: andrew, raju.lakkaraju
In-Reply-To: <1479384480-31201-2-git-send-email-allan.nielsen@microsemi.com>
On 11/17/2016 04:07 AM, Allan W. Nielsen wrote:
> From: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
>
> This covers kernel changes upto:
>
> commit f5a4732f85613b3fb43f8bc33a017e3db3b3605a
> Author: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
> Date: Wed Nov 9 16:33:09 2016 +0530
>
> ethtool: (uapi) Add ETHTOOL_PHY_DOWNSHIFT to PHY tunables
>
> For operation in cabling environments that are incompatible with
> 1000BASE-T, PHY device may provide an automatic link speed downshift
> operation. When enabled, the device automatically changes its 1000BASE-T
> auto-negotiation to the next slower speed after a configured number of
> failed attempts at 1000BASE-T. This feature is useful in setting up in
> networks using older cable installations that include only pairs A and B,
> and not pairs C and D.
>
> Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
> Signed-off-by: Allan W. Nielsen <allan.nielsen@microsemi.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2016-11-22 0:58 UTC (permalink / raw)
To: David Miller, Networking
Cc: linux-next, linux-kernel, Giuseppe CAVALLARO, LABBE Corentin
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
between commit:
ba1ffd74df74 ("stmmac: fix PTP support for GMAC4")
from the net tree and commit:
38ddc59d65b6 ("net: stmmac: replace all pr_xxx by their netdev_xxx counterpart")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 1f9ec02fa7f8,fbd1cd79233d..000000000000
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@@ -2484,7 -2493,7 +2493,7 @@@ static int stmmac_rx(struct stmmac_pri
if (netif_msg_rx_status(priv)) {
void *rx_head;
- pr_info(">>>>>> %s: descriptor ring:\n", __func__);
- netdev_dbg(priv->dev, "%s: descriptor ring:\n", __func__);
++ netdev_info(priv->dev, ">>>>>> %s: descriptor ring:\n", __func__);
if (priv->extend_desc)
rx_head = (void *)priv->dma_erx;
else
@@@ -2571,11 -2577,11 +2580,11 @@@
frame_len -= ETH_FCS_LEN;
if (netif_msg_rx_status(priv)) {
- pr_info("\tdesc: %p [entry %d] buff=0x%x\n",
- p, entry, des);
- netdev_dbg(priv->dev, "\tdesc: %p [entry %d] buff=0x%x\n",
- p, entry, des);
++ netdev_info(priv->dev, "\tdesc: %p [entry %d] buff=0x%x\n",
++ p, entry, des);
if (frame_len > ETH_FRAME_LEN)
- pr_debug("\tframe size %d, COE: %d\n",
- frame_len, status);
+ netdev_dbg(priv->dev, "frame size %d, COE: %d\n",
+ frame_len, status);
}
/* The zero-copy is always used for all the sizes
@@@ -2628,8 -2635,11 +2638,9 @@@
DMA_FROM_DEVICE);
}
- stmmac_get_rx_hwtstamp(priv, entry, skb);
-
if (netif_msg_pktdata(priv)) {
- pr_debug("frame received (%dbytes)", frame_len);
+ netdev_dbg(priv->dev, "frame received (%dbytes)",
+ frame_len);
print_pkt(skb->data, frame_len);
}
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox