Sparc driver changes afoot for 2.6.18

Sparc driver changes afoot for 2.6.18

[David Miller]

In the following tree:

	kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6.git

are some interesting changes for Sparc land.

Finally the SBUS, EBUS, ISA, etc. drivers can plug into the
generic device subsystem of the Linux kernel properly.

This means that there are proper device ID tables in the
SBUS driver modules and therefore things like UDEV should
be able to auto-load SBUS modules.

I converted most of the SBUS drivers.  All the networking and SCSI
SBUS drivers are converted.  There are some odds and ends left such as
the FC4 drivers but those are only half working anyways.

Unconverted drivers should still work as well as they did before the
new code, they just use the older interfaces and won't integrate with
the generic device subsystem.

I tested as much as I could on sparc64 and I tried hard not to
break things on sparc32 but I was not able to test things there.

Those changes should show up in Linus's tree in the next day or
so too.

If some sparc32 folks get a chance to test and help fix any
regressions, that would be really appreciated.

When it works you'll get device nodes under /sys/bus/{ebus,isa,sbus}/
and things like that.  It's pretty easy to convert the probing code
in an SBUS driver to the new stuff, and the documentation has even
been updated in Documentation/sparc/sbus_drivers.txt.  One can look
at one of the converted drivers as well for hints.

The main thing to watch for when testing on sparc32 is the build of
the in-kernel copy of the OBP device tree.  This is done right after
paging_init() is done, by calling
arch/sparc/kernel/prom.c:prom_build_devicetree().

If you get a hang early on in the boot process, it's probably
happening in there, or in sbus_init().

Notice there are no ugly ifdefs in drivers/sbus/sbus.c any longer :)
We can probably make sbus_init() a subsys_initcall() instead of
explicitly calling it from the sparc ports.

In fact there are a ton of cleanups and fixes possible with this
new stuff. :-)

In fact if some sparc32 person gets inspired, it's easy to convert
code that runs after prom_build_devicetree() to use the in-kernel
device tree for OBP device tree probing.  All of this kind of code
is very idiomatic and thus easy to convert:

	old				new


	prom_root_node			dp = of_find_node_by_path("/");

	len = prom_getproperty()	val = of_get_property(dp, "name", &len)
	val = prom_getint_default()	val = of_getintprop_default()
	nd = prom_getchild(x)		nd = x->child
	nd = prom_getsibling(x)		nd = x->sibling

You can find each OBP node with a given name using:

	for_each_node_by_name(dp, "the_name") {
	}

You can do the same for each OBP with a given "device_type" property
value:

	for_each_node_by_type(dp, "the_type") {
	}

If you have an old-style OBP node handle integer, you can get the
in-kernel device node pointer using:

	dp = of_find_node_by_phandle(prom_node);

You can see if a certain string is listed in a device node's
"compatible" property string list:

	if (of_device_is_compatible(dp, "compat_value"))

The new stuff is a lot more flexible, and also more streamlined since
no OBP firmware calls are made to do any of this stuff.  You don't
need to allocate local buffers, on the stack or dynamically, to get
property values either, as they are already in-kernel.

If you want to have a local copy, to make modifications such as to
adjust a reg property with ranges values, you do still need to
allocate some space to do that.  You can't make changes to the
in-kernel OBP tree copies of the properties! :-)

Re: Sparc driver changes afoot for 2.6.18

[Dennis Jenkins]

I converted most of the SBUS drivers.  All the networking and SCSI
SBUS drivers are converted.  There are some odds and ends left such as
the FC4 drivers but those are only half working anyways.


 Hello David,
 
     Exciting stuff.  I appreciate all of the work that you are doing.  Just wanted to let you know.
 
     I'm still hoping for FC4 !  My E3500's 144G (8 x 18.2G) fiber channel raid array is completely useless under Linux.  To run Linux on the box, I attached an 18.2G drive to some scsi chain in the back..
 
     Do you think that it is realistic that the FC4 stuff will ever work well enough that it is safe to use for "home use"?
 
     If you would like any testing, please let me know.  I haven't fired up my sun box in ages, but I could power it up, update my gentoo and grab a new kernel on a few days notice.  I don't leave it run 24/7, since it can heat my house in the winter, and it's summer right now ;)
 
 

