| 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
| ||
|
Message-ID: <CAJZ5v0ha8VG2k42qCgWXmx96Rn9WY7x10dLEipJMj2kRFEfHmw@mail.gmail.com> Date: Tue, 3 Feb 2026 21:20:42 +0100 From: "Rafael J. Wysocki" <rafael@...nel.org> To: Adrian Hunter <adrian.hunter@...el.com> Cc: "Wysocki, Rafael J" <rafael.j.wysocki@...el.com>, Frank Li <Frank.li@....com>, alexandre.belloni@...tlin.com, linux-i3c@...ts.infradead.org, linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org Subject: Re: [PATCH 5/7] i3c: mipi-i3c-hci: Allow parent to manage runtime PM On Tue, Feb 3, 2026 at 5:57 PM Adrian Hunter <adrian.hunter@...el.com> wrote: > > On 03/02/2026 18:22, Wysocki, Rafael J wrote: > > > > On 2/3/2026 4:59 PM, Frank Li wrote: > >> On Tue, Feb 03, 2026 at 02:54:44PM +0200, Adrian Hunter wrote: > >>> + Rafael > >>> > >>> Rafael, this is not at all urgent, but when you have time > >>> please have a look at this patch set. There is also some > >>> more explanation below. Is it acceptable? Is there a > >>> better way? > >>> > >>> On 02/02/2026 18:25, Frank Li wrote: > >>>> Does your device Hierarchy look like > >>>> > >>>> PCI device > >>>> | > >>>> ----------------- > >>>> HCI1 HCI2 > >>>> | | > >>>> I3C M1 I3C M2 > >>> Yes and no. There is only 1 real device : the PCI device. > >>> It implements the MIPI I3C HCI standard which allows multiple > >>> I3C bus controllers in one device (in our case 2 controllers). > >>> > >>> The PCI driver mipi-i3c-hci-pci creates 2 platform devices, > >>> one for each controller. The platform driver is mipi-i3c-hci: > >>> > >>> Driver Device Bus > >>> > >>> mipi-i3c-hci-pci 0000:00:11.1 PCI > >>> / \ > >>> mipi-i3c-hci intel-lpss-i3c.0 intel-lpss-i3c.1 Platform > >>> > >>> LPSS I3C also supports wake-up from in-band interrupt (IBI) via > >>> PCI PME. The PME only works when the PCI device is in a low power > >>> state (D3hot in our case). Also the PME is effectively shared by > >>> the 2 controllers i.e. an IBI signal (the controller's SDA line > >>> pulled low) for either controller will cause the PME. > >>> > >>> That means there are only 2 valid configurations: > >>> > >>> 1: Both controllers enabled to receive IBIs > >>> PCI device D0 > >>> Controller 1 Enabled > >>> Controller 2 Enabled > >>> > >>> 2: Both controllers disabled to enable PME wakeup > >>> PCI device D3hot > >>> Controller 1 Disabled > >>> Controller 2 Disabled > >>> > >>> However, represented as platform devices, the 2 controllers > >>> runtime suspend and resume independently from each other. > >>> Whereas they effectively need to runtime suspend (or resume) > >>> at the same time. > >>> > >>> The proposed solution is for the PCI driver mipi-i3c-hci-pci > >>> to take over managing runtime PM for both controllers, calling > >>> into mipi-i3c-hci when it is safe to do so, to save/restore state > >>> and disable/enable the controllers one after the other. > >>> > >>> Current situation (I3C next branch): > >>> > >>> PCI device Runtime PM enabled, dependent on child devices > >>> PCI subsystem controls PCI device power state > >>> > >>> Controller 1 Runtime PM enabled plus auto-suspend > >>> I3C subsystem runtime PM gets/puts the Platform device > >>> Runtime suspend: disable and save state > >>> Runtime resume: restore state and enable > >>> > >>> Controller 2 Runtime PM enabled plus auto-suspend > >>> I3C subsystem runtime PM gets/puts the Platform device > >>> Runtime suspend: disable and save state > >>> Runtime resume: restore state and enable > >>> > >>> Proposed (this patch set): > >>> > >>> PCI device Runtime PM enabled plus auto-suspend > >>> I3C subsystem runtime PM gets/puts the PCI device > >>> For each controller: > >>> Call into mipi-i3c-hci (when it is safe) > >>> Runtime suspend: disable and save state > >>> Runtime resume: restore state and enable > >>> > >>> Controller 1 Runtime PM disabled > >>> > >>> Controller 2 Runtime PM disabled > >> Controller 1/2 is child device of PCI device. > >> > >> So first patch "i3c: master: Allow controller drivers to select runtime PM device" > >> is not necessary. > >> > >> You can enable controller 1 and 2 Runtime PM with dummy operation. > >> > >> When controller 1 run time suspend, parent PCI device will reduce ref counter > >> when controller 2 run time suspend, parent PCI device will reduce ref counter > >> > >> Only runtime pm reference counter of PCI device is 0, PCI device's run time > >> suspend will be called, you can do actual disable and save work. > > > > This sounds to me like it should work. > So, like this, then? > > PCI device Runtime PM enabled > For each controller: > Call into mipi-i3c-hci (when it is safe) > Runtime suspend: disable and save state > Runtime resume: restore state and enable > > Controller 1 Runtime PM enabled plus auto-suspend > I3C subsystem runtime PM gets/puts the Platform device > Runtime suspend: does nothing > Runtime resume: does nothing > > Controller 2 Runtime PM enabled plus auto-suspend > I3C subsystem runtime PM gets/puts the Platform device > Runtime suspend: does nothing > Runtime resume: does nothing I would think so.
Powered by blists - more mailing lists