From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: David Miller <davem@davemloft.net>
Cc: jdelvare@suse.de, netdev@vger.kernel.org,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Gerald Schaefer <gerald.schaefer@de.ibm.com>,
Sebastian Ott <sebott@linux.vnet.ibm.com>
Subject: Re: [PATCH] S390: Fix libphy link failure
Date: Mon, 6 May 2013 17:49:31 +0200 [thread overview]
Message-ID: <20130506154931.GA8453@osiris> (raw)
In-Reply-To: <20130506.110011.1813294677998011362.davem@davemloft.net>
On Mon, May 06, 2013 at 11:00:11AM -0400, David Miller wrote:
> From: Jean Delvare <jdelvare@suse.de>
> Date: Mon, 06 May 2013 16:53:39 +0200
>
> > On S390 basic IRQ functions are provided by the PCI subsystem, so
> > code which calls these cannot be built if PCI support was not
> > selected.
> >
> > Signed-off-by: Jean Delvare <jdelvare@suse.de>
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> > ---
> > I know this isn't nice, but in the current state of S390 support
> > this is all I can offer.
>
> I really am tired of all of these special S390 dependencies.
>
> You can't say this is a new problem, because we've been hitting this
> issue repeatedly for more than a decade. And I don't want to hear any
> excuses, we've all already invested enough time into this to prove
> that catering to S390's weird build limitations is a never ending
> burdon for non-s390 people.
Agreed. And you won't hear any excuses since I'm tired of adding these
Kconfig dependencies as well.
Unfortunately it got worse instead of better since we support CONFIG_PCI.
> Really, our interfaces are abstract enough that every driver ought to
> be buildable on every architecture.
>
> It's time to put the burdon on your side, if you don't support some
> IRQ interface or whatever, provide a stub that returns an error
> rather than being that "special architecture" that everything else
> has to specially cater for with ugly Kconfig dependencies.
Actually I'm in favor of supplying some stupid IRQ stubs as well.
Unless our PCI guys think that we can go for GENERIC_HARDIRQS.
But that will only work for 64 bit configs, not 31 bit.
So you wouldn't mind some stupid stubs like
request_irq(unsigned int irq, irq_handler_t handler, unsigned long flags,
const char *name, void *dev) {
return -EWHATEVER;
}
?
next prev parent reply other threads:[~2013-05-06 15:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-06 14:53 [PATCH] S390: Fix libphy link failure Jean Delvare
2013-05-06 15:00 ` David Miller
2013-05-06 15:17 ` Jean Delvare
2013-05-06 15:49 ` Heiko Carstens [this message]
2013-05-06 16:00 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130506154931.GA8453@osiris \
--to=heiko.carstens@de.ibm.com \
--cc=davem@davemloft.net \
--cc=gerald.schaefer@de.ibm.com \
--cc=jdelvare@suse.de \
--cc=netdev@vger.kernel.org \
--cc=schwidefsky@de.ibm.com \
--cc=sebott@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox