[PATCH 1/2] [MTD] Add support for RAM & ROM mappings in the physmap_of MTD driver.

[PATCH 1/2] [MTD] Add support for RAM & ROM mappings in the physmap_of MTD driver.

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
=2D--
 drivers/mtd/maps/physmap_of.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.c
index 49acd41..65c30b5 100644
=2D-- a/drivers/mtd/maps/physmap_of.c
+++ b/drivers/mtd/maps/physmap_of.c
@@ -273,6 +273,14 @@ static struct of_device_id of_flash_match[] =3D {
 		.data		=3D (void *)"jedec_probe",
 	},
 	{
+		.compatible	=3D "physmap-ram",
+		.data		=3D (void *)"map_ram",
+	},
+	{
+		.compatible	=3D "physmap-rom",
+		.data		=3D (void *)"map_rom",
+	},
+	{
 		.type		=3D "rom",
 		.compatible	=3D "direct-mapped"
 	},
=2D-=20
1.5.0


=2D-=20
Laurent Pinchart
CSE Semaphore Belgium

Chauss=E9e de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
=46 +32 (2) 387 42 75

Re: [PATCH 1/2] [MTD] Add support for RAM & ROM mappings in the physmap_of MTD driver.

[Segher Boessenkool]

>  	{
> +		.compatible	= "physmap-ram",
> +		.data		= (void *)"map_ram",
> +	},
> +	{
> +		.compatible	= "physmap-rom",
> +		.data		= (void *)"map_rom",
> +	},

Why the cast?  It's redundant afaics.


Segher

Re: [PATCH 1/2] [MTD] Add support for RAM & ROM mappings in the physmap_of MTD driver.

[Sergei Shtylyov]

Segher Boessenkool wrote:

>>      {
>> +        .compatible    = "physmap-ram",
>> +        .data        = (void *)"map_ram",
>> +    },
>> +    {
>> +        .compatible    = "physmap-rom",
>> +        .data        = (void *)"map_rom",
>> +    },

> Why the cast?  It's redundant afaics.

   To be in line with the surrounding code...

> Segher

WBR, Sergei

Re: [PATCH 1/2] [MTD] Add support for RAM & ROM mappings in the physmap_of MTD driver.

[Segher Boessenkool]

>>>      {
>>> +        .compatible    = "physmap-ram",
>>> +        .data        = (void *)"map_ram",
>>> +    },
>>> +    {
>>> +        .compatible    = "physmap-rom",
>>> +        .data        = (void *)"map_rom",
>>> +    },
>
>> Why the cast?  It's redundant afaics.
>
>   To be in line with the surrounding code...

I see _that_, but it's not a great argument IMNSHO.  Could I trick
you into preceding this patch with a cleanup patch for the existing
casts?


Segher

Re: [PATCH 1/2] [MTD] Add support for RAM & ROM mappings in the physmap_of MTD driver.

[David Gibson]

On Wed, Mar 26, 2008 at 04:34:58PM +0100, Segher Boessenkool wrote:
>>>>      {
>>>> +        .compatible    = "physmap-ram",
>>>> +        .data        = (void *)"map_ram",
>>>> +    },
>>>> +    {
>>>> +        .compatible    = "physmap-rom",
>>>> +        .data        = (void *)"map_rom",
>>>> +    },
>>
>>> Why the cast?  It's redundant afaics.
>>
>>   To be in line with the surrounding code...
>
> I see _that_, but it's not a great argument IMNSHO.  Could I trick
> you into preceding this patch with a cleanup patch for the existing
> casts?

Hrm.  Much as I generally dislike redundant casts, these ones do serve
to inform the reader that the data field is not always a string, which
they might otherwise assume.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [PATCH 1/2] [MTD] Add support for RAM & ROM mappings in the physmap_of MTD driver.

[Laurent Pinchart]

On Wednesday 26 March 2008 16:34, Segher Boessenkool wrote:
> >>>      {
> >>> +        .compatible    =3D "physmap-ram",
> >>> +        .data        =3D (void *)"map_ram",
> >>> +    },
> >>> +    {
> >>> +        .compatible    =3D "physmap-rom",
> >>> +        .data        =3D (void *)"map_rom",
> >>> +    },
> >
> >> Why the cast?  It's redundant afaics.
> >
> >   To be in line with the surrounding code...
>=20
> I see _that_, but it's not a great argument IMNSHO.  Could I trick
> you into preceding this patch with a cleanup patch for the existing
> casts?

Ok. I'll submit a new patch as soon as we agree on a compatible name.

