linux-kernel - Re: [PATCH] powerpc/qe_lib: Share the qe

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <385E3F55-85BB-4E28-A396-FA54DEE1B1AB@kernel.crashing.org>
Date:	Wed, 16 Oct 2013 13:12:59 -0500
From:	Kumar Gala <galak@...nel.crashing.org>
To:	Gerhard Sittig <gsi@...x.de>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Scott Wood <scottwood@...escale.com>,
	"linuxppc-dev@...ts.ozlabs.org list" <linuxppc-dev@...ts.ozlabs.org>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Xie Xiaobo <X.Xie@...escale.com>
Subject: Re: [PATCH] powerpc/qe_lib: Share the qe_lib for the others architecture


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--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/