linux-kernel - Re: [PATCH -next 1/2] i2c: designware: Switch from using MMIO access to SMN access

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YywvmueFj/ibyZdf@smile.fi.intel.com>
Date:   Thu, 22 Sep 2022 12:49:14 +0300
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Borislav Petkov <bp@...e.de>
Cc:     "Limonciello, Mario" <mario.limonciello@....com>,
        Jan Dąbroś <jsd@...ihalf.com>,
        linux-kernel@...r.kernel.org, linux-i2c@...r.kernel.org,
        jarkko.nikula@...ux.intel.com, wsa@...nel.org,
        rrangel@...omium.org, upstream@...ihalf.com,
        Muralidhara M K <muralimk@....com>,
        Naveen Krishna Chatradhi <nchatrad@....com>
Subject: Re: [PATCH -next 1/2] i2c: designware: Switch from using MMIO access
 to SMN access

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