Re: [PATCH v3 2/2] dwc: PCI: intel: Intel PCIe RC controller driver
Hi Andy, On 9/5/2019 7:40 PM, Andy Shevchenko wrote: On Thu, Sep 05, 2019 at 11:45:18AM +0100, Andrew Murray wrote: On Wed, Sep 04, 2019 at 06:10:31PM +0800, Dilip Kota wrote: Add support to PCIe RC controller on Intel Universal Gateway SoC. PCIe controller is based of Synopsys Designware pci core. +config PCIE_INTEL_AXI I think that name here is too generic. Classical x86 seems not using this. This PCIe driver is for the Intel Gateway SoCs. So how about naming it is as "pcie-intel-gw"; pcie-intel-gw.c and Kconfig as PCIE_INTEL_GW. Andrew Murray is ok with this naming, please let me know your view. +bool "Intel AHB/AXI PCIe host controller support" +depends on PCI_MSI +depends on PCI +depends on OF +select PCIE_DW_HOST +help + Say 'Y' here to enable support for Intel AHB/AXI PCIe Host + controller driver. + The Intel PCIe controller is based on the Synopsys Designware + pcie core and therefore uses the Designware core functions to + implement the driver.
Re: Tracing text poke / kernel self-modifying code (Was: Re: [RFC v2 0/6] x86: dynamic indirect branch promotion)
On 29/08/19 2:46 PM, Peter Zijlstra wrote:
> On Thu, Aug 29, 2019 at 12:40:56PM +0300, Adrian Hunter wrote:
>> Can you expand on "and ensure the poke_handler preserves the existing
>> control flow"? Whatever the INT3-handler does will be traced normally so
>> long as it does not itself execute self-modified code.
>
> My thinking was that the code shouldn't change semantics before emitting
> the RECORD_TEXT_POKE; but you're right in that that doesn't seem to
> matter much.
>
> Either we run the old code or INT3 does 'something'. Then we get
> RECORD_TEXT_POKE and finish the poke. Which tells that the moment INT3
> stops the new text is in place.
>
> I suppose that works too, and requires less changes.
What about this?
diff --git a/arch/x86/include/asm/text-patching.h
b/arch/x86/include/asm/text-patching.h
index 70c09967a999..00aa9bef2b9d 100644
--- a/arch/x86/include/asm/text-patching.h
+++ b/arch/x86/include/asm/text-patching.h
@@ -30,6 +30,7 @@ struct text_poke_loc {
void *addr;
size_t len;
const char opcode[POKE_MAX_OPCODE_SIZE];
+ char old_opcode[POKE_MAX_OPCODE_SIZE];
};
extern void text_poke_early(void *addr, const void *opcode, size_t len);
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index ccd32013c47a..c781bafd 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -3,6 +3,7 @@
#include
#include
+#include
#include
#include
#include
@@ -1045,8 +1046,10 @@ void text_poke_bp_batch(struct text_poke_loc *tp,
unsigned int nr_entries)
/*
* First step: add a int3 trap to the address that will be patched.
*/
- for (i = 0; i < nr_entries; i++)
+ for (i = 0; i < nr_entries; i++) {
+ memcpy(tp[i].old_opcode, tp[i].addr, tp[i].len);
text_poke(tp[i].addr, &int3, sizeof(int3));
+ }
on_each_cpu(do_sync_core, NULL, 1);
@@ -1071,6 +1074,11 @@ void text_poke_bp_batch(struct text_poke_loc *tp,
unsigned int nr_entries)
on_each_cpu(do_sync_core, NULL, 1);
}
+ for (i = 0; i < nr_entries; i++) {
+ perf_event_text_poke((unsigned long)tp[i].addr,
+tp[i].old_opcode, tp[i].opcode, tp[i].len);
+ }
+
/*
* Third step: replace the first byte (int3) by the first byte of
* replacing opcode.
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 61448c19a132..f4c6095d2110 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1183,6 +1183,8 @@ extern void perf_event_exec(void);
extern void perf_event_comm(struct task_struct *tsk, bool exec);
extern void perf_event_namespaces(struct task_struct *tsk);
extern void perf_event_fork(struct task_struct *tsk);
+extern void perf_event_text_poke(unsigned long addr, const void *old_bytes,
+const void *new_bytes, size_t len);
/* Callchains */
DECLARE_PER_CPU(struct perf_callchain_entry, perf_callchain_entry);
@@ -1406,6 +1408,10 @@ static inline void perf_event_exec(void)
{ }
static inline void perf_event_comm(struct task_struct *tsk, bool exec) { }
static inline void perf_event_namespaces(struct task_struct *tsk) { }
static inline void perf_event_fork(struct task_struct *tsk){ }
+static inline void perf_event_text_poke(unsigned long addr,
+ const void *old_bytes,
+ const void *new_bytes,
+ size_t len) { }
static inline void perf_event_init(void) { }
static inline int perf_swevent_get_recursion_context(void){
return -1; }
static inline void perf_swevent_put_recursion_context(int rctx)
{ }
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index bb7b271397a6..6396d4c0d2f9 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -375,7 +375,8 @@ struct perf_event_attr {
ksymbol: 1, /* include ksymbol events
*/
bpf_event : 1, /* include bpf events */
aux_output : 1, /* generate AUX records
instead of events */
- __reserved_1 : 32;
+ text_poke : 1, /* include text poke
events */
+ __reserved_1 : 31;
union {
__u32 wakeup_events;/* wakeup every n events */
@@ -1000,6 +1001,22 @@ enum perf_event_type {
*/
PERF_RECORD_BPF_EVENT = 18,
+ /*
+* Records changes to kernel text i.e. self-modified code.
+* 'len' is the number of old bytes, which is the same as the number
+* of new bytes. 'bytes' conta
[PATCH] KVM: s390: Remove unused parameter from __inject_sigp_restart()
It's not required, so drop it to make it clear that this interrupt
does not have any extra parameters.
Signed-off-by: Thomas Huth
---
arch/s390/kvm/interrupt.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
index b5fd6e85657c..3e7efdd9228a 100644
--- a/arch/s390/kvm/interrupt.c
+++ b/arch/s390/kvm/interrupt.c
@@ -1477,8 +1477,7 @@ static int __inject_sigp_stop(struct kvm_vcpu *vcpu,
struct kvm_s390_irq *irq)
return 0;
}
-static int __inject_sigp_restart(struct kvm_vcpu *vcpu,
-struct kvm_s390_irq *irq)
+static int __inject_sigp_restart(struct kvm_vcpu *vcpu)
{
struct kvm_s390_local_interrupt *li = &vcpu->arch.local_int;
@@ -1997,7 +1996,7 @@ static int do_inject_vcpu(struct kvm_vcpu *vcpu, struct
kvm_s390_irq *irq)
rc = __inject_sigp_stop(vcpu, irq);
break;
case KVM_S390_RESTART:
- rc = __inject_sigp_restart(vcpu, irq);
+ rc = __inject_sigp_restart(vcpu);
break;
case KVM_S390_INT_CLOCK_COMP:
rc = __inject_ckc(vcpu);
--
2.18.1
Re: [PATCH v9 0/8] stg mail -e --version=v9 \
On Wed 11-09-19 18:09:18, David Hildenbrand wrote: > On 11.09.19 15:51, Michal Hocko wrote: > > On Wed 11-09-19 15:20:02, Michal Hocko wrote: > > [...] > >>> 4. Continuously report, not the "one time report everything" approach. > >> > >> So you mean the allocator reporting this rather than an external code to > >> poll right? I do not know, how much this is nice to have than must have? > > > > Another idea that I haven't really thought through so it might turned > > out to be completely bogus but let's try anyway. Your "report everything" > > just made me look and realize that free_pages_prepare already performs > > stuff that actually does something similar yet unrelated. > > > > We do report to special page poisoning, zeroying or > > CONFIG_DEBUG_PAGEALLOC to unmap the address from the kernel address > > space. This sounds like something fitting your model no? > > > > AFAIKS, the poisoning/unmapping is done whenever a page is freed. I > don't quite see yet how that would help to remember if a page was > already reported. Do you still have to differ that state when each page is reported? > After reporting the page we would have to switch some > state (Nitesh: bitmap bit, Alexander: page flag) to identify that. Yes, you can either store the state somewhere. > Of course, we could map the page and treat that as "the state" when we > reported it, but I am not sure that's such a good idea :) > > As always, I might be very wrong ... I still do not fully understand the usecase so I might be equally wrong. My thinking is along these lines. Why should you scan free pages when you can effectively capture each freed page? If you go one step further then post_alloc_hook would be the counterpart to know that your page has been allocated. -- Michal Hocko SUSE Labs
Re: [PATCH] s390/qeth: fix spelling mistake "alocpool" -> "allocpool"
On 9/11/19 5:35 PM, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in QETH_CARD_TEXT text. Fix it.
>
This spelling mistake is intended, because this qeth trace area is defined for
8 byte length entries. We try to make the entries as speaking as possible - even
at cost of spelling mistakes.
> Signed-off-by: Colin Ian King
> ---
> drivers/s390/net/qeth_core_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/s390/net/qeth_core_main.c
> b/drivers/s390/net/qeth_core_main.c
> index a7868c8133ee..ab96b22db3fe 100644
> --- a/drivers/s390/net/qeth_core_main.c
> +++ b/drivers/s390/net/qeth_core_main.c
> @@ -218,7 +218,7 @@ static int qeth_alloc_buffer_pool(struct qeth_card *card)
> void *ptr;
> int i, j;
>
> - QETH_CARD_TEXT(card, 5, "alocpool");
> + QETH_CARD_TEXT(card, 5, "allocpool");
> for (i = 0; i < card->qdio.init_pool.buf_count; ++i) {
> pool_entry = kzalloc(sizeof(*pool_entry), GFP_KERNEL);
> if (!pool_entry) {
>
Re: [PATCH] s390/qeth: fix spelling mistake "alocpool" -> "allocpool"
On 12/09/2019 08:19, Ursula Braun wrote:
>
>
> On 9/11/19 5:35 PM, Colin King wrote:
>> From: Colin Ian King
>>
>> There is a spelling mistake in QETH_CARD_TEXT text. Fix it.
>>
>
> This spelling mistake is intended, because this qeth trace area is defined for
> 8 byte length entries. We try to make the entries as speaking as possible -
> even
> at cost of spelling mistakes.
Ah, OK.
>
>> Signed-off-by: Colin Ian King
>> ---
>> drivers/s390/net/qeth_core_main.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/s390/net/qeth_core_main.c
>> b/drivers/s390/net/qeth_core_main.c
>> index a7868c8133ee..ab96b22db3fe 100644
>> --- a/drivers/s390/net/qeth_core_main.c
>> +++ b/drivers/s390/net/qeth_core_main.c
>> @@ -218,7 +218,7 @@ static int qeth_alloc_buffer_pool(struct qeth_card *card)
>> void *ptr;
>> int i, j;
>>
>> -QETH_CARD_TEXT(card, 5, "alocpool");
>> +QETH_CARD_TEXT(card, 5, "allocpool");
>> for (i = 0; i < card->qdio.init_pool.buf_count; ++i) {
>> pool_entry = kzalloc(sizeof(*pool_entry), GFP_KERNEL);
>> if (!pool_entry) {
>>
>
Re: [PATCH 1/2] watchdog: qcom: support pre-timeout when the bark irq is available
On 10/09/19 11:06:55, Guenter Roeck wrote:
> On Fri, Sep 06, 2019 at 10:54:10PM +0200, Jorge Ramirez-Ortiz wrote:
> > Use the bark interrupt as the pre-timeout notifier whenever this
> > interrupt is available.
> >
> > By default, the pretimeout notification shall occur one second earlier
> > than the timeout.
> >
> > Signed-off-by: Jorge Ramirez-Ortiz
>
> Nitpick below, otherwise:
>
> Reviewed-by: Guenter Roeck
>
> > ---
> > drivers/watchdog/qcom-wdt.c | 70 ++---
> > 1 file changed, 65 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/watchdog/qcom-wdt.c b/drivers/watchdog/qcom-wdt.c
> > index 7be7f87be28f..935c78a882a3 100644
> > --- a/drivers/watchdog/qcom-wdt.c
> > +++ b/drivers/watchdog/qcom-wdt.c
> > @@ -1,8 +1,10 @@
> > // SPDX-License-Identifier: GPL-2.0-only
> > /* Copyright (c) 2014, The Linux Foundation. All rights reserved.
> > */
> > +#include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -19,6 +21,9 @@ enum wdt_reg {
> > WDT_BITE_TIME,
> > };
> >
> > +#define QCOM_WDT_ENABLEBIT(0)
> > +#define QCOM_WDT_ENABLE_IRQBIT(1)
> > +
> > static const u32 reg_offset_data_apcs_tmr[] = {
> > [WDT_RST] = 0x38,
> > [WDT_EN] = 0x40,
> > @@ -54,15 +59,35 @@ struct qcom_wdt *to_qcom_wdt(struct watchdog_device
> > *wdd)
> > return container_of(wdd, struct qcom_wdt, wdd);
> > }
> >
> > +static inline int qcom_get_enable(struct watchdog_device *wdd)
> > +{
> > + int enable = QCOM_WDT_ENABLE;
> > +
> > + if (wdd->pretimeout)
> > + enable |= QCOM_WDT_ENABLE_IRQ;
> > +
> > + return enable;
> > +}
> > +
> > +static irqreturn_t qcom_wdt_isr(int irq, void *arg)
> > +{
> > + struct watchdog_device *wdd = arg;
> > +
> > + watchdog_notify_pretimeout(wdd);
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > static int qcom_wdt_start(struct watchdog_device *wdd)
> > {
> > struct qcom_wdt *wdt = to_qcom_wdt(wdd);
> > + unsigned int bark = wdd->timeout - wdd->pretimeout;
> >
> > writel(0, wdt_addr(wdt, WDT_EN));
> > writel(1, wdt_addr(wdt, WDT_RST));
> > - writel(wdd->timeout * wdt->rate, wdt_addr(wdt, WDT_BARK_TIME));
> > + writel(bark * wdt->rate, wdt_addr(wdt, WDT_BARK_TIME));
> > writel(wdd->timeout * wdt->rate, wdt_addr(wdt, WDT_BITE_TIME));
> > - writel(1, wdt_addr(wdt, WDT_EN));
> > + writel(qcom_get_enable(wdd), wdt_addr(wdt, WDT_EN));
> > return 0;
> > }
> >
> > @@ -89,6 +114,13 @@ static int qcom_wdt_set_timeout(struct watchdog_device
> > *wdd,
> > return qcom_wdt_start(wdd);
> > }
> >
> > +static int qcom_wdt_set_pretimeout(struct watchdog_device *wdd,
> > + unsigned int timeout)
> > +{
> > + wdd->pretimeout = timeout;
> > + return qcom_wdt_start(wdd);
> > +}
> > +
> > static int qcom_wdt_restart(struct watchdog_device *wdd, unsigned long
> > action,
> > void *data)
> > {
> > @@ -105,7 +137,7 @@ static int qcom_wdt_restart(struct watchdog_device
> > *wdd, unsigned long action,
> > writel(1, wdt_addr(wdt, WDT_RST));
> > writel(timeout, wdt_addr(wdt, WDT_BARK_TIME));
> > writel(timeout, wdt_addr(wdt, WDT_BITE_TIME));
> > - writel(1, wdt_addr(wdt, WDT_EN));
> > + writel(QCOM_WDT_ENABLE, wdt_addr(wdt, WDT_EN));
> >
> > /*
> > * Actually make sure the above sequence hits hardware before sleeping.
> > @@ -121,6 +153,7 @@ static const struct watchdog_ops qcom_wdt_ops = {
> > .stop = qcom_wdt_stop,
> > .ping = qcom_wdt_ping,
> > .set_timeout= qcom_wdt_set_timeout,
> > + .set_pretimeout = qcom_wdt_set_pretimeout,
> > .restart= qcom_wdt_restart,
> > .owner = THIS_MODULE,
> > };
> > @@ -133,6 +166,15 @@ static const struct watchdog_info qcom_wdt_info = {
> > .identity = KBUILD_MODNAME,
> > };
> >
> > +static const struct watchdog_info qcom_wdt_pt_info = {
> > + .options= WDIOF_KEEPALIVEPING
> > + | WDIOF_MAGICCLOSE
> > + | WDIOF_SETTIMEOUT
> > + | WDIOF_PRETIMEOUT
> > + | WDIOF_CARDRESET,
> > + .identity = KBUILD_MODNAME,
> > +};
> > +
> > static void qcom_clk_disable_unprepare(void *data)
> > {
> > clk_disable_unprepare(data);
> > @@ -146,7 +188,7 @@ static int qcom_wdt_probe(struct platform_device *pdev)
> > struct device_node *np = dev->of_node;
> > const u32 *regs;
> > u32 percpu_offset;
> > - int ret;
> > + int irq, ret;
> >
> > regs = of_device_get_match_data(dev);
> > if (!regs) {
> > @@ -204,7 +246,25 @@ static int qcom_wdt_probe(struct platform_device *pdev)
> > return -EINVAL;
> > }
> >
> > - wdt->wdd.info = &qcom_wdt_info;
> > + /* check if there is pretimeout support */
> > + irq = platform_get_irq(pdev, 0);
> > + if (irq > 0) {
> > + ret = devm_request_irq(dev, irq, qcom_wdt_isr,
> >
[PATCH 2/3] kbuild: warn orphan obj-y objects
obj-y specifies objects linked into vmlinux, but they are actually
linked if and only if that sub-directory is visited by the chain of
obj-y. If you have an orphan obj-y object, it is a bug, but may not
easy to notice. This commit provides build-time warning.
I tested allmodconfig based on v5.3-rc4, and I saw one warning:
scripts/Makefile.build:57: 'sound/soc/sprd/sprd-mcdt.o' will not be linked to
vmlinux even though obj-y is specified.
This is a proper warning. sound/soc/sprd/sprd-mcdt.o is compiled as
built-in since CONFIG_SND_SOC_SPRD_MCDT is boolean. However, CONFIG_SND
and CONFIG_SND_SOC are tristate, and set to m by allmodconfig.
So, Kbuild descends into sound/soc/, then sound/soc/sprd/ by obj-m.
sound/soc/sprd/sprd-mcdt.o is not linked to vmlinux.
Signed-off-by: Masahiro Yamada
---
scripts/Makefile.build | 6 ++
scripts/link-vmlinux.sh | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 54fc68168686..d30b04707fec 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -52,6 +52,12 @@ ifndef obj
$(warning kbuild: Makefile.build is included improperly)
endif
+ifeq ($(need-builtin),)
+ifneq ($(real-obj-y),)
+$(warning '$(real-obj-y)' will not be linked to vmlinux even though obj-y is
specified.)
+endif
+endif
+
ifeq ($(need-modorder),)
ifneq ($(obj-m),)
$(warning $(patsubst %.o,'%.ko',$(obj-m)) will not be built even though obj-m
is specified.)
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 2438a9faf3f1..8961d999b86b 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -216,7 +216,7 @@ else
fi;
# final build of init/
-${MAKE} -f "${srctree}/scripts/Makefile.build" obj=init
+${MAKE} -f "${srctree}/scripts/Makefile.build" obj=init need-builtin=1
#link vmlinux.o
info LD vmlinux.o
--
2.17.1
[PATCH 3/3] kbuild: change need-modorder implementation slightly
Align with the need-builtin implementation. Signed-off-by: Masahiro Yamada --- scripts/Makefile.build | 2 +- scripts/Makefile.lib | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/scripts/Makefile.build b/scripts/Makefile.build index d30b04707fec..91617b9d7a34 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -528,7 +528,7 @@ $(subdir-ym): $(Q)$(MAKE) $(build)=$@ \ $(if $(filter $@/, $(KBUILD_SINGLE_TARGETS)),single-build=) \ need-builtin=$(if $(filter $@/built-in.a, $(subdir-obj-y)),1) \ - need-modorder=$(if $(need-modorder),$(if $(filter $@/modules.order, $(modorder)),1)) + need-modorder=$(if $(filter $@/modules.order, $(modorder)),1) # Add FORCE to the prequisites of a target to force it to be always rebuilt. # --- diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 07095d3789a1..034e92ea72c6 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -23,7 +23,9 @@ lib-y := $(filter-out $(obj-y), $(sort $(lib-y) $(lib-m))) # Determine modorder. # Unfortunately, we don't have information about ordering between -y # and -m subdirs. Just put -y's first. +ifdef need-modorder modorder := $(patsubst %/,%/modules.order, $(filter %/, $(obj-y)) $(obj-m:.o=.ko)) +endif # Handle objects in subdirs # --- -- 2.17.1
[PATCH 1/3] kbuild: do not create built-in.a that is never linked to vmlinux
Both 'obj-y += foo/' and 'obj-m += foo/' requrest Kbuild to visit the sub-directory foo/, but the difference is that only the former combines foo/built-in.a into the built-in.a of the current directory because everything in sub-directories visited by obj-m is supposed to be modular. So, it makes sense to create built-in.a only if that sub-directory is reachable by the chain of obj-y. Otherwise, built-in.a will not be linked into vmlinux anyway. If an orphan built-in.a is created, it is very likely a Makefile bug. Signed-off-by: Masahiro Yamada --- scripts/Makefile.build | 2 +- scripts/Makefile.lib | 4 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/scripts/Makefile.build b/scripts/Makefile.build index 9fa09361aa5d..54fc68168686 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -66,7 +66,7 @@ lib-target := $(obj)/lib.a real-obj-y += $(obj)/lib-ksyms.o endif -ifneq ($(strip $(real-obj-y) $(need-builtin)),) +ifdef need-builtin builtin-target := $(obj)/built-in.a endif diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 264611972c4a..07095d3789a1 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -35,7 +35,11 @@ __subdir-y := $(patsubst %/,%,$(filter %/, $(obj-y))) subdir-y += $(__subdir-y) __subdir-m := $(patsubst %/,%,$(filter %/, $(obj-m))) subdir-m += $(__subdir-m) +ifdef need-builtin obj-y := $(patsubst %/, %/built-in.a, $(obj-y)) +else +obj-y := $(filter-out %/, $(obj-y)) +endif obj-m := $(filter-out %/, $(obj-m)) # Subdirectories we need to descend into -- 2.17.1
Re: [PATCH] platform/x86: dell-laptop: fix phantom kbd backlight on Inspiron 10xx
On Thursday 12 September 2019 01:14:48 Pacien TRAN-GIRARD wrote: > This patch registers a quirk disabling keyboard backlight support > for the Dell Inspiron 1012 and 1018. > > Those models wrongly report supporting the KBD_LED_OFF_TOKEN and > KBD_LED_ON_TOKEN SMBIOS tokens, exposing keyboard brightness controls > through sysfs which freeze the system when used. > > The associated SMBIOS calls never return and cause the system to > hang, notably at boot when systemd-backlight tries to restore > previous brightness settings. Hi! This sounds like a firmware bug. Have you already reported it to Dell? > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=107651 > Signed-off-by: Pacien TRAN-GIRARD -- Pali Rohár pali.ro...@gmail.com
Re: [PATCH v5 0/4] virtio-fs: shared file system for virtual machines
On Wed, Sep 11, 2019 at 4:53 PM Vivek Goyal wrote: > > On Tue, Sep 10, 2019 at 05:12:02PM +0200, Miklos Szeredi wrote: > > Git tree for this version is available here: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git#virtiofs-v5 > > > > Only post patches that actually add virtiofs > > (virtiofs-v5-base..virtiofs-v5). > > > > I've folded the series from Vivek and fixed a couple of TODO comments > > myself. AFAICS two issues remain that need to be resolved in the short > > term, one way or the other: freeze/restore and full virtqueue. > > Hi Miklos, > > We are already handling full virtqueue by waiting a bit and retrying. > I think TODO in virtio_fs_enqueue_req() is stale. Caller already > handles virtqueue full situation by retrying. Ah. > > Havind said that, this could be improved by using some sort of wait > queue or completion privimitve. Yeah, the request queuing can be cleaned up in several ways. But I think that we might postpone that till after merging with mainline. Thanks, Miklos
Re: linux-next: Fixes tag needs some work in the pm tree
On Wed, Sep 11, 2019 at 07:17:52PM +0200, Rafael J. Wysocki wrote:
> On Wednesday, September 11, 2019 9:27:41 AM CEST Heikki Krogerus wrote:
> > On Wed, Sep 11, 2019 at 12:33:06AM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > In commit
> > >
> > > fd3f7275826f ("software node: Initialize the return value in
> > > software_node_find_by_name()")
> > >
> > > Fixes tag
> > >
> > > Fixes: 1666faedb567 ("software node: Add
> > > software_node_get_reference_args()")
> > >
> > > has these problem(s):
> > >
> > > - Subject does not match target commit subject
> > > Just use
> > > git log -1 --format='Fixes: %h ("%s")'
> > >
> > > Did you mean
> > >
> > > Fixes: 1666faedb567 ("software node: Add software_node_find_by_name()")
> > >
> > > or
> > >
> > > Fixes: b06184acf751 ("software node: Add
> > > software_node_get_reference_args()")
> >
> > Rafael, it seems you have rebased your branch.
>
> No, I haven't.
>
> Actually, the commit ID is correct, but the name isn't.
>
> You'd have been unlikely to get a valid commit ID matching anything with
> "software node" in the subject had it been rebased. :-)
Ah. I've added the tag line manually (for some reason). I'm sorry
about that. I usually use this:
% git show -s --abbrev-commit --abbrev=12 --pretty=format:"%h
(\"%s\")%n"
> > Do you want me to resend those fixes, or can you fix the tags in them
> > yourself?
>
> I fixed that tag up.
Thanks Rafael!
--
heikki
Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
On Wed, Sep 11, 2019 at 3:11 PM Jens Axboe wrote:
>
> On 9/11/19 12:43 PM, Dan Carpenter wrote:
> > On Wed, Sep 11, 2019 at 08:48:59AM -0700, Dan Williams wrote:
> >> +Coding Style Addendum
> >> +-
> >> +libnvdimm expects multi-line statements to be double indented. I.e.
> >> +
> >> +if (x...
> >> +&& ...y) {
> >
> > That looks horrible and it causes a checkpatch warning. :( Why not
> > do it the same way that everyone else does it.
> >
> > if (blah_blah_x && <-- && has to be on the first line for checkpatch
> > blah_blah_y) { <-- [tab][space][space][space][space]blah
> >
> > Now all the conditions are aligned visually which makes it readable.
> > They aren't aligned with the indent block so it's easy to tell the
> > inside from the if condition.
> >
> > I kind of hate all this extra documentation because now everyone thinks
> > they can invent new hoops to jump through.
>
> FWIW, I completely agree with Dan (Carpenter) here. I absolutely
> dislike having these kinds of files, and with subsystems imposing weird
> restrictions on style (like the quoted example, yuck).
>
> Additionally, it would seem saner to standardize rules around when
> code is expected to hit the maintainers hands for kernel releases. Both
> yours and Martins deals with that, there really shouldn't be the need
> to have this specified in detail per sub-system.
So this is *the* point of the exercise.
I picked up this indentation habit a long while back in response to
review feedback on a patch to a subsystem that formatted code this
way. At the time CodingStyle did not contradict the maintainer's
preference, so I adopted it across the board.
Now I come to find that CodingStyle has settled on clang-format (in
the last 15 months) as the new standard which is a much better answer
to me than a manually specified style open to interpretation. I'll
take a look at getting libnvdimm converted over.
If we can take that further and standardize all of the places where
contributors see variations across subsystems on the fundamental
questions of style, timing, follow-up, and unit test invocation the
Maintainer Entry Profile can be superseded with common guidelines.
Otherwise, yes I completely agree with you that a "Maintainer Entry
Profile" is a sad comment on the state of what contributors need to
navigate, but that's today's reality that needs to be addressed.
[PATCH] powerpc: improve prom_init_check rule
This slightly improves the prom_init_check rule. [1] Avoid needless check Currently, prom_init_check.sh is invoked every time you run 'make' even if you have changed nothing in prom_init.c. With this commit, the script is re-run only when prom_init.o is recompiled. [2] Beautify the build log Currently, the O= build shows the absolute path to the script: CALL/abs/path/to/source/of/linux/arch/powerpc/kernel/prom_init_check.sh With this commit, it is always a relative path to the timestamp file: PROMCHK arch/powerpc/kernel/prom_init_check Signed-off-by: Masahiro Yamada --- arch/powerpc/kernel/.gitignore | 1 + arch/powerpc/kernel/Makefile | 14 ++ 2 files changed, 7 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/kernel/.gitignore b/arch/powerpc/kernel/.gitignore index c5f676c3c224..67ebd3003c05 100644 --- a/arch/powerpc/kernel/.gitignore +++ b/arch/powerpc/kernel/.gitignore @@ -1 +1,2 @@ +prom_init_check vmlinux.lds diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile index 56dfa7a2a6f2..07bf5a45f176 100644 --- a/arch/powerpc/kernel/Makefile +++ b/arch/powerpc/kernel/Makefile @@ -184,15 +184,13 @@ extra-$(CONFIG_ALTIVEC) += vector.o extra-$(CONFIG_PPC64) += entry_64.o extra-$(CONFIG_PPC_OF_BOOT_TRAMPOLINE) += prom_init.o -ifdef CONFIG_PPC_OF_BOOT_TRAMPOLINE -$(obj)/built-in.a: prom_init_check +extra-$(CONFIG_PPC_OF_BOOT_TRAMPOLINE) += prom_init_check -quiet_cmd_prom_init_check = CALL$< - cmd_prom_init_check = $(CONFIG_SHELL) $< "$(NM)" "$(obj)/prom_init.o" +quiet_cmd_prom_init_check = PROMCHK $@ + cmd_prom_init_check = $(CONFIG_SHELL) $< "$(NM)" $(obj)/prom_init.o; touch $@ -PHONY += prom_init_check -prom_init_check: $(src)/prom_init_check.sh $(obj)/prom_init.o - $(call cmd,prom_init_check) -endif +$(obj)/prom_init_check: $(src)/prom_init_check.sh $(obj)/prom_init.o FORCE + $(call if_changed,prom_init_check) +targets += prom_init_check clean-files := vmlinux.lds -- 2.17.1
Re: [PATCH v9 0/8] stg mail -e --version=v9 \
On 12.09.19 09:16, Michal Hocko wrote:
> On Wed 11-09-19 18:09:18, David Hildenbrand wrote:
>> On 11.09.19 15:51, Michal Hocko wrote:
>>> On Wed 11-09-19 15:20:02, Michal Hocko wrote:
>>> [...]
> 4. Continuously report, not the "one time report everything" approach.
So you mean the allocator reporting this rather than an external code to
poll right? I do not know, how much this is nice to have than must have?
>>>
>>> Another idea that I haven't really thought through so it might turned
>>> out to be completely bogus but let's try anyway. Your "report everything"
>>> just made me look and realize that free_pages_prepare already performs
>>> stuff that actually does something similar yet unrelated.
>>>
>>> We do report to special page poisoning, zeroying or
>>> CONFIG_DEBUG_PAGEALLOC to unmap the address from the kernel address
>>> space. This sounds like something fitting your model no?
>>>
>>
>> AFAIKS, the poisoning/unmapping is done whenever a page is freed. I
>> don't quite see yet how that would help to remember if a page was
>> already reported.
>
> Do you still have to differ that state when each page is reported?
Ah, very good point. I can see that the reason for this was not
discussed in this thread so far. (Alexander, Nitesh, please correct me
if I am wrong). It's buried in the long history of free page
hinting/reporting.
Some early patch sets tried to report during every free synchronously.
Free a page, report them to the hypervisor. This resulted in some issues
(especially, locking-related and the virtio + the hypervisor being
involved, resulting in unpredictable delays, quite some overhead ...).
It was no good.
One design decision then was to not report single pages, but a bunch of
pages at once. This made it necessary to "remember" the pages to be
reported and to temporarily block them from getting allocated while
reporting.
Nitesh implemented (at least) two "capture PFNs of free pages in an
array when freeing" approaches. One being synchronous from the freeing
CPU once the list was full (having similar issues as plain synchronous
reporting) and one being asynchronous by a separate thread (which solved
many locking issues).
Turned out the a simple array can quickly lead to us having to drop
"reports" to the hypervisor because the array is full and the reporting
thread was not able to keep up. Not good as well. Especially, if some
process frees a lot of memory this can happen quickly and Nitesh wa
sable to trigger this scenario frequently.
Finally, Nitesh decided to use the bitmap instead to keep track of pages
to report. I'd like to note that this approach could still be combined
with an "array of potentially free PFNs". Only when the array/circular
buffer runs out of entries ("reporting thread cannot keep up"), we would
have to go back to scanning the bitmap.
That was also the point where Alexander decided to look into integrating
tracking/handling reported/unreported pages directly in the buddy.
>
>> After reporting the page we would have to switch some
>> state (Nitesh: bitmap bit, Alexander: page flag) to identify that.
>
> Yes, you can either store the state somewhere.
>
>> Of course, we could map the page and treat that as "the state" when we
>> reported it, but I am not sure that's such a good idea :)
>>
>> As always, I might be very wrong ...
>
> I still do not fully understand the usecase so I might be equally wrong.
> My thinking is along these lines. Why should you scan free pages when
> you can effectively capture each freed page? If you go one step further
> then post_alloc_hook would be the counterpart to know that your page has
> been allocated.
I'd like to note that Nitesh's patch set contains the following hunk,
which is roughly what you were thinking :)
-static inline void __free_one_page(struct page *page,
+inline void __free_one_page(struct page *page,
unsigned long pfn,
struct zone *zone, unsigned int order,
- int migratetype)
+ int migratetype, bool hint)
{
unsigned long combined_pfn;
unsigned long uninitialized_var(buddy_pfn);
@@ -980,7 +981,8 @@ static inline void __free_one_page(struct page *page,
migratetype);
else
add_to_free_area(page, &zone->free_area[order], migratetype);
-
+ if (hint)
+ page_hinting_enqueue(page, order);
}
(ignore the hint parameter, when he would switch to a isolate vs.
alloc/free, that can go away and all we left is the enqueue part)
Inside that callback we can remember the pages any way we want. Right
now in a bitmap. Maybe later in a array + bitmap (as discussed above).
Another idea I had was to simply go over all pages and report them when
running into this "array full" condition. But I am not yet sure about
the performance implications on rather large machines. So the bitmap
idea might have some other limitations but seems to do its job.
Hoe that mak
Re: [PATCH] KVM: s390: Remove unused parameter from __inject_sigp_restart()
On 9/12/19 9:02 AM, Thomas Huth wrote:
> It's not required, so drop it to make it clear that this interrupt
> does not have any extra parameters.
>
> Signed-off-by: Thomas Huth
Well there's no real use for any other parameter than the target cpu, so:
Reviewed-by: Janosch Frank
> ---
> arch/s390/kvm/interrupt.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
> index b5fd6e85657c..3e7efdd9228a 100644
> --- a/arch/s390/kvm/interrupt.c
> +++ b/arch/s390/kvm/interrupt.c
> @@ -1477,8 +1477,7 @@ static int __inject_sigp_stop(struct kvm_vcpu *vcpu,
> struct kvm_s390_irq *irq)
> return 0;
> }
>
> -static int __inject_sigp_restart(struct kvm_vcpu *vcpu,
> - struct kvm_s390_irq *irq)
> +static int __inject_sigp_restart(struct kvm_vcpu *vcpu)
> {
> struct kvm_s390_local_interrupt *li = &vcpu->arch.local_int;
>
> @@ -1997,7 +1996,7 @@ static int do_inject_vcpu(struct kvm_vcpu *vcpu, struct
> kvm_s390_irq *irq)
> rc = __inject_sigp_stop(vcpu, irq);
> break;
> case KVM_S390_RESTART:
> - rc = __inject_sigp_restart(vcpu, irq);
> + rc = __inject_sigp_restart(vcpu);
> break;
> case KVM_S390_INT_CLOCK_COMP:
> rc = __inject_ckc(vcpu);
>
signature.asc
Description: OpenPGP digital signature
[PATCH v1 0/2] pinctrl: Add new pinctrl/GPIO driver
Hi, This series is to add pinctrl & GPIO controller driver for a new SoC. Patch 1 adds pinmux & GPIO controller driver. Patch 2 adds the dt bindings document & include file. Patches are against Linux 5.3-rc5 at below Git tree: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git Rahul Tanwar (2): pinctrl: Add pinmux & GPIO controller driver for new SoC dt-bindings: pinctrl: intel: Add for new SoC .../bindings/pinctrl/intel,lgm-pinctrl.yaml| 131 ++ drivers/pinctrl/Kconfig| 13 + drivers/pinctrl/Makefile |1 + drivers/pinctrl/pinctrl-equilibrium.c | 1377 drivers/pinctrl/pinctrl-equilibrium.h | 194 +++ include/dt-bindings/pinctrl/intel,equilibrium.h| 23 + 6 files changed, 1739 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/intel,lgm-pinctrl.yaml create mode 100644 drivers/pinctrl/pinctrl-equilibrium.c create mode 100644 drivers/pinctrl/pinctrl-equilibrium.h create mode 100644 include/dt-bindings/pinctrl/intel,equilibrium.h -- 2.11.0
[PATCH v1 2/2] dt-bindings: pinctrl: intel: Add for new SoC
Add dt bindings document & include file for pinmux & GPIO controller driver of
Intel Lightning Mountain SoC.
Signed-off-by: Rahul Tanwar
---
.../bindings/pinctrl/intel,lgm-pinctrl.yaml| 131 +
include/dt-bindings/pinctrl/intel,equilibrium.h| 23
2 files changed, 154 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/intel,lgm-pinctrl.yaml
create mode 100644 include/dt-bindings/pinctrl/intel,equilibrium.h
diff --git a/Documentation/devicetree/bindings/pinctrl/intel,lgm-pinctrl.yaml
b/Documentation/devicetree/bindings/pinctrl/intel,lgm-pinctrl.yaml
new file mode 100644
index ..1aee42f0057e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/intel,lgm-pinctrl.yaml
@@ -0,0 +1,131 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bindings/pinctrl/intel,lgm-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel Lightning Mountain SoC pinmux & GPIO controller binding
+
+maintainers:
+ - Rahul Tanwar
+
+description: |
+ Pinmux & GPIO controller controls pin multiplexing & configuration including
+ GPIO function selection & GPIO attributes configuration.
+
+ Please refer to [1] for details of the common pinctrl bindings used by the
+ client devices.
+
+ [1] Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+
+properties:
+ compatible:
+const: intel,lgm-pinctrl
+
+ reg:
+maxItems: 1
+
+# Client device subnode's properties
+patternProperties:
+ "^.*@[0-9a-fA-F]+$":
+type: object
+description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below defined properties.
+
+properties:
+ intel,function:
+$ref: /schemas/types.yaml#/definitions/string
+description:
+ A string containing the name of the function to mux to the group.
+
+ intel,groups:
+$ref: /schemas/types.yaml#/definitions/string-array
+description:
+ An array of strings identifying the list of groups.
+
+ intel,pins:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+description:
+ List of pins to select with this function.
+
+ intel,mux:
+description: The applicable mux group.
+allOf:
+ - $ref: "/schemas/types.yaml#/definitions/uint32"
+ - enum:
+ # Refer include/dt-bindings/pinctrl/intel,equilibrium.h
+ - PINMUX_0 # 0 PINMUX_GPIO
+ - PINMUX_1 # 1
+ - PINMUX_2 # 2
+ - PINMUX_3 # 3
+ - PINMUX_4 # 4
+
+ intel,pullup:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: Specifies pull-up configuration.
+
+ intel,pulldown:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: Specifies pull-down configuration.
+
+ intel,drive-current:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: Enables driver-current.
+
+ intel,slew-rate:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: Enables slew-rate.
+
+ intel,open-drain:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: Specifies open-drain configuration.
+
+ intel,output:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: Specifies if the pin is to be configured as output.
+
+
+required:
+ - intel,function
+ - intel,groups
+
+required:
+ - compatible
+ - reg
+
+examples:
+ # Pinmux controller node
+ - |
+pinctrl: pinctrl@e288 {
+ compatible = "intel,lgm-pinctrl";
+ reg = <0xe288 0x10>;
+};
+
+ # Client device node
+ - |
+asc0: serial@e0a0 {
+ compatible = "intel,lgm-asc";
+ reg = <0xe0a0 0x1000>;
+ interrupt-parent = <&ioapic1>;
+ interrupts = <128 1>;
+ interrupt-names = "asc_irq";
+ clocks = <&cgu0 31>, <&cgu0 98>;
+ clock-names = "freq", "asc";
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0>;
+};
+
+ # Client device subnode
+ - |
+uart0:uart0 {
+ intel,pins = <64>, /* UART_RX0 */
+ <65>; /* UART_TX0 */
+ intel,function = "CONSOLE_UART0";
+ intel,mux = <1>,
+ <1>;
+ intel,groups = "CONSOLE_UART0";
+};
+
+
+...
diff --git a/include/dt-bindings/pinctrl/intel,equilibrium.h
b/include/dt-bindings/pinctrl/intel,equilibrium.h
new file mode 100644
index ..c37bfbea8ff1
--- /dev/null
+++ b/include/dt-bindings/pinctrl/intel,equilibrium.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __DT_BINDINGS_PINCTRL_INTEL_EQUILIBRIUM_H_
+#define __DT_BINDINGS_PINCTRL_INTEL_EQUILIBRIUM_H_
+
+#define PINCTRL_DRCC_2_MA 0
+#define PINCTRL_DRCC_4_MA 1
+#define PINCTRL_DRCC_8_MA 2
+#defi
[PATCH v1 1/2] pinctrl: Add pinmux & GPIO controller driver for new SoC
Intel Lightning Mountain SoC has a pinmux controller & GPIO controller IP
which controls pin multiplexing & configuration including GPIO functions
selection & GPIO attributes configuration. Add GPIO & pin control framework
based driver for this IP.
Signed-off-by: Rahul Tanwar
---
drivers/pinctrl/Kconfig | 13 +
drivers/pinctrl/Makefile |1 +
drivers/pinctrl/pinctrl-equilibrium.c | 1377 +
drivers/pinctrl/pinctrl-equilibrium.h | 194 +
4 files changed, 1585 insertions(+)
create mode 100644 drivers/pinctrl/pinctrl-equilibrium.c
create mode 100644 drivers/pinctrl/pinctrl-equilibrium.h
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index b372419d61f2..99f20099b8eb 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -420,4 +420,17 @@ config PINCTRL_TB10X
depends on OF && ARC_PLAT_TB10X
select GPIOLIB
+config PINCTRL_EQUILIBRIUM
+ tristate "Generic pinctrl and GPIO driver for Intel Lightning Mountain
SoC"
+ select PINMUX
+ select PINCONF
+ select GPIOLIB
+ select GPIOLIB_IRQCHIP
+ help
+ Equilibrium pinctrl driver is a pinctrl & GPIO driver for Intel
Lightning
+ Mountain network processor SoC that supports both the linux GPIO and
pin
+ control frameworks. It provides interfaces to setup pinmux, assign
desired
+ pin functions, configure GPIO attributes for LGM SoC pins. Pinmux and
+ pinconf settings are retrieved from device tree.
+
endif
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index ac537fdbc998..879f312bfb75 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_PINCTRL_ZYNQ)+= pinctrl-zynq.o
obj-$(CONFIG_PINCTRL_INGENIC) += pinctrl-ingenic.o
obj-$(CONFIG_PINCTRL_RK805)+= pinctrl-rk805.o
obj-$(CONFIG_PINCTRL_OCELOT) += pinctrl-ocelot.o
+obj-$(CONFIG_PINCTRL_EQUILIBRIUM) += pinctrl-equilibrium.o
obj-y += actions/
obj-$(CONFIG_ARCH_ASPEED) += aspeed/
diff --git a/drivers/pinctrl/pinctrl-equilibrium.c
b/drivers/pinctrl/pinctrl-equilibrium.c
new file mode 100644
index ..abe522cdffbe
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-equilibrium.c
@@ -0,0 +1,1377 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2019 Intel Corporation */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include "pinctrl-equilibrium.h"
+
+#define PIN_NAME_FMT "io-%d"
+#define PIN_NAME_LEN 10
+#define PAD_REG_OFF0x100
+
+static const struct pin_config pin_cfg_type[] = {
+ {"intel,pullup",PINCONF_TYPE_PULL_UP},
+ {"intel,pulldown", PINCONF_TYPE_PULL_DOWN},
+ {"intel,drive-current", PINCONF_TYPE_DRIVE_CURRENT},
+ {"intel,slew-rate", PINCONF_TYPE_SLEW_RATE},
+ {"intel,open-drain",PINCONF_TYPE_OPEN_DRAIN},
+ {"intel,output",PINCONF_TYPE_OUTPUT},
+};
+
+static inline void eqbr_set_val(void __iomem *addr, u32 offset,
+ u32 mask, u32 set, raw_spinlock_t *lock)
+{
+ u32 val;
+ unsigned long flags;
+
+ raw_spin_lock_irqsave(lock, flags);
+ val = readl(addr) & ~(mask << offset);
+ writel(val | ((set & mask) << offset), addr);
+ raw_spin_unlock_irqrestore(lock, flags);
+}
+
+static int eqbr_irq_map(struct irq_domain *d,
+ unsigned int virq, irq_hw_number_t hw)
+{
+ struct intel_gpio_desc *desc = d->host_data;
+
+ irq_set_chip_data(virq, desc);
+ irq_set_chip_and_handler(virq, desc->ic, handle_level_irq);
+ return 0;
+}
+
+static const struct irq_domain_ops gc_irqdomain_ops = {
+ .map= eqbr_irq_map,
+ .xlate = irq_domain_xlate_twocell,
+};
+
+/* get direction 0 is out, 1 is in */
+static int intel_eqbr_gpio_get_dir(struct gpio_chip *gc, unsigned int offset)
+{
+ struct intel_gpio_desc *desc = gpiochip_get_data(gc);
+
+ return !(readl(desc->membase + GPIO_DIR) & BIT(offset));
+}
+
+static int intel_eqbr_gpio_dir_input(struct gpio_chip *gc, unsigned int offset)
+{
+ struct intel_gpio_desc *desc = gpiochip_get_data(gc);
+
+ writel(BIT(offset), desc->membase + GPIO_DIRCLR);
+ return 0;
+}
+
+static int intel_eqbr_gpio_dir_output(struct gpio_chip *gc, unsigned int
offset,
+ int value)
+{
+ struct intel_gpio_desc *desc = gpiochip_get_data(gc);
+
+ if (value)
+ writel(BIT(offset), desc->membase + GPIO_OUTSET);
+ else
+ writel(BIT(offset), desc->membase + GPIO_OUTCLR);
+
+ writel(BIT(offset), desc->membase + GPIO_DIRSET);
+ return 0;
+}
+
+static void intel_eqbr_gpio_set(struct gpio_chip *gc,
+ unsigned int offset, int dir)
+{
+
Re: [PATCH 00/13] nvdimm: Use more common kernel coding style
Hi Joe, On Wed, Sep 11, 2019 at 7:55 PM Joe Perches wrote: > > Rather than have a local coding style, use the typical kernel style. I'd rather automate this. I'm going to do once-over with clang-format and see what falls out.
KASAN: use-after-free Read in __xfrm_decode_session
Hello, syzbot found the following crash on: HEAD commit:6d028043 Add linux-next specific files for 20190830 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=150de9b960 kernel config: https://syzkaller.appspot.com/x/.config?x=82a6bec43ab0cb69 dashboard link: https://syzkaller.appspot.com/bug?extid=55d9cf7c57894c1e4860 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+55d9cf7c57894c1e4...@syzkaller.appspotmail.com == BUG: KASAN: use-after-free in decode_session6 net/xfrm/xfrm_policy.c:3390 [inline] BUG: KASAN: use-after-free in __xfrm_decode_session+0x1cfb/0x2e90 net/xfrm/xfrm_policy.c:3482 Read of size 1 at addr 88805cdb288e by task syz-executor.0/24778 CPU: 0 PID: 24778 Comm: syz-executor.0 Not tainted 5.3.0-rc6-next-20190830 #75 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+0x172/0x1f0 lib/dump_stack.c:113 print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374 __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:634 __asan_report_load1_noabort+0x14/0x20 mm/kasan/generic_report.c:129 decode_session6 net/xfrm/xfrm_policy.c:3390 [inline] __xfrm_decode_session+0x1cfb/0x2e90 net/xfrm/xfrm_policy.c:3482 xfrm_decode_session_reverse include/net/xfrm.h:1144 [inline] icmpv6_route_lookup+0x31b/0x4d0 net/ipv6/icmp.c:369 icmp6_send+0x129e/0x1e20 net/ipv6/icmp.c:557 icmpv6_send+0xec/0x230 net/ipv6/ip6_icmp.c:43 ip6_link_failure+0x2b/0x530 net/ipv6/route.c:2640 dst_link_failure include/net/dst.h:419 [inline] ip6_tnl_xmit+0x45b/0x33f0 net/ipv6/ip6_tunnel.c:1222 ip6ip6_tnl_xmit net/ipv6/ip6_tunnel.c:1376 [inline] ip6_tnl_start_xmit+0x847/0x1c90 net/ipv6/ip6_tunnel.c:1402 __netdev_start_xmit include/linux/netdevice.h:4419 [inline] netdev_start_xmit include/linux/netdevice.h:4433 [inline] xmit_one net/core/dev.c:3280 [inline] dev_hard_start_xmit+0x1a3/0x9c0 net/core/dev.c:3296 sch_direct_xmit+0x372/0xc30 net/sched/sch_generic.c:308 qdisc_restart net/sched/sch_generic.c:371 [inline] __qdisc_run+0x586/0x19d0 net/sched/sch_generic.c:379 __dev_xmit_skb net/core/dev.c:3533 [inline] __dev_queue_xmit+0x16f1/0x37c0 net/core/dev.c:3838 dev_queue_xmit+0x18/0x20 net/core/dev.c:3902 neigh_direct_output+0x16/0x20 net/core/neighbour.c:1530 neigh_output include/net/neighbour.h:511 [inline] ip6_finish_output2+0x1034/0x2550 net/ipv6/ip6_output.c:116 __ip6_finish_output+0x444/0xaa0 net/ipv6/ip6_output.c:142 ip6_finish_output+0x38/0x1f0 net/ipv6/ip6_output.c:152 NF_HOOK_COND include/linux/netfilter.h:294 [inline] ip6_output+0x235/0x7f0 net/ipv6/ip6_output.c:175 dst_output include/net/dst.h:436 [inline] NF_HOOK include/linux/netfilter.h:305 [inline] NF_HOOK include/linux/netfilter.h:299 [inline] ip6_xmit+0xe35/0x20b0 net/ipv6/ip6_output.c:279 inet6_csk_xmit+0x2fb/0x5d0 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x1a2f/0x3820 net/ipv4/tcp_output.c:1158 tcp_transmit_skb net/ipv4/tcp_output.c:1174 [inline] tcp_send_syn_data net/ipv4/tcp_output.c:3505 [inline] tcp_connect+0x1be7/0x4320 net/ipv4/tcp_output.c:3570 tcp_sendmsg_fastopen net/ipv4/tcp.c:1155 [inline] tcp_sendmsg_locked+0x2898/0x3220 net/ipv4/tcp.c:1206 tcp_sendmsg+0x30/0x50 net/ipv4/tcp.c:1434 inet6_sendmsg+0x9e/0xe0 net/ipv6/af_inet6.c:576 sock_sendmsg_nosec net/socket.c:637 [inline] sock_sendmsg+0xd7/0x130 net/socket.c:657 __sys_sendto+0x262/0x380 net/socket.c:1952 __do_sys_sendto net/socket.c:1964 [inline] __se_sys_sendto net/socket.c:1960 [inline] __x64_sys_sendto+0xe1/0x1a0 net/socket.c:1960 do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4598e9 Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f83d1625c78 EFLAGS: 0246 ORIG_RAX: 002c RAX: ffda RBX: 0006 RCX: 004598e9 RDX: 0001 RSI: 2340 RDI: 0003 RBP: 0075bfc8 R08: R09: R10: 200400cf R11: 0246 R12: 7f83d16266d4 R13: 004c7880 R14: 004dd188 R15: Allocated by task 3891: save_stack+0x23/0x90 mm/kasan/common.c:69 set_track mm/kasan/common.c:77 [inline] __kasan_kmalloc mm/kasan/common.c:510 [inline] __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:483 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:524 __do_kmalloc mm/slab.c:3655 [inline] __kmalloc+0x163/0x770 mm/slab.c:3664 kmalloc include/linux/slab.h:
[PATCH v2] kbuild: change need-modorder implementation slightly
Align with the need-builtin implementation.
I also added need-modorder=1 to scripts/link-vmlinux.sh for future-proof;
Currently, we have no module in the init/ directory, but if we had a one,
scripts/Makefile.build would show the false positive warning.
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Add need-modorder=1 to link-vmlinux.sh
scripts/Makefile.build | 2 +-
scripts/Makefile.lib| 2 ++
scripts/link-vmlinux.sh | 2 +-
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index d30b04707fec..91617b9d7a34 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -528,7 +528,7 @@ $(subdir-ym):
$(Q)$(MAKE) $(build)=$@ \
$(if $(filter $@/, $(KBUILD_SINGLE_TARGETS)),single-build=) \
need-builtin=$(if $(filter $@/built-in.a, $(subdir-obj-y)),1) \
- need-modorder=$(if $(need-modorder),$(if $(filter $@/modules.order,
$(modorder)),1))
+ need-modorder=$(if $(filter $@/modules.order, $(modorder)),1)
# Add FORCE to the prequisites of a target to force it to be always rebuilt.
# ---
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 07095d3789a1..034e92ea72c6 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -23,7 +23,9 @@ lib-y := $(filter-out $(obj-y), $(sort $(lib-y) $(lib-m)))
# Determine modorder.
# Unfortunately, we don't have information about ordering between -y
# and -m subdirs. Just put -y's first.
+ifdef need-modorder
modorder := $(patsubst %/,%/modules.order, $(filter %/, $(obj-y))
$(obj-m:.o=.ko))
+endif
# Handle objects in subdirs
# ---
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 8961d999b86b..d9edfba54d84 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -216,7 +216,7 @@ else
fi;
# final build of init/
-${MAKE} -f "${srctree}/scripts/Makefile.build" obj=init need-builtin=1
+${MAKE} -f "${srctree}/scripts/Makefile.build" obj=init need-builtin=1
need-modorder=1
#link vmlinux.o
info LD vmlinux.o
--
2.17.1
Re: [PATCH] rtc: wilco-ec: Sanitize values received from RTC
Hi Nick,
On 10/09/2019 16:19:29+0100, Nick Crews wrote:
> Check that the time received from the RTC HW is valid,
> otherwise the computation of rtc_year_days() in the next
> line could, and sometimes does, crash the kernel.
>
> While we're at it, fix the license to plain "GPL".
>
> Signed-off-by: Nick Crews
> ---
> drivers/rtc/rtc-wilco-ec.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/rtc/rtc-wilco-ec.c b/drivers/rtc/rtc-wilco-ec.c
> index 8ad4c4e6d557..0ccbf2dce832 100644
> --- a/drivers/rtc/rtc-wilco-ec.c
> +++ b/drivers/rtc/rtc-wilco-ec.c
> @@ -110,8 +110,16 @@ static int wilco_ec_rtc_read(struct device *dev, struct
> rtc_time *tm)
> tm->tm_mday = rtc.day;
> tm->tm_mon = rtc.month - 1;
> tm->tm_year = rtc.year + (rtc.century * 100) - 1900;
> - tm->tm_yday = rtc_year_days(tm->tm_mday, tm->tm_mon, tm->tm_year);
If your driver doesn't care about yday, userspace doesn't either. You
can simply not set it.
>
> + if (rtc_valid_tm(tm)) {
> + dev_warn(dev,
> + "Time computed from EC RTC is invalid: sec=%d, min=%d,
> hour=%d, mday=%d, mon=%d, year=%d",
> + tm->tm_sec, tm->tm_min, tm->tm_hour, tm->mday,
> + tm->mon, tm->year);
> + return -EIO;
> + }
> +
> + tm->tm_yday = rtc_year_days(tm->tm_mday, tm->tm_mon, tm->tm_year);
> /* Don't compute day of week, we don't need it. */
> tm->tm_wday = -1;
>
> @@ -188,5 +196,5 @@ module_platform_driver(wilco_ec_rtc_driver);
>
> MODULE_ALIAS("platform:rtc-wilco-ec");
> MODULE_AUTHOR("Nick Crews ");
> -MODULE_LICENSE("GPL v2");
> +MODULE_LICENSE("GPL");
This should be in a separate patch.
> MODULE_DESCRIPTION("Wilco EC RTC driver");
> --
> 2.11.0
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[GIT PULL] final GPIO fixes for v5.3
Hi Linus, I don't really like to send so many fixes at the very last minute, but the bug-sport activity is unpredictable. Four out of three are -stable material that will go everywhere, one is for the current cycle. Please pull them in! Yours, Linus Walleij The following changes since commit f74c2bb98776e2de508f4d607cd519873065118e: Linux 5.3-rc8 (2019-09-08 13:33:15 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git tags/gpio-v5.3-6 for you to fetch changes up to 61f7f7c8f978b1c0d80e43c83b7d110ca0496eb4: gpiolib: acpi: Add gpiolib_acpi_run_edge_events_on_boot option and blacklist (2019-09-11 10:46:54 +0100) GPIO fixes for v5.3: - An ACPI DSDT error fixup of the type we always see and Hans invariably gets to fix. - A OF quirk fix for the current release (v5.3) - Some consistency checks on the userspace ABI. - A memory leak. Dmitry Torokhov (1): gpiolib: of: fix fallback quirks handling Hans de Goede (1): gpiolib: acpi: Add gpiolib_acpi_run_edge_events_on_boot option and blacklist Kent Gibson (2): gpio: fix line flag validation in linehandle_create gpio: fix line flag validation in lineevent_create Linus Walleij (1): Merge tag 'gpio-v5.4-fixes-for-linus' of git://git.kernel.org/.../brgl/linux into fixes Wei Yongjun (1): gpio: mockup: add missing single_release() drivers/gpio/gpio-mockup.c | 1 + drivers/gpio/gpiolib-acpi.c | 42 ++ drivers/gpio/gpiolib-of.c | 27 +-- drivers/gpio/gpiolib.c | 16 +++- 4 files changed, 59 insertions(+), 27 deletions(-)
[no subject]
>From 66208ef7fcdb4176bf63cd130b3e3197086ac4b3 Mon Sep 17 00:00:00 2001 From: Gene Chen Date: Thu, 22 Aug 2019 14:21:03 +0800 Subject: [PATCH] mfd: mt6360: add pmic mt6360 driver --- drivers/mfd/Kconfig | 12 ++ drivers/mfd/Makefile | 1 + drivers/mfd/mt6360-core.c | 463 ++ 3 files changed, 476 insertions(+) create mode 100644 drivers/mfd/mt6360-core.c diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index f129f96..a422c76 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -862,6 +862,18 @@ config MFD_MAX8998 additional drivers must be enabled in order to use the functionality of the device. +config MFD_MT6360 + tristate "Mediatek MT6360 SubPMIC" + select MFD_CORE + select REGMAP_I2C + select REGMAP_IRQ + depends on I2C + help + Say Y here to enable MT6360 PMU/PMIC/LDO functional support. + PMU part include charger, flashlight, rgb led + PMIC part include 2-channel BUCKs and 2-channel LDOs + LDO part include 4-channel LDOs + config MFD_MT6397 tristate "MediaTek MT6397 PMIC Support" select MFD_CORE diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index f026ada..77a8f0b 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -241,6 +241,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC)+= intel-soc-pmic.o obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC) += intel_soc_pmic_bxtwc.o obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI) += intel_soc_pmic_chtdc_ti.o +obj-$(CONFIG_MFD_MT6360) += mt6360-core.o obj-$(CONFIG_MFD_MT6397) += mt6397-core.o obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o diff --git a/drivers/mfd/mt6360-core.c b/drivers/mfd/mt6360-core.c new file mode 100644 index 000..d3580618 --- /dev/null +++ b/drivers/mfd/mt6360-core.c @@ -0,0 +1,463 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2019 MediaTek Inc. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +/* reg 0 -> 0 ~ 7 */ +#define MT6360_CHG_TREG_EVT(4) +#define MT6360_CHG_AICR_EVT(5) +#define MT6360_CHG_MIVR_EVT(6) +#define MT6360_PWR_RDY_EVT (7) +/* REG 1 -> 8 ~ 15 */ +#define MT6360_CHG_BATSYSUV_EVT(9) +#define MT6360_FLED_CHG_VINOVP_EVT (11) +#define MT6360_CHG_VSYSUV_EVT (12) +#define MT6360_CHG_VSYSOV_EVT (13) +#define MT6360_CHG_VBATOV_EVT (14) +#define MT6360_CHG_VBUSOV_EVT (15) +/* REG 2 -> 16 ~ 23 */ +/* REG 3 -> 24 ~ 31 */ +#define MT6360_WD_PMU_DET (25) +#define MT6360_WD_PMU_DONE (26) +#define MT6360_CHG_TMRI(27) +#define MT6360_CHG_ADPBADI (29) +#define MT6360_CHG_RVPI(30) +#define MT6360_OTPI(31) +/* REG 4 -> 32 ~ 39 */ +#define MT6360_CHG_AICCMEASL (32) +#define MT6360_CHGDET_DONEI(34) +#define MT6360_WDTMRI (35) +#define MT6360_SSFINISHI (36) +#define MT6360_CHG_RECHGI (37) +#define MT6360_CHG_TERMI (38) +#define MT6360_CHG_IEOCI (39) +/* REG 5 -> 40 ~ 47 */ +#define MT6360_PUMPX_DONEI (40) +#define MT6360_BAT_OVP_ADC_EVT (41) +#define MT6360_TYPEC_OTP_EVT (42) +#define MT6360_ADC_WAKEUP_EVT (43) +#define MT6360_ADC_DONEI (44) +#define MT6360_BST_BATUVI (45) +#define MT6360_BST_VBUSOVI (46) +#define MT6360_BST_OLPI(47) +/* REG 6 -> 48 ~ 55 */ +#define MT6360_ATTACH_I(48) +#define MT6360_DETACH_I(49) +#define MT6360_QC30_STPDONE(51) +#define MT6360_QC_VBUSDET_DONE (52) +#define MT6360_HVDCP_DET (53) +#define MT6360_CHGDETI (54) +#define MT6360_DCDTI (55) +/* REG 7 -> 56 ~ 63 */ +#define MT6360_FOD_DONE_EVT(56) +#define MT6360_FOD_OV_EVT (57) +#define MT6360_CHRDET_UVP_EVT (58) +#define MT6360_CHRDET_OVP_EVT (59) +#define MT6360_CHRDET_EXT_EVT (60) +#define MT6360_FOD_LR_EVT (61) +#define MT6360_FOD_HR_EVT (62) +#define MT6360_FOD_DISCHG_FAIL_EVT (63) +/* REG 8 -> 64 ~ 71 */ +#define MT6360_USBID_EVT (64) +#define MT6360_APWDTRST_EVT(65) +#define MT6360_EN_EVT (66) +#define MT6360_QONB_RST_EVT(67) +#define MT6360_MRSTB_EVT (68) +#define MT6360_OTP_EVT (69) +#define MT6360_VDDAOV_EVT (70) +#define MT6360_SYSUV_EVT (71) +/* REG 9 -> 72 ~ 79 */ +#define MT6360_FLED_STRBPIN_EVT(72) +#define MT6360_FLED_TORPIN_EVT (73) +#define MT6360_FLED_TX_EVT (74) +#
[PATCH] mfd: mt6360: add pmic mt6360 driver
From: Gene Chen --- drivers/mfd/Kconfig | 12 ++ drivers/mfd/Makefile | 1 + drivers/mfd/mt6360-core.c | 463 ++ 3 files changed, 476 insertions(+) create mode 100644 drivers/mfd/mt6360-core.c diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index f129f96..a422c76 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -862,6 +862,18 @@ config MFD_MAX8998 additional drivers must be enabled in order to use the functionality of the device. +config MFD_MT6360 + tristate "Mediatek MT6360 SubPMIC" + select MFD_CORE + select REGMAP_I2C + select REGMAP_IRQ + depends on I2C + help + Say Y here to enable MT6360 PMU/PMIC/LDO functional support. + PMU part include charger, flashlight, rgb led + PMIC part include 2-channel BUCKs and 2-channel LDOs + LDO part include 4-channel LDOs + config MFD_MT6397 tristate "MediaTek MT6397 PMIC Support" select MFD_CORE diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index f026ada..77a8f0b 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -241,6 +241,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC)+= intel-soc-pmic.o obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC) += intel_soc_pmic_bxtwc.o obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI) += intel_soc_pmic_chtdc_ti.o +obj-$(CONFIG_MFD_MT6360) += mt6360-core.o obj-$(CONFIG_MFD_MT6397) += mt6397-core.o obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o diff --git a/drivers/mfd/mt6360-core.c b/drivers/mfd/mt6360-core.c new file mode 100644 index 000..d3580618 --- /dev/null +++ b/drivers/mfd/mt6360-core.c @@ -0,0 +1,463 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2019 MediaTek Inc. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +/* reg 0 -> 0 ~ 7 */ +#define MT6360_CHG_TREG_EVT(4) +#define MT6360_CHG_AICR_EVT(5) +#define MT6360_CHG_MIVR_EVT(6) +#define MT6360_PWR_RDY_EVT (7) +/* REG 1 -> 8 ~ 15 */ +#define MT6360_CHG_BATSYSUV_EVT(9) +#define MT6360_FLED_CHG_VINOVP_EVT (11) +#define MT6360_CHG_VSYSUV_EVT (12) +#define MT6360_CHG_VSYSOV_EVT (13) +#define MT6360_CHG_VBATOV_EVT (14) +#define MT6360_CHG_VBUSOV_EVT (15) +/* REG 2 -> 16 ~ 23 */ +/* REG 3 -> 24 ~ 31 */ +#define MT6360_WD_PMU_DET (25) +#define MT6360_WD_PMU_DONE (26) +#define MT6360_CHG_TMRI(27) +#define MT6360_CHG_ADPBADI (29) +#define MT6360_CHG_RVPI(30) +#define MT6360_OTPI(31) +/* REG 4 -> 32 ~ 39 */ +#define MT6360_CHG_AICCMEASL (32) +#define MT6360_CHGDET_DONEI(34) +#define MT6360_WDTMRI (35) +#define MT6360_SSFINISHI (36) +#define MT6360_CHG_RECHGI (37) +#define MT6360_CHG_TERMI (38) +#define MT6360_CHG_IEOCI (39) +/* REG 5 -> 40 ~ 47 */ +#define MT6360_PUMPX_DONEI (40) +#define MT6360_BAT_OVP_ADC_EVT (41) +#define MT6360_TYPEC_OTP_EVT (42) +#define MT6360_ADC_WAKEUP_EVT (43) +#define MT6360_ADC_DONEI (44) +#define MT6360_BST_BATUVI (45) +#define MT6360_BST_VBUSOVI (46) +#define MT6360_BST_OLPI(47) +/* REG 6 -> 48 ~ 55 */ +#define MT6360_ATTACH_I(48) +#define MT6360_DETACH_I(49) +#define MT6360_QC30_STPDONE(51) +#define MT6360_QC_VBUSDET_DONE (52) +#define MT6360_HVDCP_DET (53) +#define MT6360_CHGDETI (54) +#define MT6360_DCDTI (55) +/* REG 7 -> 56 ~ 63 */ +#define MT6360_FOD_DONE_EVT(56) +#define MT6360_FOD_OV_EVT (57) +#define MT6360_CHRDET_UVP_EVT (58) +#define MT6360_CHRDET_OVP_EVT (59) +#define MT6360_CHRDET_EXT_EVT (60) +#define MT6360_FOD_LR_EVT (61) +#define MT6360_FOD_HR_EVT (62) +#define MT6360_FOD_DISCHG_FAIL_EVT (63) +/* REG 8 -> 64 ~ 71 */ +#define MT6360_USBID_EVT (64) +#define MT6360_APWDTRST_EVT(65) +#define MT6360_EN_EVT (66) +#define MT6360_QONB_RST_EVT(67) +#define MT6360_MRSTB_EVT (68) +#define MT6360_OTP_EVT (69) +#define MT6360_VDDAOV_EVT (70) +#define MT6360_SYSUV_EVT (71) +/* REG 9 -> 72 ~ 79 */ +#define MT6360_FLED_STRBPIN_EVT(72) +#define MT6360_FLED_TORPIN_EVT (73) +#define MT6360_FLED_TX_EVT (74) +#define MT6360_FLED_LVF_EVT(75) +#define MT6360_FLED2_SHORT_EVT (78) +#define MT6360_FLED1_SHORT_EVT (79) +/* REG 10 -> 80 ~ 87 */ +#def
Re: [PATCH 1/3] ACPI: Resolve objects on host-directed table loads
On Fri, 6 Sep 2019, Shevchenko, Andriy wrote: On Wed, Sep 04, 2019 at 09:20:03AM +0200, Nikolaus Voss wrote: On Fri, 30 Aug 2019, Shevchenko, Andriy wrote: On Fri, Aug 16, 2019 at 01:57:26PM +0200, Nikolaus Voss wrote: On Wed, 14 Aug 2019, Schmauss, Erik wrote: -Original Message- From: Shevchenko, Andriy Sent: Wednesday, August 14, 2019 11:51 AM To: Nikolaus Voss Cc: Rafael J. Wysocki ; Len Brown ; Moore, Robert ; Schmauss, Erik ; Jacek Anaszewski ; Pavel Machek ; Dan Murphy ; Thierry Reding ; linux-a...@vger.kernel.org; de...@acpica.org; linux-l...@vger.kernel.org; linux-...@vger.kernel.org Subject: Re: [PATCH 1/3] ACPI: Resolve objects on host-directed table loads On Wed, May 29, 2019 at 02:18:20PM +0200, Nikolaus Voss wrote: If an ACPI SSDT overlay is loaded after built-in tables have been loaded e.g. via configfs or efivar_ssdt_load() it is necessary to rewalk the namespace to resolve references. Without this, relative and absolute paths like ^PCI0.SBUS or \_SB.PCI0.SBUS are not resolved correctly. Make configfs load use the same method as efivar_ssdt_load(). This patch brought a regression (bisect log below). Now I'm unable to unload the table which was working before. Reverting (manual, due to ACPICA changes) helps. Please, consider to revert for this cycle, or fix. I will be glad to test any proposed fix. We submitted a patch (d1fb5b2f623b1af5a0d2a83d205df1b61f430dc6) in response to this suggestion and I was not aware that this had been applied. Rafael, please revert at least the ACPICA portion of this patch. As I see it, my ACPICA change is not part of 5.3-rc1 any more. Reverting my fix is part of the patch above (d1fb5b2f623b1af5a0d2a83d205df1b61f430dc6) which is already applied. Nevertheless, what is new, is that acpi_ns_initialize_objects() is called in acpi_load_table(). This is necessary to resolve the references in the newly loaded table. Maybe this prevents the table from being unloaded? So, can we do something about it? It's a regression. Rafael, Nikolaus? can you describe how you unload the table (from userspace?). I cannot reproduce this regression. I was not aware of any working interface for unloading ACPI tables, I ended up in kexec'ing the kernel for my tests each time I had to unload a table. Sure. I have connected an I²C device(s) to my board where I have compiled ACPI tables which describes them (more details if you want to know is on [1]). So, I create a folder in ConfigFS [1,2] and fill it up with SSDT (an *.aml file). After this, if I try to remove the folder in ConfigFS followed by table removal event, the actual nodes won't be removed, and this messes up with the internal representation of the ACPI device tree. [1]: https://www.kernel.org/doc/html/latest/admin-guide/acpi/ssdt-overlays.html [2]: https://htot.github.io/meta-intel-edison/1.3-ACPI-or-not.html#run-time-loading-through-configfs Thanks, I have reproduced it and the culprit is my acpi_configfs patch that now uses acpi_load_table() to have the references resolved. My proposal would be to have that function return the table index, which is needed to unload the table. I'll submit a patch, Andy, could you test it in your setup? Erik/Robert, is it ok to change the acpi_load_table() ACPICA API function? It has only a few uses. Niko
Re: [PATCH] KVM: s390: Remove unused parameter from __inject_sigp_restart()
On 12.09.19 09:02, Thomas Huth wrote:
> It's not required, so drop it to make it clear that this interrupt
> does not have any extra parameters.
>
> Signed-off-by: Thomas Huth
> ---
> arch/s390/kvm/interrupt.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
> index b5fd6e85657c..3e7efdd9228a 100644
> --- a/arch/s390/kvm/interrupt.c
> +++ b/arch/s390/kvm/interrupt.c
> @@ -1477,8 +1477,7 @@ static int __inject_sigp_stop(struct kvm_vcpu *vcpu,
> struct kvm_s390_irq *irq)
> return 0;
> }
>
> -static int __inject_sigp_restart(struct kvm_vcpu *vcpu,
> - struct kvm_s390_irq *irq)
> +static int __inject_sigp_restart(struct kvm_vcpu *vcpu)
> {
> struct kvm_s390_local_interrupt *li = &vcpu->arch.local_int;
>
> @@ -1997,7 +1996,7 @@ static int do_inject_vcpu(struct kvm_vcpu *vcpu, struct
> kvm_s390_irq *irq)
> rc = __inject_sigp_stop(vcpu, irq);
> break;
> case KVM_S390_RESTART:
> - rc = __inject_sigp_restart(vcpu, irq);
> + rc = __inject_sigp_restart(vcpu);
> break;
> case KVM_S390_INT_CLOCK_COMP:
> rc = __inject_ckc(vcpu);
>
Yeah, why not
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
Re: [PATCH v5 0/4] virtio-fs: shared file system for virtual machines
On Wed, Sep 11, 2019 at 5:54 PM Stefan Hajnoczi wrote: > > On Tue, Sep 10, 2019 at 05:12:02PM +0200, Miklos Szeredi wrote: > > I've folded the series from Vivek and fixed a couple of TODO comments > > myself. AFAICS two issues remain that need to be resolved in the short > > term, one way or the other: freeze/restore and full virtqueue. > > I have researched freeze/restore and come to the conclusion that it > needs to be a future feature. It will probably come together with live > migration support for reasons mentioned below. > > Most virtio devices have fairly simply power management freeze/restore > functions that shut down the device and bring it back to the state held > in memory, respectively. virtio-fs, as well as virtio-9p and > virtio-gpu, are different because they contain session state. It is not > easily possible to bring back the state held in memory after the device > has been reset. > > The following areas of the FUSE protocol are stateful and need special > attention: > > * FUSE_INIT - this is pretty easy, we must re-negotiate the same >settings as before. > > * FUSE_LOOKUP -> fuse_inode (inode_map) > >The session contains a set of inode numbers that have been looked up >using FUSE_LOOKUP. They are ephemeral in the current virtiofsd >implementation and vary across device reset. Therefore we are unable >to restore the same inode numbers upon restore. > >The solution is persistent inode numbers in virtiofsd. This is also >needed to make open_by_handle_at(2) work and probably for live >migration. > > * FUSE_OPEN -> fh (fd_map) > >The session contains FUSE file handles for open files. There is >currently no way of re-opening a file so that a specific fh is >returned. A mechanism to do so probably isn't necessary if the >driver can update the fh to the new one produced by the device for >all open files instead. > > * FUSE_OPENDIR -> fh (dirp_map) > >Same story as for FUSE_OPEN but for open directories. > > * FUSE_GETLK/SETLK/SETLKW -> (inode->posix_locks and fcntl(F_OFD_GET/SETLK)) > >The session contains file locks. The driver must reacquire them upon >restore. It's unclear what to do when locking fails. > > Live migration has the same problem since the FUSE session will be moved > to a new virtio-fs device instance. It makes sense to tackle both > features together. This is something that can be implemented in the > next year, but it's not a quick fix. Right. The question for now is: should the freeze silently succeed (as it seems to do now) or should it fail instead? I guess normally freezing should be okay, as long as the virtiofsd remains connected while the system is frozen. I tried to test this with "echo -n mem > /sys/power/state", which indeed resulted in the virtio_fs_freeze() callback being called. However, I couldn't find a way to wake up the system... Thanks, Miklos
Re: [PATCH 00/13] nvdimm: Use more common kernel coding style
On Thu, 2019-09-12 at 01:00 -0700, Dan Williams wrote: > Hi Joe, > > On Wed, Sep 11, 2019 at 7:55 PM Joe Perches wrote: > > Rather than have a local coding style, use the typical kernel style. > > I'd rather automate this. I'm going to do once-over with clang-format > and see what falls out. I am adding Miguel Ojeda to the cc's. Of course you are welcome to try it, but I believe that clang-format doesn't work all that well yet. It's more a work in progress rather than a "standard". I believe you'll find that the patch series I sent ends up with a rather more typical kernel style. I suggest you try to apply the series I sent and then run clang-format on that and see the differences. Ideally one day, something tool like clang-format might be locally applied by every developer for their own personal style with some other neutral style the content actually distributed. cheers, Joe
[PATCH] ACPICA: make acpi_load_table() return table index
For unloading an ACPI table, it is necessary to provide the
index of the table. The method intended for dynamically
loading or hotplug addition of tables, acpi_load_table(),
should provide this information via an optional pointer
to the loaded table index.
This patch fixes the table unload function of acpi_configfs.
Reported-by: Andy Shevchenko
Fixes: d06c47e3dd07f ("ACPI: configfs: Resolve objects on host-directed table
loads")
Signed-off-by: Nikolaus Voss
---
drivers/acpi/acpi_configfs.c | 2 +-
drivers/acpi/acpica/dbfileio.c | 2 +-
drivers/acpi/acpica/tbxfload.c | 8 ++--
drivers/firmware/efi/efi.c | 2 +-
include/acpi/acpixf.h | 3 ++-
5 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/acpi_configfs.c b/drivers/acpi/acpi_configfs.c
index 57d9d574d4dde..77f81242a28e6 100644
--- a/drivers/acpi/acpi_configfs.c
+++ b/drivers/acpi/acpi_configfs.c
@@ -53,7 +53,7 @@ static ssize_t acpi_table_aml_write(struct config_item *cfg,
if (!table->header)
return -ENOMEM;
- ret = acpi_load_table(table->header);
+ ret = acpi_load_table(table->header, &table->index);
if (ret) {
kfree(table->header);
table->header = NULL;
diff --git a/drivers/acpi/acpica/dbfileio.c b/drivers/acpi/acpica/dbfileio.c
index c6e25734dc5cd..e1b6e54a96ac1 100644
--- a/drivers/acpi/acpica/dbfileio.c
+++ b/drivers/acpi/acpica/dbfileio.c
@@ -93,7 +93,7 @@ acpi_status acpi_db_load_tables(struct acpi_new_table_desc
*list_head)
while (table_list_head) {
table = table_list_head->table;
- status = acpi_load_table(table);
+ status = acpi_load_table(table, NULL);
if (ACPI_FAILURE(status)) {
if (status == AE_ALREADY_EXISTS) {
acpi_os_printf
diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
index 86f1693f6d29a..d08cd8ffcbdb6 100644
--- a/drivers/acpi/acpica/tbxfload.c
+++ b/drivers/acpi/acpica/tbxfload.c
@@ -268,7 +268,8 @@ ACPI_EXPORT_SYMBOL_INIT(acpi_install_table)
*
* PARAMETERS: table - Pointer to a buffer containing the ACPI
*table to be loaded.
- *
+ * table_idx - Pointer to a u32 for storing the table
+ *index, might be NULL
* RETURN: Status
*
* DESCRIPTION: Dynamically load an ACPI table from the caller's buffer. Must
@@ -278,7 +279,7 @@ ACPI_EXPORT_SYMBOL_INIT(acpi_install_table)
* to ensure that the table is not deleted or unmapped.
*
**/
-acpi_status acpi_load_table(struct acpi_table_header *table)
+acpi_status acpi_load_table(struct acpi_table_header *table, u32 *table_idx)
{
acpi_status status;
u32 table_index;
@@ -297,6 +298,9 @@ acpi_status acpi_load_table(struct acpi_table_header *table)
status = acpi_tb_install_and_load_table(ACPI_PTR_TO_PHYSADDR(table),
ACPI_TABLE_ORIGIN_EXTERNAL_VIRTUAL,
FALSE, &table_index);
+ if (table_idx)
+ *table_idx = table_index;
+
if (ACPI_SUCCESS(status)) {
/* Complete the initialization/resolution of new objects */
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index ad3b1f4866b35..9773e4212baef 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -308,7 +308,7 @@ static __init int efivar_ssdt_load(void)
goto free_data;
}
- ret = acpi_load_table(data);
+ ret = acpi_load_table(data, NULL);
if (ret) {
pr_err("failed to load table: %d\n", ret);
goto free_data;
diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h
index 3845c8fcc94e5..c90bbdc4146a6 100644
--- a/include/acpi/acpixf.h
+++ b/include/acpi/acpixf.h
@@ -452,7 +452,8 @@ ACPI_EXTERNAL_RETURN_STATUS(acpi_status ACPI_INIT_FUNCTION
u8 physical))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
- acpi_load_table(struct acpi_table_header *table))
+ acpi_load_table(struct acpi_table_header *table,
+ u32 *table_idx))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_unload_parent_table(acpi_handle object))
--
2.17.1
[PATCH v4 1/4] soc: amlogic: meson-gx-socinfo: Add A1 and A113L IDs
Add the SoC IDs for the A113L Amlogic A1 SoC.
Signed-off-by: Jianxin Pan
Reviewed-by: Neil Armstrong
---
drivers/soc/amlogic/meson-gx-socinfo.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/soc/amlogic/meson-gx-socinfo.c
b/drivers/soc/amlogic/meson-gx-socinfo.c
index 6d0d04f..3c86d8d 100644
--- a/drivers/soc/amlogic/meson-gx-socinfo.c
+++ b/drivers/soc/amlogic/meson-gx-socinfo.c
@@ -40,6 +40,7 @@ static const struct meson_gx_soc_id {
{ "G12A", 0x28 },
{ "G12B", 0x29 },
{ "SM1", 0x2b },
+ { "A1", 0x2c },
};
static const struct meson_gx_package_id {
@@ -68,6 +69,7 @@ static const struct meson_gx_package_id {
{ "S922X", 0x29, 0x40, 0xf0 },
{ "A311D", 0x29, 0x10, 0xf0 },
{ "S905X3", 0x2b, 0x5, 0xf },
+ { "A113L", 0x2c, 0x0, 0xf8 },
};
static inline unsigned int socinfo_to_major(u32 socinfo)
--
2.7.4
[PATCH v4 4/4] arm64: dts: add support for A1 based Amlogic AD401
Add basic support for the Amlogic A1 based Amlogic AD401 board:
which describe components as follows: Reserve Memory, CPU, GIC, IRQ,
Timer, UART. It's capable of booting up into the serial console.
Signed-off-by: Jianxin Pan
Reviewed-by: Jerome Brunet
Reviewed-by: Neil Armstrong
---
arch/arm64/boot/dts/amlogic/Makefile | 1 +
arch/arm64/boot/dts/amlogic/meson-a1-ad401.dts | 30 ++
arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 130 +
3 files changed, 161 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-a1-ad401.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-a1.dtsi
diff --git a/arch/arm64/boot/dts/amlogic/Makefile
b/arch/arm64/boot/dts/amlogic/Makefile
index 84afecb..a90be52 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -36,3 +36,4 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxm-rbox-pro.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-vega-s96.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-sei610.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-khadas-vim3l.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-a1-ad401.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-a1-ad401.dts
b/arch/arm64/boot/dts/amlogic/meson-a1-ad401.dts
new file mode 100644
index ..69c25c6
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-a1-ad401.dts
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Amlogic, Inc. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include "meson-a1.dtsi"
+
+/ {
+ compatible = "amlogic,ad401", "amlogic,a1";
+ model = "Amlogic Meson A1 AD401 Development Board";
+
+ aliases {
+ serial0 = &uart_AO_B;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x800>;
+ };
+};
+
+&uart_AO_B {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
new file mode 100644
index ..7210ad0
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
@@ -0,0 +1,130 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Amlogic, Inc. All rights reserved.
+ */
+
+#include
+#include
+
+/ {
+ compatible = "amlogic,a1";
+
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a35";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a35";
+ reg = <0x0 0x1>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ l2: l2-cache0 {
+ compatible = "cache";
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ linux,cma {
+ compatible = "shared-dma-pool";
+ reusable;
+ size = <0x0 0x80>;
+ alignment = <0x0 0x40>;
+ linux,cma-default;
+ };
+ };
+
+ sm: secure-monitor {
+ compatible = "amlogic,meson-gxbb-sm";
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ apb: bus@fe00 {
+ compatible = "simple-bus";
+ reg = <0x0 0xfe00 0x0 0x100>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0x0 0x0 0x0 0xfe00 0x0 0x100>;
+
+ uart_AO: serial@1c00 {
+ compatible = "amlogic,meson-gx-uart",
+"amlogic,meson-ao-uart";
+ reg = <0x0 0x1c00 0x0 0x18>;
+ interrupts = ;
+ clocks = <&xtal>, <&xtal>, <&xtal>;
+ clock-names = "xtal", "pclk", "baud";
+ status = "disabled";
+ };
+
+ uart_AO_B: serial@2000 {
+ compatible = "amlogic,meson-gx-uart",
+
[PATCH v4 3/4] dt-bindings: arm: amlogic: add Amlogic AD401 bindings
Add the compatible for the Amlogic A1 Based AD401 board. Signed-off-by: Jianxin Pan Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/arm/amlogic.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index 0ef45ac..ee5703c 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -159,5 +159,7 @@ properties: - description: Boards with the Amlogic Meson A1 A113L SoC items: + - enum: + - amlogic,ad401 - const: amlogic,a1 ... -- 2.7.4
Re: [PATCH V2 net-next 1/7] net: hns3: add ethtool_ops.set_channels support for HNS3 VF driver
Hi, Michal
On 2019/9/12 14:23, Michal Kubecek wrote:
On Wed, Sep 11, 2019 at 10:40:33AM +0800, Huazhong Tan wrote:
From: Guangbin Huang
This patch adds ethtool_ops.set_channels support for HNS3 VF driver,
and updates related TQP information and RSS information, to support
modification of VF TQP number, and uses current rss_size instead of
max_rss_size to initialize RSS.
Also, fixes a format error in hclgevf_get_rss().
Signed-off-by: Guangbin Huang
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 1 +
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 83 --
2 files changed, 79 insertions(+), 5 deletions(-)
...
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
index 594cae8..e3090b3 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
...
+static void hclgevf_update_rss_size(struct hnae3_handle *handle,
+ u32 new_tqps_num)
+{
+ struct hnae3_knic_private_info *kinfo = &handle->kinfo;
+ struct hclgevf_dev *hdev = hclgevf_ae_get_hdev(handle);
+ u16 max_rss_size;
+
+ kinfo->req_rss_size = new_tqps_num;
+
+ max_rss_size = min_t(u16, hdev->rss_size_max,
+hdev->num_tqps / kinfo->num_tc);
+
+ /* Use the user's configuration when it is not larger than
+* max_rss_size, otherwise, use the maximum specification value.
+*/
+ if (kinfo->req_rss_size != kinfo->rss_size && kinfo->req_rss_size &&
+ kinfo->req_rss_size <= max_rss_size)
+ kinfo->rss_size = kinfo->req_rss_size;
+ else if (kinfo->rss_size > max_rss_size ||
+(!kinfo->req_rss_size && kinfo->rss_size < max_rss_size))
+ kinfo->rss_size = max_rss_size;
I don't think requested channel count can be larger than max_rss_size
here. In ethtool_set_channels(), we check that requested channel counts
do not exceed maximum channel counts as reported by ->get_channels().
And hclgevf_get_max_channels() cannot return more than max_rss_size.
When we can modify the TC number (which PF has already supported, VF may
implement in the future) using lldptool or tc cmd,
hclgevf_update_rss_size will be called to update the rss information,
which may also change max_rss_size, so we will use max_rss_size instead
if the kinfo->rss_size configured using ethtool is bigger than max_rss_size.
+
+ kinfo->num_tqps = kinfo->num_tc * kinfo->rss_size;
+}
+
+static int hclgevf_set_channels(struct hnae3_handle *handle, u32 new_tqps_num,
+ bool rxfh_configured)
+{
+ struct hclgevf_dev *hdev = hclgevf_ae_get_hdev(handle);
+ struct hnae3_knic_private_info *kinfo = &handle->kinfo;
+ u16 cur_rss_size = kinfo->rss_size;
+ u16 cur_tqps = kinfo->num_tqps;
+ u32 *rss_indir;
+ unsigned int i;
+ int ret;
+
+ hclgevf_update_rss_size(handle, new_tqps_num);
+
+ ret = hclgevf_set_rss_tc_mode(hdev, kinfo->rss_size);
+ if (ret)
+ return ret;
+
+ /* RSS indirection table has been configuared by user */
+ if (rxfh_configured)
+ goto out;
+
+ /* Reinitializes the rss indirect table according to the new RSS size */
+ rss_indir = kcalloc(HCLGEVF_RSS_IND_TBL_SIZE, sizeof(u32), GFP_KERNEL);
+ if (!rss_indir)
+ return -ENOMEM;
+
+ for (i = 0; i < HCLGEVF_RSS_IND_TBL_SIZE; i++)
+ rss_indir[i] = i % kinfo->rss_size;
+
+ ret = hclgevf_set_rss(handle, rss_indir, NULL, 0);
+ if (ret)
+ dev_err(&hdev->pdev->dev, "set rss indir table fail, ret=%d\n",
+ ret);
+
+ kfree(rss_indir);
+
+out:
+ if (!ret)
+ dev_info(&hdev->pdev->dev,
+"Channels changed, rss_size from %u to %u, tqps from %u to
%u",
+cur_rss_size, kinfo->rss_size,
+cur_tqps, kinfo->rss_size * kinfo->num_tc);
+
+ return ret;
+}
IIRC David asked you not to issue this log message in v1 review.
Michal Kubecek
Sorry for missing this log.
Thanks.
.
[PATCH v4 0/4] arm64: Add basic support for Amlogic A1 SoC Family
A1 is an application processor designed for smart audio and IoT applications, with Dual core ARM Cortex-A35 CPU. Unlike the previous GXL and G12 series, there is no Cortex-M3 AO CPU in it. This serial add basic support for the Amlogic A1 based Amlogic AD401 board: which describe components as follows: Reserve Memory, CPU, GIC, IRQ, Timer, UART. It's capable of booting up into the serial console. The pclk for uart_AO_B need to be fixed once A1 clock driver is merged. In this version, it rely on bootloader to enable the pclk gate Changes since v3 at [2]: - remove 0x in bus Changes since v2 at [1]: - add bus in dts according Martin's suggestion - remove useless comment line Changes since v1 at [0]: - fix coding style - collect Reviewed-by [0] https://lore.kernel.org/linux-amlogic/1567493475-75451-1-git-send-email-jianxin@amlogic.com [1] https://lore.kernel.org/linux-amlogic/1567667251-33466-1-git-send-email-jianxin@amlogic.com [2] https://lore.kernel.org/linux-amlogic/1568216290-84219-1-git-send-email-jianxin@amlogic.com Jianxin Pan (4): soc: amlogic: meson-gx-socinfo: Add A1 and A113L IDs dt-bindings: arm: amlogic: add A1 bindings dt-bindings: arm: amlogic: add Amlogic AD401 bindings arm64: dts: add support for A1 based Amlogic AD401 Documentation/devicetree/bindings/arm/amlogic.yaml | 6 + arch/arm64/boot/dts/amlogic/Makefile | 1 + arch/arm64/boot/dts/amlogic/meson-a1-ad401.dts | 30 + arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 130 + drivers/soc/amlogic/meson-gx-socinfo.c | 2 + 5 files changed, 169 insertions(+) create mode 100644 arch/arm64/boot/dts/amlogic/meson-a1-ad401.dts create mode 100644 arch/arm64/boot/dts/amlogic/meson-a1.dtsi -- 2.7.4
[PATCH v4 2/4] dt-bindings: arm: amlogic: add A1 bindings
Add bindings for the new Amlogic A1 SoC family. A1 is an application processor designed for smart audio and IoT applications, with dual core Cortex-A35. Signed-off-by: Jianxin Pan Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/arm/amlogic.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index 99015ce..0ef45ac 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -156,4 +156,8 @@ properties: - seirobotics,sei610 - khadas,vim3l - const: amlogic,sm1 + + - description: Boards with the Amlogic Meson A1 A113L SoC +items: + - const: amlogic,a1 ... -- 2.7.4
HI
Drogi przyjacielu, Jestem pan Lipton, który nie był radcą prawnym. Chcę, aby twój kontakt pomógł mi odzyskać fundusz o wartości (4,8 miliona dolarów) pozostawiony przez mojego zmarłego klienta na jego koncie, zanim zostanie on skonfiskowany lub uznany za nieużyteczny przez firmę Security Finance, jeśli to kwota została zdeponowana, Wszystko, czego od ciebie wymagam, to twoja uczciwa współpraca, abyśmy mogli zobaczyć tę transakcję jak najszybciej. proszę o bezpośrednią odpowiedź w celu uzyskania dodatkowych wyjaśnień. Pozdrowienia, Mr.Lipton Daveid (Esq)
Re: [PATCH pinctrl/fixes] pinctrl: aspeed: Fix spurious mux failures on the AST2500
On Thu, Aug 29, 2019 at 8:17 AM Andrew Jeffery wrote:
> Commit 674fa8daa8c9 ("pinctrl: aspeed-g5: Delay acquisition of regmaps")
> was determined to be a partial fix to the problem of acquiring the LPC
> Host Controller and GFX regmaps: The AST2500 pin controller may need to
> fetch syscon regmaps during expression evaluation as well as when
> setting mux state. For example, this case is hit by attempting to export
> pins exposing the LPC Host Controller as GPIOs.
>
> An optional eval() hook is added to the Aspeed pinmux operation struct
> and called from aspeed_sig_expr_eval() if the pointer is set by the
> SoC-specific driver. This enables the AST2500 to perform the custom
> action of acquiring its regmap dependencies as required.
>
> John Wang tested the fix on an Inspur FP5280G2 machine (AST2500-based)
> where the issue was found, and I've booted the fix on Witherspoon
> (AST2500) and Palmetto (AST2400) machines, and poked at relevant pins
> under QEMU by forcing mux configurations via devmem before exporting
> GPIOs to exercise the driver.
>
> Fixes: 7d29ed88acbb ("pinctrl: aspeed: Read and write bits in LPC and GFX
> controllers")
> Fixes: 674fa8daa8c9 ("pinctrl: aspeed-g5: Delay acquisition of regmaps")
> Reported-by: John Wang
> Tested-by: John Wang
> Signed-off-by: Andrew Jeffery
Applied for fixes already yesterday!
Yours,
Linus Walleij
Re: [Ksummit-discuss] [PATCH v2 3/3] libnvdimm, MAINTAINERS: Maintainer Entry Profile
On Thu, Sep 12, 2019 at 9:43 AM Dan Williams wrote: > > Now I come to find that CodingStyle has settled on clang-format (in > the last 15 months) as the new standard which is a much better answer > to me than a manually specified style open to interpretation. I'll > take a look at getting libnvdimm converted over. Note that clang-format cannot do everything as we want within the kernel just yet, but it is a close enough approximation -- it is near the point where we could simply agree to use it and stop worrying about styling issues. However, that would mean everyone needs to have a recent clang-format available, which I think is the biggest obstacle at the moment. Cheers, Miguel
Re: [PATCH v3 4/4] arm64: dts: add support for A1 based Amlogic AD401
Hi Neil,
On 2019/9/11 23:54, Neil Armstrong wrote:
> On 11/09/2019 17:38, Jianxin Pan wrote:
>> Add basic support for the Amlogic A1 based Amlogic AD401 board:
>> which describe components as follows: Reserve Memory, CPU, GIC, IRQ,
>> Timer, UART. It's capable of booting up into the serial console.
>>
>> Signed-off-by: Jianxin Pan
>> Reviewed-by: Jerome Brunet
>> ---
>> arch/arm64/boot/dts/amlogic/Makefile | 1 +
>> arch/arm64/boot/dts/amlogic/meson-a1-ad401.dts | 30 ++
>> arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 131
>> +
>> 3 files changed, 162 insertions(+)
[...]
>> +
>> +sm: secure-monitor {
>> +compatible = "amlogic,meson-gxbb-sm";
>> +};
>> +
>> +soc {
>> +compatible = "simple-bus";
>> +#address-cells = <2>;
>> +#size-cells = <2>;
>> +ranges;
>> +
>> +
>> +apb: bus@0xfe00 {
>
> Should be bus@fe00
>
Thanks for your review.
I resent a new version and fixed it.
>> +compatible = "simple-bus";
>> +reg = <0x0 0xfe00 0x0 0x100>;
>> +#address-cells = <2>;
>> +#size-cells = <2>;
[...]
>> +xtal: xtal-clk {
>> +compatible = "fixed-clock";
>> +clock-frequency = <2400>;
>> +clock-output-names = "xtal";
>> +#clock-cells = <0>;
>> +};
>> +};
>>
>
> With that fixed:
> Reviewed-by: Neil Armstrong
>
> Neil
>
> .
>
[PATCH v3] venus: enc: fix enum_frameintervals
This fixes an issue when setting the encoder framerate because of missing precision. Now the frameinterval type is changed to TYPE_CONTINUOUS and step = 1. Also the math is changed when framerate property is called - the firmware side expects the framerate in Q16 values. Signed-off-by: Loic Poulain Signed-off-by: Stanimir Varbanov --- drivers/media/platform/qcom/venus/venc.c | 23 --- 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/drivers/media/platform/qcom/venus/venc.c b/drivers/media/platform/qcom/venus/venc.c index 1b7fb2d5887c..bf2dd9287c32 100644 --- a/drivers/media/platform/qcom/venus/venc.c +++ b/drivers/media/platform/qcom/venus/venc.c @@ -22,6 +22,7 @@ #include "venc.h" #define NUM_B_FRAMES_MAX 4 +#define FRAMERATE_FACTOR (1 << 16) /* * Three resons to keep MPLANE formats (despite that the number of planes @@ -576,7 +577,7 @@ static int venc_enum_frameintervals(struct file *file, void *fh, struct venus_inst *inst = to_inst(file); const struct venus_format *fmt; - fival->type = V4L2_FRMIVAL_TYPE_STEPWISE; + fival->type = V4L2_FRMIVAL_TYPE_CONTINUOUS; fmt = find_format(inst, fival->pixel_format, V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE); @@ -599,12 +600,12 @@ static int venc_enum_frameintervals(struct file *file, void *fh, fival->height < frame_height_min(inst)) return -EINVAL; - fival->stepwise.min.numerator = 1; - fival->stepwise.min.denominator = frate_max(inst); - fival->stepwise.max.numerator = 1; - fival->stepwise.max.denominator = frate_min(inst); + fival->stepwise.min.numerator = FRAMERATE_FACTOR; + fival->stepwise.min.denominator = frate_max(inst) * FRAMERATE_FACTOR; + fival->stepwise.max.numerator = FRAMERATE_FACTOR; + fival->stepwise.max.denominator = frate_min(inst) * FRAMERATE_FACTOR; fival->stepwise.step.numerator = 1; - fival->stepwise.step.denominator = frate_max(inst); + fival->stepwise.step.denominator = 1; return 0; } @@ -649,6 +650,7 @@ static int venc_set_properties(struct venus_inst *inst) struct hfi_quantization quant; struct hfi_quantization_range quant_range; u32 ptype, rate_control, bitrate, profile = 0, level = 0; + u64 framerate; int ret; ret = venus_helper_set_work_mode(inst, VIDC_WORK_MODE_2); @@ -659,9 +661,16 @@ static int venc_set_properties(struct venus_inst *inst) if (ret) return ret; + framerate = inst->timeperframe.denominator * FRAMERATE_FACTOR; + /* next line is to round up */ + framerate += inst->timeperframe.numerator - 1; + do_div(framerate, inst->timeperframe.numerator); + ptype = HFI_PROPERTY_CONFIG_FRAME_RATE; frate.buffer_type = HFI_BUFFER_OUTPUT; - frate.framerate = inst->fps * (1 << 16); + frate.framerate = framerate; + if (frate.framerate > frate_max(inst) * FRAMERATE_FACTOR) + frate.framerate = frate_max(inst) * FRAMERATE_FACTOR; ret = hfi_session_set_property(inst, ptype, &frate); if (ret) -- 2.17.1
Re: [PATCH v3 2/2] dwc: PCI: intel: Intel PCIe RC controller driver
On Thu, Sep 12, 2019 at 02:58:45PM +0800, Dilip Kota wrote: > Hi Andrew Murray, > > On 9/11/2019 6:30 PM, Andrew Murray wrote: > > On Tue, Sep 10, 2019 at 03:46:17PM +0800, Dilip Kota wrote: > > > Hi Andrew Murray, > > > > > > Please find my response inline. > > > > > > On 9/9/2019 4:31 PM, Andrew Murray wrote: > > > > On Mon, Sep 09, 2019 at 02:51:03PM +0800, Dilip Kota wrote: > > > > > On 9/6/2019 7:20 PM, Andrew Murray wrote: > > > > > > On Fri, Sep 06, 2019 at 06:58:11PM +0800, Dilip Kota wrote: > > > > > > > Hi Andrew Murray, > > > > > > > > > > > > > > Thanks for the review. Please find my response inline. > > > > > > > > > > > > > > On 9/5/2019 6:45 PM, Andrew Murray wrote: > > > > > > > > On Wed, Sep 04, 2019 at 06:10:31PM +0800, Dilip Kota wrote: > > > > > > > > > Add support to PCIe RC controller on Intel Universal > > > > > > > > > Gateway SoC. PCIe controller is based of Synopsys > > > > > > > > > Designware pci core. > > > > > > > > > > > > > > > > > > Signed-off-by: Dilip Kota > > > > > > > > > --- > > > > > > > > Hi Dilip, > > > > > > > > > > > > > > > > Thanks for the patch, initial feedback below: > > > > > > > > > > > > > > > > > changes on v3: > > > > > > > > > Rename PCIe app logic registers with PCIE_APP prefix. > > > > > > > > > PCIE_IOP_CTRL configuration is not required. Remove > > > > > > > > > respective code. > > > > > > > > > Remove wrapper functions for clk enable/disable APIs. > > > > > > > > > Use platform_get_resource_byname() instead of > > > > > > > > > devm_platform_ioremap_resource() to be similar with > > > > > > > > > DWC framework. > > > > > > > > > Rename phy name to "pciephy". > > > > > > > > > Modify debug message in msi_init() callback to be more > > > > > > > > > specific. > > > > > > > > > Remove map_irq() callback. > > > > > > > > > Enable the INTx interrupts at the time of PCIe > > > > > > > > > initialization. > > > > > > > > > Reduce memory fragmentation by using variable "struct > > > > > > > > > dw_pcie pci" > > > > > > > > > instead of allocating memory. > > > > > > > > > Reduce the delay to 100us during enpoint initialization > > > > > > > > > intel_pcie_ep_rst_init(). > > > > > > > > > Call dw_pcie_host_deinit() during remove() instead of > > > > > > > > > directly > > > > > > > > > calling PCIe core APIs. > > > > > > > > > Rename "intel,rst-interval" to "reset-assert-ms". > > > > > > > > > Remove unused APP logic Interrupt bit macro definitions. > > > > > > > > > Use dwc framework's dw_pcie_setup_rc() for PCIe host > > > > > > > > > specific > > > > > > > > >configuration instead of redefining the same > > > > > > > > > functionality in > > > > > > > > >the driver. > > > > > > > > > Move the whole DT parsing specific code to > > > > > > > > > intel_pcie_get_resources() > > > > > > > > > > > > > > > > > > drivers/pci/controller/dwc/Kconfig | 13 + > > > > > > > > > drivers/pci/controller/dwc/Makefile | 1 + > > > > > > > > > drivers/pci/controller/dwc/pcie-intel-axi.c | 840 > > > > > > > > > > > > > > > > > > 3 files changed, 854 insertions(+) > > > > > > > > > create mode 100644 > > > > > > > > > drivers/pci/controller/dwc/pcie-intel-axi.c > > > > > > > > > > > > > > > > > > diff --git a/drivers/pci/controller/dwc/Kconfig > > > > > > > > > b/drivers/pci/controller/dwc/Kconfig > > > > > > > > > index 6ea778ae4877..e44b9b6a6390 100644 > > > > > > > > > --- a/drivers/pci/controller/dwc/Kconfig > > > > > > > > > +++ b/drivers/pci/controller/dwc/Kconfig > > > > > > > > > @@ -82,6 +82,19 @@ config PCIE_DW_PLAT_EP > > > > > > > > > order to enable device-specific features > > > > > > > > > PCI_DW_PLAT_EP must be > > > > > > > > > selected. > > > > > > > > > +config PCIE_INTEL_AXI > > > > > > > > > +bool "Intel AHB/AXI PCIe host controller support" > > > > > > > > > +depends on PCI_MSI > > > > > > > > > +depends on PCI > > > > > > > > I don't think the PCI dependency is required here. > > > > > > > > > > > > > > > > I'm also not sure why PCI_MSI is required, we select > > > > > > > > PCIE_DW_HOST which > > > > > > > > depends on PCI_MSI_IRQ_DOMAIN which depends on PCI_MSI. > > > > > > > Agree, dependency on PCI and PCI_MSI can be removed. I will > > > > > > > remove it in > > > > > > > next patch revision. > > > > > > > > > +depends on OF > > > > > > > > > +select PCIE_DW_HOST > > > > > > > > > +help > > > > > > > > > + Say 'Y' here to enable support for Intel AHB/AXI > > > > > > > > > PCIe Host > > > > > > > > > + controller driver. > > > > > > > > > + The Intel PCIe controller is based on the Synopsys > > > > > > > > > Designware > > > > > > > > > + pcie core and therefore uses the Designware core > > > > > > > > > functions to > >
[PATCH v5] Staging: exfat: Avoid use of strcpy
Use strscpy instead of strcpy in exfat_core.c, and add a check for length that will return already known FFS_INVALIDPATH. Suggested-by: Rasmus Villemoes Signed-off-by: Sandro Volery --- v5: Fixed some whitespaces v4: Replaced strlen check v3: Failed to replace check v2: Forgot to replace strlen check v1: original patch drivers/staging/exfat/exfat_core.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/staging/exfat/exfat_core.c b/drivers/staging/exfat/exfat_core.c index da8c58149c35..ee474ae3bd98 100644 --- a/drivers/staging/exfat/exfat_core.c +++ b/drivers/staging/exfat/exfat_core.c @@ -2961,11 +2961,9 @@ s32 resolve_path(struct inode *inode, char *path, struct chain_t *p_dir, struct fs_info_t *p_fs = &(EXFAT_SB(sb)->fs_info); struct file_id_t *fid = &(EXFAT_I(inode)->fid); - if (strlen(path) >= (MAX_NAME_LENGTH * MAX_CHARSET_SIZE)) + if (strscpy(name_buf, path, sizeof(name_buf)) < 0) return FFS_INVALIDPATH; - strcpy(name_buf, path); - nls_cstring_to_uniname(sb, p_uniname, name_buf, &lossy); if (lossy) return FFS_INVALIDPATH; -- 2.23.0
Re: Linux 5.3-rc8
On Thu, Sep 12, 2019 at 05:44:21AM +0200, Ahmed S. Darwish wrote: > > People have suggested adding a new getrandom flag, > > GRND_I_KNOW_THIS_IS_INSECURE, > > or some such, which wouldn't block and would return "best efforts" > > randomness. I haven't been super enthusiastic about such a flag > > because I *know* it would be abused. However, the next time a massive > > security bug shows up on the front pages of the Wall Street Journal, > > or on some web site such as https://factorable.net, it won't be the > > kernel's fault > > since the flag will be GRND_INSECURE_BROKEN_APPLICATION, or some such. > > It doesn't really solve the problem, though. Hmm, one thought might be GRND_FAILSAFE, which will wait up to two minutes before returning "best efforts" randomness and issuing a huge massive warning if it is triggered? > At least for generating the MIT cookie, it would make some sort of > sense... Really caring about truly random-numbers while using Xorg > is almost like perfecting a hard-metal door for the paper house ;) For the MIT Magic Cookie, it might as well use GRND_NONBLOCK, and if it fails due to randomness being not available, it should just fall back to random_r(3). Or heck, just use random_r(3) all the time, since it's not at all secure anyway > Just 8 days ago, systemd v243 was released, with systemd-random-seed(8) > now supporting *crediting* the entropy while loading the random seed: > > https://systemd.io/RANDOM_SEEDS > > systemd-random-seed do something similar to what OpenBSD does, by > preserving the seed across reboots at /var/lib/systemd/random-seed. That makes it systemd's responsibility to properly manage the random seed file, and if the random seed file gets imaged, or if it gets read while the system is off, that's on systemd which is fine. The real problem here is that we're trying to engineer a system which makes it safe for real cryptographic systems, but there's no way to distinguish between real cryptographic systems where proper entropy is critical and pretend security systems like X.org's MIT Magic Cookie --- or python trying to get random numbers seeding its dictionary hash tables to avoid DOS attacks when python is used for CGI scripts --- but guess what happens when python is used for systemd generator scripts in early boot before the random seed file might even be mounted? In that case, python reverted to using /dev/urandom, which was probably the right choice --- it didn't *need* to use getrandom. > 1. Cutting down the number of bits needed to initialize the CRNG >to 256 bits (CHACHA20 cipher) Does the attach patch (see below) help? > 2. Complaining loudly when getrandom() is used while the CRNG is >not yet initialized. A kernel printk will make it easier for people to understand why their system is hung, in any case --- and which process is to blame. So that's definitely a good thing. - Ted diff --git a/drivers/char/random.c b/drivers/char/random.c index 5d5ea4ce1442..b9b3a5a82abf 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -500,7 +500,7 @@ static int crng_init = 0; #define crng_ready() (likely(crng_init > 1)) static int crng_init_cnt = 0; static unsigned long crng_global_init_time = 0; -#define CRNG_INIT_CNT_THRESH (2*CHACHA_KEY_SIZE) +#define CRNG_INIT_CNT_THRESH CHACHA_KEY_SIZE static void _extract_crng(struct crng_state *crng, __u8 out[CHACHA_BLOCK_SIZE]); static void _crng_backtrack_protect(struct crng_state *crng, __u8 tmp[CHACHA_BLOCK_SIZE], int used);
Re: [PATCH 1/4] mm/hmm: make full use of walk_page_range()
> +static int hmm_pfns_fill(unsigned long addr,
> + unsigned long end,
> + struct hmm_range *range,
> + enum hmm_pfn_value_e value)
Nit: can we use the space a little more efficient, e.g.:
static int hmm_pfns_fill(unsigned long addr, unsigned long end,
struct hmm_range *range, enum hmm_pfn_value_e value)
> +static int hmm_vma_walk_test(unsigned long start,
> + unsigned long end,
> + struct mm_walk *walk)
Same here.
> + if (!(vma->vm_flags & VM_READ)) {
> + (void) hmm_pfns_fill(start, end, range, HMM_PFN_NONE);
There should be no need for the void cast here.
[GIT PULL] last pin control fix for v5.3
Hi Linus, here is a hopefully last pin control fix for the Aspeed. Please pull it in! Yours, Linus Walleij The following changes since commit d45331b00ddb179e291766617259261c112db872: Linux 5.3-rc4 (2019-08-11 13:26:41 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git tags/pinctrl-v5.3-3 for you to fetch changes up to c1432423a16825ef94e019808ed7330ee33ffc69: pinctrl: aspeed: Fix spurious mux failures on the AST2500 (2019-09-12 00:08:27 +0100) Pin control fixes for v5.3: - A single patch for some Aspeed problems. The BMCs are much happier now. Andrew Jeffery (1): pinctrl: aspeed: Fix spurious mux failures on the AST2500 drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 30 +- drivers/pinctrl/aspeed/pinmux-aspeed.c | 7 +-- drivers/pinctrl/aspeed/pinmux-aspeed.h | 7 --- 3 files changed, 38 insertions(+), 6 deletions(-)
Re: [RFC PATCH 1/2] x86: Don't let pgprot_modify() change the page encryption bit
On 9/11/19 8:03 PM, Andy Lutomirski wrote: That distinction is important because if it ever comes to a choice between adding a new lock to protect vm_page_prot (and consequently slow down the whole vm system) and using the WRITE_ONCE solution in TTM, we should know what the implications are. As it turns out previous choices in this area actually seem to have opted for the lockless WRITE_ONCE / READ_ONCE / ptl solution. See __split_huge_pmd_locked() and vma_set_page_prot(). I think it would be even better if the whole thing could work without ever writing to vm_page_prot. This would be a requirement for vvar in the unlikely event that the vvar vma ever supported splittable huge pages. Fortunately, that seems unlikely :) Yeah, for TTM the situation is different since we want huge vm pages at some point. But I re-read __split_huge_pmd_locked() and it actually looks like vm_page_prot is only accessed for anonymous vmas. For other vmas, it appears it just simply zaps the PMD, relying on re-faulting the page table enries if necessary (as also suggested by Christian in another thread). So perhaps we should be good never writing to vm_page_prot. /Thomas
[PATCH v2 1/2] venus: use on-chip interconnect API
This aims to add a requests for bandwidth scaling depending
on the resolution and framerate (macroblocks per second). The
exact value of the requested bandwidth is get from a
pre-calculated tables for encoder and decoder.
Signed-off-by: Stanimir Varbanov
---
drivers/media/platform/Kconfig | 1 +
drivers/media/platform/qcom/venus/core.c| 34 +++
drivers/media/platform/qcom/venus/core.h| 14 +
drivers/media/platform/qcom/venus/helpers.c | 67 -
4 files changed, 115 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 83a785010753..97332dcb944c 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -483,6 +483,7 @@ config VIDEO_QCOM_VENUS
tristate "Qualcomm Venus V4L2 encoder/decoder driver"
depends on VIDEO_DEV && VIDEO_V4L2
depends on (ARCH_QCOM && IOMMU_DMA) || COMPILE_TEST
+ depends on INTERCONNECT || !INTERCONNECT
select QCOM_MDT_LOADER if ARCH_QCOM
select QCOM_SCM if ARCH_QCOM
select VIDEOBUF2_DMA_SG
diff --git a/drivers/media/platform/qcom/venus/core.c
b/drivers/media/platform/qcom/venus/core.c
index e6eff512a8a1..71aab25700e8 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -5,6 +5,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -239,6 +240,14 @@ static int venus_probe(struct platform_device *pdev)
if (IS_ERR(core->base))
return PTR_ERR(core->base);
+ core->video_path = of_icc_get(dev, "video-mem");
+ if (IS_ERR(core->video_path))
+ return PTR_ERR(core->video_path);
+
+ core->cpucfg_path = of_icc_get(dev, "cpu-cfg");
+ if (IS_ERR(core->cpucfg_path))
+ return PTR_ERR(core->cpucfg_path);
+
core->irq = platform_get_irq(pdev, 0);
if (core->irq < 0)
return core->irq;
@@ -273,6 +282,10 @@ static int venus_probe(struct platform_device *pdev)
if (ret)
return ret;
+ ret = icc_set_bw(core->cpucfg_path, 0, kbps_to_icc(1000));
+ if (ret)
+ return ret;
+
ret = hfi_create(core, &venus_core_ops);
if (ret)
return ret;
@@ -355,6 +368,9 @@ static int venus_remove(struct platform_device *pdev)
pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
+ icc_put(core->video_path);
+ icc_put(core->cpucfg_path);
+
v4l2_device_unregister(&core->v4l2_dev);
return ret;
@@ -464,9 +480,27 @@ static const struct freq_tbl sdm845_freq_table[] = {
{ 244800, 1 }, /* 1920x1080@30 */
};
+static const struct bw_tbl sdm845_bw_table_enc[] = {
+ { 1944000, 1612000, 0, 2416000, 0 },/* 3840x2160@60 */
+ { 972000, 951000, 0, 1434000, 0 },/* 3840x2160@30 */
+ { 489600, 723000, 0, 973000, 0 },/* 1920x1080@60 */
+ { 244800, 37, 0, 495000, 0 },/* 1920x1080@30 */
+};
+
+static const struct bw_tbl sdm845_bw_table_dec[] = {
+ { 2073600, 3929000, 0, 5551000, 0 },/* 4096x2160@60 */
+ { 1036800, 1987000, 0, 2797000, 0 },/* 4096x2160@30 */
+ { 489600, 104, 0, 1298000, 0 },/* 1920x1080@60 */
+ { 244800, 53, 0, 659000, 0 },/* 1920x1080@30 */
+};
+
static const struct venus_resources sdm845_res = {
.freq_tbl = sdm845_freq_table,
.freq_tbl_size = ARRAY_SIZE(sdm845_freq_table),
+ .bw_tbl_enc = sdm845_bw_table_enc,
+ .bw_tbl_enc_size = ARRAY_SIZE(sdm845_bw_table_enc),
+ .bw_tbl_dec = sdm845_bw_table_dec,
+ .bw_tbl_dec_size = ARRAY_SIZE(sdm845_bw_table_dec),
.clks = {"core", "iface", "bus" },
.clks_num = 3,
.max_load = 3110400,/* 4096x2160@90 */
diff --git a/drivers/media/platform/qcom/venus/core.h
b/drivers/media/platform/qcom/venus/core.h
index 922cb7e64bfa..661eaa7b81ec 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -26,10 +26,22 @@ struct reg_val {
u32 value;
};
+struct bw_tbl {
+ u32 mbs_per_sec;
+ u32 avg;
+ u32 peak;
+ u32 avg_10bit;
+ u32 peak_10bit;
+};
+
struct venus_resources {
u64 dma_mask;
const struct freq_tbl *freq_tbl;
unsigned int freq_tbl_size;
+ const struct bw_tbl *bw_tbl_enc;
+ unsigned int bw_tbl_enc_size;
+ const struct bw_tbl *bw_tbl_dec;
+ unsigned int bw_tbl_dec_size;
const struct reg_val *reg_tbl;
unsigned int reg_tbl_size;
const char * const clks[VIDC_CLKS_NUM_MAX];
@@ -115,6 +127,8 @@ struct venus_core {
struct clk *core1_clk;
struct clk *core0_bus_clk;
struct clk *core1_bus_clk;
+ struct icc_path *video_path;
+ struct icc_path *cpucfg_path;
struct video_device *vdev_dec;
struct video_device *vdev_enc;
[PATCH v2 2/2] arm64: dts: sdm845: Add interconnect properties for Venus
Populate Venus DT node with interconnect properties.
Signed-off-by: Stanimir Varbanov
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 0323e3da190a..567bfc89bd77 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -2039,6 +2039,9 @@
iommus = <&apps_smmu 0x10a0 0x8>,
<&apps_smmu 0x10b0 0x0>;
memory-region = <&venus_mem>;
+ interconnects = <&rsc_hlos MASTER_VIDEO_P0 &rsc_hlos
SLAVE_EBI1>,
+ <&rsc_hlos MASTER_APPSS_PROC &rsc_hlos
SLAVE_VENUS_CFG>;
+ interconnect-names = "video-mem", "cpu-cfg";
video-core0 {
compatible = "venus-decoder";
--
2.17.1
[PATCH v2 0/2] Venus interconnect support for sdm845
Hello, Here are two patches which adds interconnect bandwidth requests depending on the resolution (macroblocks) in order to lower bandwidth pressure on the interconnect and memory. Changes since v1: - correct typo in the 1/2 patch description - add a dependency to INTERCONNECT regards, Stan Stanimir Varbanov (2): venus: use on-chip interconnect API arm64: dts: sdm845: Add interconnect properties for Venus arch/arm64/boot/dts/qcom/sdm845.dtsi| 3 + drivers/media/platform/Kconfig | 1 + drivers/media/platform/qcom/venus/core.c| 34 +++ drivers/media/platform/qcom/venus/core.h| 14 + drivers/media/platform/qcom/venus/helpers.c | 67 - 5 files changed, 118 insertions(+), 1 deletion(-) -- 2.17.1
Greetings From Mrs Elodie,
Greetings From Mrs Elodie, Calvary Greetings in the name of the LORD Almighty and Our LORD JESUS CHRIST the giver of every good thing. Good day,i know this letter will definitely come to you as a huge surprise, but I implore you to take the time to go through it carefully as the decision you make will go off a long way to determine my future and continued existence. I am Mrs Elodie Antoine aging widow of 59 years old suffering from long time illness. I have some funds I inherited from my late husband, The sum of (US$4.5 Million Dollars) and I needed a very honest and God fearing who can withdraw this money then use the funds for Charity works. I WISH TO GIVE THIS FUNDS TO YOU FOR CHARITY WORKS. I found your email address from the internet after honest prayers to the LORD to bring me a helper and i decided to contact you if you may be willing and interested to handle these trust funds in good faith before anything happens to me. I accept this decision because I do not have any child who will inherit this money after I die. I want your urgent reply to me so that I will give you the deposit receipt which the COMPANY issued to me as next of kin for immediate transfer of the money to your account in your country, to start the good work of God, I want you to use the 15/percent of the total amount to help yourself in doing the project. I am desperately in keen need of assistance and I have summoned up courage to contact you for this task, you must not fail me and the millions of the poor people in our todays WORLD. This is no stolen money and there are no dangers involved,100% RISK FREE with full legal proof. Please if you would be able to use the funds for the Charity works kindly let me know immediately.I will appreciate your utmost confidentiality and trust in this matter to accomplish my heart desire, as I don't want anything that will jeopardize my last wish. I want you to take 15 percent of the total money for your personal use while 85% of the money will go to charity.I will appreciate your utmost confidentiality and trust in this matter to accomplish my heart desire, as I don't want anything that will jeopardize my last wish. kindly respond for further details. reply to my private E-mail:( elodieantoine76...@yahoo.com ) Thanks and God bless you, Mrs Elodie Antoine
Re: [PATCH v5] Staging: exfat: Avoid use of strcpy
You did it. Well done. :P Reviewed-by: Dan Carpenter regards, dan carpenter
[GIT PULL] IRQ fix
Linus, Please pull the latest irq-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-urgent-for-linus # HEAD: eddf3e9c7c7e4d0707c68d1bb22cc6ec8aef7d4a genirq: Prevent NULL pointer dereference in resend_irqs() Fix a race in the IRQ resend mechanism, which can result in a NULL dereference crash. Thanks, Ingo --> Yunfeng Ye (1): genirq: Prevent NULL pointer dereference in resend_irqs() kernel/irq/resend.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/irq/resend.c b/kernel/irq/resend.c index 95414ad3506a..98c04ca5fa43 100644 --- a/kernel/irq/resend.c +++ b/kernel/irq/resend.c @@ -36,6 +36,8 @@ static void resend_irqs(unsigned long arg) irq = find_first_bit(irqs_resend, nr_irqs); clear_bit(irq, irqs_resend); desc = irq_to_desc(irq); + if (!desc) + continue; local_irq_disable(); desc->handle_irq(desc); local_irq_enable();
[PATCH] tee: fix kasan check slab-out-of-bounds error.
From: fengchunguo Physical address should be set one shifting, but not cover shm struct data. If offs was set 0, it cause KASAN error. Log: [22.345259@0] BUG: KASAN: slab-out-of-bounds in optee_handle_rpc+0x644/0x858 [22.352221@0] Read of size 4 at addr ffc0445485dc by task tee_preload_fw/2505 [22.361280@0] CPU: 0 PID: 2505 Comm: tee_preload_fw Tainted: GB W O 4.19.53-01721-g11b1db7-dirty #417 [22.376617@0] Call trace: [22.379220@0] dump_backtrace+0x0/0x1b4 [22.383003@0] show_stack+0x20/0x28 [22.386459@0] dump_stack+0x8c/0xb4 [22.389909@0] print_address_description+0x10c/0x274 [22.394819@0] kasan_report+0x224/0x370 [22.398616@0] __asan_load4+0x6c/0x84 [22.402238@0] optee_handle_rpc+0x644/0x858 [22.406375@0] optee_do_call_with_arg+0x148/0x160 [22.411033@0] optee_open_session+0x1b0/0x340 [22.415352@0] tee_ioctl_open_session+0x28c/0x784 [22.420006@0] tee_ioctl+0x210/0x800 [22.423546@0] do_vfs_ioctl+0x104/0xe7c [22.427337@0] __arm64_sys_ioctl+0xac/0xc0 [22.431393@0] invoke_syscall+0xd4/0xf4 [22.435187@0] el0_svc_common+0x88/0x128 [22.439066@0] el0_svc_handler+0x40/0x84 [22.442947@0] el0_svc+0x8/0xc [22.445962@0] [22.447602@0] Allocated by task 2508: [22.451231@0] kasan_kmalloc.part.5+0x50/0x124 [22.455627@0] kasan_kmalloc+0xc4/0xe4 [22.459334@0] kmem_cache_alloc_trace+0x154/0x2bc [22.463994@0] tee_shm_alloc+0xa0/0x340 [22.467788@0] tee_ioctl+0x39c/0x800 [22.471324@0] do_vfs_ioctl+0x104/0xe7c [22.475119@0] __arm64_sys_ioctl+0xac/0xc0 [22.479172@0] invoke_syscall+0xd4/0xf4 [22.482967@0] el0_svc_common+0x88/0x128 [22.486849@0] el0_svc_handler+0x40/0x84 [22.490728@0] el0_svc+0x8/0xc [22.493743@0] [22.495384@0] Freed by task 0: [22.498408@0] __kasan_slab_free+0x11c/0x21c [22.502631@0] kasan_slab_free+0x10/0x18 [22.506511@0] kfree+0x8c/0x284 [22.509625@0] selinux_cred_free+0x48/0x64 [22.513672@0] security_cred_free+0x48/0x64 [22.517817@0] put_cred_rcu+0x3c/0x108 [22.521523@0] rcu_process_callbacks+0x308/0x7ac [22.526092@0] __do_softirq+0x1c8/0x5c8 [22.529882@0] [22.531527@0] The buggy address belongs to the object at ffc044548580 [22.531527@0] which belongs to the cache kmalloc-128 of size 128 [22.544291@0] The buggy address is located 92 bytes inside of [22.544291@0] 128-byte region [ffc044548580, ffc044548600) [22.556190@0] The buggy address belongs to the page: [22.561110@0] page:ffbf01115200 count:1 mapcount:0 mapping:ffc04540c400 index:0x0 compound_mapcount: 0 [22.571029@0] flags: 0x20094e4b00010200(slab|head) [22.575780@0] raw: 20094e4b00010200 ffbf01113408 ffbf01119508 ffc04540c400 [22.583622@0] raw: 00190019 0001 [22.591466@0] page dumped because: kasan: bad access detected [22.597157@0] [22.598797@0] Memory state around the buggy address: [22.603719@0] ffc044548480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [22.611048@0] ffc044548500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [22.618379@0] >ffc044548580: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc [22.625707@0] ^ [22.631920@0] ffc044548600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [22.639251@0] ffc044548680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [22.646580@0] == Test: 1. Set offs range,then test tee_preload successfully. / # tee_preload_fw use default tee_preload_fw pathfw_path=/lib/firmware/video/video_ucode.bin tee preload video fw ok / # echo $? 0 Signed-off-by: fengchunguo --- drivers/tee/tee_shm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c index 0b9ab1d0dd45..585361cd8dd9 100644 --- a/drivers/tee/tee_shm.c +++ b/drivers/tee/tee_shm.c @@ -461,7 +461,7 @@ int tee_shm_get_pa(struct tee_shm *shm, size_t offs, phys_addr_t *pa) if (offs >= shm->size) return -EINVAL; if (pa) - *pa = shm->paddr + offs; + *pa = shm->paddr + shm->size; return 0; } EXPORT_SYMBOL_GPL(tee_shm_get_pa); -- 2.22.0
Re: [PATCH V7 3/3] arm64/mm: Enable memory hot remove
On 09/12/2019 09:58 AM, Anshuman Khandual wrote:
>
> On 09/10/2019 09:47 PM, Catalin Marinas wrote:
>> On Tue, Sep 03, 2019 at 03:15:58PM +0530, Anshuman Khandual wrote:
>>> @@ -770,6 +1022,28 @@ int __meminit vmemmap_populate(unsigned long start,
>>> unsigned long end, int node,
>>> void vmemmap_free(unsigned long start, unsigned long end,
>>> struct vmem_altmap *altmap)
>>> {
>>> +#ifdef CONFIG_MEMORY_HOTPLUG
>>> + /*
>>> +* FIXME: We should have called remove_pagetable(start, end, true).
>>> +* vmemmap and vmalloc virtual range might share intermediate kernel
>>> +* page table entries. Removing vmemmap range page table pages here
>>> +* can potentially conflict with a concurrent vmalloc() allocation.
>>> +*
>>> +* This is primarily because vmalloc() does not take init_mm ptl for
>>> +* the entire page table walk and it's modification. Instead it just
>>> +* takes the lock while allocating and installing page table pages
>>> +* via [p4d|pud|pmd|pte]_alloc(). A concurrently vanishing page table
>>> +* entry via memory hot remove can cause vmalloc() kernel page table
>>> +* walk pointers to be invalid on the fly which can cause corruption
>>> +* or worst, a crash.
>>> +*
>>> +* So free_empty_tables() gets called where vmalloc and vmemmap range
>>> +* do not overlap at any intermediate level kernel page table entry.
>>> +*/
>>> + unmap_hotplug_range(start, end, true);
>>> + if (!vmalloc_vmemmap_overlap)
>>> + free_empty_tables(start, end);
>>> +#endif
>>> }
>>> #endif /* CONFIG_SPARSEMEM_VMEMMAP */
> Hello Catalin,
>
>> I wonder whether we could simply ignore the vmemmap freeing altogether,
>> just leave it around and not unmap it. This way, we could call
> This would have been an option (even if we just ignore for a moment that
> it might not be the cleanest possible method) if present memory hot remove
> scenarios involved just system RAM of comparable sizes.
>
> But with persistent memory which will be plugged in as ZONE_DEVICE might
> ask for a vmem_atlamp based vmemmap mapping where the backing memory comes
> from the persistent memory range itself not from existing system RAM. IIRC
> altmap support was originally added because the amount persistent memory on
> a system might be order of magnitude higher than that of regular system RAM.
> During normal memory hot add (without altmap) would have caused great deal
> of consumption from system RAM just for persistent memory range's vmemmap
> mapping. In order to avoid such a scenario altmap was created to allocate
> vmemmap mapping backing memory from the device memory range itself.
>
> In such cases vmemmap must be unmapped and it's backing memory freed up for
> the complete removal of persistent memory which originally requested for
> altmap based vmemmap backing.
>
> Just as a reference, the upcoming series which enables altmap support on
> arm64 tries to allocate vmemmap mapping backing memory from the device range
> itself during memory hot add and free them up during memory hot remove. Those
> methods will not be possible if memory hot-remove does not really free up
> vmemmap backing storage.
>
> https://patchwork.kernel.org/project/linux-mm/list/?series=139299
>
Just to add in here. There is an ongoing work which will enable allocating
memory from the hot-add range itself even for normal system RAM. So this
might not be specific to ZONE_DEVICE based device/persistent memory alone
for a long time.
https://lore.kernel.org/lkml/20190725160207.19579-1-osalva...@suse.de/
[GIT PULL] perf fix
Linus,
Please pull the latest perf-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-for-linus
# HEAD: 310aa0a25b338b3100c94880c9a69bec8ce8c3ae perf/hw_breakpoint: Fix
arch_hw_breakpoint use-before-initialization
Fix an initialization bug in the hw-breakpoints, which triggered on the
ARM platform.
Thanks,
Ingo
-->
Mark-PK Tsai (1):
perf/hw_breakpoint: Fix arch_hw_breakpoint use-before-initialization
kernel/events/hw_breakpoint.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c
index c5cd852fe86b..3cc8416ec844 100644
--- a/kernel/events/hw_breakpoint.c
+++ b/kernel/events/hw_breakpoint.c
@@ -413,7 +413,7 @@ static int hw_breakpoint_parse(struct perf_event *bp,
int register_perf_hw_breakpoint(struct perf_event *bp)
{
- struct arch_hw_breakpoint hw;
+ struct arch_hw_breakpoint hw = { };
int err;
err = reserve_bp_slot(bp);
@@ -461,7 +461,7 @@ int
modify_user_hw_breakpoint_check(struct perf_event *bp, struct perf_event_attr
*attr,
bool check)
{
- struct arch_hw_breakpoint hw;
+ struct arch_hw_breakpoint hw = { };
int err;
err = hw_breakpoint_parse(bp, attr, &hw);
Re: [PATCH v5] Staging: exfat: Avoid use of strcpy
> On 12 Sep 2019, at 10:34, Dan Carpenter wrote: > > You did it. Well done. :P > > Reviewed-by: Dan Carpenter Thanks :D Had some issues with my git configuration setting up a home workstation but now it is all fine
Re: [PATCH 00/13] nvdimm: Use more common kernel coding style
On Thu, Sep 12, 2019 at 10:15 AM Joe Perches wrote: > > I am adding Miguel Ojeda to the cc's. Thanks Joe! > Of course you are welcome to try it, but I believe that > clang-format doesn't work all that well yet. > > It's more a work in progress rather than a "standard". > > I believe you'll find that the patch series I sent > ends up with a rather more typical kernel style. > > I suggest you try to apply the series I sent and then > run clang-format on that and see the differences. Indeed, it is not there just yet. There are a few differences w.r.t. the kernel style that aren't supported yet. However, for block/batch conversions, it is very useful. Luckily, one of the biggest ones (the consecutive macros alignment, and we have a lot of them given this is C and a kernel) is going away with LLVM 9 which is about to be released next week. > Ideally one day, something tool like clang-format > might be locally applied by every developer for their > own personal style with some other neutral style the > content actually distributed. If that day comes, I hope we can all agree to a single format and apply it everywhere as other major projects have done. I think agreeing to a given style is much, much easier for any of us when formatting is fully automatic -- because at that point you don't need to spend mental cycles (and memory!) on it. :-) If I had to guess, I would say the path forward will start with some subsystem maintainers starting to apply clang-format systematically on their trees. That is why I think it is very useful that Dan tries it out and let us know his impressions. Cheers, Miguel
RE: [PATCH] arm64: psci: Use udelay() instead of msleep() to reduce waiting time
From: Yunfeng Ye
> Sent: 11 September 2019 09:50
> We want to reduce the time of cpu_down() for saving power, found that
> cpu_psci_cpu_kill() cost 10ms after psci_ops.affinity_info() fail.
>
> Normally the time cpu dead is very short, it is no need to wait 10ms.
> so use udelay 10us to instead msleep 10ms in every waiting loop, and add
> cond_resched() to give a chance to run a higher-priority process.
>
> Signed-off-by: Yunfeng Ye
> ---
> arch/arm64/kernel/psci.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
> index 85ee7d0..9e9d8a6 100644
> --- a/arch/arm64/kernel/psci.c
> +++ b/arch/arm64/kernel/psci.c
> @@ -86,15 +86,15 @@ static int cpu_psci_cpu_kill(unsigned int cpu)
>* while it is dying. So, try again a few times.
>*/
>
> - for (i = 0; i < 10; i++) {
> + for (i = 0; i < 1; i++) {
> err = psci_ops.affinity_info(cpu_logical_map(cpu), 0);
> if (err == PSCI_0_2_AFFINITY_LEVEL_OFF) {
> pr_info("CPU%d killed.\n", cpu);
> return 0;
> }
>
> - msleep(10);
> - pr_info("Retrying again to check for CPU kill\n");
> + cond_resched();
> + udelay(10);
You really don't want to be doing 1 udelay(10) before giving up.
If udelay(10) is long enough for the normal case, then do that once.
After that use usleep_range().
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
Re: [UNVERIFIED SENDER] Re: [PATCH v2 2/3] soc: amazon: al-pos: Introduce Amazon's Annapurna Labs POS driver
On Thu, 12 Sep 2019 07:50:03 +0100, "Shenhar, Talel" wrote: > > Hi Marc, > > > On 9/11/2019 5:15 PM, Marc Zyngier wrote: > > [+James] > > > > Hi Talel, > > > > On Tue, 10 Sep 2019 20:05:09 +0100, > > Talel Shenhar wrote: > > > >> + log1 = readl(pos->mmio_base + AL_POS_ERROR_LOG_1); > > Do you actually need the implied barriers? I'd expect that relaxed > > accesses should be enough. > > You are correct. Barriers are not needed, In v1 this driver indeed > used _relaxed versions. > > Due to request coming from Arnd in v1 patch series I removed it. As > this is not data path I had no strong objection for removing it. Independently from whether this has any material impact on performance (this obviously isn't a hot path, unless it can be directly generated by userspace or a guest), I believe it is important to use the right type of accessor, if only because code gets copied around... Others would probably argue that this is the very reason why we should always use the "safe" option... > > > > >> + if (!FIELD_GET(AL_POS_ERROR_LOG_1_VALID, log1)) > >> + return IRQ_NONE; > >> + > >> + log0 = readl(pos->mmio_base + AL_POS_ERROR_LOG_0); > >> + writel(0, pos->mmio_base + AL_POS_ERROR_LOG_1); > >> + > >> + addr = FIELD_GET(AL_POS_ERROR_LOG_0_ADDR_LOW, log0); > >> + addr |= (FIELD_GET(AL_POS_ERROR_LOG_1_ADDR_HIGH, log1) << 32); > >> + request_id = FIELD_GET(AL_POS_ERROR_LOG_1_REQUEST_ID, log1); > >> + bresp = FIELD_GET(AL_POS_ERROR_LOG_1_BRESP, log1); > >> + > >> + dev_err(&pdev->dev, "addr=0x%llx request_id=0x%x bresp=0x%x\n", > >> + addr, request_id, bresp); > > What is this information? How do we make use of it? Given that this is > > asynchronous, how do we correlate it to the offending software? > > Indeed this information arriving from the HW is asynchronous. > > There is no direct method to get the offending software. > > There are all kinds of hacks we do to find the offending software once > we find this error. most of the time its a new patch introduced but > some of the time is just digging. OK, so that the moment, this is more of a debug tool than anything else, right? > > The whole think looks to me like a poor man's EDAC handling, and I'd > > expect to be plugged in that subsystem instead. Any reason why this > > isn't the case? It would certainly make the handling uniform for the > > user. > > This logic was not plugged into EDAC as there is no "Correctable" > error here. its just error event. Not all errors are EDAC in the sense > of Error Detection And *Correction*. There are no correctable errors > for this driver. I'd argue the opposite! Because you obviously don't let a read-only register being written to, the error has been corrected, and you signal the correction status. > So plugging it under EDAC seems like abusing the EDAC system. > > Now that I've emphasize the reason for not putting this under EDAC, > what do you think? should this "only uncorrectable event" driver > should be part of EDAC? My choice would be to plug it into the EDAC subsystem, and report all interrupts as "Corrected" events. Optionally, and only if you are debugging something that requires it, report the error as "Uncorrectable", in which case the EDAC subsystem should trigger a panic. At least you'd get the infrastructure, logging and tooling that the EDAC subsystem offers (parsing the kernel log doesn't really count). Thanks, M. -- Jazz is not dead, it just smells funny.
RE: [RFC][PATCH 1/2] Fix event.c misaligned address error
From: Ian Rogers
> Sent: 11 September 2019 10:09
> On Wed, Jul 24, 2019 at 3:50 PM Numfor Mbiziwo-Tiapo wrote:
> >
> > The ubsan (undefined behavior sanitizer) build of perf throws an
> > error when the synthesize "Synthesize cpu map" function from
> > perf test is run.
> >
> > This can be reproduced by running (from the tip directory):
> > make -C tools/perf USE_CLANG=1 EXTRA_CFLAGS="-fsanitize=undefined"
> >
> > (see cover letter for why perf may not build)
> >
> > then running: tools/perf/perf test 44 -v
> >
> > This bug occurs because the cpu_map_data__synthesize function in
> > event.c calls synthesize_mask, casting the 'data' variable
> > (of type cpu_map_data*) to a cpu_map_mask*. Since struct
> > cpu_map_data is 2 byte aligned and struct cpu_map_mask is 8 byte
> > aligned this causes memory alignment issues.
> >
> > This is fixed by adding 6 bytes of padding to the struct cpu_map_data,
> > however, this will break compatibility between perf data files - a file
> > written by an old perf wouldn't work with a perf with this patch due
> > to event data alignment changing.
> >
> > Comments?
> >
> > Not-Quite-Signed-off-by: Numfor Mbiziwo-Tiapo
> > ---
> > tools/perf/util/event.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
> > index eb95f3384958..82eaf06c2604 100644
> > --- a/tools/perf/util/event.h
> > +++ b/tools/perf/util/event.h
> > @@ -433,6 +433,7 @@ struct cpu_map_mask {
> >
> > struct cpu_map_data {
> > u16 type;
> > + u8 pad[6];
> > chardata[];
> > };
> >
> > --
> > 2.22.0.657.g960e92d24f-goog
> >
> An idea here is that, if this breaks backward compatibility, we
> introduce an aligned variant and work to deprecate the unaligned
> variant. I will look into making a patch set.
Adding a pad[6] makes no difference.
You need to add aligened(8) to the structure itself as well.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
Re: [PATCH] KVM: x86: work around leak of uninitialized stack contents
Fuqian Huang writes: > Emulation of VMPTRST can incorrectly inject a page fault > when passed an operand that points to an MMIO address. > The page fault will use uninitialized kernel stack memory > as the CR2 and error code. > > The right behavior would be to abort the VM with a KVM_EXIT_INTERNAL_ERROR > exit to userspace; Hm, why so? KVM_EXIT_INTERNAL_ERROR is basically an error in KVM, this is not a proper reaction to a userspace-induced condition (or ever). I also looked at VMPTRST's description in Intel's manual and I can't find and explicit limitation like "this must be normal memory". We're just supposed to inject #PF "If a page fault occurs in accessing the memory destination operand." In case it seems to be too cumbersome to handle VMPTRST to MMIO and we think that nobody should be doing that I'd rather prefer injecting #GP. Please tell me what I'm missing :-) > however, it is not an easy fix, so for now just ensure > that the error code and CR2 are zero. > > Signed-off-by: Fuqian Huang > --- > arch/x86/kvm/x86.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 290c3c3efb87..7f442d710858 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -5312,6 +5312,7 @@ int kvm_write_guest_virt_system(struct kvm_vcpu *vcpu, > gva_t addr, void *val, > /* kvm_write_guest_virt_system can pull in tons of pages. */ > vcpu->arch.l1tf_flush_l1d = true; > > + memset(exception, 0, sizeof(*exception)); > return kvm_write_guest_virt_helper(addr, val, bytes, vcpu, > PFERR_WRITE_MASK, exception); > } -- Vitaly
Re: [PATCH] KVM: x86: work around leak of uninitialized stack contents
Vitaly Kuznetsov 於 2019年9月12日週四 下午4:51寫道：
>
> Fuqian Huang writes:
>
> > Emulation of VMPTRST can incorrectly inject a page fault
> > when passed an operand that points to an MMIO address.
> > The page fault will use uninitialized kernel stack memory
> > as the CR2 and error code.
> >
> > The right behavior would be to abort the VM with a KVM_EXIT_INTERNAL_ERROR
> > exit to userspace;
>
> Hm, why so? KVM_EXIT_INTERNAL_ERROR is basically an error in KVM, this
> is not a proper reaction to a userspace-induced condition (or ever).
>
> I also looked at VMPTRST's description in Intel's manual and I can't
> find and explicit limitation like "this must be normal memory". We're
> just supposed to inject #PF "If a page fault occurs in accessing the
> memory destination operand."
>
> In case it seems to be too cumbersome to handle VMPTRST to MMIO and we
> think that nobody should be doing that I'd rather prefer injecting #GP.
>
> Please tell me what I'm missing :-)
I found it during the code review, and it looks like the problem the
commit 353c0956a618 ("KVM: x86: work around leak of uninitialized
stack contents (CVE-2019-7222)")
mentions. So I fixed it in a similar way.
>
> > however, it is not an easy fix, so for now just ensure
> > that the error code and CR2 are zero.
> >
> > Signed-off-by: Fuqian Huang
> > ---
> > arch/x86/kvm/x86.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 290c3c3efb87..7f442d710858 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -5312,6 +5312,7 @@ int kvm_write_guest_virt_system(struct kvm_vcpu
> > *vcpu, gva_t addr, void *val,
> > /* kvm_write_guest_virt_system can pull in tons of pages. */
> > vcpu->arch.l1tf_flush_l1d = true;
> >
> > + memset(exception, 0, sizeof(*exception));
> > return kvm_write_guest_virt_helper(addr, val, bytes, vcpu,
> > PFERR_WRITE_MASK, exception);
> > }
>
> --
> Vitaly
Re: [PATCH RFC] gpio: Add Virtual Aggregator GPIO Driver
On Fri, Jul 5, 2019 at 5:05 PM Geert Uytterhoeven wrote: > GPIO controllers are exported to userspace using /dev/gpiochip* > character devices. Access control to these devices is provided by > standard UNIX file system permissions, on an all-or-nothing basis: > either a GPIO controller is accessible for a user, or it is not. > Currently no mechanism exists to control access to individual GPIOs. > > Hence add a virtual GPIO driver to aggregate existing GPIOs (up to 32), > and expose them as a new gpiochip. This is useful for implementing > access control, and assigning a set of GPIOs to a specific user. > Furthermore, it would simplify and harden exporting GPIOs to a virtual > machine, as the VM can just grab the full virtual GPIO controller, and > no longer needs to care about which GPIOs to grab and which not, > reducing the attack surface. > > Virtual GPIO controllers are instantiated by writing to the "new_device" > attribute file in sysfs: > > $ echo " [ ...]" >"[, [ ...]] ...]" > > /sys/bus/platform/drivers/gpio-virt-agg/new_device > > Likewise, virtual GPIO controllers can be destroyed after use: > > $ echo gpio-virt-agg. \ > > /sys/bus/platform/drivers/gpio-virt-agg/delete_device > > Signed-off-by: Geert Uytterhoeven > --- > Aggregating GPIOs and exposing them as a new gpiochip was suggested in > response to my proof-of-concept for GPIO virtualization with QEMU[1][2]. > > Sample session on r8a7791/koelsch: > > - Disable the leds node in arch/arm/boot/dts/r8a7791-koelsch.dts > > - Create virtual aggregators: > > $ echo "e6052000.gpio 19 20" \ > > /sys/bus/platform/drivers/gpio-virt-agg/new_device > > gpio-virt-agg gpio-virt-agg.0: GPIO 0 => e6052000.gpio/19 > gpio-virt-agg gpio-virt-agg.0: GPIO 1 => e6052000.gpio/20 > gpiochip_find_base: found new base at 778 > gpio gpiochip8: (gpio-virt-agg.0): added GPIO chardev (254:8) > gpiochip_setup_dev: registered GPIOs 778 to 779 on device: gpiochip8 > (gpio-virt-agg.0) > > $ echo "e6052000.gpio 21, e605.gpio 20 21 22" \ > > /sys/bus/platform/drivers/gpio-virt-agg/new_device > > gpio-virt-agg gpio-virt-agg.1: GPIO 0 => e6052000.gpio/21 > gpio-virt-agg gpio-virt-agg.1: GPIO 1 => e605.gpio/20 > gpio-virt-agg gpio-virt-agg.1: GPIO 2 => e605.gpio/21 > gpio-virt-agg gpio-virt-agg.1: GPIO 3 => e605.gpio/22 > gpiochip_find_base: found new base at 774 > gpio gpiochip9: (gpio-virt-agg.1): added GPIO chardev (254:9) > gpiochip_setup_dev: registered GPIOs 774 to 777 on device: gpiochip9 > (gpio-virt-agg.1) > > - Adjust permissions on /dev/gpiochip[89] (optional) > > - Control LEDs: > > $ gpioset gpiochip8 0=0 1=1 # LED6 OFF, LED7 ON > $ gpioset gpiochip8 0=1 1=0 # LED6 ON, LED7 OFF > $ gpioset gpiochip9 0=0 # LED8 OFF > $ gpioset gpiochip9 0=1 # LED8 ON > > - Destroy virtual aggregators: > > $ echo gpio-virt-agg.0 \ > > /sys/bus/platform/drivers/gpio-virt-agg/delete_device > $ echo gpio-virt-agg.1 \ > > /sys/bus/platform/drivers/gpio-virt-agg/delete_device > > Thanks for your comments! > > References: > - [1] "[PATCH QEMU POC] Add a GPIO backend" > > (https://lore.kernel.org/linux-renesas-soc/20181003152521.23144-1-geert+rene...@glider.be/) > - [2] "Getting To Blinky: Virt Edition / Making device pass-through > work on embedded ARM" > (https://fosdem.org/2019/schedule/event/vai_getting_to_blinky/) I'm looping in my friends at Google for this discussion. They need a virtualized gpio_chip for their Android emulator, and their current approach for other devices has been around using virtio in most cases and an emulated AC97 for the audio case as far as I remember. It would be great to have their input on this so we can create a virtualization/aggregate that works for all. Please include ade...@google.com on future postings of this! Yours, Linus Walleij
Re: [PATCH RFC] gpio: Add Virtual Aggregator GPIO Driver
Hi Linus,
On Thu, Sep 12, 2019 at 10:56 AM Linus Walleij wrote:
> On Fri, Jul 5, 2019 at 5:05 PM Geert Uytterhoeven
> wrote:
> > GPIO controllers are exported to userspace using /dev/gpiochip*
> > character devices. Access control to these devices is provided by
> > standard UNIX file system permissions, on an all-or-nothing basis:
> > either a GPIO controller is accessible for a user, or it is not.
> > Currently no mechanism exists to control access to individual GPIOs.
> >
> > Hence add a virtual GPIO driver to aggregate existing GPIOs (up to 32),
> > and expose them as a new gpiochip. This is useful for implementing
> > access control, and assigning a set of GPIOs to a specific user.
> > Furthermore, it would simplify and harden exporting GPIOs to a virtual
> > machine, as the VM can just grab the full virtual GPIO controller, and
> > no longer needs to care about which GPIOs to grab and which not,
> > reducing the attack surface.
> >
> > Virtual GPIO controllers are instantiated by writing to the "new_device"
> > attribute file in sysfs:
> >
> > $ echo " [ ...]"
> >"[, [ ...]] ...]"
> > > /sys/bus/platform/drivers/gpio-virt-agg/new_device
> >
> > Likewise, virtual GPIO controllers can be destroyed after use:
> >
> > $ echo gpio-virt-agg. \
> > > /sys/bus/platform/drivers/gpio-virt-agg/delete_device
> >
> > Signed-off-by: Geert Uytterhoeven
> > ---
> > Aggregating GPIOs and exposing them as a new gpiochip was suggested in
> > response to my proof-of-concept for GPIO virtualization with QEMU[1][2].
> >
> > Sample session on r8a7791/koelsch:
> >
> > - Disable the leds node in arch/arm/boot/dts/r8a7791-koelsch.dts
> >
> > - Create virtual aggregators:
> >
> > $ echo "e6052000.gpio 19 20" \
> > > /sys/bus/platform/drivers/gpio-virt-agg/new_device
> >
> > gpio-virt-agg gpio-virt-agg.0: GPIO 0 => e6052000.gpio/19
> > gpio-virt-agg gpio-virt-agg.0: GPIO 1 => e6052000.gpio/20
> > gpiochip_find_base: found new base at 778
> > gpio gpiochip8: (gpio-virt-agg.0): added GPIO chardev (254:8)
> > gpiochip_setup_dev: registered GPIOs 778 to 779 on device: gpiochip8
> > (gpio-virt-agg.0)
> >
> > $ echo "e6052000.gpio 21, e605.gpio 20 21 22" \
> > > /sys/bus/platform/drivers/gpio-virt-agg/new_device
> >
> > gpio-virt-agg gpio-virt-agg.1: GPIO 0 => e6052000.gpio/21
> > gpio-virt-agg gpio-virt-agg.1: GPIO 1 => e605.gpio/20
> > gpio-virt-agg gpio-virt-agg.1: GPIO 2 => e605.gpio/21
> > gpio-virt-agg gpio-virt-agg.1: GPIO 3 => e605.gpio/22
> > gpiochip_find_base: found new base at 774
> > gpio gpiochip9: (gpio-virt-agg.1): added GPIO chardev (254:9)
> > gpiochip_setup_dev: registered GPIOs 774 to 777 on device: gpiochip9
> > (gpio-virt-agg.1)
> >
> > - Adjust permissions on /dev/gpiochip[89] (optional)
> >
> > - Control LEDs:
> >
> > $ gpioset gpiochip8 0=0 1=1 # LED6 OFF, LED7 ON
> > $ gpioset gpiochip8 0=1 1=0 # LED6 ON, LED7 OFF
> > $ gpioset gpiochip9 0=0 # LED8 OFF
> > $ gpioset gpiochip9 0=1 # LED8 ON
> >
> > - Destroy virtual aggregators:
> >
> > $ echo gpio-virt-agg.0 \
> > > /sys/bus/platform/drivers/gpio-virt-agg/delete_device
> > $ echo gpio-virt-agg.1 \
> > > /sys/bus/platform/drivers/gpio-virt-agg/delete_device
> >
> > Thanks for your comments!
> >
> > References:
> > - [1] "[PATCH QEMU POC] Add a GPIO backend"
> >
> > (https://lore.kernel.org/linux-renesas-soc/20181003152521.23144-1-geert+rene...@glider.be/)
> > - [2] "Getting To Blinky: Virt Edition / Making device pass-through
> > work on embedded ARM"
> > (https://fosdem.org/2019/schedule/event/vai_getting_to_blinky/)
>
> I'm looping in my friends at Google for this discussion.
>
> They need a virtualized gpio_chip for their Android emulator,
> and their current approach for other devices has been around
> using virtio in most cases and an emulated AC97 for the
> audio case as far as I remember.
>
> It would be great to have their input on this so we can create a
> virtualization/aggregate that works for all.
>
> Please include ade...@google.com on future postings of this!
I've sent v2 yesterday:
https://lore.kernel.org/lkml/20190911143858.13024-1-geert+rene...@glider.be/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH] KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl
When the userspace program runs the KVM_S390_INTERRUPT ioctl to inject an interrupt, we convert them from the legacy struct kvm_s390_interrupt to the new struct kvm_s390_irq via the s390int_to_s390irq() function. However, this function does not take care of all types of interrupts that we can inject into the guest later (see do_inject_vcpu()). Since we do not clear out the s390irq values before calling s390int_to_s390irq(), there is a chance that we copy unwanted data from the kernel stack into the guest memory later if the interrupt data has not been properly initialized by s390int_to_s390irq(). Specifically, the problem exists with the KVM_S390_INT_PFAULT_INIT interrupt: s390int_to_s390irq() does not handle it, but the function __deliver_pfault_init() will later copy the uninitialized stack data from the ext.ext_params2 into the guest memory. Fix it by handling that interrupt type in s390int_to_s390irq(), too. And while we're at it, make sure that s390int_to_s390irq() now directly returns -EINVAL for unknown interrupt types, so that we do not run into this problem again in case we add more interrupt types to do_inject_vcpu() sometime in the future. Signed-off-by: Thomas Huth --- arch/s390/kvm/interrupt.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c index 3e7efdd9228a..165dea4c7f19 100644 --- a/arch/s390/kvm/interrupt.c +++ b/arch/s390/kvm/interrupt.c @@ -1960,6 +1960,16 @@ int s390int_to_s390irq(struct kvm_s390_interrupt *s390int, case KVM_S390_MCHK: irq->u.mchk.mcic = s390int->parm64; break; + case KVM_S390_INT_PFAULT_INIT: + irq->u.ext.ext_params = s390int->parm; + irq->u.ext.ext_params2 = s390int->parm64; + break; + case KVM_S390_RESTART: + case KVM_S390_INT_CLOCK_COMP: + case KVM_S390_INT_CPU_TIMER: + break; + default: + return -EINVAL; } return 0; } -- 2.18.1
REQUEST FOR YOUR ASSISTANCE.
-- Hello, Compliment of the season. My name is Dr. Omar Kalifa. i work with one of the reputable banks here in West Africa.I have a lucrative and profitable business to discuse with you. Reply if you are intersted for more details. Regards, Dr. Omar Kalifa
[PATCH v3 0/2] hwrng: npcm: add NPCM RNG driver support
This patch set adds Random Number Generator (RNG) support for the Nuvoton NPCM Baseboard Management Controller (BMC). The RNG driver we use power consumption when the RNG is not required. The NPCM RNG driver tested on NPCM750 evaluation board. Addressed comments from:. - Daniel Thompson: https://lkml.org/lkml/2019/9/10/352 - Milton Miller II : https://lkml.org/lkml/2019/9/10/847 - Daniel Thompson: https://lkml.org/lkml/2019/9/10/294 Changes since version 2: - Rearrange wait parameter in npcm_rng_read function. - Calling pm_runtime_enable function before hwrng_register function called to enable the hwrng before add_early_randomness called. - Remove quality dt-binding parameter in the driver and documentation. - Disable CONFIG_PM if devm_hwrng_register failed. - Remove owner setting in the driver struct. Changes since version 1: - Define timout in real-world units. - Using readl_poll_timeout in rng_read function. - Honor wait parameter in rng_read function. - Using local variable instead of #ifndef. - Remove probe print. Tomer Maimon (2): dt-binding: hwrng: add NPCM RNG documentation hwrng: npcm: add NPCM RNG driver .../bindings/rng/nuvoton,npcm-rng.txt | 12 ++ drivers/char/hw_random/Kconfig| 13 ++ drivers/char/hw_random/Makefile | 1 + drivers/char/hw_random/npcm-rng.c | 186 ++ 4 files changed, 212 insertions(+) create mode 100644 Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.txt create mode 100644 drivers/char/hw_random/npcm-rng.c -- 2.18.0
Re: [PATCH 5/5] hugetlbfs: Limit wait time when trying to share huge PMD
On 9/12/19 4:26 AM, Mike Kravetz wrote:
> On 9/11/19 8:05 AM, Waiman Long wrote:
>> When allocating a large amount of static hugepages (~500-1500GB) on a
>> system with large number of CPUs (4, 8 or even 16 sockets), performance
>> degradation (random multi-second delays) was observed when thousands
>> of processes are trying to fault in the data into the huge pages. The
>> likelihood of the delay increases with the number of sockets and hence
>> the CPUs a system has. This only happens in the initial setup phase
>> and will be gone after all the necessary data are faulted in.
>>
>> These random delays, however, are deemed unacceptable. The cause of
>> that delay is the long wait time in acquiring the mmap_sem when trying
>> to share the huge PMDs.
>>
>> To remove the unacceptable delays, we have to limit the amount of wait
>> time on the mmap_sem. So the new down_write_timedlock() function is
>> used to acquire the write lock on the mmap_sem with a timeout value of
>> 10ms which should not cause a perceivable delay. If timeout happens,
>> the task will abandon its effort to share the PMD and allocate its own
>> copy instead.
>>
>
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 6d7296dd11b8..445af661ae29 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -4750,6 +4750,8 @@ void adjust_range_if_pmd_sharing_possible(struct
>> vm_area_struct *vma,
>> }
>> }
>>
>> +#define PMD_SHARE_DISABLE_THRESHOLD (1 << 8)
>> +
>> /*
>> * Search for a shareable pmd page for hugetlb. In any case calls
>> pmd_alloc()
>> * and returns the corresponding pte. While this is not necessary for the
>> @@ -4770,11 +4772,24 @@ pte_t *huge_pmd_share(struct mm_struct *mm, unsigned
>> long addr, pud_t *pud)
>> pte_t *spte = NULL;
>> pte_t *pte;
>> spinlock_t *ptl;
>> +static atomic_t timeout_cnt;
>>
>> -if (!vma_shareable(vma, addr))
>> -return (pte_t *)pmd_alloc(mm, pud, addr);
>> +/*
>> + * Don't share if it is not sharable or locking attempt timed out
>> + * after 10ms. After 256 timeouts, PMD sharing will be permanently
>> + * disabled as it is just too slow.
>> + */
>> +if (!vma_shareable(vma, addr) ||
>> + (atomic_read(&timeout_cnt) >= PMD_SHARE_DISABLE_THRESHOLD))
>> +goto out_no_share;
>> +
>> +if (!i_mmap_timedlock_write(mapping, ms_to_ktime(10))) {
>> +if (atomic_inc_return(&timeout_cnt) ==
>> +PMD_SHARE_DISABLE_THRESHOLD)
>> +pr_info("Hugetlbfs PMD sharing disabled because of
>> timeouts!\n");
>> +goto out_no_share;
>> +}
>>
>> -i_mmap_lock_write(mapping);
> All this got me wondering if we really need to take i_mmap_rwsem in write
> mode here. We are not changing the tree, only traversing it looking for
> a suitable vma.
>
> Unless I am missing something, the hugetlb code only ever takes the semaphore
> in write mode; never read. Could this have been the result of changing the
> tree semaphore to read/write? Instead of analyzing all the code, the easiest
> and safest thing would have been to take all accesses in write mode.
>
> I can investigate more, but wanted to ask the question in case someone already
> knows.
>
> At one time, I thought it was safe to acquire the semaphore in read mode for
> huge_pmd_share, but write mode for huge_pmd_unshare. See commit b43a99900559.
> This was reverted along with another patch for other reasons.
>
> If we change change from write to read mode, this may have significant impact
> on the stalls.
If we can take the rwsem in read mode, that should solve the problem
AFAICS. As I don't have a full understanding of the history of that
code, I didn't try to do that in my patch.
Cheers,
Longman
Re: [PATCH] gpio: htc-egpio: Remove unused exported htc_egpio_get_wakeup_irq()
On Tue, Sep 10, 2019 at 3:15 PM Geert Uytterhoeven wrote: > This function was never used upstream, and is a relic of the original > handhelds.org code the htc-egpio driver was based on. > > Signed-off-by: Geert Uytterhoeven Patch applied. Yours, Linus Walleij
[PATCH] soc: qcom: socinfo: add missing soc_id sysfs entry
looks like SoC ID is not exported to sysfs for some reason. This patch adds it! This is mostly used by userspace libraries like SNPE. Signed-off-by: Srinivas Kandagatla --- drivers/soc/qcom/socinfo.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c index 8dc86a74559b..876a3f6612a3 100644 --- a/drivers/soc/qcom/socinfo.c +++ b/drivers/soc/qcom/socinfo.c @@ -422,6 +422,8 @@ static int qcom_socinfo_probe(struct platform_device *pdev) qs->attr.family = "Snapdragon"; qs->attr.machine = socinfo_machine(&pdev->dev, le32_to_cpu(info->id)); + qs->attr.soc_id = devm_kasprintf(&pdev->dev, GFP_KERNEL, "%u", +le32_to_cpu(info->id)); qs->attr.revision = devm_kasprintf(&pdev->dev, GFP_KERNEL, "%u.%u", SOCINFO_MAJOR(le32_to_cpu(info->ver)), SOCINFO_MINOR(le32_to_cpu(info->ver))); -- 2.21.0
[PATCH] soc: qcom: socinfo: add sdm845 and sda845 soc ids
This patch adds missing soc ids for sdm845 and sda845
Signed-off-by: Srinivas Kandagatla
---
drivers/soc/qcom/socinfo.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
index 855353bed19e..8dc86a74559b 100644
--- a/drivers/soc/qcom/socinfo.c
+++ b/drivers/soc/qcom/socinfo.c
@@ -198,6 +198,8 @@ static const struct soc_id soc_id[] = {
{ 310, "MSM8996AU" },
{ 311, "APQ8096AU" },
{ 312, "APQ8096SG" },
+ { 321, "SDM845"},
+ { 341, "SDA845"},
};
static const char *socinfo_machine(struct device *dev, unsigned int id)
--
2.21.0
Re: [PATCH] mfd: mt6360: add pmic mt6360 driver
Hi Gene Chen, Please use ./scripts/get_maintainer.pl to find out which are the maintainer(s) for a specific series/patch. I added Lee Jones, who is the maintainer of the MTD subsystem. Right now I have no time to review the patches, sorry. Regards, Matthias On 12/09/2019 10:10, Gene Chen wrote: > From: Gene Chen > > --- > drivers/mfd/Kconfig | 12 ++ > drivers/mfd/Makefile | 1 + > drivers/mfd/mt6360-core.c | 463 > ++ > 3 files changed, 476 insertions(+) > create mode 100644 drivers/mfd/mt6360-core.c > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index f129f96..a422c76 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -862,6 +862,18 @@ config MFD_MAX8998 > additional drivers must be enabled in order to use the functionality > of the device. > > +config MFD_MT6360 > + tristate "Mediatek MT6360 SubPMIC" > + select MFD_CORE > + select REGMAP_I2C > + select REGMAP_IRQ > + depends on I2C > + help > + Say Y here to enable MT6360 PMU/PMIC/LDO functional support. > + PMU part include charger, flashlight, rgb led > + PMIC part include 2-channel BUCKs and 2-channel LDOs > + LDO part include 4-channel LDOs > + > config MFD_MT6397 > tristate "MediaTek MT6397 PMIC Support" > select MFD_CORE > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > index f026ada..77a8f0b 100644 > --- a/drivers/mfd/Makefile > +++ b/drivers/mfd/Makefile > @@ -241,6 +241,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o > obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC) += intel_soc_pmic_bxtwc.o > obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o > obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI)+= intel_soc_pmic_chtdc_ti.o > +obj-$(CONFIG_MFD_MT6360) += mt6360-core.o > obj-$(CONFIG_MFD_MT6397) += mt6397-core.o > > obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o > diff --git a/drivers/mfd/mt6360-core.c b/drivers/mfd/mt6360-core.c > new file mode 100644 > index 000..d3580618 > --- /dev/null > +++ b/drivers/mfd/mt6360-core.c > @@ -0,0 +1,463 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c) 2019 MediaTek Inc. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > + > +/* reg 0 -> 0 ~ 7 */ > +#define MT6360_CHG_TREG_EVT (4) > +#define MT6360_CHG_AICR_EVT (5) > +#define MT6360_CHG_MIVR_EVT (6) > +#define MT6360_PWR_RDY_EVT (7) > +/* REG 1 -> 8 ~ 15 */ > +#define MT6360_CHG_BATSYSUV_EVT (9) > +#define MT6360_FLED_CHG_VINOVP_EVT (11) > +#define MT6360_CHG_VSYSUV_EVT(12) > +#define MT6360_CHG_VSYSOV_EVT(13) > +#define MT6360_CHG_VBATOV_EVT(14) > +#define MT6360_CHG_VBUSOV_EVT(15) > +/* REG 2 -> 16 ~ 23 */ > +/* REG 3 -> 24 ~ 31 */ > +#define MT6360_WD_PMU_DET(25) > +#define MT6360_WD_PMU_DONE (26) > +#define MT6360_CHG_TMRI (27) > +#define MT6360_CHG_ADPBADI (29) > +#define MT6360_CHG_RVPI (30) > +#define MT6360_OTPI (31) > +/* REG 4 -> 32 ~ 39 */ > +#define MT6360_CHG_AICCMEASL (32) > +#define MT6360_CHGDET_DONEI (34) > +#define MT6360_WDTMRI(35) > +#define MT6360_SSFINISHI (36) > +#define MT6360_CHG_RECHGI(37) > +#define MT6360_CHG_TERMI (38) > +#define MT6360_CHG_IEOCI (39) > +/* REG 5 -> 40 ~ 47 */ > +#define MT6360_PUMPX_DONEI (40) > +#define MT6360_BAT_OVP_ADC_EVT (41) > +#define MT6360_TYPEC_OTP_EVT (42) > +#define MT6360_ADC_WAKEUP_EVT(43) > +#define MT6360_ADC_DONEI (44) > +#define MT6360_BST_BATUVI(45) > +#define MT6360_BST_VBUSOVI (46) > +#define MT6360_BST_OLPI (47) > +/* REG 6 -> 48 ~ 55 */ > +#define MT6360_ATTACH_I (48) > +#define MT6360_DETACH_I (49) > +#define MT6360_QC30_STPDONE (51) > +#define MT6360_QC_VBUSDET_DONE (52) > +#define MT6360_HVDCP_DET (53) > +#define MT6360_CHGDETI (54) > +#define MT6360_DCDTI (55) > +/* REG 7 -> 56 ~ 63 */ > +#define MT6360_FOD_DONE_EVT (56) > +#define MT6360_FOD_OV_EVT(57) > +#define MT6360_CHRDET_UVP_EVT(58) > +#define MT6360_CHRDET_OVP_EVT(59) > +#define MT6360_CHRDET_EXT_EVT(60) > +#define MT6360_FOD_LR_EVT(61) > +#define MT6360_FOD_HR_EVT(62) > +#define MT6360_FOD_DISCHG_FAIL_EVT (63) > +/* REG 8 -> 64 ~ 71 */ > +#define MT6360_USBID_EVT (64) > +#define MT6360_APWDTRST_EVT (65) > +#define MT6360_EN_EVT(66) > +#define MT6360_QONB_
Re: [PATCH] KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl
On 12.09.19 11:00, Thomas Huth wrote: > When the userspace program runs the KVM_S390_INTERRUPT ioctl to inject > an interrupt, we convert them from the legacy struct kvm_s390_interrupt > to the new struct kvm_s390_irq via the s390int_to_s390irq() function. > However, this function does not take care of all types of interrupts > that we can inject into the guest later (see do_inject_vcpu()). Since we > do not clear out the s390irq values before calling s390int_to_s390irq(), > there is a chance that we copy unwanted data from the kernel stack > into the guest memory later if the interrupt data has not been properly > initialized by s390int_to_s390irq(). > > Specifically, the problem exists with the KVM_S390_INT_PFAULT_INIT > interrupt: s390int_to_s390irq() does not handle it, but the function > __deliver_pfault_init() will later copy the uninitialized stack data > from the ext.ext_params2 into the guest memory. > > Fix it by handling that interrupt type in s390int_to_s390irq(), too. > And while we're at it, make sure that s390int_to_s390irq() now > directly returns -EINVAL for unknown interrupt types, so that we > do not run into this problem again in case we add more interrupt > types to do_inject_vcpu() sometime in the future. > > Signed-off-by: Thomas Huth > --- > arch/s390/kvm/interrupt.c | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c > index 3e7efdd9228a..165dea4c7f19 100644 > --- a/arch/s390/kvm/interrupt.c > +++ b/arch/s390/kvm/interrupt.c > @@ -1960,6 +1960,16 @@ int s390int_to_s390irq(struct kvm_s390_interrupt > *s390int, > case KVM_S390_MCHK: > irq->u.mchk.mcic = s390int->parm64; > break; > + case KVM_S390_INT_PFAULT_INIT: > + irq->u.ext.ext_params = s390int->parm; > + irq->u.ext.ext_params2 = s390int->parm64; > + break; > + case KVM_S390_RESTART: > + case KVM_S390_INT_CLOCK_COMP: > + case KVM_S390_INT_CPU_TIMER: > + break; > + default: > + return -EINVAL; > } > return 0; > } > Wouldn't a safe fix be to initialize the struct to zero in the caller? -- Thanks, David / dhildenb
Re: [PATCH 3/4] arm64: Kconfig: Fix VEXPRESS driver dependencies
On Thu, Sep 12, 2019 at 12:19 AM Amit Kucheria wrote: > > Push various VEXPRESS drivers behind ARCH_VEXPRESS dependency so that it > doesn't get enabled by default on other platforms. > > Signed-off-by: Amit Kucheria > --- > drivers/bus/Kconfig | 2 +- > drivers/clk/versatile/Kconfig | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig > index d80e8d70bf10..b2b1beee9953 100644 > --- a/drivers/bus/Kconfig > +++ b/drivers/bus/Kconfig > @@ -166,7 +166,7 @@ config UNIPHIER_SYSTEM_BUS > > config VEXPRESS_CONFIG > bool "Versatile Express configuration bus" > - default y if ARCH_VEXPRESS > + depends on ARCH_VEXPRESS > depends on ARM || ARM64 > depends on OF Removing the 'default y' breaks existing defconfig files, Adding the 'depends on ARCH_VEXPRESS' unnecessarily limits compile-testing. I'd rather extend it to other architectures than limit it to builds that have vexpress enabled. > diff --git a/drivers/clk/versatile/Kconfig b/drivers/clk/versatile/Kconfig > index ac766855ba16..826750292c1e 100644 > --- a/drivers/clk/versatile/Kconfig > +++ b/drivers/clk/versatile/Kconfig > @@ -5,8 +5,8 @@ config ICST > config COMMON_CLK_VERSATILE > bool "Clock driver for ARM Reference designs" > depends on ARCH_INTEGRATOR || ARCH_REALVIEW || \ > - ARCH_VERSATILE || ARCH_VEXPRESS || ARM64 || \ > - COMPILE_TEST > + ARCH_VERSATILE || ARCH_VEXPRESS || COMPILE_TEST > + depends on ARM64 It's definitely wrong to limit this to 64 bit. Arnd
Re: [PATCH 3/3] gpio: syscon: Add support for the Xylon LogiCVC GPIOs
On Tue, Sep 10, 2019 at 4:29 PM Paul Kocialkowski wrote: > The LogiCVC display hardware block comes with GPIO capabilities > that must be exposed separately from the main driver (as GPIOs) for > use with regulators and panels. A syscon is used to share the same > regmap across the two drivers. > > Since the GPIO capabilities are pretty simple, add them to the syscon > GPIO driver. > > Signed-off-by: Paul Kocialkowski I'm fine with this for now, but the gpio-syscon driver is now growing big and when you use it you are getting support for a whole bunch of systems you're not running on included in your binary. We need to think about possibly creating drivers/gpio/syscon and split subdrivers into separate files and config options so that people can slim down to what they actually need. > + *bit = 1 << offset; Please do this: #include *bit = BIT(offset); Yours, Linus Walleij
Re: [PATCH 1/3] gpio: syscon: Add support for a custom get operation
On Tue, Sep 10, 2019 at 4:29 PM Paul Kocialkowski wrote: > Some drivers might need a custom get operation to match custom > behavior implemented in the set operation. > > Add plumbing for supporting that. > > Signed-off-by: Paul Kocialkowski Looks OK but as noted in the other patch: we are accumulating stuff in this driver, possibly this syscon part should just be a library used by individual drivers that can be switched on/off with Kconfig. Yours, Linus Walleij
Re: [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] Re: [PATCH v2 2/3] soc: amazon: al-pos: Introduce Amazon's Annapurna Labs POS driver
On 9/12/2019 11:50 AM, Marc Zyngier wrote: On Thu, 12 Sep 2019 07:50:03 +0100, "Shenhar, Talel" wrote: Hi Marc, On 9/11/2019 5:15 PM, Marc Zyngier wrote: [+James] Hi Talel, On Tue, 10 Sep 2019 20:05:09 +0100, Talel Shenhar wrote: + log1 = readl(pos->mmio_base + AL_POS_ERROR_LOG_1); Do you actually need the implied barriers? I'd expect that relaxed accesses should be enough. You are correct. Barriers are not needed, In v1 this driver indeed used _relaxed versions. Due to request coming from Arnd in v1 patch series I removed it. As this is not data path I had no strong objection for removing it. Independently from whether this has any material impact on performance (this obviously isn't a hot path, unless it can be directly generated by userspace or a guest), I believe it is important to use the right type of accessor, if only because code gets copied around... Others would probably argue that this is the very reason why we should always use the "safe" option... Arnld, would love your inputs before publishing v3 to avoid ping-pong. + if (!FIELD_GET(AL_POS_ERROR_LOG_1_VALID, log1)) + return IRQ_NONE; + + log0 = readl(pos->mmio_base + AL_POS_ERROR_LOG_0); + writel(0, pos->mmio_base + AL_POS_ERROR_LOG_1); + + addr = FIELD_GET(AL_POS_ERROR_LOG_0_ADDR_LOW, log0); + addr |= (FIELD_GET(AL_POS_ERROR_LOG_1_ADDR_HIGH, log1) << 32); + request_id = FIELD_GET(AL_POS_ERROR_LOG_1_REQUEST_ID, log1); + bresp = FIELD_GET(AL_POS_ERROR_LOG_1_BRESP, log1); + + dev_err(&pdev->dev, "addr=0x%llx request_id=0x%x bresp=0x%x\n", + addr, request_id, bresp); What is this information? How do we make use of it? Given that this is asynchronous, how do we correlate it to the offending software? Indeed this information arriving from the HW is asynchronous. There is no direct method to get the offending software. There are all kinds of hacks we do to find the offending software once we find this error. most of the time its a new patch introduced but some of the time is just digging. OK, so that the moment, this is more of a debug tool than anything else, right? Not sure what do you mean by debug tool. this is used to capture iliigle access and allow panic() based on them or simple logging. The whole think looks to me like a poor man's EDAC handling, and I'd expect to be plugged in that subsystem instead. Any reason why this isn't the case? It would certainly make the handling uniform for the user. This logic was not plugged into EDAC as there is no "Correctable" error here. its just error event. Not all errors are EDAC in the sense of Error Detection And *Correction*. There are no correctable errors for this driver. I'd argue the opposite! Because you obviously don't let a read-only register being written to, the error has been corrected, and you signal the correction status. Not the meaning of corrected from my point of view - the system as a whole (sw&hw) are not working state. a driver thinks it configured the system to do A while the system doesn't really do that. and the critical part is that the driver that did operation A doesn't even have a way to know it. So I would not call this corrected. So plugging it under EDAC seems like abusing the EDAC system. Now that I've emphasize the reason for not putting this under EDAC, what do you think? should this "only uncorrectable event" driver should be part of EDAC? My choice would be to plug it into the EDAC subsystem, and report all interrupts as "Corrected" events. Optionally, and only if you are debugging something that requires it, report the error as "Uncorrectable", in which case the EDAC subsystem should trigger a panic. At least you'd get the infrastructure, logging and tooling that the EDAC subsystem offers (parsing the kernel log doesn't really count). I see what you say. However, I don't see too much added value in plugging this to EDAC and feel like it would abuse EDAC framework. James, will love your input from EDAC point of view, does it make sense to plug un-correctable only event to EDAC? Thanks, M.
Re: [PATCH 4/4] arm64: Kconfig: Fix EXYNOS driver dependencies
On Thu, Sep 12, 2019 at 12:19 AM Amit Kucheria wrote: > diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig > index 9b2790d3f18a..bdf164a7a7c5 100644 > --- a/drivers/clk/Kconfig > +++ b/drivers/clk/Kconfig > @@ -194,6 +194,7 @@ config COMMON_CLK_ASPEED > > config COMMON_CLK_S2MPS11 > tristate "Clock driver for S2MPS1X/S5M8767 MFD" > + depends on ARCH_EXYNOS > depends on MFD_SEC_CORE || COMPILE_TEST > ---help--- > This driver supports S2MPS11/S2MPS14/S5M8767 crystal oscillator This breaks compile-testing on non-ARM targets. > diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig > index b57093d7c01f..a4c4f01343fd 100644 > --- a/drivers/regulator/Kconfig > +++ b/drivers/regulator/Kconfig > @@ -797,6 +797,7 @@ config REGULATOR_S2MPA01 > > config REGULATOR_S2MPS11 > tristate "Samsung S2MPS11/13/14/15/S2MPU02 voltage regulator" > + depends on ARCH_EXYNOS > depends on MFD_SEC_CORE > help > This driver supports a Samsung S2MPS11/13/14/15/S2MPU02 voltage Same here. What you could do instead is add depends on ARCH_EXYNOS || COMPILE_TEST to MFD_SEC_CORE, this would then propagate to these two drivers as well. Arnd
Re: [PATCH 2/3] dt-bindings: gpio: Add binding document for xylon logicvc-gpio
On Tue, Sep 10, 2019 at 4:29 PM Paul Kocialkowski wrote: > The Xylon LogiCVC display controller exports some GPIOs, which are > exposed as a dedicated driver. > > This introduces the associated device-tree bindings documentation. > > Signed-off-by: Paul Kocialkowski (...) > +The controller exposes GPIOs from the display and power control registers, > +which are mapped by the driver as follows: > +- GPIO[4:0] (display control) mapped to index 0-4 > +- EN_BLIGHT (power control) mapped to index 5 > +- EN_VDD (power control) mapped to index 6 > +- EN_VEE (power control) mapped to index 7 > +- V_EN (power control) mapped to index 8 This should be reflected in the gpio-line-names in the example and in your device trees. Yours, Linus Walleij
Re: [PATCH v9 0/8] stg mail -e --version=v9 \
On Wed 11-09-19 08:12:03, Alexander Duyck wrote: > On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko wrote: > > > > On Tue 10-09-19 14:23:40, Alexander Duyck wrote: > > [...] > > > We don't put any limitations on the allocator other then that it needs to > > > clean up the metadata on allocation, and that it cannot allocate a page > > > that is in the process of being reported since we pulled it from the > > > free_list. If the page is a "Reported" page then it decrements the > > > reported_pages count for the free_area and makes sure the page doesn't > > > exist in the "Boundary" array pointer value, if it does it moves the > > > "Boundary" since it is pulling the page. > > > > This is still a non-trivial limitation on the page allocation from an > > external code IMHO. I cannot give any explicit reason why an ordering on > > the free list might matter (well except for page shuffling which uses it > > to make physical memory pattern allocation more random) but the > > architecture seems hacky and dubious to be honest. It shoulds like the > > whole interface has been developed around a very particular and single > > purpose optimization. > > How is this any different then the code that moves a page that will > likely be merged to the tail though? I guess you are referring to the page shuffling. If that is the case then this is an integral part of the allocator for a reason and it is very well obvious in the code including the consequences. I do not really like an idea of hiding similar constrains behind a generic looking feature which is completely detached from the allocator and so any future change of the allocator might subtly break it. > In our case the "Reported" page is likely going to be much more > expensive to allocate and use then a standard page because it will be > faulted back in. In such a case wouldn't it make sense for us to want > to keep the pages that don't require faults ahead of those pages in > the free_list so that they are more likely to be allocated? OK, I was suspecting this would pop out. And this is exactly why I didn't like an idea of an external code imposing a non obvious constrains to the allocator. You simply cannot count with any ordering with the page allocator. We used to distinguish cache hot/cold pages in the past and pushed pages to the specific end of the free list but that has been removed. There are other potential changes like that possible. Shuffling is a good recent example. Anyway I am not a maintainer of this code. I would really like to hear opinions from Mel and Vlastimil here (now CCed - the thread starts http://lkml.kernel.org/r/20190907172225.10910.34302.stgit@localhost.localdomain. -- Michal Hocko SUSE Labs
Re: [PATCH 2/4] arm64: Kconfig: Fix BRCMSTB driver dependencies
On Thu, Sep 12, 2019 at 12:19 AM Amit Kucheria wrote: > diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig > index 1851112ccc29..d80e8d70bf10 100644 > --- a/drivers/bus/Kconfig > +++ b/drivers/bus/Kconfig > @@ -22,6 +22,7 @@ config ARM_CCI400_PORT_CTRL > > config BRCMSTB_GISB_ARB > bool "Broadcom STB GISB bus arbiter" > + depends on ARCH_BRCMSTB > depends on ARM || ARM64 || MIPS > default ARCH_BRCMSTB || BMIPS_GENERIC > help This breaks MIPS configurations that need this driver, and it breask compile-testing on non-ARM/MIPS targets. > diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig > index 651b763f80cd..6f0b1ed1a05a 100644 > --- a/drivers/power/reset/Kconfig > +++ b/drivers/power/reset/Kconfig > @@ -59,6 +59,7 @@ config POWER_RESET_BRCMKONA > > config POWER_RESET_BRCMSTB > bool "Broadcom STB reset driver" > + depends on ARCH_BRCMSTB > depends on ARM || ARM64 || MIPS || COMPILE_TEST > depends on MFD_SYSCON > default ARCH_BRCMSTB || BMIPS_GENERIC Same here and below. > diff --git a/drivers/soc/bcm/Kconfig b/drivers/soc/bcm/Kconfig > index 648e32693b7e..5a8ff33241ae 100644 > --- a/drivers/soc/bcm/Kconfig > +++ b/drivers/soc/bcm/Kconfig > @@ -24,6 +24,7 @@ config RASPBERRYPI_POWER > > config SOC_BRCMSTB > bool "Broadcom STB SoC drivers" > + depends on ARCH_BRCMSTB > depends on ARM || ARM64 || BMIPS_GENERIC || COMPILE_TEST > select SOC_BUS > help Arnd
Re: [PATCH] KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl
On 12/09/2019 11.14, David Hildenbrand wrote: > On 12.09.19 11:00, Thomas Huth wrote: >> When the userspace program runs the KVM_S390_INTERRUPT ioctl to inject >> an interrupt, we convert them from the legacy struct kvm_s390_interrupt >> to the new struct kvm_s390_irq via the s390int_to_s390irq() function. >> However, this function does not take care of all types of interrupts >> that we can inject into the guest later (see do_inject_vcpu()). Since we >> do not clear out the s390irq values before calling s390int_to_s390irq(), >> there is a chance that we copy unwanted data from the kernel stack >> into the guest memory later if the interrupt data has not been properly >> initialized by s390int_to_s390irq(). >> >> Specifically, the problem exists with the KVM_S390_INT_PFAULT_INIT >> interrupt: s390int_to_s390irq() does not handle it, but the function >> __deliver_pfault_init() will later copy the uninitialized stack data >> from the ext.ext_params2 into the guest memory. >> >> Fix it by handling that interrupt type in s390int_to_s390irq(), too. >> And while we're at it, make sure that s390int_to_s390irq() now >> directly returns -EINVAL for unknown interrupt types, so that we >> do not run into this problem again in case we add more interrupt >> types to do_inject_vcpu() sometime in the future. >> >> Signed-off-by: Thomas Huth >> --- >> arch/s390/kvm/interrupt.c | 10 ++ >> 1 file changed, 10 insertions(+) >> >> diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c >> index 3e7efdd9228a..165dea4c7f19 100644 >> --- a/arch/s390/kvm/interrupt.c >> +++ b/arch/s390/kvm/interrupt.c >> @@ -1960,6 +1960,16 @@ int s390int_to_s390irq(struct kvm_s390_interrupt >> *s390int, >> case KVM_S390_MCHK: >> irq->u.mchk.mcic = s390int->parm64; >> break; >> +case KVM_S390_INT_PFAULT_INIT: >> +irq->u.ext.ext_params = s390int->parm; >> +irq->u.ext.ext_params2 = s390int->parm64; >> +break; >> +case KVM_S390_RESTART: >> +case KVM_S390_INT_CLOCK_COMP: >> +case KVM_S390_INT_CPU_TIMER: >> +break; >> +default: >> +return -EINVAL; >> } >> return 0; >> } >> > > Wouldn't a safe fix be to initialize the struct to zero in the caller? That's of course possible, too. But that means that we always have to zero out the whole structure, so that's a little bit more of overhead (well, it likely doesn't matter for such a legacy ioctl). But the more important question: Do we then still care of fixing the PFAULT_INIT interrupt here? Since it requires a parameter, the "case KVM_S390_INT_PFAULT_INIT:" part would be required here anyway. Thomas
Re: [PATCH 1/4] arm64: Kconfig: Fix XGENE driver dependencies
On Thu, Sep 12, 2019 at 12:19 AM Amit Kucheria wrote: > > Push various XGENE drivers behind ARCH_XGENE dependency so that it > doesn't get enabled by default on other platforms. > > Signed-off-by: Amit Kucheria > --- > arch/arm64/Kconfig.platforms | 3 +++ > drivers/clk/Kconfig| 2 +- > drivers/gpio/Kconfig | 1 + > drivers/pci/controller/Kconfig | 1 + > drivers/phy/Kconfig| 1 + > drivers/power/reset/Kconfig| 2 +- > 6 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms > index 4778c775de1b..cdf4e452e34c 100644 > --- a/arch/arm64/Kconfig.platforms > +++ b/arch/arm64/Kconfig.platforms > @@ -281,6 +281,9 @@ config ARCH_VULCAN > > config ARCH_XGENE > bool "AppliedMicro X-Gene SOC Family" > + select COMMON_CLK_XGENE > + select PCI_XGENE > + select GPIO_XGENE > help > This enables support for AppliedMicro X-Gene SOC Family I'd rather not 'select' drivers that might be optional, the 'default y' should be sufficient as long as it's in theory possible to have them disabled or as loadable modules. > diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig > index 801fa1cd0321..9b2790d3f18a 100644 > --- a/drivers/clk/Kconfig > +++ b/drivers/clk/Kconfig > @@ -225,7 +225,7 @@ config CLK_QORIQ > > config COMMON_CLK_XGENE > bool "Clock driver for APM XGene SoC" > - default ARCH_XGENE > + depends on ARCH_XGENE > depends on ARM64 || COMPILE_TEST > ---help--- > Sypport for the APM X-Gene SoC reference, PLL, and device clocks. This breaks compile-testing, and existing defconfigs that don't list the driver. Arnd
Re: [PATCH] regulator: max77686: fix obtaining "maxim,ena" GPIO
On Tue, Sep 10, 2019 at 6:00 PM Dmitry Torokhov
wrote:
> This fixes 96392c3d8ca4, as devm_gpiod_get_from_of_node() does
> not do translation "con-id" -> "con-id-gpios" that our bindings expects,
> and therefore it was wrong to change connection ID to be simply
> "maxim,ena" when moving to using devm_gpiod_get_from_of_node().
>
> Fixes: 96392c3d8ca4 ("regulator: max77686: Pass descriptor instead of GPIO
> number")
> Signed-off-by: Dmitry Torokhov
An honest mistake, how typical :/
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
Re: [PATCH v3 2/2] dwc: PCI: intel: Intel PCIe RC controller driver
Quoting Andrew Murray:
Quoting Gustavo Pimentel:
On 9/12/2019 4:25 PM, Andrew Murray wrote:
[...]
+static void intel_pcie_max_link_width_setup(struct intel_pcie_port *lpp)
+{
+ u32 mask, val;
+
+ /* HW auto bandwidth negotiation must be enabled */
+ pcie_rc_cfg_wr_mask(lpp, PCIE_LCTLSTS_HW_AW_DIS, 0, PCIE_LCTLSTS);
+
+ mask = PCIE_DIRECT_LINK_WIDTH_CHANGE | PCIE_TARGET_LINK_WIDTH;
+ val = PCIE_DIRECT_LINK_WIDTH_CHANGE | lpp->lanes;
+ pcie_rc_cfg_wr_mask(lpp, mask, val, PCIE_MULTI_LANE_CTRL);
Is this identical functionality to the writing of PCIE_PORT_LINK_CONTROL
in dw_pcie_setup?
I ask because if the user sets num-lanes in the DT, will it have the
desired effect?
intel_pcie_max_link_width_setup() function will be called by sysfs attribute
pcie_width_store() to change on the fly.
Indeed, but a user may also set num-lanes in the device tree. I'm wondering
if, when set in device-tree, it will have the desired effect. Because I don't
see anything similar to PCIE_LCTLSTS_HW_AW_DIS in dw_pcie_setup which is what
your function does here.
I guess I'm trying to avoid the suitation where num-lanes doesn't have the
desired effect and the only way to set the num-lanes is throught the sysfs
control.
I will check this and get back to you.
intel_pcie_max_link_width_setup() is doing the lane resizing which is
different from the link up/establishment happening during probe. Also
PCIE_LCTLSTS_HW_AW_DIS default value is 0 so not setting during the probe or
dw_pcie_setup.
intel_pcie_max_link_width_setup() is programming as per the designware PCIe
controller databook instructions for lane resizing.
Below lines are from Designware PCIe databook for lane resizing.
Program the TARGET_LINK_WIDTH[5:0] field of the MULTI_LANE_CONTROL_OFF
register.
Program the DIRECT_LINK_WIDTH_CHANGE2 field of the MULTI_LANE_CONTROL_OFF
register.
It is assumed that the PCIE_CAP_HW_AUTO_WIDTH_DISABLE field in the
LINK_CONTROL_LINK_STATUS_REG register is 0.
OK, so there is a difference between initial training and then resizing
of the link. Given that this is not Intel specific, should this function
exist within the designware driver for the benefit of others?
I am ok to add if maintainer agrees with it.
Gustavo Pimentel,
Could you please let us know your opinion on this.
[...]
+}
+
+static void intel_pcie_port_logic_setup(struct intel_pcie_port *lpp)
+{
+ u32 val, mask, fts;
+
+ switch (lpp->max_speed) {
+ case PCIE_LINK_SPEED_GEN1:
+ case PCIE_LINK_SPEED_GEN2:
+ fts = PCIE_AFR_GEN12_FTS_NUM_DFT;
+ break;
[...]
+
+ if (device_property_read_u32(dev, "max-link-speed", &lpp->link_gen))
+ lpp->link_gen = 0; /* Fallback to auto */
Is it possible to use of_pci_get_max_link_speed here instead?
Thanks for pointing it. of_pci_get_max_link_speed() can be used here. I will
update it in the next patch revision.
I just remember, earlier we were using of_pci_get_max_link_speed() itself.
As per reviewer comments changed to device_property_read_u32() to maintain
symmetry in parsing device tree properties from device node.
Let me know your view.
I couldn't find an earlier version of this series that used
of_pci_get_max_link_speed,
have I missed it somewhere?
It happened in our internal review.
What's your suggestion please, either to go with symmetry in parsing
"device_property_read_u32()" or with pci helper function
"of_pci_get_max_link_speed"?
I'd prefer the helper, the added benefit of this is additional error checking.
It also means users can be confident that max-link-speed will behave in the
same way as other host controllers that use this field.
Ok, i will update it in the next patch version.
Regards,
Dilip
Thanks,
Andrew Murray
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "app");
+ if (!res)
+ return -ENXIO;
+
+ lpp->app_base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(lpp->app_base))
+ return PTR_ERR(lpp->app_base);
+
+ ret = intel_pcie_ep_rst_init(lpp);
+ if (ret)
+ return ret;
Given that this is called from a function '..._get_resources' I don't think
we should be resetting anything here.
Agree. I will move it out of get_resources().
+
+ lpp->phy = devm_phy_get(dev, "pciephy");
+ if (IS_ERR(lpp->phy)) {
+ ret = PTR_ERR(lpp->phy);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "couldn't get pcie-phy: %d\n", ret);
+ return ret;
+ }
+ return 0;
+}
+
+static void intel_pcie_deinit_phy(struct intel_pcie_port *lpp)
+{
+ phy_exit(lpp->phy);
+}
+
+static int intel_pcie_wait_l2(struct intel_pcie_port *lpp)
+{
+ u32 value;
+ int ret;
+
+ if (lpp->max_speed < PCIE_LINK_SPEED_GEN3)
+ return 0;
+
+ /* Send PME_TURN_OFF message */
+ pcie_app_wr_mask(lpp, PCIE_APP_MSG_XMT_PM_TURNOFF,
+
Re: [PATCH] regulator: da9211: fix obtaining "enable" GPIO
On Tue, Sep 10, 2019 at 6:02 PM Dmitry Torokhov
wrote:
> This fixes 11da04af0d3b, as devm_gpiod_get_from_of_node() does
> not do translation "con-id" -> "con-id-gpios" that our bindings expects,
> and therefore it was wrong to change connection ID to be simply "enable"
> when moving to using devm_gpiod_get_from_of_node().
>
> Fixes: 11da04af0d3b ("regulator: da9211: Pass descriptors instead of GPIO
> numbers")
> Signed-off-by: Dmitry Torokhov
Reviewed-by: Linus Walleij
Mark: please tag both of these for stable.
Yours,
Linus Walleij
Re: nvme vs. hibernation ( again )
Am Do., 12. Sept. 2019 um 02:51 Uhr schrieb Ming Lei : > > On Thu, Sep 12, 2019 at 12:27 AM Gabriel C wrote: > > > > Hi Christoph, > > > > I see this was already discussed in 2 threads: > > > > https://lists.infradead.org/pipermail/linux-nvme/2019-April/023234.html > > https://lkml.org/lkml/2019/5/24/668 > > > > but in latest git the issue still exists. > > > > I hit that on each resume on my Acer Nitro 5 (AN515-43-R8BF) Laptop. > > > > . > > Sep 11 16:16:30 nitro5 kernel: Freezing remaining freezable tasks ... > > (elapsed 0.000 seconds) done. > > Sep 11 16:16:30 nitro5 kernel: printk: Suspending console(s) (use > > no_console_suspend to debug) > > Sep 11 16:16:30 nitro5 kernel: WARNING: CPU: 0 PID: 882 at > > kernel/irq/chip.c:210 irq_startup+0xe6/0xf0 > > Sep 11 16:16:30 nitro5 kernel: Modules linked in: af_packet bnep > > amdgpu ath10k_pci ath10k_core ath mac80211 joydev uvcvideo > > videobuf2_vmalloc videobuf2_memops edac_mce_amd videobuf2_v4l2 > > amd_iommu_v2 kvm_amd gpu_sched btusb snd_hda_codec_realtek ttm btrtl > > btbcm btintel hid_multitouch ccp snd_hda_codec_generic nls_utf8 > > bluetooth drm_kms_helper hid_generic videobuf2_common ledtrig_audio > > snd_hda_codec_hdmi nls_cp437 cfg80211 drm kvm snd_hda_intel vfat > > videodev fat agpgart efi_pstore r8169 snd_hda_codec ecdh_generic > > i2c_algo_bit realtek irqbypass pcspkr mc rfkill fb_sys_fops efivars > > syscopyarea snd_hda_core ecc k10temp wmi_bmof sysfillrect tpm_crb > > crc16 libphy i2c_piix4 libarc4 snd_hwdep hwmon sysimgblt tpm_tis > > tpm_tis_core evdev ac tpm battery mac_hid i2c_designware_platform > > pinctrl_amd i2c_designware_core rng_core acer_wireless button > > acpi_cpufreq ppdev sch_fq_codel fuse snd_pcm_oss snd_mixer_oss snd_pcm > > snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device > > snd_timer snd soundcore lp parport_pc > > Sep 11 16:16:30 nitro5 kernel: parport xfs libcrc32c crc32c_generic > > crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel ahci > > libahci libata xhci_pci xhci_hcd aesni_intel usbcore scsi_mod > > aes_x86_64 crypto_simd cryptd glue_helper serio_raw i2c_hid hid video > > i2c_core wmi dm_mirror dm_region_hash dm_log dm_mod unix sha1_ssse3 > > sha1_generic hmac ipv6 nf_defrag_ipv6 autofs4 > > Sep 11 16:16:30 nitro5 kernel: CPU: 0 PID: 882 Comm: kworker/u32:9 Not > > tainted 5.3.0-rc8-7-g3120b9a6a3f7-dirty #2 > > Sep 11 16:16:30 nitro5 kernel: Hardware name: Acer Nitro > > AN515-43/Octavia_PKS, BIOS V1.05 08/07/2019 > > Sep 11 16:16:30 nitro5 kernel: Workqueue: events_unbound async_run_entry_fn > > Sep 11 16:16:30 nitro5 kernel: RIP: 0010:irq_startup+0xe6/0xf0 > > Sep 11 16:16:30 nitro5 kernel: Code: e8 7f 3c 00 00 85 c0 0f 85 e3 09 > > 00 00 4c 89 e7 31 d2 4c 89 ee e8 1a cf ff ff 48 89 ef e8 b2 fe ff ff > > 41 89 c4 e9 51 ff ff ff <0f> 0b eb b2 66 0f 1f 44 00 00 0f 1f 44 00 00 > > 55 48 89 fd 53 48 8b > > Sep 11 16:16:30 nitro5 kernel: RSP: 0018:be9b00793c38 EFLAGS: 00010002 > > Sep 11 16:16:30 nitro5 kernel: RAX: 0010 RBX: > > 0001 RCX: 0040 > > Sep 11 16:16:30 nitro5 kernel: RDX: RSI: > > 9d1b8800 RDI: 9c9d9e136598 > > Sep 11 16:16:30 nitro5 kernel: RBP: 9c9d981e5400 R08: > > R09: 9c9d9e8003f0 > > Sep 11 16:16:30 nitro5 kernel: R10: R11: > > 9d057688 R12: 0001 > > Sep 11 16:16:30 nitro5 kernel: R13: 9c9d9e136598 R14: > > R15: 9c9d9e346000 > > Sep 11 16:16:30 nitro5 kernel: FS: () > > GS:9c9da080() knlGS: > > Sep 11 16:16:30 nitro5 kernel: CS: 0010 DS: ES: CR0: > > 80050033 > > Sep 11 16:16:30 nitro5 kernel: CR2: 5633ad8d0060 CR3: > > 0003db8d CR4: 003406f0 > > Sep 11 16:16:30 nitro5 kernel: Call Trace: > > Sep 11 16:16:30 nitro5 kernel: enable_irq+0x48/0x90 > > Sep 11 16:16:30 nitro5 kernel: nvme_poll_irqdisable+0x20c/0x280 > > Sep 11 16:16:30 nitro5 kernel: __nvme_disable_io_queues+0x19d/0x1d0 > > Sep 11 16:16:30 nitro5 kernel: ? nvme_del_queue_end+0x20/0x20 > > Sep 11 16:16:30 nitro5 kernel: nvme_dev_disable+0x15c/0x210 > > Sep 11 16:16:30 nitro5 kernel: nvme_suspend+0x40/0x130 > > Sep 11 16:16:30 nitro5 kernel: pci_pm_suspend+0x72/0x130 > > Sep 11 16:16:30 nitro5 kernel: ? pci_pm_freeze+0xb0/0xb0 > > Sep 11 16:16:30 nitro5 kernel: dpm_run_callback+0x29/0x120 > > Sep 11 16:16:30 nitro5 kernel: __device_suspend+0x1b2/0x400 > > Sep 11 16:16:30 nitro5 kernel: async_suspend+0x1b/0x90 > > Sep 11 16:16:30 nitro5 kernel: async_run_entry_fn+0x37/0xe0 > > Sep 11 16:16:30 nitro5 kernel: process_one_work+0x1d1/0x3a0 > > Sep 11 16:16:30 nitro5 kernel: worker_thread+0x4a/0x3d0 > > Sep 11 16:16:30 nitro5 kernel: kthread+0xf9/0x130 > > Sep 11 16:16:30 nitro5 kernel: ? process_one_work+0x3a0/0x3a0 > > Sep 11 16:16:30 nitro5 kernel: ? kthread_park+0x80/0x80 > > Sep 11 16:16:30 nitro5 kernel: ret_from_fork+0x22/0x40 > > S
Re: [PATCH v9 0/8] stg mail -e --version=v9 \
On Thu 12-09-19 09:47:30, David Hildenbrand wrote:
> On 12.09.19 09:16, Michal Hocko wrote:
> > On Wed 11-09-19 18:09:18, David Hildenbrand wrote:
> >> On 11.09.19 15:51, Michal Hocko wrote:
> >>> On Wed 11-09-19 15:20:02, Michal Hocko wrote:
> >>> [...]
> > 4. Continuously report, not the "one time report everything" approach.
>
> So you mean the allocator reporting this rather than an external code to
> poll right? I do not know, how much this is nice to have than must have?
> >>>
> >>> Another idea that I haven't really thought through so it might turned
> >>> out to be completely bogus but let's try anyway. Your "report everything"
> >>> just made me look and realize that free_pages_prepare already performs
> >>> stuff that actually does something similar yet unrelated.
> >>>
> >>> We do report to special page poisoning, zeroying or
> >>> CONFIG_DEBUG_PAGEALLOC to unmap the address from the kernel address
> >>> space. This sounds like something fitting your model no?
> >>>
> >>
> >> AFAIKS, the poisoning/unmapping is done whenever a page is freed. I
> >> don't quite see yet how that would help to remember if a page was
> >> already reported.
> >
> > Do you still have to differ that state when each page is reported?
>
> Ah, very good point. I can see that the reason for this was not
> discussed in this thread so far. (Alexander, Nitesh, please correct me
> if I am wrong). It's buried in the long history of free page
> hinting/reporting.
It would really be preferable to summarize such a previous discussion
ideally with some references.
> Some early patch sets tried to report during every free synchronously.
> Free a page, report them to the hypervisor. This resulted in some issues
> (especially, locking-related and the virtio + the hypervisor being
> involved, resulting in unpredictable delays, quite some overhead ...).
> It was no good.
>
> One design decision then was to not report single pages, but a bunch of
> pages at once. This made it necessary to "remember" the pages to be
> reported and to temporarily block them from getting allocated while
> reporting.
>
> Nitesh implemented (at least) two "capture PFNs of free pages in an
> array when freeing" approaches. One being synchronous from the freeing
> CPU once the list was full (having similar issues as plain synchronous
> reporting) and one being asynchronous by a separate thread (which solved
> many locking issues).
>
> Turned out the a simple array can quickly lead to us having to drop
> "reports" to the hypervisor because the array is full and the reporting
> thread was not able to keep up. Not good as well. Especially, if some
> process frees a lot of memory this can happen quickly and Nitesh wa
> sable to trigger this scenario frequently.
>
> Finally, Nitesh decided to use the bitmap instead to keep track of pages
> to report. I'd like to note that this approach could still be combined
> with an "array of potentially free PFNs". Only when the array/circular
> buffer runs out of entries ("reporting thread cannot keep up"), we would
> have to go back to scanning the bitmap.
>
> That was also the point where Alexander decided to look into integrating
> tracking/handling reported/unreported pages directly in the buddy.
OK, this gives at least some background which is really appreciated.
Explaining _why_ you need something in the core MM is essential to move
forward.
> >> After reporting the page we would have to switch some
> >> state (Nitesh: bitmap bit, Alexander: page flag) to identify that.
> >
> > Yes, you can either store the state somewhere.
> >
> >> Of course, we could map the page and treat that as "the state" when we
> >> reported it, but I am not sure that's such a good idea :)
> >>
> >> As always, I might be very wrong ...
> >
> > I still do not fully understand the usecase so I might be equally wrong.
> > My thinking is along these lines. Why should you scan free pages when
> > you can effectively capture each freed page? If you go one step further
> > then post_alloc_hook would be the counterpart to know that your page has
> > been allocated.
>
> I'd like to note that Nitesh's patch set contains the following hunk,
> which is roughly what you were thinking :)
>
>
> -static inline void __free_one_page(struct page *page,
> +inline void __free_one_page(struct page *page,
> unsigned long pfn,
> struct zone *zone, unsigned int order,
> - int migratetype)
> + int migratetype, bool hint)
> {
> unsigned long combined_pfn;
> unsigned long uninitialized_var(buddy_pfn);
> @@ -980,7 +981,8 @@ static inline void __free_one_page(struct page *page,
> migratetype);
> else
> add_to_free_area(page, &zone->free_area[order], migratetype);
> -
> + if (hint)
> + page_hinting_enqueue(page, order);
> }
>
>
> (ignore the hint parameter, when he would switch to a isolate vs.
> alloc/free, th
Re: linux-next: Signed-off-by missing for commit in the pinctrl tree
On Wed, Sep 11, 2019 at 11:48 AM Stephen Rothwell wrote:
> cc3abdb73df4 ("pinctrl: iproc: Add 'get_direction' support")
>
> is missing a Signed-off-by from its committer.
Thanks, fixed it up!
Yours,
Linus Walleij
Re: [PATCH] KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl
On 9/12/19 11:20 AM, Thomas Huth wrote: > On 12/09/2019 11.14, David Hildenbrand wrote: >> On 12.09.19 11:00, Thomas Huth wrote: >>> When the userspace program runs the KVM_S390_INTERRUPT ioctl to inject >>> an interrupt, we convert them from the legacy struct kvm_s390_interrupt >>> to the new struct kvm_s390_irq via the s390int_to_s390irq() function. >>> However, this function does not take care of all types of interrupts >>> that we can inject into the guest later (see do_inject_vcpu()). Since we >>> do not clear out the s390irq values before calling s390int_to_s390irq(), >>> there is a chance that we copy unwanted data from the kernel stack >>> into the guest memory later if the interrupt data has not been properly >>> initialized by s390int_to_s390irq(). >>> >>> Specifically, the problem exists with the KVM_S390_INT_PFAULT_INIT >>> interrupt: s390int_to_s390irq() does not handle it, but the function >>> __deliver_pfault_init() will later copy the uninitialized stack data >>> from the ext.ext_params2 into the guest memory. >>> >>> Fix it by handling that interrupt type in s390int_to_s390irq(), too. >>> And while we're at it, make sure that s390int_to_s390irq() now >>> directly returns -EINVAL for unknown interrupt types, so that we >>> do not run into this problem again in case we add more interrupt >>> types to do_inject_vcpu() sometime in the future. >>> >>> Signed-off-by: Thomas Huth >>> --- >>> arch/s390/kvm/interrupt.c | 10 ++ >>> 1 file changed, 10 insertions(+) >>> >>> diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c >>> index 3e7efdd9228a..165dea4c7f19 100644 >>> --- a/arch/s390/kvm/interrupt.c >>> +++ b/arch/s390/kvm/interrupt.c >>> @@ -1960,6 +1960,16 @@ int s390int_to_s390irq(struct kvm_s390_interrupt >>> *s390int, >>> case KVM_S390_MCHK: >>> irq->u.mchk.mcic = s390int->parm64; >>> break; >>> + case KVM_S390_INT_PFAULT_INIT: >>> + irq->u.ext.ext_params = s390int->parm; >>> + irq->u.ext.ext_params2 = s390int->parm64; >>> + break; >>> + case KVM_S390_RESTART: >>> + case KVM_S390_INT_CLOCK_COMP: >>> + case KVM_S390_INT_CPU_TIMER: >>> + break; >>> + default: >>> + return -EINVAL; >>> } >>> return 0; >>> } >>> >> >> Wouldn't a safe fix be to initialize the struct to zero in the caller? > > That's of course possible, too. But that means that we always have to > zero out the whole structure, so that's a little bit more of overhead > (well, it likely doesn't matter for such a legacy ioctl). Or memset it in s390int_to_s390irq so the caller doesn't need to know. That should be fast enough for such a small struct. > > But the more important question: Do we then still care of fixing the > PFAULT_INIT interrupt here? Since it requires a parameter, the "case > KVM_S390_INT_PFAULT_INIT:" part would be required here anyway. Let's wait for Christian's opinion on that. signature.asc Description: OpenPGP digital signature
Re: [PATCH v4 5/9] drm: rcar-du: kms: Initialize CMM instances
Hi Jacopo,
On 06/09/2019 14:54, Jacopo Mondi wrote:
> Implement device tree parsing to collect the available CMM instances
> described by the 'renesas,cmms' property. Associate CMMs with CRTCs and
> store a mask of active CMMs in the DU group for later enablement.
>
> Enforce the probe and suspend/resume ordering of DU and CMM by creating
> a stateless device link between the two.
>
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Jacopo Mondi
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 6 +++
> drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 +
> drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 +
> drivers/gpu/drm/rcar-du/rcar_du_group.h | 2 +
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 68 +
> 5 files changed, 80 insertions(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> index 2da46e3dc4ae..23f1d6cc1719 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -1194,6 +1194,12 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp,
> unsigned int swindex,
> if (ret < 0)
> return ret;
>
> + /* CMM might be disabled for this CRTC. */
> + if (rcdu->cmms[swindex]) {
> + rcrtc->cmm = rcdu->cmms[swindex];
> + rgrp->cmms_mask |= BIT(hwindex % 2);
> + }
> +
Good - this checks out :-D
> drm_crtc_helper_add(crtc, &crtc_helper_funcs);
>
> /* Start with vertical blanking interrupt reporting disabled. */
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> index 3b7fc668996f..5f2940c42225 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> @@ -39,6 +39,7 @@ struct rcar_du_vsp;
> * @vblank_wait: wait queue used to signal vertical blanking
> * @vblank_count: number of vertical blanking interrupts to wait for
> * @group: CRTC group this CRTC belongs to
> + * @cmm: CMM associated with this CRTC
> * @vsp: VSP feeding video to this CRTC
> * @vsp_pipe: index of the VSP pipeline feeding video to this CRTC
> * @writeback: the writeback connector
> @@ -64,6 +65,7 @@ struct rcar_du_crtc {
> unsigned int vblank_count;
>
> struct rcar_du_group *group;
> + struct platform_device *cmm;
> struct rcar_du_vsp *vsp;
> unsigned int vsp_pipe;
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> index a00dccc447aa..6316a1c5236c 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> @@ -13,6 +13,7 @@
> #include
> #include
>
> +#include "rcar_cmm.h"
> #include "rcar_du_crtc.h"
> #include "rcar_du_group.h"
> #include "rcar_du_vsp.h"
> @@ -86,6 +87,7 @@ struct rcar_du_device {
> struct rcar_du_encoder *encoders[RCAR_DU_OUTPUT_MAX];
>
> struct rcar_du_group groups[RCAR_DU_MAX_GROUPS];
> + struct platform_device *cmms[RCAR_DU_MAX_CRTCS];
> struct rcar_du_vsp vsps[RCAR_DU_MAX_VSPS];
>
> struct {
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.h
> b/drivers/gpu/drm/rcar-du/rcar_du_group.h
> index 87950c1f6a52..e9906609c635 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_group.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_group.h
> @@ -22,6 +22,7 @@ struct rcar_du_device;
> * @mmio_offset: registers offset in the device memory map
> * @index: group index
> * @channels_mask: bitmask of populated DU channels in this group
> + * @cmms_mask: bitmask of available CMMs in this group
> * @num_crtcs: number of CRTCs in this group (1 or 2)
> * @use_count: number of users of the group (rcar_du_group_(get|put))
> * @used_crtcs: number of CRTCs currently in use
> @@ -37,6 +38,7 @@ struct rcar_du_group {
> unsigned int index;
>
> unsigned int channels_mask;
> + unsigned int cmms_mask;
> unsigned int num_crtcs;
> unsigned int use_count;
> unsigned int used_crtcs;
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 2dc9caee8767..294630e56992 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -17,7 +17,9 @@
> #include
> #include
>
> +#include
> #include
> +#include
> #include
>
> #include "rcar_du_crtc.h"
> @@ -614,6 +616,67 @@ static int rcar_du_vsps_init(struct rcar_du_device *rcdu)
> return ret;
> }
>
> +static int rcar_du_cmm_init(struct rcar_du_device *rcdu)
> +{
> + const struct device_node *np = rcdu->dev->of_node;
> + unsigned int i;
> + int cells;
> +
> + cells = of_property_count_u32_elems(np, "renesas,cmms");
> + if (cells == -EINVAL)
> + return 0;
> +
> + if (cells > rcdu->num_crtcs) {
> + dev_err(rcdu->dev,
> + "Invalid number of entries in 'renesas,cmms'\n");
> + return -EINVAL;
> + }
> +
> + for (i = 0; i <
Re: [PATCH V2] ovl: Fix dereferencing possible ERR_PTR()
On Thu, Sep 12, 2019 at 8:02 AM Amir Goldstein wrote:
>
> On Thu, Sep 12, 2019 at 8:24 AM Ding Xiang
> wrote:
> >
> > if ovl_encode_real_fh() fails, no memory was allocated
> > and the error in the error-valued pointer should be returned.
> >
> > V1->V2: fix SHA1 length problem
> >
> > Fixes: 9b6faee07470 ("ovl: check ERR_PTR() return value from
> > ovl_encode_fh()")
> > Signed-off-by: Ding Xiang
> > ---
> > fs/overlayfs/export.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/fs/overlayfs/export.c b/fs/overlayfs/export.c
> > index cb8ec1f..50ade19 100644
> > --- a/fs/overlayfs/export.c
> > +++ b/fs/overlayfs/export.c
> > @@ -229,7 +229,7 @@ static int ovl_d_to_fh(struct dentry *dentry, char
> > *buf, int buflen)
> > ovl_dentry_upper(dentry), !enc_lower);
> > err = PTR_ERR(fh);
> > if (IS_ERR(fh))
> > - goto fail;
> > + return err;
> >
>
> Please fix the code in warning message instead of skipping the warning.
Not sure that makes sense. ovl_encode_real_fh() will either return
-EIO in case of an internal error with WARN_ON() or it will return
-ENOMEM on memory allocation failure, which doesn't warrant a debug
message.
Thanks,
Miklos
Re: [PATCH 0/4] Cleanup arm64 driver dependencies
On Thu, Sep 12, 2019 at 12:18 AM Amit Kucheria wrote: > > I was using initcall_debugging on a QCOM platform and ran across a bunch of > driver initcalls that are enabled even if their SoC support is disabled. > > Here are some fixups for a subset of them. The idea seems reasonable, disabling a platform may just turn off all the drivers that are not useful elsewhere, but there are mistakes in a lot of your changes, so I'm certainly not applying these for 5.4. Generally speaking, the way that works best is config SUBSYS_DRIVER_FOO tristate "SUBSYS support for FOO platform" depends on ARCH_FOO || COMPILE_TEST depends on SUBSYS default "m" if ARCH_FOO This means it's enabled as a loadable module by default (use default "y" instead where necessary) as long as the platform is enabled, but an x86 allmodconfig build also includes it because of COMPILE_TEST, while any configuration without ARCH_FOO that is not compile-testing cannot enable it. Arnd
Re: [PATCH 01/11] gpiolib: of: add a fallback for wlf,reset GPIO name
On Wed, Sep 11, 2019 at 8:52 AM Dmitry Torokhov wrote: > The old Arizona binding did not use -gpio or -gpios suffix, so > devm_gpiod_get() does not work for it. As it is the one of a few users > of devm_gpiod_get_from_of_node() API that I want to remove, I'd rather > have a small quirk in the gpiolib OF handler, and switch Arizona > driver to devm_gpiod_get(). > > Signed-off-by: Dmitry Torokhov Patch applied, good to have this in and it is completely in line with my idea to handle all these quirks inside the gpiolib-of. Yours, Linus Walleij
Re: [PATCH v3 4/4] mm, slab_common: Make the loop for initializing KMALLOC_DMA start from 1
On 9/11/19 4:33 PM, Pengfei Li wrote: In the past two days, I am working on what you suggested. Great! So far, I have completed the coding work, but I need some time to make sure there are no bugs and verify the impact on performance. It would probably be hard to measure with sufficient confidence in terms of runtime performance, but you could use e.g. ./scripts/bloat-o-meter to look for unexpected code increase due to compile-time optimizations becoming runtime.
Re: [PATCH 4/4] arm64: Kconfig: Fix EXYNOS driver dependencies
On Thu, Sep 12, 2019 at 03:48:48AM +0530, Amit Kucheria wrote: > Push various EXYNOS drivers behind ARCH_EXYNOS dependency so that it > doesn't get enabled by default on other platforms. > config REGULATOR_S2MPS11 > tristate "Samsung S2MPS11/13/14/15/S2MPU02 voltage regulator" > + depends on ARCH_EXYNOS > depends on MFD_SEC_CORE > help >This driver supports a Samsung S2MPS11/13/14/15/S2MPU02 voltage This doesn't match the changelog at all. This driver is not enabled by default since it's just a normal tristate, they are disabled by default. As far as I can see all this change will do is reduce our build test coverage by adding an artificial dependency without an || COMPILE_TEST. signature.asc Description: PGP signature
Re: [PATCH 02/11] gpiolib: introduce devm_fwnode_gpiod_get_index()
On Wed, Sep 11, 2019 at 6:01 PM Andy Shevchenko wrote: > On Wed, Sep 11, 2019 at 12:52:06AM -0700, Dmitry Torokhov wrote: > > devm_fwnode_get_index_gpiod_from_child() is too long, besides the fwnode > > in question does not have to be a child of device node. Let's rename it > > to devm_fwnode_gpiod_get_index() and keep the old name for compatibility > > for now. > > > > Also let's add a devm_fwnode_gpiod_get() wrapper as majority of the > > callers need a single GPIO. > > > + return devm_fwnode_gpiod_get_index(dev, fwnode, con_id, 0, > > +flags, label); > > At least one parameter can fit previous line, but taking into consideration > that moving second one makes it 81 character long, I would do it completely on > one line. I don't remember Linus' preferences. I don't really have one, I don't mind 80+ chars, I don't mind breaking lines to avoid it. Yours, Linus Walleij
