linux-kernel - Re: [PATCH 03/11] soc/fsl: Introduce the DPAA BMan portal driver

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]

Message-ID: <1436546836.20619.231.camel@tiscali.nl>
Date:	Fri, 10 Jul 2015 18:47:16 +0200
From:	Paul Bolle <pebolle@...cali.nl>
To:	Roy Pledge <roy.pledge@...escale.com>
Cc:	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	Scott Wood <scottwood@...escale.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 03/11] soc/fsl: Introduce the DPAA BMan portal driver

Hi Roy,

On vr, 2015-07-10 at 15:19 +0000, Roy Pledge wrote:
> Thanks you for your valuable feedback so far.

You're welcome. Please note that I just scan for, well, common build
issues. Ie, stuff that requires no domain specific knowledge.

> Let me try to address a general issue you mention below: unused 
> exported APIs.

Good timing. I was pondering how to handle 04/11, a big patch that
exports 79 (!) symbols. Many of those appear to have no users.

> The QMan and BMan drivers provide a base layer for other blocks built 
> on top of them, for instance an Ethernet Driver, an Encrypt/Decrypt 
> Engine,  a pattern matcher, a compress/decompress engine, etc...
> Some of these drivers will be presented for review in the near future, 
> but in order to try and layer the review/up streaming process we're 
> presenting each layer as independently as possible.
> If you really were to start dissecting which APIs are called you would 
> come to a very small set of pieces that merely initialize the hardware 
> but don't provide any opportunity for other users to invoke that HW. 
> 
> I hope that this helps you understand our goals in trying to upstream 
> these drivers.

At the end of the day, what matters is what the people that need to sign
off on these drivers (ppc? netdev?) are comfortable with. I know that
some maintainers won't even bother looking at code that has no callers.

In the mean time I'll skip the exports for the remainder of this series.

Thanks,


Paul Bolle
--
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/