mediabay hotswap, tun naming patches (2.4)

Greetings.

It's been a while.  Got a few patches that have been languishing in my system for too long.

One changes the mediabay ide_register call to an explicit call to the pmac_ide call that it needs, at least on a wallstreet.  Without this, an ide mediabay cannot be inserted post-boot.

The second patch changes the behavior of the tun device so that devices are not required to have a numerical value after their name.  I have yet to figure out how to tell MOL to assign a numerical value and pass tun a % like the kernel wants.  Just made it so that if there is no numerical value, then that tun device is the only one of its kind.  ( "mol" = one iface, while mol% = many ifaces, (or maybe "mol0" and "mol1" are explicit different ones, not same as "mol%" ifaces.)).  I suppose would be unnessesary/undesired when MOL gets updated to support ___% registration. (or i figure out how to use it :)

Thanks.

PS, I still use my wallstreet, and haven't found out why adb crashes.  rtc and nvram also appear to break at that moment, but pmu (battery support, etc) is fine.  still not sure if its a pure software issue or if hardware got confused.

--
Joseph P. Garcia
http://www.lycestra.com/

It's been a while.  Got a few patches that have been languishing in my
system for too long.

One changes the mediabay ide_register call to an explicit call to the
pmac_ide call that it needs, at least on a wallstreet.  Without this, an
ide mediabay cannot be inserted post-boot.

Thanks.

The second patch changes the behavior of the tun device so that devices
are not required to have a numerical value after their name.  I have yet
to figure out how to tell MOL to assign a numerical value and pass tun a
% like the kernel wants.  Just made it so that if there is no numerical
value, then that tun device is the only one of its kind.  ( "mol" = one
iface, while mol% = many ifaces, (or maybe "mol0" and "mol1" are explicit
different ones, not same as "mol%" ifaces.)).  I suppose would be
unnessesary/undesired when MOL gets updated to support ___% registration.
(or i figure out how to use it :)

Could you send this to the tun driver maintainer ?

Thanks.

PS, I still use my wallstreet, and haven't found out why adb crashes.
rtc and nvram also appear to break at that moment, but pmu (battery
support, etc) is fine.  still not sure if its a pure software issue or if
hardware got confused.

rtc and nvram are broken too ? that's weird. Can you try disabling the
battery polling stuff in via-pmu.c to see if it's causing the problem ?
(comment out the calls to query_battery_state())

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

One changes the mediabay ide_register call to an explicit call to the
pmac_ide call that it needs, at least on a wallstreet.  Without this, an
ide mediabay cannot be inserted post-boot.

I don't fully understand your patch here. What you do is exactly what
ide_register() does, I see no difference between what your patch does
and what the unpatched code does.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Sun, 20 Jan 2002 21:21:21 +0100
Benjamin Herrenschmidt [off-list ref] wrote:

I don't fully understand your patch here. What you do is exactly what
ide_register() does, I see no difference between what your patch does
and what the unpatched code does.

ide_register() calls the arch's preferred init_hwif_ports.  Until recently, we could set this according to ppc platform using a member of the ppc_md (IIRC) structure.  This member was eliminated.  When we had it, at one point it was changed to have a generic (PC?) init_hwif_ports rather than the pmac one that mediabay needed.  I rack this up to possibly people forgetting that some systems have hot swap, but no matter.  The assumption that the member stood for was that differing platforms /needed/ a custom call, which is not true.  There are a few chips on startup and only media bays in runtime that need it.  They are the exception, not the rule.  (PCMCIA i think needs the generic call)  Basically, I think that any old ide hardware driver should be able to call ide_register, and anyone who is unique hardware must work only a little harder to call their proper unique function.

Basically, ide_register() is for normal IDE interfaces, and that is just more correct for other drivers to be able to assume that.  We need to explicitly handle unique hardware than to assume that uniqueness is the norm.  all IDE busses are found at boot and those that need it are handled with the pmac function explicitly rather than relying on ide_register() anyway.

--
Joseph P. Garcia
http://www.lycestra.com/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

ide_register() calls the arch's preferred init_hwif_ports.  Until
recently, we could set this according to ppc platform using a member of
the ppc_md (IIRC) structure.  This member was eliminated.  When we had
it, at one point it was changed to have a generic (PC?) init_hwif_ports
rather than the pmac one that mediabay needed.  I rack this up to
possibly people forgetting that some systems have hot swap, but no
matter.  The assumption that the member stood for was that differing
platforms /needed/ a custom call, which is not true.  There are a few
chips on startup and only media bays in runtime that need it.  They are
the exception, not the rule.  (PCMCIA i think needs the generic call)
Basically, I think that any old ide hardware driver should be able to
call ide_register, and anyone who is unique hardware must work only a
little harder to call their proper unique function.

I just noticed that change in _devel, it will cause problems with
ide_unregister() as well. I have to check what the best fix is, I
beleive ide-pmac should override the still-existing ppc_md. hook
when inited. The generic function will set wrong pointers, but those
will be overriden by the platform-specific one installed by ide-pmac.

Not pretty but should work.

Also, doing it from within ide-pmac will probably help toward making
ide-pmac moduleable ;)

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Sun, 20 Jan 2002 22:02:34 +0100
Benjamin Herrenschmidt [off-list ref] wrote:

Also, doing it from within ide-pmac will probably help toward making
ide-pmac moduleable ;)

Ok.  I see that now.  My bad.  There is new structure in BK devel's asm/ide.h called ppc_ide_md that has all these things.  platforms/pmac_setup.c sets the functions that it defines itself.  So in following that, ide_pmac.c should do that in an init or probe call (and clear it in mod_cleanup when that is implemented).

add a 'ppc_ide_md.ide_init_hwif=pmac_ide_init_hwif_ports' at the end of the probe in ide-pmac.c and hotswap works again.

--
Joseph P. Garcia
http://www.lycestra.com/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/