Received-SPF: pass (google.com: domain of linux-kernel+bounces-49966-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Message-ID: <70412f57-b59a-3a46-6853-4312991c19e5@linux.intel.com>
Date: Fri, 2 Feb 2024 16:51:06 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Firefox/102.0 Thunderbird/102.13.0
Content-Language: en-US
To: Guan-Yu Lin <guanyulin@google.com>, gregkh@linuxfoundation.org,
 mathias.nyman@intel.com, stern@rowland.harvard.edu, royluo@google.com,
 benjamin.tissoires@redhat.com, hadess@hadess.net,
 heikki.krogerus@linux.intel.com, grundler@chromium.org, oneukum@suse.com,
 dianders@chromium.org, yajun.deng@linux.dev
Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
 USB <linux-usb@vger.kernel.org>, Linux PM list <linux-pm@vger.kernel.org>,
 "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
References: <20240202084815.3064391-1-guanyulin@google.com>
From: Mathias Nyman <mathias.nyman@linux.intel.com>
Subject: Re: [PATCH] usb: host: enable suspend-to-RAM control in userspace
In-Reply-To: <20240202084815.3064391-1-guanyulin@google.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 2.2.2024 10.42, Guan-Yu Lin wrote:
> In systems with both a main processor and a co-processor, asynchronous
> controller management can lead to conflicts. For example, the main
> processor might attempt to suspend a USB device while the co-processor
> is actively transferring data. To address this, we introduce a new
> sysfs entry, "disable_suspend2ram", which allows userspace to control
> the suspend-to-RAM functionality of devices on a specific USB bus.
> Since the userspace has visibility into the activities of both
> processors, it can resolve potential conflicts.
> 
> Signed-off-by: Guan-Yu Lin <guanyulin@google.com>
> ---

Doesn't setting this new disable_suspend2ram break system suspend on all
other systems except this one?

On any system with a PCI xHC we end up trying to suddenly stop the xHC
host with all connected usb devices still fully up and running.

In the xhci platform device case again nothing will be stopped or suspended,
but PM framework assumes everything is suspended correctly.

So then xHC either continues running and generates interrupts, or it might
be abruptly powered off if the bus above it suspends.
(For example if the xhci platform device is created by a PCI DWC3, and it
goes to D3 state)

EHCI and other hosts face similar issues with trying to suspend the
controller when the devices connected to it are fully up and running.

To me it looks like this whole co-processor case needs to be developed and
designed into the pm framework

Thanks
Mathias