Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1698326 > unrolled thread

Re: [PATCH net] xgene: Don't fail probe, if there is no clk resource for SGMII interfaces

Started byLaura Abbott <labbott@redhat.com>
First post2017-07-27 23:10 +0200
Last post2017-07-28 20:50 +0200
Articles 6 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH net] xgene: Don't fail probe, if there is no clk resource  for SGMII interfaces Laura Abbott <labbott@redhat.com> - 2017-07-27 23:10 +0200
    Re: [PATCH net] xgene: Don't fail probe, if there is no clk resource  for SGMII interfaces Tom Bogendoerfer <tsbogend@alpha.franken.de> - 2017-07-27 23:40 +0200
      Re: [PATCH net] xgene: Don't fail probe, if there is no clk resource  for SGMII interfaces Laura Abbott <labbott@redhat.com> - 2017-07-28 00:50 +0200
        Re: [PATCH net] xgene: Don't fail probe, if there is no clk resource  for SGMII interfaces Tom Bogendoerfer <tsbogend@alpha.franken.de> - 2017-07-28 16:30 +0200
          Re: [PATCH net] xgene: Don't fail probe, if there is no clk resource  for SGMII interfaces Laura Abbott <labbott@redhat.com> - 2017-07-28 18:50 +0200
          Re: [PATCH net] xgene: Don't fail probe, if there is no clk resource  for SGMII interfaces Iyappan Subramanian <isubramanian@apm.com> - 2017-07-28 20:50 +0200

#1698326 — Re: [PATCH net] xgene: Don't fail probe, if there is no clk resource for SGMII interfaces

