linux-kernel - Re: [PATCH 1/5] [media] ir-rx51: port to rc-core

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 30 Dec 2016 15:50:42 +0200
From:   Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>
To:     Sean Young <sean@...s.org>
Cc:     linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
        Timo Kokkonen <timo.t.kokkonen@....fi>,
        Pavel Machek <pavel@....cz>,
        Pali Rohár <pali.rohar@...il.com>
Subject: Re: [PATCH 1/5] [media] ir-rx51: port to rc-core



On 30.12.2016 15:30, Sean Young wrote:
>
> On Fri, Dec 30, 2016 at 01:07:52PM +0000, Sean Young wrote:
>> Hi Ivo,,
>>
>> On Fri, Dec 30, 2016 at 01:30:01PM +0200, Ivaylo Dimitrov wrote:
>>> On 20.12.2016 19:50, Sean Young wrote:
>>>> This driver was written using lirc since rc-core did not support
>>>> transmitter-only hardware at that time. Now that it does, port
>>>> this driver.
>>>>
>>>> Compile tested only.
>>>>
>>>
>>> I guess after that change, there will be no more /dev/lircN device, right?
>>> Neither will LIRC_XXX IOCTL codes be supported?
>>
>> Quite the opposite, /dev/lircN and all the LIRC_XXX ioctls will still be
>> supported through ir-lirc-codec.c.
>>
>> By using rc-core, the driver will be more succinct, and some latent bugs
>> will be fixed. For example, at the moment it is possible to write hours
>> of IR data and keep the n900 from suspending.
>>
>> I'm working on lirc scancode sending and receiving using the IR encoders,
>> and when that is in place, any rc-core driver will get it for free.
>>
>>> That looks to me as a completely new driver, not a port to new API.
>>>
>>> Right now there are applications using the current behaviour (pierogi for
>>> example), which will be broken by the change.
>>
>> Nothing should break.
>
> Speaking of which, if you would please test this, that would be great. My
> N900 died many years ago.
>

Will do, but next year :) .

Thanks,
Ivo