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]
Message-ID: <CAN+gG=G+ymEdfAf3Ub6n8ErhPBz1BB3XYyEPixz9sWbNeRnPDQ@mail.gmail.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