from:"Dinh Nguyen"

Re: Ethernet on my CycloneV broke since 4.9.124

2018-11-15 Thread Dinh Nguyen




On 11/15/18 9:50 AM, Clément Péron wrote:
> Hi Dinh,
> 
> Did you upstream the patch on linux-stable ?
> 

Not yet...

Dinh
> On Fri, 2 Nov 2018 at 11:02, Clément Péron  wrote:
>>
>> Hi Dinh,
>>
>> On Wed, 31 Oct 2018 at 23:02, Dinh Nguyen  wrote:
>>>
>>> Hi Clement,
>>>
>>> On 10/31/2018 10:36 AM, Clément Péron wrote:
>>>> Hi Dinh,
>>>>
>>>> On Wed, 31 Oct 2018 at 15:42, Dinh Nguyen  wrote:
>>>>>
>>>>> Hi Clement,
>>>>>
>>>>> On 10/31/2018 08:01 AM, Clément Péron wrote:
>>>>>> Hi,
>>>>>>
>>>>>> The patch "net: stmmac: socfpga: add additional ocp reset line for
>>>>>> Stratix10" introduce in 4.9.124 broke the ethernet on my CycloneV
>>>>>> board.
>>>>>>
>>>>>> When I boot i have this issue :
>>>>>>
>>>>>> socfpga-dwmac ff702000.ethernet: error getting reset control of ocp -2
>>>>>> socfpga-dwmac: probe of ff702000.ethernet failed with error -2
>>>>>>
>>>>>> Reverting the commit : 6f37f7b62baa6a71d7f3f298acb64de51275e724 fix the 
>>>>>> issue.
>>>>>>
>>>>>
>>>>> Are you sure? I just booted v4.9.124 and did not see any errors. The
>>>>> error should not appear because the commit is using
>>>>> devm_reset_control_get_optional().
>>>>
>>>> I'm booting on 4.9.130 actually, Agree with you that
>>>> devm_reset_control_get_optional should not failed but checking other
>>>> usage of this helper
>>>> https://elixir.bootlin.com/linux/v4.9.135/source/drivers/i2c/busses/i2c-mv64xxx.c#L824
>>>> https://elixir.bootlin.com/linux/v4.9.135/source/drivers/crypto/sunxi-ss/sun4i-ss-core.c#L259
>>>> Show that they don't check for errors except for PROBE_DEFER
>>>>
>>>
>>> I made a mistake, I was booting linux-next. I am seeing the error with
>>> v4.9.124. It's due to this commit not getting backported:
>>>
>>> "bb475230b8e59a reset: make optional functions really optional"
>>>
>>> I have backported the patch and is available here if you like to take a
>>> look:
>>
>> Thanks, works fine on my board too.
>> Regards,
>> Clement
>>
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git/log/?h=v4.9.124_optional_reset
>>>
>>> Dinh

Re: Ethernet on my CycloneV broke since 4.9.124

2018-10-31 Thread Dinh Nguyen

Hi Clement,

On 10/31/2018 10:36 AM, Clément Péron wrote:
> Hi Dinh,
> 
> On Wed, 31 Oct 2018 at 15:42, Dinh Nguyen  wrote:
>>
>> Hi Clement,
>>
>> On 10/31/2018 08:01 AM, Clément Péron wrote:
>>> Hi,
>>>
>>> The patch "net: stmmac: socfpga: add additional ocp reset line for
>>> Stratix10" introduce in 4.9.124 broke the ethernet on my CycloneV
>>> board.
>>>
>>> When I boot i have this issue :
>>>
>>> socfpga-dwmac ff702000.ethernet: error getting reset control of ocp -2
>>> socfpga-dwmac: probe of ff702000.ethernet failed with error -2
>>>
>>> Reverting the commit : 6f37f7b62baa6a71d7f3f298acb64de51275e724 fix the 
>>> issue.
>>>
>>
>> Are you sure? I just booted v4.9.124 and did not see any errors. The
>> error should not appear because the commit is using
>> devm_reset_control_get_optional().
> 
> I'm booting on 4.9.130 actually, Agree with you that
> devm_reset_control_get_optional should not failed but checking other
> usage of this helper
> https://elixir.bootlin.com/linux/v4.9.135/source/drivers/i2c/busses/i2c-mv64xxx.c#L824
> https://elixir.bootlin.com/linux/v4.9.135/source/drivers/crypto/sunxi-ss/sun4i-ss-core.c#L259
> Show that they don't check for errors except for PROBE_DEFER
> 

I made a mistake, I was booting linux-next. I am seeing the error with
v4.9.124. It's due to this commit not getting backported:

"bb475230b8e59a reset: make optional functions really optional"

I have backported the patch and is available here if you like to take a
look:

https://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git/log/?h=v4.9.124_optional_reset

Dinh

Re: Ethernet on my CycloneV broke since 4.9.124

2018-10-31 Thread Dinh Nguyen

Hi Clement,

On 10/31/2018 08:01 AM, Clément Péron wrote:
> Hi,
> 
> The patch "net: stmmac: socfpga: add additional ocp reset line for
> Stratix10" introduce in 4.9.124 broke the ethernet on my CycloneV
> board.
> 
> When I boot i have this issue :
> 
> socfpga-dwmac ff702000.ethernet: error getting reset control of ocp -2
> socfpga-dwmac: probe of ff702000.ethernet failed with error -2
> 
> Reverting the commit : 6f37f7b62baa6a71d7f3f298acb64de51275e724 fix the issue.
> 

Are you sure? I just booted v4.9.124 and did not see any errors. The
error should not appear because the commit is using
devm_reset_control_get_optional().

Dinh

Re: [BUG] net: stmmac: socfpga ethernet no longer working on linux-next

2018-06-14 Thread Dinh Nguyen

On Thu, Jun 14, 2018 at 10:23 AM Jose Abreu  wrote:
>
> On 14-06-2018 15:21, Dinh Nguyen wrote:
> >
> > [0.835537] socfpga-dwmac ff702000.ethernet: PTP uses main clock
> > [0.841794] socfpga-dwmac ff702000.ethernet: Version ID not available
> > [0.848223] socfpga-dwmac ff702000.ethernet: DWMAC1000
> > [0.853454] socfpga-dwmac ff702000.ethernet: Normal descriptors
> > [0.859357] socfpga-dwmac ff702000.ethernet: Ring mode enabled
> > [0.865184] socfpga-dwmac ff702000.ethernet: DMA HW capability register 
> > suppo
> > rted
> > [0.872654] socfpga-dwmac ff702000.ethernet: RX Checksum Offload Engine 
> > suppo
> > rted
> > [0.880113] socfpga-dwmac ff702000.ethernet: COE Type 2
> > [0.885329] socfpga-dwmac ff702000.ethernet: TX Checksum insertion 
> > supported
> >
>
> Interesting ... Please check if bellow patch makes thing work
> again (if not please send me the resultant dmesg log and also the
> log without the problematic patch that you identified):
>
> >8--
> diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.c
> b/drivers/net/ethernet/stmicro/stmmac/hwif.c
> index 14770fc..1961819 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/hwif.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/hwif.c
> @@ -252,12 +252,8 @@ int stmmac_hwif_init(struct stmmac_priv *priv)
>  return ret;
>  }
>
> -/* Run quirks, if needed */
> -if (entry->quirks) {
> -ret = entry->quirks(priv);
> -if (ret)
> -return ret;
> -}
> +/* Save quirks, if needed for posterior use */
> +priv->hwif_quirks = entry->quirks;
>
>  return 0;
>  }
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> index 025efbf..be7da43 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> @@ -193,6 +193,9 @@ struct stmmac_priv {
>
>  /* Pulse Per Second output */
>  struct stmmac_pps_cfg pps[STMMAC_PPS_MAX];
> +
> +/* DEBUG */
> +int (*hwif_quirks)(struct stmmac_priv *priv);
>  };
>
>  enum stmmac_state {
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 11fb7c7..fbe74f2 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -4130,6 +4130,12 @@ static int stmmac_hw_init(struct
> stmmac_priv *priv)
>  if (priv->dma_cap.tsoen)
>  dev_info(priv->device, "TSO supported\n");
>
> +if (priv->hwif_quirks) {
> +ret = priv->hwif_quirks(priv);
> +if (ret)
> +return ret;
> +}
> +
>  return 0;
>  }
>
> >8--
>

The above patch fixed it!

Dinh

Re: [BUG] net: stmmac: socfpga ethernet no longer working on linux-next

2018-06-14 Thread Dinh Nguyen

On Thu, Jun 14, 2018 at 6:14 AM Marek Vasut  wrote:
>
> On 06/14/2018 10:18 AM, Jose Abreu wrote:
> > On 14-06-2018 08:38, Jose Abreu wrote:
> >> Hello,
> >>
> >> On 13-06-2018 21:46, Dinh Nguyen wrote:
> >>> Hi,
> >>>
> >>> The stmmac ethernet has stopped working in linux-next and linus/master
> >>> branch(v4.17-11782-gbe779f03d563)
> >>>
> >>> It appears that the stmmac ethernet has stopped working after these 2 
> >>> commits:
> >>>
> >>> 4dbbe8dde848 net: stmmac: Add support for U32 TC filter using Flexible RX 
> >>> Parser
> >>> 5f0456b43140 net: stmmac: Implement logic to automatically select HW 
> >>> Interface
> >>>
> >>> If I move to this commit "565020aaeebf net: stmmac: Disable ACS
> >>> Feature for GMAC >= 4", then the stmmac works again on SoCFPGA.
> >>>
> >>> I was following this thread:
> >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.spinics.net_lists_netdev_msg502858.html=DwIBaQ=DPL6_X_6JkXFx7AXWqB0tg=yaVFU4TjGY0gVF8El1uKcisy6TPsyCl9uN7Wsis-qhY=fvPkLp2xlWolmIYwoFLmALhxlycg1w0UmxiYdT7qojc=aC4a2U3X_siDxSNz3c5OeadhEJWll31yP-oi5nNar94=
> >>>
> >>> Was wondering if there was a patch to fix dwmac-sun8i that the socfpga
> >>> platform needs as well?
> >> Probably. I will check and get back to you ASAP.
> >
> > This seems to be a different problem. Can you send me your dmesg
> > log and DT bindings you are using?
>
> arch/arm/boot/dts/socfpga_arria10_socdk_sdmmc.dts
> for example fails for me in next/master. Worked on 4.17-rc7.
>

