netdev - Re: [PATCH RFC 0/2] stmmac: stand alone platform drivers

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: <5987007.lq0DjS0tE0@wuerfel>
Date:	Fri, 08 May 2015 15:30:50 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	linux-arm-kernel@...ts.infradead.org
Cc:	Joachim Eastwood <manabian@...il.com>, peppe.cavallaro@...com,
	davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH RFC 0/2] stmmac: stand alone platform drivers

On Thursday 07 May 2015 20:19:23 Joachim Eastwood wrote:
> Hi Arnd,
> 
> I ran into some issue using a separate platform driver[1] for lpc1850-dwmac.
> 
> My dts files looks like this.
> mac: ethernet@...10000 {
>         compatible = "nxp,lpc1850-dwmac", "snps,dwmac-3.611", "snps,dwmac";
>         ...
> }
> 
> On boot the generic driver in stmmac_platform.c would grab the
> device, matching on one of generic compat strings and thus blocking
> the lpc1850-dwmac driver.
> 
> By changing the build order in the Makefile (see patch 1) I managed
> to get it working, but I am not sure that is a good solution(?).

Changing the link order in the Makefile is an acceptable solution
for managing initialization order in general, but I think it won't
work here, because if your driver is a loadable module, the base
driver would always be attached first.
 
> Another fix would be to remove the generic compat strings from the
> match table in stmmac_platform but there are some dts-files that
> only have these compat strings.
> See abilis_tb10x.dtsi and exynos5440.dtsi.

Yes, that has a high risk of causing regressions.

> I could also remove the generic compat strings from my dts file but
> I am not sure that is good solution either. If more glue is
> converted this would then be need in those dts files also.

I think it would work if you move the generic strings into a separate
module that is not the one providing the base support. In that case,
the kernel should first try to use the driver that matches the first
compatible string. Can you try that?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html