| 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: <51922E83.2060002@atmel.com> Date: Tue, 14 May 2013 14:30:59 +0200 From: Nicolas Ferre <nicolas.ferre@...el.com> To: <monstr@...str.eu> CC: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>, <michal.simek@...inx.com>, <s.trumtrar@...gutronix.de>, <hein_tibosch@...oo.es>, Ludovic Desroches <ludovic.desroches@...el.com>, <linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>, Anirudha Sarangi <anirudh@...inx.com> Subject: Re: [PATCH] net/macb: fix ISR clear-on-write behavior only for some SoC On 14/05/2013 13:38, Michal Simek : > On 05/14/2013 11:16 AM, Nicolas Ferre wrote: >> On 13/05/2013 18:05, Jean-Christophe PLAGNIOL-VILLARD : >>> >>> On May 14, 2013, at 12:05 AM, Nicolas Ferre <nicolas.ferre@...el.com> wrote: >>> >>>> Commit 749a2b6 (net/macb: clear tx/rx completion flags in ISR) >>>> introduces clear-on-write on ISR register. This behavior is not always >>>> implemented when using Cadence MACB/GEM and is breaking other platforms. >>>> We are using a new Device Tree compatibility string and a capability >>>> property to actually activate this clear-on-write behavior on ISR. >>>> >>>> Reported-by: Hein Tibosch <hein_tibosch@...oo.es> >>>> Signed-off-by: Nicolas Ferre <nicolas.ferre@...el.com> >>> >>> can we detect it via the IP? >> >> As said by Hein, we cannot use the IP revision number. *But* we may have the opportunity to read this integration configuration in the Design Configuration Register 1 (DCFG1 already used for determining data bus width). >> >> So, Michal or Steffen, can you please tell me the value of: >> -> bit 23 at register address 0x280: mine is "1" which should mean "IRQ read clear", yours should be "0". > > here is the whole reg map for zynq. > Reg 0x280 is undocumented in our TRM. > Please decode it not sure if bit 0 is LSB or MSB. Bit 0 is LSB. Value of DCFG1 is 0x02500111 so I read '0' for this value which should be good. I write a new patch immediately. > U-Boot-PetaLinux> md e000b000 > e000b000: 0000001c 000e0013 00000006 00000000 ................ > e000b010: 00180704 00000021 3ffba2e4 3ffbd32c ....!......?,..? > e000b020: 00000003 00000000 00000000 00000000 ................ > e000b030: 07ffffff 63c66f08 00000000 0000ffff .....o.c........ > e000b040: 000003ff 000003ff 00000000 00000000 ................ > e000b050: 00000000 00000000 00000000 00000000 ................ > e000b060: 00000000 00000000 00000000 00000000 ................ > e000b070: 00000000 00000000 00000000 00000000 ................ > e000b080: 00000000 00000000 00350a00 00001c48 ..........5.H... > e000b090: 00000000 00000000 00000000 00000000 ................ > e000b0a0: 00000000 00000000 00000000 00000000 ................ > e000b0b0: 00000000 00000000 00000000 00000000 ................ > e000b0c0: 00000000 00000000 00000000 00000000 ................ > e000b0d0: 00000000 00000000 00000000 00000000 ................ > e000b0e0: 00000000 00000000 00000000 00000000 ................ > e000b0f0: 00000000 00000000 00000000 00020118 ................ > U-Boot-PetaLinux> > e000b100: 00014796 00000000 0000051e 00000001 .G.............. > e000b110: 00000000 00000000 0000051d 00000001 ................ > e000b120: 00000000 00000000 00000000 00000000 ................ > e000b130: 00000000 00000000 00000000 00000000 ................ > e000b140: 00000000 00000000 00000000 00000000 ................ > e000b150: 001e58b6 00000000 00000526 00000000 .X......&....... > e000b160: 00000004 00000000 00000004 00000001 ................ > e000b170: 00000000 00000004 00000000 0000051d ................ > e000b180: 00000000 00000000 00000000 00000000 ................ > e000b190: 00000000 00000000 00000000 00000000 ................ > e000b1a0: 00000038 00000000 00000000 00000000 8............... > e000b1b0: 00000000 00000000 00000000 00000000 ................ > e000b1c0: 00000000 00000000 00000000 00000000 ................ > e000b1d0: 00000000 00000000 00000000 00000000 ................ > e000b1e0: 00000000 00000000 00000000 00000000 ................ > e000b1f0: 00000000 00000000 00000000 00000000 ................ > U-Boot-PetaLinux> > e000b200: 00000000 00000000 00000000 00000000 ................ > e000b210: 00000000 00000000 00000000 00000000 ................ > e000b220: 00000000 00000000 00000000 00000000 ................ > e000b230: 00000000 00000000 00000000 00000000 ................ > e000b240: 00000000 00000000 00000000 00000000 ................ > e000b250: 00000000 00000000 00000000 00000000 ................ > e000b260: 00000000 00000000 00000000 00000000 ................ > e000b270: 00000000 00000000 00000000 00000000 ................ > e000b280: 02500111 2ab13fff 00000000 00000000 ..P..?.*........ > e000b290: 002f2145 00000200 00000000 00000000 E!/............. > e000b2a0: 00000000 00000000 00000000 00000000 ................ > e000b2b0: 00000000 00000000 00000000 00000000 ................ > e000b2c0: 00000000 00000000 00000000 00000000 ................ > e000b2d0: 00000000 00000000 00000000 00000000 ................ > e000b2e0: 00000000 00000000 00000000 00000000 ................ > e000b2f0: 00000000 00000000 00000000 00000000 ................ > U-Boot-PetaLinux> > > > >> >> Hein, in case of use of the MACB, we do not have this register included, so I will avoid to run the test when using MACB (we already have this information). >> >> If it works, I plan to rewrite the patch but taking this information instead of the device tree compatibility string. > > yep. Will be good to detect it instead of new compatible string. > > Also is there an option to remove "CONFIG_ARCH_AT91"? Okay, I have a look at this as-well. Best regards, -- Nicolas Ferre -- 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