netdev - RE: [PATCH] gianfar: Don't enable RX Filer if not supported

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]

Date:	Tue, 15 Dec 2015 10:12:36 +0000
From:	Manoil Claudiu <claudiu.manoil@...escale.com>
To:	Hamish Martin <hamish.martin@...iedtelesis.co.nz>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>
Subject: RE: [PATCH] gianfar: Don't enable RX Filer if not supported

>-----Original Message-----
>From: Hamish Martin [mailto:hamish.martin@...iedtelesis.co.nz]
>Sent: Tuesday, December 15, 2015 3:15 AM
>To: Manoil Claudiu-B08782 <claudiu.manoil@...escale.com>
>Cc: netdev@...r.kernel.org; Hamish Martin
><hamish.martin@...iedtelesis.co.nz>
>Subject: [PATCH] gianfar: Don't enable RX Filer if not supported
>
>After commit 15bf176db1fb ("gianfar: Don't enable the Filer w/o the
>Parser"), 'TSEC' model controllers (for example as seen on MPC8541E)
>always have 8 bytes stripped from the front of received frames.
>Only 'eTSEC' gianfar controllers have the RX Filer capability (amongst
>other enhancements). Previously this was treated as always enabled
>for both 'TSEC' and 'eTSEC' controllers.
>In commit 15bf176db1fb ("gianfar: Don't enable the Filer w/o the Parser")
>a subtle change was made to the setting of 'uses_rxfcb' to effectively
>always set it (since 'rx_filer_enable' was always true). This had the
>side-effect of always stripping 8 bytes from the front of received frames
>on 'TSEC' type controllers.
>
>We now only enable the RX Filer capability on controller types that
>support it, thereby avoiding the issue for 'TSEC' type controllers.
>


Reviewed-by: Claudiu Manoil <claudiu.manoil@...escale.com>

Thanks.
This should be applied on net. (I checked it applies w/o conflicts)

The usecase covered by rx_filer_enable was lost to me, yet I didn't remove
rx_filer_enable.  Turns out it's for TSEC, unfortunately I don't have a TSEC
board for testing yet.  With this patch, rx_filer_enable makes a lot more sense now.

Just out of curiosity, I had a look at the rx_filer_enable history. It looks that
its meaning got lost back in 2011 with
commit 4aa3a715551c93eda32d79bd52042ce500bd5383
(gianfar v5: implement nfc)

Where following change occurred:
-       /* enable filer if using multiple RX queues*/
-       if(priv->num_rx_queues > 1)
-               priv->rx_filer_enable = 1;
+       /* always enable rx filer*/
+       priv->rx_filer_enable = 1;

Back then, apparently the number of Rx queues was used to differentiate
between eTSEC and the older TSEC controllers (with just 1 RxQ).


--
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