Arnd Bergmann writes:
> From: Arnd Bergmann
>
> The tango4 platform is getting removed, and this driver has no
> other known users, so it can be removed.
>
> Cc: Marc Gonzalez
> Cc: Mans Rullgard
> Signed-off-by: Arnd Bergmann
Acked-by: Mans Rullgard
> ---
> drivers/net/ethernet/Kconfig
s/net/phy/smsc.c
@@ -408,7 +408,7 @@ static struct phy_driver smsc_phy_driver[] = {
.read_status= lan87xx_read_status,
.config_init= smsc_phy_config_init,
.soft_reset = smsc_phy_reset,
- .config_aneg= lan87xx_config_aneg_ext,
+ .config_aneg= lan87xx_config_aneg,
/* IRQ related */
.ack_interrupt = smsc_phy_ack_interrupt,
The internal phy of the LAN9500A does have a register 16 with
documentation matching the usage in this patch. Unfortunately, there
doesn't seem to be any way of distinguishing this from the LAN8710A
based on register values. Anyone got any clever ideas?
--
Måns Rullgård
Heiner Kallweit writes:
> On 28.03.2021 21:59, Måns Rullgård wrote:
>> Andre Edich writes:
>>
>>> Generally, each PHY has their own configuration and it can be done
>>> through an external PHY driver. The smsc95xx driver uses only the
>>> hard-code
e.
>
> Reported-by: Måns Rullgård
> Fixes: 05b35e7eb9a1 ("smsc95xx: add phylib support")
> Signed-off-by: Andre Edich
> ---
> drivers/net/phy/smsc.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/phy/smsc.c b/drivers/n
writes:
> On Mon, 2021-03-29 at 12:19 +0100, Måns Rullgård wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>> the content is safe
>>
>> Andre Edich writes:
>>
>> > The function lan87xx_config_aneg_ext was introdu
e.
>
> Reported-by: Måns Rullgård
> Fixes: 05b35e7eb9a1 ("smsc95xx: add phylib support")
> Signed-off-by: Andre Edich
> ---
> drivers/net/phy/smsc.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
I can confirm that this fixes the problem I was seeing.
RCE_MEM, 1);
>> ...
>> rc = davinci_emac_try_get_mac(pdev, res_ctrl ? 0 : 1,
>> priv->mac_addr);
>>
>> So it there are two ranges, the slave param becomes 0. It there is only one,
>> it
>> will be 1. Since the am3517 only has a single regs entry it ends up with
>> slave 1,
>> while there is only a single davinci_emac.
>
> OK thanks for clarifying it:
>
> Acked-by: Tony Lindgren
What happened to this patch?
--
Måns Rullgård
> num_pkts < quota) {
> mbx_mask = BIT(priv->rx_next); /* next rx mailbox to process */
> --
> 2.7.4
This seems to have been lost or forgotten.
--
Måns Rullgård
> - },
> {
> .compatible = "sigma,smp8642-ethernet",
> .data = &nb8800_tangox_ops,
> --
Please leave this. It works just fine on tango3.
--
Måns Rullgård
_FL, priv->pause_tx);
> - nb8800_start_rx(dev);
> - netif_tx_unlock_bh(dev);
> - napi_enable(&priv->napi);
> - } else {
> - nb8800_modl(priv, NB8800_RXC_CR, RCR_FL, priv->pause_tx);
> - }
> + nb8800_modl(priv, NB8800_RXC_CR, RCR_FL, priv->pause_tx);
> }
>
> static void nb8800_link_reconfigure(struct net_device *dev)
> --
--
Måns Rullgård
egotiate 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
0_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
Marc Gonzalez 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-NB8800 hardware block (ethernet DMA). Thus,
>>> it
Marc Gonzalez 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 of your newer chips it can, but
Marc Gonzalez 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.
>>> Delete nb8800_dma_stop.
>>
>
Marc Gonzalez 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:
>>>>
>>>>> Power entire ethernet block d
Marc Gonzalez 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 have other suggestions?
>>
o?
>
> 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
:
> - pad_mode = PAD_MODE_RGMII | PAD_MODE_GTX_CLK_DELAY;
> + pad_mode = PAD_MODE_RGMII;
> break;
Won't this just make it break in a different set of circumstances?
I think the 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
Mason 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
mode |= HALF_DUPLEX;
>
> if (gigabit) {
> - if (priv->phy_mode == PHY_INTERFACE_MODE_RGMII)
> + if (phy_interface_is_rgmii(dev->phydev))
> mac_mode |= RGMII_MODE;
>
> mac_mode |= GMAC_MODE;
> --
> 2.11.0
>
--
Måns Rullgård
efault:
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
Marc Gonzalez writes:
> On 21/07/2017 15:04, Måns Rullgård wrote:
>
>> Marc Gonzalez wrote:
>>
>>> According to commit e5f3a4a56ce2a707b2fb8ce37e4414dcac89c672
>>> ("Documentation: devicetree: clarify usage of the RGMII phy-modes")
>>> the
Marc Gonzalez 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:
>>>>
>>>>> According to commit e5f3a4a56ce2a707b
n 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 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 less heavy-handed way?
>
> I&#
n 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
Mason 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't. When the enable bit is 1,
Mason 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 in a way that ndo_open
Mason 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 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 have it on by default. Th
xpected."
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 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:
>>>>
>>>>> I have identified a 100% reprod
criptors 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
-1492,8 +1492,6 @@ static int 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
Mason 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.
>>> ---
>>> drivers/net/ethernet/aurora/nb8800.c | 50
n 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 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 feature has been added to
Mason 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 does the tango5 do if you flood
Mason 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
>>>> kernel can keep up with?
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
ket loss could be somewhere
else.
--
Måns Rullgård
9,7 @@ static int nb8800_open(struct net_device *dev)
if (err)
goto err_free_dma;
+ nb8800_writel(priv, NB8800_RX_ITR, priv->rx_itr_irq);
nb8800_mac_rx(dev, true);
nb8800_mac_tx(dev, true);
--
Måns Rullgård
s device. I'll include netdev when I send an updated
version.
--
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
it is supported or not.
This does something to the configuration of the external pins, the
documentation is vague about what.
>> +phydev = phy_find_first(bus);
>> +if (!phydev || phy_read(phydev, MII_BMSR) <= 0) {
>
> What is this additional MII_MBSR read used for?
On one of my boards, phylib mis
MBSR read used for?
>>
>> On one of my boards, phylib misdetects a phy on the second ethernet port
>> even though there is none. Perhaps I should revisit that problem and
>> look for a better solution.
>
> I think that would be best, if you are currently using the Gener
igma,smp8642-ethernet", "aurora,nb8800";
> + reg = <0x26000 0x800>;
> + interrupts = <38>;
> + clocks = <&sys_clk>;
> + max-speed = <1000>;
> + phy-connection-type = "rgmii";
> + phy-handle = <ð0_phy>;
&g
t;
> Since you are implementing ethtool please add a driver
> info function.
I don't know what I'd set there that the fallback code doesn't.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body
ting new
> resources first, then receive data if alloc + map suceeded.
The hardware receives a frame and stores it in the provided DMA buffer,
then raises an interrupt and moves on to the next buffer. When a buffer
is handed over to the network stack, a new one has to take its place in
the DMA
t; + struct resource *res;
>> + struct net_device *dev;
>> + struct mii_bus *bus;
>> + const unsigned char *mac;
>> + void __iomem *base;
>> + int irq;
>> + int ret;
>> +
>> + match = of_match_device(nb8800_dt_i
Francois Romieu writes:
> Måns Rullgård :
>> Francois Romieu writes:
> [...]
>> > It looks like it receives, then tries to allocate new resources. If so
>> > it may deplete the ring and you should instead consider allocating new
>> > resources first, th
arithmetic on pointer values. They have to be
cast to an integer type first.
>>>> + nb8800_writeb(priv, NB8800_RANDOM_SEED, 0x08);
>>>> +
>>>> + /* TX single deferral params */
>>>> + nb8800_writeb(priv, NB8800_TX_SDP, 0xc);
>>
@@ again:
> 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
ev->dev, "no PHY specified\n");
> + ret = -ENODEV;
> + goto err_free_bus;
> + }
> }
>
> priv->mii_bus = bus;
> --
> 2.1.4
>
--
Måns Rullgård
"phy-handle", 0);
if (!priv->phy_node) {
dev_err(&pdev->dev, "no PHY specified\n");
ret = -ENODEV;
goto err_free_bus;
}
--
Måns Rullgård
Sebastian Frias writes:
> On 02/05/2016 02:58 PM, Måns Rullgård wrote:
>> Sebastian Frias writes:
>>
>>> Signed-off-by: Sebastian Frias
>>> ---
>>> drivers/net/ethernet/aurora/nb8800.c | 15 ---
>>> 1 file changed, 12 inserti
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(&pdev->dev, "no PHY specified\n");
> ret = -ENODEV;
> --
> 2.1.4
--
Måns Rullgård
Sebastian Frias writes:
> On 02/05/2016 03:34 PM, Måns Rullgård wrote:
>> Sebastian Frias writes:
>>
>>> Signed-off-by: Sebastian Frias
>>
>> Please change the subject to something like "net: ethernet: nb8800:
>> support fixed-link DT node&quo
Sebastian Frias writes:
> On 02/05/2016 04:08 PM, Måns Rullgård wrote:
>> Sebastian Frias writes:
>>
>>> On 02/05/2016 03:34 PM, Måns Rullgård wrote:
>>>> Sebastian Frias writes:
>>>>
>>>>> Signed-off-by: Sebastian Frias
>&
Andy Shevchenko writes:
> On Fri, Feb 5, 2016 at 3:39 PM, Måns Rullgård wrote:
>>> + if (ret < 0) {
>>> + dev_err(&pdev->dev, "broken fixed-link
>>> specification\n");
>>
>> Line is l
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(&pdev->dev, "no PHY specified\n");
> ret = -ENODEV;
> --
> 2.1.4
>
--
Måns Rullgård
Sebastian Frias writes:
> On 02/05/2016 04:26 PM, Måns Rullgård wrote:
>> Sebastian Frias writes:
>>
>>> On 02/05/2016 04:08 PM, Måns Rullgård wrote:
>>>> Sebastian Frias writes:
>>>>
>>>>> On 02/05/2016 03:34 PM, Måns Rullgård w
Sebastian Frias 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
>>>> the
e 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
k about how it should behave in
>> at803x_link_change_notify without control of the reset line, because
>> this code isn't reached then.
>
> If I understand correctly, it is possible to soft-reset the PHY
> by writing to a specific register. The GPIO pin is useful only to
->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_pause_config(dev);
> - else if (priv->phydev)
> - phy_start_aneg(priv->phydev);
> + else if (phydev)
> + phy_start_aneg(phydev);
>
> return 0;
> }
> diff --git a/drivers/net/ethernet/aurora/nb8800.h
> b/drivers/net/ethernet/aurora/nb8800.h
> index e5adbc2..6ec4a95 100644
> --- a/drivers/net/ethernet/aurora/nb8800.h
> +++ b/drivers/net/ethernet/aurora/nb8800.h
> @@ -284,7 +284,6 @@ struct nb8800_priv {
>
> struct mii_bus *mii_bus;
> struct device_node *phy_node;
> - struct phy_device *phydev;
>
> /* PHY connection type from DT */
> int phy_mode;
> --
> 1.7.4.4
>
--
Måns Rullgård
.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
a
specific driver. Interrupts, for example.
--
Måns Rullgård
+ dev_kfree_skb(skb);
> return;
> }
>
> --
> 2.7.4
>
--
Måns Rullgård
@ -1419,7 +1419,7 @@ static int nb8800_probe(struct platform_device *pdev)
> if (ops && ops->reset) {
> ret = ops->reset(dev);
> if (ret)
> - goto err_free_dev;
> + goto err_disable_clk;
> }
>
> bus = devm_mdiobus_alloc(&pdev->dev);
>
--
Måns Rullgård
ernet/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 (!phydev) {
> + err = -ENODEV;
> goto err_free_irq;
> + }
>
> nb8800_pause_adv(dev);
>
--
Måns Rullgård
e 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
Felix Fietkau writes:
> On 2016-12-10 14:25, Måns Rullgård wrote:
>> Felix Fietkau writes:
>>
>>> On 2016-12-07 19:54, Jason A. Donenfeld wrote:
>>>> On Wed, Dec 7, 2016 at 7:51 PM, David Miller wrote:
>>>>> It's so much better to anal
ur protocol.
Always include some way of extending the protocol in the future. A
single bit is often enough. Require a value of zero initially, then if
you ever want to change anything, setting it to one can indicate
whatever you want, including a complete redesign of the header.
Alternatively, a o
David Laight 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
>> skb_add_rx_frag(). The kernel netw
.
> 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
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 itself.
> (Although 1ns is about 1 foot - so track delays of that length are unlikely.)
There could be a delay element.
--
Måns Rullgård
ys enabled, whether the user
> requests it or not.
>
> Could someone knowledgeable comment on the expected behavior of
> enabling rgmii rx (and tx) clock delay?
Clock delay is sometimes (depending on PCB layout) required to achieve
the correct timing between clock and data signals. 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
TB 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
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
NTERFACE_MODE_RGMII_TXID:
> - pad_mode = PAD_MODE_RGMII | PAD_MODE_GTX_CLK_DELAY;
> + pad_mode = PAD_MODE_RGMII;
> break;
>
> default:
> --
> 1.7.11.2
If this change is correct (and I'm not convinced it is), that case
should be merged with the one above it and PHY_INTERFACE_MODE_RGMII_RXID
added as well.
--
Måns Rullgård
Andrew Lunn writes:
> On Fri, Nov 04, 2016 at 03:05:00PM +0000, Måns Rullgård wrote:
>> Andrew Lunn writes:
>>
>> >> > I agree with you. But fixing it is likely to break boards which
>> >> > currently have "rgmii", but actually need the
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
Florian Fainelli 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 writes:
>>>
>>>> The delay can be applied at PHY or MAC level, but since
>>&g
Florian Fainelli writes:
> On 11/04/2016 08:22 AM, Måns Rullgård wrote:
>> Andrew Lunn writes:
>>
>>> On Fri, Nov 04, 2016 at 03:05:00PM +, Måns Rullgård wrote:
>>>> Andrew Lunn writes:
>>>>
>>>>>>> I agree with you.
GMII_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
;
> - 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
Sebastian Frias 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))
>>
d 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
Florian Fainelli writes:
> On 11/14/2016 11:00 AM, Måns Rullgård wrote:
>> Florian Fainelli writes:
>>
>>> On 11/14/2016 10:20 AM, Florian Fainelli wrote:
>>>> On 11/14/2016 09:59 AM, Sebastian Frias wrote:
>>>>> On 11/14/2016 06:32 PM, Fl
t/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 on HAS_DMA
> select PHYLIB
> help
>Support for the AU-
;nr_frags, page,
>> +offset + RX_COPYHDR, len - RX_COPYHDR,
>> +RX_BUF_SIZE);
>> +}
>> +
>> +skb->protocol = eth_type_trans(skb, dev);
>> +netif_receive_skb(skb);
>> +}
>> +
>
> Any
O_DEVICE);
>> +
>> +if (dma_mapping_error(&dev->dev, dma_addr)) {
>> +netdev_err(dev, "tx dma mapping error\n");
>> +kfree_skb(skb);
>> +dev->stats.tx_dropped++;
>> + return NETDEV_TX_OK;
>> +
/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 writes:
> From: Måns Rullgård
> 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 function. I can
>> certainly change it.
>
David Miller writes:
> From: Måns Rullgård
> Date: Tue, 10 Nov 2015 20:53:19 +
>
>> David Miller writes:
>>
>>> From: Måns Rullgård
>>> Date: Tue, 10 Nov 2015 18:05:15 +
>>>
>>>> Because I haven't been follo
SC_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
Andy Shevchenko writes:
> On Wed, Nov 11, 2015 at 12:34 AM, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>>
>>>> +static inline void nb8800_maskb(struct nb8800_priv *priv, int reg,
>>>> + u32 mask, u32 val)
>>>&g
+
>> +/* rx interrupt */
>> +val = nb8800_readl(priv, NB8800_RXC_SR);
>> +if (val) {
> [...]
>> +}
>> +
>> +return IRQ_HANDLED;
>
> Returning IRQ_HANDLED is fine if one of those hold:
> 1. you're sure that at least one of the &q
1 - 100 of 125 matches
Mail list logo
