[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2acbd3e40810141621p31ba3ccdic909fc4634b5ef26@mail.gmail.com>
Date: Tue, 14 Oct 2008 18:21:44 -0500
From: "Andy Fleming" <afleming@...il.com>
To: "David Miller" <davem@...emloft.net>
Cc: afleming@...escale.com, netdev@...r.kernel.org
Subject: Re: [PATCH] Change S390 anti-dependency to CONFIG_GENERIC_HARDIRQS dependency
On Tue, Oct 14, 2008 at 5:44 PM, David Miller <davem@...emloft.net> wrote:
> From: Andy Fleming <afleming@...escale.com>
> Date: Tue, 14 Oct 2008 17:28:13 -0500
>
>> PHY Lib and DSA expect request_irq and other such functions to exist.
>> S390 doesn't support those functions, however we should mark the actual
>> dependency, which is generic hardirq support, rather than explicitly
>> depend on !S390.
>>
>> Signed-off-by: Andy Fleming <afleming@...escale.com>
>> ---
>> This makes more sense to me, but I could be missing something?
>
> GENERIC_HARDIRQS is not the correct dependency.
>
> Not all architectures use the generic IRQ layer, yet have
> support for interrupts (request_irq(), free_irq(), etc.)
>
> Two such platforms are 32-bit sparc and m68k.
Argh. From what I could see, we have request_irq, free_irq,
disable_irq, enable_irq, and disable_irq_nosync. For the PHYLIB, it
shouldn't be difficult to modify things so that it doesn't compile in
interrupt support if the system doesn't support them. Shouldn't, that
is, if there's some config option that tells me whether those
functions exist.
Would it be acceptable to create a config option which *did* convey
this meaning? Off the top of my head I can imagine either having
s390's Kconfig declare NO_HARDIRQ_SUPPORT. Alternatively, it would be
less trivial, but fairly easy to create a config option,
HARDIRQ_SUPPORT, which is either selected by arches which define their
own request_irq, etc functions, or automatically selected when
GENERIC_HARDIRQS is selected.
Andy
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists