This is a note to let you know that I've just added the patch titled
drm/edid: set ELD connector type in drm_edid_to_eld()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-edid-set-eld-connector-type-in-drm_edid_to_eld.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Jani Nikula <jani.nikula(a)intel.com>
Date: Wed, 1 Nov 2017 16:20:58 +0200
Subject: drm/edid: set ELD connector type in drm_edid_to_eld()
From: Jani Nikula <jani.nikula(a)intel.com>
[ Upstream commit 1d1c36650752b7fb81cee515a9bba4131cac4b7c ]
Since drm_edid_to_eld() knows the connector type, we can set the type in
ELD while at it. Most connectors this gets called on are not DP
encoders, and with the HDMI type being 0, this does not change behaviour
for non-DP.
For i915 having this in place earlier would have saved a considerable
amount of debugging that lead to the fix 2d8f63297b9f ("drm/i915: always
update ELD connector type after get modes"). I don't see other drivers,
even the ones calling drm_edid_to_eld() on DP connectors, setting the
connector type in ELD.
Cc: Alex Deucher <alexander.deucher(a)amd.com>
Cc: Christian König <christian.koenig(a)amd.com>
Cc: Archit Taneja <architt(a)codeaurora.org>
Cc: Andrzej Hajda <a.hajda(a)samsung.com>
Cc: Russell King <linux(a)armlinux.org.uk>
Cc: CK Hu <ck.hu(a)mediatek.com>
Cc: Philipp Zabel <p.zabel(a)pengutronix.de>
Cc: Ben Skeggs <bskeggs(a)redhat.com>
Cc: Mark Yao <mark.yao(a)rock-chips.com>
Cc: Benjamin Gaignard <benjamin.gaignard(a)linaro.org>
Cc: Vincent Abriou <vincent.abriou(a)st.com>
Cc: Thierry Reding <thierry.reding(a)gmail.com>
Cc: Eric Anholt <eric(a)anholt.net>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com>
Acked-by: Thierry Reding <treding(a)nvidia.com>
Signed-off-by: Jani Nikula <jani.nikula(a)intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/d527b31619528c477c2c136f25cdf…
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/drm_edid.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3347,8 +3347,7 @@ EXPORT_SYMBOL(drm_edid_get_monitor_name)
* @edid: EDID to parse
*
* Fill the ELD (EDID-Like Data) buffer for passing to the audio driver. The
- * Conn_Type, HDCP and Port_ID ELD fields are left for the graphics driver to
- * fill in.
+ * HDCP and Port_ID ELD fields are left for the graphics driver to fill in.
*/
void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid)
{
@@ -3426,6 +3425,12 @@ void drm_edid_to_eld(struct drm_connecto
}
eld[5] |= total_sad_count << 4;
+ if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
+ connector->connector_type == DRM_MODE_CONNECTOR_eDP)
+ eld[DRM_ELD_SAD_COUNT_CONN_TYPE] |= DRM_ELD_CONN_TYPE_DP;
+ else
+ eld[DRM_ELD_SAD_COUNT_CONN_TYPE] |= DRM_ELD_CONN_TYPE_HDMI;
+
eld[DRM_ELD_BASELINE_ELD_LEN] =
DIV_ROUND_UP(drm_eld_calc_baseline_block_size(eld), 4);
Patches currently in stable-queue which might be from jani.nikula(a)intel.com are
queue-4.9/drm-edid-set-eld-connector-type-in-drm_edid_to_eld.patch
This is a note to let you know that I've just added the patch titled
drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off)
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-defer-disabling-the-vblank-irq-until-the-next-interrupt-for-instant-off.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Chris Wilson <chris(a)chris-wilson.co.uk>
Date: Wed, 15 Mar 2017 20:40:25 +0000
Subject: drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off)
From: Chris Wilson <chris(a)chris-wilson.co.uk>
[ Upstream commit 608b20506941969ea30d8c08dc9ae02bb87dbf7d ]
On vblank instant-off systems, we can get into a situation where the cost
of enabling and disabling the vblank IRQ around a drmWaitVblank query
dominates. And with the advent of even deeper hardware sleep state,
touching registers becomes ever more expensive. However, we know that if
the user wants the current vblank counter, they are also very likely to
immediately queue a vblank wait and so we can keep the interrupt around
and only turn it off if we have no further vblank requests queued within
the interrupt interval.
After vblank event delivery, this patch adds a shadow of one vblank where
the interrupt is kept alive for the user to query and queue another vblank
event. Similarly, if the user is using blocking drmWaitVblanks, the
interrupt will be disabled on the IRQ following the wait completion.
However, if the user is simply querying the current vblank counter and
timestamp, the interrupt will be disabled after every IRQ and the user
will enabled it again on the first query following the IRQ.
v2: Mario Kleiner -
After testing this, one more thing that would make sense is to move
the disable block at the end of drm_handle_vblank() instead of at the
top.
Turns out that if high precision timestaming is disabled or doesn't
work for some reason (as can be simulated by echo 0 >
/sys/module/drm/parameters/timestamp_precision_usec), then with your
delayed disable code at its current place, the vblank counter won't
increment anymore at all for instant queries, ie. with your other
"instant query" patches. Clients which repeatedly query the counter
and wait for it to progress will simply hang, spinning in an endless
query loop. There's that comment in vblank_disable_and_save:
"* Skip this step if there isn't any high precision timestamp
* available. In that case we can't account for this and just
* hope for the best.
*/
With the disable happening after leading edge of vblank (== hw counter
increment already happened) but before the vblank counter/timestamp
handling in drm_handle_vblank, that step is needed to keep the counter
progressing, so skipping it is bad.
Now without high precision timestamping support, a kms driver must not
set dev->vblank_disable_immediate = true, as this would cause problems
for clients, so this shouldn't matter, but it would be good to still
make this robust against a future kms driver which might have
unreliable high precision timestamping, e.g., high precision
timestamping that intermittently doesn't work.
v3: Patch before coffee needs extra coffee.
Testcase: igt/kms_vblank
Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: Daniel Vetter <daniel(a)ffwll.ch>
Cc: Michel Dänzer <michel(a)daenzer.net>
Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Cc: Dave Airlie <airlied(a)redhat.com>,
Cc: Mario Kleiner <mario.kleiner.de(a)gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170315204027.20160-1-chris@c…
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/drm_irq.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1202,9 +1202,9 @@ static void drm_vblank_put(struct drm_de
if (atomic_dec_and_test(&vblank->refcount)) {
if (drm_vblank_offdelay == 0)
return;
- else if (dev->vblank_disable_immediate || drm_vblank_offdelay < 0)
+ else if (drm_vblank_offdelay < 0)
vblank_disable_fn((unsigned long)vblank);
- else
+ else if (!dev->vblank_disable_immediate)
mod_timer(&vblank->disable_timer,
jiffies + ((drm_vblank_offdelay * HZ)/1000));
}
@@ -1819,6 +1819,16 @@ bool drm_handle_vblank(struct drm_device
wake_up(&vblank->queue);
drm_handle_vblank_events(dev, pipe);
+ /* With instant-off, we defer disabling the interrupt until after
+ * we finish processing the following vblank. The disable has to
+ * be last (after drm_handle_vblank_events) so that the timestamp
+ * is always accurate.
+ */
+ if (dev->vblank_disable_immediate &&
+ drm_vblank_offdelay > 0 &&
+ !atomic_read(&vblank->refcount))
+ vblank_disable_fn((unsigned long)vblank);
+
spin_unlock_irqrestore(&dev->event_lock, irqflags);
return true;
Patches currently in stable-queue which might be from chris(a)chris-wilson.co.uk are
queue-4.9/drm-defer-disabling-the-vblank-irq-until-the-next-interrupt-for-instant-off.patch
queue-4.9/agp-intel-flush-all-chipset-writes-after-updating-the-ggtt.patch
This is a note to let you know that I've just added the patch titled
drm/amdkfd: Fix memory leaks in kfd topology
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-amdkfd-fix-memory-leaks-in-kfd-topology.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Yong Zhao <yong.zhao(a)amd.com>
Date: Fri, 8 Dec 2017 23:08:48 -0500
Subject: drm/amdkfd: Fix memory leaks in kfd topology
From: Yong Zhao <yong.zhao(a)amd.com>
[ Upstream commit 5108d768408abc80e4e8d99f5b406a73cb04056b ]
Kobject created using kobject_create_and_add() can be freed using
kobject_put() when there is no referenece any more. However,
kobject memory allocated with kzalloc() has to set up a release
callback in order to free it when the counter decreases to 0.
Otherwise it causes memory leak.
Signed-off-by: Yong Zhao <yong.zhao(a)amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling(a)amd.com>
Reviewed-by: Oded Gabbay <oded.gabbay(a)gmail.com>
Signed-off-by: Oded Gabbay <oded.gabbay(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
@@ -519,11 +519,17 @@ static ssize_t sysprops_show(struct kobj
return ret;
}
+static void kfd_topology_kobj_release(struct kobject *kobj)
+{
+ kfree(kobj);
+}
+
static const struct sysfs_ops sysprops_ops = {
.show = sysprops_show,
};
static struct kobj_type sysprops_type = {
+ .release = kfd_topology_kobj_release,
.sysfs_ops = &sysprops_ops,
};
@@ -559,6 +565,7 @@ static const struct sysfs_ops iolink_ops
};
static struct kobj_type iolink_type = {
+ .release = kfd_topology_kobj_release,
.sysfs_ops = &iolink_ops,
};
@@ -586,6 +593,7 @@ static const struct sysfs_ops mem_ops =
};
static struct kobj_type mem_type = {
+ .release = kfd_topology_kobj_release,
.sysfs_ops = &mem_ops,
};
@@ -625,6 +633,7 @@ static const struct sysfs_ops cache_ops
};
static struct kobj_type cache_type = {
+ .release = kfd_topology_kobj_release,
.sysfs_ops = &cache_ops,
};
@@ -747,6 +756,7 @@ static const struct sysfs_ops node_ops =
};
static struct kobj_type node_type = {
+ .release = kfd_topology_kobj_release,
.sysfs_ops = &node_ops,
};
Patches currently in stable-queue which might be from yong.zhao(a)amd.com are
queue-4.9/drm-amdkfd-fix-memory-leaks-in-kfd-topology.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: Fail fb creation from imported dma-bufs. (v2)
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-amdgpu-fail-fb-creation-from-imported-dma-bufs.-v2.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Christopher James Halse Rogers <christopher.halse.rogers(a)canonical.com>
Date: Wed, 29 Mar 2017 15:02:11 +1100
Subject: drm/amdgpu: Fail fb creation from imported dma-bufs. (v2)
From: Christopher James Halse Rogers <christopher.halse.rogers(a)canonical.com>
[ Upstream commit 1769152ac64b0b07583f696b621624df2ca4c840 ]
Any use of the framebuffer will migrate it to VRAM, which is not sensible for
an imported dma-buf.
v2: Use DRM_DEBUG_KMS to prevent userspace accidentally spamming dmesg.
Reviewed-by: Michel Dänzer <michel.daenzer(a)amd.com>
Reviewed-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers(a)canonical.com>
CC: amd-gfx(a)lists.freedesktop.org
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -533,6 +533,12 @@ amdgpu_user_framebuffer_create(struct dr
return ERR_PTR(-ENOENT);
}
+ /* Handle is imported dma-buf, so cannot be migrated to VRAM for scanout */
+ if (obj->import_attach) {
+ DRM_DEBUG_KMS("Cannot create framebuffer from imported dma_buf\n");
+ return ERR_PTR(-EINVAL);
+ }
+
amdgpu_fb = kzalloc(sizeof(*amdgpu_fb), GFP_KERNEL);
if (amdgpu_fb == NULL) {
drm_gem_object_unreference_unlocked(obj);
Patches currently in stable-queue which might be from christopher.halse.rogers(a)canonical.com are
queue-4.9/drm-amdgpu-fail-fb-creation-from-imported-dma-bufs.-v2.patch
queue-4.9/drm-radeon-fail-fb-creation-from-imported-dma-bufs.patch
This is a note to let you know that I've just added the patch titled
drivers/perf: arm_pmu: handle no platform_device
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drivers-perf-arm_pmu-handle-no-platform_device.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Mark Rutland <mark.rutland(a)arm.com>
Date: Tue, 11 Apr 2017 09:39:49 +0100
Subject: drivers/perf: arm_pmu: handle no platform_device
From: Mark Rutland <mark.rutland(a)arm.com>
[ Upstream commit 7654137071fa706e5c91f4f27bc2a5cd7e435a9b ]
In armpmu_dispatch_irq() we look at arm_pmu::plat_device to acquire
platdata, so that we can defer to platform-specific IRQ handling,
required on some 32-bit parts. With the advent of ACPI we won't always
have a platform_device, and so we must avoid trying to dereference
fields from it.
This patch fixes up armpmu_dispatch_irq() to avoid doing so, introducing
a new armpmu_get_platdata() helper.
Signed-off-by: Mark Rutland <mark.rutland(a)arm.com>
Tested-by: Jeremy Linton <jeremy.linton(a)arm.com>
Cc: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/perf/arm_pmu.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -322,10 +322,16 @@ validate_group(struct perf_event *event)
return 0;
}
+static struct arm_pmu_platdata *armpmu_get_platdata(struct arm_pmu *armpmu)
+{
+ struct platform_device *pdev = armpmu->plat_device;
+
+ return pdev ? dev_get_platdata(&pdev->dev) : NULL;
+}
+
static irqreturn_t armpmu_dispatch_irq(int irq, void *dev)
{
struct arm_pmu *armpmu;
- struct platform_device *plat_device;
struct arm_pmu_platdata *plat;
int ret;
u64 start_clock, finish_clock;
@@ -337,8 +343,8 @@ static irqreturn_t armpmu_dispatch_irq(i
* dereference.
*/
armpmu = *(void **)dev;
- plat_device = armpmu->plat_device;
- plat = dev_get_platdata(&plat_device->dev);
+
+ plat = armpmu_get_platdata(armpmu);
start_clock = sched_clock();
if (plat && plat->handle_irq)
Patches currently in stable-queue which might be from mark.rutland(a)arm.com are
queue-4.9/drivers-perf-arm_pmu-handle-no-platform_device.patch
This is a note to let you know that I've just added the patch titled
drivers: net: xgene: Fix wrong logical operation
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drivers-net-xgene-fix-wrong-logical-operation.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Quan Nguyen <qnguyen(a)apm.com>
Date: Wed, 15 Mar 2017 13:27:17 -0700
Subject: drivers: net: xgene: Fix wrong logical operation
From: Quan Nguyen <qnguyen(a)apm.com>
[ Upstream commit 11623fce0f9afef30c45e3f2120b063de3809a8f ]
This patch fixes the wrong logical OR operation by changing it to
bit-wise OR operation.
Fixes: 3bb502f83080 ("drivers: net: xgene: fix statistics counters race condition")
Signed-off-by: Iyappan Subramanian <isubramanian(a)apm.com>
Signed-off-by: Quan Nguyen <qnguyen(a)apm.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -537,9 +537,9 @@ static int xgene_enet_rx_frame(struct xg
buf_pool->rx_skb[skb_index] = NULL;
/* checking for error */
- status = (GET_VAL(ELERR, le64_to_cpu(raw_desc->m0)) << LERR_LEN) ||
+ status = (GET_VAL(ELERR, le64_to_cpu(raw_desc->m0)) << LERR_LEN) |
GET_VAL(LERR, le64_to_cpu(raw_desc->m0));
- if (unlikely(status > 2)) {
+ if (unlikely(status)) {
dev_kfree_skb_any(skb);
xgene_enet_parse_error(rx_ring, netdev_priv(rx_ring->ndev),
status);
Patches currently in stable-queue which might be from qnguyen(a)apm.com are
queue-4.9/drivers-net-xgene-fix-wrong-logical-operation.patch
queue-4.9/drivers-net-xgene-fix-hardware-checksum-setting.patch
queue-4.9/drivers-net-phy-xgene-fix-mdio-write.patch
This is a note to let you know that I've just added the patch titled
drivers: net: xgene: Fix hardware checksum setting
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drivers-net-xgene-fix-hardware-checksum-setting.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Quan Nguyen <qnguyen(a)apm.com>
Date: Wed, 15 Mar 2017 13:27:16 -0700
Subject: drivers: net: xgene: Fix hardware checksum setting
From: Quan Nguyen <qnguyen(a)apm.com>
[ Upstream commit e026e700d940a1ea3d3bc84d92ac668b1f015462 ]
This patch fixes the hardware checksum settings by properly program
the classifier. Otherwise, packet may be received with checksum error
on X-Gene1 SoC.
Signed-off-by: Quan Nguyen <qnguyen(a)apm.com>
Signed-off-by: Iyappan Subramanian <isubramanian(a)apm.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 1 +
drivers/net/ethernet/apm/xgene/xgene_enet_hw.h | 1 +
2 files changed, 2 insertions(+)
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
@@ -560,6 +560,7 @@ static void xgene_enet_cle_bypass(struct
xgene_enet_rd_csr(pdata, CLE_BYPASS_REG0_0_ADDR, &cb);
cb |= CFG_CLE_BYPASS_EN0;
CFG_CLE_IP_PROTOCOL0_SET(&cb, 3);
+ CFG_CLE_IP_HDR_LEN_SET(&cb, 0);
xgene_enet_wr_csr(pdata, CLE_BYPASS_REG0_0_ADDR, cb);
xgene_enet_rd_csr(pdata, CLE_BYPASS_REG1_0_ADDR, &cb);
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
@@ -163,6 +163,7 @@ enum xgene_enet_rm {
#define CFG_RXCLK_MUXSEL0_SET(dst, val) xgene_set_bits(dst, val, 26, 3)
#define CFG_CLE_IP_PROTOCOL0_SET(dst, val) xgene_set_bits(dst, val, 16, 2)
+#define CFG_CLE_IP_HDR_LEN_SET(dst, val) xgene_set_bits(dst, val, 8, 5)
#define CFG_CLE_DSTQID0_SET(dst, val) xgene_set_bits(dst, val, 0, 12)
#define CFG_CLE_FPSEL0_SET(dst, val) xgene_set_bits(dst, val, 16, 4)
#define CFG_MACMODE_SET(dst, val) xgene_set_bits(dst, val, 18, 2)
Patches currently in stable-queue which might be from qnguyen(a)apm.com are
queue-4.9/drivers-net-xgene-fix-wrong-logical-operation.patch
queue-4.9/drivers-net-xgene-fix-hardware-checksum-setting.patch
queue-4.9/drivers-net-phy-xgene-fix-mdio-write.patch
This is a note to let you know that I've just added the patch titled
drivers: net: phy: xgene: Fix mdio write
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drivers-net-phy-xgene-fix-mdio-write.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Quan Nguyen <qnguyen(a)apm.com>
Date: Wed, 15 Mar 2017 13:27:15 -0700
Subject: drivers: net: phy: xgene: Fix mdio write
From: Quan Nguyen <qnguyen(a)apm.com>
[ Upstream commit 4b72436dc3dd2457056b22d6f147777368c869fa ]
This patches fixes a typo in the argument to xgene_enet_wr_mdio_csr().
Signed-off-by: Quan Nguyen <qnguyen(a)apm.com>
Signed-off-by: Iyappan Subramanian <isubramanian(a)apm.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/phy/mdio-xgene.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/phy/mdio-xgene.c
+++ b/drivers/net/phy/mdio-xgene.c
@@ -232,7 +232,7 @@ static int xgene_xfi_mdio_write(struct m
val = SET_VAL(HSTPHYADX, phy_id) | SET_VAL(HSTREGADX, reg) |
SET_VAL(HSTMIIMWRDAT, data);
- xgene_enet_wr_mdio_csr(addr, MIIM_FIELD_ADDR, data);
+ xgene_enet_wr_mdio_csr(addr, MIIM_FIELD_ADDR, val);
val = HSTLDCMD | SET_VAL(HSTMIIMCMD, MIIM_CMD_LEGACY_WRITE);
xgene_enet_wr_mdio_csr(addr, MIIM_COMMAND_ADDR, val);
Patches currently in stable-queue which might be from qnguyen(a)apm.com are
queue-4.9/drivers-net-xgene-fix-wrong-logical-operation.patch
queue-4.9/drivers-net-xgene-fix-hardware-checksum-setting.patch
queue-4.9/drivers-net-phy-xgene-fix-mdio-write.patch
This is a note to let you know that I've just added the patch titled
driver: (adm1275) set the m,b and R coefficients correctly for power
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
driver-adm1275-set-the-m-b-and-r-coefficients-correctly-for-power.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Sun Mar 18 16:55:33 CET 2018
From: Shikhar Dogra <shidogra(a)cisco.com>
Date: Mon, 27 Mar 2017 16:16:44 -0700
Subject: driver: (adm1275) set the m,b and R coefficients correctly for power
From: Shikhar Dogra <shidogra(a)cisco.com>
[ Upstream commit 6faecba0b3da7b617bf72bef422bf0d3bb6dfe7d ]
Seems like coefficient values for m, b and R under power have been
put in the wrong order. Rearranging them properly to get correct
values of coefficients for power.
For specs, please refer to table 7 (page 35) on
http://www.analog.com/media/en/technical-documentation/data-sheets/ADM1075.…
Fixes: 904b296f308d ("hwmon: (adm1275) Introduce configuration data structure for coeffcients")
Signed-off-by: Shikhar Dogra <shidogra(a)cisco.com>
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hwmon/pmbus/adm1275.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/hwmon/pmbus/adm1275.c
+++ b/drivers/hwmon/pmbus/adm1275.c
@@ -101,8 +101,8 @@ static const struct coefficients adm1075
[0] = { 27169, 0, -1 }, /* voltage */
[1] = { 806, 20475, -1 }, /* current, irange25 */
[2] = { 404, 20475, -1 }, /* current, irange50 */
- [3] = { 0, -1, 8549 }, /* power, irange25 */
- [4] = { 0, -1, 4279 }, /* power, irange50 */
+ [3] = { 8549, 0, -1 }, /* power, irange25 */
+ [4] = { 4279, 0, -1 }, /* power, irange50 */
};
static const struct coefficients adm1275_coefficients[] = {
Patches currently in stable-queue which might be from shidogra(a)cisco.com are
queue-4.9/driver-adm1275-set-the-m-b-and-r-coefficients-correctly-for-power.patch