Re: [PATCH] mtd: spi-nor: parse SFDP 4-byte Address Instruction Table
On Tue, 20 Nov 2018 11:55:21 + wrote: > + > + /* > + * We set nor->addr_width here to skip spi_nor_set_4byte_opcodes() > + * later because this latest function implements a legacy quirk for > + * the erase size of Spansion memory. However this quirk is no longer > + * needed with new SFDP compliant memories. > + */ > + nor->addr_width = 4; > + nor->flags |= SPI_NOR_4B_OPCODES; You mean SNOR_F_4B_OPCODES (the one introduced here [1]), because SPI_NOR_4B_OPCODES should only be used for flash_info->flags and might soon conflict with another SNOR_F_ flag? [1]http://patchwork.ozlabs.org/patch/991476/
Re: [PATCH v5 2/7] tpm: remove definition of TPM2_ACTIVE_PCR_BANKS
On 11/16/2018 2:38 PM, Jarkko Sakkinen wrote:
On Wed, Nov 14, 2018 at 04:31:03PM +0100, Roberto Sassu wrote:
tcg_efi_specid_event and tcg_pcr_event2 declaration contains static arrays
for a list of hash algorithms used for event logs and event log digests.
However, according to TCG EFI Protocol Specification, these arrays have
variable sizes. Setting the array size to zero or 3 does not make any
difference, because the parser has to adjust the offset depending on the
actual array size to access structure members after the static arrays.
Thus, this patch removes the declaration of TPM2_ACTIVE_PCR_BANKS and sets
the array size to zero.
Fixes: 4d23cc323cdb ("tpm: add securityfs support for TPM 2.0 firmware
event log")
Signed-off-by: Roberto Sassu
---
include/linux/tpm_eventlog.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/include/linux/tpm_eventlog.h b/include/linux/tpm_eventlog.h
index 20d9da77fc11..3d5d162f09cc 100644
--- a/include/linux/tpm_eventlog.h
+++ b/include/linux/tpm_eventlog.h
@@ -8,7 +8,6 @@
#define TCG_EVENT_NAME_LEN_MAX255
#define MAX_TEXT_EVENT1000/* Max event string length */
#define ACPI_TCPA_SIG "TCPA"/* 0x41504354 /'TCPA' */
-#define TPM2_ACTIVE_PCR_BANKS 3
#define EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2 0x1
#define EFI_TCG2_EVENT_LOG_FORMAT_TCG_2 0x2
@@ -90,7 +89,7 @@ struct tcg_efi_specid_event {
u8 spec_errata;
u8 uintnsize;
u32 num_algs;
- struct tcg_efi_specid_event_algs digest_sizes[TPM2_ACTIVE_PCR_BANKS];
+ struct tcg_efi_specid_event_algs digest_sizes[0];
u8 vendor_info_size;
u8 vendor_info[0];
} __packed;
@@ -117,7 +116,7 @@ struct tcg_pcr_event2 {
u32 pcr_idx;
u32 event_type;
u32 count;
- struct tpm2_digest digests[TPM2_ACTIVE_PCR_BANKS];
+ struct tpm2_digest digests[0];
struct tcg_event_field event;
} __packed;
--
2.17.1
NAK for the same reason as last time.
No Fixes tag, or Fixes tag without newline?
Roberto
/Jarkko
--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Jian LI, Yanli SHI
[PATCH v3] spi: mediatek: Add bindings for mediatek MT7629 soc platform
This patch adds a DT binding documentation for the MT7629 soc. Signed-off-by: Leilk Liu --- v3: remove cover-letter. v2: remove "mediatek,mt7629-spi" compatible according Matthias's advice. v1: This series are based on 4.20-rc1 and provide two patches to support mt7629 IC. --- .../devicetree/bindings/spi/spi-mt65xx.txt |1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt index 7940940..69c3567 100644 --- a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt +++ b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt @@ -6,6 +6,7 @@ Required properties: - mediatek,mt2712-spi: for mt2712 platforms - mediatek,mt6589-spi: for mt6589 platforms - mediatek,mt7622-spi: for mt7622 platforms +- "mediatek,mt7629-spi", "mediatek,mt7622-spi": for mt7629 platforms - mediatek,mt8135-spi: for mt8135 platforms - mediatek,mt8173-spi: for mt8173 platforms - mediatek,mt8183-spi: for mt8183 platforms -- 1.7.9.5
Re: [PATCH v2 00/12] tracing: Unifying dynamic event interface
Ping? Hi Tom, This series, especially [09/12] tracing: Remove unneeded synth_event_mutex will effect your current working series. Please tell me your opinion. Thank you, On Mon, 5 Nov 2018 17:59:46 +0900 Masami Hiramatsu wrote: > Hi, > > This is v2 series of unifying dynamic event interface on ftrace. > Currently ftrace has 3 dynamic event interfaces, kprobes, uprobes > and synthetic. This series unifies those dynamic event interfaces > to "dynamic_events" so that we can add other dynamic events easily > on same interface, e.g. function events. > The older interfaces are left on the tracefs for backward > compatibility. > > dynamic_events syntax has no difference from kprobe_events and > uprobe_events. You can use same syntax for dynamic_events interface. > For synthetic events, similar to the probe events, dynamic_events > adds "s:[GROUP/]" prefix, where the "GROUP/" must be "synthetic/". > > s:[synthetic/] type arg [type arg]... > > E.g. > > $ echo 'wakeup_latency u64 lat pid_t pid char' > synthetic_events > > is same as > > $ echo 's:wakeup_latency u64 lat pid_t pid char' > dynamic_events > > Or > > $ echo 's:synthetic/wakeup_latency u64 lat pid_t pid char' > dynamic_events > > This series modifies synthetic event interface behavior a bit, > reorder lock dependency and related cleanups so that we can integrate > the synthetic event to dynamic_events interface. > > In this version, I changed the generic '!' erase command, which > now supports entire line style like other interfaces. So you can > delete events via dynamic_events as below > > $ cat dynamic_events | while read line; \ >do echo "!$line" >> dynamic_events; done > > Also, the big change will be removing dyn_event_mutex and > synth_event_mutex because all those parts are protected by > event_mutex. > > Changes from v2 are here; > > New patches: > - Reorder event_mutex and synth_event_mutex to solve >AB-BA deadlock correctly. ([2/12]) > - Simplify creation and deletion of synthetic event. ([3/12]) > - Retern -ENOENT if there is no synthetic event when deleting ([4/12]) > - Integrate similar probe argument parsers ([5/12]) > - Use dyn_event framework for synthetic events ([9/12]) > - Remove synth_event_mutex ([10/12]) > - Remove unused APIs ([11/12]) > > Modified patches: > [6/12] - [8/12] > - Generalize delete event and export as dyn_event_release_all(). > - Add match operation for find deleting event. > - Reorder event_mutex and dyn_event_mutex to solve lock dependency >issue. > - Pass const char **argv for create operation and use -ECANCELED to >signal for trying next dyn_event_operations. > - Remove dyn_event_mutex. > > [12/12] > - Accept entire line, but instead of checking the given entire line >strictly, simply checking the event and group name. > > Tom, thanks for your Ack for v1 series. Since I changed many things > from v1 (not only minor change), I decided to not add your Ack for > this version. Anyway, what I've added in this version are related to > synthetic events. I need your review for those. > (especially removing synth_event_mutex) > > You can try it from my git tree. > > https://github.com/mhiramat/linux/tree/unify-dynamic-events-v2 > > Thank you, > > --- > > Masami Hiramatsu (12): > tracing/uprobes: Add busy check when cleanup all uprobes > tracing: Lock event_mutex before synth_event_mutex > tracing: Simplify creation and deletion of synthetic event > tracing: Integrate similar probe argument parsers > tracing: Add unified dynamic event framework > tracing/kprobes: Use dyn_event framework for kprobe events > tracing/uprobes: Use dyn_event framework for uprobe events > tracing: Use dyn_event framework for synthetic events > tracing: Remove unneeded synth_event_mutex > tracing: Remove orphaned trace_add/remove_event_call functions > tracing: Add generic event-name based remove event method > selftests/ftrace: Add testcases for dynamic event > > > Documentation/trace/kprobetrace.rst|3 > Documentation/trace/uprobetracer.rst |4 > include/linux/trace_events.h |4 > kernel/trace/Kconfig |6 > kernel/trace/Makefile |1 > kernel/trace/trace.c | 12 + > kernel/trace/trace_dynevent.c | 217 > kernel/trace/trace_dynevent.h | 119 +++ > kernel/trace/trace_events.c| 12 - > kernel/trace/trace_events_hist.c | 322 ++ > kernel/trace/trace_kprobe.c| 357 > ++-- > kernel/trace/trace_probe.c | 74 > kernel/trace/trace_probe.h |9 - > kernel/trace/trace_uprobe.c| 305 - > .
[PATCH v2] lzo: fix ip overrun during compress.
It`s possible ip overrun in lzo1x_1_do_compress() when compressed page is point to the end of memory and which virtual address is 0xf000. Leading to a NULL pointer access during the get_unaligned_le32(ip). Fix this panic: [ 2738.034508] Unable to handle kernel NULL pointer dereference at virtual address 0009 [ 2738.034515] Mem abort info: [ 2738.034518] Exception class = DABT (current EL), IL = 32 bits [ 2738.034520] SET = 0, FnV = 0 [ 2738.034523] EA = 0, S1PTW = 0 [ 2738.034524] FSC = 5 [ 2738.034526] Data abort info: [ 2738.034528] ISV = 0, ISS = 0x0005 [ 2738.034530] CM = 0, WnR = 0 [ 2738.034533] user pgtable: 4k pages, 39-bit VAs, pgd = 94cee000 [ 2738.034535] [0009] *pgd=, *pud= ... [ 2738.034592] pc : lzo1x_1_do_compress+0x198/0x610 [ 2738.034595] lr : lzo1x_1_compress+0x98/0x3d8 [ 2738.034597] sp : ff801caa3470 pstate : 00c00145 [ 2738.034598] x29: ff801caa3500 x28: 1000 [ 2738.034601] x27: 1000 x26: f000 [ 2738.034604] x25: 4ebc x24: [ 2738.034607] x23: 004c x22: f7b8 [ 2738.034610] x21: 2e2ee0b3 x20: 2e2ee0bb [ 2738.034612] x19: 0fcc x18: f84a [ 2738.034615] x17: 801b03d6 x16: 0782 [ 2738.034618] x15: 2e2ee0bf x14: fff0 [ 2738.034620] x13: 000f x12: 0020 [ 2738.034623] x11: 1824429d x10: ffec [ 2738.034626] x9 : 0009 x8 : [ 2738.034628] x7 : 0868 x6 : 0434 [ 2738.034631] x5 : 4ebc x4 : [ 2738.034633] x3 : ff801caa3510 x2 : 2e2ee000 [ 2738.034636] x1 : x0 : f000 ... [ 2738.034717] Process kworker/u16:1 (pid: 8705, stack limit = 0xff801caa) [ 2738.034720] Call trace: [ 2738.034722] lzo1x_1_do_compress+0x198/0x610 [ 2738.034725] lzo_compress+0x48/0x88 [ 2738.034729] crypto_compress+0x14/0x20 [ 2738.034733] zcomp_compress+0x2c/0x38 [ 2738.034736] zram_bvec_rw+0x3d0/0x860 [ 2738.034738] zram_rw_page+0x88/0xe0 [ 2738.034742] bdev_write_page+0x70/0xc0 [ 2738.034745] __swap_writepage+0x58/0x3f8 [ 2738.034747] swap_writepage+0x40/0x50 [ 2738.034750] shrink_page_list+0x4fc/0xe58 [ 2738.034753] reclaim_pages_from_list+0xa0/0x150 [ 2738.034756] reclaim_pte_range+0x18c/0x1f8 [ 2738.034759] __walk_page_range+0xf8/0x1e0 [ 2738.034762] walk_page_range+0xf8/0x130 [ 2738.034765] reclaim_task_anon+0xcc/0x168 [ 2738.034767] swap_fn+0x438/0x668 [ 2738.034771] process_one_work+0x1fc/0x460 [ 2738.034773] worker_thread+0x2d0/0x478 [ 2738.034775] kthread+0x110/0x120 [ 2738.034778] ret_from_fork+0x10/0x18 [ 2738.034781] Code: 3800167f 54a8 d100066f 1431 (b9400131) [ 2738.034784] ---[ end trace 9b5cca106f0e54d1 ]--- [ 2738.035473] Kernel panic - not syncing: Fatal exception crash> dis lzo1x_1_do_compress+100 3 -l ../kernel/msm-4.14/lib/lzo/lzo1x_compress.c: 44 0xff8dec8c6af4 : cmp x9, x10 0xff8dec8c6af8 : b.cc0xff8dec8c6c28 0xff8dec8c6afc : b 0xff8dec8c7094 crash> dis lzo1x_1_do_compress+0x198 0xff8dec8c6c28 : ldr w17, [x9] ip = x9 = 0x0009 is overflow. Signed-off-by: liyueyi --- lib/lzo/lzo1x_compress.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/lib/lzo/lzo1x_compress.c b/lib/lzo/lzo1x_compress.c index 236eb21..b15082b 100644 --- a/lib/lzo/lzo1x_compress.c +++ b/lib/lzo/lzo1x_compress.c @@ -17,6 +17,9 @@ #include #include "lzodefs.h" +#define OVERFLOW_ADD_CHECK(a, b) \ + (((a) + (b)) < (a)) + static noinline size_t lzo1x_1_do_compress(const unsigned char *in, size_t in_len, unsigned char *out, size_t *out_len, @@ -39,6 +42,8 @@ lzo1x_1_do_compress(const unsigned char *in, size_t in_len, size_t t, m_len, m_off; u32 dv; literal: + if (unlikely(OVERFLOW_ADD_CHECK(ip, 1 + ((ip - ii) >> 5 + break; ip += 1 + ((ip - ii) >> 5); next: if (unlikely(ip >= ip_end)) @@ -99,7 +104,8 @@ lzo1x_1_do_compress(const unsigned char *in, size_t in_len, m_len += 8; v = get_unaligned((const u64 *) (ip + m_len)) ^ get_unaligned((const u64 *) (m_pos + m_len)); - if (unlikely(ip + m_len >= ip_end)) + if (unlikely(OVERFLOW_ADD_CHECK(ip, m_len) + || (ip + m_len >= ip_end))) goto m_len_done; } while (v == 0); } @@ -124,7 +130,8 @@ lzo1x_1_do_compress(const unsigned char *in, size_t in_len, m_len += 4;
[PATCH] sound/soc/rockchip: add RT5640 codec option
The Firefly-RK3399 DeviceTree (`arch/arm64/boot/dts/rockchip/rk3399-firefly.dts`) defines a `simple-audio-card` device which selects a `realtek,rt5640` codec. This codec however is inaccessible in the kernel configuration (`SND_SOC_RT5640`) and thus cannot be used. This patch adds a new configuration option named `SND_SOC_ROCKCHIP_RT5640` which selects `SND_SOC_RT5640` and `SND_SIMPLE_CARD`, but does nothing else. It enables `SND_SIMPLE_CARD`, because that's what the Firefly has. I'm not sure if there are Rockchip products which need a different sound card driver with RT5640. Signed-off-by: Max Kellermann --- sound/soc/rockchip/Kconfig | 10 ++ 1 file changed, 10 insertions(+) diff --git a/sound/soc/rockchip/Kconfig b/sound/soc/rockchip/Kconfig index 957046ac6c8c..ac2e27043107 100644 --- a/sound/soc/rockchip/Kconfig +++ b/sound/soc/rockchip/Kconfig @@ -42,6 +42,16 @@ config SND_SOC_ROCKCHIP_MAX98090 Say Y or M here if you want to add support for SoC audio on Rockchip boards using the MAX98090 codec, such as Veyron. +config SND_SOC_ROCKCHIP_RT5640 + tristate "ASoC support for Rockchip boards using a RT5640 codec" + depends on SND_SOC_ROCKCHIP + select SND_SOC_ROCKCHIP_I2S + select SND_SOC_RT5640 + select SND_SIMPLE_CARD + help + Say Y or M here if you want to add support for SoC audio on Rockchip + boards using the RT5640 codec, such as Firefly-RK3399. + config SND_SOC_ROCKCHIP_RT5645 tristate "ASoC support for Rockchip boards using a RT5645/RT5650 codec" depends on SND_SOC_ROCKCHIP && I2C && GPIOLIB && CLKDEV_LOOKUP -- 2.19.2
[PATCH v3 1/3] perf annotate: Compute average IPC and IPC coverage per symbol
Add support to perf report annotate view or perf annotate --stdio2 to
aggregate the IPC derived from timed LBRs per symbol. We compute the
average IPC and the IPC coverage percentage.
For example,
$ perf annotate --stdio2
Percent IPC Cycle (Average IPC: 2.30, IPC Coverage: 54.8%)
Disassembly of section .text:
0003aac0 :
8.32 3.28 sub$0x18,%rsp
3.28 mov$0x1,%esi
3.28 xor%eax,%eax
3.28 cmpl
$0x0,argp_program_version_hook@@GLIBC_2.2.5+0x1e0
11.57 3.28 1 ↓ je 20
lock cmpxchg %esi,__abort_msg@@GLIBC_PRIVATE+0x8a0
↓ jne29
↓ jmp43
11.57 1.1020: cmpxchg %esi,__abort_msg@@GLIBC_PRIVATE+0x8a0
0.00 1.10 1 ↓ je 43
29: lea__abort_msg@@GLIBC_PRIVATE+0x8a0,%rdi
sub$0x80,%rsp
→ callq __lll_lock_wait_private
add$0x80,%rsp
0.00 3.0043: lea__ctype_b@GLIBC_2.2.5+0x38,%rdi
3.00 lea0xc(%rsp),%rsi
8.49 3.00 1 → callq __random_r
7.91 1.94 cmpl
$0x0,argp_program_version_hook@@GLIBC_2.2.5+0x1e0
0.00 1.94 1 ↓ je 68
lock decl __abort_msg@@GLIBC_PRIVATE+0x8a0
↓ jne70
↓ jmp8a
0.00 2.0068: decl __abort_msg@@GLIBC_PRIVATE+0x8a0
21.56 2.00 1 ↓ je 8a
70: lea__abort_msg@@GLIBC_PRIVATE+0x8a0,%rdi
sub$0x80,%rsp
→ callq __lll_unlock_wake_private
add$0x80,%rsp
21.56 2.908a: movslq 0xc(%rsp),%rax
2.90 add$0x18,%rsp
9.03 2.90 1 ← retq
It shows for this symbol the average IPC is 2.30 and the IPC coverage
is 54.8%.
Signed-off-by: Jin Yao
---
tools/perf/util/annotate.c | 41 ++---
tools/perf/util/annotate.h | 5 +
2 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 6936daf..4b2b1b0 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -1000,6 +1000,7 @@ static unsigned annotation__count_insn(struct annotation
*notes, u64 start, u64
static void annotation__count_and_fill(struct annotation *notes, u64 start,
u64 end, struct cyc_hist *ch)
{
unsigned n_insn;
+ unsigned int cover_insn = 0;
u64 offset;
n_insn = annotation__count_insn(notes, start, end);
@@ -1013,21 +1014,34 @@ static void annotation__count_and_fill(struct
annotation *notes, u64 start, u64
for (offset = start; offset <= end; offset++) {
struct annotation_line *al = notes->offsets[offset];
- if (al)
+ if (al && al->ipc == 0.0) {
al->ipc = ipc;
+ cover_insn++;
+ }
+ }
+
+ if (cover_insn) {
+ notes->hit_cycles += ch->cycles;
+ notes->hit_insn += n_insn * ch->num;
+ notes->cover_insn += cover_insn;
}
}
}
void annotation__compute_ipc(struct annotation *notes, size_t size)
{
- u64 offset;
+ s64 offset;
if (!notes->src || !notes->src->cycles_hist)
return;
+ notes->total_insn = annotation__count_insn(notes, 0, size - 1);
+ notes->hit_cycles = 0;
+ notes->hit_insn = 0;
+ notes->cover_insn = 0;
+
pthread_mutex_lock(¬es->lock);
- for (offset = 0; offset < size; ++offset) {
+ for (offset = size - 1; offset >= 0; --offset) {
struct cyc_hist *ch;
ch = ¬es->src->cycles_hist[offset];
@@ -2563,6 +2577,22 @@ static void disasm_line__write(struct disasm_line *dl,
struct annotation *notes,
disasm_line__scnprintf(dl, bf, size, !notes->options->use_offset);
}
+static void ipc_coverage_string(char *bf, int size, struct annotation *notes)
+{
+ double ipc = 0.0, coverage = 0.0;
+
+ if (notes->hit_cycles)
+ ipc = notes->hit_insn / ((double)notes->hit_cycles);
+
+ if (notes->total_insn) {
+ coverage = notes->cover_insn * 100.0 /
+ ((double)notes->total_insn);
+ }
+
+ scnprintf(bf, size, "(Average IPC: %.2f, IPC Coverage: %.1f%%)",
+ ipc, coverage);
+}
+
static void __annotation_line__write(struct annotation_line *al, struct
annotation *notes,
bool first_line, bool current_entry, bool
change_color, int width,
voi
[PATCH v3 3/3] perf report: Display average IPC and IPC coverage per symbol
Support displaying the average IPC and IPC coverage per symbol
in perf report TUI and stdio modes.
For example,
$ perf record -b ...
$ perf report -s symbol
Overhead Symbol IPC [IPC Coverage]
39.60% [.] __random 2.30 [ 54.8%]
18.02% [.] main 0.43 [ 54.3%]
14.21% [.] compute_flag 2.29 [100.0%]
14.16% [.] rand 0.36 [100.0%]
7.06% [.] __random_r 2.57 [ 70.5%]
6.85% [.] rand@plt 0.00 [ 0.0%]
Jiri Olsa provides the patch to support the
stdio mode. I merge Jiri's code in this patch.
$ perf report -s symbol --stdio
# Overhead Symbol IPC [IPC Coverage]
# ...
#
39.60% [.] __random 2.30 [ 54.8%]
18.02% [.] main 0.43 [ 54.3%]
14.21% [.] compute_flag 2.29 [100.0%]
14.16% [.] rand 0.36 [100.0%]
7.06% [.] __random_r 2.57 [ 70.5%]
6.85% [.] rand@plt 0.00 [ 0.0%]
0.02% [k] run_timer_softirq 1.60 [ 57.2%]
The columns "IPC" and "[IPC Coverage]" are automatically enabled
when the sort-key "symbol" is specified. If the perf.data doesn't
contain timed LBR information, columns are filled with "-".
For example,
# Overhead Symbol IPC [IPC Coverage]
# ...
#
46.57% [.] main - -
17.60% [.] rand - -
15.84% [.] __random_r - -
11.90% [.] __random - -
6.50% [.] compute_flag - -
1.59% [.] rand@plt - -
0.00% [.] _dl_relocate_object - -
0.00% [k] tlb_flush_mmu- -
0.00% [k] perf_event_mmap - -
0.00% [k] native_sched_clock - -
0.00% [k] intel_pmu_handle_irq_v4 - -
0.00% [k] native_write_msr - -
v3:
---
Removed the sortkey 'ipc' from command-line. The columns "IPC"
and "[IPC Coverage]" are automatically enabled when "symbol"
is specified.
v2:
---
Merge in Jiri's patch to support stdio mode
Signed-off-by: Jin Yao
---
tools/perf/builtin-report.c | 26 ---
tools/perf/util/hist.h | 1 +
tools/perf/util/sort.c | 61 +
tools/perf/util/sort.h | 2 ++
4 files changed, 87 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 257c9c1..4958095 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -85,6 +85,7 @@ struct report {
int socket_filter;
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
struct branch_type_stat brtype_stat;
+ boolsymbol_ipc;
};
static int report__config(const char *var, const char *value, void *cb)
@@ -129,7 +130,7 @@ static int hist_iter__report_callback(struct
hist_entry_iter *iter,
struct mem_info *mi;
struct branch_info *bi;
- if (!ui__has_annotation())
+ if (!ui__has_annotation() && !rep->symbol_ipc)
return 0;
hist__account_cycles(sample->branch_stack, al, sample,
@@ -174,7 +175,7 @@ static int hist_iter__branch_callback(struct
hist_entry_iter *iter,
struct perf_evsel *evsel = iter->evsel;
int err;
- if (!ui__has_annotation())
+ if (!ui__has_annotation() && !rep->symbol_ipc)
return 0;
hist__account_cycles(sample->branch_stack, al, sample,
@@ -1133,6 +1134,7 @@ int cmd_report(int argc, const char **argv)
.mode = PERF_DATA_MODE_READ,
};
int ret = hists__init();
+ char sort_tmp[128];
if (ret < 0)
return ret;
@@ -1284,6 +1286,24 @@ int cmd_report(int argc, const char **argv)
else
use_browser = 0;
+ if (sort_order && strstr(sort_order, "ipc")) {
+ parse_options_usage(report_usage, options, "s", 1);
+ goto error;
+ }
+
+ if (sort_order && strstr(sort_order, "symbol")) {
+ if (sort__mode == SORT_MODE__BRANCH) {
+ snprintf(sort_tmp, sizeof(sort_tmp), "%s,%s",
+sort_order, "ipc_lbr");
+ report.symbol_ipc = true;
+ } else {
+ snprintf(sort_tmp, sizeof(sort_tmp), "%s,%s",
+sort_order, "ipc_null");
+ }
+
+ sort_order = sort_tmp;
+ }
+
if (setup_sorting(session->evlist) < 0) {
if (sort_order)
parse_options_usage(report_usage, options
[PATCH v3 2/3] perf annotate: Create a annotate2 flag in struct symbol
We often use the symbol__annotate2() to annotate a specified symbol.
While annotating may take some time, so in order to avoid annotating
the same symbol repeatedly, the patch creates a new flag to indicate
the symbol has been annotated.
Signed-off-by: Jin Yao
---
tools/perf/util/annotate.c | 1 +
tools/perf/util/symbol.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 4b2b1b0..f69d8e1 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -2798,6 +2798,7 @@ int symbol__annotate2(struct symbol *sym, struct map
*map, struct perf_evsel *ev
notes->nr_events = nr_pcnt;
annotation__update_column_widths(notes);
+ sym->annotate2 = true;
return 0;
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index d026d21..14d9d43 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -63,6 +63,7 @@ struct symbol {
u8 ignore:1;
u8 inlined:1;
u8 arch_sym;
+ boolannotate2;
charname[0];
};
--
2.7.4
[PATCH v3 0/3] perf report/annotate: Support average IPC and IPC coverage for function
Add supporting of displaying the average IPC and IPC coverage
percentage per function.
For example,
$ perf record -b ...
$ perf report -s symbol or
perf report -s symbol --stdio
Overhead Symbol IPC [IPC Coverage]
39.60% [.] __random 2.30 [ 54.8%]
18.02% [.] main 0.43 [ 54.3%]
14.21% [.] compute_flag 2.29 [100.0%]
14.16% [.] rand 0.36 [100.0%]
7.06% [.] __random_r 2.57 [ 70.5%]
6.85% [.] rand@plt 0.00 [ 0.0%]
...
$ perf annotate --stdio2
Percent IPC Cycle (Average IPC: 2.30, IPC Coverage: 54.8%)
Disassembly of section .text:
0003aac0 :
8.32 3.28 sub$0x18,%rsp
3.28 mov$0x1,%esi
3.28 xor%eax,%eax
3.28 cmpl
$0x0,argp_program_version_hook@@GLIBC_2.2.5+0x1e0
11.57 3.28 1 ↓ je 20
lock cmpxchg %esi,__abort_msg@@GLIBC_PRIVATE+0x8a0
↓ jne29
↓ jmp43
11.57 1.1020: cmpxchg %esi,__abort_msg@@GLIBC_PRIVATE+0x8a0
...
v3:
---
Remove the sortkey "ipc" from command-line. The columns "IPC"
and "[IPC Coverage]" are automatically enabled when "symbol"
is specified.
Patch "perf report: Display average IPC and IPC coverage per symbol"
is impacted.
v2:
---
1. Merge in Jiri's patch to support stdio mode
2. Add a new patch "perf annotate: Create a annotate2 flag
in struct symbol" which records if the symbol has been
annotated yet.
3. Minor update such as adding { } for multiline code in 'if'
condition.
Jin Yao (3):
perf annotate: Compute average IPC and IPC coverage per symbol
perf annotate: Create a annotate2 flag in struct symbol
perf report: Display average IPC and IPC coverage per symbol
tools/perf/builtin-report.c | 26 ---
tools/perf/util/annotate.c | 42 ---
tools/perf/util/annotate.h | 5
tools/perf/util/hist.h | 1 +
tools/perf/util/sort.c | 61 +
tools/perf/util/sort.h | 2 ++
tools/perf/util/symbol.h| 1 +
7 files changed, 132 insertions(+), 6 deletions(-)
--
2.7.4
Re: [PATCH] sis5513: fix potential use after free
On Wed, Nov 28, 2018 at 08:55:26AM +0800, Pan Bian wrote: > The function sis_find_family drops lpc_bridge reference via pci_dev_put, > however, after that, field lpc_bridge->revision is read. This may result > in a use after free bug. The patch moves the put operation after the > condition check. > > Signed-off-by: Pan Bian Looks good, Reviewed-by: Christoph Hellwig
Re: [PATCH] ata: read ->revision before dropping pci_device reference
Looks good, Reviewed-by: Christoph Hellwig
Re: [PATCH] Little memset_explicit optimisation
On Wed, Nov 28, 2018 at 06:32:27AM +, David CARLIER wrote: > Bad entrance with bad idea I m afraid :-) sorry for the noise. We all start somewhere, no worries :) -- Cheers, Joey Pabalinas signature.asc Description: PGP signature
Re: [PATCH] arm64: dts: qcom: sdm845-mtp: Mark protected gcc clocks
Quoting Bjorn Andersson (2018-11-21 23:30:43) > On Wed 21 Nov 01:01 PST 2018, Stephen Boyd wrote: > > > Quoting Bjorn Andersson (2018-11-05 21:50:13) > > > As of v4.20-rc1 probing the GCC driver on a SDM845 device with the > > > standard security implementation causes an access violation and an > > > immediate system restart. Use the protected-clocks property to mark the > > > offending clocks protected for the MTP, in order to allow it to boot. > > > > > > Cc: Stephen Boyd > > > Signed-off-by: Bjorn Andersson > > > --- > > > > > > This depends on the acceptance of > > > https://lore.kernel.org/lkml/20181105194011.43770-1-swb...@chromium.org/ > > > > Do you need me to merge this into clk-fixes so that Andy can send this > > up for v4.20 final? I thought you may have other boot blocking issues so > > this wouldn't be a critical fix. > > > > We resolved the gpio-related issues, so iirc this is the only other item > preventing the MTP from booting. So yes please. > > Unless you enable USB support, because configuring the first USB > controller in host currently crashes the device - I've not yet found the > cause for this though. > Ok let me do the necessary shuffling to get this all lined up for merging later this week, including this dts patch.
Re: [PATCH] Little memset_explicit optimisation
Bad entrance with bad idea I m afraid :-) sorry for the noise.
Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression
On Tue 27-11-18 14:50:05, Linus Torvalds wrote: > On Tue, Nov 27, 2018 at 12:57 PM Andrea Arcangeli wrote: > > > > This difference can only happen with defrag=always, and that's not the > > current upstream default. > > Ok, thanks. That makes it a bit less critical. > > > That MADV_HUGEPAGE causes flights with NUMA balancing is not great > > indeed, qemu needs NUMA locality too, but then the badness caused by > > __GFP_THISNODE was a larger regression in the worst case for qemu. > [...] > > So the short term alternative again would be the alternate patch that > > does __GFP_THISNODE|GFP_ONLY_COMPACT appended below. > > Sounds like we should probably do this. Particularly since Vlastimil > pointed out that we'd otherwise have issues with the back-port for 4.4 > where that "defrag=always" was the default. > > The patch doesn't look horrible, and it directly addresses this > particular issue. > > Is there some reason we wouldn't want to do it? We have discussed it previously and the biggest concern was that it introduces a new GFP flag with a very weird and one-off semantic. Anytime we have done that in the past it basically kicked back because people have started to use such a flag and any further changes were really hard to do. So I would really prefer some more systematic solution. And I believe we can do that here. MADV_HUGEPAGE (resp. THP always enabled) has gained a local memory policy with the patch which got effectively reverted. I do believe that conflating "I want THP" with "I want them local" is just wrong from the API point of view. There are different classes of usecases which obviously disagree on the later. So I believe that a long term solution should introduce a MPOL_NODE_RECLAIM kind of policy. It would effectively reclaim local nodes (within NODE_RECLAIM distance) before falling to other nodes. Apart from that we need a less disruptive reclaim driven by compaction and Mel is already working on that AFAIK. -- Michal Hocko SUSE Labs
RE: [PATCH] ALSA: pcm: Fix starvation on down_write_nonblock()
> > > > Hrm, converting unconditionally with msleep() looks too drastic. > > Yes, it looks drastic. But, IMHO, I can't say busy-spin is not non-drastic. Fix typo in this comment: I can't say busy-spin is not drastic. Thanks Chanho
Re: [PATCH] lzo: fix ip overrun during compress.
Hi Willy, On 2018/11/28 12:08, Willy Tarreau wrote: > Hi Yueyi, > > On Tue, Nov 27, 2018 at 10:34:26AM +, Yueyi Li wrote: >> It`s possible ip overrun in lzo1x_1_do_compress() when compressed page is >> point to the end of memory and which virtual address is 0xf000. >> Leading to a NULL pointer access during the get_unaligned_le32(ip). > Thanks for this report. > > (...) >> diff --git a/lib/lzo/lzo1x_compress.c b/lib/lzo/lzo1x_compress.c >> index 236eb21..a0265a6 100644 >> --- a/lib/lzo/lzo1x_compress.c >> +++ b/lib/lzo/lzo1x_compress.c >> @@ -17,6 +17,9 @@ >> #include >> #include "lzodefs.h" >> >> +#define OVERFLOW_ADD_CHECK(a, b) \ >> +((size_t)~0 - (size_t)(a) < (size_t)(b) ? true : false) >> + > I think the test would be easier to grasp this way : > > #define OVERFLOW_ADD_CHECK(a, b) \ > ((size_t)(b) >= (size_t)((void*)0 - (void *)(a))) > > But the following should be more efficient since we build with > -fno-strict-overflow : > > #define OVERFLOW_ADD_CHECK(a, b) \ > (((a) + (b)) < (a)) Thanks for the suggestion, I will change it in next version. > Could you please recheck ? > > Thanks, > Willy Thanks, Yueyi
Re: [patch 20/24] x86/speculation: Split out TIF update
On Tue, 27 Nov 2018, Thomas Gleixner wrote: > > Does it really have to? > > > > We need this special handling only if the next task has TIF_SPEC_UPDATE > > set, which is one-off event globally (when seccomp marks all its threads > > so due to seccomp filter change), and once all the TIF_SPEC_UPDATE tasks > > schedule at least once, we're in a consistent state again and don't need > > this, as every running task will then have its TIF consistent with MSR > > value. > > And how so? You set the bits is spec_flags. And then you set the TIF_UPDATE > bit which is evaluated once. Yeah, that was a complete brainfart on my side, sorry for the noise, disregard that crap. I blame it all on the dentist appointment I went through before writing the patch :p Thanks, -- Jiri Kosina SUSE Labs
[PATCH V2 3/4] defconfig: arm64: add i.MX system controller thermal support
This patch enables CONFIG_IMX_SC_THERMAL as module. Signed-off-by: Anson Huang --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index abd80c5..9f12324 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -376,6 +376,7 @@ CONFIG_SENSORS_RASPBERRYPI_HWMON=m CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y CONFIG_CPU_THERMAL=y CONFIG_THERMAL_EMULATION=y +CONFIG_IMX_SC_THERMAL=m CONFIG_ROCKCHIP_THERMAL=m CONFIG_RCAR_GEN3_THERMAL=y CONFIG_ARMADA_THERMAL=y -- 2.7.4
[PATCH V2 4/4] ARM64: dts: imx: add i.MX8QXP thermal support
Add i.MX8QXP CPU thermal zone support.
Signed-off-by: Anson Huang
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 5e8b554..ef57db6 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include "imx8-ca35.dtsi"
@@ -85,6 +86,32 @@
};
};
+ tsens: thermal-sensor {
+ compatible = "nxp,imx8qxp-sc-thermal";
+ tsens-num = <1>;
+ #thermal-sensor-cells = <1>;
+ };
+
+ thermal_zones: thermal-zones {
+ cpu-thermal0 {
+ polling-delay-passive = <250>;
+ polling-delay = <2000>;
+ thermal-sensors = <&tsens 355>;
+ trips {
+ cpu_alert0: trip0 {
+ temperature = <107000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+ cpu_crit0: trip1 {
+ temperature = <127000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+ };
+
adma_subsys: bus@5900 {
compatible = "simple-bus";
#address-cells = <1>;
--
2.7.4
[PATCH V2 1/4] dt-bindings: thermal: add binding doc for i.MX system controller thermal driver
NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
system controller, the system controller is in charge of system
power, clock and thermal sensors etc. management, Linux kernel
has to communicate with system controller via MU (message unit)
IPC to get temperature from thermal sensors, this patch adds
binding doc for i.MX system controller thermal driver.
Signed-off-by: Anson Huang
---
no change since V1.
.../devicetree/bindings/thermal/imx-sc-thermal.txt | 33 ++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/imx-sc-thermal.txt
diff --git a/Documentation/devicetree/bindings/thermal/imx-sc-thermal.txt
b/Documentation/devicetree/bindings/thermal/imx-sc-thermal.txt
new file mode 100644
index 000..2f5b0a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/imx-sc-thermal.txt
@@ -0,0 +1,33 @@
+* Temperature Monitor (TEMPMON) on NXP i.MX SoCs with System Controller
+
+Required properties:
+- compatible : Must be "nxp,imx8qxp-sc-thermal";
+- tsens-num : Total number of thermal sensors supported;
+- #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
+
+Example:
+tsens: thermal-sensor {
+ compatible = "nxp,imx8qxp-sc-thermal";
+ tsens-num = <1>;
+ #thermal-sensor-cells = <1>;
+};
+
+thermal_zones: thermal-zones {
+ cpu-thermal0 {
+ polling-delay-passive = <250>;
+ polling-delay = <2000>;
+ thermal-sensors = <&tsens 355>;
+ trips {
+ cpu_alert0: trip0 {
+ temperature = <107000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+ cpu_crit0: trip1 {
+ temperature = <127000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+};
--
2.7.4
[PATCH V2 2/4] thermal: imx_sc: add i.MX system controller thermal support
i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
inside, the system controller is in charge of controlling power,
clock and thermal sensors etc..
This patch adds i.MX system controller thermal driver support,
Linux kernel has to communicate with system controller via MU
(message unit) IPC to get each thermal sensor's temperature,
it supports multiple sensors which are passed from device tree,
please see the binding doc for details.
Signed-off-by: Anson Huang
---
changes since V1:
remove boiler plate license text;
remove unnecessary kfree during probe;
remove build warning of comparing unsigned int with < 0;
drivers/thermal/Kconfig | 11 +++
drivers/thermal/Makefile | 1 +
drivers/thermal/imx_sc_thermal.c | 201 +++
3 files changed, 213 insertions(+)
create mode 100644 drivers/thermal/imx_sc_thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 0e69edc..84e850c 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -222,6 +222,17 @@ config IMX_THERMAL
cpufreq is used as the cooling device to throttle CPUs when the
passive trip is crossed.
+config IMX_SC_THERMAL
+ tristate "Temperature sensor driver for NXP i.MX SoCs with System
Controller"
+ depends on ARCH_MXC || COMPILE_TEST
+ depends on OF
+ help
+ Support for Temperature Monitor (TEMPMON) found on NXP i.MX SoCs with
+ system controller inside, Linux kernel has to communicate with system
+ controller via MU (message unit) IPC to get temperature from thermal
+ sensor. It supports one critical trip point and one
+ passive trip point for each thermal sensor.
+
config MAX77620_THERMAL
tristate "Temperature sensor driver for Maxim MAX77620 PMIC"
depends on MFD_MAX77620
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 610344e..1b13f6a 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
obj-$(CONFIG_TANGO_THERMAL)+= tango_thermal.o
obj-$(CONFIG_IMX_THERMAL) += imx_thermal.o
+obj-$(CONFIG_IMX_SC_THERMAL) += imx_sc_thermal.o
obj-$(CONFIG_MAX77620_THERMAL) += max77620_thermal.o
obj-$(CONFIG_QORIQ_THERMAL)+= qoriq_thermal.o
obj-$(CONFIG_DA9062_THERMAL) += da9062-thermal.o
diff --git a/drivers/thermal/imx_sc_thermal.c b/drivers/thermal/imx_sc_thermal.c
new file mode 100644
index 000..890537f
--- /dev/null
+++ b/drivers/thermal/imx_sc_thermal.c
@@ -0,0 +1,201 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018 NXP.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "thermal_core.h"
+
+#define IMX_SC_MISC_FUNC_GET_TEMP 13
+#define IMX_SC_C_TEMP 0
+
+struct imx_sc_ipc *thermal_ipc_handle;
+
+struct imx_sc_sensor {
+ struct thermal_zone_device *tzd;
+ u32 resource_id;
+};
+
+struct imx_sc_thermal_data {
+ struct imx_sc_sensor *sensor;
+};
+
+struct imx_sc_msg_req_misc_get_temp {
+ struct imx_sc_rpc_msg hdr;
+ u16 resource_id;
+ u8 type;
+} __packed;
+
+struct imx_sc_msg_resp_misc_get_temp {
+ struct imx_sc_rpc_msg hdr;
+ u16 celsius;
+ u8 tenths;
+} __packed;
+
+static int imx_sc_thermal_get_temp(void *data, int *temp)
+{
+ struct imx_sc_msg_resp_misc_get_temp *resp;
+ struct imx_sc_msg_req_misc_get_temp msg;
+ struct imx_sc_rpc_msg *hdr = &msg.hdr;
+ struct imx_sc_sensor *sensor = data;
+ int ret;
+
+ msg.resource_id = sensor->resource_id;
+ msg.type = IMX_SC_C_TEMP;
+
+ hdr->ver = IMX_SC_RPC_VERSION;
+ hdr->svc = IMX_SC_RPC_SVC_MISC;
+ hdr->func = IMX_SC_MISC_FUNC_GET_TEMP;
+ hdr->size = 2;
+
+ ret = imx_scu_call_rpc(thermal_ipc_handle, &msg, true);
+ if (ret) {
+ pr_err("read temp sensor %d failed, ret %d\n",
+ sensor->resource_id, ret);
+ return ret;
+ }
+
+ resp = (struct imx_sc_msg_resp_misc_get_temp *)&msg;
+ *temp = resp->celsius * 1000 + resp->tenths * 100;
+
+ return 0;
+}
+
+static const struct thermal_zone_of_device_ops imx_sc_thermal_ops = {
+ .get_temp = imx_sc_thermal_get_temp,
+};
+
+static int imx_sc_thermal_register_sensor(struct platform_device *pdev,
+ struct imx_sc_sensor *sensor)
+{
+ struct thermal_zone_device *tzd;
+
+ tzd = devm_thermal_zone_of_sensor_register(&pdev->dev,
+ sensor->resource_id,
+ sensor,
+ &imx_sc_thermal_ops);
+ if (IS_ERR(tzd)) {
+ dev_err(&pdev->dev, "failed to register sensor: %d\n",
+
[PATCH V2 0/4] Add i.MX System Controller thermal driver support
i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller inside, the system controller is in charge of controlling power, clock and thermal sensors etc.. This patch adds i.MX system controller thermal driver support, Linux kernel has to communicate with system controller via MU (message unit) IPC to get each thermal sensor's temperature, it supports multiple sensors which are passed from device tree, please see the binding doc for details. Note that this patch set is based on [V4,5/5] defconfig: arm64: add imx8qxp support, https://patchwork.kernel.org/patch/10677315/ Anson Huang (4): dt-bindings: thermal: add binding doc for i.MX system controller thermal driver thermal: imx_sc: add i.MX system controller thermal support defconfig: arm64: add i.MX system controller thermal support ARM64: dts: imx: add i.MX8QXP thermal support .../devicetree/bindings/thermal/imx-sc-thermal.txt | 33 arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 27 +++ arch/arm64/configs/defconfig | 1 + drivers/thermal/Kconfig| 11 ++ drivers/thermal/Makefile | 1 + drivers/thermal/imx_sc_thermal.c | 201 + 6 files changed, 274 insertions(+) create mode 100644 Documentation/devicetree/bindings/thermal/imx-sc-thermal.txt create mode 100644 drivers/thermal/imx_sc_thermal.c -- 2.7.4
Re: [PATCH v3 3/3] thermal: tegra: parse sensor id before sensor register
Hi Daniel,
I updated my patch to parse the sensor id, please take a look.
Wei.
On 28/11/2018 1:44 PM, Wei Ni wrote:
> Since different platforms may not support all 4
> sensors, so the sensor registration may be failed.
> Add codes to parse dt to find sensor id which
> need to be registered. So that the registration
> can be successful on all platform.
>
> Signed-off-by: Wei Ni
> ---
> drivers/thermal/tegra/soctherm.c | 46
> ++--
> 1 file changed, 44 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/tegra/soctherm.c
> b/drivers/thermal/tegra/soctherm.c
> index 375cadbc24cd..79e4628224d7 100644
> --- a/drivers/thermal/tegra/soctherm.c
> +++ b/drivers/thermal/tegra/soctherm.c
> @@ -1224,6 +1224,44 @@ static void soctherm_init(struct platform_device *pdev)
> tegra_soctherm_throttle(&pdev->dev);
> }
>
> +static bool tegra_soctherm_find_sensor_id(int sensor_id)
> +{
> + int id;
> + bool ret = false;
> + struct of_phandle_args sensor_specs;
> + struct device_node *np, *sensor_np;
> +
> + np = of_find_node_by_name(NULL, "thermal-zones");
> + if (!np)
> + return ret;
> +
> + sensor_np = of_get_next_child(np, NULL);
> + for_each_available_child_of_node(np, sensor_np) {
> + if (of_parse_phandle_with_args(sensor_np, "thermal-sensors",
> + "#thermal-sensor-cells",
> + 0, &sensor_specs))
> + continue;
> +
> + if (sensor_specs.args_count != 1) {
> + WARN(sensor_specs.args_count > 1,
> + "%s: wrong cells in sensor specifier %d\n",
> + sensor_specs.np->name, sensor_specs.args_count);
> + continue;
> + } else {
> + id = sensor_specs.args[0];
> + if (sensor_id == id) {
> + ret = true;
> + break;
> + }
> + }
> + }
> +
> + of_node_put(np);
> + of_node_put(sensor_np);
> +
> + return ret;
> +}
> +
> static const struct of_device_id tegra_soctherm_of_match[] = {
> #ifdef CONFIG_ARCH_TEGRA_124_SOC
> {
> @@ -1365,13 +1403,15 @@ static int tegra_soctherm_probe(struct
> platform_device *pdev)
> zone->sg = soc->ttgs[i];
> zone->ts = tegra;
>
> + if (!tegra_soctherm_find_sensor_id(soc->ttgs[i]->id))
> + continue;
> z = devm_thermal_zone_of_sensor_register(&pdev->dev,
>soc->ttgs[i]->id, zone,
>&tegra_of_thermal_ops);
> if (IS_ERR(z)) {
> err = PTR_ERR(z);
> - dev_err(&pdev->dev, "failed to register sensor: %d\n",
> - err);
> + dev_err(&pdev->dev, "failed to register sensor %s:
> %d\n",
> + soc->ttgs[i]->name, err);
> goto disable_clocks;
> }
>
> @@ -1434,6 +1474,8 @@ static int __maybe_unused soctherm_resume(struct device
> *dev)
> struct thermal_zone_device *tz;
>
> tz = tegra->thermctl_tzs[soc->ttgs[i]->id];
> + if (!tz)
> + continue;
> err = tegra_soctherm_set_hwtrips(dev, soc->ttgs[i], tz);
> if (err) {
> dev_err(&pdev->dev,
>
[PATCH v3 3/3] thermal: tegra: parse sensor id before sensor register
Since different platforms may not support all 4
sensors, so the sensor registration may be failed.
Add codes to parse dt to find sensor id which
need to be registered. So that the registration
can be successful on all platform.
Signed-off-by: Wei Ni
---
drivers/thermal/tegra/soctherm.c | 46 ++--
1 file changed, 44 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/tegra/soctherm.c b/drivers/thermal/tegra/soctherm.c
index 375cadbc24cd..79e4628224d7 100644
--- a/drivers/thermal/tegra/soctherm.c
+++ b/drivers/thermal/tegra/soctherm.c
@@ -1224,6 +1224,44 @@ static void soctherm_init(struct platform_device *pdev)
tegra_soctherm_throttle(&pdev->dev);
}
+static bool tegra_soctherm_find_sensor_id(int sensor_id)
+{
+ int id;
+ bool ret = false;
+ struct of_phandle_args sensor_specs;
+ struct device_node *np, *sensor_np;
+
+ np = of_find_node_by_name(NULL, "thermal-zones");
+ if (!np)
+ return ret;
+
+ sensor_np = of_get_next_child(np, NULL);
+ for_each_available_child_of_node(np, sensor_np) {
+ if (of_parse_phandle_with_args(sensor_np, "thermal-sensors",
+"#thermal-sensor-cells",
+0, &sensor_specs))
+ continue;
+
+ if (sensor_specs.args_count != 1) {
+ WARN(sensor_specs.args_count > 1,
+"%s: wrong cells in sensor specifier %d\n",
+sensor_specs.np->name, sensor_specs.args_count);
+ continue;
+ } else {
+ id = sensor_specs.args[0];
+ if (sensor_id == id) {
+ ret = true;
+ break;
+ }
+ }
+ }
+
+ of_node_put(np);
+ of_node_put(sensor_np);
+
+ return ret;
+}
+
static const struct of_device_id tegra_soctherm_of_match[] = {
#ifdef CONFIG_ARCH_TEGRA_124_SOC
{
@@ -1365,13 +1403,15 @@ static int tegra_soctherm_probe(struct platform_device
*pdev)
zone->sg = soc->ttgs[i];
zone->ts = tegra;
+ if (!tegra_soctherm_find_sensor_id(soc->ttgs[i]->id))
+ continue;
z = devm_thermal_zone_of_sensor_register(&pdev->dev,
soc->ttgs[i]->id, zone,
&tegra_of_thermal_ops);
if (IS_ERR(z)) {
err = PTR_ERR(z);
- dev_err(&pdev->dev, "failed to register sensor: %d\n",
- err);
+ dev_err(&pdev->dev, "failed to register sensor %s:
%d\n",
+ soc->ttgs[i]->name, err);
goto disable_clocks;
}
@@ -1434,6 +1474,8 @@ static int __maybe_unused soctherm_resume(struct device
*dev)
struct thermal_zone_device *tz;
tz = tegra->thermctl_tzs[soc->ttgs[i]->id];
+ if (!tz)
+ continue;
err = tegra_soctherm_set_hwtrips(dev, soc->ttgs[i], tz);
if (err) {
dev_err(&pdev->dev,
--
2.7.4
[PATCH v3 2/3] thermal: tegra: fix memory allocation
Fix memory allocation to store the pointers to thermal_zone_device. Signed-off-by: Wei Ni Acked-by: Thierry Reding --- drivers/thermal/tegra/soctherm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/tegra/soctherm.c b/drivers/thermal/tegra/soctherm.c index 55cc1f2f6a45..375cadbc24cd 100644 --- a/drivers/thermal/tegra/soctherm.c +++ b/drivers/thermal/tegra/soctherm.c @@ -1339,7 +1339,7 @@ static int tegra_soctherm_probe(struct platform_device *pdev) } tegra->thermctl_tzs = devm_kcalloc(&pdev->dev, - soc->num_ttgs, sizeof(*z), + soc->num_ttgs, sizeof(z), GFP_KERNEL); if (!tegra->thermctl_tzs) return -ENOMEM; -- 2.7.4
[PATCH v3 0/3] Fixes for Tegra soctherm
This series fixed some issues for Tegra soctherm Main changes from v2: 1. add codes to parse sensor id to avoid registration failure. Main changes from v1: 1. Acked by Thierry Reding for the patch "thermal: tegra: fix memory allocation". 2. Print out the sensor name when register failed. 2. Remove patch "thermal: tegra: fix coverity defect" Wei Ni (3): thermal: tegra: remove unnecessary warnings thermal: tegra: fix memory allocation thermal: tegra: parse sensor id before sensor register drivers/thermal/tegra/soctherm.c | 54 +++- 1 file changed, 48 insertions(+), 6 deletions(-) -- 2.7.4
[PATCH v3 1/3] thermal: tegra: remove unnecessary warnings
Convert warnings to info as not all platforms may
have all the thresholds and sensors enabled.
Signed-off-by: Wei Ni
---
drivers/thermal/tegra/soctherm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/tegra/soctherm.c b/drivers/thermal/tegra/soctherm.c
index ed28110a3535..55cc1f2f6a45 100644
--- a/drivers/thermal/tegra/soctherm.c
+++ b/drivers/thermal/tegra/soctherm.c
@@ -550,7 +550,7 @@ static int tegra_soctherm_set_hwtrips(struct device *dev,
ret = tz->ops->get_crit_temp(tz, &temperature);
if (ret) {
- dev_warn(dev, "thermtrip: %s: missing critical temperature\n",
+ dev_info(dev, "thermtrip: %s: missing critical temperature\n",
sg->name);
goto set_throttle;
}
@@ -569,7 +569,7 @@ static int tegra_soctherm_set_hwtrips(struct device *dev,
set_throttle:
ret = get_hot_temp(tz, &trip, &temperature);
if (ret) {
- dev_warn(dev, "throttrip: %s: missing hot temperature\n",
+ dev_info(dev, "throttrip: %s: missing hot temperature\n",
sg->name);
return 0;
}
@@ -600,7 +600,7 @@ static int tegra_soctherm_set_hwtrips(struct device *dev,
}
if (i == THROTTLE_SIZE)
- dev_warn(dev, "throttrip: %s: missing throttle cdev\n",
+ dev_info(dev, "throttrip: %s: missing throttle cdev\n",
sg->name);
return 0;
--
2.7.4
[PATCH v2 1/2] mtd: rawnand: denali: remove ->dev_ready() hook
The Denali NAND IP has no way to read out the current signal level
of the R/B# pin. Instead, denali_dev_ready() checks if the R/B#
transition has already happened. (The INTR__INT_ACT interrupt is
asserted at the rising edge of the R/B# pin.) It is not a correct
way to implement the ->dev_ready() hook.
In fact, it has a drawback; in the nand_scan_ident phase, the chip
detection iterates over maxchips until it fails to find a homogeneous
chip. For the last loop, nand_reset() fails if no chip is there.
If ->dev_ready hook exists, nand_command(_lp) calls nand_wait_ready()
after NAND_CMD_RESET. However, we know denali_dev_ready() never
returns 1 unless there exists a chip that toggles R/B# in that chip
select. Then, nand_wait_ready() just ends up with wasting 400 msec,
in the end, shows the "timeout while waiting for chip to become ready"
warning.
Let's remove the mis-implemented dev_ready hook, and fallback to
sending the NAND_CMD_STATUS and nand_wait_status_ready(), which
bails out more quickly.
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Rebase
drivers/mtd/nand/raw/denali.c | 23 +--
1 file changed, 1 insertion(+), 22 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 830ea24..ead6e60 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -204,18 +204,6 @@ static uint32_t denali_wait_for_irq(struct
denali_nand_info *denali,
return denali->irq_status;
}
-static uint32_t denali_check_irq(struct denali_nand_info *denali)
-{
- unsigned long flags;
- uint32_t irq_status;
-
- spin_lock_irqsave(&denali->irq_lock, flags);
- irq_status = denali->irq_status;
- spin_unlock_irqrestore(&denali->irq_lock, flags);
-
- return irq_status;
-}
-
static void denali_read_buf(struct nand_chip *chip, uint8_t *buf, int len)
{
struct mtd_info *mtd = nand_to_mtd(chip);
@@ -288,8 +276,7 @@ static void denali_cmd_ctrl(struct nand_chip *chip, int
dat, unsigned int ctrl)
return;
/*
-* Some commands are followed by chip->legacy.dev_ready or
-* chip->legacy.waitfunc.
+* Some commands are followed by chip->legacy.waitfunc.
* irq_status must be cleared here to catch the R/B# interrupt later.
*/
if (ctrl & NAND_CTRL_CHANGE)
@@ -298,13 +285,6 @@ static void denali_cmd_ctrl(struct nand_chip *chip, int
dat, unsigned int ctrl)
denali->host_write(denali, DENALI_BANK(denali) | type, dat);
}
-static int denali_dev_ready(struct nand_chip *chip)
-{
- struct denali_nand_info *denali = mtd_to_denali(nand_to_mtd(chip));
-
- return !!(denali_check_irq(denali) & INTR__INT_ACT);
-}
-
static int denali_check_erased_page(struct mtd_info *mtd,
struct nand_chip *chip, uint8_t *buf,
unsigned long uncor_ecc_flags,
@@ -1359,7 +1339,6 @@ int denali_init(struct denali_nand_info *denali)
chip->legacy.read_byte = denali_read_byte;
chip->legacy.write_byte = denali_write_byte;
chip->legacy.cmd_ctrl = denali_cmd_ctrl;
- chip->legacy.dev_ready = denali_dev_ready;
chip->legacy.waitfunc = denali_waitfunc;
if (features & FEATURES__INDEX_ADDR) {
--
2.7.4
[PATCH v2 0/2] mtd: rawnand: denali: clean-up unnecessary hook and device reset
I sent this series on September, and Miquel replied this series was applied: http://patchwork.ozlabs.org/patch/967242/ But, It turned out not applied. I rebased it and resending now. Masahiro Yamada (2): mtd: rawnand: denali: remove ->dev_ready() hook mtd: rawnand: denali: remove denali_reset_banks() drivers/mtd/nand/raw/denali.c | 52 +-- 1 file changed, 1 insertion(+), 51 deletions(-) -- 2.7.4
[PATCH v2 2/2] mtd: rawnand: denali: remove denali_reset_banks()
In nand_scan_ident(), the controller driver resets every NAND chip.
This is done by sending NAND_CMD_RESET. The Denali IP provides
another way to do the equivalent thing; if a bit is set in the
DEVICE_RESET register, the controller sends the RESET command to
the corresponding device. denali_reset_banks() uses it to reset
all devices beforehand.
This redundant reset sequence was needed to know the actual number
of chips before calling nand_scan_ident(); if DEVICE_RESET fails,
there is no chip in that chip select. Then, denali_reset_banks()
sets denali->max_banks to the number of detected chips.
As commit f486287d2372 ("mtd: nand: denali: fix bank reset function
to detect the number of chips") explained, nand_scan_ident() issued
Set Features (0xEF) command to all CS lines, some of which may not be
connected with a chip. Then, the driver would wait for R/B# response,
which never happens.
This problem was solved by commit 107b7d6a7ad4 ("mtd: rawnand: avoid
setting again the timings to mode 0 after a reset"). In the current
code, nand_setup_data_interface() is called from nand_scan_tail(),
which is invoked after the chip detection.
Now, we can really remove the redundant denali_nand_banks() by simply
passing the maximum number of chip selects supported by this IP
(typically 4 or 8) to nand_scan(). Let's leave all the chip detection
process to nand_scan_ident().
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
drivers/mtd/nand/raw/denali.c | 29 -
1 file changed, 29 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index ead6e60..2302010 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -1045,29 +1045,6 @@ static int denali_setup_data_interface(struct nand_chip
*chip, int chipnr,
return 0;
}
-static void denali_reset_banks(struct denali_nand_info *denali)
-{
- u32 irq_status;
- int i;
-
- for (i = 0; i < denali->max_banks; i++) {
- denali->active_bank = i;
-
- denali_reset_irq(denali);
-
- iowrite32(DEVICE_RESET__BANK(i),
- denali->reg + DEVICE_RESET);
-
- irq_status = denali_wait_for_irq(denali,
- INTR__RST_COMP | INTR__INT_ACT | INTR__TIME_OUT);
- if (!(irq_status & INTR__INT_ACT))
- break;
- }
-
- dev_dbg(denali->dev, "%d chips connected\n", i);
- denali->max_banks = i;
-}
-
static void denali_hw_init(struct denali_nand_info *denali)
{
/*
@@ -1321,12 +1298,6 @@ int denali_init(struct denali_nand_info *denali)
}
denali_enable_irq(denali);
- denali_reset_banks(denali);
- if (!denali->max_banks) {
- /* Error out earlier if no chip is found for some reasons. */
- ret = -ENODEV;
- goto disable_irq;
- }
denali->active_bank = DENALI_INVALID_BANK;
--
2.7.4
linux-next: Tree for Nov 28
Hi all, Changes since 20181127: The vfs tree gained a conflict against the ext3 tree. Non-merge commits (relative to Linus' tree): 5084 5241 files changed, 259238 insertions(+), 151877 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 286 trees (counting Linus' and 67 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (ef78e5ec9214 ia64: export node_distance function) Merging fixes/master (595c647d341e sparc: suppress the implicit-fallthrough warnings) Merging kbuild-current/fixes (ccda4af0f4b9 Linux 4.20-rc2) Merging arc-current/for-curr (6b04114f6fae arc: [devboards] Add support of NFSv3 ACL) Merging arm-current/fixes (e46daee53bb5 ARM: 8806/1: kprobes: Fix false positive with FORTIFY_SOURCE) Merging arm64-fixes/for-next/fixes (4f9f49646a57 arm64: cpufeature: Fix mismerge of CONFIG_ARM64_SSBD block) Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and m68k_pgtable_cachemode) Merging powerpc-fixes/fixes (b2fed34a628d selftests/powerpc: Adjust wild_bctr to build with old binutils) Merging sparc/master (86322ba9571a arch/sparc: Use kzalloc_node) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (93143f846b27 Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf) Merging bpf/master (2b9034b5eadd sparc: Adjust bpf JIT prologue for PSEUDO calls.) Merging ipsec/master (4a135e538962 xfrm_user: fix freeing of xfrm states on acquire) Merging netfilter/master (53ca0f2fec39 netfilter: nf_conncount: remove wrong condition check routine) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (2e6e902d1850 Linux 4.20-rc4) Merging mac80211/master (113f3aaa81bd cfg80211: Prevent regulatory restore during STA disconnect in concurrent interfaces) Merging rdma-fixes/for-rc (75b7b86bdb0d IB/mlx5: Fix page fault handling for MW) Merging sound-current/for-linus (b8e0be79d000 Merge tag 'asoc-v4.20-rc4' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging sound-asoc-fixes/for-linus (8f47ccdd70fd Merge branch 'asoc-4.20' into asoc-linus) Merging regmap-fixes/for-linus (9ff01193a20d Linux 4.20-rc3) Merging regulator-fixes/for-linus (84f59cf6d5fc Merge branch 'regulator-4.20' into regulator-linus) Merging spi-fixes/for-linus (0ca420a3bddf Merge branch 'spi-4.20' into spi-linus) Merging pci-current/for-linus (94ea01a6d9a6 PCI: Fix incorrect value returned from pcie_get_speed_cap()) Merging driver-core.current/driver-core-linus (a66d972465d1 devres: Align data[] to ARCH_KMALLOC_MINALIGN) Merging tty.current/tty-linus (2a48602615e0 tty: do not set TTY_IO_ERROR flag if console port) Merging usb.current/usb-linus (effd14f66cc1 usb: core: quirks: add RESET_RESUME quirk for Cherry G230 Stream series) Merging usb-gadget-fixes/fixes (069caf5950df USB: omap_udc: fix rejection of out transfers when DMA is used) Merging usb-serial-fixes/usb-linus (ccda4af0f4b9 Linux 4.20-rc2) Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: Always build ULPI code) Merging phy/fixes (c88520db18ba phy: qcom-qusb2: Fix HSTX_TRIM tuning with fused value for SDM845) Me
[PATCH V2 0/4] Add i.MX system controller RTC driver
NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as system controller, the system controller is in charge of system power, clock and secure RTC etc. management, Linux kernel has to communicate with system controller via MU (message unit) IPC to do RTC operation. Since the RTC set time MUST to be done in secure EL3 mode (required by system controller firmware) and ALARM functions needs to be done with general MU IRQ handle, these are NOT ready NOW, so this patch ONLY supports RTC read time for now. Note that this patch set is based on [V4,5/5] defconfig: arm64: add imx8qxp support, https://patchwork.kernel.org/patch/10677315/ Anson Huang (4): dt-bindings: rtc: add binding doc for i.MX system controller RTC driver rtc: add i.MX system controller RTC support defconfig: arm64: add i.MX system controller RTC support ARM64: dts: imx: add i.MX8QXP system controller RTC support .../devicetree/bindings/rtc/rtc-imx-sc.txt | 10 ++ arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 4 + arch/arm64/configs/defconfig | 1 + drivers/rtc/Kconfig| 6 ++ drivers/rtc/Makefile | 1 + drivers/rtc/rtc-imx-sc.c | 107 + 6 files changed, 129 insertions(+) create mode 100644 Documentation/devicetree/bindings/rtc/rtc-imx-sc.txt create mode 100644 drivers/rtc/rtc-imx-sc.c -- 2.7.4
[PATCH V2 1/4] dt-bindings: rtc: add binding doc for i.MX system controller RTC driver
NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
system controller, the system controller is in charge of system
power, clock and secure RTC etc. management, Linux kernel
has to communicate with system controller via MU (message unit)
IPC to do RTC operation, this patch adds binding doc for i.MX
system controller RTC driver.
Signed-off-by: Anson Huang
---
no change since V1.
Documentation/devicetree/bindings/rtc/rtc-imx-sc.txt | 10 ++
1 file changed, 10 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/rtc-imx-sc.txt
diff --git a/Documentation/devicetree/bindings/rtc/rtc-imx-sc.txt
b/Documentation/devicetree/bindings/rtc/rtc-imx-sc.txt
new file mode 100644
index 000..d6e2353
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/rtc-imx-sc.txt
@@ -0,0 +1,10 @@
+* NXP i.MX System Controller Real Time Clock
+
+Required properties:
+- compatible: should be "nxp,imx8qxp-sc-rtc";
+
+Example:
+
+rtc: rtc {
+ compatible = "nxp,imx8qxp-sc-rtc";
+};
--
2.7.4
[PATCH V2 4/4] ARM64: dts: imx: add i.MX8QXP system controller RTC support
Add i.MX8QXP system controller RTC support.
Signed-off-by: Anson Huang
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 9155d45..ef57db6 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -433,4 +433,8 @@
#size-cells = <1>;
ranges = <0x5f00 0x0 0x5f00 0x100>;
};
+
+ rtc: rtc {
+ compatible = "nxp,imx8qxp-sc-rtc";
+ };
};
--
2.7.4
[PATCH V2 2/4] rtc: add i.MX system controller RTC support
i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
inside, the system controller is in charge of controlling power,
clock and secure rtc etc..
This patch adds i.MX system controller RTC driver support,
Linux kernel has to communicate with system controller via MU
(message unit) IPC to set/get RTC time and other alarm functions,
since the RTC set time needs to be done in secure EL3 mode (required
by system controller firmware) and alarm functions needs to be done
with general MU IRQ handle, these depend on other components which
are NOT ready, so this patch ONLY enables the RTC time read.
Signed-off-by: Anson Huang
---
changes since V1:
- sort module in Makefile alphabetically;
- remove boiler plate license text;
- use devm_rtc_allocate_device and rtc_register_device to register the
RTC.
drivers/rtc/Kconfig | 6 +++
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-imx-sc.c | 107 +++
3 files changed, 114 insertions(+)
create mode 100644 drivers/rtc/rtc-imx-sc.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index a819ef0..3b9642e 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1677,6 +1677,12 @@ config RTC_DRV_SNVS
This driver can also be built as a module, if so, the module
will be called "rtc-snvs".
+config RTC_DRV_IMX_SC
+ tristate "NXP i.MX System Controller RTC support"
+ help
+ If you say yes here you get support for the NXP i.MX System
+ Controller RTC module.
+
config RTC_DRV_SIRFSOC
tristate "SiRFSOC RTC"
depends on ARCH_SIRF
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 290c173..f97c05e 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -75,6 +75,7 @@ obj-$(CONFIG_RTC_DRV_GOLDFISH)+= rtc-goldfish.o
obj-$(CONFIG_RTC_DRV_HID_SENSOR_TIME) += rtc-hid-sensor-time.o
obj-$(CONFIG_RTC_DRV_HYM8563) += rtc-hym8563.o
obj-$(CONFIG_RTC_DRV_IMXDI)+= rtc-imxdi.o
+obj-$(CONFIG_RTC_DRV_IMX_SC) += rtc-imx-sc.o
obj-$(CONFIG_RTC_DRV_ISL12022) += rtc-isl12022.o
obj-$(CONFIG_RTC_DRV_ISL12026) += rtc-isl12026.o
obj-$(CONFIG_RTC_DRV_ISL1208) += rtc-isl1208.o
diff --git a/drivers/rtc/rtc-imx-sc.c b/drivers/rtc/rtc-imx-sc.c
new file mode 100644
index 000..7212e38
--- /dev/null
+++ b/drivers/rtc/rtc-imx-sc.c
@@ -0,0 +1,107 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018 NXP.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define IMX_SC_TIMER_FUNC_GET_RTC_SEC1970 9
+#define IMX_SC_TIMER_FUNC_SET_RTC_TIME 6
+
+struct imx_sc_ipc *rtc_ipc_handle;
+struct rtc_device *rtc;
+
+struct imx_sc_msg_req_timer_get_rtc_time {
+ struct imx_sc_rpc_msg hdr;
+} __packed;
+
+struct imx_sc_msg_resp_timer_get_rtc_time {
+ struct imx_sc_rpc_msg hdr;
+ u32 time;
+} __packed;
+
+static int imx_sc_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+ struct imx_sc_msg_resp_timer_get_rtc_time *resp;
+ struct imx_sc_msg_req_timer_get_rtc_time msg;
+ struct imx_sc_rpc_msg *hdr = &msg.hdr;
+ int ret;
+
+ hdr->ver = IMX_SC_RPC_VERSION;
+ hdr->svc = IMX_SC_RPC_SVC_TIMER;
+ hdr->func = IMX_SC_TIMER_FUNC_GET_RTC_SEC1970;
+ hdr->size = 1;
+
+ ret = imx_scu_call_rpc(rtc_ipc_handle, &msg, true);
+ if (ret) {
+ pr_err("read rtc time failed, ret %d\n", ret);
+ return ret;
+ }
+
+ resp = (struct imx_sc_msg_resp_timer_get_rtc_time *)&msg;
+ rtc_time_to_tm(resp->time, tm);
+
+ return 0;
+}
+
+static const struct rtc_class_ops imx_sc_rtc_ops = {
+ .read_time = imx_sc_rtc_read_time,
+};
+
+static int imx_sc_rtc_probe(struct platform_device *pdev)
+{
+ int ret;
+
+ ret = imx_scu_get_handle(&rtc_ipc_handle);
+ if (ret) {
+ if (ret == -EPROBE_DEFER)
+ return ret;
+
+ dev_err(&pdev->dev, "failed to get ipc handle: %d!\n", ret);
+ return ret;
+ }
+
+ rtc = devm_rtc_allocate_device(&pdev->dev);
+ if (IS_ERR(rtc)) {
+ ret = PTR_ERR(rtc);
+ return ret;
+ }
+
+ rtc->ops = &imx_sc_rtc_ops;
+ rtc->range_min = 0;
+ rtc->range_max = U32_MAX;
+
+ ret = rtc_register_device(rtc);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to register rtc: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static const struct of_device_id imx_sc_dt_ids[] = {
+ { .compatible = "nxp,imx8qxp-sc-rtc", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, imx_sc_dt_ids);
+
+static struct platform_driver imx_sc_rtc_driver = {
+ .driver = {
+ .name = "imx-sc-rtc",
+ .of_match_table = imx_sc_dt_ids,
+ },
+ .probe = imx_sc_rtc_probe,
+};
+module_platform_driver(imx_sc_rtc_driver);
+
+MODULE_AUTHO
[PATCH V2 3/4] defconfig: arm64: add i.MX system controller RTC support
This patch enables CONFIG_RTC_DRV_IMX_SC as module by default. Signed-off-by: Anson Huang --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 6d224f7..e3df5dd 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -573,6 +573,7 @@ CONFIG_RTC_DRV_PL031=y CONFIG_RTC_DRV_SUN6I=y CONFIG_RTC_DRV_ARMADA38X=y CONFIG_RTC_DRV_TEGRA=y +CONFIG_RTC_DRV_IMX_SC=m CONFIG_RTC_DRV_XGENE=y CONFIG_DMADEVICES=y CONFIG_DMA_BCM2835=m -- 2.7.4
Re: [PATCH v5 1/2] gpio: Add driver for PC Engines APU boards
Hi Florian, Thank you for the patch! Yet something to improve: [auto build test ERROR on gpio/for-next] [also build test ERROR on v4.20-rc4 next-20181127] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Florian-Eckert/Add-device-driver-for-APU2-APU3-GPIOs/20181128-045043 base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git for-next config: i386-allmodconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 All error/warnings (new ones prefixed by >>): In file included from drivers/gpio/gpio-apu.c:13:0: >> include/linux/module.h:213:1: error: expected ',' or ';' before 'extern' extern typeof(name) __mod_##type##__##name##_device_table \ ^ >> drivers/gpio/gpio-apu.c:163:1: note: in expansion of macro >> 'MODULE_DEVICE_TABLE' MODULE_DEVICE_TABLE(dmi, apu2_gpio_dmi_table); ^~~ vim +213 include/linux/module.h ^1da177e Linus Torvalds2005-04-16 209 cff26a51 Rusty Russell 2014-02-03 210 #ifdef MODULE cff26a51 Rusty Russell 2014-02-03 211 /* Creates an alias so file2alias.c can find device table. */ ^1da177e Linus Torvalds2005-04-16 212 #define MODULE_DEVICE_TABLE(type, name) \ 0bf8bf50 Matthias Kaehlcke 2017-07-24 @213 extern typeof(name) __mod_##type##__##name##_device_table \ cff26a51 Rusty Russell 2014-02-03 214__attribute__ ((unused, alias(__stringify(name cff26a51 Rusty Russell 2014-02-03 215 #else /* !MODULE */ cff26a51 Rusty Russell 2014-02-03 216 #define MODULE_DEVICE_TABLE(type, name) cff26a51 Rusty Russell 2014-02-03 217 #endif ^1da177e Linus Torvalds2005-04-16 218 :: The code at line 213 was first introduced by commit :: 0bf8bf50eddc7511b52461bae798cbfaa0157a34 module: Remove const attribute from alias for MODULE_DEVICE_TABLE :: TO: Matthias Kaehlcke :: CC: Jessica Yu --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v17 18/23] platform/x86: Intel SGX driver
On Sat, Nov 24, 2018 at 08:45:34AM -0800, Jarkko Sakkinen wrote: > On Fri, Nov 23, 2018 at 04:39:23AM -0600, Dr. Greg wrote: > > Jarkko, when this driver lands it will set the SGX ABI in stone for > > Linux. It would be very, very helpful to the development community if > > there was some official guidance from Intel on whether or not FLC will > > be a universal feature on all hardware and the date that is going to > > happen or has happened. > > I seriously don't know but I can take this message to the mothership... LC enabling is essentially a platform vendors choice, not Intels choice, like many other CPU features that Linux is dependent on. Of course, if Linux ends supporting only LC that will without doubt have a big impact on vendors so in that way it is indirectly also communitys choice. /Jarkko
Re: siginfo pid not populated from ptrace?
Kees Cook writes: > On Tue, Nov 27, 2018 at 4:38 PM, Kees Cook wrote: >> On Tue, Nov 27, 2018 at 3:21 PM, Tycho Andersen wrote: >>> On Mon, Nov 12, 2018 at 12:24:43PM -0700, Tycho Andersen wrote: On Mon, Nov 12, 2018 at 11:55:38AM -0700, Tycho Andersen wrote: > I haven't manage to reproduce it on stock v4.20-rc2, unfortunately. Ok, now I have, seccomp_bpf.c:2736:global.syscall_restart:Expected getpid() (1493) == info._sifields._kill.si_pid (0) global.syscall_restart: Test failed at step #22 >>> >>> Seems like this is still happening on v4.20-rc4, >>> >>> [ RUN ] global.syscall_restart >>> seccomp_bpf.c:2736:global.syscall_restart:Expected getpid() (1901) == >>> info._sifields._kill.si_pid (0) >>> global.syscall_restart: Test failed at step #22 >> >> This fails every time for me -- is it still racey for you? >> >> I'm attempting a bisect, hoping it doesn't _become_ racey for me. ;) > > This bisect to here for me: > > commit f149b31557446aff9ca96d4be7e39cc266f6e7cc > Author: Eric W. Biederman > Date: Mon Sep 3 09:50:36 2018 +0200 > > signal: Never allocate siginfo for SIGKILL or SIGSTOP > > The SIGKILL and SIGSTOP signals are never delivered to userspace so > queued siginfo for these signals can never be observed. Therefore > remove the chance of failure by never even attempting to allocate > siginfo in those cases. > > Reviewed-by: Thomas Gleixner > Signed-off-by: "Eric W. Biederman" > > They are certainly visible via seccomp ;) Well SIGSTOP is visible via PTRACE_GETSIGINFO. I see what is happening now. Since we don't have queued siginfo we generate some as: /* * Ok, it wasn't in the queue. This must be * a fast-pathed signal or we must have been * out of queue space. So zero out the info. */ clear_siginfo(info); info->si_signo = sig; info->si_errno = 0; info->si_code = SI_USER; info->si_pid = 0; info->si_uid = 0; Which allows last_signfo to be set, so despite not really having any siginfo PTRACE_GET_SIGINFO has something to return so does not return -EINVAL. Reconstructing my context that was part of removing SEND_SIG_FORCED so this looks like it will take a little more than a revert to fix this. This is definitely a change that is visible to user space. The logic in my patch was definitely wrong with respect to SIGSTOP and PTRACE_GETSIGINFO. Is there something in userspace that actually cares? AKA is the idiom that the test seccomp_bpf.c is using something that non-test code does? The change below should restore the old behavior. I am just wondering if this is something we want to do. siginfo is allocated with GFP_ATOMIC so if your maching is under memory pressure there is a real chance the allocation can fail. Which would cause whatever is breaking now to break less deterministically then. If we need to fix this do we need to make siginfo allocation more reliable? Eric diff --git a/kernel/signal.c b/kernel/signal.c index 4fd431ce4f91..5c34c55bfea4 100644 --- a/kernel/signal.c +++ b/kernel/signal.c @@ -1057,10 +1057,10 @@ static int __send_signal(int sig, struct kernel_siginfo *info, struct task_struc result = TRACE_SIGNAL_DELIVERED; /* -* Skip useless siginfo allocation for SIGKILL SIGSTOP, +* Skip useless siginfo allocation for SIGKILL, * and kernel threads. */ - if (sig_kernel_only(sig) || (t->flags & PF_KTHREAD)) + if ((sig == SIGKILL) || (t->flags & PF_KTHREAD)) goto out_set; /*
Re: [PATCH 1/1] sched/headers: fix thread_info. is overwritten by STACK_END_MAGIC
Hello Kees,
On 2018/11/28 6:38, Kees Cook wrote:
> On Thu, Nov 22, 2018 at 11:54 PM, Wang Dongsheng
> wrote:
>> When select ARCH_TASK_STRUCT_ON_STACK the first of thread_info variable
>> is overwritten by STACK_END_MAGIC. In fact, the ARCH_TASK_STRUCT_ON_STACK
>> is not a real task on stack, it's only init_task on init_stack.
>>
>> Commit 0500871f21b2 ("Construct init thread stack in the linker script
>> rather than by union") added this macro and put task_strcut into
>> thread_union. This brings us the following possibilities:
>> TASK_ON_STACKTHREAD_INFO_IN_TASKSTACK
>> - <-- thread_info & stack
>> NN | | --- <-- task
>>| || |
>> - ---
>>
>> - <-- stack
>> NY | | --- <--
>> task(Including thread_info)
>>| || |
>> - ---
>>
>> - <-- stack & task &
>> thread_info
>> YN | |
>>| |
>> -
>>
>> - <-- stack & task(Including
>> thread_info)
>> YY | |
>>| |
>> -
>> The kernel has handled the first two cases correctly.
>>
>> For the third case:
>> TASK_ON_STACK: Y. THREAD_INFO_IN_TASK: N. this case
>> should never happen, because the task and thread_info will overlap. So
>> when TASK_ON_STACK is selected, THREAD_INFO_IN_TASK must be selected too.
>>
>> For the fourth case:
>> When task on stack, the end of stack should add a sizeof(task_struct) offset.
>>
>> This patch handled with the third and fourth case.
>>
>> Fixes: 0500871f21b2 ("Construct init thread stack in the linker ...")
>>
>> Signed-off-by: Wang Dongsheng
>> Signed-off-by: Shunyong Yang
>> ---
>> arch/Kconfig | 1 +
>> include/linux/sched/task_stack.h | 5 -
>> 2 files changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/Kconfig b/arch/Kconfig
>> index e1e540ffa979..0a2c73e73195 100644
>> --- a/arch/Kconfig
>> +++ b/arch/Kconfig
>> @@ -251,6 +251,7 @@ config ARCH_HAS_SET_MEMORY
>> # Select if arch init_task must go in the __init_task_data section
>> config ARCH_TASK_STRUCT_ON_STACK
>> bool
>> + depends on THREAD_INFO_IN_TASK || IA64
> The "IA64" part shouldn't be needed since IA64 already selects it.
>
> Since it's selected, it also can't have a depends, IIUC.
Since the IA64 thread_info including task_struct, it doesn't need to
select THREAD_INFO_IN_TASK.
So we need to allow IA64 select ARCH_TASK_STRUCT_ON_STACK without
THREAD_INFO.
>> # Select if arch has its private alloc_task_struct() function
>> config ARCH_TASK_STRUCT_ALLOCATOR
>> diff --git a/include/linux/sched/task_stack.h
>> b/include/linux/sched/task_stack.h
>> index 6a841929073f..624c48defb9e 100644
>> --- a/include/linux/sched/task_stack.h
>> +++ b/include/linux/sched/task_stack.h
>> @@ -7,6 +7,7 @@
>> */
>>
>> #include
>> +#include
>> #include
>>
>> #ifdef CONFIG_THREAD_INFO_IN_TASK
>> @@ -25,7 +26,9 @@ static inline void *task_stack_page(const struct
>> task_struct *task)
>>
>> static inline unsigned long *end_of_stack(const struct task_struct *task)
>> {
>> - return task->stack;
>> + if (!IS_ENABLED(CONFIG_ARCH_TASK_STRUCT_ON_STACK) || task !=
>> &init_task)
>> + return task->stack;
>> + return (unsigned long *)(task + 1);
>> }
> This seems like a strange place for the change. It feels more like
> init_task has been defined incorrectly.
The init_task will put into init_stack when ARCH_TASK_STRUCT_ON_STACK is
selected.
include/asm-generic/vmlinux.lds.h:
#define INIT_TASK_DATA(align)\
. = ALIGN(align);\
__start_init_task = .;\
init_thread_union = .;\
init_stack = .;\
KEEP(*(.data..init_task))\
KEEP(*(.data..init_thread_info))\
. = __start_init_task + THREAD_SIZE;\
__end_init_task = .;
So we need end_of_stack to offset sizeof(task_struct).
Cheers,
Dongsheng
Re: linux-next: Tree for Nov 27 (scsi/aha1542)
Hi all,
On Tue, 27 Nov 2018 20:14:58 -0800 Randy Dunlap wrote:
>
> On 11/26/18 8:25 PM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20181126:
> >
>
> on i386:
>
> ERROR: "__udivdi3" [drivers/scsi/aha1542.ko] undefined!
>
> somewhere in aha1542_interrupt() according to objdump.
Presumably caused by commit
1794ef2b150d ("scsi: aha1542: convert to DMA mapping API")
--
Cheers,
Stephen Rothwell
pgpgKdyluUPkw.pgp
Description: OpenPGP digital signature
[PATCH v2 3/3] dt-bindings: reset: imx7: Document usage on i.MX8MQ SoCs
The driver now supports i.MX8MQ, so update bindings accordingly. Cc: p.za...@pengutronix.de Cc: Fabio Estevam Cc: cphe...@gmail.com Cc: l.st...@pengutronix.de Cc: Leonard Crestez Cc: "A.s. Dong" Cc: Richard Zhu Cc: Rob Herring Cc: devicet...@vger.kernel.org Cc: linux-...@nxp.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Andrey Smirnov --- Documentation/devicetree/bindings/reset/fsl,imx7-src.txt | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/reset/fsl,imx7-src.txt b/Documentation/devicetree/bindings/reset/fsl,imx7-src.txt index 1ab1d109318e..2ecf33815d18 100644 --- a/Documentation/devicetree/bindings/reset/fsl,imx7-src.txt +++ b/Documentation/devicetree/bindings/reset/fsl,imx7-src.txt @@ -5,7 +5,9 @@ Please also refer to reset.txt in this directory for common reset controller binding usage. Required properties: -- compatible: Should be "fsl,imx7d-src", "syscon" +- compatible: + - For i.MX7 SoCs should be "fsl,imx7d-src", "syscon" + - For i.MX8MQ SoCs should be "fsl,imx8mq-src", "syscon" - reg: should be register base and length as documented in the datasheet - interrupts: Should contain SRC interrupt @@ -44,4 +46,5 @@ Example: For list of all valid reset indicies see - + for i.MX7 and + for i.MX8MQ -- 2.19.1
[PATCH v2 2/3] reset: imx7: Add support for i.MX8MQ IP block variant
Add bits and pieces needed to support IP block variant found on
i.MX8MQ SoCs.
Cc: p.za...@pengutronix.de
Cc: Fabio Estevam
Cc: cphe...@gmail.com
Cc: l.st...@pengutronix.de
Cc: Leonard Crestez
Cc: "A.s. Dong"
Cc: Richard Zhu
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov
---
drivers/reset/Kconfig| 2 +-
drivers/reset/reset-imx7.c | 106 +++
include/dt-bindings/reset/imx8mq-reset.h | 64 ++
3 files changed, 171 insertions(+), 1 deletion(-)
create mode 100644 include/dt-bindings/reset/imx8mq-reset.h
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index c21da9fe51ec..4909aab7401b 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -50,7 +50,7 @@ config RESET_HSDK
config RESET_IMX7
bool "i.MX7 Reset Driver" if COMPILE_TEST
depends on HAS_IOMEM
- default SOC_IMX7D
+ default SOC_IMX7D || SOC_IMX8MQ
select MFD_SYSCON
help
This enables the reset controller driver for i.MX7 SoCs.
diff --git a/drivers/reset/reset-imx7.c b/drivers/reset/reset-imx7.c
index cfbb6346a72e..34ce7448b299 100644
--- a/drivers/reset/reset-imx7.c
+++ b/drivers/reset/reset-imx7.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
struct imx7_src_signal {
unsigned int offset, bit;
@@ -113,6 +114,110 @@ static const struct imx7_src_variant variant_imx7 = {
.prepare = imx7_src_prepare,
};
+enum imx8mq_src_registers {
+ SRC_A53RCR0 = 0x0004,
+ SRC_HDMI_RCR= 0x0030,
+ SRC_DISP_RCR= 0x0034,
+ SRC_GPU_RCR = 0x0040,
+ SRC_VPU_RCR = 0x0044,
+ SRC_PCIE2_RCR = 0x0048,
+ SRC_MIPIPHY1_RCR= 0x004c,
+ SRC_MIPIPHY2_RCR= 0x0050,
+ SRC_DDRC2_RCR = 0x1004,
+};
+
+static const struct imx7_src_signal imx8mq_src_signals[IMX8MQ_RESET_NUM] = {
+ [IMX8MQ_RESET_A53_CORE_POR_RESET0] = { SRC_A53RCR0, BIT(0) },
+ [IMX8MQ_RESET_A53_CORE_POR_RESET1] = { SRC_A53RCR0, BIT(1) },
+ [IMX8MQ_RESET_A53_CORE_POR_RESET2] = { SRC_A53RCR0, BIT(2) },
+ [IMX8MQ_RESET_A53_CORE_POR_RESET3] = { SRC_A53RCR0, BIT(3) },
+ [IMX8MQ_RESET_A53_CORE_RESET0] = { SRC_A53RCR0, BIT(4) },
+ [IMX8MQ_RESET_A53_CORE_RESET1] = { SRC_A53RCR0, BIT(5) },
+ [IMX8MQ_RESET_A53_CORE_RESET2] = { SRC_A53RCR0, BIT(6) },
+ [IMX8MQ_RESET_A53_CORE_RESET3] = { SRC_A53RCR0, BIT(7) },
+ [IMX8MQ_RESET_A53_DBG_RESET0] = { SRC_A53RCR0, BIT(8) },
+ [IMX8MQ_RESET_A53_DBG_RESET1] = { SRC_A53RCR0, BIT(9) },
+ [IMX8MQ_RESET_A53_DBG_RESET2] = { SRC_A53RCR0, BIT(10) },
+ [IMX8MQ_RESET_A53_DBG_RESET3] = { SRC_A53RCR0, BIT(11) },
+ [IMX8MQ_RESET_A53_ETM_RESET0] = { SRC_A53RCR0, BIT(12) },
+ [IMX8MQ_RESET_A53_ETM_RESET1] = { SRC_A53RCR0, BIT(13) },
+ [IMX8MQ_RESET_A53_ETM_RESET2] = { SRC_A53RCR0, BIT(14) },
+ [IMX8MQ_RESET_A53_ETM_RESET3] = { SRC_A53RCR0, BIT(15) },
+ [IMX8MQ_RESET_A53_SOC_DBG_RESET]= { SRC_A53RCR0, BIT(20) },
+ [IMX8MQ_RESET_A53_L2RESET] = { SRC_A53RCR0, BIT(21) },
+ [IMX8MQ_RESET_SW_NON_SCLR_M4C_RST] = { SRC_M4RCR, BIT(0) },
+ [IMX8MQ_RESET_OTG1_PHY_RESET] = { SRC_USBOPHY1_RCR, BIT(0) },
+ [IMX8MQ_RESET_OTG2_PHY_RESET] = { SRC_USBOPHY2_RCR, BIT(0) },
+ [IMX8MQ_RESET_MIPI_DSI_RESET_BYTE_N]= { SRC_MIPIPHY_RCR, BIT(1) },
+ [IMX8MQ_RESET_MIPI_DSI_RESET_N] = { SRC_MIPIPHY_RCR, BIT(2) },
+ [IMX8MQ_RESET_MIPI_DIS_DPI_RESET_N] = { SRC_MIPIPHY_RCR, BIT(3) },
+ [IMX8MQ_RESET_MIPI_DIS_ESC_RESET_N] = { SRC_MIPIPHY_RCR, BIT(4) },
+ [IMX8MQ_RESET_MIPI_DIS_PCLK_RESET_N]= { SRC_MIPIPHY_RCR, BIT(5) },
+ [IMX8MQ_RESET_PCIEPHY] = { SRC_PCIEPHY_RCR,
+ BIT(2) | BIT(1) },
+ [IMX8MQ_RESET_PCIEPHY_PERST]= { SRC_PCIEPHY_RCR, BIT(3) },
+ [IMX8MQ_RESET_PCIE_CTRL_APPS_EN]= { SRC_PCIEPHY_RCR, BIT(6) },
+ [IMX8MQ_RESET_PCIE_CTRL_APPS_TURNOFF] = { SRC_PCIEPHY_RCR, BIT(11) },
+ [IMX8MQ_RESET_HDMI_PHY_APB_RESET] = { SRC_HDMI_RCR, BIT(0) },
+ [IMX8MQ_RESET_DISP_RESET] = { SRC_DISP_RCR, BIT(0) },
+ [IMX8MQ_RESET_GPU_RESET]= { SRC_GPU_RCR, BIT(0) },
+ [IMX8MQ_RESET_VPU_RESET]= { SRC_VPU_RCR, BIT(0) },
+ [IMX8MQ_RESET_PCIEPHY2] = { SRC_PCIE2_RCR,
+ BIT(2) | BIT(1) },
+ [IMX8MQ_RESET_PCIEPHY2_PERST] = { SRC_PCIE2_RCR, BIT(3) },
+ [IMX8MQ_RESET_PCIE2_CTRL_APPS_EN]
[PATCH v2 1/3] reset: imx7: Add plubming to support multiple IP variants
In order to enable supporting i.MX8MQ with this driver, convert it to
expect variant specific bits to be passed via driver data.
Cc: p.za...@pengutronix.de
Cc: Fabio Estevam
Cc: cphe...@gmail.com
Cc: l.st...@pengutronix.de
Cc: Leonard Crestez
Cc: "A.s. Dong"
Cc: Richard Zhu
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov
---
drivers/reset/reset-imx7.c | 62 +++---
1 file changed, 45 insertions(+), 17 deletions(-)
diff --git a/drivers/reset/reset-imx7.c b/drivers/reset/reset-imx7.c
index 77911fa8f31d..cfbb6346a72e 100644
--- a/drivers/reset/reset-imx7.c
+++ b/drivers/reset/reset-imx7.c
@@ -17,14 +17,29 @@
#include
#include
+#include
#include
#include
#include
#include
+struct imx7_src_signal {
+ unsigned int offset, bit;
+};
+
+struct imx7_src;
+
+struct imx7_src_variant {
+ const struct imx7_src_signal *signals;
+ unsigned int signals_num;
+ unsigned int (*prepare)(struct imx7_src *imx7src, unsigned long id,
+ bool assert);
+};
+
struct imx7_src {
struct reset_controller_dev rcdev;
struct regmap *regmap;
+ struct imx7_src_variant *variant;
};
enum imx7_src_registers {
@@ -39,10 +54,6 @@ enum imx7_src_registers {
SRC_DDRC_RCR= 0x1000,
};
-struct imx7_src_signal {
- unsigned int offset, bit;
-};
-
static const struct imx7_src_signal imx7_src_signals[IMX7_RESET_NUM] = {
[IMX7_RESET_A7_CORE_POR_RESET0] = { SRC_A7RCR0, BIT(0) },
[IMX7_RESET_A7_CORE_POR_RESET1] = { SRC_A7RCR0, BIT(1) },
@@ -72,17 +83,11 @@ static const struct imx7_src_signal
imx7_src_signals[IMX7_RESET_NUM] = {
[IMX7_RESET_DDRC_CORE_RST] = { SRC_DDRC_RCR, BIT(1) },
};
-static struct imx7_src *to_imx7_src(struct reset_controller_dev *rcdev)
+static unsigned int
+imx7_src_prepare(struct imx7_src *imx7src, unsigned long id, bool assert)
{
- return container_of(rcdev, struct imx7_src, rcdev);
-}
-
-static int imx7_reset_set(struct reset_controller_dev *rcdev,
- unsigned long id, bool assert)
-{
- struct imx7_src *imx7src = to_imx7_src(rcdev);
- const struct imx7_src_signal *signal = &imx7_src_signals[id];
- unsigned int value = assert ? signal->bit : 0;
+ const unsigned int bit = imx7src->variant->signals[id].bit;
+ unsigned int value = assert ? bit : 0;
switch (id) {
case IMX7_RESET_PCIEPHY:
@@ -95,10 +100,32 @@ static int imx7_reset_set(struct reset_controller_dev
*rcdev,
break;
case IMX7_RESET_PCIE_CTRL_APPS_EN:
- value = (assert) ? 0 : signal->bit;
+ value = assert ? 0 : bit;
break;
}
+ return value;
+}
+
+static const struct imx7_src_variant variant_imx7 = {
+ .signals = imx7_src_signals,
+ .signals_num = ARRAY_SIZE(imx7_src_signals),
+ .prepare = imx7_src_prepare,
+};
+
+static struct imx7_src *to_imx7_src(struct reset_controller_dev *rcdev)
+{
+ return container_of(rcdev, struct imx7_src, rcdev);
+}
+
+static int imx7_reset_set(struct reset_controller_dev *rcdev,
+ unsigned long id, bool assert)
+{
+ struct imx7_src *imx7src = to_imx7_src(rcdev);
+ const struct imx7_src_variant *variant = imx7src->variant;
+ const struct imx7_src_signal *signal = &variant->signals[id];
+ const unsigned int value = variant->prepare(imx7src, id, assert);
+
return regmap_update_bits(imx7src->regmap,
signal->offset, signal->bit, value);
}
@@ -130,6 +157,7 @@ static int imx7_reset_probe(struct platform_device *pdev)
if (!imx7src)
return -ENOMEM;
+ imx7src->variant = of_device_get_match_data(dev);
imx7src->regmap = syscon_node_to_regmap(dev->of_node);
if (IS_ERR(imx7src->regmap)) {
dev_err(dev, "Unable to get imx7-src regmap");
@@ -138,7 +166,7 @@ static int imx7_reset_probe(struct platform_device *pdev)
regmap_attach_dev(dev, imx7src->regmap, &config);
imx7src->rcdev.owner = THIS_MODULE;
- imx7src->rcdev.nr_resets = IMX7_RESET_NUM;
+ imx7src->rcdev.nr_resets = imx7src->variant->signals_num;
imx7src->rcdev.ops = &imx7_reset_ops;
imx7src->rcdev.of_node = dev->of_node;
@@ -146,7 +174,7 @@ static int imx7_reset_probe(struct platform_device *pdev)
}
static const struct of_device_id imx7_reset_dt_ids[] = {
- { .compatible = "fsl,imx7d-src", },
+ { .compatible = "fsl,imx7d-src", .data = &variant_imx7 },
{ /* sentinel */ },
};
--
2.19.1
[PATCH v2 0/3] Reset controller support for i.MX8MQ
Everyone: This patch contains changes I made in order to add support for i.MX8MQ to reset-imx7.c in order to enable support of PCIE IP block on i.MX8MQ SoCs (full tree can be found at [github-v1]). NOTE: This patch depens on CONFIG_ARCH_IMX8MQ introduced in [imx8mq] Feedback is welcome! Thanks, Andrey Smirnov Changes since [v1] - Series re-written to use a per-variant LUT instead of using a single table - Changed driver to use "imx8mq" insead of "imx8m" to match other drivers and CONFIG_ARCH_IMX8MQ - Updated list of exported i.MX8MQ resets, add missing and remove bogus ones (hopefully nothing is missing this time) [v1] lkml.kernel.org/r/20181117181131.9330-2-andrew.smir...@gmail.com [github-v1] https://github.com/ndreys/linux/commits/imx8mq-pcie-v1 [imx8mq] https://www.spinics.net/lists/arm-kernel/msg687293.html Andrey Smirnov (3): reset: imx7: Add plubming to support multiple IP variants reset: imx7: Add support for i.MX8MQ IP block variant dt-bindings: reset: imx7: Document usage on i.MX8MQ SoCs .../bindings/reset/fsl,imx7-src.txt | 7 +- drivers/reset/Kconfig | 2 +- drivers/reset/reset-imx7.c| 166 -- include/dt-bindings/reset/imx8mq-reset.h | 64 +++ 4 files changed, 220 insertions(+), 19 deletions(-) create mode 100644 include/dt-bindings/reset/imx8mq-reset.h -- 2.19.1
RE: [PATCH] PCI: Mark NXP LS1088 to avoid bus reset bus
Hi,
> -Original Message-
> From: Alex Williamson
> Sent: Tuesday, November 27, 2018 9:39 PM
> To: Bjorn Helgaas
> Cc: Bharat Bhushan ; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; bharatb.ya...@gmail.com; David Daney
> ; Jan Glauber ; Maik
> Broemme ; Chris Blake
>
> Subject: Re: [PATCH] PCI: Mark NXP LS1088 to avoid bus reset bus
>
> On Tue, 27 Nov 2018 09:33:56 -0600
> Bjorn Helgaas wrote:
>
> > [+cc David, Jan, Alex, Maik, Chris]
> >
> > On Tue, Nov 27, 2018 at 08:46:33AM +, Bharat Bhushan wrote:
> > > NXP (Freescale Vendor ID) LS1088 chips do not behave correctly after
> > > bus reset with e1000e. Link state of device does not comes UP and so
> > > config space never accessible again.
> >
> > Previous similar commits:
> >
> > 822155100e58 ("PCI: Mark Cavium CN8xxx to avoid bus reset")
> > 8e2e03179923 ("PCI: Mark Atheros AR9580 to avoid bus reset")
> > 9ac0108c2bac ("PCI: Mark Atheros AR9485 and QCA9882 to avoid bus
> reset")
> > c3e59ee4e766 ("PCI: Mark Atheros AR93xx to avoid bus reset")
> >
> > 1) Please make your subject match (remove the spurious "bus" at the
> > end)
Will correct, added by mistake
> >
> > 2) This should probably be marked for stable (v3.14 and later, since
> > the quirk itself appeared in v3.19 and marked for v3.14 and later
> > stable kernels). Maybe even mark it as "Fixes: c3e59ee4e766..." to
> > connect it.
Ok,
> >
> > 3) The 1957:80c0 PCI ID doesn't appear in
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpci
> -
> ids.ucw.cz%2F&data=02%7C01%7Cbharat.bhushan%40nxp.com%7C296
> 02a2efa584249221808d65482945b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7
> C0%7C0%7C636789317139032063&sdata=3jkRMa1NljSCp%2BvZP0kgz7D
> PWPJZH8d7JXhCE5vCCMk%3D&reserved=0; can you add it?
> >
Yes, I will add
> > 4) Is there a hardware erratum for this? If so, please include the
> > URL here.
No h/w errata as of now.
> >
> > 5) Can you reproduce the problem using the same endpoint (e1000e) on a
> > different system with a different bridge?
I have multiple LS1088 boards and I can observe problem with all LS1088 boards.
While when I uses same PCI device on other NXP board (LS2088) then it works
fine.
> >
> > 6) Have you looked at this with a PCIe analyzer? It would be very
> > interesting to compare the boot-time or system reboot path with the
> > individual bus reset path you're fixing.
I have not used PCIe analyzer,
> >
> > Since there are several similar reports and they sometimes involve the
> > same devices (both your patch and 822155100e58 mention e1000e), I'm a
> > little suspicious that we're doing something wrong in the bus reset
> > path.
>
> I agree, entirely excluding bus resets is not something to be taken lightly.
> It's
> less than ideal for an endpoint and a fairly major functional gap for a
> downstream port. It should really be considered a last resort.
>
> > I think bus reset uses Secondary Bus Reset in the Bridge Control
> > register. That's a generic mechanism that I would expect to be pretty
> > well-tested. I suspect the BIOS probably uses it in the reboot path,
> > and the device probably works after that.
> >
> > So I wonder if the Linux delay isn't quite long enough, or our first
> > access to the device isn't quite right, e.g., maybe there's some issue
> > with the bus/device number capture (PCIe r4.0, sec 2.2.6.2).
>
> Tweaking the delay would be a reasonable solution, though we are seeing
> some issues where users with lots of assigned devices that require bus
> resets experience long delays as vfio file descriptors are closed sequentially
> on exit.
In pci_reset_secondary_bus() I have tried to increase the delay after reset but
not helped.
Do I need to add delay at some other place as well?
Thanks
-Bharat
> So perhaps we could flag downstream ports requiring an extra delay,
> if that becomes a solution. Your mention of the bus/device number also
> reminds me of the issue we saw on Threadripper where there were patches
> proposed to re-write the secondary and subordinate bus numbers after
> reset. AMD was able to resolve that in a firmware update, but there could
> be something similar occurring here. Thanks,
>
> Alex
>
> > > Signed-off-by: Bharat Bhushan
> > > ---
> > > drivers/pci/quirks.c | 7 +++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index
> > > 4700d24e5d55..b9ae4e9f101a 100644
> > > --- a/drivers/pci/quirks.c
> > > +++ b/drivers/pci/quirks.c
> > > @@ -3391,6 +3391,13 @@
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0033,
> quirk_no_bus_reset);
> > > */
> > > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_CAVIUM, 0xa100,
> > > quirk_no_bus_reset);
> > >
> > > +/*
> > > + * NXP (Freescale Vendor ID) LS1088 chips do not behave correctly
> > > +after
> > > + * bus reset. Link state of device does not comes UP and so config
> > > +space
> > > + * never accessible again.
> > > + */
> > > +DECLARE_PCI_FIXUP
[PATCH 25/41] scsi: lpfc: lpfc_nportdisc: Mark expected switch fall-through
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Gustavo A. R. Silva --- drivers/scsi/lpfc/lpfc_nportdisc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/lpfc/lpfc_nportdisc.c b/drivers/scsi/lpfc/lpfc_nportdisc.c index 7d5693cfaa87..e8583496feaf 100644 --- a/drivers/scsi/lpfc/lpfc_nportdisc.c +++ b/drivers/scsi/lpfc/lpfc_nportdisc.c @@ -360,6 +360,7 @@ lpfc_rcv_plogi(struct lpfc_vport *vport, struct lpfc_nodelist *ndlp, case NLP_STE_NPR_NODE: if (!(ndlp->nlp_flag & NLP_NPR_ADISC)) break; + /* fall through */ case NLP_STE_REG_LOGIN_ISSUE: case NLP_STE_PRLI_ISSUE: case NLP_STE_UNMAPPED_NODE: -- 2.17.1
Re: [PATCH v2 00/15] ARM: sunxi: Enable Broadcom-based Bluetooth controllers
Hi, On Thu, Nov 15, 2018 at 5:36 PM Chen-Yu Tsai wrote: > > Hi everyone, > > This is v2 of my Broadcom-based Bluetooth controllers on Allwinner SoC- > based SBCs series. > > Changes since v1: > > - Collected tags > - Re-organize dt binding clocks and clock-names properties > - Simplify check for deferred probe when getting clocks > - Add explanation of Cubietruck's clk_out_a pinmux setting placement > to commit message. > - Add missing "uart-has-rtscts" property to Cubietruck device tree > > Original cover letter follows. > > > On many Allwinner SBCs / developer boards, there is a WiFi+BT combo > module from AMPAK. Inside is either one or two Broadcom chips, depending > on the model. This series enables the Bluetooth controllers for AMPAK > AP6210, AP6212, and AP6330 found on several boards. More will come later > as other SoCs require changes to some other parts. I did not cover the > SCO PCM connections from the controller to the SoC's I2S interface. It > seems no one is actually doing this, so I was not sure how to proceed. > Any suggestions? > > I deliberately left out the netdev mailing list and Dave Miller, as the > only thing that is under net is the binding document. Maybe we should > move that out of Documentation/devicetree/bindings/net/ ? > > Also, I'm not subscribed to the linux-bluetooth ML, so please CC me for > any discussions. > > Patches 1 through 4 are device tree binding changes: > > 1 - Make the external clock name unambiguous, and add a second entry for > the LPO clock. > > 2 - Add regulator supply properties for the VBAT and VDDIO power pins. > > 3 - Add a compatible string for BCM20702A1. > > 4 - Add a compatible string for BCM4330. > > Patches 5 through 13 are changes to the driver, either improvements, > or updates to handle the updated device tree binding. > > 5 - Make the driver handle deferred probing for the external clock. > > 6 - Simplify clock error checking for subsequent clk API calls. > > 7 - Handle clock-names for the main external clock. > > 8 - Support a new external clock, the LPO. > > 9 - Support regulator supplies. > > 10 - Wait a small amount of time after toggling the GPIO for the device > to settle. > > 11 - Add support for BCM20702A1, including its default address. > > 12 - Add BCM4330 compatible string to the driver. > > 13 - Handle default address for BCM43430A0. > > 14 - Enable Broadcom-based serdev Bluetooth for multiple Allwinner ARMv7 > boards. > > 15 - Enable Broadcom-based serdev Bluetooth for the Bananapi M64. > > checkpatch reports an error for both patch 11 and patch 13: > > ERROR: space required after that close brace '}' > > I followed the existing code's style. If this is undesirable, I can send > a follow-up patch fixing the entire code block. > > The first 13 patches should go through the Bluetooth tree, while we, the > sunxi maintainers, will take the last 2. It's been close to two weeks. Any comments or concerns from the Bluetooth maintainers? I'd like to see this in 4.22 if possible. Thanks ChenYu > Thanks > ChenYu > > Chen-Yu Tsai (14): > dt-bindings: net: broadcom-bluetooth: Fix external clock names > dt-bindings: net: broadcom-bluetooth: Add VBAT and VDDIO supplies > dt-bindings: net: broadcom-bluetooth: Add BCM20702A1 compatible string > dt-bindings: net: broadcom-bluetooth: Add BCM4330 compatible string > Bluetooth: hci_bcm: Handle deferred probing for the clock supply > Bluetooth: hci_bcm: Simplify clk_get error handling > Bluetooth: hci_bcm: Use "txco" and "extclk" to get clock reference > Bluetooth: hci_bcm: Add support for LPO clock > Bluetooth: hci_bcm: Add support for regulator supplies > Bluetooth: hci_bcm: Wait for device to come out of reset after power > on > Bluetooth: hci_bcm: Add compatible string for BCM4330 > Bluetooth: btbcm: Add default address for BCM43430A0 > ARM: dts: sunxi: Enable Broadcom-based Bluetooth for multiple boards > arm64: dts: allwinner: a64: bananapi-m64: Add Bluetooth device node > > Maxime Ripard (1): > Bluetooth: hci_bcm: Add BCM20702A1 variant > > .../bindings/net/broadcom-bluetooth.txt | 11 +- > arch/arm/boot/dts/sun7i-a20-cubietruck.dts| 23 > arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 18 +++ > .../boot/dts/sun8i-a83t-cubietruck-plus.dts | 18 +++ > arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts | 14 +++ > .../dts/allwinner/sun50i-a64-bananapi-m64.dts | 14 +++ > drivers/bluetooth/btbcm.c | 13 +- > drivers/bluetooth/hci_bcm.c | 112 +++--- > 8 files changed, 206 insertions(+), 17 deletions(-) > > -- > 2.19.1 >
Re: [PATCH] Small typo fix
> On Nov 27, 2018, at 2:04 PM, Emre Ates wrote:
>
> ---
> mm/vmstat.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/vmstat.c b/mm/vmstat.c
> index 9c624595e904..cc7d04928c2e 100644
> --- a/mm/vmstat.c
> +++ b/mm/vmstat.c
> @@ -1106,7 +1106,7 @@ int fragmentation_index(struct zone *zone, unsigned int
> order)
> TEXT_FOR_HIGHMEM(xx) xx "_movable",
>
> const char * const vmstat_text[] = {
> - /* enum zone_stat_item countes */
> + /* enum zone_stat_item counters */
> "nr_free_pages",
> "nr_zone_inactive_anon",
> "nr_zone_active_anon",
> --
> 2.19.1
>
> Signed-off-by: Emre Ates
Reviewed-by: William Kucharski
Re: kmemleak: Early log buffer exceeded (525980) during boot
On 11/10/18 11:59 AM, Catalin Marinas wrote: > On Sat, Nov 10, 2018 at 10:08:10AM -0500, Qian Cai wrote: >> On Nov 8, 2018, at 4:23 PM, Qian Cai wrote: >>> The maximum value for DEBUG_KMEMLEAK_EARLY_LOG_SIZE is only 4, so it >>> disables kmemleak every time on this aarch64 server running the latest >>> mainline >>> (b00d209). >>> >>> # echo scan > /sys/kernel/debug/kmemleak >>> -bash: echo: write error: Device or resource busy >>> >>> Any idea on how to enable kmemleak there? >> >> I have managed to hard-code DEBUG_KMEMLEAK_EARLY_LOG_SIZE to 60, > > That's quite a high number, I wouldn't have thought it is needed. > Basically the early log buffer is only used until the slub allocator > gets initialised and kmemleak_init() is called from start_kernel(). I > don't know what allocates that much memory so early. > It turned out that kmemleak does not play well with KASAN on those aarch64 (HPE Apollo 70 and Huawei TaiShan 2280) servers. After calling start_kernel()->setup_arch()->kasan_init(), kmemleak early log buffer went from something like from 280 to 26. The multitude of kmemleak_alloc() calls is, for_each_memblock(memory, reg) x \ while (pgdp++, addr = next, addr != end) x \ while (ptep++, addr = next, addr != end && \ pte_none(READ_ONCE(*ptep))) Is this expected?
Re: ext4 file system corruption with v4.19.3 / v4.19.4
On Wed, Nov 28, 2018 at 03:16:33AM +0300, Andrey Jr. Melnikov wrote: > Corrupted inodes - always directory, not touched at least year or > more for writing. Something wrong when updating atime? We're not sure. The frustrating thing is that it's not reproducing for me. I run extensive regression tests, and I'm using 4.19 on my development laptop without notcing any problems. If I could reproduce it, I could debug it, but since I can't, I need to rely on those who are seeing the problem to help pinpoint the problem. I'm trying to figure out common factors from those people who are reporting problems. (a) What distribution are you running (it appears that many people reporting problems are running Ubuntu, but this may be a sampling issue; lots of people run Ubuntu)? (For the record, I'm using Debian Testing.) (b) What hardware are you using? (SSD? SATA-attached? NVMe-attached?) (c) Are you using LVM? LUKS (e.g., disk encrypted)? (d) are you using discard? One theory is a recent discard change may be in play. How do you use discard? (mount option, fstrim, etc.) - Ted
Re: [PATCH] lzo: fix ip overrun during compress.
Hi Yueyi, On Tue, Nov 27, 2018 at 10:34:26AM +, Yueyi Li wrote: > It`s possible ip overrun in lzo1x_1_do_compress() when compressed page is > point to the end of memory and which virtual address is 0xf000. > Leading to a NULL pointer access during the get_unaligned_le32(ip). Thanks for this report. (...) > diff --git a/lib/lzo/lzo1x_compress.c b/lib/lzo/lzo1x_compress.c > index 236eb21..a0265a6 100644 > --- a/lib/lzo/lzo1x_compress.c > +++ b/lib/lzo/lzo1x_compress.c > @@ -17,6 +17,9 @@ > #include > #include "lzodefs.h" > > +#define OVERFLOW_ADD_CHECK(a, b) \ > + ((size_t)~0 - (size_t)(a) < (size_t)(b) ? true : false) > + I think the test would be easier to grasp this way : #define OVERFLOW_ADD_CHECK(a, b) \ ((size_t)(b) >= (size_t)((void*)0 - (void *)(a))) But the following should be more efficient since we build with -fno-strict-overflow : #define OVERFLOW_ADD_CHECK(a, b) \ (((a) + (b)) < (a)) Could you please recheck ? Thanks, Willy
[PATCH v4 2/2] PCI: uniphier: Add UniPhier PCIe host controller support
This introduces specific glue layer for UniPhier platform to support
PCIe host controller that is based on the DesignWare PCIe core, and
this driver supports Root Complex (host) mode.
Signed-off-by: Kunihiko Hayashi
---
MAINTAINERS| 7 +
drivers/pci/controller/dwc/Kconfig | 10 +
drivers/pci/controller/dwc/Makefile| 1 +
drivers/pci/controller/dwc/pcie-uniphier.c | 471 +
4 files changed, 489 insertions(+)
create mode 100644 drivers/pci/controller/dwc/pcie-uniphier.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 23725d4..c0e15ec 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11653,6 +11653,13 @@ S: Maintained
F: Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt
F: drivers/pci/controller/pci-v3-semi.c
+PCIE DRIVER FOR SOCIONEXT UNIPHIER
+M: Kunihiko Hayashi
+L: linux-...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/pci/uniphier-pcie.txt
+F: drivers/pci/controller/dwc/pcie-uniphier.c
+
PCIE DRIVER FOR ST SPEAR13XX
M: Pratyush Anand
L: linux-...@vger.kernel.org
diff --git a/drivers/pci/controller/dwc/Kconfig
b/drivers/pci/controller/dwc/Kconfig
index 91b0194..9550688 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -193,4 +193,14 @@ config PCIE_HISI_STB
help
Say Y here if you want PCIe controller support on HiSilicon STB SoCs
+config PCIE_UNIPHIER
+ bool "Socionext UniPhier PCIe controllers"
+ depends on ARCH_UNIPHIER || COMPILE_TEST
+ depends on OF && HAS_IOMEM
+ depends on PCI_MSI_IRQ_DOMAIN
+ select PCIE_DW_HOST
+ help
+ Say Y here if you want PCIe controller support on UniPhier SoCs.
+ This driver supports LD20 and PXs3 SoCs.
+
endmenu
diff --git a/drivers/pci/controller/dwc/Makefile
b/drivers/pci/controller/dwc/Makefile
index fcf91ea..688a0ec 100644
--- a/drivers/pci/controller/dwc/Makefile
+++ b/drivers/pci/controller/dwc/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o
obj-$(CONFIG_PCIE_KIRIN) += pcie-kirin.o
obj-$(CONFIG_PCIE_HISI_STB) += pcie-histb.o
+obj-$(CONFIG_PCIE_UNIPHIER) += pcie-uniphier.o
# The following drivers are for devices that use the generic ACPI
# pci_root.c driver but don't support standard ECAM config access.
diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c
b/drivers/pci/controller/dwc/pcie-uniphier.c
new file mode 100644
index 000..e93bde4
--- /dev/null
+++ b/drivers/pci/controller/dwc/pcie-uniphier.c
@@ -0,0 +1,471 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PCIe host controller driver for UniPhier SoCs
+ * Copyright 2018 Socionext Inc.
+ * Author: Kunihiko Hayashi
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "pcie-designware.h"
+
+#define PCL_PINCTRL0 0x002c
+#define PCL_PERST_PLDN_REGEN BIT(12)
+#define PCL_PERST_NOE_REGENBIT(11)
+#define PCL_PERST_OUT_REGENBIT(8)
+#define PCL_PERST_PLDN_REGVAL BIT(4)
+#define PCL_PERST_NOE_REGVAL BIT(3)
+#define PCL_PERST_OUT_REGVAL BIT(0)
+
+#define PCL_PIPEMON0x0044
+#define PCL_PCLK_ALIVE BIT(15)
+
+#define PCL_APP_READY_CTRL 0x8008
+#define PCL_APP_LTSSM_ENABLE BIT(0)
+
+#define PCL_APP_PM00x8078
+#define PCL_SYS_AUX_PWR_DETBIT(8)
+
+#define PCL_RCV_INT0x8108
+#define PCL_RCV_INT_ALL_ENABLE GENMASK(20, 17)
+#define PCL_CFG_BW_MGT_STATUS BIT(4)
+#define PCL_CFG_LINK_AUTO_BW_STATUSBIT(3)
+#define PCL_CFG_AER_RC_ERR_MSI_STATUS BIT(2)
+#define PCL_CFG_PME_MSI_STATUS BIT(1)
+
+#define PCL_RCV_INTX 0x810c
+#define PCL_RCV_INTX_ALL_ENABLEGENMASK(19, 16)
+#define PCL_RCV_INTX_ALL_MASK GENMASK(11, 8)
+#define PCL_RCV_INTX_MASK_SHIFT8
+#define PCL_RCV_INTX_ALL_STATUSGENMASK(3, 0)
+#define PCL_RCV_INTX_STATUS_SHIFT 0
+
+#define PCL_STATUS_LINK0x8140
+#define PCL_RDLH_LINK_UP BIT(1)
+#define PCL_XMLH_LINK_UP BIT(0)
+
+struct uniphier_pcie_priv {
+ void __iomem *base;
+ struct dw_pcie pci;
+ struct clk *clk;
+ struct reset_control *rst;
+ struct phy *phy;
+ struct irq_domain *legacy_irq_domain;
+};
+
+#define to_uniphier_pcie(x)dev_get_drvdata((x)->dev)
+
+static void uniphier_pcie_ltssm_enable(struct uniphier_pcie_priv *priv,
+ bool enable)
+{
+ u32 val;
+
+ val = readl(priv->base + PCL_APP_READY_CTRL);
+ if (enable)
+ val |= PCL_APP_LTSSM_ENABLE;
+ else
+ val &= ~PCL_APP_LTSSM_ENA
[PATCH v4 0/2] Add new UniPhier PCIe host driver
This series adds PCIe host controller driver for Socionext UniPhier SoCs. This controller is based on the DesignWare PCIe core. This driver supports LD20 and PXs3 SoCs. v3: https://www.spinics.net/lists/linux-pci/msg77224.html About legacy IRQ, it might be necessary to share common view from keystone driver that have been cleaned up[1]. [1] https://lore.kernel.org/patchwork/patch/989541/ Changes since v3: - dt-bindings: fix INTX numbering of legacy interrupt map - change interrupts to level ones - remove .xlate function - merge uniphier_pcie_ltssm_disable() into uniphier_pcie_ltssm_enable() - remove an error message on uniphier_pcie_establish_link() - change the order between irq_domain_add_liniear() and irq_set_chained_handler_and_data() - replace dummy_irq_chip with uniphier_pcie_irq_chip and its functions - add dependency on CONFIG_HAS_IOMEM - MAINTAINERS: add pcie-uniphier entry Changes since v2: - dt-bindings: remove a comment that the node name isn't important - dt-bindings: remove "intx" interrupt - dt-bindings: define 'legacy-interrupt-controller' node and its properties - return an error value when link up fails - remove devm_request_irq() and a handler for MSI IRQ - use chained interrupt instead of devm_request_irq() for legacy IRQ - add unipher_pcie_config_legacy_irq() to get legacy IRQ from 'legacy-interrupt controller' node - replace 4 statments to handle INTX with for_each_set_bit() - remove initialization of pp->root_bus_nr - remove indivisual interrupt enable bit definitions - rename 'irq_domain' member to 'legacy_irq_domain' in private structure - use pci_irqd_intx_xlate() for irq_domain_ops.xlate function Changes since v1: - follow capitalization conventions in the descriptions - use C style comments except for the SPDX line Kunihiko Hayashi (2): dt-bindings: PCI: Add UniPhier PCIe host controller description PCI: uniphier: Add UniPhier PCIe host controller support .../devicetree/bindings/pci/uniphier-pcie.txt | 81 MAINTAINERS| 7 + drivers/pci/controller/dwc/Kconfig | 10 + drivers/pci/controller/dwc/Makefile| 1 + drivers/pci/controller/dwc/pcie-uniphier.c | 471 + 5 files changed, 570 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/uniphier-pcie.txt create mode 100644 drivers/pci/controller/dwc/pcie-uniphier.c -- 2.7.4
[PATCH v4 1/2] dt-bindings: PCI: Add UniPhier PCIe host controller description
Add DT bindings for PCIe controller implemented in UniPhier SoCs when
configured in Root Complex (host) mode. This controller is based on
the DesignWare PCIe core.
Signed-off-by: Kunihiko Hayashi
Reviewed-by: Rob Herring
---
.../devicetree/bindings/pci/uniphier-pcie.txt | 81 ++
1 file changed, 81 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/uniphier-pcie.txt
diff --git a/Documentation/devicetree/bindings/pci/uniphier-pcie.txt
b/Documentation/devicetree/bindings/pci/uniphier-pcie.txt
new file mode 100644
index 000..1fa2c59
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/uniphier-pcie.txt
@@ -0,0 +1,81 @@
+Socionext UniPhier PCIe host controller bindings
+
+This describes the devicetree bindings for PCIe host controller implemented
+on Socionext UniPhier SoCs.
+
+UniPhier PCIe host controller is based on the Synopsys DesignWare PCI core.
+It shares common functions with the PCIe DesignWare core driver and inherits
+common properties defined in
+Documentation/devicetree/bindings/pci/designware-pcie.txt.
+
+Required properties:
+- compatible: Should be "socionext,uniphier-pcie".
+- reg: Specifies offset and length of the register set for the device.
+ According to the reg-names, appropriate register sets are required.
+- reg-names: Must include the following entries:
+"dbi"- controller configuration registers
+"link" - SoC-specific glue layer registers
+"config" - PCIe configuration space
+- clocks: A phandle to the clock gate for PCIe glue layer including
+ the host controller.
+- resets: A phandle to the reset line for PCIe glue layer including
+ the host controller.
+- interrupts: A list of interrupt specifiers. According to the
+ interrupt-names, appropriate interrupts are required.
+- interrupt-names: Must include the following entries:
+"dma" - DMA interrupt
+"msi" - MSI interrupt
+
+Optional properties:
+- phys: A phandle to generic PCIe PHY. According to the phy-names, appropriate
+ phys are required.
+- phy-names: Must be "pcie-phy".
+
+Required sub-node:
+- legacy-interrupt-controller: Specifies interrupt controller for legacy PCI
+ interrupts.
+
+Required properties for legacy-interrupt-controller:
+- interrupt-controller: identifies the node as an interrupt controller.
+- #interrupt-cells: specifies the number of cells needed to encode an
+ interrupt source. The value must be 1.
+- interrupt-parent: Phandle to the parent interrupt controller.
+- interrupts: An interrupt specifier for legacy interrupt.
+
+Example:
+
+ pcie: pcie@6600 {
+ compatible = "socionext,uniphier-pcie", "snps,dw-pcie";
+ status = "disabled";
+ reg-names = "dbi", "link", "config";
+ reg = <0x6600 0x1000>, <0x6601 0x1>,
+ <0x2fff 0x1>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ clocks = <&sys_clk 24>;
+ resets = <&sys_rst 24>;
+ num-lanes = <1>;
+ num-viewport = <1>;
+ bus-range = <0x0 0xff>;
+ device_type = "pci";
+ ranges =
+ /* downstream I/O */
+ <0x8100 0 0x 0x2ffe 0 0x0001
+ /* non-prefetchable memory */
+0x8200 0 0x 0x2000 0 0x0ffe>;
+ #interrupt-cells = <1>;
+ interrupt-names = "dma", "msi";
+ interrupts = <0 224 4>, <0 225 4>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &pcie_intc 0>, /* INTA */
+ <0 0 0 2 &pcie_intc 1>, /* INTB */
+ <0 0 0 3 &pcie_intc 2>, /* INTC */
+ <0 0 0 4 &pcie_intc 3>; /* INTD */
+
+ pcie_intc: legacy-interrupt-controller {
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 226 4>;
+ };
+ };
--
2.7.4
[PATCH] regulator: mcp16502: fix platform_no_drv_owner.cocci warnings
From: kbuild test robot
drivers/regulator/mcp16502.c:530:3-8: No need to set .owner here. The core will
do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Fixes: 9199c277faeb ("regulator: mcp16502: add regulator driver for MCP16502")
CC: andrei.stefane...@microchip.com
Signed-off-by: kbuild test robot
---
url:
https://github.com/0day-ci/linux/commits/Andrei-Stefanescu-microchip-com/add-support-for-MCP16502-PMIC/20181128-041809
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
for-next
mcp16502.c |1 -
1 file changed, 1 deletion(-)
--- a/drivers/regulator/mcp16502.c
+++ b/drivers/regulator/mcp16502.c
@@ -527,7 +527,6 @@ static struct i2c_driver mcp16502_drv =
.probe = mcp16502_probe,
.driver = {
.name = "mcp16502-regulator",
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(mcp16502_ids),
.pm = &mcp16502_pm_ops,
},
Re: [PATCH v2 3/3] regulator: mcp16502: add regulator driver for MCP16502
Hi Andrei.Stefanescu, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on regulator/for-next] [also build test WARNING on v4.20-rc4 next-20181127] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Andrei-Stefanescu-microchip-com/add-support-for-MCP16502-PMIC/20181128-041809 base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next coccinelle warnings: (new ones prefixed by >>) >> drivers/regulator/mcp16502.c:530:3-8: No need to set .owner here. The core >> will do it. Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCH] Input: xpad - add support for Hyperkin Duke Xbox One gamepad
On 11/27/2018 07:28 PM, Cameron Gutman wrote:
> Originally submitted by Shelby Jueden (GitHub: AkBKukU) to paroj/xpad:
> https://github.com/paroj/xpad/pull/97
>
> Minor change to the location of the new entries done by me.
>
> Cc: Shelby Jueden
> Cc: sta...@vger.kernel.org
> Signed-off-by: Cameron Gutman
> ---
I'm going to actually NACK this one myself.
I didn't realize Shelby had already submitted it here and received
feedback - https://patchwork.kernel.org/patch/10421897/
I believe I have a patch to always read from Xbox One gamepads kicking around
here somewhere. I'll send that in a series with this patch (or Shelby's if he
wants to make a v2 with the ordering fixed).
> drivers/input/joystick/xpad.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
> index cfc8b94527b9..8d6ea091a01a 100644
> --- a/drivers/input/joystick/xpad.c
> +++ b/drivers/input/joystick/xpad.c
> @@ -330,6 +330,7 @@ static const struct xpad_device {
> { 0x24c6, 0x5b03, "Thrustmaster Ferrari 458 Racing Wheel", 0,
> XTYPE_XBOX360 },
> { 0x24c6, 0x5d04, "Razer Sabertooth", 0, XTYPE_XBOX360 },
> { 0x24c6, 0xfafe, "Rock Candy Gamepad for Xbox 360", 0, XTYPE_XBOX360 },
> + { 0x2e24, 0x0652, "Hyperkin Duke X-Box One pad", 0, XTYPE_XBOXONE },
> { 0x3767, 0x0101, "Fanatec Speedster 3 Forceshock Wheel", 0, XTYPE_XBOX
> },
> { 0x, 0x, "Chinese-made Xbox Controller", 0, XTYPE_XBOX },
> { 0x, 0x, "Generic X-Box pad", 0, XTYPE_UNKNOWN }
> @@ -440,6 +441,7 @@ static const struct usb_device_id xpad_table[] = {
> XPAD_XBOX360_VENDOR(0x1bad),/* Harminix Rock Band Guitar
> and Drums */
> XPAD_XBOX360_VENDOR(0x24c6),/* PowerA Controllers */
> XPAD_XBOXONE_VENDOR(0x24c6),/* PowerA Controllers */
> + XPAD_XBOXONE_VENDOR(0x2e24),/* Hyperkin Duke X-Box One pad
> */
> { }
> };
>
>
Re: [PATCH] Input: synaptics - Add PNP ID for ThinkPad P50 to SMBus
On Wed, Nov 21, 2018 at 03:16:20PM -0500, Lyude Paul wrote:
> Noticed the other day the trackpoint felt different on my P50, then
> realized it was because rmi4 wasn't loading for this machine
> automatically. Suspend/resume, hibernate, and everything else seem to
> work perfectly fine on here.
>
> Signed-off-by: Lyude Paul
Acked-by: Peter Hutterer
Cheers,
Peter
> ---
> drivers/input/mouse/synaptics.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
> index 5e85f3cca867..c42813d50591 100644
> --- a/drivers/input/mouse/synaptics.c
> +++ b/drivers/input/mouse/synaptics.c
> @@ -170,6 +170,7 @@ static const char * const smbus_pnp_ids[] = {
> "LEN0048", /* X1 Carbon 3 */
> "LEN0046", /* X250 */
> "LEN004a", /* W541 */
> + "LEN005b", /* P50 */
> "LEN0071", /* T480 */
> "LEN0072", /* X1 Carbon Gen 5 (2017) - Elan/ALPS trackpoint */
> "LEN0073", /* X1 Carbon G5 (Elantech) */
> --
> 2.19.1
>
Re: linux-next: Tree for Nov 27 (net/ipv4/af_inet.c)
On 11/26/18 8:25 PM, Stephen Rothwell wrote: > Hi all, > > Changes since 20181126: > as reported for linux-next-20181109: (see https://lore.kernel.org/lkml/499e91d0-7349-641f-9826-753571317...@infradead.org/) when CONFIG_PROC_FS is not enabled: ld: net/ipv4/af_inet.o: in function `inet_init': af_inet.c:(.init.text+0x42d): undefined reference to `raw_init' -- ~Randy
[PATCH v2 4/8] HID: input: use the Resolution Multiplier for high-resolution scrolling
Windows uses a magic number of 120 for a wheel click. High-resolution
scroll wheels are supposed to use a fraction of 120 to signal smaller
scroll steps. This is implemented by the Resolution Multiplier in the
device itself.
If the multiplier is present in the report descriptor, set it to the
logical max and then use the resolution multiplier to calculate the
high-resolution events. This is the recommendation by Microsoft, see
http://msdn.microsoft.com/en-us/windows/hardware/gg487477.aspx
Note that all mice encountered so far have a logical min/max of 0/1, so
it's a binary "yes or no" to high-res scrolling anyway.
To make userspace simpler, always enable the REL_WHEEL_HI_RES bit. Where
the device doesn't support high-resolution scrolling, the value for the
high-res data will simply be a multiple of 120 every time. For userspace,
if REL_WHEEL_HI_RES is available that is the one to be used.
Potential side-effect: a device with a Resolution Multiplier applying to
other Input items will have those items set to the logical max as well.
This cannot easily be worked around but it is doubtful such devices exist.
Signed-off-by: Peter Hutterer
---
Changes to v1:
- drop the wheel factor and calculate the hi-res value as the event comes
in. This fixes the issue with a multiplier of 16, makes the code simpler
too because we don't have to refresh anything after setting the
multiplier.
drivers/hid/hid-input.c | 108 ++--
include/linux/hid.h | 3 ++
2 files changed, 108 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index ad823a01bd65..328ce163aea8 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -709,7 +709,15 @@ static void hidinput_configure_usage(struct hid_input
*hidinput, struct hid_fiel
map_abs_clear(usage->hid & 0xf);
break;
- case HID_GD_SLIDER: case HID_GD_DIAL: case HID_GD_WHEEL:
+ case HID_GD_WHEEL:
+ if (field->flags & HID_MAIN_ITEM_RELATIVE) {
+ set_bit(REL_WHEEL, input->relbit);
+ map_rel(REL_WHEEL_HI_RES);
+ } else {
+ map_abs(usage->hid & 0xf);
+ }
+ break;
+ case HID_GD_SLIDER: case HID_GD_DIAL:
if (field->flags & HID_MAIN_ITEM_RELATIVE)
map_rel(usage->hid & 0xf);
else
@@ -1009,7 +1017,10 @@ static void hidinput_configure_usage(struct hid_input
*hidinput, struct hid_fiel
case 0x22f: map_key_clear(KEY_ZOOMRESET); break;
case 0x233: map_key_clear(KEY_SCROLLUP);break;
case 0x234: map_key_clear(KEY_SCROLLDOWN); break;
- case 0x238: map_rel(REL_HWHEEL);break;
+ case 0x238: /* AC Pan */
+ set_bit(REL_HWHEEL, input->relbit);
+ map_rel(REL_HWHEEL_HI_RES);
+ break;
case 0x23d: map_key_clear(KEY_EDIT);break;
case 0x25f: map_key_clear(KEY_CANCEL); break;
case 0x269: map_key_clear(KEY_INSERT); break;
@@ -1197,6 +1208,38 @@ static void hidinput_configure_usage(struct hid_input
*hidinput, struct hid_fiel
}
+static void hidinput_handle_scroll(struct hid_usage *usage,
+ struct input_dev *input,
+ __s32 value)
+{
+ int code;
+ int hi_res, lo_res;
+
+ if (value == 0)
+ return;
+
+ if (usage->code == REL_WHEEL_HI_RES)
+ code = REL_WHEEL;
+ else
+ code = REL_HWHEEL;
+
+ /*
+* Windows reports one wheel click as value 120. Where a high-res
+* scroll wheel is present, a fraction of 120 is reported instead.
+* Our REL_WHEEL_HI_RES axis does the same because all HW must
+* adhere to the 120 expectation.
+*/
+ hi_res = value * 120/usage->resolution_multiplier;
+
+ usage->wheel_accumulated += hi_res;
+ lo_res = usage->wheel_accumulated/120;
+ if (lo_res)
+ usage->wheel_accumulated -= lo_res * 120;
+
+ input_event(input, EV_REL, code, lo_res);
+ input_event(input, EV_REL, usage->code, hi_res);
+}
+
void hidinput_hid_event(struct hid_device *hid, struct hid_field *field,
struct hid_usage *usage, __s32 value)
{
struct input_dev *input;
@@ -1259,6 +1302,12 @@ void hidinput_hid_event(struct hid_device *hid, struct
hid_field *field, struct
if ((usage->type == EV_KEY) && (usage->code == 0)) /* Key 0 is
"unassigned", not KEY_UNKNOWN */
return;
+ if ((usage->type == EV_REL) && (usage->code == REL_WHEEL_HI_RES ||
+
[GIT PULL] tracing: Fix fgraph design bug and sched_switch state output
Linus,
While rewriting the function graph tracer, I discovered a design flaw that
was introduced by a patch that tried to fix one bug, but by doing so created
another bug. As both bugs corrupt the output (but they do not crash the
kernel), I decided to fix the design such that it could have both bugs
fixed. The original fix, fixed time reporting of the function graph tracer
when doing a max_depth of one. This was code that can test how much the
kernel interferes with userspace. But in doing so, it could corrupt the time
keeping of the function profiler.
The issue is that the curr_ret_stack variable was being used for two
different meanings. One was to keep track of the stack pointer on the
ret_stack (shadow stack used by the function graph tracer), and the other
use case was the graph call depth. Although, the two may be closely
related, where they got updated was the issue that lead to the two different
bugs that required the two use cases to be updated differently.
The big issue with this fix is that it requires changing each architecture.
The good news is, I was able to remove a lot of code that was duplicated
within the architectures and place it into a single location. Then I could
make the fix in one place.
I pushed this code into linux-next to let it settle over a week, and before
doing so, I cross compiled all the affected architectures to make sure that
they built fine.
In the mean time, I also pulled in a patch that fixes the sched_switch
previous tasks state output, that was not actually correct.
Please pull the latest trace-v4.20-rc3 tree, which can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
trace-v4.20-rc3
Tag SHA1: adc352569eb25f7a0ecb4785b595a85315074020
Head SHA1: 3054426dc68e5d63aa6a6e9b91ac4ec78e3f3805
Pavankumar Kondeti (1):
sched, trace: Fix prev_state output in sched_switch tracepoint
Steven Rostedt (VMware) (18):
function_graph: Create function_graph_enter() to consolidate architecture
code
x86/function_graph: Simplify with function_graph_enter()
ARM: function_graph: Simplify with function_graph_enter()
arm64: function_graph: Simplify with function_graph_enter()
microblaze: function_graph: Simplify with function_graph_enter()
MIPS: function_graph: Simplify with function_graph_enter()
nds32: function_graph: Simplify with function_graph_enter()
parisc: function_graph: Simplify with function_graph_enter()
powerpc/function_graph: Simplify with function_graph_enter()
riscv/function_graph: Simplify with function_graph_enter()
s390/function_graph: Simplify with function_graph_enter()
sh/function_graph: Simplify with function_graph_enter()
sparc/function_graph: Simplify with function_graph_enter()
function_graph: Make ftrace_push_return_trace() static
function_graph: Use new curr_ret_depth to manage depth instead of
curr_ret_stack
function_graph: Move return callback before update of curr_ret_stack
function_graph: Reverse the order of pushing the ret_stack and the
callback
function_graph: Have profiler use curr_ret_stack and not depth
arch/arm/kernel/ftrace.c | 17 +
arch/arm64/kernel/ftrace.c | 15 +--
arch/microblaze/kernel/ftrace.c | 15 ++-
arch/mips/kernel/ftrace.c| 14 ++-
arch/nds32/kernel/ftrace.c | 18 ++---
arch/parisc/kernel/ftrace.c | 17 +++--
arch/powerpc/kernel/trace/ftrace.c | 15 ++-
arch/riscv/kernel/ftrace.c | 14 ++-
arch/s390/kernel/ftrace.c| 13 ++
arch/sh/kernel/ftrace.c | 16 ++--
arch/sparc/kernel/ftrace.c | 11 +---
arch/x86/kernel/ftrace.c | 15 +--
include/linux/ftrace.h | 4 +--
include/linux/sched.h| 1 +
include/trace/events/sched.h | 12 -
kernel/trace/ftrace.c| 7 --
kernel/trace/trace_functions_graph.c | 49
17 files changed, 78 insertions(+), 175 deletions(-)
---
diff --git a/arch/arm/kernel/ftrace.c b/arch/arm/kernel/ftrace.c
index 0142fcfcc3d3..bda949fd84e8 100644
--- a/arch/arm/kernel/ftrace.c
+++ b/arch/arm/kernel/ftrace.c
@@ -183,9 +183,7 @@ void prepare_ftrace_return(unsigned long *parent, unsigned
long self_addr,
unsigned long frame_pointer)
{
unsigned long return_hooker = (unsigned long) &return_to_handler;
- struct ftrace_graph_ent trace;
unsigned long old;
- int err;
if (unlikely(atomic_read(¤t->tracing_graph_pause)))
return;
@@ -193,21 +191,8 @@ void prepare_ftrace_return(unsigned long *parent, unsigned
long self_addr,
old = *parent;
*parent = return_hooker;
- trace.func = self_addr;
- trace.depth = current->curr_ret_sta
[PATCH v2 8/8] HID: logitech: Enable high-resolution scrolling on Logitech mice
From: Harry Cutts
There are three features used by various Logitech mice for
high-resolution scrolling: the scrolling acceleration bit in HID++ 1.0,
and the x2120 and x2121 features in HID++ 2.0 and above. This patch
supports all three, and uses the multiplier reported by the mouse for
the HID++ 2.0+ features.
The full list of product IDs of mice which support high-resolution
scrolling was provided by Logitech, but the patch was tested using the
following mice (using the Unifying receiver):
* HID++ 1.0: Anywhere MX, Performance MX
* x2120: M560
* x2121: MX Anywhere 2, MX Master 2S
This patch is a combinations of the now-reverted commits 1ff2e1a44e0,
d56ca9855bf9, 5fe2ccbef9d, 044ee89028 together with some extra bits for the
directional and timeout-based reset.
The previous patch series was in hid-input, it appears this remainder
handling is logitech-specific and was moved to hid-logitech-hidpp.c and
renamed accordingly.
Signed-off-by: Harry Cutts
Signed-off-by: Peter Hutterer
---
Changes to v1:
- get rid of the timer in favour of sched_clock()
- drop storing the multiplier and calculate value on the fly
drivers/hid/hid-logitech-hidpp.c | 292 ++-
1 file changed, 288 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 67ca587aecfa..236ed256e4e7 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -64,6 +65,14 @@ MODULE_PARM_DESC(disable_tap_to_click,
#define HIDPP_QUIRK_NO_HIDINPUTBIT(23)
#define HIDPP_QUIRK_FORCE_OUTPUT_REPORTS BIT(24)
#define HIDPP_QUIRK_UNIFYING BIT(25)
+#define HIDPP_QUIRK_HI_RES_SCROLL_1P0 BIT(26)
+#define HIDPP_QUIRK_HI_RES_SCROLL_X2120BIT(27)
+#define HIDPP_QUIRK_HI_RES_SCROLL_X2121BIT(28)
+
+/* Convenience constant to check for any high-res support. */
+#define HIDPP_QUIRK_HI_RES_SCROLL (HIDPP_QUIRK_HI_RES_SCROLL_1P0 | \
+HIDPP_QUIRK_HI_RES_SCROLL_X2120 | \
+HIDPP_QUIRK_HI_RES_SCROLL_X2121)
#define HIDPP_QUIRK_DELAYED_INIT HIDPP_QUIRK_NO_HIDINPUT
@@ -128,6 +137,25 @@ struct hidpp_battery {
bool online;
};
+/**
+ * struct hidpp_scroll_counter - Utility class for processing high-resolution
+ * scroll events.
+ * @dev: the input device for which events should be reported.
+ * @wheel_multiplier: the scalar multiplier to be applied to each wheel event
+ * @remainder: counts the number of high-resolution units moved since the last
+ * low-resolution event (REL_WHEEL or REL_HWHEEL) was sent. Should
+ * only be used by class methods.
+ * @direction: direction of last movement (1 or -1)
+ * @last_time: last event time, used to reset remainder after inactivity
+ */
+struct hidpp_scroll_counter {
+ struct input_dev *dev;
+ int wheel_multiplier;
+ int remainder;
+ int direction;
+ unsigned long long last_time;
+};
+
struct hidpp_device {
struct hid_device *hid_dev;
struct mutex send_mutex;
@@ -149,6 +177,7 @@ struct hidpp_device {
unsigned long capabilities;
struct hidpp_battery battery;
+ struct hidpp_scroll_counter vertical_wheel_counter;
};
/* HID++ 1.0 error codes */
@@ -391,6 +420,67 @@ static void hidpp_prefix_name(char **name, int name_length)
*name = new_name;
}
+/**
+ * hidpp_scroll_counter_handle_scroll() - Send high- and low-resolution scroll
+ *events given a high-resolution wheel
+ *movement.
+ * @counter: a hid_scroll_counter struct describing the wheel.
+ * @hi_res_value: the movement of the wheel, in the mouse's high-resolution
+ *units.
+ *
+ * Given a high-resolution movement, this function converts the movement into
+ * fractions of 120 and emits high-resolution scroll events for the input
+ * device. It also uses the multiplier from &struct hid_scroll_counter to
+ * emit low-resolution scroll events when appropriate for
+ * backwards-compatibility with userspace input libraries.
+ */
+static void hidpp_scroll_counter_handle_scroll(struct hidpp_scroll_counter
*counter,
+ int hi_res_value)
+{
+ int low_res_value, remainder, direction;
+ unsigned long long now, previous;
+
+ hi_res_value = hi_res_value * 120/counter->wheel_multiplier;
+ input_report_rel(counter->dev, REL_WHEEL_HI_RES, hi_res_value);
+
+ remainder = counter->remainder;
+ direction = hi_res_value > 0 ? 1 : -1;
+
+ now = sched_clock();
+ previous = counter->last_time;
+ counter->last_time = now;
+ /*
+* Reset the remainder after a period of
Re: [PATCH v2] panic: Add options to print system info when panic happens
Hi Steven, On Tue, Nov 27, 2018 at 01:23:18PM -0500, Steven Rostedt wrote: > On Tue, 27 Nov 2018 15:15:20 +0800 > Feng Tang wrote: > > > Kernel panic issues are always painful to debug, partially > > because it's not easy to get enough information of the > > context when panic happens. > > > > And we have ramoops and kdump for that, while this commit > > tries to provide a easier way to show the system info by adding > > a cmdline parameter, referring some idea from sysrq handler. > > > > Signed-off-by: Feng Tang > > Cc: Thomas Gleixner > > Cc: John Stultz > > Cc: Ingo Molnar > > Cc: Peter Zijlstra > > Cc: Steven Rostedt > > --- > > Changelog: > > v2: > > - change text "dump/DUMP" to "print/PRINT" which > > is more accurate, suggested by Andrew Morton > > - add code to print ftrace buffer > > > > Documentation/admin-guide/kernel-parameters.txt | 8 +++ > > kernel/panic.c | 28 > > + > > 2 files changed, 36 insertions(+) > > > > diff --git a/Documentation/admin-guide/kernel-parameters.txt > > b/Documentation/admin-guide/kernel-parameters.txt > > index 19f4423..80c819a 100644 > > --- a/Documentation/admin-guide/kernel-parameters.txt > > +++ b/Documentation/admin-guide/kernel-parameters.txt > > @@ -3081,6 +3081,14 @@ > > timeout < 0: reboot immediately > > Format: > > > > + panic_print=Bitmask for printing system info when panic happens. > > + User can chose combination of the following bits: > > + bit 0: print all tasks info > > + bit 1: print system memory info > > + bit 2: print timer info > > + bit 3: print locks info if CONFIG_LOCKDEP is on > > > + bit 4: print ftrace buffer > > Note, "ftrace_dump_on_oops" accomplishes the same thing. > > Should this be a sysctl setting as well? Thanks for the suggestion and note. I will add sysctl part in next version. - Feng
Re: [PATCH v2 3/3] regulator: mcp16502: add regulator driver for MCP16502
Hi Andrei.Stefanescu,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on regulator/for-next]
[also build test ERROR on v4.20-rc4 next-20181127]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Andrei-Stefanescu-microchip-com/add-support-for-MCP16502-PMIC/20181128-041809
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
for-next
config: sh-allyesconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=sh
All error/warnings (new ones prefixed by >>):
drivers//regulator/mcp16502.c: In function 'mcp16502_suspend_get_target_reg':
>> drivers//regulator/mcp16502.c:273:10: error: 'pm_suspend_target_state'
>> undeclared (first use in this function); did you mean 'pm_suspended_storage'?
switch (pm_suspend_target_state) {
^~~
pm_suspended_storage
drivers//regulator/mcp16502.c:273:10: note: each undeclared identifier is
reported only once for each function it appears in
drivers//regulator/mcp16502.c: In function 'mcp16502_set_suspend_mode':
drivers//regulator/mcp16502.c:310:10: error: 'pm_suspend_target_state'
undeclared (first use in this function); did you mean 'pm_suspended_storage'?
switch (pm_suspend_target_state) {
^~~
pm_suspended_storage
drivers//regulator/mcp16502.c: In function 'mcp16502_suspend_get_target_reg':
>> drivers//regulator/mcp16502.c:284:1: warning: control reaches end of
>> non-void function [-Wreturn-type]
}
^
drivers//regulator/mcp16502.c: In function 'mcp16502_set_suspend_mode':
drivers//regulator/mcp16502.c:321:1: warning: control reaches end of
non-void function [-Wreturn-type]
}
^
vim +273 drivers//regulator/mcp16502.c
266
267 /*
268 * mcp16502_suspend_get_target_reg() - get the reg of the target
suspend PMIC
269 * mode
270 */
271 static int mcp16502_suspend_get_target_reg(struct regulator_dev *rdev)
272 {
> 273 switch (pm_suspend_target_state) {
274 case PM_SUSPEND_STANDBY:
275 return mcp16502_get_reg(rdev, MCP16502_OPMODE_LPM);
276 case PM_SUSPEND_ON:
277 case PM_SUSPEND_MEM:
278 return mcp16502_get_reg(rdev, MCP16502_OPMODE_HIB);
279 default:
280 dev_err(&rdev->dev, "invalid suspend target: %d\n",
281 pm_suspend_target_state);
282 return -EINVAL;
283 }
> 284 }
285
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[PATCH] Input: xpad - add support for Hyperkin Duke Xbox One gamepad
Originally submitted by Shelby Jueden (GitHub: AkBKukU) to paroj/xpad:
https://github.com/paroj/xpad/pull/97
Minor change to the location of the new entries done by me.
Cc: Shelby Jueden
Cc: sta...@vger.kernel.org
Signed-off-by: Cameron Gutman
---
drivers/input/joystick/xpad.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index cfc8b94527b9..8d6ea091a01a 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -330,6 +330,7 @@ static const struct xpad_device {
{ 0x24c6, 0x5b03, "Thrustmaster Ferrari 458 Racing Wheel", 0,
XTYPE_XBOX360 },
{ 0x24c6, 0x5d04, "Razer Sabertooth", 0, XTYPE_XBOX360 },
{ 0x24c6, 0xfafe, "Rock Candy Gamepad for Xbox 360", 0, XTYPE_XBOX360 },
+ { 0x2e24, 0x0652, "Hyperkin Duke X-Box One pad", 0, XTYPE_XBOXONE },
{ 0x3767, 0x0101, "Fanatec Speedster 3 Forceshock Wheel", 0, XTYPE_XBOX
},
{ 0x, 0x, "Chinese-made Xbox Controller", 0, XTYPE_XBOX },
{ 0x, 0x, "Generic X-Box pad", 0, XTYPE_UNKNOWN }
@@ -440,6 +441,7 @@ static const struct usb_device_id xpad_table[] = {
XPAD_XBOX360_VENDOR(0x1bad),/* Harminix Rock Band Guitar
and Drums */
XPAD_XBOX360_VENDOR(0x24c6),/* PowerA Controllers */
XPAD_XBOXONE_VENDOR(0x24c6),/* PowerA Controllers */
+ XPAD_XBOXONE_VENDOR(0x2e24),/* Hyperkin Duke X-Box One pad
*/
{ }
};
--
2.19.1
[PATCH] ubi: do not drop UBI device reference before using
The UBI device reference is dropped but then the device is used as a
parameter of ubi_err. The bug is introduced in changing ubi_err's
behavior. The old ubi_err does not require a UBI device as its first
parameter, but the new one does.
Fixes: 32608703310 ("UBI: Extend UBI layer debug/messaging capabilities")
Signed-off-by: Pan Bian
---
drivers/mtd/ubi/kapi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/ubi/kapi.c b/drivers/mtd/ubi/kapi.c
index e9e9ecb..0b8f0c4 100644
--- a/drivers/mtd/ubi/kapi.c
+++ b/drivers/mtd/ubi/kapi.c
@@ -227,9 +227,9 @@ struct ubi_volume_desc *ubi_open_volume(int ubi_num, int
vol_id, int mode)
out_free:
kfree(desc);
out_put_ubi:
- ubi_put_device(ubi);
ubi_err(ubi, "cannot open device %d, volume %d, error %d",
ubi_num, vol_id, err);
+ ubi_put_device(ubi);
return ERR_PTR(err);
}
EXPORT_SYMBOL_GPL(ubi_open_volume);
--
2.7.4
[PATCH V2] ASoC: max98373: Added max98373_reset for stable amp reset
Signed-off-by: Ryan Lee
---
Changes since v1 : Removed unusual repeat for amp software reset and
verification.
Amp software reset will be performed once and it repeats
verification maximum 3 times if it is failed.
Wait 10ms before every verification trial. Maximum 30ms
delay will be applied to wait AMP idle state.
Changes : Created max98373_reset function to minimize code duplication.
Changed regmap_write to regmap_update_bits. Other bits except LSB
need to be masked.
Added reset verification step to make sure software reset is
completed well. Software reset is done in 10ms in normal case.
Revision ID is available when the amp is in the idle state which
means software reset is completed.
Software reset will be performed maximum 3 times to avoid amp reset
failure. Generally it is done in the first trial.
sleep time after software reset is increased + 30ms for every
retrial. Maximum possible msleep time is 100 ms (initial 10 ms + 30 ms * 3
times).
sound/soc/codecs/max98373.c | 35 +--
1 file changed, 29 insertions(+), 6 deletions(-)
diff --git a/sound/soc/codecs/max98373.c b/sound/soc/codecs/max98373.c
index a09d013..9c8616a 100644
--- a/sound/soc/codecs/max98373.c
+++ b/sound/soc/codecs/max98373.c
@@ -724,14 +724,39 @@ static struct snd_soc_dai_driver max98373_dai[] = {
}
};
+static void max98373_reset(struct max98373_priv *max98373, struct device *dev)
+{
+ int ret, reg, count;
+
+ /* Software Reset */
+ ret = regmap_update_bits(max98373->regmap,
+ MAX98373_R2000_SW_RESET,
+ MAX98373_SOFT_RESET,
+ MAX98373_SOFT_RESET);
+ if (ret)
+ dev_err(dev, "Reset command failed. (ret:%d)\n", ret);
+
+ count = 0;
+ while (count < 3) {
+ usleep_range(1, 11000);
+ /* Software Reset Verification */
+ ret = regmap_read(max98373->regmap,
+ MAX98373_R21FF_REV_ID, ®);
+ if (!ret) {
+ dev_info(dev, "Reset completed (retry:%d)\n", count);
+ return;
+ }
+ count++;
+ }
+ dev_err(dev, "Reset failed. (ret:%d)\n", ret);
+}
+
static int max98373_probe(struct snd_soc_component *component)
{
struct max98373_priv *max98373 =
snd_soc_component_get_drvdata(component);
/* Software Reset */
- regmap_write(max98373->regmap,
- MAX98373_R2000_SW_RESET, MAX98373_SOFT_RESET);
- usleep_range(1, 11000);
+ max98373_reset(max98373, component->dev);
/* IV default slot configuration */
regmap_write(max98373->regmap,
@@ -818,9 +843,7 @@ static int max98373_resume(struct device *dev)
{
struct max98373_priv *max98373 = dev_get_drvdata(dev);
- regmap_write(max98373->regmap,
- MAX98373_R2000_SW_RESET, MAX98373_SOFT_RESET);
- usleep_range(1, 11000);
+ max98373_reset(max98373, dev);
regcache_cache_only(max98373->regmap, false);
regcache_sync(max98373->regmap);
return 0;
--
2.7.4
Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression
Andrea Arcangeli writes:
> Hi Linus,
>
> On Tue, Nov 27, 2018 at 09:08:50AM -0800, Linus Torvalds wrote:
>> On Mon, Nov 26, 2018 at 10:24 PM kernel test robot
>> wrote:
>> >
>> > FYI, we noticed a -61.3% regression of vm-scalability.throughput due
>> > to commit ac5b2c18911f ("mm: thp: relax __GFP_THISNODE for
>> > MADV_HUGEPAGE mappings")
>>
>> Well, that's certainly noticeable and not good.
>
> Noticed this email too.
>
> This difference can only happen with defrag=always, and that's not the
> current upstream default.
>
> thp_enabled: always
> thp_defrag: always
> ^^ emulates MADV_HUGEPAGE always set
>
>> Andrea, I suspect it might be causing fights with auto numa migration..
>
> That MADV_HUGEPAGE causes flights with NUMA balancing is not great
> indeed, qemu needs NUMA locality too, but then the badness caused by
> __GFP_THISNODE was a larger regression in the worst case for qemu.
>
> When the kernel wants to allocate a THP from node A, if there are no
> THP generated on node A but there are in node B, they'll be picked from
> node B now.
>
> __GFP_THISNODE previously prevented any THP to be allocated from any
> node except A. This introduces a higher chance of initial misplacement
> which NUMA balancing will correct over time, but it should only apply
> to long lived allocations under MADV_HUGEPAGE. Perhaps the workload
> here uses short lived allocations and sets defrag=always which is not
> optimal to begin with?
>
> The motivation of the fix, is that the previous code invoked reclaim
> with __GFP_THISNODE set. That looked insecure and such behavior should
> only have been possible under a mlock/mempolicy
> capability. __GFP_THISNODE is like a transient but still privileged
> mbind for reclaim.
>
> Before the fix, __GFP_THISNODE would end up swapping out everything
> from node A to free 4k pages from node A, despite perhaps there were
> gigabytes of memory free in node B. That caused severe regression to
> threaded workloads whose memory spanned more than one NUMA node. So
> again going back doesn't sounds great for NUMA in general.
>
> The vmscalability test is most certainly not including any
> multithreaded process whose memory doesn't fit in a single NUMA node
> or we'd see also the other side of the tradeoff. It'd be nice to add
> such a test to be sure that the old __GFP_THISNODE behavior won't
> happen again for apps that don't fit in a single node.
The test case is to test swap subsystem. Where tens (32 in test job)
processes are run to eat memory to trigger to swap to NVMe disk. The
memory size to eat is almost same in this commit and its parent. But I
found the swap triggered is much more for this commit.
70934968 ± 10% +51.7% 1.076e+08 ± 3% proc-vmstat.pswpout
One possibility is that for parent commit, some processes exit much
earlier than other processes, so the total memory requirement of the
whole system is much lower. So I dig more on test log and found,
For the parent commit,
$ grep 'usecs =' vm-scalability
24573771360 bytes / 13189705 usecs = 1819435 KB/s
24573771360 bytes / 13853913 usecs = 1732205 KB/s
24573771360 bytes / 42953388 usecs = 558694 KB/s
24573771360 bytes / 52782761 usecs = 454652 KB/s
24573771360 bytes / 84026989 usecs = 285596 KB/s
24573771360 bytes / 111677310 usecs = 214885 KB/s
24573771360 bytes / 146084698 usecs = 164273 KB/s
24573771360 bytes / 146978329 usecs = 163274 KB/s
24573771360 bytes / 149371224 usecs = 160658 KB/s
24573771360 bytes / 162892070 usecs = 147323 KB/s
24573771360 bytes / 177949001 usecs = 134857 KB/s
24573771360 bytes / 181729992 usecs = 132052 KB/s
24573771360 bytes / 189812698 usecs = 126428 KB/s
24573771360 bytes / 190992698 usecs = 125647 KB/s
24573771360 bytes / 200039238 usecs = 119965 KB/s
24573771360 bytes / 201254461 usecs = 119241 KB/s
24573771360 bytes / 202825077 usecs = 118317 KB/s
24573771360 bytes / 203441285 usecs = 117959 KB/s
24573771360 bytes / 205378150 usecs = 116847 KB/s
24573771360 bytes / 204840555 usecs = 117153 KB/s
24573771360 bytes / 206235458 usecs = 116361 KB/s
24573771360 bytes / 206419877 usecs = 116257 KB/s
24573771360 bytes / 206619347 usecs = 116145 KB/s
24573771360 bytes / 206942267 usecs = 115963 KB/s
24573771360 bytes / 210289229 usecs = 114118 KB/s
24573771360 bytes / 210504531 usecs = 114001 KB/s
24573771360 bytes / 210521351 usecs = 113992 KB/s
24573771360 bytes / 211012852 usecs = 113726 KB/s
24573771360 bytes / 211547509 usecs = 113439 KB/s
24573771360 bytes / 212179521 usecs = 113101 KB/s
24573771360 bytes / 212907825 usecs = 112714 KB/s
24573771360 bytes / 215558786 usecs = 111328 KB/s
For this commit,
$ grep 'usecs =' vm-scalability
24573681072 bytes / 203705073 usecs = 117806 KB/s
24573681072 bytes / 216146130 usecs = 111025 KB/s
24573681072 bytes / 257234408 usecs = 93291 KB/s
24573681072 bytes / 259530715 usecs = 92465 KB/s
24573681072 bytes / 261335046 usecs = 91827 KB/s
24573681072 bytes / 260134706 usecs = 92251 KB/s
2457368
[PATCH] ARM: multi_v7_defconfig: enable CONFIG_UNIPHIER_MDMAC
Enable the UniPhier MIO DMAC driver. This is used as the DMA engine for accelerating the SD/eMMC controller drivers. Signed-off-by: Masahiro Yamada --- The insertion context was decided by savedefconfig on next-20181127. arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 63af623..715da88 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -862,6 +862,7 @@ CONFIG_STM32_DMA=y CONFIG_STM32_DMAMUX=y CONFIG_STM32_MDMA=y CONFIG_TEGRA20_APB_DMA=y +CONFIG_UNIPHIER_MDMAC=y CONFIG_XILINX_DMA=y CONFIG_QCOM_BAM_DMA=y CONFIG_DW_DMAC=y -- 2.7.4
Re: [PATCH] arm64/lib: improve CRC32 performance for deep pipelines
The code execute on my system performance improves from
# time ./old
real0m6.645s
user0m6.644s
sys 0m0.001s
to
# time ./new
real0m5.565s
user0m5.565s
sys 0m0.000s
> Improve the performance of the crc32() asm routines by getting rid of most of
> the branches and small sized loads on the common path.
>
> Instead, use a branchless code path involving overlapping 16 byte loads to
> process the first (length % 32) bytes, and process the remainder using a loop
> that processes 32 bytes at a time.
>
> Tested using the following test program:
>
> #include
>
> extern void crc32_le(unsigned short, char const*, int);
>
> int main(void)
> {
> static const char buf[4096];
>
> srand(20181126);
>
> for (int i = 0; i < 100 * 1000 * 1000; i++)
> crc32_le(0, buf, rand() % 1024);
>
> return 0;
> }
>
> On Cortex-A53 and Cortex-A57, the performance regresses but only very
> slightly. On Cortex-A72 however, the performance improves from
>
> $ time ./crc32
>
> real 0m10.149s
> user 0m10.149s
> sys 0m0.000s
>
> to
>
> $ time ./crc32
>
> real 0m7.915s
> user 0m7.915s
> sys 0m0.000s
>
> Cc: Rui Sun
> Signed-off-by: Ard Biesheuvel
> ---
> Cortex-A57 tcrypt results after the patch.
>
> I ran Rui's code [0] as well. On Cortex-A57, performance regresses a bit more
> (but not dramatically). On Cortex-A72, it executes at
>
> $ time ./crc32
>
> real 0m9.625s
> user 0m9.625s
> sys 0m0.000s
>
> Rui, can you please benchmark this code on your system as well?
>
> [0]
> https://lore.kernel.org/lkml/1542612560-10089-1-git-send-email-sunru...@huawei.com/
>
> arch/arm64/lib/crc32.S | 54 ++--
> 1 file changed, 49 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/lib/crc32.S b/arch/arm64/lib/crc32.S index
> 5bc1e85b4e1c..f132f2a7522e 100644
> --- a/arch/arm64/lib/crc32.S
> +++ b/arch/arm64/lib/crc32.S
> @@ -15,15 +15,59 @@
> .cpugeneric+crc
>
> .macro __crc32, c
> -0: subsx2, x2, #16
> - b.mi8f
> - ldp x3, x4, [x1], #16
> + cmp x2, #16
> + b.lt8f // less than 16 bytes
> +
> + and x7, x2, #0x1f
> + and x2, x2, #~0x1f
> + cbz x7, 32f // multiple of 32 bytes
> +
> + and x8, x7, #0xf
> + ldp x3, x4, [x1]
> + add x8, x8, x1
> + add x1, x1, x7
> + ldp x5, x6, [x8]
> CPU_BE( rev x3, x3 )
> CPU_BE( rev x4, x4 )
> +CPU_BE( rev x5, x5 )
> +CPU_BE( rev x6, x6 )
> +
> + tst x7, #8
> + crc32\c\()x w8, w0, x3
> + cselx3, x3, x4, eq
> + cselw0, w0, w8, eq
> + tst x7, #4
> + lsr x4, x3, #32
> + crc32\c\()w w8, w0, w3
> + cselx3, x3, x4, eq
> + cselw0, w0, w8, eq
> + tst x7, #2
> + lsr w4, w3, #16
> + crc32\c\()h w8, w0, w3
> + cselw3, w3, w4, eq
> + cselw0, w0, w8, eq
> + tst x7, #1
> + crc32\c\()b w8, w0, w3
> + cselw0, w0, w8, eq
> + tst x7, #16
> + crc32\c\()x w8, w0, x5
> + crc32\c\()x w8, w8, x6
> + cselw0, w0, w8, eq
> + cbz x2, 0f
> +
> +32: ldp x3, x4, [x1], #32
> + sub x2, x2, #32
> + ldp x5, x6, [x1, #-16]
> +CPU_BE( rev x3, x3 )
> +CPU_BE( rev x4, x4 )
> +CPU_BE( rev x5, x5 )
> +CPU_BE( rev x6, x6 )
> crc32\c\()x w0, w0, x3
> crc32\c\()x w0, w0, x4
> - b.ne0b
> - ret
> + crc32\c\()x w0, w0, x5
> + crc32\c\()x w0, w0, x6
> + cbnzx2, 32b
> +0: ret
>
> 8: tbz x2, #3, 4f
> ldr x3, [x1], #8
> --
> 2.19.1
>
>
> BEFORE testing speed of async crc32c (crc32c-generic)
> tcrypt: test 0 ( 16 byte blocks, 16 bytes per update, 1 updates):
> 35416299 opers/sec, 50784 bytes/sec
> tcrypt: test 1 ( 64 byte blocks, 16 bytes per update, 4 updates):
> 5342888 opers/sec, 341944832 bytes/sec
> tcrypt: test 2 ( 64 byte blocks, 64 bytes per update, 1 updates):
> 30056634 opers/sec, 1923624576 bytes/sec
> tcrypt: test 3 ( 256 byte blocks, 16 bytes per update, 16 updates):
> 1543567 opers/sec, 395153152 bytes/sec
> tcrypt: test 4 ( 256 byte blocks, 64 bytes per update, 4 updates):
> 4865198 opers/sec, 1245490688 bytes/sec
> tcrypt: test 5 ( 256 byte blocks, 256 bytes per update, 1 updates):
> 12709474 opers/sec, 3253625344 bytes/sec
> tcrypt: test 6 ( 1024
Re: [PATCH v2 4/4] ARM: dts: Add stmpe-adc driver to relevant devicetrees
On Mon, Nov 19, 2018 at 11:25:28AM +0100, Philippe Schenker wrote:
> From: Philippe Schenker
>
> Activate the stmpe-adc driver as found on Apalis/Colibri iMX6/T30 modules
iMX6 and T30 changes need to be separate patches.
Shawn
>
> Signed-off-by: Philippe Schenker
> ---
>
> Changes in v2:
> - Put common ADC settings in mfd
>
> arch/arm/boot/dts/imx6qdl-apalis.dtsi | 22 ++
> arch/arm/boot/dts/imx6qdl-colibri.dtsi | 23 +++
> arch/arm/boot/dts/tegra30-apalis.dtsi | 22 ++
> arch/arm/boot/dts/tegra30-colibri.dtsi | 22 ++
> 4 files changed, 57 insertions(+), 32 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> index 3dc99dd8dde1..8db476d8978d 100644
> --- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> @@ -331,11 +331,18 @@
> id = <0>;
> blocks = <0x5>;
> irq-trigger = <0x1>;
> + /* 3.25 MHz ADC clock speed */
> + st,adc-freq = <1>;
> + /* 12-bit ADC */
> + st,mod-12b = <1>;
> + /* internal ADC reference */
> + st,ref-sel = <0>;
> + /* ADC converstion time: 80 clocks */
> + st,sample-time = <4>;
> + /* forbid to use ADC channels 3-0 (touch) */
>
> stmpe_touchscreen {
> compatible = "st,stmpe-ts";
> - /* 3.25 MHz ADC clock speed */
> - st,adc-freq = <1>;
> /* 8 sample average control */
> st,ave-ctrl = <3>;
> /* 7 length fractional part in z */
> @@ -345,17 +352,16 @@
>* current limit value
>*/
> st,i-drive = <1>;
> - /* 12-bit ADC */
> - st,mod-12b = <1>;
> - /* internal ADC reference */
> - st,ref-sel = <0>;
> - /* ADC converstion time: 80 clocks */
> - st,sample-time = <4>;
> /* 1 ms panel driver settling time */
> st,settling = <3>;
> /* 5 ms touch detect interrupt delay */
> st,touch-det-delay = <5>;
> };
> +
> + stmpe_adc {
> + compatible = "st,stmpe-adc";
> + st,norequest-mask = <0x0F>;
> + };
> };
> };
>
> diff --git a/arch/arm/boot/dts/imx6qdl-colibri.dtsi
> b/arch/arm/boot/dts/imx6qdl-colibri.dtsi
> index 87e15e7cb32b..2e303d79c7f8 100644
> --- a/arch/arm/boot/dts/imx6qdl-colibri.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-colibri.dtsi
> @@ -262,11 +262,18 @@
> id = <0>;
> blocks = <0x5>;
> irq-trigger = <0x1>;
> + /* 3.25 MHz ADC clock speed */
> + st,adc-freq = <1>;
> + /* 12-bit ADC */
> + st,mod-12b = <1>;
> + /* internal ADC reference */
> + st,ref-sel = <0>;
> + /* ADC converstion time: 80 clocks */
> + st,sample-time = <4>;
> + /* forbid to use ADC channels 3-0 (touch) */
>
> stmpe_touchscreen {
> compatible = "st,stmpe-ts";
> - /* 3.25 MHz ADC clock speed */
> - st,adc-freq = <1>;
> /* 8 sample average control */
> st,ave-ctrl = <3>;
> /* 7 length fractional part in z */
> @@ -276,17 +283,17 @@
>* current limit value
>*/
> st,i-drive = <1>;
> - /* 12-bit ADC */
> - st,mod-12b = <1>;
> - /* internal ADC reference */
> - st,ref-sel = <0>;
> - /* ADC converstion time: 80 clocks */
> - st,sample-time = <4>;
> /* 1 ms panel driver settling time */
> st,settling = <3>;
> /* 5 ms touch detect interrupt delay */
> st,touch-det-delay = <5>;
> };
> +
> + stmpe_adc {
> + compatible = "st,stmpe-adc";
> + /* 3.25 MHz ADC clock speed */
> + st,norequest-mask = <0x0F>;
> + };
> };
> };
>
> diff --git a/arch/arm/boot/dts/tegra30-apalis.dtsi
> b/arch/arm/boot/dts/tegra30-apalis.dtsi
> index 7f112f192fe9..850b0d13549a 100644
> --- a/arch/arm/boot/dts/tegra30-apalis.dtsi
> +++ b/arch/arm/boot/dts/tegra30-apalis.dtsi
> @@ -976,11 +976,18 @@
> id = <0>;
> blocks = <0x5>;
> irq-trigger = <0x1>;
> + /* 3.25 MHz ADC clock speed *
[PATCH] ubi: put MTD device after it is not used
The MTD device reference is dropped via put_mtd_device, however its field ->index is read and passed to ubi_msg. To fix this, the patch moves the reference dropping after calling ubi_msg. Signed-off-by: Pan Bian --- drivers/mtd/ubi/build.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c index a4e3454..09170b7 100644 --- a/drivers/mtd/ubi/build.c +++ b/drivers/mtd/ubi/build.c @@ -1101,10 +1101,10 @@ int ubi_detach_mtd_dev(int ubi_num, int anyway) ubi_wl_close(ubi); ubi_free_internal_volumes(ubi); vfree(ubi->vtbl); - put_mtd_device(ubi->mtd); vfree(ubi->peb_buf); vfree(ubi->fm_buf); ubi_msg(ubi, "mtd%d is detached", ubi->mtd->index); + put_mtd_device(ubi->mtd); put_device(&ubi->dev); return 0; } -- 2.7.4
Re: [PATCH v2 0/6] RFC: gup+dma: tracking dma-pinned pages
On 11/27/18 5:21 PM, Tom Talpey wrote: > On 11/21/2018 5:06 PM, John Hubbard wrote: >> On 11/21/18 8:49 AM, Tom Talpey wrote: >>> On 11/21/2018 1:09 AM, John Hubbard wrote: On 11/19/18 10:57 AM, Tom Talpey wrote: [...] >>> >>> What I'd really like to see is to go back to the original fio parameters >>> (1 thread, 64 iodepth) and try to get a result that gets at least close >>> to the speced 200K IOPS of the NVMe device. There seems to be something >>> wrong with yours, currently. >> >> I'll dig into what has gone wrong with the test. I see fio putting data files >> in the right place, so the obvious "using the wrong drive" is (probably) >> not it. Even though it really feels like that sort of thing. We'll see. >> >>> >>> Then of course, the result with the patched get_user_pages, and >>> compare whichever of IOPS or CPU% changes, and how much. >>> >>> If these are within a few percent, I agree it's good to go. If it's >>> roughly 25% like the result just above, that's a rocky road. >>> >>> I can try this after the holiday on some basic hardware and might >>> be able to scrounge up better. Can you post that github link? >>> >> >> Here: >> >> g...@github.com:johnhubbard/linux (branch: gup_dma_testing) > > I'm super-limited here this week hardware-wise and have not been able > to try testing with the patched kernel. > > I was able to compare my earlier quick test with a Bionic 4.15 kernel > (400K IOPS) against a similar 4.20rc3 kernel, and the rate dropped to > ~_375K_ IOPS. Which I found perhaps troubling. But it was only a quick > test, and without your change. > So just to double check (again): you are running fio with these parameters, right? [reader] direct=1 ioengine=libaio blocksize=4096 size=1g numjobs=1 rw=read iodepth=64 > Say, that branch reports it has not had a commit since June 30. Is that > the right one? What about gup_dma_for_lpc_2018? > That's the right branch, but the AuthorDate for the head commit (only) somehow got stuck in the past. I just now amended that patch with a new date and pushed it, so the head commit now shows Nov 27: https://github.com/johnhubbard/linux/commits/gup_dma_testing The actual code is the same, though. (It is still based on Nov 19th's f2ce1065e767 commit.) thanks, -- John Hubbard NVIDIA
[PATCH] Input: xpad - quirk all PDP Xbox One gamepads
Since we continue to find tons of new variants [0,1,2,3,4,5,6] that
need the PDP quirk, let's just quirk all devices from PDP.
[0]: https://github.com/paroj/xpad/pull/104
[1]: https://github.com/paroj/xpad/pull/105
[2]: https://github.com/paroj/xpad/pull/108
[3]: https://github.com/paroj/xpad/pull/109
[4]: https://github.com/paroj/xpad/pull/112
[5]: https://github.com/paroj/xpad/pull/115
[6]: https://github.com/paroj/xpad/pull/116
Fixes: e5c9c6a885fa ("Input: xpad - add support for PDP Xbox One controllers")
Cc: sta...@vger.kernel.org
Signed-off-by: Cameron Gutman
---
Dmitry,
This patch applies to your for-linus branch, since another PDP
quirked device was added there.
Regards,
Cameron
---
drivers/input/joystick/xpad.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index d4b9db487b16..cfc8b94527b9 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -480,18 +480,18 @@ static const u8 xboxone_hori_init[] = {
};
/*
- * This packet is required for some of the PDP pads to start
+ * This packet is required for most (all?) of the PDP pads to start
* sending input reports. These pads include: (0x0e6f:0x02ab),
- * (0x0e6f:0x02a4).
+ * (0x0e6f:0x02a4), (0x0e6f:0x02a6).
*/
static const u8 xboxone_pdp_init1[] = {
0x0a, 0x20, 0x00, 0x03, 0x00, 0x01, 0x14
};
/*
- * This packet is required for some of the PDP pads to start
+ * This packet is required for most (all?) of the PDP pads to start
* sending input reports. These pads include: (0x0e6f:0x02ab),
- * (0x0e6f:0x02a4).
+ * (0x0e6f:0x02a4), (0x0e6f:0x02a6).
*/
static const u8 xboxone_pdp_init2[] = {
0x06, 0x20, 0x00, 0x02, 0x01, 0x00
@@ -527,12 +527,8 @@ static const struct xboxone_init_packet
xboxone_init_packets[] = {
XBOXONE_INIT_PKT(0x0e6f, 0x0165, xboxone_hori_init),
XBOXONE_INIT_PKT(0x0f0d, 0x0067, xboxone_hori_init),
XBOXONE_INIT_PKT(0x, 0x, xboxone_fw2015_init),
- XBOXONE_INIT_PKT(0x0e6f, 0x02ab, xboxone_pdp_init1),
- XBOXONE_INIT_PKT(0x0e6f, 0x02ab, xboxone_pdp_init2),
- XBOXONE_INIT_PKT(0x0e6f, 0x02a4, xboxone_pdp_init1),
- XBOXONE_INIT_PKT(0x0e6f, 0x02a4, xboxone_pdp_init2),
- XBOXONE_INIT_PKT(0x0e6f, 0x02a6, xboxone_pdp_init1),
- XBOXONE_INIT_PKT(0x0e6f, 0x02a6, xboxone_pdp_init2),
+ XBOXONE_INIT_PKT(0x0e6f, 0x, xboxone_pdp_init1),
+ XBOXONE_INIT_PKT(0x0e6f, 0x, xboxone_pdp_init2),
XBOXONE_INIT_PKT(0x24c6, 0x541a, xboxone_rumblebegin_init),
XBOXONE_INIT_PKT(0x24c6, 0x542a, xboxone_rumblebegin_init),
XBOXONE_INIT_PKT(0x24c6, 0x543a, xboxone_rumblebegin_init),
--
2.19.1
Re: [PATCH 03/10] ARM64: dts: fsl: Add all CPUs in cooling maps
On Fri, Nov 16, 2018 at 03:34:26PM +0530, Viresh Kumar wrote: > Each CPU can (and does) participate in cooling down the system but the > DT only captures a handful of them, normally CPU0, in the cooling maps. > Things work by chance currently as under normal circumstances its the > first CPU of each cluster which is used by the operating systems to > probe the cooling devices. But as soon as this CPU ordering changes and > any other CPU is used to bring up the cooling device, we will start > seeing failures. > > Also the DT is rather incomplete when we list only one CPU in the > cooling maps, as the hardware doesn't have any such limitations. > > Update cooling maps to include all devices affected by individual trip > points. > > Signed-off-by: Viresh Kumar Applied, thanks.
Re: [PATCH 2/6] ARM: dts: ls1021a: Add all CPUs in cooling maps
On Fri, Nov 16, 2018 at 03:31:11PM +0530, Viresh Kumar wrote: > Each CPU can (and does) participate in cooling down the system but the > DT only captures a handful of them, normally CPU0, in the cooling maps. > Things work by chance currently as under normal circumstances its the > first CPU of each cluster which is used by the operating systems to > probe the cooling devices. But as soon as this CPU ordering changes and > any other CPU is used to bring up the cooling device, we will start > seeing failures. > > Also the DT is rather incomplete when we list only one CPU in the > cooling maps, as the hardware doesn't have any such limitations. > > Update cooling maps to include all devices affected by individual trip > points. > > Signed-off-by: Viresh Kumar Applied, thanks.
Re: [PATCH v4] arm64: dts: rockchip: Add DT for nanopc-t4
Hi Tomeu,
On 2018-11-27 9:07 am, Tomeu Vizoso wrote:
This adds a device tree for the NanoPC-T4 SBC, which is based on the
Rockchip RK3399 SoC and marketed by FriendlyELEC.
I'm happy to see this, as mine's been sat waiting until I could find
time to wrangle a mainline DT for it :)
Known working:
- Serial
- Ethernet
- HDMI
- USB 2.0
All of the interesting stuff is in a .dtsi because there are at least
two other boards that share most of it: NanoPi M4 and NanoPi NEO4.
TBH after picking through all 3 schematics, this looks to describe the
details of the M4 a lot more than it does the T4.
Signed-off-by: Tomeu Vizoso
---
v2: - Rename compatible from friendlyelec to friendlyarm, to match
existing bindings
- Remove superfluous node spi1
v3: - Rewrite regulator tree to match the schematics (Heiko)
- Sort top-level nodes alphabetically (Heiko)
- Used defines for GPIO numbers (Heiko)
- Enabled rga (Heiko)
- Removed cdn_dp node (Heiko)
- Removed dependencies to fusb0 as extcon (Heiko)
- Removed superfluous properties (Heiko)
v4: - Replace underscores in node names (Heiko)
- Reorder entry in makefile (Heiko)
- Remove superfluous properties and nodes (Heiko and Shawn)
- Use xin32k as one of the clock outputs of the RK808 (Heiko)
---
.../devicetree/bindings/arm/rockchip.txt | 4 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3399-nanopc-t4.dts| 18 +
.../boot/dts/rockchip/rk3399-nanopi4.dtsi | 732 ++
4 files changed, 755 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
b/Documentation/devicetree/bindings/arm/rockchip.txt
index 0cc71236d639..e907d309486e 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -71,6 +71,10 @@ Rockchip platforms device tree bindings
Required root node properties:
- compatible = "firefly,roc-rk3399-pc", "rockchip,rk3399";
+- FriendlyElec NanoPC-T4 board:
+Required root node properties:
+ - compatible = "friendlyarm,nanopc-t4", "rockchip,rk3399";
+
- ChipSPARK PopMetal-RK3288 board:
Required root node properties:
- compatible = "chipspark,popmetal-rk3288", "rockchip,rk3288";
diff --git a/arch/arm64/boot/dts/rockchip/Makefile
b/arch/arm64/boot/dts/rockchip/Makefile
index 49042c477870..19c129702e06 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -14,6 +14,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-ficus.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-firefly.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-bob.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-kevin.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-puma-haikou.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-roc-pc.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock960.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
b/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
new file mode 100644
index ..0965712b4464
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * FriendlyElec NanoPC-T4 board device tree source
+ *
+ * Copyright (c) 2018 FriendlyElec Computer Tech. Co., Ltd.
+ * (http://www.friendlyarm.com)
+ *
+ * Copyright (c) 2018 Collabora Ltd.
+ */
+
+/dts-v1/;
+#include "rk3399-nanopi4.dtsi"
+
+/ {
+ model = "FriendlyElec NanoPC-T4";
+ compatible = "friendlyarm,nanopc-t4", "rockchip,rk3399";
+};
+
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
new file mode 100644
index ..e10b98d637d3
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
@@ -0,0 +1,732 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * RK3399-based FriendlyElec boards device tree source
+ *
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Copyright (c) 2018 FriendlyElec Computer Tech. Co., Ltd.
+ * (http://www.friendlyarm.com)
+ *
+ * Copyright (c) 2018 Collabora Ltd.
+ */
+
+/dts-v1/;
+#include
+#include "rk3399.dtsi"
+#include "rk3399-opp.dtsi"
+
+/ {
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ clkin_gmac: external-gmac-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <12500>;
+ clock-output-names = "clkin_gmac";
+ #clock-cells = <0>;
+ };
+
+ vdd_5v: vdd-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_5v";
+ regulator-always-on;
+ regulator-boot-on;
+ };
This doesn't exist on the T4 - VCC5V0_SYS is g
[PATCH] ARM: dts: uniphier: add MIO DMAC nodes
Add MIO-DMAC (Media IO DMA Controller) nodes, and use them as
the DMA engine of SD/eMMC controllers.
Signed-off-by: Masahiro Yamada
---
arch/arm/boot/dts/uniphier-ld4.dtsi | 14 ++
arch/arm/boot/dts/uniphier-pro4.dtsi | 16
arch/arm/boot/dts/uniphier-sld8.dtsi | 14 ++
3 files changed, 44 insertions(+)
diff --git a/arch/arm/boot/dts/uniphier-ld4.dtsi
b/arch/arm/boot/dts/uniphier-ld4.dtsi
index b73d594..c2706ce 100644
--- a/arch/arm/boot/dts/uniphier-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ld4.dtsi
@@ -235,6 +235,16 @@
};
};
+ dmac: dma-controller@5a00 {
+ compatible = "socionext,uniphier-mio-dmac";
+ reg = <0x5a00 0x1000>;
+ interrupts = <0 68 4>, <0 68 4>, <0 69 4>, <0 70 4>,
+<0 71 4>, <0 72 4>, <0 73 4>;
+ clocks = <&mio_clk 7>;
+ resets = <&mio_rst 7>;
+ #dma-cells = <1>;
+ };
+
sd: sdhc@5a40 {
compatible = "socionext,uniphier-sd-v2.91";
status = "disabled";
@@ -246,6 +256,8 @@
clocks = <&mio_clk 0>;
reset-names = "host", "bridge";
resets = <&mio_rst 0>, <&mio_rst 3>;
+ dma-names = "rx-tx";
+ dmas = <&dmac 4>;
bus-width = <4>;
cap-sd-highspeed;
sd-uhs-sdr12;
@@ -263,6 +275,8 @@
clocks = <&mio_clk 1>;
reset-names = "host", "bridge", "hw";
resets = <&mio_rst 1>, <&mio_rst 4>, <&mio_rst 6>;
+ dma-names = "rx-tx";
+ dmas = <&dmac 6>;
bus-width = <8>;
cap-mmc-highspeed;
cap-mmc-hw-reset;
diff --git a/arch/arm/boot/dts/uniphier-pro4.dtsi
b/arch/arm/boot/dts/uniphier-pro4.dtsi
index 0beb606..97d051e 100644
--- a/arch/arm/boot/dts/uniphier-pro4.dtsi
+++ b/arch/arm/boot/dts/uniphier-pro4.dtsi
@@ -269,6 +269,16 @@
};
};
+ dmac: dma-controller@5a00 {
+ compatible = "socionext,uniphier-mio-dmac";
+ reg = <0x5a00 0x1000>;
+ interrupts = <0 68 4>, <0 68 4>, <0 69 4>, <0 70 4>,
+<0 71 4>, <0 72 4>, <0 73 4>, <0 74 4>;
+ clocks = <&mio_clk 7>;
+ resets = <&mio_rst 7>;
+ #dma-cells = <1>;
+ };
+
sd: sdhc@5a40 {
compatible = "socionext,uniphier-sd-v2.91";
status = "disabled";
@@ -280,6 +290,8 @@
clocks = <&mio_clk 0>;
reset-names = "host", "bridge";
resets = <&mio_rst 0>, <&mio_rst 3>;
+ dma-names = "rx-tx";
+ dmas = <&dmac 4>;
bus-width = <4>;
cap-sd-highspeed;
sd-uhs-sdr12;
@@ -297,6 +309,8 @@
clocks = <&mio_clk 1>;
reset-names = "host", "bridge", "hw";
resets = <&mio_rst 1>, <&mio_rst 4>, <&mio_rst 6>;
+ dma-names = "rx-tx";
+ dmas = <&dmac 5>;
bus-width = <8>;
cap-mmc-highspeed;
cap-mmc-hw-reset;
@@ -313,6 +327,8 @@
clocks = <&mio_clk 2>;
reset-names = "host", "bridge";
resets = <&mio_rst 2>, <&mio_rst 5>;
+ dma-names = "rx-tx";
+ dmas = <&dmac 6>;
bus-width = <4>;
cap-sd-highspeed;
};
diff --git a/arch/arm/boot/dts/uniphier-sld8.dtsi
b/arch/arm/boot/dts/uniphier-sld8.dtsi
index f7fcf6b..efce027 100644
--- a/arch/arm/boot/dts/uniphier-sld8.dtsi
+++ b/arch/arm/boot/dts/uniphier-sld8.dtsi
@@ -239,6 +239,16 @@
};
};
+ dmac: dma-controller@5a00 {
+ compatible = "socionext,uniphier-mio-dmac";
+ reg = <0x5a00 0x1000>;
+ interrupts = <0 68 4>, <0 68 4>, <0 69 4>, <0 70 4>,
+<0 71 4>, <0 72 4>, <0 73 4>;
+ clocks = <&mio_clk 7>;
+ resets = <&mio_rst 7>;
+ #dma-cells = <1>;
+ };
+
sd: sdhc@5a40 {
compatible = "socionext,uniphier-sd-v2.91";
Re: [PATCH] ARM: dts: imx: Add Y Soft IOTA Draco, Hydra and Ursa boards
On Thu, Nov 01, 2018 at 03:43:26PM +, Vokáč Michal wrote:
...
> +&usdhc3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc3>;
> + bus-width = <4>;
> + cd-gpios = <&gpio7 8 GPIO_ACTIVE_LOW>;
> + wp-gpios = <&gpio2 22 GPIO_ACTIVE_HIGH>;
> + no-1-8-v;
> + keep-power-in-suspend;
> + enable-sdio-wakeup;
This property is deprecated. Please use "wakeup-source" instead.
Shawn
> + vmmc-supply = <&sw2_reg>;
> + status = "disabled";
> +};
Re: [PATCH] tty: serial: qcom_geni_serial: Fix softlock
On Tue, Nov 27, 2018 at 6:04 PM Stephen Boyd wrote:
>
> Quoting Ryan Case (2018-11-27 17:24:44)
> > On Tue, Nov 27, 2018 at 4:20 PM Stephen Boyd wrote:
> > >
> > > Quoting Ryan Case (2018-11-26 18:25:36)
> > > > Transfers were being divided into device FIFO sized (64 byte max)
> > > > operations which would poll for completion within a spin_lock_irqsave /
> > > > spin_unlock_irqrestore block. This both made things slow by waiting for
> > > > the FIFO to completely drain before adding further data and would also
> > > > result in softlocks on large transmissions.
> > > >
> > > > This patch allows larger transfers with continuous FIFO additions as
> > > > space becomes available and removes polling from the interrupt handler.
> > > >
> > > > Signed-off-by: Ryan Case
> > > > Version: 1
> > >
> > > I've never seen a Version tag before. Did you manually add this?
> >
> > I submitted with patman, this should have been Series-version:
>
> Hmm ok. I'm not aware of this being a kernel idiom so I would remove
> this tag before sending.
Yup. Series-version: would be properly parsed out and adds the
v1/v2/etc... tags so this won't show up in the v2.
>
> >
> > >
> > > >
> > > > WARN_ON(co->index < 0 || co->index >= GENI_UART_CONS_PORTS);
> > > >
> > > > @@ -465,9 +470,17 @@ static void qcom_geni_serial_console_write(struct
> > > > console *co, const char *s,
> > > > }
> > > > writel_relaxed(M_CMD_CANCEL_EN, uport->membase +
> > > >
> > > > SE_GENI_M_IRQ_CLEAR);
> > > > - }
> > > > + } else if ((geni_status & M_GENI_CMD_ACTIVE) &&
> > > > !port->cur_tx_remaining)
> > > > + /* It seems we can interrupt existing transfers unless
> > > > all data
> > >
> > > Nitpick: Have /* on a line by itself
> > >
> > > Is this comment supposed to say "we can't interrupt existing transfers"?
> >
> > Nope, comment is correct as is.
>
> Ok. I fail at parsing it then. Perhaps
>
> "It seems we can interrupt existing transfers except for when all data
> has been sent"
>
> would make it easier for me to read.
>
> >
> > >
> > > >
> > > > __qcom_geni_serial_console_write(uport, s, count);
> > > > +
> > > > + if (port->cur_tx_remaining)
> > > > + qcom_geni_serial_setup_tx(uport,
> > > > port->cur_tx_remaining);
> > >
> > > Does this happen? Is the console being used as a tty at the same time?
> >
> > Yup, happens quite a bit.
>
> So its being used in both modes at the same time?
Yes.
>
> >
> > >
> > > > +
> > > > if (locked)
> > > > spin_unlock_irqrestore(&uport->lock, flags);
> > > > }
> > > > @@ -701,40 +714,47 @@ static void qcom_geni_serial_handle_rx(struct
> > > > uart_port *uport, bool drop)
> > > > port->handle_rx(uport, total_bytes, drop);
> > > > }
> > > >
> > > > -static void qcom_geni_serial_handle_tx(struct uart_port *uport)
> > > > +static void qcom_geni_serial_handle_tx(struct uart_port *uport, bool
> > > > done,
> > > > + bool active)
> > > > {
> > > > struct qcom_geni_serial_port *port = to_dev_port(uport, uport);
> > > > struct circ_buf *xmit = &uport->state->xmit;
> > > > size_t avail;
> > > > size_t remaining;
> > > > + size_t pending;
> > > > int i;
> > > > u32 status;
> > > > unsigned int chunk;
> > > > int tail;
> > > > - u32 irq_en;
> > > >
> > > > - chunk = uart_circ_chars_pending(xmit);
> > > > status = readl_relaxed(uport->membase + SE_GENI_TX_FIFO_STATUS);
> > > > - /* Both FIFO and framework buffer are drained */
> > > > - if (!chunk && !status) {
> > > > +
> > > > + /* Complete the current tx command before taking newly added
> > > > data */
> > > > + if (active)
> > > > + pending = port->cur_tx_remaining;
> > > > + else
> > > > + pending = uart_circ_chars_pending(xmit);
> > > > +
> > > > + /* All data has been transmitted and acknowledged as received */
> > > > + if (!pending && !status && done) {
> > >
> > > Nitpick: status is a poor variable name to test here. I don't understand
> > > what this line is doing. Maybe it would help to have another local
> > > variable like 'needs_attention'?
> >
> > It could be renamed but since this isn't a general file cleanup patch
> > I was avoiding non-functional changes. It is the TX_FIFO_STATUS
> > register, if non-zero there is still data in the FIFO or related
> > activity ongoing.
>
> Ok.
>
> >
> > >
> > > > qcom_geni_serial_stop_tx(uport);
> > > > goto out_write_wakeup;
> > > > }
> > > >
> > > > - if (!uart_console(uport)) {
> > > > - irq_en = readl_relaxed(uport->membase +
> > > > SE_GENI_M_IRQ_EN);
> > > > - irq_en &= ~(M_TX_FIFO_WATERMARK_EN);
> > > > - writel_relaxed(0, uport->membase +
> > > > SE_GENI_TX_WATERMAR
Re: [PATCH v5 4/5] arm64: dts: qcom: sdm845: Add UFS nodes for sdm845-mtp
Quoting Bjorn Andersson (2018-11-21 23:04:12)
> On Mon 19 Nov 11:42 PST 2018, Stephen Boyd wrote:
> >
> > A workaround for this somewhat rare case would be to specify
> > /delete-property/ on those nodes that aren't used. Unless that can't
> > even work because the phandle is parsed before properties are deleted? I
> > haven't tried. Or we could try to have dtc ignore broken phandles in
> > status = "disabled" nodes or omit them entirely from the dtb so this
> > isn't a problem.
> >
> > Either way, I would push for making it easier for the users of the SoC
> > to not need to know the SoC internal details too much and rely on the
> > SoC dtsi file to get it right. From the user perspective it's just a
> > bunch of pins connected to something. We could also have a 0 volt
> > "ground" regulator for any grounded/unconnected pins if that helps. It
> > could be marked as status = "disabled" so that no runtime code is used
> > while dtc is still happy to have the disabled node with a label.
> >
>
> I dislike the use of the labels "vdda_ufs1_core" as that doesn't tell me
> which regulator this is actually wired to, without having to jump around
> in the board dts file. It's annoying, but it's pretty much write-once so
> it's not a big issue.
>
> But I really don't like the idea of having sdm845.dtsi depend on labels
> specified in the board dtsi. This just means that in order to add a new
> board I need to figure out the information and the way to specify it is
> to change a label in the board file.
>
>
> The static configuration here is that vdda-phy-supply is connected to
> the vdda_ufs1_core pin on the SoC, which is connected to some board
> specific regulator. If anything I think we should model that
> intermediate entity, in which case we could move the link between the
> phy and the pin to the platform dtsi.
>
Hmm alright. This is a similar problem that the DT connectors have with
phandle remapping through the connector to the actual phandle that is
desired. I can think of two solutions. One would be to make a
phandle-map binding to remap phandles within the soc node to actually be
another phandle. The downside is that we need to make nodes for
everything just to remap them. For example:
soc {
phandle-map {
vdda_ufs1_core: vdda-ufs1-core {
}
};
};
In the SoC dtsi file and then
&vdda_ufs1_core {
phandle-alias = <&pm8998_ldo19>
};
Would be in the board specific dtsi file.
The regulator code to fix that up is rather simple, but not generic. It
just walks the chain of alias nodes until it doesn't find anything else.
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index 210fc20f7de7..9c1346374351 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -432,6 +432,15 @@ static int of_node_match(struct device *dev, const void
*data)
struct regulator_dev *of_find_regulator_by_node(struct device_node *np)
{
struct device *dev;
+ struct device_node *aliased_np;
+
+ do {
+ aliased_np = of_parse_phandle(np, "phandle-alias", 0);
+
+ if (aliased_np)
+ np = aliased_np;
+
+ } while (aliased_np);
dev = class_find_device(®ulator_class, NULL, np, of_node_match);
Another idea would be to have a phandle nexus node that converts
phandles into some #cells property. This way, we can make the regulator
supply binding parse the cells of the nexus node and figure out that the
next specifier after it corresponds to something that needs to be set in
the nexus node by the board.
soc {
soc_regulator: regulator-nexus {
#regulator-cells = <1>;
#define VDDA_UFS1_CORE 0
};
ufs {
vdda-supply = <&soc_regulator VDDA_UFS1_CORE>;
};
};
In the SoC dtsi file and then
&soc_regulator {
regulator-map =
}
And then some parsing code in regulator core to remap the cells on the
left side to the phandle on the right of the cells. I suppose that makes
things sort of awkward and makes the binding look different depending on
if the node has the #regulator-cells property or not for the supply
binding.
Another idea would be to have dts phandle fixups applied somehow when
the DT is loaded by the kernel or possibly bootloader or extra
efficiently with a compiler change. So then we can alias labels to
different labels in the board file.
So in the board dtsi file we would have something like
soc {
phandle-map {
vdda-ufs1-core = <&pm8998_ldo19>;
};
};
and the SoC dtsi file would have:
soc {
phandle-map {
vdda_ufs1_core: vdda-ufs1-core = <0>;
}
linux-kernel@vger.kernel.org has been hacked! Change your password immediately!
Hello! I have very bad news for you. 03/08/2018 - on this day I hacked your OS and got full access to your account linux-kernel@vger.kernel.org On this day your account linux-kernel@vger.kernel.org has password: qwerty So, you can change the password, yes.. But my malware intercepts it every time. How I made it: In the software of the router, through which you went online, was a vulnerability. I just hacked this router and placed my malicious code on it. When you went online, my trojan was installed on the OS of your device. After that, I made a full dump of your disk (I have all your address book, history of viewing sites, all files, phone numbers and addresses of all your contacts). A month ago, I wanted to lock your device and ask for a not big amount of btc to unlock. But I looked at the sites that you regularly visit, and I was shocked by what I saw!!! I'm talk you about sites for adults. I want to say - you are a BIG pervert. Your fantasy is shifted far away from the normal course! And I got an idea I made a screenshot of the adult sites where you have fun (do you understand what it is about, huh?). After that, I made a screenshot of your joys (using the camera of your device) and glued them together. Turned out amazing! You are so spectacular! I'm know that you would not like to show these screenshots to your friends, relatives or colleagues. I think $700 is a very, very small amount for my silence. Besides, I have been spying on you for so long, having spent a lot of time! Pay ONLY in Bitcoins! My BTC wallet: 1FgfdebSqbXRciP2DXKJyqPSffX3Sx57RF You do not know how to use bitcoins? Enter a query in any search engine: "how to replenish btc wallet". It's extremely easy For this payment I give you two days (48 hours). As soon as this letter is opened, the timer will work. After payment, my virus and dirty screenshots with your enjoys will be self-destruct automatically. If I do not receive from you the specified amount, then your device will be locked, and all your contacts will receive a screenshots with your "enjoys". I hope you understand your situation. - Do not try to find and destroy my virus! (All your data, files and screenshots is already uploaded to a remote server) - Do not try to contact me (you yourself will see that this is impossible, the sender address is automatically generated) - Various security services will not help you; formatting a disk or destroying a device will not help, since your data is already on a remote server. P.S. You are not my single victim. so, I guarantee you that I will not disturb you again after payment! This is the word of honor hacker I also ask you to regularly update your antiviruses in the future. This way you will no longer fall into a similar situation. Do not hold evil! I just do my job. Good luck.
Re: File not found: /sys/kernel/debug/tracing/events/syscalls
Hi Masami San,
Thanks for the patch it solved the problem.
On Tue, 27 Nov 2018 at 21:41, Masami Hiramatsu
wrote:
>
> Hi,
>
> I found that the commit 4378a7d4be30 ("arm64: implement syscall
> wrappers") changed
> the syscall wrapper function names by adding __arm64_ prefix. So arm64
> kernel should
> have its own arch_syscall_match_sym_name().
arm64: ftrace: Fix to enable syscall events on arm64
From: Masami Hiramatsu
Since commit 4378a7d4be30 ("arm64: implement syscall wrappers")
introduced "__arm64_" prefix to all syscall wrapper symbols in
sys_call_table, syscall tracer can not find corresponding
metadata from syscall name. In the result, we have no syscall
ftrace events on arm64 kernel, and some bpf testcases are failed
on arm64.
To fix this issue, this introduces custom
arch_syscall_match_sym_name() which skips first 8 bytes when
comparing the syscall and symbol names.
Fixes: 4378a7d4be30 ("arm64: implement syscall wrappers")
Signed-off-by: Masami Hiramatsu
Reported-by: Naresh Kamboju
Tested-by: Naresh Kamboju
---
arch/arm64/include/asm/ftrace.h |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/include/asm/ftrace.h b/arch/arm64/include/asm/ftrace.h
index caa955f10e19..a710f79db442 100644
--- a/arch/arm64/include/asm/ftrace.h
+++ b/arch/arm64/include/asm/ftrace.h
@@ -56,6 +56,15 @@ static inline bool
arch_trace_is_compat_syscall(struct pt_regs *regs)
{
return is_compat_task();
}
+
+#define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
+
+static inline bool arch_syscall_match_sym_name(const char *sym,
+ const char *name)
+{
+ /* Since all syscall functions have __arm64_ prefix, we must skip it */
+ return !strcmp(sym + 8, name);
+}
#endif /* ifndef __ASSEMBLY__ */
#endif /* __ASM_FTRACE_H */
>
> Thank you,
>
> 2018年11月28日(水) 0:22 Naresh Kamboju :
> >
> > While debugging the selftests/bpf: get_cgroup_id_user test failure on arm64
> > where the test is expecting trace file
> > /sys/kernel/debug/tracing/events/syscalls/sys_enter_nanosleep/id
> > but this path not enabled after enabling required kernel configuration also.
> > CONFIG_FTRACE_SYSCALLS=y
> >
> > strace output:
> > open(\"/sys/kernel/debug/tracing/events/syscalls/sys_enter_nanosleep/id\",
> > O_RDONLY) = -1 ENOENT (No such file or directory)
> >
> > This problem noticed on Linux mainline kernel version 4.20.0-rc3.
> >
> > Best regards
> > Naresh Kamboju
>
>
>
> --
> Masami Hiramatsu
Re: [PATCH v7 09/16] tracing: Add hist trigger snapshot() action test case
Hi Tom, On Tue, 27 Nov 2018 16:53:45 -0600 Tom Zanussi wrote: > > > +ping $LOCALHOST -c 3 > > > +nice -n 1 ping $LOCALHOST -c 3 > > > + > > > +echo 0 > /sys/kernel/debug/tracing/events/sched/enable > > > > Shouldn't we stop tracing instead of disabling the event? > > > > This is just reversing the enable, so should be fine, but I can stop > tracing instead if you prefer. Oops, maybe we have to check the difference between event enabling and trace enabling. echo 0 > tracing_on will stop writing ring buffer, but event may continue to be called. Does this mean hist will be updated? (and I guess preferrable behavior is to stop hist too, isn't it?) Thank you, -- Masami Hiramatsu
Re: [RFC PATCH 0/1] support ftrace and -ffunction-sections
On Tue, 27 Nov 2018 15:27:14 -0500 Joe Lawrence wrote: > Gentle ping... I took a dive through the rhkl-archives and found a few > older discussions: Thanks for the reminder, my INBOX is totally out of control with Plumbers followed by Turkey Day. > > [PATCH] scripts/recordmcount.pl: Support build with -ffunction-sections. > > https://lore.kernel.org/lkml/CAFbHwiRtBaHkpZqTm6VZ=fCJcyu+dsdpo_kxMHy1egce=rt...@mail.gmail.com/ > > and related LWN article: > > The source of the e1000e corruption bug > https://lwn.net/Articles/304105/ > > Catching up with those, I assume that this has never been implemented in > the past due to fear of ftrace modifying a potentially freed section > (and bricking NICs in the process :( Actually, we have a lot more safe guards against that today. > > Looking through the kernel sources (like Will in 2008) I don't see any > code jumping out at me that frees code other than .init. However a > quick code inspection is no guarantee. > > Assuming the same use-after-free reservation holds true today: > > 1: Is there any reasonable way to mark code sections (pages?) as > in-use to avoid memory freeing mechanisms from releasing them? The > logic for .init is mostly arch-specific, so there could be many > different ways random arches may try to pull this off. > > 2: Would/could it be safer to restrict __mcount_loc detection of > ".text.*" sections to modules? The recordmcount.pl script already > knows about is_module... that information could be provided to > recordmcount.c as well for consideration. I'm fine with just applying your patch. Today, for x86, there's a gcc option that adds the __mcount_loc automatically without doing any whitelisting (it doesn't run recordmcount.*). It just adds anything that is traced, thus it has to work for all possible cases now. -- Steve
Re: [PATCH v8 1/4] ARM: dts: imx: Add an cpu0 label for imx6dl devices.
On Tue, Nov 27, 2018 at 04:04:01PM +0100, Jan Tuerk wrote: > Adding the label cpu0 allows the adjustment of cpu-parameters > by reference in overlaying dtsi files in the same way as it > is possible for imx6q devices. > > Signed-off-by: Jan Tuerk > Reviewed-by: Andreas Färber Applied all, thanks.
Re: [PATCH] tty: serial: qcom_geni_serial: Fix softlock
Quoting Ryan Case (2018-11-27 17:24:44)
> On Tue, Nov 27, 2018 at 4:20 PM Stephen Boyd wrote:
> >
> > Quoting Ryan Case (2018-11-26 18:25:36)
> > > Transfers were being divided into device FIFO sized (64 byte max)
> > > operations which would poll for completion within a spin_lock_irqsave /
> > > spin_unlock_irqrestore block. This both made things slow by waiting for
> > > the FIFO to completely drain before adding further data and would also
> > > result in softlocks on large transmissions.
> > >
> > > This patch allows larger transfers with continuous FIFO additions as
> > > space becomes available and removes polling from the interrupt handler.
> > >
> > > Signed-off-by: Ryan Case
> > > Version: 1
> >
> > I've never seen a Version tag before. Did you manually add this?
>
> I submitted with patman, this should have been Series-version:
Hmm ok. I'm not aware of this being a kernel idiom so I would remove
this tag before sending.
>
> >
> > >
> > > WARN_ON(co->index < 0 || co->index >= GENI_UART_CONS_PORTS);
> > >
> > > @@ -465,9 +470,17 @@ static void qcom_geni_serial_console_write(struct
> > > console *co, const char *s,
> > > }
> > > writel_relaxed(M_CMD_CANCEL_EN, uport->membase +
> > >
> > > SE_GENI_M_IRQ_CLEAR);
> > > - }
> > > + } else if ((geni_status & M_GENI_CMD_ACTIVE) &&
> > > !port->cur_tx_remaining)
> > > + /* It seems we can interrupt existing transfers unless
> > > all data
> >
> > Nitpick: Have /* on a line by itself
> >
> > Is this comment supposed to say "we can't interrupt existing transfers"?
>
> Nope, comment is correct as is.
Ok. I fail at parsing it then. Perhaps
"It seems we can interrupt existing transfers except for when all data
has been sent"
would make it easier for me to read.
>
> >
> > >
> > > __qcom_geni_serial_console_write(uport, s, count);
> > > +
> > > + if (port->cur_tx_remaining)
> > > + qcom_geni_serial_setup_tx(uport, port->cur_tx_remaining);
> >
> > Does this happen? Is the console being used as a tty at the same time?
>
> Yup, happens quite a bit.
So its being used in both modes at the same time?
>
> >
> > > +
> > > if (locked)
> > > spin_unlock_irqrestore(&uport->lock, flags);
> > > }
> > > @@ -701,40 +714,47 @@ static void qcom_geni_serial_handle_rx(struct
> > > uart_port *uport, bool drop)
> > > port->handle_rx(uport, total_bytes, drop);
> > > }
> > >
> > > -static void qcom_geni_serial_handle_tx(struct uart_port *uport)
> > > +static void qcom_geni_serial_handle_tx(struct uart_port *uport, bool
> > > done,
> > > + bool active)
> > > {
> > > struct qcom_geni_serial_port *port = to_dev_port(uport, uport);
> > > struct circ_buf *xmit = &uport->state->xmit;
> > > size_t avail;
> > > size_t remaining;
> > > + size_t pending;
> > > int i;
> > > u32 status;
> > > unsigned int chunk;
> > > int tail;
> > > - u32 irq_en;
> > >
> > > - chunk = uart_circ_chars_pending(xmit);
> > > status = readl_relaxed(uport->membase + SE_GENI_TX_FIFO_STATUS);
> > > - /* Both FIFO and framework buffer are drained */
> > > - if (!chunk && !status) {
> > > +
> > > + /* Complete the current tx command before taking newly added data
> > > */
> > > + if (active)
> > > + pending = port->cur_tx_remaining;
> > > + else
> > > + pending = uart_circ_chars_pending(xmit);
> > > +
> > > + /* All data has been transmitted and acknowledged as received */
> > > + if (!pending && !status && done) {
> >
> > Nitpick: status is a poor variable name to test here. I don't understand
> > what this line is doing. Maybe it would help to have another local
> > variable like 'needs_attention'?
>
> It could be renamed but since this isn't a general file cleanup patch
> I was avoiding non-functional changes. It is the TX_FIFO_STATUS
> register, if non-zero there is still data in the FIFO or related
> activity ongoing.
Ok.
>
> >
> > > qcom_geni_serial_stop_tx(uport);
> > > goto out_write_wakeup;
> > > }
> > >
> > > - if (!uart_console(uport)) {
> > > - irq_en = readl_relaxed(uport->membase + SE_GENI_M_IRQ_EN);
> > > - irq_en &= ~(M_TX_FIFO_WATERMARK_EN);
> > > - writel_relaxed(0, uport->membase +
> > > SE_GENI_TX_WATERMARK_REG);
> > > - writel_relaxed(irq_en, uport->membase + SE_GENI_M_IRQ_EN);
> > > - }
> > > + avail = port->tx_fifo_depth - (status & TX_FIFO_WC);
> > > + avail *= port->tx_bytes_pw;
> > > + if (avail < 0)
> > > + avail = 0;
> >
> > How can 'avail' be less than 0? It's size_t which is unsigned? If
> > underflow is happening from that subtraction or overflow from the
> > multiply that co
Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
Quoting Sugaya Taichi (2018-11-18 17:01:07)
> Add DT bindings document for Milbeaut trampoline.
>
> Signed-off-by: Sugaya Taichi
> ---
> .../devicetree/bindings/soc/socionext/socionext,m10v.txt | 12
>
> 1 file changed, 12 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
>
> diff --git
> a/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
> b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
> new file mode 100644
> index 000..f5d906c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
> @@ -0,0 +1,12 @@
> +Socionext M10V SMP trampoline driver binding
> +
> +This is a driver to wait for sub-cores while boot process.
> +
> +- compatible: should be "socionext,smp-trampoline"
> +- reg: should be <0x4C000100 0x100>
> +
> +EXAMPLE
> + trampoline: trampoline@0x4C000100 {
Drop the 0x part of unit addresses.
> + compatible = "socionext,smp-trampoline";
> + reg = <0x4C000100 0x100>;
Looks like a software construct, which we wouldn't want to put into DT
this way. DT doesn't describe drivers.
Re: ext4 file system corruption with v4.19.3 / v4.19.4
On Tue, Nov 27, 2018 at 01:22:55PM -0800, Guenter Roeck wrote: > On Tue, Nov 27, 2018 at 07:55:01PM +0100, Rainer Fiebig wrote: > > Am Dienstag, 27. November 2018, 15:48:19 schrieb Marek Habersack: > > > On 27/11/2018 15:32, Guenter Roeck wrote: > > > Hi, > > > > > > You might try to see if you have CONFIG_SCSI_MQ_DEFAULT=yes in your kernel > > > config. Starting with 4.19.1 it somehow interferes with ext4 and causes > > > problems similar to the ones you list below. Ever since I disabled MQ > > > (either recompile your kernel or add `scsi_mod.use_blk_mq=0` to the kernel > > > command line) none of those errors came back. > > > > > > hope it helps, > > > > > > marek > > > > Unfortunately, this doesn't seem to work in every case: > > https://bugzilla.kernel.org/show_bug.cgi?id=201685#c54 > > > > And I'm using a defconfig-4.19.3 (meaning: CONFIG_SCSI_MQ_DEFAULT=yes) in a > > VM > > and I'm not seeing those errors there. OK, it's a VM - but anyway. > > > > Agreed. I disabled CONFIG_SCSI_MQ_DEFAULT, but the problem is still seen > at least on one of my servers, so disabling it does not help, at least not > in my case. > > If the problem is somehow related to CONFIG_SCSI_MQ_DEFAULT, you might > have to explicitly use a scsi drive (virtio-scsi-pci or similar) to > trigger its use in a VM. > > Guenter > > > The definite cause of this can only be found by bisecting, IMO. And it > > needs > > to be pinned down because else some feeling of insecurity will remain. > > > > So long! > > > > Rainer Fiebig > > > > > > > > > [trying again, this time with correct kernel.org address] > > > > > > > > Hi, > > > > > > > > I have seen the following and similar problems several times, > > > > with both v4.19.3 and v4.19.4: > > > > > > > > Nov 23 04:32:25 mars kernel: [112668.673671] EXT4-fs error (device > > > > sdb1): > > > > ext4_iget:4831: inode #12602889: comm git: bad extra_isize 33661 (inode > > > > size 256) > > > > Nov 23 04:32:25 mars kernel: [112668.675217] Aborting journal on device > > > > sdb1-8. Nov 23 04:32:25 mars kernel: [112668.676681] EXT4-fs (sdb1): > > > > Remounting filesystem read-only Nov 23 04:32:25 mars kernel: > > > > [112668.808886] EXT4-fs error (device sdb1): ext4_iget:4831: inode > > > > #12602881: comm rm: bad extra_isize 33685 (inode size 256) > > > > ... > > > > > > > > Nov 25 00:12:43 saturn kernel: [59377.725984] EXT4-fs error (device > > > > sda1): > > > > ext4_lookup:1578: inode #238034131: comm updatedb.mlocat: deleted inode > > > > referenced: 238160407 > > > > Nov 25 00:12:43 saturn kernel: [59377.766638] Aborting journal on device > > > > sda1-8. Nov 25 00:12:43 saturn kernel: [59377.779372] EXT4-fs (sda1): > > > > Remounting filesystem read-only ... > > > > > > > > Nov 24 01:52:31 saturn kernel: [189085.240016] EXT4-fs error (device > > > > sda1): ext4_lookup:1578: inode #52038457: comm nfsd: deleted inode > > > > referenced: 52043796 > > > > Nov 24 01:52:31 saturn kernel: [189085.263427] Aborting journal on > > > > device > > > > sda1-8. Nov 24 01:52:31 saturn kernel: [189085.275313] EXT4-fs (sda1): > > > > Remounting filesystem read-only > > > > > > > > > > > > The same systems running v4.18.6 never experienced a problem. > > > > > > > > Has anyone else seen similar problems ? Is there anything I can do > > > > to help tracking down the problem ? > > > > > > > > Thanks, > > > > Guenter > > Not sure how relevant this is, but I had emailed the list earlier in the month reporting totally bogus fs/SATA errors following an fstrim in 4.19. I didn't have much information to add, as the logs were all lost, and I didn't have any interest in trying to reproduce it on my daily driven laptop. I've just been running 4.17 since then (4.18 has some annoying i915 drm bugs), and things have been perfectly fine in the storage/filesystem department. What I had noticed as being suspect back then was the following: $ git tag --contains 744889b7cbb56a6 v4.19 v4.19.1 v4.19.2 v4.19.3 v4.19.4 v4.19.5 v4.20-rc1 v4.20-rc2 v4.20-rc3 v4.20-rc4 $ git tag --contains 1adfc5e4136f5967 v4.20-rc2 v4.20-rc3 v4.20-rc4 $ Since the 744889b7 commit message talks specifically about discard, and 1adfc5e4 claims to fix 744889b7, I assumed it was probably responsible considering the tags profile, but did not try understand the commits or bisect. FYI the machine I observed this on is a SATA-attached SSD (Samsung 840 EVO 250G) X61s. I only run fstrim manually, but of course with discard enabled all the way down the lvm+dmcrypt stack. Maybe that's of use in hunting down this bug. If nobody else bisects in the coming weeks I'll have to reconsider the rigamarole of backups, repro, and attempting a bisect. Regards, Vito Caputo
Re: [RFC PATCH] of: make MAX_RESERVED_REGIONS configurable
On Mon, 2018-11-26 at 09:33 +0800, Miles Chen wrote:
> On Sat, 2018-11-24 at 14:56 -0600, Rob Herring wrote:
> > On Wed, Nov 21, 2018 at 8:51 PM Miles Chen wrote:
> > >
> > > On Wed, 2018-11-21 at 10:39 -0600, Rob Herring wrote:
> > > > On Wed, Nov 21, 2018 at 2:11 AM wrote:
> > > > >
> > > > > From: Miles Chen
> > > > >
> > > > > When we use more than 32 entries in /resered-memory,
> > > > > there will be an error message: "not enough space all defined
> > > > > regions.".
> > > > > We can increase MAX_RESERVED_REGIONS to fix this.
> > > > >
> > > > > commit 22f8cc6e3373 ("drivers: of: increase MAX_RESERVED_REGIONS to
> > > > > 32")
> > > > > increased MAX_RESERVED_REGIONS to 32 but I'm not sure if increasing
> > > > > MAX_RESERVED_REGIONS to 64 is suitable for everyone.
> > > > >
> > > > > In this RFC patch, CONFIG_MAX_OF_RESERVED_REGIONS is added and used as
> > > > > MAX_RESERVED_REGIONS. Add a sanity test to make sure that
> > > > > MAX_RESERVED_REGIONS is less than INIT_MEMBLOCK_REGIONS.
> > > > > Users can configure CONFIG_MAX_OF_RESERVED_REGIONS according to their
> > > > > need.
> > > >
> > > > I don't want a kconfig option for this. I think it should be dynamic
> > > > instead.
> > > >
> > > > The current flow is like this:
> > > >
> > > > for each reserved node:
> > > > - call memblock_reserve
> > > > - Add info to reserved_mem array
> > > >
> > > > I think we should change it to:
> > > >
> > > > for each reserved node:
> > > > - call memblock_reserve
> > > > - count number of nodes
> > > >
> > > > Alloc array using memblock_alloc
> > > >
> > > > for each reserved node:
> > > >- Add info to reserved_mem array
> > > >
> > >
> > > thanks for your comment.
> > >
> > > I reviewed the flow and it might be easier to count the
> > > nodes and setup array first:
> > >
> > > for each reserved node:
> > > - count number of nodes
> > >
> > > Alloc array using memblock_alloc
> > >
> > >
> > > for each reserved node:
> > >- call memblock_reserve
> >
> > The order here is wrong. It is important that you reserve the memory
> > blocks before doing any allocations.
>
> thanks for pointing that out. You are right. I'll follow your
> suggestion.
I got a problem while implementing this change: the array allocation
is done successfully but the kernel does not create mappings for it yet,
so the array is not accessible. (kernel will create the mapping later in
paging_init())
For example: aarch64 setup_arch()
setup_arch()
{
memblock_init(); /* early_init_fdt_scan_reserved_mem() is called */
paging_init();
}
Could you give me some advice, please?
Miles
>
> >
> > >- Add info to reserved_mem array
> > >
> > > What do you think?
> > >
> > > > Rob
> > >
> > >
>
>
Re: [patch 20/24] x86/speculation: Split out TIF update
On 11/27/2018 02:36 PM, Thomas Gleixner wrote: >> >> We need this special handling only if the next task has TIF_SPEC_UPDATE >> set, which is one-off event globally (when seccomp marks all its threads >> so due to seccomp filter change), and once all the TIF_SPEC_UPDATE tasks >> schedule at least once, we're in a consistent state again and don't need >> this, as every running task will then have its TIF consistent with MSR >> value. > > And how so? You set the bits is spec_flags. And then you set the TIF_UPDATE > bit which is evaluated once. > > Then you OR the bits into tifp which is a local variable and has nothing to > do with the TIF flags of the next task. So on the next context switch this > will evaluate the previous state of the TIF bits and you could have spared > the whole exercise :) > This is better than my original implementation which was racy. Using task_spec_ssb_disable and task_spec_ib_disable to update TIF_* flags at context switch time makes the update logic very clear and extensible. Thanks. Tim
Re: [PATCH v2 1/4] x86/hyper-v: move synic/stimer control structures definitions to hyperv-tlfs.h
> On Nov 27, 2018, at 10:48 AM, Roman Kagan wrote: > > On Tue, Nov 27, 2018 at 02:10:49PM +0100, Vitaly Kuznetsov wrote: >> Roman Kagan writes: >>> On Mon, Nov 26, 2018 at 04:47:29PM +0100, Vitaly Kuznetsov wrote: >>> I personally tend to prefer masks over bitfields, so I'd rather do the >>> consolidation in the opposite direction: use the definitions in >>> hyperv-tlfs.h and replace those unions/bitfields elsewhere. (I vaguely >>> remember posting such a patchset a couple of years ago but I lacked the >>> motivation to complete it). >> >> Are there any known advantages of using masks over bitfields or the >> resulting binary code is the same? > > Strictly speaking bitwise ops are portable while bitfields are not, but > I guess this is not much of an issue with gcc which is dependable to > produce the right thing. > > I came to dislike the bitfields for the false feeling of atomicity of > assignment while most of the time they are read-modify-write operations. > > And no, I don't feel strong about it, so if nobody backs me on this I > give up :) Last time I tried to push a change from bitmasks to bitfields I failed: https://lkml.org/lkml/2014/9/16/245 On a different note: how come all of the hyper-v structs are not marked with the “packed" attribute?
Re: [PATCH v2 3/3] perf report: Display average IPC and IPC coverage per symbol
On 11/28/2018 2:33 AM, Andi Kleen wrote:
On Tue, Nov 27, 2018 at 08:09:48PM +0800, Jin Yao wrote:
Support displaying the average IPC and IPC coverage for symbol
in perf report TUI browser. We create a new sort-key 'ipc' for
that.
Another thing that would be nice would be to automatically enable
these columns perf report when -b was enabled in the perf.data.
We can't check for timed LBR being supported without
looking into samples, but at least can check for -b.
Otherwise a lot of people won't realize it's supported.
It would show always 0.0 when timed LBR is not supported,
but that might be ok. Perhaps make both columns empty
in this case instead of 0.0.
-Andi
Hi Andi,
Yes, I agree, people will not realize a new option 'ipc' is created.
So I will enable 2 columns ("IPC" and "IPC columns") even when timed LBR
is not supported. Just show empty or '-' in these columns.
Thanks
Jin Yao
[PATCH] ata: read ->revision before dropping pci_device reference
pci_device->revision is read after dropping pci_device reference via
pci_dev_put, which may result in use-after-free bugs. To fix this, the
patch reads ->revision before dropping reference.
Signed-off-by: Pan Bian
---
drivers/ata/pata_sis.c | 4 +++-
drivers/ata/pata_sl82c105.c | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/pata_sis.c b/drivers/ata/pata_sis.c
index 626f989..01635bc 100644
--- a/drivers/ata/pata_sis.c
+++ b/drivers/ata/pata_sis.c
@@ -833,6 +833,7 @@ static int sis_init_one (struct pci_dev *pdev, const struct
pci_device_id *ent)
u16 trueid;
u8 prefctl;
u8 idecfg;
+ u8 sbrev;
/* Try the second unmasking technique */
pci_read_config_byte(pdev, 0x4a, &idecfg);
@@ -846,9 +847,10 @@ static int sis_init_one (struct pci_dev *pdev, const
struct pci_device_id *ent)
if (lpc_bridge == NULL)
break;
pci_read_config_byte(pdev, 0x49, &prefctl);
+ sbrev = lpc_bridge->revision;
pci_dev_put(lpc_bridge);
- if (lpc_bridge->revision == 0x10 && (prefctl & 0x80)) {
+ if (sbrev == 0x10 && (prefctl & 0x80)) {
chipset = &sis133_early;
break;
}
diff --git a/drivers/ata/pata_sl82c105.c b/drivers/ata/pata_sl82c105.c
index 4935f61f..476438e 100644
--- a/drivers/ata/pata_sl82c105.c
+++ b/drivers/ata/pata_sl82c105.c
@@ -264,6 +264,7 @@ static struct ata_port_operations sl82c105_port_ops = {
static int sl82c105_bridge_revision(struct pci_dev *pdev)
{
struct pci_dev *bridge;
+ u8 rev;
/*
* The bridge should be part of the same device, but function 0.
@@ -285,8 +286,9 @@ static int sl82c105_bridge_revision(struct pci_dev *pdev)
/*
* We need to find function 0's revision, not function 1
*/
+ rev = bridge->revision;
pci_dev_put(bridge);
- return bridge->revision;
+ return rev;
}
static void sl82c105_fixup(struct pci_dev *pdev)
--
2.7.4
Re: [PATCH 02/25] iov_iter: Use accessor function [ver #2]
On Wed, Oct 24 2018, David Howells wrote: > Use accessor functions to access an iterator's type and direction. This > allows for the possibility of using some other method of determining the > type of iterator than if-chains with bitwise-AND conditions. > > Signed-off-by: David Howells > --- > @@ -74,7 +104,8 @@ static inline struct iovec iov_iter_iovec(const struct > iov_iter *iter) > } > > #define iov_for_each(iov, iter, start) \ > - if (!((start).type & (ITER_BVEC | ITER_PIPE))) \ > + if (iov_iter_type(start) == ITER_IOVEC || \ > + iov_iter_type(start) == ITER_KVEC) \ > for (iter = (start);\ >(iter).count &&\ >((iov = iov_iter_iovec(&(iter))), 1); \ BTW this breaks iov_for_each(). 'start' is a struct, but iov_iter_type() requires a pointer to a struct. You could fix it with > + if (iov_iter_type(&start) == ITER_IOVEC || \ > + iov_iter_type(&start) == ITER_KVEC) \ but as there are no users it is probably best to discard it. I discovered this because lustre uses (or rather "used") it. NeilBrown From: NeilBrown Date: Wed, 28 Nov 2018 12:38:30 +1100 Subject: [PATCH] iov_iter: discard iov_for_each() iov_for_each has no users and cannot compile as 'start' is treated sometimes like a struct and sometimes like a pointer to a struct. So discard it. Signed-off-by: NeilBrown --- .clang-format | 1 - include/linux/uio.h | 8 2 files changed, 9 deletions(-) diff --git a/.clang-format b/.clang-format index e6080f5834a3..c144d9c24d5d 100644 --- a/.clang-format +++ b/.clang-format @@ -259,7 +259,6 @@ ForEachMacros: - 'idr_for_each_entry_ul' - 'inet_bind_bucket_for_each' - 'inet_lhash2_for_each_icsk_rcu' - - 'iov_for_each' - 'key_for_each' - 'key_for_each_safe' - 'klp_for_each_func' diff --git a/include/linux/uio.h b/include/linux/uio.h index 55ce99ddb912..a2b2109838b0 100644 --- a/include/linux/uio.h +++ b/include/linux/uio.h @@ -109,14 +109,6 @@ static inline struct iovec iov_iter_iovec(const struct iov_iter *iter) }; } -#define iov_for_each(iov, iter, start) \ - if (iov_iter_type(start) == ITER_IOVEC || \ - iov_iter_type(start) == ITER_KVEC) \ - for (iter = (start);\ -(iter).count &&\ -((iov = iov_iter_iovec(&(iter))), 1); \ -iov_iter_advance(&(iter), (iov).iov_len)) - size_t iov_iter_copy_from_user_atomic(struct page *page, struct iov_iter *i, unsigned long offset, size_t bytes); void iov_iter_advance(struct iov_iter *i, size_t bytes); -- 2.14.0.rc0.dirty signature.asc Description: PGP signature
Re: [RFC][PATCH 11/14] function_graph: Convert ret_stack to a series of longs
On Mon, Nov 26, 2018 at 11:26:03AM -0500, Steven Rostedt wrote:
> On Tue, 27 Nov 2018 01:07:55 +0900
> Masami Hiramatsu wrote:
>
> > > > --- a/include/linux/sched.h
> > > > +++ b/include/linux/sched.h
> > > > @@ -1119,7 +1119,7 @@ struct task_struct {
> > > > int curr_ret_depth;
> > > >
> > > > /* Stack of return addresses for return function tracing: */
> > > > - struct ftrace_ret_stack *ret_stack;
> > > > + unsigned long *ret_stack;
> > > >
> > > > /* Timestamp for last schedule: */
> > > > unsigned long long ftrace_timestamp;
> > > > diff --git a/kernel/trace/fgraph.c b/kernel/trace/fgraph.c
> > > > index 9b85638ecded..1389fe39f64c 100644
> > > > --- a/kernel/trace/fgraph.c
> > > > +++ b/kernel/trace/fgraph.c
> > > > @@ -23,6 +23,17 @@
> > > > #define ASSIGN_OPS_HASH(opsname, val)
> > > > #endif
> > > >
> > > > +#define FGRAPH_RET_SIZE (sizeof(struct ftrace_ret_stack))
> > > > +#define FGRAPH_RET_INDEX (ALIGN(FGRAPH_RET_SIZE, sizeof(long)) /
> > > > sizeof(long))
> > > > +#define SHADOW_STACK_SIZE (FTRACE_RETFUNC_DEPTH * FGRAPH_RET_SIZE)
> > > > +#define SHADOW_STACK_INDEX \
> > > > + (ALIGN(SHADOW_STACK_SIZE, sizeof(long)) / sizeof(long))
> > > > +#define SHADOW_STACK_MAX_INDEX (SHADOW_STACK_INDEX - FGRAPH_RET_INDEX)
> > > > +
> > > > +#define RET_STACK(t, index) ((struct ftrace_ret_stack
> > > > *)(&(t)->ret_stack[index]))
> > > > +#define RET_STACK_INC(c) ({ c += FGRAPH_RET_INDEX; })
> > > > +#define RET_STACK_DEC(c) ({ c -= FGRAPH_RET_INDEX; })
> > > > +
> > > [...]
> > > > @@ -514,7 +531,7 @@ void ftrace_graph_init_task(struct task_struct *t)
> > > >
> > > > void ftrace_graph_exit_task(struct task_struct *t)
> > > > {
> > > > - struct ftrace_ret_stack *ret_stack = t->ret_stack;
> > > > + unsigned long *ret_stack = t->ret_stack;
> > > >
> > > > t->ret_stack = NULL;
> > > > /* NULL must become visible to IRQs before we free it: */
> > > > @@ -526,12 +543,10 @@ void ftrace_graph_exit_task(struct task_struct *t)
> > > > /* Allocate a return stack for each task */
> > > > static int start_graph_tracing(void)
> > > > {
> > > > - struct ftrace_ret_stack **ret_stack_list;
> > > > + unsigned long **ret_stack_list;
> > > > int ret, cpu;
> > > >
> > > > - ret_stack_list = kmalloc_array(FTRACE_RETSTACK_ALLOC_SIZE,
> > > > - sizeof(struct ftrace_ret_stack
> > > > *),
> > > > - GFP_KERNEL);
> > > > + ret_stack_list = kmalloc(SHADOW_STACK_SIZE, GFP_KERNEL);
> > > >
> > >
> > > I had dumped the fgraph size related macros to understand the patch
> > > better, I
> > > got:
> > > [0.909528] val of FGRAPH_RET_SIZE is 40
> > > [0.910250] val of FGRAPH_RET_INDEX is 5
> > > [0.910866] val of FGRAPH_ARRAY_SIZE is 16
> > > [0.911488] val of FGRAPH_ARRAY_MASK is 255
> > > [0.912134] val of FGRAPH_MAX_INDEX is 16
> > > [0.912751] val of FGRAPH_INDEX_SHIFT is 8
> > > [0.913382] val of FGRAPH_FRAME_SIZE is 168
> > > [0.914033] val of FGRAPH_FRAME_INDEX is 21
> > > FTRACE_RETFUNC_DEPTH is 50
> > > [0.914686] val of SHADOW_STACK_SIZE is 8400
> > >
> > > I had a concern about memory overhead per-task. It seems the total memory
> > > needed per task for the stack is 8400 bytes (with my configuration with
> > > FUNCTION_PROFILE
> > > turned off).
> > >
> > > Where as before it would be 32 * 40 = 1280 bytes. That looks like ~7 times
> > > more than before.
> >
> > Hmm, this seems too big... I thought the shadow-stack size should be
> > smaller than 1 page (4kB). Steve, can we give a 4k page for shadow stack
> > and define FTRACE_RETFUNC_DEPTH = 4096 / FGRAPH_RET_SIZE ?
>
> For the first pass, I decided not to worry about the size. It made the
> code less complex :-)
>
> Yes, I plan on working on making the size of the stack smaller, but
> that will probably be added on patches to do so.
Cool, sounds good.
> > > On my system with ~4000 threads, that becomes ~32MB which seems a bit
> > > wasteful especially if there was only one or 2 function graph callbacks
> > > registered and most of the callback array in the stack isn't used.
>
> Note, all 4000 threads could be doing those trace backs, and if you are
> doing full function graph tracing, it will use a lot.
But I think each of the threads will only use N entries in the callback array
where N is the number of function graph callback users who registered, right?
So the remaining total-N allocated callback array entries per thread will not
be used.
> > > Could we make the array size configurable at compile time and start it
> > > with a
> > > small number like 4 or 6?
> >
> > Or, we can introduce online setting :)
>
> Yes, that can easily be added. I didn't try to make this into the
> perfect solution, I wanted a
Re: [PATCH v2 0/6] RFC: gup+dma: tracking dma-pinned pages
On 11/21/2018 5:06 PM, John Hubbard wrote: On 11/21/18 8:49 AM, Tom Talpey wrote: On 11/21/2018 1:09 AM, John Hubbard wrote: On 11/19/18 10:57 AM, Tom Talpey wrote: ~14000 4KB read IOPS is really, really low for an NVMe disk. Yes, but Jan Kara's original config file for fio is *intended* to highlight the get_user_pages/put_user_pages changes. It was *not* intended to get max performance, as you can see by the numjobs and direct IO parameters: cat fio.conf [reader] direct=1 ioengine=libaio blocksize=4096 size=1g numjobs=1 rw=read iodepth=64 To be clear - I used those identical parameters, on my lower-spec machine, and got 400,000 4KB read IOPS. Those results are nearly 30x higher than yours! OK, then something really is wrong here... So I'm thinking that this is not a "tainted" test, but rather, we're constraining things a lot with these choices. It's hard to find a good test config to run that allows decisions, but so far, I'm not really seeing anything that says "this is so bad that we can't afford to fix the brokenness." I think. I'm not suggesting we tune the benchmark, I'm suggesting the results on your system are not meaningful since they are orders of magnitude low. And without meaningful data it's impossible to see the performance impact of the change... Can you confirm what type of hardware you're running this test on? CPU, memory speed and capacity, and NVMe device especially? Tom. Yes, it's a nice new system, I don't expect any strange perf problems: CPU: Intel(R) Core(TM) i7-7800X CPU @ 3.50GHz (Intel X299 chipset) Block device: nvme-Samsung_SSD_970_EVO_250GB DRAM: 32 GB The Samsung Evo 970 250GB is speced to yield 200,000 random read IOPS with a 4KB QD32 workload: https://www.samsung.com/us/computing/memory-storage/solid-state-drives/ssd-970-evo-nvme-m-2-250gb-mz-v7e250bw/#specs And the I7-7800X is a 6-core processor (12 hyperthreads). So, here's a comparison using 20 threads, direct IO, for the baseline vs. patched kernel (below). Highlights: -- IOPS are similar, around 60k. -- BW gets worse, dropping from 290 to 220 MB/s. -- CPU is well under 100%. -- latency is incredibly long, but...20 threads. Baseline: $ ./run.sh fio configuration: [reader] ioengine=libaio blocksize=4096 size=1g rw=read group_reporting iodepth=256 direct=1 numjobs=20 Ouch - 20 threads issuing 256 io's each!? Of course latency skyrockets. That's going to cause tremendous queuing, and context switching, far outside of the get_user_pages() change. But even so, it only brings IOPS to 74.2K, which is still far short of the device's 200K spec. Comparing anyway: Patched: Running fio: reader: (g=0): rw=read, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=256 ... fio-3.3 Starting 20 processes Jobs: 13 (f=8): [_(1),R(1),_(1),f(1),R(2),_(1),f(2),_(1),R(1),f(1),R(1),f(1),R(1),_(2),R(1),_(1),R(1)][97.9%][r=229MiB/s,w=0KiB/s][r=58.5k,w=0 IOPS][eta 00m:02s] reader: (groupid=0, jobs=20): err= 0: pid=2104: Tue Nov 20 22:01:58 2018 read: IOPS=56.8k, BW=222MiB/s (232MB/s)(20.0GiB/92385msec) ... Thoughts? Concern - the 74.2K IOPS unpatched drops to 56.8K patched! ACK. :) What I'd really like to see is to go back to the original fio parameters (1 thread, 64 iodepth) and try to get a result that gets at least close to the speced 200K IOPS of the NVMe device. There seems to be something wrong with yours, currently. I'll dig into what has gone wrong with the test. I see fio putting data files in the right place, so the obvious "using the wrong drive" is (probably) not it. Even though it really feels like that sort of thing. We'll see. Then of course, the result with the patched get_user_pages, and compare whichever of IOPS or CPU% changes, and how much. If these are within a few percent, I agree it's good to go. If it's roughly 25% like the result just above, that's a rocky road. I can try this after the holiday on some basic hardware and might be able to scrounge up better. Can you post that github link? Here: g...@github.com:johnhubbard/linux (branch: gup_dma_testing) I'm super-limited here this week hardware-wise and have not been able to try testing with the patched kernel. I was able to compare my earlier quick test with a Bionic 4.15 kernel (400K IOPS) against a similar 4.20rc3 kernel, and the rate dropped to ~_375K_ IOPS. Which I found perhaps troubling. But it was only a quick test, and without your change. Say, that branch reports it has not had a commit since June 30. Is that the right one? What about gup_dma_for_lpc_2018? Tom.
