* [PATCH 2/2] net: ethernet: ti: cpsw: fix runtime_pm while add/kill vlan
From: Ivan Khoronzhuk @ 2018-08-10 12:47 UTC (permalink / raw)
To: grygorii.strashko, davem
Cc: linux-omap, netdev, linux-kernel, Ivan Khoronzhuk
In-Reply-To: <20180810124709.25089-1-ivan.khoronzhuk@linaro.org>
It's exclusive with normal behaviour but if try to set vlan to one of
the reserved values is made, the cpsw runtime pm is broken.
Fixes: commit a6c5d14f5136
("drivers: net: cpsw: ndev: fix accessing to suspended device")
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
drivers/net/ethernet/ti/cpsw.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 9edac671f276..3e34cb8ac1d3 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2086,14 +2086,16 @@ static int cpsw_ndo_vlan_rx_add_vid(struct net_device *ndev,
int i;
for (i = 0; i < cpsw->data.slaves; i++) {
- if (vid == cpsw->slaves[i].port_vlan)
- return -EINVAL;
+ if (vid == cpsw->slaves[i].port_vlan) {
+ ret = -EINVAL;
+ goto err;
+ }
}
}
dev_info(priv->dev, "Adding vlanid %d to vlan filter\n", vid);
ret = cpsw_add_vlan_ale_entry(priv, vid);
-
+err:
pm_runtime_put(cpsw->dev);
return ret;
}
@@ -2119,7 +2121,7 @@ static int cpsw_ndo_vlan_rx_kill_vid(struct net_device *ndev,
for (i = 0; i < cpsw->data.slaves; i++) {
if (vid == cpsw->slaves[i].port_vlan)
- return -EINVAL;
+ goto err;
}
}
@@ -2129,6 +2131,7 @@ static int cpsw_ndo_vlan_rx_kill_vid(struct net_device *ndev,
HOST_PORT_NUM, ALE_VLAN, vid);
ret |= cpsw_ale_del_mcast(cpsw->ale, priv->ndev->broadcast,
0, ALE_VLAN, vid);
+err:
pm_runtime_put(cpsw->dev);
return ret;
}
--
2.17.1
^ permalink raw reply related
* [PATCH 1/2] net: ethernet: ti: cpsw: clear all entries when delete vid
From: Ivan Khoronzhuk @ 2018-08-10 12:47 UTC (permalink / raw)
To: grygorii.strashko, davem
Cc: linux-omap, netdev, linux-kernel, Ivan Khoronzhuk
In-Reply-To: <20180810124709.25089-1-ivan.khoronzhuk@linaro.org>
In cases if some of the entries were not found in forwarding table
while killing vlan, the rest not needed entries still left in the
table. No need to stop, as entry was deleted anyway. So fix this by
returning error only after all was cleaned. To implement this, return
-ENOENT in cpsw_ale_del_mcast() as it's supposed to be.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
drivers/net/ethernet/ti/cpsw.c | 14 ++++----------
drivers/net/ethernet/ti/cpsw_ale.c | 2 +-
2 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 358edab9e72e..9edac671f276 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2125,16 +2125,10 @@ static int cpsw_ndo_vlan_rx_kill_vid(struct net_device *ndev,
dev_info(priv->dev, "removing vlanid %d from vlan filter\n", vid);
ret = cpsw_ale_del_vlan(cpsw->ale, vid, 0);
- if (ret != 0)
- return ret;
-
- ret = cpsw_ale_del_ucast(cpsw->ale, priv->mac_addr,
- HOST_PORT_NUM, ALE_VLAN, vid);
- if (ret != 0)
- return ret;
-
- ret = cpsw_ale_del_mcast(cpsw->ale, priv->ndev->broadcast,
- 0, ALE_VLAN, vid);
+ ret |= cpsw_ale_del_ucast(cpsw->ale, priv->mac_addr,
+ HOST_PORT_NUM, ALE_VLAN, vid);
+ ret |= cpsw_ale_del_mcast(cpsw->ale, priv->ndev->broadcast,
+ 0, ALE_VLAN, vid);
pm_runtime_put(cpsw->dev);
return ret;
}
diff --git a/drivers/net/ethernet/ti/cpsw_ale.c b/drivers/net/ethernet/ti/cpsw_ale.c
index 93dc05c194d3..5766225a4ce1 100644
--- a/drivers/net/ethernet/ti/cpsw_ale.c
+++ b/drivers/net/ethernet/ti/cpsw_ale.c
@@ -394,7 +394,7 @@ int cpsw_ale_del_mcast(struct cpsw_ale *ale, u8 *addr, int port_mask,
idx = cpsw_ale_match_addr(ale, addr, (flags & ALE_VLAN) ? vid : 0);
if (idx < 0)
- return -EINVAL;
+ return -ENOENT;
cpsw_ale_read(ale, idx, ale_entry);
--
2.17.1
^ permalink raw reply related
* [PATCH 0/2] net: ethernet: ti: cpsw: fix runtime pm while add/del reserved vid
From: Ivan Khoronzhuk @ 2018-08-10 12:47 UTC (permalink / raw)
To: grygorii.strashko, davem
Cc: linux-omap, netdev, linux-kernel, Ivan Khoronzhuk
Here 2 not critical fixes for:
- vlan ale table leak while error if deleting vlan (simplifies next fix)
- runtime pm while try to set reserved vlan
Based on net/master
Ivan Khoronzhuk (2):
net: ethernet: ti: cpsw: clear all entries when delete vid
net: ethernet: ti: cpsw: fix runtime_pm while add/kill vlan
drivers/net/ethernet/ti/cpsw.c | 25 +++++++++++--------------
drivers/net/ethernet/ti/cpsw_ale.c | 2 +-
2 files changed, 12 insertions(+), 15 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: [PATCH 4.9-stable] tcp: add tcp_ooo_try_coalesce() helper
From: maowenan @ 2018-08-10 10:10 UTC (permalink / raw)
To: David Woodhouse, Greg KH
Cc: davem, edumazet, juha-matti.tilli, ycheng, soheil, netdev,
eric.dumazet, jdw
In-Reply-To: <1eb36303-c713-a517-735b-da1cd8343712@huawei.com>
On 2018/8/10 14:26, maowenan wrote:
>
>
> On 2018/8/9 20:52, David Woodhouse wrote:
>> On Thu, 2018-08-09 at 14:47 +0200, Greg KH wrote:
>>> On Thu, Aug 09, 2018 at 08:37:13PM +0800, maowenan wrote:
>>>> There are two patches in stable branch linux-4.4, but I have tested with below patches, and found that the cpu usage was very high.
>>>> dc6ae4d tcp: detect malicious patterns in tcp_collapse_ofo_queue()
>>>> 5fbec48 tcp: avoid collapses in tcp_prune_queue() if possible
>>>>
>>>> test results:
>>>> with fix patch： 78.2% ksoftirqd
>>>> no fix patch： 90% ksoftirqd
>>>>
>>>> there is %0 when no attack packets.
>>>>
>>>> so please help verify that fixed patches are enough in linux-stable 4.4.
>>>>
>>>
>>> I do not know, I am not a network developer. Please try to reproduce
>>> the same thing on a newer kernel release and see if the result is the
>>> same or not. If you can find a change that I missed, please let me know
>>> and I will be glad to apply it.
>>
>> maowenan, there were five patches in the original upstream set to
>> address SegmentSmack:
>>
>> tcp: free batches of packets in tcp_prune_ofo_queue()
>> tcp: avoid collapses in tcp_prune_queue() if possible
>> tcp: detect malicious patterns in tcp_collapse_ofo_queue()
>> t
>> cp: call tcp_drop() from tcp_data_queue_ofo()
>> tcp: add
>> tcp_ooo_try_coalesce() helper
>>
>> I believe that the first one, "free batches of packets..." is not
>> needed in 4.4 because we only have a simple queue of packets there
>> anyway, so we're dropping everything each time and don't need the
>> heuristics for how many to drop.
>>
>> That leaves two more which have so far not been backported to 4.4; can
>> you try applying them and see if it resolves the problem for you?
>
> I have tried to add below two patches in 4.4 stable, since I can't apply
> tcp: add tcp_ooo_try_coalesce() helper because conflicts, it has the same result
> after testing, and the cpu usage has not obviously been improved.
>
> tcp: call tcp_drop() from tcp_data_queue_ofo()
> tcp: increment sk_drops for dropped rx packets
>
> @Eric Dumazet, do you have any comments about this, and shall we apply which patches
> to fix in stable branch?
I have checked [PATCH net 3/5] tcp: detect malicious patterns in tcp_collapse_ofo_queue(),
and found that stable branch 4.4 and 3.18 are tiny different from latest mainline,
stable 4.4 branch:
range_truesize = skb->truesize;
latest mainline code:
range_truesize += skb->truesize;
I wonder know why there is some difference here, anything I have ignored?
thank you.
@@ -4923,11 +4925,20 @@ static void tcp_collapse_ofo_queue(struct sock *sk)
if (!skb ||
after(TCP_SKB_CB(skb)->seq, end) ||
before(TCP_SKB_CB(skb)->end_seq, start)) {
- tcp_collapse(sk, NULL, &tp->out_of_order_queue,
- head, skb, start, end);
+ /* Do not attempt collapsing tiny skbs */
+ if (range_truesize != head->truesize ||
+ end - start >= SKB_WITH_OVERHEAD(SK_MEM_QUANTUM)) {
+ tcp_collapse(sk, NULL, &tp->out_of_order_queue,
+ head, skb, start, end);
+ } else {
+ sum_tiny += range_truesize;
+ if (sum_tiny > sk->sk_rcvbuf >> 3)
+ return;
+ }
goto new_range;
}
+ range_truesize += skb->truesize; //stable 4.4 is different from mainline.
if (unlikely(before(TCP_SKB_CB(skb)->seq, start)))
start = TCP_SKB_CB(skb)->seq;
if (after(TCP_SKB_CB(skb)->end_seq, end))
>
>>
>> Thanks.
>>
>
>
> .
>
^ permalink raw reply
* RE: [PATCH net-next v2 1/1] net/tls: Combined memory allocation for decryption request
From: Vakul Garg @ 2018-08-10 10:02 UTC (permalink / raw)
To: Dave Watson
Cc: netdev@vger.kernel.org, borisp@mellanox.com, aviadye@mellanox.com,
davem@davemloft.net
In-Reply-To: <20180809162532.GB59729@davejwatson-mba.local>
> -----Original Message-----
> From: Dave Watson [mailto:davejwatson@fb.com]
> Sent: Thursday, August 9, 2018 9:56 PM
> To: Vakul Garg <vakul.garg@nxp.com>
> Cc: netdev@vger.kernel.org; borisp@mellanox.com;
> aviadye@mellanox.com; davem@davemloft.net
> Subject: Re: [PATCH net-next v2 1/1] net/tls: Combined memory allocation
> for decryption request
>
> On 08/09/18 04:56 AM, Vakul Garg wrote:
> > For preparing decryption request, several memory chunks are required
> > (aead_req, sgin, sgout, iv, aad). For submitting the decrypt request
> > to an accelerator, it is required that the buffers which are read by
> > the accelerator must be dma-able and not come from stack. The buffers
> > for aad and iv can be separately kmalloced each, but it is inefficient.
> > This patch does a combined allocation for preparing decryption request
> > and then segments into aead_req || sgin || sgout || iv || aad.
> >
> > Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
>
> Reviewed-by: Dave Watson <davejwatson@fb.com>
>
> Thanks, looks good to me now.
I had to rebase the patch so as not to use any other patch which is under review.
Since Doron's skb_nsg() patch needs rework, I submitted v3 after removing reference to function skb_nsg() and
replaced it with skb_cow_data().
Kindly review.
^ permalink raw reply
* [PATCH][net-next] packet: switch kvzalloc to allocate memory
From: Li RongQing @ 2018-08-10 10:00 UTC (permalink / raw)
To: netdev
Use modern kvzalloc()/kvfree() instead of custom allocations.
And remove order argument for free_pg_vec and alloc_pg_vec,
this argument is useless to kvfree, or can get from req.
Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
net/packet/af_packet.c | 40 ++++++++++++----------------------------
1 file changed, 12 insertions(+), 28 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 75c92a87e7b2..f28fcaba4f36 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -4137,52 +4137,36 @@ static const struct vm_operations_struct packet_mmap_ops = {
.close = packet_mm_close,
};
-static void free_pg_vec(struct pgv *pg_vec, unsigned int order,
- unsigned int len)
+static void free_pg_vec(struct pgv *pg_vec, unsigned int len)
{
int i;
for (i = 0; i < len; i++) {
if (likely(pg_vec[i].buffer)) {
- if (is_vmalloc_addr(pg_vec[i].buffer))
- vfree(pg_vec[i].buffer);
- else
- free_pages((unsigned long)pg_vec[i].buffer,
- order);
+ kvfree(pg_vec[i].buffer);
pg_vec[i].buffer = NULL;
}
}
kfree(pg_vec);
}
-static char *alloc_one_pg_vec_page(unsigned long order)
+static char *alloc_one_pg_vec_page(unsigned long size)
{
char *buffer;
- gfp_t gfp_flags = GFP_KERNEL | __GFP_COMP |
- __GFP_ZERO | __GFP_NOWARN | __GFP_NORETRY;
- buffer = (char *) __get_free_pages(gfp_flags, order);
+ buffer = kvzalloc(size, GFP_KERNEL);
if (buffer)
return buffer;
- /* __get_free_pages failed, fall back to vmalloc */
- buffer = vzalloc(array_size((1 << order), PAGE_SIZE));
- if (buffer)
- return buffer;
+ buffer = kvzalloc(size, GFP_KERNEL | __GFP_RETRY_MAYFAIL);
- /* vmalloc failed, lets dig into swap here */
- gfp_flags &= ~__GFP_NORETRY;
- buffer = (char *) __get_free_pages(gfp_flags, order);
- if (buffer)
- return buffer;
-
- /* complete and utter failure */
- return NULL;
+ return buffer;
}
-static struct pgv *alloc_pg_vec(struct tpacket_req *req, int order)
+static struct pgv *alloc_pg_vec(struct tpacket_req *req)
{
unsigned int block_nr = req->tp_block_nr;
+ unsigned long size = req->tp_block_size;
struct pgv *pg_vec;
int i;
@@ -4191,7 +4175,7 @@ static struct pgv *alloc_pg_vec(struct tpacket_req *req, int order)
goto out;
for (i = 0; i < block_nr; i++) {
- pg_vec[i].buffer = alloc_one_pg_vec_page(order);
+ pg_vec[i].buffer = alloc_one_pg_vec_page(size);
if (unlikely(!pg_vec[i].buffer))
goto out_free_pgvec;
}
@@ -4200,7 +4184,7 @@ static struct pgv *alloc_pg_vec(struct tpacket_req *req, int order)
return pg_vec;
out_free_pgvec:
- free_pg_vec(pg_vec, order, block_nr);
+ free_pg_vec(pg_vec, block_nr);
pg_vec = NULL;
goto out;
}
@@ -4275,7 +4259,7 @@ static int packet_set_ring(struct sock *sk, union tpacket_req_u *req_u,
err = -ENOMEM;
order = get_order(req->tp_block_size);
- pg_vec = alloc_pg_vec(req, order);
+ pg_vec = alloc_pg_vec(req);
if (unlikely(!pg_vec))
goto out;
switch (po->tp_version) {
@@ -4355,7 +4339,7 @@ static int packet_set_ring(struct sock *sk, union tpacket_req_u *req_u,
}
if (pg_vec)
- free_pg_vec(pg_vec, order, req->tp_block_nr);
+ free_pg_vec(pg_vec, req->tp_block_nr);
out:
return err;
}
--
2.16.2
^ permalink raw reply related
* Re: Error running AF_XDP sample application
From: Konrad Djimeli @ 2018-08-10 9:58 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, netdev-owner
In-Reply-To: <20180809185100.588f33a1@cakuba.netronome.com>
On 2018-08-10 03:51, Jakub Kicinski wrote:
> On Thu, 09 Aug 2018 18:18:08 +0200, kdjimeli wrote:
>> Hello,
>>
>> I have been trying to test a sample AF_XDP program, but I have been
>> experiencing some issues.
>> After building the sample code
>> https://github.com/torvalds/linux/tree/master/samples/bpf,
>> when running the xdpsock binary, I get the errors
>> "libbpf: failed to create map (name: 'xsks_map'): Invalid argument"
>> "libbpf: failed to load object './xdpsock_kern.o"
>>
>> I tried to figure out the cause of the error but all I know is that it
>> occurs at line 910 with the function
>> call "bpf_prog_load_xattr(&prog_load_attr, &obj, &prog_fd)".
>>
>> Please I would like to inquire what could be a possible for this error.
>
> which kernel version are you running?
My kernel version is 4.18.0-rc8+. I cloned it from
https://github.com/torvalds/linux before building a running.
My commit head(git show-ref --head) is at
1236568ee3cbb0d3ac62d0074a29b97ecf34cbbc HEAD
1236568ee3cbb0d3ac62d0074a29b97ecf34cbbc refs/heads/master
1236568ee3cbb0d3ac62d0074a29b97ecf34cbbc refs/remotes/origin/HEAD
1236568ee3cbb0d3ac62d0074a29b97ecf34cbbc refs/remotes/origin/master
...
I also applied the patch https://patchwork.ozlabs.org/patch/949884/
(samples: bpf: convert xdpsock_user.c to libbpf ), as the error was
initially in the form show below:
"failed to create a map: 22 Invalid argument"
"ERROR: load_bpf_file"
Thanks
Konrad
^ permalink raw reply
* [PATCH net-next v3 1/1] net/tls: Combined memory allocation for decryption request
From: Vakul Garg @ 2018-08-10 15:16 UTC (permalink / raw)
To: netdev; +Cc: borisp, aviadye, davejwatson, davem, Vakul Garg
In-Reply-To: <20180810151641.14580-1-vakul.garg@nxp.com>
For preparing decryption request, several memory chunks are required
(aead_req, sgin, sgout, iv, aad). For submitting the decrypt request to
an accelerator, it is required that the buffers which are read by the
accelerator must be dma-able and not come from stack. The buffers for
aad and iv can be separately kmalloced each, but it is inefficient.
This patch does a combined allocation for preparing decryption request
and then segments into aead_req || sgin || sgout || iv || aad.
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
---
Changes since v2:
- Rebased to not require following Doron Roberts-Kedes's patch.
"net/tls: Calculate nsg for zerocopy path without skb_cow_data."
include/net/tls.h | 4 -
net/tls/tls_sw.c | 238 ++++++++++++++++++++++++++++++++----------------------
2 files changed, 142 insertions(+), 100 deletions(-)
diff --git a/include/net/tls.h b/include/net/tls.h
index d8b3b6578c01..d5c683e8bb22 100644
--- a/include/net/tls.h
+++ b/include/net/tls.h
@@ -124,10 +124,6 @@ struct tls_sw_context_rx {
struct sk_buff *recv_pkt;
u8 control;
bool decrypted;
-
- char rx_aad_ciphertext[TLS_AAD_SPACE_SIZE];
- char rx_aad_plaintext[TLS_AAD_SPACE_SIZE];
-
};
struct tls_record_info {
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 83d67df33f0c..52fbe727d7c1 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -48,19 +48,13 @@ static int tls_do_decryption(struct sock *sk,
struct scatterlist *sgout,
char *iv_recv,
size_t data_len,
- struct sk_buff *skb,
- gfp_t flags)
+ struct aead_request *aead_req)
{
struct tls_context *tls_ctx = tls_get_ctx(sk);
struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
- struct aead_request *aead_req;
-
int ret;
- aead_req = aead_request_alloc(ctx->aead_recv, flags);
- if (!aead_req)
- return -ENOMEM;
-
+ aead_request_set_tfm(aead_req, ctx->aead_recv);
aead_request_set_ad(aead_req, TLS_AAD_SPACE_SIZE);
aead_request_set_crypt(aead_req, sgin, sgout,
data_len + tls_ctx->rx.tag_size,
@@ -69,8 +63,6 @@ static int tls_do_decryption(struct sock *sk,
crypto_req_done, &ctx->async_wait);
ret = crypto_wait_req(crypto_aead_decrypt(aead_req), &ctx->async_wait);
-
- aead_request_free(aead_req);
return ret;
}
@@ -657,8 +649,132 @@ static struct sk_buff *tls_wait_data(struct sock *sk, int flags,
return skb;
}
+/* This function decrypts the input skb into either out_iov or in out_sg
+ * or in skb buffers itself. The input parameter 'zc' indicates if
+ * zero-copy mode needs to be tried or not. With zero-copy mode, either
+ * out_iov or out_sg must be non-NULL. In case both out_iov and out_sg are
+ * NULL, then the decryption happens inside skb buffers itself, i.e.
+ * zero-copy gets disabled and 'zc' is updated.
+ */
+
+static int decrypt_internal(struct sock *sk, struct sk_buff *skb,
+ struct iov_iter *out_iov,
+ struct scatterlist *out_sg,
+ int *chunk, bool *zc)
+{
+ struct tls_context *tls_ctx = tls_get_ctx(sk);
+ struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
+ struct strp_msg *rxm = strp_msg(skb);
+ int n_sgin, n_sgout, nsg, mem_size, aead_size, err, pages = 0;
+ struct aead_request *aead_req;
+ struct sk_buff *unused;
+ u8 *aad, *iv, *mem = NULL;
+ struct scatterlist *sgin = NULL;
+ struct scatterlist *sgout = NULL;
+ const int data_len = rxm->full_len - tls_ctx->rx.overhead_size;
+
+ if (*zc && (out_iov || out_sg)) {
+ if (out_iov)
+ n_sgout = iov_iter_npages(out_iov, INT_MAX) + 1;
+ else
+ n_sgout = sg_nents(out_sg);
+ } else {
+ n_sgout = 0;
+ *zc = false;
+ }
+
+ n_sgin = skb_cow_data(skb, 0, &unused);
+ if (n_sgin < 1)
+ return -EBADMSG;
+
+ /* Increment to accommodate AAD */
+ n_sgin = n_sgin + 1;
+
+ nsg = n_sgin + n_sgout;
+
+ aead_size = sizeof(*aead_req) + crypto_aead_reqsize(ctx->aead_recv);
+ mem_size = aead_size + (nsg * sizeof(struct scatterlist));
+ mem_size = mem_size + TLS_AAD_SPACE_SIZE;
+ mem_size = mem_size + crypto_aead_ivsize(ctx->aead_recv);
+
+ /* Allocate a single block of memory which contains
+ * aead_req || sgin[] || sgout[] || aad || iv.
+ * This order achieves correct alignment for aead_req, sgin, sgout.
+ */
+ mem = kmalloc(mem_size, sk->sk_allocation);
+ if (!mem)
+ return -ENOMEM;
+
+ /* Segment the allocated memory */
+ aead_req = (struct aead_request *)mem;
+ sgin = (struct scatterlist *)(mem + aead_size);
+ sgout = sgin + n_sgin;
+ aad = (u8 *)(sgout + n_sgout);
+ iv = aad + TLS_AAD_SPACE_SIZE;
+
+ /* Prepare IV */
+ err = skb_copy_bits(skb, rxm->offset + TLS_HEADER_SIZE,
+ iv + TLS_CIPHER_AES_GCM_128_SALT_SIZE,
+ tls_ctx->rx.iv_size);
+ if (err < 0) {
+ kfree(mem);
+ return err;
+ }
+ memcpy(iv, tls_ctx->rx.iv, TLS_CIPHER_AES_GCM_128_SALT_SIZE);
+
+ /* Prepare AAD */
+ tls_make_aad(aad, rxm->full_len - tls_ctx->rx.overhead_size,
+ tls_ctx->rx.rec_seq, tls_ctx->rx.rec_seq_size,
+ ctx->control);
+
+ /* Prepare sgin */
+ sg_init_table(sgin, n_sgin);
+ sg_set_buf(&sgin[0], aad, TLS_AAD_SPACE_SIZE);
+ err = skb_to_sgvec(skb, &sgin[1],
+ rxm->offset + tls_ctx->rx.prepend_size,
+ rxm->full_len - tls_ctx->rx.prepend_size);
+ if (err < 0) {
+ kfree(mem);
+ return err;
+ }
+
+ if (n_sgout) {
+ if (out_iov) {
+ sg_init_table(sgout, n_sgout);
+ sg_set_buf(&sgout[0], aad, TLS_AAD_SPACE_SIZE);
+
+ *chunk = 0;
+ err = zerocopy_from_iter(sk, out_iov, data_len, &pages,
+ chunk, &sgout[1],
+ (n_sgout - 1), false);
+ if (err < 0)
+ goto fallback_to_reg_recv;
+ } else if (out_sg) {
+ memcpy(sgout, out_sg, n_sgout * sizeof(*sgout));
+ } else {
+ goto fallback_to_reg_recv;
+ }
+ } else {
+fallback_to_reg_recv:
+ sgout = sgin;
+ pages = 0;
+ *chunk = 0;
+ *zc = false;
+ }
+
+ /* Prepare and submit AEAD request */
+ err = tls_do_decryption(sk, sgin, sgout, iv, data_len, aead_req);
+
+ /* Release the pages in case iov was mapped to pages */
+ for (; pages > 0; pages--)
+ put_page(sg_page(&sgout[pages]));
+
+ kfree(mem);
+ return err;
+}
+
static int decrypt_skb_update(struct sock *sk, struct sk_buff *skb,
- struct scatterlist *sgout, bool *zc)
+ struct iov_iter *dest, int *chunk, bool *zc)
{
struct tls_context *tls_ctx = tls_get_ctx(sk);
struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
@@ -671,7 +787,7 @@ static int decrypt_skb_update(struct sock *sk, struct sk_buff *skb,
return err;
#endif
if (!ctx->decrypted) {
- err = decrypt_skb(sk, skb, sgout);
+ err = decrypt_internal(sk, skb, dest, NULL, chunk, zc);
if (err < 0)
return err;
} else {
@@ -690,54 +806,10 @@ static int decrypt_skb_update(struct sock *sk, struct sk_buff *skb,
int decrypt_skb(struct sock *sk, struct sk_buff *skb,
struct scatterlist *sgout)
{
- struct tls_context *tls_ctx = tls_get_ctx(sk);
- struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
- char iv[TLS_CIPHER_AES_GCM_128_SALT_SIZE + MAX_IV_SIZE];
- struct scatterlist sgin_arr[MAX_SKB_FRAGS + 2];
- struct scatterlist *sgin = &sgin_arr[0];
- struct strp_msg *rxm = strp_msg(skb);
- int ret, nsg = ARRAY_SIZE(sgin_arr);
- struct sk_buff *unused;
-
- ret = skb_copy_bits(skb, rxm->offset + TLS_HEADER_SIZE,
- iv + TLS_CIPHER_AES_GCM_128_SALT_SIZE,
- tls_ctx->rx.iv_size);
- if (ret < 0)
- return ret;
-
- memcpy(iv, tls_ctx->rx.iv, TLS_CIPHER_AES_GCM_128_SALT_SIZE);
- if (!sgout) {
- nsg = skb_cow_data(skb, 0, &unused) + 1;
- sgin = kmalloc_array(nsg, sizeof(*sgin), sk->sk_allocation);
- sgout = sgin;
- }
-
- sg_init_table(sgin, nsg);
- sg_set_buf(&sgin[0], ctx->rx_aad_ciphertext, TLS_AAD_SPACE_SIZE);
-
- nsg = skb_to_sgvec(skb, &sgin[1],
- rxm->offset + tls_ctx->rx.prepend_size,
- rxm->full_len - tls_ctx->rx.prepend_size);
- if (nsg < 0) {
- ret = nsg;
- goto out;
- }
-
- tls_make_aad(ctx->rx_aad_ciphertext,
- rxm->full_len - tls_ctx->rx.overhead_size,
- tls_ctx->rx.rec_seq,
- tls_ctx->rx.rec_seq_size,
- ctx->control);
-
- ret = tls_do_decryption(sk, sgin, sgout, iv,
- rxm->full_len - tls_ctx->rx.overhead_size,
- skb, sk->sk_allocation);
-
-out:
- if (sgin != &sgin_arr[0])
- kfree(sgin);
+ bool zc = true;
+ int chunk;
- return ret;
+ return decrypt_internal(sk, skb, NULL, sgout, &chunk, &zc);
}
static bool tls_sw_advance_skb(struct sock *sk, struct sk_buff *skb,
@@ -816,43 +888,17 @@ int tls_sw_recvmsg(struct sock *sk,
}
if (!ctx->decrypted) {
- int page_count;
- int to_copy;
-
- page_count = iov_iter_npages(&msg->msg_iter,
- MAX_SKB_FRAGS);
- to_copy = rxm->full_len - tls_ctx->rx.overhead_size;
- if (!is_kvec && to_copy <= len && page_count < MAX_SKB_FRAGS &&
- likely(!(flags & MSG_PEEK))) {
- struct scatterlist sgin[MAX_SKB_FRAGS + 1];
- int pages = 0;
+ int to_copy = rxm->full_len - tls_ctx->rx.overhead_size;
+ if (!is_kvec && to_copy <= len &&
+ likely(!(flags & MSG_PEEK)))
zc = true;
- sg_init_table(sgin, MAX_SKB_FRAGS + 1);
- sg_set_buf(&sgin[0], ctx->rx_aad_plaintext,
- TLS_AAD_SPACE_SIZE);
-
- err = zerocopy_from_iter(sk, &msg->msg_iter,
- to_copy, &pages,
- &chunk, &sgin[1],
- MAX_SKB_FRAGS, false);
- if (err < 0)
- goto fallback_to_reg_recv;
-
- err = decrypt_skb_update(sk, skb, sgin, &zc);
- for (; pages > 0; pages--)
- put_page(sg_page(&sgin[pages]));
- if (err < 0) {
- tls_err_abort(sk, EBADMSG);
- goto recv_end;
- }
- } else {
-fallback_to_reg_recv:
- err = decrypt_skb_update(sk, skb, NULL, &zc);
- if (err < 0) {
- tls_err_abort(sk, EBADMSG);
- goto recv_end;
- }
+
+ err = decrypt_skb_update(sk, skb, &msg->msg_iter,
+ &chunk, &zc);
+ if (err < 0) {
+ tls_err_abort(sk, EBADMSG);
+ goto recv_end;
}
ctx->decrypted = true;
}
@@ -903,7 +949,7 @@ ssize_t tls_sw_splice_read(struct socket *sock, loff_t *ppos,
int err = 0;
long timeo;
int chunk;
- bool zc;
+ bool zc = false;
lock_sock(sk);
@@ -920,7 +966,7 @@ ssize_t tls_sw_splice_read(struct socket *sock, loff_t *ppos,
}
if (!ctx->decrypted) {
- err = decrypt_skb_update(sk, skb, NULL, &zc);
+ err = decrypt_skb_update(sk, skb, NULL, &chunk, &zc);
if (err < 0) {
tls_err_abort(sk, EBADMSG);
--
2.13.6
^ permalink raw reply related
* [PATCH net-next v3 0/1] net/tls: Combined memory allocation for decryption request
From: Vakul Garg @ 2018-08-10 15:16 UTC (permalink / raw)
To: netdev; +Cc: borisp, aviadye, davejwatson, davem, Vakul Garg
This patch does a combined memory allocation from heap for scatterlists,
aead_request, aad and iv for the tls record decryption path. In present
code, aead_request is allocated from heap, scatterlists on a conditional
basis are allocated on heap or on stack. This is inefficient as it may
requires multiple kmalloc/kfree.
The initialization vector passed in cryption request is allocated on
stack. This is a problem since the stack memory is not dma-able from
crypto accelerators.
Doing one combined memory allocation for each decryption request fixes
both the above issues. It also paves a way to be able to submit multiple
async decryption requests while the previous one is pending i.e. being
processed or queued.
Vakul Garg (1):
net/tls: Combined memory allocation for decryption request
include/net/tls.h | 4 -
net/tls/tls_sw.c | 238 ++++++++++++++++++++++++++++++++----------------------
2 files changed, 142 insertions(+), 100 deletions(-)
--
2.13.6
^ permalink raw reply
* Re: [Patch net-next] net_sched: fix a potential out-of-bound access
From: Vlad Buslov @ 2018-08-10 9:54 UTC (permalink / raw)
To: Cong Wang; +Cc: Linux Kernel Network Developers, Jiri Pirko
In-Reply-To: <CAM_iQpWHPPZdRirBSYG89SjNfYyr4GVC9dsTM+jJYZ-+daNMww@mail.gmail.com>
On Thu 09 Aug 2018 at 21:43, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Thu, Aug 9, 2018 at 12:32 AM Vlad Buslov <vladbu@mellanox.com> wrote:
>>
>> Before version V5 of my action API patchset this functionality was
>> implemented in exactly the same way as in your patch. Unfortunately, it
>> has a double-free bug. The problem is that if you have multiple
>> actions(N) being deleted, and deleted succeeded for first K actions,
>> this implementation will try to delete all N actions second time
>> (including first K actions that were already deleted). That is why I
>> added 'acts_deleted' variable that tracks actual amount of actions that
>> were deleted successfully, and only delete last N-K actions in case of
>> error.
>
> Interesting, I didn't notice you call it for tcf_del_notify()'s failure too.
>
> But this is easy to resolve, we can just set succeeded ones to NULL
> and teach tcf_action_put_many() to scan the whole array but
> skip NULL's.
Both approaches have their own tradeoffs. I considered just skipping
NULLs, but in my experience such approach might introduce hard to debug
bugs when all callers are expected to have either valid pointers or
NULLs in whole array. Then someone forgets to zero unused elements, but
it continues to work because stack memory just happens to be 0. Until
some code path uses same stack space before and leaves some junk there
instead of convenient zeroes...
Also, it becomes more computationally expensive to always scan whole
array for non-NULL pointers, instead of exiting when first NULL is
encountered. I don't think it is a major concert for current
implementation with MAX_PRIO==32, just a general preference of mine.
>
>
>>
>> In order to fix that issue I did following code changes in V5:
>> - Added 'acts_deleted' variable to delete only actions [K, N) in case of
>> error.
>> - Extended 'actions' array size by one to ensure that it always ends
>> with NULL pointer.
>
> Oh, I see, this is not how we use C, you can at least rollback
> by passing acts_deleted as a parameter as the start of the array.
> You picked the most confusing way to handle it.
Noted. I will refrain from passing pointers to arbitrary array elements
as beginning-of-array from now on.
>
> I will send an updated patch.
^ permalink raw reply
* Re: [PATCH net-next v6 06/11] net: sched: add 'delete' function to action ops
From: Vlad Buslov @ 2018-08-10 9:41 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
Jiri Pirko, Alexei Starovoitov, Daniel Borkmann,
Yevgeny Kliteynik, Jiri Pirko
In-Reply-To: <CAM_iQpU53VfnUA-WEJzafo_HhvLmGTZ6s=gZ0O5VenCpoxdGyQ@mail.gmail.com>
On Thu 09 Aug 2018 at 19:38, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Thu, Jul 5, 2018 at 7:24 AM Vlad Buslov <vladbu@mellanox.com> wrote:
>>
>> Extend action ops with 'delete' function. Each action type to implements
>> its own delete function that doesn't depend on rtnl lock.
>>
>> Implement delete function that is required to delete actions without
>> holding rtnl lock. Use action API function that atomically deletes action
>> only if it is still in action idr. This implementation prevents concurrent
>> threads from deleting same action twice.
>
> I fail to understand why you introduce ops->delete(), it seems all
> you want is getting the tn->idrinfo, but you already have tc_action
> before calling ops->delete(), and tc_action has ->idrinfo...
>
> Each type of action does the same too, that is, just calling
> tcf_idr_delete_index()...
I agree with your assessment. Should have implemented it by just calling
tcf_idr_delete_index() directly.
>
> This changelog sucks again, it claims for skipping rtnl lock,
> but you can skip rtnl lock by just calling tcf_idr_delete_index()
> directly too, it is not the reason for adding ops->delete().
My intention was to implement some generic and parallel-safe API that
could be used to implement delete for all actions. It turns out that, as
you noted, just calling tcf_idr_delete_index() is enough because any
special per-action delete code is already implemented by ops->cleanup().
^ permalink raw reply
* Re: [PATCH 1/1] ath10k: avoid possible memory access violation
From: Kalle Valo @ 2018-08-10 12:03 UTC (permalink / raw)
To: VIJAYAKUMAAR K T
Cc: davem@davemloft.net, ath10k@lists.infradead.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, CPGS
In-Reply-To: <20180810101916epcms5p1e3d60d9cbc49f9a7c9529d87d691f359@epcms5p1>
VIJAYAKUMAAR K T <vijay.bvb@samsung.com> writes:
> It would be great, if this patch could be reviewed.
It's in the queue and you can check the state from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#checking_state_of_patches_from_patchwork
--
Kalle Valo
^ permalink raw reply
* [PATCH bpf] Revert "xdp: add NULL pointer check in __xdp_return()"
From: Björn Töpel @ 2018-08-10 9:28 UTC (permalink / raw)
To: ast, daniel, netdev, ap420073, brouer
Cc: Björn Töpel, magnus.karlsson, magnus.karlsson, kafai
From: Björn Töpel <bjorn.topel@intel.com>
This reverts commit 36e0f12bbfd3016f495904b35e41c5711707509f.
The reverted commit adds a WARN to check against NULL entries in the
mem_id_ht rhashtable. Any kernel path implementing the XDP (generic or
driver) fast path is required to make a paired
xdp_rxq_info_reg/xdp_rxq_info_unreg call for proper function. In
addition, a driver using a different allocation scheme than the
default MEM_TYPE_PAGE_SHARED is required to additionally call
xdp_rxq_info_reg_mem_model.
For MEM_TYPE_ZERO_COPY, an xdp_rxq_info_reg_mem_model call ensures
that the mem_id_ht rhashtable has a properly inserted allocator id. If
not, this would be a driver bug. A NULL pointer kernel OOPS is
preferred to the WARN.
Suggested-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
---
net/core/xdp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/core/xdp.c b/net/core/xdp.c
index 6771f1855b96..9d1f22072d5d 100644
--- a/net/core/xdp.c
+++ b/net/core/xdp.c
@@ -345,8 +345,7 @@ static void __xdp_return(void *data, struct xdp_mem_info *mem, bool napi_direct,
rcu_read_lock();
/* mem->id is valid, checked in xdp_rxq_info_reg_mem_model() */
xa = rhashtable_lookup(mem_id_ht, &mem->id, mem_id_rht_params);
- if (!WARN_ON_ONCE(!xa))
- xa->zc_alloc->free(xa->zc_alloc, handle);
+ xa->zc_alloc->free(xa->zc_alloc, handle);
rcu_read_unlock();
default:
/* Not possible, checked in xdp_rxq_info_reg_mem_model() */
--
2.17.1
^ permalink raw reply related
* [PATCH net-next] cxgb4: add support to display DCB info
From: Ganesh Goudar @ 2018-08-10 9:17 UTC (permalink / raw)
To: netdev, davem; +Cc: nirranjan, indranil, dt, Ganesh Goudar, Casey Leedom
display Data Center bridging information in debug
fs.
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.c | 2 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 193 +++++++++++++++++++++
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 3 +-
4 files changed, 197 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 3da9299..76d1674 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -1853,4 +1853,5 @@ void cxgb4_write_sgl(const struct sk_buff *skb, struct sge_txq *q,
void cxgb4_ring_tx_db(struct adapter *adap, struct sge_txq *q, int n);
int t4_set_vlan_acl(struct adapter *adap, unsigned int mbox, unsigned int vf,
u16 vlan);
+int cxgb4_dcb_enabled(const struct net_device *dev);
#endif /* __CXGB4_H__ */
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.c
index 4e7f72b..b34f0f0 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.c
@@ -22,7 +22,7 @@
/* DCBx version control
*/
-static const char * const dcb_ver_array[] = {
+const char * const dcb_ver_array[] = {
"Unknown",
"DCBx-CIN",
"DCBx-CEE 1.01",
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
index 6f312e0..0f72f9c 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -2414,6 +2414,196 @@ static const struct file_operations rss_vf_config_debugfs_fops = {
.release = seq_release_private
};
+#ifdef CONFIG_CHELSIO_T4_DCB
+extern char *dcb_ver_array[];
+
+/* Data Center Briging information for each port.
+ */
+static int dcb_info_show(struct seq_file *seq, void *v)
+{
+ struct adapter *adap = seq->private;
+
+ if (v == SEQ_START_TOKEN) {
+ seq_puts(seq, "Data Center Bridging Information\n");
+ } else {
+ int port = (uintptr_t)v - 2;
+ struct net_device *dev = adap->port[port];
+ struct port_info *pi = netdev2pinfo(dev);
+ struct port_dcb_info *dcb = &pi->dcb;
+
+ seq_puts(seq, "\n");
+ seq_printf(seq, "Port: %d (DCB negotiated: %s)\n",
+ port,
+ cxgb4_dcb_enabled(dev) ? "yes" : "no");
+
+ if (cxgb4_dcb_enabled(dev))
+ seq_printf(seq, "[ DCBx Version %s ]\n",
+ dcb_ver_array[dcb->dcb_version]);
+
+ if (dcb->msgs) {
+ int i;
+
+ seq_puts(seq, "\n Index\t\t\t :\t");
+ for (i = 0; i < 8; i++)
+ seq_printf(seq, " %3d", i);
+ seq_puts(seq, "\n\n");
+ }
+
+ if (dcb->msgs & CXGB4_DCB_FW_PGID) {
+ int prio, pgid;
+
+ seq_puts(seq, " Priority Group IDs\t :\t");
+ for (prio = 0; prio < 8; prio++) {
+ pgid = (dcb->pgid >> 4 * (7 - prio)) & 0xf;
+ seq_printf(seq, " %3d", pgid);
+ }
+ seq_puts(seq, "\n");
+ }
+
+ if (dcb->msgs & CXGB4_DCB_FW_PGRATE) {
+ int pg;
+
+ seq_puts(seq, " Priority Group BW(%)\t :\t");
+ for (pg = 0; pg < 8; pg++)
+ seq_printf(seq, " %3d", dcb->pgrate[pg]);
+ seq_puts(seq, "\n");
+
+ if (dcb->dcb_version == FW_PORT_DCB_VER_IEEE) {
+ seq_puts(seq, " TSA Algorithm\t\t :\t");
+ for (pg = 0; pg < 8; pg++)
+ seq_printf(seq, " %3d", dcb->tsa[pg]);
+ seq_puts(seq, "\n");
+ }
+
+ seq_printf(seq, " Max PG Traffic Classes [%3d ]\n",
+ dcb->pg_num_tcs_supported);
+
+ seq_puts(seq, "\n");
+ }
+
+ if (dcb->msgs & CXGB4_DCB_FW_PRIORATE) {
+ int prio;
+
+ seq_puts(seq, " Priority Rate\t:\t");
+ for (prio = 0; prio < 8; prio++)
+ seq_printf(seq, " %3d", dcb->priorate[prio]);
+ seq_puts(seq, "\n");
+ }
+
+ if (dcb->msgs & CXGB4_DCB_FW_PFC) {
+ int prio;
+
+ seq_puts(seq, " Priority Flow Control :\t");
+ for (prio = 0; prio < 8; prio++) {
+ int pfcen = (dcb->pfcen >> 1 * (7 - prio))
+ & 0x1;
+ seq_printf(seq, " %3d", pfcen);
+ }
+ seq_puts(seq, "\n");
+
+ seq_printf(seq, " Max PFC Traffic Classes [%3d ]\n",
+ dcb->pfc_num_tcs_supported);
+
+ seq_puts(seq, "\n");
+ }
+
+ if (dcb->msgs & CXGB4_DCB_FW_APP_ID) {
+ int app, napps;
+
+ seq_puts(seq, " Application Information:\n");
+ seq_puts(seq, " App Priority Selection Protocol\n");
+ seq_puts(seq, " Index Map Field ID\n");
+ for (app = 0, napps = 0;
+ app < CXGB4_MAX_DCBX_APP_SUPPORTED; app++) {
+ struct app_priority *ap;
+ static const char * const sel_names[] = {
+ "Ethertype",
+ "Socket TCP",
+ "Socket UDP",
+ "Socket All",
+ };
+ const char *sel_name;
+
+ ap = &dcb->app_priority[app];
+ /* skip empty slots */
+ if (ap->protocolid == 0)
+ continue;
+ napps++;
+
+ if (ap->sel_field < ARRAY_SIZE(sel_names))
+ sel_name = sel_names[ap->sel_field];
+ else
+ sel_name = "UNKNOWN";
+
+ seq_printf(seq, " %3d %#04x %-10s (%d) %#06x (%d)\n",
+ app,
+ ap->user_prio_map,
+ sel_name, ap->sel_field,
+ ap->protocolid, ap->protocolid);
+ }
+ if (napps == 0)
+ seq_puts(seq, " --- None ---\n");
+ }
+ }
+ return 0;
+}
+
+static inline void *dcb_info_get_idx(struct adapter *adap, loff_t pos)
+{
+ return (pos <= adap->params.nports
+ ? (void *)((uintptr_t)pos + 1)
+ : NULL);
+}
+
+static void *dcb_info_start(struct seq_file *seq, loff_t *pos)
+{
+ struct adapter *adap = seq->private;
+
+ return (*pos
+ ? dcb_info_get_idx(adap, *pos)
+ : SEQ_START_TOKEN);
+}
+
+static void dcb_info_stop(struct seq_file *seq, void *v)
+{
+}
+
+static void *dcb_info_next(struct seq_file *seq, void *v, loff_t *pos)
+{
+ struct adapter *adap = seq->private;
+
+ (*pos)++;
+ return dcb_info_get_idx(adap, *pos);
+}
+
+static const struct seq_operations dcb_info_seq_ops = {
+ .start = dcb_info_start,
+ .next = dcb_info_next,
+ .stop = dcb_info_stop,
+ .show = dcb_info_show
+};
+
+static int dcb_info_open(struct inode *inode, struct file *file)
+{
+ int res = seq_open(file, &dcb_info_seq_ops);
+
+ if (!res) {
+ struct seq_file *seq = file->private_data;
+
+ seq->private = inode->i_private;
+ }
+ return res;
+}
+
+static const struct file_operations dcb_info_debugfs_fops = {
+ .owner = THIS_MODULE,
+ .open = dcb_info_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = seq_release,
+};
+#endif /* CONFIG_CHELSIO_T4_DCB */
+
static int resources_show(struct seq_file *seq, void *v)
{
struct adapter *adapter = seq->private;
@@ -3435,6 +3625,9 @@ int t4_setup_debugfs(struct adapter *adap)
{ "rss_pf_config", &rss_pf_config_debugfs_fops, 0400, 0 },
{ "rss_vf_config", &rss_vf_config_debugfs_fops, 0400, 0 },
{ "resources", &resources_debugfs_fops, 0400, 0 },
+#ifdef CONFIG_CHELSIO_T4_DCB
+ { "dcb_info", &dcb_info_debugfs_fops, 0400, 0 },
+#endif
{ "sge_qinfo", &sge_qinfo_debugfs_fops, 0400, 0 },
{ "ibq_tp0", &cim_ibq_fops, 0400, 0 },
{ "ibq_tp1", &cim_ibq_fops, 0400, 1 },
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 479a73d..53d5dad 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -267,7 +267,7 @@ static void dcb_tx_queue_prio_enable(struct net_device *dev, int enable)
}
}
-static int cxgb4_dcb_enabled(const struct net_device *dev)
+int cxgb4_dcb_enabled(const struct net_device *dev)
{
struct port_info *pi = netdev_priv(dev);
@@ -5659,6 +5659,7 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
#ifdef CONFIG_CHELSIO_T4_DCB
netdev->dcbnl_ops = &cxgb4_dcb_ops;
cxgb4_dcb_state_init(netdev);
+ cxgb4_dcb_version_init(netdev);
#endif
cxgb4_set_ethtool_ops(netdev);
}
--
2.1.0
^ permalink raw reply related
* Re: [PATCH v2 00/29] at24: remove at24_platform_data
From: Srinivas Kandagatla @ 2018-08-10 8:41 UTC (permalink / raw)
To: Bartosz Golaszewski, Jonathan Corbet, Sekhar Nori, Kevin Hilman,
Russell King, Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse,
Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Naren, Mauro Carvalho Chehab,
Andrew Morton, Lukas Wunner, Dan Carpenter, Flori
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd,
linux-omap, netdev, Bartosz Golaszewski
In-Reply-To: <20180810080526.27207-1-brgl@bgdev.pl>
On 10/08/18 09:04, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> This is a follow-up to the previously rejected series[1] which partially
> removed the at24_platform_data structure. After further development and
> taking reviews into account, this series finally removes that struct
> completely but not without touching many different parts of the code
> base.
>
> Since I took over maintainership of the at24 driver I've been working
> towards removing at24_platform_data in favor for device properties.
>
> DaVinci is the only platform that's still using it - all other users
> have already been converted.
>
> One of the obstacles in case of DaVinci is removing the setup() callback
> from the pdata struct, the only user of which are some davinci boards.
>
> Most boards use the EEPROM to store the MAC address. This series adds
> support for cell lookups to the nvmem framework, registers relevant
> cells for all users, adds nvmem support to eth_platform_get_mac_address(),
> converts davinci_emac driver to using it and replaces at24_platform_data
> with device properties.
>
> There's also one board (da850-evm) which uses MTD for reading the MAC
> address. I used the patch from Alban Bedel's previous submission[2] to
> add support for nvmem to the MTD framework. Since this user doesn't
> need device tree, I dropped Alban's patches modifying the DT bindings.
> We can add that later once an agreement is reached. For the time being
> MTD devices are registered as nvmem devices and we're registering the
> mac-address cell using the cell lookup mechanism.
>
> This series adds a blocking notifier chain to the nvmem framework, so
> that we can keep the EEPROM reading code in the mityomapl138 board file
> with only slight modifications.
>
> I also included some minor fixes to the modified code.
>
> Tested on da850-evm & dm365-evm.
>
> [1] https://lkml.org/lkml/2018/6/29/153
> [2] https://lkml.org/lkml/2018/3/24/312
>
...
> Bartosz Golaszewski (28):
> nvmem: add support for cell lookups
> Documentation: nvmem: document lookup entries
> nvmem: add a notifier chain
> nvmem: provide nvmem_dev_name()
> nvmem: remove the name field from struct nvmem_device
>
> Documentation/nvmem/nvmem.txt | 28 +++++
..
> drivers/nvmem/core.c | 106 ++++++++++++++++-
nvmem parts looks good to me other then few trivial kernel doc comments!
I can either Ack those patches or Send them after rc3-4 to Greg KH as
4.20 material.
Thanks
srini
>
^ permalink raw reply
* Re: [PATCH v2 05/29] nvmem: remove the name field from struct nvmem_device
From: Srinivas Kandagatla @ 2018-08-10 8:33 UTC (permalink / raw)
To: Bartosz Golaszewski, Jonathan Corbet, Sekhar Nori, Kevin Hilman,
Russell King, Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse,
Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Naren, Mauro Carvalho Chehab,
Andrew Morton, Lukas Wunner, Dan Carpenter, Flori
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd,
linux-omap, netdev, Bartosz Golaszewski
In-Reply-To: <20180810080526.27207-6-brgl@bgdev.pl>
On 10/08/18 09:05, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> This field is never set and is only used in a single error message.
> Remove the field and use nvmem_dev_name() instead.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
Looks good to me!
> drivers/nvmem/core.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> index 31df2e6d6f72..ab3ced2d9a84 100644
> --- a/drivers/nvmem/core.c
> +++ b/drivers/nvmem/core.c
> @@ -26,7 +26,6 @@
> #include <linux/slab.h>
>
> struct nvmem_device {
> - const char *name;
> struct module *owner;
> struct device dev;
> int stride;
> @@ -712,7 +711,7 @@ static struct nvmem_device *__nvmem_device_get(struct device_node *np,
> if (!try_module_get(nvmem->owner)) {
> dev_err(&nvmem->dev,
> "could not increase module refcount for cell %s\n",
> - nvmem->name);
> + nvmem_dev_name(nvmem));
>
> mutex_lock(&nvmem_mutex);
> nvmem->users--;
>
^ permalink raw reply
* Re: [PATCH v2 03/29] nvmem: add a notifier chain
From: Srinivas Kandagatla @ 2018-08-10 8:33 UTC (permalink / raw)
To: Bartosz Golaszewski, Jonathan Corbet, Sekhar Nori, Kevin Hilman,
Russell King, Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse,
Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Naren, Mauro Carvalho Chehab,
Andrew Morton, Lukas Wunner, Dan Carpenter, Flori
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd,
linux-omap, netdev, Bartosz Golaszewski
In-Reply-To: <20180810080526.27207-4-brgl@bgdev.pl>
On 10/08/18 09:05, Bartosz Golaszewski wrote:
> +int nvmem_register_notifier(struct notifier_block *nb)
> +{
> + return blocking_notifier_chain_register(&nvmem_notifier, nb);
> +}
> +EXPORT_SYMBOL_GPL(nvmem_register_notifier);
> +
> +int nvmem_unregister_notifier(struct notifier_block *nb)
> +{
> + return blocking_notifier_chain_unregister(&nvmem_notifier, nb);
> +}
> +EXPORT_SYMBOL_GPL(nvmem_unregister_notifier);
> +
Kerneldoc is missing for these both exported symbols too!
--srini
^ permalink raw reply
* Re: [PATCH net-next] crush: fix using plain integer as NULL warning
From: Ilya Dryomov @ 2018-08-10 10:59 UTC (permalink / raw)
To: yuehaibing
Cc: David S. Miller, linux-kernel, netdev, Yan, Zheng, Sage Weil,
Ceph Development
In-Reply-To: <20180808115257.6088-1-yuehaibing@huawei.com>
On Wed, Aug 8, 2018 at 1:53 PM YueHaibing <yuehaibing@huawei.com> wrote:
>
> Fixes the following sparse warning:
> net/ceph/crush/mapper.c:517:76: warning: Using plain integer as NULL pointer
> net/ceph/crush/mapper.c:728:68: warning: Using plain integer as NULL pointer
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> net/ceph/crush/mapper.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/ceph/crush/mapper.c b/net/ceph/crush/mapper.c
> index 417df67..3f323ed 100644
> --- a/net/ceph/crush/mapper.c
> +++ b/net/ceph/crush/mapper.c
> @@ -514,7 +514,7 @@ static int crush_choose_firstn(const struct crush_map *map,
> in, work->work[-1-in->id],
> x, r,
> (choose_args ?
> - &choose_args[-1-in->id] : 0),
> + &choose_args[-1-in->id] : NULL),
> outpos);
> if (item >= map->max_devices) {
> dprintk(" bad item %d\n", item);
> @@ -725,7 +725,7 @@ static void crush_choose_indep(const struct crush_map *map,
> in, work->work[-1-in->id],
> x, r,
> (choose_args ?
> - &choose_args[-1-in->id] : 0),
> + &choose_args[-1-in->id] : NULL),
> outpos);
> if (item >= map->max_devices) {
> dprintk(" bad item %d\n", item);
Applied.
Thanks,
Ilya
^ permalink raw reply
* Re: [PATCH net-next] xen-netfront: fix warn message as irq device name has '/'
From: Juergen Gross @ 2018-08-10 10:54 UTC (permalink / raw)
To: Xiao Liang, netdev, xen-devel, davem, boris.ostrovsky; +Cc: linux-kernel
In-Reply-To: <20180809060355.6525-1-xiliang@redhat.com>
On 09/08/18 08:03, Xiao Liang wrote:
> There is a call trace generated after commit 2d408c0d4574b01b9ed45e02516888bf925e11a9(
> xen-netfront: fix queue name setting). There is no 'device/vif/xx-q0-tx' file found
> under /proc/irq/xx/.
>
> This patch only picks up device type and id as its name.
>
> With the patch, now /proc/interrupts looks like and the warning message gone:
> 70: 21 0 0 0 xen-dyn -event vif0-q0-tx
> 71: 15 0 0 0 xen-dyn -event vif0-q0-rx
> 72: 14 0 0 0 xen-dyn -event vif0-q1-tx
> 73: 33 0 0 0 xen-dyn -event vif0-q1-rx
> 74: 12 0 0 0 xen-dyn -event vif0-q2-tx
> 75: 24 0 0 0 xen-dyn -event vif0-q2-rx
> 76: 19 0 0 0 xen-dyn -event vif0-q3-tx
> 77: 21 0 0 0 xen-dyn -event vif0-q3-rx
>
> Below is call trace information without this patch:
>
> name 'device/vif/0-q0-tx'
> WARNING: CPU: 2 PID: 37 at fs/proc/generic.c:174 __xlate_proc_name+0x85/0xa0
> RIP: 0010:__xlate_proc_name+0x85/0xa0
> RSP: 0018:ffffb85c40473c18 EFLAGS: 00010286
> RAX: 0000000000000000 RBX: 0000000000000006 RCX: 0000000000000006
> RDX: 0000000000000007 RSI: 0000000000000096 RDI: ffff984c7f516930
> RBP: ffffb85c40473cb8 R08: 000000000000002c R09: 0000000000000229
> R10: 0000000000000000 R11: 0000000000000001 R12: ffffb85c40473c98
> R13: ffffb85c40473cb8 R14: ffffb85c40473c50 R15: 0000000000000000
> FS: 0000000000000000(0000) GS:ffff984c7f500000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f69b6899038 CR3: 000000001c20a006 CR4: 00000000001606e0
> Call Trace:
> __proc_create+0x45/0x230
> ? snprintf+0x49/0x60
> proc_mkdir_data+0x35/0x90
> register_handler_proc+0xef/0x110
> ? proc_register+0xfc/0x110
> ? proc_create_data+0x70/0xb0
> __setup_irq+0x39b/0x660
> ? request_threaded_irq+0xad/0x160
> request_threaded_irq+0xf5/0x160
> ? xennet_tx_buf_gc+0x1d0/0x1d0 [xen_netfront]
> bind_evtchn_to_irqhandler+0x3d/0x70
> ? xenbus_alloc_evtchn+0x41/0xa0
> netback_changed+0xa46/0xcda [xen_netfront]
> ? find_watch+0x40/0x40
> xenwatch_thread+0xc5/0x160
> ? finish_wait+0x80/0x80
> kthread+0x112/0x130
> ? kthread_create_worker_on_cpu+0x70/0x70
> ret_from_fork+0x35/0x40
> Code: 81 5c 00 48 85 c0 75 cc 5b 49 89 2e 31 c0 5d 4d 89 3c 24 41 5c 41 5d 41 5e 41 5f c3 4c 89 ee 48 c7 c7 40 4f 0e b4 e8 65 ea d8 ff <0f> 0b b8 fe ff ff ff 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 0f 1f
> ---[ end trace 650e5561b0caab3a ]---
>
> Signed-off-by: Xiao Liang <xiliang@redhat.com>
> ---
> drivers/net/xen-netfront.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 799cba4624a5..6f40df4a452e 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -1604,14 +1604,16 @@ static int xennet_init_queue(struct netfront_queue *queue)
> {
> unsigned short i;
> int err = 0;
> + int devid = 0;
>
> spin_lock_init(&queue->tx_lock);
> spin_lock_init(&queue->rx_lock);
>
> timer_setup(&queue->rx_refill_timer, rx_refill_timeout, 0);
>
> - snprintf(queue->name, sizeof(queue->name), "%s-q%u",
> - queue->info->xbdev->nodename, queue->id);
> + kstrtoint(strrchr(queue->info->xbdev->nodename,'/')+1, 10, &devid);
Please add blanks before '/' and around the +.
With that you can add my:
Reviewed-by: Juergen Gross <jgross@suse.com>
Juergen
^ permalink raw reply
* BUG: corrupted list in p9_write_work
From: syzbot @ 2018-08-10 8:22 UTC (permalink / raw)
To: davem, ericvh, linux-kernel, lucho, netdev, rminnich,
syzkaller-bugs, v9fs-developer
Hello,
syzbot found the following crash on:
HEAD commit: 116b181bb646 Add linux-next specific files for 20180803
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1333a3e0400000
kernel config: https://syzkaller.appspot.com/x/.config?x=b4f38be7c2c519d5
dashboard link: https://syzkaller.appspot.com/bug?extid=1788bd5d4e051da6ec08
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+1788bd5d4e051da6ec08@syzkaller.appspotmail.com
list_add corruption. prev->next should be next (ffff8801c2aad370), but was
ffff8801c2aad380. (prev=ffff8801b1a15ad8).
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:28!
invalid opcode: 0000 [#1] SMP KASAN
CPU: 0 PID: 1879 Comm: kworker/0:2 Not tainted 4.18.0-rc7-next-20180803+ #31
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events p9_write_work
RIP: 0010:__list_add_valid.cold.0+0x23/0x25 lib/list_debug.c:26
Code: e8 4f ce 56 fe eb 97 48 89 d9 48 c7 c7 e0 9a 3a 87 e8 32 87 fe fd 0f
0b 48 89 f1 48 c7 c7 a0 9b 3a 87 48 89 de e8 1e 87 fe fd <0f> 0b 4c 89 e2
48 89 de 48 c7 c7 e0 9c 3a 87 e8 0a 87 fe fd 0f 0b
RSP: 0018:ffff8801ce447590 EFLAGS: 00010282
RAX: 0000000000000075 RBX: ffff8801c2aad370 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff816366f1 RDI: 0000000000000001
RBP: ffff8801ce4475a8 R08: ffff8801ce43a500 R09: ffffed003b604fd0
R10: ffffed003b604fd0 R11: ffff8801db027e87 R12: ffff8801b1a15ad8
R13: ffff8801b1a15ad8 R14: ffff8801c2aad3c4 R15: ffff8801b1a15ad8
FS: 0000000000000000(0000) GS:ffff8801db000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b31525000 CR3: 00000001b53b4000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__list_add include/linux/list.h:60 [inline]
list_add_tail include/linux/list.h:93 [inline]
list_move_tail include/linux/list.h:183 [inline]
p9_write_work+0x34e/0xd50 net/9p/trans_fd.c:470
process_one_work+0xc73/0x1ba0 kernel/workqueue.c:2153
worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
kthread+0x35a/0x420 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415
Modules linked in:
Dumping ftrace buffer:
(ftrace buffer empty)
---[ end trace fb8b29d28d8f9975 ]---
RIP: 0010:__list_add_valid.cold.0+0x23/0x25 lib/list_debug.c:26
Code: e8 4f ce 56 fe eb 97 48 89 d9 48 c7 c7 e0 9a 3a 87 e8 32 87 fe fd 0f
0b 48 89 f1 48 c7 c7 a0 9b 3a 87 48 89 de e8 1e 87 fe fd <0f> 0b 4c 89 e2
48 89 de 48 c7 c7 e0 9c 3a 87 e8 0a 87 fe fd 0f 0b
RSP: 0018:ffff8801ce447590 EFLAGS: 00010282
RAX: 0000000000000075 RBX: ffff8801c2aad370 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff816366f1 RDI: 0000000000000001
RBP: ffff8801ce4475a8 R08: ffff8801ce43a500 R09: ffffed003b604fd0
R10: ffffed003b604fd0 R11: ffff8801db027e87 R12: ffff8801b1a15ad8
R13: ffff8801b1a15ad8 R14: ffff8801c2aad3c4 R15: ffff8801b1a15ad8
FS: 0000000000000000(0000) GS:ffff8801db000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b31525000 CR3: 00000001b53b4000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* Re: [PATCH v2 04/29] nvmem: provide nvmem_dev_name()
From: Srinivas Kandagatla @ 2018-08-10 8:10 UTC (permalink / raw)
To: Bartosz Golaszewski, Jonathan Corbet, Sekhar Nori, Kevin Hilman,
Russell King, Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse,
Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Naren, Mauro Carvalho Chehab,
Andrew Morton, Lukas Wunner, Dan Carpenter, Flori
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd,
linux-omap, netdev, Bartosz Golaszewski
In-Reply-To: <20180810080526.27207-5-brgl@bgdev.pl>
On 10/08/18 09:05, Bartosz Golaszewski wrote:
>
> +const char *nvmem_dev_name(struct nvmem_device *nvmem)
> +{
> + return dev_name(&nvmem->dev);
> +}
> +EXPORT_SYMBOL_GPL(nvmem_dev_name);
> +
Kernel doc for this is missing!
Other than that it looks good to me!
--srini
^ permalink raw reply
* [PATCH v2 21/29] ARM: davinci: da830-evm: use device properties for at24 eeprom
From: Bartosz Golaszewski @ 2018-08-10 8:05 UTC (permalink / raw)
To: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd,
linux-omap, netdev, Bartosz Golaszewski
In-Reply-To: <20180810080526.27207-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
We want to work towards phasing out the at24_platform_data structure.
There are few users and its contents can be represented using generic
device properties. Using device properties only will allow us to
significantly simplify the at24 configuration code.
Remove the at24_platform_data structure and replace it with an array
of property entries. Drop the byte_len/size property, as the model name
already implies the EEPROM's size.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
arch/arm/mach-davinci/board-da830-evm.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 9a055ebba081..fcfd1565bfdc 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -18,7 +18,7 @@
#include <linux/platform_device.h>
#include <linux/i2c.h>
#include <linux/platform_data/pcf857x.h>
-#include <linux/platform_data/at24.h>
+#include <linux/property.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
#include <linux/nvmem-provider.h>
@@ -419,12 +419,9 @@ static struct nvmem_cell_lookup da830_evm_mac_address_cell = {
.nvmem_name = "1-00500",
};
-static struct at24_platform_data da830_evm_i2c_eeprom_info = {
- .byte_len = SZ_256K / 8,
- .page_size = 64,
- .flags = AT24_FLAG_ADDR16,
- .setup = davinci_get_mac_addr,
- .context = (void *)0x7f00,
+static const struct property_entry da830_evm_i2c_eeprom_properties[] = {
+ PROPERTY_ENTRY_U32("pagesize", 64),
+ { }
};
static int __init da830_evm_ui_expander_setup(struct i2c_client *client,
@@ -458,7 +455,7 @@ static struct pcf857x_platform_data __initdata da830_evm_ui_expander_info = {
static struct i2c_board_info __initdata da830_evm_i2c_devices[] = {
{
I2C_BOARD_INFO("24c256", 0x50),
- .platform_data = &da830_evm_i2c_eeprom_info,
+ .properties = da830_evm_i2c_eeprom_properties,
},
{
I2C_BOARD_INFO("tlv320aic3x", 0x18),
--
2.18.0
^ permalink raw reply related
* [PATCH v2 20/29] ARM: davinci: dm365-evm: use device properties for at24 eeprom
From: Bartosz Golaszewski @ 2018-08-10 8:05 UTC (permalink / raw)
To: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd,
linux-omap, netdev, Bartosz Golaszewski
In-Reply-To: <20180810080526.27207-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
We want to work towards phasing out the at24_platform_data structure.
There are few users and its contents can be represented using generic
device properties. Using device properties only will allow us to
significantly simplify the at24 configuration code.
Remove the at24_platform_data structure and replace it with an array
of property entries. Drop the byte_len/size property, as the model name
already implies the EEPROM's size.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
arch/arm/mach-davinci/board-dm365-evm.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index cf3f2e611228..2447e08dd68d 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -18,7 +18,7 @@
#include <linux/i2c.h>
#include <linux/io.h>
#include <linux/clk.h>
-#include <linux/platform_data/at24.h>
+#include <linux/property.h>
#include <linux/leds.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
@@ -179,18 +179,15 @@ static struct nvmem_cell_lookup dm365evm_mac_address_cell = {
.nvmem_name = "1-00500",
};
-static struct at24_platform_data eeprom_info = {
- .byte_len = (256*1024) / 8,
- .page_size = 64,
- .flags = AT24_FLAG_ADDR16,
- .setup = davinci_get_mac_addr,
- .context = (void *)0x7f00,
+static const struct property_entry eeprom_properties[] = {
+ PROPERTY_ENTRY_U32("pagesize", 64),
+ { }
};
static struct i2c_board_info i2c_info[] = {
{
I2C_BOARD_INFO("24c256", 0x50),
- .platform_data = &eeprom_info,
+ .properties = eeprom_properties,
},
{
I2C_BOARD_INFO("tlv320aic3x", 0x18),
--
2.18.0
^ permalink raw reply related
* [PATCH v2 14/29] net: simplify eth_platform_get_mac_address()
From: Bartosz Golaszewski @ 2018-08-10 8:05 UTC (permalink / raw)
To: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd,
linux-omap, netdev, Bartosz Golaszewski
In-Reply-To: <20180810080526.27207-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
We don't need to use pci_device_to_OF_node() - we can retrieve
dev->of_node directly even for pci devices.
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
net/ethernet/eth.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
index ee28440f57c5..7f08105402c8 100644
--- a/net/ethernet/eth.c
+++ b/net/ethernet/eth.c
@@ -530,11 +530,7 @@ int eth_platform_get_mac_address(struct device *dev, u8 *mac_addr)
const unsigned char *addr;
struct device_node *dp;
- if (dev_is_pci(dev))
- dp = pci_device_to_OF_node(to_pci_dev(dev));
- else
- dp = dev->of_node;
-
+ dp = dev->of_node;
addr = NULL;
if (dp)
addr = of_get_mac_address(dp);
--
2.18.0
^ permalink raw reply related
* [PATCH v2 12/29] ARM: davinci: da850-evm: use nvmem lookup for mac address
From: Bartosz Golaszewski @ 2018-08-10 8:05 UTC (permalink / raw)
To: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd,
linux-omap, netdev, Bartosz Golaszewski
In-Reply-To: <20180810080526.27207-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
We now support nvmem lookups for machine code. Add a lookup for
mac-address.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/board-da850-evm.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 6d5beb11bd96..5a634a04ec69 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -29,6 +29,7 @@
#include <linux/mtd/rawnand.h>
#include <linux/mtd/partitions.h>
#include <linux/mtd/physmap.h>
+#include <linux/nvmem-provider.h>
#include <linux/platform_device.h>
#include <linux/platform_data/gpio-davinci.h>
#include <linux/platform_data/mtd-davinci.h>
@@ -99,6 +100,19 @@ static struct mtd_partition da850evm_spiflash_part[] = {
},
};
+static struct nvmem_cell_lookup da850evm_mac_address_cell = {
+ .info = {
+ .name = "mac-address",
+ .offset = 0x0,
+ .bytes = ETH_ALEN,
+ },
+ /*
+ * The nvmem name differs from the partition name because of the
+ * internal works of the nvmem framework.
+ */
+ .nvmem_name = "MAC-Address0",
+};
+
static struct flash_platform_data da850evm_spiflash_data = {
.name = "m25p80",
.parts = da850evm_spiflash_part,
@@ -1447,6 +1461,8 @@ static __init void da850_evm_init(void)
pr_warn("%s: spi info registration failed: %d\n", __func__,
ret);
+ nvmem_add_lookup_table(&da850evm_mac_address_cell, 1);
+
ret = da8xx_register_spi_bus(1, ARRAY_SIZE(da850evm_spi_info));
if (ret)
pr_warn("%s: SPI 1 registration failed: %d\n", __func__, ret);
--
2.18.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox