From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755695AbeASNhg (ORCPT ); Fri, 19 Jan 2018 08:37:36 -0500 Received: from mail-bn3nam01on0084.outbound.protection.outlook.com ([104.47.33.84]:10176 "EHLO NAM01-BN3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753841AbeASNh2 (ORCPT ); Fri, 19 Jan 2018 08:37:28 -0500 Authentication-Results: spf=fail (sender IP is 192.88.168.50) smtp.mailfrom=nxp.com; codeaurora.org; dkim=none (message not signed) header.d=none;codeaurora.org; dmarc=fail action=none header.from=nxp.com; From: Dong Aisheng To: CC: , , , , Dong Aisheng , Jonathan Corbet , Stephen Boyd Subject: [PATCH 1/1] Documentation: clk: enable lock is not held for clk_is_enabled API Date: Fri, 19 Jan 2018 21:37:15 +0800 Message-ID: <1516369035-24740-1-git-send-email-aisheng.dong@nxp.com> X-Mailer: git-send-email 2.7.4 X-EOPAttributedMessage: 0 X-Matching-Connectors: 131608426457145724;(91ab9b29-cfa4-454e-5278-08d120cd25b8);() X-Forefront-Antispam-Report: CIP:192.88.168.50;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(10009020)(396003)(39860400002)(346002)(376002)(39380400002)(2980300002)(1109001)(1110001)(339900001)(43544003)(189003)(199004)(81156014)(50466002)(53936002)(51416003)(8676002)(36756003)(8936002)(47776003)(59450400001)(68736007)(104016004)(50226002)(48376002)(77096007)(97736004)(305945005)(26005)(2906002)(356003)(81166006)(54906003)(86362001)(498600001)(2351001)(85426001)(16586007)(6666003)(4326008)(105606002)(6916009)(8656006)(5660300001)(106466001)(316002);DIR:OUT;SFP:1101;SCL:1;SRVR:CO2PR03MB2358;H:tx30smr01.am.freescale.net;FPR:;SPF:Fail;PTR:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BL2FFO11FD040;1:X2xUPmcFNaNZRfpEqpNg5JYQW/WcSSXemNJC2BZDiRM9V0zEQiycWRzQwT5rAzXgatIP7q+eF7KoNzrhW6/b0P1mcyrkLPS3kKshgpMM+gL2WB3f5EBx0ehwu8rOj+fL MIME-Version: 1.0 Content-Type: text/plain X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b0eca7f8-9d19-471a-217c-08d55f41c6e4 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(7020095)(5600026)(4604075)(2017052603307);SRVR:CO2PR03MB2358; X-Microsoft-Exchange-Diagnostics: 1;CO2PR03MB2358;3:hgi65AcRGtM47pzKwRDN3LkBXlJltOdiMpg3E1LDTATku1yZkMx+Xm+G2vLnKSN2khiKku1rR150eUQhkRCqza/FGa3UFiZm07lWw4IaYFYQfwoL4aYzJTeor1BwXen5j2bgr6lDc9JPqn4VSIQ+iP+HPcQ10JJg8ePUe6/O+6zwF4PNSXGrq5DJqN5GJwUmLcIIIJHgOKSln3M3XeztiUdSOf0NY91VV6pRev6Np5A/KOhK5aqC4aNRVybmRrnq6DlYUoAyaAS/sFzjXq0kTfunbNsJ9RXFqoDbwtvQAHnvXI3pFPXEE3bzTbuOehDjZRYT/+I80OEEE6wE/ec0PovoGqmkO15hWHA+H5RJzvg=;25:84huKWj/Kk8fNVCJY4/w13Xvm+cYlYgqU6WJc58DR1ObgmJA6HVfjXqnsOJ8veY2A0v0FDzZDueq0QxXtwoomt6xgr71ADh1J7tFU8FPDCoP7YvfMEHgSf1M20Lcmx8dEZ3GvHeBg5MVNycZbfagU5fCTRqqOD1n6BhPWWpW+28gk7jwRSKnQ5jH4+0iMV+18Ymy4UwCCnVjpU++Vkng8VF/t0K4Ps4biGWa/Lf5Hio2RISg9ToN8jVzmjuUzhvMwEOnJO06hProu3BkKrS5MMmUu8JnElaY/SdfV2SI3ZUBKYHoF9GiUKeICiPE3Eyq7YVbRNOmZVRJ/9X1C2zfLw== X-MS-TrafficTypeDiagnostic: CO2PR03MB2358: X-Microsoft-Exchange-Diagnostics: 1;CO2PR03MB2358;31:Qq6wYElnz8Dx/mwzWVeDtNsnfx/ju1KzPmwGteP+q2EY33M83a+qSjxvMghpZ+pVSNw0g9HyZAaJhXSlggqaffs/zhC5ldR9DYfenowEc6GzeSdLory6zIDV6I7o1LbNvPyE4Whezb+hypqpmv/Gr5p0GAEPQMCVZjcqe14/YfoWMkTS9ICbEkfDX8UgGBjesie99l9GH4DlPOTtmOldJ9t76W2pO+ZO10zILwGvEqg=;4:wIUFEHC3VmvpdSyEB3m0tz2preBC4dnZlA62Y5LxcgmqMrm00v+Jcr8QCgpT95L0NZ431saq3WEzFU1k9A1QkkDwFcLwRqYuafeA2SWx4pGGXiQkbyDBWHO6ih8SQ/icDx1TnFTqrOxX+F9bIs12jAgWdLaT/2dajUB2cWFL+OfSkcfubDl+zsTUps8ukrBgLBhffiY4LieCog6uDTTxFxSKpHPoy4P1SOjsysthj30bfMdz38Q9XIUCCJr5yJma7wCd4+F5BWzp2Hl+gg5/MGfcXr57v4AFP7INF+CDY+DxVmkjNmPXeSq+yqyn9G9J X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(185117386973197); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6095135)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231023)(2400078)(944501161)(10201501046)(6055026)(6096035)(20161123565025)(20161123556025)(20161123563025)(20161123561025)(201703131430075)(201703131448075)(201703131433075)(201703151042153)(20161123559100)(201708071742011);SRVR:CO2PR03MB2358;BCL:0;PCL:0;RULEID:(100000803101)(100110400095)(400006);SRVR:CO2PR03MB2358; X-Forefront-PRVS: 0557CBAD84 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;CO2PR03MB2358;23:jTSvWpa/1DKo+GfbaUGB5QKilc9hQB7+AedG2C+kd?= =?us-ascii?Q?hKX1u6ezB6ziW9tNtN8LOXu1BK69rj/MBn+7/B8CMwP6yQT89nvpZtF/CPzp?= =?us-ascii?Q?TQebRW7GLe+KXKu5K7O5Iz+qf5WYMdqYELHz3xzo4pGPoc5kHTmNKGSENTQI?= =?us-ascii?Q?HXJOOgEnhzjYI2rMOwPnn+q52nRRmJ1Ox+tx8zG4GzHqWUSb9jNb8DaGG9/w?= =?us-ascii?Q?fycX9FSdIkcYCJeQp4m0p7Ug5UFu74BiCyUH5tj29WQs6kRH8ku8sgRw+G/M?= =?us-ascii?Q?eWwI+DOKe2T8PCRDlFkPy2luI8+S2Qe8eAn22SoVzY3QorGp8wgXaRXcI4EM?= =?us-ascii?Q?F85lUfdwr4fBmWTeLTjpBKVVrvBcQskiPovq9uk83WkafujpQugo3hmDyJf2?= =?us-ascii?Q?V2HwQAifdMfiY4j9oYTCFo6tHcff5GaXm6pc6wkxLQeA17oH8DpoyXBcbmKV?= =?us-ascii?Q?0RxTRDyRMyFJ7fWMRGYioxuuy219PITv4lisoMt8bA97KLwkxIbVlaNvyqSM?= =?us-ascii?Q?Fn4PctUN64+du4IPXHIRuL28bvZ8PyRBnkLDAVL61UOS6b0j/amfeigWwg9Z?= =?us-ascii?Q?IJHpFG2kliBFlyz/aGZ5Gidsa4NdRG+hYxUoefjyZTQphfQLnxZZgPVVOHWC?= =?us-ascii?Q?7W4bu7k7RbKjcYUqyu096klnMyGIUxcNm3pPEv1wPy2D+fesVZUkKBAwyeLp?= =?us-ascii?Q?hJfu2nvGOer9iyz/vnB9mo1tsO3HuHagZUGEvWoA+OYXqoO+n+tA8QK59rE/?= =?us-ascii?Q?fopFGr9P1GuAIaCTxLi7wf8DzrynGLkrZSiJN6jhuJ5hbcDopkiDxeAtSDJn?= =?us-ascii?Q?UKLkLl+sZeYohmdZaGIu3t4Q0hKOPzI8tP+DM3UklAAYh4CbXLQXulBT412T?= =?us-ascii?Q?OfxJ/t6ehZmf7xlLeYJMHdMOuwglZwDpg5Mzby7HhLBGqvgoIrRTrD+srQta?= =?us-ascii?Q?6Hhlk3JeXe1Ijw6UQMiL0O58qqBNlHQWUvuJChBnITdT2+awdkED/kPq8dBU?= =?us-ascii?Q?reOLFw3Jjnlci/+Rk3tOlpQ0xPhuOy27oKyppUELZVw6YCSPeNRFZiVUJFVN?= =?us-ascii?Q?BVt8aQMdBt5E3lWnWpd1S8PAtFo?= X-Microsoft-Exchange-Diagnostics: 1;CO2PR03MB2358;6:N9BdWtf2GYuPqVNrF7aR+qJHcoAaKCNfRl/B0DJi3e07uzYHan4vmmm2BomNV/zxMdevAdidWi/h6hGbtn1b0ztTuBT3LA2zBFp2KAoG0a0UeDzl/CfpV1+i0xzFkV/v8PtO+pwz2DgwFA3E1cI5JR5YYNlMygxalqN37FR7qFE7+hcgkpFVveBEPPo+Vp7wHr40jPBbrgjTUaTQ4Tzs7MNFVGJg+vKyHz0gQEwhgKnLEcpF79OJQeVximQZ+uF6DMYwaY4+nDxIZqFRyeu1XsiyceSOX7THYF4HQ7o1eLGZTpWKFbx+1+0ohkQJ/SH9ApMzK48LuHWL2ydGrtxNrNpYMvjAkTBj+3/G8yRJoZ8=;5:4N0y7MJcBVTqdk+K7GX+p1jBWfdQqSVi1kvgW3AhzACyzsznwabWC+OA0ryKyGoMDmUlaPaZxb7MZmCR4b6V73ZWSOzuAnP2OLmQWbZeW+LzCy3ISjzPWpRbJScX17oZqDOI5N5S1rKpQbEVKe+Sx14vx6uN9h+A/rzKMPUhu4A=;24:PWxf4JHFw7jivKJxYjMfjRotXIIVLFnoCpqA29vR7TSdiIVnz3YD3OylR2JKvYMdTmiMfffAYBj6iVfwNGfNOUJeKt/ZlKPHjeKsJlYzn0A=;7:X6BW5XgXWoCqmfGIfpGIf57QnVurQ6q7X4RFBOduPVHmlDFo/RERP8UapkvL6TvvF+JiiGkkPznVR14t7Hq0zrD56XpbK88GGYpx7zd/hOp9q2L4lUQrH5gvJuWcQvH/c1IcTukJ6jicquYX1X79QkeuuKjphS8PNgZ6sCoTgSFBT+tR0PskH5de5eOrs60ZIaR7gnHo3U9Yt9LYiVH3rfc3aX88IWNCGZzC4wgIcV6KP+mNLrvcR/QcAjwu9Uj9 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jan 2018 13:37:25.5585 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b0eca7f8-9d19-471a-217c-08d55f41c6e4 X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e;Ip=[192.88.168.50];Helo=[tx30smr01.am.freescale.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2358 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The core does not need to hold enable lock for clk_is_enabled API. Update the doc to reflect it. Cc: Jonathan Corbet Cc: Stephen Boyd Suggested-by: Stephen Boyd Signed-off-by: Dong Aisheng --- Documentation/clk.txt | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/Documentation/clk.txt b/Documentation/clk.txt index be909ed..f286ff5 100644 --- a/Documentation/clk.txt +++ b/Documentation/clk.txt @@ -268,9 +268,17 @@ The common clock framework uses two global locks, the prepare lock and the enable lock. The enable lock is a spinlock and is held across calls to the .enable, -.disable and .is_enabled operations. Those operations are thus not allowed to -sleep, and calls to the clk_enable(), clk_disable() and clk_is_enabled() API -functions are allowed in atomic context. +.disable operations. Those operations are thus not allowed to sleep, +and calls to the clk_enable(), clk_disable() API functions are allowed in +atomic context. + +For clk_is_enabled() API, it is also designed to be allowed to be used in +atomic context. However, it doesn't really make any sense to hold the enable +lock in core, unless you want to do something else with the information of +the enable state with that lock held. Otherwise, seeing if a clk is enabled is +a one-shot read of the enabled state, which could just as easily change after +the function returns because the lock is released. Thus driver onwer needs +judge and take care of it in their driver if it needs lock. The prepare lock is a mutex and is held across calls to all other operations. All those operations are allowed to sleep, and calls to the corresponding API -- 2.7.4 From mboxrd@z Thu Jan 1 00:00:00 1970 From: aisheng.dong@nxp.com (Dong Aisheng) Date: Fri, 19 Jan 2018 21:37:15 +0800 Subject: [PATCH 1/1] Documentation: clk: enable lock is not held for clk_is_enabled API Message-ID: <1516369035-24740-1-git-send-email-aisheng.dong@nxp.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org The core does not need to hold enable lock for clk_is_enabled API. Update the doc to reflect it. Cc: Jonathan Corbet Cc: Stephen Boyd Suggested-by: Stephen Boyd Signed-off-by: Dong Aisheng --- Documentation/clk.txt | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/Documentation/clk.txt b/Documentation/clk.txt index be909ed..f286ff5 100644 --- a/Documentation/clk.txt +++ b/Documentation/clk.txt @@ -268,9 +268,17 @@ The common clock framework uses two global locks, the prepare lock and the enable lock. The enable lock is a spinlock and is held across calls to the .enable, -.disable and .is_enabled operations. Those operations are thus not allowed to -sleep, and calls to the clk_enable(), clk_disable() and clk_is_enabled() API -functions are allowed in atomic context. +.disable operations. Those operations are thus not allowed to sleep, +and calls to the clk_enable(), clk_disable() API functions are allowed in +atomic context. + +For clk_is_enabled() API, it is also designed to be allowed to be used in +atomic context. However, it doesn't really make any sense to hold the enable +lock in core, unless you want to do something else with the information of +the enable state with that lock held. Otherwise, seeing if a clk is enabled is +a one-shot read of the enabled state, which could just as easily change after +the function returns because the lock is released. Thus driver onwer needs +judge and take care of it in their driver if it needs lock. The prepare lock is a mutex and is held across calls to all other operations. All those operations are allowed to sleep, and calls to the corresponding API -- 2.7.4