On 7/31/08, David Gibson <[EMAIL PROTECTED]> wrote: > On Thu, Jul 31, 2008 at 04:58:34PM -0400, Jon Smirl wrote: > > On 7/31/08, Grant Likely <[EMAIL PROTECTED]> wrote: > > > On Thu, Jul 31, 2008 at 04:49:49PM -0400, Jon Smirl wrote: > > > > On 7/31/08, Grant Likely <[EMAIL PROTECTED]> wrote: > > > > > This topic keeps coming up, so it is probably time to address it > once > > > > > and for all. > > > > > > > > > > When it comes to machine level support in arch/powerpc, there > seems to > > > > > me that there are two levels or machine support. > > > > > > > > > ...... > > > > > > > > > > Thoughts? > > > > > g. > > > > > > > > > > > > As part of this, how can we going to solve the problem with triggering > > > > the load of a board specific machine/fabric driver in a generic way? > > > > > > > > > That really is a separate problem. We *could* do this with a board > > > specific powerpc machine driver, but I don't think it is the best > > > solution. > > > > > > I'm still thinking that the drivers module_init() function could check > > > the top level board model property and decide whether or not to load > > > based on that. > > > > You're assuming the driver is compiled in. > > > > If the drivers are on initrd selection has to happen via the normal > > device/driver matching process. Search for a device in the alias table > > of the drive file. > > > This can still be done via the board platform code. The platform code > creates a platform device which the driver can later bind to.
That is what I'm doing now. But it requires every board to add a file to arch/powerpc/platforms. Can we have some common code to make the fabric device? Can it be an OF device instead of a platform one? An OF device could be compatible with boardname-fabric, generic-fabric. That allows a stub fabric driver to always bind. > > > > -- > 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 > -- Jon Smirl [EMAIL PROTECTED] _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
