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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
 <SEYPR06MB5134034FACBE7D7B9DCC67AF9D272@SEYPR06MB5134.apcprd06.prod.outlook.com>
Date: Mon, 18 Nov 2024 09:36:51 +0000
From: Jacky Chou <jacky_chou@...eedtech.com>
To: Arnd Bergmann <arnd@...db.de>, "andrew+netdev@...n.ch"
	<andrew+netdev@...n.ch>, "David S . Miller" <davem@...emloft.net>, Eric
 Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
	<pabeni@...hat.com>, Rob Herring <robh@...nel.org>, "krzk+dt@...nel.org"
	<krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Philipp Zabel
	<p.zabel@...gutronix.de>, Netdev <netdev@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject:
 回覆: [net-next v2 5/7] net: ftgmac100: add pin strap configuration for AST2700

> >> Is there a way to probe the presence of 64-bit addressing from
> >> hardware registers? That would be nicer than triggering it from the
> >> compatible string, given that any future SoC is likely also 64-bit.
> 
> I just realized I replied to the wrong email, I meant to send my question as a
> reply to patch 4/7. The patch for the pin strap looks fine.
> 
> > There is no register indicated about 64-bit address support in the
> > ftgmac100 of Aspeed 7th generation. Therefore, we use the compatible
> > to configure pin strap and DMA mask.
> 
> Later in the series you just unconditionally write the 64-bit address, so it
> appears that the ftgmac100 can actually do 64-bti addressing all along, and
> this doesn't have to be conditional at all, the call to
> dma_set_mask_and_coherent() only tells the kernel that the device can do it,
> which should work on all of them. Since the other devices won't have a larger
> "dma-ranges" configuration in DT, and no RAM above 32-bit addressing, it
> should have no effect.
> 
> Just make that part in patch 5 unconditional.

Agree, I got your point.
We tried to add less codes to compatible the older generations.
I will adjust it to normal probe procedure in next version, not use compatible to call 
dma_set_mask_and_coherent().
Thank you for your kind reminder.

Thanks,
Jacky

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