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  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]
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

Powered by blists - more mailing lists