Message-Id: <BD8F08D3-871B-45CF-B588-489E09ADA70C@kayser.net>
Date:	Fri, 9 Oct 2009 10:49:24 -0500
From:	Donald Kayser <linux@...ser.net>
To:	linuxppc-dev@...abs.org, linuxkernel <linux-kernel@...r.kernel.org>
Subject: Re: ppc_md.SMI replacement for 2.6

I have more information on this PPC HPPB target. I compared the  
EXCEPTION macro between 2.4 and 2.6 with respect to SMI Exceptions. I  
noticed that in the 2.4 kernel a macro named STD_EXCEPTION was used  
and in the 2.6 kernel their is a new EXCEPTION macro structure. In the  
2.6 kernel, it is much different, but with the TAUException I noticed  
that it used an EXC_XFER_STD instead of EXC_XFER_EE, so I tried it and  
with great news, I am actually getting the exceptions correctly now.

My question to anyone who understands is: is it OK to change the line  
in arch/powerpc/kernel/head_32.S from

EXCEPTION(0x1400, SMI, SMIException, EXC_XFER_EE)

to

EXCEPTION(0x1400, SMI, SMIException, EXC_XFER_STD)

I have not decoded assembler to determine the exact differences, and I  
will do so, but I wanted to know if there was anyone who knew why this  
would make my SMI interrupt behave correctly.

Also, as noted earlier in this post, there is no hook for notification  
of the SMI. The vendor who did the 2.4 port provided his own hook  
through ppc_md global variable. Would anyone care to suggest the 'best/ 
preferred' method to provide a callback to the SMI Exception.

Thanks
Donald
linux@...ser.net

On Oct 9, 2009, at 8:50 AM, Arnd Bergmann wrote:

> On Friday 09 October 2009, Donald Kayser wrote:
>> On further comparison, this section of code has been added by the
>> vendor that actually ported linux 2.4 to this PPC HPPB target. So, if
>> anyone would like to lend a thought towards System Managment
>> Exceptions on PPC, please cc me at linux@...ser.net. I will be
>> stopping the subscription to this list shortly. Regards, Donald
>
> Hi Donald,
>
> You should ask ppc specific questions on the linuxppc-dev@...abs.org
> mailing list instead of the global linux-kernel list to increase the
> chances of someone reading it who knows the answer.
>
> The world of powerpc linux has changed a lot since 2.4, as you
> undoubtedly found out. You are certainly encouraged to submit
> your platform code for inclusion in the mainline kernel (if you
> can do the usual cleanups necessary to do that), even for
> old code.
>
> I don't know a specific reason why the SMI callback was removed,
> but I would guess that if you have a platform that requires it
> and want it in the mainline kernel, a callback for it can be
> added back, either through ppc_md or some other method.
>
> 	Arnd <><
>
>> On Oct 8, 2009, at 8:37 AM, Donald Kayser wrote:
>>
>>> I have found the differences between the 2.4 and 2.6 kernel. It is
>>> in linux-2.4/arch/ppc/kernel/traps.c and linux-2.6/arch/powerpc/
>>> kernel/traps.c in the function SMIException(). There is no longer
>>> the code segment
>>>
>>> if (ppc_md.SMI)
>>> {
>>> ppc_md.SMI(regs);
>>> return;
>>> }
>>>
>>> There is now only a
>>>
>>> die("System Management Interrupt", regs, SIGABRT);
>>>
>>> I am guessing that the SMI callback is no longer needed by the linux
>>> community at large, so I modified the code for my specific hardware
>>> (HPPB) and acknowledged the exception as in the 2.4 kernel, and
>>> returned from the exception without the call to die(). My problem
>>> now is that it doesn't seem to work. Does anyone have a reason why
>>> the SMI exception might hang the system when it has been provided a
>>> handler?
>>>
>>> Thanks in advance.
>>>
>>> Donald Kayser
>>>
>>> On Oct 7, 2009, at 10:06 AM, Donald Kayser wrote:
>>>
>>>> I have ported the 2.6 kernel to an embedded PPC target (old stuff).
>>>> I have managed to figure everything out, but can't find any
>>>> replacement for a SMI handler. The original 2.4 version for this
>>>> target has a bit of code ppc_md.SMI == SmiFuncHandler; I have not
>>>> been able to find in the current source anything like this. I am
>>>> not certain that I need to provide a handler at all, but the
>>>> original developers saw some reason for including it. The
>>>> particular handler does not do anything more than cancel a watchdog
>>>> listener for this specific target. I have been living without the
>>>> handler, but would like to find any kind of replacement if it is
>>>> supported.
>>>>
>>>> Thanks,
>>>> Donald Kayser
>>>> linux@...ser.net
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists