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
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 b
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
ravb_a
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
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
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);
>>> +
>>>
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 arbitrary
From: Sergei Shtylyov
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 of the start of the TX
frame when D
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.
From: Sergei Shtylyov
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?
>>> Probably need to print
From: Sergei Shtylyov
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 something?
>>> Probably ne
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 w
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
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...
NET_IP_ALIGN is for receive, not tran
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);
+
From: MITSUHIRO KIMURA
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");
>> >> + netif_stop_queue(n
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, fla
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.
>
>
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: e
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
20 matches
Mail list logo
