- Jul 28, 2017
-
-
-
Robert Nelson authored
-
http://rcn-ee.online:8080Robert Nelson authored
Signed-off-by:Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by: -
Rob Herring authored
Recent versions of libfdt add a dependency on strnlen. Copy the implementation in lib/string.c here, so we can update libfdt. Acked-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Rob Herring <robh@kernel.org>
-
Rob Herring authored
The newly added dtc warning to check DT unit-address without reg property and vice-versa generates lots of warnings. Turn off the check unless building with W=1 or W=2. Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Will Newton authored
Reduce max_segs to 64, a value that allows allocation of an entire EDMA descriptor list within a single page - EDMA descriptors are 40 bytes and the header is much larger. This avoids doing a higher order GFP_ATOMIC allocation in edma_prep_slave_sg when setting up a transfer which can potentially fail due to fragmentation under heavy I/O load. The current value of 1024 is unusually high in comparison to other mmc host drivers which mostly use values of between 1 and 256. The EDMA driver at present splits lists above 20 segments in any case so reducing the size of lists we pass to it shouldn't add much overhead. rcn-ee: add use_adma option: https://www.spinics.net/lists/linux-omap/msg137942.html Signed-off-by:
Will Newton <willn@resin.io> Signed-off-by:
-
Robert Nelson authored
Signed-off-by: -
-
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
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 authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
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 authored
Signed-off-by: -
henrix authored
-
Robert Nelson authored
Signed-off-by: -
frost authored
-
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
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>
-
Nicolas Dichtel authored
The inital goal was to consolidate ethtool.h uapi header. But I took the opportunity to remove all duplicate definitions of DIV_ROUND_UP. v3: add patch #2 and #3 v2: split the patch define DIV_ROUND_UP in uapi .../drm/vmwgfx/device_include/svga3d_surfacedefs.h | 20 +++++++++++--------- drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 2 +- include/linux/kernel.h | 2 +- include/uapi/linux/ethtool.h | 7 ++++++- include/uapi/linux/kernel.h | 1 + include/uapi/linux/mroute6.h | 9 ++------- 6 files changed, 22 insertions(+), 19 deletions(-) Regards, Nicolas Date: Fri, 4 Mar 2016 11:52:18 +0100 From: Nicolas Dichtel <nicolas.dichtel@...nd.com> To: davem@...emloft.net Cc: netdev@...r.kernel.org, ben@...adent.org.uk, Karen Xie <kxie@...lsio.com>, linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org, David Airlie <airlied@...ux.ie>, dri-devel@...ts.freedesktop.org, Nicolas Dichtel <nicolas.dichtel@...nd.com> Subject: [PATCH net-next v3 3/4] drm/vmwgfx: remove userland definition of DIV_ROUND_UP Let's use __KERNEL_DIV_ROUND_UP, which is defined in uapi/linux/kernel.h. Signed-off-by:Nicolas Dichtel <nicolas.dichtel@...nd.com>
-
Robert Nelson authored
Signed-off-by: -
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: -
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:
-
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: -
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:
-
