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 11FB4C6FA82 for ; Thu, 22 Sep 2022 09:51:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231135AbiIVJvY (ORCPT ); Thu, 22 Sep 2022 05:51:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45938 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229713AbiIVJvV (ORCPT ); Thu, 22 Sep 2022 05:51:21 -0400 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C4624D6921; Thu, 22 Sep 2022 02:51:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663840280; x=1695376280; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=tTaBK+DjBfucGFWPWzGuutlagPaerU/MshiXq/Ty9nM=; b=fUZ8jP7Iqqe483VQaKB0v0QLDqMCDq6Wo/pfuLKA9yEulp3JCMHsypYs dCP9Dr95qGIGYFxeGHd/bmgXMpMhXyWyxNuEXrcuFHvJ/JzTKl8+ZRMVd OEin7seiknpr6Y18jWLYYyf0fgixDh/7SMTEUVdZp0Tjqw/Gt38nFCYK6 1ya0t0xrpJVobL/7PxQyHnmmMOn0uhxR3Fk6QEwFNEzapfUE+FTahv7co NaaYoCt25J2EHNORnC/u3Ci6uRMc14gATrYo2++d6PQ35Im9+1N2IpUBj dxzxwOtMVKBILG8O4nCiodbauY8sjCm0hinZAkrMUP8Y8TnQamlLg6c8/ A==; X-IronPort-AV: E=McAfee;i="6500,9779,10477"; a="283306198" X-IronPort-AV: E=Sophos;i="5.93,335,1654585200"; d="scan'208";a="283306198" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2022 02:51:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.93,335,1654585200"; d="scan'208";a="650456489" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga008.jf.intel.com with ESMTP; 22 Sep 2022 02:51:17 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1obIrT-005wxh-0K; Thu, 22 Sep 2022 12:51:15 +0300 Date: Thu, 22 Sep 2022 12:51:14 +0300 From: Andy Shevchenko To: Borislav Petkov , Hans de Goede Cc: "Limonciello, Mario" , Jan =?utf-8?B?RMSFYnJvxZs=?= , 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 Subject: Re: [PATCH -next 1/2] i2c: designware: Switch from using MMIO access to SMN access Message-ID: References: <20220916131854.687371-1-jsd@semihalf.com> <20220916131854.687371-2-jsd@semihalf.com> <60a52348-7d50-1056-a596-e154f87c99d2@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 +Cc: Hans (mentioned your name and was under impression that you are in Cc list already) On Thu, Sep 22, 2022 at 12:49:15PM +0300, Andy Shevchenko wrote: > On Wed, Sep 21, 2022 at 10:50:53PM +0200, Borislav Petkov wrote: > > On Wed, Sep 21, 2022 at 03:19:26PM -0500, Limonciello, Mario wrote: > > > Jan mentioned this in the commit message: > > > > > > > The function which registers i2c-designware-platdrv is a > > > > subsys_initcall that is executed before fs_initcall (when enumeration > of > > > NB descriptors occurs). > > > > > > So if it's not exported again, then it means that we somehow > > > need to get i2c-designware-platdrv to register earlier too. > > > > So I have this there: > > > > /* This has to go after the PCI subsystem */ > > fs_initcall(init_amd_nbs); > > > > as I need PCI. It itself does > > > > arch_initcall(pci_arch_init); > > > > so I guess init_amd_nbs() could be a subsys_initcall... > > > > Or why is > > > > subsys_initcall(dw_i2c_init_driver); > > > > a subsys initcall in the first place? > > > > Looking at > > > > 104522806a7d ("i2c: designware: dw_i2c_init_driver as subsys initcall") > > > > I don't see a particular reason why it should be a subsys_initcall... > > > > In any case, this should be fixed without an export which was crap in > > the first place. > > > > Hm. > > I'm speculating here, but IIRC the I2C controllers may serve PMICs on some > platform that are required to be present earlier due to some ACPI code > accessing them. This Hans de Goede can confirm or correct me. > > Another case comes to my mind is that I2C framework wants to initialize I2C > peripherals which were supplied via struct i2c_board_info on earlier stages. > And again comes to the specifics of the certain peripherals that needs for > power / reset / etc control, i.o.w. critical hardware for the platforms. > > But it's still what I remember and I can be mistaken. -- With Best Regards, Andy Shevchenko