public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: "Michał Mirosław" <mirq-linux@rere.qmqm.pl>
Cc: linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] [PATCH 2/2] mmc: implement SD-combo (IO+mem) support
Date: Fri, 28 May 2010 14:51:50 -0700	[thread overview]
Message-ID: <20100528145150.5257af9f.akpm@linux-foundation.org> (raw)
In-Reply-To: <2-1000-12432-1274803827-7569@rere.qmqm.pl>

On Tue, 25 May 2010 18:10:28 +0200 (CEST)
Micha__ Miros__aw <mirq-linux@rere.qmqm.pl> wrote:

> ---

There's really nothing at all to be said?  I don't even know what
"SD-combo" _is_.  Help us out here!

Why do we need this patch?  What happens if we don't have it?  Where's
the value to our users?  etcetera.


>
> ...
>
> @@ -144,10 +145,10 @@ static int sdio_enable_wide(struct mmc_card *card)
>  	u8 ctrl;
>  
>  	if (!(card->host->caps & MMC_CAP_4_BIT_DATA))
> -		return 0;
> +		return -EOPNOTSUPP;

grr.

"The requested operation is not supported on this type of object. 
 This usually occurs if you are trying to accept(2) a non SOCK_STREAM
 socket."

So if this EOPNOTSUPP gets propagated back to userspace, our poor user
will be looking at his networking code wondering what he did wrong!

Please, just because an error code sounds appropriate, that doesn't
mean that it was the correct thing to use.  ENXIO might be appropriate,
but when in doubt, plain old EIO is good.

> +static int sdio_enable_hs(struct mmc_card *card)
> +{
> +	int err;
> +
> +	err = mmc_sdio_switch_hs(card, true);
> +	if (err)
> +		return err;
> +
> +	if (card->type == MMC_TYPE_SD_COMBO) {
> +		err = mmc_sd_switch_hs(card);
> +		if (err == -EOPNOTSUPP)
> +			mmc_sdio_switch_hs(card, false);
> +	}

Now, if the EOPNOTSUPP is purely for internal use and never gets
propagated back to userspace then I _guess_ that's acceptable.  It's a
kind of internal overloading of an inappropriate identifier for MMC's
own usage.

But it would be clearer and cleaner to not borrow the Unix errnos in
this fashion.  Better to define a set of MMC-specific error codes and
put them in an MMC-specific header file.

> @@ -295,6 +356,34 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32 ocr,
>  
>  	card->type = MMC_TYPE_SDIO;
>  
> +	if (!oldcard || oldcard->type == MMC_TYPE_SDIO) {
> +		u32 cid[4];
> +
> +		err = mmc_sd_get_cid(host, host->ocr & ocr, cid);
> +		if (!err) {
> +			/* this is SD-combo card */
> +			if (oldcard && oldcard->type == MMC_TYPE_SDIO) {
> +				err = -ENOENT;
> +				goto remove;
> +			}
> +			card->type = MMC_TYPE_SD_COMBO;
> +			memcpy(card->raw_cid, cid, sizeof(card->raw_cid));
> +		}
> +	} else if (oldcard->type == MMC_TYPE_SD_COMBO) {
> +		u32 cid[4];
> +
> +		err = mmc_sd_get_cid(host, host->ocr & ocr, cid);
> +		if (err) {
> +			/* this is SDIO-only card */
> +			goto remove;
> +		}
> +
> +		if (memcmp(cid, oldcard->raw_cid, sizeof(cid)) != 0) {
> +			err = -ENOENT;
> +			goto remove;
> +		}
> +	}

Be aware that gcc has a habit of being inefficient with local
variables.  It will probably allocate 32 bytes of stack for the above
two cid[] arrays.  But it could have allocated just 16 bytes.

It's not a big problem in this particular case, but it should be
remembered.  Unfortunately any C-level workaround for this involves
making the source code nastier :(



  reply	other threads:[~2010-05-28 21:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-25 16:10 [RFC] [PATCH 1/2] mmc: split mmc_sd_init_card() Michał Mirosław 
2010-05-25 16:10 ` [RFC] [PATCH 2/2] mmc: implement SD-combo (IO+mem) support Michał Mirosław 
2010-05-28 21:51   ` Andrew Morton [this message]
2010-05-28 21:40 ` [RFC] [PATCH 1/2] mmc: split mmc_sd_init_card() Andrew Morton
2010-05-31 15:58   ` Michał Mirosław
2010-06-03  9:23     ` Adrian Hunter
2010-06-03 17:21       ` Chris Ball
2010-06-03 18:37         ` Michał Mirosław

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100528145150.5257af9f.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=mirq-linux@rere.qmqm.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox