Revision 259039fa30457986929a324d769f543c1509987f authored by David S. Miller on 07 February 2020, 10:36:22 UTC, committed by David S. Miller on 07 February 2020, 10:36:22 UTC
Ong Boon Leong says:
====================
net: stmmac: general fixes for Ethernet functionality
1/5: It ensures that the previous value of GMAC_VLAN_TAG register is
read first before for updating the register.
2/5: Similar to 2/6 patch but it is a fix for XGMAC_VLAN_TAG register
as requested by Jose Abreu.
3/5: It ensures the GMAC IP v4.xx and above behaves correctly to:-
ip link set <devname> multicast off|on
4/5: Added similar IFF_MULTICAST flag for xgmac2, similar to 4/6.
5/5: It ensures PCI platform data is using plat->phy_interface.
Changes from v4:-
patch 1/6 - this patch is dropped now and will take the input on
handling return value from netif_set_real_num_rx|
tx_queues() in future patch series.
v3:-
patch 1/6 - add rtnl_lock() and rtnl_unlock() for stmmac_hw_setup()
called inside stmmac_resume()
patch 3/6 - Added new patch to fix XGMAC_VLAN_TAG register writting
v2:-
patch 1/5 - added control for rtnl_lock() & rtnl_unlock() to ensure
they are used forstmmac_resume()
patch 4/5 - added IFF_MULTICAST flag check for xgmac to ensure
multicast works correctly.
v1:-
- Drop v1 patches (1/7, 3/7 & 4/7) that are not valid.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
debugging-modules.txt
Debugging Modules after 2.6.3
-----------------------------
In almost all distributions, the kernel asks for modules which don't
exist, such as "net-pf-10" or whatever. Changing "modprobe -q" to
"succeed" in this case is hacky and breaks some setups, and also we
want to know if it failed for the fallback code for old aliases in
fs/char_dev.c, for example.
In the past a debugging message which would fill people's logs was
emitted. This debugging message has been removed. The correct way
of debugging module problems is something like this:
echo '#! /bin/sh' > /tmp/modprobe
echo 'echo "$@" >> /tmp/modprobe.log' >> /tmp/modprobe
echo 'exec /sbin/modprobe "$@"' >> /tmp/modprobe
chmod a+x /tmp/modprobe
echo /tmp/modprobe > /proc/sys/kernel/modprobe
Note that the above applies only when the *kernel* is requesting
that the module be loaded -- it won't have any effect if that module
is being loaded explicitly using "modprobe" from userspace.
Computing file changes ...
