Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753205AbdFTJpX (ORCPT ); Tue, 20 Jun 2017 05:45:23 -0400 Received: from mail-io0-f182.google.com ([209.85.223.182]:36278 "EHLO mail-io0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753153AbdFTJpS (ORCPT ); Tue, 20 Jun 2017 05:45:18 -0400 MIME-Version: 1.0 In-Reply-To: <6b92d0af00024549a0d22dda039780dd@bowex36d.micron.com> References: <1491895862-7952-1-git-send-email-richard.leitner@skidata.com> <0a29de1a-2635-2bb8-808a-7b9a0197921a@skidata.com> <6b92d0af00024549a0d22dda039780dd@bowex36d.micron.com> From: Linus Walleij Date: Tue, 20 Jun 2017 11:45:16 +0200 Message-ID: Subject: Re: [EXT] Re: [PATCH v2] mmc: core: add mmc-card hardware reset enable support To: "Luca Porzio (lporzio)" Cc: Richard Leitner , 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1539 Lines: 46 Hi Luca, thanks for joining! On Wed, Jun 14, 2017 at 6:12 PM, Luca Porzio (lporzio) wrote: > This behavior is not Micron specific but instead it is enforced by the Jedec > Specification. All eMMC must have HW reset disabled by default. That's very good to know. > This specification (as Ulf correctly hinted) originated from badly connected > HW Reset pins which caused unnecessary eMMC reset glitches. > Disabling this feature is a good option to contain glitches and avoid > system level bugs. Ah, makes sense. > 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. This makes a lot of sense. When say ethernet devices need MAC addresses written to their OTP we do not put that into the device tree to be programmed either, we assume production tools to do that job. Yours, Linus Walleij