All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joonhoe Kim <26rote@gmail.com>
To: Abel Vesa <abel.vesa@oss.qualcomm.com>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konradybcio@kernel.org>,
	Dmitry Baryshkov <lumag@kernel.org>,
	Johan Hovold <johan@kernel.org>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Casey Connolly <casey.connolly@linaro.org>,
	linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] usb: typec: ucsi: Schedule connector worker on freezable workqueue
Date: Fri, 16 Oct 2026 21:50:44 +0900	[thread overview]
Message-ID: <20261016125044.1085-1-26rote@gmail.com> (raw)
In-Reply-To: <20250205-ucsi-schedule-conn-worker-on-freezable-wq-v1-1-107d1356b77b@linaro.org>

(Resending with the lists on Cc; my earlier reply only went to Abel.)

On Wed, Feb 05, 2025 at 01:45:05PM +0200, Abel Vesa wrote:
> Scheduling the USCI connector worker on the freezable system workqueue
> instead will ensure the devices are resumed by the time the worker is
> scheduled to run.

Hi Abel,

You mentioned respinning this together with the altmode change (now
7d0767c5cd87). Are you still planning to? I hit the same problem on a
Kaanapali tablet (Lenovo Legion Tab Y700 Gen 5) with an FSA4480
orientation switch. Unplugging a USB-C to HDMI adapter during s2idle,
with the altmode change applied:

  i2c i2c-2: Transfer while suspended
  Workqueue: events ucsi_handle_connector_change
   fsa4480_set
   typec_switch_set
   typec_set_orientation
   pmic_glink_ucsi_connector_status
   ucsi_handle_connector_change

and the system never resumes. With this patch on v7.3-rc4 it resumes
normally (2 of 2) and the change is handled after thaw.

On Dmitry's question: freezing the ucsi_glink notify_work instead would
also hold back command completions (ucsi_notify_common() ->
complete()), so a command in flight at freeze time would wait for
UCSI_TIMEOUT_MS. That is from reading the code, not tested.

If you respin it, I can reply with a Tested-by. If you'd rather I send
it, I have it rebased on next-20260928; just tell me how to credit you.

Thanks,
Joonhoe Kim

      parent reply	other threads:[~2026-10-16 12:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-05 11:45 [PATCH RFC] usb: typec: ucsi: Schedule connector worker on freezable workqueue Abel Vesa
2025-02-05 17:31 ` Dmitry Baryshkov
2026-10-16 12:50 ` Joonhoe Kim [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261016125044.1085-1-26rote@gmail.com \
    --to=26rote@gmail.com \
    --cc=abel.vesa@oss.qualcomm.com \
    --cc=andersson@kernel.org \
    --cc=casey.connolly@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=johan@kernel.org \
    --cc=konradybcio@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=lumag@kernel.org \
    --cc=neil.armstrong@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.