- 11 11月, 2008 8 次提交
-
-
由 Paul Mackerras 提交于
Turned off CONFIG_PCI_LEGACY and turned on EXT4, and otherwise mostly took the defaults. This also updates ppc6xx_defconfig, which covers the 6xx/7xx/7xxx-based embedded boards. Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Andreas Schwab 提交于
The new context may not be 16-byte aligned, so the real address of the mcontext structure should be read from the uc_regs pointer instead of directly using the (unaligned) uc_mcontext field. Signed-off-by: NAndreas Schwab <schwab@suse.de> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Rafael J. Wysocki 提交于
While investigating the failure of hibernation on 32-bit x86 with CONFIG_NUMA set, as described in this message http://marc.info/?l=linux-kernel&m=122634118116226&w=4 I asked some people for help and I was told that it wasn't really worth the effort, because CONFIG_NUMA was generally broken on 32-bit x86 systems and it shouldn't be used in such configs. For this reason, make CONFIG_NUMA depend on BROKEN instead of EXPERIMENTAL on x86-32. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Cc: Andi Kleen <andi@firstfloor.org> Cc: Pavel Machek <pavel@suse.cz> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 David S. Miller 提交于
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
This reverts commit 8dd94537. This fixes a boot failure reported by Robert Reif. The code above the section change expects to fallthrough, so we can't make such a section change here.
-
由 Matt Fleming 提交于
Some functions that may be called from this handler require that interrupts are disabled. Also, combining IRQF_DISABLED and IRQF_SHARED does not reliably disable interrupts in a handler, so remove IRQF_SHARED from the irq flags (this irq is not shared anyway). Signed-off-by: NMatt Fleming <mjf@gentoo.org> Cc: mingo@elte.hu Cc: venkatesh.pallipadi@intel.com Cc: "Will Newton" <will.newton@gmail.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Matt Fleming 提交于
In hpet_next_event() we check that the value we just wrote to HPET_Tn_CMP(timer) has reached the chip. Currently, we're checking that the value we wrote to HPET_Tn_CMP(timer) is in HPET_T0_CMP, which, if timer is anything other than timer 0, is likely to fail. Signed-off-by: NMatt Fleming <mjf@gentoo.org> Cc: mingo@elte.hu Cc: venkatesh.pallipadi@intel.com Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Matt Fleming 提交于
It is possible to flood the console with call traces if the WARN_ON condition is true because of the frequency with which this function is called. Signed-off-by: NMatt Fleming <mjf@gentoo.org> Cc: mingo@elte.hu Cc: venkatesh.pallipadi@intel.com Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
- 09 11月, 2008 5 次提交
-
-
由 Kumar Gala 提交于
unset CONFIG_PCI_LEGACY in the defconfigs as none of them enable ISDN drivers which seem to be the only place we are using pci_find_device Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Li Yang 提交于
Fixes following build error: CC drivers/usb/gadget/fsl_qe_udc.o drivers/usb/gadget/fsl_qe_udc.c: In function 'qe_eprx_stall_change': drivers/usb/gadget/fsl_qe_udc.c:156: error: 'struct usb_ctlr' has no member named 'usb_usep' drivers/usb/gadget/fsl_qe_udc.c:163: error: 'struct usb_ctlr' has no member named 'usb_usep' drivers/usb/gadget/fsl_qe_udc.c: In function 'qe_eptx_stall_change': drivers/usb/gadget/fsl_qe_udc.c:173: error: 'struct usb_ctlr' has no member named 'usb_usep' drivers/usb/gadget/fsl_qe_udc.c:180: error: 'struct usb_ctlr' has no member named 'usb_usep' drivers/usb/gadget/fsl_qe_udc.c: In function 'qe_eprx_nack': drivers/usb/gadget/fsl_qe_udc.c:201: error: 'struct usb_ctlr' has no member named 'usb_usep' drivers/usb/gadget/fsl_qe_udc.c:201: error: 'struct usb_ctlr' has no member named 'usb_usep' drivers/usb/gadget/fsl_qe_udc.c: In function 'qe_eprx_normal': drivers/usb/gadget/fsl_qe_udc.c:218: error: 'struct usb_ctlr' has no member named 'usb_usep' drivers/usb/gadget/fsl_qe_udc.c:218: error: 'struct usb_ctlr' has no member named 'usb_usep' drivers/usb/gadget/fsl_qe_udc.c: In function 'qe_ep_reset': drivers/usb/gadget/fsl_qe_udc.c:325: error: 'struct usb_ctlr' has no member named 'usb_usep' drivers/usb/gadget/fsl_qe_udc.c:342: error: 'struct usb_ctlr' has no member named 'usb_usep' drivers/usb/gadget/fsl_qe_udc.c: In function 'qe_ep_register_init': drivers/usb/gadget/fsl_qe_udc.c:515: error: 'struct usb_ctlr' has no member named 'usb_usep' drivers/usb/gadget/fsl_qe_udc.c: In function 'ch9getstatus': drivers/usb/gadget/fsl_qe_udc.c:1981: error: 'struct usb_ctlr' has no member named 'usb_usep' make[2]: *** [drivers/usb/gadget/fsl_qe_udc.o] Error 1 Signed-off-by: NLi Yang <leoli@freescale.com> Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Martyn Welch 提交于
This patch corrects the bus-frequency value provided in the SBC610's dts. Signed-off-by: NMartyn Welch <martyn.welch@gefanuc.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Kumar Gala 提交于
The implemetation of _tlbil_pid() on Freescale Book-E cores needs an msync & isync after we flash invalidate the TLBs. This was causing the following oops reported by Sebastian Andrzej Siewior: VFS: Mounted root (nfs filesystem) readonly. Freeing unused kernel memory: 148k init BUG: sleeping function called from invalid context at /home/bigeasy/git/linux-2.6-powerpc/mm/mmap.c:234 in_atomic():1, irqs_disabled():0 Call Trace: [df189df0] [c0007160] show_stack+0x48/0x148 (unreliable) [df189e30] [c0029480] __might_sleep+0xf0/0x100 [df189e40] [c0070ac0] remove_vma+0x28/0x98 [df189e50] [c0070c1c] exit_mmap+0xec/0x128 [df189e80] [c002d2f4] mmput+0x54/0xec [df189ea0] [c0030b6c] exit_mm+0x10c/0x120 [df189ed0] [c003288c] do_exit+0x1ac/0x6e8 [df189f20] [c0032e48] do_group_exit+0x80/0xac [df189f40] [c000e9dc] ret_from_syscall+0x0/0x3c BUG: scheduling while atomic: udevd/956/0x10000002 Modules linked in: Call Trace: [df189df0] [c0007160] show_stack+0x48/0x148 (unreliable) [df189e30] [c002ac88] __schedule_bug+0x58/0x6c [df189e40] [c023e6cc] schedule+0xa8/0x4a8 [df189e90] [c002ad6c] __cond_resched+0x38/0x64 [df189ea0] [c023ebc8] _cond_resched+0x3c/0x58 [df189eb0] [c0030e70] put_files_struct+0x90/0xec [df189ed0] [c00328a8] do_exit+0x1c8/0x6e8 [df189f20] [c0032e48] do_group_exit+0x80/0xac [df189f40] [c000e9dc] ret_from_syscall+0x0/0x3c Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Ingo Molnar 提交于
sched_clock() uses cycles_2_ns() needlessly - which is an irq-disabling variant of __cycles_2_ns(). Most of the time sched_clock() is called with irqs disabled already. The few places that call it with irqs enabled need to be updated. Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 08 11月, 2008 3 次提交
-
-
由 Ingo Molnar 提交于
in scheduler-intense workloads native_read_tsc() overhead accounts for 20% of the system overhead: 659567 system_call 41222.9375 686796 schedule 435.7843 718382 __switch_to 665.1685 823875 switch_mm 4526.7857 1883122 native_read_tsc 55385.9412 9761990 total 2.8468 this is large part due to the rdtsc_barrier() that is done before and after reading the TSC. But sched_clock() is not a precise clock in the GTOD sense, using such barriers is completely pointless. So remove the barriers and only use them in vget_cycles(). This improves lat_ctx performance by about 5%. Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Jay Lan 提交于
IA64 kdump kernel failed to initialize /proc/vmcore in 2.6.28-rc2. A bug was introduced in this patch commit: d9a9855d always reserve elfcore header memory in crash kernel The problem was that the call to reserve_elfcorehdr() should be placed in CONFIG_CRASH_DUMP rather than in CONFIG_CRASH_KERNEL, which does not exist. Signed-off-by: NJay Lan <jlan@sgi.com> Acked-by: NSimon Hormon <horms@verge.net.au> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
由 Andi Kleen 提交于
Fix the counter overflow check for CPUs with counter width > 32 I had a similar change in a different patch that I didn't submit and I didn't notice the problem earlier because it was always tested together. Signed-off-by: NAndi Kleen <ak@linux.intel.com> Signed-off-by: NRobert Richter <robert.richter@amd.com>
-
- 07 11月, 2008 7 次提交
-
-
由 Jeremy Fitzhardinge 提交于
Xen requires that all mappings of pagetable pages are read-only, so that they can't be updated illegally. As a result, if a page is being turned into a pagetable page, we need to make sure all its mappings are RO. If the page had been used for ioremap or vmalloc, it may still have left over mappings as a result of not having been lazily unmapped. This change makes sure we explicitly mop them all up before pinning the page. Unlike aliases created by kmap, the there can be vmalloc aliases even for non-high pages, so we must do the flush unconditionally. Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: Linux Memory Management List <linux-mm@kvack.org> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Jeremy Fitzhardinge 提交于
Impact: fix 32-bit Xen guest boot crash On 32-bit PAE, pud_page, for no good reason, didn't really return a struct page *. Since Jan Beulich's fix "i386/PAE: fix pud_page()", pud_page does return a struct page *. Because PAE has 3 pagetable levels, the pud level is folded into the pgd level, so pgd_page() is the same as pud_page(), and now returns a struct page *. Update the xen/mmu.c code which uses pgd_page() accordingly. Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Dan Williams 提交于
When 'start' and 'end' are less than a cacheline apart and 'start' is unaligned we are done after cleaning and invalidating the first cacheline. So check for (start < end) which will not walk off into invalid address ranges when (start > end). This issue was caught by drivers/dma/dmatest. 2.6.27 is susceptible. Cc: <stable@kernel.org> Cc: Haavard Skinnemoen <haavard.skinnemoen@atmel.com> Cc: Lothar WaÃ<9f>mann <LW@KARO-electronics.de> Cc: Lennert Buytenhek <buytenh@marvell.com> Cc: Eric Miao <eric.miao@marvell.com> Signed-off-by: NDan Williams <dan.j.williams@intel.com>
-
由 Russell King 提交于
As a result of the ptebits changes, we ended up marking device mappings as normal memory on ARMv7 CPUs, resulting in undesirable behaviour with serial ports and the like. While reviewing the section mapping table entries, other errors in the memory type settings for devices were detected and confirmed to prevent Xscale3 platforms booting. Tested on: OMAP34xx (ARMv7), OMAP24xx (ARMv6), OMAP16xx (ARM926T, ARMv5), PXA311 (Xscale3), PXA272 (Xscale), PXA255 (Xscale), IXP42x (Xscale), S3C2410 (ARM920T, ARMv4T), ARM720T (ARMv4T) StrongARM-110 (ARMv4) Acked-by: NTony Lindgren <tony@atomide.com> Tested-by: NRobert Jarzmik <robert.jarzmik@free.fr> Tested-by: NMike Rapoport <mike@compulab.co.il> Tested-by: NBen Dooks <ben-linux@fluff.org> Tested-by: NAnders Grafström <grfstrm@users.sourceforge.net> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Doug Chapman 提交于
This fixes a regression introduced by 2c6e6db4 "Minimize per_cpu reservations." That patch incorrectly used information about what CPUs are possible that was not yet initialized by ACPI. The end result was that per_cpu structures for offline CPUs were not initialized causing a NULL pointer reference. Since we cannot do the full acpi_boot_init() call any earlier, the simplest fix is to just parse the MADT for SAPIC entries early to find the CPU info. This should also allow for some cleanup of the code added by the "Minimize per_cpu reservations". This patch just fixes the regressions, the cleanup will come in a later patch. Signed-off-by: NDoug Chapman <doug.chapman@hp.com> Signed-off-by: NAlex Chiang <achiang@hp.com> CC: Robin Holt <holt@sgi.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
由 Bjorn Helgaas 提交于
No functional change, just reorder some config options and update the "Power management and ACPI" label to match the defacto x86 standard. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
由 Russell King 提交于
As of 73bdf0a6, the kernel needs to know where modules are located in the virtual address space. On ARM, we located this region between MODULE_START and MODULE_END. Unfortunately, everyone else calls it MODULES_VADDR and MODULES_END. Update ARM to use the same naming, so is_vmalloc_or_module_addr() can work properly. Also update the comment on mm/vmalloc.c to reflect that ARM also places modules in a separate region from the vmalloc space. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 06 11月, 2008 9 次提交
-
-
由 Eduardo Habkost 提交于
This reverts commit c7ffa6c2. the assumptio of this change was that this would not break any existing machine. Andrey Borzenkov reported troubles with the ACPI reboot method: the system would hang on reboot, necessiating a power cycle. Probably more systems are affected as well. Also, there are patches queued up for v2.6.29 to disable virtualization on emergency_restart() - which was the original motivation of this change. Reported-by: NAndrey Borzenkov <arvidjaar@mail.ru> Bisected-by: NAndrey Borzenkov <arvidjaar@mail.ru> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Acked-by: NAvi Kivity <avi@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Hugh Dickins 提交于
Impact: right-align /proc/meminfo consistent with other fields When the split-LRU patches added Inactive(anon) and Inactive(file) lines to /proc/meminfo, all counts were moved two columns rightwards to fit in. Now move x86's DirectMap lines two columns rightwards to line up. Signed-off-by: NHugh Dickins <hugh@veritas.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Joerg Roedel 提交于
Lazy flushing needs to take care of the unmap path too which is not yet implemented and leads to stale IO/TLB entries. This is fixed by this patch. Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
-
由 Suresh Siddha 提交于
Impact: fix rare x2apic hang On x86, x2apic mode accesses for sending IPI's don't have serializing semantics. If the IPI receivner refers(in lock-free fashion) to some memory setup by the sender, the need for smp_mb() before sending the IPI becomes critical in x2apic mode. Add the smp_mb() in native_flush_tlb_others() before sending the IPI. Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Yinghai Lu 提交于
Impact: fix warning message when PARAVIRT is set in config Remove stale #ifdef components from our IRQ sizing logic. x86/Voyager is the only holdout. Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Bjorn Helgaas 提交于
Impact: clarify menuconfig text Mention ACPI in the top-level menu to give a clue as to where it lives. This matches what ia64 does. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Yinghai Lu 提交于
Impact: make NR_IRQS big enough for system with lots of apic/pins If lots of IO_APIC's are there (or can be there), size the same way as 64-bit, depending on MAX_IO_APICS and NR_CPUS. This fixes the boot problem reported by Ben Hutchings on a 32-bit server with 5 IO-APICs and 240 IO-APIC pins. Signed-off-by: NYinghai <yinghai@kernel.org> Tested-by: NBen Hutchings <bhutchings@solarflare.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Ben Hutchings 提交于
Impact: fix boot hang on 32-bit systems with more than 224 IO-APIC pins On some 32-bit systems with a lot of IO-APICs probe_nr_irqs() can return a value larger than NR_IRQS. This will lead to probe_irq_on() overrunning the irq_desc array. I hit this when running net-next-2.6 (close to 2.6.28-rc3) on a Supermicro dual Xeon system. NR_IRQS is 224 but probe_nr_irqs() detects 5 IOAPICs and returns 240. Here are the log messages: Tue Nov 4 16:53:47 2008 ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) Tue Nov 4 16:53:47 2008 IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23 Tue Nov 4 16:53:47 2008 ACPI: IOAPIC (id[0x02] address[0xfec81000] gsi_base[24]) Tue Nov 4 16:53:47 2008 IOAPIC[1]: apic_id 2, version 32, address 0xfec81000, GSI 24-47 Tue Nov 4 16:53:47 2008 ACPI: IOAPIC (id[0x03] address[0xfec81400] gsi_base[48]) Tue Nov 4 16:53:47 2008 IOAPIC[2]: apic_id 3, version 32, address 0xfec81400, GSI 48-71 Tue Nov 4 16:53:47 2008 ACPI: IOAPIC (id[0x04] address[0xfec82000] gsi_base[72]) Tue Nov 4 16:53:47 2008 IOAPIC[3]: apic_id 4, version 32, address 0xfec82000, GSI 72-95 Tue Nov 4 16:53:47 2008 ACPI: IOAPIC (id[0x05] address[0xfec82400] gsi_base[96]) Tue Nov 4 16:53:47 2008 IOAPIC[4]: apic_id 5, version 32, address 0xfec82400, GSI 96-119 Tue Nov 4 16:53:47 2008 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) Tue Nov 4 16:53:47 2008 ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Tue Nov 4 16:53:47 2008 Enabling APIC mode: Flat. Using 5 I/O APICs Signed-off-by: NBen Hutchings <bhutchings@solarflare.com> Acked-by: NYinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Ingo Molnar 提交于
Impact: improve wakeup affinity on NUMA systems, tweak SMP systems Given the fixes+tweaks to the wakeup-buddy code, re-tweak the domain balancing defaults on NUMA and SMP systems. Turn on SD_WAKE_AFFINE which was off on x86 NUMA - there's no reason why we would not want to have wakeup affinity across nodes as well. (we already do this in the standard NUMA template.) lat_ctx on a NUMA box is particularly happy about this change: before: | phoenix:~/l> ./lat_ctx -s 0 2 | "size=0k ovr=2.60 | 2 5.70 after: | phoenix:~/l> ./lat_ctx -s 0 2 | "size=0k ovr=2.65 | 2 2.07 a 2.75x speedup. pipe-test is similarly happy about it too: | phoenix:~/sched-tests> ./pipe-test | 18.26 usecs/loop. | 14.70 usecs/loop. | 14.38 usecs/loop. | 10.55 usecs/loop. # +WAKE_AFFINE on domain0+domain1 | 8.63 usecs/loop. | 8.59 usecs/loop. | 9.03 usecs/loop. | 8.94 usecs/loop. | 8.96 usecs/loop. | 8.63 usecs/loop. Also: - disable SD_BALANCE_NEWIDLE on NUMA and SMP domains (keep it for siblings) - enable SD_WAKE_BALANCE on SMP domains Sysbench+postgresql improves all around the board, quite significantly: .28-rc3-11474e2c .28-rc3-11474e2c-tune ------------------------------------------------- 1: 571 688 +17.08% 2: 1236 1206 -2.55% 4: 2381 2642 +9.89% 8: 4958 5164 +3.99% 16: 9580 9574 -0.07% 32: 7128 8118 +12.20% 64: 7342 8266 +11.18% 128: 7342 8064 +8.95% 256: 7519 7884 +4.62% 512: 7350 7731 +4.93% ------------------------------------------------- SUM: 55412 59341 +6.62% So it's a win both for the runup portion, the peak area and the tail. Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 05 11月, 2008 8 次提交
-
-
由 Stephen Rothwell 提交于
This gets rid of this build warning: arch/powerpc/platforms/pseries/pci_dlpar.c: In function 'init_phb_dynamic': arch/powerpc/platforms/pseries/pci_dlpar.c:192: warning: unused variable 'b' This is one of the very few warnings left in a ppc64_defconfig build and getting rid of it will make it easier to see future introduced ones (in fact this was introduced very recently). Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Alexey Dobriyan 提交于
This fixes this error on Cell when CONFIG_KEXEC = n: arch/powerpc/platforms/cell/ras.c:299: error: implicit declaration of function 'crash_shutdown_register' We have to include <asm/kexec.h> because it contains the dummy definition of crash_shutdown_register that is used when CONFIG_KEXEC=n, but <linux/kexec.h> doesn't include <asm/kexec.h> in that case. Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Tony Lindgren 提交于
Otherwise twl4030 gpios won't work. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
On omap24xx, INTCPS_SIR_IRQ_OFFSET bits [6:0] contains the current active interrupt number. However, on 34xx INTCPS_SIR_IRQ_OFFSET bits [31:7] also contains the SPURIOUSIRQFLAG, which gets set if the interrupt sorting information is invalid. If the SPURIOUSIRQFLAG bits are not ignored, the interrupt code will occasionally produce a bunch of confusing errors: irq -33, desc: c02ddcc8, depth: 0, count: 0, unhandled: 0 ->handle_irq(): c006f23c, handle_bad_irq+0x0/0x22c ->chip(): 00000000, 0x0 ->action(): 00000000 Fix this by masking out only the ACTIVEIRQ bits. Also fix a confusing comment. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Zhaolei 提交于
debugfs_create_*() returns NULL if an error occurs, returns -ENODEV when debugfs is not enabled in the kernel. Comparing to PATCH v1, because clk_debugfs_init is included in "#if defined CONFIG_DEBUG_FS", we only need to check NULL return. Thanks Li Zefan <lizf@cn.fujitsu.com> debugfs_create_u8() and other function's return value's checking method are also fixed in this patch. Signed-off-by: NZhao Lei <zhaolei@cn.fujitsu.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Sanjeev Premi 提交于
Fix these compiler warnings: gpmc.c: In function 'gpmc_init': gpmc.c:432: warning: 'return' with a value, in function returning void gpmc.c:439: warning: 'return' with a value, in function returning void Signed-off-by: NSanjeev Premi <premi@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Luck 提交于
Now that all the ia64 mmu pieces are in the tree we can build support into the generic kernel. Signed-off-by: NTony Luck <tony.luck@intel.com>
-
由 FUJITA Tomonori 提交于
The block layer dropped the virtual merge feature (b8b3e16c). BIO_VMERGE_BOUNDARY definition is meaningless now (For IA64, BIO_VMERGE_BOUNDARY has been meaningless for a long time since IA64 disables the virtual merge feature). Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by: NTony Luck <tony.luck@intel.com>
-