[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20221004074459.35b58ed0@endymion.delvare>
Date: Tue, 4 Oct 2022 07:44:59 +0200
From: Jean Delvare <jdelvare@...e.de>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc: Daniel Hung-yu Wu <hywu@...gle.com>, linux-input@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Input: misc - atmel_captouch does not depend on OF
On Mon, 3 Oct 2022 20:54:48 -0700, Dmitry Torokhov wrote:
> Hi Jean,
>
> On Mon, Oct 03, 2022 at 05:29:53PM +0200, Jean Delvare wrote:
> > The atmel_captouch driver does not actually depend on OF, it includes
> > a non-OF device ID which could be used to instantiate the device, and
> > the driver code is already prepared to be built with or without OF. So
> > drop the unneeded dependency.
> >
> > Signed-off-by: Jean Delvare <jdelvare@...e.de>
> > Cc: Daniel Hung-yu Wu <hywu@...gle.com>
> > Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>
> > ---
> > The problem I'm trying to solve here is that "depends on OF ||
> > COMPILE_TEST" does not make sense since OF can now be enabled on all
> > architectures. One way to fix this is by removing the dependency
> > altogether (this patch).
> >
> > If the driver is known to be needed only on OF-enabled systems then we
> > could leave the dependency on OF and only drop COMPILE_TEST (and
> > simplify the driver code accordingly). I have an alternative patch
> > doing that already. Tell me what you prefer, I'm fine either way.
>
> The driver is not operable on systems without OF:
>
> static int atmel_captouch_probe(...
> ...
>
> node = dev->of_node;
> if (!node) {
> dev_err(dev, "failed to find matching node in device tree\n");
> return -EINVAL;
> }
>
> if (of_property_read_bool(node, "autorepeat"))
>
> So the reason for "depends on OF || COMPILE_TEST" is to avoid prompting
> users who actually try to configure real systems for drivers that make
> no sense for them while still allowing people interested in compile
> coverage to select COMPILE_TEST and enable more drivers.
OK, thanks for the clarification. Please disregard this patch then,
I'll send the other one.
--
Jean Delvare
SUSE L3 Support
Powered by blists - more mailing lists