Re: [PATCH] staging: mt7621-pci: don't return if get gpio fails

[Greg Ungerer <gerg@kernel.org>]

Hi Sergio,

On 21/3/20 1:25 am, Sergio Paracuellos wrote:
> On Fri, Mar 20, 2020 at 4:08 PM Greg Ungerer <gerg@kernel.org> wrote:
>> On 21/3/20 12:38 am, Sergio Paracuellos wrote:
>>> On Fri, Mar 20, 2020 at 3:30 PM Greg Ungerer <gerg@kernel.org> wrote:
>>>> On 20/3/20 2:14 am, Sergio Paracuellos wrote:
>> [snip]
>>>> rt2880-pinmux pinctrl: pcie is already enabled
>>>> mt7621-pci 1e140000.pcie: Error applying setting, reverse things back
>>>> mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
>>>> mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
>>>> mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz
>>>> mt7621-pci 1e140000.pcie: pcie0 no card, disable it (RST & CLK)
>>>> mt7621-pci 1e140000.pcie: pcie1 no card, disable it (RST & CLK)
>>>> mt7621-pci 1e140000.pcie: pcie2 no card, disable it (RST & CLK)
>>>> mt7621-pci 1e140000.pcie: Nothing is connected in virtual bridges. Exiting..
>>>> ...
>>>>
>>>> It is probably 50:50 on any boot whether it will probe pci successfully or
>>>> fail to probe it.
>>>>
>>>> BTW, this is with the patch here applied:
>>>> http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2020-March/142472.html
>>>
>>> Yes this is the behaviour I was talking about in this series:
>>>
>>> http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2020-March/142520.html
>>>
>>> These patches have been already added to staging-testing and should
>>> work and found properly ports also for you.
>>>
>>> Let me know any issue you might find.
>>
>> Ok, I am testing now a fresh up-to-date staging-testing.
>> I can see your most recent patches for the pci-phy at the top of the git log.
>> No other patches applied (just my devicetree for my hardware).
>>
>> It dumps on every boot with:
>>
>> ...
>> rt2880-pinmux pinctrl: pcie is already enabled
>> mt7621-pci 1e140000.pcie: Error applying setting, reverse things back
>> mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual port = 1)
>> mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual port = 0)
>> mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
>> mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz
>> mt7621-pci 1e140000.pcie: pcie1 no card, disable it (RST & CLK)
>> Unhandled kernel unaligned access[#1]:
>> CPU: 3 PID: 111 Comm: kworker/3:2 Not tainted 5.6.0-rc3-00347-g825c6f470c62-dirty #9
>> Workqueue: events deferred_probe_work_func
>> $ 0   : 00000000 00000001 5f60d043 8fe1ba80
>> $ 4   : 0000010d 01eb9000 00000000 00000000
>> $ 8   : 294b4c00 80940000 00000008 000000ce
>> $12   : 2e303030 00000000 00000000 65696370
>> $16   : ffffffed 0000010d 8e373cd0 8214c1e0
>> $20   : 00000000 82144c80 82144680 8214c250
>> $24   : 00000018 803ef8f4
>> $28   : 8e372000 8e373c60 8214c080 803940e8
>> Hi    : 00000125
>> Lo    : 122f2000
>> epc   : 807b3328 mutex_lock+0x8/0x44
>> ra    : 803940e8 phy_power_off+0x28/0xb0
>> Status: 1100fc03        KERNEL EXL IE
>> Cause : 00800010 (ExcCode 04)
>> BadVA : 0000010d
>> PrId  : 0001992f (MIPS 1004Kc)
>> Modules linked in:
>> Process kworker/3:2 (pid: 111, threadinfo=(ptrval), task=(ptrval), tls=00000000)
>> Stack : 8e373cd0 803fe4f4 8e372000 8e373c90 8214c080 804fde1c 8e373c98 808d62f4
>>           8e373c78 00000000 8214c254 804fe648 1e160000 804f27b8 00000001 808d62f4
>>           00000000 00000001 8214c228 808d62f4 80930000 809a0000 8fd47e10 808d63d4
>>           808d62d4 8fd47e10 808d0000 808d0000 8e373cd0 8e373cd0 809e2a74 809db510
>>           809db510 00000006 00000001 00000000 00000000 00000000 01000000 1e1440ff
>>           ...
>> Call Trace:
>> [<807b3328>] mutex_lock+0x8/0x44
>> [<803940e8>] phy_power_off+0x28/0xb0
>> [<804fe648>] mt7621_pci_probe+0xc20/0xd18
>> [<80402ab8>] platform_drv_probe+0x40/0x94
>> [<80400a74>] really_probe+0x104/0x364
>> [<803feb74>] bus_for_each_drv+0x84/0xdc
>> [<80400924>] __device_attach+0xdc/0x120
>> [<803ffb5c>] bus_probe_device+0xa0/0xbc
>> [<80400124>] deferred_probe_work_func+0x7c/0xbc
>> [<800420e8>] process_one_work+0x230/0x450
>> [<80042638>] worker_thread+0x330/0x5fc
>> [<80048eb0>] kthread+0x12c/0x134
>> [<80007438>] ret_from_kernel_thread+0x14/0x1c
>> Code: 24050002  27bdfff8  8f830000 <c0850000> 14a00005  00000000  00600825  e0810000  1020fffa
>>
> 
> Ok, this seems to be the access for slot 1 which I default set to true
> as enabled ports because of the phy is for dual_port,
> so because you are using only one of the two ports the
> phy_power_off(port->phy); for slot 1 should not be triggered because
> it is done for slot 0 if neccessary.
> 
> Can you try this small fix:
> 
> diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c
> b/drivers/staging/mt7621-pci/pci-mt7621.c
> index 739504f7e4fc..23b51789f72e 100644
> --- a/drivers/staging/mt7621-pci/pci-mt7621.c
> +++ b/drivers/staging/mt7621-pci/pci-mt7621.c
> @@ -517,7 +517,8 @@ static void mt7621_pcie_init_ports(struct mt7621_pcie *pcie)
>                  if (!mt7621_pcie_port_is_linkup(port)) {
>                          dev_err(dev, "pcie%d no card, disable it (RST & CLK)\n",
>                                  slot);
> -                       phy_power_off(port->phy);
> +                       if (slot != 1)
> +                               phy_power_off(port->phy);
>                          mt7621_control_assert(port);
>                          mt7621_pcie_port_clk_disable(port);
>                          port->enabled = false;
> 
> 
>> ---[ end trace 8e3fadee03559cba ]---

Yep, that fixes it. No more dumps.

In limited testing so far every boot up has probed the PCI bu successfully.
I'll keep testing, and report any problems.

Note that I am running with the modified mt7621.dtsi that has the reset
lines for PCIe limited to only GPIO19. (GPIO7 and GPIO8 removed from reset).

Regards
Greg

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel