- 09 8月, 2009 1 次提交
-
-
由 Roel Kluin 提交于
If the vendor name (from c16) can be longer than 100 bytes (or missing a terminating null), then the null is written past the end of vendor[]. Found with Parfait, http://research.sun.com/projects/parfait/Signed-off-by: NRoel Kluin <roel.kluin@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NH. Peter Anvin <hpa@zytor.com> Cc: Huang Ying <ying.huang@intel.com>
-
- 08 8月, 2009 3 次提交
-
-
由 Ozan Çağlayan 提交于
MacBookPro5,1 is not able to reboot unless reboot=pci is set. This patch forces it through a DMI quirk specific to this device. Signed-off-by: NOzan Çağlayan <ozan@pardus.org.tr> LKML-Reference: <1249403971-6543-1-git-send-email-ozan@pardus.org.tr> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Yinghai Lu 提交于
found a system where x2apic reports an MSI-X irq initialization failure: [ 302.859446] igbvf 0000:81:10.4: enabling device (0000 -> 0002) [ 302.874369] igbvf 0000:81:10.4: using 64bit DMA mask [ 302.879023] igbvf 0000:81:10.4: using 64bit consistent DMA mask [ 302.894386] igbvf 0000:81:10.4: enabling bus mastering [ 302.898171] igbvf 0000:81:10.4: setting latency timer to 64 [ 302.914050] reserve_memtype added 0xefb08000-0xefb0c000, track uncached-minus, req uncached-minus, ret uncached-minus [ 302.933839] reserve_memtype added 0xefb28000-0xefb29000, track uncached-minus, req uncached-minus, ret uncached-minus [ 302.940367] alloc irq_desc for 265 on node 4 [ 302.956874] alloc kstat_irqs on node 4 [ 302.959452] alloc irq_2_iommu on node 0 [ 302.974328] igbvf 0000:81:10.4: irq 265 for MSI/MSI-X [ 302.977778] alloc irq_desc for 266 on node 4 [ 302.980347] alloc kstat_irqs on node 4 [ 302.995312] free_memtype request 0xefb28000-0xefb29000 [ 302.998816] igbvf 0000:81:10.4: Failed to initialize MSI-X interrupts. ... it turns out that when trying to enable MSI-X, __assign_irq_vector(new, cfg_new, apic->target_cpus()) can not get vector because for x2apic target-cpus returns cpumask_of(0) Update that to online_mask like xapic. Signed-off-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com> LKML-Reference: <4A785AFF.3050902@kernel.org> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Gupta, Ajay Kumar 提交于
OMAP3EVM uses ISP1504 phy which doesn't require any programming and thus has to use NOP otg transceiver. Cleanups being done: - Remove unwanted code in usb-musb.c file - Register NOP in OMAP3EVM board file using usb_nop_xceiv_register(). - Select NOP_USB_XCEIV for OMAP3EVM boards. - Don't enable TWL4030_USB in omap3_evm_defconfig Signed-off-by: NAjay Kumar Gupta <ajay.gupta@ti.com> Signed-off-by: NEino-Ville Talvala <talvala@stanford.edu> Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 07 8月, 2009 2 次提交
-
-
由 Roel Kluin 提交于
Check whether index is within bounds before testing the element. Signed-off-by: NRoel Kluin <roel.kluin@gmail.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
由 Hendrik Brueckner 提交于
Currently, the machine_flags are stored late in the startup initialization which results in failing machine type checks (e.g. for MACHINE_IS_VM). To allow these checks, store the machine flags in the lowcore when the machine type has been detected. Moving the machine_flags to the lowcore has been introduced with git commit 25097bf1Signed-off-by: NHendrik Brueckner <brueckner@linux.vnet.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
- 06 8月, 2009 4 次提交
-
-
由 Benjamin Herrenschmidt 提交于
If the current CPU doesn't support performance counters, cur_cpu_spec->oprofile_cpu_type can be NULL. The current perf_counter modules don't test for that case and would thus crash at boot time. Bug reported by David Woodhouse. Reported-by: NDavid Woodhouse <dwmw2@infradead.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: NPaul Mackerras <paulus@samba.org> LKML-Reference: <19066.48028.446975.501454@cargo.ozlabs.ibm.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Hartley Sweeten 提交于
<linux/clk.h> should be included to get the base API prototypes. This fixes the following sparse warnings: arch/arm/common/clkdev.c:65:12: warning: symbol 'clk_get_sys' was not declared. Should it be static? arch/arm/common/clkdev.c:79:12: warning: symbol 'clk_get' was not declared. Should it be static? arch/arm/common/clkdev.c:87:6: warning: symbol 'clk_put' was not declared. Should it be static? Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Hartley Sweeten 提交于
preserve_crunch_context() calls __copy_to_user() which expects the destination address to be in __user space. setup_sigframe() properly passes the destination address. restore_crunch_context() calls __copy_from_user() which expects the source address to be in __user space. restore_sigframe() properly passes the source address. This fixes {preserve/restore}_crunch_context() to accept the address as __user space and resolves the following sparse warnings: arch/arm/kernel/signal.c:146:31: warning: incorrect type in argument 1 (different address spaces) expected void [noderef] <asn:1>*to got struct crunch_sigframe *frame arch/arm/kernel/signal.c:156:38: warning: incorrect type in argument 2 (different address spaces) expected void const [noderef] <asn:1>*from got struct crunch_sigframe *frame arch/arm/kernel/signal.c:250:48: warning: incorrect type in argument 1 (different address spaces) expected struct crunch_sigframe *frame got struct crunch_sigframe [noderef] <asn:1>*<noident> arch/arm/kernel/signal.c:365:49: warning: incorrect type in argument 1 (different address spaces) expected struct crunch_sigframe *frame got struct crunch_sigframe [noderef] <asn:1>*<noident> Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Andrew Victor 提交于
Stop referencing CLOCK_TICK_RATE in the KS8695 drivers, rather refer to a KS8695_CLOCK_RATE. Issue pointed out by Russell King on arm-linux-kernel mailing list. Signed-off-by: NAndrew Victor <linux@maxim.org.za> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 05 8月, 2009 1 次提交
-
-
由 Alok Kataria 提交于
With CONFIG_STACK_PROTECTOR turned on, VMI doesn't boot with more than one processor. The problem is with the gs value not being initialized correctly when registering the secondary processor for VMI's case. The patch below initializes the gs value for the AP to __KERNEL_STACK_CANARY. Without this the secondary processor keeps on taking a GP on every gs access. Signed-off-by: NAlok N Kataria <akataria@vmware.com> Cc: <stable@kernel.org> # for v2.6.30.x LKML-Reference: <1249425262.18955.40.camel@ank32.eng.vmware.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 04 8月, 2009 29 次提交
-
-
由 Subrata Modak 提交于
The following fix was initially inspired by David Howells fix few days back: http://lkml.org/lkml/2009/7/9/109 However, Ingo disapproves such fixes as it's dangerous (it can hide future, relevant warnings) - in something as performance-uncritical. So, initialize 'err' to '0' to work around a GCC false positive warning: http://lkml.org/lkml/2009/7/18/89 Signed-off-by: Subrata Modak<subrata@linux.vnet.ibm.com> Cc: Sachin P Sant <sachinp@linux.vnet.ibm.com> Cc: David Howells <dhowells@redhat.com> Cc: Balbir Singh <balbir@linux.vnet.ibm.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> LKML-Reference: <20090721023226.31855.67236.sendpatchset@subratamodak.linux.ibm.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Jack Steiner 提交于
In uv_setup_irq(), the call to create_irq() initially assigns IRQ vectors to cpu 0. The subsequent call to assign_irq_vector() in arch_enable_uv_irq() migrates the IRQ to another cpu and frees the cpu 0 vector - at least it will be freed as soon as the "IRQ move" completes. arch_enable_uv_irq() needs to send a cleanup IPI to complete the IRQ move. Otherwise, assignment of GRU interrupts on large systems (>200 cpus) will exhaust the cpu 0 interrupt vectors and initialization of the GRU driver will fail. Signed-off-by: NJack Steiner <steiner@sgi.com> LKML-Reference: <20090720142840.GA8885@sgi.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Jan Beulich 提交于
With VMALLOC_END included in the calculation of MAXMEM (as of 2.6.28) it is no longer correct to also bump __VMALLOC_RESERVE in reserve_top_address(). Doing so results in needlessly small lowmem. Signed-off-by: NJan Beulich <jbeulich@novell.com> LKML-Reference: <4A71DD2A020000780000D482@vpn.id2.novell.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Yinghai Lu 提交于
One system has socket 1 come up as BSP. kexeced kernel reports BSP as: [ 1.524550] Initializing cgroup subsys cpuacct [ 1.536064] initial_apicid:20 [ 1.537135] ht_mask_width:1 [ 1.538128] core_select_mask:f [ 1.539126] core_plus_mask_width:5 [ 1.558479] CPU: Physical Processor ID: 0 [ 1.559501] CPU: Processor Core ID: 0 [ 1.560539] CPU: L1 I cache: 32K, L1 D cache: 32K [ 1.579098] CPU: L2 cache: 256K [ 1.580085] CPU: L3 cache: 24576K [ 1.581108] CPU 0/0x20 -> Node 0 [ 1.596193] CPU 0 microcode level: 0xffff0008 It doesn't have correct physical processor id and will get an error: [ 38.840859] CPU0 attaching sched-domain: [ 38.848287] domain 0: span 0,8,72 level SIBLING [ 38.851151] groups: 0 8 72 [ 38.858137] domain 1: span 0,8-15,72-79 level MC [ 38.868944] groups: 0,8,72 9,73 10,74 11,75 12,76 13,77 14,78 15,79 [ 38.881383] ERROR: parent span is not a superset of domain->span [ 38.890724] domain 2: span 0-7,64-71 level CPU [ 38.899237] ERROR: domain->groups does not contain CPU0 [ 38.909229] groups: 8-15,72-79 [ 38.912547] ERROR: groups don't span domain->span [ 38.919665] domain 3: span 0-127 level NODE [ 38.930739] groups: 0-7,64-71 8-15,72-79 16-23,80-87 24-31,88-95 32-39,96-103 40-47,104-111 48-55,112-119 56-63,120-127 it turns out: we can not use current_cpu_data in phys_pgd_id for x2apic. identify_boot_cpu() is called by check_bugs() before smp_prepare_cpus() and till smp_prepare_cpus() current_cpu_data for bsp is assigned with boot_cpu_data. Just make phys_pkg_id for x2apic is aligned to xapic. Signed-off-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> LKML-Reference: <4A6ADD0D.10002@kernel.org> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Jack Steiner 提交于
Change SGI UV default apicid mode to "physical". This is required to match settings in the UV hub chip. Signed-off-by: NJack Steiner <steiner@sgi.com> LKML-Reference: <20090727143856.GA8905@sgi.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Jack Steiner 提交于
The UV chipset automatically supplies the upper bits on nodes being referenced by MMR accesses. These bit can be deleted from the hub addressing macros. Signed-off-by: NJack Steiner <steiner@sgi.com> LKML-Reference: <20090727143808.GA8076@sgi.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Jack Steiner 提交于
The UV BIOS has added additional MMR ranges that are mapped via EFI virtual mode mappings. These ranges should be deleted from ranges mapped by uv_system_init(). Signed-off-by: NJack Steiner <steiner@sgi.com> Cc: linux-mm@kvack.org LKML-Reference: <20090727143656.GA7698@sgi.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Jack Steiner 提交于
UV blades may not have any blade-local memory. Add a field (nid) to the UV blade structure to indicates whether the node has local memory. This is needed by the GRU driver (pushed separately). Signed-off-by: NJack Steiner <steiner@sgi.com> Cc: linux-mm@kvack.org LKML-Reference: <20090727143507.GA7006@sgi.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 H. Peter Anvin 提交于
From Gabe Black in bugzilla 13888: native_save_fl is implemented as follows: 11static inline unsigned long native_save_fl(void) 12{ 13 unsigned long flags; 14 15 asm volatile("# __raw_save_flags\n\t" 16 "pushf ; pop %0" 17 : "=g" (flags) 18 : /* no input */ 19 : "memory"); 20 21 return flags; 22} If gcc chooses to put flags on the stack, for instance because this is inlined into a larger function with more register pressure, the offset of the flags variable from the stack pointer will change when the pushf is performed. gcc doesn't attempt to understand that fact, and address used for pop will still be the same. It will write to somewhere near flags on the stack but not actually into it and overwrite some other value. I saw this happen in the ide_device_add_all function when running in a simulator I work on. I'm assuming that some quirk of how the simulated hardware is set up caused the code path this is on to be executed when it normally wouldn't. A simple fix might be to change "=g" to "=r". Reported-by: NGabe Black <spamforgabe@umich.edu> Signed-off-by: NH. Peter Anvin <hpa@zytor.com> Cc: Stable Team <stable@kernel.org>
-
由 Borislav Petkov 提交于
Make rdmsr_on_cpus/wrmsr_on_cpus execute on the current CPU only if it is in the supplied bitmask. Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
由 H. Peter Anvin 提交于
Older versions of binutils did not accept the naked "ASSERT" syntax; it is considered an expression whose value needs to be assigned to something. Reported-tested-and-fixed-by: NJean Delvare <khali@linux-fr.org> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
由 Paul Mackerras 提交于
Booting current 64-bit x86 kernels on the latest Apple MacBook (MacBook5,2) via EFI gives the following warning: [ 0.182209] ------------[ cut here ]------------ [ 0.182222] WARNING: at arch/x86/mm/pageattr.c:581 __cpa_process_fault+0x44/0xa0() [ 0.182227] Hardware name: MacBook5,2 [ 0.182231] CPA: called for zero pte. vaddr = ffff8800ffe00000 cpa->vaddr = ffff8800ffe00000 [ 0.182236] Modules linked in: [ 0.182242] Pid: 0, comm: swapper Not tainted 2.6.31-rc4 #6 [ 0.182246] Call Trace: [ 0.182254] [<ffffffff8102c754>] ? __cpa_process_fault+0x44/0xa0 [ 0.182261] [<ffffffff81048668>] warn_slowpath_common+0x78/0xd0 [ 0.182266] [<ffffffff81048744>] warn_slowpath_fmt+0x64/0x70 [ 0.182272] [<ffffffff8102c7ec>] ? update_page_count+0x3c/0x50 [ 0.182280] [<ffffffff818d25c5>] ? phys_pmd_init+0x140/0x22e [ 0.182286] [<ffffffff8102c754>] __cpa_process_fault+0x44/0xa0 [ 0.182292] [<ffffffff8102ce60>] __change_page_attr_set_clr+0x5f0/0xb40 [ 0.182301] [<ffffffff810d1035>] ? vm_unmap_aliases+0x175/0x190 [ 0.182307] [<ffffffff8102d4ae>] change_page_attr_set_clr+0xfe/0x3d0 [ 0.182314] [<ffffffff8102dcca>] _set_memory_uc+0x2a/0x30 [ 0.182319] [<ffffffff8102dd4b>] set_memory_uc+0x7b/0xb0 [ 0.182327] [<ffffffff818afe31>] efi_enter_virtual_mode+0x2ad/0x2c9 [ 0.182334] [<ffffffff818a1c66>] start_kernel+0x2db/0x3f4 [ 0.182340] [<ffffffff818a1289>] x86_64_start_reservations+0x99/0xb9 [ 0.182345] [<ffffffff818a1389>] x86_64_start_kernel+0xe0/0xf2 [ 0.182357] ---[ end trace 4eaa2a86a8e2da22 ]--- [ 0.182982] init_memory_mapping: 00000000ffffc000-0000000100000000 [ 0.182993] 00ffffc000 - 0100000000 page 4k This happens because the 64-bit version of efi_ioremap calls init_memory_mapping for all addresses, regardless of whether they are RAM or MMIO. The EFI tables on this machine ask for runtime access to some MMIO regions: [ 0.000000] EFI: mem195: type=11, attr=0x8000000000000000, range=[0x0000000093400000-0x0000000093401000) (0MB) [ 0.000000] EFI: mem196: type=11, attr=0x8000000000000000, range=[0x00000000ffc00000-0x00000000ffc40000) (0MB) [ 0.000000] EFI: mem197: type=11, attr=0x8000000000000000, range=[0x00000000ffc40000-0x00000000ffc80000) (0MB) [ 0.000000] EFI: mem198: type=11, attr=0x8000000000000000, range=[0x00000000ffc80000-0x00000000ffca4000) (0MB) [ 0.000000] EFI: mem199: type=11, attr=0x8000000000000000, range=[0x00000000ffca4000-0x00000000ffcb4000) (0MB) [ 0.000000] EFI: mem200: type=11, attr=0x8000000000000000, range=[0x00000000ffcb4000-0x00000000ffffc000) (3MB) [ 0.000000] EFI: mem201: type=11, attr=0x8000000000000000, range=[0x00000000ffffc000-0x0000000100000000) (0MB) This arranges to pass the EFI memory type through to efi_ioremap, and makes efi_ioremap use ioremap rather than init_memory_mapping if the type is EFI_MEMORY_MAPPED_IO. With this, the above warning goes away. Signed-off-by: NPaul Mackerras <paulus@samba.org> LKML-Reference: <19062.55858.533494.471153@cargo.ozlabs.ibm.com> Cc: Huang Ying <ying.huang@intel.com> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
由 Paul Mackerras 提交于
The latest Apple MacBook (MacBook5,2) doesn't reboot successfully under Linux; neither the EFI reboot method nor the default method using the keyboard controller works (the system just hangs and doesn't reset). However, the method using the "PCI reset register" at 0xcf9 does work. This adds a quirk to detect this machine via DMI and force the reboot_type to BOOT_CF9. With this it reboots successfully without requiring a command-line option. Note that the EFI code forces reboot_type to BOOT_EFI when the machine is booted via EFI, but this overrides that since the core_initcall runs after the EFI initialization code. Signed-off-by: NPaul Mackerras <paulus@samba.org> LKML-Reference: <19062.56420.501516.316181@cargo.ozlabs.ibm.com> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
由 Thomas Hellstrom 提交于
The code was incorrectly reserving memtypes using the page virtual address instead of the physical address. Furthermore, the code was not ignoring highmem pages as it ought to. ( upstream does not pass in highmem pages yet - but upcoming graphics code will do it and there's no reason to not handle this properly in the CPA APIs.) Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=13884Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com> Cc: <stable@kernel.org> Cc: dri-devel@lists.sourceforge.net Cc: venkatesh.pallipadi@intel.com LKML-Reference: <1249284345-7654-1-git-send-email-thellstrom@vmware.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
None of these is used outside the VPE loader. Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
This may happen if a bad sequence of relocations is being encountered. Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Raghu Gandham 提交于
Signed-off-by: NRaghu Gandham <raghu@mips.com> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
There were three different errors resulting in a "dangerous relocation" message. Add the relocation type to the messgages to make them more useful. Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 David Daney 提交于
In mm/slab.c the function do_ccupdate_local requires that interrupts be disabled. If they are not, we panic with CONFIG_DEBUG_SLAB. So we disable interrupts while processing IPIs. Also these are not shared irqs, so get rid of the IRQF_SHARED flag. Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Roel Kluin 提交于
Check whether index is within bounds before testing the element. Signed-off-by: NRoel Kluin <roel.kluin@gmail.com> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Julia Lawall 提交于
The kernel.h macro DIV_ROUND_CLOSEST performs the computation (x + d/2)/d but is perhaps more readable. The semantic patch that makes this change is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @haskernel@ @@ #include <linux/kernel.h> @depends on haskernel@ expression x,__divisor; @@ - (((x) + ((__divisor) / 2)) / (__divisor)) + DIV_ROUND_CLOSEST(x,__divisor) // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Florian Fainelli 提交于
This patch fixes the following warning at boot time: WARNING: at drivers/gpio/gpiolib.c:83 0x8021d5e0() autorequest GPIO-207 Modules linked in: Call Trace:[<8011e0ec>] 0x8011e0ec [<80110a28>] 0x80110a28 [<80110a28>] 0x80110a28 [..snip..] The current code does not request the GPIO and attempts to set its direction, which is a violation of the GPIO API. This patch also unhardcode the GPIO we request and use the one we defined in the button driver. Signed-off-by: NFlorian Fainelli <florian@openwrt.org> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Florian Fainelli 提交于
Now that we have removed all warnings from the ar7 board code we can use -Werror like on other MIPS boards. Signed-off-by: NFlorian Fainelli <florian@openwrt.org> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Florian Fainelli 提交于
Signed-off-by: NFlorian Fainelli <florian@openwrt.org> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Florian Fainelli 提交于
Signed-off-by: NFlorian Fainelli <florian@openwrt.org> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Florian Fainelli 提交于
This patch fixes the following build failure when CONFIG_SERIAL_8250 is not enabled in the kernel configuration: arch/mips/ar7/built-in.o: In function 'ar7_register_devices': platform.c:(.init.text+0x61c): undefined reference to 'early_serial_setup' platform.c:(.init.text+0x61c): relocation truncated to fit: R_MIPS_26 against 'early_serial_setup' platform.c:(.init.text+0x68c): undefined reference to 'early_serial_setup' platform.c:(.init.text+0x68c): relocation truncated to fit: R_MIPS_26 against 'early_serial_setup' Signed-off-by: NFlorian Fainelli <florian@openwrt.org> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-