linux-kernel - Re: [PATCH] ethernet/arc/arc_emac

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2468036.im0srnzmHT@wuerfel>
Date:	Fri, 07 Jun 2013 14:13:14 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Alexey Brodkin <Alexey.Brodkin@...opsys.com>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Vineet Gupta <Vineet.Gupta1@...opsys.com>,
	Mischa Jonker <Mischa.Jonker@...opsys.com>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <rob.herring@...xeda.com>,
	Paul Gortmaker <paul.gortmaker@...driver.com>,
	"David S. Miller" <davem@...emloft.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>
Subject: Re: [PATCH] ethernet/arc/arc_emac - Add new driver

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/