netdev - Re: [PATCH v2] net: cadence: Add architecture dependencies

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 23 Apr 2014 12:27:35 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Jean Delvare <jdelvare@...e.de>
Cc:	monstr@...str.eu, netdev@...r.kernel.org,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robh+dt@...nel.org>
Subject: Re: [PATCH v2] net: cadence: Add architecture dependencies

On Wed, Apr 23, 2014 at 12:48:38PM +0200, Jean Delvare wrote:
> On Wed, 23 Apr 2014 11:35:55 +0200, Michal Simek wrote:
> > On 04/23/2014 09:40 AM, Jean Delvare wrote:

> > > Thanks for the information. I will send a patch adding MICROBLAZE to
> > > the dependencies. Out of curiosity, is there any way I could have found
> > > out by myself?

> > Microblaze doesn't need to be only one. I am not sure if there is
> > any AXI bridge for openrisc.

> You lost me here again :-(

AXI is a bus commonly used inside ICs, it's one of a series of buses of
varying complexity commonly used to integrate IPs into chips.  Michal is
wondering if there is anything available to interface an AXI bus to an
OpenRISC processor.

> > IMHO you should just add COMPILE_TEST and do not try to extend that
> > list of dependencies.

> COMPILE_TEST is already present, I can't add it twice ;-) But
> COMPILE_TEST isn't supposed to be used when the architecture /
> platform / system is actually expected to possibly need the driver in
> question. If the list of possible hardware dependencies isn't well
> known, or is too complex to express, or too difficult to maintain, then
> we have to either make it broader, or even drop it.

Like I said in my original reply for things like this that are clearly
generic IPs not tied to a particular chip vendor I think we ought to at
least create a symbol they can depend on which can be selected by the
architectures that are commonly deployed with FPGAs (or just in custom
silicon like ARM).  That will cover most of the uses I expect.

For some of these IPs there will also be additional places where they
could appear (eg, if something gets put on a PCI card) but they should
be much less common.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)