Mason <slash@free.fr> writes:
> On 11/12/2017 15:36, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> I suppose I should test forcefully setting the enable bit to 0 in
>>> the driver, and see if hell breaks loose.
>>
>> You can
>> in the Receive Status Register is set to "1".
>
> I don't see how sending "fake" packets through the loop back would be
> considered "resetting the DMA enable in the middle of a DMA".
> (I'm afraid the HW dev didn't grasp what the driver is doing.)
>
> I suppose I should test forcefully setting the enable bit to 0 in
> the driver, and see if hell breaks loose.
You can't. When the enable bit is 1, writes to that register are
ignored. It goes back to 0 automatically when the hw runs out of
descriptors.
--
Måns Rullgård
l my patches are NACKed, what would you have me do?
>
> Moreover, mainline still has the nb8800_dma_stop() work-around,
> which Mans has never seen hang.
Here's the thing, if that trick doesn't work, then the dma queue filling
up from real traffic will also hang the controller, which is a much
bigger problem. Your test today suggests that this might be the case.
--
Måns Rullgård
Marc Gonzalez <marc_gonza...@sigmadesigns.com> writes:
> On 14/11/2017 17:55, Måns Rullgård wrote:
>
>> Marc Gonzalez wrote:
>>
>>> I will run iperf3 tests with RX_DESC_COUNT lowered to 2.
>>> Would that produce conclusive results?
>>> Do you
Marc Gonzalez <marc_gonza...@sigmadesigns.com> writes:
> On 14/11/2017 14:54, Måns Rullgård wrote:
>
>> Marc Gonzalez writes:
>>
>>> On 14/11/2017 13:40, Måns Rullgård wrote:
>>>
>>>> Marc Gonzalez wrote:
>>>>
>>&g
Marc Gonzalez <marc_gonza...@sigmadesigns.com> writes:
> On 14/11/2017 13:40, Måns Rullgård wrote:
>
>> Marc Gonzalez wrote:
>>
>>> Power entire ethernet block down in ndo_stop().
>>> Power it back up in ndo_open() and perform HW init.
>>> De
Marc Gonzalez <marc_gonza...@sigmadesigns.com> writes:
> On 14/11/2017 13:38, Måns Rullgård wrote:
>
>> Marc Gonzalez writes:
>>
>>> The "flow control enable" bit can be tweaked, even if DMA is enabled.
>>
>> No, it can't. Maybe on some o
Marc Gonzalez <marc_gonza...@sigmadesigns.com> writes:
> On 14/11/2017 13:37, Måns Rullgård wrote:
>
>> Marc Gonzalez writes:
>>
>>> According to our HW dev, there is no provision for software to safely
>>> disable RX DMA in the AU-
;,
> @@ -1444,6 +1464,8 @@ static struct platform_driver nb8800_driver = {
> },
> .probe = nb8800_probe,
> .remove = nb8800_remove,
> + .suspend = nb8800_suspend,
> + .resume = nb8800_resume,
> };
>
> module_platform_driver(nb8800_driver);
> --
> 2.15.0
>
--
Måns Rullgård
nb8800_modl(priv, NB8800_RXC_CR, RCR_FL, priv->pause_tx);
> - nb8800_start_rx(dev);
> - netif_tx_unlock_bh(dev);
> - napi_enable(>napi);
> - } else {
> - nb8800_modl(priv, NB8800_RXC_CR, RCR_FL, priv->pause
+ /* Auto-negotiate by default */
> + priv->pause_aneg = true;
> + priv->pause_rx = true;
> + priv->pause_tx = true;
> +
> + priv->ops = match->data;
> + priv->ops->power_down(dev);
> +
> return 0;
>
> -err_free_dma:
> - nb8800_dma_free(dev);
> err_deregister_fixed_link:
> if (of_phy_is_fixed_link(pdev->dev.of_node))
> of_phy_deregister_fixed_link(pdev->dev.of_node);
> diff --git a/drivers/net/ethernet/aurora/nb8800.h
> b/drivers/net/ethernet/aurora/nb8800.h
> index 6ec4a956e1e5..23fefca54804 100644
> --- a/drivers/net/ethernet/aurora/nb8800.h
> +++ b/drivers/net/ethernet/aurora/nb8800.h
> @@ -305,11 +305,13 @@ struct nb8800_priv {
> dma_addr_t tx_desc_dma;
>
> struct clk *clk;
> + const struct nb8800_ops *ops;
> };
>
> struct nb8800_ops {
> int (*init)(struct net_device *dev);
> - int (*reset)(struct net_device *dev);
> + void(*power_down)(struct net_device *dev);
> + void(*power_up)(struct net_device *dev);
> };
>
> #endif /* _NB8800_H_ */
> --
> 2.15.0
>
--
Måns Rullgård
t; - .compatible = "aurora,nb8800",
> - },
> {
> .compatible = "sigma,smp8642-ethernet",
> .data = _tangox_ops,
> --
Please leave this. It works just fine on tango3.
--
Måns Rullgård
eck causing packet loss could be somewhere
else.
--
Måns Rullgård
Transfer Bandwidth Total Datagrams
>> [ 4] 0.00-1.00 sec 102 MBytes 858 Mbits/sec 13091
>> [ 4] 1.00-2.00 sec 114 MBytes 953 Mbits/sec 14541
>
> 114 MB in 14541 packets => 7840 bytes per packet
> Is iperf3 sending jumbo frames??
It's probably sending fragmented packets.
--
Måns Rullgård
Mason <slash@free.fr> writes:
> On 02/08/2017 18:10, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> On 02/08/2017 17:56, Måns Rullgård wrote:
>>>
>>>> What does the tango5 do if you flood it with packets faster than the
>>>>
Mason <slash@free.fr> writes:
> On 02/08/2017 17:56, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> From my perspective, the older method does not work on newer chips :-)
>>
>> It does work on tango4.
>
> Agreed.
>
>> What
Mason <slash@free.fr> writes:
> On 02/08/2017 17:36, Måns Rullgård wrote:
>
>> Mason wrote:
>>
>>> Looking at the tango-specific integration, I note this nugget:
>>>
>>> 1.5.4 Stopping & Starting the DMA
>>>
>>> This f
in the FIFO was an UDP packet, when clearing dma_stop,
> this packet will directly start being written in the DRAM since UDP
> packets are not controlled by the descriptor mechanism);
> 2- Program a new chain of descriptor;
> 3- Re-enable DMA (rx_ctrl register)
>
> rx_dma_stop:
> Software control to stop the Rx DMA.
> A write to this bit with “1” will gracefully stop the Rx DMA by after
> transferring the current packet. If more packets are pending they will
> be held until the software clears this bit.
>
> Hmmm, what do you think? This looks promising...
This is only available in the more recent Sigma versions. Although it
is nicer, I didn't think it was worth the trouble to support both
methods since the older method should work on all chips.
--
Måns Rullgård
Mason <slash@free.fr> writes:
> On 02/08/2017 13:02, Måns Rullgård wrote:
>
>> Mason wrote:
>>
>>> Move all HW initializations to nb8800_init.
>>> This provides the basis for suspend/resume support.
>>>
nb8800_probe(struct platform_device *pdev)
>
> return 0;
>
> -err_free_dma:
> - nb8800_dma_free(dev);
> err_deregister_fixed_link:
> if (of_phy_is_fixed_link(pdev->dev.of_node))
> of_phy_deregister_fixed_link(pdev->dev.of_node);
> diff --git a/drivers/net/ethernet/aurora/nb8800.h
> b/drivers/net/ethernet/aurora/nb8800.h
> index 6ec4a956e1e5..d5f4481a2c7b 100644
> --- a/drivers/net/ethernet/aurora/nb8800.h
> +++ b/drivers/net/ethernet/aurora/nb8800.h
> @@ -305,6 +305,7 @@ struct nb8800_priv {
> dma_addr_t tx_desc_dma;
>
> struct clk *clk;
> + const struct nb8800_ops *ops;
> };
>
> struct nb8800_ops {
> --
> 2.11.0
--
Måns Rullgård
ue of
three descriptors that are pre-loaded from memory. Your hardware people
should be able to confirm this.
> With my changes, I get *exactly* the same logs on BOARD A
> and BOARD B (modulo the descriptors addresses).
>
> Yet BOARD A stays functional, but BOARD B is hosed...
What's the difference between board A and board B?
> Depressing. I've run out of ideas.
Get your hardware people involved. Perhaps they can run some test in a
simulator.
--
Måns Rullgård
Mason <slash@free.fr> writes:
> On 31/07/2017 13:59, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> On 29/07/2017 17:18, Florian Fainelli wrote:
>>>
>>>> On 07/29/2017 05:02 AM, Mason wrote:
>>>>
>>>>>
ock, and everything will work as expected."
Nobody is saying a reset won't recover the lockup. The problem is that
we don't know what caused it to lock up in the first place. How do we
know it can't happen during normal operation? If we knew the cause, it
might also be possible to avoid the situation entirely.
--
Måns Rullgård
Mason <slash@free.fr> writes:
> On 29/07/2017 14:05, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> I'll take this opportunity to change flow control to
>>> off by default (it breaks several 100 Mbps switches).
>>
>> I was told to h
Mason <slash@free.fr> writes:
> On 29/07/2017 13:24, Måns Rullgård wrote:
>
>> Until you figure out why it's getting stuck, we can't be sure
>> it isn't caused by something that could trigger at any time.
> Would you take a look at it, if I can reproduce on tango4?
Mason <slash@free.fr> writes:
> On 28/07/2017 20:56, Måns Rullgård wrote:
>
>> Marc Gonzalez writes:
>>
>>> On 28/07/2017 18:17, Måns Rullgård wrote:
>>>
>>>> Marc Gonzalez wrote:
>>>>
>>>>> ndo_stop breaks RX
Marc Gonzalez <marc_gonza...@sigmadesigns.com> writes:
> On 28/07/2017 18:17, Måns Rullgård wrote:
>
>> Marc Gonzalez wrote:
>>
>>> ndo_stop breaks RX in a way that ndo_open is unable to undo.
>>
>> Please elaborate. Why can't it be fixed in a
0;
>
> -err_free_dma:
> - nb8800_dma_free(dev);
> err_deregister_fixed_link:
> if (of_phy_is_fixed_link(pdev->dev.of_node))
> of_phy_deregister_fixed_link(pdev->dev.of_node);
> diff --git a/drivers/net/ethernet/aurora/nb8800.h
> b/drivers/net/ethernet/aurora/nb8800.h
> index 6ec4a956e1e5..d5f4481a2c7b 100644
> --- a/drivers/net/ethernet/aurora/nb8800.h
> +++ b/drivers/net/ethernet/aurora/nb8800.h
> @@ -305,6 +305,7 @@ struct nb8800_priv {
> dma_addr_t tx_desc_dma;
>
> struct clk *clk;
> + const struct nb8800_ops *ops;
> };
>
> struct nb8800_ops {
> --
> 2.11.0
>
--
Måns Rullgård
Marc Gonzalez <marc_gonza...@sigmadesigns.com> writes:
> On 21/07/2017 15:47, Måns Rullgård wrote:
>
>> Marc Gonzalez wrote:
>>
>>> On 21/07/2017 15:04, Måns Rullgård wrote:
>>>
>>>> Marc Gonzalez wrote:
>>>>
Marc Gonzalez <marc_gonza...@sigmadesigns.com> writes:
> On 21/07/2017 15:04, Måns Rullgård wrote:
>
>> Marc Gonzalez wrote:
>>
>>> According to commit e5f3a4a56ce2a707b2fb8ce37e4414dcac89c672
>>> ("Documentation: devicetree: clarify usage of th
pad_mode = PAD_MODE_RGMII;
> break;
>
> default:
I still don't like this. Having both the MAC and PHY drivers react to
the phy-connection-type property is bound to cause trouble somewhere.
The only way out of the current mess is to define new properties for
both MAC and PHY that override the existing ones if present.
--
Måns Rullgård
mac_mode |= RGMII_MODE;
>
> mac_mode |= GMAC_MODE;
> --
> 2.11.0
>
--
Måns Rullgård
Mason <slash@free.fr> writes:
> I will look for an inter-packet gap knob and FCS error counter.
There is an FCS error counter. Use "ethtool -S" and look for
rx_bad_fcs_frames. Reading the stats counters automatically resets
them to zero.
--
Måns Rullgård
e only sane solution to this mess is to never configure the
MAC delay based on the existing phy-connection-type property. If some
board requires this delay (because the PHY can't do it), a new property
should probably be introduced for that.
--
Måns Rullgård
sed features that require a
specific driver. Interrupts, for example.
--
Måns Rullgård
David Laight <david.lai...@aculab.com> writes:
> From: Måns Rullgård
>> Sent: 10 December 2016 13:25
> ...
>> I solved this problem in an Ethernet driver by copying the initial part
>> of the packet to an aligned skb and appending the remainder using
>> sk
a one-bit field can indicate the presence of an extended
header yet to be defined. Then old software can still make sense of the
basic header.
--
Måns Rullgård
Felix Fietkau <n...@nbd.name> writes:
> On 2016-12-10 14:25, Måns Rullgård wrote:
>> Felix Fietkau <n...@nbd.name> writes:
>>
>>> On 2016-12-07 19:54, Jason A. Donenfeld wrote:
>>>> On Wed, Dec 7, 2016 at 7:51 PM, David Miller <da...@davemlo
aligned skb and appending the remainder using
skb_add_rx_frag(). The kernel network stack only cares about the
headers, so the alignment of the packet payload doesn't matter.
--
Måns Rullgård
gt; What I am trying to say is that once a PHY driver properly configures a
>> delay that you have specified, there is no reason why this is not
>> applicable to other platforms using this same PHY driver.
>
> As has been stated earlier it can depend on the track lengths on the
> board i
etween the MAC and the PHY.
> From your explanation it appears that the delay is to account for board
> routing (wires) between the PHY and the RJ45 socket.
The delay pertains to the RGMII link between MAC and PHY. The external
connection is self-clocking.
--
Måns Rullgård
Florian Fainelli <f.faine...@gmail.com> writes:
> On 11/14/2016 11:00 AM, Måns Rullgård wrote:
>> Florian Fainelli <f.faine...@gmail.com> writes:
>>
>>> On 11/14/2016 10:20 AM, Florian Fainelli wrote:
>>>> On 11/14/2016 09:59 AM, Sebastian Fr
ol tend to kick in under higher packet rates (at
>> least, that's what you expect).
>>
>>>
>>> Right now we know that Mason's patch makes this work, but we do not
>>> understand why nor its implications.
>>
>> You need to understand why, right now, the way this problem is
>> presented, you came up with a workaround, not with the root cause or the
>> solution. What does your link partner (switch?) reports, that is, what
>> is the ethtool output when you have a link up from your nb8800 adapter?
>
> Actually, nb8800_pause_config() seems to be doing a complete MAC/DMA
> reconfiguration when pause frames get auto-negotiated while the link is
> UP,
This is due to a silly hardware limitation. The register containing the
flow control bits can't be written while rx is enabled.
> and it does not differentiate being called from
> ethtool::set_pauseparam or the PHYLIB adjust_link callback (which it
> probably should),
Differentiate how?
> wondering if there is a not a remote chance you can get the reply to
> arrive right when you just got signaled a link UP?
If you're attempting to send or receive things before you get the link
up notification, you shouldn't expect anything to work reliably.
--
Måns Rullgård
Sebastian Frias <s...@laposte.net> writes:
> Hi Måns,
>
> On 11/05/2016 01:58 PM, Måns Rullgård wrote:
>>> if (gigabit) {
>>> - if (priv->phy_mode == PHY_INTERFACE_MODE_RGMII)
>>> + if (phy_interface_is_rgmii(phydev))
&
pad_mode = PAD_MODE_RGMII;
> - break;
> -
> + case PHY_INTERFACE_MODE_RGMII_ID:
> + case PHY_INTERFACE_MODE_RGMII_RXID:
> case PHY_INTERFACE_MODE_RGMII_TXID:
> pad_mode = PAD_MODE_RGMII;
> break;
> --
> 1.7.11.2
>
--
Måns Rullgård
gt; + case PHY_INTERFACE_MODE_RGMII_ID:
> + case PHY_INTERFACE_MODE_RGMII_RXID:
> case PHY_INTERFACE_MODE_RGMII_TXID:
> pad_mode = PAD_MODE_RGMII;
> break;
> --
> 1.7.11.2
>
--
Måns Rullgård
Florian Fainelli <f.faine...@gmail.com> writes:
> On 11/04/2016 08:22 AM, Måns Rullgård wrote:
>> Andrew Lunn <and...@lunn.ch> writes:
>>
>>> On Fri, Nov 04, 2016 at 03:05:00PM +, Måns Rullgård wrote:
>>>> Andrew Lunn <and...@lunn.ch
Florian Fainelli <f.faine...@gmail.com> writes:
> On 11/04/2016 08:36 AM, Sebastian Frias wrote:
>> Hi Måns,
>>
>> On 11/04/2016 04:18 PM, Måns Rullgård wrote:
>>> Sebastian Frias <s...@laposte.net> writes:
>>>
>>>> The delay
pad_mode = PAD_MODE_RGMII;
>> break;
>
> How many boards use this Ethernet driver? How many boards are your
> potentially breaking, because they need this delay?
>
> I guess it is a small number, because doesn't it require the PHY is
> also broken, not adding a delay when it should?
What if the PHY doesn't have that option?
--
Måns Rullgård
Andrew Lunn <and...@lunn.ch> writes:
> On Fri, Nov 04, 2016 at 03:05:00PM +0000, Måns Rullgård wrote:
>> Andrew Lunn <and...@lunn.ch> writes:
>>
>> >> > I agree with you. But fixing it is likely to break boards which
>> >> > currently h
s), that case
should be merged with the one above it and PHY_INTERFACE_MODE_RGMII_RXID
added as well.
--
Måns Rullgård
The delay can be applied at
either end or not at all, and it's anything but clear what the
properties are supposed to mean.
There is also no way to specify the amount of delay required even though
many devices support more than one value.
--
Måns Rullgård
d
>> when a DTB specifies "rgmii" or "rgmii-txid" ?
>
> I agree with you. But fixing it is likely to break boards which
> currently have "rgmii", but actually need the delay in order to work.
Does the internal delay here refer to the PHY or the MAC? It's a
property of the MAC node after all.
--
Måns Rullgård
nals. The delay can be
applied at the MAC or the PHY. I'd start by finding out what the PCB
design expects or check the signals with a fast oscilloscope if you have
one.
--
Måns Rullgård
onfigure, 0,
> priv->phy_mode);
> - if (!phydev)
> + if (!phydev) {
> + err = -ENODEV;
> goto err_free_irq;
> + }
>
> nb8800_pause_adv(dev);
>
--
Måns Rullgård
gt; index 453dc0967125..d5f2ad1a5a30 100644
> --- a/drivers/net/ethernet/aurora/nb8800.c
> +++ b/drivers/net/ethernet/aurora/nb8800.c
> @@ -1357,6 +1357,7 @@ static const struct of_device_id nb8800_dt_ids[] = {
> },
> { }
> };
> +MODULE_DEVICE_TABLE(of, nb8800_dt_ids);
>
> static int nb8800_probe(struct platform_device *pdev)
> {
> --
--
Måns Rullgård
if (ret)
> - goto err_free_dev;
> + goto err_disable_clk;
> }
>
> bus = devm_mdiobus_alloc(>dev);
>
--
Måns Rullgård
x buffer allocation failed\n");
> dev->stats.rx_dropped++;
> + dev_kfree_skb(skb);
> return;
> }
>
> --
> 2.7.4
>
--
Måns Rullgård
truct phy_device *phydev = dev->phydev;
>
> priv->pause_aneg = pp->autoneg;
> priv->pause_rx = pp->rx_pause;
> @@ -1088,8 +1089,8 @@ static int nb8800_set_pauseparam(struct net_device *dev,
>
> if (!priv->pause_aneg)
> nb8800_p
800_ethtool_ops = {
> .get_sset_count = nb8800_get_sset_count,
> .get_strings= nb8800_get_strings,
> .get_ethtool_stats = nb8800_get_ethtool_stats,
> + .get_link_ksettings = phy_ethtool_get_link_ksettings,
> + .set_link_ksettings = phy_ethtool_set_link_ksettings,
> };
>
> static int nb8800_hw_init(struct net_device *dev)
> --
> 1.7.4.4
>
--
Måns Rullgård
only to
> force a hardware-reset when the PHY is wedged by some random event.
Yes, and some variants of this phy are broken and require a hard reset
in certain situations. At least that's what the comment in the code
says.
--
Måns Rullgård
Sebastian Frias <s...@laposte.net> writes:
> On 02/08/2016 03:11 PM, Mason wrote:
>> On 08/02/2016 14:37, Måns Rullgård wrote:
>>
>>> Sebastian Frias wrote:
>>>
>>>> By the way, I know some people like the command line, email, etc. but
>>
he inlined comments were addressed.
Gerrit has some merits, but for seasoned developers it's largely a
nuisance. It's probably good at keeping junior/undisciplined developers
from doing too much damage by strictly enforcing a cumbersome process.
--
Måns Rullgård
Sebastian Frias <s...@laposte.net> writes:
> On 02/05/2016 04:26 PM, Måns Rullgård wrote:
>> Sebastian Frias <s...@laposte.net> writes:
>>
>>> On 02/05/2016 04:08 PM, Måns Rullgård wrote:
>>>> Sebastian Frias <s...@laposte.net> writes:
}
> + priv->phy_node = of_node_get(pdev->dev.of_node);
> + }
> +
> + if (!priv->phy_node)
> + priv->phy_node = of_parse_phandle(pdev->dev.of_node,
> + "phy-handle", 0);
> +
> if (!priv->phy_node) {
> dev_err(>dev, "no PHY specified\n");
> ret = -ENODEV;
> --
> 2.1.4
>
--
Måns Rullgård
Sebastian Frias <s...@laposte.net> writes:
> On 02/05/2016 04:08 PM, Måns Rullgård wrote:
>> Sebastian Frias <s...@laposte.net> writes:
>>
>>> On 02/05/2016 03:34 PM, Måns Rullgård wrote:
>>>> Sebastian Frias <s...@laposte.net> writes:
>&
Sebastian Frias <s...@laposte.net> writes:
> On 02/05/2016 03:34 PM, Måns Rullgård wrote:
>> Sebastian Frias <s...@laposte.net> writes:
>>
>>> Signed-off-by: Sebastian Frias <s...@laposte.net>
>>
>> Please change the subject to something like
Andy Shevchenko <andy.shevche...@gmail.com> writes:
> On Fri, Feb 5, 2016 at 3:39 PM, Måns Rullgård <m...@mansr.com> wrote:
>>> + if (ret < 0) {
>>> + dev_err(>dev, "broken fixed-link
>>>
"phy-handle", 0);
if (!priv->phy_node) {
dev_err(>dev, "no PHY specified\n");
ret = -ENODEV;
goto err_free_bus;
}
--
Måns Rullgård
Sebastian Frias <s...@laposte.net> writes:
> On 02/05/2016 02:58 PM, Måns Rullgård wrote:
>> Sebastian Frias <s...@laposte.net> writes:
>>
>>> Signed-off-by: Sebastian Frias <s...@laposte.net>
>>> ---
>>> drivers/net/ethernet/a
dev_err(>dev, "no PHY specified\n");
> + ret = -ENODEV;
> + goto err_free_bus;
> + }
> }
>
> priv->mii_bus = bus;
> --
> 2.1.4
>
--
Måns Rullgård
rxd->report = 0;
> last = next;
> work++;
> - }
> + } while (work < budget);
>
> if (work) {
> priv->rx_descs[last].desc.config |= DESC_EOC;
> --
> 2.7.0
>
--
Måns Rullgård
a/Kconfig
> index a3c7106fdf85e78f..8ba7f8ff3434000f 100644
> --- a/drivers/net/ethernet/aurora/Kconfig
> +++ b/drivers/net/ethernet/aurora/Kconfig
> @@ -13,6 +13,7 @@ if NET_VENDOR_AURORA
>
> config AURORA_NB8800
> tristate "Aurora AU-NB8800 support"
> + depends
Alexander Duyck <alexander.du...@gmail.com> writes:
> On Wed, Nov 25, 2015 at 5:04 AM, Måns Rullgård <m...@mansr.com> wrote:
>> Mason <slash@free.fr> writes:
>>
>>> On 25/11/2015 13:45, Måns Rullgård wrote:
>>>
>>>> M
Mason <slash@free.fr> writes:
> On 25/11/2015 17:16, Måns Rullgård wrote:
>
>> Alexander Duyck writes:
>>
>>> On Wed, Nov 25, 2015 at 5:04 AM, Måns Rullgård wrote:
>>>
>>>> Mason writes:
>>>>
>>>>> On 25/11/2
ge_testzero(page)))
> __free_pages_ok(page, compound_order(page));
> }
>
> Regards.
>
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Mason <slash@free.fr> writes:
> On 25/11/2015 13:45, Måns Rullgård wrote:
>
>> Mason wrote:
>>
>>> On 19/11/2015 14:02, Mans Rullgard wrote:
>>>
>>>> + if (dma_mapping_error(>dev, dma_addr)) {
>>>> + skb_free_f
David Miller <da...@davemloft.net> writes:
> From: Måns Rullgård <m...@mansr.com>
> Date: Mon, 16 Nov 2015 20:59:18 +
>
>> Anything else?
>
> Sorry, when I find one problem I give you the feedback for that
> and move on to the 100s of other patches I h
ly spell out "unsigned int" rather than use "unsigned"
> as a shorthand.
OK
Anything else?
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ted Documentation/CodingStyle to forbid taking the address
> of functions.
I can't find anything to that effect. That said, it's not something I
would normally do, but all the other phy_driver entries in that file
look like that.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this lis
Mason <slash@free.fr> writes:
> On 12/11/2015 20:14, Florian Fainelli wrote:
>> On 12/11/15 11:09, Måns Rullgård wrote:
>>> On 12 November 2015 19:06:23 GMT+00:00, Mason wrote:
>>>> On 12/11/2015 18:40, Mans Rullgard wrote:
>>>>>
Mason <slash@free.fr> writes:
> On 10/11/2015 20:25, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> On 10/11/2015 17:14, Mans Rullgard wrote:
>>>
>>>> This adds a driver for the Aurora VLSI NB8800 Ethernet controller.
>>>
Mason <slash@free.fr> writes:
> [ CCing a few knowledgeable people ]
>
> Despite the subject, this is about an Atheros 8035 PHY :-)
>
> On 12/11/2015 15:04, Måns Rullgård wrote:
>
>> Mason wrote:
>>
>>> BTW, you're not using the PHY IRQ, right
Måns Rullgård <m...@mansr.com> writes:
> Mason <slash@free.fr> writes:
>
>> [ CCing a few knowledgeable people ]
>>
>> Despite the subject, this is about an Atheros 8035 PHY :-)
>>
>> On 12/11/2015 15:04, Måns Rullgård wrote:
>>
>&g
ad_status,
>> +.ack_interrupt = at803x_ack_interrupt,
>> +.config_intr= at803x_config_intr,
>> .driver = {
>> .owner = THIS_MODULE,
>> },
>
>Shouldn't we take the opportunity to clean up the duplicated regi
David Miller <da...@davemloft.net> writes:
> From: Måns Rullgård <m...@mansr.com>
> Date: Wed, 11 Nov 2015 13:04:07 +
>
>> Måns Rullgård <m...@mansr.com> writes:
>>
>>> David Miller <da...@davemloft.net> writes:
>>>
>>>
Mason <slash@free.fr> writes:
> On 10/11/2015 22:51, Eric Dumazet wrote:
>
>> On Tue, 2015-11-10 at 21:21 +0000, Måns Rullgård wrote:
>>
>>> Even ixgbe uses napi_complete() while netdevice.h says one should
>>> "consider using napi_com
Eric Dumazet <eric.duma...@gmail.com> writes:
> On Wed, 2015-11-11 at 13:48 +0000, Måns Rullgård wrote:
>> Eric Dumazet <eric.duma...@gmail.com> writes:
>>
>> > On Wed, 2015-11-11 at 13:04 +, Måns Rullgård wrote:
>> >
>> >> I tried
Måns Rullgård <m...@mansr.com> writes:
> Eric Dumazet <eric.duma...@gmail.com> writes:
>
>> On Wed, 2015-11-11 at 13:48 +, Måns Rullgård wrote:
>>> Eric Dumazet <eric.duma...@gmail.com> writes:
>>>
>>> > On Wed, 2015-11-
David Miller <da...@davemloft.net> writes:
> From: Måns Rullgård <m...@mansr.com>
> Date: Wed, 11 Nov 2015 18:25:05 +
>
>> If the TX DMA channel is idle when start_xmit is called, it can be
>> started immediately. Checking the DMA status and starting it if
David Miller <da...@davemloft.net> writes:
> From: Måns Rullgård <m...@mansr.com>
> Date: Wed, 11 Nov 2015 19:09:19 +
>
>> David Miller <da...@davemloft.net> writes:
>>
>>> From: Måns Rullgård <m...@mansr.com>
>>> Date: Wed, 11
David Miller <da...@davemloft.net> writes:
> From: Måns Rullgård <m...@mansr.com>
> Date: Wed, 11 Nov 2015 19:17:07 +
>
>> David Miller <da...@davemloft.net> writes:
>>
>>> From: Måns Rullgård <m...@mansr.com>
>>>
David Miller <da...@davemloft.net> writes:
> From: Måns Rullgård <m...@mansr.com>
> Date: Wed, 11 Nov 2015 19:35:05 +
>
>>> I don't think it's silly at all.
>>
>> I'm sure I read somewhere that the time spent spinning on a lock should
>> be k
A_TO_DEVICE);
>> +
>> +if (dma_mapping_error(>dev, dma_addr)) {
>> +netdev_err(dev, "tx dma mapping error\n");
>> +kfree_skb(skb);
>> +dev->stats.tx_dropped++;
>> + return NETDEV_TX_OK;
>> +
t; +offset + RX_COPYHDR, len - RX_COPYHDR,
>> +RX_BUF_SIZE);
>> +}
>> +
>> + skb->protocol = eth_type_trans(skb, dev);
>> +netif_receive_skb(skb);
>> +}
>> +
>
> Any reason
s support?
>
> drivers/net/ethernet/aurora/nb8800.c | 1146
> ++
> drivers/net/ethernet/aurora/nb8800.h | 230 +++
Some of the increase is from new features, some from improvements, and
then there are a bunch of new comments.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller <da...@davemloft.net> writes:
> From: Måns Rullgård <m...@mansr.com>
> Date: Tue, 10 Nov 2015 18:05:15 +
>
>> Because I haven't been following the netdev list closely for the last
>> five years, and no documentation I read mentioned this fun
David Miller <da...@davemloft.net> writes:
> From: Måns Rullgård <m...@mansr.com>
> Date: Tue, 10 Nov 2015 20:53:19 +
>
>> David Miller <da...@davemloft.net> writes:
>>
>>> From: Måns Rullgård <m...@mansr.com>
>>> Date:
Andy Shevchenko <andy.shevche...@gmail.com> writes:
> On Wed, Nov 11, 2015 at 12:34 AM, Måns Rullgård <m...@mansr.com> wrote:
>> Andy Shevchenko <andy.shevche...@gmail.com> writes:
>>
>>>> +static inline void nb8800_maskb(struct nb8800_priv *priv, int
_TX_DESC_ADDR, txb->dma_desc);
>> + wmb(); /* ensure desc addr is written before starting DMA */
>
> Hm… Have I missed corresponding rmb() ? If it's about MMIO, perhaps mmiowb() ?
Possibly.
>> + nb8800_writel(priv, NB8800_TXC_CR, txc_cr | TCR_EN);
>> +
>> + priv->tx_queue = (priv->tx_queue + txb->chain_len) % TX_DESC_COUNT;
>> +}
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
1 - 100 of 110 matches
Mail list logo
