Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 16 Jan 2023 19:48:09 +0200
From:   Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To:     "Limonciello, Mario" <Mario.Limonciello@amd.com>
Cc:     Jan =?utf-8?B?RMSFYnJvxZs=?= <jsd@semihalf.com>,
        Borislav Petkov <bp@alien8.de>, Borislav Petkov <bp@suse.de>,
        Hans de Goede <hdegoede@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
        "jarkko.nikula@linux.intel.com" <jarkko.nikula@linux.intel.com>,
        "wsa@kernel.org" <wsa@kernel.org>,
        "rrangel@chromium.org" <rrangel@chromium.org>,
        "upstream@semihalf.com" <upstream@semihalf.com>,
        "M K, Muralidhara" <Muralidhara.MK@amd.com>,
        "Chatradhi, Naveen Krishna" <NaveenKrishna.Chatradhi@amd.com>,
        "Ghannam, Yazen" <Yazen.Ghannam@amd.com>
Subject: Re: [PATCH -next 1/2] i2c: designware: Switch from using MMIO access
 to SMN access
Message-ID: <Y8WN2ZTnnVDgVlZB@smile.fi.intel.com>
References: <c0c8bdce-26a0-ad3f-749b-7585d947608b@redhat.com>
 <YyxrdpUyc+kp48kX@zn.tnic>
 <33d5cc27-474b-fdec-a6b0-84ac16f7d386@redhat.com>
 <CAOtMz3M=BTZUTRMHWGULwMDWmGdOzHKo=UcZeg3sP8_ndVYk2g@mail.gmail.com>
 <YzG657ZFeEvLd6hm@zn.tnic>
 <CAOtMz3MWnmdMbw_CKxBKVt=TJpLNJuZUzpxvnDi+QnigaLozLA@mail.gmail.com>
 <Y7v2j92Ol6dL3FLE@zn.tnic>
 <CAOtMz3PG4nku-O7dh+1U_DA05HAmQboTqwUQkCkrXQLV9bFjPw@mail.gmail.com>
 <Y8VFVmhqP8dpqZcQ@smile.fi.intel.com>
 <MN0PR12MB6101E79DA61CB0154C4819B2E2C19@MN0PR12MB6101.namprd12.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <MN0PR12MB6101E79DA61CB0154C4819B2E2C19@MN0PR12MB6101.namprd12.prod.outlook.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Precedence: bulk

On Mon, Jan 16, 2023 at 04:22:09PM +0000, Limonciello, Mario wrote:
> > From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Sent: Monday, January 16, 2023 06:39
> > To: Jan Dąbroś <jsd@semihalf.com>
> > On Mon, Jan 16, 2023 at 11:19:00AM +0100, Jan Dąbroś wrote:

> > > > 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?)?
> 
> There is a need to be able to write and read PCI config space.

So, it's available even on early stages, are there some specifics why it can't
be done using the respective APIs?

-- 
With Best Regards,
Andy Shevchenko