From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Anderson Briglia <anderson.briglia@indt.org.br>
Cc: "Lizardo Anderson (EXT-INdT/Manaus)"
<anderson.lizardo@indt.org.br>,
Pierre Ossman <drzeus-list@drzeus.cx>,
linux-kernel@vger.kernel.org,
"Aguiar Carlos (EXT-INdT/Manaus)" <carlos.aguiar@indt.org.br>,
Tony Lindgren <tony@atomide.com>,
ext David Brownell <david-b@pacbell.net>
Subject: Re: [PATCH 4/4] Add MMC Password Protection (lock/unlock) support V8: mmc_sysfs.diff
Date: Fri, 15 Dec 2006 19:37:17 +0000 [thread overview]
Message-ID: <20061215193717.GA10367@flint.arm.linux.org.uk> (raw)
In-Reply-To: <45748173.2050008@indt.org.br>
On Mon, Dec 04, 2006 at 04:13:39PM -0400, Anderson Briglia wrote:
> Implement MMC password force erase, remove password, change password,
> unlock card and assign password operations. It uses the sysfs mechanism
> to send commands to the MMC subsystem.
Sorry, this is still unsuitable for mainline.
> Signed-off-by: Carlos Eduardo Aguiar <carlos.aguiar <at> indt.org.br>
> Signed-off-by: Anderson Lizardo <anderson.lizardo <at> indt.org.br>
> Signed-off-by: Anderson Briglia <anderson.briglia <at> indt.org.br>
Please use the standard format, do not obfuscate these. The kernel
community utterly abhors this.
> +/*
> + * implement MMC password functions: force erase, remove password, change
> + * password, unlock card and assign password.
> + */
> +static ssize_t
> +mmc_lockable_store(struct device *dev, struct device_attribute *att,
> + const char *data, size_t len)
> +{
> + struct mmc_card *card = dev_to_mmc_card(dev);
> + int err = 0;
Where is the check that the host can do byte-wise data transfers?
> +
> + err = mmc_card_claim_host(card);
> + if (err != MMC_ERR_NONE)
> + return -EINVAL;
> +
> + if (!mmc_card_lockable(card))
> + return -EINVAL;
So writing to this file with a card which is not lockable results in
deadlocking the host. Suggest you do as other subsystems do and have
one exit path, and use gotos, setting the appropriate return code in a
variable. If everything goes via that it forces you to think about
where you want to jump to in each case.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
next prev parent reply other threads:[~2006-12-15 19:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-04 20:13 [PATCH 4/4] Add MMC Password Protection (lock/unlock) support V8: mmc_sysfs.diff Anderson Briglia
2006-12-15 19:37 ` Russell King [this message]
2006-12-18 12:41 ` Anderson Briglia
2006-12-23 14:14 ` Pierre Ossman
[not found] ` <F26D8BDC5BC8014A909C6D45468F69EF022B6839@mzebe101.NOE.Nokia.com>
2006-12-27 20:37 ` Pierre Ossman
2006-12-28 20:07 ` Anderson Briglia
2006-12-29 10:34 ` Pierre Ossman
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=20061215193717.GA10367@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--cc=anderson.briglia@indt.org.br \
--cc=anderson.lizardo@indt.org.br \
--cc=carlos.aguiar@indt.org.br \
--cc=david-b@pacbell.net \
--cc=drzeus-list@drzeus.cx \
--cc=linux-kernel@vger.kernel.org \
--cc=tony@atomide.com \
/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