Enabling MMC BKOPs in kernel based on host caps

Enabling MMC BKOPs in kernel based on host caps

[Ravikumar Kattekola]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="y", Size: 1042 bytes --]

Hi all,
	I’ve seen an eMMC failure due to pending background operations on a certain OMAP device since bkops enable bit was not set.
Further investigation showed me that someone already posted patch to enable Background operations in kernel  based on a host capability check (Caps2 & BK_OPS_EN)
but was turned down quoting that it should be enabled from user space using mmc-utils.

Enabling this would add one additional check for exception event in the response R1 or R1B (only on hosts that explicitly set BK_OPS_EN in caps2).
But not enabling this could lead to a system failure especially when the Filesystem is on eMMC and the card stops responding due to pending critical bkops.

I would like to ask for expert opinion on ‘why is it a bad idea to enable bkops in kernel?’
It’s a one time programmable bit but if it helps in keeping system functional why not do it?
I haven’t measured the performance impact but I don’t see a reason for major drop because the frequency of critical bkops events would be less.

Regards,
RK 

Re: Enabling MMC BKOPs in kernel based on host caps

[Shawn Lin]

Hi Ravikumar,

+ Alex,

在 2016/10/3 18:43, Ravikumar Kattekola 写道:
> Hi all,
> 	I’ve seen an eMMC failure due to pending background operations on a certain OMAP device since bkops enable bit was not set.
> Further investigation showed me that someone already posted patch to enable Background operations in kernel  based on a host capability check (Caps2 & BK_OPS_EN)
> but was turned down quoting that it should be enabled from user space using mmc-utils.
>
> Enabling this would add one additional check for exception event in the response R1 or R1B (only on hosts that explicitly set BK_OPS_EN in caps2).
> But not enabling this could lead to a system failure especially when the Filesystem is on eMMC and the card stops responding due to pending critical bkops.
>
> I would like to ask for expert opinion on ‘why is it a bad idea to enable bkops in kernel?’

Some discussion about the similar topic could be found here:
https://patchwork.kernel.org/patch/9157121/


> It’s a one time programmable bit but if it helps in keeping system functional why not do it?

Actually BKOPS_EN is not OTP bit.. Quoted from Ulf "I don't have any
issue to allow all non-OTP registers bits to be written." So I guess
you could do this, although it needs more discussion there.

But it's persistent EXT_CSD register and we get used to control it from
userspace, which is the policy we have been sticking to when writing to
persistent EXT_CSD registers. I guess that is nothing about "right and
wrong", just a rule for us in case someone wants to set the persistent
bit in kernel but setting other persistent bits from user-space, which
is prone to mess up the mmc core. Or, someone will sent mail to the list
asking "why is it a good idea to enable bkops in kernel" ? :)

> I haven’t measured the performance impact but I don’t see a reason for major drop because the frequency of critical bkops events would be less.
>
> Regards,
> RK
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Best Regards
Shawn Lin

Re: Enabling MMC BKOPs in kernel based on host caps

[Ravikumar]

Hi Shawn,


On Wednesday 05 October 2016 03:07 PM, Shawn Lin wrote:
> Hi Ravikumar,
>
> + Alex,
>
> 在 2016/10/3 18:43, Ravikumar Kattekola 写道:
>> Hi all,
>>     I’ve seen an eMMC failure due to pending background operations on 
>> a certain OMAP device since bkops enable bit was not set.
>> Further investigation showed me that someone already posted patch to 
>> enable Background operations in kernel  based on a host capability 
>> check (Caps2 & BK_OPS_EN)
>> but was turned down quoting that it should be enabled from user space 
>> using mmc-utils.
>>
>> Enabling this would add one additional check for exception event in 
>> the response R1 or R1B (only on hosts that explicitly set BK_OPS_EN 
>> in caps2).
>> But not enabling this could lead to a system failure especially when 
>> the Filesystem is on eMMC and the card stops responding due to 
>> pending critical bkops.
>>
>> I would like to ask for expert opinion on ‘why is it a bad idea to 
>> enable bkops in kernel?’
>
> Some discussion about the similar topic could be found here:
> https://patchwork.kernel.org/patch/9157121/
>
>
>> It’s a one time programmable bit but if it helps in keeping system 
>> functional why not do it?
>
> Actually BKOPS_EN is not OTP bit.. Quoted from Ulf "I don't have any
> issue to allow all non-OTP registers bits to be written." So I guess
> you could do this, although it needs more discussion there.
In the spec for 4.5, jesd84_B45 it does say not whether the ENABLE bit 
is OTP.
But in 5.1 spec, jesd84-b51, it says MANUAL_EN is R/W which means OTP 
and readable.
As I read form mmc-utils -help
"        mmc bkops enable <device>
                 Enable the eMMC BKOPS feature on <device>.
                 NOTE!  This is a one-time programmable (unreversible) 
change "
>
> But it's persistent EXT_CSD register and we get used to control it from
> userspace, which is the policy we have been sticking to when writing to
> persistent EXT_CSD registers. I guess that is nothing about "right and
> wrong", just a rule for us in case someone wants to set the persistent
> bit in kernel but setting other persistent bits from user-space, which
> is prone to mess up the mmc core. Or, someone will sent mail to the list
> asking "why is it a good idea to enable bkops in kernel" ? :)
So there's no functional problem/reason that stops us from enabling 
BKOPS (Manual) in
kernel except for consistency with other persistent registers.
Since not enabling BKOPS could lead to a functional failure / 
non-responsive system
at a later point of time I guess this could be exempted.
what do you think?

As user I would choose functional safety and reliability over performance.
Hence it would make sense to have the bkops (at least manual) be enabled 
by default,
especially in Automotive applications.

>
>> I haven’t measured the performance impact but I don’t see a reason 
>> for major drop because the frequency of critical bkops events would 
>> be less.
>>
>> Regards,
>> RK
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
Thanks for your response.

Regards,
RK

Re: Enabling MMC BKOPs in kernel based on host caps

[Alex Lemberg]

Hi Ravikumar,

The reason for enabling Auto/Manual BKOPS is understandable.
Personally I don’t think that user space should play with a storage device 
BKOPS settings, it should be a matter of storage device and a driver decision. 
But as Shown mentioned, there is a discussion on this topic.
Also, recently I have submitted a patch for letting device more time
to complete its BKOPS on runtime Suspend:
http://www.spinics.net/lists/linux-mmc/msg38952.html

Thanks,
Alex

On 10/5/16, 1:55 PM, "Ravikumar" <a0131654@ti.com> wrote:

>Hi Shawn,
>
>
>On Wednesday 05 October 2016 03:07 PM, Shawn Lin wrote:
>> Hi Ravikumar,
>>
>> + Alex,
>>
>> 在 2016/10/3 18:43, Ravikumar Kattekola 写道:
>>> Hi all,
>>>     I’ve seen an eMMC failure due to pending background operations on 
>>> a certain OMAP device since bkops enable bit was not set.
>>> Further investigation showed me that someone already posted patch to 
>>> enable Background operations in kernel  based on a host capability 
>>> check (Caps2 & BK_OPS_EN)
>>> but was turned down quoting that it should be enabled from user space 
>>> using mmc-utils.
>>>
>>> Enabling this would add one additional check for exception event in 
>>> the response R1 or R1B (only on hosts that explicitly set BK_OPS_EN 
>>> in caps2).
>>> But not enabling this could lead to a system failure especially when 
>>> the Filesystem is on eMMC and the card stops responding due to 
>>> pending critical bkops.
>>>
>>> I would like to ask for expert opinion on ‘why is it a bad idea to 
>>> enable bkops in kernel?’
>>
>> Some discussion about the similar topic could be found here:
>> https://patchwork.kernel.org/patch/9157121/
>>
>>
>>> It’s a one time programmable bit but if it helps in keeping system 
>>> functional why not do it?
>>
>> Actually BKOPS_EN is not OTP bit.. Quoted from Ulf "I don't have any
>> issue to allow all non-OTP registers bits to be written." So I guess
>> you could do this, although it needs more discussion there.
>In the spec for 4.5, jesd84_B45 it does say not whether the ENABLE bit 
>is OTP.
>But in 5.1 spec, jesd84-b51, it says MANUAL_EN is R/W which means OTP 
>and readable.
>As I read form mmc-utils -help
>"        mmc bkops enable <device>
>                 Enable the eMMC BKOPS feature on <device>.
>                 NOTE!  This is a one-time programmable (unreversible) 
>change "
>>
>> But it's persistent EXT_CSD register and we get used to control it from
>> userspace, which is the policy we have been sticking to when writing to
>> persistent EXT_CSD registers. I guess that is nothing about "right and
>> wrong", just a rule for us in case someone wants to set the persistent
>> bit in kernel but setting other persistent bits from user-space, which
>> is prone to mess up the mmc core. Or, someone will sent mail to the list
>> asking "why is it a good idea to enable bkops in kernel" ? :)
>So there's no functional problem/reason that stops us from enabling 
>BKOPS (Manual) in
>kernel except for consistency with other persistent registers.
>Since not enabling BKOPS could lead to a functional failure / 
>non-responsive system
>at a later point of time I guess this could be exempted.
>what do you think?
>
>As user I would choose functional safety and reliability over performance.
>Hence it would make sense to have the bkops (at least manual) be enabled 
>by default,
>especially in Automotive applications.
>
>>
>>> I haven’t measured the performance impact but I don’t see a reason 
>>> for major drop because the frequency of critical bkops events would 
>>> be less.
>>>
>>> Regards,
>>> RK
>>> -- 
>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>>
>Thanks for your response.
>
>Regards,
>RK
>

