* Re: [PATCH RFC] net: decrease the length of backlog queue immediately after it's detached from sk
From: Yang Yingliang @ 2016-04-12 12:31 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem, Ding Tianhong
In-Reply-To: <570C6483.5020502@huawei.com>
On 2016/4/12 10:59, Yang Yingliang wrote:
>
>
> On 2016/4/11 20:13, Eric Dumazet wrote:
>> On Mon, 2016-04-11 at 19:57 +0800, Yang Yingliang wrote:
>>>
>>> On 2016/4/8 22:44, Eric Dumazet wrote:
>>>> On Fri, 2016-04-08 at 19:18 +0800, Yang Yingliang wrote:
>>>>
>>>>> I expand tcp_adv_win_scale and tcp_rmem. It has no effect.
>>>>
>>>> Try :
>>>>
>>>> echo -2 >/proc/sys/net/ipv4/tcp_adv_win_scale
>>>>
>>>> And restart your flows.
>>>>
>>> cat /proc/sys/net/ipv4/tcp_rmem
>>> 10240 2097152 10485760
>>
>> What about leaving the default values ?
> I tried, it did not work.
>
>>
>> $ cat /proc/sys/net/ipv4/tcp_rmem
>> 4096 87380 6291456
>>
>>>
>>> echo 102400 20971520 104857600 > /proc/sys/net/ipv4/tcp_rmem
>>> echo -2 >/proc/sys/net/ipv4/tcp_adv_win_scale
>>>
>>> It seems has not effect.
>>>
>>
>> I have no idea what you did on the sender side to allow it to send more
>> than 1.5 MB then.
>
> We are doing performance test. The sender send 256KB per-block with 128
> threads to one socket. And the receiver uses 10Gb NIC to handle the
> data on ARM64. The data flow is driver->ip layer->tcp layer->iscsi.
>
> I added some debug messages and found handling backlog packets in
> __release_sock() cost about 11ms at most. This can cause backlog queue
> overflow. The sk_data_ready is re-assigned, it may cost time in our
> program. I will check it out.
>
I traced the cost cycles of handling backlog packets in
__release_sock().
16.97 ms to handling about 12MB backlog packets, of which 13.66ms to do
sk_data_ready.
The speed of handling packets in TCP is 5.65Gb/s which is smaller than
the NIC's bandwidth. So the packets will be dropped.
If the cost of sk_data_read cannot be reduced, do we have other choice
exclude dropping packets ?
^ permalink raw reply
* Re: [PATCH v2] mwifiex: fix possible NULL dereference
From: Sudip Mukherjee @ 2016-04-12 11:56 UTC (permalink / raw)
To: Arend van Spriel, Amitkumar Karwar, Nishant Sarmukadam,
Kalle Valo
Cc: linux-kernel, linux-wireless, netdev, Sudip Mukherjee,
Christian Daudt
In-Reply-To: <570CE113.20200@broadcom.com>
On Tuesday 12 April 2016 05:20 PM, Arend van Spriel wrote:
>
>
> On 12-04-16 13:46, Sudip Mukherjee wrote:
>> From: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
>>
>> We have a check for card just after dereferencing it. So if it is NULL
>> we have already dereferenced it before its check. Lets dereference it
>> after checking card for NULL.
>
> And you are changing the scope of the pdev variable.
yes, and since all usage of pdev is inside the "if" block so it should
not matter.
regards
sudip
>
> Regards,
> Arend
>
>> Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
>> ---
>> drivers/net/wireless/marvell/mwifiex/pcie.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
>> index edf8b07..d4db9db 100644
>> --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
>> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
>> @@ -2884,10 +2884,11 @@ static void mwifiex_unregister_dev(struct mwifiex_adapter *adapter)
>> {
>> struct pcie_service_card *card = adapter->card;
>> const struct mwifiex_pcie_card_reg *reg;
>> - struct pci_dev *pdev = card->dev;
>> int i;
>>
>> if (card) {
>> + struct pci_dev *pdev = card->dev;
>> +
>> if (card->msix_enable) {
>> for (i = 0; i < MWIFIEX_NUM_MSIX_VECTORS; i++)
>> synchronize_irq(card->msix_entries[i].vector);
>>
^ permalink raw reply
* Re: [PATCH v2] mwifiex: fix possible NULL dereference
From: Arend van Spriel @ 2016-04-12 11:50 UTC (permalink / raw)
To: Sudip Mukherjee, Amitkumar Karwar, Nishant Sarmukadam, Kalle Valo
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Sudip Mukherjee, Christian Daudt
In-Reply-To: <1460461597-7309-1-git-send-email-sudipm.mukherjee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 12-04-16 13:46, Sudip Mukherjee wrote:
> From: Sudip Mukherjee <sudip.mukherjee-4yDnlxn2s6sWdaTGBSpHTA@public.gmane.org>
>
> We have a check for card just after dereferencing it. So if it is NULL
> we have already dereferenced it before its check. Lets dereference it
> after checking card for NULL.
And you are changing the scope of the pdev variable.
Regards,
Arend
> Signed-off-by: Sudip Mukherjee <sudip.mukherjee-4yDnlxn2s6sWdaTGBSpHTA@public.gmane.org>
> ---
> drivers/net/wireless/marvell/mwifiex/pcie.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
> index edf8b07..d4db9db 100644
> --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> @@ -2884,10 +2884,11 @@ static void mwifiex_unregister_dev(struct mwifiex_adapter *adapter)
> {
> struct pcie_service_card *card = adapter->card;
> const struct mwifiex_pcie_card_reg *reg;
> - struct pci_dev *pdev = card->dev;
> int i;
>
> if (card) {
> + struct pci_dev *pdev = card->dev;
> +
> if (card->msix_enable) {
> for (i = 0; i < MWIFIEX_NUM_MSIX_VECTORS; i++)
> synchronize_irq(card->msix_entries[i].vector);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* [PATCH v2] mwifiex: fix possible NULL dereference
From: Sudip Mukherjee @ 2016-04-12 11:46 UTC (permalink / raw)
To: Amitkumar Karwar, Nishant Sarmukadam, Kalle Valo
Cc: linux-kernel, linux-wireless, netdev, Sudip Mukherjee,
Christian Daudt
From: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
We have a check for card just after dereferencing it. So if it is NULL
we have already dereferenced it before its check. Lets dereference it
after checking card for NULL.
Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index edf8b07..d4db9db 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2884,10 +2884,11 @@ static void mwifiex_unregister_dev(struct mwifiex_adapter *adapter)
{
struct pcie_service_card *card = adapter->card;
const struct mwifiex_pcie_card_reg *reg;
- struct pci_dev *pdev = card->dev;
int i;
if (card) {
+ struct pci_dev *pdev = card->dev;
+
if (card->msix_enable) {
for (i = 0; i < MWIFIEX_NUM_MSIX_VECTORS; i++)
synchronize_irq(card->msix_entries[i].vector);
--
1.9.1
^ permalink raw reply related
* [PATCH 4.6 fix] bgmac: reset & enable Ethernet core before using it
From: Rafał Miłecki @ 2016-04-12 11:30 UTC (permalink / raw)
To: David S. Miller, netdev
Cc: Hauke Mehrtens, Rafał Miłecki, Felix Fietkau
This fixes Ethernet on D-Link DIR-885L with BCM47094 SoC. Felix reported
similar fix was needed for his BCM4709 device (Buffalo WXR-1900DHP?).
I tested this for regressions on BCM4706, BCM4708A0 and BCM47081A0.
Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
drivers/net/ethernet/broadcom/bgmac.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
index 99b30a9..38db2e4 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -1572,6 +1572,11 @@ static int bgmac_probe(struct bcma_device *core)
dev_warn(&core->dev, "Using random MAC: %pM\n", mac);
}
+ /* This (reset &) enable is not preset in specs or reference driver but
+ * Broadcom does it in arch PCI code when enabling fake PCI device.
+ */
+ bcma_core_enable(core, 0);
+
/* Allocation and references */
net_dev = alloc_etherdev(sizeof(*bgmac));
if (!net_dev)
--
1.8.4.5
^ permalink raw reply related
* Re: [PATCH 0/3] crypto: af_alg - add TLS type encryption
From: Fridolin Pokorny @ 2016-04-12 11:13 UTC (permalink / raw)
To: Tadeusz Struk
Cc: Tom Herbert, Herbert Xu, linux-crypto, LKML, David S. Miller,
Linux Kernel Network Developers, davejwatson, nmav,
fridolin.pokorny
In-Reply-To: <CALx6S37m_ayZJ4nth0SPNr2Km2+uBZUCtK4iqPKHTARv2eB4aA@mail.gmail.com>
On 08.04.2016 04:58, Tom Herbert wrote:
> On Thu, Apr 7, 2016 at 11:52 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>> On Wed, Apr 06, 2016 at 10:56:12AM -0700, Tadeusz Struk wrote:
>>>
>>> The intend is to enable HW acceleration of the TLS protocol.
>>> The way it will work is that the user space will send a packet of data
>>> via AF_ALG and HW will authenticate and encrypt it in one go.
>>
>> There have been suggestions to implement TLS data-path within
>> the kernel. So we should decide whether we pursue that or go
>> with your approach before we start adding algorithms.
>>
> Yes, please see Dave Watson's patches on this.
>
Hi Tadeusz,
we were experimenting with this. We have a prove of concept of a kernel
TLS type socket, so called AF_KTLS, which is based on Dave Watson's
RFC5288 patch. It handles both TLS and DTLS, unfortunately it is not
ready now to be proposed here. There are still issues which should be
solved (but mostly user space API design) [1]. If you are interested, we
could combine efforts.
Regards,
Fridolin Pokorny
[1] https://github.com/fridex/af_ktls
^ permalink raw reply
* [PATCH net-next v1 1/1] tipc: fix a race condition leading to subscriber refcnt bug
From: Parthasarathy Bhuvaragan @ 2016-04-12 11:05 UTC (permalink / raw)
To: netdev; +Cc: tipc-discussion
Until now, the requests sent to topology server are queued
to a workqueue by the generic server framework.
These messages are processed by worker threads and trigger the
registered callbacks.
To reduce latency on uniprocessor systems, explicit rescheduling
is performed using cond_resched() after MAX_RECV_MSG_COUNT(25)
messages.
This implementation on SMP systems leads to an subscriber refcnt
error as described below:
When a worker thread yields by calling cond_resched() in a SMP
system, a new worker is created on another CPU to process the
pending workitem. Sometimes the sleeping thread wakes up before
the new thread finishes execution.
This breaks the assumption on ordering and being single threaded.
The fault is more frequent when MAX_RECV_MSG_COUNT is lowered.
If the first thread was processing subscription create and the
second thread processing close(), the close request will free
the subscriber and the create request oops as follows:
[31.224137] WARNING: CPU: 2 PID: 266 at include/linux/kref.h:46 tipc_subscrb_rcv_cb+0x317/0x380 [tipc]
[31.228143] CPU: 2 PID: 266 Comm: kworker/u8:1 Not tainted 4.5.0+ #97
[31.228377] Workqueue: tipc_rcv tipc_recv_work [tipc]
[...]
[31.228377] Call Trace:
[31.228377] [<ffffffff812fbb6b>] dump_stack+0x4d/0x72
[31.228377] [<ffffffff8105a311>] __warn+0xd1/0xf0
[31.228377] [<ffffffff8105a3fd>] warn_slowpath_null+0x1d/0x20
[31.228377] [<ffffffffa0098067>] tipc_subscrb_rcv_cb+0x317/0x380 [tipc]
[31.228377] [<ffffffffa00a4984>] tipc_receive_from_sock+0xd4/0x130 [tipc]
[31.228377] [<ffffffffa00a439b>] tipc_recv_work+0x2b/0x50 [tipc]
[31.228377] [<ffffffff81071925>] process_one_work+0x145/0x3d0
[31.246554] ---[ end trace c3882c9baa05a4fd ]---
[31.248327] BUG: spinlock bad magic on CPU#2, kworker/u8:1/266
[31.249119] BUG: unable to handle kernel NULL pointer dereference at 0000000000000428
[31.249323] IP: [<ffffffff81099d0c>] spin_dump+0x5c/0xe0
[31.249323] PGD 0
[31.249323] Oops: 0000 [#1] SMP
In this commit, we
- rename tipc_conn_shutdown() to tipc_conn_release().
- move connection release callback execution from tipc_close_conn()
to a new function tipc_sock_release(), which is executed before
we free the connection.
Thus we release the subscriber during connection release procedure
rather than connection shutdown procedure.
Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
Acked-by: Ying Xue <ying.xue@windriver.com>
---
net/tipc/server.c | 19 +++++++++++++------
net/tipc/server.h | 4 ++--
net/tipc/subscr.c | 4 ++--
3 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/net/tipc/server.c b/net/tipc/server.c
index 2446bfbaa309..7a0af2dc0406 100644
--- a/net/tipc/server.c
+++ b/net/tipc/server.c
@@ -86,6 +86,7 @@ struct outqueue_entry {
static void tipc_recv_work(struct work_struct *work);
static void tipc_send_work(struct work_struct *work);
static void tipc_clean_outqueues(struct tipc_conn *con);
+static void tipc_sock_release(struct tipc_conn *con);
static void tipc_conn_kref_release(struct kref *kref)
{
@@ -102,6 +103,7 @@ static void tipc_conn_kref_release(struct kref *kref)
}
saddr->scope = -TIPC_NODE_SCOPE;
kernel_bind(sock, (struct sockaddr *)saddr, sizeof(*saddr));
+ tipc_sock_release(con);
sock_release(sock);
con->sock = NULL;
}
@@ -184,26 +186,31 @@ static void tipc_unregister_callbacks(struct tipc_conn *con)
write_unlock_bh(&sk->sk_callback_lock);
}
+static void tipc_sock_release(struct tipc_conn *con)
+{
+ struct tipc_server *s = con->server;
+
+ if (con->conid)
+ s->tipc_conn_release(con->conid, con->usr_data);
+
+ tipc_unregister_callbacks(con);
+}
+
static void tipc_close_conn(struct tipc_conn *con)
{
struct tipc_server *s = con->server;
if (test_and_clear_bit(CF_CONNECTED, &con->flags)) {
- if (con->conid)
- s->tipc_conn_shutdown(con->conid, con->usr_data);
spin_lock_bh(&s->idr_lock);
idr_remove(&s->conn_idr, con->conid);
s->idr_in_use--;
spin_unlock_bh(&s->idr_lock);
- tipc_unregister_callbacks(con);
-
/* We shouldn't flush pending works as we may be in the
* thread. In fact the races with pending rx/tx work structs
* are harmless for us here as we have already deleted this
- * connection from server connection list and set
- * sk->sk_user_data to 0 before releasing connection object.
+ * connection from server connection list.
*/
kernel_sock_shutdown(con->sock, SHUT_RDWR);
diff --git a/net/tipc/server.h b/net/tipc/server.h
index 9015faedb1b0..34f8055afa3b 100644
--- a/net/tipc/server.h
+++ b/net/tipc/server.h
@@ -53,7 +53,7 @@
* @send_wq: send workqueue
* @max_rcvbuf_size: maximum permitted receive message length
* @tipc_conn_new: callback will be called when new connection is incoming
- * @tipc_conn_shutdown: callback will be called when connection is shut down
+ * @tipc_conn_release: callback will be called before releasing the connection
* @tipc_conn_recvmsg: callback will be called when message arrives
* @saddr: TIPC server address
* @name: server name
@@ -70,7 +70,7 @@ struct tipc_server {
struct workqueue_struct *send_wq;
int max_rcvbuf_size;
void *(*tipc_conn_new)(int conid);
- void (*tipc_conn_shutdown)(int conid, void *usr_data);
+ void (*tipc_conn_release)(int conid, void *usr_data);
void (*tipc_conn_recvmsg)(struct net *net, int conid,
struct sockaddr_tipc *addr, void *usr_data,
void *buf, size_t len);
diff --git a/net/tipc/subscr.c b/net/tipc/subscr.c
index e6cb386fbf34..79de588c7bd6 100644
--- a/net/tipc/subscr.c
+++ b/net/tipc/subscr.c
@@ -302,7 +302,7 @@ static void tipc_subscrp_subscribe(struct net *net, struct tipc_subscr *s,
}
/* Handle one termination request for the subscriber */
-static void tipc_subscrb_shutdown_cb(int conid, void *usr_data)
+static void tipc_subscrb_release_cb(int conid, void *usr_data)
{
tipc_subscrb_delete((struct tipc_subscriber *)usr_data);
}
@@ -365,7 +365,7 @@ int tipc_topsrv_start(struct net *net)
topsrv->max_rcvbuf_size = sizeof(struct tipc_subscr);
topsrv->tipc_conn_recvmsg = tipc_subscrb_rcv_cb;
topsrv->tipc_conn_new = tipc_subscrb_connect_cb;
- topsrv->tipc_conn_shutdown = tipc_subscrb_shutdown_cb;
+ topsrv->tipc_conn_release = tipc_subscrb_release_cb;
strncpy(topsrv->name, name, strlen(name) + 1);
tn->topsrv = topsrv;
--
2.1.4
^ permalink raw reply related
* Inter-VRF routing on a single machine
From: Darwin Dingel @ 2016-04-12 10:09 UTC (permalink / raw)
To: netdev
Hi All,
Have anyone tried the following setup on a single machine with 2 TCP
sockets on different VRF's and succeeded?
- client_socket on VRF1
- server_socket on VRF2
- ip rules and iproutes for inter-VRF set up
- client_socket sends TCP connect to server_socket. skb was sent using
VRF1 interface
- skb received in loopback interface
- TCP code got SYN but cannot route back to VRF1 to send ACK.
I was wondering if this is a known limitation of VRF as of the moment,
or could work with proper iprules/iproute.
Thanks!
Darwin
^ permalink raw reply
* Re: [PATCH net-next WIP] ethtool: generic netlink policy
From: Johannes Berg @ 2016-04-12 10:01 UTC (permalink / raw)
To: Roopa Prabhu, netdev; +Cc: davem, jiri, eladr, idosch
In-Reply-To: <1460344545-45501-1-git-send-email-roopa@cumulusnetworks.com>
Hi,
> + [ETHTOOL_ATTR_FLAGS] = { .type = NLA_U32 },
I suppose this comes from the current API, but perhaps it'd be
worthwhile to make provision for more flags? Perhaps even using
NLA_BINARY and have "infinitely extensible" flags.
> + [ETHTOOL_ATTR_SSET_COUNT] = { .type = NLA_U32
What do you need that for? Wouldn't it be sufficient to count the SSET
values returned? I can see how this would be useful for ioctl, but not
really for netlink messages?
> +static struct genl_ops ethtool_ops[] = {
> + {
> + .cmd = ETHTOOL_CMD_GET_SETTINGS,
> + .policy = ethtool_policy,
> + .doit = ethtool_get_settings,
> + },
[...]
> + {
> + .cmd = ETHTOOL_CMD_SET_MODULE_INFO,
> + .policy = ethtool_policy,
> + .doit = ethtool_set_module_info,
> + },
> +};
Shouldn't the ops have GENL_ADMIN_PERM as flags?
> +int ethtool_get_settings(struct net_device *dev, struct ethtool_cmd
> *cmd)
> +{
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(ethtool_get_settings);
I don't understand what kind of placeholder this was meant to be - but
why would it be exported? This part is called by the genl ops, so
doesn't really make sense?
It seems that instead these functions should be static, declared above
the ops, and call into the existing ethtool driver ops, based on
IFINDEX demultiplexing.
> +void ethtool_get_ethtool_stats(struct net_device *dev,
> + struct ethtool_stats *stats,
> + u64 *data)
> +{
> +
> + /* example the driver handler would do the below
> + *
> + err = nla_put_u32(msg, PORT_ATTR_IFINDEX, ifindex);
> + if (err < 0)
> + goto err_out;
> +
> + err = nla_put_u32(msg, PORT_ATTR_FLAGS, flags);
> + if (err < 0)
> + goto err_out;
> +
> + err = nla_put_u32(msg, PORT_ATTR_SSET_COUNT,
> + count);
> + if (err < 0)
> + goto err_out;
> +
> + nest = nla_nest_start(msg, PORT_ATTR_STATS);
> + for (i = 0; i < count; i++)
> + nla_put_u64(msg, PORT_ATTR_STAT, data[i]);
> + nla_nest_end(msg, nest);
> +
> + */
> +}
> +EXPORT_SYMBOL_GPL(ethtool_get_ethtool_stats);
It seems possible that you could have a lot of ports, or a lot of
strings, or similar, so I think this should be a dumpit instead of a
doit handler.
Similar, perhaps, for the EEPROM thing, unless you provide API to query
the size first so the application can size it's recvmsg() buffer
appropriately - however doing so also requires a big message allocation
and more code in userspace, so I think having an "offset/length" type
of API combined with a dumpit rather than doit would be good for all of
the things that could get bigger or that might be extended in the
future.
johannes
^ permalink raw reply
* Re: [PATCH RFT 2/2] macb: kill PHY reset code
From: Nicolas Ferre @ 2016-04-12 9:23 UTC (permalink / raw)
To: Andrew Lunn, Sergei Shtylyov
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20160411185115.GA30623-g2DYL2Zd6BY@public.gmane.org>
Le 11/04/2016 20:51, Andrew Lunn a écrit :
> On Mon, Apr 11, 2016 at 09:39:02PM +0300, Sergei Shtylyov wrote:
>> Hello.
>>
>> On 04/11/2016 09:19 PM, Andrew Lunn wrote:
>>
>>>>> The code you are deleting would of ignored the flags in the gpio
>>>>> property, i.e. active low.
>>>>
>>>> Hm, you're right -- I forgot about that... :-/
>>>>
>>>>> The new code in the previous patch does
>>>>> however take the flags into account. Did you check if there are any
>>>>> device trees which have flags, which were never used, but are now
>>>>> going to be used and thus break...
>>>>
>>>> Checked this now and found out arch/arm/boot/dts/ar91-vinco.dts.
>>>> Looks like it needs to be fixed indeed...
>>>>
>>> And this is where it gets tricky. You are breaking backwards
>>> compatibility by now respecting the flag. An old DT blob is not going
>>> to work.
>>
>> Do we care that much about the DT blobs that are just *wrong*?
>
> Wrong, but currently works.
>
>>> You potentially need to add a new property and deprecate the old one.
>>
>> I would like to avoid that...
>
> You will need the agreement from the at91-vinco maintainer.
If the at91-vinco has to be modified, you have my agreement that it can
be modified.
Bye,
--
Nicolas Ferre
--
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 RFT 2/2] macb: kill PHY reset code
From: Nicolas Ferre @ 2016-04-12 9:22 UTC (permalink / raw)
To: Andrew Lunn, Sergei Shtylyov; +Cc: netdev, linux-kernel
In-Reply-To: <20160411022802.GB4307@lunn.ch>
Le 11/04/2016 04:28, Andrew Lunn a écrit :
> On Sat, Apr 09, 2016 at 01:25:03AM +0300, Sergei Shtylyov wrote:
>> With the 'phylib' now being aware of the "reset-gpios" PHY node property,
>> there should be no need to frob the PHY reset in this driver anymore...
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>
>> ---
>> drivers/net/ethernet/cadence/macb.c | 17 -----------------
>> drivers/net/ethernet/cadence/macb.h | 1 -
>> 2 files changed, 18 deletions(-)
>>
>> Index: net-next/drivers/net/ethernet/cadence/macb.c
>> ===================================================================
>> --- net-next.orig/drivers/net/ethernet/cadence/macb.c
>> +++ net-next/drivers/net/ethernet/cadence/macb.c
>> @@ -2884,7 +2884,6 @@ static int macb_probe(struct platform_de
>> = macb_clk_init;
>> int (*init)(struct platform_device *) = macb_init;
>> struct device_node *np = pdev->dev.of_node;
>> - struct device_node *phy_node;
>> const struct macb_config *macb_config = NULL;
>> struct clk *pclk, *hclk = NULL, *tx_clk = NULL;
>> unsigned int queue_mask, num_queues;
>> @@ -2977,18 +2976,6 @@ static int macb_probe(struct platform_de
>> else
>> macb_get_hwaddr(bp);
>>
>> - /* Power up the PHY if there is a GPIO reset */
>> - phy_node = of_get_next_available_child(np, NULL);
>> - if (phy_node) {
>> - int gpio = of_get_named_gpio(phy_node, "reset-gpios", 0);
>> -
>> - if (gpio_is_valid(gpio)) {
>> - bp->reset_gpio = gpio_to_desc(gpio);
>> - gpiod_direction_output(bp->reset_gpio, 1);
>
> Hi Sergei
>
> The code you are deleting would of ignored the flags in the gpio
I don't parse this.
The code deleted does take the flag into account. And the DT property
associated to it seems correct to me (I mean, with proper flag
specification).
> property, i.e. active low. The new code in the previous patch does
> however take the flags into account. Did you check if there are any
> device trees which have flags, which were never used, but are now
> going to be used and thus break...
Flag was used and you are saying that it's taken into account in new
code... So, what's the issue?
I see a difference in the way the "value" of gpiod_* functions is used.
There may be a misunderstanding here...
Bye,
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH for-next 2/2] net/mlx5: Update mlx5_ifc hardware features
From: Or Gerlitz @ 2016-04-12 9:13 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Leon Romanovsky, Saeed Mahameed, Matan Barak, Linux Netdev List,
linux-rdma@vger.kernel.org, David S. Miller, Doug Ledford,
Linus Torvalds, Or Gerlitz, Leon Romanovsky, Tal Alon
In-Reply-To: <CALzJLG8fXPLQ7tj2Nc7NbGpu4EuNoXTE+w8tDkwQ2F_AqgDtLA@mail.gmail.com>
On Tue, Apr 12, 2016 at 10:40 AM, Saeed Mahameed
<saeedm@dev.mellanox.co.il> wrote:
> Why would you break down this patch to many when no matter what you
> do, at the end it would look the same ?
> As Leon mentioned we MLNX maintainers prefer to update this file at
> once when possible.
See my response to Leon. It happened to me many times in code review
that people gave
me patches that open X fields in the IFC file and their code used Y <<
X fields. I don't
want the IFC file to have even one unused field, and I think the
correct way to do that
is have both the IFC file and the driver changes in the same series. I
understand the trend
to have zero-conflicts, lets try that. Did you make sure all exposed
IFC fields are used?
Or.
^ permalink raw reply
* Re: [PATCH for-next 2/2] net/mlx5: Update mlx5_ifc hardware features
From: Or Gerlitz @ 2016-04-12 9:09 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Saeed Mahameed, Saeed Mahameed, Matan Barak, Linux Netdev List,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David S. Miller, Doug Ledford, Linus Torvalds, Or Gerlitz,
Leon Romanovsky, Tal Alon
In-Reply-To: <20160412060117.GA24649-2ukJVAZIZ/Y@public.gmane.org>
On Tue, Apr 12, 2016 at 9:01 AM, Leon Romanovsky <leon-2ukJVAZIZ/Y@public.gmane.org> wrote:
> On Tue, Apr 12, 2016 at 08:36:21AM +0300, Or Gerlitz wrote:
>> Conflicts happens @ all times, life.
>> I understand your desire to get it down to zero, but it's not gonna
>> work, pick another target.
> Maybe you are right and the time will show, but now we (Saeed, Matan and me)
> are trying hard to achieve this goal.
going with your approach, next you are going to define a goal of no RC time
conflicts between rdma and net, and this will slow down the already
terribly slow
(no 4.6 net mlx5 rc patches so far) process even further.
>> For example, the networking community has a fairly large rc activity
>> (I would say 10-20x
>> vs rdma), so when Dave does his "merge-rebases" for net-next over net
>> and linus tree
>> (4-5 times in a release), he has to this way or another solve
>> conflicts, yes! ditto for
>> Linus during merge windows and to some extent in rc times too.
> I don't see any harm in our desire to decrease work overhead from these
> busy people.
Desire is one thing, you took it too further to my taste.
>> > It won't help to anyone to split this commit to more than one patch.
>> The commit change-log should make it clear what this is about, and it doesn't.
>> If you believe in something, state that clear, be precise.
> I agree.
good, so please do that in the respin
>> As Saeed admitted the shared code in the commit spans maybe 2% of it.
>> The 1st commit deals with a field which is not used in the driver,
>> this is a cleanup
>> that you can do in rc (net) patch (remove the field all together) and
>> overall, w.o seeing
> I don't agree with your point that cleanup should go to RC.
>> the down-stream patches that depend on the newly introduced fields,
>> how do you know there aren't such (unused) bits in the 2nd commit?
> No, I don't know in advance, but the truth is that it doesn't bother
> anyone, because we are exposing our internal HW to kernel clients and
> doing it with minimal impact on the maintainers.
this is not the internal HW, it's the FW API and the FW API is stabilized
together with implementing the feature in the driver. We must not expose
unused fields since they might change/move or be eliminated as part of
the driver implementation and this creates extra noise and burden for other
developers and maintainers. The 1st patch should change to be elimination
of these two fields (cqe_zip_xxx and early VF enable) b/c they are not
used in the code.
Or.
--
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: Configuring ethernet link fails with No such device
From: Bob Ham @ 2016-04-12 8:58 UTC (permalink / raw)
To: Stefan Agner, systemd-devel, netdev, davem
Cc: fabio.estevam, bryan.wu, u.kleine-koenig, l.stach
In-Reply-To: <67b662523c63277fa95a59472cbf018f@agner.ch>
On Mon, 2016-04-11 at 15:46 -0700, Stefan Agner wrote:
> The FEC driver (fec_main.c) does not initialize phy_dev until the
> device
> has been opened, and therefor the callback
> fec_enet_(get|set)_settings
> returns -19.
I saw the same problem with the FEC driver. From what I recall, it
became clear that there was a problem with the driver returning from
the eth device initialisation before the PHY was initialised, which
apparently is Bad and Wrong.
> Or in other words: Is this a Kernel or systemd issue?
From what I recall, both; an issue with the FEC driver, and issues in
systemd/udevd's handling of link-level settings.
--
Bob Ham <bob.ham@collabora.com>
Software Engineer
>>>>>>>>
Open First
Collabora is hiring!
Please check out our latest opportunities here:
http://bit.ly/Collabora-Careers
<<<<<<<<
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
^ permalink raw reply
* Re: [RFC PATCH 0/2] selinux: avoid nf hooks overhead when not needed
From: Paolo Abeni @ 2016-04-12 8:52 UTC (permalink / raw)
To: Paul Moore
Cc: Florian Westphal, linux-security-module, David S. Miller,
James Morris, Andreas Gruenbacher, Stephen Smalley, netdev,
selinux
In-Reply-To: <2239567.jkCk1gtQAE@sifl>
On Thu, 2016-04-07 at 14:55 -0400, Paul Moore wrote:
> On Thursday, April 07, 2016 01:45:32 AM Florian Westphal wrote:
> > Paul Moore <paul@paul-moore.com> wrote:
> > > On Wed, Apr 6, 2016 at 6:14 PM, Florian Westphal <fw@strlen.de> wrote:
> > > > netfilter hooks are per namespace -- so there is hook unregister when
> > > > netns is destroyed.
> > >
> > > Looking around, I see the global and per-namespace registration
> > > functions (nf_register_hook and nf_register_net_hook, respectively),
> > > but I'm looking to see if/how newly created namespace inherit
> > > netfilter hooks from the init network namespace ... if you can create
> > > a network namespace and dodge the SELinux hooks, that isn't a good
> > > thing from a SELinux point of view, although it might be a plus
> > > depending on where you view Paolo's original patches ;)
> >
> > Heh :-)
> >
> > If you use nf_register_net_hook, the hook is only registered in the
> > namespace.
> >
> > If you use nf_register_hook, the hook is put on a global list and
> > registed in all existing namespaces.
> >
> > New namespaces will have the hook added as well (see
> > netfilter_net_init -> nf_register_hook_list in netfilter/core.c )
> >
> > Since nf_register_hook is used it should be impossible to get a netns
> > that doesn't call these hooks.
>
> Great, thanks.
>
> > > > Do you think it makes sense to rework the patch to delay registering
> > > > of the netfiler hooks until the system is in a state where they're
> > > > needed, without the 'unregister' aspect?
> > >
> > > I would need to see the patch to say for certain, but in principle
> > > that seems perfectly reasonable and I think would satisfy both the
> > > netdev and SELinux camps - good suggestion. My main goal is to drop
> > > the selinux_nf_ip_init() entirely so it can't be used as a ROP gadget.
> > >
> > > We might even be able to trim the secmark_active and peerlbl_active
> > > checks in the SELinux netfilter hooks (an earlier attempt at
> > > optimization; contrary to popular belief, I do care about SELinux
> > > performance), although that would mean that enabling the network
> > > access controls would be one way ... I guess you can disregard that
> > > last bit, I'm thinking aloud again.
> >
> > One way is fine I think.
>
> Yes, just disregard my second paragraph above.
>
> > > > Ideally this would even be per netns -- in perfect world we would
> > > > be able to make it so that a new netns are created with an empty
> > > > hook list.
> > >
> > > In general SELinux doesn't care about namespaces, for reasons that are
> > > sorta beyond the scope of this conversation, so I would like to stick
> > > to a all or nothing approach to enabling the SELinux netfilter hooks
> > > across namespaces. Perhaps we can revisit this at a later time, but
> > > let's keep it simple right now.
> >
> > Okay, I'd prefer to stick to your recommendation anyway wrt. to selinux
> > (Casey, I read your comment regarding smack. Noted, we don't want to
> > break smack either...)
> >
> > I think that in this case the entire question is:
> >
> > In your experience, how likely is a config where selinux is enabled BUT the
> > hooks are not needed (i.e., where we hit the
> >
> > if (!selinux_policycap_netpeer)
> > return NF_ACCEPT;
> >
> > if (!secmark_active && !peerlbl_active)
> > return NF_ACCEPT;
> >
> > tests inside the hooks)? If such setups are uncommon we should just
> > drop this idea or at least put it on the back burner until the more
> > expensive netfilter hooks (conntrack, cough) are out of the way.
>
> A few years ago I would have said that it is relatively uncommon for admins to
> enable the SELinux network access controls; it was typically just
> government/intelligence agencies who had very strict access control
> requirements and represented a small portion of SELinux users. However, over
> the past few years I've been fielding more and more questions from admins/devs
> in the virtualization space who are interested in some of these capabilities;
> it isn't clear to me how many of these people are switching it on, but there
> is definitely more interest than I have seen in the past and the interested is
> centered around some rather common use cases.
>
> So, to summarize, I don't know ;)
>
> If you've got bigger sources of overhead, my opinion would be to go tackle
> those first. Perhaps I can even find the time to work on the
> SELinux/netfilter stuff while you are off slaying the bigger dragons, no
> promises at the moment.
Double checking if I got the above correctly.
Will be ok if we post a v2 version of this series, removing the hooks
de-registration bits, but preserving the selinux nf-hooks and
socket_sock_rcv_skb() on-demand/delayed registration ? Will that fit
with the post-init read only memory usage that you are planning ?
Regards,
Paolo
^ permalink raw reply
* RE: [PATCH net-next 00/11] FUJITSU Extended Socket driver version 1.1
From: Izumi, Taku @ 2016-04-12 8:35 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20160411.115617.2124648532876219571.davem@davemloft.net>
Dear David and Jiri,
Thank you for reviewing!
> This submission is of an extremely low quality.
>
> All of your ioctl additions are completely inappropriate, as are your
> debugfs facilities. You must remove all of them completely.
OK, I'll remove ioctl part. But I'd like to keep some debugfs facility
for status information and some specific stats other thatn net_stats.
Are you okay with this ?
Sincerely,
Taku Izumi
^ permalink raw reply
* pull request: bluetooth-next 2016-04-12
From: Johan Hedberg @ 2016-04-12 8:08 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]
Hi Dave,
Here's a set of Bluetooth & 802.15.4 patches intended for the 4.7 kernel:
- Fix for race condition in vhci driver
- Memory leak fix for ieee802154/adf7242 driver
- Improvements to deal with single-mode (LE-only) Bluetooth controllers
- Fix for allowing the BT_SECURITY_FIPS security level
- New BCM2E71 ACPI ID
- NULL pointer dereference fix fox hci_ldisc driver
Let me know if there are any issues pulling. Thanks.
Johan
----
The following changes since commit 9ef280c6c28f0c01aa9d909263ad47c796713a8e:
irda: sh_irda: remove driver (2016-04-04 16:24:13 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git for-upstream
for you to fetch changes up to 8805eea2494a2837983bc4aaaf6842c89666ec25:
Bluetooth: hci_bcsp: fix code style (2016-04-08 23:01:36 +0200)
----------------------------------------------------------------
Alexander Aring (1):
6lowpan: iphc: fix handling of link-local compression
Jiri Slaby (2):
Bluetooth: vhci: fix open_timeout vs. hdev race
Bluetooth: vhci: purge unhandled skbs
Johan Hedberg (2):
Bluetooth: Fix setting NO_BREDR advertising flag
Bluetooth: Ignore unknown advertising packet types
Loic Poulain (2):
Bluetooth: hci_bcm: Add BCM2E71 ACPI ID
Bluetooth: hci_ldisc: Fix null pointer derefence in case of early data
Maxim Zhukov (1):
Bluetooth: hci_bcsp: fix code style
Patrik Flykt (1):
Bluetooth: Allow setting BT_SECURITY_FIPS with setsockopt
Sudip Mukherjee (1):
ieee802154/adf7242: fix memory leak of firmware
drivers/bluetooth/hci_bcm.c | 1 +
drivers/bluetooth/hci_bcsp.c | 57 +++++++++++++++++++++++++++++++--------------------------
drivers/bluetooth/hci_ldisc.c | 11 +++++++----
drivers/bluetooth/hci_uart.h | 1 +
drivers/bluetooth/hci_vhci.c | 9 ++++++---
drivers/net/ieee802154/adf7242.c | 2 ++
net/6lowpan/iphc.c | 11 +++++++++--
net/bluetooth/hci_event.c | 13 +++++++++++++
net/bluetooth/hci_request.c | 6 +++---
net/bluetooth/l2cap_sock.c | 2 +-
10 files changed, 74 insertions(+), 39 deletions(-)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH for-next 2/2] net/mlx5: Update mlx5_ifc hardware features
From: Saeed Mahameed @ 2016-04-12 7:40 UTC (permalink / raw)
To: leon
Cc: Or Gerlitz, Saeed Mahameed, Matan Barak, Linux Netdev List,
linux-rdma@vger.kernel.org, David S. Miller, Doug Ledford,
Linus Torvalds, Or Gerlitz, Leon Romanovsky, Tal Alon
In-Reply-To: <20160412060117.GA24649@leon.nu>
On Tue, Apr 12, 2016 at 9:01 AM, Leon Romanovsky <leon@leon.nu> wrote:
> On Tue, Apr 12, 2016 at 08:36:21AM +0300, Or Gerlitz wrote:
>>
>> I understand your desire to get it down to zero, but it's not gonna
>> work, pick another target.
>
> Maybe you are right and the time will show, but now we (Saeed, Matan and me)
> are trying hard to achieve this goal.
>
>>
>> For example, the networking community has a fairly large rc activity
>> (I would say 10-20x
>> vs rdma), so when Dave does his "merge-rebases" for net-next over net
>> and linus tree
>> (4-5 times in a release), he has to this way or another solve
>> conflicts, yes! ditto for
>> Linus during merge windows and to some extent in rc times too.
>
> I don't see any harm in our desire to decrease work overhead from these
> busy people.
>
>>
>> > It won't help to anyone to split this commit to more than one patch.
>>
>> The commit change-log should make it clear what this is about, and it doesn't.
>> If you believe in something, state that clear, be precise.
>
> I agree.
>
>>
>> As Saeed admitted the shared code in the commit spans maybe 2% of it.
>>
>> The 1st commit deals with a field which is not used in the driver,
>> this is a cleanup
>> that you can do in rc (net) patch (remove the field all together) and
>> overall, w.o seeing
Or, I guess everybody here agrees that mlx5_ifc is our Connectx-4 pure
HW spec, written in C, isn't that cool ?
I see no harm updating our HW spec once in a kernel cycle revealing
new cool HW bits and interfaces
for anyone to use mlx5e/mlx5_core/mlx5_ib .. you name it.
Why would you break down this patch to many when no matter what you
do, at the end it would look the same ?
As Leon mentioned we MLNX maintainers prefer to update this file at
once when possible.
>
> I don't agree with your point that cleanup should go to RC.
I am with Leon on this one, the cleanup code is just cleanup for new
features to come,
it has nothing to do with RC (net).
>
>> the down-stream patches that depend on the newly introduced fields,
>> how do you know there aren't such (unused) bits in the 2nd commit?
>
> No, I don't know in advance, but the truth is that it doesn't bother
> anyone, because we are exposing our internal HW to kernel clients and
> doing it with minimal impact on the maintainers.
Yep, this is exactly what i am trying to say, there are no two ways to
describe/write (mlx5_ifc) code,
if it is a HW spec, why shouldn't it appear from day one ?
^ permalink raw reply
* Re: Configuring ethernet link fails with No such device
From: Stefan Agner @ 2016-04-12 7:25 UTC (permalink / raw)
To: David Miller
Cc: systemd-devel, netdev, fabio.estevam, l.stach, u.kleine-koenig,
bryan.wu, bob.ham
In-Reply-To: <20160411.212900.1164760179761034053.davem@davemloft.net>
On 2016-04-11 18:29, David Miller wrote:
> From: Stefan Agner <stefan@agner.ch>
> Date: Mon, 11 Apr 2016 15:46:08 -0700
>
>> What is the expectation/definition when link configuration should be
>> possible? Only after the network device got opened or before?
>
> Only after it is open. Drivers almost always have the entire chip in
> powerdown state when it is not open, so we wouldn't be able to
> properly do link settings even if we wanted to when the device is
> closed.
I see. Afact it is a udev rule which triggers the built-in link setup
code:
https://github.com/systemd/systemd/blob/09541e49ebd17b41482e447dd8194942f39788c0/rules/80-net-setup-link.rules
The udev rule is triggering on action add (=> probe on driver level). At
least on the device I tested, it seems that there is no event on open...
Any other ideas what could be used as trigger to configure the link?
^ permalink raw reply
* [PATCH net v3] net: sched: do not requeue a NULL skb
From: Lars Persson @ 2016-04-12 6:45 UTC (permalink / raw)
To: netdev; +Cc: jhs, linux-kernel, xiyou.wangcong, eric.dumazet, Lars Persson
A failure in validate_xmit_skb_list() triggered an unconditional call
to dev_requeue_skb with skb=NULL. This slowly grows the queue
discipline's qlen count until all traffic through the queue stops.
We take the optimistic approach and continue running the queue after a
failure since it is unknown if later packets also will fail in the
validate path.
Fixes: 55a93b3ea780 ("qdisc: validate skb without holding lock")
Signed-off-by: Lars Persson <larper@axis.com>
---
v3: After a discussion with Eric and Cong I went back to v1 and added the
likely() for the common path.
---
net/sched/sch_generic.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index f18c350..80742ed 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -159,12 +159,15 @@ int sch_direct_xmit(struct sk_buff *skb, struct Qdisc *q,
if (validate)
skb = validate_xmit_skb_list(skb, dev);
- if (skb) {
+ if (likely(skb)) {
HARD_TX_LOCK(dev, txq, smp_processor_id());
if (!netif_xmit_frozen_or_stopped(txq))
skb = dev_hard_start_xmit(skb, dev, txq, &ret);
HARD_TX_UNLOCK(dev, txq);
+ } else {
+ spin_lock(root_lock);
+ return qdisc_qlen(q);
}
spin_lock(root_lock);
--
2.1.4
^ permalink raw reply related
* [PATCH V3] net: mediatek: update the IRQ part of the binding document
From: John Crispin @ 2016-04-12 6:35 UTC (permalink / raw)
To: David S. Miller
Cc: Felix Fietkau, Matthias Brugger, netdev, linux-mediatek,
linux-kernel, John Crispin, devicetree
The current binding document only describes a single interrupt. Update the
document by adding the 2 other interrupts.
The driver currently only uses a single interrupt. The HW is however able
to using IRQ grouping to split TX and RX onto separate GIC irqs.
Signed-off-by: John Crispin <blogic@openwrt.org>
Cc: devicetree@vger.kernel.org
---
This binding doc was merged in 4.6-rc1 and there are no users yet. The
current driver only uses 1 irq but will work fine with all 3 listed in
the devicetree. This patch should be merged before v4.6 is final such
that listing all 3 irqs becomes part of the ABI. I have already posted
a patch that utilizes all 3 irqs for next-next for v4.7 inclusion.
Changes in V3:
* be verbose about the 3 irqs and their ordering
Changes in V2:
* split this patch out of the series that fixes tx stalls in the driver
Documentation/devicetree/bindings/net/mediatek-net.txt | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt b/Documentation/devicetree/bindings/net/mediatek-net.txt
index 5ca7929..32eaaca 100644
--- a/Documentation/devicetree/bindings/net/mediatek-net.txt
+++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
@@ -9,7 +9,8 @@ have dual GMAC each represented by a child node..
Required properties:
- compatible: Should be "mediatek,mt7623-eth"
- reg: Address and length of the register set for the device
-- interrupts: Should contain the frame engines interrupt
+- interrupts: Should contain the three frame engines interrupts in numeric
+ order. These are fe_int0, fe_int1 and fe_int2.
- clocks: the clock used by the core
- clock-names: the names of the clock listed in the clocks property. These are
"ethif", "esw", "gp2", "gp1"
@@ -42,7 +43,9 @@ eth: ethernet@1b100000 {
<ðsys CLK_ETHSYS_GP2>,
<ðsys CLK_ETHSYS_GP1>;
clock-names = "ethif", "esw", "gp2", "gp1";
- interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_LOW>;
+ interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_LOW
+ GIC_SPI 199 IRQ_TYPE_LEVEL_LOW
+ GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&scpsys MT2701_POWER_DOMAIN_ETH>;
resets = <ðsys MT2701_ETHSYS_ETH_RST>;
reset-names = "eth";
--
1.7.10.4
^ permalink raw reply related
* DONATION !!!
From: Ally Mohammed @ 2016-04-07 12:06 UTC (permalink / raw)
To: Recipients
This Message is directed to you from Saudi Arabia Prince Alwaleed bin Talal for his charity donation and You have been selected as recipient/benefactor for $2.5 Million Dollars from Prince Alwaleed Philanthropic Foundation Grant. For more information contact rebeccabill@careceo.com
Thanks
Ally Mohammed
^ permalink raw reply
* Re: [Lsf] [Lsf-pc] [LSF/MM TOPIC] Generic page-pool recycle facility?
From: Jesper Dangaard Brouer @ 2016-04-12 6:28 UTC (permalink / raw)
To: Alexander Duyck
Cc: lsf@lists.linux-foundation.org, James Bottomley, Sagi Grimberg,
Tom Herbert, Brenden Blanco, Christoph Hellwig, linux-mm,
netdev@vger.kernel.org, Bart Van Assche,
lsf-pc@lists.linux-foundation.org, Alexei Starovoitov, brouer
In-Reply-To: <CAKgT0UdbO00-Pe3xdrCC2T8L=XVZasWSQQVzTTs9r521RDes+Q@mail.gmail.com>
On Mon, 11 Apr 2016 15:02:51 -0700 Alexander Duyck <alexander.duyck@gmail.com> wrote:
> Have you taken a look at possibly trying to optimize the DMA pool API
> to work with pages? It sounds like it is supposed to do something
> similar to what you are wanting to do.
Yes, I have looked at the mm/dmapool.c API. AFAIK this is for DMA
coherent memory (see use of dma_alloc_coherent/dma_free_coherent).
What we are doing is "streaming" DMA memory, when processing the RX
ring.
(NIC are only using DMA coherent memory for the descriptors, which are
allocated on driver init)
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [Lsf] [Lsf-pc] [LSF/MM TOPIC] Generic page-pool recycle facility?
From: Jesper Dangaard Brouer @ 2016-04-12 6:16 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: lsf@lists.linux-foundation.org, James Bottomley, Sagi Grimberg,
Tom Herbert, Brenden Blanco, Christoph Hellwig, linux-mm,
netdev@vger.kernel.org, Bart Van Assche,
lsf-pc@lists.linux-foundation.org, brouer
In-Reply-To: <20160411222124.GA80595@ast-mbp.thefacebook.com>
On Mon, 11 Apr 2016 15:21:26 -0700
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> On Mon, Apr 11, 2016 at 11:41:57PM +0200, Jesper Dangaard Brouer wrote:
> >
> > On Sun, 10 Apr 2016 21:45:47 +0300 Sagi Grimberg <sagi@grimberg.me> wrote:
> >
[...]
> > >
> > > If we go down this road how about also attaching some driver opaques
> > > to the page sets?
> >
> > That was the ultimate plan... to leave some opaques bytes left in the
> > page struct that drivers could use.
> >
> > In struct page I would need a pointer back to my page_pool struct and a
> > page flag. Then, I would need room to store the dma_unmap address.
> > (And then some of the usual fields are still needed, like the refcnt,
> > and reusing some of the list constructs). And a zero-copy cross-domain
> > id.
>
> I don't think we need to add anything to struct page.
> This is supposed to be small cache of dma_mapped pages with lockless access.
> It can be implemented as an array or link list where every element
> is dma_addr and pointer to page. If it is full, dma_unmap_page+put_page to
> send it to back to page allocator.
It sounds like the Intel drivers recycle facility, where they split the
page into two parts, and keep page in RX-ring, by swapping to other
half of page, if page_count(page) is <= 2. Thus, they use the atomic
page ref count to synchronize on.
Thus, we end-up having two atomic operations per RX packet, on the page
refcnt. Where DPDK have zero...
By fully taking over the page as an allocator, almost like slab. I can
optimize the common case (of the packet-page getting allocated and
free'ed on the same CPU), and remove these atomic operations.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH for-next 2/2] net/mlx5: Update mlx5_ifc hardware features
From: Leon Romanovsky @ 2016-04-12 6:01 UTC (permalink / raw)
To: Or Gerlitz
Cc: Saeed Mahameed, Saeed Mahameed, Matan Barak, Linux Netdev List,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David S. Miller, Doug Ledford, Linus Torvalds, Or Gerlitz,
Leon Romanovsky, Tal Alon
In-Reply-To: <CAJ3xEMijYrLvSmbNZp0B6AXqKGozz1rdZ58SCUP_09zOB6-2gQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]
On Tue, Apr 12, 2016 at 08:36:21AM +0300, Or Gerlitz wrote:
> Conflicts happens @ all times, life.
>
...
>
> I understand your desire to get it down to zero, but it's not gonna
> work, pick another target.
Maybe you are right and the time will show, but now we (Saeed, Matan and me)
are trying hard to achieve this goal.
>
> For example, the networking community has a fairly large rc activity
> (I would say 10-20x
> vs rdma), so when Dave does his "merge-rebases" for net-next over net
> and linus tree
> (4-5 times in a release), he has to this way or another solve
> conflicts, yes! ditto for
> Linus during merge windows and to some extent in rc times too.
I don't see any harm in our desire to decrease work overhead from these
busy people.
>
> > It won't help to anyone to split this commit to more than one patch.
>
> The commit change-log should make it clear what this is about, and it doesn't.
> If you believe in something, state that clear, be precise.
I agree.
>
> As Saeed admitted the shared code in the commit spans maybe 2% of it.
>
> The 1st commit deals with a field which is not used in the driver,
> this is a cleanup
> that you can do in rc (net) patch (remove the field all together) and
> overall, w.o seeing
I don't agree with your point that cleanup should go to RC.
> the down-stream patches that depend on the newly introduced fields,
> how do you know there aren't such (unused) bits in the 2nd commit?
No, I don't know in advance, but the truth is that it doesn't bother
anyone, because we are exposing our internal HW to kernel clients and
doing it with minimal impact on the maintainers.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ 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