Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp2078124rwi; Fri, 28 Oct 2022 02:45:37 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5xBZEAF0ZonVYwPXEqGckeCHTyIFwpGL65DBCZhrUt1pv0nTo2k7Dhmo5uWr+fmzXw3XeL X-Received: by 2002:a17:907:708:b0:77e:ff47:34b1 with SMTP id xb8-20020a170907070800b0077eff4734b1mr44147321ejb.493.1666950336751; Fri, 28 Oct 2022 02:45:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666950336; cv=none; d=google.com; s=arc-20160816; b=AvDUhk5wkgOXkM0Yd+YDd5aHs02imBzkrB6hENqftz2h3S6kFjXEsYPNctHWCxVADt Hy+6sE53Xn1dpYztYjUsfg+JeIAtdo3dkGf8kKfZ+uESK2wyHcWAUFvQ3wWfczVvSwKX 6Og+p030p/+bdcaA7YrfOZMCzsPzO1q0/1TlXTowxObEhqQ/1g/TwBkPIi4FDttJPta4 7pEi5E+cUTtuQXUiREHWbsLTCx3GR1LwE4pxCyH5J/rwMg1WdqjyflVHPymoKu4IrWEE jWWhfTmrWTpMLnNsEdYzGtWNVR7J+cxdtC8K1butp74BjtY7Ch8qrYmoYm2ERzazezVU WpCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=ySka4Xz8oYpVMJmGs1uWrHr/m2OpCyAifeU/LNLCiHQ=; b=ChsMrF9eiFc5gIqWmIO6M26mL659errpvOrGChs93mpGUWLVA+GO7x7xFweGtO4PbS t1iYKykTVGfbgKhGXgHNpAnm0TXUagf5Uxxu2laIxk/25Hwgcg4Tq+PTsZg+UkWWRg80 M0EzINgO34k0IqyqEd0h21pCC2AcM7O3h04ZOsopO54GH+Ga+OIhLBzEANh2OULoVqGW LUhaUCTcuF/3Y6QdkSwDlZut9KxKwuXvTSa2ObrOrU4wtwOgw5pMSDUxQH2K289MMpYk Fti0F5x1V+V03o74YqcXDo8ETllFpvG+3rXO5JdZi0PCoFjx/BVSMhY+qW06fj83a6eH f0tg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@semihalf.com header.s=google header.b="nS/yCaXK"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=semihalf.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g6-20020a056402320600b0045cf2d0357asi4345429eda.34.2022.10.28.02.45.11; Fri, 28 Oct 2022 02:45:36 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@semihalf.com header.s=google header.b="nS/yCaXK"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=semihalf.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229885AbiJ1Ich (ORCPT + 99 others); Fri, 28 Oct 2022 04:32:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59664 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229535AbiJ1Icc (ORCPT ); Fri, 28 Oct 2022 04:32:32 -0400 Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 028C91C491A for ; Fri, 28 Oct 2022 01:32:32 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id z3so4028841iof.3 for ; Fri, 28 Oct 2022 01:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf.com; s=google; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ySka4Xz8oYpVMJmGs1uWrHr/m2OpCyAifeU/LNLCiHQ=; b=nS/yCaXKm38e/A6crGMFTj32mUFQxrwTaGmc83TsgD15qCCKSstQnCRiFCqAy7NK1q lRpNoN34XkxNEbzDXLIa0ACcbGEdrw0h1uzEUReP8xcS58AXn1zupTR6ukCfJ5Dqop02 f8IYIcZJwp8jGgs8EuyruLxrIleE6PjEhwUMkA6UlAYCbhp+mt6YIXdqzZNlDeHvLHBp VgFO9uiSyCAldjV4s9nJQyIry3dpahwbenCpkCFB4Fc7LnL/YevfXJ1cVx9fvDkrqLLF QTViOSPo65F41rSbKojWt8i+mtyWVa7bzNAtE7lPHlgdRGfdybny7kXI/NjocnGAxIHY vmxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ySka4Xz8oYpVMJmGs1uWrHr/m2OpCyAifeU/LNLCiHQ=; b=lYMt8qcLI/cordr4jX020PN1/SUyWm/q+YxlapsNt6srfhi9ZUvqO2pme8SDMPw7Ex 8Bde04vQQqZVViwUHsLJtCiK1Jx3axMYIyzDpN3FGbSiAzi74Ky3yItrYmxwgNKBxPqw NHc+O55pCySMyDsBF01uzmBWCjueVP5Hko/mL2jDPi++E0mLSAM6LFRDcOTgs0OF95+t FjskVAJZ/K+uKCZDr1/OUi9uPpLKiTNEFLhb9eZH3H2DN0DkT3+cLHURa7JU5ecGXoib B3UTxjQP5kmDxWUV3EDB2rLjhfY1D/2nJdZQftsG2HxVoPAMxKapj5JyQxs7uNgZqQxn 2WNA== X-Gm-Message-State: ACrzQf3DcuAgCJFN9XspMGdpZgIumdhgcRJlbiAGH3LHUGbCKfN6gXKr Vh7GQeoN1UuRPeX2NaP5NluIltKcSNskPziMGgARiw== X-Received: by 2002:a02:cc51:0:b0:36d:df36:fcb1 with SMTP id i17-20020a02cc51000000b0036ddf36fcb1mr19474070jaq.51.1666945951384; Fri, 28 Oct 2022 01:32:31 -0700 (PDT) MIME-Version: 1.0 References: <60a52348-7d50-1056-a596-e154f87c99d2@amd.com> <33d5cc27-474b-fdec-a6b0-84ac16f7d386@redhat.com> In-Reply-To: From: =?UTF-8?B?SmFuIETEhWJyb8Wb?= Date: Fri, 28 Oct 2022 10:32:20 +0200 Message-ID: Subject: Re: [PATCH -next 1/2] i2c: designware: Switch from using MMIO access to SMN access To: Borislav Petkov Cc: Hans de Goede , Andy Shevchenko , "Limonciello, Mario" , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Sorry for a late reply. I did some research and experiments and right now got stuck with this problem. 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. So to summarize everything, I would like below order: acpi_init() -> init_amd_nbs() -> dw_i2c_init_driver() ^--subsys_initcall ^--fs_initicall ^--subsys_initcall but I don't have a clear idea how to achieve this in a clean way. The only option seems to be to register init_amd_nbs() as subsys_initcall and force it to execute after acpi_init() and before dw_i2c_init_drvier(). However the only option (if I'm not mistaken) for forcing order on initcalls placed on the same level is to modify their order within Makefile, so that linker puts them in the "init" section with addresses in desired order. This doesn't seem to be an option for upstream. Do you have any clue how to solve this problem? Best Regards, Jan pon., 26 wrz 2022 o 16:45 Borislav Petkov napisa=C5=82(a): > > On Mon, Sep 26, 2022 at 02:49:12PM +0200, Jan D=C4=85bro=C5=9B wrote: > > What do you think about this? > > I don't mind as long as it is tested properly so that nothing breaks > - I can help out on my end as I have a lot of AMD hw - and then > properly documented in a comment above it *why* it needs to be > arch_initcall_sync(). > > Thx. > > -- > Regards/Gruss, > Boris. > > SUSE Software Solutions Germany GmbH > GF: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman > (HRB 36809, AG N=C3=BCrnberg)