Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 16 3月, 2012 9 次提交
  3. 05 3月, 2012 2 次提交
    • A
      Merge tag 'tegra-boards' of... · 2eed4e7d
      由 Arnd Bergmann 提交于 
      Merge tag 'tegra-boards' of git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra into tegra/boards

Tegra board updates. Most of the board updates for tegra30 and for some
of the driver device-tree conversions have gone in through the other
branches, so that leaves quite little left here -- mostly a couple
of updates to the not-yet-converted tegra2 boards and a couple of
device-tree updates.

* tag 'tegra-boards' of git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra:
  ARM: tegra: match SoC name not board name in DT board files
  ARM: tegra: PCIe: Provide 3.3V supply voltage
  ARM: dt: tegra: add the wifi led to paz00 device tree
  ARM: dt: tegra: add the power gpio key to paz00 device tree
  ARM: dt: tegra: add ADT7461 temperature sensor to paz00 device tree
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      2eed4e7d
    • S
      ARM: tegra: match SoC name not board name in DT board files · c5444f39
      由 Stephen Warren 提交于 
      board-dt-tegra*.c should support any board using Tegra when booted using
device tree. Instead of explicitly listing all the supported boards,
which requires a kernel change for each new board, list the supported SoC
model instead.

Note that the board files do currently have explicit support for setting
up each board's pinmux. However, it's fairly likely that at least the
basic devices on any new board will work just fine as set up by the boot-
loader, and the pinmux data should be moving into device tree soon anyway.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>
      c5444f39
  5. 02 3月, 2012 9 次提交
  7. 01 3月, 2012 1 次提交
  9. 28 2月, 2012 9 次提交
  11. 27 2月, 2012 1 次提交
  13. 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
  15. 25 2月, 2012 5 次提交