| 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
| ||
|
Message-ID: <20110324162517.GI6466@game.jcrosoft.org> Date: Thu, 24 Mar 2011 17:25:17 +0100 From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com> To: Jamie Iles <jamie@...ieiles.com> Cc: Nicolas Ferre <nicolas.ferre@...el.com>, David Miller <davem@...emloft.net>, Russell King - ARM Linux <linux@....linux.org.uk>, netdev@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, Andrew Victor <linux@...im.org.za>, Peter Korsgaard <jacmet@...site.dk> Subject: Re: [PATCHv2 0/9] macb: add support for Cadence GEM On 17:55 Tue 22 Mar , Jamie Iles wrote: > Hi Jean-Christophe, > > On Tue, Mar 22, 2011 at 04:39:17PM +0000, Jamie Iles wrote: > > Hi Jean-Christophe, > > > > On Tue, Mar 22, 2011 at 05:18:11PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: > > > On 11:18 Mon 21 Mar , Jamie Iles wrote: > > > > I have an existing tree for this at > > > > > > > > git://github.com/jamieiles/linux-2.6-ji.git macb-gem > > > > > > > > based off of 2.6.38 (with your ACK's now added) and I'd be happy with > > > > either route. > > > but we must detect the gem via the version register and ditto for macb for > > > avr32 and at91 > > > > > > so please rebase it over my patch > > > > > > and you get my sob too > > > > Would you mind respinning your patch without the changes to the clk > > stuff? Otherwise we're changing it from compile time to version based, > > only to completely remove it in subsequent patches. > > Actually, this patch doesn't work anyway as the version register is > being read before the clks are enabled so the device isn't accessible > (and the registers haven't yet been ioremap()'d). yeah I found it also I forget to put he RFC in the patch title as I want just to give the way to detect it the way to detect it for avr32 and at91 so we can remove the ifdef fully > > > Also, can you confirm that the module ID's that you are using to > > differentiate between AT91 and AVR32 won't clash with MACB uses in > > other, non-at91/avr32 chips, or that it doesn't matter? > > If this does work, then it would be nice if we made the else path of the > RMII AT91 tests also test for avr32 too so we aren't driving the USRIO > pins on platforms that aren't at91 but also aren't avr32. So something > the patch below instead. I'm currently traveling so I can not test it yet will test it next week but looks good Best Regards, J. -- 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