linux-kernel - Re: [PATCH 1/2] Input: synaptics - print firmware ID and board number at init

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:	Mon, 2 Jul 2012 14:37:15 +0200
From:	"Henrik Rydberg" <rydberg@...omail.se>
To:	Daniel Kurtz <djkurtz@...omium.org>
Cc:	Alessandro Rubini <rubini@...vis.unipv.it>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Olof Johansson <olof@...om.net>,
	Benson Leung <bleung@...omium.org>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] Input: synaptics - print firmware ID and board
 number at init

> > Is there a specific usecase for this, except the nice-to-have?
> 
> Use cases (these are all very real use cases, that we use today, they
> are not hypothetical):
>   * To include firmware and hardware versions in user feedback reports.
>   * Used by factory tests to ensure systems are being built and
> deployed correctly.
>   * Lastly, these are also precursor patches for a larger set that
> adds firmware update capability.  A userspace firmware update script
> can use these APIs to determine which file to load and/or whether such
> a load is necessary.

Thanks. Future firmware update patches is the prime reason for the
sysfs interface, IOW.

> If there is a standard non-driver-specific way of achieving these use
> cases, I'd be happy to modify the implementation to adopt that
> standard.  From what I've seen, however, it looks like most drivers
> have their own ad hoc way of exposing device/vendor specific
> properties.

Precisely. If there is no standard, it is quite alright to try to come
up with one. Otherwise we might as well leave all firmware-related
code in userspace.

Thanks,
Henrik
--
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/