Patch "net: stmmac: Wait a bit for the reset to take effect" has been added to the 5.15-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    net: stmmac: Wait a bit for the reset to take effect

to the 5.15-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     net-stmmac-wait-a-bit-for-the-reset-to-take-effect.patch
and it can be found in the queue-5.15 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit e7927c779fc32f55dbf2385c91118efc7b726ede
Author: Bernd Edlinger <bernd.edlinger@xxxxxxxxxx>
Date:   Mon Jan 22 19:19:09 2024 +0100

    net: stmmac: Wait a bit for the reset to take effect
    
    [ Upstream commit a5f5eee282a0aae80227697e1d9c811b1726d31d ]
    
    otherwise the synopsys_id value may be read out wrong,
    because the GMAC_VERSION register might still be in reset
    state, for at least 1 us after the reset is de-asserted.
    
    Add a wait for 10 us before continuing to be on the safe side.
    
    > From what have you got that delay value?
    
    Just try and error, with very old linux versions and old gcc versions
    the synopsys_id was read out correctly most of the time (but not always),
    with recent linux versions and recnet gcc versions it was read out
    wrongly most of the time, but again not always.
    I don't have access to the VHDL code in question, so I cannot
    tell why it takes so long to get the correct values, I also do not
    have more than a few hardware samples, so I cannot tell how long
    this timeout must be in worst case.
    Experimentally I can tell that the register is read several times
    as zero immediately after the reset is de-asserted, also adding several
    no-ops is not enough, adding a printk is enough, also udelay(1) seems to
    be enough but I tried that not very often, and I have not access to many
    hardware samples to be 100% sure about the necessary delay.
    And since the udelay here is only executed once per device instance,
    it seems acceptable to delay the boot for 10 us.
    
    BTW: my hardware's synopsys id is 0x37.
    
    Fixes: c5e4ddbdfa11 ("net: stmmac: Add support for optional reset control")
    Signed-off-by: Bernd Edlinger <bernd.edlinger@xxxxxxxxxx>
    Reviewed-by: Jiri Pirko <jiri@xxxxxxxxxx>
    Reviewed-by: Serge Semin <fancer.lancer@xxxxxxxxx>
    Link: https://lore.kernel.org/r/AS8P193MB1285A810BD78C111E7F6AA34E4752@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index ede630bfad2f..ab3ded6e0e6a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -7096,6 +7096,9 @@ int stmmac_dvr_probe(struct device *device,
 		dev_err(priv->device, "unable to bring out of ahb reset: %pe\n",
 			ERR_PTR(ret));
 
+	/* Wait a bit for the reset to take effect */
+	udelay(10);
+
 	/* Init MAC and get the capabilities */
 	ret = stmmac_hw_init(priv);
 	if (ret)




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux