netdev - RE: [PATCH net-next v4 05/12] net: ethernet: oa_tc6: implement error interrupts unmasking

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: 
 <BY5PR02MB678683EADBC47A29A4F545A59D1C2@BY5PR02MB6786.namprd02.prod.outlook.com>
Date: Mon, 6 May 2024 06:47:32 +0000
From: Piergiorgio Beruto <Pier.Beruto@...emi.com>
To: Andrew Lunn <andrew@...n.ch>,
        "Parthiban.Veerasooran@...rochip.com"
	<Parthiban.Veerasooran@...rochip.com>
CC: "ramon.nordin.rodriguez@...roamp.se" <ramon.nordin.rodriguez@...roamp.se>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "edumazet@...gle.com"
	<edumazet@...gle.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "horms@...nel.org"
	<horms@...nel.org>,
        "saeedm@...dia.com" <saeedm@...dia.com>,
        "anthony.l.nguyen@...el.com" <anthony.l.nguyen@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "corbet@....net" <corbet@....net>,
        "linux-doc@...r.kernel.org"
	<linux-doc@...r.kernel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "krzysztof.kozlowski+dt@...aro.org" <krzysztof.kozlowski+dt@...aro.org>,
        "conor+dt@...nel.org" <conor+dt@...nel.org>,
        "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>,
        "Horatiu.Vultur@...rochip.com"
	<Horatiu.Vultur@...rochip.com>,
        "ruanjinjie@...wei.com"
	<ruanjinjie@...wei.com>,
        "Steen.Hegelund@...rochip.com"
	<Steen.Hegelund@...rochip.com>,
        "vladimir.oltean@....com"
	<vladimir.oltean@....com>,
        "UNGLinuxDriver@...rochip.com"
	<UNGLinuxDriver@...rochip.com>,
        "Thorsten.Kummermehr@...rochip.com"
	<Thorsten.Kummermehr@...rochip.com>,
        Selvamani Rajagopal
	<Selvamani.Rajagopal@...emi.com>,
        "Nicolas.Ferre@...rochip.com"
	<Nicolas.Ferre@...rochip.com>,
        "benjamin.bigler@...nformulastudent.ch"
	<benjamin.bigler@...nformulastudent.ch>
Subject: RE: [PATCH net-next v4 05/12] net: ethernet: oa_tc6: implement error
 interrupts unmasking

HI all,

The RXBOE is basically a warning, indicating that for some reason the SPI host is not fast enough in retrieving frames from the device.
In my experience, this is typically caused by excessive latency of the SPI driver, or if you have an unoptimized network driver for the MACPHY.

And no, you would certainly NOT drop a frame that is transferred over the SPI bus. It is the frame at the ingress of the device that will be dropped (ie the one at the end of the queue, not the beginning)..
Just my 0.2cent

Thanks,
Piergiorgio

-----Original Message-----
From: Andrew Lunn <andrew@...n.ch> 
Sent: 6 May, 2024 03:21
To: Parthiban.Veerasooran@...rochip.com
Cc: ramon.nordin.rodriguez@...roamp.se; davem@...emloft.net; edumazet@...gle.com; kuba@...nel.org; pabeni@...hat.com; horms@...nel.org; saeedm@...dia.com; anthony.l.nguyen@...el.com; netdev@...r.kernel.org; linux-kernel@...r.kernel.org; corbet@....net; linux-doc@...r.kernel.org; robh+dt@...nel.org; krzysztof.kozlowski+dt@...aro.org; conor+dt@...nel.org; devicetree@...r.kernel.org; Horatiu.Vultur@...rochip.com; ruanjinjie@...wei.com; Steen.Hegelund@...rochip.com; vladimir.oltean@....com; UNGLinuxDriver@...rochip.com; Thorsten.Kummermehr@...rochip.com; Piergiorgio Beruto <Pier.Beruto@...emi.com>; Selvamani Rajagopal <Selvamani.Rajagopal@...emi.com>; Nicolas.Ferre@...rochip.com; benjamin.bigler@...nformulastudent.ch
Subject: Re: [PATCH net-next v4 05/12] net: ethernet: oa_tc6: implement error interrupts unmasking

[External Email]: This email arrived from an external source - Please exercise caution when opening any attachments or clicking on links.


> [  285.482275] LAN865X Rev.B0 Internal Phy spi0.0:00: attached PHY 
> driver (mii_bus:phy_addr=spi0.0:00, irq=POLL) [  285.534760] lan865x 
> spi0.0 eth1: Link is Up - 10Mbps/Half - flow control off [  
> 341.466221] eth1: Receive buffer overflow error [  345.730222] eth1: 
> Receive buffer overflow error [  345.891126] eth1: Receive buffer 
> overflow error [  346.074220] eth1: Receive buffer overflow error

Generally we only log real errors. Is a receive buffer overflow a real error? I would say not. But it would be good to count it.

There was also the open question, what exactly does a receive buffer overflow mean?

The spec says:

  9.2.8.11 RXBOE

  Receive Buffer Overflow Error. When set, this bit indicates that the
  receive buffer (from the network) has overflowed and receive frame
  data was lost.

Which is a bit ambiguous. I would hope it means the receiver has dropped the packet. It will not be passed to the host. But other than maybe count it, i don't think there is anything to do. But Ramón was suggesting you actually drop the frame currently be transferred over the SPI bus?

	Andrew