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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8BC4CC46467 for ; Mon, 16 Jan 2023 12:39:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230202AbjAPMjQ (ORCPT ); Mon, 16 Jan 2023 07:39:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34262 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230286AbjAPMjP (ORCPT ); Mon, 16 Jan 2023 07:39:15 -0500 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D68F51BAC7; Mon, 16 Jan 2023 04:39:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1673872754; x=1705408754; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=NsxSQXRA1+OPD1T485eedwEPZNoRWfbPHxonr1F3p8k=; b=Beu3qnju9uLthjzEgi0/9LCMeWckAWx64yieew4T3rV/mvTpORs51y5Y a+AkyVi1eMNmjSYTvCqeSbWpevRMpUvNY4ulx/vCc0+uBaljoXXEUygV1 r3sp4PM7kX9+YZZq/1fYfwNnjYKXMWsXKxClWYxe0XYE4Ecy8kfx4y6OG JDdAzPMXDSab/X5GUgHwsd3fgAyDrOy7KDKzu7dxg/ZjMgLYeBQmbmdrv zMBUJNrU/IVwdw0KcanqRKV749rgbuWMchvszNzbVeCpypVwuiPzpWHBw 0zb1Xia41B1s+MVG5AUHRyAMracGYNIlMD+oUCrYB/Rrp/eecba+jUefl w==; X-IronPort-AV: E=McAfee;i="6500,9779,10591"; a="325717846" X-IronPort-AV: E=Sophos;i="5.97,221,1669104000"; d="scan'208";a="325717846" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jan 2023 04:38:52 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10591"; a="766869030" X-IronPort-AV: E=Sophos;i="5.97,220,1669104000"; d="scan'208";a="766869030" Received: from smile.fi.intel.com ([10.237.72.54]) by fmsmga002.fm.intel.com with ESMTP; 16 Jan 2023 04:38:49 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1pHOlD-00A4JX-0L; Mon, 16 Jan 2023 14:38:47 +0200 Date: Mon, 16 Jan 2023 14:38:46 +0200 From: Andy Shevchenko To: Jan =?utf-8?B?RMSFYnJvxZs=?= Cc: Borislav Petkov , "Limonciello, Mario" , Borislav Petkov , Hans de Goede , linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org, jarkko.nikula@linux.intel.com, wsa@kernel.org, rrangel@chromium.org, upstream@semihalf.com, Muralidhara M K , Naveen Krishna Chatradhi , Yazen Ghannam Subject: Re: [PATCH -next 1/2] i2c: designware: Switch from using MMIO access to SMN access Message-ID: References: <33d5cc27-474b-fdec-a6b0-84ac16f7d386@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-i2c@vger.kernel.org On Mon, Jan 16, 2023 at 11:19:00AM +0100, Jan Dąbroś wrote: > Hi Borislav, > > > Make init_amd_nbs() arch_initcall_sync() so that it executes after PCI init. > > I described earlier in this thread why such option is not working - > let me quote myself: > > It's not enough for running init_amd_nbs() to have only > pci_arch_init() done. We need the pci bus to be created and registered > with all devices found on the bus. We are traversing through them and > trying to find northbridge VID/DID. Due to the above, we need to run > init_amd_nbs() only after acpi_scan_init() that is invoked from > acpi_init() which is registered as subsys_initcall. That's why the > trick with switching init_amd_nbs() to arch_initcall_sync will not > work. > > We have a kind of chicken-and-egg problem here. Or is there something I missed? > > I wonder if there is upstreamable option to control order of the > drivers' init by forcing link order? But what exactly do you need from North Bridge? Is it only its existence or do you need to have fully instantiated PCI device (if so, why?)? -- With Best Regards, Andy Shevchenko