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: <a6525228-2abf-4177-acc7-858843941ba4@intel.com>
Date: Tue, 3 Feb 2026 18:57:38 +0200
From: Adrian Hunter <adrian.hunter@...el.com>
To: "Wysocki, Rafael J" <rafael.j.wysocki@...el.com>, Frank Li
	<Frank.li@....com>
CC: <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 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



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