Re: [PATCH v2] drivers/tty: Folding Android's keyreset driver in sysRQ

[Colin Cross]

On Fri, Aug 31, 2012 at 2:52 PM, Mathieu Poirier
<mathieu.poirier@xxxxxxxxxx> 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@xxxxxxxxxx wrote:
>>> From: "Mathieu J. Poirier" <mathieu.poirier@xxxxxxxxxx>
>>>
>>> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/