- 07 Jul, 2005 3 commits
-
-
Dave Airlie authored
The conversion to core/driver got this check in-correct. Signed-off-by:Dave Airlie <airlied@linux.ie>
-
Linus Torvalds authored
-
-
- 06 Jul, 2005 37 commits
-
-
Ivan Kokshaysky authored
There is a slight disagreement between setup-bus.c code and traditional x86 PCI setup wrt which recourses are invalid vs resources that are free for further allocations. In particular, in the setup-bus.c, if we failed to allocate some resource, we nullify "start" and "flags" fields, but *not* the "end" one. But x86 pcibios_enable_resources() does the following check: if (!r->start && r->end) { printk(KERN_ERR "PCI: Device %s not available because of resource collisions\n", pci_name(dev)); return -EINVAL; which means that the device owning the offending resource cannot be enabled. In particular, this breaks cardbus behind the normal decode p2p bridge - the cardbus code from setup-bus.c requests rather large IO and MEM windows, and if it fails, the socket is completely unavailable. Which is wrong, as the yenta code is capable to allocate smaller windows. Signed-off-by:Ivan Kokshaysky <ink@jurassic.park.msu.ru> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Eddie C. Dost authored
Call ebus_dma_enable() before calling ebus_dma_request(), otherwise ebus_dma_request() returns -EINVAL and enable_dma() calls BUG()... Signed-off-by:David S. Miller <davem@davemloft.net>
-
Eddie C. Dost authored
Signed-off-by: -
Eddie C. Dost authored
Do not cat bucket->irq_info to struct irqaction * directly, but go through struct irq_desc *. Signed-off-by: -
Linus Torvalds authored
-
Eddie C. Dost authored
Signed-off-by: -
Deepak Saxena authored
Patch from Deepak Saxena This patch implements the iomap API for Intel IXP4xx NPU systems. We need to implement our own version of the API functions b/c of the PCI hostbridge does not provide the capability to map PCI I/O space into the CPU's physical memory space. In addition, if a system has more than 64M of PCI memory mapped BARs, PCI memory must also be accessed indirectly. This patch changes the assignment of PCI I/O resources to fall into to 0x0000:0xffff range so that we can trap I/O areas in our ioread/iowrite macros. Signed-off-by: Deepak Saxena Signed-off-by:Russell King <rmk+kernel@arm.linux.org.uk>
-
Todd Poynor authored
Patch from Todd Poynor Fix module versioning for 3 ARM symbols that do not have CRCs added, avoid "disagrees about version of symbol struct_module" errors at module load time. From David Singleton. Signed-off-by:
Todd Poynor <tpoynor@mvista.com> Signed-off-by:
-
Stefan Sorensen authored
coyote Patch from Stefan Sorensen On the ixdp425 and coyote platforms, the plat_serial8250_port arrays are missing the terminating entry required by serial8250_probe. Signed-off-by:
Stefan Sorensen <ssoe@kirktelecom.com> Signed-off-by:
-
Catalin Marinas authored
Patch from Catalin Marinas The VFP instructions trigger undefined exceptions because the access to CP11 is disabled (only CP10 is currently enabled by the kernel). The patch fixes this problem. Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Dag Arne Osvik authored
I've made a new implementation of DES to replace the old one in the kernel. It provides faster encryption on all tested processors apart from the original Pentium, and key setup is many times faster. Speed relative to old kernel implementation Processor des_setkey des_encrypt des3_ede_setkey des3_ede_encrypt Pentium 120Mhz 6.8 0.82 7.2 0.86 Pentium III 1.266Ghz 5.6 1.19 5.8 1.34 Pentium M 1.3Ghz 5.7 1.15 6.0 1.31 Pentium 4 2.266Ghz 5.8 1.24 6.0 1.40 Pentium 4E 3Ghz 5.4 1.27 5.5 1.48 StrongARM 1110 206Mhz 4.3 1.03 4.4 1.14 Athlon XP 2Ghz 7.8 1.44 8.1 1.61 Athlon 64 2Ghz 7.8 1.34 8.3 1.49 Signed-off-by:Dag Arne Osvik <da@osvik.no> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Herbert Xu authored
The iv field in des_ctx/des3_ede_ctx/serpent_ctx has never been used. This was noticed by Dag Arne Osvik. Signed-off-by:
-
Andreas Steinmetz authored
Implementation: =============== The encrypt/decrypt code is based on an x86 implementation I did a while ago which I never published. This unpublished implementation does include an assembler based key schedule and precomputed tables. For simplicity and best acceptance, however, I took Gladman's in-kernel code for table generation and key schedule for the kernel port of my assembler code and modified this code to produce the key schedule as required by my assembler implementation. File locations and Kconfig are kept similar to the i586 AES assembler implementation. It may seem a little bit strange to use 32 bit I/O and registers in the assembler implementation but this gives the best code size. My implementation takes one instruction more per round compared to Gladman's x86 assembler but it doesn't require any stack for local variables or saved registers and it is less serialized than Gladman's code. Note that all comparisons to Gladman's code were done after my code was implemented. I did only use FIPS PUB 197 for the implementation so my implementation is independent work. If anybody has a better assembler solution for x86_64 I'll be pleased to have my code replaced with the better solution. Testing: ======== The implementation passes the in-kernel crypto testing module and I'm running it without any problems on my laptop where it is mainly used for dm-crypt. Microbenchmark: =============== The microbenchmark was done in userspace with similar compile flags as used during kernel compile. Encrypt/decrypt is about 35% faster than the generic C implementation. As the generic C as well as my assembler implementation are both table I don't really expect that there is much room for further improvements though I'll be glad to be corrected here. The key schedule is about 5% slower than the generic C implementation. This is due to the fact that some more work has to be done in the key schedule routine to fit the schedule to the assembler implementation. Code Size: ========== Encrypt and decrypt are together about 2.1 Kbytes smaller than the generic C implementation which is important with regard to L1 cache usage. The key schedule routine is about 100 bytes larger than the generic C implementation. Data Size: ========== There's no difference in data size requirements between the assembler implementation and the generic C implementation. License: ======== Gladmans's code is dual BSD/GPL whereas my assembler code is GPLv2 only (I'm not going to change the license for my code). So I had to change the module license for the x86_64 aes module from 'Dual BSD/GPL' to 'GPL' to reflect the most restrictive license within the module. Signed-off-by:
Andreas Steinmetz <ast@domdv.de> Signed-off-by:
-
Jesper Juhl authored
As far as I'm aware there's a general concensus that functions that are responsible for freeing resources should be able to cope with being passed a NULL pointer. This makes sense as it removes the need for all callers to check for NULL, thus elliminating the bugs that happen when some forget (safer to just check centrally in the freeing function) and it also makes for smaller code all over due to the lack of all those NULL checks. This patch makes it safe to pass the crypto_free_tfm() function a NULL pointer. Once this patch is applied we can start removing the NULL checks from the callers. Signed-off-by:
Jesper Juhl <juhl-lkml@dif.dk> Signed-off-by:
-
Herbert Xu authored
When the Padlock does CBC encryption, the memory pointed to by EAX is not updated at all. Instead, it updates the value of EAX by pointing it to the last block in the output. Therefore to maintain the correct semantics we need to copy the IV. Signed-off-by:
-
Herbert Xu authored
Even though cit_iv is now always aligned, the user can still supply an unaligned iv through crypto_cipher_encrypt_iv/crypto_cipher_decrypt_iv. This patch will check the alignment of the user-supplied iv and copy it if necessary. Signed-off-by:
-
Herbert Xu authored
This patch ensures that cit_iv is aligned according to cra_alignmask by allocating it as part of the tfm structure. As a side effect the crypto layer will also guarantee that the tfm ctx area has enough space to be aligned by cra_alignmask. This allows us to remove the extra space reservation from the Padlock driver. Signed-off-by:
-
Adrian Bunk authored
This patch makes a needlessly global function static. Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
Herbert Xu authored
By operating on multiple blocks at once, we expect to extract more performance out of the VIA Padlock. Signed-off-by:
-
Herbert Xu authored
Most of the work done aes_padlock can be done in aes_set_key. This means that we only have to do it once when the key changes rather than every time we perform an encryption or decryption. This patch also sets cra_alignmask to let the upper layer ensure that the buffers fed to us are aligned correctly. Signed-off-by:
-
Herbert Xu authored
The VIA Padlock device requires the input and output buffers to be aligned on 16-byte boundaries. This patch adds the alignmask attribute for low-level cipher implementations to indicate their alignment requirements. The mid-level crypt() function will copy the input/output buffers if they are not aligned correctly before they are passed to the low-level implementation. Strictly speaking, some of the software implementations require the buffers to be aligned on 4-byte boundaries as they do 32-bit loads. However, it is not clear whether it is better to copy the buffers or pay the penalty for unaligned loads/stores. Signed-off-by:
-
Herbert Xu authored
This patch adds hooks for cipher algorithms to implement multi-block ECB/CBC operations directly. This is expected to provide significant performance boots to the VIA Padlock. It could also be used for improving software implementations such as AES where operating on multiple blocks at a time may enable certain optimisations. Signed-off-by:
-
Herbert Xu authored
The VIA Padlock device is able to perform much better when multiple blocks are fed to it at once. As this device offers an exceptional throughput rate it is worthwhile to optimise the infrastructure specifically for it. We shift the existing page-sized fast path down to the CBC/ECB functions. We can then replace the CBC/ECB functions with functions provided by the underlying algorithm that performs the multi-block operations. As a side-effect this improves the performance of large cipher operations for all existing algorithm implementations. I've measured the gain to be around 5% for 3DES and 15% for AES. Signed-off-by:
-
Jesper Juhl authored
Checking a pointer for NULL before calling kfree() on it is redundant. This patch removes such checks from crypto/ Signed-off-by:
-
Linus Torvalds authored
"ack_code" is assigned (and tested against) negative numbers, but was declared as "char". Which only works if "char" is signed - which it necessarily isn't. So make that signedness assumption specific.
-
Jeff Mahoney authored
This adds the hotplug routine for generating hotplug events when devices are seen on the macio bus. It uses the attributed created by the sysfs nodes to generate the hotplug environment vars for userspace. Since the characters allowed inside the 'compatible' field are NUL terminated, they are exported as individual OF_COMPATIBLE_# variables, with OF_COMPATIBLE_N maintaining a count of how many there are. In order for hotplug to work with macio devices, patches to module-init-tools and hotplug must be applied. Those patches are available at: ftp://ftp.suse.com/pub/people/jeffm/linux/macio-hotplug/Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Signed-off-by:
-
Jeff Mahoney authored
This adds sysfs nodes that the hotplug userspace can use to load the appropriate modules. In order for hotplug to work with macio devices, patches to module-init-tools and hotplug must be applied. Those patches are available at: ftp://ftp.suse.com/pub/people/jeffm/linux/macio-hotplug/ Changes: The previous versions were built on 2.6.12. 2.6.13-rcX introduced a device_attribute parameter to the show functions. Since that parameter was treated as the output buffer, memory corruption would result, causing Oopsen very quickly. Signed-off-by:
-
Jeff Mahoney authored
This converts the usage of struct of_match to struct of_device_id, similar to pci_device_id. This allows a device table to be generated, which can be parsed by depmod(8) to generate a map file for module loading. In order for hotplug to work with macio devices, patches to module-init-tools and hotplug must be applied. Those patches are available at: ftp://ftp.suse.com/pub/people/jeffm/linux/macio-hotplug/Signed-off-by:
-
Dave Jones authored
Just the declaration fix wasn't enough to fix things in bt78x.c Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Christoph Lameter authored
This patch used to be in Andrew's tree before the NUMA slab allocator went in. Either this patch or the NUMA slab allocator is needed in order for kmalloc_node to work correctly. pcibus_to_node may be used to generate the node information passed to kmalloc_node. pcibus_to_node returns -1 if it was not able to determine on which node a pcibus is located. For that case kmalloc_node must work like kmalloc. Signed-off-by:
Christoph Lameter <christoph@lameter.com> Signed-off-by:
-
Greg KH authored
Missing forward declaration Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
-
Greg KH authored
Here's a patch to fix the build issue when CONFIG_HOTPLUG is not enabled in 2.6.13-rc2. Signed-off-by:
-
Linus Torvalds authored
-
Linus Torvalds authored
-
David S. Miller authored
The membar changes made the size of __cheetah_flush_tlb_pending grow by one instruction, but the boot-time code patching was not updated to match. Signed-off-by: -
Rusty Lynch authored
The following renames arch_init, a kprobes function for performing any architecture specific initialization, to arch_init_kprobes in order to cleanup the namespace. Also, this patch adds arch_init_kprobes to sparc64 to fix the sparc64 kprobes build from the last return probe patch. Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Eugene Surovegin authored
Add explicit disabling of 440GP IRQ compatibility mode when configuring 440GX interrupt controller. This helps when board firmware for some reason uses this compatibility mode and leaves it enabled. It breaks 440GX interrupt code because it assumes native 440GX IRQ mode. People seems to be continuously bitten by this. Signed-off-by:
Eugene Surovegin <ebs@ebshome.net> Signed-off-by:
-
