linux-kernel - Re: [PATCH 6/6] spi: octeon: Add thunderx 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]

Date:	Wed, 27 Jul 2016 20:08:55 +0100
From:	Mark Brown <broonie@...nel.org>
To:	David Daney <ddaney@...iumnetworks.com>
Cc:	Jan Glauber <jan.glauber@...iumnetworks.com>,
	linux-kernel@...r.kernel.org, linux-spi@...r.kernel.org,
	"Steven J. Hill" <steven.hill@...ium.com>,
	David Daney <david.daney@...ium.com>
Subject: Re: [PATCH 6/6] spi: octeon: Add thunderx driver

On Wed, Jul 27, 2016 at 11:25:10AM -0700, David Daney wrote:
> On 07/27/2016 11:12 AM, Mark Brown wrote:
> > On Mon, Jul 25, 2016 at 09:31:15AM -0700, David Daney wrote:

> > > ARCH_THUNDER needs to die, so perhaps it should be (ARM64 || COMPILE_TEST)
> > > && PCI && 64BIT if you really want to hide it from non-arm64 kernel configs.

> > It does?  Why?

> It adds clutter.  If we build a generic kernel, we first must select all the
> ARCH_*, then go back and select the devices we want.  Not much of a value
> add.

The value comes when moving to a new kernel version and updating your
config or doing a new board - if you're building for a specific system
then you get fewer new driver prompts (especially if you've got a
smaller number of hotpluggable buses enabled).  This is the much more
common case for people doing kernel configuration, it did bother people
a lot in the past.

> Better to just directly select the devices and remove this middle ARCH_*
> layer.

It's one option every time a new vendor appears rather than every time a
new driver appears - it's a useful quality of life improvement for
people who are doing system customization that is fairly painless for
those doing generic kernels (who can just enable everything).

> Also who is responsible for making sure the proper ARCH_* constraints are
> maintained?  If we remove ARCH_THUNDER, no need to worry about this.

People using the devices or writing drivers...  this really isn't
particularly challenging and it's not like it's hard to fix if people
notice issues.

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