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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