Re: Enabling MMC BKOPs in kernel based on host caps

[Ravikumar]

Hi Alex,


On Thursday 06 October 2016 03:39 AM, Alex Lemberg wrote:
> Hi Ravikumar,
>
> The reason for enabling Auto/Manual BKOPS is understandable.
> Personally I don’t think that user space should play with a storage device
> BKOPS settings, it should be a matter of storage device and a driver decision.
> But as Shown mentioned, there is a discussion on this topic.
> Also, recently I have submitted a patch for letting device more time
> to complete its BKOPS on runtime Suspend:
> http://www.spinics.net/lists/linux-mmc/msg38952.html
>
> Thanks,
> Alex
Thanks for sharing this information.

I totally agree with you, it should be the driver who makes the decision.

I'm still wondering why there's a concern even after adding a platform 
level check.

Should the code to enable BKOPS be wrapped inside a CONFIG_ENABLE_BKOPS
in order to give the individual an option to change the default behavior?

Thanks and Regards,
RK
>
> On 10/5/16, 1:55 PM, "Ravikumar" <a0131654@ti.com> wrote:
>
>> Hi Shawn,
>>
>>
>> On Wednesday 05 October 2016 03:07 PM, Shawn Lin wrote:
>>> Hi Ravikumar,
>>>
>>> + Alex,
>>>
>>> 在 2016/10/3 18:43, Ravikumar Kattekola 写道:
>>>> Hi all,
>>>>      I’ve seen an eMMC failure due to pending background operations on
>>>> a certain OMAP device since bkops enable bit was not set.
>>>> Further investigation showed me that someone already posted patch to
>>>> enable Background operations in kernel  based on a host capability
>>>> check (Caps2 & BK_OPS_EN)
>>>> but was turned down quoting that it should be enabled from user space
>>>> using mmc-utils.
>>>>
>>>> Enabling this would add one additional check for exception event in
>>>> the response R1 or R1B (only on hosts that explicitly set BK_OPS_EN
>>>> in caps2).
>>>> But not enabling this could lead to a system failure especially when
>>>> the Filesystem is on eMMC and the card stops responding due to
>>>> pending critical bkops.
>>>>
>>>> I would like to ask for expert opinion on ‘why is it a bad idea to
>>>> enable bkops in kernel?’
>>> Some discussion about the similar topic could be found here:
>>> https://patchwork.kernel.org/patch/9157121/
>>>
>>>
>>>> It’s a one time programmable bit but if it helps in keeping system
>>>> functional why not do it?
>>> Actually BKOPS_EN is not OTP bit.. Quoted from Ulf "I don't have any
>>> issue to allow all non-OTP registers bits to be written." So I guess
>>> you could do this, although it needs more discussion there.
>> In the spec for 4.5, jesd84_B45 it does say not whether the ENABLE bit
>> is OTP.
>> But in 5.1 spec, jesd84-b51, it says MANUAL_EN is R/W which means OTP
>> and readable.
>> As I read form mmc-utils -help
>> "        mmc bkops enable <device>
>>                  Enable the eMMC BKOPS feature on <device>.
>>                  NOTE!  This is a one-time programmable (unreversible)
>> change "
>>> But it's persistent EXT_CSD register and we get used to control it from
>>> userspace, which is the policy we have been sticking to when writing to
>>> persistent EXT_CSD registers. I guess that is nothing about "right and
>>> wrong", just a rule for us in case someone wants to set the persistent
>>> bit in kernel but setting other persistent bits from user-space, which
>>> is prone to mess up the mmc core. Or, someone will sent mail to the list
>>> asking "why is it a good idea to enable bkops in kernel" ? :)
>> So there's no functional problem/reason that stops us from enabling
>> BKOPS (Manual) in
>> kernel except for consistency with other persistent registers.
>> Since not enabling BKOPS could lead to a functional failure /
>> non-responsive system
>> at a later point of time I guess this could be exempted.
>> what do you think?
>>
>> As user I would choose functional safety and reliability over performance.
>> Hence it would make sense to have the bkops (at least manual) be enabled
>> by default,
>> especially in Automotive applications.
>>
>>>> I haven’t measured the performance impact but I don’t see a reason
>>>> for major drop because the frequency of critical bkops events would
>>>> be less.
>>>>
>>>> Regards,
>>>> RK
>>>> -- 
>>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>> Thanks for your response.
>>
>> Regards,
>> RK
>>

Re: Enabling MMC BKOPs in kernel based on host caps

[Alex Lemberg]

Hi Ravikumar,

[…]

>Should the code to enable BKOPS be wrapped inside a CONFIG_ENABLE_BKOPS
>in order to give the individual an option to change the default behavior?

In case both storage device and the driver decide to enable BKOPS 
based on internal status, params and registers, I don’t think the user should 
have such an option in config?
But anyway, I would let Ulf and Shawn to comment on this.

Thanks,
Alex

[…]

Re: Enabling MMC BKOPs in kernel based on host caps

[Adrian Hunter]

On 05/10/16 14:55, Ravikumar wrote:
> Hi Shawn,
> 
> 
> On Wednesday 05 October 2016 03:07 PM, Shawn Lin wrote:
>> Hi Ravikumar,
>>
>> + Alex,
>>
>> 在 2016/10/3 18:43, Ravikumar Kattekola 写道:
>>> Hi all,
>>>     I’ve seen an eMMC failure due to pending background operations on a
>>> certain OMAP device since bkops enable bit was not set.

It is not clear what you are talking about. BKOPS_EN is
one-time-programmable so you can just set when the device is provisioned.

However BKOPS_EN does not really enable background operations.  It is an
indication from the host to the card about whether the card may delay
maintenance operations.  The definition is:

"This field allows the host to indicate to the device if it is expected to
periodically manually start background operations by writing to the
BKOPS_START field."

Currently the kernel does not do periodic background operations, so having
the kernel set BKOPS_EN would not make sense - even if it wasn't
one-time-programmable.

>>> Further investigation showed me that someone already posted patch to
>>> enable Background operations in kernel  based on a host capability check
>>> (Caps2 & BK_OPS_EN)
>>> but was turned down quoting that it should be enabled from user space
>>> using mmc-utils.
>>>
>>> Enabling this would add one additional check for exception event in the
>>> response R1 or R1B (only on hosts that explicitly set BK_OPS_EN in caps2).
>>> But not enabling this could lead to a system failure especially when the
>>> Filesystem is on eMMC and the card stops responding due to pending
>>> critical bkops.

Yes the kernel only does urgent background operations if BKOPS_EN is set.
You seem to be suggesting that the cards are violating the specification by
delaying maintenance operations even though they are not allowed to because
BKOPS_EN is not set.  Is that the case?

>>>
>>> I would like to ask for expert opinion on ‘why is it a bad idea to enable
>>> bkops in kernel?’

It is one-time-programmable so the kernel should not have to program it,
because it should have already been programmed when the device was provisioned.

>>
>> Some discussion about the similar topic could be found here:
>> https://patchwork.kernel.org/patch/9157121/
>>
>>
>>> It’s a one time programmable bit but if it helps in keeping system
>>> functional why not do it?
>>
>> Actually BKOPS_EN is not OTP bit.. Quoted from Ulf "I don't have any
>> issue to allow all non-OTP registers bits to be written." So I guess
>> you could do this, although it needs more discussion there.
> In the spec for 4.5, jesd84_B45 it does say not whether the ENABLE bit is OTP.

That is not entirely accurate.  Table 75 clearly lists it as R/W meaning
one-time-programmable and readable.

> But in 5.1 spec, jesd84-b51, it says MANUAL_EN is R/W which means OTP and
> readable.
> As I read form mmc-utils -help
> "        mmc bkops enable <device>
>                 Enable the eMMC BKOPS feature on <device>.
>                 NOTE!  This is a one-time programmable (unreversible) change "
>>
>> But it's persistent EXT_CSD register and we get used to control it from
>> userspace, which is the policy we have been sticking to when writing to
>> persistent EXT_CSD registers. I guess that is nothing about "right and
>> wrong", just a rule for us in case someone wants to set the persistent
>> bit in kernel but setting other persistent bits from user-space, which
>> is prone to mess up the mmc core. Or, someone will sent mail to the list
>> asking "why is it a good idea to enable bkops in kernel" ? :)
> So there's no functional problem/reason that stops us from enabling BKOPS
> (Manual) in
> kernel except for consistency with other persistent registers.
> Since not enabling BKOPS could lead to a functional failure / non-responsive
> system
> at a later point of time I guess this could be exempted.
> what do you think?
> 
> As user I would choose functional safety and reliability over performance.
> Hence it would make sense to have the bkops (at least manual) be enabled by
> default,
> especially in Automotive applications.
> 
>>
>>> I haven’t measured the performance impact but I don’t see a reason for
>>> major drop because the frequency of critical bkops events would be less.
>>>
>>> Regards,
>>> RK
>>> -- 
>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>>
> Thanks for your response.
> 
> Regards,
> RK
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Enabling MMC BKOPs in kernel based on host caps

[Ulf Hansson]

On 12 October 2016 at 09:09, Adrian Hunter <adrian.hunter@intel.com> wrote:
> On 05/10/16 14:55, Ravikumar wrote:
>> Hi Shawn,
>>
>>
>> On Wednesday 05 October 2016 03:07 PM, Shawn Lin wrote:
>>> Hi Ravikumar,
>>>
>>> + Alex,
>>>
>>> 在 2016/10/3 18:43, Ravikumar Kattekola 写道:
>>>> Hi all,
>>>>     I’ve seen an eMMC failure due to pending background operations on a
>>>> certain OMAP device since bkops enable bit was not set.
>
> It is not clear what you are talking about. BKOPS_EN is
> one-time-programmable so you can just set when the device is provisioned.
>
> However BKOPS_EN does not really enable background operations.  It is an
> indication from the host to the card about whether the card may delay
> maintenance operations.  The definition is:
>
> "This field allows the host to indicate to the device if it is expected to
> periodically manually start background operations by writing to the
> BKOPS_START field."
>
> Currently the kernel does not do periodic background operations, so having
> the kernel set BKOPS_EN would not make sense - even if it wasn't
> one-time-programmable.

Agree!

However, in cases when the BKOPS_EN bit has been set (in one way or
the other), this do becomes a problem as we currently only supports
urgent background operations.
Perhaps we should print a warning when BKOPS_EN is set during card
initialization, as this isn't currently supported.

