From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0071435CBC3 for ; Fri, 12 Jun 2026 16:05:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781280305; cv=none; b=Pn6h7LtZlHOuUUDHX1oPykkCNS4ra+dasRebhdLi2HcfKf/2g/NwlJcN3rDBmY/SBxiu+++TSWzUCK8zKRpuTv9zbDbViVz42BGmF79vAJNTbTmQchs9fryOxUAldMvLEiucR17pPLGxERG4fWhKBn/jAcvRBQfQsbWcmJqsfwI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781280305; c=relaxed/simple; bh=iZkU5757aEdnyjqs5KcZm6BSLds782Hk7JK9LvpXjf8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=NxmPkPVFPd95v9Ycxhboj3GGWLDRr1XWQuOBZr8kuBxqjmj9DWsb2gz7sTp784MjwFYCp18l2zTn6Rz0wVMoL0GTY1j/Cz95tRXmWBDSMHD2WIoBSskThKKYcanullTZPKORtzmDz4xw/y5yVfbFaKSPtVK3BpiXYqkAMjJeBmY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BGs6yLHJ; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BGs6yLHJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 774741F000E9; Fri, 12 Jun 2026 16:05:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781280303; bh=mj13/P4pFmGLwbyGNiyReg0Yny8dmZLm6qgAmsrPGJI=; h=From:To:Cc:Subject:Date; b=BGs6yLHJCOo4j+BiGKx3Bi3jWsCPhRj3nA/BXkqUbbmdGH4YqWsTGKAF/O3y7Gw1l MDxxHwghZj8SkOyYhePTpXtYuMTDcIotM9Erh4PQiX4uwy5G+7C55fJk/qeArnPqy7 kaRSPjFZxUYaDFl5bjKT9aTSteirH8bYZuHapP8OlqoGrNP/kXMEx48C9DveOkQEBc AzoKl12Ypw79+MROdJVjOOEhlbXxZMpN6fnm14yBGro1xP0QyM1GNE3kAec6xM3NJ8 uXvEYdWHPm8NOtcDMOhCMqrXvDEpnNRppjdBtMy5FJMwNQsx3LS71SnhtA/pP1SIWH unZaK7LEzGROA== From: Claudiu Beznea To: wsa+renesas@sang-engineering.com, tommaso.merciai.xr@bp.renesas.com, alexandre.belloni@bootlin.com, Frank.Li@nxp.com, p.zabel@pengutronix.de Cc: claudiu.beznea@kernel.org, linux-i3c@lists.infradead.org, linux-kernel@vger.kernel.org, claudiu.beznea@tuxon.dev, Claudiu Beznea Subject: [PATCH v4 00/16] i3c: renesas: Suspend to RAM with power loss and runtime PM Date: Fri, 12 Jun 2026 19:04:42 +0300 Message-ID: <20260612160458.3102106-1-claudiu.beznea@kernel.org> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Claudiu Beznea Hi, This series adjusts the suspend to RAM code to handle cases where power to the connected devices is lost during suspend to RAM. The fixes included in this series are required for that support. Along with suspend to RAM support, runtime PM support is also added. Cleanup patches were included to prepare for clean runtime PM support. Please note that series need to be applied on top of [1] since patch "i3c: renesas: Perform Dynamic Address Assignment on resume" uses i3c_master_reattach_i3c_dev_locked(). Thank you, Claudiu Changes in v4: - dropped patch "i3c: renesas: Do not attach devices if xfer failed" - fixed the swap in renesas_i3c_group_devs_in_slots() for i3c->addr[] renesas_i3c_irqs_mask_and_clear(); - in patch 16/16 renamed renesas_i3c_abort_xfer() from v3 to Changes in v3: - re-based on top of series [1] to be able to use i3c_master_reattach_i3c_dev_locked() - used i3c_master_reattach_i3c_dev_locked() on patch "i3c: renesas: Perform Dynamic Address Assignment on resume" along with grouping the I2C and I3C devices in the driver slot - collected tags Changes in v2: - dropped patch "i3c: renesas: Use the divider 128" - adjusted the patches title and description where requested in the review process - adjusted the DAA procedure after resume to still properly re-configure the controller in case the bus was full before a suspend - added patch "i3c: renesas: Do not attach devices if xfer failed" - collected tags [1] https://lore.kernel.org/linux-i3c/20260525064209.2263045-1-lakshay.piplani@nxp.com/T/#m74ddb24e1e3a8006d933bd6106cc0c4508a11d2c Claudiu Beznea (16): i3c: renesas: Check that the transfer is valid before accessing it i3c: renesas: Restore STDBR and EXTBR registers on resume i3c: renesas: Follow the reset deassert order used in probe i3c: renesas: Reconfigure the DATBAS register on re-attach i3c: renesas: Reset the controller on resume i3c: renesas: Perform Dynamic Address Assignment on resume i3c: renesas: Clean DATBAS register on detach i3c: renesas: Use reset_control_bulk_{assert, deassert}() i3c: renesas: Return immediately if there is no transfer i3c: renesas: Follow a unified pattern for transfer and command initialization i3c: renesas: Drop the explicit memset() call i3c: renesas: Update HW registers after SW computations are done i3c: renesas: Organize structures to avoid unnecessary padding i3c: renesas: Use the "dev_name:irq_name" format for the interrupt name i3c: renesas: Drop unnecessary tab i3c: renesas: Add runtime PM support drivers/i3c/master/renesas-i3c.c | 541 +++++++++++++++++++++++-------- 1 file changed, 413 insertions(+), 128 deletions(-) -- 2.43.0