ret = -ENOMEM;
> goto err_portio;
> + }
> kobject_init(&portio->kobj, &portio_attr_type);
> portio->port = port;
> port->portio = portio;
> --
> 1.7.8.6
>
Thanks, goo
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 y
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 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 change
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 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.
> &
idden at first 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 00c3c734c0dde67873a628bcb
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 c
[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 p
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 inste
[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 creat
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 l
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 UI
ions(-) and
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, Vit
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
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
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..0c80df2 10
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 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 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 ui
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 ui
; > 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:
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
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 stra
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 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 ch
uio_map.
> >
> > 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 the
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 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.) pri
-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 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() di
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 rele
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 i
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: &q
INERS
> 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"
&
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 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
Am Sat, 16 Feb 2008 18:29:39 -0800
schrieb Arjan van de Ven <[EMAIL PROTECTED]>:
> On Sun, 17 Feb 2008 01:54:53 +0100
> Hans-Jürgen Koch <[EMAIL PROTECTED]> wrote:
>
> > Am Sat, 16 Feb 2008 14:39:46 -0800
> > schrieb Arjan van de Ven <[EMAIL PROTECTED]>:
> >
> > > On Sat, 16 Feb 2008 22:59:32 +0
Am Sun, 17 Feb 2008 07:29:27 -0800
schrieb Arjan van de Ven <[EMAIL PROTECTED]>:
> On Sun, 17 Feb 2008 13:37:53 +0100
> "Hans J. Koch" <[EMAIL PROTECTED]> wrote:
> > > Of course there's no driver for the wlan, but that's a different
> > > st
Am Sun, 17 Feb 2008 07:29:27 -0800
schrieb Arjan van de Ven <[EMAIL PROTECTED]>:
> On Sun, 17 Feb 2008 13:37:53 +0100
> "Hans J. Koch" <[EMAIL PROTECTED]> wrote:
> > > Of course there's no driver for the wlan, but that's a different
> > > st
On Thu, Jul 12, 2012 at 09:26:23AM +0200, Andreas Schallenberg wrote:
[Added more people to Cc:]
> Hello,
>
> I'm doing experiments with the Userspace IO driver (UIO_PCI_GENERIC)
> and a set of PCIe cards. The kernel version is 3.4.4, CPU is a
> Marvell MV78200 (ARMv5te). Example with an Intel e
On Fri, Jul 13, 2012 at 02:16:32AM +0300, Michael S. Tsirkin wrote:
> On Thu, Jul 12, 2012 at 09:44:33PM +0200, Hans J. Koch wrote:
> > > Looking further at the code, I cannot see where the mem fields are
> > > being filled at all.
> > > Which code is suppos
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 ver
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 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 unsubscr
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 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 ui
5:59 +0100)
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 u
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
he userspace 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
Tha
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(+),
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
On Fri, Jul 13, 2012 at 04:22:23PM +0300, Michael S. Tsirkin wrote:
> On Fri, Jul 13, 2012 at 10:09:15AM +0200, Dominic Eschweiler wrote:
> > Am Freitag, den 13.07.2012, 02:16 +0300 schrieb Michael S. Tsirkin:
> > > My concern was people will ask for more and more stuff that pci
> > > sysfs already
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 t
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&
uot;.
> 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
>
56 matches
Mail list logo
