Re: espressobin device tree with kernel 5.1 RC

[Miquel Raynal <miquel.raynal@bootlin.com>]

Hi Timothy,

> > > [    4.203692] cacheinfo: Unable to detect cache hierarchy for CPU 0
> > > [    4.210192] in mvebu probe
> > > [    4.212924] check device match
> > > [    4.216026] device did match
> > > [    4.219058] check resources
> > > [    4.221858] resources ok
> > > [    4.224458] enable resources
> > > [    4.227405] past enable resources
> > > [    4.230817] disenable resources
> > > [    4.234042] past disable resources
> > > [    4.237536] init host
> > > [    4.239931] ahci-mvebu d00e0000.sata: AHCI 0001.0300 32 slots 1 ports 6  
> > Gbps 0x1 impl platform mode  
> > > [    4.249196] ahci-mvebu d00e0000.sata: flags: ncq sntf led only pmp fbs pio  
> > slum part sxs  
> > > [    4.258647] scsi host0: ahci-mvebu
> > > [    4.262491] ata1: SATA max UDMA/133 mmio [mem 0xd00e0000-  
> > 0xd00e1fff] port 0x100 irq 21  
> > > [    4.270609] past init host
> > > [    4.273353] past rc check
> > > [    4.276455] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
> > > [    4.284408] MACsec IEEE 802.1AE
> > > [    4.287965] libphy: Fixed MDIO Bus: probed
> > > [snip]
> > >
> > > Unfortunately that does not tell me much.  Does it say anything to you?
> > > I mean I guess        rc = ahci_platform_enable_resources(hpriv); Is failing,  
> > should I put some traces in that?
> > 
> > Yes, in particular around the PHY initialization, until you found where it fails
> > exactly.
> > 
> > 
> > Thanks,
> > Miquèl  
> 
> I have traced it down to phy_init in phy-core.c and have put in the following traces:
> 
> int phy_init(struct phy *phy)
> {
>         int ret;
> 
>         if (!phy)
>                 return 0;
> 
>         ret = phy_pm_runtime_get_sync(phy);
>         if (ret < 0 && ret != -ENOTSUPP)
>                 return ret;
>         ret = 0; /* Override possible ret == -ENOTSUPP */
> 
>         mutex_lock(&phy->mutex);
> printk(KERN_INFO "in phy init before check\n");
> printk(KERN_INFO "phy->init_count %d\n", phy->init_count);
> printk(KERN_INFO "phy->ops->init %pr\n", phy->ops->init);
>         if (phy->init_count == 0 && phy->ops->init) {
> printk(KERN_INFO "in phy init past check\n");
>                 ret = phy->ops->init(phy);
>                 if (ret < 0) {
> printk(KERN_INFO "in phy init  phy->ops->init(phy) failed\n");
>                         dev_err(&phy->dev, "phy init failed --> %d\n", ret);
>                         goto out;
>                 }
>         }
>         ++phy->init_count;
> 
> out:
>         mutex_unlock(&phy->mutex);
>         phy_pm_runtime_put(phy);
>         return ret;
> }
> 
> Which produces the following dmesg :
> [    4.194835] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
> [    4.205270] cacheinfo: Unable to detect cache hierarchy for CPU 0
> [    4.211777] in mvebu probe
> [    4.214508] check device match
> [    4.217609] device did match
> [    4.220662] check resources
> [    4.223455] resources ok
> [    4.226061] in phy init before check
> [    4.229718] phy->init_count 0
> [    4.232774] phy->ops->init (null)
> [    4.236188] phy phy-d0018300.phy.2: phy poweron failed --> -1
> [    4.242095] enable resources
> [    4.245072] ahci-mvebu: probe of d00e0000.sata failed with error -1
> [    4.251831] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
> [    4.259753] MACsec IEEE 802.1AE
> [    4.263371] libphy: Fixed MDIO Bus: probed
> [    4.267777] tun: Universal TUN/TAP device driver, 1.6
> [    4.273375] libphy: orion_mdio_bus: probed
> 
> I believe the significant line is [    4.232774] phy->ops->init (null)
> 
> I'm not sure where that was supposed to have been initialized but it apparently was not.

Something looks wrong in your logs: you have init_count to 0 and
ops->init() to NULL, how can "(phy->init_count == 0 && phy->ops->init)"
be evaluated to true?

Miquèl

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel