linux-kernel - Re: [PATCH 00/03][RFC] Reusable UIO Platform Driver

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: <aec7e5c30805210456r6f09b1a4sfef5bcefc82f5ba6@mail.gmail.com>
Date:	Wed, 21 May 2008 20:56:07 +0900
From:	"Magnus Damm" <magnus.damm@...il.com>
To:	"Uwe Kleine-König" <Uwe.Kleine-Koenig@...i.com>
Cc:	"Hans J. Koch" <hjk@...utronix.de>, linux-kernel@...r.kernel.org,
	lethal@...ux-sh.org, gregkh@...e.de, linux-sh@...r.kernel.org
Subject: Re: [PATCH 00/03][RFC] Reusable UIO Platform Driver

On Wed, May 21, 2008 at 8:04 PM, Uwe Kleine-König
<Uwe.Kleine-Koenig@...i.com> wrote:
> Magnus Damm wrote:
>> What about letting the uio_pdrv code override info->handler and
>> info->enable_irq with the above functions if info->handler is NULL?
> ... if both info->handler and info->prep_read_poll are NULL and
> info->irq >= 0.

Even better! =)

>> The physically contiguous memory issue still needs to be solved
>> somehow though. What about using struct resouce flagged as
>> IORESOURCE_DMA to pass the amount of memory that should be allocated?
> I'm not sure that solving that problem in uio_pdrv is the right
> approach.  Other uio drivers might have the same problem, so better
> allow the userspace driver to allocate some memory in a more generic
> way?

I don't think there is any generic way for a user space driver to
allocate physically contiguous memory. If such way exists then we
should use that instead of course. Recommendations anyone?

>> Regarding loosing information, if your hardware device can't cope with
>> long latencies and drops things on the floor then improve your
>> latency, increase buffer size or design better hardware. Also, I don't
>> think the interrupt can go berserk since it will be disabled directly
>> by the interrupt handler.
> Assume your irq is stuck at its active level.  Normally the irq is
> then disabled after some time.  You can handle that in your userspace
> driver, but with acking in kernel space and returning IRQ_NONE or
> IRQ_HANDLED you get it for free.  Nevertheless, go on.

Ok, so normally if the irq is stuck as asserted then it gets disabled
after some time. In my case it gets disabled directly so see it as a
feature. =)

Would you like to fold in the irq_handler and irq_enable function in
your patch, or would you like me to make a patch that fits on top of
your latest version?

Thanks for your help!

/ magnus
--
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/