1. 25 10月, 2011 12 次提交
  2. 20 10月, 2011 11 次提交
    • A
      MIPS: Fix build with C=1 · 08fa624f
      Aaro Koskinen 提交于
      When trying to compile the 3.1-rc10 kernel for my MIPS board with C=1
      (sparse checking), the build fails early with the error:
      
      	  CHK     include/linux/version.h
      	  UPD     include/linux/version.h
      	  CHK     include/generated/utsrelease.h
      	  UPD     include/generated/utsrelease.h
      	  Checking missing-syscalls for N32
      	  CALL    scripts/checksyscalls.sh
      	  Checking missing-syscalls for O32
      	  CALL    scripts/checksyscalls.sh
      	  CC      kernel/bounds.s
      	  GEN     include/generated/bounds.h
      	  CC      arch/mips/kernel/asm-offsets.s
      	  GEN     include/generated/asm-offsets.h
      	  CALL    scripts/checksyscalls.sh
      	  HOSTCC  scripts/genksyms/genksyms.o
      	  SHIPPED scripts/genksyms/lex.lex.c
      	  SHIPPED scripts/genksyms/keywords.hash.c
      	  SHIPPED scripts/genksyms/parse.tab.h
      	  HOSTCC  scripts/genksyms/lex.lex.o
      	  SHIPPED scripts/genksyms/parse.tab.c
      	  HOSTCC  scripts/genksyms/parse.tab.o
      	  HOSTLD  scripts/genksyms/genksyms
      	/bin/sh: Syntax error: "(" unexpected
      	make[3]: *** [scripts/mod/empty.o] Error 2
      	make[2]: *** [scripts/mod] Error 2
      	make[1]: *** [scripts] Error 2
      
      It seems the shell chokes because sparse is called with command line
      arguments such as:
      
      	-D__INT8_C(c)='c'
      
      Converting these to form:
      
      	-D'__INT8_C(c)'='c'
      
      seems to fix the problem.
      
      [ralf@linux-mips.org: This affects builds with gcc 4.5 and newer.]
      Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/2827/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      08fa624f
    • R
      MIPS: MSP71xx: Fix build error. · 2fd43108
      Ralf Baechle 提交于
      After the recent cleanup of the register_*_smp_ops() functions msp71xx
      wasn't fixed to include the now necessary header resulting in:
      
      /home/ralf/src/linux/upstream-linus/arch/mips/pmc-sierra/msp71xx/msp_setup.c: In function ‘prom_init’:
      /home/ralf/src/linux/upstream-linus/arch/mips/pmc-sierra/msp71xx/msp_setup.c:231:2: error: implicit declaration of function ‘register_vsmp_smp_ops’ [-Werror=implicit-function-declaration]
      cc1: all warnings being treated as errors
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      2fd43108
    • R
    • J
      MIPS: Netlogic: Specify architecture CFLAGS · 39ad5680
      Jayachandran C 提交于
      Use -march=xlr if available, otherwise fallback to mips64. This allows
      us to support compilation with MIPS toolchains which are not customized
      for XLR.
      
      [ralf@linux-mips.org: And more importantly it works around a gas bug in
      binutils 2.21 which otherwise may result in an assertion failure building
      arch/mips/kernel/genex.S.  See
      http://sourceware.org/bugzilla/show_bug.cgi?id=12915 for details.]
      Signed-off-by: NJayachandran C <jayachandranc@netlogicmicro.com>
      To: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/2534/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      39ad5680
    • J
      MIPS:Netlogic:Fix section mismatch warnings. · a74e3353
      Jayachandran C 提交于
      Add __init and __cpuinit annotation to functions that need it.
      Signed-off-by: NJayachandran C <jayachandranc@netlogicmicro.com>
      To: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/2535/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      a74e3353
    • R
      Revert "MIPS: LD/SD o32 macro GAS fix update" · b77bb37a
      Ralf Baechle 提交于
      This reverts commit 97475f8b42e83be2966aa2d70ab9c98477701c53 (lmo) /
      82b89152 (kernel.org) [MIPS: LD/SD o32
      macro GAS fix update].
      
      Turns out this patch is producing many build errors with gcc 4.2.  Based
      on further testing with a test case extracted from the build errors found
      further build errors and suboptimal generation even in violation of the
      "R" constraint.
      
      To make matters worse, the binutils changes also don't work quite as
      intended so revert this patch for now.
      b77bb37a
    • R
      MIPS: SNI: Fix conflicting wrapper symbols for headers. · dd5d1380
      Ralf Baechle 提交于
      If Open Firmware / Device Tree support is enabled on a SNI RM kernel both
      <asm/mipsprom.h> and <asm/prom.h> will be included into some .c files.
      Since both headers use the same wrapper symbol only the inclusion of the
      first file will have an effect but the 2nd file will be ignored resulting
      in a build error.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      dd5d1380
    • R
      MIPS: PNX8550: Fix section mismatch · cba2efb6
      Ralf Baechle 提交于
      Triggered by pnx8550-jbs_defconfig and pnx8550-stb810_defconfig:
      
      WARNING: vmlinux.o(.text+0xc0c): Section mismatch in reference from the function prom_getcmdline() to the variable .init.data:arcs_cmdline
      The function prom_getcmdline() references
      the variable __initdata arcs_cmdline.
      This is often because prom_getcmdline lacks a __initdata
      annotation or the annotation of arcs_cmdline is wrong.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      cba2efb6
    • R
      MIPS: 32-bit: Fix number of argument to epoll_wait. · 5db6acdb
      Ralf Baechle 提交于
      The number of arguments only matters for syscalls with stack arguments that
      is using 5 or more argument slots so this is just cosmetic fix.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      5db6acdb
    • R
      MIPS: IP27: Sort out section mismatch. · 901f6169
      Ralf Baechle 提交于
      WARNING: vmlinux.o(.text+0x3059f8): Section mismatch in reference from the function pcibios_plat_dev_init() to the function .devinit.text:request_bridge_irq()
      The function pcibios_plat_dev_init() references
      the function __devinit request_bridge_irq().
      This is often because pcibios_plat_dev_init lacks a __devinit
      annotation or the annotation of request_bridge_irq is wrong.
      
      Fixing this one leads to:
      
      WARNING: vmlinux.o(.text+0x1790): Section mismatch in reference from the function request_bridge_irq() to the function .devinit.text:register_bridge_irq()
      The function request_bridge_irq() references
      the function __devinit register_bridge_irq().
      This is often because request_bridge_irq lacks a __devinit
      annotation or the annotation of register_bridge_irq is wrong.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      901f6169
    • R
      MIPS: cache: Provide cache flush operations for XFS · d9cdc901
      Ralf Baechle 提交于
      Until now flush_kernel_vmap_range() and invalidate_kernel_vmap_range() did
      not exist on MIPS resulting in heavy cache corruption on XFS filesystems.
      
      Left for the post-3.0 time: optimization and make this work with highmem,
      too.  Since the combination of highmem + cache aliases atm doesn't work
      this isn't a regression.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      Patchwork: https://patchwork.linux-mips.org/patch/2505/
      d9cdc901
  3. 15 10月, 2011 3 次提交
  4. 14 10月, 2011 1 次提交
  5. 13 10月, 2011 1 次提交
  6. 11 10月, 2011 1 次提交
  7. 10 10月, 2011 1 次提交
  8. 07 10月, 2011 2 次提交
    • S
      ARM: mach-ux500: enable fix for ARM errata 754322 · 98e87d57
      srinidhi kasagar 提交于
      This applies ARM errata fix 754322 for all ux500 platforms.
      
      Cc: stable@kernel.org
      Signed-off-by: Nsrinidhi kasagar <srinidhi.kasagar@stericsson.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      98e87d57
    • P
      x86/PCI: use host bridge _CRS info on ASUS M2V-MX SE · 29cf7a30
      Paul Menzel 提交于
      In summary, this DMI quirk uses the _CRS info by default for the ASUS
      M2V-MX SE by turning on `pci=use_crs` and is similar to the quirk
      added by commit 2491762c ("x86/PCI: use host bridge _CRS info on
      ASRock ALiveSATA2-GLAN") whose commit message should be read for further
      information.
      
      Since commit 3e3da00c ("x86/pci: AMD one chain system to use pci
      read out res") Linux gives the following oops:
      
          parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
          HDA Intel 0000:20:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
          HDA Intel 0000:20:01.0: setting latency timer to 64
          BUG: unable to handle kernel paging request at ffffc90011c08000
          IP: [<ffffffffa0578402>] azx_probe+0x3ad/0x86b [snd_hda_intel]
          PGD 13781a067 PUD 13781b067 PMD 1300ba067 PTE 800000fd00000173
          Oops: 0009 [#1] SMP
          last sysfs file: /sys/module/snd_pcm/initstate
          CPU 0
          Modules linked in: snd_hda_intel(+) snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event tpm_tis tpm snd_seq tpm_bios psmouse parport_pc snd_timer snd_seq_device parport processor evdev snd i2c_viapro thermal_sys amd64_edac_mod k8temp i2c_core soundcore shpchp pcspkr serio_raw asus_atk0110 pci_hotplug edac_core button snd_page_alloc edac_mce_amd ext3 jbd mbcache sha256_generic cryptd aes_x86_64 aes_generic cbc dm_crypt dm_mod raid1 md_mod usbhid hid sg sd_mod crc_t10dif sr_mod cdrom ata_generic uhci_hcd sata_via pata_via libata ehci_hcd usbcore scsi_mod via_rhine mii nls_base [last unloaded: scsi_wait_scan]
          Pid: 1153, comm: work_for_cpu Not tainted 2.6.37-1-amd64 #1 M2V-MX SE/System Product Name
          RIP: 0010:[<ffffffffa0578402>]  [<ffffffffa0578402>] azx_probe+0x3ad/0x86b [snd_hda_intel]
          RSP: 0018:ffff88013153fe50  EFLAGS: 00010286
          RAX: ffffc90011c08000 RBX: ffff88013029ec00 RCX: 0000000000000006
          RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
          RBP: ffff88013341d000 R08: 0000000000000000 R09: 0000000000000040
          R10: 0000000000000286 R11: 0000000000003731 R12: ffff88013029c400
          R13: 0000000000000000 R14: 0000000000000000 R15: ffff88013341d090
          FS:  0000000000000000(0000) GS:ffff8800bfc00000(0000) knlGS:00000000f7610ab0
          CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
          CR2: ffffc90011c08000 CR3: 0000000132f57000 CR4: 00000000000006f0
          DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
          DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
          Process work_for_cpu (pid: 1153, threadinfo ffff88013153e000, task ffff8801303c86c0)
          Stack:
           0000000000000005 ffffffff8123ad65 00000000000136c0 ffff88013029c400
           ffff8801303c8998 ffff88013341d000 ffff88013341d090 ffff8801322d9dc8
           ffff88013341d208 0000000000000000 0000000000000000 ffffffff811ad232
          Call Trace:
           [<ffffffff8123ad65>] ? __pm_runtime_set_status+0x162/0x186
           [<ffffffff811ad232>] ? local_pci_probe+0x49/0x92
           [<ffffffff8105afc5>] ? do_work_for_cpu+0x0/0x1b
           [<ffffffff8105afc5>] ? do_work_for_cpu+0x0/0x1b
           [<ffffffff8105afd0>] ? do_work_for_cpu+0xb/0x1b
           [<ffffffff8105fd3f>] ? kthread+0x7a/0x82
           [<ffffffff8100a824>] ? kernel_thread_helper+0x4/0x10
           [<ffffffff8105fcc5>] ? kthread+0x0/0x82
           [<ffffffff8100a820>] ? kernel_thread_helper+0x0/0x10
          Code: f4 01 00 00 ef 31 f6 48 89 df e8 29 dd ff ff 85 c0 0f 88 2b 03 00 00 48 89 ef e8 b4 39 c3 e0 8b 7b 40 e8 fc 9d b1 e0 48 8b 43 38 <66> 8b 10 66 89 14 24 8b 43 14 83 e8 03 83 f8 01 77 32 31 d2 be
          RIP  [<ffffffffa0578402>] azx_probe+0x3ad/0x86b [snd_hda_intel]
           RSP <ffff88013153fe50>
          CR2: ffffc90011c08000
          ---[ end trace 8d1f3ebc136437fd ]---
      
      Trusting the ACPI _CRS information (`pci=use_crs`) fixes this problem.
      
          $ dmesg | grep -i crs # with the quirk
          PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
      
      The match has to be against the DMI board entries though since the vendor entries are not populated.
      
          DMI: System manufacturer System Product Name/M2V-MX SE, BIOS 0304    10/30/2007
      
      This quirk should be removed when `pci=use_crs` is enabled for machines
      from 2006 or earlier or some other solution is implemented.
      
      Using coreboot [1] with this board the problem does not exist but this
      quirk also does not affect it either. To be safe though the check is
      tightened to only take effect when the BIOS from American Megatrends is
      used.
      
              15:13 < ruik> but coreboot does not need that
              15:13 < ruik> because i have there only one root bus
              15:13 < ruik> the audio is behind a bridge
      
              $ sudo dmidecode
              BIOS Information
                      Vendor: American Megatrends Inc.
                      Version: 0304
                      Release Date: 10/30/2007
      
      [1] http://www.coreboot.org/
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=30552
      
      Cc: stable@kernel.org (2.6.34)
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: x86@kernel.org
      Signed-off-by: NPaul Menzel <paulepanter@users.sourceforge.net>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      29cf7a30
  9. 02 10月, 2011 2 次提交
  10. 01 10月, 2011 3 次提交
    • A
      ARM: OMAP: musb: Remove a redundant omap4430_phy_init call in usb_musb_init · b8e111a7
      Axel Lin 提交于
      Current code calls omap4430_phy_init() twice in usb_musb_init().
      Calling omap4430_phy_init() once is enough.
      This patch removes the first omap4430_phy_init() call, which using an
      uninitialized pointer as parameter.
      
      This patch elimates below build warning:
      arch/arm/mach-omap2/usb-musb.c: In function 'usb_musb_init':
      arch/arm/mach-omap2/usb-musb.c:141: warning: 'dev' may be used uninitialized in this function
      Signed-off-by: NAxel Lin <axel.lin@gmail.com>
      Bjarne Steinsbo <bsteinsbo@gmail.com>
      Acked-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      b8e111a7
    • T
      ARM: OMAP: Fix i2c init for twl4030 · bfd46a54
      Tony Lindgren 提交于
      Looks like 2600 kHz rate does not work reliably on 2430,
      so just use the 100 kHz rate.
      
      Otherwise the system often fails to boot properly with:
      
      omap_i2c omap_i2c.2: timeout waiting for bus ready
      omap_i2c omap_i2c.2: timeout waiting for bus ready
      twl: i2c_write failed to transfer all messages
      omap_i2c omap_i2c.2: timeout waiting for bus ready
      twl: i2c_write failed to transfer all messages
      omap_i2c omap_i2c.2: timeout waiting for bus ready
      twl: i2c_write failed to transfer all messages
      twl: clock init err [-110]
      omap_i2c omap_i2c.2: timeout waiting for bus ready
      twl: i2c_write failed to transfer all messages
      TWL4030 Unable to unlock IDCODE registers --110
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      bfd46a54
    • B
      ARM: OMAP4: MMC: fix power and audio issue, decouple USBC1 from MMC1 · 3696d303
      Bryan Buckley 提交于
      Remove OMAP4_USBC1_ICUSB_PWRDNZ_MASK during enable/disable PWRDNZ mode for
      MMC1_PBIAS and associated extended-drain MMC1 I/O cell. This is in accordance
      with the control module programming guide. This fixes a bug where if trying to
      use gpio_98 or gpio_99 and MMC1 at the same time the GPIO signal will be
      affected by a changing SDMMC1_VDDS.
      
      Software must keep MMC1_PBIAS cell and MMC1_IO cell PWRDNZ signals low whenever
      SDMMC1_VDDS ramps up/down or changes for cell protection purposes.
      
      MMC1 is based on SDMMC1_VDDS whereas USBC1 is based on SIM_VDDS therefore
      they can operate independently.
      Signed-off-by: NBryan Buckley <bryan.buckley@ti.com>
      Acked-by: NKishore Kadiyala <kishore.kadiyala@ti.com>
      Tested-by: NBalaji T K <balajitk@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      3696d303
  11. 30 9月, 2011 2 次提交
    • B
      powerpc: Fix device-tree matching for Apple U4 bridge · 16fa42af
      Benjamin Herrenschmidt 提交于
      Apple Quad G5 has some oddity in it's device-tree which causes the new
      generic matching code to fail to relate nodes for PCI-E devices below U4
      with their respective struct pci_dev.  This breaks graphics on those
      machines among others.
      
      This fixes it using a quirk which copies the node pointer from the host
      bridge for the root complex, which makes the generic code work for the
      children afterward.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      16fa42af
    • D
      sparc64: Force the execute bit in OpenFirmware's translation entries. · f4142cba
      David S. Miller 提交于
      In the OF 'translations' property, the template TTEs in the mappings
      never specify the executable bit.  This is the case even though some
      of these mappings are for OF's code segment.
      
      Therefore, we need to force the execute bit on in every mapping.
      
      This problem can only really trigger on Niagara/sun4v machines and the
      history behind this is a little complicated.
      
      Previous to sun4v, the sun4u TTE entries lacked a hardware execute
      permission bit.  So OF didn't have to ever worry about setting
      anything to handle executable pages.  Any valid TTE loaded into the
      I-TLB would be respected by the chip.
      
      But sun4v Niagara chips have a real hardware enforced executable bit
      in their TTEs.  So it has to be set or else the I-TLB throws an
      instruction access exception with type code 6 (protection violation).
      
      We've been extremely fortunate to not get bitten by this in the past.
      
      The best I can tell is that the OF's mappings for it's executable code
      were mapped using permanent locked mappings on sun4v in the past.
      Therefore, the fact that we didn't have the exec bit set in the OF
      translations we would use did not matter in practice.
      
      Thanks to Greg Onufer for helping me track this down.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f4142cba
  12. 27 9月, 2011 1 次提交