* Re: [PATCH v2] drivers/isdn: checkng length to be sure not memory overflow
From: David Miller @ 2013-03-08 5:36 UTC (permalink / raw)
To: gang.chen; +Cc: jslaby, jkosina, isdn, gregkh, alan, netdev
In-Reply-To: <51396845.3050600@asianux.com>
From: Chen Gang <gang.chen@asianux.com>
Date: Fri, 08 Mar 2013 12:25:41 +0800
>
> sizeof (cmd.parm.cmsg.para) is 50 (MAX_CAPI_PARA_LEN).
> sizeof (cmd.parm) is 80+, but less than 100.
> strlen(msg) may be more than 80+ (Modem-Commandbuffer, less than 255).
> isdn_tty_send_msg is called by isdn_tty_parse_at
> the relative parameter is m->mdmcmd (atemu *m)
> the relative command may be "+M..."
>
> so need check the length to be sure not memory overflow.
> cmd.parm is a union, and need keep original valid buffer length no touch
>
>
> Signed-off-by: Chen Gang <gang.chen@asianux.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/4] VXLAN: segmentation offload
From: Stephen Hemminger @ 2013-03-08 5:40 UTC (permalink / raw)
To: Pravin B Shelar; +Cc: davem, netdev, jesse
In-Reply-To: <1362698490-2378-1-git-send-email-pshelar@nicira.com>
On Thu, 7 Mar 2013 15:21:30 -0800
Pravin B Shelar <pshelar@nicira.com> wrote:
> Following patches add segmentation offload to VXLAN. These
> patches shows performance improvement from 3.9G to 5.8G (+50%)
> with netperf single process TCP_STREAM test on 10G network.
>
> Pravin B Shelar (4):
> net: Add skb_headers_offset_update helper function.
> tunneling: Capture inner mac header during encapsulation.
> tunneling: Add generic Tunnel segmentation.
> VXLAN: Use UDP Tunnel segmention.
>
> drivers/net/vxlan.c | 21 ++++++-
> include/linux/netdev_features.h | 7 +-
> include/linux/skbuff.h | 36 ++++++++++++
> net/core/ethtool.c | 1 +
> net/core/skbuff.c | 36 +++++-------
> net/ipv4/af_inet.c | 6 ++-
> net/ipv4/tcp.c | 1 +
> net/ipv4/udp.c | 116 ++++++++++++++++++++++++++++++--------
> net/ipv6/ip6_offload.c | 1 +
> net/ipv6/udp_offload.c | 10 +++-
> 10 files changed, 181 insertions(+), 54 deletions(-)
>
> --
> 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
Looks good, I wonder how well this will work with vendors plans to
offload segmentation of tunnel packets in hardware?
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
^ permalink raw reply
* Re: [PATCH net-next 1/4] net: Add skb_headers_offset_update helper function.
From: Stephen Hemminger @ 2013-03-08 5:40 UTC (permalink / raw)
To: Pravin B Shelar; +Cc: davem, netdev, jesse
In-Reply-To: <1362698500-2411-1-git-send-email-pshelar@nicira.com>
On Thu, 7 Mar 2013 15:21:40 -0800
Pravin B Shelar <pshelar@nicira.com> wrote:
> +static void skb_headers_offset_update(struct sk_buff *skb, int off)
> +{
> + /* {transport,network,mac}_header and tail are relative to skb->head */
> + skb->transport_header += off;
> + skb->network_header += off;
> + if (skb_mac_header_was_set(skb))
> + skb->mac_header += off;
> + skb->inner_transport_header += off;
> + skb->inner_network_header += off;
> +}
> +
Won't this cause an unused function warning if NET_SKBUFF_DATA_USES_OFFSET is defined?
^ permalink raw reply
* Re: [RFC PATCH v2 net-next 0/3] Allow bridge to function in non-promisc mode
From: Stephen Hemminger @ 2013-03-08 5:43 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, bridge
In-Reply-To: <1362691728-13289-1-git-send-email-vyasevic@redhat.com>
On Thu, 7 Mar 2013 16:28:45 -0500
Vlad Yasevich <vyasevic@redhat.com> wrote:
> The series adds an ability to configure the bridge into a non-primiscuous
> mode. Instead, it provides the ability to identitfy some set of bridge
> ports as uplinks and allows for MAC addresses to be programmed onto
> those ports. In case the port hardware does not support mac filter,
> that port will be placed in promiscuous mode.
>
> Default bridge operation continues to remain as "promiscuous". The new
> functionality has to be enabled via sysfs (similar to other bridge extensions).
>
> The uplink mode is implemented as a flag on a bridge port. The api to
> change that flag follows the existing api to enable/disable other existing
> flags.
>
> All comments are welcome.
>
Can we make this a one step process and less visible to the user.
If user defines an uplink device, and the uplink device is capable of filtering
(and what ever other pre-conditions people can think of), then the bridge will
transparently switch to uplink/non-promisc mode. This can also be used to trigger
edge only mode in RSTP in the future.
Less knobs.
^ permalink raw reply
* Re: [PATCH RFC] ipv6: use stronger hash for reassembly queue hash table
From: Hannes Frederic Sowa @ 2013-03-08 5:57 UTC (permalink / raw)
To: netdev, eric.dumazet, yoshfuji
In-Reply-To: <20130307214211.GP7941@order.stressinduktion.org>
On Thu, Mar 07, 2013 at 10:42:11PM +0100, Hannes Frederic Sowa wrote:
> ipv6_addr_hash can yield the exact same hash value for countless ip
> addresses from one /64 subnet. Let's make it a bit harder to create a
> long list of reassembly queues in the hash table by using a stronger hash.
>
> I spotted this just by looking at the source and did not verify if it
> is really the case, so this patch has RFC status. But the jhash change
> should not really hurt anyway. This patch is only compile tested.
Hmpf, I haven't seen Eric's change(279e9f2: ipv6: optimize
inet6_hash_frag()) and tried to compare a v3.8 against a net-next
kernel. At a first sight, it seems in some kind of denial of service
scenario the relative amount of time spend in inet_frag_find increased,
but I will do more comparable benchmarks later today (could be also
because of other changes). I just wanted to let you know that I will do
more research on this one and that you shouldn't apply this patch for now.
I also noticed that this function is also used by netfilter in the
forwarding path. Perhaps a jenkins hash on the destination address would
be better, too. Perhaps a netfilter specific hash function could also
be used.
Greetings,
Hannes
^ permalink raw reply
* Re: [net-next.git 0/9] stmmac: update to March_2013 (adding PTP & RGMII/SGMII)
From: Richard Cochran @ 2013-03-08 6:04 UTC (permalink / raw)
To: Giuseppe CAVALLARO; +Cc: netdev, bh74.an, ayagond
In-Reply-To: <1362653419-1047-1-git-send-email-peppe.cavallaro@st.com>
On Thu, Mar 07, 2013 at 11:50:10AM +0100, Giuseppe CAVALLARO wrote:
> Rayagond Kokatanur (4):
> stmmac: add tx_skbuff_dma to save descriptors used by PTP
> stmmac: add IEEE 1588-2002 PTP support
> stmmac: add the support for PTP hw clock driver
> stmmac: add IEEE 1588-2008 PTP V2 support
In the future, for PTP clock and time stamping patches, I would
appreciate being put on CC.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH] net/rds: zero last byte for strncpy
From: Chen Gang @ 2013-03-08 6:13 UTC (permalink / raw)
To: David Miller
Cc: bhutchings, David.Laight, venkat.x.venkatsubra, rds-devel, netdev
In-Reply-To: <20130308.003630.1150878411855053823.davem@davemloft.net>
于 2013年03月08日 13:36, David Miller 写道:
> From: Chen Gang <gang.chen@asianux.com>
> Date: Fri, 08 Mar 2013 11:19:32 +0800
>
>>
>> for NUL terminated string, need be always sure '\0' in the end.
>>
>> additional info:
>> strncpy will pads with zeroes to the end of the given buffer.
>> should initialise every bit of memory that is going to be copied to userland
>>
>>
>> Signed-off-by: Chen Gang <gang.chen@asianux.com>
>> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
>
> Applied.
>
>
thanks.
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* TCP small packets throughput and multiqueue virtio-net
From: Jason Wang @ 2013-03-08 6:24 UTC (permalink / raw)
To: netdev
Cc: Michael S. Tsirkin, KVM, David Miller, Eric Dumazet,
Stephen Hemminger, jpirko
Hello all:
I meet an issue when testing multiqueue virtio-net. When I testing guest
small packets stream sending performance with netperf. I find an
regression of multiqueue. When I run 2 sessions of TCP_STREAM test with
1024 byte from guest to local host, I get following result:
1q result: 3457.64
2q result: 7781.45
Statistics shows that: compared with one queue, multiqueue tends to send
much more but smaller packets. Tcpdump shows single queue has a much
higher possibility to produce a 64K gso packet compared to multiqueue.
More but smaller packets will cause more vmexits and interrupts which
lead a degradation on throughput.
Then problem only exist for small packets sending. When I test with
larger size, multiqueue will gradually outperfrom single queue. And
multiqueue also outperfrom in both TCP_RR and pktgen test (even with
small packets). The problem disappear when I turn off both gso and tso.
I'm not sure whether it's a bug or expected since anyway we get
improvement on latency. And if it's a bug, I suspect it was related to
TCP GSO batching algorithm who tends to batch less in this situation. (
Jiri Pirko suspect it was the defect of virtio-net driver, but I didn't
find any obvious clue on this). After some experiments, I find the it
maybe related to tcp_tso_should_defer(), after
1) change the tcp_tso_win_divisor to 1
2) the following changes
the throughput were almost the same (but still a little worse) as single
queue:
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index fd0cea1..dedd2a6 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1777,10 +1777,12 @@ static bool tcp_tso_should_defer(struct sock
*sk, struct sk_buff *skb)
limit = min(send_win, cong_win);
+#if 0
/* If a full-sized TSO skb can be sent, do it. */
if (limit >= min_t(unsigned int, sk->sk_gso_max_size,
sk->sk_gso_max_segs * tp->mss_cache))
goto send_now;
+#endif
/* Middle in queue won't get any more data, full sendable
already? */
if ((skb != tcp_write_queue_tail(sk)) && (limit >= skb->len))
Git history shows this check were added for both westwood and fasttcp,
I'm not familiar with tcp but looks like we can easily hit this check
under when multiqueue is enabled for virtio-net. Maybe I was wrong but I
wonder whether we can still do some batching here.
Any comments, thoughts are welcomed.
Thanks
^ permalink raw reply related
* Re: [net-next.git 2/9] stmmac: add IEEE 1588-2002 PTP support
From: Richard Cochran @ 2013-03-08 6:34 UTC (permalink / raw)
To: Giuseppe CAVALLARO; +Cc: netdev, bh74.an, ayagond, Rayagond Kokatanur
In-Reply-To: <1362653419-1047-3-git-send-email-peppe.cavallaro@st.com>
I have a few comments, below.
On Thu, Mar 07, 2013 at 11:50:12AM +0100, Giuseppe CAVALLARO wrote:
> From: Rayagond Kokatanur <rayagond@vayavyalabs.com>
>
> This patch enhances the stmmac driver to support IEEE 1588-2002
> PTP (Precision Time Protocol) version 1.
>
> IEEE 1588-2002 standard defines a protocol, Precision Time
> Protocol(PTP),
> which enables precise synchronization of clocks in measurement and
> control systems implemented with technologies such as network
> communication,local computing, & distributed objects.
>
> HW Timestamp support can be enabled while configuring the Kernel and
> the Koption is: STMMAC_USE_HWSTAMP
> At runtime, the support is verified by looking at the HW capability
> register.
As davem said, since you have the ability to detect this at run time,
then there is no need for a kconfig option.
> Signed-off-by: Rayagond Kokatanur <rayagond@vayavyalabs.com>
> Hacked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 +
> drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
> drivers/net/ethernet/stmicro/stmmac/chain_mode.c | 23 ++-
> drivers/net/ethernet/stmicro/stmmac/common.h | 27 ++-
> drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c | 1 -
> drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 37 +++
> drivers/net/ethernet/stmicro/stmmac/norm_desc.c | 34 +++
> drivers/net/ethernet/stmicro/stmmac/ring_mode.c | 14 +-
> drivers/net/ethernet/stmicro/stmmac/stmmac.h | 8 +
> .../net/ethernet/stmicro/stmmac/stmmac_hwstamp.c | 129 ++++++++++
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 255 +++++++++++++++++++-
> drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h | 72 ++++++
> 12 files changed, 588 insertions(+), 24 deletions(-)
> create mode 100644 drivers/net/ethernet/stmicro/stmmac/stmmac_hwstamp.c
> create mode 100644 drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> index c0ea838..ef703b3 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
> +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> @@ -71,5 +71,16 @@ config STMMAC_CHAINED
>
> endchoice
>
> +config STMMAC_USE_HWSTAMP
> + bool "Use IEEE 1588 Precision Time Protocol"
> + depends on STMMAC_ETH
> + select PTP_1588_CLOCK
> + default n
> + ---help---
> + Enable this option to support the IEEE 1588 Precision Time Protocol
> + (PTP) and HW Timestamps.
> + At runtime, on new chip generations, the hardware capability
> + register will be used to verify if either the IEEE 1588-2008 Advanced
> + Timestamping (PTPv2) or IEEE 1588-2002 (PTPv1) is actually supported.
>
> endif
> diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
> index c8e8ea6..cc97c07 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/Makefile
> +++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
> @@ -3,6 +3,7 @@ stmmac-$(CONFIG_STMMAC_RING) += ring_mode.o
> stmmac-$(CONFIG_STMMAC_CHAINED) += chain_mode.o
> stmmac-$(CONFIG_STMMAC_PLATFORM) += stmmac_platform.o
> stmmac-$(CONFIG_STMMAC_PCI) += stmmac_pci.o
> +stmmac-$(CONFIG_STMMAC_USE_HWSTAMP) += stmmac_hwstamp.o
> stmmac-objs:= stmmac_main.o stmmac_ethtool.o stmmac_mdio.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/chain_mode.c b/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
> index ad3d75f..dd60f6b 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/chain_mode.c
> @@ -92,16 +92,35 @@ static unsigned int stmmac_is_jumbo_frm(int len, int enh_desc)
> return ret;
> }
>
> -static void stmmac_refill_desc3(int bfsize, struct dma_desc *p)
> +static void stmmac_refill_desc3(void *priv_ptr, struct dma_desc *p)
> {
> + struct stmmac_priv *priv = (struct stmmac_priv *)priv_ptr;
> +
> + if (priv->hwts_rx_en)
> + /* NOTE: Device will overwrite des3 with timestamp value if
> + * 1588-2002 time stamping is enabled, hence reinitialize it
> + * to keep explicit chaining in the descriptor.
> + */
> + p->des3 = (unsigned int)(priv->dma_rx +
> + ((priv->dirty_rx) + 1) % priv->dma_rx_size);
> }
>
> static void stmmac_init_desc3(int des3_as_data_buf, struct dma_desc *p)
> {
> }
>
> -static void stmmac_clean_desc3(struct dma_desc *p)
> +static void stmmac_clean_desc3(void *priv_ptr, struct dma_desc *p,
> + int tstamp_taken)
> {
> + struct stmmac_priv *priv = (struct stmmac_priv *)priv_ptr;
> +
> + if (tstamp_taken && priv->hw->desc->get_tx_ls(p))
> + /* NOTE: Device will overwrite des3 with timestamp value if
> + * 1588-2002 time stamping is enabled, hence reinitialize it
> + * to keep explicit chaining in the descriptor.
> + */
> + p->des3 = (unsigned int)(priv->dma_tx +
> + ((priv->dirty_tx + 1) % priv->dma_tx_size));
> }
>
> static void stmmac_init_dma_chain(struct dma_desc *des, dma_addr_t phy_addr,
> diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
> index 186d148..fa8ff9b 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/common.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/common.h
> @@ -290,6 +290,16 @@ struct stmmac_desc_ops {
> /* Return the reception status looking at the RDES1 */
> int (*rx_status) (void *data, struct stmmac_extra_stats *x,
> struct dma_desc *p);
> + /* Set tx timestamp enable bit */
> + void (*enable_tx_timestamp) (struct dma_desc *p);
> + /* get tx timestamp status */
> + int (*get_tx_timestamp_status) (struct dma_desc *p);
> + /* get tx/rx timestamp low value */
> + u32 (*get_timestamp_low) (struct dma_desc *p);
> + /* get tx/rx timestamp high value */
> + u32 (*get_timestamp_high) (struct dma_desc *p);
These two separate functions should be combined into one.
> + /* get rx timestamp status */
> + int (*get_rx_timestamp_status) (struct dma_desc *p);
> };
>
> struct stmmac_dma_ops {
> @@ -346,6 +356,15 @@ struct stmmac_ops {
> void (*set_eee_pls) (void __iomem *ioaddr, int link);
> };
>
> +#ifdef CONFIG_STMMAC_USE_HWSTAMP
> +struct stmmac_hwtimestamp {
> + void (*config_hw_tstamping) (void __iomem *ioaddr, u32 data);
> + void (*config_sub_second_increment) (void __iomem *ioaddr);
> + int (*init_systime) (void __iomem *ioaddr, u32 sec, u32 nsec);
> + int (*config_addend)(void __iomem *ioaddr, u32 addend);
> +};
> +#endif
> +
> struct mac_link {
> int port;
> int duplex;
> @@ -360,11 +379,11 @@ struct mii_regs {
> struct stmmac_ring_mode_ops {
> unsigned int (*is_jumbo_frm) (int len, int ehn_desc);
> unsigned int (*jumbo_frm) (void *priv, struct sk_buff *skb, int csum);
> - void (*refill_desc3) (int bfsize, struct dma_desc *p);
> + void (*refill_desc3) (void *priv, struct dma_desc *p);
> void (*init_desc3) (int des3_as_data_buf, struct dma_desc *p);
> void (*init_dma_chain) (struct dma_desc *des, dma_addr_t phy_addr,
> unsigned int size);
> - void (*clean_desc3) (struct dma_desc *p);
> + void (*clean_desc3) (void *priv, struct dma_desc *p, int tstamp_taken);
> int (*set_16kib_bfsize) (int mtu);
> };
>
> @@ -373,6 +392,9 @@ struct mac_device_info {
> const struct stmmac_desc_ops *desc;
> const struct stmmac_dma_ops *dma;
> const struct stmmac_ring_mode_ops *ring;
> +#ifdef CONFIG_STMMAC_USE_HWSTAMP
> + const struct stmmac_hwtimestamp *ptp;
> +#endif
> struct mii_regs mii; /* MII register Addresses */
> struct mac_link link;
> unsigned int synopsys_uid;
> @@ -390,5 +412,4 @@ extern void stmmac_set_mac(void __iomem *ioaddr, bool enable);
>
> extern void dwmac_dma_flush_tx_fifo(void __iomem *ioaddr);
> extern const struct stmmac_ring_mode_ops ring_mode_ops;
> -
> #endif /* __COMMON_H__ */
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
> index 491d7e9..8c4ea93 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
> @@ -286,4 +286,3 @@ void stmmac_get_mac_addr(void __iomem *ioaddr, unsigned char *addr,
> addr[4] = hi_addr & 0xff;
> addr[5] = (hi_addr >> 8) & 0xff;
> }
> -
> diff --git a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
> index 2fc8ef9..4d635d5 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
> @@ -323,6 +323,38 @@ static int enh_desc_get_rx_frame_len(struct dma_desc *p, int rx_coe_type)
> return p->des01.erx.frame_length;
> }
>
> +static void enh_desc_enable_tx_timestamp(struct dma_desc *p)
> +{
> + p->des01.etx.time_stamp_enable = 1;
> +}
> +
> +static int enh_desc_get_tx_timestamp_status(struct dma_desc *p)
> +{
> + return p->des01.etx.time_stamp_status;
> +}
> +
> +static u32 enh_desc_get_timestamp_low(struct dma_desc *p)
> +{
> + /* FIXME if Enhance descriptor with 8 DWORDS is enabled */
> + return p->des2;
> +}
> +
> +static u32 enh_desc_get_timestamp_high(struct dma_desc *p)
> +{
> + /* FIXME if Enhance descriptor with 8 DWORDS is enabled */
> + return p->des3;
> +}
> +
> +static int enh_desc_get_rx_timestamp_status(struct dma_desc *p)
> +{
> + /* FIXME if Enhance descriptor with 8 DWORDS is enabled */
Why not fix these FIXMEs for the next respin?
> + if ((p->des2 == 0xffffffff) && (p->des3 == 0xffffffff))
> + /* timestamp is currupted, hence don't store it */
corrupted
> + return 0;
> + else
> + return 1;
> +}
> +
> const struct stmmac_desc_ops enh_desc_ops = {
> .tx_status = enh_desc_get_tx_status,
> .rx_status = enh_desc_get_rx_status,
> @@ -339,4 +371,9 @@ const struct stmmac_desc_ops enh_desc_ops = {
> .set_tx_owner = enh_desc_set_tx_owner,
> .set_rx_owner = enh_desc_set_rx_owner,
> .get_rx_frame_len = enh_desc_get_rx_frame_len,
> + .enable_tx_timestamp = enh_desc_enable_tx_timestamp,
> + .get_tx_timestamp_status = enh_desc_get_tx_timestamp_status,
> + .get_timestamp_low = enh_desc_get_timestamp_low,
> + .get_timestamp_high = enh_desc_get_timestamp_high,
> + .get_rx_timestamp_status = enh_desc_get_rx_timestamp_status,
> };
> diff --git a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
> index 68962c5..edb5e88 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
> @@ -215,6 +215,35 @@ static int ndesc_get_rx_frame_len(struct dma_desc *p, int rx_coe_type)
> return p->des01.rx.frame_length;
> }
>
> +static void ndesc_enable_tx_timestamp(struct dma_desc *p)
> +{
> + p->des01.tx.time_stamp_enable = 1;
> +}
> +
> +static int ndesc_get_tx_timestamp_status(struct dma_desc *p)
> +{
> + return p->des01.tx.time_stamp_status;
> +}
> +
> +static u32 ndesc_get_timestamp_low(struct dma_desc *p)
> +{
> + return p->des2;
> +}
> +
> +static u32 ndesc_get_timestamp_high(struct dma_desc *p)
> +{
> + return p->des3;
> +}
> +
> +static int ndesc_get_rx_timestamp_status(struct dma_desc *p)
> +{
> + if ((p->des2 == 0xffffffff) && (p->des3 == 0xffffffff))
> + /* timestamp is currupted, hence don't store it */
corrupted
> + return 0;
> + else
> + return 1;
> +}
> +
> const struct stmmac_desc_ops ndesc_ops = {
> .tx_status = ndesc_get_tx_status,
> .rx_status = ndesc_get_rx_status,
> @@ -231,4 +260,9 @@ const struct stmmac_desc_ops ndesc_ops = {
> .set_tx_owner = ndesc_set_tx_owner,
> .set_rx_owner = ndesc_set_rx_owner,
> .get_rx_frame_len = ndesc_get_rx_frame_len,
> + .enable_tx_timestamp = ndesc_enable_tx_timestamp,
> + .get_tx_timestamp_status = ndesc_get_tx_timestamp_status,
> + .get_timestamp_low = ndesc_get_timestamp_low,
> + .get_timestamp_high = ndesc_get_timestamp_high,
> + .get_rx_timestamp_status = ndesc_get_rx_timestamp_status,
> };
> diff --git a/drivers/net/ethernet/stmicro/stmmac/ring_mode.c b/drivers/net/ethernet/stmicro/stmmac/ring_mode.c
> index 839e349..94a1c2f 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/ring_mode.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/ring_mode.c
> @@ -85,11 +85,14 @@ static unsigned int stmmac_is_jumbo_frm(int len, int enh_desc)
> return ret;
> }
>
> -static void stmmac_refill_desc3(int bfsize, struct dma_desc *p)
> +static void stmmac_refill_desc3(void *priv_ptr, struct dma_desc *p)
> {
> - /* Fill DES3 in case of RING mode */
> - if (bfsize >= BUF_SIZE_8KiB)
> - p->des3 = p->des2 + BUF_SIZE_8KiB;
> + struct stmmac_priv *priv = (struct stmmac_priv *)priv_ptr;
> +
> + if (unlikely(priv->plat->has_gmac))
> + /* Fill DES3 in case of RING mode */
> + if (priv->dma_buf_sz >= BUF_SIZE_8KiB)
> + p->des3 = p->des2 + BUF_SIZE_8KiB;
> }
>
> /* In ring mode we need to fill the desc3 because it is used
> @@ -105,7 +108,8 @@ static void stmmac_init_dma_chain(struct dma_desc *des, dma_addr_t phy_addr,
> {
> }
>
> -static void stmmac_clean_desc3(struct dma_desc *p)
> +static void stmmac_clean_desc3(void *priv_ptr, struct dma_desc *p,
> + int tstamp_taken)
> {
> if (unlikely(p->des3))
> p->des3 = 0;
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> index 013a7d5..665f2a2 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> @@ -94,6 +94,11 @@ struct stmmac_priv {
> u32 tx_coal_timer;
> int use_riwt;
> u32 rx_riwt;
> +#ifdef CONFIG_STMMAC_USE_HWSTAMP
> + int hwts_tx_en;
> + int hwts_rx_en;
> + unsigned int default_addend;
> +#endif
> };
>
> extern int phyaddr;
> @@ -103,6 +108,9 @@ extern int stmmac_mdio_register(struct net_device *ndev);
> extern void stmmac_set_ethtool_ops(struct net_device *netdev);
> extern const struct stmmac_desc_ops enh_desc_ops;
> extern const struct stmmac_desc_ops ndesc_ops;
> +#ifdef CONFIG_STMMAC_USE_HWSTAMP
> +extern const struct stmmac_hwtimestamp stmmac_ptp;
> +#endif
> int stmmac_freeze(struct net_device *ndev);
> int stmmac_restore(struct net_device *ndev);
> int stmmac_resume(struct net_device *ndev);
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwstamp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwstamp.c
> new file mode 100644
> index 0000000..be9e399
> --- /dev/null
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwstamp.c
> @@ -0,0 +1,129 @@
> +/*******************************************************************************
> + Copyright (C) 2013 Vayavya Labs Pvt Ltd
> +
> + This implements all the API for managing HW timestamp & PTP.
> +
> + This program is free software; you can redistribute it and/or modify it
> + under the terms and conditions of the GNU General Public License,
> + version 2, as published by the Free Software Foundation.
> +
> + This program is distributed in the hope it will be useful, but WITHOUT
> + ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + more details.
> +
> + You should have received a copy of the GNU General Public License along with
> + this program; if not, write to the Free Software Foundation, Inc.,
> + 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
> +
> + The full GNU General Public License is included in this distribution in
> + the file called "COPYING".
> +
> + Author: Rayagond Kokatanur <rayagond@vayavyalabs.com>
> + Author: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> +*******************************************************************************/
> +
> +#include <linux/io.h>
> +#include <linux/delay.h>
> +#include "common.h"
> +#include "stmmac_ptp.h"
> +
> +static void stmmac_config_hw_tstamping(void __iomem *ioaddr, u32 data)
> +{
> + writel(data, ioaddr + PTP_TCR);
> +}
> +
> +static void stmmac_config_sub_second_increment(void __iomem *ioaddr)
> +{
> + u32 value = readl(ioaddr + PTP_TCR);
> + unsigned long data;
> +
> + /* Convert the ptp_clock to nano second
> + * formula = (1/ptp_clock) * 1000000000
> + * where, ptp_clock = 50MHz for FINE correction method &
> + * ptp_clock = STMMAC_SYSCLOCK for COARSE correction method
> + */
What are these coarse/fine method? Can't we always use the fine one?
> + if (value & PTP_TCR_TSCFUPDT)
> + data = (1000000000ULL / 50000000);
> + else
> + data = (1000000000ULL / STMMAC_SYSCLOCK);
> +
> + writel(data, ioaddr + PTP_SSIR);
> +}
> +
> +static int stmmac_init_systime(void __iomem *ioaddr, u32 sec, u32 nsec)
> +{
> + int limit;
> + u32 value;
> +
> + /* wait for previous(if any) system time initialize to complete */
> + limit = 100;
> + while (limit--) {
> + if (!(readl(ioaddr + PTP_TCR) & PTP_TCR_TSINIT))
> + break;
> + mdelay(10);
> + }
> +
> + if (limit < 0)
> + return -EBUSY;
> +
Ugh, this is terrible...
> + writel(sec, ioaddr + PTP_STSUR);
> + writel(nsec, ioaddr + PTP_STNSUR);
> + /* issue command to initialize the system time value */
> + value = readl(ioaddr + PTP_TCR);
> + value |= PTP_TCR_TSINIT;
> + writel(value, ioaddr + PTP_TCR);
> +
> + /* wait for present system time initialize to complete */
> + limit = 100;
> + while (limit--) {
> + if (!(readl(ioaddr + PTP_TCR) & PTP_TCR_TSINIT))
> + break;
> + mdelay(10);
> + }
> + if (limit < 0)
> + return -EBUSY;
... for a number of reasons.
1. You are polling for 100*10ms = one second, and the caller has
disabled interrupts! This is way too long. Is the hardware really
that slow? If so, then you need to use delayed work or find some
other way not to block.
2. You are waiting both before and after for the status bit. Pick one
or the other. You don't need both.
This same pattern is repeated a few times here, and it needs fixing in
each case.
> +
> + return 0;
> +}
> +
> +static int stmmac_config_addend(void __iomem *ioaddr, u32 addend)
> +{
> + u32 value;
> + int limit;
> +
> + /* wait for previous (if any) addend update to complete */
> + limit = 100;
> + while (limit--) {
> + if (!(readl(ioaddr + PTP_TCR) & PTP_TCR_TSADDREG))
> + break;
> + mdelay(10);
> + }
> + if (limit < 0)
> + return -EBUSY;
> +
> + writel(addend, ioaddr + PTP_TAR);
> + /* issue command to update the addend value */
> + value = readl(ioaddr + PTP_TCR);
> + value |= PTP_TCR_TSADDREG;
> + writel(value, ioaddr + PTP_TCR);
> +
> + /* wait for present addend update to complete */
> + limit = 100;
> + while (limit--) {
> + if (!(readl(ioaddr + PTP_TCR) & PTP_TCR_TSADDREG))
> + break;
> + mdelay(10);
> + }
> + if (limit < 0)
> + return -EBUSY;
> +
> + return 0;
> +}
> +
> +const struct stmmac_hwtimestamp stmmac_ptp = {
> + .config_hw_tstamping = stmmac_config_hw_tstamping,
> + .init_systime = stmmac_init_systime,
> + .config_sub_second_increment = stmmac_config_sub_second_increment,
> + .config_addend = stmmac_config_addend,
> +};
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 260af93..3bbd554 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -47,6 +47,10 @@
> #include <linux/debugfs.h>
> #include <linux/seq_file.h>
> #endif
> +#ifdef CONFIG_STMMAC_USE_HWSTAMP
> +#include <linux/net_tstamp.h>
> +#include "stmmac_ptp.h"
> +#endif
> #include "stmmac.h"
>
> #undef STMMAC_DEBUG
> @@ -304,6 +308,192 @@ static void stmmac_eee_adjust(struct stmmac_priv *priv)
> priv->hw->mac->set_eee_pls(priv->ioaddr, priv->phydev->link);
> }
>
> +#ifdef CONFIG_STMMAC_USE_HWSTAMP
> +/* stmmac_get_tx_hwtstamp:
> + * @priv : pointer to private device structure.
> + * @p : pointer to desc structure.
> + * @skb : the socket buffer
> + * Description :
> + * This function will read timestamp from the descriptor & pass it to stack.
> + * and also perform some sanity checks.
> + * Return value :
> + * 1 if time stamp is taken & 0 if time stamp is not taken.
> + */
> +static unsigned int stmmac_get_tx_hwtstamp(struct stmmac_priv *priv,
> + struct dma_desc *p,
> + struct sk_buff *skb)
> +{
> + struct skb_shared_hwtstamps shhwtstamp;
> + u64 ns;
> +
> + if (!priv->hwts_tx_en)
> + return 0;
> +
> + /* if skb doesn't support hw tstamp */
> + if (likely(!(skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS)))
> + return 0;
> +
> + /* check tx tstamp status */
> + if (!priv->hw->desc->get_tx_timestamp_status(p))
> + return 0;
> +
> + /* get the valid tstamp */
> + ns = priv->hw->desc->get_timestamp_low(p);
> + /* convert high/sec time stamp value to nanosecond */
> + ns += priv->hw->desc->get_timestamp_high(p) * 1000000000ULL;
> +
> + memset(&shhwtstamp, 0, sizeof(struct skb_shared_hwtstamps));
> + shhwtstamp.hwtstamp = ns_to_ktime(ns);
> + /* pass tstamp to stack */
> + skb_tstamp_tx(skb, &shhwtstamp);
> +
> + return 1;
> +}
> +
> +/* stmmac_get_rx_hwtstamp:
> + * @priv : pointer to private device structure.
> + * @p : pointer to desc structure.
> + * @skb : the socket buffer
> + * Description :
> + * This function will read received packet's timestamp from the descriptor
> + * and pass it to stack. It also perform some sanity checks.
> + */
> +static void stmmac_get_rx_hwtstamp(struct stmmac_priv *priv, struct dma_desc *p,
> + struct sk_buff *skb)
> +{
> + struct skb_shared_hwtstamps *shhwtstamp = NULL;
> + u64 ns;
> +
> + if (!priv->hwts_rx_en)
> + return;
> +
> + /* if rx tstamp is not valid */
> + if (!priv->hw->desc->get_rx_timestamp_status(p))
> + return;
> +
> + /* get valid tstamp */
> + ns = priv->hw->desc->get_timestamp_low(p);
> + /* convert high/sec time stamp value to nanosecond */
> + ns += priv->hw->desc->get_timestamp_high(p) * 1000000000ULL;
> + shhwtstamp = skb_hwtstamps(skb);
> + memset(shhwtstamp, 0, sizeof(struct skb_shared_hwtstamps));
> + shhwtstamp->hwtstamp = ns_to_ktime(ns);
> +}
> +
> +/**
> + * stmmac_hwtstamp_ioctl - control hardware timestamping.
> + * @dev: device pointer.
> + * @ifr: An IOCTL specefic structure, that can contain a pointer to
> + * a proprietary structure used to pass information to the driver.
> + * Description:
> + * This function configures the MAC to enable/disable both outgoing(TX)
> + * and incoming(RX) packets time stamping based on user input.
> + * Return Value:
> + * 0 on success and an appropriate -ve integer on failure.
> + */
> +static int stmmac_hwtstamp_ioctl(struct net_device *dev, struct ifreq *ifr)
> +{
> + struct stmmac_priv *priv = netdev_priv(dev);
> + struct hwtstamp_config config;
> + struct timespec now;
> + u64 temp = 0;
You add this new code here, but you change it all around again a few
patches later. Please just submit the final, combined version.
Thanks,
Richard
^ permalink raw reply
* Re: [net-next.git 0/9] stmmac: update to March_2013 (adding PTP & RGMII/SGMII)
From: Giuseppe CAVALLARO @ 2013-03-08 6:39 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev, bh74.an, ayagond
In-Reply-To: <20130308060445.GA2382@netboy.at.omicron.at>
On 3/8/2013 7:04 AM, Richard Cochran wrote:
> On Thu, Mar 07, 2013 at 11:50:10AM +0100, Giuseppe CAVALLARO wrote:
>
>> Rayagond Kokatanur (4):
>> stmmac: add tx_skbuff_dma to save descriptors used by PTP
>> stmmac: add IEEE 1588-2002 PTP support
>> stmmac: add the support for PTP hw clock driver
>> stmmac: add IEEE 1588-2008 PTP V2 support
>
> In the future, for PTP clock and time stamping patches, I would
> appreciate being put on CC.
Sorry Richard, I didn't know. You will be in copy when I send
the next patches.
Peppe
> Thanks,
> Richard
>
^ permalink raw reply
* Re: [net-next.git 2/9] stmmac: add IEEE 1588-2002 PTP support
From: Giuseppe CAVALLARO @ 2013-03-08 7:02 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev, bh74.an, Rayagond K, Rayagond Kokatanur
In-Reply-To: <20130308063437.GB2382@netboy.at.omicron.at>
On 3/8/2013 7:34 AM, Richard Cochran wrote:
> I have a few comments, below.
thanks for them.
>> HW Timestamp support can be enabled while configuring the Kernel and
>> the Koption is: STMMAC_USE_HWSTAMP
>> At runtime, the support is verified by looking at the HW capability
>> register.
>
> As davem said, since you have the ability to detect this at run time,
> then there is no need for a kconfig option.
I'll try to give you more details about this replying to D. Miller
[snip]
>> + /* get tx/rx timestamp low value */
>> + u32 (*get_timestamp_low) (struct dma_desc *p);
>> + /* get tx/rx timestamp high value */
>> + u32 (*get_timestamp_high) (struct dma_desc *p);
>
> These two separate functions should be combined into one.
ok
>> + /* get rx timestamp status */
>> + int (*get_rx_timestamp_status) (struct dma_desc *p);
>> +
>> +static int enh_desc_get_rx_timestamp_status(struct dma_desc *p)
>> +{
>> + /* FIXME if Enhance descriptor with 8 DWORDS is enabled */
>
> Why not fix these FIXMEs for the next respin?
This is fixed in the patch #5 where we use the extended descriptors
for PTP2.
>> + if ((p->des2 == 0xffffffff) && (p->des3 == 0xffffffff))
>> + /* timestamp is currupted, hence don't store it */
>
> corrupted
thanks
>> + /* Convert the ptp_clock to nano second
>> + * formula = (1/ptp_clock) * 1000000000
>> + * where, ptp_clock = 50MHz for FINE correction method &
>> + * ptp_clock = STMMAC_SYSCLOCK for COARSE correction method
>> + */
>
> What are these coarse/fine method? Can't we always use the fine one?
This is explained in the "4.1.2 System Time Register Module" of Synopsys
Databook. Summarizing, the MAC can have an optional module and use this
coarse correction method. In the fine correction method, a slave clock’s
frequency drift with respect to the master clock is corrected over a
period of time instead of in one clock, as in coarse correction.
Pls, Rayagond feels free to provide more details...
>> + if (value & PTP_TCR_TSCFUPDT)
>> + data = (1000000000ULL / 50000000);
>> + else
>> + data = (1000000000ULL / STMMAC_SYSCLOCK);
>> +
>> + writel(data, ioaddr + PTP_SSIR);
>> +}
>> +
>> +static int stmmac_init_systime(void __iomem *ioaddr, u32 sec, u32 nsec)
>> +{
>> + int limit;
>> + u32 value;
>> +
>> + /* wait for previous(if any) system time initialize to complete */
>> + limit = 100;
>> + while (limit--) {
>> + if (!(readl(ioaddr + PTP_TCR) & PTP_TCR_TSINIT))
>> + break;
>> + mdelay(10);
>> + }
>> +
>> + if (limit < 0)
>> + return -EBUSY;
>> +
>
> Ugh, this is terrible...
>
>> + writel(sec, ioaddr + PTP_STSUR);
>> + writel(nsec, ioaddr + PTP_STNSUR);
>> + /* issue command to initialize the system time value */
>> + value = readl(ioaddr + PTP_TCR);
>> + value |= PTP_TCR_TSINIT;
>> + writel(value, ioaddr + PTP_TCR);
>> +
>> + /* wait for present system time initialize to complete */
>> + limit = 100;
>> + while (limit--) {
>> + if (!(readl(ioaddr + PTP_TCR) & PTP_TCR_TSINIT))
>> + break;
>> + mdelay(10);
>> + }
>> + if (limit < 0)
>> + return -EBUSY;
>
> ... for a number of reasons.
>
> 1. You are polling for 100*10ms = one second, and the caller has
> disabled interrupts! This is way too long. Is the hardware really
> that slow? If so, then you need to use delayed work or find some
> other way not to block.
>
> 2. You are waiting both before and after for the status bit. Pick one
> or the other. You don't need both.
>
> This same pattern is repeated a few times here, and it needs fixing in
> each case.
This is for the Author. I've no HW where test. Rayagond tested all on
his side. Pls Rayagond fixes it and gives me the new code.
>> + struct stmmac_priv *priv = netdev_priv(dev);
>> + struct hwtstamp_config config;
>> + struct timespec now;
>> + u64 temp = 0;
>
> You add this new code here, but you change it all around again a few
> patches later. Please just submit the final, combined version.
we kept these separately because the patch #5 (for example) depends on
another one that adds the extended descriptor support. Also If I add
all the code in a single patch this will be very big. I had some
problems to review all separately. So I suspect that if we merge all
in a single patch this will not help (especially myself). At any rate,
tell me if you prefer to have a single patch. I can do that.
peppe
>
> Thanks,
> Richard
>
^ permalink raw reply
* Re: BUG: IPv4: Attempt to release TCP socket in state 1
From: dormando @ 2013-03-08 7:09 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Cong Wang, linux-kernel, netdev
In-Reply-To: <1362663990.15793.208.camel@edumazet-glaptop>
> On Wed, 2013-03-06 at 16:41 -0800, dormando wrote:
>
> > Ok... bridge module is loaded but nothing seems to be using it. No
> > bond/tunnels/anything enabled. I couldn't quickly figure out what was
> > causing it to load.
> >
> > We removed the need for macvlan, started machines with a fresh boot, and
> > they still crashed without it, after a few hours.
> >
> > Unfortunately I just saw a machine crash in the same way on 3.6.6 and
> > 3.6.9. I'm working on getting a completely pristine 3.6.6 and 3.6.9
> > tested. Our patches are minor but there were a few, so I'm backing it all
> > out just to be sure.
> >
> > Is there anything in particular which is most interesting? I can post lots
> > and lots and lots of information. Sadly bridge/macvlan weren't part of the
> > problem. .config, sysctls are easiest I guess? When this "hang" happens
> > the machine is still up somewhat, but we lose access to it. Syslog is
> > still writing entries to disk occasionally, so it's possible we could set
> > something up to dump more information.
> >
> > It takes a day or two to cycle this, so it might take a while to get
> > information and test crashes.
>
> Thanks !
>
> Please add a stack trace, it might help :
>
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index 68f6a94..1d4d97e 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -141,8 +141,9 @@ void inet_sock_destruct(struct sock *sk)
> sk_mem_reclaim(sk);
>
> if (sk->sk_type == SOCK_STREAM && sk->sk_state != TCP_CLOSE) {
> - pr_err("Attempt to release TCP socket in state %d %p\n",
> - sk->sk_state, sk);
> + pr_err("Attempt to release TCP socket family %d in state %d %p\n",
> + sk->sk_family, sk->sk_state, sk);
> + WARN_ON_ONCE(1);
> return;
> }
> if (!sock_flag(sk, SOCK_DEAD)) {
Ok. I have a pristine 3.6.6 up and testing now... It definitely looks like
we've been having this crash for quite a while, but much more rarely.
Recent changes in traffic have made it worse. I'll try your patch soon.
It'll take a few days to reproduce. I'll be back (ho ho ho). Please ping
with any ideas you folks might have in the meantime :(
^ permalink raw reply
* Re: [net-next.git 0/9] stmmac: update to March_2013 (adding PTP & RGMII/SGMII)
From: Giuseppe CAVALLARO @ 2013-03-08 7:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev, bh74.an, Rayagond K
In-Reply-To: <20130307.153456.83724032858548621.davem@davemloft.net>
Hello David
On 3/7/2013 9:34 PM, David Miller wrote:
> From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
> Date: Thu, 7 Mar 2013 11:50:10 +0100
>
>> The PTP support is quite intrusive because it needs to support the extended
>> descriptors used for saving the HW timestamps.
>> These are available in new chip generations, only.
>> So we have actually found useful to use some Kconfig options to
>> surround PTP and extended descriptor support. This approach helped on
>> old platform (embeeded system) where PTP is not supported and where we
>> do not want to pay extra code and check in critical rx/tx paths.
>
> I would prefer run time handling of all of this.
>
> You do not need to put extra checks in the fast paths, instead you
> have different methods that get hooked up into the netdev_ops
> based upon chip capabilities/features/mode.
I don't also like to see ifdef in C code and I always tried to
avoid them in the stmmac.
Indeed I haven't well explained the main reason of this Kconfig. Sorry!
To support PTPv2, we need to change the main descriptor structure
adding new fields (DES4,5,6,7).
The DESC4 is used for saving some extra information. For this reason
I added this support in a separate patch.
The DES6/7 are used for saving HW timestamps.
Unfortunately this new layout breaks the compatibility with old chips.
On new chips that supports the extended descriptors, in fact, we have a
ATDS bit in the DMA MODE register to allow the DMA to use the new
alternate structure.
This is not completely supported in old chips.
For this reason I decided to add these extra Koption.
Welcome advice.
Peppe
>
> Thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/4] net: Add skb_headers_offset_update helper function.
From: Pravin Shelar @ 2013-03-08 7:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, netdev, jesse
In-Reply-To: <20130307214025.639c713c@nehalam.linuxnetplumber.net>
On Thu, Mar 7, 2013 at 9:40 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> On Thu, 7 Mar 2013 15:21:40 -0800
> Pravin B Shelar <pshelar@nicira.com> wrote:
>
>> +static void skb_headers_offset_update(struct sk_buff *skb, int off)
>> +{
>> + /* {transport,network,mac}_header and tail are relative to skb->head */
>> + skb->transport_header += off;
>> + skb->network_header += off;
>> + if (skb_mac_header_was_set(skb))
>> + skb->mac_header += off;
>> + skb->inner_transport_header += off;
>> + skb->inner_network_header += off;
>> +}
>> +
>
> Won't this cause an unused function warning if NET_SKBUFF_DATA_USES_OFFSET is defined?
This function is used in both cases, so it should be ok.
Thanks,
Pravin.
^ permalink raw reply
* Re: [PATCH 1/3] driver: net: ethernet: cpsw: implement ethtool get/set phy setting
From: Mugunthan V N @ 2013-03-08 7:23 UTC (permalink / raw)
To: Ben Hutchings
Cc: Peter Korsgaard, netdev, davem, devicetree-discuss, linux-omap,
b-cousson, paul
In-Reply-To: <1362686350.2936.43.camel@bwh-desktop.uk.solarflarecom.com>
On 3/8/2013 1:29 AM, Ben Hutchings wrote:
> On Thu, 2013-03-07 at 14:24 +0100, Peter Korsgaard wrote:
>>>>>>> "M" == Mugunthan V N <mugunthanvnm@ti.com> writes:
>> M> This patch implements get/set of the phy settings via ethtool apis
>> M> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
>> M> ---
>> M> Documentation/devicetree/bindings/net/cpsw.txt | 3 +++
>> M> drivers/net/ethernet/ti/cpsw.c | 32 ++++++++++++++++++++++++
>> M> include/linux/platform_data/cpsw.h | 1 +
>> M> 3 files changed, 36 insertions(+)
>>
>> M> diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt
>> M> index ecfdf75..8d61300 100644
>> M> --- a/Documentation/devicetree/bindings/net/cpsw.txt
>> M> +++ b/Documentation/devicetree/bindings/net/cpsw.txt
>> M> @@ -20,6 +20,7 @@ Required properties:
>> M> - cpts_clock_shift : Denominator to convert input clock ticks into nanoseconds
>> M> - phy_id : Specifies slave phy id
>> M> - mac-address : Specifies slave MAC address
>> M> +- ethtool-active-slave : Specifies the slave to use for ethtool command
>>
>> That again sounds like something Linux specific rather than a hardware
>> property.
> Yes, indeed. Isn't it redundant with the phy_id?
>
> Ben.
phy_id is part of slave data and will be present for both the slaves.
so phy_id cannot be used for get/set phy setting until phy framework
allows to change settings without going through eth interface.
Regards
Mugunthan V N
^ permalink raw reply
* Re: [Patch net] bridge: do not expire mdb entry when bridge still uses it
From: Cong Wang @ 2013-03-08 7:26 UTC (permalink / raw)
To: Herbert Xu; +Cc: Stephen Hemminger, netdev, bridge, David S. Miller, Adam Baker
In-Reply-To: <20130308040853.GA27704@gondor.apana.org.au>
On Fri, 2013-03-08 at 12:08 +0800, Herbert Xu wrote:
> On Fri, Mar 08, 2013 at 12:06:53PM +0800, Cong Wang wrote:
> >
> > The mdst may be removed, however the BR_INPUT_SKB_CB_MROUTERS_ONLY(skb)
> > is still set, because in br_multicast_ipv4_rcv():
>
> But those packets are only meant for routers, which is why we
> have the br_multicast_is_router test above.
>
Hmm, what the user experiences is the multicast traffic between the
bridge and some port is broken. Isn't this expected to work by default?
Or we can just change the default value of br->multicast_router to 2?
Thanks!
^ permalink raw reply
* [PATCH] sctp: don't break the loop while meeting the active_path so as to find the matched transport
From: Xufeng Zhang @ 2013-03-08 7:39 UTC (permalink / raw)
To: vyasevich, nhorman, davem; +Cc: linux-sctp, netdev, linux-kernel
sctp_assoc_lookup_tsn() function searchs which transport a certain TSN
was sent on, if not found in the active_path transport, then go search
all the other transports in the peer's transport_addr_list, however, we
should continue to the next entry rather than break the loop when meet
the active_path transport.
Signed-off-by: Xufeng Zhang <xufeng.zhang@windriver.com>
---
net/sctp/associola.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/sctp/associola.c b/net/sctp/associola.c
index 43cd0dd..d2709e2 100644
--- a/net/sctp/associola.c
+++ b/net/sctp/associola.c
@@ -1079,7 +1079,7 @@ struct sctp_transport *sctp_assoc_lookup_tsn(struct sctp_association *asoc,
transports) {
if (transport == active)
- break;
+ continue;
list_for_each_entry(chunk, &transport->transmitted,
transmitted_list) {
if (key == chunk->subh.data_hdr->tsn) {
--
1.7.0.2
^ permalink raw reply related
* Re: [net-next.git 2/9] stmmac: add IEEE 1588-2002 PTP support
From: Rayagond K @ 2013-03-08 7:51 UTC (permalink / raw)
To: Giuseppe CAVALLARO; +Cc: Richard Cochran, netdev, bh74.an
In-Reply-To: <51398CFD.9010605@st.com>
On Fri, Mar 8, 2013 at 12:32 PM, Giuseppe CAVALLARO
<peppe.cavallaro@st.com> wrote:
>
> On 3/8/2013 7:34 AM, Richard Cochran wrote:
>>
>> I have a few comments, below.
>
>
> thanks for them.
>
>
>>> HW Timestamp support can be enabled while configuring the Kernel and
>>> the Koption is: STMMAC_USE_HWSTAMP
>>> At runtime, the support is verified by looking at the HW capability
>>> register.
>>
>>
>> As davem said, since you have the ability to detect this at run time,
>> then there is no need for a kconfig option.
>
>
> I'll try to give you more details about this replying to D. Miller
>
> [snip]
>
>
>>> + /* get tx/rx timestamp low value */
>>> + u32 (*get_timestamp_low) (struct dma_desc *p);
>>> + /* get tx/rx timestamp high value */
>>> + u32 (*get_timestamp_high) (struct dma_desc *p);
>>
>>
>> These two separate functions should be combined into one.
>
>
> ok
>
>
>>> + /* get rx timestamp status */
>>> + int (*get_rx_timestamp_status) (struct dma_desc *p);
>
>
>>> +
>>> +static int enh_desc_get_rx_timestamp_status(struct dma_desc *p)
>>> +{
>>> + /* FIXME if Enhance descriptor with 8 DWORDS is enabled */
>>
>>
>> Why not fix these FIXMEs for the next respin?
>
>
> This is fixed in the patch #5 where we use the extended descriptors
> for PTP2.
>
>
>>> + if ((p->des2 == 0xffffffff) && (p->des3 == 0xffffffff))
>>> + /* timestamp is currupted, hence don't store it */
>>
>>
>> corrupted
>
>
> thanks
>
>
>
>>> + /* Convert the ptp_clock to nano second
>>> + * formula = (1/ptp_clock) * 1000000000
>>> + * where, ptp_clock = 50MHz for FINE correction method &
>>> + * ptp_clock = STMMAC_SYSCLOCK for COARSE correction method
>>> + */
>>
>>
>> What are these coarse/fine method? Can't we always use the fine one?
>
>
> This is explained in the "4.1.2 System Time Register Module" of Synopsys
> Databook. Summarizing, the MAC can have an optional module and use this
> coarse correction method. In the fine correction method, a slave clock’s
> frequency drift with respect to the master clock is corrected over a period
> of time instead of in one clock, as in coarse correction.
>
> Pls, Rayagond feels free to provide more details...
Yes Synopsys core support two method for correcting the system time ie
COARSE method and FINE method.
In the fine correction method, a slave clock’s frequency drift with
respect to the master clock (as defined in IEEE 1588) is corrected
over a period of time instead of in one clock, as in coarse
correction. This helps maintain linear time and does not introduce
drastic changes (or a large jitter) in the reference time between PTP
Sync message intervals.
And updating the SSNR (Sub Second Increment Register) depends on which
method is selected during the initialization.
>
>>> + if (value & PTP_TCR_TSCFUPDT)
>>> + data = (1000000000ULL / 50000000);
>>> + else
>>> + data = (1000000000ULL / STMMAC_SYSCLOCK);
>>> +
>>> + writel(data, ioaddr + PTP_SSIR);
>>> +}
>>> +
>>> +static int stmmac_init_systime(void __iomem *ioaddr, u32 sec, u32 nsec)
>>> +{
>>> + int limit;
>>> + u32 value;
>>> +
>>> + /* wait for previous(if any) system time initialize to complete
>>> */
>>> + limit = 100;
>>> + while (limit--) {
>>> + if (!(readl(ioaddr + PTP_TCR) & PTP_TCR_TSINIT))
>>> + break;
>>> + mdelay(10);
>>> + }
>>> +
>>> + if (limit < 0)
>>> + return -EBUSY;
>>> +
>>
>>
>> Ugh, this is terrible...
>>
>>> + writel(sec, ioaddr + PTP_STSUR);
>>> + writel(nsec, ioaddr + PTP_STNSUR);
>>> + /* issue command to initialize the system time value */
>>> + value = readl(ioaddr + PTP_TCR);
>>> + value |= PTP_TCR_TSINIT;
>>> + writel(value, ioaddr + PTP_TCR);
>>> +
>>> + /* wait for present system time initialize to complete */
>>> + limit = 100;
>>> + while (limit--) {
>>> + if (!(readl(ioaddr + PTP_TCR) & PTP_TCR_TSINIT))
>>> + break;
>>> + mdelay(10);
>>> + }
>>> + if (limit < 0)
>>> + return -EBUSY;
>>
>>
>> ... for a number of reasons.
>>
>> 1. You are polling for 100*10ms = one second, and the caller has
>> disabled interrupts! This is way too long. Is the hardware really
>> that slow? If so, then you need to use delayed work or find some
>> other way not to block.
Sorry for this, during testing I just used maximum delay as there was
bug in the HW initially. But after fixing the HW issue I noticed that
HW is not that much slow. We will reduce the delay in all functions.
>>
>> 2. You are waiting both before and after for the status bit. Pick one
>> or the other. You don't need both.
>>
>> This same pattern is repeated a few times here, and it needs fixing in
>> each case.
Sure will change it. I added just to make sure double check here.
Practically first wait is not required, will remove this.
>
>
> This is for the Author. I've no HW where test. Rayagond tested all on his
> side. Pls Rayagond fixes it and gives me the new code.
>
>
>>> + struct stmmac_priv *priv = netdev_priv(dev);
>>> + struct hwtstamp_config config;
>>> + struct timespec now;
>>> + u64 temp = 0;
>>
>>
>> You add this new code here, but you change it all around again a few
>> patches later. Please just submit the final, combined version.
>
>
> we kept these separately because the patch #5 (for example) depends on
> another one that adds the extended descriptor support. Also If I add
> all the code in a single patch this will be very big. I had some
> problems to review all separately. So I suspect that if we merge all
> in a single patch this will not help (especially myself). At any rate,
> tell me if you prefer to have a single patch. I can do that.
>
> peppe
>>
>>
>> Thanks,
>> Richard
>>
>
Thanks
Rayagond.
^ permalink raw reply
* Re: [PATCH] ipv6 addrconf: Fix addrconf_ifid_eui64 of 802.15.4 devices
From: Alexander Aring @ 2013-03-08 8:53 UTC (permalink / raw)
To: David Miller
Cc: eric.dumazet, bhutchings, kuznet, jmorris, yoshfuji,
linux-zigbee-devel, netdev
In-Reply-To: <20130307.181751.2267151221127000913.davem@davemloft.net>
On Thu, Mar 07, 2013 at 06:17:51PM -0500, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 07 Mar 2013 14:57:05 -0800
>
> > On Thu, 2013-03-07 at 22:41 +0000, Ben Hutchings wrote:
> >> On Thu, 2013-03-07 at 21:13 +0100, Alexander Aring wrote:
> >> > The function addrconf_ifid_eui64 will copy eui into dev->dev_addr.
> >> > We need first to manipulate eui[0] before we call memcpy afterwards.
> >>
> >> memcpy() does not work that way.
> >>
> >> > Broken since commit:
> >> > 5e98a36ed4bf6ea396170e3af0dd4fcbe51d772f
> >> >
> >> > Since this commit I got many trouble with the ieee802154 stack.
> >>
> >> Your change is effectively reverting that commit.
> >
> > Reverting the commit seems the solution ;)
>
> So Yoshifuji HIDEAKI and Alexander need to work out what is happening
> here.
Ok, I will try that. Maybe somebody with a another 802.15.4 device with
6lowpan on linux-zigbee-devel mailinglist can confirm that?
I have a at86rf231 device.
Alex
^ permalink raw reply
* Re: [PATCH] ipv6 addrconf: Fix addrconf_ifid_eui64 of 802.15.4 devices
From: Alexander Aring @ 2013-03-08 9:04 UTC (permalink / raw)
To: Ben Hutchings
Cc: yoshfuji-VfPWfsRibaP+Ru+s062T9g, netdev-u79uwXL29TY76Z2rM5mHXA,
jmorris-gx6/JNMH7DfYtjvyW6yDsg,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
kuznet-v/Mj1YrvjDBInbfyfbPRSQ, davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <1362696088.2936.47.camel-/LGg1Z1CJKReKY3V0RtoKmatzQS1i7+A3tAM5lWOD0I@public.gmane.org>
On Thu, Mar 07, 2013 at 10:41:28PM +0000, Ben Hutchings wrote:
> On Thu, 2013-03-07 at 21:13 +0100, Alexander Aring wrote:
> > The function addrconf_ifid_eui64 will copy eui into dev->dev_addr.
> > We need first to manipulate eui[0] before we call memcpy afterwards.
>
> memcpy() does not work that way.
>
oh yeah, sry. It was too late yesterday. Change dest and src address of a common
function, sry. :-)
Alex
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
^ permalink raw reply
* be2net failed to initialize regression
From: CAI Qian @ 2013-03-08 9:05 UTC (permalink / raw)
To: netdev; +Cc: Ivan Vecera, LKML
Emulex CNA card failed to initialize using 3.8 and the latest upstream kernel,
[ 87.479859] be2net 0000:04:00.0: POST timeout; stage=0xc911
[ 87.515978] be2net 0000:04:00.0: Emulex OneConnect initialization failed
[ 87.557130] be2net: probe of 0000:04:00.0 failed with error -1
lspci output,
04:00.0 Ethernet controller: Emulex Corporation OneConnect 10Gb NIC (rev 02)
04:00.1 Ethernet controller: Emulex Corporation OneConnect 10Gb NIC (rev 02)
04:00.1 Ethernet controller: Emulex Corporation OneConnect 10Gb NIC (rev 02)
Subsystem: Hewlett-Packard Company NC551i Dual Port FlexFabric 10Gb Adapter
Confirmed no such problem using 3.7 kernel. Reproduced every time and still
bisecting. Just want to give an early head-up to see if anyone saw sometime
obvious.
CAI Qian
^ permalink raw reply
* Re: [PATCH] ipv6 addrconf: Fix addrconf_ifid_eui64 of 802.15.4 devices
From: Alexander Aring @ 2013-03-08 9:37 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: davem, kuznet, jmorris, linux-zigbee-devel, netdev
In-Reply-To: <51394B32.9090807@linux-ipv6.org>
Hi,
On Fri, Mar 08, 2013 at 11:21:38AM +0900, YOSHIFUJI Hideaki wrote:
> Hi,
>
> Alexander Aring wrote:
> > Hi,
> >
> > I don't know if this is a right solution for that, because other
> > functions like addrconf_ifid_infiniband to manipulate eui after memcpy,
> > too.
> >
> > But this patch solves my problems with ieee802154 stack.
>
> What kind of problems do you have?
>
I compile with #define DEBUG enabled in net/ieee802154/6lowpan.c
The problem is the address compression in 6lowpan.
First device has address fe80::a000:0:0:1/64. Second device has address
fe80::a000:0:0:2/64. I use only a ping6 to check connection.
Debug Information on the receiving side:
Without your patch which is working.
iphc0 = 7a, iphc1 = 11
NH flag is set, next header carried inline: 3a
source address stateless compression
(lowpan_uncompress_addr) linklocal address:
a0 00 00 00 00 00 00 02
uncompressing 2 + 8 =>
fe 80 00 00 00 00 00 00 a0 00 00 00 00 00 00 02
dest: stateless compression
(lowpan_uncompress_addr) linklocal address:
a0 00 00 00 00 00 00 01
uncompressing 2 + 8 =>
fe 80 00 00 00 00 00 00 a0 00 00 00 00 00 00 01
skb headroom size = 40, data length = 64
IPv6 header dump:
version = 6
length = 64
nexthdr = 0x3a
hop_lim = 64
With your patch, which isn't working anymore:
iphc0 = 7b, iphc1 = 3b
NH flag is set, next header carried inline: 3a
source address stateless compression
(lowpan_uncompress_addr) linklocal address:
02 85 00 3a 20 00 00 00
uncompressing 2 + 0 =>
fe 80 00 00 00 00 00 00 00 85 00 3a 20 00 00 00
dest: non context-based mcast compression
uncompressing 2 + 1 =>
ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 02
skb headroom size = 25, data length = 24
IPv6 header dump:
version = 6
length = 24
nexthdr = 0x3a
hop_lim = 255
And for every ipv6 packet I got:
ICMPv6 checksum failed [fe80:0000:0000:0000:0001:ff00:0001:8700 > ff02:0000:0000:0000:0000:0001:ff00:0001]
I seems that the reconstructed destination address and header length are
not right.
I will try to figure out this problem. Hope this information helps you to
know more about my problems.
Regards
Alex
^ permalink raw reply
* Re: [PATCH v2 4/6] ARM: davinci: da850: add DT node for eth0.
From: Prabhakar Lad @ 2013-03-08 9:45 UTC (permalink / raw)
To: Sekhar Nori
Cc: linux-arm-kernel, davinci-linux-open-source, linux-kernel, netdev,
devicetree-discuss, Heiko Schocher, Lad, Prabhakar
In-Reply-To: <510FF4C8.7000706@ti.com>
Sekhar,
On Mon, Feb 4, 2013 at 11:20 PM, Sekhar Nori <nsekhar@ti.com> wrote:
> On 2/4/2013 10:37 AM, Prabhakar Lad wrote:
>> Sekhar ,
>>
>> On Sun, Feb 3, 2013 at 5:33 PM, Sekhar Nori <nsekhar@ti.com> wrote:
>>> On 1/28/2013 7:17 PM, Prabhakar Lad wrote:
>>>> From: Lad, Prabhakar <prabhakar.lad@ti.com>
>>>>
>>>> Add eth0 device tree node information and pinmux for mii to da850 by
>>>> providing interrupt details and local mac address of eth0.
>>>>
>>>> Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
>>>> Cc: linux-arm-kernel@lists.infradead.org
>>>> Cc: linux-kernel@vger.kernel.org
>>>> Cc: davinci-linux-open-source@linux.davincidsp.com
>>>> Cc: netdev@vger.kernel.org
>>>> Cc: devicetree-discuss@lists.ozlabs.org
>>>> Cc: Sekhar Nori <nsekhar@ti.com>
>>>> Cc: Heiko Schocher <hs@denx.de>
>>>> ---
>>>> arch/arm/boot/dts/da850-evm.dts | 5 +++++
>>>> arch/arm/boot/dts/da850.dtsi | 35 +++++++++++++++++++++++++++++++++++
>>>> 2 files changed, 40 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
>>>> index a319491..19aa2b3 100644
>>>> --- a/arch/arm/boot/dts/da850-evm.dts
>>>> +++ b/arch/arm/boot/dts/da850-evm.dts
>>>> @@ -30,6 +30,11 @@
>>>> mdio: davinci_mdio@1e24000 {
>>>> status = "okay";
>>>> };
>>>> + eth0: emac@1e20000 {
>>>> + status = "okay";
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&mii_pins>;
>>>> + };
>>>> };
>>>> nand_cs3@62000000 {
>>>> status = "okay";
>>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>>> index ba28f2d..76905f3 100644
>>>> --- a/arch/arm/boot/dts/da850.dtsi
>>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>>> @@ -56,6 +56,26 @@
>>>> 0x30 0x01100000 0x0ff00000
>>>> >;
>>>> };
>>>> + mii_pins: pinmux_mii_pins {
>>>> + pinctrl-single,bits = <
>>>> + /*
>>>> + * MII_TXEN, MII_TXCLK, MII_COL
>>>> + * MII_TXD_3, MII_TXD_2, MII_TXD_1
>>>> + * MII_TXD_0
>>>> + */
>>>> + 0x8 0x88888880 0xfffffff0
>>>> + /*
>>>> + * MII_RXER, MII_CRS, MII_RXCLK
>>>> + * MII_RXDV, MII_RXD_3, MII_RXD_2
>>>> + * MII_RXD_1, MII_RXD_0
>>>> + */
>>>> + 0xc 0x88888888 0xffffffff
>>>> + /* MDIO_CLK, MDIO_D */
>>>
>>> You call this mii_pins, but include mdio pins in there as well. Can you
>>> separate them out? Then some board which uses rmii can simply reuse the
>>> entry.
>>>
>> Ok makes sense.
>>
>>>> + 0x10 0x00222288 0x00ffffff
>>>> + /* GPIO2_6 */
>>>> + 0x18 0x00000080 0x000000f0
>>>
>>> This is SoC specific pin list. Such board specific pins should not make
>>> it here.
>>>
>> Ok, so this should be set up using GPIO API's ?
>
> Yes, the pins ultimately will be controlled by gpiolib APIs, but the
> pins should be defined under the eth node in .dts
>
You mean '0x18 0x00000080 0x000000f0' still needs to defined in eth0 node ?
Can you elaborate and give some pointers.
Regards,
--Prabhakar
> Thanks,
> Sekhar
^ permalink raw reply
* Re: [PATCH v2 4/6] ARM: davinci: da850: add DT node for eth0.
From: Sekhar Nori @ 2013-03-08 9:51 UTC (permalink / raw)
To: Prabhakar Lad
Cc: davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Lad, Prabhakar,
Heiko Schocher, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <CA+V-a8tSjF0Zz53_v=d-hUdKK4ihK_aLceOYnmQFhhKLOx3y1g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 3/8/2013 3:15 PM, Prabhakar Lad wrote:
> Sekhar,
>
> On Mon, Feb 4, 2013 at 11:20 PM, Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org> wrote:
>> On 2/4/2013 10:37 AM, Prabhakar Lad wrote:
>>> Sekhar ,
>>>
>>> On Sun, Feb 3, 2013 at 5:33 PM, Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org> wrote:
>>>> On 1/28/2013 7:17 PM, Prabhakar Lad wrote:
>>>>> From: Lad, Prabhakar <prabhakar.lad-l0cyMroinI0@public.gmane.org>
>>>>>
>>>>> Add eth0 device tree node information and pinmux for mii to da850 by
>>>>> providing interrupt details and local mac address of eth0.
>>>>>
>>>>> Signed-off-by: Lad, Prabhakar <prabhakar.lad-l0cyMroinI0@public.gmane.org>
>>>>> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>>>>> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>>> Cc: davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org
>>>>> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>>> Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
>>>>> Cc: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
>>>>> Cc: Heiko Schocher <hs-ynQEQJNshbs@public.gmane.org>
>>>>> ---
>>>>> arch/arm/boot/dts/da850-evm.dts | 5 +++++
>>>>> arch/arm/boot/dts/da850.dtsi | 35 +++++++++++++++++++++++++++++++++++
>>>>> 2 files changed, 40 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
>>>>> index a319491..19aa2b3 100644
>>>>> --- a/arch/arm/boot/dts/da850-evm.dts
>>>>> +++ b/arch/arm/boot/dts/da850-evm.dts
>>>>> @@ -30,6 +30,11 @@
>>>>> mdio: davinci_mdio@1e24000 {
>>>>> status = "okay";
>>>>> };
>>>>> + eth0: emac@1e20000 {
>>>>> + status = "okay";
>>>>> + pinctrl-names = "default";
>>>>> + pinctrl-0 = <&mii_pins>;
>>>>> + };
>>>>> };
>>>>> nand_cs3@62000000 {
>>>>> status = "okay";
>>>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>>>> index ba28f2d..76905f3 100644
>>>>> --- a/arch/arm/boot/dts/da850.dtsi
>>>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>>>> @@ -56,6 +56,26 @@
>>>>> 0x30 0x01100000 0x0ff00000
>>>>> >;
>>>>> };
>>>>> + mii_pins: pinmux_mii_pins {
>>>>> + pinctrl-single,bits = <
>>>>> + /*
>>>>> + * MII_TXEN, MII_TXCLK, MII_COL
>>>>> + * MII_TXD_3, MII_TXD_2, MII_TXD_1
>>>>> + * MII_TXD_0
>>>>> + */
>>>>> + 0x8 0x88888880 0xfffffff0
>>>>> + /*
>>>>> + * MII_RXER, MII_CRS, MII_RXCLK
>>>>> + * MII_RXDV, MII_RXD_3, MII_RXD_2
>>>>> + * MII_RXD_1, MII_RXD_0
>>>>> + */
>>>>> + 0xc 0x88888888 0xffffffff
>>>>> + /* MDIO_CLK, MDIO_D */
>>>>
>>>> You call this mii_pins, but include mdio pins in there as well. Can you
>>>> separate them out? Then some board which uses rmii can simply reuse the
>>>> entry.
>>>>
>>> Ok makes sense.
>>>
>>>>> + 0x10 0x00222288 0x00ffffff
>>>>> + /* GPIO2_6 */
>>>>> + 0x18 0x00000080 0x000000f0
>>>>
>>>> This is SoC specific pin list. Such board specific pins should not make
>>>> it here.
>>>>
>>> Ok, so this should be set up using GPIO API's ?
>>
>> Yes, the pins ultimately will be controlled by gpiolib APIs, but the
>> pins should be defined under the eth node in .dts
>>
> You mean '0x18 0x00000080 0x000000f0' still needs to defined in eth0 node ?
> Can you elaborate and give some pointers.
Since the GPIO usage for ethernet is board specific, it cannot be in
.dtsi which is SoC generic. I am suggesting do in the .dts file which is
board specific.
Thanks,
Sekhar
^ permalink raw reply
* [net-next 00/15][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2013-03-08 10:07 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, sassmann
This series contains updates to ixgbevf and e1000e.
Alex's ixgbevf patch is meant to address several race issues that become
possible because next_to_watch could possibly be set to a value that shows
that the descriptor is done when it is not. In order to correct that we
instead make next_to_watch a pointer that is set to NULL during cleanup,
and set to the eop_desc after the descriptor rings have been written.
Stephen's ixgbevf patch makes the PCI id table a const and reformats the
table to match what the ixgbe driver does.
The remaining 13 patches from Bruce are cleanup patches for e1000e to
resolve checkpatch.pl warnings/errors, removing blank lines where
necessary and fix code formatting.
The following are changes since commit 7f0e44ac9f7f12a2519bfed9ea4df3c1471bd8bb:
ipv6 flowlabel: add __rcu annotations
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Alexander Duyck (1):
ixgbevf: Make next_to_watch a pointer and adjust memory barriers to
avoid races
Bruce Allan (13):
e1000e: cleanup CODE_INDENT checkpatch errors
e1000e: cleanup SPACING checkpatch errors and warnings
e1000e: cleanup LONG_LINE checkpatch warnings
e1000e: cleanup LEADING_SPACE checkpatch warnings
e1000e: cleanup PARENTHESIS_ALIGNMENT checkpatch checks
e1000e: cleanup SPACING checkpatch checks
e1000e: cleanup (add/remove) blank lines where appropriate
e1000e: cleanup unusually placed comments
e1000e: cleanup formatting of static structs
e1000e: cleanup unnecessary line breaks
e1000e: cleanup USLEEP_RANGE checkpatch checks
e1000e: cleanup format of struct e1000_opt_list struct
e1000e: cleanup - move defines to appropriate header file
Stephen Hemminger (1):
ixgbevf: use PCI_DEVICE_TABLE macro
drivers/net/ethernet/intel/e1000e/80003es2lan.c | 131 ++++++-----
drivers/net/ethernet/intel/e1000e/82571.c | 38 ++-
drivers/net/ethernet/intel/e1000e/82571.h | 2 +
drivers/net/ethernet/intel/e1000e/defines.h | 25 +-
drivers/net/ethernet/intel/e1000e/e1000.h | 18 +-
drivers/net/ethernet/intel/e1000e/ethtool.c | 177 +++++++-------
drivers/net/ethernet/intel/e1000e/hw.h | 4 +-
drivers/net/ethernet/intel/e1000e/ich8lan.c | 195 ++++++++--------
drivers/net/ethernet/intel/e1000e/mac.c | 10 +-
drivers/net/ethernet/intel/e1000e/netdev.c | 269 ++++++++++------------
drivers/net/ethernet/intel/e1000e/nvm.c | 2 +-
drivers/net/ethernet/intel/e1000e/param.c | 62 +++--
drivers/net/ethernet/intel/e1000e/phy.c | 130 +++++------
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 2 +-
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 80 ++++---
15 files changed, 574 insertions(+), 571 deletions(-)
--
1.7.11.7
^ 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