linux-kernel - Re: [PATCH v3] i2c-hid: introduce HID over i2c specification implementation

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] [day] [month] [year] [list]

Date:	Tue, 4 Dec 2012 12:50:39 +0100
From:	Benjamin Tissoires <benjamin.tissoires@...il.com>
To:	Jiri Kosina <jkosina@...e.cz>
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 Tue, Dec 4, 2012 at 11:31 AM, Jiri Kosina <jkosina@...e.cz> wrote:
> 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.

Sure, I intend to send some patches today (with the change of the name
included). I'll send the patch related to the name in the first
position so that you can safely pick it up even if you are not
satisfied with the other changes.

Thanks,
Benjamin

>
> 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/