[PATCH 3/3] KVM: arm/arm64: prefix header search paths with $(srctree)/
Currently, the Kbuild core manipulates header search paths in a crazy
way [1].
To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
the search paths in the srctree. Some Makefiles are already written in
that way, but not all. The goal of this work is to make the notation
consistent, and finally get rid of the gross hacks.
Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
("kbuild: do not drop -I without parameter").
[1]: https://patchwork.kernel.org/patch/9632347/
Signed-off-by: Masahiro Yamada
---
arch/arm/kvm/Makefile | 2 +-
arch/arm64/kvm/Makefile | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kvm/Makefile b/arch/arm/kvm/Makefile
index bca775e..531e59f 100644
--- a/arch/arm/kvm/Makefile
+++ b/arch/arm/kvm/Makefile
@@ -8,7 +8,7 @@ ifeq ($(plus_virt),+virt)
plus_virt_def := -DREQUIRES_VIRT=1
endif
-ccflags-y += -Iarch/arm/kvm -Ivirt/kvm/arm/vgic
+ccflags-y += -I $(srctree)/$(src) -I $(srctree)/virt/kvm/arm/vgic
CFLAGS_arm.o := $(plus_virt_def)
AFLAGS_init.o := -Wa,-march=armv7-a$(plus_virt)
diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
index 3089b31..690e033 100644
--- a/arch/arm64/kvm/Makefile
+++ b/arch/arm64/kvm/Makefile
@@ -3,7 +3,7 @@
# Makefile for Kernel-based Virtual Machine module
#
-ccflags-y += -Iarch/arm64/kvm -Ivirt/kvm/arm/vgic
+ccflags-y += -I $(srctree)/$(src) -I $(srctree)/virt/kvm/arm/vgic
KVM=../../../virt/kvm
--
2.7.4
patch "tools/firmware/ihex2fw: Simplify next record offset calculation" added to driver-core-next
This is a note to let you know that I've just added the patch titled
tools/firmware/ihex2fw: Simplify next record offset calculation
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From 2ef8179bb7a6817de3fc9407ab55aa357f2d1e4d Mon Sep 17 00:00:00 2001
From: Andrey Smirnov
Date: Thu, 20 Dec 2018 23:28:40 -0800
Subject: tools/firmware/ihex2fw: Simplify next record offset calculation
We can convert original expression for 'writelen" to use ALIGN as
follows:
(p->len + 9) & ~3 => (p->len + 6 + 3) & ~3 => ALIGN(p->len + 6, 4)
Now, subsituting "p->len + 6" with "p->len + sizeof(p->addr) +
sizeof(p->len)" we end up with the same expression as used by kernel
couterpart in linux/ihex.h:
ALIGN(p->len + sizeof(p->addr) + sizeof(p->len), 4)
That is a full size of the record, aligned to 4 bytes. No functional
change intended.
Cc: Chris Healy
Cc: Kyle McMartin
Cc: Andrew Morton
Cc: Masahiro Yamada
Cc: David Woodhouse
Cc: Greg Kroah-Hartman
Cc: linux-kernel
Signed-off-by: Andrey Smirnov
Signed-off-by: Greg Kroah-Hartman
---
tools/firmware/ihex2fw.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/tools/firmware/ihex2fw.c b/tools/firmware/ihex2fw.c
index b58dd061e978..e081cef730d8 100644
--- a/tools/firmware/ihex2fw.c
+++ b/tools/firmware/ihex2fw.c
@@ -24,6 +24,10 @@
#include
+#define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
+#define __ALIGN_KERNEL(x, a) __ALIGN_KERNEL_MASK(x, (typeof(x))(a) -
1)
+#define ALIGN(x, a)__ALIGN_KERNEL((x), (a))
+
struct ihex_binrec {
struct ihex_binrec *next; /* not part of the real data structure */
uint32_t addr;
@@ -259,13 +263,18 @@ static void file_record(struct ihex_binrec *record)
*p = record;
}
+static uint16_t ihex_binrec_size(struct ihex_binrec *p)
+{
+ return p->len + sizeof(p->addr) + sizeof(p->len);
+}
+
static int output_records(int outfd)
{
unsigned char zeroes[6] = {0, 0, 0, 0, 0, 0};
struct ihex_binrec *p = records;
while (p) {
- uint16_t writelen = (p->len + 9) & ~3;
+ uint16_t writelen = ALIGN(ihex_binrec_size(p), 4);
p->addr = htonl(p->addr);
p->len = htons(p->len);
--
2.20.1
patch "ihex: Simplify next record offset calculation" added to driver-core-next
This is a note to let you know that I've just added the patch titled
ihex: Simplify next record offset calculation
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From 9fb4ab4d3dd665a62da9c176a89e7c7feaf5d9e4 Mon Sep 17 00:00:00 2001
From: Andrey Smirnov
Date: Thu, 20 Dec 2018 23:28:39 -0800
Subject: ihex: Simplify next record offset calculation
Next record calucaltion can be reduced to a much more tivial ALIGN
operation as follows:
1. Splitting 5 into 2 + 3 we get
next = ((be16_to_cpu(rec->len) + 2 + 3) & ~3) - 2(1)
2. Using ALIGN macro we reduce (1) to:
ALIGN(be16_to_cpu(rec->len) + 2, 4) - 2 (2)
3. Subsituting 'next' in original next record calucation we get:
(void *)>data[ALIGN(be16_to_cpu(rec->len) + 2, 4) - 2] (3)
4. Converting array index to pointer arithmetic we convert (3) into:
(void *)rec + sizeof(*rec) +
ALIGN(be16_to_cpu(rec->len) + 2, 4) - 2(4)
5. Subsituting sizeof(*rec) with its value, 6, and substracting 2,
in (4) we get:
(void *)rec + ALIGN(be16_to_cpu(rec->len) + 2, 4) + 4(5)
6. Since ALIGN(X, 4) + 4 == ALIGN(X + 4, 4), (5) can be converted to:
(void *)rec + ALIGN(be16_to_cpu(rec->len) + 6, 4)(6)
5. Subsituting 6 in (6) to sizeof(*rec) we get:
(void *)rec + ALIGN(be16_to_cpu(rec->len) + sizeof(*rec), 4) (7)
Using expression (7) should make it more clear that next record is
located by adding full size of the current record (payload + auxiliary
data) aligned to 4 bytes, to the location of the current one. No
functional change intended.
Cc: Chris Healy
Cc: Kyle McMartin
Cc: Andrew Morton
Cc: Masahiro Yamada
Cc: David Woodhouse
Cc: Greg Kroah-Hartman
Cc: linux-kernel
Signed-off-by: Andrey Smirnov
Signed-off-by: Greg Kroah-Hartman
---
include/linux/ihex.h | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/include/linux/ihex.h b/include/linux/ihex.h
index 9130f307a420..98cb5ce0b0a0 100644
--- a/include/linux/ihex.h
+++ b/include/linux/ihex.h
@@ -21,14 +21,18 @@ struct ihex_binrec {
uint8_t data[0];
} __attribute__((packed));
+static inline uint16_t ihex_binrec_size(const struct ihex_binrec *p)
+{
+ return be16_to_cpu(p->len) + sizeof(*p);
+}
+
/* Find the next record, taking into account the 4-byte alignment */
static inline const struct ihex_binrec *
__ihex_next_binrec(const struct ihex_binrec *rec)
{
- int next = ((be16_to_cpu(rec->len) + 5) & ~3) - 2;
- rec = (void *)>data[next];
+ const void *p = rec;
- return rec;
+ return p + ALIGN(ihex_binrec_size(rec), 4);
}
static inline const struct ihex_binrec *
--
2.20.1
patch "tools/firmware/ihex2fw: Replace explicit alignment with ALIGN" added to driver-core-next
This is a note to let you know that I've just added the patch titled
tools/firmware/ihex2fw: Replace explicit alignment with ALIGN
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From 925f8d4aad5ca1bf18987a3cdcb0e176bcf1 Mon Sep 17 00:00:00 2001
From: Andrey Smirnov
Date: Thu, 20 Dec 2018 23:28:41 -0800
Subject: tools/firmware/ihex2fw: Replace explicit alignment with ALIGN
(X + 3) & ~3 is the same as ALIGN(X, 4), so replace all of the
instances of the formwer in the code with the latter. While at it,
introduce a helper variable 'record_size' to avoid duplicating length
calculatin code. No functional change intended.
Cc: Chris Healy
Cc: Kyle McMartin
Cc: Andrew Morton
Cc: Masahiro Yamada
Cc: David Woodhouse
Cc: Greg Kroah-Hartman
Cc: linux-kernel
Signed-off-by: Andrey Smirnov
Signed-off-by: Greg Kroah-Hartman
---
tools/firmware/ihex2fw.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/firmware/ihex2fw.c b/tools/firmware/ihex2fw.c
index e081cef730d8..8925b60e51f5 100644
--- a/tools/firmware/ihex2fw.c
+++ b/tools/firmware/ihex2fw.c
@@ -135,6 +135,7 @@ int main(int argc, char **argv)
static int process_ihex(uint8_t *data, ssize_t size)
{
struct ihex_binrec *record;
+ size_t record_size;
uint32_t offset = 0;
uint32_t data32;
uint8_t type, crc = 0, crcbyte = 0;
@@ -161,12 +162,13 @@ static int process_ihex(uint8_t *data, ssize_t size)
len <<= 8;
len += hex(data + i, ); i += 2;
}
- record = malloc((sizeof (*record) + len + 3) & ~3);
+ record_size = ALIGN(sizeof(*record) + len, 4);
+ record = malloc(record_size);
if (!record) {
fprintf(stderr, "out of memory for records\n");
return -ENOMEM;
}
- memset(record, 0, (sizeof(*record) + len + 3) & ~3);
+ memset(record, 0, record_size);
record->len = len;
/* now check if we have enough data to read everything */
--
2.20.1
patch "ihex: Share code between ihex_validate_fw() and ihex_next_binrec()" added to driver-core-next
This is a note to let you know that I've just added the patch titled
ihex: Share code between ihex_validate_fw() and ihex_next_binrec()
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From 8092e79204e7884f4bee3584ecfe6cf4a124d129 Mon Sep 17 00:00:00 2001
From: Andrey Smirnov
Date: Thu, 20 Dec 2018 23:28:37 -0800
Subject: ihex: Share code between ihex_validate_fw() and ihex_next_binrec()
Convert both ihex_validate_fw() and ihex_next_binrec() to use a helper
function to calculate next record offest. This way we only have one
place implementing next record offset calculation logic. No functional
change intended.
Cc: Chris Healy
Cc: Kyle McMartin
Cc: Andrew Morton
Cc: Masahiro Yamada
Cc: David Woodhouse
Cc: Greg Kroah-Hartman
Cc: linux-kernel
Signed-off-by: Andrey Smirnov
Signed-off-by: Greg Kroah-Hartman
---
include/linux/ihex.h | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/include/linux/ihex.h b/include/linux/ihex.h
index 75c194391869..9c701521176b 100644
--- a/include/linux/ihex.h
+++ b/include/linux/ihex.h
@@ -23,29 +23,34 @@ struct ihex_binrec {
/* Find the next record, taking into account the 4-byte alignment */
static inline const struct ihex_binrec *
-ihex_next_binrec(const struct ihex_binrec *rec)
+__ihex_next_binrec(const struct ihex_binrec *rec)
{
int next = ((be16_to_cpu(rec->len) + 5) & ~3) - 2;
rec = (void *)>data[next];
+ return rec;
+}
+
+static inline const struct ihex_binrec *
+ihex_next_binrec(const struct ihex_binrec *rec)
+{
+ rec = __ihex_next_binrec(rec);
+
return be16_to_cpu(rec->len) ? rec : NULL;
}
/* Check that ihex_next_binrec() won't take us off the end of the image... */
static inline int ihex_validate_fw(const struct firmware *fw)
{
- const struct ihex_binrec *rec;
- size_t ofs = 0;
+ const struct ihex_binrec *end, *rec;
- while (ofs <= fw->size - sizeof(*rec)) {
- rec = (void *)>data[ofs];
+ rec = (const void *)fw->data;
+ end = (const void *)>data[fw->size - sizeof(*end)];
+ for (; rec <= end; rec = __ihex_next_binrec(rec)) {
/* Zero length marks end of records */
if (!be16_to_cpu(rec->len))
return 0;
-
- /* Point to next record... */
- ofs += (sizeof(*rec) + be16_to_cpu(rec->len) + 3) & ~3;
}
return -EINVAL;
}
--
2.20.1
[PATCH 0/3] KVM: arm/arm64: trivial header path sanitization
My main motivation is to get rid of crappy header search path manipulation from Kbuild core. Before that, I want to finish as many cleanup works as possible. If you are interested in the big picture of this work, the full patch set is available at: git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git build-test Masahiro Yamada (3): KVM: arm/arm64: fix TRACE_INCLUDE_PATH KVM: arm/arm64: remove -I. header search paths KVM: arm/arm64: prefix header search paths with $(srctree)/ arch/arm/kvm/Makefile | 5 ++--- arch/arm64/kvm/Makefile | 4 +--- virt/kvm/arm/trace.h| 2 +- 3 files changed, 4 insertions(+), 7 deletions(-) -- 2.7.4
patch "ihex: Check if zero-length record is at the end of the blob" added to driver-core-next
This is a note to let you know that I've just added the patch titled
ihex: Check if zero-length record is at the end of the blob
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From 5158c36ec9d0b3343f58987cec7ebfd866331fd0 Mon Sep 17 00:00:00 2001
From: Andrey Smirnov
Date: Thu, 20 Dec 2018 23:28:38 -0800
Subject: ihex: Check if zero-length record is at the end of the blob
When verifying the validity of IHEX file we need to make sure that
zero-length record we found is located at the end of the file. Not
doing that could result in an invalid file with a bogus zero-length in
the middle short-circuiting the check and being reported as valid.
Cc: Chris Healy
Cc: Kyle McMartin
Cc: Andrew Morton
Cc: Masahiro Yamada
Cc: David Woodhouse
Cc: Greg Kroah-Hartman
Cc: linux-kernel
Signed-off-by: Andrey Smirnov
Signed-off-by: Greg Kroah-Hartman
---
include/linux/ihex.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/ihex.h b/include/linux/ihex.h
index 9c701521176b..9130f307a420 100644
--- a/include/linux/ihex.h
+++ b/include/linux/ihex.h
@@ -49,7 +49,7 @@ static inline int ihex_validate_fw(const struct firmware *fw)
for (; rec <= end; rec = __ihex_next_binrec(rec)) {
/* Zero length marks end of records */
- if (!be16_to_cpu(rec->len))
+ if (rec == end && !be16_to_cpu(rec->len))
return 0;
}
return -EINVAL;
--
2.20.1
[PATCH 1/3] KVM: arm/arm64: fix TRACE_INCLUDE_PATH
As the comment block in include/trace/define_trace.h says, TRACE_INCLUDE_PATH should be a relative path to the define_trace.h ../../virt/kvm/arm is the correct relative path. ../../../virt/kvm/arm is working by coincidence because the top Makefile adds -I$(srctree)/arch/$(SRCARCH)/include as a header search path, but we should not rely on it. Signed-off-by: Masahiro Yamada --- virt/kvm/arm/trace.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/virt/kvm/arm/trace.h b/virt/kvm/arm/trace.h index 3828bea..853f3b1 100644 --- a/virt/kvm/arm/trace.h +++ b/virt/kvm/arm/trace.h @@ -265,7 +265,7 @@ TRACE_EVENT(kvm_timer_update_irq, #endif /* _TRACE_KVM_H */ #undef TRACE_INCLUDE_PATH -#define TRACE_INCLUDE_PATH ../../../virt/kvm/arm +#define TRACE_INCLUDE_PATH ../../virt/kvm/arm #undef TRACE_INCLUDE_FILE #define TRACE_INCLUDE_FILE trace -- 2.7.4
[PATCH 2/3] KVM: arm/arm64: remove -I. header search paths
The header search path -I. in kernel Makefiles is very suspicious; it allows the compiler to search for headers in the top of $(srctree), where obviously no header file exists. I was able to build without these extra header search paths. Signed-off-by: Masahiro Yamada --- arch/arm/kvm/Makefile | 3 +-- arch/arm64/kvm/Makefile | 2 -- 2 files changed, 1 insertion(+), 4 deletions(-) diff --git a/arch/arm/kvm/Makefile b/arch/arm/kvm/Makefile index 48de846..bca775e 100644 --- a/arch/arm/kvm/Makefile +++ b/arch/arm/kvm/Makefile @@ -9,8 +9,7 @@ ifeq ($(plus_virt),+virt) endif ccflags-y += -Iarch/arm/kvm -Ivirt/kvm/arm/vgic -CFLAGS_arm.o := -I. $(plus_virt_def) -CFLAGS_mmu.o := -I. +CFLAGS_arm.o := $(plus_virt_def) AFLAGS_init.o := -Wa,-march=armv7-a$(plus_virt) AFLAGS_interrupts.o := -Wa,-march=armv7-a$(plus_virt) diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile index 0f2a135..3089b31 100644 --- a/arch/arm64/kvm/Makefile +++ b/arch/arm64/kvm/Makefile @@ -4,8 +4,6 @@ # ccflags-y += -Iarch/arm64/kvm -Ivirt/kvm/arm/vgic -CFLAGS_arm.o := -I. -CFLAGS_mmu.o := -I. KVM=../../../virt/kvm -- 2.7.4
Re: [PATCH] mm,memory_hotplug: Fix scan_movable_pages for gigantic hugepages
On Wed, Jan 23, 2019 at 11:33:56AM +0100, David Hildenbrand wrote:
> If you use {} for the else case, please also do so for the if case.
Diff on top:
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 25aee4f04a72..d5810e522b72 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1338,9 +1338,9 @@ static unsigned long scan_movable_pages(unsigned long
start, unsigned long end)
struct page *head = compound_head(page);
if
(hugepage_migration_supported(page_hstate(head)) &&
- page_huge_active(head))
+ page_huge_active(head)) {
return pfn;
- else {
+ } else {
unsigned long skip;
skip = (1 << compound_order(head)) -
(page - head);
> Apart from that this looks good to me
>
> Reviewed-by: David Hildenbrand
Thanks David ;-)
--
Oscar Salvador
SUSE L3
[PATCH] watchdog: dw: remove useless pr_fmt
When switch to watchdog infrastructure, pr_* usage is removed, so there's no any users of the pr_fmt, remove it. Signed-off-by: Jisheng Zhang --- drivers/watchdog/dw_wdt.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c index c053c2de5c2f..0ce8fa5cfbf4 100644 --- a/drivers/watchdog/dw_wdt.c +++ b/drivers/watchdog/dw_wdt.c @@ -16,8 +16,6 @@ * heartbeat requests after the watchdog device has been closed. */ -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt - #include #include #include -- 2.20.1
Re: [PATCH 1/2] Bluetooth: Annotate implicit fall through in l2cap_config_rsp
Hi Mathieu, > There is a plan to build the kernel with -Wimplicit-fallthrough and > this place in the code produced a warning (W=1). > > This commit removes the following warning: > > net/bluetooth/l2cap_core.c:4223:6: warning: this statement may fall through > [-Wimplicit-fallthrough=] > > Cc: Gustavo Padovan > Signed-off-by: Mathieu Malaterre > --- > net/bluetooth/l2cap_core.c | 1 + > 1 file changed, 1 insertion(+) the patches don’t apply cleanly against bluetooth-next tree. Please fix it up and resend. Regards Marcel
Re: [PATCH v3] arm64: dts: sdm845: add video nodes
On 2019-01-25 13:16, Alexandre Courbot wrote:
On Thu, Jan 17, 2019 at 8:58 PM Stanimir Varbanov
wrote:
Hi Malathi,
On 12/20/18 9:47 AM, Malathi Gottam wrote:
> This adds video nodes to sdm845 based on the examples
> in the bindings.
>
> Signed-off-by: Malathi Gottam
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 35 +++
> 1 file changed, 35 insertions(+)
Looks good to me:
Reviewed-by: Stanimir Varbanov
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index b72bdb0..ccd2b10 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -87,6 +87,11 @@
> reg = <0 0x8620 0 0x2d0>;
> no-map;
> };
> +
> + venus_region: memory@9580 {
> + reg = <0x0 0x9580 0x0 0x50>;
> + no-map;
> + };
> };
>
> cpus {
> @@ -1403,5 +1408,35 @@
> status = "disabled";
> };
> };
> +
> + video-codec@aa0 {
> + compatible = "qcom,sdm845-venus";
> + reg = <0x0aa0 0xff000>;
> + interrupts = ;
> + power-domains = < VENUS_GDSC>;
> + clocks = < VIDEO_CC_VENUS_CTL_CORE_CLK>,
> + < VIDEO_CC_VENUS_AHB_CLK>,
> + < VIDEO_CC_VENUS_CTL_AXI_CLK>;
> + clock-names = "core", "iface", "bus";
> + iommus = <_smmu 0x10a0 0x8>,
> + <_smmu 0x10b0 0x0>;
> + memory-region = <_region>;
> +
> + video-core0 {
> + compatible = "venus-decoder";
> + clocks = < VIDEO_CC_VCODEC0_CORE_CLK>,
> + < VIDEO_CC_VCODEC0_AXI_CLK>;
> + clock-names = "core", "bus";
> + power-domains = < VCODEC0_GDSC>;
> + };
> +
> + video-core1 {
> + compatible = "venus-encoder";
> + clocks = < VIDEO_CC_VCODEC1_CORE_CLK>,
> + < VIDEO_CC_VCODEC1_AXI_CLK>;
> + clock-names = "core", "bus";
> + power-domains = < VCODEC1_GDSC>;
> + };
> + };
This patch lacks the video-firmware node, it should at the very least
be added before this gets merged.
Yes Alex, I missed adding video-firmware node. Thanks for noticing.
Will add it and post new version.
Thanks,
Malathi.
Re: [PATCH 09/15] habanalabs: add sysfs and hwmon support
On Wed, Jan 23, 2019 at 02:00:51AM +0200, Oded Gabbay wrote: > This patch add the sysfs and hwmon entries that are exposed by the driver. > > Goya has several sensors, from various categories such as temperature, > voltage, current, etc. The driver exposes those sensors in the standard > hwmon mechanism. > > In addition, the driver exposes a couple of interfaces in sysfs, both for > configuration and for providing status of the device or driver. > > The configuration attributes is for Power Management: > - Automatic or manual > - Frequency value when moving to high frequency mode > - Maximum power the device is allowed to consume > > The rest of the attributes are read-only and provide the following > information: > - Versions of the various firmwares running on the device > - Contents of the device's EEPROM > - The device type (currently only Goya is supported) > - PCI address of the device (to allow user-space to connect between > /dev/hlX to PCI address) > - Status of the device (operational, malfunction, in_reset) > - How many processes are open on the device's file > > Signed-off-by: Oded Gabbay > --- > .../ABI/testing/sysfs-driver-habanalabs | 190 ++ > drivers/misc/habanalabs/Makefile | 2 +- > drivers/misc/habanalabs/device.c | 146 + > drivers/misc/habanalabs/goya/Makefile | 2 +- > drivers/misc/habanalabs/goya/goya.c | 230 +++ > drivers/misc/habanalabs/goya/goyaP.h | 21 + > drivers/misc/habanalabs/goya/goya_hwmgr.c | 306 + > drivers/misc/habanalabs/habanalabs.h | 97 +++ > drivers/misc/habanalabs/habanalabs_drv.c | 7 + > drivers/misc/habanalabs/hwmon.c | 449 + > drivers/misc/habanalabs/sysfs.c | 588 ++ > 11 files changed, 2036 insertions(+), 2 deletions(-) > create mode 100644 Documentation/ABI/testing/sysfs-driver-habanalabs > create mode 100644 drivers/misc/habanalabs/goya/goya_hwmgr.c > create mode 100644 drivers/misc/habanalabs/hwmon.c > create mode 100644 drivers/misc/habanalabs/sysfs.c > > diff --git a/Documentation/ABI/testing/sysfs-driver-habanalabs > b/Documentation/ABI/testing/sysfs-driver-habanalabs > new file mode 100644 > index ..19edd4da87c1 > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-driver-habanalabs > @@ -0,0 +1,190 @@ > +What: /sys/class/habanalabs/hl/armcp_kernel_ver > +Date: Jan 2019 > +KernelVersion: 5.1 > +Contact:oded.gab...@gmail.com > +Description:Version of the Linux kernel running on the device's CPU > + > +What: /sys/class/habanalabs/hl/armcp_ver > +Date: Jan 2019 > +KernelVersion: 5.1 > +Contact:oded.gab...@gmail.com > +Description:Version of the application running on the device's CPU > + > +What: /sys/class/habanalabs/hl/cpld_ver > +Date: Jan 2019 > +KernelVersion: 5.1 > +Contact:oded.gab...@gmail.com > +Description:Version of the Device's CPLD F/W > + > +What: /sys/class/habanalabs/hl/device_type > +Date: Jan 2019 > +KernelVersion: 5.1 > +Contact:oded.gab...@gmail.com > +Description:Displays the code name of the device according to its type. > +The supported values are: "GOYA" > + > +What: /sys/class/habanalabs/hl/eeprom > +Date: Jan 2019 > +KernelVersion: 5.1 > +Contact:oded.gab...@gmail.com > +Description:A binary file attribute that contains the contents of the > +on-board EEPROM > + > +What: /sys/class/habanalabs/hl/fuse_ver > +Date: Jan 2019 > +KernelVersion: 5.1 > +Contact:oded.gab...@gmail.com > +Description:Displays the device's version from the eFuse > + > +What: /sys/class/habanalabs/hl/hard_reset > +Date: Jan 2019 > +KernelVersion: 5.1 > +Contact:oded.gab...@gmail.com > +Description:Interface to trigger a hard-reset operation for the device. > +Hard-reset will reset ALL internal components of the device > +except for the PCI interface and the internal PLLs > + > +What: /sys/class/habanalabs/hl/hard_reset_cnt > +Date: Jan 2019 > +KernelVersion: 5.1 > +Contact:oded.gab...@gmail.com > +Description:Displays how many times the device have undergone a > hard-reset > +operation > + > +What: /sys/class/habanalabs/hl/high_pll > +Date: Jan 2019 > +KernelVersion: 5.1 > +Contact:oded.gab...@gmail.com > +Description:Allows the user to set the maximum clock frequency for MME, > TPC > +and IC when the power management profile is set to > "automatic". > + > +What: /sys/class/habanalabs/hl/ic_clk > +Date: Jan 2019 > +KernelVersion: 5.1 > +Contact:oded.gab...@gmail.com > +Description:Allows the user to set the maximum clock frequency of the > +
Re: [PATCH RFC 07/24] userfaultfd: wp: add the writeprotect API to userfaultfd ioctl
On Thu, Jan 24, 2019 at 05:28:48PM +0800, Peter Xu wrote: > On Thu, Jan 24, 2019 at 09:27:07AM +0200, Mike Rapoport wrote: > > On Thu, Jan 24, 2019 at 12:56:15PM +0800, Peter Xu wrote: > > > On Mon, Jan 21, 2019 at 12:42:33PM +0200, Mike Rapoport wrote: > > > > > > [...] > > > > > > > > @@ -1343,7 +1344,7 @@ static int userfaultfd_register(struct > > > > > userfaultfd_ctx *ctx, > > > > > > > > > > /* check not compatible vmas */ > > > > > ret = -EINVAL; > > > > > - if (!vma_can_userfault(cur)) > > > > > + if (!vma_can_userfault(cur, vm_flags)) > > > > > goto out_unlock; > > > > > > > > > > /* > > > > > @@ -1371,6 +1372,8 @@ static int userfaultfd_register(struct > > > > > userfaultfd_ctx *ctx, > > > > > if (end & (vma_hpagesize - 1)) > > > > > goto out_unlock; > > > > > } > > > > > + if ((vm_flags & VM_UFFD_WP) && !(cur->vm_flags & > > > > > VM_WRITE)) > > > > > + goto out_unlock; > > > > > > > > This is problematic for the non-cooperative use-case. Way may still > > > > want to > > > > monitor a read-only area because it may eventually become writable, > > > > e.g. if > > > > the monitored process runs mprotect(). > > > > > > Firstly I think I should be able to change it to VM_MAYWRITE which > > > seems to suite more. > > > > > > Meanwhile, frankly speaking I didn't think a lot about how to nest the > > > usages of uffd-wp and mprotect(), so far I was only considering it as > > > a replacement of mprotect(). But indeed it can happen that the > > > monitored process calls mprotect(). Is there an existing scenario of > > > such usage? > > > > > > The problem is I'm uncertain about whether this scenario can work > > > after all. Say, the monitor process A write protected process B's > > > page P, so logically A will definitely receive a message before B > > > writes to page P. However here if we allow process B to do > > > mprotect(PROT_WRITE) upon page P and grant write permission to it on > > > its own, then A will not be able to capture the write operation at > > > all? Then I don't know how it can work here... or whether we should > > > fail the mprotect() at least upon uffd-wp ranges? > > > > The use-case we've discussed a while ago was to use uffd-wp instead of > > soft-dirty for tracking memory changes in CRIU for pre-copy migration. > > Currently, we enable soft-dirty for the migrated process and monitor > > /proc/pid/pagemap between memory dump iterations to see what memory pages > > have been changed. > > With uffd-wp we thought to register all the process memory with uffd-wp and > > then track changes with uffd-wp notifications. Back then it was considered > > only at the very general level without paying much attention to details. > > > > So my initial thought was that we do register the entire memory with > > uffd-wp. If an area changes from RO to RW at some point, uffd-wp will > > generate notifications to the monitor, it would be able to notice the > > change and the write will continue normally. > > > > If we are to limit uffd-wp register only to VMAs with VM_WRITE and even > > VM_MAYWRITE, we'd need a way to handle the possible changes of VMA > > protection and an ability to add monitoring for areas that changed from RO > > to RW. > > > > Can't say I have a clear picture in mind at the moment, will continue to > > think about it. > > Thanks for these details. Though I have a question about how it's > used. > > Since we're talking about replacing soft dirty with uffd-wp here, I > noticed that there's a major interface difference between soft-dirty > and uffd-wp: the soft-dirty was all about /proc operations so a > monitor process can easily monitor mostly any process on the system as > long as knowing its PID. However I'm unsure about uffd-wp since > userfaultfd was always bound to a mm_struct. For example, the syscall > userfaultfd() will always attach the current process mm_struct to the > newly created userfaultfd but it cannot be attached to another random > mm_struct of other processes. Or is there any way that the CRIU > monitor process can gain an userfaultfd of any process of the system > somehow? Yes, there is. For CRIU to read the process state during snapshot (or one the source in case of the migration) we inject a parasite code into the victim process. The parasite code communicates with the "main" CRIU monitor via UNIX socket to pass information that cannot be obtained from outside. For uffd-wp usage we thought about creating the uffd context in the parasite code, registering the memory and passing the userfault file descriptor to the CRIU core via that UNIX socket. > > > > > > Particularity, for using uffd-wp as a replacement for soft-dirty would > > > > require it. > > > > > > > > > > > > > > /* > > > > >* Check that this vma isn't
Re: [PATCH] Bluetooth: make hw_err static, reduces object code size
Hi Colin, > Don't populate the const array hw_err on the stack but instead make > it static. Makes the object code smaller by 45 bytes: > > Before: > text data bss dec hex filename > 100880 210901088 123058 1e0b2 linux/net/bluetooth/hci_core.o > > After: > text data bss dec hex filename > 100739 211861088 123013 1e085 linux/net/bluetooth/hci_core.o > > (gcc version 8.2.0 x86_64) > > Signed-off-by: Colin Ian King > --- > net/bluetooth/hci_core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) patch has been applied to bluetooth-next tree. Regards Marcel
DEAREST ONE
-- My name is Miss Alizata Aron. It give me a great pleasure to write you,it attracts me to write to you so that we can be friends if you will have the desire as me. i will be very happy to be in communication with you so that we can get to know each other better and see what happens in future. I await your reply so that i can tell you more about my self and give you my picture. Have a blessed day. Miss Alizata Aron.
RE: [v4] dt-bindings: ahci-fsl-qoriq: add lx2160a chip name to the list
>-Original Message- >From: Sergei Shtylyov >Sent: 2019年1月25日 15:46 >To: Peng Ma ; shawn...@kernel.org; ax...@kernel.dk >Cc: robh...@kernel.org; mark.rutl...@arm.com; Leo Li >; linux-...@vger.kernel.org; devicet...@vger.kernel.org; >linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Andy Tang > >Subject: Re: [v4] dt-bindings: ahci-fsl-qoriq: add lx2160a chip name to the >list > >Hello! > >On 25.01.2019 6:32, Peng Ma wrote: > >> Add lxx2160a compatible to bindings documentation. > >lx2160a? > [Peng Ma] Yes, it is should be lx2160a, thanks very much. I will change it as soon as possible. Best Regards, Peng >> Signed-off-by: Peng Ma >> --- >> changed for V4: >> - add lx2160a compatible to bindings doc >> >> .../devicetree/bindings/ata/ahci-fsl-qoriq.txt |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt >b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt >> index 7c3ca0e..9ecc019 100644 >> --- a/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt >> +++ b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt >> @@ -3,7 +3,7 @@ Binding for Freescale QorIQ AHCI SATA Controller >> Required properties: >> - reg: Physical base address and size of the controller's register area. >> - compatible: Compatibility string. Must be 'fsl,-ahci', where >> -chip could be ls1021a, ls1043a, ls1046a, ls1088a, ls2080a etc. >> +chip could be ls1021a, ls1043a, ls1046a, ls1088a, ls2080a, lx2160a, etc. >> - clocks: Input clock specifier. Refer to common clock bindings. >> - interrupts: Interrupt specifier. Refer to interrupt binding. >> > >MBR, Sergei
[PATCH] watchdog: dw: use devm_watchdog_register_device()
Use devm_watchdog_register_device() to simplify the code.
Signed-off-by: Jisheng Zhang
---
drivers/watchdog/dw_wdt.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c
index 501aebb5b81f..c053c2de5c2f 100644
--- a/drivers/watchdog/dw_wdt.c
+++ b/drivers/watchdog/dw_wdt.c
@@ -303,7 +303,7 @@ static int dw_wdt_drv_probe(struct platform_device *pdev)
watchdog_set_restart_priority(wdd, 128);
- ret = watchdog_register_device(wdd);
+ ret = devm_watchdog_register_device(wdd);
if (ret)
goto out_disable_clk;
@@ -318,7 +318,6 @@ static int dw_wdt_drv_remove(struct platform_device *pdev)
{
struct dw_wdt *dw_wdt = platform_get_drvdata(pdev);
- watchdog_unregister_device(_wdt->wdd);
reset_control_assert(dw_wdt->rst);
clk_disable_unprepare(dw_wdt->clk);
--
2.20.1
Re: [PATCH v6 2/4] usb: assign ACPI companions for embedded USB devices
Hi Rajat, > USB devices permanently connected to USB ports may be described in ACPI > tables and share ACPI devices with ports they are connected to. See [1] > for details. > > This will allow us to describe sideband resources for devices, such as, > for example, hard reset line for BT USB controllers. > > [1] > https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/other-acpi-namespace-objects#acpi-namespace-hierarchy-and-adr-for-embedded-usb-devices > > Signed-off-by: Dmitry Torokhov > Signed-off-by: Rajat Jain (changed how we get the > usb_port) > Acked-by: Greg Kroah-Hartman > Tested-by: Sukumar Ghorai > --- > v6: same as v4 > v5: same as v4 > v4: Add Acked-by and Tested-by in signatures. > v3: same as v1 > v2: same as v1 > > drivers/usb/core/usb-acpi.c | 44 + > 1 file changed, 35 insertions(+), 9 deletions(-) patch has been applied to bluetooth-next tree. Regards Marcel
Re: [PATCH 07/15] habanalabs: add h/w queues module
On Wed, Jan 23, 2019 at 02:00:49AM +0200, Oded Gabbay wrote:
> This patch adds the H/W queues module and the code to initialize Goya's
> various compute and DMA engines and their queues.
>
> Goya has 5 DMA channels, 8 TPC engines and a single MME engine. For each
> channel/engine, there is a H/W queue logic which is used to pass commands
> from the user to the H/W. That logic is called QMAN.
>
> There are two types of QMANs: external and internal. The DMA QMANs are
> considered external while the TPC and MME QMANs are considered internal.
> For each external queue there is a completion queue, which is located on
> the Host memory.
>
> The differences between external and internal QMANs are:
>
> 1. The location of the queue's memory. External QMANs are located on the
>Host memory while internal QMANs are located on the on-chip memory.
>
> 2. The external QMAN write an entry to a completion queue and sends an
>MSI-X interrupt upon completion of a command buffer that was given to
>it. The internal QMAN doesn't do that.
>
> Signed-off-by: Oded Gabbay
> ---
> drivers/misc/habanalabs/Makefile |2 +-
> drivers/misc/habanalabs/device.c | 74 +-
> drivers/misc/habanalabs/goya/goya.c | 1518 +++--
> drivers/misc/habanalabs/goya/goyaP.h |6 +
> drivers/misc/habanalabs/habanalabs.h | 176 +-
> drivers/misc/habanalabs/habanalabs_drv.c |6 +
> drivers/misc/habanalabs/hw_queue.c| 404 +
> .../habanalabs/include/goya/goya_packets.h| 234 +++
> .../habanalabs/include/habanalabs_device_if.h | 272 +++
> drivers/misc/habanalabs/irq.c | 150 ++
> 10 files changed, 2721 insertions(+), 121 deletions(-)
> create mode 100644 drivers/misc/habanalabs/hw_queue.c
> create mode 100644 drivers/misc/habanalabs/include/goya/goya_packets.h
> create mode 100644 drivers/misc/habanalabs/irq.c
>
> diff --git a/drivers/misc/habanalabs/Makefile
> b/drivers/misc/habanalabs/Makefile
> index 2530c9b78ca4..c07f3ccb57dc 100644
> --- a/drivers/misc/habanalabs/Makefile
> +++ b/drivers/misc/habanalabs/Makefile
> @@ -5,7 +5,7 @@
> obj-m:= habanalabs.o
>
> habanalabs-y := habanalabs_drv.o device.o context.o asid.o
> habanalabs_ioctl.o \
> - command_buffer.o
> + command_buffer.o hw_queue.o irq.o
>
> include $(src)/goya/Makefile
> habanalabs-y += $(HL_GOYA_FILES)
> diff --git a/drivers/misc/habanalabs/device.c
> b/drivers/misc/habanalabs/device.c
> index 9fc7218a973c..98220628a467 100644
> --- a/drivers/misc/habanalabs/device.c
> +++ b/drivers/misc/habanalabs/device.c
> @@ -170,13 +170,22 @@ static int device_early_init(struct hl_device *hdev)
> if (rc)
> goto early_fini;
>
> + hdev->cq_wq = alloc_workqueue("hl-free-jobs", WQ_UNBOUND, 0);
> + if (hdev->cq_wq == NULL) {
> + dev_err(hdev->dev, "Failed to allocate CQ workqueue\n");
> + goto asid_fini;
> + }
> +
> hl_cb_mgr_init(>kernel_cb_mgr);
>
> mutex_init(>device_open);
> + mutex_init(>send_cpu_message_lock);
> atomic_set(>fd_open_cnt, 0);
>
> return 0;
>
> +asid_fini:
> + hl_asid_fini(hdev);
> early_fini:
> if (hdev->asic_funcs->early_fini)
> hdev->asic_funcs->early_fini(hdev);
> @@ -192,9 +201,12 @@ static int device_early_init(struct hl_device *hdev)
> */
> static void device_early_fini(struct hl_device *hdev)
> {
> + mutex_destroy(>send_cpu_message_lock);
>
> hl_cb_mgr_fini(hdev, >kernel_cb_mgr);
>
> + destroy_workqueue(hdev->cq_wq);
> +
> hl_asid_fini(hdev);
>
> if (hdev->asic_funcs->early_fini)
> @@ -273,7 +285,7 @@ int hl_device_resume(struct hl_device *hdev)
> */
> int hl_device_init(struct hl_device *hdev, struct class *hclass)
> {
> - int rc;
> + int i, rc, cq_ready_cnt;
>
> /* Create device */
> rc = device_setup_cdev(hdev, hclass, hdev->id, _ops);
> @@ -294,11 +306,48 @@ int hl_device_init(struct hl_device *hdev, struct class
> *hclass)
> if (rc)
> goto early_fini;
>
> + /*
> + * Initialize the H/W queues. Must be done before hw_init, because
> + * there the addresses of the kernel queue are being written to the
> + * registers of the device
> + */
> + rc = hl_hw_queues_create(hdev);
> + if (rc) {
> + dev_err(hdev->dev, "failed to initialize kernel queues\n");
> + goto sw_fini;
> + }
> +
> + /*
> + * Initialize the completion queues. Must be done before hw_init,
> + * because there the addresses of the completion queues are being
> + * passed as arguments to request_irq
> + */
> + hdev->completion_queue =
> + kcalloc(hdev->asic_prop.completion_queues_count,
> + sizeof(*hdev->completion_queue), GFP_KERNEL);
> +
> + if (!hdev->completion_queue) {
> +
Re: pids.current with invalid value for hours [5.0.0 rc3 git]
On 24/01/2019 12:21, Arkadiusz Miśkiewicz wrote: > On 17/01/2019 14:17, Arkadiusz Miśkiewicz wrote: >> On 17/01/2019 13:25, Aleksa Sarai wrote: >>> On 2019-01-17, Arkadiusz Miśkiewicz wrote: Using kernel 4.19.13. For one cgroup I noticed weird behaviour: # cat pids.current 60 # cat cgroup.procs # >>> >>> Are there any zombies in the cgroup? pids.current is linked up directly >>> to __put_task_struct (so exit(2) won't decrease it, only the task_struct >>> actually being freed will decrease it). >>> >> >> There are no zombie processes. >> >> In mean time the problem shows on multiple servers and so far saw it >> only in cgroups that were OOMed. >> >> What has changed on these servers (yesterday) is turning on >> memory.oom.group=1 for all cgroups and changing memory.high from 1G to >> "max" (leaving memory.max=2G limit only). >> >> Previously there was no such problem. >> > > I'm attaching reproducer. This time tried on different distribution > kernel (arch linux). > > After 60s pids.current still shows 37 processes even if there are no > processes running (according to ps aux). The same test on 5.0.0-rc3-00104-gc04e2a780caf and it's easy to reproduce bug. No processes in cgroup but pids.current reports 91. memory.oom.group=0 - everything works fine, pids are counted properly memory.oom.group=1 - bug becomes visible [root@xps test]# python3 cg.py Created cgroup: /sys/fs/cgroup/test_5277 Start: pids.current: 0 Start: cgroup.procs: 0: pids.current: 103 0: cgroup.procs: 1: pids.current: 91 1: cgroup.procs: 2: pids.current: 91 2: cgroup.procs: 3: pids.current: 91 3: cgroup.procs: 4: pids.current: 91 4: cgroup.procs: 5: pids.current: 91 5: cgroup.procs: 6: pids.current: 91 6: cgroup.procs: 7: pids.current: 91 7: cgroup.procs: 8: pids.current: 91 8: cgroup.procs: 9: pids.current: 91 9: cgroup.procs: 10: pids.current: 91 10: cgroup.procs: 11: pids.current: 91 11: cgroup.procs: [root@xps test]# uname -a Linux xps 5.0.0-rc3-00104-gc04e2a780caf #288 SMP PREEMPT Thu Jan 24 19:00:32 CET 2019 x86_64 Intel(R)_Core(TM)_i9-8950HK_CPU_@_2.90GHz PLD Linux cc relevant people script is here: https://www.spinics.net/lists/cgroups/msg21330.html > > [root@warm ~]# uname -a > Linux warm 4.20.3-arch1-1-ARCH #1 SMP PREEMPT Wed Jan 16 22:38:58 UTC > 2019 x86_64 GNU/Linux > [root@warm ~]# python3 cg.py > Created cgroup: /sys/fs/cgroup/test_26207 > Start: pids.current: 0 > Start: cgroup.procs: > 0: pids.current: 62 > 0: cgroup.procs: > 1: pids.current: 37 > 1: cgroup.procs: > 2: pids.current: 37 > 2: cgroup.procs: > 3: pids.current: 37 > 3: cgroup.procs: > 4: pids.current: 37 > 4: cgroup.procs: > 5: pids.current: 37 > 5: cgroup.procs: > 6: pids.current: 37 > 6: cgroup.procs: > 7: pids.current: 37 > 7: cgroup.procs: > 8: pids.current: 37 > 8: cgroup.procs: > 9: pids.current: 37 > 9: cgroup.procs: > 10: pids.current: 37 > 10: cgroup.procs: > 11: pids.current: 37 > 11: cgroup.procs: > -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
Re: [PATCH 08/15] habanalabs: add event queue and interrupts
On Wed, Jan 23, 2019 at 02:00:50AM +0200, Oded Gabbay wrote:
> This patch adds support for receiving events from Goya's control CPU and
> for receiving MSI-X interrupts from Goya's DMA engines and CPU.
>
> Goya's PCI controller supports up to 8 MSI-X interrupts, which only 6 of
> them are currently used. The first 5 interrupts are dedicated for Goya's
> DMA engine queues. The 6th interrupt is dedicated for Goya's control CPU.
>
> The DMA queue will signal its MSI-X entry upon each completion of a command
> buffer that was placed on its primary queue. The driver will then mark that
> CB as completed and free the related resources. It will also update the
> command submission object which that CB belongs to.
>
> There is a dedicated event queue (EQ) between the driver and Goya's control
> CPU. The EQ is located on the Host memory. The control CPU writes a new
> entry to the EQ for various reasons, such as ECC error, MMU page fault, Hot
> temperature. After writing the new entry to the EQ, the control CPU will
> trigger its dedicated MSI-X entry to signal the driver that there is a new
> entry in the EQ. The driver will then read the entry and act accordingly.
>
> Signed-off-by: Oded Gabbay
> ---
> drivers/misc/habanalabs/device.c| 35 +-
> drivers/misc/habanalabs/goya/goya.c | 522 +++-
> drivers/misc/habanalabs/goya/goyaP.h| 1 +
> drivers/misc/habanalabs/habanalabs.h| 37 ++
> drivers/misc/habanalabs/include/goya/goya.h | 1 -
> drivers/misc/habanalabs/irq.c | 144 ++
> 6 files changed, 729 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/misc/habanalabs/device.c
> b/drivers/misc/habanalabs/device.c
> index 98220628a467..9199e070e79e 100644
> --- a/drivers/misc/habanalabs/device.c
> +++ b/drivers/misc/habanalabs/device.c
> @@ -173,9 +173,17 @@ static int device_early_init(struct hl_device *hdev)
> hdev->cq_wq = alloc_workqueue("hl-free-jobs", WQ_UNBOUND, 0);
> if (hdev->cq_wq == NULL) {
> dev_err(hdev->dev, "Failed to allocate CQ workqueue\n");
> + rc = -ENOMEM;
Apparently, it should have been in one of the earlier patches
> goto asid_fini;
> }
>
> + hdev->eq_wq = alloc_workqueue("hl-events", WQ_UNBOUND, 0);
> + if (hdev->eq_wq == NULL) {
> + dev_err(hdev->dev, "Failed to allocate EQ workqueue\n");
> + rc = -ENOMEM;
> + goto free_cq_wq;
> + }
> +
> hl_cb_mgr_init(>kernel_cb_mgr);
>
> mutex_init(>device_open);
> @@ -184,6 +192,8 @@ static int device_early_init(struct hl_device *hdev)
>
> return 0;
>
> +free_cq_wq:
> + destroy_workqueue(hdev->cq_wq);
> asid_fini:
> hl_asid_fini(hdev);
> early_fini:
> @@ -205,6 +215,7 @@ static void device_early_fini(struct hl_device *hdev)
>
> hl_cb_mgr_fini(hdev, >kernel_cb_mgr);
>
> + destroy_workqueue(hdev->eq_wq);
> destroy_workqueue(hdev->cq_wq);
>
> hl_asid_fini(hdev);
> @@ -343,11 +354,22 @@ int hl_device_init(struct hl_device *hdev, struct class
> *hclass)
> }
> }
>
> + /*
> + * Initialize the event queue. Must be done before hw_init,
> + * because there the address of the event queue is being
> + * passed as argument to request_irq
> + */
> + rc = hl_eq_init(hdev, >event_queue);
> + if (rc) {
> + dev_err(hdev->dev, "failed to initialize event queue\n");
> + goto cq_fini;
> + }
> +
> /* Allocate the kernel context */
> hdev->kernel_ctx = kzalloc(sizeof(*hdev->kernel_ctx), GFP_KERNEL);
> if (!hdev->kernel_ctx) {
> rc = -ENOMEM;
> - goto cq_fini;
> + goto eq_fini;
> }
>
> hdev->user_ctx = NULL;
> @@ -392,6 +414,8 @@ int hl_device_init(struct hl_device *hdev, struct class
> *hclass)
> "kernel ctx is still alive on initialization
> failure\n");
> free_ctx:
> kfree(hdev->kernel_ctx);
> +eq_fini:
> + hl_eq_fini(hdev, >event_queue);
> cq_fini:
> for (i = 0 ; i < cq_ready_cnt ; i++)
> hl_cq_fini(hdev, >completion_queue[i]);
> @@ -433,6 +457,13 @@ void hl_device_fini(struct hl_device *hdev)
> /* Mark device as disabled */
> hdev->disabled = true;
>
> + /*
> + * Halt the engines and disable interrupts so we won't get any more
> + * completions from H/W and we won't have any accesses from the
> + * H/W to the host machine
> + */
> + hdev->asic_funcs->halt_engines(hdev, true);
> +
> hl_cb_pool_fini(hdev);
>
> /* Release kernel context */
> @@ -442,6 +473,8 @@ void hl_device_fini(struct hl_device *hdev)
> /* Reset the H/W. It will be in idle state after this returns */
> hdev->asic_funcs->hw_fini(hdev, true);
>
> + hl_eq_fini(hdev, >event_queue);
> +
> for (i = 0 ; i < hdev->asic_prop.completion_queues_count ; i++)
>
Re: [PATCH v6 1/4] usb: split code locating ACPI companion into port and device
Hi Rajat, > In preparation for handling embedded USB devices let's split > usb_acpi_find_companion() into usb_acpi_find_companion_for_device() and > usb_acpi_find_companion_for_port(). > > Signed-off-by: Dmitry Torokhov > Signed-off-by: Rajat Jain > Acked-by: Greg Kroah-Hartman > Tested-by: Sukumar Ghorai > --- > v6: same as v4 > v5: same as v4 > v4: Add Acked-by and Tested-by in signatures. > v3: same as v1 > v2: same as v1 > > drivers/usb/core/usb-acpi.c | 133 +++- > 1 file changed, 72 insertions(+), 61 deletions(-) patch has been applied to bluetooth-next tree. Regards Marcel
Re: [PATCH v6 3/4] Bluetooth: Allow driver specific cmd timeout handling
Hi Rajat, > Add a hook to allow the BT driver to do device or command specific > handling in case of timeouts. This is to be used by Intel driver to > reset the device after certain number of timeouts. > > Signed-off-by: Rajat Jain > --- > v6: Dropped the "sent command" parameter from cmd_timeout() > v5: Drop the quirk, and rename the hook function to cmd_timeout() > v4: same as v1 > v3: same as v1 > v2: same as v1 > > include/net/bluetooth/hci_core.h | 1 + > net/bluetooth/hci_core.c | 3 +++ > 2 files changed, 4 insertions(+) patch has been applied to bluetooth-next tree. Regards Marcel
Re: [PATCH v6 4/4] Bluetooth: btusb: Use the cmd_timeout method to reset the Intel BT chip
Hi Rajat, > If the platform provides it, use the reset gpio to reset the Intel BT > chip, as part of cmd_timeout handling. This has been found helpful on > Intel bluetooth controllers where the firmware gets stuck and the only > way out is a hard reset pin provided by the platform. > > Signed-off-by: Rajat Jain > --- > v6: Move the cmd_timeout() hook assignment with other hooks, move the >reset_gpio check in the timeout function. > v5: Rename the hook to cmd_timeout, and wait for 5 timeouts before >resetting the device. > v4: Use data->flags instead of clearing the quirk in btusb_hw_reset() > v3: Better error handling for gpiod_get_optional() > v2: Handle the EPROBE_DEFER case. > > drivers/bluetooth/btusb.c | 54 +++ > 1 file changed, 54 insertions(+) patch has been applied to bluetooth-next tree. Regards Marcel
Re: [PATCH 06/15] habanalabs: add basic Goya h/w initialization
Hi,
This starts the 6-9 review :)
These were more difficult to review because small pieces of code are
interleaved with
large sequences of register writes. Probably making these register data
rather than code can help.
On Wed, Jan 23, 2019 at 02:00:48AM +0200, Oded Gabbay wrote:
> This patch adds the basic part of Goya's H/W initialization. It adds code
> that initializes Goya's internal CPU, various registers that are related to
> internal routing, scrambling, workarounds for H/W bugs, etc.
>
> It also initializes Goya's security scheme that prevents the user from
> abusing Goya to steal data from the host, crash the host, change
> Goya's F/W, etc.
>
> Signed-off-by: Oded Gabbay
> ---
> drivers/misc/habanalabs/device.c | 12 +
> drivers/misc/habanalabs/goya/Makefile |2 +-
> drivers/misc/habanalabs/goya/goya.c | 1892 ++-
> drivers/misc/habanalabs/goya/goyaP.h |3 +
> drivers/misc/habanalabs/goya/goya_security.c | 2999 +
> drivers/misc/habanalabs/habanalabs.h | 16 +
> drivers/misc/habanalabs/habanalabs_drv.c |8 +
> drivers/misc/habanalabs/include/goya/goya.h |1 +
> .../include/goya/goya_async_events.h | 186 +
> .../habanalabs/include/goya/goya_boot_if.h| 32 +
> 10 files changed, 5144 insertions(+), 7 deletions(-)
> create mode 100644 drivers/misc/habanalabs/goya/goya_security.c
> create mode 100644 drivers/misc/habanalabs/include/goya/goya_async_events.h
> create mode 100644 drivers/misc/habanalabs/include/goya/goya_boot_if.h
>
> diff --git a/drivers/misc/habanalabs/device.c
> b/drivers/misc/habanalabs/device.c
> index 0bd86a7d34db..9fc7218a973c 100644
> --- a/drivers/misc/habanalabs/device.c
> +++ b/drivers/misc/habanalabs/device.c
> @@ -315,6 +315,15 @@ int hl_device_init(struct hl_device *hdev, struct class
> *hclass)
> goto release_ctx;
> }
>
> + rc = hdev->asic_funcs->hw_init(hdev);
> + if (rc) {
> + dev_err(hdev->dev, "failed to initialize the H/W\n");
> + rc = 0;
Mistype, I suppose.
> + goto out_disabled;
> + }
> +
> + hdev->disabled = false;
> +
> dev_notice(hdev->dev,
> "Successfully added device to habanalabs driver\n");
>
> @@ -366,6 +375,9 @@ void hl_device_fini(struct hl_device *hdev)
> if ((hdev->kernel_ctx) && (hl_ctx_put(hdev->kernel_ctx) != 1))
> dev_err(hdev->dev, "kernel ctx is still alive\n");
>
> + /* Reset the H/W. It will be in idle state after this returns */
> + hdev->asic_funcs->hw_fini(hdev, true);
> +
> /* Call ASIC S/W finalize function */
> hdev->asic_funcs->sw_fini(hdev);
>
> diff --git a/drivers/misc/habanalabs/goya/Makefile
> b/drivers/misc/habanalabs/goya/Makefile
> index 5ebf3d0d5794..a57096fa41b6 100644
> --- a/drivers/misc/habanalabs/goya/Makefile
> +++ b/drivers/misc/habanalabs/goya/Makefile
> @@ -1,3 +1,3 @@
> subdir-ccflags-y += -I$(src)
>
> -HL_GOYA_FILES := goya/goya.o
> \ No newline at end of file
> +HL_GOYA_FILES := goya/goya.o goya/goya_security.o
> \ No newline at end of file
> diff --git a/drivers/misc/habanalabs/goya/goya.c
> b/drivers/misc/habanalabs/goya/goya.c
> index 341ac085af82..f715e01838b3 100644
> --- a/drivers/misc/habanalabs/goya/goya.c
> +++ b/drivers/misc/habanalabs/goya/goya.c
> @@ -119,11 +119,11 @@ static void goya_get_fixed_properties(struct hl_device
> *hdev)
> prop->va_space_dram_end_address = VA_DDR_SPACE_END;
> prop->cfg_size = CFG_SIZE;
> prop->max_asid = MAX_ASID;
> + prop->cb_pool_cb_cnt = GOYA_CB_POOL_CB_CNT;
> + prop->cb_pool_cb_size = GOYA_CB_POOL_CB_SIZE;
> prop->tpc_enabled_mask = TPC_ENABLED_MASK;
>
> prop->high_pll = PLL_HIGH_DEFAULT;
> - prop->cb_pool_cb_cnt = GOYA_CB_POOL_CB_CNT;
> - prop->cb_pool_cb_size = GOYA_CB_POOL_CB_SIZE;
> }
>
> /**
> @@ -459,10 +459,12 @@ static int goya_early_init(struct hl_device *hdev)
> goto disable_device;
> }
>
> - val = RREG32(mmPSOC_GLOBAL_CONF_BOOT_STRAP_PINS);
> - if (val & PSOC_GLOBAL_CONF_BOOT_STRAP_PINS_SRIOV_EN_MASK)
> - dev_warn(hdev->dev,
> - "PCI strap is not configured correctly, PCI bus errors
> may occur\n");
> + if (!hdev->pldm) {
> + val = RREG32(mmPSOC_GLOBAL_CONF_BOOT_STRAP_PINS);
What is the purpose of the 'mm' prefix in register names?
> + if (val & PSOC_GLOBAL_CONF_BOOT_STRAP_PINS_SRIOV_EN_MASK)
> + dev_warn(hdev->dev,
> + "PCI strap is not configured correctly, PCI bus
> errors may occur\n");
> + }
>
> return 0;
>
> @@ -593,6 +595,1882 @@ int goya_sw_fini(struct hl_device *hdev)
> return 0;
> }
>
> +/**
> + * goya_init_pll - Initialize pll registers
> + *
> + * @hdev: pointer to hl_device structure
> + *
> + */
> +static void goya_init_pll(struct hl_device *hdev)
> +{
> +
Re: [v4] dt-bindings: ahci-fsl-qoriq: add lx2160a chip name to the list
Hello! On 25.01.2019 6:32, Peng Ma wrote: Add lxx2160a compatible to bindings documentation. lx2160a? Signed-off-by: Peng Ma --- changed for V4: - add lx2160a compatible to bindings doc .../devicetree/bindings/ata/ahci-fsl-qoriq.txt |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt index 7c3ca0e..9ecc019 100644 --- a/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt +++ b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt @@ -3,7 +3,7 @@ Binding for Freescale QorIQ AHCI SATA Controller Required properties: - reg: Physical base address and size of the controller's register area. - compatible: Compatibility string. Must be 'fsl,-ahci', where -chip could be ls1021a, ls1043a, ls1046a, ls1088a, ls2080a etc. +chip could be ls1021a, ls1043a, ls1046a, ls1088a, ls2080a, lx2160a, etc. - clocks: Input clock specifier. Refer to common clock bindings. - interrupts: Interrupt specifier. Refer to interrupt binding. MBR, Sergei
[PATCH] pinctrl: berlin: as370: use generic "pwm" as pwm function name
So that we could use the generic "pwm" for two or more pins, e.g
pwm0_pmux: pwm0-pmux {
groups = "PWM0", "PWM1";
function = "pwm";
};
Signed-off-by: Jisheng Zhang
---
drivers/pinctrl/berlin/pinctrl-as370.c | 58 +-
1 file changed, 29 insertions(+), 29 deletions(-)
diff --git a/drivers/pinctrl/berlin/pinctrl-as370.c
b/drivers/pinctrl/berlin/pinctrl-as370.c
index d2bb811fc5fa..44f8ccdbeeff 100644
--- a/drivers/pinctrl/berlin/pinctrl-as370.c
+++ b/drivers/pinctrl/berlin/pinctrl-as370.c
@@ -36,13 +36,13 @@ static const struct berlin_desc_group
as370_soc_pinctrl_groups[] = {
BERLIN_PINCTRL_GROUP("I2S1_DO2", 0x0, 0x3, 0x0c,
BERLIN_PINCTRL_FUNCTION(0x0, "por"), /* CORE RSTB */
BERLIN_PINCTRL_FUNCTION(0x1, "i2s1"), /* DO2 */
- BERLIN_PINCTRL_FUNCTION(0x2, "pwm4"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "pwm"), /* PWM4 */
BERLIN_PINCTRL_FUNCTION(0x3, "gpio"), /* GPIO4 */
BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG4 */
BERLIN_PINCTRL_GROUP("I2S1_DO3", 0x0, 0x3, 0x0f,
BERLIN_PINCTRL_FUNCTION(0x0, "gpio"), /* GPIO5 */
BERLIN_PINCTRL_FUNCTION(0x1, "i2s1"), /* DO3 */
- BERLIN_PINCTRL_FUNCTION(0x2, "pwm5"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "pwm"), /* PWM5 */
BERLIN_PINCTRL_FUNCTION(0x3, "spififib"), /* SPDIFIB */
BERLIN_PINCTRL_FUNCTION(0x4, "spdifo"), /* SPDIFO */
BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG5 */
@@ -61,24 +61,24 @@ static const struct berlin_desc_group
as370_soc_pinctrl_groups[] = {
BERLIN_PINCTRL_GROUP("I2S2_DI0", 0x0, 0x3, 0x1b,
BERLIN_PINCTRL_FUNCTION(0x0, "gpio"), /* GPIO9 */
BERLIN_PINCTRL_FUNCTION(0x1, "i2s2"), /* DI0 */
- BERLIN_PINCTRL_FUNCTION(0x2, "pwm2"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "pwm"), /* PWM2 */
BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG9 */
BERLIN_PINCTRL_GROUP("I2S2_DI1", 0x4, 0x3, 0x00,
BERLIN_PINCTRL_FUNCTION(0x0, "gpio"), /* GPIO10 */
BERLIN_PINCTRL_FUNCTION(0x1, "i2s2"), /* DI1 */
- BERLIN_PINCTRL_FUNCTION(0x2, "pwm3"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "pwm"), /* PWM3 */
BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG10 */
BERLIN_PINCTRL_GROUP("I2S2_DI2", 0x4, 0x3, 0x03,
BERLIN_PINCTRL_FUNCTION(0x0, "gpio"), /* GPIO11 */
BERLIN_PINCTRL_FUNCTION(0x1, "i2s2"), /* DI2 */
- BERLIN_PINCTRL_FUNCTION(0x2, "pwm6"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "pwm"), /* PWM6 */
BERLIN_PINCTRL_FUNCTION(0x3, "spdific"), /* SPDIFIC */
BERLIN_PINCTRL_FUNCTION(0x4, "spdifo"), /* SPDIFO */
BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG11 */
BERLIN_PINCTRL_GROUP("I2S2_DI3", 0x4, 0x3, 0x06,
BERLIN_PINCTRL_FUNCTION(0x0, "gpio"), /* GPIO12 */
BERLIN_PINCTRL_FUNCTION(0x1, "i2s2"), /* DI3 */
- BERLIN_PINCTRL_FUNCTION(0x2, "pwm7"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "pwm"), /* PWM7 */
BERLIN_PINCTRL_FUNCTION(0x3, "spdifia"), /* SPDIFIA */
BERLIN_PINCTRL_FUNCTION(0x4, "spdifo"), /* SPDIFO */
BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG12 */
@@ -98,14 +98,14 @@ static const struct berlin_desc_group
as370_soc_pinctrl_groups[] = {
BERLIN_PINCTRL_GROUP("PDM_DI2", 0x4, 0x3, 0x12,
BERLIN_PINCTRL_FUNCTION(0x0, "gpio"), /* GPIO16 */
BERLIN_PINCTRL_FUNCTION(0x1, "pdm"), /* DI2 */
- BERLIN_PINCTRL_FUNCTION(0x2, "pwm4"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "pwm"), /* PWM4 */
BERLIN_PINCTRL_FUNCTION(0x3, "spdifid"), /* SPDIFID */
BERLIN_PINCTRL_FUNCTION(0x4, "spdifo"), /* SPDIFO */
BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG16 */
BERLIN_PINCTRL_GROUP("PDM_DI3", 0x4, 0x3, 0x15,
BERLIN_PINCTRL_FUNCTION(0x0, "gpio"), /* GPIO17 */
BERLIN_PINCTRL_FUNCTION(0x1, "pdm"), /* DI3 */
- BERLIN_PINCTRL_FUNCTION(0x2, "pwm5"),
+ BERLIN_PINCTRL_FUNCTION(0x2, "pwm"), /* PWM5 */
BERLIN_PINCTRL_FUNCTION(0x3, "spdifi"), /* SPDIFI */
BERLIN_PINCTRL_FUNCTION(0x4, "spdifo"), /* SPDIFO */
BERLIN_PINCTRL_FUNCTION(0x5, "phy")), /* DBG17 */
@@ -139,11 +139,11
Re: [PATCH 00/15] Habana Labs kernel driver
On Fri, Jan 25, 2019 at 1:14 AM Olof Johansson wrote: > > On Thu, Jan 24, 2019 at 2:23 AM Dave Airlie wrote: > > > > > I know I won't be able to convince you but I want to say that I think > > > your arguments for full userspace open source are not really > > > technical. > > > > There is more to keeping a kernel going than technical argument > > unfortunately. > > > > I guess the question for Greg, Olof etc, is do we care about Linux the > > kernel, or Linux the open source ecosystem, if the former, these sort > > of accelerator shim drivers are fine, useless to anyone who doesn't > > have all the magic hidden userspace, and impossible to support for > > anyone else, if the latter, we should leave the cost of maintenance to > > the company benefiting from it and leave maintaining it out of tree. > > As mentioned in my reply to Daniel, I think we've got a history of > being pragmatic and finding reasonable trade-offs of what can be open > and what can be closed. For example, if truly care about open source > ecosystem, drivers that require closed firmware should also be > refused. Firmware has traditionally been different since usually it's looked down, doesn't do much wrt functionality (dumb fifo scheduling at best, not really power management) and so could be reasonably shrugged off as "it's part of hw". If you care about the open graphics ecosystem, i.e. your ability to port the stack to new cpu architectures, new window systems (e.g. android -> xorg, or xorg -> android, or something entirely new like wayland), new, more efficient client interface (vulkan is a very new fad), then having a closed firmware is not going to be a problem. Closed compiler, closed runtime, closed anything else otoh is a serious practical pain. Unfortunately hw vendors seem to have realized that we (overall community of customers, distro, upstream) are not insisting on open firmware, so they're moving a lot of "valuable sauce" (no really, it's not) into the firmware. PM governors, cpu scheduling algorithms, that kind of stuff. We're not pleased, and there's lots of people doing the behind the scenes work to fix it. One practical problem is that even if we've demonstrated that r/e'ing a uc is no bigger challenge than anything, there's usually this pesky issue with signatures. So we can't force the vendors like we can with the userspace side. Otherwise nouveau would have completely open firmware even for latest chips (like it has for olders). > > Simple question like If I plug your accelerator into Power or ARM64, > > where do I get the port of your userspace to use it? > > Does demanding complete open userspace get us closer to that goal in > reality? By refusing to work with people to enable their hardware, > they will still ship their platforms out of tree, using DKMS and all > the other ways of getting kernel modules installed to talk to the > hardware. And we'd be no closer. > > In the end, they'd open up their userspace when there's business > reasons to do so. It's well-known how to work around refusal from us > to merge drivers by now, so it's not much leverage in that area. Correct. None of the hw vendors had a business reason to open source anything unforunately. Yes, eventually customers started demanding open source and treatening to buy the competition, but this only works if you have multiple reasonably performant & conformant stacks for different vendors. The only way to get these is to reverse engineer them. Now reverse-engineering is a major pain in itself (despite all the great tooling gpu folks developed over the past 10 years to convert it from a black art to a repeatable engineering excercise), but if you additionally prefer the vendors closed stack (which you do by allowing to get them to get merged) the r/e'd stack has no chance. And there is not other way to get your open source stack. I can't really go into all the details of the past 15+ of open source gpus, but without the pressure of other r/e'ed stacks and the pressure of having stacks for competitiors (all made possible through aggressive code sharing) we would have 0 open source gfx stacks. All the ones we have either got started with r/e first (and eventually the vendor jumped on board) or survived through r/e and customer efforts (because the vendor planned to abandon it). Another part of this is that we accept userspace only when it's the common upstream (if there is one), to prevent vendors closing down their stacks gradually. So yeah I think by not clearly preferring open source over stacks-with-blobs (how radically you do that is a bit a balance act in the end, I think we've maxed out in drivers/gpu on what's practically possible) you'll just make sure that there's never going to be a serious open source stack. > > I'm not the final arbiter on this sort of thing, but I'm definitely > > going to make sure that anyone who lands this code is explicit in > > ignoring any experience we've had in this area and in the future will > >
Re: [PATCH] Bluetooth: hci_ldisc: Fix for pty driver
Hi Myungho, > tty_set_termios() should be called with slave side of pty driver. So, If > tty driver is pty master, it needs to be switched to ->link. Also, > tiocmget() and tiocmset() operations are optional so we need NULL check > for some drivers missing the operations like pty. these are two independent fixes. Please turn them into two patches. Regards Marcel
[PATCH] i3c: fix missing detach if failed to retrieve i3c dev
If we failed to retrieve the i3c dev, we should detach the i3c dev
I.E i3c_master_detach_i3c_dev().
Signed-off-by: Jisheng Zhang
---
drivers/i3c/master.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
index c39f89d2deba..2dc628d4f1ae 100644
--- a/drivers/i3c/master.c
+++ b/drivers/i3c/master.c
@@ -1828,7 +1828,7 @@ int i3c_master_add_i3c_dev_locked(struct
i3c_master_controller *master,
ret = i3c_master_retrieve_dev_info(newdev);
if (ret)
- goto err_free_dev;
+ goto err_detach_dev;
olddev = i3c_master_search_i3c_dev_duplicate(newdev);
if (olddev) {
--
2.20.1
Re: [PATCH 00/15] Habana Labs kernel driver
On Thu, Jan 24, 2019 at 07:57:11AM +1000, Dave Airlie wrote: > On Wed, 23 Jan 2019 at 10:01, Oded Gabbay wrote: > > > > Hello, > > > > For those who don't know me, my name is Oded Gabbay (Kernel Maintainer > > for AMD's amdkfd driver, worked at RedHat's Desktop group) and I work at > > Habana Labs since its inception two and a half years ago. > > Hey Oded, > > So this creates a driver with a userspace facing API via ioctls. > Although this isn't a "GPU" driver we have a rule in the graphics > drivers are for accelerators that we don't merge userspace API with an > appropriate userspace user. > > https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements > > I see nothing in these accelerator drivers that make me think we > should be treating them different. I understand that this is your position on when you accept drivers into the DRM layer, as you need to interact with common interfaces and a massive userspace stack at the same time. And that's wonderful, it allows you to be able to move both sides of that stack forward without removing support for devices that worked on older kernels. But, that's not really the case with this new driver at all. We add new driver subsystems, and individual drivers, with loads of new ioctls, in every new kernel release. We don't impose on all of them the "your userspace code must be open" rule, so why is this new driver somehow different from them? Yes, there is the fun legal issue of "derivative works" when talking about a userspace program that is written to only interact with a specific kernel driver using a custom api like this one has, and how the license of the kernel side (GPLv2) affects the userspace side (whatever), but that is something that I leave up to the lawyers who like discussing and enforcing such things. When evaluating this driver (note, I saw it for a few revisions before Oded posted it here), all I did was try to make sure that it fit in properly with the kernel apis and methods of operations. Given that there are no in-kernel drivers for this type of device, and that it really is a pretty small shim layer around the hardware, which means that userspace does a lot of the heavy lifting, it is going to be a very hardware-specific user/kernel api, and that shows. Sidenote, this could have almost just been a UIO driver, which would have put _ALL_ of the logic in userspace. At least this way we have a chance for the kernel code to be sane and not try to inflict problems on the rest of the system. Going forward, it would be wonderful if we could come up with a unified api for how to interact with these types of hardware accelerators, but given the newness of this industry, and the vastly different ways people are trying to solve the problem, that is going to take a few attempts, and many years before we can get there. Until then, taking drivers like this into the kernel tree makes sense as that way all of our users will be able to use that hardware, and better yet, the rest of us can learn more about how this stuff works so that we can help out with that api generation when it happens. So for now, I have no objection to taking this type of driver into the tree. Yes, it would be wonderful if we had an open userspace program to drive it so that we could actually test and make changes to the api over time, but I think that is something that the submitting company needs to realize will be better for them to do, as for right now, all of that testing and changes are their responsibility. As for what directory the code should live in, I suggested "misc" as there was no other universal location, and I hate to see new subsystems be created with only one driver, as that's pretty sad. But it's just a name/location, I have no dog in the fight, so I really don't care where it ends up in the tree, just as long as it gets merged somewhere :) thanks, greg k-h
Re: kernel panic due to https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2830bf6f05fb3e05bc4743274b806c821807a684
On Fri 25-01-19 17:48:32, Linus Torvalds wrote: > [ Just adding a lot of other people to the cc ] > > Robert, could you add a dmesg of a successful boot to that bugzilla, > or just as an attachement in email to this group of people.. > > This looks to be with the Fedora kernel config. Two people reporting > it, it looks like similar machines. > > I assume it's some odd memory sizing detail that happens to trigger a > particular case. Quite possible. > I absolutely *hate* those "let's lazily clear 'struct page' array" > patches. They've caused problems before, and I'm not convinced the > pain has been worth it. Maybe we should revert them (again) and > promise to never ever take things like that again? Andrew? The performance numbers were pretty dramatic on the other hand. This was especially seen for very large NVDIMMs initialization when a userspace was timing out without these applied. I am certainly not very happy about regressions which we still do see. I was worried about that early when reviewing these patches because it is really hard to find all those weird places which simply happened to work even when broken before. E.g. unitialized struct pages were simply with zeroed and that means that they seemed to belong to node zero and zone DMA and nothing really blown up. With the poisoning in place we have an explicit VM_BUG_ON and Fedora kernels do enable VM debugging so those problems are visible. I still think we should chase after those issue and fix them regardless. Lazy initialization revert will not solve those problems. It will just paper over them. -- Michal Hocko SUSE Labs
[PATCH] f2fs: fix typos in code comments
lengh -> length
Signed-off-by: Geliang Tang
---
include/linux/f2fs_fs.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/f2fs_fs.h b/include/linux/f2fs_fs.h
index d7711048ef93..624b8a47d3c6 100644
--- a/include/linux/f2fs_fs.h
+++ b/include/linux/f2fs_fs.h
@@ -186,7 +186,7 @@ struct f2fs_orphan_block {
struct f2fs_extent {
__le32 fofs;/* start file offset of the extent */
__le32 blk; /* start block address of the extent */
- __le32 len; /* lengh of the extent */
+ __le32 len; /* length of the extent */
} __packed;
#define F2FS_NAME_LEN 255
@@ -511,7 +511,7 @@ typedef __le32 f2fs_hash_t;
struct f2fs_dir_entry {
__le32 hash_code; /* hash code of file name */
__le32 ino; /* inode number */
- __le16 name_len;/* lengh of file name */
+ __le16 name_len;/* length of file name */
__u8 file_type; /* file type */
} __packed;
--
2.17.1
[PATCH] KVM: x86: fix TRACE_INCLUDE_PATH and remove -I. header search paths
The header search path -I. in kernel Makefiles is very suspicious; it allows the compiler to search for headers in the top of $(srctree), where obviously no header file exists. The reason of having -I. here is to make the incorrectly set TRACE_INCLUDE_PATH working. As the comment block in include/trace/define_trace.h says, TRACE_INCLUDE_PATH should be a relative path to the define_trace.h Fix the TRACE_INCLUDE_PATH, and remove the iffy include paths. Signed-off-by: Masahiro Yamada --- arch/x86/kvm/Makefile | 4 arch/x86/kvm/trace.h | 2 +- 2 files changed, 1 insertion(+), 5 deletions(-) diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile index 69b3a7c..31ecf7a 100644 --- a/arch/x86/kvm/Makefile +++ b/arch/x86/kvm/Makefile @@ -2,10 +2,6 @@ ccflags-y += -Iarch/x86/kvm -CFLAGS_x86.o := -I. -CFLAGS_svm.o := -I. -CFLAGS_vmx.o := -I. - KVM := ../../../virt/kvm kvm-y += $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o \ diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h index 705f40a..6432d08 100644 --- a/arch/x86/kvm/trace.h +++ b/arch/x86/kvm/trace.h @@ -1465,7 +1465,7 @@ TRACE_EVENT(kvm_hv_send_ipi_ex, #endif /* _TRACE_KVM_H */ #undef TRACE_INCLUDE_PATH -#define TRACE_INCLUDE_PATH arch/x86/kvm +#define TRACE_INCLUDE_PATH ../../arch/x86/kvm #undef TRACE_INCLUDE_FILE #define TRACE_INCLUDE_FILE trace -- 2.7.4
[PATCH] i3c: master: dw: fix deadlock
In dw_i3c_master_irq_handler(), we already have gotten
>xferqueue.lock, if we try to get the same lock again in
dw_i3c_master_dequeue_xfer(), deadlock happens.
We fix this issue by introduing dw_i3c_master_dequeue_xfer_locked()
which does all what dw_i3c_master_dequeue_xfer() does without trying
to lock >xferqueue.lock.
Signed-off-by: Jisheng Zhang
---
drivers/i3c/master/dw-i3c-master.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/i3c/master/dw-i3c-master.c
b/drivers/i3c/master/dw-i3c-master.c
index f8c00b94817f..bb03079fbade 100644
--- a/drivers/i3c/master/dw-i3c-master.c
+++ b/drivers/i3c/master/dw-i3c-master.c
@@ -419,12 +419,9 @@ static void dw_i3c_master_enqueue_xfer(struct
dw_i3c_master *master,
spin_unlock_irqrestore(>xferqueue.lock, flags);
}
-static void dw_i3c_master_dequeue_xfer(struct dw_i3c_master *master,
- struct dw_i3c_xfer *xfer)
+static void dw_i3c_master_dequeue_xfer_locked(struct dw_i3c_master *master,
+ struct dw_i3c_xfer *xfer)
{
- unsigned long flags;
-
- spin_lock_irqsave(>xferqueue.lock, flags);
if (master->xferqueue.cur == xfer) {
u32 status;
@@ -439,6 +436,15 @@ static void dw_i3c_master_dequeue_xfer(struct
dw_i3c_master *master,
} else {
list_del_init(>node);
}
+}
+
+static void dw_i3c_master_dequeue_xfer(struct dw_i3c_master *master,
+ struct dw_i3c_xfer *xfer)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(>xferqueue.lock, flags);
+ dw_i3c_master_dequeue_xfer_locked(master, xfer);
spin_unlock_irqrestore(>xferqueue.lock, flags);
}
@@ -494,7 +500,7 @@ static void dw_i3c_master_end_xfer_locked(struct
dw_i3c_master *master, u32 isr)
complete(>comp);
if (ret < 0) {
- dw_i3c_master_dequeue_xfer(master, xfer);
+ dw_i3c_master_dequeue_xfer_locked(master, xfer);
writel(readl(master->regs + DEVICE_CTRL) | DEV_CTRL_RESUME,
master->regs + DEVICE_CTRL);
}
--
2.20.1
Re: [PATCH 1/2] mm: Create mem_cgroup_from_seq
On Thu 24-01-19 14:40:50, Chris Down wrote:
> This is the start of a series of patches similar to my earlier
> DEFINE_MEMCG_MAX_OR_VAL work, but with less Macro Magic(tm).
>
> There are a bunch of places we go from seq_file to mem_cgroup, which
> currently requires manually getting the css, then getting the mem_cgroup
> from the css. It's in enough places now that having mem_cgroup_from_seq
> makes sense (and also makes the next patch a bit nicer).
>
> Signed-off-by: Chris Down
> Cc: Andrew Morton
> Cc: Johannes Weiner
> Cc: Tejun Heo
> Cc: Roman Gushchin
> Cc: linux-kernel@vger.kernel.org
> Cc: cgro...@vger.kernel.org
> Cc: linux...@kvack.org
> Cc: kernel-t...@fb.com
Acked-by: Michal Hocko
> ---
> include/linux/memcontrol.h | 10 ++
> mm/memcontrol.c| 24
> mm/slab_common.c | 6 +++---
> 3 files changed, 25 insertions(+), 15 deletions(-)
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index b0eb29ea0d9c..1f3d880b7ca1 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -429,6 +429,11 @@ static inline unsigned short mem_cgroup_id(struct
> mem_cgroup *memcg)
> }
> struct mem_cgroup *mem_cgroup_from_id(unsigned short id);
>
> +static inline struct mem_cgroup *mem_cgroup_from_seq(struct seq_file *m)
> +{
> + return mem_cgroup_from_css(seq_css(m));
> +}
> +
> static inline struct mem_cgroup *lruvec_memcg(struct lruvec *lruvec)
> {
> struct mem_cgroup_per_node *mz;
> @@ -937,6 +942,11 @@ static inline struct mem_cgroup
> *mem_cgroup_from_id(unsigned short id)
> return NULL;
> }
>
> +static inline struct mem_cgroup *mem_cgroup_from_seq(struct seq_file *m)
> +{
> + return NULL;
> +}
> +
> static inline struct mem_cgroup *lruvec_memcg(struct lruvec *lruvec)
> {
> return NULL;
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 18f4aefbe0bf..98aad31f5226 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3359,7 +3359,7 @@ static int memcg_numa_stat_show(struct seq_file *m,
> void *v)
> const struct numa_stat *stat;
> int nid;
> unsigned long nr;
> - struct mem_cgroup *memcg = mem_cgroup_from_css(seq_css(m));
> + struct mem_cgroup *memcg = mem_cgroup_from_seq(m);
>
> for (stat = stats; stat < stats + ARRAY_SIZE(stats); stat++) {
> nr = mem_cgroup_nr_lru_pages(memcg, stat->lru_mask);
> @@ -3410,7 +3410,7 @@ static const char *const memcg1_event_names[] = {
>
> static int memcg_stat_show(struct seq_file *m, void *v)
> {
> - struct mem_cgroup *memcg = mem_cgroup_from_css(seq_css(m));
> + struct mem_cgroup *memcg = mem_cgroup_from_seq(m);
> unsigned long memory, memsw;
> struct mem_cgroup *mi;
> unsigned int i;
> @@ -3842,7 +3842,7 @@ static void mem_cgroup_oom_unregister_event(struct
> mem_cgroup *memcg,
>
> static int mem_cgroup_oom_control_read(struct seq_file *sf, void *v)
> {
> - struct mem_cgroup *memcg = mem_cgroup_from_css(seq_css(sf));
> + struct mem_cgroup *memcg = mem_cgroup_from_seq(sf);
>
> seq_printf(sf, "oom_kill_disable %d\n", memcg->oom_kill_disable);
> seq_printf(sf, "under_oom %d\n", (bool)memcg->under_oom);
> @@ -5385,7 +5385,7 @@ static u64 memory_current_read(struct
> cgroup_subsys_state *css,
>
> static int memory_min_show(struct seq_file *m, void *v)
> {
> - struct mem_cgroup *memcg = mem_cgroup_from_css(seq_css(m));
> + struct mem_cgroup *memcg = mem_cgroup_from_seq(m);
> unsigned long min = READ_ONCE(memcg->memory.min);
>
> if (min == PAGE_COUNTER_MAX)
> @@ -5415,7 +5415,7 @@ static ssize_t memory_min_write(struct kernfs_open_file
> *of,
>
> static int memory_low_show(struct seq_file *m, void *v)
> {
> - struct mem_cgroup *memcg = mem_cgroup_from_css(seq_css(m));
> + struct mem_cgroup *memcg = mem_cgroup_from_seq(m);
> unsigned long low = READ_ONCE(memcg->memory.low);
>
> if (low == PAGE_COUNTER_MAX)
> @@ -5445,7 +5445,7 @@ static ssize_t memory_low_write(struct kernfs_open_file
> *of,
>
> static int memory_high_show(struct seq_file *m, void *v)
> {
> - struct mem_cgroup *memcg = mem_cgroup_from_css(seq_css(m));
> + struct mem_cgroup *memcg = mem_cgroup_from_seq(m);
> unsigned long high = READ_ONCE(memcg->high);
>
> if (high == PAGE_COUNTER_MAX)
> @@ -5482,7 +5482,7 @@ static ssize_t memory_high_write(struct
> kernfs_open_file *of,
>
> static int memory_max_show(struct seq_file *m, void *v)
> {
> - struct mem_cgroup *memcg = mem_cgroup_from_css(seq_css(m));
> + struct mem_cgroup *memcg = mem_cgroup_from_seq(m);
> unsigned long max = READ_ONCE(memcg->memory.max);
>
> if (max == PAGE_COUNTER_MAX)
> @@ -5544,7 +5544,7 @@ static ssize_t memory_max_write(struct kernfs_open_file
> *of,
>
> static int memory_events_show(struct seq_file *m, void *v)
> {
> - struct mem_cgroup *memcg =
Re: [PATCH 2/2] mm: Extract memcg maxable seq_file logic to seq_show_memcg_tunable
On Thu 24-01-19 14:41:00, Chris Down wrote:
> memcg has a significant number of files exposed to kernfs where their
> value is either exposed directly or is "max" in the case of
> PAGE_COUNTER_MAX.
>
> This patch makes this generic by providing a single function to do this
> work. In combination with the previous patch adding mem_cgroup_from_seq,
> this makes all of the seq_show feeder functions significantly more
> simple.
Yeah this is what I've had in mind when mentioning a helper in the
previous version of the patch. I like this more even though the
resulting savings are not that large.
> Signed-off-by: Chris Down
> Cc: Andrew Morton
> Cc: Johannes Weiner
> Cc: Tejun Heo
> Cc: Roman Gushchin
> Cc: linux-kernel@vger.kernel.org
> Cc: cgro...@vger.kernel.org
> Cc: linux...@kvack.org
> Cc: kernel-t...@fb.com
Acked-by: Michal Hocko
> ---
> mm/memcontrol.c | 64 +++--
> 1 file changed, 19 insertions(+), 45 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 98aad31f5226..81b6f752471a 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -5375,6 +5375,16 @@ static void mem_cgroup_bind(struct cgroup_subsys_state
> *root_css)
> root_mem_cgroup->use_hierarchy = false;
> }
>
> +static int seq_puts_memcg_tunable(struct seq_file *m, unsigned long value)
> +{
> + if (value == PAGE_COUNTER_MAX)
> + seq_puts(m, "max\n");
> + else
> + seq_printf(m, "%llu\n", (u64)value * PAGE_SIZE);
> +
> + return 0;
> +}
> +
> static u64 memory_current_read(struct cgroup_subsys_state *css,
> struct cftype *cft)
> {
> @@ -5385,15 +5395,8 @@ static u64 memory_current_read(struct
> cgroup_subsys_state *css,
>
> static int memory_min_show(struct seq_file *m, void *v)
> {
> - struct mem_cgroup *memcg = mem_cgroup_from_seq(m);
> - unsigned long min = READ_ONCE(memcg->memory.min);
> -
> - if (min == PAGE_COUNTER_MAX)
> - seq_puts(m, "max\n");
> - else
> - seq_printf(m, "%llu\n", (u64)min * PAGE_SIZE);
> -
> - return 0;
> + return seq_puts_memcg_tunable(m,
> + READ_ONCE(mem_cgroup_from_seq(m)->memory.min));
> }
>
> static ssize_t memory_min_write(struct kernfs_open_file *of,
> @@ -5415,15 +5418,8 @@ static ssize_t memory_min_write(struct
> kernfs_open_file *of,
>
> static int memory_low_show(struct seq_file *m, void *v)
> {
> - struct mem_cgroup *memcg = mem_cgroup_from_seq(m);
> - unsigned long low = READ_ONCE(memcg->memory.low);
> -
> - if (low == PAGE_COUNTER_MAX)
> - seq_puts(m, "max\n");
> - else
> - seq_printf(m, "%llu\n", (u64)low * PAGE_SIZE);
> -
> - return 0;
> + return seq_puts_memcg_tunable(m,
> + READ_ONCE(mem_cgroup_from_seq(m)->memory.low));
> }
>
> static ssize_t memory_low_write(struct kernfs_open_file *of,
> @@ -5445,15 +5441,7 @@ static ssize_t memory_low_write(struct
> kernfs_open_file *of,
>
> static int memory_high_show(struct seq_file *m, void *v)
> {
> - struct mem_cgroup *memcg = mem_cgroup_from_seq(m);
> - unsigned long high = READ_ONCE(memcg->high);
> -
> - if (high == PAGE_COUNTER_MAX)
> - seq_puts(m, "max\n");
> - else
> - seq_printf(m, "%llu\n", (u64)high * PAGE_SIZE);
> -
> - return 0;
> + return seq_puts_memcg_tunable(m,
> READ_ONCE(mem_cgroup_from_seq(m)->high));
> }
>
> static ssize_t memory_high_write(struct kernfs_open_file *of,
> @@ -5482,15 +5470,8 @@ static ssize_t memory_high_write(struct
> kernfs_open_file *of,
>
> static int memory_max_show(struct seq_file *m, void *v)
> {
> - struct mem_cgroup *memcg = mem_cgroup_from_seq(m);
> - unsigned long max = READ_ONCE(memcg->memory.max);
> -
> - if (max == PAGE_COUNTER_MAX)
> - seq_puts(m, "max\n");
> - else
> - seq_printf(m, "%llu\n", (u64)max * PAGE_SIZE);
> -
> - return 0;
> + return seq_puts_memcg_tunable(m,
> + READ_ONCE(mem_cgroup_from_seq(m)->memory.max));
> }
>
> static ssize_t memory_max_write(struct kernfs_open_file *of,
> @@ -6622,15 +6603,8 @@ static u64 swap_current_read(struct
> cgroup_subsys_state *css,
>
> static int swap_max_show(struct seq_file *m, void *v)
> {
> - struct mem_cgroup *memcg = mem_cgroup_from_seq(m);
> - unsigned long max = READ_ONCE(memcg->swap.max);
> -
> - if (max == PAGE_COUNTER_MAX)
> - seq_puts(m, "max\n");
> - else
> - seq_printf(m, "%llu\n", (u64)max * PAGE_SIZE);
> -
> - return 0;
> + return seq_puts_memcg_tunable(m,
> + READ_ONCE(mem_cgroup_from_seq(m)->swap.max));
> }
>
> static ssize_t swap_max_write(struct kernfs_open_file *of,
> --
> 2.20.1
--
Michal Hocko
SUSE Labs
[PATCH] lightnvm: pblk: fix TRACE_INCLUDE_PATH
As the comment block in include/trace/define_trace.h says, TRACE_INCLUDE_PATH should be a relative path to the define_trace.h ../../drivers/lightnvm is the correct relative path. ../../../drivers/lightnvm is working by coincidence because the top Makefile adds -I$(srctree)/arch/$(SRCARCH)/include as a header search path, but we should not rely on it. Signed-off-by: Masahiro Yamada --- drivers/lightnvm/pblk-trace.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/lightnvm/pblk-trace.h b/drivers/lightnvm/pblk-trace.h index 679e5c45..9534503 100644 --- a/drivers/lightnvm/pblk-trace.h +++ b/drivers/lightnvm/pblk-trace.h @@ -139,7 +139,7 @@ TRACE_EVENT(pblk_state, /* This part must be outside protection */ #undef TRACE_INCLUDE_PATH -#define TRACE_INCLUDE_PATH ../../../drivers/lightnvm +#define TRACE_INCLUDE_PATH ../../drivers/lightnvm #undef TRACE_INCLUDE_FILE #define TRACE_INCLUDE_FILE pblk-trace #include -- 2.7.4
[PATCH] cpufreq: Use struct kobj_attribute instead of struct global_attr
The cpufreq_global_kobject is created using kobject_create_and_add()
helper, which assigns the kobj_type as dynamic_kobj_ktype and show/store
routines are set to kobj_attr_show() and kobj_attr_store().
These routines pass struct kobj_attribute as an argument to the
show/store callbacks. But all the cpufreq files created using the
cpufreq_global_kobject expect the argument to be of type struct
attribute. Things work fine currently as no one accesses the "attr"
argument. We may not see issues even if the argument is used, as struct
kobj_attribute has struct attribute as its first element and so they
will both get same address.
But this is logically incorrect and we should rather use struct
kobj_attribute instead of struct global_attr in the cpufreq core and
drivers and the show/store callbacks should take struct kobj_attribute
as argument instead.
This bug is caught using CFI CLANG builds in android kernel which
catches mismatch in function prototypes for such callbacks.
Reported-by: Donghee Han
Reported-by: Sangkyu Kim
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 6 +++---
drivers/cpufreq/intel_pstate.c | 23 ---
include/linux/cpufreq.h| 12 ++--
3 files changed, 17 insertions(+), 24 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index e35a886e00bc..ef0e33e21b98 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -545,13 +545,13 @@ EXPORT_SYMBOL_GPL(cpufreq_policy_transition_delay_us);
* SYSFS INTERFACE *
*/
static ssize_t show_boost(struct kobject *kobj,
-struct attribute *attr, char *buf)
+ struct kobj_attribute *attr, char *buf)
{
return sprintf(buf, "%d\n", cpufreq_driver->boost_enabled);
}
-static ssize_t store_boost(struct kobject *kobj, struct attribute *attr,
- const char *buf, size_t count)
+static ssize_t store_boost(struct kobject *kobj, struct kobj_attribute *attr,
+ const char *buf, size_t count)
{
int ret, enable;
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index dd66decf2087..5ab6a4fe93aa 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -895,7 +895,7 @@ static void intel_pstate_update_policies(void)
/** sysfs begin /
#define show_one(file_name, object)\
static ssize_t show_##file_name \
- (struct kobject *kobj, struct attribute *attr, char *buf) \
+ (struct kobject *kobj, struct kobj_attribute *attr, char *buf) \
{ \
return sprintf(buf, "%u\n", global.object); \
}
@@ -904,7 +904,7 @@ static ssize_t intel_pstate_show_status(char *buf);
static int intel_pstate_update_status(const char *buf, size_t size);
static ssize_t show_status(struct kobject *kobj,
- struct attribute *attr, char *buf)
+ struct kobj_attribute *attr, char *buf)
{
ssize_t ret;
@@ -915,7 +915,7 @@ static ssize_t show_status(struct kobject *kobj,
return ret;
}
-static ssize_t store_status(struct kobject *a, struct attribute *b,
+static ssize_t store_status(struct kobject *a, struct kobj_attribute *b,
const char *buf, size_t count)
{
char *p = memchr(buf, '\n', count);
@@ -929,7 +929,7 @@ static ssize_t store_status(struct kobject *a, struct
attribute *b,
}
static ssize_t show_turbo_pct(struct kobject *kobj,
- struct attribute *attr, char *buf)
+ struct kobj_attribute *attr, char *buf)
{
struct cpudata *cpu;
int total, no_turbo, turbo_pct;
@@ -955,7 +955,7 @@ static ssize_t show_turbo_pct(struct kobject *kobj,
}
static ssize_t show_num_pstates(struct kobject *kobj,
- struct attribute *attr, char *buf)
+ struct kobj_attribute *attr, char *buf)
{
struct cpudata *cpu;
int total;
@@ -976,7 +976,7 @@ static ssize_t show_num_pstates(struct kobject *kobj,
}
static ssize_t show_no_turbo(struct kobject *kobj,
-struct attribute *attr, char *buf)
+struct kobj_attribute *attr, char *buf)
{
ssize_t ret;
@@ -998,7 +998,7 @@ static ssize_t show_no_turbo(struct kobject *kobj,
return ret;
}
-static ssize_t store_no_turbo(struct kobject *a, struct attribute *b,
+static ssize_t store_no_turbo(struct kobject *a, struct kobj_attribute *b,
const char *buf, size_t count)
{
Re: [RESEND PATCH v3 1/2] drivers: amba: Updates to component identification for driver matching.
Hi Mike,
Thanks for the patch.
BTW somehow I can't find the latest series in my inbox, so commenting
on this here.
Mathieu pointed me to this patch series.This solves CPU debug module
sharing same PID as ETM on MSM8996. I will be posting patch for CPU
debug UCI table soon.
But please find my one comment inline.
On 12/19/2018 3:29 AM, Mike Leach wrote:
The CoreSight specification (ARM IHI 0029E), updates the ID register
requirements for components on an AMBA bus, to cover both traditional
ARM Primecell type devices, and newer CoreSight and other components.
The Peripheral ID (PID) / Component ID (CID) pair is extended in certain
cases to uniquely identify components. CoreSight components related to
a single function can share Peripheral ID values, and must be further
identified using a Unique Component Identifier (UCI). e.g. the ETM, CTI,
PMU and Debug hardware of the A35 all share the same PID.
[..]
+static const struct amba_id *
+amba_lookup(const struct amba_id *table, struct amba_device *dev)
+{
while (table->mask) {
- ret = (dev->periphid & table->mask) == table->id;
- if (ret)
- break;
+ if (((dev->periphid & table->mask) == table->id) &&
+ ((dev->cid != CORESIGHT_CID) ||
+(amba_cs_uci_id_match(table, dev
Shouldn't the check be (dev->cid == CORESIGHT_CID) ?
Without this STM fails to probe on both SDM845 and MSM8996.
With this,
Tested-by: Sai Prakash Ranjan
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH] ia64: prefix header search path with $(srctree)/
Currently, the Kbuild core manipulates header search paths in a crazy
way [1].
To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
the search paths in the srctree. Some Makefiles are already written in
that way, but not all. The goal of this work is to make the notation
consistent, and finally get rid of the gross hacks.
Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
("kbuild: do not drop -I without parameter").
I removed some header search paths because I was able to build ia64
without them.
[1]: https://patchwork.kernel.org/patch/9632347/
Signed-off-by: Masahiro Yamada
---
arch/ia64/sn/kernel/Makefile | 2 +-
arch/ia64/sn/kernel/sn2/Makefile | 2 --
arch/ia64/sn/pci/Makefile| 2 --
arch/ia64/sn/pci/pcibr/Makefile | 2 +-
4 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/ia64/sn/kernel/Makefile b/arch/ia64/sn/kernel/Makefile
index d27df1d..9c349dd 100644
--- a/arch/ia64/sn/kernel/Makefile
+++ b/arch/ia64/sn/kernel/Makefile
@@ -7,7 +7,7 @@
# Copyright (C) 1999,2001-2006,2008 Silicon Graphics, Inc. All Rights
Reserved.
#
-ccflags-y := -Iarch/ia64/sn/include
+ccflags-y := -I $(srctree)/arch/ia64/sn/include
obj-y += setup.o bte.o bte_error.o irq.o mca.o idle.o
\
huberror.o io_acpi_init.o io_common.o \
diff --git a/arch/ia64/sn/kernel/sn2/Makefile b/arch/ia64/sn/kernel/sn2/Makefile
index 3d09108..170bde4 100644
--- a/arch/ia64/sn/kernel/sn2/Makefile
+++ b/arch/ia64/sn/kernel/sn2/Makefile
@@ -9,7 +9,5 @@
# sn2 specific kernel files
#
-ccflags-y := -Iarch/ia64/sn/include
-
obj-y += cache.o io.o ptc_deadlock.o sn2_smp.o sn_proc_fs.o \
prominfo_proc.o timer.o timer_interrupt.o sn_hwperf.o
diff --git a/arch/ia64/sn/pci/Makefile b/arch/ia64/sn/pci/Makefile
index df2a901..321576b 100644
--- a/arch/ia64/sn/pci/Makefile
+++ b/arch/ia64/sn/pci/Makefile
@@ -7,6 +7,4 @@
#
# Makefile for the sn pci general routines.
-ccflags-y := -Iarch/ia64/sn/include
-
obj-y := pci_dma.o tioca_provider.o tioce_provider.o pcibr/
diff --git a/arch/ia64/sn/pci/pcibr/Makefile b/arch/ia64/sn/pci/pcibr/Makefile
index 396bcae..712f6af 100644
--- a/arch/ia64/sn/pci/pcibr/Makefile
+++ b/arch/ia64/sn/pci/pcibr/Makefile
@@ -7,7 +7,7 @@
#
# Makefile for the sn2 io routines.
-ccflags-y := -Iarch/ia64/sn/include
+ccflags-y := -I $(srctree)/arch/ia64/sn/include
obj-y += pcibr_dma.o pcibr_reg.o \
pcibr_ate.o pcibr_provider.o
--
2.7.4
RE: [PATCH v8 1/5] spi: spi-mem: Add driver for NXP FlexSPI controller
> -Original Message- > From: linux-mtd On Behalf Of Yogesh > Narayan Gaur > Sent: Tuesday, January 15, 2019 5:30 PM > To: linux-...@lists.infradead.org; bbrezil...@kernel.org; > marek.va...@gmail.com; broo...@kernel.org; linux-...@vger.kernel.org; > devicet...@vger.kernel.org > Cc: mark.rutl...@arm.com; r...@kernel.org; Yogesh Narayan Gaur > ; linux-kernel@vger.kernel.org; > frieder.schre...@kontron.de; computersforpe...@gmail.com; > shawn...@kernel.org; linux-arm-ker...@lists.infradead.org > Subject: [PATCH v8 1/5] spi: spi-mem: Add driver for NXP FlexSPI controller > > - Add driver for NXP FlexSPI host controller > > (0) What is the FlexSPI controller? > FlexSPI is a flexsible SPI host controller which supports two SPI channels > and up > to 4 external devices. Each channel supports Single/Dual/Quad/Octal mode data > transfer (1/2/4/8 bidirectional data lines) i.e. FlexSPI acts as an > interface to > external devices, maximum 4, each with up to 8 bidirectional data lines. > > It uses new SPI memory interface of the SPI framework to issue flash memory > operations to up to four connected flash devices (2 buses with 2 CS each). > > (1) Tested this driver with the mtd_debug and JFFS2 filesystem utility on NXP > LX2160ARDB and LX2160AQDS targets. > LX2160ARDB is having two NOR slave device connected on single bus A i.e. A0 > and A1 (CS0 and CS1). > LX2160AQDS is having two NOR slave device connected on separate buses one > flash on A0 and second on B1 i.e. (CS0 and CS3). > Verified this driver on following SPI NOR flashes: > Micron, mt35xu512ab, [Read - 1 bit mode] > Cypress, s25fl512s, [Read - 1/2/4 bit mode] > > Signed-off-by: Yogesh Narayan Gaur > Reviewed-by: Frieder Schrempf > Reviewed-by: Boris Brezillon > > --- > Changes for v8: > - Typo review comments changes > - Fix logic of read data for case when read size is less than 8 bytes. > - Add correct email address of Boris > - Add r-o-b tag of Frieder and Boris Tested on LX2160ARDB in 1-bit mode for read, write and erase Tested-by: Ashish Kumar Regards Ashish > Changes for v7: > - Add func pointer for '.get_name' for struct spi_controller_mem_ops > - Add input address range check as per controller memory mapped space > - Update _fill_txfifo/_read_rxfifo funcs as per Frieder review comments > Changes > for v6: > - Rebase on top of v5.0-rc1 > - Updated as per Frieder review comments and perform code cleanup > - Updated _fill_txfifo/_read_rxfifo func write/read logic Changes for v5: > - Rebase on top of v4.20-rc2 > - Modified fspi_readl_poll_tout() as per review comments > - Arrange header file in alphabetical order > - Removed usage of read()/write() function callback pointer > - Add support for 1 and 2 byte address length > - Change Frieder e-mail to new e-mail address Changes for v4: > - Incorporate Boris review comments > * Use readl_poll_timeout() instead of busy looping. > * Re-define register masking as per comment. > * Drop fspi_devtype enum. > Changes for v3: > - Added endianness flag in platform specific structure instead of DTS. > - Modified nxp_fspi_read_ahb(), removed remapping code. > - Added Boris and Frieder as Author and provided reference of spi-fsl-qspi.c > Changes for v2: > - Incorporated Boris review comments. > - Remove dependency of driver over connected flash device size. > - Modified the logic to select requested CS. > - Remove SPI-Octal Macros. > drivers/spi/Kconfig| 10 + > drivers/spi/Makefile |1 + > drivers/spi/spi-nxp-fspi.c | 1105 > 3 files changed, 1116 insertions(+) > create mode 100644 drivers/spi/spi-nxp-fspi.c > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index > dc67eda1788a..fc4cc7a65c33 100644 > --- a/drivers/spi/Kconfig > +++ b/drivers/spi/Kconfig > @@ -279,6 +279,16 @@ config SPI_FSL_QUADSPI > This controller does not support generic SPI messages. It only > supports the high-level SPI memory interface. > > +config SPI_NXP_FLEXSPI > + tristate "NXP Flex SPI controller" > + depends on ARCH_LAYERSCAPE || HAS_IOMEM > + help > + This enables support for the Flex SPI controller in master mode. > + Up to four slave devices can be connected on two buses with two > + chipselects each. > + This controller does not support generic SPI messages and only > + supports the high-level SPI memory interface. > + > config SPI_GPIO > tristate "GPIO-based bitbanging SPI Master" > depends on GPIOLIB || COMPILE_TEST > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index > 2a857cb9aa81..5c5af4676279 100644 > --- a/drivers/spi/Makefile > +++ b/drivers/spi/Makefile > @@ -64,6 +64,7 @@ obj-$(CONFIG_SPI_MXIC) += spi-mxic.o > obj-$(CONFIG_SPI_MXS)+= spi-mxs.o > obj-$(CONFIG_SPI_NPCM_PSPI) += spi-npcm-pspi.o > obj-$(CONFIG_SPI_NUC900) += spi-nuc900.o >
[PATCH] security: keys: add NULL checking for key->type->instantiate
key->type->instantiate can be NULL, add NULL checking to prevent
NULL pointer dereference in __key_instantiate_and_link().
Signed-off-by: Geliang Tang
---
security/keys/key.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/security/keys/key.c b/security/keys/key.c
index 44a80d6741a1..ae3cc11be0d2 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -438,7 +438,8 @@ static int __key_instantiate_and_link(struct key *key,
/* can't instantiate twice */
if (key->state == KEY_IS_UNINSTANTIATED) {
/* instantiate the key */
- ret = key->type->instantiate(key, prep);
+ if (key->type->instantiate)
+ ret = key->type->instantiate(key, prep);
if (ret == 0) {
/* mark the key as being instantiated */
--
2.17.1
Re: [PATCH] staging: rtlwifi: replace ---help--- with help in Kconfig
On Thu, Jan 24, 2019 at 08:57:19PM +, Cezary Kierzyk wrote: > This patch fixes the checkpatch.pl warning: > > WARNING: prefer 'help' over '---help---' for new help texts > > Signed-off-by: Cezary Kierzyk > --- > drivers/staging/rtlwifi/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) $ ./scripts/get_maintainer.pl --file drivers/staging/rtlwifi/Kconfig Greg Kroah-Hartman (supporter:STAGING SUBSYSTEM,commit_signer:1/1=100%) Corentin Labbe (commit_signer:1/1=100%,authored:1/1=100%,removed_lines:10/10=100%) de...@driverdev.osuosl.org (open list:STAGING SUBSYSTEM) linux-kernel@vger.kernel.org (open list) Why did you not cc: the driverdev mailing list? Please fix up and resend. thanks, greg k-h
[PATCH 0/2] scsi: trivial header search path fixups
My main motivation is to get rid of crappy header search path manipulation from Kbuild core. Before that, I want to do as many treewide cleanups as possible. The full work of this is available at: git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git build-test Masahiro Yamada (2): scsi: remove unneeded header search paths scsi: prefix header search paths with $(srctree)/ drivers/scsi/aacraid/Makefile | 2 -- drivers/scsi/aic7xxx/Makefile | 1 - drivers/scsi/cxgbi/Makefile| 2 +- drivers/scsi/pcmcia/Makefile | 2 +- drivers/scsi/smartpqi/Makefile | 1 - 5 files changed, 2 insertions(+), 6 deletions(-) -- 2.7.4
[PATCH 2/2] scsi: prefix header search paths with $(srctree)/
Currently, the Kbuild core manipulates header search paths in a crazy
way [1].
To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
the search paths in the srctree. Some Makefiles are already written in
that way, but not all. The goal of this work is to make the notation
consistent, and finally get rid of the gross hacks.
Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
("kbuild: do not drop -I without parameter").
[1]: https://patchwork.kernel.org/patch/9632347/
Signed-off-by: Masahiro Yamada
---
drivers/scsi/cxgbi/Makefile | 2 +-
drivers/scsi/pcmcia/Makefile | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/cxgbi/Makefile b/drivers/scsi/cxgbi/Makefile
index a73781a..f78c9cc 100644
--- a/drivers/scsi/cxgbi/Makefile
+++ b/drivers/scsi/cxgbi/Makefile
@@ -1,4 +1,4 @@
-ccflags-y += -Idrivers/net/ethernet/chelsio/libcxgb
+ccflags-y += -I $(srctree)/drivers/net/ethernet/chelsio/libcxgb
obj-$(CONFIG_SCSI_CXGB3_ISCSI) += libcxgbi.o cxgb3i/
obj-$(CONFIG_SCSI_CXGB4_ISCSI) += libcxgbi.o cxgb4i/
diff --git a/drivers/scsi/pcmcia/Makefile b/drivers/scsi/pcmcia/Makefile
index faa87a4..a5a24dd 100644
--- a/drivers/scsi/pcmcia/Makefile
+++ b/drivers/scsi/pcmcia/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
-ccflags-y := -Idrivers/scsi
+ccflags-y := -I $(srctree)/drivers/scsi
# 16-bit client drivers
obj-$(CONFIG_PCMCIA_QLOGIC)+= qlogic_cs.o
--
2.7.4
[PATCH 1/2] scsi: remove unneeded header search paths
I was able to build without these extra header search paths. Especially, the header search path -I. in kernel Makefiles is always suspicious; it allows the compiler to search for headers in the top of $(srctree), where obviously no header file exists. Signed-off-by: Masahiro Yamada --- drivers/scsi/aacraid/Makefile | 2 -- drivers/scsi/aic7xxx/Makefile | 1 - drivers/scsi/smartpqi/Makefile | 1 - 3 files changed, 4 deletions(-) diff --git a/drivers/scsi/aacraid/Makefile b/drivers/scsi/aacraid/Makefile index 1bd9fd1..3893b95 100644 --- a/drivers/scsi/aacraid/Makefile +++ b/drivers/scsi/aacraid/Makefile @@ -4,5 +4,3 @@ obj-$(CONFIG_SCSI_AACRAID) := aacraid.o aacraid-objs := linit.o aachba.o commctrl.o comminit.o commsup.o \ dpcsup.o rx.o sa.o rkt.o nark.o src.o - -ccflags-y := -Idrivers/scsi diff --git a/drivers/scsi/aic7xxx/Makefile b/drivers/scsi/aic7xxx/Makefile index c15be25..e0188ec 100644 --- a/drivers/scsi/aic7xxx/Makefile +++ b/drivers/scsi/aic7xxx/Makefile @@ -34,7 +34,6 @@ aic79xx-y += aic79xx_osm.o\ aic79xx_proc.o \ aic79xx_osm_pci.o -ccflags-y += -Idrivers/scsi ifdef WARNINGS_BECOME_ERRORS ccflags-y += -Werror endif diff --git a/drivers/scsi/smartpqi/Makefile b/drivers/scsi/smartpqi/Makefile index e6b7799..a03a6ed 100644 --- a/drivers/scsi/smartpqi/Makefile +++ b/drivers/scsi/smartpqi/Makefile @@ -1,3 +1,2 @@ -ccflags-y += -I. obj-$(CONFIG_SCSI_SMARTPQI) += smartpqi.o smartpqi-objs := smartpqi_init.o smartpqi_sis.o smartpqi_sas_transport.o -- 2.7.4
Re: [PATCH] ALSA: hda/tegra: enable clock during probe
On 1/25/2019 12:38 AM, Takashi Iwai wrote:
On Thu, 24 Jan 2019 18:36:43 +0100,
Sameer Pujar wrote:
If CONFIG_PM is disabled or runtime PM calls are forbidden, the clocks
will not be ON. This could cause issue during probe, where hda init
setup is done. This patch checks whether runtime PM is enabled or not.
If disabled, clocks are enabled in probe() and disabled in remove()
This patch does following minor changes as cleanup,
* return code check for pm_runtime_get_sync() to take care of failure
and exit gracefully.
* In remove path runtime PM is disabled before calling snd_card_free().
* hda_tegra_disable_clocks() is moved out of CONFIG_PM_SLEEP check.
* runtime PM callbacks moved out of CONFIG_PM check
Signed-off-by: Sameer Pujar
Reviewed-by: Ravindra Lokhande
Reviewed-by: Jon Hunter
(snip)
@@ -555,6 +553,13 @@ static int hda_tegra_probe(struct platform_device *pdev)
if (!azx_has_pm_runtime(chip))
pm_runtime_forbid(hda->dev);
+ /* explicit resume if runtime PM is disabled */
+ if (!pm_runtime_enabled(hda->dev)) {
+ err = hda_tegra_runtime_resume(hda->dev);
+ if (err)
+ goto out_free;
+ }
+
schedule_work(>probe_work);
Calling runtime_resume here is really confusing...
@@ -571,7 +576,14 @@ static void hda_tegra_probe_work(struct work_struct *work)
struct platform_device *pdev = to_platform_device(hda->dev);
int err;
- pm_runtime_get_sync(hda->dev);
+ err = pm_runtime_get_sync(hda->dev);
+ if (err < 0) {
+ dev_err(hda->dev,
+ "failed in pm_runtime_get_syc with err = %d\n",
+ err);
+ return;
+ }
This pm_runtime_get_sync() is needed just because you enabled runtime
PM before probe_work. Why not deferring the runtime PM enablement
after probing done?
I think what you are suggesting can be done and simplify things further.
I can get rid of pm_runtime_get_sync/pm_runtime_put in probe work.
That is what we need is the hda_tegra_enable_clocks() call at probe
unconditionally before enabling runtime PM.
err = hda_tegra_first_init(chip, pdev);
if (err < 0)
goto out_free;
@@ -599,12 +611,13 @@ static void hda_tegra_probe_work(struct work_struct *work)
static int hda_tegra_remove(struct platform_device *pdev)
{
- int ret;
-
- ret = snd_card_free(dev_get_drvdata(>dev));
pm_runtime_disable(>dev);
+ if (!pm_runtime_status_suspended(>dev)) {
+ hda_tegra_runtime_suspend(>dev);
+ pm_runtime_set_suspended(>dev);
+ }
- return ret;
+ return snd_card_free(dev_get_drvdata(>dev));
Forcing the suspend *before* snd_card_free() doesn't sound right.
It's the point before the disconnect and release procedure of all the
rest. That is, the other hardware components are still active at this
point.
Ok, I will keep the sequence same and publish updated version.
Thanks,
Sameer.
thanks,
Takashi
Re: [RFC PATCH] cpufreq / cppc: Work around for Hisilicon CPPC cpufreq
Hi Wang,
On Thu, Jan 24, 2019 at 12:27 PM Viresh Kumar wrote:
>
> +George/Prashanth.
>
> Guys please see if you have any objections to this patch. I am not
> very familiar with this stuff and it would be good to get some
> feedback from you guys.
>
> @Rafael: Do you have any comments on this ?
>
> On 17-01-19, 19:00, Xiongfeng Wang wrote:
> > Hisilicon chips do not support delivered performance counter register
> > and reference performance counter register. But the platform can
> > calculate the real performance using its own method. This patch provide
> > a workaround for this problem, and other platforms can also use this
> > workaround framework. We reuse the desired performance register to
> > store the real performance calculated by the platform. After the
> > platform finished the frequency adjust, it gets the real performance and
> > writes it into desired performance register. OS can use it to calculate
> > the real frequency.
Does your platform support Autonomous Selection mode?
This register is not valid when autonomous mode is enabled. In such case
how are you calculating the frequency?
> >
> > Signed-off-by: Xiongfeng Wang
> > ---
> > drivers/acpi/cppc_acpi.c | 29
> > drivers/cpufreq/Kconfig.arm| 7 +
> > drivers/cpufreq/cppc_cpufreq.c | 62
> > ++
> > include/acpi/cppc_acpi.h | 4 +++
> > 4 files changed, 102 insertions(+)
> >
> > diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
> > index 217a782..0cdaf7e 100644
> > --- a/drivers/acpi/cppc_acpi.c
> > +++ b/drivers/acpi/cppc_acpi.c
> > @@ -1050,6 +1050,35 @@ static int cpc_write(int cpu, struct
> > cpc_register_resource *reg_res, u64 val)
> > return ret_val;
> > }
> >
> > +#ifdef CONFIG_HISILICON_CPPC_CPUFREQ_WORKAROUND
> > +/*
> > + * We reuse the desired performance register to store the real performance
> > + * calculated by the platform.
> > + */
> > +u64 hisi_cppc_get_real_perf(unsigned int cpunum)
> > +{
> > + int pcc_ss_id = per_cpu(cpu_pcc_subspace_idx, cpunum);
> > + struct cpc_desc *cpc_desc = per_cpu(cpc_desc_ptr, cpunum);
> > + struct cpc_register_resource *desired_reg;
> > + u64 desired_perf;
> > + int ret;
> > +
> > + /*
> > + * Make sure the platform has finished the frequency adjust
> > + * and wrote the real performance in desired performance register
> > + */
> > + ret = check_pcc_chan(pcc_ss_id, false);
> > + if (ret)
> > + return 0;
If there is a pending command in the channel then returning zero
will give bogus frequency value. You may return the previous written value.
> > +
> > + desired_reg = _desc->cpc_regs[DESIRED_PERF];
> > + cpc_read(cpunum, desired_reg, _perf);
> > +
> > + return desired_perf;
> > +}
> > +EXPORT_SYMBOL_GPL(hisi_cppc_get_real_perf);
> > +#endif
> > +
> > /**
> > * cppc_get_perf_caps - Get a CPUs performance capabilities.
> > * @cpunum: CPU from which to get capabilities info.
> > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> > index 688f102..236bd07 100644
> > --- a/drivers/cpufreq/Kconfig.arm
> > +++ b/drivers/cpufreq/Kconfig.arm
> > @@ -18,6 +18,13 @@ config ACPI_CPPC_CPUFREQ
> >
> > If in doubt, say N.
> >
> > +config HISILICON_CPPC_CPUFREQ_WORKAROUND
> > + bool "Workaround for Hisilicon CPPC Cpufreq"
> > + default y
> > + depends on ACPI_CPPC_CPUFREQ && ARM64
Do you really want this to be applied to all ARM64? or just only
for affected HISI platforms?
> > + help
> > + This option enables a workaround for Hisilicon CPPC Cpufreq.
> > +
> > config ARM_ARMADA_37XX_CPUFREQ
> > tristate "Armada 37xx CPUFreq support"
> > depends on ARCH_MVEBU && CPUFREQ_DT
> > diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
> > index fd25c21c..b910e84 100644
> > --- a/drivers/cpufreq/cppc_cpufreq.c
> > +++ b/drivers/cpufreq/cppc_cpufreq.c
> > @@ -33,6 +33,13 @@
> > /* Offest in the DMI processor structure for the max frequency */
> > #define DMI_PROCESSOR_MAX_SPEED 0x14
> >
> > +struct cppc_get_rate_workaround_info {
If your intention is to make a generic framework for future extensions
then you might need to name it differently. Something like
struct cppc_workaround_info, so that you can extend the same for any
future workarounds.
> > + char oem_id[ACPI_OEM_ID_SIZE +1];
> > + char oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1];
> > + u32 oem_revision;
> > + unsigned int (*get)(unsigned int cpu);
This can be unsigned int (*get_rate)(unsigned int cpu);
> > +};
> > +
> > /*
> > * These structs contain information parsed from per CPU
> > * ACPI _CPC structures.
> > @@ -357,6 +364,59 @@ static unsigned int cppc_cpufreq_get_rate(unsigned int
> > cpunum)
> > .name = "cppc_cpufreq",
> > };
> >
> > +#ifdef CONFIG_HISILICON_CPPC_CPUFREQ_WORKAROUND
> > +/*
> > + * When the platform does not support delivered
Re: [PATCH v13 00/10] powerpc: Switch to CONFIG_THREAD_INFO_IN_TASK
On Thu, Jan 24, 2019 at 04:58:41PM +0100, Christophe Leroy wrote: > > > Le 24/01/2019 à 16:01, Christophe Leroy a écrit : > > > > > > Le 24/01/2019 à 10:43, Christophe Leroy a écrit : > > > > > > > > > On 01/24/2019 01:06 AM, Michael Ellerman wrote: > > > > Christophe Leroy writes: > > > > > Le 12/01/2019 à 10:55, Christophe Leroy a écrit : > > > > > > The purpose of this serie is to activate > > > > > > CONFIG_THREAD_INFO_IN_TASK which > > > > > > moves the thread_info into task_struct. > > > > > > > > > > > > Moving thread_info into task_struct has the following advantages: > > > > > > - It protects thread_info from corruption in the case of stack > > > > > > overflows. > > > > > > - Its address is harder to determine if stack addresses are > > > > > > leaked, making a number of attacks more difficult. > > > > > > > > > > I ran null_syscall and context_switch benchmark selftests > > > > > and the result > > > > > is surprising. There is slight degradation in context_switch and a > > > > > significant one on null_syscall: > > > > > > > > > > Without the serie: > > > > > > > > > > ~# chrt -f 98 ./context_switch --no-altivec --no-vector --no-fp > > > > > 55542 > > > > > 55562 > > > > > 55564 > > > > > 55562 > > > > > 55568 > > > > > ... > > > > > > > > > > ~# ./null_syscall > > > > > 2546.71 ns 336.17 cycles > > > > > > > > > > > > > > > With the serie: > > > > > > > > > > ~# chrt -f 98 ./context_switch --no-altivec --no-vector --no-fp > > > > > 55138 > > > > > 55142 > > > > > 55152 > > > > > 55144 > > > > > 55142 > > > > > > > > > > ~# ./null_syscall > > > > > 3479.54 ns 459.30 cycles > > > > > > > > > > So 0,8% less context switches per second and 37% more time > > > > > for one syscall ? > > > > > > > > > > Any idea ? > > > > > > > > What platform is that on? > > > > > > It is on the 8xx > > On the 83xx, I have a slight improvment: > > Without the serie: > > root@vgoippro:~# ./null_syscall > 921.44 ns 307.15 cycles > > With the serie: > > root@vgoippro:~# ./null_syscall > 918.78 ns 306.26 cycles > The 8xx has very low cache associativity, something like 2, right? In this case it may be access patterns which change the number of cache line transfers when you move things around. Try to move things around in main(), for example allocate a variable of ~1kB on the stack in the function that performs the null_syscalls (use the variable before and after the loop, to avoid clever compiler optimizations). Gabriel > Christophe > > > > > > > > > > > > On 64-bit we have to turn one mtmsrd into two and that's obviously a > > > > slow down. But I don't see that you've done anything similar in 32-bit > > > > code. > > > > > > > > I assume it's patch 8 that causes the slow down? > > > > > > I have not digged into it yet, but why patch 8 ? > > > > > > > The increase of null_syscall duration happens with patch 5 when we > > activate CONFIG_THREAD_INFO_IN_TASK. > >
[PATCHv3 9/9] cpufreq: scpi: Use auto-registration of thermal cooling device
Use the CPUFREQ_AUTO_REGISTER_COOLING_DEV flag to allow cpufreq core to
automatically register as a thermal cooling device.
This allows removal of boiler plate code from the driver.
Signed-off-by: Amit Kucheria
Acked-by: Sudeep Holla
---
drivers/cpufreq/scpi-cpufreq.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/cpufreq/scpi-cpufreq.c b/drivers/cpufreq/scpi-cpufreq.c
index 99449738faa4..82420e8e5f0d 100644
--- a/drivers/cpufreq/scpi-cpufreq.c
+++ b/drivers/cpufreq/scpi-cpufreq.c
@@ -22,7 +22,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -34,7 +33,6 @@
struct scpi_data {
struct clk *clk;
struct device *cpu_dev;
- struct thermal_cooling_device *cdev;
};
static struct scpi_ops *scpi_ops;
@@ -186,7 +184,6 @@ static int scpi_cpufreq_exit(struct cpufreq_policy *policy)
{
struct scpi_data *priv = policy->driver_data;
- cpufreq_cooling_unregister(priv->cdev);
clk_put(priv->clk);
dev_pm_opp_free_cpufreq_table(priv->cpu_dev, >freq_table);
kfree(priv);
@@ -195,23 +192,16 @@ static int scpi_cpufreq_exit(struct cpufreq_policy
*policy)
return 0;
}
-static void scpi_cpufreq_ready(struct cpufreq_policy *policy)
-{
- struct scpi_data *priv = policy->driver_data;
-
- priv->cdev = of_cpufreq_cooling_register(policy);
-}
-
static struct cpufreq_driver scpi_cpufreq_driver = {
.name = "scpi-cpufreq",
.flags = CPUFREQ_STICKY | CPUFREQ_HAVE_GOVERNOR_PER_POLICY |
- CPUFREQ_NEED_INITIAL_FREQ_CHECK,
+ CPUFREQ_NEED_INITIAL_FREQ_CHECK |
+ CPUFREQ_AUTO_REGISTER_COOLING_DEV,
.verify = cpufreq_generic_frequency_table_verify,
.attr = cpufreq_generic_attr,
.get= scpi_cpufreq_get_rate,
.init = scpi_cpufreq_init,
.exit = scpi_cpufreq_exit,
- .ready = scpi_cpufreq_ready,
.target_index = scpi_cpufreq_set_target,
};
--
2.17.1
Re: [PATCH RFC 1/1] arm64: Use PSCI calls for CPU stop when hotplug is supported
On Wed, Jan 23, 2019 at 11:03 PM Mark Rutland wrote: > > On Wed, Jan 23, 2019 at 09:05:26AM -0800, Scott Branden wrote: > > Hi Mark, > > > > Hopefully I can shed some light on the use case inline. > > > > On 2019-01-23 8:48 a.m., Mark Rutland wrote: > > > On Mon, Jan 21, 2019 at 11:30:02AM +0530, Pramod Kumar wrote: > > > > On Mon, Jan 21, 2019 at 11:28 AM Pramod Kumar > > > > > > > > wrote: > > > > > > > > Need comes from a specific use case where one Accelerator > > > > card(SoC) is > > > > plugged in a sever over a PCIe interface. This Card gets supply > > > > from a > > > > battery, which could provide very less power for a very small > > > > time, in case > > > > of any power loss. Once Card switches to battery, this has to > > > > reduce its > > > > power consumption to its lowest point and back-up the DDR contents > > > > asap > > > > before battery gets fully drained off. > > > In this example is Linux running on the server, or on the accelerator? > > Accelerator > > > > > > What precisely are you trying to back up from DDR, and why? > > Data in DDR is being written to disk at this time (disk is connected to > > accelerator) > > > > > > What is responsible for backing up that contents? > > > > A low power M-class processor and DMA engine which continues necessary > > operations to transfer DDR memory to disk. > > > > The high power processors on the accelerator running linux needed to be > > halted ASAP on this power loss event and M0 take over. Graceful shutdown of > > linux and other peripherals is unnecessary (and we don't have the power > > necessary to do so). > > If graceful shutdown of Linux is not required (and is in fact > undesireable), why is Linux involved at all in this shutdown process? > > For example, why is this not a secure interrupt taken to EL3, which can > (gracefully) shut down the CPUs regardless? > This is an GPIO interrupt. This can not be marked secure as for that we need to mark whole GPIO controller as secure which is not possible as GPIO controller is meant for non-secure world having more than 100 lines connected. I agree we have work around where we invoke handler in Linux and switch to ATF via SMC and from ATF we need bring all secondary CPU to ATF via sending SGI and and then respective core flushes the L1/L2 and bring himself out of coherency domain and cluster and MCU shutdowns the CPU subsystem gracefully. This could work for our requirement. Need to check ATF support for that. But What about generic system? This patch address the generic multi-master system's requirement. Consider system where shutting down the linux does not mean shutting down the complete system. Lets take an example of smartnic case Where NIC master and CPUs access cachable DDR. In smarnic its quite common to bring CPUs on demand means when needed via MCU help. Now in full-fledged system. if CPU subsystem is shutdown via poweroff command which does not bring secondary CPUs out of coherency domain, it will bring the complete system unstable when NIC master tries to access DDR and snoop is send to CPUs as well which is not available. Fabric/System hangs... I feel While shutting down the CPUs subsystem or powering off, All secondary CPUs must be shutdown properly by bring-out of coherency domain to remain rest of subsystem usable. I agree that introducing PSCI call introduce delay for shutdown/reboot case but stability matter than little delay. > > > > Since battery can provide limited power for a very short time > > > > hence need to > > > > transition to lowest power. As per the transition process , CPUs > > > > power > > > > domain has to be off but before that it needs to flush out its > > > > content to > > > > system memory(L3) so that content could be backed-up by a MCU, a > > > > controller > > > > consuming very less power. Since we can not afford plugging-out > > > > every > > > > individual CPUs in sequence hence uses ipi_cpu_stop for all other > > > > CPUs > > > > which ultimately switch to ATF to flush out all the CPUs caches > > > > and comes > > > > out of coherency domain so that its power rails could be > > > > switched-off. > > > If you're stopping CPUs from completely arbitrary states, what is the > > > benefit of saving the RAM contents? > > > > Some of the RAM contains data that was in the process of being written to > > disk by the accelerator. > > Ok, so this isn't actually about backing up RAM contents; it's about > completing pending I/O. > > I'm still confused as to how that works. How do you avoid leaving the > disk in some corrupt state if data runs out partway through? > > > This data must be saved to disk and the high power CPUs consume too much > > power to continue performing this operation. > > > > > CPUs might be running with IRQs disabled for an arbitrarily long time, > > > > In an embedded linux system we control everything running. > > Sure, and that complete control
[PATCHv3 3/9] cpufreq: qcom-hw: Register as a cpufreq cooling device
Add the CPUFREQ_AUTO_REGISTER_COOLING_DEV flag to allow the cpufreq core
to auto-register the driver as a cooling device.
Signed-off-by: Amit Kucheria
Reviewed-by: Matthias Kaehlcke
Tested-by: Matthias Kaehlcke
Reviewed-by: Stephen Boyd
---
drivers/cpufreq/qcom-cpufreq-hw.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
b/drivers/cpufreq/qcom-cpufreq-hw.c
index d83939a1b3d4..ed32849a3d40 100644
--- a/drivers/cpufreq/qcom-cpufreq-hw.c
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -231,7 +231,8 @@ static struct freq_attr *qcom_cpufreq_hw_attr[] = {
static struct cpufreq_driver cpufreq_qcom_hw_driver = {
.flags = CPUFREQ_STICKY | CPUFREQ_NEED_INITIAL_FREQ_CHECK |
- CPUFREQ_HAVE_GOVERNOR_PER_POLICY,
+ CPUFREQ_HAVE_GOVERNOR_PER_POLICY |
+ CPUFREQ_AUTO_REGISTER_COOLING_DEV,
.verify = cpufreq_generic_frequency_table_verify,
.target_index = qcom_cpufreq_hw_target_index,
.get= qcom_cpufreq_hw_get,
--
2.17.1
[PATCHv3 4/9] cpufreq: imx6q: Use auto-registration of thermal cooling device
Use the CPUFREQ_AUTO_REGISTER_COOLING_DEV flag to allow cpufreq core to
automatically register as a thermal cooling device.
This allows removal of boiler plate code from the driver.
Signed-off-by: Amit Kucheria
---
drivers/cpufreq/imx6q-cpufreq.c | 24 ++--
1 file changed, 2 insertions(+), 22 deletions(-)
diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
index 9fedf627e000..9935df234fa1 100644
--- a/drivers/cpufreq/imx6q-cpufreq.c
+++ b/drivers/cpufreq/imx6q-cpufreq.c
@@ -9,7 +9,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -52,7 +51,6 @@ static struct clk_bulk_data clks[] = {
};
static struct device *cpu_dev;
-static struct thermal_cooling_device *cdev;
static bool free_opp;
static struct cpufreq_frequency_table *freq_table;
static unsigned int max_freq;
@@ -193,16 +191,6 @@ static int imx6q_set_target(struct cpufreq_policy *policy,
unsigned int index)
return 0;
}
-static void imx6q_cpufreq_ready(struct cpufreq_policy *policy)
-{
- cdev = of_cpufreq_cooling_register(policy);
-
- if (!cdev)
- dev_err(cpu_dev,
- "running cpufreq without cooling device: %ld\n",
- PTR_ERR(cdev));
-}
-
static int imx6q_cpufreq_init(struct cpufreq_policy *policy)
{
int ret;
@@ -214,22 +202,14 @@ static int imx6q_cpufreq_init(struct cpufreq_policy
*policy)
return ret;
}
-static int imx6q_cpufreq_exit(struct cpufreq_policy *policy)
-{
- cpufreq_cooling_unregister(cdev);
-
- return 0;
-}
-
static struct cpufreq_driver imx6q_cpufreq_driver = {
- .flags = CPUFREQ_NEED_INITIAL_FREQ_CHECK,
+ .flags = CPUFREQ_NEED_INITIAL_FREQ_CHECK |
+CPUFREQ_AUTO_REGISTER_COOLING_DEV,
.verify = cpufreq_generic_frequency_table_verify,
.target_index = imx6q_set_target,
.get = cpufreq_generic_get,
.init = imx6q_cpufreq_init,
- .exit = imx6q_cpufreq_exit,
.name = "imx6q-cpufreq",
- .ready = imx6q_cpufreq_ready,
.attr = cpufreq_generic_attr,
.suspend = cpufreq_generic_suspend,
};
--
2.17.1
[PATCHv3 8/9] cpufreq: scmi: Use auto-registration of thermal cooling device
Use the CPUFREQ_AUTO_REGISTER_COOLING_DEV flag to allow cpufreq core to
automatically register as a thermal cooling device.
This allows removal of boiler plate code from the driver.
Signed-off-by: Amit Kucheria
Acked-by: Sudeep Holla
---
drivers/cpufreq/scmi-cpufreq.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
index 242c3370544e..b19e9d129f8f 100644
--- a/drivers/cpufreq/scmi-cpufreq.c
+++ b/drivers/cpufreq/scmi-cpufreq.c
@@ -11,7 +11,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -22,7 +21,6 @@
struct scmi_data {
int domain_id;
struct device *cpu_dev;
- struct thermal_cooling_device *cdev;
};
static const struct scmi_handle *handle;
@@ -185,7 +183,6 @@ static int scmi_cpufreq_exit(struct cpufreq_policy *policy)
{
struct scmi_data *priv = policy->driver_data;
- cpufreq_cooling_unregister(priv->cdev);
dev_pm_opp_free_cpufreq_table(priv->cpu_dev, >freq_table);
kfree(priv);
dev_pm_opp_remove_all_dynamic(priv->cpu_dev);
@@ -193,17 +190,11 @@ static int scmi_cpufreq_exit(struct cpufreq_policy
*policy)
return 0;
}
-static void scmi_cpufreq_ready(struct cpufreq_policy *policy)
-{
- struct scmi_data *priv = policy->driver_data;
-
- priv->cdev = of_cpufreq_cooling_register(policy);
-}
-
static struct cpufreq_driver scmi_cpufreq_driver = {
.name = "scmi",
.flags = CPUFREQ_STICKY | CPUFREQ_HAVE_GOVERNOR_PER_POLICY |
- CPUFREQ_NEED_INITIAL_FREQ_CHECK,
+ CPUFREQ_NEED_INITIAL_FREQ_CHECK |
+ CPUFREQ_AUTO_REGISTER_COOLING_DEV,
.verify = cpufreq_generic_frequency_table_verify,
.attr = cpufreq_generic_attr,
.target_index = scmi_cpufreq_set_target,
@@ -211,7 +202,6 @@ static struct cpufreq_driver scmi_cpufreq_driver = {
.get= scmi_cpufreq_get_rate,
.init = scmi_cpufreq_init,
.exit = scmi_cpufreq_exit,
- .ready = scmi_cpufreq_ready,
};
static int scmi_cpufreq_probe(struct scmi_device *sdev)
--
2.17.1
[PATCHv3 7/9] cpufreq: qoriq: Use auto-registration of thermal cooling device
Use the CPUFREQ_AUTO_REGISTER_COOLING_DEV flag to allow cpufreq core to
automatically register as a thermal cooling device.
This allows removal of boiler plate code from the driver.
Signed-off-by: Amit Kucheria
---
drivers/cpufreq/qoriq-cpufreq.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/cpufreq/qoriq-cpufreq.c b/drivers/cpufreq/qoriq-cpufreq.c
index 3d773f64b4df..b206e6cb55f0 100644
--- a/drivers/cpufreq/qoriq-cpufreq.c
+++ b/drivers/cpufreq/qoriq-cpufreq.c
@@ -13,7 +13,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -31,7 +30,6 @@
struct cpu_data {
struct clk **pclk;
struct cpufreq_frequency_table *table;
- struct thermal_cooling_device *cdev;
};
/*
@@ -239,7 +237,6 @@ static int qoriq_cpufreq_cpu_exit(struct cpufreq_policy
*policy)
{
struct cpu_data *data = policy->driver_data;
- cpufreq_cooling_unregister(data->cdev);
kfree(data->pclk);
kfree(data->table);
kfree(data);
@@ -258,23 +255,15 @@ static int qoriq_cpufreq_target(struct cpufreq_policy
*policy,
return clk_set_parent(policy->clk, parent);
}
-
-static void qoriq_cpufreq_ready(struct cpufreq_policy *policy)
-{
- struct cpu_data *cpud = policy->driver_data;
-
- cpud->cdev = of_cpufreq_cooling_register(policy);
-}
-
static struct cpufreq_driver qoriq_cpufreq_driver = {
.name = "qoriq_cpufreq",
- .flags = CPUFREQ_CONST_LOOPS,
+ .flags = CPUFREQ_CONST_LOOPS |
+ CPUFREQ_AUTO_REGISTER_COOLING_DEV,
.init = qoriq_cpufreq_cpu_init,
.exit = qoriq_cpufreq_cpu_exit,
.verify = cpufreq_generic_frequency_table_verify,
.target_index = qoriq_cpufreq_target,
.get= cpufreq_generic_get,
- .ready = qoriq_cpufreq_ready,
.attr = cpufreq_generic_attr,
};
--
2.17.1
[PATCHv3 5/9] cpufreq: cpufreq-dt: Use auto-registration of thermal cooling device
Use the CPUFREQ_AUTO_REGISTER_COOLING_DEV flag to allow cpufreq core to
automatically register as a thermal cooling device.
This allows removal of boiler plate code from the driver.
Signed-off-by: Amit Kucheria
---
drivers/cpufreq/cpufreq-dt.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index e58bfcb1169e..2a4c4ea7980b 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -13,7 +13,6 @@
#include
#include
-#include
#include
#include
#include
@@ -30,7 +29,6 @@
struct private_data {
struct opp_table *opp_table;
struct device *cpu_dev;
- struct thermal_cooling_device *cdev;
const char *reg_name;
bool have_static_opps;
};
@@ -301,7 +299,6 @@ static int cpufreq_exit(struct cpufreq_policy *policy)
{
struct private_data *priv = policy->driver_data;
- cpufreq_cooling_unregister(priv->cdev);
dev_pm_opp_free_cpufreq_table(priv->cpu_dev, >freq_table);
if (priv->have_static_opps)
dev_pm_opp_of_cpumask_remove_table(policy->related_cpus);
@@ -314,21 +311,14 @@ static int cpufreq_exit(struct cpufreq_policy *policy)
return 0;
}
-static void cpufreq_ready(struct cpufreq_policy *policy)
-{
- struct private_data *priv = policy->driver_data;
-
- priv->cdev = of_cpufreq_cooling_register(policy);
-}
-
static struct cpufreq_driver dt_cpufreq_driver = {
- .flags = CPUFREQ_STICKY | CPUFREQ_NEED_INITIAL_FREQ_CHECK,
+ .flags = CPUFREQ_STICKY | CPUFREQ_NEED_INITIAL_FREQ_CHECK |
+CPUFREQ_AUTO_REGISTER_COOLING_DEV,
.verify = cpufreq_generic_frequency_table_verify,
.target_index = set_target,
.get = cpufreq_generic_get,
.init = cpufreq_init,
.exit = cpufreq_exit,
- .ready = cpufreq_ready,
.name = "cpufreq-dt",
.attr = cpufreq_dt_attr,
.suspend = cpufreq_generic_suspend,
--
2.17.1
[PATCHv3 1/9] thermal: cpu_cooling: Require thermal core to be compiled in
The CPU cooling driver (cpu_cooling.c) allows the platform's cpufreq driver to register as a cooling device and cool down the platform by throttling the CPU frequency. In order to be able to auto-register a cpufreq driver as a cooling device from the cpufreq core, we need access to code inside cpu_cooling.c which, in turn, accesses code inside thermal core. CPU_FREQ is a bool while THERMAL is tristate. In some configurations (e.g. allmodconfig), CONFIG_THERMAL ends up as a module while CONFIG_CPU_FREQ is compiled in. This leads to following error: drivers/cpufreq/cpufreq.o: In function `cpufreq_offline': cpufreq.c:(.text+0x407c): undefined reference to `cpufreq_cooling_unregister' drivers/cpufreq/cpufreq.o: In function `cpufreq_online': cpufreq.c:(.text+0x70c0): undefined reference to `of_cpufreq_cooling_register' Given that platforms using CPU_THERMAL usually want it compiled-in so it is available early in boot, make CPU_THERMAL depend on THERMAL being compiled-in instead of allowing it to be a module. As a result of this change, get rid of the ugly (!CPU_THERMAL || THERMAL) dependency in all cpufreq drivers using CPU_THERMAL. Suggested-by: Rafael J. Wysocki Signed-off-by: Amit Kucheria --- drivers/cpufreq/Kconfig | 3 --- drivers/cpufreq/Kconfig.arm | 5 - drivers/thermal/Kconfig | 1 + 3 files changed, 1 insertion(+), 8 deletions(-) diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig index 608af20a3494..b22e6bba71f1 100644 --- a/drivers/cpufreq/Kconfig +++ b/drivers/cpufreq/Kconfig @@ -207,8 +207,6 @@ comment "CPU frequency scaling drivers" config CPUFREQ_DT tristate "Generic DT based cpufreq driver" depends on HAVE_CLK && OF - # if CPU_THERMAL is on and THERMAL=m, CPUFREQ_DT cannot be =y: - depends on !CPU_THERMAL || THERMAL select CPUFREQ_DT_PLATDEV select PM_OPP help @@ -327,7 +325,6 @@ endif config QORIQ_CPUFREQ tristate "CPU frequency scaling driver for Freescale QorIQ SoCs" depends on OF && COMMON_CLK && (PPC_E500MC || ARM || ARM64) - depends on !CPU_THERMAL || THERMAL select CLK_QORIQ help This adds the CPUFreq driver support for Freescale QorIQ SoCs diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index 688f10227793..ca8567c3152c 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -29,8 +29,6 @@ config ARM_ARMADA_37XX_CPUFREQ config ARM_BIG_LITTLE_CPUFREQ tristate "Generic ARM big LITTLE CPUfreq driver" depends on ARM_CPU_TOPOLOGY && HAVE_CLK - # if CPU_THERMAL is on and THERMAL=m, ARM_BIT_LITTLE_CPUFREQ cannot be =y - depends on !CPU_THERMAL || THERMAL select PM_OPP help This enables the Generic CPUfreq driver for ARM big.LITTLE platforms. @@ -38,7 +36,6 @@ config ARM_BIG_LITTLE_CPUFREQ config ARM_SCPI_CPUFREQ tristate "SCPI based CPUfreq driver" depends on ARM_SCPI_PROTOCOL && COMMON_CLK_SCPI - depends on !CPU_THERMAL || THERMAL help This adds the CPUfreq driver support for ARM platforms using SCPI protocol for CPU power management. @@ -93,7 +90,6 @@ config ARM_KIRKWOOD_CPUFREQ config ARM_MEDIATEK_CPUFREQ tristate "CPU Frequency scaling support for MediaTek SoCs" depends on ARCH_MEDIATEK && REGULATOR - depends on !CPU_THERMAL || THERMAL select PM_OPP help This adds the CPUFreq driver support for MediaTek SoCs. @@ -233,7 +229,6 @@ config ARM_SA1110_CPUFREQ config ARM_SCMI_CPUFREQ tristate "SCMI based CPUfreq driver" depends on ARM_SCMI_PROTOCOL || COMPILE_TEST - depends on !CPU_THERMAL || THERMAL select PM_OPP help This adds the CPUfreq driver support for ARM platforms using SCMI diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index 30323426902e..58bb7d72dc2b 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -152,6 +152,7 @@ config CPU_THERMAL bool "generic cpu cooling support" depends on CPU_FREQ depends on THERMAL_OF + depends on THERMAL=y help This implements the generic cpu cooling mechanism through frequency reduction. An ACPI version of this already exists -- 2.17.1
[PATCHv3 6/9] cpufreq: mediatek: Use auto-registration of thermal cooling device
Use the CPUFREQ_AUTO_REGISTER_COOLING_DEV flag to allow cpufreq core to
automatically register as a thermal cooling device.
This allows removal of boiler plate code from the driver.
Signed-off-by: Amit Kucheria
---
drivers/cpufreq/mediatek-cpufreq.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/cpufreq/mediatek-cpufreq.c
b/drivers/cpufreq/mediatek-cpufreq.c
index eb8920d39818..9a937f4c63e7 100644
--- a/drivers/cpufreq/mediatek-cpufreq.c
+++ b/drivers/cpufreq/mediatek-cpufreq.c
@@ -14,7 +14,6 @@
#include
#include
-#include
#include
#include
#include
@@ -48,7 +47,6 @@ struct mtk_cpu_dvfs_info {
struct regulator *sram_reg;
struct clk *cpu_clk;
struct clk *inter_clk;
- struct thermal_cooling_device *cdev;
struct list_head list_head;
int intermediate_voltage;
bool need_voltage_tracking;
@@ -307,13 +305,6 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy
*policy,
#define DYNAMIC_POWER "dynamic-power-coefficient"
-static void mtk_cpufreq_ready(struct cpufreq_policy *policy)
-{
- struct mtk_cpu_dvfs_info *info = policy->driver_data;
-
- info->cdev = of_cpufreq_cooling_register(policy);
-}
-
static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu)
{
struct device *cpu_dev;
@@ -472,7 +463,6 @@ static int mtk_cpufreq_exit(struct cpufreq_policy *policy)
{
struct mtk_cpu_dvfs_info *info = policy->driver_data;
- cpufreq_cooling_unregister(info->cdev);
dev_pm_opp_free_cpufreq_table(info->cpu_dev, >freq_table);
return 0;
@@ -480,13 +470,13 @@ static int mtk_cpufreq_exit(struct cpufreq_policy *policy)
static struct cpufreq_driver mtk_cpufreq_driver = {
.flags = CPUFREQ_STICKY | CPUFREQ_NEED_INITIAL_FREQ_CHECK |
-CPUFREQ_HAVE_GOVERNOR_PER_POLICY,
+CPUFREQ_HAVE_GOVERNOR_PER_POLICY |
+CPUFREQ_AUTO_REGISTER_COOLING_DEV,
.verify = cpufreq_generic_frequency_table_verify,
.target_index = mtk_cpufreq_set_target,
.get = cpufreq_generic_get,
.init = mtk_cpufreq_init,
.exit = mtk_cpufreq_exit,
- .ready = mtk_cpufreq_ready,
.name = "mtk-cpufreq",
.attr = cpufreq_generic_attr,
};
--
2.17.1
[PATCHv3 2/9] cpufreq: Auto-register the driver as a thermal cooling device if asked
All cpufreq drivers do similar things to register as a cooling device.
Provide a cpufreq driver flag so drivers can just ask the cpufreq core
to register the cooling device on their behalf. This allows us to get
rid of duplicated code in the drivers.
In order to allow this, we add a struct thermal_cooling_device pointer
to struct cpufreq_policy so that drivers don't need to store it in a
private data structure.
Suggested-by: Stephen Boyd
Suggested-by: Viresh Kumar
Signed-off-by: Amit Kucheria
Reviewed-by: Matthias Kaehlcke
Tested-by: Matthias Kaehlcke
---
drivers/cpufreq/cpufreq.c | 6 ++
include/linux/cpufreq.h | 21 +
2 files changed, 27 insertions(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index e35a886e00bc..cf1be057caf4 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1318,6 +1318,9 @@ static int cpufreq_online(unsigned int cpu)
if (cpufreq_driver->ready)
cpufreq_driver->ready(policy);
+ if (cpufreq_driver->flags & CPUFREQ_AUTO_REGISTER_COOLING_DEV)
+ register_cooling_device(policy);
+
pr_debug("initialization complete\n");
return 0;
@@ -1405,6 +1408,9 @@ static int cpufreq_offline(unsigned int cpu)
goto unlock;
}
+ if (cpufreq_driver->flags & CPUFREQ_AUTO_REGISTER_COOLING_DEV)
+ unregister_cooling_device(policy);
+
if (cpufreq_driver->stop_cpu)
cpufreq_driver->stop_cpu(policy);
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index bd7fbd6a4478..c7eb59b8ce94 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -13,6 +13,7 @@
#include
#include
+#include
#include
#include
#include
@@ -151,6 +152,9 @@ struct cpufreq_policy {
/* For cpufreq driver's internal use */
void*driver_data;
+
+ /* Pointer to the cooling device if used for thermal mitigation */
+ struct thermal_cooling_device *cdev;
};
/* Only for ACPI */
@@ -386,6 +390,12 @@ struct cpufreq_driver {
*/
#define CPUFREQ_NO_AUTO_DYNAMIC_SWITCHING BIT(6)
+/*
+ * Set by drivers that want the core to automatically register the cpufreq
+ * driver as a thermal cooling device.
+ */
+#define CPUFREQ_AUTO_REGISTER_COOLING_DEV BIT(7)
+
int cpufreq_register_driver(struct cpufreq_driver *driver_data);
int cpufreq_unregister_driver(struct cpufreq_driver *driver_data);
@@ -415,6 +425,17 @@ cpufreq_verify_within_cpu_limits(struct cpufreq_policy
*policy)
policy->cpuinfo.max_freq);
}
+static inline void register_cooling_device(struct cpufreq_policy *policy)
+{
+ policy->cdev = of_cpufreq_cooling_register(policy);
+}
+
+static inline void unregister_cooling_device(struct cpufreq_policy *policy)
+{
+ cpufreq_cooling_unregister(policy->cdev);
+ policy->cdev = NULL;
+}
+
#ifdef CONFIG_CPU_FREQ
void cpufreq_suspend(void);
void cpufreq_resume(void);
--
2.17.1
[PATCHv3 0/9] cpufreq: Add flag to auto-register as cooling device
Add a flag for cpufreq drivers to tell cpufreq core to auto-register themselves as a thermal cooling device. There series converts over all the drivers except arm_big_little.c. Tested on SDM845 with the qcom-cpufreq-hw driver. Only compile-tested the others. Things needing fixing (but not a blocker for the series): - Look at how to detect that we're not in IKS mode in arm_big_little's .ready callback. Changes since v2: - Get rid of #ifdef'ery and let the pointer exist in all cases - Get rid of (!CPU_THERMAL || THERMAL) dependency in all cpufreq drivers' Kconfig Changes since v1: - Fix compilation failures with allmodconfig - Get rid of #ifdef in cpufreq.c - Removed miscellaneous patches and sent them separately - Merged patches 1 and 2 from v1 Amit Kucheria (9): thermal: cpu_cooling: Require thermal core to be compiled in cpufreq: Auto-register the driver as a thermal cooling device if asked cpufreq: qcom-hw: Register as a cpufreq cooling device cpufreq: imx6q: Use auto-registration of thermal cooling device cpufreq: cpufreq-dt: Use auto-registration of thermal cooling device cpufreq: mediatek: Use auto-registration of thermal cooling device cpufreq: qoriq: Use auto-registration of thermal cooling device cpufreq: scmi: Use auto-registration of thermal cooling device cpufreq: scpi: Use auto-registration of thermal cooling device drivers/cpufreq/Kconfig| 3 --- drivers/cpufreq/Kconfig.arm| 5 - drivers/cpufreq/cpufreq-dt.c | 14 ++ drivers/cpufreq/cpufreq.c | 6 ++ drivers/cpufreq/imx6q-cpufreq.c| 24 ++-- drivers/cpufreq/mediatek-cpufreq.c | 14 ++ drivers/cpufreq/qcom-cpufreq-hw.c | 3 ++- drivers/cpufreq/qoriq-cpufreq.c| 15 ++- drivers/cpufreq/scmi-cpufreq.c | 14 ++ drivers/cpufreq/scpi-cpufreq.c | 14 ++ drivers/thermal/Kconfig| 1 + include/linux/cpufreq.h| 21 + 12 files changed, 42 insertions(+), 92 deletions(-) -- 2.17.1
INQUIRIES ORDER
Dear Supplier, Please kindly confirm back in reply if am onto the right contact person in your company responsible for inquiries & orders. Please can you as well send your updated 2019 product catalog/price listing to our Import Department desk. Thanking You, Yours truly, Carrino Giovanni Null CALATA POLLENA MOLO BAUSAN 80133 NAPOLI 80133 Napoli (NAPOLI) ITALY VAT No. IT00269100633 www.Carrino.it
[PATCH 0/3] media: clean-up header search paths and add $(srctree)/ prefix
My main motivation is to get rid of crappy header search path manipulation from Kbuild core. Before that, I want to do as many treewide cleanups as possible. If you are interested in the big picture of this work, the full patch set is available at: git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git build-test Masahiro Yamada (3): media: coda: remove -I$(src) header search path media: remove unneeded header search paths media: prefix header search paths with $(srctree)/ drivers/media/common/b2c2/Makefile| 4 ++-- drivers/media/dvb-frontends/cxd2880/Makefile | 2 -- drivers/media/i2c/smiapp/Makefile | 2 +- drivers/media/mmc/siano/Makefile | 3 +-- drivers/media/pci/b2c2/Makefile | 2 +- drivers/media/pci/bt8xx/Makefile | 5 ++--- drivers/media/pci/cx18/Makefile | 4 ++-- drivers/media/pci/cx23885/Makefile| 4 ++-- drivers/media/pci/cx88/Makefile | 4 ++-- drivers/media/pci/ddbridge/Makefile | 4 ++-- drivers/media/pci/dm1105/Makefile | 2 +- drivers/media/pci/mantis/Makefile | 2 +- drivers/media/pci/netup_unidvb/Makefile | 2 +- drivers/media/pci/ngene/Makefile | 4 ++-- drivers/media/pci/pluto2/Makefile | 2 +- drivers/media/pci/pt1/Makefile| 4 ++-- drivers/media/pci/pt3/Makefile| 4 ++-- drivers/media/pci/smipcie/Makefile| 5 ++--- drivers/media/pci/ttpci/Makefile | 4 ++-- drivers/media/platform/coda/Makefile | 2 -- drivers/media/platform/coda/coda-h264.c | 3 ++- drivers/media/platform/coda/trace.h | 2 +- drivers/media/platform/sti/c8sectpfe/Makefile | 5 ++--- drivers/media/radio/Makefile | 2 -- drivers/media/spi/Makefile| 4 +--- drivers/media/usb/as102/Makefile | 2 +- drivers/media/usb/au0828/Makefile | 4 ++-- drivers/media/usb/b2c2/Makefile | 2 +- drivers/media/usb/cx231xx/Makefile| 5 ++--- drivers/media/usb/em28xx/Makefile | 4 ++-- drivers/media/usb/go7007/Makefile | 2 +- drivers/media/usb/pvrusb2/Makefile| 4 ++-- drivers/media/usb/siano/Makefile | 2 +- drivers/media/usb/tm6000/Makefile | 4 ++-- drivers/media/usb/ttusb-budget/Makefile | 2 +- drivers/media/usb/usbvision/Makefile | 2 -- 36 files changed, 50 insertions(+), 64 deletions(-) -- 2.7.4
Re: [PATCH] security: mark expected switch fall-throughs
On 1/24/19 6:56 PM, Gustavo A. R. Silva wrote: > In preparation to enabling -Wimplicit-fallthrough, mark switch > cases where we are expecting to fall through. > > This patch fixes the following warnings: > > security/integrity/ima/ima_appraise.c:116:26: warning: this statement may > fall through [-Wimplicit-fallthrough=] > security/integrity/ima/ima_template_lib.c:85:10: warning: this statement may > fall through [-Wimplicit-fallthrough=] > security/integrity/ima/ima_policy.c:940:18: warning: this statement may fall > through [-Wimplicit-fallthrough=] > security/integrity/ima/ima_policy.c:943:7: warning: this statement may fall > through [-Wimplicit-fallthrough=] > security/integrity/ima/ima_policy.c:972:21: warning: this statement may fall > through [-Wimplicit-fallthrough=] > security/integrity/ima/ima_policy.c:974:7: warning: this statement may fall > through [-Wimplicit-fallthrough=] > security/smack/smack_lsm.c:3391:9: warning: this statement may fall through > [-Wimplicit-fallthrough=] > security/apparmor/domain.c:569:6: warning: this statement may fall through > [-Wimplicit-fallthrough=] > > Warning level 3 was used: -Wimplicit-fallthrough=3 > > This patch is part of the ongoing efforts to enabling -Wimplicit-fallthrough. > > Signed-off-by: Gustavo A. R. Silva looks good to me Acked-by: John Johansen > --- > security/apparmor/domain.c| 2 +- > security/integrity/ima/ima_appraise.c | 1 + > security/integrity/ima/ima_policy.c | 4 > security/integrity/ima/ima_template_lib.c | 1 + > security/smack/smack_lsm.c| 3 +-- > 5 files changed, 8 insertions(+), 3 deletions(-) > > diff --git a/security/apparmor/domain.c b/security/apparmor/domain.c > index 726910bba84b..c7c619578095 100644 > --- a/security/apparmor/domain.c > +++ b/security/apparmor/domain.c > @@ -572,7 +572,7 @@ static struct aa_label *x_to_label(struct aa_profile > *profile, > stack = NULL; > break; > } > - /* fall through to X_NAME */ > + /* fall through - to X_NAME */ > case AA_X_NAME: > if (xindex & AA_X_CHILD) > /* released by caller */ > diff --git a/security/integrity/ima/ima_appraise.c > b/security/integrity/ima/ima_appraise.c > index a2baa85ea2f5..57daf30fb7d4 100644 > --- a/security/integrity/ima/ima_appraise.c > +++ b/security/integrity/ima/ima_appraise.c > @@ -114,6 +114,7 @@ static void ima_set_cache_status(struct > integrity_iint_cache *iint, > break; > case CREDS_CHECK: > iint->ima_creds_status = status; > + /* fall through */ > case FILE_CHECK: > case POST_SETATTR: > iint->ima_file_status = status; > diff --git a/security/integrity/ima/ima_policy.c > b/security/integrity/ima/ima_policy.c > index 8bc8a1c8cb3f..122797023bdb 100644 > --- a/security/integrity/ima/ima_policy.c > +++ b/security/integrity/ima/ima_policy.c > @@ -938,10 +938,12 @@ static int ima_parse_rule(char *rule, struct > ima_rule_entry *entry) > case Opt_uid_gt: > case Opt_euid_gt: > entry->uid_op = _gt; > + /* fall through */ > case Opt_uid_lt: > case Opt_euid_lt: > if ((token == Opt_uid_lt) || (token == Opt_euid_lt)) > entry->uid_op = _lt; > + /* fall through */ > case Opt_uid_eq: > case Opt_euid_eq: > uid_token = (token == Opt_uid_eq) || > @@ -970,9 +972,11 @@ static int ima_parse_rule(char *rule, struct > ima_rule_entry *entry) > break; > case Opt_fowner_gt: > entry->fowner_op = _gt; > + /* fall through */ > case Opt_fowner_lt: > if (token == Opt_fowner_lt) > entry->fowner_op = _lt; > + /* fall through */ > case Opt_fowner_eq: > ima_log_string_op(ab, "fowner", args[0].from, > entry->fowner_op); > diff --git a/security/integrity/ima/ima_template_lib.c > b/security/integrity/ima/ima_template_lib.c > index 43752002c222..513b457ae900 100644 > --- a/security/integrity/ima/ima_template_lib.c > +++ b/security/integrity/ima/ima_template_lib.c > @@ -83,6 +83,7 @@ static void ima_show_template_data_ascii(struct seq_file *m, > /* skip ':' and '\0' */ > buf_ptr += 2; > buflen -= buf_ptr - field_data->data; > + /* fall through */ > case DATA_FMT_DIGEST: > case DATA_FMT_HEX: > if (!buflen) > diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c > index fa98394a40d0..127aa6c58e34 100644 > --- a/security/smack/smack_lsm.c > +++ b/security/smack/smack_lsm.c > @@
[PATCH 3/3] media: prefix header search paths with $(srctree)/
Currently, the Kbuild core manipulates header search paths in a crazy
way [1].
To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
the search paths in the srctree. Some Makefiles are already written in
that way, but not all. The goal of this work is to make the notation
consistent, and finally get rid of the gross hacks.
Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
("kbuild: do not drop -I without parameter").
[1]: https://patchwork.kernel.org/patch/9632347/
Signed-off-by: Masahiro Yamada
---
drivers/media/common/b2c2/Makefile| 4 ++--
drivers/media/i2c/smiapp/Makefile | 2 +-
drivers/media/mmc/siano/Makefile | 3 +--
drivers/media/pci/b2c2/Makefile | 2 +-
drivers/media/pci/bt8xx/Makefile | 4 ++--
drivers/media/pci/cx18/Makefile | 4 ++--
drivers/media/pci/cx23885/Makefile| 4 ++--
drivers/media/pci/cx88/Makefile | 4 ++--
drivers/media/pci/ddbridge/Makefile | 4 ++--
drivers/media/pci/dm1105/Makefile | 2 +-
drivers/media/pci/mantis/Makefile | 2 +-
drivers/media/pci/netup_unidvb/Makefile | 2 +-
drivers/media/pci/ngene/Makefile | 4 ++--
drivers/media/pci/pluto2/Makefile | 2 +-
drivers/media/pci/pt1/Makefile| 4 ++--
drivers/media/pci/pt3/Makefile| 4 ++--
drivers/media/pci/smipcie/Makefile| 5 ++---
drivers/media/pci/ttpci/Makefile | 4 ++--
drivers/media/platform/sti/c8sectpfe/Makefile | 4 ++--
drivers/media/spi/Makefile| 2 +-
drivers/media/usb/as102/Makefile | 2 +-
drivers/media/usb/au0828/Makefile | 4 ++--
drivers/media/usb/b2c2/Makefile | 2 +-
drivers/media/usb/cx231xx/Makefile| 4 ++--
drivers/media/usb/em28xx/Makefile | 4 ++--
drivers/media/usb/go7007/Makefile | 2 +-
drivers/media/usb/pvrusb2/Makefile| 4 ++--
drivers/media/usb/siano/Makefile | 2 +-
drivers/media/usb/tm6000/Makefile | 4 ++--
drivers/media/usb/ttusb-budget/Makefile | 2 +-
30 files changed, 47 insertions(+), 49 deletions(-)
diff --git a/drivers/media/common/b2c2/Makefile
b/drivers/media/common/b2c2/Makefile
index aa2dc24..0e32b77 100644
--- a/drivers/media/common/b2c2/Makefile
+++ b/drivers/media/common/b2c2/Makefile
@@ -4,5 +4,5 @@ b2c2-flexcop-objs += flexcop-sram.o flexcop-eeprom.o
flexcop-misc.o
b2c2-flexcop-objs += flexcop-hw-filter.o
obj-$(CONFIG_DVB_B2C2_FLEXCOP) += b2c2-flexcop.o
-ccflags-y += -Idrivers/media/dvb-frontends/
-ccflags-y += -Idrivers/media/tuners/
+ccflags-y += -I $(srctree)/drivers/media/dvb-frontends/
+ccflags-y += -I $(srctree)/drivers/media/tuners/
diff --git a/drivers/media/i2c/smiapp/Makefile
b/drivers/media/i2c/smiapp/Makefile
index f45a003..9f03aef 100644
--- a/drivers/media/i2c/smiapp/Makefile
+++ b/drivers/media/i2c/smiapp/Makefile
@@ -2,4 +2,4 @@ smiapp-objs += smiapp-core.o smiapp-regs.o \
smiapp-quirk.o smiapp-limits.o
obj-$(CONFIG_VIDEO_SMIAPP) += smiapp.o
-ccflags-y += -Idrivers/media/i2c
+ccflags-y += -I $(srctree)/drivers/media/i2c
diff --git a/drivers/media/mmc/siano/Makefile b/drivers/media/mmc/siano/Makefile
index 5fc3456..848548f 100644
--- a/drivers/media/mmc/siano/Makefile
+++ b/drivers/media/mmc/siano/Makefile
@@ -1,4 +1,3 @@
obj-$(CONFIG_SMS_SDIO_DRV) += smssdio.o
-ccflags-y += -Idrivers/media/common/siano
-
+ccflags-y += -I $(srctree)/drivers/media/common/siano
diff --git a/drivers/media/pci/b2c2/Makefile b/drivers/media/pci/b2c2/Makefile
index b43b916..14ed6e4 100644
--- a/drivers/media/pci/b2c2/Makefile
+++ b/drivers/media/pci/b2c2/Makefile
@@ -6,4 +6,4 @@ endif
b2c2-flexcop-pci-objs += flexcop-pci.o
obj-$(CONFIG_DVB_B2C2_FLEXCOP_PCI) += b2c2-flexcop-pci.o
-ccflags-y += -Idrivers/media/common/b2c2/
+ccflags-y += -I $(srctree)/drivers/media/common/b2c2/
diff --git a/drivers/media/pci/bt8xx/Makefile b/drivers/media/pci/bt8xx/Makefile
index 0b5032c..69bc0d9 100644
--- a/drivers/media/pci/bt8xx/Makefile
+++ b/drivers/media/pci/bt8xx/Makefile
@@ -6,5 +6,5 @@ bttv-objs := bttv-driver.o bttv-cards.o bttv-if.o \
obj-$(CONFIG_VIDEO_BT848) += bttv.o
obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o dst.o dst_ca.o
-ccflags-y += -Idrivers/media/dvb-frontends
-ccflags-y += -Idrivers/media/tuners
+ccflags-y += -I $(srctree)/drivers/media/dvb-frontends
+ccflags-y += -I $(srctree)/drivers/media/tuners
diff --git a/drivers/media/pci/cx18/Makefile b/drivers/media/pci/cx18/Makefile
index 9c82c2d..df00ef8 100644
--- a/drivers/media/pci/cx18/Makefile
+++ b/drivers/media/pci/cx18/Makefile
@@ -9,5 +9,5 @@ cx18-alsa-objs := cx18-alsa-main.o cx18-alsa-pcm.o
obj-$(CONFIG_VIDEO_CX18) += cx18.o
obj-$(CONFIG_VIDEO_CX18_ALSA) += cx18-alsa.o
-ccflags-y += -Idrivers/media/dvb-frontends
-ccflags-y +=
Re: [PATCH] drivers: iio: industrialio-core: add check when kzalloc fails
On Thu, Jan 24, 2019 at 4:28 PM Bharath Vedartham wrote:
>
> add code to handle the case when kzalloc fails to allocate memory to dev
>
> Signed-off-by: Bharath Vedartham
> ---
> drivers/iio/industrialio-core.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 4f5cd9f..93caa6b 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -1475,6 +1475,8 @@ struct iio_dev *iio_device_alloc(int sizeof_priv)
> }
> dev_set_name(>dev, "iio:device%d", dev->id);
> INIT_LIST_HEAD(>buffer_list);
> + } else {
> + return NULL;
I'd argue that this is a bit redundant, because `dev` is NULL, the
return below (return dev) will also return NULL.
Alex
> }
>
> return dev;
> --
> 2.7.4
>
[PATCH 1/3] media: coda: remove -I$(src) header search path
Remove the header search path to the current directory.
The compiler will search headers in the current directory by
using #include "..." instead of #include <...>
Also, change TRACE_INCLUDE_PATH to point to the location of trace.h.
Signed-off-by: Masahiro Yamada
---
drivers/media/platform/coda/Makefile| 2 --
drivers/media/platform/coda/coda-h264.c | 3 ++-
drivers/media/platform/coda/trace.h | 2 +-
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/coda/Makefile
b/drivers/media/platform/coda/Makefile
index 8582843..3eed821 100644
--- a/drivers/media/platform/coda/Makefile
+++ b/drivers/media/platform/coda/Makefile
@@ -1,5 +1,3 @@
-ccflags-y += -I$(src)
-
coda-objs := coda-common.o coda-bit.o coda-gdi.o coda-h264.o coda-jpeg.o
obj-$(CONFIG_VIDEO_CODA) += coda.o
diff --git a/drivers/media/platform/coda/coda-h264.c
b/drivers/media/platform/coda/coda-h264.c
index 635356a..6da82d1 100644
--- a/drivers/media/platform/coda/coda-h264.c
+++ b/drivers/media/platform/coda/coda-h264.c
@@ -14,7 +14,8 @@
#include
#include
#include
-#include
+
+#include "coda.h"
static const u8 coda_filler_size[8] = { 0, 7, 14, 13, 12, 11, 10, 9 };
diff --git a/drivers/media/platform/coda/trace.h
b/drivers/media/platform/coda/trace.h
index a672bfc..6cf5823 100644
--- a/drivers/media/platform/coda/trace.h
+++ b/drivers/media/platform/coda/trace.h
@@ -157,7 +157,7 @@ DEFINE_EVENT(coda_buf_meta_class, coda_dec_rot_done,
#endif /* __CODA_TRACE_H__ */
#undef TRACE_INCLUDE_PATH
-#define TRACE_INCLUDE_PATH .
+#define TRACE_INCLUDE_PATH ../../drivers/media/platform/coda
#undef TRACE_INCLUDE_FILE
#define TRACE_INCLUDE_FILE trace
--
2.7.4
[PATCH 2/3] media: remove unneeded header search paths
I was able to build without these extra header search paths. Signed-off-by: Masahiro Yamada --- drivers/media/dvb-frontends/cxd2880/Makefile | 2 -- drivers/media/pci/bt8xx/Makefile | 1 - drivers/media/platform/sti/c8sectpfe/Makefile | 1 - drivers/media/radio/Makefile | 2 -- drivers/media/spi/Makefile| 2 -- drivers/media/usb/cx231xx/Makefile| 1 - drivers/media/usb/usbvision/Makefile | 2 -- 7 files changed, 11 deletions(-) diff --git a/drivers/media/dvb-frontends/cxd2880/Makefile b/drivers/media/dvb-frontends/cxd2880/Makefile index c6baa4c..646598b 100644 --- a/drivers/media/dvb-frontends/cxd2880/Makefile +++ b/drivers/media/dvb-frontends/cxd2880/Makefile @@ -14,5 +14,3 @@ cxd2880-objs := cxd2880_common.o \ cxd2880_top.o obj-$(CONFIG_DVB_CXD2880) += cxd2880.o - -ccflags-y += -Idrivers/media/dvb-frontends diff --git a/drivers/media/pci/bt8xx/Makefile b/drivers/media/pci/bt8xx/Makefile index 7f1c3be..0b5032c 100644 --- a/drivers/media/pci/bt8xx/Makefile +++ b/drivers/media/pci/bt8xx/Makefile @@ -7,5 +7,4 @@ obj-$(CONFIG_VIDEO_BT848) += bttv.o obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o dst.o dst_ca.o ccflags-y += -Idrivers/media/dvb-frontends -ccflags-y += -Idrivers/media/common ccflags-y += -Idrivers/media/tuners diff --git a/drivers/media/platform/sti/c8sectpfe/Makefile b/drivers/media/platform/sti/c8sectpfe/Makefile index 34d6947..4bf0c6b 100644 --- a/drivers/media/platform/sti/c8sectpfe/Makefile +++ b/drivers/media/platform/sti/c8sectpfe/Makefile @@ -4,6 +4,5 @@ c8sectpfe-y += c8sectpfe-core.o c8sectpfe-common.o c8sectpfe-dvb.o \ obj-$(CONFIG_DVB_C8SECTPFE) += c8sectpfe.o -ccflags-y += -Idrivers/media/common ccflags-y += -Idrivers/media/dvb-frontends/ ccflags-y += -Idrivers/media/tuners/ diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile index 37e6e82..53c7ae1 100644 --- a/drivers/media/radio/Makefile +++ b/drivers/media/radio/Makefile @@ -36,5 +36,3 @@ obj-$(CONFIG_RADIO_TEA575X) += tea575x.o obj-$(CONFIG_USB_RAREMONO) += radio-raremono.o shark2-objs := radio-shark2.o radio-tea5777.o - -ccflags-y += -Isound diff --git a/drivers/media/spi/Makefile b/drivers/media/spi/Makefile index 9e53677..c254e2a 100644 --- a/drivers/media/spi/Makefile +++ b/drivers/media/spi/Makefile @@ -1,6 +1,4 @@ obj-$(CONFIG_VIDEO_GS1662) += gs1662.o obj-$(CONFIG_CXD2880_SPI_DRV) += cxd2880-spi.o -ccflags-y += -Idrivers/media/dvb-core -ccflags-y += -Idrivers/media/dvb-frontends ccflags-y += -Idrivers/media/dvb-frontends/cxd2880 diff --git a/drivers/media/usb/cx231xx/Makefile b/drivers/media/usb/cx231xx/Makefile index c023d97..af824fd 100644 --- a/drivers/media/usb/cx231xx/Makefile +++ b/drivers/media/usb/cx231xx/Makefile @@ -11,4 +11,3 @@ obj-$(CONFIG_VIDEO_CX231XX_DVB) += cx231xx-dvb.o ccflags-y += -Idrivers/media/tuners ccflags-y += -Idrivers/media/dvb-frontends -ccflags-y += -Idrivers/media/usb/dvb-usb diff --git a/drivers/media/usb/usbvision/Makefile b/drivers/media/usb/usbvision/Makefile index 494d030..e8e5eda 100644 --- a/drivers/media/usb/usbvision/Makefile +++ b/drivers/media/usb/usbvision/Makefile @@ -1,5 +1,3 @@ usbvision-objs := usbvision-core.o usbvision-video.o usbvision-i2c.o usbvision-cards.o obj-$(CONFIG_VIDEO_USBVISION) += usbvision.o - -ccflags-y += -Idrivers/media/tuners -- 2.7.4
Re: [PATCH net-next] bridge: remove duplicated include from br_multicast.c
From: YueHaibing Date: Fri, 25 Jan 2019 10:59:09 +0800 > Remove duplicated include. > > Signed-off-by: YueHaibing Applied.
RE: [PATCH] arm64 memory accesses may cause undefined fault on Fujitsu-A64FX
Hi, Mark, James > -Original Message- > From: linux-arm-kernel > [mailto:linux-arm-kernel-boun...@lists.infradead.org] On Behalf Of > Zhang, Lei > Sent: Wednesday, January 23, 2019 9:51 PM > To: 'Mark Rutland'; 'james.mo...@arm.com' > Cc: 'catalin.mari...@arm.com'; 'will.dea...@arm.com'; > 'linux-kernel@vger.kernel.org'; > 'linux-arm-ker...@lists.infradead.org'; Zhang, Lei/張 雷 > Subject: RE: [PATCH] arm64 memory accesses may cause undefined fault on > Fujitsu-A64FX > > At first thanks for your comments. > I thinks James's comments is quite similar with above comment. > I am reviewing this point now. > I will respond to your questions after I check this. As your comments, this patch cannot avoid this problem completely. So I will post a new patch to resolve this problem in different way. Lei Zhang zhang@jp.fujitsu.com
Re: [PATCH] net: dev_is_mac_header_xmit() true for ARPHRD_RAWIP
From: Maciej Żenczykowski Date: Thu, 24 Jan 2019 03:07:02 -0800 > From: Maciej Żenczykowski > > __bpf_redirect() and act_mirred checks this boolean > to determine whether to prefix an ethernet header. > > Signed-off-by: Maciej Żenczykowski Applied.
Request for Quotation
Nice day to you! My Names Sasha Kelley from Earthlink, Inc. Moscow Russia There is an available invitation to tender suitable for your products and I would like to inquire if your company will be interested to submit offer for your products in Moscow Russia. Please confirm interest by sending product catalog/price list for our review. Looking forward to hearing from you. Best Regards, Area Manager Sasha Kelley Tel: +79017731031 E-mail: earthl...@zoho.com Earthlink, Inc (Moscow).
Re: [PATCH] net: usb: asix: ax88772_bind return error when hw_reset fail
From: Zhang Run Date: Thu, 24 Jan 2019 13:48:49 +0800 > The ax88772_bind() should return error code immediately when the PHY > was not reset properly through ax88772a_hw_reset(). > Otherwise, The asix_get_phyid() will block when get the PHY > Identifier from the PHYSID1 MII registers through asix_mdio_read() > due to the PHY isn't ready. Furthermore, it will produce a lot of > error message cause system crash.As follows: > asix 1-1:1.0 (unnamed net_device) (uninitialized): Failed to write > reg index 0x: -71 > asix 1-1:1.0 (unnamed net_device) (uninitialized): Failed to send > software reset: ffb9 > asix 1-1:1.0 (unnamed net_device) (uninitialized): Failed to write > reg index 0x: -71 > asix 1-1:1.0 (unnamed net_device) (uninitialized): Failed to enable > software MII access > asix 1-1:1.0 (unnamed net_device) (uninitialized): Failed to read > reg index 0x: -71 > asix 1-1:1.0 (unnamed net_device) (uninitialized): Failed to write > reg index 0x: -71 > asix 1-1:1.0 (unnamed net_device) (uninitialized): Failed to enable > software MII access > asix 1-1:1.0 (unnamed net_device) (uninitialized): Failed to read > reg index 0x: -71 > ... > > Signed-off-by: Zhang Run > Reviewed-by: Yang Wei Applied.
Re: [PATCH] tipc: remove dead code in struct tipc_topsrv
From: Zhaolong Zhang Date: Thu, 24 Jan 2019 10:06:41 +0800 > max_rcvbuf_size is no longer used since commit "414574a0af36". > > Signed-off-by: Zhaolong Zhang Applied.
Re: [PATCH 5/5] dax: "Hotplug" persistent memory for use like normal RAM
On Thu, Jan 24, 2019 at 10:13 PM Jane Chu wrote: > > Hi, Dave, > > While chatting with my colleague Erwin about the patchset, it occurred > that we're not clear about the error handling part. Specifically, > > 1. If an uncorrectable error is detected during a 'load' in the hot > plugged pmem region, how will the error be handled? will it be > handled like PMEM or DRAM? DRAM. > 2. If a poison is set, and is persistent, which entity should clear > the poison, and badblock(if applicable)? If it's user's responsibility, > does ndctl support the clearing in this mode? With persistent memory advertised via a static logical-to-physical storage/dax device mapping, once an error develops it destroys a physical *and* logical part of a device address space. That loss of logical address space makes error clearing a necessity. However, with the DRAM / "System RAM" error handling model, the OS can just offline the page and map a different one to repair the logical address space. So, no, ndctl will not have explicit enabling to clear volatile errors, the OS will just dynamically offline problematic pages.
Re: [PATCH 3/9] drivers/firewire/core-iso.c: Convert to use vm_insert_range_buggy
On Fri, Jan 11, 2019 at 8:34 PM Souptick Joarder wrote:
>
> Convert to use vm_insert_range_buggy to map range of kernel memory
> to user vma.
>
> This driver has ignored vm_pgoff and mapped the entire pages. We
> could later "fix" these drivers to behave according to the normal
> vm_pgoff offsetting simply by removing the _buggy suffix on the
> function name and if that causes regressions, it gives us an easy
> way to revert.
>
> Signed-off-by: Souptick Joarder
Any comment on this patch ?
> ---
> drivers/firewire/core-iso.c | 15 ++-
> 1 file changed, 2 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/firewire/core-iso.c b/drivers/firewire/core-iso.c
> index 35e784c..99a6582 100644
> --- a/drivers/firewire/core-iso.c
> +++ b/drivers/firewire/core-iso.c
> @@ -107,19 +107,8 @@ int fw_iso_buffer_init(struct fw_iso_buffer *buffer,
> struct fw_card *card,
> int fw_iso_buffer_map_vma(struct fw_iso_buffer *buffer,
> struct vm_area_struct *vma)
> {
> - unsigned long uaddr;
> - int i, err;
> -
> - uaddr = vma->vm_start;
> - for (i = 0; i < buffer->page_count; i++) {
> - err = vm_insert_page(vma, uaddr, buffer->pages[i]);
> - if (err)
> - return err;
> -
> - uaddr += PAGE_SIZE;
> - }
> -
> - return 0;
> + return vm_insert_range_buggy(vma, buffer->pages,
> + buffer->page_count);
> }
>
> void fw_iso_buffer_destroy(struct fw_iso_buffer *buffer,
> --
> 1.9.1
>
Re: [PATCH 2/9] arch/arm/mm/dma-mapping.c: Convert to use vm_insert_range
On Fri, Jan 11, 2019 at 8:33 PM Souptick Joarder wrote:
>
> Convert to use vm_insert_range() to map range of kernel
> memory to user vma.
>
> Signed-off-by: Souptick Joarder
Any comment on this patch ?
> ---
> arch/arm/mm/dma-mapping.c | 22 ++
> 1 file changed, 6 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 78de138..5334391 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -1582,31 +1582,21 @@ static int __arm_iommu_mmap_attrs(struct device *dev,
> struct vm_area_struct *vma
> void *cpu_addr, dma_addr_t dma_addr, size_t size,
> unsigned long attrs)
> {
> - unsigned long uaddr = vma->vm_start;
> - unsigned long usize = vma->vm_end - vma->vm_start;
> struct page **pages = __iommu_get_pages(cpu_addr, attrs);
> unsigned long nr_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
> - unsigned long off = vma->vm_pgoff;
> + int err;
>
> if (!pages)
> return -ENXIO;
>
> - if (off >= nr_pages || (usize >> PAGE_SHIFT) > nr_pages - off)
> + if (vma->vm_pgoff >= nr_pages)
> return -ENXIO;
>
> - pages += off;
> -
> - do {
> - int ret = vm_insert_page(vma, uaddr, *pages++);
> - if (ret) {
> - pr_err("Remapping memory failed: %d\n", ret);
> - return ret;
> - }
> - uaddr += PAGE_SIZE;
> - usize -= PAGE_SIZE;
> - } while (usize > 0);
> + err = vm_insert_range(vma, pages, nr_pages);
> + if (err)
> + pr_err("Remapping memory failed: %d\n", err);
>
> - return 0;
> + return err;
> }
> static int arm_iommu_mmap_attrs(struct device *dev,
> struct vm_area_struct *vma, void *cpu_addr,
> --
> 1.9.1
>
Re: [GIT PULL] Hyper-V hv_netvsc commits for 5.0
From: Sasha Levin Date: Wed, 23 Jan 2019 13:30:29 -0500 > Three patches from Haiyang Zhang to fix settings hash key using ethtool, > and Adrian Vladu's first patch fixing a few spelling mistakes. Pulled, thanks.
Re: [PATCH 5/5] dax: "Hotplug" persistent memory for use like normal RAM
Hi, Dave,
While chatting with my colleague Erwin about the patchset, it occurred
that we're not clear about the error handling part. Specifically,
1. If an uncorrectable error is detected during a 'load' in the hot
plugged pmem region, how will the error be handled? will it be
handled like PMEM or DRAM?
2. If a poison is set, and is persistent, which entity should clear
the poison, and badblock(if applicable)? If it's user's responsibility,
does ndctl support the clearing in this mode?
thanks!
-jane
On 1/24/2019 3:14 PM, Dave Hansen wrote:
From: Dave Hansen
This is intended for use with NVDIMMs that are physically persistent
(physically like flash) so that they can be used as a cost-effective
RAM replacement. Intel Optane DC persistent memory is one
implementation of this kind of NVDIMM.
Currently, a persistent memory region is "owned" by a device driver,
either the "Direct DAX" or "Filesystem DAX" drivers. These drivers
allow applications to explicitly use persistent memory, generally
by being modified to use special, new libraries. (DIMM-based
persistent memory hardware/software is described in great detail
here: Documentation/nvdimm/nvdimm.txt).
However, this limits persistent memory use to applications which
*have* been modified. To make it more broadly usable, this driver
"hotplugs" memory into the kernel, to be managed and used just like
normal RAM would be.
To make this work, management software must remove the device from
being controlled by the "Device DAX" infrastructure:
echo -n dax0.0 > /sys/bus/dax/drivers/device_dax/remove_id
echo -n dax0.0 > /sys/bus/dax/drivers/device_dax/unbind
and then bind it to this new driver:
echo -n dax0.0 > /sys/bus/dax/drivers/kmem/new_id
echo -n dax0.0 > /sys/bus/dax/drivers/kmem/bind
After this, there will be a number of new memory sections visible
in sysfs that can be onlined, or that may get onlined by existing
udev-initiated memory hotplug rules.
This rebinding procedure is currently a one-way trip. Once memory
is bound to "kmem", it's there permanently and can not be
unbound and assigned back to device_dax.
The kmem driver will never bind to a dax device unless the device
is *explicitly* bound to the driver. There are two reasons for
this: One, since it is a one-way trip, it can not be undone if
bound incorrectly. Two, the kmem driver destroys data on the
device. Think of if you had good data on a pmem device. It
would be catastrophic if you compile-in "kmem", but leave out
the "device_dax" driver. kmem would take over the device and
write volatile data all over your good data.
This inherits any existing NUMA information for the newly-added
memory from the persistent memory device that came from the
firmware. On Intel platforms, the firmware has guarantees that
require each socket's persistent memory to be in a separate
memory-only NUMA node. That means that this patch is not expected
to create NUMA nodes, but will simply hotplug memory into existing
nodes.
Because NUMA nodes are created, the existing NUMA APIs and tools
are sufficient to create policies for applications or memory areas
to have affinity for or an aversion to using this memory.
There is currently some metadata at the beginning of pmem regions.
The section-size memory hotplug restrictions, plus this small
reserved area can cause the "loss" of a section or two of capacity.
This should be fixable in follow-on patches. But, as a first step,
losing 256MB of memory (worst case) out of hundreds of gigabytes
is a good tradeoff vs. the required code to fix this up precisely.
This calculation is also the reason we export
memory_block_size_bytes().
Signed-off-by: Dave Hansen
Cc: Dan Williams
Cc: Dave Jiang
Cc: Ross Zwisler
Cc: Vishal Verma
Cc: Tom Lendacky
Cc: Andrew Morton
Cc: Michal Hocko
Cc: linux-nvd...@lists.01.org
Cc: linux-kernel@vger.kernel.org
Cc: linux...@kvack.org
Cc: Huang Ying
Cc: Fengguang Wu
Cc: Borislav Petkov
Cc: Bjorn Helgaas
Cc: Yaowei Bai
Cc: Takashi Iwai
Cc: Jerome Glisse
---
b/drivers/base/memory.c |1
b/drivers/dax/Kconfig | 16 +++
b/drivers/dax/Makefile |1
b/drivers/dax/kmem.c| 108
4 files changed, 126 insertions(+)
diff -puN drivers/base/memory.c~dax-kmem-try-4 drivers/base/memory.c
--- a/drivers/base/memory.c~dax-kmem-try-4 2019-01-24 15:13:15.987199535
-0800
+++ b/drivers/base/memory.c 2019-01-24 15:13:15.994199535 -0800
@@ -88,6 +88,7 @@ unsigned long __weak memory_block_size_b
{
return MIN_MEMORY_BLOCK_SIZE;
}
+EXPORT_SYMBOL_GPL(memory_block_size_bytes);
static unsigned long get_memory_block_size(void)
{
diff -puN drivers/dax/Kconfig~dax-kmem-try-4 drivers/dax/Kconfig
--- a/drivers/dax/Kconfig~dax-kmem-try-42019-01-24 15:13:15.988199535
-0800
+++ b/drivers/dax/Kconfig 2019-01-24 15:13:15.994199535 -0800
@@ -32,6 +32,22 @@ config DEV_DAX_PMEM
Say M if unsure
[PATCH] crypto: bcm: remove -I. header search path and unused macro define
The header search path -I. in kernel Makefiles is very suspicious; it allows the compiler to search for headers in the top of $(srctree), where obviously no header file exists. 'git grep BCMDRIVER' has no hit. So, this macro is not referenced. I was able to build this driver without the extra compiler options. Signed-off-by: Masahiro Yamada --- drivers/crypto/bcm/Makefile | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/crypto/bcm/Makefile b/drivers/crypto/bcm/Makefile index 13cb80e..7469e19 100644 --- a/drivers/crypto/bcm/Makefile +++ b/drivers/crypto/bcm/Makefile @@ -11,5 +11,3 @@ obj-$(CONFIG_CRYPTO_DEV_BCM_SPU) := bcm_crypto_spu.o bcm_crypto_spu-objs := util.o spu.o spu2.o cipher.o - -ccflags-y += -I. -DBCMDRIVER -- 2.7.4
Re: [PATCH] net: amd8111e: clean up two minor indentation issues
From: Colin King Date: Tue, 22 Jan 2019 14:37:55 + > From: Colin Ian King > > Two statements are incorrecly indented, fix these by removing a space. > > Signed-off-by: Colin Ian King Applied.
[PATCH v4 2/5] usb: phy: Workaround for USB erratum-A005728
From: Suresh Gupta
PHY_CLK_VALID bit for UTMI PHY in USBDR does not set even
if PHY is providing valid clock. Workaround for this
involves resetting of PHY and check PHY_CLK_VALID bit
multiple times. If PHY_CLK_VALID bit is still not set even
after 5 retries, it would be safe to deaclare that PHY
clock is not available.
This erratum is applicable for USBDR less then ver 2.4.
Signed-off-by: Suresh Gupta
Signed-off-by: Yinbo Zhu
---
Change in v4:
Incorrect indentation of the continuation line.
replace pr_err with dev_err.
drivers/usb/host/ehci-fsl.c | 38 +++---
drivers/usb/host/ehci-fsl.h |3 +++
2 files changed, 30 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 38674b7..373a816 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -183,6 +183,17 @@ static int fsl_ehci_drv_probe(struct platform_device *pdev)
return retval;
}
+static bool usb_phy_clk_valid(struct usb_hcd *hcd)
+{
+ void __iomem *non_ehci = hcd->regs;
+ bool ret = true;
+
+ if (!(ioread32be(non_ehci + FSL_SOC_USB_CTRL) & PHY_CLK_VALID))
+ ret = false;
+
+ return ret;
+}
+
static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
enum fsl_usb2_phy_modes phy_mode,
unsigned int port_offset)
@@ -226,6 +237,17 @@ static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
/* fall through */
case FSL_USB2_PHY_UTMI:
case FSL_USB2_PHY_UTMI_DUAL:
+ /* PHY_CLK_VALID bit is de-featured from all controller
+* versions below 2.4 and is to be checked only for
+* internal UTMI phy
+*/
+ if (pdata->controller_ver > FSL_USB_VER_2_4 &&
+ pdata->have_sysif_regs && !usb_phy_clk_valid(hcd)) {
+ dev_err(dev,
+ "%s: USB PHY clock invalid\n", dev_name(dev));
+ return -EINVAL;
+ }
+
if (pdata->have_sysif_regs && pdata->controller_ver) {
/* controller version 1.6 or above */
tmp = ioread32be(non_ehci + FSL_SOC_USB_CTRL);
@@ -249,17 +271,11 @@ static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
break;
}
- /*
-* check PHY_CLK_VALID to determine phy clock presence before writing
-* to portsc
-*/
- if (pdata->check_phy_clk_valid) {
- if (!(ioread32be(non_ehci + FSL_SOC_USB_CTRL) &
- PHY_CLK_VALID)) {
- dev_warn(hcd->self.controller,
-"USB PHY clock invalid\n");
- return -EINVAL;
- }
+ if (pdata->have_sysif_regs &&
+ pdata->controller_ver > FSL_USB_VER_1_6 &&
+ !usb_phy_clk_valid(hcd)) {
+ dev_warn(hcd->self.controller, "USB PHY clock invalid\n");
+ return -EINVAL;
}
ehci_writel(ehci, portsc, >regs->port_status[port_offset]);
diff --git a/drivers/usb/host/ehci-fsl.h b/drivers/usb/host/ehci-fsl.h
index cbc4220..9d18c6e 100644
--- a/drivers/usb/host/ehci-fsl.h
+++ b/drivers/usb/host/ehci-fsl.h
@@ -50,4 +50,7 @@
#define UTMI_PHY_EN (1<<9)
#define ULPI_PHY_CLK_SEL(1<<10)
#define PHY_CLK_VALID (1<<17)
+
+/* Retry count for checking UTMI PHY CLK validity */
+#define UTMI_PHY_CLK_VALID_CHK_RETRY 5
#endif /* _EHCI_FSL_H */
--
1.7.1
[PATCH v4 4/5] usb: host: Stops USB controller init if PLL fails to lock
From: Ramneek Mehresh
USB erratum-A006918 workaround tries to start internal PHY inside
uboot (when PLL fails to lock). However, if the workaround also
fails, then USB initialization is also stopped inside Linux.
Erratum-A006918 workaround failure creates "fsl,erratum_a006918"
node in device-tree. Presence of this node in device-tree is
used to stop USB controller initialization in Linux
Signed-off-by: Ramneek Mehresh
Signed-off-by: Suresh Gupta
Signed-off-by: Yinbo Zhu
---
drivers/usb/host/ehci-fsl.c |5 +
drivers/usb/host/fsl-mph-dr-of.c |3 ++-
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 373a816..8b47277 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -236,6 +236,11 @@ static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
portsc |= PORT_PTS_PTW;
/* fall through */
case FSL_USB2_PHY_UTMI:
+ if (pdata->has_fsl_erratum_a006918) {
+ pr_warn("fsl-ehci: USB PHY clock invalid\n");
+ return -EINVAL;
+ }
+
case FSL_USB2_PHY_UTMI_DUAL:
/* PHY_CLK_VALID bit is de-featured from all controller
* versions below 2.4 and is to be checked only for
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 4f8b8a0..762b976 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -224,13 +224,14 @@ static int fsl_usb2_mph_dr_of_probe(struct
platform_device *ofdev)
of_property_read_bool(np, "fsl,usb-erratum-a005275");
pdata->has_fsl_erratum_a005697 =
of_property_read_bool(np, "fsl,usb_erratum-a005697");
+ pdata->has_fsl_erratum_a006918 =
+ of_property_read_bool(np, "fsl,usb_erratum-a006918");
if (of_get_property(np, "fsl,usb_erratum_14", NULL))
pdata->has_fsl_erratum_14 = 1;
else
pdata->has_fsl_erratum_14 = 0;
-
/*
* Determine whether phy_clk_valid needs to be checked
* by reading property in device tree
--
1.7.1
[PATCH v4 3/5] usb: linux/fsl_device: Add platform member has_fsl_erratum_a006918
From: Yinbo Zhu
This patch is to add member has_fsl_erratum_a006918 in platform data
Signed-off-by: Yinbo Zhu
---
include/linux/fsl_devices.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
index 5da56a6..4c613da 100644
--- a/include/linux/fsl_devices.h
+++ b/include/linux/fsl_devices.h
@@ -102,6 +102,7 @@ struct fsl_usb2_platform_data {
unsignedhas_fsl_erratum_14:1;
unsignedhas_fsl_erratum_a005275:1;
unsignedhas_fsl_erratum_a005697:1;
+ unsignedhas_fsl_erratum_a006918:1;
unsignedcheck_phy_clk_valid:1;
/* register save area for suspend/resume */
--
1.7.1
[PATCH v4 5/5] usb :fsl: Change string format for errata property
From: Nikhil Badola Remove USB errata checking code from driver. Applicability of erratum is retrieved by reading corresponding property in device tree. This property is written during device tree fixup. Signed-off-by: Ramneek Mehresh Signed-off-by: Nikhil Badola Signed-off-by: Yinbo Zhu --- drivers/usb/host/fsl-mph-dr-of.c |7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c index 762b976..ae8f60f 100644 --- a/drivers/usb/host/fsl-mph-dr-of.c +++ b/drivers/usb/host/fsl-mph-dr-of.c @@ -226,11 +226,8 @@ static int fsl_usb2_mph_dr_of_probe(struct platform_device *ofdev) of_property_read_bool(np, "fsl,usb_erratum-a005697"); pdata->has_fsl_erratum_a006918 = of_property_read_bool(np, "fsl,usb_erratum-a006918"); - - if (of_get_property(np, "fsl,usb_erratum_14", NULL)) - pdata->has_fsl_erratum_14 = 1; - else - pdata->has_fsl_erratum_14 = 0; + pdata->has_fsl_erratum_14 = + of_property_read_bool(np, "fsl,usb_erratum-14"); /* * Determine whether phy_clk_valid needs to be checked -- 1.7.1
[PATCH v4 1/5] usb: fsl: Set USB_EN bit to select ULPI phy
From: Nikhil Badola Set USB_EN bit to select ULPI phy for USB controller version 2.5 Signed-off-by: Nikhil Badola Signed-off-by: Yinbo Zhu --- Change in v4: Incorrect indentation of the continuation line drivers/usb/host/ehci-fsl.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c index e3d0c1c..38674b7 100644 --- a/drivers/usb/host/ehci-fsl.c +++ b/drivers/usb/host/ehci-fsl.c @@ -122,6 +122,12 @@ static int fsl_ehci_drv_probe(struct platform_device *pdev) tmp |= 0x4; iowrite32be(tmp, hcd->regs + FSL_SOC_USB_CTRL); } + + /* Set USB_EN bit to select ULPI phy for USB controller version 2.5 */ + if (pdata->controller_ver == FSL_USB_VER_2_5 && + pdata->phy_mode == FSL_USB2_PHY_ULPI) + iowrite32be(USB_CTRL_USB_EN, hcd->regs + FSL_SOC_USB_CTRL); + /* * Enable UTMI phy and program PTS field in UTMI mode before asserting * controller reset for USB Controller version 2.5 -- 1.7.1
Re: [PATCH] iio: adc: ti-ads7950: inconsistency with spi msg
Hello Florian On Thu, Jan 24, 2019 at 8:30 PM Florian Fainelli wrote: > > > Hi Justin, > > On 1/24/19 5:56 PM, justinpo...@gmail.com wrote: > > From: Justin Chen > > > > To read a channel we require 3 cycles to send, process, and receive > > the data. The transfer buffer for the third transaction is left blank. > > This leaves it up to the SPI driver to decide what to do. > > > > In one particular case, if the tx buffer is not set the spi driver > > sets it to 0xff. This puts the ADC in a alarm programming state, > > therefore the following read to a channel becomes erroneous. > > > > Instead of leaving us to the mercy of the SPI driver, we send the > > ADC cmd on the third transaction to prevent inconsistent behavior. > > Do you think this warrants a Fixes: tag? > This was an issue when the driver was introduced. Should I tag that commit the introduced the driver? > > > > Signed-off-by: Justin Chen > > --- > > drivers/iio/adc/ti-ads7950.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/iio/adc/ti-ads7950.c b/drivers/iio/adc/ti-ads7950.c > > index 0ad6359..5453e10 100644 > > --- a/drivers/iio/adc/ti-ads7950.c > > +++ b/drivers/iio/adc/ti-ads7950.c > > @@ -422,6 +422,7 @@ static int ti_ads7950_probe(struct spi_device *spi) > > st->scan_single_xfer[1].tx_buf = >single_tx; > > st->scan_single_xfer[1].len = 2; > > st->scan_single_xfer[1].cs_change = 1; > > + st->scan_single_xfer[2].rx_buf = >single_tx; > > Should this be st->scan_single_xfer[2].tx_buf? > Oh yes. Good catch. Careless mistake! v2 incoming. > > st->scan_single_xfer[2].rx_buf = >single_rx; > > st->scan_single_xfer[2].len = 2; > > > > > > -- > Florian
Re: [PATCH 07/10] venus: helpers: add three more helper functions
On Thu, Jan 24, 2019 at 5:54 PM Stanimir Varbanov wrote: > > Hi Alex, > > Thanks for the review! > > On 1/24/19 10:43 AM, Alexandre Courbot wrote: > > On Fri, Jan 18, 2019 at 1:21 AM Stanimir Varbanov > > wrote: > >> > >> This adds three more helper functions: > >> * for internal buffers reallocation, applicable when we are doing > >> dynamic resolution change > >> * for initial buffer processing of capture and output queue buffer > >> types > >> > >> All of them will be needed for stateful Codec API support. > >> > >> Signed-off-by: Stanimir Varbanov > >> --- > >> drivers/media/platform/qcom/venus/helpers.c | 82 + > >> drivers/media/platform/qcom/venus/helpers.h | 2 + > >> 2 files changed, 84 insertions(+) > >> > >> diff --git a/drivers/media/platform/qcom/venus/helpers.c > >> b/drivers/media/platform/qcom/venus/helpers.c > >> index f33bbfea3576..637ce7b82d94 100644 > >> --- a/drivers/media/platform/qcom/venus/helpers.c > >> +++ b/drivers/media/platform/qcom/venus/helpers.c > >> @@ -322,6 +322,52 @@ int venus_helper_intbufs_free(struct venus_inst *inst) > >> } > >> EXPORT_SYMBOL_GPL(venus_helper_intbufs_free); > >> > >> +int venus_helper_intbufs_realloc(struct venus_inst *inst) > > > > Does this function actually reallocate buffers? It seems to just free > > what we had previously. > > The function free all internal buffers except PERSIST. After that the > buffers are allocated in intbufs_set_buffer function (I know that the > function name is misleading). Yeah, that's what I felt - do you think you can fix this for clarity?
Re: [PATCH 10/10] venus: dec: make decoder compliant with stateful codec API
On Thu, Jan 24, 2019 at 9:34 PM Stanimir Varbanov
wrote:
>
> Hi Alex,
>
> Thanks for the comments!
>
> On 1/24/19 10:44 AM, Alexandre Courbot wrote:
> > On Fri, Jan 18, 2019 at 1:21 AM Stanimir Varbanov
> > wrote:
> >>
> >> This refactored code for start/stop streaming vb2 operations and
> >
> > s/refactored/refactors?
>
> Ack.
>
> >
> >> adds a state machine handling similar to the one in stateful codec
> >> API documentation. One major change is that now the HFI session is
> >> started on STREAMON(OUTPUT) and stopped on REQBUF(OUTPUT,count=0),
> >> during that time streamoff(cap,out) just flush buffers but doesn't
> >
> > streamoff(cap,out) should probably be in capitals for consistency.
>
> OK.
>
> >
> >> stop the session. The other major change is that now the capture
> >> and output queues are completely separated.
> >>
> >> Signed-off-by: Stanimir Varbanov
> >> ---
> >> drivers/media/platform/qcom/venus/core.h| 20 +-
> >> drivers/media/platform/qcom/venus/helpers.c | 23 +-
> >> drivers/media/platform/qcom/venus/helpers.h | 5 +
> >> drivers/media/platform/qcom/venus/vdec.c| 449
> >> 4 files changed, 389 insertions(+), 108 deletions(-)
> >>
> >> diff --git a/drivers/media/platform/qcom/venus/core.h
> >> b/drivers/media/platform/qcom/venus/core.h
> >> index 79c7e816c706..5a133c203455 100644
> >> --- a/drivers/media/platform/qcom/venus/core.h
> >> +++ b/drivers/media/platform/qcom/venus/core.h
> >> @@ -218,6 +218,15 @@ struct venus_buffer {
> >>
> >> #define to_venus_buffer(ptr) container_of(ptr, struct venus_buffer, vb)
> >>
> >> +#define DEC_STATE_UNINIT 0
> >
> > Not sure about "uninit", DEC_STATE_DEINIT may be more explicit here?
>
> I don't have strong opinion on that, so I will change it.
>
> >
> >> +#define DEC_STATE_INIT 1
> >> +#define DEC_STATE_CAPTURE_SETUP2
> >> +#define DEC_STATE_STOPPED 3
> >> +#define DEC_STATE_SEEK 4
> >> +#define DEC_STATE_DRAIN5
> >> +#define DEC_STATE_DECODING 6
> >> +#define DEC_STATE_DRC 7
> >
> > How about defining these as an enum, for better type safety? I'd also
> > prefix with VENUS_ to avoid possible (if unlikely) name collisions.
>
> OK.
>
> >
> >> +
> >> /**
> >> * struct venus_inst - holds per instance paramerters
> >> *
> >> @@ -241,6 +250,10 @@ struct venus_buffer {
> >> * @colorspace:current color space
> >> * @quantization: current quantization
> >> * @xfer_func: current xfer function
> >> + * @codec_state: current codec API state (see DEC/ENC_STATE_)
> >> + * @reconf_wait: wait queue for resolution change event
> >> + * @ten_bits: does new stream is 10bits depth
> >
> > "is new stream 10 bits deep" maybe?
>
> that is better description, but it should be in this patch (I have made
> 10bits support but didn't included in that initial stateful codec patch).
>
> >
> >> + * @buf_count: used to count number number of buffers (reqbuf(0))
> >
> > "number" written twice here.
>
> OK.
>
> >
> >> * @fps: holds current FPS
> >> * @timeperframe: holds current time per frame structure
> >> * @fmt_out: a reference to output format structure
> >> @@ -255,8 +268,6 @@ struct venus_buffer {
> >> * @opb_buftype: output picture buffer type
> >> * @opb_fmt: output picture buffer raw format
> >> * @reconfig: a flag raised by decoder when the stream resolution changed
> >> - * @reconfig_width:holds the new width
> >> - * @reconfig_height: holds the new height
> >> * @hfi_codec: current codec for this instance in HFI space
> >> * @sequence_cap: a sequence counter for capture queue
> >> * @sequence_out: a sequence counter for output queue
> >> @@ -296,6 +307,9 @@ struct venus_inst {
> >> u8 ycbcr_enc;
> >> u8 quantization;
> >> u8 xfer_func;
> >> + unsigned int codec_state;
> >
> > As mentioned above, with an enum the type of this member would make it
> > obvious which values it can accept.
> >
> >> + wait_queue_head_t reconf_wait;
> >> + int buf_count;
> >> u64 fps;
> >> struct v4l2_fract timeperframe;
> >> const struct venus_format *fmt_out;
> >> @@ -310,8 +324,6 @@ struct venus_inst {
> >> u32 opb_buftype;
> >> u32 opb_fmt;
> >> bool reconfig;
> >> - u32 reconfig_width;
> >> - u32 reconfig_height;
> >> u32 hfi_codec;
> >> u32 sequence_cap;
> >> u32 sequence_out;
> >> diff --git a/drivers/media/platform/qcom/venus/helpers.c
> >> b/drivers/media/platform/qcom/venus/helpers.c
> >> index 637ce7b82d94..25d8cceccae4 100644
> >> --- a/drivers/media/platform/qcom/venus/helpers.c
> >> +++ b/drivers/media/platform/qcom/venus/helpers.c
> >> @@ -1030,16 +1030,15 @@ void venus_helper_vb2_buf_queue(struct vb2_buffer
> >> *vb)
> >>
> >>
Re: [PATCH 09/10] venus: vdec: allow bigger sizeimage set by clients
On Thu, Jan 24, 2019 at 7:05 PM Stanimir Varbanov
wrote:
>
> Hi Alex,
>
> Thanks for the comments!
>
> On 1/24/19 10:43 AM, Alexandre Courbot wrote:
> > On Fri, Jan 18, 2019 at 1:21 AM Stanimir Varbanov
> > wrote:
> >>
> >> In most of the cases the client will know better what could be
> >> the maximum size for compressed data buffers. Change the driver
> >> to permit the user to set bigger size for the compressed buffer
> >> but make reasonable sanitation.
> >>
> >> Signed-off-by: Stanimir Varbanov
> >> ---
> >> drivers/media/platform/qcom/venus/vdec.c | 18 +-
> >> 1 file changed, 13 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/media/platform/qcom/venus/vdec.c
> >> b/drivers/media/platform/qcom/venus/vdec.c
> >> index 282de21cf2e1..7a9370df7515 100644
> >> --- a/drivers/media/platform/qcom/venus/vdec.c
> >> +++ b/drivers/media/platform/qcom/venus/vdec.c
> >> @@ -142,6 +142,7 @@ vdec_try_fmt_common(struct venus_inst *inst, struct
> >> v4l2_format *f)
> >> struct v4l2_pix_format_mplane *pixmp = >fmt.pix_mp;
> >> struct v4l2_plane_pix_format *pfmt = pixmp->plane_fmt;
> >> const struct venus_format *fmt;
> >> + u32 szimage;
> >>
> >> memset(pfmt[0].reserved, 0, sizeof(pfmt[0].reserved));
> >> memset(pixmp->reserved, 0, sizeof(pixmp->reserved));
> >> @@ -170,14 +171,18 @@ vdec_try_fmt_common(struct venus_inst *inst, struct
> >> v4l2_format *f)
> >> pixmp->num_planes = fmt->num_planes;
> >> pixmp->flags = 0;
> >>
> >> - pfmt[0].sizeimage = venus_helper_get_framesz(pixmp->pixelformat,
> >> -pixmp->width,
> >> -pixmp->height);
> >> + szimage = venus_helper_get_framesz(pixmp->pixelformat,
> >> pixmp->width,
> >> + pixmp->height);
> >>
> >> - if (f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
> >> + if (f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
> >> + pfmt[0].sizeimage = szimage;
> >> pfmt[0].bytesperline = ALIGN(pixmp->width, 128);
> >> - else
> >> + } else {
> >> + pfmt[0].sizeimage = clamp_t(u32, pfmt[0].sizeimage, 0,
> >> SZ_4M);
> >> + if (szimage > pfmt[0].sizeimage)
> >> + pfmt[0].sizeimage = szimage;
> >
> > pfmt[0].sizeimage = max(clamp_t(u32, pfmt[0].sizeimage, 0, SZ_4M),
> > szimage)?
>
> I'm not a big fan to that calling of macro from macro :)
>
> What about this:
>
> pfmt[0].sizeimage = clamp_t(u32, pfmt[0].sizeimage, 0, SZ_4M);
> pfmt[0].sizeimage = max(pfmt[0].sizeimage, szimage);
Looks fine, I just wanted to make sure that we use the more expressive
"max" instead of an if statement.
>
> >
> >> pfmt[0].bytesperline = 0;
> >> + }
> >>
> >> return fmt;
> >> }
> >> @@ -275,6 +280,7 @@ static int vdec_s_fmt(struct file *file, void *fh,
> >> struct v4l2_format *f)
> >> inst->ycbcr_enc = pixmp->ycbcr_enc;
> >> inst->quantization = pixmp->quantization;
> >> inst->xfer_func = pixmp->xfer_func;
> >> + inst->input_buf_size = pixmp->plane_fmt[0].sizeimage;
> >> }
> >>
> >> memset(, 0, sizeof(format));
> >> @@ -737,6 +743,8 @@ static int vdec_queue_setup(struct vb2_queue *q,
> >> sizes[0] = venus_helper_get_framesz(inst->fmt_out->pixfmt,
> >> inst->out_width,
> >> inst->out_height);
> >> + if (inst->input_buf_size > sizes[0])
> >> + sizes[0] = inst->input_buf_size;
> >
> >sizes[0] =
> > max(venus_helper_get_framesz(inst->fmt_out->pixfmt,
> >inst->out_width,
> > inst->out_height),
> > inst->input_buf_size)?
>
> I think it'd be more readable that way:
>
> sizes[0] = max(sizes[0], inst->input_buf_size);
Ditto.
Re: [PATCH 00/10] Venus stateful Codec API
On Thu, Jan 24, 2019 at 7:13 PM Stanimir Varbanov wrote: > > Hi Alex, > > Thank you for review and valuable comments! > > On 1/24/19 10:43 AM, Alexandre Courbot wrote: > > Hi Stanimir, > > > > On Fri, Jan 18, 2019 at 1:20 AM Stanimir Varbanov > > wrote: > >> > >> Hello, > >> > >> This aims to make Venus decoder compliant with stateful Codec API [1]. > >> The patches 1-9 are preparation for the cherry on the cake patch 10 > >> which implements the decoder state machine similar to the one in the > >> stateful codec API documentation. > > > > Thanks *a lot* for this series! I am still stress-testing it against > > the Chromium decoder tests, but so far it has been rock-solid. I have > > a few inline comments on some patches ; I will also want to review the > > state machine more thoroughly after refreshing my mind on Tomasz doc, > > but this looks pretty promising already. > > I'm expecting problems with ResetAfterFirstConfigInfo. I don't know why > but this test case is very dirty. I'd appreciate any help to decipher > what is the sequence of v4l2 calls made by this unittest case. I did not see any issue with ResetAfterFirstConfigInfo, however ResourceExhaustion seems to hang once in a while. But I could already see this behavior with the older patchset. In any case I plan to thoroughly review the state machine. I agree it is a bit complex to grasp.
Re: [PATCH 1/2] infiniband: remove unneeded header search paths
On 1/24/19 8:39 PM, Masahiro Yamada wrote: The included headers are located in include/target/. I was able to build these drivers without the extra header search paths. Signed-off-by: Masahiro Yamada --- drivers/infiniband/ulp/isert/Makefile | 1 - drivers/infiniband/ulp/srpt/Makefile | 1 - 2 files changed, 2 deletions(-) diff --git a/drivers/infiniband/ulp/isert/Makefile b/drivers/infiniband/ulp/isert/Makefile index c8bf242..a4a4766 100644 --- a/drivers/infiniband/ulp/isert/Makefile +++ b/drivers/infiniband/ulp/isert/Makefile @@ -1,2 +1 @@ -ccflags-y := -Idrivers/target -Idrivers/target/iscsi obj-$(CONFIG_INFINIBAND_ISERT)+= ib_isert.o diff --git a/drivers/infiniband/ulp/srpt/Makefile b/drivers/infiniband/ulp/srpt/Makefile index e3ee4bd..43fbde4 100644 --- a/drivers/infiniband/ulp/srpt/Makefile +++ b/drivers/infiniband/ulp/srpt/Makefile @@ -1,2 +1 @@ -ccflags-y := -Idrivers/target obj-$(CONFIG_INFINIBAND_SRPT) += ib_srpt.o Reviewed-by: Bart Van Assche
Re: Regression found (Stop-marking-clocks-as-CLK_IS_CRITICAL)
‐‐‐ Original Message ‐‐‐ On Tuesday, January 22, 2019 7:27 PM, Pierre-Louis Bossart wrote: > On 1/20/19 11:55 PM, Mogens Jensen wrote: > > > The only minor annoyance I'm experiencing now, is a large amount of debug > > output from something in kernel log when audio is played on the system: > > writing to lpe: : 01 01 01 01 00 00 08 00 ff ff ff ff 55 00 00 00 > > U... > > writing to lpe: : 01 01 01 01 00 00 1a 00 ff ff ff ff 75 00 12 00 > > u... > > ... > > That's enabled via dynamic debug so that's rather a configuration issue > than a kernel problem? Do you have any suggestions on how to disable it? My kernel is compiled without DYNAMIC_DEBUG, DEBUG_FS and other debug features, so I don't understand why all this debug output is flooding the kernel log. It's a minor issue, but it would be nice to get rid of it. Regards, Mogens Jensen
Re: [PATCH] of: Make of_node_name_eq() case insensitive
On 1/24/19 6:06 PM, Frank Rowand wrote:
> On 1/24/19 5:20 PM, Florian Fainelli wrote:
>>
>>
>> On 1/24/19 3:45 PM, Frank Rowand wrote:
>>> On 1/24/19 12:08 PM, Florian Fainelli wrote:
Since c32569e358ad ("regulator: Use of_node_name_eq for node name
comparisons") Vivien reported the mc13892-regulator complaining about
not being able to find regulators.
This is because prior to that commit we used of_node_cmp() to compare
the regulator array passed from mc13892_regulators down to
mc13xxx_parse_regulators_dt() and they are all defined in uppercase
letters by the MC13892_*_DEFINE* macros, whereas they are defined as
lowercase in the DTS.
Fix this by use strncasecmp() since that makes sure the comparison is
case insensitive like what of_node_cmp() did.
Reported-by: Vivien Didelot
Fixes: c32569e358ad ("regulator: Use of_node_name_eq for node name
comparisons")
Signed-off-by: Florian Fainelli
---
drivers/of/base.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 5226e898476e..ff47c86277cb 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -66,7 +66,8 @@ bool of_node_name_eq(const struct device_node *np, const
char *name)
node_name = kbasename(np->full_name);
len = strchrnul(node_name, '@') - node_name;
- return (strlen(name) == len) && (strncmp(node_name, name, len) == 0);
+ return (strlen(name) == len) &&
+ (strncasecmp(node_name, name, len) == 0);
}
EXPORT_SYMBOL(of_node_name_eq);
>>>
>>> Node names are case sensitive. Please fix mc13xxx_parse_regulators_dt() to
>>> properly handle case instead of changing of_node_name_eq().
>>
>> Fair enough, should we issue a warning if np->full_name contains upper
>> case while name does not (and vice versa) to help troubleshoot cases
>> like the one we found with Vivien?
>
> It seems like a lot of work to detect that specific case. If anything,
> maybe just add some text to the existing "Unknown regulator: ..." warning
> in mc13xxx_parse_regulators_dt() to mention that case matters.
I was not thinking about something very clever, just issue a warning
like this, completely untested and likely flawed:
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 5226e898476e..2505286c875b 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -58,6 +58,7 @@ DEFINE_RAW_SPINLOCK(devtree_lock);
bool of_node_name_eq(const struct device_node *np, const char *name)
{
const char *node_name;
+ int ret1, ret2;
size_t len;
if (!np)
@@ -66,7 +67,12 @@ bool of_node_name_eq(const struct device_node *np,
const char *name)
node_name = kbasename(np->full_name);
len = strchrnul(node_name, '@') - node_name;
- return (strlen(name) == len) && (strncmp(node_name, name, len)
== 0);
+ ret1 = strncmp(node_name, name, len);
+ ret2 = strncasecmp(node_name, len);
+
+ WARN(ret1 ^ ret2, "Comparing case sensitive names!");
+
+ return (strlen(name) == len && (strncmp(node_name, name, len) == 0);
}
EXPORT_SYMBOL(of_node_name_eq);
My concern is that we have identified one place here where the
conversion to of_node_name_eq() broke that particular driver in fact,
all other regulator drivers but qcom-rpmh-regulator.c that use
of_node_name_eq() are broken after that change, but presumably this is
not the only place in the kernel where things could break, so having a
warning could potentially help (also adding the backtrace which is neat).
What should the fix look like though? Add an of_node_casename_eq() and
use it, revert Rob's commit that changes these regulators to use
of_node_name_eq()?
I don't know the regulator framework enough to know whether forcibly
making the names lowercase is not breaking sysfs/debugfs...
--
Florian
Re: [PATCH 7/9] videobuf2/videobuf2-dma-sg.c: Convert to use vm_insert_range_buggy
Hi Marek,
On Tue, Jan 22, 2019 at 8:37 PM Marek Szyprowski
wrote:
>
> Hi Souptick,
>
> On 2019-01-11 16:11, Souptick Joarder wrote:
> > Convert to use vm_insert_range_buggy to map range of kernel memory
> > to user vma.
> >
> > This driver has ignored vm_pgoff. We could later "fix" these drivers
> > to behave according to the normal vm_pgoff offsetting simply by
> > removing the _buggy suffix on the function name and if that causes
> > regressions, it gives us an easy way to revert.
>
> Just a generic note about videobuf2: videobuf2-dma-sg is ignoring vm_pgoff by
> design. vm_pgoff is used as a 'cookie' to select a buffer to mmap and
> videobuf2-core already checks that. If userspace provides an offset, which
> doesn't match any of the registered 'cookies' (reported to userspace via
> separate v4l2 ioctl), an error is returned.
Ok, it means once the buf is selected, videobuf2-dma-sg should always
mapped buf->pages[i]
from index 0 ( irrespective of vm_pgoff value). So although we are
replacing the code with
vm_insert_range_buggy(), *_buggy* suffix will mislead others and
should not be used.
And if we replace this code with vm_insert_range(), this will
introduce bug for *non zero*
value of vm_pgoff.
Please correct me if my understanding is wrong.
So what your opinion about this patch ? Shall I drop this patch from
current series ?
or,
There is any better way to handle this scenario ?
>
> > There is an existing bug inside gem_mmap_obj(), where user passed
> > length is not checked against buf->num_pages. For any value of
> > length > buf->num_pages it will end up overrun buf->pages[i],
> > which could lead to a potential bug.
It is not gem_mmap_obj(), it should be vb2_dma_sg_mmap().
Sorry about it.
What about this issue ? Does it looks like a valid issue ?
> >
> > This has been addressed by passing buf->num_pages as input to
> > vm_insert_range_buggy() and inside this API error condition is
> > checked which will avoid overrun the page boundary.
> >
> > Signed-off-by: Souptick Joarder
> > ---
> > drivers/media/common/videobuf2/videobuf2-dma-sg.c | 22
> > ++
> > 1 file changed, 6 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> > b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> > index 015e737..ef046b4 100644
> > --- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> > +++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> > @@ -328,28 +328,18 @@ static unsigned int vb2_dma_sg_num_users(void
> > *buf_priv)
> > static int vb2_dma_sg_mmap(void *buf_priv, struct vm_area_struct *vma)
> > {
> > struct vb2_dma_sg_buf *buf = buf_priv;
> > - unsigned long uaddr = vma->vm_start;
> > - unsigned long usize = vma->vm_end - vma->vm_start;
> > - int i = 0;
> > + int err;
> >
> > if (!buf) {
> > printk(KERN_ERR "No memory to map\n");
> > return -EINVAL;
> > }
> >
> > - do {
> > - int ret;
> > -
> > - ret = vm_insert_page(vma, uaddr, buf->pages[i++]);
> > - if (ret) {
> > - printk(KERN_ERR "Remapping memory, error: %d\n", ret);
> > - return ret;
> > - }
> > -
> > - uaddr += PAGE_SIZE;
> > - usize -= PAGE_SIZE;
> > - } while (usize > 0);
> > -
> > + err = vm_insert_range_buggy(vma, buf->pages, buf->num_pages);
> > + if (err) {
> > + printk(KERN_ERR "Remapping memory, error: %d\n", err);
> > + return err;
> > + }
> >
> > /*
> >* Use common vm_area operations to track buffer refcount.
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R Institute Poland
>
Re: kernel panic due to https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2830bf6f05fb3e05bc4743274b806c821807a684
[ Just adding a lot of other people to the cc ] Robert, could you add a dmesg of a successful boot to that bugzilla, or just as an attachement in email to this group of people.. This looks to be with the Fedora kernel config. Two people reporting it, it looks like similar machines. I assume it's some odd memory sizing detail that happens to trigger a particular case. I absolutely *hate* those "let's lazily clear 'struct page' array" patches. They've caused problems before, and I'm not convinced the pain has been worth it. Maybe we should revert them (again) and promise to never ever take things like that again? Andrew? Linus On Fri, Jan 25, 2019 at 3:21 AM robert shteynfeld wrote: > > Hi, > > It looks like the above commit is causing an early kernel panic during boot > on my system starting with kernel 4.19.13. Here's the redhat bug regarding > this: https://bugzilla.redhat.com/show_bug.cgi?id=1666948. > > Cheers, > > Robert
test
test
[PATCH 2/2] infiniband: prefix header search paths with $(srctree)/
Currently, the Kbuild core manipulates header search paths in a crazy
way [1].
To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
the search paths in the srctree. Some Makefiles are already written in
that way, but not all. The goal of this work is to make the notation
consistent, and finally get rid of the gross hacks.
Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
("kbuild: do not drop -I without parameter").
[1]: https://patchwork.kernel.org/patch/9632347/
Signed-off-by: Masahiro Yamada
---
drivers/infiniband/hw/bnxt_re/Makefile | 2 +-
drivers/infiniband/hw/cxgb3/Makefile | 2 +-
drivers/infiniband/hw/cxgb4/Makefile | 4 ++--
drivers/infiniband/hw/hns/Makefile | 2 +-
drivers/infiniband/hw/i40iw/Makefile | 2 +-
drivers/infiniband/hw/ocrdma/Makefile | 2 +-
drivers/infiniband/hw/usnic/Makefile | 2 +-
7 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/infiniband/hw/bnxt_re/Makefile
b/drivers/infiniband/hw/bnxt_re/Makefile
index 6e3bc25..ee9bb1b 100644
--- a/drivers/infiniband/hw/bnxt_re/Makefile
+++ b/drivers/infiniband/hw/bnxt_re/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
-ccflags-y := -Idrivers/net/ethernet/broadcom/bnxt
+ccflags-y := -I $(srctree)/drivers/net/ethernet/broadcom/bnxt
obj-$(CONFIG_INFINIBAND_BNXT_RE) += bnxt_re.o
bnxt_re-y := main.o ib_verbs.o \
qplib_res.o qplib_rcfw.o \
diff --git a/drivers/infiniband/hw/cxgb3/Makefile
b/drivers/infiniband/hw/cxgb3/Makefile
index 66fe091..34bb86a 100644
--- a/drivers/infiniband/hw/cxgb3/Makefile
+++ b/drivers/infiniband/hw/cxgb3/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
-ccflags-y := -Idrivers/net/ethernet/chelsio/cxgb3
+ccflags-y := -I $(srctree)/drivers/net/ethernet/chelsio/cxgb3
obj-$(CONFIG_INFINIBAND_CXGB3) += iw_cxgb3.o
diff --git a/drivers/infiniband/hw/cxgb4/Makefile
b/drivers/infiniband/hw/cxgb4/Makefile
index 9edd920..31a87d9 100644
--- a/drivers/infiniband/hw/cxgb4/Makefile
+++ b/drivers/infiniband/hw/cxgb4/Makefile
@@ -1,5 +1,5 @@
-ccflags-y := -Idrivers/net/ethernet/chelsio/cxgb4
-ccflags-y += -Idrivers/net/ethernet/chelsio/libcxgb
+ccflags-y := -I $(srctree)/drivers/net/ethernet/chelsio/cxgb4
+ccflags-y += -I $(srctree)/drivers/net/ethernet/chelsio/libcxgb
obj-$(CONFIG_INFINIBAND_CXGB4) += iw_cxgb4.o
diff --git a/drivers/infiniband/hw/hns/Makefile
b/drivers/infiniband/hw/hns/Makefile
index 004c88b..e2a7f14 100644
--- a/drivers/infiniband/hw/hns/Makefile
+++ b/drivers/infiniband/hw/hns/Makefile
@@ -2,7 +2,7 @@
# Makefile for the Hisilicon RoCE drivers.
#
-ccflags-y := -Idrivers/net/ethernet/hisilicon/hns3
+ccflags-y := -I $(srctree)/drivers/net/ethernet/hisilicon/hns3
obj-$(CONFIG_INFINIBAND_HNS) += hns-roce.o
hns-roce-objs := hns_roce_main.o hns_roce_cmd.o hns_roce_pd.o \
diff --git a/drivers/infiniband/hw/i40iw/Makefile
b/drivers/infiniband/hw/i40iw/Makefile
index 5a8a7a3..8942f82 100644
--- a/drivers/infiniband/hw/i40iw/Makefile
+++ b/drivers/infiniband/hw/i40iw/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
-ccflags-y := -Idrivers/net/ethernet/intel/i40e
+ccflags-y := -I $(srctree)/drivers/net/ethernet/intel/i40e
obj-$(CONFIG_INFINIBAND_I40IW) += i40iw.o
diff --git a/drivers/infiniband/hw/ocrdma/Makefile
b/drivers/infiniband/hw/ocrdma/Makefile
index d1bfd4f..e3f20ca 100644
--- a/drivers/infiniband/hw/ocrdma/Makefile
+++ b/drivers/infiniband/hw/ocrdma/Makefile
@@ -1,4 +1,4 @@
-ccflags-y := -Idrivers/net/ethernet/emulex/benet
+ccflags-y := -I $(srctree)/drivers/net/ethernet/emulex/benet
obj-$(CONFIG_INFINIBAND_OCRDMA)+= ocrdma.o
diff --git a/drivers/infiniband/hw/usnic/Makefile
b/drivers/infiniband/hw/usnic/Makefile
index 94ae7a1..f12a493 100644
--- a/drivers/infiniband/hw/usnic/Makefile
+++ b/drivers/infiniband/hw/usnic/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
-ccflags-y := -Idrivers/net/ethernet/cisco/enic
+ccflags-y := -I $(srctree)/drivers/net/ethernet/cisco/enic
obj-$(CONFIG_INFINIBAND_USNIC)+= usnic_verbs.o
--
2.7.4
