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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7B553C433F5 for ; Tue, 26 Apr 2022 13:33:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350966AbiDZNgb (ORCPT ); Tue, 26 Apr 2022 09:36:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47398 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346599AbiDZNg0 (ORCPT ); Tue, 26 Apr 2022 09:36:26 -0400 Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 555D037035 for ; Tue, 26 Apr 2022 06:33:17 -0700 (PDT) Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-2ebf4b91212so182291947b3.8 for ; Tue, 26 Apr 2022 06:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xQJxtHgYo45TypCgF91EJUJX/kpEtMGt2+M/xOBJnMI=; b=SwIK1PdkH4n+khwbHWsA069VnDXEen+KnTWOPpaksm1zszI77d6fkxok+B1KfpsMIU Z8DGXH867i4dqJ+RjIAoUudDdGyaJv5rfW/bxSMufgtl+hF5p6E648Sogatr0G3L9wKd hQdoH1h8hg0jgYD4x90Fy9w1yXLMEk/DWd6RqrPz+tPkKQPrSyO5CXGGltSPkcCQl1gx F+gDmRZBk0Qh/TEUul/7QIJ23O9qnHpbaPw2t2m1mRFzELl3pRHnWyaCTwXUAYi5yVQi k51NW7rxmelAmQ5+PNoVD5SniZRWllE92VyWyfYXNAXpIHcL/L/8URDqvSK3xEjiKykR HMHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xQJxtHgYo45TypCgF91EJUJX/kpEtMGt2+M/xOBJnMI=; b=xmBOOQ0aJDziAskFYDi7CWZOWptlhwQCf5k0qjFFNUgDYGpKwxuMZ0U3GTotTeD9Gh 9NIXLHOpRTAptuoaznW9juTvwVuk9wlY4ZEBTqdfxqhBIcayIW7lqJ6ceoQ6q1QnHSD0 wO9xavLtxYRwTRoQ49kEEKRb+ub/o0hdQ1yTvU0rUr1bnCG19UCZX7Lq3VwxiEEHaxcs 9ABU11bc+NWtsEIhTBtcnnKlhf+u3gzDdGJ5OEWKNeWGeXOvNz5PDWV6rfdSHyxrZpwd 0qe8me/j7pNLHIZG4nm9kwf0opCj+/V1ZtHOflTGUNVCvKGVa85T91RnDJDPsPooMLnO LxkA== X-Gm-Message-State: AOAM532OHPzcLLGdeQRDpHHqir0wrD1FoSS2CsYdkC/AKKdig4XPWFe0 KhmZy/MjO6bS7KVVUXE7thnwtLOPch/peZqBk6vtxfIKdm8= X-Google-Smtp-Source: ABdhPJyNT/CX/SXRXOQuOox6/jWyVG5uSS7VPA9wWYPVI6WZSfJ7419v0oaLcxGDmhwykXFIqSwFNqC/4GfbI9f/pa8= X-Received: by 2002:a81:998e:0:b0:2f4:e2a0:f30f with SMTP id q136-20020a81998e000000b002f4e2a0f30fmr21317098ywg.376.1650979997177; Tue, 26 Apr 2022 06:33:17 -0700 (PDT) MIME-Version: 1.0 References: <20220423221623.1074556-1-huobean@gmail.com> <20220423221623.1074556-3-huobean@gmail.com> <89845bec6c827d7012cda916ee50b16c8eb08755.camel@gmail.com> In-Reply-To: From: Ulf Hansson Date: Tue, 26 Apr 2022 15:32:40 +0200 Message-ID: Subject: Re: [PATCH v1 2/2] mmc: core: Allows to override the timeout value for ioctl() path To: Linus Walleij , Bean Huo Cc: adrian.hunter@intel.com, linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org, beanhuo@micron.com, stable Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 25 Apr 2022 at 22:15, Linus Walleij wrote: > > On Mon, Apr 25, 2022 at 10:02 PM Bean Huo wrote: > > > I think the current solution is the most flexible way, if the customer > > wants to override the kernel default timeout, they know how to initiate > > the correct timeout value in ioctl() based on their specific > > hardware/software system. I don't know how to convince every maintainer > > and reviewer if we don't want to give this permission or want to > > maintain a unified timeout value in the kernel driver. Given that we > > already have eMMC ioctl() support, and we've opened the door to allow > > users to specify specific cmd_timeout_ms in struct mmc_ioc_cmd{}, > > please consider my change. > > The patch is fine, I'm just saying we should put another patch on > top that defines a RPMB default timeout and set it to something > high, such as a minute. I am also okay with $subject patch - and I agree with you Linus, that it sounds reasonable to pick something specific for RPMB. I guess the question is rather what value to pick, but I guess Bean can have some ideas for that, at least for Micron eMMCs. BTW, we do something very similar for mmc_sanitize() already. Kind regards Uffe