From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0F70DC0015E for ; Fri, 14 Jul 2023 08:55:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235687AbjGNIzd (ORCPT ); Fri, 14 Jul 2023 04:55:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59586 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235464AbjGNIzb (ORCPT ); Fri, 14 Jul 2023 04:55:31 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 96F25198A; Fri, 14 Jul 2023 01:55:30 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 315DA61CAD; Fri, 14 Jul 2023 08:55:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 85BACC433C7; Fri, 14 Jul 2023 08:55:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689324929; bh=xdDf7J7wabwwPPB+N1BvY/uSNfnGVhm7ZROnIm0p/5Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FMgYoOahrvkogcf5KQkChhRaST3bloYhS2133a16LmXrB+jLLypPWfg5s3h980Q7B dPw70+y61HTYkjwcD9HaqTJuO7Kz7V8Ura3Owh9wU/bz4ixATwQABqwf6RHy0O3JJ+ rhsYYh+XDJ6LbdGjOT5VihuKX+hl0pcmeL0yFgaunyt2kui0yb4QqQEnron+jGQOGz nQl04P5F7xw4j4Ory6Dy5RhWoVeJRUCoNQIENhMeRZ4NjC7ekmbHKNv47wnsRdB0Ua LL4jdDay9N0m89Dn1Z3/JjTr+fmkMud94GpnIfIBuZFnOizgeJVR0eHhcgTJ+E4kiy 8VQvGNXLEzJmg== Received: from johan by xi.lan with local (Exim 4.96) (envelope-from ) id 1qKEaH-0006W1-29; Fri, 14 Jul 2023 10:55:30 +0200 Date: Fri, 14 Jul 2023 10:55:29 +0200 From: Johan Hovold To: Ajay Agarwal Cc: Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Manivannan Sadhasivam , Lorenzo Pieralisi , Jingoo Han , Gustavo Pimentel , Rob Herring , Bjorn Helgaas , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Bjorn Andersson , Sajid Dalvi Subject: Re: [PATCH] Revert "PCI: dwc: Wait for link up only if link is started" Message-ID: References: <20230706082610.26584-1-johan+linaro@kernel.org> <20230706125811.GD4808@thinkpad> <20230710170608.GA346178@rocinante> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 12, 2023 at 11:15:54PM +0530, Ajay Agarwal wrote: > On Tue, Jul 11, 2023 at 08:52:23AM +0200, Johan Hovold wrote: > > All mainline drivers already start the link before that > > wait-for-link-up, so the commit in question makes very little sense. > > That's why I prefer reverting it, so as to not pollute the git logs > > (e.g. for git blame) with misleading justifications. > I am developing a PCIe driver which will not have the start_link > callback defined. Instead, the link will be coming up much later based > on some other trigger. So my driver will not attempt the LTSSM training > on probe. So even if the probe is made asynchronous, it will still end > up wasting 1 second of time. Yeah, I had the suspicion that this was really motivated by some out-of-tree driver, which as I'm sure you know, is not a concern for mainline. Vendor drivers do all sorts of crazy stuff and we don't carry code in mainline for the sole benefit of such drivers that have not been upstreamed (and likely never will be). So again, I think this patch should just be reverted. If you want to get something like this in, you can send a follow-on patch describing your actual motivation and use case. But as it appears to boil down to "I need this for my out-of-tree driver", I suspect such a patch would still be rejected. Johan