summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* m68knommu: make 528x FEC platform addressing consistentGreg Ungerer2012-03-052-10/+17
| | | | | | | | | | | | | | If we make all FEC (ethernet) addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 528x FEC addressing so that: . FECs are numbered from 0 up . base addresses are absolute (not relative to MBAR peripheral register) . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: make 527x FEC platform addressing consistentGreg Ungerer2012-03-052-12/+27
| | | | | | | | | | | | | | If we make all FEC (ethernet) addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 527x FEC addressing so that: . FECs are numbered from 0 up . base addresses are absolute (not relative to MBAR peripheral register) . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: make 5272 FEC platform addressing consistentGreg Ungerer2012-03-052-11/+14
| | | | | | | | | | | | | | If we make all FEC (ethernet) addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 5272 FEC addressing so that: . FECs are numbered from 0 up . base addresses are absolute (not relative to MBAR peripheral register) . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: make 523x FEC platform addressing consistentGreg Ungerer2012-03-052-11/+18
| | | | | | | | | | | | | | If we make all FEC (ethernet) addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 523x FEC addressing so that: . FECs are numbered from 0 up . base addresses are absolute (not relative to MBAR peripheral register) . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: make 520x FEC platform addressing consistentGreg Ungerer2012-03-052-10/+17
| | | | | | | | | | | | | | If we make all FEC (ethernet) addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 520x FEC addressing so that: . FECs are numbered from 0 up . base addresses are absolute (not relative to MBAR peripheral register) . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: merge common ColdFire UART IRQ setupGreg Ungerer2012-03-056-69/+24
| | | | | | | | Some ColdFire CPU UART hardware modules can configure the IRQ they use. Currently the same setup code is duplicated in the init code for each of these ColdFire CPUs. Merge all this code to a single instance. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: merge common ColdFire UART platform setup codeGreg Ungerer2012-03-0513-299/+61
| | | | | | | | The ColdFire UART is common to all ColdFire CPU's. No need to duplicate its platform setup code for every CPU family member. Merge all the setup code into a single shared file. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: simplify the 54xx UART setup codeGreg Ungerer2012-03-051-24/+9
| | | | | | | | | Simplify the UART setup code so that it no longer loops for each UART present. Just make it do all the work it needs in a single function. This will make the code easier to share when we move to a single set of platform data for ColdFire UARTs. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: simplify the 5407 UART setup codeGreg Ungerer2012-03-051-18/+9
| | | | | | | | | Simplify the UART setup code so that it no longer loops for each UART present. Just make it do all the work it needs in a single function. This will make the code easier to share when we move to a single set of platform data for ColdFire UARTs. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: simplify the 532x UART setup codeGreg Ungerer2012-03-051-16/+3
| | | | | | | | | Simplify the UART setup code so that it no longer loops for each UART present. Just make it do all the work it needs in a single function. This will make the code easier to share when we move to a single set of platform data for ColdFire UARTs. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: simplify the 5307 UART setup codeGreg Ungerer2012-03-051-18/+9
| | | | | | | | | Simplify the UART setup code so that it no longer loops for each UART present. Just make it do all the work it needs in a single function. This will make the code easier to share when we move to a single set of platform data for ColdFire UARTs. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: simplify the 528x UART setup codeGreg Ungerer2012-03-051-18/+4
| | | | | | | | | Simplify the UART setup code so that it no longer loops for each UART present. Just make it do all the work it needs in a single function. This will make the code easier to share when we move to a single set of platform data for ColdFire UARTs. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: simplify the 527x UART setup codeGreg Ungerer2012-03-051-19/+2
| | | | | | | | | Simplify the UART setup code so that it no longer loops for each UART present. Just make it do all the work it needs in a single function. This will make the code easier to share when we move to a single set of platform data for ColdFire UARTs. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: simplify the 5272 UART setup codeGreg Ungerer2012-03-051-19/+8
| | | | | | | | | Simplify the UART setup code so that it no longer loops for each UART present. Just make it do all the work it needs in a single function. This will make the code easier to share when we move to a single set of platform data for ColdFire UARTs. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: simplify the 5249 UART setup codeGreg Ungerer2012-03-051-18/+9
| | | | | | | | | Simplify the UART setup code so that it no longer loops for each UART present. Just make it do all the work it needs in a single function. This will make the code easier to share when we move to a single set of platform data for ColdFire UARTs. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: simplify the 520x UART setup codeGreg Ungerer2012-03-051-30/+12
| | | | | | | | | Simplify the UART setup code so that it no longer loops for each UART present. Just make it do all the work it needs in a single function. This will make the code easier to share when we move to a single set of platform data for ColdFire UARTs. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: simplify the 5206 UART setup codeGreg Ungerer2012-03-051-18/+9
| | | | | | | | | Simplify the UART setup code so that it no longer loops for each UART present. Just make it do all the work it needs in a single function. This will make the code easier to share when we move to a single set of platform data for ColdFire UARTs. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: make 54xx UART platform addressing consistentGreg Ungerer2012-03-052-14/+18
| | | | | | | | | | | | | | If we make all UART addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 54xx UART addressing so that: . UARTs are numbered from 0 up . base addresses are absolute (not relative to MBAR peripheral register) . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: make 5407 UART platform addressing consistentGreg Ungerer2012-03-052-8/+10
| | | | | | | | | | | | | | If we make all UART addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 5407 UART addressing so that: . UARTs are numbered from 0 up . base addresses are absolute (not relative to MBAR peripheral register) . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: make 532x UART platform addressing consistentGreg Ungerer2012-03-052-9/+13
| | | | | | | | | | | | | If we make all UART addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 532x UART addressing so that: . UARTs are numbered from 0 up . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: make 528x UART platform addressing consistentGreg Ungerer2012-03-052-9/+15
| | | | | | | | | | | | | If we make all UART addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 528x UART addressing so that: . UARTs are numbered from 0 up . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: make 5307 UART platform addressing consistentGreg Ungerer2012-03-052-10/+12
| | | | | | | | | | | | | | If we make all UART addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 5307 UART addressing so that: . UARTs are numbered from 0 up . base addresses are absolute (not relative to MBAR peripheral register) . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: make 527x UART platform addressing consistentGreg Ungerer2012-03-052-9/+13
| | | | | | | | | | | | | If we make all UART addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 527x UART addressing so that: . UARTs are numbered from 0 up . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: make 5272 UART platform addressing consistentGreg Ungerer2012-03-052-8/+8
| | | | | | | | | | | | | If we make all UART addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 5272 UART addressing so that: . UARTs are numbered from 0 up . base addresses are absolute (not relative to MBAR peripheral register) Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: make 5249 UART platform addressing consistentGreg Ungerer2012-03-052-8/+11
| | | | | | | | | | | | | | If we make all UART addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 5249 UART addressing so that: . UARTs are numbered from 0 up . base addresses are absolute (not relative to MBAR peripheral register) . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: make 523x UART platform addressing consistentGreg Ungerer2012-03-052-9/+15
| | | | | | | | | | | | | If we make all UART addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 523x UART addressing so that: . UARTs are numbered from 0 up . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: make 520x UART platform addressing consistentGreg Ungerer2012-03-052-9/+13
| | | | | | | | | | | | | If we make all UART addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 520x UART addressing so that: . UARTs are numbered from 0 up . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: make 5206 UART platform addressing consistentGreg Ungerer2012-03-052-10/+12
| | | | | | | | | | | | | | If we make all UART addressing consistent across all ColdFire family members then we will be able to remove the duplicated plaform data and use a single setup for all. So modify the ColdFire 5206 UART addressing so that: . UARTs are numbered from 0 up . base addresses are absolute (not relative to MBAR peripheral register) . use a common name for IRQs used Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68k: merge the MMU and non-MMU versions of process.cGreg Ungerer2012-03-053-777/+377
| | | | | | | | | | The MMU and non-MMU varients of the m68k arch process.c code are pretty much the same. Only a few minor details differ between the two. The majority of the difference is to deal with having or wanting hardware FPU support. So merge them back into a single process.c file. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
* m68k: make support for FPU hardware configurableGreg Ungerer2012-03-051-0/+4
| | | | | | | | | | | | | | | The classic m68k code has always supported an FPU (although it may have been a software emulated one). The non-MMU m68k code has never supported FPU hardware. To help in merging common code create a configation setting that signifies if we are builing in FPU support or not. This switch, CONFIG_FPU, is set as per the current use cases. So it is always enabled if CONFIG_MMU is set, and disabled otherwise. With a little extra code it will be possible to disable it on the classic m68k platforms as well, and to enable it on non-MMU platforms that do have hardware FPU. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
* m68k: merge the mmu and non-mmu versions of ptrace.cGreg Ungerer2012-03-053-553/+303
| | | | | | | | Most of the code in the non-mmu ptrace_no.c file is the same as the mmu version ptrace_mm.c. So merge them back into a single file. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
* m68k: remove dead timer codeGreg Ungerer2012-03-051-7/+0
| | | | | | | | The set_rtc_mmss() function is defined "static inline" but is never used in this file. Remove it. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
* m68k: merge mmu and non-mmu versions of time.cGreg Ungerer2012-03-053-190/+118
| | | | | | | | There is only trivial differences between the mmu time_mm.c and non-mmu time_no.c files. Merge them back into a single time.c. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
* m68knommu: remove unused CONFIG_GENERIC_CMOS_UPDATE optionGreg Ungerer2012-03-052-8/+0
| | | | | | | | | | | | The CONFIG_GENERIC_CMOS_UPDATE switch is always enabled for the non-MMU m68k case. But the underlying code to support it, update_persistent_clock(), doesn't end up doing anything on the currently supported non-MMU platforms. No platforms supply the necessary function support for writing back the RTC. So lets remove this option and support code. This also brings m68knommu in line with the m68k, which doesn't enabled this switch either. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: modify timer init code to make it consistent with m68k codeGreg Ungerer2012-03-0517-12/+28
| | | | | | | | | | | | | With a few small changes we can make the m68knommu timer init code the same as the m68k code. By using the mach_sched_init function pointer and reworking the current timer initializers to keep track of the common m68k timer_interrupt() handler we end up with almost identical code for m68knommu. This will allow us to more easily merge the mmu and non-mmu m68k time.c in future patches. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: make persistent clock code consistent with m68kGreg Ungerer2012-03-058-46/+35
| | | | | | | | | | | The read_persistent_clock() code is different on m68knommu, for really no reason. With a few changes to support function names and some code re-organization the code can be made the same. This will make it easier to merge the arch/m68k/kernel/time.c for m68k and m68knommu in a future patch. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: remove reduntant definitions of _ramvecGreg Ungerer2012-03-053-6/+0
| | | | | | | | The base of the real RAM resident hardware vectors, _ramvec, is declared in our asm/traps.h. No need to have local declarations spread around in other files that use this. So remove them. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: clean up linker scriptGreg Ungerer2012-03-051-151/+49
| | | | | | | | | | | There is a lot of years of collected cruft in the m68knommu linker script. Clean it all up and use the well defined linker script support macros. Support is maintained for building both ROM/FLASH based and RAM based setups. No major changes to section layouts, though the rodata section is now lumped in with the read/write data section. Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* m68knommu: hard set the ColdFire MBAR register on startupGreg Ungerer2012-03-051-0/+4
| | | | | | | | | | The ColdFire MBAR register that holds the mapping of the peripheral region on some ColdFire CPUs is configurable. It can be configured at some address different to that of the bootloader that loaded the kernel. So hard set the MBAR register mapping at kernel startup time. Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
* Linux 3.3-rc6v3.3-rc6Linus Torvalds2012-03-041-1/+1
|
* Merge tag 'scsi-fixes' of ↵Linus Torvalds2012-03-041-2/+2
|\ | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6 SCSI fixes from James Bottomley: "There's just a single fix in here: the osd max device number fix." * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6: [SCSI] osd_uld: Bump MAX_OSD_DEVICES from 64 to 1,048,576
| * [SCSI] osd_uld: Bump MAX_OSD_DEVICES from 64 to 1,048,576Boaz Harrosh2012-02-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It used to be that minors where 8 bit. But now they are actually 20 bit. So the fix is simplicity itself. I've tested with 300 devices and all user-mode utils work just fine. I have also mechanically added 10,000 to the ida (so devices are /dev/osd10000, /dev/osd10001 ...) and was able to mkfs an exofs filesystem and access osds from user-mode. All the open-osd user-mode code uses the same library to access devices through their symbolic names in /dev/osdX so I'd say it's pretty safe. (Well tested) This patch is very important because some of the systems that will be deploying the 3.2 pnfs-objects code are larger than 64 OSDs and will stop to work properly when reaching that number. CC: Stable <stable@vger.kernel.org> Signed-off-by: Boaz Harrosh <bharrosh@panasas.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
* | Merge tag 'parisc-fixes' of ↵Linus Torvalds2012-03-044-2/+8
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jejb/parisc-2.6 PARISC fixes from James Bottomley: "This is a set of build fixes to get the cross compiled architecture testbeds building again" * tag 'parisc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/parisc-2.6: [PARISC] don't unconditionally override CROSS_COMPILE for 64 bit. [PARISC] include <linux/prefetch.h> in drivers/parisc/iommu-helpers.h [PARISC] fix compile break caused by iomap: make IOPORT/PCI mapping functions conditional
| * | [PARISC] don't unconditionally override CROSS_COMPILE for 64 bit.James Bottomley2012-02-281-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | The user may wish to set their own value (for real cross compiles). Since the top level Makefile initialises CROSS_COMPILE to empty by default, we must check it for being empty (rather than for being defined) before we override. Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
| * | [PARISC] include <linux/prefetch.h> in drivers/parisc/iommu-helpers.hCong Wang2012-02-271-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | drivers/parisc/iommu-helpers.h:62: error: implicit declaration of function 'prefetchw' make[3]: *** [drivers/parisc/sba_iommu.o] Error 1 drivers/parisc/iommu-helpers.h needs to #include <linux/prefetch.h> where prefetchw is declared. Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
| * | [PARISC] fix compile break caused by iomap: make IOPORT/PCI mapping ↵James Bottomley2012-02-272-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | functions conditional The problem in commit fea80311a939a746533a6d7e7c3183729d6a3faf Author: Randy Dunlap <rdunlap@xenotime.net> Date: Sun Jul 24 11:39:14 2011 -0700 iomap: make IOPORT/PCI mapping functions conditional is that if your architecture supplies pci_iomap/pci_iounmap, it expects always to supply them. Adding empty body defitions in the !CONFIG_PCI case, which is what this patch does, breaks the parisc compile because the functions become doubly defined. It took us a while to spot this, because we don't actually build !CONFIG_PCI very often (only if someone is brave enough to test the snake/asp machines). Since the note in the commit log says this is to fix a CONFIG_GENERIC_IOMAP issue (which it does because CONFIG_GENERIC_IOMAP supplies pci_iounmap only if CONFIG_PCI is set), there should actually have been a condition upon this. This should make sure no other architecture's !CONFIG_PCI compile breaks in the same way as parisc. The fix had to be updated to take account of the GENERIC_PCI_IOMAP separation. Reported-by: Rolf Eike Beer <eike@sf-mail.de> Signed-off-by: James Bottomley <JBottomley@Parallels.com>
* | | Merge branch 'perf-urgent-for-linus' of ↵Linus Torvalds2012-03-034-4/+54
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/kvm: Fix Host-Only/Guest-Only counting with SVM disabled
| * | | perf/x86/kvm: Fix Host-Only/Guest-Only counting with SVM disabledJoerg Roedel2012-03-024-4/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It turned out that a performance counter on AMD does not count at all when the GO or HO bit is set in the control register and SVM is disabled in EFER. This patch works around this issue by masking out the HO bit in the performance counter control register when SVM is not enabled. The GO bit is not touched because it is only set when the user wants to count in guest-mode only. So when SVM is disabled the counter should not run at all and the not-counting is the intended behaviour. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Avi Kivity <avi@redhat.com> Cc: Stephane Eranian <eranian@google.com> Cc: David Ahern <dsahern@gmail.com> Cc: Gleb Natapov <gleb@redhat.com> Cc: Robert Richter <robert.richter@amd.com> Cc: stable@vger.kernel.org # v3.2 Link: http://lkml.kernel.org/r/1330523852-19566-1-git-send-email-joerg.roedel@amd.com Signed-off-by: Ingo Molnar <mingo@elte.hu>
* | | | Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Linus Torvalds2012-03-031-0/+1
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull from Herbert Xu: "This push fixes a bug in mv_cesa that causes all hash operations that supply data on a final operation to fail." * git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: mv_cesa - fix final callback not ignoring input data
| * | | | crypto: mv_cesa - fix final callback not ignoring input dataPhil Sutter2012-02-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Broken by commit 6ef84509f3d439ed2d43ea40080643efec37f54f for users passing a request with non-zero 'nbytes' field, like e.g. testmgr. Cc: <stable@kernel.org> # 3.0+ Signed-off-by: Phil Sutter <phil.sutter@viprinet.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>