linux-kernel - Re: [PATCH V5 1/6] SLIMbus: Device management on SLIMbus

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:	Thu, 28 Apr 2016 18:49:23 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Mark Brown <broonie@...nel.org>
Cc:	Sagar Dharia <sdharia@...eaurora.org>, gregkh@...uxfoundation.org,
	bp@...e.de, poeschel@...onage.de, treding@...dia.com,
	gong.chen@...ux.intel.com, andreas.noever@...il.com,
	alan@...ux.intel.com, mathieu.poirier@...aro.org, daniel@...ll.ch,
	jkosina@...e.cz, sharon.dvir1@...l.huji.ac.il, joe@...ches.com,
	davem@...emloft.net, james.hogan@...tec.com,
	michael.opdenacker@...e-electrons.com, daniel.thompson@...aro.org,
	robh+dt@...nel.org, pawel.moll@....com, mark.rutland@....com,
	ijc+devicetree@...lion.org.uk, galak@...eaurora.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	kheitke@...ience.com, mlocke@...eaurora.org, agross@...eaurora.org,
	sheetal.tigadoli@...il.com, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH V5 1/6] SLIMbus: Device management on SLIMbus

On Thursday 28 April 2016 17:39:20 Mark Brown wrote:
> > I don't think we have merge new platform support on any
> > architecture that would need this in the past years and
> > stuff like spi_board_info and i2c_board_info is only really
> > used on really old machines (but not going away any time soon
> > either).
> 
> It's not just platforms that use these things though - there's things
> like the SolarFlare NICs where the firmware update mechanism essentially
> involves exposing a SPI flash as part of a PCI device and we just merged
> an ASoC driver for a video card which was reusing some existing IPs and
> chips.
> 

That's of course fine: you essentially have a discoverable bus there,
and if we need something like that, we can always add it later to
any subsystem.

In contrast, the interface in the proposed slimbus subsystem seems
designed for board files, and is in the best case just dead code
that can be removed, or has a risk of being misused e.g. if some
device manufacturer decides to use a board file for this instead
of describing the slimbus slaves in DT.

	Arnd