[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20081014.165211.53009170.davem@davemloft.net>
Date: Tue, 14 Oct 2008 16:52:11 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: csnook@...hat.com
Cc: afleming@...il.com, afleming@...escale.com, netdev@...r.kernel.org
Subject: Re: [PATCH] Change S390 anti-dependency to CONFIG_GENERIC_HARDIRQS
dependency
From: Chris Snook <csnook@...hat.com>
Date: Tue, 14 Oct 2008 19:43:05 -0400
> David Miller wrote:
> > From: "Andy Fleming" <afleming@...il.com>
> > Date: Tue, 14 Oct 2008 18:21:44 -0500
> >
> >> 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.
> > I think this whole situation with s390 is rediculious.
> > If s390 is weird and lacks these fundamental things, that's fine.
> > What isn't fine is how we're handling this.
> > No code should care or even be aware of this.
> > S390 should simply provide a set of dummy DMA and interrupt interface
> > stubs that always fail and return an error value.
> > Then we can get rid of this S390 Kconfig stuff which has been spewed
> > all over the place.
>
> "depends on PCI" has always worked for me. Any reason we can't use that here?
That's every worse.
What in the world does PCI have to do with the attribute we are
trying to depend upon here?
No, it's just stupid. Add nop do-nothing stub functions for the
APIs an architecture doesn't support, then we need none of this.
--
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