| Message ID | 20140414153849.7138699b@endymion.delvare |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
From: Jean Delvare <jdelvare@suse.de> Date: Mon, 14 Apr 2014 15:38:49 +0200 > The Cadence ethernet chipsets are only used on specific ARM > architectures. Add Kconfig dependencies so that drivers for these > chipsets are only buildable on the relevant architectures. > > Signed-off-by: Jean Delvare <jdelvare@suse.de> Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Apr 14, 2014 at 03:38:49PM +0200, Jean Delvare wrote: > The Cadence ethernet chipsets are only used on specific ARM > architectures. Add Kconfig dependencies so that drivers for these > chipsets are only buildable on the relevant architectures. Are you sure they're not used on any of the FPGA platforms like Microblaze? Cadence are an IP company, might be worth having a FPGA Kconfig that architectures commonly deployed with lots of soft IPs can select and the IPs depend on rather than building a custom list for each IP.
On 04/22/2014 10:32 PM, Mark Brown wrote: > On Mon, Apr 14, 2014 at 03:38:49PM +0200, Jean Delvare wrote: >> The Cadence ethernet chipsets are only used on specific ARM >> architectures. Add Kconfig dependencies so that drivers for these >> chipsets are only buildable on the relevant architectures. > > Are you sure they're not used on any of the FPGA platforms like > Microblaze? Cadence are an IP company, might be worth having a FPGA > Kconfig that architectures commonly deployed with lots of soft IPs can > select and the IPs depend on rather than building a custom list for each > IP. macb driver can be used by Microblaze too. Thanks, Michal
Hi Mark, Michal, On Wed, 23 Apr 2014 09:16:49 +0200, Michal Simek wrote: > On 04/22/2014 10:32 PM, Mark Brown wrote: > > On Mon, Apr 14, 2014 at 03:38:49PM +0200, Jean Delvare wrote: > >> The Cadence ethernet chipsets are only used on specific ARM > >> architectures. Add Kconfig dependencies so that drivers for these > >> chipsets are only buildable on the relevant architectures. > > > > Are you sure they're not used on any of the FPGA platforms like > > Microblaze? I'm not sure of anything, embedded isn't my area. > > Cadence are an IP company, I can't parse this, sorry. What is an "IP company"? > > might be worth having a FPGA > > Kconfig that architectures commonly deployed with lots of soft IPs can > > select and the IPs depend on rather than building a custom list for each > > IP. What are "soft IPs"? I'm afraid I wouldn't be able to translate your proposal into a patch, I just don't understand what you mean exactly. > macb driver can be used by Microblaze too. Thanks for the information. I will send a patch adding MICROBLAZE to the dependencies. Out of curiosity, is there any way I could have found out by myself?
On 04/23/2014 09:40 AM, Jean Delvare wrote: > Hi Mark, Michal, > > On Wed, 23 Apr 2014 09:16:49 +0200, Michal Simek wrote: >> On 04/22/2014 10:32 PM, Mark Brown wrote: >>> On Mon, Apr 14, 2014 at 03:38:49PM +0200, Jean Delvare wrote: >>>> The Cadence ethernet chipsets are only used on specific ARM >>>> architectures. Add Kconfig dependencies so that drivers for these >>>> chipsets are only buildable on the relevant architectures. >>> >>> Are you sure they're not used on any of the FPGA platforms like >>> Microblaze? > > I'm not sure of anything, embedded isn't my area. > >>> Cadence are an IP company, > > I can't parse this, sorry. What is an "IP company"? Company which is creating this piece of HW which is called IP. >>> might be worth having a FPGA >>> Kconfig that architectures commonly deployed with lots of soft IPs can >>> select and the IPs depend on rather than building a custom list for each >>> IP. > > What are "soft IPs"? I'm afraid I wouldn't be able to translate your > proposal into a patch, I just don't understand what you mean exactly. Microblaze is soft-core cpu or soft IP if you like. It means it is written in VHDL/Verilog or in different hardware description language. >> macb driver can be used by Microblaze too. > > Thanks for the information. I will send a patch adding MICROBLAZE to > the dependencies. Out of curiosity, is there any way I could have found > out by myself? Microblaze doesn't need to be only one. I am not sure if there is any AXI bridge for openrisc. IMHO you should just add COMPILE_TEST and do not try to extend that list of dependencies. Thanks, Michal
On Wed, Apr 23, 2014 at 09:40:10AM +0200, Jean Delvare wrote: > On Wed, 23 Apr 2014 09:16:49 +0200, Michal Simek wrote: > > > Cadence are an IP company, > I can't parse this, sorry. What is an "IP company"? They sell designs for blocks that can be used to build hardware rather than physical objects or complete chips and they are independant of chip vendors. There are a number of other companies that do this, people like Designware for example, and while ARM do obviously do architectures they are also a generic soft IP company as well. This means that for those companies (and sometimes others) you can't assume that just because it's used on some architecture that doesn't mean it's used on others. > > > might be worth having a FPGA > > > Kconfig that architectures commonly deployed with lots of soft IPs can > > > select and the IPs depend on rather than building a custom list for each > > > IP. > What are "soft IPs"? I'm afraid I wouldn't be able to translate your > proposal into a patch, I just don't understand what you mean exactly. Components used in the design of hardware sold by the above companies. Several architectures (at least ARM, Microblaze and PowerPC) are available in chips where most of the chip is a FPGA.
Hi Michal, On Wed, 23 Apr 2014 11:35:55 +0200, Michal Simek wrote: > On 04/23/2014 09:40 AM, Jean Delvare wrote: > > Thanks for the information. I will send a patch adding MICROBLAZE to > > the dependencies. Out of curiosity, is there any way I could have found > > out by myself? > > Microblaze doesn't need to be only one. I am not sure if there is > any AXI bridge for openrisc. You lost me here again :-( > IMHO you should just add COMPILE_TEST and do not try to extend that > list of dependencies. COMPILE_TEST is already present, I can't add it twice ;-) But COMPILE_TEST isn't supposed to be used when the architecture / platform / system is actually expected to possibly need the driver in question. If the list of possible hardware dependencies isn't well known, or is too complex to express, or too difficult to maintain, then we have to either make it broader, or even drop it. Originally I wanted to hide the Cadence drivers from X86 kernel configuration. If there's still a way to achieve that, let's do it. If not, we can leave the hardware dependency for ARM_AT91_ETHER and drop the one for MACB (and subsequently NET_CADENCE.) That's still better than nothing. Please let me know how you want to proceed. Thanks,
Hi Jean, On 04/23/2014 12:48 PM, Jean Delvare wrote: > Hi Michal, > > On Wed, 23 Apr 2014 11:35:55 +0200, Michal Simek wrote: >> On 04/23/2014 09:40 AM, Jean Delvare wrote: >>> Thanks for the information. I will send a patch adding MICROBLAZE to >>> the dependencies. Out of curiosity, is there any way I could have found >>> out by myself? >> >> Microblaze doesn't need to be only one. I am not sure if there is >> any AXI bridge for openrisc. > > You lost me here again :-( at least on Zynq we have cadence macb on AXI bus. Not sure which bus is used on Atmel. SoC vendor just buy it from Cadence and add it to silicon. Or for microblaze case because it is soft-core we can simple connect Microblaze with this IP. It means if you have any soft-core cpu which supports AXI bus or bridge to AXI it can connect this IP. >> IMHO you should just add COMPILE_TEST and do not try to extend that >> list of dependencies. > > COMPILE_TEST is already present, I can't add it twice ;-) But > COMPILE_TEST isn't supposed to be used when the architecture / > platform / system is actually expected to possibly need the driver in > question. If the list of possible hardware dependencies isn't well > known, or is too complex to express, or too difficult to maintain, then > we have to either make it broader, or even drop it. I am not COMPILE_TEST expert but IMHO idea was to compile all drivers for all platforms and do not hide anything. Even I think that will be just easier not to use COMPILE_TEST at all because it is just pain. At least I use zero-day testing system to compile it for others architectures. And I have asked Fengguang to explicitly enable COMPILE_TEST for all platforms and do not depend that randconfig enables it. > Originally I wanted to hide the Cadence drivers from X86 kernel > configuration. If there's still a way to achieve that, let's do it. If > not, we can leave the hardware dependency for ARM_AT91_ETHER and drop > the one for MACB (and subsequently NET_CADENCE.) That's still better > than nothing. Any reason to hide this driver for x86? Thanks, Michal
On Wed, Apr 23, 2014 at 12:48:38PM +0200, Jean Delvare wrote: > On Wed, 23 Apr 2014 11:35:55 +0200, Michal Simek wrote: > > On 04/23/2014 09:40 AM, Jean Delvare wrote: > > > Thanks for the information. I will send a patch adding MICROBLAZE to > > > the dependencies. Out of curiosity, is there any way I could have found > > > out by myself? > > Microblaze doesn't need to be only one. I am not sure if there is > > any AXI bridge for openrisc. > You lost me here again :-( AXI is a bus commonly used inside ICs, it's one of a series of buses of varying complexity commonly used to integrate IPs into chips. Michal is wondering if there is anything available to interface an AXI bus to an OpenRISC processor. > > IMHO you should just add COMPILE_TEST and do not try to extend that > > list of dependencies. > COMPILE_TEST is already present, I can't add it twice ;-) But > COMPILE_TEST isn't supposed to be used when the architecture / > platform / system is actually expected to possibly need the driver in > question. If the list of possible hardware dependencies isn't well > known, or is too complex to express, or too difficult to maintain, then > we have to either make it broader, or even drop it. Like I said in my original reply for things like this that are clearly generic IPs not tied to a particular chip vendor I think we ought to at least create a symbol they can depend on which can be selected by the architectures that are commonly deployed with FPGAs (or just in custom silicon like ARM). That will cover most of the uses I expect. For some of these IPs there will also be additional places where they could appear (eg, if something gets put on a PCI card) but they should be much less common.
On Wed, Apr 23, 2014 at 01:14:41PM +0200, Michal Simek wrote: > On 04/23/2014 12:48 PM, Jean Delvare wrote: > > Originally I wanted to hide the Cadence drivers from X86 kernel > > configuration. If there's still a way to achieve that, let's do it. If > > not, we can leave the hardware dependency for ARM_AT91_ETHER and drop > > the one for MACB (and subsequently NET_CADENCE.) That's still better > > than nothing. > Any reason to hide this driver for x86? Distro maintainers like Jean are complaining about build times for their kernels if they enable absolutely everything so if they're never likely to see any hardware using something they want to skip it.
On 04/23/2014 01:34 PM, Mark Brown wrote: > On Wed, Apr 23, 2014 at 01:14:41PM +0200, Michal Simek wrote: >> On 04/23/2014 12:48 PM, Jean Delvare wrote: > >>> Originally I wanted to hide the Cadence drivers from X86 kernel >>> configuration. If there's still a way to achieve that, let's do it. If >>> not, we can leave the hardware dependency for ARM_AT91_ETHER and drop >>> the one for MACB (and subsequently NET_CADENCE.) That's still better >>> than nothing. > >> Any reason to hide this driver for x86? > > Distro maintainers like Jean are complaining about build times for their > kernels if they enable absolutely everything so if they're never likely > to see any hardware using something they want to skip it. Is there any reasonable solution for this? 1. One group is saying use COMPILE_TEST for every driver to have better coverage. 2. Next group is saying I don't want to build everything for my arch. Fixing Kconfig to say !x86 is probably not the right way to go. Isn't it enough not to enable absolutely everything? Thanks, Michal
Hi Michal, On Wed, 23 Apr 2014 15:16:04 +0200, Michal Simek wrote: > On 04/23/2014 01:34 PM, Mark Brown wrote: > > On Wed, Apr 23, 2014 at 01:14:41PM +0200, Michal Simek wrote: > >> Any reason to hide this driver for x86? > > > > Distro maintainers like Jean are complaining about build times for their > > kernels if they enable absolutely everything so if they're never likely > > to see any hardware using something they want to skip it. Exactly. See this discussion thread for details: https://lkml.org/lkml/2014/4/14/280 > Is there any reasonable solution for this? > 1. One group is saying use COMPILE_TEST for every driver to have better > coverage. I think pretty much everyone agrees with this. The problem is that COMPILE_TEST is relatively new so a lot of old drivers don't have it yet, and developers and maintainers are not yet used to using it or asking for it. > 2. Next group is saying I don't want to build everything for my arch. I don't understand what you mean here. The idea is that distro maintainers or simple users don't set COMPILE_TEST so they only see what is useful to them, while developers set COMPILE_TEST to be able to build-test everything. Before COMPILE_TEST was introduced, it wasn't possible to make everyone happy. Now it is, so let's just do it. > Fixing Kconfig to say !x86 is probably not the right way to go. Definitely not. I did not even consider it as an acceptable workaround. If we can't come up with reasonable dependencies for a given driver, we can just leave it as is. There's plenty of easier drivers to work on :) > Isn't it enough not to enable absolutely everything? Everything that is visible requires everyone around to make a decision. The more we can help them, the easier the process.
On Wed, Apr 23, 2014 at 03:16:04PM +0200, Michal Simek wrote: > On 04/23/2014 01:34 PM, Mark Brown wrote: > > Distro maintainers like Jean are complaining about build times for their > > kernels if they enable absolutely everything so if they're never likely > > to see any hardware using something they want to skip it. > Is there any reasonable solution for this? > 1. One group is saying use COMPILE_TEST for every driver to have better > coverage. > 2. Next group is saying I don't want to build everything for my arch. > Fixing Kconfig to say !x86 is probably not the right way to go. > Isn't it enough not to enable absolutely everything? You're misunderstanding - the discussion here is for the !COMPILE_TEST case. Nobody wants to hide things in the COMPILE_TEST case, it's about what happens when that's disabled for production kernels.
--- linux-3.15-rc1.orig/drivers/net/ethernet/cadence/Kconfig 2014-03-31 05:40:15.000000000 +0200 +++ linux-3.15-rc1/drivers/net/ethernet/cadence/Kconfig 2014-04-14 15:36:18.141242446 +0200 @@ -4,7 +4,7 @@ config NET_CADENCE bool "Cadence devices" - depends on HAS_IOMEM + depends on HAS_IOMEM && (ARM || AVR32 || COMPILE_TEST) default y ---help--- If you have a network (Ethernet) card belonging to this class, say Y. @@ -22,7 +22,7 @@ if NET_CADENCE config ARM_AT91_ETHER tristate "AT91RM9200 Ethernet support" - depends on HAS_DMA + depends on HAS_DMA && (ARCH_AT91RM9200 || COMPILE_TEST) select MACB ---help--- If you wish to compile a kernel for the AT91RM9200 and enable @@ -30,7 +30,7 @@ config ARM_AT91_ETHER config MACB tristate "Cadence MACB/GEM support" - depends on HAS_DMA + depends on HAS_DMA && (PLATFORM_AT32AP || ARCH_AT91 || ARCH_PICOXCELL || ARCH_ZYNQ || COMPILE_TEST) select PHYLIB ---help--- The Cadence MACB ethernet interface is found on many Atmel AT32 and
The Cadence ethernet chipsets are only used on specific ARM architectures. Add Kconfig dependencies so that drivers for these chipsets are only buildable on the relevant architectures. Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Nicolas Ferre <nicolas.ferre@atmel.com> --- Changes since v1: * Added missing dependency on AVR32, as reported by Nicolas Ferre. drivers/net/ethernet/cadence/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)