| Message ID | 20241118060207.141048-6-jacky_chou@aspeedtech.com (mailing list archive) |
|---|---|
| State | New |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | Add Aspeed G7 FTGMAC100 support | expand |
On Mon, Nov 18, 2024, at 07:02, Jacky Chou wrote: > @@ -351,6 +352,10 @@ static void ftgmac100_start_hw(struct ftgmac100 *priv) > if (priv->netdev->features & NETIF_F_HW_VLAN_CTAG_RX) > maccr |= FTGMAC100_MACCR_RM_VLAN; > > + if (of_device_is_compatible(priv->dev->of_node, "aspeed,ast2700-mac") > && > + phydev && phydev->interface == PHY_INTERFACE_MODE_RMII) > + maccr |= FTGMAC100_MACCR_RMII_ENABLE; > + > /* Hit the HW */ 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. Arnd
Hi Arnd, Thank you for your reply. > > @@ -351,6 +352,10 @@ static void ftgmac100_start_hw(struct ftgmac100 > *priv) > > if (priv->netdev->features & NETIF_F_HW_VLAN_CTAG_RX) > > maccr |= FTGMAC100_MACCR_RM_VLAN; > > > > + if (of_device_is_compatible(priv->dev->of_node, > > +"aspeed,ast2700-mac") > > && > > + phydev && phydev->interface == PHY_INTERFACE_MODE_RMII) > > + maccr |= FTGMAC100_MACCR_RMII_ENABLE; > > + > > /* Hit the HW */ > > 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. 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. Thanks, Jacky
On Mon, Nov 18, 2024, at 08:51, Jacky Chou wrote: >> 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. Arnd
> >> 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
diff --git a/drivers/net/ethernet/faraday/ftgmac100.c b/drivers/net/ethernet/faraday/ftgmac100.c index 5b277285666a..801fbc89ab09 100644 --- a/drivers/net/ethernet/faraday/ftgmac100.c +++ b/drivers/net/ethernet/faraday/ftgmac100.c @@ -323,6 +323,7 @@ static void ftgmac100_init_hw(struct ftgmac100 *priv) static void ftgmac100_start_hw(struct ftgmac100 *priv) { u32 maccr = ioread32(priv->base + FTGMAC100_OFFSET_MACCR); + struct phy_device *phydev = priv->netdev->phydev; /* Keep the original GMAC and FAST bits */ maccr &= (FTGMAC100_MACCR_FAST_MODE | FTGMAC100_MACCR_GIGA_MODE); @@ -351,6 +352,10 @@ static void ftgmac100_start_hw(struct ftgmac100 *priv) if (priv->netdev->features & NETIF_F_HW_VLAN_CTAG_RX) maccr |= FTGMAC100_MACCR_RM_VLAN; + if (of_device_is_compatible(priv->dev->of_node, "aspeed,ast2700-mac") && + phydev && phydev->interface == PHY_INTERFACE_MODE_RMII) + maccr |= FTGMAC100_MACCR_RMII_ENABLE; + /* Hit the HW */ iowrite32(maccr, priv->base + FTGMAC100_OFFSET_MACCR); } diff --git a/drivers/net/ethernet/faraday/ftgmac100.h b/drivers/net/ethernet/faraday/ftgmac100.h index 4968f6f0bdbc..c87aa7d7f14c 100644 --- a/drivers/net/ethernet/faraday/ftgmac100.h +++ b/drivers/net/ethernet/faraday/ftgmac100.h @@ -166,6 +166,7 @@ #define FTGMAC100_MACCR_RX_MULTIPKT (1 << 16) #define FTGMAC100_MACCR_RX_BROADPKT (1 << 17) #define FTGMAC100_MACCR_DISCARD_CRCERR (1 << 18) +#define FTGMAC100_MACCR_RMII_ENABLE (1 << 20) /* defined in ast2700 */ #define FTGMAC100_MACCR_FAST_MODE (1 << 19) #define FTGMAC100_MACCR_SW_RST (1 << 31)
On AST2700, the RMII/RGMII pin strap is configured by setting MAC 0x50 bit 20. Set to 0 is RGMII and set to 1 is RMII. Use compatible property to distinguish different generations for configuration. Signed-off-by: Jacky Chou <jacky_chou@aspeedtech.com> --- drivers/net/ethernet/faraday/ftgmac100.c | 5 +++++ drivers/net/ethernet/faraday/ftgmac100.h | 1 + 2 files changed, 6 insertions(+)