On Mon, Apr 28, 2008 at 3:37 PM, Sean MacLennan <[EMAIL PROTECTED]> wrote: > On Mon, 28 Apr 2008 13:56:11 -0600 > > "Grant Likely" <[EMAIL PROTECTED]> wrote: > > > > > > You need to add the gpio-controller and #gpio-cells properties to the > > GPIO nodes for the LED's gpios property to work correctly. Search for > > "2) gpio-controller nodes" in > > Documentation/powerpc/booting-without-of.txt for details. #gpio-cells > > should probably be '2' for this gpio controller; 1 cell for the gpio > > pin and 1 cell for flags. > > I believe these gpio nodes predate that text, but I added the fields > anyway. > > > > > > These should not be children of the soc node (they are not part of the > > SoC internal bus). However, I think it would be perfectly valid to > > make them children of the gpio node since they don't have any > > connections to other device on the platform. > > I put them in gpio. That was where I put them initialy. > > > > Why is this information in the dts *and* the platform file? I haven't > > been following the flash partition map binding conventions, but having > > it in both places looks wrong.... > > > > oh, wait... the one in the dts is for NOR and this one is for NAND, > > right? And we don't have a binding yet for NAND partitions yet, > > correct? > > Correct. Josh originally asked me to split out the warp-nand.c file so > that once the NAND is in the dts, we can just delete the file. NAND is > much more complicated that NOR to configure. > > > > When exporting symbols for platform code you should avoid polluting > > the global Linux namespace and prefix the functions with your platform > > name. > > I was hoping dtm was good enough. I prefixed them with the company name. > We are expecting to have a "family" of Asterisk appliances and I am > trying to make educated guesses as to what will be family wide > (prefixed with pika) and what will be warp specific.
Its just kernel code; it can be changed easily at later date. When the company has *2* boards supported mainline in the kernel, then make it generic. :-P My experience is that educated guesses in this context are almost always wrong (ie. the API won't be what you think it should be now). Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
