[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <431dacd9-bda0-7a0b-3280-e27d01030c01@wanadoo.fr>
Date: Tue, 30 Aug 2022 18:49:22 +0200
From: Christophe JAILLET <christophe.jaillet@...adoo.fr>
To: Benjamin Tissoires <benjamin.tissoires@...hat.com>,
Jiri Kosina <jikos@...nel.org>
Cc: lkml <linux-kernel@...r.kernel.org>,
kernel-janitors@...r.kernel.org,
"open list:HID CORE LAYER" <linux-input@...r.kernel.org>
Subject: Re: [PATCH] HID: cp2112: Remove some dead code
Le 30/08/2022 à 13:56, Benjamin Tissoires a écrit :
> On Thu, Aug 25, 2022 at 11:26 AM Jiri Kosina <jikos@...nel.org> wrote:
>>
>> On Sat, 18 Jun 2022, Christophe JAILLET wrote:
>>
>>> Commit 13de9cca514e ("HID: cp2112: add IRQ chip handling") has introduced
>>> cp2112_allocate_irq() that seems to be unused since 2016.
>>>
>>> Remove it, remove the associated resources and part of the remove()
>>> function that frees the resources allocated in cp2112_allocate_irq().
>>>
>>> Signed-off-by: Christophe JAILLET <christophe.jaillet@...adoo.fr>
>>> ---
>>> Compile tested only.
>>>
>>> Maybe the issue is completely elsewhere and the probe() should call
>>> cp2112_allocate_irq() in some cases.
>>
>> Benjamin, could you please take a look? Apparently you were aware of the
>> code being dead due to the __maybe_unused annotation ... :) What was the
>> point?
>>
>
> Looks like I kept that code around for the CI I am running on HID patches.
>
> IIRC, I left the code in the tree because it might have been useful to
> others when they need to declare IRQs on the board. So yes, it is
> entirely dead code upstream :/
>
> I am applying the following 3 patches on the current master tree to be
> able to declare hid-cp2112 as an i2c-hid transport:
> https://gitlab.freedesktop.org/bentiss/gitlab-kernel-ci/-/tree/master/VM
>
> Those 3 patches can not be upstreamed because platform drivers are a
> dead thing, but I have no other ideas on how I can declare an i2c-hid
> device on top of hid-cp2112. Given that we don't have DT on x86_64
> vm, I can not rely on that to have my custom sensor (or maybe I can
> but I am not aware of it).
>
> So unless anybody has a better idea, I won't fight against removing
> that code, but it's more convenient for me to have it.
>
> Cheers,
> Benjamin
>
This was just a clean-up patch. I personally don't really care if
applied or not.
So, from my POV if it helps, it can stay.
On the other side, I guess that it could also easily become another
patch in your serie.
Do what is best.
CJ
Powered by blists - more mailing lists