FromLaura Abbott <labbott@redhat.com>
Date2017-07-27 23:10 +0200
SubjectRe: [PATCH net] xgene: Don't fail probe, if there is no clk resource for SGMII interfaces
Message-ID<u7YcG-2T1-37@gated-at.bofh.it>
On 07/13/2017 01:57 AM, Thomas Bogendoerfer wrote:
> From: Thomas Bogendoerfer <tbogendoerfer@suse.de>
> 
> This change fixes following problem
> 
> [    1.827940] xgene-enet: probe of 1f210030.ethernet failed with error -2
> 
> which leads to a missing ethernet interface (reproducable at least on
> Gigabyte MP30-AR0 and APM Mustang systems).
> 
> The check for a valid clk resource fails, because DT doesn't provide a
> clock for sgenet1. But the driver doesn't use this clk, if the ethernet
> port is connected via SGMII. Therefore this patch avoids probing for clk
> on SGMII interfaces.
> 
> Fixes: 9aea7779b764 drivers: net: xgene: Fix crash on DT systems
> Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
> ---
>  drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 22 ++++++++++++----------
>  1 file changed, 12 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
> index d3906f6b01bd..86058a9f3417 100644
> --- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
> +++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
> @@ -1785,16 +1785,18 @@ static int xgene_enet_get_resources(struct xgene_enet_pdata *pdata)
>  
>  	xgene_enet_gpiod_get(pdata);
>  
> -	pdata->clk = devm_clk_get(&pdev->dev, NULL);
> -	if (IS_ERR(pdata->clk)) {
> -		/* Abort if the clock is defined but couldn't be retrived.
> -		 * Always abort if the clock is missing on DT system as
> -		 * the driver can't cope with this case.
> -		 */
> -		if (PTR_ERR(pdata->clk) != -ENOENT || dev->of_node)
> -			return PTR_ERR(pdata->clk);
> -		/* Firmware may have set up the clock already. */
> -		dev_info(dev, "clocks have been setup already\n");
> +	if (pdata->phy_mode != PHY_INTERFACE_MODE_SGMII) {
> +		pdata->clk = devm_clk_get(&pdev->dev, NULL);
> +		if (IS_ERR(pdata->clk)) {
> +			/* Abort if the clock is defined but couldn't be
> +			 * retrived. Always abort if the clock is missing on
> +			 * DT system as the driver can't cope with this case.
> +			 */
> +			if (PTR_ERR(pdata->clk) != -ENOENT || dev->of_node)
> +				return PTR_ERR(pdata->clk);
> +			/* Firmware may have set up the clock already. */
> +			dev_info(dev, "clocks have been setup already\n");
> +		}
>  	}
>  
>  	if (pdata->phy_mode != PHY_INTERFACE_MODE_XGMII)
> 

This change causes boot failures for me on my APM Mustang system running
Fedora rawhide:

[   16.669089] Synchronous External Abort: synchronous external abort (0x9600000
[   16.669099] Internal error: : 96000010 [#1] SMP                              
[   16.669103] Modules linked in: xgene_enet(+) at803x realtek mdio_xgene xgenes
[   16.669127] CPU: 2 PID: 534 Comm: systemd-udevd Not tainted 4.13.0-0.rc1.git1
[   16.669128] Hardware name: AppliedMicro X-Gene Mustang Board/X-Gene Mustang 6
[   16.669131] task: ffff8003e6f8ce00 task.stack: ffff8003e4fd8000              
[   16.669144] PC is at xgene_enet_wr_mac+0xa0/0x128 [xgene_enet]               
[   16.669152] LR is at xgene_enet_wr_mac+0x64/0x128 [xgene_enet] 

<snip>
           
[   16.669345] [<ffff000000de19f0>] xgene_enet_wr_mac+0xa0/0x128 [xgene_enet]   
[   16.669354] [<ffff000000de2fc0>] xgene_sgmac_reset+0x28/0x48 [xgene_enet]    
[   16.669362] [<ffff000000de3b50>] xgene_sgmac_init+0x1e0/0x2e8 [xgene_enet]   
[   16.669370] [<ffff000000de8564>] xgene_enet_probe+0xfa4/0x1368 [xgene_enet]  
[   16.669376] [<ffff0000086f14f0>] platform_drv_probe+0x60/0xc0                
[   16.669379] [<ffff0000086ee86c>] driver_probe_device+0x31c/0x458             
[   16.669381] [<ffff0000086eea8c>] __driver_attach+0xe4/0x130                  
[   16.669384] [<ffff0000086ebfd4>] bus_for_each_dev+0x5c/0xa8                  
[   16.669386] [<ffff0000086edf30>] driver_attach+0x30/0x40                     
[   16.669388] [<ffff0000086ed8d0>] bus_add_driver+0x220/0x2c0                  
[   16.669390] [<ffff0000086efd04>] driver_register+0x6c/0x118                  
[   16.669392] [<ffff0000086f142c>] __platform_driver_register+0x54/0x60        
[   16.669400] [<ffff000000e05014>] xgene_enet_driver_init+0x14/0x1000 [xgene_e]
[   16.669404] [<ffff000008083834>] do_one_initcall+0x44/0x138                  
[   16.669408] [<ffff0000081a327c>] do_init_module+0x64/0x1d0                   
[   16.669410] [<ffff0000081a1dc4>] load_module+0x151c/0x1770                   
[   16.669413] [<ffff0000081a2330>] SyS_finit_module+0xd8/0xf0                  
[   16.669415] [<ffff00000808364c>] __sys_trace_return+0x0/0x4                  
[   16.669418] Code: 14000004 d503201f d28218e0 95f24031 (b94002a2)     

I suspect the clock is actually needed on some systems.

Thanks,
Laura

[toc] | [next] | [standalone]


#1698334

FromTom Bogendoerfer <tsbogend@alpha.franken.de>
Date2017-07-27 23:40 +0200
Message-ID<u7YFH-33c-1@gated-at.bofh.it>
In reply to#1698326
On Thu, Jul 27, 2017 at 02:03:42PM -0700, Laura Abbott wrote:
> This change causes boot failures for me on my APM Mustang system running
> Fedora rawhide:
> 
> [   16.669089] Synchronous External Abort: synchronous external abort (0x9600000
> [   16.669099] Internal error: : 96000010 [#1] SMP                              
> [   16.669103] Modules linked in: xgene_enet(+) at803x realtek mdio_xgene xgenes
> [   16.669127] CPU: 2 PID: 534 Comm: systemd-udevd Not tainted 4.13.0-0.rc1.git1
> [   16.669128] Hardware name: AppliedMicro X-Gene Mustang Board/X-Gene Mustang 6
> [   16.669131] task: ffff8003e6f8ce00 task.stack: ffff8003e4fd8000              
> [   16.669144] PC is at xgene_enet_wr_mac+0xa0/0x128 [xgene_enet]               
> [   16.669152] LR is at xgene_enet_wr_mac+0x64/0x128 [xgene_enet] 

on the first glance I don't see anything clock related there.

What firmware version is installed on your mustang board ? I saw
ethernet related crashes with mustang boards because the device tree
in firmware was too old for the xgene ethernet driver.

Thoms.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

[toc] | [prev] | [next] | [standalone]


#1698355

FromLaura Abbott <labbott@redhat.com>
Date2017-07-28 00:50 +0200
Message-ID<u7ZLr-3JP-5@gated-at.bofh.it>
In reply to#1698334
On 07/27/2017 02:39 PM, Tom Bogendoerfer wrote:
> On Thu, Jul 27, 2017 at 02:03:42PM -0700, Laura Abbott wrote:
>> This change causes boot failures for me on my APM Mustang system running
>> Fedora rawhide:
>>
>> [   16.669089] Synchronous External Abort: synchronous external abort (0x9600000
>> [   16.669099] Internal error: : 96000010 [#1] SMP                              
>> [   16.669103] Modules linked in: xgene_enet(+) at803x realtek mdio_xgene xgenes
>> [   16.669127] CPU: 2 PID: 534 Comm: systemd-udevd Not tainted 4.13.0-0.rc1.git1
>> [   16.669128] Hardware name: AppliedMicro X-Gene Mustang Board/X-Gene Mustang 6
>> [   16.669131] task: ffff8003e6f8ce00 task.stack: ffff8003e4fd8000              
>> [   16.669144] PC is at xgene_enet_wr_mac+0xa0/0x128 [xgene_enet]               
>> [   16.669152] LR is at xgene_enet_wr_mac+0x64/0x128 [xgene_enet] 
> 
> on the first glance I don't see anything clock related there.
> 

I don't know the intricacies of the Mustang hardware but external
aborts have been a symptom of missing clocks on other hardware.

> What firmware version is installed on your mustang board ? I saw
> ethernet related crashes with mustang boards because the device tree
> in firmware was too old for the xgene ethernet driver.
> 
> Thoms.
> 

TianoCore 3.06.12 UEFI 2.4.0 Aug 12 2016 13:30:51
CPU: APM ARM 64-bit Potenza Rev B0 2400MHz PCP 2400MHz
     32 KB ICACHE, 32 KB DCACHE
     SOC 2000MHz IOBAXI 400MHz AXI 250MHz AHB 200MHz GFC 125MHz
Board: X-Gene Mustang Board
Little Endian build
Slimpro FW:
        Ver: 3.5 (build 03.06.12.00 2016/08/12)
        PMD: 1000 mV
        SOC: 950 mV


Thanks,
Laura

[toc] | [prev] | [next] | [standalone]


#1698849

FromTom Bogendoerfer <tsbogend@alpha.franken.de>
Date2017-07-28 16:30 +0200
Message-ID<u8er8-4Rs-25@gated-at.bofh.it>
In reply to#1698355
On Thu, Jul 27, 2017 at 03:39:58PM -0700, Laura Abbott wrote:
> I don't know the intricacies of the Mustang hardware but external
> aborts have been a symptom of missing clocks on other hardware.

you are right, it's a missing clock. For SGMII ports the driver
doesn't really use the clock source other then doing the one
devm_clk_get(), but this is enough to get the clock going.

Below patch fixes the crash and brings back the second SGMII port
(even without a clock source in device tree, I guess it uses clock
from first port).  From a correctness standpoint there should probably 
be a clk_prepare_enable(), if port is SGMII.

Could you test the patch ? If it works, I'll submit it.

Thomas.

diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
index 86058a9f3417..1d307f2def2d 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -1785,9 +1785,9 @@ static int xgene_enet_get_resources(struct xgene_enet_pdata *pdata)
 
 	xgene_enet_gpiod_get(pdata);
 
-	if (pdata->phy_mode != PHY_INTERFACE_MODE_SGMII) {
-		pdata->clk = devm_clk_get(&pdev->dev, NULL);
-		if (IS_ERR(pdata->clk)) {
+	pdata->clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(pdata->clk)) {
+		if (pdata->phy_mode != PHY_INTERFACE_MODE_SGMII) {
 			/* Abort if the clock is defined but couldn't be
 			 * retrived. Always abort if the clock is missing on
 			 * DT system as the driver can't cope with this case.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

[toc] | [prev] | [next] | [standalone]


#1698945

FromLaura Abbott <labbott@redhat.com>
Date2017-07-28 18:50 +0200
Message-ID<u8gCC-6cX-19@gated-at.bofh.it>
In reply to#1698849
On 07/28/2017 07:23 AM, Tom Bogendoerfer wrote:
> On Thu, Jul 27, 2017 at 03:39:58PM -0700, Laura Abbott wrote:
>> I don't know the intricacies of the Mustang hardware but external
>> aborts have been a symptom of missing clocks on other hardware.
> 
> you are right, it's a missing clock. For SGMII ports the driver
> doesn't really use the clock source other then doing the one
> devm_clk_get(), but this is enough to get the clock going.
> 
> Below patch fixes the crash and brings back the second SGMII port
> (even without a clock source in device tree, I guess it uses clock
> from first port).  From a correctness standpoint there should probably 
> be a clk_prepare_enable(), if port is SGMII.
> 
> Could you test the patch ? If it works, I'll submit it.
> 
> Thomas.
> 
> diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
> index 86058a9f3417..1d307f2def2d 100644
> --- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
> +++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
> @@ -1785,9 +1785,9 @@ static int xgene_enet_get_resources(struct xgene_enet_pdata *pdata)
>  
>  	xgene_enet_gpiod_get(pdata);
>  
> -	if (pdata->phy_mode != PHY_INTERFACE_MODE_SGMII) {
> -		pdata->clk = devm_clk_get(&pdev->dev, NULL);
> -		if (IS_ERR(pdata->clk)) {
> +	pdata->clk = devm_clk_get(&pdev->dev, NULL);
> +	if (IS_ERR(pdata->clk)) {
> +		if (pdata->phy_mode != PHY_INTERFACE_MODE_SGMII) {
>  			/* Abort if the clock is defined but couldn't be
>  			 * retrived. Always abort if the clock is missing on
>  			 * DT system as the driver can't cope with this case.
> 


Yes, this works. You can add my Tested-by.

Thanks,
Laura

[toc] | [prev] | [next] | [standalone]


#1699017

FromIyappan Subramanian <isubramanian@apm.com>
Date2017-07-28 20:50 +0200
Message-ID<u8iuJ-7rY-9@gated-at.bofh.it>
In reply to#1698849
On Fri, Jul 28, 2017 at 7:23 AM, Tom Bogendoerfer
<tsbogend@alpha.franken.de> wrote:
> On Thu, Jul 27, 2017 at 03:39:58PM -0700, Laura Abbott wrote:
>> I don't know the intricacies of the Mustang hardware but external
>> aborts have been a symptom of missing clocks on other hardware.
>
> you are right, it's a missing clock. For SGMII ports the driver
> doesn't really use the clock source other then doing the one
> devm_clk_get(), but this is enough to get the clock going.
>
> Below patch fixes the crash and brings back the second SGMII port
> (even without a clock source in device tree, I guess it uses clock
> from first port).  From a correctness standpoint there should probably
> be a clk_prepare_enable(), if port is SGMII.
>
> Could you test the patch ? If it works, I'll submit it.
>
> Thomas.
>
> diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
> index 86058a9f3417..1d307f2def2d 100644
> --- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
> +++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
> @@ -1785,9 +1785,9 @@ static int xgene_enet_get_resources(struct xgene_enet_pdata *pdata)
>
>         xgene_enet_gpiod_get(pdata);
>
> -       if (pdata->phy_mode != PHY_INTERFACE_MODE_SGMII) {
> -               pdata->clk = devm_clk_get(&pdev->dev, NULL);
> -               if (IS_ERR(pdata->clk)) {
> +       pdata->clk = devm_clk_get(&pdev->dev, NULL);
> +       if (IS_ERR(pdata->clk)) {
> +               if (pdata->phy_mode != PHY_INTERFACE_MODE_SGMII) {
>                         /* Abort if the clock is defined but couldn't be
>                          * retrived. Always abort if the clock is missing on
>                          * DT system as the driver can't cope with this case.
>
> --

Thanks for the patch.

Acked-by: Iyappan Subramanian <isubramanian@apm.com>

> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea.                                                [ RFC1925, 2.3 ]

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web