On Fri, 2015-04-24 at 21:53 +0300, Sergei Shtylyov wrote:
On 04/23/2015 02:22 AM, Florian Fainelli wrote:
[...]
+if (ecmd-duplex == DUPLEX_FULL)
+priv-duplex = 1;
+else
+priv-duplex = 0;
Why not use what priv-phydev-duplex has cached for you?
From: Sergei Shtylyov
Sent: 24 April 2015 19:27
...
If you have ethernet hardware that requires tx or rx buffers to be on
4n boundaries you should send it back as 'not fit for purpose'.
The RX buffers can be adjusted with skb_resrerve(), it's only the TX
buffers that need to be
From: Sergei Shtylyov
Sent: 22 April 2015 22:39
On 04/22/2015 11:42 PM, David Miller wrote:
Hmm, I've been digging in the net core, and was unable to see where TX
skb's get their NET_IP_ALIGN bytes reserved. Have I missed something?
Probably need to print out skb's fields...
On 04/24/2015 12:03 PM, David Laight wrote:
Sent: 22 April 2015 22:39
On 04/22/2015 11:42 PM, David Miller wrote:
Hmm, I've been digging in the net core, and was unable to see where TX
skb's get their NET_IP_ALIGN bytes reserved. Have I missed something?
Probably need to print
On 04/23/2015 02:22 AM, Florian Fainelli wrote:
[...]
+if (ecmd-duplex == DUPLEX_FULL)
+priv-duplex = 1;
+else
+priv-duplex = 0;
Why not use what priv-phydev-duplex has cached for you?
Because we compare 'priv-duplex' with 'priv-phydev-duplex' in
From: MITSUHIRO KIMURA mitsuhiro.kimura...@renesas.com
Date: Wed, 22 Apr 2015 05:04:13 +
Hello Sergei.
(2015/04/15 6:37:28), Sergei Shtylyov wrote:
+ if (!ravb_tx_free(ndev, q)) {
+ netif_warn(priv, tx_queued, ndev, TX FD exhausted.\n);
+
From: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Date: Thu, 23 Apr 2015 00:38:56 +0300
On 04/22/2015 11:42 PM, David Miller wrote:
Hmm, I've been digging in the net core, and was unable to see where TX
skb's get their NET_IP_ALIGN bytes reserved. Have I missed something?
From: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Date: Thu, 23 Apr 2015 01:34:32 +0300
Sigh... I'm seeing no way out of that then, only copying. :-(
What exactly is the device's restriction?
Any reasonable modern chip allows one of two things.
Either it allows arbitrary alignment
Hello.
On 04/22/2015 11:42 PM, David Miller wrote:
Hmm, I've been digging in the net core, and was unable to see where TX
skb's get their NET_IP_ALIGN bytes reserved. Have I missed something?
Probably need to print out skb's fields...
NET_IP_ALIGN is for receive, not transmit.
From: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Date: Wed, 22 Apr 2015 23:46:52 +0300
Hello.
On 04/22/2015 11:42 PM, David Miller wrote:
Hmm, I've been digging in the net core, and was unable to see where TX
skb's get their NET_IP_ALIGN bytes reserved. Have I missed
On 04/23/2015 01:41 AM, David Miller wrote:
Sigh... I'm seeing no way out of that then, only copying. :-(
What exactly is the device's restriction?
The frame data must be aligned on 32-bit boundary.
Any reasonable modern chip allows one of two things.
Either it allows
From: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Date: Wed, 22 Apr 2015 23:30:02 +0300
Hmm, I've been digging in the net core, and was unable to see where TX
skb's get their NET_IP_ALIGN bytes reserved. Have I missed something?
Probably need to print out skb's fields...
On 04/22/2015 11:42 PM, David Miller wrote:
Hmm, I've been digging in the net core, and was unable to see where TX
skb's get their NET_IP_ALIGN bytes reserved. Have I missed something?
Probably need to print out skb's fields...
NET_IP_ALIGN is for receive, not transmit.
But
On 04/23/2015 01:18 AM, David Miller wrote:
Hmm, I've been digging in the net core, and was unable to see where TX
skb's get their NET_IP_ALIGN bytes reserved. Have I missed something?
Probably need to print out skb's fields...
NET_IP_ALIGN is for receive, not transmit.
On 14/04/15 14:37, Sergei Shtylyov wrote:
+/* Wait for stopping the hardware TX process */
+ravb_wait(ndev, TCCR, TCCR_TSRQ0 | TCCR_TSRQ1 | TCCR_TSRQ2 |
TCCR_TSRQ3,
+ 0);
+
+ravb_wait(ndev, CSR, CSR_TPO0 | CSR_TPO1 | CSR_TPO2 | CSR_TPO3, 0);
+
+/* Stop the
Hello.
On 04/22/2015 06:36 PM, David Miller wrote:
+ if (!ravb_tx_free(ndev, q)) {
+ netif_warn(priv, tx_queued, ndev, TX FD exhausted.\n);
+ netif_stop_queue(ndev);
+ spin_unlock_irqrestore(priv-lock, flags);
+
Hello Sergei.
(2015/04/15 6:37:28), Sergei Shtylyov wrote:
+ if (!ravb_tx_free(ndev, q)) {
+ netif_warn(priv, tx_queued, ndev, TX FD exhausted.\n);
+ netif_stop_queue(ndev);
+ spin_unlock_irqrestore(priv-lock, flags);
+
On Tue, Apr 14, 2015 at 01:07:38AM +0300, Sergei Shtylyov wrote:
+static int ravb_wait(struct net_device *ndev, u16 reg, u32 mask, u32 value)
+{
+ int i;
+
+ for (i = 0; i 1; i++) {
+ if ((ravb_read(ndev, reg) mask) == value)
+ return 0;
+
Hello.
On 04/14/2015 03:49 AM, Lino Sanfilippo wrote:
+struct ravb_desc {
+#ifdef __LITTLE_ENDIAN
+ u32 ds: 12; /* Descriptor size */
+ u32 cc: 12; /* Content control */
+ u32 die: 4; /* Descriptor interrupt enable */
+ /* 0: disable, other:
Hi,
On 20.04.2015 00:10, Sergei Shtylyov wrote:
I recall a thread in which the use of bitfields for structs that are
shared with the hardware was considered a bad idea (because the compiler
is free to reorder the fields). Shift operations are probably a better
choice here.
Well, it
20 matches
Mail list logo
