linux-kernel - Re: Generic VME UIO 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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <55ACACA7.6020006@ge.com>
Date:	Mon, 20 Jul 2015 09:09:11 +0100
From:	Martyn Welch <martyn.welch@...com>
To:	Dmitry Kalinkin <dmitry.kalinkin@...il.com>
CC:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	<linux-kernel@...r.kernel.org>, <devel@...verdev.osuosl.org>,
	Manohar Vanga <manohar.vanga@...il.com>,
	Igor Alekseev <igor.alekseev@...p.ru>
Subject: Re: Generic VME UIO driver



On 08/07/15 16:02, Dmitry Kalinkin wrote:
>
>> On 08 Jul 2015, at 16:22, Martyn Welch <martyn.welch@...com> wrote:
>>
>> On 06/07/15 18:24, Dmitry Kalinkin wrote:
>>>> Some functionality was dropped as it was not good practice
>>>>> (such as receiving VME interrupts in user space, it's not really doable if
>>>>> the slave card is Release On Register Access rather than Release on
>>>>> Acknowledge),
>>> Didn't know about RORA. I wonder how different this is compared to the
>>> PCI bus case.
>>
>> Little I suspect. What it does mean is that there's no generic mechanism for clearing down an interrupt, so a device specific interrupt routine is required, which needs to be in kernel space.
> Yet PCI somehow managed to settle with UIO.

"If, on the other hand, your hardware needs some action to be performed 
after each interrupt, then you must do it in your kernel module."

https://www.kernel.org/doc/htmldocs/uio-howto/adding_irq_handler.html

> Now imagine I am working with a board using vme_user API and I need to
> implement interrupts. The PCI case teaches me that I need to write a board specific
> UIO driver. My board is ROAK and allows to configure it's interrupt to any level and
> any status/id. So I only use a standard vme_irq_request API that generates IACK
> cycle for me automatically. I also don’t want to limit my end user with a choice of
> interrupt level and status/id and so I make it configurable. In the end I’ve got a very
> generic ROAK device driver. What did I do wrong?
>

Nothing by the sounds of it. If you have ROAK hardware, life is a lot 
simpler.

Martyn

> Cheers,
> Dmitry
>

-- 
Martyn Welch (Lead Software Engineer)  | Registered in England and Wales
GE Intelligent Platforms               | (3828642) at 100 Barbirolli Square
T +44(0)1327322748                     | Manchester, M2 3AB
E martyn.welch@...com                  | VAT:GB 927559189
--
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/