lkml.org 
[lkml]   [2008]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [git patch] free_irq() fixes
Linus Torvalds wrote:
> The absolutely _only_ piece of reliably information we have that is
> architecture- and irq-controller neutral is the exact information we pass
> in to "request_irq()". That is: irq number, the name, and the device
> cookie thing. Nothing more.

Agreed.

However, it does not follow that an int is what _must_ be passed around.
We already have design patterns like

cookie_pointer = ioremap(raw bus resource)

Not that I am the one pushing for that, just noting.

Overall this is all wild-assed speculation based on a thought
exploration (#irq-remove) that a several kernel hackers seemed to like.


> - the "device cookie". This is the thing that the system itself doesn't
> care about, and is _entirely_ under control of the driver, so the
> driver can pass its own interrupt controller some helpful instance
> pointers.
>
> So of the three, "device cookie" is the one that we absolutely have to
> have. The irq number is not necessary, but it does actually have some
> meaning especially for legacy devices (eg ISA), and it is at least
> _sensible_ to pass around (ie it has no downsides, and it's not
> fundamentally broken). And the name would be just stupid.

Agreed.


> EVERYTHING else would be architecture-specific. And that is exactly what
> we do not want. EVER.

Not true -- you have metadata/OOB data like MSI messages, where you are
passed a value from the PCI hardware in the PCI message, not just an
"interrupt asserted" condition. Or s/value/values/ if you enable PCI
MSI's multiple message support.

The PCI devices themselves are moving from sending a single bit of
information ("irq!") to sending actual messages.

That is not arch-specific at all, but a new model for "interrupt" (i.e.
event) notification being pushed upon us.

Jeff




\
 
 \ /
  Last update: 2008-04-24 17:43    [W:0.072 / U:0.820 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site