=2D-=20
Laurent Pinchart
CSE Semaphore Belgium

Chauss=E9e de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
=46 +32 (2) 387 42 75

Re: [PATCH 1/2] [MTD] Add support for RAM & ROM mappings in the physmap_of MTD driver.

[David Woodhouse]

On Thu, 2008-03-27 at 10:26 +0100, Laurent Pinchart wrote:
> Ok. I'll submit a new patch as soon as we agree on a compatible name.

Did we?

-- 
dwmw2

Re: [PATCH 1/2] [MTD] Add support for RAM & ROM mappings in the physmap_of MTD driver.

[Sergei Shtylyov]

David Woodhouse wrote:

>>Ok. I'll submit a new patch as soon as we agree on a compatible name.

> Did we?

    IIRC, The latest agreement was that we don't need the "compatible" and 
will match on node name.

WBR, Sergei

Re: [PATCH 1/2] [MTD] Add support for RAM & ROM mappings in the physmap_of MTD driver.

[David Woodhouse]

On Wed, 2008-04-23 at 00:16 +0400, Sergei Shtylyov wrote:
> David Woodhouse wrote:
> 
> >>Ok. I'll submit a new patch as soon as we agree on a compatible name.
> 
> > Did we?
> 
>     IIRC, The latest agreement was that we don't need the "compatible" and 
> will match on node name.

Ok. Is there a current patch I should be merging?

-- 
dwmw2

Re: [PATCH 1/2] [MTD] Add support for RAM & ROM mappings in the physmap_of MTD driver.

[Sergei Shtylyov]

David Woodhouse wrote:

>>>>Ok. I'll submit a new patch as soon as we agree on a compatible name.

>>>Did we?

>>    IIRC, The latest agreement was that we don't need the "compatible" and 
>>will match on node name.

> Ok. Is there a current patch I should be merging?

    Looks like it was decided to revert to the platform device method, not 
sure why -- so, no changes. Laurent?

WBR, Sergei

Re: [PATCH 1/2] [MTD] Add support for RAM & ROM mappings in the physmap_of MTD driver.

[Laurent Pinchart]

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

On Wednesday 23 April 2008 13:12, Sergei Shtylyov wrote:
> David Woodhouse wrote:
> 
> >>>>Ok. I'll submit a new patch as soon as we agree on a compatible name.
> 
> >>>Did we?
> 
> >>    IIRC, The latest agreement was that we don't need the "compatible" and 
> >>will match on node name.
> 
> > Ok. Is there a current patch I should be merging?
> 
>     Looks like it was decided to revert to the platform device method, not 
> sure why -- so, no changes. Laurent?

Last thing I heard was that the device tree should not encode a device's 
expected usage, so memory nodes should not have any compatible property that 
would automatically associated them to an MTD driver. I've been adviced to 
add platform-specific code to instantiate a platform device manually 
(possibly checking if the required memory node is present in the device 
tree). This arguably makes sense, but adds more platform-specific code.

So, no need for a patch so far.

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: [PATCH 1/2] [MTD] Add support for RAM & ROMmappings in the physmap_of MTD driver.

[Rune Torgersen]

Laurent Pinchart wrote:
> Last thing I heard was that the device tree should not encode
> a device's
> expected usage, so memory nodes should not have any
> compatible property that
> would automatically associated them to an MTD driver. I've
> been adviced to
> add platform-specific code to instantiate a platform device manually
> (possibly checking if the required memory node is present in
> the device
> tree). This arguably makes sense, but adds more
> platform-specific code.

So... What good it the device tree at all then, if intended usage should
not be encoded in there.
Most other devices has an intended usage encoded.

Examples would be the FCC's on a Freescale PQ2 chip, where they are
encoded as ethernet controllers. (Thsy could be used as high-speed HDLC
controllers, ATM controllers and other usages), the SCC ports (as
serial, they can be used for syncronous serial and HDLC)

That would also mean if usage would change, the kernel image (and
possiby u-boot) whould have to change, instead of just fixing the device
tree. Argh....

Re: [PATCH 1/2] [MTD] Add support for RAM & ROMmappings in the physmap_of MTD driver.

[Scott Wood]

On Mon, Apr 28, 2008 at 11:26:15AM -0500, Rune Torgersen wrote:
> Examples would be the FCC's on a Freescale PQ2 chip, where they are
> encoded as ethernet controllers. (Thsy could be used as high-speed HDLC
> controllers, ATM controllers and other usages), the SCC ports (as
> serial, they can be used for syncronous serial and HDLC)

But that choice is made by board-level hardware, not purely by software.

-Scott