quot;.
> But "bad1" has pm_runtime_disable() call, this function should
> be called when uio_register_device() is failed. So it is moved
> into handling error for uio_register_device().
Looks alright to me. Thanks for your contribution.
Signed-off-by: Hans J. Koch
>
>
should
be called when uio_register_device() is failed. So it is moved
into handling error for uio_register_device().
Looks alright to me. Thanks for your contribution.
Signed-off-by: Hans J. Koch h...@hansjkoch.de
Signed-off-by: Daeseok Youn daeseok.y...@gmail.com
---
drivers/uio
index 69fea4f..dc9d04a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5253,9 +5253,8 @@ F: Documentation/hwmon/max16065
> F: drivers/hwmon/max16065.c
>
> MAX6650 HARDWARE MONITOR AND FAN CONTROLLER DRIVER
> -M: "Hans J. Koch"
> L:
100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5253,9 +5253,8 @@ F: Documentation/hwmon/max16065
F: drivers/hwmon/max16065.c
MAX6650 HARDWARE MONITOR AND FAN CONTROLLER DRIVER
-M: Hans J. Koch h...@hansjkoch.de
L: lm-sens...@lm-sensors.org
-S: Maintained
+S: Orphan
F
On Fri, May 17, 2013 at 05:53:39PM +0300, Eli Billauer wrote:
> This is the documentation for the Xillybus driver. It's intended for kernel
> maintainers, since actual users will most likely rely on other documentation.
>
> It has turned out somewhat tricky to put Xillybus in one of the existing
On Fri, May 17, 2013 at 05:53:39PM +0300, Eli Billauer wrote:
This is the documentation for the Xillybus driver. It's intended for kernel
maintainers, since actual users will most likely rely on other documentation.
It has turned out somewhat tricky to put Xillybus in one of the existing
On Fri, Jan 18, 2013 at 02:00:50PM -0800, Greg Kroah-Hartman wrote:
> On Fri, Jan 18, 2013 at 10:05:45PM +0100, Cong Ding wrote:
> > On Tue, Dec 11, 2012 at 2:21 AM, Hans J. Koch wrote:
> > > On Thu, Nov 29, 2012 at 05:40:00PM +, Cong Ding wrote:
> > >> In
On Fri, Jan 18, 2013 at 02:00:50PM -0800, Greg Kroah-Hartman wrote:
On Fri, Jan 18, 2013 at 10:05:45PM +0100, Cong Ding wrote:
On Tue, Dec 11, 2012 at 2:21 AM, Hans J. Koch h...@hansjkoch.de wrote:
On Thu, Nov 29, 2012 at 05:40:00PM +, Cong Ding wrote:
In version 1, I forgot to modify
On Fri, Dec 14, 2012 at 11:33:50AM +0200, Vitalii Demianets wrote:
>
> Hans, why do you want to put in this patch, which is dealing with
> memory-freeing issues only, completely unrelated functional changes?
Because during review of your patch we happened to find another issue
a few lines up
On Fri, Dec 14, 2012 at 11:33:50AM +0200, Vitalii Demianets wrote:
Hans, why do you want to put in this patch, which is dealing with
memory-freeing issues only, completely unrelated functional changes?
Because during review of your patch we happened to find another issue
a few lines up and
)
Cong Ding (1):
uio: fix possible memory leak in uio.c
Hans J. Koch (1):
uio: Fix warning: 'ret' might be used uninitialized
drivers/uio/uio.c | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
--
To unsubscribe from
On Mon, Dec 10, 2012 at 11:44:45AM +0200, Vitalii Demianets wrote:
> 1. uioinfo was kfreed based on the presence of pdev->dev.of_node, which was
> obviously wrong and unrelated to the fact if uioinfo was allocated statically
> or dynamically. This patch introduces new flag which clearly shows if
On Thu, Dec 13, 2012 at 07:23:21PM +0200, Vitalii Demianets wrote:
> On Thursday 13 December 2012 19:11:09 Hans J. Koch wrote:
> > On Tue, Dec 11, 2012 at 12:47:35PM +0200, Vitalii Demianets wrote:
> > > Please, review the v3 of "Fix memory freeing issues" patch (first
On Tue, Dec 11, 2012 at 12:47:35PM +0200, Vitalii Demianets wrote:
>
> Please, review the v3 of "Fix memory freeing issues" patch (first in the
> series I posted yesterday) and ignore the second, as we haven't agreed
> on it.
>
I can't find a v3. Please resend it.
Thanks,
Hans
--
To
On Tue, Dec 11, 2012 at 12:47:35PM +0200, Vitalii Demianets wrote:
Please, review the v3 of Fix memory freeing issues patch (first in the
series I posted yesterday) and ignore the second, as we haven't agreed
on it.
I can't find a v3. Please resend it.
Thanks,
Hans
--
To unsubscribe
On Thu, Dec 13, 2012 at 07:23:21PM +0200, Vitalii Demianets wrote:
On Thursday 13 December 2012 19:11:09 Hans J. Koch wrote:
On Tue, Dec 11, 2012 at 12:47:35PM +0200, Vitalii Demianets wrote:
Please, review the v3 of Fix memory freeing issues patch (first in the
series I posted yesterday
On Mon, Dec 10, 2012 at 11:44:45AM +0200, Vitalii Demianets wrote:
1. uioinfo was kfreed based on the presence of pdev-dev.of_node, which was
obviously wrong and unrelated to the fact if uioinfo was allocated statically
or dynamically. This patch introduces new flag which clearly shows if
)
Cong Ding (1):
uio: fix possible memory leak in uio.c
Hans J. Koch (1):
uio: Fix warning: 'ret' might be used uninitialized
drivers/uio/uio.c | 18 --
1 files changed, 12 insertions(+), 6 deletions(-)
--
To unsubscribe from
On Wed, Dec 12, 2012 at 07:08:18AM -0800, Greg KH wrote:
> On Wed, Dec 12, 2012 at 09:56:16AM +0100, Benedikt Spranger wrote:
> > Am Wed, 12 Dec 2012 09:50:54 +0100
> > schrieb "Hans J. Koch" :
> >
> > > On Tue, Dec 11, 2012 at 08:46:48PM -0800, Greg KH wro
On Tue, Dec 11, 2012 at 08:46:48PM -0800, Greg KH wrote:
> On Wed, Dec 12, 2012 at 02:42:22AM +0100, Hans J. Koch wrote:
> > On Tue, Dec 11, 2012 at 03:20:32PM -0800, Greg KH wrote:
> > > On Wed, Dec 12, 2012 at 12:12:02AM +0100, Benedikt Spranger wrote:
> > > >
On Tue, Dec 11, 2012 at 08:46:48PM -0800, Greg KH wrote:
On Wed, Dec 12, 2012 at 02:42:22AM +0100, Hans J. Koch wrote:
On Tue, Dec 11, 2012 at 03:20:32PM -0800, Greg KH wrote:
On Wed, Dec 12, 2012 at 12:12:02AM +0100, Benedikt Spranger wrote:
The inode parameter is unused by in kernel
On Wed, Dec 12, 2012 at 07:08:18AM -0800, Greg KH wrote:
On Wed, Dec 12, 2012 at 09:56:16AM +0100, Benedikt Spranger wrote:
Am Wed, 12 Dec 2012 09:50:54 +0100
schrieb Hans J. Koch h...@hansjkoch.de:
On Tue, Dec 11, 2012 at 08:46:48PM -0800, Greg KH wrote:
Yes, but what does
On Tue, Dec 11, 2012 at 03:18:16PM -0800, Greg KH wrote:
> On Wed, Dec 12, 2012 at 12:12:01AM +0100, Benedikt Spranger wrote:
> > The documentation has no clear statement to the POSIX 1003.1 mmap()
> > feature, wich allows open(), mmap(), close() while the mmaped pointer is
> > valid.
> > The
On Tue, Dec 11, 2012 at 03:20:32PM -0800, Greg KH wrote:
> On Wed, Dec 12, 2012 at 12:12:02AM +0100, Benedikt Spranger wrote:
> > The inode parameter is unused by in kernel users of UIO.
>
> Ok.
>
> > Also the inode parameter makes it hard to resolve the existing open(),
> > mmap() and close()
On Tue, Dec 11, 2012 at 03:20:32PM -0800, Greg KH wrote:
On Wed, Dec 12, 2012 at 12:12:02AM +0100, Benedikt Spranger wrote:
The inode parameter is unused by in kernel users of UIO.
Ok.
Also the inode parameter makes it hard to resolve the existing open(),
mmap() and close() difficulty.
On Tue, Dec 11, 2012 at 03:18:16PM -0800, Greg KH wrote:
On Wed, Dec 12, 2012 at 12:12:01AM +0100, Benedikt Spranger wrote:
The documentation has no clear statement to the POSIX 1003.1 mmap()
feature, wich allows open(), mmap(), close() while the mmaped pointer is
valid.
The release()
-off-by: Cong Ding
Signed-off-by: "Hans J. Koch"
> ---
> drivers/uio/uio.c | 16 ++--
> 1 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> index 5110f36..79774d3 100644
> --- a/drivers/uio/uio
On Mon, Dec 10, 2012 at 12:24:04PM +0200, Vitalii Demianets wrote:
> > > > Hi Vitalii,
> > > > thanks a lot for analyzing the problem so thoroughly. It made me review
> > > > uio_pdrv_genirq.c again, and I noticed several issues and came to the
> > > > following conclusions:
> > > >
> > > > 1.)
On Mon, Dec 10, 2012 at 11:03:59AM +0200, Vitalii Demianets wrote:
> On Saturday 08 December 2012 01:47:21 Hans J. Koch wrote:
> > On Fri, Dec 07, 2012 at 05:00:54PM +0200, Vitalii Demianets wrote:
> > > > On second thought, we can't call enable_irq()/disable_irq()
> >
On Mon, Dec 10, 2012 at 11:03:59AM +0200, Vitalii Demianets wrote:
On Saturday 08 December 2012 01:47:21 Hans J. Koch wrote:
On Fri, Dec 07, 2012 at 05:00:54PM +0200, Vitalii Demianets wrote:
On second thought, we can't call enable_irq()/disable_irq()
unconditionally because
On Mon, Dec 10, 2012 at 12:24:04PM +0200, Vitalii Demianets wrote:
Hi Vitalii,
thanks a lot for analyzing the problem so thoroughly. It made me review
uio_pdrv_genirq.c again, and I noticed several issues and came to the
following conclusions:
1.) priv-lock is completely
...@gmail.com
Signed-off-by: Hans J. Koch h...@hansjkoch.de
---
drivers/uio/uio.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 5110f36..79774d3 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
ap.
> >
> > The usage here is quite strange, but it works. If I write this
> > function from zero, I will use a pointer to kobject in uio_portio
> > struct instead of kobject struct itself. In this case I can call
> > kobject_create instead of kobject_init, and then we
On Fri, Dec 07, 2012 at 05:00:54PM +0200, Vitalii Demianets wrote:
> >
> > On second thought, we can't call enable_irq()/disable_irq() unconditionally
> > because of the potential disable counter (irq_desc->depth) disbalance.
> > That's why we need UIO_IRQ_DISABLED flag, and that's why we should
On Fri, Dec 07, 2012 at 05:00:54PM +0200, Vitalii Demianets wrote:
On second thought, we can't call enable_irq()/disable_irq() unconditionally
because of the potential disable counter (irq_desc-depth) disbalance.
That's why we need UIO_IRQ_DISABLED flag, and that's why we should check it
kzalloc(uio_portio) and kfree(uio_portio) in the file uio.c.
Best,
Cong
On Fri, Nov 30, 2012 at 1:13 AM, Hans J. Koch h...@hansjkoch.de wrote:
There's still another bug: The memory allocated with kzalloc is
never freed.
--
To unsubscribe from this list: send the line unsubscribe linux
On Thu, Dec 06, 2012 at 01:44:56PM +0100, Benedikt Spranger wrote:
> After open(), mmap(), close() the mmaped pointer is valid. Removing the
> underlaying module causes a Oops or other strange effects. Keep all structures
> valid till the last user is gone.
>
> Signed-off-by: Benedikt Spranger
>
On Thu, Dec 06, 2012 at 01:44:57PM +0100, Benedikt Spranger wrote:
> A kernel module can create a uio device. Get a reference to the module, if the
> UIO device is in use. Otherwise the device can be removed and a uio write or
> an
> access to am mmaped memory can cause a kernel Oops or other
On Thu, Dec 06, 2012 at 11:11:38AM +0200, Vitalii Demianets wrote:
> On Thursday 06 December 2012 04:41:01 Hans J. Koch wrote:
> > > @@ -63,7 +68,7 @@ static irqreturn_t uio_pdrv_genirq_handler(int irq,
> struct uio_info *dev_info)
> > >* remember the state so
On Thu, Dec 06, 2012 at 11:11:38AM +0200, Vitalii Demianets wrote:
On Thursday 06 December 2012 04:41:01 Hans J. Koch wrote:
@@ -63,7 +68,7 @@ static irqreturn_t uio_pdrv_genirq_handler(int irq,
struct uio_info *dev_info)
* remember the state so we can allow user space to enable
On Thu, Dec 06, 2012 at 01:44:57PM +0100, Benedikt Spranger wrote:
A kernel module can create a uio device. Get a reference to the module, if the
UIO device is in use. Otherwise the device can be removed and a uio write or
an
access to am mmaped memory can cause a kernel Oops or other strange
On Thu, Dec 06, 2012 at 01:44:56PM +0100, Benedikt Spranger wrote:
After open(), mmap(), close() the mmaped pointer is valid. Removing the
underlaying module causes a Oops or other strange effects. Keep all structures
valid till the last user is gone.
Signed-off-by: Benedikt Spranger
On Wed, Dec 05, 2012 at 11:22:57AM +0200, Vitalii Demianets wrote:
> 1. uioinfo was kfreed based on the presence of pdev->dev.of_node, which was
> obviously wrong and unrelated to the fact if uioinfo was allocated statically
> or dynamically. This patch introduces new flag which clearly shows if
On Wed, Dec 05, 2012 at 11:22:57AM +0200, Vitalii Demianets wrote:
1. uioinfo was kfreed based on the presence of pdev-dev.of_node, which was
obviously wrong and unrelated to the fact if uioinfo was allocated statically
or dynamically. This patch introduces new flag which clearly shows if
On Thu, Nov 29, 2012 at 01:47:28PM +0200, Vitalii Demianets wrote:
> 1. uioinfo was kfreed based on the presence of pdev->dev.of_node, which was
> obviously wrong and unrelated to the fact if uioinfo was allocated statically
> or dynamically. This patch introduces new flag which clearly shows if
On Thu, Nov 29, 2012 at 01:47:28PM +0200, Vitalii Demianets wrote:
1. uioinfo was kfreed based on the presence of pdev-dev.of_node, which was
obviously wrong and unrelated to the fact if uioinfo was allocated statically
or dynamically. This patch introduces new flag which clearly shows if
On Mon, Dec 03, 2012 at 10:53:45AM +0200, Vitalii Demianets wrote:
> > On Friday 30 November 2012 23:39:06 Hans J. Koch wrote:
> > > Thanks a lot for reporting and discussing that problem. I'll add a
> > >
> > > Reported-by: Vitalii Demianets
>
On Mon, Dec 03, 2012 at 10:53:45AM +0200, Vitalii Demianets wrote:
On Friday 30 November 2012 23:39:06 Hans J. Koch wrote:
Thanks a lot for reporting and discussing that problem. I'll add a
Reported-by: Vitalii Demianets vi...@nppfactor.kiev.ua
if you have no objections
On Sat, Dec 01, 2012 at 09:58:32AM +, Cong Ding wrote:
> If it is really necessary to save the 4 lines of codes, I would suggest to do
> in the following style. But you are more senior than me, so I may be wrong in
> this aspect.
"Seniority" (whatever you mean by that) has got nothing to
In two cases, the return value variable "ret" can be undefined.
Signed-off-by: Hans J. Koch
Reported-by: Vitalii Demianets
---
drivers/uio/uio.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 5110f36..0c80
In two cases, the return value variable ret can be undefined.
Signed-off-by: Hans J. Koch h...@hansjkoch.de
Reported-by: Vitalii Demianets vi...@nppfactor.kiev.ua
---
drivers/uio/uio.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio
On Sat, Dec 01, 2012 at 09:58:32AM +, Cong Ding wrote:
If it is really necessary to save the 4 lines of codes, I would suggest to do
in the following style. But you are more senior than me, so I may be wrong in
this aspect.
Seniority (whatever you mean by that) has got nothing to do
On Sat, Dec 01, 2012 at 02:22:44AM +0100, Cong Ding wrote:
> On Fri, Nov 30, 2012 at 10:33 PM, Hans J. Koch wrote:
> > On Fri, Nov 30, 2012 at 12:12:46PM +0100, Tux9 wrote:
> >> I like Vitalii's solution more. Hans's solution assign the value
> >> -ENOMEM to ret in eve
On Fri, Nov 30, 2012 at 01:16:19PM +0200, Vitalii Demianets wrote:
> On Friday 30 November 2012 01:58:22 Hans J. Koch wrote:
> > On Thu, Nov 29, 2012 at 06:36:59PM +0200, Vitalii Demianets wrote:
> > > > On Thursday 29 November 2012 18:05:27 Tux9 wrote:
> > > > &g
d
1 files changed, 2 insertions(+), 0 deletions(-)
is more important. Note that this code is not in a fast path but only
called once at device creation.
Thanks,
Hans
>
> On Fri, Nov 30, 2012 at 12:58 AM, Hans J. Koch wrote:
> > On Thu, Nov 29, 2012 at 06:36:59PM +0200, Vi
, 2 insertions(+), 0 deletions(-)
is more important. Note that this code is not in a fast path but only
called once at device creation.
Thanks,
Hans
On Fri, Nov 30, 2012 at 12:58 AM, Hans J. Koch h...@hansjkoch.de wrote:
On Thu, Nov 29, 2012 at 06:36:59PM +0200, Vitalii Demianets wrote
On Fri, Nov 30, 2012 at 01:16:19PM +0200, Vitalii Demianets wrote:
On Friday 30 November 2012 01:58:22 Hans J. Koch wrote:
On Thu, Nov 29, 2012 at 06:36:59PM +0200, Vitalii Demianets wrote:
On Thursday 29 November 2012 18:05:27 Tux9 wrote:
Hans, I think there are something wrong
On Sat, Dec 01, 2012 at 02:22:44AM +0100, Cong Ding wrote:
On Fri, Nov 30, 2012 at 10:33 PM, Hans J. Koch h...@hansjkoch.de wrote:
On Fri, Nov 30, 2012 at 12:12:46PM +0100, Tux9 wrote:
I like Vitalii's solution more. Hans's solution assign the value
-ENOMEM to ret in every round of the loop
On Thu, Nov 29, 2012 at 05:40:00PM +, Cong Ding wrote:
> In version 1, I forgot to modify the same bug in the first loop.
>
> we have to call kobject_put() to clean up the kobject after function
> kobject_init(), kobject_add(), or kobject_uevent() is called.
Yes, thanks. Incredible how that
irst iteration (mi == 0), so Hans's
> approach does not work.
> I must do more thinking before replying in a hurry.
You're right. Initialization of "ret" has to take place at the beginning of
the loop.
I think this version is right:
>From 00c3c734c0dde67873a628bcb18cee403c95c301 Mon
at the beginning of
the loop.
I think this version is right:
From 00c3c734c0dde67873a628bcb18cee403c95c301 Mon Sep 17 00:00:00 2001
From: Hans J. Koch h...@hansjkoch.de
Date: Fri, 30 Nov 2012 00:51:50 +0100
Subject: [PATCH] uio: Fix warning: 'ret' might be used uninitialized
In two cases, the return
On Thu, Nov 29, 2012 at 05:40:00PM +, Cong Ding wrote:
In version 1, I forgot to modify the same bug in the first loop.
we have to call kobject_put() to clean up the kobject after function
kobject_init(), kobject_add(), or kobject_uevent() is called.
Yes, thanks. Incredible how that code
On Wed, Nov 28, 2012 at 11:37:23AM +0200, Vitalii Demianets wrote:
> On Wednesday 28 November 2012 02:37:50 Hans J. Koch wrote:
> >
> > In other words, the case of uioinfo AND pdev->dev.of_node both being NULL
> > is not handled properly and will have ugly results.
>
On Wed, Nov 28, 2012 at 10:29:29AM +0100, Cong Ding wrote:
> On Wed, Nov 28, 2012 at 1:37 AM, Hans J. Koch wrote:
> > On Wed, Nov 28, 2012 at 01:07:26AM +0100, Cong Ding wrote:
> >> On Wed, Nov 28, 2012 at 12:07 AM, Hans J. Koch wrote:
> >> > On Tue, Nov 27, 201
On Wed, Nov 28, 2012 at 10:58:32AM +0200, Vitalii Demianets wrote:
> On Wednesday 28 November 2012 00:43:41 Hans J. Koch wrote:
> >
> > Thanks, good catch, but why don't you simply do this:
> >
>
> Just a matter of personal preference.
Your patch: 1 files changed, 12
On Wed, Nov 28, 2012 at 10:58:32AM +0200, Vitalii Demianets wrote:
On Wednesday 28 November 2012 00:43:41 Hans J. Koch wrote:
Thanks, good catch, but why don't you simply do this:
Just a matter of personal preference.
Your patch: 1 files changed, 12 insertions(+), 4 deletions(-)
My
On Wed, Nov 28, 2012 at 10:29:29AM +0100, Cong Ding wrote:
On Wed, Nov 28, 2012 at 1:37 AM, Hans J. Koch h...@hansjkoch.de wrote:
On Wed, Nov 28, 2012 at 01:07:26AM +0100, Cong Ding wrote:
On Wed, Nov 28, 2012 at 12:07 AM, Hans J. Koch h...@hansjkoch.de wrote:
On Tue, Nov 27, 2012 at 07:29
On Wed, Nov 28, 2012 at 11:37:23AM +0200, Vitalii Demianets wrote:
On Wednesday 28 November 2012 02:37:50 Hans J. Koch wrote:
In other words, the case of uioinfo AND pdev-dev.of_node both being NULL
is not handled properly and will have ugly results.
Moreover, the case of (uioinfo
On Wed, Nov 28, 2012 at 01:07:26AM +0100, Cong Ding wrote:
> On Wed, Nov 28, 2012 at 12:07 AM, Hans J. Koch wrote:
> > On Tue, Nov 27, 2012 at 07:29:32PM +0200, Vitalii Demianets wrote:
> >> Memory leak was caused by jumping to the wrong exit label. So, it is good
> &g
On Tue, Nov 27, 2012 at 07:29:32PM +0200, Vitalii Demianets wrote:
> Memory leak was caused by jumping to the wrong exit label. So, it is good time
> to improve misleading label names too.
I agree that bad0, bad1, and bad2 are not the best choice for label names...
I don't have any objections to
goto err_portio;
> + }
> kobject_init(>kobj, _attr_type);
> portio->port = port;
> port->portio = portio;
> --
> 1.7.8.6
>
Thanks, good catch, but why don't you simply do this:
>From 228445996bb7
you simply do this:
From 228445996bb75a44d16b6237eca6a0916d9b2d7e Mon Sep 17 00:00:00 2001
From: Hans J. Koch h...@hansjkoch.de
Date: Tue, 27 Nov 2012 23:38:00 +0100
Subject: [PATCH] uio: Fix warning: 'ret' might be used uninitialized
In two cases, the return value variable ret can be undefined
On Tue, Nov 27, 2012 at 07:29:32PM +0200, Vitalii Demianets wrote:
Memory leak was caused by jumping to the wrong exit label. So, it is good time
to improve misleading label names too.
I agree that bad0, bad1, and bad2 are not the best choice for label names...
I don't have any objections to
On Wed, Nov 28, 2012 at 01:07:26AM +0100, Cong Ding wrote:
On Wed, Nov 28, 2012 at 12:07 AM, Hans J. Koch h...@hansjkoch.de wrote:
On Tue, Nov 27, 2012 at 07:29:32PM +0200, Vitalii Demianets wrote:
Memory leak was caused by jumping to the wrong exit label. So, it is good
time
to improve
On Fri, Nov 09, 2012 at 07:06:40AM +0100, Manuel Traut wrote:
> If uio_pdrv[_genirq] is used, the uio maps have currently no name set.
> This patch sets the uio_mem name to the name of the memory resource.
Looks fine to me. I added the driver's authors to Cc.
Signed-off-by: "H
On Fri, Nov 09, 2012 at 07:06:40AM +0100, Manuel Traut wrote:
If uio_pdrv[_genirq] is used, the uio maps have currently no name set.
This patch sets the uio_mem name to the name of the memory resource.
Looks fine to me. I added the driver's authors to Cc.
Signed-off-by: Hans J. Koch h
; > Signed-off-by: Matt Porter
>
> Hans,
>
> Any additional concerns on this patch?
Not from my side. I was waiting for your discussion to calm down.
> Sekhar is holding off on applying
> parts 4,5,7 for davinci until this is accepted.
You can add my
Signed-off-by:
Hans,
Any additional concerns on this patch?
Not from my side. I was waiting for your discussion to calm down.
Sekhar is holding off on applying
parts 4,5,7 for davinci until this is accepted.
You can add my
Signed-off-by: Hans J. Koch h...@hansjkoch.de
Thanks,
Hans
Thanks,
Matt
On Wed, Sep 26, 2012 at 09:44:29AM -0400, Matt Porter wrote:
> Add ifdefery hacks to only use SRAM on Davinci. This
> needs to be cleaned up with a sane generic SRAM allocator
> (like the DT based driver available that can't be used on
> Davinci which is just starting DT conversion) before it
>
On Tue, Sep 25, 2012 at 03:09:12PM +0900, Damian Hobson-Garcia wrote:
> Signed-off-by: Damian Hobson-Garcia
Signed-off-by: "Hans J. Koch"
> ---
> Documentation/DocBook/uio-howto.tmpl | 56
> ++
> 1 files changed, 56 insertions(+),
erspace via /sys/class/uio/uioX/maps/mapY/addr in the same way as
> static addresses are when the uio device file is open, when no processes
> are holding the device file open, the address returned to userspace is
> DMA_ERROR_CODE.
>
> Signed-off-by: Damian Hobson-Garcia
Thanks f
in the same way as
static addresses are when the uio device file is open, when no processes
are holding the device file open, the address returned to userspace is
DMA_ERROR_CODE.
Signed-off-by: Damian Hobson-Garcia dhobs...@igel.co.jp
Thanks for your contribution!
Signed-off-by: Hans J. Koch h
On Tue, Sep 25, 2012 at 03:09:12PM +0900, Damian Hobson-Garcia wrote:
Signed-off-by: Damian Hobson-Garcia dhobs...@igel.co.jp
Signed-off-by: Hans J. Koch h...@hansjkoch.de
---
Documentation/DocBook/uio-howto.tmpl | 56
++
1 files changed, 56 insertions
On Wed, Sep 26, 2012 at 09:44:29AM -0400, Matt Porter wrote:
Add ifdefery hacks to only use SRAM on Davinci. This
needs to be cleaned up with a sane generic SRAM allocator
(like the DT based driver available that can't be used on
Davinci which is just starting DT conversion) before it
can go
On Wed, Sep 12, 2012 at 02:29:43PM +0900, Damian Hobson-Garcia wrote:
> Reposting: I realized that this series should have gone out to a broader list.
You forgot GregKH, I added him.
> My apologies to those who those who will recieve a duplicate post.
>
> Hello all,
>
> I've been using this
On Wed, Sep 12, 2012 at 02:29:43PM +0900, Damian Hobson-Garcia wrote:
Reposting: I realized that this series should have gone out to a broader list.
You forgot GregKH, I added him.
My apologies to those who those who will recieve a duplicate post.
Hello all,
I've been using this UIO
On Thu, Aug 30, 2012 at 11:03:04PM +, Worth, Kevin wrote:
> >
> >> but the code seems like
> >> possibly useful sample/example code.
> >
> >That is another good argument.
>
> Perhaps this could be genericized to be a generic "Memory Map Userspace
> IO Device" that takes a base address and a
On Thu, Aug 30, 2012 at 11:03:04PM +, Worth, Kevin wrote:
but the code seems like
possibly useful sample/example code.
That is another good argument.
Perhaps this could be genericized to be a generic Memory Map Userspace
IO Device that takes a base address and a length in config
[Added Greg Kroah-Hartman to Cc:]
On Thu, Aug 30, 2012 at 08:10:11PM +, Worth, Kevin wrote:
> >> Thanks for the reply, Hans. Your question about opening /dev/uio0 O_RDWR
> >> prompted me to check out how I was creating /dev/uio0 ... my system
> >> isn't using udev, and I was accidentally
On Thu, Aug 30, 2012 at 06:36:53PM +, Worth, Kevin wrote:
> Thanks for the reply, Hans. Your question about opening /dev/uio0 O_RDWR
> prompted me to check out how I was creating /dev/uio0 ... my system
> isn't using udev, and I was accidentally creating it with major/minor
> number 254/0
On Thu, Aug 30, 2012 at 06:36:53PM +, Worth, Kevin wrote:
Thanks for the reply, Hans. Your question about opening /dev/uio0 O_RDWR
prompted me to check out how I was creating /dev/uio0 ... my system
isn't using udev, and I was accidentally creating it with major/minor
number 254/0 instead
[Added Greg Kroah-Hartman to Cc:]
On Thu, Aug 30, 2012 at 08:10:11PM +, Worth, Kevin wrote:
Thanks for the reply, Hans. Your question about opening /dev/uio0 O_RDWR
prompted me to check out how I was creating /dev/uio0 ... my system
isn't using udev, and I was accidentally creating it
[Added driver author to Cc:]
On Wed, Aug 29, 2012 at 11:19:00PM +, Worth, Kevin wrote:
> I have below what appears to be a mostly-functional device using the UIO
> Platform Driver. The /sys entries I'd expect appear, /proc/iomem contains "
> d000-dfff : myfpga", and lsuio sees the
[Added driver author to Cc:]
On Wed, Aug 29, 2012 at 11:19:00PM +, Worth, Kevin wrote:
I have below what appears to be a mostly-functional device using the UIO
Platform Driver. The /sys entries I'd expect appear, /proc/iomem contains
d000-dfff : myfpga, and lsuio sees the
On Wed, Jul 18, 2012 at 12:40:47PM +0200, Dominic Eschweiler wrote:
> Am Montag, den 16.07.2012, 23:58 +0200 schrieb Hans J. Koch:
> > Try to hack up a patch to add generic BAR mapping to uio_pci_generic.c
> > and post it for review.
> >
>
> Here we go ...
Thank you v
On Wed, Jul 18, 2012 at 12:40:47PM +0200, Dominic Eschweiler wrote:
Am Montag, den 16.07.2012, 23:58 +0200 schrieb Hans J. Koch:
Try to hack up a patch to add generic BAR mapping to uio_pci_generic.c
and post it for review.
Here we go ...
Thank you very much for your work. I'm really
On Wed, Jul 18, 2012 at 12:40:47PM +0200, Dominic Eschweiler wrote:
> Am Montag, den 16.07.2012, 23:58 +0200 schrieb Hans J. Koch:
> > Try to hack up a patch to add generic BAR mapping to uio_pci_generic.c
> > and post it for review.
> >
>
> Here we go ...
Great! I'
On Wed, Jul 18, 2012 at 12:40:47PM +0200, Dominic Eschweiler wrote:
Am Montag, den 16.07.2012, 23:58 +0200 schrieb Hans J. Koch:
Try to hack up a patch to add generic BAR mapping to uio_pci_generic.c
and post it for review.
Here we go ...
Great! I'm a bit under time pressure with my
On Mon, Jul 16, 2012 at 08:16:12PM +0200, Dominic Eschweiler wrote:
> Am Freitag, den 13.07.2012, 21:19 +0300 schrieb Michael S. Tsirkin:
> >
> > UIO has the same property, doesn't it? Multiple users can
> > access device memory through sysfs.
>
>
> Indeed, that's a similar problem. I haven't
On Mon, Jul 16, 2012 at 08:16:12PM +0200, Dominic Eschweiler wrote:
Am Freitag, den 13.07.2012, 21:19 +0300 schrieb Michael S. Tsirkin:
UIO has the same property, doesn't it? Multiple users can
access device memory through sysfs.
Indeed, that's a similar problem. I haven't tried it
1 - 100 of 112 matches
Mail list logo
