linux.git/arch/mips, branch v2.6.35 Linux kernel source tree MIPS: Set io_map_base for several PCI bridges lacking it 2010-07-26T18:08:19+00:00 Ben Hutchings ben@decadent.org.uk 2010-06-13T21:22:59+00:00 8faf2e6c201d95b780cd3b4674b7a55ede6dcbbb Several MIPS platforms don't set pci_controller::io_map_base for their PCI bridges. This results in a panic in pci_iomap(). (The panic is conditional on CONFIG_PCI_DOMAINS, but that is now enabled for all PCI MIPS systems.) Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Cc: linux-mips@linux-mips.org Cc: Martin Michlmayr <tbm@cyrius.com> Cc: Aurelien Jarno <aurelien@aurel32.net> Cc: 584784@bugs.debian.org Patchwork: https://patchwork.linux-mips.org/patch/1377/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> 
Several MIPS platforms don't set pci_controller::io_map_base for their
PCI bridges.  This results in a panic in pci_iomap().  (The panic is
conditional on CONFIG_PCI_DOMAINS, but that is now enabled for all PCI
MIPS systems.)

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: linux-mips@linux-mips.org
Cc: Martin Michlmayr <tbm@cyrius.com>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: 584784@bugs.debian.org
Patchwork: https://patchwork.linux-mips.org/patch/1377/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: Alchemy: Define eth platform devices in the correct order 2010-07-26T18:08:19+00:00 Wolfgang Grandegger wg@denx.de 2010-07-17T14:38:48+00:00 0d5977d652fa5fd4e9a56127b109e5e28d4db95d Currently, the eth devices are probed in the inverse order, first au1xxx_eth1_device and then au1xxx_eth0_device. On the GPR board, this makes trouble: # ifconfig|grep HWaddr eth0 Link encap:Ethernet HWaddr 00:50:C2:0C:30:01 eth1 Link encap:Ethernet HWaddr 66:22:01:80:38:10 A bogous ethernet hwaddr is assigned to the first device and au1xxx_eth0_device is mapped to eth1, which even does not work properly. With this patch, the problems are gone: # ifconfig|grep HWaddr eth0 Link encap:Ethernet HWaddr 66:22:11:32:38:10 eth1 Link encap:Ethernet HWaddr 66:22:11:32:38:11 Signed-off-by: Wolfgang Grandegger <wg@denx.de> To: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/1473/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> 
Currently, the eth devices are probed in the inverse order, first
au1xxx_eth1_device and then au1xxx_eth0_device. On the GPR board,
this makes trouble:

  # ifconfig|grep HWaddr
  eth0      Link encap:Ethernet  HWaddr 00:50:C2:0C:30:01
  eth1      Link encap:Ethernet  HWaddr 66:22:01:80:38:10

A bogous ethernet hwaddr is assigned to the first device and
au1xxx_eth0_device is mapped to eth1, which even does not work
properly. With this patch, the problems are gone:

  # ifconfig|grep HWaddr
  eth0      Link encap:Ethernet  HWaddr 66:22:11:32:38:10
  eth1      Link encap:Ethernet  HWaddr 66:22:11:32:38:11

Signed-off-by: Wolfgang Grandegger <wg@denx.de>
To: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/1473/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: BCM63xx: Prevent second enet registration on BCM6338 2010-07-26T18:08:18+00:00 Florian Fainelli florian@openwrt.org 2010-07-21T20:59:26+00:00 7f13f65e61f1deed77c5c335ed0fa4d08f69e608 This SoC has only one ethernet MAC, so prevent registration of a second one. Signed-off-by: Florian Fainelli <florian@openwrt.org> To: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/1482/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> 
This SoC has only one ethernet MAC, so prevent registration of a second one.

Signed-off-by: Florian Fainelli <florian@openwrt.org>
To: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/1482/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: Quit using undefined behavior of ADDU in 64-bit atomic operations. 2010-07-26T18:08:18+00:00 David Daney ddaney@caviumnetworks.com 2010-07-22T18:59:27+00:00 f2a68272d799bf4092443357142f63b74f7669a1 For 64-bit, we must use DADDU and DSUBU. Signed-off-by: David Daney <ddaney@caviumnetworks.com> To: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/1483/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> 
For 64-bit, we must use DADDU and DSUBU.

Signed-off-by: David Daney <ddaney@caviumnetworks.com>
To: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/1483/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: N32: Define getdents64. 2010-07-26T18:08:17+00:00 Ralf Baechle ralf@linux-mips.org 2010-07-22T01:20:25+00:00 31c984a5acabea5d8c7224dc226453022be46f33 As a relativly new ABI N32 should only have received the getdents64(2) but instead it only had getdents(2). This was noticed as a performance anomaly in glibc. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> 
As a relativly new ABI N32 should only have received the getdents64(2) but
instead it only had getdents(2).  This was noticed as a performance anomaly
in glibc.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: MTX-1: Fix PCI on the MeshCube and related boards 2010-07-26T18:08:17+00:00 Bruno Randolf randolf.bruno@googlemail.com 2010-07-11T15:40:28+00:00 98a0f86a54bb195c28ae1ccb5a5f5cda12cf7121 This patch fixes a regression introduced by commit "MIPS: Alchemy: MTX-1: Use linux gpio api." (bb706b28bbd647c2fd7f22d6bf03a18b9552be05) which broke PCI bus operation. The problem is caused by alchemy_gpio2_enable() which resets the GPIO2 block. Two PCI signals (PCI_SERR and PCI_RST) are connected to GPIO2 and they obviously do not to like the reset. Since GPIO2 is correctly initialized by the boot monitor (YAMON) it is not necessary to call this function, so just remove it. Also replace gpio_set_value() with alchemy_gpio_set_value() to avoid problems in case gpiolib gets initialized after PCI. And since alchemy gpio_set_value() calls au_sync() we don't have to au_sync() again later. Signed-off-by: Bruno Randolf <br1@einfach.org> To: linux-mips@linux-mips.org To: manuel.lauss@googlemail.com Patchwork: https://patchwork.linux-mips.org/patch/1448/ Tested-by: Florian Fainelli <florian@openwrt.org> Signed-off-by: Ralf Baechle <ralf@linux-mips.org> 
This patch fixes a regression introduced by commit "MIPS: Alchemy: MTX-1:
Use linux gpio api." (bb706b28bbd647c2fd7f22d6bf03a18b9552be05) which broke
PCI bus operation. The problem is caused by alchemy_gpio2_enable() which
resets the GPIO2 block. Two PCI signals (PCI_SERR and PCI_RST) are connected
to GPIO2 and they obviously do not to like the reset. Since GPIO2 is
correctly initialized by the boot monitor (YAMON) it is not necessary to
call this function, so just remove it.

Also replace gpio_set_value() with alchemy_gpio_set_value() to avoid
problems in case gpiolib gets initialized after PCI. And since alchemy
gpio_set_value() calls au_sync() we don't have to au_sync() again later.

