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
Hello.
On 04/14/2015 01:38 AM, Florian Fainelli wrote:
[snip]
+struct ravb_private {
+ struct net_device *ndev;
+ struct platform_device *pdev;
+ void __iomem *addr;
+ struct mdiobb_ctrl mdiobb;
+ u32 num_rx_ring[NUM_RX_QUEUE];
+ u32 num_tx_ring[NUM_TX_QUE
From: Lino Sanfilippo
> On 14.04.2015 00:07, Sergei Shtylyov wrote:
>
...
> > +#ifdef __LITTLE_ENDIAN
> > + u32 res: 16;/* Reserved bits */
> > + u32 ts_sh: 16; /* Timestamp high */
> > +#else
> > + u32 ts_sh: 16; /* Timestamp high */
> > + u32 res: 16;/* Reserved bits */
> > +#e
Hi,
On 14.04.2015 00:07, Sergei Shtylyov 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: enabl
On 13/04/15 15:07, Sergei Shtylyov wrote:
[snip]
> +struct ravb_private {
> + struct net_device *ndev;
> + struct platform_device *pdev;
> + void __iomem *addr;
> + struct mdiobb_ctrl mdiobb;
> + u32 num_rx_ring[NUM_RX_QUEUE];
> + u32 num_tx_ring[NUM_TX_QUEUE];
> + u32
Ethernet AVB includes an Gigabit Ethernet controller (E-MAC) that is basically
compatible with SuperH Gigabit Ethernet E-MAC). Ethernet AVB has a dedicated
direct memory access controller (AVB-DMAC) that is a new design compared to the
SuperH E-DMAC. The AVB-DMAC is compliant with 3 standards form
25 matches
Mail list logo
