From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4380948C8DC for ; Wed, 15 Jul 2026 17:55:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.208.53 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784138147; cv=pass; b=flMikZ96FBmXB18mzdKP/6zlBPuwHCheOvaeqzGIQHLTPBAxrPdSRze3/jr890+k0vrvz4lPor9BsB2ts0ZGEzN5DsbsmDd1mnuSUYmtL85OhOoyYNxH5xqiCzGgjHRBOZVqydA/RxJC8Lk0s12LjZSiwx+/1DCBlrSBHMz0RzE= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784138147; c=relaxed/simple; bh=t0NQOLYqHWDz9VsRSjuVoji+SI41r96ungAAD1Kanl0=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ISxD0tBD9blA6PGqu5VTkogGtiy8BN2zgKTm7ViqxaQWKMF2oMtahaMQ6N/fyOi659FyI/oew4QiTorNWfqAjP6fSUNYVlMPd98FuyXG4j4cV3PICxTyshIgeDq1ZRyAbFcLmX/fZ1+jonw70+dnPXXLghoA+AMd7YezFec5GYc= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=lgKv2/1A; arc=pass smtp.client-ip=209.85.208.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="lgKv2/1A" Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-6976b0c5adbso12051202a12.2 for ; Wed, 15 Jul 2026 10:55:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1784138143; cv=none; d=google.com; s=arc-20260327; b=IAvSrshe2WIQrfLMcveMcxbz6oppPhxpG5IqUgFh+VSKhXJkn3SuPpPhOOf/sXZgrY fCm5b6N2N2XpV/2OKN242SpUMM0tBaJxC2lE1Wq1T/pYWH5SKMSWkdnrCh6WdI44v0AJ IoBS3W6mNxRXlbLucmTNXtEZ28yHRCly+R+xMQ4UmuO7c9XJnV1P5QcowvSm4o9pLt7Z tmwCCNNzeXTwh9Std1LWnMJAynuwQuzlb2Qy/AjDvSGxeXhzcbhZQK/rZnK4AjSzYnZk 7ysfJn0GeQzaxNUiLzREbWrKdud0iX4UB/027XJI1cqIV3X9gUBa+nwNPoHXuQZ0i3/P Nv0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=B1fLH5vkVlaT9TAQEnaHfQcEDTexVsSO83pCVpu+qHI=; fh=XOdN4BceCZ5XhRVJdjouRT9Xc9DXDtIGoP/CClxmWp0=; b=dcZwGyOimWltajHh7YkcvEIYsd6Y6OXS3Fw92Pu7iD7j4LESTTx97xOgNVvwd/qO+C X/EVFlzuirSP0fF447o8OlC3xmDr13m1TTWtdM4UXOROWEGmPTb13yYAFvaJhEs+BOq9 /PoxwrsjmY+nTVMN8s8VjCetuOXeANsC1Mb77DyZFjZGsECdX/hYY9FL1/ZwI9yvqxnH mlG87wzRWG2znsKrXIDhEEQ0bGWuAAvEvf46OEVPevfBEkJAx+UXQOif2dTx2BUeX1iq /VJMO7mb/xrDZV3xVOENwc/zDHi5wdTSxADIqEQK3aj2tg+2DZFfeitAToekHII6z4wP ns6w==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1784138143; x=1784742943; darn=vger.kernel.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=B1fLH5vkVlaT9TAQEnaHfQcEDTexVsSO83pCVpu+qHI=; b=lgKv2/1A3Qpu3dh33l55DhDZ2WtOfRur9GvjsEMwzA9HDB+dUvz/FuSaGvWaOvO5+j FlXO74Majb2FoMEPFvHMYKxiHP4LXOJLt/kFFOt/dzDbaWvKWhQ+yah0PJkEJBLiyUoB /QeLjS2mnBxfuV4BC/qkivLafCM65Tg33yAbx724+nWPUeTnZs9gi9ewYNNHUHpve9QS sbrVAAdE9muwlAs73JW2WhIewcVXhmWzqO715dlQfju5fvQtRozsJnjzSPbHDzdy5AHl Osxv5MGrJz8w9EH97sSBZHzBkGx38AiKZKD4xFyQcMP9i76iF8GzqzP0c+RxH7midKxc 9Ubw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784138143; x=1784742943; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=B1fLH5vkVlaT9TAQEnaHfQcEDTexVsSO83pCVpu+qHI=; b=Nj+M8wsh5Q3pv5Sb1ttwyvyDERHSJY6LMGxPb+D0csw24C9KeBw7XkVAOQxJPZwkLB shg2WWYaC6frGQ7Fof6aBVKv0ARme0tiEHw0Hz8+ZYKDtjmWc/JFKdrjAj1oiNeCux6W 9kAYD91EyIF0NUSX1DuoBPY1EON4g5uHI0MtxQ1UVTig24cX96rJdDJ3ed5DEKpEs4jN ZOmWLpfojbbSuIv9RQpz672DE2PwITuuxQ/EmeeBkW7eXjfhjVjcsOuA1ivkySp/M6R3 tGuR9Mre4fGPI0o3LCbE7EGhj/IPFQitwhrfw8PJLUVdEK/yEIGnYCI0n4/lzEuYIDuD FexA== X-Forwarded-Encrypted: i=1; AHgh+Rq2ZqtEqOSAtwpNvzLE2ZIGNJlyeu2jag3hkbFth7i2rFxuiVI7FUQhXXx7fsWZ09MZLmomooPblHPfLxE=@vger.kernel.org X-Gm-Message-State: AOJu0Ywd4nwD0E2x7jPpiO8pQqbwPgUAvYvNbcxpZ2hIpVfH4g+cg6/O QZ+uympF2imw0ZPZBX3WoL5wThR5sz6GgDbwM+TaYvRofYb7Qv+LEm9RHsF9oiS4PNP39GK8Nce ggFpoq2C+kL7XpHRi1Lvp9kbsMZ+E1SPXe84+c7dHHw== X-Gm-Gg: AfdE7ck3TvGY7lVXRKFamD8ypTNM8bmmn7Xa/qKdUhLjrUCUz3gmo85HRDwmoo5ejvt RSdv0GAZRht3X79eVvs5Z0uXtAzea3mDaL344/BvuS2QwWKonYXxKEAJxvyfiDtaAZoCL2cDv/S rLrM7crcu0xWQIWMV074aUh2ThEJzjsd5Bq8xpqxs2M8FF4fpPGZ+w+649ESjH4rO1acaVrj2HS gooFQYdwIxGYcv5RGF0wfQQ7pvdEtM1QA9PiZVGOfSt6/6sdcAYptlumuiEMR8/0+yNdCSVctkh NjBD6182VaHotIe1P4p0nLtxAsyGzGU= X-Received: by 2002:a05:6402:1588:b0:69c:7567:cf5c with SMTP id 4fb4d7f45d1cf-69cd6ddfb91mr4781134a12.41.1784138143408; Wed, 15 Jul 2026 10:55:43 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260625155432.815185-1-shenwei.wang@oss.nxp.com> <20260625155432.815185-2-shenwei.wang@oss.nxp.com> In-Reply-To: From: Mathieu Poirier Date: Wed, 15 Jul 2026 11:55:32 -0600 X-Gm-Features: AUfX_mzC-pSYEjUJ9BYRTa4GlO7TcNO2B0DY7O1_KieZEYL7x6Ya_ZTaPmF0Y3w Message-ID: Subject: Re: [PATCH v14 1/5] docs: driver-api: gpio: rpmsg gpio driver over rpmsg bus To: "Shenwei Wang (OSS)" Cc: Linus Walleij , Bartosz Golaszewski , Jonathan Corbet , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Bjorn Andersson , Frank Li , Sascha Hauer , Shuah Khan , "linux-gpio@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Pengutronix Kernel Team , Fabio Estevam , Shenwei Wang , Peng Fan , "devicetree@vger.kernel.org" , "linux-remoteproc@vger.kernel.org" , "imx@lists.linux.dev" , "linux-arm-kernel@lists.infradead.org" , dl-linux-imx , Arnaud POULIQUEN , "b-padhi@ti.com" , Andrew Lunn Content-Type: text/plain; charset="UTF-8" On Wed, 15 Jul 2026 at 09:55, Shenwei Wang (OSS) wrote: > > > > > -----Original Message----- > > From: Mathieu Poirier > > Sent: Wednesday, July 15, 2026 10:26 AM > > To: Shenwei Wang (OSS) > > Cc: Linus Walleij ; Bartosz Golaszewski ; > > Jonathan Corbet ; Rob Herring ; Krzysztof > > Kozlowski ; Conor Dooley ; Bjorn > > Andersson ; Frank Li ; Sascha Hauer > > ; Shuah Khan ; linux- > > gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org; > > Pengutronix Kernel Team ; Fabio Estevam > > ; Shenwei Wang ; Peng Fan > > ; devicetree@vger.kernel.org; linux- > > remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm- > > kernel@lists.infradead.org; dl-linux-imx ; Arnaud > > POULIQUEN ; b-padhi@ti.com; Andrew Lunn > > > > Subject: Re: [PATCH v14 1/5] docs: driver-api: gpio: rpmsg gpio driver over rpmsg > > bus > > > > On Tue, Jul 14, 2026 at 06:43:30PM +0000, Shenwei Wang (OSS) wrote: > > > > > > > > > > -----Original Message----- > > > > From: Mathieu Poirier > > > > Sent: Tuesday, July 14, 2026 11:36 AM > > > > To: Shenwei Wang (OSS) > > > > Cc: Linus Walleij ; Bartosz Golaszewski > > > > ; Jonathan Corbet ; Rob Herring > > > > ; Krzysztof Kozlowski ; Conor > > > > Dooley ; Bjorn Andersson > > > > ; Frank Li ; Sascha Hauer > > > > ; Shuah Khan ; > > > > linux- gpio@vger.kernel.org; linux-doc@vger.kernel.org; > > > > linux-kernel@vger.kernel.org; Pengutronix Kernel Team > > > > ; Fabio Estevam ; Shenwei > > > > Wang ; Peng Fan ; > > > > devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org; > > > > imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org; > > > > dl-linux-imx ; Arnaud POULIQUEN > > > > ; b-padhi@ti.com; Andrew Lunn > > > > > > > > Subject: Re: [PATCH v14 1/5] docs: driver-api: gpio: rpmsg gpio > > > > driver over rpmsg bus > > > > > > > > On Tue, Jul 14, 2026 at 02:29:12PM +0000, Shenwei Wang (OSS) wrote: > > > d > > > > > > > + - 3: Both edge trigger > > > > > > > + - 4: High level trigger > > > > > > > + - 8: Low level trigger > > > > > > > > > > > > I'm in agreement with cmd 3, 4, 5 and 6. > > > > > > > > > > > > > > > > How about cmd 2? > > > > > > > > Yes, I forgot cmd 2. > > > > > > > > > > > > > > > > + > > > > > > > +**Reply:** > > > > > > > + > > > > > > > +.. code-block:: none > > > > > > > + > > > > > > > + +------+--------+--------+ > > > > > > > + | 0x00 | 0x01 | 0x02 | > > > > > > > + | 1 | status | 0 | > > > > > > > + +------+--------+--------+ > > > > > > > + > > > > > > > +- **status**: > > > > > > > + > > > > > > > + - 0: Ok > > > > > > > + - 1: Error > > > > > > > + > > > > > > > +SET_WAKEUP (Cmd=16) > > > > > > > +~~~~~~~~~~~~~~~~~~~ > > > > > > > > > > > > I already commented on messages that are not part of the > > > > > > virtio-gpio specification. > > > > > > > > > > > > > > > > I don't believe virtio-gpio needs a SET_WAKEUP command. > > > > > > > > > > In the RPMSG case, SET_WAKEUP is required because it performs an > > > > > operation on the remote processor, so the remote side must be > > > > > explicitly > > > > notified. > > > > > > > > What operations would that be? > > > > > > > > > > The operation is enabling the line as a wakeup source. In practice, > > > this involves configuring hardware-specific wakeup settings (e.g., > > > register bits) on the remote processor, so the remote side must be explicitly > > notified through SET_WAKEUP. > > > > > > > As I said before, we are not enhancing the virtio-gpio specification. If the > > functionality is not part of the specification, it is not part of this protocol. > > > > It's about the functionality, not the specification. > No, it's about the specification. > Without SET_WAKEUP, a virtio-GPIO line can still be used as a wakeup source, but > an RPMSG implementation cannot because the remote processor is never notified > to configure its wakeup settings. > > So both implementations may follow the same virtio-gpio specification, but they do > not provide the same wakeup functionality. > No. The kernel treats rpmsg-gpio the same way as virtio-gpio - they need to provide exactly the same functionality. > Anyway, if you want to drop the function, the command can be removed. > > Shenwei > > > > > > > > > > > > > > For virtio-gpio, however, everything is handled locally. The other > > > > > side does not need to perform any action, so sending a SET_WAKEUP > > > > > command > > > > appears unnecessary. > > > > > > > > What is "everything"? > > > > > > > > > > I mean masking, unmasking, and marking the interrupt as a wakeup > > > source. All of these operations are handled on local processor. > > > > There may be enough capability in your remote processor to do all that, but we > > can't assume the same applies to all implementations. rpmsg-gpio is not about > > inventing a new protocol or delegating actions to the remote processor. It is > > about carrying virtio-gpio packets on top of RPMSG. It needs to operate > > _exactly_ the same way as virtio-gpio. > > > > > > > > Shenwei > > > > > > > > > > > > > > > > > > > > + > > > > > > > +**Request:** > > > > > > > + > > > > > > > +.. code-block:: none > > > > > > > + > > > > > > > + +------+------+------+------+------+------+------+------+ > > > > > > > + | 0x00 | 0x01 | 0x02 | 0x03 | 0x04 | 0x05 | 0x06 | 0x07 | > > > > > > > + | 1 | line | value | > > > > > > > + +------+------+------+------+------+------+------+------+ > > > > > > > + > > > > > > > +- **value**: Wakeup enable. > > > > > > > + > > > > > > > + The remote system should always aim to stay in a > > > > > > > + power-efficient state by shutting down or clock-gating the > > > > > > > + GPIO blocks that aren't in use. Since the remoteproc driver > > > > > > > + is responsible for managing the power states of the remote > > > > > > > + firmware, the GPIO driver does not require to know the > > > > > > > + firmware's > > > > running states. > > > > > > > + > > > > > > > + When the wakeup bit is set, the remote firmware should > > > > > > > + configure the line as a wakeup source. The firmware should > > > > > > > + send the notification message to Linux after it is woken from the GPIO > > line. > > > > > > > + > > > > > > > + - 0: Disable wakeup from GPIO > > > > > > > + - 1: Enable wakeup from GPIO > > > > > > > + > > > > > > > +**Reply:** > > > > > > > + > > > > > > > +.. code-block:: none > > > > > > > + > > > > > > > + +------+--------+--------+ > > > > > > > + | 0x00 | 0x01 | 0x02 | > > > > > > > + | 1 | status | 0 | > > > > > > > + +------+--------+--------+ > > > > > > > + > > > > > > > +- **status**: > > > > > > > + > > > > > > > + - 0: Ok > > > > > > > + - 1: Error > > > > > > > + > > > > > > > +Notification Message > > > > > > > +-------------------- > > > > > > > > > > > > "Interrupt Messages" > > > > > > > > > > > > > + > > > > > > > +Notifications are sent by the remote core and they have > > > > > > > +**Type=2 (GPIO_RPMSG_NOTIFY)**: > > > > > > > + > > > > > > > +When a GPIO line asserts an interrupt on the remote > > > > > > > +processor, the firmware should immediately mask the > > > > > > > +corresponding interrupt source and send a notification > > > > > > > +message to the Linux. Upon completion of the interrupt > > > > > > > +handling on the Linux side, the driver should issue a command > > > > > > > +**SET_IRQ_TYPE** to the firmware to > > > > unmask the interrupt. > > > > > > > + > > > > > > > +A Notification message can arrive between a SEND and its > > > > > > > +REPLY message, and the driver is expected to handle this scenario. > > > > > > > + > > > > > > > +.. code-block:: none > > > > > > > + > > > > > > > + +------+------+--------+ > > > > > > > + | 0x00 | 0x01 | 0x02 | > > > > > > > + | 2 | line | trigger| > > > > > > > + +------+------+--------+ > > > > > > > > > > > > 2 things here: > > > > > > > > > > > > 1) You did not include messages that mask and unmask interrupts > > > > > > at the driver side. > > > > > > > > > > Interrupt masking and unmasking are handled entirely on the local > > processor. > > > > > > > > > > When an interrupt occurs, the remote system masks the interrupt > > > > > and then sends a notification to Linux. After Linux processes the > > > > > notification, it sends a SET_IRQ_TYPE message back to the remote > > > > > system, > > > > which then unmasks the interrupt. > > > > > > > > This is the kind of information that should be part of this documentation. > > > > > > > > > > > > > > Thanks, > > > > > Shenwei > > > > > > > > > > > > > > > > > 2) We are carrying virtio-gpio messages on top of RPMSG and as > > > > > > such, this whole protocol should be about thar: > > > > > > > > > > > > +------+------+--------+-------- > > > > > > | 0x00 | payload | > > > > > > | Q | | > > > > > > +------+------+--------+-------- > > > > > > > > > > > > Q = 0 requestq > > > > > > Q = 1 eventq > > > > > > > > > > > > The "payload" part is simply the format of the messages as found > > > > > > in the virtio- gpio specification. From there, the only thing > > > > > > left to mention is which messages are not supported, i.e get line names. > > > > > > > > > > > > > + > > > > > > > +- **line**: The GPIO line (pin) index of the port. > > > > > > > + > > > > > > > +- **trigger**: Optional parameter to indicate the trigger event type. > > > > > > > > > > > > Not part of the spec - remove. > > > > > > > > > > > > Given the refactoring work that is still needed, I will not look > > > > > > at the implementation. > > > > > > > > > > > > Thanks, > > > > > > Mathieu > > > > > > > > > > > > > + > > > > > > > diff --git a/Documentation/driver-api/gpio/index.rst > > > > > > > b/Documentation/driver-api/gpio/index.rst > > > > > > > index bee58f709b9a..e5eb1f82f01f 100644 > > > > > > > --- a/Documentation/driver-api/gpio/index.rst > > > > > > > +++ b/Documentation/driver-api/gpio/index.rst > > > > > > > @@ -16,6 +16,7 @@ Contents: > > > > > > > drivers-on-gpio > > > > > > > bt8xxgpio > > > > > > > pca953x > > > > > > > + gpio-rpmsg > > > > > > > > > > > > > > Core > > > > > > > ==== > > > > > > > -- > > > > > > > 2.43.0 > > > > > > >