From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5DEB2C43613 for ; Mon, 24 Jun 2019 11:56:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 30B53212F5 for ; Mon, 24 Jun 2019 11:56:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727638AbfFXLz7 (ORCPT ); Mon, 24 Jun 2019 07:55:59 -0400 Received: from ns.iliad.fr ([212.27.33.1]:54742 "EHLO ns.iliad.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727579AbfFXLz7 (ORCPT ); Mon, 24 Jun 2019 07:55:59 -0400 Received: from ns.iliad.fr (localhost [127.0.0.1]) by ns.iliad.fr (Postfix) with ESMTP id 02C7520598; Mon, 24 Jun 2019 13:55:58 +0200 (CEST) Received: from [192.168.108.49] (freebox.vlq16.iliad.fr [213.36.7.13]) by ns.iliad.fr (Postfix) with ESMTP id BF36F202C7; Mon, 24 Jun 2019 13:55:57 +0200 (CEST) Subject: Re: [PATCH v1] phy: qcom-qmp: Raise qcom_qmp_phy_enable() polling delay To: Kishon Vijay Abraham I , Vivek Gautam , Bjorn Andersson , Douglas Anderson Cc: MSM , LKML References: <92d97c68-d226-6290-37d6-f46f42ea604b@free.fr> <134f4648-682e-5fed-60e7-bc25985dd7e9@free.fr> From: Marc Gonzalez Message-ID: <967571b1-358f-09c3-dee6-0e664ab3c3d3@free.fr> Date: Mon, 24 Jun 2019 13:55:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP ; ns.iliad.fr ; Mon Jun 24 13:55:58 2019 +0200 (CEST) Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On 20/06/2019 08:25, Kishon Vijay Abraham I wrote: > On 14/06/19 6:08 PM, Marc Gonzalez wrote: > >> The issue is usleep_range() being misused ^_^ >> >> Although usleep_range() takes unsigned longs as parameters, it is >> not appropriate over the entire 0-2^64 range. >> >> a) It should not be used with tiny values, because the cost of programming >> the timer interrupt, and processing the resulting IRQ would dominate. >> >> b) It should not be used with large values (above 2000000/HZ) because >> msleep() is more efficient, and is acceptable for these ranges. > > Documentation/timers/timers-howto.txt has all the information on the various > kernel delay/sleep mechanisms. For < ~10us, it recommends to use udelay > (readx_poll_timeout_atomic). Depending on the actual timeout to be used, the > delay mechanism in timers-howto.txt should be used. Hello Kishon, I believe the proposed patch does the right thing: a) polling for the ready bit is not done in atomic context, therefore we don't need to busy-loop b) since we're ultimately calling usleep_range(), we should pass an appropriate parameter, such as max_us = 10 (instead of max_us = 1, which is outside usleep_range spec) Maybe it would help if someone reviewed this patch. Regards.