linux-kernel - Re: [PATCH] dell-laptop: use dedicated sysfs file for ALS

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

Message-ID: <1663320.Wk1Y30OHLH@xps13>
Date:	Sun, 18 Jan 2015 19:34:17 +0100
From:	Gabriele Mazzotta <gabriele.mzt@...il.com>
To:	Darren Hart <dvhart@...radead.org>
Cc:	mjg59@...f.ucam.org, pali.rohar@...il.com,
	linux-kernel@...r.kernel.org, platform-driver-x86@...r.kernel.org,
	A.Sloman@...bham.ac.uk, computersforpeace@...il.com
Subject: Re: [PATCH] dell-laptop: use dedicated sysfs file for ALS

On Sunday 18 January 2015 10:08:21 Darren Hart wrote:
> On Wed, Jan 14, 2015 at 03:07:21PM +0100, Gabriele Mazzotta wrote:
> > Hi,
> > 
> > I decided to remove "als" from input_triggers and created a dedicated
> > sysfs file for it. Having it there was wrong and misleading.
> > I also updated the documentation to reflect this change and fixed the
> > wrong description of als_setting, now used for als_enabled.
> 
> Given this is a significant functional change, as opposed to a bug fix, I'm
> leaning toward reverting the original and adding back the corrected version to
> 3.20. I'm going to look at the total impact first - let me know if you have a
> strong argument one way or the other.

I'm not against this decision.
If you do, please remember to also revert the commit that added the
documentation.

> > Is returning -ENODEV only when writing to als_enabled the right thing
> > to do or should it be returned also when reading als_enabled?
> 
> Why would the als_enabled file exist if it would return ENODEV? If it shouldn't,
> then returning ENODEV in both cases would be the right thing to do as there is
> an error present.

I'd say it makes sense not to create it when not neeeded.
Creating the file conditionally probably requires more changes than what
you'd like to see at this stage, so this would be another argument
supporting the revert.
--
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/