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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 2995EC07E9C for ; Mon, 12 Jul 2021 12:12:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0A9CE61153 for ; Mon, 12 Jul 2021 12:12:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233501AbhGLMOw (ORCPT ); Mon, 12 Jul 2021 08:14:52 -0400 Received: from mga14.intel.com ([192.55.52.115]:52381 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230074AbhGLMOw (ORCPT ); Mon, 12 Jul 2021 08:14:52 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10042"; a="209785552" X-IronPort-AV: E=Sophos;i="5.84,232,1620716400"; d="scan'208";a="209785552" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jul 2021 05:12:03 -0700 X-IronPort-AV: E=Sophos;i="5.84,232,1620716400"; d="scan'208";a="652927011" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jul 2021 05:12:00 -0700 Received: from andy by smile with local (Exim 4.94.2) (envelope-from ) id 1m2umv-00CDOQ-W1; Mon, 12 Jul 2021 15:11:53 +0300 Date: Mon, 12 Jul 2021 15:11:53 +0300 From: Andy Shevchenko To: Henning Schild Cc: "Enrico Weigelt, metux IT consult" , Bjorn Helgaas , Wolfram Sang , Jean Delvare , Lee Jones , Tan Jui Nee , Jim Quinlan , Jonathan Yong , Bjorn Helgaas , linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org, linux-pci@vger.kernel.org, Jean Delvare , Peter Tyser , hdegoede@redhat.com Subject: Re: [PATCH v1 3/7] PCI: New Primary to Sideband (P2SB) bridge support library Message-ID: References: <20210309014221.GA1831206@bjorn-Precision-5520> <20210309094252.396b7f2d@md1za8fc.ad001.siemens.net> <3f33a178-3002-e93e-89f1-8cf05097da25@metux.net> <20210406154001.3eec0698@md1za8fc.ad001.siemens.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210406154001.3eec0698@md1za8fc.ad001.siemens.net> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-i2c@vger.kernel.org On Tue, Apr 06, 2021 at 03:40:01PM +0200, Henning Schild wrote: > Am Fri, 2 Apr 2021 15:09:12 +0200 > schrieb "Enrico Weigelt, metux IT consult" : > > > On 09.03.21 09:42, Henning Schild wrote: > > > > > The device will respond to MMIO while being hidden. I am afraid > > > nothing stops a collision, except for the assumption that the BIOS > > > is always right and PCI devices never get remapped. But just > > > guessing here. > > > > What could go wrong if it is remapped, except that this driver would > > write to the wrong mmio space ? > > > > If it's unhidden, pci-core should see it and start the usual probing, > > right ? > > I have seen this guy exposed to Linux on coreboot machines. No issues. > But i can imagine BIOSs that somehow make use of the device and assume > it wont move. So we would at least need a parameter to allow keeping > that device hidden, or "fixed" in memory. I'm wondering if they have pin control device described in the ACPI. If so, how in that case you prevent double initialisation? We would need to check both: P2SB and ACPI tables. Basically if we enable P2SB as a PCI device we may create a corresponding driver (somewhere under drivers/pci or PDx86) and check in its probe that ACPI device is also present and functional. -- With Best Regards, Andy Shevchenko