Skip to content

L
linux-davinci
Switch branch/tag
  1. 24 Aug, 2009 1 commit
  3. 14 Jul, 2009 1 commit
  5. 26 Jun, 2009 2 commits
  7. 25 Jul, 2009 1 commit
  9. 21 Jul, 2009 1 commit
  11. 02 Sep, 2009 5 commits
  13. 14 Aug, 2009 5 commits
  15. 24 Aug, 2009 2 commits
  17. 31 Jul, 2009 3 commits
  19. 08 Sep, 2009 1 commit
    • Anton Vorontsov's avatar
      Convert the m25p80 driver so that now it uses .id_table for device · 37b89bfa
      Anton Vorontsov authored 
      matching, making it properly detect devices on OpenFirmware platforms
(prior to this patch the driver misdetected non-JEDEC chips, seeing all
chips as "m25p80").

Also, now jedec_probe() only does jedec probing, nothing else.  If it is
not able to detect a chip, NULL is returned and the driver fall backs to
the information specified by the platform (platform_data, or exact ID).
Signed-off-by: default avatarAnton Vorontsov <avorontsov@ru.mvista.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      37b89bfa
  21. 31 Jul, 2009 1 commit
    • Anton Vorontsov's avatar
      With this patch spi drivers can use standard spi_driver.id_table and · c50b748f
      Anton Vorontsov authored 
      MODULE_DEVICE_TABLE() mechanisms to bind against the devices.  Just like
we do with I2C drivers.

This is useful when a single driver supports several variants of devices
but it is not possible to detect them in run-time (like non-JEDEC chips
probing in drivers/mtd/devices/m25p80.c), and when platform_data usage is
overkill.

This patch also makes life a lot easier on OpenFirmware platforms, since
with OF we extensively use proper device IDs in modaliases.
Signed-off-by: default avatarAnton Vorontsov <avorontsov@ru.mvista.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      c50b748f
  23. 24 Jun, 2009 1 commit
  25. 23 Jul, 2009 1 commit
  27. 18 Jul, 2009 3 commits
  29. 24 Jun, 2009 1 commit
  31. 03 Sep, 2009 2 commits
  33. 25 Jul, 2009 1 commit
  35. 18 Jul, 2009 1 commit
  37. 09 Sep, 2009 1 commit
    • Roland McGrath's avatar
      In fs/binfmt_elf.c, load_elf_interp() calls padzero() for .bss even if the · 2e1a32d9
      Roland McGrath authored 
      PT_LOAD has no PROT_WRITE and no .bss.  This generates EFAULT.

Here is a small test case.  (Yes, there are other, useful PT_INTERP which
have only .text and no .data/.bss.)

	----- ptinterp.S
	_start: .globl _start
		 nop
		 int3
	-----
	$ gcc -m32 -nostartfiles -nostdlib -o ptinterp ptinterp.S
	$ gcc -m32 -Wl,--dynamic-linker=ptinterp -o hello hello.c
	$ ./hello
	Segmentation fault  # during execve() itself

	After applying the patch:
	$ ./hello
	Trace trap  # user-mode execution after execve() finishes

If the ELF headers are actually self-inconsistent, then dying is fine. 
But having no PROT_WRITE segment is perfectly normal and correct if there
is no segment with p_memsz > p_filesz (i.e.  bss).  John Reiser suggested
checking for PROT_WRITE in the bss logic.  I think it makes most sense to
simply apply the bss logic only when there is bss.

This patch looks less trivial than it is due to some reindentation.  It
just moves the "if (last_bss > elf_bss) {" test up to include the
partial-page bss logic as well as the more-pages bss logic.
Reported-by: default avatarJohn Reiser <jreiser@bitwagon.com>
Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: James Morris <jmorris@namei.org>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      2e1a32d9
  39. 03 Sep, 2009 1 commit
  41. 05 Sep, 2009 1 commit
  43. 03 Sep, 2009 4 commits
    • KAMEZAWA Hiroyuki's avatar
      Benjamin Herrenschmidt <benh@kernel.crashing.org> pointed out that vmemmap · 715f10e2
      KAMEZAWA Hiroyuki authored 
      range is not included in KCORE_RAM, KCORE_VMALLOC ....

This adds KCORE_VMEMMAP if SPARSEMEM_VMEMMAP is used.  By this, vmemmap
can be readable via /proc/kcore

Because it's not vmalloc area, vread/vwrite cannot be used.  But the range
is static against the memory layout, this patch handles vmemmap area by
the same scheme with physical memory.

This patch assumes SPARSEMEM_VMEMMAP range is not in VMALLOC range.  It's
correct now.
Signed-off-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Jiri Slaby <jirislaby@gmail.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      715f10e2
    • KAMEZAWA Hiroyuki's avatar
      For /proc/kcore, each arch registers its memory range by kclist_add(). · e5d7d433
      KAMEZAWA Hiroyuki authored 
      In usual,

	- range of physical memory
	- range of vmalloc area
	- text, etc...

are registered but "range of physical memory" has some troubles.  It
doesn't updated at memory hotplug and it tend to include unnecessary
memory holes.  Now, /proc/iomem (kernel/resource.c) includes required
physical memory range information and it's properly updated at memory
hotplug.  Then, it's good to avoid using its own code(duplicating
information) and to rebuild kclist for physical memory based on
/proc/iomem.
Signed-off-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: default avatarJiri Slaby <jirislaby@gmail.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      e5d7d433
    • KAMEZAWA Hiroyuki's avatar
      Originally, walk_memory_resource() was introduced to traverse all memory · d8890008
      KAMEZAWA Hiroyuki authored 
      of "System RAM" for detecting memory hotplug/unplug range.  For doing so,
flags of IORESOUCE_MEM|IORESOURCE_BUSY was used and this was enough for
memory hotplug.

But for using other purpose, /proc/kcore, this may includes some firmware
area marked as IORESOURCE_BUSY | IORESOUCE_MEM.  This patch makes the
check strict to find out busy "System RAM".

Note: PPC64 keeps their own walk_memory_resouce(), which walk through
ppc64's lmb informaton.  Because old kclist_add() is called per lmb, this
patch makes no difference in behavior, finally.

And this patch removes CONFIG_MEMORY_HOTPLUG check from this function. 
Because pfn_valid() just show "there is memmap or not* and cannot be used
for "there is physical memory or not", this function is useful in generic
to scan physical memory range.
Signed-off-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      d8890008
    • KAMEZAWA Hiroyuki's avatar
      Some 64bit arch has special segment for mapping kernel text. It should be · 5794ed50
      KAMEZAWA Hiroyuki authored 
      entried to /proc/kcore in addtion to direct-linear-map, vmalloc area. 
This patch unifies KCORE_TEXT entry scattered under x86 and ia64.

I'm not familiar with other archs (mips has its own even after this patch)
but range of [_stext ..._end) is a valid area of text and it's not in
direct-map area, defining CONFIG_ARCH_PROC_KCORE_TEXT is only a necessary
thing to do.

Note: I left mips as it is now.
Signed-off-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      5794ed50