I'm using "arch/arm/boot/dts/socfpga_arria5_socdk.dts". Here's my boot log:

It appears to just get stuck in "eth0: link becomes ready", times out
and reinits:

[0.00] Linux version 4.17.0-11782-gbe779f03d563-dirty (dinguyen@linux-bu
ilds1) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #26 SMP Thu Jun 14
09:01:38 CDT 2018
[0.00] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instructio
n cache
[0.00] OF: fdt: Machine model: Altera SOCFPGA Arria V SoC Development Ki
t
[0.00] debug: ignoring loglevel setting.
[0.00] Memory policy: Data cache writealloc
[0.00] On node 0 totalpages: 262144
[0.00]   Normal zone: 1536 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 196608 pages, LIFO batch:31
[0.00]   HighMem zone: 65536 pages, LIFO batch:15
[0.00] random: get_random_bytes called from start_kernel+0xac/0x488 with
 crng_init=0
[0.00] percpu: Embedded 16 pages/cpu @(ptrval) s36044 r8192 d21300 u6553
6
[0.00] pcpu-alloc: s36044 r8192 d21300 u65536 alloc=16*4096
[0.00] pcpu-alloc: [0] 0 [0] 1
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 260608
[0.00] Kernel command line: root=/dev/nfs rw nfsroot=10.122.105.139:/hom
e/dinguyen/rootfs_yocto ip=dhcp debug ignore_loglevel
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 1027460K/1048576K available (7168K kernel code, 508K rwda
ta, 1540K rodata, 1024K init, 133K bss, 21116K reserved, 0K cma-reserved, 262144
K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xf080 - 0xff80   ( 240 MB)
[0.00] lowmem  : 0xc000 - 0xf000   ( 768 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0x(ptrval) - 0x(ptrval)   (8160 kB)
[0.00]   .init : 0x(ptrval) - 0x(ptrval)   (1024 kB)
[0.00]   .data : 0x(ptrval) - 0x(ptrval)   ( 509 kB)
[0.00].bss : 0x(ptrval) - 0x(ptrval)   ( 134 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[0.00] ftrace: allocating 25769 entries in 76 pages
[0.00] Hierarchical RCU implementation.
[0.00]  RCU event tracing is enabled.
[0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[0.00] L2C-310 enabling early BRESP for Cortex-A9
[0.00] L2C-310 full line of zeros enabled for Cortex-A9
[0.00] L2C-310 ID prefetch enabled, offset 8 lines
[0.00] L2C-310 dynamic clock gating enabled, standby mode enabled
[0.00] L2C-310 cache controller enabled, 8 ways, 512 kB
[0.00] L2C-310: CACHE_ID 0x410030c9, AUX_CTRL 0x76460001
[

[BUG] net: stmmac: socfpga ethernet no longer working on linux-next

2018-06-13 Thread Dinh Nguyen

Hi,

The stmmac ethernet has stopped working in linux-next and linus/master
branch(v4.17-11782-gbe779f03d563)

It appears that the stmmac ethernet has stopped working after these 2 commits:

4dbbe8dde848 net: stmmac: Add support for U32 TC filter using Flexible RX Parser
5f0456b43140 net: stmmac: Implement logic to automatically select HW Interface

If I move to this commit "565020aaeebf net: stmmac: Disable ACS
Feature for GMAC >= 4", then the stmmac works again on SoCFPGA.

I was following this thread:
https://www.spinics.net/lists/netdev/msg502858.html

Was wondering if there was a patch to fix dwmac-sun8i that the socfpga
platform needs as well?

Thanks,
Dinh

Re: [PATCH V2] net: stmmac: socfpga: Remove re-registration of reset controller

2016-04-21 Thread Dinh Nguyen



On 04/21/2016 06:51 AM, Marek Vasut wrote:

 if you modify the patch to call stmmac_dvr_probe() before calling
 socfpga_dwmac_init(), then you would already have the reset control
 information.
>>>
>>> I was under the impression that you must call socfpga_dwmac_init()
>>> before stmmac_dvr_probe() for whatever hardware-related reason. If
>>> you are absolutely certain this is not necessary, then that's just
>>> perfect and the patch can be simplified even further -- just remove
>>> the call to socfpga_dwmac_init() from probe altogether , the dwmac
>>> core code will call plat_dat->init at the end of probe .
>>>
>>> So shall we do that ? I am happy to spin V3 like that if you confirm
>>> that it's legal to do things in the aforementioned order.
>>>
>>
>> AFAICT, I don't see any reason why the socfpga_dwmac_init() has to go
>> before the stmmac_dvr_probe(). I tested this by using U-Boot to put the
>> PHY modes in the system manager into a different mode, and put the
>> ethernet IP into reset. Linux was able to use ethernet just fine with
>> the aformentioned order.
> 
> Ha, the dwmac code does not call the ->init, so you have to call it from
> the socfpga-dwmac probe afterall. I will send a V3 now and do
> it just like you suggested. I will send a RFC for calling ->init and
> ->exit from the stmmac common code too.
> 

Yes, I saw this too. Was going to wait until after this patch to
follow-up. Looks like you already did! Thanks!

Dinh

Re: [PATCH V3] net: stmmac: socfpga: Remove re-registration of reset controller

2016-04-21 Thread Dinh Nguyen



On 04/21/2016 07:11 AM, Marek Vasut wrote:
> Both socfpga_dwmac_parse_data() in dwmac-socfpga.c and stmmac_dvr_probe()
> in stmmac_main.c functions call devm_reset_control_get() to register an
> reset controller for the stmmac. This results in an attempt to register
> two reset controllers for the same non-shared reset line.
> 
> The first attempt to register the reset controller works fine. The second
> attempt fails with warning from the reset controller core, see below.
> The warning is produced because the reset line is non-shared and thus
> it is allowed to have only up-to one reset controller associated with
> that reset line, not two or more.
> 
> The solution has multiple parts. First, the original socfpga_dwmac_init()
> is tweaked to use reset controller pointer from the stmmac_priv (private
> data of the stmmac core) instead of the local instance, which was used
> before. The local re-registration of the reset controller is removed.
> 
> Next, the socfpga_dwmac_init() is moved after stmmac_dvr_probe() in the
> probe function. This order is legal according to Altera and it makes the
> code much easier, since there is no need to temporarily register and
> unregister the reset controller ; the reset controller is already registered
> by the stmmac_dvr_probe().
> 
> Finally, plat_dat->exit and socfpga_dwmac_exit() is no longer necessary,
> since the functionality is already performed by the stmmac core.
> 
> [ cut here ]
> WARNING: CPU: 0 PID: 1 at drivers/reset/core.c:187 
> __of_reset_control_get+0x218/0x270
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> 4.6.0-rc4-next-20160419-00015-gabb2477-dirty #4
> Hardware name: Altera SOCFPGA
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x94/0xa8)
> [] (dump_stack) from [] (__warn+0xec/0x104)
> [] (__warn) from [] (warn_slowpath_null+0x20/0x28)
> [] (warn_slowpath_null) from [] 
> (__of_reset_control_get+0x218/0x270)
> [] (__of_reset_control_get) from [] 
> (__devm_reset_control_get+0x54/0x90)
> [] (__devm_reset_control_get) from [] 
> (stmmac_dvr_probe+0x1b4/0x8e8)
> [] (stmmac_dvr_probe) from [] 
> (socfpga_dwmac_probe+0x1b8/0x28c)
> [] (socfpga_dwmac_probe) from [] 
> (platform_drv_probe+0x4c/0xb0)
> [] (platform_drv_probe) from [] 
> (driver_probe_device+0x224/0x2bc)
> [] (driver_probe_device) from [] 
> (__driver_attach+0xac/0xb0)
> [] (__driver_attach) from [] (bus_for_each_dev+0x6c/0xa0)
> [] (bus_for_each_dev) from [] (bus_add_driver+0x1a4/0x21c)
> [] (bus_add_driver) from [] (driver_register+0x78/0xf8)
> [] (driver_register) from [] (do_one_initcall+0x40/0x170)
> [] (do_one_initcall) from [] 
> (kernel_init_freeable+0x1dc/0x27c)
> [] (kernel_init_freeable) from [] (kernel_init+0x8/0x114)
> [] (kernel_init) from [] (ret_from_fork+0x14/0x3c)
> ---[ end trace 059d2fbe87608fa9 ]---
> 
> Signed-off-by: Marek Vasut <ma...@denx.de>
> Cc: Matthew Gerlach <mgerl...@opensource.altera.com>
> Cc: Dinh Nguyen <dingu...@opensource.altera.com>
> Cc: David S. Miller <da...@davemloft.net>
> ---
> V2: Add missing stmmac_rst = NULL; into socfpga_dwmac_init_probe()
> V3: Greatly simplify the code by moving socfpga_dwmac_init() after
> stmmac_dvr_probe(), which is legal. This removes the need for
> temporary registration of the reset controller, which is super.
>

Tested-by: Dinh Nguyen <dingu...@opensource.altera.com>

Thanks,
Dinh

Re: [PATCH V2] net: stmmac: socfpga: Remove re-registration of reset controller

2016-04-20 Thread Dinh Nguyen



On 04/20/2016 05:27 PM, Marek Vasut wrote:
> On 04/20/2016 11:17 PM, Dinh Nguyen wrote:
>> On 04/19/2016 07:05 PM, Marek Vasut wrote:
>>> Both socfpga_dwmac_parse_data() in dwmac-socfpga.c and stmmac_dvr_probe()
>>> in stmmac_main.c functions call devm_reset_control_get() to register an
>>> reset controller for the stmmac. This results in an attempt to register
>>> two reset controllers for the same non-shared reset line.
>>>
>>> The first attempt to register the reset controller works fine. The second
>>> attempt fails with warning from the reset controller core, see below.
>>> The warning is produced because the reset line is non-shared and thus
>>> it is allowed to have only up-to one reset controller associated with
>>> that reset line, not two or more.
>>>
>>> The solution is not great. Since the hardware needs to toggle the reset
>>> before calling stmmac_dvr_probe() to perform mandatory preconfiguration,
>>> this patch splits socfpga_dwmac_init_probe() from socfpga_dwmac_init().
>>>
>>> The socfpga_dwmac_init_probe() temporarily registers the reset controller,
>>> performs the pre-configuration and unregisters the reset controller again.
>>> This function is only called from the socfpga_dwmac_probe().
>>>
>>> The original socfpga_dwmac_init() is tweaked to use reset controller
>>> pointer from the stmmac_priv (private data of the stmmac core) instead
>>> of the local instance, which was used before.
>>>
>>> Finally, plat_dat->exit and socfpga_dwmac_exit() is no longer necessary,
>>> since the functionality is already performed by the stmmac core.
>>>
>>> [ cut here ]
>>> WARNING: CPU: 0 PID: 1 at drivers/reset/core.c:187 
>>> __of_reset_control_get+0x218/0x270
>>> Modules linked in:
>>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
>>> 4.6.0-rc4-next-20160419-00015-gabb2477-dirty #4
>>> Hardware name: Altera SOCFPGA
>>> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
>>> [] (show_stack) from [] (dump_stack+0x94/0xa8)
>>> [] (dump_stack) from [] (__warn+0xec/0x104)
>>> [] (__warn) from [] (warn_slowpath_null+0x20/0x28)
>>> [] (warn_slowpath_null) from [] 
>>> (__of_reset_control_get+0x218/0x270)
>>> [] (__of_reset_control_get) from [] 
>>> (__devm_reset_control_get+0x54/0x90)
>>> [] (__devm_reset_control_get) from [] 
>>> (stmmac_dvr_probe+0x1b4/0x8e8)
>>> [] (stmmac_dvr_probe) from [] 
>>> (socfpga_dwmac_probe+0x1b8/0x28c)
>>> [] (socfpga_dwmac_probe) from [] 
>>> (platform_drv_probe+0x4c/0xb0)
>>> [] (platform_drv_probe) from [] 
>>> (driver_probe_device+0x224/0x2bc)
>>> [] (driver_probe_device) from [] 
>>> (__driver_attach+0xac/0xb0)
>>> [] (__driver_attach) from [] 
>>> (bus_for_each_dev+0x6c/0xa0)
>>> [] (bus_for_each_dev) from [] 
>>> (bus_add_driver+0x1a4/0x21c)
>>> [] (bus_add_driver) from [] (driver_register+0x78/0xf8)
>>> [] (driver_register) from [] 
>>> (do_one_initcall+0x40/0x170)
>>> [] (do_one_initcall) from [] 
>>> (kernel_init_freeable+0x1dc/0x27c)
>>> [] (kernel_init_freeable) from [] 
>>> (kernel_init+0x8/0x114)
>>> [] (kernel_init) from [] (ret_from_fork+0x14/0x3c)
>>> ---[ end trace 059d2fbe87608fa9 ]---
>>>
>>> Signed-off-by: Marek Vasut <ma...@denx.de>
>>> Cc: Matthew Gerlach <mgerl...@opensource.altera.com>
>>> Cc: Dinh Nguyen <dingu...@opensource.altera.com>
>>> Cc: David S. Miller <da...@davemloft.net>
>>> ---
>>> V2: Add missing stmmac_rst = NULL; into socfpga_dwmac_init_probe()
>>> ---
>>>  .../net/ethernet/stmicro/stmmac/dwmac-socfpga.c| 70 
>>> --
>>>  1 file changed, 39 insertions(+), 31 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c 
>>> b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
>>> index 76d671e..5885a2e 100644
>>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
>>> @@ -49,7 +49,6 @@ struct socfpga_dwmac {
>>> u32 reg_shift;
>>> struct  device *dev;
>>> struct regmap *sys_mgr_base_addr;
>>> -   struct reset_control *stmmac_rst;
>>> void __iomem *splitter_base;
>>> bool f2h_ptp_ref_clk;
>>>  };
>>> @@ -92,15 +91,6 @@ static int so

Re: [PATCH V2] net: stmmac: socfpga: Remove re-registration of reset controller

2016-04-20 Thread Dinh Nguyen

On 04/19/2016 07:05 PM, Marek Vasut wrote:
> Both socfpga_dwmac_parse_data() in dwmac-socfpga.c and stmmac_dvr_probe()
> in stmmac_main.c functions call devm_reset_control_get() to register an
> reset controller for the stmmac. This results in an attempt to register
> two reset controllers for the same non-shared reset line.
> 
> The first attempt to register the reset controller works fine. The second
> attempt fails with warning from the reset controller core, see below.
> The warning is produced because the reset line is non-shared and thus
> it is allowed to have only up-to one reset controller associated with
> that reset line, not two or more.
> 
> The solution is not great. Since the hardware needs to toggle the reset
> before calling stmmac_dvr_probe() to perform mandatory preconfiguration,
> this patch splits socfpga_dwmac_init_probe() from socfpga_dwmac_init().
> 
> The socfpga_dwmac_init_probe() temporarily registers the reset controller,
> performs the pre-configuration and unregisters the reset controller again.
> This function is only called from the socfpga_dwmac_probe().
> 
> The original socfpga_dwmac_init() is tweaked to use reset controller
> pointer from the stmmac_priv (private data of the stmmac core) instead
> of the local instance, which was used before.
> 
> Finally, plat_dat->exit and socfpga_dwmac_exit() is no longer necessary,
> since the functionality is already performed by the stmmac core.
> 
> [ cut here ]
> WARNING: CPU: 0 PID: 1 at drivers/reset/core.c:187 
> __of_reset_control_get+0x218/0x270
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> 4.6.0-rc4-next-20160419-00015-gabb2477-dirty #4
> Hardware name: Altera SOCFPGA
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x94/0xa8)
> [] (dump_stack) from [] (__warn+0xec/0x104)
> [] (__warn) from [] (warn_slowpath_null+0x20/0x28)
> [] (warn_slowpath_null) from [] 
> (__of_reset_control_get+0x218/0x270)
> [] (__of_reset_control_get) from [] 
> (__devm_reset_control_get+0x54/0x90)
> [] (__devm_reset_control_get) from [] 
> (stmmac_dvr_probe+0x1b4/0x8e8)
> [] (stmmac_dvr_probe) from [] 
> (socfpga_dwmac_probe+0x1b8/0x28c)
> [] (socfpga_dwmac_probe) from [] 
> (platform_drv_probe+0x4c/0xb0)
> [] (platform_drv_probe) from [] 
> (driver_probe_device+0x224/0x2bc)
> [] (driver_probe_device) from [] 
> (__driver_attach+0xac/0xb0)
> [] (__driver_attach) from [] (bus_for_each_dev+0x6c/0xa0)
> [] (bus_for_each_dev) from [] (bus_add_driver+0x1a4/0x21c)
> [] (bus_add_driver) from [] (driver_register+0x78/0xf8)
> [] (driver_register) from [] (do_one_initcall+0x40/0x170)
> [] (do_one_initcall) from [] 
> (kernel_init_freeable+0x1dc/0x27c)
> [] (kernel_init_freeable) from [] (kernel_init+0x8/0x114)
> [] (kernel_init) from [] (ret_from_fork+0x14/0x3c)
> ---[ end trace 059d2fbe87608fa9 ]---
> 
> Signed-off-by: Marek Vasut <ma...@denx.de>
> Cc: Matthew Gerlach <mgerl...@opensource.altera.com>
> Cc: Dinh Nguyen <dingu...@opensource.altera.com>
> Cc: David S. Miller <da...@davemloft.net>
> ---
> V2: Add missing stmmac_rst = NULL; into socfpga_dwmac_init_probe()
> ---
>  .../net/ethernet/stmicro/stmmac/dwmac-socfpga.c| 70 
> --
>  1 file changed, 39 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c 
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> index 76d671e..5885a2e 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> @@ -49,7 +49,6 @@ struct socfpga_dwmac {
>   u32 reg_shift;
>   struct  device *dev;
>   struct regmap *sys_mgr_base_addr;
> - struct reset_control *stmmac_rst;
>   void __iomem *splitter_base;
>   bool f2h_ptp_ref_clk;
>  };
> @@ -92,15 +91,6 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac 
> *dwmac, struct device *
>   struct device_node *np_splitter;
>   struct resource res_splitter;
>  
> - dwmac->stmmac_rst = devm_reset_control_get(dev,
> -   STMMAC_RESOURCE_NAME);
> - if (IS_ERR(dwmac->stmmac_rst)) {
> - dev_info(dev, "Could not get reset control!\n");
> - if (PTR_ERR(dwmac->stmmac_rst) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> - dwmac->stmmac_rst = NULL;
> - }
> -
>   dwmac->interface = of_get_phy_mode(np);
>  
>   sys_mgr_base_addr = syscon_regmap_lookup_by_phandle(np, 
> "altr,sysmgr-syscon");
> @@ -194,30 +184,23 @@ static int socfpga_dwm

Re: [PATCH V2] net: stmmac: socfpga: Remove re-registration of reset controller

2016-04-19 Thread Dinh Nguyen



On 04/19/2016 07:05 PM, Marek Vasut wrote:
> Both socfpga_dwmac_parse_data() in dwmac-socfpga.c and stmmac_dvr_probe()
> in stmmac_main.c functions call devm_reset_control_get() to register an
> reset controller for the stmmac. This results in an attempt to register
> two reset controllers for the same non-shared reset line.
> 
> The first attempt to register the reset controller works fine. The second
> attempt fails with warning from the reset controller core, see below.
> The warning is produced because the reset line is non-shared and thus
> it is allowed to have only up-to one reset controller associated with
> that reset line, not two or more.
> 
> The solution is not great. Since the hardware needs to toggle the reset
> before calling stmmac_dvr_probe() to perform mandatory preconfiguration,
> this patch splits socfpga_dwmac_init_probe() from socfpga_dwmac_init().
> 
> The socfpga_dwmac_init_probe() temporarily registers the reset controller,
> performs the pre-configuration and unregisters the reset controller again.
> This function is only called from the socfpga_dwmac_probe().
> 
> The original socfpga_dwmac_init() is tweaked to use reset controller
> pointer from the stmmac_priv (private data of the stmmac core) instead
> of the local instance, which was used before.
> 
> Finally, plat_dat->exit and socfpga_dwmac_exit() is no longer necessary,
> since the functionality is already performed by the stmmac core.
> 
> [ cut here ]
> WARNING: CPU: 0 PID: 1 at drivers/reset/core.c:187 
> __of_reset_control_get+0x218/0x270
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> 4.6.0-rc4-next-20160419-00015-gabb2477-dirty #4
> Hardware name: Altera SOCFPGA
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x94/0xa8)
> [] (dump_stack) from [] (__warn+0xec/0x104)
> [] (__warn) from [] (warn_slowpath_null+0x20/0x28)
> [] (warn_slowpath_null) from [] 
> (__of_reset_control_get+0x218/0x270)
> [] (__of_reset_control_get) from [] 
> (__devm_reset_control_get+0x54/0x90)
> [] (__devm_reset_control_get) from [] 
> (stmmac_dvr_probe+0x1b4/0x8e8)
> [] (stmmac_dvr_probe) from [] 
> (socfpga_dwmac_probe+0x1b8/0x28c)
> [] (socfpga_dwmac_probe) from [] 
> (platform_drv_probe+0x4c/0xb0)
> [] (platform_drv_probe) from [] 
> (driver_probe_device+0x224/0x2bc)
> [] (driver_probe_device) from [] 
> (__driver_attach+0xac/0xb0)
> [] (__driver_attach) from [] (bus_for_each_dev+0x6c/0xa0)
> [] (bus_for_each_dev) from [] (bus_add_driver+0x1a4/0x21c)
> [] (bus_add_driver) from [] (driver_register+0x78/0xf8)
> [] (driver_register) from [] (do_one_initcall+0x40/0x170)
> [] (do_one_initcall) from [] 
> (kernel_init_freeable+0x1dc/0x27c)
> [] (kernel_init_freeable) from [] (kernel_init+0x8/0x114)
> [] (kernel_init) from [] (ret_from_fork+0x14/0x3c)
> ---[ end trace 059d2fbe87608fa9 ]---
> 

Odd, I hadn't seen this error before. I would have noticed it, but I
haven't ran linux-next for a few days.

I see that this error was introduced on linux-next/next-20160414. The
error was not there prior to that. While I agree that the extra call to
get the reset control is not needed, I wonder what commit between
next-20160413 and next-20160414 exposed this error. I'll try to dig this
some more.

Dinh

Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement

2016-03-30 Thread Dinh Nguyen

On Tue, Mar 15, 2016 at 7:36 AM, Giuseppe CAVALLARO
 wrote:
> Hello Tomeu
>
> On 3/15/2016 8:23 AM, Tomeu Vizoso wrote:
>>
>> Thanks.
>>
>> Btw, I have rebased on top of 4.5 this morning and I have noticed that
>> 88f8b1bb41c6 ("stmmac: Fix 'eth0: No PHY found' regression") got in
>> there, so I guess we have now a bunch of boards with broken network on
>> that release:(
>
>
>
> This is the status on my side: I am testing on an HW that has the
> Enhanced descriptors and all works fine.
>
> On this HW, if I force the driver to use the normal descriptor
> layout, I meet problems but using both net.git and net-next.
> So I suspect I cannot ply with this HW forcing the normal descriptors.
> But! That is helping me to check if, on net-next, the stmmac is
> actually  programming fine the normal desc case.
> I have just found another fix so I kindly ask you to apply the temp
> patch  attached and let me know.
> In details, I have noticed that the OWN bit was not set in the right
> TDES0.
>
> I also ask you to give me a log of the kernel where the stmmac was
> running fine. I would like to see which configuration it is selected
> at runtime by the driver on your box.
> From your previous logs (where the stmmac failed), it seems that
> the  problem is on normal desc but, to be honest, this is the first
> case I see a 3.50a with HW capability register and w/o Enhanced
> descriptors.
>

Are you still working on a fix for:

[1.196110] libphy: PHY stmmac-0: not found
[1.200972] eth0: Could not attach to PHY
[1.204991] stmmac_open: Cannot attach to PHY (error: -19)

I see the error still there as of linux-next 20160330.

Dinh

Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement

2016-03-10 Thread Dinh Nguyen

On Thu, Mar 10, 2016 at 3:13 AM, Giuseppe CAVALLARO
<peppe.cavall...@st.com> wrote:
> On 3/9/2016 5:31 PM, Dinh Nguyen wrote:
>>
>> On Wed, Mar 9, 2016 at 8:53 AM, Giuseppe CAVALLARO
>> <peppe.cavall...@st.com> wrote:
>>>
>>> Hi Tomeu, Dinh, Andreas
>>>
>>> I need a sum and help from you to go ahead on the
>>> tx timeout.
>>>
>>> The "stmmac: MDIO fixes" seems to be the candidate to
>>> fix the phy connection and I will send the V2 asap (Andreas' comment).
>>>
>>> So, supposing the probe is ok and phy is connected,
>>> I need your input ...
>>>
>>>   Tomeu: after revering the 0e80bdc9a72d (stmmac: first frame
>>>  prep at the end of xmit routine) the network is
>>>  not stable and there is a timeout after a while.
>>>  The box has 3.50 with normal desc settings.
>>>
>>>   Dinh: the network is ok, I wonder if you can share a boot
>>> log just to understand if the normal or enhanced
>>> descriptors are used.
>>>
>>
>> Here it is:
>
> ...
>>
>> [0.850523] stmmac - user ID: 0x10, Synopsys ID: 0x37
>> [0.855570]  Ring mode enabled
>> [0.858611]  DMA HW capability register supported
>> [0.863128]  Enhanced/Alternate descriptors
>> [0.867482]  Enabled extended descriptors
>> [0.871482]  RX Checksum Offload Engine supported (type 2)
>> [0.876948]  TX Checksum insertion supported
>> [0.881204]  Enable RX Mitigation via HW Watchdog Timer
>> [0.886863] socfpga-dwmac ff702000.ethernet eth0: No MDIO subnode found
>> [0.899090] libphy: stmmac: probed
>> [0.902484] eth0: PHY ID 00221611 at 4 IRQ POLL (stmmac-0:04) active
>
>
> Thx Dinh, so you are using the Enhanced/Alternate descriptors
> I am debugging on my side on a setup with normal descriptors, I let you
> know
>

Doesn't the printout "Enhanced/Alternate descriptors"  mean that I'm using
Enhanced/Alternate descriptors?

Dinh

Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement

2016-03-09 Thread Dinh Nguyen

On Wed, Mar 9, 2016 at 8:53 AM, Giuseppe CAVALLARO
 wrote:
> Hi Tomeu, Dinh, Andreas
>
> I need a sum and help from you to go ahead on the
> tx timeout.
>
> The "stmmac: MDIO fixes" seems to be the candidate to
> fix the phy connection and I will send the V2 asap (Andreas' comment).
>
> So, supposing the probe is ok and phy is connected,
> I need your input ...
>
>  Tomeu: after revering the 0e80bdc9a72d (stmmac: first frame
> prep at the end of xmit routine) the network is
> not stable and there is a timeout after a while.
> The box has 3.50 with normal desc settings.
>
>  Dinh: the network is ok, I wonder if you can share a boot
>log just to understand if the normal or enhanced
>descriptors are used.
>

Here it is:

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.5.0-rc6-next-20160304-1-g092eb23
(dinguyen@linux-builds1) (gcc version 4.7.3 2013022
6 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2013.03-20130313 -
Linaro GCC 2013.03) ) #1 SMP Wed Mar 9 10:22:14 CST 2
016
[0.00] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[0.00] Machine model: Altera SOCFPGA Cyclone V SoC Development Kit
[0.00] cma: Reserved 64 MiB at 0x3c00
[0.00] Memory policy: Data cache writealloc
[0.00] PERCPU: Embedded 13 pages/cpu @ef7cc000 s23808 r8192
d21248 u53248
[0.00] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 260608
[0.00] Kernel command line: console=ttyS0,115200
root=/dev/mmcblk0p2 rw rootwait ip=dhcp
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 955932K/1048576K available (9522K kernel code,
1142K rwdata, 4124K rodata, 2048K init, 342K bss,
 27108K reserved, 65536K cma-reserved, 196608K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xf080 - 0xff80   ( 240 MB)
[0.00] lowmem  : 0xc000 - 0xf000   ( 768 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0xc0208000 - 0xc1053830   (14639 kB)
[0.00]   .init : 0xc110 - 0xc130   (2048 kB)
[0.00]   .data : 0xc130 - 0xc141da80   (1143 kB)
[0.00].bss : 0xc141f000 - 0xc1474920   ( 343 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[0.00] Hierarchical RCU implementation.
[0.00]  Build-time adjustment of leaf fanout to 32.
[0.00]  RCU restricting CPUs from NR_CPUS=16 to nr_cpu_ids=2.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] L2C-310 erratum 769419 enabled
[0.00] L2C-310 enabling early BRESP for Cortex-A9
[0.00] L2C-310 full line of zeros enabled for Cortex-A9
[0.00] L2C-310 ID prefetch enabled, offset 1 lines
[0.00] L2C-310 dynamic clock gating enabled, standby mode enabled
[0.00] L2C-310 cache controller enabled, 8 ways, 512 kB
[0.00] L2C-310: CACHE_ID 0x410030c9, AUX_CTRL 0x76060001
[0.00] clocksource: timer1: mask: 0x max_cycles:
0x, max_idle_ns: 19112604467 ns
[0.05] sched_clock: 32 bits at 100MHz, resolution 10ns, wraps
every 21474836475ns
[0.15] Switching to timer-based delay loop, resolution 10ns
[0.000268] Console: colour dummy device 80x30
[0.000290] Calibrating delay loop (skipped), value calculated
using timer frequency.. 200.00 BogoMIPS (lpj=50)
[0.000301] pid_max: default: 32768 minimum: 301
[0.000374] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.000382] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.000879] CPU: Testing write buffer coherency: ok
[0.001062] CPU0: thread -1, cpu 0, socket 0, mpidr 8000
[0.001207] Setting up static identity map for 0x30 - 0x300098
[0.003872] CPU1: thread -1, cpu 1, socket 0, mpidr 8001
[0.003946] Brought up 2 CPUs
[0.003959] SMP: Total of 2 processors activated (400.00 BogoMIPS).
[0.003965] CPU: All CPU(s) started in SVC mode.
[0.004672] devtmpfs: initialized
[0.008193] VFP support v0.3: implementor 41 architecture 3 part 30
variant 9 rev 4
[0.008609] clocksource: jiffies: mask: 0x max_cycles:
0x, max_idle_ns: 9556302231375000 ns
[0.011733] pinctrl core: initialized pinctrl subsystem
[0.013149] NET: Registered protocol family 16
[

Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement

2016-03-08 Thread Dinh Nguyen

On Tue, Mar 8, 2016 at 1:24 AM, Giuseppe CAVALLARO
<peppe.cavall...@st.com> wrote:
> Hi Dinh,
>
> On 3/8/2016 12:22 AM, Dinh Nguyen wrote:
> [snip]
>>
>>
>> I'm seeing the same issue on the SoCFPGA platform:
>>
>> libphy: PHY stmmac-0: not found
>> eth0: Could not attach to PHY
>> stmmac_open: Cannot attach to PHY (error: -19)
>>
>> If I just revert:
>>
>>   "stmmac: Fix 'eth0: No PHY found' regression"
>>
>> then the issue goes away.
>
>
> do you have this patch "stmmac: first frame prep at the end of xmit routine"
> ? Or you just reverted
>   "stmmac: Fix 'eth0: No PHY found' regression"

I only reverted "stmmac: Fix 'eth0: No PHY found' regression". I do have the
patch "stmmac: first frame prep at the end of the xmit routine", but I did not
need to revert that patch.

Dinh

Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement

2016-03-07 Thread Dinh Nguyen

On Mon, Mar 7, 2016 at 11:15 AM, Andreas Färber  wrote:
> Am 07.03.2016 um 16:52 schrieb Giuseppe CAVALLARO:
>> On 3/7/2016 4:46 PM, Andreas Färber wrote:
>>> Am 07.03.2016 um 16:09 schrieb Giuseppe CAVALLARO:
 On 3/7/2016 3:27 PM, Andreas Färber wrote:
> Indeed, reverting Gabriel's commit fixes the observed error messages
>>> [...]
> However, I am unable to ping any hosts on the network now.

 hmm, this could be another problem. I wonder if you can
 check which recent patch is introducing the problem on ARM64.
 For example if this depends on Oct_2015 update.
>>>
>>> I've had success reverting drivers/net/ethernet/stmicro/ up to and
>>> including "stmmac: first frame prep at the end of xmit routine", i.e.
>>> top 7 commits.
>>
>> Andreas, I will check it and let you know asap.
>
> I verified that it's just these two commits that I need to revert:
>
> "stmmac: Fix 'eth0: No PHY found' regression"
> "stmmac: first frame prep at the end of xmit routine"
>
> Those in between don't cause conflicts and seem to work okay.
>

I'm seeing the same issue on the SoCFPGA platform:

libphy: PHY stmmac-0: not found
eth0: Could not attach to PHY
stmmac_open: Cannot attach to PHY (error: -19)

If I just revert:

 "stmmac: Fix 'eth0: No PHY found' regression"

then the issue goes away.

Thanks,
Dinh

Re: commit e34d65696d2e broke stmmac ethernet on socfpga

2016-01-04 Thread Dinh Nguyen

On 01/01/2016 02:49 AM, Romain Perier wrote:
> Hi all,
> 
> Same here on rockchip.
> See "[PATCH] stmmac: Don't exit mdio registration when mdio subnode is
> not found in the DTS"
> 
> Regards,
> Romain
> 
> 2015-12-18 18:45 GMT+01:00 Dinh Nguyen <dingu...@opensource.altera.com>:
>> Hi,
>>
>> It appears that commit e34d65696d2e 'stmmac: create of compatible mdio
>> bus for
>> stmmac driver' is causing this error on the SoCFPGA platform:
>>
>> [1.767246] libphy: PHY stmmac-0: not found
>> [1.772106] eth0: Could not attach to PHY
>> [1.776129] stmmac_open: Cannot attach to PHY (error: -19)
>> [1.781590] IP-Config: Failed to open eth0
>> [1.785681] IP-Config: No network devices available
>>
>> Doing a revert of this commit fixes the issue. Will try to debug further.
>>

There error is here:

[0.663275] socfpga-dwmac ff702000.ethernet eth0: NO MDIO subnode

It appears that his commit requires an update to DTS files, which will
subsequently break legacy DTS.

Also, this commit is only in linux-next.

Dinh

--
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

commit e34d65696d2e broke stmmac ethernet on socfpga

2015-12-18 Thread Dinh Nguyen

Hi,

It appears that commit e34d65696d2e 'stmmac: create of compatible mdio
bus for
stmmac driver' is causing this error on the SoCFPGA platform:

[1.767246] libphy: PHY stmmac-0: not found
[1.772106] eth0: Could not attach to PHY
[1.776129] stmmac_open: Cannot attach to PHY (error: -19)
[1.781590] IP-Config: Failed to open eth0
[1.785681] IP-Config: No network devices available

Doing a revert of this commit fixes the issue. Will try to debug further.

Thanks,
Dinh
--
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

Re: [PATCH v6 4/4] stmmac: socfpga: Provide dt node to config ptp clk source.

2015-12-14 Thread Dinh Nguyen

On Sun, Dec 13, 2015 at 9:32 PM, Phil Reid <pr...@electromag.com.au> wrote:
> Provides an options to use the ptp clock routed from the Altera FPGA
> fabric. Instead of the defalt eosc1 clock connected to the ARM HPS core.
> This setting affects all emacs in the core as the ptp clock is common.
>
> Acked-by: Rob Herring <r...@kernel.org>
> Signed-off-by: Phil Reid <pr...@electromag.com.au>
> ---
>  Documentation/devicetree/bindings/net/socfpga-dwmac.txt | 2 ++
>  drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 9 +
>  2 files changed, 11 insertions(+)
>

Acked-by: Dinh Nguyen <dingu...@opensource.altera.com>

Dinh
--
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

Re: [PATCHv2 net] phy: micrel: Fix finding PHY properties in MAC node.

2015-12-09 Thread Dinh Nguyen

On 12/09/2015 12:56 PM, Andrew Lunn wrote:
> commit 8b63ec1837fa ("phylib: Make PHYs children of their MDIO bus,
> not the bus' parent.")  changed the parenting of PHY devices, making
> them a child of the MDIO bus, instead of the MAC device. This broken
> the Micrel PHY driver which has a deprecated feature of allowing PHY
> properties to be placed into the MAC node.
> 
> In order to find the MAC node, we need to walk up the tree of devices
> until we find one with an OF node attached.
> 
> Reported-by: Dinh Nguyen <dingu...@opensource.altera.com>
> Suggested-by: David Daney <david.da...@cavium.com>
> Acked-by: David Daney <david.da...@cavium.com>
> Fixes: 8b63ec1837fa ("phylib: Make PHYs children of their MDIO bus, not the 
> bus' parent.")
> Signed-off-by: Andrew Lunn <and...@lunn.ch>
> ---
> v2: Remove include of netdev.h
> ---

Feel free to add:

Tested-by: Dinh Nguyen <dingu...@opensource.altera.com>

Thanks,
Dinh

--
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

Re: SoCFPGA ethernet broken

2015-12-04 Thread Dinh Nguyen

Hi Andrew,

On Fri, 4 Dec 2015, Andrew Lunn wrote:

> On Fri, Dec 04, 2015 at 02:10:50AM +0100, Andrew Lunn wrote:
> > > > FWIW: My initial patch to address the failure worked with the original 
> > > > DTB.
> > > 
> > > Can I ask what patch are you referring to? I was sidetracked for a while
> > > on this issue, but I still see it failing as of v4.4-rc3. I'll try to
> > > get back to debugging this.
> > 
> > Hi Dinh
> > 
> > There are two different patches:
> > 
> > https://lkml.org/lkml/2015/10/16/669
> > 
> > and
> > 
> > https://www.mail-archive.com/netdev@vger.kernel.org/msg83183.html
> > 
> > Although the first one works, it keeps searching up and up and up, so
> > you could in theory put the phy properties a lot higher than the MAC.
> > 
> > The second patch restricts where it looks for the phy properties to
> > only the MAC. But it does not work. We would like to understand why it
> > does not work.
> 
> Hi Dinh
> 
> Please could you run this patch and let us know what it outputs.
> 
> Thanks
>   Andrew
> 
> diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
> index cf6312fafea5..d7ddc0bb0e7f 100644
> --- a/drivers/net/phy/micrel.c
> +++ b/drivers/net/phy/micrel.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -339,9 +340,19 @@ static int ksz9021_config_init(struct phy_device *phydev)
>  {
>   const struct device *dev = >dev;
>   const struct device_node *of_node = dev->of_node;
> + const struct device *dev_walker;
>  
> - if (!of_node && dev->parent->of_node)
> - of_node = dev->parent->of_node;
> + dev_info(dev, "dev->parent: %s\n", dev_name(dev->parent));
> + dev_info(dev, "phydev->attached_dev->dev: %s\n", 
> dev_name(>attached_dev->dev));
> +
> + dev_walker = >dev;
> + do {
> + of_node = dev_walker->of_node;
> + dev_info(dev, "walking: %s %p\n",
> +  dev_name(dev_walker), of_node);
> + dev_walker = dev_walker->parent;
> +
> + } while (!of_node && dev_walker);
>  
>   if (of_node) {
>   ksz9021_load_values_from_of(phydev, of_node,
> 

Here is the output from the above patch:

[1.042049] mmc0: new high speed SDHC card at address 
[1.048017] mmcblk0: mmc0: SU32G 29.7 GiB
[1.053506]  mmcblk0: p1 p2 p3 p4
[1.057708] dwc2 ffb4.usb: Configuration mismatch. Forcing host mode
[1.064418] dwc2 ffb4.usb: no platform data or transceiver defined
[1.070966] Micrel KSZ9021 Gigabit PHY stmmac-0:04: dev->parent: stmmac-0
[1.077746] Micrel KSZ9021 Gigabit PHY stmmac-0:04: 
phydev->attached_dev->dev: eth0
[1.085389] Micrel KSZ9021 Gigabit PHY stmmac-0:04: walking: stmmac-0:04   
(null)
[1.092841] Micrel KSZ9021 Gigabit PHY stmmac-0:04: walking: stmmac-0   
(null)
[1.100042] Micrel KSZ9021 Gigabit PHY stmmac-0:04: walking: 
ff702000.ethernet ef9f3538
[1.133638] Sending DHCP requests ..
[5.104138] socfpga-dwmac ff702000.ethernet eth0: Link is Up - 1Gbps/Full - 
flow control rx/tx

BR,
Dinh
--
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

Re: SoCFPGA ethernet broken

2015-12-03 Thread Dinh Nguyen

On 12/03/2015 03:23 PM, David Daney wrote:
> On 12/03/2015 12:48 PM, Pavel Machek wrote:
>> On Thu 2015-10-15 13:25:59, Florian Fainelli wrote:
>>> On 15/10/15 12:59, Dinh Nguyen wrote:
>>>> On 10/15/2015 03:03 PM, Florian Fainelli wrote:
>>>>> On 15/10/15 12:09, Dinh Nguyen wrote:
>>>>>> Hi,
>>>>>>
>>>>>> commit "8b63ec1837fa phylib: Make PHYs children of their MDIO bus,
>>>>>> not
>>>>>> the bus' parent." seems to have broken ethernet support for the
>>>>>> SoCFPGA
>>>>>> platform which is using the stmmac ethernet driver.
>>>>>
>>>>> It is not clear to me how this relates to what you are seeing yet.
>>>>>
>>>>>>
>>>>>> It appears that during DHCP, it cannot get an IP address. This only
>>>>>> happens if ethernet was not used by the bootloader to tftp an kernel
>>>>>> image. If I use the bootloader to tftp an image then ethernet is
>>>>>> working
>>>>>> fine. So I think the PHY is not getting enabled properly.
>>>>>>
>>>>>> If I revert this patch, then ethernet is back to working on the
>>>>>> platform.
>>>>>
>>>>> Is the Device Tree source for this platform available somewhere to
>>>>> look at?
>>>>>
>>>>
>>>> Yes, I'm using the DTS that is in the mainline:
>>>>
>>>> arch/arm/boot/dts/socfpga.dtsi
>>>> arch/arm/boot/dts/socfpga_cyclone5.dtsi
>>>> arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
>>>
>>> There are no PHY devices in any of these DTS files, instead there is the
>>> non-standard "phy-addr" property which is set to 0x supposedly
>>> to indicate that the MDIO bus should be scanned. This is likely part of
>>> your problem. The stmmac driver seems to be looking for "snps,phy-addr"
>>> and not "phy-addr", so I am not even clear how this is supposed to work,
>>> and the driver mentions this custom property is deprecated anyway.
>>>
>>> The core problem is in
>>> drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c::stmmac_mdio_register
>>> which manually detects the PHY, that is mostly fine, except that it does
>>> not really seem to work here for a reason that is still unclear to me.
>>>
>>> Your Ethernet PHYs need to be declared in Device Tree, see
>>> Documentation/devicetree/bindings/net/phy.txt
>>
>> While updating DTS might be good idea, I don't think you can simply
>> blame this on DTS. If it worked before the change, it is supposed to
>> work after the change, otherwise we call that change a "regression"
>> and revert the change.
> 
> FWIW: My initial patch to address the failure worked with the original DTB.
> 

Can I ask what patch are you referring to? I was sidetracked for a while
on this issue, but I still see it failing as of v4.4-rc3. I'll try to
get back to debugging this.

Dinh

--
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

Re: SoCFPGA ethernet broken

2015-10-19 Thread Dinh Nguyen

+CC Giuseppe Cavallaro
+CC STi and Rockchip Maintainers

This is approaching beyond my breadth of knowledge on this subject, so I just
wanted to get some further insight.

On Fri, 16 Oct 2015, Andrew Lunn wrote:

> > > Maybe we need to walk up the hierarchy.
> > > 
> > > Perhaps something like:
> > > 
> > > const struct device *dev_walker;
> > > 
> > > dev_walker = >dev;
> > > do {
> > >of_node = dev_walker->of_node;
> > >dev_walker = dev_walker->parent;
> > > } while (!of_node && dev_walker);
> > > 
> > 
> > The above code seems to have fixed the issue.
> 
> What i don't like about this is that it allows you to put these
> properties in the mdio device node. These are phy properties, not mdio
> properties
>

AFAICT, the stmmac driver is allowing for the phy node to be part of the mdio.
In the function, stmmac_init_phy(), there is a separate check of a standalone
phy_node, and the case where the phy is part of the mdio.

commit "8b63ec1837fa phylib: Make PHYs children of their MDIO bus, not
the bus' parent." is now placing a hard requirement to have a PHY as a
separate node. For now this is only breaking SoCFPGA, but perhaps might
have affected STi41x and RockChip, but maybe haven't been spotted because
perhaps the testing has the bootloader setting up the PHYs?

> If phydev->attached_dev->dev->of_node works, that would be my
> preference.
>

BR,
Dinh
--
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

Re: [PATCH] net/phy: micrel: Follow attached_dev to get to the MAC device

2015-10-18 Thread Dinh Nguyen

On Sat, 17 Oct 2015, Dinh Nguyen wrote:

> On Sat, 17 Oct 2015, Andrew Lunn wrote:
> 
> > > Sure, will try to debug. It looks like phydev->attached_dev is valid, but
> > > phydev->attached_dev->dev.of_node is NULL.
> > 
> > Humm
> > 
> > phydev->attached_dev is a net_device, so should be the mac.  What
> > device is phydev->attached_dev->dev? Is it not the dev embedded in the
> > platform_device passed to socfpga_dwmac_probe()?
> >
> 
> Yes, it looks like it is, the dev->of_node is valid in socfpga_dwmac_probe(),
> but it looks like of_node is getting lost somewhere. 
> 

Do you know why this happening? In ksz9021_config_init():

@@ -345,7 +345,11 @@ static int ksz9021_config_init(struct phy_device *phydev)
phydev->attached_dev->dev.of_node)
of_node = phydev->attached_dev->dev.of_node;

+   printk("%s %08x\n", __func__, phydev->attached_dev->dev.of_node);
+   printk("%s %08x %08x\n", __func__, phydev->attached_dev->dev, 
phydev->attached_dev->dev.of_node);


[1.923311] ksz9021_config_init 
[1.927224] ksz9021_config_init eedc0210 ee401680

The first printout shows phydev->attached_dev->dev.of_node is NULL. but the
second printout, where I'm also printing out phydev->attached_dev->dev, then
phydev->attached_dev->dev.of_node is not NULL.

BR,
Dinh
--
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

Re: [PATCH] net/phy: micrel: Follow attached_dev to get to the MAC device

2015-10-17 Thread Dinh Nguyen

On Sat, 17 Oct 2015, Andrew Lunn wrote:

> > Sure, will try to debug. It looks like phydev->attached_dev is valid, but
> > phydev->attached_dev->dev.of_node is NULL.
> 
> Humm
> 
> phydev->attached_dev is a net_device, so should be the mac.  What
> device is phydev->attached_dev->dev? Is it not the dev embedded in the
> platform_device passed to socfpga_dwmac_probe()?
>

Yes, it looks like it is, the dev->of_node is valid in socfpga_dwmac_probe(),
but it looks like of_node is getting lost somewhere. 

BR,
Dinh
--
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

Re: [PATCH] net/phy: micrel: Follow attached_dev to get to the MAC device

2015-10-17 Thread Dinh Nguyen

On Fri, 16 Oct 2015, Andrew Lunn wrote:

> On Fri, Oct 16, 2015 at 05:58:41PM -0500, Dinh Nguyen wrote:
> > On Fri, 16 Oct 2015, Andrew Lunn wrote:
> > 
> > > Commit "8b63ec1837fa phylib: Make PHYs children of their MDIO bus, not
> > > the bus' parent." broke finding PHY properties in the MAC device tree
> > > node. The parent device is now the MDIO bus, not the MAC. Use
> > > attached_dev towards the MAC device tree node.
> > > 
> > > Fixes: 8b63ec1837fa ("phylib: Make PHYs children of their MDIO bus, not 
> > > the bus' parent.")
> > > Signed-off-by: Andrew Lunn <and...@lunn.ch>
> > > ---
> > > 
> > > Compile tested only.
> > > 
> > > Dinh, please could you test it and report back if it works or not.
> > >
> > 
> > This patch did not seem to fix the problem. The following code did seem to
> > fix the problem:
> > 
> > if (!of_node && dev->parent->of_node)
> > -   of_node = dev->parent->of_node;
> > +   do {
> > +   of_node = dev->of_node;
> > +   dev = dev->parent;
> > +   i++;
> > +   } while (!of_node && dev);
> 
> This might fix the issue, but it has disadvantages. As i said before,
> it allows people to place phy properties into the mdio device node. We
> want to be reducing placing you can add phy properties, not adding
> more.
> 
> Please could you try to debug why my patch did not work. Is
> attached_dev null?
>

Sure, will try to debug. It looks like phydev->attached_dev is valid, but
phydev->attached_dev->dev.of_node is NULL.
 

BR,
Dinh
--
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

Re: [PATCH] net/phy: micrel: Follow attached_dev to get to the MAC device

2015-10-17 Thread Dinh Nguyen

On Sat, 17 Oct 2015, Dinh Nguyen wrote:

> On Fri, 16 Oct 2015, Andrew Lunn wrote:
> 
> > On Fri, Oct 16, 2015 at 05:58:41PM -0500, Dinh Nguyen wrote:
> > > On Fri, 16 Oct 2015, Andrew Lunn wrote:
> > > 
> > > > Commit "8b63ec1837fa phylib: Make PHYs children of their MDIO bus, not
> > > > the bus' parent." broke finding PHY properties in the MAC device tree
> > > > node. The parent device is now the MDIO bus, not the MAC. Use
> > > > attached_dev towards the MAC device tree node.
> > > > 
> > > > Fixes: 8b63ec1837fa ("phylib: Make PHYs children of their MDIO bus, not 
> > > > the bus' parent.")
> > > > Signed-off-by: Andrew Lunn <and...@lunn.ch>
> > > > ---
> > > > 
> > > > Compile tested only.
> > > > 
> > > > Dinh, please could you test it and report back if it works or not.
> > > >
> > > 
> > > This patch did not seem to fix the problem. The following code did seem to
> > > fix the problem:
> > > 
> > >   if (!of_node && dev->parent->of_node)
> > > -   of_node = dev->parent->of_node;
> > > +   do {
> > > +   of_node = dev->of_node;
> > > +   dev = dev->parent;
> > > +   i++;
> > > +   } while (!of_node && dev);
> > 
> > This might fix the issue, but it has disadvantages. As i said before,
> > it allows people to place phy properties into the mdio device node. We
> > want to be reducing placing you can add phy properties, not adding
> > more.
> >

I've also tried creating a separate phy node in the DTS and have the EMAC
point the PHY with a 'phy = <>;', but that also didn't seem to work with
your patch.
 
> 
> Sure, will try to debug. It looks like phydev->attached_dev is valid, but
> phydev->attached_dev->dev.of_node is NULL.
>  
> 
> BR,
> Dinh
> 

BR,
Dinh
--
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

Re: SoCFPGA ethernet broken

2015-10-16 Thread Dinh Nguyen

On Fri, 16 Oct 2015, David Daney wrote:

> On 10/16/2015 08:56 AM, Andrew Lunn wrote:
> > > So I think I'll move to inspect what Florian had suggested, and that was
> > > to look
> > > at:
> > > drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c::stmmac_mdio_register
> > 
> > I have a suspicion. If you look at the phy driver it does:
> > 
> > static int ksz9021_config_init(struct phy_device *phydev)
> > {
> >  const struct device *dev = >dev;
> >  const struct device_node *of_node = dev->of_node;
> > 
> >  if (!of_node && dev->parent->of_node)
> >  of_node = dev->parent->of_node;
> > 
> 
> Maybe we need to walk up the hierarchy.
> 
> Perhaps something like:
> 
> const struct device *dev_walker;
> 
> dev_walker = >dev;
> do {
>of_node = dev_walker->of_node;
>dev_walker = dev_walker->parent;
> } while (!of_node && dev_walker);
> 

The above code seems to have fixed the issue.

> An alternative would be to assign the bus the same of_node as the bus parent.
> 
> If either approach works, you can add:
>  Acked-by: David Daney 
> 
> to the patch that implements it.
> 
> > 
> > In your case, you don't have a phy node in your device tree, so of_node
> > is NULL. So it looks in the parent device.
> > 
> >  phylib: Make PHYs children of their MDIO bus, not the bus' parent.
> > 
> > changed what the parent is. It is now the mdio device. Before, i
> > suspect it was the MAC. Hence it found your properties in the MAC
> > node.
> > 
> > What i think you might want to do is change this code. Rather than
> > look a dev->parent->of_node; you might want
> > phydev->attached_dev->dev->of_node.
> > 
> > This assumes the phy has been attached to the MAC. I've no idea of the
> > ordering, so maybe it has not been attached yet?
> > 
> > dp83867.c has similar code. However quick grep did not find any
> > mainline users with properties in the MAC node. If that is true, i
> > would suggest removing the code looking in the parent for that phy
> > driver.
> > 
> > Andrew
> > 
> 
> 

BR,
Dinh
--
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

Re: SoCFPGA ethernet broken

2015-10-16 Thread Dinh Nguyen

On Fri, 16 Oct 2015, Andrew Lunn wrote:

> On Fri, Oct 16, 2015 at 09:38:37AM -0500, Dinh Nguyen wrote:
> > On Fri, 16 Oct 2015, Andrew Lunn wrote:
> > 
> > > > Another debugging point, the SoCFPGA board has a Micrel ksz9021 PHY 
> > > > attached
> > > > to the ethernet port. What I'm seeing is that with 8b63ec1837fa patch, 
> > > > when
> > > > the call to ksz9021_config_init() is made both of_node and 
> > > > dev->parent->of_node
> > > > are NULL, without the patch the dev->parent->of_node is a valid 
> > > > pointer. Thus
> > > > the skew values get programmed to the phy.
> > > 
> > > Ah!
> > > 
> > > You have the phy device tree parameters in the wrong place. These are
> > > phy paramters, so should really be in the phy node. But
> > > socfpga_cyclone5_socdk.dts has them in the MAC node.
> > >
> > 
> > Alright, let me see if I can rework the DTS.
> 
> Well, we are not supposed to break device tree bindings. So we should
> try to make this work again.
>  

Great..thanks for recognizing that point.
 
> > > There is nothing in Documentation/devicetree/bindings/net/micrel.txt
> > > which says you are allowed to place them in the MAC node. Obviously
> > > the code did allow this, which is what has now broken.
> > 
> > I was following Documentation/devicetree/bindings/net/micrel-ksz90x1.txt and
> > in this document I was following the autodetected PHY example. Did I 
> > mis-interpret
> > the example?
> 
> I was looking at the wrong binding documentation. So yes, it is
> documented you can do this.
> 
> But i still think it is wrong. These are phy properties, implemented
> by the phy, so should be in the phy node. So moving them would be
> good. But as i said, we should fix backwards compatibility if
> possible.
>

I moved the phy settings to a separate phy node, but it did not seem to make a
difference at all.

So I think I'll move to inspect what Florian had suggested, and that was to look
at: drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c::stmmac_mdio_register 

BR,
Dinh
--
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

Re: [PATCH] net/phy: micrel: Follow attached_dev to get to the MAC device

2015-10-16 Thread Dinh Nguyen

On Fri, 16 Oct 2015, Andrew Lunn wrote:

> Commit "8b63ec1837fa phylib: Make PHYs children of their MDIO bus, not
> the bus' parent." broke finding PHY properties in the MAC device tree
> node. The parent device is now the MDIO bus, not the MAC. Use
> attached_dev towards the MAC device tree node.
> 
> Fixes: 8b63ec1837fa ("phylib: Make PHYs children of their MDIO bus, not the 
> bus' parent.")
> Signed-off-by: Andrew Lunn 
> ---
> 
> Compile tested only.
> 
> Dinh, please could you test it and report back if it works or not.
>

This patch did not seem to fix the problem. The following code did seem to
fix the problem:

if (!of_node && dev->parent->of_node)
-   of_node = dev->parent->of_node;
+   do {
+   of_node = dev->of_node;
+   dev = dev->parent;
+   i++;
+   } while (!of_node && dev);

BR,
Dinh
--
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

Re: SoCFPGA ethernet broken

2015-10-15 Thread Dinh Nguyen

On 10/15/2015 03:03 PM, Florian Fainelli wrote:
> On 15/10/15 12:09, Dinh Nguyen wrote:
>> Hi,
>>
>> commit "8b63ec1837fa phylib: Make PHYs children of their MDIO bus, not
>> the bus' parent." seems to have broken ethernet support for the SoCFPGA
>> platform which is using the stmmac ethernet driver.
> 
> It is not clear to me how this relates to what you are seeing yet.
> 
>>
>> It appears that during DHCP, it cannot get an IP address. This only
>> happens if ethernet was not used by the bootloader to tftp an kernel
>> image. If I use the bootloader to tftp an image then ethernet is working
>> fine. So I think the PHY is not getting enabled properly.
>>
>> If I revert this patch, then ethernet is back to working on the platform.
> 
> Is the Device Tree source for this platform available somewhere to look at?
> 

Yes, I'm using the DTS that is in the mainline:

arch/arm/boot/dts/socfpga.dtsi
arch/arm/boot/dts/socfpga_cyclone5.dtsi
arch/arm/boot/dts/socfpga_cyclone5_socdk.dts

Dinh


--
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

Re: SoCFPGA ethernet broken

2015-10-15 Thread Dinh Nguyen

On Thu, 15 Oct 2015, Florian Fainelli wrote:

> On 15/10/15 13:49, Dinh Nguyen wrote:
> >>
> >> Does this text change with and without the 8b63ec1837fa patch?
> > 
> > No, this text does not change with/without the 8b63ec1837fa patch.
> 
> Could you instrument mdiobus_scan(), get_phy_device() and
> phy_device_create/register to see if the parent is NULL, non-NULL?
> 

[0.800479] get_phy_device bus=0xeee26c00 addr=0004 phy_id=00221611
[0.806735] phy_device_create dev->dev.parent=0xeee26c50
[0.84] phy_device_register completed
[0.814675] mdiobus_scan phydev=0xeee27000
[1.979034] ksz9021_config_init of_node=

 Without patch 

[0.801294] get_phy_device bus=0xeeef6c00 addr=0004 phy_id=00221611
[0.807551] phy_device_create dev->dev.parent=0xeed6cc10
[0.811929] phy_device_register completed
[0.815510] mdiobus_scan phydev=0xeeef7000
[1.979034] ksz9021_config_init of_node=0xef203538
[1.988064] ksz9021_load_values_from_of
[1.992485] ksz9021_load_values_from_of
[1.996905] ksz9021_load_values_from_of 

BR,
Dinh
--
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

Re: SoCFPGA ethernet broken

2015-10-15 Thread Dinh Nguyen

On Thu, 15 Oct 2015, Florian Fainelli wrote:

> On 15/10/15 13:49, Dinh Nguyen wrote:
> >>
> >> Does this text change with and without the 8b63ec1837fa patch?
> > 
> > No, this text does not change with/without the 8b63ec1837fa patch.
> 
> Could you instrument mdiobus_scan(), get_phy_device() and
> phy_device_create/register to see if the parent is NULL, non-NULL?
>

Yes, I can do that.

> So far, I cannot see what is wrong with David's changes, quite the
> contrary, and if there was something wrong with the PHY device creation,
> it should not get you that far.
> 
> You have not answered my previous question though, do you have PHY
> fixups registered for that ID?

By fixups, do you mean the skew values that are in the device tree?
Those are the only fixups that I have the PHY.

Another debugging point, the SoCFPGA board has a Micrel ksz9021 PHY attached
to the ethernet port. What I'm seeing is that with 8b63ec1837fa patch, when
the call to ksz9021_config_init() is made both of_node and dev->parent->of_node
are NULL, without the patch the dev->parent->of_node is a valid pointer. Thus
the skew values get programmed to the phy.

BR,
Dinh
--
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

Re: SoCFPGA ethernet broken

2015-10-15 Thread Dinh Nguyen

On 10/15/2015 03:35 PM, David Daney wrote:
> On 10/15/2015 01:25 PM, Florian Fainelli wrote:
>> On 15/10/15 12:59, Dinh Nguyen wrote:
>>> On 10/15/2015 03:03 PM, Florian Fainelli wrote:
>>>> On 15/10/15 12:09, Dinh Nguyen wrote:
>>>>> Hi,
>>>>>
>>>>> commit "8b63ec1837fa phylib: Make PHYs children of their MDIO bus, not
>>>>> the bus' parent." seems to have broken ethernet support for the
>>>>> SoCFPGA
>>>>> platform which is using the stmmac ethernet driver.
>>>>
>>>> It is not clear to me how this relates to what you are seeing yet.
>>>>
>>>>>
>>>>> It appears that during DHCP, it cannot get an IP address. This only
>>>>> happens if ethernet was not used by the bootloader to tftp an kernel
>>>>> image. If I use the bootloader to tftp an image then ethernet is
>>>>> working
>>>>> fine. So I think the PHY is not getting enabled properly.
>>>>>
>>>>> If I revert this patch, then ethernet is back to working on the
>>>>> platform.
>>>>
>>>> Is the Device Tree source for this platform available somewhere to
>>>> look at?
>>>>
>>>
>>> Yes, I'm using the DTS that is in the mainline:
>>>
>>> arch/arm/boot/dts/socfpga.dtsi
>>> arch/arm/boot/dts/socfpga_cyclone5.dtsi
>>> arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
>>
>> There are no PHY devices in any of these DTS files, instead there is the
>> non-standard "phy-addr" property which is set to 0x supposedly
>> to indicate that the MDIO bus should be scanned. This is likely part of
>> your problem. The stmmac driver seems to be looking for "snps,phy-addr"
>> and not "phy-addr", so I am not even clear how this is supposed to work,
>> and the driver mentions this custom property is deprecated anyway.
>>
> 
> I think it is OK not to expose the PHYs in the device tree if they can
> be accurately probed without knowing information from the device tree.
> 
>> The core problem is in
>> drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c::stmmac_mdio_register
>> which manually detects the PHY, that is mostly fine, except that it does
>> not really seem to work here for a reason that is still unclear to me.
>>
> 
> I agree with this analysis.  I have also been looking at the code and
> cannot see anything that depends on what the parent device of the PHY
> is.  So it is a bit mystifying.
> 
> 
> I noticed in your original message you had in the boot log this:
> 
> .
> .
> .
> [0.804992] libphy: stmmac: probed
> [0.808410] eth0: PHY ID 00221611 at 4 IRQ POLL (stmmac-0:04) active
> .
> .
> .
> 
> Does this text change with and without the 8b63ec1837fa patch?

No, this text does not change with/without the 8b63ec1837fa patch.

Dinh

--
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

SoCFPGA ethernet broken

2015-10-15 Thread Dinh Nguyen

Hi,

commit "8b63ec1837fa phylib: Make PHYs children of their MDIO bus, not
the bus' parent." seems to have broken ethernet support for the SoCFPGA
platform which is using the stmmac ethernet driver.

It appears that during DHCP, it cannot get an IP address. This only
happens if ethernet was not used by the bootloader to tftp an kernel
image. If I use the bootloader to tftp an image then ethernet is working
fine. So I think the PHY is not getting enabled properly.

If I revert this patch, then ethernet is back to working on the platform.

I just tested this in the v4.3-rc5.

Will continue to debug, but was wondering if anyone has seen this issue.

Thanks for any help/comments.

Dinh

Bootlog below.

[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpuset
[0.00] Linux version 4.3.0-rc5-00037-g5b5f145
(dinguyen@linux-builds1) (gcc version 4.7.3 20130226 (prerelease) (crosstool
-NG linaro-1.13.1-4.7-2013.03-20130313 - Linaro GCC 2013.03) ) #1 SMP
Thu Oct 15 13:55:48 CDT 2015
[0.00] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7),
cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[0.00] Machine model: Altera SOCFPGA Cyclone V SoC Development Kit
[0.00] Truncating RAM at 0x-0x4000 to -0x2f80
[0.00] Consider using a HIGHMEM enabled kernel.
[0.00] Memory policy: Data cache writealloc
[0.00] On node 0 totalpages: 194560
[0.00] free_area_init_node: node 0, pgdat c067c080, node_mem_map
ef20b000
[0.00]   Normal zone: 1520 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 194560 pages, LIFO batch:31
[0.00] PERCPU: Embedded 13 pages/cpu @ef1df000 s21760 r8192
d23296 u53248
[0.00] pcpu-alloc: s21760 r8192 d23296 u53248 alloc=13*4096
[0.00] pcpu-alloc: [0] 0 [0] 1
[0.00] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 193040
[0.00] Kernel command line: console=ttyS0,115200 root=/dev/nfs
rw nfsroot=137.57.160.210:/home/dinguyen/rootfs_yocto ip=dh
cp debug
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288
bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144
bytes)
[0.00] Memory: 764368K/778240K available (4696K kernel code,
274K rwdata, 1328K rodata, 324K init, 131K bss, 13872K reserv
ed, 0K cma-reserved)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xf000 - 0xff00   ( 240 MB)
[0.00] lowmem  : 0xc000 - 0xef80   ( 760 MB)
[0.00] modules : 0xbf00 - 0xc000   (  16 MB)
[0.00]   .text : 0xc0008000 - 0xc05ea5f4   (6026 kB)
[0.00]   .init : 0xc05eb000 - 0xc063c000   ( 324 kB)
[0.00]   .data : 0xc063c000 - 0xc0680b30   ( 275 kB)
[0.00].bss : 0xc0680b30 - 0xc06a1a38   ( 132 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[0.00] Hierarchical RCU implementation.
[0.00]  Build-time adjustment of leaf fanout to 32.
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] L2C-310 enabling early BRESP for Cortex-A9
[0.00] L2C-310 full line of zeros enabled for Cortex-A9
[0.00] L2C-310 ID prefetch enabled, offset 1 lines
[0.00] L2C-310 dynamic clock gating enabled, standby mode enabled
[0.00] L2C-310 cache controller enabled, 8 ways, 512 kB
[0.00] L2C-310: CACHE_ID 0x410030c9, AUX_CTRL 0x76060001
[0.00] clocksource: timer1: mask: 0x max_cycles:
0x, max_idle_ns: 19112604467 ns
[0.05] sched_clock: 32 bits at 100MHz, resolution 10ns, wraps
every 21474836475ns
[0.000134] Console: colour dummy device 80x30
[0.000151] Calibrating delay loop... 1836.64 BogoMIPS (lpj=9183232)
[0.059867] pid_max: default: 32768 minimum: 301
[0.059938] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.059947] Mountpoint-cache hash table entries: 2048 (order: 1, 8192
bytes)
[0.060411] CPU: Testing write buffer coherency: ok
[0.060586] CPU0: thread -1, cpu 0, socket 0, mpidr 8000
[0.060735] Setting up static identity map for 0x8280 - 0x82d8
[0.119895] CPU1: thread -1, cpu 1, socket 0, mpidr 8001
[0.119954] Brought up 2 CPUs
[0.119968] SMP: Total of 2 processors activated (3679.84 BogoMIPS).
[0.119974] CPU: All CPU(s) started in SVC mode.
[0.120594] devtmpfs: initialized
[0.124057] VFP support v0.3: implementor 41 architecture 3 part 30
variant 9 rev 4
[0.124296] clocksource: jiffies: mask: 0x max_cycles:
0x, max_idle_ns: 1911260446275 ns
[0.125249] NET: Registered protocol family 16

Re: Ethernet on my CycloneV broke since 4.9.124

Re: Ethernet on my CycloneV broke since 4.9.124

Re: Ethernet on my CycloneV broke since 4.9.124

Re: [BUG] net: stmmac: socfpga ethernet no longer working on linux-next

Re: [BUG] net: stmmac: socfpga ethernet no longer working on linux-next

[BUG] net: stmmac: socfpga ethernet no longer working on linux-next

Re: [PATCH V2] net: stmmac: socfpga: Remove re-registration of reset controller

Re: [PATCH V3] net: stmmac: socfpga: Remove re-registration of reset controller

Re: [PATCH V2] net: stmmac: socfpga: Remove re-registration of reset controller

Re: [PATCH V2] net: stmmac: socfpga: Remove re-registration of reset controller

Re: [PATCH V2] net: stmmac: socfpga: Remove re-registration of reset controller

Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement

Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement

Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement

Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement

Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement

Re: commit e34d65696d2e broke stmmac ethernet on socfpga

commit e34d65696d2e broke stmmac ethernet on socfpga

Re: [PATCH v6 4/4] stmmac: socfpga: Provide dt node to config ptp clk source.

Re: [PATCHv2 net] phy: micrel: Fix finding PHY properties in MAC node.

Re: SoCFPGA ethernet broken

Re: SoCFPGA ethernet broken

Re: SoCFPGA ethernet broken

Re: [PATCH] net/phy: micrel: Follow attached_dev to get to the MAC device

Re: [PATCH] net/phy: micrel: Follow attached_dev to get to the MAC device

Re: [PATCH] net/phy: micrel: Follow attached_dev to get to the MAC device

Re: [PATCH] net/phy: micrel: Follow attached_dev to get to the MAC device

Re: SoCFPGA ethernet broken

Re: SoCFPGA ethernet broken

Re: [PATCH] net/phy: micrel: Follow attached_dev to get to the MAC device

Re: SoCFPGA ethernet broken

Re: SoCFPGA ethernet broken

Re: SoCFPGA ethernet broken

Re: SoCFPGA ethernet broken

SoCFPGA ethernet broken

35 matches

Site Navigation

Mail list logo

Footer information