From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756032AbeASPZS (ORCPT ); Fri, 19 Jan 2018 10:25:18 -0500 Received: from mail-sn1nam02on0049.outbound.protection.outlook.com ([104.47.36.49]:30864 "EHLO NAM02-SN1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755751AbeASPY6 (ORCPT ); Fri, 19 Jan 2018 10:24:58 -0500 Authentication-Results: spf=fail (sender IP is 192.88.168.50) smtp.mailfrom=nxp.com; lwn.net; dkim=none (message not signed) header.d=none;lwn.net; 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:13:02 +0800 Message-ID: <1516367582-24422-1-git-send-email-aisheng.dong@nxp.com> X-Mailer: git-send-email 2.7.4 X-EOPAttributedMessage: 0 X-Matching-Connectors: 131608490965841943;(91ab9b29-cfa4-454e-5278-08d120cd25b8);() X-Forefront-Antispam-Report: CIP:192.88.168.50;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(10009020)(39860400002)(39380400002)(396003)(376002)(346002)(2980300002)(1110001)(1109001)(339900001)(189003)(199004)(43544003)(8676002)(47776003)(305945005)(68736007)(59450400001)(51416003)(50226002)(36756003)(81156014)(86362001)(16586007)(6666003)(356003)(54906003)(81166006)(498600001)(2351001)(6916009)(316002)(8936002)(106466001)(105606002)(5660300001)(50466002)(104016004)(53936002)(48376002)(2906002)(4326008)(97736004)(85426001)(26005)(77096007)(107886003);DIR:OUT;SFP:1101;SCL:1;SRVR:BN3PR03MB2356;H:tx30smr01.am.freescale.net;FPR:;SPF:Fail;PTR:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BY2FFO11OLC016;1:d8UmzExuvZBfG+chl5TrDrV1Rz9gsdav2aFKto5Yfn036w3dKLto69xVS/ytG4A2ealKsODkQCFK+pBXLzDGCy95N8b0ycP6p9ai5LNLe60JtZmGVZSecj5PPVoV4pJC MIME-Version: 1.0 Content-Type: text/plain X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 87132f96-89c9-4c28-b817-08d55f50cbe8 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(7020095)(5600026)(4604075)(2017052603307);SRVR:BN3PR03MB2356; X-Microsoft-Exchange-Diagnostics: 1;BN3PR03MB2356;3:1XQBoyEWaRq3OhWfqw+HTSlpVford3WDF3/68NcfdzwWSRH+Vpx4hc4XF91CrQjuG9BRWTs6B53r7dVs3/TfDaK1yURrESsdNSeNkUJBJfvZByCM+BRq4a2VpsLZhanJNbxgjAYQPFpBlNzuVDFm50bIVJF+zYvViv6d+MVS6a91vLZDsn0c7WJ9VI1QA96cMntaxctUymnEQJWnHaRpj/rHHDF+Xv0AkBHmsu+Ms9aOgjvkiQHofOb/0GjL8Xh/qzM0zsbjncO2EpwM1K7e5QL+6E06B2jp46VVg+heQ6zLbAiIW+GvqsWZsmhNA8lVUSu/M/GLXUoj2iY8OludW9XIjH3YzEnZaz8ssYcFPhw=;25:GrFtXdoWdMZRxYnrl6XF3/UEKHsQFBlGy0gFnllMoJ9luX+XfpYUM+4f1V6suoeELNaKihJSNqpZ9DWehVH4LFz0RJ9wyt/7u+tjtxGFjzHD1XftelAyNnW78tiBTzIfxHEM1zn/Q4df9oooEfp6aMAb9//AEPweR3m3X54hNc7EOeIQwQpI7Kw9p5Uq2u+eKiS/RkZjFleiJVf+ffYR8mgMraYeUElwfAHD6NacOUNhvPZEgBRFjFBf3OB2wB9TXLQNt055SzBV8nlTzBYA3SZVLig84PW/Hjucs+81BWrvT7JO1xfZGkh1eBMwJydOMaH7NmPLqQsZeDORF/hIKg== X-MS-TrafficTypeDiagnostic: BN3PR03MB2356: X-Microsoft-Exchange-Diagnostics: 1;BN3PR03MB2356;31:4dkwCVCDcjaWlnth1qXSrSa+8dCj59PBkMPLxu5zQj9Zz4MhYoH48e0hmQZeZuz5de2R04mnt5AW4kJCY1qISCaNvmgb27/YAyIZDxMhtq3uEP+ySsNRcvcbWDYA7rztwZC3kNncGN6lI28pk4XO5iJKXDxySMTLz0lkWM5jCeNZVqHC8qCGGkwkC6f7qUJHkxDLbi8k7A5TPlE22H4/RBN/XhD2xN9VFbKarpkeKJA=;4:SO3mjJlm2a4x+eY5RCKIrFTyjgt0SDGqWp4V+z8S+Qp0IcgWdkWyO49yiuTSRa9adxIj5339XrqR2UFLgO6DKJIO8auBfz+Xu5bojEXnb1/LeAPx7M1BUEl+9E3VECIUdoU31ejv1/fP7qkVRS6q7faml+S0ACxUsjeTJkX45XzavFyGPahi+Js88LiKZcy2nMbUYEavRBvThDunbFx+chTp1LMT7rJYulhjcw4P6p5gc9lakzqwpHU+2SLs7zUpr7MuRIAqABHbXjCg87NZ9B3ddWhWXNX/JIMEUulazpAe/aXVheFROYc+Gs4iNkmY X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(185117386973197); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6095135)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231023)(2400079)(944501161)(10201501046)(6055026)(6096035)(20161123563025)(20161123559100)(20161123556025)(20161123565025)(20161123561025)(201703131430075)(201703131448075)(201703131433075)(201703151042153)(201708071742011);SRVR:BN3PR03MB2356;BCL:0;PCL:0;RULEID:(100000803101)(100110400095)(400006);SRVR:BN3PR03MB2356; X-Forefront-PRVS: 0557CBAD84 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BN3PR03MB2356;23:HlzmrXOPBblH45MK4IIi1UIDKzXv+RdGhaIzrgdJX?= =?us-ascii?Q?G/8kUp3SsXZDBxancvRmBxVXSOGJ1fZsM5CprMAEvvxm2OkNaAgKjo3PALBL?= =?us-ascii?Q?Z2u2l7Do+ogkCz8Jz3aryfUmH32eEmS3HzYvR1BVpfEPdFFwddA+c1T8aBQi?= =?us-ascii?Q?6LtHGDbpZl0sggYn9Wcri8fHCmpBzG9ALhY/IYd6DXuyrIr/D0rnSGsg4RhC?= =?us-ascii?Q?k8TX8TJpwXKCxZkQlYUrvWi+EHhwJOt6F24+Iw53omfMCIXmopLlIs/5Il3r?= =?us-ascii?Q?GAlpdqxsdDXiqV3dR/ZB7fLckrd57ZKM18HUYZNHtCt93xT5abZ8rf9bTLJy?= =?us-ascii?Q?pXrgbSJPtGGDXcL9YyLcF1BVytx4hhgImJtccmdzn/skMTCwjG9KTt+PlC8N?= =?us-ascii?Q?VykPutSuuhIJ16RufJysl1qIkfngVXohM5irnVaLXA1Tbc4RFbfFQxqB1Dlo?= =?us-ascii?Q?8XlC5lo6FEsrcgsHgyz45uJcZWdu0byIuRgMDKBMKri08KFgML79UWxYo2VH?= =?us-ascii?Q?cjUMezo16wOp8NmJLf9pp0d91QXeZH18wd/csfcfregS7tPEHe09V5xjSlYc?= =?us-ascii?Q?S93chnWNvseWShm3ldrblxEPbK8G2o4Y2y4Gwmjd4T5IVl9Lh2CHex5MvS/F?= =?us-ascii?Q?Dyz/LZgWpdVoKKoK5nXQ2S3Ur54Gw+M3LhHOxvafIkDSKvy6U9NL5Gcnx1Ry?= =?us-ascii?Q?9Ywm+LZHxviDqcWfDfR3Sde+/i6VLqXzdcciqmZ+1pTBt/LA3eymH9IglhMs?= =?us-ascii?Q?CQUOuQyeY7zieXe1Ms5mtOLy6EoMZOkeevWZmXteGrKAov/ajmJb8SSMcYf1?= =?us-ascii?Q?EoOhc9krIMhM0/HjEaF+z8Bk7aa+WdTp3D8NFmXAd3+HwjO9Gm5AimTL3YaY?= =?us-ascii?Q?UjN8PjkIC9UlTluc7XX0+B3iP2x4oxuxHsERX8WjyhMxMQeBaoZTNlT+kwgc?= =?us-ascii?Q?P40SvLFvxmW8q6Sr1p8IBZn0PB8MNOV51D91ejc6EOB1DBbHNnU2UeBkznCH?= =?us-ascii?Q?+zZF8eAHA3twYLWXL7XrdAm34jyfzHQ4Pk91CsQP/50FxfXk8G6wdbO6FSf3?= =?us-ascii?Q?tT5NcUgBjdUOjk1Our2QwOYlmXYVN1T22c0oBDbFOXWdvZv+Q=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;BN3PR03MB2356;6:V0eEs8Em+PCl0DfkHkNn2XUu8ps9Q4VWgmE3R9QyjwpxmIyv1BJWIYgbhZBrpGlJkDaJ3vZ3zQVnH/Y2JKnF9lDAz0AJHOlTHgO1dOFzb+odVrI2KKpSHif3aFZ4+Cl29erNDdWqaRY43epWky0yOPBYVVTNQRzpaiDviSyTTijjhO82N5R29TwP6S9sUrJLeIqwSYk8N7ONi+XtG6Nqu0UqUeWUVStXlHF2CoF5ifCBUKM4fCjVyx08eniZ+6o7HPzTVNZRI84vv6P4F7xHDEN9oriphkzFFfNjV0zNsb8EXCEZHpzZqHF7BeUGzjMPorBCB2qPVnnEMCDbQiynglEWBSN1PMjlA3V0JL4P3Hc=;5:TqJlP2AUrdpU7vcbJVIXXUhU8b1u+wY5n8EVbPpO77XECVsIn5qDH7XQwE1OWoQsMtT6VOF6gYCWXbVmxtPb047n6M9f0qbehDCWkjK3H05KTcGynzp76Vm3vzesvPFBQd7dvj0hCL1/0oJ2OkUn6RCCu4K9F+s9Nk/r5zVIeB8=;24:a2YdrrJh08yuq/bJNksG7xMvA7n5GRRbLotSx7S7Cf3ZY7HdDhy1keAaaD0KYDu+VO6KfTb06GtOc6oBYApMuhdmAkVK5N25TaqzW6j4VAs=;7:RBF38uYyMFPb1UgVKDKsnvjVRYFuQyAshrAuFZ9fqUsUKmAm6CzRLENsJ4Hy6viVKRwNfkGKaridgbOCVoODLqEp6afL4qd7WAzPJKZT+Yup1nNCS4cy04SJhljTFke817iVqp7/WwPKzX+u1UHg5qvHZBVHFKdEAgdqIRIpbQI2RYDa9mmPHaHyBDLdbB4yBHbfpPs4RvlcL2u7kEz7AhuH0oa+E9mNQqTEXx799B7yXREFk+TZtSoGyDuFTikN SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jan 2018 15:24:54.6342 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 87132f96-89c9-4c28-b817-08d55f50cbe8 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: BN3PR03MB2356 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:13:02 +0800 Subject: [PATCH 1/1] Documentation: clk: enable lock is not held for clk_is_enabled API Message-ID: <1516367582-24422-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