Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <f89e203a-af77-9661-1003-0e9370ff6fab@axis.com>
Date:   Thu, 1 Jun 2023 11:10:58 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.9.0
Subject: Re: [PATCH net] net: dsa: mv88e6xxx: Increase wait after reset
 deactivation
Content-Language: en-US
To:     Andrew Lunn <andrew@lunn.ch>
CC:     Florian Fainelli <f.fainelli@gmail.com>,
        Vladimir Oltean <olteanv@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>, <kernel@axis.com>,
        Baruch Siach <baruch@tkos.co.il>, <netdev@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>
References: <20230530145223.1223993-1-andreas.svensson@axis.com>
 <be44dfe3-b4cb-4fd5-b4bd-23eec4bd401c@lunn.ch>
From:   Andreas Svensson <andreas.svensson@axis.com>
In-Reply-To: <be44dfe3-b4cb-4fd5-b4bd-23eec4bd401c@lunn.ch>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ME9UUFR4SmlSWU9pb2FvWHRwYXJMOXltcU5BbWVmU0lBakh2VWdYVGE5V21w?=
 =?utf-8?B?QkRlYUY0VXdUWVNTdHFyWWdsS2ZmcjNGK2xxWjJqOXpWaGdVbkhCellESUkv?=
 =?utf-8?B?bDc1K3RDcW82enJhR2xzMit2OVlvZ1pmcE5QQWNYWWZZYW81MGxjSmhqMjgy?=
 =?utf-8?B?M2x4N0w0UlJMMVRrMkJUeFhmbnBxaEZwRGJxQjZDQUpVMnkxZWppbVVhMkg5?=
 =?utf-8?B?YU14S3EyeVB5UVF3SCs5VkRUQ1JLSTVGb0xzdlNaUldEemw5QXUzOVdpNWVQ?=
 =?utf-8?B?aktVT05wenUrZU9GUEl1aEJUZXh6NllpZldMcTduUnBZSkJMbXBNTEtGVHNs?=
 =?utf-8?B?ZFMwRFJXTkZzVzJlWk04a2ltZDhlNVhiSm9NTzdNQ0tNOFJweTRMU0gyQWgv?=
 =?utf-8?B?QXBabUx5LzViL2hLYXBMcTM4bmtiTVF3b2MxMTBDOEV5RStQUS9LdmJZRXQr?=
 =?utf-8?B?M0pUWTMvZXE5VzZMTVlheVM3UUE2Sjd5WjQzRFNKd0d3N014Q3ZXS1FVWHJM?=
 =?utf-8?B?ZG5TeUFnaDhnV2dLTnUzWkRrY2xhck5RUGs2TitCUjNTbFBUWVRra2Z3cVNS?=
 =?utf-8?B?OFd3QUVyRytTNjc3R2ZQTW5IMlRzL1FlRzNjaW5kUitSSlFuNHJXMjRVcitG?=
 =?utf-8?B?aFBDZHJvbzl0S0dkTUw0WVBnYlkvdnBtZHJOa1U2a3l1VU13TnRWTGZZaGpW?=
 =?utf-8?B?TXJqY2lmWG5WMC9ndldhTEt3eXNkb1cwNU1zajZvVUxQT1FCd0VTci8wZEIv?=
 =?utf-8?B?OXBMWDB2aGowdnl6anE3aENmUXhqbytRSDJlSDh3dGRTNEdJRXEzSWptcE5I?=
 =?utf-8?B?MDRaMHZSc0ViTEVkOXVmeVNhdlhleWljSHRvMjN4dTQzVkVCTTQvZGQvTGVp?=
 =?utf-8?B?b1JPYlRxV2FkS2d1YjM0aHV1Q1BsaWQ0RE5rWEJ1eXljZmZHMG1hSitsVHRX?=
 =?utf-8?B?OTk3Zit0dnFiMDlzOG1UNkJyRVl5cGV1aHZWeEpseE5VeUZnejNSbTJPSDhD?=
 =?utf-8?B?RDFDYVpyRDkvMHVua1p1R1c3SEtoelQ5aUJDUXo5ditBWFFjQzQwMUV2VzM5?=
 =?utf-8?B?a1YxUDlXR3BUV1VrM25OMElrV1dGbjRVYWVQaTd3YzEySWdCV2R2anplclZB?=
 =?utf-8?B?MFUxaTZCVFBKSFh1TFcxbktacldSaWJHL1diYzJTRTBiTWxJQktjOXI1Ung0?=
 =?utf-8?B?Z3VJMENrSVIrVUZZcGg2SGNiL1JHS2VMNGNpSzBHL1pUdnRKUHdlSTNreEdw?=
 =?utf-8?B?SW9oTTdUdG56MjRMRThXUU8zNFJQWFdqNklXSFNvNG1Sazl3V0pQdVZuUGRH?=
 =?utf-8?B?OXB5MzdVRTNrKzltTHNEYjBGYzRsVUlCb0N5dHNsQXBsQzhQUjJuN01OZWx2?=
 =?utf-8?B?cTJnUEM5UjNTUmxRVndNNmxidERnVkdtcy8rN3BPSVBOMjdkUldJMFVHWEUv?=
 =?utf-8?B?QnRUVVkzV1U5MFZNRGc4ZkIzeTFadDZnVnFXTTZsbVVwanRQSTE4ZHUzZXBK?=
 =?utf-8?B?YmdpSENxdHkrTm1UaFlvOGVTRVpKU01iWmtsdlJFZklCZGNsakhpK1V0T0N6?=
 =?utf-8?B?QmpVc3pMc0t6WmdyVWhLQjNrZ3drMXpaZDJSY3pxT3YxTk42NVRvYkhITzYz?=
 =?utf-8?B?UEF2MGNodHBTTlpqVmRLdWVHeTUrK1plcTBuUFlKUnNiSnRuWDRlUSthV3M1?=
 =?utf-8?B?amhLbHJ3Wk9kUDBMTkxXbzJsWHdjdWRoR29LSzJ0K3VGdlY3cllvbDFaQW1v?=
 =?utf-8?B?TWNHTDVGZHR6UVJFcDZjQm1pcVdmZnAzN0VabVJ2YzBiUTBZK1dSY1pNK2lm?=
 =?utf-8?B?b3ZHQWhiQnRRQTNKNjRodEU5Z3pLUzVaME5GcGJCZEdPK0hLKy85OC9vc0dC?=
 =?utf-8?B?ME5Yd0w5aE4vK0pKdTFNYmliaHFPRDhYZHZvZHlvTzVuTE9Fb1NQNGZndVZY?=
 =?utf-8?B?MVFoMVdtelRoRE1mUGxhT1ZlaW9Ya0t2UDdOakw2czlLV1p4V05BMHV1QXRQ?=
 =?utf-8?B?VDFRNDlvVXZQVU11V1h4WkgzK0JGMjZodWNlTExaWGZ2OUswOUJkTEZiUHVn?=
 =?utf-8?B?UXI5U1Qvb3RrUzFVSkR6S091NjVBWG5TcFBBeTczZ3N6K0VvN1ZwUFZDYUpG?=
 =?utf-8?Q?MGw9j3WBL2z00Zy0ip7vUhE2A?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 0002ef93-5fa6-4258-9143-08db62801e43
