linux-mips
[Top] [All Lists]

Re: [PATCH net-next] bcm63xx_enet: add support Broadcom BCM6345 Ethernet

To: florian@openwrt.org
Subject: Re: [PATCH net-next] bcm63xx_enet: add support Broadcom BCM6345 Ethernet
From: David Miller <davem@davemloft.net>
Date: Thu, 13 Jun 2013 02:25:24 -0700 (PDT)
Cc: netdev@vger.kernel.org, ralf@linux-mips.org, blogic@openwrt.org, linux-mips@linux-mips.org, mbizon@freebox.fr, jogo@openwrt.org, cernekee@gmail.com
In-reply-to: <CAGVrzcYE4VDWtL_Uj1DrkZ6GqX6ghqPAXPpyLptc6PGwReixSQ@mail.gmail.com>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <1371066785-17168-1-git-send-email-florian@openwrt.org> <20130613.014450.1434692343011842828.davem@davemloft.net> <CAGVrzcYE4VDWtL_Uj1DrkZ6GqX6ghqPAXPpyLptc6PGwReixSQ@mail.gmail.com>
Sender: linux-mips-bounce@linux-mips.org
From: Florian Fainelli <florian@openwrt.org>
Date: Thu, 13 Jun 2013 09:58:34 +0100

> 2013/6/13 David Miller <davem@davemloft.net>:
>> From: Florian Fainelli <florian@openwrt.org>
>> Date: Wed, 12 Jun 2013 20:53:05 +0100
>>
>>> +#ifdef BCMCPU_RUNTIME_DETECT
>>
>> I want the MIPS folks to fix this brain damange.
>>
>> This runtime detect thing is just a big mess in a header file
>> using hundreds of lines of CPP stuff to express what is fundamentally
>> a simple (albeit sizable) Kconfig dependency.
> 
> The codebase supporting the Broadcom BCM63xx SoC supports about 6-7

You don't need to explain it to me, I read the code and understand
what it's trying to accomplish.

I reject the implementation of it, only.

> No, the ifdefs are kept in the arch/mips/bcm63xx portions of the code
> specifically for that reason. The driver just needs to take into account a
> new set of platform_data properties to deal with this.

Fine, it's still terrible.

<Prev in Thread] Current Thread [Next in Thread>