1. 01 3月, 2012 1 次提交
    • A
      Merge branch 'cleanup' of... · a26d3c4f
      Arnd Bergmann 提交于
      Merge branch 'cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/cleanup
      
      * 'cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
        ARM: OMAP2+: Fix L4_EMU_34XX_BASE error after iomap changes
        ARM: OMAP2+: Limit omap_read/write usage to legacy USB drivers
        ARM: OMAP: Remove plat/io.h by splitting it into mach/io.h and mach/hardware.h
        ARM: OMAP2+: Move most of plat/io.h into local iomap.h
        ARM: OMAP1: Move most of plat/io.h into local iomap.h
        ARM: OMAP1: Move 16xx GPIO system clock to platform init code
        ARM: OMAP: Move omap_init_consistent_dma_size() to local common.h
        ARM: OMAP2+: Move SDRC related functions from io.h into local common.h
        ARM: OMAP2+: Drop DISPC L3 firewall code
        ARM: OMAP2xxx: PM: remove obsolete timer disable code in the suspend path
        ARM: OMAP: McSPI: Remove unused flag from struct omap2_mcspi_device_config
      
      (update to latest rmk/for-arm-soc branch)
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      a26d3c4f
  2. 29 2月, 2012 2 次提交
  3. 28 2月, 2012 3 次提交
  4. 27 2月, 2012 6 次提交
  5. 26 2月, 2012 4 次提交
    • L
      Linux 3.3-rc5 · 6b21d18e
      Linus Torvalds 提交于
      6b21d18e
    • L
      Merge tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging · 00b10ecf
      Linus Torvalds 提交于
      Couple of minor driver fixes.
      
      * tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
        hwmon: (max34440) Fix resetting temperature history
        hwmon: (f75375s) Fix register write order when setting fans to full speed
        hwmon: (ads1015) Fix file leak in probe function
        hwmon: (max6639) Fix PPR register initialization to set both channels
        hwmon: (max6639) Fix FAN_FROM_REG calculation
      00b10ecf
    • L
      Merge branch 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild · 1e73fde5
      Linus Torvalds 提交于
      three kbuild fixes for 3.3:
       - make deb-pkg symlink race fix.
       - make coccicheck fix.
       - Dropping the check for modutils.  This is not a regression, but
         allows the module-init-tools replacement kmod work with the 3.3
         kernel.
      
      * 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
        coccicheck: change handling of C={1,2} when M= is set
        builddeb: Don't create files in /tmp with predictable names
        kbuild: do not check for ancient modutils tools
      1e73fde5
    • I
      autofs: work around unhappy compat problem on x86-64 · a32744d4
      Ian Kent 提交于
      When the autofs protocol version 5 packet type was added in commit
      5c0a32fc ("autofs4: add new packet type for v5 communications"), it
      obvously tried quite hard to be word-size agnostic, and uses explicitly
      sized fields that are all correctly aligned.
      
      However, with the final "char name[NAME_MAX+1]" array at the end, the
      actual size of the structure ends up being not very well defined:
      because the struct isn't marked 'packed', doing a "sizeof()" on it will
      align the size of the struct up to the biggest alignment of the members
      it has.
      
      And despite all the members being the same, the alignment of them is
      different: a "__u64" has 4-byte alignment on x86-32, but native 8-byte
      alignment on x86-64.  And while 'NAME_MAX+1' ends up being a nice round
      number (256), the name[] array starts out a 4-byte aligned.
      
      End result: the "packed" size of the structure is 300 bytes: 4-byte, but
      not 8-byte aligned.
      
      As a result, despite all the fields being in the same place on all
      architectures, sizeof() will round up that size to 304 bytes on
      architectures that have 8-byte alignment for u64.
      
      Note that this is *not* a problem for 32-bit compat mode on POWER, since
      there __u64 is 8-byte aligned even in 32-bit mode.  But on x86, 32-bit
      and 64-bit alignment is different for 64-bit entities, and as a result
      the structure that has exactly the same layout has different sizes.
      
      So on x86-64, but no other architecture, we will just subtract 4 from
      the size of the structure when running in a compat task.  That way we
      will write the properly sized packet that user mode expects.
      
      Not pretty.  Sadly, this very subtle, and unnecessary, size difference
      has been encoded in user space that wants to read packets of *exactly*
      the right size, and will refuse to touch anything else.
      Reported-and-tested-by: NThomas Meyer <thomas@m3y3r.de>
      Signed-off-by: NIan Kent <raven@themaw.net>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a32744d4
  6. 25 2月, 2012 24 次提交