Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751133AbdFTKeZ (ORCPT ); Tue, 20 Jun 2017 06:34:25 -0400 Received: from mail2.skidata.com ([91.230.2.91]:23855 "EHLO mail2.skidata.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750925AbdFTKeX (ORCPT ); Tue, 20 Jun 2017 06:34:23 -0400 X-Greylist: delayed 603 seconds by postgrey-1.27 at vger.kernel.org; Tue, 20 Jun 2017 06:34:22 EDT X-IronPort-AV: E=Sophos;i="5.39,364,1493676000"; d="scan'208";a="717033" Subject: Re: [EXT] Re: [PATCH v2] mmc: core: add mmc-card hardware reset enable support To: Linus Walleij , "Luca Porzio (lporzio)" CC: Ulf Hansson , Bart Van Assche , Rob Herring , Mark Rutland , Shawn Lin , Adrian Hunter , Jaehoon Chung , "linux-mmc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , Richard Leitner References: <1491895862-7952-1-git-send-email-richard.leitner@skidata.com> <0a29de1a-2635-2bb8-808a-7b9a0197921a@skidata.com> <6b92d0af00024549a0d22dda039780dd@bowex36d.micron.com> From: Richard Leitner Message-ID: Date: Tue, 20 Jun 2017 12:24:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [172.16.60.30] X-ClientProxiedBy: sdex1srv.skidata.net (172.16.10.92) To sdex1srv.skidata.net (172.16.10.92) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1188 Lines: 31 On 06/20/2017 11:45 AM, Linus Walleij wrote: >> IMHO mmc-util is where the patch really stands: the enabling is OTP, >> the programmer have to use mmc-util only once and the kernel >> will behave accordingly. > > So we should not add it to the device tree. > >> Any platform vendor must check that the HW Reset pin is actually >> Connected BEFORE enabling this feature otherwise the system may be >> unstable. A DT Binding may be dangerous if this condition is not met >> as well as the code execution at each MMC init is honestly redundant >> for an OTP location of the extCSD. > > I agree. So the device should be configured during production, or > a user who know exactly what they are doing may reconfigure it > using the mmc-utils. > > Thus the kernel should just read what the device says and stay with > that, no DT props or anything. Ok. Thanks for that clarification to everybody involved! Should we then add a warning/info message to the kernel if we have a reset gpio configured in the DT, but the eMMC hasn't this OTP bit set? Or should we just leave it as it is? (Due to the fact the reset-gpio could be connected to an external reset chip?) kind regards, Richard.L