On Oct 15, 2013, at 8:16 AM, Gerhard Sittig wrote: > On Mon, Oct 14, 2013 at 13:09 -0700, Greg Kroah-Hartman wrote: >> >> On Mon, Oct 14, 2013 at 02:40:44PM -0500, Kumar Gala wrote: >>> >>> Greg, >>> >>> Wondering your thoughts on drivers/qe vs something like >>> drivers/soc/fsl/qe. The QuiccEngine (qe) is a communication core on >>> some of the Freescale networking SoCs that provides the ability to do >>> various networking/communication functionality. "Channels" on the QE >>> can be used for various different things from ethernet, ATM, UART, or >>> other functions. >> >> What makes the code "QE" specific? Are these devices that live on the >> QE "bus", or are they controlling the QE controller? > > You may think of the QUICC as a "programmable bitbang machine" if > you like. The very same component runs arbitrary and rather > different protocols depending on how you setup its parameters. > > There have been serial controllers capable of different protocols > like UART or SPI or I2S, but all of them are "serial > communication". There have been memory controllers which could > bitbang different protocols (NAND, NOR/SRAM, DRAM), but all of > them are "memory". > > The QUICC is just a little more versatile, and appears to cover > cases which reside in different Linux kernel subsystems (like: > it's neither serial nor network exclusively, but can be either > and potentially more). > > IIUC the question which Kumar Gala was asking is where to put > code for the component which is neither a strict subset of any > subsystem. Please correct me if I'm wrong.
Thanks for the description. Yeah, the actual ethernet, usb, serial drivers that exist with QE live today in proper drivers/ dirs. This is the infrastructure that those drivers utilize that isn't quite related to an existing subsystem. Mostly set up of channel state/cfg/etc. - k _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
