[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4818F4EE.8050004@linuxtv.org>
Date: Wed, 30 Apr 2008 18:38:38 -0400
From: mkrufky@...uxtv.org
To: xyzzy@...akeasy.org
Cc: akpm@...ux-foundation.org, sfr@...b.auug.org.au,
video4linux-list@...hat.com, torvalds@...ux-foundation.org,
efault@....de, linux-kernel@...r.kernel.org, mchehab@...radead.org,
linux-dvb-maintainer@...uxtv.org, mingo@...e.hu, sam@...nborg.org,
davem@...emloft.net
Subject: Re: [v4l-dvb-maintainer] [patch, -git] drivers/media build fix fo
r modular builds
Trent Piepho wrote:
> On Wed, 30 Apr 2008, Andrew Morton wrote:
>
>> Does this make it feel better?
>>
>> --- a/drivers/media/video/tuner-core.c~a
>> +++ a/drivers/media/video/tuner-core.c
>> @@ -40,11 +40,11 @@
>> typeof(&FUNCTION) __a = symbol_request(FUNCTION); \
>> if (__a) { \
>> __r = (int) __a(ARGS); \
>> + symbol_put(FUNCTION); \
>> } else { \
>> printk(KERN_ERR "TUNER: Unable to find " \
>> "symbol "#FUNCTION"()\n"); \
>> } \
>> - symbol_put(FUNCTION); \
>> __r; \
>> })
>>
>
> Should the symbol_put be done at all? When I wrote the code this is based
> on, it would check if FUNCTION failed or not. If it failed, the symbol
was
> put. But if it worked, then one was returned a handle into FUNCTION's
> module, and so the symbol was not put. If it was, the module's refcount
> would be zero but the caller would have a handle into the module.
>
> So if FUNCTION does anything that creates references to the module, and it
> doesn't inc it's own refcount, then the symbol_put shouldn't be done.
>
>
Trent,
The symbol_put is correct in this case. This macro above is called
"tuner_symbol_probe" , used only within tuner-core.c
This macro is used to call the probe function of a tuner sub-module
(tea5761, tea5767, tda8290). Regardless of whether the probe succeeds
or fails, we do the symbol_put. If the probe succeeds, tuner-core will
proceed to dvb_attach(that_tuner_attach, params), which does the actual
module use count increase.
Regards,
Mike
--
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