* Re: [PATCHv2 net-next 11/16] net: mvpp2: handle misc PPv2.1/PPv2.2 differences
From: Russell King - ARM Linux @ 2017-01-07 9:38 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Mark Rutland, devicetree, Yehuda Yitschak, Jason Cooper,
Pawel Moll, Ian Campbell, netdev, Hanna Hawa, Nadav Haklai,
Rob Herring, Andrew Lunn, Kumar Gala, Gregory Clement,
Stefan Chulski, Marcin Wojtas, David S. Miller, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <1482943592-12556-12-git-send-email-thomas.petazzoni@free-electrons.com>
On Wed, Dec 28, 2016 at 05:46:27PM +0100, Thomas Petazzoni wrote:
> @@ -6511,7 +6515,9 @@ static int mvpp2_port_probe(struct platform_device *pdev,
> dev_err(&pdev->dev, "failed to init port %d\n", id);
> goto err_free_stats;
> }
> - mvpp2_port_power_up(port);
> +
> + if (priv->hw_version == MVPP21)
> + mvpp21_port_power_up(port);
This has the side effect that nothing clears the port reset bit in the
GMAC, which means there's no hope of the interface working - with the
reset bit set, the port is well and truely held in "link down" state.
In any case, the GMAC part is much the same as mvneta, and I think
that code should be shared rather than writing new versions of it.
There are some subtle differences between neta, pp2.1 and pp2.2, but
it's entirely doable (I have an implementation here as I wasn't going
to duplicate this code for my phylink conversion.)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCHv2 net-next 0/5] sctp: add support for generating stream reconf chunks
From: Xin Long @ 2017-01-07 9:42 UTC (permalink / raw)
To: network dev, linux-sctp
Cc: Marcelo Ricardo Leitner, Neil Horman, Vlad Yasevich, davem
This patchset is to add some functions to generate stream reconf chunks,
described in RFC6525 Section 3 and Section 4.
v1->v2:
- put these into a smaller group.
- rename some temporary variables in the codes.
- rename the titles of the commits and improve some changelogs.
Xin Long (5):
sctp: add a common helper function to generate stream reconf chunk
sctp: add support for generating stream reconf ssn reset request chunk
sctp: add support for generating stream reconf ssn/tsn reset request
chunk
sctp: add support for generating stream reconf response chunk
sctp: add support for generating stream reconf add streams request
chunk
include/linux/sctp.h | 68 ++++++++++++
include/net/sctp/sm.h | 17 ++-
include/net/sctp/structs.h | 3 +
net/sctp/associola.c | 1 +
net/sctp/sm_make_chunk.c | 270 +++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 358 insertions(+), 1 deletion(-)
--
2.1.0
^ permalink raw reply
* [PATCHv2 net-next 1/5] sctp: add a common helper function to generate stream reconf chunk
From: Xin Long @ 2017-01-07 9:42 UTC (permalink / raw)
To: network dev, linux-sctp
Cc: Marcelo Ricardo Leitner, Neil Horman, Vlad Yasevich, davem
In-Reply-To: <cover.1483781759.git.lucien.xin@gmail.com>
This patch is to define a common api used to alloc memory and initialize
reconf chunk header that described in rfc6525 section 3.1.
All reconf chunks will be generated by calling this helper function.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
include/linux/sctp.h | 6 ++++++
net/sctp/sm_make_chunk.c | 33 +++++++++++++++++++++++++++++++++
2 files changed, 39 insertions(+)
diff --git a/include/linux/sctp.h b/include/linux/sctp.h
index fcb4c36..cdc3b05 100644
--- a/include/linux/sctp.h
+++ b/include/linux/sctp.h
@@ -108,6 +108,7 @@ typedef enum {
/* Use hex, as defined in ADDIP sec. 3.1 */
SCTP_CID_ASCONF = 0xC1,
SCTP_CID_ASCONF_ACK = 0x80,
+ SCTP_CID_RECONF = 0x82,
} sctp_cid_t; /* enum */
@@ -710,4 +711,9 @@ struct sctp_infox {
struct sctp_association *asoc;
};
+struct sctp_reconf_chunk {
+ sctp_chunkhdr_t chunk_hdr;
+ __u8 params[0];
+} __packed;
+
#endif /* __LINUX_SCTP_H__ */
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index a15d824..fd58097 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -3526,3 +3526,36 @@ struct sctp_chunk *sctp_make_fwdtsn(const struct sctp_association *asoc,
return retval;
}
+
+/* RE-CONFIG 3.1 (RE-CONFIG chunk)
+ * 0 1 2 3
+ * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Type = 130 | Chunk Flags | Chunk Length |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * \ \
+ * / Re-configuration Parameter /
+ * \ \
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * \ \
+ * / Re-configuration Parameter (optional) /
+ * \ \
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ */
+static struct sctp_chunk *sctp_make_reconf(
+ const struct sctp_association *asoc,
+ int length)
+{
+ struct sctp_reconf_chunk *reconf;
+ struct sctp_chunk *retval;
+
+ retval = sctp_make_control(asoc, SCTP_CID_RECONF, 0, length,
+ GFP_ATOMIC);
+ if (!retval)
+ return NULL;
+
+ reconf = (struct sctp_reconf_chunk *)retval->chunk_hdr;
+ retval->param_hdr.v = reconf->params;
+
+ return retval;
+}
--
2.1.0
^ permalink raw reply related
* [PATCHv2 net-next 2/5] sctp: add support for generating stream reconf ssn reset request chunk
From: Xin Long @ 2017-01-07 9:42 UTC (permalink / raw)
To: network dev, linux-sctp
Cc: Marcelo Ricardo Leitner, Neil Horman, Vlad Yasevich, davem
In-Reply-To: <cover.1483781759.git.lucien.xin@gmail.com>
This patch is to add asoc strreset_outseq and strreset_inseq for
saving the reconf request sequence, initialize them when create
assoc and process init, and also to define Incoming and Outgoing
SSN Reset Request Parameter described in rfc6525 section 4.1 and
4.2, As they can be in one same chunk as section rfc6525 3.1-3
describes, it makes them in one function.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
include/linux/sctp.h | 26 ++++++++++++++
include/net/sctp/sm.h | 5 ++-
include/net/sctp/structs.h | 3 ++
net/sctp/associola.c | 1 +
net/sctp/sm_make_chunk.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 122 insertions(+), 1 deletion(-)
diff --git a/include/linux/sctp.h b/include/linux/sctp.h
index cdc3b05..d5da19c 100644
--- a/include/linux/sctp.h
+++ b/include/linux/sctp.h
@@ -200,6 +200,13 @@ typedef enum {
SCTP_PARAM_SUCCESS_REPORT = cpu_to_be16(0xc005),
SCTP_PARAM_ADAPTATION_LAYER_IND = cpu_to_be16(0xc006),
+ /* RE-CONFIG. Section 4 */
+ SCTP_PARAM_RESET_OUT_REQUEST = cpu_to_be16(0x000d),
+ SCTP_PARAM_RESET_IN_REQUEST = cpu_to_be16(0x000e),
+ SCTP_PARAM_RESET_TSN_REQUEST = cpu_to_be16(0x000f),
+ SCTP_PARAM_RESET_RESPONSE = cpu_to_be16(0x0010),
+ SCTP_PARAM_RESET_ADD_OUT_STREAMS = cpu_to_be16(0x0011),
+ SCTP_PARAM_RESET_ADD_IN_STREAMS = cpu_to_be16(0x0012),
} sctp_param_t; /* enum */
@@ -716,4 +723,23 @@ struct sctp_reconf_chunk {
__u8 params[0];
} __packed;
+struct sctp_strreset_req {
+ sctp_paramhdr_t param_hdr;
+ __u32 request_seq;
+} __packed;
+
+struct sctp_strreset_outreq {
+ sctp_paramhdr_t param_hdr;
+ __u32 request_seq;
+ __u32 response_seq;
+ __u32 send_reset_at_tsn;
+ __u16 list_of_streams[0];
+} __packed;
+
+struct sctp_strreset_inreq {
+ sctp_paramhdr_t param_hdr;
+ __u32 request_seq;
+ __u16 list_of_streams[0];
+} __packed;
+
#endif /* __LINUX_SCTP_H__ */
diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h
index ca6c971..3462cb0 100644
--- a/include/net/sctp/sm.h
+++ b/include/net/sctp/sm.h
@@ -259,7 +259,10 @@ struct sctp_chunk *sctp_make_fwdtsn(const struct sctp_association *asoc,
__u32 new_cum_tsn, size_t nstreams,
struct sctp_fwdtsn_skip *skiplist);
struct sctp_chunk *sctp_make_auth(const struct sctp_association *asoc);
-
+struct sctp_chunk *sctp_make_strreset_req(
+ const struct sctp_association *asoc,
+ __u16 stream_num, __u16 *stream_list,
+ bool out, bool in);
void sctp_chunk_assign_tsn(struct sctp_chunk *);
void sctp_chunk_assign_ssn(struct sctp_chunk *);
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index 4741ec2..3dc983e 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -1865,6 +1865,9 @@ struct sctp_association {
temp:1, /* Is it a temporary association? */
prsctp_enable:1;
+ __u32 strreset_outseq; /* Update after receiving response */
+ __u32 strreset_inseq; /* Update after receiving request */
+
struct sctp_priv_assoc_stats stats;
int sent_cnt_removable;
diff --git a/net/sctp/associola.c b/net/sctp/associola.c
index 36294f7..42ece6f 100644
--- a/net/sctp/associola.c
+++ b/net/sctp/associola.c
@@ -207,6 +207,7 @@ static struct sctp_association *sctp_association_init(struct sctp_association *a
* association to the same value as the initial TSN.
*/
asoc->addip_serial = asoc->c.initial_tsn;
+ asoc->strreset_outseq = asoc->c.initial_tsn;
INIT_LIST_HEAD(&asoc->addip_chunk_list);
INIT_LIST_HEAD(&asoc->asconf_ack_list);
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index fd58097..172385c 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -1844,6 +1844,7 @@ struct sctp_association *sctp_unpack_cookie(
retval->next_tsn = retval->c.initial_tsn;
retval->ctsn_ack_point = retval->next_tsn - 1;
retval->addip_serial = retval->c.initial_tsn;
+ retval->strreset_outseq = retval->c.initial_tsn;
retval->adv_peer_ack_point = retval->ctsn_ack_point;
retval->peer.prsctp_capable = retval->c.prsctp_capable;
retval->peer.adaptation_ind = retval->c.adaptation_ind;
@@ -2387,6 +2388,8 @@ int sctp_process_init(struct sctp_association *asoc, struct sctp_chunk *chunk,
asoc->peer.i.initial_tsn =
ntohl(peer_init->init_hdr.initial_tsn);
+ asoc->strreset_inseq = asoc->peer.i.initial_tsn;
+
/* Apply the upper bounds for output streams based on peer's
* number of inbound streams.
*/
@@ -3559,3 +3562,88 @@ static struct sctp_chunk *sctp_make_reconf(
return retval;
}
+
+/* RE-CONFIG 4.1 (STREAM OUT RESET)
+ * 0 1 2 3
+ * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Parameter Type = 13 | Parameter Length = 16 + 2 * N |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Re-configuration Request Sequence Number |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Re-configuration Response Sequence Number |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Sender's Last Assigned TSN |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Stream Number 1 (optional) | Stream Number 2 (optional) |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * / ...... /
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Stream Number N-1 (optional) | Stream Number N (optional) |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ *
+ * RE-CONFIG 4.2 (STREAM IN RESET)
+ * 0 1 2 3
+ * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Parameter Type = 14 | Parameter Length = 8 + 2 * N |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Re-configuration Request Sequence Number |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Stream Number 1 (optional) | Stream Number 2 (optional) |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * / ...... /
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Stream Number N-1 (optional) | Stream Number N (optional) |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ */
+struct sctp_chunk *sctp_make_strreset_req(
+ const struct sctp_association *asoc,
+ __u16 stream_num, __u16 *stream_list,
+ bool out, bool in)
+{
+ struct sctp_strreset_outreq outreq;
+ __u16 stream_len = stream_num * 2;
+ struct sctp_strreset_inreq inreq;
+ struct sctp_chunk *retval;
+ __u16 outlen, inlen, i;
+
+ outlen = (sizeof(outreq) + stream_len) * out;
+ inlen = (sizeof(inreq) + stream_len) * in;
+
+ retval = sctp_make_reconf(asoc, outlen + inlen);
+ if (!retval)
+ return NULL;
+
+ for (i = 0; i < stream_num; i++)
+ stream_list[i] = htons(stream_list[i]);
+
+ if (outlen) {
+ outreq.param_hdr.type = SCTP_PARAM_RESET_OUT_REQUEST;
+ outreq.param_hdr.length = htons(outlen);
+ outreq.request_seq = htonl(asoc->strreset_outseq);
+ outreq.response_seq = htonl(asoc->strreset_inseq - 1);
+ outreq.send_reset_at_tsn = htonl(asoc->next_tsn - 1);
+
+ sctp_addto_chunk(retval, sizeof(outreq), &outreq);
+
+ if (stream_len)
+ sctp_addto_chunk(retval, stream_len, stream_list);
+ }
+
+ if (inlen) {
+ inreq.param_hdr.type = SCTP_PARAM_RESET_IN_REQUEST;
+ inreq.param_hdr.length = htons(inlen);
+ inreq.request_seq = htonl(asoc->strreset_outseq + out);
+
+ sctp_addto_chunk(retval, sizeof(inreq), &inreq);
+
+ if (stream_len)
+ sctp_addto_chunk(retval, stream_len, stream_list);
+ }
+
+ for (i = 0; i < stream_num; i++)
+ stream_list[i] = ntohs(stream_list[i]);
+
+ return retval;
+}
--
2.1.0
^ permalink raw reply related
* [PATCHv2 net-next 3/5] sctp: add support for generating stream reconf ssn/tsn reset request chunk
From: Xin Long @ 2017-01-07 9:43 UTC (permalink / raw)
To: network dev, linux-sctp
Cc: Marcelo Ricardo Leitner, Neil Horman, Vlad Yasevich, davem
In-Reply-To: <cover.1483781759.git.lucien.xin@gmail.com>
This patch is to define SSN/TSN Reset Request Parameter described
in rfc6525 section 4.3.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
include/linux/sctp.h | 5 +++++
include/net/sctp/sm.h | 2 ++
net/sctp/sm_make_chunk.c | 29 +++++++++++++++++++++++++++++
3 files changed, 36 insertions(+)
diff --git a/include/linux/sctp.h b/include/linux/sctp.h
index d5da19c..cc4c74d 100644
--- a/include/linux/sctp.h
+++ b/include/linux/sctp.h
@@ -742,4 +742,9 @@ struct sctp_strreset_inreq {
__u16 list_of_streams[0];
} __packed;
+struct sctp_strreset_tsnreq {
+ sctp_paramhdr_t param_hdr;
+ __u32 request_seq;
+} __packed;
+
#endif /* __LINUX_SCTP_H__ */
diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h
index 3462cb0..c658700 100644
--- a/include/net/sctp/sm.h
+++ b/include/net/sctp/sm.h
@@ -263,6 +263,8 @@ struct sctp_chunk *sctp_make_strreset_req(
const struct sctp_association *asoc,
__u16 stream_num, __u16 *stream_list,
bool out, bool in);
+struct sctp_chunk *sctp_make_strreset_tsnreq(
+ const struct sctp_association *asoc);
void sctp_chunk_assign_tsn(struct sctp_chunk *);
void sctp_chunk_assign_ssn(struct sctp_chunk *);
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index 172385c..f1d8f07 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -3647,3 +3647,32 @@ struct sctp_chunk *sctp_make_strreset_req(
return retval;
}
+
+/* RE-CONFIG 4.3 (SSN/TSN RESET ALL)
+ * 0 1 2 3
+ * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Parameter Type = 15 | Parameter Length = 8 |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Re-configuration Request Sequence Number |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ */
+struct sctp_chunk *sctp_make_strreset_tsnreq(
+ const struct sctp_association *asoc)
+{
+ struct sctp_strreset_tsnreq tsnreq;
+ __u16 length = sizeof(tsnreq);
+ struct sctp_chunk *retval;
+
+ retval = sctp_make_reconf(asoc, length);
+ if (!retval)
+ return NULL;
+
+ tsnreq.param_hdr.type = SCTP_PARAM_RESET_TSN_REQUEST;
+ tsnreq.param_hdr.length = htons(length);
+ tsnreq.request_seq = htonl(asoc->strreset_outseq);
+
+ sctp_addto_chunk(retval, sizeof(tsnreq), &tsnreq);
+
+ return retval;
+}
--
2.1.0
^ permalink raw reply related
* [PATCHv2 net-next 4/5] sctp: add support for generating stream reconf response chunk
From: Xin Long @ 2017-01-07 9:43 UTC (permalink / raw)
To: network dev, linux-sctp
Cc: Marcelo Ricardo Leitner, Neil Horman, Vlad Yasevich, davem
In-Reply-To: <cover.1483781759.git.lucien.xin@gmail.com>
This patch is to define Re-configuration Response Parameter described
in rfc6525 section 4.4. As optional fields are only for SSN/TSN Reset
Request Parameter, it uses another function to make that.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
include/linux/sctp.h | 24 ++++++++++++++++
include/net/sctp/sm.h | 7 +++++
net/sctp/sm_make_chunk.c | 74 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 105 insertions(+)
diff --git a/include/linux/sctp.h b/include/linux/sctp.h
index cc4c74d..c4fcc7d 100644
--- a/include/linux/sctp.h
+++ b/include/linux/sctp.h
@@ -747,4 +747,28 @@ struct sctp_strreset_tsnreq {
__u32 request_seq;
} __packed;
+enum {
+ SCTP_STRRESET_NOTHING_TO_DO = 0x00,
+ SCTP_STRRESET_PERFORMED = 0x01,
+ SCTP_STRRESET_DENIED = 0x02,
+ SCTP_STRRESET_ERR_WRONG_SSN = 0x03,
+ SCTP_STRRESET_ERR_IN_PROGRESS = 0x04,
+ SCTP_STRRESET_ERR_BAD_SEQNO = 0x05,
+ SCTP_STRRESET_IN_PROGRESS = 0x06,
+};
+
+struct sctp_strreset_resp {
+ sctp_paramhdr_t param_hdr;
+ __u32 response_seq;
+ __u32 result;
+} __packed;
+
+struct sctp_strreset_resptsn {
+ sctp_paramhdr_t param_hdr;
+ __u32 response_seq;
+ __u32 result;
+ __u32 senders_next_tsn;
+ __u32 receivers_next_tsn;
+} __packed;
+
#endif /* __LINUX_SCTP_H__ */
diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h
index c658700..013d69f 100644
--- a/include/net/sctp/sm.h
+++ b/include/net/sctp/sm.h
@@ -265,6 +265,13 @@ struct sctp_chunk *sctp_make_strreset_req(
bool out, bool in);
struct sctp_chunk *sctp_make_strreset_tsnreq(
const struct sctp_association *asoc);
+struct sctp_chunk *sctp_make_strreset_resp(
+ const struct sctp_association *asoc,
+ __u32 result, __u32 sn);
+struct sctp_chunk *sctp_make_strreset_tsnresp(
+ struct sctp_association *asoc,
+ __u32 result, __u32 sn,
+ __u32 sender_tsn, __u32 receiver_tsn);
void sctp_chunk_assign_tsn(struct sctp_chunk *);
void sctp_chunk_assign_ssn(struct sctp_chunk *);
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index f1d8f07..34edb30 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -3676,3 +3676,77 @@ struct sctp_chunk *sctp_make_strreset_tsnreq(
return retval;
}
+
+/* RE-CONFIG 4.4 (RESP)
+ * 0 1 2 3
+ * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Parameter Type = 16 | Parameter Length |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Re-configuration Response Sequence Number |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Result |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ */
+struct sctp_chunk *sctp_make_strreset_resp(
+ const struct sctp_association *asoc,
+ __u32 result, __u32 sn)
+{
+ struct sctp_strreset_resp resp;
+ __u16 length = sizeof(resp);
+ struct sctp_chunk *retval;
+
+ retval = sctp_make_reconf(asoc, length);
+ if (!retval)
+ return NULL;
+
+ resp.param_hdr.type = SCTP_PARAM_RESET_RESPONSE;
+ resp.param_hdr.length = htons(length);
+ resp.response_seq = htonl(sn);
+ resp.result = htonl(result);
+
+ sctp_addto_chunk(retval, sizeof(resp), &resp);
+
+ return retval;
+}
+
+/* RE-CONFIG 4.4 OPTIONAL (TSNRESP)
+ * 0 1 2 3
+ * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Parameter Type = 16 | Parameter Length |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Re-configuration Response Sequence Number |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Result |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Sender's Next TSN (optional) |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Receiver's Next TSN (optional) |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ */
+struct sctp_chunk *sctp_make_strreset_tsnresp(
+ struct sctp_association *asoc,
+ __u32 result, __u32 sn,
+ __u32 sender_tsn, __u32 receiver_tsn)
+{
+ struct sctp_strreset_resptsn tsnresp;
+ __u16 length = sizeof(tsnresp);
+ struct sctp_chunk *retval;
+
+ retval = sctp_make_reconf(asoc, length);
+ if (!retval)
+ return NULL;
+
+ tsnresp.param_hdr.type = SCTP_PARAM_RESET_RESPONSE;
+ tsnresp.param_hdr.length = htons(length);
+
+ tsnresp.response_seq = htonl(sn);
+ tsnresp.result = htonl(result);
+ tsnresp.senders_next_tsn = htonl(sender_tsn);
+ tsnresp.receivers_next_tsn = htonl(receiver_tsn);
+
+ sctp_addto_chunk(retval, sizeof(tsnresp), &tsnresp);
+
+ return retval;
+}
--
2.1.0
^ permalink raw reply related
* [PATCHv2 net-next 5/5] sctp: add support for generating stream reconf add streams request chunk
From: Xin Long @ 2017-01-07 9:43 UTC (permalink / raw)
To: network dev, linux-sctp
Cc: Marcelo Ricardo Leitner, Neil Horman, Vlad Yasevich, davem
In-Reply-To: <cover.1483781759.git.lucien.xin@gmail.com>
This patch is to define Add Incoming/Outgoing Streams Request
Parameter described in rfc6525 section 4.5 and 4.6. They can
be in one same chunk trunk as rfc6525 section 3.1-7 describes,
so make them in one function.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
include/linux/sctp.h | 7 +++++++
include/net/sctp/sm.h | 3 +++
net/sctp/sm_make_chunk.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 56 insertions(+)
diff --git a/include/linux/sctp.h b/include/linux/sctp.h
index c4fcc7d..3a9f234 100644
--- a/include/linux/sctp.h
+++ b/include/linux/sctp.h
@@ -771,4 +771,11 @@ struct sctp_strreset_resptsn {
__u32 receivers_next_tsn;
} __packed;
+struct sctp_strreset_addstrm {
+ sctp_paramhdr_t param_hdr;
+ __u32 request_seq;
+ __u16 number_of_streams;
+ __u16 reserved;
+} __packed;
+
#endif /* __LINUX_SCTP_H__ */
diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h
index 013d69f..35986d0 100644
--- a/include/net/sctp/sm.h
+++ b/include/net/sctp/sm.h
@@ -272,6 +272,9 @@ struct sctp_chunk *sctp_make_strreset_tsnresp(
struct sctp_association *asoc,
__u32 result, __u32 sn,
__u32 sender_tsn, __u32 receiver_tsn);
+struct sctp_chunk *sctp_make_strreset_addstrm(
+ const struct sctp_association *asoc,
+ __u16 out, __u16 in);
void sctp_chunk_assign_tsn(struct sctp_chunk *);
void sctp_chunk_assign_ssn(struct sctp_chunk *);
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index 34edb30..e6a5530 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -3750,3 +3750,49 @@ struct sctp_chunk *sctp_make_strreset_tsnresp(
return retval;
}
+
+/* RE-CONFIG 4.5/4.6 (ADD STREAM)
+ * 0 1 2 3
+ * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Parameter Type = 17 | Parameter Length = 12 |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Re-configuration Request Sequence Number |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * | Number of new streams | Reserved |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ */
+struct sctp_chunk *sctp_make_strreset_addstrm(
+ const struct sctp_association *asoc,
+ __u16 out, __u16 in)
+{
+ struct sctp_strreset_addstrm addstrm;
+ __u16 length = sizeof(addstrm);
+ struct sctp_chunk *retval;
+
+ retval = sctp_make_reconf(asoc, (!!out + !!in) * length);
+ if (!retval)
+ return NULL;
+
+ if (out) {
+ addstrm.param_hdr.type = SCTP_PARAM_RESET_ADD_OUT_STREAMS;
+ addstrm.param_hdr.length = htons(length);
+ addstrm.number_of_streams = htons(out);
+ addstrm.request_seq = htonl(asoc->strreset_outseq);
+ addstrm.reserved = 0;
+
+ sctp_addto_chunk(retval, length, &addstrm);
+ }
+
+ if (in) {
+ addstrm.param_hdr.type = SCTP_PARAM_RESET_ADD_IN_STREAMS;
+ addstrm.param_hdr.length = htons(length);
+ addstrm.number_of_streams = htons(in);
+ addstrm.request_seq = htonl(asoc->strreset_outseq + !!out);
+ addstrm.reserved = 0;
+
+ sctp_addto_chunk(retval, length, &addstrm);
+ }
+
+ return retval;
+}
--
2.1.0
^ permalink raw reply related
* [PATCH] fix itnull.cocci warnings
From: Julia Lawall @ 2017-01-07 9:46 UTC (permalink / raw)
To: Harsh Jain
Cc: hariprasad, netdev, herbert, linux-crypto, Atul Gupta, kbuild-all
The first argument to list_for_each_entry cannot be NULL.
Generated by: scripts/coccinelle/iterators/itnull.cocci
CC: Harsh Jain <harsh@chelsio.com>
Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
This code comes from the following git tree:
url:
https://github.com/0day-ci/linux/commits/Harsh-Jain/crypto-chcr-Bug-fixes/20170107-093356
base:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
master
In-Reply-To:
<8e0086b56d8fb61637d179c32a09a1bca03c4186.1483599449.git.harsh@chelsio.com>
chcr_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/crypto/chelsio/chcr_core.c
+++ b/drivers/crypto/chelsio/chcr_core.c
@@ -61,7 +61,7 @@ int assign_chcr_device(struct chcr_dev *
*/
mutex_lock(&dev_mutex); /* TODO ? */
list_for_each_entry(u_ctx, &uld_ctx_list, entry)
- if (u_ctx && u_ctx->dev) {
+ if (u_ctx->dev) {
*dev = u_ctx->dev;
ret = 0;
break;
^ permalink raw reply
* Re: [PATCH v2 12/12] net: ethernet: aquantia: Receive side scaling
From: kbuild test robot @ 2017-01-07 9:48 UTC (permalink / raw)
To: Alexander Loktionov
Cc: kbuild-all, netdev, David VomLehn, Simon Edelhaus,
Alexander Loktionov, Dmitrii Tarakanov, Pavel Belous
In-Reply-To: <22b9276ab1020a75c13aa2714922434886446d69.1483689029.git.vomlehn@texas.net>
Hi David,
[auto build test WARNING on net-next/master]
[also build test WARNING on v4.10-rc2 next-20170106]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Alexander-Loktionov/net-ethernet-aquantia-Add-AQtion-2-5-5-GB-NIC-driver/20170107-100651
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
include/linux/compiler.h:253:8: sparse: attribute 'no_sanitize_address': unknown attribute
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
--
include/linux/compiler.h:253:8: sparse: attribute 'no_sanitize_address': unknown attribute
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
--
include/linux/compiler.h:253:8: sparse: attribute 'no_sanitize_address': unknown attribute
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
--
include/linux/compiler.h:253:8: sparse: attribute 'no_sanitize_address': unknown attribute
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
>> drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h:44:28: sparse: marked inline, but without a definition
vim +44 drivers/net/ethernet/aquantia/hw_atl/../aq_hw_utils.h
96511018 David VomLehn 2017-01-06 28 unsigned int AQ_HW_WAIT_FOR_i; \
96511018 David VomLehn 2017-01-06 29 for (AQ_HW_WAIT_FOR_i = _N_; (!(_B_)) && (AQ_HW_WAIT_FOR_i);\
96511018 David VomLehn 2017-01-06 30 --AQ_HW_WAIT_FOR_i) {\
96511018 David VomLehn 2017-01-06 31 udelay(_US_); \
96511018 David VomLehn 2017-01-06 32 } \
96511018 David VomLehn 2017-01-06 33 if (!AQ_HW_WAIT_FOR_i) {\
96511018 David VomLehn 2017-01-06 34 err = ETIME; \
96511018 David VomLehn 2017-01-06 35 } \
96511018 David VomLehn 2017-01-06 36 } while (0)
96511018 David VomLehn 2017-01-06 37
96511018 David VomLehn 2017-01-06 38 struct aq_hw_s;
96511018 David VomLehn 2017-01-06 39
96511018 David VomLehn 2017-01-06 40 void aq_hw_write_reg_bit(struct aq_hw_s *aq_hw, u32 addr, u32 msk,
96511018 David VomLehn 2017-01-06 41 u32 shift, u32 val);
96511018 David VomLehn 2017-01-06 42 u32 aq_hw_read_reg_bit(struct aq_hw_s *aq_hw, u32 addr, u32 msk, u32 shift);
96511018 David VomLehn 2017-01-06 43 u32 aq_hw_read_reg(struct aq_hw_s *hw, u32 reg);
96511018 David VomLehn 2017-01-06 @44 inline void aq_hw_write_reg(struct aq_hw_s *hw, u32 reg, u32 value);
96511018 David VomLehn 2017-01-06 45 int aq_hw_err_from_flags(struct aq_hw_s *hw);
96511018 David VomLehn 2017-01-06 46
96511018 David VomLehn 2017-01-06 47 #endif /* AQ_HW_UTILS_H */
:::::: The code at line 44 was first introduced by commit
:::::: 9651101834438045cb888ea0bea44cc575b69d03 net: ethernet: aquantia: Hardware interface and utility functions
:::::: TO: David VomLehn <vomlehn@texas.net>
:::::: CC: 0day robot <fengguang.wu@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [net-next PATCH] net: reduce cycles spend on ICMP replies that gets rate limited
From: Jesper Dangaard Brouer @ 2017-01-07 10:31 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev, brouer, xiyou.wangcong
In-Reply-To: <20170106.221042.1641025960219244932.davem@davemloft.net>
On Fri, 06 Jan 2017 22:10:42 -0500 (EST)
David Miller <davem@davemloft.net> wrote:
> BTW Eric, you asked about kmalloc() allocation, you were CC:'d in the
> patch which did this :-)
>
> commit 9a99d4a50cb8ce516adf0f2436138d4c8e6e4535
> Author: Cong Wang <amwang@redhat.com>
> Date: Sun Jun 2 15:00:52 2013 +0000
>
> icmp: avoid allocating large struct on stack
>
> struct icmp_bxm is a large struct, reduce stack usage
> by allocating it on heap.
>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Joe Perches <joe@perches.com>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Did a quick revert, and tested again. It is not the major bottleneck,
but we do save something. The major bottleneck is still the call to
__ip_route_output_key_hash (invoked by icmp_route_lookup).
Single flow improvement from 1719182 pps to 1783368 pps.
- 64186 pps
- (1/1783368-1/1719182)*10^9 = -20.93 nanosec
* 4GHz approx = 20.93*4 = 83.72 cycles
The optimal SLUB fast-path on this machine is 54 cycles(tsc) 13.557 ns,
thus the saving is actually higher than expected. But low compared to
avoiding the icmp_route_lookup.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: M. Braun @ 2017-01-07 10:32 UTC (permalink / raw)
To: Johannes Berg, Felix Fietkau, Linus Lüssing, netdev
Cc: bridge, linux-wireless, David S . Miller, linux-kernel
In-Reply-To: <1483710841.12677.1.camel@sipsolutions.net>
Am 06.01.2017 um 14:54 schrieb Johannes Berg:
>
>> The bridge layer can use IGMP snooping to ensure that the multicast
>> stream is only transmitted to clients that are actually a member of
>> the group. Can the mac80211 feature do the same?
>
> No, it'll convert the packet for all clients that are behind that
> netdev. But that's an argument for dropping the mac80211 feature, which
> hasn't been merged upstream yet, no?
But there is multicast/broadcast traffic like e.g. ARP and some IP
multicast groups that are not covered by IGMP snooping. The mac80211
patch converts this to unicast as well, which the bridge cannot do.
That way, these features both complement and overlap each other.
Regards,
Michael
^ permalink raw reply
* Re: [PATCHv1 2/7] TAP: Renaming tap related APIs, data structures, macros
From: kbuild test robot @ 2017-01-07 10:44 UTC (permalink / raw)
To: Sainath Grandhi
Cc: kbuild-all, netdev, davem, mahesh, linux-kernel, Sainath Grandhi
In-Reply-To: <1483742009-19184-3-git-send-email-sainath.grandhi@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]
Hi Sainath,
[auto build test ERROR on net/master]
[also build test ERROR on v4.10-rc2 next-20170106]
[cannot apply to net-next/master]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sainath-Grandhi/Refactor-macvtap-to-re-use-tap-functionality-by-other-virtual-intefaces/20170107-165707
config: powerpc-defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
>> ERROR: ".tap_get_socket" [drivers/vhost/vhost_net.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 22529 bytes --]
^ permalink raw reply
* Re: [PATCHv1 6/7] TAP: tap as an independent module
From: kbuild test robot @ 2017-01-07 10:46 UTC (permalink / raw)
To: Sainath Grandhi
Cc: kbuild-all, netdev, davem, mahesh, linux-kernel, Sainath Grandhi
In-Reply-To: <1483742009-19184-7-git-send-email-sainath.grandhi@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1468 bytes --]
Hi Sainath,
[auto build test ERROR on net/master]
[also build test ERROR on v4.10-rc2 next-20170106]
[cannot apply to net-next/master]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sainath-Grandhi/Refactor-macvtap-to-re-use-tap-functionality-by-other-virtual-intefaces/20170107-165707
config: s390-default_defconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=s390
All errors (new ones prefixed by >>):
ERROR: "tap_get_socket" [drivers/vhost/vhost_net.ko] undefined!
>> ERROR: "tap_create_cdev" [drivers/net/macvtap.ko] undefined!
>> ERROR: "tap_queue_resize" [drivers/net/macvtap.ko] undefined!
>> ERROR: "tap_get_minor" [drivers/net/macvtap.ko] undefined!
>> ERROR: "tap_destroy_cdev" [drivers/net/macvtap.ko] undefined!
>> ERROR: "tap_handle_frame" [drivers/net/macvtap.ko] undefined!
>> ERROR: "tap_free_minor" [drivers/net/macvtap.ko] undefined!
>> ERROR: "tap_del_queues" [drivers/net/macvtap.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 16728 bytes --]
^ permalink raw reply
* Re: [PATCHv2 net-next 11/16] net: mvpp2: handle misc PPv2.1/PPv2.2 differences
From: Russell King - ARM Linux @ 2017-01-07 11:03 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: netdev, David S. Miller, devicetree, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, Andrew Lunn,
Yehuda Yitschak, Jason Cooper, Hanna Hawa, Nadav Haklai,
Gregory Clement, Stefan Chulski, Marcin Wojtas, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <1482943592-12556-12-git-send-email-thomas.petazzoni@free-electrons.com>
On Wed, Dec 28, 2016 at 05:46:27PM +0100, Thomas Petazzoni wrote:
> +#define MVPP22_SMI_MISC_CFG_REG 0x2a204
> +#define MVPP22_SMI_POLLING_EN BIT(10)
> +
...
> + if (priv->hw_version == MVPP21) {
> + val = readl(priv->lms_base + MVPP2_PHY_AN_CFG0_REG);
> + val |= MVPP2_PHY_AN_STOP_SMI0_MASK;
> + writel(val, priv->lms_base + MVPP2_PHY_AN_CFG0_REG);
> + } else {
> + val = readl(priv->iface_base + MVPP22_SMI_MISC_CFG_REG);
> + val &= ~MVPP22_SMI_POLLING_EN;
> + writel(val, priv->iface_base + MVPP22_SMI_MISC_CFG_REG);
> + }
The MVPP22_SMI_MISC_CFG_REG register is within the MDIO driver's
register set, although the mvmdio driver does not access this register.
Shouldn't this be taken care of by the mvmdio driver?
Also, a point that I've noticed while reviewing this is the mvmdio
driver also accesses these registers:
#define MVMDIO_ERR_INT_CAUSE 0x007C
#define MVMDIO_ERR_INT_MASK 0x0080
in addition to the un-named register at offset 0. The driver writes
to these registers unconditionally when unbinding:
writel(0, dev->regs + MVMDIO_ERR_INT_MASK);
However, the various bindings for the driver have:
arch/arm/boot/dts/armada-370-xp.dtsi: compatible = "marvell,orion-mdio";
arch/arm/boot/dts/armada-370-xp.dtsi- reg = <0x72004 0x4>;
arch/arm/boot/dts/armada-375.dtsi: compatible = "marvell,orion-mdio";
arch/arm/boot/dts/armada-375.dtsi- reg = <0xc0054 0x4>;
arch/arm/boot/dts/dove.dtsi: compatible = "marvell,orion-mdio";
arch/arm/boot/dts/dove.dtsi- #address-cells = <1>;
arch/arm/boot/dts/dove.dtsi- #size-cells = <0>;
arch/arm/boot/dts/dove.dtsi- reg = <0x72004 0x84>;
arch/arm/boot/dts/orion5x.dtsi: compatible = "marvell,orion-mdio";
arch/arm/boot/dts/orion5x.dtsi- #address-cells = <1>;
arch/arm/boot/dts/orion5x.dtsi- #size-cells = <0>;
arch/arm/boot/dts/orion5x.dtsi- reg = <0x72004 0x84>;
arch/arm/boot/dts/kirkwood.dtsi: compatible = "marvell,orion-mdio";
arch/arm/boot/dts/kirkwood.dtsi- #address-cells = <1>;
arch/arm/boot/dts/kirkwood.dtsi- #size-cells = <0>;
arch/arm/boot/dts/kirkwood.dtsi- reg = <0x72004 0x84>;
arch/arm/boot/dts/armada-38x.dtsi: compatible = "marvell,orion-mdio";
arch/arm/boot/dts/armada-38x.dtsi- reg = <0x72004 0x4>;
So, for many of these, we're accessing registers outside of the given
binding, which sounds incorrect. I guess that write should be
conditional upon an interrupt being present.
The binding document says:
- reg: address and length of the SMI register
which is clearly wrong for those cases where the interrupt is used.
I also notice that the binding for CP110 uses a register size of 0x10
(even in your tree) - but I guess this should be 4.
I'm starting to wonder whether the orion-mdio driver really is a
separate chunk of hardware that warrants a separate description in
DT from the ethernet controller - it appears in all cases to be
embedded with an ethernet controller, sharing its register space
and at least some of the ethernet controllers clocks. That says
to me that it isn't an independent functional unit of hardware.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH RFC 0/4] Fix orion-mdio resource/interrupt issues indentified while reviewing mvpp2
From: Russell King - ARM Linux @ 2017-01-07 11:26 UTC (permalink / raw)
To: Thomas Petazzoni, Andrew Lunn, Jason Cooper, Gregory Clement,
Mark Rutland, Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Marcin Wojtas,
netdev-u79uwXL29TY76Z2rM5mHXA, Sebastian Hesselbarth
This patch series fixes some issues identified while reviewing the
mvpp2 driver changes recently posted by Thomas. I've left the clock
issue, and the question over whether this should be separate out of
this series, concentrating on the resource size / interrupt issue.
This series updates the binding to reflect reality, and ensures that
the driver will not try to access registers outside its binding. It
also ensures that it doesn't leave the interrupt enabled in hardware
on probe failure.
.../devicetree/bindings/net/marvell-orion-mdio.txt | 17 +++++++++++++++--
drivers/net/ethernet/marvell/mvmdio.c | 11 ++++++++++-
2 files changed, 25 insertions(+), 3 deletions(-)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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
* [PATCH RFC 3/4] dt-bindings: correct marvell orion MDIO binding document
From: Russell King @ 2017-01-07 11:28 UTC (permalink / raw)
To: Thomas Petazzoni, Andrew Lunn, Jason Cooper, Gregory Clement,
Mark Rutland, Rob Herring
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Marcin Wojtas,
Sebastian Hesselbarth, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170107112656.GL14217-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
Correct the Marvell Orion MDIO binding document to properly reflect the
cases where an interrupt is present. Augment the examples to show this.
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
.../devicetree/bindings/net/marvell-orion-mdio.txt | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
index 9417e54c26c0..ca733ff68ab9 100644
--- a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
+++ b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
@@ -7,7 +7,10 @@ interface.
Required properties:
- compatible: "marvell,orion-mdio"
-- reg: address and length of the SMI register
+- reg: address and length of the MDIO registers. When an interrupt is
+ not present, the length is the size of the SMI register (4 bytes)
+ otherwise it must be 0x84 bytes to cover the interrupt control
+ registers.
Optional properties:
- interrupts: interrupt line number for the SMI error/done interrupt
@@ -17,7 +20,7 @@ The child nodes of the MDIO driver are the individual PHY devices
connected to this MDIO bus. They must have a "reg" property given the
PHY address on the MDIO bus.
-Example at the SoC level:
+Example at the SoC level without an interrupt property:
mdio {
#address-cells = <1>;
@@ -26,6 +29,16 @@ mdio {
reg = <0xd0072004 0x4>;
};
+Example with an interrupt property:
+
+mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "marvell,orion-mdio";
+ reg = <0xd0072004 0x84>;
+ interrupts = <30>;
+};
+
And at the board level:
mdio {
--
2.7.4
--
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 related
* [PATCH RFC 1/4] net: mvmdio: disable interrupts in driver failure path
From: Russell King @ 2017-01-07 11:28 UTC (permalink / raw)
To: Thomas Petazzoni, Andrew Lunn, Jason Cooper, Gregory Clement,
Mark Rutland, Rob Herring
Cc: linux-arm-kernel, Marcin Wojtas, Sebastian Hesselbarth, netdev
In-Reply-To: <20170107112656.GL14217@n2100.armlinux.org.uk>
When the mvmdio driver has an interrupt, it enables the "done" interrupt
after requesting its interrupt handler. However, probe failure results
in the interrupt being left enabled. Disable it on the failure path.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/marvell/mvmdio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
index a0d1b084ecec..7aea0beca56e 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -251,6 +251,8 @@ static int orion_mdio_probe(struct platform_device *pdev)
return 0;
out_mdio:
+ if (dev->err_interrupt > 0)
+ writel(0, dev->regs + MVMDIO_ERR_INT_MASK);
if (!IS_ERR(dev->clk))
clk_disable_unprepare(dev->clk);
return ret;
--
2.7.4
^ permalink raw reply related
* [PATCH RFC 2/4] net: mvmdio: fix interrupt disable in remove path
From: Russell King @ 2017-01-07 11:28 UTC (permalink / raw)
To: Thomas Petazzoni, Andrew Lunn, Jason Cooper, Gregory Clement,
Mark Rutland, Rob Herring
Cc: linux-arm-kernel, Marcin Wojtas, Sebastian Hesselbarth, netdev
In-Reply-To: <20170107112656.GL14217@n2100.armlinux.org.uk>
The pre-existing write to disable interrupts on the remove path happens
whether we have an interrupt or not. While this may seem to be a good
idea, this driver is re-used in many different implementations, some
where the binding only specifies four bytes of register space. This
access causes us to access registers outside of the binding.
Make it conditional on the interrupt being present, which is the same
condition used when enabling the interrupt in the first place.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/marvell/mvmdio.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
index 7aea0beca56e..6ea5caddca62 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -263,7 +263,8 @@ static int orion_mdio_remove(struct platform_device *pdev)
struct mii_bus *bus = platform_get_drvdata(pdev);
struct orion_mdio_dev *dev = bus->priv;
- writel(0, dev->regs + MVMDIO_ERR_INT_MASK);
+ if (dev->err_interrupt > 0)
+ writel(0, dev->regs + MVMDIO_ERR_INT_MASK);
mdiobus_unregister(bus);
if (!IS_ERR(dev->clk))
clk_disable_unprepare(dev->clk);
--
2.7.4
^ permalink raw reply related
* [PATCH RFC 4/4] net: mvmdio: disable interrupt if resource size is too small
From: Russell King @ 2017-01-07 11:28 UTC (permalink / raw)
To: Thomas Petazzoni, Andrew Lunn, Jason Cooper, Gregory Clement,
Mark Rutland, Rob Herring
Cc: linux-arm-kernel, Marcin Wojtas, Sebastian Hesselbarth, netdev
In-Reply-To: <20170107112656.GL14217@n2100.armlinux.org.uk>
Disable the MDIO interrupt, falling back to polled mode, if the resource
size does not allow us to access the interrupt registers. All current
DT bindings use a size of 0x84, which allows access, but verifying it is
good practice.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/marvell/mvmdio.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
index 6ea5caddca62..614dfde657fe 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -221,6 +221,12 @@ static int orion_mdio_probe(struct platform_device *pdev)
clk_prepare_enable(dev->clk);
dev->err_interrupt = platform_get_irq(pdev, 0);
+ if (dev->err_interrupt > 0 &&
+ resource_size(r) < MVMDIO_ERR_INT_MASK + 4) {
+ dev_err(&pdev->dev,
+ "disabling interrupt, resource size is too small\n");
+ dev->err_interrupt = 0;
+ }
if (dev->err_interrupt > 0) {
ret = devm_request_irq(&pdev->dev, dev->err_interrupt,
orion_mdio_err_irq,
--
2.7.4
^ permalink raw reply related
* Re: [PATCHv1 2/7] TAP: Renaming tap related APIs, data structures, macros
From: kbuild test robot @ 2017-01-07 12:00 UTC (permalink / raw)
To: Sainath Grandhi
Cc: kbuild-all, netdev, davem, mahesh, linux-kernel, Sainath Grandhi
In-Reply-To: <1483742009-19184-3-git-send-email-sainath.grandhi@intel.com>
[-- Attachment #1: Type: text/plain, Size: 900 bytes --]
Hi Sainath,
[auto build test ERROR on net/master]
[also build test ERROR on v4.10-rc2 next-20170106]
[cannot apply to net-next/master]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sainath-Grandhi/Refactor-macvtap-to-re-use-tap-functionality-by-other-virtual-intefaces/20170107-165707
config: x86_64-acpi-redef (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/built-in.o: In function `vhost_net_ioctl':
>> net.c:(.text+0x68e0b1): undefined reference to `tap_get_socket'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 28924 bytes --]
^ permalink raw reply
* Re: [PATCHv2 net-next 11/16] net: mvpp2: handle misc PPv2.1/PPv2.2 differences
From: Marcin Wojtas @ 2017-01-07 12:12 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Thomas Petazzoni, devicetree@vger.kernel.org, Yehuda Yitschak,
Jason Cooper, Pawel Moll, Ian Campbell, netdev, Hanna Hawa,
Nadav Haklai, Rob Herring, Andrew Lunn, Kumar Gala,
Gregory Clement, Stefan Chulski, Mark Rutland, David S. Miller,
linux-arm-kernel@lists.infradead.org, Sebastian Hesselbarth
In-Reply-To: <20170107110351.GK14217@n2100.armlinux.org.uk>
Hi Russel,
2017-01-07 12:03 GMT+01:00 Russell King - ARM Linux <linux@armlinux.org.uk>:
> On Wed, Dec 28, 2016 at 05:46:27PM +0100, Thomas Petazzoni wrote:
>> +#define MVPP22_SMI_MISC_CFG_REG 0x2a204
>> +#define MVPP22_SMI_POLLING_EN BIT(10)
>> +
> ...
>> + if (priv->hw_version == MVPP21) {
>> + val = readl(priv->lms_base + MVPP2_PHY_AN_CFG0_REG);
>> + val |= MVPP2_PHY_AN_STOP_SMI0_MASK;
>> + writel(val, priv->lms_base + MVPP2_PHY_AN_CFG0_REG);
>> + } else {
>> + val = readl(priv->iface_base + MVPP22_SMI_MISC_CFG_REG);
>> + val &= ~MVPP22_SMI_POLLING_EN;
>> + writel(val, priv->iface_base + MVPP22_SMI_MISC_CFG_REG);
>> + }
>
> The MVPP22_SMI_MISC_CFG_REG register is within the MDIO driver's
> register set, although the mvmdio driver does not access this register.
> Shouldn't this be taken care of by the mvmdio driver?
>
> Also, a point that I've noticed while reviewing this is the mvmdio
> driver also accesses these registers:
>
> #define MVMDIO_ERR_INT_CAUSE 0x007C
> #define MVMDIO_ERR_INT_MASK 0x0080
>
> in addition to the un-named register at offset 0. The driver writes
> to these registers unconditionally when unbinding:
>
> writel(0, dev->regs + MVMDIO_ERR_INT_MASK);
>
> However, the various bindings for the driver have:
>
> arch/arm/boot/dts/armada-370-xp.dtsi: compatible = "marvell,orion-mdio";
> arch/arm/boot/dts/armada-370-xp.dtsi- reg = <0x72004 0x4>;
> arch/arm/boot/dts/armada-375.dtsi: compatible = "marvell,orion-mdio";
> arch/arm/boot/dts/armada-375.dtsi- reg = <0xc0054 0x4>;
> arch/arm/boot/dts/dove.dtsi: compatible = "marvell,orion-mdio";
> arch/arm/boot/dts/dove.dtsi- #address-cells = <1>;
> arch/arm/boot/dts/dove.dtsi- #size-cells = <0>;
> arch/arm/boot/dts/dove.dtsi- reg = <0x72004 0x84>;
> arch/arm/boot/dts/orion5x.dtsi: compatible = "marvell,orion-mdio";
> arch/arm/boot/dts/orion5x.dtsi- #address-cells = <1>;
> arch/arm/boot/dts/orion5x.dtsi- #size-cells = <0>;
> arch/arm/boot/dts/orion5x.dtsi- reg = <0x72004 0x84>;
> arch/arm/boot/dts/kirkwood.dtsi: compatible = "marvell,orion-mdio";
> arch/arm/boot/dts/kirkwood.dtsi- #address-cells = <1>;
> arch/arm/boot/dts/kirkwood.dtsi- #size-cells = <0>;
> arch/arm/boot/dts/kirkwood.dtsi- reg = <0x72004 0x84>;
> arch/arm/boot/dts/armada-38x.dtsi: compatible = "marvell,orion-mdio";
> arch/arm/boot/dts/armada-38x.dtsi- reg = <0x72004 0x4>;
>
> So, for many of these, we're accessing registers outside of the given
> binding, which sounds incorrect. I guess that write should be
> conditional upon an interrupt being present.
>
> The binding document says:
>
> - reg: address and length of the SMI register
>
> which is clearly wrong for those cases where the interrupt is used.
>
> I also notice that the binding for CP110 uses a register size of 0x10
> (even in your tree) - but I guess this should be 4.
>
> I'm starting to wonder whether the orion-mdio driver really is a
> separate chunk of hardware that warrants a separate description in
> DT from the ethernet controller - it appears in all cases to be
> embedded with an ethernet controller, sharing its register space
> and at least some of the ethernet controllers clocks. That says
> to me that it isn't an independent functional unit of hardware.
>
In fact there is common SMI bus, but each port has its own register
set to control it (it's true at least for Neta and PP2). There is also
an option to use HW polling - every 1s hardware checks PHY over SMI
and updates MAC registers of each port independently. I was able to
use those successfully in other implementations.
However we are supposed to use libphy in Linux and I'm afraid we have
to use single instance that controls single SMI bus - I think current
implementation is a compromise between HW and libphy demands.
Best regards,
Marcin
^ permalink raw reply
* Re: [PATCHv1 6/7] TAP: tap as an independent module
From: kbuild test robot @ 2017-01-07 12:32 UTC (permalink / raw)
To: Sainath Grandhi
Cc: kbuild-all, netdev, davem, mahesh, linux-kernel, Sainath Grandhi
In-Reply-To: <1483742009-19184-7-git-send-email-sainath.grandhi@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1746 bytes --]
Hi Sainath,
[auto build test ERROR on net/master]
[also build test ERROR on v4.10-rc2 next-20170106]
[cannot apply to net-next/master]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sainath-Grandhi/Refactor-macvtap-to-re-use-tap-functionality-by-other-virtual-intefaces/20170107-165707
config: x86_64-allyesdebian (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/built-in.o: In function `macvtap_dellink':
>> macvtap.c:(.text+0x7d3255): undefined reference to `tap_del_queues'
drivers/built-in.o: In function `macvtap_exit':
>> macvtap.c:(.text+0x7d32e2): undefined reference to `tap_destroy_cdev'
drivers/built-in.o: In function `macvtap_init':
>> macvtap.c:(.text+0x7d3308): undefined reference to `tap_create_cdev'
drivers/built-in.o: In function `macvtap_newlink':
>> macvtap.c:(.text+0x7d33df): undefined reference to `tap_handle_frame'
drivers/built-in.o: In function `macvtap_device_event':
>> macvtap.c:(.text+0x7d34b5): undefined reference to `tap_get_minor'
>> macvtap.c:(.text+0x7d34fe): undefined reference to `tap_free_minor'
macvtap.c:(.text+0x7d3586): undefined reference to `tap_free_minor'
>> macvtap.c:(.text+0x7d3594): undefined reference to `tap_queue_resize'
drivers/built-in.o: In function `vhost_net_ioctl':
net.c:(.text+0x11835a3): undefined reference to `tap_get_socket'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 38068 bytes --]
^ permalink raw reply
* Re: [next PATCH 04/11] ixgbe: Update code to better handle incrementing page count
From: kbuild test robot @ 2017-01-07 13:06 UTC (permalink / raw)
To: Alexander Duyck; +Cc: kbuild-all, intel-wired-lan, jeffrey.t.kirsher, netdev
In-Reply-To: <20170106160654.1501.10742.stgit@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 8788 bytes --]
Hi Alexander,
[auto build test ERROR on jkirsher-next-queue/dev-queue]
[also build test ERROR on v4.10-rc2 next-20170106]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Alexander-Duyck/ixgbe-Add-support-for-writable-pages-and-build_skb/20170107-193738
base: https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git dev-queue
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=alpha
All errors (new ones prefixed by >>):
In file included from drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:60:0:
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c: In function 'ixgbe_can_reuse_rx_page':
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:1960:46: error: 'rx_ring' undeclared (first use in this function)
unsigned int last_offset = ixgbe_rx_pg_size(rx_ring) -
^
drivers/net/ethernet/intel/ixgbe/ixgbe.h:371:65: note: in definition of macro 'ixgbe_rx_pg_size'
#define ixgbe_rx_pg_size(_ring) (PAGE_SIZE << ixgbe_rx_pg_order(_ring))
^~~~~
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:1960:46: note: each undeclared identifier is reported only once for each function it appears in
unsigned int last_offset = ixgbe_rx_pg_size(rx_ring) -
^
drivers/net/ethernet/intel/ixgbe/ixgbe.h:371:65: note: in definition of macro 'ixgbe_rx_pg_size'
#define ixgbe_rx_pg_size(_ring) (PAGE_SIZE << ixgbe_rx_pg_order(_ring))
^~~~~
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c: In function 'ixgbe_fetch_rx_buffer':
>> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:2124:3: error: implicit declaration of function '__page_frag_cache_drain' [-Werror=implicit-function-declaration]
__page_frag_cache_drain(page,
^~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/__page_frag_cache_drain +2124 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
1954
1955 static bool ixgbe_can_reuse_rx_page(struct ixgbe_rx_buffer *rx_buffer,
1956 struct page *page,
1957 const unsigned int truesize)
1958 {
1959 #if (PAGE_SIZE >= 8192)
> 1960 unsigned int last_offset = ixgbe_rx_pg_size(rx_ring) -
1961 ixgbe_rx_bufsz(rx_ring);
1962 #endif
1963 unsigned int pagecnt_bias = rx_buffer->pagecnt_bias--;
1964
1965 /* avoid re-using remote pages */
1966 if (unlikely(ixgbe_page_is_reserved(page)))
1967 return false;
1968
1969 #if (PAGE_SIZE < 8192)
1970 /* if we are only owner of page we can reuse it */
1971 if (unlikely(page_count(page) != pagecnt_bias))
1972 return false;
1973
1974 /* flip page offset to other buffer */
1975 rx_buffer->page_offset ^= truesize;
1976 #else
1977 /* move offset up to the next cache line */
1978 rx_buffer->page_offset += truesize;
1979
1980 if (rx_buffer->page_offset > last_offset)
1981 return false;
1982 #endif
1983
1984 /* If we have drained the page fragment pool we need to update
1985 * the pagecnt_bias and page count so that we fully restock the
1986 * number of references the driver holds.
1987 */
1988 if (unlikely(pagecnt_bias == 1)) {
1989 page_ref_add(page, USHRT_MAX);
1990 rx_buffer->pagecnt_bias = USHRT_MAX;
1991 }
1992
1993 return true;
1994 }
1995
1996 /**
1997 * ixgbe_add_rx_frag - Add contents of Rx buffer to sk_buff
1998 * @rx_ring: rx descriptor ring to transact packets on
1999 * @rx_buffer: buffer containing page to add
2000 * @rx_desc: descriptor containing length of buffer written by hardware
2001 * @skb: sk_buff to place the data into
2002 *
2003 * This function will add the data contained in rx_buffer->page to the skb.
2004 * This is done either through a direct copy if the data in the buffer is
2005 * less than the skb header size, otherwise it will just attach the page as
2006 * a frag to the skb.
2007 *
2008 * The function will then update the page offset if necessary and return
2009 * true if the buffer can be reused by the adapter.
2010 **/
2011 static bool ixgbe_add_rx_frag(struct ixgbe_ring *rx_ring,
2012 struct ixgbe_rx_buffer *rx_buffer,
2013 unsigned int size,
2014 struct sk_buff *skb)
2015 {
2016 struct page *page = rx_buffer->page;
2017 unsigned char *va = page_address(page) + rx_buffer->page_offset;
2018 #if (PAGE_SIZE < 8192)
2019 unsigned int truesize = ixgbe_rx_bufsz(rx_ring);
2020 #else
2021 unsigned int truesize = ALIGN(size, L1_CACHE_BYTES);
2022 #endif
2023
2024 if (unlikely(skb_is_nonlinear(skb)))
2025 goto add_tail_frag;
2026
2027 if (size <= IXGBE_RX_HDR_SIZE) {
2028 memcpy(__skb_put(skb, size), va, ALIGN(size, sizeof(long)));
2029
2030 /* page is not reserved, we can reuse buffer as-is */
2031 if (likely(!ixgbe_page_is_reserved(page)))
2032 return true;
2033
2034 /* this page cannot be reused so discard it */
2035 return false;
2036 }
2037
2038 add_tail_frag:
2039 skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, page,
2040 rx_buffer->page_offset, size, truesize);
2041
2042 return ixgbe_can_reuse_rx_page(rx_buffer, page, truesize);
2043 }
2044
2045 static struct sk_buff *ixgbe_fetch_rx_buffer(struct ixgbe_ring *rx_ring,
2046 union ixgbe_adv_rx_desc *rx_desc)
2047 {
2048 unsigned int size = le16_to_cpu(rx_desc->wb.upper.length);
2049 struct ixgbe_rx_buffer *rx_buffer;
2050 struct sk_buff *skb;
2051 struct page *page;
2052
2053 rx_buffer = &rx_ring->rx_buffer_info[rx_ring->next_to_clean];
2054 page = rx_buffer->page;
2055 prefetchw(page);
2056
2057 skb = rx_buffer->skb;
2058
2059 if (likely(!skb)) {
2060 void *page_addr = page_address(page) +
2061 rx_buffer->page_offset;
2062
2063 /* prefetch first cache line of first page */
2064 prefetch(page_addr);
2065 #if L1_CACHE_BYTES < 128
2066 prefetch(page_addr + L1_CACHE_BYTES);
2067 #endif
2068
2069 /* allocate a skb to store the frags */
2070 skb = napi_alloc_skb(&rx_ring->q_vector->napi,
2071 IXGBE_RX_HDR_SIZE);
2072 if (unlikely(!skb)) {
2073 rx_ring->rx_stats.alloc_rx_buff_failed++;
2074 return NULL;
2075 }
2076
2077 /*
2078 * we will be copying header into skb->data in
2079 * pskb_may_pull so it is in our interest to prefetch
2080 * it now to avoid a possible cache miss
2081 */
2082 prefetchw(skb->data);
2083
2084 /*
2085 * Delay unmapping of the first packet. It carries the
2086 * header information, HW may still access the header
2087 * after the writeback. Only unmap it when EOP is
2088 * reached
2089 */
2090 if (likely(ixgbe_test_staterr(rx_desc, IXGBE_RXD_STAT_EOP)))
2091 goto dma_sync;
2092
2093 IXGBE_CB(skb)->dma = rx_buffer->dma;
2094 } else {
2095 if (ixgbe_test_staterr(rx_desc, IXGBE_RXD_STAT_EOP))
2096 ixgbe_dma_sync_frag(rx_ring, skb);
2097
2098 dma_sync:
2099 /* we are reusing so sync this buffer for CPU use */
2100 dma_sync_single_range_for_cpu(rx_ring->dev,
2101 rx_buffer->dma,
2102 rx_buffer->page_offset,
2103 size,
2104 DMA_FROM_DEVICE);
2105
2106 rx_buffer->skb = NULL;
2107 }
2108
2109 /* pull page into skb */
2110 if (ixgbe_add_rx_frag(rx_ring, rx_buffer, size, skb)) {
2111 /* hand second half of page back to the ring */
2112 ixgbe_reuse_rx_page(rx_ring, rx_buffer);
2113 } else {
2114 if (IXGBE_CB(skb)->dma == rx_buffer->dma) {
2115 /* the page has been released from the ring */
2116 IXGBE_CB(skb)->page_released = true;
2117 } else {
2118 /* we are not reusing the buffer so unmap it */
2119 dma_unmap_page_attrs(rx_ring->dev, rx_buffer->dma,
2120 ixgbe_rx_pg_size(rx_ring),
2121 DMA_FROM_DEVICE,
2122 IXGBE_RX_DMA_ATTR);
2123 }
> 2124 __page_frag_cache_drain(page,
2125 rx_buffer->pagecnt_bias);
2126 }
2127
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 48633 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 1/4] siphash: add cryptographically secure PRF
From: Jason A. Donenfeld @ 2017-01-07 13:11 UTC (permalink / raw)
To: Eric Biggers
Cc: David Miller, Netdev, LKML, Jean-Philippe Aumasson,
Linus Torvalds, David Laight, Eric Dumazet
In-Reply-To: <20170107040459.GA575@zzz>
Hi Eric,
Thanks for the review. I wish we had gotten to this much earlier
before the merge, when there were quite a few revisions and
refinements, but better late than never, and I'm quite pleased to have
your feedback for making this patchset perfect. Comments are inline
below.
On Sat, Jan 7, 2017 at 5:04 AM, Eric Biggers <ebiggers3@gmail.com> wrote:
> I was confused by all the functions passing siphash_key_t "by value" until I saw
> that it's actually typedefed to u64[2]. Have you considered making it a struct
> instead, something like this?
>
> typedef struct {
> u64 v[2];
> } siphash_key_t;
That's a good idea. I'll make this change.
>
>> +static inline u64 ___siphash_aligned(const __le64 *data, size_t len, const siphash_key_t key)
>> +{
>> + if (__builtin_constant_p(len) && len == 4)
>> + return siphash_1u32(le32_to_cpu(data[0]), key);
>
> Small bug here: data[0] is not valid if len is 4. This can be fixed by casting
> to a le32 pointer:
>
> return siphash_1u32(le32_to_cpup((const __le32 *)data), key);
Since data[0] is then passed to a function that takes a u32, gcc
actually does the right thing here and doesn't generate an out of
bounds read. But of course this isn't good behavior to rely on. I'll
fix this up. Thanks for catching it.
>
>> +static int __init siphash_test_init(void)
>> +{
>> + u8 in[64] __aligned(SIPHASH_ALIGNMENT);
>> + u8 in_unaligned[65];
>
> It seems that in_unaligned+1 is meant to be misaligned, but that's not
> guaranteed because in_unaligned has no alignment restriction, so it could
> theoretically be misaligned in a way that makes in_unaligned+1 aligned. So it
> should be 'in_unaligned[65] __aligned(SIPHASH_ALIGNMENT)'.
Thanks, will do.
>
> There are also a lot of checkpatch warnings produced by this patch. It looks
> like many of them can be ignored, but there may be some that should be
> addressed.
Will have a look and address for v2.
Thanks again for your review!
Regards,
Jason
^ permalink raw reply
* Re: [PATCHv2 net-next 11/16] net: mvpp2: handle misc PPv2.1/PPv2.2 differences
From: Russell King - ARM Linux @ 2017-01-07 13:50 UTC (permalink / raw)
To: Marcin Wojtas
Cc: Thomas Petazzoni, netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Ian Campbell, Pawel Moll, Mark Rutland, Kumar Gala, Andrew Lunn,
Yehuda Yitschak, Jason Cooper, Hanna Hawa, Nadav Haklai,
Gregory Clement, Stefan Chulski,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Sebastian Hesselbarth
In-Reply-To: <CAPv3WKeQ=fj2cKPyJ2NqCaAv55cOyWodujKwj3-v5iCrDYNcmA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sat, Jan 07, 2017 at 01:12:35PM +0100, Marcin Wojtas wrote:
> In fact there is common SMI bus, but each port has its own register
> set to control it (it's true at least for Neta and PP2). There is also
> an option to use HW polling - every 1s hardware checks PHY over SMI
> and updates MAC registers of each port independently. I was able to
> use those successfully in other implementations.
>
> However we are supposed to use libphy in Linux and I'm afraid we have
> to use single instance that controls single SMI bus - I think current
> implementation is a compromise between HW and libphy demands.
One of the "DT rules" is that DT only describes the hardware in an
implementation independent way. It should not describe a particular
implementation's view of the hardware.
"libphy demands" sounds very much like an implementation dictating
the DT description, which sounds to me very wrong and against the
goals and purposes of DT.
Anyway, I don't think it's too bad - a possible solution here would
be to have the existing MDIO driver as a library, which can be
instantiated by the Neta and PP2 drivers. This could be done in
DT (taking dove as an example) as:
eth: ethernet-ctrl@72000 {
compatible = "marvell,orion-eth";
reg = <0x72000 0x4000>;
ranges = <0 0x72000 0 0x4000>;
...
mdio: mdio@4 {
compatible = "marvell,orion-mdio";
reg = <4>;
...
... phys ...
};
};
I don't think that would require that big a change - and it could be
done in a way that compatibility with the existing DT descriptions is
maintained very cheaply.
Now, I'm not suggesting that mdio@4 should be created by a platform
device via marking ethernet-ctrl@72000 with "simple-bus", but it's
something that should be created by the ethernet driver if present.
The compatible string is there so we can identify that this is a
mdio node, and which type of mdio it is (the Armada 8k has this type
and a separate clause-45 xmdio implementation, and we need to
distinguish those.)
What that means is that we no longer have to worry about clocks and
overlapping register regions and the like, and can deal with the
ethernet driver wanting to access the SMI registers as well.
We would need the ethernet driver to be capable of instantiation even
with no ports enabled, so cases where the MDIO interface is used with
other ethernet controllers continues to be supportable (eg, the
Armada 8040 case where the slave CP110 ethernet controller is used
with PHYs connected to the master CP110 ethernet controller's MDIO
buses - which afaik aren't shared between the two CP110 dies.)
However, I'd like to see libphy become more flexible and support
hardware polled mode of operation, since libphy provides a nice
library of functions for accessing various phy features (like setting
the advertisment, EEE modes, flow control, etc.) Even with hardware
polling, we should still describe the PHY in DT, because PHY is part
of the hardware description, and we need to know where it is in order
to program these phy features.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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
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