- Dec 09, 2016
-
-
Robert Nelson authored
-
https://travis-ci.org/beagleboard/linuxRobert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Ulf Hansson authored
Commit 520bd7a8 ("mmc: core: Optimize boot time by detecting cards simultaneously") causes regressions for some platforms. These platforms relies on fixed mmcblk device indexes, instead of deploying the defacto standard with UUID/PARTUUID. In other words their rootfs needs to be available at hardcoded paths, like /dev/mmcblk0p2. Such guarantees have never been made by the kernel, but clearly the above commit changes the behaviour. More precisely, because of that the order changes of how cards becomes detected, so do their corresponding mmcblk device indexes. As the above commit significantly improves boot time for some platforms (magnitude of seconds), let's avoid reverting this change but instead restore the behaviour of how mmcblk device indexes becomes picked. By using the same index for the mmcblk device as for the corresponding mmc host device, the probe order of mmc host devices decides the index we get for the mmcblk device. For those platforms that suffers from a regression, one could expect that this updated behaviour should be sufficient to meet their expectations of "fixed" mmcblk device indexes. Another side effect from this change, is that the same index is used for the mmc host device, the mmcblk device and the mmc block queue. That should clarify their relationship. Reported-by: Peter Hurley <peter@hurleysoftware.com> Reported-by: Laszlo Fiat <laszlo.fiat@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Fixes: 520bd7a8 ("mmc: core: Optimize boot time by detecting cards simultaneously") Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Jay at Control Module Industries authored
I have encountered the same issue(s) on A6A boards. I couldn't find a patch, so I wrote this patch to update the device tree in the davinci_mdio driver in the 3.15.1 tree, it seems to correct it. I would welcome any input on a different approach. https://groups.google.com/d/msg/beagleboard/9mctrG26Mc8/SRlnumt0LoMJ v4.1-rcX: added hack around CONFIG_OF_OVERLAY v4.2-rc3+: added if (of_machine_is_compatible("ti,am335x-bone")) so we do not break dual ethernet am335x devices Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
D.S. Ljungmark authored
The Modio cape exposes 4 UARTs as 3xRS485 and 1xRS232 port on the BeagleBoneBlack. To function, it needs the cape manager to be disabled, since the capemanager shares pins with one of the UART devices. This device tree file is based on the minimal dts file. It currently sets up RTS pins as GPIO pins, which the OMAP_SERIAL driver can function with. So far, I have not managed to make the driver simply set the RTS flag in order to control the port. Signed-off-by: D.S. Ljungmark <ljungmark@modio.se>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
David Decotigny authored
Aimed at transferring bitmaps to/from user-space in a 32/64-bit agnostic way. Tested: unit tests (next patch) on qemu i386, x86_64, ppc, ppc64 BE and LE, ARM. Signed-off-by: David Decotigny <decot@googlers.com> Reviewed-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Ben Hutchings authored
When the ETHTOOL_GLINKSETTINGS implementation finds that userland is using the wrong number of words of link mode bitmaps (or is trying to find out the right numbers) it sets the cmd field to 0 in the response structure. This is inconsistent with the implementation of every other ethtool command, so let's remove that inconsistency before it gets into a stable release. Fixes: 3f1ac7a7 ("net: ethtool: add new ETHTOOL_xLINKSETTINGS API") Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David Decotigny authored
This patch defines a new ETHTOOL_GLINKSETTINGS/SLINKSETTINGS API, handled by the new get_link_ksettings/set_link_ksettings callbacks. This API provides support for most legacy ethtool_cmd fields, adds support for larger link mode masks (up to 4064 bits, variable length), and removes ethtool_cmd deprecated fields (transceiver/maxrxpkt/maxtxpkt). This API is deprecating the legacy ETHTOOL_GSET/SSET API and provides the following backward compatibility properties: - legacy ethtool with legacy drivers: no change, still using the get_settings/set_settings callbacks. - legacy ethtool with new get/set_link_ksettings drivers: the new driver callbacks are used, data internally converted to legacy ethtool_cmd. ETHTOOL_GSET will return only the 1st 32b of each link mode mask. ETHTOOL_SSET will fail if user tries to set the ethtool_cmd deprecated fields to non-0 (transceiver/maxrxpkt/maxtxpkt). A kernel warning is logged if driver sets higher bits. - future ethtool with legacy drivers: no change, still using the get_settings/set_settings callbacks, internally converted to new data structure. Deprecated fields (transceiver/maxrxpkt/maxtxpkt) will be ignored and seen as 0 from user space. Note that that "future" ethtool tool will not allow changes to these deprecated fields. - future ethtool with new drivers: direct call to the new callbacks. By "future" ethtool, what is meant is: - query: first try ETHTOOL_GLINKSETTINGS, and revert to ETHTOOL_GSET if fails - set: query first and remember which of ETHTOOL_GLINKSETTINGS or ETHTOOL_GSET was successful + if ETHTOOL_GLINKSETTINGS was successful, then change config with ETHTOOL_SLINKSETTINGS. A failure there is final (do not try ETHTOOL_SSET). + otherwise ETHTOOL_GSET was successful, change config with ETHTOOL_SSET. A failure there is final (do not try ETHTOOL_SLINKSETTINGS). The interaction user/kernel via the new API requires a small ETHTOOL_GLINKSETTINGS handshake first to agree on the length of the link mode bitmaps. If kernel doesn't agree with user, it returns the bitmap length it is expecting from user as a negative length (and cmd field is 0). When kernel and user agree, kernel returns valid info in all fields (ie. link mode length > 0 and cmd is ETHTOOL_GLINKSETTINGS). Data structure crossing user/kernel boundary is 32/64-bit agnostic. Converted internally to a legal kernel bitmap. The internal __ethtool_get_settings kernel helper will gradually be replaced by __ethtool_get_link_ksettings by the time the first "link_settings" drivers start to appear. So this patch doesn't change it, it will be removed before it needs to be changed. Signed-off-by: David Decotigny <decot@googlers.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Kan Liang authored
This patch implements sub command ETHTOOL_SCOALESCE for ioctl ETHTOOL_PERQUEUE. It introduces an interface set_per_queue_coalesce to set coalesce of each masked queue to device driver. The wanted coalesce information are stored in "data" for each masked queue, which can copy from userspace. If it fails to set coalesce to device driver, the value which already set to specific queue will be tried to rollback. Signed-off-by: Kan Liang <kan.liang@intel.com> Reviewed-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Kan Liang authored
This patch implements sub command ETHTOOL_GCOALESCE for ioctl ETHTOOL_PERQUEUE. It introduces an interface get_per_queue_coalesce to get coalesce of each masked queue from device driver. Then the interrupt coalescing parameters will be copied back to user space one by one. Signed-off-by: Kan Liang <kan.liang@intel.com> Reviewed-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Kan Liang authored
Introduce a new ioctl ETHTOOL_PERQUEUE for per queue parameters setting. The following patches will enable some SUB_COMMANDs for per queue setting. Signed-off-by: Kan Liang <kan.liang@intel.com> Reviewed-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
-
John Fastabend authored
Its useful to turn off the qdisc offload feature at a per device level. This gives us a big hammer to enable/disable offloading. More fine grained control (i.e. per rule) may be supported later. Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Keller, Jacob E authored
Add a sanity check to ensure that all requested channel sizes are within bounds, which should reduce errors in driver implementation. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Keller, Jacob E authored
Ethernet drivers implementing both {GS}RXFH and {GS}CHANNELS ethtool ops incorrectly allow SCHANNELS when it would conflict with the settings from SRXFH. This occurs because it is not possible for drivers to understand whether their Rx flow indirection table has been configured or is in the default state. In addition, drivers currently behave in various ways when increasing the number of Rx channels. Some drivers will always destroy the Rx flow indirection table when this occurs, whether it has been set by the user or not. Other drivers will attempt to preserve the table even if the user has never modified it from the default driver settings. Neither of these situation is desirable because it leads to unexpected behavior or loss of user configuration. The correct behavior is to simply return -EINVAL when SCHANNELS would conflict with the current Rx flow table settings. However, it should only do so if the current settings were modified by the user. If we required that the new settings never conflict with the current (default) Rx flow settings, we would force users to first reduce their Rx flow settings and then reduce the number of Rx channels. This patch proposes a solution implemented in net/core/ethtool.c which ensures that all drivers behave correctly. It checks whether the RXFH table has been configured to non-default settings, and stores this information in a private netdev flag. When the number of channels is requested to change, it first ensures that the current Rx flow table is not going to assign flows to now disabled channels. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Kim Jones authored
netdev_rss_key is written to once and thereafter is read by drivers when they are initialising. The fact that it is mostly read and not written to makes it a candidate for a __read_mostly declaration. Signed-off-by: Kim Jones <kim-marie.jones@intel.com> Signed-off-by: Alan Carey <alan.carey@intel.com> Acked-by: Rami Rosen <rami.rosen@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Andrew Lunn authored
Ethernet PHYs can maintain statistics, for example errors while idle and receive errors. Add an ethtool mechanism to retrieve these statistics, using the same model as MAC statistics. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tom Herbert authored
The name NETIF_F_ALL_CSUM is a misnomer. This does not correspond to the set of features for offloading all checksums. This is a mask of the checksum offload related features bits. It is incorrect to set both NETIF_F_HW_CSUM and NETIF_F_IP_CSUM or NETIF_F_IPV6 at the same time for features of a device. This patch: - Changes instances of NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK (where NETIF_F_ALL_CSUM is being used as a mask). - Changes bonding, sfc/efx, ipvlan, macvlan, vlan, and team drivers to use NEITF_F_HW_CSUM in features list instead of NETIF_F_ALL_CSUM. Signed-off-by: Tom Herbert <tom@herbertland.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tom Herbert authored
The SCTP checksum is really a CRC and is very different from the standards 1's complement checksum that serves as the checksum for IP protocols. This offload interface is also very different. Rename NETIF_F_SCTP_CSUM to NETIF_F_SCTP_CRC to highlight these differences. The term CSUM should be reserved in the stack to refer to the standard 1's complement IP checksum. Signed-off-by: Tom Herbert <tom@herbertland.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Baozhu Zuo authored
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>