<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/arch/sparc/crypto/crop_devid.c, branch dev</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2012-09-15T16:46:25+00:00</updated>
<entry>
<title>sparc64: Add auto-loading mechanism to crypto-opcode drivers.</title>
<updated>2012-09-15T16:46:25+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2012-09-15T16:46:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=979e93ca24e8336acb660529676dcda6817d8a1f'/>
<id>urn:sha1:979e93ca24e8336acb660529676dcda6817d8a1f</id>
<content type='text'>
Just simply provide a device table containing an entry for sun4v cpus,
the capability mask checks in the drivers themselves will take care of
the rest.

This makes the bootup logs on pre-T4 cpus slightly more verbose, with
each driver indicating lack of support for the associated opcode(s).

But this isn't too much of a real problem.

I toyed with the idea of using explicit entries with compatability
fields of "SPARC-T4", "SPARC-T5", etc. but all future cpus will have
some subset of these opcodes available and this would just be one more
pointless thing to do as each new cpu is released with a new string.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
