> -----Original Message----- > From: Kumar Gala [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 18, 2006 9:53 PM > To: Li Yang-r58472 > Cc: Dan Malek; [EMAIL PROTECTED]; linux-usb-devel@lists.sourceforge.net > Subject: Re: [PATCH] Add USB to MPC8349 PB platform support > > [snip] > > >> Well, I think there is a coupling that exists between whatever your > >> boot rom is and the kernel. If you are trying to optimize boot time > >> I'd say one thing you would want is to avoid multiple writing the > >> same configuration registers. > >> > >> I dont have an issue if a fixed function board decides to do these > >> things in their kernel init instead of their boot rom. I however, > >> don't want thousand and one config options to support all the various > >> ways one can configure the Freescale board. > > > > We won't have the thousand and one config options, making use of the > > device > > tree. So this is not a problem. > > I'm talking about opening the door to a ton of options, not that we > have them now. For example, your patch doesnt handle the USB PHYs if > they are on the MDS instead of the SYS board. It doesn't handle > setting SCCR properly for different frequency choices. I'm concerned > about where to draw the line because of all the ways a user can > configure the MDS board.
My understanding is that in embedded world only this kind of versatile development boards needs to have Linux port in mainstream kernel. A fixed function customer board used in embedded product will never get into kernel source. The reasons for Freescale to provide this kind of boards are: first, verify functions on chip; second, demonstrate chip functions to customer; third, validate customer application on reference board; forth, help customer to build their own product by cutting down the board and software. Doing that, we do need some configure options to demonstrate main functions. But there won't be too many options to confuse the user. Only key working modes are needed. In your example, I think making USB PHYs configurable for MDS is reasonable, but for SCCR it isn't as it is well commented in code and is not likely to be modified. Keep in mind that our only purpose is making customers easier and faster in developing their own products. > > - kumar ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel