* Re: [PATCH v2 net-next 1/4] bpf: add helper bpf_perf_read_counter_time for perf event array map
From: Peter Zijlstra @ 2017-09-04 7:46 UTC (permalink / raw)
To: Yonghong Song; +Cc: rostedt, ast, daniel, netdev, kernel-team
In-Reply-To: <20170902054824.371962-2-yhs@fb.com>
On Fri, Sep 01, 2017 at 10:48:21PM -0700, Yonghong Song wrote:
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index b14095b..5a50808 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -898,7 +898,8 @@ perf_event_create_kernel_counter(struct perf_event_attr *attr,
> void *context);
> extern void perf_pmu_migrate_context(struct pmu *pmu,
> int src_cpu, int dst_cpu);
> -int perf_event_read_local(struct perf_event *event, u64 *value);
> +int perf_event_read_local(struct perf_event *event, u64 *value,
> + u64 *enabled, u64 *running);
> extern u64 perf_event_read_value(struct perf_event *event,
> u64 *enabled, u64 *running);
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 8c01572..20c4039 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -3670,7 +3670,8 @@ static inline u64 perf_event_count(struct perf_event *event)
> * will not be local and we cannot read them atomically
> * - must not have a pmu::count method
> */
> -int perf_event_read_local(struct perf_event *event, u64 *value)
> +int perf_event_read_local(struct perf_event *event, u64 *value,
> + u64 *enabled, u64 *running)
> {
> unsigned long flags;
> int ret = 0;
> @@ -3694,7 +3695,7 @@ int perf_event_read_local(struct perf_event *event, u64 *value)
> * It must not have a pmu::count method, those are not
> * NMI safe.
> */
> - if (event->pmu->count) {
> + if (value && event->pmu->count) {
> ret = -EOPNOTSUPP;
> goto out;
> }
No, value _must_ be !NULL. Otherwise you allow getting timestamps
independently from the count value and that is broken.
The {value, enabled, running} tuple is temporally related.
> @@ -3718,10 +3719,16 @@ int perf_event_read_local(struct perf_event *event, u64 *value)
> * or local to this CPU. Furthermore it means its ACTIVE (otherwise
> * oncpu == -1).
> */
> - if (event->oncpu == smp_processor_id())
> - event->pmu->read(event);
> -
> - *value = local64_read(&event->count);
> + if (value) {
> + if (event->oncpu == smp_processor_id())
> + event->pmu->read(event);
> + *value = local64_read(&event->count);
> + }
> + if (enabled && running) {
> + u64 ctx_time = event->shadow_ctx_time + perf_clock();
> + *enabled = ctx_time - event->tstamp_enabled;
> + *running = ctx_time - event->tstamp_running;
> + }
> out:
> local_irq_restore(flags);
Please make that something like:
u64 now = event->shadow_ctx_time + perf_clock();
if (enabled)
*enabled = now - event->tstamp_enabled;
if (event->oncpu == smp_processor_id()) {
event->pmu->read(event);
if (running)
*running = now - event->tstamp_running;
} else {
*running = event->total_time_running;
}
And I'll fix it up when I make:
https://lkml.kernel.org/r/20170831171837.njnc6r6elsvkl7lt@hirez.programming.kicks-ass.net
happen.
^ permalink raw reply
* [net v2] gianfar: Fix Tx flow control deactivation
From: Claudiu Manoil @ 2017-09-04 7:45 UTC (permalink / raw)
To: netdev; +Cc: David S . Miller
The wrong register is checked for the Tx flow control bit,
it should have been maccfg1 not maccfg2.
This went unnoticed for so long probably because the impact is
hardly visible, not to mention the tangled code from adjust_link().
First, link flow control (i.e. handling of Rx/Tx link level pause frames)
is disabled by default (needs to be enabled via 'ethtool -A').
Secondly, maccfg2 always returns 0 for tx_flow_oldval (except for a few
old boards), which results in Tx flow control remaining always on
once activated.
Should be queued for -stable, thanks.
Fixes: 45b679c9a3ccd9e34f28e6ec677b812a860eb8eb ("gianfar: Implement PAUSE frame generation support")
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
v2: "Fixes" tag formatting and removed CC: stable from comments.
drivers/net/ethernet/freescale/gianfar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index c4b4b0a..5be52d8 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -3687,7 +3687,7 @@ static noinline void gfar_update_link_state(struct gfar_private *priv)
u32 tempval1 = gfar_read(®s->maccfg1);
u32 tempval = gfar_read(®s->maccfg2);
u32 ecntrl = gfar_read(®s->ecntrl);
- u32 tx_flow_oldval = (tempval & MACCFG1_TX_FLOW);
+ u32 tx_flow_oldval = (tempval1 & MACCFG1_TX_FLOW);
if (phydev->duplex != priv->oldduplex) {
if (!(phydev->duplex))
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 1/1] sched: Use __qdisc_drop instead of kfree_skb in sch_prio and sch_qfq
From: gfree.wind @ 2017-09-04 6:21 UTC (permalink / raw)
To: jhs, xiyou.wangcong, jiri, davem, edumazet, netdev; +Cc: Gao Feng
From: Gao Feng <gfree.wind@vip.163.com>
The commit 520ac30f4551 ("net_sched: drop packets after root qdisc lock
is released) made a big change of tc for performance. There are two points
left in sch_prio and sch_qfq which are not changed with that commit. Now
enhance them now with __qdisc_drop.
Signed-off-by: Gao Feng <gfree.wind@vip.163.com>
---
net/sched/sch_prio.c | 2 +-
net/sched/sch_qfq.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sched/sch_prio.c b/net/sched/sch_prio.c
index f31b28f..2dd6c68 100644
--- a/net/sched/sch_prio.c
+++ b/net/sched/sch_prio.c
@@ -80,7 +80,7 @@ struct prio_sched_data {
if (ret & __NET_XMIT_BYPASS)
qdisc_qstats_drop(sch);
- kfree_skb(skb);
+ __qdisc_drop(skb, to_free);
return ret;
}
#endif
diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c
index cd661a7..6ddfd49 100644
--- a/net/sched/sch_qfq.c
+++ b/net/sched/sch_qfq.c
@@ -1215,7 +1215,7 @@ static int qfq_enqueue(struct sk_buff *skb, struct Qdisc *sch,
if (cl == NULL) {
if (err & __NET_XMIT_BYPASS)
qdisc_qstats_drop(sch);
- kfree_skb(skb);
+ __qdisc_drop(skb, to_free);
return err;
}
pr_debug("qfq_enqueue: cl = %x\n", cl->common.classid);
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] ip6_tunnel: fix setting hop_limit value for ipv6 tunnel
From: Haishuang Yan @ 2017-09-04 6:17 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI
Cc: netdev, linux-kernel, Haishuang Yan
In-Reply-To: <1504505848-3331-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
Similar to vxlan/geneve tunnel, if hop_limit is zero, it should fall
back to ip6_dst_hoplimt().
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
---
net/ipv6/ip6_tunnel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 3a0ba2a..10a693a 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1184,6 +1184,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev, __u8 dsfield,
init_tel_txopt(&opt, encap_limit);
ipv6_push_frag_opts(skb, &opt.ops, &proto);
}
+ hop_limit = hop_limit ? : ip6_dst_hoplimit(dst);
/* Calculate max headroom for all the headers and adjust
* needed_headroom if necessary.
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3] ip6_tunnel: Correct tos value in collect_md mode
From: Haishuang Yan @ 2017-09-04 6:17 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI
Cc: netdev, linux-kernel, Haishuang Yan, Peter Dawson
Same as ip_gre, geneve and vxlan, use key->tos as traffic class value.
CC: Peter Dawson <petedaws@gmail.com>
Fixes: 0e9a709560db ("ip6_tunnel, ip6_gre: fix setting of DSCP on
encapsulated packets”)
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
---
Changes since v3:
* Add fixes information
* Remove obsoleted RT_TOS mask
---
net/ipv6/ip6_tunnel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index ef99d59..9d65918 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1249,7 +1249,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev, __u8 dsfield,
fl6.flowi6_proto = IPPROTO_IPIP;
fl6.daddr = key->u.ipv6.dst;
fl6.flowlabel = key->label;
- dsfield = ip6_tclass(key->label);
+ dsfield = key->tos;
} else {
if (!(t->parms.flags & IP6_TNL_F_IGN_ENCAP_LIMIT))
encap_limit = t->parms.encap_limit;
@@ -1320,7 +1320,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev, __u8 dsfield,
fl6.flowi6_proto = IPPROTO_IPV6;
fl6.daddr = key->u.ipv6.dst;
fl6.flowlabel = key->label;
- dsfield = ip6_tclass(key->label);
+ dsfield = key->tos;
} else {
offset = ip6_tnl_parse_tlv_enc_lim(skb, skb_network_header(skb));
/* ip6_tnl_parse_tlv_enc_lim() might have reallocated skb->head */
--
1.8.3.1
^ permalink raw reply related
* We'll ship you a 30-day supply of our weight loss product
From: info @ 2017-09-02 8:45 UTC (permalink / raw)
To: netdev
Taking a premium quality weight loss aid solution like ours daily is simply the only way to make sure your body gets the vitamins it needs to burn excessive fat and stay active.
It was created with premium additives, our diet aid solution will help you feel amazing and look your best!
Our diet pill includes over 24 different nutrients and minerals and it helps preserve your:
Boosted metabolism,
Immune system,
Physical energy,
Muscle mass.
We will send you a 25-day supply of our weight reduction supplement only if you use this link within the next three days.
This URL is only provided for this IP
http://vztgjn.greenerpasturesip.xyz/OS8yLzIwMTc7MTA6NDU6NTI=
^ permalink raw reply
* [PATCH net-next] cxgb4: Ignore MPS_TX_INT_CAUSE[Bubble] for T6
From: Ganesh Goudar @ 2017-09-04 5:55 UTC (permalink / raw)
To: netdev, davem; +Cc: nirranjan, indranil, venkatesh, Ganesh Goudar, Casey Leedom
MPS_TX_INT_CAUSE[Bubble] is a normal condition for T6, hence
ignore this interrupt for T6.
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Signed-off-by: Casey Leedom <leedom@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index 08624db..b0f9aea 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -4548,6 +4548,18 @@ static void mps_intr_handler(struct adapter *adapter)
{ FRMERR_F, "MPS Tx framing error", -1, 1 },
{ 0 }
};
+ static const struct intr_info t6_mps_tx_intr_info[] = {
+ { TPFIFO_V(TPFIFO_M), "MPS Tx TP FIFO parity error", -1, 1 },
+ { NCSIFIFO_F, "MPS Tx NC-SI FIFO parity error", -1, 1 },
+ { TXDATAFIFO_V(TXDATAFIFO_M), "MPS Tx data FIFO parity error",
+ -1, 1 },
+ { TXDESCFIFO_V(TXDESCFIFO_M), "MPS Tx desc FIFO parity error",
+ -1, 1 },
+ /* MPS Tx Bubble is normal for T6 */
+ { SECNTERR_F, "MPS Tx SOP/EOP error", -1, 1 },
+ { FRMERR_F, "MPS Tx framing error", -1, 1 },
+ { 0 }
+ };
static const struct intr_info mps_trc_intr_info[] = {
{ FILTMEM_V(FILTMEM_M), "MPS TRC filter parity error", -1, 1 },
{ PKTFIFO_V(PKTFIFO_M), "MPS TRC packet FIFO parity error",
@@ -4579,7 +4591,9 @@ static void mps_intr_handler(struct adapter *adapter)
fat = t4_handle_intr_status(adapter, MPS_RX_PERR_INT_CAUSE_A,
mps_rx_intr_info) +
t4_handle_intr_status(adapter, MPS_TX_INT_CAUSE_A,
- mps_tx_intr_info) +
+ is_t6(adapter->params.chip)
+ ? t6_mps_tx_intr_info
+ : mps_tx_intr_info) +
t4_handle_intr_status(adapter, MPS_TRC_INT_CAUSE_A,
mps_trc_intr_info) +
t4_handle_intr_status(adapter, MPS_STAT_PERR_INT_CAUSE_SRAM_A,
--
2.1.0
^ permalink raw reply related
* Re: [PATCH v3 2/3] dt-binding: net: sfp binding documentation
From: Baruch Siach @ 2017-09-04 5:55 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Rob Herring, Mark Rutland, Andrew Lunn, Florian Fainelli,
David S. Miller, netdev, devicetree, Sergei Shtylyov
In-Reply-To: <20170903204634.GZ20805@n2100.armlinux.org.uk>
Hi Russell,
On Sun, Sep 03, 2017 at 09:46:35PM +0100, Russell King - ARM Linux wrote:
> On Sun, Sep 03, 2017 at 03:31:13PM +0300, Baruch Siach wrote:
> > Add device-tree binding documentation SFP transceivers. Support for SFP
> > transceivers has been recently introduced (drivers/net/phy/sfp.c).
> >
> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > ---
> > v3:
> > Mention gpios phandle and specifier
> > Mention the polarity of each gpio
> > Fix example property names
> >
> > v2:
> > Rename -gpio properties to -gpios
> > Rename the rate-select-gpio property to rate-select0-gpios
> > Add the rate-select1-gpios property
> > Add examples
> > ---
> > Documentation/devicetree/bindings/net/sff,sfp.txt | 78 +++++++++++++++++++++++
> > 1 file changed, 78 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/net/sff,sfp.txt
> >
> > diff --git a/Documentation/devicetree/bindings/net/sff,sfp.txt b/Documentation/devicetree/bindings/net/sff,sfp.txt
> > new file mode 100644
> > index 000000000000..b98ee5945265
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/sff,sfp.txt
> > @@ -0,0 +1,78 @@
> > +Small Form Factor (SFF) Committee Small Form-factor Pluggable (SFP)
> > +Transceiver
> > +
> > +Required properties:
> > +
> > +- compatible : must be "sff,sfp"
> > +
> > +Optional Properties:
> > +
> > +- i2c-bus : phandle of an I2C bus controller for the SFP two wire serial
> > + interface
> > +
> > +- moddef0-gpios : GPIO phandle and a single specifier of the MOD-DEF0 (AKA
> > + Mod_ABS) module presence input gpio signal, active (module absent) high
> > +
> > +- los-gpios : GPIO phandle and a single specifier of the Receiver Loss of
> > + Signal Indication input gpio signal, active (signal lost) high
> > +
> > +- tx-fault-gpios : GPIO phandle and a single specifier of the Module
> > + Transmitter Fault input gpio signal, active (fault condition) high
> > +
> > +- tx-disable-gpios : GPIO phandle and a single specifier of the Transmitter
> > + Disable output gpio signal, active (Tx disable) high
> > +
> > +- rate-select0-gpios : GPIO phandle and a single specifier of the Rx Signaling
> > + Rate Select (AKA RS0) output gpio signal, low: low Rx rate, high: high Rx
> > + rate
> > +
> > +- rate-select1-gpios : GPIO phandle and a single specifier of the Tx Signaling
> > + Rate Select (AKA RS1) output gpio signal (SFP+ only), low: low Tx rate,
> > + high: high Tx rate
> > +
> > +Example #1: Direct serdes to SFP connection
> > +
> > +sfp_eth3: sfp-eth3 {
> > + compatible = "sff,sfp";
> > + i2c-bus = <&sfp_1g_i2c>;
> > + los-gpios = <&cpm_gpio2 22 GPIO_ACTIVE_HIGH>;
> > + moddef0-gpios = <&cpm_gpio2 21 GPIO_ACTIVE_LOW>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&cpm_sfp_1g_pins &cps_sfp_1g_pins>;
> > + tx-disable-gpios = <&cps_gpio1 24 GPIO_ACTIVE_HIGH>;
> > + tx-fault-gpios = <&cpm_gpio2 19 GPIO_ACTIVE_HIGH>;
> > +};
> > +
> > +&cps_emac3 {
> > + phy-mode = "sgmii";
> > + phy-names = "comphy";
> > + phys = <&cps_comphy 5 COMPHY_SGMII2>;
>
> I don't like this level of example - SGMII is Cisco SGMII which is not
> the same as 1000Base-X - the two are incompatible. Fibre SFP modules
> only work with 1000Base-X.
>
> The SFP/phylink takes care of informing the MAC which mode it should
> be in, and the MAC must configure itself appropriately in response to
> that, otherwise the module can't be supported.
So, if I understand you correctly, the PHY mode should not be coded in the DT
since the mode is run-time configurable, and depends on the SFP module. Is
that correct?
How about the following then:
&cps_emac3 {
phy-names = "comphy";
phys = <&cps_comphy 5>;
sfp = <&sfp_eth3>;
};
Thanks,
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH net-next] cxgb4: Fix pause frame count in t4_get_port_stats
From: Ganesh Goudar @ 2017-09-04 5:47 UTC (permalink / raw)
To: netdev, davem; +Cc: nirranjan, indranil, venkatesh, Ganesh Goudar, Casey Leedom
MPS_STAT_CTL[CountPauseStatTx] and MPS_STAT_CTL[CountPauseStatRx]
only control whether or not Pause Frames will be counted as part
of the 64-Byte Tx/Rx Frame counters. These bits do not control
whether Pause Frames are counted in the Total Tx/Rx Frames/Bytes
counters.
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Signed-off-by: Casey Leedom <leedom@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index b0f9aea..b65ce26 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -6001,10 +6001,8 @@ void t4_get_port_stats(struct adapter *adap, int idx, struct port_stats *p)
p->tx_ppp7 = GET_STAT(TX_PORT_PPP7);
if (CHELSIO_CHIP_VERSION(adap->params.chip) >= CHELSIO_T5) {
- if (stat_ctl & COUNTPAUSESTATTX_F) {
- p->tx_frames -= p->tx_pause;
- p->tx_octets -= p->tx_pause * 64;
- }
+ if (stat_ctl & COUNTPAUSESTATTX_F)
+ p->tx_frames_64 -= p->tx_pause;
if (stat_ctl & COUNTPAUSEMCTX_F)
p->tx_mcast_frames -= p->tx_pause;
}
@@ -6037,10 +6035,8 @@ void t4_get_port_stats(struct adapter *adap, int idx, struct port_stats *p)
p->rx_ppp7 = GET_STAT(RX_PORT_PPP7);
if (CHELSIO_CHIP_VERSION(adap->params.chip) >= CHELSIO_T5) {
- if (stat_ctl & COUNTPAUSESTATRX_F) {
- p->rx_frames -= p->rx_pause;
- p->rx_octets -= p->rx_pause * 64;
- }
+ if (stat_ctl & COUNTPAUSESTATRX_F)
+ p->rx_frames_64 -= p->rx_pause;
if (stat_ctl & COUNTPAUSEMCRX_F)
p->rx_mcast_frames -= p->rx_pause;
}
--
2.1.0
^ permalink raw reply related
* [PATCH net-next] cxgb4: fix memory leak
From: Ganesh Goudar @ 2017-09-04 5:46 UTC (permalink / raw)
To: netdev, davem; +Cc: nirranjan, indranil, venkatesh, Ganesh Goudar
do not reuse the loop counter which is used iterate over
the ports, so that sched_tbl will be freed for all the ports.
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/sched.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/sched.c b/drivers/net/ethernet/chelsio/cxgb4/sched.c
index 02acff7..9148abb 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sched.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sched.c
@@ -533,10 +533,10 @@ struct sched_table *t4_init_sched(unsigned int sched_size)
void t4_cleanup_sched(struct adapter *adap)
{
struct sched_table *s;
- unsigned int i;
+ unsigned int j, i;
- for_each_port(adap, i) {
- struct port_info *pi = netdev2pinfo(adap->port[i]);
+ for_each_port(adap, j) {
+ struct port_info *pi = netdev2pinfo(adap->port[j]);
s = pi->sched_tbl;
for (i = 0; i < s->sched_size; i++) {
--
2.1.0
^ permalink raw reply related
* Re: [PATCH][next] rocker: fix kcalloc parameter order
From: Zahari Doychev @ 2017-09-04 5:40 UTC (permalink / raw)
To: Zahari Doychev; +Cc: jiri, netdev
In-Reply-To: <4d8a3c58c2a4e89319034f5faf41ba4682dc15ae.1504461594.git.zahari.doychev@linux.com>
On Sun, Sep 03, 2017 at 10:26:03PM +0200, Zahari Doychev wrote:
> The function calls to kcalloc use wrong parameter order. The flags
> have to be passed as last parameter.
>
> The change was done using the following coccinelle script:
>
> @@
> expression E1,E2;
> type T;
> @@
>
> -kcalloc(E1, E2, sizeof(T))
> +kcalloc(E2, sizeof(T), E1)
>
> Signed-off-by: Zahari Doychev <zahari.doychev@linux.com>
> ---
> drivers/net/ethernet/rocker/rocker_ofdpa.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/rocker/rocker_ofdpa.c b/drivers/net/ethernet/rocker/rocker_ofdpa.c
> index da4e26b53a52..2708451ce22a 100644
> --- a/drivers/net/ethernet/rocker/rocker_ofdpa.c
> +++ b/drivers/net/ethernet/rocker/rocker_ofdpa.c
> @@ -1177,7 +1177,7 @@ static int ofdpa_group_l2_fan_out(struct ofdpa_port *ofdpa_port,
> entry->group_id = group_id;
> entry->group_count = group_count;
>
> - entry->group_ids = kcalloc(flags, group_count, sizeof(u32));
> + entry->group_ids = kcalloc(group_count, sizeof(u32), flags);
I think that the flags are also not used correctly, so I will have to resend
the patch.
> if (!entry->group_ids) {
> kfree(entry);
> return -ENOMEM;
> @@ -1456,7 +1456,7 @@ static int ofdpa_port_vlan_flood_group(struct ofdpa_port *ofdpa_port,
> int err = 0;
> int i;
>
> - group_ids = kcalloc(flags, port_count, sizeof(u32));
> + group_ids = kcalloc(port_count, sizeof(u32), flags);
> if (!group_ids)
> return -ENOMEM;
>
> --
> 2.13.0
>
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the rockchip tree
From: Stephen Rothwell @ 2017-09-04 5:26 UTC (permalink / raw)
To: David Miller, Networking, Heiko Stuebner, Olof Johansson,
Arnd Bergmann, ARM
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, David Wu,
Rocky Hao, Joseph Chen
In-Reply-To: <20170822112414.06f3b00f@canb.auug.org.au>
Hi all,
On Tue, 22 Aug 2017 11:24:14 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> arch/arm64/boot/dts/rockchip/rk3328-evb.dts
>
> between commits:
>
> ab78718bda79 ("arm64: dts: rockchip: Enable tsadc module on RK3328 eavluation board")
> 1e28037ec88e ("arm64: dts: rockchip: add rk805 node for rk3328-evb")
>
> from the rockchip tree and commit:
>
> 4b05bc6157eb ("ARM64: dts: rockchip: Enable gmac2phy for rk3328-evb")
>
> 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 arch/arm64/boot/dts/rockchip/rk3328-evb.dts
> index 86605ae7b6f5,b9f36dad17e6..000000000000
> --- a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
> @@@ -51,147 -51,24 +51,164 @@@
> stdout-path = "serial2:1500000n8";
> };
>
> + dc_12v: dc-12v {
> + compatible = "regulator-fixed";
> + regulator-name = "dc_12v";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <12000000>;
> + regulator-max-microvolt = <12000000>;
> + };
> +
> + vcc_phy: vcc-phy-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_phy";
> + regulator-always-on;
> + regulator-boot-on;
> + };
> ++
> + vcc_sys: vcc-sys {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + vin-supply = <&dc_12v>;
> + };
> };
>
> + &gmac2phy {
> + phy-supply = <&vcc_phy>;
> + clock_in_out = "output";
> + assigned-clocks = <&cru SCLK_MAC2PHY_SRC>;
> + assigned-clock-rate = <50000000>;
> + assigned-clocks = <&cru SCLK_MAC2PHY>;
> + assigned-clock-parents = <&cru SCLK_MAC2PHY_SRC>;
> + status = "okay";
> + };
> +
> +&i2c1 {
> + status = "okay";
> +
> + rk805: rk805@18 {
> + compatible = "rockchip,rk805";
> + reg = <0x18>;
> + interrupt-parent = <&gpio2>;
> + interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
> + #clock-cells = <1>;
> + clock-output-names = "xin32k", "rk805-clkout2";
> + gpio-controller;
> + #gpio-cells = <2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pmic_int_l>;
> + rockchip,system-power-controller;
> + wakeup-source;
> +
> + vcc1-supply = <&vcc_sys>;
> + vcc2-supply = <&vcc_sys>;
> + vcc3-supply = <&vcc_sys>;
> + vcc4-supply = <&vcc_sys>;
> + vcc5-supply = <&vcc_io>;
> + vcc6-supply = <&vcc_io>;
> +
> + regulators {
> + vdd_logic: DCDC_REG1 {
> + regulator-name = "vdd_logic";
> + regulator-min-microvolt = <712500>;
> + regulator-max-microvolt = <1450000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1000000>;
> + };
> + };
> +
> + vdd_arm: DCDC_REG2 {
> + regulator-name = "vdd_arm";
> + regulator-min-microvolt = <712500>;
> + regulator-max-microvolt = <1450000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <950000>;
> + };
> + };
> +
> + vcc_ddr: DCDC_REG3 {
> + regulator-name = "vcc_ddr";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + };
> + };
> +
> + vcc_io: DCDC_REG4 {
> + regulator-name = "vcc_io";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <3300000>;
> + };
> + };
> +
> + vcc_18: LDO_REG1 {
> + regulator-name = "vcc_18";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1800000>;
> + };
> + };
> +
> + vcc18_emmc: LDO_REG2 {
> + regulator-name = "vcc18_emmc";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1800000>;
> + };
> + };
> +
> + vdd_10: LDO_REG3 {
> + regulator-name = "vdd_10";
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1000000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1000000>;
> + };
> + };
> + };
> + };
> +};
> +
> +&pinctrl {
> + pmic {
> + pmic_int_l: pmic-int-l {
> + rockchip,pins = <2 RK_PA6 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
> +};
> +
> +&tsadc {
> + status = "okay";
> +};
> +
> &uart2 {
> status = "okay";
> };
Just a reminder that these conflicts still exist.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* RE: netdev carrier changes is one even after ethernet link up.
From: Bhadram Varka @ 2017-09-04 5:10 UTC (permalink / raw)
To: Florian Fainelli, andrew@lunn.ch; +Cc: linux-netdev
In-Reply-To: <a7bf6cf0-c534-95f9-47f6-ee56a95fe961@gmail.com>
> -----Original Message-----
> From: Florian Fainelli [mailto:f.fainelli@gmail.com]
> Sent: Saturday, September 02, 2017 7:25 AM
> To: Bhadram Varka <vbhadram@nvidia.com>; andrew@lunn.ch
> Cc: linux-netdev <netdev@vger.kernel.org>
> Subject: Re: netdev carrier changes is one even after ethernet link up.
>
> On 08/31/2017 10:49 PM, Bhadram Varka wrote:
> > Thanks for responding. Now responding inline
> >
> >> -----Original Message-----
> >> From: Florian Fainelli [mailto:f.fainelli@gmail.com]
> >> Sent: Friday, September 01, 2017 5:53 AM
> >> To: Bhadram Varka <vbhadram@nvidia.com>; andrew@lunn.ch
> >> Cc: linux-netdev <netdev@vger.kernel.org>
> >> Subject: Re: netdev carrier changes is one even after ethernet link up.
> >>
> >> On 08/30/2017 10:53 PM, Bhadram Varka wrote:
> >>> Hi,
> >>>
> >>>
> >>>
> >>> I have observed that carrier_changes is one even in case of the
> >>> ethernet link is up.
> >>>
> >>>
> >>>
> >>> After investigating the code below is my observation -
> >>>
> >>>
> >>>
> >>> ethernet_driver_probe()
> >>>
> >>> +--->phy_connect()
> >>>
> >>> | +--->phy_attach_direct()
> >>>
> >>> | +---> netif_carrier_off() : which increments
> >>> carrier_changes to one.
> >>>
> >>> +--->register_netdevice() : will the carrier_changes becomes zero here ?
> >>>
> >>> +--->netif_carrier_off(): not increment the carrier_changes since
> >>> __LINK_STATE_NOCARRIER already set.
> >>>
> >>>
> >>>
> >>> From ethernet driver open will start the PHY and trigger the
> >>> phy_state_machine.
> >>>
> >>> Phy_state_machine workqueue calling netif_carrier_on() once the link
> >>> is
> >> UP.
> >>>
> >>> netif_carrier_on() increments the carrier_changes by one.
> >>
> >> If the call trace is correct, then there is at least two problems here:
> >>
> >> - phy_connect() does start the PHY machine which means that as soon
> >> as it detects a link state of any kind (up or down) it can call
> >> netif_carrier_off() respectively netif_carrier_on()
> >>
> >> - as soon as you call register_netdevice() notifiers run and other
> >> parts of the kernel or user-space programs can see an inconsistent
> >> link state
> >>
> >> I would suggest doing the following sequence instead:
> >>
> >> netif_carrier_off()
> >> register_netdevice()
> >> phy_connect()
> >>
> >> Which should result in a consistent link state and carrier value.
> >>
> > Yes, It will address the issue.
> >
> > If we did the phy_conect in ndo_open it will make the carrier changes as
> two. But if we did in probe function then it's not working.
> >
> > In ethernet driver probe - (below sequence is not working)
> > phy_connect()
> > register_netdevice()
> > netif_carrier_off()
> >
> > working sequence:
> > In probe():
> > register_netdevice()
> > ndo_open:
> > phy_connect()
> >
> > After reverting - https://lkml.org/lkml/2016/1/9/173 this works if we do
> phy_connect in probe as well.
>
> But as mentioned before you should not be doing the PHY probe in your
> driver's probe function for different reasons:
>
> - the probe function's responsibility is to initialize the driver and the HW to a
> state where they both have everything needed but it should be in quiesced
> state. There is no guarantee that your network device may ever be used
> after probe unless something calls ndo_open(), you should therefore keep
> all resources to a minimum: memory allocated, HW powered down etc.
>
> - there is a race condition between the PHY state machine started in
> phy_connect(), and when register_netdevice() is called and notifiers running
> which can lead to an inconsistent state for the carrier
Agreed. But I could see lot of drivers performing the phy_connect() in driver_probe() function itself.
Also observed that these drivers are performing netif_carrier_off() after register_netdevice().
My point is that why do we need to do netif_carrier_off() in phy_connect() since we already doing the same after register_netdevice() in MAC driver ?
Thanks!
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
^ permalink raw reply
* RE: netdev carrier changes is one even after ethernet link up.
From: Bhadram Varka @ 2017-09-04 5:07 UTC (permalink / raw)
To: Florian Fainelli, andrew@lunn.ch; +Cc: linux-netdev
In-Reply-To: <a7bf6cf0-c534-95f9-47f6-ee56a95fe961@gmail.com>
Hi Florian,
> -----Original Message-----
> From: Florian Fainelli [mailto:f.fainelli@gmail.com]
> Sent: Saturday, September 02, 2017 7:25 AM
> To: Bhadram Varka <vbhadram@nvidia.com>; andrew@lunn.ch
> Cc: linux-netdev <netdev@vger.kernel.org>
> Subject: Re: netdev carrier changes is one even after ethernet link up.
>
> On 08/31/2017 10:49 PM, Bhadram Varka wrote:
> > Thanks for responding. Now responding inline
> >
> >> -----Original Message-----
> >> From: Florian Fainelli [mailto:f.fainelli@gmail.com]
> >> Sent: Friday, September 01, 2017 5:53 AM
> >> To: Bhadram Varka <vbhadram@nvidia.com>; andrew@lunn.ch
> >> Cc: linux-netdev <netdev@vger.kernel.org>
> >> Subject: Re: netdev carrier changes is one even after ethernet link up.
> >>
> >> On 08/30/2017 10:53 PM, Bhadram Varka wrote:
> >>> Hi,
> >>>
> >>>
> >>>
> >>> I have observed that carrier_changes is one even in case of the
> >>> ethernet link is up.
> >>>
> >>>
> >>>
> >>> After investigating the code below is my observation -
> >>>
> >>>
> >>>
> >>> ethernet_driver_probe()
> >>>
> >>> +--->phy_connect()
> >>>
> >>> | +--->phy_attach_direct()
> >>>
> >>> | +---> netif_carrier_off() : which increments
> >>> carrier_changes to one.
> >>>
> >>> +--->register_netdevice() : will the carrier_changes becomes zero here ?
> >>>
> >>> +--->netif_carrier_off(): not increment the carrier_changes since
> >>> __LINK_STATE_NOCARRIER already set.
> >>>
> >>>
> >>>
> >>> From ethernet driver open will start the PHY and trigger the
> >>> phy_state_machine.
> >>>
> >>> Phy_state_machine workqueue calling netif_carrier_on() once the link
> >>> is
> >> UP.
> >>>
> >>> netif_carrier_on() increments the carrier_changes by one.
> >>
> >> If the call trace is correct, then there is at least two problems here:
> >>
> >> - phy_connect() does start the PHY machine which means that as soon
> >> as it detects a link state of any kind (up or down) it can call
> >> netif_carrier_off() respectively netif_carrier_on()
> >>
> >> - as soon as you call register_netdevice() notifiers run and other
> >> parts of the kernel or user-space programs can see an inconsistent
> >> link state
> >>
> >> I would suggest doing the following sequence instead:
> >>
> >> netif_carrier_off()
> >> register_netdevice()
> >> phy_connect()
> >>
> >> Which should result in a consistent link state and carrier value.
> >>
> > Yes, It will address the issue.
> >
> > If we did the phy_conect in ndo_open it will make the carrier changes as
> two. But if we did in probe function then it's not working.
> >
> > In ethernet driver probe - (below sequence is not working)
> > phy_connect()
> > register_netdevice()
> > netif_carrier_off()
> >
> > working sequence:
> > In probe():
> > register_netdevice()
> > ndo_open:
> > phy_connect()
> >
> > After reverting - https://lkml.org/lkml/2016/1/9/173 this works if we do
> phy_connect in probe as well.
>
> But as mentioned before you should not be doing the PHY probe in your
> driver's probe function for different reasons:
>
> - the probe function's responsibility is to initialize the driver and the HW to a
> state where they both have everything needed but it should be in quiesced
> state. There is no guarantee that your network device may ever be used
> after probe unless something calls ndo_open(), you should therefore keep
> all resources to a minimum: memory allocated, HW powered down etc.
>
> - there is a race condition between the PHY state machine started in
> phy_connect(), and when register_netdevice() is called and notifiers running
> which can lead to an inconsistent state for the carrier
>
Agreed. But I could see lot of drivers performing the phy_connect() in driver_probe() function itself.
Also observed that these drivers are performing netif_carrier_off() after register_netdevice().
My point is that we do we need to do netif_carrier_off() in phy_connect since we already doing the same after register_netdevice() ?
Thanks!
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
^ permalink raw reply
* Re: linux-next: manual merge of the pci tree with the net tree
From: Stephen Rothwell @ 2017-09-04 4:54 UTC (permalink / raw)
To: Bjorn Helgaas, David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Ding Tianhong,
Casey Leedom, Sinan Kaya
In-Reply-To: <20170816095128.7205e4f1@canb.auug.org.au>
Hi all,
On Wed, 16 Aug 2017 09:51:28 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the pci tree got a conflict in:
>
> drivers/pci/probe.c
>
> between commit:
>
> a99b646afa8a ("PCI: Disable PCIe Relaxed Ordering if unsupported")
>
> from the net tree and commit:
>
> 62ce94a7a5a5 ("PCI: Mark Broadcom HT2100 Root Port Extended Tags as broken")
>
> from the pci 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/pci/probe.c
> index e6a917b4acd3,d11fede6bd53..000000000000
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@@ -1751,67 -1753,51 +1753,94 @@@ int pci_configure_extended_tags(struct
> int ret;
>
> if (!pci_is_pcie(dev))
> - return;
> + return 0;
>
> - ret = pcie_capability_read_dword(dev, PCI_EXP_DEVCAP, &dev_cap);
> + ret = pcie_capability_read_dword(dev, PCI_EXP_DEVCAP, &cap);
> if (ret)
> - return;
> + return 0;
> +
> + if (!(cap & PCI_EXP_DEVCAP_EXT_TAG))
> + return 0;
> +
> + ret = pcie_capability_read_word(dev, PCI_EXP_DEVCTL, &ctl);
> + if (ret)
> + return 0;
> +
> + host = pci_find_host_bridge(dev->bus);
> + if (!host)
> + return 0;
> +
> + /*
> + * If some device in the hierarchy doesn't handle Extended Tags
> + * correctly, make sure they're disabled.
> + */
> + if (host->no_ext_tags) {
> + if (ctl & PCI_EXP_DEVCTL_EXT_TAG) {
> + dev_info(&dev->dev, "disabling Extended Tags\n");
> + pcie_capability_clear_word(dev, PCI_EXP_DEVCTL,
> + PCI_EXP_DEVCTL_EXT_TAG);
> + }
> + return 0;
> + }
>
> - if (dev_cap & PCI_EXP_DEVCAP_EXT_TAG)
> + if (!(ctl & PCI_EXP_DEVCTL_EXT_TAG)) {
> + dev_info(&dev->dev, "enabling Extended Tags\n");
> pcie_capability_set_word(dev, PCI_EXP_DEVCTL,
> PCI_EXP_DEVCTL_EXT_TAG);
> + }
> + return 0;
> }
>
> +/**
> + * pcie_relaxed_ordering_enabled - Probe for PCIe relaxed ordering enable
> + * @dev: PCI device to query
> + *
> + * Returns true if the device has enabled relaxed ordering attribute.
> + */
> +bool pcie_relaxed_ordering_enabled(struct pci_dev *dev)
> +{
> + u16 v;
> +
> + pcie_capability_read_word(dev, PCI_EXP_DEVCTL, &v);
> +
> + return !!(v & PCI_EXP_DEVCTL_RELAX_EN);
> +}
> +EXPORT_SYMBOL(pcie_relaxed_ordering_enabled);
> +
> +static void pci_configure_relaxed_ordering(struct pci_dev *dev)
> +{
> + struct pci_dev *root;
> +
> + /* PCI_EXP_DEVICE_RELAX_EN is RsvdP in VFs */
> + if (dev->is_virtfn)
> + return;
> +
> + if (!pcie_relaxed_ordering_enabled(dev))
> + return;
> +
> + /*
> + * For now, we only deal with Relaxed Ordering issues with Root
> + * Ports. Peer-to-Peer DMA is another can of worms.
> + */
> + root = pci_find_pcie_root_port(dev);
> + if (!root)
> + return;
> +
> + if (root->dev_flags & PCI_DEV_FLAGS_NO_RELAXED_ORDERING) {
> + pcie_capability_clear_word(dev, PCI_EXP_DEVCTL,
> + PCI_EXP_DEVCTL_RELAX_EN);
> + dev_info(&dev->dev, "Disable Relaxed Ordering because the Root Port didn't support it\n");
> + }
> +}
> +
> static void pci_configure_device(struct pci_dev *dev)
> {
> struct hotplug_params hpp;
> int ret;
>
> pci_configure_mps(dev);
> - pci_configure_extended_tags(dev);
> + pci_configure_extended_tags(dev, NULL);
> + pci_configure_relaxed_ordering(dev);
>
> memset(&hpp, 0, sizeof(hpp));
> ret = pci_get_hp_params(dev, &hpp);
Just a reminder that this conflict still exists.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: pull request: bluetooth-next 2017-09-03
From: David Miller @ 2017-09-04 4:28 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth, netdev
In-Reply-To: <20170903062055.GA9569@x1c.home>
From: Johan Hedberg <johan.hedberg@gmail.com>
Date: Sun, 3 Sep 2017 09:20:55 +0300
> Here's one last bluetooth-next pull request for the 4.14 kernel:
>
> - NULL pointer fix in ca8210 802.15.4 driver
> - A few "const" fixes
> - New Kconfig option for disabling legacy interfaces
>
> Please let me know if there are any issues pulling. Thanks.
Pulled.
^ permalink raw reply
* Re: [PATCH net-next 0/6] net: qualcomm: rmnet: Fix comments on initial patchset
From: David Miller @ 2017-09-04 4:27 UTC (permalink / raw)
To: subashab; +Cc: netdev
In-Reply-To: <1504416646-9527-1-git-send-email-subashab@codeaurora.org>
From: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Date: Sat, 2 Sep 2017 23:30:40 -0600
> This series fixes the comments from Dan on the first patch series.
>
> Fixes a memory corruption which could occur if mux_id was higher than 32.
> Remove the RMNET_LOCAL_LOGICAL_ENDPOINT which is no longer used.
> Make a log message more useful.
> Combine __rmnet_set_endpoint_config() with rmnet_set_endpoint_config().
> Set the mux_id in rmnet_vnd_newlink().
> Set the ingress and egress data format directly in newlink.
> Implement ndo_get_iflink to find the real_dev.
> Rename the real_dev_info to port to make it similar to other drivers.
>
> The conversion of rmnet_devices to a list and hash lookup will be sent
> as part of a seperate patch.
Series applied.
^ permalink raw reply
* Re: [PATCH net-next 0/6] nfp: refactor app init, and minor flower fixes
From: David Miller @ 2017-09-04 4:22 UTC (permalink / raw)
To: jakub.kicinski; +Cc: netdev, oss-drivers
In-Reply-To: <20170903012605.7435-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Sat, 2 Sep 2017 18:25:59 -0700
> This series is a part 2 to what went into net as a simpler fix.
> In net we simply moved when existing callbacks are invoked to
> ensure flower app does not still use representors when lower
> netdev has already been destroyed. In this series we add a
> callback to notify apps when vNIC netdevs are fully initialized
> and they are about to be destroyed. This allows flower to spawn
> representors at the right time, while keeping the start/stop
> callbacks for what they are intended to be used - FW initialization
> over control channel.
>
> Patch 4 improves drop monitor interaction and patch 5 changes
> the default Kconfig selection of flower offload. Patch 6 fixes
> locking around representor updates which got lost in net-next.
Series applied, thanks.
^ permalink raw reply
* Re: [pull request][net-next 00/17] Mellanox, mlx5 updates 2017-09-03
From: David Miller @ 2017-09-04 4:19 UTC (permalink / raw)
To: saeedm; +Cc: netdev, kernel-team
In-Reply-To: <20170903042117.28923-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Sun, 3 Sep 2017 07:21:00 +0300
> This series from Tariq includes micro data path optimization for mlx5e
> netdevice driver.
>
> Sorry about the late submission but most of the patches are really
> small and trivial.
>
> For more details please see tag log message below.
> Please pull and let me know if there's any problem.
Pulled, thanks.
^ permalink raw reply
* [PATCH net-next 2/2] tun: rename generic_xdp to skb_xdp
From: Jason Wang @ 2017-09-04 3:36 UTC (permalink / raw)
To: netdev, linux-kernel; +Cc: mst, Jason Wang, Daniel Borkmann
In-Reply-To: <1504496169-31190-1-git-send-email-jasowang@redhat.com>
Rename "generic_xdp" to "skb_xdp" to avoid confusing it with the
generic XDP which will be done at netif_receive_skb().
Cc: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/tun.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 80ac18f..3c9985f 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1267,7 +1267,7 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
struct tun_file *tfile,
struct iov_iter *from,
struct virtio_net_hdr *hdr,
- int len, int *generic_xdp)
+ int len, int *skb_xdp)
{
struct page_frag *alloc_frag = ¤t->task_frag;
struct sk_buff *skb;
@@ -1301,13 +1301,13 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
* we do XDP on skb in case the headroom is not enough.
*/
if (hdr->gso_type || !xdp_prog)
- *generic_xdp = 1;
+ *skb_xdp = 1;
else
- *generic_xdp = 0;
+ *skb_xdp = 0;
rcu_read_lock();
xdp_prog = rcu_dereference(tun->xdp_prog);
- if (xdp_prog && !*generic_xdp) {
+ if (xdp_prog && !*skb_xdp) {
struct xdp_buff xdp;
void *orig_data;
u32 act;
@@ -1389,7 +1389,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
bool zerocopy = false;
int err;
u32 rxhash;
- int generic_xdp = 1;
+ int skb_xdp = 1;
if (!(tun->dev->flags & IFF_UP))
return -EIO;
@@ -1448,7 +1448,11 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
}
if (tun_can_build_skb(tun, tfile, len, noblock, zerocopy)) {
- skb = tun_build_skb(tun, tfile, from, &gso, len, &generic_xdp);
+ /* For the packet that is not easy to be processed
+ * (e.g gso or jumbo packet), we will do it at after
+ * skb was created with generic XDP routine.
+ */
+ skb = tun_build_skb(tun, tfile, from, &gso, len, &skb_xdp);
if (IS_ERR(skb)) {
this_cpu_inc(tun->pcpu_stats->rx_dropped);
return PTR_ERR(skb);
@@ -1528,7 +1532,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
skb_reset_network_header(skb);
skb_probe_transport_header(skb, 0);
- if (generic_xdp) {
+ if (skb_xdp) {
struct bpf_prog *xdp_prog;
int ret;
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 1/2] tun: reserve extra headroom only when XDP is set
From: Jason Wang @ 2017-09-04 3:36 UTC (permalink / raw)
To: netdev, linux-kernel; +Cc: mst, Jason Wang, Jakub Kicinski
We reserve headroom unconditionally which could cause unnecessary
stress on socket memory accounting because of increased trusesize. Fix
this by only reserve extra headroom when XDP is set.
Cc: Jakub Kicinski <kubakici@wp.pl>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/tun.c | 26 ++++++++++++++++++--------
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 06e8f0b..80ac18f 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -108,7 +108,7 @@ do { \
#endif
#define TUN_HEADROOM 256
-#define TUN_RX_PAD (NET_IP_ALIGN + NET_SKB_PAD + TUN_HEADROOM)
+#define TUN_RX_PAD (NET_IP_ALIGN + NET_SKB_PAD)
/* TUN device flags */
@@ -1272,25 +1272,35 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
struct page_frag *alloc_frag = ¤t->task_frag;
struct sk_buff *skb;
struct bpf_prog *xdp_prog;
- int buflen = SKB_DATA_ALIGN(len + TUN_RX_PAD) +
- SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+ int buflen = SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
unsigned int delta = 0;
char *buf;
size_t copied;
bool xdp_xmit = false;
- int err;
+ int err, pad = TUN_RX_PAD;
+
+ rcu_read_lock();
+ xdp_prog = rcu_dereference(tun->xdp_prog);
+ if (xdp_prog)
+ pad += TUN_HEADROOM;
+ buflen += SKB_DATA_ALIGN(len + pad);
+ rcu_read_unlock();
if (unlikely(!skb_page_frag_refill(buflen, alloc_frag, GFP_KERNEL)))
return ERR_PTR(-ENOMEM);
buf = (char *)page_address(alloc_frag->page) + alloc_frag->offset;
copied = copy_page_from_iter(alloc_frag->page,
- alloc_frag->offset + TUN_RX_PAD,
+ alloc_frag->offset + pad,
len, from);
if (copied != len)
return ERR_PTR(-EFAULT);
- if (hdr->gso_type)
+ /* There's a small window that XDP may be set after the check
+ * of xdp_prog above, this should be rare and for simplicity
+ * we do XDP on skb in case the headroom is not enough.
+ */
+ if (hdr->gso_type || !xdp_prog)
*generic_xdp = 1;
else
*generic_xdp = 0;
@@ -1303,7 +1313,7 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
u32 act;
xdp.data_hard_start = buf;
- xdp.data = buf + TUN_RX_PAD;
+ xdp.data = buf + pad;
xdp.data_end = xdp.data + len;
orig_data = xdp.data;
act = bpf_prog_run_xdp(xdp_prog, &xdp);
@@ -1339,7 +1349,7 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
return ERR_PTR(-ENOMEM);
}
- skb_reserve(skb, TUN_RX_PAD - delta);
+ skb_reserve(skb, pad - delta);
skb_put(skb, len + delta);
get_page(alloc_frag->page);
alloc_frag->offset += buflen;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next v2 0/4] net: dsa: Allow switch drivers to indicate number of TX queues
From: Florian Fainelli @ 2017-09-04 3:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev, andrew, vivien.didelot, jiri, jhs, xiyou.wangcong
In-Reply-To: <20170903.202009.2104340600797726296.davem@davemloft.net>
Le 09/03/17 à 20:20, David Miller a écrit :
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Sat, 2 Sep 2017 11:06:05 -0700
>
>> This patch series extracts the parts of the patch set that are likely not to be
>> controversial and actually bringing multi-queue support to DSA-created network
>> devices.
>>
>> With these patches, we can now use sch_multiq as documented under
>> Documentation/networking/multique.txt and let applications dedice the switch
>> port output queue they want to use. Currently only Broadcom tags utilize that
>> information.
>>
>> Changes in v2:
>> - use a proper define for the number of TX queues in bcm_sf2.c (Andrew)
>
> Hello Florian.
>
> For some reason this series didn't make it completely into patchwork, I only
> see patch #1 there.
>
> Can you try submitting again? If it doesn't work this time I'll just apply
> it by hand from my inbox.
No problem, I just resent this patch series, thanks for the heads-up.
--
Florian
^ permalink raw reply
* [PATCH net-next v2 RESEND 4/4] net: dsa: bcm_sf2: Configure IMP port TC2QOS mapping
From: Florian Fainelli @ 2017-09-04 3:27 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, vivien.didelot, Florian Fainelli
In-Reply-To: <20170904032703.4593-1-f.fainelli@gmail.com>
Even though TC2QOS mapping is for switch egress queues, we need to
configure it correclty in order for the Broadcom tag ingress (CPU ->
switch) queue selection to work correctly since there is a 1:1 mapping
between switch egress queues and ingress queues.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/bcm_sf2.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 6b184bafa235..d7b53d53c116 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -103,6 +103,7 @@ static void bcm_sf2_brcm_hdr_setup(struct bcm_sf2_priv *priv, int port)
static void bcm_sf2_imp_setup(struct dsa_switch *ds, int port)
{
struct bcm_sf2_priv *priv = bcm_sf2_to_priv(ds);
+ unsigned int i;
u32 reg, offset;
if (priv->type == BCM7445_DEVICE_ID)
@@ -129,6 +130,14 @@ static void bcm_sf2_imp_setup(struct dsa_switch *ds, int port)
reg |= MII_DUMB_FWDG_EN;
core_writel(priv, reg, CORE_SWITCH_CTRL);
+ /* Configure Traffic Class to QoS mapping, allow each priority to map
+ * to a different queue number
+ */
+ reg = core_readl(priv, CORE_PORT_TC2_QOS_MAP_PORT(port));
+ for (i = 0; i < SF2_NUM_EGRESS_QUEUES; i++)
+ reg |= i << (PRT_TO_QID_SHIFT * i);
+ core_writel(priv, reg, CORE_PORT_TC2_QOS_MAP_PORT(port));
+
bcm_sf2_brcm_hdr_setup(priv, port);
/* Force link status for IMP port */
--
2.11.0
^ permalink raw reply related
* [PATCH net-next v2 RESEND 3/4] net: dsa: bcm_sf2: Advertise number of egress queues
From: Florian Fainelli @ 2017-09-04 3:27 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, vivien.didelot, Florian Fainelli
In-Reply-To: <20170904032703.4593-1-f.fainelli@gmail.com>
The switch supports 8 egress queues per port, so indicate that such that
net/dsa/slave.c::dsa_slave_create can allocate the right number of TX queues.
While at it use SF2_NUM_EGRESS_QUEUE as a define for the number of queues we
support.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/bcm_sf2.c | 5 ++++-
drivers/net/dsa/bcm_sf2_regs.h | 3 +++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 554fe2df9365..6b184bafa235 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -244,7 +244,7 @@ static int bcm_sf2_port_setup(struct dsa_switch *ds, int port,
* to a different queue number
*/
reg = core_readl(priv, CORE_PORT_TC2_QOS_MAP_PORT(port));
- for (i = 0; i < 8; i++)
+ for (i = 0; i < SF2_NUM_EGRESS_QUEUES; i++)
reg |= i << (PRT_TO_QID_SHIFT * i);
core_writel(priv, reg, CORE_PORT_TC2_QOS_MAP_PORT(port));
@@ -1151,6 +1151,9 @@ static int bcm_sf2_sw_probe(struct platform_device *pdev)
ds = dev->ds;
ds->ops = &bcm_sf2_ops;
+ /* Advertise the 8 egress queues */
+ ds->num_tx_queues = SF2_NUM_EGRESS_QUEUES;
+
dev_set_drvdata(&pdev->dev, priv);
spin_lock_init(&priv->indir_lock);
diff --git a/drivers/net/dsa/bcm_sf2_regs.h b/drivers/net/dsa/bcm_sf2_regs.h
index 26052450091e..49695fcc2ea8 100644
--- a/drivers/net/dsa/bcm_sf2_regs.h
+++ b/drivers/net/dsa/bcm_sf2_regs.h
@@ -401,4 +401,7 @@ enum bcm_sf2_reg_offs {
#define CFP_NUM_RULES 256
+/* Number of egress queues per port */
+#define SF2_NUM_EGRESS_QUEUES 8
+
#endif /* __BCM_SF2_REGS_H */
--
2.11.0
^ permalink raw reply related
* [PATCH net-next v2 RESEND 2/4] net: dsa: tag_brcm: Set output queue from skb queue mapping
From: Florian Fainelli @ 2017-09-04 3:27 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, vivien.didelot, Florian Fainelli
In-Reply-To: <20170904032703.4593-1-f.fainelli@gmail.com>
We originally used skb->priority but that was not quite correct as this
bitfield needs to contain the egress switch queue we intend to send this
SKB to.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
net/dsa/tag_brcm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/dsa/tag_brcm.c b/net/dsa/tag_brcm.c
index de74c3f77818..dbb016434ace 100644
--- a/net/dsa/tag_brcm.c
+++ b/net/dsa/tag_brcm.c
@@ -62,6 +62,7 @@
static struct sk_buff *brcm_tag_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct dsa_slave_priv *p = netdev_priv(dev);
+ u16 queue = skb_get_queue_mapping(skb);
u8 *brcm_tag;
if (skb_cow_head(skb, BRCM_TAG_LEN) < 0)
@@ -78,7 +79,7 @@ static struct sk_buff *brcm_tag_xmit(struct sk_buff *skb, struct net_device *dev
* deprecated
*/
brcm_tag[0] = (1 << BRCM_OPCODE_SHIFT) |
- ((skb->priority << BRCM_IG_TC_SHIFT) & BRCM_IG_TC_MASK);
+ ((queue & BRCM_IG_TC_MASK) << BRCM_IG_TC_SHIFT);
brcm_tag[1] = 0;
brcm_tag[2] = 0;
if (p->dp->index == 8)
--
2.11.0
^ permalink raw reply related
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