From: Arnd Bergmann <arnd@arndb.de>
To: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Vineet Gupta <Vineet.Gupta1@synopsys.com>,
Mischa Jonker <Mischa.Jonker@synopsys.com>,
Grant Likely <grant.likely@linaro.org>,
Rob Herring <rob.herring@calxeda.com>,
Paul Gortmaker <paul.gortmaker@windriver.com>,
"David S. Miller" <davem@davemloft.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>
Subject: Re: [PATCH] ethernet/arc/arc_emac - Add new driver
Date: Fri, 07 Jun 2013 14:13:14 +0200 [thread overview]
Message-ID: <2468036.im0srnzmHT@wuerfel> (raw)
In-Reply-To: <4881796E12491D4BB15146FE0209CE643F5C77EC@DE02WEMBXB.internal.synopsys.com>
On Friday 07 June 2013 10:42:28 Alexey Brodkin wrote:
> On 06/07/2013 12:47 PM, Arnd Bergmann wrote:
> > I wonder if it would be better to name the directory "synopsys" or
> > "designware" rather than "arc" now. Is there a chance that the same
> > controller is used on non-arc CPUs?
>
> The thing is - "arc_emac" is a custom ARC's (that was implemented before
> acquisition of ARC by Synopsys) IP (it's not an IC - just a part of CPU)
> Ethernet controller that only exists in some legacy FPGA boards we
> (ex-ARC and our customers) still use a lot in development process.
>
> Synopsys itself doesn't actively sell this device so there's no point in
> putting ARC EMAC into Synopsys folder.
>
> And indeed we don't expect this device to be used with non-ARC CPU's.
>
> I didn't add dependency on ARC in Kconfig just because I wanted to leave
> an ability to build this driver on x86 machine. I thought this is
> important requirement - allow anybody to at least build this driver to
> make sure it builds and doesn't cause tons of warnings to appear.
>
> If it's totally fine to add dependency on ARC - then it would be even
> easier for me - refer to the next block of comments.
No, I think making it generally available for all architectures is better.
> >> +static int arc_emac_probe(struct platform_device *pdev)
> >> +{
> >> + struct net_device *net_dev;
> >> + struct arc_emac_priv *priv;
> >> + int err;
> >> + unsigned int clock_frequency;
> >> + unsigned int id;
> >> + struct resource res_regs;
> >> +#ifdef CONFIG_OF_IRQ
> >> + struct resource res_irq;
> >> +#endif
> >> + const char *mac_addr = NULL;
> >
> > Please remove the #ifdef here. The driver does not work without this
> > anyway, so better make it 'depend on OF_IRQ' in Kconfig.
>
> As stated above I wanted to make it possible to compile on x86.
> And for this I needed to:
> 1. Add explicit mentions of "linux/platform_device.h" because with
> existence of OF "linux/of_platform.h" has "linux/platform_device.h"
> included internally.
> 2. Enclose "of_irq_to_resource" and "of_get_mac_address" in ifdefs
> because neither of them has a stub for non-OF situation.
But you can enable CONFIG_OF on x86. An allmodconfig build should
still enable this driver. The #ifdefs are generally considered ugly,
and there is no point adding them when the driver clearly wouldn't
work on any architecture without them even if that hardware was
available.
> So if I may depend on ARC then I'm sure OF is selected and no need to worry.
> Otherwise do I need to add stubs for "of_irq_to_resource" and
> "of_get_mac_address" somewhere in "of/of_xxx.h"?
We are currently discussing those changes to the header files elsewhere.
I think with a dependency on CONFIG_OF_IRQ and other symbols you need,
you get the best compromise of the various requirements.
Arnd
next prev parent reply other threads:[~2013-06-07 12:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-04 12:21 [PATCH] ethernet/arc/arc_emac - Add new driver Alexey Brodkin
2013-06-06 23:35 ` David Miller
2013-06-07 8:47 ` Arnd Bergmann
2013-06-07 10:42 ` Alexey Brodkin
2013-06-07 12:13 ` Arnd Bergmann [this message]
2013-06-07 12:37 ` Alexey Brodkin
2013-06-07 12:48 ` Arnd Bergmann
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=2468036.im0srnzmHT@wuerfel \
--to=arnd@arndb.de \
--cc=Alexey.Brodkin@synopsys.com \
--cc=Mischa.Jonker@synopsys.com \
--cc=Vineet.Gupta1@synopsys.com \
--cc=davem@davemloft.net \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paul.gortmaker@windriver.com \
--cc=rob.herring@calxeda.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