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 X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 53B53C4360F for ; Thu, 4 Apr 2019 18:58:27 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 2807F20820 for ; Thu, 4 Apr 2019 18:58:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="I0cI8j7D"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Yff9bA6z" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2807F20820 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=3W0Nwz43aLxDk6qJHo8yxnpluFG/sqrtvHwS3xi4eZg=; b=I0cI8j7DSNBntC n1ouO3kG6kTfWjrOJM/wEgRuJrG5+jSO0pnFm5z8MhP1MAEa8Hh0EhUMSynElRRt0vcjgdMvqXpHW td5s6jTOeXSOlCZq0bvMN3nWtEoXXGr9WDgg5Zhj08G7LPAlKUq8X5wYsv6EH0OhTM6FtNYQPb1hX 53O1Oic5fRGXRWP5djOlN84EmjdcW5SdcX5pUqxHYd4GO06xo3ZNKRxDSOpGii5hdvYM/S2VZJALl fMSX2QI6rXZBTur5ndmmSBZXLFsozOfp+iK6P0ocLboVtRfqNeKNQ+VxpJ0LvseYJxeUpUvTbehV2 QHqL04oOi+jRQV2E9s+w==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hC7Z6-0003I9-WF; Thu, 04 Apr 2019 18:58:21 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hC7Z3-0003HC-UG for linux-arm-kernel@lists.infradead.org; Thu, 04 Apr 2019 18:58:19 +0000 Received: from localhost (odyssey.drury.edu [64.22.249.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2D4042075E; Thu, 4 Apr 2019 18:58:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1554404296; bh=6ExJ9046PCPNSnwgHJ0lFpyBupkZefxFZh1kFArbs50=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Yff9bA6zROCoAHa4Q2WOOlquYTiBHd1/StocSZUebTK3/ljoyrQ8RLrf3HMY3RAr8 T2CxX/pdI5pB+3qu1LRNYaJiz+BfPdTxRuucUVoIl3KSoS+IAnYjheHeLd3C19/+G7 wOgClwo3vYpHlxRKZgzqOJL81EqWSCL2uzEKEGjg= Date: Thu, 4 Apr 2019 13:58:15 -0500 From: Bjorn Helgaas To: Guenter Roeck Subject: Re: [PATCH v3 3/4] lib: logic_pio: Reject accesses to unregistered CPU MMIO regions Message-ID: <20190404185815.GA26522@google.com> References: <1554393602-152448-1-git-send-email-john.garry@huawei.com> <1554393602-152448-4-git-send-email-john.garry@huawei.com> <20190404164130.GA12203@roeck-us.net> <24cc8006-0f0d-6b20-a466-e4a32a0bb656@huawei.com> <20190404174336.GA10404@roeck-us.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190404174336.GA10404@roeck-us.net> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190404_115817_995123_1865021E X-CRM114-Status: GOOD ( 15.69 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: wangkefeng.wang@huawei.com, lorenzo.pieralisi@arm.com, arnd@arndb.de, rafael@kernel.org, linux-pci@vger.kernel.org, John Garry , will.deacon@arm.com, linux-kernel@vger.kernel.org, linuxarm@huawei.com, andy.shevchenko@gmail.com, catalin.marinas@arm.com, bp@suse.de, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Apr 04, 2019 at 10:43:36AM -0700, Guenter Roeck wrote: > On Thu, Apr 04, 2019 at 05:52:35PM +0100, John Garry wrote: > > >>Note that the f71805f driver does not call > > >>request_{muxed_}region(), as it should. > > > > >... which is the real problem, one that is not solved by this > > >patch. This may result in parallel and descructive accesses if > > >there is another device on the LPC bus, and another driver > > >accessing that device. Personally I'd rather have > > >request_muxed_region() added to the f71805f driver. > > > > Right, we should and will still fix f71805f. If you recall, I did > > have the f71805f fix in the v1 series, but you committed that it > > was orthogonal, so I decided to take it out of this work for now. > > > > And even if we fix up f71805f and other known drivers which don't > > call request_muxed_region(), we still need to police against these > > rogue accesses, which is what this patch attempts to do. > > > Do we ? I am personally not convinced that LPC accesses _have_ to > occur through PCI on any given system. On current systems, I suspect ISA/LPC devices are typically connected via a PCI-to-ISA/LPC bridge. But AFAIK there's no actual requirement for that bridge, and there certainly *were* systems with ISA devices but no PCI at all. IMO, if you want to build ISA drivers on your arch, you need to make sure the inb() probing done by those drivers works like it does on x86. If there's no device there, the inb() should return 0xff with no fuss and no crash. Bjorn _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel