[PATCH v3 1/3] KVM: s390: vsie: copy wrapping keys to right place
Copy the key mask to the right offset inside the shadow CRYCB Signed-off-by: Pierre Morel Reviewed-by: David Hildenbrand Reviewed-by: Cornelia Huck Reviewed-by: Janosch Frank --- arch/s390/kvm/vsie.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c index 9175518..12b9707 100644 --- a/arch/s390/kvm/vsie.c +++ b/arch/s390/kvm/vsie.c @@ -173,7 +173,8 @@ static int shadow_crycb(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page) return set_validity_icpt(scb_s, 0x0039U); /* copy only the wrapping keys */ - if (read_guest_real(vcpu, crycb_addr + 72, _page->crycb, 56)) + if (read_guest_real(vcpu, crycb_addr + 72, + vsie_page->crycb.dea_wrapping_key_mask, 56)) return set_validity_icpt(scb_s, 0x0035U); scb_s->ecb3 |= ecb3_flags; -- 2.7.4
[PATCH v3 1/3] KVM: s390: vsie: copy wrapping keys to right place
Copy the key mask to the right offset inside the shadow CRYCB Signed-off-by: Pierre Morel Reviewed-by: David Hildenbrand Reviewed-by: Cornelia Huck Reviewed-by: Janosch Frank --- arch/s390/kvm/vsie.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c index 9175518..12b9707 100644 --- a/arch/s390/kvm/vsie.c +++ b/arch/s390/kvm/vsie.c @@ -173,7 +173,8 @@ static int shadow_crycb(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page) return set_validity_icpt(scb_s, 0x0039U); /* copy only the wrapping keys */ - if (read_guest_real(vcpu, crycb_addr + 72, _page->crycb, 56)) + if (read_guest_real(vcpu, crycb_addr + 72, + vsie_page->crycb.dea_wrapping_key_mask, 56)) return set_validity_icpt(scb_s, 0x0035U); scb_s->ecb3 |= ecb3_flags; -- 2.7.4
[PATCH] tracing: Fix event filters and triggers to handle negative numbers
Then tracing syscall exit event it is extremely useful to filter exit
codes equal to some negative value, to react only to required errors.
But negative numbers does not work:
[root@snorch sys_exit_read]# echo "ret == -1" > filter
bash: echo: write error: Invalid argument
[root@snorch sys_exit_read]# cat filter
ret == -1
^
parse_error: Invalid value (did you forget quotes)?
Similar thing happens when setting triggers.
These is a regression in v4.17 introduced by the commit mentioned below,
testing without these commit shows no problem with negative numbers.
Fixes: 80765597bc58 ("tracing: Rewrite filter logic to be simpler and faster")
Signed-off-by: Pavel Tikhomirov
---
kernel/trace/trace_events_filter.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/trace_events_filter.c
b/kernel/trace/trace_events_filter.c
index 84a65173b1e9..2ba449292561 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -1299,7 +1299,7 @@ static int parse_pred(const char *str, void *data,
/* go past the last quote */
i++;
- } else if (isdigit(str[i])) {
+ } else if (isdigit(str[i]) || str[i] == '-') {
/* Make sure the field is not a string */
if (is_string_field(field)) {
@@ -1312,6 +1312,9 @@ static int parse_pred(const char *str, void *data,
goto err_free;
}
+ if (str[i] == '-')
+ i++;
+
/* We allow 0xDEADBEEF */
while (isalnum(str[i]))
i++;
--
2.17.1
[PATCH] tracing: Fix event filters and triggers to handle negative numbers
Then tracing syscall exit event it is extremely useful to filter exit
codes equal to some negative value, to react only to required errors.
But negative numbers does not work:
[root@snorch sys_exit_read]# echo "ret == -1" > filter
bash: echo: write error: Invalid argument
[root@snorch sys_exit_read]# cat filter
ret == -1
^
parse_error: Invalid value (did you forget quotes)?
Similar thing happens when setting triggers.
These is a regression in v4.17 introduced by the commit mentioned below,
testing without these commit shows no problem with negative numbers.
Fixes: 80765597bc58 ("tracing: Rewrite filter logic to be simpler and faster")
Signed-off-by: Pavel Tikhomirov
---
kernel/trace/trace_events_filter.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/trace_events_filter.c
b/kernel/trace/trace_events_filter.c
index 84a65173b1e9..2ba449292561 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -1299,7 +1299,7 @@ static int parse_pred(const char *str, void *data,
/* go past the last quote */
i++;
- } else if (isdigit(str[i])) {
+ } else if (isdigit(str[i]) || str[i] == '-') {
/* Make sure the field is not a string */
if (is_string_field(field)) {
@@ -1312,6 +1312,9 @@ static int parse_pred(const char *str, void *data,
goto err_free;
}
+ if (str[i] == '-')
+ i++;
+
/* We allow 0xDEADBEEF */
while (isalnum(str[i]))
i++;
--
2.17.1
Re: [PATCH v9 12/22] s390: vfio-ap: sysfs interfaces to configure control domains
On Wed, 22 Aug 2018 15:16:19 -0400 Tony Krowiak wrote: > One of the things I suggested in a private conversation with Christian > earlier > today was to provide an additional rw sysfs attribute - a boolean - that > indicates > whether all usage domains should also be control domains. The default > could be > true. This would allow one to configure guests with usage-only domains > as well > as satisfy the convention. Would this additional attribute then control "add usage domains to the list of control domains automatically", or "don't allow to add a usage domain if it has not already been added as a control domain"? One thing I'm still unsure about is how libvirt comes into the picture here. Will it consume the setting, or actively manipulate it? [In general, I'm not very clear about how libvirt will interact with the whole infrastructure...]
Re: [PATCH v9 12/22] s390: vfio-ap: sysfs interfaces to configure control domains
On Wed, 22 Aug 2018 15:16:19 -0400 Tony Krowiak wrote: > One of the things I suggested in a private conversation with Christian > earlier > today was to provide an additional rw sysfs attribute - a boolean - that > indicates > whether all usage domains should also be control domains. The default > could be > true. This would allow one to configure guests with usage-only domains > as well > as satisfy the convention. Would this additional attribute then control "add usage domains to the list of control domains automatically", or "don't allow to add a usage domain if it has not already been added as a control domain"? One thing I'm still unsure about is how libvirt comes into the picture here. Will it consume the setting, or actively manipulate it? [In general, I'm not very clear about how libvirt will interact with the whole infrastructure...]
[PATCH v4 1/3] mmc: sdhci: add adma_table_cnt member to struct sdhci_host
This patch adds adma_table_cnt member to struct sdhci_host to give more
flexibility to drivers to control the ADMA table count.
Default value of adma_table_cnt is set to (SDHCI_MAX_SEGS * 2 + 1).
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host/sdhci.c | 17 +
drivers/mmc/host/sdhci.h | 3 +++
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 1b3fbd9bd5c5..52ccf4644384 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -3322,6 +3322,13 @@ struct sdhci_host *sdhci_alloc_host(struct device *dev,
host->sdma_boundary = SDHCI_DEFAULT_BOUNDARY_ARG;
+ /*
+* The DMA table descriptor count is calculated as the maximum
+* number of segments times 2, to allow for an alignment
+* descriptor for each segment, plus 1 for a nop end descriptor.
+*/
+ host->adma_table_cnt = SDHCI_MAX_SEGS * 2 + 1;
+
return host;
}
@@ -3567,18 +3574,12 @@ int sdhci_setup_host(struct sdhci_host *host)
dma_addr_t dma;
void *buf;
- /*
-* The DMA descriptor table size is calculated as the maximum
-* number of segments times 2, to allow for an alignment
-* descriptor for each segment, plus 1 for a nop end descriptor,
-* all multipled by the descriptor size.
-*/
if (host->flags & SDHCI_USE_64_BIT_DMA) {
- host->adma_table_sz = (SDHCI_MAX_SEGS * 2 + 1) *
+ host->adma_table_sz = host->adma_table_cnt *
SDHCI_ADMA2_64_DESC_SZ;
host->desc_sz = SDHCI_ADMA2_64_DESC_SZ;
} else {
- host->adma_table_sz = (SDHCI_MAX_SEGS * 2 + 1) *
+ host->adma_table_sz = host->adma_table_cnt *
SDHCI_ADMA2_32_DESC_SZ;
host->desc_sz = SDHCI_ADMA2_32_DESC_SZ;
}
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index f0bd36ce3817..25bddd21de31 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -563,6 +563,9 @@ struct sdhci_host {
/* Host SDMA buffer boundary. */
u32 sdma_boundary;
+ /* Host ADMA table count */
+ u32 adma_table_cnt;
+
u64 data_timeout;
unsigned long private[0] cacheline_aligned;
--
2.18.0
[PATCH v4 1/3] mmc: sdhci: add adma_table_cnt member to struct sdhci_host
This patch adds adma_table_cnt member to struct sdhci_host to give more
flexibility to drivers to control the ADMA table count.
Default value of adma_table_cnt is set to (SDHCI_MAX_SEGS * 2 + 1).
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host/sdhci.c | 17 +
drivers/mmc/host/sdhci.h | 3 +++
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 1b3fbd9bd5c5..52ccf4644384 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -3322,6 +3322,13 @@ struct sdhci_host *sdhci_alloc_host(struct device *dev,
host->sdma_boundary = SDHCI_DEFAULT_BOUNDARY_ARG;
+ /*
+* The DMA table descriptor count is calculated as the maximum
+* number of segments times 2, to allow for an alignment
+* descriptor for each segment, plus 1 for a nop end descriptor.
+*/
+ host->adma_table_cnt = SDHCI_MAX_SEGS * 2 + 1;
+
return host;
}
@@ -3567,18 +3574,12 @@ int sdhci_setup_host(struct sdhci_host *host)
dma_addr_t dma;
void *buf;
- /*
-* The DMA descriptor table size is calculated as the maximum
-* number of segments times 2, to allow for an alignment
-* descriptor for each segment, plus 1 for a nop end descriptor,
-* all multipled by the descriptor size.
-*/
if (host->flags & SDHCI_USE_64_BIT_DMA) {
- host->adma_table_sz = (SDHCI_MAX_SEGS * 2 + 1) *
+ host->adma_table_sz = host->adma_table_cnt *
SDHCI_ADMA2_64_DESC_SZ;
host->desc_sz = SDHCI_ADMA2_64_DESC_SZ;
} else {
- host->adma_table_sz = (SDHCI_MAX_SEGS * 2 + 1) *
+ host->adma_table_sz = host->adma_table_cnt *
SDHCI_ADMA2_32_DESC_SZ;
host->desc_sz = SDHCI_ADMA2_32_DESC_SZ;
}
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index f0bd36ce3817..25bddd21de31 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -563,6 +563,9 @@ struct sdhci_host {
/* Host SDMA buffer boundary. */
u32 sdma_boundary;
+ /* Host ADMA table count */
+ u32 adma_table_cnt;
+
u64 data_timeout;
unsigned long private[0] cacheline_aligned;
--
2.18.0
[PATCH v4 3/3] mmc: sdhci-of-dwcmshc: solve 128MB DMA boundary limitation
When using DMA, if the DMA addr spans 128MB boundary, we have to split
the DMA transfer into two so that each one doesn't exceed the boundary.
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host/sdhci-of-dwcmshc.c | 39 +
1 file changed, 39 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-dwcmshc.c
b/drivers/mmc/host/sdhci-of-dwcmshc.c
index 1b7cd144fb01..df0a3aeabe19 100644
--- a/drivers/mmc/host/sdhci-of-dwcmshc.c
+++ b/drivers/mmc/host/sdhci-of-dwcmshc.c
@@ -8,21 +8,48 @@
*/
#include
+#include
#include
#include
+#include
#include "sdhci-pltfm.h"
+#define BOUNDARY_OK(addr, len) \
+ ((addr | (SZ_128M - 1)) == ((addr + len - 1) | (SZ_128M - 1)))
+
struct dwcmshc_priv {
struct clk *bus_clk;
};
+/*
+ * If DMA addr spans 128MB boundary, we split the DMA transfer into two
+ * so that the DMA transfer doesn't exceed the boundary.
+ */
+static void dwcmshc_adma_write_desc(struct sdhci_host *host, void **desc,
+ dma_addr_t addr, int len, unsigned int cmd)
+{
+ int tmplen, offset;
+
+ if (likely(!len || BOUNDARY_OK(addr, len)))
+ sdhci_adma_write_desc(host, desc, addr, len, cmd);
+
+ offset = addr & (SZ_128M - 1);
+ tmplen = SZ_128M - offset;
+ sdhci_adma_write_desc(host, desc, addr, tmplen, cmd);
+
+ addr += tmplen;
+ len -= tmplen;
+ sdhci_adma_write_desc(host, desc, addr, len, cmd);
+}
+
static const struct sdhci_ops sdhci_dwcmshc_ops = {
.set_clock = sdhci_set_clock,
.set_bus_width = sdhci_set_bus_width,
.set_uhs_signaling = sdhci_set_uhs_signaling,
.get_max_clock = sdhci_pltfm_clk_get_max_clock,
.reset = sdhci_reset,
+ .adma_write_desc= dwcmshc_adma_write_desc,
};
static const struct sdhci_pltfm_data sdhci_dwcmshc_pdata = {
@@ -36,12 +63,24 @@ static int dwcmshc_probe(struct platform_device *pdev)
struct sdhci_host *host;
struct dwcmshc_priv *priv;
int err;
+ u32 extra;
host = sdhci_pltfm_init(pdev, _dwcmshc_pdata,
sizeof(struct dwcmshc_priv));
if (IS_ERR(host))
return PTR_ERR(host);
+ /*
+* The DMA table descriptor count is calculated as the maximum
+* number of segments times 2, to allow for an alignment
+* descriptor for each segment, plus 1 for a nop end descriptor,
+* plus extra number for cross 128M boundary handling.
+*/
+ extra = DIV_ROUND_UP(totalram_pages, SZ_128M / PAGE_SIZE);
+ if (extra > SDHCI_MAX_SEGS)
+ extra = SDHCI_MAX_SEGS;
+ host->adma_table_cnt = SDHCI_MAX_SEGS * 2 + 1 + extra;
+
pltfm_host = sdhci_priv(host);
priv = sdhci_pltfm_priv(pltfm_host);
--
2.18.0
[PATCH v4 3/3] mmc: sdhci-of-dwcmshc: solve 128MB DMA boundary limitation
When using DMA, if the DMA addr spans 128MB boundary, we have to split
the DMA transfer into two so that each one doesn't exceed the boundary.
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host/sdhci-of-dwcmshc.c | 39 +
1 file changed, 39 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-dwcmshc.c
b/drivers/mmc/host/sdhci-of-dwcmshc.c
index 1b7cd144fb01..df0a3aeabe19 100644
--- a/drivers/mmc/host/sdhci-of-dwcmshc.c
+++ b/drivers/mmc/host/sdhci-of-dwcmshc.c
@@ -8,21 +8,48 @@
*/
#include
+#include
#include
#include
+#include
#include "sdhci-pltfm.h"
+#define BOUNDARY_OK(addr, len) \
+ ((addr | (SZ_128M - 1)) == ((addr + len - 1) | (SZ_128M - 1)))
+
struct dwcmshc_priv {
struct clk *bus_clk;
};
+/*
+ * If DMA addr spans 128MB boundary, we split the DMA transfer into two
+ * so that the DMA transfer doesn't exceed the boundary.
+ */
+static void dwcmshc_adma_write_desc(struct sdhci_host *host, void **desc,
+ dma_addr_t addr, int len, unsigned int cmd)
+{
+ int tmplen, offset;
+
+ if (likely(!len || BOUNDARY_OK(addr, len)))
+ sdhci_adma_write_desc(host, desc, addr, len, cmd);
+
+ offset = addr & (SZ_128M - 1);
+ tmplen = SZ_128M - offset;
+ sdhci_adma_write_desc(host, desc, addr, tmplen, cmd);
+
+ addr += tmplen;
+ len -= tmplen;
+ sdhci_adma_write_desc(host, desc, addr, len, cmd);
+}
+
static const struct sdhci_ops sdhci_dwcmshc_ops = {
.set_clock = sdhci_set_clock,
.set_bus_width = sdhci_set_bus_width,
.set_uhs_signaling = sdhci_set_uhs_signaling,
.get_max_clock = sdhci_pltfm_clk_get_max_clock,
.reset = sdhci_reset,
+ .adma_write_desc= dwcmshc_adma_write_desc,
};
static const struct sdhci_pltfm_data sdhci_dwcmshc_pdata = {
@@ -36,12 +63,24 @@ static int dwcmshc_probe(struct platform_device *pdev)
struct sdhci_host *host;
struct dwcmshc_priv *priv;
int err;
+ u32 extra;
host = sdhci_pltfm_init(pdev, _dwcmshc_pdata,
sizeof(struct dwcmshc_priv));
if (IS_ERR(host))
return PTR_ERR(host);
+ /*
+* The DMA table descriptor count is calculated as the maximum
+* number of segments times 2, to allow for an alignment
+* descriptor for each segment, plus 1 for a nop end descriptor,
+* plus extra number for cross 128M boundary handling.
+*/
+ extra = DIV_ROUND_UP(totalram_pages, SZ_128M / PAGE_SIZE);
+ if (extra > SDHCI_MAX_SEGS)
+ extra = SDHCI_MAX_SEGS;
+ host->adma_table_cnt = SDHCI_MAX_SEGS * 2 + 1 + extra;
+
pltfm_host = sdhci_priv(host);
priv = sdhci_pltfm_priv(pltfm_host);
--
2.18.0
[GIT PULL] sound fixes for 4.19-rc1
Linus,
please pull sound fixes for v4.19-rc1 from:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
tags/sound-fix-4.19-rc1
The topmost commit is 8a328ac1f9ebfc7621f76bbb27aa0382cc5b393d
sound fixes for 4.19-rc1
no surprises here: a regression fix for virmidi code refactoring,
three fixes for the new AC97 bus compat and runtime PM, and a usual
HD-audio quirk.
Kailang Yang (1):
ALSA: hda/realtek - Fix HP Headset Mic can't record
Lihua Yao (3):
ALSA: ac97: fix device initialization in the compat layer
ALSA: ac97: fix check of pm_runtime_get_sync failure
ALSA: ac97: fix unbalanced pm_runtime_enable
Takashi Iwai (1):
ALSA: seq: virmidi: Fix discarding the unsubscribed output
---
sound/ac97/bus.c | 4 +++-
sound/ac97/snd_ac97_compat.c | 19 +--
sound/core/seq/seq_virmidi.c | 5 +++--
sound/pci/hda/patch_realtek.c | 18 +-
4 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/sound/ac97/bus.c b/sound/ac97/bus.c
index 7a0dfca03a57..9f0c480489ef 100644
--- a/sound/ac97/bus.c
+++ b/sound/ac97/bus.c
@@ -529,7 +529,7 @@ static int ac97_bus_remove(struct device *dev)
int ret;
ret = pm_runtime_get_sync(dev);
- if (ret)
+ if (ret < 0)
return ret;
ret = adrv->remove(adev);
@@ -537,6 +537,8 @@ static int ac97_bus_remove(struct device *dev)
if (ret == 0)
ac97_put_disable_clk(adev);
+ pm_runtime_disable(dev);
+
return ret;
}
diff --git a/sound/ac97/snd_ac97_compat.c b/sound/ac97/snd_ac97_compat.c
index 61544e0d8de4..8bab44f74bb8 100644
--- a/sound/ac97/snd_ac97_compat.c
+++ b/sound/ac97/snd_ac97_compat.c
@@ -15,6 +15,11 @@
#include "ac97_core.h"
+static void compat_ac97_release(struct device *dev)
+{
+ kfree(to_ac97_t(dev));
+}
+
static void compat_ac97_reset(struct snd_ac97 *ac97)
{
struct ac97_codec_device *adev = to_ac97_device(ac97->private_data);
@@ -65,21 +70,31 @@ static struct snd_ac97_bus compat_soc_ac97_bus = {
struct snd_ac97 *snd_ac97_compat_alloc(struct ac97_codec_device *adev)
{
struct snd_ac97 *ac97;
+ int ret;
ac97 = kzalloc(sizeof(struct snd_ac97), GFP_KERNEL);
if (ac97 == NULL)
return ERR_PTR(-ENOMEM);
- ac97->dev = adev->dev;
ac97->private_data = adev;
ac97->bus = _soc_ac97_bus;
+
+ ac97->dev.parent = >dev;
+ ac97->dev.release = compat_ac97_release;
+ dev_set_name(>dev, "%s-compat", dev_name(>dev));
+ ret = device_register(>dev);
+ if (ret) {
+ put_device(>dev);
+ return ERR_PTR(ret);
+ }
+
return ac97;
}
EXPORT_SYMBOL_GPL(snd_ac97_compat_alloc);
void snd_ac97_compat_release(struct snd_ac97 *ac97)
{
- kfree(ac97);
+ device_unregister(>dev);
}
EXPORT_SYMBOL_GPL(snd_ac97_compat_release);
diff --git a/sound/core/seq/seq_virmidi.c b/sound/core/seq/seq_virmidi.c
index a2f1c6b58693..cb988efd1ed0 100644
--- a/sound/core/seq/seq_virmidi.c
+++ b/sound/core/seq/seq_virmidi.c
@@ -149,8 +149,9 @@ static void snd_vmidi_output_work(struct work_struct *work)
/* discard the outputs in dispatch mode unless subscribed */
if (vmidi->seq_mode == SNDRV_VIRMIDI_SEQ_DISPATCH &&
!(vmidi->rdev->flags & SNDRV_VIRMIDI_SUBSCRIBE)) {
- while (!snd_rawmidi_transmit_empty(substream))
- snd_rawmidi_transmit_ack(substream, 1);
+ char buf[32];
+ while (snd_rawmidi_transmit(substream, buf, sizeof(buf)) > 0)
+ ; /* ignored */
return;
}
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index b20974ef1e13..1d117f00d04d 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5494,6 +5494,7 @@ enum {
ALC255_FIXUP_DUMMY_LINEOUT_VERB,
ALC255_FIXUP_DELL_HEADSET_MIC,
ALC295_FIXUP_HP_X360,
+ ALC221_FIXUP_HP_HEADSET_MIC,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -6351,7 +6352,16 @@ static const struct hda_fixup alc269_fixups[] = {
.v.func = alc295_fixup_hp_top_speakers,
.chained = true,
.chain_id = ALC269_FIXUP_HP_MUTE_LED_MIC3
- }
+ },
+ [ALC221_FIXUP_HP_HEADSET_MIC] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x19, 0x0181313f},
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC269_FIXUP_HEADSET_MIC
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -6777,6 +6787,12 @@ static const struct hda_model_fixup
alc269_fixup_models[] = {
{0x21, 0x03211020}
[GIT PULL] sound fixes for 4.19-rc1
Linus,
please pull sound fixes for v4.19-rc1 from:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
tags/sound-fix-4.19-rc1
The topmost commit is 8a328ac1f9ebfc7621f76bbb27aa0382cc5b393d
sound fixes for 4.19-rc1
no surprises here: a regression fix for virmidi code refactoring,
three fixes for the new AC97 bus compat and runtime PM, and a usual
HD-audio quirk.
Kailang Yang (1):
ALSA: hda/realtek - Fix HP Headset Mic can't record
Lihua Yao (3):
ALSA: ac97: fix device initialization in the compat layer
ALSA: ac97: fix check of pm_runtime_get_sync failure
ALSA: ac97: fix unbalanced pm_runtime_enable
Takashi Iwai (1):
ALSA: seq: virmidi: Fix discarding the unsubscribed output
---
sound/ac97/bus.c | 4 +++-
sound/ac97/snd_ac97_compat.c | 19 +--
sound/core/seq/seq_virmidi.c | 5 +++--
sound/pci/hda/patch_realtek.c | 18 +-
4 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/sound/ac97/bus.c b/sound/ac97/bus.c
index 7a0dfca03a57..9f0c480489ef 100644
--- a/sound/ac97/bus.c
+++ b/sound/ac97/bus.c
@@ -529,7 +529,7 @@ static int ac97_bus_remove(struct device *dev)
int ret;
ret = pm_runtime_get_sync(dev);
- if (ret)
+ if (ret < 0)
return ret;
ret = adrv->remove(adev);
@@ -537,6 +537,8 @@ static int ac97_bus_remove(struct device *dev)
if (ret == 0)
ac97_put_disable_clk(adev);
+ pm_runtime_disable(dev);
+
return ret;
}
diff --git a/sound/ac97/snd_ac97_compat.c b/sound/ac97/snd_ac97_compat.c
index 61544e0d8de4..8bab44f74bb8 100644
--- a/sound/ac97/snd_ac97_compat.c
+++ b/sound/ac97/snd_ac97_compat.c
@@ -15,6 +15,11 @@
#include "ac97_core.h"
+static void compat_ac97_release(struct device *dev)
+{
+ kfree(to_ac97_t(dev));
+}
+
static void compat_ac97_reset(struct snd_ac97 *ac97)
{
struct ac97_codec_device *adev = to_ac97_device(ac97->private_data);
@@ -65,21 +70,31 @@ static struct snd_ac97_bus compat_soc_ac97_bus = {
struct snd_ac97 *snd_ac97_compat_alloc(struct ac97_codec_device *adev)
{
struct snd_ac97 *ac97;
+ int ret;
ac97 = kzalloc(sizeof(struct snd_ac97), GFP_KERNEL);
if (ac97 == NULL)
return ERR_PTR(-ENOMEM);
- ac97->dev = adev->dev;
ac97->private_data = adev;
ac97->bus = _soc_ac97_bus;
+
+ ac97->dev.parent = >dev;
+ ac97->dev.release = compat_ac97_release;
+ dev_set_name(>dev, "%s-compat", dev_name(>dev));
+ ret = device_register(>dev);
+ if (ret) {
+ put_device(>dev);
+ return ERR_PTR(ret);
+ }
+
return ac97;
}
EXPORT_SYMBOL_GPL(snd_ac97_compat_alloc);
void snd_ac97_compat_release(struct snd_ac97 *ac97)
{
- kfree(ac97);
+ device_unregister(>dev);
}
EXPORT_SYMBOL_GPL(snd_ac97_compat_release);
diff --git a/sound/core/seq/seq_virmidi.c b/sound/core/seq/seq_virmidi.c
index a2f1c6b58693..cb988efd1ed0 100644
--- a/sound/core/seq/seq_virmidi.c
+++ b/sound/core/seq/seq_virmidi.c
@@ -149,8 +149,9 @@ static void snd_vmidi_output_work(struct work_struct *work)
/* discard the outputs in dispatch mode unless subscribed */
if (vmidi->seq_mode == SNDRV_VIRMIDI_SEQ_DISPATCH &&
!(vmidi->rdev->flags & SNDRV_VIRMIDI_SUBSCRIBE)) {
- while (!snd_rawmidi_transmit_empty(substream))
- snd_rawmidi_transmit_ack(substream, 1);
+ char buf[32];
+ while (snd_rawmidi_transmit(substream, buf, sizeof(buf)) > 0)
+ ; /* ignored */
return;
}
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index b20974ef1e13..1d117f00d04d 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5494,6 +5494,7 @@ enum {
ALC255_FIXUP_DUMMY_LINEOUT_VERB,
ALC255_FIXUP_DELL_HEADSET_MIC,
ALC295_FIXUP_HP_X360,
+ ALC221_FIXUP_HP_HEADSET_MIC,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -6351,7 +6352,16 @@ static const struct hda_fixup alc269_fixups[] = {
.v.func = alc295_fixup_hp_top_speakers,
.chained = true,
.chain_id = ALC269_FIXUP_HP_MUTE_LED_MIC3
- }
+ },
+ [ALC221_FIXUP_HP_HEADSET_MIC] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x19, 0x0181313f},
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC269_FIXUP_HEADSET_MIC
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -6777,6 +6787,12 @@ static const struct hda_model_fixup
alc269_fixup_models[] = {
{0x21, 0x03211020}
[PATCH v4 2/3] mmc: sdhci: introduce adma_write_desc() hook to struct sdhci_ops
Add this hook so that it can be overridden with driver specific
implementations. We also let the original sdhci_adma_write_desc()
accept so that the function can set its new value. Then export
the function so that it could be reused by driver's specific
implementations.
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host/sdhci.c | 37 +++--
drivers/mmc/host/sdhci.h | 4
2 files changed, 27 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 52ccf4644384..eb21d2db7f05 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -554,10 +554,10 @@ static void sdhci_kunmap_atomic(void *buffer, unsigned
long *flags)
local_irq_restore(*flags);
}
-static void sdhci_adma_write_desc(struct sdhci_host *host, void *desc,
- dma_addr_t addr, int len, unsigned cmd)
+void sdhci_adma_write_desc(struct sdhci_host *host, void **desc,
+ dma_addr_t addr, int len, unsigned int cmd)
{
- struct sdhci_adma2_64_desc *dma_desc = desc;
+ struct sdhci_adma2_64_desc *dma_desc = *desc;
/* 32-bit and 64-bit descriptors have these members in same position */
dma_desc->cmd = cpu_to_le16(cmd);
@@ -566,6 +566,19 @@ static void sdhci_adma_write_desc(struct sdhci_host *host,
void *desc,
if (host->flags & SDHCI_USE_64_BIT_DMA)
dma_desc->addr_hi = cpu_to_le32((u64)addr >> 32);
+
+ *desc += host->desc_sz;
+}
+EXPORT_SYMBOL_GPL(sdhci_adma_write_desc);
+
+static inline void __sdhci_adma_write_desc(struct sdhci_host *host,
+ void **desc, dma_addr_t addr,
+ int len, unsigned int cmd)
+{
+ if (host->ops->adma_write_desc)
+ host->ops->adma_write_desc(host, desc, addr, len, cmd);
+
+ sdhci_adma_write_desc(host, desc, addr, len, cmd);
}
static void sdhci_adma_mark_end(void *desc)
@@ -618,28 +631,24 @@ static void sdhci_adma_table_pre(struct sdhci_host *host,
}
/* tran, valid */
- sdhci_adma_write_desc(host, desc, align_addr, offset,
- ADMA2_TRAN_VALID);
+ __sdhci_adma_write_desc(host, , align_addr,
+ offset, ADMA2_TRAN_VALID);
BUG_ON(offset > 65536);
align += SDHCI_ADMA2_ALIGN;
align_addr += SDHCI_ADMA2_ALIGN;
- desc += host->desc_sz;
-
addr += offset;
len -= offset;
}
BUG_ON(len > 65536);
- if (len) {
- /* tran, valid */
- sdhci_adma_write_desc(host, desc, addr, len,
- ADMA2_TRAN_VALID);
- desc += host->desc_sz;
- }
+ /* tran, valid */
+ if (len)
+ __sdhci_adma_write_desc(host, , addr, len,
+ ADMA2_TRAN_VALID);
/*
* If this triggers then we have a calculation bug
@@ -656,7 +665,7 @@ static void sdhci_adma_table_pre(struct sdhci_host *host,
}
} else {
/* Add a terminating entry - nop, end, valid */
- sdhci_adma_write_desc(host, desc, 0, 0, ADMA2_NOP_END_VALID);
+ __sdhci_adma_write_desc(host, , 0, 0, ADMA2_NOP_END_VALID);
}
}
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 25bddd21de31..2115416f973a 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -606,6 +606,8 @@ struct sdhci_ops {
void(*adma_workaround)(struct sdhci_host *host, u32 intmask);
void(*card_event)(struct sdhci_host *host);
void(*voltage_switch)(struct sdhci_host *host);
+ void(*adma_write_desc)(struct sdhci_host *host, void **desc,
+ dma_addr_t addr, int len, unsigned int cmd);
};
#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
@@ -736,6 +738,8 @@ void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios
*ios);
int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
struct mmc_ios *ios);
void sdhci_enable_sdio_irq(struct mmc_host *mmc, int enable);
+void sdhci_adma_write_desc(struct sdhci_host *host, void **desc,
+ dma_addr_t addr, int len, unsigned int cmd);
#ifdef CONFIG_PM
int sdhci_suspend_host(struct sdhci_host *host);
--
2.18.0
[PATCH v4 2/3] mmc: sdhci: introduce adma_write_desc() hook to struct sdhci_ops
Add this hook so that it can be overridden with driver specific
implementations. We also let the original sdhci_adma_write_desc()
accept so that the function can set its new value. Then export
the function so that it could be reused by driver's specific
implementations.
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host/sdhci.c | 37 +++--
drivers/mmc/host/sdhci.h | 4
2 files changed, 27 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 52ccf4644384..eb21d2db7f05 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -554,10 +554,10 @@ static void sdhci_kunmap_atomic(void *buffer, unsigned
long *flags)
local_irq_restore(*flags);
}
-static void sdhci_adma_write_desc(struct sdhci_host *host, void *desc,
- dma_addr_t addr, int len, unsigned cmd)
+void sdhci_adma_write_desc(struct sdhci_host *host, void **desc,
+ dma_addr_t addr, int len, unsigned int cmd)
{
- struct sdhci_adma2_64_desc *dma_desc = desc;
+ struct sdhci_adma2_64_desc *dma_desc = *desc;
/* 32-bit and 64-bit descriptors have these members in same position */
dma_desc->cmd = cpu_to_le16(cmd);
@@ -566,6 +566,19 @@ static void sdhci_adma_write_desc(struct sdhci_host *host,
void *desc,
if (host->flags & SDHCI_USE_64_BIT_DMA)
dma_desc->addr_hi = cpu_to_le32((u64)addr >> 32);
+
+ *desc += host->desc_sz;
+}
+EXPORT_SYMBOL_GPL(sdhci_adma_write_desc);
+
+static inline void __sdhci_adma_write_desc(struct sdhci_host *host,
+ void **desc, dma_addr_t addr,
+ int len, unsigned int cmd)
+{
+ if (host->ops->adma_write_desc)
+ host->ops->adma_write_desc(host, desc, addr, len, cmd);
+
+ sdhci_adma_write_desc(host, desc, addr, len, cmd);
}
static void sdhci_adma_mark_end(void *desc)
@@ -618,28 +631,24 @@ static void sdhci_adma_table_pre(struct sdhci_host *host,
}
/* tran, valid */
- sdhci_adma_write_desc(host, desc, align_addr, offset,
- ADMA2_TRAN_VALID);
+ __sdhci_adma_write_desc(host, , align_addr,
+ offset, ADMA2_TRAN_VALID);
BUG_ON(offset > 65536);
align += SDHCI_ADMA2_ALIGN;
align_addr += SDHCI_ADMA2_ALIGN;
- desc += host->desc_sz;
-
addr += offset;
len -= offset;
}
BUG_ON(len > 65536);
- if (len) {
- /* tran, valid */
- sdhci_adma_write_desc(host, desc, addr, len,
- ADMA2_TRAN_VALID);
- desc += host->desc_sz;
- }
+ /* tran, valid */
+ if (len)
+ __sdhci_adma_write_desc(host, , addr, len,
+ ADMA2_TRAN_VALID);
/*
* If this triggers then we have a calculation bug
@@ -656,7 +665,7 @@ static void sdhci_adma_table_pre(struct sdhci_host *host,
}
} else {
/* Add a terminating entry - nop, end, valid */
- sdhci_adma_write_desc(host, desc, 0, 0, ADMA2_NOP_END_VALID);
+ __sdhci_adma_write_desc(host, , 0, 0, ADMA2_NOP_END_VALID);
}
}
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 25bddd21de31..2115416f973a 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -606,6 +606,8 @@ struct sdhci_ops {
void(*adma_workaround)(struct sdhci_host *host, u32 intmask);
void(*card_event)(struct sdhci_host *host);
void(*voltage_switch)(struct sdhci_host *host);
+ void(*adma_write_desc)(struct sdhci_host *host, void **desc,
+ dma_addr_t addr, int len, unsigned int cmd);
};
#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
@@ -736,6 +738,8 @@ void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios
*ios);
int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
struct mmc_ios *ios);
void sdhci_enable_sdio_irq(struct mmc_host *mmc, int enable);
+void sdhci_adma_write_desc(struct sdhci_host *host, void **desc,
+ dma_addr_t addr, int len, unsigned int cmd);
#ifdef CONFIG_PM
int sdhci_suspend_host(struct sdhci_host *host);
--
2.18.0
[PATCH v4 0/3] solve SDHCI DWC MSHC 128MB DMA boundary limitation
When using DMA, if the DMA addr spans 128MB boundary, we have to split the DMA transfer into two so that each one doesn't exceed the boundary. patch1 adds adma_table_num to struct sdhci_host so that driver can control the ADMA table number. patch2 introduces adma_write_desc() hook to struct sdhci_ops so that driver can override it. patch3 finally solves the 128MB boundary limitation. since v3: - s/adma_table_num/adma_table_cnt - add comment to adma_table_cnt - make the exported function name without the _ - let sdhci_adma_write_desc() accept param and set the new desc value since v2: - make use of "likely" to check (!len || BOUNDARY_OK(addr, len)) - explictly include for SZ_128M since v1: - fix BOUNDARY_OK macro if addr+len is aligned to 128MB - use DIV_ROUND_UP to cal extra desc num - fix !len for dwcmshc_adma_write_desc() Jisheng Zhang (3): mmc: sdhci: add adma_table_cnt member to struct sdhci_host mmc: sdhci: introduce adma_write_desc() hook to struct sdhci_ops mmc: sdhci-of-dwcmshc: solve 128MB DMA boundary limitation drivers/mmc/host/sdhci-of-dwcmshc.c | 39 + drivers/mmc/host/sdhci.c| 54 + drivers/mmc/host/sdhci.h| 7 3 files changed, 78 insertions(+), 22 deletions(-) -- 2.18.0
[PATCH v4 0/3] solve SDHCI DWC MSHC 128MB DMA boundary limitation
When using DMA, if the DMA addr spans 128MB boundary, we have to split the DMA transfer into two so that each one doesn't exceed the boundary. patch1 adds adma_table_num to struct sdhci_host so that driver can control the ADMA table number. patch2 introduces adma_write_desc() hook to struct sdhci_ops so that driver can override it. patch3 finally solves the 128MB boundary limitation. since v3: - s/adma_table_num/adma_table_cnt - add comment to adma_table_cnt - make the exported function name without the _ - let sdhci_adma_write_desc() accept param and set the new desc value since v2: - make use of "likely" to check (!len || BOUNDARY_OK(addr, len)) - explictly include for SZ_128M since v1: - fix BOUNDARY_OK macro if addr+len is aligned to 128MB - use DIV_ROUND_UP to cal extra desc num - fix !len for dwcmshc_adma_write_desc() Jisheng Zhang (3): mmc: sdhci: add adma_table_cnt member to struct sdhci_host mmc: sdhci: introduce adma_write_desc() hook to struct sdhci_ops mmc: sdhci-of-dwcmshc: solve 128MB DMA boundary limitation drivers/mmc/host/sdhci-of-dwcmshc.c | 39 + drivers/mmc/host/sdhci.c| 54 + drivers/mmc/host/sdhci.h| 7 3 files changed, 78 insertions(+), 22 deletions(-) -- 2.18.0
Re: KASAN: null-ptr-deref Write in binder_update_page_range
> Could you test this patch? I found that bug a month ago but didn't submit > yet. I don't have a reproducer now. I manually analzed a root cause of the crash using a fuzzer's log. The log reported a race on 'alloc->vma'. Because I don't have a reproducer, I can't test the patch. I'm sorry.
Re: KASAN: null-ptr-deref Write in binder_update_page_range
> Could you test this patch? I found that bug a month ago but didn't submit > yet. I don't have a reproducer now. I manually analzed a root cause of the crash using a fuzzer's log. The log reported a race on 'alloc->vma'. Because I don't have a reproducer, I can't test the patch. I'm sorry.
Re: [PATCH v9 21/22] KVM: s390: CPU model support for AP virtualization
On 08/23/2018 09:44 AM, David Hildenbrand wrote:
On 22.08.2018 22:16, Tony Krowiak wrote:
On 08/22/2018 07:24 AM, David Hildenbrand wrote:
On 22.08.2018 13:19, David Hildenbrand wrote:
On 13.08.2018 23:48, Tony Krowiak wrote:
From: Tony Krowiak
Introduces a new CPU model feature and two CPU model
facilities to support AP virtualization for KVM guests.
CPU model feature:
The KVM_S390_VM_CPU_FEAT_AP feature indicates that
AP instructions are available on the guest. This
feature will be enabled by the kernel only if the AP
instructions are installed on the linux host. This feature
must be specifically turned on for the KVM guest from
userspace to use the VFIO AP device driver for guest
access to AP devices.
CPU model facilities:
1. AP Query Configuration Information (QCI) facility is installed.
This is indicated by setting facilities bit 12 for
the guest. The kernel will not enable this facility
for the guest if it is not set on the host.
If this facility is not set for the KVM guest, then only
APQNs with an APQI less than 16 will be used by a Linux
guest regardless of the matrix configuration for the virtual
machine. This is a limitation of the Linux AP bus.
2. AP Facilities Test facility (APFT) is installed.
This is indicated by setting facilities bit 15 for
the guest. The kernel will not enable this facility for
the guest if it is not set on the host.
If this facility is not set for the KVM guest, then no
AP devices will be available to the guest regardless of
the guest's matrix configuration for the virtual
machine. This is a limitation of the Linux AP bus.
Signed-off-by: Tony Krowiak
Reviewed-by: Christian Borntraeger
Reviewed-by: Halil Pasic
Tested-by: Michael Mueller
Tested-by: Farhan Ali
Signed-off-by: Christian Borntraeger
---
arch/s390/kvm/kvm-s390.c |5 +
arch/s390/tools/gen_facilities.c |2 ++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 1e8cb67..d5e04d2 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -367,6 +367,11 @@ static void kvm_s390_cpu_feat_init(void)
if (MACHINE_HAS_ESOP)
allow_cpu_feat(KVM_S390_VM_CPU_FEAT_ESOP);
+
+ /* Check if AP instructions installed on host */
+ if (ap_instructions_available())
+ allow_cpu_feat(KVM_S390_VM_CPU_FEAT_AP);
+
/*
* We need SIE support, ESOP (PROT_READ protection for gmap_shadow),
* 64bit SCAO (SCA passthrough) and IDTE (for gmap_shadow unshadowing).
diff --git a/arch/s390/tools/gen_facilities.c b/arch/s390/tools/gen_facilities.c
index 90a8c9e..a52290b 100644
--- a/arch/s390/tools/gen_facilities.c
+++ b/arch/s390/tools/gen_facilities.c
@@ -106,6 +106,8 @@ struct facility_def {
.name = "FACILITIES_KVM_CPUMODEL",
.bits = (int[]){
+ 12, /* AP Query Configuration Information */
+ 15, /* AP Facilities Test */
-1 /* END */
}
},
I really wonder if we should also export the APXA facility.
We can probe and allow that CPU feature. However, we cannot disable it
(as of now).
We have other CPU features where it is the same case (basically all
subfunctions). See kvm_s390_get_processor_subfunc(). We probe them and
export them, but support to disable them has never been implemented.
On a high level, we could then e.g. deny to start a QEMU guest if APXA
is available but has been disabled. (until we know that disabling it
actually works - if ever).
This helps to catch nasty migration bugs (e.g. APXA suddenly
disappearing). Although unlikely, definitely possible.
Are there any other AP related facilities that the guest can from now on
probe that should also become part of the CPU model?
To be more precise, shouldn't PQAP(QCI) be handled just like other
subfunctions? (I remember it should)
When you suggest PQAP(QCI) be handled like other subfunctions, are you
suggesting that there should be a field in struct kvm_s390_vm_cpu_subfunc
with a bit indicating the QCI subfunction is available? The availability
of the QCI subfunction of the PQAP instruction is determined by facilities
bit 12. Is it not enough to export facilities bit 12?
The feature block (128 bit) from PQAP(QCI) should be passed through a
subfunction block to QEMU.
I'm confused, which 128 bit?
So it is about passing e.g. APXA availability, not QCI itself. (as you
correctly said, that is stfl 12)
Re: [PATCH v9 21/22] KVM: s390: CPU model support for AP virtualization
On 08/23/2018 09:44 AM, David Hildenbrand wrote:
On 22.08.2018 22:16, Tony Krowiak wrote:
On 08/22/2018 07:24 AM, David Hildenbrand wrote:
On 22.08.2018 13:19, David Hildenbrand wrote:
On 13.08.2018 23:48, Tony Krowiak wrote:
From: Tony Krowiak
Introduces a new CPU model feature and two CPU model
facilities to support AP virtualization for KVM guests.
CPU model feature:
The KVM_S390_VM_CPU_FEAT_AP feature indicates that
AP instructions are available on the guest. This
feature will be enabled by the kernel only if the AP
instructions are installed on the linux host. This feature
must be specifically turned on for the KVM guest from
userspace to use the VFIO AP device driver for guest
access to AP devices.
CPU model facilities:
1. AP Query Configuration Information (QCI) facility is installed.
This is indicated by setting facilities bit 12 for
the guest. The kernel will not enable this facility
for the guest if it is not set on the host.
If this facility is not set for the KVM guest, then only
APQNs with an APQI less than 16 will be used by a Linux
guest regardless of the matrix configuration for the virtual
machine. This is a limitation of the Linux AP bus.
2. AP Facilities Test facility (APFT) is installed.
This is indicated by setting facilities bit 15 for
the guest. The kernel will not enable this facility for
the guest if it is not set on the host.
If this facility is not set for the KVM guest, then no
AP devices will be available to the guest regardless of
the guest's matrix configuration for the virtual
machine. This is a limitation of the Linux AP bus.
Signed-off-by: Tony Krowiak
Reviewed-by: Christian Borntraeger
Reviewed-by: Halil Pasic
Tested-by: Michael Mueller
Tested-by: Farhan Ali
Signed-off-by: Christian Borntraeger
---
arch/s390/kvm/kvm-s390.c |5 +
arch/s390/tools/gen_facilities.c |2 ++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 1e8cb67..d5e04d2 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -367,6 +367,11 @@ static void kvm_s390_cpu_feat_init(void)
if (MACHINE_HAS_ESOP)
allow_cpu_feat(KVM_S390_VM_CPU_FEAT_ESOP);
+
+ /* Check if AP instructions installed on host */
+ if (ap_instructions_available())
+ allow_cpu_feat(KVM_S390_VM_CPU_FEAT_AP);
+
/*
* We need SIE support, ESOP (PROT_READ protection for gmap_shadow),
* 64bit SCAO (SCA passthrough) and IDTE (for gmap_shadow unshadowing).
diff --git a/arch/s390/tools/gen_facilities.c b/arch/s390/tools/gen_facilities.c
index 90a8c9e..a52290b 100644
--- a/arch/s390/tools/gen_facilities.c
+++ b/arch/s390/tools/gen_facilities.c
@@ -106,6 +106,8 @@ struct facility_def {
.name = "FACILITIES_KVM_CPUMODEL",
.bits = (int[]){
+ 12, /* AP Query Configuration Information */
+ 15, /* AP Facilities Test */
-1 /* END */
}
},
I really wonder if we should also export the APXA facility.
We can probe and allow that CPU feature. However, we cannot disable it
(as of now).
We have other CPU features where it is the same case (basically all
subfunctions). See kvm_s390_get_processor_subfunc(). We probe them and
export them, but support to disable them has never been implemented.
On a high level, we could then e.g. deny to start a QEMU guest if APXA
is available but has been disabled. (until we know that disabling it
actually works - if ever).
This helps to catch nasty migration bugs (e.g. APXA suddenly
disappearing). Although unlikely, definitely possible.
Are there any other AP related facilities that the guest can from now on
probe that should also become part of the CPU model?
To be more precise, shouldn't PQAP(QCI) be handled just like other
subfunctions? (I remember it should)
When you suggest PQAP(QCI) be handled like other subfunctions, are you
suggesting that there should be a field in struct kvm_s390_vm_cpu_subfunc
with a bit indicating the QCI subfunction is available? The availability
of the QCI subfunction of the PQAP instruction is determined by facilities
bit 12. Is it not enough to export facilities bit 12?
The feature block (128 bit) from PQAP(QCI) should be passed through a
subfunction block to QEMU.
I'm confused, which 128 bit?
So it is about passing e.g. APXA availability, not QCI itself. (as you
correctly said, that is stfl 12)
Re: [PATCH] ASoC: max98373: Added 10ms delay after amp software reset
On Wed, Aug 22, 2018 at 05:31:04PM -0700, Dmitry Torokhov wrote: > On Wed, Aug 22, 2018 at 5:21 PM Ryan Lee > wrote: > > + mdelay(10); > Is it really necessary for the CPU to spin for 10msec here? > usleep_range() would be better solution. Or msleep() for that matter, it's not going ot be the end of the world if we delay a bit too long. signature.asc Description: PGP signature
Re: [PATCH] ASoC: max98373: Added 10ms delay after amp software reset
On Wed, Aug 22, 2018 at 05:31:04PM -0700, Dmitry Torokhov wrote: > On Wed, Aug 22, 2018 at 5:21 PM Ryan Lee > wrote: > > + mdelay(10); > Is it really necessary for the CPU to spin for 10msec here? > usleep_range() would be better solution. Or msleep() for that matter, it's not going ot be the end of the world if we delay a bit too long. signature.asc Description: PGP signature
Re: microblaze-linux-ld: cannot find sound/soc/jz4740/jz4740-i2s.o: No such file or directory
Hi. 2018-08-23 7:40 GMT+09:00 kbuild test robot : > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 899fbc33fd775b9dfa363db28f322272920a2196 > commit: 0fbe9a245c60bedebb6dd329966f463bb724450a microblaze: add endianness > options to LDFLAGS instead of LD > date: 4 weeks ago > config: microblaze-allmodconfig (attached as .config) > compiler: microblaze-linux-gcc (GCC) 8.1.0 > reproduce: > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > git checkout 0fbe9a245c60bedebb6dd329966f463bb724450a > # save the attached .config to linux build tree > GCC_VERSION=8.1.0 make.cross ARCH=microblaze > > All errors (new ones prefixed by >>): > >>> microblaze-linux-ld: cannot find sound/soc/jz4740/jz4740-i2s.o: No such >>> file or directory > -- >>> microblaze-linux-ld: cannot find sound/soc/jz4740/qi_lb60.o: No such file >>> or directory > -- >>> microblaze-linux-ld: cannot find sound/soc/kirkwood/kirkwood-dma.o: No such >>> file or directory >>> microblaze-linux-ld: cannot find sound/soc/kirkwood/kirkwood-i2s.o: No such >>> file or directory > -- >>> microblaze-linux-ld: cannot find sound/soc/kirkwood/armada-370-db.o: No >>> such file or directory > -- >>> microblaze-linux-ld: cannot find drivers/media/usb/uvc/uvc_driver.o: No >>> such file or directory >>> microblaze-linux-ld: cannot find drivers/media/usb/uvc/uvc_v4l2.o: No such >>> file or directory > -- >>> microblaze-linux-ld: cannot find drivers/gpu/drm/vc4/vc4_fence.o: No such >>> file or directory >>> microblaze-linux-ld: cannot find drivers/gpu/drm/vc4/vc4_gem.o: No such >>> file or directory > -- >>> microblaze-linux-ld: cannot find drivers/media/pci/cobalt/cobalt-driver.o: >>> No such file or directory >>> microblaze-linux-ld: cannot find drivers/media/pci/cobalt/cobalt-v4l2.o: No >>> such file or directory >>> microblaze-linux-ld: cannot find drivers/media/pci/cobalt/cobalt-flash.o: >>> No such file or directory > > --- > 0-DAY kernel test infrastructureOpen Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation Thanks for the report. I will fix this. diff --git a/scripts/Makefile.build b/scripts/Makefile.build index 93b8e24..f5d7612 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -220,7 +220,7 @@ sub_cmd_record_mcount = set -e ; perl $(srctree)/scripts/recordmcount.pl "$(ARCH "$(if $(CONFIG_CPU_BIG_ENDIAN),big,little)" \ "$(if $(CONFIG_64BIT),64,32)" \ "$(OBJDUMP)" "$(OBJCOPY)" "$(CC) $(KBUILD_CFLAGS)" \ - "$(LD)" "$(NM)" "$(RM)" "$(MV)" \ + "$(LD) $(LDFLAGS)" "$(NM)" "$(RM)" "$(MV)" \ "$(if $(part-of-module),1,0)" "$(@)"; recordmcount_source := $(srctree)/scripts/recordmcount.pl endif # BUILD_C_RECORDMCOUNT -- Best Regards Masahiro Yamada
Re: microblaze-linux-ld: cannot find sound/soc/jz4740/jz4740-i2s.o: No such file or directory
Hi. 2018-08-23 7:40 GMT+09:00 kbuild test robot : > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 899fbc33fd775b9dfa363db28f322272920a2196 > commit: 0fbe9a245c60bedebb6dd329966f463bb724450a microblaze: add endianness > options to LDFLAGS instead of LD > date: 4 weeks ago > config: microblaze-allmodconfig (attached as .config) > compiler: microblaze-linux-gcc (GCC) 8.1.0 > reproduce: > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > git checkout 0fbe9a245c60bedebb6dd329966f463bb724450a > # save the attached .config to linux build tree > GCC_VERSION=8.1.0 make.cross ARCH=microblaze > > All errors (new ones prefixed by >>): > >>> microblaze-linux-ld: cannot find sound/soc/jz4740/jz4740-i2s.o: No such >>> file or directory > -- >>> microblaze-linux-ld: cannot find sound/soc/jz4740/qi_lb60.o: No such file >>> or directory > -- >>> microblaze-linux-ld: cannot find sound/soc/kirkwood/kirkwood-dma.o: No such >>> file or directory >>> microblaze-linux-ld: cannot find sound/soc/kirkwood/kirkwood-i2s.o: No such >>> file or directory > -- >>> microblaze-linux-ld: cannot find sound/soc/kirkwood/armada-370-db.o: No >>> such file or directory > -- >>> microblaze-linux-ld: cannot find drivers/media/usb/uvc/uvc_driver.o: No >>> such file or directory >>> microblaze-linux-ld: cannot find drivers/media/usb/uvc/uvc_v4l2.o: No such >>> file or directory > -- >>> microblaze-linux-ld: cannot find drivers/gpu/drm/vc4/vc4_fence.o: No such >>> file or directory >>> microblaze-linux-ld: cannot find drivers/gpu/drm/vc4/vc4_gem.o: No such >>> file or directory > -- >>> microblaze-linux-ld: cannot find drivers/media/pci/cobalt/cobalt-driver.o: >>> No such file or directory >>> microblaze-linux-ld: cannot find drivers/media/pci/cobalt/cobalt-v4l2.o: No >>> such file or directory >>> microblaze-linux-ld: cannot find drivers/media/pci/cobalt/cobalt-flash.o: >>> No such file or directory > > --- > 0-DAY kernel test infrastructureOpen Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation Thanks for the report. I will fix this. diff --git a/scripts/Makefile.build b/scripts/Makefile.build index 93b8e24..f5d7612 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -220,7 +220,7 @@ sub_cmd_record_mcount = set -e ; perl $(srctree)/scripts/recordmcount.pl "$(ARCH "$(if $(CONFIG_CPU_BIG_ENDIAN),big,little)" \ "$(if $(CONFIG_64BIT),64,32)" \ "$(OBJDUMP)" "$(OBJCOPY)" "$(CC) $(KBUILD_CFLAGS)" \ - "$(LD)" "$(NM)" "$(RM)" "$(MV)" \ + "$(LD) $(LDFLAGS)" "$(NM)" "$(RM)" "$(MV)" \ "$(if $(part-of-module),1,0)" "$(@)"; recordmcount_source := $(srctree)/scripts/recordmcount.pl endif # BUILD_C_RECORDMCOUNT -- Best Regards Masahiro Yamada
Re: [RFC PATCH 5/5] mm/memory_hotplug: Simplify node_states_check_changes_offline
On Wed, Aug 22, 2018 at 11:32:26AM +0200, Oscar Salvador wrote: > From: Oscar Salvador > > This patch tries to simplify node_states_check_changes_offline > and make the code more understandable by: > > - Removing the if (N_MEMORY == N_NORMAL_MEMORY) wrong statement > - Removing the if (N_MEMORY == N_HIGH_MEMORY) wrong statement > - Re-structure the code a bit > - Removing confusing comments > > Signed-off-by: Oscar Salvador I realized I made a mistake here. I was not counting the present pages correctly. I will send a new version after the merge-windows gets closed. Sorry for the noise For the sake of clarity, the patch should have been: --- diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 006a7b817724..bca11da4e11f 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -1487,23 +1487,12 @@ static void node_states_check_changes_offline(unsigned long nr_pages, enum zone_type zt, zone_last = ZONE_NORMAL; /* -* If we have HIGHMEM or movable node, node_states[N_NORMAL_MEMORY] -* contains nodes which have zones of 0...ZONE_NORMAL, -* set zone_last to ZONE_NORMAL. -* -* If we don't have HIGHMEM nor movable node, -* node_states[N_NORMAL_MEMORY] contains nodes which have zones of -* 0...ZONE_MOVABLE, set zone_last to ZONE_MOVABLE. -*/ - if (N_MEMORY == N_NORMAL_MEMORY) - zone_last = ZONE_MOVABLE; - - /* -* check whether node_states[N_NORMAL_MEMORY] will be changed. -* If the memory to be offline is in a zone of 0...zone_last, -* and it is the last present memory, 0...zone_last will -* become empty after offline , thus we can determind we will -* need to clear the node from node_states[N_NORMAL_MEMORY]. +* If the current zone is whithin (0..ZONE_NORMAL], +* check if the amount of pages that are going to be +* offlined is above or equal to the sum of the present +* pages of these zones. +* If that happens, we need to take this node out of +* node_state[N_NORMAL_MEMORY] */ for (zt = 0; zt <= zone_last; zt++) present_pages += pgdat->node_zones[zt].present_pages; @@ -1514,21 +1503,15 @@ static void node_states_check_changes_offline(unsigned long nr_pages, #ifdef CONFIG_HIGHMEM /* -* If we have movable node, node_states[N_HIGH_MEMORY] -* contains nodes which have zones of 0...ZONE_HIGHMEM, -* set zone_last to ZONE_HIGHMEM. -* -* If we don't have movable node, node_states[N_NORMAL_MEMORY] -* contains nodes which have zones of 0...ZONE_MOVABLE, -* set zone_last to ZONE_MOVABLE. +* If the current zone is whithin (0..ZONE_HIGHMEM], check if +* the amount of pages that are going to be offlined is above +* or equal to the sum of the present pages of these zones. +* If that happens, we need to take this node out of +* node_state[N_HIGH_MEMORY] */ - zone_last = ZONE_HIGHMEM; - if (N_MEMORY == N_HIGH_MEMORY) - zone_last = ZONE_MOVABLE; - - for (; zt <= zone_last; zt++) - present_pages += pgdat->node_zones[zt].present_pages; - if (zone_idx(zone) <= zone_last && nr_pages >= present_pages) + zt = ZONE_HIGHMEM; + present_pages += pgdat->node_zones[zt].present_pages; + if (zone_idx(zone) <= zt && nr_pages >= present_pages) arg->status_change_nid_high = zone_to_nid(zone); else arg->status_change_nid_high = -1; @@ -1541,18 +1524,14 @@ static void node_states_check_changes_offline(unsigned long nr_pages, #endif /* -* node_states[N_HIGH_MEMORY] contains nodes which have 0...ZONE_MOVABLE +* Count pages from ZONE_MOVABLE as well. +* If the amount of pages that are going to be offlined is above +* or equal the sum of the present pages of all zones, we need +* to remove this node from node_state[N_MEMORY] */ - zone_last = ZONE_MOVABLE; + zt = ZONE_MOVABLE; + present_pages += pgdat->node_zones[zt].present_pages; - /* -* check whether node_states[N_HIGH_MEMORY] will be changed -* If we try to offline the last present @nr_pages from the node, -* we can determind we will need to clear the node from -* node_states[N_HIGH_MEMORY]. -*/ - for (; zt <= zone_last; zt++) - present_pages += pgdat->node_zones[zt].present_pages; if (nr_pages >= present_pages) arg->status_change_nid = zone_to_nid(zone); else -- Oscar Salvador SUSE L3
Re: [RFC PATCH 5/5] mm/memory_hotplug: Simplify node_states_check_changes_offline
On Wed, Aug 22, 2018 at 11:32:26AM +0200, Oscar Salvador wrote: > From: Oscar Salvador > > This patch tries to simplify node_states_check_changes_offline > and make the code more understandable by: > > - Removing the if (N_MEMORY == N_NORMAL_MEMORY) wrong statement > - Removing the if (N_MEMORY == N_HIGH_MEMORY) wrong statement > - Re-structure the code a bit > - Removing confusing comments > > Signed-off-by: Oscar Salvador I realized I made a mistake here. I was not counting the present pages correctly. I will send a new version after the merge-windows gets closed. Sorry for the noise For the sake of clarity, the patch should have been: --- diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 006a7b817724..bca11da4e11f 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -1487,23 +1487,12 @@ static void node_states_check_changes_offline(unsigned long nr_pages, enum zone_type zt, zone_last = ZONE_NORMAL; /* -* If we have HIGHMEM or movable node, node_states[N_NORMAL_MEMORY] -* contains nodes which have zones of 0...ZONE_NORMAL, -* set zone_last to ZONE_NORMAL. -* -* If we don't have HIGHMEM nor movable node, -* node_states[N_NORMAL_MEMORY] contains nodes which have zones of -* 0...ZONE_MOVABLE, set zone_last to ZONE_MOVABLE. -*/ - if (N_MEMORY == N_NORMAL_MEMORY) - zone_last = ZONE_MOVABLE; - - /* -* check whether node_states[N_NORMAL_MEMORY] will be changed. -* If the memory to be offline is in a zone of 0...zone_last, -* and it is the last present memory, 0...zone_last will -* become empty after offline , thus we can determind we will -* need to clear the node from node_states[N_NORMAL_MEMORY]. +* If the current zone is whithin (0..ZONE_NORMAL], +* check if the amount of pages that are going to be +* offlined is above or equal to the sum of the present +* pages of these zones. +* If that happens, we need to take this node out of +* node_state[N_NORMAL_MEMORY] */ for (zt = 0; zt <= zone_last; zt++) present_pages += pgdat->node_zones[zt].present_pages; @@ -1514,21 +1503,15 @@ static void node_states_check_changes_offline(unsigned long nr_pages, #ifdef CONFIG_HIGHMEM /* -* If we have movable node, node_states[N_HIGH_MEMORY] -* contains nodes which have zones of 0...ZONE_HIGHMEM, -* set zone_last to ZONE_HIGHMEM. -* -* If we don't have movable node, node_states[N_NORMAL_MEMORY] -* contains nodes which have zones of 0...ZONE_MOVABLE, -* set zone_last to ZONE_MOVABLE. +* If the current zone is whithin (0..ZONE_HIGHMEM], check if +* the amount of pages that are going to be offlined is above +* or equal to the sum of the present pages of these zones. +* If that happens, we need to take this node out of +* node_state[N_HIGH_MEMORY] */ - zone_last = ZONE_HIGHMEM; - if (N_MEMORY == N_HIGH_MEMORY) - zone_last = ZONE_MOVABLE; - - for (; zt <= zone_last; zt++) - present_pages += pgdat->node_zones[zt].present_pages; - if (zone_idx(zone) <= zone_last && nr_pages >= present_pages) + zt = ZONE_HIGHMEM; + present_pages += pgdat->node_zones[zt].present_pages; + if (zone_idx(zone) <= zt && nr_pages >= present_pages) arg->status_change_nid_high = zone_to_nid(zone); else arg->status_change_nid_high = -1; @@ -1541,18 +1524,14 @@ static void node_states_check_changes_offline(unsigned long nr_pages, #endif /* -* node_states[N_HIGH_MEMORY] contains nodes which have 0...ZONE_MOVABLE +* Count pages from ZONE_MOVABLE as well. +* If the amount of pages that are going to be offlined is above +* or equal the sum of the present pages of all zones, we need +* to remove this node from node_state[N_MEMORY] */ - zone_last = ZONE_MOVABLE; + zt = ZONE_MOVABLE; + present_pages += pgdat->node_zones[zt].present_pages; - /* -* check whether node_states[N_HIGH_MEMORY] will be changed -* If we try to offline the last present @nr_pages from the node, -* we can determind we will need to clear the node from -* node_states[N_HIGH_MEMORY]. -*/ - for (; zt <= zone_last; zt++) - present_pages += pgdat->node_zones[zt].present_pages; if (nr_pages >= present_pages) arg->status_change_nid = zone_to_nid(zone); else -- Oscar Salvador SUSE L3
RE: [ANNOUNCE] 4.14.63-rt40
Steven, commit 7f11a591bbdb111792298144c3476506aa7f1ca8 (HEAD -> v4.14.63-rt40-rebase, tag: v4.14.63-rt40-rebase, origin/v4.14-rt-rebase) Author: Steven Rostedt (VMware) Date: Wed May 16 09:33:00 2018 -0400 Linux 4.14.63-rt40 REBASE diff --git a/localversion-rt b/localversion-rt index 90290c642ed5..a3b2408c1da6 100644 --- a/localversion-rt +++ b/localversion-rt @@ -1 +1 @@ --rt29 +-rt37 ^ Isn't it supposed to be rt40? Thanks Tiejun > -Original Message- > From: linux-rt-users-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Steven Rostedt > Sent: Thursday, August 23, 2018 2:15 AM > To: LKML ; linux-rt-users us...@vger.kernel.org> > Cc: Thomas Gleixner ; Carsten Emde > ; John Kacur ; Sebastian Andrzej > Siewior ; Julia Cartwright ; Daniel > Wagner ; Tom Zanussi > > Subject: [ANNOUNCE] 4.14.63-rt40 > > > Dear RT Folks, > > I'm pleased to announce the 4.14.63-rt40 stable release. > > > This release is just an update to the new stable 4.14.63 version and no RT > specific changes have been made. > > NOTE: There is a known issue with this release. The fix is here: > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flkml.ker > nel.org%2Fr%2F1534660115.6187.4.camel%40gmx.dedata=02%7C01% > 7Ctiejunc%40vmware.com%7Cf5505a126bb8491ac2db08d6085b2e15%7Cb39 > 138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636705585062142956 > ;sdata=vdH9xCIjC2pVwMggGJvVAkfIrq2jG3qJaTi0asnq7Sk%3Dreserved > =0 > > I did not apply it to this release because it needs to be added to v4.16-rt > first > before it gets backported. Feel free to apply it yourself if you have any > concerns. > > You can get this release via the git tree at: > > git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git > > branch: v4.14-rt > Head SHA1: da6bee3cef4af60566dc56f3d48fce0b18165107 > > > Or to build 4.14.63-rt40 directly, the following patches should be applied: > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ke > rnel.org%2Fpub%2Flinux%2Fkernel%2Fv4.x%2Flinux- > 4.14.tar.xzdata=02%7C01%7Ctiejunc%40vmware.com%7Cf5505a126bb > 8491ac2db08d6085b2e15%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7 > C0%7C636705585062152970sdata=cuTUJOzPb8rJSbK8QLfqb5s9jHNYk3 > WbrUDla5s6ixM%3Dreserved=0 > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ke > rnel.org%2Fpub%2Flinux%2Fkernel%2Fv4.x%2Fpatch- > 4.14.63.xzdata=02%7C01%7Ctiejunc%40vmware.com%7Cf5505a126bb > 8491ac2db08d6085b2e15%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7 > C0%7C636705585062152970sdata=yVr3le4J2mYik%2B8MJ796KcEb%2B > 7i%2BhAkEWQt2qZ5q2KY%3Dreserved=0 > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ke > rnel.org%2Fpub%2Flinux%2Fkernel%2Fprojects%2Frt%2F4.14%2Fpatch- > 4.14.63- > rt40.patch.xzdata=02%7C01%7Ctiejunc%40vmware.com%7Cf5505a126 > bb8491ac2db08d6085b2e15%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1 > %7C0%7C636705585062152970sdata=TEcL3d3nkG623UFOgWZV5wkrJl > oPsY7qXcZ8bm%2FmFDI%3Dreserved=0 > > > > > Enjoy, > > -- Steve
RE: [ANNOUNCE] 4.14.63-rt40
Steven, commit 7f11a591bbdb111792298144c3476506aa7f1ca8 (HEAD -> v4.14.63-rt40-rebase, tag: v4.14.63-rt40-rebase, origin/v4.14-rt-rebase) Author: Steven Rostedt (VMware) Date: Wed May 16 09:33:00 2018 -0400 Linux 4.14.63-rt40 REBASE diff --git a/localversion-rt b/localversion-rt index 90290c642ed5..a3b2408c1da6 100644 --- a/localversion-rt +++ b/localversion-rt @@ -1 +1 @@ --rt29 +-rt37 ^ Isn't it supposed to be rt40? Thanks Tiejun > -Original Message- > From: linux-rt-users-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Steven Rostedt > Sent: Thursday, August 23, 2018 2:15 AM > To: LKML ; linux-rt-users us...@vger.kernel.org> > Cc: Thomas Gleixner ; Carsten Emde > ; John Kacur ; Sebastian Andrzej > Siewior ; Julia Cartwright ; Daniel > Wagner ; Tom Zanussi > > Subject: [ANNOUNCE] 4.14.63-rt40 > > > Dear RT Folks, > > I'm pleased to announce the 4.14.63-rt40 stable release. > > > This release is just an update to the new stable 4.14.63 version and no RT > specific changes have been made. > > NOTE: There is a known issue with this release. The fix is here: > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flkml.ker > nel.org%2Fr%2F1534660115.6187.4.camel%40gmx.dedata=02%7C01% > 7Ctiejunc%40vmware.com%7Cf5505a126bb8491ac2db08d6085b2e15%7Cb39 > 138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636705585062142956 > ;sdata=vdH9xCIjC2pVwMggGJvVAkfIrq2jG3qJaTi0asnq7Sk%3Dreserved > =0 > > I did not apply it to this release because it needs to be added to v4.16-rt > first > before it gets backported. Feel free to apply it yourself if you have any > concerns. > > You can get this release via the git tree at: > > git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git > > branch: v4.14-rt > Head SHA1: da6bee3cef4af60566dc56f3d48fce0b18165107 > > > Or to build 4.14.63-rt40 directly, the following patches should be applied: > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ke > rnel.org%2Fpub%2Flinux%2Fkernel%2Fv4.x%2Flinux- > 4.14.tar.xzdata=02%7C01%7Ctiejunc%40vmware.com%7Cf5505a126bb > 8491ac2db08d6085b2e15%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7 > C0%7C636705585062152970sdata=cuTUJOzPb8rJSbK8QLfqb5s9jHNYk3 > WbrUDla5s6ixM%3Dreserved=0 > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ke > rnel.org%2Fpub%2Flinux%2Fkernel%2Fv4.x%2Fpatch- > 4.14.63.xzdata=02%7C01%7Ctiejunc%40vmware.com%7Cf5505a126bb > 8491ac2db08d6085b2e15%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7 > C0%7C636705585062152970sdata=yVr3le4J2mYik%2B8MJ796KcEb%2B > 7i%2BhAkEWQt2qZ5q2KY%3Dreserved=0 > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ke > rnel.org%2Fpub%2Flinux%2Fkernel%2Fprojects%2Frt%2F4.14%2Fpatch- > 4.14.63- > rt40.patch.xzdata=02%7C01%7Ctiejunc%40vmware.com%7Cf5505a126 > bb8491ac2db08d6085b2e15%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1 > %7C0%7C636705585062152970sdata=TEcL3d3nkG623UFOgWZV5wkrJl > oPsY7qXcZ8bm%2FmFDI%3Dreserved=0 > > > > > Enjoy, > > -- Steve
Re: [RFC PATCH] EDAC, ghes: Enable per-layer error reporting for ARM
Hi guys, (CC: +Fan Wu) On 19/07/18 19:36, Tyler Baicar wrote: > On 7/19/2018 10:46 AM, James Morse wrote: >> On 19/07/18 15:01, Borislav Petkov wrote: >>> On Mon, Jul 16, 2018 at 01:26:49PM -0400, Tyler Baicar wrote: Enable per-layer error reporting for ARM systems so that the error counters are incremented per-DIMM. This 'layer' term seems to be EDAC's artificial view of memory. >> I'm guessing this is the mapping between CPER records and the DMItable data. > Unfortunately the DMI table doesn't actually have channel and DIMM number > values > which makes this more complicated than I originally thought... information and enable per layer error reporting for ARM systems so that the EDAC error counters are incremented based on DIMM number as per the SMBIOS table rather than just incrementing the noinfo counters on the memory controller. >> Does this work on x86, and its just the dmi/cper fields have a subtle >> difference? > There are CPU specific EDAC drivers for a lot of x86 folks and those drivers > populate the layer information in a custom way. Not for GHES surely? > With more investigation and testing it turns out a simple patch like this is > not > going to work. This worked for > me on a 1DPC board since the card number turned out to always be the same as > the > index into the DMI table > to find the proper DIMM. On a 2DPC board this fails completely. The ghes_edac > driver only sets up a single > layer so it is only using the card number with this patch. (DPC == DIMM per Channel?) > So it is only setting up a single layer with all the DIMMs on that layer. In > order to properly enable the layers > to represent channel and DIMM number on that channel, we would need to have a > way of determining the > number of channels (which would be layers[0].size) and the number of DIMMs > each > channel supported > (layers[1].size). There doesn't appear to be a way to determine that > information > at this point. So, we're after a mapping for EDAC:layers that includes 'channel'? What would you do with a channel counter? Isn't that part of the SoC? (it can't be replaced!) > The goal is to be able to enable the per layer error reporting in the > ghes_edac > driver so that the per dimm counters exposed in the EDAC sysfs nodes are > properly > updated. What do you mean by layer? I can't find anything in the ACPI/UEFI/SMBIOS specs that uses this term... If its just 'per dimm counters' you're after, this looks straightforward. > The other obvious but more messy way would be to have notifiers register to > be called > by ghes_edac and have a custom EDAC driver for each CPU to properly populate > their layer > information. Yuck. This isn't platform specific, its firmware specific. You're hooking the driver to say "my firmware thinks 'card' means this". Where would this information come from? We don't want per-soc,per-firmware-version code mangling what was supposed to be a standard interface. ... we can't be the first people to try and do this ... [re-ordered hunk:] > This seems pretty hacky to me, so if anyone has other suggestions please share > them. CPER's "Memory Error Record 2" thinks that "NODE, CARD and MODULE should provide the information necessary to identify the failing FRU". As EDAC has three 'levels', these are what they should correspond to for ghes-edac. I assume NODE means rack/chassis in some distributed system. Lets ignore it as it doesn't seem to map to anything in the SMBIOS table. The CPER record's card and module numbers are useless to us, as we need to know how many there will be in advance. (does this version of firmware count from 0 or 1?) ... but CPER also gives us a 'Card Handle' and 'Module Handle'. 'Module Handle' maps to SMBIOS:17 Memory Device (aka, a DIMM). The Handle is a word-value in the structure, so it doesn't depend on the layout/parse-order of the SMBIOS tables. When we count the DIMMs in edac-ghes we can give them some level-idx, then use the handle to find which level-idx to use for this DIMM. ghes_edac_report_mem_error() already picks up the module-handle, but only uses it to print the bank/device. 'Card' doesn't mean much to me, but it maps to SMBIOS:17 "Memory Array Structure", which the Memory Device structure also points to. Card then must mean "a collection of memory devices (DIMMs) that operate together to form an address space". This might be what I think of as a memory-controller, or it might be something more complicated. Regardless, the CPER records think its relevant. For the edac:layers, we could walk the DMI table to find these structures, and build the layers from them. If the Memory-array-structures are missing, we can use the existing 1:NUM_DIMMS approach. Hope this makes sense! Thanks, James
Re: [RFC PATCH] EDAC, ghes: Enable per-layer error reporting for ARM
Hi guys, (CC: +Fan Wu) On 19/07/18 19:36, Tyler Baicar wrote: > On 7/19/2018 10:46 AM, James Morse wrote: >> On 19/07/18 15:01, Borislav Petkov wrote: >>> On Mon, Jul 16, 2018 at 01:26:49PM -0400, Tyler Baicar wrote: Enable per-layer error reporting for ARM systems so that the error counters are incremented per-DIMM. This 'layer' term seems to be EDAC's artificial view of memory. >> I'm guessing this is the mapping between CPER records and the DMItable data. > Unfortunately the DMI table doesn't actually have channel and DIMM number > values > which makes this more complicated than I originally thought... information and enable per layer error reporting for ARM systems so that the EDAC error counters are incremented based on DIMM number as per the SMBIOS table rather than just incrementing the noinfo counters on the memory controller. >> Does this work on x86, and its just the dmi/cper fields have a subtle >> difference? > There are CPU specific EDAC drivers for a lot of x86 folks and those drivers > populate the layer information in a custom way. Not for GHES surely? > With more investigation and testing it turns out a simple patch like this is > not > going to work. This worked for > me on a 1DPC board since the card number turned out to always be the same as > the > index into the DMI table > to find the proper DIMM. On a 2DPC board this fails completely. The ghes_edac > driver only sets up a single > layer so it is only using the card number with this patch. (DPC == DIMM per Channel?) > So it is only setting up a single layer with all the DIMMs on that layer. In > order to properly enable the layers > to represent channel and DIMM number on that channel, we would need to have a > way of determining the > number of channels (which would be layers[0].size) and the number of DIMMs > each > channel supported > (layers[1].size). There doesn't appear to be a way to determine that > information > at this point. So, we're after a mapping for EDAC:layers that includes 'channel'? What would you do with a channel counter? Isn't that part of the SoC? (it can't be replaced!) > The goal is to be able to enable the per layer error reporting in the > ghes_edac > driver so that the per dimm counters exposed in the EDAC sysfs nodes are > properly > updated. What do you mean by layer? I can't find anything in the ACPI/UEFI/SMBIOS specs that uses this term... If its just 'per dimm counters' you're after, this looks straightforward. > The other obvious but more messy way would be to have notifiers register to > be called > by ghes_edac and have a custom EDAC driver for each CPU to properly populate > their layer > information. Yuck. This isn't platform specific, its firmware specific. You're hooking the driver to say "my firmware thinks 'card' means this". Where would this information come from? We don't want per-soc,per-firmware-version code mangling what was supposed to be a standard interface. ... we can't be the first people to try and do this ... [re-ordered hunk:] > This seems pretty hacky to me, so if anyone has other suggestions please share > them. CPER's "Memory Error Record 2" thinks that "NODE, CARD and MODULE should provide the information necessary to identify the failing FRU". As EDAC has three 'levels', these are what they should correspond to for ghes-edac. I assume NODE means rack/chassis in some distributed system. Lets ignore it as it doesn't seem to map to anything in the SMBIOS table. The CPER record's card and module numbers are useless to us, as we need to know how many there will be in advance. (does this version of firmware count from 0 or 1?) ... but CPER also gives us a 'Card Handle' and 'Module Handle'. 'Module Handle' maps to SMBIOS:17 Memory Device (aka, a DIMM). The Handle is a word-value in the structure, so it doesn't depend on the layout/parse-order of the SMBIOS tables. When we count the DIMMs in edac-ghes we can give them some level-idx, then use the handle to find which level-idx to use for this DIMM. ghes_edac_report_mem_error() already picks up the module-handle, but only uses it to print the bank/device. 'Card' doesn't mean much to me, but it maps to SMBIOS:17 "Memory Array Structure", which the Memory Device structure also points to. Card then must mean "a collection of memory devices (DIMMs) that operate together to form an address space". This might be what I think of as a memory-controller, or it might be something more complicated. Regardless, the CPER records think its relevant. For the edac:layers, we could walk the DMI table to find these structures, and build the layers from them. If the Memory-array-structures are missing, we can use the existing 1:NUM_DIMMS approach. Hope this makes sense! Thanks, James
Re: [PATCH v9 12/22] s390: vfio-ap: sysfs interfaces to configure control domains
On 08/22/2018 09:16 PM, Tony Krowiak wrote: On 08/22/2018 01:11 PM, Halil Pasic wrote: On 08/22/2018 05:48 PM, Christian Borntraeger wrote: On 08/22/2018 05:34 PM, Pierre Morel wrote: On 22/08/2018 17:11, Christian Borntraeger wrote: On 08/22/2018 01:03 PM, Pierre Morel wrote: That's interesting. IMHO this quote is quite a half-full half-empty cup one: * it mandates the set of usage domains is a subset of the set of the control domains, but * it speaks of independent controls, namely about the 'usage domain index' and the 'control domain index list' and makes the enforcement of the rule a job of the administrator (instead of codifying it in the controls). I'm wondering if a configuration with a usage domain that is not also a control domain is rejected outright? Anybody tried that? :) Yes, and no it is not. We can use a queue (usage domain) to a AP card for SHA-512 or RSA without having to define the queue as a control domain. Huh? My HMC allows to add a domain as - control only domain - control and usage domain. But I am not able to configure a usage-only domain for my LPAR. That seems to match the current code, no? Yes, it may not be configurable by the HMC but if we start a guest with no control domain it is not a problem to access the hardware through the usage domain. I tested this a long time ago, but tested again today to be sure on my LPAR. AFAIU adding a control only domain and a control and usage domain allows say: control and usage domain 1 control only domain 2 Allow to send a message to domain 2 using queue 1 Allow also to send a domain modifying message to domain 1 using queue 1 control domain are domain which are controlled So you have changed the code to not automatically make a usage domain a control domain in the bitfield (and you could still use it as a usage domain). Correct? I tested basically the same yesterday, with the same results. I think this is probably expected. the "usage implies control" seems to be a convention implemented by HMC (lpar) and z/VM but millicode offers the bits to have usage-only domains. As LPAR and z/VM will always enable any usage-domain to also be a control domain we should do the same. I'm fine either way, but slightly prefer higher level management software and not the kernel accommodating this convention. Please consider a quote from Harald's mail in another sub-thread """ ... about control domains Talked with the s390 firmware guys. The convention that the control domain mask is a superset of the usage domain mask is only true for 1st level guests. It is absolutely valid to run a kvm guest with restricted control domain mask bitmap in the CRYCB. It is valid to have an empty control domain mask and the guest should be able to run crypto CPRBs on the usage domain(s) without any problems. However, nobody has tried this. """ I'm yet to get an explanation why was this convention established in the first place. And I can not figure it out myself. For me a setup where I know that the domains used by some guest can not be modified by the same guest makes perfect sense. If I try to think in analogies, I kind of compare modification (that is control domain) with write access, and usage (that is usage domain) with read access to, let's say a regular file. For me, all options (rw, r, and w) do make sense, and if I had to pick the one that makes the least sense I would pick write only. The convention is in these terms making read-only illegal. But should 'usage only domains' ever get identified as something somebody wants to do we can just add an attribute for that. So I'm fine either way. One of the things I suggested in a private conversation with Christian earlier today was to provide an additional rw sysfs attribute - a boolean - that indicates whether all usage domains should also be control domains. The default could be true. This would allow one to configure guests with usage-only domains as well as satisfy the convention. I prefer keeping the attributes as they are and adding a new let's say (un)assign_usage_domain if the need arises over this boolean attribute that changes how (un)assign_domain works. Halil
Re: [PATCH v9 12/22] s390: vfio-ap: sysfs interfaces to configure control domains
On 08/22/2018 09:16 PM, Tony Krowiak wrote: On 08/22/2018 01:11 PM, Halil Pasic wrote: On 08/22/2018 05:48 PM, Christian Borntraeger wrote: On 08/22/2018 05:34 PM, Pierre Morel wrote: On 22/08/2018 17:11, Christian Borntraeger wrote: On 08/22/2018 01:03 PM, Pierre Morel wrote: That's interesting. IMHO this quote is quite a half-full half-empty cup one: * it mandates the set of usage domains is a subset of the set of the control domains, but * it speaks of independent controls, namely about the 'usage domain index' and the 'control domain index list' and makes the enforcement of the rule a job of the administrator (instead of codifying it in the controls). I'm wondering if a configuration with a usage domain that is not also a control domain is rejected outright? Anybody tried that? :) Yes, and no it is not. We can use a queue (usage domain) to a AP card for SHA-512 or RSA without having to define the queue as a control domain. Huh? My HMC allows to add a domain as - control only domain - control and usage domain. But I am not able to configure a usage-only domain for my LPAR. That seems to match the current code, no? Yes, it may not be configurable by the HMC but if we start a guest with no control domain it is not a problem to access the hardware through the usage domain. I tested this a long time ago, but tested again today to be sure on my LPAR. AFAIU adding a control only domain and a control and usage domain allows say: control and usage domain 1 control only domain 2 Allow to send a message to domain 2 using queue 1 Allow also to send a domain modifying message to domain 1 using queue 1 control domain are domain which are controlled So you have changed the code to not automatically make a usage domain a control domain in the bitfield (and you could still use it as a usage domain). Correct? I tested basically the same yesterday, with the same results. I think this is probably expected. the "usage implies control" seems to be a convention implemented by HMC (lpar) and z/VM but millicode offers the bits to have usage-only domains. As LPAR and z/VM will always enable any usage-domain to also be a control domain we should do the same. I'm fine either way, but slightly prefer higher level management software and not the kernel accommodating this convention. Please consider a quote from Harald's mail in another sub-thread """ ... about control domains Talked with the s390 firmware guys. The convention that the control domain mask is a superset of the usage domain mask is only true for 1st level guests. It is absolutely valid to run a kvm guest with restricted control domain mask bitmap in the CRYCB. It is valid to have an empty control domain mask and the guest should be able to run crypto CPRBs on the usage domain(s) without any problems. However, nobody has tried this. """ I'm yet to get an explanation why was this convention established in the first place. And I can not figure it out myself. For me a setup where I know that the domains used by some guest can not be modified by the same guest makes perfect sense. If I try to think in analogies, I kind of compare modification (that is control domain) with write access, and usage (that is usage domain) with read access to, let's say a regular file. For me, all options (rw, r, and w) do make sense, and if I had to pick the one that makes the least sense I would pick write only. The convention is in these terms making read-only illegal. But should 'usage only domains' ever get identified as something somebody wants to do we can just add an attribute for that. So I'm fine either way. One of the things I suggested in a private conversation with Christian earlier today was to provide an additional rw sysfs attribute - a boolean - that indicates whether all usage domains should also be control domains. The default could be true. This would allow one to configure guests with usage-only domains as well as satisfy the convention. I prefer keeping the attributes as they are and adding a new let's say (un)assign_usage_domain if the need arises over this boolean attribute that changes how (un)assign_domain works. Halil
[PATCH 4.14 198/217] ACPI / EC: Use ec_no_wakeup on more Thinkpad X1 Carbon 6th systems
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: "Robin H. Johnson"
[ Upstream commit 2c4d6baf1bc4f7729773ffcee9ba2a9781578633 ]
The ec_no_wakeup matcher added for Thinkpad X1 Carbon 6th gen systems
beyond matched only a single DMI model (20KGS3JF01), that didn't cover
my laptop (20KH002JUS). Change to match based on DMI product family to
cover all X1 6th gen systems.
Signed-off-by: Robin H. Johnson
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/acpi/ec.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -2034,7 +2034,7 @@ static const struct dmi_system_id acpi_e
.ident = "Thinkpad X1 Carbon 6th",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
- DMI_MATCH(DMI_PRODUCT_NAME, "20KGS3JF01"),
+ DMI_MATCH(DMI_PRODUCT_FAMILY, "Thinkpad X1 Carbon 6th"),
},
},
{ },
[PATCH 4.14 198/217] ACPI / EC: Use ec_no_wakeup on more Thinkpad X1 Carbon 6th systems
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: "Robin H. Johnson"
[ Upstream commit 2c4d6baf1bc4f7729773ffcee9ba2a9781578633 ]
The ec_no_wakeup matcher added for Thinkpad X1 Carbon 6th gen systems
beyond matched only a single DMI model (20KGS3JF01), that didn't cover
my laptop (20KH002JUS). Change to match based on DMI product family to
cover all X1 6th gen systems.
Signed-off-by: Robin H. Johnson
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/acpi/ec.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -2034,7 +2034,7 @@ static const struct dmi_system_id acpi_e
.ident = "Thinkpad X1 Carbon 6th",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
- DMI_MATCH(DMI_PRODUCT_NAME, "20KGS3JF01"),
+ DMI_MATCH(DMI_PRODUCT_FAMILY, "Thinkpad X1 Carbon 6th"),
},
},
{ },
[PATCH 4.17 004/324] HID: google: Add support for whiskers
4.17-stable review patch. If anyone has any objections, please let me know.
--
From: Nicolas Boichat
[ Upstream commit 3e84c7651dde7cca43c5cfd7385086599cce5a5d ]
Another device in the hammer class, with USB id 0x5030.
Signed-off-by: Nicolas Boichat
Acked-by: Benjamin Tissoires
Signed-off-by: Jiri Kosina
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/hid/hid-google-hammer.c |2 ++
drivers/hid/hid-ids.h |1 +
2 files changed, 3 insertions(+)
--- a/drivers/hid/hid-google-hammer.c
+++ b/drivers/hid/hid-google-hammer.c
@@ -124,6 +124,8 @@ static const struct hid_device_id hammer
USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_STAFF) },
{ HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_WAND) },
+ { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
+USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_WHISKERS) },
{ }
};
MODULE_DEVICE_TABLE(hid, hammer_devices);
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -452,6 +452,7 @@
#define USB_DEVICE_ID_GOOGLE_TOUCH_ROSE0x5028
#define USB_DEVICE_ID_GOOGLE_STAFF 0x502b
#define USB_DEVICE_ID_GOOGLE_WAND 0x502d
+#define USB_DEVICE_ID_GOOGLE_WHISKERS 0x5030
#define USB_VENDOR_ID_GOTOP0x08f2
#define USB_DEVICE_ID_SUPER_Q2 0x007f
[PATCH 4.17 004/324] HID: google: Add support for whiskers
4.17-stable review patch. If anyone has any objections, please let me know.
--
From: Nicolas Boichat
[ Upstream commit 3e84c7651dde7cca43c5cfd7385086599cce5a5d ]
Another device in the hammer class, with USB id 0x5030.
Signed-off-by: Nicolas Boichat
Acked-by: Benjamin Tissoires
Signed-off-by: Jiri Kosina
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/hid/hid-google-hammer.c |2 ++
drivers/hid/hid-ids.h |1 +
2 files changed, 3 insertions(+)
--- a/drivers/hid/hid-google-hammer.c
+++ b/drivers/hid/hid-google-hammer.c
@@ -124,6 +124,8 @@ static const struct hid_device_id hammer
USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_STAFF) },
{ HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_WAND) },
+ { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
+USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_WHISKERS) },
{ }
};
MODULE_DEVICE_TABLE(hid, hammer_devices);
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -452,6 +452,7 @@
#define USB_DEVICE_ID_GOOGLE_TOUCH_ROSE0x5028
#define USB_DEVICE_ID_GOOGLE_STAFF 0x502b
#define USB_DEVICE_ID_GOOGLE_WAND 0x502d
+#define USB_DEVICE_ID_GOOGLE_WHISKERS 0x5030
#define USB_VENDOR_ID_GOTOP0x08f2
#define USB_DEVICE_ID_SUPER_Q2 0x007f
[PATCH 4.17 011/324] drm/bridge/sii8620: fix display modes validation
4.17-stable review patch. If anyone has any objections, please let me know.
--
From: Maciej Purski
[ Upstream commit ecba7cfa3afbe489288f2c819158b7402afd7ee9 ]
Current implementation of mode_valid() and mode_fixup() callbacks
handle packed pixel modes improperly.
Fix it by using proper maximum clock values from the documentation.
Signed-off-by: Maciej Purski
Signed-off-by: Andrzej Hajda
Link:
https://patchwork.freedesktop.org/patch/msgid/1517568865-25219-1-git-send-email-m.pur...@samsung.com
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/bridge/sil-sii8620.c | 78 +--
1 file changed, 40 insertions(+), 38 deletions(-)
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -36,8 +36,11 @@
#define SII8620_BURST_BUF_LEN 288
#define VAL_RX_HDMI_CTRL2_DEFVAL VAL_RX_HDMI_CTRL2_IDLE_CNT(3)
-#define MHL1_MAX_LCLK 225000
-#define MHL3_MAX_LCLK 60
+
+#define MHL1_MAX_PCLK 75000
+#define MHL1_MAX_PCLK_PP_MODE 15
+#define MHL3_MAX_PCLK 20
+#define MHL3_MAX_PCLK_PP_MODE 30
enum sii8620_mode {
CM_DISCONNECTED,
@@ -2277,17 +2280,43 @@ static void sii8620_detach(struct drm_br
rc_unregister_device(ctx->rc_dev);
}
+static int sii8620_is_packing_required(struct sii8620 *ctx,
+ const struct drm_display_mode *mode)
+{
+ int max_pclk, max_pclk_pp_mode;
+
+ if (sii8620_is_mhl3(ctx)) {
+ max_pclk = MHL3_MAX_PCLK;
+ max_pclk_pp_mode = MHL3_MAX_PCLK_PP_MODE;
+ } else {
+ max_pclk = MHL1_MAX_PCLK;
+ max_pclk_pp_mode = MHL1_MAX_PCLK_PP_MODE;
+ }
+
+ if (mode->clock < max_pclk)
+ return 0;
+ else if (mode->clock < max_pclk_pp_mode)
+ return 1;
+ else
+ return -1;
+}
+
static enum drm_mode_status sii8620_mode_valid(struct drm_bridge *bridge,
const struct drm_display_mode *mode)
{
struct sii8620 *ctx = bridge_to_sii8620(bridge);
+ int pack_required = sii8620_is_packing_required(ctx, mode);
bool can_pack = ctx->devcap[MHL_DCAP_VID_LINK_MODE] &
MHL_DCAP_VID_LINK_PPIXEL;
- unsigned int max_pclk = sii8620_is_mhl3(ctx) ? MHL3_MAX_LCLK :
- MHL1_MAX_LCLK;
- max_pclk /= can_pack ? 2 : 3;
- return (mode->clock > max_pclk) ? MODE_CLOCK_HIGH : MODE_OK;
+ switch (pack_required) {
+ case 0:
+ return MODE_OK;
+ case 1:
+ return (can_pack) ? MODE_OK : MODE_CLOCK_HIGH;
+ default:
+ return MODE_CLOCK_HIGH;
+ }
}
static bool sii8620_mode_fixup(struct drm_bridge *bridge,
@@ -2295,43 +2324,16 @@ static bool sii8620_mode_fixup(struct dr
struct drm_display_mode *adjusted_mode)
{
struct sii8620 *ctx = bridge_to_sii8620(bridge);
- int max_lclk;
- bool ret = true;
mutex_lock(>lock);
- max_lclk = sii8620_is_mhl3(ctx) ? MHL3_MAX_LCLK : MHL1_MAX_LCLK;
- if (max_lclk > 3 * adjusted_mode->clock) {
- ctx->use_packed_pixel = 0;
- goto end;
- }
- if ((ctx->devcap[MHL_DCAP_VID_LINK_MODE] & MHL_DCAP_VID_LINK_PPIXEL) &&
- max_lclk > 2 * adjusted_mode->clock) {
- ctx->use_packed_pixel = 1;
- goto end;
- }
- ret = false;
-end:
- if (ret) {
- u8 vic = drm_match_cea_mode(adjusted_mode);
+ ctx->use_packed_pixel = sii8620_is_packing_required(ctx, adjusted_mode);
+ ctx->video_code = drm_match_cea_mode(adjusted_mode);
+ ctx->pixel_clock = adjusted_mode->clock;
- if (!vic) {
- union hdmi_infoframe frm;
- u8 mhl_vic[] = { 0, 95, 94, 93, 98 };
-
- /* FIXME: We need the connector here */
- drm_hdmi_vendor_infoframe_from_display_mode(
- , NULL, adjusted_mode);
- vic = frm.vendor.hdmi.vic;
- if (vic >= ARRAY_SIZE(mhl_vic))
- vic = 0;
- vic = mhl_vic[vic];
- }
- ctx->video_code = vic;
- ctx->pixel_clock = adjusted_mode->clock;
- }
mutex_unlock(>lock);
- return ret;
+
+ return true;
}
static const struct drm_bridge_funcs sii8620_bridge_funcs = {
[PATCH 4.17 011/324] drm/bridge/sii8620: fix display modes validation
4.17-stable review patch. If anyone has any objections, please let me know.
--
From: Maciej Purski
[ Upstream commit ecba7cfa3afbe489288f2c819158b7402afd7ee9 ]
Current implementation of mode_valid() and mode_fixup() callbacks
handle packed pixel modes improperly.
Fix it by using proper maximum clock values from the documentation.
Signed-off-by: Maciej Purski
Signed-off-by: Andrzej Hajda
Link:
https://patchwork.freedesktop.org/patch/msgid/1517568865-25219-1-git-send-email-m.pur...@samsung.com
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/bridge/sil-sii8620.c | 78 +--
1 file changed, 40 insertions(+), 38 deletions(-)
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -36,8 +36,11 @@
#define SII8620_BURST_BUF_LEN 288
#define VAL_RX_HDMI_CTRL2_DEFVAL VAL_RX_HDMI_CTRL2_IDLE_CNT(3)
-#define MHL1_MAX_LCLK 225000
-#define MHL3_MAX_LCLK 60
+
+#define MHL1_MAX_PCLK 75000
+#define MHL1_MAX_PCLK_PP_MODE 15
+#define MHL3_MAX_PCLK 20
+#define MHL3_MAX_PCLK_PP_MODE 30
enum sii8620_mode {
CM_DISCONNECTED,
@@ -2277,17 +2280,43 @@ static void sii8620_detach(struct drm_br
rc_unregister_device(ctx->rc_dev);
}
+static int sii8620_is_packing_required(struct sii8620 *ctx,
+ const struct drm_display_mode *mode)
+{
+ int max_pclk, max_pclk_pp_mode;
+
+ if (sii8620_is_mhl3(ctx)) {
+ max_pclk = MHL3_MAX_PCLK;
+ max_pclk_pp_mode = MHL3_MAX_PCLK_PP_MODE;
+ } else {
+ max_pclk = MHL1_MAX_PCLK;
+ max_pclk_pp_mode = MHL1_MAX_PCLK_PP_MODE;
+ }
+
+ if (mode->clock < max_pclk)
+ return 0;
+ else if (mode->clock < max_pclk_pp_mode)
+ return 1;
+ else
+ return -1;
+}
+
static enum drm_mode_status sii8620_mode_valid(struct drm_bridge *bridge,
const struct drm_display_mode *mode)
{
struct sii8620 *ctx = bridge_to_sii8620(bridge);
+ int pack_required = sii8620_is_packing_required(ctx, mode);
bool can_pack = ctx->devcap[MHL_DCAP_VID_LINK_MODE] &
MHL_DCAP_VID_LINK_PPIXEL;
- unsigned int max_pclk = sii8620_is_mhl3(ctx) ? MHL3_MAX_LCLK :
- MHL1_MAX_LCLK;
- max_pclk /= can_pack ? 2 : 3;
- return (mode->clock > max_pclk) ? MODE_CLOCK_HIGH : MODE_OK;
+ switch (pack_required) {
+ case 0:
+ return MODE_OK;
+ case 1:
+ return (can_pack) ? MODE_OK : MODE_CLOCK_HIGH;
+ default:
+ return MODE_CLOCK_HIGH;
+ }
}
static bool sii8620_mode_fixup(struct drm_bridge *bridge,
@@ -2295,43 +2324,16 @@ static bool sii8620_mode_fixup(struct dr
struct drm_display_mode *adjusted_mode)
{
struct sii8620 *ctx = bridge_to_sii8620(bridge);
- int max_lclk;
- bool ret = true;
mutex_lock(>lock);
- max_lclk = sii8620_is_mhl3(ctx) ? MHL3_MAX_LCLK : MHL1_MAX_LCLK;
- if (max_lclk > 3 * adjusted_mode->clock) {
- ctx->use_packed_pixel = 0;
- goto end;
- }
- if ((ctx->devcap[MHL_DCAP_VID_LINK_MODE] & MHL_DCAP_VID_LINK_PPIXEL) &&
- max_lclk > 2 * adjusted_mode->clock) {
- ctx->use_packed_pixel = 1;
- goto end;
- }
- ret = false;
-end:
- if (ret) {
- u8 vic = drm_match_cea_mode(adjusted_mode);
+ ctx->use_packed_pixel = sii8620_is_packing_required(ctx, adjusted_mode);
+ ctx->video_code = drm_match_cea_mode(adjusted_mode);
+ ctx->pixel_clock = adjusted_mode->clock;
- if (!vic) {
- union hdmi_infoframe frm;
- u8 mhl_vic[] = { 0, 95, 94, 93, 98 };
-
- /* FIXME: We need the connector here */
- drm_hdmi_vendor_infoframe_from_display_mode(
- , NULL, adjusted_mode);
- vic = frm.vendor.hdmi.vic;
- if (vic >= ARRAY_SIZE(mhl_vic))
- vic = 0;
- vic = mhl_vic[vic];
- }
- ctx->video_code = vic;
- ctx->pixel_clock = adjusted_mode->clock;
- }
mutex_unlock(>lock);
- return ret;
+
+ return true;
}
static const struct drm_bridge_funcs sii8620_bridge_funcs = {
[tip:perf/urgent] perf parser: Improve error message for PMU address filters
Commit-ID: 49836f7811f383d8613661fff110ce74f4710d52
Gitweb: https://git.kernel.org/tip/49836f7811f383d8613661fff110ce74f4710d52
Author: Jack Henschel
AuthorDate: Wed, 4 Jul 2018 14:13:45 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 20 Aug 2018 08:54:58 -0300
perf parser: Improve error message for PMU address filters
This is the second version of a patch that improves the error message of
the perf events parser when the PMU hardware does not support address
filters.
Previously, the perf returned the following error:
$ perf record -e intel_pt// --filter 'filter sys_write'
--filter option should follow a -e tracepoint or HW tracer option
This implies there is some syntax error present in the command line,
which is not true. Rather, notify the user that the CPU does not have
support for this feature.
For example, Intel chips based on the Broadwell micro-archticture have
the Intel PT PMU, but do not support address filtering.
Now, perf prints the following error message:
$ perf record -e intel_pt// --filter 'filter sys_write'
This CPU does not support address filtering
Signed-off-by: Jack Henschel
Tested-by: Arnaldo Carvalho de Melo
Acked-by: Jiri Olsa
Cc: Alexander Shishkin
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20180704121345.19025-1-jack...@mailbox.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/parse-events.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 15eec49e71a1..f8cd3e7c9186 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -1991,8 +1991,11 @@ static int set_filter(struct perf_evsel *evsel, const
void *arg)
int nr_addr_filters = 0;
struct perf_pmu *pmu = NULL;
- if (evsel == NULL)
- goto err;
+ if (evsel == NULL) {
+ fprintf(stderr,
+ "--filter option should follow a -e tracepoint or HW
tracer option\n");
+ return -1;
+ }
if (evsel->attr.type == PERF_TYPE_TRACEPOINT) {
if (perf_evsel__append_tp_filter(evsel, str) < 0) {
@@ -2014,8 +2017,11 @@ static int set_filter(struct perf_evsel *evsel, const
void *arg)
perf_pmu__scan_file(pmu, "nr_addr_filters",
"%d", _addr_filters);
- if (!nr_addr_filters)
- goto err;
+ if (!nr_addr_filters) {
+ fprintf(stderr,
+ "This CPU does not support address filtering\n");
+ return -1;
+ }
if (perf_evsel__append_addr_filter(evsel, str) < 0) {
fprintf(stderr,
@@ -2024,12 +2030,6 @@ static int set_filter(struct perf_evsel *evsel, const
void *arg)
}
return 0;
-
-err:
- fprintf(stderr,
- "--filter option should follow a -e tracepoint or HW tracer
option\n");
-
- return -1;
}
int parse_filter(const struct option *opt, const char *str,
[tip:perf/urgent] perf parser: Improve error message for PMU address filters
Commit-ID: 49836f7811f383d8613661fff110ce74f4710d52
Gitweb: https://git.kernel.org/tip/49836f7811f383d8613661fff110ce74f4710d52
Author: Jack Henschel
AuthorDate: Wed, 4 Jul 2018 14:13:45 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 20 Aug 2018 08:54:58 -0300
perf parser: Improve error message for PMU address filters
This is the second version of a patch that improves the error message of
the perf events parser when the PMU hardware does not support address
filters.
Previously, the perf returned the following error:
$ perf record -e intel_pt// --filter 'filter sys_write'
--filter option should follow a -e tracepoint or HW tracer option
This implies there is some syntax error present in the command line,
which is not true. Rather, notify the user that the CPU does not have
support for this feature.
For example, Intel chips based on the Broadwell micro-archticture have
the Intel PT PMU, but do not support address filtering.
Now, perf prints the following error message:
$ perf record -e intel_pt// --filter 'filter sys_write'
This CPU does not support address filtering
Signed-off-by: Jack Henschel
Tested-by: Arnaldo Carvalho de Melo
Acked-by: Jiri Olsa
Cc: Alexander Shishkin
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20180704121345.19025-1-jack...@mailbox.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/parse-events.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 15eec49e71a1..f8cd3e7c9186 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -1991,8 +1991,11 @@ static int set_filter(struct perf_evsel *evsel, const
void *arg)
int nr_addr_filters = 0;
struct perf_pmu *pmu = NULL;
- if (evsel == NULL)
- goto err;
+ if (evsel == NULL) {
+ fprintf(stderr,
+ "--filter option should follow a -e tracepoint or HW
tracer option\n");
+ return -1;
+ }
if (evsel->attr.type == PERF_TYPE_TRACEPOINT) {
if (perf_evsel__append_tp_filter(evsel, str) < 0) {
@@ -2014,8 +2017,11 @@ static int set_filter(struct perf_evsel *evsel, const
void *arg)
perf_pmu__scan_file(pmu, "nr_addr_filters",
"%d", _addr_filters);
- if (!nr_addr_filters)
- goto err;
+ if (!nr_addr_filters) {
+ fprintf(stderr,
+ "This CPU does not support address filtering\n");
+ return -1;
+ }
if (perf_evsel__append_addr_filter(evsel, str) < 0) {
fprintf(stderr,
@@ -2024,12 +2030,6 @@ static int set_filter(struct perf_evsel *evsel, const
void *arg)
}
return 0;
-
-err:
- fprintf(stderr,
- "--filter option should follow a -e tracepoint or HW tracer
option\n");
-
- return -1;
}
int parse_filter(const struct option *opt, const char *str,
[PATCH V4 1/3] MAINTAINERS: da7280 updates to the Dialog Semiconductor search terms
This patch adds the da7280 bindings doc and driver to the Dialog Semiconductor support list. Signed-off-by: Roy Im --- v4: No changes. v3: No changes. v2: No changes. MAINTAINERS |2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 544cac8..720f9fe 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4221,6 +4221,7 @@ S:Supported F: Documentation/hwmon/da90?? F: Documentation/devicetree/bindings/mfd/da90*.txt F: Documentation/devicetree/bindings/input/da90??-onkey.txt +F: Documentation/devicetree/bindings/input/dlg,da72??.txt F: Documentation/devicetree/bindings/thermal/da90??-thermal.txt F: Documentation/devicetree/bindings/regulator/da92*.txt F: Documentation/devicetree/bindings/watchdog/da90??-wdt.txt @@ -4229,6 +4230,7 @@ F:drivers/gpio/gpio-da90??.c F: drivers/hwmon/da90??-hwmon.c F: drivers/iio/adc/da91??-*.c F: drivers/input/misc/da90??_onkey.c +F: drivers/input/misc/da72??.[ch] F: drivers/input/touchscreen/da9052_tsi.c F: drivers/leds/leds-da90??.c F: drivers/mfd/da903x.c -- end-of-patch for PATCH V4
[PATCH V4 1/3] MAINTAINERS: da7280 updates to the Dialog Semiconductor search terms
This patch adds the da7280 bindings doc and driver to the Dialog Semiconductor support list. Signed-off-by: Roy Im --- v4: No changes. v3: No changes. v2: No changes. MAINTAINERS |2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 544cac8..720f9fe 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4221,6 +4221,7 @@ S:Supported F: Documentation/hwmon/da90?? F: Documentation/devicetree/bindings/mfd/da90*.txt F: Documentation/devicetree/bindings/input/da90??-onkey.txt +F: Documentation/devicetree/bindings/input/dlg,da72??.txt F: Documentation/devicetree/bindings/thermal/da90??-thermal.txt F: Documentation/devicetree/bindings/regulator/da92*.txt F: Documentation/devicetree/bindings/watchdog/da90??-wdt.txt @@ -4229,6 +4230,7 @@ F:drivers/gpio/gpio-da90??.c F: drivers/hwmon/da90??-hwmon.c F: drivers/iio/adc/da91??-*.c F: drivers/input/misc/da90??_onkey.c +F: drivers/input/misc/da72??.[ch] F: drivers/input/touchscreen/da9052_tsi.c F: drivers/leds/leds-da90??.c F: drivers/mfd/da903x.c -- end-of-patch for PATCH V4
[PATCH V4 3/3] Input: new da7280 haptic driver
Adds support for the Dialog DA7280 LRA/ERM Haptic Driver with
multiple mode and integrated waveform memory and wideband support.
It communicates via an I2C bus to the device.
Signed-off-by: Roy Im
---
v4: Updated code as dt-bindings are changed.
v3: No changes.
v2: Fixed kbuild error/warning
drivers/input/misc/Kconfig | 12 +
drivers/input/misc/Makefile |1 +
drivers/input/misc/da7280.c | 1438 +++
drivers/input/misc/da7280.h | 412 +
4 files changed, 1863 insertions(+)
create mode 100644 drivers/input/misc/da7280.c
create mode 100644 drivers/input/misc/da7280.h
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ca59a2b..6e0de69 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -851,4 +851,16 @@ config INPUT_SC27XX_VIBRA
To compile this driver as a module, choose M here. The module will
be called sc27xx_vibra.
+config INPUT_DA7280_HAPTICS
+ tristate "Dialog Semiconductor DA7280 haptics support"
+ depends on (INPUT && I2C && SYSFS) || PWM
+ select INPUT_FF_MEMLESS
+ select REGMAP_I2C
+ help
+ Say Y to enable support for the haptics controller on
+ Dialog DA7280 chip.
+
+ To compile this driver as a module, choose M here: the
+ module will be called da7280-haptic.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 9d0f9d1..d941348 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_INPUT_CMA3000) += cma3000_d0x.o
obj-$(CONFIG_INPUT_CMA3000_I2C)+= cma3000_d0x_i2c.o
obj-$(CONFIG_INPUT_COBALT_BTNS)+= cobalt_btns.o
obj-$(CONFIG_INPUT_CPCAP_PWRBUTTON)+= cpcap-pwrbutton.o
+obj-$(CONFIG_INPUT_DA7280_HAPTICS) += da7280.o
obj-$(CONFIG_INPUT_DA9052_ONKEY) += da9052_onkey.o
obj-$(CONFIG_INPUT_DA9055_ONKEY) += da9055_onkey.o
obj-$(CONFIG_INPUT_DA9063_ONKEY) += da9063_onkey.o
diff --git a/drivers/input/misc/da7280.c b/drivers/input/misc/da7280.c
new file mode 100644
index 000..da500ab
--- /dev/null
+++ b/drivers/input/misc/da7280.c
@@ -0,0 +1,1438 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DA7280 Haptic device driver
+ *
+ * Copyright (c) 2018 Dialog Semiconductor.
+ * Author: Roy Im
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "da7280.h"
+
+/* uV unit for voltage rate */
+#define DA7280_VOLTAGE_RATE_MAX600
+#define DA7280_VOLTAGE_RATE_STEP 23400
+#define DA7280_NOMMAX_DFT 0x6B
+#define DA7280_ABSMAX_DFT 0x78
+
+#define DA7280_IMPD_MAX15
+#define DA7280_IMPD_DEFAULT2200
+
+#define DA7280_IMAX_DEFAULT0x0E
+/* uA unit step and limit for IMAX*/
+#define DA7280_IMAX_STEP 7200
+#define DA7280_IMAX_LIMIT 252000
+
+#define DA7280_RESONT_FREQH_DFT0x39
+#define DA7280_RESONT_FREQL_DFT0x32
+#define DA7280_MIN_RESONAT_FREQ_HZ 50
+#define DA7280_MAX_RESONAT_FREQ_HZ 300
+#define DA7280_MIN_PWM_FREQ_KHZ10
+#define DA7280_MAX_PWM_FREQ_KHZ250
+
+#define DA7280_SEQ_ID_MAX 15
+#define DA7280_SEQ_LOOP_MAX15
+#define DA7280_GPI1_SEQ_ID_DEFT0x0
+
+#define DA7280_SNP_MEM_SIZE100
+#define DA7280_SNP_MEM_MAX DA7280_SNP_MEM_99
+
+#define IRQ_NUM3
+
+#define DA7280_SKIP_INIT 0x100
+
+enum da7280_haptic_dev_t {
+ DA7280_LRA = 0,
+ DA7280_ERM_BAR = 1,
+ DA7280_ERM_COIN = 2,
+ DA7280_DEV_MAX,
+};
+
+enum da7280_op_mode {
+ DA7280_INACTIVE = 0,
+ DA7280_DRO_MODE = 1,
+ DA7280_PWM_MODE = 2,
+ DA7280_RTWM_MODE= 3,
+ DA7280_ETWM_MODE= 4,
+ DA7280_OPMODE_MAX,
+};
+
+struct da7280_gpi_ctl {
+ u8 seq_id;
+ u8 mode;
+ u8 polarity;
+};
+
+struct da7280_haptic {
+ struct regmap *regmap;
+ struct input_dev *input_dev;
+ struct device *dev;
+ struct i2c_client *client;
+ struct pwm_device *pwm_dev;
+ boollegacy;
+ int pwm_id;
+ struct work_struct work;
+
+ bool suspend_state;
+ unsigned int magnitude;
+
+ u8 dev_type;
+ u8 op_mode;
+ u16 nommax;
+ u16 absmax;
+ u32 imax;
+ u32 impd;
+ u32 resonant_freq_h;
+ u32 resonant_freq_l;
+ u8 bemf_sense_en;
+ u8 freq_track_en;
+ u8 acc_en;
+ u8 rapid_stop_en;
+ u8 amp_pid_en;
+ u8 ps_seq_id;
+ u8 ps_seq_loop;
+ struct da7280_gpi_ctl gpi_ctl[3];
+ bool mem_update;
+ u8 snp_mem[DA7280_SNP_MEM_SIZE];
+ const struct attribute_group **attr_group;
+};
+
+static bool
[PATCH V4 0/3] da7280: haptic driver submission
From: Roy Im This patch adds support for the Dialog DA7280 Haptic driver IC. In this patch set the following is provided: [PATCH V2 1/3] MAINTAINERS file update for DA7280 [PATCH V2 2/3] DA7280 DT Binding [PATCH V2 3/3] DA7280 Driver This patch applies against linux-next and v4.18 Thank you, Roy Im, Dialog Semiconductor Ltd. Roy Im (3): MAINTAINERS: da7280 updates to the Dialog Semiconductor search terms dt-bindings: input: Add document bindings for DA7280 Input: new da7280 haptic driver .../devicetree/bindings/input/dlg,da7280.txt | 101 ++ MAINTAINERS|2 + drivers/input/misc/Kconfig | 12 + drivers/input/misc/Makefile|1 + drivers/input/misc/da7280.c| 1438 drivers/input/misc/da7280.h| 412 ++ 6 files changed, 1966 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/dlg,da7280.txt create mode 100644 drivers/input/misc/da7280.c create mode 100644 drivers/input/misc/da7280.h -- end-of-patch for PATCH V4
[PATCH V4 0/3] da7280: haptic driver submission
From: Roy Im This patch adds support for the Dialog DA7280 Haptic driver IC. In this patch set the following is provided: [PATCH V2 1/3] MAINTAINERS file update for DA7280 [PATCH V2 2/3] DA7280 DT Binding [PATCH V2 3/3] DA7280 Driver This patch applies against linux-next and v4.18 Thank you, Roy Im, Dialog Semiconductor Ltd. Roy Im (3): MAINTAINERS: da7280 updates to the Dialog Semiconductor search terms dt-bindings: input: Add document bindings for DA7280 Input: new da7280 haptic driver .../devicetree/bindings/input/dlg,da7280.txt | 101 ++ MAINTAINERS|2 + drivers/input/misc/Kconfig | 12 + drivers/input/misc/Makefile|1 + drivers/input/misc/da7280.c| 1438 drivers/input/misc/da7280.h| 412 ++ 6 files changed, 1966 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/dlg,da7280.txt create mode 100644 drivers/input/misc/da7280.c create mode 100644 drivers/input/misc/da7280.h -- end-of-patch for PATCH V4
[PATCH V4 3/3] Input: new da7280 haptic driver
Adds support for the Dialog DA7280 LRA/ERM Haptic Driver with
multiple mode and integrated waveform memory and wideband support.
It communicates via an I2C bus to the device.
Signed-off-by: Roy Im
---
v4: Updated code as dt-bindings are changed.
v3: No changes.
v2: Fixed kbuild error/warning
drivers/input/misc/Kconfig | 12 +
drivers/input/misc/Makefile |1 +
drivers/input/misc/da7280.c | 1438 +++
drivers/input/misc/da7280.h | 412 +
4 files changed, 1863 insertions(+)
create mode 100644 drivers/input/misc/da7280.c
create mode 100644 drivers/input/misc/da7280.h
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ca59a2b..6e0de69 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -851,4 +851,16 @@ config INPUT_SC27XX_VIBRA
To compile this driver as a module, choose M here. The module will
be called sc27xx_vibra.
+config INPUT_DA7280_HAPTICS
+ tristate "Dialog Semiconductor DA7280 haptics support"
+ depends on (INPUT && I2C && SYSFS) || PWM
+ select INPUT_FF_MEMLESS
+ select REGMAP_I2C
+ help
+ Say Y to enable support for the haptics controller on
+ Dialog DA7280 chip.
+
+ To compile this driver as a module, choose M here: the
+ module will be called da7280-haptic.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 9d0f9d1..d941348 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_INPUT_CMA3000) += cma3000_d0x.o
obj-$(CONFIG_INPUT_CMA3000_I2C)+= cma3000_d0x_i2c.o
obj-$(CONFIG_INPUT_COBALT_BTNS)+= cobalt_btns.o
obj-$(CONFIG_INPUT_CPCAP_PWRBUTTON)+= cpcap-pwrbutton.o
+obj-$(CONFIG_INPUT_DA7280_HAPTICS) += da7280.o
obj-$(CONFIG_INPUT_DA9052_ONKEY) += da9052_onkey.o
obj-$(CONFIG_INPUT_DA9055_ONKEY) += da9055_onkey.o
obj-$(CONFIG_INPUT_DA9063_ONKEY) += da9063_onkey.o
diff --git a/drivers/input/misc/da7280.c b/drivers/input/misc/da7280.c
new file mode 100644
index 000..da500ab
--- /dev/null
+++ b/drivers/input/misc/da7280.c
@@ -0,0 +1,1438 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DA7280 Haptic device driver
+ *
+ * Copyright (c) 2018 Dialog Semiconductor.
+ * Author: Roy Im
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "da7280.h"
+
+/* uV unit for voltage rate */
+#define DA7280_VOLTAGE_RATE_MAX600
+#define DA7280_VOLTAGE_RATE_STEP 23400
+#define DA7280_NOMMAX_DFT 0x6B
+#define DA7280_ABSMAX_DFT 0x78
+
+#define DA7280_IMPD_MAX15
+#define DA7280_IMPD_DEFAULT2200
+
+#define DA7280_IMAX_DEFAULT0x0E
+/* uA unit step and limit for IMAX*/
+#define DA7280_IMAX_STEP 7200
+#define DA7280_IMAX_LIMIT 252000
+
+#define DA7280_RESONT_FREQH_DFT0x39
+#define DA7280_RESONT_FREQL_DFT0x32
+#define DA7280_MIN_RESONAT_FREQ_HZ 50
+#define DA7280_MAX_RESONAT_FREQ_HZ 300
+#define DA7280_MIN_PWM_FREQ_KHZ10
+#define DA7280_MAX_PWM_FREQ_KHZ250
+
+#define DA7280_SEQ_ID_MAX 15
+#define DA7280_SEQ_LOOP_MAX15
+#define DA7280_GPI1_SEQ_ID_DEFT0x0
+
+#define DA7280_SNP_MEM_SIZE100
+#define DA7280_SNP_MEM_MAX DA7280_SNP_MEM_99
+
+#define IRQ_NUM3
+
+#define DA7280_SKIP_INIT 0x100
+
+enum da7280_haptic_dev_t {
+ DA7280_LRA = 0,
+ DA7280_ERM_BAR = 1,
+ DA7280_ERM_COIN = 2,
+ DA7280_DEV_MAX,
+};
+
+enum da7280_op_mode {
+ DA7280_INACTIVE = 0,
+ DA7280_DRO_MODE = 1,
+ DA7280_PWM_MODE = 2,
+ DA7280_RTWM_MODE= 3,
+ DA7280_ETWM_MODE= 4,
+ DA7280_OPMODE_MAX,
+};
+
+struct da7280_gpi_ctl {
+ u8 seq_id;
+ u8 mode;
+ u8 polarity;
+};
+
+struct da7280_haptic {
+ struct regmap *regmap;
+ struct input_dev *input_dev;
+ struct device *dev;
+ struct i2c_client *client;
+ struct pwm_device *pwm_dev;
+ boollegacy;
+ int pwm_id;
+ struct work_struct work;
+
+ bool suspend_state;
+ unsigned int magnitude;
+
+ u8 dev_type;
+ u8 op_mode;
+ u16 nommax;
+ u16 absmax;
+ u32 imax;
+ u32 impd;
+ u32 resonant_freq_h;
+ u32 resonant_freq_l;
+ u8 bemf_sense_en;
+ u8 freq_track_en;
+ u8 acc_en;
+ u8 rapid_stop_en;
+ u8 amp_pid_en;
+ u8 ps_seq_id;
+ u8 ps_seq_loop;
+ struct da7280_gpi_ctl gpi_ctl[3];
+ bool mem_update;
+ u8 snp_mem[DA7280_SNP_MEM_SIZE];
+ const struct attribute_group **attr_group;
+};
+
+static bool
[PATCH V4 2/3] dt-bindings: input: Add document bindings for DA7280
Add device tree binding information for DA7280 haptic driver.
Example bindings for DA7280 are added.
Signed-off-by: Roy Im
---
v4: Fixed commit message, properties.
v3: Fixed subject format.
v2: No changes
.../devicetree/bindings/input/dlg,da7280.txt | 101
1 file changed, 101 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/dlg,da7280.txt
diff --git a/Documentation/devicetree/bindings/input/dlg,da7280.txt
b/Documentation/devicetree/bindings/input/dlg,da7280.txt
new file mode 100644
index 000..a61e9f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/dlg,da7280.txt
@@ -0,0 +1,101 @@
+Dialog Semiconductor DA7280 Haptics bindings
+
+Required properties:
+- compatible: Should be "dlg,da7280".
+- reg: Specifies the I2C slave address.
+
+- interrupt-parent : Specifies the phandle of the interrupt controller to
+ which the IRQs from DA7280 are delivered to.
+
+- dlg,vib-mode:
+ "LRA-MODE" - Linear Resonance Actuator mode.
+ "ERM-BAR" - Bar type Eccentric Rotating Mass mode.
+ "ERM-COIN" - Coin type Eccentric Rotating Mass mode.
+
+- dlg,op-mode: Haptic operation mode.
+ Possible values:
+ 1 - Direct register override mode triggered by i2c(default),
+ 2 - PWM data source mode setting duty to 0 - 0x(0% - 100%),
+ 3 - Register triggered waveform memory mode, the pattern assigned
+ to the PS_SEQ_ID played as much times as PS_SEQ_LOOP,
+ 4 - Edge triggered waveform memory mode, external GPI(N) condtrol
+ are required to enable/disable and it needs to keep
+ device enabled by sending magnitude (X > 0),
+ the pattern is assigned to the GPI(N)_SEQUENCE_ID below
+ For more details, please see the datasheet.
+
+- dlg,nom-microvolt: Nominal actuator voltage rating.
+ Valid values: 0 - 600.
+- dlg,abs-max-microvolt: Absolute actuator maximum voltage rating.
+ Valid values: 0 - 600.
+- dlg,imax-microamp: Actuator max current rating.
+ Valid values: 0 - 252000.
+ Default: 13.
+- dlg,impd-micro-ohms: the impedance of the actuator in micro ohm,
+ as read from its datasheet.
+ Valid values: 0 - 15.
+
+Optional properties:
+- pwms : phandle to the physical PWM(Pulse Width Modulation) device.
+ PWM properties should be named "pwms". And number of cell is different
+ for each pwm device.
+ (See Documentation/devicetree/bindings/pwm/pwm.txt
+ for further information relating to pwm properties)
+
+- dlg,ps-seq-id: the PS_SEQ_ID(pattern ID in waveform memory inside chip)
+ to play back when RTWM-MODE is enabled.
+ Valid range: 0 - 15.
+- dlg,ps-seq-loop: the PS_SEQ_LOOP, Number of times the pre-stored sequence
+ pointed to by PS_SEQ_ID or GPI(N)_SEQUENCE_ID is repeated.
+ Valid range: 0 - 15.
+- dlg,gpiN-seq-id: the GPI(N)_SEQUENCE_ID, pattern to play
+ when gpi0 is triggered, 'N' must be 0 - 2.
+ Valid range: 0 - 15.
+- dlg,gpiN-mode: the pattern mode which can select either
+ "Single-pattern" or "Multi-pattern", 'N' must be 0 - 2.
+- dlg,gpiN-polarity: gpiN polarity which can be chosen among
+ "Rising-edge", "Falling-edge" and "Both-edge",
+ 'N' must be 0 - 2
+ Haptic will work by this edge option in case of ETWM-MODE.
+
+- dlg,resonant-freq-hz: use in case of LRA-MODE.
+ the frequency range: 50 - 300.
+ Default: 205.
+
+- dlg,bemf-sens-enable: Enable for internal loop computations.
+- dlg,freq-track-enable: Enable for resonant frequency tracking.
+- dlg,acc-enable: Enable for active acceleration.
+- dlg,rapid-stop-enable: Enable for rapid stop.
+- dlg,amp-pid-enable: Enable for the amplitude PID.
+- dlg,mem-array: use in case that memory registers should be updated,
+ Please fill the whole buffers(100 bytes) to avoid any error in driver.
+ For example,
+ dlg,mem-array = <
+ 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A
+ ...
+ 0x71 0x72 0x73 0x74 0x75 0x76 0x77 0x78 0x79 0x7A
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ >;
+
+For further information, see device datasheet.
+
+==
+
+Example:
+
+ haptics: da7280-haptics@4a {
+ compatible = "dlg,da7280";
+ reg = <0x4a>;
+ interrupt-parent = <>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ dlg,vib-mode = "LRA-MODE";
+ dlg,op-mode = <1>;
+ dlg,nom-microvolt = <200>;
+ dlg,abs-max-microvolt = <200>;
+ dlg,imax-microamp = <17>;
+ dlg,resonant-freq-hz = <180>;
+ dlg,impd-micro-ohms = <1050>;
+ dlg,freq-track-enable;
+ dlg,rapid-stop-enable;
+ };
--
end-of-patch for PATCH V4
[PATCH V4 2/3] dt-bindings: input: Add document bindings for DA7280
Add device tree binding information for DA7280 haptic driver.
Example bindings for DA7280 are added.
Signed-off-by: Roy Im
---
v4: Fixed commit message, properties.
v3: Fixed subject format.
v2: No changes
.../devicetree/bindings/input/dlg,da7280.txt | 101
1 file changed, 101 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/dlg,da7280.txt
diff --git a/Documentation/devicetree/bindings/input/dlg,da7280.txt
b/Documentation/devicetree/bindings/input/dlg,da7280.txt
new file mode 100644
index 000..a61e9f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/dlg,da7280.txt
@@ -0,0 +1,101 @@
+Dialog Semiconductor DA7280 Haptics bindings
+
+Required properties:
+- compatible: Should be "dlg,da7280".
+- reg: Specifies the I2C slave address.
+
+- interrupt-parent : Specifies the phandle of the interrupt controller to
+ which the IRQs from DA7280 are delivered to.
+
+- dlg,vib-mode:
+ "LRA-MODE" - Linear Resonance Actuator mode.
+ "ERM-BAR" - Bar type Eccentric Rotating Mass mode.
+ "ERM-COIN" - Coin type Eccentric Rotating Mass mode.
+
+- dlg,op-mode: Haptic operation mode.
+ Possible values:
+ 1 - Direct register override mode triggered by i2c(default),
+ 2 - PWM data source mode setting duty to 0 - 0x(0% - 100%),
+ 3 - Register triggered waveform memory mode, the pattern assigned
+ to the PS_SEQ_ID played as much times as PS_SEQ_LOOP,
+ 4 - Edge triggered waveform memory mode, external GPI(N) condtrol
+ are required to enable/disable and it needs to keep
+ device enabled by sending magnitude (X > 0),
+ the pattern is assigned to the GPI(N)_SEQUENCE_ID below
+ For more details, please see the datasheet.
+
+- dlg,nom-microvolt: Nominal actuator voltage rating.
+ Valid values: 0 - 600.
+- dlg,abs-max-microvolt: Absolute actuator maximum voltage rating.
+ Valid values: 0 - 600.
+- dlg,imax-microamp: Actuator max current rating.
+ Valid values: 0 - 252000.
+ Default: 13.
+- dlg,impd-micro-ohms: the impedance of the actuator in micro ohm,
+ as read from its datasheet.
+ Valid values: 0 - 15.
+
+Optional properties:
+- pwms : phandle to the physical PWM(Pulse Width Modulation) device.
+ PWM properties should be named "pwms". And number of cell is different
+ for each pwm device.
+ (See Documentation/devicetree/bindings/pwm/pwm.txt
+ for further information relating to pwm properties)
+
+- dlg,ps-seq-id: the PS_SEQ_ID(pattern ID in waveform memory inside chip)
+ to play back when RTWM-MODE is enabled.
+ Valid range: 0 - 15.
+- dlg,ps-seq-loop: the PS_SEQ_LOOP, Number of times the pre-stored sequence
+ pointed to by PS_SEQ_ID or GPI(N)_SEQUENCE_ID is repeated.
+ Valid range: 0 - 15.
+- dlg,gpiN-seq-id: the GPI(N)_SEQUENCE_ID, pattern to play
+ when gpi0 is triggered, 'N' must be 0 - 2.
+ Valid range: 0 - 15.
+- dlg,gpiN-mode: the pattern mode which can select either
+ "Single-pattern" or "Multi-pattern", 'N' must be 0 - 2.
+- dlg,gpiN-polarity: gpiN polarity which can be chosen among
+ "Rising-edge", "Falling-edge" and "Both-edge",
+ 'N' must be 0 - 2
+ Haptic will work by this edge option in case of ETWM-MODE.
+
+- dlg,resonant-freq-hz: use in case of LRA-MODE.
+ the frequency range: 50 - 300.
+ Default: 205.
+
+- dlg,bemf-sens-enable: Enable for internal loop computations.
+- dlg,freq-track-enable: Enable for resonant frequency tracking.
+- dlg,acc-enable: Enable for active acceleration.
+- dlg,rapid-stop-enable: Enable for rapid stop.
+- dlg,amp-pid-enable: Enable for the amplitude PID.
+- dlg,mem-array: use in case that memory registers should be updated,
+ Please fill the whole buffers(100 bytes) to avoid any error in driver.
+ For example,
+ dlg,mem-array = <
+ 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A
+ ...
+ 0x71 0x72 0x73 0x74 0x75 0x76 0x77 0x78 0x79 0x7A
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ >;
+
+For further information, see device datasheet.
+
+==
+
+Example:
+
+ haptics: da7280-haptics@4a {
+ compatible = "dlg,da7280";
+ reg = <0x4a>;
+ interrupt-parent = <>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ dlg,vib-mode = "LRA-MODE";
+ dlg,op-mode = <1>;
+ dlg,nom-microvolt = <200>;
+ dlg,abs-max-microvolt = <200>;
+ dlg,imax-microamp = <17>;
+ dlg,resonant-freq-hz = <180>;
+ dlg,impd-micro-ohms = <1050>;
+ dlg,freq-track-enable;
+ dlg,rapid-stop-enable;
+ };
--
end-of-patch for PATCH V4
Re: [RFC PATCH 1/2] dt-bindings: pwm: imx: Allow switching PWM output between PWM and GPIO
On 22.8.2018 16:10, Lothar Waßmann wrote:
Michal Vokáč wrote:
On 22.8.2018 13:17, Lothar Waßmann wrote:
Michal Vokáč wrote:
On 22.8.2018 08:14, Lothar Waßmann wrote:
Michal Vokáč wrote:
Output of the PWM block of i.MX SoCs is always zero volts when the block
is disabled. This can caue issues when inverted PWM polarity is needed.
With inverted polarity a duty cycle = 0% corresponds to solid high level
on the output. If the PWM is dissabled its output instantly goes to solid
zero which corresponds to duty cycle = 100%.
To have a trully inverted PWM output configure the PWM pad as a GPIO
with pull-up. Then switch the pad to PWM output whenever non-zero
duty cycle is needed.
Signed-off-by: Michal Vokáč
---
Documentation/devicetree/bindings/pwm/imx-pwm.txt | 44
+++
1 file changed, 44 insertions(+)
diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
index c61bdf8..3b1bc4c 100644
--- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
@@ -14,6 +14,12 @@ See the clock consumer binding,
Documentation/devicetree/bindings/clock/clock-bindings.txt
- interrupts: The interrupt for the pwm controller
+Optional properties:
+- pinctrl: For i.MX27 and newer SoCs. Add extra pinctrl to configure the PWM
+ pin to gpio function. It allows control over the pin output level when the
+ PWM block is disabled. This is meant to be used if inverted polarity of the
+ PWM signal is required. See "Inverted PWM output" section bellow.
+
Example:
pwm1: pwm@53fb4000 {
@@ -25,3 +31,41 @@ pwm1: pwm@53fb4000 {
clock-names = "ipg", "per";
interrupts = <61>;
};
+
+Inverted PWM output
+---
+
+The i.MX SoC has such limitation that whenever a pad is configured as a PWM
+output, the output level is always zero volts when the PWM block is disabled.
+The zero output level is actively driven by the output stage of the PWM block
+and can not be overridden by pull-up. It also does not matter what PWM polarity
+a PWM client (e.g. backlight) requested.
+
+To gain control of the PWM output level in disabled state two pinctrl states
+can be used. The "default" state and the "pwm" state. In the default state the
The "default" function of a PWM is to deliver a PWM signal. So it is
more sensible to me to have the PWM function as "default" and a "gpio"
function as alternative state.
Yes, I totally agree that using "default" for PWM and "gpio" as the
alternative function seems more sensible. That is actually how I started.
Then I realized that that way you end up with the PWM pad set to zero
until the first call of imx_pwm_apply_v2 where you can select the GPIO
function. On my system that first call is made by pwm-backlight more than
3s after pinctrl init.
I suggested to use the "default" state as a GPIO function as the only way
how to get a truly inverted PWM output all the time from power-up to
power-down.
In my opinion it is up to the DT author what pad configuration he uses for
each pinctrl function as he knows what the HW really needs. I see that this
approach is kind of controversial but I hope that with good documentation
this would not be a problem. And as I wrote in the intro, it is absolutely
optional. If you do not need it, you do not use it.
This is OK so far.
But the approach with the pin being driven high via the pullup
configuration has a fundamental flaw:
The pwm polarity is specified by the PWM client (e.g: the pwm-backlight
driver:
pwms = < 0 PWM_POLARITY_INVERTED>;
)
The pinconfig is defined in the pinctrl of the PWM driver.
If you have clients that may use the same PWM instance and require
different polarity, there is no way to set the pullup/-down
configuration in accordance with the clients needs.
Hmm, I did not think about more than one PWM client. Is it even possible
to design such board? Do you have an example of such usage? It would mean
My use case is attaching different displays to the same baseboard,
where some displays have the brightness control pin inverted with
respect to the others. It's easy to change the compatible string for
the simple-panel driver and the PWM polarity setting for the
pwm-backlight driver from U-Boot according to the display model, but
it's not so easy, to edit the pinctrl settings from pull-up to
pull-down or vice versa.
OK, I got it. Though that is something different than having two clients,
right?
You do not actually need to change the pinctrl pull-up/down configuration
in bootloader. You define the two pinctrl groups as I suggested in the
example. Or more precisely, you add a new pinctrl group where the PWM
output pad is configured as a GPIO with pull-up. You add this group to
all your common device trees. This does no harm as the group is not used
yet.
In bootloader you detect the type of the panel. Normal PWM polarity? OK,
do
Re: [RFC PATCH 1/2] dt-bindings: pwm: imx: Allow switching PWM output between PWM and GPIO
On 22.8.2018 16:10, Lothar Waßmann wrote:
Michal Vokáč wrote:
On 22.8.2018 13:17, Lothar Waßmann wrote:
Michal Vokáč wrote:
On 22.8.2018 08:14, Lothar Waßmann wrote:
Michal Vokáč wrote:
Output of the PWM block of i.MX SoCs is always zero volts when the block
is disabled. This can caue issues when inverted PWM polarity is needed.
With inverted polarity a duty cycle = 0% corresponds to solid high level
on the output. If the PWM is dissabled its output instantly goes to solid
zero which corresponds to duty cycle = 100%.
To have a trully inverted PWM output configure the PWM pad as a GPIO
with pull-up. Then switch the pad to PWM output whenever non-zero
duty cycle is needed.
Signed-off-by: Michal Vokáč
---
Documentation/devicetree/bindings/pwm/imx-pwm.txt | 44
+++
1 file changed, 44 insertions(+)
diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
index c61bdf8..3b1bc4c 100644
--- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
@@ -14,6 +14,12 @@ See the clock consumer binding,
Documentation/devicetree/bindings/clock/clock-bindings.txt
- interrupts: The interrupt for the pwm controller
+Optional properties:
+- pinctrl: For i.MX27 and newer SoCs. Add extra pinctrl to configure the PWM
+ pin to gpio function. It allows control over the pin output level when the
+ PWM block is disabled. This is meant to be used if inverted polarity of the
+ PWM signal is required. See "Inverted PWM output" section bellow.
+
Example:
pwm1: pwm@53fb4000 {
@@ -25,3 +31,41 @@ pwm1: pwm@53fb4000 {
clock-names = "ipg", "per";
interrupts = <61>;
};
+
+Inverted PWM output
+---
+
+The i.MX SoC has such limitation that whenever a pad is configured as a PWM
+output, the output level is always zero volts when the PWM block is disabled.
+The zero output level is actively driven by the output stage of the PWM block
+and can not be overridden by pull-up. It also does not matter what PWM polarity
+a PWM client (e.g. backlight) requested.
+
+To gain control of the PWM output level in disabled state two pinctrl states
+can be used. The "default" state and the "pwm" state. In the default state the
The "default" function of a PWM is to deliver a PWM signal. So it is
more sensible to me to have the PWM function as "default" and a "gpio"
function as alternative state.
Yes, I totally agree that using "default" for PWM and "gpio" as the
alternative function seems more sensible. That is actually how I started.
Then I realized that that way you end up with the PWM pad set to zero
until the first call of imx_pwm_apply_v2 where you can select the GPIO
function. On my system that first call is made by pwm-backlight more than
3s after pinctrl init.
I suggested to use the "default" state as a GPIO function as the only way
how to get a truly inverted PWM output all the time from power-up to
power-down.
In my opinion it is up to the DT author what pad configuration he uses for
each pinctrl function as he knows what the HW really needs. I see that this
approach is kind of controversial but I hope that with good documentation
this would not be a problem. And as I wrote in the intro, it is absolutely
optional. If you do not need it, you do not use it.
This is OK so far.
But the approach with the pin being driven high via the pullup
configuration has a fundamental flaw:
The pwm polarity is specified by the PWM client (e.g: the pwm-backlight
driver:
pwms = < 0 PWM_POLARITY_INVERTED>;
)
The pinconfig is defined in the pinctrl of the PWM driver.
If you have clients that may use the same PWM instance and require
different polarity, there is no way to set the pullup/-down
configuration in accordance with the clients needs.
Hmm, I did not think about more than one PWM client. Is it even possible
to design such board? Do you have an example of such usage? It would mean
My use case is attaching different displays to the same baseboard,
where some displays have the brightness control pin inverted with
respect to the others. It's easy to change the compatible string for
the simple-panel driver and the PWM polarity setting for the
pwm-backlight driver from U-Boot according to the display model, but
it's not so easy, to edit the pinctrl settings from pull-up to
pull-down or vice versa.
OK, I got it. Though that is something different than having two clients,
right?
You do not actually need to change the pinctrl pull-up/down configuration
in bootloader. You define the two pinctrl groups as I suggested in the
example. Or more precisely, you add a new pinctrl group where the PWM
output pad is configured as a GPIO with pull-up. You add this group to
all your common device trees. This does no harm as the group is not used
yet.
In bootloader you detect the type of the panel. Normal PWM polarity? OK,
do
[PATCH 4.17 089/324] irqchip/gic-v2m: Fix SPI release on error path
4.17-stable review patch. If anyone has any objections, please let me know.
--
From: Marc Zyngier
[ Upstream commit cbaf45a6be497c272e80500e4fd9bccdf20d5050 ]
On failing to allocate the required SPIs, the actual number of interrupts
should be freed and not its log2 value.
Fixes: de337ee30142 ("irqchip/gic-v2m: Add PCI Multi-MSI support")
Signed-off-by: Marc Zyngier
Signed-off-by: Thomas Gleixner
Cc: Jason Cooper
Cc: Alexandre Belloni
Cc: Yang Yingliang
Cc: Sumit Garg
Link: https://lkml.kernel.org/r/20180622095254.5906-4-marc.zyng...@arm.com
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/irqchip/irq-gic-v2m.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/irqchip/irq-gic-v2m.c
+++ b/drivers/irqchip/irq-gic-v2m.c
@@ -199,7 +199,7 @@ static int gicv2m_irq_domain_alloc(struc
fail:
irq_domain_free_irqs_parent(domain, virq, nr_irqs);
- gicv2m_unalloc_msi(v2m, hwirq, get_count_order(nr_irqs));
+ gicv2m_unalloc_msi(v2m, hwirq, nr_irqs);
return err;
}
[PATCH 4.17 089/324] irqchip/gic-v2m: Fix SPI release on error path
4.17-stable review patch. If anyone has any objections, please let me know.
--
From: Marc Zyngier
[ Upstream commit cbaf45a6be497c272e80500e4fd9bccdf20d5050 ]
On failing to allocate the required SPIs, the actual number of interrupts
should be freed and not its log2 value.
Fixes: de337ee30142 ("irqchip/gic-v2m: Add PCI Multi-MSI support")
Signed-off-by: Marc Zyngier
Signed-off-by: Thomas Gleixner
Cc: Jason Cooper
Cc: Alexandre Belloni
Cc: Yang Yingliang
Cc: Sumit Garg
Link: https://lkml.kernel.org/r/20180622095254.5906-4-marc.zyng...@arm.com
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/irqchip/irq-gic-v2m.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/irqchip/irq-gic-v2m.c
+++ b/drivers/irqchip/irq-gic-v2m.c
@@ -199,7 +199,7 @@ static int gicv2m_irq_domain_alloc(struc
fail:
irq_domain_free_irqs_parent(domain, virq, nr_irqs);
- gicv2m_unalloc_msi(v2m, hwirq, get_count_order(nr_irqs));
+ gicv2m_unalloc_msi(v2m, hwirq, nr_irqs);
return err;
}
[PATCH 4.9 095/130] bnxt_en: Fix for system hang if request_irq fails
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Vikas Gupta
[ Upstream commit c58387ab1614f6d7fb9e244f214b61e7631421fc ]
Fix bug in the error code path when bnxt_request_irq() returns failure.
bnxt_disable_napi() should not be called in this error path because
NAPI has not been enabled yet.
Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
Signed-off-by: Vikas Gupta
Signed-off-by: Michael Chan
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -5560,7 +5560,7 @@ static int __bnxt_open_nic(struct bnxt *
rc = bnxt_request_irq(bp);
if (rc) {
netdev_err(bp->dev, "bnxt_request_irq err: %x\n", rc);
- goto open_err;
+ goto open_err_irq;
}
}
@@ -5593,6 +5593,8 @@ static int __bnxt_open_nic(struct bnxt *
open_err:
bnxt_disable_napi(bp);
+
+open_err_irq:
bnxt_del_napi(bp);
open_err_free_mem:
[PATCH 4.14 062/217] nvmet: reset keep alive timer in controller enable
4.14-stable review patch. If anyone has any objections, please let me know. -- From: Max Gurtuvoy [ Upstream commit d68a90e148f5a82aa67654c5012071e31c0e4baa ] Controllers that are not yet enabled should not really enforce keep alive timeouts, but we still want to track a timeout and cleanup in case a host died before it enabled the controller. Hence, simply reset the keep alive timer when the controller is enabled. Suggested-by: Max Gurtovoy Signed-off-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/nvme/target/core.c |8 1 file changed, 8 insertions(+) --- a/drivers/nvme/target/core.c +++ b/drivers/nvme/target/core.c @@ -598,6 +598,14 @@ static void nvmet_start_ctrl(struct nvme } ctrl->csts = NVME_CSTS_RDY; + + /* +* Controllers that are not yet enabled should not really enforce the +* keep alive timeout, but we still want to track a timeout and cleanup +* in case a host died before it enabled the controller. Hence, simply +* reset the keep alive timer when the controller is enabled. +*/ + mod_delayed_work(system_wq, >ka_work, ctrl->kato * HZ); } static void nvmet_clear_ctrl(struct nvmet_ctrl *ctrl)
[PATCH 4.14 062/217] nvmet: reset keep alive timer in controller enable
4.14-stable review patch. If anyone has any objections, please let me know. -- From: Max Gurtuvoy [ Upstream commit d68a90e148f5a82aa67654c5012071e31c0e4baa ] Controllers that are not yet enabled should not really enforce keep alive timeouts, but we still want to track a timeout and cleanup in case a host died before it enabled the controller. Hence, simply reset the keep alive timer when the controller is enabled. Suggested-by: Max Gurtovoy Signed-off-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/nvme/target/core.c |8 1 file changed, 8 insertions(+) --- a/drivers/nvme/target/core.c +++ b/drivers/nvme/target/core.c @@ -598,6 +598,14 @@ static void nvmet_start_ctrl(struct nvme } ctrl->csts = NVME_CSTS_RDY; + + /* +* Controllers that are not yet enabled should not really enforce the +* keep alive timeout, but we still want to track a timeout and cleanup +* in case a host died before it enabled the controller. Hence, simply +* reset the keep alive timer when the controller is enabled. +*/ + mod_delayed_work(system_wq, >ka_work, ctrl->kato * HZ); } static void nvmet_clear_ctrl(struct nvmet_ctrl *ctrl)
[PATCH 4.9 095/130] bnxt_en: Fix for system hang if request_irq fails
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Vikas Gupta
[ Upstream commit c58387ab1614f6d7fb9e244f214b61e7631421fc ]
Fix bug in the error code path when bnxt_request_irq() returns failure.
bnxt_disable_napi() should not be called in this error path because
NAPI has not been enabled yet.
Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
Signed-off-by: Vikas Gupta
Signed-off-by: Michael Chan
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -5560,7 +5560,7 @@ static int __bnxt_open_nic(struct bnxt *
rc = bnxt_request_irq(bp);
if (rc) {
netdev_err(bp->dev, "bnxt_request_irq err: %x\n", rc);
- goto open_err;
+ goto open_err_irq;
}
}
@@ -5593,6 +5593,8 @@ static int __bnxt_open_nic(struct bnxt *
open_err:
bnxt_disable_napi(bp);
+
+open_err_irq:
bnxt_del_napi(bp);
open_err_free_mem:
[PATCH 4.17 294/324] ACPI / EC: Use ec_no_wakeup on more Thinkpad X1 Carbon 6th systems
4.17-stable review patch. If anyone has any objections, please let me know.
--
From: "Robin H. Johnson"
[ Upstream commit 2c4d6baf1bc4f7729773ffcee9ba2a9781578633 ]
The ec_no_wakeup matcher added for Thinkpad X1 Carbon 6th gen systems
beyond matched only a single DMI model (20KGS3JF01), that didn't cover
my laptop (20KH002JUS). Change to match based on DMI product family to
cover all X1 6th gen systems.
Signed-off-by: Robin H. Johnson
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/acpi/ec.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -2036,7 +2036,7 @@ static const struct dmi_system_id acpi_e
.ident = "Thinkpad X1 Carbon 6th",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
- DMI_MATCH(DMI_PRODUCT_NAME, "20KGS3JF01"),
+ DMI_MATCH(DMI_PRODUCT_FAMILY, "Thinkpad X1 Carbon 6th"),
},
},
{ },
[PATCH 4.17 163/324] objtool: Support GCC 8 -fnoreorder-functions
4.17-stable review patch. If anyone has any objections, please let me know.
--
From: Josh Poimboeuf
[ Upstream commit 08b393d01c88aff27347ed2b1b354eb4db2f1532 ]
Since the following commit:
cd77849a69cf ("objtool: Fix GCC 8 cold subfunction detection for aliased
functions")
... if the kernel is built with EXTRA_CFLAGS='-fno-reorder-functions',
objtool can get stuck in an infinite loop.
That flag causes the new GCC 8 cold subfunctions to be placed in .text
instead of .text.unlikely. But it also has an unfortunate quirk: in the
symbol table, the subfunction (e.g., nmi_panic.cold.7) is nested inside
the parent (nmi_panic).
That function overlap confuses objtool, and causes it to get into an
infinite loop in next_insn_same_func(). Here's Allan's description of
the loop:
"Objtool iterates through the instructions in nmi_panic using
next_insn_same_func. Once it reaches the end of nmi_panic at 0x534 it
jumps to 0x528 as that's the start of nmi_panic.cold.7. However, since
the instructions starting at 0x528 are still associated with nmi_panic
objtool will get stuck in a loop, continually jumping back to 0x528
after reaching 0x534."
Fix it by shortening the length of the parent function so that the
functions no longer overlap.
Reported-and-analyzed-by: Allan Xavier
Signed-off-by: Josh Poimboeuf
Cc: Allan Xavier
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/9e704c52bee651129b036be14feda317ae5606ae.1530136978.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
tools/objtool/elf.c | 37 ++---
1 file changed, 26 insertions(+), 11 deletions(-)
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -302,19 +302,34 @@ static int read_symbols(struct elf *elf)
continue;
sym->pfunc = sym->cfunc = sym;
coldstr = strstr(sym->name, ".cold.");
- if (coldstr) {
- coldstr[0] = '\0';
- pfunc = find_symbol_by_name(elf, sym->name);
- coldstr[0] = '.';
+ if (!coldstr)
+ continue;
+
+ coldstr[0] = '\0';
+ pfunc = find_symbol_by_name(elf, sym->name);
+ coldstr[0] = '.';
+
+ if (!pfunc) {
+ WARN("%s(): can't find parent function",
+sym->name);
+ goto err;
+ }
- if (!pfunc) {
- WARN("%s(): can't find parent function",
-sym->name);
- goto err;
- }
+ sym->pfunc = pfunc;
+ pfunc->cfunc = sym;
- sym->pfunc = pfunc;
- pfunc->cfunc = sym;
+ /*
+* Unfortunately, -fnoreorder-functions puts the child
+* inside the parent. Remove the overlap so we can
+* have sane assumptions.
+*
+* Note that pfunc->len now no longer matches
+* pfunc->sym.st_size.
+*/
+ if (sym->sec == pfunc->sec &&
+ sym->offset >= pfunc->offset &&
+ sym->offset + sym->len == pfunc->offset +
pfunc->len) {
+ pfunc->len -= sym->len;
}
}
}
[PATCH 4.9 094/130] bnxt_en: Always set output parameters in bnxt_get_max_rings().
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Michael Chan
[ Upstream commit 78f058a4aa0f2280dc4d45d2c4a95728398ef857 ]
The current code returns -ENOMEM and does not bother to set the output
parameters to 0 when no rings are available. Some callers, such as
bnxt_get_channels() will display garbage ring numbers when that happens.
Fix it by always setting the output parameters.
Fixes: 6e6c5a57fbe1 ("bnxt_en: Modify bnxt_get_max_rings() to support shared or
non shared rings.")
Signed-off-by: Michael Chan
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -6862,11 +6862,11 @@ int bnxt_get_max_rings(struct bnxt *bp,
int rx, tx, cp;
_bnxt_get_max_rings(bp, , , );
+ *max_rx = rx;
+ *max_tx = tx;
if (!rx || !tx || !cp)
return -ENOMEM;
- *max_rx = rx;
- *max_tx = tx;
return bnxt_trim_rings(bp, max_rx, max_tx, cp, shared);
}
[PATCH 4.17 294/324] ACPI / EC: Use ec_no_wakeup on more Thinkpad X1 Carbon 6th systems
4.17-stable review patch. If anyone has any objections, please let me know.
--
From: "Robin H. Johnson"
[ Upstream commit 2c4d6baf1bc4f7729773ffcee9ba2a9781578633 ]
The ec_no_wakeup matcher added for Thinkpad X1 Carbon 6th gen systems
beyond matched only a single DMI model (20KGS3JF01), that didn't cover
my laptop (20KH002JUS). Change to match based on DMI product family to
cover all X1 6th gen systems.
Signed-off-by: Robin H. Johnson
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/acpi/ec.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -2036,7 +2036,7 @@ static const struct dmi_system_id acpi_e
.ident = "Thinkpad X1 Carbon 6th",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
- DMI_MATCH(DMI_PRODUCT_NAME, "20KGS3JF01"),
+ DMI_MATCH(DMI_PRODUCT_FAMILY, "Thinkpad X1 Carbon 6th"),
},
},
{ },
[PATCH 4.17 163/324] objtool: Support GCC 8 -fnoreorder-functions
4.17-stable review patch. If anyone has any objections, please let me know.
--
From: Josh Poimboeuf
[ Upstream commit 08b393d01c88aff27347ed2b1b354eb4db2f1532 ]
Since the following commit:
cd77849a69cf ("objtool: Fix GCC 8 cold subfunction detection for aliased
functions")
... if the kernel is built with EXTRA_CFLAGS='-fno-reorder-functions',
objtool can get stuck in an infinite loop.
That flag causes the new GCC 8 cold subfunctions to be placed in .text
instead of .text.unlikely. But it also has an unfortunate quirk: in the
symbol table, the subfunction (e.g., nmi_panic.cold.7) is nested inside
the parent (nmi_panic).
That function overlap confuses objtool, and causes it to get into an
infinite loop in next_insn_same_func(). Here's Allan's description of
the loop:
"Objtool iterates through the instructions in nmi_panic using
next_insn_same_func. Once it reaches the end of nmi_panic at 0x534 it
jumps to 0x528 as that's the start of nmi_panic.cold.7. However, since
the instructions starting at 0x528 are still associated with nmi_panic
objtool will get stuck in a loop, continually jumping back to 0x528
after reaching 0x534."
Fix it by shortening the length of the parent function so that the
functions no longer overlap.
Reported-and-analyzed-by: Allan Xavier
Signed-off-by: Josh Poimboeuf
Cc: Allan Xavier
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/9e704c52bee651129b036be14feda317ae5606ae.1530136978.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
tools/objtool/elf.c | 37 ++---
1 file changed, 26 insertions(+), 11 deletions(-)
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -302,19 +302,34 @@ static int read_symbols(struct elf *elf)
continue;
sym->pfunc = sym->cfunc = sym;
coldstr = strstr(sym->name, ".cold.");
- if (coldstr) {
- coldstr[0] = '\0';
- pfunc = find_symbol_by_name(elf, sym->name);
- coldstr[0] = '.';
+ if (!coldstr)
+ continue;
+
+ coldstr[0] = '\0';
+ pfunc = find_symbol_by_name(elf, sym->name);
+ coldstr[0] = '.';
+
+ if (!pfunc) {
+ WARN("%s(): can't find parent function",
+sym->name);
+ goto err;
+ }
- if (!pfunc) {
- WARN("%s(): can't find parent function",
-sym->name);
- goto err;
- }
+ sym->pfunc = pfunc;
+ pfunc->cfunc = sym;
- sym->pfunc = pfunc;
- pfunc->cfunc = sym;
+ /*
+* Unfortunately, -fnoreorder-functions puts the child
+* inside the parent. Remove the overlap so we can
+* have sane assumptions.
+*
+* Note that pfunc->len now no longer matches
+* pfunc->sym.st_size.
+*/
+ if (sym->sec == pfunc->sec &&
+ sym->offset >= pfunc->offset &&
+ sym->offset + sym->len == pfunc->offset +
pfunc->len) {
+ pfunc->len -= sym->len;
}
}
}
[PATCH 4.9 094/130] bnxt_en: Always set output parameters in bnxt_get_max_rings().
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Michael Chan
[ Upstream commit 78f058a4aa0f2280dc4d45d2c4a95728398ef857 ]
The current code returns -ENOMEM and does not bother to set the output
parameters to 0 when no rings are available. Some callers, such as
bnxt_get_channels() will display garbage ring numbers when that happens.
Fix it by always setting the output parameters.
Fixes: 6e6c5a57fbe1 ("bnxt_en: Modify bnxt_get_max_rings() to support shared or
non shared rings.")
Signed-off-by: Michael Chan
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -6862,11 +6862,11 @@ int bnxt_get_max_rings(struct bnxt *bp,
int rx, tx, cp;
_bnxt_get_max_rings(bp, , , );
+ *max_rx = rx;
+ *max_tx = tx;
if (!rx || !tx || !cp)
return -ENOMEM;
- *max_rx = rx;
- *max_tx = tx;
return bnxt_trim_rings(bp, max_rx, max_tx, cp, shared);
}
[PATCH 4.14 101/217] selftests/x86/sigreturn/64: Fix spurious failures on AMD CPUs
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Andy Lutomirski
[ Upstream commit ec348020566009d3da9b99f07c05814d13969c78 ]
When I wrote the sigreturn test, I didn't realize that AMD's busted
IRET behavior was different from Intel's busted IRET behavior:
On AMD CPUs, the CPU leaks the high 32 bits of the kernel stack pointer
to certain userspace contexts. Gee, thanks. There's very little
the kernel can do about it. Modify the test so it passes.
Signed-off-by: Andy Lutomirski
Cc: Borislav Petkov
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/86e7fd3564497f657de30a36da4505799eebef01.1530076529.git.l...@kernel.org
Signed-off-by: Ingo Molnar
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
tools/testing/selftests/x86/sigreturn.c | 46
1 file changed, 29 insertions(+), 17 deletions(-)
--- a/tools/testing/selftests/x86/sigreturn.c
+++ b/tools/testing/selftests/x86/sigreturn.c
@@ -612,19 +612,38 @@ static int test_valid_sigreturn(int cs_b
greg_t req = requested_regs[i], res = resulting_regs[i];
if (i == REG_TRAPNO || i == REG_IP)
continue; /* don't care */
- if (i == REG_SP) {
- printf("\tSP: %llx -> %llx\n", (unsigned long long)req,
- (unsigned long long)res);
+ if (i == REG_SP) {
/*
-* In many circumstances, the high 32 bits of rsp
-* are zeroed. For example, we could be a real
-* 32-bit program, or we could hit any of a number
-* of poorly-documented IRET or segmented ESP
-* oddities. If this happens, it's okay.
+* If we were using a 16-bit stack segment, then
+* the kernel is a bit stuck: IRET only restores
+* the low 16 bits of ESP/RSP if SS is 16-bit.
+* The kernel uses a hack to restore bits 31:16,
+* but that hack doesn't help with bits 63:32.
+* On Intel CPUs, bits 63:32 end up zeroed, and, on
+* AMD CPUs, they leak the high bits of the kernel
+* espfix64 stack pointer. There's very little that
+* the kernel can do about it.
+*
+* Similarly, if we are returning to a 32-bit context,
+* the CPU will often lose the high 32 bits of RSP.
*/
- if (res == (req & 0x))
- continue; /* OK; not expected to work */
+
+ if (res == req)
+ continue;
+
+ if (cs_bits != 64 && ((res ^ req) & 0x) == 0) {
+ printf("[NOTE]\tSP: %llx -> %llx\n",
+ (unsigned long long)req,
+ (unsigned long long)res);
+ continue;
+ }
+
+ printf("[FAIL]\tSP mismatch: requested 0x%llx; got
0x%llx\n",
+ (unsigned long long)requested_regs[i],
+ (unsigned long long)resulting_regs[i]);
+ nerrs++;
+ continue;
}
bool ignore_reg = false;
@@ -663,13 +682,6 @@ static int test_valid_sigreturn(int cs_b
}
if (requested_regs[i] != resulting_regs[i] && !ignore_reg) {
- /*
-* SP is particularly interesting here. The
-* usual cause of failures is that we hit the
-* nasty IRET case of returning to a 16-bit SS,
-* in which case bits 16:31 of the *kernel*
-* stack pointer persist in ESP.
-*/
printf("[FAIL]\tReg %d mismatch: requested 0x%llx; got
0x%llx\n",
i, (unsigned long long)requested_regs[i],
(unsigned long long)resulting_regs[i]);
[PATCH 4.14 075/217] Smack: Mark inode instant in smack_task_to_inode
4.14-stable review patch. If anyone has any objections, please let me know. -- From: Casey Schaufler [ Upstream commit 7b4e88434c4e7982fb053c49657e1c8bbb8692d9 ] Smack: Mark inode instant in smack_task_to_inode /proc clean-up in commit 1bbc55131e59bd099fdc568d3aa0b42634dbd188 resulted in smack_task_to_inode() being called before smack_d_instantiate. This resulted in the smk_inode value being ignored, even while present for files in /proc/self. Marking the inode as instant here fixes that. Signed-off-by: Casey Schaufler Signed-off-by: James Morris Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- security/smack/smack_lsm.c |1 + 1 file changed, 1 insertion(+) --- a/security/smack/smack_lsm.c +++ b/security/smack/smack_lsm.c @@ -2281,6 +2281,7 @@ static void smack_task_to_inode(struct t struct smack_known *skp = smk_of_task_struct(p); isp->smk_inode = skp; + isp->smk_flags |= SMK_INODE_INSTANT; } /*
[PATCH 4.14 206/217] netfilter: conntrack: dccp: treat SYNC/SYNCACK as invalid if no prior state
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Florian Westphal
commit 6613b6173dee098997229caf1f3b961c49da75e6 upstream.
When first DCCP packet is SYNC or SYNCACK, we insert a new conntrack
that has an un-initialized timeout value, i.e. such entry could be
reaped at any time.
Mark them as INVALID and only ignore SYNC/SYNCACK when connection had
an old state.
Reported-by: syzbot+6f18401420df260e3...@syzkaller.appspotmail.com
Signed-off-by: Florian Westphal
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Greg Kroah-Hartman
---
net/netfilter/nf_conntrack_proto_dccp.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/net/netfilter/nf_conntrack_proto_dccp.c
+++ b/net/netfilter/nf_conntrack_proto_dccp.c
@@ -243,14 +243,14 @@ dccp_state_table[CT_DCCP_ROLE_MAX + 1][D
* We currently ignore Sync packets
*
* sNO, sRQ, sRS, sPO, sOP, sCR, sCG, sTW */
- sIG, sIG, sIG, sIG, sIG, sIG, sIG, sIG,
+ sIV, sIG, sIG, sIG, sIG, sIG, sIG, sIG,
},
[DCCP_PKT_SYNCACK] = {
/*
* We currently ignore SyncAck packets
*
* sNO, sRQ, sRS, sPO, sOP, sCR, sCG, sTW */
- sIG, sIG, sIG, sIG, sIG, sIG, sIG, sIG,
+ sIV, sIG, sIG, sIG, sIG, sIG, sIG, sIG,
},
},
[CT_DCCP_ROLE_SERVER] = {
@@ -371,14 +371,14 @@ dccp_state_table[CT_DCCP_ROLE_MAX + 1][D
* We currently ignore Sync packets
*
* sNO, sRQ, sRS, sPO, sOP, sCR, sCG, sTW */
- sIG, sIG, sIG, sIG, sIG, sIG, sIG, sIG,
+ sIV, sIG, sIG, sIG, sIG, sIG, sIG, sIG,
},
[DCCP_PKT_SYNCACK] = {
/*
* We currently ignore SyncAck packets
*
* sNO, sRQ, sRS, sPO, sOP, sCR, sCG, sTW */
- sIG, sIG, sIG, sIG, sIG, sIG, sIG, sIG,
+ sIV, sIG, sIG, sIG, sIG, sIG, sIG, sIG,
},
},
};
[PATCH 4.14 205/217] xfrm_user: prevent leaking 2 bytes of kernel memory
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
commit 45c180bc29babbedd6b8c01b975780ef44d9d09c upstream.
struct xfrm_userpolicy_type has two holes, so we should not
use C99 style initializer.
KMSAN report:
BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:140 [inline]
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x1b14/0x2800 lib/iov_iter.c:571
CPU: 1 PID: 4520 Comm: syz-executor841 Not tainted 4.17.0+ #5
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:113
kmsan_report+0x188/0x2a0 mm/kmsan/kmsan.c:1117
kmsan_internal_check_memory+0x138/0x1f0 mm/kmsan/kmsan.c:1211
kmsan_copy_to_user+0x7a/0x160 mm/kmsan/kmsan.c:1253
copyout lib/iov_iter.c:140 [inline]
_copy_to_iter+0x1b14/0x2800 lib/iov_iter.c:571
copy_to_iter include/linux/uio.h:106 [inline]
skb_copy_datagram_iter+0x422/0xfa0 net/core/datagram.c:431
skb_copy_datagram_msg include/linux/skbuff.h:3268 [inline]
netlink_recvmsg+0x6f1/0x1900 net/netlink/af_netlink.c:1959
sock_recvmsg_nosec net/socket.c:802 [inline]
sock_recvmsg+0x1d6/0x230 net/socket.c:809
___sys_recvmsg+0x3fe/0x810 net/socket.c:2279
__sys_recvmmsg+0x58e/0xe30 net/socket.c:2391
do_sys_recvmmsg+0x2a6/0x3e0 net/socket.c:2472
__do_sys_recvmmsg net/socket.c:2485 [inline]
__se_sys_recvmmsg net/socket.c:2481 [inline]
__x64_sys_recvmmsg+0x15d/0x1c0 net/socket.c:2481
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x446ce9
RSP: 002b:7fc307918db8 EFLAGS: 0293 ORIG_RAX: 012b
RAX: ffda RBX: 006dbc24 RCX: 00446ce9
RDX: 000a RSI: 20005040 RDI: 0003
RBP: 006dbc20 R08: 20004e40 R09:
R10: 4000 R11: 0293 R12:
R13: 7ffc8d2df32f R14: 7fc3079199c0 R15: 0001
Uninit was stored to memory at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:279 [inline]
kmsan_save_stack mm/kmsan/kmsan.c:294 [inline]
kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:685
kmsan_memcpy_origins+0x11d/0x170 mm/kmsan/kmsan.c:527
__msan_memcpy+0x109/0x160 mm/kmsan/kmsan_instr.c:413
__nla_put lib/nlattr.c:569 [inline]
nla_put+0x276/0x340 lib/nlattr.c:627
copy_to_user_policy_type net/xfrm/xfrm_user.c:1678 [inline]
dump_one_policy+0xbe1/0x1090 net/xfrm/xfrm_user.c:1708
xfrm_policy_walk+0x45a/0xd00 net/xfrm/xfrm_policy.c:1013
xfrm_dump_policy+0x1c0/0x2a0 net/xfrm/xfrm_user.c:1749
netlink_dump+0x9b5/0x1550 net/netlink/af_netlink.c:2226
__netlink_dump_start+0x1131/0x1270 net/netlink/af_netlink.c:2323
netlink_dump_start include/linux/netlink.h:214 [inline]
xfrm_user_rcv_msg+0x8a3/0x9b0 net/xfrm/xfrm_user.c:2577
netlink_rcv_skb+0x37e/0x600 net/netlink/af_netlink.c:2448
xfrm_netlink_rcv+0xb2/0xf0 net/xfrm/xfrm_user.c:2598
netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
netlink_unicast+0x1680/0x1750 net/netlink/af_netlink.c:1336
netlink_sendmsg+0x104f/0x1350 net/netlink/af_netlink.c:1901
sock_sendmsg_nosec net/socket.c:629 [inline]
sock_sendmsg net/socket.c:639 [inline]
___sys_sendmsg+0xec8/0x1320 net/socket.c:2117
__sys_sendmsg net/socket.c:2155 [inline]
__do_sys_sendmsg net/socket.c:2164 [inline]
__se_sys_sendmsg net/socket.c:2162 [inline]
__x64_sys_sendmsg+0x331/0x460 net/socket.c:2162
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Local variable description: upt.i@dump_one_policy
Variable was created at:
dump_one_policy+0x78/0x1090 net/xfrm/xfrm_user.c:1689
xfrm_policy_walk+0x45a/0xd00 net/xfrm/xfrm_policy.c:1013
Byte 130 of 137 is uninitialized
Memory access starts at 88019550407f
Fixes: c0144beaeca42 ("[XFRM] netlink: Use nla_put()/NLA_PUT() variantes")
Signed-off-by: Eric Dumazet
Reported-by: syzbot
Cc: Steffen Klassert
Cc: Herbert Xu
Signed-off-by: Steffen Klassert
Signed-off-by: Greg Kroah-Hartman
---
net/xfrm/xfrm_user.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1665,9 +1665,11 @@ static inline size_t userpolicy_type_att
#ifdef CONFIG_XFRM_SUB_POLICY
static int copy_to_user_policy_type(u8 type, struct sk_buff *skb)
{
- struct xfrm_userpolicy_type upt = {
- .type = type,
- };
+ struct xfrm_userpolicy_type upt;
+
+ /* Sadly there are two holes in struct xfrm_userpolicy_type */
+ memset(, 0, sizeof(upt));
+ upt.type = type;
return nla_put(skb, XFRMA_POLICY_TYPE, sizeof(upt), );
}
[PATCH 4.14 101/217] selftests/x86/sigreturn/64: Fix spurious failures on AMD CPUs
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Andy Lutomirski
[ Upstream commit ec348020566009d3da9b99f07c05814d13969c78 ]
When I wrote the sigreturn test, I didn't realize that AMD's busted
IRET behavior was different from Intel's busted IRET behavior:
On AMD CPUs, the CPU leaks the high 32 bits of the kernel stack pointer
to certain userspace contexts. Gee, thanks. There's very little
the kernel can do about it. Modify the test so it passes.
Signed-off-by: Andy Lutomirski
Cc: Borislav Petkov
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/86e7fd3564497f657de30a36da4505799eebef01.1530076529.git.l...@kernel.org
Signed-off-by: Ingo Molnar
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
tools/testing/selftests/x86/sigreturn.c | 46
1 file changed, 29 insertions(+), 17 deletions(-)
--- a/tools/testing/selftests/x86/sigreturn.c
+++ b/tools/testing/selftests/x86/sigreturn.c
@@ -612,19 +612,38 @@ static int test_valid_sigreturn(int cs_b
greg_t req = requested_regs[i], res = resulting_regs[i];
if (i == REG_TRAPNO || i == REG_IP)
continue; /* don't care */
- if (i == REG_SP) {
- printf("\tSP: %llx -> %llx\n", (unsigned long long)req,
- (unsigned long long)res);
+ if (i == REG_SP) {
/*
-* In many circumstances, the high 32 bits of rsp
-* are zeroed. For example, we could be a real
-* 32-bit program, or we could hit any of a number
-* of poorly-documented IRET or segmented ESP
-* oddities. If this happens, it's okay.
+* If we were using a 16-bit stack segment, then
+* the kernel is a bit stuck: IRET only restores
+* the low 16 bits of ESP/RSP if SS is 16-bit.
+* The kernel uses a hack to restore bits 31:16,
+* but that hack doesn't help with bits 63:32.
+* On Intel CPUs, bits 63:32 end up zeroed, and, on
+* AMD CPUs, they leak the high bits of the kernel
+* espfix64 stack pointer. There's very little that
+* the kernel can do about it.
+*
+* Similarly, if we are returning to a 32-bit context,
+* the CPU will often lose the high 32 bits of RSP.
*/
- if (res == (req & 0x))
- continue; /* OK; not expected to work */
+
+ if (res == req)
+ continue;
+
+ if (cs_bits != 64 && ((res ^ req) & 0x) == 0) {
+ printf("[NOTE]\tSP: %llx -> %llx\n",
+ (unsigned long long)req,
+ (unsigned long long)res);
+ continue;
+ }
+
+ printf("[FAIL]\tSP mismatch: requested 0x%llx; got
0x%llx\n",
+ (unsigned long long)requested_regs[i],
+ (unsigned long long)resulting_regs[i]);
+ nerrs++;
+ continue;
}
bool ignore_reg = false;
@@ -663,13 +682,6 @@ static int test_valid_sigreturn(int cs_b
}
if (requested_regs[i] != resulting_regs[i] && !ignore_reg) {
- /*
-* SP is particularly interesting here. The
-* usual cause of failures is that we hit the
-* nasty IRET case of returning to a 16-bit SS,
-* in which case bits 16:31 of the *kernel*
-* stack pointer persist in ESP.
-*/
printf("[FAIL]\tReg %d mismatch: requested 0x%llx; got
0x%llx\n",
i, (unsigned long long)requested_regs[i],
(unsigned long long)resulting_regs[i]);
[PATCH 4.14 075/217] Smack: Mark inode instant in smack_task_to_inode
4.14-stable review patch. If anyone has any objections, please let me know. -- From: Casey Schaufler [ Upstream commit 7b4e88434c4e7982fb053c49657e1c8bbb8692d9 ] Smack: Mark inode instant in smack_task_to_inode /proc clean-up in commit 1bbc55131e59bd099fdc568d3aa0b42634dbd188 resulted in smack_task_to_inode() being called before smack_d_instantiate. This resulted in the smk_inode value being ignored, even while present for files in /proc/self. Marking the inode as instant here fixes that. Signed-off-by: Casey Schaufler Signed-off-by: James Morris Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- security/smack/smack_lsm.c |1 + 1 file changed, 1 insertion(+) --- a/security/smack/smack_lsm.c +++ b/security/smack/smack_lsm.c @@ -2281,6 +2281,7 @@ static void smack_task_to_inode(struct t struct smack_known *skp = smk_of_task_struct(p); isp->smk_inode = skp; + isp->smk_flags |= SMK_INODE_INSTANT; } /*
[PATCH 4.14 206/217] netfilter: conntrack: dccp: treat SYNC/SYNCACK as invalid if no prior state
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Florian Westphal
commit 6613b6173dee098997229caf1f3b961c49da75e6 upstream.
When first DCCP packet is SYNC or SYNCACK, we insert a new conntrack
that has an un-initialized timeout value, i.e. such entry could be
reaped at any time.
Mark them as INVALID and only ignore SYNC/SYNCACK when connection had
an old state.
Reported-by: syzbot+6f18401420df260e3...@syzkaller.appspotmail.com
Signed-off-by: Florian Westphal
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Greg Kroah-Hartman
---
net/netfilter/nf_conntrack_proto_dccp.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/net/netfilter/nf_conntrack_proto_dccp.c
+++ b/net/netfilter/nf_conntrack_proto_dccp.c
@@ -243,14 +243,14 @@ dccp_state_table[CT_DCCP_ROLE_MAX + 1][D
* We currently ignore Sync packets
*
* sNO, sRQ, sRS, sPO, sOP, sCR, sCG, sTW */
- sIG, sIG, sIG, sIG, sIG, sIG, sIG, sIG,
+ sIV, sIG, sIG, sIG, sIG, sIG, sIG, sIG,
},
[DCCP_PKT_SYNCACK] = {
/*
* We currently ignore SyncAck packets
*
* sNO, sRQ, sRS, sPO, sOP, sCR, sCG, sTW */
- sIG, sIG, sIG, sIG, sIG, sIG, sIG, sIG,
+ sIV, sIG, sIG, sIG, sIG, sIG, sIG, sIG,
},
},
[CT_DCCP_ROLE_SERVER] = {
@@ -371,14 +371,14 @@ dccp_state_table[CT_DCCP_ROLE_MAX + 1][D
* We currently ignore Sync packets
*
* sNO, sRQ, sRS, sPO, sOP, sCR, sCG, sTW */
- sIG, sIG, sIG, sIG, sIG, sIG, sIG, sIG,
+ sIV, sIG, sIG, sIG, sIG, sIG, sIG, sIG,
},
[DCCP_PKT_SYNCACK] = {
/*
* We currently ignore SyncAck packets
*
* sNO, sRQ, sRS, sPO, sOP, sCR, sCG, sTW */
- sIG, sIG, sIG, sIG, sIG, sIG, sIG, sIG,
+ sIV, sIG, sIG, sIG, sIG, sIG, sIG, sIG,
},
},
};
[PATCH 4.14 205/217] xfrm_user: prevent leaking 2 bytes of kernel memory
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
commit 45c180bc29babbedd6b8c01b975780ef44d9d09c upstream.
struct xfrm_userpolicy_type has two holes, so we should not
use C99 style initializer.
KMSAN report:
BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:140 [inline]
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x1b14/0x2800 lib/iov_iter.c:571
CPU: 1 PID: 4520 Comm: syz-executor841 Not tainted 4.17.0+ #5
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:113
kmsan_report+0x188/0x2a0 mm/kmsan/kmsan.c:1117
kmsan_internal_check_memory+0x138/0x1f0 mm/kmsan/kmsan.c:1211
kmsan_copy_to_user+0x7a/0x160 mm/kmsan/kmsan.c:1253
copyout lib/iov_iter.c:140 [inline]
_copy_to_iter+0x1b14/0x2800 lib/iov_iter.c:571
copy_to_iter include/linux/uio.h:106 [inline]
skb_copy_datagram_iter+0x422/0xfa0 net/core/datagram.c:431
skb_copy_datagram_msg include/linux/skbuff.h:3268 [inline]
netlink_recvmsg+0x6f1/0x1900 net/netlink/af_netlink.c:1959
sock_recvmsg_nosec net/socket.c:802 [inline]
sock_recvmsg+0x1d6/0x230 net/socket.c:809
___sys_recvmsg+0x3fe/0x810 net/socket.c:2279
__sys_recvmmsg+0x58e/0xe30 net/socket.c:2391
do_sys_recvmmsg+0x2a6/0x3e0 net/socket.c:2472
__do_sys_recvmmsg net/socket.c:2485 [inline]
__se_sys_recvmmsg net/socket.c:2481 [inline]
__x64_sys_recvmmsg+0x15d/0x1c0 net/socket.c:2481
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x446ce9
RSP: 002b:7fc307918db8 EFLAGS: 0293 ORIG_RAX: 012b
RAX: ffda RBX: 006dbc24 RCX: 00446ce9
RDX: 000a RSI: 20005040 RDI: 0003
RBP: 006dbc20 R08: 20004e40 R09:
R10: 4000 R11: 0293 R12:
R13: 7ffc8d2df32f R14: 7fc3079199c0 R15: 0001
Uninit was stored to memory at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:279 [inline]
kmsan_save_stack mm/kmsan/kmsan.c:294 [inline]
kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:685
kmsan_memcpy_origins+0x11d/0x170 mm/kmsan/kmsan.c:527
__msan_memcpy+0x109/0x160 mm/kmsan/kmsan_instr.c:413
__nla_put lib/nlattr.c:569 [inline]
nla_put+0x276/0x340 lib/nlattr.c:627
copy_to_user_policy_type net/xfrm/xfrm_user.c:1678 [inline]
dump_one_policy+0xbe1/0x1090 net/xfrm/xfrm_user.c:1708
xfrm_policy_walk+0x45a/0xd00 net/xfrm/xfrm_policy.c:1013
xfrm_dump_policy+0x1c0/0x2a0 net/xfrm/xfrm_user.c:1749
netlink_dump+0x9b5/0x1550 net/netlink/af_netlink.c:2226
__netlink_dump_start+0x1131/0x1270 net/netlink/af_netlink.c:2323
netlink_dump_start include/linux/netlink.h:214 [inline]
xfrm_user_rcv_msg+0x8a3/0x9b0 net/xfrm/xfrm_user.c:2577
netlink_rcv_skb+0x37e/0x600 net/netlink/af_netlink.c:2448
xfrm_netlink_rcv+0xb2/0xf0 net/xfrm/xfrm_user.c:2598
netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
netlink_unicast+0x1680/0x1750 net/netlink/af_netlink.c:1336
netlink_sendmsg+0x104f/0x1350 net/netlink/af_netlink.c:1901
sock_sendmsg_nosec net/socket.c:629 [inline]
sock_sendmsg net/socket.c:639 [inline]
___sys_sendmsg+0xec8/0x1320 net/socket.c:2117
__sys_sendmsg net/socket.c:2155 [inline]
__do_sys_sendmsg net/socket.c:2164 [inline]
__se_sys_sendmsg net/socket.c:2162 [inline]
__x64_sys_sendmsg+0x331/0x460 net/socket.c:2162
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Local variable description: upt.i@dump_one_policy
Variable was created at:
dump_one_policy+0x78/0x1090 net/xfrm/xfrm_user.c:1689
xfrm_policy_walk+0x45a/0xd00 net/xfrm/xfrm_policy.c:1013
Byte 130 of 137 is uninitialized
Memory access starts at 88019550407f
Fixes: c0144beaeca42 ("[XFRM] netlink: Use nla_put()/NLA_PUT() variantes")
Signed-off-by: Eric Dumazet
Reported-by: syzbot
Cc: Steffen Klassert
Cc: Herbert Xu
Signed-off-by: Steffen Klassert
Signed-off-by: Greg Kroah-Hartman
---
net/xfrm/xfrm_user.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1665,9 +1665,11 @@ static inline size_t userpolicy_type_att
#ifdef CONFIG_XFRM_SUB_POLICY
static int copy_to_user_policy_type(u8 type, struct sk_buff *skb)
{
- struct xfrm_userpolicy_type upt = {
- .type = type,
- };
+ struct xfrm_userpolicy_type upt;
+
+ /* Sadly there are two holes in struct xfrm_userpolicy_type */
+ memset(, 0, sizeof(upt));
+ upt.type = type;
return nla_put(skb, XFRMA_POLICY_TYPE, sizeof(upt), );
}
[PATCH 4.9 029/130] net: stmmac: socfpga: add additional ocp reset line for Stratix10
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Dinh Nguyen
[ Upstream commit bc8a2d9bcbf1ca548b1deb315d14e1da81945bea ]
The Stratix10 platform has an additional reset line, OCP(Open Core Protocol),
that also needs to get deasserted for the stmmac ethernet controller to work.
Thus we need to update the Kconfig to include ARCH_STRATIX10 in order to build
dwmac-socfpga.
Also, remove the redundant check for the reset controller pointer. The
reset driver already checks for the pointer and returns 0 if the pointer
is NULL.
Signed-off-by: Dinh Nguyen
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/ethernet/stmicro/stmmac/Kconfig |2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 18 ++
2 files changed, 15 insertions(+), 5 deletions(-)
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -83,7 +83,7 @@ config DWMAC_ROCKCHIP
config DWMAC_SOCFPGA
tristate "SOCFPGA dwmac support"
default ARCH_SOCFPGA
- depends on OF && (ARCH_SOCFPGA || COMPILE_TEST)
+ depends on OF && (ARCH_SOCFPGA || ARCH_STRATIX10 || COMPILE_TEST)
select MFD_SYSCON
help
Support for ethernet controller on Altera SOCFPGA
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -55,6 +55,7 @@ struct socfpga_dwmac {
struct device *dev;
struct regmap *sys_mgr_base_addr;
struct reset_control *stmmac_rst;
+ struct reset_control *stmmac_ocp_rst;
void __iomem *splitter_base;
bool f2h_ptp_ref_clk;
struct tse_pcs pcs;
@@ -262,8 +263,8 @@ static int socfpga_dwmac_set_phy_mode(st
val = SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_GMII_MII;
/* Assert reset to the enet controller before changing the phy mode */
- if (dwmac->stmmac_rst)
- reset_control_assert(dwmac->stmmac_rst);
+ reset_control_assert(dwmac->stmmac_ocp_rst);
+ reset_control_assert(dwmac->stmmac_rst);
regmap_read(sys_mgr_base_addr, reg_offset, );
ctrl &= ~(SYSMGR_EMACGRP_CTRL_PHYSEL_MASK << reg_shift);
@@ -285,8 +286,8 @@ static int socfpga_dwmac_set_phy_mode(st
/* Deassert reset for the phy configuration to be sampled by
* the enet controller, and operation to start in requested mode
*/
- if (dwmac->stmmac_rst)
- reset_control_deassert(dwmac->stmmac_rst);
+ reset_control_deassert(dwmac->stmmac_ocp_rst);
+ reset_control_deassert(dwmac->stmmac_rst);
if (phymode == PHY_INTERFACE_MODE_SGMII) {
if (tse_pcs_init(dwmac->pcs.tse_pcs_base, >pcs) != 0) {
dev_err(dwmac->dev, "Unable to initialize TSE PCS");
@@ -321,6 +322,15 @@ static int socfpga_dwmac_probe(struct pl
goto err_remove_config_dt;
}
+ dwmac->stmmac_ocp_rst = devm_reset_control_get_optional(dev,
"stmmaceth-ocp");
+ if (IS_ERR(dwmac->stmmac_ocp_rst)) {
+ ret = PTR_ERR(dwmac->stmmac_ocp_rst);
+ dev_err(dev, "error getting reset control of ocp %d\n", ret);
+ goto err_remove_config_dt;
+ }
+
+ reset_control_deassert(dwmac->stmmac_ocp_rst);
+
ret = socfpga_dwmac_parse_data(dwmac, dev);
if (ret) {
dev_err(dev, "Unable to parse OF data\n");
[PATCH 4.9 029/130] net: stmmac: socfpga: add additional ocp reset line for Stratix10
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Dinh Nguyen
[ Upstream commit bc8a2d9bcbf1ca548b1deb315d14e1da81945bea ]
The Stratix10 platform has an additional reset line, OCP(Open Core Protocol),
that also needs to get deasserted for the stmmac ethernet controller to work.
Thus we need to update the Kconfig to include ARCH_STRATIX10 in order to build
dwmac-socfpga.
Also, remove the redundant check for the reset controller pointer. The
reset driver already checks for the pointer and returns 0 if the pointer
is NULL.
Signed-off-by: Dinh Nguyen
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/ethernet/stmicro/stmmac/Kconfig |2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 18 ++
2 files changed, 15 insertions(+), 5 deletions(-)
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -83,7 +83,7 @@ config DWMAC_ROCKCHIP
config DWMAC_SOCFPGA
tristate "SOCFPGA dwmac support"
default ARCH_SOCFPGA
- depends on OF && (ARCH_SOCFPGA || COMPILE_TEST)
+ depends on OF && (ARCH_SOCFPGA || ARCH_STRATIX10 || COMPILE_TEST)
select MFD_SYSCON
help
Support for ethernet controller on Altera SOCFPGA
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -55,6 +55,7 @@ struct socfpga_dwmac {
struct device *dev;
struct regmap *sys_mgr_base_addr;
struct reset_control *stmmac_rst;
+ struct reset_control *stmmac_ocp_rst;
void __iomem *splitter_base;
bool f2h_ptp_ref_clk;
struct tse_pcs pcs;
@@ -262,8 +263,8 @@ static int socfpga_dwmac_set_phy_mode(st
val = SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_GMII_MII;
/* Assert reset to the enet controller before changing the phy mode */
- if (dwmac->stmmac_rst)
- reset_control_assert(dwmac->stmmac_rst);
+ reset_control_assert(dwmac->stmmac_ocp_rst);
+ reset_control_assert(dwmac->stmmac_rst);
regmap_read(sys_mgr_base_addr, reg_offset, );
ctrl &= ~(SYSMGR_EMACGRP_CTRL_PHYSEL_MASK << reg_shift);
@@ -285,8 +286,8 @@ static int socfpga_dwmac_set_phy_mode(st
/* Deassert reset for the phy configuration to be sampled by
* the enet controller, and operation to start in requested mode
*/
- if (dwmac->stmmac_rst)
- reset_control_deassert(dwmac->stmmac_rst);
+ reset_control_deassert(dwmac->stmmac_ocp_rst);
+ reset_control_deassert(dwmac->stmmac_rst);
if (phymode == PHY_INTERFACE_MODE_SGMII) {
if (tse_pcs_init(dwmac->pcs.tse_pcs_base, >pcs) != 0) {
dev_err(dwmac->dev, "Unable to initialize TSE PCS");
@@ -321,6 +322,15 @@ static int socfpga_dwmac_probe(struct pl
goto err_remove_config_dt;
}
+ dwmac->stmmac_ocp_rst = devm_reset_control_get_optional(dev,
"stmmaceth-ocp");
+ if (IS_ERR(dwmac->stmmac_ocp_rst)) {
+ ret = PTR_ERR(dwmac->stmmac_ocp_rst);
+ dev_err(dev, "error getting reset control of ocp %d\n", ret);
+ goto err_remove_config_dt;
+ }
+
+ reset_control_deassert(dwmac->stmmac_ocp_rst);
+
ret = socfpga_dwmac_parse_data(dwmac, dev);
if (ret) {
dev_err(dev, "Unable to parse OF data\n");
[PATCH 4.18 00/22] 4.18.5-stable review
This is the start of the stable review cycle for the 4.18.5 release. There are 22 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat Aug 25 07:47:43 UTC 2018. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.5-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.18.y and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 4.18.5-rc1 Jann Horn reiserfs: fix broken xattr handling (heap corruption, bad retval) Esben Haabendal i2c: imx: Fix race condition in dma read Hans de Goede i2c: core: ACPI: Properly set status byte to 0 for multi-byte writes Lukas Wunner PCI: pciehp: Fix unprotected list iteration in IRQ handler Lukas Wunner PCI: pciehp: Fix use-after-free on unplug Myron Stowe PCI: Skip MPS logic for Virtual Functions (VFs) Zachary Zhang PCI: aardvark: Size bridges before resources allocation Lukas Wunner PCI: hotplug: Don't leak pci_slot on registration failure Rafael J. Wysocki PCI / ACPI / PM: Resume all bridges on suspend-to-RAM Christian König PCI: Restore resized BAR state on resume John David Anglin parisc: Remove ordered stores from syscall.S John David Anglin parisc: Remove unnecessary barriers from spinlock.h Gustavo A. R. Silva drm/amdgpu/pm: Fix potential Spectre v1 Gustavo A. R. Silva drm/i915/kvmgt: Fix potential Spectre v1 Jeremy Cline ext4: fix spectre gadget in ext4_mb_regular_allocator() Michael Ellerman powerpc64s: Show ori31 availability in spectre_v1 sysfs file not v2 Dave Hansen x86/mm/init: Remove freed kernel image areas from alias mapping Dave Hansen x86/mm/init: Add helper for freeing kernel image pages Dave Hansen x86/mm/init: Pass unconverted symbol addresses to free_init_pages() Dave Hansen mm: Allow non-direct-map arguments to free_reserved_area() Matthijs van Duin pty: fix O_CLOEXEC for TIOCGPTPEER Takashi Iwai EDAC: Add missing MEM_LRDDR4 entry in edac_mem_types[] - Diffstat: Makefile | 4 ++-- arch/parisc/include/asm/spinlock.h | 8 ++-- arch/parisc/kernel/syscall.S | 24 +++--- arch/powerpc/kernel/security.c | 27 - arch/x86/include/asm/processor.h | 1 + arch/x86/include/asm/set_memory.h | 1 + arch/x86/mm/init.c | 37 +++--- arch/x86/mm/init_64.c | 8 ++-- arch/x86/mm/pageattr.c | 13 drivers/edac/edac_mc.c | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 3 ++- drivers/gpu/drm/i915/gvt/kvmgt.c | 9 - drivers/i2c/busses/i2c-imx.c | 8 drivers/i2c/i2c-core-acpi.c| 11 +++--- drivers/pci/controller/pci-aardvark.c | 1 + drivers/pci/hotplug/pci_hotplug_core.c | 9 + drivers/pci/hotplug/pciehp.h | 1 + drivers/pci/hotplug/pciehp_core.c | 7 +++ drivers/pci/hotplug/pciehp_hpc.c | 18 + drivers/pci/pci-acpi.c | 6 ++ drivers/pci/pci.c | 28 + drivers/pci/probe.c| 4 drivers/tty/pty.c | 2 +- fs/ext4/mballoc.c | 4 +++- fs/reiserfs/xattr.c| 4 +++- mm/page_alloc.c| 16 +-- 26 files changed, 185 insertions(+), 70 deletions(-)
[PATCH 4.9 028/130] net: propagate dev_get_valid_name return code
4.9-stable review patch. If anyone has any objections, please let me know. -- From: Li RongQing [ Upstream commit 7892bd081045222b9e4027fec279a28d6fe7aa66 ] if dev_get_valid_name failed, propagate its return code and remove the setting err to ENODEV, it will be set to 0 again before dev_change_net_namespace exits. Signed-off-by: Li RongQing Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- net/core/dev.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/net/core/dev.c +++ b/net/core/dev.c @@ -7945,7 +7945,8 @@ int dev_change_net_namespace(struct net_ /* We get here if we can't use the current device name */ if (!pat) goto out; - if (dev_get_valid_name(net, dev, pat) < 0) + err = dev_get_valid_name(net, dev, pat); + if (err < 0) goto out; } @@ -7957,7 +7958,6 @@ int dev_change_net_namespace(struct net_ dev_close(dev); /* And unlink it from device chain */ - err = -ENODEV; unlist_netdevice(dev); synchronize_net();
[PATCH 4.18 22/22] reiserfs: fix broken xattr handling (heap corruption, bad retval)
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Jann Horn
commit a13f085d111e90469faf2d9965eb39b11c114d7e upstream.
This fixes the following issues:
- When a buffer size is supplied to reiserfs_listxattr() such that each
individual name fits, but the concatenation of all names doesn't fit,
reiserfs_listxattr() overflows the supplied buffer. This leads to a
kernel heap overflow (verified using KASAN) followed by an out-of-bounds
usercopy and is therefore a security bug.
- When a buffer size is supplied to reiserfs_listxattr() such that a
name doesn't fit, -ERANGE should be returned. But reiserfs instead just
truncates the list of names; I have verified that if the only xattr on a
file has a longer name than the supplied buffer length, listxattr()
incorrectly returns zero.
With my patch applied, -ERANGE is returned in both cases and the memory
corruption doesn't happen anymore.
Credit for making me clean this code up a bit goes to Al Viro, who pointed
out that the ->actor calling convention is suboptimal and should be
changed.
Link: http://lkml.kernel.org/r/20180802151539.5373-1-ja...@google.com
Fixes: 48b32a3553a5 ("reiserfs: use generic xattr handlers")
Signed-off-by: Jann Horn
Acked-by: Jeff Mahoney
Cc: Eric Biggers
Cc: Al Viro
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
fs/reiserfs/xattr.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/fs/reiserfs/xattr.c
+++ b/fs/reiserfs/xattr.c
@@ -792,8 +792,10 @@ static int listxattr_filler(struct dir_c
return 0;
size = namelen + 1;
if (b->buf) {
- if (size > b->size)
+ if (b->pos + size > b->size) {
+ b->pos = -ERANGE;
return -ERANGE;
+ }
memcpy(b->buf + b->pos, name, namelen);
b->buf[b->pos + namelen] = 0;
}
[PATCH 4.18 00/22] 4.18.5-stable review
This is the start of the stable review cycle for the 4.18.5 release. There are 22 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat Aug 25 07:47:43 UTC 2018. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.5-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.18.y and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 4.18.5-rc1 Jann Horn reiserfs: fix broken xattr handling (heap corruption, bad retval) Esben Haabendal i2c: imx: Fix race condition in dma read Hans de Goede i2c: core: ACPI: Properly set status byte to 0 for multi-byte writes Lukas Wunner PCI: pciehp: Fix unprotected list iteration in IRQ handler Lukas Wunner PCI: pciehp: Fix use-after-free on unplug Myron Stowe PCI: Skip MPS logic for Virtual Functions (VFs) Zachary Zhang PCI: aardvark: Size bridges before resources allocation Lukas Wunner PCI: hotplug: Don't leak pci_slot on registration failure Rafael J. Wysocki PCI / ACPI / PM: Resume all bridges on suspend-to-RAM Christian König PCI: Restore resized BAR state on resume John David Anglin parisc: Remove ordered stores from syscall.S John David Anglin parisc: Remove unnecessary barriers from spinlock.h Gustavo A. R. Silva drm/amdgpu/pm: Fix potential Spectre v1 Gustavo A. R. Silva drm/i915/kvmgt: Fix potential Spectre v1 Jeremy Cline ext4: fix spectre gadget in ext4_mb_regular_allocator() Michael Ellerman powerpc64s: Show ori31 availability in spectre_v1 sysfs file not v2 Dave Hansen x86/mm/init: Remove freed kernel image areas from alias mapping Dave Hansen x86/mm/init: Add helper for freeing kernel image pages Dave Hansen x86/mm/init: Pass unconverted symbol addresses to free_init_pages() Dave Hansen mm: Allow non-direct-map arguments to free_reserved_area() Matthijs van Duin pty: fix O_CLOEXEC for TIOCGPTPEER Takashi Iwai EDAC: Add missing MEM_LRDDR4 entry in edac_mem_types[] - Diffstat: Makefile | 4 ++-- arch/parisc/include/asm/spinlock.h | 8 ++-- arch/parisc/kernel/syscall.S | 24 +++--- arch/powerpc/kernel/security.c | 27 - arch/x86/include/asm/processor.h | 1 + arch/x86/include/asm/set_memory.h | 1 + arch/x86/mm/init.c | 37 +++--- arch/x86/mm/init_64.c | 8 ++-- arch/x86/mm/pageattr.c | 13 drivers/edac/edac_mc.c | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 3 ++- drivers/gpu/drm/i915/gvt/kvmgt.c | 9 - drivers/i2c/busses/i2c-imx.c | 8 drivers/i2c/i2c-core-acpi.c| 11 +++--- drivers/pci/controller/pci-aardvark.c | 1 + drivers/pci/hotplug/pci_hotplug_core.c | 9 + drivers/pci/hotplug/pciehp.h | 1 + drivers/pci/hotplug/pciehp_core.c | 7 +++ drivers/pci/hotplug/pciehp_hpc.c | 18 + drivers/pci/pci-acpi.c | 6 ++ drivers/pci/pci.c | 28 + drivers/pci/probe.c| 4 drivers/tty/pty.c | 2 +- fs/ext4/mballoc.c | 4 +++- fs/reiserfs/xattr.c| 4 +++- mm/page_alloc.c| 16 +-- 26 files changed, 185 insertions(+), 70 deletions(-)
[PATCH 4.9 028/130] net: propagate dev_get_valid_name return code
4.9-stable review patch. If anyone has any objections, please let me know. -- From: Li RongQing [ Upstream commit 7892bd081045222b9e4027fec279a28d6fe7aa66 ] if dev_get_valid_name failed, propagate its return code and remove the setting err to ENODEV, it will be set to 0 again before dev_change_net_namespace exits. Signed-off-by: Li RongQing Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- net/core/dev.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/net/core/dev.c +++ b/net/core/dev.c @@ -7945,7 +7945,8 @@ int dev_change_net_namespace(struct net_ /* We get here if we can't use the current device name */ if (!pat) goto out; - if (dev_get_valid_name(net, dev, pat) < 0) + err = dev_get_valid_name(net, dev, pat); + if (err < 0) goto out; } @@ -7957,7 +7958,6 @@ int dev_change_net_namespace(struct net_ dev_close(dev); /* And unlink it from device chain */ - err = -ENODEV; unlist_netdevice(dev); synchronize_net();
[PATCH 4.18 22/22] reiserfs: fix broken xattr handling (heap corruption, bad retval)
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Jann Horn
commit a13f085d111e90469faf2d9965eb39b11c114d7e upstream.
This fixes the following issues:
- When a buffer size is supplied to reiserfs_listxattr() such that each
individual name fits, but the concatenation of all names doesn't fit,
reiserfs_listxattr() overflows the supplied buffer. This leads to a
kernel heap overflow (verified using KASAN) followed by an out-of-bounds
usercopy and is therefore a security bug.
- When a buffer size is supplied to reiserfs_listxattr() such that a
name doesn't fit, -ERANGE should be returned. But reiserfs instead just
truncates the list of names; I have verified that if the only xattr on a
file has a longer name than the supplied buffer length, listxattr()
incorrectly returns zero.
With my patch applied, -ERANGE is returned in both cases and the memory
corruption doesn't happen anymore.
Credit for making me clean this code up a bit goes to Al Viro, who pointed
out that the ->actor calling convention is suboptimal and should be
changed.
Link: http://lkml.kernel.org/r/20180802151539.5373-1-ja...@google.com
Fixes: 48b32a3553a5 ("reiserfs: use generic xattr handlers")
Signed-off-by: Jann Horn
Acked-by: Jeff Mahoney
Cc: Eric Biggers
Cc: Al Viro
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
fs/reiserfs/xattr.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/fs/reiserfs/xattr.c
+++ b/fs/reiserfs/xattr.c
@@ -792,8 +792,10 @@ static int listxattr_filler(struct dir_c
return 0;
size = namelen + 1;
if (b->buf) {
- if (size > b->size)
+ if (b->pos + size > b->size) {
+ b->pos = -ERANGE;
return -ERANGE;
+ }
memcpy(b->buf + b->pos, name, namelen);
b->buf[b->pos + namelen] = 0;
}
[PATCH 4.18 06/22] x86/mm/init: Remove freed kernel image areas from alias mapping
4.18-stable review patch. If anyone has any objections, please let me know. -- From: Dave Hansen commit c40a56a7818cfe735fc93a69e1875f8bba834483 upstream. The kernel image is mapped into two places in the virtual address space (addresses without KASLR, of course): 1. The kernel direct map (0x8800) 2. The "high kernel map" (0x8100) We actually execute out of #2. If we get the address of a kernel symbol, it points to #2, but almost all physical-to-virtual translations point to Parts of the "high kernel map" alias are mapped in the userspace page tables with the Global bit for performance reasons. The parts that we map to userspace do not (er, should not) have secrets. When PTI is enabled then the global bit is usually not set in the high mapping and just used to compensate for poor performance on systems which lack PCID. This is fine, except that some areas in the kernel image that are adjacent to the non-secret-containing areas are unused holes. We free these holes back into the normal page allocator and reuse them as normal kernel memory. The memory will, of course, get *used* via the normal map, but the alias mapping is kept. This otherwise unused alias mapping of the holes will, by default keep the Global bit, be mapped out to userspace, and be vulnerable to Meltdown. Remove the alias mapping of these pages entirely. This is likely to fracture the 2M page mapping the kernel image near these areas, but this should affect a minority of the area. The pageattr code changes *all* aliases mapping the physical pages that it operates on (by default). We only want to modify a single alias, so we need to tweak its behavior. This unmapping behavior is currently dependent on PTI being in place. Going forward, we should at least consider doing this for all configurations. Having an extra read-write alias for memory is not exactly ideal for debugging things like random memory corruption and this does undercut features like DEBUG_PAGEALLOC or future work like eXclusive Page Frame Ownership (XPFO). Before this patch: current_kernel:---[ High Kernel Mapping ]--- current_kernel-0x8000-0x8100 16M pmd current_kernel-0x8100-0x81e0 14M ro PSE GLB x pmd current_kernel-0x81e0-0x81e11000 68K ro GLB x pte current_kernel-0x81e11000-0x82001980K RW NX pte current_kernel-0x8200-0x8260 6M ro PSE GLB NX pmd current_kernel-0x8260-0x82c0 6M RW PSE NX pmd current_kernel-0x82c0-0x82e0 2M RW NX pte current_kernel-0x82e0-0x8320 4M RW PSE NX pmd current_kernel-0x8320-0xa000 462M pmd current_user:---[ High Kernel Mapping ]--- current_user-0x8000-0x8100 16M pmd current_user-0x8100-0x81e0 14M ro PSE GLB x pmd current_user-0x81e0-0x81e11000 68K ro GLB x pte current_user-0x81e11000-0x82001980K RW NX pte current_user-0x8200-0x8260 6M ro PSE GLB NX pmd current_user-0x8260-0xa000 474M pmd After this patch: current_kernel:---[ High Kernel Mapping ]--- current_kernel-0x8000-0x8100 16M pmd current_kernel-0x8100-0x81e0 14M ro PSE GLB x pmd current_kernel-0x81e0-0x81e11000 68K ro GLB x pte current_kernel-0x81e11000-0x82001980K pte current_kernel-0x8200-0x8240 4M ro PSE GLB NX pmd current_kernel-0x8240-0x82488000 544K ro NX pte current_kernel-0x82488000-0x82601504K pte current_kernel-0x8260-0x82c0 6M RW PSE NX pmd current_kernel-0x82c0-0x82c0d000 52K RW NX pte current_kernel-0x82c0d000-0x82dc1740K pte current_user:---[ High Kernel Mapping ]--- current_user-0x8000-0x8100 16M pmd current_user-0x8100-0x81e0
[PATCH 4.18 07/22] powerpc64s: Show ori31 availability in spectre_v1 sysfs file not v2
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Michael Ellerman
commit 6d44acae1937b81cf8115ada8958e04f601f3f2e upstream.
When I added the spectre_v2 information in sysfs, I included the
availability of the ori31 speculation barrier.
Although the ori31 barrier can be used to mitigate v2, it's primarily
intended as a spectre v1 mitigation. Spectre v2 is mitigated by
hardware changes.
So rework the sysfs files to show the ori31 information in the
spectre_v1 file, rather than v2.
Currently we display eg:
$ grep . spectre_v*
spectre_v1:Mitigation: __user pointer sanitization
spectre_v2:Mitigation: Indirect branch cache disabled, ori31 speculation
barrier enabled
After:
$ grep . spectre_v*
spectre_v1:Mitigation: __user pointer sanitization, ori31 speculation barrier
enabled
spectre_v2:Mitigation: Indirect branch cache disabled
Fixes: d6fbe1c55c55 ("powerpc/64s: Wire up cpu_show_spectre_v2()")
Cc: sta...@vger.kernel.org # v4.17+
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/kernel/security.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -117,25 +117,35 @@ ssize_t cpu_show_meltdown(struct device
ssize_t cpu_show_spectre_v1(struct device *dev, struct device_attribute *attr,
char *buf)
{
- if (!security_ftr_enabled(SEC_FTR_BNDS_CHK_SPEC_BAR))
- return sprintf(buf, "Not affected\n");
+ struct seq_buf s;
+
+ seq_buf_init(, buf, PAGE_SIZE - 1);
+
+ if (security_ftr_enabled(SEC_FTR_BNDS_CHK_SPEC_BAR)) {
+ if (barrier_nospec_enabled)
+ seq_buf_printf(, "Mitigation: __user pointer
sanitization");
+ else
+ seq_buf_printf(, "Vulnerable");
- if (barrier_nospec_enabled)
- return sprintf(buf, "Mitigation: __user pointer
sanitization\n");
+ if (security_ftr_enabled(SEC_FTR_SPEC_BAR_ORI31))
+ seq_buf_printf(, ", ori31 speculation barrier
enabled");
- return sprintf(buf, "Vulnerable\n");
+ seq_buf_printf(, "\n");
+ } else
+ seq_buf_printf(, "Not affected\n");
+
+ return s.len;
}
ssize_t cpu_show_spectre_v2(struct device *dev, struct device_attribute *attr,
char *buf)
{
- bool bcs, ccd, ori;
struct seq_buf s;
+ bool bcs, ccd;
seq_buf_init(, buf, PAGE_SIZE - 1);
bcs = security_ftr_enabled(SEC_FTR_BCCTRL_SERIALISED);
ccd = security_ftr_enabled(SEC_FTR_COUNT_CACHE_DISABLED);
- ori = security_ftr_enabled(SEC_FTR_SPEC_BAR_ORI31);
if (bcs || ccd) {
seq_buf_printf(, "Mitigation: ");
@@ -151,9 +161,6 @@ ssize_t cpu_show_spectre_v2(struct devic
} else
seq_buf_printf(, "Vulnerable");
- if (ori)
- seq_buf_printf(, ", ori31 speculation barrier enabled");
-
seq_buf_printf(, "\n");
return s.len;
[PATCH 4.18 06/22] x86/mm/init: Remove freed kernel image areas from alias mapping
4.18-stable review patch. If anyone has any objections, please let me know. -- From: Dave Hansen commit c40a56a7818cfe735fc93a69e1875f8bba834483 upstream. The kernel image is mapped into two places in the virtual address space (addresses without KASLR, of course): 1. The kernel direct map (0x8800) 2. The "high kernel map" (0x8100) We actually execute out of #2. If we get the address of a kernel symbol, it points to #2, but almost all physical-to-virtual translations point to Parts of the "high kernel map" alias are mapped in the userspace page tables with the Global bit for performance reasons. The parts that we map to userspace do not (er, should not) have secrets. When PTI is enabled then the global bit is usually not set in the high mapping and just used to compensate for poor performance on systems which lack PCID. This is fine, except that some areas in the kernel image that are adjacent to the non-secret-containing areas are unused holes. We free these holes back into the normal page allocator and reuse them as normal kernel memory. The memory will, of course, get *used* via the normal map, but the alias mapping is kept. This otherwise unused alias mapping of the holes will, by default keep the Global bit, be mapped out to userspace, and be vulnerable to Meltdown. Remove the alias mapping of these pages entirely. This is likely to fracture the 2M page mapping the kernel image near these areas, but this should affect a minority of the area. The pageattr code changes *all* aliases mapping the physical pages that it operates on (by default). We only want to modify a single alias, so we need to tweak its behavior. This unmapping behavior is currently dependent on PTI being in place. Going forward, we should at least consider doing this for all configurations. Having an extra read-write alias for memory is not exactly ideal for debugging things like random memory corruption and this does undercut features like DEBUG_PAGEALLOC or future work like eXclusive Page Frame Ownership (XPFO). Before this patch: current_kernel:---[ High Kernel Mapping ]--- current_kernel-0x8000-0x8100 16M pmd current_kernel-0x8100-0x81e0 14M ro PSE GLB x pmd current_kernel-0x81e0-0x81e11000 68K ro GLB x pte current_kernel-0x81e11000-0x82001980K RW NX pte current_kernel-0x8200-0x8260 6M ro PSE GLB NX pmd current_kernel-0x8260-0x82c0 6M RW PSE NX pmd current_kernel-0x82c0-0x82e0 2M RW NX pte current_kernel-0x82e0-0x8320 4M RW PSE NX pmd current_kernel-0x8320-0xa000 462M pmd current_user:---[ High Kernel Mapping ]--- current_user-0x8000-0x8100 16M pmd current_user-0x8100-0x81e0 14M ro PSE GLB x pmd current_user-0x81e0-0x81e11000 68K ro GLB x pte current_user-0x81e11000-0x82001980K RW NX pte current_user-0x8200-0x8260 6M ro PSE GLB NX pmd current_user-0x8260-0xa000 474M pmd After this patch: current_kernel:---[ High Kernel Mapping ]--- current_kernel-0x8000-0x8100 16M pmd current_kernel-0x8100-0x81e0 14M ro PSE GLB x pmd current_kernel-0x81e0-0x81e11000 68K ro GLB x pte current_kernel-0x81e11000-0x82001980K pte current_kernel-0x8200-0x8240 4M ro PSE GLB NX pmd current_kernel-0x8240-0x82488000 544K ro NX pte current_kernel-0x82488000-0x82601504K pte current_kernel-0x8260-0x82c0 6M RW PSE NX pmd current_kernel-0x82c0-0x82c0d000 52K RW NX pte current_kernel-0x82c0d000-0x82dc1740K pte current_user:---[ High Kernel Mapping ]--- current_user-0x8000-0x8100 16M pmd current_user-0x8100-0x81e0
[PATCH 4.18 07/22] powerpc64s: Show ori31 availability in spectre_v1 sysfs file not v2
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Michael Ellerman
commit 6d44acae1937b81cf8115ada8958e04f601f3f2e upstream.
When I added the spectre_v2 information in sysfs, I included the
availability of the ori31 speculation barrier.
Although the ori31 barrier can be used to mitigate v2, it's primarily
intended as a spectre v1 mitigation. Spectre v2 is mitigated by
hardware changes.
So rework the sysfs files to show the ori31 information in the
spectre_v1 file, rather than v2.
Currently we display eg:
$ grep . spectre_v*
spectre_v1:Mitigation: __user pointer sanitization
spectre_v2:Mitigation: Indirect branch cache disabled, ori31 speculation
barrier enabled
After:
$ grep . spectre_v*
spectre_v1:Mitigation: __user pointer sanitization, ori31 speculation barrier
enabled
spectre_v2:Mitigation: Indirect branch cache disabled
Fixes: d6fbe1c55c55 ("powerpc/64s: Wire up cpu_show_spectre_v2()")
Cc: sta...@vger.kernel.org # v4.17+
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/kernel/security.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -117,25 +117,35 @@ ssize_t cpu_show_meltdown(struct device
ssize_t cpu_show_spectre_v1(struct device *dev, struct device_attribute *attr,
char *buf)
{
- if (!security_ftr_enabled(SEC_FTR_BNDS_CHK_SPEC_BAR))
- return sprintf(buf, "Not affected\n");
+ struct seq_buf s;
+
+ seq_buf_init(, buf, PAGE_SIZE - 1);
+
+ if (security_ftr_enabled(SEC_FTR_BNDS_CHK_SPEC_BAR)) {
+ if (barrier_nospec_enabled)
+ seq_buf_printf(, "Mitigation: __user pointer
sanitization");
+ else
+ seq_buf_printf(, "Vulnerable");
- if (barrier_nospec_enabled)
- return sprintf(buf, "Mitigation: __user pointer
sanitization\n");
+ if (security_ftr_enabled(SEC_FTR_SPEC_BAR_ORI31))
+ seq_buf_printf(, ", ori31 speculation barrier
enabled");
- return sprintf(buf, "Vulnerable\n");
+ seq_buf_printf(, "\n");
+ } else
+ seq_buf_printf(, "Not affected\n");
+
+ return s.len;
}
ssize_t cpu_show_spectre_v2(struct device *dev, struct device_attribute *attr,
char *buf)
{
- bool bcs, ccd, ori;
struct seq_buf s;
+ bool bcs, ccd;
seq_buf_init(, buf, PAGE_SIZE - 1);
bcs = security_ftr_enabled(SEC_FTR_BCCTRL_SERIALISED);
ccd = security_ftr_enabled(SEC_FTR_COUNT_CACHE_DISABLED);
- ori = security_ftr_enabled(SEC_FTR_SPEC_BAR_ORI31);
if (bcs || ccd) {
seq_buf_printf(, "Mitigation: ");
@@ -151,9 +161,6 @@ ssize_t cpu_show_spectre_v2(struct devic
} else
seq_buf_printf(, "Vulnerable");
- if (ori)
- seq_buf_printf(, ", ori31 speculation barrier enabled");
-
seq_buf_printf(, "\n");
return s.len;
[PATCH 4.18 05/22] x86/mm/init: Add helper for freeing kernel image pages
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Dave Hansen
commit 6ea2738e0ca0e626c75202fb051c1e88d7a950fa upstream.
When chunks of the kernel image are freed, free_init_pages() is used
directly. Consolidate the three sites that do this. Also update the
string to give an incrementally better description of that memory versus
what was there before.
Signed-off-by: Dave Hansen
Signed-off-by: Thomas Gleixner
Cc: keesc...@google.com
Cc: aarca...@redhat.com
Cc: jgr...@suse.com
Cc: jpoim...@redhat.com
Cc: gre...@linuxfoundation.org
Cc: pet...@infradead.org
Cc: hu...@google.com
Cc: torva...@linux-foundation.org
Cc: b...@alien8.de
Cc: l...@kernel.org
Cc: a...@linux.intel.com
Cc: Kees Cook
Cc: Andrea Arcangeli
Cc: Juergen Gross
Cc: Josh Poimboeuf
Cc: Greg Kroah-Hartman
Cc: Peter Zijlstra
Cc: Hugh Dickins
Cc: Linus Torvalds
Cc: Borislav Petkov
Cc: Andy Lutomirski
Cc: Andi Kleen
Link: https://lkml.kernel.org/r/20180802225829.fe0e3...@viggo.jf.intel.com
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/include/asm/processor.h |1 +
arch/x86/mm/init.c | 15 ---
arch/x86/mm/init_64.c|4 ++--
3 files changed, 15 insertions(+), 5 deletions(-)
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -971,6 +971,7 @@ static inline uint32_t hypervisor_cpuid_
extern unsigned long arch_align_stack(unsigned long sp);
extern void free_init_pages(char *what, unsigned long begin, unsigned long
end);
+extern void free_kernel_image_pages(void *begin, void *end);
void default_idle(void);
#ifdef CONFIG_XEN
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -775,13 +775,22 @@ void free_init_pages(char *what, unsigne
}
}
+/*
+ * begin/end can be in the direct map or the "high kernel mapping"
+ * used for the kernel image only. free_init_pages() will do the
+ * right thing for either kind of address.
+ */
+void free_kernel_image_pages(void *begin, void *end)
+{
+ free_init_pages("unused kernel image",
+ (unsigned long)begin, (unsigned long)end);
+}
+
void __ref free_initmem(void)
{
e820__reallocate_tables();
- free_init_pages("unused kernel",
- (unsigned long)(&__init_begin),
- (unsigned long)(&__init_end));
+ free_kernel_image_pages(&__init_begin, &__init_end);
}
#ifdef CONFIG_BLK_DEV_INITRD
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -1283,8 +1283,8 @@ void mark_rodata_ro(void)
set_memory_ro(start, (end-start) >> PAGE_SHIFT);
#endif
- free_init_pages("unused kernel", text_end, rodata_start);
- free_init_pages("unused kernel", rodata_end, _sdata);
+ free_kernel_image_pages((void *)text_end, (void *)rodata_start);
+ free_kernel_image_pages((void *)rodata_end, (void *)_sdata);
debug_checkwx();
[PATCH 4.18 16/22] PCI: aardvark: Size bridges before resources allocation
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Zachary Zhang
commit 91a2968e245d6ba616db37001fa1a043078b1a65 upstream.
The PCIE I/O and MEM resource allocation mechanism is that root bus
goes through the following steps:
1. Check PCI bridges' range and computes I/O and Mem base/limits.
2. Sort all subordinate devices I/O and MEM resource requirements and
allocate the resources and writes/updates subordinate devices'
requirements to PCI bridges I/O and Mem MEM/limits registers.
Currently, PCI Aardvark driver only handles the second step and lacks
the first step, so there is an I/O and MEM resource allocation failure
when using a PCI switch. This commit fixes that by sizing bridges
before doing the resource allocation.
Fixes: 8c39d710363c1 ("PCI: aardvark: Add Aardvark PCI host controller
driver")
Signed-off-by: Zachary Zhang
[Thomas: edit commit log.]
Signed-off-by: Thomas Petazzoni
Signed-off-by: Lorenzo Pieralisi
Cc:
Signed-off-by: Greg Kroah-Hartman
---
drivers/pci/controller/pci-aardvark.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -952,6 +952,7 @@ static int advk_pcie_probe(struct platfo
bus = bridge->bus;
+ pci_bus_size_bridges(bus);
pci_bus_assign_resources(bus);
list_for_each_entry(child, >children, node)
[PATCH 4.18 03/22] mm: Allow non-direct-map arguments to free_reserved_area()
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Dave Hansen
commit 0d83432811f26871295a9bc24d3c387924da6071 upstream.
free_reserved_area() takes pointers as arguments to show which addresses
should be freed. However, it does this in a somewhat ambiguous way. If it
gets a kernel direct map address, it always works. However, if it gets an
address that is part of the kernel image alias mapping, it can fail.
It fails if all of the following happen:
* The specified address is part of the kernel image alias
* Poisoning is requested (forcing a memset())
* The address is in a read-only portion of the kernel image
The memset() fails on the read-only mapping, of course.
free_reserved_area() *is* called both on the direct map and on kernel image
alias addresses. We've just lucked out thus far that the kernel image
alias areas it gets used on are read-write. I'm fairly sure this has been
just a happy accident.
It is quite easy to make free_reserved_area() work for all cases: just
convert the address to a direct map address before doing the memset(), and
do this unconditionally. There is little chance of a regression here
because we previously did a virt_to_page() on the address for the memset,
so we know these are not highmem pages for which virt_to_page() would fail.
Signed-off-by: Dave Hansen
Signed-off-by: Thomas Gleixner
Cc: keesc...@google.com
Cc: aarca...@redhat.com
Cc: jgr...@suse.com
Cc: jpoim...@redhat.com
Cc: gre...@linuxfoundation.org
Cc: pet...@infradead.org
Cc: hu...@google.com
Cc: torva...@linux-foundation.org
Cc: b...@alien8.de
Cc: l...@kernel.org
Cc: a...@linux.intel.com
Cc: Kees Cook
Cc: Andrea Arcangeli
Cc: Juergen Gross
Cc: Josh Poimboeuf
Cc: Greg Kroah-Hartman
Cc: Peter Zijlstra
Cc: Hugh Dickins
Cc: Linus Torvalds
Cc: Borislav Petkov
Cc: Andy Lutomirski
Cc: Andi Kleen
Link: https://lkml.kernel.org/r/20180802225826.1287a...@viggo.jf.intel.com
Signed-off-by: Greg Kroah-Hartman
---
mm/page_alloc.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6939,9 +6939,21 @@ unsigned long free_reserved_area(void *s
start = (void *)PAGE_ALIGN((unsigned long)start);
end = (void *)((unsigned long)end & PAGE_MASK);
for (pos = start; pos < end; pos += PAGE_SIZE, pages++) {
+ struct page *page = virt_to_page(pos);
+ void *direct_map_addr;
+
+ /*
+* 'direct_map_addr' might be different from 'pos'
+* because some architectures' virt_to_page()
+* work with aliases. Getting the direct map
+* address ensures that we get a _writeable_
+* alias for the memset().
+*/
+ direct_map_addr = page_address(page);
if ((unsigned int)poison <= 0xFF)
- memset(pos, poison, PAGE_SIZE);
- free_reserved_page(virt_to_page(pos));
+ memset(direct_map_addr, poison, PAGE_SIZE);
+
+ free_reserved_page(page);
}
if (pages && s)
[PATCH 4.18 17/22] PCI: Skip MPS logic for Virtual Functions (VFs)
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Myron Stowe
commit 3dbe97efe8bf450b183d6dee2305cbc032e6b8a4 upstream.
PCIe r4.0, sec 9.3.5.4, "Device Control Register", shows both
Max_Payload_Size (MPS) and Max_Read_request_Size (MRRS) to be 'RsvdP' for
VFs. Just prior to the table it states:
"PF and VF functionality is defined in Section 7.5.3.4 except where
noted in Table 9-16. For VF fields marked 'RsvdP', the PF setting
applies to the VF."
All of which implies that with respect to Max_Payload_Size Supported
(MPSS), MPS, and MRRS values, we should not be paying any attention to the
VF's fields, but rather only to the PF's. Only looking at the PF's fields
also logically makes sense as it's the sole physical interface to the PCIe
bus.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200527
Fixes: 27d868b5e6cf ("PCI: Set MPS to match upstream bridge")
Signed-off-by: Myron Stowe
Signed-off-by: Bjorn Helgaas
Cc: sta...@vger.kernel.org # 4.3+
Cc: Keith Busch
Cc: Sinan Kaya
Cc: Dongdong Liu
Cc: Jon Mason
Signed-off-by: Greg Kroah-Hartman
---
drivers/pci/probe.c |4
1 file changed, 4 insertions(+)
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1730,6 +1730,10 @@ static void pci_configure_mps(struct pci
if (!pci_is_pcie(dev) || !bridge || !pci_is_pcie(bridge))
return;
+ /* MPS and MRRS fields are of type 'RsvdP' for VFs, short-circuit out */
+ if (dev->is_virtfn)
+ return;
+
mps = pcie_get_mps(dev);
p_mps = pcie_get_mps(bridge);
[PATCH 4.18 09/22] drm/i915/kvmgt: Fix potential Spectre v1
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Gustavo A. R. Silva
commit de5372da605d3bca46e3102bab51b7e1c0e0a6f6 upstream.
info.index can be indirectly controlled by user-space, hence leading
to a potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
drivers/gpu/drm/i915/gvt/kvmgt.c:1232 intel_vgpu_ioctl() warn:
potential spectre issue 'vgpu->vdev.region' [r]
Fix this by sanitizing info.index before indirectly using it to index
vgpu->vdev.region
Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].
[1] https://marc.info/?l=linux-kernel=152449131114778=2
Cc: sta...@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva
Signed-off-by: Zhenyu Wang
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/i915/gvt/kvmgt.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -43,6 +43,8 @@
#include
#include
+#include
+
#include "i915_drv.h"
#include "gvt.h"
@@ -1084,7 +1086,8 @@ static long intel_vgpu_ioctl(struct mdev
} else if (cmd == VFIO_DEVICE_GET_REGION_INFO) {
struct vfio_region_info info;
struct vfio_info_cap caps = { .buf = NULL, .size = 0 };
- int i, ret;
+ unsigned int i;
+ int ret;
struct vfio_region_info_cap_sparse_mmap *sparse = NULL;
size_t size;
int nr_areas = 1;
@@ -1169,6 +1172,10 @@ static long intel_vgpu_ioctl(struct mdev
if (info.index >= VFIO_PCI_NUM_REGIONS +
vgpu->vdev.num_regions)
return -EINVAL;
+ info.index =
+ array_index_nospec(info.index,
+ VFIO_PCI_NUM_REGIONS +
+ vgpu->vdev.num_regions);
i = info.index - VFIO_PCI_NUM_REGIONS;
[PATCH 4.18 04/22] x86/mm/init: Pass unconverted symbol addresses to free_init_pages()
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Dave Hansen
commit 9f515cdb411ef34f1aaf4c40bb0c932cf6db5de1 upstream.
The x86 code has several places where it frees parts of kernel image:
1. Unused SMP alternative
2. __init code
3. The hole between text and rodata
4. The hole between rodata and data
We call free_init_pages() to do this. Strangely, we convert the symbol
addresses to kernel direct map addresses in some cases (#3, #4) but not
others (#1, #2).
The virt_to_page() and the other code in free_reserved_area() now works
fine for for symbol addresses on x86, so don't bother converting the
addresses to direct map addresses before freeing them.
Signed-off-by: Dave Hansen
Signed-off-by: Thomas Gleixner
Cc: keesc...@google.com
Cc: aarca...@redhat.com
Cc: jgr...@suse.com
Cc: jpoim...@redhat.com
Cc: gre...@linuxfoundation.org
Cc: pet...@infradead.org
Cc: hu...@google.com
Cc: torva...@linux-foundation.org
Cc: b...@alien8.de
Cc: l...@kernel.org
Cc: a...@linux.intel.com
Cc: Kees Cook
Cc: Andrea Arcangeli
Cc: Juergen Gross
Cc: Josh Poimboeuf
Cc: Greg Kroah-Hartman
Cc: Peter Zijlstra
Cc: Hugh Dickins
Cc: Linus Torvalds
Cc: Borislav Petkov
Cc: Andy Lutomirski
Cc: Andi Kleen
Link: https://lkml.kernel.org/r/20180802225828.89b2d...@viggo.jf.intel.com
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/mm/init_64.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -1283,12 +1283,8 @@ void mark_rodata_ro(void)
set_memory_ro(start, (end-start) >> PAGE_SHIFT);
#endif
- free_init_pages("unused kernel",
- (unsigned long) __va(__pa_symbol(text_end)),
- (unsigned long) __va(__pa_symbol(rodata_start)));
- free_init_pages("unused kernel",
- (unsigned long) __va(__pa_symbol(rodata_end)),
- (unsigned long) __va(__pa_symbol(_sdata)));
+ free_init_pages("unused kernel", text_end, rodata_start);
+ free_init_pages("unused kernel", rodata_end, _sdata);
debug_checkwx();
[PATCH 4.18 05/22] x86/mm/init: Add helper for freeing kernel image pages
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Dave Hansen
commit 6ea2738e0ca0e626c75202fb051c1e88d7a950fa upstream.
When chunks of the kernel image are freed, free_init_pages() is used
directly. Consolidate the three sites that do this. Also update the
string to give an incrementally better description of that memory versus
what was there before.
Signed-off-by: Dave Hansen
Signed-off-by: Thomas Gleixner
Cc: keesc...@google.com
Cc: aarca...@redhat.com
Cc: jgr...@suse.com
Cc: jpoim...@redhat.com
Cc: gre...@linuxfoundation.org
Cc: pet...@infradead.org
Cc: hu...@google.com
Cc: torva...@linux-foundation.org
Cc: b...@alien8.de
Cc: l...@kernel.org
Cc: a...@linux.intel.com
Cc: Kees Cook
Cc: Andrea Arcangeli
Cc: Juergen Gross
Cc: Josh Poimboeuf
Cc: Greg Kroah-Hartman
Cc: Peter Zijlstra
Cc: Hugh Dickins
Cc: Linus Torvalds
Cc: Borislav Petkov
Cc: Andy Lutomirski
Cc: Andi Kleen
Link: https://lkml.kernel.org/r/20180802225829.fe0e3...@viggo.jf.intel.com
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/include/asm/processor.h |1 +
arch/x86/mm/init.c | 15 ---
arch/x86/mm/init_64.c|4 ++--
3 files changed, 15 insertions(+), 5 deletions(-)
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -971,6 +971,7 @@ static inline uint32_t hypervisor_cpuid_
extern unsigned long arch_align_stack(unsigned long sp);
extern void free_init_pages(char *what, unsigned long begin, unsigned long
end);
+extern void free_kernel_image_pages(void *begin, void *end);
void default_idle(void);
#ifdef CONFIG_XEN
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -775,13 +775,22 @@ void free_init_pages(char *what, unsigne
}
}
+/*
+ * begin/end can be in the direct map or the "high kernel mapping"
+ * used for the kernel image only. free_init_pages() will do the
+ * right thing for either kind of address.
+ */
+void free_kernel_image_pages(void *begin, void *end)
+{
+ free_init_pages("unused kernel image",
+ (unsigned long)begin, (unsigned long)end);
+}
+
void __ref free_initmem(void)
{
e820__reallocate_tables();
- free_init_pages("unused kernel",
- (unsigned long)(&__init_begin),
- (unsigned long)(&__init_end));
+ free_kernel_image_pages(&__init_begin, &__init_end);
}
#ifdef CONFIG_BLK_DEV_INITRD
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -1283,8 +1283,8 @@ void mark_rodata_ro(void)
set_memory_ro(start, (end-start) >> PAGE_SHIFT);
#endif
- free_init_pages("unused kernel", text_end, rodata_start);
- free_init_pages("unused kernel", rodata_end, _sdata);
+ free_kernel_image_pages((void *)text_end, (void *)rodata_start);
+ free_kernel_image_pages((void *)rodata_end, (void *)_sdata);
debug_checkwx();
[PATCH 4.18 16/22] PCI: aardvark: Size bridges before resources allocation
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Zachary Zhang
commit 91a2968e245d6ba616db37001fa1a043078b1a65 upstream.
The PCIE I/O and MEM resource allocation mechanism is that root bus
goes through the following steps:
1. Check PCI bridges' range and computes I/O and Mem base/limits.
2. Sort all subordinate devices I/O and MEM resource requirements and
allocate the resources and writes/updates subordinate devices'
requirements to PCI bridges I/O and Mem MEM/limits registers.
Currently, PCI Aardvark driver only handles the second step and lacks
the first step, so there is an I/O and MEM resource allocation failure
when using a PCI switch. This commit fixes that by sizing bridges
before doing the resource allocation.
Fixes: 8c39d710363c1 ("PCI: aardvark: Add Aardvark PCI host controller
driver")
Signed-off-by: Zachary Zhang
[Thomas: edit commit log.]
Signed-off-by: Thomas Petazzoni
Signed-off-by: Lorenzo Pieralisi
Cc:
Signed-off-by: Greg Kroah-Hartman
---
drivers/pci/controller/pci-aardvark.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -952,6 +952,7 @@ static int advk_pcie_probe(struct platfo
bus = bridge->bus;
+ pci_bus_size_bridges(bus);
pci_bus_assign_resources(bus);
list_for_each_entry(child, >children, node)
[PATCH 4.18 03/22] mm: Allow non-direct-map arguments to free_reserved_area()
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Dave Hansen
commit 0d83432811f26871295a9bc24d3c387924da6071 upstream.
free_reserved_area() takes pointers as arguments to show which addresses
should be freed. However, it does this in a somewhat ambiguous way. If it
gets a kernel direct map address, it always works. However, if it gets an
address that is part of the kernel image alias mapping, it can fail.
It fails if all of the following happen:
* The specified address is part of the kernel image alias
* Poisoning is requested (forcing a memset())
* The address is in a read-only portion of the kernel image
The memset() fails on the read-only mapping, of course.
free_reserved_area() *is* called both on the direct map and on kernel image
alias addresses. We've just lucked out thus far that the kernel image
alias areas it gets used on are read-write. I'm fairly sure this has been
just a happy accident.
It is quite easy to make free_reserved_area() work for all cases: just
convert the address to a direct map address before doing the memset(), and
do this unconditionally. There is little chance of a regression here
because we previously did a virt_to_page() on the address for the memset,
so we know these are not highmem pages for which virt_to_page() would fail.
Signed-off-by: Dave Hansen
Signed-off-by: Thomas Gleixner
Cc: keesc...@google.com
Cc: aarca...@redhat.com
Cc: jgr...@suse.com
Cc: jpoim...@redhat.com
Cc: gre...@linuxfoundation.org
Cc: pet...@infradead.org
Cc: hu...@google.com
Cc: torva...@linux-foundation.org
Cc: b...@alien8.de
Cc: l...@kernel.org
Cc: a...@linux.intel.com
Cc: Kees Cook
Cc: Andrea Arcangeli
Cc: Juergen Gross
Cc: Josh Poimboeuf
Cc: Greg Kroah-Hartman
Cc: Peter Zijlstra
Cc: Hugh Dickins
Cc: Linus Torvalds
Cc: Borislav Petkov
Cc: Andy Lutomirski
Cc: Andi Kleen
Link: https://lkml.kernel.org/r/20180802225826.1287a...@viggo.jf.intel.com
Signed-off-by: Greg Kroah-Hartman
---
mm/page_alloc.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6939,9 +6939,21 @@ unsigned long free_reserved_area(void *s
start = (void *)PAGE_ALIGN((unsigned long)start);
end = (void *)((unsigned long)end & PAGE_MASK);
for (pos = start; pos < end; pos += PAGE_SIZE, pages++) {
+ struct page *page = virt_to_page(pos);
+ void *direct_map_addr;
+
+ /*
+* 'direct_map_addr' might be different from 'pos'
+* because some architectures' virt_to_page()
+* work with aliases. Getting the direct map
+* address ensures that we get a _writeable_
+* alias for the memset().
+*/
+ direct_map_addr = page_address(page);
if ((unsigned int)poison <= 0xFF)
- memset(pos, poison, PAGE_SIZE);
- free_reserved_page(virt_to_page(pos));
+ memset(direct_map_addr, poison, PAGE_SIZE);
+
+ free_reserved_page(page);
}
if (pages && s)
[PATCH 4.18 17/22] PCI: Skip MPS logic for Virtual Functions (VFs)
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Myron Stowe
commit 3dbe97efe8bf450b183d6dee2305cbc032e6b8a4 upstream.
PCIe r4.0, sec 9.3.5.4, "Device Control Register", shows both
Max_Payload_Size (MPS) and Max_Read_request_Size (MRRS) to be 'RsvdP' for
VFs. Just prior to the table it states:
"PF and VF functionality is defined in Section 7.5.3.4 except where
noted in Table 9-16. For VF fields marked 'RsvdP', the PF setting
applies to the VF."
All of which implies that with respect to Max_Payload_Size Supported
(MPSS), MPS, and MRRS values, we should not be paying any attention to the
VF's fields, but rather only to the PF's. Only looking at the PF's fields
also logically makes sense as it's the sole physical interface to the PCIe
bus.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200527
Fixes: 27d868b5e6cf ("PCI: Set MPS to match upstream bridge")
Signed-off-by: Myron Stowe
Signed-off-by: Bjorn Helgaas
Cc: sta...@vger.kernel.org # 4.3+
Cc: Keith Busch
Cc: Sinan Kaya
Cc: Dongdong Liu
Cc: Jon Mason
Signed-off-by: Greg Kroah-Hartman
---
drivers/pci/probe.c |4
1 file changed, 4 insertions(+)
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1730,6 +1730,10 @@ static void pci_configure_mps(struct pci
if (!pci_is_pcie(dev) || !bridge || !pci_is_pcie(bridge))
return;
+ /* MPS and MRRS fields are of type 'RsvdP' for VFs, short-circuit out */
+ if (dev->is_virtfn)
+ return;
+
mps = pcie_get_mps(dev);
p_mps = pcie_get_mps(bridge);
[PATCH 4.18 09/22] drm/i915/kvmgt: Fix potential Spectre v1
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Gustavo A. R. Silva
commit de5372da605d3bca46e3102bab51b7e1c0e0a6f6 upstream.
info.index can be indirectly controlled by user-space, hence leading
to a potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
drivers/gpu/drm/i915/gvt/kvmgt.c:1232 intel_vgpu_ioctl() warn:
potential spectre issue 'vgpu->vdev.region' [r]
Fix this by sanitizing info.index before indirectly using it to index
vgpu->vdev.region
Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].
[1] https://marc.info/?l=linux-kernel=152449131114778=2
Cc: sta...@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva
Signed-off-by: Zhenyu Wang
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/i915/gvt/kvmgt.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -43,6 +43,8 @@
#include
#include
+#include
+
#include "i915_drv.h"
#include "gvt.h"
@@ -1084,7 +1086,8 @@ static long intel_vgpu_ioctl(struct mdev
} else if (cmd == VFIO_DEVICE_GET_REGION_INFO) {
struct vfio_region_info info;
struct vfio_info_cap caps = { .buf = NULL, .size = 0 };
- int i, ret;
+ unsigned int i;
+ int ret;
struct vfio_region_info_cap_sparse_mmap *sparse = NULL;
size_t size;
int nr_areas = 1;
@@ -1169,6 +1172,10 @@ static long intel_vgpu_ioctl(struct mdev
if (info.index >= VFIO_PCI_NUM_REGIONS +
vgpu->vdev.num_regions)
return -EINVAL;
+ info.index =
+ array_index_nospec(info.index,
+ VFIO_PCI_NUM_REGIONS +
+ vgpu->vdev.num_regions);
i = info.index - VFIO_PCI_NUM_REGIONS;
[PATCH 4.18 04/22] x86/mm/init: Pass unconverted symbol addresses to free_init_pages()
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Dave Hansen
commit 9f515cdb411ef34f1aaf4c40bb0c932cf6db5de1 upstream.
The x86 code has several places where it frees parts of kernel image:
1. Unused SMP alternative
2. __init code
3. The hole between text and rodata
4. The hole between rodata and data
We call free_init_pages() to do this. Strangely, we convert the symbol
addresses to kernel direct map addresses in some cases (#3, #4) but not
others (#1, #2).
The virt_to_page() and the other code in free_reserved_area() now works
fine for for symbol addresses on x86, so don't bother converting the
addresses to direct map addresses before freeing them.
Signed-off-by: Dave Hansen
Signed-off-by: Thomas Gleixner
Cc: keesc...@google.com
Cc: aarca...@redhat.com
Cc: jgr...@suse.com
Cc: jpoim...@redhat.com
Cc: gre...@linuxfoundation.org
Cc: pet...@infradead.org
Cc: hu...@google.com
Cc: torva...@linux-foundation.org
Cc: b...@alien8.de
Cc: l...@kernel.org
Cc: a...@linux.intel.com
Cc: Kees Cook
Cc: Andrea Arcangeli
Cc: Juergen Gross
Cc: Josh Poimboeuf
Cc: Greg Kroah-Hartman
Cc: Peter Zijlstra
Cc: Hugh Dickins
Cc: Linus Torvalds
Cc: Borislav Petkov
Cc: Andy Lutomirski
Cc: Andi Kleen
Link: https://lkml.kernel.org/r/20180802225828.89b2d...@viggo.jf.intel.com
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/mm/init_64.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -1283,12 +1283,8 @@ void mark_rodata_ro(void)
set_memory_ro(start, (end-start) >> PAGE_SHIFT);
#endif
- free_init_pages("unused kernel",
- (unsigned long) __va(__pa_symbol(text_end)),
- (unsigned long) __va(__pa_symbol(rodata_start)));
- free_init_pages("unused kernel",
- (unsigned long) __va(__pa_symbol(rodata_end)),
- (unsigned long) __va(__pa_symbol(_sdata)));
+ free_init_pages("unused kernel", text_end, rodata_start);
+ free_init_pages("unused kernel", rodata_end, _sdata);
debug_checkwx();
[PATCH 4.18 08/22] ext4: fix spectre gadget in ext4_mb_regular_allocator()
4.18-stable review patch. If anyone has any objections, please let me know. -- From: Jeremy Cline commit 1a5d5e5d51e75a5bca67dadbcea8c841934b7b85 upstream. 'ac->ac_g_ex.fe_len' is a user-controlled value which is used in the derivation of 'ac->ac_2order'. 'ac->ac_2order', in turn, is used to index arrays which makes it a potential spectre gadget. Fix this by sanitizing the value assigned to 'ac->ac2_order'. This covers the following accesses found with the help of smatch: * fs/ext4/mballoc.c:1896 ext4_mb_simple_scan_group() warn: potential spectre issue 'grp->bb_counters' [w] (local cap) * fs/ext4/mballoc.c:445 mb_find_buddy() warn: potential spectre issue 'EXT4_SB(e4b->bd_sb)->s_mb_offsets' [r] (local cap) * fs/ext4/mballoc.c:446 mb_find_buddy() warn: potential spectre issue 'EXT4_SB(e4b->bd_sb)->s_mb_maxs' [r] (local cap) Suggested-by: Josh Poimboeuf Signed-off-by: Jeremy Cline Signed-off-by: Theodore Ts'o Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- fs/ext4/mballoc.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -14,6 +14,7 @@ #include #include #include +#include #include #include @@ -2140,7 +2141,8 @@ ext4_mb_regular_allocator(struct ext4_al * This should tell if fe_len is exactly power of 2 */ if ((ac->ac_g_ex.fe_len & (~(1 << (i - 1 == 0) - ac->ac_2order = i - 1; + ac->ac_2order = array_index_nospec(i - 1, + sb->s_blocksize_bits + 2); } /* if stream allocation is enabled, use global goal */
[PATCH 4.18 08/22] ext4: fix spectre gadget in ext4_mb_regular_allocator()
4.18-stable review patch. If anyone has any objections, please let me know. -- From: Jeremy Cline commit 1a5d5e5d51e75a5bca67dadbcea8c841934b7b85 upstream. 'ac->ac_g_ex.fe_len' is a user-controlled value which is used in the derivation of 'ac->ac_2order'. 'ac->ac_2order', in turn, is used to index arrays which makes it a potential spectre gadget. Fix this by sanitizing the value assigned to 'ac->ac2_order'. This covers the following accesses found with the help of smatch: * fs/ext4/mballoc.c:1896 ext4_mb_simple_scan_group() warn: potential spectre issue 'grp->bb_counters' [w] (local cap) * fs/ext4/mballoc.c:445 mb_find_buddy() warn: potential spectre issue 'EXT4_SB(e4b->bd_sb)->s_mb_offsets' [r] (local cap) * fs/ext4/mballoc.c:446 mb_find_buddy() warn: potential spectre issue 'EXT4_SB(e4b->bd_sb)->s_mb_maxs' [r] (local cap) Suggested-by: Josh Poimboeuf Signed-off-by: Jeremy Cline Signed-off-by: Theodore Ts'o Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- fs/ext4/mballoc.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -14,6 +14,7 @@ #include #include #include +#include #include #include @@ -2140,7 +2141,8 @@ ext4_mb_regular_allocator(struct ext4_al * This should tell if fe_len is exactly power of 2 */ if ((ac->ac_g_ex.fe_len & (~(1 << (i - 1 == 0) - ac->ac_2order = i - 1; + ac->ac_2order = array_index_nospec(i - 1, + sb->s_blocksize_bits + 2); } /* if stream allocation is enabled, use global goal */
[PATCH 4.18 20/22] i2c: core: ACPI: Properly set status byte to 0 for multi-byte writes
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Hans de Goede
commit c463a158cb6c5d9a85b7d894cd4f8116e8bd6be0 upstream.
acpi_gsb_i2c_write_bytes() returns i2c_transfer()'s return value, which
is the number of transfers executed on success, so 1.
The ACPI code expects us to store 0 in gsb->status for success, not 1.
Specifically this breaks the following code in the Thinkpad 8 DSDT:
ECWR = I2CW = ECWR /* \_SB_.I2C1.BAT0.ECWR */
If ((ECST == Zero))
{
ECRD = I2CR /* \_SB_.I2C1.I2CR */
}
Before this commit we set ECST to 1, causing the read to never happen
breaking battery monitoring on the Thinkpad 8.
This commit makes acpi_gsb_i2c_write_bytes() return 0 when i2c_transfer()
returns 1, so the single write transfer completed successfully, and
makes it return -EIO on for other (unexpected) return values >= 0.
Cc: sta...@vger.kernel.org
Signed-off-by: Hans de Goede
Acked-by: Mika Westerberg
Signed-off-by: Wolfram Sang
Signed-off-by: Greg Kroah-Hartman
---
drivers/i2c/i2c-core-acpi.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
--- a/drivers/i2c/i2c-core-acpi.c
+++ b/drivers/i2c/i2c-core-acpi.c
@@ -482,11 +482,16 @@ static int acpi_gsb_i2c_write_bytes(stru
msgs[0].buf = buffer;
ret = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs));
- if (ret < 0)
- dev_err(>adapter->dev, "i2c write failed\n");
kfree(buffer);
- return ret;
+
+ if (ret < 0) {
+ dev_err(>adapter->dev, "i2c write failed: %d\n", ret);
+ return ret;
+ }
+
+ /* 1 transfer must have completed successfully */
+ return (ret == 1) ? 0 : -EIO;
}
static acpi_status
[PATCH 4.18 02/22] pty: fix O_CLOEXEC for TIOCGPTPEER
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Matthijs van Duin
commit 36ecc1481dc8d8c52d43ba18c6b642c1d2fde789 upstream.
It was being ignored because the flags were not passed to fd allocation.
Fixes: 54ebbfb16034 ("tty: add TIOCGPTPEER ioctl")
Signed-off-by: Matthijs van Duin
Acked-by: Aleksa Sarai
Cc: stable
Signed-off-by: Greg Kroah-Hartman
---
drivers/tty/pty.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/tty/pty.c
+++ b/drivers/tty/pty.c
@@ -625,7 +625,7 @@ int ptm_open_peer(struct file *master, s
if (tty->driver != ptm_driver)
return -EIO;
- fd = get_unused_fd_flags(0);
+ fd = get_unused_fd_flags(flags);
if (fd < 0) {
retval = fd;
goto err;
[PATCH 4.18 19/22] PCI: pciehp: Fix unprotected list iteration in IRQ handler
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Lukas Wunner
commit 1204e35bedf4e5015cda559ed8c84789a6dae24e upstream.
Commit b440bde74f04 ("PCI: Add pci_ignore_hotplug() to ignore hotplug
events for a device") iterates over the devices on a hotplug port's
subordinate bus in pciehp's IRQ handler without acquiring pci_bus_sem.
It is thus possible for a user to cause a crash by concurrently
manipulating the device list, e.g. by disabling slot power via sysfs
on a different CPU or by initiating a remove/rescan via sysfs.
This can't be fixed by acquiring pci_bus_sem because it may sleep.
The simplest fix is to avoid the list iteration altogether and just
check the ignore_hotplug flag on the port itself. This works because
pci_ignore_hotplug() sets the flag both on the device as well as on its
parent bridge.
We do lose the ability to print the name of the device blocking hotplug
in the debug message, but that's probably bearable.
Fixes: b440bde74f04 ("PCI: Add pci_ignore_hotplug() to ignore hotplug events
for a device")
Signed-off-by: Lukas Wunner
Signed-off-by: Bjorn Helgaas
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/pci/hotplug/pciehp_hpc.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -539,8 +539,6 @@ static irqreturn_t pciehp_isr(int irq, v
{
struct controller *ctrl = (struct controller *)dev_id;
struct pci_dev *pdev = ctrl_dev(ctrl);
- struct pci_bus *subordinate = pdev->subordinate;
- struct pci_dev *dev;
struct slot *slot = ctrl->slot;
u16 status, events;
u8 present;
@@ -588,14 +586,9 @@ static irqreturn_t pciehp_isr(int irq, v
wake_up(>queue);
}
- if (subordinate) {
- list_for_each_entry(dev, >devices, bus_list) {
- if (dev->ignore_hotplug) {
- ctrl_dbg(ctrl, "ignoring hotplug event %#06x
(%s requested no hotplug)\n",
-events, pci_name(dev));
- return IRQ_HANDLED;
- }
- }
+ if (pdev->ignore_hotplug) {
+ ctrl_dbg(ctrl, "ignoring hotplug event %#06x\n", events);
+ return IRQ_HANDLED;
}
/* Check Attention Button Pressed */
[PATCH 4.18 18/22] PCI: pciehp: Fix use-after-free on unplug
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Lukas Wunner
commit 281e878eab191cce4259abbbf1a0322e3adae02c upstream.
When pciehp is unbound (e.g. on unplug of a Thunderbolt device), the
hotplug_slot struct is deregistered and thus freed before freeing the
IRQ. The IRQ handler and the work items it schedules print the slot
name referenced from the freed structure in various informational and
debug log messages, each time resulting in a quadruple dereference of
freed pointers (hotplug_slot -> pci_slot -> kobject -> name).
At best the slot name is logged as "(null)", at worst kernel memory is
exposed in logs or the driver crashes:
pciehp :10:00.0:pcie204: Slot((null)): Card not present
An attacker may provoke the bug by unplugging multiple devices on a
Thunderbolt daisy chain at once. Unplugging can also be simulated by
powering down slots via sysfs. The bug is particularly easy to trigger
in poll mode.
It has been present since the driver's introduction in 2004:
https://git.kernel.org/tglx/history/c/c16b4b14d980
Fix by rearranging teardown such that the IRQ is freed first. Run the
work items queued by the IRQ handler to completion before freeing the
hotplug_slot struct by draining the work queue from the ->release_slot
callback which is invoked by pci_hp_deregister().
Signed-off-by: Lukas Wunner
Signed-off-by: Bjorn Helgaas
Cc: sta...@vger.kernel.org # v2.6.4
Signed-off-by: Greg Kroah-Hartman
---
drivers/pci/hotplug/pciehp.h |1 +
drivers/pci/hotplug/pciehp_core.c |7 +++
drivers/pci/hotplug/pciehp_hpc.c |5 ++---
3 files changed, 10 insertions(+), 3 deletions(-)
--- a/drivers/pci/hotplug/pciehp.h
+++ b/drivers/pci/hotplug/pciehp.h
@@ -119,6 +119,7 @@ int pciehp_unconfigure_device(struct slo
void pciehp_queue_pushbutton_work(struct work_struct *work);
struct controller *pcie_init(struct pcie_device *dev);
int pcie_init_notification(struct controller *ctrl);
+void pcie_shutdown_notification(struct controller *ctrl);
int pciehp_enable_slot(struct slot *p_slot);
int pciehp_disable_slot(struct slot *p_slot);
void pcie_reenable_notification(struct controller *ctrl);
--- a/drivers/pci/hotplug/pciehp_core.c
+++ b/drivers/pci/hotplug/pciehp_core.c
@@ -62,6 +62,12 @@ static int reset_slot(struct hotplug_slo
*/
static void release_slot(struct hotplug_slot *hotplug_slot)
{
+ struct slot *slot = hotplug_slot->private;
+
+ /* queued work needs hotplug_slot name */
+ cancel_delayed_work(>work);
+ drain_workqueue(slot->wq);
+
kfree(hotplug_slot->ops);
kfree(hotplug_slot->info);
kfree(hotplug_slot);
@@ -264,6 +270,7 @@ static void pciehp_remove(struct pcie_de
{
struct controller *ctrl = get_service_data(dev);
+ pcie_shutdown_notification(ctrl);
cleanup_slot(ctrl);
pciehp_release_ctrl(ctrl);
}
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -765,7 +765,7 @@ int pcie_init_notification(struct contro
return 0;
}
-static void pcie_shutdown_notification(struct controller *ctrl)
+void pcie_shutdown_notification(struct controller *ctrl)
{
if (ctrl->notification_enabled) {
pcie_disable_notification(ctrl);
@@ -800,7 +800,7 @@ abort:
static void pcie_cleanup_slot(struct controller *ctrl)
{
struct slot *slot = ctrl->slot;
- cancel_delayed_work(>work);
+
destroy_workqueue(slot->wq);
kfree(slot);
}
@@ -893,7 +893,6 @@ abort:
void pciehp_release_ctrl(struct controller *ctrl)
{
- pcie_shutdown_notification(ctrl);
pcie_cleanup_slot(ctrl);
kfree(ctrl);
}
