mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ben Hutchings <ben@decadent.org.uk>
To: John Stultz <john.stultz@linaro.org>, Colin Cross <ccross@android.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Chuanxiao Dong <chuanxiao.dong@intel.com>,
	Shawn Lin <shawn.lin@rock-chips.com>,
	Austin S Hemmelgarn <ahferroin7@gmail.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Android Kernel Team <kernel-team@android.com>,
	linux-mmc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH v2] mmc_block: Allow more than 8 partitions per card
Date: Thu, 22 Oct 2015 19:13:08 +0100	[thread overview]
Message-ID: <1445537588.10397.74.camel@decadent.org.uk> (raw)
In-Reply-To: <1445537261.10397.70.camel@decadent.org.uk>

[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]

On Thu, 2015-10-22 at 19:07 +0100, Ben Hutchings wrote:
> On Thu, 2015-10-22 at 10:00 -0700, John Stultz wrote:
> > From: Colin Cross <ccross@android.com>
> > 
> > It is quite common for Android devices to utilize more
> > then 8 partitions on internal eMMC storage.
> > 
> > The vanilla kernel can support this via
> > CONFIG_MMC_BLOCK_MINORS, however that solution caps the
> > system to 256 minors total, which limits the number of
> > mmc cards the system can support.
> [...]
> 
> This commit was intended to allow support for 256 cards with any number
> of partitions:
> 
> commit a26eba614afff0e39594101bcb73014a9a22fb33
> Author: Ben Hutchings <ben@decadent.org.uk>
> Date:   Thu Nov 6 03:35:09 2014 +0000
> 
>     mmc: block: Increase max_devices
> 
> I don't think the new patch is sufficient or necessary to increase the
> limit further.

Of course, this does allow use of more than any predefined number of
partitions per card, the same as sd can.  So it still has some
usefulness, though the commit message seems to overstate that.

Ben.

> Do you have a compatibility requirement to retain the numbering of the
> first 7 partitions?
> 
> Ben.
> 
-- 
Ben Hutchings
Q.  Which is the greater problem in the world today, ignorance or apathy?
A.  I don't know and I couldn't care less.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

  reply	other threads:[~2015-10-22 18:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-22 17:00 John Stultz
2015-10-22 18:07 ` Ben Hutchings
2015-10-22 18:13   ` Ben Hutchings [this message]
2015-12-15 15:11 ` Ulf Hansson

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=1445537588.10397.74.camel@decadent.org.uk \
    --to=ben@decadent.org.uk \
    --cc=adrian.hunter@intel.com \
    --cc=ahferroin7@gmail.com \
    --cc=arnd@arndb.de \
    --cc=ccross@android.com \
    --cc=chuanxiao.dong@intel.com \
    --cc=john.stultz@linaro.org \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=shawn.lin@rock-chips.com \
    --cc=ulf.hansson@linaro.org \
    /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

all inboxes | Powered by JetHome®