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 abrod...@synopsys.com
-Alexey--
To unsubscribe
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 alexey.brod...@synopsys.com
Date: Tue, 16 Jun 2015 20:40:41 +0300
Current implementtion of descriptor init procedure only takes
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
and des1 fields
of all buffer descriptors during initialization of
DMA transfer.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Giuseppe Cavallaro peppe.cavall...@st.com
Cc: arc-linux-...@synopsys.com
Cc: linux-ker...@vger.kernel.org
Cc: sta...@vger.kernel.org
Cc: David Miller da
Hi David,
On Wed, 2015-06-24 at 01:44 -0700, David Miller wrote:
From: Alexey Brodkin alexey.brod...@synopsys.com
Date: Wed, 24 Jun 2015 11:07:26 +0300
- priv-dma_tx = dma_alloc_coherent(priv-device,
txsize *
+ priv-dma_tx = dma_zalloc_coherent(priv-device
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 abrod...@synopsys.com
Cc: Giuseppe Cavallaro peppe.cavall...@st.com
Cc: arc-linux-...@synopsys.com
Cc
of the 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 abrod...@synopsys.com
Cc: Giuseppe Cavallaro peppe.cavall...@st.com
Cc: arc-linux-...@synopsys.com
Cc: linux-ker...@vger.kernel.org
Cc
-linux-...@synopsys.com
Cc: linux-ker...@vger.kernel.org
Cc: sta...@vger.kernel.org
Cc: David Miller <da...@davemloft.net>
Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
Shtylyov <sergei.shtyl...@cogentembedded.com>
Cc: Giuseppe Cavallaro <peppe.cavall...@st.com>
Cc: linux-ker...@vger.kernel.org
Cc: sta...@vger.kernel.org
Cc: David Miller <da...@davemloft.net>
Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
---
Changes compared to v2:
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 err
<peppe.cavall...@st.com>
Cc: linux-ker...@vger.kernel.org
Cc: sta...@vger.kernel.org
Cc: David Miller <da...@davemloft.net>
Cc: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
---
Changes compared to v1:
* Use IS_ERR_OR_NU
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.
> >
>
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 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
Shtylyov <sergei.shtyl...@cogentembedded.com>
Cc: Giuseppe Cavallaro <peppe.cavall...@st.com>
Cc: linux-ker...@vger.kernel.org
Cc: sta...@vger.kernel.org
Cc: David Miller <da...@davemloft.net>
Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
---
Changes compared to v3:
commit 05c00d82f4d1 ("net: nps_enet: bug fix - handle lost tx
interrupts")
that 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 <abrod...@synopsys.com>
P.S. Given my obse
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:
> > > > >
fff 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 <abrod...@synopsys.com>
Cc: Ro
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
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
fff 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 <abrod...@synopsys.com>
Cc: Ro
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:
- --
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
> <alexey.brod...@synopsys.com> wrote:
> >
> > Hello,
> >
> > I was playing with quite simple bridged setup on different boards with
> > ver
Hi Russel,
On Sun, 2016-07-10 at 00:19 -0700, Russell Senior wrote:
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > "Alexey" == Alexey Brodkin <alexey.brod...@synopsys.com> writes:
> Alexe
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 <alexey.brod...@synopsys.com> writes:
> > Alexey> H
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
>
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.
>
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 <abrod...@synopsys.
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
dhcpc: lease of x.x.x.x obtained, lease time 3600
deleting routers
adding dns x.x.x.x
-->8-
Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
Cc: Murali Karicheri <m-kariche...@ti.com>
Cc: Sekhar Nori <nsek...@ti.com>
Cc: David S
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 <alexey.brod...@synopsys.com>
> Date: Fri, 27 Jan 201
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
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 <abrod...@synopsys.com>
Cc: Giuseppe Cavallaro <peppe.cava
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
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 <alexey.brod...@synopsys.com>
> > Date: Mon, 6 Feb 2017 22:24:45 +0300
> >
> > >
> > > Given the
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 -
36 matches
Mail list logo
