Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 24 8月, 2009 1 次提交
  3. 11 8月, 2009 3 次提交
  5. 07 7月, 2009 1 次提交
  7. 09 6月, 2009 13 次提交
  9. 23 5月, 2009 1 次提交
  11. 22 5月, 2009 1 次提交
  13. 21 5月, 2009 1 次提交
  15. 24 4月, 2009 1 次提交
    • N
      [ARM] 5460/1: Orion: reduce namespace pollution · fdd8b079
      由 Nicolas Pitre 提交于 
      Symbols like SOFT_RESET are way too generic to be exported at large.
To avoid this, let's move the mbus bridge register defines into a
separate file and include it where needed.  This affects mach-kirkwood,
mach-loki, mach-mv78xx0 and mach-orion5x simultaneously as they all
share code in plat-orion which relies on those defines.

Some other defines have been moved to narrower scopes, or simply deleted
when they had no user.

This fixes compilation problem with mpt2sas on the above listed
platforms.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      fdd8b079
  17. 07 4月, 2009 2 次提交
  19. 24 3月, 2009 3 次提交
  21. 22 3月, 2009 1 次提交
    • L
      dsa: add switch chip cascading support · e84665c9
      由 Lennert Buytenhek 提交于 
      The initial version of the DSA driver only supported a single switch
chip per network interface, while DSA-capable switch chips can be
interconnected to form a tree of switch chips.  This patch adds support
for multiple switch chips on a network interface.

An example topology for a 16-port device with an embedded CPU is as
follows:

	+-----+          +--------+       +--------+
	|     |eth0    10| switch |9    10| switch |
	| CPU +----------+        +-------+        |
	|     |          | chip 0 |       | chip 1 |
	+-----+          +---++---+       +---++---+
	                     ||               ||
	                     ||               ||
	                     ||1000baseT      ||1000baseT
	                     ||ports 1-8      ||ports 9-16

This requires a couple of interdependent changes in the DSA layer:

- The dsa platform driver data needs to be extended: there is still
  only one netdevice per DSA driver instance (eth0 in the example
  above), but each of the switch chips in the tree needs its own
  mii_bus device pointer, MII management bus address, and port name
  array. (include/net/dsa.h)  The existing in-tree dsa users need
  some small changes to deal with this. (arch/arm)

- The DSA and Ethertype DSA tagging modules need to be extended to
  use the DSA device ID field on receive and demultiplex the packet
  accordingly, and fill in the DSA device ID field on transmit
  according to which switch chip the packet is heading to.
  (net/dsa/tag_{dsa,edsa}.c)

- The concept of "CPU port", which is the switch chip port that the
  CPU is connected to (port 10 on switch chip 0 in the example), needs
  to be extended with the concept of "upstream port", which is the
  port on the switch chip that will bring us one hop closer to the CPU
  (port 10 for both switch chips in the example above).

- The dsa platform data needs to specify which ports on which switch
  chips are links to other switch chips, so that we can enable DSA
  tagging mode on them.  (For inter-switch links, we always use
  non-EtherType DSA tagging, since it has lower overhead.  The CPU
  link uses dsa or edsa tagging depending on what the 'root' switch
  chip supports.)  This is done by specifying "dsa" for the given
  port in the port array.

- The dsa platform data needs to be extended with information on via
  which port to reach any given switch chip from any given switch chip.
  This info is specified via the per-switch chip data struct ->rtable[]
  array, which gives the nexthop ports for each of the other switches
  in the tree.

For the example topology above, the dsa platform data would look
something like this:

	static struct dsa_chip_data sw[2] = {
		{
			.mii_bus	= &foo,
			.sw_addr	= 1,
			.port_names[0]	= "p1",
			.port_names[1]	= "p2",
			.port_names[2]	= "p3",
			.port_names[3]	= "p4",
			.port_names[4]	= "p5",
			.port_names[5]	= "p6",
			.port_names[6]	= "p7",
			.port_names[7]	= "p8",
			.port_names[9]	= "dsa",
			.port_names[10]	= "cpu",
			.rtable		= (s8 []){ -1, 9, },
		}, {
			.mii_bus	= &foo,
			.sw_addr	= 2,
			.port_names[0]	= "p9",
			.port_names[1]	= "p10",
			.port_names[2]	= "p11",
			.port_names[3]	= "p12",
			.port_names[4]	= "p13",
			.port_names[5]	= "p14",
			.port_names[6]	= "p15",
			.port_names[7]	= "p16",
			.port_names[10]	= "dsa",
			.rtable		= (s8 []){ 10, -1, },
		},
	},

	static struct dsa_platform_data pd = {
		.netdev		= &foo,
		.nr_switches	= 2,
		.sw		= sw,
	};
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Tested-by: NGary Thomas <gary@mlbassoc.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e84665c9
  23. 20 3月, 2009 1 次提交
    • R
      [ARM] pass reboot command line to arch_reset() · be093beb
      由 Russell King 提交于 
      OMAP wishes to pass state to the boot loader upon reboot in order to
instruct it whether to wait for USB-based reflashing or not.  There is
already a facility to do this via the reboot() syscall, except we ignore
the string passed to machine_restart().

This patch fixes things to pass this string to arch_reset().  This means
that we keep the reboot mode limited to telling the kernel _how_ to
perform the reboot which should be independent of what we request the
boot loader to do.
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      be093beb
  25. 16 3月, 2009 3 次提交
  27. 27 2月, 2009 4 次提交
  29. 20 2月, 2009 2 次提交
  31. 18 2月, 2009 1 次提交
    • N
      [ARM] 5401/1: Orion: fix edge triggered GPIO interrupt support · fd4b9b36
      由 Nicolas Pitre 提交于 
      The GPIO interrupts can be configured as either level triggered or edge
triggered, with a default of level triggered.  When an edge triggered
interrupt is requested, the gpio_irq_set_type method is called which
currently switches the given IRQ descriptor between two struct irq_chip
instances: orion_gpio_irq_level_chip and orion_gpio_irq_edge_chip. This
happens via __setup_irq() which also calls irq_chip_set_defaults() to
assign default methods to uninitialized ones.  The problem is that
irq_chip_set_defaults() is called before the irq_chip reference is
switched, leaving the new irq_chip (orion_gpio_irq_edge_chip in this
case) with uninitialized methods such as chip->startup() causing a kernel
oops.

Many solutions are possible, such as making irq_chip_set_defaults() global
and calling it from gpio_irq_set_type(), or calling __irq_set_trigger()
before irq_chip_set_defaults() in __setup_irq().  But those require
modifications to the generic IRQ code which might have adverse effect on
other architectures, and that would still be a fragile arrangement.
Manually copying the missing methods from within gpio_irq_set_type()
would be really ugly and it would break again the day new methods with
automatic defaults are added.

A better solution is to have a single irq_chip instance which can deal
with both edge and level triggered interrupts.  It is also a good idea
to switch the IRQ handler instead, as the edge IRQ handler allows for
one edge IRQ event to be queued as the IRQ is actually masked only when
that second IRQ is received, at which point the hardware can queue an
additional IRQ event, making edge triggered interrupts a bit more
reliable.
Tested-by: NMartin Michlmayr <tbm@cyrius.com>
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      fd4b9b36
  33. 09 1月, 2009 1 次提交