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: 10+ 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-04 12:21 ` Alexey Brodkin
[not found] ` <1370348510-23754-1-git-send-email-abrodkin-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
2013-06-06 23:35 ` David Miller
2013-06-06 23:35 ` David Miller
2013-06-07 8:47 ` Arnd Bergmann
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.