* Re: [PATCH net] net: bcmgenet: device stats are unsigned long
From: Florian Fainelli @ 2016-04-18 0:49 UTC (permalink / raw)
To: Eric Dumazet, David Miller; +Cc: netdev
In-Reply-To: <1460742472.10638.78.camel@edumazet-glaptop3.roam.corp.google.com>
Le 15/04/2016 10:47, Eric Dumazet a écrit :
> From: Eric Dumazet <edumazet@google.com>
>
> On 64bit kernels, device stats are 64bit wide, not 32bit.
>
> Fixes: 1c1008c793fa4 ("net: bcmgenet: add main driver file")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
Late, but:
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Thanks Eric!
--
Florian
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2016-04-18 1:30 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Vivien Didelot
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/dsa/mv88e6xxx.c
between commit:
207afda1b503 ("net: dsa: mv88e6xxx: share the same default FDB")
from the net tree and commit:
009a2b9843bf ("net: dsa: mv88e6xxx: add number of ports to info")
from the net-next tree.
I fixed it up (the former removed some of the code updated by the latter)
and can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2016-04-18 1:31 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Craig Gallek, Eric Dumazet
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/ipv4/udp.c
between commit:
d894ba18d4e4 ("soreuseport: fix ordering for mixed v4/v6 sockets")
from the net tree and commit:
ca065d0cf80f ("udp: no longer use SLAB_DESTROY_BY_RCU")
from the net-next tree.
I tried to fixed it up (see below). Unfortunately,
hlist_add_tail_rcu() does not exist. So instead I have reverted commit
d894ba18d4e4 ("soreuseport: fix ordering for mixed v4/v6 sockets") for
today.
--
Cheers,
Stephen Rothwell
diff --cc net/ipv4/udp.c
index a2e7f55a1f61,f1863136d3e4..000000000000
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@@ -339,13 -336,8 +336,13 @@@ found
hslot2 = udp_hashslot2(udptable, udp_sk(sk)->udp_portaddr_hash);
spin_lock(&hslot2->lock);
- hlist_add_head_rcu(&udp_sk(sk)->udp_portaddr_node,
- &hslot2->head);
+ if (IS_ENABLED(CONFIG_IPV6) && sk->sk_reuseport &&
+ sk->sk_family == AF_INET6)
- hlist_nulls_add_tail_rcu(&udp_sk(sk)->udp_portaddr_node,
- &hslot2->head);
++ hlist_add_tail_rcu(&udp_sk(sk)->udp_portaddr_node,
++ &hslot2->head);
+ else
- hlist_nulls_add_head_rcu(&udp_sk(sk)->udp_portaddr_node,
- &hslot2->head);
++ hlist_add_head_rcu(&udp_sk(sk)->udp_portaddr_node,
++ &hslot2->head);
hslot2->count++;
spin_unlock(&hslot2->lock);
}
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the net tree
From: Eric Dumazet @ 2016-04-18 1:38 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, netdev, linux-next, linux-kernel, Craig Gallek,
Eric Dumazet
In-Reply-To: <20160418113116.6f7f8740@canb.auug.org.au>
On Mon, 2016-04-18 at 11:31 +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> net/ipv4/udp.c
>
> between commit:
>
> d894ba18d4e4 ("soreuseport: fix ordering for mixed v4/v6 sockets")
>
> from the net tree and commit:
>
> ca065d0cf80f ("udp: no longer use SLAB_DESTROY_BY_RCU")
>
> from the net-next tree.
>
> I tried to fixed it up (see below). Unfortunately,
> hlist_add_tail_rcu() does not exist. So instead I have reverted commit
> d894ba18d4e4 ("soreuseport: fix ordering for mixed v4/v6 sockets") for
> today.
Hi Stephen
Craig warned that this would happen indeed, and provided a net-next
patch, to help David with this conflict.
https://patchwork.ozlabs.org/patch/611093/
Thanks
^ permalink raw reply
* Re: [PATCH V2] net: ethernet: mellanox: correct page conversion
From: David Miller @ 2016-04-18 4:00 UTC (permalink / raw)
To: okaya-sgV2jX0FEOL9JmXXK+q4OQ
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, timur-sgV2jX0FEOL9JmXXK+q4OQ,
cov-sgV2jX0FEOL9JmXXK+q4OQ, yishaih-VPRAkNaXOzVWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1460845412-13120-1-git-send-email-okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
From: Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Date: Sat, 16 Apr 2016 18:23:32 -0400
> Current code is assuming that the address returned by dma_alloc_coherent
> is a logical address. This is not true on ARM/ARM64 systems. This patch
> replaces dma_alloc_coherent with dma_map_page API. The address returned
> can later by virtually mapped from the CPU side with vmap API.
>
> Signed-off-by: Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
You can't do this.
The DMA map page API gives non-coherent mappings, and thus requires
proper flushing.
So a straight conversion like this is never legitimate.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] of_mdio: make of_mdiobus_register_{device|phy}() *void*
From: David Miller @ 2016-04-18 4:02 UTC (permalink / raw)
To: sergei.shtylyov
Cc: grant.likely, robh+dt, devicetree, f.fainelli, netdev,
frowand.list
In-Reply-To: <1834436.v0N3sgcLOX@wasted.cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Sun, 17 Apr 2016 01:05:19 +0300
> The results of of_mdiobus_register_{device|phy}() are never checked, so we
> can make both these functions *void*...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Applied, thanks Sergei.
^ permalink raw reply
* Re: [PATCH] ixgbe: use msleep for long delays
From: David Miller @ 2016-04-18 4:03 UTC (permalink / raw)
To: arnd
Cc: jeffrey.t.kirsher, jesse.brandeburg, shannon.nelson,
carolyn.wyborny, donald.c.skidmore, bruce.w.allan, john.ronciak,
mitch.a.williams, mark.d.rustad, intel-wired-lan, netdev,
linux-kernel
In-Reply-To: <1460838941-1251989-1-git-send-email-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Sat, 16 Apr 2016 22:35:08 +0200
> The newly added x550em_a support causes a link failure on ARM because of
> an overly long time passed into udelay():
>
> ERROR: "__bad_udelay" [drivers/net/ethernet/intel/ixgbe/ixgbe.ko] undefined!
>
> There are multiple variants of the ixgbe_acquire_swfw_sync_*() function,
> and the other ones all use msleep(), so we can safely assume that all
> callers are allowed to sleep, which makes msleep() a better replacement
> than mdelay().
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 49425dfc7451 ("ixgbe: Add support for x550em_a 10G MAC type")
I'm assuming Jeff will pick this up.
^ permalink raw reply
* Re: [PATCH] bpf: avoid warning for wrong pointer cast
From: David Miller @ 2016-04-18 4:04 UTC (permalink / raw)
To: arnd; +Cc: netdev, rostedt, mingo, ast, daniel, linux-kernel
In-Reply-To: <1460838585-1248139-1-git-send-email-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Sat, 16 Apr 2016 22:29:33 +0200
> Two new functions in bpf contain a cast from a 'u64' to a
> pointer. This works on 64-bit architectures but causes a warning
> on all 32-bit architectures:
>
> kernel/trace/bpf_trace.c: In function 'bpf_perf_event_output_tp':
> kernel/trace/bpf_trace.c:350:13: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
> u64 ctx = *(long *)r1;
>
> This changes the cast to first convert the u64 argument into a uintptr_t,
> which is guaranteed to be the same size as a pointer.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 9940d67c93b5 ("bpf: support bpf_get_stackid() and bpf_perf_event_output() in tracepoint programs")
Applied.
^ permalink raw reply
* Re: [PATCH net-next 5/5] qed*: Add support for read/write of eeprom
From: David Miller @ 2016-04-18 4:07 UTC (permalink / raw)
To: Yuval.Mintz; +Cc: netdev, Sudarsana.Kalluru
In-Reply-To: <CO2PR11MB0088716755CC57276455ADA4976B0@CO2PR11MB0088.namprd11.prod.outlook.com>
From: Yuval Mintz <Yuval.Mintz@qlogic.com>
Date: Mon, 18 Apr 2016 03:59:42 +0000
> The third option I see is to completely ditch this, stating that although
> We obviously CAN set the non-volatile memory we CAN'T do it with the
> regular API, and to move into doing this via some proprietary API such
> as debugfs.
Why go to debugfs rather than gracefully extending the ethtool stuff to
explicitly support what you need?
Anyone who says debugfs just isn't willing to design things correctly.
That's why I basically have started rejecting everything that tries
to use debugfs in the networking, it's the "I'm too damn lazy to
do this properly" option and I simply won't stand for crap like that
any more.
^ permalink raw reply
* RE: [PATCH net-next 5/5] qed*: Add support for read/write of eeprom
From: Yuval Mintz @ 2016-04-18 3:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Sudarsana Kalluru
In-Reply-To: <20160417.191849.2044093416855662399.davem@davemloft.net>
> > There's quite a bit of `magic' here [based on the ethtool `magic'
> > field] which is retained by the user application responsible for
> > interacting with the driver for the purpose of upgrading the nvram
> > image.
>
> This is not how the 'magic' value of the eeprom structure is specified to be used,
> please use it the way it is supposed to be used rather than inventing semantics
> which only apply to your device.
>
> The entire point of defining a common interface for device driver interface
> interaction with the user is exactly so that driver authors don't do things like this.
While I obviously get what you're writing, I actually think this is the
more revealing API option.
I.e., the bottom line is that write to this device's nvram is complex in
nature and requires interacting with the management firmware.
The other immediate option would have been to implement this
in driver as simple read/write toward the management firmware,
and let the management firmware analyze what it needs to do with
the data based on hidden meta-data inside the buffer written by the
application.
While this might be less 'extending' of the ethtool API, it's a security-
in-obscurity kind of API, where a reviewer can't possibly know how to
perform read/write from reading the driver code.
The third option I see is to completely ditch this, stating that although
We obviously CAN set the non-volatile memory we CAN'T do it with the
regular API, and to move into doing this via some proprietary API such
as debugfs.
Thanks,
Yuval
^ permalink raw reply
* Re: [PATCH V2] net: ethernet: mellanox: correct page conversion
From: okaya @ 2016-04-18 5:06 UTC (permalink / raw)
To: David Miller; +Cc: linux-rdma, timur, cov, yishaih, netdev, linux-kernel
In-Reply-To: <20160418.000039.1946438541182822213.davem@davemloft.net>
On 2016-04-18 00:00, David Miller wrote:
> From: Sinan Kaya <okaya@codeaurora.org>
> Date: Sat, 16 Apr 2016 18:23:32 -0400
>
>> Current code is assuming that the address returned by
>> dma_alloc_coherent
>> is a logical address. This is not true on ARM/ARM64 systems. This
>> patch
>> replaces dma_alloc_coherent with dma_map_page API. The address
>> returned
>> can later by virtually mapped from the CPU side with vmap API.
>>
>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>
> You can't do this.
>
> The DMA map page API gives non-coherent mappings, and thus requires
> proper flushing.
>
> So a straight conversion like this is never legitimate.
I would agree on proper dma api usage. However, the code is already
assuming coherent architecture by mapping the cpu pages as page_kernel.
Dma_map_page returns cached buffers and you don't need cache flushes on
coherent architecture to make the data visible.
^ permalink raw reply
* [PATCH net-next V2 0/2] ethernet: intel: Support Hyper-V hosts
From: K. Y. Srinivasan @ 2016-04-18 5:22 UTC (permalink / raw)
To: davem, netdev, linux-kernel, devel, olaf, apw, jasowang, eli,
jackm, yevgenyp, john.ronciak, intel-wired-lan
Make adjustments to the Intel 10G VF driver to support
running on Hyper-V hosts.
K. Y. Srinivasan (2):
ethernet: intel: Add the device ID's presented while running on
Hyper-V
intel: ixgbevf: Support Windows hosts (Hyper-V)
drivers/net/ethernet/intel/ixgbevf/defines.h | 5 +
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 12 ++
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 16 ++-
drivers/net/ethernet/intel/ixgbevf/mbx.c | 12 ++
drivers/net/ethernet/intel/ixgbevf/vf.c | 201 +++++++++++++++++++++
5 files changed, 242 insertions(+), 4 deletions(-)
--
1.7.4.1
^ permalink raw reply
* [PATCH net-next V2 0/2] ethernet: intel: Support Hyper-V hosts
From: K. Y. Srinivasan @ 2016-04-18 5:22 UTC (permalink / raw)
To: davem, netdev, linux-kernel, devel, olaf, apw, jasowang, eli,
jackm, yevgenyp, john.ronciak, intel-wired-lan
In-Reply-To: <1460956943-17560-1-git-send-email-kys@microsoft.com>
Make adjustments to the Intel 10G VF driver to support
running on Hyper-V hosts.
K. Y. Srinivasan (2):
ethernet: intel: Add the device ID's presented while running on
Hyper-V
intel: ixgbevf: Support Windows hosts (Hyper-V)
drivers/net/ethernet/intel/ixgbevf/defines.h | 5 +
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 12 ++
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 16 ++-
drivers/net/ethernet/intel/ixgbevf/mbx.c | 12 ++
drivers/net/ethernet/intel/ixgbevf/vf.c | 201 +++++++++++++++++++++
5 files changed, 242 insertions(+), 4 deletions(-)
--
1.7.4.1
^ permalink raw reply
* [PATCH net-next V2 1/2] ethernet: intel: Add the device ID's presented while running on Hyper-V
From: K. Y. Srinivasan @ 2016-04-18 5:22 UTC (permalink / raw)
To: davem, netdev, linux-kernel, devel, olaf, apw, jasowang, eli,
jackm, yevgenyp, john.ronciak, intel-wired-lan
In-Reply-To: <1460956969-17601-1-git-send-email-kys@microsoft.com>
Intel SR-IOV cards present different ID when running on Hyper-V.
Add the device IDs presented while running on Hyper-V.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
V2: No change from V1.
drivers/net/ethernet/intel/ixgbevf/defines.h | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbevf/defines.h b/drivers/net/ethernet/intel/ixgbevf/defines.h
index 5843458..1306a0d 100644
--- a/drivers/net/ethernet/intel/ixgbevf/defines.h
+++ b/drivers/net/ethernet/intel/ixgbevf/defines.h
@@ -33,6 +33,11 @@
#define IXGBE_DEV_ID_X550_VF 0x1565
#define IXGBE_DEV_ID_X550EM_X_VF 0x15A8
+#define IXGBE_DEV_ID_82599_VF_HV 0x152E
+#define IXGBE_DEV_ID_X540_VF_HV 0x1530
+#define IXGBE_DEV_ID_X550_VF_HV 0x1564
+#define IXGBE_DEV_ID_X550EM_X_VF_HV 0x15A9
+
#define IXGBE_VF_IRQ_CLEAR_MASK 7
#define IXGBE_VF_MAX_TX_QUEUES 8
#define IXGBE_VF_MAX_RX_QUEUES 8
--
1.7.4.1
^ permalink raw reply related
* [PATCH net-next V2 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)
From: K. Y. Srinivasan @ 2016-04-18 5:22 UTC (permalink / raw)
To: davem, netdev, linux-kernel, devel, olaf, apw, jasowang, eli,
jackm, yevgenyp, john.ronciak, intel-wired-lan
In-Reply-To: <1460956969-17601-1-git-send-email-kys@microsoft.com>
On Hyper-V, the VF/PF communication is a via software mediated path
as opposed to the hardware mailbox. Make the necessary
adjustments to support Hyper-V.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
V2: Addressed most of the comments from
Alexander Duyck <alexander.duyck@gmail.com>
and Rustad, Mark D <mark.d.rustad@intel.com>.
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 12 ++
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 16 ++-
drivers/net/ethernet/intel/ixgbevf/mbx.c | 12 ++
drivers/net/ethernet/intel/ixgbevf/vf.c | 201 +++++++++++++++++++++
4 files changed, 237 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
index 5ac60ee..3296d27 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
@@ -460,9 +460,13 @@ enum ixbgevf_state_t {
enum ixgbevf_boards {
board_82599_vf,
+ board_82599_vf_hv,
board_X540_vf,
+ board_X540_vf_hv,
board_X550_vf,
+ board_X550_vf_hv,
board_X550EM_x_vf,
+ board_X550EM_x_vf_hv,
};
enum ixgbevf_xcast_modes {
@@ -477,6 +481,13 @@ extern const struct ixgbevf_info ixgbevf_X550_vf_info;
extern const struct ixgbevf_info ixgbevf_X550EM_x_vf_info;
extern const struct ixgbe_mbx_operations ixgbevf_mbx_ops;
+
+extern const struct ixgbevf_info ixgbevf_82599_vf_hv_info;
+extern const struct ixgbevf_info ixgbevf_X540_vf_hv_info;
+extern const struct ixgbevf_info ixgbevf_X550_vf_hv_info;
+extern const struct ixgbevf_info ixgbevf_X550EM_x_vf_hv_info;
+extern const struct ixgbe_mbx_operations ixgbevf_hv_mbx_ops;
+
/* needed by ethtool.c */
extern const char ixgbevf_driver_name[];
extern const char ixgbevf_driver_version[];
@@ -494,6 +505,7 @@ void ixgbevf_free_rx_resources(struct ixgbevf_ring *);
void ixgbevf_free_tx_resources(struct ixgbevf_ring *);
void ixgbevf_update_stats(struct ixgbevf_adapter *adapter);
int ethtool_ioctl(struct ifreq *ifr);
+bool ixgbevf_on_hyperv(struct ixgbe_hw *hw);
extern void ixgbevf_write_eitr(struct ixgbevf_q_vector *q_vector);
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 007cbe0..c761d80 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -62,10 +62,14 @@ static char ixgbevf_copyright[] =
"Copyright (c) 2009 - 2015 Intel Corporation.";
static const struct ixgbevf_info *ixgbevf_info_tbl[] = {
- [board_82599_vf] = &ixgbevf_82599_vf_info,
- [board_X540_vf] = &ixgbevf_X540_vf_info,
- [board_X550_vf] = &ixgbevf_X550_vf_info,
- [board_X550EM_x_vf] = &ixgbevf_X550EM_x_vf_info,
+ [board_82599_vf] = &ixgbevf_82599_vf_info,
+ [board_82599_vf_hv] = &ixgbevf_82599_vf_hv_info,
+ [board_X540_vf] = &ixgbevf_X540_vf_info,
+ [board_X540_vf_hv] = &ixgbevf_X540_vf_hv_info,
+ [board_X550_vf] = &ixgbevf_X550_vf_info,
+ [board_X550_vf_hv] = &ixgbevf_X550_vf_hv_info,
+ [board_X550EM_x_vf] = &ixgbevf_X550EM_x_vf_info,
+ [board_X550EM_x_vf_hv] = &ixgbevf_X550EM_x_vf_hv_info,
};
/* ixgbevf_pci_tbl - PCI Device ID Table
@@ -78,9 +82,13 @@ static const struct ixgbevf_info *ixgbevf_info_tbl[] = {
*/
static const struct pci_device_id ixgbevf_pci_tbl[] = {
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_VF), board_82599_vf },
+ {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_VF_HV), board_82599_vf_hv },
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X540_VF), board_X540_vf },
+ {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X540_VF_HV), board_X540_vf_hv },
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550_VF), board_X550_vf },
+ {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550_VF_HV), board_X550_vf_hv },
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_X_VF), board_X550EM_x_vf },
+ {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_X_VF_HV), board_X550EM_x_vf_hv},
/* required last entry */
{0, }
};
diff --git a/drivers/net/ethernet/intel/ixgbevf/mbx.c b/drivers/net/ethernet/intel/ixgbevf/mbx.c
index dc68fea..298a0da 100644
--- a/drivers/net/ethernet/intel/ixgbevf/mbx.c
+++ b/drivers/net/ethernet/intel/ixgbevf/mbx.c
@@ -346,3 +346,15 @@ const struct ixgbe_mbx_operations ixgbevf_mbx_ops = {
.check_for_rst = ixgbevf_check_for_rst_vf,
};
+/**
+ * Mailbox operations when running on Hyper-V.
+ * On Hyper-V, PF/VF communiction is not through the
+ * hardware mailbox; this communication is through
+ * a software mediated path.
+ * Most mail box operations are noop while running on
+ * Hyper-V.
+ */
+const struct ixgbe_mbx_operations ixgbevf_hv_mbx_ops = {
+ .init_params = ixgbevf_init_mbx_params_vf,
+ .check_for_rst = ixgbevf_check_for_rst_vf,
+};
diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.c b/drivers/net/ethernet/intel/ixgbevf/vf.c
index 4d613a4..1ec13c1 100644
--- a/drivers/net/ethernet/intel/ixgbevf/vf.c
+++ b/drivers/net/ethernet/intel/ixgbevf/vf.c
@@ -27,6 +27,13 @@
#include "vf.h"
#include "ixgbevf.h"
+/*
+ * On Hyper-V, to reset, we need to read from this offset
+ * from the PCI config space. This is the mechanism used on
+ * Hyper-V to support PF/VF communication.
+ */
+#define IXGBE_HV_RESET_OFFSET 0x201
+
/**
* ixgbevf_start_hw_vf - Prepare hardware for Tx/Rx
* @hw: pointer to hardware structure
@@ -126,6 +133,23 @@ static s32 ixgbevf_reset_hw_vf(struct ixgbe_hw *hw)
}
/**
+ * Hyper-V variant; the VF/PF communication is through the PCI
+ * config space.
+ */
+static s32 ixgbevf_hv_reset_hw_vf(struct ixgbe_hw *hw)
+{
+ struct ixgbevf_adapter *adapter = hw->back;
+ int i;
+
+ for (i = 0; i < 6; i++)
+ pci_read_config_byte(adapter->pdev,
+ (i + IXGBE_HV_RESET_OFFSET),
+ &hw->mac.perm_addr[i]);
+
+ return 0;
+}
+
+/**
* ixgbevf_stop_hw_vf - Generic stop Tx/Rx units
* @hw: pointer to hardware structure
*
@@ -258,6 +282,11 @@ static s32 ixgbevf_set_uc_addr_vf(struct ixgbe_hw *hw, u32 index, u8 *addr)
return ret_val;
}
+static s32 ixgbevf_hv_set_uc_addr_vf(struct ixgbe_hw *hw, u32 index, u8 *addr)
+{
+ return -EOPNOTSUPP;
+}
+
/**
* ixgbevf_get_reta_locked - get the RSS redirection table (RETA) contents.
* @adapter: pointer to the port handle
@@ -416,6 +445,26 @@ static s32 ixgbevf_set_rar_vf(struct ixgbe_hw *hw, u32 index, u8 *addr,
return ret_val;
}
+/**
+ * ixgbevf_hv_set_rar_vf - set device MAC address Hyper-V variant
+ * @hw: pointer to hardware structure
+ * @index: Receive address register to write
+ * @addr: Address to put into receive address register
+ * @vmdq: Unused in this implementation
+ *
+ * We don't really allow setting the device MAC address. However,
+ * if the address being set is the permanent MAC address we will
+ * permit that.
+ **/
+static s32 ixgbevf_hv_set_rar_vf(struct ixgbe_hw *hw, u32 index, u8 *addr,
+ u32 vmdq)
+{
+ if (ether_addr_equal(addr, hw->mac.perm_addr))
+ return 0;
+
+ return -EOPNOTSUPP;
+}
+
static void ixgbevf_write_msg_read_ack(struct ixgbe_hw *hw,
u32 *msg, u16 size)
{
@@ -473,6 +522,15 @@ static s32 ixgbevf_update_mc_addr_list_vf(struct ixgbe_hw *hw,
}
/**
+ * Hyper-V variant - just a stub.
+ */
+static s32 ixgbevf_hv_update_mc_addr_list_vf(struct ixgbe_hw *hw,
+ struct net_device *netdev)
+{
+ return -EOPNOTSUPP;
+}
+
+/**
* ixgbevf_update_xcast_mode - Update Multicast mode
* @hw: pointer to the HW structure
* @netdev: pointer to net device structure
@@ -513,6 +571,15 @@ static s32 ixgbevf_update_xcast_mode(struct ixgbe_hw *hw,
}
/**
+ * Hyper-V variant - just a stub.
+ */
+static s32 ixgbevf_hv_update_xcast_mode(struct ixgbe_hw *hw,
+ struct net_device *netdev, int xcast_mode)
+{
+ return -EOPNOTSUPP;
+}
+
+/**
* ixgbevf_set_vfta_vf - Set/Unset VLAN filter table address
* @hw: pointer to the HW structure
* @vlan: 12 bit VLAN ID
@@ -551,6 +618,15 @@ mbx_err:
}
/**
+ * Hyper-V variant - just a stub.
+ */
+static s32 ixgbevf_hv_set_vfta_vf(struct ixgbe_hw *hw, u32 vlan, u32 vind,
+ bool vlan_on)
+{
+ return -EOPNOTSUPP;
+}
+
+/**
* ixgbevf_setup_mac_link_vf - Setup MAC link settings
* @hw: pointer to hardware structure
* @speed: Unused in this implementation
@@ -656,6 +732,67 @@ out:
}
/**
+ * Hyper-V variant; there is no mailbox communication.
+ */
+static s32 ixgbevf_hv_check_mac_link_vf(struct ixgbe_hw *hw,
+ ixgbe_link_speed *speed,
+ bool *link_up,
+ bool autoneg_wait_to_complete)
+{
+ struct ixgbe_mbx_info *mbx = &hw->mbx;
+ struct ixgbe_mac_info *mac = &hw->mac;
+ u32 links_reg;
+
+ /* If we were hit with a reset drop the link */
+ if (!mbx->ops.check_for_rst(hw) || !mbx->timeout)
+ mac->get_link_status = true;
+
+ if (!mac->get_link_status)
+ goto out;
+
+ /* if link status is down no point in checking to see if pf is up */
+ links_reg = IXGBE_READ_REG(hw, IXGBE_VFLINKS);
+ if (!(links_reg & IXGBE_LINKS_UP))
+ goto out;
+
+ /* for SFP+ modules and DA cables on 82599 it can take up to 500usecs
+ * before the link status is correct
+ */
+ if (mac->type == ixgbe_mac_82599_vf) {
+ int i;
+
+ for (i = 0; i < 5; i++) {
+ udelay(100);
+ links_reg = IXGBE_READ_REG(hw, IXGBE_VFLINKS);
+
+ if (!(links_reg & IXGBE_LINKS_UP))
+ goto out;
+ }
+ }
+
+ switch (links_reg & IXGBE_LINKS_SPEED_82599) {
+ case IXGBE_LINKS_SPEED_10G_82599:
+ *speed = IXGBE_LINK_SPEED_10GB_FULL;
+ break;
+ case IXGBE_LINKS_SPEED_1G_82599:
+ *speed = IXGBE_LINK_SPEED_1GB_FULL;
+ break;
+ case IXGBE_LINKS_SPEED_100_82599:
+ *speed = IXGBE_LINK_SPEED_100_FULL;
+ break;
+ }
+
+ /* if we passed all the tests above then the link is up and we no
+ * longer need to check for link
+ */
+ mac->get_link_status = false;
+
+out:
+ *link_up = !mac->get_link_status;
+ return 0;
+}
+
+/**
* ixgbevf_rlpml_set_vf - Set the maximum receive packet length
* @hw: pointer to the HW structure
* @max_size: value to assign to max frame size
@@ -663,6 +800,18 @@ out:
void ixgbevf_rlpml_set_vf(struct ixgbe_hw *hw, u16 max_size)
{
u32 msgbuf[2];
+ u32 reg;
+
+ if (ixgbevf_on_hyperv(hw)) {
+ /* If we are on Hyper-V, we implement
+ * this functionality differently.
+ */
+ reg = IXGBE_READ_REG(hw, IXGBE_VFRXDCTL(0));
+ /* CRC == 4 */
+ reg |= ((max_size + 4) | IXGBE_RXDCTL_RLPML_EN);
+ IXGBE_WRITE_REG(hw, IXGBE_VFRXDCTL(0), reg);
+ return;
+ }
msgbuf[0] = IXGBE_VF_SET_LPE;
msgbuf[1] = max_size;
@@ -679,6 +828,15 @@ int ixgbevf_negotiate_api_version(struct ixgbe_hw *hw, int api)
int err;
u32 msg[3];
+ if (ixgbevf_on_hyperv(hw)) {
+ /* Hyper-V only supports api version ixgbe_mbox_api_10
+ */
+ if (api != ixgbe_mbox_api_10)
+ return IXGBE_ERR_INVALID_ARGUMENT;
+
+ return 0;
+ }
+
/* Negotiate the mailbox API version */
msg[0] = IXGBE_VF_API_NEGOTIATE;
msg[1] = api;
@@ -776,22 +934,65 @@ static const struct ixgbe_mac_operations ixgbevf_mac_ops = {
.set_vfta = ixgbevf_set_vfta_vf,
};
+static const struct ixgbe_mac_operations ixgbevf_hv_mac_ops = {
+ .init_hw = ixgbevf_init_hw_vf,
+ .reset_hw = ixgbevf_hv_reset_hw_vf,
+ .start_hw = ixgbevf_start_hw_vf,
+ .get_mac_addr = ixgbevf_get_mac_addr_vf,
+ .stop_adapter = ixgbevf_stop_hw_vf,
+ .setup_link = ixgbevf_setup_mac_link_vf,
+ .check_link = ixgbevf_hv_check_mac_link_vf,
+ .set_rar = ixgbevf_hv_set_rar_vf,
+ .update_mc_addr_list = ixgbevf_hv_update_mc_addr_list_vf,
+ .update_xcast_mode = ixgbevf_hv_update_xcast_mode,
+ .set_uc_addr = ixgbevf_hv_set_uc_addr_vf,
+ .set_vfta = ixgbevf_hv_set_vfta_vf,
+};
+
const struct ixgbevf_info ixgbevf_82599_vf_info = {
.mac = ixgbe_mac_82599_vf,
.mac_ops = &ixgbevf_mac_ops,
};
+const struct ixgbevf_info ixgbevf_82599_vf_hv_info = {
+ .mac = ixgbe_mac_82599_vf,
+ .mac_ops = &ixgbevf_hv_mac_ops,
+};
+
const struct ixgbevf_info ixgbevf_X540_vf_info = {
.mac = ixgbe_mac_X540_vf,
.mac_ops = &ixgbevf_mac_ops,
};
+const struct ixgbevf_info ixgbevf_X540_vf_hv_info = {
+ .mac = ixgbe_mac_X540_vf,
+ .mac_ops = &ixgbevf_hv_mac_ops,
+};
+
const struct ixgbevf_info ixgbevf_X550_vf_info = {
.mac = ixgbe_mac_X550_vf,
.mac_ops = &ixgbevf_mac_ops,
};
+const struct ixgbevf_info ixgbevf_X550_vf_hv_info = {
+ .mac = ixgbe_mac_X550_vf,
+ .mac_ops = &ixgbevf_hv_mac_ops,
+};
+
const struct ixgbevf_info ixgbevf_X550EM_x_vf_info = {
.mac = ixgbe_mac_X550EM_x_vf,
.mac_ops = &ixgbevf_mac_ops,
};
+
+const struct ixgbevf_info ixgbevf_X550EM_x_vf_hv_info = {
+ .mac = ixgbe_mac_X550EM_x_vf,
+ .mac_ops = &ixgbevf_hv_mac_ops,
+};
+
+bool ixgbevf_on_hyperv(struct ixgbe_hw *hw)
+{
+ if (hw->mbx.ops.check_for_msg == NULL)
+ return true;
+ else
+ return false;
+}
--
1.7.4.1
^ permalink raw reply related
* [PATCH net-next v4] rtnetlink: add new RTM_GETSTATS message to dump link stats
From: Roopa Prabhu @ 2016-04-18 5:35 UTC (permalink / raw)
To: netdev; +Cc: jhs, davem, tgraf
From: Roopa Prabhu <roopa@cumulusnetworks.com>
This patch adds a new RTM_GETSTATS message to query link stats via netlink
from the kernel. RTM_NEWLINK also dumps stats today, but RTM_NEWLINK
returns a lot more than just stats and is expensive in some cases when
frequent polling for stats from userspace is a common operation.
RTM_GETSTATS is an attempt to provide a light weight netlink message
to explicity query only link stats from the kernel on an interface.
The idea is to also keep it extensible so that new kinds of stats can be
added to it in the future.
This patch adds the following attribute for NETDEV stats:
struct nla_policy ifla_stats_policy[IFLA_STATS_MAX + 1] = {
[IFLA_STATS_LINK_64] = { .len = sizeof(struct rtnl_link_stats64) },
};
Like any other rtnetlink message, RTM_GETSTATS can be used to get stats of
a single interface or all interfaces with NLM_F_DUMP.
Future possible new types of stat attributes:
link af stats:
- IFLA_STATS_LINK_IPV6 (nested. for ipv6 stats)
- IFLA_STATS_LINK_MPLS (nested. for mpls/mdev stats)
extended stats:
- IFLA_STATS_LINK_EXTENDED (nested. extended software netdev stats like bridge,
vlan, vxlan etc)
- IFLA_STATS_LINK_HW_EXTENDED (nested. extended hardware stats which are
available via ethtool today)
This patch also declares a filter mask for all stat attributes.
User has to provide a mask of stats attributes to query. filter mask
can be specified in the new hdr 'struct if_stats_msg' for stats messages.
Other important field in the header is the ifindex.
This api can also include attributes for global stats (eg tcp) in the future.
When global stats are included in a stats msg, the ifindex in the header
must be zero. A single stats message cannot contain both global and
netdev specific stats. To easily distinguish them, netdev specific stat
attributes name are prefixed with IFLA_STATS_LINK_
Without any attributes in the filter_mask, no stats will be returned.
This patch has been tested with mofified iproute2 ifstat.
Suggested-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
RFC to v1 (apologies for the delay in sending this version out. busy days):
- Addressed feedback from Dave
- removed rtnl_link_stats
- Added hdr struct if_stats_msg to carry ifindex and
filter mask
- new macro IFLA_STATS_FILTER_BIT(ATTR) for filter mask
- split the ipv6 patch into a separate patch, need some more eyes on it
- prefix attributes with IFLA_STATS instead of IFLA_LINK_STATS for
shorter attribute names
v2:
- move IFLA_STATS_INET6 declaration to the inet6 patch
- get rid of RTM_DELSTATS
- mark ipv6 patch RFC. It can be used as an example for
other AF stats like stats
v3:
- add required padding to the if_stats_msg structure(suggested by jamal)
- rename netdev stat attributes with IFLA_STATS_LINK prefix
so that they are easily distinguishable with global
stats in the future (after global stats discussion with thomas)
- get rid of unnecessary copy when getting stats with dev_get_stats
(suggested by dave)
v4:
- dropped calcit and af stats from this patch. Will add it
back when it becomes necessary and with the first af stats
patch
- add check for null filter in dump and return -EINVAL:
this follows rtnl_fdb_dump in returning an error.
But since netlink_dump does not propagate the error
to the user, the user will not see an error and
but will also not see any data. This is consistent with
other kinds of dumps.
include/uapi/linux/if_link.h | 23 +++++++
include/uapi/linux/rtnetlink.h | 5 ++
net/core/rtnetlink.c | 150 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 178 insertions(+)
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index bb3a90b..0762f35 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -781,4 +781,27 @@ enum {
#define IFLA_HSR_MAX (__IFLA_HSR_MAX - 1)
+/* STATS section */
+
+struct if_stats_msg {
+ __u8 family;
+ __u8 pad1;
+ __u16 pad2;
+ __u32 ifindex;
+ __u32 filter_mask;
+};
+
+/* A stats attribute can be netdev specific or a global stat.
+ * For netdev stats, lets use the prefix IFLA_STATS_LINK_*
+ */
+enum {
+ IFLA_STATS_UNSPEC,
+ IFLA_STATS_LINK_64,
+ __IFLA_STATS_MAX,
+};
+
+#define IFLA_STATS_MAX (__IFLA_STATS_MAX - 1)
+
+#define IFLA_STATS_FILTER_BIT(ATTR) (1 << (ATTR))
+
#endif /* _UAPI_LINUX_IF_LINK_H */
diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
index ca764b5..cc885c4 100644
--- a/include/uapi/linux/rtnetlink.h
+++ b/include/uapi/linux/rtnetlink.h
@@ -139,6 +139,11 @@ enum {
RTM_GETNSID = 90,
#define RTM_GETNSID RTM_GETNSID
+ RTM_NEWSTATS = 92,
+#define RTM_NEWSTATS RTM_NEWSTATS
+ RTM_GETSTATS = 94,
+#define RTM_GETSTATS RTM_GETSTATS
+
__RTM_MAX,
#define RTM_MAX (((__RTM_MAX + 3) & ~3) - 1)
};
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index a75f7e9..fe35102 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -3451,6 +3451,153 @@ out:
return err;
}
+static int rtnl_fill_statsinfo(struct sk_buff *skb, struct net_device *dev,
+ int type, u32 pid, u32 seq, u32 change,
+ unsigned int flags, unsigned int filter_mask)
+{
+ struct if_stats_msg *ifsm;
+ struct nlmsghdr *nlh;
+ struct nlattr *attr;
+
+ ASSERT_RTNL();
+
+ nlh = nlmsg_put(skb, pid, seq, type, sizeof(*ifsm), flags);
+ if (!nlh)
+ return -EMSGSIZE;
+
+ ifsm = nlmsg_data(nlh);
+ ifsm->ifindex = dev->ifindex;
+ ifsm->filter_mask = filter_mask;
+
+ if (filter_mask & IFLA_STATS_FILTER_BIT(IFLA_STATS_LINK_64)) {
+ struct rtnl_link_stats64 *sp;
+
+ attr = nla_reserve(skb, IFLA_STATS_LINK_64,
+ sizeof(struct rtnl_link_stats64));
+ if (!attr)
+ goto nla_put_failure;
+
+ sp = nla_data(attr);
+ dev_get_stats(dev, sp);
+ }
+
+ nlmsg_end(skb, nlh);
+
+ return 0;
+
+nla_put_failure:
+ nlmsg_cancel(skb, nlh);
+
+ return -EMSGSIZE;
+}
+
+static const struct nla_policy ifla_stats_policy[IFLA_STATS_MAX + 1] = {
+ [IFLA_STATS_LINK_64] = { .len = sizeof(struct rtnl_link_stats64) },
+};
+
+static size_t if_nlmsg_stats_size(const struct net_device *dev,
+ u32 filter_mask)
+{
+ size_t size = 0;
+
+ if (filter_mask & IFLA_STATS_FILTER_BIT(IFLA_STATS_LINK_64))
+ size += nla_total_size(sizeof(struct rtnl_link_stats64));
+
+ return size;
+}
+
+static int rtnl_stats_get(struct sk_buff *skb, struct nlmsghdr *nlh)
+{
+ struct net *net = sock_net(skb->sk);
+ struct if_stats_msg *ifsm;
+ struct net_device *dev = NULL;
+ struct sk_buff *nskb;
+ u32 filter_mask;
+ int err;
+
+ ifsm = nlmsg_data(nlh);
+ if (ifsm->ifindex > 0)
+ dev = __dev_get_by_index(net, ifsm->ifindex);
+ else
+ return -EINVAL;
+
+ if (!dev)
+ return -ENODEV;
+
+ filter_mask = ifsm->filter_mask;
+ if (!filter_mask)
+ return -EINVAL;
+
+ nskb = nlmsg_new(if_nlmsg_stats_size(dev, filter_mask), GFP_KERNEL);
+ if (!nskb)
+ return -ENOBUFS;
+
+ err = rtnl_fill_statsinfo(nskb, dev, RTM_NEWSTATS,
+ NETLINK_CB(skb).portid, nlh->nlmsg_seq, 0,
+ 0, filter_mask);
+ if (err < 0) {
+ /* -EMSGSIZE implies BUG in if_nlmsg_stats_size */
+ WARN_ON(err == -EMSGSIZE);
+ kfree_skb(nskb);
+ } else {
+ err = rtnl_unicast(nskb, net, NETLINK_CB(skb).portid);
+ }
+
+ return err;
+}
+
+static int rtnl_stats_dump(struct sk_buff *skb, struct netlink_callback *cb)
+{
+ struct net *net = sock_net(skb->sk);
+ struct if_stats_msg *ifsm;
+ int h, s_h;
+ int idx = 0, s_idx;
+ struct net_device *dev;
+ struct hlist_head *head;
+ unsigned int flags = NLM_F_MULTI;
+ u32 filter_mask = 0;
+ int err;
+
+ s_h = cb->args[0];
+ s_idx = cb->args[1];
+
+ cb->seq = net->dev_base_seq;
+
+ ifsm = nlmsg_data(cb->nlh);
+ filter_mask = ifsm->filter_mask;
+ if (!filter_mask)
+ return -EINVAL;
+
+ for (h = s_h; h < NETDEV_HASHENTRIES; h++, s_idx = 0) {
+ idx = 0;
+ head = &net->dev_index_head[h];
+ hlist_for_each_entry(dev, head, index_hlist) {
+ if (idx < s_idx)
+ goto cont;
+ err = rtnl_fill_statsinfo(skb, dev, RTM_NEWSTATS,
+ NETLINK_CB(cb->skb).portid,
+ cb->nlh->nlmsg_seq, 0,
+ flags, filter_mask);
+ /* If we ran out of room on the first message,
+ * we're in trouble
+ */
+ WARN_ON((err == -EMSGSIZE) && (skb->len == 0));
+
+ if (err < 0)
+ goto out;
+
+ nl_dump_check_consistent(cb, nlmsg_hdr(skb));
+cont:
+ idx++;
+ }
+ }
+out:
+ cb->args[1] = idx;
+ cb->args[0] = h;
+
+ return skb->len;
+}
+
/* Process one rtnetlink message. */
static int rtnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
@@ -3600,4 +3747,7 @@ void __init rtnetlink_init(void)
rtnl_register(PF_BRIDGE, RTM_GETLINK, NULL, rtnl_bridge_getlink, NULL);
rtnl_register(PF_BRIDGE, RTM_DELLINK, rtnl_bridge_dellink, NULL, NULL);
rtnl_register(PF_BRIDGE, RTM_SETLINK, rtnl_bridge_setlink, NULL, NULL);
+
+ rtnl_register(PF_UNSPEC, RTM_GETSTATS, rtnl_stats_get, rtnl_stats_dump,
+ NULL);
}
--
1.9.1
^ permalink raw reply related
* RE: [PATCHv2] wlcore: spi: add wl18xx support
From: Reizer, Eyal @ 2016-04-18 5:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Kalle Valo, Eyal Reizer,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <14313437.cDJIgY3kzo@wuerfel>
> >
> > - all wilink family needs special init command for entering wspi mode.
> > extra clock cycles should be sent after the spi init command while the
> > cs pin is high.
> > - switch to controling the cs pin from the spi driver for achieveing the
> > above.
> > - the selected cs gpio is read from the spi device-tree node using the
> > cs-gpios field and setup as a gpio.
> > - See the example below for specifying the cs gpio using the cs-gpios entry
> > &spi0 {
> > ...
> > cs-gpios = <&gpio0 5 0>;
> > ...
> > wlcore: wlcore@0 {
> > compatible = "ti,wl1835";
> > ...
> > ...
> > };
> > };
> >
> > Signed-off-by: Eyal Reizer <eyalr-l0cyMroinI0@public.gmane.org>
>
> I don't think this can work in general: not all SPI hosts uses GPIOs for
> controlling CS, so the logic can't work, and it's also a layering violation for the
> driver to look at the parent.
>
> I would suggest fixing this using a new API function from the SPI core, if we
> don't already have a generic way to do it.
>
Originally this is what I have done until I was pointed to the generic cs-gpio mechanism
in the SPI core.
It is a generic mechanism already in the SPI core driver.
See: Documentation/devicetree/bindings/spi/spi-bus.txt
It is also part of the generic spi.h (include/Linux/spi/spi.h), already part of
" struct spi_device" So it seemed redundant adding another mechanism for
implementing the same.
Platform that interact with a wilink need to use it, and platforms that don't
have this capability will probably not interact with a wilink device using SPI.
Best Regards,
Eyal
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 5/5] qed*: Add support for read/write of eeprom
From: Yuval Mintz @ 2016-04-18 5:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Sudarsana Kalluru
In-Reply-To: <20160418.000712.473871996964045833.davem@davemloft.net>
>> The third option I see is to completely ditch this, stating that although
>> We obviously CAN set the non-volatile memory we CAN'T do it with the
>> regular API, and to move into doing this via some proprietary API such
>> as debugfs.
> Why go to debugfs rather than gracefully extending the ethtool stuff to
> explicitly support what you need?
Gracefully extend it to where?
The most I can learn from this is that some adapters are in
need of additional metadata for doing this sort of stuff.
The state-machine itself is propriety and I don't think anyone
would gain from trying to formalize anything else from it.
If by 'graceful extension' of ethtool API you mean adding an
additional field or two for metadata - sure, I can do that,
I just don't think of it as graceful. ;-)
And if this is actually the way we want to take this, I would
still [don't get upset ;-)] argue in favor of overloading the
'magic' field for this purpose, as bnx2x and bnxt are already
doing.
Basically if the 'magic' would also contain metadata that
could be verified as appropriate [I.e., by having valid ranges],
it would still fit as a safety measure for guaranteeing the
correctness of the write request.
^ permalink raw reply
* Re: [PATCH V2] net: ethernet: mellanox: correct page conversion
From: Eli Cohen @ 2016-04-18 6:54 UTC (permalink / raw)
To: Sinan Kaya; +Cc: linux-rdma, timur, cov, Yishai Hadas, netdev, linux-kernel
In-Reply-To: <1460845412-13120-1-git-send-email-okaya@codeaurora.org>
Sinan,
if we get rid of the part this code:
if (BITS_PER_LONG == 64) {
struct page **pages;
pages = kmalloc(sizeof *pages * buf->nbufs, gfp);
if (!pages)
goto err_free;
...
...
if (!buf->direct.buf)
goto err_free;
}
Does that solve the arm issue?
The other parts of the driver using the allocated buffer can still
work with list of coherent chunks.
On Sat, Apr 16, 2016 at 06:23:32PM -0400, Sinan Kaya wrote:
> Current code is assuming that the address returned by dma_alloc_coherent
> is a logical address. This is not true on ARM/ARM64 systems. This patch
> replaces dma_alloc_coherent with dma_map_page API. The address returned
> can later by virtually mapped from the CPU side with vmap API.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/net/ethernet/mellanox/mlx4/alloc.c | 37 ++++++++++++++++++++++--------
> 1 file changed, 27 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/alloc.c b/drivers/net/ethernet/mellanox/mlx4/alloc.c
> index 0c51c69..22a7ae7 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/alloc.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/alloc.c
> @@ -618,13 +618,26 @@ int mlx4_buf_alloc(struct mlx4_dev *dev, int size, int max_direct,
> return -ENOMEM;
>
> for (i = 0; i < buf->nbufs; ++i) {
> - buf->page_list[i].buf =
> - dma_alloc_coherent(&dev->persist->pdev->dev,
> - PAGE_SIZE,
> - &t, gfp);
> - if (!buf->page_list[i].buf)
> + struct page *page;
> +
> + page = alloc_page(GFP_KERNEL);
> + if (!page)
> goto err_free;
>
> + t = dma_map_page(&dev->persist->pdev->dev, page, 0,
> + PAGE_SIZE, DMA_BIDIRECTIONAL);
> +
> + if (dma_mapping_error(&dev->persist->pdev->dev, t)) {
> + __free_page(page);
> + goto err_free;
> + }
> +
> + buf->page_list[i].buf = page_address(page);
> + if (!buf->page_list[i].buf) {
> + __free_page(page);
> + goto err_free;
> + }
> +
> buf->page_list[i].map = t;
>
> memset(buf->page_list[i].buf, 0, PAGE_SIZE);
> @@ -666,11 +679,15 @@ void mlx4_buf_free(struct mlx4_dev *dev, int size, struct mlx4_buf *buf)
> vunmap(buf->direct.buf);
>
> for (i = 0; i < buf->nbufs; ++i)
> - if (buf->page_list[i].buf)
> - dma_free_coherent(&dev->persist->pdev->dev,
> - PAGE_SIZE,
> - buf->page_list[i].buf,
> - buf->page_list[i].map);
> + if (buf->page_list[i].buf) {
> + struct page *page;
> +
> + page = virt_to_page(buf->page_list[i].buf);
> + dma_unmap_page(&dev->persist->pdev->dev,
> + buf->page_list[i].map,
> + PAGE_SIZE, DMA_BIDIRECTIONAL);
> + __free_page(page);
> + }
> kfree(buf->page_list);
> }
> }
> --
> 1.8.2.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* request for stable inclusion
From: Or Gerlitz @ 2016-04-18 6:57 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, Huy Nguyen, Yevgeny Petrilin
Hi Dave,
Could you please push to -stable the UAR patch (below), it allows mlx4
to run on PPC systems without hacking PCI BAR sizes. The patch
introduced small regression for people that do prefer to run non
modified VF drivers with modified host driver, and hence should be
accompanied by the backward compatibility (below too)
76e39cc net/mlx4_core: Fix backward compatibility on VFs
85743f1 net/mlx4_core: Set UAR page size to 4KB regardless of system page size
Thanks,
Or.
^ permalink raw reply
* Re: [PATCH net-next 2/2] bpf: add event output helper for notifications/sampling/logging
From: Daniel Borkmann @ 2016-04-18 7:22 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, davem, alexei.starovoitov, tgraf, netdev,
linux-kernel, Alexei Starovoitov
In-Reply-To: <201604180722.wizpe3nL%fengguang.wu@intel.com>
On 04/18/2016 01:55 AM, kbuild test robot wrote:
> Hi Daniel,
>
> [auto build test ERROR on net-next/master]
>
> url: https://github.com/0day-ci/linux/commits/Daniel-Borkmann/bpf-trace-add-BPF_F_CURRENT_CPU-flag-for-bpf_perf_event_output/20160418-063147
> config: m68k-allyesconfig (attached as .config)
> reproduce:
> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=m68k
>
> All errors (new ones prefixed by >>):
>
> net/core/filter.c: In function 'bpf_skb_event_output':
>>> net/core/filter.c:1599:2: error: implicit declaration of function 'perf_fetch_caller_regs' [-Werror=implicit-function-declaration]
> perf_fetch_caller_regs(regs);
> ^
> cc1: some warnings being treated as errors
>
> vim +/perf_fetch_caller_regs +1599 net/core/filter.c
>
> 1593 static DEFINE_PER_CPU(struct pt_regs, bpf_pt_regs);
> 1594
> 1595 static u64 bpf_skb_event_output(u64 r1, u64 r2, u64 flags, u64 r4, u64 size)
> 1596 {
> 1597 struct pt_regs *regs = this_cpu_ptr(&bpf_pt_regs);
> 1598
>> 1599 perf_fetch_caller_regs(regs);
> 1600
> 1601 return bpf_perf_event_output((long)regs, r2, flags, r4, size);
> 1602 }
Sorry about that, missed this one. Will fix it up in v2!
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH] macsec: fix crypto Kconfig dependency
From: Herbert Xu @ 2016-04-18 8:02 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: davem, sd, arnd, hannes, johannes, netdev, linux-kernel
In-Reply-To: <1460884918-2879720-1-git-send-email-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> wrote:
> The new MACsec driver uses the AES crypto algorithm, but can be configured
> even if CONFIG_CRYPTO is disabled, leading to a build error:
>
> warning: (MAC80211 && MACSEC) selects CRYPTO_GCM which has unmet direct dependencies (CRYPTO)
> warning: (BT && CEPH_LIB && INET && MAC802154 && MAC80211 && BLK_DEV_RBD && MACSEC && AIRO_CS && LIBIPW && HOSTAP && USB_WUSB && RTLLIB_CRYPTO_CCMP && FS_ENCRYPTION && EXT4_ENCRYPTION && CEPH_FS && BIG_KEYS && ENCRYPTED_KEYS) selects CRYPTO_AES which has unmet direct dependencies (CRYPTO)
> crypto/built-in.o: In function `gcm_enc_copy_hash':
> aes_generic.c:(.text+0x2b8): undefined reference to `crypto_xor'
> aes_generic.c:(.text+0x2dc): undefined reference to `scatterwalk_map_and_copy'
>
> This adds an explicit 'select CRYPTO' statement the way that other
> drivers handle it.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver")
Thnis patch is bogus. The build error is coming from the fact
that GCM is built-in but CRYPTO_ALGAPI is (presumably) only built
as a module. The patch in question does nothing to address that
AFAICS.
In fact this strikes me as a kbuild bug because CRYPTO_GCM already
selects (indirectly) CRYPTO_ALGAPI so why is this happening at all?
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [patch -next] udp: fix if statement in SIOCINQ ioctl
From: Dan Carpenter @ 2016-04-18 8:44 UTC (permalink / raw)
To: David S. Miller, Willem de Bruijn
Cc: Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, netdev, linux-kernel, kernel-janitors
We deleted a line of code and accidentally made the "return put_user()"
part of the if statement when it's supposed to be unconditional.
Fixes: 9f9a45beaa96 ('udp: do not expect udp headers on ioctl SIOCINQ')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index f186313..37e09c3 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1276,12 +1276,6 @@ int udp_ioctl(struct sock *sk, int cmd, unsigned long arg)
{
unsigned int amount = first_packet_length(sk);
- if (amount)
- /*
- * We will only return the amount
- * of this packet since that is all
- * that will be read.
- */
return put_user(amount, (int __user *)arg);
}
^ permalink raw reply related
* Re: [PATCH] ipv6: allow bypassing cross-intf routing limits
From: Michal Kazior @ 2016-04-18 9:38 UTC (permalink / raw)
To: David Miller; +Cc: Network Development
In-Reply-To: <20160416.184936.1899675200733835878.davem@davemloft.net>
On 17 April 2016 at 00:49, David Miller <davem@davemloft.net> wrote:
> From: Michal Kazior <michal.kazior@tieto.com>
> Date: Thu, 14 Apr 2016 14:46:28 +0200
>
>> There are some use-cases to allow link-local
>> routing for bridging purposes.
>>
>> One of these is allowing transparent 802.11
>> bridging. Due to 802.11 framing limitations many
>> Access Points make it impossible to create bridges
>> on Client endpoints because they can't maintain
>> Destination/Source/Transmitter/Receiver address
>> distinction with only 3 addresses in frame header.
>>
>> The default behavior, i.e. link-local traffic
>> being non-routable, remains. The user has to
>> explicitly enable the bypass when defining a given
>> route.
>>
>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>
> Sorry, whilst I realize your problem, I'm not going to add what is
> explicitly a violation of the way link-local addresses are meant to
> work and the very much intentional restrictions the RFCs place upon
> them (they MUST not be routed).
>
> I also didn't see any real discussions in response to your original
> proposals, not from even one person I know is knowledgable about ipv6
> and the implications your change would have, and that is extremely
> troubling.
>
> I tried to let your patches sit for several days in order to let that
> kind of discussion happen, but it didn't.
I totally understand. Thanks anyway.
> So, you'll need to find another way to achieve your goals.
Hmm.. I actually do have another idea in mind already.
I was wondering about about implementing a link device in a similar
fashion to macvlan, bridge, et al, i.e. the device would take an
interface (wlan interface in my case) as a slave and perform L2
address mangling (which should be enough to accommodate the addressing
deficiency in wireless client modes). The device would obviously need
to do some L3/L4 packet inspection and manipulation.
Would something like that be acceptable? Thoughts?
Michał
^ permalink raw reply
* Re: [PATCHv3 net-next 1/6] sctp: add sctp_info dump api for sctp_diag
From: Phil Sutter @ 2016-04-18 10:18 UTC (permalink / raw)
To: David Miller
Cc: lucien.xin, netdev, linux-sctp, marcelo.leitner, vyasevich,
daniel, eric.dumazet
In-Reply-To: <20160415.172858.253625178036493951.davem@davemloft.net>
On Fri, Apr 15, 2016 at 05:28:58PM -0400, David Miller wrote:
> Feedback was given here not to mix the changelog and the commit message.
>
> And I want to explicitly state that I totally and _COMPLETELY_ disagree
> with this.
>
> It is absolutely essential information and belongs in the commit message.
>
> Adding more information never hurts, so don't do this crap of putting
> things that might be useful to know after the "---", ever.
>
> Someone in the future might ask "why didn't he implement it like XXX"
> and the changelog can tell him that originally that is what was done
> and feedback was given to do it differently.
I see your point and am well aware the last word on this belongs to you.
Still I would like to explain why I disagree:
In my understanding, the changelog addresses reviewers only, so they
know what to expect or which new chunks to have another look at. If the
changelog provides valuable information beyond that, I think the mistake
was to not update the commit message accordingly.
Imagine a patchset being rerolled ten times with massive changes in
between - do you really appreciate if the changelog applies to v1 only
and people have to read through nine increments to find out what is
actually being done?
Although I'm exaggerating, one could apply the same logic to the code
changes itself and demand v1 being applied as is with each evolution
separately on top, as otherwise information is lost.
Cheers, Phil
>
> So Xin thanks for correctly putting the changelog inside of the commit
> message, so that future developers can benefit from this knowledge.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox