[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080530160505.GA12722@cosmic.amd.com>
Date: Fri, 30 May 2008 10:05:05 -0600
From: Jordan Crouse <jordan.crouse@....com>
To: David Brigada <brigad@....edu>
Cc: Ingo Molnar <mingo@...e.hu>, Wim Van Sebroeck <wim@...ana.be>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Samuel Tardieu <sam@...1149.net>,
Mike Frysinger <vapier.adi@...il.com>,
Mingarelli@...omag.amd.com
Subject: Re: drivers/watchdog/geodewdt.c: build fix
On 30/05/08 11:54 -0400, David Brigada wrote:
> I was trying to compile a kernel with this support, and noticed this bug,
> too. The interface was changed in commit
> fa28e067c3b8af96c79c060e163b1387c172ae75, with the message:
>
> > We had planned to use the 'owner' field for allowing re-allocation of
> > MFGPTs; however, doing it by module owner name isn't flexible enough. >
> So, drop this for now. If it turns out that we need timers in
> > modules, we'll need to come up with a scheme that matches the
> > write-once fields of the MFGPTx_SETUP register, and drops ponies from >
> the sky.
>
> I may be reading this incorrectly, but it seems that to do this correctly,
> we would either need to drop module support for this driver or rework the
> MFGPT code. I'm not sure there's a kernel hook for dropping ponies from
> the sky quite yet.
I think the hamster dropping code is queued for 2.6.27, so at least we're
up to mammals.
The story here is that in an unfortunate instance of bad planning the
MFGPT timers can only be configured once, so a module can't allocate a
timer at init and release it when it is done. The original object of this
code was to try give the timer back to a module if it happened to go away
and come back, but that is clearly a more complex process then just simply
storing the module name, and this code fell into bitrot.
So its not so much that we need to drop module support, rather it needs to
be understood that if you remove and insert your module on a regular basis
you will run out of timers, and deprive others of the timers too. I think
that is a reasonable restriction to impose, given the limited usefulness
of these timers for general purpose use.
Jordan
> Jordan Crouse wrote:
>> On 30/05/08 17:02 +0200, Ingo Molnar wrote:
>>> * Wim Van Sebroeck <wim@...ana.be> wrote:
>>>
>>>> Author: Jordan Crouse <jordan.crouse@....com>
>>>> Date: Mon Jan 21 10:07:00 2008 -0700
>>>>
>>>> [WATCHDOG] Add a watchdog driver based on the CS5535/CS5536 MFGPT
>>>> timers
>>> -tip testing found the following build failure on latest -git:
>>>
>>> drivers/watchdog/geodewdt.c: In function 'geodewdt_probe':
>>> drivers/watchdog/geodewdt.c:225: error: too many arguments to function
>>> 'geode_mfgpt_alloc_timer'
>>> make[1]: *** [drivers/watchdog/geodewdt.o] Error 1
>>> make: *** [drivers/watchdog/geodewdt.o] Error 2
>>>
>>> with this config:
>>>
>>> http://redhat.com/~mingo/misc/config-Fri_May_30_15_19_52_CEST_2008.bad
>>>
>>> find the fix below.
>>>
>>> Signed-off-by: Ingo Molnar <mingo@...e.hu>
>> Acked-by: Jordan Crouse <jordan.crouse@....com>
>>> ---
>>> drivers/watchdog/geodewdt.c | 3 +--
>>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> Index: tip/drivers/watchdog/geodewdt.c
>>> ===================================================================
>>> --- tip.orig/drivers/watchdog/geodewdt.c
>>> +++ tip/drivers/watchdog/geodewdt.c
>>> @@ -221,8 +221,7 @@ geodewdt_probe(struct platform_device *d
>>> {
>>> int ret, timer;
>>> - timer = geode_mfgpt_alloc_timer(MFGPT_TIMER_ANY,
>>> - MFGPT_DOMAIN_WORKING, THIS_MODULE);
>>> + timer = geode_mfgpt_alloc_timer(MFGPT_TIMER_ANY, MFGPT_DOMAIN_WORKING);
>>> if (timer == -1) {
>>> printk(KERN_ERR "geodewdt: No timers were available\n");
>>>
>
>
--
Jordan Crouse
Systems Software Development Engineer
Advanced Micro Devices, Inc.
--
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