Re: [PATCH] riscv: move sifive_l2_cache.c to drivers/soc
On Mon, Aug 19, 2019 at 11:56 AM Christoph Hellwig wrote: > > On Mon, Aug 19, 2019 at 08:09:04AM +0200, Borislav Petkov wrote: > > On Sun, Aug 18, 2019 at 10:29:35AM +0200, Christoph Hellwig wrote: > > > The sifive_l2_cache.c is in no way related to RISC-V architecture > > > memory management. It is a little stub driver working around the fact > > > that the EDAC maintainers prefer their drivers to be structured in a > > > certain way > > > > That changed recently so I guess we can do the per-IP block driver after > > all, if people would still prefer it. > > That would seem like the best idea. But I don't really know this code > well enough myself, and I really need to get this code out of the > forced on RISC-V codebase as some SOCs I'm working with simply don't > have the memory for it.. > > So unless someone signs up to do a per-IP block edac drivers instead > very quickly I'd still like to see something like this go into 5.4 > for now. As of now, we can pull this patch into 5.4. Later, I will review if per-IP block edac driver is needed and if so, will take care of implementing it. - Yash
[PATCH v4] arm64: dts: ls1088a: fix gpio node
From: Song Hui
add ls1088a gpio specify compatible.
Signed-off-by: Song Hui
---
Changes in v4:
- update the patch description.
Changes in v3:
- delete the attribute of little-endian.
Changes in v2:
- update the subject.
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index dfbead4..ff669c8 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -269,7 +269,7 @@
};
gpio0: gpio@230 {
- compatible = "fsl,qoriq-gpio";
+ compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
reg = <0x0 0x230 0x0 0x1>;
interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>;
little-endian;
@@ -280,7 +280,7 @@
};
gpio1: gpio@231 {
- compatible = "fsl,qoriq-gpio";
+ compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
reg = <0x0 0x231 0x0 0x1>;
interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>;
little-endian;
@@ -291,7 +291,7 @@
};
gpio2: gpio@232 {
- compatible = "fsl,qoriq-gpio";
+ compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
reg = <0x0 0x232 0x0 0x1>;
interrupts = <0 37 IRQ_TYPE_LEVEL_HIGH>;
little-endian;
@@ -302,7 +302,7 @@
};
gpio3: gpio@233 {
- compatible = "fsl,qoriq-gpio";
+ compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
reg = <0x0 0x233 0x0 0x1>;
interrupts = <0 37 IRQ_TYPE_LEVEL_HIGH>;
little-endian;
--
2.9.5
Re: [PATCH] FS: timerfd: Fix unexpected return value of timerfd_read function.
hi Tglx
Agreed. Please find the dmesg output below. We see the problem on
[1456773.366951].
Let us know if you find anything suspicious.
[0.00] Linux version 4.9.0-8-amd64
(debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian
6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.110-3+deb9u6 (2015-12-19)
[0.00] Command line:
BOOT_IMAGE=/image-20181130.26/boot/vmlinuz-4.9.0-8-amd64
root=/dev/sda8 rw console=tty0 console=ttyS1,9600n8 quiet
net.ifnames=0 biosdevname=0 loop=image-20181130.26/fs.squashfs
loopfstype=squashfs apparmor=1 security=apparmor varlog_size=4096
usbcore.autosuspend=-1 module_blacklist=gpio_ich
[0.00] x86/fpu: Legacy x87 FPU detected.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009abff] usable
[0.00] BIOS-e820: [mem 0x0009ac00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xbedb5fff] usable
[0.00] BIOS-e820: [mem 0xbedb6000-0xbede5fff] reserved
[0.00] BIOS-e820: [mem 0xbede6000-0xbedf5fff] ACPI data
[0.00] BIOS-e820: [mem 0xbedf6000-0xbf4b7fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbf4b8000-0xbf66afff] reserved
[0.00] BIOS-e820: [mem 0xbf66b000-0xbf7f] usable
[0.00] BIOS-e820: [mem 0xe000-0xe3ff] reserved
[0.00] BIOS-e820: [mem 0xfed01000-0xfed03fff] reserved
[0.00] BIOS-e820: [mem 0xfed08000-0xfed08fff] reserved
[0.00] BIOS-e820: [mem 0xfed0c000-0xfed0] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1cfff] reserved
[0.00] BIOS-e820: [mem 0xfef0-0xfeff] reserved
[0.00] BIOS-e820: [mem 0xff80-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00023fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.8 present.
[0.00] DMI: Dell, Inc. S6100/S6100-CPU, BIOS 5.6.5 07/26/2016
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x24 max_arch_pfn = 0x4
[0.00] MTRR default type: write-back
[0.00] MTRR fixed ranges enabled:
[0.00] 0-9 write-back
[0.00] A-B uncachable
[0.00] C-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00] 0 base 0C000 mask FC000 uncachable
[0.00] 1 base 24000 mask FC000 uncachable
[0.00] 2 base 28000 mask F8000 uncachable
[0.00] 3 base 3 mask F uncachable
[0.00] 4 base 4 mask C uncachable
[0.00] 5 base 8 mask 8 uncachable
[0.00] 6 disabled
[0.00] 7 disabled
[0.00] x86/PAT: Configuration [0-7]: WB WT UC- UC WB WT UC- UC
[0.00] e820: last_pfn = 0xbf800 max_arch_pfn = 0x4
[0.00] found SMP MP-table at [mem 0x000fd880-0x000fd88f]
mapped at [96ea400fd880]
[0.00] Base memory trampoline at [96ea40094000] 94000 size 24576
[0.00] BRK [0x10453a000, 0x10453afff] PGTABLE
[0.00] BRK [0x10453b000, 0x10453bfff] PGTABLE
[0.00] BRK [0x10453c000, 0x10453cfff] PGTABLE
[0.00] BRK [0x10453d000, 0x10453dfff] PGTABLE
[0.00] BRK [0x10453e000, 0x10453efff] PGTABLE
[0.00] BRK [0x10453f000, 0x10453] PGTABLE
[0.00] BRK [0x10454, 0x104540fff] PGTABLE
[0.00] BRK [0x104541000, 0x104541fff] PGTABLE
[0.00] BRK [0x104542000, 0x104542fff] PGTABLE
[0.00] RAMDISK: [mem 0x353e8000-0x369ebfff]
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000F0530 24 (v02 ALASKA)
[0.00] ACPI: XSDT 0xBEDF2090 9C (v01 ALASKA A M I
01072009 AMI 00010013)
[0.00] ACPI: FACP 0xBEDF4630 00010C (v05 ALASKA A M I
01072009 AMI 00010013)
[0.00] ACPI: DSDT 0xBEDF21B8 002476 (v02 ALASKA A M I
01072009 INTL 20061109)
[0.00] ACPI: FACS 0xBF4B5F80 40
[0.00] ACPI: FPDT 0xBEDF4740 44 (v01 ALASKA A M I
01072009 AMI 00010013)
[0.00] ACPI: FIDT 0xBEDF4788 9C (v01 ALASKA A M I
01072009 AMI 00010013)
[0.00] ACPI: MCFG 0xBEDF4828 3C (v01 ALASKA A M I
01072009 MSFT 0097)
[0.00] ACPI: WDAT 0xBEDF4868 0001AC (v01 ALASKA A M I
01072009 MSFT 00010013)
[0.00] ACPI: UEFI 0xBEDF4A18 42 (v01
)
[0.00] ACPI: APIC 0xBEDF4A60 78 (v03 INTEL TIANO
0001 MSFT )
[
Re: [PATCH v5 2/3] OPP: Add support for bandwidth OPP tables
On 07-08-19, 15:31, Saravana Kannan wrote:
> Not all devices quantify their performance points in terms of frequency.
> Devices like interconnects quantify their performance points in terms of
> bandwidth. We need a way to represent these bandwidth levels in OPP. So,
> add support for parsing bandwidth OPPs from DT.
>
> Signed-off-by: Saravana Kannan
> ---
> drivers/opp/of.c | 41 -
> drivers/opp/opp.h | 4 +++-
> 2 files changed, 35 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/opp/of.c b/drivers/opp/of.c
> index 1813f5ad5fa2..e1750033fef9 100644
> --- a/drivers/opp/of.c
> +++ b/drivers/opp/of.c
> @@ -523,6 +523,35 @@ void dev_pm_opp_of_remove_table(struct device *dev)
> }
> EXPORT_SYMBOL_GPL(dev_pm_opp_of_remove_table);
>
> +static int _read_opp_key(struct dev_pm_opp *new_opp, struct device_node *np)
> +{
> + int ret;
> + u64 rate;
> + u32 bw;
> +
> + ret = of_property_read_u64(np, "opp-hz", );
> + if (!ret) {
> + /*
> + * Rate is defined as an unsigned long in clk API, and so
> + * casting explicitly to its type. Must be fixed once rate is 64
> + * bit guaranteed in clk API.
> + */
> + new_opp->rate = (unsigned long)rate;
> + return 0;
> + }
> +
Please read opp-level also here and do error handling.
> + ret = of_property_read_u32(np, "opp-peak-kBps", );
> + if (ret)
> + return ret;
> + new_opp->rate = (unsigned long) bw;
> +
> + ret = of_property_read_u32(np, "opp-avg-kBps", );
> + if (!ret)
> + new_opp->avg_bw = (unsigned long) bw;
If none of opp-hz/level/peak-kBps are available, print error message here
itself..
> +
> + return 0;
You are returning 0 on failure as well here.
> +}
> +
> /**
> * _opp_add_static_v2() - Allocate static OPPs (As per 'v2' DT bindings)
> * @opp_table: OPP table
> @@ -560,22 +589,16 @@ static struct dev_pm_opp *_opp_add_static_v2(struct
> opp_table *opp_table,
> if (!new_opp)
> return ERR_PTR(-ENOMEM);
>
> - ret = of_property_read_u64(np, "opp-hz", );
> + ret = _read_opp_key(new_opp, np);
> if (ret < 0) {
> /* "opp-hz" is optional for devices like power domains. */
> if (!opp_table->is_genpd) {
> - dev_err(dev, "%s: opp-hz not found\n", __func__);
> + dev_err(dev, "%s: opp-hz or opp-peak-kBps not found\n",
> + __func__);
> goto free_opp;
> }
>
> rate_not_available = true;
Move all above as well to read_opp_key().
> - } else {
> - /*
> - * Rate is defined as an unsigned long in clk API, and so
> - * casting explicitly to its type. Must be fixed once rate is 64
> - * bit guaranteed in clk API.
> - */
> - new_opp->rate = (unsigned long)rate;
> }
>
> of_property_read_u32(np, "opp-level", _opp->level);
> diff --git a/drivers/opp/opp.h b/drivers/opp/opp.h
> index 01a500e2c40a..6bb238af9cac 100644
> --- a/drivers/opp/opp.h
> +++ b/drivers/opp/opp.h
> @@ -56,7 +56,8 @@ extern struct list_head opp_tables;
> * @turbo: true if turbo (boost) OPP
> * @suspend: true if suspend OPP
> * @pstate: Device's power domain's performance state.
> - * @rate:Frequency in hertz
> + * @rate:Frequency in hertz OR Peak bandwidth in kilobytes per second
> + * @avg_bw: Average bandwidth in kilobytes per second
Please add separate entry for peak_bw here.
I know you reused rate because you don't want to reimplement the helpers we
have. Maybe we can just update them to return peak_bw when opp-hz isn't present.
> * @level: Performance level
> * @supplies:Power supplies voltage/current values
> * @clock_latency_ns: Latency (in nanoseconds) of switching to this OPP's
> @@ -78,6 +79,7 @@ struct dev_pm_opp {
> bool suspend;
> unsigned int pstate;
> unsigned long rate;
> + unsigned long avg_bw;
> unsigned int level;
>
> struct dev_pm_opp_supply *supplies;
> --
> 2.23.0.rc1.153.gdeed80330f-goog
--
viresh
[PATCH 0/3] fix interrupt swamp in NVMe
From: Long Li This patch set tries to fix interrupt swamp in NVMe devices. On large systems with many CPUs, a number of CPUs may share one NVMe hardware queue. It may have this situation where several CPUs are issuing I/Os, and all the I/Os are returned on the CPU where the hardware queue is bound to. This may result in that CPU swamped by interrupts and stay in interrupt mode for extended time while other CPUs continue to issue I/O. This can trigger Watchdog and RCU timeout, and make the system unresponsive. This patch set addresses this by enforcing scheduling and throttling I/O when CPU is starved in this situation. Long Li (3): sched: define a function to report the number of context switches on a CPU sched: export idle_cpu() nvme: complete request in work queue on CPU with flooded interrupts drivers/nvme/host/core.c | 57 +++- drivers/nvme/host/nvme.h | 1 + include/linux/sched.h| 2 ++ kernel/sched/core.c | 7 + 4 files changed, 66 insertions(+), 1 deletion(-) -- 2.17.1
[PATCH 2/3] sched: export idle_cpu()
From: Long Li This function is useful for device drivers to check if this CPU has work to do in process context. Signed-off-by: Long Li --- include/linux/sched.h | 1 + kernel/sched/core.c | 1 + 2 files changed, 2 insertions(+) diff --git a/include/linux/sched.h b/include/linux/sched.h index 575f1ef7b159..a209941c1770 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -1501,6 +1501,7 @@ current_restore_flags(unsigned long orig_flags, unsigned long flags) extern int cpuset_cpumask_can_shrink(const struct cpumask *cur, const struct cpumask *trial); extern int task_can_attach(struct task_struct *p, const struct cpumask *cs_cpus_allowed); extern u64 get_cpu_rq_switches(int cpu); +extern int idle_cpu(int cpu); #ifdef CONFIG_SMP extern void do_set_cpus_allowed(struct task_struct *p, const struct cpumask *new_mask); extern int set_cpus_allowed_ptr(struct task_struct *p, const struct cpumask *new_mask); diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 1a76f0e97c2d..d1cedfb38174 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -4023,6 +4023,7 @@ int idle_cpu(int cpu) return 1; } +EXPORT_SYMBOL_GPL(idle_cpu); /** * available_idle_cpu - is a given CPU idle for enqueuing work. -- 2.17.1
[PATCH 3/3] nvme: complete request in work queue on CPU with flooded interrupts
From: Long Li
When a NVMe hardware queue is mapped to several CPU queues, it is possible
that the CPU this hardware queue is bound to is flooded by returning I/O for
other CPUs.
For example, consider the following scenario:
1. CPU 0, 1, 2 and 3 share the same hardware queue
2. the hardware queue interrupts CPU 0 for I/O response
3. processes from CPU 1, 2 and 3 keep sending I/Os
CPU 0 may be flooded with interrupts from NVMe device that are I/O responses
for CPU 1, 2 and 3. Under heavy I/O load, it is possible that CPU 0 spends
all the time serving NVMe and other system interrupts, but doesn't have a
chance to run in process context.
To fix this, CPU 0 can schedule a work to complete the I/O request when it
detects the scheduler is not making progress. This serves multiple purposes:
1. This CPU has to be scheduled to complete the request. The other CPUs can't
issue more I/Os until some previous I/Os are completed. This helps this CPU
get out of NVMe interrupts.
2. This acts a throttling mechanisum for NVMe devices, in that it can not
starve a CPU while servicing I/Os from other CPUs.
3. This CPU can make progress on RCU and other work items on its queue.
Signed-off-by: Long Li
---
drivers/nvme/host/core.c | 57 +++-
drivers/nvme/host/nvme.h | 1 +
2 files changed, 57 insertions(+), 1 deletion(-)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 6a9dd68c0f4f..576bb6fce293 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#define CREATE_TRACE_POINTS
#include "trace.h"
@@ -97,6 +98,15 @@ static dev_t nvme_chr_devt;
static struct class *nvme_class;
static struct class *nvme_subsys_class;
+/*
+ * The following are for detecting if this CPU is flooded with interrupts.
+ * The timestamp for the last context switch is recorded. If that is at least
+ * MAX_SCHED_TIMEOUT ago, try to recover from interrupt flood
+ */
+static DEFINE_PER_CPU(u64, last_switch);
+static DEFINE_PER_CPU(u64, last_clock);
+#define MAX_SCHED_TIMEOUT 20 // 2 seconds in ns
+
static int nvme_revalidate_disk(struct gendisk *disk);
static void nvme_put_subsystem(struct nvme_subsystem *subsys);
static void nvme_remove_invalid_namespaces(struct nvme_ctrl *ctrl,
@@ -260,9 +270,54 @@ static void nvme_retry_req(struct request *req)
blk_mq_delay_kick_requeue_list(req->q, delay);
}
+static void nvme_complete_rq_work(struct work_struct *work)
+{
+ struct nvme_request *nvme_rq =
+ container_of(work, struct nvme_request, work);
+ struct request *req = blk_mq_rq_from_pdu(nvme_rq);
+
+ nvme_complete_rq(req);
+}
+
+
void nvme_complete_rq(struct request *req)
{
- blk_status_t status = nvme_error_status(req);
+ blk_status_t status;
+ int cpu;
+ u64 switches;
+ struct nvme_request *nvme_rq;
+
+ if (!in_interrupt())
+ goto skip_check;
+
+ nvme_rq = nvme_req(req);
+ cpu = smp_processor_id();
+ if (idle_cpu(cpu))
+ goto skip_check;
+
+ /* Check if this CPU is flooded with interrupts */
+ switches = get_cpu_rq_switches(cpu);
+ if (this_cpu_read(last_switch) == switches) {
+ /*
+* If this CPU hasn't made a context switch in
+* MAX_SCHED_TIMEOUT ns (and it's not idle), schedule a work to
+* complete this I/O. This forces this CPU run non-interrupt
+* code and throttle the other CPU issuing the I/O
+*/
+ if (sched_clock() - this_cpu_read(last_clock)
+ > MAX_SCHED_TIMEOUT) {
+ INIT_WORK(_rq->work, nvme_complete_rq_work);
+ schedule_work_on(cpu, _rq->work);
+ return;
+ }
+
+ } else {
+ this_cpu_write(last_switch, switches);
+ this_cpu_write(last_clock, sched_clock());
+ }
+
+skip_check:
+ status = nvme_error_status(req);
trace_nvme_complete_rq(req);
diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
index 0a4a7f5e0de7..a8876e69e476 100644
--- a/drivers/nvme/host/nvme.h
+++ b/drivers/nvme/host/nvme.h
@@ -113,6 +113,7 @@ struct nvme_request {
u8 flags;
u16 status;
struct nvme_ctrl*ctrl;
+ struct work_struct work;
};
/*
--
2.17.1
[PATCH 1/3] sched: define a function to report the number of context switches on a CPU
From: Long Li
The number of context switches on a CPU is useful to determine how busy this
CPU is on processing IRQs. Export this information so it can be used by device
drivers.
Signed-off-by: Long Li
---
include/linux/sched.h | 1 +
kernel/sched/core.c | 6 ++
2 files changed, 7 insertions(+)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 9b35aff09f70..575f1ef7b159 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1500,6 +1500,7 @@ current_restore_flags(unsigned long orig_flags, unsigned
long flags)
extern int cpuset_cpumask_can_shrink(const struct cpumask *cur, const struct
cpumask *trial);
extern int task_can_attach(struct task_struct *p, const struct cpumask
*cs_cpus_allowed);
+extern u64 get_cpu_rq_switches(int cpu);
#ifdef CONFIG_SMP
extern void do_set_cpus_allowed(struct task_struct *p, const struct cpumask
*new_mask);
extern int set_cpus_allowed_ptr(struct task_struct *p, const struct cpumask
*new_mask);
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 4a8e7207cafa..1a76f0e97c2d 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1143,6 +1143,12 @@ int set_cpus_allowed_ptr(struct task_struct *p, const
struct cpumask *new_mask)
}
EXPORT_SYMBOL_GPL(set_cpus_allowed_ptr);
+u64 get_cpu_rq_switches(int cpu)
+{
+ return cpu_rq(cpu)->nr_switches;
+}
+EXPORT_SYMBOL_GPL(get_cpu_rq_switches);
+
void set_task_cpu(struct task_struct *p, unsigned int new_cpu)
{
#ifdef CONFIG_SCHED_DEBUG
--
2.17.1
[PATCH] ASoC: uniphier: Fix double reset assersion when transitioning to suspend state
When transitioning to supend state, uniphier_aio_dai_suspend() is called
and asserts reset lines and disables clocks.
However, if there are two or more DAIs, uniphier_aio_dai_suspend() are
called multiple times, and double reset assersion will cause.
This patch defines the counter that has the number of DAIs at first, and
whenever uniphier_aio_dai_suspend() are called, it decrements the
counter. And only if the counter is zero, it asserts reset lines and
disables clocks.
In the same way, uniphier_aio_dai_resume() are called, it increments the
counter after deasserting reset lines and enabling clocks.
Fixes: 139a34200233 ("ASoC: uniphier: add support for UniPhier AIO CPU DAI
driver")
Signed-off-by: Kunihiko Hayashi
---
sound/soc/uniphier/aio-cpu.c | 31 +--
sound/soc/uniphier/aio.h | 1 +
2 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/sound/soc/uniphier/aio-cpu.c b/sound/soc/uniphier/aio-cpu.c
index ee90e6c..2ae582a 100644
--- a/sound/soc/uniphier/aio-cpu.c
+++ b/sound/soc/uniphier/aio-cpu.c
@@ -424,8 +424,11 @@ int uniphier_aio_dai_suspend(struct snd_soc_dai *dai)
{
struct uniphier_aio *aio = uniphier_priv(dai);
- reset_control_assert(aio->chip->rst);
- clk_disable_unprepare(aio->chip->clk);
+ aio->chip->num_wup_aios--;
+ if (!aio->chip->num_wup_aios) {
+ reset_control_assert(aio->chip->rst);
+ clk_disable_unprepare(aio->chip->clk);
+ }
return 0;
}
@@ -439,13 +442,15 @@ int uniphier_aio_dai_resume(struct snd_soc_dai *dai)
if (!aio->chip->active)
return 0;
- ret = clk_prepare_enable(aio->chip->clk);
- if (ret)
- return ret;
+ if (!aio->chip->num_wup_aios) {
+ ret = clk_prepare_enable(aio->chip->clk);
+ if (ret)
+ return ret;
- ret = reset_control_deassert(aio->chip->rst);
- if (ret)
- goto err_out_clock;
+ ret = reset_control_deassert(aio->chip->rst);
+ if (ret)
+ goto err_out_clock;
+ }
aio_iecout_set_enable(aio->chip, true);
aio_chip_init(aio->chip);
@@ -458,7 +463,7 @@ int uniphier_aio_dai_resume(struct snd_soc_dai *dai)
ret = aio_init(sub);
if (ret)
- goto err_out_clock;
+ goto err_out_reset;
if (!sub->setting)
continue;
@@ -466,11 +471,16 @@ int uniphier_aio_dai_resume(struct snd_soc_dai *dai)
aio_port_reset(sub);
aio_src_reset(sub);
}
+ aio->chip->num_wup_aios++;
return 0;
+err_out_reset:
+ if (!aio->chip->num_wup_aios)
+ reset_control_assert(aio->chip->rst);
err_out_clock:
- clk_disable_unprepare(aio->chip->clk);
+ if (!aio->chip->num_wup_aios)
+ clk_disable_unprepare(aio->chip->clk);
return ret;
}
@@ -619,6 +629,7 @@ int uniphier_aio_probe(struct platform_device *pdev)
return PTR_ERR(chip->rst);
chip->num_aios = chip->chip_spec->num_dais;
+ chip->num_wup_aios = chip->num_aios;
chip->aios = devm_kcalloc(dev,
chip->num_aios, sizeof(struct uniphier_aio),
GFP_KERNEL);
diff --git a/sound/soc/uniphier/aio.h b/sound/soc/uniphier/aio.h
index ca6ccba..a7ff7e5 100644
--- a/sound/soc/uniphier/aio.h
+++ b/sound/soc/uniphier/aio.h
@@ -285,6 +285,7 @@ struct uniphier_aio_chip {
struct uniphier_aio *aios;
int num_aios;
+ int num_wup_aios;
struct uniphier_aio_pll *plls;
int num_plls;
--
2.7.4
Re: [PATCH 22/22] arm64: dts: qcom: sm8150: Add APSS shared mailbox
Hey Vinod,
There seems to be a mismatch
between the commit description
and the dt node (This is the
aoss qmp node not the APPS
shared node).
On 2019-08-19 23:11, Vinod Koul wrote:
On 14-08-19, 10:17, Stephen Boyd wrote:
Quoting Vinod Koul (2019-08-14 05:50:12)
> @@ -338,6 +339,16 @@
> #interrupt-cells = <2>;
> };
>
> + aoss_qmp: qmp@c30 {
Node name of 'clock-controller', or 'power-controller'?
The orignal entry for sdm845 has no such statement, but yes it doesn
makes sense. I am thinking power-controller.. Bjorn?
aoss_qmp registers both pd and
clock providers.
--
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
[PATCH] omfs: Fix a memory leak bug
In omfs_get_imap(), 'sbi->s_imap' is allocated through kcalloc(). However,
it is not deallocated in the following execution if 'block' is not less
than 'sbi->s_num_blocks', leading to a memory leak bug. To fix this issue,
go to the 'nomem_free' label to free 'sbi->s_imap'.
Signed-off-by: Wenwen Wang
---
fs/omfs/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/omfs/inode.c b/fs/omfs/inode.c
index 08226a8..e4d89a6 100644
--- a/fs/omfs/inode.c
+++ b/fs/omfs/inode.c
@@ -356,7 +356,7 @@ static int omfs_get_imap(struct super_block *sb)
block = clus_to_blk(sbi, sbi->s_bitmap_ino);
if (block >= sbi->s_num_blocks)
- goto nomem;
+ goto nomem_free;
ptr = sbi->s_imap;
for (count = bitmap_size; count > 0; count -= sb->s_blocksize) {
--
2.7.4
Re: [PATCH] ASoC: uniphier: Fix double reset assersion when transitioning to suspend state
Hello, just noticed while reading through my linux-arm-kernel folder: $Subject ~= s/assersion/assertion/ Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH] auxdisplay: ht16k33: Make ht16k33_fb_fix and ht16k33_fb_var constant
On 2019-08-19 09:51, Nishka Dasgupta wrote:
The static structures ht16k33_fb_fix and ht16k33_fb_var, of types
fb_fix_screeninfo and fb_var_screeninfo respectively, are not used
except to be copied into other variables. Hence make both of them
constant to prevent unintended modification.
Issue found with
Coccinelle.
Signed-off-by: Nishka Dasgupta
---
drivers/auxdisplay/ht16k33.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/auxdisplay/ht16k33.c
b/drivers/auxdisplay/ht16k33.c
index 9c0bb771751d..a2fcde582e2a 100644
--- a/drivers/auxdisplay/ht16k33.c
+++ b/drivers/auxdisplay/ht16k33.c
@@ -74,7 +74,7 @@ struct ht16k33_priv {
struct ht16k33_fbdev fbdev;
};
-static struct fb_fix_screeninfo ht16k33_fb_fix = {
+static const struct fb_fix_screeninfo ht16k33_fb_fix = {
.id = DRIVER_NAME,
.type = FB_TYPE_PACKED_PIXELS,
.visual = FB_VISUAL_MONO10,
@@ -85,7 +85,7 @@ static struct fb_fix_screeninfo ht16k33_fb_fix = {
.accel = FB_ACCEL_NONE,
};
-static struct fb_var_screeninfo ht16k33_fb_var = {
+static const struct fb_var_screeninfo ht16k33_fb_var = {
.xres = HT16K33_MATRIX_LED_MAX_ROWS,
.yres = HT16K33_MATRIX_LED_MAX_COLS,
.xres_virtual = HT16K33_MATRIX_LED_MAX_ROWS,
ACK
Robin
Re: [PATCH 22/22] arm64: dts: qcom: sm8150: Add APSS shared mailbox
On 20-08-19, 11:50, Sibi Sankar wrote:
> Hey Vinod,
>
> There seems to be a mismatch
> between the commit description
> and the dt node (This is the
> aoss qmp node not the APPS
> shared node).
Thanks for pointing, I have squashed this and other into single patch
and updated the description
>
>
> On 2019-08-19 23:11, Vinod Koul wrote:
> > On 14-08-19, 10:17, Stephen Boyd wrote:
> > > Quoting Vinod Koul (2019-08-14 05:50:12)
> > > > @@ -338,6 +339,16 @@
> > > > #interrupt-cells = <2>;
> > > > };
> > > >
> > > > + aoss_qmp: qmp@c30 {
> > >
> > > Node name of 'clock-controller', or 'power-controller'?
> >
> > The orignal entry for sdm845 has no such statement, but yes it doesn
> > makes sense. I am thinking power-controller.. Bjorn?
>
> aoss_qmp registers both pd and
> clock providers.
Thats correct, I chatted with Bjorn and he recommended we use power-controller
--
~Vinod
Re: [KVM] 323d73a8ec: kernel_selftests.kvm.vmx_set_nested_state_test.fail
On 20/08/19 02:52, kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 323d73a8ecad22bf3284f2a7cce576ade6af ("KVM: nVMX: Change
> KVM_STATE_NESTED_EVMCS to signal vmcs12 is copied from eVMCS")
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git
> master
>
> in testcase: kernel_selftests
> with following parameters:
>
> group: kselftests-01
>
> test-description: The kernel contains a set of "self tests" under the
> tools/testing/selftests/ directory. These are intended to be small unit tests
> to exercise individual code paths in the kernel.
> test-url: https://www.kernel.org/doc/Documentation/kselftest.txt
>
>
> on test machine: 8 threads Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz with 16G
> memory
>
> caused below changes (please refer to attached dmesg/kmsg for entire
> log/backtrace):
Patches for these are already on the list, but I'll add the Reported-by.
Paolo
>
> If you fix the issue, kindly add following tag
> Reported-by: kernel test robot
>
> # selftests: kvm: vmx_set_nested_state_test
> # Test Assertion Failure
> # lib/kvm_util.c:1277: ret == 0
> # pid=12810 tid=12810 - Invalid argument
> # 1 0x00403624: vcpu_nested_state_set at kvm_util.c:1275
> # 2 0x00401197: test_nested_state at
> vmx_set_nested_state_test.c:32
> # 3 0x00401562: test_vmx_nested_state at
> vmx_set_nested_state_test.c:151
> # 4 0x0040100f: main at vmx_set_nested_state_test.c:283
> # 5 0x7efdc57f409a: ?? ??:0
> # 6 0x00401099: _start at ??:?
> # KVM_SET_NESTED_STATE failed, ret: -1 errno: 22
> not ok 12 selftests: kvm: vmx_set_nested_state_test
>
>
> To reproduce:
>
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> bin/lkp install job.yaml # job file is attached in this email
> bin/lkp run job.yaml
>
>
>
> Thanks,
> Rong Chen
>
Re: [RT PATCH v2] net/xfrm/xfrm_ipcomp: Protect scratch buffer with local_lock
Hi, On 20/08/19 13:35, kbuild test robot wrote: > Hi Juri, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on linus/master] > [cannot apply to v5.3-rc5 next-20190819] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] This seems to be indeed the case, as this patch is for RT v4.19-rt stable tree: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git v4.19-rt I was under the impression that putting "RT" on the subject line (before PATCH) would prevent build bot to pick this up, but maybe something else/different is needed? Thanks, Juri
Re: [RT PATCH v2] net/xfrm/xfrm_ipcomp: Protect scratch buffer with local_lock
On 19/08/19 15:57, Steven Rostedt wrote: > On Mon, 19 Aug 2019 14:27:31 +0200 > Juri Lelli wrote: > > > The following BUG has been reported while running ipsec tests. > > Thanks! > > I'm still in the process of backporting patches to fix some bugs that > showed up with the latest merge of upstream stable. I'll add this to > the queue to add. Great, thank you! Best, Juri
[PATCH v2 2/8] arm64: dts: qcom: pm8150: Add Base DTS file
Add base DTS file for pm8150 along with GPIOs, power-on, rtc and vadc
nodes
Signed-off-by: Vinod Koul
---
arch/arm64/boot/dts/qcom/pm8150.dtsi | 95
1 file changed, 95 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/pm8150.dtsi
diff --git a/arch/arm64/boot/dts/qcom/pm8150.dtsi
b/arch/arm64/boot/dts/qcom/pm8150.dtsi
new file mode 100644
index ..4a678be46d37
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/pm8150.dtsi
@@ -0,0 +1,95 @@
+// SPDX-License-Identifier: BSD-3-Clause
+// Copyright (c) 2017-2019, The Linux Foundation. All rights reserved.
+// Copyright (c) 2019, Linaro Limited
+
+#include
+#include
+#include
+#include
+
+_bus {
+ pm8150_0: pmic@0 {
+ compatible = "qcom,pm8150", "qcom,spmi-pmic";
+ reg = <0x0 SPMI_USID>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pon: power-on@800 {
+ compatible = "qcom,pm8916-pon";
+ reg = <0x0800>;
+ pwrkey {
+ compatible = "qcom,pm8941-pwrkey";
+ interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
+ debounce = <15625>;
+ bias-pull-up;
+ linux,code = ;
+
+ status = "disabled";
+ };
+ };
+
+ pm8150_adc: adc@3100 {
+ compatible = "qcom,spmi-adc5";
+ reg = <0x3100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #io-channel-cells = <1>;
+ interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>;
+
+ status = "disabled";
+
+ ref-gnd@0 {
+ reg = ;
+ qcom,pre-scaling = <1 1>;
+ label = "ref_gnd";
+ };
+
+ vref-1p25@1 {
+ reg = ;
+ qcom,pre-scaling = <1 1>;
+ label = "vref_1p25";
+ };
+
+ die-temp@6 {
+ reg = ;
+ qcom,pre-scaling = <1 1>;
+ label = "die_temp";
+ };
+ };
+
+ rtc@6000 {
+ compatible = "qcom,pm8941-rtc";
+ reg = <0x6000>;
+ reg-names = "rtc", "alarm";
+ interrupts = <0x0 0x61 0x1 IRQ_TYPE_NONE>;
+
+ status = "disabled";
+ };
+
+ pm8150_gpios: gpio@c000 {
+ compatible = "qcom,pm8150-gpio";
+ reg = <0xc000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupts = <0 0xc0 0 IRQ_TYPE_NONE>,
+<0 0xc1 0 IRQ_TYPE_NONE>,
+<0 0xc2 0 IRQ_TYPE_NONE>,
+<0 0xc3 0 IRQ_TYPE_NONE>,
+<0 0xc4 0 IRQ_TYPE_NONE>,
+<0 0xc5 0 IRQ_TYPE_NONE>,
+<0 0xc6 0 IRQ_TYPE_NONE>,
+<0 0xc7 0 IRQ_TYPE_NONE>,
+<0 0xc8 0 IRQ_TYPE_NONE>,
+<0 0xc9 0 IRQ_TYPE_NONE>,
+<0 0xca 0 IRQ_TYPE_NONE>,
+<0 0xcb 0 IRQ_TYPE_NONE>;
+ };
+ };
+
+ pmic@1 {
+ compatible = "qcom,pm8150", "qcom,spmi-pmic";
+ reg = <0x1 SPMI_USID>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+};
--
2.20.1
[PATCH v2 3/8] arm64: dts: qcom: pm8150b: Add Base DTS file
PMIC pm8150b is a slave pmic and this adds base DTS file for pm8150b
with pon, adc, and gpio nodes
Signed-off-by: Vinod Koul
---
arch/arm64/boot/dts/qcom/pm8150b.dtsi | 84 +++
1 file changed, 84 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/pm8150b.dtsi
diff --git a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
new file mode 100644
index ..dfb71fb8c90a
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
@@ -0,0 +1,84 @@
+// SPDX-License-Identifier: BSD-3-Clause
+// Copyright (c) 2017-2019, The Linux Foundation. All rights reserved.
+// Copyright (c) 2019, Linaro Limited
+
+#include
+#include
+#include
+
+_bus {
+ pmic@2 {
+ compatible = "qcom,pm8150b", "qcom,spmi-pmic";
+ reg = <0x2 SPMI_USID>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ power-on@800 {
+ compatible = "qcom,pm8916-pon";
+ reg = <0x0800>;
+
+ status = "disabled";
+ };
+
+ adc@3100 {
+ compatible = "qcom,spmi-adc5";
+ reg = <0x3100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #io-channel-cells = <1>;
+ interrupts = <0x2 0x31 0x0 IRQ_TYPE_EDGE_RISING>;
+
+ status = "disabled";
+
+ ref-gnd@0 {
+ reg = ;
+ qcom,pre-scaling = <1 1>;
+ label = "ref_gnd";
+ };
+
+ vref-1p25@1 {
+ reg = ;
+ qcom,pre-scaling = <1 1>;
+ label = "vref_1p25";
+ };
+
+ die-temp@6 {
+ reg = ;
+ qcom,pre-scaling = <1 1>;
+ label = "die_temp";
+ };
+
+ chg-temp@9 {
+ reg = ;
+ qcom,pre-scaling = <1 1>;
+ label = "chg_temp";
+ };
+ };
+
+ pm8150b_gpios: gpio@c000 {
+ compatible = "qcom,pm8150b-gpio";
+ reg = <0xc000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupts = <0x2 0xc0 0 IRQ_TYPE_NONE>,
+<0x2 0xc1 0 IRQ_TYPE_NONE>,
+<0x2 0xc2 0 IRQ_TYPE_NONE>,
+<0x2 0xc3 0 IRQ_TYPE_NONE>,
+<0x2 0xc4 0 IRQ_TYPE_NONE>,
+<0x2 0xc5 0 IRQ_TYPE_NONE>,
+<0x2 0xc6 0 IRQ_TYPE_NONE>,
+<0x2 0xc7 0 IRQ_TYPE_NONE>,
+<0x2 0xc8 0 IRQ_TYPE_NONE>,
+<0x2 0xc9 0 IRQ_TYPE_NONE>,
+<0x2 0xca 0 IRQ_TYPE_NONE>,
+<0x2 0xcb 0 IRQ_TYPE_NONE>;
+ };
+ };
+
+ pmic@3 {
+ compatible = "qcom,pm8150b", "qcom,spmi-pmic";
+ reg = <0x3 SPMI_USID>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+};
--
2.20.1
[PATCH v2 5/8] arm64: dts: qcom: sm8150-mtp: add base dts file
This add base DTS file for sm8150-mtp and enables boot to console, adds
tlmm reserved range, resin node, volume down key and also includes pmic
file.
Signed-off-by: Vinod Koul
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/sm8150-mtp.dts | 48 +
2 files changed, 49 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sm8150-mtp.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index 0a7e5dfce6f7..1964dacaf19b 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -12,5 +12,6 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r2.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r3.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-db845c.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-mtp.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sm8150-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM)+= qcs404-evb-1000.dtb
dtb-$(CONFIG_ARCH_QCOM)+= qcs404-evb-4000.dtb
diff --git a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
new file mode 100644
index ..80b15f4f07c8
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: BSD-3-Clause
+// Copyright (c) 2017-2019, The Linux Foundation. All rights reserved.
+// Copyright (c) 2019, Linaro Limited
+
+/dts-v1/;
+
+#include "sm8150.dtsi"
+#include "pm8150.dtsi"
+#include "pm8150b.dtsi"
+#include "pm8150l.dtsi"
+
+/ {
+ model = "Qualcomm Technologies, Inc. SM8150 MTP";
+ compatible = "qcom,sm8150-mtp";
+
+ aliases {
+ serial0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+_id_1 {
+ status = "okay";
+};
+
+ {
+ pwrkey {
+ status = "okay";
+ };
+
+ resin {
+ compatible = "qcom,pm8941-resin";
+ interrupts = <0x0 0x8 1 IRQ_TYPE_EDGE_BOTH>;
+ debounce = <15625>;
+ bias-pull-up;
+ linux,code = ;
+ };
+};
+ {
+ gpio-reserved-ranges = <0 4>, <126 4>;
+};
+
+ {
+ status = "okay";
+};
--
2.20.1
[PATCH v2 4/8] arm64: dts: qcom: pm8150l: Add Base DTS file
PMIC pm8150l is a slave pmic and this adds base DTS file for pm8150l
with power-on, adc and gpio nodes
Signed-off-by: Vinod Koul
---
arch/arm64/boot/dts/qcom/pm8150l.dtsi | 78 +++
1 file changed, 78 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/pm8150l.dtsi
diff --git a/arch/arm64/boot/dts/qcom/pm8150l.dtsi
b/arch/arm64/boot/dts/qcom/pm8150l.dtsi
new file mode 100644
index ..5022ac3fd9b7
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/pm8150l.dtsi
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: BSD-3-Clause
+// Copyright (c) 2017-2019, The Linux Foundation. All rights reserved.
+// Copyright (c) 2019, Linaro Limited
+
+#include
+#include
+#include
+
+_bus {
+ pmic@4 {
+ compatible = "qcom,pm8150l", "qcom,spmi-pmic";
+ reg = <0x4 SPMI_USID>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ power-on@800 {
+ compatible = "qcom,pm8916-pon";
+ reg = <0x0800>;
+
+ status = "disabled";
+ };
+
+ adc@3100 {
+ compatible = "qcom,spmi-adc5";
+ reg = <0x3100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #io-channel-cells = <1>;
+ interrupts = <0x4 0x31 0x0 IRQ_TYPE_EDGE_RISING>;
+
+ status = "disabled";
+
+ ref-gnd@0 {
+ reg = ;
+ qcom,pre-scaling = <1 1>;
+ label = "ref_gnd";
+ };
+
+ vref-1p25@1 {
+ reg = ;
+ qcom,pre-scaling = <1 1>;
+ label = "vref_1p25";
+ };
+
+ die-temp@6 {
+ reg = ;
+ qcom,pre-scaling = <1 1>;
+ label = "die_temp";
+ };
+ };
+
+ pm8150l_gpios: gpio@c000 {
+ compatible = "qcom,pm8150l-gpio";
+ reg = <0xc000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupts = <0x4 0xc0 0 IRQ_TYPE_NONE>,
+<0x4 0xc1 0 IRQ_TYPE_NONE>,
+<0x4 0xc2 0 IRQ_TYPE_NONE>,
+<0x4 0xc3 0 IRQ_TYPE_NONE>,
+<0x4 0xc4 0 IRQ_TYPE_NONE>,
+<0x4 0xc5 0 IRQ_TYPE_NONE>,
+<0x4 0xc6 0 IRQ_TYPE_NONE>,
+<0x4 0xc7 0 IRQ_TYPE_NONE>,
+<0x4 0xc8 0 IRQ_TYPE_NONE>,
+<0x4 0xc9 0 IRQ_TYPE_NONE>,
+<0x4 0xca 0 IRQ_TYPE_NONE>,
+<0x4 0xcb 0 IRQ_TYPE_NONE>;
+ };
+ };
+
+ pmic@5 {
+ compatible = "qcom,pm8150l", "qcom,spmi-pmic";
+ reg = <0x5 SPMI_USID>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+};
--
2.20.1
[PATCH v2 0/8] arm64: dts: qcom: sm8150: Add SM8150 DTS
This series adds DTS for SM8150, PMIC PM8150, PM8150B, PM8150L and the MTP for SM8150. Changes in v2: - Squash patches - Fix comments given by Stephen namely, lowercase for hext numbers, making rpmhcc have xo_board as parent, rename pon controller to power-on controller, make pmic nodes as disabled etc. - removed the dependency on clk defines and use raw numbers Vinod Koul (8): arm64: dts: qcom: sm8150: add base dts file arm64: dts: qcom: pm8150: Add Base DTS file arm64: dts: qcom: pm8150b: Add Base DTS file arm64: dts: qcom: pm8150l: Add Base DTS file arm64: dts: qcom: sm8150-mtp: add base dts file arm64: dts: qcom: sm8150-mtp: Add regulators arm64: dts: qcom: sm8150: Add reserved-memory regions arm64: dts: qcom: sm8150: Add apps shared nodes arch/arm64/boot/dts/qcom/Makefile | 1 + arch/arm64/boot/dts/qcom/pm8150.dtsi| 95 + arch/arm64/boot/dts/qcom/pm8150b.dtsi | 84 + arch/arm64/boot/dts/qcom/pm8150l.dtsi | 78 arch/arm64/boot/dts/qcom/sm8150-mtp.dts | 375 +++ arch/arm64/boot/dts/qcom/sm8150.dtsi| 479 6 files changed, 1112 insertions(+) create mode 100644 arch/arm64/boot/dts/qcom/pm8150.dtsi create mode 100644 arch/arm64/boot/dts/qcom/pm8150b.dtsi create mode 100644 arch/arm64/boot/dts/qcom/pm8150l.dtsi create mode 100644 arch/arm64/boot/dts/qcom/sm8150-mtp.dts create mode 100644 arch/arm64/boot/dts/qcom/sm8150.dtsi -- 2.20.1
[PATCH v2 1/8] arm64: dts: qcom: sm8150: add base dts file
This add base DTS file with cpu, psci, firmware, clock, tlmm and
spmi nodes which enables boot to console
Signed-off-by: Vinod Koul
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 305 +++
1 file changed, 305 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sm8150.dtsi
diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
b/arch/arm64/boot/dts/qcom/sm8150.dtsi
new file mode 100644
index ..d9dc95f851b7
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -0,0 +1,305 @@
+// SPDX-License-Identifier: BSD-3-Clause
+// Copyright (c) 2017-2019, The Linux Foundation. All rights reserved.
+// Copyright (c) 2019, Linaro Limited
+
+#include
+#include
+#include
+
+/ {
+ interrupt-parent = <>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ chosen { };
+
+ clocks {
+ xo_board: xo-board {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <3840>;
+ clock-output-names = "xo_board";
+ };
+
+ sleep_clk: sleep-clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32764>;
+ clock-output-names = "sleep_clk";
+ };
+ };
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ CPU0: cpu@0 {
+ device_type = "cpu";
+ compatible = "qcom,kryo485";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ next-level-cache = <_0>;
+ L2_0: l2-cache {
+ compatible = "cache";
+ next-level-cache = <_0>;
+ L3_0: l3-cache {
+ compatible = "cache";
+ };
+ };
+ };
+
+ CPU1: cpu@100 {
+ device_type = "cpu";
+ compatible = "qcom,kryo485";
+ reg = <0x0 0x100>;
+ enable-method = "psci";
+ next-level-cache = <_100>;
+ L2_100: l2-cache {
+ compatible = "cache";
+ next-level-cache = <_0>;
+ };
+
+ };
+
+ CPU2: cpu@200 {
+ device_type = "cpu";
+ compatible = "qcom,kryo485";
+ reg = <0x0 0x200>;
+ enable-method = "psci";
+ next-level-cache = <_200>;
+ L2_200: l2-cache {
+ compatible = "cache";
+ next-level-cache = <_0>;
+ };
+ };
+
+ CPU3: cpu@300 {
+ device_type = "cpu";
+ compatible = "qcom,kryo485";
+ reg = <0x0 0x300>;
+ enable-method = "psci";
+ next-level-cache = <_300>;
+ L2_300: l2-cache {
+ compatible = "cache";
+ next-level-cache = <_0>;
+ };
+ };
+
+ CPU4: cpu@400 {
+ device_type = "cpu";
+ compatible = "qcom,kryo485";
+ reg = <0x0 0x400>;
+ enable-method = "psci";
+ next-level-cache = <_400>;
+ L2_400: l2-cache {
+ compatible = "cache";
+ next-level-cache = <_0>;
+ };
+ };
+
+ CPU5: cpu@500 {
+ device_type = "cpu";
+ compatible = "qcom,kryo485";
+ reg = <0x0 0x500>;
+ enable-method = "psci";
+ next-level-cache = <_500>;
+ L2_500: l2-cache {
+ compatible = "cache";
+ next-level-cache = <_0>;
+ };
+ };
+
+ CPU6: cpu@600 {
+ device_type = "cpu";
+ compatible = "qcom,kryo485";
+ reg = <0x0 0x600>;
+ enable-method = "psci";
+ next-level-cache = <_600>;
+ L2_600: l2-cache {
+ compatible = "cache";
+ next-level-cache = <_0>;
+ };
+ };
+
+ CPU7: cpu@700 {
+
[PATCH v2 8/8] arm64: dts: qcom: sm8150: Add apps shared nodes
Add apss_shared and apps_rsc including the rpmhcc child node, pmu, SMEM
nodes
Co-developed-by: Sibi Sankar
Signed-off-by: Sibi Sankar
Signed-off-by: Vinod Koul
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 63
1 file changed, 63 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index 8bf4b4c17ae0..cf58b367df28 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -142,12 +142,23 @@
};
};
+ tcsr_mutex: hwlock {
+ compatible = "qcom,tcsr-mutex";
+ syscon = <_mutex_regs 0 0x1000>;
+ #hwlock-cells = <1>;
+ };
+
memory@8000 {
device_type = "memory";
/* We expect the bootloader to fill in the size */
reg = <0 0x8000 0 0>;
};
+ pmu {
+ compatible = "arm,armv8-pmuv3";
+ interrupts = ;
+ };
+
psci {
compatible = "arm,psci-1.0";
method = "smc";
@@ -264,6 +275,12 @@
};
};
+ smem {
+ compatible = "qcom,smem";
+ memory-region = <_mem>;
+ hwlocks = <_mutex 3>;
+ };
+
soc: soc@0 {
#address-cells = <1>;
#size-cells = <1>;
@@ -303,6 +320,11 @@
};
};
+ tcsr_mutex_regs: syscon@1f4 {
+ compatible = "syscon";
+ reg = <0x01f4 0x4>;
+ };
+
tlmm: pinctrl@310 {
compatible = "qcom,sm8150-pinctrl";
reg = <0x0310 0x30>,
@@ -318,6 +340,16 @@
#interrupt-cells = <2>;
};
+ aoss_qmp: power-controller@c30 {
+ compatible = "qcom,sm8150-aoss-qmp";
+ reg = <0x0c30 0x10>;
+ interrupts = ;
+ mboxes = <_shared 0>;
+
+ #clock-cells = <0>;
+ #power-domain-cells = <1>;
+ };
+
intc: interrupt-controller@17a0 {
compatible = "arm,gic-v3";
interrupt-controller;
@@ -327,6 +359,12 @@
interrupts = ;
};
+ apss_shared: mailbox@17c0 {
+ compatible = "qcom,sm8150-apss-shared";
+ reg = <0x17c0 0x1000>;
+ #mbox-cells = <1>;
+ };
+
timer@17c2 {
#address-cells = <1>;
#size-cells = <1>;
@@ -386,6 +424,31 @@
};
};
+ apps_rsc: rsc@1820 {
+ label = "apps_rsc";
+ compatible = "qcom,rpmh-rsc";
+ reg = <0x1820 0x1>,
+ <0x1821 0x1>,
+ <0x1822 0x1>;
+ reg-names = "drv-0", "drv-1", "drv-2";
+ interrupts = ,
+,
+;
+ qcom,tcs-offset = <0xd00>;
+ qcom,drv-id = <2>;
+ qcom,tcs-config = ,
+ ,
+ ,
+ ;
+
+ rpmhcc: clock-controller {
+ compatible = "qcom,sm8150-rpmh-clk";
+ #clock-cells = <1>;
+ clock-names = "xo";
+ clocks = <_board>;
+ };
+ };
+
spmi_bus: spmi@c44 {
compatible = "qcom,spmi-pmic-arb";
reg = <0x0c44 0x0001100>,
--
2.20.1
[PATCH v2 7/8] arm64: dts: qcom: sm8150: Add reserved-memory regions
Add the reserved memory regions in SM8150
Signed-off-by: Vinod Koul
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 111 +++
1 file changed, 111 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index d9dc95f851b7..8bf4b4c17ae0 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -153,6 +153,117 @@
method = "smc";
};
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ hyp_mem: memory@8570 {
+ reg = <0x0 0x8570 0x0 0x60>;
+ no-map;
+ };
+
+ xbl_mem: memory@85d0 {
+ reg = <0x0 0x85d0 0x0 0x14>;
+ no-map;
+ };
+
+ aop_mem: memory@85f0 {
+ reg = <0x0 0x85f0 0x0 0x2>;
+ no-map;
+ };
+
+ aop_cmd_db: memory@85f2 {
+ compatible = "qcom,cmd-db";
+ reg = <0x0 0x85f2 0x0 0x2>;
+ no-map;
+ };
+
+ smem_mem: memory@8600 {
+ reg = <0x0 0x8600 0x0 0x20>;
+ no-map;
+ };
+
+ tz_mem: memory@8620 {
+ reg = <0x0 0x8620 0x0 0x390>;
+ no-map;
+ };
+
+ rmtfs_mem: memory@89b0 {
+ compatible = "qcom,rmtfs-mem";
+ reg = <0x0 0x89b0 0x0 0x20>;
+ no-map;
+
+ qcom,client-id = <1>;
+ qcom,vmid = <15>;
+ };
+
+ camera_mem: memory@8b70 {
+ reg = <0x0 0x8b70 0x0 0x50>;
+ no-map;
+ };
+
+ wlan_mem: memory@8bc0 {
+ reg = <0x0 0x8bc0 0x0 0x18>;
+ no-map;
+ };
+
+ npu_mem: memory@8bd8 {
+ reg = <0x0 0x8bd8 0x0 0x8>;
+ no-map;
+ };
+
+ adsp_mem: memory@8be0 {
+ reg = <0x0 0x8be0 0x0 0x1a0>;
+ no-map;
+ };
+
+ mpss_mem: memory@8d80 {
+ reg = <0x0 0x8d80 0x0 0x960>;
+ no-map;
+ };
+
+ venus_mem: memory@96e0 {
+ reg = <0x0 0x96e0 0x0 0x50>;
+ no-map;
+ };
+
+ slpi_mem: memory@9730 {
+ reg = <0x0 0x9730 0x0 0x140>;
+ no-map;
+ };
+
+ ipa_fw_mem: memory@9870 {
+ reg = <0x0 0x9870 0x0 0x1>;
+ no-map;
+ };
+
+ ipa_gsi_mem: memory@9871 {
+ reg = <0x0 0x9871 0x0 0x5000>;
+ no-map;
+ };
+
+ gpu_mem: memory@98715000 {
+ reg = <0x0 0x98715000 0x0 0x2000>;
+ no-map;
+ };
+
+ spss_mem: memory@9880 {
+ reg = <0x0 0x9880 0x0 0x10>;
+ no-map;
+ };
+
+ cdsp_mem: memory@9890 {
+ reg = <0x0 0x9890 0x0 0x140>;
+ no-map;
+ };
+
+ qseecom_mem: memory@9e40 {
+ reg = <0 0x9e40 0 0x140>;
+ no-map;
+ };
+ };
+
soc: soc@0 {
#address-cells = <1>;
#size-cells = <1>;
--
2.20.1
[PATCH v2 6/8] arm64: dts: qcom: sm8150-mtp: Add regulators
Add the regulators found in the mtp platform. This platform consists of
pmic PM8150, PM8150L and PM8009.
Signed-off-by: Vinod Koul
---
arch/arm64/boot/dts/qcom/sm8150-mtp.dts | 327
1 file changed, 327 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
index 80b15f4f07c8..0513b24496f6 100644
--- a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
@@ -4,6 +4,7 @@
/dts-v1/;
+#include
#include "sm8150.dtsi"
#include "pm8150.dtsi"
#include "pm8150b.dtsi"
@@ -20,6 +21,332 @@
chosen {
stdout-path = "serial0:115200n8";
};
+
+ vph_pwr: vph-pwr-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vph_pwr";
+ regulator-min-microvolt = <370>;
+ regulator-max-microvolt = <370>;
+ };
+
+ /*
+* Apparently RPMh does not provide support for PM8150 S4 because it
+* is always-on; model it as a fixed regulator.
+*/
+ vreg_s4a_1p8: pm8150-s4 {
+ compatible = "regulator-fixed";
+ regulator-name = "vreg_s4a_1p8";
+
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+
+ regulator-always-on;
+ regulator-boot-on;
+
+ vin-supply = <_pwr>;
+ };
+};
+
+_rsc {
+ pm8150-rpmh-regulators {
+ compatible = "qcom,pm8150-rpmh-regulators";
+ qcom,pmic-id = "a";
+
+ vdd-s1-supply = <_pwr>;
+ vdd-s2-supply = <_pwr>;
+ vdd-s3-supply = <_pwr>;
+ vdd-s4-supply = <_pwr>;
+ vdd-s5-supply = <_pwr>;
+ vdd-s6-supply = <_pwr>;
+ vdd-s7-supply = <_pwr>;
+ vdd-s8-supply = <_pwr>;
+ vdd-s9-supply = <_pwr>;
+ vdd-s10-supply = <_pwr>;
+
+ vdd-l1-l8-l11-supply = <_s6a_0p9>;
+ vdd-l2-l10-supply = <_bob>;
+ vdd-l3-l4-l5-l18-supply = <_s6a_0p9>;
+ vdd-l6-l9-supply = <_s8c_1p3>;
+ vdd-l7-l12-l14-l15-supply = <_s5a_2p0>;
+ vdd-l13-l16-l17-supply = <_bob>;
+
+ vreg_s5a_2p0: smps5 {
+ regulator-min-microvolt = <1904000>;
+ regulator-max-microvolt = <200>;
+ };
+
+ vreg_s6a_0p9: smps6 {
+ regulator-min-microvolt = <92>;
+ regulator-max-microvolt = <1128000>;
+ };
+
+ vdda_wcss_pll:
+ vreg_l1a_0p75: ldo1 {
+ regulator-min-microvolt = <752000>;
+ regulator-max-microvolt = <752000>;
+ regulator-initial-mode = ;
+ };
+
+ vdd_pdphy:
+ vdda_usb_hs_3p1:
+ vreg_l2a_3p1: ldo2 {
+ regulator-min-microvolt = <3072000>;
+ regulator-max-microvolt = <3072000>;
+ regulator-initial-mode = ;
+ };
+
+ vreg_l3a_0p8: ldo3 {
+ regulator-min-microvolt = <48>;
+ regulator-max-microvolt = <932000>;
+ regulator-initial-mode = ;
+ };
+
+ vdd_usb_hs_core:
+ vdda_csi_0_0p9:
+ vdda_csi_1_0p9:
+ vdda_csi_2_0p9:
+ vdda_csi_3_0p9:
+ vdda_dsi_0_0p9:
+ vdda_dsi_1_0p9:
+ vdda_dsi_0_pll_0p9:
+ vdda_dsi_1_pll_0p9:
+ vdda_pcie_1ln_core:
+ vdda_pcie_2ln_core:
+ vdda_pll_hv_cc_ebi01:
+ vdda_pll_hv_cc_ebi23:
+ vdda_qrefs_0p875_5:
+ vdda_sp_sensor:
+ vdda_ufs_2ln_core_1:
+ vdda_ufs_2ln_core_2:
+ vdda_usb_ss_dp_core_1:
+ vdda_usb_ss_dp_core_2:
+ vdda_qlink_lv:
+ vdda_qlink_lv_ck:
+ vreg_l5a_0p875: ldo5 {
+ regulator-min-microvolt = <88>;
+ regulator-max-microvolt = <88>;
+ regulator-initial-mode = ;
+ };
+
+ vreg_l6a_1p2: ldo6 {
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <120>;
+ regulator-initial-mode = ;
+ };
+
+ vreg_l7a_1p8: ldo7 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-initial-mode = ;
+ };
+
+ vddpx_10:
+ vreg_l9a_1p2: ldo9 {
+ regulator-min-microvolt = <120>;
+
Re: [kbuild-all] [PATCH v3 4/5] arm64: perf: Enable pmu counter direct access for perf event on armv8
On Mon, Aug 19, 2019 at 08:59:33AM +0100, Raphael Gault wrote: > Hi, > > On 8/18/19 1:37 PM, kbuild test robot wrote: > > Hi Raphael, > > > > Thank you for the patch! Yet something to improve: > > > > [auto build test ERROR on linus/master] > > [cannot apply to v5.3-rc4 next-20190816] > > [if your patch is applied to the wrong git tree, please drop us a note to > > help improve the system] > > This patchset was based on linux-next/master and note linus thanks for the input, we will look for how to find better base to test. > > Thanks, > > -- > Raphael Gault > ___ > kbuild-all mailing list > kbuild-...@lists.01.org > https://lists.01.org/mailman/listinfo/kbuild-all
Re: [PATCH V40 00/29] Add kernel lockdown functionality
On Mon, 19 Aug 2019, Matthew Garrett wrote: > After chatting with James in person, I'm resending the full set with the > fixes merged in in order to avoid any bisect issues. There should be no > functional changes other than avoiding build failures with some configs, > and fixing the oops in tracefs. Applied to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-lockdown and next-testing Thanks! -- James Morris
Re: Let's talk about the elephant in the room - the Linux kernel's inability to gracefully handle low memory pressure
Hi, Artem S. Tashkinov wrote: > Once you hit a situation when opening a new tab requires more RAM than > is currently available, the system will stall hard. You will barely be > able to move the mouse pointer. Your disk LED will be flashing > incessantly (I'm not entirely sure why). You will not be able to run new > applications or close currently running ones. > > This little crisis may continue for minutes or even longer. I think > that's not how the system should behave in this situation. I believe > something must be done about that to avoid this stall. Thanks for reviving this discussion. Indeed, this is a real pain point in the Linux experience. For Endless, we sunk some time into this and emerged with psi being the best solution we could find. The way it works on a time basis seems very appropriate when what we're ultimately interested in is maintaining desktop UI interactivity. With psi enabled in the kernel, we add a small userspace daemon to kill a process when psi reports that *all* userspace tasks are being blocked on kernel memory management work for (at least) 1 second in a 10 second period. https://github.com/endlessm/eos-boot-helper/blob/master/psi-monitor/psi-monitor.c To share our results so far, despite this daemon being a quick initial implementation, we find that it is bringing excellent results, no more memory pressure hangs. The system recovers in less than 30 seconds, usually in more like 10-15 seconds. Sadly a process got killed along the way, but that's a lot better than the user having no option other than pulling the plug. The system may not always recover to a totally smooth state, but the responsiveness to mouse movements and clicks is still decent, so at that point the user can close some more windows to restore full UI performance again. There's just one issue we've seen so far: a single report of psi reporting memory pressure on a desktop system with 4GB RAM which is only running the normal desktop components plus a single gmail tab in the web browser. psi occasionally reports high memory pressure, so then psi-monitor steps in and kills the browser tab, which seems erroneous. We haven't had a chance to look at this in detail yet. Here's a log from the kernel OOM killer showing the memory and process state at this point. https://gist.github.com/dsd/b338bab0206dcce78263f6bb87de7d4a > I'm almost sure some sysctl parameters could be changed to avoid this > situation but something tells me this could be done for everyone and > made default because some non tech-savvy users will just give up on > Linux if they ever get in a situation like this and they won't be keen > or even be able to Google for solutions. As you anticipated, myself and others already jumped in with solutions appropriate for tech-savvy users. Getting solutions widely deployed is indeed another important aspect to tackle. If you're curious to see how this can look from a "just works" standpoint, you might be interested in downloading Endless (www.endlessos.com) and running your tests there; we have the above solution running and active out of the box. Bastien Nocera has recently adapted and extended our solution, presumably with an eye towards getting this more widely deployed as a standard part of the Linux desktop. https://gitlab.freedesktop.org/hadess/low-memory-monitor/ And if there is a meaningful way to make the kernel behave better, that would obviously be of huge value too. Thanks Daniel
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
> Am 19.08.2019 um 21:43 schrieb Adam Ford : > >> Thanks to the help from the Pyra community, I was able to get a (binary) >> reference >> implementation using DRM that works on Pyra/OMAP5. At least the gles1test1. > > just a question, > > If DRM is working, does that mean it works without needing the overhead of X? Yes, we have to kill X11 to successfully run the gles1test1. An interesting question will be how to mix both... E.g. have a 3D rendering in a window controlled by some window manager.
[PATCH] x86/PCI: Remove surplus return from a void function
Remove unnecessary empty return statement at the end of a void function in the arch/x86/kernel/quirks.c. Signed-off-by: Krzysztof Wilczynski --- arch/x86/kernel/quirks.c | 4 1 file changed, 4 deletions(-) diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c index 8451f38ad399..1daf8f2aa21f 100644 --- a/arch/x86/kernel/quirks.c +++ b/arch/x86/kernel/quirks.c @@ -90,8 +90,6 @@ static void ich_force_hpet_resume(void) BUG(); else printk(KERN_DEBUG "Force enabled HPET at resume\n"); - - return; } static void ich_force_enable_hpet(struct pci_dev *dev) @@ -448,7 +446,6 @@ static void nvidia_force_enable_hpet(struct pci_dev *dev) dev_printk(KERN_DEBUG, >dev, "Force enabled HPET at 0x%lx\n", force_hpet_address); cached_dev = dev; - return; } /* ISA Bridges */ @@ -513,7 +510,6 @@ static void e6xx_force_enable_hpet(struct pci_dev *dev) force_hpet_resume_type = NONE_FORCE_HPET_RESUME; dev_printk(KERN_DEBUG, >dev, "Force enabled HPET at " "0x%lx\n", force_hpet_address); - return; } DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E6XX_CU, e6xx_force_enable_hpet); -- 2.22.1
Re: Kernel 5.2.8 - au0828 - Tuner Is Busy
While your mention of quirks-table.h certainly had possibilities, I'm
afraid adding the "AU0828_DEVICE(0x05e1, 0x0400, "Hauppauge",
"Woodbury")," entry for my tuner did not make any difference regarding
the "Tuner is busy. Error -19" message.
I don't know if this means anything, but I see
https://patchwork.kernel.org/patch/97726/ from 2010 which contains
changes for the 0x0400 model. I guess it never got pulled in.
Really, it's fine for me just to hang back at v5.1 for a year or two
until ATSC 3.0 USB tuners come out at a reasonable price.
On Mon, Aug 19, 2019 at 4:44 PM shuah wrote:
> You said you make changes to the
>
> "Whenever I update my kernel, I edit the
> ./drivers/media/usb/au0828/au0828-cards.c file adding an entry for my
> 0x400 device.
> I've been doing it for years and it's been working fine... until now..."
>
> Please send me the changes you make to the file. I see the following
> WOODBURY devices. I am assuming you add 0x400 entry.
>
> { USB_DEVICE(0x05e1, 0x0480),
> .driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
> { USB_DEVICE(0x2040, 0x8200),
> .driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
>
>
> There is another table in sound/usb/quirks-table.h for AU0828
> devices. In addition to 812658d88d26, 66354f18fe5f makes change
> to this table to add a flag. I see two entries in that table:
>
> AU0828_DEVICE(0x05e1, 0x0480, "Hauppauge", "Woodbury"),
> AU0828_DEVICE(0x2040, 0x8200, "Hauppauge", "Woodbury"),
>
> Since these drivers are now coupled doing resource sharing,
> could it be that with your change to au02828 device table,
> your changes are bow incomplete.
>
> I don't have a Woodbury device though. This is something to
> try.
>
> Did you consider sending patch to add your device variant,
> so you don't have to keep making this change whenever you
> go to a new kernel?
>
> thanks,
> -- Shuah
Re: [PATCH v2] mm: hwpoison: disable memory error handling on 1GB hugepage
Cc Mel Gorman, Kirill, Dave Hansen, On Tue, 11 Jun 2019 at 07:51, Naoya Horiguchi wrote: > > On Wed, May 29, 2019 at 04:31:01PM -0700, Mike Kravetz wrote: > > On 5/28/19 2:49 AM, Wanpeng Li wrote: > > > Cc Paolo, > > > Hi all, > > > On Wed, 14 Feb 2018 at 06:34, Mike Kravetz > > > wrote: > > >> > > >> On 02/12/2018 06:48 PM, Michael Ellerman wrote: > > >>> Andrew Morton writes: > > >>> > > On Thu, 08 Feb 2018 12:30:45 + Punit Agrawal > > wrote: > > > > >> > > >> So I don't think that the above test result means that errors are > > >> properly > > >> handled, and the proposed patch should help for arm64. > > > > > > Although, the deviation of pud_huge() avoids a kernel crash the code > > > would be easier to maintain and reason about if arm64 helpers are > > > consistent with expectations by core code. > > > > > > I'll look to update the arm64 helpers once this patch gets merged. But > > > it would be helpful if there was a clear expression of semantics for > > > pud_huge() for various cases. Is there any version that can be used as > > > reference? > > > > Is that an ack or tested-by? > > > > Mike keeps plaintively asking the powerpc developers to take a look, > > but they remain steadfastly in hiding. > > >>> > > >>> Cc'ing linuxppc-dev is always a good idea :) > > >>> > > >> > > >> Thanks Michael, > > >> > > >> I was mostly concerned about use cases for soft/hard offline of huge > > >> pages > > >> larger than PMD_SIZE on powerpc. I know that powerpc supports PGD_SIZE > > >> huge pages, and soft/hard offline support was specifically added for > > >> this. > > >> See, 94310cbcaa3c "mm/madvise: enable (soft|hard) offline of HugeTLB > > >> pages > > >> at PGD level" > > >> > > >> This patch will disable that functionality. So, at a minimum this is a > > >> 'heads up'. If there are actual use cases that depend on this, then more > > >> work/discussions will need to happen. From the e-mail thread on PGD_SIZE > > >> support, I can not tell if there is a real use case or this is just a > > >> 'nice to have'. > > > > > > 1GB hugetlbfs pages are used by DPDK and VMs in cloud deployment, we > > > encounter gup_pud_range() panic several times in product environment. > > > Is there any plan to reenable and fix arch codes? > > > > I too am aware of slightly more interest in 1G huge pages. Suspect that as > > Intel MMU capacity increases to handle more TLB entries there will be more > > and more interest. > > > > Personally, I am not looking at this issue. Perhaps Naoya will comment as > > he know most about this code. > > Thanks for forwarding this to me, I'm feeling that memory error handling > on 1GB hugepage is demanded as real use case. > > > > > > In addition, > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kvm/mmu.c#n3213 > > > The memory in guest can be 1GB/2MB/4K, though the host-backed memory > > > are 1GB hugetlbfs pages, after above PUD panic is fixed, > > > try_to_unmap() which is called in MCA recovery path will mark the PUD > > > hwpoison entry. The guest will vmexit and retry endlessly when > > > accessing any memory in the guest which is backed by this 1GB poisoned > > > hugetlbfs page. We have a plan to split this 1GB hugetblfs page by 2MB > > > hugetlbfs pages/4KB pages, maybe file remap to a virtual address range > > > which is 2MB/4KB page granularity, also split the KVM MMU 1GB SPTE > > > into 2MB/4KB and mark the offensive SPTE w/ a hwpoison flag, a sigbus > > > will be delivered to VM at page fault next time for the offensive > > > SPTE. Is this proposal acceptable? > > > > I am not sure of the error handling design, but this does sound reasonable. > > I agree that that's better. > > > That block of code which potentially dissolves a huge page on memory error > > is hard to understand and I'm not sure if that is even the 'normal' > > functionality. Certainly, we would hate to waste/poison an entire 1G page > > for an error on a small subsection. > > Yes, that's not practical, so we need at first establish the code base for > 2GB hugetlb splitting and then extending it to 1GB next. I found it is not easy to split. There is a unique hugetlb page size that is associated with a mounted hugetlbfs filesystem, file remap to 2MB/4KB will break this. How about hard offline 1GB hugetlb page as what has already done in soft offline, replace the corrupted 1GB page by new 1GB page through page migration, the offending/corrupted area in the original 1GB page doesn't need to be copied into the new page, the offending/corrupted area in new page can keep full zero just as it is clear during hugetlb page fault, other sub-pages of the original 1GB page can be freed to buddy system. The sigbus signal is sent to userspace w/ offending/corrupted virtual address, and signal code, userspace should take care this. Regards, Wanpeng Li
Re: [PATCH v2] ALSA: hda/ca0132 - Add new SBZ quirk
On Mon, 19 Aug 2019 22:40:07 +0200, Paweł Rekowski wrote: > > This patch adds a new PCI subsys ID for the SBZ, as found and tested by > me and some reddit users. > > Signed-off-by: Paweł Rekowski Thanks, applied with Cc to stable. Takashi
Re: [PATCH] ecryptfs: fix a memory leak bug
On 2019-08-20 00:16:40, Wenwen Wang wrote:
> In parse_tag_1_packet(), if tag 1 packet contains a key larger than
> ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES, no cleanup is executed, leading to a
> memory leak on the allocated 'auth_tok_list_item'. To fix this issue, go to
> the label 'out_free' to perform the cleanup work.
>
> Signed-off-by: Wenwen Wang
Thanks for the patch!
I added the following tags to the commit message:
Cc: sta...@vger.kernel.org
Fixes: dddfa461fc89 ("[PATCH] eCryptfs: Public key; packet management")
I also added the function name to the commit subject so that it was
unique from your other fix.
I've pushed the fix to the eCryptfs next branch and I'll submit a pull
request for inclusion soon.
Tyler
> ---
> fs/ecryptfs/keystore.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/ecryptfs/keystore.c b/fs/ecryptfs/keystore.c
> index 216fbe6..4dc0963 100644
> --- a/fs/ecryptfs/keystore.c
> +++ b/fs/ecryptfs/keystore.c
> @@ -1304,7 +1304,7 @@ parse_tag_1_packet(struct ecryptfs_crypt_stat
> *crypt_stat,
> printk(KERN_WARNING "Tag 1 packet contains key larger "
> "than ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES\n");
> rc = -EINVAL;
> - goto out;
> + goto out_free;
> }
> memcpy((*new_auth_tok)->session_key.encrypted_key,
> [(*packet_size)], (body_size - (ECRYPTFS_SIG_SIZE + 2)));
> --
> 2.7.4
>
linux-next: Tree for Aug 20
Hi all, Changes since 20190819: The drm-misc tree gained a conflict against the drm-intel tree. The security tree lost its build failure. Non-merge commits (relative to Linus' tree): 6824 7412 files changed, 368368 insertions(+), 221059 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 309 trees (counting Linus' and 77 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (06821504fd47 Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net) Merging fixes/master (609488bc979f Linux 5.3-rc2) Merging kbuild-current/fixes (451577f3e3a9 Merge tag 'kbuild-fixes-v5.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging arc-current/for-curr (e86d94fdda8e ARC: unwind: Mark expected switch fall-throughs) Merging arm-current/fixes (c5d0e49e8d8f ARM: 8867/1: vdso: pass --be8 to linker if necessary) Merging arm-soc-fixes/arm/fixes (305cd70ec311 Merge tag 'amlogic-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic into arm/fixes) Merging arm64-fixes/for-next/fixes (b6143d10d23e arm64: ftrace: Ensure module ftrace trampoline is coherent with I-side) Merging m68k-current/for-linus (f28a1f16135c m68k: Don't select ARCH_HAS_DMA_PREP_COHERENT for nommu or coldfire) Merging powerpc-fixes/fixes (b9ee5e04fd77 powerpc/64e: Drop stale call to smp_processor_id() which hangs SMP startup) Merging s390-fixes/fixes (d45331b00ddb Linux 5.3-rc4) Merging sparc/master (038029c03e21 sparc: remove unneeded uapi/asm/statfs.h) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (e15dbcdeb9f6 Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf) Merging bpf/master (d34b044038bf tools: bpftool: close prog FD before exit on showing a single program) Merging ipsec/master (22d6552f827e xfrm interface: fix management of phydev) Merging netfilter/master (38a429c898dd netfilter: add include guard to nf_conntrack_h323_types.h) Merging ipvs/master (58e8b37069ff Merge branch 'net-phy-dp83867-add-some-fixes') Merging wireless-drivers/master (1f6607250331 iwlwifi: dbg_ini: fix compile time assert build errors) Merging mac80211/master (d8a1de3d5bb8 isdn: hfcsusb: Fix mISDN driver crash caused by transfer buffer on the stack) Merging rdma-fixes/for-rc (2c8ccb37b08f RDMA/siw: Change CQ flags from 64->32 bits) Merging sound-current/for-linus (f9ef724d4896 ALSA: hda - Fixes inverted Conexant GPIO mic mute led) Merging sound-asoc-fixes/for-linus (9dd959fb934e Merge branch 'asoc-5.3' into asoc-linus) Merging regmap-fixes/for-linus (0161b8716465 Merge branch 'regmap-5.3' into regmap-linus) Merging regulator-fixes/for-linus (c8c4e33fb85d Merge branch 'regulator-5.3' into regulator-linus) Merging spi-fixes/for-linus (ec010644e3b7 Merge branch 'spi-5.3' into spi-linus) Merging pci-current/for-linus (7bafda88de20 Documentation PCI: Fix pciebus-howto.rst filename typo) Merging driver-core.current/driver-core-linus (d45331b00ddb Linux 5.3-rc4) Merging tty.current/tty-linus (d45331b00ddb Linux 5.3-rc4) Merging usb.current/usb-linus (d1abaeb3be7b Linux 5.3-rc5) Merging usb-gadget-fixes/fixes (4a56a478a525 usb: gadget: mass_storage: Fix races between fsg_disable and fsg_set_alt) Merging usb-serial-fixes/usb-linus (d1abaeb3be7b Linux 5.3-rc5) Merging
Re: [PATCH] ecryptfs: fix a memory leak bug
On 2019-08-20 00:33:54, Wenwen Wang wrote:
> In ecryptfs_init_messaging(), if the allocation for 'ecryptfs_msg_ctx_arr'
> fails, the previously allocated 'ecryptfs_daemon_hash' is not deallocated,
> leading to a memory leak bug. To fix this issue, free
> 'ecryptfs_daemon_hash' before returning the error.
>
> Signed-off-by: Wenwen Wang
Thanks for the patch!
I added the following tags to the commit message:
Cc: sta...@vger.kernel.org
Fixes: 88b4a07e6610 ("[PATCH] eCryptfs: Public key transport mechanism")
I also added the function name to the commit subject so that it was
unique from your other fix.
I've pushed the fix to the eCryptfs next branch and I'll submit a pull
request for inclusion soon.
Tyler
> ---
> fs/ecryptfs/messaging.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fs/ecryptfs/messaging.c b/fs/ecryptfs/messaging.c
> index d668e60..c05ca39 100644
> --- a/fs/ecryptfs/messaging.c
> +++ b/fs/ecryptfs/messaging.c
> @@ -379,6 +379,7 @@ int __init ecryptfs_init_messaging(void)
> * ecryptfs_message_buf_len),
> GFP_KERNEL);
> if (!ecryptfs_msg_ctx_arr) {
> + kfree(ecryptfs_daemon_hash);
> rc = -ENOMEM;
> goto out;
> }
> --
> 2.7.4
>
Re: [PATCH v3] gpio: pl061: Fix the issue failed to register the ACPI interrtupion
On Mon, Aug 19, 2019 at 5:07 PM Andy Shevchenko wrote: > The proper fix is to revert the culprit since we call > acpi_gpiochip_request_interrupts() for all controllers. > Linus, please re-do the approach with IRQ handling, Exactly what do you refer to when you want me to "re-do the approach for IRQ handling"? Do you mean this driver or are you referring to: commit e0d89728981393b7d694bd3419b7794b9882c92d Author: Thierry Reding Date: Tue Nov 7 19:15:54 2017 +0100 gpio: Implement tighter IRQ chip integration Currently GPIO drivers are required to add the GPIO chip and its corresponding IRQ chip separately, which can result in a lot of boilerplate. Use the newly introduced struct gpio_irq_chip, embedded in struct gpio_chip, that drivers can fill in if they want the GPIO core to automatically register the IRQ chip associated with a GPIO chip. Signed-off-by: Thierry Reding Acked-by: Grygorii Strashko Signed-off-by: Linus Walleij The new API introduced by this patch is what I am trying to switch everything over to, because the forked paths inside of gpiolib is causing me a maintenance headache and also increasing the footprint of the library. > it seems broadly > regress with ACPI enabled platforms. It only becomes a problem if the platform uses ACPI right? But it's a problem if I can't really tell if a driver is using ACPI or not, there is no sign in the pl061 driver that it would be used on ACPI systems until now, so how do I design for it? The problem comes from the problem/mess I am trying to clean up in the first place. So if the new way of registering GPIO irqchips is not working for ACPI, then we have to fix that instead of reverting all attempts to use the new API IMO. Yours, Linus Walleij
Re: [PATCH v4 02/10] clk: sunxi-ng: Mark AR100 clocks as critical
Hi, On Mon, Aug 19, 2019 at 10:23:03PM -0500, Samuel Holland wrote: > On sun8i, sun9i, and sun50i SoCs, system suspend/resume support requires > firmware running on the AR100 coprocessor (the "SCP"). Such firmware can > provide additional features, such as thermal monitoring and poweron/off > support for boards without a PMIC. > > Since the AR100 may be running critical firmware, even if Linux does not > know about it or directly interact with it (all requests may go through > an intermediary interface such as PSCI), Linux must not turn off its > clock. > > At this time, such power management firmware only exists for the A64 and > H5 SoCs. However, it makes sense to take care of all CCU drivers now > for consistency, and to ease the transition in the future once firmware > is ported to the other SoCs. > > Leaving the clock running is safe even if no firmware is present, since > the AR100 stays in reset by default. In most cases, the AR100 clock is > kept enabled by Linux anyway, since it is the parent of all APB0 bus > peripherals. This change only prevents Linux from turning off the AR100 > clock in the rare case that no peripherals are in use. > > Signed-off-by: Samuel Holland So I'm not really sure where you want to go with this. That clock is only useful where you're having a firmware running on the AR100, and that firmware would have a device tree node of its own, where we could list the clocks needed for the firmware to keep running, if it ever runs. If the driver has not been compiled in / loaded, then we don't care either. But more fundamentally, if we're going to use SCPI, then those clocks will not be handled by that driver anyway, but by the firmware, right? So I'm not really sure that we should do it statically this way, and that we should do it at all. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [PATCH v4 03/10] dt-bindings: mailbox: Add a sunxi message box binding
Hi, On Mon, Aug 19, 2019 at 10:23:04PM -0500, Samuel Holland wrote: > This mailbox hardware is present in Allwinner sun8i, sun9i, and sun50i > SoCs. Add a device tree binding for it. > > Reviewed-by: Rob Herring > Signed-off-by: Samuel Holland > --- > .../mailbox/allwinner,sunxi-msgbox.yaml | 79 +++ > 1 file changed, 79 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/mailbox/allwinner,sunxi-msgbox.yaml So we merged a bunch of schemas already, with the convention that the name was the first compatible to use that binding. That would be allwinner,sun6i-a31-msgbox.yaml in that case Thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [v2 PATCH] RISC-V: Optimize tlb flush path.
On Aug 19 2019, "h...@infradead.org" wrote: > This looks a little odd to m and assumes we never pass a size smaller > than PAGE_SIZE. Whule that is probably true, why not something like: > > if (size < PAGE_SIZE && size != -1) ITYM size <= PAGE_SIZE. And since size is unsigned it cannot be == -1 at the same time. > local_flush_tlb_page(start); > else > local_flush_tlb_all(); > > ? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH RESEND] i386/kvm: support guest access CORE cstate
Kindly reminder, :)
On Mon, 15 Jul 2019 at 17:16, Paolo Bonzini wrote:
>
> On 15/07/19 03:28, Wanpeng Li wrote:
> > From: Wanpeng Li
> >
> > Allow guest reads CORE cstate when exposing host CPU power management
> > capabilities
> > to the guest. PKG cstate is restricted to avoid a guest to get the whole
> > package
> > information in multi-tenant scenario.
> >
> > Cc: Eduardo Habkost
> > Cc: Paolo Bonzini
> > Cc: Radim Krčmář
> > Signed-off-by: Wanpeng Li
>
> Hi,
>
> QEMU is in hard freeze now. This will be applied after the release.
>
> Thanks,
>
> Paolo
>
> > ---
> > linux-headers/linux/kvm.h | 4 +++-
> > target/i386/kvm.c | 3 ++-
> > 2 files changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
> > index b53ee59..d648fde 100644
> > --- a/linux-headers/linux/kvm.h
> > +++ b/linux-headers/linux/kvm.h
> > @@ -696,9 +696,11 @@ struct kvm_ioeventfd {
> > #define KVM_X86_DISABLE_EXITS_MWAIT (1 << 0)
> > #define KVM_X86_DISABLE_EXITS_HLT(1 << 1)
> > #define KVM_X86_DISABLE_EXITS_PAUSE (1 << 2)
> > +#define KVM_X86_DISABLE_EXITS_CSTATE (1 << 3)
> > #define KVM_X86_DISABLE_VALID_EXITS (KVM_X86_DISABLE_EXITS_MWAIT
> > | \
> >KVM_X86_DISABLE_EXITS_HLT | \
> > - KVM_X86_DISABLE_EXITS_PAUSE)
> > + KVM_X86_DISABLE_EXITS_PAUSE
> > | \
> > + KVM_X86_DISABLE_EXITS_CSTATE)
> >
> > /* for KVM_ENABLE_CAP */
> > struct kvm_enable_cap {
> > diff --git a/target/i386/kvm.c b/target/i386/kvm.c
> > index 3b29ce5..49a0cc1 100644
> > --- a/target/i386/kvm.c
> > +++ b/target/i386/kvm.c
> > @@ -1645,7 +1645,8 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
> > if (disable_exits) {
> > disable_exits &= (KVM_X86_DISABLE_EXITS_MWAIT |
> >KVM_X86_DISABLE_EXITS_HLT |
> > - KVM_X86_DISABLE_EXITS_PAUSE);
> > + KVM_X86_DISABLE_EXITS_PAUSE |
> > + KVM_X86_DISABLE_EXITS_CSTATE);
> > }
> >
> > ret = kvm_vm_enable_cap(s, KVM_CAP_X86_DISABLE_EXITS, 0,
> >
>
Re: [v2 PATCH] RISC-V: Optimize tlb flush path.
On Tue, Aug 20, 2019 at 09:14:58AM +0200, Andreas Schwab wrote: > On Aug 19 2019, "h...@infradead.org" wrote: > > > This looks a little odd to m and assumes we never pass a size smaller > > than PAGE_SIZE. Whule that is probably true, why not something like: > > > > if (size < PAGE_SIZE && size != -1) > > ITYM size <= PAGE_SIZE. And since size is unsigned it cannot be == -1 > at the same time. Yes, the <= was obvious, that's what you get for hacking up a demo patch on the plan. And true for the -1. That being said I find the -1 convention rather annoying, a ULONG_MAX in the callers would be a lot more obvious.
Re: [PATCH v5 2/6] vfio: Introduce vGPU display irq type
> > > +#define VFIO_IRQ_TYPE_GFX(1) > > > +/* > > > + * vGPU vendor sub-type > > > + * vGPU device display related interrupts e.g. vblank/pageflip */ > > > +#define VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ (1) > > > > If this is a GFX/DISPLAY IRQ, why are we talking about a "vGPU" in the > > description? It's not specific to a vGPU implementation, right? Is this > > related to a physical display or a virtual display? If it's related to the > > GFX > > PLANE ioctls, it should state that. It's not well specified what this > > interrupt > > signals. Is it vblank? Is it pageflip? > > Is it both? Neither? Something else? > > Sorry for the confusion caused here. > > The original idea here was to use VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ to > notify user space with the display refresh event. The display refresh > event is general. When notified, user space can use > VFIO_DEVICE_QUERY_GFX_PLANE and VFIO_DEVICE_GET_GFX_DMABUF to get the > updated framebuffer, instead of polling them all the time. > > In order to give user space more choice to do the optimization, > vfio_irq_info_cap_display_plane_events is proposed to tell user space > the different plane refresh event values. So when notified by > VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ, user space can get the value of the > eventfd counter and understand which plane the event refresh event > comes from and choose to get the framebuffer on that plane instead of > all the planes. > > So, from the VFIO user point of view, there is only the display > refresh event (i.e. no other events like vblank, pageflip ...). For > GTV-g, this display refresh event is implemented by both vblank and > pageflip, which is only the implementation thing and can be > transparent to the user space. Again sorry about the confusion cased > here, I'll correct the comments in the next version. All this should be explained in a comment for the IRQ in the header file. Key point for the API is that (a) this is a "the display should be updated" event and (b) this covers all display updates, i.e. user space can stop the display update timer and fully depend on getting notifications if an update is needed. That GTV-g watches guest pageflips is an implementation detail. Should nvidia support this they will probably do something completely different. As far I know they render the guest display to some framebuffer at something like 10fps, so it would make sense for them to send an event each time they refreshed the framebuffer. Also note the relationships (cur_event_val is for DRM_PLANE_TYPE_CURSOR updates and pri_event_val for DRM_PLANE_TYPE_PRIMARY). cheers, Gerd
Re: [PATCH v8 19/20] pstore: fs superblock limits
On Sun, Aug 18, 2019 at 09:58:16AM -0700, Deepa Dinamani wrote:
> Leaving granularity at 1ns because it is dependent on the specific
> attached backing pstore module. ramoops has microsecond resolution.
>
> Fix the readback of ramoops fractional timestamp microseconds,
> which has incorrectly been reporting the value as nanoseconds since
> 3f8f80f0 ("pstore/ram: Read and write to the 'compressed' flag of pstore").
As such, this should also have:
Fixes: 3f8f80f0cfeb ("pstore/ram: Read and write to the 'compressed' flag of
pstore")
> Signed-off-by: Deepa Dinamani
> Acked-by: Kees Cook
Also: this is going via some other tree, yes? (Or should I pick this up
for the pstore tree?)
Thanks!
-Kees
> Cc: an...@enomsg.org
> Cc: ccr...@android.com
> Cc: keesc...@chromium.org
> Cc: tony.l...@intel.com
> ---
> fs/pstore/ram.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index 2bb3468fc93a..8caff834f002 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -144,6 +144,7 @@ static int ramoops_read_kmsg_hdr(char *buffer, struct
> timespec64 *time,
> if (sscanf(buffer, RAMOOPS_KERNMSG_HDR "%lld.%lu-%c\n%n",
> (time64_t *)>tv_sec, >tv_nsec, _type,
> _length) == 3) {
> + time->tv_nsec *= 1000;
> if (data_type == 'C')
> *compressed = true;
> else
> @@ -151,6 +152,7 @@ static int ramoops_read_kmsg_hdr(char *buffer, struct
> timespec64 *time,
> } else if (sscanf(buffer, RAMOOPS_KERNMSG_HDR "%lld.%lu\n%n",
> (time64_t *)>tv_sec, >tv_nsec,
> _length) == 2) {
> + time->tv_nsec *= 1000;
> *compressed = false;
> } else {
> time->tv_sec = 0;
> --
> 2.17.1
>
--
Kees Cook
[PATCH] powerpc/Makefile: Always pass --synthetic to nm if supported
Back in 2004 we added logic to arch/ppc64/Makefile to pass the --synthetic option to nm, if it was supported by nm. Then in 2005 when arch/ppc64 and arch/ppc were merged, the logic to add --synthetic was moved inside an #ifdef CONFIG_PPC64 block within arch/powerpc/Makefile, and has remained there since. That was fine, though crufty, until recently when a change to init/Kconfig added a config time check that uses $(NM). On powerpc that leads to an infinite loop because Kconfig uses $(NM) to calculate some values, then the powerpc Makefile changes $(NM), which Kconfig notices and restarts. The original commit that added --synthetic simply said: On new toolchains we need to use nm --synthetic or we miss code symbols. And the nm man page says that the --synthetic option causes nm to: Include synthetic symbols in the output. These are special symbols created by the linker for various purposes. So it seems safe to always pass --synthetic if nm supports it, ie. on 32-bit and 64-bit, it just means 32-bit kernels might have more symbols reported (and in practice I see no extra symbols). Making it unconditional avoids the #ifdef CONFIG_PPC64, which in turn avoids the infinite loop. Debugged-by: Peter Collingbourne Signed-off-by: Michael Ellerman --- arch/powerpc/Makefile | 2 -- 1 file changed, 2 deletions(-) See the original discussion here: https://lore.kernel.org/lkml/camn1go6p_vfdrjgzb67zs4kh0wjteqi0cbokmibtokhqogp...@mail.gmail.com/ diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index c345b79414a9..403f7e193833 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -39,13 +39,11 @@ endif uname := $(shell uname -m) KBUILD_DEFCONFIG := $(if $(filter ppc%,$(uname)),$(uname),ppc64)_defconfig -ifdef CONFIG_PPC64 new_nm := $(shell if $(NM) --help 2>&1 | grep -- '--synthetic' > /dev/null; then echo y; else echo n; fi) ifeq ($(new_nm),y) NM := $(NM) --synthetic endif -endif # BITS is used as extension for files which are available in a 32 bit # and a 64 bit version to simplify shared Makefiles. -- 2.21.0
Re: linux-next: build failure after merge of the arm64 tree
Will Deacon writes: > Hi Michael, > > On Fri, Aug 16, 2019 at 02:52:40PM +1000, Michael Ellerman wrote: >> Will Deacon writes: >> > Although Alpha, Itanic and PowerPC all override NM, only PowerPC does it >> > conditionally so I agree with you that passing '--synthetic' >> > unconditionally >> > would resolve the problem and is certainly my preferred approach if mpe is >> > ok with it. >> >> I'd rather we keep passing --synthetic, otherwise there's the potential >> that symbols go missing that were previously visible. > > Yup -- that was my suggestion above. > >> I think we can keep the new_nm check, but drop the dependency on >> CONFIG_PPC64, and that will fix it. Worst case is we start passing >> --synthetic on ppc32, but that's probably not a problem. >> >> This seems to fix it for me, and 32-bit builds fine. > > Brill, thanks for confirming! > >> Do you want me to send a proper patch for this, or do you want to squash >> it into the original series? > > I'd prefer not to rebase the arm64 queue, so if you send this as a proper > patch, please, then I can queue it on top before reverting the hack we > currently have. Cool, just sent a patch. cheers
[PATCHv2 0/4] Layerscape: Remove num-lanes property from PCIe nodes
From: Hou Zhiqiang On FSL Layerscape SoCs, the number of lanes assigned to PCIe controller is not fixed, it is determined by the selected SerDes protocol. The current num-lanes indicates the max lanes PCIe controller can support up to, instead of the lanes assigned to the PCIe controller. This can result in PCIe link training fail after hot-reset. Hou Zhiqiang (4): dt-bindings: PCI: designware: Remove the num-lanes from Required properties PCI: dwc: Return directly when num-lanes is not found ARM: dts: ls1021a: Remove num-lanes property from PCIe nodes arm64: dts: fsl: Remove num-lanes property from PCIe nodes Documentation/devicetree/bindings/pci/designware-pcie.txt | 1 - arch/arm/boot/dts/ls1021a.dtsi| 2 -- arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi| 1 - arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi| 3 --- arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi| 6 -- arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi| 3 --- arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi| 4 drivers/pci/controller/dwc/pcie-designware.c | 6 -- 8 files changed, 4 insertions(+), 22 deletions(-) -- 2.17.1
Re: Enabling UBSAN breaks KCOV in clang (8.0.*) on arm64
On Mon, Aug 19, 2019 at 05:59:48PM +0100, Mark Rutland wrote:
> Hi,
>
> I found that when I enable both KCOV and UBSAN on arm64, clang fails to
> emit any __sanitizer_cov_trace_*() calls in the resulting binary,
> rendering KCOV useless.
>
> For example, when building v5.3-rc3's arch/arm64/kernel/setup.o:
>
> * With defconfig + CONFIG KCOV:
>
> clang -Wp,-MD,arch/arm64/kernel/.setup.o.d -nostdinc -isystem
>
> /mnt/data/opt/toolchain/llvm/8.0.0/clang+llvm-8.0.0-x86_64-linux-sles11.3/lib/clang/8.0.0/include
> -I./arch/arm64/include -I./arch/arm64/include/generated -I./include
> -I./arch/arm64/include/uapi -I./arch/arm64/include/generated/uapi
> -I./include/uapi -I./include/generated/uapi -include
> ./include/linux/kconfig.h -include ./include/linux/compiler_types.h
> -D__KERNEL__ -mlittle-endian -DKASAN_SHADOW_SCALE_SHIFT=3
> -Qunused-arguments -Wall -Wundef -Werror=strict-prototypes
> -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE
> -Werror=implicit-function-declaration -Werror=implicit-int
> -Wno-format-security -std=gnu89 --target=aarch64-linux
>
> --prefix=/mnt/data/opt/toolchain/kernel-org-crosstool/gcc-8.1.0-nolibc/aarch64-linux/bin/
>
> --gcc-toolchain=/mnt/data/opt/toolchain/kernel-org-crosstool/gcc-8.1.0-nolibc/aarch64-linux
> -no-integrated-as -Werror=unknown-warning-option -mgeneral-regs-only
> -DCONFIG_AS_LSE=1 -fno-asynchronous-unwind-tables
> -DKASAN_SHADOW_SCALE_SHIFT=3 -fno-delete-null-pointer-checks
> -Wno-address-of-packed-member -O2 -Wframe-larger-than=2048
> -fstack-protector-strong -Wno-format-invalid-specifier -Wno-gnu
> -Wno-tautological-compare -mno-global-merge -Wno-unused-const-variable
> -fno-omit-frame-pointer -fno-optimize-sibling-calls -g
> -Wdeclaration-after-statement -Wvla -Wno-pointer-sign
> -fno-strict-overflow -fno-merge-all-constants -fno-stack-check
> -Werror=date-time -Werror=incompatible-pointer-types
> -Wno-initializer-overrides -Wno-format -Wno-sign-compare
> -Wno-format-zero-length -fsanitize-coverage=trace-pc
> -DKBUILD_BASENAME='"setup"' -DKBUILD_MODNAME='"setup"' -c -o
> arch/arm64/kernel/setup.o arch/arm64/kernel/setup.c
>
> ... and there are 44 calls to __sanitizer_cov_trace_pc in the
> resulting setup.o
>
> * with defconfig + CONFIG_KCOV + CONFIG_UBSAN:
>
> clang -Wp,-MD,arch/arm64/kernel/.setup.o.d -nostdinc -isystem
>
> /mnt/data/opt/toolchain/llvm/8.0.0/clang+llvm-8.0.0-x86_64-linux-sles11.3/lib/clang/8.0.0/include
> -I./arch/arm64/include -I./arch/arm64/include/generated -I./include
> -I./arch/arm64/include/uapi -I./arch/arm64/include/generated/uapi
> -I./include/uapi -I./include/generated/uapi -include
> ./include/linux/kconfig.h -include ./include/linux/compiler_types.h
> -D__KERNEL__ -mlittle-endian -DKASAN_SHADOW_SCALE_SHIFT=3
> -Qunused-arguments -Wall -Wundef -Werror=strict-prototypes
> -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE
> -Werror=implicit-function-declaration -Werror=implicit-int
> -Wno-format-security -std=gnu89 --target=aarch64-linux
>
> --prefix=/mnt/data/opt/toolchain/kernel-org-crosstool/gcc-8.1.0-nolibc/aarch64-linux/bin/
>
> --gcc-toolchain=/mnt/data/opt/toolchain/kernel-org-crosstool/gcc-8.1.0-nolibc/aarch64-linux
> -no-integrated-as -Werror=unknown-warning-option -mgeneral-regs-only
> -DCONFIG_AS_LSE=1 -fno-asynchronous-unwind-tables
> -DKASAN_SHADOW_SCALE_SHIFT=3 -fno-delete-null-pointer-checks
> -Wno-address-of-packed-member -O2 -Wframe-larger-than=2048
> -fstack-protector-strong -Wno-format-invalid-specifier -Wno-gnu
> -Wno-tautological-compare -mno-global-merge -Wno-unused-const-variable
> -fno-omit-frame-pointer -fno-optimize-sibling-calls -g
> -Wdeclaration-after-statement -Wvla -Wno-pointer-sign
> -fno-strict-overflow -fno-merge-all-constants -fno-stack-check
> -Werror=date-time -Werror=incompatible-pointer-types
> -Wno-initializer-overrides -Wno-format -Wno-sign-compare
> -Wno-format-zero-length-fsanitize=shift
> -fsanitize=integer-divide-by-zero -fsanitize=unreachable
> -fsanitize=signed-integer-overflow -fsanitize=bounds
> -fsanitize=object-size -fsanitize=bool -fsanitize=enum
> -fsanitize-coverage=trace-pc-DKBUILD_BASENAME='"setup"'
> -DKBUILD_MODNAME='"setup"' -c -o arch/arm64/kernel/setup.o
> arch/arm64/kernel/setup.c
>
> ... and there are 0 calls to __sanitizer_cov_trace_pc in the resulting
> setup.o, even though -fsanitize-coverage=trace-pc was passed to clang.
>
> If I remove -fsanitize=bounds, there are 121 calls to
> __sanitizer_cov_trace_pc in setup.o. Removing the other options enabled
> by UBSAN didn't have any effect on setup.o.
>
> I'm using the llvm.org 8.0.{0,1} binaries [1,2], along with the
> kernel.org crosstool 8.1.0 binaries [3].
>
> Any ideas as to what's going on?
>
> Thanks,
> Mark.
>
> [1] http://releases.llvm.org/download.html#8.0.0
> [2] http://releases.llvm.org/download.html#8.0.1
> [3]
[PATCHv2 3/4] ARM: dts: ls1021a: Remove num-lanes property from PCIe nodes
From: Hou Zhiqiang Remove the num-lanes to avoid the driver setting the link width. On FSL Layerscape SoCs, the number of lanes assigned to PCIe controller is not fixed, it is determined by the selected SerDes protocol in the RCW (Reset Configuration Word), and the PCIe link training is completed automatically base on the selected SerDes protocol, and the link width set-up is updated by hardware after power on reset. So the num-lanes is not needed for Layerscape PCIe. The current num-lanes was added erroneously, which actually indicates the max lanes PCIe controller can support up to, instead of the lanes assigned to the PCIe controller. And the link width set by SerDes protocol will be overridden by the num-lanes, hence the subsequent re-taining will fail when the assigned lanes does not equal to num-lanes. Signed-off-by: Hou Zhiqiang Reviewed-by: Andrew Murray --- V2: - Reworded the change log. arch/arm/boot/dts/ls1021a.dtsi | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi index 464df4290ffc..2f6977ada447 100644 --- a/arch/arm/boot/dts/ls1021a.dtsi +++ b/arch/arm/boot/dts/ls1021a.dtsi @@ -874,7 +874,6 @@ #address-cells = <3>; #size-cells = <2>; device_type = "pci"; - num-lanes = <4>; num-viewport = <6>; bus-range = <0x0 0xff>; ranges = <0x8100 0x0 0x 0x40 0x0001 0x0 0x0001 /* downstream I/O */ @@ -899,7 +898,6 @@ #address-cells = <3>; #size-cells = <2>; device_type = "pci"; - num-lanes = <4>; num-viewport = <6>; bus-range = <0x0 0xff>; ranges = <0x8100 0x0 0x 0x48 0x0001 0x0 0x0001 /* downstream I/O */ -- 2.17.1
[PATCHv2 2/4] PCI: dwc: Return directly when num-lanes is not found
From: Hou Zhiqiang
The num-lanes is optional, so probably it isn't added
on some platforms. The subsequent programming is base
on the num-lanes, hence return when it is not found.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Andrew Murray
---
V2:
- No change.
drivers/pci/controller/dwc/pcie-designware.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware.c
b/drivers/pci/controller/dwc/pcie-designware.c
index 7d25102c304c..0a89bfd1636e 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -423,8 +423,10 @@ void dw_pcie_setup(struct dw_pcie *pci)
ret = of_property_read_u32(np, "num-lanes", );
- if (ret)
- lanes = 0;
+ if (ret) {
+ dev_dbg(pci->dev, "property num-lanes isn't found\n");
+ return;
+ }
/* Set the number of lanes */
val = dw_pcie_readl_dbi(pci, PCIE_PORT_LINK_CONTROL);
--
2.17.1
[PATCHv2 1/4] dt-bindings: PCI: designware: Remove the num-lanes from Required properties
From: Hou Zhiqiang The num-lanes is not a mandatory property, e.g. on FSL Layerscape SoCs, the PCIe link training is completed automatically base on the selected SerDes protocol, it doesn't need the num-lanes to set-up the link width. It is previously in both Required and Optional properties, let's remove it from the Required properties. Signed-off-by: Hou Zhiqiang --- V2: - Reworded the change log and subject. - Fixed a typo in subject. Documentation/devicetree/bindings/pci/designware-pcie.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt index 5561a1c060d0..bd880df39a79 100644 --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt @@ -11,7 +11,6 @@ Required properties: the ATU address space. (The old way of getting the configuration address space from "ranges" is deprecated and should be avoided.) -- num-lanes: number of lanes to use RC mode: - #address-cells: set to <3> - #size-cells: set to <2> -- 2.17.1
[PATCHv2 4/4] arm64: dts: fsl: Remove num-lanes property from PCIe nodes
From: Hou Zhiqiang Remove the num-lanes to avoid the driver setting the link width. On FSL Layerscape SoCs, the number of lanes assigned to PCIe controller is not fixed, it is determined by the selected SerDes protocol in the RCW (Reset Configuration Word), and the PCIe link training is completed automatically base on the selected SerDes protocol, and the link width set-up is updated by hardware after power on reset. So the num-lanes is not needed for Layerscape PCIe. The current num-lanes was added erroneously, which actually indicates the max lanes PCIe controller can support up to, instead of the lanes assigned to the PCIe controller. And the link width set by SerDes protocol will be overridden by the num-lanes, hence the subsequent re-taining will fail when the assigned lanes does not equal to num-lanes. Signed-off-by: Hou Zhiqiang Reviewed-by: Andrew Murray --- V2: - Reworded the change log. arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 1 - arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 3 --- arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 6 -- arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 3 --- arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 4 5 files changed, 17 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi index ec6257a5b251..119c597ca867 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi @@ -486,7 +486,6 @@ #address-cells = <3>; #size-cells = <2>; device_type = "pci"; - num-lanes = <4>; num-viewport = <2>; bus-range = <0x0 0xff>; ranges = <0x8100 0x0 0x 0x40 0x0001 0x0 0x0001 /* downstream I/O */ diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi index 71d9ed9ff985..c084c7a4b6a6 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi @@ -677,7 +677,6 @@ #size-cells = <2>; device_type = "pci"; dma-coherent; - num-lanes = <4>; num-viewport = <6>; bus-range = <0x0 0xff>; ranges = <0x8100 0x0 0x 0x40 0x0001 0x0 0x0001 /* downstream I/O */ @@ -704,7 +703,6 @@ #size-cells = <2>; device_type = "pci"; dma-coherent; - num-lanes = <2>; num-viewport = <6>; bus-range = <0x0 0xff>; ranges = <0x8100 0x0 0x 0x48 0x0001 0x0 0x0001 /* downstream I/O */ @@ -731,7 +729,6 @@ #size-cells = <2>; device_type = "pci"; dma-coherent; - num-lanes = <2>; num-viewport = <6>; bus-range = <0x0 0xff>; ranges = <0x8100 0x0 0x 0x50 0x0001 0x0 0x0001 /* downstream I/O */ diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi index b0ef08b090dd..d4c1da3d4bde 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi @@ -649,7 +649,6 @@ #size-cells = <2>; device_type = "pci"; dma-coherent; - num-lanes = <4>; num-viewport = <8>; bus-range = <0x0 0xff>; ranges = <0x8100 0x0 0x 0x40 0x0001 0x0 0x0001 /* downstream I/O */ @@ -671,7 +670,6 @@ reg-names = "regs", "addr_space"; num-ib-windows = <6>; num-ob-windows = <8>; - num-lanes = <2>; status = "disabled"; }; @@ -687,7 +685,6 @@ #size-cells = <2>; device_type = "pci"; dma-coherent; - num-lanes = <2>; num-viewport = <8>; bus-range = <0x0 0xff>; ranges = <0x8100 0x0 0x 0x48 0x0001 0x0 0x0001 /* downstream I/O */ @@ -709,7 +706,6 @@ reg-names = "regs", "addr_space"; num-ib-windows = <6>; num-ob-windows = <8>; - num-lanes = <2>; status = "disabled"; }; @@ -725,7 +721,6 @@ #size-cells = <2>;
Re: [LINUX PATCH v19] mtd: rawnand: pl353: Add basic driver for arm pl353 smc nand interface
Hi,
On Tue, Jul 30, 2019 at 05:43:37AM -0600, Naga Sureshkumar Relli wrote:
> Add driver for arm pl353 static memory controller nand interface.
> This controller is used in Xilinx Zynq SoC for interfacing the
> NAND flash memory.
Is there a reason that you dropped me from the Cc list? If you Cc me,
the feedback loop is faster. Please continue to Cc me on this driver.
> -> Tested Micron MT29F2G08ABAEAWP (On-die capable) and AMD/Spansion S34ML01G1.
I tested this version of the driver with this exact Micron flash in an
on-die configuration against v5.3-rc4. The patch applied cleanly and
built without problems. The driver detects the chip and works
"somewhat". One can interact with portions of the flash, but the amount
of ECC errors returned makes it unusable. I was able to reproduce the
same issue on multiple devices.
...
[ 14.909894] jffs2: mtd->read(0x178 bytes from 0x21e0688) returned ECC error
[ 14.917250] jffs2: mtd->read(0x800 bytes from 0x21e) returned ECC error
[ 14.952765] jffs2: mtd->read(0x364 bytes from 0x21c049c) returned ECC error
[ 14.960070] jffs2: mtd->read(0x6f8 bytes from 0x21c0108) returned ECC error
[ 14.967435] jffs2: mtd->read(0x800 bytes from 0x21c) returned ECC error
[ 15.001194] [ cut here ]
[ 15.006092] WARNING: CPU: 0 PID: 94 at
drivers/mtd/nand/raw/nand_micron.c:245
micron_nand_read_page_on_die_ecc+0x394/0x3a0
[ 15.018148] ---[ end trace 2d1d02f05cac8fbb ]---
[ 15.022909] jffs2: error: (94) jffs2_get_inode_nodes: can not read 344 bytes
from 0x021a16a8, error code: -22.
[ 15.035205] jffs2: error: (94) jffs2_do_read_inode_internal: cannot read
nodes for ino 8375, returned error is -22
[ 15.045744] jffs2: Returned error for crccheck of ino #8375. Expect
badness...
[ 15.231220] jffs2: Checked all inodes but still 0x15361c bytes of unchecked
space?
[ 15.238851] jffs2: No space for garbage collection. Aborting GC thread
...
I cannot confirm that the driver works.
For completeness sake, here is the decompiled DT that I used:
memory-controller@e000e000 {
#address-cells = <0x2>;
#size-cells = <0x1>;
status = "okay";
clock-names = "memclk", "apb_pclk";
clocks = <0x1 0xb 0x1 0x2c>;
compatible = "arm,pl353-smc-r2p1", "arm,primecell";
interrupt-parent = <0x4>;
interrupts = <0x0 0x12 0x4>;
ranges = <0x0 0x0 0xe100 0x100>;
reg = <0xe000e000 0x1000>;
flash@e100 {
status = "okay";
compatible = "arm,pl353-nand-r2p1";
reg = <0x0 0x0 0x100>;
#address-cells = <0x1>;
#size-cells = <0x1>;
nand-ecc-mode = "on-die";
nand-bus-width = <0x8>;
};
};
I am posting a decompiled DT, because parts are generated using
https://github.com/Xilinx/device-tree-xlnx.
The driver from the xlnx 4.14 tree continues to work with the hardware I
used for testing.
Helmut
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
Hi, On 20/08/2019 08:48, H. Nikolaus Schaller wrote: > >> Am 19.08.2019 um 21:43 schrieb Adam Ford : >> >>> Thanks to the help from the Pyra community, I was able to get a (binary) >>> reference >>> implementation using DRM that works on Pyra/OMAP5. At least the gles1test1. >> >> just a question, >> >> If DRM is working, does that mean it works without needing the overhead of X? > > Yes, we have to kill X11 to successfully run the gles1test1. An interesting > question > will be how to mix both... E.g. have a 3D rendering in a window controlled by > some > window manager. > This is probably what you want to look at / start with: https://github.com/TexasInstruments/dri3wsegl Cheers, Merlijn signature.asc Description: OpenPGP digital signature
Re: [PATCH v8 2/3] fdt: add support for rng-seed
Hi Ted, Thanks for raising this question. For UEFI based system, they have a config table that carries rng seed and can be passed to device randomness. However, they also use add_device_randomness (not sure if it's the same reason that they can't guarantee _all_ bootloader can be trusted) This patch is to let DT based system also have similar features, which can make initial random number stronger. (We only care initial situation here, since more entropy would be added to kernel as time goes on ) Conservatively, we can use add_device_randomness() as well, which would pass buffer to crng_slow_load() instead of crng_fast_load(). But I think we should trust bootloader here. Whoever wants to use this feature should make sure their bootloader can pass valid (random enough) seeds. If they are not sure, they can just don't add the property to DT.
Re: [v2 PATCH] RISC-V: Optimize tlb flush path.
On Aug 19 2019, Atish Patra wrote:
> @@ -42,20 +43,44 @@ static inline void flush_tlb_range(struct vm_area_struct
> *vma,
>
> #include
>
> -static inline void remote_sfence_vma(struct cpumask *cmask, unsigned long
> start,
> - unsigned long size)
> +static void __riscv_flush_tlb(struct cpumask *cmask, unsigned long start,
> + unsigned long size)
cmask can be const.
> {
> struct cpumask hmask;
> + unsigned int hartid;
> + unsigned int cpuid;
>
> cpumask_clear();
> +
> + if (!cmask) {
> + riscv_cpuid_to_hartid_mask(cpu_online_mask, );
> + goto issue_sfence;
> + }
Wouldn't it make sense to fall through to doing a local flush here?
if (!cmask)
cmask = cpu_online_mask;
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: [PATCH v2 01/19] dt-bindings: display: renesas,cmm: Add R-Car CMM documentation
Hi Geert,
sorry for the delayed response..
On Mon, Aug 19, 2019 at 03:45:54PM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Mon, Jul 8, 2019 at 9:58 AM Geert Uytterhoeven
> wrote:
> > On Sat, Jul 6, 2019 at 4:07 PM Jacopo Mondi
> > wrote:
> > > Add device tree bindings documentation for the Renesas R-Car Display
> > > Unit Color Management Module.
> > >
> > > CMM is the image enhancement module available on each R-Car DU video
> > > channel on R-Car Gen2 and Gen3 SoCs (V3H and V3M excluded).
> > >
> > > Signed-off-by: Jacopo Mondi
> > > Reviewed-by: Laurent Pinchart
> >
> > Thanks for your patch!
> >
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/display/renesas,cmm.txt
> > > @@ -0,0 +1,25 @@
> > > +* Renesas R-Car Color Management Module (CMM)
> > > +
> > > +Renesas R-Car image enhancement module connected to R-Car DU video
> > > channels.
> > > +
> > > +Required properties:
> > > + - compatible: shall be one of:
> > > + - "renesas,rcar-gen3-cmm"
> > > + - "renesas,rcar-gen2-cmm"
> >
> > Why do you think you do not need SoC-specific compatible values?
> > What if you discover a different across the R-Car Gen3 line tomorrow?
> > Does the IP block have a version register?
>
> Do you have an answer to these questions?
It does not seem to me that CMM has any version register, nor there
are differences between the different Gen3 SoCs..
However, even if we now define a single compatible property for
gen3/gen2 and we later find out one of the SoC needs a soc-specific
property we can safely add it and keep the generic gen3/gen2 one as
fallback.. Does it work for you?
Thanks
j
> Thanks!
>
> 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
signature.asc
Description: PGP signature
[PATCH] x86/mm/pti: in pti_clone_pgtable() don't increase addr by PUD_SIZE
pti_clone_pgtable() increases addr by PUD_SIZE for pud_none(*pud) case.
This is not accurate because addr may not be PUD_SIZE aligned.
In our x86_64 kernel, pti_clone_pgtable() fails to clone 7 PMDs because
of this issuse, including PMD for the irq entry table. For a memcache
like workload, this introduces about 4.5x more iTLB-load and about 2.5x
more iTLB-load-misses on a Skylake CPU.
This patch fixes this issue by adding PMD_SIZE to addr for pud_none()
case.
Cc: sta...@vger.kernel.org # v4.19+
Fixes: 16a3fe634f6a ("x86/mm/pti: Clone kernel-image on PTE level for 32 bit")
Signed-off-by: Song Liu
Cc: Joerg Roedel
Cc: Thomas Gleixner
Cc: Dave Hansen
Cc: Andy Lutomirski
Cc: Peter Zijlstra
---
arch/x86/mm/pti.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
index b196524759ec..5a67c3015f59 100644
--- a/arch/x86/mm/pti.c
+++ b/arch/x86/mm/pti.c
@@ -330,7 +330,7 @@ pti_clone_pgtable(unsigned long start, unsigned long end,
pud = pud_offset(p4d, addr);
if (pud_none(*pud)) {
- addr += PUD_SIZE;
+ addr += PMD_SIZE;
continue;
}
--
2.17.1
Re: [PATCH v4 06/10] modpost: Add modinfo flag to livepatch modules
> > How is this feature supposed to work for external modules? > > > > klp-convert receives: > > "symbols from vmlinux" + "symbols from no-klp in-tree modules" > > + "symbols from no-klp external modules" ?? > > > > I don't think that this use-case has been previously thought out (Miroslav, > correct me if I'm wrong here.) > > I did just run an external build of a copy of > samples/livepatch/livepatch-annotated-sample.c: > > - modules.livepatch is generated in external dir > - klp-convert is invoked for the livepatch module > - the external livepatch module successfully loads > > But that was only testing external livepatch modules. > > I don't know if we need/want to support general external modules supplementing > Symbols.list, at least for the initial klp-convert commit. I suppose external > livepatch modules would then need to specify additional Symbols.list(s) files > somehow as well. I think we discussed it briefly and decided to postpone it for later improvements. External modules are not so important in my opinion. > > > > BTW, 'Symbols.list' sounds like a file to list out symbols > > for generic purposes, but in fact, the > > file format is very specific for the klp-convert tool. > > Perhaps, is it better to rename it so it infers > > this is for livepatching? What do you think? > > > > I don't know if the "Symbols.list" name and leading uppercase was based on any > convention, but something like symbols.klp would be fine with me. symbols.klp looks ok Miroslav
[PATCH] NFSv4: Fix a memory leak bug
In nfs4_try_migration(), if nfs4_begin_drain_session() fails, the
previously allocated 'page' and 'locations' are not deallocated, leading to
memory leaks. To fix this issue, free 'page' and 'locations' before
returning the error.
Signed-off-by: Wenwen Wang
---
fs/nfs/nfs4state.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
index cad4e06..37823dc 100644
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -2095,8 +2095,12 @@ static int nfs4_try_migration(struct nfs_server *server,
const struct cred *cred
}
status = nfs4_begin_drain_session(clp);
- if (status != 0)
+ if (status != 0) {
+ if (page != NULL)
+ __free_page(page);
+ kfree(locations);
return status;
+ }
status = nfs4_replace_transport(server, locations);
if (status != 0) {
--
2.7.4
[PATCH net-next v4 2/2] dt-bindings: net: meson-dwmac: convert to yaml
Now that we have the DT validation in place, let's convert the device tree
bindings for the Synopsys DWMAC Glue for Amlogic SoCs over to a YAML schemas.
Reviewed-by: Rob Herring
Reviewed-by: Martin Blumenstingl
Signed-off-by: Neil Armstrong
---
.../bindings/net/amlogic,meson-dwmac.yaml | 113 ++
.../devicetree/bindings/net/meson-dwmac.txt | 71 ---
.../devicetree/bindings/net/snps,dwmac.yaml | 5 +
3 files changed, 118 insertions(+), 71 deletions(-)
create mode 100644
Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
delete mode 100644 Documentation/devicetree/bindings/net/meson-dwmac.txt
diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
new file mode 100644
index ..ae91aa9d8616
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/net/amlogic,meson-dwmac.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Amlogic Meson DWMAC Ethernet controller
+
+maintainers:
+ - Neil Armstrong
+ - Martin Blumenstingl
+
+# We need a select here so we don't match all nodes with 'snps,dwmac'
+select:
+ properties:
+compatible:
+ contains:
+enum:
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+ required:
+- compatible
+
+allOf:
+ - $ref: "snps,dwmac.yaml#"
+ - if:
+ properties:
+compatible:
+ contains:
+enum:
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+
+then:
+ properties:
+clocks:
+ items:
+- description: GMAC main clock
+- description: First parent clock of the internal mux
+- description: Second parent clock of the internal mux
+
+clock-names:
+ minItems: 3
+ maxItems: 3
+ items:
+- const: stmmaceth
+- const: clkin0
+- const: clkin1
+
+amlogic,tx-delay-ns:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description:
+The internal RGMII TX clock delay (provided by this driver) in
+nanoseconds. Allowed values are 0ns, 2ns, 4ns, 6ns.
+When phy-mode is set to "rgmii" then the TX delay should be
+explicitly configured. When not configured a fallback of 2ns is
+used. When the phy-mode is set to either "rgmii-id" or "rgmii-txid"
+the TX clock delay is already provided by the PHY. In that case
+this property should be set to 0ns (which disables the TX clock
+delay in the MAC to prevent the clock from going off because both
+PHY and MAC are adding a delay).
+Any configuration is ignored when the phy-mode is set to "rmii".
+
+properties:
+ compatible:
+additionalItems: true
+maxItems: 3
+items:
+ - enum:
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+contains:
+ enum:
+- snps,dwmac-3.70a
+- snps,dwmac
+
+ reg:
+items:
+ - description:
+ The first register range should be the one of the DWMAC controller
+ - description:
+ The second range is is for the Amlogic specific configuration
+ (for example the PRG_ETHERNET register range on Meson8b and newer)
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - phy-mode
+
+examples:
+ - |
+ethmac: ethernet@c941 {
+ compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
+ reg = <0xc941 0x1>, <0xc8834540 0x8>;
+ interrupts = <8>;
+ interrupt-names = "macirq";
+ clocks = <_eth>, <_fclk_div2>, <_mpll2>;
+ clock-names = "stmmaceth", "clkin0", "clkin1";
+ phy-mode = "rgmii";
+};
diff --git a/Documentation/devicetree/bindings/net/meson-dwmac.txt
b/Documentation/devicetree/bindings/net/meson-dwmac.txt
deleted file mode 100644
index 1321bb194ed9..
--- a/Documentation/devicetree/bindings/net/meson-dwmac.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-* Amlogic Meson DWMAC Ethernet controller
-
-The device inherits all the properties of the dwmac/stmmac devices
-described in the file stmmac.txt in the current directory with the
-following changes.
-
-Required properties on all platforms:
-
-- compatible: Depending on the platform this should be one of:
- - "amlogic,meson6-dwmac"
-
[PATCH net-next v4 0/2] dt-bindings: net: meson-dwmac: convert to yaml
This patchsets converts the Amlogic Meson DWMAC glue bindings over to YAML schemas using the already converted dwmac bindings. The first patch is needed because the Amlogic glue needs a supplementary reg cell to access the DWMAC glue registers. Changes since v3: - Specified net-next target tree Changes since v2: - Added review tags - Updated allwinner,sun7i-a20-gmac.yaml reg maxItems Neil Armstrong (2): dt-bindings: net: snps,dwmac: update reg minItems maxItems dt-bindings: net: meson-dwmac: convert to yaml .../net/allwinner,sun7i-a20-gmac.yaml | 3 + .../bindings/net/amlogic,meson-dwmac.yaml | 113 ++ .../devicetree/bindings/net/meson-dwmac.txt | 71 --- .../devicetree/bindings/net/snps,dwmac.yaml | 8 +- 4 files changed, 123 insertions(+), 72 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml delete mode 100644 Documentation/devicetree/bindings/net/meson-dwmac.txt -- 2.22.0
[PATCH net-next v4 1/2] dt-bindings: net: snps,dwmac: update reg minItems maxItems
The Amlogic Meson DWMAC glue bindings needs a second reg cells for the glue registers, thus update the reg minItems/maxItems to allow more than a single reg cell. Also update the allwinner,sun7i-a20-gmac.yaml derivative schema to specify maxItems to 1. Signed-off-by: Neil Armstrong Acked-by: Rob Herring Acked-by: Maxime Ripard --- .../devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml | 3 +++ Documentation/devicetree/bindings/net/snps,dwmac.yaml | 3 ++- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml index 06b1cc8bea14..ef446ae166f3 100644 --- a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml +++ b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml @@ -17,6 +17,9 @@ properties: compatible: const: allwinner,sun7i-a20-gmac + reg: +maxItems: 1 + interrupts: maxItems: 1 diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 76fea2be66ac..4377f511a51d 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -61,7 +61,8 @@ properties: - snps,dwxgmac-2.10 reg: -maxItems: 1 +minItems: 1 +maxItems: 2 interrupts: minItems: 1 -- 2.22.0
Re: [v5 PATCH] RISC-V: Fix unsupported isa string info.
On Sun, 2019-08-18 at 11:16 -0700, h...@infradead.org wrote:
> On Fri, Aug 16, 2019 at 07:21:52PM +, Atish Patra wrote:
> > > > + if (isa[0] != '\0') {
> > > > + /* Add remainging isa strings */
> > > > + for (e = isa; *e != '\0'; ++e) {
> > > > +#if !defined(CONFIG_VIRTUALIZATION)
> > > > + if (e[0] != 'h')
> > > > +#endif
> > > > + seq_write(f, e, 1);
> > > > + }
> > > > + }
> > >
> > > This one I don't get. Why do we want to check
> > > CONFIG_VIRTUALIZATION?
> > >
> >
> > If CONFIG_VIRTUALIZATION is not enabled, it shouldn't print that
> > hypervisor extension "h" in isa extensions.
>
> CONFIG_VIRTUALIZATION doesn't change anything in the kernels
> capabilities, it just enables other config options.
Yes. But it must be enabled if virtualization is supported in kernel.
The idea was to let userspace know that if virtualization can be used
or not.
> But more
> importantly the 'h' extension is only relevant for S-mode software
> anyway.
>
Do you think we should just print all the extensions available in isa
string as it is ?
> > This is just an information to the userspace that some of the
> > mandatory
> > ISA extensions ("mafdcsu") are not supported in kernel which may
> > lead
> > to undesirable results.
>
> I think we need to sit down decide what the purpose of /proc/cpuinfo
> is. IIRC on other architectures is just prints what the hardware
> supports, not what you can actually make use of. How else would you
> find out that you'd need to enable more kernel options to fully
> utilize the hardware?
>
> Also printing this warning to the kernel log when someone reads the
> procfs file is very strange.
Agreed. May be something like this ?
Let's say f/d is enabled in kernel but cpu doesn't support it.
"unsupported isa" will only appear if there are any unsupported isa.
processor : 3
hart: 4
isa : rv64imac
unsupported isa : fd
mmu : sv39
uarch : sifive,u54-mc
May be I am just trying over optimize one corner case :) :).
/proc/cpuinfo should just print all the isa string. That's it.
Regards,
Atish
Re: [PATCH v3] gpio: pl061: Fix the issue failed to register the ACPI interrtupion
On Mon, Aug 19, 2019 at 3:29 PM Wei Xu wrote: > Invoke acpi_gpiochip_request_interrupts after the acpi data has been > attached to the pl061 acpi node to register interruption. > > Otherwise it will be failed to register interruption for the ACPI case. > Because in the gpiochip_add_data_with_key, acpi_gpiochip_add is invoked > after gpiochip_add_irqchip but at that time the acpi data has not been > attached yet. We need to fix this problem in gpiochip_add_data_with_key() instead. Yours, Linus Walleij
Re: [PATCH v7 0/4] DCMI bridge support
Hi Sakari, Hans, st-mipid02 changes are already merged, thanks Sakari and sorry for disturbance. Still remain the V4L2_CID_LINK_FREQ for OV5640. On 8/19/19 11:13 AM, Hugues FRUCHET wrote: > Hi Hans, Sakari, > > OK to push separately the 80 char fix. > > There was pending related changes on st-mipid02 and ov5640 (listed > below), do you think it's possible to take them also ? > > > media: st-mipid02: add support of V4L2_CID_LINK_FREQ > https://patchwork.linuxtv.org/patch/56969/ > State Accepted > > [v2,1/3] media: st-mipid02: add support of RGB565 > https://patchwork.linuxtv.org/patch/56970/ > State Accepted > > [v2,2/3] media: st-mipid02: add support of YUYV8 and UYVY8 > https://patchwork.linuxtv.org/patch/56971/ > State Accepted > > [v2,3/3] media: st-mipid02: add support of JPEG > https://patchwork.linuxtv.org/patch/56973/ > State Accepted > > > [v2] media: ov5640: add support of V4L2_CID_LINK_FREQ > https://patchwork.linuxtv.org/patch/57215/ > State Changes Requested > => This change is needed to make it work the whole setup. > => I don't know what to change here, even if this 384MHz fixed value > seems strange, it works fine on my setup, on my opinion it's better than > nothing. We could come back on this later on when other OV5640 CSI > interfaces will require V4L2_CID_LINK_FREQ value. > > Sakari, what do you think about this ? > > > BR, > Hugues. BR, Hugues.
[PATCH v11 0/7] powerpc: implement machine check safe memcpy
During a memcpy from a pmem device, if a machine check exception is generated we end up in a panic. In case of fsdax read, this should only result in a -EIO. Avoid MCE by implementing memcpy_mcsafe. Before this patch series: ``` bash-4.4# mount -o dax /dev/pmem0 /mnt/pmem/ [ 7621.714094] Disabling lock debugging due to kernel taint [ 7621.714099] MCE: CPU0: machine check (Severe) Host UE Load/Store [Not recovered] [ 7621.714104] MCE: CPU0: NIP: [c0088978] memcpy_power7+0x418/0x7e0 [ 7621.714107] MCE: CPU0: Hardware error [ 7621.714112] opal: Hardware platform error: Unrecoverable Machine Check exception [ 7621.714118] CPU: 0 PID: 1368 Comm: mount Tainted: G M 5.2.0-rc5-00239-g241e39004581 #50 [ 7621.714123] NIP: c0088978 LR: c08e16f8 CTR: 01de [ 7621.714129] REGS: c000fffbfd70 TRAP: 0200 Tainted: G M (5.2.0-rc5-00239-g241e39004581) [ 7621.714131] MSR: 92209033 CR: 24428840 XER: 0004 [ 7621.714160] CFAR: c00889a8 DAR: deadbeefdeadbeef DSISR: 8000 IRQMASK: 0 [ 7621.714171] GPR00: 0e00 c000f0b8b1e0 c12cf100 c000ed8e1100 [ 7621.714186] GPR04: c2001100 0001 0200 03fff1272000 [ 7621.714201] GPR08: 8000 0010 0020 0030 [ 7621.714216] GPR12: 0040 7fffb8c6d390 0050 0060 [ 7621.714232] GPR16: 0070 0001 c000f0b8b960 [ 7621.714247] GPR20: 0001 c000f0b8b940 0001 0001 [ 7621.714262] GPR24: c1382560 c00c003b6380 c00c003b6380 0001 [ 7621.714277] GPR28: 0001 c200 0001 [ 7621.714294] NIP [c0088978] memcpy_power7+0x418/0x7e0 [ 7621.714298] LR [c08e16f8] pmem_do_bvec+0xf8/0x430 ... ... ``` After this patch series: ``` bash-4.4# mount -o dax /dev/pmem0 /mnt/pmem/ [25302.883978] Buffer I/O error on dev pmem0, logical block 0, async page read [25303.020816] EXT4-fs (pmem0): DAX enabled. Warning: EXPERIMENTAL, use at your own risk [25303.021236] EXT4-fs (pmem0): Can't read superblock on 2nd try [25303.152515] EXT4-fs (pmem0): DAX enabled. Warning: EXPERIMENTAL, use at your own risk [25303.284031] EXT4-fs (pmem0): DAX enabled. Warning: EXPERIMENTAL, use at your own risk [25304.084100] UDF-fs: bad mount option "dax" or missing value mount: /mnt/pmem: wrong fs type, bad option, bad superblock on /dev/pmem0, missing codepage or helper program, or other error. ``` MCE is injected on a pmem address using mambo. The last patch which adds a nop is only for testing on mambo, where r13 is not restored upon hitting vector 200. The memcpy code can be optimised by adding VMX optimizations and GAS macros can be used to enable code reusablity, which I will send as another series. -- v11: * Move back to returning pfn instead of physical address [nick] * Move patch "Handle UE event" up in the order * Add reviewed-bys v10: Fix authorship; add reviewed-bys and acks. v9: * Add a new IRQ work for UE events [mahesh] * Reorder patches, and copy stable v8: * While ignoring UE events, return was used instead of continue. * Checkpatch fixups for commit log v7: * Move schedule_work to be called from irq_work. v6: * Don't return pfn, all callees are expecting physical address anyway [nick] * Patch re-ordering: move exception table patch before memcpy_mcsafe patch [nick] * Reword commit log for search_exception_tables patch [nick] v5: * Don't use search_exception_tables since it searches for module exception tables also [Nicholas] * Fix commit message for patch 2 [Nicholas] v4: * Squash return remaining bytes patch to memcpy_mcsafe implemtation patch [christophe] * Access ok should be checked for copy_to_user_mcsafe() [christophe] v3: * Drop patch which enables DR/IR for external modules * Drop notifier call chain, we don't want to do that in real mode * Return remaining bytes from memcpy_mcsafe correctly * We no longer restore r13 for simulator tests, rather use a nop at vector 0x200 [workaround for simulator; not to be merged] v2: * Don't set RI bit explicitly [mahesh] * Re-ordered series to get r13 workaround as the last patch -- Balbir Singh (3): powerpc/mce: Fix MCE handling for huge pages powerpc/mce: Handle UE event for memcpy_mcsafe powerpc/memcpy: Add memcpy_mcsafe for pmem Reza Arbab (1): powerpc/mce: Make machine_check_ue_event() static Santosh Sivaraj (3): powerpc/mce: Schedule work from irq_work extable: Add function to search only kernel exception table powerpc: add machine check safe copy_to_user arch/powerpc/Kconfig| 1 + arch/powerpc/include/asm/mce.h | 4 +- arch/powerpc/include/asm/string.h | 2 + arch/powerpc/include/asm/uaccess.h | 14 ++ arch/powerpc/kernel/mce.c | 31 +++-
[PATCH v11 2/7] powerpc/mce: Fix MCE handling for huge pages
From: Balbir Singh
The current code would fail on huge pages addresses, since the shift would
be incorrect. Use the correct page shift value returned by
__find_linux_pte() to get the correct physical address. The code is more
generic and can handle both regular and compound pages.
Fixes: ba41e1e1ccb9 ("powerpc/mce: Hookup derror (load/store) UE errors")
Signed-off-by: Balbir Singh
[ar...@linux.ibm.com: Fixup pseries_do_memory_failure()]
Signed-off-by: Reza Arbab
Tested-by: Mahesh Salgaonkar
Signed-off-by: Santosh Sivaraj
Cc: sta...@vger.kernel.org # v4.15+
---
arch/powerpc/kernel/mce_power.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/mce_power.c b/arch/powerpc/kernel/mce_power.c
index a814d2dfb5b0..714a98e0927f 100644
--- a/arch/powerpc/kernel/mce_power.c
+++ b/arch/powerpc/kernel/mce_power.c
@@ -26,6 +26,7 @@
unsigned long addr_to_pfn(struct pt_regs *regs, unsigned long addr)
{
pte_t *ptep;
+ unsigned int shift;
unsigned long flags;
struct mm_struct *mm;
@@ -35,13 +36,18 @@ unsigned long addr_to_pfn(struct pt_regs *regs, unsigned
long addr)
mm = _mm;
local_irq_save(flags);
- if (mm == current->mm)
- ptep = find_current_mm_pte(mm->pgd, addr, NULL, NULL);
- else
- ptep = find_init_mm_pte(addr, NULL);
+ ptep = __find_linux_pte(mm->pgd, addr, NULL, );
local_irq_restore(flags);
+
if (!ptep || pte_special(*ptep))
return ULONG_MAX;
+
+ if (shift > PAGE_SHIFT) {
+ unsigned long rpnmask = (1ul << shift) - PAGE_SIZE;
+
+ return pte_pfn(__pte(pte_val(*ptep) | (addr & rpnmask)));
+ }
+
return pte_pfn(*ptep);
}
@@ -344,7 +350,7 @@ static const struct mce_derror_table mce_p9_derror_table[]
= {
MCE_INITIATOR_CPU, MCE_SEV_SEVERE, true },
{ 0, false, 0, 0, 0, 0, 0 } };
-static int mce_find_instr_ea_and_pfn(struct pt_regs *regs, uint64_t *addr,
+static int mce_find_instr_ea_and_phys(struct pt_regs *regs, uint64_t *addr,
uint64_t *phys_addr)
{
/*
@@ -541,7 +547,8 @@ static int mce_handle_derror(struct pt_regs *regs,
* kernel/exception-64s.h
*/
if (get_paca()->in_mce < MAX_MCE_DEPTH)
- mce_find_instr_ea_and_pfn(regs, addr,
phys_addr);
+ mce_find_instr_ea_and_phys(regs, addr,
+ phys_addr);
}
found = 1;
}
--
2.21.0
[PATCH v11 3/7] powerpc/mce: Make machine_check_ue_event() static
From: Reza Arbab
The function doesn't get used outside this file, so make it static.
Signed-off-by: Reza Arbab
Signed-off-by: Santosh Sivaraj
Reviewed-by: Nicholas Piggin
---
arch/powerpc/kernel/mce.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
index cff31d4a501f..a3b122a685a5 100644
--- a/arch/powerpc/kernel/mce.c
+++ b/arch/powerpc/kernel/mce.c
@@ -34,7 +34,7 @@ static DEFINE_PER_CPU(struct machine_check_event[MAX_MC_EVT],
static void machine_check_process_queued_event(struct irq_work *work);
static void machine_check_ue_irq_work(struct irq_work *work);
-void machine_check_ue_event(struct machine_check_event *evt);
+static void machine_check_ue_event(struct machine_check_event *evt);
static void machine_process_ue_event(struct work_struct *work);
static struct irq_work mce_event_process_work = {
@@ -212,7 +212,7 @@ static void machine_check_ue_irq_work(struct irq_work *work)
/*
* Queue up the MCE event which then can be handled later.
*/
-void machine_check_ue_event(struct machine_check_event *evt)
+static void machine_check_ue_event(struct machine_check_event *evt)
{
int index;
--
2.21.0
[PATCH v11 4/7] extable: Add function to search only kernel exception table
Certain architecture specific operating modes (e.g., in powerpc machine
check handler that is unable to access vmalloc memory), the
search_exception_tables cannot be called because it also searches the
module exception tables if entry is not found in the kernel exception
table.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Nicholas Piggin
Signed-off-by: Santosh Sivaraj
Reviewed-by: Nicholas Piggin
---
include/linux/extable.h | 2 ++
kernel/extable.c| 11 +--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/include/linux/extable.h b/include/linux/extable.h
index 41c5b3a25f67..81ecfaa83ad3 100644
--- a/include/linux/extable.h
+++ b/include/linux/extable.h
@@ -19,6 +19,8 @@ void trim_init_extable(struct module *m);
/* Given an address, look for it in the exception tables */
const struct exception_table_entry *search_exception_tables(unsigned long add);
+const struct exception_table_entry *
+search_kernel_exception_table(unsigned long addr);
#ifdef CONFIG_MODULES
/* For extable.c to search modules' exception tables. */
diff --git a/kernel/extable.c b/kernel/extable.c
index e23cce6e6092..f6c9406eec7d 100644
--- a/kernel/extable.c
+++ b/kernel/extable.c
@@ -40,13 +40,20 @@ void __init sort_main_extable(void)
}
}
+/* Given an address, look for it in the kernel exception table */
+const
+struct exception_table_entry *search_kernel_exception_table(unsigned long addr)
+{
+ return search_extable(__start___ex_table,
+ __stop___ex_table - __start___ex_table, addr);
+}
+
/* Given an address, look for it in the exception tables. */
const struct exception_table_entry *search_exception_tables(unsigned long addr)
{
const struct exception_table_entry *e;
- e = search_extable(__start___ex_table,
- __stop___ex_table - __start___ex_table, addr);
+ e = search_kernel_exception_table(addr);
if (!e)
e = search_module_extables(addr);
return e;
--
2.21.0
[PATCH v11 1/7] powerpc/mce: Schedule work from irq_work
schedule_work() cannot be called from MCE exception context as MCE can
interrupt even in interrupt disabled context.
fixes: 733e4a4c ("powerpc/mce: hookup memory_failure for UE errors")
Reviewed-by: Mahesh Salgaonkar
Reviewed-by: Nicholas Piggin
Acked-by: Balbir Singh
Signed-off-by: Santosh Sivaraj
Cc: sta...@vger.kernel.org # v4.15+
---
arch/powerpc/kernel/mce.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
index b18df633eae9..cff31d4a501f 100644
--- a/arch/powerpc/kernel/mce.c
+++ b/arch/powerpc/kernel/mce.c
@@ -33,6 +33,7 @@ static DEFINE_PER_CPU(struct machine_check_event[MAX_MC_EVT],
mce_ue_event_queue);
static void machine_check_process_queued_event(struct irq_work *work);
+static void machine_check_ue_irq_work(struct irq_work *work);
void machine_check_ue_event(struct machine_check_event *evt);
static void machine_process_ue_event(struct work_struct *work);
@@ -40,6 +41,10 @@ static struct irq_work mce_event_process_work = {
.func = machine_check_process_queued_event,
};
+static struct irq_work mce_ue_event_irq_work = {
+ .func = machine_check_ue_irq_work,
+};
+
DECLARE_WORK(mce_ue_event_work, machine_process_ue_event);
static void mce_set_error_info(struct machine_check_event *mce,
@@ -199,6 +204,10 @@ void release_mce_event(void)
get_mce_event(NULL, true);
}
+static void machine_check_ue_irq_work(struct irq_work *work)
+{
+ schedule_work(_ue_event_work);
+}
/*
* Queue up the MCE event which then can be handled later.
@@ -216,7 +225,7 @@ void machine_check_ue_event(struct machine_check_event *evt)
memcpy(this_cpu_ptr(_ue_event_queue[index]), evt, sizeof(*evt));
/* Queue work to process this event later. */
- schedule_work(_ue_event_work);
+ irq_work_queue(_ue_event_irq_work);
}
/*
--
2.21.0
[PATCH v11 5/7] powerpc/mce: Handle UE event for memcpy_mcsafe
From: Balbir Singh
If we take a UE on one of the instructions with a fixup entry, set nip
to continue execution at the fixup entry. Stop processing the event
further or print it.
Co-developed-by: Reza Arbab
Signed-off-by: Reza Arbab
Signed-off-by: Balbir Singh
Reviewed-by: Mahesh Salgaonkar
Reviewed-by: Nicholas Piggin
Signed-off-by: Santosh Sivaraj
---
arch/powerpc/include/asm/mce.h | 4 +++-
arch/powerpc/kernel/mce.c | 16
arch/powerpc/kernel/mce_power.c | 15 +--
3 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/mce.h b/arch/powerpc/include/asm/mce.h
index a4c6a74ad2fb..19a33707d5ef 100644
--- a/arch/powerpc/include/asm/mce.h
+++ b/arch/powerpc/include/asm/mce.h
@@ -122,7 +122,8 @@ struct machine_check_event {
enum MCE_UeErrorType ue_error_type:8;
u8 effective_address_provided;
u8 physical_address_provided;
- u8 reserved_1[5];
+ u8 ignore_event;
+ u8 reserved_1[4];
u64 effective_address;
u64 physical_address;
u8 reserved_2[8];
@@ -193,6 +194,7 @@ struct mce_error_info {
enum MCE_Initiator initiator:8;
enum MCE_ErrorClass error_class:8;
boolsync_error;
+ boolignore_event;
};
#define MAX_MC_EVT 100
diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
index a3b122a685a5..ec4b3e1087be 100644
--- a/arch/powerpc/kernel/mce.c
+++ b/arch/powerpc/kernel/mce.c
@@ -149,6 +149,7 @@ void save_mce_event(struct pt_regs *regs, long handled,
if (phys_addr != ULONG_MAX) {
mce->u.ue_error.physical_address_provided = true;
mce->u.ue_error.physical_address = phys_addr;
+ mce->u.ue_error.ignore_event = mce_err->ignore_event;
machine_check_ue_event(mce);
}
}
@@ -266,8 +267,17 @@ static void machine_process_ue_event(struct work_struct
*work)
/*
* This should probably queued elsewhere, but
* oh! well
+*
+* Don't report this machine check because the caller has a
+* asked us to ignore the event, it has a fixup handler which
+* will do the appropriate error handling and reporting.
*/
if (evt->error_type == MCE_ERROR_TYPE_UE) {
+ if (evt->u.ue_error.ignore_event) {
+ __this_cpu_dec(mce_ue_count);
+ continue;
+ }
+
if (evt->u.ue_error.physical_address_provided) {
unsigned long pfn;
@@ -301,6 +311,12 @@ static void machine_check_process_queued_event(struct
irq_work *work)
while (__this_cpu_read(mce_queue_count) > 0) {
index = __this_cpu_read(mce_queue_count) - 1;
evt = this_cpu_ptr(_event_queue[index]);
+
+ if (evt->error_type == MCE_ERROR_TYPE_UE &&
+ evt->u.ue_error.ignore_event) {
+ __this_cpu_dec(mce_queue_count);
+ continue;
+ }
machine_check_print_event_info(evt, false, false);
__this_cpu_dec(mce_queue_count);
}
diff --git a/arch/powerpc/kernel/mce_power.c b/arch/powerpc/kernel/mce_power.c
index 714a98e0927f..b6cbe3449358 100644
--- a/arch/powerpc/kernel/mce_power.c
+++ b/arch/powerpc/kernel/mce_power.c
@@ -11,6 +11,7 @@
#include
#include
+#include
#include
#include
#include
@@ -18,6 +19,7 @@
#include
#include
#include
+#include
/*
* Convert an address related to an mm to a PFN. NOTE: we are in real
@@ -565,9 +567,18 @@ static int mce_handle_derror(struct pt_regs *regs,
return 0;
}
-static long mce_handle_ue_error(struct pt_regs *regs)
+static long mce_handle_ue_error(struct pt_regs *regs,
+ struct mce_error_info *mce_err)
{
long handled = 0;
+ const struct exception_table_entry *entry;
+
+ entry = search_kernel_exception_table(regs->nip);
+ if (entry) {
+ mce_err->ignore_event = true;
+ regs->nip = extable_fixup(entry);
+ return 1;
+ }
/*
* On specific SCOM read via MMIO we may get a machine check
@@ -600,7 +611,7 @@ static long mce_handle_error(struct pt_regs *regs,
_addr);
if (!handled && mce_err.error_type == MCE_ERROR_TYPE_UE)
- handled = mce_handle_ue_error(regs);
+ handled = mce_handle_ue_error(regs,
[PATCH v11 6/7] powerpc/memcpy: Add memcpy_mcsafe for pmem
From: Balbir Singh The pmem infrastructure uses memcpy_mcsafe in the pmem layer so as to convert machine check exceptions into a return value on failure in case a machine check exception is encountered during the memcpy. The return value is the number of bytes remaining to be copied. This patch largely borrows from the copyuser_power7 logic and does not add the VMX optimizations, largely to keep the patch simple. If needed those optimizations can be folded in. Signed-off-by: Balbir Singh [ar...@linux.ibm.com: Added symbol export] Co-developed-by: Santosh Sivaraj Signed-off-by: Santosh Sivaraj --- arch/powerpc/include/asm/string.h | 2 + arch/powerpc/lib/Makefile | 2 +- arch/powerpc/lib/memcpy_mcsafe_64.S | 242 3 files changed, 245 insertions(+), 1 deletion(-) create mode 100644 arch/powerpc/lib/memcpy_mcsafe_64.S diff --git a/arch/powerpc/include/asm/string.h b/arch/powerpc/include/asm/string.h index 9bf6dffb4090..b72692702f35 100644 --- a/arch/powerpc/include/asm/string.h +++ b/arch/powerpc/include/asm/string.h @@ -53,7 +53,9 @@ void *__memmove(void *to, const void *from, __kernel_size_t n); #ifndef CONFIG_KASAN #define __HAVE_ARCH_MEMSET32 #define __HAVE_ARCH_MEMSET64 +#define __HAVE_ARCH_MEMCPY_MCSAFE +extern int memcpy_mcsafe(void *dst, const void *src, __kernel_size_t sz); extern void *__memset16(uint16_t *, uint16_t v, __kernel_size_t); extern void *__memset32(uint32_t *, uint32_t v, __kernel_size_t); extern void *__memset64(uint64_t *, uint64_t v, __kernel_size_t); diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile index eebc782d89a5..fa6b1b657b43 100644 --- a/arch/powerpc/lib/Makefile +++ b/arch/powerpc/lib/Makefile @@ -39,7 +39,7 @@ obj-$(CONFIG_PPC_BOOK3S_64) += copyuser_power7.o copypage_power7.o \ memcpy_power7.o obj64-y+= copypage_64.o copyuser_64.o mem_64.o hweight_64.o \ - memcpy_64.o pmem.o + memcpy_64.o pmem.o memcpy_mcsafe_64.o obj64-$(CONFIG_SMP)+= locks.o obj64-$(CONFIG_ALTIVEC)+= vmx-helper.o diff --git a/arch/powerpc/lib/memcpy_mcsafe_64.S b/arch/powerpc/lib/memcpy_mcsafe_64.S new file mode 100644 index ..949976dc115d --- /dev/null +++ b/arch/powerpc/lib/memcpy_mcsafe_64.S @@ -0,0 +1,242 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (C) IBM Corporation, 2011 + * Derived from copyuser_power7.s by Anton Blanchard + * Author - Balbir Singh + */ +#include +#include +#include + + .macro err1 +100: + EX_TABLE(100b,.Ldo_err1) + .endm + + .macro err2 +200: + EX_TABLE(200b,.Ldo_err2) + .endm + + .macro err3 +300: EX_TABLE(300b,.Ldone) + .endm + +.Ldo_err2: + ld r22,STK_REG(R22)(r1) + ld r21,STK_REG(R21)(r1) + ld r20,STK_REG(R20)(r1) + ld r19,STK_REG(R19)(r1) + ld r18,STK_REG(R18)(r1) + ld r17,STK_REG(R17)(r1) + ld r16,STK_REG(R16)(r1) + ld r15,STK_REG(R15)(r1) + ld r14,STK_REG(R14)(r1) + addir1,r1,STACKFRAMESIZE +.Ldo_err1: + /* Do a byte by byte copy to get the exact remaining size */ + mtctr r7 +46: +err3; lbz r0,0(r4) + addir4,r4,1 +err3; stb r0,0(r3) + addir3,r3,1 + bdnz46b + li r3,0 + blr + +.Ldone: + mfctr r3 + blr + + +_GLOBAL(memcpy_mcsafe) + mr r7,r5 + cmpldi r5,16 + blt .Lshort_copy + +.Lcopy: + /* Get the source 8B aligned */ + neg r6,r4 + mtocrf 0x01,r6 + clrldi r6,r6,(64-3) + + bf cr7*4+3,1f +err1; lbz r0,0(r4) + addir4,r4,1 +err1; stb r0,0(r3) + addir3,r3,1 + subir7,r7,1 + +1: bf cr7*4+2,2f +err1; lhz r0,0(r4) + addir4,r4,2 +err1; sth r0,0(r3) + addir3,r3,2 + subir7,r7,2 + +2: bf cr7*4+1,3f +err1; lwz r0,0(r4) + addir4,r4,4 +err1; stw r0,0(r3) + addir3,r3,4 + subir7,r7,4 + +3: sub r5,r5,r6 + cmpldi r5,128 + blt 5f + + mflrr0 + stdur1,-STACKFRAMESIZE(r1) + std r14,STK_REG(R14)(r1) + std r15,STK_REG(R15)(r1) + std r16,STK_REG(R16)(r1) + std r17,STK_REG(R17)(r1) + std r18,STK_REG(R18)(r1) + std r19,STK_REG(R19)(r1) + std r20,STK_REG(R20)(r1) + std r21,STK_REG(R21)(r1) + std r22,STK_REG(R22)(r1) + std r0,STACKFRAMESIZE+16(r1) + + srdir6,r5,7 + mtctr r6 + + /* Now do cacheline (128B) sized loads and stores. */ + .align 5 +4: +err2; ld r0,0(r4) +err2; ld r6,8(r4) +err2; ld r8,16(r4) +err2; ld r9,24(r4) +err2; ld r10,32(r4) +err2; ld r11,40(r4) +err2; ld r12,48(r4) +err2; ld r14,56(r4) +err2; ld r15,64(r4) +err2; ld
[PATCH v11 7/7] powerpc: add machine check safe copy_to_user
Use memcpy_mcsafe() implementation to define copy_to_user_mcsafe()
Signed-off-by: Santosh Sivaraj
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/uaccess.h | 14 ++
2 files changed, 15 insertions(+)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index d8dcd8820369..39c738aa600a 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -136,6 +136,7 @@ config PPC
select ARCH_HAS_STRICT_KERNEL_RWX if ((PPC_BOOK3S_64 || PPC32) &&
!RELOCATABLE && !HIBERNATION)
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAS_UACCESS_FLUSHCACHE if PPC64
+ select ARCH_HAS_UACCESS_MCSAFE if PPC64
select ARCH_HAS_UBSAN_SANITIZE_ALL
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select ARCH_KEEP_MEMBLOCK
diff --git a/arch/powerpc/include/asm/uaccess.h
b/arch/powerpc/include/asm/uaccess.h
index 8b03eb44e876..15002b51ff18 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -387,6 +387,20 @@ static inline unsigned long raw_copy_to_user(void __user
*to,
return ret;
}
+static __always_inline unsigned long __must_check
+copy_to_user_mcsafe(void __user *to, const void *from, unsigned long n)
+{
+ if (likely(check_copy_size(from, n, true))) {
+ if (access_ok(to, n)) {
+ allow_write_to_user(to, n);
+ n = memcpy_mcsafe((void *)to, from, n);
+ prevent_write_to_user(to, n);
+ }
+ }
+
+ return n;
+}
+
extern unsigned long __clear_user(void __user *addr, unsigned long size);
static inline unsigned long clear_user(void __user *addr, unsigned long size)
--
2.21.0
Re: [PATCH v2 1/2] dt-bindings: media: Add YAML schemas for the generic RC bindings
On Mon, Aug 19, 2019 at 08:26:18PM +0200, Maxime Ripard wrote: > From: Maxime Ripard > > The RC controllers have a bunch of generic properties that are needed in a > device tree. Add a YAML schemas for those. > > Reviewed-by: Rob Herring > Signed-off-by: Maxime Ripard For the series (both 1/2 and 2.2): Reviewed-by: Sean Young How's tree should this go through? Thanks Sean > > --- > > Changes from v1: > - Update the list of valid RC map name > --- > .../devicetree/bindings/media/rc.txt | 118 +- > .../devicetree/bindings/media/rc.yaml | 145 ++ > 2 files changed, 146 insertions(+), 117 deletions(-) > create mode 100644 Documentation/devicetree/bindings/media/rc.yaml > > diff --git a/Documentation/devicetree/bindings/media/rc.txt > b/Documentation/devicetree/bindings/media/rc.txt > index d3e7a012bfda..be629f7fa77e 100644 > --- a/Documentation/devicetree/bindings/media/rc.txt > +++ b/Documentation/devicetree/bindings/media/rc.txt > @@ -1,117 +1 @@ > -The following properties are common to the infrared remote controllers: > - > -- linux,rc-map-name: string, specifies the scancode/key mapping table > - defined in-kernel for the remote controller. Support values are: > - * "rc-adstech-dvb-t-pci" > - * "rc-alink-dtu-m" > - * "rc-anysee" > - * "rc-apac-viewcomp" > - * "rc-asus-pc39" > - * "rc-asus-ps3-100" > - * "rc-ati-tv-wonder-hd-600" > - * "rc-ati-x10" > - * "rc-avermedia-a16d" > - * "rc-avermedia-cardbus" > - * "rc-avermedia-dvbt" > - * "rc-avermedia-m135a" > - * "rc-avermedia-m733a-rm-k6" > - * "rc-avermedia-rm-ks" > - * "rc-avermedia" > - * "rc-avertv-303" > - * "rc-azurewave-ad-tu700" > - * "rc-behold-columbus" > - * "rc-behold" > - * "rc-budget-ci-old" > - * "rc-cec" > - * "rc-cinergy-1400" > - * "rc-cinergy" > - * "rc-delock-61959" > - * "rc-dib0700-nec" > - * "rc-dib0700-rc5" > - * "rc-digitalnow-tinytwin" > - * "rc-digittrade" > - * "rc-dm1105-nec" > - * "rc-dntv-live-dvbt-pro" > - * "rc-dntv-live-dvb-t" > - * "rc-dtt200u" > - * "rc-dvbsky" > - * "rc-empty" > - * "rc-em-terratec" > - * "rc-encore-enltv2" > - * "rc-encore-enltv-fm53" > - * "rc-encore-enltv" > - * "rc-evga-indtube" > - * "rc-eztv" > - * "rc-flydvb" > - * "rc-flyvideo" > - * "rc-fusionhdtv-mce" > - * "rc-gadmei-rm008z" > - * "rc-geekbox" > - * "rc-genius-tvgo-a11mce" > - * "rc-gotview7135" > - * "rc-hauppauge" > - * "rc-imon-mce" > - * "rc-imon-pad" > - * "rc-iodata-bctv7e" > - * "rc-it913x-v1" > - * "rc-it913x-v2" > - * "rc-kaiomy" > - * "rc-kworld-315u" > - * "rc-kworld-pc150u" > - * "rc-kworld-plus-tv-analog" > - * "rc-leadtek-y04g0051" > - * "rc-lirc" > - * "rc-lme2510" > - * "rc-manli" > - * "rc-medion-x10" > - * "rc-medion-x10-digitainer" > - * "rc-medion-x10-or2x" > - * "rc-msi-digivox-ii" > - * "rc-msi-digivox-iii" > - * "rc-msi-tvanywhere-plus" > - * "rc-msi-tvanywhere" > - * "rc-nebula" > - * "rc-nec-terratec-cinergy-xs" > - * "rc-norwood" > - * "rc-npgtech" > - * "rc-pctv-sedna" > - * "rc-pinnacle-color" > - * "rc-pinnacle-grey" > - * "rc-pinnacle-pctv-hd" > - * "rc-pixelview-new" > - * "rc-pixelview" > - * "rc-pixelview-002t" > - * "rc-pixelview-mk12" > - * "rc-powercolor-real-angel" > - * "rc-proteus-2309" > - * "rc-purpletv" > - * "rc-pv951" > - * "rc-hauppauge" > - * "rc-rc5-tv" > - * "rc-rc6-mce" > - * "rc-real-audio-220-32-keys" > - * "rc-reddo" > - * "rc-snapstream-firefly" > - * "rc-streamzap" > - * "rc-tbs-nec" > - * "rc-technisat-ts35" > - * "rc-technisat-usb2" > - * "rc-terratec-cinergy-c-pci" > - * "rc-terratec-cinergy-s2-hd" > - * "rc-terratec-cinergy-xs" > - * "rc-terratec-slim" > - * "rc-terratec-slim-2" > - * "rc-tevii-nec" > - * "rc-tivo" > - * "rc-total-media-in-hand" > - * "rc-total-media-in-hand-02" > - * "rc-trekstor" > - * "rc-tt-1500" > - * "rc-twinhan-dtv-cab-ci" > - * "rc-twinhan1027" > - * "rc-videomate-k100" > - * "rc-videomate-s350" > - * "rc-videomate-tv-pvr" > - * "rc-winfast" > - * "rc-winfast-usbii-deluxe" > - * "rc-su3000" > +This file has been moved to rc.yaml. > diff --git a/Documentation/devicetree/bindings/media/rc.yaml > b/Documentation/devicetree/bindings/media/rc.yaml > new file mode 100644 > index ..3d5c154fd230 > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/rc.yaml > @@ -0,0 +1,145 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/media/rc.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Generic Infrared Remote Controller Device Tree Bindings > + > +maintainers: > + - Mauro Carvalho Chehab > + - Sean Young > + > +properties: > + $nodename: > +pattern: "^ir(@[a-f0-9]+)?$" > + > + linux,rc-map-name: > +description: > + Specifies the scancode/key mapping table defined in-kernel for > + the remote controller. > +allOf: > + - $ref: '/schemas/types.yaml#/definitions/string' > +
Re: [PATCH v4 05/10] ARM: dts: sunxi: a80: Add msgbox node
Hi, On Mon, Aug 19, 2019 at 10:23:06PM -0500, Samuel Holland wrote: > The A80 SoC contains a message box that can be used to send messages and > interrupts back and forth between the ARM application CPUs and the ARISC > coprocessor. Add a device tree node for it. > > Signed-off-by: Samuel Holland I think you mentionned that crust has been tested only on the A64 and the H3/H5, did you test the mailbox on those other SoCs as well? Thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
numlist_pop(): Re: [RFC PATCH v4 1/9] printk-rb: add a new printk ringbuffer implementation
On Thu 2019-08-08 00:32:26, John Ogness wrote:
> --- /dev/null
> +++ b/kernel/printk/numlist.c
> +/**
> + * numlist_pop() - Remove the oldest node from the list.
> + *
> + * @nl: The numbered list from which to remove the tail node.
> + *
> + * The tail node can only be removed if two conditions are satisfied:
> + *
> + * * The node is not the only node on the list.
> + * * The node is not busy.
> + *
> + * If, during this function, another task removes the tail, this function
> + * will try again with the new tail.
> + *
> + * Return: The removed node or NULL if the tail node cannot be removed.
> + */
> +struct nl_node *numlist_pop(struct numlist *nl)
> +{
> + unsigned long tail_id;
> + unsigned long next_id;
> + unsigned long r;
> +
> + /* cA: #1 */
> + tail_id = atomic_long_read(>tail_id);
> +
> + for (;;) {
> + /* cB */
> + while (!numlist_read(nl, tail_id, NULL, _id)) {
> + /*
> + * @tail_id is invalid. Try again with an
> + * updated value.
> + */
> +
> + cpu_relax();
> +
> + /* cA: #2 */
> + tail_id = atomic_long_read(>tail_id);
> + }
The above while-cycle basically does the same as the upper for-cycle.
It tries again with freshly loaded nl->tail_id. The following code
looks easier to follow:
do {
tail_id = atomic_long_read(>tail_id);
/*
* Read might fail when the tail node has been removed
* and reused in parallel.
*/
if (!numlist_read(nl, tail_id, NULL, _id))
continue;
/* Make sure the node is not the only node on the list. */
if (next_id == tail_id)
return NULL;
/* cC: Make sure the node is not busy. */
if (nl->busy(tail_id, nl->busy_arg))
return NULL;
while (atomic_long_cmpxchg_relaxed(>tail_id, tail_id, next_id) !=
tail_id);
/* This should never fail. The node is ours. */
return nl->node(tail_id, nl->node_arg);
> + /* Make sure the node is not the only node on the list. */
> + if (next_id == tail_id)
> + return NULL;
> +
> + /*
> + * cC:
> + *
> + * Make sure the node is not busy.
> + */
> + if (nl->busy(tail_id, nl->busy_arg))
> + return NULL;
> +
> + r = atomic_long_cmpxchg_relaxed(>tail_id,
> + tail_id, next_id);
> + if (r == tail_id)
> + break;
> +
> + /* cA: #3 */
> + tail_id = r;
> + }
> +
> + return nl->node(tail_id, nl->node_arg);
If I get it correctly, the above nl->node() call should never fail.
The node has been removed from the list and nobody else could
touch it. It is pretty useful information and it might be worth
mention it in a comment.
Best Regards,
Petr
PS: I am scratching my head around the patchset. I'll try Peter's
approach and comment independent things is separate mails.
Re: [Linux-kernel-mentees][PATCH v6 1/2] sgi-gru: Convert put_page() to put_user_page*()
On Mon 19-08-19 12:30:18, John Hubbard wrote: > On 8/19/19 12:06 PM, Bharath Vedartham wrote: > > On Mon, Aug 19, 2019 at 07:56:11AM -0500, Dimitri Sivanich wrote: > > > Reviewed-by: Dimitri Sivanich > > Thanks! > > > > John, would you like to take this patch into your miscellaneous > > conversions patch set? > > > > (+Andrew and Michal, so they know where all this is going.) > > Sure, although that conversion series [1] is on a brief hold, because > there are additional conversions desired, and the API is still under > discussion. Also, reading between the lines of Michal's response [2] > about it, I think people would prefer that the next revision include > the following, for each conversion site: > > Conversion of gup/put_page sites: > > Before: > > get_user_pages(...); > ... > for each page: > put_page(); > > After: > > gup_flags |= FOLL_PIN; (maybe FOLL_LONGTERM in some cases) > vaddr_pin_user_pages(...gup_flags...) I was hoping that FOLL_PIN would be handled by vaddr_pin_user_pages. > ... > vaddr_unpin_user_pages(); /* which invokes put_user_page() */ > > Fortunately, it's not harmful for the simpler conversion from put_page() > to put_user_page() to happen first, and in fact those have usually led > to simplifications, paving the way to make it easier to call > vaddr_unpin_user_pages(), once it's ready. (And showing exactly what > to convert, too.) If that makes the later conversion easier then no real objections from me. Assuming that the current put_user_page conversions are correct of course (I have the mlock one and potentials that falls into the same category in mind). -- Michal Hocko SUSE Labs
assign_desc() barriers: Re: [RFC PATCH v4 1/9] printk-rb: add a new printk ringbuffer implementation
On Thu 2019-08-08 00:32:26, John Ogness wrote:
> --- /dev/null
> +++ b/kernel/printk/ringbuffer.c
> +/**
> + * assign_desc() - Assign a descriptor to the caller.
> + *
> + * @e: The entry structure to store the assigned descriptor to.
> + *
> + * Find an available descriptor to assign to the caller. First it is checked
> + * if the tail descriptor from the committed list can be recycled. If not,
> + * perhaps a never-used descriptor is available. Otherwise, data blocks will
> + * be invalidated until the tail descriptor from the committed list can be
> + * recycled.
> + *
> + * Assigned descriptors are invalid until data has been reserved for them.
> + *
> + * Return: true if a descriptor was assigned, otherwise false.
> + *
> + * This will only fail if it was not possible to invalidate data blocks in
> + * order to recycle a descriptor. This can happen if a writer has reserved
> but
> + * not yet committed data and that reserved data is currently the oldest
> data.
> + */
> +static bool assign_desc(struct prb_reserved_entry *e)
> +{
> + struct printk_ringbuffer *rb = e->rb;
> + struct prb_desc *d;
> + struct nl_node *n;
> + unsigned long i;
> +
> + for (;;) {
> + /*
> + * jA:
> + *
> + * Try to recycle a descriptor on the committed list.
> + */
> + n = numlist_pop(>nl);
> + if (n) {
> + d = container_of(n, struct prb_desc, list);
> + break;
> + }
> +
> + /* Fallback to static never-used descriptors. */
> + if (atomic_read(>desc_next_unused) < DESCS_COUNT(rb)) {
> + i = atomic_fetch_inc(>desc_next_unused);
> + if (i < DESCS_COUNT(rb)) {
> + d = >descs[i];
> + atomic_long_set(>id, i);
> + break;
> + }
> + }
> +
> + /*
> + * No descriptor available. Make one available for recycling
> + * by invalidating data (which some descriptor will be
> + * referencing).
> + */
> + if (!dataring_pop(>dr))
> + return false;
> + }
> +
> + /*
> + * jB:
> + *
> + * Modify the descriptor ID so that users of the descriptor see that
> + * it has been recycled. A _release() is used so that prb_getdesc()
> + * callers can see all data ringbuffer updates after issuing a
> + * pairing smb_rmb(). See iA for details.
> + *
> + * Memory barrier involvement:
> + *
> + * If dB->iA reads from jB, then dI reads the same value as
> + * jA->cD->hA.
> + *
> + * Relies on:
> + *
> + * RELEASE from jA->cD->hA to jB
> + *matching
> + * RMB between dB->iA and dI
> + */
> + atomic_long_set_release(>id, atomic_long_read(>id) +
> + DESCS_COUNT(rb));
atomic_long_set_release() might be a bit confusing here.
There is no related acquire.
In fact, d->id manipulation has barriers from both sides:
+ smp_rmb() before so that all reads are finished before
the id is updated (release)
+ smp_wmb() after so that the new ID is written before other
related values are modified (acquire).
The smp_wmb() barrier is in prb_reserve(). I would move it here.
Best Regards,
Petr
> +
> + e->desc = d;
> + return true;
> +}
> +
> +/**
> + * prb_reserve() - Reserve data in the ringbuffer.
> + *
> + * @e:The entry structure to setup.
> + *
> + * @rb: The ringbuffer to reserve data in.
> + *
> + * @size: The size of the data to reserve.
> + *
> + * This is the public function available to writers to reserve data.
> + *
> + * Context: Any context. Disables local interrupts on success.
> + * Return: A pointer to the reserved data or an ERR_PTR if data could not be
> + * reserved.
> + *
> + * If the provided size is legal, this will only fail if it was not possible
> + * to invalidate the oldest data block. This can happen if a writer has
> + * reserved but not yet committed data and that reserved data is currently
> + * the oldest data.
> + *
> + * The ERR_PTR values and their meaning:
> + *
> + * * -EINVAL: illegal @size value
> + * * -EBUSY: failed to reserve a descriptor (@fail count incremented)
> + * * -ENOMEM: failed to reserve data (invalid descriptor committed)
> + */
> +char *prb_reserve(struct prb_reserved_entry *e, struct printk_ringbuffer *rb,
> + unsigned int size)
> +{
> + struct prb_desc *d;
> + unsigned long id;
> + char *buf;
> +
> + if (!dataring_checksize(>dr, size))
> + return ERR_PTR(-EINVAL);
> +
> + e->rb = rb;
> +
> + /*
> + * Disable interrupts during the reserve/commit window in order to
> + * minimize the number of reserved but not yet committed data blocks
> + * in the data ringbuffer.
Re: [PATCH 0/3] fix interrupt swamp in NVMe
On Tue, Aug 20, 2019 at 2:14 PM wrote: > > From: Long Li > > This patch set tries to fix interrupt swamp in NVMe devices. > > On large systems with many CPUs, a number of CPUs may share one NVMe hardware > queue. It may have this situation where several CPUs are issuing I/Os, and > all the I/Os are returned on the CPU where the hardware queue is bound to. > This may result in that CPU swamped by interrupts and stay in interrupt mode > for extended time while other CPUs continue to issue I/O. This can trigger > Watchdog and RCU timeout, and make the system unresponsive. > > This patch set addresses this by enforcing scheduling and throttling I/O when > CPU is starved in this situation. > > Long Li (3): > sched: define a function to report the number of context switches on a > CPU > sched: export idle_cpu() > nvme: complete request in work queue on CPU with flooded interrupts > > drivers/nvme/host/core.c | 57 +++- > drivers/nvme/host/nvme.h | 1 + > include/linux/sched.h| 2 ++ > kernel/sched/core.c | 7 + > 4 files changed, 66 insertions(+), 1 deletion(-) Another simpler solution may be to complete request in threaded interrupt handler for this case. Meantime allow scheduler to run the interrupt thread handler on CPUs specified by the irq affinity mask, which was discussed by the following link: https://lore.kernel.org/lkml/e0e9478e-62a5-ca24-3b12-58f7d0563...@huawei.com/ Could you try the above solution and see if the lockup can be avoided? John Garry should have workable patch. Thanks, Ming Lei
Re: [PATCH] csky: Fixup ioremap function losing
On Mon, Aug 19, 2019 at 2:21 AM Christoph Hellwig wrote: > > On Sun, Aug 18, 2019 at 10:20:18AM +0800, Guo Ren wrote: > > > > Also change flag VM_ALLOC to VM_IOREMAP in get_vm_area_caller. > > > > > > Looks generally fine, but two comments: > > > > > > - do you have a need for ioremap_cache? We are generally try to > > >phase it out in favour of memremap, and it is generally only used > > >by arch specific code. > > Yes, some drivers of our customers use ioremap_cache to map phy_addr > > which isn't belong to system memory. > > Which driver? We should move it over to memremap instead of adding > a new ioremap_cache. The driver hasn't been upstreamed. OK, just remove ioremap_cache and seems it's not a big problem. -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
Re: [PATCH v4 04/10] mailbox: sunxi-msgbox: Add a new mailbox driver
Hi, On Mon, Aug 19, 2019 at 10:23:05PM -0500, Samuel Holland wrote: > Allwinner sun8i, sun9i, and sun50i SoCs contain a hardware message box > used for communication between the ARM CPUs and the ARISC management > coprocessor. The hardware contains 8 unidirectional 4-message FIFOs. > > Add a driver for it, so it can be used for SCPI or other communication > protocols. > > Signed-off-by: Samuel Holland > --- > drivers/mailbox/Kconfig| 10 + > drivers/mailbox/Makefile | 2 + > drivers/mailbox/sunxi-msgbox.c | 323 + > 3 files changed, 335 insertions(+) > create mode 100644 drivers/mailbox/sunxi-msgbox.c It's pretty much the same remark than for the name of the binding file, but sunxi in itself is pretty confusing, it covers a range of SoCs going from armv5 to armv8, some with a single CPU and some with more, and some with an OpenRISC core and some without. It would be less confusing (albeit not perfect) to use sun6i there, the family that IP was first introduced in. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [RT PATCH v2] net/xfrm/xfrm_ipcomp: Protect scratch buffer with local_lock
On 2019-08-19 14:27:31 [+0200], Juri Lelli wrote: > This v2 applies to v4.19.59-rt24. Looks good, I suggest to apply this to v4.19 and earlier. For v5.2 and later (including upstream) please send a patch to simply replace get_cpu() with smp_processor_id(). The reason is that get_cpu() will not disable BH and according to the call path this function is invoked in NAPI callback and the other sides does local_bh_disable(). Therefore the caller of this must ensure that BH is disabled and disabling preemption is not enough. Sebastian
Re: [PATCH v2 11/11] vsock_test: wait for the remote to close the connection
On Thu, Aug 01, 2019 at 05:25:41PM +0200, Stefano Garzarella wrote:
> +/* Wait for the remote to close the connection */
> +void vsock_wait_remote_close(int fd)
> +{
> + struct epoll_event ev;
> + int epollfd, nfds;
> +
> + epollfd = epoll_create1(0);
> + if (epollfd == -1) {
> + perror("epoll_create1");
> + exit(EXIT_FAILURE);
> + }
> +
> + ev.events = EPOLLRDHUP | EPOLLHUP;
> + ev.data.fd = fd;
> + if (epoll_ctl(epollfd, EPOLL_CTL_ADD, fd, ) == -1) {
> + perror("epoll_ctl");
> + exit(EXIT_FAILURE);
> + }
> +
> + nfds = epoll_wait(epollfd, , 1, TIMEOUT * 1000);
> + if (nfds == -1) {
> + perror("epoll_wait");
> + exit(EXIT_FAILURE);
> + }
> +
> + if (nfds == 0) {
> + fprintf(stderr, "epoll_wait timed out\n");
> + exit(EXIT_FAILURE);
> + }
> +
> + assert(nfds == 1);
> + assert(ev.events & (EPOLLRDHUP | EPOLLHUP));
> + assert(ev.data.fd == fd);
> +
> + close(epollfd);
> +}
Please use timeout_begin()/timeout_end() so that the test cannot hang.
> diff --git a/tools/testing/vsock/vsock_test.c
> b/tools/testing/vsock/vsock_test.c
> index 64adf45501ca..a664675bec5a 100644
> --- a/tools/testing/vsock/vsock_test.c
> +++ b/tools/testing/vsock/vsock_test.c
> @@ -84,6 +84,11 @@ static void test_stream_client_close_server(const struct
> test_opts *opts)
>
> control_expectln("CLOSED");
>
> + /* Wait for the remote to close the connection, before check
> + * -EPIPE error on send.
> + */
> + vsock_wait_remote_close(fd);
Is control_expectln("CLOSED") still necessary now that we're waiting for
the poll event? The control message was an attempt to wait until the
other side closed the socket.
signature.asc
Description: PGP signature
[PATCH v2 0/2] dt-bindings: serial: lantiq: Convert to YAML & add support for new SoC
There is a new product which reuses Lantiq serial controller IP. Patch 1 in this series converts existing lantiq dt bindings to YAML schema and Patch 2 updates it to support newer product. These patches are baselined upon Linux 5.3-rc4 at below Git tree: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git v2: * Update license to GPL-2.0-only. * Fix trailing whitespace error. Rahul Tanwar (2): dt-bindings: serial: lantiq: Convert to YAML schema dt-bindings: lantiq: Update for new SoC .../devicetree/bindings/serial/lantiq_asc.txt | 31 .../devicetree/bindings/serial/lantiq_asc.yaml | 87 ++ 2 files changed, 87 insertions(+), 31 deletions(-) delete mode 100644 Documentation/devicetree/bindings/serial/lantiq_asc.txt create mode 100644 Documentation/devicetree/bindings/serial/lantiq_asc.yaml -- 2.11.0
[PATCH v2 2/2] dt-bindings: lantiq: Update for new SoC
Intel Lightning Mountain(LGM) SoC reuses Lantiq ASC serial controller IP.
Update the dt bindings to support LGM as well.
Signed-off-by: Rahul Tanwar
---
.../devicetree/bindings/serial/lantiq_asc.yaml | 17 +
1 file changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/lantiq_asc.yaml
b/Documentation/devicetree/bindings/serial/lantiq_asc.yaml
index 54b90490f4fb..92807b59b024 100644
--- a/Documentation/devicetree/bindings/serial/lantiq_asc.yaml
+++ b/Documentation/devicetree/bindings/serial/lantiq_asc.yaml
@@ -17,6 +17,7 @@ properties:
oneOf:
items:
- const: lantiq,asc
+- const: intel,lgm-asc
reg:
maxItems: 1
@@ -28,6 +29,12 @@ properties:
- description: tx or combined interrupt
- description: rx interrupt
- description: err interrupt
+description:
+ For lantiq,asc compatible, it supports 3 separate
+ interrupts for tx rx & err. Whereas, for intel,lgm-asc
+ compatible, it supports combined single interrupt for
+ all of tx, rx & err interrupts.
+
clocks:
description:
@@ -67,4 +74,14 @@ examples:
interrupts = <112 113 114>;
};
+ - |
+asc0: serial@e0a0 {
+compatible = "intel,lgm-asc";
+reg = <0xe0a0 0x1000>;
+interrupt-parent = <>;
+interrupts = <128 1>;
+clocks = < LGM_CLK_NOC4>, < LGM_GCLK_ASC0>;
+clock-names = "freq", "asc";
+};
+
...
--
2.11.0
Re: iwlwifi: microcode SW error detected
On 18/08/2019 09:21, Chris Clayton wrote: > > > On 17/08/2019 08:19, Chris Clayton wrote: >> Hi. >> >> I just found the following error in the output from dmesg. >> >> [ 4023.460058] iwlwifi :02:00.0: Microcode SW error detected. Restarting >> 0x0. > > Since reporting, I've found that this problem is being explored in the thread > that starts at > https://marc.info/?l=linux-kernel=15660151913. Mmm, that's a dead link. Don't knwo what happened there but the real link is https://marc.info/?l=linux-kernel=156265244614126 > > Chris >
[PATCH v2 1/2] dt-bindings: serial: lantiq: Convert to YAML schema
Convert the existing DT binding document for Lantiq SoC ASC serial controller
from txt format to YAML format.
Signed-off-by: Rahul Tanwar
---
.../devicetree/bindings/serial/lantiq_asc.txt | 31 --
.../devicetree/bindings/serial/lantiq_asc.yaml | 70 ++
2 files changed, 70 insertions(+), 31 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/serial/lantiq_asc.txt
create mode 100644 Documentation/devicetree/bindings/serial/lantiq_asc.yaml
diff --git a/Documentation/devicetree/bindings/serial/lantiq_asc.txt
b/Documentation/devicetree/bindings/serial/lantiq_asc.txt
deleted file mode 100644
index 40e81a5818f6..
--- a/Documentation/devicetree/bindings/serial/lantiq_asc.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-Lantiq SoC ASC serial controller
-
-Required properties:
-- compatible : Should be "lantiq,asc"
-- reg : Address and length of the register set for the device
-- interrupts: the 3 (tx rx err) interrupt numbers. The interrupt specifier
- depends on the interrupt-parent interrupt controller.
-
-Optional properties:
-- clocks: Should contain frequency clock and gate clock
-- clock-names: Should be "freq" and "asc"
-
-Example:
-
-asc0: serial@1660 {
- compatible = "lantiq,asc";
- reg = <0x1660 0x10>;
- interrupt-parent = <>;
- interrupts = ,
- ,
- ;
- clocks = < CLK_SSX4>, < GCLK_UART>;
- clock-names = "freq", "asc";
-};
-
-asc1: serial@e100c00 {
- compatible = "lantiq,asc";
- reg = <0xE100C00 0x400>;
- interrupt-parent = <>;
- interrupts = <112 113 114>;
-};
diff --git a/Documentation/devicetree/bindings/serial/lantiq_asc.yaml
b/Documentation/devicetree/bindings/serial/lantiq_asc.yaml
new file mode 100644
index ..54b90490f4fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/lantiq_asc.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/lantiq_asc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lantiq SoC ASC serial controller
+
+maintainers:
+ - Rahul Tanwar
+
+allOf:
+ - $ref: /schemas/serial.yaml#
+
+properties:
+ compatible:
+oneOf:
+ items:
+- const: lantiq,asc
+
+ reg:
+maxItems: 1
+
+ interrupts:
+minItems: 1
+maxItems: 3
+items:
+ - description: tx or combined interrupt
+ - description: rx interrupt
+ - description: err interrupt
+
+ clocks:
+description:
+ When present, first entry listed should contain phandle
+ to the frequency clock and second entry should contain
+ phandle to the gate clock.
+
+ clock-names:
+items:
+ - const: freq
+ - const: asc
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+
+examples:
+ - |
+asc0: serial@1660 {
+compatible = "lantiq,asc";
+reg = <0x1660 0x10>;
+interrupt-parent = <>;
+interrupts = ,
+ ,
+ ;
+clocks = < CLK_SSX4>, < GCLK_UART>;
+clock-names = "freq", "asc";
+};
+
+ - |
+asc1: serial@e100c00 {
+compatible = "lantiq,asc";
+reg = <0xE100C00 0x400>;
+interrupt-parent = <>;
+interrupts = <112 113 114>;
+};
+
+...
--
2.11.0
Re: [PATCH v3] gpio: pl061: Fix the issue failed to register the ACPI interrtupion
On Tue, Aug 20, 2019 at 10:12 AM Linus Walleij wrote: > > On Mon, Aug 19, 2019 at 5:07 PM Andy Shevchenko > wrote: > > > The proper fix is to revert the culprit since we call > > acpi_gpiochip_request_interrupts() for all controllers. > > Linus, please re-do the approach with IRQ handling, > > Exactly what do you refer to when you want me to > "re-do the approach for IRQ handling"? Do you mean > this driver or are you referring to: > > commit e0d89728981393b7d694bd3419b7794b9882c92d > Author: Thierry Reding > Date: Tue Nov 7 19:15:54 2017 +0100 > > gpio: Implement tighter IRQ chip integration > > Currently GPIO drivers are required to add the GPIO chip and its > corresponding IRQ chip separately, which can result in a lot of > boilerplate. Use the newly introduced struct gpio_irq_chip, embedded in > struct gpio_chip, that drivers can fill in if they want the GPIO core > to automatically register the IRQ chip associated with a GPIO chip. > > Signed-off-by: Thierry Reding > Acked-by: Grygorii Strashko > Signed-off-by: Linus Walleij > > The new API introduced by this patch is what I am trying to switch > everything over to, because the forked paths inside of gpiolib > is causing me a maintenance headache and also increasing > the footprint of the library. > > > it seems broadly > > regress with ACPI enabled platforms. > > It only becomes a problem if the platform uses ACPI right? > But it's a problem if I can't really tell if a driver is using > ACPI or not, there is no sign in the pl061 driver that it would > be used on ACPI systems until now, so how do I design > for it? > > The problem comes from the problem/mess I am trying to > clean up in the first place. So if the new way of registering GPIO > irqchips is not working for ACPI, then we have to fix that instead > of reverting all attempts to use the new API IMO. > > Yours, > Linus Walleij -- With Best Regards, Andy Shevchenko
Csapat motiváció
Üdvözlöm! Ahogyan az üzleti gyakorlat mutatja, a nem anyagi juttatások sajnos nem a leghatékonyabb módjai annak, hogy növeljük az alkalmazottak motivációját vagy a munka iránti elköteleződésüket! Az alkalmazottakkal szemben tanúsított lojalitás jelenleg a legnagyobb kihívás a vállalkozások számára országunkban. Az foglalkoztatók rendelkezésre bocsájtanak, többek között, étkezési jegyeket, amelyek felhasználhatók bármilyen jellegű élelmiszer vásárlása esetén, valamint az internetes vásárlások alkalmával is. El tudja érni nem csupán a jobban motviált dolgozói csapatot, de ugyanakkor adóbefizetését is csökkentheti! Szeretne többet tudni a lehetőségről amely megoldásként szolgálhat Ön és kollégái számára? Kapolcs Mátyás Hungary Team Leader
Re: [PATCH v2 10/11] vsock_test: skip read() in test_stream*close tests on a VMCI host
On Thu, Aug 01, 2019 at 05:25:40PM +0200, Stefano Garzarella wrote: > When VMCI transport is used, if the guest closes a connection, > all data is gone and EOF is returned, so we should skip the read > of data written by the peer before closing the connection. All transports should aim for identical semantics. I think virtio-vsock should behave the same as VMCI since userspace applications should be transport-independent. Let's view this as a vsock bug. Is it feasible to change the VMCI behavior so it's more like TCP sockets? If not, let's change the virtio-vsock behavior to be compatible with VMCI. signature.asc Description: PGP signature
Re: [PATCH v5] perf diff: Report noisy for cycles diff
On Fri, Aug 16, 2019 at 10:13:43AM +0800, Jin Yao wrote:
SNIP
> static void
> hpp__entry_unpair(struct hist_entry *he, int idx, char *buf, size_t size)
> {
> @@ -1662,6 +1794,10 @@ static void data__hpp_register(struct data__file *d,
> int idx)
> fmt->color = hpp__color_cycles;
> fmt->sort = hist_entry__cmp_nop;
> break;
> + case PERF_HPP_DIFF__CYCLES_HIST:
> + fmt->color = hpp__color_cycles_hist;
> + fmt->sort = hist_entry__cmp_nop;
> + break;
> default:
> fmt->sort = hist_entry__cmp_nop;
> break;
> @@ -1688,8 +1824,13 @@ static int ui_init(void)
>* PERF_HPP_DIFF__RATIO
>* PERF_HPP_DIFF__WEIGHTED_DIFF
>*/
> - data__hpp_register(d, i ? compute_2_hpp[compute] :
> - PERF_HPP_DIFF__BASELINE);
> + if (cycles_hist && i && (compute == COMPUTE_CYCLES)) {
> + data__hpp_register(d, PERF_HPP_DIFF__CYCLES);
> + data__hpp_register(d, PERF_HPP_DIFF__CYCLES_HIST);
> + } else {
> + data__hpp_register(d, i ? compute_2_hpp[compute] :
> + PERF_HPP_DIFF__BASELINE);
> + }
hum, why can't it be just like we treat other extra columns:
---
@@ -1687,6 +1823,7 @@ static int ui_init(void)
* PERF_HPP_DIFF__DELTA
* PERF_HPP_DIFF__RATIO
* PERF_HPP_DIFF__WEIGHTED_DIFF
+* PERF_HPP_DIFF__CYCLES
*/
data__hpp_register(d, i ? compute_2_hpp[compute] :
PERF_HPP_DIFF__BASELINE);
@@ -1704,6 +1841,9 @@ static int ui_init(void)
if (show_period)
data__hpp_register(d, i ? PERF_HPP_DIFF__PERIOD :
PERF_HPP_DIFF__PERIOD_BASELINE);
+
+ if (cycles_hist && i)
+ data__hpp_register(d, PERF_HPP_DIFF__CYCLES_HIST);
thanks,
jirka
[PATCH v13 02/12] dt-binding: gce: add gce header file for mt8183
Add documentation for the mt8183 gce. Add gce header file defined the gce hardware event, subsys number and constant for mt8183. Signed-off-by: Bibby Hsieh Reviewed-by: Rob Herring --- .../devicetree/bindings/mailbox/mtk-gce.txt | 6 +- include/dt-bindings/gce/mt8183-gce.h | 175 ++ 2 files changed, 178 insertions(+), 3 deletions(-) create mode 100644 include/dt-bindings/gce/mt8183-gce.h diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt index cfe40b01d164..1f7f8f2a3f49 100644 --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt @@ -9,7 +9,7 @@ CMDQ driver uses mailbox framework for communication. Please refer to mailbox.txt for generic information about mailbox device-tree bindings. Required properties: -- compatible: Must be "mediatek,mt8173-gce" +- compatible: can be "mediatek,mt8173-gce" or "mediatek,mt8183-gce" - reg: Address range of the GCE unit - interrupts: The interrupt signal from the GCE block - clock: Clocks according to the common clock binding @@ -28,8 +28,8 @@ Required properties for a client device: - mediatek,gce-subsys: u32, specify the sub-system id which is corresponding to the register address. -Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h'. Such as -sub-system ids, thread priority, event ids. +Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h' +or 'dt-binding/gce/mt8183-gce.h'. Such as sub-system ids, thread priority, event ids. Example: diff --git a/include/dt-bindings/gce/mt8183-gce.h b/include/dt-bindings/gce/mt8183-gce.h new file mode 100644 index ..29c967476f73 --- /dev/null +++ b/include/dt-bindings/gce/mt8183-gce.h @@ -0,0 +1,175 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (c) 2019 MediaTek Inc. + * Author: Bibby Hsieh + * + */ + +#ifndef _DT_BINDINGS_GCE_MT8183_H +#define _DT_BINDINGS_GCE_MT8183_H + +#define CMDQ_NO_TIMEOUT0x + +/* GCE HW thread priority */ +#define CMDQ_THR_PRIO_LOWEST 0 +#define CMDQ_THR_PRIO_HIGHEST 1 + +/* GCE SUBSYS */ +#define SUBSYS_13000 +#define SUBSYS_14001 +#define SUBSYS_14012 +#define SUBSYS_14023 +#define SUBSYS_15024 +#define SUBSYS_18805 +#define SUBSYS_18816 +#define SUBSYS_18827 +#define SUBSYS_18838 +#define SUBSYS_18849 +#define SUBSYS_100010 +#define SUBSYS_100111 +#define SUBSYS_100212 +#define SUBSYS_100313 +#define SUBSYS_100414 +#define SUBSYS_100515 +#define SUBSYS_102016 +#define SUBSYS_102817 +#define SUBSYS_170018 +#define SUBSYS_170119 +#define SUBSYS_170220 +#define SUBSYS_170321 +#define SUBSYS_180022 +#define SUBSYS_180123 +#define SUBSYS_180224 +#define SUBSYS_180425 +#define SUBSYS_180526 +#define SUBSYS_180827 +#define SUBSYS_180a28 +#define SUBSYS_180b29 + +#define CMDQ_EVENT_DISP_RDMA0_SOF 0 +#define CMDQ_EVENT_DISP_RDMA1_SOF 1 +#define CMDQ_EVENT_MDP_RDMA0_SOF 2 +#define CMDQ_EVENT_MDP_RSZ0_SOF 4 +#define CMDQ_EVENT_MDP_RSZ1_SOF 5 +#define CMDQ_EVENT_MDP_TDSHP_SOF 6 +#define CMDQ_EVENT_MDP_WROT0_SOF 7 +#define CMDQ_EVENT_MDP_WDMA0_SOF 8 +#define CMDQ_EVENT_DISP_OVL0_SOF 9 +#define CMDQ_EVENT_DISP_OVL0_2L_SOF10 +#define CMDQ_EVENT_DISP_OVL1_2L_SOF11 +#define CMDQ_EVENT_DISP_WDMA0_SOF 12 +#define CMDQ_EVENT_DISP_COLOR0_SOF 13 +#define CMDQ_EVENT_DISP_CCORR0_SOF 14 +#define CMDQ_EVENT_DISP_AAL0_SOF 15 +#define CMDQ_EVENT_DISP_GAMMA0_SOF 16 +#define CMDQ_EVENT_DISP_DITHER0_SOF17 +#define CMDQ_EVENT_DISP_PWM0_SOF 18 +#define CMDQ_EVENT_DISP_DSI0_SOF 19 +#define CMDQ_EVENT_DISP_DPI0_SOF 20
[PATCH v13 06/12] soc: mediatek: cmdq: clear the event in cmdq initial flow
GCE hardware stored event information in own internal sysram,
if the initial value in those sysram is not zero value
it will cause a situation that gce can wait the event immediately
after client ask gce to wait event but not really trigger the
corresponding hardware.
In order to make sure that the wait event function is
exactly correct, we need to clear the sysram value in
cmdq initial flow.
Fixes: 623a6143a845 ("mailbox: mediatek: Add Mediatek CMDQ driver")
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/mailbox/mtk-cmdq-mailbox.c | 5 +
include/linux/mailbox/mtk-cmdq-mailbox.h | 2 ++
include/linux/soc/mediatek/mtk-cmdq.h| 3 ---
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
b/drivers/mailbox/mtk-cmdq-mailbox.c
index 69daaadc3a5f..9a6ce9f5a7db 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -21,6 +21,7 @@
#define CMDQ_NUM_CMD(t)(t->cmd_buf_size /
CMDQ_INST_SIZE)
#define CMDQ_CURR_IRQ_STATUS 0x10
+#define CMDQ_SYNC_TOKEN_UPDATE 0x68
#define CMDQ_THR_SLOT_CYCLES 0x30
#define CMDQ_THR_BASE 0x100
#define CMDQ_THR_SIZE 0x80
@@ -104,8 +105,12 @@ static void cmdq_thread_resume(struct cmdq_thread *thread)
static void cmdq_init(struct cmdq *cmdq)
{
+ int i;
+
WARN_ON(clk_enable(cmdq->clock) < 0);
writel(CMDQ_THR_ACTIVE_SLOT_CYCLES, cmdq->base + CMDQ_THR_SLOT_CYCLES);
+ for (i = 0; i <= CMDQ_MAX_EVENT; i++)
+ writel(i, cmdq->base + CMDQ_SYNC_TOKEN_UPDATE);
clk_disable(cmdq->clock);
}
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
b/include/linux/mailbox/mtk-cmdq-mailbox.h
index ccb73422c2fa..911475da7a53 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -19,6 +19,8 @@
#define CMDQ_WFE_UPDATEBIT(31)
#define CMDQ_WFE_WAIT BIT(15)
#define CMDQ_WFE_WAIT_VALUE0x1
+/** cmdq event maximum */
+#define CMDQ_MAX_EVENT 0x3ff
/*
* CMDQ_CODE_MASK:
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index 54ade13a9b15..4e8899972db4 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -13,9 +13,6 @@
#define CMDQ_NO_TIMEOUT0xu
-/** cmdq event maximum */
-#define CMDQ_MAX_EVENT 0x3ff
-
struct cmdq_pkt;
struct cmdq_client {
--
2.18.0
[PATCH v13 07/12] soc: mediatek: cmdq: reorder the parameter
The order of gce instructions is [subsys offset value]
so reorder the parameter of cmdq_pkt_write_mask
and cmdq_pkt_write function.
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 6 +++---
include/linux/soc/mediatek/mtk-cmdq.h | 10 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index ff9fef5a032b..082b8978651e 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -136,7 +136,7 @@ static int cmdq_pkt_append_command(struct cmdq_pkt *pkt,
enum cmdq_code code,
return 0;
}
-int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 value, u32 subsys, u32 offset)
+int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value)
{
u32 arg_a = (offset & CMDQ_ARG_A_WRITE_MASK) |
(subsys << CMDQ_SUBSYS_SHIFT);
@@ -145,8 +145,8 @@ int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 value, u32
subsys, u32 offset)
}
EXPORT_SYMBOL(cmdq_pkt_write);
-int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 value,
- u32 subsys, u32 offset, u32 mask)
+int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
+ u32 offset, u32 value, u32 mask)
{
u32 offset_mask = offset;
int err = 0;
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index 4e8899972db4..39d813dde4b4 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -60,26 +60,26 @@ void cmdq_pkt_destroy(struct cmdq_pkt *pkt);
/**
* cmdq_pkt_write() - append write command to the CMDQ packet
* @pkt: the CMDQ packet
- * @value: the specified target register value
* @subsys:the CMDQ sub system code
* @offset:register offset from CMDQ sub system
+ * @value: the specified target register value
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 value, u32 subsys, u32 offset);
+int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value);
/**
* cmdq_pkt_write_mask() - append write command with mask to the CMDQ packet
* @pkt: the CMDQ packet
- * @value: the specified target register value
* @subsys:the CMDQ sub system code
* @offset:register offset from CMDQ sub system
+ * @value: the specified target register value
* @mask: the specified target register mask
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 value,
- u32 subsys, u32 offset, u32 mask);
+int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
+ u32 offset, u32 value, u32 mask);
/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
--
2.18.0
[PATCH v13 09/12] soc: mediatek: cmdq: define the instruction struct
Define an instruction structure for gce driver to append command.
This structure can make the client's code more readability.
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 106 +++
include/linux/mailbox/mtk-cmdq-mailbox.h | 2 +
2 files changed, 74 insertions(+), 34 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 7aa0517ff2f3..cae6a794cc48 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -9,12 +9,24 @@
#include
#include
-#define CMDQ_ARG_A_WRITE_MASK 0x
#define CMDQ_WRITE_ENABLE_MASK BIT(0)
#define CMDQ_EOC_IRQ_ENBIT(0)
#define CMDQ_EOC_CMD ((u64)((CMDQ_CODE_EOC << CMDQ_OP_CODE_SHIFT)) \
<< 32 | CMDQ_EOC_IRQ_EN)
+struct cmdq_instruction {
+ union {
+ u32 value;
+ u32 mask;
+ };
+ union {
+ u16 offset;
+ u16 event;
+ };
+ u8 subsys;
+ u8 op;
+};
+
static void cmdq_client_timeout(struct timer_list *t)
{
struct cmdq_client *client = from_timer(client, t, timer);
@@ -110,10 +122,8 @@ void cmdq_pkt_destroy(struct cmdq_pkt *pkt)
}
EXPORT_SYMBOL(cmdq_pkt_destroy);
-static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
- u32 arg_a, u32 arg_b)
+static struct cmdq_instruction *cmdq_pkt_append_command(struct cmdq_pkt *pkt)
{
- u64 *cmd_ptr;
if (unlikely(pkt->cmd_buf_size + CMDQ_INST_SIZE > pkt->buf_size)) {
/*
@@ -127,81 +137,109 @@ static int cmdq_pkt_append_command(struct cmdq_pkt *pkt,
enum cmdq_code code,
pkt->cmd_buf_size += CMDQ_INST_SIZE;
WARN_ONCE(1, "%s: buffer size %u is too small !\n",
__func__, (u32)pkt->buf_size);
- return -ENOMEM;
+ return NULL;
}
- cmd_ptr = pkt->va_base + pkt->cmd_buf_size;
- (*cmd_ptr) = (u64)((code << CMDQ_OP_CODE_SHIFT) | arg_a) << 32 | arg_b;
+
pkt->cmd_buf_size += CMDQ_INST_SIZE;
+ *(u64 *)(pkt->va_base + pkt->cmd_buf_size) = 0;
- return 0;
+ return pkt->va_base + pkt->cmd_buf_size - CMDQ_INST_SIZE;
}
int cmdq_pkt_write(struct cmdq_pkt *pkt, u8 subsys, u16 offset, u32 value)
{
- u32 arg_a = (offset & CMDQ_ARG_A_WRITE_MASK) |
- (subsys << CMDQ_SUBSYS_SHIFT);
+ struct cmdq_instruction *inst;
+
+ inst = cmdq_pkt_append_command(pkt);
+ if (!inst)
+ return -ENOMEM;
+
+ inst->op = CMDQ_CODE_WRITE;
+ inst->value = value;
+ inst->offset = offset;
+ inst->subsys = subsys;
- return cmdq_pkt_append_command(pkt, CMDQ_CODE_WRITE, arg_a, value);
+ return 0;
}
EXPORT_SYMBOL(cmdq_pkt_write);
int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
u16 offset, u32 value, u32 mask)
{
- u32 offset_mask = offset;
- int err = 0;
+ struct cmdq_instruction *inst;
+ u16 offset_mask = offset;
if (mask != 0x) {
- err = cmdq_pkt_append_command(pkt, CMDQ_CODE_MASK, 0, ~mask);
+ inst = cmdq_pkt_append_command(pkt);
+ if (!inst)
+ return -ENOMEM;
+
+ inst->op = CMDQ_CODE_MASK;
+ inst->mask = ~mask;
offset_mask |= CMDQ_WRITE_ENABLE_MASK;
}
- err |= cmdq_pkt_write(pkt, value, subsys, offset_mask);
- return err;
+ return cmdq_pkt_write(pkt, subsys, offset_mask, value);
}
EXPORT_SYMBOL(cmdq_pkt_write_mask);
int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
- u32 arg_b;
+ struct cmdq_instruction *inst;
if (event >= CMDQ_MAX_EVENT)
return -EINVAL;
- /*
-* WFE arg_b
-* bit 0-11: wait value
-* bit 15: 1 - wait, 0 - no wait
-* bit 16-27: update value
-* bit 31: 1 - update, 0 - no update
-*/
- arg_b = CMDQ_WFE_UPDATE | CMDQ_WFE_WAIT | CMDQ_WFE_WAIT_VALUE;
+ inst = cmdq_pkt_append_command(pkt);
+ if (!inst)
+ return -ENOMEM;
+
+ inst->op = CMDQ_CODE_WFE;
+ inst->value = CMDQ_WFE_OPTION;
+ inst->event = event;
- return cmdq_pkt_append_command(pkt, CMDQ_CODE_WFE, event, arg_b);
+ return 0;
}
EXPORT_SYMBOL(cmdq_pkt_wfe);
int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
{
+ struct cmdq_instruction *inst;
+
if (event >= CMDQ_MAX_EVENT)
return -EINVAL;
- return cmdq_pkt_append_command(pkt, CMDQ_CODE_WFE, event,
- CMDQ_WFE_UPDATE);
+ inst = cmdq_pkt_append_command(pkt);
+ if (!inst)
+ return -ENOMEM;
+
+ inst->op = CMDQ_CODE_WFE;
+ inst->value =
[PATCH v13 01/12] dt-binding: gce: remove thread-num property
"thread-num" is an unused property so we remove it from example. Signed-off-by: Bibby Hsieh Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/mailbox/mtk-gce.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt index 7d72b21c9e94..cfe40b01d164 100644 --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt @@ -39,7 +39,6 @@ Example: interrupts = ; clocks = < CLK_INFRA_GCE>; clock-names = "gce"; - thread-num = CMDQ_THR_MAX_COUNT; #mbox-cells = <3>; }; -- 2.18.0
[PATCH v13 12/12] arm64: dts: add gce node for mt8183
add gce device node for mt8183
Signed-off-by: Bibby Hsieh
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 08274bfcebd8..a81c995bbea9 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
/ {
compatible = "mediatek,mt8183";
@@ -212,6 +213,15 @@
clock-names = "spi", "wrap";
};
+ gce: mailbox@10238000 {
+ compatible = "mediatek,mt8183-gce";
+ reg = <0 0x10238000 0 0x4000>;
+ interrupts = ;
+ #mbox-cells = <3>;
+ clocks = < CLK_INFRA_GCE>;
+ clock-names = "gce";
+ };
+
uart0: serial@11002000 {
compatible = "mediatek,mt8183-uart",
"mediatek,mt6577-uart";
--
2.18.0
[PATCH v13 04/12] mailbox: mediatek: cmdq: move the CMDQ_IRQ_MASK into cmdq driver data
The interrupt mask and thread number has positive correlation,
so we move the CMDQ_IRQ_MASK into cmdq driver data and calculate
it by thread number.
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/mailbox/mtk-cmdq-mailbox.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
b/drivers/mailbox/mtk-cmdq-mailbox.c
index 00d5219094e5..8fddd26288e8 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -18,7 +18,6 @@
#include
#define CMDQ_OP_CODE_MASK (0xff << CMDQ_OP_CODE_SHIFT)
-#define CMDQ_IRQ_MASK 0x
#define CMDQ_NUM_CMD(t)(t->cmd_buf_size /
CMDQ_INST_SIZE)
#define CMDQ_CURR_IRQ_STATUS 0x10
@@ -72,6 +71,7 @@ struct cmdq {
void __iomem*base;
u32 irq;
u32 thread_nr;
+ u32 irq_mask;
struct cmdq_thread *thread;
struct clk *clock;
boolsuspended;
@@ -285,11 +285,11 @@ static irqreturn_t cmdq_irq_handler(int irq, void *dev)
unsigned long irq_status, flags = 0L;
int bit;
- irq_status = readl(cmdq->base + CMDQ_CURR_IRQ_STATUS) & CMDQ_IRQ_MASK;
- if (!(irq_status ^ CMDQ_IRQ_MASK))
+ irq_status = readl(cmdq->base + CMDQ_CURR_IRQ_STATUS) & cmdq->irq_mask;
+ if (!(irq_status ^ cmdq->irq_mask))
return IRQ_NONE;
- for_each_clear_bit(bit, _status, fls(CMDQ_IRQ_MASK)) {
+ for_each_clear_bit(bit, _status, cmdq->thread_nr) {
struct cmdq_thread *thread = >thread[bit];
spin_lock_irqsave(>chan->lock, flags);
@@ -473,6 +473,9 @@ static int cmdq_probe(struct platform_device *pdev)
dev_err(dev, "failed to get irq\n");
return -EINVAL;
}
+
+ cmdq->thread_nr = (u32)(unsigned long)of_device_get_match_data(dev);
+ cmdq->irq_mask = GENMASK(cmdq->thread_nr - 1, 0);
err = devm_request_irq(dev, cmdq->irq, cmdq_irq_handler, IRQF_SHARED,
"mtk_cmdq", cmdq);
if (err < 0) {
@@ -489,7 +492,6 @@ static int cmdq_probe(struct platform_device *pdev)
return PTR_ERR(cmdq->clock);
}
- cmdq->thread_nr = (u32)(unsigned long)of_device_get_match_data(dev);
cmdq->mbox.dev = dev;
cmdq->mbox.chans = devm_kcalloc(dev, cmdq->thread_nr,
sizeof(*cmdq->mbox.chans), GFP_KERNEL);
--
2.18.0
