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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E17C4C433EF for ; Thu, 27 Jan 2022 15:19:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:References: List-Owner; bh=2H3g2SEdMgMzMkhGboZN2GLdp3f4+x65d3aah1itXao=; b=sqHd0qZ9qMX97l JcrZQZBpWVNaMQzWB/NtrIwbUtDnE58YzibIobjqSidQpMLDhl2p1BVDMR1j4cQ+aD6xyP7rLqp4j r59L0eTRMh5v8mWDIRSumjhlIkDTX2KChE0UKM8SJeZEupwzQY4A1r/pAS6OGwe82wBkL+PpFMsdv b71SNkPsUeUHBwfYvwA7jJfNeENQg57rycc0Mu9TrrP/Z6mXg93FxJDWIiVpJFZa95QkW/qBsCnuU 1jcnSvCFHL3pVGjNCk+62QdeYG15kXPk2amiDxnGpNVdE9a7NJhGgsrQFnLiQhTneNSTczKQg5gfv NGYACPkJ6Kdgejq5RK+A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nD6Vq-00GBvr-0A; Thu, 27 Jan 2022 15:16:38 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nD6Vm-00GBvI-1h for linux-arm-kernel@lists.infradead.org; Thu, 27 Jan 2022 15:16:35 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 0A12560B4F; Thu, 27 Jan 2022 15:16:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2A4C8C340E4; Thu, 27 Jan 2022 15:16:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643296592; bh=6zdI64JO16o4OH7ihIB0tyhcoVY66C9Jpg96cHbKPds=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=hACrKDFLEvnRX2070s40MHT2rdBP6mAneFCTf5+sefDmyVuNOGFCIC+g+qN1028um /Ibeid44iPpekMbYboRKsakO/x6MVfzNQPdB8yJ8JzSZHsykf5XfI+XmzMPOip4Ju0 INLL1ozY5XoDNN765dpagbrWTf0+RrXW5U/q+eEfv1zHAyHfbAD2zItMPuvBXue1T9 q7ELjwNJJMEOe7G0mZ3FhoPBZbjGulwhA+2755cC+5ztRRFM22NZkifhGHTmP84frZ IDdxkI2cDy2xYx4dpEivf0rNZ975DUGdHd/fbKBcjeU8R//VHo6dQjRLWNeGX0XY9N 9Slo4T7bqdY5g== Date: Thu, 27 Jan 2022 09:16:30 -0600 From: Bjorn Helgaas To: Baruch Siach Cc: Andy Gross , Bjorn Andersson , Selvam Sathappan Periakaruppan , Kathiravan T , Bjorn Helgaas , Rob Herring , Thierry Reding , Jonathan Hunter , Jingoo Han , Gustavo Pimentel , Robert Marko , Bryan O'Donoghue , linux-pci@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-tegra@vger.kernel.org Subject: Re: [PATCH v5 3/3] PCI: qcom: add support for IPQ60xx PCIe controller Message-ID: <20220127151630.GA100574@bhelgaas> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8735lc9r9d.fsf@tarshish> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220127_071634_175597_EC416D2A X-CRM114-Status: GOOD ( 21.53 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jan 25, 2022 at 09:41:45AM +0200, Baruch Siach wrote: > On Mon, Jan 24 2022, Bjorn Helgaas wrote: > > On Mon, Jan 24, 2022 at 06:27:31PM +0200, Baruch Siach wrote: > >> +static int qcom_pcie_init_2_9_0(struct qcom_pcie *pcie) > >> +{ > >> + struct qcom_pcie_resources_2_9_0 *res = &pcie->res.v2_9_0; > >> + struct device *dev = pcie->pci->dev; > >> + int ret; > >> + > >> + ret = reset_control_assert(res->rst); > >> + if (ret) { > >> + dev_err(dev, "reset assert failed (%d)\n", ret); > >> + return ret; > >> + } > >> + > >> + usleep_range(2000, 2500); > > > > Where do these sleep durations come from? If they're specified > > somewhere by PCIe, can you include a citation, e.g., a section number > > in the spec. > > As I mentioned before, I have no access to hardware documentation. I'm > only porting working code from downstream kernel. > > In a comment on v4 Bjorn Andersson mentioned "datasheet stating the > minimum timing of the operations to be performed to get the PCIe > controller into a known (clean) state". Sorry if I'm repeating questions. We can help avoid that by adding a brief comment here like "black magic copied from working code at X" or whatever you *do* know. Repeated questions are wasted effort for both the author and reviewers. Sleeps with unsourced durations are always suspect because nobody wants to wait longer than necessary, and if all we have is a bare number and nobody knows how it was derived, we can't be confident about changing it. > https://lore.kernel.org/all/Ydd5Wh0KeADBQ%2Fh1@ripper/ > > I have no further details. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel