On Wed, Aug 22, 2012 at 11:25 AM, Nicolas Pitre [off-list ref] wrote:

On Wed, 22 Aug 2012, Olof Johansson wrote:

quoted

On Wed, Aug 22, 2012 at 9:00 AM, Philip Rakity [off-list ref] wrote:

quoted

On Aug 22, 2012, at 8:44 AM, Doug Anderson [off-list ref] wrote:

quoted

Thanks for your feedback.  In this case I have a card that is an MMC
card so mmc_attach_sdio() and mmc_attach_sd() will fail.  If I let
mmc_attach_mmc() run it will actually find the MMC card.  However, on
this platform it is not valid to recognize MMC cards.

Understand.

Can you explain why the change is needed.  Is it for technical
reasons that MMC is not allowed -- if so then I do not understand how SD can work
and MMC cannot.

If it is for marketing reasons -- then --- oh well .....


Could you add some additional comments to the commit message.
I think it makes sense to handle all 3 cases
a) SDIO not allowed
b) SD not allowed
c) MMC not allowed

We are working with a system manufacturer who wishes to only support
SD cards in their product, and need to accommodate that. It made sense
for us to contribute this work upstream since others might want to do
the same in the future for some reason.

Adding all three cases makes sense if others foresee a use case for it.

Isn't this rather revolting?

Personally I find such "feature" totally ridiculous. If said
manufacturer doesn't want to support MMC cards, they just have to not
advertise it, period.  Or if they really mean it, then they only have to
state it explicitly in their user manual, and repeat it if ever problems
are reported.

Dumbing down kernel functionality to serve marketing purpose or
technology lock-ins is utterly stupid.  Purposely restricting
interoperability might even be ruled illegal in some jurisdictions.

I therefore insist on providing a vehement NAK on such patches.

Ok, thanks. We'll keep carrying it locally instead then.


-Olof