Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1670570 > unrolled thread

Re: [EXT] Re: [PATCH v2] mmc: core: add mmc-card hardware reset enable support

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [EXT] Re: [PATCH v2] mmc: core: add mmc-card hardware reset  enable support Linus Walleij <linus.walleij@linaro.org> - 2017-06-20 11:50 +0200
    Re: [EXT] Re: [PATCH v2] mmc: core: add mmc-card hardware reset  enable support Richard Leitner <richard.leitner@skidata.com> - 2017-06-20 12:40 +0200
      Re: [EXT] Re: [PATCH v2] mmc: core: add mmc-card hardware reset  enable support Linus Walleij <linus.walleij@linaro.org> - 2017-06-20 18:20 +0200

#1670570 — Re: [EXT] Re: [PATCH v2] mmc: core: add mmc-card hardware reset enable support

Hi Luca,

thanks for joining!

On Wed, Jun 14, 2017 at 6:12 PM, Luca Porzio (lporzio)
<lporzio@micron.com> 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

[toc] | [next] | [standalone]

#1670659

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

[toc] | [prev] | [next] | [standalone]

#1670919

On Tue, Jun 20, 2017 at 12:24 PM, Richard Leitner
<richard.leitner@skidata.com> wrote:

> 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?

That makes a lot of sense. Because the situation is ambigous.
We provide the hardware to reset the card, but the card says it
does not accept a reset.

Yours,
Linus Walleij

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web