Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2000540pxb; Mon, 8 Mar 2021 11:20:45 -0800 (PST) X-Google-Smtp-Source: ABdhPJzZZF/2Rff6Gc1ufWZfKTE6LvvO9RZoaYBd+0mZBCKS52DiAf74ioXpzfEMocCukcJZorir X-Received: by 2002:a17:906:fc1c:: with SMTP id ov28mr16515144ejb.342.1615231245707; Mon, 08 Mar 2021 11:20:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615231245; cv=none; d=google.com; s=arc-20160816; b=THVmDv5s69qdbI/ylfqNC+Hh4X1aaFWnp8zdtlVWJS8l+RnM4FMTJQOqgfz/CrkMLL 6gT9f9TC1Wvg5NijbYN/tEj5ki/agI6kMmdCWW3OSkpy6RN2b8JwXrgzE5/3nlAB+ZU+ e+sg1VRK4joPL40Gy9mMnEFDlGRf8vgAFAkdownHT/ml9/JN18ZlE+rC5msVWrGjIBhq x8XV6mtsn0sC0slmilXkT5fPMeayximcddKZ6spu2IT71CeUKNk6ks8/Sq/putt2DMD5 DSAJ1+zHApZcFwtVPnDkUPLqUjYqWVGovYp9VJ5vN9jPABl0D1KYi9xJScA0Dm3Rhppn vpsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :ironport-sdr:ironport-sdr; bh=H8jBkjcFjjrHTaH9DBX2NbVCPN+1rw+VGbhPC9LzDB0=; b=Og6Axf2oES+mCqpLnKkVvmL8j/gpPat1QUoMnsf2d2IJ4Y/BbbjdA81Oy0/wR14Gwx 618MbO94SSBGQP+7LHxgmMuDWVspiwGhk1gra21aVC3307nzmZ3507zj1JbarV/Ba63K jDvXipP2rFDaChf9APHdqdjZieKrSsl6hvtbrt4x/jJx1GEikBQ0oiDicpd0BND1uFf4 10khTJgbsU7MPfRqK3EsZSEHhG5AogtO40tE4glMopFxZztCTRVL8LtLxh0RxdD7IpR8 lhh7UF16/Qe7asKi6pstYLVd1R3s9m6MZd0PqUTs5mRFgKfBFoV9FlvN+534ELdgpqed v6Cw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a9si3703140edr.332.2021.03.08.11.20.22; Mon, 08 Mar 2021 11:20:45 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230320AbhCHTRH (ORCPT + 99 others); Mon, 8 Mar 2021 14:17:07 -0500 Received: from mga18.intel.com ([134.134.136.126]:7497 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229701AbhCHTQ6 (ORCPT ); Mon, 8 Mar 2021 14:16:58 -0500 IronPort-SDR: 5AZ4rRs3TrWafxpM/u/BgdhIL8TIp1a6FDAbZOEzFlTWaA8OoZXNwX6/ZhGXS9N9lApSXxj2Ba iDZE99IrCD9A== X-IronPort-AV: E=McAfee;i="6000,8403,9917"; a="175704374" X-IronPort-AV: E=Sophos;i="5.81,233,1610438400"; d="scan'208";a="175704374" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Mar 2021 11:16:57 -0800 IronPort-SDR: xCEhKGvn12MnWivwFnLJwGcSstpYUBabTQLIVR+SWBzzbKV+opX+SgcBGE/inQcgN8s8i3qkGz h2+dCiGfnQSg== X-IronPort-AV: E=Sophos;i="5.81,233,1610438400"; d="scan'208";a="437595267" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Mar 2021 11:16:53 -0800 Received: from andy by smile with local (Exim 4.94) (envelope-from ) id 1lJLN4-00AtQQ-HD; Mon, 08 Mar 2021 21:16:50 +0200 Date: Mon, 8 Mar 2021 21:16:50 +0200 From: Andy Shevchenko To: Bjorn Helgaas Cc: 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, henning.schild@siemens.com Subject: Re: [PATCH v1 3/7] PCI: New Primary to Sideband (P2SB) bridge support library Message-ID: References: <20210308122020.57071-4-andriy.shevchenko@linux.intel.com> <20210308185212.GA1790506@bjorn-Precision-5520> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210308185212.GA1790506@bjorn-Precision-5520> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 08, 2021 at 12:52:12PM -0600, Bjorn Helgaas wrote: > On Mon, Mar 08, 2021 at 02:20:16PM +0200, Andy Shevchenko wrote: > > From: Jonathan Yong > > > > There is already one and at least one more user is coming which > > requires an access to Primary to Sideband bridge (P2SB) in order to > > get IO or MMIO bar hidden by BIOS. Create a library to access P2SB > > for x86 devices. > > Can you include a spec reference? I'm not sure I have a public link to the spec. It's the 100 Series PCH [1]. The document number to look for is 546955 [2] and there actually a bit of information about this. > I'm trying to figure out why this > belongs in drivers/pci/. It looks very device-specific. Because it's all about access to PCI configuration spaces of the (hidden) devices. [1]: https://ark.intel.com/content/www/us/en/ark/products/series/98456/intel-100-series-desktop-chipsets.html [2]: https://medium.com/@jacksonchen_43335/bios-gpio-p2sb-70e9b829b403 ... > > +config PCI_P2SB > > + bool "Primary to Sideband (P2SB) bridge access support" > > + depends on PCI && X86 > > + help > > + The Primary to Sideband bridge is an interface to some PCI > > + devices connected through it. In particular, SPI NOR > > + controller in Intel Apollo Lake SoC is one of such devices. > > This doesn't sound like a "bridge". If it's a bridge, what's on the > primary (upstream) side? What's on the secondary side? What > resources are passed through the bridge, i.e., what transactions does > it transfer from one side to the other? It's a confusion terminology here. It's a Bridge according to the spec, but it is *not* a PCI Bridge as you may had a first impression. ... > > + /* Unhide the P2SB device */ > > + pci_bus_write_config_byte(bus, df, P2SBC_HIDE_BYTE, 0); > > + > > + /* Read the first BAR of the device in question */ > > + __pci_bus_read_base(bus, devfn, pci_bar_unknown, mem, PCI_BASE_ADDRESS_0, true); > > I don't get this. Apparently this normally hidden device is consuming > PCI address space. The PCI core needs to know about this. If it > doesn't, the PCI core may assign this space to another device. Right, it returns all 1:s to any request so PCI core *thinks* it's plugged off (like D3cold or so). > > + /* Hide the P2SB device */ > > + pci_bus_write_config_byte(bus, df, P2SBC_HIDE_BYTE, P2SBC_HIDE_BIT); -- With Best Regards, Andy Shevchenko