Re: [PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.
This isn't a problem with this device tree, but it's probably time we started establishing some conventional generic names for nand flash and board-control devices. So, to start the ball rolling, I've seen several names for nand flash nodes, I'd suggest we standardise on "nand-flash". What's wrong with the already well-established generic name "flash"? I was concerned that using "flash" for both NOR flash (which it already is) and NAND flash might be unwise. I am quite open to being convinced otherwise, though. You already said you're convinced, but I'll add another argument anyway... For NAND flash, there will usually be a parent node named "nand-controller" or similar, while NOR flash will typically be direct-mapped. There is always this tension between making the names as generic as possible, and not losing too much information. In my experience, you can always make leaf nodes have very very generic names, it's only the bus nodes where this can be harder. And then there are exceptions like "board-control" where there just _is_ no really good name ;-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.
On Tue, Mar 11, 2008 at 01:43:49AM +0100, Arnd Bergmann wrote: > On Tuesday 11 March 2008, David Gibson wrote: > > On Fri, Mar 07, 2008 at 04:39:30AM +0100, Segher Boessenkool wrote: > > > > This isn't a problem with this device tree, but it's probably time we > > > > started establishing some conventional generic names for nand flash > > > > and board-control devices. > > > > > > > > So, to start the ball rolling, I've seen several names for nand flash > > > > nodes, I'd suggest we standardise on "nand-flash". > > > > > > What's wrong with the already well-established generic name "flash"? > > > > I was concerned that using "flash" for both NOR flash (which it > > already is) and NAND flash might be unwise. I am quite open to being > > convinced otherwise, though. > > One argument for just using "flash" is that there are much finer differences > than just "NAND" and "NOR", with at least "dataflash", "OneNAND", "SD/MMC" > being further types of flash that don't fit the categories exactly, though > each one for different reasons. > > For SD/MMC, there are good reasons to use something completely different, > for the others, calling them all "flash" sounds better than fitting them > into "nand" and "nor". Ok, I'm convinced. "flash" it is. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.
On Tuesday 11 March 2008, David Gibson wrote: > On Fri, Mar 07, 2008 at 04:39:30AM +0100, Segher Boessenkool wrote: > > > This isn't a problem with this device tree, but it's probably time we > > > started establishing some conventional generic names for nand flash > > > and board-control devices. > > > > > > So, to start the ball rolling, I've seen several names for nand flash > > > nodes, I'd suggest we standardise on "nand-flash". > > > > What's wrong with the already well-established generic name "flash"? > > I was concerned that using "flash" for both NOR flash (which it > already is) and NAND flash might be unwise. I am quite open to being > convinced otherwise, though. One argument for just using "flash" is that there are much finer differences than just "NAND" and "NOR", with at least "dataflash", "OneNAND", "SD/MMC" being further types of flash that don't fit the categories exactly, though each one for different reasons. For SD/MMC, there are good reasons to use something completely different, for the others, calling them all "flash" sounds better than fitting them into "nand" and "nor". Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.
On Fri, Mar 07, 2008 at 04:39:30AM +0100, Segher Boessenkool wrote: > > This isn't a problem with this device tree, but it's probably time we > > started establishing some conventional generic names for nand flash > > and board-control devices. > > > > So, to start the ball rolling, I've seen several names for nand flash > > nodes, I'd suggest we standardise on "nand-flash". > > What's wrong with the already well-established generic name "flash"? I was concerned that using "flash" for both NOR flash (which it already is) and NAND flash might be unwise. I am quite open to being convinced otherwise, though. > > I've seen several variants for board control devices (cpld, bcsr, > > fpga, etc.) I suggest we standardise on "board-control" > > Fine with me, but it's very vague (hard to avoid though). Yes. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.
On Fri, Mar 07, 2008 at 08:35:39AM -0600, Kumar Gala wrote: > On Mar 6, 2008, at 6:27 PM, David Gibson wrote: [snip] > > I've seen several variants for board control devices (cpld, bcsr, > > fpga, etc.) I suggest we standardise on "board-control" > > I don't see any reason for this. If I have a cpld or fpga why not > just call it that. I don't see what calling it 'board-control' gets > us. There may be non-board control functionality in an fpga than what > do we call it? Exactly! The device tree is supposed to describe the hardware from a functional perspective, so the fact that something is implemented in an fpga or cpld is irrelevant, what matters is what's inside the fpga. If an fpga was used to implement an ethernet MAC, we'd call if "ethernet", if something else, something else. If it was designed to be programmed at runtime by the OS, then we'd probably call it "fpga", but otherwise it should be named for what's inside it. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.
>> I've seen several variants for board control devices (cpld, bcsr, >> fpga, etc.) I suggest we standardise on "board-control" > > I don't see any reason for this. If I have a cpld or fpga why not > just call it that. I don't see what calling it 'board-control' gets > us. There may be non-board control functionality in an fpga than what > do we call it? Good point. Also, it is important to keep in mind that the "name" is meant for human consumption only, so while it is important to use some consistent naming (to not confuse the user), there should be quite some leeway here. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.
On Mar 6, 2008, at 4:42 AM, Li Yang wrote: > Signed-off-by: Li Yang <[EMAIL PROTECTED]> > --- > arch/powerpc/boot/dts/mpc8377_mds.dts | 66 > + > arch/powerpc/boot/dts/mpc8378_mds.dts | 66 > + > arch/powerpc/boot/dts/mpc8379_mds.dts | 66 > + > arch/powerpc/platforms/83xx/mpc837x_mds.c |8 +-- > 4 files changed, 201 insertions(+), 5 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.
On Mar 6, 2008, at 6:27 PM, David Gibson wrote:
> [snip]
>> +[EMAIL PROTECTED],0 {
>> +reg = <1 0x0 0x8000>;
>> +compatible = "fsl,mpc837xmds-bcsr";
>> +};
>> +
>> +[EMAIL PROTECTED],0 {
>
> This isn't a problem with this device tree, but it's probably time we
> started establishing some conventional generic names for nand flash
> and board-control devices.
>
> So, to start the ball rolling, I've seen several names for nand flash
> nodes, I'd suggest we standardise on "nand-flash".
This seems reasonable.
> I've seen several variants for board control devices (cpld, bcsr,
> fpga, etc.) I suggest we standardise on "board-control"
I don't see any reason for this. If I have a cpld or fpga why not
just call it that. I don't see what calling it 'board-control' gets
us. There may be non-board control functionality in an fpga than what
do we call it?
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.
> This isn't a problem with this device tree, but it's probably time we > started establishing some conventional generic names for nand flash > and board-control devices. > > So, to start the ball rolling, I've seen several names for nand flash > nodes, I'd suggest we standardise on "nand-flash". What's wrong with the already well-established generic name "flash"? > I've seen several variants for board control devices (cpld, bcsr, > fpga, etc.) I suggest we standardise on "board-control" Fine with me, but it's very vague (hard to avoid though). Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.
[snip]
> + [EMAIL PROTECTED],0 {
> + reg = <1 0x0 0x8000>;
> + compatible = "fsl,mpc837xmds-bcsr";
> + };
> +
> + [EMAIL PROTECTED],0 {
This isn't a problem with this device tree, but it's probably time we
started establishing some conventional generic names for nand flash
and board-control devices.
So, to start the ball rolling, I've seen several names for nand flash
nodes, I'd suggest we standardise on "nand-flash".
I've seen several variants for board control devices (cpld, bcsr,
fpga, etc.) I suggest we standardise on "board-control"
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
