[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.00.1212041129530.17055@pobox.suse.cz>
Date: Tue, 4 Dec 2012 11:31:41 +0100 (CET)
From: Jiri Kosina <jkosina@...e.cz>
To: Benjamin Tissoires <benjamin.tissoires@...il.com>
Cc: Jean Delvare <khali@...ux-fr.org>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Stephane Chatty <chatty@...c.fr>, fabien.andre@...il.com,
scott.liu@....com.tw, JJ Ding <jj_ding@....com.tw>,
Jiri Slaby <jslaby@...e.cz>,
Shubhrajyoti Datta <omaplinuxkernel@...il.com>,
linux-i2c@...r.kernel.org, linux-input@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] i2c-hid: introduce HID over i2c specification
implementation
On Mon, 3 Dec 2012, Benjamin Tissoires wrote:
> >> I know that it already have been used by one Nvidia team and by Elan
> >> for internal tests. So I don't know if it's possible to change it now
> >> (though it's not a big deal).
> >
> > Yes it is possible, as long as the code isn't in Linus' tree (and I'd
> > even say: as long as it is not in any kernel released by Linus.)
> > Whoever is already using your driver will have to adjust their code.
> > They'll certainly want to anyway, in order to get the bug fixes.
> >
> >> Anyway, "hid" is a little weird to me (but this is because I started
> >> hacking the kernel from there), as it's really short and does not
> >> contain i2c :)
> >
> > This is exactly my point: no other i2c client (to my knowledge) has
> > "i2c" in its name, because it is redundant.
> >
> > I would agree that this is kind of a special case as this is a generic
> > driver and not a device-specific driver. I would still prefer "hid" but
> > if you don't feel like changing it, I guess I can live with that.
>
> Ok, I'll change the name.
> My concerns were just because from my point of view, "hid" refers to
> the core implementation. But for OEMs, they need to declare a "hid"
> device, so it makes sense. Anyway, when I'll be able to get my hand on
> an ACPI 5 device with hid over i2c, I'll be able to write the missing
> autoloading code, and this name will be only used by a small part of
> OEMs (I hope).
If you are going to change the name, please either send me the patch
before merge window for 3.8 opens, or explicitly ask me not to include
this driver in pull request that goes to Linus yet.
Once the driver is in Linus' tree, I'd rather not change the name.
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists