linux.kernel - 26 new messages in 14 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* sysfs_rename_link() and its usage - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/f1f1b010c1a48195?hl=en
* perf report: Add --percentage option - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/a2b106be220a1f65?hl=en
* mei: allow multiple retries if the hw reset has failed - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/1ed6574c84928b7d?hl=en
* hvc: ensure hvc_init is only ever called once in hvc_console.c - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/5282e7efa4f9699f?hl=en
* sys, seccomp: add PR_SECCOMP_EXT and SECCOMP_EXT_ACT_TSYNC - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/e2f632c51e6112a2?hl=en
* ARM: OMAP4: sleep: byteswap data for big-endian - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/42dfa14ea7e21a21?hl=en
* locks: skip deadlock detection on FL_FILE_PVT locks - 9 messages, 4 authors
http://groups.google.com/group/linux.kernel/t/6a7c503eabf52b07?hl=en
* Staging: android: fix parentheses coding style issue in alarm-dev.c - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/6f1631dc1b7f8b07?hl=en
* KREDIT ANGEBOT - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f5c1b79227387b09?hl=en
* usb: xhci: Link TRB must not occur within a USB payload burst [NEW HARDWARE]
- 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/02bb633f7aaf9195?hl=en
* ACPI/Battery: Add a _BIX quirk for NEC LZ750/LS - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/eb56e9827c8b75a7?hl=en
* ARM: OMAP4460: cpuidle: Extend PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD on cpuidle
- 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/ef17777685a1a5c6?hl=en
* mei: export active connections to debugfs - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c5f7bed439db426e?hl=en
* ASoC: simple-card: fix one bug to writing to the platform data - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/2ae05930c48e0323?hl=en

==============================================================================
TOPIC: sysfs_rename_link() and its usage
http://groups.google.com/group/linux.kernel/t/f1f1b010c1a48195?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Jan 14 2014 1:10 pm
From: Veaceslav Falico


On Tue, Jan 14, 2014 at 11:31:39AM -0800, Greg KH wrote:
>On Tue, Jan 14, 2014 at 08:12:08PM +0100, Veaceslav Falico wrote:
>> On Tue, Jan 14, 2014 at 10:21:35AM -0800, Greg KH wrote:
>> >On Tue, Jan 14, 2014 at 06:17:40PM +0100, Veaceslav Falico wrote:
>> >>Hi,
>> >>
>> >>I'm hitting a strange issue and/or I'm completely lost in sysfs internals.
>> >>
>> >>Consider having two net_device *a, *b; which are registered normally.
>> >>Now, to create a link from /sys/class/net/a->name/linkname to b, one should
>> >>use:
>> >>
>> >>sysfs_create_link(&(a->dev.kobj), &(b->dev.kobj), linkname);
>> >>
>> >>To remove it, even simpler:
>> >>
>> >>sysfs_remove_link(&(a->dev.kobj), linkname);
>> >>
>> >>This works like a charm. However, if I want to use (obviously, with the
>> >>symlink present):
>> >>
>> >>sysfs_rename_link(&(a->dev.kobj), &(b->dev.kobj), oldname, newname);
>> >
>> >You forgot the namespace option to this call, what kernel version are
>> >you using here?
>>
>> It's git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next ,
>> 3.13-rc6 with some networking patches on top of it.
>>
>> And wrt namespace - there are two functions, one is sysfs_rename_link(),
>> which calls the second one - sysfs_rename_link_ns() with NULL namespace.
>>
>> >
>> >>this fails with:
>> >>
>> >>"sysfs: ns invalid in 'a->name' for 'oldname'"
>> >
>> >Looks like the namespace for this link isn't valid.
>>
>> Yep, though dunno why.
>
>Are you testing this with network namespaces enabled? Perhaps that is
>why, you need to specify the namespace of the link that you are
>changing.
>
>The fact that the bridge link works is odd to me, I would think that it
>too needs to specify the network namespace involved, but perhaps bridge
>objects aren't part of any specific network namespace? I don't know the
>bridging code at all, sorry.

Yep, might be it, will test soon and come back with the results.

What still bugs me, though, is the logic - why is it possible to remove/add
without specifying namespace, while it fails to rename it? Maybe the rename
function should do a better job at detecting the namespace?

>
>So try calling sysfs_rename_link_ns() and specify the namespace of the
>kobject you are changing, and see if that works or not.
>
>thanks,
>
>greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 2 ==
Date: Tues, Jan 14 2014 1:20 pm
From: Greg KH


On Tue, Jan 14, 2014 at 10:06:10PM +0100, Veaceslav Falico wrote:
> On Tue, Jan 14, 2014 at 11:31:39AM -0800, Greg KH wrote:
> >On Tue, Jan 14, 2014 at 08:12:08PM +0100, Veaceslav Falico wrote:
> >>On Tue, Jan 14, 2014 at 10:21:35AM -0800, Greg KH wrote:
> >>>On Tue, Jan 14, 2014 at 06:17:40PM +0100, Veaceslav Falico wrote:
> >>>>Hi,
> >>>>
> >>>>I'm hitting a strange issue and/or I'm completely lost in sysfs internals.
> >>>>
> >>>>Consider having two net_device *a, *b; which are registered normally.
> >>>>Now, to create a link from /sys/class/net/a->name/linkname to b, one should
> >>>>use:
> >>>>
> >>>>sysfs_create_link(&(a->dev.kobj), &(b->dev.kobj), linkname);
> >>>>
> >>>>To remove it, even simpler:
> >>>>
> >>>>sysfs_remove_link(&(a->dev.kobj), linkname);
> >>>>
> >>>>This works like a charm. However, if I want to use (obviously, with the
> >>>>symlink present):
> >>>>
> >>>>sysfs_rename_link(&(a->dev.kobj), &(b->dev.kobj), oldname, newname);
> >>>
> >>>You forgot the namespace option to this call, what kernel version are
> >>>you using here?
> >>
> >>It's git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next ,
> >>3.13-rc6 with some networking patches on top of it.
> >>
> >>And wrt namespace - there are two functions, one is sysfs_rename_link(),
> >>which calls the second one - sysfs_rename_link_ns() with NULL namespace.
> >>
> >>>
> >>>>this fails with:
> >>>>
> >>>>"sysfs: ns invalid in 'a->name' for 'oldname'"
> >>>
> >>>Looks like the namespace for this link isn't valid.
> >>
> >>Yep, though dunno why.
> >
> >Are you testing this with network namespaces enabled? Perhaps that is
> >why, you need to specify the namespace of the link that you are
> >changing.
> >
> >The fact that the bridge link works is odd to me, I would think that it
> >too needs to specify the network namespace involved, but perhaps bridge
> >objects aren't part of any specific network namespace? I don't know the
> >bridging code at all, sorry.
>
> Yep, might be it, will test soon and come back with the results.
>
> What still bugs me, though, is the logic - why is it possible to remove/add
> without specifying namespace, while it fails to rename it? Maybe the rename
> function should do a better job at detecting the namespace?

Yes, maybe it should, patches are always gladly welcome :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: perf report: Add --percentage option
http://groups.google.com/group/linux.kernel/t/a2b106be220a1f65?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Jan 14 2014 1:10 pm
From: Andi Kleen


Namhyung Kim <namhyung@kernel.org> writes:
>
> +--percentage::
> + Determine how to display the overhead percentage of filtered
> entries.

This should describe also what a "filtered entry" exactly is. It's not clear
even to me.

-Andi

> + "relative" means it's relative to filtered entries only so that the
> + sum of shown entries will be always 100%. "absolute" means it retains
> + original value before and after the filter applied.
> +

--
ak@linux.intel.com -- Speaking for myself only
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 2 ==
Date: Tues, Jan 14 2014 1:30 pm
From: Arnaldo Carvalho de Melo


Em Tue, Jan 14, 2014 at 01:07:00PM -0800, Andi Kleen escreveu:
> Namhyung Kim <namhyung@kernel.org> writes:
> >
> > +--percentage::
> > + Determine how to display the overhead percentage of filtered
> > entries.
>
> This should describe also what a "filtered entry" exactly is. It's not clear
> even to me.

Yeah, the text should give some context, mentioning the "Zoom"
operations that can be done in the TUI (DSO, thread, etc) that allows
applying what he is calling "filters".`

> -Andi
>
> > + "relative" means it's relative to filtered entries only so that the
> > + sum of shown entries will be always 100%. "absolute" means it retains
> > + original value before and after the filter applied.
> > +
>
> --
> ak@linux.intel.com -- Speaking for myself only
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: mei: allow multiple retries if the hw reset has failed
http://groups.google.com/group/linux.kernel/t/1ed6574c84928b7d?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 14 2014 1:20 pm
From: Tomas Winkler


In some rare case mei hw reset may take long time to settle.
Instead of blocking resume flow we span another driver reset flow in
separate work context

This allows as to shorten hw reset timeout to something more acceptable
by DPM_WATCHDOG_TIMEOUT

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
---
drivers/misc/mei/hbm.c | 2 +-
drivers/misc/mei/hw-me.c | 2 +-
drivers/misc/mei/hw.h | 4 ++--
drivers/misc/mei/init.c | 40 ++++++++++++++++++++++++++++++----------
4 files changed, 34 insertions(+), 14 deletions(-)

diff --git a/drivers/misc/mei/hbm.c b/drivers/misc/mei/hbm.c
index 28cd74c..0aaf2c5 100644
--- a/drivers/misc/mei/hbm.c
+++ b/drivers/misc/mei/hbm.c
@@ -147,7 +147,7 @@ int mei_hbm_start_wait(struct mei_device *dev)
ret = wait_event_interruptible_timeout(dev->wait_recvd_msg,
dev->hbm_state == MEI_HBM_IDLE ||
dev->hbm_state >= MEI_HBM_STARTED,
- mei_secs_to_jiffies(MEI_INTEROP_TIMEOUT));
+ mei_secs_to_jiffies(MEI_HBM_TIMEOUT));
mutex_lock(&dev->device_lock);

if (ret <= 0 && (dev->hbm_state <= MEI_HBM_START)) {
diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
index 6f656c0..54286f3 100644
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -240,7 +240,7 @@ static int mei_me_hw_ready_wait(struct mei_device *dev)
mutex_unlock(&dev->device_lock);
err = wait_event_interruptible_timeout(dev->wait_hw_ready,
dev->recvd_hw_ready,
- mei_secs_to_jiffies(MEI_INTEROP_TIMEOUT));
+ mei_secs_to_jiffies(MEI_HW_READY_TIMEOUT));
mutex_lock(&dev->device_lock);
if (!err && !dev->recvd_hw_ready) {
if (!err)
diff --git a/drivers/misc/mei/hw.h b/drivers/misc/mei/hw.h
index dd44e33..e06779d 100644
--- a/drivers/misc/mei/hw.h
+++ b/drivers/misc/mei/hw.h
@@ -22,7 +22,7 @@
/*
* Timeouts in Seconds
*/
-#define MEI_INTEROP_TIMEOUT 7 /* Timeout on ready message */
+#define MEI_HW_READY_TIMEOUT 2 /* Timeout on ready message */
#define MEI_CONNECT_TIMEOUT 3 /* HPS: at least 2 seconds */

#define MEI_CL_CONNECT_TIMEOUT 15 /* HPS: Client Connect Timeout */
@@ -31,13 +31,13 @@
#define MEI_IAMTHIF_STALL_TIMER 12 /* HPS */
#define MEI_IAMTHIF_READ_TIMER 10 /* HPS */

+#define MEI_HBM_TIMEOUT 1 /* 1 second */

/*
* MEI Version
*/
#define HBM_MINOR_VERSION 0
#define HBM_MAJOR_VERSION 1
-#define HBM_TIMEOUT 1 /* 1 second */

/* Host bus message command opcode */
#define MEI_HBM_CMD_OP_MSK 0x7f
diff --git a/drivers/misc/mei/init.c b/drivers/misc/mei/init.c
index cdd31c2..95a7180 100644
--- a/drivers/misc/mei/init.c
+++ b/drivers/misc/mei/init.c
@@ -126,7 +126,6 @@ int mei_reset(struct mei_device *dev)

if (ret) {
dev_err(&dev->pdev->dev, "hw_reset failed ret = %d\n", ret);
- dev->dev_state = MEI_DEV_DISABLED;
return ret;
}

@@ -139,7 +138,6 @@ int mei_reset(struct mei_device *dev)
ret = mei_hw_start(dev);
if (ret) {
dev_err(&dev->pdev->dev, "hw_start failed ret = %d\n", ret);
- dev->dev_state = MEI_DEV_DISABLED;
return ret;
}

@@ -149,7 +147,7 @@ int mei_reset(struct mei_device *dev)
ret = mei_hbm_start_req(dev);
if (ret) {
dev_err(&dev->pdev->dev, "hbm_start failed ret = %d\n", ret);
- dev->dev_state = MEI_DEV_DISABLED;
+ dev->dev_state = MEI_DEV_RESETTING;
return ret;
}

@@ -166,6 +164,7 @@ EXPORT_SYMBOL_GPL(mei_reset);
*/
int mei_start(struct mei_device *dev)
{
+ int ret;
mutex_lock(&dev->device_lock);

/* acknowledge interrupt and stop interrupts */
@@ -175,10 +174,18 @@ int mei_start(struct mei_device *dev)

dev_dbg(&dev->pdev->dev, "reset in start the mei device.\n");

- dev->dev_state = MEI_DEV_INITIALIZING;
dev->reset_count = 0;
- mei_reset(dev);
+ do {
+ dev->dev_state = MEI_DEV_INITIALIZING;
+ ret = mei_reset(dev);
+
+ if (ret == -ENODEV || dev->dev_state == MEI_DEV_DISABLED) {
+ dev_err(&dev->pdev->dev, "reset failed ret = %d", ret);
+ goto err;
+ }
+ } while (ret);

+ /* we cannot start the device w/o hbm start message completed */
if (dev->dev_state == MEI_DEV_DISABLED) {
dev_err(&dev->pdev->dev, "reset failed");
goto err;
@@ -238,27 +245,40 @@ int mei_restart(struct mei_device *dev)

mutex_unlock(&dev->device_lock);

- if (err || dev->dev_state == MEI_DEV_DISABLED)
+ if (err == -ENODEV || dev->dev_state == MEI_DEV_DISABLED) {
+ dev_err(&dev->pdev->dev, "device disabled = %d\n", err);
return -ENODEV;
+ }
+
+ /* try to start again */
+ if (err)
+ schedule_work(&dev->reset_work);
+

return 0;
}
EXPORT_SYMBOL_GPL(mei_restart);

-
static void mei_reset_work(struct work_struct *work)
{
struct mei_device *dev =
container_of(work, struct mei_device, reset_work);
+ int ret;

mutex_lock(&dev->device_lock);

- mei_reset(dev);
+ ret = mei_reset(dev);

mutex_unlock(&dev->device_lock);

- if (dev->dev_state == MEI_DEV_DISABLED)
- dev_err(&dev->pdev->dev, "reset failed");
+ if (dev->dev_state == MEI_DEV_DISABLED) {
+ dev_err(&dev->pdev->dev, "device disabled = %d\n", ret);
+ return;
+ }
+
+ /* retry reset in case of failure */
+ if (ret)
+ schedule_work(&dev->reset_work);
}

void mei_stop(struct mei_device *dev)
--
1.8.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: hvc: ensure hvc_init is only ever called once in hvc_console.c
http://groups.google.com/group/linux.kernel/t/5282e7efa4f9699f?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 14 2014 1:20 pm
From: Greg Kroah-Hartman


On Tue, Jan 14, 2014 at 04:03:37PM -0500, Paul Gortmaker wrote:
> Commit 3e6c6f630a5282df8f3393a59f10eb9c56536d23 ("Delay creation of
> khcvd thread") moved the call of hvc_init from being a device_initcall
> into hvc_alloc, and used a non-null hvc_driver as indication of whether
> hvc_init had already been called.
>
> The problem with this is that hvc_driver is only assigned a value
> at the bottom of hvc_init, and so there is a window where multiple
> hvc_alloc calls can be in progress at the same time and hence try
> and call hvc_init multiple times. Previously the use of device_init
> guaranteed that hvc_init was only called once.
>
> This manifests itself as sporadic instances of two hvc_init calls
> racing each other, and with the loser of the race getting -EBUSY
> from tty_register_driver() and hence that virtual console fails:
>
> Couldn't register hvc console driver
> virtio-ports vport0p1: error -16 allocating hvc for port
>
> Here we add an atomic_t to guarantee we'll never run hvc_init twice.
>
> Cc: stable@vger.kernel.org # v2.6.24+
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Fixes: 3e6c6f630a52 ("Delay creation of khcvd thread")
> Reported-by: Jim Somerville <Jim.Somerville@windriver.com>
> Tested-by: Jim Somerville <Jim.Somerville@windriver.com>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
>
> [Greg: I realize tty-next is closed; given that this is an ancient
> bug, I don't see any real urgency here, so feel free to queue it
> whenever/whereever is most convenient - assuming it is an OK fix.]

Looks ok, I'll queue it up after 3.14-rc1 is out, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: sys, seccomp: add PR_SECCOMP_EXT and SECCOMP_EXT_ACT_TSYNC
http://groups.google.com/group/linux.kernel/t/e2f632c51e6112a2?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Jan 14 2014 1:20 pm
From: Will Drewry


On Tue, Jan 14, 2014 at 3:09 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Tue, Jan 14, 2014 at 12:59 PM, Will Drewry <wad@chromium.org> wrote:
>> On Tue, Jan 14, 2014 at 2:24 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> On Tue, Jan 14, 2014 at 10:59 AM, Will Drewry <wad@chromium.org> wrote:
>>>> On Mon, Jan 13, 2014 at 5:36 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>>>> On 01/13/2014 12:30 PM, Will Drewry wrote:
>>>>>> Applying restrictive seccomp filter programs to large or diverse
>>>>>> codebases often requires handling threads which may be started early in
>>>>>> the process lifetime (e.g., by code that is linked in). While it is
>>>>>> possible to apply permissive programs prior to process start up, it is
>>>>>> difficult to further restrict the kernel ABI to those threads after that
>>>>>> point.
>>>>>>
>>>>>> This change adds a new seccomp "extension" for synchronizing thread
>>>>>> group seccomp filters and a prctl() for accessing that functionality.
>>>>>> The need for the added prctl() is due to the lack of reserved arguments
>>>>>> in PR_SET_SECCOMP.
>>>>>>
>>>>>> When prctl(PR_SECCOMP_EXT, SECCOMP_EXT_ACT_TSYNC, 0, 0) is called, it
>>>>>> will attempt to synchronize all threads in current's threadgroup to its
>>>>>> seccomp filter program. This is possible iff all threads are using a
>>>>>> filter that is an ancestor to the filter current is attempting to
>>>>>> synchronize to. NULL filters (where the task is running as
>>>>>> SECCOMP_MODE_NONE) are also treated as ancestors allowing threads to be
>>>>>> transitioned into SECCOMP_MODE_FILTER. On success, 0 is returned. On
>>>>>> failure, the pid of one of the failing threads will be returned.
>>>>>>
>>>>>> Suggested-by: Julien Tinnes <jln@chromium.org>
>>>>>> Signed-off-by: Will Drewry <wad@chromium.org>
>>>>>> ---
>>>>>> include/linux/seccomp.h | 7 +++
>>>>>> include/uapi/linux/prctl.h | 6 ++
>>>>>> include/uapi/linux/seccomp.h | 6 ++
>>>>>> kernel/seccomp.c | 128 ++++++++++++++++++++++++++++++++++++++++++
>>>>>> kernel/sys.c | 3 +
>>>>>> 5 files changed, 150 insertions(+)
>>>>>>
>>>>>> diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
>>>>>> index 85c0895..3163db6 100644
>>>>>> --- a/include/linux/seccomp.h
>>>>>> +++ b/include/linux/seccomp.h
>>>>>> @@ -77,6 +77,8 @@ static inline int seccomp_mode(struct seccomp *s)
>>>>>> extern void put_seccomp_filter(struct task_struct *tsk);
>>>>>> extern void get_seccomp_filter(struct task_struct *tsk);
>>>>>> extern u32 seccomp_bpf_load(int off);
>>>>>> +extern long prctl_seccomp_ext(unsigned long, unsigned long,
>>>>>> + unsigned long, unsigned long);
>>>>>> #else /* CONFIG_SECCOMP_FILTER */
>>>>>> static inline void put_seccomp_filter(struct task_struct *tsk)
>>>>>> {
>>>>>> @@ -86,5 +88,10 @@ static inline void get_seccomp_filter(struct task_struct *tsk)
>>>>>> {
>>>>>> return;
>>>>>> }
>>>>>> +static inline long prctl_seccomp_ext(unsigned long arg2, unsigned long arg3,
>>>>>> + unsigned long arg4, unsigned long arg5)
>>>>>> +{
>>>>>> + return -EINVAL;
>>>>>> +}
>>>>>>