[PATCH] S390: Fix libphy link failure

[PATCH] S390: Fix libphy link failure

[Jean Delvare]

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.

 drivers/net/phy/Kconfig |    1 +
 1 file changed, 1 insertion(+)

--- linux-3.10-rc0.orig/drivers/net/phy/Kconfig	2013-04-29 02:36:01.000000000 +0200
+++ linux-3.10-rc0/drivers/net/phy/Kconfig	2013-05-06 10:34:41.141846466 +0200
@@ -5,6 +5,7 @@
 menuconfig PHYLIB
 	tristate "PHY Device support and infrastructure"
 	depends on NETDEVICES
+	depends on !S390 || PCI
 	help
 	  Ethernet controllers are usually attached to PHY
 	  devices.  This option provides infrastructure for

-- 
Jean Delvare
Suse L3

Re: [PATCH] S390: Fix libphy link failure

[David Miller]

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.

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.

Thanks.

Re: [PATCH] S390: Fix libphy link failure

[Jean Delvare]

Hi David,

Le Monday 06 May 2013 à 11:00 -0400, David Miller a écrit :
> 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.
> 
> 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.

Fair enough, I tend to agree with you. S390 isn't my thing in the first
place. I was only trying to help fix a build regression (make
allmodconfig fails on 32-bit S390.)

-- 
Jean Delvare
Suse L3

Re: [PATCH] S390: Fix libphy link failure

[Heiko Carstens]

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;
}

?

Re: [PATCH] S390: Fix libphy link failure

[David Miller]

From: Heiko Carstens <heiko.carstens@de.ibm.com>
Date: Mon, 6 May 2013 17:49:31 +0200

> 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;
> }
> 
> ?

It's your architecture, so I really don't care.

All I care is that we don't see S390 blobs any more in driver/net/
Kconfig's :-)