[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170307081558.GB1805@ozzy.nask.waw.pl>
Date: Tue, 7 Mar 2017 09:15:58 +0100
From: Michał Kępień <kernel@...pniu.pl>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>,
linux-input <linux-input@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] Input: sparse-keymap - use a managed allocation for
keymap copy
> On Mon, Mar 6, 2017 at 9:09 AM, Michał Kępień <kernel@...pniu.pl> wrote:
> >> On Thu, Mar 2, 2017 at 2:02 PM, Michał Kępień <kernel@...pniu.pl> wrote:
>
> >> > + * Since sparse_keymap_setup() now uses a managed allocation for the
> >> > + * keymap copy, use of this function is deprecated.
> >>
> >> So...
> >>
> >> > */
> >> > void sparse_keymap_free(struct input_dev *dev)
> >>
> >> ... add __deprecated then?
> >
> > Sure, I can do that if Dmitry recognizes this patch as otherwise sane.
> > I have never used that attribute before, so thanks for the tip.
>
> It will provoke a warning when compiling the code.
> It makes sense if anyone is going to fix the current users and leave
> old API for one cycle.
>
> So, the question is what we are going to do with an old API.
If this is a latent call to clean it up, then sure, I can take care of
it ;) A quick scan shows ca. 30 call sites in the entire tree, fixing
which seems to be doable given a few weeks of time.
Though obviously I would really like to hear that the patch looks sound
before I set out on that journey.
--
Best regards,
Michał Kępień
Powered by blists - more mailing lists