Re: pull-request: wireless-drivers-next 2016-09-29

[David Miller]

From: Kalle Valo 
Date: Wed, 05 Oct 2016 07:50:39 +0300

> net-next still fails to compile for me. I verified that these two
> patches fix it but I don't see them in net-next yet.

Pablo please get those fixes to me as soon as possible.

Re: pull-request: wireless-drivers-next 2016-09-29

[Kalle Valo]

Aaron Conole  writes:

> David Miller  writes:
>
>> From: Kalle Valo 
>> Date: Thu, 29 Sep 2016 19:57:28 +0300
>>
> ...
>>> Or actually I had one problem. While doing a test merge I noticed that
>>> net-next fails to compile for me, but I don't think this is anything
>>> wireless related:
>>> 
>>>   CC  net/netfilter/core.o
>>> net/netfilter/core.c: In function 'nf_set_hooks_head':
>>> net/netfilter/core.c:96:149: error: 'struct net_device' has no
>>> member named 'nf_hooks_ingress'
>>
>> Yes, I am aware of this build issue and will tackle it myself if someone
>> doesn't beat me to it.
>
> Sorry, I introduced this.  I posted a series targetted at nf-next to
> solve this, but it could be merged to net-next instead, if that makes
> sense.
>
> The patches are here:
>
> https://patchwork.ozlabs.org/patch/676287/
> https://patchwork.ozlabs.org/patch/676288/

net-next still fails to compile for me. I verified that these two
patches fix it but I don't see them in net-next yet.

-- 
Kalle Valo

Re: [PATCH v2 3/4] ARM: dts: dra72-evm-revc: fix correct phy delay and impedance settings

[Mugunthan V N]

On Tuesday 04 October 2016 06:41 PM, Lokesh Vutla wrote:
> 
> On Tuesday 04 October 2016 06:26 PM, Mugunthan V N wrote:
>> > The default impedance settings of the phy is not the optimal
>> > value, due to this the second ethernet is not working. Fix it
>> > with correct values which makes the second ethernet port to work.
>> > 
>> > Signed-off-by: Mugunthan V N 
>> > ---
>> >  arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
>> >  1 file changed, 2 insertions(+)
>> > 
>> > diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts 
>> > b/arch/arm/boot/dts/dra72-evm-revc.dts
>> > index f9cfd3b..d626cd7 100644
>> > --- a/arch/arm/boot/dts/dra72-evm-revc.dts
>> > +++ b/arch/arm/boot/dts/dra72-evm-revc.dts
>> > @@ -62,6 +62,7 @@
>> >ti,rx-internal-delay = ;
>> >ti,tx-internal-delay = ;
>> >ti,fifo-depth = ;
>> > +  ti,min-output-imepdance;
> s/imepdance/impedance
> 

Thanks for quick catch. Will fix this in v3.

Regards
Mugunthan V N

Re: [PATCH v2 2/4] net: phy: dp83867: add support for MAC impedance configuration

[Mugunthan V N]

On Tuesday 04 October 2016 06:40 PM, Andrew Lunn wrote:
>> +if (of_property_read_bool(of_node, "ti,max-output-imepdance"))
>> +dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
>> +else if (of_property_read_bool(of_node, "ti,min-output-imepdance"))
> 
> Did you really test this? Or did you make the same typos in your device
> tree file?
> 

I have tested this and attached the log in cover letter. Since there is
a typo error on both dts and driver it worked as expected. Will send a
v3 ASAP.

Regards
Mugunthan V N

Re: [PATCH net-next 0/7] qed*: Add qedr infrastructure support,Re: [PATCH net-next 0/7] qed*: Add qedr infrastructure support

[Doug Ledford]

On 10/4/2016 7:59 PM, David Miller wrote:
> From: Doug Ledford 
> Date: Tue, 4 Oct 2016 08:04:20 -0400
> 
>> Are you going to merge this in 4.9 or is this going into net-next?
> 
> 4.9, it will go into the pull request I send to Linus later today.
> 

Got it, thanks.

-- 
Doug Ledford 
GPG Key ID: 0E572FDD



signature.asc
Description: OpenPGP digital signature

Re: A bug in team driver

[Eric Dumazet]

On Tue, 2016-10-04 at 18:30 -0400, Alex Sidorenko wrote:
> The problem was found on RHEL7.2 but is still present in the latest
> upstream kernel (according to visual sources inspection).
> 
> While using roundrobin runner we have noticed that after sending on
> team0 about 2.1 billion packets we started seeing 50% packet drop on
> team0 
> (according to 'netstat -i'). This number suggested 'signed int'
> overflow and indeed, inspecting the sources I have noticed the
> following in 
> 
> drivers/net/team/team_mode_roundrobin.c
> ---
> struct rr_priv {
>   unsigned int sent_packets;<- unsigned
> int
> };
> 
> static struct rr_priv *rr_priv(struct team *team)
> {
>   return (struct rr_priv *) >mode_priv;
> }
> 
> static bool rr_transmit(struct team *team, struct sk_buff *skb)
> {
>   struct team_port *port;
>   int port_index;
> 
>   port_index = team_num_to_port_index(team,
>   rr_priv(team)->sent_packets++);
> ---
> 
> 
> we have 'unsigned int sent_packets' but we call team_num_to_port_index
> where 'num' is 'int'
> 
> include/linux/if_team.h
> ---
> static inline int team_num_to_port_index(struct team *team, int num)
> <-- signed int
> {
>   int en_port_count = ACCESS_ONCE(team->en_port_count);
> 
>   if (unlikely(!en_port_count))
>   return 0;
>   return num % en_port_count;
> }
> 
> 
> As soon as sent_packets becomes larger than MAXINT (=2**31-1),
> team_num_to_port_index() can return negative number as num becomes
> negative and remainder 
> (num % en_port_count) is either 0 or negative. This leads to looking
> up incorrect hash-bucket and dropping packets.
> 
> We have easily duplicated this in roundrobin mode with two ports.
> After reaching 2**31 packets sent on team0 every second packet was
> dropped.
> 
> Rebuilding the kernel after changing 
> 
> team_num_to_port_index(struct team *team, int num) ->
> team_num_to_port_index(struct team *team, unsigned int num)
> 
> and running the test again does not show packet drop anymore.
> 
> The same subroutine is used in
> team_mode_loadbalance.c:lb_hash_select_tx_port but we pass 'unsigned
> char hash' to team_num_to_port_index(), so there should be no
> overflow. I did not test that mode in my tests.

Good catch ! Can you send an official patch to fix this ?

Thanks.

> 

Re: [1/3] bpf powerpc: introduce accessors for using the tmp local stack space

[Michael Ellerman]

On Fri, 2016-23-09 at 20:35:00 UTC, "Naveen N. Rao" wrote:
> While at it, ensure that the location of the local save area is
> consistent whether or not we setup our own stackframe. This property is
> utilised in the next patch that adds support for tail calls.
> 
> Signed-off-by: Naveen N. Rao 

Series applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/7b847f523fe07b4ad73a01cec49a4d

cheers

Re: [PATCH net-next] openvswitch: correctly fragment packet with mpls headers

[Pravin Shelar]

On Tue, Oct 4, 2016 at 9:59 AM, Jiri Benc  wrote:
> On Tue, 4 Oct 2016 09:53:25 -0700, Pravin Shelar wrote:
>> This code can be executed on encapsulated geneve or vxlan packets.
>
> How? The encapsulation header is in the form of metadata_dst at this
> point and not present in the packet itself. Am I missing something?
>

We could have encapsulated packet defragmented in physical bridge.
that mean the packet is entering OVS after egressing tunnel device.
That use case would break due to this patch.

> If this patch is wrong, then the current push_mpls is wrong, too, it
> does the same assumption.
>
I am not sure what you mean, can you explain?

Re: [PATCH] netdevice: add netdev_pub helper function

[Jason A. Donenfeld]

Hey David,

The use of this function is going from the private member to the
public netdev struct. The usage is desired from the following coding
pattern.

You're implementing a netdevice. You've got ndo_init, ndo_uninit,
ndo_open, ndo_stop, ndo_start_xmit, and maybe even ndo_do_ioctl. All
of these functions basically follow the flow: get some information out
of struct netdev, then call netdev_priv(), and pass that specific
pointer onto the rest of the driver. The rest of the driver, 99% of
the time, only deals with your private member. Very very occasionally
it might want to check into how some piece of public data is doing.
For example, is the interface up? In this case, it's very convenient
to have the netdev_pub function, as in this patch.

if (netdev_pub(priv)->flags & IFF_UP) {
...
}

Then, after shortly using the public members, the driver gets on its
way dealing again exclusively with the private part.

I posted this patch a year ago, and let it languish after your initial
comment, because I wasn't confident that this was necessarily
something everybody could benefit from. 18 months later, after reading
quite a few netdevice-based drivers, it seems like this is indeed a
very useful code pattern, that makes things a bit more clear, a bit
less verbose, and helps maintain type safety throughout a driver.

So, I resubmit this to you for inclusion.

Regards,
Jason


On Fri, Jun 12, 2015 at 3:30 PM, Jason A. Donenfeld  wrote:
> Being able to utilize this makes much code a lot simpler and cleaner.
> It's a nice convenience function.
>
> Signed-off-by: Jason A. Donenfeld 
> ---
>  include/linux/netdevice.h | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 05b9a69..f85be18 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1871,6 +1871,17 @@ static inline void *netdev_priv(const struct 
> net_device *dev)
> return (char *)dev + ALIGN(sizeof(struct net_device), NETDEV_ALIGN);
>  }
>
> +/**
> + * netdev_pub - access network device from private pointer
> + * @priv: private data pointer of network device
> + *
> + * Get network device from a network device private data pointer
> + */
> +static inline struct net_device *netdev_pub(void *priv)
> +{
> +   return (struct net_device *)((char *)priv - ALIGN(sizeof(struct 
> net_device), NETDEV_ALIGN));
> +}
> +
>  /* Set the sysfs physical device reference for the network logical device
>   * if set prior to registration will cause a symlink during initialization.
>   */
> --
> 2.4.2
>

Re: kernel v4.8: iptables logs are truncated with the 4.8 kernel?

[Liping Zhang]

Hi Justin,

2016-10-05 6:02 GMT+08:00 Justin Piszcz :
> Hello,
>
> kernel 4.8 with ulogd-2.0.5- IPs are no longer logged:
>
> Oct  4 17:51:30 atom INPUT_BLOCK IN=eth1 OUT=
> MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 LEN=0 TOS=00 PREC=0x00
> TTL=0 ID=0 PROTO=0 MARK=0
> Oct  4 17:51:31 atom INPUT_BLOCK IN=eth1 OUT=
> MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 LEN=0 TOS=00 PREC=0x00
> TTL=0 ID=0 PROTO=0 MARK=0
> Oct  4 17:51:32 atom INPUT_BLOCK IN=eth1 OUT=
> MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 LEN=0 TOS=00 PREC=0x00
> TTL=0 ID=0 PROTO=0 MARK=0
>
> (reboot back to kernel 4.7, works fine)
>
> kernel 4.7 with ulogd-2.0.5:
> Oct  4 17:56:44 atom INPUT_BLOCK IN=eth1 OUT=
> MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 SRC=74.125.22.125
> DST=1.2.3.4 LEN=397 TOS=00 PREC=0x00 TTL=48 ID=58093 PROTO=TCP
> SPT=5222 DPT=19804 SEQ=2032644254 ACK=2273184383 WINDOW=55272 ACK PSH
> URGP=0 MARK=0
> Oct  4 17:56:45 atom INPUT_BLOCK IN=eth1 OUT=
> MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 SRC=74.125.22.125
> DST=1.2.3.4 LEN=397 TOS=00 PREC=0x00 TTL=48 ID=58725 PROTO=TCP
> SPT=5222 DPT=19804 SEQ=2032644254 ACK=2273184383 WINDOW=55272 ACK PSH
> URGP=0 MARK=0
>
> Looks like there were some changes in the 4.8 kernel regarding ulogd,
> has anyone else run into this problem?
>
> } ulog;
> +   if ((li->u.ulog.flags & NF_LOG_F_COPY_LEN) &&
> +   (li->u.ulog.copy_len < data_len))
> +   data_len = li->u.ulog.copy_len;
> li->u.ulog.group = ntohs(nla_get_be16(tb[NFTA_LOG_GROUP]));
> +   li->u.ulog.flags |= NF_LOG_F_COPY_LEN;
> li->u.ulog.copy_len =
> if (nla_put_be16(skb, NFTA_LOG_GROUP, 
> htons(li->u.ulog.group)))
> -   if (li->u.ulog.copy_len) {
> +   if (li->u.ulog.flags & NF_LOG_F_COPY_LEN) {
>  htonl(li->u.ulog.copy_len)))
> li.u.ulog.group  = info->group;
> li.u.ulog.qthreshold = info->threshold;
> +   li.u.ulog.flags |= NF_LOG_F_COPY_LEN;
>
> Thanks,
>
> Justin.

Which one are you using? iptables or nftables?

Could you please paste the related iptables/nftables rules here?

Re: Assertion faileda at samples/bpf/test_maps

[William Tu]

Hi Louie,

Can you check whether your num_possible_cpu == num_online_cpu?
by doing:
cat /sys/devices/system/cpu/possible
and see how many cpu[0-9]
ls /sys/devices/system/cpu/cpu*

There is a related discussion here:
https://www.mail-archive.com/netdev@vger.kernel.org/msg121258.html

Regards,
William

On Sun, Oct 2, 2016 at 3:55 PM, Louie Lu  wrote:
> Hi everyone,
>
> I'm now playing net-next samples/bpf things, and I found that
> test_maps will give an assertion
>
> ```
> test_maps: /home/grd/linux/net-next/samples/bpf/test_maps.c:146:
> test_percpu_hashmap_sanity: Assertion `bpf_lookup_elem(map_fd, ,
> value) == -1 && errno == ENOENT' failed.
> [1]20706 abort (core dumped)  ./test_maps
> ```
>
> I've done the check at [[iovisor-dev] Assertion fails at
> samples/bpf/test_maps](http://lists.iovisor.org/pipermail/iovisor-dev/2016-June/000281.html)
> which tells me to set ulimit to unlimited or patching by setrlimit().
>
> The problem is bpf_lookup_elem return -1, and errno return 0.
>
> I'm using Intel(R) Core(TM) i7-2640M and net-next commit:
> 803783849fed11, 4.8.0-rc7-ARCH-02283-g8037838.
>
> And, a strange this is when I done this at QEMU, test_maps perform
> will and pass the test.
>
> Is that my hardware problem or something else?
>
>
> Thanks.
>
> Louie Lu.

Re: [patch net 0/2] mlxsw: Couple of fixes

[David Miller]

From: Jiri Pirko 
Date: Tue,  4 Oct 2016 09:46:03 +0200

> Couple of fixes from Yotam.

Series applied, thanks.

Note that needed_headroom is a request, rather than a guarantee, so you
may in some rare cases need to realloc your headroom if the kernel was
not able to meet your request.

Re: pull-request: mac80211-next 2016-10-04

[David Miller]

From: Johannes Berg 
Date: Tue,  4 Oct 2016 09:31:28 +0200

> Here's a version with the conflicts resolved - had to jigger some
> code around, but it's all described in the merge commit message.
> 
> Let me know if there's any problem.

Pulled, thanks for resolving this.

Re: [PATCH net-next 0/7] rxrpc: More fixes and adjustments

[David Miller]

From: David Howells 
Date: Tue, 04 Oct 2016 17:01:30 +0100

> What's the procedure for sending more fixes at this point?  Do I send them
> against net-next, since net doesn't contain the things to be fixed yet, or do
> I wait for net to catch up?

I'm sending Linus a pull request later today for the stuff in net-next,
and once he takes that all the trees will be synced up and you can start
sending fixes.

Thanks.

Re: [PATCH net-next 1/2] openvswitch: remove nonreachable code in vlan parsing

[Eric Garver]

Hi Jiri,

On Tue, Oct 04, 2016 at 02:30:01PM +0200, Jiri Benc wrote:
> It can never happen that there's a vlan tag in the packet but not in
> skb->vlan_tci. This is ensured in __netif_receive_skb_core and honored by
> skb_vlan_push and skb_vlan_pop. The code dealing with such case is a dead
> code.
>

This code is also called for packets passed back down from userspace
(after the flow key miss and upcall). So it does happen that we have a
skb without skb->vlan_tci set.

See the chain:
ovs_packet_cmd_execute()
  ovs_flow_key_extract_userspace()
key_extract()
  parse_vlan()

> Moreover, the likely() statement around skb_vlan_tag_present is bogus. This
> code is called whenever flow key is being extracted from the packet. The
> packet may be as likely vlan tagged as not.
> 

I guess the unlikely scenario is the one I mention above.

Re: [PATCH net-next 0/7] qed*: Add qedr infrastructure support,Re: [PATCH net-next 0/7] qed*: Add qedr infrastructure support

[David Miller]

From: Doug Ledford 
Date: Tue, 4 Oct 2016 08:04:20 -0400

> Are you going to merge this in 4.9 or is this going into net-next?

4.9, it will go into the pull request I send to Linus later today.

A bug in team driver

[Alex Sidorenko]

The problem was found on RHEL7.2 but is still present in the latest upstream 
kernel (according to visual sources inspection).

While using roundrobin runner we have noticed that after sending on team0 about 
2.1 billion packets we started seeing 50% packet drop on team0 
(according to 'netstat -i'). This number suggested 'signed int' overflow and 
indeed, inspecting the sources I have noticed the following in 

drivers/net/team/team_mode_roundrobin.c
---
struct rr_priv {
unsigned int sent_packets;<- unsigned 
int
};

static struct rr_priv *rr_priv(struct team *team)
{
return (struct rr_priv *) >mode_priv;
}

static bool rr_transmit(struct team *team, struct sk_buff *skb)
{
struct team_port *port;
int port_index;

port_index = team_num_to_port_index(team,
rr_priv(team)->sent_packets++);
---


we have 'unsigned int sent_packets' but we call team_num_to_port_index where 
'num' is 'int'

include/linux/if_team.h
---
static inline int team_num_to_port_index(struct team *team, int num)<-- 
signed int
{
int en_port_count = ACCESS_ONCE(team->en_port_count);

if (unlikely(!en_port_count))
return 0;
return num % en_port_count;
}


As soon as sent_packets becomes larger than MAXINT (=2**31-1), 
team_num_to_port_index() can return negative number as num becomes negative and 
remainder 
(num % en_port_count) is either 0 or negative. This leads to looking up 
incorrect hash-bucket and dropping packets.

We have easily duplicated this in roundrobin mode with two ports. After 
reaching 2**31 packets sent on team0 every second packet was dropped.

Rebuilding the kernel after changing 

team_num_to_port_index(struct team *team, int num) -> 
team_num_to_port_index(struct team *team, unsigned int num)

and running the test again does not show packet drop anymore.

The same subroutine is used in team_mode_loadbalance.c:lb_hash_select_tx_port 
but we pass 'unsigned char hash' to team_num_to_port_index(), so there should 
be no overflow. I did not test that mode in my tests.

Regards,
Alex



-- 

--
Alex Sidorenko  email: a...@hpe.com
ERT  Linux  Hewlett-Packard Enterprise (Canada)
--

kernel v4.8: iptables logs are truncated with the 4.8 kernel?

[Justin Piszcz]

Hello,

kernel 4.8 with ulogd-2.0.5- IPs are no longer logged:

Oct  4 17:51:30 atom INPUT_BLOCK IN=eth1 OUT=
MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 LEN=0 TOS=00 PREC=0x00
TTL=0 ID=0 PROTO=0 MARK=0
Oct  4 17:51:31 atom INPUT_BLOCK IN=eth1 OUT=
MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 LEN=0 TOS=00 PREC=0x00
TTL=0 ID=0 PROTO=0 MARK=0
Oct  4 17:51:32 atom INPUT_BLOCK IN=eth1 OUT=
MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 LEN=0 TOS=00 PREC=0x00
TTL=0 ID=0 PROTO=0 MARK=0

(reboot back to kernel 4.7, works fine)

kernel 4.7 with ulogd-2.0.5:
Oct  4 17:56:44 atom INPUT_BLOCK IN=eth1 OUT=
MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 SRC=74.125.22.125
DST=1.2.3.4 LEN=397 TOS=00 PREC=0x00 TTL=48 ID=58093 PROTO=TCP
SPT=5222 DPT=19804 SEQ=2032644254 ACK=2273184383 WINDOW=55272 ACK PSH
URGP=0 MARK=0
Oct  4 17:56:45 atom INPUT_BLOCK IN=eth1 OUT=
MAC=00:1b:21:9c:3b:fa:3e:94:d5:d2:49:1e:08:00 SRC=74.125.22.125
DST=1.2.3.4 LEN=397 TOS=00 PREC=0x00 TTL=48 ID=58725 PROTO=TCP
SPT=5222 DPT=19804 SEQ=2032644254 ACK=2273184383 WINDOW=55272 ACK PSH
URGP=0 MARK=0

Looks like there were some changes in the 4.8 kernel regarding ulogd,
has anyone else run into this problem?

} ulog;
+   if ((li->u.ulog.flags & NF_LOG_F_COPY_LEN) &&
+   (li->u.ulog.copy_len < data_len))
+   data_len = li->u.ulog.copy_len;
li->u.ulog.group = ntohs(nla_get_be16(tb[NFTA_LOG_GROUP]));
+   li->u.ulog.flags |= NF_LOG_F_COPY_LEN;
li->u.ulog.copy_len =
if (nla_put_be16(skb, NFTA_LOG_GROUP, htons(li->u.ulog.group)))
-   if (li->u.ulog.copy_len) {
+   if (li->u.ulog.flags & NF_LOG_F_COPY_LEN) {
 htonl(li->u.ulog.copy_len)))
li.u.ulog.group  = info->group;
li.u.ulog.qthreshold = info->threshold;
+   li.u.ulog.flags |= NF_LOG_F_COPY_LEN;

Thanks,

Justin.

[PATCH v3] mwifiex: report wakeup for wowlan

[Rajat Jain]

Register the WLAN device as a wakeup source since it can
wake the system via wake-on-wireless-lan. In an actual wowlan
event, notify the PM core that we are the current wakeup source.
This allows the PM core to update the wakeup attributes in /sys.

This was causing wakeup issues on chromeos as the system was
apparently confused about the wakeup source.

Signed-off-by: Wei-Ning Huang 
Signed-off-by: Rajat Jain 
Tested-by: Wei-Ning Huang 
Reviewed-by: Eric Caruso 
Acked-by: Amitkumar Karwar 
---
v3: Fix the commit log
v2: Fix the commit log

 drivers/net/wireless/marvell/mwifiex/sdio.c | 8 
 drivers/net/wireless/marvell/mwifiex/sdio.h | 1 +
 2 files changed, 9 insertions(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c 
b/drivers/net/wireless/marvell/mwifiex/sdio.c
index d3e1561..a5f63e4 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -89,6 +89,9 @@ static irqreturn_t mwifiex_wake_irq_wifi(int irq, void *priv)
disable_irq_nosync(irq);
}
 
+   /* Notify PM core we are wakeup source */
+   pm_wakeup_event(cfg->dev, 0);
+
return IRQ_HANDLED;
 }
 
@@ -112,6 +115,7 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct 
sdio_mmc_card *card)
  GFP_KERNEL);
cfg = card->plt_wake_cfg;
if (cfg && card->plt_of_node) {
+   cfg->dev = dev;
cfg->irq_wifi = irq_of_parse_and_map(card->plt_of_node, 0);
if (!cfg->irq_wifi) {
dev_dbg(dev,
@@ -130,6 +134,10 @@ static int mwifiex_sdio_probe_of(struct device *dev, 
struct sdio_mmc_card *card)
}
}
 
+   ret = device_init_wakeup(dev, true);
+   if (ret)
+   dev_err(dev, "fail to init wakeup for mwifiex");
+
return 0;
 }
 
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.h 
b/drivers/net/wireless/marvell/mwifiex/sdio.h
index db837f1..07cdd23 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.h
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.h
@@ -155,6 +155,7 @@
 } while (0)
 
 struct mwifiex_plt_wake_cfg {
+   struct device *dev;
int irq_wifi;
bool wake_by_wifi;
 };
-- 
2.8.0.rc3.226.g39d4020

Re: [ISSUE: mv88e6xxx]: Down/Up link and not forwarding

[Andrew Lunn]

> >The main difference is GLOBAL2 5th register. When the unit is just
> >initialized, the driver sets this register to 00ff, however, when
> >the issue happens, its value is c12f.

You might want to hack the MDIO driver and get it to trap writes to
this register and give you a call stack.

 Andrew

RE: [PATCH] igb: Realign bad indentation

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Joe Perches
> Sent: Monday, September 26, 2016 8:46 PM
> To: Kirsher, Jeffrey T 
> Cc: intel-wired-...@lists.osuosl.org; netdev@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH] igb: Realign bad indentation
> 
> Statements should start on tabstops.
> 
> Use a single statement and test instead of multiple tests.
> 
> Signed-off-by: Joe Perches 
> ---
>  drivers/net/ethernet/intel/igb/e1000_mac.c | 15 ++-
>  1 file changed, 6 insertions(+), 9 deletions(-)

Tested-by: Aaron Brown 

Re: [ISSUE: mv88e6xxx]: Down/Up link and not forwarding

[Florian Fainelli]

On October 4, 2016 8:37:13 AM PDT, Jose Antonio Delgado Alfonso 
 wrote:
>We are working in an ARMv7 embedded system running kernel 4.1 but
>including patches to upgrade dsa/mv88e6xxx to kernel version 4.3
>(5acf4d0, Wed, 27 May 2015 15:32:15 -0700) "[PATCH] blk: rq_data_dir()
>should not return a boolean."
>
>This is the schema of the system.
>
> +---+ eth0
> |   +--+
> |   |  |
> | Embedded system   +--+
> |   |
> |  ARMv7|
> |   | Marvell 88E8057(sky2) +-+
>|   +--+ +--+ +--+ eth1
>|   |  +-+  | | 
>+--+
> |   +--+  CPU port   +--+  mv88e6176  +--+
> +--+--+-+   | |
>emulated|  | | |
>GPIO+--+  +--+ +--+
>eth2
>MDIO  +---+  | | 
>+--+
>  MDIO+--+ +--+
> +-+
>
>There is a bridge (br-lan) which includes eth0/eth1/eth2

Can you detail what eth0 and eth1 actually correspond to? The bridge layer 
denies adding DSA master network interfaces as bridge members as soon as they 
have tags enabled.

>
>>From time to time, We are seeing a link down and up of about 1s.
>Following the message that kernel sends.
>
>[  312.769399] dsa dsa@0 eth2: Link is Down
>[  312.773372] br-lan: port 3(eth2) entered disabled state
>[  312.947274] dsa dsa@0 eth2: link up, 100 Mb/s, full duplex, flow
>control disabled
>[  312.963807] br-lan: port 3(eth2) entered forwarding state
>[  312.969276] br-lan: port 3(eth2) entered forwarding state
>[  313.777815] dsa dsa@0 eth2: Link is Up - 100Mbps/Full - flow control
>rx/tx
>[  314.966277] br-lan: port 3(eth2) entered forwarding state
>
>Moreover, under a reboot loop test which consists in booting the
>system,
>ping the unit and, if it responds, reboot again, we found that the
>bridge does not forward packages after many reboots.
>Looking into 88e6176 registers we saw the following
>
>GLOBAL GLOBAL2   0123456 
> 0:  c820   0  de0f 5d0f 500f 500f 500f 4e07 4007
> 1: 3   03e333333
> 2: 0 0000000
> 3: 0  1761 1761 1761 1761 1761 1761 1761
> 4:  6000 258  373f  433  430  433  433  433  433
> 5:  1000c12f 0000000
> 6:  c0001f0f  101e 3005 3003 4001 5001 6001 7001
> 7: 0707f 0000000
> 8: 07800  2480 2480 2480 2480 2480 2480 2480
> 9: 01600 1111111
> a:   148   0 0000000
> b:  60001000 1248   10   20   40
> c: 0  22 0000000
> d:   507 0000000
> e:    36 0000000
> f:   f00  dada dada dada dada dada dada dada
>10: 0   0 0000000
>11: 0   0 0000000
>12:     0 0000000
>13:     0   34d 8b18  54d0000
>14:   400 0000000
>15:     0 0000000
>16:     033   33   33   33   33   330
>17:     0 0000000
>18:  fa411884  3210 3210 3210 3210 3210 3210 3210
>19: 0 5e1  7654 7654 7654 7654 7654 7654 7654
>1a: 0   0 0000000
>1b:   1fcf869  8000 8000 8000 8000 8000 8000 8000
>1c: 04c00 0000000
>1d:  5ce0   0 0000000
>1e: 0   0 0000000
>1f: 0   0 0000000
>
>The main difference is GLOBAL2 5th register. When the unit is just
>initialized, the driver sets this register to 00ff, however, when the
>issue happens, its value is c12f.
>We got a patch which allows us to set registers values. If we change
>c12f to 00ff the ping works, otherwise, ping does not work. We do not
>know who is changing the register value. Apparently, driver does not.
>
>Weirderif possible, sometimes even global2 5th register is set to 00ff
>and bridge does not forward packages either. We have not sorted out
>which other register is affecting.
>
>Finally, The weirdest behaviour we are seeing is that the unit does not
>detect a link change, register 0 of ports 1 and 2 do not update their
>status.
>
>Have you experienced a similar issue in your side?
>
>Is it possible that those micro-outage could be the reason of bad
>settings in Global2 5th register?
>
>Have 

ethtool 4.8 released

[John W. Linville]

ethtool version 4.8 has been released.

Home page: https://www.kernel.org/pub/software/network/ethtool/
Download link:
https://www.kernel.org/pub/software/network/ethtool/ethtool-4.8.tar.xz

Release notes:

* Feature: QSFP Plus/QSFP28 Diagnostics Information Support
* Feature: Enhancing link mode bits to support 25G/50G/100G
* Feature: add support for 1000BaseX and missing 10G link mode
* Fixes: address Coverity issues 1363118 - 1363125

John
-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.

Re: [PATCH net-next] openvswitch: correctly fragment packet with mpls headers

[Jiri Benc]

On Tue, 4 Oct 2016 09:53:25 -0700, Pravin Shelar wrote:
> This code can be executed on encapsulated geneve or vxlan packets.

How? The encapsulation header is in the form of metadata_dst at this
point and not present in the packet itself. Am I missing something?

If this patch is wrong, then the current push_mpls is wrong, too, it
does the same assumption.

 Jiri

Re: [PATCH net-next] openvswitch: correctly fragment packet with mpls headers

[Pravin Shelar]

On Tue, Oct 4, 2016 at 2:28 AM, Jiri Benc  wrote:
> On Tue, 4 Oct 2016 10:24:58 +0200, Jiri Benc wrote:
>> On Mon, 3 Oct 2016 11:04:46 -0700, Pravin Shelar wrote:
>> > This is not correct way to detect MPLS packet. inner_protocol can be
>> > set by any tunnel device for using tunnel offloads. So this would
>> > break the fragmentation for encapsulated packets.
>>
>> You're right, stupid me.
>
> Actually, too little caffeine in the morning. I actually did consider
> this and I believe my patch is correct. It doesn't matter what the
> encapsulation is, we want to fragment the *inner* packet. And this is
> exactly what this patch does.
>
> Besides, the only case is MPLS anyway. I'm not aware of any code path
> that could lead us to here, set inner protocol and not be MPLS. But
> even if it is, it should work, provided the encapsulation header is
> identical for all fragments and smaller than MAX_L2_LEN.
>

This code can be executed on encapsulated geneve or vxlan packets. So
in that case encapsulation header would not be same for all fragments.

[PATCH][RESEND] dt-bindings: net: renesas-ravb: Add support for R8A7796 RAVB

[Laurent Pinchart]

Add a new compatible string for the R8A7796 (M3-W) RAVB.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Geert Uytterhoeven 
---
 Documentation/devicetree/bindings/net/renesas,ravb.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

The patch has been posted to the linux-renesas-soc mailing list only, adding
the netdev mailing list to get it upstreamed.

diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt 
b/Documentation/devicetree/bindings/net/renesas,ravb.txt
index c8ac222eac67..b519503be51a 100644
--- a/Documentation/devicetree/bindings/net/renesas,ravb.txt
+++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt
@@ -10,6 +10,7 @@ Required properties:
  "renesas,etheravb-r8a7793" if the device is a part of R8A7793 SoC.
  "renesas,etheravb-r8a7794" if the device is a part of R8A7794 SoC.
  "renesas,etheravb-r8a7795" if the device is a part of R8A7795 SoC.
+ "renesas,etheravb-r8a7796" if the device is a part of R8A7796 SoC.
  "renesas,etheravb-rcar-gen2" for generic R-Car Gen 2 compatible 
interface.
  "renesas,etheravb-rcar-gen3" for generic R-Car Gen 3 compatible 
interface.
 
@@ -33,7 +34,7 @@ Optional properties:
 - interrupt-parent: the phandle for the interrupt controller that services
interrupts for this device.
 - interrupt-names: A list of interrupt names.
-  For the R8A7795 SoC this property is mandatory;
+  For the R8A779[56] SoCs this property is mandatory;
   it should include one entry per channel, named "ch%u",
   where %u is the channel number ranging from 0 to 24.
   For other SoCs this property is optional; if present
-- 
Regards,

Laurent Pinchart

Re: [PATCH net-next 0/7] rxrpc: More fixes and adjustments

[David Howells]

Hi Dave,

What's the procedure for sending more fixes at this point?  Do I send them
against net-next, since net doesn't contain the things to be fixed yet, or do
I wait for net to catch up?

David

[ISSUE: mv88e6xxx]: Down/Up link and not forwarding

[Jose Antonio Delgado Alfonso]

We are working in an ARMv7 embedded system running kernel 4.1 but
including patches to upgrade dsa/mv88e6xxx to kernel version 4.3
(5acf4d0, Wed, 27 May 2015 15:32:15 -0700) "[PATCH] blk: rq_data_dir()
should not return a boolean."

This is the schema of the system.

 +---+ eth0
 |   +--+
 |   |  |
 | Embedded system   +--+
 |   |
 |  ARMv7|
 |   | Marvell 88E8057(sky2) +-+
 |   +--+ +--+ +--+ eth1
 |   |  +-+  | |  +--+
 |   +--+  CPU port   +--+  mv88e6176  +--+
 +--+--+-+   | |
emulated|  | | |
GPIO+--+  +--+ +--+ eth2
MDIO  +---+  | |  +--+
  MDIO+--+ +--+
 +-+

There is a bridge (br-lan) which includes eth0/eth1/eth2

>From time to time, We are seeing a link down and up of about 1s.
Following the message that kernel sends.

[  312.769399] dsa dsa@0 eth2: Link is Down
[  312.773372] br-lan: port 3(eth2) entered disabled state
[  312.947274] dsa dsa@0 eth2: link up, 100 Mb/s, full duplex, flow
control disabled
[  312.963807] br-lan: port 3(eth2) entered forwarding state
[  312.969276] br-lan: port 3(eth2) entered forwarding state
[  313.777815] dsa dsa@0 eth2: Link is Up - 100Mbps/Full - flow control
rx/tx
[  314.966277] br-lan: port 3(eth2) entered forwarding state

Moreover, under a reboot loop test which consists in booting the system,
ping the unit and, if it responds, reboot again, we found that the
bridge does not forward packages after many reboots.
Looking into 88e6176 registers we saw the following

GLOBAL GLOBAL2   0123456 
 0:  c820   0  de0f 5d0f 500f 500f 500f 4e07 4007
 1: 3   03e333333
 2: 0 0000000
 3: 0  1761 1761 1761 1761 1761 1761 1761
 4:  6000 258  373f  433  430  433  433  433  433
 5:  1000c12f 0000000
 6:  c0001f0f  101e 3005 3003 4001 5001 6001 7001
 7: 0707f 0000000
 8: 07800  2480 2480 2480 2480 2480 2480 2480
 9: 01600 1111111
 a:   148   0 0000000
 b:  60001000 1248   10   20   40
 c: 0  22 0000000
 d:   507 0000000
 e:    36 0000000
 f:   f00  dada dada dada dada dada dada dada
10: 0   0 0000000
11: 0   0 0000000
12:     0 0000000
13:     0   34d 8b18  54d0000
14:   400 0000000
15:     0 0000000
16:     033   33   33   33   33   330
17:     0 0000000
18:  fa411884  3210 3210 3210 3210 3210 3210 3210
19: 0 5e1  7654 7654 7654 7654 7654 7654 7654
1a: 0   0 0000000
1b:   1fcf869  8000 8000 8000 8000 8000 8000 8000
1c: 04c00 0000000
1d:  5ce0   0 0000000
1e: 0   0 0000000
1f: 0   0 0000000

The main difference is GLOBAL2 5th register. When the unit is just
initialized, the driver sets this register to 00ff, however, when the
issue happens, its value is c12f.
We got a patch which allows us to set registers values. If we change
c12f to 00ff the ping works, otherwise, ping does not work. We do not
know who is changing the register value. Apparently, driver does not.

Weirderif possible, sometimes even global2 5th register is set to 00ff
and bridge does not forward packages either. We have not sorted out
which other register is affecting.

Finally, The weirdest behaviour we are seeing is that the unit does not
detect a link change, register 0 of ports 1 and 2 do not update their
status.

Have you experienced a similar issue in your side?

Is it possible that those micro-outage could be the reason of bad
settings in Global2 5th register?

Have you fixed this issues in a newer Linux kernel version?

Thanks in advance.

[ISSUE: mv88e6xxx]: Down/Up link and not forwarding

[Jose Antonio Delgado Alfonso]

We are working in an ARMv7 embedded system running kernel 4.1 but
including patches to upgrade dsa/mv88e6xxx to kernel version 4.3
(5acf4d0, Wed, 27 May 2015 15:32:15 -0700) "[PATCH] blk: rq_data_dir()
should not return a boolean."

This is the schema of the system.

+-+ eth0
| +--+
| |  |
|   Embedded system   +--+
| |
|   ARMv7 |
| | Marvell 88E8057(sky2)  
+--+
| +--+  
+--+  +--+ eth1@marvell
| |  +---+ 
|  |  +---+
| +--+ CPU port  +--+   
mv88e6176 +--+
+--+--+---+
|  |
emulated   |  |
|  |
GPIO-MDIO  +--+ 
+--+  +--+ eth2@marvell
 +---+ 
|  |  +---+
  MDIO  
+--+  +--+
   
+--+

There is a bridge (br-lan) which includes eth0/eth1/eth2

>From time to time, We are seeing a link down and up of about 1s.
Following the message that kernel sends.

[  312.769399] dsa dsa@0 eth2: Link is Down
[  312.773372] br-lan: port 3(eth2) entered disabled state
[  312.947274] dsa dsa@0 eth2: link up, 100 Mb/s, full duplex, flow
control disabled
[  312.963807] br-lan: port 3(eth2) entered forwarding state
[  312.969276] br-lan: port 3(eth2) entered forwarding state
[  313.777815] dsa dsa@0 eth2: Link is Up - 100Mbps/Full - flow control
rx/tx
[  314.966277] br-lan: port 3(eth2) entered forwarding state

Moreover, under a reboot loop test which consists in booting the system,
ping the unit and, if it responds, reboot again, we found that the
bridge does not forward packages after many reboots.
Looking into 88e6176 registers we saw the following

GLOBAL GLOBAL2   0123456 
 0:  c820   0  de0f 5d0f 500f 500f 500f 4e07 4007
 1: 3   03e333333
 2: 0 0000000
 3: 0  1761 1761 1761 1761 1761 1761 1761
 4:  6000 258  373f  433  430  433  433  433  433
 5:  1000c12f 0000000
 6:  c0001f0f  101e 3005 3003 4001 5001 6001 7001
 7: 0707f 0000000
 8: 07800  2480 2480 2480 2480 2480 2480 2480
 9: 01600 1111111
 a:   148   0 0000000
 b:  60001000 1248   10   20   40
 c: 0  22 0000000
 d:   507 0000000
 e:    36 0000000
 f:   f00  dada dada dada dada dada dada dada
10: 0   0 0000000
11: 0   0 0000000
12:     0 0000000
13:     0   34d 8b18  54d0000
14:   400 0000000
15:     0 0000000
16:     033   33   33   33   33   330
17:     0 0000000
18:  fa411884  3210 3210 3210 3210 3210 3210 3210
19: 0 5e1  7654 7654 7654 7654 7654 7654 7654
1a: 0   0 0000000
1b:   1fcf869  8000 8000 8000 8000 8000 8000 8000
1c: 04c00 0000000
1d:  5ce0   0 0000000
1e: 0   0 0000000
1f: 0   0 0000000

The main difference is GLOBAL2 5th register. When the unit is just
initialized, the driver sets this register to 00ff, however, when the
issue happens, its value is c12f.
We got a patch which allows us to set registers values. If we change
c12f to 00ff the ping works, otherwise, ping does not work. We do not
know who is changing the register value. Apparently, driver does not.

Weirderif possible, sometimes even global2 5th register is set to 00ff
and bridge does not forward packages either. We have not sorted out
which other register is affecting.

Finally, The weirdest behaviour we are seeing is that the unit does not
detect a link change, register 0 of ports 1 and 2 do not update their
status.

Have you experienced a similar issue in your side?

Is it possible that those micro-outage could be the reason of bad
settings in Global2 5th register?

Have you fixed this issues in a newer Linux kernel version?

Thanks in advance.

Re: [PATCH 6/6] mISDN: remove unused function

[Arnd Bergmann]

On Saturday, September 24, 2016 1:28:02 PM CEST Baoyou Xie wrote:
> diff --git a/drivers/isdn/mISDN/layer2.c b/drivers/isdn/mISDN/layer2.c
> index f6ab6027..2519510 100644
> --- a/drivers/isdn/mISDN/layer2.c
> +++ b/drivers/isdn/mISDN/layer2.c
> @@ -459,15 +459,6 @@ IsDISC(u_char *data)
> return (data[0] & 0xef) == DISC;
>  }
>  
> -inline int
> -IsRR(u_char *data, struct layer2 *l2)
> -{
> -   if (test_bit(FLG_MOD128, >flag))
> -   return data[0] == RR;
> -   else
> -   return (data[0] & 0xf) == 1;
> -}
> -
>  static inline int
>  IsSFrame(u_char *data, struct layer2 *l2)
>  {
> -- 
> 

This is not wrong, but it might be nicer to just
make this one as 'static inline' as well like the other
ones for consistency.

Note that static inline functions don't cause a warning
when they are unused.

Arnd

Re: [Xen-devel] [PATCH v2 net-next 5/7] xen-netback: process guest rx packets in batches

[David Vrabel]

On 04/10/16 13:47, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 04, 2016 at 10:29:16AM +0100, Paul Durrant wrote:
>> From: David Vrabel 
>>
>> Instead of only placing one skb on the guest rx ring at a time, process
>> a batch of up-to 64.  This improves performance by ~10% in some tests.
> 
> And does it regress latency workloads?

No. Because the loop outside of these batches is only checking for a
fatal error condition or a disconnection.

> What are those 'some tests' you speak off?

I think it was aggregate intrahost, but I don't remember exactly.

David

RE: [net-next 08/13] fsl/fman: check pcsphy pointer before use

[David Laight]

From: Madalin Bucur
> Sent: 04 October 2016 08:33
> Subject: [net-next 08/13] fsl/fman: check pcsphy pointer before use
..
> --- a/drivers/net/ethernet/freescale/fman/fman_memac.c
> +++ b/drivers/net/ethernet/freescale/fman/fman_memac.c
> @@ -507,6 +507,9 @@ static void setup_sgmii_internal_phy(struct fman_mac 
> *memac,
>  {
>   u16 tmp_reg16;
> 
> + if (WARN_ON(!memac->pcsphy))
> + return;
> +

Why?

Either it can validly be NULL in which case you don't want the message.
Or it shouldn't be NULL in which case you need to find and fix the bug.
The later kernel OOPS will make the bug much easier to find.

David

Re: [PATCH v7 net-next] net: phy: Add Edge-rate driver for Microsemi PHYs.

[Andrew Lunn]

> v7:
> - As per review comment, Removed '-'s (minus) sign in Edge rate table. 

Still no exact match on the table. 

So if i specify a voltage of 3301, 53% slowdown it looks i will
actually get 0% slowdown and no error message. That is not very
helpful.

Andrew

Re: [PATCH net-next 2/2] net: phy: Add PHY Auto/Mdi/Mdix set driver for Microsemi PHYs.

[Raju Lakkaraju]

Hi Andrew,

Thank you for code review and valuable comments.

On Wed, Sep 28, 2016 at 10:24:51PM +0200, Andrew Lunn wrote:
> EXTERNAL EMAIL
> 
> 
> > + reg_val = phy_read(phydev, MSCC_PHY_BYPASS_CONTROL);
> > + if ((mdix == ETH_TP_MDI) || (mdix == ETH_TP_MDI_X)) {
> > + reg_val |= (DISABLE_PAIR_SWAP_CORR_MASK |
> > + DISABLE_POLARITY_CORR_MASK  |
> > + DISABLE_HP_AUTO_MDIX_MASK);
> > + } else {
> > + reg_val &= ~(DISABLE_PAIR_SWAP_CORR_MASK |
> > +  DISABLE_POLARITY_CORR_MASK  |
> > +  DISABLE_HP_AUTO_MDIX_MASK);
> > + }
> > + rc = phy_write(phydev, MSCC_PHY_BYPASS_CONTROL, reg_val);
> > + if (rc != 0)
> > + goto out_unlock;
> > +
> > + rc = vsc85xx_phy_page_set(phydev, MSCC_PHY_PAGE_EXTENDED);
> > + if (rc != 0)
> > + goto out_unlock;
> > +
> > + reg_val = phy_read(phydev, MSCC_PHY_EXT_MODE_CNTL);
> > + reg_val &= ~(FORCE_MDI_CROSSOVER_MASK);
> > + if (mdix == ETH_TP_MDI)
> > + reg_val |= FORCE_MDI_CROSSOVER_MDI;
> > + else if (mdix == ETH_TP_MDI_X)
> > + reg_val |= FORCE_MDI_CROSSOVER_MDIX;
> > + rc = phy_write(phydev, MSCC_PHY_EXT_MODE_CNTL, reg_val);
> > + if (rc != 0)
> > + goto out_unlock;
> > +
> > + rc = vsc85xx_phy_page_set(phydev, MSCC_PHY_PAGE_STANDARD);
> > +
> > +out_unlock:
> 
> out_unlock seems a bit of an odd name, since you are not unlocking
> anything.
> 

It's my mistake. Mutex should be there. I will add mutex.

> I also wonder if you should try to reset to MSCC_PHY_PAGE_STANDARD in
> the error condition?
> 

> > +
> > + return rc;
> > +}
> > +
> >  static int vsc85xx_wol_set(struct phy_device *phydev,
> >  struct ethtool_wolinfo *wol)
> >  {
> > @@ -227,6 +281,7 @@ static int vsc85xx_default_config(struct phy_device 
> > *phydev)
> >   int rc;
> >   u16 reg_val;
> >
> > + phydev->mdix = ETH_TP_MDI_AUTO;
> 
> Humm, interesting. The only other driver supporting mdix is the
> Marvell one. It does not do this, it leaves it to its default value of
> ETH_TP_MDI_INVALID. It does however interpret ETH_TP_MDI_INVALID as
> meaning as ETH_TP_MDI_AUTO.
> 
> There needs to be consistency here. You either need to do the same as
> the Marvell driver, or you need to modify the Marvell driver to also
> set phydev->mdix to ETH_TP_MDI_AUTO.
> 
In Ethtool two variable i.e. eth_tp_mdix_ctrl, eth_tp_mdix use to update
the status. But, driver header is having one variable i.e. mdix.
Driver header should also have another variabl like mdix_ctrl.
Then, Ethtool can get/set the Auto MDIX/MDI.
In case, mdix is not configure with ETH_TP_MDI_AUTO, Ethtool shows error as
"setting MDI not supported"

Please suggest me if you have any better method to fix this issue.

> I don't yet know which of these two is the right thing to do.
> 
> Florian?
> 
> Andrew

---
Thanks,
Raju.

Re: [Xen-devel] [PATCH v2 net-next 2/7] xen-netback: retire guest rx side prefix GSO feature

[Konrad Rzeszutek Wilk]

On Tue, Oct 04, 2016 at 01:35:41PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > Sent: 04 October 2016 13:52
> > To: Paul Durrant ; annie...@oracle.com;
> > joao.m.mart...@oracle.com
> > Cc: netdev@vger.kernel.org; xen-de...@lists.xenproject.org; Wei Liu
> > 
> > Subject: Re: [Xen-devel] [PATCH v2 net-next 2/7] xen-netback: retire guest
> > rx side prefix GSO feature
> > 
> > On Tue, Oct 04, 2016 at 10:29:13AM +0100, Paul Durrant wrote:
> > > As far as I am aware only very old Windows network frontends make use
> > > of this style of passing GSO packets from backend to frontend. These
> > > frontends can easily be replaced by the freely available Xen Project
> > > Windows PV network frontend, which uses the 'default' mechanism for
> > > passing GSO packets, which is also used by all Linux frontends.
> > 
> > It is not that simple. Some companies have extra juice in their Windows
> > frontends so can't easily swap over to the Xen Project one.
> 
> Ok, then those frontends will continue to work, but they won't get GSO 
> packets any more. Prefix GSO has never been specified in the canonical netif 
> header and so has been in a limbo state forever so such frontends have always 
> been on borrowed time and only just happened to work against a linux backend. 
> If someone wants to actually specify prefix GSO properly then it could be 
> added back in, but it should not be necessary now that the RX side req<->rsp 
> identity relation is documented 
> (http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/io/netif.h;hb=HEAD#l729).
> 
> > 
> > Either way CC-ing Annie
> > 
> > Also would it make sense to CC the FreeBSD and NetBSD maintainers of their
> > PV drivers just to make sure? (Or has that been confirmed)
> > 
> 
> I could do that, but I'd hope that they would be subscribed to xen-devel and 
> will chime in if there's likely to be a problem.

Usually one CCs those folks. I think you are asking me to do
the legwork and find them and CC them here?

CC-ing Roger and  Manuel Bouyer.

> 
> > >
> > > NOTE: Removal of this feature will not cause breakage in old Windows
> > >   frontends. They simply will no longer receive GSO packets - the
> > >   packets instead being fragmented in the backend.
> > 
> > Did you also test this with SuSE/Novell Windows PV drivers?
> > 
> 
> No, I don't have copies of these. Internal XenServer testing has not shown up 
> any issues with 'legacy' PV drivers though (which do still have the prefix 
> GSO code in).

You can download these drivers and install on your guests.
> 
>   Paul
> 
> > Thanks.
> > >
> > > Signed-off-by: Paul Durrant 
> > > ---
> > > Cc: Wei Liu 
> > > ---
> > >  drivers/net/xen-netback/common.h|  1 -
> > >  drivers/net/xen-netback/interface.c |  4 ++--
> > >  drivers/net/xen-netback/rx.c| 26 --
> > >  drivers/net/xen-netback/xenbus.c| 21 -
> > >  4 files changed, 2 insertions(+), 50 deletions(-)
> > >
> > > diff --git a/drivers/net/xen-netback/common.h
> > > b/drivers/net/xen-netback/common.h
> > > index b38fb2c..0ba5910 100644
> > > --- a/drivers/net/xen-netback/common.h
> > > +++ b/drivers/net/xen-netback/common.h
> > > @@ -260,7 +260,6 @@ struct xenvif {
> > >
> > >   /* Frontend feature information. */
> > >   int gso_mask;
> > > - int gso_prefix_mask;
> > >
> > >   u8 can_sg:1;
> > >   u8 ip_csum:1;
> > > diff --git a/drivers/net/xen-netback/interface.c
> > > b/drivers/net/xen-netback/interface.c
> > > index fb50c6d..211d542 100644
> > > --- a/drivers/net/xen-netback/interface.c
> > > +++ b/drivers/net/xen-netback/interface.c
> > > @@ -319,9 +319,9 @@ static netdev_features_t
> > > xenvif_fix_features(struct net_device *dev,
> > >
> > >   if (!vif->can_sg)
> > >   features &= ~NETIF_F_SG;
> > > - if (~(vif->gso_mask | vif->gso_prefix_mask) & GSO_BIT(TCPV4))
> > > + if (~(vif->gso_mask) & GSO_BIT(TCPV4))
> > >   features &= ~NETIF_F_TSO;
> > > - if (~(vif->gso_mask | vif->gso_prefix_mask) & GSO_BIT(TCPV6))
> > > + if (~(vif->gso_mask) & GSO_BIT(TCPV6))
> > >   features &= ~NETIF_F_TSO6;
> > >   if (!vif->ip_csum)
> > >   features &= ~NETIF_F_IP_CSUM;
> > > diff --git a/drivers/net/xen-netback/rx.c
> > > b/drivers/net/xen-netback/rx.c index 03836aa..6bd7d6e 100644
> > > --- a/drivers/net/xen-netback/rx.c
> > > +++ b/drivers/net/xen-netback/rx.c
> > > @@ -347,16 +347,6 @@ static int xenvif_gop_skb(struct sk_buff *skb,
> > >   gso_type = XEN_NETIF_GSO_TYPE_TCPV6;
> > >   }
> > >
> > > - /* Set up a GSO prefix descriptor, if necessary */
> > > - if ((1 << gso_type) & vif->gso_prefix_mask) {
> > > - RING_COPY_REQUEST(>rx, queue->rx.req_cons++,
> > );
> > > - meta = npo->meta + npo->meta_prod++;
> > > - meta->gso_type = gso_type;
> > > -

Re: [PATCH net-next 1/2] net: phy: Add Wake-on-LAN driver for Microsemi PHYs.

[Raju Lakkaraju]

Hi Florian,

Thank you for code review and valuable comments.


On Wed, Sep 28, 2016 at 10:37:07AM -0700, Florian Fainelli wrote:
> EXTERNAL EMAIL
> 
> 
> On 09/28/2016 05:01 AM, Raju Lakkaraju wrote:
> > From: Raju Lakkaraju 
> >
> > Wake-on-LAN (WoL) is an Ethernet networking standard that allows
> > a computer/device to be turned on or awakened by a network message.
> > VSC8531 PHY can support this feature configure by driver set function.
> > WoL status get by driver get function.
> >
> > Tested on Beaglebone Black with VSC 8531 PHY.
> >
> > Signed-off-by: Raju Lakkaraju 
> > ---
> >  drivers/net/phy/mscc.c | 132 
> > +
> >  1 file changed, 132 insertions(+)
> >
> > diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
> > index d350deb..ca6ea23 100644
> > --- a/drivers/net/phy/mscc.c
> > +++ b/drivers/net/phy/mscc.c
> > @@ -11,6 +11,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  enum rgmii_rx_clock_delay {
> >   RGMII_RX_CLK_DELAY_0_2_NS = 0,
> > @@ -35,6 +36,7 @@ enum rgmii_rx_clock_delay {
> >
> >  #define MII_VSC85XX_INT_MASK   25
> >  #define MII_VSC85XX_INT_MASK_MASK  0xa000
> > +#define MII_VSC85XX_INT_MASK_WOL   0x0040
> >  #define MII_VSC85XX_INT_STATUS 26
> >
> >  #define MSCC_EXT_PAGE_ACCESS   31
> > @@ -46,6 +48,19 @@ enum rgmii_rx_clock_delay {
> >  #define RGMII_RX_CLK_DELAY_MASK0x0070
> >  #define RGMII_RX_CLK_DELAY_POS 4
> >
> > +#define MSCC_PHY_WOL_LOWER_MAC_ADDR21
> > +#define MSCC_PHY_WOL_MID_MAC_ADDR  22
> > +#define MSCC_PHY_WOL_UPPER_MAC_ADDR23
> > +#define MSCC_PHY_WOL_LOWER_PASSWD  24
> > +#define MSCC_PHY_WOL_MID_PASSWD25
> > +#define MSCC_PHY_WOL_UPPER_PASSWD  26
> > +
> > +#define MSCC_PHY_WOL_MAC_CONTROL   27
> > +#define EDGE_RATE_CNTL_POS 5
> > +#define EDGE_RATE_CNTL_MASK0x00E0
> > +#define SECURE_ON_ENABLE   0x8000
> > +#define SECURE_ON_PASSWD_LEN_4 0x4000
> > +
> >  /* Microsemi PHY ID's */
> >  #define PHY_ID_VSC8531 0x00070570
> >  #define PHY_ID_VSC8541 0x00070770
> > @@ -58,6 +73,119 @@ static int vsc85xx_phy_page_set(struct phy_device 
> > *phydev, u8 page)
> >   return rc;
> >  }
> >
> > +static int vsc85xx_wol_set(struct phy_device *phydev,
> > +struct ethtool_wolinfo *wol)
> > +{
> > + int rc;
> > + u16 reg_val;
> > + struct ethtool_wolinfo *wol_conf = wol;
> > +
> > + mutex_lock(>lock);
> 
> This mutex is used here because you are using an indirect page access,
> right? This is not to protect against multiple calls of wol_set from
> different executing threads?
> 

Correct. mutex is used for indirect page access.

I did find any protect against multiple calls of wol_set in other vendors.
Do you have any suggestions?

> > + rc = vsc85xx_phy_page_set(phydev, MSCC_PHY_PAGE_EXTENDED_2);
> > + if (rc != 0)
> > + goto out_unlock;
> > +
> > + if (wol->wolopts & WAKE_MAGIC) {
> > + /* Store the device address for the magic packet */
> > + reg_val = phydev->attached_dev->dev_addr[4] << 8;
> > + reg_val |= phydev->attached_dev->dev_addr[5];
> > + phy_write(phydev, MSCC_PHY_WOL_LOWER_MAC_ADDR, reg_val);
> > + reg_val = phydev->attached_dev->dev_addr[2] << 8;
> > + reg_val |= phydev->attached_dev->dev_addr[3];
> > + phy_write(phydev, MSCC_PHY_WOL_MID_MAC_ADDR, reg_val);
> > + reg_val = phydev->attached_dev->dev_addr[0] << 8;
> > + reg_val |= phydev->attached_dev->dev_addr[1];
> > + phy_write(phydev, MSCC_PHY_WOL_UPPER_MAC_ADDR, reg_val);
> > + } else {
> > + phy_write(phydev, MSCC_PHY_WOL_LOWER_MAC_ADDR, 0);
> > + phy_write(phydev, MSCC_PHY_WOL_MID_MAC_ADDR, 0);
> > + phy_write(phydev, MSCC_PHY_WOL_UPPER_MAC_ADDR, 0);
> > + }
> > +
> > + reg_val = phy_read(phydev, MSCC_PHY_WOL_MAC_CONTROL);
> > + if (wol_conf->wolopts & WAKE_MAGICSECURE)
> > + reg_val |= SECURE_ON_ENABLE;
> > + else
> > + reg_val &= ~SECURE_ON_ENABLE;
> > + phy_write(phydev, MSCC_PHY_WOL_MAC_CONTROL, reg_val);
> > +
> > + if (wol_conf->wolopts & WAKE_MAGICSECURE) {
> > + reg_val = wol_conf->sopass[4] << 8;
> > + reg_val |= wol_conf->sopass[5];
> > + phy_write(phydev, MSCC_PHY_WOL_LOWER_PASSWD, reg_val);
> > + reg_val = wol_conf->sopass[2] << 8;
> > + reg_val |= wol_conf->sopass[3];
> > + phy_write(phydev, MSCC_PHY_WOL_MID_PASSWD, reg_val);
> > + reg_val = wol_conf->sopass[0] << 8;
> > + reg_val |= wol_conf->sopass[1];
> > + phy_write(phydev, MSCC_PHY_WOL_UPPER_PASSWD, 

Re: [PATCH 2/7] ethtool: avoid resource leak of strings in do_gprivflags

[John W. Linville]

On Mon, Oct 03, 2016 at 01:54:26PM -0400, Jarod Wilson wrote:
> On Fri, Sep 30, 2016 at 03:56:16PM -0400, John W. Linville wrote:
> > Coverity issue: 1363119
> > Fixes: e1ee596326ae ("Add support for querying and setting private flags")
> > 
> > Signed-off-by: John W. Linville 
> > ---
> >  ethtool.c | 18 +-
> >  1 file changed, 13 insertions(+), 5 deletions(-)
> > 
> > diff --git a/ethtool.c b/ethtool.c
> > index aa3ef5ed2f75..0885a61097ad 100644
> > --- a/ethtool.c
> > +++ b/ethtool.c
> > @@ -4205,7 +4205,7 @@ static int do_gprivflags(struct cmd_context *ctx)
> > struct ethtool_gstrings *strings;
> > struct ethtool_value flags;
> > unsigned int i;
> > -   int max_len = 0, cur_len;
> > +   int max_len = 0, cur_len, rc;
> >  
> > if (ctx->argc != 0)
> > exit_bad_args();
> > @@ -4215,11 +4215,13 @@ static int do_gprivflags(struct cmd_context *ctx)
> > 1);
> > if (!strings) {
> > perror("Cannot get private flag names");
> > -   return 1;
> > +   rc = 1;
> > +   goto err;
> 
> This goto looks redundant, since all you're doing at err is re-checking if
> strings is non-null to free it.

True, the original return is just as good there. And since strings
is non-NULL for everything after that, the NULL check at error can
be eliminated as well...

Thanks!

John

> > if (strings->len == 0) {
> > fprintf(stderr, "No private flags defined\n");
> > -   return 1;
> > +   rc = 1;
> > +   goto err;
> > }
> > if (strings->len > 32) {
> > /* ETHTOOL_GPFLAGS can only cover 32 flags */
> > @@ -4230,7 +4232,8 @@ static int do_gprivflags(struct cmd_context *ctx)
> > flags.cmd = ETHTOOL_GPFLAGS;
> > if (send_ioctl(ctx, )) {
> > perror("Cannot get private flags");
> > -   return 1;
> > +   rc = 1;
> > +   goto err;
> > }
> >  
> > /* Find longest string and align all strings accordingly */
> > @@ -4248,7 +4251,12 @@ static int do_gprivflags(struct cmd_context *ctx)
> >(const char *)strings->data + i * ETH_GSTRING_LEN,
> >(flags.data & (1U << i)) ? "on" : "off");
> >  
> > -   return 0;
> > +   rc = 0;
> > +
> > +err:
> > +   if (strings)
> > +   free(strings);
> > +   return rc;
> >  }
> >  
> >  static int do_sprivflags(struct cmd_context *ctx)
> > -- 
> > 2.7.4
> > 
> 
> -- 
> Jarod Wilson
> ja...@redhat.com
> 
> 
> 

-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.

[PATCH v2 2/7] ethtool: avoid resource leak of strings in do_gprivflags

[John W. Linville]

Coverity issue: 1363119
Fixes: e1ee596326ae ("Add support for querying and setting private flags")

Signed-off-by: John W. Linville 
Reviewed-by: Greg Rose 
---
 ethtool.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/ethtool.c b/ethtool.c
index aa3ef5ed2f75..7ce5667fcdd7 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -4205,7 +4205,7 @@ static int do_gprivflags(struct cmd_context *ctx)
struct ethtool_gstrings *strings;
struct ethtool_value flags;
unsigned int i;
-   int max_len = 0, cur_len;
+   int max_len = 0, cur_len, rc;
 
if (ctx->argc != 0)
exit_bad_args();
@@ -4219,7 +4219,8 @@ static int do_gprivflags(struct cmd_context *ctx)
}
if (strings->len == 0) {
fprintf(stderr, "No private flags defined\n");
-   return 1;
+   rc = 1;
+   goto err;
}
if (strings->len > 32) {
/* ETHTOOL_GPFLAGS can only cover 32 flags */
@@ -4230,7 +4231,8 @@ static int do_gprivflags(struct cmd_context *ctx)
flags.cmd = ETHTOOL_GPFLAGS;
if (send_ioctl(ctx, )) {
perror("Cannot get private flags");
-   return 1;
+   rc = 1;
+   goto err;
}
 
/* Find longest string and align all strings accordingly */
@@ -4248,7 +4250,11 @@ static int do_gprivflags(struct cmd_context *ctx)
   (const char *)strings->data + i * ETH_GSTRING_LEN,
   (flags.data & (1U << i)) ? "on" : "off");
 
-   return 0;
+   rc = 0;
+
+err:
+   free(strings);
+   return rc;
 }
 
 static int do_sprivflags(struct cmd_context *ctx)
-- 
2.7.4

RE: [Xen-devel] [PATCH v2 net-next 4/7] xen-netback: immediately wake tx queue when guest rx queue has space

[Paul Durrant]

> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: 04 October 2016 13:49
> To: Paul Durrant 
> Cc: netdev@vger.kernel.org; xen-de...@lists.xenproject.org; Wei Liu
> ; David Vrabel 
> Subject: Re: [Xen-devel] [PATCH v2 net-next 4/7] xen-netback: immediately
> wake tx queue when guest rx queue has space
> 
> On Tue, Oct 04, 2016 at 02:29:15AM -0700, Paul Durrant wrote:
> > From: David Vrabel 
> >
> > When an skb is removed from the guest rx queue, immediately wake the
> > tx queue, instead of after processing them.
> 
> Please, could the description explain why?
> 

Is it not reasonably obvious that it improves parallelism between filling and 
draining the queue? I could add a comment if you think it needs spelling out.

  Paul

> >
> > Signed-off-by: David Vrabel  [re-based]
> > Signed-off-by: Paul Durrant 
> > ---
> > Cc: Wei Liu 
> > ---
> >  drivers/net/xen-netback/rx.c | 24 
> >  1 file changed, 8 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/net/xen-netback/rx.c
> > b/drivers/net/xen-netback/rx.c index b0ce4c6..9548709 100644
> > --- a/drivers/net/xen-netback/rx.c
> > +++ b/drivers/net/xen-netback/rx.c
> > @@ -92,27 +92,21 @@ static struct sk_buff *xenvif_rx_dequeue(struct
> xenvif_queue *queue)
> > spin_lock_irq(>rx_queue.lock);
> >
> > skb = __skb_dequeue(>rx_queue);
> > -   if (skb)
> > +   if (skb) {
> > queue->rx_queue_len -= skb->len;
> > +   if (queue->rx_queue_len < queue->rx_queue_max) {
> > +   struct netdev_queue *txq;
> > +
> > +   txq = netdev_get_tx_queue(queue->vif->dev,
> queue->id);
> > +   netif_tx_wake_queue(txq);
> > +   }
> > +   }
> >
> > spin_unlock_irq(>rx_queue.lock);
> >
> > return skb;
> >  }
> >
> > -static void xenvif_rx_queue_maybe_wake(struct xenvif_queue *queue) -
> {
> > -   spin_lock_irq(>rx_queue.lock);
> > -
> > -   if (queue->rx_queue_len < queue->rx_queue_max) {
> > -   struct net_device *dev = queue->vif->dev;
> > -
> > -   netif_tx_wake_queue(netdev_get_tx_queue(dev, queue-
> >id));
> > -   }
> > -
> > -   spin_unlock_irq(>rx_queue.lock);
> > -}
> > -
> >  static void xenvif_rx_queue_purge(struct xenvif_queue *queue)  {
> > struct sk_buff *skb;
> > @@ -585,8 +579,6 @@ int xenvif_kthread_guest_rx(void *data)
> >  */
> > xenvif_rx_queue_drop_expired(queue);
> >
> > -   xenvif_rx_queue_maybe_wake(queue);
> > -
> > cond_resched();
> > }
> >
> > --
> > 2.1.4
> >
> >
> > ___
> > Xen-devel mailing list
> > xen-de...@lists.xen.org
> > https://lists.xen.org/xen-devel

Re: [PATCH net-next 1/2] net: phy: Add Wake-on-LAN driver for Microsemi PHYs.

[Raju Lakkaraju]

Hi Andrew,

Thank you for code review and valuable comments.

On Wed, Sep 28, 2016 at 06:27:05PM +0200, Andrew Lunn wrote:
> EXTERNAL EMAIL
> 
> 
> > +#define MSCC_PHY_WOL_MAC_CONTROL   27
> > +#define EDGE_RATE_CNTL_POS 5
> > +#define EDGE_RATE_CNTL_MASK0x00E0
> 
> This patch does not require these two #defines.
> 
> Please indicate in the cover note if the patches depends on other
> patches in order to cleanly apply. Or if these patches are going to
> conflict with some other patches.
> 

Accepted. I will remove those 2 defines.

> > + reg_val = phy_read(phydev, MSCC_PHY_WOL_MAC_CONTROL);
> > + if (wol_conf->wolopts & WAKE_MAGICSECURE)
> > + reg_val |= SECURE_ON_ENABLE;
> > + else
> > + reg_val &= ~SECURE_ON_ENABLE;
> > + phy_write(phydev, MSCC_PHY_WOL_MAC_CONTROL, reg_val);
> > +
> > + if (wol_conf->wolopts & WAKE_MAGICSECURE) {
> > + reg_val = wol_conf->sopass[4] << 8;
> > + reg_val |= wol_conf->sopass[5];
> > + phy_write(phydev, MSCC_PHY_WOL_LOWER_PASSWD, reg_val);
> > + reg_val = wol_conf->sopass[2] << 8;
> > + reg_val |= wol_conf->sopass[3];
> > + phy_write(phydev, MSCC_PHY_WOL_MID_PASSWD, reg_val);
> > + reg_val = wol_conf->sopass[0] << 8;
> > + reg_val |= wol_conf->sopass[1];
> > + phy_write(phydev, MSCC_PHY_WOL_UPPER_PASSWD, reg_val);
> > + } else {
> > + phy_write(phydev, MSCC_PHY_WOL_LOWER_PASSWD, 0);
> > + phy_write(phydev, MSCC_PHY_WOL_MID_PASSWD, 0);
> > + phy_write(phydev, MSCC_PHY_WOL_UPPER_PASSWD, 0);
> > + }
> 
> Wouldn't it be better to set the password, and then enable the
> password feature?
> 

Accepted. I will change.

> I don't know much about WOL. Hopefully Florian will add further
> comments.
> 
>  Andrew

---
Thanks,
Raju.

RE: [Xen-devel] [PATCH v2 net-next 5/7] xen-netback: process guest rx packets in batches

[Paul Durrant]

> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: 04 October 2016 13:48
> To: Paul Durrant 
> Cc: netdev@vger.kernel.org; xen-de...@lists.xenproject.org; Wei Liu
> ; David Vrabel 
> Subject: Re: [Xen-devel] [PATCH v2 net-next 5/7] xen-netback: process
> guest rx packets in batches
> 
> On Tue, Oct 04, 2016 at 10:29:16AM +0100, Paul Durrant wrote:
> > From: David Vrabel 
> >
> > Instead of only placing one skb on the guest rx ring at a time,
> > process a batch of up-to 64.  This improves performance by ~10% in some
> tests.

I believe the tests are mainly throughput tests, but David would know the 
specifics.

> 
> And does it regress latency workloads?
> 

It shouldn't, although I have not run ping-pong tests to verify. If packets are 
only placed on the vif queue singly though then the batching should have no 
effect, since rx_action will complete and do the push as before.

  Paul

> What are those 'some tests' you speak off?
> 
> Thanks.
> >
> > Signed-off-by: David Vrabel  [re-based]
> > Signed-off-by: Paul Durrant 
> > ---
> > Cc: Wei Liu 
> > ---
> >  drivers/net/xen-netback/rx.c | 15 ++-
> >  1 file changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/xen-netback/rx.c
> > b/drivers/net/xen-netback/rx.c index 9548709..ae822b8 100644
> > --- a/drivers/net/xen-netback/rx.c
> > +++ b/drivers/net/xen-netback/rx.c
> > @@ -399,7 +399,7 @@ static void xenvif_rx_extra_slot(struct
> xenvif_queue *queue,
> > BUG();
> >  }
> >
> > -void xenvif_rx_action(struct xenvif_queue *queue)
> > +void xenvif_rx_skb(struct xenvif_queue *queue)
> >  {
> > struct xenvif_pkt_state pkt;
> >
> > @@ -425,6 +425,19 @@ void xenvif_rx_action(struct xenvif_queue
> *queue)
> > xenvif_rx_complete(queue, );
> >  }
> >
> > +#define RX_BATCH_SIZE 64
> > +
> > +void xenvif_rx_action(struct xenvif_queue *queue) {
> > +   unsigned int work_done = 0;
> > +
> > +   while (xenvif_rx_ring_slots_available(queue) &&
> > +  work_done < RX_BATCH_SIZE) {
> > +   xenvif_rx_skb(queue);
> > +   work_done++;
> > +   }
> > +}
> > +
> >  static bool xenvif_rx_queue_stalled(struct xenvif_queue *queue)  {
> > RING_IDX prod, cons;
> > --
> > 2.1.4
> >
> >
> > ___
> > Xen-devel mailing list
> > xen-de...@lists.xen.org
> > https://lists.xen.org/xen-devel

Re: [PATCH v6 net-next] net: phy: Add Edge-rate driver for Microsemi PHYs.

[Raju Lakkaraju]

Hi Andrew,

Thank you for review comments.
I accepted your review comment and change the code.
I resent for code review.

Thanks,
Raju.

On Tue, Oct 04, 2016 at 02:53:19PM +0200, Andrew Lunn wrote:
> EXTERNAL EMAIL
> 
> 
> > Regarding remove the -'s in table, PHY data sheet descript the
> > concept of edge rate with table. I would like to keep the same table
> > in driver.
> 
> The double negative makes the code ugly. Plus a negative slowdown is a
> speed up! The kernel maintainability and sanity comes first, and if
> the data sheet is crazy, because it uses negative slows downs, it
> should be ignored. Get the data sheet fixed
> 
>Andrew

[PATCH v7 net-next] net: phy: Add Edge-rate driver for Microsemi PHYs.

[Raju Lakkaraju]

From: Raju Lakkaraju 

Edge-rate:
As system and networking speeds increase, a signal's output transition,
also know as the edge rate or slew rate (V/ns), takes on greater importance
because high-speed signals come with a price. That price is an assortment of
interference problems like ringing on the line, signal overshoot and
undershoot, extended signal settling times, crosstalk noise, transmission
line reflections, false signal detection by the receiving device and
electromagnetic interference (EMI) -- all of which can negate the potential
gains designers are seeking when they try to increase system speeds through
the use of higher performance logic devices. The fact is, faster signaling
edge rates can cause a higher level of electrical noise or other type of
interference that can actually lead to slower line speeds and lower maximum
system frequencies. This parameter allow the board designers to change the
driving strange, and thereby change the EMI behavioral.

Edge-rate parameters (vddmac, edge-slowdown) get from Device Tree.

Tested on Beaglebone Black with VSC 8531 PHY.

Signed-off-by: Raju Lakkaraju 

---
All the review comments updated and resending for review.

Change set:
v1:
- Initial version of Edge-rate driver add by using IOCTL.
v2:
- Changed edge-rate parameter to Device Tree with magic number.
v3:
- Added Device Tree documentati0n and edge-rate parameter table.
  Added probe function initialize the vsc8531 private data structure.
v4:
- As per review comment, Device Tree parameters (vddmac, edge-slowdown)
  added.
v5:
- As per review comment, Device Tree Document parameters (vddmac, 
  edge-slowdown) real numbers added. Table number changed from 5 to 1.
v6:
- As per review comment, Removed Device Tree header file. Removed MACROs
  and add ARRAYSIZE
v7:
- As per review comment, Removed '-'s (minus) sign in Edge rate table. 

---

 .../devicetree/bindings/net/mscc-phy-vsc8531.txt   |  3 +-
 drivers/net/phy/mscc.c | 43 --
 include/dt-bindings/net/mscc-phy-vsc8531.h | 21 ---
 3 files changed, 26 insertions(+), 41 deletions(-)
 delete mode 100644 include/dt-bindings/net/mscc-phy-vsc8531.h

diff --git a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt 
b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
index 99c7eb0..241841c 100644
--- a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
+++ b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
@@ -18,7 +18,8 @@ Optional properties:
  to reprogram drive strength and in effect slow
  down the edge rate if desired.  Table 1 shows the
  impact to the edge rate per VDDMAC supply for each
- drive strength setting.
+ drive strength setting. VDDMAC supply voltage
+ should be one of the value in Table-1 first row.
  Ref: Table:1 - Edge rate change below.
 
 Note: see dt-bindings/net/mscc-phy-vsc8531.h for applicable values
diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
index a17573e..b40cf18c 100644
--- a/drivers/net/phy/mscc.c
+++ b/drivers/net/phy/mscc.c
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 
 enum rgmii_rx_clock_delay {
RGMII_RX_CLK_DELAY_0_2_NS = 0,
@@ -56,16 +55,18 @@ enum rgmii_rx_clock_delay {
 #define PHY_ID_VSC8531   0x00070570
 #define PHY_ID_VSC8541   0x00070770
 
+#define MSCC_SLOWDOWN_MAX8
+
 struct edge_rate_table {
u16 vddmac;
-   int slowdown[MSCC_SLOWDOWN_MAX];
+   u8 slowdown[MSCC_SLOWDOWN_MAX];
 };
 
-struct edge_rate_table edge_table[MSCC_VDDMAC_MAX] = {
-   {3300, { 0, -2, -4,  -7,  -10, -17, -29, -53} },
-   {2500, { 0, -3, -6,  -10, -14, -23, -37, -63} },
-   {1800, { 0, -5, -9,  -16, -23, -35, -52, -76} },
-   {1500, { 0, -6, -14, -21, -29, -42, -58, -77} },
+static const struct edge_rate_table edge_table[] = {
+   {3300, { 0, 2, 4,  7,  10, 17, 29, 53} },
+   {2500, { 0, 3, 6,  10, 14, 23, 37, 63} },
+   {1800, { 0, 5, 9,  16, 23, 35, 52, 76} },
+   {1500, { 0, 6, 14, 21, 29, 42, 58, 77} },
 };
 
 struct vsc8531_private {
@@ -81,21 +82,26 @@ static int vsc85xx_phy_page_set(struct phy_device *phydev, 
u8 page)
return rc;
 }
 
-static u8 edge_rate_magic_get(u16 vddmac,
- int slowdown)
+static u8 vsc85xx_edge_rate_magic_get(u16 vddmac,
+ u8 slowdown)
 {
-   int rc = (MSCC_SLOWDOWN_MAX - 1);
+   int rc = (ARRAY_SIZE(edge_table[0].slowdown) - 1);
u8 vdd;
u8 sd;
 
-   for (vdd = 0; vdd < MSCC_VDDMAC_MAX; vdd++) {
+   for (vdd = 0; vdd < ARRAY_SIZE(edge_table); vdd++) {
if (edge_table[vdd].vddmac == vddmac) {
-   for (sd = 0; sd < 

RE: [Xen-devel] [PATCH v2 net-next 2/7] xen-netback: retire guest rx side prefix GSO feature

[Paul Durrant]

> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: 04 October 2016 13:52
> To: Paul Durrant ; annie...@oracle.com;
> joao.m.mart...@oracle.com
> Cc: netdev@vger.kernel.org; xen-de...@lists.xenproject.org; Wei Liu
> 
> Subject: Re: [Xen-devel] [PATCH v2 net-next 2/7] xen-netback: retire guest
> rx side prefix GSO feature
> 
> On Tue, Oct 04, 2016 at 10:29:13AM +0100, Paul Durrant wrote:
> > As far as I am aware only very old Windows network frontends make use
> > of this style of passing GSO packets from backend to frontend. These
> > frontends can easily be replaced by the freely available Xen Project
> > Windows PV network frontend, which uses the 'default' mechanism for
> > passing GSO packets, which is also used by all Linux frontends.
> 
> It is not that simple. Some companies have extra juice in their Windows
> frontends so can't easily swap over to the Xen Project one.

Ok, then those frontends will continue to work, but they won't get GSO packets 
any more. Prefix GSO has never been specified in the canonical netif header and 
so has been in a limbo state forever so such frontends have always been on 
borrowed time and only just happened to work against a linux backend. If 
someone wants to actually specify prefix GSO properly then it could be added 
back in, but it should not be necessary now that the RX side req<->rsp identity 
relation is documented 
(http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/io/netif.h;hb=HEAD#l729).

> 
> Either way CC-ing Annie
> 
> Also would it make sense to CC the FreeBSD and NetBSD maintainers of their
> PV drivers just to make sure? (Or has that been confirmed)
> 

I could do that, but I'd hope that they would be subscribed to xen-devel and 
will chime in if there's likely to be a problem.

> >
> > NOTE: Removal of this feature will not cause breakage in old Windows
> >   frontends. They simply will no longer receive GSO packets - the
> >   packets instead being fragmented in the backend.
> 
> Did you also test this with SuSE/Novell Windows PV drivers?
> 

No, I don't have copies of these. Internal XenServer testing has not shown up 
any issues with 'legacy' PV drivers though (which do still have the prefix GSO 
code in).

  Paul

> Thanks.
> >
> > Signed-off-by: Paul Durrant 
> > ---
> > Cc: Wei Liu 
> > ---
> >  drivers/net/xen-netback/common.h|  1 -
> >  drivers/net/xen-netback/interface.c |  4 ++--
> >  drivers/net/xen-netback/rx.c| 26 --
> >  drivers/net/xen-netback/xenbus.c| 21 -
> >  4 files changed, 2 insertions(+), 50 deletions(-)
> >
> > diff --git a/drivers/net/xen-netback/common.h
> > b/drivers/net/xen-netback/common.h
> > index b38fb2c..0ba5910 100644
> > --- a/drivers/net/xen-netback/common.h
> > +++ b/drivers/net/xen-netback/common.h
> > @@ -260,7 +260,6 @@ struct xenvif {
> >
> > /* Frontend feature information. */
> > int gso_mask;
> > -   int gso_prefix_mask;
> >
> > u8 can_sg:1;
> > u8 ip_csum:1;
> > diff --git a/drivers/net/xen-netback/interface.c
> > b/drivers/net/xen-netback/interface.c
> > index fb50c6d..211d542 100644
> > --- a/drivers/net/xen-netback/interface.c
> > +++ b/drivers/net/xen-netback/interface.c
> > @@ -319,9 +319,9 @@ static netdev_features_t
> > xenvif_fix_features(struct net_device *dev,
> >
> > if (!vif->can_sg)
> > features &= ~NETIF_F_SG;
> > -   if (~(vif->gso_mask | vif->gso_prefix_mask) & GSO_BIT(TCPV4))
> > +   if (~(vif->gso_mask) & GSO_BIT(TCPV4))
> > features &= ~NETIF_F_TSO;
> > -   if (~(vif->gso_mask | vif->gso_prefix_mask) & GSO_BIT(TCPV6))
> > +   if (~(vif->gso_mask) & GSO_BIT(TCPV6))
> > features &= ~NETIF_F_TSO6;
> > if (!vif->ip_csum)
> > features &= ~NETIF_F_IP_CSUM;
> > diff --git a/drivers/net/xen-netback/rx.c
> > b/drivers/net/xen-netback/rx.c index 03836aa..6bd7d6e 100644
> > --- a/drivers/net/xen-netback/rx.c
> > +++ b/drivers/net/xen-netback/rx.c
> > @@ -347,16 +347,6 @@ static int xenvif_gop_skb(struct sk_buff *skb,
> > gso_type = XEN_NETIF_GSO_TYPE_TCPV6;
> > }
> >
> > -   /* Set up a GSO prefix descriptor, if necessary */
> > -   if ((1 << gso_type) & vif->gso_prefix_mask) {
> > -   RING_COPY_REQUEST(>rx, queue->rx.req_cons++,
> );
> > -   meta = npo->meta + npo->meta_prod++;
> > -   meta->gso_type = gso_type;
> > -   meta->gso_size = skb_shinfo(skb)->gso_size;
> > -   meta->size = 0;
> > -   meta->id = req.id;
> > -   }
> > -
> > RING_COPY_REQUEST(>rx, queue->rx.req_cons++, );
> > meta = npo->meta + npo->meta_prod++;
> >
> > @@ -511,22 +501,6 @@ static void xenvif_rx_action(struct xenvif_queue
> *queue)
> > while ((skb = __skb_dequeue()) != NULL) {
> > struct xen_netif_extra_info *extra = NULL;
> >
> > -

[net-next PATCH] drivers: net: cpsw-phy-sel: add support to configure rgmii internal delay

[Mugunthan V N]

Add support to enable CPSW RGMII internal delay (id mode) bits
when rgmii internal delay is configured in phy.

Signed-off-by: Mugunthan V N 
---
 drivers/net/ethernet/ti/cpsw-phy-sel.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/net/ethernet/ti/cpsw-phy-sel.c 
b/drivers/net/ethernet/ti/cpsw-phy-sel.c
index c3e85ac..054a8dd 100644
--- a/drivers/net/ethernet/ti/cpsw-phy-sel.c
+++ b/drivers/net/ethernet/ti/cpsw-phy-sel.c
@@ -30,6 +30,8 @@
 
 #define AM33XX_GMII_SEL_RMII2_IO_CLK_ENBIT(7)
 #define AM33XX_GMII_SEL_RMII1_IO_CLK_ENBIT(6)
+#define AM33XX_GMII_SEL_RGMII2_IDMODE  BIT(5)
+#define AM33XX_GMII_SEL_RGMII1_IDMODE  BIT(4)
 
 #define GMII_SEL_MODE_MASK 0x3
 
@@ -48,6 +50,7 @@ static void cpsw_gmii_sel_am3352(struct cpsw_phy_sel_priv 
*priv,
u32 reg;
u32 mask;
u32 mode = 0;
+   bool rgmii_id = false;
 
reg = readl(priv->gmii_sel);
 
@@ -57,10 +60,14 @@ static void cpsw_gmii_sel_am3352(struct cpsw_phy_sel_priv 
*priv,
break;
 
case PHY_INTERFACE_MODE_RGMII:
+   mode = AM33XX_GMII_SEL_MODE_RGMII;
+   break;
+
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII_RXID:
case PHY_INTERFACE_MODE_RGMII_TXID:
mode = AM33XX_GMII_SEL_MODE_RGMII;
+   rgmii_id = true;
break;
 
default:
@@ -83,6 +90,13 @@ static void cpsw_gmii_sel_am3352(struct cpsw_phy_sel_priv 
*priv,
mode |= AM33XX_GMII_SEL_RMII2_IO_CLK_EN;
}
 
+   if (rgmii_id) {
+   if (slave == 0)
+   mode |= AM33XX_GMII_SEL_RGMII1_IDMODE;
+   else
+   mode |= AM33XX_GMII_SEL_RGMII2_IDMODE;
+   }
+
reg &= ~mask;
reg |= mode;
 
-- 
2.10.0.372.g6fe1b14

Re: [PATCH v2 4/4] ARM: dts: dra72-evm-revc: fix correct phy delay

[Andrew Lunn]

On Tue, Oct 04, 2016 at 06:26:07PM +0530, Mugunthan V N wrote:
> The current delay settings of the phy are not the optimal value,
> fix it with correct values.

This should be a separate patch, since it has nothing to do with impedance.

 Andrew

> 
> Signed-off-by: Mugunthan V N 
> ---
>  arch/arm/boot/dts/dra72-evm-revc.dts | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts 
> b/arch/arm/boot/dts/dra72-evm-revc.dts
> index d626cd7..8472a8c 100644
> --- a/arch/arm/boot/dts/dra72-evm-revc.dts
> +++ b/arch/arm/boot/dts/dra72-evm-revc.dts
> @@ -59,16 +59,16 @@
>  _mdio {
>   dp83867_0: ethernet-phy@2 {
>   reg = <2>;
> - ti,rx-internal-delay = ;
> - ti,tx-internal-delay = ;
> + ti,rx-internal-delay = ;
> + ti,tx-internal-delay = ;
>   ti,fifo-depth = ;
>   ti,min-output-imepdance;
>   };
>  
>   dp83867_1: ethernet-phy@3 {
>   reg = <3>;
> - ti,rx-internal-delay = ;
> - ti,tx-internal-delay = ;
> + ti,rx-internal-delay = ;
> + ti,tx-internal-delay = ;
>   ti,fifo-depth = ;
>   ti,min-output-imepdance;
>   };
> -- 
> 2.10.0.372.g6fe1b14
> 

Re: [PATCH v2 3/4] ARM: dts: dra72-evm-revc: fix correct phy delay and impedance settings

[Andrew Lunn]

On Tue, Oct 04, 2016 at 06:26:06PM +0530, Mugunthan V N wrote:
> The default impedance settings of the phy is not the optimal
> value, due to this the second ethernet is not working. Fix it
> with correct values which makes the second ethernet port to work.
> 
> Signed-off-by: Mugunthan V N 
> ---
>  arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts 
> b/arch/arm/boot/dts/dra72-evm-revc.dts
> index f9cfd3b..d626cd7 100644
> --- a/arch/arm/boot/dts/dra72-evm-revc.dts
> +++ b/arch/arm/boot/dts/dra72-evm-revc.dts
> @@ -62,6 +62,7 @@
>   ti,rx-internal-delay = ;
>   ti,tx-internal-delay = ;
>   ti,fifo-depth = ;
> + ti,min-output-imepdance;

And there is my answer :-(

Andrew

Re: [PATCH v2 2/4] net: phy: dp83867: add support for MAC impedance configuration

[Lokesh Vutla]

On Tuesday 04 October 2016 06:26 PM, Mugunthan V N wrote:
> Add support for programmable MAC impedance configuration
> 
> Signed-off-by: Mugunthan V N 
> ---
>  drivers/net/phy/dp83867.c | 28 
>  1 file changed, 28 insertions(+)
> 
> diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
> index 91177a4..795ae17 100644
> --- a/drivers/net/phy/dp83867.c
> +++ b/drivers/net/phy/dp83867.c
> @@ -33,6 +33,7 @@
>  /* Extended Registers */
>  #define DP83867_RGMIICTL 0x0032
>  #define DP83867_RGMIIDCTL0x0086
> +#define DP83867_IO_MUX_CFG   0x0170
>  
>  #define DP83867_SW_RESET BIT(15)
>  #define DP83867_SW_RESTART   BIT(14)
> @@ -62,10 +63,17 @@
>  /* RGMIIDCTL bits */
>  #define DP83867_RGMII_TX_CLK_DELAY_SHIFT 4
>  
> +/* IO_MUX_CFG bits */
> +#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL 0x1f
> +
> +#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX  0x0
> +#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN  0x1f
> +
>  struct dp83867_private {
>   int rx_id_delay;
>   int tx_id_delay;
>   int fifo_depth;
> + int io_impedance;
>  };
>  
>  static int dp83867_ack_interrupt(struct phy_device *phydev)
> @@ -111,6 +119,14 @@ static int dp83867_of_init(struct phy_device *phydev)
>   if (!of_node)
>   return -ENODEV;
>  
> + dp83867->io_impedance = -EINVAL;
> +
> + /* Optional configuration */
> + if (of_property_read_bool(of_node, "ti,max-output-imepdance"))

s/imepdance/impedance

> + dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
> + else if (of_property_read_bool(of_node, "ti,min-output-imepdance"))

s/imepdance/impedance

Thanks and regards,
Lokesh

> + dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN;
> +
>   ret = of_property_read_u32(of_node, "ti,rx-internal-delay",
>  >rx_id_delay);
>   if (ret)
> @@ -184,6 +200,18 @@ static int dp83867_config_init(struct phy_device *phydev)
>  
>   phy_write_mmd_indirect(phydev, DP83867_RGMIIDCTL,
>  DP83867_DEVADDR, delay);
> +
> + if (dp83867->io_impedance >= 0) {
> + val = phy_read_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
> + DP83867_DEVADDR);
> +
> + val &= ~DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
> + val |= dp83867->io_impedance &
> +DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
> +
> + phy_write_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
> +DP83867_DEVADDR, val);
> + }
>   }
>  
>   return 0;
> 

Re: [PATCH v2 3/4] ARM: dts: dra72-evm-revc: fix correct phy delay and impedance settings

[Lokesh Vutla]

On Tuesday 04 October 2016 06:26 PM, Mugunthan V N wrote:
> The default impedance settings of the phy is not the optimal
> value, due to this the second ethernet is not working. Fix it
> with correct values which makes the second ethernet port to work.
> 
> Signed-off-by: Mugunthan V N 
> ---
>  arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts 
> b/arch/arm/boot/dts/dra72-evm-revc.dts
> index f9cfd3b..d626cd7 100644
> --- a/arch/arm/boot/dts/dra72-evm-revc.dts
> +++ b/arch/arm/boot/dts/dra72-evm-revc.dts
> @@ -62,6 +62,7 @@
>   ti,rx-internal-delay = ;
>   ti,tx-internal-delay = ;
>   ti,fifo-depth = ;
> + ti,min-output-imepdance;

s/imepdance/impedance

>   };
>  
>   dp83867_1: ethernet-phy@3 {
> @@ -69,5 +70,6 @@
>   ti,rx-internal-delay = ;
>   ti,tx-internal-delay = ;
>   ti,fifo-depth = ;
> + ti,min-output-imepdance;

same here.

Thanks and regards,
Lokesh

>   };
>  };
> 

Re: [PATCH v2 2/4] net: phy: dp83867: add support for MAC impedance configuration

[Andrew Lunn]

> + if (of_property_read_bool(of_node, "ti,max-output-imepdance"))
> + dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
> + else if (of_property_read_bool(of_node, "ti,min-output-imepdance"))

Did you really test this? Or did you make the same typos in your device
tree file?

Andrew

[PATCH v2 2/4] net: phy: dp83867: add support for MAC impedance configuration

[Mugunthan V N]

Add support for programmable MAC impedance configuration

Signed-off-by: Mugunthan V N 
---
 drivers/net/phy/dp83867.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 91177a4..795ae17 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -33,6 +33,7 @@
 /* Extended Registers */
 #define DP83867_RGMIICTL   0x0032
 #define DP83867_RGMIIDCTL  0x0086
+#define DP83867_IO_MUX_CFG 0x0170
 
 #define DP83867_SW_RESET   BIT(15)
 #define DP83867_SW_RESTART BIT(14)
@@ -62,10 +63,17 @@
 /* RGMIIDCTL bits */
 #define DP83867_RGMII_TX_CLK_DELAY_SHIFT   4
 
+/* IO_MUX_CFG bits */
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL   0x1f
+
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX0x0
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN0x1f
+
 struct dp83867_private {
int rx_id_delay;
int tx_id_delay;
int fifo_depth;
+   int io_impedance;
 };
 
 static int dp83867_ack_interrupt(struct phy_device *phydev)
@@ -111,6 +119,14 @@ static int dp83867_of_init(struct phy_device *phydev)
if (!of_node)
return -ENODEV;
 
+   dp83867->io_impedance = -EINVAL;
+
+   /* Optional configuration */
+   if (of_property_read_bool(of_node, "ti,max-output-imepdance"))
+   dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
+   else if (of_property_read_bool(of_node, "ti,min-output-imepdance"))
+   dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN;
+
ret = of_property_read_u32(of_node, "ti,rx-internal-delay",
   >rx_id_delay);
if (ret)
@@ -184,6 +200,18 @@ static int dp83867_config_init(struct phy_device *phydev)
 
phy_write_mmd_indirect(phydev, DP83867_RGMIIDCTL,
   DP83867_DEVADDR, delay);
+
+   if (dp83867->io_impedance >= 0) {
+   val = phy_read_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+   DP83867_DEVADDR);
+
+   val &= ~DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+   val |= dp83867->io_impedance &
+  DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+
+   phy_write_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+  DP83867_DEVADDR, val);
+   }
}
 
return 0;
-- 
2.10.0.372.g6fe1b14

[PATCH v2 0/4] add support for impedance control for TI dp83867 phy and fix 2nd ethernet on dra72 rev C evm

[Mugunthan V N]

Add support for configurable impedance control for TI dp83867
phy via devicetree. More documentation in [1].
CPSW second ethernet is not working, fix it by enabling
impedance configuration on the phy.

Verified the patch on DRA72 Rev C evm, logs at [2]. Also pushed
a branch [3] for others to test.

Changes from initial version:
* As per Sekhar's comment, instead of passing impedance values,
  change to max and min impedance from DT
* Adopted phy_read_mmd_indirect() to cunnrent implementation.
* Corrected the phy delay timings to the optimal value.

[1] - http://www.ti.com/lit/ds/symlink/dp83867ir.pdf
[2] - http://pastebin.ubuntu.com/23274616/
[3] - git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git dp83867-v2

Mugunthan V N (4):
  net: phy: dp83867: Add documentation for optional impedance control
  net: phy: dp83867: add support for MAC impedance configuration
  ARM: dts: dra72-evm-revc: fix correct phy delay and impedance settings
  ARM: dts: dra72-evm-revc: fix correct phy delay

 .../devicetree/bindings/net/ti,dp83867.txt | 12 ++
 arch/arm/boot/dts/dra72-evm-revc.dts   | 10 
 drivers/net/phy/dp83867.c  | 28 ++
 3 files changed, 46 insertions(+), 4 deletions(-)

-- 
2.10.0.372.g6fe1b14

[PATCH v2 4/4] ARM: dts: dra72-evm-revc: fix correct phy delay

[Mugunthan V N]

The current delay settings of the phy are not the optimal value,
fix it with correct values.

Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/dra72-evm-revc.dts | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts 
b/arch/arm/boot/dts/dra72-evm-revc.dts
index d626cd7..8472a8c 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -59,16 +59,16 @@
 _mdio {
dp83867_0: ethernet-phy@2 {
reg = <2>;
-   ti,rx-internal-delay = ;
-   ti,tx-internal-delay = ;
+   ti,rx-internal-delay = ;
+   ti,tx-internal-delay = ;
ti,fifo-depth = ;
ti,min-output-imepdance;
};
 
dp83867_1: ethernet-phy@3 {
reg = <3>;
-   ti,rx-internal-delay = ;
-   ti,tx-internal-delay = ;
+   ti,rx-internal-delay = ;
+   ti,tx-internal-delay = ;
ti,fifo-depth = ;
ti,min-output-imepdance;
};
-- 
2.10.0.372.g6fe1b14

[PATCH v2 3/4] ARM: dts: dra72-evm-revc: fix correct phy delay and impedance settings

[Mugunthan V N]

The default impedance settings of the phy is not the optimal
value, due to this the second ethernet is not working. Fix it
with correct values which makes the second ethernet port to work.

Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts 
b/arch/arm/boot/dts/dra72-evm-revc.dts
index f9cfd3b..d626cd7 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -62,6 +62,7 @@
ti,rx-internal-delay = ;
ti,tx-internal-delay = ;
ti,fifo-depth = ;
+   ti,min-output-imepdance;
};
 
dp83867_1: ethernet-phy@3 {
@@ -69,5 +70,6 @@
ti,rx-internal-delay = ;
ti,tx-internal-delay = ;
ti,fifo-depth = ;
+   ti,min-output-imepdance;
};
 };
-- 
2.10.0.372.g6fe1b14

[PATCH][V2] net: hns: Add missing \n to end of dev_err messages, tidy up text

[Colin King]

From: Colin Ian King 

Trival fix, dev_err messages are missing a \n, so add it. Also
fix grammer, spelling mistake and add white spaces to various
error messages.

Signed-off-by: Colin Ian King 
---
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
index a834774..751c126 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
@@ -126,7 +126,7 @@ void hns_mac_adjust_link(struct hns_mac_cb *mac_cb, int 
speed, int duplex)
(enum mac_speed)speed, duplex);
if (ret) {
dev_err(mac_cb->dev,
-   "adjust_link failed,%s mac%d ret = %#x!\n",
+   "adjust_link failed, %s mac%d ret = %#x!\n",
mac_cb->dsaf_dev->ae_dev.name,
mac_cb->mac_id, ret);
return;
@@ -149,7 +149,7 @@ static int hns_mac_get_inner_port_num(struct hns_mac_cb 
*mac_cb,
if (mac_cb->dsaf_dev->dsaf_mode <= DSAF_MODE_ENABLE) {
if (mac_cb->mac_id != DSAF_MAX_PORT_NUM) {
dev_err(mac_cb->dev,
-   "input invalid,%s mac%d vmid%d !\n",
+   "input invalid, %s mac%d vmid%d !\n",
mac_cb->dsaf_dev->ae_dev.name,
mac_cb->mac_id, vmid);
return -EINVAL;
@@ -157,19 +157,19 @@ static int hns_mac_get_inner_port_num(struct hns_mac_cb 
*mac_cb,
} else if (mac_cb->dsaf_dev->dsaf_mode < DSAF_MODE_MAX) {
if (mac_cb->mac_id >= DSAF_MAX_PORT_NUM) {
dev_err(mac_cb->dev,
-   "input invalid,%s mac%d vmid%d!\n",
+   "input invalid, %s mac%d vmid%d!\n",
mac_cb->dsaf_dev->ae_dev.name,
mac_cb->mac_id, vmid);
return -EINVAL;
}
} else {
-   dev_err(mac_cb->dev, "dsaf mode invalid,%s mac%d!\n",
+   dev_err(mac_cb->dev, "dsaf mode invalid, %s mac%d!\n",
mac_cb->dsaf_dev->ae_dev.name, mac_cb->mac_id);
return -EINVAL;
}
 
if (vmid >= mac_cb->dsaf_dev->rcb_common[0]->max_vfn) {
-   dev_err(mac_cb->dev, "input invalid,%s mac%d vmid%d !\n",
+   dev_err(mac_cb->dev, "input invalid, %s mac%d vmid%d !\n",
mac_cb->dsaf_dev->ae_dev.name, mac_cb->mac_id, vmid);
return -EINVAL;
}
@@ -196,7 +196,7 @@ static int hns_mac_get_inner_port_num(struct hns_mac_cb 
*mac_cb,
tmp_port = vmid;
break;
default:
-   dev_err(mac_cb->dev, "dsaf mode invalid,%s mac%d!\n",
+   dev_err(mac_cb->dev, "dsaf mode invalid, %s mac%d!\n",
mac_cb->dsaf_dev->ae_dev.name, mac_cb->mac_id);
return -EINVAL;
}
@@ -275,7 +275,7 @@ int hns_mac_set_multi(struct hns_mac_cb *mac_cb,
ret = hns_dsaf_add_mac_mc_port(dsaf_dev, _entry);
if (ret) {
dev_err(dsaf_dev->dev,
-   "set mac mc port failed,%s mac%d ret = %#x!\n",
+   "set mac mc port failed, %s mac%d ret = %#x!\n",
mac_cb->dsaf_dev->ae_dev.name,
mac_cb->mac_id, ret);
return ret;
@@ -305,7 +305,7 @@ int hns_mac_del_mac(struct hns_mac_cb *mac_cb, u32 vfn, 
char *mac)
old_mac = _cb->addr_entry_idx[vfn];
} else {
dev_err(mac_cb->dev,
-   "vf queue is too large,%s mac%d queue = %#x!\n",
+   "vf queue is too large, %s mac%d queue = %#x!\n",
mac_cb->dsaf_dev->ae_dev.name, mac_cb->mac_id, vfn);
return -EINVAL;
}
@@ -547,7 +547,7 @@ int hns_mac_set_autoneg(struct hns_mac_cb *mac_cb, u8 
enable)
struct mac_driver *mac_ctrl_drv = hns_mac_get_drv(mac_cb);
 
if (mac_cb->phy_if == PHY_INTERFACE_MODE_XGMII && enable) {
-   dev_err(mac_cb->dev, "enable autoneg is not allowed!");
+   dev_err(mac_cb->dev, "enabling autoneg is not allowed!\n");
return -ENOTSUPP;
}
 
@@ -571,7 +571,7 @@ int hns_mac_set_pauseparam(struct hns_mac_cb *mac_cb, u32 
rx_en, u32 tx_en)
 
if (mac_cb->mac_type == HNAE_PORT_DEBUG) {
if (is_ver1 && (tx_en || rx_en)) {
-   dev_err(mac_cb->dev, "macv1 cann't enable 
tx/rx_pause!");

[PATCH v2 1/4] net: phy: dp83867: Add documentation for optional impedance control

[Mugunthan V N]

Add documention of ti,impedance-control which can be used to
correct MAC impedance mismatch using phy extended registers.

Signed-off-by: Mugunthan V N 
---
 Documentation/devicetree/bindings/net/ti,dp83867.txt | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt 
b/Documentation/devicetree/bindings/net/ti,dp83867.txt
index 5d21141..85bf945 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
+++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
@@ -9,6 +9,18 @@ Required properties:
- ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
for applicable values
 
+Optional property:
+   - ti,min-output-impedance - MAC Interface Impedance control to set
+   the programmable output impedance to
+   minimum value (35 ohms).
+   - ti,max-output-impedance - MAC Interface Impedance control to set
+   the programmable output impedance to
+   maximum value (70 ohms).
+
+Note: ti,min-output-impedance and ti,max-output-impedance are mutually
+  exclusive. When both properties are present ti,max-output-impedance
+  takes precedence.
+
 Default child nodes are standard Ethernet PHY device
 nodes as described in Documentation/devicetree/bindings/net/phy.txt
 
-- 
2.10.0.372.g6fe1b14

Re: [PATCH v6 net-next] net: phy: Add Edge-rate driver for Microsemi PHYs.

[Andrew Lunn]

> Regarding remove the -'s in table, PHY data sheet descript the
> concept of edge rate with table. I would like to keep the same table
> in driver.

The double negative makes the code ugly. Plus a negative slowdown is a
speed up! The kernel maintainability and sanity comes first, and if
the data sheet is crazy, because it uses negative slows downs, it
should be ignored. Get the data sheet fixed

   Andrew

Re: [Xen-devel] [PATCH v2 net-next 2/7] xen-netback: retire guest rx side prefix GSO feature

[Konrad Rzeszutek Wilk]

On Tue, Oct 04, 2016 at 10:29:13AM +0100, Paul Durrant wrote:
> As far as I am aware only very old Windows network frontends make use of
> this style of passing GSO packets from backend to frontend. These
> frontends can easily be replaced by the freely available Xen Project
> Windows PV network frontend, which uses the 'default' mechanism for
> passing GSO packets, which is also used by all Linux frontends.

It is not that simple. Some companies have extra juice in their Windows
frontends so can't easily swap over to the Xen Project one.

Either way CC-ing Annie

Also would it make sense to CC the FreeBSD and NetBSD maintainers of
their PV drivers just to make sure? (Or has that been confirmed)

> 
> NOTE: Removal of this feature will not cause breakage in old Windows
>   frontends. They simply will no longer receive GSO packets - the
>   packets instead being fragmented in the backend.

Did you also test this with SuSE/Novell Windows PV drivers?

Thanks.
> 
> Signed-off-by: Paul Durrant 
> ---
> Cc: Wei Liu 
> ---
>  drivers/net/xen-netback/common.h|  1 -
>  drivers/net/xen-netback/interface.c |  4 ++--
>  drivers/net/xen-netback/rx.c| 26 --
>  drivers/net/xen-netback/xenbus.c| 21 -
>  4 files changed, 2 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/common.h 
> b/drivers/net/xen-netback/common.h
> index b38fb2c..0ba5910 100644
> --- a/drivers/net/xen-netback/common.h
> +++ b/drivers/net/xen-netback/common.h
> @@ -260,7 +260,6 @@ struct xenvif {
>  
>   /* Frontend feature information. */
>   int gso_mask;
> - int gso_prefix_mask;
>  
>   u8 can_sg:1;
>   u8 ip_csum:1;
> diff --git a/drivers/net/xen-netback/interface.c 
> b/drivers/net/xen-netback/interface.c
> index fb50c6d..211d542 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -319,9 +319,9 @@ static netdev_features_t xenvif_fix_features(struct 
> net_device *dev,
>  
>   if (!vif->can_sg)
>   features &= ~NETIF_F_SG;
> - if (~(vif->gso_mask | vif->gso_prefix_mask) & GSO_BIT(TCPV4))
> + if (~(vif->gso_mask) & GSO_BIT(TCPV4))
>   features &= ~NETIF_F_TSO;
> - if (~(vif->gso_mask | vif->gso_prefix_mask) & GSO_BIT(TCPV6))
> + if (~(vif->gso_mask) & GSO_BIT(TCPV6))
>   features &= ~NETIF_F_TSO6;
>   if (!vif->ip_csum)
>   features &= ~NETIF_F_IP_CSUM;
> diff --git a/drivers/net/xen-netback/rx.c b/drivers/net/xen-netback/rx.c
> index 03836aa..6bd7d6e 100644
> --- a/drivers/net/xen-netback/rx.c
> +++ b/drivers/net/xen-netback/rx.c
> @@ -347,16 +347,6 @@ static int xenvif_gop_skb(struct sk_buff *skb,
>   gso_type = XEN_NETIF_GSO_TYPE_TCPV6;
>   }
>  
> - /* Set up a GSO prefix descriptor, if necessary */
> - if ((1 << gso_type) & vif->gso_prefix_mask) {
> - RING_COPY_REQUEST(>rx, queue->rx.req_cons++, );
> - meta = npo->meta + npo->meta_prod++;
> - meta->gso_type = gso_type;
> - meta->gso_size = skb_shinfo(skb)->gso_size;
> - meta->size = 0;
> - meta->id = req.id;
> - }
> -
>   RING_COPY_REQUEST(>rx, queue->rx.req_cons++, );
>   meta = npo->meta + npo->meta_prod++;
>  
> @@ -511,22 +501,6 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
>   while ((skb = __skb_dequeue()) != NULL) {
>   struct xen_netif_extra_info *extra = NULL;
>  
> - if ((1 << queue->meta[npo.meta_cons].gso_type) &
> - vif->gso_prefix_mask) {
> - resp = RING_GET_RESPONSE(>rx,
> -  queue->rx.rsp_prod_pvt++);
> -
> - resp->flags = XEN_NETRXF_gso_prefix |
> -   XEN_NETRXF_more_data;
> -
> - resp->offset = queue->meta[npo.meta_cons].gso_size;
> - resp->id = queue->meta[npo.meta_cons].id;
> - resp->status = XENVIF_RX_CB(skb)->meta_slots_used;
> -
> - npo.meta_cons++;
> - XENVIF_RX_CB(skb)->meta_slots_used--;
> - }
> -
>   queue->stats.tx_bytes += skb->len;
>   queue->stats.tx_packets++;
>  
> diff --git a/drivers/net/xen-netback/xenbus.c 
> b/drivers/net/xen-netback/xenbus.c
> index daf4c78..7056404 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -1135,7 +1135,6 @@ static int read_xenbus_vif_flags(struct backend_info 
> *be)
>   vif->can_sg = !!val;
>  
>   vif->gso_mask = 0;
> - vif->gso_prefix_mask = 0;
>  
>   if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-gso-tcpv4",
>"%d", ) < 0)
> @@ -1143,32 +1142,12 @@ static int read_xenbus_vif_flags(struct backend_info 
> *be)
>   if (val)
>   

Re: [Xen-devel] [PATCH v2 net-next 4/7] xen-netback: immediately wake tx queue when guest rx queue has space

[Konrad Rzeszutek Wilk]

On Tue, Oct 04, 2016 at 02:29:15AM -0700, Paul Durrant wrote:
> From: David Vrabel 
> 
> When an skb is removed from the guest rx queue, immediately wake the
> tx queue, instead of after processing them.

Please, could the description explain why?

> 
> Signed-off-by: David Vrabel 
> [re-based]
> Signed-off-by: Paul Durrant 
> ---
> Cc: Wei Liu 
> ---
>  drivers/net/xen-netback/rx.c | 24 
>  1 file changed, 8 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/rx.c b/drivers/net/xen-netback/rx.c
> index b0ce4c6..9548709 100644
> --- a/drivers/net/xen-netback/rx.c
> +++ b/drivers/net/xen-netback/rx.c
> @@ -92,27 +92,21 @@ static struct sk_buff *xenvif_rx_dequeue(struct 
> xenvif_queue *queue)
>   spin_lock_irq(>rx_queue.lock);
>  
>   skb = __skb_dequeue(>rx_queue);
> - if (skb)
> + if (skb) {
>   queue->rx_queue_len -= skb->len;
> + if (queue->rx_queue_len < queue->rx_queue_max) {
> + struct netdev_queue *txq;
> +
> + txq = netdev_get_tx_queue(queue->vif->dev, queue->id);
> + netif_tx_wake_queue(txq);
> + }
> + }
>  
>   spin_unlock_irq(>rx_queue.lock);
>  
>   return skb;
>  }
>  
> -static void xenvif_rx_queue_maybe_wake(struct xenvif_queue *queue)
> -{
> - spin_lock_irq(>rx_queue.lock);
> -
> - if (queue->rx_queue_len < queue->rx_queue_max) {
> - struct net_device *dev = queue->vif->dev;
> -
> - netif_tx_wake_queue(netdev_get_tx_queue(dev, queue->id));
> - }
> -
> - spin_unlock_irq(>rx_queue.lock);
> -}
> -
>  static void xenvif_rx_queue_purge(struct xenvif_queue *queue)
>  {
>   struct sk_buff *skb;
> @@ -585,8 +579,6 @@ int xenvif_kthread_guest_rx(void *data)
>*/
>   xenvif_rx_queue_drop_expired(queue);
>  
> - xenvif_rx_queue_maybe_wake(queue);
> -
>   cond_resched();
>   }
>  
> -- 
> 2.1.4
> 
> 
> ___
> Xen-devel mailing list
> xen-de...@lists.xen.org
> https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 net-next 5/7] xen-netback: process guest rx packets in batches

[Konrad Rzeszutek Wilk]

On Tue, Oct 04, 2016 at 10:29:16AM +0100, Paul Durrant wrote:
> From: David Vrabel 
> 
> Instead of only placing one skb on the guest rx ring at a time, process
> a batch of up-to 64.  This improves performance by ~10% in some tests.

And does it regress latency workloads?

What are those 'some tests' you speak off?

Thanks.
> 
> Signed-off-by: David Vrabel 
> [re-based]
> Signed-off-by: Paul Durrant 
> ---
> Cc: Wei Liu 
> ---
>  drivers/net/xen-netback/rx.c | 15 ++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/xen-netback/rx.c b/drivers/net/xen-netback/rx.c
> index 9548709..ae822b8 100644
> --- a/drivers/net/xen-netback/rx.c
> +++ b/drivers/net/xen-netback/rx.c
> @@ -399,7 +399,7 @@ static void xenvif_rx_extra_slot(struct xenvif_queue 
> *queue,
>   BUG();
>  }
>  
> -void xenvif_rx_action(struct xenvif_queue *queue)
> +void xenvif_rx_skb(struct xenvif_queue *queue)
>  {
>   struct xenvif_pkt_state pkt;
>  
> @@ -425,6 +425,19 @@ void xenvif_rx_action(struct xenvif_queue *queue)
>   xenvif_rx_complete(queue, );
>  }
>  
> +#define RX_BATCH_SIZE 64
> +
> +void xenvif_rx_action(struct xenvif_queue *queue)
> +{
> + unsigned int work_done = 0;
> +
> + while (xenvif_rx_ring_slots_available(queue) &&
> +work_done < RX_BATCH_SIZE) {
> + xenvif_rx_skb(queue);
> + work_done++;
> + }
> +}
> +
>  static bool xenvif_rx_queue_stalled(struct xenvif_queue *queue)
>  {
>   RING_IDX prod, cons;
> -- 
> 2.1.4
> 
> 
> ___
> Xen-devel mailing list
> xen-de...@lists.xen.org
> https://lists.xen.org/xen-devel

Re: [v2] mwifiex: report wakeup for wowlan

[Kalle Valo]

Rajat Jain  writes:

> Hello Kalie,
>
> On Mon, Oct 3, 2016 at 6:04 AM, Kalle Valo  wrote:
>> Rajat Jain  wrote:
>>> Enable notifying wakeup source to the PM core in case of
>>> a wake on wireless LAN event.
>>>
>>> Signed-off-by: Wei-Ning Huang 
>>> Signed-off-by: Rajat Jain 
>>> Tested-by: Wei-Ning Huang 
>>> Reviewed-by: Eric Caruso 
>>> Acked-by: Amitkumar Karwar 
>>
>> The commit log doesn't give any background info. Does this fix a bug or
>> why is it needed?
>
> Some of chromeos' features (called "darkresume" in chromeos
> terminology) use and track the wake up sources using the wakeup
> attributes in sysfs. Since the wireless device can wake up the host,
> hence we wanted to add it as a wakeup source to the system, and in the
> case of an actual wakeup event, trigger to the PM core that it was
> indeed caused by the device and it increments the different counters
> etc. In the absence of this patch,  the feature wasn't working very
> well (as it was apparently confused about the cause of wake up).

Thanks, makes sense. Please add that to the commit and send v3.

-- 
Kalle Valo

Re: [PATCH] net: hns: qdd missing \n to end of dev_err messages

[Sergei Shtylyov]

Hello.

On 10/04/2016 02:06 PM, Colin King wrote:


From: Colin Ian King 

Trival fix, dev_err messages are missing a \n, so add it.

Signed-off-by: Colin Ian King 
---
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
index a834774..7aeed08 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
@@ -547,7 +547,7 @@ int hns_mac_set_autoneg(struct hns_mac_cb *mac_cb, u8 
enable)
struct mac_driver *mac_ctrl_drv = hns_mac_get_drv(mac_cb);

if (mac_cb->phy_if == PHY_INTERFACE_MODE_XGMII && enable) {
-   dev_err(mac_cb->dev, "enable autoneg is not allowed!");
+   dev_err(mac_cb->dev, "enable autoneg is not allowed!\n");


   Enabling, perhaps?


return -ENOTSUPP;
}

@@ -571,7 +571,7 @@ int hns_mac_set_pauseparam(struct hns_mac_cb *mac_cb, u32 
rx_en, u32 tx_en)

if (mac_cb->mac_type == HNAE_PORT_DEBUG) {
if (is_ver1 && (tx_en || rx_en)) {
-   dev_err(mac_cb->dev, "macv1 cann't enable 
tx/rx_pause!");
+   dev_err(mac_cb->dev, "macv1 cann't enable 
tx/rx_pause!\n");


   Perhaps a good time to fix this "cann't"?

[...]

MBR, Sergei

[PATCH net-next 2/2] openvswitch: fix vlan subtraction from packet length

[Jiri Benc]

When the packet has its vlan tag in skb->vlan_tci, the length of the VLAN
header is not counted in skb->len. It doesn't make sense to subtract it.

In addition, to honor the comment below the code, the VLAN header length
should not be subtracted if there's a vlan tag in skb->vlan_tci. This leads
to the code simply subtracting the Ethernet header length.

Fixes: 018c1dda5ff1 ("openvswitch: 802.1AD Flow handling, actions, vlan 
parsing, netlink attributes")
Signed-off-by: Jiri Benc 
---
 net/openvswitch/vport.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/net/openvswitch/vport.c b/net/openvswitch/vport.c
index 8f198437c724..210bafc09bd8 100644
--- a/net/openvswitch/vport.c
+++ b/net/openvswitch/vport.c
@@ -483,17 +483,13 @@ EXPORT_SYMBOL_GPL(ovs_vport_deferred_free);
 
 static unsigned int packet_length(const struct sk_buff *skb)
 {
-   unsigned int length = skb->len - ETH_HLEN;
-
-   if (skb_vlan_tagged(skb))
-   length -= VLAN_HLEN;
-
/* Don't subtract for multiple VLAN tags. Most (all?) drivers allow
 * (ETH_LEN + VLAN_HLEN) in addition to the mtu value, but almost none
 * account for 802.1ad. e.g. is_skb_forwardable().
+* Note that the first VLAN tag is always in skb->vlan_tci, thus not
+* accounted for in skb->len.
 */
-
-   return length;
+   return skb->len - ETH_HLEN;
 }
 
 void ovs_vport_send(struct vport *vport, struct sk_buff *skb)
-- 
1.8.3.1

[PATCH net-next 0/2] openvswitch: vlan fixes

[Jiri Benc]

Fix a bug and inefficiency in the vlan handling code introduced by the
802.1AD set. Strictly speaking, both were present even before that set
but it made them more prominent.

Jiri Benc (2):
  openvswitch: remove nonreachable code in vlan parsing
  openvswitch: fix vlan subtraction from packet length

 net/openvswitch/flow.c  | 28 
 net/openvswitch/vport.c | 10 +++---
 2 files changed, 11 insertions(+), 27 deletions(-)

-- 
1.8.3.1

[PATCH net-next 1/2] openvswitch: remove nonreachable code in vlan parsing

[Jiri Benc]

It can never happen that there's a vlan tag in the packet but not in
skb->vlan_tci. This is ensured in __netif_receive_skb_core and honored by
skb_vlan_push and skb_vlan_pop. The code dealing with such case is a dead
code.

Moreover, the likely() statement around skb_vlan_tag_present is bogus. This
code is called whenever flow key is being extracted from the packet. The
packet may be as likely vlan tagged as not.

Fixes: 018c1dda5ff1 ("openvswitch: 802.1AD Flow handling, actions, vlan 
parsing, netlink attributes")
Signed-off-by: Jiri Benc 
---
 net/openvswitch/flow.c | 28 
 1 file changed, 8 insertions(+), 20 deletions(-)

diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
index c8c82e109c68..d88c0a55b783 100644
--- a/net/openvswitch/flow.c
+++ b/net/openvswitch/flow.c
@@ -308,9 +308,7 @@ static bool icmp6hdr_ok(struct sk_buff *skb)
 
 /**
  * Parse vlan tag from vlan header.
- * Returns ERROR on memory error.
- * Returns 0 if it encounters a non-vlan or incomplete packet.
- * Returns 1 after successfully parsing vlan tag.
+ * Returns ERROR on memory error, 0 otherwise.
  */
 static int parse_vlan_tag(struct sk_buff *skb, struct vlan_head *key_vh)
 {
@@ -331,34 +329,24 @@ static int parse_vlan_tag(struct sk_buff *skb, struct 
vlan_head *key_vh)
key_vh->tpid = vh->tpid;
 
__skb_pull(skb, sizeof(struct vlan_head));
-   return 1;
+   return 0;
 }
 
 static int parse_vlan(struct sk_buff *skb, struct sw_flow_key *key)
 {
-   int res;
-
key->eth.vlan.tci = 0;
key->eth.vlan.tpid = 0;
key->eth.cvlan.tci = 0;
key->eth.cvlan.tpid = 0;
 
-   if (likely(skb_vlan_tag_present(skb))) {
-   key->eth.vlan.tci = htons(skb->vlan_tci);
-   key->eth.vlan.tpid = skb->vlan_proto;
-   } else {
-   /* Parse outer vlan tag in the non-accelerated case. */
-   res = parse_vlan_tag(skb, >eth.vlan);
-   if (res <= 0)
-   return res;
-   }
+   if (!skb_vlan_tag_present(skb))
+   return 0;
 
-   /* Parse inner vlan tag. */
-   res = parse_vlan_tag(skb, >eth.cvlan);
-   if (res <= 0)
-   return res;
+   key->eth.vlan.tci = htons(skb->vlan_tci);
+   key->eth.vlan.tpid = skb->vlan_proto;
 
-   return 0;
+   /* Parse inner vlan tag. */
+   return parse_vlan_tag(skb, >eth.cvlan);
 }
 
 static __be16 parse_ethertype(struct sk_buff *skb)
-- 
1.8.3.1

Re: [PATCH v6 net-next] net: phy: Add Edge-rate driver for Microsemi PHYs.

[Raju Lakkaraju]

Hi Andrew,

Thank you for review comment.
In another thread, I wrote my comment as below.

-
> In edge_table, remove the -'s and call edge_rate_magic_get with 
> positive values. The table is also missing "static const".
> edge_rate_magic_get is missing its prefix, so keeping the name space 
> clean.
> 

I will add "static const" to table and also add prefix vsc85xx_ to 
edge_rate_magic_get function.

Regarding remove the -'s in table, PHY data sheet descript the concept of edge 
rate with table. I would like to keep the same table in driver.

> Since you are using real values, you can remove mscc-phy-vsc8531.h.
-

But I did not see your comment. I though you accepted to keep the table
as in PHY Data sheet. 

Is any thing wrong if i keep in table with '-' (minus) values?

Thanks,
Raju.

On Tue, Oct 04, 2016 at 01:51:32PM +0200, Andrew Lunn wrote:
> EXTERNAL EMAIL
> 
> 
> On Tue, Oct 04, 2016 at 05:11:12PM +0530, Raju Lakkaraju wrote:
> > From: Raju Lakkaraju 
> >
> > Edge-rate:
> > As system and networking speeds increase, a signal's output transition,
> > also know as the edge rate or slew rate (V/ns), takes on greater importance
> > because high-speed signals come with a price. That price is an assortment of
> > interference problems like ringing on the line, signal overshoot and
> > undershoot, extended signal settling times, crosstalk noise, transmission
> > line reflections, false signal detection by the receiving device and
> > electromagnetic interference (EMI) -- all of which can negate the potential
> > gains designers are seeking when they try to increase system speeds through
> > the use of higher performance logic devices. The fact is, faster signaling
> > edge rates can cause a higher level of electrical noise or other type of
> > interference that can actually lead to slower line speeds and lower maximum
> > system frequencies. This parameter allow the board designers to change the
> > driving strange, and thereby change the EMI behavioral.
> >
> > Edge-rate parameters (vddmac, edge-slowdown) get from Device Tree.
> >
> > Tested on Beaglebone Black with VSC 8531 PHY.
> >
> > Signed-off-by: Raju Lakkaraju 
> >
> > ---
> > All the review comments updated and resending for review.
> >
> > Change set:
> > v1:
> > - Initial version of Edge-rate driver add by using IOCTL.
> > v2:
> > - Changed edge-rate parameter to Device Tree with magic number.
> > v3:
> > - Added Device Tree documentati0n and edge-rate parameter table.
> >   Added probe function initialize the vsc8531 private data structure.
> > v4:
> > - As per review comment, Device Tree parameters (vddmac, edge-slowdown)
> >   added.
> > v5:
> > - As per review comment, Device Tree Document parameters (vddmac,
> >   edge-slowdown) real numbers added. Table number changed from 5 to 1.
> > v6:
> > - As per review comment, Removed Device Tree header file. Removed MACROs
> >   and add ARRAYSIZE
> 
> But you ignored my request to make the table values positive, and to
> enforce an exact match in the table.
> 
> NACK
> 
> Andrew

Re: [PATCH net-next 2/3] net: ethernet: mediatek: get hw lro capability by the chip id instead of by the dtsi

[Nelson Chang]

Hi John,

do you plan to add more chips to the mtk_is_hwlro_supporte() function ?
=> yes, there will be more chips with hw lro in the future, so i think
using mtk_is_hwlro_supporte() function can have the scalability.

Thanks.


Nelson

-Original Message-
From: John Crispin [mailto:j...@phrozen.org] 
Sent: Tuesday, October 04, 2016 3:19 AM
To: Nelson Chang (張家祥); da...@davemloft.net
Cc: netdev@vger.kernel.org; n...@openwrt.org;
linux-media...@lists.infradead.org; nelsonch...@gmail.com
Subject: Re: [PATCH net-next 2/3] net: ethernet: mediatek: get hw lro
capability by the chip id instead of by the dtsi

Hi Nelson,

comment inline

On 03/10/2016 09:18, Nelson Chang wrote:
> Because hw lro started to be supported from MT7623, the proper way to 
> check if the feature is capable is to judge by the chip id instead of
by the dtsi.
> 
> Signed-off-by: Nelson Chang 
> ---
>  drivers/net/ethernet/mediatek/mtk_eth_soc.c | 12 ++--  
> drivers/net/ethernet/mediatek/mtk_eth_soc.h |  1 +
>  2 files changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
> b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index a3e4ae6..3d16a0c 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -2344,6 +2344,14 @@ static u32 mtk_get_chip_id(struct mtk_eth *eth)
>   return chip_id;
>  }
>  
> +static bool mtk_is_hwlro_supported(struct mtk_eth *eth) {
> + if (eth->chip_id == MT7623_ETH)
> + return true;
> + else
> + return false;
> +}
> +
>  static int mtk_probe(struct platform_device *pdev)  {
>   struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 
> 0); @@ -2383,8 +2391,6 @@ static int mtk_probe(struct platform_device
*pdev)
>   return PTR_ERR(eth->pctl);
>   }
>  
> - eth->hwlro = of_property_read_bool(pdev->dev.of_node,
"mediatek,hwlro");
> -
>   for (i = 0; i < 3; i++) {
>   eth->irq[i] = platform_get_irq(pdev, i);
>   if (eth->irq[i] < 0) {
> @@ -2415,6 +2421,8 @@ static int mtk_probe(struct platform_device
*pdev)
>   return -ENODEV;
>   }
>  
> + eth->hwlro = mtk_is_hwlro_supported(eth);
> +

do you plan to add more chips to the mtk_is_hwlro_supporte() function ?
if not a simple

eth->hwlro = (eth->chip_id == MT7623_ETH);

might be enough

John


>   for_each_child_of_node(pdev->dev.of_node, mac_np) {
>   if (!of_device_is_compatible(mac_np,
>"mediatek,eth-mac"))
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h 
> b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> index a5b422b..58738fd 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> @@ -345,6 +345,7 @@
>  /* ethernet subsystem chip id register */
>  #define ETHSYS_CHIPID0_3 0x0
>  #define ETHSYS_CHIPID4_7 0x4
> +#define MT7623_ETH   (7623)
>  
>  /* ethernet subsystem config register */
>  #define ETHSYS_SYSCFG0   0x14
> 

Re: [PATCH net-next 1/3] net: ethernet: mediatek: get the chip id by ETHDMASYS registers

[John Crispin]

On 04/10/2016 14:12, Nelson Chang wrote:
> Hi John,
> 
> Thanks for your review!
> I will modify that as below. Would you think it is okay?
> 
> static int mtk_get_chip_id(struct mtk_eth *eth, u32 *chip_id)
> {
>   u32 val[2], id[4];
> 
>   regmap_read(eth->ethsys, ETHSYS_CHIPID0_3, [0]);
>   regmap_read(eth->ethsys, ETHSYS_CHIPID4_7, [1]);
> 
>   id[3] = ((val[0] >> 16) & 0xff) - '0';
>   id[2] = ((val[0] >> 24) & 0xff) - '0';
>   id[1] = (val[1] & 0xff) - '0';
>   id[0] = ((val[1] >> 8) & 0xff) - '0';
> 
>   *chip_id = (id[3] * 1000) + (id[2] * 100) +
>  (id[1] * 10) + id[0];
> 
>   if (!(*chip_id)) {
>   dev_err(eth->dev, "failed to get chip id\n");
>   return -ENODEV;
>   }
> 
>   dev_info(eth->dev, "chip id = %d\n", *chip_id);
> 
>   return 0;
> }
> ...
> static int mtk_probe(struct platform_device *pdev)
> {
>   ...
>   err = mtk_get_chip_id(eth, >chip_id);
>   if (err)
>   return err;
>   ...
> }
> 
> 
> Nelson


Hi Nelson,

I think that looks nicer, thanks !

John

> 
> -Original Message-
> From: John Crispin [mailto:j...@phrozen.org] 
> Sent: Tuesday, October 04, 2016 3:17 AM
> To: Nelson Chang (張家祥); da...@davemloft.net
> Cc: n...@openwrt.org; netdev@vger.kernel.org;
> linux-media...@lists.infradead.org; nelsonch...@gmail.com
> Subject: Re: [PATCH net-next 1/3] net: ethernet: mediatek: get the chip
> id by ETHDMASYS registers
> 
> Hi Nelson,
> 
> comments inline
> 
> On 03/10/2016 09:18, Nelson Chang wrote:
>> The driver gets the chip id by ETHSYS_CHIPID0_3/ETHSYS_CHIPID4_7 
>> registers in mtk_probe().
>>
>> Signed-off-by: Nelson Chang 
>> ---
>>  drivers/net/ethernet/mediatek/mtk_eth_soc.c | 27 
>> +++  
>> drivers/net/ethernet/mediatek/mtk_eth_soc.h |  5 +
>>  2 files changed, 32 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
>> b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>> index ad4ab97..a3e4ae6 100644
>> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>> @@ -2323,6 +2323,27 @@ free_netdev:
>>  return err;
>>  }
>>  
>> +static u32 mtk_get_chip_id(struct mtk_eth *eth) {
>> +u32 val[2], id[4];
>> +u32 chip_id;
>> +
>> +regmap_read(eth->ethsys, ETHSYS_CHIPID0_3, [0]);
>> +regmap_read(eth->ethsys, ETHSYS_CHIPID4_7, [1]);
>> +
>> +id[3] = ((val[0] >> 16) & 0xff) - '0';
>> +id[2] = ((val[0] >> 24) & 0xff) - '0';
>> +id[1] = (val[1] & 0xff) - '0';
>> +id[0] = ((val[1] >> 8) & 0xff) - '0';
>> +
>> +chip_id = (id[3] * 1000) + (id[2] * 100) +
>> +  (id[1] * 10) + id[0];
>> +
>> +dev_info(eth->dev, "chip id = %d\n", chip_id);
> 
> the chip id is printed here
> 
>> +return chip_id;
>> +}
>> +
>>  static int mtk_probe(struct platform_device *pdev)  {
>>  struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 
>> 0); @@ -2388,6 +2409,12 @@ static int mtk_probe(struct platform_device
> *pdev)
>>  if (err)
>>  return err;
>>  
>> +eth->chip_id = mtk_get_chip_id(eth);
>> +if (!eth->chip_id) {
>> +dev_err(>dev, "failed to get chip id\n");
>> +return -ENODEV;
>> +}
>> +
> 
> and the error check happens here. maybe you could move the dev_err to
> the above function.
> 
>   John
> 
>>  for_each_child_of_node(pdev->dev.of_node, mac_np) {
>>  if (!of_device_is_compatible(mac_np,
>>   "mediatek,eth-mac"))
>> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h 
>> b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
>> index 3003195..a5b422b 100644
>> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
>> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
>> @@ -342,6 +342,10 @@
>>  #define GPIO_BIAS_CTRL  0xed0
>>  #define GPIO_DRV_SEL10  0xf00
>>  
>> +/* ethernet subsystem chip id register */
>> +#define ETHSYS_CHIPID0_30x0
>> +#define ETHSYS_CHIPID4_70x4
>> +
>>  /* ethernet subsystem config register */
>>  #define ETHSYS_SYSCFG0  0x14
>>  #define SYSCFG0_GE_MASK 0x3
>> @@ -534,6 +538,7 @@ struct mtk_eth {
>>  unsigned long   sysclk;
>>  struct regmap   *ethsys;
>>  struct regmap   *pctl;
>> +u32 chip_id;
>>  boolhwlro;
>>  atomic_tdma_refcnt;
>>  struct mtk_tx_ring  tx_ring;
>>
> 
> 

RE: [PATCH net-next 1/3] net: ethernet: mediatek: get the chip id by ETHDMASYS registers

[Nelson Chang]

Hi John,

Thanks for your review!
I will modify that as below. Would you think it is okay?

static int mtk_get_chip_id(struct mtk_eth *eth, u32 *chip_id)
{
u32 val[2], id[4];

regmap_read(eth->ethsys, ETHSYS_CHIPID0_3, [0]);
regmap_read(eth->ethsys, ETHSYS_CHIPID4_7, [1]);

id[3] = ((val[0] >> 16) & 0xff) - '0';
id[2] = ((val[0] >> 24) & 0xff) - '0';
id[1] = (val[1] & 0xff) - '0';
id[0] = ((val[1] >> 8) & 0xff) - '0';

*chip_id = (id[3] * 1000) + (id[2] * 100) +
   (id[1] * 10) + id[0];

if (!(*chip_id)) {
dev_err(eth->dev, "failed to get chip id\n");
return -ENODEV;
}

dev_info(eth->dev, "chip id = %d\n", *chip_id);

return 0;
}
...
static int mtk_probe(struct platform_device *pdev)
{
...
err = mtk_get_chip_id(eth, >chip_id);
if (err)
return err;
...
}


Nelson

-Original Message-
From: John Crispin [mailto:j...@phrozen.org] 
Sent: Tuesday, October 04, 2016 3:17 AM
To: Nelson Chang (張家祥); da...@davemloft.net
Cc: n...@openwrt.org; netdev@vger.kernel.org;
linux-media...@lists.infradead.org; nelsonch...@gmail.com
Subject: Re: [PATCH net-next 1/3] net: ethernet: mediatek: get the chip
id by ETHDMASYS registers

Hi Nelson,

comments inline

On 03/10/2016 09:18, Nelson Chang wrote:
> The driver gets the chip id by ETHSYS_CHIPID0_3/ETHSYS_CHIPID4_7 
> registers in mtk_probe().
> 
> Signed-off-by: Nelson Chang 
> ---
>  drivers/net/ethernet/mediatek/mtk_eth_soc.c | 27 
> +++  
> drivers/net/ethernet/mediatek/mtk_eth_soc.h |  5 +
>  2 files changed, 32 insertions(+)
> 
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
> b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index ad4ab97..a3e4ae6 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -2323,6 +2323,27 @@ free_netdev:
>   return err;
>  }
>  
> +static u32 mtk_get_chip_id(struct mtk_eth *eth) {
> + u32 val[2], id[4];
> + u32 chip_id;
> +
> + regmap_read(eth->ethsys, ETHSYS_CHIPID0_3, [0]);
> + regmap_read(eth->ethsys, ETHSYS_CHIPID4_7, [1]);
> +
> + id[3] = ((val[0] >> 16) & 0xff) - '0';
> + id[2] = ((val[0] >> 24) & 0xff) - '0';
> + id[1] = (val[1] & 0xff) - '0';
> + id[0] = ((val[1] >> 8) & 0xff) - '0';
> +
> + chip_id = (id[3] * 1000) + (id[2] * 100) +
> +   (id[1] * 10) + id[0];
> +
> + dev_info(eth->dev, "chip id = %d\n", chip_id);

the chip id is printed here

> + return chip_id;
> +}
> +
>  static int mtk_probe(struct platform_device *pdev)  {
>   struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 
> 0); @@ -2388,6 +2409,12 @@ static int mtk_probe(struct platform_device
*pdev)
>   if (err)
>   return err;
>  
> + eth->chip_id = mtk_get_chip_id(eth);
> + if (!eth->chip_id) {
> + dev_err(>dev, "failed to get chip id\n");
> + return -ENODEV;
> + }
> +

and the error check happens here. maybe you could move the dev_err to
the above function.

John

>   for_each_child_of_node(pdev->dev.of_node, mac_np) {
>   if (!of_device_is_compatible(mac_np,
>"mediatek,eth-mac"))
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h 
> b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> index 3003195..a5b422b 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> @@ -342,6 +342,10 @@
>  #define GPIO_BIAS_CTRL   0xed0
>  #define GPIO_DRV_SEL10   0xf00
>  
> +/* ethernet subsystem chip id register */
> +#define ETHSYS_CHIPID0_3 0x0
> +#define ETHSYS_CHIPID4_7 0x4
> +
>  /* ethernet subsystem config register */
>  #define ETHSYS_SYSCFG0   0x14
>  #define SYSCFG0_GE_MASK  0x3
> @@ -534,6 +538,7 @@ struct mtk_eth {
>   unsigned long   sysclk;
>   struct regmap   *ethsys;
>   struct regmap   *pctl;
> + u32 chip_id;
>   boolhwlro;
>   atomic_tdma_refcnt;
>   struct mtk_tx_ring  tx_ring;
> 

Re: [PATCH net-next 0/7] qed*: Add qedr infrastructure support

[Doug Ledford]

On 10/3/2016 11:24 PM, David Miller wrote:
> From: Yuval Mintz 
> Date: Sat, 1 Oct 2016 21:59:54 +0300
> 
>> In the last couple of weeks we've been sending RFCs for the qedr
>> driver - the RoCE driver for QLogic FastLinQ 4 line of adapters.
>> Latest RFC can be found at [1].
>>
>> At Doug's advice [2], we've decided to split the series into two:
>>  - first part contains the qed backbone that's necessary for all the
>> configurations relating to the qedr driver, as well as the qede
>> infrastructure that is used for communication between the qedr and qede.
>>  - Second part consists of the actual qedr driver and introduces almost
>> no changes to qed/qede.
>>
>> This is the first of said two parts. The second half would be sent
>> later this week.
>>
>> The only 'oddity' in the devision are the Kconfig options - 
>> As this series introduces both LL2 and QEDR-based logic in qed/qede,
>> I wanted to add the CONFIG_INFINIBAND_QEDR option here [with default n].
>> Otherwise, a lot of the code introduced would be dead-code [won't even
>> be compiled] until qedr is accepted.
>> As a result I've placed the config option in an odd place - under
>> qlogic's Kconfig. The second series would then remove that option
>> and add it in its correct place under the infiniband Kconfig.
>> [I'm fine with pushing it there to begin with, but I didn't want to
>> 'contaminate' non-qlogic configuration files with half-baked options].
>>
>> Dave - I don't think you were E-mailed with Doug's suggestion.
>> I think the notion was to have the two halves accepted side-by-side,
>> but actually the first has no dependency issues, so it's also
>> possible to simply take this first to net-next, and push the qedr
>> into rdma once it's merged. But it's basically up to you and Doug;
>> We'd align with whatever suits you best.
> 
> I'll take this, series applied, thanks.
> 

Are you going to merge this in 4.9 or is this going into net-next?

-- 
Doug Ledford 
GPG Key ID: 0E572FDD



signature.asc
Description: OpenPGP digital signature

[PATCH v6 net-next] net: phy: Add Edge-rate driver for Microsemi PHYs.

[Raju Lakkaraju]

From: Raju Lakkaraju 

Edge-rate:
As system and networking speeds increase, a signal's output transition,
also know as the edge rate or slew rate (V/ns), takes on greater importance
because high-speed signals come with a price. That price is an assortment of
interference problems like ringing on the line, signal overshoot and
undershoot, extended signal settling times, crosstalk noise, transmission
line reflections, false signal detection by the receiving device and
electromagnetic interference (EMI) -- all of which can negate the potential
gains designers are seeking when they try to increase system speeds through
the use of higher performance logic devices. The fact is, faster signaling
edge rates can cause a higher level of electrical noise or other type of
interference that can actually lead to slower line speeds and lower maximum
system frequencies. This parameter allow the board designers to change the
driving strange, and thereby change the EMI behavioral.

Edge-rate parameters (vddmac, edge-slowdown) get from Device Tree.

Tested on Beaglebone Black with VSC 8531 PHY.

Signed-off-by: Raju Lakkaraju 

---
All the review comments updated and resending for review.

Change set:
v1:
- Initial version of Edge-rate driver add by using IOCTL.
v2:
- Changed edge-rate parameter to Device Tree with magic number.
v3:
- Added Device Tree documentati0n and edge-rate parameter table.
  Added probe function initialize the vsc8531 private data structure.
v4:
- As per review comment, Device Tree parameters (vddmac, edge-slowdown)
  added.
v5:
- As per review comment, Device Tree Document parameters (vddmac, 
  edge-slowdown) real numbers added. Table number changed from 5 to 1.
v6:
- As per review comment, Removed Device Tree header file. Removed MACROs
  and add ARRAYSIZE 

---

 .../devicetree/bindings/net/mscc-phy-vsc8531.txt   |  3 ++-
 drivers/net/phy/mscc.c | 29 --
 include/dt-bindings/net/mscc-phy-vsc8531.h | 21 
 3 files changed, 18 insertions(+), 35 deletions(-)
 delete mode 100644 include/dt-bindings/net/mscc-phy-vsc8531.h

diff --git a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt 
b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
index 99c7eb0..241841c 100644
--- a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
+++ b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
@@ -18,7 +18,8 @@ Optional properties:
  to reprogram drive strength and in effect slow
  down the edge rate if desired.  Table 1 shows the
  impact to the edge rate per VDDMAC supply for each
- drive strength setting.
+ drive strength setting. VDDMAC supply voltage
+ should be one of the value in Table-1 first row.
  Ref: Table:1 - Edge rate change below.
 
 Note: see dt-bindings/net/mscc-phy-vsc8531.h for applicable values
diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
index a17573e..e25786e 100644
--- a/drivers/net/phy/mscc.c
+++ b/drivers/net/phy/mscc.c
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 
 enum rgmii_rx_clock_delay {
RGMII_RX_CLK_DELAY_0_2_NS = 0,
@@ -56,12 +55,14 @@ enum rgmii_rx_clock_delay {
 #define PHY_ID_VSC8531   0x00070570
 #define PHY_ID_VSC8541   0x00070770
 
+#define MSCC_SLOWDOWN_MAX8
+
 struct edge_rate_table {
u16 vddmac;
int slowdown[MSCC_SLOWDOWN_MAX];
 };
 
-struct edge_rate_table edge_table[MSCC_VDDMAC_MAX] = {
+static const struct edge_rate_table edge_table[] = {
{3300, { 0, -2, -4,  -7,  -10, -17, -29, -53} },
{2500, { 0, -3, -6,  -10, -14, -23, -37, -63} },
{1800, { 0, -5, -9,  -16, -23, -35, -52, -76} },
@@ -81,18 +82,21 @@ static int vsc85xx_phy_page_set(struct phy_device *phydev, 
u8 page)
return rc;
 }
 
-static u8 edge_rate_magic_get(u16 vddmac,
- int slowdown)
+static u8 vsc85xx_edge_rate_magic_get(u16 vddmac,
+ int slowdown)
 {
-   int rc = (MSCC_SLOWDOWN_MAX - 1);
+   int rc = (ARRAY_SIZE(edge_table[0].slowdown) - 1);
u8 vdd;
u8 sd;
 
-   for (vdd = 0; vdd < MSCC_VDDMAC_MAX; vdd++) {
+   for (vdd = 0; vdd < ARRAY_SIZE(edge_table); vdd++) {
if (edge_table[vdd].vddmac == vddmac) {
-   for (sd = 0; sd < MSCC_SLOWDOWN_MAX; sd++) {
+   for (sd = 0;
+sd < ARRAY_SIZE(edge_table[0].slowdown);
+sd++) {
if (edge_table[vdd].slowdown[sd] <= slowdown) {
-   rc = (MSCC_SLOWDOWN_MAX - sd - 1);
+   rc = 

Re: [PATCH v6 net-next] net: phy: Add Edge-rate driver for Microsemi PHYs.

[Andrew Lunn]

On Tue, Oct 04, 2016 at 05:11:12PM +0530, Raju Lakkaraju wrote:
> From: Raju Lakkaraju 
> 
> Edge-rate:
> As system and networking speeds increase, a signal's output transition,
> also know as the edge rate or slew rate (V/ns), takes on greater importance
> because high-speed signals come with a price. That price is an assortment of
> interference problems like ringing on the line, signal overshoot and
> undershoot, extended signal settling times, crosstalk noise, transmission
> line reflections, false signal detection by the receiving device and
> electromagnetic interference (EMI) -- all of which can negate the potential
> gains designers are seeking when they try to increase system speeds through
> the use of higher performance logic devices. The fact is, faster signaling
> edge rates can cause a higher level of electrical noise or other type of
> interference that can actually lead to slower line speeds and lower maximum
> system frequencies. This parameter allow the board designers to change the
> driving strange, and thereby change the EMI behavioral.
> 
> Edge-rate parameters (vddmac, edge-slowdown) get from Device Tree.
> 
> Tested on Beaglebone Black with VSC 8531 PHY.
> 
> Signed-off-by: Raju Lakkaraju 
> 
> ---
> All the review comments updated and resending for review.
> 
> Change set:
> v1:
> - Initial version of Edge-rate driver add by using IOCTL.
> v2:
> - Changed edge-rate parameter to Device Tree with magic number.
> v3:
> - Added Device Tree documentati0n and edge-rate parameter table.
>   Added probe function initialize the vsc8531 private data structure.
> v4:
> - As per review comment, Device Tree parameters (vddmac, edge-slowdown)
>   added.
> v5:
> - As per review comment, Device Tree Document parameters (vddmac, 
>   edge-slowdown) real numbers added. Table number changed from 5 to 1.
> v6:
> - As per review comment, Removed Device Tree header file. Removed MACROs
>   and add ARRAYSIZE 

But you ignored my request to make the table values positive, and to
enforce an exact match in the table.

NACK

Andrew

[PATCH] i40e: Add missing \n to end of dev_err message

[Colin King]

From: Colin Ian King 

Trival fix, dev_err message is missing a \n, so add it.

Signed-off-by: Colin Ian King 
---
 drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c 
b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index 54b8ee2..64e54a5 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -2940,7 +2940,7 @@ int i40e_ndo_set_vf_bw(struct net_device *netdev, int 
vf_id, int min_tx_rate,
}
 
if (max_tx_rate > speed) {
-   dev_err(>pdev->dev, "Invalid max tx rate %d specified for 
VF %d.",
+   dev_err(>pdev->dev, "Invalid max tx rate %d specified for 
VF %d.\n",
max_tx_rate, vf->vf_id);
ret = -EINVAL;
goto error;
-- 
2.9.3

[PATCH] net: ps3_gelic: Add missing \n to end of deb_dbg message

[Colin King]

From: Colin Ian King 

Trival fix, dev_dbg message is missing a \n, so add it.

Signed-off-by: Colin Ian King 
---
 drivers/net/ethernet/toshiba/ps3_gelic_net.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.c 
b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
index bc258d7..272f2b1 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_net.c
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
@@ -1769,7 +1769,7 @@ static int ps3_gelic_driver_probe(struct 
ps3_system_bus_device *dev)
gelic_ether_setup_netdev_ops(netdev, >napi);
result = gelic_net_setup_netdev(netdev, card);
if (result) {
-   dev_dbg(>core, "%s: setup_netdev failed %d",
+   dev_dbg(>core, "%s: setup_netdev failed %d\n",
__func__, result);
goto fail_setup_netdev;
}
-- 
2.9.3

[PATCH] net: axienet: Add missing \n to end of dev_err messages

[Colin King]

From: Colin Ian King 

Trival fix, dev_err messages are missing a \n, so add it.

Signed-off-by: Colin Ian King 
---
 drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c 
b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 69e2a83..35f9f97 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -818,7 +818,7 @@ static irqreturn_t axienet_tx_irq(int irq, void *_ndev)
goto out;
}
if (!(status & XAXIDMA_IRQ_ALL_MASK))
-   dev_err(>dev, "No interrupts asserted in Tx path");
+   dev_err(>dev, "No interrupts asserted in Tx path\n");
if (status & XAXIDMA_IRQ_ERROR_MASK) {
dev_err(>dev, "DMA Tx error 0x%x\n", status);
dev_err(>dev, "Current BD is at: 0x%x\n",
@@ -867,7 +867,7 @@ static irqreturn_t axienet_rx_irq(int irq, void *_ndev)
goto out;
}
if (!(status & XAXIDMA_IRQ_ALL_MASK))
-   dev_err(>dev, "No interrupts asserted in Rx path");
+   dev_err(>dev, "No interrupts asserted in Rx path\n");
if (status & XAXIDMA_IRQ_ERROR_MASK) {
dev_err(>dev, "DMA Rx error 0x%x\n", status);
dev_err(>dev, "Current BD is at: 0x%x\n",
-- 
2.9.3

Re: [PATCH v2] phy: micrel.c: Enable ksz9031 energy-detect power-down mode

[Florian Fainelli]

On 10/03/2016 10:52 PM, Mike Looijmans wrote:
> Set bit 0 in register 1C.23 to enable the EDPD feature of the
> KSZ9031 PHY. This reduces power consumption when the link is
> down.
> 
> Signed-off-by: Mike Looijmans 

Reviewed-by: Florian Fainelli 

[PATCH] net: hns: qdd missing \n to end of dev_err messages

[Colin King]

From: Colin Ian King 

Trival fix, dev_err messages are missing a \n, so add it.

Signed-off-by: Colin Ian King 
---
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
index a834774..7aeed08 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
@@ -547,7 +547,7 @@ int hns_mac_set_autoneg(struct hns_mac_cb *mac_cb, u8 
enable)
struct mac_driver *mac_ctrl_drv = hns_mac_get_drv(mac_cb);
 
if (mac_cb->phy_if == PHY_INTERFACE_MODE_XGMII && enable) {
-   dev_err(mac_cb->dev, "enable autoneg is not allowed!");
+   dev_err(mac_cb->dev, "enable autoneg is not allowed!\n");
return -ENOTSUPP;
}
 
@@ -571,7 +571,7 @@ int hns_mac_set_pauseparam(struct hns_mac_cb *mac_cb, u32 
rx_en, u32 tx_en)
 
if (mac_cb->mac_type == HNAE_PORT_DEBUG) {
if (is_ver1 && (tx_en || rx_en)) {
-   dev_err(mac_cb->dev, "macv1 cann't enable 
tx/rx_pause!");
+   dev_err(mac_cb->dev, "macv1 cann't enable 
tx/rx_pause!\n");
return -EINVAL;
}
}
-- 
2.9.3

Re: [Xen-devel] [PATCH v2 net-next 7/7] xen/netback: add fraglist support for to-guest rx

[David Vrabel]

On 04/10/16 10:29, Paul Durrant wrote:
> From: Ross Lagerwall 
> 
> This allows full 64K skbuffs (with 1500 mtu ethernet, composed of 45
> fragments) to be handled by netback for to-guest rx.

Reviewed-by: David Vrabel 

David

[PATCH iproute2] fix netlink message length checks

[Igor Ryzhov]

Signed-off-by: Igor Ryzhov 
---
 ip/ipaddress.c | 2 +-
 lib/ll_map.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index fcc3c53..3614837 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -1218,7 +1218,7 @@ static int print_selected_addrinfo(struct ifinfomsg *ifi,
if (n->nlmsg_type != RTM_NEWADDR)
continue;
 
-   if (n->nlmsg_len < NLMSG_LENGTH(sizeof(ifa)))
+   if (n->nlmsg_len < NLMSG_LENGTH(sizeof(*ifa)))
return -1;
 
if (ifa->ifa_index != ifi->ifi_index ||
diff --git a/lib/ll_map.c b/lib/ll_map.c
index 571d11e..4e4556c 100644
--- a/lib/ll_map.c
+++ b/lib/ll_map.c
@@ -90,7 +90,7 @@ int ll_remember_index(const struct sockaddr_nl *who,
if (n->nlmsg_type != RTM_NEWLINK && n->nlmsg_type != RTM_DELLINK)
return 0;
 
-   if (n->nlmsg_len < NLMSG_LENGTH(sizeof(ifi)))
+   if (n->nlmsg_len < NLMSG_LENGTH(sizeof(*ifi)))
return -1;
 
im = ll_get_by_index(ifi->ifi_index);
-- 
2.6.4

Re: [Xen-devel] [PATCH v2 net-next 2/7] xen-netback: retire guest rx side prefix GSO feature

[David Vrabel]

On 04/10/16 10:29, Paul Durrant wrote:
> As far as I am aware only very old Windows network frontends make use of
> this style of passing GSO packets from backend to frontend. These
> frontends can easily be replaced by the freely available Xen Project
> Windows PV network frontend, which uses the 'default' mechanism for
> passing GSO packets, which is also used by all Linux frontends.
> 
> NOTE: Removal of this feature will not cause breakage in old Windows
>   frontends. They simply will no longer receive GSO packets - the
>   packets instead being fragmented in the backend.

Reviewed-by: David Vrabel 

David

Re: [PATCH v5 net-next] net: phy: Add Edge-rate driver for Microsemi PHYs.

[Raju Lakkaraju]

Hi Andrew,

Thank you for comments. I will fix and send the patch.

Thanks,
Raju.

On Tue, Oct 04, 2016 at 08:54:01AM +0200, Andrew Lunn wrote:
> EXTERNAL EMAIL
> 
> 
> On Tue, Oct 04, 2016 at 12:48:59AM -0400, David Miller wrote:
> > From: Raju Lakkaraju 
> > Date: Mon, 3 Oct 2016 12:53:13 +0530
> >
> > > From: Raju Lakkaraju 
> > >
> > > Edge-rate:
> > > As system and networking speeds increase, a signal's output transition,
> > > also know as the edge rate or slew rate (V/ns), takes on greater 
> > > importance
> > > because high-speed signals come with a price. That price is an assortment 
> > > of
> > > interference problems like ringing on the line, signal overshoot and
> > > undershoot, extended signal settling times, crosstalk noise, transmission
> > > line reflections, false signal detection by the receiving device and
> > > electromagnetic interference (EMI) -- all of which can negate the 
> > > potential
> > > gains designers are seeking when they try to increase system speeds 
> > > through
> > > the use of higher performance logic devices. The fact is, faster signaling
> > > edge rates can cause a higher level of electrical noise or other type of
> > > interference that can actually lead to slower line speeds and lower 
> > > maximum
> > > system frequencies. This parameter allow the board designers to change the
> > > driving strange, and thereby change the EMI behavioral.
> > >
> > > Edge-rate parameters (vddmac, edge-slowdown) get from Device Tree.
> > >
> > > Tested on Beaglebone Black with VSC 8531 PHY.
> > >
> > > Signed-off-by: Raju Lakkaraju 
> >
> > Applied, thanks.
> 
> Oh dear. It was not ready for acceptance yet. I guess you missed all
> the discussion because it was attached to the previous version of the
> patch.
> 
> Raju you now need to submit fixup patches relative to the version
> David has accepted, to fix the issues we were discussing.
> 

Accepted.

>   Andrew
> 

[PATCH v2 net-next 5/7] xen-netback: process guest rx packets in batches

[Paul Durrant]

From: David Vrabel 

Instead of only placing one skb on the guest rx ring at a time, process
a batch of up-to 64.  This improves performance by ~10% in some tests.

Signed-off-by: David Vrabel 
[re-based]
Signed-off-by: Paul Durrant 
---
Cc: Wei Liu 
---
 drivers/net/xen-netback/rx.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/net/xen-netback/rx.c b/drivers/net/xen-netback/rx.c
index 9548709..ae822b8 100644
--- a/drivers/net/xen-netback/rx.c
+++ b/drivers/net/xen-netback/rx.c
@@ -399,7 +399,7 @@ static void xenvif_rx_extra_slot(struct xenvif_queue *queue,
BUG();
 }
 
-void xenvif_rx_action(struct xenvif_queue *queue)
+void xenvif_rx_skb(struct xenvif_queue *queue)
 {
struct xenvif_pkt_state pkt;
 
@@ -425,6 +425,19 @@ void xenvif_rx_action(struct xenvif_queue *queue)
xenvif_rx_complete(queue, );
 }
 
+#define RX_BATCH_SIZE 64
+
+void xenvif_rx_action(struct xenvif_queue *queue)
+{
+   unsigned int work_done = 0;
+
+   while (xenvif_rx_ring_slots_available(queue) &&
+  work_done < RX_BATCH_SIZE) {
+   xenvif_rx_skb(queue);
+   work_done++;
+   }
+}
+
 static bool xenvif_rx_queue_stalled(struct xenvif_queue *queue)
 {
RING_IDX prod, cons;
-- 
2.1.4

[PATCH v2 net-next 0/7] xen-netback: guest rx side refactor

[Paul Durrant]

This series refactors the guest rx side of xen-netback:

- The code is moved into its own source module.

- The prefix variant of GSO handling is retired (since it is no longer
  in common use, and alternatives exist).

- The code is then simplified and modifications made to improve
  performance.

v2:
- Rebased onto refreshed net-next

David Vrabel (4):
  xen-netback: refactor guest rx
  xen-netback: immediately wake tx queue when guest rx queue has space
  xen-netback: process guest rx packets in batches
  xen-netback: batch copies for multiple to-guest rx packets

Paul Durrant (2):
  xen-netback: separate guest side rx code into separate module
  xen-netback: retire guest rx side prefix GSO feature

Ross Lagerwall (1):
  xen/netback: add fraglist support for to-guest rx

 drivers/net/xen-netback/Makefile|   2 +-
 drivers/net/xen-netback/common.h|  25 +-
 drivers/net/xen-netback/interface.c |   6 +-
 drivers/net/xen-netback/netback.c   | 754 
 drivers/net/xen-netback/rx.c| 628 ++
 drivers/net/xen-netback/xenbus.c|  21 -
 6 files changed, 643 insertions(+), 793 deletions(-)
 create mode 100644 drivers/net/xen-netback/rx.c

-- 
2.1.4

[PATCH v2 net-next 7/7] xen/netback: add fraglist support for to-guest rx

[Paul Durrant]

From: Ross Lagerwall 

This allows full 64K skbuffs (with 1500 mtu ethernet, composed of 45
fragments) to be handled by netback for to-guest rx.

Signed-off-by: Ross Lagerwall 
[re-based]
Signed-off-by: Paul Durrant 
---
Cc: Wei Liu 
---
 drivers/net/xen-netback/interface.c |  2 +-
 drivers/net/xen-netback/rx.c| 38 -
 2 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index 211d542..4af532a 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -467,7 +467,7 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t 
domid,
dev->netdev_ops = _netdev_ops;
dev->hw_features = NETIF_F_SG |
NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
-   NETIF_F_TSO | NETIF_F_TSO6;
+   NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_FRAGLIST;
dev->features = dev->hw_features | NETIF_F_RXCSUM;
dev->ethtool_ops = _ethtool_ops;
 
diff --git a/drivers/net/xen-netback/rx.c b/drivers/net/xen-netback/rx.c
index 8c8c5b5..8e9ade6 100644
--- a/drivers/net/xen-netback/rx.c
+++ b/drivers/net/xen-netback/rx.c
@@ -215,7 +215,8 @@ static unsigned int xenvif_gso_type(struct sk_buff *skb)
 struct xenvif_pkt_state {
struct sk_buff *skb;
size_t remaining_len;
-   int frag; /* frag == -1 => skb->head */
+   struct sk_buff *frag_iter;
+   int frag; /* frag == -1 => frag_iter->head */
unsigned int frag_offset;
struct xen_netif_extra_info extras[XEN_NETIF_EXTRA_TYPE_MAX - 1];
unsigned int extra_count;
@@ -237,6 +238,7 @@ static void xenvif_rx_next_skb(struct xenvif_queue *queue,
memset(pkt, 0, sizeof(struct xenvif_pkt_state));
 
pkt->skb = skb;
+   pkt->frag_iter = skb;
pkt->remaining_len = skb->len;
pkt->frag = -1;
 
@@ -293,20 +295,40 @@ static void xenvif_rx_complete(struct xenvif_queue *queue,
__skb_queue_tail(queue->rx_copy.completed, pkt->skb);
 }
 
+static void xenvif_rx_next_frag(struct xenvif_pkt_state *pkt)
+{
+   struct sk_buff *frag_iter = pkt->frag_iter;
+   unsigned int nr_frags = skb_shinfo(frag_iter)->nr_frags;
+
+   pkt->frag++;
+   pkt->frag_offset = 0;
+
+   if (pkt->frag >= nr_frags) {
+   if (frag_iter == pkt->skb)
+   pkt->frag_iter = skb_shinfo(frag_iter)->frag_list;
+   else
+   pkt->frag_iter = frag_iter->next;
+
+   pkt->frag = -1;
+   }
+}
+
 static void xenvif_rx_next_chunk(struct xenvif_queue *queue,
 struct xenvif_pkt_state *pkt,
 unsigned int offset, void **data,
 size_t *len)
 {
-   struct sk_buff *skb = pkt->skb;
+   struct sk_buff *frag_iter = pkt->frag_iter;
void *frag_data;
size_t frag_len, chunk_len;
 
+   BUG_ON(!frag_iter);
+
if (pkt->frag == -1) {
-   frag_data = skb->data;
-   frag_len = skb_headlen(skb);
+   frag_data = frag_iter->data;
+   frag_len = skb_headlen(frag_iter);
} else {
-   skb_frag_t *frag = _shinfo(skb)->frags[pkt->frag];
+   skb_frag_t *frag = _shinfo(frag_iter)->frags[pkt->frag];
 
frag_data = skb_frag_address(frag);
frag_len = skb_frag_size(frag);
@@ -322,10 +344,8 @@ static void xenvif_rx_next_chunk(struct xenvif_queue 
*queue,
pkt->frag_offset += chunk_len;
 
/* Advance to next frag? */
-   if (frag_len == chunk_len) {
-   pkt->frag++;
-   pkt->frag_offset = 0;
-   }
+   if (frag_len == chunk_len)
+   xenvif_rx_next_frag(pkt);
 
*data = frag_data;
*len = chunk_len;
-- 
2.1.4

[PATCH v2 net-next 6/7] xen-netback: batch copies for multiple to-guest rx packets

[Paul Durrant]

From: David Vrabel 

Instead of flushing the copy ops when an packet is complete, complete
packets when their copy ops are done.  This improves performance by
reducing the number of grant copy hypercalls.

Latency is still limited by the relatively small size of the copy
batch.

Signed-off-by: David Vrabel 
[re-based]
Signed-off-by: Paul Durrant 
---
Cc: Wei Liu 
---
 drivers/net/xen-netback/common.h |  1 +
 drivers/net/xen-netback/rx.c | 27 +--
 2 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 7d12a38..cf68149 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -132,6 +132,7 @@ struct xenvif_copy_state {
struct gnttab_copy op[COPY_BATCH_SIZE];
RING_IDX idx[COPY_BATCH_SIZE];
unsigned int num;
+   struct sk_buff_head *completed;
 };
 
 struct xenvif_queue { /* Per-queue data for xenvif */
diff --git a/drivers/net/xen-netback/rx.c b/drivers/net/xen-netback/rx.c
index ae822b8..8c8c5b5 100644
--- a/drivers/net/xen-netback/rx.c
+++ b/drivers/net/xen-netback/rx.c
@@ -133,6 +133,7 @@ static void xenvif_rx_queue_drop_expired(struct 
xenvif_queue *queue)
 static void xenvif_rx_copy_flush(struct xenvif_queue *queue)
 {
unsigned int i;
+   int notify;
 
gnttab_batch_copy(queue->rx_copy.op, queue->rx_copy.num);
 
@@ -154,6 +155,13 @@ static void xenvif_rx_copy_flush(struct xenvif_queue 
*queue)
}
 
queue->rx_copy.num = 0;
+
+   /* Push responses for all completed packets. */
+   RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(>rx, notify);
+   if (notify)
+   notify_remote_via_irq(queue->rx_irq);
+
+   __skb_queue_purge(queue->rx_copy.completed);
 }
 
 static void xenvif_rx_copy_add(struct xenvif_queue *queue,
@@ -279,18 +287,10 @@ static void xenvif_rx_next_skb(struct xenvif_queue *queue,
 static void xenvif_rx_complete(struct xenvif_queue *queue,
   struct xenvif_pkt_state *pkt)
 {
-   int notify;
-
-   /* Complete any outstanding copy ops for this skb. */
-   xenvif_rx_copy_flush(queue);
-
-   /* Push responses and notify. */
+   /* All responses are ready to be pushed. */
queue->rx.rsp_prod_pvt = queue->rx.req_cons;
-   RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(>rx, notify);
-   if (notify)
-   notify_remote_via_irq(queue->rx_irq);
 
-   dev_kfree_skb(pkt->skb);
+   __skb_queue_tail(queue->rx_copy.completed, pkt->skb);
 }
 
 static void xenvif_rx_next_chunk(struct xenvif_queue *queue,
@@ -429,13 +429,20 @@ void xenvif_rx_skb(struct xenvif_queue *queue)
 
 void xenvif_rx_action(struct xenvif_queue *queue)
 {
+   struct sk_buff_head completed_skbs;
unsigned int work_done = 0;
 
+   __skb_queue_head_init(_skbs);
+   queue->rx_copy.completed = _skbs;
+
while (xenvif_rx_ring_slots_available(queue) &&
   work_done < RX_BATCH_SIZE) {
xenvif_rx_skb(queue);
work_done++;
}
+
+   /* Flush any pending copies and complete all skbs. */
+   xenvif_rx_copy_flush(queue);
 }
 
 static bool xenvif_rx_queue_stalled(struct xenvif_queue *queue)
-- 
2.1.4

[PATCH v2 net-next 3/7] xen-netback: refactor guest rx

[Paul Durrant]

From: David Vrabel 

Refactor the to-guest (rx) path to:

1. Push responses for completed skbs earlier, reducing latency.

2. Reduce the per-queue memory overhead by greatly reducing the
   maximum number of grant copy ops in each hypercall (from 4352 to
   64).  Each struct xenvif_queue is now only 44 kB instead of 220 kB.

3. Make the code more maintainable.

Signed-off-by: David Vrabel 
[re-based]
Signed-off-by: Paul Durrant 
---
Cc: Wei Liu 
---
 drivers/net/xen-netback/common.h |  23 +-
 drivers/net/xen-netback/rx.c | 654 +++
 2 files changed, 254 insertions(+), 423 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 0ba5910..7d12a38 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -91,13 +91,6 @@ struct xenvif_rx_meta {
  */
 #define MAX_XEN_SKB_FRAGS (65536 / XEN_PAGE_SIZE + 1)
 
-/* It's possible for an skb to have a maximal number of frags
- * but still be less than MAX_BUFFER_OFFSET in size. Thus the
- * worst-case number of copy operations is MAX_XEN_SKB_FRAGS per
- * ring slot.
- */
-#define MAX_GRANT_COPY_OPS (MAX_XEN_SKB_FRAGS * XEN_NETIF_RX_RING_SIZE)
-
 #define NETBACK_INVALID_HANDLE -1
 
 /* To avoid confusion, we define XEN_NETBK_LEGACY_SLOTS_MAX indicating
@@ -133,6 +126,14 @@ struct xenvif_stats {
unsigned long tx_frag_overflow;
 };
 
+#define COPY_BATCH_SIZE 64
+
+struct xenvif_copy_state {
+   struct gnttab_copy op[COPY_BATCH_SIZE];
+   RING_IDX idx[COPY_BATCH_SIZE];
+   unsigned int num;
+};
+
 struct xenvif_queue { /* Per-queue data for xenvif */
unsigned int id; /* Queue ID, 0-based */
char name[QUEUE_NAME_SIZE]; /* DEVNAME-qN */
@@ -189,12 +190,7 @@ struct xenvif_queue { /* Per-queue data for xenvif */
unsigned long last_rx_time;
bool stalled;
 
-   struct gnttab_copy grant_copy_op[MAX_GRANT_COPY_OPS];
-
-   /* We create one meta structure per ring request we consume, so
-* the maximum number is the same as the ring size.
-*/
-   struct xenvif_rx_meta meta[XEN_NETIF_RX_RING_SIZE];
+   struct xenvif_copy_state rx_copy;
 
/* Transmit shaping: allow 'credit_bytes' every 'credit_usec'. */
unsigned long   credit_bytes;
@@ -358,6 +354,7 @@ int xenvif_dealloc_kthread(void *data);
 
 irqreturn_t xenvif_ctrl_irq_fn(int irq, void *data);
 
+void xenvif_rx_action(struct xenvif_queue *queue);
 void xenvif_rx_queue_tail(struct xenvif_queue *queue, struct sk_buff *skb);
 
 void xenvif_carrier_on(struct xenvif *vif);
diff --git a/drivers/net/xen-netback/rx.c b/drivers/net/xen-netback/rx.c
index 6bd7d6e..b0ce4c6 100644
--- a/drivers/net/xen-netback/rx.c
+++ b/drivers/net/xen-netback/rx.c
@@ -26,7 +26,6 @@
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
  * IN THE SOFTWARE.
  */
-
 #include "common.h"
 
 #include 
@@ -137,464 +136,299 @@ static void xenvif_rx_queue_drop_expired(struct 
xenvif_queue *queue)
}
 }
 
-struct netrx_pending_operations {
-   unsigned int copy_prod, copy_cons;
-   unsigned int meta_prod, meta_cons;
-   struct gnttab_copy *copy;
-   struct xenvif_rx_meta *meta;
-   int copy_off;
-   grant_ref_t copy_gref;
-};
-
-static struct xenvif_rx_meta *get_next_rx_buffer(
-   struct xenvif_queue *queue,
-   struct netrx_pending_operations *npo)
+static void xenvif_rx_copy_flush(struct xenvif_queue *queue)
 {
-   struct xenvif_rx_meta *meta;
-   struct xen_netif_rx_request req;
+   unsigned int i;
 
-   RING_COPY_REQUEST(>rx, queue->rx.req_cons++, );
+   gnttab_batch_copy(queue->rx_copy.op, queue->rx_copy.num);
 
-   meta = npo->meta + npo->meta_prod++;
-   meta->gso_type = XEN_NETIF_GSO_TYPE_NONE;
-   meta->gso_size = 0;
-   meta->size = 0;
-   meta->id = req.id;
+   for (i = 0; i < queue->rx_copy.num; i++) {
+   struct gnttab_copy *op;
 
-   npo->copy_off = 0;
-   npo->copy_gref = req.gref;
+   op = >rx_copy.op[i];
 
-   return meta;
+   /* If the copy failed, overwrite the status field in
+* the corresponding response.
+*/
+   if (unlikely(op->status != GNTST_okay)) {
+   struct xen_netif_rx_response *rsp;
+
+   rsp = RING_GET_RESPONSE(>rx,
+   queue->rx_copy.idx[i]);
+   rsp->status = op->status;
+   }
+   }
+
+   queue->rx_copy.num = 0;
 }
 
-struct gop_frag_copy {
-   struct xenvif_queue *queue;
-   struct netrx_pending_operations *npo;
-   struct xenvif_rx_meta *meta;
-   int head;
-   int gso_type;
-   int protocol;
-   int hash_present;
-
-   struct page *page;
-};
-
-static void 

[PATCH v2 net-next 4/7] xen-netback: immediately wake tx queue when guest rx queue has space

[Paul Durrant]

From: David Vrabel 

When an skb is removed from the guest rx queue, immediately wake the
tx queue, instead of after processing them.

Signed-off-by: David Vrabel 
[re-based]
Signed-off-by: Paul Durrant 
---
Cc: Wei Liu 
---
 drivers/net/xen-netback/rx.c | 24 
 1 file changed, 8 insertions(+), 16 deletions(-)

diff --git a/drivers/net/xen-netback/rx.c b/drivers/net/xen-netback/rx.c
index b0ce4c6..9548709 100644
--- a/drivers/net/xen-netback/rx.c
+++ b/drivers/net/xen-netback/rx.c
@@ -92,27 +92,21 @@ static struct sk_buff *xenvif_rx_dequeue(struct 
xenvif_queue *queue)
spin_lock_irq(>rx_queue.lock);
 
skb = __skb_dequeue(>rx_queue);
-   if (skb)
+   if (skb) {
queue->rx_queue_len -= skb->len;
+   if (queue->rx_queue_len < queue->rx_queue_max) {
+   struct netdev_queue *txq;
+
+   txq = netdev_get_tx_queue(queue->vif->dev, queue->id);
+   netif_tx_wake_queue(txq);
+   }
+   }
 
spin_unlock_irq(>rx_queue.lock);
 
return skb;
 }
 
-static void xenvif_rx_queue_maybe_wake(struct xenvif_queue *queue)
-{
-   spin_lock_irq(>rx_queue.lock);
-
-   if (queue->rx_queue_len < queue->rx_queue_max) {
-   struct net_device *dev = queue->vif->dev;
-
-   netif_tx_wake_queue(netdev_get_tx_queue(dev, queue->id));
-   }
-
-   spin_unlock_irq(>rx_queue.lock);
-}
-
 static void xenvif_rx_queue_purge(struct xenvif_queue *queue)
 {
struct sk_buff *skb;
@@ -585,8 +579,6 @@ int xenvif_kthread_guest_rx(void *data)
 */
xenvif_rx_queue_drop_expired(queue);
 
-   xenvif_rx_queue_maybe_wake(queue);
-
cond_resched();
}
 
-- 
2.1.4

[PATCH v2 net-next 1/7] xen-netback: separate guest side rx code into separate module

[Paul Durrant]

The netback source module has become very large and somewhat confusing.
This patch simply moves all code related to the backend to frontend (i.e
guest side rx) data-path into a separate rx source module.

This patch contains no functional change, it is code movement and
minimal changes to avoid patch style-check issues.

Signed-off-by: Paul Durrant 
---
Cc: Wei Liu 
---
 drivers/net/xen-netback/Makefile  |   2 +-
 drivers/net/xen-netback/netback.c | 754 
 drivers/net/xen-netback/rx.c  | 789 ++
 3 files changed, 790 insertions(+), 755 deletions(-)
 create mode 100644 drivers/net/xen-netback/rx.c

diff --git a/drivers/net/xen-netback/Makefile b/drivers/net/xen-netback/Makefile
index 11e02be..d49798a 100644
--- a/drivers/net/xen-netback/Makefile
+++ b/drivers/net/xen-netback/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_XEN_NETDEV_BACKEND) := xen-netback.o
 
-xen-netback-y := netback.o xenbus.o interface.o hash.o
+xen-netback-y := netback.o xenbus.o interface.o hash.o rx.o
diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index 3d0c989..47b4810 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -106,13 +106,6 @@ static void push_tx_responses(struct xenvif_queue *queue);
 
 static inline int tx_work_todo(struct xenvif_queue *queue);
 
-static struct xen_netif_rx_response *make_rx_response(struct xenvif_queue 
*queue,
-u16  id,
-s8   st,
-u16  offset,
-u16  size,
-u16  flags);
-
 static inline unsigned long idx_to_pfn(struct xenvif_queue *queue,
   u16 idx)
 {
@@ -155,571 +148,11 @@ static inline pending_ring_idx_t pending_index(unsigned 
i)
return i & (MAX_PENDING_REQS-1);
 }
 
-static bool xenvif_rx_ring_slots_available(struct xenvif_queue *queue)
-{
-   RING_IDX prod, cons;
-   struct sk_buff *skb;
-   int needed;
-
-   skb = skb_peek(>rx_queue);
-   if (!skb)
-   return false;
-
-   needed = DIV_ROUND_UP(skb->len, XEN_PAGE_SIZE);
-   if (skb_is_gso(skb))
-   needed++;
-   if (skb->sw_hash)
-   needed++;
-
-   do {
-   prod = queue->rx.sring->req_prod;
-   cons = queue->rx.req_cons;
-
-   if (prod - cons >= needed)
-   return true;
-
-   queue->rx.sring->req_event = prod + 1;
-
-   /* Make sure event is visible before we check prod
-* again.
-*/
-   mb();
-   } while (queue->rx.sring->req_prod != prod);
-
-   return false;
-}
-
-void xenvif_rx_queue_tail(struct xenvif_queue *queue, struct sk_buff *skb)
-{
-   unsigned long flags;
-
-   spin_lock_irqsave(>rx_queue.lock, flags);
-
-   __skb_queue_tail(>rx_queue, skb);
-
-   queue->rx_queue_len += skb->len;
-   if (queue->rx_queue_len > queue->rx_queue_max)
-   netif_tx_stop_queue(netdev_get_tx_queue(queue->vif->dev, 
queue->id));
-
-   spin_unlock_irqrestore(>rx_queue.lock, flags);
-}
-
-static struct sk_buff *xenvif_rx_dequeue(struct xenvif_queue *queue)
-{
-   struct sk_buff *skb;
-
-   spin_lock_irq(>rx_queue.lock);
-
-   skb = __skb_dequeue(>rx_queue);
-   if (skb)
-   queue->rx_queue_len -= skb->len;
-
-   spin_unlock_irq(>rx_queue.lock);
-
-   return skb;
-}
-
-static void xenvif_rx_queue_maybe_wake(struct xenvif_queue *queue)
-{
-   spin_lock_irq(>rx_queue.lock);
-
-   if (queue->rx_queue_len < queue->rx_queue_max)
-   netif_tx_wake_queue(netdev_get_tx_queue(queue->vif->dev, 
queue->id));
-
-   spin_unlock_irq(>rx_queue.lock);
-}
-
-
-static void xenvif_rx_queue_purge(struct xenvif_queue *queue)
-{
-   struct sk_buff *skb;
-   while ((skb = xenvif_rx_dequeue(queue)) != NULL)
-   kfree_skb(skb);
-}
-
-static void xenvif_rx_queue_drop_expired(struct xenvif_queue *queue)
-{
-   struct sk_buff *skb;
-
-   for(;;) {
-   skb = skb_peek(>rx_queue);
-   if (!skb)
-   break;
-   if (time_before(jiffies, XENVIF_RX_CB(skb)->expires))
-   break;
-   xenvif_rx_dequeue(queue);
-   kfree_skb(skb);
-   }
-}
-
-struct netrx_pending_operations {
-   unsigned copy_prod, copy_cons;
-   unsigned meta_prod, meta_cons;
-   struct gnttab_copy *copy;
-   struct xenvif_rx_meta *meta;
-   int copy_off;
-   grant_ref_t copy_gref;
-};
-
-static struct xenvif_rx_meta *get_next_rx_buffer(struct xenvif_queue *queue,
-struct 

[PATCH v2 net-next 2/7] xen-netback: retire guest rx side prefix GSO feature

[Paul Durrant]

As far as I am aware only very old Windows network frontends make use of
this style of passing GSO packets from backend to frontend. These
frontends can easily be replaced by the freely available Xen Project
Windows PV network frontend, which uses the 'default' mechanism for
passing GSO packets, which is also used by all Linux frontends.

NOTE: Removal of this feature will not cause breakage in old Windows
  frontends. They simply will no longer receive GSO packets - the
  packets instead being fragmented in the backend.

Signed-off-by: Paul Durrant 
---
Cc: Wei Liu 
---
 drivers/net/xen-netback/common.h|  1 -
 drivers/net/xen-netback/interface.c |  4 ++--
 drivers/net/xen-netback/rx.c| 26 --
 drivers/net/xen-netback/xenbus.c| 21 -
 4 files changed, 2 insertions(+), 50 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index b38fb2c..0ba5910 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -260,7 +260,6 @@ struct xenvif {
 
/* Frontend feature information. */
int gso_mask;
-   int gso_prefix_mask;
 
u8 can_sg:1;
u8 ip_csum:1;
diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index fb50c6d..211d542 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -319,9 +319,9 @@ static netdev_features_t xenvif_fix_features(struct 
net_device *dev,
 
if (!vif->can_sg)
features &= ~NETIF_F_SG;
-   if (~(vif->gso_mask | vif->gso_prefix_mask) & GSO_BIT(TCPV4))
+   if (~(vif->gso_mask) & GSO_BIT(TCPV4))
features &= ~NETIF_F_TSO;
-   if (~(vif->gso_mask | vif->gso_prefix_mask) & GSO_BIT(TCPV6))
+   if (~(vif->gso_mask) & GSO_BIT(TCPV6))
features &= ~NETIF_F_TSO6;
if (!vif->ip_csum)
features &= ~NETIF_F_IP_CSUM;
diff --git a/drivers/net/xen-netback/rx.c b/drivers/net/xen-netback/rx.c
index 03836aa..6bd7d6e 100644
--- a/drivers/net/xen-netback/rx.c
+++ b/drivers/net/xen-netback/rx.c
@@ -347,16 +347,6 @@ static int xenvif_gop_skb(struct sk_buff *skb,
gso_type = XEN_NETIF_GSO_TYPE_TCPV6;
}
 
-   /* Set up a GSO prefix descriptor, if necessary */
-   if ((1 << gso_type) & vif->gso_prefix_mask) {
-   RING_COPY_REQUEST(>rx, queue->rx.req_cons++, );
-   meta = npo->meta + npo->meta_prod++;
-   meta->gso_type = gso_type;
-   meta->gso_size = skb_shinfo(skb)->gso_size;
-   meta->size = 0;
-   meta->id = req.id;
-   }
-
RING_COPY_REQUEST(>rx, queue->rx.req_cons++, );
meta = npo->meta + npo->meta_prod++;
 
@@ -511,22 +501,6 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
while ((skb = __skb_dequeue()) != NULL) {
struct xen_netif_extra_info *extra = NULL;
 
-   if ((1 << queue->meta[npo.meta_cons].gso_type) &
-   vif->gso_prefix_mask) {
-   resp = RING_GET_RESPONSE(>rx,
-queue->rx.rsp_prod_pvt++);
-
-   resp->flags = XEN_NETRXF_gso_prefix |
- XEN_NETRXF_more_data;
-
-   resp->offset = queue->meta[npo.meta_cons].gso_size;
-   resp->id = queue->meta[npo.meta_cons].id;
-   resp->status = XENVIF_RX_CB(skb)->meta_slots_used;
-
-   npo.meta_cons++;
-   XENVIF_RX_CB(skb)->meta_slots_used--;
-   }
-
queue->stats.tx_bytes += skb->len;
queue->stats.tx_packets++;
 
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index daf4c78..7056404 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -1135,7 +1135,6 @@ static int read_xenbus_vif_flags(struct backend_info *be)
vif->can_sg = !!val;
 
vif->gso_mask = 0;
-   vif->gso_prefix_mask = 0;
 
if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-gso-tcpv4",
 "%d", ) < 0)
@@ -1143,32 +1142,12 @@ static int read_xenbus_vif_flags(struct backend_info 
*be)
if (val)
vif->gso_mask |= GSO_BIT(TCPV4);
 
-   if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-gso-tcpv4-prefix",
-"%d", ) < 0)
-   val = 0;
-   if (val)
-   vif->gso_prefix_mask |= GSO_BIT(TCPV4);
-
if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-gso-tcpv6",
 "%d", ) < 0)
val = 0;
if (val)
vif->gso_mask |= GSO_BIT(TCPV6);
 
-   if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-gso-tcpv6-prefix",
-"%d", ) < 

Re: [PATCH net-next] openvswitch: correctly fragment packet with mpls headers

[Jiri Benc]

On Tue, 4 Oct 2016 10:24:58 +0200, Jiri Benc wrote:
> On Mon, 3 Oct 2016 11:04:46 -0700, Pravin Shelar wrote:
> > This is not correct way to detect MPLS packet. inner_protocol can be
> > set by any tunnel device for using tunnel offloads. So this would
> > break the fragmentation for encapsulated packets.
> 
> You're right, stupid me.

Actually, too little caffeine in the morning. I actually did consider
this and I believe my patch is correct. It doesn't matter what the
encapsulation is, we want to fragment the *inner* packet. And this is
exactly what this patch does.

Besides, the only case is MPLS anyway. I'm not aware of any code path
that could lead us to here, set inner protocol and not be MPLS. But
even if it is, it should work, provided the encapsulation header is
identical for all fragments and smaller than MAX_L2_LEN.

 Jiri

RE: [PATCH net-next 0/7] xen-netback: guest rx side refactor

[Paul Durrant]

> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: 04 October 2016 05:52
> To: Paul Durrant 
> Cc: netdev@vger.kernel.org; xen-de...@lists.xenproject.org
> Subject: Re: [PATCH net-next 0/7] xen-netback: guest rx side refactor
> 
> From: Paul Durrant 
> Date: Mon, 3 Oct 2016 08:31:05 +0100
> 
> > This series refactors the guest rx side of xen-netback:
> >
> > - The code is moved into its own source module.
> >
> > - The prefix variant of GSO handling is retired (since it is no longer
> >   in common use, and alternatives exist).
> >
> > - The code is then simplified and modifications made to improve
> >   performance.
> 
> This doesn't apply cleanly to net-next, please respin.

Sure. V2 coming up.

  Paul

Re: [PATCH net-next] openvswitch: correctly fragment packet with mpls headers

[Jiri Benc]

On Mon, 3 Oct 2016 11:04:46 -0700, Pravin Shelar wrote:
> This is not correct way to detect MPLS packet. inner_protocol can be
> set by any tunnel device for using tunnel offloads. So this would
> break the fragmentation for encapsulated packets.

You're right, stupid me.

> How about using eth_p_mpls() as done in do-output()?

Will look into it.

 Jiri

[net-next 09/13] fsl/fman: check of_get_phy_mode() return value

[Madalin Bucur]

For unknown compatibles avoid crashing and default to SGMII.

Signed-off-by: Madalin Bucur 
---
 drivers/net/ethernet/freescale/fman/mac.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fman/mac.c 
b/drivers/net/ethernet/freescale/fman/mac.c
index e4378c2..8fe6b3e 100644
--- a/drivers/net/ethernet/freescale/fman/mac.c
+++ b/drivers/net/ethernet/freescale/fman/mac.c
@@ -663,6 +663,7 @@ static int mac_probe(struct platform_device *_of_dev)
const u8*mac_addr;
u32  val;
u8  fman_id;
+   int phy_if;
 
dev = &_of_dev->dev;
mac_node = dev->of_node;
@@ -842,13 +843,14 @@ static int mac_probe(struct platform_device *_of_dev)
}
 
/* Get the PHY connection type */
-   priv->phy_if = of_get_phy_mode(mac_node);
-   if (priv->phy_if < 0) {
+   phy_if = of_get_phy_mode(mac_node);
+   if (phy_if < 0) {
dev_warn(dev,
-"of_get_phy_mode() for %s failed. Defaulting to MII\n",
+"of_get_phy_mode() for %s failed. Defaulting to 
SGMII\n",
 mac_node->full_name);
-   priv->phy_if = PHY_INTERFACE_MODE_MII;
+   phy_if = PHY_INTERFACE_MODE_SGMII;
}
+   priv->phy_if = phy_if;
 
priv->speed = phy2speed[priv->phy_if];
priv->max_speed = priv->speed;
-- 
2.1.0

[net-next 07/13] fsl/fman: MEMAC may use QSGMII PHY interface mode

[Madalin Bucur]

Signed-off-by: Madalin Bucur 
---
 drivers/net/ethernet/freescale/fman/fman_memac.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/fman/fman_memac.c 
b/drivers/net/ethernet/freescale/fman/fman_memac.c
index 45e98fd..96dfe7e 100644
--- a/drivers/net/ethernet/freescale/fman/fman_memac.c
+++ b/drivers/net/ethernet/freescale/fman/fman_memac.c
@@ -1151,7 +1151,8 @@ struct fman_mac *memac_config(struct fman_mac_params 
*params)
/* Save FMan revision */
fman_get_revision(memac->fm, >fm_rev_info);
 
-   if (memac->phy_if == PHY_INTERFACE_MODE_SGMII) {
+   if (memac->phy_if == PHY_INTERFACE_MODE_SGMII ||
+   memac->phy_if == PHY_INTERFACE_MODE_QSGMII) {
if (!params->internal_phy_node) {
pr_err("PCS PHY node is not available\n");
memac_free(memac);
-- 
2.1.0

[net-next 00/13] fsl/fman: cleanup and small fixes

[Madalin Bucur]

This series contains fixes for the DPAA FMan driver.
Adding myself as maintainer of the driver.

The following are changes since commit a4cc96d1f0170b779c32c6b2cc58764f5d2cdef0
 net: phy: Add Edge-rate driver for Microsemi PHYs.
and are available on the fman-next branch in the git repository at
 git://git.freescale.com/ppc/upstream/linux.git

Igal Liberman (1):
  fsl/fman: fix loadable module compilation

Madalin Bucur (12):
  fsl/fman: split lines over 80 characters
  fsl/fman: small fixes
  fsl/fman: use of_get_phy_mode()
  fsl/fman: simplify device tree reads
  fsl/fman: return a phy_dev pointer from init
  fsl/fman: MEMAC may use QSGMII PHY interface mode
  fsl/fman: check pcsphy pointer before use
  fsl/fman: check of_get_phy_mode() return value
  fsl/fman: simplify redundant condition
  fsl/fman: fix return value checking
  fsl/fman: remove leftover comment
  MAINTAINERS: net: add entry for Freescale QorIQ DPAA FMan driver

 MAINTAINERS  |  7 ++
 drivers/net/ethernet/freescale/fman/Makefile | 10 +--
 drivers/net/ethernet/freescale/fman/fman.c   | 78 ++
 drivers/net/ethernet/freescale/fman/fman_mac.h   |  4 --
 drivers/net/ethernet/freescale/fman/fman_memac.c |  6 +-
 drivers/net/ethernet/freescale/fman/fman_muram.c |  3 +-
 drivers/net/ethernet/freescale/fman/fman_muram.h |  3 +-
 drivers/net/ethernet/freescale/fman/fman_port.c  | 55 ++--
 drivers/net/ethernet/freescale/fman/fman_sp.c|  3 +
 drivers/net/ethernet/freescale/fman/mac.c| 83 
 drivers/net/ethernet/freescale/fman/mac.h|  3 +-
 11 files changed, 139 insertions(+), 116 deletions(-)

-- 
2.1.0

Re: [PATCH net v2] L2TP:Adjust intf MTU,factor underlay L3,overlay L2

[James Chapman]

On 04/10/16 04:12, R. Parameswaran wrote:
>
> Hi James, 
>
> Please see inline, thanks for the reply:
>
> On Sat, 1 Oct 2016, James Chapman wrote:
>
>> On 30/09/16 03:39, R. Parameswaran wrote:
> + /* Adjust MTU, factor overhead - underlay L3 hdr, overlay L2 hdr*/
> + if (tunnel->sock->sk_family == AF_INET)
> + overhead += (ETH_HLEN + sizeof(struct iphdr));
> + else if (tunnel->sock->sk_family == AF_INET6)
> + overhead += (ETH_HLEN + sizeof(struct ipv6hdr));
 What about options in the IP header? If certain options are set on the
 socket, the IP header may be larger.

>>> Thanks for the reply - It looks like IP options can only be 
>>> enabled through setsockopt on an application's socket (if there's any 
>>> other way to turn on IP options, please let me know - didn't see any 
>>> sysctl setting for transmit). This scenario would come 
>>> into picture when an application opens a raw IP or UDP socket such that it 
>>> routes into the L2TP logical interface.
>> No. An L2TP daemon (userspace) will open a socket for each tunnel that
>> it creates. Control and data packets use the same socket, which is the
>> socket used by this code. It may set any options on its sockets. L2TP
>> tunnel sockets can be created either by an L2TP daemon (managed tunnels)
>> or by ip l2tp commands (unmanaged tunnels).
>>
> One Q I have is whether it would be sufficient to solve this for the
> common case (i.e no IP options) and have an expectation that the 
> administrator will explicitly provision the mtu using the 'ip link ... 
> mtu'  command when dealing with infrequent occurences like IP options? 
>
> But looking at the code, it looks to be possible to pick up whether 
> options are enabled and how long the options are, from the ip_options struct 
> embedded in the tunnel socket. If you want me to, I can repost the patch
> with this change (will need a few days) - please let me know if this is 
> what you had in mind.
>
>
Yes, that's what I had in mind. But my preference would be that this
would be a new function in the ip core, for use by any encap protocol,
where appropriate.

pull-request: mac80211-next 2016-10-04

[Johannes Berg]

Hi Dave,

Here's a version with the conflicts resolved - had to jigger some
code around, but it's all described in the merge commit message.

Let me know if there's any problem.

Thanks,
johannes



The following changes since commit 9a8dd213d2a38349e5ea2ca400952112b45c:

  Merge branch 'ncsi-next' (2016-10-04 02:11:58 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git 
tags/mac80211-next-for-davem-2016-10-04

for you to fetch changes up to 1e1430d5282bc3a572465ef3261eea793d98a653:

  Merge remote-tracking branch 'net-next/master' into mac80211-next (2016-10-04 
09:46:44 +0200)


This time around, we have
 * Neighbor Awareness Networking (NAN) APIs
 * a fix for a previous patch that caused memory corruption
   in wireless extensions key settings
 * beacon rate configuration for AP and mesh
 * memory limits for mac80211's internal TXQs
 * a (fairly involved) fix for the TXQ vs. crypto problems
 * direct cfg80211 driver API for WEP keys

This also pulls in net-next to fix the merge conflicts, see
the merge commit for more details.


Ayala Beker (9):
  cfg80211: add start / stop NAN commands
  mac80211: add boilerplate code for start / stop NAN
  cfg80211: add add_nan_func / del_nan_func
  cfg80211: allow the user space to change current NAN configuration
  cfg80211: provide a function to report a match for NAN
  cfg80211: Provide an API to report NAN function termination
  mac80211: implement nan_change_conf
  mac80211: Implement add_nan_func and rm_nan_func
  mac80211: Add API to report NAN function match

David Spinadel (1):
  cfg80211: Add support for static WEP in the driver

Johannes Berg (3):
  cfg80211: add checks for beacon rate, extend to mesh
  cfg80211: wext: really don't store non-WEP keys
  Merge remote-tracking branch 'net-next/master' into mac80211-next

Pedersen, Thomas (2):
  mac80211: add offset_tsf driver op and use it for mesh
  mac80211: mesh: decrease max drift

Purushottam Kushwaha (1):
  cfg80211: Add support to configure a beacon data rate

Toke Høiland-Jørgensen (5):
  mac80211: Move ieee802111_tx_dequeue() to later in tx.c
  fq.h: Port memory limit mechanism from fq_codel
  mac80211: Export fq memory limit information in debugfs
  mac80211: Set lower memory limit for non-VHT devices
  mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue

 include/net/cfg80211.h|  223 +++-
 include/net/fq.h  |3 +
 include/net/fq_impl.h |7 +-
 include/net/mac80211.h|   75 +++
 include/uapi/linux/nl80211.h  |  270 -
 net/mac80211/cfg.c|  208 +++
 net/mac80211/chan.c   |6 +
 net/mac80211/debugfs.c|8 +
 net/mac80211/debugfs_netdev.c |   12 +-
 net/mac80211/driver-ops.c |   15 +
 net/mac80211/driver-ops.h |   83 +++
 net/mac80211/ieee80211_i.h|   26 +
 net/mac80211/iface.c  |   28 +-
 net/mac80211/main.c   |8 +
 net/mac80211/mesh_sync.c  |   12 +-
 net/mac80211/offchannel.c |4 +-
 net/mac80211/rx.c |7 +-
 net/mac80211/sta_info.c   |   10 +-
 net/mac80211/trace.h  |  159 ++
 net/mac80211/tx.c |  420 +-
 net/mac80211/util.c   |   61 ++-
 net/wireless/chan.c   |2 +
 net/wireless/core.c   |   35 ++
 net/wireless/core.h   |7 +-
 net/wireless/ibss.c   |5 +-
 net/wireless/mlme.c   |1 +
 net/wireless/nl80211.c| 1220 -
 net/wireless/rdev-ops.h   |   58 ++
 net/wireless/sme.c|6 +-
 net/wireless/trace.h  |   90 +++
 net/wireless/util.c   |   30 +-
 net/wireless/wext-compat.c|   14 +-
 net/wireless/wext-sme.c   |2 +-
 33 files changed, 2682 insertions(+), 433 deletions(-)

[net-next 11/13] fsl/fman: fix return value checking

[Madalin Bucur]

Signed-off-by: Madalin Bucur 
---
 drivers/net/ethernet/freescale/fman/fman.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fman/fman.c 
b/drivers/net/ethernet/freescale/fman/fman.c
index 1fc1049..dafd9e1 100644
--- a/drivers/net/ethernet/freescale/fman/fman.c
+++ b/drivers/net/ethernet/freescale/fman/fman.c
@@ -618,7 +618,7 @@ struct fman {
unsigned long cam_offset;
size_t cam_size;
/* Fifo in MURAM */
-   int fifo_offset;
+   unsigned long fifo_offset;
size_t fifo_size;
 
u32 liodn_base[64];
@@ -2036,7 +2036,7 @@ static int fman_init(struct fman *fman)
/* allocate MURAM for FIFO according to total size */
fman->fifo_offset = fman_muram_alloc(fman->muram,
 fman->state->total_fifo_size);
-   if (IS_ERR_VALUE(fman->cam_offset)) {
+   if (IS_ERR_VALUE(fman->fifo_offset)) {
free_init_resources(fman);
dev_err(fman->dev, "%s: MURAM alloc for BMI FIFO failed\n",
__func__);
-- 
2.1.0

[net-next 12/13] fsl/fman: remove leftover comment

[Madalin Bucur]

Signed-off-by: Madalin Bucur 
---
 drivers/net/ethernet/freescale/fman/fman_mac.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fman/fman_mac.h 
b/drivers/net/ethernet/freescale/fman/fman_mac.h
index ddf0260..dd6d052 100644
--- a/drivers/net/ethernet/freescale/fman/fman_mac.h
+++ b/drivers/net/ethernet/freescale/fman/fman_mac.h
@@ -191,10 +191,6 @@ struct fman_mac_params {
u16 max_speed;
/* A handle to the FM object this port related to */
void *fm;
-   /* MDIO exceptions interrupt source - not valid for all
-* MACs; MUST be set to 0 for MACs that don't have
-* mdio-irq, or for polling
-*/
void *dev_id; /* device cookie used by the exception cbs */
fman_mac_exception_cb *event_cb;/* MDIO Events Callback Routine */
fman_mac_exception_cb *exception_cb;/* Exception Callback Routine */
-- 
2.1.0

[net-next 04/13] fsl/fman: use of_get_phy_mode()

[Madalin Bucur]

From: Madalin Bucur 

Signed-off-by: Madalin Bucur 
---
 drivers/net/ethernet/freescale/fman/mac.c | 33 ++-
 1 file changed, 2 insertions(+), 31 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fman/mac.c 
b/drivers/net/ethernet/freescale/fman/mac.c
index e33d9d2..f94fad7 100644
--- a/drivers/net/ethernet/freescale/fman/mac.c
+++ b/drivers/net/ethernet/freescale/fman/mac.c
@@ -583,31 +583,6 @@ static void setup_memac(struct mac_device *mac_dev)
 
 static DEFINE_MUTEX(eth_lock);
 
-static const char phy_str[][11] = {
-   [PHY_INTERFACE_MODE_MII]= "mii",
-   [PHY_INTERFACE_MODE_GMII]   = "gmii",
-   [PHY_INTERFACE_MODE_SGMII]  = "sgmii",
-   [PHY_INTERFACE_MODE_TBI]= "tbi",
-   [PHY_INTERFACE_MODE_RMII]   = "rmii",
-   [PHY_INTERFACE_MODE_RGMII]  = "rgmii",
-   [PHY_INTERFACE_MODE_RGMII_ID]   = "rgmii-id",
-   [PHY_INTERFACE_MODE_RGMII_RXID] = "rgmii-rxid",
-   [PHY_INTERFACE_MODE_RGMII_TXID] = "rgmii-txid",
-   [PHY_INTERFACE_MODE_RTBI]   = "rtbi",
-   [PHY_INTERFACE_MODE_XGMII]  = "xgmii"
-};
-
-static phy_interface_t __pure __attribute__((nonnull)) str2phy(const char *str)
-{
-   int i;
-
-   for (i = 0; i < ARRAY_SIZE(phy_str); i++)
-   if (strcmp(str, phy_str[i]) == 0)
-   return (phy_interface_t)i;
-
-   return PHY_INTERFACE_MODE_MII;
-}
-
 static const u16 phy2speed[] = {
[PHY_INTERFACE_MODE_MII]= SPEED_100,
[PHY_INTERFACE_MODE_GMII]   = SPEED_1000,
@@ -686,7 +661,6 @@ static int mac_probe(struct platform_device *_of_dev)
struct resource  res;
struct mac_priv_s   *priv;
const u8*mac_addr;
-   const char  *char_prop;
const u32   *u32_prop;
u8  fman_id;
 
@@ -870,15 +844,12 @@ static int mac_probe(struct platform_device *_of_dev)
}
 
/* Get the PHY connection type */
-   char_prop = (const char *)of_get_property(mac_node,
- "phy-connection-type", NULL);
-   if (!char_prop) {
+   priv->phy_if = of_get_phy_mode(mac_node);
+   if (priv->phy_if < 0) {
dev_warn(dev,
 "of_get_property(%s, phy-connection-type) failed. 
Defaulting to MII\n",
 mac_node->full_name);
priv->phy_if = PHY_INTERFACE_MODE_MII;
-   } else {
-   priv->phy_if = str2phy(char_prop);
}
 
priv->speed = phy2speed[priv->phy_if];
-- 
2.1.0