| Message ID | 20260430110652.558622-10-vladimir.oltean@nxp.com (mailing list archive) |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-sunxi+bounces-23013-sunxi=pue.re@lists.linux.dev> X-Original-To: noreply@patchwork.local Delivered-To: noreply@patchwork.local Received: from sin.lore.kernel.org (sin.lore.kernel.org [104.64.211.4]) by mxe881.netcup.net (Postfix) with ESMTPS id 4F96A1C00DB for <noreply@patchwork.local>; Thu, 30 Apr 2026 13:13:39 +0200 (CEST) Authentication-Results: mxe881; dkim=pass header.d=nxp.com; spf=pass (sender IP is 104.64.211.4) smtp.mailfrom=linux-sunxi+bounces-23013-noreply=patchwork.local@lists.linux.dev smtp.helo=sin.lore.kernel.org Received-SPF: pass (mxe881: domain of lists.linux.dev designates 104.64.211.4 as permitted sender) client-ip=104.64.211.4; envelope-from=linux-sunxi+bounces-23013-noreply=patchwork.local@lists.linux.dev; helo=sin.lore.kernel.org; Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sin.lore.kernel.org (Postfix) with ESMTP id 5A9C63037550 for <noreply@patchwork.local>; Thu, 30 Apr 2026 11:09:19 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2727C41C2F5; Thu, 30 Apr 2026 11:07:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=nxp.com header.i=@nxp.com header.b="HlqgIwbJ" X-Original-To: linux-sunxi@lists.linux.dev Received: from AM0PR83CU005.outbound.protection.outlook.com (mail-westeuropeazon11010066.outbound.protection.outlook.com [52.101.69.66]) (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 5F7BB41B361; Thu, 30 Apr 2026 11:07:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.69.66 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777547242; cv=fail; b=J/GD+gYrBsmT+P2NhNHEUw3TlvfVpxFESmDkfSqA/oMvD/OE1hQ0ysx8wczUckAYllOK2I6jP08qxI9+HaRUfU6ZPJw7oDcd4kxkgXeFaBTV6hY2VXRfLip/1LYrhF8Zb3hgBM3iFtwYwea5w/qtxFS2q5sySbc76Ga5WTIEYdg= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777547242; c=relaxed/simple; bh=yvj5998aJtf3Q5D3t2lV33gj2V+Ip37XLsJ1kVsI56I=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: Content-Type:MIME-Version; b=TShIlmxHP7P+AcPN5Xp+hdhcJQqk+2aFxxoUB5QD+i0Qp/WnOS5AhxIhfLRgd3++j46dktbon8nP/rLVhKKW+wz7N01WbDwBDtqVdPrT4pnYrOX6epsZID6Zh/MS4eFJBzuSvQCuW4ME462S04wXkhIrrNEBZFAybDUKc+s85eA= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=nxp.com; spf=pass smtp.mailfrom=nxp.com; dkim=pass (2048-bit key) header.d=nxp.com header.i=@nxp.com header.b=HlqgIwbJ; arc=fail smtp.client-ip=52.101.69.66 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=nxp.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=nxp.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=f7HyCAvH062Au1WiHUg8kN41qQseCTt/ApwOsXn75hHp12Rj59mRtv0ezvgXmAKqO0bbxQN2iMTsQ86bfYvAeqdR8tsqHskWvKhRodkoJH7gQXeqjJlTZdBnR2TOets0xc/k/yINRtijdAgpJcbLWJioAmEa3h9RgweG0XT4zkNVufWwi4RIHDqBB+AwZHwioROc6z6+y8oMnAzgEQI280wDbKMZzwx2K22VS39jCBplGw72Tuv5MY/aeUzI65dVWe1kX4Ny14h4xx5Kw883En1C7/mtR7rnxifRHnn1r1P74Mkp9LNy+VUu2KA7ttLP/7Uadj3S05CH8qWvmHHaRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1QJPjyyLXnZdF9yEeSZ4NvwxeNHOna0J2SuRHf1upYU=; b=mGHYtVzeb/fQ/FF9jOrwnp5LA2kIx4KNcn9s2EEKaf+5KO+z2YatAm+yo3J+Aftzc2VFe6vs/g4fNMPwSAgiiTnHmg//Wsq2px0pv5jZP7s6BugqUSgE27Gxl/aPRPCN8Aob6gJbjcBbbt+dznGce2/pWP1UuOMzUHq02+YXTPH16E9muWPmCdoEUdEUUMePc97YkAHfvs7j8wc4a20xHMtDP/qD7w4znxeKjQ9q2/tbyuytGu9IsrYkOjaqF42DgJkTpwIKqpkaleQmEf5Las27EJrIwqKKQ9pzER8UVDrqA0U400bcCDK9eoFA7UETnlvUMt+bt3dlOjZUgqx3Qg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1QJPjyyLXnZdF9yEeSZ4NvwxeNHOna0J2SuRHf1upYU=; b=HlqgIwbJowg5tfJlIWS+c+7JNj1xSQwHdtwDCuJ3L1USxzomt5moma6Y5nqC1VtGAgYvVu44M6NA1FtiR4XcvjMfngtYHxA6N07nddPA0UuJZ7s3mHuYLsRqgtddug5dnB+Izdd06dD3HmyO9OMIFhKmBusTzkFVTP5osTf4aAtZly1kAji5L1lEXe8WEcLrzkDJrYSEGakE6sGO/j+xsWoC6xyE5a7TRvxBRBBsgabSvjnDKP7A7WJCil+Z4f6thQfwzjQ9PTtYwWRCg4DCtqHF/atCugqEpX1ZAKUU3cdmAl+dHktUafXCGV0pYQn7HGfvqFD0raYFHbR+MXMYoA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nxp.com; Received: from AM9PR04MB8585.eurprd04.prod.outlook.com (2603:10a6:20b:438::13) by VI1PR04MB7182.eurprd04.prod.outlook.com (2603:10a6:800:121::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9870.20; Thu, 30 Apr 2026 11:07:12 +0000 Received: from AM9PR04MB8585.eurprd04.prod.outlook.com ([fe80::f010:fca8:7ef:62f4]) by AM9PR04MB8585.eurprd04.prod.outlook.com ([fe80::f010:fca8:7ef:62f4%4]) with mapi id 15.20.9846.025; Thu, 30 Apr 2026 11:07:12 +0000 From: Vladimir Oltean <vladimir.oltean@nxp.com> To: linux-phy@lists.infradead.org Cc: Vinod Koul <vkoul@kernel.org>, Neil Armstrong <neil.armstrong@linaro.org>, dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-can@vger.kernel.org, linux-gpio@vger.kernel.org, linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, linux-pci@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-riscv@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-scsi@vger.kernel.org, linux-sunxi@lists.linux.dev, linux-tegra@vger.kernel.org, linux-usb@vger.kernel.org, netdev@vger.kernel.org, spacemit@lists.linux.dev, UNGLinuxDriver@microchip.com, Bart Van Assche <bvanassche@acm.org>, Alim Akhtar <alim.akhtar@samsung.com>, "Martin K . Petersen" <martin.petersen@oracle.com>, Peter Griffin <peter.griffin@linaro.org>, "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>, Krzysztof Kozlowski <krzk@kernel.org>, Chanho Park <chanho61.park@samsung.com> Subject: [PATCH v7 phy-next 09/27] scsi: ufs: exynos: stop poking into struct phy guts Date: Thu, 30 Apr 2026 14:06:34 +0300 Message-Id: <20260430110652.558622-10-vladimir.oltean@nxp.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260430110652.558622-1-vladimir.oltean@nxp.com> References: <20260430110652.558622-1-vladimir.oltean@nxp.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: AM0PR10CA0015.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:17c::25) To AM9PR04MB8585.eurprd04.prod.outlook.com (2603:10a6:20b:438::13) Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: <linux-sunxi.lists.linux.dev> List-Subscribe: <mailto:linux-sunxi+subscribe@lists.linux.dev> List-Unsubscribe: <mailto:linux-sunxi+unsubscribe@lists.linux.dev> MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM9PR04MB8585:EE_|VI1PR04MB7182:EE_ X-MS-Office365-Filtering-Correlation-Id: f3262e45-7f41-47fa-29fd-08dea6a8a11e X-LD-Processed: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635,ExtAddr X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|10070799003|7416014|376014|366016|19092799006|1800799024|18002099003|56012099003|22082099003; X-Microsoft-Antispam-Message-Info: uQ6BRxv4JcHbS+k38O0AjKarOe+huf/EtXhvm8ji8sHBbMWtxLl0DZnTQlgxbZn6xAG54feJ6ZerCQnHZ0DXTwUBWRMH073iD9cYCIEwGPNfk3lNoi8AprLQY6OkgIZWVLLwqelZqVg8LYThHBfPV7G1aooVbimuL9aI4w/vVADugSCuMhpKZW7KCaAop4BhWaM6/gO+VhHdaK4URPgZurJZCSMCIigFifqhuRU9AqL/Qx9MHdpZhzlA/PAiqqGAtQSgedngWT/TErmmb8qpnyW6dqi08RppIsUM2QSJhb6X5hUmS1RCfBJT2avjGN4nETlPqnqeL6BjN/5gjZW+UPuf8qzwaPd5BW3hheKaUsu7hcZggDwWTxat4Ef43aUI8+bjGVMWYg7ETGP96nDjSlJm5yGkihEkC0B3Xn424/0ogOOwcZCyY1CAIOJ2hwp0XN6n3OfcEZYeLWP99N4a4vWabNcn3E9YvmyiQ7ueiKhvgFyo1CG6ct0gjVVFU23xMHe52+LJR18nPuHjo4XeiLSzuSDfMIFJv1U00tW+n6c54l0A4sIu9kTaDaBb7fEPyzp99zkiQi/sR3pUWesMfE0DnRgLQk1QGf/kZrl/+VQY64rW/xe0WDi+UoqfOhovWRsPV7sZddGO/2V+AN4mT94ZodvnuP1VRMaPaujGMO8/mia+mSUYRK61lXGLI/nNCBUuFqWl4vaGOL0+x9JcpTtgIvB4Lvabqn0PKfMZbEg= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9PR04MB8585.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(7416014)(376014)(366016)(19092799006)(1800799024)(18002099003)(56012099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: pgDZnIOlO9Sx4kbYGpXGMTchYlY0VoxyFBF0zPxJ5zEx1n3zjCDq5wspqXZDNnoAzYFUXRHTCH6at1/Bqs87vURuw4BnFJ/Hs5eAVzAz+jcbjVoxSP+RvMkbokXKZQ5kLQZDD+2XvkU9wpL9nTyc4hl0cVWvozSGca69kFrA3pbvYhyaNA1SVlhAdcPokY59j6qyIw6WvS8qxV9HIpJu3exvLIP7CFft5faDNluSNNxUVW9hp+Ki46pAU7NvBWhoPLTcr4FFSa3yQdmj3M+mFR2jA7FI8GTm5GeYUCvhjSZOdzDmMaXj+JWZRnynamhHLC2mbpD+500LQCzC9e8Y7zgJMaUA84BIKveqGAfWKKUs5RSrsUWJfP+iOuUPuBN73dFwSv7OPEyozXwpgBXDQvMF4Y+CaMdpw10c73m4DFrE0dYh9Fk5DKEDIiRC0LKAJYFQhGEIsGAcToEM4TJJ9/Kg9w/QQRV/Qxt9SlVDPYgmRMmz11ji4726YnLYmwb32L+VupwNHRRNuG1K1x3ClUV6GxP9IuNUxM9O0Dbd7e+h4lYXFkPlk/h8G9wLvWNNDjuwrrKLfnB8a7zUpcWNi1z+WgrEbNCtFajQ4NTaSGtP0TVnfeWwPDjEX0tOmDhPGthDe+ULUYprxBF2hlQ5rVp/kuQVvKxcGbNDV0ujBI3yqWO3cJcPWTP/hpkN79PD8xpdsWa2yepyEIEhFwrYtKMqmhaIfeWbhnk44rxAR1H65QDjvhinKp90ELYTwD8u9Y/NopbDKp55daAkYHXVlvGQgf+mAvfESwynovOsgD7o0mAgbB8HEQi7LbN0gpEApi/CQEkOWhYgXkpsJE5GC1niHQZ7wICXw7OeezAzGgjRClCpYQxAvT7M11nabgf9+WZmuu/zao2BVQtZaS4ZxN+yAWcRYoVCx8ooMMw7EpeIxhkxDpypGo4fl4Nevkoy4kQvdmN3a0Bj2Q2iU+nqPy1bdSxL9ICwr11c4ZI6xjGsyt6lwNOqS5vphAIIg3CM9nF5qLg3gq31l6gzvGKYjg2W8BZd6i1p4yv/5OR55ZvTHcMZ3GWWvHypZOsp5fj32vfum5+O0LAxNCMqZRpD1Xg1z9YEHvmJ5jvByOuKCj9QuKWUw/5odjSxSUoKkPRmsRMlwop28MyaeG2GMU1282p/h+hMvqAg+t1RgmzXInZgdiaqeF+SUdY6kwvtUWK2SLTUVdgHfJkAucn4wrH7LlD/RinC4y6/40KB2rMNulsmrbpNDmIYFPp3TmShWrgd1jHTPn0hqsHab3fez5kdQwdwzo8o+NsZWTA1j/yWfALU//S6Rye8LO+O1ZSzC+zJ0zv83pbXHV5CwqfU90N9IuLrAXqwuQi0gcwalEVSxdpUf1tXZ0Q8STw7UidSlygXB5gbYv1g4qLBj6T9z5vvuNQn6+6uaAiV4RNYO37ReJqsPpDmP/lFu5iWUaCTfVKyKkWhWuJofqdbEnjMdPfLeLFC/swGnF0fcmsiywVGD2C0TbjpeV5Z/s2quq9Kc8eVUaah0fJwKvBH65DiJYVWfqYdBcsQJz9rM1Dl2KEQHlrj+RZd8v4aAK9hLm6t29Qms4uz0hD6I2NUrpJcy7zOUn+ITjapRFqxJjPcUfuY8Bjhh0YQml5X/Vpj70fKQXigGFJMDKvU0n8algSqZBliWb1JD/396mvLWgvCJB0bE9WNy2RXQggQbIov4bz5mG5XeNmxe/TxOx5BlDiE3Ao3BHR2yrkPymkL3EIUcAAefh4oBeKfZFbkdvzRPn6SLYod X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: f3262e45-7f41-47fa-29fd-08dea6a8a11e X-MS-Exchange-CrossTenant-AuthSource: AM9PR04MB8585.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Apr 2026 11:07:12.2474 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: kIuQtmxuE5y1843gN8NLwBWzm3OllBERGCKiFhD8K3uQuUmQSult87soW07Qbbzrr0rsMwbvLMhQOo/nCSl5+A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB7182 X-MORS-Enabled: yes X-MORS-DOMAIN: patchwork.local X-MORS-HOSTING: hosting172546 X-MORS-USER: hosting172546 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= |
| Series |
Split Generic PHY consumer and provider
|
|
Commit Message
Vladimir Oltean
April 30, 2026, 11:06 a.m. UTC
The Exynos host controller driver is clearly a PHY consumer (gets the ufs->phy using devm_phy_get()), but pokes into the guts of struct phy to get the generic_phy->power_count. The UFS core (specifically ufshcd_link_startup()) may call the variant operation exynos_ufs_pre_link() -> exynos_ufs_phy_init() multiple times if the link startup fails and needs to be retried. However ufs-exynos shouldn't be doing what it's doing, i.e. looking at the generic_phy->power_count, because in the general sense of the API, a single Generic PHY may have multiple consumers. If ufs-exynos looks at generic_phy->power_count, there's no guarantee that this ufs-exynos instance is the one who previously bumped that power count. So it may be powering down the PHY on behalf of another consumer. The correct way in which this should be handled is ufs-exynos should *remember* whether it has initialized and powered up the PHY before, and power it down during link retries. Not rely on the power_count (which, btw, on the writer side is modified under &phy->mutex, but on the reader side is accessed unlocked). This is a discouraged pattern even if here it doesn't cause functional problems. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Acked-by: Alim Akhtar <alim.akhtar@samsung.com> Tested-by: Alim Akhtar <alim.akhtar@samsung.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> --- Cc: Alim Akhtar <alim.akhtar@samsung.com> Cc: Peter Griffin <peter.griffin@linaro.org> Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Chanho Park <chanho61.park@samsung.com> v6->v7: collect tags from Martin and Peter v5->v6: collect tags from Alim Akhtar v4->v5: collect tag, add "scsi: " prefix to commit title v3->v4: none v2->v3: - add Cc Chanho Park, author of commit 3d73b200f989 ("scsi: ufs: ufs-exynos: Change ufs phy control sequence") v1->v2: - add better ufs->phy_powered_on handling in exynos_ufs_exit(), exynos_ufs_suspend() and exynos_ufs_resume() which ensures we won't enter a phy->power_count underrun condition --- drivers/ufs/host/ufs-exynos.c | 24 ++++++++++++++++++++---- drivers/ufs/host/ufs-exynos.h | 1 + 2 files changed, 21 insertions(+), 4 deletions(-)
Comments
Sashiko says: > commit 76ded6c0290bdb192c2ae1af9a2e6a47fc39c9a1 > Author: Vladimir Oltean <vladimir.oltean@nxp.com> > > scsi: ufs: exynos: stop poking into struct phy guts > This commit modifies the Exynos UFS driver to stop directly accessing the > generic PHY's power_count. Instead, it tracks the PHY power state internally > using a new phy_powered_on flag to properly handle link retries and > suspend/resume operations. > > > diff --git a/drivers/ufs/host/ufs-exynos.c b/drivers/ufs/host/ufs-exynos.c > > --- a/drivers/ufs/host/ufs-exynos.c > > +++ b/drivers/ufs/host/ufs-exynos.c > [ ... ] > > @@ -1513,6 +1516,9 @@ static void exynos_ufs_exit(struct ufs_hba *hba) > > { > > struct exynos_ufs *ufs = ufshcd_get_variant(hba); > > > > + if (!ufs->phy_powered_on) > > + return; > > + > > phy_power_off(ufs->phy); > > phy_exit(ufs->phy); > > } > > Does this introduce a regression where initialization resources are leaked > if the driver is unbound while suspended? > Looking at exynos_ufs_suspend(), the PHY is powered off and phy_powered_on > is set to false, but phy_exit() is intentionally not called so the PHY > remains initialized: > exynos_ufs_suspend() > if (!ufshcd_is_link_active(hba) && ufs->phy_powered_on) { > phy_power_off(ufs->phy); > ufs->phy_powered_on = false; > } > If an unbind or fatal error occurs while in this suspended state, > exynos_ufs_exit() will see phy_powered_on as false and return immediately. > The initialization reference and any resources allocated by phy_init() > would never be released since phy_exit() is completely skipped. > [ ... ] I think I've been looking at this issue all wrong, not considering why the UFS HCD driver calls phy_exit() -> phy_init() at runtime and what can be done about that. I have replaced this patch with the one attached, which I will be sending for v8.
diff --git a/drivers/ufs/host/ufs-exynos.c b/drivers/ufs/host/ufs-exynos.c index 77a6c8e44485..be9bfde915ce 100644 --- a/drivers/ufs/host/ufs-exynos.c +++ b/drivers/ufs/host/ufs-exynos.c @@ -949,9 +949,10 @@ static int exynos_ufs_phy_init(struct exynos_ufs *ufs) phy_set_bus_width(generic_phy, ufs->avail_ln_rx); - if (generic_phy->power_count) { + if (ufs->phy_powered_on) { phy_power_off(generic_phy); phy_exit(generic_phy); + ufs->phy_powered_on = false; } ret = phy_init(generic_phy); @@ -965,6 +966,8 @@ static int exynos_ufs_phy_init(struct exynos_ufs *ufs) if (ret) goto out_exit_phy; + ufs->phy_powered_on = true; + return 0; out_exit_phy: @@ -1513,6 +1516,9 @@ static void exynos_ufs_exit(struct ufs_hba *hba) { struct exynos_ufs *ufs = ufshcd_get_variant(hba); + if (!ufs->phy_powered_on) + return; + phy_power_off(ufs->phy); phy_exit(ufs->phy); } @@ -1727,8 +1733,10 @@ static int exynos_ufs_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op, if (ufs->drv_data->suspend) ufs->drv_data->suspend(ufs); - if (!ufshcd_is_link_active(hba)) + if (!ufshcd_is_link_active(hba) && ufs->phy_powered_on) { phy_power_off(ufs->phy); + ufs->phy_powered_on = false; + } return 0; } @@ -1736,9 +1744,17 @@ static int exynos_ufs_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op, static int exynos_ufs_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op) { struct exynos_ufs *ufs = ufshcd_get_variant(hba); + int err; - if (!ufshcd_is_link_active(hba)) - phy_power_on(ufs->phy); + if (!ufshcd_is_link_active(hba) && !ufs->phy_powered_on) { + err = phy_power_on(ufs->phy); + if (err) { + dev_err(hba->dev, "Failed to power on PHY: %pe\n", + ERR_PTR(err)); + } else { + ufs->phy_powered_on = true; + } + } exynos_ufs_config_smu(ufs); exynos_ufs_fmp_resume(hba); diff --git a/drivers/ufs/host/ufs-exynos.h b/drivers/ufs/host/ufs-exynos.h index abe7e472759e..683b9150e2ba 100644 --- a/drivers/ufs/host/ufs-exynos.h +++ b/drivers/ufs/host/ufs-exynos.h @@ -227,6 +227,7 @@ struct exynos_ufs { int avail_ln_rx; int avail_ln_tx; int rx_sel_idx; + bool phy_powered_on; struct ufs_pa_layer_attr dev_req_params; struct ufs_phy_time_cfg t_cfg; ktime_t entry_hibern8_t;