From: Florian Fainelli <firstname.lastname@example.org> To: Vladimir Oltean <email@example.com>, Florian Fainelli <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org, "David S. Miller" <email@example.com>, Jakub Kicinski <firstname.lastname@example.org>, Murali Krishna Policharla <email@example.com>, Vladimir Oltean <firstname.lastname@example.org>, "open list:BROADCOM SYSTEMPORT ETHERNET DRIVER" <email@example.com>, open list <firstname.lastname@example.org> Subject: Re: [PATCH net] net: systemport: set dev->max_mtu to UMAC_MAX_MTU_SIZE Date: Fri, 18 Dec 2020 13:08:58 -0800 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <20201218210250.owahylqnagtssbsw@skbuf> On 12/18/20 1:02 PM, Vladimir Oltean wrote: > On Fri, Dec 18, 2020 at 12:54:33PM -0800, Florian Fainelli wrote: >> On 12/18/20 12:52 PM, Vladimir Oltean wrote: >>> On Fri, Dec 18, 2020 at 12:30:20PM -0800, Florian Fainelli wrote: >>>> On 12/18/20 12:24 PM, Vladimir Oltean wrote: >>>>> Hi Florian, >>>>> >>>>> On Fri, Dec 18, 2020 at 09:38:43AM -0800, Florian Fainelli wrote: >>>>>> The driver is already allocating receive buffers of 2KiB and the >>>>>> Ethernet MAC is configured to accept frames up to UMAC_MAX_MTU_SIZE. >>>>>> >>>>>> Fixes: bfcb813203e6 ("net: dsa: configure the MTU for switch ports") >>>>>> Signed-off-by: Florian Fainelli <firstname.lastname@example.org> >>>>>> --- >>>>>> drivers/net/ethernet/broadcom/bcmsysport.c | 1 + >>>>>> 1 file changed, 1 insertion(+) >>>>>> >>>>>> diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c b/drivers/net/ethernet/broadcom/bcmsysport.c >>>>>> index 0fdd19d99d99..b1ae9eb8f247 100644 >>>>>> --- a/drivers/net/ethernet/broadcom/bcmsysport.c >>>>>> +++ b/drivers/net/ethernet/broadcom/bcmsysport.c >>>>>> @@ -2577,6 +2577,7 @@ static int bcm_sysport_probe(struct platform_device *pdev) >>>>>> NETIF_F_HW_VLAN_CTAG_TX; >>>>>> dev->hw_features |= dev->features; >>>>>> dev->vlan_features |= dev->features; >>>>>> + dev->max_mtu = UMAC_MAX_MTU_SIZE; >>>>>> >>>>>> /* Request the WOL interrupt and advertise suspend if available */ >>>>>> priv->wol_irq_disabled = 1; >>>>>> -- >>>>>> 2.25.1 >>>>>> >>>>> >>>>> Do you want to treat the SYSTEMPORT Lite differently? >>>>> >>>>> /* Set maximum frame length */ >>>>> if (!priv->is_lite) >>>>> umac_writel(priv, UMAC_MAX_MTU_SIZE, UMAC_MAX_FRAME_LEN); >>>>> else >>>>> gib_set_pad_extension(priv); >>>> >>>> SYSTEMPORT Lite does not actually validate the frame length, so setting >>>> a maximum number to the buffer size we allocate could work, but I don't >>>> see a reason to differentiate the two types of MACs here. >>> >>> And if the Lite doesn't validate the frame length, then shouldn't it >>> report a max_mtu equal to the max_mtu of the attached DSA switch, plus >>> the Broadcom tag length? Doesn't the b53 driver support jumbo frames? >> >> And how would I do that without create a horrible layering violation in >> either the systemport driver or DSA? Yes the b53 driver supports jumbo >> frames. > > Sorry, I don't understand where is the layering violation (maybe it doesn't > help me either that I'm not familiar with Broadcom architectures). > > Is the SYSTEMPORT Lite always used as a DSA master, or could it also be > used standalone? What would be the issue with hardcoding a max_mtu value > which is large enough for b53 to use jumbo frames? SYSTEMPORT Lite is always used as a DSA master AFAICT given its GMII Integration Block (GIB) was specifically designed with another MAC and particularly that of a switch on the other side. The layering violation I am concerned with is that we do not know ahead of time which b53 switch we are going to be interfaced with, and they have various limitations on the sizes they support. Right now b53 only concerns itself with returning JMS_MAX_SIZE, but I am fairly positive this needs fixing given the existing switches supported by the driver. -- Florian
next prev parent reply other threads:[~2020-12-18 21:09 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-18 17:38 Florian Fainelli 2020-12-18 20:24 ` Vladimir Oltean 2020-12-18 20:30 ` Florian Fainelli 2020-12-18 20:52 ` Vladimir Oltean 2020-12-18 20:54 ` Florian Fainelli 2020-12-18 21:02 ` Vladimir Oltean 2020-12-18 21:08 ` Florian Fainelli [this message] 2020-12-18 21:14 ` Vladimir Oltean 2020-12-18 21:17 ` Florian Fainelli 2020-12-21 21:49 ` Florian Fainelli 2020-12-21 22:25 ` Vladimir Oltean 2020-12-21 22:55 ` Florian Fainelli
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH net] net: systemport: set dev->max_mtu to UMAC_MAX_MTU_SIZE' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.