>
>>>> Further investigation showed me that someone already posted patch to
>>>> enable Background operations in kernel  based on a host capability check
>>>> (Caps2 & BK_OPS_EN)
>>>> but was turned down quoting that it should be enabled from user space
>>>> using mmc-utils.
>>>>
>>>> Enabling this would add one additional check for exception event in the
>>>> response R1 or R1B (only on hosts that explicitly set BK_OPS_EN in caps2).
>>>> But not enabling this could lead to a system failure especially when the
>>>> Filesystem is on eMMC and the card stops responding due to pending
>>>> critical bkops.
>
> Yes the kernel only does urgent background operations if BKOPS_EN is set.
> You seem to be suggesting that the cards are violating the specification by
> delaying maintenance operations even though they are not allowed to because
> BKOPS_EN is not set.  Is that the case?
>

If this is the case, the solution would probably be to actually set
the BKOPS_EN bit from the kernel, perhaps via using a card quirk.

Although, to do that, we first need to add proper background
operations support. I guess that is what Alex intends to do here [1].

[...]

[1]
http://www.spinics.net/lists/linux-mmc/msg38952.html

Kind regards
Uffe

Re: Enabling MMC BKOPs in kernel based on host caps

[Jaehoon Chung]

On 10/12/2016 04:58 PM, Ulf Hansson wrote:
> On 12 October 2016 at 09:09, Adrian Hunter <adrian.hunter@intel.com> wrote:
>> On 05/10/16 14:55, Ravikumar wrote:
>>> Hi Shawn,
>>>
>>>
>>> On Wednesday 05 October 2016 03:07 PM, Shawn Lin wrote:
>>>> Hi Ravikumar,
>>>>
>>>> + Alex,
>>>>
>>>> 在 2016/10/3 18:43, Ravikumar Kattekola 写道:
>>>>> Hi all,
>>>>>     I’ve seen an eMMC failure due to pending background operations on a
>>>>> certain OMAP device since bkops enable bit was not set.
>>
>> It is not clear what you are talking about. BKOPS_EN is
>> one-time-programmable so you can just set when the device is provisioned.
>>
>> However BKOPS_EN does not really enable background operations.  It is an
>> indication from the host to the card about whether the card may delay
>> maintenance operations.  The definition is:
>>
>> "This field allows the host to indicate to the device if it is expected to
>> periodically manually start background operations by writing to the
>> BKOPS_START field."
>>
>> Currently the kernel does not do periodic background operations, so having
>> the kernel set BKOPS_EN would not make sense - even if it wasn't
>> one-time-programmable.
> 
> Agree!
> 
> However, in cases when the BKOPS_EN bit has been set (in one way or
> the other), this do becomes a problem as we currently only supports
> urgent background operations.
> Perhaps we should print a warning when BKOPS_EN is set during card
> initialization, as this isn't currently supported.

When i had added the bkops features, i remembered that discussed about this.
(set BKOPS_EN from kernel..or not..)

When enable the bkops_en by default, there should be a problem...
(I'm not sure..but at that time..Chris had wanted to remove the enabling bkops by default.)

For just understanding..i added the changelog for my bkops patch.

https://patchwork.kernel.org/patch/1466501/

> 
>>
>>>>> Further investigation showed me that someone already posted patch to
>>>>> enable Background operations in kernel  based on a host capability check
>>>>> (Caps2 & BK_OPS_EN)
>>>>> but was turned down quoting that it should be enabled from user space
>>>>> using mmc-utils.
>>>>>
>>>>> Enabling this would add one additional check for exception event in the
>>>>> response R1 or R1B (only on hosts that explicitly set BK_OPS_EN in caps2).
>>>>> But not enabling this could lead to a system failure especially when the
>>>>> Filesystem is on eMMC and the card stops responding due to pending
>>>>> critical bkops.
>>
>> Yes the kernel only does urgent background operations if BKOPS_EN is set.
>> You seem to be suggesting that the cards are violating the specification by
>> delaying maintenance operations even though they are not allowed to because
>> BKOPS_EN is not set.  Is that the case?
>>
> 
> If this is the case, the solution would probably be to actually set
> the BKOPS_EN bit from the kernel, perhaps via using a card quirk.
> 
> Although, to do that, we first need to add proper background
> operations support. I guess that is what Alex intends to do here [1].
> 
> [...]
> 
> [1]
> http://www.spinics.net/lists/linux-mmc/msg38952.html
> 
> Kind regards
> Uffe
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
>