Re: Sparc driver changes afoot for 2.6.18

[David Miller]

From: Dennis Jenkins <dennis.jenkins@sbcglobal.net>
Date: Sat, 24 Jun 2006 22:44:09 -0700 (PDT)

>      I'm still hoping for FC4 !  My E3500's 144G (8 x 18.2G) fiber
>  channel raid array is completely useless under Linux.  To run Linux
>  on the box, I attached an 18.2G drive to some scsi chain in the
>  back..  Do you think that it is realistic that the FC4 stuff will
>  ever work well enough that it is safe to use for "home use"?

Not any time soon, no, sorry.

My efforts aren't going to make that situation any better, nor
worse.

Re: Sparc driver changes afoot for 2.6.18

[Bob Breuer]

I just got around to testing these changes on sparc32 with 2.6.18-rc1,
and it dies early on.


BUG: warning at /usr/src/linux-2.6-git/lib/kref.c:32/kref_get()
[f01058c4 : get_bus+0x1c/0x40 ]
[f0105f7c : bus_add_driver+0xc/0x13c ]
[f0106fa8 : driver_register+0xb0/0xb8 ]
[f01e2358 : unpack_to_rootfs+0x434/0x958 ]
[f01dae2c : _etext+0x5b78c/0x5c958 ]
[f01da790 : _etext+0x5b0f0/0x5c958 ]
[00000000 : 0x8 ]
BUG: warning at /usr/src/linux-2.6-git/lib/kref.c:32/kref_get()
[f00cb870 : kobject_init+0x40/0x68 ]
[f00cbc28 : kobject_register+0x18/0x44 ]
[f0105fc4 : bus_add_driver+0x54/0x13c ]
[f0106fa8 : driver_register+0xb0/0xb8 ]
[f01e2358 : unpack_to_rootfs+0x434/0x958 ]
[f01dae2c : _etext+0x5b78c/0x5c958 ]
[f01da790 : _etext+0x5b0f0/0x5c958 ]
[00000000 : 0x8 ]
Unable to handle kernel NULL pointer dereference
tsk->{mm,active_mm}->context = ffffffff
tsk->{mm,active_mm}->pgd = fc000000
              \|/ ____ \|/
              "@'/ ,. \`@"
              /_| \__/ |_\
                 \__U_/
swapper(0): Oops [#1]
PSR: 1e001fc1 PC: f00cbb6c NPC: f00cbb70 Y: 00000000    Not tainted
PC: <kobject_add+0x138/0x1dc>
%G: 0000000a f01ad054  f01acaf4 00000000  f0030b90 f01ad400  f000e000
0000000
%O: f01ad05c 00000001  00000035 ffffffff  0000000a fffffff8  f000fd20
f00cbbd0
RPC: <kobject_add+0x19c/0x1dc>
%L: f01acad8 f01acaf0  f01ad05c f01b2400  f01acadc 00000000  00000003
00000000
%I: f01acad8 000000d0  f0185dba f000fe40  00000001 0000022e  f000fd88
f00cbc30
Caller[f00cbc30]: kobject_register+0x20/0x44
Caller[f0105fc4]: bus_add_driver+0x54/0x13c
Caller[f0106fa8]: driver_register+0xb0/0xb8
Caller[f01e2358]: unpack_to_rootfs+0x434/0x958
Caller[f01dae2c]: _etext+0x5b78c/0x5c958
Caller[f01da790]: _etext+0x5b0f0/0x5c958
Caller[00000000]: 0x8
Instruction DUMP: c6006004  c224201c  c4206004 <c420c000> 10bfffc6
c620a004  80a26000  b0102000  22bfffdd
Kernel panic - not syncing: Attempted to kill the idle task!
 <0>Press Stop-A (L1-A) to return to the boot prom


The last part from ksymoops:

>>PC;  f00cbb6c <kobject_add+130/1dc>   <==Trace; f00cbc30 <kobject_register+18/44>
Trace; f0105fc4 <bus_add_driver+4c/13c>
Trace; f0106fa8 <driver_register+a8/b8>
Trace; f01e2358 <sbus_time_init+38/1b4>
Trace; f01dae2c <start_kernel+154/2b8>
Trace; f01da790 <sun4c_continue_boot+314/324>
Trace; 00000000 Before first symbol
Code;  f00cbb60 <kobject_add+124/1dc>
00000000 <_PC>:
Code;  f00cbb60 <kobject_add+124/1dc>
   0:   c6 00 60 04       ld  [ %g1 + 4 ], %g3
Code;  f00cbb64 <kobject_add+128/1dc>
   4:   c2 24 20 1c       st  %g1, [ %l0 + 0x1c ]
Code;  f00cbb68 <kobject_add+12c/1dc>
   8:   c4 20 60 04       st  %g2, [ %g1 + 4 ]
Code;  f00cbb6c <kobject_add+130/1dc>   <==   c:   c4 20 c0 00       st  %g2, [ %g3 ]   <==Code;  f00cbb70 <kobject_add+134/1dc>
  10:   10 bf ff c6       b  ffffff28 <_PC+0xffffff28>
Code;  f00cbb74 <kobject_add+138/1dc>
  14:   c6 20 a0 04       st  %g3, [ %g2 + 4 ]
Code;  f00cbb78 <kobject_add+13c/1dc>
  18:   80 a2 60 00       cmp  %o1, 0
Code;  f00cbb7c <kobject_add+140/1dc>
  1c:   b0 10 20 00       clr  %i0
Code;  f00cbb80 <kobject_add+144/1dc>
  20:   22 bf ff dd       be,a   ffffff94 <_PC+0xffffff94>


I'll keep looking at it and try to figure out where the NULL pointer
came from.

Bob

Re: Sparc driver changes afoot for 2.6.18

[David Miller]

From: Bob Breuer <breuerr@mc.net>
Date: Sat, 08 Jul 2006 14:29:07 -0500

> I just got around to testing these changes on sparc32 with 2.6.18-rc1,
> and it dies early on.
 ...
> I'll keep looking at it and try to figure out where the NULL pointer
> came from.

Thanks bob for testing.

In another email Raymond Burns notes that clock_probe() is invoked
too early.  This may be related to your problem.

Re: Sparc driver changes afoot for 2.6.18

[Bob Breuer]

David Miller wrote:
> In another email Raymond Burns notes that clock_probe() is invoked
> too early.  This may be related to your problem.

Yes, it's the same problem.  After getting around that problem, I've now
hit another potential problem.  Multiple instances of a device don't
seem to be uniquely identified.


kobject_add failed for zs with -EEXIST, don't try to register things
with the same name in the same directory.
[f001badc : of_device_register+0x20/0x60 ] [f01e30d8 :
sun4c_init_IRQ+0xcc/0x1e8 ] [f01e3348 : sun4d_init_sbi_irq+0x6c/0xd0 ]
[f01e335c : sun4d_init_sbi_irq+0x80/0xd0 ] [f01e33dc :
sun4d_init_IRQ+0x30/0xfc ] [f0010108 : init+0x94/0x330 ] [f0014ef4 :
kernel_thread+0x3c/0x50 ] [f0010010 : rest_init+0x18/0x2c ]
/obio/zs: Could not register of device.

kobject_add failed for Ross,RT626 with -EEXIST, don't try to register
things with the same name in the same directory.
[f001badc : of_device_register+0x20/0x60 ] [f01e30d8 :
sun4c_init_IRQ+0xcc/0x1e8 ] [f01e3348 : sun4d_init_sbi_irq+0x6c/0xd0 ]
[f01e33dc : sun4d_init_IRQ+0x30/0xfc ] [f0010108 : init+0x94/0x330 ]
[f0014ef4 : kernel_thread+0x3c/0x50 ] [f0010010 : rest_init+0x18/0x2c ]
/Ross,RT626: Could not register of device.