* Re: [PATCH 1/1] ip-link: in human readable output use dynamic precision length
From: Christian Hesse @ 2014-11-04 10:44 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <1415093990-22632-1-git-send-email-mail@eworm.de>
[-- Attachment #1: Type: text/plain, Size: 969 bytes --]
Christian Hesse <mail@eworm.de> on Tue, 2014/11/04 10:39:
> Now that we use floating point numbers for human readable output we can
> calculate precision length on the fly.
> ---
> ip/ipaddress.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/ip/ipaddress.c b/ip/ipaddress.c
> index e240bb5..0ddcb0d 100644
> --- a/ip/ipaddress.c
> +++ b/ip/ipaddress.c
> @@ -343,8 +343,8 @@ static void print_num(FILE *fp, unsigned width,
> uint64_t count) ++prefix;
> }
>
> - snprintf(buf, sizeof(buf), "%.1f%c%s", (double) count / powi,
> - *prefix, use_iec ? "i" : "");
> + snprintf(buf, sizeof(buf), "%.*f%c%s", 3 - snprintf(NULL, 0,
> "%"PRIu64, count / powi),
> + (double) count / powi, *prefix, use_iec ? "i" : "");
>
> fprintf(fp, "%-*s ", width, buf);
> }
Damn... In IEC mode we have negative precision length for values between 1000
and 1024. Will send a new patch.
--
Best Regards,
Christian Hesse
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH v2 1/1] ip-link: in human readable output use dynamic precision length
From: Christian Hesse @ 2014-11-04 10:50 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Christian Hesse
In-Reply-To: <20141104114421.6a7f9de5@leda.localdomain>
---
ip/ipaddress.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index e240bb5..55cbc77 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -324,6 +324,7 @@ static void print_num(FILE *fp, unsigned width, uint64_t count)
const char *prefix = "kMGTPE";
const unsigned int base = use_iec ? 1024 : 1000;
uint64_t powi = 1;
+ int precision;
char buf[64];
if (!human_readable || count < base) {
@@ -343,8 +344,11 @@ static void print_num(FILE *fp, unsigned width, uint64_t count)
++prefix;
}
- snprintf(buf, sizeof(buf), "%.1f%c%s", (double) count / powi,
- *prefix, use_iec ? "i" : "");
+ if ((precision = 3 - snprintf(NULL, 0, "%"PRIu64, count / powi)) < 0)
+ precision = 0;
+
+ snprintf(buf, sizeof(buf), "%.*f%c%s", precision,
+ (double) count / powi, *prefix, use_iec ? "i" : "");
fprintf(fp, "%-*s ", width, buf);
}
--
2.1.3
^ permalink raw reply related
* Re: [PATCH] Add missing descriptions for fwmark_reflect for ipv4 and ipv6.
From: Loganaden Velvindron @ 2014-11-04 10:56 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20141030.161137.1421672304905070027.davem@davemloft.net>
t was initially sent by Lorenzo Colitti, but was subsequently
lost in the final diff he submitted.
Signed-off-by: Loganaden Velvindron <logan@elandsys.com>
---
Documentation/networking/ip-sysctl.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 0307e28..a476b08 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -56,6 +56,13 @@ ip_forward_use_pmtu - BOOLEAN
0 - disabled
1 - enabled
+fwmark_reflect - BOOLEAN
+ Controls the fwmark of kernel-generated IPv4 reply packets that are not
+ associated with a socket for example, TCP RSTs or ICMP echo replies).
+ If unset, these packets have a fwmark of zero. If set, they have the
+ fwmark of the packet they are replying to.
+ Default: 0
+
route/max_size - INTEGER
Maximum number of routes allowed in the kernel. Increase
this when using large numbers of interfaces and/or routes.
@@ -1201,6 +1208,13 @@ conf/all/forwarding - BOOLEAN
proxy_ndp - BOOLEAN
Do proxy ndp.
+fwmark_reflect - BOOLEAN
+ Controls the fwmark of kernel-generated IPv6 reply packets that are not
+ associated with a socket for example, TCP RSTs or ICMPv6 echo replies).
+ If unset, these packets have a fwmark of zero. If set, they have the
+ fwmark of the packet they are replying to.
+ Default: 0
+
conf/interface/*:
Change special settings per interface.
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] Add missing descriptions for fwmark_reflect for ipv4 and ipv6.
From: Loganaden Velvindron @ 2014-11-04 11:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20141104105650.GA5233@mx.elandsys.com>
It was initially sent by Lorenzo Colitti, but was subsequently
lost in the final diff he submitted.
Signed-off-by: Loganaden Velvindron <logan@elandsys.com>
---
Documentation/networking/ip-sysctl.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 0307e28..a476b08 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -56,6 +56,13 @@ ip_forward_use_pmtu - BOOLEAN
0 - disabled
1 - enabled
+fwmark_reflect - BOOLEAN
+ Controls the fwmark of kernel-generated IPv4 reply packets that are not
+ associated with a socket for example, TCP RSTs or ICMP echo replies).
+ If unset, these packets have a fwmark of zero. If set, they have the
+ fwmark of the packet they are replying to.
+ Default: 0
+
route/max_size - INTEGER
Maximum number of routes allowed in the kernel. Increase
this when using large numbers of interfaces and/or routes.
@@ -1201,6 +1208,13 @@ conf/all/forwarding - BOOLEAN
proxy_ndp - BOOLEAN
Do proxy ndp.
+fwmark_reflect - BOOLEAN
+ Controls the fwmark of kernel-generated IPv6 reply packets that are not
+ associated with a socket for example, TCP RSTs or ICMPv6 echo replies).
+ If unset, these packets have a fwmark of zero. If set, they have the
+ fwmark of the packet they are replying to.
+ Default: 0
+
conf/interface/*:
Change special settings per interface.
--
1.9.1
^ permalink raw reply related
* RE: [PATCH v2 1/1] ip-link: in human readable output use dynamic precision length
From: David Laight @ 2014-11-04 11:06 UTC (permalink / raw)
To: 'Christian Hesse', Stephen Hemminger; +Cc: netdev@vger.kernel.org
In-Reply-To: <1415098208-17942-1-git-send-email-mail@eworm.de>
From: Christian Hesse
...
> diff --git a/ip/ipaddress.c b/ip/ipaddress.c
> index e240bb5..55cbc77 100644
> --- a/ip/ipaddress.c
> +++ b/ip/ipaddress.c
> @@ -324,6 +324,7 @@ static void print_num(FILE *fp, unsigned width, uint64_t count)
> const char *prefix = "kMGTPE";
> const unsigned int base = use_iec ? 1024 : 1000;
> uint64_t powi = 1;
> + int precision;
> char buf[64];
>
> if (!human_readable || count < base) {
> @@ -343,8 +344,11 @@ static void print_num(FILE *fp, unsigned width, uint64_t count)
> ++prefix;
> }
>
> - snprintf(buf, sizeof(buf), "%.1f%c%s", (double) count / powi,
> - *prefix, use_iec ? "i" : "");
> + if ((precision = 3 - snprintf(NULL, 0, "%"PRIu64, count / powi)) < 0)
Don't put assignments in conditionals.
> + precision = 0;
> +
> + snprintf(buf, sizeof(buf), "%.*f%c%s", precision,
> + (double) count / powi, *prefix, use_iec ? "i" : "");
>
> fprintf(fp, "%-*s ", width, buf);
> }
> --
> 2.1.3
The above will go wrong in all sorts of horrid ways....
For instance you are doing a truncating integer divide, but the FP
value will get rounded for display.
It would be safer to use integers throughout.
Oh, and a 2Mbit E1 link is actually 2048000 :-)
David
^ permalink raw reply
* Re: [PATCH ipsec-next] xfrm: add XFRMA_REPLAY_VAL attribute to SA messages
From: Steffen Klassert @ 2014-11-04 11:33 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: davem, netdev, dingzhi, Adrien Mazarguil
In-Reply-To: <1414658376-4207-1-git-send-email-nicolas.dichtel@6wind.com>
On Thu, Oct 30, 2014 at 09:39:36AM +0100, Nicolas Dichtel wrote:
> From: dingzhi <zhi.ding@6wind.com>
>
> After this commit, the attribute XFRMA_REPLAY_VAL is added when no ESN replay
> value is defined. Thus sequence number values are always notified to userspace.
>
> Signed-off-by: dingzhi <zhi.ding@6wind.com>
> Signed-off-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied to ipsec-next, thanks!
^ permalink raw reply
* Re: TCP NewReno and single retransmit
From: Marcelo Ricardo Leitner @ 2014-11-04 13:12 UTC (permalink / raw)
To: Yuchung Cheng, Neal Cardwell; +Cc: netdev, Eric Dumazet
In-Reply-To: <CAK6E8=cgkznkAWTps7aA+txuETpZ2RNiU3rbQf9WxLjawhgNog@mail.gmail.com>
On 04-11-2014 05:59, Yuchung Cheng wrote:
> On Tue, Nov 4, 2014 at 7:17 AM, Neal Cardwell <ncardwell@google.com> wrote:
>> On Mon, Nov 3, 2014 at 4:35 PM, Marcelo Ricardo Leitner
>> <mleitner@redhat.com> wrote:
>>> So by sticking with the recovery for a bit longer will help disambiguate the
>>> 3 dupacks on high_seq, if they ever happen, and with that avoid re-entering
>>> Fast Retransmit if initial (2) happen. It's at the cost of leaving the fast
>>> retransmit an ack later but if (2) happens the impact would be much worse,
>>> AFAICS.
>>
>> Yes, that's my sense.
>>
>>> Cool, thanks Neal. If Yuchung is okay with it, I'll proceed with just
>>> zeroing that tstamp as initially proposed.
>>
>> Yes, that sounds good to me for a short-term fix for the "net" branch,
>> as long as it's:
>>
>> + if (!tcp_any_retrans_done(sk))
>> + tp->retrans_stamp = 0;
>>
>> Longer-term ("net-next"?) perhaps it makes sense to remove the hold
>> state and protect against this spurious FR situation at the time we
>> decide to enter Fast Recovery, which seems to be the model the RFC is
>> suggesting.
> Thanks for checking. So my suggested fix of removing the hold state is
> the "less careful variant" that RFC does not recommend. I would rather
> have the proposed 2-liner fix than implementing the section 6
> heuristics to detect spurious retransmit. It's not worth the effort.
> Everyone should use SACK.
Yup, agreed.
Thanks,
Marcelo
^ permalink raw reply
* Re: [PATCH 7/7] can: m_can: workaround for transmit data less than 4 bytes
From: Oliver Hartkopp @ 2014-11-04 13:13 UTC (permalink / raw)
To: Marc Kleine-Budde, Dong Aisheng
Cc: linux-can, wg, varkabhadram, netdev, linux-arm-kernel
In-Reply-To: <5458AB65.7000500@pengutronix.de>
On 04.11.2014 11:33, Marc Kleine-Budde wrote:
> On 11/04/2014 10:27 AM, Dong Aisheng wrote:
>> + /* We meet an IC issue that we have to write the full 8
>
> At least on the *insert SoC name here*, an issue with the Message RAM
> was discovered. Sending CAN frames with dlc less than 4 bytes will lead
> to bit errors, when the first 8 bytes of the Message RAM have not been
> initialized (i.e. written to). To work around this issue, the first 8
> bytes are initialized here.
Yes. Also put the current IP revision (3.0.x) into the comment.
Did inform the Bosch guys from this issue - or is it already in some errata sheet?
>
>> + * bytes (whatever value for the second word) in Message RAM to
>> + * avoid bit error for transmit data less than 4 bytes at the first
>> + * time. By initializing the first 8 bytes of tx buffer before using
>> + * it can avoid such issue.
>> + */
>> + m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), 0x0);
>> + m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), 0x0);
>> +
>> m_can_config_endisable(priv, false);
>> }
>
> Can you trigger the issue when sending CAN-FD frames with dlc > 8 && dlc
> < 64?
Just a nitpick:
DLC can just be 0 .. 15
and the length (struct canfd_frame.len) can be from 0 .. 64
See:
http://lxr.free-electrons.com/source/include/uapi/linux/can.h#L83
That's the reason for all these helpers
http://lxr.free-electrons.com/source/drivers/net/can/dev.c#L36
that hide the evil "DLC" from userspace now and make 'len' a usable loop
variable as we were able to use the former dlc for classic CAN :-)
Regards,
Oliver
^ permalink raw reply
* Re: [PATCH 7/7] can: m_can: workaround for transmit data less than 4 bytes
From: Marc Kleine-Budde @ 2014-11-04 13:28 UTC (permalink / raw)
To: Oliver Hartkopp, Dong Aisheng
Cc: linux-can, wg, varkabhadram, netdev, linux-arm-kernel
In-Reply-To: <5458D0FA.1040504@hartkopp.net>
[-- Attachment #1: Type: text/plain, Size: 2179 bytes --]
On 11/04/2014 02:13 PM, Oliver Hartkopp wrote:
>
>
> On 04.11.2014 11:33, Marc Kleine-Budde wrote:
>> On 11/04/2014 10:27 AM, Dong Aisheng wrote:
>
>
>>> + /* We meet an IC issue that we have to write the full 8
>>
>> At least on the *insert SoC name here*, an issue with the Message RAM
>> was discovered. Sending CAN frames with dlc less than 4 bytes will lead
>> to bit errors, when the first 8 bytes of the Message RAM have not been
>> initialized (i.e. written to). To work around this issue, the first 8
>> bytes are initialized here.
>
> Yes. Also put the current IP revision (3.0.x) into the comment.
Good idea - also add the SoC's mask revision.
> Did inform the Bosch guys from this issue - or is it already in some
> errata sheet?
>
>>
>>> + * bytes (whatever value for the second word) in Message RAM to
>>> + * avoid bit error for transmit data less than 4 bytes at the
>>> first
>>> + * time. By initializing the first 8 bytes of tx buffer
>>> before using
>>> + * it can avoid such issue.
>>> + */
>>> + m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(0), 0x0);
>>> + m_can_fifo_write(priv, 0, M_CAN_FIFO_DATA(1), 0x0);
>>> +
>>> m_can_config_endisable(priv, false);
>>> }
>>
>> Can you trigger the issue when sending CAN-FD frames with dlc > 8 && dlc
>> < 64?
>
> Just a nitpick:
>
> DLC can just be 0 .. 15
Correct, I was talking about the length
> and the length (struct canfd_frame.len) can be from 0 .. 64
>
> See:
>
> http://lxr.free-electrons.com/source/include/uapi/linux/can.h#L83
>
> That's the reason for all these helpers
>
> http://lxr.free-electrons.com/source/drivers/net/can/dev.c#L36
>
> that hide the evil "DLC" from userspace now and make 'len' a usable loop
> variable as we were able to use the former dlc for classic CAN :-)
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH net] vxlan: Do not reuse sockets for a different address family
From: Marcelo Ricardo Leitner @ 2014-11-04 13:46 UTC (permalink / raw)
To: netdev; +Cc: stephen
Currently, we only match against local port number in order to reuse
socket. But if this new vxlan wants an IPv6 socket and a IPv4 one bound
to that port, vxlan will reuse an IPv4 socket as IPv6 and a panic will
follow. The following steps reproduce it:
# ip link add vxlan6 type vxlan id 42 group 229.10.10.10 \
srcport 5000 6000 dev eth0
# ip link add vxlan7 type vxlan id 43 group ff0e::110 \
srcport 5000 6000 dev eth0
# ip link set vxlan6 up
# ip link set vxlan7 up
<panic>
[ 4.187481] BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
[ 4.187509] IP: [<ffffffff81667c98>] ipv6_sock_mc_join+0x88/0x630
...
[ 4.188076] Call Trace:
[ 4.188085] [<ffffffff81667c4a>] ? ipv6_sock_mc_join+0x3a/0x630
[ 4.188098] [<ffffffffa05a6ad6>] vxlan_igmp_join+0x66/0xd0 [vxlan]
[ 4.188113] [<ffffffff810a3430>] process_one_work+0x220/0x710
[ 4.188125] [<ffffffff810a33c4>] ? process_one_work+0x1b4/0x710
[ 4.188138] [<ffffffff810a3a3b>] worker_thread+0x11b/0x3a0
[ 4.188149] [<ffffffff810a3920>] ? process_one_work+0x710/0x710
So address family must also match in order to reuse a socket.
Reported-by: Jean-Tsung Hsiao <jhsiao@redhat.com>
Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
---
drivers/net/vxlan.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index ca309820d39e1ba7995f38d3a2f9bacbd1c1f857..c0fa76d55ae3cc07fb14b70656d6b13b5bab091c 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -281,7 +281,8 @@ static struct vxlan_sock *vxlan_find_sock(struct net *net, __be16 port)
struct vxlan_sock *vs;
hlist_for_each_entry_rcu(vs, vs_head(net, port), hlist) {
- if (inet_sk(vs->sock->sk)->inet_sport == port)
+ if ((inet_sk(vs->sock->sk)->inet_sport == port) &&
+ (inet_sk(vs->sock->sk)->sk.sk_family == family))
return vs;
}
return NULL;
--
1.9.3
^ permalink raw reply related
* [PATCH net] tcp: zero retrans_stamp if all retrans were acked
From: Marcelo Ricardo Leitner @ 2014-11-04 14:18 UTC (permalink / raw)
To: netdev; +Cc: ncardwell, ycheng, edumazet
Ueki Kohei reported that when we are using NewReno with connections that
have a very low traffic, we may timeout the connection too early if a
second loss occurs after the first one was successfully acked but no
data was transfered later. Below is his description of it:
When SACK is disabled, and a socket suffers multiple separate TCP
retransmissions, that socket's ETIMEDOUT value is calculated from the
time of the *first* retransmission instead of the *latest*
retransmission.
This happens because the tcp_sock's retrans_stamp is set once then never
cleared.
Take the following connection:
Linux remote-machine
| |
send#1---->(*1)|--------> data#1 --------->|
| | |
RTO : :
| | |
---(*2)|----> data#1(retrans) ---->|
| (*3)|<---------- ACK <----------|
| | |
| : :
| : :
| : :
16 minutes (or more) :
| : :
| : :
| : :
| | |
send#2---->(*4)|--------> data#2 --------->|
| | |
RTO : :
| | |
---(*5)|----> data#2(retrans) ---->|
| | |
| | |
RTO*2 : :
| | |
| | |
ETIMEDOUT<----(*6)| |
(*1) One data packet sent.
(*2) Because no ACK packet is received, the packet is retransmitted.
(*3) The ACK packet is received. The transmitted packet is acknowledged.
At this point the first "retransmission event" has passed and been
recovered from. Any future retransmission is a completely new "event".
(*4) After 16 minutes (to correspond with retries2=15), a new data
packet is sent. Note: No data is transmitted between (*3) and (*4).
The socket's timeout SHOULD be calculated from this point in time, but
instead it's calculated from the prior "event" 16 minutes ago.
(*5) Because no ACK packet is received, the packet is retransmitted.
(*6) At the time of the 2nd retransmission, the socket returns
ETIMEDOUT.
Therefore, now we clear retrans_stamp as soon as all data during the
loss window is fully acked.
Reported-by: Ueki Kohei
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
---
net/ipv4/tcp_input.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index a12b455928e52211efdc6b471ef54de6218f5df0..65686efeaaf3c36706390d3bfd260fd1fb942b7f 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2410,6 +2410,8 @@ static bool tcp_try_undo_recovery(struct sock *sk)
* is ACKed. For Reno it is MUST to prevent false
* fast retransmits (RFC2582). SACK TCP is safe. */
tcp_moderate_cwnd(tp);
+ if (!tcp_any_retrans_done(sk))
+ tp->retrans_stamp = 0;
return true;
}
tcp_set_ca_state(sk, TCP_CA_Open);
--
1.9.3
^ permalink raw reply related
* Re: [PATCH 0/1] mv643xx_eth: Disable TSO by default
From: Karl Beldan @ 2014-11-04 14:20 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: netdev, David Miller, Thomas Petazzoni, Gregory Clement,
Tawfik Bayouk, Lior Amsalem, Nadav Haklai
In-Reply-To: <1414855820-15094-1-git-send-email-ezequiel.garcia@free-electrons.com>
On Sat, Nov 01, 2014 at 12:30:19PM -0300, Ezequiel Garcia wrote:
> Several users ([1], [2]) have been reporting data corruption with TSO on
> Kirkwood platforms (i.e. using the mv643xx_eth driver).
>
> Until we manage to find what's causing this, this simple patch will make
> the TSO path disabled by default. This patch should be queued for stable,
> fixing the TSO feature introduced in v3.16.
>
> The corruption itself is very easy to reproduce: checking md5sum on a mounted
> NFS directory gives a different result each time. Same tests using the mvneta
> driver (Armada 370/38x/XP SoC) pass with no issues.
>
> Frankly, I'm a bit puzzled about this, and so any ideas or debugging hints
> are well received.
>
Hi,
Can you try this :
@@ -1067,7 +1082,8 @@ static int txq_reclaim(struct tx_queue *txq, int budget, int force)
txq->tx_desc_count--;
skb = NULL;
- if (cmd_sts & TX_LAST_DESC)
+ if ((cmd_sts & (TX_LAST_DESC | TX_ENABLE_INTERRUPT)) ==
+ (TX_LAST_DESC | TX_ENABLE_INTERRUPT))
skb = __skb_dequeue(&txq->tx_skb);
if (cmd_sts & ERROR_SUMMARY) {
--
Karl
^ permalink raw reply
* Re: [PATCH 1/4] inet: Add skb_copy_datagram_iter
From: Al Viro @ 2014-11-04 14:32 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, netdev, Linux Kernel Mailing List,
Benjamin LaHaise
In-Reply-To: <E1XlZWY-0003HZ-Ef@gondolin.me.apana.org.au>
On Tue, Nov 04, 2014 at 04:31:34PM +0800, Herbert Xu wrote:
> This patch adds skb_copy_datagram_iter, which is identical to
> skb_copy_datagram_iovec except that it operates on iov_iter
> instead of iovec.
>
> Eventually all users of skb_copy_datagram_iovec should switch
> over to iov_iter and then we can remove skb_copy_datagram_iovec.
Too noisy, IMO. How about skb_copy_datagram_msg() first? The fewer
places have to even think of iovec or iov_iter, the better...
^ permalink raw reply
* Re: [PATCH 1/4] inet: Add skb_copy_datagram_iter
From: Al Viro @ 2014-11-04 14:35 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, netdev, Linux Kernel Mailing List,
Benjamin LaHaise
In-Reply-To: <20141104143200.GC7996@ZenIV.linux.org.uk>
On Tue, Nov 04, 2014 at 02:32:00PM +0000, Al Viro wrote:
> On Tue, Nov 04, 2014 at 04:31:34PM +0800, Herbert Xu wrote:
> > This patch adds skb_copy_datagram_iter, which is identical to
> > skb_copy_datagram_iovec except that it operates on iov_iter
> > instead of iovec.
> >
> > Eventually all users of skb_copy_datagram_iovec should switch
> > over to iov_iter and then we can remove skb_copy_datagram_iovec.
>
> Too noisy, IMO. How about skb_copy_datagram_msg() first? The fewer
> places have to even think of iovec or iov_iter, the better...
PS: "too noisy" is about turning every callsite of skb_copy_datagram_iovec
into that of skb_copy_datagram_iter; the helper itself is just fine.
^ permalink raw reply
* Re: TCP NewReno and single retransmit
From: Neal Cardwell @ 2014-11-04 14:38 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: Marcelo Ricardo Leitner, netdev, Eric Dumazet
In-Reply-To: <CAK6E8=cgkznkAWTps7aA+txuETpZ2RNiU3rbQf9WxLjawhgNog@mail.gmail.com>
On Tue, Nov 4, 2014 at 2:59 AM, Yuchung Cheng <ycheng@google.com> wrote:
> Thanks for checking. So my suggested fix of removing the hold state is
> the "less careful variant" that RFC does not recommend. I would rather
> have the proposed 2-liner fix than implementing the section 6
> heuristics to detect spurious retransmit. It's not worth the effort.
> Everyone should use SACK.
Agreed. The simple 2-liner seems like the simplest and lowest-risk
fix. And given that >95% of public Internet flows and an even higher
proportion of datacenter flows use SACK, it's not worth spending time
optimizing NewReno.
neal
^ permalink raw reply
* Re: [PATCH 1/4] inet: Add skb_copy_datagram_iter
From: Herbert Xu @ 2014-11-04 14:42 UTC (permalink / raw)
To: Al Viro
Cc: David S. Miller, netdev, Linux Kernel Mailing List,
Benjamin LaHaise
In-Reply-To: <20141104143200.GC7996@ZenIV.linux.org.uk>
On Tue, Nov 04, 2014 at 02:32:00PM +0000, Al Viro wrote:
>
> Too noisy, IMO. How about skb_copy_datagram_msg() first? The fewer
> places have to even think of iovec or iov_iter, the better...
We have places like tcp ucopy and tun that do not have msghdr.
So doing skb_copy_datagram_msg means that we'd have to create
a fake msghdr wrapper around them. The point is not everything
comes in via sendmsg/recvmsg.
What is your motivation for hiding iov/iov_iter? Do you plan to
change their API at some future point?
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] drivers: net: ethernet: xilinx: xilinx_emaclite: revert the original commit "1db3ddff1602edf2390b7667dcbaa0f71512e3ea"
From: Chen Gang @ 2014-11-04 14:43 UTC (permalink / raw)
To: michal.simek, soren.brinkmann, davem, sthokal, manuel.schoelling,
f.fainelli, paul.gortmaker, ebiederm
Cc: netdev, linux-kernel@vger.kernel.org
Microblaze is a fpga soft core, it can be customized easily, which may
cause many various hardware version strings.
So the original fix patch based on hard-coded compatible version strings
is not a good idea (although it is correct for current issue). For it,
there will be a new solving way soon (which based on the device tree).
The original issue is related with qemu, so can only change the hardware
version string in qemu for it, then keep the original driver no touch (
qemu is for virtualization which has much easier life than real world).
Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
---
drivers/net/ethernet/xilinx/xilinx_emaclite.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
index 298fad3..28dbbdc 100644
--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
@@ -1236,7 +1236,6 @@ static struct of_device_id xemaclite_of_match[] = {
{ .compatible = "xlnx,opb-ethernetlite-1.01.b", },
{ .compatible = "xlnx,xps-ethernetlite-1.00.a", },
{ .compatible = "xlnx,xps-ethernetlite-2.00.a", },
- { .compatible = "xlnx,xps-ethernetlite-2.00.b", },
{ .compatible = "xlnx,xps-ethernetlite-2.01.a", },
{ .compatible = "xlnx,xps-ethernetlite-3.00.a", },
{ /* end of list */ },
-- davem@davemloft.net
1.9.3
^ permalink raw reply related
* Re: [PATCH 1/4] inet: Add skb_copy_datagram_iter
From: Herbert Xu @ 2014-11-04 14:44 UTC (permalink / raw)
To: Al Viro
Cc: David S. Miller, netdev, Linux Kernel Mailing List,
Benjamin LaHaise
In-Reply-To: <20141104143536.GD7996@ZenIV.linux.org.uk>
On Tue, Nov 04, 2014 at 02:35:36PM +0000, Al Viro wrote:
> On Tue, Nov 04, 2014 at 02:32:00PM +0000, Al Viro wrote:
>
> > Too noisy, IMO. How about skb_copy_datagram_msg() first? The fewer
> > places have to even think of iovec or iov_iter, the better...
>
> PS: "too noisy" is about turning every callsite of skb_copy_datagram_iovec
> into that of skb_copy_datagram_iter; the helper itself is just fine.
Hmm if that is your concern then I don't see how skb_copy_datagram_msg
changes things as you'd still have to convert every existing caller
of skb_copy_datagram_iovec. Colour me confused.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 1/4] inet: Add skb_copy_datagram_iter
From: Al Viro @ 2014-11-04 14:52 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, netdev, Linux Kernel Mailing List,
Benjamin LaHaise
In-Reply-To: <20141104144416.GB14743@gondor.apana.org.au>
On Tue, Nov 04, 2014 at 10:44:16PM +0800, Herbert Xu wrote:
> On Tue, Nov 04, 2014 at 02:35:36PM +0000, Al Viro wrote:
> > On Tue, Nov 04, 2014 at 02:32:00PM +0000, Al Viro wrote:
> >
> > > Too noisy, IMO. How about skb_copy_datagram_msg() first? The fewer
> > > places have to even think of iovec or iov_iter, the better...
> >
> > PS: "too noisy" is about turning every callsite of skb_copy_datagram_iovec
> > into that of skb_copy_datagram_iter; the helper itself is just fine.
>
> Hmm if that is your concern then I don't see how skb_copy_datagram_msg
> changes things as you'd still have to convert every existing caller
> of skb_copy_datagram_iovec. Colour me confused.
Fewer places having to even think of iovec/iov_iter...
^ permalink raw reply
* Re: [PATCH 1/4] inet: Add skb_copy_datagram_iter
From: Herbert Xu @ 2014-11-04 14:55 UTC (permalink / raw)
To: Al Viro
Cc: David S. Miller, netdev, Linux Kernel Mailing List,
Benjamin LaHaise
In-Reply-To: <20141104145222.GF7996@ZenIV.linux.org.uk>
On Tue, Nov 04, 2014 at 02:52:22PM +0000, Al Viro wrote:
>
> > Hmm if that is your concern then I don't see how skb_copy_datagram_msg
> > changes things as you'd still have to convert every existing caller
> > of skb_copy_datagram_iovec. Colour me confused.
>
> Fewer places having to even think of iovec/iov_iter...
Well it's the difference between
skb_copy_datagram_iter(..., &kmsghdr->iov_iter, ...)
and
skb_copy_datagram_msg(..., kmsghdr, ...)
Heck we could even make skb_copy_datagram_msg an inline wrapper
around skb_copy_datagram_iter if you like.
Anyway, the point is that not everything comes with a kmsghdr.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [net-next.git 3/3 (V2)] stmmac: remove BUS_MODE_DA
From: Giuseppe Cavallaro @ 2014-11-04 14:49 UTC (permalink / raw)
To: netdev; +Cc: Giuseppe Cavallaro
In-Reply-To: <1415112574-21321-1-git-send-email-peppe.cavallaro@st.com>
This is a very old and often unused option to configure
a bit in a register inside the DMA. This support should
not stay under Koption and should be extended for new chips too.
This will be do later maybe via device-tree parameters.
Also no performance impact when remove this setting on STi platforms.
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
V2: re-based on top of the latest updates for net-next
drivers/net/ethernet/stmicro/stmmac/Kconfig | 10 ----------
.../net/ethernet/stmicro/stmmac/dwmac1000_dma.c | 4 ----
2 files changed, 0 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index af5228a..33b85ba 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -37,14 +37,4 @@ config STMMAC_PCI
D1215994A VIRTEX FPGA board.
If unsure, say N.
-
-config STMMAC_DA
- bool "STMMAC DMA arbitration scheme"
- default n
- ---help---
- Selecting this option, rx has priority over Tx (only for Giga
- Ethernet device).
- By default, the DMA arbitration scheme is based on Round-robin
- (rx:tx priority is 1:1).
-
endif
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
index 0c2058a..59d92e8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
@@ -70,10 +70,6 @@ static int dwmac1000_dma_init(void __iomem *ioaddr, int pbl, int fb, int mb,
if (mb)
value |= DMA_BUS_MODE_MB;
-#ifdef CONFIG_STMMAC_DA
- value |= DMA_BUS_MODE_DA; /* Rx has priority over tx */
-#endif
-
if (atds)
value |= DMA_BUS_MODE_ATDS;
--
1.7.4.4
^ permalink raw reply related
* [net-next.git 2/3 (V2)] stmmac: remove STMMAC_DEBUG_FS
From: Giuseppe Cavallaro @ 2014-11-04 14:49 UTC (permalink / raw)
To: netdev; +Cc: Giuseppe Cavallaro
In-Reply-To: <1415112574-21321-1-git-send-email-peppe.cavallaro@st.com>
the STMMAC_DEBUG_FS Koption is now removed from the
driver configuration and this support will be built
by default when DEBUG_FS is present. This can also be
useful on building driver verification.
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
V2: re-based on top of the latest updates for net-next
drivers/net/ethernet/stmicro/stmmac/Kconfig | 8 --------
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 14 +++++++-------
2 files changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 40f356d..af5228a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -38,14 +38,6 @@ config STMMAC_PCI
If unsure, say N.
-config STMMAC_DEBUG_FS
- bool "Enable monitoring via sysFS "
- default n
- depends on STMMAC_ETH && DEBUG_FS
- ---help---
- The stmmac entry in /sys reports DMA TX/RX rings
- or (if supported) the HW cap register.
-
config STMMAC_DA
bool "STMMAC DMA arbitration scheme"
default n
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 6f77a46..a34754b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -44,10 +44,10 @@
#include <linux/slab.h>
#include <linux/prefetch.h>
#include <linux/pinctrl/consumer.h>
-#ifdef CONFIG_STMMAC_DEBUG_FS
+#ifdef CONFIG_DEBUG_FS
#include <linux/debugfs.h>
#include <linux/seq_file.h>
-#endif /* CONFIG_STMMAC_DEBUG_FS */
+#endif /* CONFIG_DEBUG_FS */
#include <linux/net_tstamp.h>
#include "stmmac_ptp.h"
#include "stmmac.h"
@@ -116,7 +116,7 @@ MODULE_PARM_DESC(chain_mode, "To use chain instead of ring mode");
static irqreturn_t stmmac_interrupt(int irq, void *dev_id);
-#ifdef CONFIG_STMMAC_DEBUG_FS
+#ifdef CONFIG_DEBUG_FS
static int stmmac_init_fs(struct net_device *dev);
static void stmmac_exit_fs(void);
#endif
@@ -1688,7 +1688,7 @@ static int stmmac_hw_setup(struct net_device *dev)
if (ret && ret != -EOPNOTSUPP)
pr_warn("%s: failed PTP initialisation\n", __func__);
-#ifdef CONFIG_STMMAC_DEBUG_FS
+#ifdef CONFIG_DEBUG_FS
ret = stmmac_init_fs(dev);
if (ret < 0)
pr_warn("%s: failed debugFS registration\n", __func__);
@@ -1866,7 +1866,7 @@ static int stmmac_release(struct net_device *dev)
netif_carrier_off(dev);
-#ifdef CONFIG_STMMAC_DEBUG_FS
+#ifdef CONFIG_DEBUG_FS
stmmac_exit_fs();
#endif
@@ -2453,7 +2453,7 @@ static int stmmac_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
return ret;
}
-#ifdef CONFIG_STMMAC_DEBUG_FS
+#ifdef CONFIG_DEBUG_FS
static struct dentry *stmmac_fs_dir;
static struct dentry *stmmac_rings_status;
static struct dentry *stmmac_dma_cap;
@@ -2638,7 +2638,7 @@ static void stmmac_exit_fs(void)
debugfs_remove(stmmac_dma_cap);
debugfs_remove(stmmac_fs_dir);
}
-#endif /* CONFIG_STMMAC_DEBUG_FS */
+#endif /* CONFIG_DEBUG_FS */
static const struct net_device_ops stmmac_netdev_ops = {
.ndo_open = stmmac_open,
--
1.7.4.4
^ permalink raw reply related
* [net-next.git 0/3 (v2)] stmmac: review driver Koptions
From: Giuseppe Cavallaro @ 2014-11-04 14:49 UTC (permalink / raw)
To: netdev; +Cc: Giuseppe Cavallaro
Recently many Koption options have been added to have new glue logic on several
platforms.
The main goal behind this work is to guarantee that the driver built
fine on all the branches where it is present independently of which
glue logic is selected.
IMHO, it is better to remove all the not necessary Koption(s) that can hide
build problems when something changes in the driver and especially when
the DT compatibility allows us to manage all the platform data.
I compiled the driver w/o any issue on net-next Git for:
x86, arm and sh4.
In case of there are build problems on some repos now it will be
easy to catch them and cherry-pick patches from mainstream.
For sure, do not hesitate to contact me in case of issue.
Also this set removes STMMAC_DEBUG_FS and BUS_MODE_DA. The latter is useless
and the former can be replaced by DEBUG_FS (always to make safe the build).
V2: patch-set re-based on top of the latest updates for net-next
Giuseppe Cavallaro (3):
stmmac: remove specific SoC Koption from platform.
stmmac: remove STMMAC_DEBUG_FS
stmmac: remove BUS_MODE_DA
drivers/net/ethernet/stmicro/stmmac/Kconfig | 68 +------------------
drivers/net/ethernet/stmicro/stmmac/Makefile | 8 +--
.../net/ethernet/stmicro/stmmac/dwmac1000_dma.c | 4 -
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 9 +--
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 14 ++--
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 10 +---
6 files changed, 16 insertions(+), 97 deletions(-)
--
1.7.4.4
^ permalink raw reply
* [net-next.git 1/3 (V2)] stmmac: remove specific SoC Koption from platform.
From: Giuseppe Cavallaro @ 2014-11-04 14:49 UTC (permalink / raw)
To: netdev; +Cc: Giuseppe Cavallaro
In-Reply-To: <1415112574-21321-1-git-send-email-peppe.cavallaro@st.com>
This patch removes all the Koptions added to build the glue-logic files
for all different architectures: DWMAC_MESON, DWMAC_SUNXI, DWMAC_STI ...
Nowadays the stmmac needs to be compiled on several platforms; in some
case it very convenient to guarantee that its build is always completed
with success on all the branches where the driver is present.
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
V2: re-based on top of the latest updates for net-next
drivers/net/ethernet/stmicro/stmmac/Kconfig | 50 ++------------------
drivers/net/ethernet/stmicro/stmmac/Makefile | 8 +--
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 9 +---
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 10 +----
4 files changed, 9 insertions(+), 68 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index b02d4a3..40f356d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -18,56 +18,14 @@ config STMMAC_PLATFORM
depends on STMMAC_ETH
default y
---help---
- This selects the platform specific bus support for
- the stmmac device driver. This is the driver used
- on many embedded STM platforms based on ARM and SuperH
- processors.
+ This selects the platform specific bus support for the stmmac driver.
+ This is the driver used on several SoCs:
+ STi, Allwinner, Amlogic Meson, Altera SOCFPGA.
+
If you have a controller with this interface, say Y or M here.
If unsure, say N.
-config DWMAC_MESON
- bool "Amlogic Meson dwmac support"
- depends on STMMAC_PLATFORM && ARCH_MESON
- help
- Support for Ethernet controller on Amlogic Meson SoCs.
-
- This selects the Amlogic Meson SoC glue layer support for
- the stmmac device driver. This driver is used for Meson6 and
- Meson8 SoCs.
-
-config DWMAC_SOCFPGA
- bool "SOCFPGA dwmac support"
- depends on STMMAC_PLATFORM && MFD_SYSCON && (ARCH_SOCFPGA || COMPILE_TEST)
- help
- Support for ethernet controller on Altera SOCFPGA
-
- This selects the Altera SOCFPGA SoC glue layer support
- for the stmmac device driver. This driver is used for
- arria5 and cyclone5 FPGA SoCs.
-
-config DWMAC_SUNXI
- bool "Allwinner GMAC support"
- depends on STMMAC_PLATFORM && ARCH_SUNXI
- default y
- ---help---
- Support for Allwinner A20/A31 GMAC ethernet controllers.
-
- This selects Allwinner SoC glue layer support for the
- stmmac device driver. This driver is used for A20/A31
- GMAC ethernet controller.
-
-config DWMAC_STI
- bool "STi GMAC support"
- depends on STMMAC_PLATFORM && ARCH_STI
- default y
- ---help---
- Support for ethernet controller on STi SOCs.
-
- This selects STi SoC glue layer support for the stmmac
- device driver. This driver is used on for the STi series
- SOCs GMAC ethernet controller.
-
config STMMAC_PCI
bool "STMMAC PCI bus support"
depends on STMMAC_ETH && PCI
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 0533d0b..034da70 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -1,10 +1,8 @@
obj-$(CONFIG_STMMAC_ETH) += stmmac.o
-stmmac-$(CONFIG_STMMAC_PLATFORM) += stmmac_platform.o
stmmac-$(CONFIG_STMMAC_PCI) += stmmac_pci.o
-stmmac-$(CONFIG_DWMAC_MESON) += dwmac-meson.o
-stmmac-$(CONFIG_DWMAC_SUNXI) += dwmac-sunxi.o
-stmmac-$(CONFIG_DWMAC_STI) += dwmac-sti.o
-stmmac-$(CONFIG_DWMAC_SOCFPGA) += dwmac-socfpga.o
+stmmac-$(CONFIG_STMMAC_PLATFORM) += stmmac_platform.o dwmac-meson.o \
+ dwmac-sunxi.o dwmac-sti.o \
+ dwmac-socfpga.o
stmmac-objs:= stmmac_main.o stmmac_ethtool.o stmmac_mdio.o ring_mode.o \
chain_mode.o dwmac_lib.o dwmac1000_core.o dwmac1000_dma.o \
dwmac100_core.o dwmac100_dma.o enh_desc.o norm_desc.o \
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index c3c4065..23aad9a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -137,20 +137,13 @@ void stmmac_disable_eee_mode(struct stmmac_priv *priv);
bool stmmac_eee_init(struct stmmac_priv *priv);
#ifdef CONFIG_STMMAC_PLATFORM
-#ifdef CONFIG_DWMAC_MESON
extern const struct stmmac_of_data meson6_dwmac_data;
-#endif
-#ifdef CONFIG_DWMAC_SUNXI
extern const struct stmmac_of_data sun7i_gmac_data;
-#endif
-#ifdef CONFIG_DWMAC_STI
extern const struct stmmac_of_data stih4xx_dwmac_data;
extern const struct stmmac_of_data stid127_dwmac_data;
-#endif
-#ifdef CONFIG_DWMAC_SOCFPGA
extern const struct stmmac_of_data socfpga_gmac_data;
-#endif
extern struct platform_driver stmmac_pltfr_driver;
+
static inline int stmmac_register_platform(void)
{
int err;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index db56fa7..f4fe854 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -30,22 +30,14 @@
#include "stmmac.h"
static const struct of_device_id stmmac_dt_ids[] = {
-#ifdef CONFIG_DWMAC_MESON
+ /* SoC specific glue layers should come before generic bindings */
{ .compatible = "amlogic,meson6-dwmac", .data = &meson6_dwmac_data},
-#endif
-#ifdef CONFIG_DWMAC_SUNXI
{ .compatible = "allwinner,sun7i-a20-gmac", .data = &sun7i_gmac_data},
-#endif
-#ifdef CONFIG_DWMAC_STI
{ .compatible = "st,stih415-dwmac", .data = &stih4xx_dwmac_data},
{ .compatible = "st,stih416-dwmac", .data = &stih4xx_dwmac_data},
{ .compatible = "st,stid127-dwmac", .data = &stid127_dwmac_data},
{ .compatible = "st,stih407-dwmac", .data = &stih4xx_dwmac_data},
-#endif
-#ifdef CONFIG_DWMAC_SOCFPGA
{ .compatible = "altr,socfpga-stmmac", .data = &socfpga_gmac_data },
-#endif
- /* SoC specific glue layers should come before generic bindings */
{ .compatible = "st,spear600-gmac"},
{ .compatible = "snps,dwmac-3.610"},
{ .compatible = "snps,dwmac-3.70a"},
--
1.7.4.4
^ permalink raw reply related
* Understanding what's going on when using a Huawei E173 USB 3G web-stick (UMTS/HSPA)
From: Sedat Dilek @ 2014-11-04 15:11 UTC (permalink / raw)
To: Greg KH, David S. Miller; +Cc: netdev@vger.kernel.org, linux-usb
Hi,
I wanted to understand what is going on the kernel-side when
connecting to the Internet via a Huawei E173 USB web-stick (3rd
Generation: UMTS / HSPA).
Especially the correlation between the diverse USB/NET kernel-drivers
and how the networking is setup.
I have tested a Ubuntu trusty kernel on my Ubuntu/precise system and
compared the configs to get the stuff run on 3.18-rc2+.
Beyond the "option" driver, I required usb_serial / usb_wwan to be
activated and some more ("cde-ether" or sth. sound similiar...).
( Currently, I am not sitting (it's a Windows machine) in front of my
machine, so I cannot send you my latest kernel-config. )
As usually I looked into Documentation directory.
So, my 1st question where do I get some informations in general on
this topic - usb [1] or net subdirectory (seen from kernel-side)?
I found a usb-serial kernel-doc [1].
( I have no Linux Git source so I cannot grep for patterns. )
The next mystery is what is network-manager doing in the background?
I have seen that modem-manager is invoked, but as said I would like to
understand the "internas" (means check the logs, turn on some
debugging kernel-space/user-space, etc.).
I am not sure but syncing with 3G network seems to take a while since
I really can connect to the Internet.
I am happy about some fruitful informations or web-links...
Thanks in advance.
Regards,
- Sedat -
[1] https://www.kernel.org/doc/Documentation/usb/usb-serial.txt
^ 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