Hi Florian,
On Wed, 2017-02-08 at 10:20 -0800, Florian Fainelli wrote:
> On 02/08/2017 10:15 AM, David Miller wrote:
> >
> > From: Alexey Brodkin
> > Date: Mon, 6 Feb 2017 22:24:45 +0300
> >
> > >
> > > Given there're default values mention
Given there're default values mentioned in the PHY datasheet
fall-back gracefully to them instead of silently return an error
through the whole call-chain.
This allows to use minimalistic description in DT if no special
features are required.
Signed-off-by: Alexey Brodkin
Cc: Murali Kari
Hi Florian, all,
On Fri, 2017-02-03 at 10:34 -0800, Florian Fainelli wrote:
> On 02/03/2017 09:30 AM, Alexey Brodkin wrote:
> >
> > Hi Andrew,
> >
> > On Fri, 2017-02-03 at 18:10 +0100, Andrew Lunn wrote:
> > >
> > > On Fri, Feb 03, 2
Hi Andrew,
On Fri, 2017-02-03 at 18:10 +0100, Andrew Lunn wrote:
> On Fri, Feb 03, 2017 at 07:52:37PM +0300, Alexey Brodkin wrote:
> >
> > Current implemntation returns ENODEV if device tree node for
> > phy is absent. But in reality there're many boards with the one
pc: sending select for x.x.x.x
udhcpc: lease of x.x.x.x obtained, lease time 3600
deleting routers
adding dns x.x.x.x
------>8-----
Signed-off-by: Alexey Brodkin
Cc: Murali Karicheri
Cc: Sekhar Nori
Cc: David S. Miller
Cc: Grygorii Strashko
Cc: Fl
manab...@gmail.com;
> pr...@electromag.com.au; alexandre.tor...@gmail.com;
> vineet.gup...@synopsys.com
> Subject: Re: [PATCH] stmmac: Discard masked flags in interrupt status
> register
>
> From: Alexey Brodkin
> Date: Fri, 27 Jan 2017 15:24:43 +0300
>
> > D
Hi Giuseppe,
On Tue, 2017-01-31 at 10:55 +0100, Giuseppe CAVALLARO wrote:
> On 1/27/2017 11:23 AM, Alexey Brodkin wrote:
> >
> > That's why my initial proposal was to ignore whatever we read from this
> > register
> > if we have MDIO bus instantiated already.
GMAC, for
example we were happy enough to just see bogus messages about link
state changes.
So from now on we'll be only checking bits that really may trigger an
interrupt.
[1] https://lkml.org/lkml/2016/11/3/413
Signed-off-by: Alexey Brodkin
Cc: Giuseppe Cavallaro
Cc: Fabrice Gasnier
Cc:
Hi Giuseppe,
On Wed, 2017-01-25 at 21:39 +0300, Alexey Brodkin wrote:
> Hi Giuseppe,
>
> On Mon, 2016-11-14 at 09:14 +0100, Giuseppe CAVALLARO wrote:
> >
> > Hello Alexey
> >
> > Sorry for my late reply. In that case, I think that the stmmac
> > is using
Hi Giuseppe,
On Mon, 2016-11-14 at 09:14 +0100, Giuseppe CAVALLARO wrote:
> Hello Alexey
>
> Sorry for my late reply. In that case, I think that the stmmac
> is using own RGMII/SGMII support (PCS) to dialog with the
> transceiver. I think, from the HW capability register
> this feature is present
Hello,
I'm seeing pretty strange issue with GMAC reporting a lot of link state changes
based on bits in GMAC_RGSMIIIS. It looks like that:
-->8---
Link is Down
Link is Up - 10/Full
Link is Down
Link is Up - 10/Half
Link is Down
Link is Down
Link is Up -
Hello,
On Mon, 2016-07-11 at 06:15 +, Alexey Brodkin wrote:
> Hi Russel,
>
> On Sun, 2016-07-10 at 00:19 -0700, Russell Senior wrote:
> >
> > > > > > > "Alexey" == Alexey Brodkin writes:
> > Alexey> Hi Aaron,
> > Alexey> On
Hi Russel,
On Sun, 2016-07-10 at 00:19 -0700, Russell Senior wrote:
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > "Alexey" == Alexey Brodkin writes:
> Alexey> Hi Aaron,
> Alexey> On Sat
Hi Aaron,
On Sat, 2016-07-09 at 07:47 -0400, Aaron Z wrote:
> On Sat, Jul 9, 2016 at 4:37 AM, Alexey Brodkin
> wrote:
> >
> > Hello,
> >
> > I was playing with quite simple bridged setup on different boards with
> > very recent kernels (4.6.3 as of thi
Hello,
I was playing with quite simple bridged setup on different boards with
very recent kernels (4.6.3 as of this writing) and found one interesting
behavior that I cannot yet understand and googling din't help here as well.
My setup is pretty simple:
- --
introduced the problem. At least reverting it I got networking working.
And indeed that patch fixes mentioned issue.
In other words...
Tested-by: Alexey Brodkin
P.S. Given my observation is correct please add following to your commit
message if you ever do a respin:
-->8---
Fixes: 05c00d82f4d1 ("net: nps_enet: bug fix - handle lost tx interrupts")
Cc: # 4.6.x
-->8---
Hi Sergei,
On Thu, 2016-03-17 at 13:58 +0300, Sergei Shtylyov wrote:
> On 3/17/2016 12:41 PM, Alexey Brodkin wrote:
>
> >
> > Following commit broke DW GMAC functionality on AXS10x boards:
> > http://git.kernel.org/cgit/linux/kernel/git/torva
Hi Sergei,
On Thu, 2016-03-17 at 14:59 +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 3/17/2016 2:41 PM, Vineet Gupta wrote:
>
> >
> > >
> > > >
> > > > >
> > > > > Following commit broke DW GMAC functionality on AXS10x boards:
> > > > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/li
not found
eth0: Could not attach to PHY
stmmac_open: Cannot attach to PHY (error: -19)
--->8
Simplest solution is to add PHY description in board's .dts.
And so we do here.
Signed-off-by: Alexey Brodkin
Cc: Rob Herring
Cc: Phil R
Hi Sergei,
On Tue, 2016-03-15 at 17:38 +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 3/15/2016 12:29 PM, Alexey Brodkin wrote:
>
> >
> > Following commit broke DW GMAC functionality on AXS10x boards:
> > http://git.kernel.org/cgit/linux/kernel/git
not found
eth0: Could not attach to PHY
stmmac_open: Cannot attach to PHY (error: -19)
--->8
Simplest solution is to add PHY description in board's .dts.
And so we do here.
Signed-off-by: Alexey Brodkin
Cc: Rob Herring
Cc: Phil R
ergei Shtylyov
Cc: Giuseppe Cavallaro
Cc: linux-ker...@vger.kernel.org
Cc: sta...@vger.kernel.org
Cc: David Miller
Signed-off-by: Alexey Brodkin
---
Changes compared to v3:
* Remove "else" branch after "return" as suggested by Sergei.
Changes compared to v2:
* Updated commi
Hi Sergei,
On Tue, 2015-09-08 at 22:53 +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 09/08/2015 03:46 PM, Alexey Brodkin wrote:
>
> > > > Current check of phydev with IS_ERR(phydev) may make not much sense
> > > > because of_phy_connect() returns NU
Hi Sergei,
On Tue, 2015-09-08 at 14:20 +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 9/8/2015 11:43 AM, Alexey Brodkin wrote:
>
> > Current check of phydev with IS_ERR(phydev) may make not much sense
> > because of_phy_connect() returns NULL on failure instead of error v
ergei Shtylyov
Cc: Giuseppe Cavallaro
Cc: linux-ker...@vger.kernel.org
Cc: sta...@vger.kernel.org
Cc: David Miller
Signed-off-by: Alexey Brodkin
---
Changes compared to v2:
* Updated commit message with mention of of_phy_connect() instead of
of_phy_attach().
* Return ENODEV in ca
Hi Sergei,
On Tue, 2015-09-08 at 00:24 +0300, Sergei Shtylyov wrote:
> On 09/07/2015 11:50 PM, Alexey Brodkin wrote:
>
> > Current implementation via IS_ERR(phydev) may make no sense because
> > of_phy_attach() returns NULL on failure instead of error value.
>
>
Hi Sergei,
On Mon, 2015-09-07 at 23:53 +0300, Sergei Shtylyov wrote:
> On 09/07/2015 11:50 PM, Alexey Brodkin wrote:
>
> > Current implementation via IS_ERR(phydev) may make no sense because
> > of_phy_attach() returns NULL on failure instead of error value.
> >
> >
-ker...@vger.kernel.org
Cc: sta...@vger.kernel.org
Cc: David Miller
Cc: Sergei Shtylyov
Signed-off-by: Alexey Brodkin
---
Changes compared to v1:
* Use IS_ERR_OR_NULL() instead of discrete checks for null and err
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
1 file changed, 1
-ker...@vger.kernel.org
Cc: sta...@vger.kernel.org
Cc: David Miller
Signed-off-by: Alexey Brodkin
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet
on driver probe.
[2] Do explicit zeroing of both "des0" and "des1" fields
of all buffer descriptors during initialization of
DMA transfer.
And while at it fixed identation of dma_free_coherent()
counterpart as well.
Signed-off-by: Alexey Brodkin
Cc: Giuseppe Cavallaro
Hi David,
On Wed, 2015-06-24 at 01:44 -0700, David Miller wrote:
> From: Alexey Brodkin
> Date: Wed, 24 Jun 2015 11:07:26 +0300
>
> >
> > - priv->dma_tx = dma_alloc_coherent(priv->device,
> > txsize *
> > + priv->dma_tx = dma
on driver probe.
[2] Do explicit zeroing of both "des0" and "des1" fields
of all buffer descriptors during initialization of
DMA transfer.
Signed-off-by: Alexey Brodkin
Cc: Giuseppe Cavallaro
Cc: arc-linux-...@synopsys.com
Cc: linux-ker...@vger.kernel.org
Cc: sta...@vg
Hi David,
On Mon, 2015-06-22 at 09:43 +0300, Alexey Brodkin wrote:
> Hi David,
>
> On Sun, 2015-06-21 at 09:29 -0700, David Miller wrote:
> > From: Alexey Brodkin
> > Date: Tue, 16 Jun 2015 20:40:41 +0300
> >
> > > Current implementtion of descriptor i
Hi all,
On Wed, 2015-06-17 at 07:03 +, Vineet Gupta wrote:
+CC linux-arch, linux-mm, Arnd and Marek
On Tuesday 16 June 2015 11:11 PM, Alexey Brodkin wrote:
Current implementtion of descriptor init procedure only takes care about
ownership flag. While it is perfectly possible to have
Hi David,
On Sun, 2015-06-21 at 09:29 -0700, David Miller wrote:
> From: Alexey Brodkin
> Date: Tue, 16 Jun 2015 20:40:41 +0300
>
> > Current implementtion of descriptor init procedure only takes care
> > about
> > ownership flag. While it is perfectly possible to
GMAC DMA block.
Solution to this problem is as simple as explicit zeroing of both des0
and des1 fields of all buffer descriptors.
Signed-off-by: Alexey Brodkin
Cc: Giuseppe Cavallaro
Cc: arc-linux-...@synopsys.com
Cc: linux-ker...@vger.kernel.org
Cc: sta...@vger.kernel.org
---
drivers/net
reset sequence*/
> + ge_rst.gmac_0 = NPS_ENET_ENABLE;
> + nps_enet_reg_set(net_priv, NPS_ENET_REG_GE_RST,
> ge_rst.value);
> + usleep_range(10, 20);
I'm wondering if there's a possibility to read back for example the
same bit we set and once it gets reset by hardware we then know for
sure that hardware exited reset state? If there's such a possibility we
may just busywait for it... well probably with known timeout to report
a problem if hardware still in reset state.
Otherwise you cannot be sure hardware is ready to operate really.
Probably I'm nitpicking here but in general driver looks good to me so
feel free to add:
Acked-by: Alexey Brodkin
-Alexey--
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
37 matches
Mail list logo
