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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMbhsRRy+M+5qtptr7_1mwUxCv5mj2HqyQY6pVa5om6-_oK+Mg@mail.gmail.com>
Date:	Sat, 1 Sep 2012 12:18:05 -0700
From:	Colin Cross <ccross@...gle.com>
To:	Mathieu Poirier <mathieu.poirier@...aro.org>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	linux-kernel@...r.kernel.org, rdunlap@...otime.net,
	arve@...roid.com, kernel-team@...roid.com, john.stultz@...aro.org
Subject: Re: [PATCH v2] drivers/tty: Folding Android's keyreset driver in sysRQ

On Fri, Aug 31, 2012 at 2:52 PM, Mathieu Poirier
<mathieu.poirier@...aro.org> wrote:
> On 12-08-30 05:01 PM, Dmitry Torokhov wrote:
>> Hi Matthieu,
>>
>> On Thu, Aug 30, 2012 at 04:30:54PM -0600, mathieu.poirier@...aro.org wrote:
>>> From: "Mathieu J. Poirier" <mathieu.poirier@...aro.org>
>>>
>>> This patch adds keyreset functionality to the sysrq driver. It
>>> allows certain button/key combinations to be used in order to
>>> trigger device resets.
>>>
>>> The first time the key-combo is detected a work function that syncs
>>> the filesystems is scheduled and the kernel rebooted. If all the keys
>>> are released and then pressed again, it calls panic. Reboot on panic
>>> should be set for this to work.  A platform device that specify a
>>> reset key-combo should be added to the board file to trigger the
>>> feature.
>>
>> Why do we need to involve a platform device and not use, for example, a module
>> parameter, that could be set up from userspace?
>
> The platform device comes from the original design and was included to
> minimise the amount of changes in code that make use of the current
> keyreset driver.
>
> I am definitely willing to explore the possibility of adding module
> parameter to complement the platform data but again, to avoid impacting
> board code I'm in favour of keeping the platform data/device - get back
> to me if you disagree.

I wouldn't worry too much about compatibility with existing board
files, they are unlikely to move to a new driver anyways, and if they
do, changing the way they are configured is not a big deal.  That
said, I generally don't like module parameters because it ends up
cluttering the kernel command line with configuration for every
device.  Setting them through sysfs is too late, if a device with a
non-removable battery hangs during boot you would like to be able to
reset it with this driver.
--
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