This is a note to let you know that I've just added the patch titled
ima: relax requiring a file signature for new files with zero length
to the 4.14-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:
ima-relax-requiring-a-file-signature-for-new-files-with-zero-length.patch
and it can be found in the queue-4.14 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 Fri Mar 16 15:43:17 CET 2018
From: Mimi Zohar <zohar(a)linux.vnet.ibm.com>
Date: Wed, 8 Nov 2017 07:38:28 -0500
Subject: ima: relax requiring a file signature for new files with zero length
From: Mimi Zohar <zohar(a)linux.vnet.ibm.com>
[ Upstream commit b7e27bc1d42e8e0cc58b602b529c25cd0071b336 ]
Custom policies can require file signatures based on LSM labels. These
files are normally created and only afterwards labeled, requiring them
to be signed.
Instead of requiring file signatures based on LSM labels, entire
filesystems could require file signatures. In this case, we need the
ability of writing new files without requiring file signatures.
The definition of a "new" file was originally defined as any file with
a length of zero. Subsequent patches redefined a "new" file to be based
on the FILE_CREATE open flag. By combining the open flag with a file
size of zero, this patch relaxes the file signature requirement.
Fixes: 1ac202e978e1 ima: accept previously set IMA_NEW_FILE
Signed-off-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/integrity/ima/ima_appraise.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -223,7 +223,8 @@ int ima_appraise_measurement(enum ima_ho
if (opened & FILE_CREATED)
iint->flags |= IMA_NEW_FILE;
if ((iint->flags & IMA_NEW_FILE) &&
- !(iint->flags & IMA_DIGSIG_REQUIRED))
+ (!(iint->flags & IMA_DIGSIG_REQUIRED) ||
+ (inode->i_size == 0)))
status = INTEGRITY_PASS;
goto out;
}
Patches currently in stable-queue which might be from zohar(a)linux.vnet.ibm.com are
queue-4.14/ima-relax-requiring-a-file-signature-for-new-files-with-zero-length.patch
This is a note to let you know that I've just added the patch titled
iio: health: max30102: Add power enable parameter to get_temp function
to the 4.14-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:
iio-health-max30102-add-power-enable-parameter-to-get_temp-function.patch
and it can be found in the queue-4.14 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 Fri Mar 16 15:43:17 CET 2018
From: Peter Meerwald-Stadler <pmeerw(a)pmeerw.net>
Date: Fri, 27 Oct 2017 21:45:38 +0200
Subject: iio: health: max30102: Add power enable parameter to get_temp function
From: Peter Meerwald-Stadler <pmeerw(a)pmeerw.net>
[ Upstream commit a9c47abbdd71dceeaf1b923e5ce10e700e036905 ]
Chip must not be in shutdown for reading temperature, so briefly leave
shutdown if buffer is not already running
Signed-off-by: Peter Meerwald-Stadler <pmeerw(a)pmeerw.net>
Acked-by: Matt Ranostay <matt.ranostay(a)konsulko.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/health/max30102.c | 36 +++++++++++++++++++++++-------------
1 file changed, 23 insertions(+), 13 deletions(-)
--- a/drivers/iio/health/max30102.c
+++ b/drivers/iio/health/max30102.c
@@ -329,20 +329,31 @@ static int max30102_read_temp(struct max
return 0;
}
-static int max30102_get_temp(struct max30102_data *data, int *val)
+static int max30102_get_temp(struct max30102_data *data, int *val, bool en)
{
int ret;
+ if (en) {
+ ret = max30102_set_powermode(data, true);
+ if (ret)
+ return ret;
+ }
+
/* start acquisition */
ret = regmap_update_bits(data->regmap, MAX30102_REG_TEMP_CONFIG,
MAX30102_REG_TEMP_CONFIG_TEMP_EN,
MAX30102_REG_TEMP_CONFIG_TEMP_EN);
if (ret)
- return ret;
+ goto out;
msleep(35);
+ ret = max30102_read_temp(data, val);
+
+out:
+ if (en)
+ max30102_set_powermode(data, false);
- return max30102_read_temp(data, val);
+ return ret;
}
static int max30102_read_raw(struct iio_dev *indio_dev,
@@ -355,20 +366,19 @@ static int max30102_read_raw(struct iio_
switch (mask) {
case IIO_CHAN_INFO_RAW:
/*
- * Temperature reading can only be acquired while engine
- * is running
+ * Temperature reading can only be acquired when not in
+ * shutdown; leave shutdown briefly when buffer not running
*/
mutex_lock(&indio_dev->mlock);
-
if (!iio_buffer_enabled(indio_dev))
- ret = -EBUSY;
- else {
- ret = max30102_get_temp(data, val);
- if (!ret)
- ret = IIO_VAL_INT;
- }
-
+ ret = max30102_get_temp(data, val, true);
+ else
+ ret = max30102_get_temp(data, val, false);
mutex_unlock(&indio_dev->mlock);
+ if (ret)
+ return ret;
+
+ ret = IIO_VAL_INT;
break;
case IIO_CHAN_INFO_SCALE:
*val = 1000; /* 62.5 */
Patches currently in stable-queue which might be from pmeerw(a)pmeerw.net are
queue-4.14/iio-health-max30102-add-power-enable-parameter-to-get_temp-function.patch
This is a note to let you know that I've just added the patch titled
IB/mlx5: revisit -Wmaybe-uninitialized warning
to the 4.14-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:
ib-mlx5-revisit-wmaybe-uninitialized-warning.patch
and it can be found in the queue-4.14 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 Fri Mar 16 15:43:17 CET 2018
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Mon, 11 Dec 2017 12:45:44 +0100
Subject: IB/mlx5: revisit -Wmaybe-uninitialized warning
From: Arnd Bergmann <arnd(a)arndb.de>
[ Upstream commit 1b19b95169cd52fe82cd442fec0b279fe25cc838 ]
A warning that I thought I had fixed before occasionally comes
back in rare randconfig builds (I found 7 instances in the last
100000 builds, originally it was much more frequent):
drivers/infiniband/hw/mlx5/mr.c: In function 'mlx5_ib_reg_user_mr':
drivers/infiniband/hw/mlx5/mr.c:1229:5: error: 'order' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (order <= mr_cache_max_order(dev)) {
^
drivers/infiniband/hw/mlx5/mr.c:1247:8: error: 'ncont' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/infiniband/hw/mlx5/mr.c:1247:8: error: 'page_shift' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/infiniband/hw/mlx5/mr.c:1260:2: error: 'npages' may be used uninitialized in this function [-Werror=maybe-uninitialized]
I've looked at all those findings again and noticed that they are all
with CONFIG_INFINIBAND_USER_MEM=n, which means ib_umem_get() returns
an error unconditionally and we never initialize or use those variables.
This triggers a condition in gcc iff mr_umem_get() is partially but not
entirely inlined, which in turn depends on the exact combination of
optimization settings. This is a known problem with gcc, with no
easy solution in the compiler, so this adds another workaround that
should be more reliable than my previous attempt.
Returning an error from mlx5_ib_reg_user_mr() earlier means that we
can completely bypass the logic that caused the warning, the compiler
can now see that the variable is never accessed.
Fixes: 14ab8896f5d9 ("IB/mlx5: avoid bogus -Wmaybe-uninitialized warning")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/mlx5/mr.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -1206,6 +1206,9 @@ struct ib_mr *mlx5_ib_reg_user_mr(struct
int err;
bool use_umr = true;
+ if (!IS_ENABLED(CONFIG_INFINIBAND_USER_MEM))
+ return ERR_PTR(-EINVAL);
+
mlx5_ib_dbg(dev, "start 0x%llx, virt_addr 0x%llx, length 0x%llx, access_flags 0x%x\n",
start, virt_addr, length, access_flags);
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.14/ib-mlx5-revisit-wmaybe-uninitialized-warning.patch
queue-4.14/earlycon-add-reg-offset-to-physical-address-before-mapping.patch
This is a note to let you know that I've just added the patch titled
HID: multitouch: Only look at non touch fields in first packet of a frame
to the 4.14-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:
hid-multitouch-only-look-at-non-touch-fields-in-first-packet-of-a-frame.patch
and it can be found in the queue-4.14 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 Fri Mar 16 15:43:16 CET 2018
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Wed, 22 Nov 2017 12:57:09 +0100
Subject: HID: multitouch: Only look at non touch fields in first packet of a frame
From: Hans de Goede <hdegoede(a)redhat.com>
[ Upstream commit 55746d28d66860bccaae20a67b55b9d5db7c14af ]
Devices in "single finger hybrid mode" will send one report per finger,
on some devices only the first report of such a multi-packet frame will
contain a value for BTN_LEFT, in subsequent reports (if multiple fingers
are down) the value is always 0, causing hid-mt to report BTN_LEFT going
1 - 0 - 1 - 0 when pressing a clickpad and putting down a second finger.
This happens for example on USB 0603:0002 mt touchpads.
This commit fixes this by only reporting non touch fields for the first
packet of a (possibly) multi-packet frame.
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com>
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/hid-multitouch.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -738,9 +738,11 @@ static int mt_touch_event(struct hid_dev
}
static void mt_process_mt_event(struct hid_device *hid, struct hid_field *field,
- struct hid_usage *usage, __s32 value)
+ struct hid_usage *usage, __s32 value,
+ bool first_packet)
{
struct mt_device *td = hid_get_drvdata(hid);
+ __s32 cls = td->mtclass.name;
__s32 quirks = td->mtclass.quirks;
struct input_dev *input = field->hidinput->input;
@@ -794,6 +796,15 @@ static void mt_process_mt_event(struct h
break;
default:
+ /*
+ * For Win8 PTP touchpads we should only look at
+ * non finger/touch events in the first_packet of
+ * a (possible) multi-packet frame.
+ */
+ if ((cls == MT_CLS_WIN_8 || cls == MT_CLS_WIN_8_DUAL) &&
+ !first_packet)
+ return;
+
if (usage->type)
input_event(input, usage->type, usage->code,
value);
@@ -813,6 +824,7 @@ static void mt_touch_report(struct hid_d
{
struct mt_device *td = hid_get_drvdata(hid);
struct hid_field *field;
+ bool first_packet;
unsigned count;
int r, n;
@@ -831,6 +843,7 @@ static void mt_touch_report(struct hid_d
td->num_expected = value;
}
+ first_packet = td->num_received == 0;
for (r = 0; r < report->maxfield; r++) {
field = report->field[r];
count = field->report_count;
@@ -840,7 +853,7 @@ static void mt_touch_report(struct hid_d
for (n = 0; n < count; n++)
mt_process_mt_event(hid, field, &field->usage[n],
- field->value[n]);
+ field->value[n], first_packet);
}
if (td->num_received >= td->num_expected)
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.14/asoc-rt5651-fix-regcache-sync-errors-on-resume.patch
queue-4.14/uas-fix-comparison-for-error-code.patch
queue-4.14/hid-multitouch-only-look-at-non-touch-fields-in-first-packet-of-a-frame.patch
This is a note to let you know that I've just added the patch titled
HID: elo: clear BTN_LEFT mapping
to the 4.14-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:
hid-elo-clear-btn_left-mapping.patch
and it can be found in the queue-4.14 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 Fri Mar 16 15:43:16 CET 2018
From: Jiri Kosina <jkosina(a)suse.cz>
Date: Wed, 22 Nov 2017 11:19:51 +0100
Subject: HID: elo: clear BTN_LEFT mapping
From: Jiri Kosina <jkosina(a)suse.cz>
[ Upstream commit 9abd04af951e5734c9d5cfee9b49790844b734cf ]
ELO devices have one Button usage in GenDesk field, which makes hid-input map
it to BTN_LEFT; that confuses userspace, which then considers the device to be
a mouse/touchpad instead of touchscreen.
Fix that by unmapping BTN_LEFT and keeping only BTN_TOUCH in place.
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/hid-elo.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/hid/hid-elo.c
+++ b/drivers/hid/hid-elo.c
@@ -42,6 +42,12 @@ static int elo_input_configured(struct h
{
struct input_dev *input = hidinput->input;
+ /*
+ * ELO devices have one Button usage in GenDesk field, which makes
+ * hid-input map it to BTN_LEFT; that confuses userspace, which then
+ * considers the device to be a mouse/touchpad instead of touchscreen.
+ */
+ clear_bit(BTN_LEFT, input->keybit);
set_bit(BTN_TOUCH, input->keybit);
set_bit(ABS_PRESSURE, input->absbit);
input_set_abs_params(input, ABS_PRESSURE, 0, 256, 0, 0);
Patches currently in stable-queue which might be from jkosina(a)suse.cz are
queue-4.14/hid-elo-clear-btn_left-mapping.patch
queue-4.14/hid-multitouch-only-look-at-non-touch-fields-in-first-packet-of-a-frame.patch
This is a note to let you know that I've just added the patch titled
Fix misannotated out-of-line _copy_to_user()
to the 4.14-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:
fix-misannotated-out-of-line-_copy_to_user.patch
and it can be found in the queue-4.14 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 Fri Mar 16 15:43:17 CET 2018
From: Christophe Leroy <christophe.leroy(a)c-s.fr>
Date: Sat, 9 Dec 2017 17:24:24 +0100
Subject: Fix misannotated out-of-line _copy_to_user()
From: Christophe Leroy <christophe.leroy(a)c-s.fr>
[ Upstream commit a0e94598e6b6c0d1df6a5fa14eb7c767ca817a20 ]
Destination is a kernel pointer and source - a userland one
in _copy_from_user(); _copy_to_user() is the other way round.
Fixes: d597580d37377 ("generic ...copy_..._user primitives")
Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr>
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
lib/usercopy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/lib/usercopy.c
+++ b/lib/usercopy.c
@@ -20,7 +20,7 @@ EXPORT_SYMBOL(_copy_from_user);
#endif
#ifndef INLINE_COPY_TO_USER
-unsigned long _copy_to_user(void *to, const void __user *from, unsigned long n)
+unsigned long _copy_to_user(void __user *to, const void *from, unsigned long n)
{
might_fault();
if (likely(access_ok(VERIFY_WRITE, to, n))) {
Patches currently in stable-queue which might be from christophe.leroy(a)c-s.fr are
queue-4.14/fix-misannotated-out-of-line-_copy_to_user.patch
This is a note to let you know that I've just added the patch titled
drm/sun4i: Fix format mask in DE2 driver
to the 4.14-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-sun4i-fix-format-mask-in-de2-driver.patch
and it can be found in the queue-4.14 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 Fri Mar 16 15:43:17 CET 2018
From: Jernej Skrabec <jernej.skrabec(a)siol.net>
Date: Fri, 1 Dec 2017 07:05:24 +0100
Subject: drm/sun4i: Fix format mask in DE2 driver
From: Jernej Skrabec <jernej.skrabec(a)siol.net>
[ Upstream commit a2407f4bd1f3001d6b46f6d32eb1cc98a60f5a43 ]
Format mask is one bit too short. Fix it.
Fixes: 9d75b8c0b999 (drm/sun4i: add support for Allwinner DE2 mixers)
Signed-off-by: Jernej Skrabec <jernej.skrabec(a)siol.net>
Signed-off-by: Maxime Ripard <maxime.ripard(a)free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171201060550.10392-2-jernej…
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/sun4i/sun8i_mixer.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
@@ -80,7 +80,7 @@
#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN BIT(0)
#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_MASK GENMASK(2, 1)
-#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_MASK GENMASK(11, 8)
+#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_MASK GENMASK(12, 8)
#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MASK GENMASK(31, 24)
#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_DEF (1 << 1)
#define SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_ARGB8888 (0 << 8)
Patches currently in stable-queue which might be from jernej.skrabec(a)siol.net are
queue-4.14/drm-sun4i-fix-format-mask-in-de2-driver.patch
This is a note to let you know that I've just added the patch titled
drm/etnaviv: make THERMAL selectable
to the 4.14-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-etnaviv-make-thermal-selectable.patch
and it can be found in the queue-4.14 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 Fri Mar 16 15:43:17 CET 2018
From: Philipp Zabel <p.zabel(a)pengutronix.de>
Date: Fri, 1 Dec 2017 16:00:41 +0100
Subject: drm/etnaviv: make THERMAL selectable
From: Philipp Zabel <p.zabel(a)pengutronix.de>
[ Upstream commit 49b82c389d2a40eaef1355aaa35868b367aec9d1 ]
The etnaviv driver causes a link failure if it is built-in but THERMAL
is built as a module:
drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_bind':
etnaviv_gpu.c:(.text+0x4c4): undefined reference to `thermal_of_cooling_device_register'
etnaviv_gpu.c:(.text+0x600): undefined reference to `thermal_cooling_device_unregister'
drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_unbind':
etnaviv_gpu.c:(.text+0x2aac): undefined reference to `thermal_cooling_device_unregister'
Adding a Kconfig dependency on THERMAL || !THERMAL to avoid this causes
a dependency loop on x86_64:
drivers/gpu/drm/tve200/Kconfig:1:error: recursive dependency detected!
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/tve200/Kconfig:1: symbol DRM_TVE200 depends on CMA
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
mm/Kconfig:489: symbol CMA is selected by DRM_ETNAVIV
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/etnaviv/Kconfig:2: symbol DRM_ETNAVIV depends on THERMAL
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/thermal/Kconfig:5: symbol THERMAL is selected by ACPI_VIDEO
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/acpi/Kconfig:189: symbol ACPI_VIDEO is selected by BACKLIGHT_CLASS_DEVICE
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/backlight/Kconfig:158: symbol BACKLIGHT_CLASS_DEVICE is selected by DRM_PARADE_PS8622
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/bridge/Kconfig:62: symbol DRM_PARADE_PS8622 depends on DRM_BRIDGE
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_BRIDGE is selected by DRM_TVE200
To work around this, add a new option DRM_ETNAVIV_THERMAL to optionally
enable thermal throttling support and make DRM_ETNAVIV select THERMAL
at the same time.
Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au>
Signed-off-by: Philipp Zabel <p.zabel(a)pengutronix.de>
Signed-off-by: Lucas Stach <l.stach(a)pengutronix.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/etnaviv/Kconfig | 9 +++++++++
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 8 +++++---
2 files changed, 14 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/etnaviv/Kconfig
+++ b/drivers/gpu/drm/etnaviv/Kconfig
@@ -6,6 +6,7 @@ config DRM_ETNAVIV
depends on MMU
select SHMEM
select SYNC_FILE
+ select THERMAL if DRM_ETNAVIV_THERMAL
select TMPFS
select IOMMU_API
select IOMMU_SUPPORT
@@ -15,6 +16,14 @@ config DRM_ETNAVIV
help
DRM driver for Vivante GPUs.
+config DRM_ETNAVIV_THERMAL
+ bool "enable ETNAVIV thermal throttling"
+ depends on DRM_ETNAVIV
+ default y
+ help
+ Compile in support for thermal throttling.
+ Say Y unless you want to risk burning your SoC.
+
config DRM_ETNAVIV_REGISTER_LOGGING
bool "enable ETNAVIV register logging"
depends on DRM_ETNAVIV
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1622,7 +1622,7 @@ static int etnaviv_gpu_bind(struct devic
struct etnaviv_gpu *gpu = dev_get_drvdata(dev);
int ret;
- if (IS_ENABLED(CONFIG_THERMAL)) {
+ if (IS_ENABLED(CONFIG_DRM_ETNAVIV_THERMAL)) {
gpu->cooling = thermal_of_cooling_device_register(dev->of_node,
(char *)dev_name(dev), gpu, &cooling_ops);
if (IS_ERR(gpu->cooling))
@@ -1635,7 +1635,8 @@ static int etnaviv_gpu_bind(struct devic
ret = etnaviv_gpu_clk_enable(gpu);
#endif
if (ret < 0) {
- thermal_cooling_device_unregister(gpu->cooling);
+ if (IS_ENABLED(CONFIG_DRM_ETNAVIV_THERMAL))
+ thermal_cooling_device_unregister(gpu->cooling);
return ret;
}
@@ -1692,7 +1693,8 @@ static void etnaviv_gpu_unbind(struct de
gpu->drm = NULL;
- thermal_cooling_device_unregister(gpu->cooling);
+ if (IS_ENABLED(CONFIG_DRM_ETNAVIV_THERMAL))
+ thermal_cooling_device_unregister(gpu->cooling);
gpu->cooling = NULL;
}
Patches currently in stable-queue which might be from p.zabel(a)pengutronix.de are
queue-4.14/drm-edid-set-eld-connector-type-in-drm_edid_to_eld.patch
queue-4.14/drm-etnaviv-make-thermal-selectable.patch
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.14-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.14 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 Fri Mar 16 15:43:16 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
@@ -3823,8 +3823,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)
{
@@ -3905,6 +3904,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.14/drm-edid-set-eld-connector-type-in-drm_edid_to_eld.patch