* [PATCH 10/20 v2] uli526x: fix misspelling of current function in string
From: Julia Lawall @ 2014-12-07 20:59 UTC (permalink / raw)
To: Grant Grundler
Cc: Grant Grundler, kernel-janitors, Rasmus Villemoes, joe,
open list:TULIP NETWORK DRI..., open list
In-Reply-To: <CAP6odjh4Gnc0uAcPTsUMFPTRj7=NYZvMgmL=Rre_kCNah+YcNg@mail.gmail.com>
The function is named uli526x_cleanup_module, rather than uli526x_clean_module.
This was done using Coccinelle, including the use of Levenshtein distance,
as proposed by Rasmus Villemoes.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: Grant Grundler <grantgrundler@gmail.com>
---
v2: fixed commit message
The semantic patch is difficult to summarize, but is available in the cover
letter of this patch series.
drivers/net/ethernet/dec/tulip/uli526x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/dec/tulip/uli526x.c b/drivers/net/ethernet/dec/tulip/uli526x.c
index 4061f9b..1c5916b 100644
--- a/drivers/net/ethernet/dec/tulip/uli526x.c
+++ b/drivers/net/ethernet/dec/tulip/uli526x.c
@@ -1837,7 +1837,7 @@ static int __init uli526x_init_module(void)
static void __exit uli526x_cleanup_module(void)
{
- ULI526X_DBUG(0, "uli526x_clean_module() ", debug);
+ ULI526X_DBUG(0, "uli526x_cleanup_module() ", debug);
pci_unregister_driver(&uli526x_driver);
}
^ permalink raw reply related
* Re: [PATCH v3 net-next] tcp: refine TSO autosizing
From: Yuchung Cheng @ 2014-12-07 21:24 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Neal Cardwell, Nandita Dukkipati
In-Reply-To: <1417983738.15618.38.camel@edumazet-glaptop2.roam.corp.google.com>
On Sun, Dec 7, 2014 at 12:22 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Commit 95bd09eb2750 ("tcp: TSO packets automatic sizing") tried to
> control TSO size, but did this at the wrong place (sendmsg() time)
>
> At sendmsg() time, we might have a pessimistic view of flow rate,
> and we end up building very small skbs (with 2 MSS per skb).
>
> This is bad because :
>
> - It sends small TSO packets even in Slow Start where rate quickly
> increases.
> - It tends to make socket write queue very big, increasing tcp_ack()
> processing time, but also increasing memory needs, not necessarily
> accounted for, as fast clones overhead is currently ignored.
> - Lower GRO efficiency and more ACK packets.
>
> Servers with a lot of small lived connections suffer from this.
>
> Lets instead fill skbs as much as possible (64KB of payload), but split
> them at xmit time, when we have a precise idea of the flow rate.
> skb split is actually quite efficient.
>
> Patch looks bigger than necessary, because TCP Small Queue decision now
> has to take place after the eventual split.
>
> As Neal suggested, introduce a new tcp_tso_autosize() helper, so that
> tcp_tso_should_defer() can be synchronized on same goal.
>
> Rename tp->xmit_size_goal_segs to tp->gso_segs, as this variable
> contains number of mss that we can put in GSO packet, and is not
> related to the autosizing goal anymore.
>
>
> Tested:
>
> 40 ms rtt link
>
> nstat >/dev/null
> netperf -H remote -l -2000000 -- -s 1000000
> nstat | egrep "IpInReceives|IpOutRequests|TcpOutSegs|IpExtOutOctets"
>
> Before patch :
>
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/s
>
> 87380 2000000 2000000 0.36 44.22
> IpInReceives 600 0.0
> IpOutRequests 599 0.0
> TcpOutSegs 1397 0.0
> IpExtOutOctets 2033249 0.0
>
>
> After patch :
>
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 87380 2000000 2000000 0.36 44.27
> IpInReceives 221 0.0
> IpOutRequests 232 0.0
> TcpOutSegs 1397 0.0
> IpExtOutOctets 2013953 0.0
>
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Very nice Eric. This would improve both performance and simplify the
complex TSO logic. I have a small question below.
> ---
> v3: tcp_xmit_size_goal() still needs to return a multiple of mss.
> v2: added tcp_tso_autosize() helper and removed tp->xmit_size_goal_segs
>
> include/linux/tcp.h | 2 -
> net/ipv4/tcp.c | 60 ++++++++++++++--------------------------
> net/ipv4/tcp_output.c | 59 +++++++++++++++++++++++++++------------
> 3 files changed, 63 insertions(+), 58 deletions(-)
>
> diff --git a/include/linux/tcp.h b/include/linux/tcp.h
> index f566b8567892ef0bb213de0540b37cfc6ac03ca0..3fa0a9669a3a662be81d4b04f7d117b11012257c 100644
> --- a/include/linux/tcp.h
> +++ b/include/linux/tcp.h
> @@ -130,7 +130,7 @@ struct tcp_sock {
> /* inet_connection_sock has to be the first member of tcp_sock */
> struct inet_connection_sock inet_conn;
> u16 tcp_header_len; /* Bytes of tcp header to send */
> - u16 xmit_size_goal_segs; /* Goal for segmenting output packets */
> + u16 gso_segs; /* Max number of segs per GSO packet */
>
> /*
> * Header prediction flags
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index dc13a3657e8e1b81ba0cb1fcd5386a9d0b106168..427aee33ffc04ad189d9d0ec24ab8004c25961ec 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -835,47 +835,29 @@ static unsigned int tcp_xmit_size_goal(struct sock *sk, u32 mss_now,
> int large_allowed)
> {
> struct tcp_sock *tp = tcp_sk(sk);
> - u32 xmit_size_goal, old_size_goal;
> -
> - xmit_size_goal = mss_now;
> -
> - if (large_allowed && sk_can_gso(sk)) {
> - u32 gso_size, hlen;
> -
> - /* Maybe we should/could use sk->sk_prot->max_header here ? */
> - hlen = inet_csk(sk)->icsk_af_ops->net_header_len +
> - inet_csk(sk)->icsk_ext_hdr_len +
> - tp->tcp_header_len;
> -
> - /* Goal is to send at least one packet per ms,
> - * not one big TSO packet every 100 ms.
> - * This preserves ACK clocking and is consistent
> - * with tcp_tso_should_defer() heuristic.
> - */
> - gso_size = sk->sk_pacing_rate / (2 * MSEC_PER_SEC);
> - gso_size = max_t(u32, gso_size,
> - sysctl_tcp_min_tso_segs * mss_now);
> -
> - xmit_size_goal = min_t(u32, gso_size,
> - sk->sk_gso_max_size - 1 - hlen);
> -
> - xmit_size_goal = tcp_bound_to_half_wnd(tp, xmit_size_goal);
> -
> - /* We try hard to avoid divides here */
> - old_size_goal = tp->xmit_size_goal_segs * mss_now;
> -
> - if (likely(old_size_goal <= xmit_size_goal &&
> - old_size_goal + mss_now > xmit_size_goal)) {
> - xmit_size_goal = old_size_goal;
> - } else {
> - tp->xmit_size_goal_segs =
> - min_t(u16, xmit_size_goal / mss_now,
> - sk->sk_gso_max_segs);
> - xmit_size_goal = tp->xmit_size_goal_segs * mss_now;
> - }
> + u32 new_size_goal, size_goal, hlen;
> +
> + if (!large_allowed || !sk_can_gso(sk))
> + return mss_now;
> +
> + /* Maybe we should/could use sk->sk_prot->max_header here ? */
> + hlen = inet_csk(sk)->icsk_af_ops->net_header_len +
> + inet_csk(sk)->icsk_ext_hdr_len +
> + tp->tcp_header_len;
> +
> + new_size_goal = sk->sk_gso_max_size - 1 - hlen;
> + new_size_goal = tcp_bound_to_half_wnd(tp, new_size_goal);
> +
> + /* We try hard to avoid divides here */
> + size_goal = tp->gso_segs * mss_now;
> + if (unlikely(new_size_goal < size_goal ||
> + new_size_goal >= size_goal + mss_now)) {
> + tp->gso_segs = min_t(u16, new_size_goal / mss_now,
> + sk->sk_gso_max_segs);
> + size_goal = tp->gso_segs * mss_now;
> }
>
> - return max(xmit_size_goal, mss_now);
> + return max(size_goal, mss_now);
> }
>
> static int tcp_send_mss(struct sock *sk, int *size_goal, int flags)
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index f5bd4bd3f7e669b3fd48a843d55e7313a30a3409..f37ecf53ee8a96827fc08bd203b0ca8857f8fc34 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -1524,6 +1524,27 @@ static bool tcp_nagle_check(bool partial, const struct tcp_sock *tp,
> ((nonagle & TCP_NAGLE_CORK) ||
> (!nonagle && tp->packets_out && tcp_minshall_check(tp)));
> }
> +
> +/* Return how many segs we'd like on a TSO packet,
> + * to send one TSO packet per ms
> + */
> +static u32 tcp_tso_autosize(const struct sock *sk, unsigned int mss_now)
> +{
> + u32 bytes, segs;
> +
> + bytes = min(sk->sk_pacing_rate >> 10,
> + sk->sk_gso_max_size - 1 - MAX_TCP_HEADER);
> +
> + /* Goal is to send at least one packet per ms,
> + * not one big TSO packet every 100 ms.
> + * This preserves ACK clocking and is consistent
> + * with tcp_tso_should_defer() heuristic.
> + */
> + segs = max_t(u32, bytes / mss_now, sysctl_tcp_min_tso_segs);
> +
> + return min_t(u32, segs, sk->sk_gso_max_segs);
> +}
> +
> /* Returns the portion of skb which can be sent right away */
> static unsigned int tcp_mss_split_point(const struct sock *sk,
> const struct sk_buff *skb,
> @@ -1731,7 +1752,7 @@ static int tso_fragment(struct sock *sk, struct sk_buff *skb, unsigned int len,
> * This algorithm is from John Heffner.
> */
> static bool tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb,
> - bool *is_cwnd_limited)
> + bool *is_cwnd_limited, u32 max_segs)
> {
> struct tcp_sock *tp = tcp_sk(sk);
> const struct inet_connection_sock *icsk = inet_csk(sk);
> @@ -1761,8 +1782,7 @@ static bool tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb,
> limit = min(send_win, cong_win);
>
> /* If a full-sized TSO skb can be sent, do it. */
> - if (limit >= min_t(unsigned int, sk->sk_gso_max_size,
> - tp->xmit_size_goal_segs * tp->mss_cache))
> + if (limit >= max_segs * tp->mss_cache)
> goto send_now;
>
> /* Middle in queue won't get any more data, full sendable already? */
> @@ -1959,6 +1979,7 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
> int cwnd_quota;
> int result;
> bool is_cwnd_limited = false;
> + u32 max_segs;
>
> sent_pkts = 0;
>
> @@ -1972,6 +1993,7 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
> }
> }
>
> + max_segs = tcp_tso_autosize(sk, mss_now);
> while ((skb = tcp_send_head(sk))) {
> unsigned int limit;
>
> @@ -2004,10 +2026,23 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
> break;
> } else {
> if (!push_one &&
> - tcp_tso_should_defer(sk, skb, &is_cwnd_limited))
> + tcp_tso_should_defer(sk, skb, &is_cwnd_limited,
> + max_segs))
> break;
> }
>
> + limit = mss_now;
> + if (tso_segs > 1 && !tcp_urg_mode(tp))
> + limit = tcp_mss_split_point(sk, skb, mss_now,
> + min_t(unsigned int,
> + cwnd_quota,
> + max_segs),
> + nonagle);
> +
> + if (skb->len > limit &&
> + unlikely(tso_fragment(sk, skb, limit, mss_now, gfp)))
> + break;
> +
> /* TCP Small Queues :
> * Control number of packets in qdisc/devices to two packets / or ~1 ms.
> * This allows for :
> @@ -2018,8 +2053,8 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
> * of queued bytes to ensure line rate.
> * One example is wifi aggregation (802.11 AMPDU)
> */
> - limit = max_t(unsigned int, sysctl_tcp_limit_output_bytes,
> - sk->sk_pacing_rate >> 10);
> + limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 10);
is this capping necessary if skb->truesize already takes the pacing
rate into account from the new logic above?
> + limit = min_t(u32, limit, sysctl_tcp_limit_output_bytes);
>
> if (atomic_read(&sk->sk_wmem_alloc) > limit) {
> set_bit(TSQ_THROTTLED, &tp->tsq_flags);
> @@ -2032,18 +2067,6 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
> break;
> }
>
> - limit = mss_now;
> - if (tso_segs > 1 && !tcp_urg_mode(tp))
> - limit = tcp_mss_split_point(sk, skb, mss_now,
> - min_t(unsigned int,
> - cwnd_quota,
> - sk->sk_gso_max_segs),
> - nonagle);
> -
> - if (skb->len > limit &&
> - unlikely(tso_fragment(sk, skb, limit, mss_now, gfp)))
> - break;
> -
> if (unlikely(tcp_transmit_skb(sk, skb, 1, gfp)))
> break;
>
>
>
^ permalink raw reply
* Re: [PATCH RFC] pci: Control whether VFs are probed on pci_enable_sriov
From: Don Dutile @ 2014-12-07 21:32 UTC (permalink / raw)
To: Yuval Mintz, Eli Cohen, bhelgaas@google.com, David Miller
Cc: linux-pci, netdev, ogerlitz@mellanox.com, yevgenyp@mellanox.com,
Eli Cohen
In-Reply-To: <B5657A6538887040AD3A81F1008BEC63BA6616@avmb3.qlogic.org>
On 12/07/2014 12:05 PM, Yuval Mintz wrote:
>
>> This can save host side resource usage by VF instances which would be
>> eventually probed to VMs.
>
>> Use a parameter to pci_enable_sriov to control that policy, and modify
>> all current callers such that they retain the same functionality.
>
> What's the end-game here? How eventually would this be controlled?
>
>> Use a one shot flag on struct pci_device which is cleared after the
>> first probe is ignored so subsequent attempts go through.
>
> Does a one-shot flag suffice? E.g., consider assigning a VF to VM and
> than shutting down the VM. Assuming this feature is disabled,
> the VF didn't appear on the hypervisor prior to the assignment but
> will appear after its shutdown.
>
+1 to this question.
All I see is a one-shot savings in VF configuration time at pci_sriov_enable() time.
Please explain why this is so important for mlx5 (sriov) operation?
Can the vf driver probe be called & exit early the first time, and perform full
(host) configuration thereafter?
- Don
^ permalink raw reply
* Re: Where exactly will arch_fast_hash be used
From: George Spelvin @ 2014-12-07 21:33 UTC (permalink / raw)
To: hannes, linux
Cc: davem, dborkman, herbert, linux-kernel, netdev, tgraf, tytso
In-Reply-To: <1417961203.17658.52.camel@localhost>
On Sun, 2014-12-07 at 15:06 +0100, Hannes Frederic Sowa wrote:
> In case of openvswitch it shows a performance improvment. The seed
> parameter could be used as an initial biasing of the crc32 function, but
> in case of openvswitch it is only set to 0.
NACK.
This is the Fatal Error in thinking that Herbert was warning about.
The seed parameter doesn't affect CRC32 collisions *at all* if the inputs
are the same size.
For fixed-size inputs, a non-zero seed is equivalent to XORing a
constant into the output of the CRC computation.
for *different* sized inputs, a non-zero seed detects zero-padding
better than a zero one, but *which* non-zero value is also irrelevant;
all-ones is the traditional choice because it's simplest in hardware.
A CRC is inherently linear. CRC(a^b) = CRC(a) ^ CRC(b). This makes
them easy to analyze mathematically and gives them a number of nice
properties for detecting hardware corruption.
But that same simplicity makes it *ridiculously* easy to generate
collisions if you try.
One way of looking at a CRC is to say that each bit in the input
has a CRC. The CRC of a message string is just the XOR of the CRCs
of the individual bits that are set in the message.
Now, a CRC polynomial is chosen so that all of the bits of a
message have different CRCs. Obviously, there's a limit: when the
message is 2^n bits long, it's not possible for all the bits to
have different, non-zero n-bit CRCs.
But a CRC is a really efficient way of assigning different bit patterns
to different input bits up to that limit.
(Something like CRC32c is also chosen so that, for messages up to a
reasonable length, no 3-bit, 4-bit, etc. combinations have CRCs that
XOR to zero.)
But, and this might be what Herbert was trying to say and I was
misunderstanding, if you then *truncate* that CRC, the CRCs of the
message bits lose that uniqueness guarantee. They're just pseudorandom
numbers, and a CRC loses its special collision-resistance properties.
It's just an ordinary random hash, and thanks to the birthday paradox,
you're likely to find two bits whose CRCs agree in any particular 8 bits
within roughly sqrt(2*256) or 22 bits.
Here are a few such collisions for the least significant 8 bits of CRC32c:
Msg1 CRC32c Msg2 CRC32c Match
1<<11 3fc5f181 1<<30 bf672381 81
1<<12 9d14c3b8 1<<31 dd45aab8 b8
1<<5 c79a971f 1<<44 6006181f 1f
1<<15 13a29877 1<<45 b2f53777 77
There's nothing special about the lsbits of the CRC.
Within 64 bits, the most significant 8 bits have it worse:
1<<5 c79a971f 1<<17 c76580d9 c7
1<<6 e13b70f7 1<<18 e144fb14 e1
1<<19 70a27d8a 1<<38 7022df58 70
1<<20 38513ec5 1<<39 38116fac 38
1<<13 4e8a61dc 1<<52 4e2dfd53 4e
1<<23 a541927e 1<<53 a5e0c5d1 a5
Now, I'd like to stress that this collision rate is no worse than any
*other* hash function. A truncated CRC loses its special resistance to
the birthday paradox (you'd have been much smarter to use 8-bit CRC),
but it doesn't become especially bad. A truncated SHA-1 will have
coillisions just as often.
The concern with a CRC is that, once you've found one collision, you've
found a huge number of them. Just XOR the bit pattern of your choice
into both of the colliding messages, and you have a new collision.
For another example, if you consider the CRC32c of all possible 1-byte
messages *and then take only the low byte*, there are only 128 possible
values.
It turns out that the byte 0x5d has a CRC32c of 0xee0d9600. This ends
in 00, so if I XOR 0x5d into anything, the low 8 bits of the CRC
don't change.
Likewise, the message "23 00" has a CRC32c of 0x00ee0d96. So you can
XOR 0x23 into the second-last byte of anything, and the high 8 bits of
the CRC don't change.
^ permalink raw reply
* [PATCH] net: wireless: rtlwifi: rtl8192de: fw.c: Remove unused function
From: Rickard Strandqvist @ 2014-12-07 22:00 UTC (permalink / raw)
To: Larry Finger, Chaoming Li
Cc: Rickard Strandqvist, John W. Linville, linux-wireless, netdev,
linux-kernel
Remove the function rtl92d_set_fw_pwrmode_cmd() that is not used anywhere.
This was partially found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
---
drivers/net/wireless/rtlwifi/rtl8192de/fw.c | 17 -----------------
drivers/net/wireless/rtlwifi/rtl8192de/fw.h | 1 -
2 files changed, 18 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/fw.c b/drivers/net/wireless/rtlwifi/rtl8192de/fw.c
index 2317707..62ef820 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192de/fw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192de/fw.c
@@ -540,23 +540,6 @@ void rtl92d_fill_h2c_cmd(struct ieee80211_hw *hw,
return;
}
-void rtl92d_set_fw_pwrmode_cmd(struct ieee80211_hw *hw, u8 mode)
-{
- struct rtl_priv *rtlpriv = rtl_priv(hw);
- u8 u1_h2c_set_pwrmode[3] = { 0 };
- struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
-
- RT_TRACE(rtlpriv, COMP_POWER, DBG_LOUD, "FW LPS mode = %d\n", mode);
- SET_H2CCMD_PWRMODE_PARM_MODE(u1_h2c_set_pwrmode, mode);
- SET_H2CCMD_PWRMODE_PARM_SMART_PS(u1_h2c_set_pwrmode, 1);
- SET_H2CCMD_PWRMODE_PARM_BCN_PASS_TIME(u1_h2c_set_pwrmode,
- ppsc->reg_max_lps_awakeintvl);
- RT_PRINT_DATA(rtlpriv, COMP_CMD, DBG_DMESG,
- "rtl92d_set_fw_rsvdpagepkt(): u1_h2c_set_pwrmode",
- u1_h2c_set_pwrmode, 3);
- rtl92d_fill_h2c_cmd(hw, H2C_SETPWRMODE, 3, u1_h2c_set_pwrmode);
-}
-
static bool _rtl92d_cmd_send_packet(struct ieee80211_hw *hw,
struct sk_buff *skb)
{
diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/fw.h b/drivers/net/wireless/rtlwifi/rtl8192de/fw.h
index a55a803..1646e7c 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192de/fw.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192de/fw.h
@@ -136,7 +136,6 @@ int rtl92d_download_fw(struct ieee80211_hw *hw);
void rtl92d_fill_h2c_cmd(struct ieee80211_hw *hw, u8 element_id,
u32 cmd_len, u8 *p_cmdbuffer);
void rtl92d_firmware_selfreset(struct ieee80211_hw *hw);
-void rtl92d_set_fw_pwrmode_cmd(struct ieee80211_hw *hw, u8 mode);
void rtl92d_set_fw_rsvdpagepkt(struct ieee80211_hw *hw, bool b_dl_finished);
void rtl92d_set_fw_joinbss_report_cmd(struct ieee80211_hw *hw, u8 mstatus);
--
1.7.10.4
^ permalink raw reply related
* Re: 3.12.33 - BUG xfrm_selector_match+0x25/0x2f6
From: Smart Weblications GmbH - Florian Wiessner @ 2014-12-07 22:04 UTC (permalink / raw)
To: Julian Anastasov
Cc: Steffen Klassert, netdev, LKML, stable, Simon Horman, lvs-devel
In-Reply-To: <alpine.LFD.2.11.1412052249570.1825@ja.home.ssi.bg>
Hi,
Am 05.12.2014 22:32, schrieb Julian Anastasov:
>
> Hello,
>
> On Fri, 5 Dec 2014, Smart Weblications GmbH - Florian Wiessner wrote:
>
>> thank you for the fast responses! I would like to test any patch for 3.12.
>
> I hope I'll have time this weekend...
>
>> If i understand correctly, i set:
>>
>> echo 0 > /proc/sys/net/ipv4/vs/snat_reroute
>
> The flag works per-packet, no need to reload any modules.
> But it does not help for the case with local client where
> the problem with sockets occurs, that is why you can keep
> ip_vs_route_me_harder() empty (return 0) until patch is
> created.
>
>> modprobe ip_vs_ftp
>>
>> and reenable ftp ipvs?
>>
>> It does not crash, but ftp is not working with neither PASV nor PORT:
>>
>>
>> [14:47:42] [R] Verbindung herstellen zu 192.168.10.62 -> IP=192.168.10.62 PORT=21
>> [14:47:42] [R] Verbunden mit 192.168.10.62
>> [14:47:43] [R] 220 (vsFTPd 3.0.2)
>> [14:47:43] [R] USER (hidden)
>> [14:47:43] [R] 331 Please specify the password.
>> [14:47:43] [R] PASS (hidden)
>> [14:47:43] [R] 230 Login successful.
>> [14:47:43] [R] SYST
>> [14:47:43] [R] 215 UNIX Type: L8
>> [14:47:43] [R] FEAT
>> [14:47:43] [R] 211-Features:
>> [14:47:43] [R] EPRT
>> [14:47:43] [R] EPSV
>> [14:47:43] [R] MDTM
>> [14:47:43] [R] PASV
>> [14:47:43] [R] REST STREAM
>> [14:47:43] [R] SIZE
>> [14:47:43] [R] TVFS
>> [14:47:43] [R] UTF8
>> [14:47:43] [R] 211 End
>> [14:47:43] [R] PWD
>> [14:47:43] [R] 257 "/"
>> [14:47:43] [R] CWD /
>> [14:47:43] [R] 250 Directory successfully changed.
>> [14:47:43] [R] PWD
>> [14:47:43] [R] 257 "/"
>> [14:47:43] [R] TYPE A
>> [14:47:43] [R] 200 Switching to ASCII mode.
>> [14:47:43] [R] PASV
>> [14:47:43] [R] 227 Entering Passive Mode (10,10,1,23,251,6).
>> [14:47:43] [R] Datenkanal-IP öffnen: 192.168.10.62 PORT: 64262
>> [14:47:44] [R] Datensocket-Fehler: Verbindung abgewiesen
>> [14:47:44] [R] List Fehler
>> [14:47:44] [R] PASV
>> [14:47:44] [R] 227 Entering Passive Mode (10,10,1,23,250,144).
>> [14:47:44] [R] Datenkanal-IP öffnen: 192.168.10.62 PORT: 64144
>> [14:47:45] [R] Datensocket-Fehler: Verbindung abgewiesen
>> [14:47:45] [R] List Fehler
>> [14:47:45] [R] PASV-Modus fehlgeschlagen, PORT -Modus versuchen...
>> [14:47:45] [R] Auf PORT: 62505 warten, Verbindung erwarten.
>> [14:47:45] [R] PORT 192,168,200,13,244,41
>> [14:47:45] [R] 500 Illegal PORT command.
>
> Who is 192.168.200.13? From vsftpd-3.0.2/postlogin.c,
> handle_port():
>
192.168.200.13 was the ftp client. As this client also was natted, PORT Mode
will fail here because the client provided the internal ip, but i disabled PORT
anyways before and did reenable it only to test...
> /* SECURITY:
> * 1) Reject requests not connecting to the control socket IP
> * 2) Reject connects to privileged ports
> */
>
> It looks like PORT command provides different IP.
> IIRC, IPVS does not mangle PORT command, vsftpd expects to
> connect to the same client IP. There is config option you can
> try to set (port_promiscuous), only while testing.
>
While this is true, PASV should have worked anyhow, right?
--
Mit freundlichen Grüßen,
Florian Wiessner
Smart Weblications GmbH
Martinsberger Str. 1
D-95119 Naila
fon.: +49 9282 9638 200
fax.: +49 9282 9638 205
24/7: +49 900 144 000 00 - 0,99 EUR/Min*
http://www.smart-weblications.de
--
Sitz der Gesellschaft: Naila
Geschäftsführer: Florian Wiessner
HRB-Nr.: HRB 3840 Amtsgericht Hof
*aus dem dt. Festnetz, ggf. abweichende Preise aus dem Mobilfunknetz
^ permalink raw reply
* [PATCH 1/3] can: peak_usb: fix memset() usage
From: Marc Kleine-Budde @ 2014-12-07 22:06 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Stephane Grosjean, linux-stable,
Marc Kleine-Budde
In-Reply-To: <1417989966-31309-1-git-send-email-mkl@pengutronix.de>
From: Stephane Grosjean <s.grosjean@peak-system.com>
This patchs fixes a misplaced call to memset() that fills the request
buffer with 0. The problem was with sending PCAN_USBPRO_REQ_FCT
requests, the content set by the caller was thus lost.
With this patch, the memory area is zeroed only when requesting info
from the device.
Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/usb/peak_usb/pcan_usb_pro.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_pro.c b/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
index 263dd921edc4..f7f796a2c50b 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
@@ -333,8 +333,6 @@ static int pcan_usb_pro_send_req(struct peak_usb_device *dev, int req_id,
if (!(dev->state & PCAN_USB_STATE_CONNECTED))
return 0;
- memset(req_addr, '\0', req_size);
-
req_type = USB_TYPE_VENDOR | USB_RECIP_OTHER;
switch (req_id) {
@@ -345,6 +343,7 @@ static int pcan_usb_pro_send_req(struct peak_usb_device *dev, int req_id,
default:
p = usb_rcvctrlpipe(dev->udev, 0);
req_type |= USB_DIR_IN;
+ memset(req_addr, '\0', req_size);
break;
}
--
2.1.3
^ permalink raw reply related
* [PATCH 3/3] can: peak_usb: fix multi-byte values endianess
From: Marc Kleine-Budde @ 2014-12-07 22:06 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel, Stephane Grosjean, Marc Kleine-Budde
In-Reply-To: <1417989966-31309-1-git-send-email-mkl@pengutronix.de>
From: Stephane Grosjean <s.grosjean@peak-system.com>
This patch fixes the endianess definition as well as the usage of the
multi-byte fields in the data structures exchanged with the PEAK-System USB
adapters.
By fixing the endianess, this patch also fixes the wrong usage of a 32-bits
local variable for handling the error status 16-bits field, in function
pcan_usb_pro_handle_error().
Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/usb/peak_usb/pcan_usb.c | 14 ++++----
drivers/net/can/usb/peak_usb/pcan_usb_core.c | 3 +-
drivers/net/can/usb/peak_usb/pcan_usb_pro.c | 20 ++++++------
drivers/net/can/usb/peak_usb/pcan_usb_pro.h | 48 ++++++++++++++--------------
4 files changed, 43 insertions(+), 42 deletions(-)
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb.c b/drivers/net/can/usb/peak_usb/pcan_usb.c
index 925ab8ec9329..4e1659d07979 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb.c
@@ -316,7 +316,7 @@ static int pcan_usb_get_serial(struct peak_usb_device *dev, u32 *serial_number)
if (err) {
netdev_err(dev->netdev, "getting serial failure: %d\n", err);
} else if (serial_number) {
- u32 tmp32;
+ __le32 tmp32;
memcpy(&tmp32, args, 4);
*serial_number = le32_to_cpu(tmp32);
@@ -347,7 +347,7 @@ static int pcan_usb_get_device_id(struct peak_usb_device *dev, u32 *device_id)
*/
static int pcan_usb_update_ts(struct pcan_usb_msg_context *mc)
{
- u16 tmp16;
+ __le16 tmp16;
if ((mc->ptr+2) > mc->end)
return -EINVAL;
@@ -371,7 +371,7 @@ static int pcan_usb_decode_ts(struct pcan_usb_msg_context *mc, u8 first_packet)
{
/* only 1st packet supplies a word timestamp */
if (first_packet) {
- u16 tmp16;
+ __le16 tmp16;
if ((mc->ptr + 2) > mc->end)
return -EINVAL;
@@ -614,7 +614,7 @@ static int pcan_usb_decode_data(struct pcan_usb_msg_context *mc, u8 status_len)
return -ENOMEM;
if (status_len & PCAN_USB_STATUSLEN_EXT_ID) {
- u32 tmp32;
+ __le32 tmp32;
if ((mc->ptr + 4) > mc->end)
goto decode_failed;
@@ -622,9 +622,9 @@ static int pcan_usb_decode_data(struct pcan_usb_msg_context *mc, u8 status_len)
memcpy(&tmp32, mc->ptr, 4);
mc->ptr += 4;
- cf->can_id = le32_to_cpu(tmp32 >> 3) | CAN_EFF_FLAG;
+ cf->can_id = (le32_to_cpu(tmp32) >> 3) | CAN_EFF_FLAG;
} else {
- u16 tmp16;
+ __le16 tmp16;
if ((mc->ptr + 2) > mc->end)
goto decode_failed;
@@ -632,7 +632,7 @@ static int pcan_usb_decode_data(struct pcan_usb_msg_context *mc, u8 status_len)
memcpy(&tmp16, mc->ptr, 2);
mc->ptr += 2;
- cf->can_id = le16_to_cpu(tmp16 >> 5);
+ cf->can_id = le16_to_cpu(tmp16) >> 5;
}
cf->can_dlc = get_can_dlc(rec_len);
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
index dc807e10f802..c62f48a1161d 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
@@ -856,6 +856,7 @@ static int peak_usb_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
struct usb_device *usb_dev = interface_to_usbdev(intf);
+ const u16 usb_id_product = le16_to_cpu(usb_dev->descriptor.idProduct);
struct peak_usb_adapter *peak_usb_adapter, **pp;
int i, err = -ENOMEM;
@@ -863,7 +864,7 @@ static int peak_usb_probe(struct usb_interface *intf,
/* get corresponding PCAN-USB adapter */
for (pp = peak_usb_adapters_list; *pp; pp++)
- if ((*pp)->device_id == usb_dev->descriptor.idProduct)
+ if ((*pp)->device_id == usb_id_product)
break;
peak_usb_adapter = *pp;
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_pro.c b/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
index f7f796a2c50b..4cfa3b8605b1 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_pro.c
@@ -78,8 +78,8 @@ struct pcan_usb_pro_msg {
int rec_buffer_size;
int rec_buffer_len;
union {
- u16 *rec_cnt_rd;
- u32 *rec_cnt;
+ __le16 *rec_cnt_rd;
+ __le32 *rec_cnt;
u8 *rec_buffer;
} u;
};
@@ -155,7 +155,7 @@ static int pcan_msg_add_rec(struct pcan_usb_pro_msg *pm, u8 id, ...)
*pc++ = va_arg(ap, int);
*pc++ = va_arg(ap, int);
*pc++ = va_arg(ap, int);
- *(u32 *)pc = cpu_to_le32(va_arg(ap, u32));
+ *(__le32 *)pc = cpu_to_le32(va_arg(ap, u32));
pc += 4;
memcpy(pc, va_arg(ap, int *), i);
pc += i;
@@ -165,7 +165,7 @@ static int pcan_msg_add_rec(struct pcan_usb_pro_msg *pm, u8 id, ...)
case PCAN_USBPRO_GETDEVID:
*pc++ = va_arg(ap, int);
pc += 2;
- *(u32 *)pc = cpu_to_le32(va_arg(ap, u32));
+ *(__le32 *)pc = cpu_to_le32(va_arg(ap, u32));
pc += 4;
break;
@@ -173,21 +173,21 @@ static int pcan_msg_add_rec(struct pcan_usb_pro_msg *pm, u8 id, ...)
case PCAN_USBPRO_SETBUSACT:
case PCAN_USBPRO_SETSILENT:
*pc++ = va_arg(ap, int);
- *(u16 *)pc = cpu_to_le16(va_arg(ap, int));
+ *(__le16 *)pc = cpu_to_le16(va_arg(ap, int));
pc += 2;
break;
case PCAN_USBPRO_SETLED:
*pc++ = va_arg(ap, int);
- *(u16 *)pc = cpu_to_le16(va_arg(ap, int));
+ *(__le16 *)pc = cpu_to_le16(va_arg(ap, int));
pc += 2;
- *(u32 *)pc = cpu_to_le32(va_arg(ap, u32));
+ *(__le32 *)pc = cpu_to_le32(va_arg(ap, u32));
pc += 4;
break;
case PCAN_USBPRO_SETTS:
pc++;
- *(u16 *)pc = cpu_to_le16(va_arg(ap, int));
+ *(__le16 *)pc = cpu_to_le16(va_arg(ap, int));
pc += 2;
break;
@@ -200,7 +200,7 @@ static int pcan_msg_add_rec(struct pcan_usb_pro_msg *pm, u8 id, ...)
len = pc - pm->rec_ptr;
if (len > 0) {
- *pm->u.rec_cnt = cpu_to_le32(*pm->u.rec_cnt+1);
+ *pm->u.rec_cnt = cpu_to_le32(le32_to_cpu(*pm->u.rec_cnt) + 1);
*pm->rec_ptr = id;
pm->rec_ptr = pc;
@@ -571,7 +571,7 @@ static int pcan_usb_pro_handle_canmsg(struct pcan_usb_pro_interface *usb_if,
static int pcan_usb_pro_handle_error(struct pcan_usb_pro_interface *usb_if,
struct pcan_usb_pro_rxstatus *er)
{
- const u32 raw_status = le32_to_cpu(er->status);
+ const u16 raw_status = le16_to_cpu(er->status);
const unsigned int ctrl_idx = (er->channel >> 4) & 0x0f;
struct peak_usb_device *dev = usb_if->dev[ctrl_idx];
struct net_device *netdev = dev->netdev;
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_pro.h b/drivers/net/can/usb/peak_usb/pcan_usb_pro.h
index 32275af547e0..837cee267132 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_pro.h
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_pro.h
@@ -33,27 +33,27 @@
/* PCAN_USBPRO_INFO_BL vendor request record type */
struct __packed pcan_usb_pro_blinfo {
- u32 ctrl_type;
+ __le32 ctrl_type;
u8 version[4];
u8 day;
u8 month;
u8 year;
u8 dummy;
- u32 serial_num_hi;
- u32 serial_num_lo;
- u32 hw_type;
- u32 hw_rev;
+ __le32 serial_num_hi;
+ __le32 serial_num_lo;
+ __le32 hw_type;
+ __le32 hw_rev;
};
/* PCAN_USBPRO_INFO_FW vendor request record type */
struct __packed pcan_usb_pro_fwinfo {
- u32 ctrl_type;
+ __le32 ctrl_type;
u8 version[4];
u8 day;
u8 month;
u8 year;
u8 dummy;
- u32 fw_type;
+ __le32 fw_type;
};
/*
@@ -80,46 +80,46 @@ struct __packed pcan_usb_pro_fwinfo {
struct __packed pcan_usb_pro_btr {
u8 data_type;
u8 channel;
- u16 dummy;
- u32 CCBT;
+ __le16 dummy;
+ __le32 CCBT;
};
struct __packed pcan_usb_pro_busact {
u8 data_type;
u8 channel;
- u16 onoff;
+ __le16 onoff;
};
struct __packed pcan_usb_pro_silent {
u8 data_type;
u8 channel;
- u16 onoff;
+ __le16 onoff;
};
struct __packed pcan_usb_pro_filter {
u8 data_type;
u8 dummy;
- u16 filter_mode;
+ __le16 filter_mode;
};
struct __packed pcan_usb_pro_setts {
u8 data_type;
u8 dummy;
- u16 mode;
+ __le16 mode;
};
struct __packed pcan_usb_pro_devid {
u8 data_type;
u8 channel;
- u16 dummy;
- u32 serial_num;
+ __le16 dummy;
+ __le32 serial_num;
};
struct __packed pcan_usb_pro_setled {
u8 data_type;
u8 channel;
- u16 mode;
- u32 timeout;
+ __le16 mode;
+ __le32 timeout;
};
struct __packed pcan_usb_pro_rxmsg {
@@ -127,8 +127,8 @@ struct __packed pcan_usb_pro_rxmsg {
u8 client;
u8 flags;
u8 len;
- u32 ts32;
- u32 id;
+ __le32 ts32;
+ __le32 id;
u8 data[8];
};
@@ -141,15 +141,15 @@ struct __packed pcan_usb_pro_rxmsg {
struct __packed pcan_usb_pro_rxstatus {
u8 data_type;
u8 channel;
- u16 status;
- u32 ts32;
- u32 err_frm;
+ __le16 status;
+ __le32 ts32;
+ __le32 err_frm;
};
struct __packed pcan_usb_pro_rxts {
u8 data_type;
u8 dummy[3];
- u32 ts64[2];
+ __le32 ts64[2];
};
struct __packed pcan_usb_pro_txmsg {
@@ -157,7 +157,7 @@ struct __packed pcan_usb_pro_txmsg {
u8 client;
u8 flags;
u8 len;
- u32 id;
+ __le32 id;
u8 data[8];
};
--
2.1.3
^ permalink raw reply related
* pull-request: can 2014-12-07
From: Marc Kleine-Budde @ 2014-12-07 22:06 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel
Hello David,
this is a pull request of three patches by Stephane Grosjean which fix several
bugs in the peak_usb CAN drivers.
Please queue, if possible for 3.18, if it's too late these patches takes the
slow lane via net-next.
regards,
Marc
---
The following changes since commit f2a01517f2a1040a0b156f171a7cefd748f2fd03:
openvswitch: Fix flow mask validation. (2014-12-05 21:42:16 -0800)
are available in the git repository at:
git://gitorious.org/linux-can/linux-can.git tags/linux-can-fixes-for-3.18-20141207
for you to fetch changes up to 62bc24f67abda56e486735706be6a4dea60fdb4c:
can: peak_usb: fix multi-byte values endianess (2014-12-07 21:04:03 +0100)
----------------------------------------------------------------
linux-can-fixes-for-3.18-20141207
----------------------------------------------------------------
Stephane Grosjean (3):
can: peak_usb: fix memset() usage
can: peak_usb: fix cleanup sequence order in case of error during init
can: peak_usb: fix multi-byte values endianess
drivers/net/can/usb/peak_usb/pcan_usb.c | 14 ++++----
drivers/net/can/usb/peak_usb/pcan_usb_core.c | 20 +++++++-----
drivers/net/can/usb/peak_usb/pcan_usb_pro.c | 23 +++++++------
drivers/net/can/usb/peak_usb/pcan_usb_pro.h | 48 ++++++++++++++--------------
4 files changed, 54 insertions(+), 51 deletions(-)
^ permalink raw reply
* [PATCH 2/3] can: peak_usb: fix cleanup sequence order in case of error during init
From: Marc Kleine-Budde @ 2014-12-07 22:06 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Stephane Grosjean, linux-stable,
Marc Kleine-Budde
In-Reply-To: <1417989966-31309-1-git-send-email-mkl@pengutronix.de>
From: Stephane Grosjean <s.grosjean@peak-system.com>
This patch sets the correct reverse sequence order to the instructions
set to run, when any failure occurs during the initialization steps.
It also adds the missing unregistration call of the can device if the
failure appears after having been registered.
Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/usb/peak_usb/pcan_usb_core.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
index 644e6ab8a489..dc807e10f802 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
@@ -735,7 +735,7 @@ static int peak_usb_create_dev(struct peak_usb_adapter *peak_usb_adapter,
dev->cmd_buf = kmalloc(PCAN_USB_MAX_CMD_LEN, GFP_KERNEL);
if (!dev->cmd_buf) {
err = -ENOMEM;
- goto lbl_set_intf_data;
+ goto lbl_free_candev;
}
dev->udev = usb_dev;
@@ -775,7 +775,7 @@ static int peak_usb_create_dev(struct peak_usb_adapter *peak_usb_adapter,
err = register_candev(netdev);
if (err) {
dev_err(&intf->dev, "couldn't register CAN device: %d\n", err);
- goto lbl_free_cmd_buf;
+ goto lbl_restore_intf_data;
}
if (dev->prev_siblings)
@@ -788,14 +788,14 @@ static int peak_usb_create_dev(struct peak_usb_adapter *peak_usb_adapter,
if (dev->adapter->dev_init) {
err = dev->adapter->dev_init(dev);
if (err)
- goto lbl_free_cmd_buf;
+ goto lbl_unregister_candev;
}
/* set bus off */
if (dev->adapter->dev_set_bus) {
err = dev->adapter->dev_set_bus(dev, 0);
if (err)
- goto lbl_free_cmd_buf;
+ goto lbl_unregister_candev;
}
/* get device number early */
@@ -807,11 +807,14 @@ static int peak_usb_create_dev(struct peak_usb_adapter *peak_usb_adapter,
return 0;
-lbl_free_cmd_buf:
- kfree(dev->cmd_buf);
+lbl_unregister_candev:
+ unregister_candev(netdev);
-lbl_set_intf_data:
+lbl_restore_intf_data:
usb_set_intfdata(intf, dev->prev_siblings);
+ kfree(dev->cmd_buf);
+
+lbl_free_candev:
free_candev(netdev);
return err;
--
2.1.3
^ permalink raw reply related
* pull-request: can-next 2014-12-07
From: Marc Kleine-Budde @ 2014-12-07 23:33 UTC (permalink / raw)
To: netdev; +Cc: David Miller, linux-can@vger.kernel.org, kernel@pengutronix.de
[-- Attachment #1: Type: text/plain, Size: 2697 bytes --]
Hello David,
this is a pull request of 8 patches for net-next/master.
Andri Yngvason contributes 4 patches in which the CAN state change
handling is consolidated and unified among the sja1000, mscan and
flexcan driver. The three patches by Jeremiah Mahler fix spelling
mistakes and eliminate the banner[] variable in various parts. And a
patch by me that switches on sparse endianess checking by default.
Marc
---
The following changes since commit 8d0c4697534a739725e429ff062dea393d8860d1:
Merge branch 'ebpf-next' (2014-12-05 21:47:48 -0800)
are available in the git repository at:
git://gitorious.org/linux-can/linux-can-next.git tags/linux-can-next-for-3.19-20141207
for you to fetch changes up to 71a3aedce6b37318d0e38676681dff179ec42874:
can: flexcan: Consolidate and unify state change handling (2014-12-07 21:22:10 +0100)
----------------------------------------------------------------
linux-can-next-for-3.19-20141207
----------------------------------------------------------------
Andri Yngvason (4):
can: dev: Consolidate and unify state change handling
can: sja1000: Consolidate and unify state change handling
can: mscan: Consolidate and unify state change handling
can: flexcan: Consolidate and unify state change handling
Jeremiah Mahler (3):
can: eliminate banner[] variable and switch to pr_info()
can: slcan/vcan: eliminate banner[] variable, switch to pr_info()
can: fix spelling errors
Marc Kleine-Budde (1):
can: Enable -D__CHECK_ENDIAN__ for sparse by default
drivers/net/can/Makefile | 3 +-
drivers/net/can/cc770/cc770.c | 2 +-
drivers/net/can/dev.c | 78 +++++++++++++++++++++++++++++
drivers/net/can/flexcan.c | 101 +++++++-------------------------------
drivers/net/can/mscan/mscan.c | 48 ++++++------------
drivers/net/can/sja1000/sja1000.c | 51 +++++++++----------
drivers/net/can/slcan.c | 7 +--
drivers/net/can/vcan.c | 5 +-
include/linux/can/dev.h | 3 ++
include/uapi/linux/can/error.h | 1 +
net/can/af_can.c | 7 +--
net/can/bcm.c | 16 +++---
net/can/gw.c | 2 +-
net/can/raw.c | 4 +-
14 files changed, 154 insertions(+), 174 deletions(-)
--
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
* Re: [PATCH 0/20] fix misspelling of current function in string
From: Julian Calaby @ 2014-12-07 23:44 UTC (permalink / raw)
To: Julia Lawall
Cc: devel@driverdev.osuosl.org, linux-samsung-soc, linux-scsi,
linux-pci, linux-wireless, intel-gfx, linux-usb, kernel-janitors,
linux-kernel@vger.kernel.org, dri-devel, netdev, linux-mtd, linux,
Joe Perches, Mailing List, Arm
In-Reply-To: <1417980062-25151-1-git-send-email-Julia.Lawall@lip6.fr>
Hi Julia,
On Mon, Dec 8, 2014 at 6:20 AM, Julia Lawall <Julia.Lawall@lip6.fr> wrote:
> These patches replace what appears to be a reference to the name of the
> current function but is misspelled in some way by either the name of the
> function itself, or by %s and then __func__ in an argument list.
Would there be any value in doing this for _all_ cases where the
function name is written in a format string?
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* iproute2: Important fixes
From: Vadim Kochan @ 2014-12-08 0:13 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev@vger.kernel.org
Hi Stephen,
Before releasing the 3.18 version can you please look at fixes in patch:
"[iproute2,REGRESSIONS,v3] ss: Fix layout issues introduced by regression"
and took to the 3.18 release if you will be OK with them ?
Thanks,
Vadim
^ permalink raw reply
* Re: [PATCH][net-next] net: avoid to call skb_queue_len again
From: Li RongQing @ 2014-12-08 0:46 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Sergei Shtylyov, netdev
In-Reply-To: <1417789870.15618.1.camel@edumazet-glaptop2.roam.corp.google.com>
On Fri, Dec 5, 2014 at 10:31 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Fri, 2014-12-05 at 17:06 +0300, Sergei Shtylyov wrote:
>> Hello.
>>
>> On 12/5/2014 12:49 PM, roy.qing.li@gmail.com wrote:
>>
>> > From: Li RongQing <roy.qing.li@gmail.com>
>>
>> > the queue length of sd->input_pkt_queue has been putted into qlen,
>>
>> s/putted/put/, it's irregular verb.
>>
I will fix it and resend this patch
>> > and impossible to change, since hold the lock
>>
>> I can't parse that. Who holds the lock?
>
> This thread/cpu holds the lock to manipulate input_pkt_queue.
>
> Otherwise, the following would break horribly....
>
> __skb_queue_tail(&sd->input_pkt_queue, skb);
>
>
Thanks Eric
-Roy
>
^ permalink raw reply
* [PATCH flow-net-next] net: flow: Correct spelling of action
From: Simon Horman @ 2014-12-08 1:14 UTC (permalink / raw)
To: John Fastabend; +Cc: netdev, Simon Horman
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
include/uapi/linux/if_flow.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/if_flow.h b/include/uapi/linux/if_flow.h
index 25aa744..9255990 100644
--- a/include/uapi/linux/if_flow.h
+++ b/include/uapi/linux/if_flow.h
@@ -356,7 +356,7 @@ enum {
* @uid unique identifier for flow
* @priority priority to execute flow match/action in table
* @match null terminated set of match uids match criteria
- * @actoin null terminated set of action uids to apply to match
+ * @action null terminated set of action uids to apply to match
*
* Flows must match all entries in match set.
*/
--
2.1.3
^ permalink raw reply related
* Re: [PATCH flow-net-next] net: flow: Correct spelling of action
From: John Fastabend @ 2014-12-08 1:36 UTC (permalink / raw)
To: Simon Horman; +Cc: netdev
In-Reply-To: <1418001295-2389-1-git-send-email-simon.horman@netronome.com>
On 12/07/2014 05:14 PM, Simon Horman wrote:
> Signed-off-by: Simon Horman <simon.horman@netronome.com>
> ---
> include/uapi/linux/if_flow.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/if_flow.h b/include/uapi/linux/if_flow.h
> index 25aa744..9255990 100644
> --- a/include/uapi/linux/if_flow.h
> +++ b/include/uapi/linux/if_flow.h
> @@ -356,7 +356,7 @@ enum {
> * @uid unique identifier for flow
> * @priority priority to execute flow match/action in table
> * @match null terminated set of match uids match criteria
> - * @actoin null terminated set of action uids to apply to match
> + * @action null terminated set of action uids to apply to match
> *
> * Flows must match all entries in match set.
> */
>
Great thanks Simon! Also I've added a bit so we can
distinguish between INGRESS pipelines and EGRESS pipelines
and a bunch of fixes to the netlink processing to check the
lengths correctly. I'll push those to my tree in the next day or
so. I'm also porting this to rocker switch now which I hope
should be ready in the next week for submitting.
Just to be clear this is against my git tree @
https://github.com/jrfastab/flow-net-next/
^ permalink raw reply
* [PATCH][net-next][V2] net: avoid to call skb_queue_len again
From: roy.qing.li @ 2014-12-08 1:42 UTC (permalink / raw)
To: netdev; +Cc: edumazet, sergei.shtylyov
From: Li RongQing <roy.qing.li@gmail.com>
the queue length of sd->input_pkt_queue has been put into qlen,
and impossible to change, since hold the lock
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 0814a56..b954400 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3297,7 +3297,7 @@ static int enqueue_to_backlog(struct sk_buff *skb, int cpu,
rps_lock(sd);
qlen = skb_queue_len(&sd->input_pkt_queue);
if (qlen <= netdev_max_backlog && !skb_flow_limit(skb, qlen)) {
- if (skb_queue_len(&sd->input_pkt_queue)) {
+ if (qlen) {
enqueue:
__skb_queue_tail(&sd->input_pkt_queue, skb);
input_queue_tail_incr_save(sd, qtail);
--
2.1.0
^ permalink raw reply related
* Re: [PATCH v8 3/3] net: hisilicon: new hip04 ethernet driver
From: Ding Tianhong @ 2014-12-08 1:48 UTC (permalink / raw)
To: Arnd Bergmann, Alexander Graf
Cc: mark.rutland, devicetree, f.fainelli, linux, eric.dumazet,
sergei.shtylyov, netdev, xuwei5, David.Laight, Zhangfei Gao,
davem, linux-arm-kernel
In-Reply-To: <2619239.NTtdNaZCJM@wuerfel>
On 2014/12/8 4:09, Arnd Bergmann wrote:
> On Sunday 07 December 2014 10:49:12 Alexander Graf wrote:
>> On 07.12.14 04:28, Ding Tianhong wrote:
>>> On 2014/12/7 8:42, Alexander Graf wrote:
>>>> On 19.04.14 03:13, Zhangfei Gao wrote:
>>>>> Support Hisilicon hip04 ethernet driver, including 100M / 1000M controller.
>>>>> The controller has no tx done interrupt, reclaim xmitted buffer in the poll.
>>>>>
>>>>> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
>>>>
>>>> Is this driver still supposed to go upstream? I presume this was the
>>>> last submission and it's been quite some time ago
>>>>
>>>
>>> yes, it is really a long time, but The hip04 did not support tx irq,
>>> we couldn't get any better idea to fix this defect, do you have any suggestion?
>>
>> Well, if hardware doesn't have a TX irq I don't see there's anything we
>> can do to fix that ;).
>
> I don't know if it's related to the ethernet on hip01, but I would assume
> it is, and that platform is currently being submitted for inclusion, so
> I'd definitely hope to see this driver get merged too eventually.
>
> IIRC, the last revision of the patch set had basically fixed the problem,
> except for a race that would still allow the napi poll function to exit
> with poll_complete() but a full queue of TX descriptors and no fallback
> to clean them up. There was also still an open question about whether or
> not the driver should use skb_orphan, but I may be misremembering that part.
>
>> Dave, what's your take here? Should we keep a driver from going upstream
>> just because the hardware is partly broken? I'd really prefer to have an
>> upstream driver on that SoC rather than some random (eventually even
>> more broken) downstream code.
>
> We can certainly have a slow driver for this hardware, and I'd much
> prefer slow over broken. I'd guess that some of the performance impact
> of the missing interrupts can now be offset with the xmit_more logic.
>
> Arnd
Ok, if so, I can modify this patch set and send them again base on zhangfei's last version
just for reviewing.
Regards
Ding
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> .
>
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: correct the endianness of doorbell_qpn on big endian platform
From: Wei Yang @ 2014-12-08 3:12 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, weiyang, netdev, gideonn, edumazet, amirv
In-Reply-To: <1417844801.15618.30.camel@edumazet-glaptop2.roam.corp.google.com>
On Fri, Dec 05, 2014 at 09:46:41PM -0800, Eric Dumazet wrote:
>On Fri, 2014-12-05 at 21:31 -0800, David Miller wrote:
>
>> Guys, let's figure out what we are doing with this patch.
>> --
>
>Oh well, patch is fine, please apply it, thanks !
Thanks :-)
>
>
--
Richard Yang
Help you, Help me
^ permalink raw reply
* [PATCH] net: phy: micrel: workaround to NAND_Tree# incorrectly strapp-in during the reset period.
From: Wenyou Yang @ 2014-12-08 3:35 UTC (permalink / raw)
To: f.fainelli
Cc: netdev, linux-kernel, nicolas.ferre, linux-arm-kernel-bounces,
wenyou.yang
Appearance: On some boards, after power up, the Ethernet doesn't work.
Reason: On the SAMA5D4EK, the PIOE2 pin is connected to the NAND_Tree# of KSZ8081,
But it outputs LOW during the reset period, which cause the NAND_Tree# enabled.
Workaround: In the .config_init(), add code to disable NAND_Tree#
by operating Operation Mode Strap Override(i.e. Register 16h).
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
---
drivers/net/phy/micrel.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 8c2a29a..11d72cb 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -31,6 +31,7 @@
/* Operation Mode Strap Override */
#define MII_KSZPHY_OMSO 0x16
#define KSZPHY_OMSO_B_CAST_OFF (1 << 9)
+#define KSZPHY_OMSO_NAND_TREE_OVERRIDE (1 << 5)
#define KSZPHY_OMSO_RMII_OVERRIDE (1 << 1)
#define KSZPHY_OMSO_MII_OVERRIDE (1 << 0)
@@ -180,7 +181,12 @@ static int kszphy_setup_led(struct phy_device *phydev,
static int kszphy_config_init(struct phy_device *phydev)
{
- return 0;
+ int rc;
+
+ phy_write(phydev, MII_KSZPHY_OMSO, phy_read(phydev, MII_KSZPHY_OMSO)
+ & (~KSZPHY_OMSO_NAND_TREE_OVERRIDE));
+ rc = ksz_config_flags(phydev);
+ return rc < 0 ? rc : 0;
}
static int kszphy_config_init_led8041(struct phy_device *phydev)
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH flow-net-next] net: flow: Correct spelling of action
From: Simon Horman @ 2014-12-08 3:47 UTC (permalink / raw)
To: John Fastabend; +Cc: netdev
In-Reply-To: <54850093.7050900@intel.com>
On Sun, Dec 07, 2014 at 05:36:19PM -0800, John Fastabend wrote:
> On 12/07/2014 05:14 PM, Simon Horman wrote:
> > Signed-off-by: Simon Horman <simon.horman@netronome.com>
> > ---
> > include/uapi/linux/if_flow.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/uapi/linux/if_flow.h b/include/uapi/linux/if_flow.h
> > index 25aa744..9255990 100644
> > --- a/include/uapi/linux/if_flow.h
> > +++ b/include/uapi/linux/if_flow.h
> > @@ -356,7 +356,7 @@ enum {
> > * @uid unique identifier for flow
> > * @priority priority to execute flow match/action in table
> > * @match null terminated set of match uids match criteria
> > - * @actoin null terminated set of action uids to apply to match
> > + * @action null terminated set of action uids to apply to match
> > *
> > * Flows must match all entries in match set.
> > */
> >
>
> Great thanks Simon! Also I've added a bit so we can
> distinguish between INGRESS pipelines and EGRESS pipelines
> and a bunch of fixes to the netlink processing to check the
> lengths correctly. I'll push those to my tree in the next day or
> so. I'm also porting this to rocker switch now which I hope
> should be ready in the next week for submitting.
>
> Just to be clear this is against my git tree @
>
> https://github.com/jrfastab/flow-net-next/
Yes, that is right.
Feel free to squash it into existing patches if you prefer.
^ permalink raw reply
* Re: [PATCH 0/20] fix misspelling of current function in string
From: Joe Perches @ 2014-12-08 3:55 UTC (permalink / raw)
To: Julia Lawall
Cc: devel, linux-samsung-soc, linux-scsi, linux-pci, linux-wireless,
intel-gfx, linux-usb, kernel-janitors, linux-kernel, dri-devel,
netdev, linux-mtd, linux, linux-arm-kernel
In-Reply-To: <1417980062-25151-1-git-send-email-Julia.Lawall@lip6.fr>
On Sun, 2014-12-07 at 20:20 +0100, Julia Lawall wrote:
> These patches replace what appears to be a reference to the name of the
> current function but is misspelled in some way by either the name of the
> function itself, or by %s and then __func__ in an argument list.
At least a few of these seem to be function tracing
style uses that might as well be deleted instead.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* OVS Kernel Datapath development
From: Pravin Shelar @ 2014-12-08 4:47 UTC (permalink / raw)
To: netdev, dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org
Since the beginning OVS kernel datapath development is primarily done
on external OVS repo. Now we have mostly synced upstream and external
OVS. So we have decided to change this process. New process is as
follows.
1. OVS feature development that involves kernel datapath should be
done on net-next tree datapath.
2. Such feature patch series should be posted on netdev and ovs-dev
mailing list.
3. Once review is done for entire series, kernel and OVS userspace
patches will be merged in respective repo.
4. After the merge developer is suppose to send patches for external
kernel datapath along with old kernel compatibility code. So that we
can keep external datapath insync.
Thanks,
Pravin.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH 2/3] bridge: offload bridge port attributes to switch asic if feature flag set
From: Roopa Prabhu @ 2014-12-08 4:56 UTC (permalink / raw)
To: Scott Feldman
Cc: Arad, Ronen, Netdev, Jirí Pírko, Jamal Hadi Salim,
Benjamin LaHaise, Thomas Graf, john fastabend,
stephen@networkplumber.org, John Linville, nhorman@tuxdriver.com,
Nicolas Dichtel, vyasevic@redhat.com, Florian Fainelli,
buytenh@wantstofly.org, Aviad Raveh, David S. Miller,
shm@cumulusnetworks.com, Andy Gospodarek
In-Reply-To: <5484B773.7000809@cumulusnetworks.com>
On 12/7/14, 12:24 PM, Roopa Prabhu wrote:
> On 12/5/14, 10:54 PM, Scott Feldman wrote:
>> On Fri, Dec 5, 2014 at 3:21 PM, Arad, Ronen <ronen.arad@intel.com>
>> wrote:
>>>
>>>> -----Original Message-----
>>>> From: netdev-owner@vger.kernel.org [mailto:netdev-
>>>> owner@vger.kernel.org] On Behalf Of Roopa Prabhu
>>>> Sent: Thursday, December 04, 2014 11:02 PM
>>>> To: Scott Feldman
>>>> Cc: Jiří Pírko; Jamal Hadi Salim; Benjamin LaHaise; Thomas Graf; john
>>>> fastabend; stephen@networkplumber.org; John Linville;
>>>> nhorman@tuxdriver.com; Nicolas Dichtel; vyasevic@redhat.com; Florian
>>>> Fainelli; buytenh@wantstofly.org; Aviad Raveh; Netdev; David S.
>>>> Miller;
>>>> shm@cumulusnetworks.com; Andy Gospodarek
>>>> Subject: Re: [PATCH 2/3] bridge: offload bridge port attributes to
>>>> switch asic
>>>> if feature flag set
>>>>
>>>> On 12/4/14, 10:41 PM, Scott Feldman wrote:
>>>>> On Thu, Dec 4, 2014 at 6:26 PM, <roopa@cumulusnetworks.com> wrote:
>>>>>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>>>>>
>>>>>> This allows offloading to switch asic without having the user to set
>>>>>> any flag. And this is done in the bridge driver to rollback kernel
>>>>>> settings on hw offload failure if required in the future.
>>>>>>
>>>>>> With this, it also makes sure a notification goes out only after the
>>>>>> attributes are set both in the kernel and hw.
>>>>> I like this approach as it streamlines the steps for the user in
>>>>> setting port flags. There is one case for FLOODING where you'll have
>>>>> to turn off flooding for both, and then turn on flooding in hw. You
>>>>> don't want flooding turned on on kernel and hw.
>>>> ok, maybe using the higher bits as in
>>>> https://patchwork.ozlabs.org/patch/413211/
>>>>
>>>> might help with that. Let me think some more.
>>>>>> ---
>>>>>> net/bridge/br_netlink.c | 27 ++++++++++++++++++++++++++-
>>>>>> 1 file changed, 26 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c index
>>>>>> 9f5eb55..ce173f0 100644
>>>>>> --- a/net/bridge/br_netlink.c
>>>>>> +++ b/net/bridge/br_netlink.c
>>>>>> @@ -407,9 +407,21 @@ int br_setlink(struct net_device *dev, struct
>>>> nlmsghdr *nlh)
>>>>>> afspec, RTM_SETLINK);
>>>>>> }
>>>>>>
>>>>>> + if ((dev->features & NETIF_F_HW_SWITCH_OFFLOAD) &&
>>>>>> + dev->netdev_ops->ndo_bridge_setlink) {
>>>>>> + int ret = dev->netdev_ops->ndo_bridge_setlink(dev,
>>>>>> + nlh);
>>>>> I think you want to up-level this to net/core/rtnetlink.c because
>>>>> you're only enabling the feature for one instance of a driver that
>>>>> implements ndo_bridge_setlink: the bridge driver. If another driver
>>>>> was MASTER and implemented ndo_bridge_setlink, you'd want same check
>>>>> to push setting down to SELF port driver.
>>>> yeah, i thought about that. But i moved it here so that rollback
>>>> would be
>>>> easier.
>>> There is a need for propagating setlink/dellink requests down
>>> multiple levels.
>>> The use-case I have in mind is a bridge at the top, team/bond in the
>>> middle, and port devices at the bottom.
>>> A setlink for VLAN filtering attributes would come with MASTER flag
>>> set, and either port or bond/team netdev.
>>> How would this be handled?
>>>
>>> The propagation rules between bridge and enslaved port device could
>>> be different from those between bond/team and enslaved devices.
>>> The current bridge driver does not propagate VLAN filtering from
>>> bridge to its ports as each port could have different configuration.
>>> In a case of a bond/team all members need to have the same
>>> configuration such that the a bond/team would be indistinguishable
>>> from a simple port.
>>>
>>> Therefore rtnetlink.c might not have the knowledge for propagation
>>> across multiple levels.
>>> It seems that each device which implements
>>> ndo_bridge_setlink/ndo_bridge_dellink and could have master role,
>>> need to take care of propagation to its slaves.
>> Thanks Ronen for bringing up this use-case of stacked masters. I
>> think for VLAN filtering, the stacked master case is handled, not by
>> ndo_setlink/dellink at each level, but with ndo_vlan_rx_kill_vid and
>> ndo_vlan_rx_add_vid. So the switch port driver can know VLAN
>> membership for port even if port is under bond which is under bridge,
>> by using ndo_vlan_rx_xxx and setting NETIF_F_HW_VLAN_CTAG_FILTER. The
>> bonding driver's ndo_vlan_rx_xxx handlers seem to keep ports in bond
>> VLAN membership consistent across bond.
>>
>> But in general, ndo_setlink/dellink don't work for the stack use-case
>> for other non-VLAN attributes. Maybe the answer is to use the VLAN
>> propogation model for other attributes. ndo_setlink/dellink/getlink
>> have enough weird-isms it might be time to define cleaner ndo ops to
>> propagate the other attrs down.
> And, only the switch asic driver is interested in these attrs. So,
> seems like for these cases, we need to send these attrs to the
> switchdriver directly instead of going through the stack of netdevs ?.
> see my response to ronen's other email.
As I work on v3 version of the patches, thinking some more, i am going
to try to use the OFFLOAD feature flag to traverse the stack of netdevs
(the bond to the slaves) to get to the switch port. This is only for
bridge port attrs for now.
^ permalink raw reply
* Re: [PATCH] net: phy: micrel: workaround to NAND_Tree# incorrectly strapp-in during the reset period.
From: Florian Fainelli @ 2014-12-08 5:08 UTC (permalink / raw)
To: Wenyou Yang
Cc: netdev, linux-kernel, nicolas.ferre, linux-arm-kernel-bounces,
johan
In-Reply-To: <1418009740-27384-1-git-send-email-wenyou.yang@atmel.com>
Le 07/12/2014 19:35, Wenyou Yang a écrit :
> Appearance: On some boards, after power up, the Ethernet doesn't work.
>
> Reason: On the SAMA5D4EK, the PIOE2 pin is connected to the NAND_Tree# of KSZ8081,
> But it outputs LOW during the reset period, which cause the NAND_Tree# enabled.
>
> Workaround: In the .config_init(), add code to disable NAND_Tree#
> by operating Operation Mode Strap Override(i.e. Register 16h).
Your patch won't apply cleanly to the net-next tree where the PHY
drivers development is happening, especially not after Johan's recent
changes.
Is not what you are looking for a phy_fixup() rather than clearing this
bit for all Micrel PHYs?
>
> Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
> ---
> drivers/net/phy/micrel.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
> index 8c2a29a..11d72cb 100644
> --- a/drivers/net/phy/micrel.c
> +++ b/drivers/net/phy/micrel.c
> @@ -31,6 +31,7 @@
> /* Operation Mode Strap Override */
> #define MII_KSZPHY_OMSO 0x16
> #define KSZPHY_OMSO_B_CAST_OFF (1 << 9)
> +#define KSZPHY_OMSO_NAND_TREE_OVERRIDE (1 << 5)
> #define KSZPHY_OMSO_RMII_OVERRIDE (1 << 1)
> #define KSZPHY_OMSO_MII_OVERRIDE (1 << 0)
>
> @@ -180,7 +181,12 @@ static int kszphy_setup_led(struct phy_device *phydev,
>
> static int kszphy_config_init(struct phy_device *phydev)
> {
> - return 0;
> + int rc;
> +
> + phy_write(phydev, MII_KSZPHY_OMSO, phy_read(phydev, MII_KSZPHY_OMSO)
> + & (~KSZPHY_OMSO_NAND_TREE_OVERRIDE));
> + rc = ksz_config_flags(phydev);
> + return rc < 0 ? rc : 0;
> }
>
> static int kszphy_config_init_led8041(struct phy_device *phydev)
>
^ 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