public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Greg Ungerer <gregungerer@westnet.com.au>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
	linux-mtd@lists.infradead.org,
	Mike Frysinger <vapier.adi@gmail.com>,
	kernel@pengutronix.de, Greg Ungerer <gerg@uclinux.org>
Subject: Re: [PATCH 1/2 v3] mtd/uclinux: support ROM and allow passing the base address
Date: Sat, 12 Jan 2013 21:42:09 +1000	[thread overview]
Message-ID: <50F14C11.5050401@westnet.com.au> (raw)
In-Reply-To: <20130111140222.GJ14860@pengutronix.de>

On 01/12/2013 12:02 AM, Uwe Kleine-König wrote:
> Hello Greg,
>
> On Fri, Jan 11, 2013 at 11:37:29PM +1000, Greg Ungerer wrote:
>> On 01/11/2013 02:31 AM, Uwe Kleine-König wrote:
>>> This allows to put the filesystem at a defined address in ROM allowing
>>> to save more precious RAM.
>>>
>>> I think it's safe to default to ROM because the intention of using the
>>> uclinux map is to use a romfs and so mtd-ram doesn't give you anything
>>> that mtd-rom doesn't.
>>>
>>> Just in case I missed something a warning is added if the driver has to
>>> fall back to the RAM mapping.
>>>
>>> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>>> ---
>>> Changes since v2, id:1350027693-19528-1-git-send-email-u.kleine-koenig@pengutronix.de:
>>>
>>>   - drop a few "ram"s from printks instead of making them "ram/rom"
>>>   - fix a typo in the commit log and add rational for the introduced warning.
>>>
>>> Who is responsible for taking (or not) these two patches? David? Artem?
>>>
>>> Best regards
>>> Uwe
>>>
>>> ---
>>>   drivers/mtd/maps/Kconfig   |    2 +-
>>>   drivers/mtd/maps/uclinux.c |   26 +++++++++++++++++++++-----
>>>   2 files changed, 22 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
>>> index 2e47c2e..0dc86fc 100644
>>> --- a/drivers/mtd/maps/Kconfig
>>> +++ b/drivers/mtd/maps/Kconfig
>>> @@ -443,7 +443,7 @@ config MTD_GPIO_ADDR
>>>
>>>   config MTD_UCLINUX
>>>   	bool "Generic uClinux RAM/ROM filesystem support"
>>> -	depends on MTD_RAM=y && (!MMU || COLDFIRE)
>>> +	depends on (MTD_RAM=y || MTD_ROM=y) && (!MMU || COLDFIRE)
>>>   	help
>>>   	  Map driver to support image based filesystems for uClinux.
>>>
>>> diff --git a/drivers/mtd/maps/uclinux.c b/drivers/mtd/maps/uclinux.c
>>> index 299bf88..b3a9c54 100644
>>> --- a/drivers/mtd/maps/uclinux.c
>>> +++ b/drivers/mtd/maps/uclinux.c
>>> @@ -24,11 +24,12 @@
>>>   /****************************************************************************/
>>>
>>>   struct map_info uclinux_ram_map = {
>>> -	.name = "RAM",
>>> -	.phys = (unsigned long)__bss_stop,
>>>   	.size = 0,
>>>   };
>>>
>>> +static unsigned long physaddr = -1;
>>> +module_param(physaddr, ulong, S_IRUGO);
>>> +
>>>   static struct mtd_info *uclinux_ram_mtdinfo;
>>>
>>>   /****************************************************************************/
>>> @@ -60,11 +61,17 @@ static int __init uclinux_mtd_init(void)
>>>   	struct map_info *mapp;
>>>
>>>   	mapp = &uclinux_ram_map;
>>> +
>>> +	if (physaddr == -1)
>>> +		mapp->phys = (resource_size_t)__bss_stop;
>>> +	else
>>> +		mapp->phys = physaddr;
>>> +
>>>   	if (!mapp->size)
>>>   		mapp->size = PAGE_ALIGN(ntohl(*((unsigned long *)(mapp->phys + 8))));
>>>   	mapp->bankwidth = 4;
>>>
>>> -	printk("uclinux[mtd]: RAM probe address=0x%x size=0x%x\n",
>>> +	printk("uclinux[mtd]: probe address=0x%x size=0x%x\n",
>>>   	       	(int) mapp->phys, (int) mapp->size);
>>>
>>>   	/*
>>> @@ -82,7 +89,16 @@ static int __init uclinux_mtd_init(void)
>>>
>>>   	simple_map_init(mapp);
>>>
>>> -	mtd = do_map_probe("map_ram", mapp);
>>> +	mapp->name = "ROM";
>>> +	mtd = do_map_probe("map_rom", mapp);
>>> +	if (!mtd) {
>>> +		/* fall back to ram probing for compatibility reasons */
>>> +		mapp->name = "RAM";
>>> +		mtd = do_map_probe("map_ram", mapp);
>>> +		if (mtd && IS_ENABLED(CONFIG_MTD_ROM))
>>> +			pr_err("Failed to map rom, but ram succeeded. Please report this issue!\n");
>>
>> I still don't like this, as per:
>>
>> http://lists.infradead.org/pipermail/linux-mtd/2012-October/044612.html
> I remember your concerns, but as you didn't write back on my last try to
> explain why I consider the warning useful, I resent.
 >
> You wrote:
>
>   The message is only printed if both ROM and RAM mappings are enabled.
>   Many of the configs I use only have RAM mappings enabled.
>
> Yeah, so the warning will not trigger for you. And this is correct,
> because the only thing I want to catch is map_rom not being able to
> provide everything needed when map_ram does.

But why?
I still don't see how this is a useful runtime message.


> I don't know what you would prefer. Just drop the warning? Force the
> usage of map_rom by depending on (or selecting) MTD_ROM?

I would suggest dropping the message. And yes making the use map_rom
depend on CONFIG_MAP_ROM being enabled would seem to make sense to me.

Regards
Greg

  reply	other threads:[~2013-01-12 11:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-10 16:31 [PATCH 1/2 v3] mtd/uclinux: support ROM and allow passing the base address Uwe Kleine-König
2013-01-10 16:31 ` [PATCH 2/2 v3] mtd/uclinux: add a comment about why uclinux_ram_map must not be static Uwe Kleine-König
2013-01-11 13:37 ` [PATCH 1/2 v3] mtd/uclinux: support ROM and allow passing the base address Greg Ungerer
2013-01-11 14:02   ` Uwe Kleine-König
2013-01-12 11:42     ` Greg Ungerer [this message]
2013-01-16 14:36 ` [PATCH v4 1/2] " Uwe Kleine-König
2013-01-17  3:12   ` Greg Ungerer
2013-01-17 13:37   ` Artem Bityutskiy
2013-01-16 14:36 ` [PATCH v4 2/2] mtd/uclinux: add a comment about why uclinux_ram_map must not be static Uwe Kleine-König

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=50F14C11.5050401@westnet.com.au \
    --to=gregungerer@westnet.com.au \
    --cc=artem.bityutskiy@linux.intel.com \
    --cc=gerg@uclinux.org \
    --cc=kernel@pengutronix.de \
    --cc=linux-mtd@lists.infradead.org \
    --cc=u.kleine-koenig@pengutronix.de \
    --cc=vapier.adi@gmail.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