X-MS-Exchange-CrossTenant-AuthSource: AS8PR02MB9651.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jun 2023 09:11:00.7505
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 78703d3c-b907-432f-b066-88f7af9ca3af
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 8CYJiarhT8uw1mbnG1NMjnxPMYpOu67ZxgWe2is9UtlnSTUtGa2lKgZX7VnIjtPwsp3Jpz3XgV/NnabowK8F2Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR02MB6025
X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_MED,
        SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 5/30/23 19:28, Andrew Lunn wrote:
> On Tue, May 30, 2023 at 04:52:23PM +0200, Andreas Svensson wrote:
>> A switch held in reset by default needs to wait longer until we can
>> reliably detect it.
>>
>> An issue was observed when testing on the Marvell 88E6393X (Link Street).
>> The driver failed to detect the switch on some upstarts. Increasing the
>> wait time after reset deactivation solves this issue.
>>
>> The updated wait time is now also the same as the wait time in the
>> mv88e6xxx_hardware_reset function.
> 
> Do you have an EEPROM attached and content in it?

There's no EEPROM attached to the switch in our design.

> 
> It is not necessarily the reset itself which is the problem, but how
> long it takes after the reset to read the contents of the
> EEPROM. While it is doing that, is does not respond on the MDIO
> bus. Which is why mv88e6xxx_hardware_reset() polls for that to
> complete.

Ok, yes that makes sense. I could add the mv88e6xxx_g1_wait_eeprom_done
function after the reset deactivation.

> 
> I know there are some users who want the switch to boot as fast as
> possible, and don't really want the additional 9ms delay. But this is
> also a legitimate change. I'm just wondering if we need to consider a
> DT property here for those with EEPROM content. Or, if there is an
> interrupt line, wait for the EEPROM complete interrupt. We just have
> tricky chicken and egg problems. At this point in time, we don't
> actually know if the devices exists or not.
> 
> 	  Andrew

It just seems like we need to wait longer for the switch 88E6393X
until it responds reliably on the MDIO bus. But I'm open to adding
a new DT property if that's needed.

The datasheet for 88E6393X also states that it needs at least 10ms
before it's ready. But I suppose this varies from switch to switch.

Best Regards,
Andreas Svensson