All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Härdeman" <david@hardeman.nu>
To: Tomas Melin <tomas.melin@iki.fi>
Cc: LKML <linux-kernel@vger.kernel.org>,
	linux-media@vger.kernel.org, james.hogan@imgtec.com,
	"Antti Seppälä" <a.seppala@gmail.com>,
	"Александр Берсенев" <bay@hackerdom.ru>,
	"Mauro Carvalho Chehab" <m.chehab@samsung.com>,
	tomas.j.melin@gmail.com
Subject: Re: [PATCH v2 1/2] [media] rc-core: fix protocol_change regression in ir_raw_event_register
Date: Tue, 28 Oct 2014 09:42:30 +0100	[thread overview]
Message-ID: <f308d753cb68dc6afbfe4360c1bd4404@hardeman.nu> (raw)
In-Reply-To: <CACraW2pZnOnjj4iXoAN4A23efWVoL4ZjFXvXiS4ktxZ5YYEz9Q@mail.gmail.com>

On 2014-10-26 20:33, Tomas Melin wrote:
> On Sat, Oct 25, 2014 at 12:03 PM, David Härdeman <david@hardeman.nu> 
> wrote:
>> Wouldn't something like this be a simpler way of achieving the same
>> result? (untested):
> 
> The idea was to remove the empty change_protocol function that had
> been added in the breaking commit.

The empty function was added for a reason? The presence of a 
change_protocol function implies that the receiver supports protocol 
changing (whether it's via the raw IR decoding or in hardware).

> IMHO, it would be better to not have functions that don't do anything.
> Actually, another problem with that empty function is that if the
> driver first sets up a "real" change_protocol function and related
> data, and then calls rc_register_device, the driver defined
> change_protocol function would be overwritten.

change_protocol is only set if it's a driver that does in-kernel 
decoding...meaning that it generates pulse/space timings...meaning that 
hardware protocol changes aren't necessary?

>> diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
>> index a7991c7..d521f20 100644
>> --- a/drivers/media/rc/rc-main.c
>> +++ b/drivers/media/rc/rc-main.c
>> @@ -1421,6 +1421,9 @@ int rc_register_device(struct rc_dev *dev)
>> 
>>         if (dev->change_protocol) {
>>                 u64 rc_type = (1 << rc_map->rc_type);
>> +               if (dev->driver_type == RC_DRIVER_IR_RAW)
>> +                       rc_type |= RC_BIT_LIRC;
>> +
>>                 rc = dev->change_protocol(dev, &rc_type);
>>                 if (rc < 0)
>>                         goto out_raw;
> 
> But otherwise yes, your suggestion could work, with the addition that
> we still need to update enabled_protocols (and not init
> enabled_protocols anymore in ir_raw_event_register() ).

First, enabled_protocols is already taken care of in the above patch 
(the line after "goto out_raw" is "dev->enabled_protocols = rc_type;")?

Second, initializing enabled_protocols to some default in 
ir_raw_event_register() might not be strictly necessary but it also 
doesn't hurt since that happens before dev->change_protocol() is called 
in rc_register_device()?

> +               dev->enabled_protocols = (rc_type | RC_BIT_LIRC);
> 
> Please let me know your preferences on which you prefer, and, if
> needed, I'll make a new patch version.

I'd prefer the above, minimal, approach. But it's Mauro who decides in 
the end.

Regards,
David


  reply	other threads:[~2014-10-28  8:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-21 18:30 [PATCH v2 1/2] [media] rc-core: fix protocol_change regression in ir_raw_event_register Tomas Melin
2014-10-21 18:30 ` [PATCH v2 2/2] [media] rc-core: change enabled_protocol default setting Tomas Melin
2014-10-25  9:03 ` [PATCH v2 1/2] [media] rc-core: fix protocol_change regression in ir_raw_event_register David Härdeman
2014-10-26 19:33   ` Tomas Melin
2014-10-28  8:42     ` David Härdeman [this message]
2014-10-28 18:36       ` Tomas Melin

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=f308d753cb68dc6afbfe4360c1bd4404@hardeman.nu \
    --to=david@hardeman.nu \
    --cc=a.seppala@gmail.com \
    --cc=bay@hackerdom.ru \
    --cc=james.hogan@imgtec.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=m.chehab@samsung.com \
    --cc=tomas.j.melin@gmail.com \
    --cc=tomas.melin@iki.fi \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.