Signed-off-by: Bruno Randolf <br1@einfach.org>
To: linux-mips@linux-mips.org
To: manuel.lauss@googlemail.com
Patchwork: https://patchwork.linux-mips.org/patch/1448/
Tested-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: Make init_vdso a subsys_initcall. 2010-07-26T18:08:16+00:00 David Daney ddaney@caviumnetworks.com 2010-06-16T22:00:28+00:00 1ed845375b1f2938acc4496a186e180892b00c71 Quoting from Jiri Slaby's patch of a similar nature for x86: When initrd is in use and a driver does request_module() in its module_init (i.e. __initcall or device_initcall), a modprobe process is created with VDSO mapping. But VDSO is inited even in __initcall, i.e. on the same level (at the same time), so it may not be inited yet (link order matters). Move init_vdso up to subsys_initcall to avoid the issue. Signed-off-by: David Daney <ddaney@caviumnetworks.com> To: linux-mips@linux-mips.org Cc: David Daney <ddaney@caviumnetworks.com> Cc: Jiri Slaby <jslaby@suse.cz> Patchwork: http://patchwork.linux-mips.org/patch/1386/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> 
Quoting from Jiri Slaby's patch of a similar nature for x86:

    When initrd is in use and a driver does request_module() in its
    module_init (i.e. __initcall or device_initcall), a modprobe
    process is created with VDSO mapping. But VDSO is inited even in
    __initcall, i.e. on the same level (at the same time), so it may
    not be inited yet (link order matters).

Move init_vdso up to subsys_initcall to avoid the issue.

Signed-off-by: David Daney <ddaney@caviumnetworks.com>
To: linux-mips@linux-mips.org
Cc: David Daney <ddaney@caviumnetworks.com>
Cc: Jiri Slaby <jslaby@suse.cz>
Patchwork: http://patchwork.linux-mips.org/patch/1386/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: "Fix" useless 'init_vdso successfully' message. 2010-07-26T18:08:16+00:00 David Daney ddaney@caviumnetworks.com 2010-06-16T22:00:27+00:00 57d15018aa48ecc5fafef3374dcebcf0bbbfa764 In addition to being useless, it was mis-spelled. Signed-off-by: David Daney <ddaney@caviumnetworks.com> To: linux-mips@linux-mips.org Cc: David Daney <ddaney@caviumnetworks.com> Patchwork: http://patchwork.linux-mips.org/patch/1385/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> 
In addition to being useless, it was mis-spelled.

Signed-off-by: David Daney <ddaney@caviumnetworks.com>
To: linux-mips@linux-mips.org
Cc: David Daney <ddaney@caviumnetworks.com>
Patchwork: http://patchwork.linux-mips.org/patch/1385/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: PowerTV: Move register setup to before reading registers. 2010-07-26T18:08:16+00:00 David VomLehn dvomlehn@cisco.com 2010-06-18T23:51:49+00:00 28d7d213a1ba4f1891eebb680f8a16a731d7a72a The 4600 family code reads registers to differentiate between two ASIC variants, but this was being done prior to the register setup. This moves register setup before the reading code. Signed-off-by: David VomLehn <dvomlehn@cisco.com> To: linux-mips@linux-mips.org Patchwork: http://patchwork.linux-mips.org/patch/1392/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> 
The 4600 family code reads registers to differentiate between two ASIC
variants, but this was being done prior to the register setup. This moves
register setup before the reading code.

Signed-off-by: David VomLehn <dvomlehn@cisco.com>
To: linux-mips@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/1392/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: Return after handling coprocessor 2 exception 2010-07-05T16:17:33+00:00 Jesper Nilsson jesper@jni.nu 2010-06-17T13:25:54+00:00 55dc9d51a89ba10a1f7b3ed15f1262eb83e87e74 Breaking here dropped us to the default code which always sends a SIGILL to the current process, no matter what the CU2 notifier says. [Ralf: Currently this only hurts on Cavium and possibly some out of tree platforms.] Signed-off-by: Jesper Nilsson <jesper@jni.nu> To: linux-mips@linux-mips.org To: linux-kernel@vger.kernel.org Patchwork: http://patchwork.linux-mips.org/patch/1391/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org> 
Breaking here dropped us to the default code which always sends a SIGILL
to the current process, no matter what the CU2 notifier says.

[Ralf: Currently this only hurts on Cavium and possibly some out of tree
platforms.]

Signed-off-by: Jesper Nilsson <jesper@jni.nu>
To: linux-mips@linux-mips.org
To: linux-kernel@vger.kernel.org
Patchwork: http://patchwork.linux-mips.org/patch/1391/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>