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 D4C4EC433F5 for ; Fri, 7 Jan 2022 21:56:41 +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=JBJK2OL5c2tttrvPCFnbXFLGKAwNFKOnqajAch3TQBc=; b=GEgc15i4E8LPv6 nNIaD02PVM+8EKoQyU5ZFKPggSpMJhi/q5OtnE9rDF2qLMC1umsRvzA4mIb0wq+sAk2Ri8WA9V4st FhZUufxy2sbmdvFe/YTB+pgzqPT65RD5ps2UL/NpFtYyDbqN8hyLe0PP27YOhSdZCuiXc4SjgPrj+ x7IjW2xEg7wnssfle1VcmTUBFdCISU4nOXypY/daHBER9v95kl+FTvDxO8LSnMB45JL3//5dw4Txr vVGBIl1G+2/DrygqgAQdaw+WhFGFieMsaMComTJAV0olc6rUnMFPsucsd6xiTf4od6uN3QAODDulN 6Oxg/0AWmWhaeoYpNrzg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n5xCZ-005JSp-3L; Fri, 07 Jan 2022 21:55:11 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n5xCV-005JS6-Lo for linux-arm-kernel@lists.infradead.org; Fri, 07 Jan 2022 21:55:08 +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 0EE0A60EED; Fri, 7 Jan 2022 21:55:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 305B8C36AE5; Fri, 7 Jan 2022 21:55:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1641592506; bh=HgYX2Xd0D0iuYUqUJO/K8O0+08VNCD8SxUseluRKNRE=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=sOuGiD4rcOoj8+I99d5UuB7lYWYvj2SV1qtC2748LbEzT2Btpmsr7tVPu+mMEcl+2 ZgbsIwSJ8x+FE3W01aKY+XGJatcjCgcRKFQ+PqccL3RdeLywQQvG24IgPgFc0nyH+3 7t9fT2lYUKMv/0gYGhg21u8tLU/kBAvlA2rtGkHC9pRuMyAK+bgtUxb/fw1S/1cUBR 6GBisCHGHGQ28BrUs+M+9dwao2+OiXFFjqQrvp4qPwyJYkhXTDQOkt4NTTr4i4aZPh pdVmgdAxnppQP5cwZTHkpN9l12qhQc3U95O9SQT/cXqU/yUvGNRIy4JL+TGZpGQNqv 6FFm8pJ4cLCyA== Date: Fri, 7 Jan 2022 15:55:04 -0600 From: Bjorn Helgaas To: Pali =?iso-8859-1?Q?Roh=E1r?= Cc: Thomas Petazzoni , Lorenzo Pieralisi , Rob Herring , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Bjorn Helgaas , Marek =?iso-8859-1?Q?Beh=FAn?= , linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 08/15] PCI: mvebu: Propagate errors when updating PCI_IO_BASE and PCI_MEM_BASE registers Message-ID: <20220107215504.GA406217@bhelgaas> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20211125124605.25915-9-pali@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220107_135507_779721_C4E51FBE X-CRM114-Status: GOOD ( 13.30 ) 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Nov 25, 2021 at 01:45:58PM +0100, Pali Roh=E1r wrote: > Properly propagate failure from mvebu_pcie_add_windows() function back to > the caller mvebu_pci_bridge_emul_base_conf_write() and correctly updates > PCI_IO_BASE, PCI_MEM_BASE and PCI_IO_BASE_UPPER16 registers on error. > On error set base value higher than limit value which indicates that > address range is disabled. = Does the spec say that if software programs something invalid, hardware should proactively set the base and limit registers to disable the window? I'm not sure I've seen hardware that does this, and it seems ... maybe a little aggressive. What happens if software writes the base and limit in the wrong order, so the window is invalid after the first write but valid after the second? That actually sounds like it could be a sensible strategy to prevent a partially-configured window from being active. Bjorn _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel