public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: linux-media@vger.kernel.org
Subject: Re: [PATCH 2/2] media: rc: improve lirc module detection
Date: Thu, 3 Dec 2015 20:03:20 +0100	[thread overview]
Message-ID: <566091F8.9030300@gmail.com> (raw)
In-Reply-To: <20151203150828.5ebdc89b@recife.lan>

Am 03.12.2015 um 18:08 schrieb Mauro Carvalho Chehab:
> Em Sat, 21 Nov 2015 16:30:56 +0100
> Heiner Kallweit <hkallweit1@gmail.com> escreveu:
> 
>> Improve detection whether lirc codec is loaded and avoid dependency
>> on config symbols and having to check for a specific module.
>>
>> This also fixes the bug that the current check checks for module
>> lirc_dev instead of ir_lirc_codec (which depends on lirc_dev).
>> If the ir_lirc_codec module is unloaded the check would still
>> return OK.
>>
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>> ---
>>  drivers/media/rc/ir-lirc-codec.c |  4 ++++
>>  drivers/media/rc/rc-main.c       | 19 +++++--------------
>>  2 files changed, 9 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
>> index a32659f..7fc5b3f 100644
>> --- a/drivers/media/rc/ir-lirc-codec.c
>> +++ b/drivers/media/rc/ir-lirc-codec.c
>> @@ -22,6 +22,8 @@
>>  
>>  #define LIRCBUF_SIZE 256
>>  
>> +extern atomic_t ir_raw_lirc_available;
>> +
> 
> No, this is not good, due to several reasons:
> 
> - it lacks an EXPORT_SYMBOL_GPL(ir_raw_lirc_available);
> - if lirc module is not compiled, the RC core will have a missed
>   symbol.
> 
> The right thing to do is to have a var inside the RC core and a
> way for LIRC to tell the core that it was loaded.
> 
IMHO that's actually the case.
The var is defined in rc_main.c and also exported from there.
Your comment is at the position where the variable is declared as "extern"
in the (potential) lirc module.

> I would prefer to not export a var. So, perhaps this could be
> done by calling some function.
> 
Sure, we could define the var static and add a public setter.
Would you prefer this?

> Anyway, the way the patch is, it will break compilation, depending
> on the config options.
> 
> Regards,
> Mauro
> 
Rgds, Heiner
> 
>>  /**
>>   * ir_lirc_decode() - Send raw IR data to lirc_dev to be relayed to the
>>   *		      lircd userspace daemon for decoding.
>> @@ -398,6 +400,7 @@ static int ir_lirc_register(struct rc_dev *dev)
>>  
>>  	dev->raw->lirc.drv = drv;
>>  	dev->raw->lirc.dev = dev;
>> +	atomic_set(&ir_raw_lirc_available, 1);
>>  	return 0;
>>  
>>  lirc_register_failed:
>> @@ -413,6 +416,7 @@ static int ir_lirc_unregister(struct rc_dev *dev)
>>  {
>>  	struct lirc_codec *lirc = &dev->raw->lirc;
>>  
>> +	atomic_set(&ir_raw_lirc_available, 0);
>>  	lirc_unregister_driver(lirc->drv->minor);
>>  	lirc_buffer_free(lirc->drv->rbuf);
>>  	kfree(lirc->drv);
>> diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
>> index 1042fa3..0bd11b4 100644
>> --- a/drivers/media/rc/rc-main.c
>> +++ b/drivers/media/rc/rc-main.c
>> @@ -829,21 +829,12 @@ struct rc_filter_attribute {
>>  		.mask = (_mask),					\
>>  	}
>>  
>> -static bool lirc_is_present(void)
>> +atomic_t ir_raw_lirc_available = ATOMIC_INIT(0);
>> +EXPORT_SYMBOL(ir_raw_lirc_available);
>> +
>> +static inline bool lirc_is_present(void)
>>  {
>> -#if defined(CONFIG_LIRC_MODULE)
>> -	struct module *lirc;
>> -
>> -	mutex_lock(&module_mutex);
>> -	lirc = find_module("lirc_dev");
>> -	mutex_unlock(&module_mutex);
>> -
>> -	return lirc ? true : false;
>> -#elif defined(CONFIG_LIRC)
>> -	return true;
>> -#else
>> -	return false;
>> -#endif
>> +	return atomic_read(&ir_raw_lirc_available) != 0;
>>  }
>>  
>>  /**
> 


      reply	other threads:[~2015-12-03 19:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-21 15:30 [PATCH 2/2] media: rc: improve lirc module detection Heiner Kallweit
2015-12-03 17:08 ` Mauro Carvalho Chehab
2015-12-03 19:03   ` Heiner Kallweit [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=566091F8.9030300@gmail.com \
    --to=hkallweit1@gmail.com \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@osg.samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox