[PATCH v4 2/2] x86/boot/KASLR: skip the specified crashkernel region
crashkernel=x@y or or =range1:size1[,range2:size2,...]@offset option may
fail to reserve the required memory region if KASLR puts kernel into the
region. To avoid this uncertainty, asking KASLR to skip the required
region.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Baoquan He
Cc: Will Deacon
Cc: Nicolas Pitre
Cc: Vivek Goyal
Cc: Chao Fan
Cc: "Kirill A. Shutemov"
Cc: Ard Biesheuvel
CC: Hari Bathini
Cc: linux-kernel@vger.kernel.org
---
arch/x86/boot/compressed/kaslr.c | 40
1 file changed, 40 insertions(+)
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 2e53c05..765a593 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -107,6 +107,7 @@ enum mem_avoid_index {
MEM_AVOID_BOOTPARAMS,
MEM_AVOID_MEMMAP_BEGIN,
MEM_AVOID_MEMMAP_END = MEM_AVOID_MEMMAP_BEGIN + MAX_MEMMAP_REGIONS - 1,
+ MEM_AVOID_CRASHKERNEL,
MEM_AVOID_MAX,
};
@@ -131,6 +132,11 @@ char *skip_spaces(const char *str)
}
#include "../../../../lib/ctype.c"
#include "../../../../lib/cmdline.c"
+#ifdef CONFIG_CRASH_CORE
+#define printk
+#define _BOOT_KASLR
+#include "../../../../lib/parse_crashkernel.c"
+#endif
static int
parse_memmap(char *p, unsigned long long *start, unsigned long long *size)
@@ -292,6 +298,39 @@ static void handle_mem_options(void)
return;
}
+static u64 mem_ram_size(void)
+{
+ struct boot_e820_entry *entry;
+ u64 total_sz = 0;
+ int i;
+
+ for (i = 0; i < boot_params->e820_entries; i++) {
+ entry = _params->e820_table[i];
+ /* Skip non-RAM entries. */
+ if (entry->type != E820_TYPE_RAM)
+ continue;
+ total_sz += entry->size;
+ }
+ return total_sz;
+}
+
+/*
+ * For crashkernel=size@offset or =range1:size1[,range2:size2,...]@offset
+ * options, recording mem_avoid for them.
+ */
+static void handle_crashkernel_options(void)
+{
+ unsigned long long crash_size, crash_base = 0;
+ char *cmdline = (char *)get_cmd_line_ptr();
+ u64 total_sz = mem_ram_size();
+
+ parse_crashkernel(cmdline, total_sz, _size, _base);
+ if (crash_base) {
+ mem_avoid[MEM_AVOID_CRASHKERNEL].start = crash_base;
+ mem_avoid[MEM_AVOID_CRASHKERNEL].size = crash_size;
+ }
+}
+
/*
* In theory, KASLR can put the kernel anywhere in the range of [16M, 64T).
* The mem_avoid array is used to store the ranges that need to be avoided
@@ -414,6 +453,7 @@ static void mem_avoid_init(unsigned long input, unsigned
long input_size,
/* Mark the memmap regions we need to avoid */
handle_mem_options();
+ handle_crashkernel_options();
/* Enumerate the immovable memory regions */
num_immovable_mem = count_immovable_mem_regions();
--
2.7.4
[PATCH v4 1/2] kernel/crash_core: separate the parsing routines to lib/parse_crashkernel.c
Beside kernel, at early boot stage, the KASLR code also needs to parse the
crashkernel=x@y or crashkernel=ramsize-range:size[,...][@offset] option,
and avoid to put randomized kernel in the region.
Extracting the parsing related routines to lib/parse_crashkernel.c, so it
will be handy included by other
files.
Signed-off-by: Pingfan Liu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Baoquan He
Cc: Will Deacon
Cc: Nicolas Pitre
Cc: Chao Fan
Cc: "Kirill A. Shutemov"
Cc: Ard Biesheuvel
Cc: Vivek Goyal
CC: Hari Bathini
Cc: linux-kernel@vger.kernel.org
---
kernel/crash_core.c | 273 -
lib/Makefile| 2 +
lib/parse_crashkernel.c | 289
3 files changed, 291 insertions(+), 273 deletions(-)
create mode 100644 lib/parse_crashkernel.c
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index 093c9f9..37c4d6f 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -21,279 +21,6 @@ u32 *vmcoreinfo_note;
/* trusted vmcoreinfo, e.g. we can make a copy in the crash memory */
static unsigned char *vmcoreinfo_data_safecopy;
-/*
- * parsing the "crashkernel" commandline
- *
- * this code is intended to be called from architecture specific code
- */
-
-
-/*
- * This function parses command lines in the format
- *
- * crashkernel=ramsize-range:size[,...][@offset]
- *
- * The function returns 0 on success and -EINVAL on failure.
- */
-static int __init parse_crashkernel_mem(char *cmdline,
- unsigned long long system_ram,
- unsigned long long *crash_size,
- unsigned long long *crash_base)
-{
- char *cur = cmdline, *tmp;
-
- /* for each entry of the comma-separated list */
- do {
- unsigned long long start, end = ULLONG_MAX, size;
-
- /* get the start of the range */
- start = memparse(cur, );
- if (cur == tmp) {
- pr_warn("crashkernel: Memory value expected\n");
- return -EINVAL;
- }
- cur = tmp;
- if (*cur != '-') {
- pr_warn("crashkernel: '-' expected\n");
- return -EINVAL;
- }
- cur++;
-
- /* if no ':' is here, than we read the end */
- if (*cur != ':') {
- end = memparse(cur, );
- if (cur == tmp) {
- pr_warn("crashkernel: Memory value expected\n");
- return -EINVAL;
- }
- cur = tmp;
- if (end <= start) {
- pr_warn("crashkernel: end <= start\n");
- return -EINVAL;
- }
- }
-
- if (*cur != ':') {
- pr_warn("crashkernel: ':' expected\n");
- return -EINVAL;
- }
- cur++;
-
- size = memparse(cur, );
- if (cur == tmp) {
- pr_warn("Memory value expected\n");
- return -EINVAL;
- }
- cur = tmp;
- if (size >= system_ram) {
- pr_warn("crashkernel: invalid size\n");
- return -EINVAL;
- }
-
- /* match ? */
- if (system_ram >= start && system_ram < end) {
- *crash_size = size;
- break;
- }
- } while (*cur++ == ',');
-
- if (*crash_size > 0) {
- while (*cur && *cur != ' ' && *cur != '@')
- cur++;
- if (*cur == '@') {
- cur++;
- *crash_base = memparse(cur, );
- if (cur == tmp) {
- pr_warn("Memory value expected after '@'\n");
- return -EINVAL;
- }
- }
- } else
- pr_info("crashkernel size resulted in zero bytes\n");
-
- return 0;
-}
-
-/*
- * That function parses "simple" (old) crashkernel command lines like
- *
- * crashkernel=size[@offset]
- *
- * It returns 0 on success and -EINVAL on failure.
- */
-static int __init parse_crashkernel_simple(char *cmdline,
- unsigned long long *crash_size,
- unsigned long long *crash_base)
-{
- char *cur = cmdline;
-
- *crash_size = memparse(cmdline, );
- if (cmdline == cur) {
- pr_warn("crashkernel: memory value expected\n");
- return -EINVAL;
- }
-
- if (*cur == '@')
-
[PATCH v4 0/2] x86/boot/KASLR: skip the specified crashkernel region
crashkernel=x@y or or =range1:size1[,range2:size2,...]@offset option may fail to reserve the required memory region if KASLR puts kernel into the region. To avoid this uncertainty, asking KASLR to skip the required region. And the parsing routine can be re-used at this early boot stage. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: Baoquan He Cc: Will Deacon Cc: Nicolas Pitre Cc: Vivek Goyal Cc: Chao Fan Cc: "Kirill A. Shutemov" Cc: Ard Biesheuvel CC: Hari Bathini Cc: linux-kernel@vger.kernel.org --- v3 -> v4: reuse the parse_crashkernel_xx routines Pingfan Liu (2): kernel/crash_core: separate the parsing routines to lib/parse_crashkernel.c x86/boot/KASLR: skip the specified crashkernel region arch/x86/boot/compressed/kaslr.c | 40 ++ kernel/crash_core.c | 273 lib/Makefile | 2 + lib/parse_crashkernel.c | 289 +++ 4 files changed, 331 insertions(+), 273 deletions(-) create mode 100644 lib/parse_crashkernel.c -- 2.7.4
Re: [Update][PATCH v3 3/4] cpufreq: schedutil: Simplify iowait boosting
On 28-03-19, 11:33, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > There is not reason for the minimum iowait boost value in the > schedutil cpufreq governor to depend on the available range of CPU > frequencies. In fact, that dependency is generally confusing, > because it causes the iowait boost to behave somewhat differently > on CPUs with the same maximum frequency and different minimum > frequencies, for example. > > For this reason, replace the min field in struct sugov_cpu > with a constant and choose its values to be 1/8 of > SCHED_CAPACITY_SCALE (for consistency with the intel_pstate > driver's internal governor). > > [Note that policy->cpuinfo.max_freq will not be a constant any more > after a subsequent change, so this change is depended on by it.] > > Link: > https://lore.kernel.org/lkml/20190305083202.gu32...@hirez.programming.kicks-ass.net/T/#ee20bdc98b7d89f6110c0d00e5c3ee8c2ced93c3d > Suggested-by: Peter Zijlstra > Signed-off-by: Rafael J. Wysocki > --- > > As pointed out by Quentin, the original patch overlooked two kerneldoc > comments that needed to be updated along with the code, so do that here. > > No other changes with respect to the original. > > --- > kernel/sched/cpufreq_schedutil.c | 21 ++--- > 1 file changed, 10 insertions(+), 11 deletions(-) Acked-by: Viresh Kumar -- viresh
Re: Regression in suspend-to-ram (TPM related) with 5.1-rc1 (BISECTED)
On 21.03.19 14:41, Jarkko Sakkinen wrote: > On Tue, Mar 19, 2019 at 04:03:37PM -0700, Paul Zimmerman wrote: >> So I bisected this down to: >> >> # first bad commit: [a3fbfae82b4cb3ff9928e29f34c64d0507cad874] tpm: >> take TPM chip power gating out of tpm_transmit() >> >> but this doesn't revert cleanly on Linus' HEAD. Anyone have an idea what >> could be wrong here? > > Sorry I've been in flu for the early week. I spotted the bug > immediately. When I did these patches I did not have TPM 1.x at my > hand. I used fTPM 2.0 and dTPM 2.0. Stefan did TPM 1.x testing but I > probably forgot to ask him to try out suspend. > > Anyway, the bug is obvious and I'll send you a patch to try out. > Thanks a lot for bisecting this! > > /Jarkko > Hi, Any news on this? It seems not to be fixed in -rc4. I'd happily test a patch too. thanks a lot, martin smime.p7s Description: S/MIME cryptographic signature
[PATCH 1/2] arm64: dts: allwinner: a64-amarula-relic: Add GT5663 CTP node
Add Goodix GT5663 capacitive touch controller node on
Amarula A64-Relic board.
The CTP connected to board with,
- SDA, SCK from i2c1
- GPIO-LD0 as AVDD28 supply
- PH4 gpio as interrupt pin
- PH8 gpio as reset pin
- X axis is inverted
- Y axis is inverted
Signed-off-by: Jagan Teki
---
.../allwinner/sun50i-a64-amarula-relic.dts| 29 +++
1 file changed, 29 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
index 3575db216016..a76353d59aaa 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
@@ -49,6 +49,28 @@
bias-pull-up;
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+
+ touchscreen@5d {
+ compatible = "goodix,gt5663";
+ reg = <0x5d>;
+ AVDD28-supply = <_ldo_io0>; /* VCC-CTP:
GPIO0-LDO */
+ interrupt-parent = <>;
+ interrupts = <7 4 IRQ_TYPE_EDGE_FALLING>;
+ irq-gpios = < 7 4 GPIO_ACTIVE_HIGH>;/* CTP-INT: PH4
*/
+ reset-gpios = < 7 8 GPIO_ACTIVE_HIGH>; /* CTP-RST: PH8
*/
+ touchscreen-inverted-x;
+ touchscreen-inverted-y;
+ };
+};
+
+_pins {
+ bias-pull-up;
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
@@ -212,6 +234,13 @@
regulator-name = "vdd-cpus";
};
+_ldo_io0 {
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vcc-ctp";
+ status = "okay";
+};
+
_rtc_ldo {
regulator-name = "vcc-rtc";
};
--
2.18.0.321.gffc6fa0e3
[PATCH 2/2] arm64: dts: allwinner: a64-oceanic-5205-5inmfd: Enable GT911 CTP
Goodix GT911 CTP is bound with Oceanic 5205 5inMFD board.
The CTP connected to board with,
- SDA, SCK from i2c0
- GPIO-LD0 as AVDD28 supply
- PH4 gpio as interrupt pin
- PH11 gpio as reset pin
- X axis is inverted
- Y axis is inverted
Signed-off-by: Jagan Teki
---
.../sun50i-a64-oceanic-5205-5inmfd.dts| 22 +++
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts
index 6a2154525d1e..5b0631929a6c 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-oceanic-5205-5inmfd.dts
@@ -37,6 +37,28 @@
status = "okay";
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+
+ touchscreen@5d {
+ compatible = "goodix,gt911";
+ reg = <0x5d>;
+ AVDD28-supply = <_ldo_io0>; /* VDD_CTP:
GPIO0-LDO */
+ interrupt-parent = <>;
+ interrupts = <7 4 IRQ_TYPE_EDGE_FALLING>;
+ irq-gpios = < 7 4 GPIO_ACTIVE_HIGH>;/* CTP-INT: PH4
*/
+ reset-gpios = < 7 11 GPIO_ACTIVE_HIGH>; /* CTP-RST:
PH11 */
+ touchscreen-inverted-x;
+ touchscreen-inverted-y;
+ };
+};
+
+_pins {
+ bias-pull-up;
+};
+
{
ext_rgmii_phy: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
--
2.18.0.321.gffc6fa0e3
linux-next: Fixes tag needs some work in the nvdimm-fixes tree
Hi Dan,
In commit
7c33bd4e3e97 ("libnvdimm/pmem: fix a possible OOB access when read and write
pmem")
Fixes tag
Fixes: 98cc093cba1e "(block, THP: make block_device_operations.rw_page
support THP)"
has these problem(s):
- Subject does not match target commit subject
Just use
git log -1 --format='Fixes: %h ("%s")'
--
Cheers,
Stephen Rothwell
pgpBB4J3R6x5P.pgp
Description: OpenPGP digital signature
Re: Adding plain accesses and detecting data races in the LKMM
> > > > I'd have:
> > > >
> > > > *x = 1; /* A */
> > > > smp_mb__before_atomic();
> > > > r0 = xchg_relaxed(x, 2); /* B (read or write part) */
> > > >
> > > > => (A ->barrier B)
> > >
> > > Perhaps so. It wasn't clear initially how these should be treated, so
> > > I just ignored them. For example, what should happen here if there
> > > were other statements between the smp_mb__before_atomic and the
> > > xchg_relaxed?
> >
> > I'd say that the link "A ->barrier B" should still be present and that
> > no other barrier-links should appear. More formally, I am suggesting
> > that Before-atomic induced the following barrier-links:
> >
> > [M] ; fencerel(Before-atomic) ; [RMW] ; po? ; [M]
>
> Hmmm, maybe. But exactly where is the barrier introduced? Are you
> saying that on some architectures the barrier is contained in the
> smp_mb__before_atomic and on others it is contained in the
> xchg_relaxed?
The formula was more along the line of "do not assume either of these
cases to hold; use barrier() is you need an unconditional barrier..."
AFAICT, all current implementations of smp_mb__{before,after}_atomic()
provides a compiler barrier with either barrier() or "memory" clobber.
> > I was suggesting to consider something like:
> >
> > let barrier = [...] | mb
> >
> > but I'm still not sure about those After-unlock-lock and After-spinlock.
>
> I don't see any point in saying that After-unlock-lock or
> After-spinlock contains a barrier, because spin_lock and spin_unlock
> already do.
(They would not "contain a barrier", they would induce some when paired
with the specified locking primitive/sequence: this distinction matters
for some implementation here doesn't provide the compiler barrier. But)
I agree with you: these barriers seem either redundant or unnecessary.
> > > > Also, consider the snippets:
> > > >
> > > > WRITE_ONCE(*x, 1);
> > > > *x = 2;
> > > >
> > > > and
> > > >
> > > > smp_store_release(x, 1);
> > > > *x = 2;
> > > >
> > > > The first snippet would be flagged "mixed-accesses" by the patch while
> > > > the second snippet would not (thanks to the above component); was this
> > > > intentional? (Notice that some implementations map the latter to:
> > > >
> > > > barrier();
> > > > WRITE_ONCE(*x, 1);
> > > > *x = 2;
> > > >
> > > > )
> > >
> > > That last observation is a good reason for changing the Cat code.
> >
> > You mean in:
> >
> > po-rel | acq-po
> >
> > ? (together with the fencerel()-ifications of Release and Acquire already
> > present in the patch).
>
> No, I meant changing the definition of "barrier" to say:
>
> (po ; [Release]) | ([Acquire] ; po)
>
> (for example) instead of the code you quoted above.
This makes sense to me.
> > > > > To avoid complications, the LKMM will consider only code in which
> > > > > plain writes are separated by a compiler barrier from any marked
> > > > > accesses of the same location. (Question: Can this restriction be
> > > > > removed?) As a consequence, if a region contains any marked accesses
> > > > > to a particular location then it cannot contain any plain writes to
> > > > > that location.
> > > >
> > > > I don't know if it can be removed... Said this, maybe we should go back
> > > > to the (simpler?) question: "What can go wrong without the
> > > > restriction?",
> > > > ;-) IOW, what are those "complications", can you provide some examples?
> > >
> > > Here's an example I sent to Will a little while ago. Suppose we
> > > have:
> > >
> > > r = rcu_dereference(ptr);
> > > *r = 1;
> > > WRITE_ONCE(x, 2);
> > >
> > > Imagine if the compiler transformed this to:
> > >
> > > r = rcu_dereference(ptr);
> > > WRITE_ONCE(x, 2);
> > > if (r != )
> > > *r = 1;
> > >
> > > This is bad because it destroys the address dependency when ptr
> > > contains
> >
> > Oh, indeed! (In fact, we discussed this example before... ;-/) BTW,
> > can you also point out an example which does not involve dependencies
> > (or destruction thereof)?
>
> I believe all the examples did involve dependencies. However, Paul has
> provided several use cases showing that one might have good reasons for
> mixing plain reads with marked acccesses -- but he didn't have any use
> cases for mixing plain writes.
I see. BTW, if we'll converge to add this new flag (or some variant),
it might be a good idea to log some of these examples, maybe just the
snippet above, in a commit message (these could come in handy when we
will be addressed with the question "Why am I seeing this flag?" ...)
> There are some open questions remaining. For instance, given:
>
> r1 = READ_ONCE(*x);
> r2 = *x;
>
> is the compiler allowed to replace the plain read with the value from
> the READ_ONCE? What if the statements were in the opposite order?
> What if the READ_ONCE was
Re: [PATCH v4 1/2] drm/bridge: sil_sii8620: make remote control optional.
On 07.04.2019 07:03, Ronald Tschalär wrote: > commit d6abe6df706c (drm/bridge: sil_sii8620: do not have a dependency > of RC_CORE) changed the driver to select both RC_CORE and INPUT. > However, this causes problems with other drivers, in particular an input > driver that depends on MFD_INTEL_LPSS_PCI (to be added in a separate > commit): > > drivers/clk/Kconfig:9:error: recursive dependency detected! > drivers/clk/Kconfig:9:symbol COMMON_CLK is selected by > MFD_INTEL_LPSS > drivers/mfd/Kconfig:566: symbol MFD_INTEL_LPSS is selected by > MFD_INTEL_LPSS_PCI > drivers/mfd/Kconfig:580: symbol MFD_INTEL_LPSS_PCI is implied by > KEYBOARD_APPLESPI > drivers/input/keyboard/Kconfig:73:symbol KEYBOARD_APPLESPI depends on > INPUT > drivers/input/Kconfig:8: symbol INPUT is selected by DRM_SIL_SII8620 > drivers/gpu/drm/bridge/Kconfig:83:symbol DRM_SIL_SII8620 depends on > DRM_BRIDGE > drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_BRIDGE is selected by > DRM_PL111 > drivers/gpu/drm/pl111/Kconfig:1: symbol DRM_PL111 depends on COMMON_CLK > > According to the docs and general consensus, select should only be used > for non user-visible symbols, but both RC_CORE and INPUT are > user-visible. Furthermore almost all other references to INPUT > throughout the kernel config are depends, not selects. For this reason > the first part of this change reverts commit d6abe6df706c. > > In order to address the original reason for commit d6abe6df706c, namely > that not all boards use the remote controller functionality and hence > should not need have to deal with RC_CORE, the second part of this > change now makes the remote control support in the driver optional and > contingent on RC_CORE being defined. And with this the hard dependency > on INPUT also goes away as that is only needed if RC_CORE is defined > (which in turn already depends on INPUT). > > CC: Inki Dae > CC: Andrzej Hajda > CC: Laurent Pinchart > CC: Dmitry Torokhov > Signed-off-by: Ronald Tschalär Reviewed-by: Andrzej Hajda -- Regards Andrzej
[PATCH] intel-lpss: Set the device in reset state when init
In virtualized setup, when system reboots due to warm
reset interrupt storm is seen.
Call Trace:
dump_stack+0x70/0xa5
__report_bad_irq+0x2e/0xc0
note_interrupt+0x248/0x290
? add_interrupt_randomness+0x30/0x220
handle_irq_event_percpu+0x54/0x80
handle_irq_event+0x39/0x60
handle_fasteoi_irq+0x91/0x150
handle_irq+0x108/0x180
do_IRQ+0x52/0xf0
common_interrupt+0xf/0xf
RIP: 0033:0x76fc2cfabc1d
Code: 24 28 bf 03 00 00 00 31 c0 48 8d 35 63 77 0e 00 48 8d 15 2e
94 0e 00 4c 89 f9 49 89 d9 4c 89 d3 e8 b8 e2 01 00 48 8b 54 24 18
<48> 89 ef 48 89 de 4c 89 e1 e8 d5 97 01 00 84 c0 74 2d 48 8b 04
24
RSP: 002b:7ffd247c1fc0 EFLAGS: 0293 ORIG_RAX: ffda
RAX: RBX: 7ffd247c1ff0 RCX: 0003d3ce
RDX: RSI: 7ffd247c1ff0 RDI: 76fc2cbb6010
RBP: 76fc2cded010 R08: 7ffd247c2210 R09: 7ffd247c22a0
R10: 76fc29465470 R11: R12: 7ffd247c1fc0
R13: 76fc2ce8e470 R14: 76fc27ec9960 R15: 0414
handlers:
[<0d3fa913>] idma64_irq
Disabling IRQ #27
To avoid interrupt storm, set the device in reset state
before bringing out the device from reset state.
Signed-off-by: Binbin Wu
---
drivers/mfd/intel-lpss.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/intel-lpss.c b/drivers/mfd/intel-lpss.c
index 50bffc3..ff3fba1 100644
--- a/drivers/mfd/intel-lpss.c
+++ b/drivers/mfd/intel-lpss.c
@@ -273,6 +273,9 @@ static void intel_lpss_init_dev(const struct intel_lpss
*lpss)
{
u32 value = LPSS_PRIV_SSP_REG_DIS_DMA_FIN;
+ /* Set the device in reset state */
+ writel(0, lpss->priv + LPSS_PRIV_RESETS);
+
intel_lpss_deassert_reset(lpss);
intel_lpss_set_remap_addr(lpss);
--
2.7.4
Re: [RESENT PATCH] mm/memory_hotplug: Do not unlock when fails to take the device_hotplug_lock
On Mon 08-04-19 12:07:17, zhong jiang wrote:
> When adding the memory by probing memory block in sysfs interface, there is an
> obvious issue that we will unlock the device_hotplug_lock when fails to takes
> it.
>
> That issue was introduced in Commit 8df1d0e4a265
> ("mm/memory_hotplug: make add_memory() take the device_hotplug_lock")
>
> We should drop out in time when fails to take the device_hotplug_lock.
>
> Fixes: 8df1d0e4a265 ("mm/memory_hotplug: make add_memory() take the
> device_hotplug_lock")
> Reported-by: Yang yingliang
> Signed-off-by: zhong jiang
Acked-by: Michal Hocko
> ---
> drivers/base/memory.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index d9ebb89..0c9e22f 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -507,7 +507,7 @@ static ssize_t probe_store(struct device *dev, struct
> device_attribute *attr,
>
> ret = lock_device_hotplug_sysfs();
> if (ret)
> - goto out;
> + return ret;
>
> nid = memory_add_physaddr_to_nid(phys_addr);
> ret = __add_memory(nid, phys_addr,
> --
> 1.7.12.4
>
--
Michal Hocko
SUSE Labs
linux-next: Tree for Apr 8
Hi all, Changes since 20190405: The kspp-gustavo tree gained a conflict against Linus' tree. The drm tree inherited the build failure from the drm-misc tree for which I disabled a driver. The audit tree gained a conflict against Linus' tree. The staging tree gained a conflict against the staging.current tree. Non-merge commits (relative to Linus' tree): 5190 5018 files changed, 164937 insertions(+), 77223 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 298 trees (counting Linus' and 69 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 (3b0468914708 Merge tag 'for-linus-5.1b-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip) Merging fixes/master (b352face4ca9 adfs: mark expected switch fall-throughs) Merging kspp-gustavo/for-next/kspp (2d212a1bac7e NFC: st21nfca: Fix fall-through warnings) CONFLICT (content): Merge conflict in arch/x86/include/asm/syscall.h Merging kbuild-current/fixes (79a3aaa7b82e Linux 5.1-rc3) Merging arc-current/for-curr (831e90bd606e ARC: PAE40: don't panic and instead turn off hw ioc) Merging arm-current/fixes (d410a8a49e3e ARM: 8849/1: NOMMU: Fix encodings for PMSAv8's PRBAR4/PRLAR4) Merging arm64-fixes/for-next/fixes (1c41860864c8 arm64: fix wrong check of on_sdei_stack in nmi context) Merging m68k-current/for-linus (28713169d879 m68k: Add -ffreestanding to CFLAGS) Merging powerpc-fixes/fixes (6f845ebec270 powerpc/pseries/mce: Fix misleading print for TLB mutlihit) Merging sparc/master (7d762d69145a afs: Fix manually set volume location server list) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (6491d698396f nfc: nci: Potential off by one in ->pipes[] array) Merging bpf/master (bbd669a868bb ibmvnic: Fix completion structure initialization) Merging ipsec/master (8742dc86d0c7 xfrm4: Fix uninitialized memory read in _decode_session4) Merging netfilter/master (5f543a54eec0 net: hns3: fix for not calculating tx bd num correctly) Merging ipvs/master (b2e3d68d1251 netfilter: nft_compat: destroy function must not have side effects) Merging wireless-drivers/master (4837696f6b54 Merge tag 'iwlwifi-for-kalle-2019-03-22' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging mac80211/master (53bf5811ca37 cfg80211: add ratelimited variants of err and warn) Merging rdma-fixes/for-rc (1abe186ed8a6 IB/mlx5: Reset access mask when looping inside page fault handler) Merging sound-current/for-linus (212ac181c158 ALSA: seq: Fix OOB-reads from strlcpy) Merging sound-asoc-fixes/for-linus (a243bce92ee5 Merge branch 'asoc-5.1' into asoc-linus) Merging regmap-fixes/for-linus (34fd5ecd01f0 Merge branch 'regmap-5.1' into regmap-linus) Merging regulator-fixes/for-linus (e4bf73ad9d85 Merge branch 'regulator-5.1' into regulator-linus) Merging spi-fixes/for-linus (4cb7a4b2f6ef Merge branch 'spi-5.1' into spi-linus) Merging pci-current/for-linus (9cde402a5977 PCI: Add function 1 DMA alias quirk for Marvell 9170 SATA controller) Merging driver-core.current/driver-core-linus (79a3aaa7b82e Linux 5.1-rc3) Merging tty.current/tty-linus (79a3aaa7b82e Linux 5.1-rc3) Merging usb.current/usb-linus (79a3aaa7b82e Linux 5.1-rc3) Merging usb-gadget-fixes/fixes (072684e8c58d USB: gadget: f_hid: fix deadlock in
Re: [PATCH] cpufreq: stats: Use lock by stat to replace global spin lock
On 26-03-19, 11:43, Matthias Kaehlcke wrote:
> On Mon, Mar 25, 2019 at 03:29:33PM +0800, Kyle Lin wrote:
> > Stats is updated by each policy, using the lock by stat can
> > reduce the contention.
> >
> > Signed-off-by: Kyle Lin
> > ---
> > drivers/cpufreq/cpufreq_stats.c | 15 ---
> > 1 file changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/cpufreq/cpufreq_stats.c
> > b/drivers/cpufreq/cpufreq_stats.c
> > index e2db5581489a..17beb1bc7e16 100644
> > --- a/drivers/cpufreq/cpufreq_stats.c
> > +++ b/drivers/cpufreq/cpufreq_stats.c
> > @@ -14,7 +14,6 @@
> > #include
> > #include
> >
> > -static DEFINE_SPINLOCK(cpufreq_stats_lock);
> >
> > struct cpufreq_stats {
> > unsigned int total_trans;
> > @@ -23,6 +22,7 @@ struct cpufreq_stats {
> > unsigned int state_num;
> > unsigned int last_index;
> > u64 *time_in_state;
> > + spinlock_t lock;/*spinlock for stats update*/
>
> nit: not sure if the comment adds much value. If it stay there it
> needs a blank after '/*' and another before '*/'
Just drop the comment please.
--
viresh
Re: [PATCH] slab: fix a crash by reading /proc/slab_allocators
On Sat, Apr 6, 2019 at 12:59 PM Qian Cai wrote:
>
> The commit 510ded33e075 ("slab: implement slab_root_caches list")
> changes the name of the list node within "struct kmem_cache" from
> "list" to "root_caches_node", but leaks_show() still use the "list"
> which causes a crash when reading /proc/slab_allocators.
The patch does seem to be correct, and I have applied it.
However, it does strike me that apparently this wasn't caught for two
years. Which makes me wonder whether we should (once again) discuss
just removing SLAB entirely, or at least removing the
/proc/slab_allocators file. Apparently it has never been used in the
last two years. At some point a "this can't have worked if anybody
ever tried to use it" situation means that the code should likely be
excised.
Qian, how did you end up noticing and debugging this?
Linus
[PATCH 2/2] ARM: dts: exynos: Remove console argument from bootargs
Remove the "console=ttySAC..." argument from DTSes having a proper
stdout-path property. To make the code functionally equivalent, add the
serial port baud rate and parity.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4210-origen.dts | 4 ++--
arch/arm/boot/dts/exynos4210-smdkv310.dts | 4 ++--
arch/arm/boot/dts/exynos4210-trats.dts | 4 ++--
arch/arm/boot/dts/exynos4210-universal_c210.dts | 4 ++--
arch/arm/boot/dts/exynos4412-origen.dts | 3 +--
arch/arm/boot/dts/exynos4412-smdk4412.dts | 4 ++--
6 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index dd9ec05eb0f7..36b1edea254a 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -30,8 +30,8 @@
};
chosen {
- bootargs ="root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M
console=ttySAC2,115200 init=/linuxrc";
- stdout-path = _2;
+ bootargs = "root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M
init=/linuxrc";
+ stdout-path = "serial2:115200n8";
};
mmc_reg: voltage-regulator {
diff --git a/arch/arm/boot/dts/exynos4210-smdkv310.dts
b/arch/arm/boot/dts/exynos4210-smdkv310.dts
index 7a3e621edede..77fc11e593ad 100644
--- a/arch/arm/boot/dts/exynos4210-smdkv310.dts
+++ b/arch/arm/boot/dts/exynos4210-smdkv310.dts
@@ -26,8 +26,8 @@
};
chosen {
- bootargs = "root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M
console=ttySAC1,115200 init=/linuxrc";
- stdout-path = _1;
+ bootargs = "root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M
init=/linuxrc";
+ stdout-path = "serial1:115200n8";
};
fixed-rate-clocks {
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index 8dbc47d627a5..6882480dbaf7 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -26,8 +26,8 @@
};
chosen {
- bootargs = "console=ttySAC2,115200N8 root=/dev/mmcblk0p5
rootwait earlyprintk panic=5";
- stdout-path = _2;
+ bootargs = "root=/dev/mmcblk0p5 rootwait earlyprintk panic=5";
+ stdout-path = "serial2:115200n8";
};
regulators {
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 5c3d98654f13..07d64a8f82e3 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -24,8 +24,8 @@
};
chosen {
- bootargs = "console=ttySAC2,115200N8 root=/dev/mmcblk0p5 rw
rootwait earlyprintk panic=5 maxcpus=1";
- stdout-path = _2;
+ bootargs = "root=/dev/mmcblk0p5 rw rootwait earlyprintk panic=5
maxcpus=1";
+ stdout-path = "serial2:115200n8";
};
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
b/arch/arm/boot/dts/exynos4412-origen.dts
index 346f71932457..698de4345d16 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -25,8 +25,7 @@
};
chosen {
- bootargs ="console=ttySAC2,115200";
- stdout-path = _2;
+ stdout-path = "serial2:115200n8";
};
firmware@203f000 {
diff --git a/arch/arm/boot/dts/exynos4412-smdk4412.dts
b/arch/arm/boot/dts/exynos4412-smdk4412.dts
index 5c5c2887c14f..e70fb6e601f0 100644
--- a/arch/arm/boot/dts/exynos4412-smdk4412.dts
+++ b/arch/arm/boot/dts/exynos4412-smdk4412.dts
@@ -23,8 +23,8 @@
};
chosen {
- bootargs ="root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M
console=ttySAC1,115200 init=/linuxrc";
- stdout-path = _1;
+ bootargs = "root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M
init=/linuxrc";
+ stdout-path = "serial1:115200n8";
};
fixed-rate-clocks {
--
2.17.1
[PATCH 1/2] ARM: dts: exynos: Use stdout-path property instead of console in bootargs
Replacing bootargs with stdout-path property in chosen node allows using
early console by adding just 'earlycon' parameter to the kernel command
line.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4412-trats2.dts| 3 ++-
arch/arm/boot/dts/exynos5250-smdk5250.dts | 3 ++-
arch/arm/boot/dts/exynos5260-xyref5260.dts | 2 +-
arch/arm/boot/dts/exynos5410-smdk5410.dts | 2 +-
arch/arm/boot/dts/exynos5420-smdk5420.dts | 3 ++-
5 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 327ee980d3a5..aac533933c61 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -22,6 +22,7 @@
};
chosen {
- bootargs = "console=ttySAC2,115200N8 root=/dev/mmcblk0p5
rootwait earlyprintk panic=5";
+ bootargs = "root=/dev/mmcblk0p5 rootwait earlyprintk panic=5";
+ stdout-path = "serial2:115200n8";
};
};
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index d5e66189ed2a..6dc96948a9cc 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -24,7 +24,8 @@
};
chosen {
- bootargs = "root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M
console=ttySAC2,115200 init=/linuxrc";
+ bootargs = "root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M
init=/linuxrc";
+ stdout-path = "serial2:115200n8";
};
vdd: fixed-regulator-vdd {
diff --git a/arch/arm/boot/dts/exynos5260-xyref5260.dts
b/arch/arm/boot/dts/exynos5260-xyref5260.dts
index fa19c59b2fb6..36a2b77eeb9d 100644
--- a/arch/arm/boot/dts/exynos5260-xyref5260.dts
+++ b/arch/arm/boot/dts/exynos5260-xyref5260.dts
@@ -19,7 +19,7 @@
};
chosen {
- bootargs = "console=ttySAC2,115200";
+ stdout-path = "serial2:115200n8";
};
fin_pll: xxti {
diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
index 8fc8c841d34b..dffa5e3ed90c 100644
--- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -19,7 +19,7 @@
};
chosen {
- bootargs = "console=ttySAC2,115200";
+ stdout-path = "serial2:115200n8";
};
fin_pll: xxti {
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 3cf905047893..8240e5186972 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -21,7 +21,8 @@
};
chosen {
- bootargs = "console=ttySAC2,115200 init=/linuxrc";
+ bootargs = "init=/linuxrc";
+ stdout-path = "serial2:115200n8";
};
fixed-rate-clocks {
--
2.17.1
Re: [PATCH] slab: fix a crash by reading /proc/slab_allocators
On Sat, Apr 06, 2019 at 06:59:01PM -0400, Qian Cai wrote:
> The commit 510ded33e075 ("slab: implement slab_root_caches list")
> changes the name of the list node within "struct kmem_cache" from
> "list" to "root_caches_node", but leaks_show() still use the "list"
> which causes a crash when reading /proc/slab_allocators.
>
> BUG: unable to handle kernel NULL pointer dereference at
> 00aa
> PGD 0 P4D 0
> Oops: [#1] SMP DEBUG_PAGEALLOC PTI
> CPU: 3 PID: 5925 Comm: ldd Not tainted 5.1.0-rc3-mm1+ #6
> RIP: 0010:__lock_acquire.isra.14+0x4b4/0xa50
> Call Trace:
>
> lock_acquire+0xa3/0x180
> _raw_spin_lock+0x2f/0x40
> do_drain+0x61/0xc0
> flush_smp_call_function_queue+0x3a/0x110
> generic_smp_call_function_single_interrupt+0x13/0x2b
> smp_call_function_interrupt+0x66/0x1a0
> call_function_interrupt+0xf/0x20
>
> RIP: 0010:__tlb_remove_page_size+0x8c/0xe0
> zap_pte_range+0x39f/0xc80
> unmap_page_range+0x38a/0x550
> unmap_single_vma+0x7d/0xe0
> unmap_vmas+0xae/0xd0
> exit_mmap+0xae/0x190
> mmput+0x7a/0x150
> do_exit+0x2d9/0xd40
> do_group_exit+0x41/0xd0
> __x64_sys_exit_group+0x18/0x20
> do_syscall_64+0x68/0x381
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Fixes: 510ded33e075 ("slab: implement slab_root_caches list")
> Signed-off-by: Qian Cai
> ---
> mm/slab.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/mm/slab.c b/mm/slab.c
> index 46a6e084222b..9142ee992493 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -4307,7 +4307,8 @@ static void show_symbol(struct seq_file *m, unsigned
> long address)
>
> static int leaks_show(struct seq_file *m, void *p)
> {
> - struct kmem_cache *cachep = list_entry(p, struct kmem_cache, list);
> + struct kmem_cache *cachep = list_entry(p, struct kmem_cache,
> +root_caches_node);
> struct page *page;
> struct kmem_cache_node *n;
> const char *name;
> --
> 2.17.2 (Apple Git-113)
>
For what its worth
Reviewed-by: Tobin C. Harding
thanks,
Tobin.
[PATCH] pinctrl:intel: Retain HOSTSW_OWN for requested gpio pin
The touchpad of the ASUS laptops E403NA, X540NA, X541NA are not
responsive after suspend/resume. The following error message
shows after resume.
i2c_hid i2c-ELAN1200:00: failed to reset device.
On these laptops, the touchpad interrupt is connected via a GPIO
pin which is controlled by Intel pinctrl. After system resumes,
the GPIO is in ACPI mode and no longer works as an IRQ.
This commit saves the HOSTSW_OWN value during suspend, make sure
the HOSTSW_OWN mode remains the same after resume.
Signed-off-by: Chris Chiu
---
drivers/pinctrl/intel/pinctrl-intel.c | 50 ++-
1 file changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/intel/pinctrl-intel.c
b/drivers/pinctrl/intel/pinctrl-intel.c
index 8cda7b535b02..3930819049c4 100644
--- a/drivers/pinctrl/intel/pinctrl-intel.c
+++ b/drivers/pinctrl/intel/pinctrl-intel.c
@@ -81,6 +81,7 @@ struct intel_pad_context {
struct intel_community_context {
u32 *intmask;
+ u32 *hostown;
};
struct intel_pinctrl_context {
@@ -1284,7 +1285,7 @@ static int intel_pinctrl_pm_init(struct intel_pinctrl
*pctrl)
for (i = 0; i < pctrl->ncommunities; i++) {
struct intel_community *community = >communities[i];
- u32 *intmask;
+ u32 *intmask, *hostown;
intmask = devm_kcalloc(pctrl->dev, community->ngpps,
sizeof(*intmask), GFP_KERNEL);
@@ -1292,6 +1293,13 @@ static int intel_pinctrl_pm_init(struct intel_pinctrl
*pctrl)
return -ENOMEM;
communities[i].intmask = intmask;
+
+ hostown = devm_kcalloc(pctrl->dev, community->ngpps,
+ sizeof(*hostown), GFP_KERNEL);
+ if (!hostown)
+ return -ENOMEM;
+
+ communities[i].hostown = hostown;
}
pctrl->context.pads = pads;
@@ -1503,6 +1511,10 @@ int intel_pinctrl_suspend(struct device *dev)
base = community->regs + community->ie_offset;
for (gpp = 0; gpp < community->ngpps; gpp++)
communities[i].intmask[gpp] = readl(base + gpp * 4);
+
+ base = community->regs + community->hostown_offset;
+ for (gpp = 0; gpp < community->ngpps; gpp++)
+ communities[i].hostown[gpp] = readl(base + gpp * 4);
}
return 0;
@@ -1529,6 +1541,28 @@ static void intel_gpio_irq_init(struct intel_pinctrl
*pctrl)
}
}
+static u32
+intel_gpio_is_requested(struct gpio_chip *chip, int base, unsigned int size)
+{
+ u32 requested = 0;
+ unsigned int i;
+
+ for (i = 0; i < size; i++)
+ if (gpiochip_is_requested(chip, base + i))
+ requested |= BIT(i);
+
+ return requested;
+}
+
+static void
+intel_gpio_update_pad_mode(void __iomem *hostown, u32 mask, u32 value)
+{
+ u32 curr = readl(hostown);
+ u32 updated = (curr & ~mask) | (value & mask);
+
+ return writel(updated, hostown);
+}
+
int intel_pinctrl_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
@@ -1588,6 +1622,20 @@ int intel_pinctrl_resume(struct device *dev)
dev_dbg(dev, "restored mask %d/%u %#08x\n", i, gpp,
readl(base + gpp * 4));
}
+
+ base = community->regs + community->hostown_offset;
+ for (gpp = 0; gpp < community->ngpps; gpp++) {
+ const struct intel_padgroup *padgrp =
>gpps[gpp];
+ u32 requested = 0;
+
+ if (padgrp->gpio_base < 0)
+ continue;
+
+ requested = intel_gpio_is_requested(>chip,
+ padgrp->gpio_base, padgrp->size);
+ intel_gpio_update_pad_mode(base + gpp * 4, requested,
+ communities[i].hostown[gpp]);
+ }
}
return 0;
--
2.21.0
[PATCH] alarmtimer: return correct remaining time
To calculate a remaining time, we need to subtract the current time from
the expiration time. Currently, arguments of ktime_sub are swapped.
Signed-off-by: Andrei Vagin
---
kernel/time/alarmtimer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/time/alarmtimer.c b/kernel/time/alarmtimer.c
index 2c97e8c2d29f..0519a8805aab 100644
--- a/kernel/time/alarmtimer.c
+++ b/kernel/time/alarmtimer.c
@@ -594,7 +594,7 @@ static ktime_t alarm_timer_remaining(struct k_itimer *timr,
ktime_t now)
{
struct alarm *alarm = >it.alarm.alarmtimer;
- return ktime_sub(now, alarm->node.expires);
+ return ktime_sub(alarm->node.expires, now);
}
/**
--
2.20.1
Re: [PATCH] mm/memory_hotplug: Do not unlock when fails to take the device_hotplug_lock
I am sorry, It is incorrect. please ignore the patch. I will resent it.
Thanks,
zhong jiang
On 2019/4/8 12:00, zhong jiang wrote:
> When adding the memory by probing memory block in sysfs interface, there is an
> obvious issue that we will unlock the device_hotplug_lock when fails to takes
> it.
>
> That issue was introduced in Commit 8df1d0e4a265
> ("mm/memory_hotplug: make add_memory() take the device_hotplug_lock")
>
> We should drop out in time when fails to take the device_hotplug_lock.
>
> Fixes: 8df1d0e4a265 ("mm/memory_hotplug: make add_memory() take the
> device_hotplug_lock")
> Reported-by: Yang yingliang
> Signed-off-by: zhong jiang
> ---
> drivers/base/memory.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index d9ebb89..8b0cec7 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -507,7 +507,7 @@ static ssize_t probe_store(struct device *dev, struct
> device_attribute *attr,
>
> ret = lock_device_hotplug_sysfs();
> if (ret)
> - goto out;
> + goto ret;
>
> nid = memory_add_physaddr_to_nid(phys_addr);
> ret = __add_memory(nid, phys_addr,
[RESENT PATCH] mm/memory_hotplug: Do not unlock when fails to take the device_hotplug_lock
When adding the memory by probing memory block in sysfs interface, there is an
obvious issue that we will unlock the device_hotplug_lock when fails to takes
it.
That issue was introduced in Commit 8df1d0e4a265
("mm/memory_hotplug: make add_memory() take the device_hotplug_lock")
We should drop out in time when fails to take the device_hotplug_lock.
Fixes: 8df1d0e4a265 ("mm/memory_hotplug: make add_memory() take the
device_hotplug_lock")
Reported-by: Yang yingliang
Signed-off-by: zhong jiang
---
drivers/base/memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index d9ebb89..0c9e22f 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -507,7 +507,7 @@ static ssize_t probe_store(struct device *dev, struct
device_attribute *attr,
ret = lock_device_hotplug_sysfs();
if (ret)
- goto out;
+ return ret;
nid = memory_add_physaddr_to_nid(phys_addr);
ret = __add_memory(nid, phys_addr,
--
1.7.12.4
Re: [PATCH 6/6] arm64/mm: Enable ZONE_DEVICE
On Sun, Apr 07, 2019 at 03:11:00PM -0700, Dan Williams wrote: > On Thu, Apr 4, 2019 at 2:47 AM Robin Murphy wrote: > > > > On 04/04/2019 06:04, Dan Williams wrote: > > > On Wed, Apr 3, 2019 at 9:42 PM Anshuman Khandual > > > wrote: > > >> > > >> > > >> > > >> On 04/03/2019 07:28 PM, Robin Murphy wrote: > > >>> [ +Dan, Jerome ] > > >>> > > >>> On 03/04/2019 05:30, Anshuman Khandual wrote: > > Arch implementation for functions which create or destroy vmemmap > > mapping > > (vmemmap_populate, vmemmap_free) can comprehend and allocate from > > inside > > device memory range through driver provided vmem_altmap structure which > > fulfils all requirements to enable ZONE_DEVICE on the platform. Hence > > just > > >>> > > >>> ZONE_DEVICE is about more than just altmap support, no? > > >> > > >> Hot plugging the memory into a dev->numa_node's ZONE_DEVICE and > > >> initializing the > > >> struct pages for it has stand alone and self contained use case. The > > >> driver could > > >> just want to manage the memory itself but with struct pages either in > > >> the RAM or > > >> in the device memory range through struct vmem_altmap. The driver may > > >> not choose > > >> to opt for HMM, FS DAX, P2PDMA (use cases of ZONE_DEVICE) where it may > > >> have to > > >> map these pages into any user pagetable which would necessitate support > > >> for > > >> pte|pmd|pud_devmap. > > > > > > What's left for ZONE_DEVICE if none of the above cases are used? > > > > > >> Though I am still working towards getting HMM, FS DAX, P2PDMA enabled on > > >> arm64, > > >> IMHO ZONE_DEVICE is self contained and can be evaluated in itself. > > > > > > I'm not convinced. What's the specific use case. > > > > The fundamental "roadmap" reason we've been doing this is to enable > > further NVDIMM/pmem development (libpmem/Qemu/etc.) on arm64. The fact > > that ZONE_DEVICE immediately opens the door to the various other stuff > > that the CCIX folks have interest in is a definite bonus, so it would > > certainly be preferable to get arm64 on par with the current state of > > things rather than try to subdivide the scope further. > > > > I started working on this from the ZONE_DEVICE end, but got bogged down > > in trying to replace my copied-from-s390 dummy hot-remove implementation > > with something proper. Anshuman has stepped in to help with hot-remove > > (since we also have cloud folks wanting that for its own sake), so is > > effectively coming at the problem from the opposite direction, and I'll > > be the first to admit that we've not managed the greatest job of meeting > > in the middle and coordinating our upstream story; sorry about that :) > > > > Let me freshen up my devmap patches and post them properly, since that > > discussion doesn't have to happen in the context of hot-remove; they're > > effectively just parallel dependencies for ZONE_DEVICE. > > Sounds good. It's also worth noting that Ira's recent patches for > supporting get_user_pages_fast() for "longterm" pins relies on > PTE_DEVMAP to determine when fast-GUP is safe to proceed, or whether > it needs to fall back to slow-GUP. So it really is the case that > "devmap" support is an assumption for ZONE_DEVICE. Could you cc me on the patches when you post? Thanks, Ira
[PATCH] mm/memory_hotplug: Do not unlock when fails to take the device_hotplug_lock
When adding the memory by probing memory block in sysfs interface, there is an
obvious issue that we will unlock the device_hotplug_lock when fails to takes
it.
That issue was introduced in Commit 8df1d0e4a265
("mm/memory_hotplug: make add_memory() take the device_hotplug_lock")
We should drop out in time when fails to take the device_hotplug_lock.
Fixes: 8df1d0e4a265 ("mm/memory_hotplug: make add_memory() take the
device_hotplug_lock")
Reported-by: Yang yingliang
Signed-off-by: zhong jiang
---
drivers/base/memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index d9ebb89..8b0cec7 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -507,7 +507,7 @@ static ssize_t probe_store(struct device *dev, struct
device_attribute *attr,
ret = lock_device_hotplug_sysfs();
if (ret)
- goto out;
+ goto ret;
nid = memory_add_physaddr_to_nid(phys_addr);
ret = __add_memory(nid, phys_addr,
--
1.7.12.4
Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT
at 4:58 AM, Robert R. Howell wrote:
On 4/3/19 2:54 AM, Hans de Goede wrote:
Hi,
On 03-04-19 07:43, Kai-Heng Feng wrote:
i2c-designware-platdrv fails to work after the system restored from
hibernation:
[ 272.775692] i2c_designware 80860F41:00: Unknown Synopsys component
type: 0x
Commit 48402cee6889 ("ACPI / LPSS: Resume BYT/CHT I2C controllers from
resume_noirq") makes acpi_lpss_{suspend_late,resume_early}() bail early
on BYT/CHT as resume_from_noirq is set. This means dw_i2c_plat_resume()
doesn't gets called by acpi_lpss_resume_early(), and this causes the
issue.
...
The ordering problem fixed by commit 48402cee6889 can hit hibernate too,
so I think it would be better to do this instead to fix this problem:
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 1e2a10a06b9d..cf768608437e 100644
...
If people affected by the problem can give my version of the fix a test,
then that would be great.
Regards,
Hans
I did try applying your (Hans') patch to a 5.0.0 and a 5.1-rc3 kernel,
instead of what I had
been doing previously, which was reverting commit 02e45646d53b. I tested
it on an ASUS T100TA
and unfortunately with both kernels after resume from hibernation I still
get errors like those
listed below, and sound no longer works. I also tried applying the patch
from Kai-Heng Feng
(instead of Hans' patch or my revert) on both kernels and again in both
cases I get these same errors.
Hmm, Hans’ works for me, as acpi_lpss_resume_noirq() calls
acpi_lpss_do_resume_early() for S4.
In contrast, on the 5.0.0 kernel when I revert 02e45646d53b, the problem
is fixed. Because
of changes in adjacent code in 5.1-rc3, I haven't yet found a way to
merge the new code
and the 02e45646d53b revert without causing worse problems. But that's
probably because
I don't really understand the details of that code.
[ 120.690428] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 120.690442] rt5640 i2c-10EC5640:00: Failed to write 13d = 3600: -110
[ 120.712860] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 120.737389] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 120.759657] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 120.781797] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 120.804153] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 120.826467] i2c_designware 80860F41:01: timeout waiting for bus ready
[ 121.965886] i2c_designware 80860F41:01: timeout in disabling adapter
.
[ 132.782634] i2c_designware 80860F41:01: controller timed out
[ 133.806538] i2c_designware 80860F41:01: controller timed out
[ 134.830991] i2c_designware 80860F41:01: controller timed out
[ 135.855183] i2c_designware 80860F41:01: controller timed out
Let me know if I can do any other testing to help.
Is it possible to attach full dmesg? Thanks.
Kai-Heng
Bob Howell
Re: [RFC PATCH v2 1/3] arch/x86: add the support of ACRN guest
On 2019年04月06日 03:01, Thomas Gleixner wrote: Zhao, On Tue, 26 Mar 2019, Zhao Yakui wrote: Vs. the Subject line: arch/x86: add the support of ACRN guest The proper prefix for x86 is surprisingly 'x86:' not 'arch/x86:'. Also please start the first word after the colon with an upper case letter. ACRN is one open-source hypervisour, which is maintained by Linux s/one/an/ foundation. by the Linuxfoundation. This is to add the para-virtualization support so that it allows the Linux guest to run on acrn-hypervisor. This adds x86_hyper_acrn into supported hypervisors array, which enables Linux ACRN guest running on ACRN hypervisor. It is restricted to X86_64. Please do not use 'This is to add' or 'This adds'. Just say: Add v1->v2: Change the CONFIG_ACRN to CONFIG_ACRN_GUEST, which makes it easy to understand. Remove the export of x86_hyper_acrn. Thanks for having the version changes documented, but please put them after the '---' line below and add another '---' before the diffstat. These changes are not part of the final change log and if they are below then I don't have to strip them manually. Sure. It will be updated. Co-developed-by: Jason Chen CJ Signed-off-by: Jason Chen CJ Signed-off-by: Zhao Yakui --- arch/x86/Kconfig | 8 arch/x86/include/asm/hypervisor.h | 1 + arch/x86/kernel/cpu/Makefile | 1 + arch/x86/kernel/cpu/acrn.c| 35 +++ arch/x86/kernel/cpu/hypervisor.c | 4 5 files changed, 49 insertions(+) create mode 100644 arch/x86/kernel/cpu/acrn.c diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index c1f9b3c..d73225e 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -842,6 +842,14 @@ config JAILHOUSE_GUEST cell. You can leave this option disabled if you only want to start Jailhouse and run Linux afterwards in the root cell. +config ACRN_GUEST + bool "ACRN Guest support" + depends on X86_64 && PARAVIRT Why does this select PARAVIRT? The current patches are not implementing anything of the paravirt functionality. Which part of paravirtualization are you going to provide? Thanks for your nice and careful review. Yes. The CONFIG_PARAVIRT is not required. It will be removed. Thanks, tglx
Re: [PATCH] dt-bindings: cpu: Fix JSON schema
On 2019/04/08 7:13, Olof Johansson wrote:
On Tue, Apr 02, 2019 at 08:42:02PM +0900, Sugaya, Taichi wrote:
Hi,
On 2019/04/01 22:02, Sugaya, Taichi wrote:
Hi,
On 2019/04/01 20:35, Maxime Ripard wrote:
Hi,
On Mon, Apr 01, 2019 at 07:52:06PM +0900, Sugaya, Taichi wrote:
On 2019/04/01 18:10, Maxime Ripard wrote:
Hi Sugaya, Arnd, Olof,
On Thu, Mar 28, 2019 at 02:35:54PM -0500, Rob Herring wrote:
+arm-soc
On Mon, Mar 18, 2019 at 5:05 AM Maxime Ripard wrote:
Commit fd73403a4862 ("dt-bindings: arm: Add SMP enable-method for
Milbeaut") added support for a new cpu enable-method, but did so using
tabulations to ident. This is however invalid in the syntax, and resulted
in a failure when trying to use that schemas for validation.
Use spaces instead of tabs to indent to fix this.
Fixes: fd73403a4862 ("dt-bindings: arm: Add SMP enable-method for Milbeaut")
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/arm/cpus.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Rob Herring
This should be applied to arm-soc tree having the commit.
Could you pick up that patch?
I got it.
My mission is to resubmit your fix-patch added my singned-off tag and
Rob's reviewed tag...right?
If you are part of arm-soc and send your pull requests to Arnd and
Olof, simply pick it up in the same branch than the initial patch was
in. And when you apply that patch, you indeed need to add your
Signed-off-by (note that most commands to commit have an option to do
that automatically: -s and that includes git am) and the Rob's
reviewed-by.
Then, send a new pull request to arm-soc.
Okay, thanks for your suggestion.
I try to make pull request!
Sorry I realized that I couldn't make a private repository, so I'll send my Ack
instead.
Acked-by: Sugaya Taichi
Applied to arm/fixes now. Thanks!
-Olof
Thank you for appling!
Re: [RFC PATCH v2 2/3] arch/x86/acrn: Use HYPERVISOR_CALLBACK_VECTOR for Acrn upcall vector
On 2019年04月06日 03:07, Thomas Gleixner wrote:
On Tue, 26 Mar 2019, Zhao Yakui wrote:
diff --git a/arch/x86/include/asm/hardirq.h b/arch/x86/include/asm/hardirq.h
index d9069bb..a8f4d08 100644
--- a/arch/x86/include/asm/hardirq.h
+++ b/arch/x86/include/asm/hardirq.h
@@ -37,7 +37,8 @@ typedef struct {
#ifdef CONFIG_X86_MCE_AMD
unsigned int irq_deferred_error_count;
#endif
-#if IS_ENABLED(CONFIG_HYPERV) || defined(CONFIG_XEN)
+#if IS_ENABLED(CONFIG_HYPERV) || defined(CONFIG_XEN) ||\
+ defined(CONFIG_ACRN_GUEST)
..
@@ -134,7 +134,8 @@ int arch_show_interrupts(struct seq_file *p, int prec)
seq_printf(p, "%10u ", per_cpu(mce_poll_count, j));
seq_puts(p, " Machine check polls\n");
#endif
-#if IS_ENABLED(CONFIG_HYPERV) || defined(CONFIG_XEN)
+#if IS_ENABLED(CONFIG_HYPERV) || defined(CONFIG_XEN) ||\
+ defined(CONFIG_ACRN_GUEST)
if (test_bit(HYPERVISOR_CALLBACK_VECTOR, system_vectors)) {
seq_printf(p, "%*s: ", prec, "HYP");
for_each_online_cpu(j)
This starts to become unreadable. Please create a new config symbol:
config X86_HV_CALLBACK_VECTOR
def_bool
and select if from HYPERV, XEN and your new thing. That wants to be a
separate preparatory patch at the beginning of the series please.
Thanks for the suggestion.
Sure. One new config will be added in next version.
Thanks,
tglx
Re: [RFC PATCH v2 3/3] arch/x86/acrn: add hypercall for acrn_guest
On 2019年04月06日 03:19, Thomas Gleixner wrote:
On Tue, 26 Mar 2019, Zhao Yakui wrote:
When acrn_hypervisor is detected, the hypercall is needed so that the
acrn guest can query/config some settings. For example: it can be used
to query the resources in hypervisor and manage the CPU/memory/device/
interrupt for Guest system.
So the hypercall is added so that the kernel can communicate with the
low-level acrn-hypervisor. On x86 it is implemented by using vmacll when
is implemented with the VMCALL instruction
the acrn hypervisor is enabled.
+++ b/arch/x86/include/asm/acrn_hypercall.h
@@ -0,0 +1,84 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * acrn_hypercall.h : acrn hypervisor call API
No file names in headers please. They are pointless and get out of sync
when files are renamed.
Sure. It will be removed in next vesion.
+ */
+
+#ifndef __ACRN_HYPERCALL_H__
+#define __ACRN_HYPERCALL_H__
asm headers start with
__ASM_X86_
This will be fixed.
+
+#include
+
+#ifdef CONFIG_ACRN_GUEST
+
+/*
+ * Hypercalls for ACRN Guest
+ *
+ * Hypercall number is passed in r8 register.
+ * Return value will be placed in rax.
+ * Up to 2 arguments are passed in rdi, rsi.
+ */
+
+static inline long acrn_hypercall0(unsigned long hcall_id)
+{
+
Remove the empty new line please.
+ register long result asm("rax");
+ register unsigned long r8 asm("r8") = hcall_id;
Please order them the other way around, like a reverse christmas tree:
register unsigned long r8 asm("r8") = hcall_id;
register long result asm("rax");
That's way simpler to read.
This will be fixed.
+ asm volatile(".byte 0x0F,0x01,0xC1\n"
+ : "=r"(result)
+ : "r"(r8));
Please mention in the changelog why this is implemented with bytes and not
with the proper mnemonic. I assume it depends on binutils, so please
document which version of binutils supports the mnemonic.
I check the binutils version mentioned in Document/changes.
(binutils, 2.20)
It seems that the "vmcall" is already supported.
So the "vmcall" mnemonic will be used to make it readable.
And in the first function, i.e. hypercall0, add a comment above the asm
volatile() to that effect as well.
Sure.
Thanks,
tglx
linux-next: manual merge of the staging tree with the staging.current tree
Hi all,
Today's linux-next merge of the staging tree got a conflict in:
drivers/iio/industrialio-buffer.c
between commit:
20ea39ef9f2f ("iio: Fix scan mask selection")
from the staging.current tree and commit:
3862828a903d ("iio: buffer: Switch to bitmap_zalloc()")
from the staging tree.
I fixed it up (I just used the staging tree version) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging. You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpYhnGcUI5Q1.pgp
Description: OpenPGP digital signature
[PATCH 2/2] lib/scatterlist.c: add more commit for sg_alloc_table_from_pages
The get_user_pages_fast() may mess up the page order in @pages array, We will get the wrong DMA results in this case. Add more commit to clarify it. Signed-off-by: Huang Shijie --- lib/scatterlist.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lib/scatterlist.c b/lib/scatterlist.c index 739dc9fe2c55..c170afb1a25e 100644 --- a/lib/scatterlist.c +++ b/lib/scatterlist.c @@ -450,6 +450,9 @@ EXPORT_SYMBOL(__sg_alloc_table_from_pages); *specified by the page array. The returned sg table is released by *sg_free_table. * + * Note: Do not use get_user_pages_fast() to pin the pages for @pages array, + * it may mess up the page order, and we will get the wrong DMA results. + * Returns: * 0 on success, negative error on failure */ -- 2.17.1
[PATCH 1/2] mm/gup.c: fix the wrong comments
When CONFIG_HAVE_GENERIC_GUP is defined, the kernel will use its own get_user_pages_fast(). In the following scenario, we will may meet the bug in the DMA case: . get_user_pages_fast(start,,, pages); .. sg_alloc_table_from_pages(, pages, ...); . The root cause is that sg_alloc_table_from_pages() requires the page order to keep the same as it used in the user space, but get_user_pages_fast() will mess it up. So change the comments, and make it more clear for the driver users. Signed-off-by: Huang Shijie --- mm/gup.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/mm/gup.c b/mm/gup.c index 22acdd0f79ff..fb11ff90ba3b 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -1129,10 +1129,6 @@ EXPORT_SYMBOL(get_user_pages_locked); * with: * * get_user_pages_unlocked(tsk, mm, ..., pages); - * - * It is functionally equivalent to get_user_pages_fast so - * get_user_pages_fast should be used instead if specific gup_flags - * (e.g. FOLL_FORCE) are not required. */ long get_user_pages_unlocked(unsigned long start, unsigned long nr_pages, struct page **pages, unsigned int gup_flags) @@ -2147,6 +2143,10 @@ int __get_user_pages_fast(unsigned long start, int nr_pages, int write, * If not successful, it will fall back to taking the lock and * calling get_user_pages(). * + * Note this routine may fill the pages array with entries in a + * different order than get_user_pages_unlocked(), which may cause + * issues for callers expecting the routines to be equivalent. + * * Returns number of pages pinned. This may be fewer than the number * requested. If nr_pages is 0 or negative, returns 0. If no pages * were pinned, returns -errno. -- 2.17.1
Re: [PATCH v13 1/3] /proc/pid/status: Add support for architecture specific output
On 2019/4/8 9:52, Andy Lutomirski wrote: > On Sun, Apr 7, 2019 at 5:38 PM Li, Aubrey wrote: >> >> On 2019/4/8 1:34, Andy Lutomirski wrote: >>> On Fri, Apr 5, 2019 at 12:32 PM Thomas Gleixner wrote: On Sun, 24 Feb 2019, Aubrey Li wrote: > The architecture specific information of the running processes could > be useful to the userland. Add support to examine process architecture > specific information externally. > > Signed-off-by: Aubrey Li > Cc: Peter Zijlstra > Cc: Andi Kleen > Cc: Tim Chen > Cc: Dave Hansen > Cc: Arjan van de Ven This really lacks Cc: Linux API Cc: Alexey Dobriyan Cc: Andrew Morton Cc'ed now. >>> >>> I certainly understand why you want to expose this info, but would it >>> make more sense to instead add an arch_status file in /proc with >>> architecture-specific info? Or maybe an x86_status field for x86 >>> status, etc. >>> >> >> I tried this, but no other architecture showed interest in arch_status >> under /proc. >> > > Why is that a problem? It could exist on x86 and not exist on other > arches until needed. > I placed it in tid_base_stuff, under live_patch entry, so it exists for all arches, is there a better way to do this? Thanks, -Aubrey
Re: [PATCH v2] srcu: Remove unused vmlinux srcu linker entries
On Sun, Apr 07, 2019 at 08:47:19PM -0400, Joel Fernandes (Google) wrote:
> The SRCU for modules optimization (commit title "srcu: Allocate per-CPU
> data for DEFINE_SRCU() in modules") introduced vmlinux linker entries
> which is unused since it applies only to the built-in vmlinux. So remove
> it to prevent any space usage due to the 8 byte alignment it added.
> vmlinux.lds.h has no effect on module loading and is not used for
> building the module object, so the changes were not needed in the first
> place since the optimization is specific to modules.
>
> Tested with SRCU torture_type and rcutorture. Put prints in module
> loader to confirm it is able to find and initialize the srcu structures.
>
> Cc: Josh Triplett
> Cc: Steven Rostedt
> Cc: Mathieu Desnoyers
> Cc: Lai Jiangshan
> Cc: kernel-t...@android.com
> Cc: paul...@linux.vnet.ibm.com
> Signed-off-by: Joel Fernandes (Google)
Queued, thank you, Joel!
Thanx, Paul
> ---
> v1->v2: Added more context to change log.
>
> include/asm-generic/vmlinux.lds.h | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/include/asm-generic/vmlinux.lds.h
> b/include/asm-generic/vmlinux.lds.h
> index c2d919a1566e..f8f6f04c4453 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -338,10 +338,6 @@
> KEEP(*(__tracepoints_ptrs)) /* Tracepoints: pointer array */ \
> __stop___tracepoints_ptrs = .; \
> *(__tracepoints_strings)/* Tracepoints: strings */ \
> - . = ALIGN(8); \
> - __start___srcu_struct = .; \
> - *(___srcu_struct_ptrs) \
> - __end___srcu_struct = .;\
> } \
> \
> .rodata1 : AT(ADDR(.rodata1) - LOAD_OFFSET) { \
> --
> 2.21.0.392.gf8f6787159e-goog
>
Re: [patch V2 28/29] x86/irq/64: Remap the IRQ stack with guard pages
On Sun, Apr 7, 2019 at 3:44 PM Thomas Gleixner wrote: > > On Sat, 6 Apr 2019, Andy Lutomirski wrote: > > On Fri, Apr 5, 2019 at 8:11 AM Thomas Gleixner wrote: > > > > > > From: Andy Lutomirski > > > > > > The IRQ stack lives in percpu space, so an IRQ handler that overflows it > > > will overwrite other data structures. > > > > > > Use vmap() to remap the IRQ stack so that it will have the usual guard > > > pages that vmap/vmalloc allocations have. With this the kernel will panic > > > immediately on an IRQ stack overflow. > > > > The 0day bot noticed that this dies with DEBUG_PAGEALLOC on. This is > > because the store_stackinfo() function is utter garbage and this patch > > correctly detects just how broken it is. The attached patch "fixes" > > it. (It also contains a reliability improvement that should probably > > get folded in, but is otherwise unrelated.) > > > > A real fix would remove the generic kstack_end() function entirely > > along with __HAVE_ARCH_KSTACK_END and would optionally replace > > store_stackinfo() with something useful. Josh, do we have a generic > > API to do a little stack walk like this? Otherwise, I don't think it > > would be the end of the world to just remove the offending code. > > Actually we have: save_stack_trace() > Like I did here: https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=WIP.x86/stackguards (Link is bad right now but will hopefully be okay when you read it. I'm still fiddling with the other patches in there -- I'd like to kill kstack_end() entirely.
Re: [PATCH] slab: fix a crash by reading /proc/slab_allocators
On 4/7/19 9:59 PM, Tobin C. Harding wrote:
> On Sat, Apr 06, 2019 at 06:59:01PM -0400, Qian Cai wrote:
>> The commit 510ded33e075 ("slab: implement slab_root_caches list")
>> changes the name of the list node within "struct kmem_cache" from
>> "list" to "root_caches_node"
>
> Are you sure? It looks to me like it adds a member to the memcg_cache_array
>
> diff --git a/include/linux/slab.h b/include/linux/slab.h
> index a0cc7a77cda2..af1a5bef80f4 100644
> --- a/include/linux/slab.h
> +++ b/include/linux/slab.h
> @@ -556,6 +556,8 @@ struct memcg_cache_array {
> * used to index child cachces during allocation and cleared
> * early during shutdown.
> *
> + * @root_caches_node: List node for slab_root_caches list.
> + *
> * @children: List of all child caches. While the child caches are also
> * reachable through @memcg_caches, a child cache remains on
> * this list until it is actually destroyed.
> @@ -573,6 +575,7 @@ struct memcg_cache_params {
> union {
> struct {
> struct memcg_cache_array __rcu *memcg_caches;
> + struct list_head __root_caches_node;
> struct list_head children;
> };
>
> And then defines 'root_caches_node' to be 'memcg_params.__root_caches_node'
> if we have CONFIG_MEMCG otherwise defines 'root_caches_node' to be 'list'
>
>
>> but leaks_show() still use the "list"
>
> I believe it should since 'list' is used to add to slab_caches list.
See the offensive commit 510ded33e075 which changed those.
@@ -1136,12 +1146,12 @@ static void print_slabinfo_header(struct seq_file *m)
void *slab_start(struct seq_file *m, loff_t *pos)
{
mutex_lock(_mutex);
- return seq_list_start(_caches, *pos);
+ return seq_list_start(_root_caches, *pos);
}
void *slab_next(struct seq_file *m, void *p, loff_t *pos)
{
- return seq_list_next(p, _caches, pos);
+ return seq_list_next(p, _root_caches, pos);
}
and then memcg_link_cache() does,
if (is_root_cache(s)) {
list_add(>root_caches_node, _root_caches);
memcg_unlink_cache() does,
if (is_root_cache(s)) {
list_del(>root_caches_node);
It also changed /proc/slabinfo but forgot to change /proc/slab_allocators.
@@ -1193,12 +1203,11 @@ static void cache_show(struct kmem_cache *s, struct
seq_file *m)
static int slab_show(struct seq_file *m, void *p)
{
- struct kmem_cache *s = list_entry(p, struct kmem_cache, list);
+ struct kmem_cache *s = list_entry(p, struct kmem_cache,
root_caches_node);
>
>> which causes a crash when reading /proc/slab_allocators.
>
> I was unable to reproduce this crash, I built with
>
> # CONFIG_MEMCG is not set
> CONFIG_SLAB=y
> CONFIG_SLAB_MERGE_DEFAULT=y
> CONFIG_SLAB_FREELIST_RANDOM=y
> CONFIG_DEBUG_SLAB=y
> CONFIG_DEBUG_SLAB_LEAK=y
>
> I then booted in Qemu and successfully ran
> $ cat slab_allocators
>
> Perhaps you could post your config?
Yes, it won't be reproducible without CONFIG_MEMCG=y, because it has,
/* If !memcg, all caches are root. */
#define slab_root_caches slab_caches
#define root_caches_node list
Anyway,
https://git.sr.ht/~cai/linux-debug/blob/master/config
RE: [EXT] Re: [PATCH] iio: accell: mma8452: free iio trigger pointer when cleanup
Hi, Jonathan
Best Regards!
Anson Huang
> -Original Message-
> From: Jonathan Cameron [mailto:ji...@kernel.org]
> Sent: 2019年4月7日 18:40
> To: Anson Huang
> Cc: knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net; Leonard
> Crestez ; gust...@embeddedor.com;
> mart...@posteo.de; rtres...@electromag.com.au; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; dl-linux-imx
> Subject: [EXT] Re: [PATCH] iio: accell: mma8452: free iio trigger pointer when
> cleanup
>
> WARNING: This email was created outside of NXP. DO NOT CLICK links or
> attachments unless you recognize the sender and know the content is safe.
>
>
>
> On Thu, 4 Apr 2019 08:02:05 +
> Anson Huang wrote:
>
> > When mma8452 is built as module, once it is insmod and rmmod, below
> > kernel dump will show out, the root cause is module being put twice if
> > iio trigger pointer is NOT NULL, this patch frees iio trigger pointer
> > after iio trigger is unregistered to avoid below kernel
> > dump:
> >
> > [ cut here ]
> > WARNING: CPU: 3 PID: 270 at kernel/module.c:1145
> module_put+0xd0/0x188
> > Modules linked in: mma8452(-)
> > CPU: 3 PID: 270 Comm: rmmod Not tainted
> > 5.1.0-rc3-next-20190403-00022-g5ede0c9-dirty #1596 Hardware name:
> > Freescale i.MX6 Quad/DualLite (Device Tree) []
> > (unwind_backtrace) from [] (show_stack+0x10/0x14)
> > [] (show_stack) from [] (dump_stack+0xd8/0x10c)
> > [] (dump_stack) from [] (__warn+0xf8/0x124)
> > [] (__warn) from []
> (warn_slowpath_null+0x3c/0x48)
> > [] (warn_slowpath_null) from []
> > (module_put+0xd0/0x188) [] (module_put) from []
> > (iio_device_unregister_trigger_consumer+0x18/0x24)
> > [] (iio_device_unregister_trigger_consumer) from
> > [] (iio_dev_release+0x20/0) [] (iio_dev_release)
> > from [] (device_release+0x24/0x8c) []
> > (device_release) from [] (kobject_put+0x74/0xd4)
> > [] (kobject_put) from []
> > (release_nodes+0x16c/0x1f0) [] (release_nodes) from
> > [] (device_release_driver_internal+0xec/0x1a0)
> > [] (device_release_driver_internal) from []
> > (driver_detach+0x44/0x80) [] (driver_detach) from
> > [] (bus_remove_driver+0x4c/0xa0) []
> > (bus_remove_driver) from [] (sys_delete_module+0x130/0x1dc)
> > [] (sys_delete_module) from []
> (ret_fast_syscall+0x0/0x28) Exception stack(0xe8d87fa8 to 0xe8d87ff0)
> > 7fa0: 0001ffc0 38616d6d be87bbf0 0880
> > be87be98
> > 7fc0: 0001ffc0 38616d6d 00323534 0081 000a9744 be87bf81 000a9790
> >
> > 7fe0: be87bbe8 be87bbd8 0001fe18 b6e381a0 irq event stamp: 4017
> > hardirqs last enabled at (4035): []
> > console_unlock+0x400/0x630 hardirqs last disabled at (4052):
> > [] console_unlock+0x80/0x630 softirqs last enabled at
> > (4050): [] __do_softirq+0x458/0x554 softirqs last disabled
> > at (4069): [] irq_exit+0x130/0x180 ---[ end trace
> > a7ba8f1823b1e073 ]---
> >
> > Signed-off-by: Anson Huang
> Good fine, but the fix is not in the best place. The key thing is that any
> assignment inside a driver to iio_dev->trig should be done with
> iio_trigger_get.
>
> indio_dev->trig = iio_trigger_get(trig). The intent is to avoid this exact
> double
> free, but also handle it correctly if we are using devm_ for all the handling.
>
> I just did a grep and there are quite a few drivers not doing this though so
> it's
> one we should be more careful about.
>
> Hmm. Anyone fancy doing an audit of existing drivers and checking which
> ones have this problem? Some seem to do exactly what you have here, but
> that isn't a the best pattern to encourage.
>
> For this one would you mind trying with the iio_trigger_get approach and if
> I'm not missing something, send a v2 fixing it that way?
With below patch to use iio_trigger_get, looks like try_release_module_ref()
will return 1
and cause try_stop_module() return fail and we will see " rmmod: can't unload
'mma8452': Resource temporarily unavailable ",
As the module ref count check is before
iio_device_unregister_trigger_consumer() is called which
will do iio_trigger_put(), so looks like there is still something wrong with
the module ref count?
+++ b/drivers/iio/accel/mma8452.c
@@ -1468,17 +1468,15 @@ static int mma8452_trigger_setup(struct iio_dev
*indio_dev)
if (ret)
return ret;
- indio_dev->trig = trig;
+ indio_dev->trig = iio_trigger_get(trig);
Thanks,
Anson.
>
> Thanks
>
> Jonathan
>
>
> > ---
> > drivers/iio/accel/mma8452.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> > index 3027811..6b18177 100644
> > --- a/drivers/iio/accel/mma8452.c
> > +++ b/drivers/iio/accel/mma8452.c
> > @@ -1475,8 +1475,10 @@ static int mma8452_trigger_setup(struct iio_dev
> > *indio_dev)
> >
> > static void mma8452_trigger_cleanup(struct iio_dev *indio_dev) {
> > - if (indio_dev->trig)
> > + if (indio_dev->trig) {
> > iio_trigger_unregister(indio_dev->trig);
Re: [PATCH v9 1/2] dt-bindings: misc: aspeed-p2a-ctrl: add support
On Fri, 5 Apr 2019, at 01:55, Patrick Venture wrote:
> Document the ast2400, ast2500 PCI-to-AHB bridge control driver bindings.
>
> Signed-off-by: Patrick Venture
> Reviewed-by: Rob Herring
> ---
> Changes for v9:
> - Added missing details about syscon parent
> Changes for v8:
> - None
> Changes for v7:
> - Moved node under the syscon node it requires
> Changes for v6:
> - None
> Changes for v5:
> - None
> Changes for v4:
> - None
> Changes for v3:
> - None
> Changes for v2:
> - Added comment about syscon required parameter.
> ---
> .../bindings/misc/aspeed-p2a-ctrl.txt | 56 +++
> 1 file changed, 56 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
>
> diff --git a/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
> b/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
> new file mode 100644
> index 0..05ed654848b60
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
> @@ -0,0 +1,56 @@
> +==
> +Device tree bindings for Aspeed AST2400/AST2500 PCI-to-AHB Bridge
> Control Driver
> +==
> +
> +The bridge is available on platforms with the VGA enabled on the
> Aspeed device.
> +In this case, the host has access to a 64KiB window into all of the
> BMC's
> +memory. The BMC can disable this bridge. If the bridge is enabled,
> the host
> +has read access to all the regions of memory, however the host only
> has read
> +and write access depending on a register controlled by the BMC.
> +
> +Required properties:
> +===
> +
> + - compatible: must be one of:
> + - "aspeed,ast2400-p2a-ctrl"
> + - "aspeed,ast2500-p2a-ctrl"
> +
> +Optional properties:
> +===
> +
> +- memory-region: A phandle to a reserved_memory region to be used for
> the PCI
> + to AHB mapping
> +
> +The p2a-control node should be the child of a syscon node with the
> required
> +property:
> +
> +- compatible : Should be one of the following:
> + "aspeed,ast2400-scu", "syscon", "simple-mfd"
> + "aspeed,g4-scu", "syscon", "simple-mfd"
> + "aspeed,ast2500-scu", "syscon", "simple-mfd"
> + "aspeed,g5-scu", "syscon", "simple-mfd"
> +
> +The aspeed-p2a-ctrl node should be the child of a syscon node with the
> required
> +property:
> +
> +- compatible : Should be one of the following:
> + "aspeed,ast2400-scu", "syscon", "simple-mfd"
> + "aspeed,g4-scu", "syscon", "simple-mfd"
> + "aspeed,ast2500-scu", "syscon", "simple-mfd"
> + "aspeed,g5-scu", "syscon", "simple-mfd"
Agh, now the info's here twice!
Next time, surely :D
Unless Greg or Rob want to chop one out as they apply it? It looks good to
me otherwise.
Andrew
> +
> +Example
> +===
> +
> +g4 Example
> +--
> +
> +syscon: scu@1e6e2000 {
> + compatible = "aspeed,ast2400-scu", "syscon", "simple-mfd";
> + reg = <0x1e6e2000 0x1a8>;
> +
> + p2a: p2a-control {
> + compatible = "aspeed,ast2400-p2a-ctrl";
> + memory-region = <_memory>;
> + };
> +};
> --
> 2.21.0.392.gf8f6787159e-goog
>
>
Re: [PATCH] slab: fix a crash by reading /proc/slab_allocators
On Sat, Apr 06, 2019 at 06:59:01PM -0400, Qian Cai wrote:
> The commit 510ded33e075 ("slab: implement slab_root_caches list")
> changes the name of the list node within "struct kmem_cache" from
> "list" to "root_caches_node"
Are you sure? It looks to me like it adds a member to the memcg_cache_array
diff --git a/include/linux/slab.h b/include/linux/slab.h
index a0cc7a77cda2..af1a5bef80f4 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -556,6 +556,8 @@ struct memcg_cache_array {
* used to index child cachces during allocation and cleared
* early during shutdown.
*
+ * @root_caches_node: List node for slab_root_caches list.
+ *
* @children: List of all child caches. While the child caches are also
* reachable through @memcg_caches, a child cache remains on
* this list until it is actually destroyed.
@@ -573,6 +575,7 @@ struct memcg_cache_params {
union {
struct {
struct memcg_cache_array __rcu *memcg_caches;
+ struct list_head __root_caches_node;
struct list_head children;
};
And then defines 'root_caches_node' to be 'memcg_params.__root_caches_node'
if we have CONFIG_MEMCG otherwise defines 'root_caches_node' to be 'list'
> but leaks_show() still use the "list"
I believe it should since 'list' is used to add to slab_caches list.
> which causes a crash when reading /proc/slab_allocators.
I was unable to reproduce this crash, I built with
# CONFIG_MEMCG is not set
CONFIG_SLAB=y
CONFIG_SLAB_MERGE_DEFAULT=y
CONFIG_SLAB_FREELIST_RANDOM=y
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_SLAB_LEAK=y
I then booted in Qemu and successfully ran
$ cat slab_allocators
Perhaps you could post your config?
Hope this helps,
Tobin.
Re: [PATCH v13 1/3] /proc/pid/status: Add support for architecture specific output
On Sun, Apr 7, 2019 at 5:38 PM Li, Aubrey wrote: > > On 2019/4/8 1:34, Andy Lutomirski wrote: > > On Fri, Apr 5, 2019 at 12:32 PM Thomas Gleixner wrote: > >> > >> On Sun, 24 Feb 2019, Aubrey Li wrote: > >> > >>> The architecture specific information of the running processes could > >>> be useful to the userland. Add support to examine process architecture > >>> specific information externally. > >>> > >>> Signed-off-by: Aubrey Li > >>> Cc: Peter Zijlstra > >>> Cc: Andi Kleen > >>> Cc: Tim Chen > >>> Cc: Dave Hansen > >>> Cc: Arjan van de Ven > >> > >> This really lacks > >> > >> Cc: Linux API > >> Cc: Alexey Dobriyan > >> Cc: Andrew Morton > >> > >> Cc'ed now. > >> > > > > I certainly understand why you want to expose this info, but would it > > make more sense to instead add an arch_status file in /proc with > > architecture-specific info? Or maybe an x86_status field for x86 > > status, etc. > > > > I tried this, but no other architecture showed interest in arch_status > under /proc. > Why is that a problem? It could exist on x86 and not exist on other arches until needed.
Re: [PATCH 08/14] powercap/intel_rapl: Support multi-die/package
On 五, 2019-04-05 at 20:27 +0200, Thomas Gleixner wrote:
> On Tue, 26 Feb 2019, Len Brown wrote:
>
> >
> > From: Zhang Rui
> >
> > On the new dual-die/package systems, the RAPL MSR becomes die-
> > scope.
> > Thus instead of one powercap device per physical package, now there
> > should be one powercap device for each unique die on these systems.
> >
> > This patch introduces intel_rapl driver support for new
> > dual-die/package systems.
> This patch See Documentation/processs/
>
> and this sentence is not really helpful either.
>
> >
> > On the hardwares that do not have multi-die,
> > topology_logical_die_id()
> > equals topology_physical_package_id(), thus there is no functional
> > change.
> Something like this:
>
> To support this the RAPL package domain has to be identified by the
> die id
> instead of the package id. On single die CPUs the die id is the same
> as the
> physical package id.
>
> Hmm?
Yeah, sounds much better.
Len, will you help me update the changelog or do you want me to send an
updated version to you?
thanks,
rui
>
> >
> > Signed-off-by: Zhang Rui
> > Signed-off-by: Len Brown
> > Acked-by: Rafael J. Wysocki
> > Cc: linux...@vger.kernel.org
> > ---
> > drivers/powercap/intel_rapl.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/powercap/intel_rapl.c
> > b/drivers/powercap/intel_rapl.c
> > index 6057d9695fed..8723e9ae7436 100644
> > --- a/drivers/powercap/intel_rapl.c
> > +++ b/drivers/powercap/intel_rapl.c
> > @@ -266,7 +266,7 @@ static struct rapl_domain
> > *platform_rapl_domain; /* Platform (PSys) domain */
> > /* caller to ensure CPU hotplug lock is held */
> > static struct rapl_package *rapl_find_package(int cpu)
> > {
> > - int id = topology_physical_package_id(cpu);
> > + int id = topology_logical_die_id(cpu);
> > struct rapl_package *rp;
> >
> > list_for_each_entry(rp, _packages, plist) {
> > @@ -1457,7 +1457,7 @@ static void rapl_remove_package(struct
> > rapl_package *rp)
> > /* called from CPU hotplug notifier, hotplug lock held */
> > static struct rapl_package *rapl_add_package(int cpu)
> > {
> > - int id = topology_physical_package_id(cpu);
> > + int id = topology_logical_die_id(cpu);
> > struct rapl_package *rp;
> > int ret;
> >
linux-next: manual merge of the audit tree with Linus' tree
Hi all,
Today's linux-next merge of the audit tree got conflicts in:
arch/mips/kernel/ptrace.c
kernel/seccomp.c
between commit:
b35f549df1d7 ("syscalls: Remove start and number from syscall_get_arguments()
args")
from Linus' tree and commit:
16add411645c ("syscall_get_arch: add "struct task_struct *" argument")
from the audit tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/mips/kernel/ptrace.c
index 3a62f80958e1,2ead6ff919b7..
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@@ -1418,8 -1418,8 +1418,8 @@@ asmlinkage long syscall_trace_enter(str
unsigned long args[6];
sd.nr = syscall;
- sd.arch = syscall_get_arch();
+ sd.arch = syscall_get_arch(current);
- syscall_get_arguments(current, regs, 0, 6, args);
+ syscall_get_arguments(current, regs, args);
for (i = 0; i < 6; i++)
sd.args[i] = args[i];
sd.instruction_pointer = KSTK_EIP(current);
diff --cc kernel/seccomp.c
index df27e499956a,36f36ab00f48..
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@@ -148,8 -148,8 +148,8 @@@ static void populate_seccomp_data(struc
unsigned long args[6];
sd->nr = syscall_get_nr(task, regs);
- sd->arch = syscall_get_arch();
+ sd->arch = syscall_get_arch(task);
- syscall_get_arguments(task, regs, 0, 6, args);
+ syscall_get_arguments(task, regs, args);
sd->args[0] = args[0];
sd->args[1] = args[1];
sd->args[2] = args[2];
pgpzceiLMortN.pgp
Description: OpenPGP digital signature
Re: Using device tree overlays in Linux
Hi Frank,
On 8/04/19 1:05 PM, Frank Rowand wrote:
> Hi Chris,
>
> On 4/3/19 6:50 PM, Chris Packham wrote:
>> Hi,
>>
>> I'm implementing support for some modular Linux based systems using
>> device tree overlays. The code is working but it seems a little more
>> fiddly that than it should be so I'm wondering if I'm doing it right.
>
> Let me start by saying that I strongly discourage using device tree
> overlays in the Linux kernel until the support is more baked. For
> some info on how unbaked overlays are, see:
>
> https://elinux.org/Frank%27s_Evolving_Overlay_Thoughts
>
> You should consider applying overlays in the Linux kernel to be
> fragile at best.
>
> If you can not figure out how to solve your needs without using
> overlays, then having the boot loader apply the overlay instead
> of the kernel applying the overlay avoids most of the issues.
>
Consider us beta-testers :).
We've got a few modular systems that have miscellaneous devices that we
want to be hot-swapping at run time. For the most part the devices in
question are i2c based. We want to use overlays as it saves manually
instantiating devices and avoids needing specific knowledge of the base
platform.
>> An example of what I'm doing is
>>
>>
>> arch/arm/boot/dts/Makefile:
>> DTC_FLAGS_myboard += -@
>>
>> drivers/foo/Makefile:
>> obj-y += myplugin.dtb.o
>> obj-y += mydriver.o
>>
>> drivers/foo/myplugin.dts:
>> /dts-v1/;
>> /plugin/;
>> /{
>> fragment@0 {
>> target = <>;
>> __overlay__ {
>> gpio@74 {
>> compatible = "nxp,pca9539";
>> reg = <0x74>
>> };
>> };
>> };
>> };
>
> The fragment and __overlay__ nodes are implementation, subject to
> change, and should not be hand coded. The dtc compiler has added
> features to allow a more generic source code. The above should be:
>
> // SPDX-License-Identifier: GPL-2.0
> /dts-v1/;
> /plugin/;
>
> {
> gpio@74 {
> compatible = "nxp,pca9539";
> reg = <0x74>;
> };
> };
>
> (Not compiled, not tested.)
>
> The rcar overlay sources were merged before dtc was updated to
> handle this new syntax, so they are not a good example for
> how to write an overlay.
OK thanks. I suspected as much. I'll update my code based on your example.
>> drivers/foo/mydriver.c:
>> extern uint8_t __dtb_myplugin_begin[];
>> extern uint8_t __dtb_myplugin_end[];
>>
>> int mydriver_probe(struct platform_device *pdev)
>> {
>> u32 size = __dtb_myplugin_end - __dtb_myplugin_begin;
>> int overlay_id;
>> int ret;
>>
>> ret = of_overlay_fdt_apply(__dtb_myplugin_begin,
>> size, _id);
>> return ret;
>> }
>
> I'm guessing that you have simplified your use case to make it easier to
> describe (thank you for that). But that also makes it harder to understand
> the use case, and whether this is a good solution. Can you describe your
> use case in some more detail?
As I said above we have a few different modular systems we're trying to
support. But they all do basically the same thing.
The insertion of a module is detected based on a gpio line being asserted.
Then we identify what was just inserted, the details vary a little per
platform but in one instance we load an overlay that has instantiates an
i2c eeprom identifying the module.
Once we know which specific module has been inserted based on the data
in the eeprom we load another overlay that instantiates the rest of the
devices on that module.
>> The first issue is that I need to add -@ to the DTC_FLAGS for my board
>> dtb. I kind of understand that I only need -@ if my overlay targets
>> something symbolic so I might not need it but I was surprised that there
>> wasn't a Kconfig option that makes this happen automatically.
>>
>> externing things in C files makes checkpatch.pl complain. I see the
>> of/unittests.c and rcar_du_of.c hide this with a macro. I was again
>> surprised that there wasn't a common macro to declare these.
>
> unittests.c should not be used as a model of how to code for devicetree.
> There are some hacks that are needed to be able to test, but should not
> be used by normal drivers.
>
> The rcar use of overlays is a temporary hack to provide backward
> compatibility. The intent is to drop this code once the backward
> compatibility window ends.
Yes I suspected as much.
> The long-term intent (once enough of the overlay code is in place) is
> to provide an overlay loader than can apply an overlay .dtb from a file.
Would that be a kernel helper or driven via udev?
Re: [PATCH] mm/gup.c: fix the wrong comments
On Thu, Apr 04, 2019 at 09:50:47AM -0700, Ira Weiny wrote: > On Thu, Apr 04, 2019 at 03:23:47PM +0800, Huang Shijie wrote: > > When CONFIG_HAVE_GENERIC_GUP is defined, the kernel will use its own > > get_user_pages_fast(). > > > > In the following scenario, we will may meet the bug in the DMA case: > > . > > get_user_pages_fast(start,,, pages); > > .. > > sg_alloc_table_from_pages(, pages, ...); > > . > > > > The root cause is that sg_alloc_table_from_pages() requires the > > page order to keep the same as it used in the user space, but > > get_user_pages_fast() will mess it up. > > I wonder if there is something we can do to change sg_alloc_table_from_pages() > to work? Reading the comment for it there is no indication of this > limitation. The sg_alloc_table_from_pages() cannot work if the page order is wrong... > So should we update that comment as well? Okay. I will create a DMA patch to add more comment for sg_alloc_table_from_pages(). Thanks Huang Shijie
Re: [PATCH] of: Documentation: Correct return value from of_overlay_fdt_apply
On 4/3/19 7:25 PM, Chris Packham wrote: > The return from of_overlay_fdt_apply() just indicates success or fail. > The cookie is returned via reference. > > Signed-off-by: Chris Packham > --- > Documentation/devicetree/overlay-notes.txt | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/overlay-notes.txt > b/Documentation/devicetree/overlay-notes.txt > index 725fb8d255c1..62f2003d6205 100644 > --- a/Documentation/devicetree/overlay-notes.txt > +++ b/Documentation/devicetree/overlay-notes.txt > @@ -88,7 +88,8 @@ Overlay in-kernel API > The API is quite easy to use. > > 1. Call of_overlay_fdt_apply() to create and apply an overlay changeset. The > -return value is an error or a cookie identifying this overlay. > +return indicates success or failure. A a cookie identifying this overlay is > +returned via reference on success. > > 2. Call of_overlay_remove() to remove and cleanup the overlay changeset > previously created via the call to of_overlay_fdt_apply(). Removal of an > Reviewed-by: Frank Rowand
Re: Using device tree overlays in Linux
Hi Chris,
On 4/3/19 6:50 PM, Chris Packham wrote:
> Hi,
>
> I'm implementing support for some modular Linux based systems using
> device tree overlays. The code is working but it seems a little more
> fiddly that than it should be so I'm wondering if I'm doing it right.
Let me start by saying that I strongly discourage using device tree
overlays in the Linux kernel until the support is more baked. For
some info on how unbaked overlays are, see:
https://elinux.org/Frank%27s_Evolving_Overlay_Thoughts
You should consider applying overlays in the Linux kernel to be
fragile at best.
If you can not figure out how to solve your needs without using
overlays, then having the boot loader apply the overlay instead
of the kernel applying the overlay avoids most of the issues.
> An example of what I'm doing is
>
>
> arch/arm/boot/dts/Makefile:
> DTC_FLAGS_myboard += -@
>
> drivers/foo/Makefile:
> obj-y += myplugin.dtb.o
> obj-y += mydriver.o
>
> drivers/foo/myplugin.dts:
> /dts-v1/;
> /plugin/;
> /{
> fragment@0 {
> target = <>;
> __overlay__ {
> gpio@74 {
> compatible = "nxp,pca9539";
> reg = <0x74>
> };
> };
> };
> };
The fragment and __overlay__ nodes are implementation, subject to
change, and should not be hand coded. The dtc compiler has added
features to allow a more generic source code. The above should be:
// SPDX-License-Identifier: GPL-2.0
/dts-v1/;
/plugin/;
{
gpio@74 {
compatible = "nxp,pca9539";
reg = <0x74>;
};
};
(Not compiled, not tested.)
The rcar overlay sources were merged before dtc was updated to
handle this new syntax, so they are not a good example for
how to write an overlay.
> drivers/foo/mydriver.c:
> extern uint8_t __dtb_myplugin_begin[];
> extern uint8_t __dtb_myplugin_end[];
>
> int mydriver_probe(struct platform_device *pdev)
> {
> u32 size = __dtb_myplugin_end - __dtb_myplugin_begin;
> int overlay_id;
> int ret;
>
> ret = of_overlay_fdt_apply(__dtb_myplugin_begin,
> size, _id);
> return ret;
> }
I'm guessing that you have simplified your use case to make it easier to
describe (thank you for that). But that also makes it harder to understand
the use case, and whether this is a good solution. Can you describe your
use case in some more detail?
> The first issue is that I need to add -@ to the DTC_FLAGS for my board
> dtb. I kind of understand that I only need -@ if my overlay targets
> something symbolic so I might not need it but I was surprised that there
> wasn't a Kconfig option that makes this happen automatically.
>
> externing things in C files makes checkpatch.pl complain. I see the
> of/unittests.c and rcar_du_of.c hide this with a macro. I was again
> surprised that there wasn't a common macro to declare these.
unittests.c should not be used as a model of how to code for devicetree.
There are some hacks that are needed to be able to test, but should not
be used by normal drivers.
The rcar use of overlays is a temporary hack to provide backward
compatibility. The intent is to drop this code once the backward
compatibility window ends.
The long-term intent (once enough of the overlay code is in place) is
to provide an overlay loader than can apply an overlay .dtb from a file.
-Frank
Re: [PATCH] kprobes: fix compilation when KPROBE_EVENTS is enabled without kretpobes
On Sat, 6 Apr 2019 17:55:43 +0200
Sven Schnelle wrote:
> While implementing kprobes on PA-RISC (without kretprobes) compilation
> fails when CONFIG_KPROBE_EVENTS is enabled:
>
> kernel/trace/trace_kprobe.o: in function `trace_kprobe_create':
> kernel/trace/trace_kprobe.c:666: undefined reference to `kprobe_on_func_entry'
> kernel/trace/trace_kprobe.o: in function `trace_kprobe_on_func_entry':
> kernel/trace/trace_kprobe.c:167: undefined reference to `kprobe_on_func_entry'
> kernel/trace/trace_kprobe.c:167: undefined reference to `kprobe_on_func_entry'
> make: *** [Makefile:1029: vmlinux] Error 1
>
> Given the fact that these functions have no dependencies on kretprobes i think
> they should be moved out of the #ifdef CONFIG_KRETPROBES block.
Ah, I got it. Yes, this function had been introduced for kretprobe (because
kretprobe must be the entry of functions) but is used for kprobe_event and
bpf now.
It should be moved out of CONFIG_KPROBE_EVENTS.
Acked-by: Masami Hiramatsu
Thank you,
>
> Signed-off-by: Sven Schnelle
> Cc: "Naveen N. Rao"
> Cc: Anil S Keshavamurthy
> Cc: "David S. Miller"
> Cc: Masami Hiramatsu
> ---
> kernel/kprobes.c | 39 ---
> 1 file changed, 20 insertions(+), 19 deletions(-)
>
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index c83e54727131..10a7e67fea67 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -1819,6 +1819,26 @@ unsigned long __weak arch_deref_entry_point(void
> *entry)
> return (unsigned long)entry;
> }
>
> +bool __weak arch_kprobe_on_func_entry(unsigned long offset)
> +{
> + return !offset;
> +}
> +
> +bool kprobe_on_func_entry(kprobe_opcode_t *addr, const char *sym,
> + unsigned long offset)
> +{
> + kprobe_opcode_t *kp_addr = _kprobe_addr(addr, sym, offset);
> +
> + if (IS_ERR(kp_addr))
> + return false;
> +
> + if (!kallsyms_lookup_size_offset((unsigned long)kp_addr, NULL, )
> ||
> + !arch_kprobe_on_func_entry(offset))
> + return false;
> +
> + return true;
> +}
> +
> #ifdef CONFIG_KRETPROBES
> /*
> * This kprobe pre_handler is registered with every kretprobe. When probe
> @@ -1875,25 +1895,6 @@ static int pre_handler_kretprobe(struct kprobe *p,
> struct pt_regs *regs)
> }
> NOKPROBE_SYMBOL(pre_handler_kretprobe);
>
> -bool __weak arch_kprobe_on_func_entry(unsigned long offset)
> -{
> - return !offset;
> -}
> -
> -bool kprobe_on_func_entry(kprobe_opcode_t *addr, const char *sym, unsigned
> long offset)
> -{
> - kprobe_opcode_t *kp_addr = _kprobe_addr(addr, sym, offset);
> -
> - if (IS_ERR(kp_addr))
> - return false;
> -
> - if (!kallsyms_lookup_size_offset((unsigned long)kp_addr, NULL, )
> ||
> -
> !arch_kprobe_on_func_entry(offset))
> - return false;
> -
> - return true;
> -}
> -
> int register_kretprobe(struct kretprobe *rp)
> {
> int ret = 0;
> --
> 2.20.1
>
--
Masami Hiramatsu
[PATCH v2] srcu: Remove unused vmlinux srcu linker entries
The SRCU for modules optimization (commit title "srcu: Allocate per-CPU
data for DEFINE_SRCU() in modules") introduced vmlinux linker entries
which is unused since it applies only to the built-in vmlinux. So remove
it to prevent any space usage due to the 8 byte alignment it added.
vmlinux.lds.h has no effect on module loading and is not used for
building the module object, so the changes were not needed in the first
place since the optimization is specific to modules.
Tested with SRCU torture_type and rcutorture. Put prints in module
loader to confirm it is able to find and initialize the srcu structures.
Cc: Josh Triplett
Cc: Steven Rostedt
Cc: Mathieu Desnoyers
Cc: Lai Jiangshan
Cc: kernel-t...@android.com
Cc: paul...@linux.vnet.ibm.com
Signed-off-by: Joel Fernandes (Google)
---
v1->v2: Added more context to change log.
include/asm-generic/vmlinux.lds.h | 4
1 file changed, 4 deletions(-)
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index c2d919a1566e..f8f6f04c4453 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -338,10 +338,6 @@
KEEP(*(__tracepoints_ptrs)) /* Tracepoints: pointer array */ \
__stop___tracepoints_ptrs = .; \
*(__tracepoints_strings)/* Tracepoints: strings */ \
- . = ALIGN(8); \
- __start___srcu_struct = .; \
- *(___srcu_struct_ptrs) \
- __end___srcu_struct = .;\
} \
\
.rodata1 : AT(ADDR(.rodata1) - LOAD_OFFSET) { \
--
2.21.0.392.gf8f6787159e-goog
Re: [PATCH v13 1/3] /proc/pid/status: Add support for architecture specific output
On 2019/4/7 23:46, Alexey Dobriyan wrote: > On Sun, Apr 07, 2019 at 09:02:38PM +0800, Li, Aubrey wrote: >> On 2019/4/7 5:41, Alexey Dobriyan wrote: >>> On Fri, Apr 05, 2019 at 09:32:35PM +0200, Thomas Gleixner wrote: > +/* Add support for architecture specific output in /proc/pid/status */ > +extern void arch_proc_pid_status(struct seq_file *m, struct task_struct > *task); >>> ^^ >>> >>> Unnecessary extern. >>> >> The linkage is default extern, but with this functions and variables >> can be treated the same way. >> >> Is it mandatory not to use it explicitly? ./script/checkpatch.pl did >> not report this. > > "extern" is only necessary for variables. For prototypes, it is more typing > and more characters on the screen. > > checkpatch.pl doesn't report it because opening floodgates is not the plan. > > Yours, > Extern Police. > No problem, Mr. Police, I can remove it in the next version. Thanks, -Aubrey
[PATCH] srcu: Remove unused vmlinux srcu linker entries
The SRCU for modules optimization introduced vmlinux linker entries
which is unused since it applies only to the built-in vmlinux. So remove
it to prevent any space usage due to the 8 byte alignment it added.
Tested with SRCU torture_type and rcutorture. Put prints in module
loader to confirm it is able to find and initialize the srcu structures.
Cc: kernel-t...@android.com
Cc: paul...@linux.vnet.ibm.com
Signed-off-by: Joel Fernandes (Google)
---
include/asm-generic/vmlinux.lds.h | 4
1 file changed, 4 deletions(-)
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index c2d919a1566e..f8f6f04c4453 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -338,10 +338,6 @@
KEEP(*(__tracepoints_ptrs)) /* Tracepoints: pointer array */ \
__stop___tracepoints_ptrs = .; \
*(__tracepoints_strings)/* Tracepoints: strings */ \
- . = ALIGN(8); \
- __start___srcu_struct = .; \
- *(___srcu_struct_ptrs) \
- __end___srcu_struct = .;\
} \
\
.rodata1 : AT(ADDR(.rodata1) - LOAD_OFFSET) { \
--
2.21.0.392.gf8f6787159e-goog
Re: [PATCH v13 1/3] /proc/pid/status: Add support for architecture specific output
On 2019/4/8 1:34, Andy Lutomirski wrote: > On Fri, Apr 5, 2019 at 12:32 PM Thomas Gleixner wrote: >> >> On Sun, 24 Feb 2019, Aubrey Li wrote: >> >>> The architecture specific information of the running processes could >>> be useful to the userland. Add support to examine process architecture >>> specific information externally. >>> >>> Signed-off-by: Aubrey Li >>> Cc: Peter Zijlstra >>> Cc: Andi Kleen >>> Cc: Tim Chen >>> Cc: Dave Hansen >>> Cc: Arjan van de Ven >> >> This really lacks >> >> Cc: Linux API >> Cc: Alexey Dobriyan >> Cc: Andrew Morton >> >> Cc'ed now. >> > > I certainly understand why you want to expose this info, but would it > make more sense to instead add an arch_status file in /proc with > architecture-specific info? Or maybe an x86_status field for x86 > status, etc. > I tried this, but no other architecture showed interest in arch_status under /proc. Thanks, -Aubrey
Linux 5.1-rc4
Another week, another rc. Smaller than rc3, I'm happy to say. Nothing particularly big in here, just a number of small things all over. And it really is all over. Drivers are about a third (networking, block, gpu, scsi), with the rest being a mix of arch updates, filesystem updates, documentation, core networking, tooling.. So there's no single theme here, just spread out smallish fixes all over. Shortlog appended for people who want to get an overview of the details, Linus --- Aaro Koskinen (6): net: stmmac: use correct DMA buffer size in the RX descriptor net: stmmac: ratelimit RX error logs net: stmmac: don't stop NAPI processing when dropping a packet net: stmmac: don't overwrite discard_frame status net: stmmac: fix dropping of multi-descriptor RX frames net: stmmac: don't log oversized frames Aditya Pakki (1): net: mlx5: Add a missing check on idr_find, free buf Al Viro (11): aio: fold lookup_kiocb() into its sole caller aio: keep io_event in aio_kiocb aio: store event at final iocb_put() Fix aio_poll() races make aio_read()/aio_write() return int aio: move dropping ->ki_eventfd into iocb_destroy() deal with get_reqs_available() in aio_get_req() itself aio: move sanity checks and request allocation to io_submit_one() jffs2: fix use-after-free on symlink traversal ubifs: fix use-after-free on symlink traversal debugfs: fix use-after-free on symlink traversal Alan Kao (1): riscv: fix accessing 8-byte variable from RV32 Alex Williamson (1): vfio/type1: Limit DMA mappings per container Alexander Lobakin (1): net: core: netif_receive_skb_list: unlist skb before passing to pt->func Alexandre Belloni (2): rtc: sd3078: fix manufacturer name rtc: da9063: set uie_unsupported when relevant Anders Roxell (1): batman-adv: fix warning in function batadv_v_elp_get_throughput Andi Kleen (1): dm init: fix const confusion for dm_allowed_targets array Andrea Righi (2): openvswitch: fix flow actions reallocation xen: use struct_size() helper in kzalloc() Andreas Kemnade (1): mfd: twl-core: Disable IRQ while suspended Andrew Morton (1): mm/util.c: fix strndup_user() comment Andrii Nakryiko (2): libbpf: fix btf_dedup equivalence check handling of different kinds selftests/bpf: add btf_dedup test for VOID equivalence check Andy Shevchenko (1): HID: quirks: Drop misused kernel-doc annotation Aneesh Kumar K.V (1): mm/huge_memory.c: fix modifying of page protection by insert_pfn_pmd() Anup Patel (2): RISC-V: Always compile mm/init.c with cmodel=medany and notrace RISC-V: Fix FIXMAP_TOP to avoid overlap with VMALLOC area Arnd Bergmann (5): HID: hid-asus: select CONFIG_POWER_SUPPLY include/linux/bitrev.h: fix constant bitrev ARM: orion: don't use using 64-bit DMA masks ARM: iop: don't use using 64-bit DMA masks ARM: milbeaut: fix build with !CONFIG_HOTPLUG_CPU Artemy Kovalyov (1): net/mlx5: Decrease default mr cache size Arvind Sankar (1): igb: Fix WARN_ONCE on runtime suspend Axel Lin (2): reset: meson-audio-arb: Fix missing .owner setting of reset_controller_dev hwmon: (w83773g) Select REGMAP_I2C to fix build error Aya Levin (2): net/mlx5: ethtool, Fix type analysis of advertised link-mode net/mlx5: ethtool, Allow legacy link-modes configuration via non-extended ptys Baolin Wang (1): mfd: sc27xx: Use SoC compatible string for PMIC devices Bart Van Assche (1): block: Revert v5.0 blk_mq_request_issue_directly() changes Ben Hutchings (1): tools/power turbostat: Add checks for failure of fgets() and fscanf() Bert Kenward (1): MAINTAINERS: net: update Solarflare maintainers Björn Töpel (4): libbpf: add xsk.h to install_headers target libbpf: add libelf dependency to shared library build i40e: move i40e_xsk_umem function i40e: add tracking of AF_XDP ZC state for each queue pair Bjørn Mork (1): qmi_wwan: add Olicard 600 Borislav Petkov (1): cpufreq/intel_pstate: Load only on Intel hardware Calvin Walton (2): tools/power turbostat: Add support for AMD Fam 17h (Zen) RAPL tools/power turbostat: Also read package power on AMD F17h (Zen) Carlos Menin (1): dt-bindings: hwmon: (adc128d818) Specify ti,mode property size Catalin Marinas (1): kmemleak: powerpc: skip scanning holes in the .bss section Chengming Gui (1): drm/amd/amdgpu: fix PCIe dpm feature issue (v3) Chris Leech (1): vlan: conditional inclusion of FCoE hooks to match netdevice.h and bnx2x Chris Wilson (2): drm/i915: Always backoff after a drm_modeset_lock() deadlock drm/i915/gvt: Fix kerneldoc typo for intel_vgpu_emulate_hotplug Claudiu Manoil (1): net: mii: Fix PAUSE cap advertisement from linkmode_adv_to_lcl_adv_t() helper Colin Ian
Re: [PATCH] arm64: ptrace: Add function argument access API
Hi Will,
On Wed, 3 Apr 2019 13:06:49 +0100
Will Deacon wrote:
> On Mon, Mar 18, 2019 at 04:59:02PM +0900, Masami Hiramatsu wrote:
> > Add regs_get_argument() which returns N th argument of the function
> > call. On arm64, it supports up to 8th argument.
> > Note that this chooses most probably assignment, in some case
> > it can be incorrect (e.g. passing data structure or floating
> > point etc.)
> >
> > This enables ftrace kprobe events to access kernel function
> > arguments via $argN syntax.
> >
> > Signed-off-by: Masami Hiramatsu
> > ---
> > arch/arm64/Kconfig |1 +
> > arch/arm64/include/asm/ptrace.h | 18 ++
> > 2 files changed, 19 insertions(+)
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 117b2541ef3d..6ba0da4be73c 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -148,6 +148,7 @@ config ARM64
> > select HAVE_PERF_REGS
> > select HAVE_PERF_USER_STACK_DUMP
> > select HAVE_REGS_AND_STACK_ACCESS_API
> > + select HAVE_FUNCTION_ARG_ACCESS_API
> > select HAVE_RCU_TABLE_FREE
> > select HAVE_RCU_TABLE_INVALIDATE
> > select HAVE_RSEQ
> > diff --git a/arch/arm64/include/asm/ptrace.h
> > b/arch/arm64/include/asm/ptrace.h
> > index ec60174c8c18..cfa1bc9b8b70 100644
> > --- a/arch/arm64/include/asm/ptrace.h
> > +++ b/arch/arm64/include/asm/ptrace.h
> > @@ -305,6 +305,24 @@ static inline unsigned long regs_return_value(struct
> > pt_regs *regs)
> > return regs->regs[0];
> > }
> >
> > +/**
> > + * regs_get_kernel_argument() - get Nth function argument in kernel
> > + * @regs: pt_regs of that context
> > + * @n: function argument number (start from 0)
> > + *
> > + * regs_get_argument() returns @n th argument of the function call.
> > + * Note that this chooses most probably assignment, in some case
> > + * it can be incorrect.
>
> In which cases would it be incorrect? I can imagine varargs causing
> problems, but are there others?
As far as I can read "Procedure Call Standard for the ARM 64-bit
Architecture(AArch64) 5.4.2 Parameter Passing Rules", it may not return
correct data if the target function has a parameter which is 16bytes
or bigger size. Of course that is just a limitation of this interface.
But anyway, it can return wrong data for the parameter after such big
parameters. I think, for func(data-struct-128bits p1, u64 p2), p1
is stored into r0 and r1, and p2 is stored r2, is that correct?
(Of course any SIMD/float parameter passed to the function, it also can
not correctly get, but in the kernel we can ignore it.)
> > +static inline unsigned long regs_get_kernel_argument(struct pt_regs *regs,
> > +unsigned int n)
> > +{
> > +#define NR_REG_ARGUMENTS 8
> > + if (n < NR_REG_ARGUMENTS)
> > + return regs_get_register(regs, n << 3);
>
> You can use pt_regs_read_reg() to avoid the shift here.
Ah, right!
Thank you,
--
Masami Hiramatsu
Dear Friend (Assalamu Alaikum),
-- Dear Friend (Assalamu Alaikum), I came across your e-mail contact prior a private search while in need of your assistance. My name is Aisha Al-Qaddafi a single Mother and a Widow with three Children. I am the only biological Daughter of late Libyan President (Late Colonel Muammar Gaddafi). I have investment funds worth Twenty Seven Million Five Hundred Thousand United State Dollar ($27.500.000.00 ) and i need a trusted investment Manager/Partner because of my current refugee status, however, I am interested in you for investment project assistance in your country, may be from there, we can build business relationship in the nearest future. I am willing to negotiate investment/business profit sharing ratio with you base on the future investment earning profits. If you are willing to handle this project on my behalf kindly reply urgent to enable me provide you more information about the investment funds. Your Urgent Reply Will Be Appreciated. write me at this email address( ayishagdda...@mail.com ) for further discussion. Best Regards Mrs Aisha Al-Qaddafi Reply to: ayishagdda...@mail.com
Re: [PATCH 1/3] fs: stream_open - opener for stream-like files so that read and write can run simultaneously without deadlock
On Sun, Apr 7, 2019 at 10:04 AM Kirill Smelkov wrote: > > Fixing regression on FUSE side is my reason to do this whole work - > that's why I care about it the most and ask. Yeah, we can do the actual FUSE fix, I think. Preferably through the FUSE tree. Miklos? Linus
Re: [GIT PULL] ARM: SoC fixes
The pull request you sent on Sun, 7 Apr 2019 15:50:20 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/armsoc-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/d8491223bc243b960ee1c4a8aa5219eca0d69acf Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [RFC][PATCH 0/3] tracing: Make error_log per instance
Hi Steve, Sorry for replying late. On Tue, 02 Apr 2019 14:29:51 -0400 Steven Rostedt wrote: > Hi Tom, > > I noticed that you created an error_log file in every instance, but > they all show the same errors. These three patches make it so that > the errors appear in the instance directory that they happened in. > If you write a bad error to > >/sys/kernel/tracing/instance/foo/events/sched/sched_switch/hist > > It appears only in > > /sys/kernel/tracing/instances/foo/error_log > > Which I think is the proper approach, especially instances should not > affect the top directory or other instances. Agreed, leaking the probe-event error on instance will not be good. > > For those errors that do not have an associated instance (creating a > kprobe/uprobe event or perf), a NULL passed to tracing_log_err() will > result in the error message in the top level error message. > > Do you (or Masami) have any issues with this patch set? > > If not, please add a "reviewed-by" or "acked-by" and I'll add it > to your patch series and push them to for-next (after more testing). This looks good to me. Reviewed-by: Masami Hiramatsu Thank you! > > If this isn't obvious, this patch series is on top of: > > http://lkml.kernel.org/r/cover.1554072478.git.tom.zanu...@linux.intel.com > > Actually, I added it right after patch 5 of that series (before the > selftests and documentation). > > Thanks! > > -- Steve > > > > Steven Rostedt (VMware) (3): > tracing: Add trace_array parameter to create_event_filter() > tracing: Have histogram code pass around trace_array for error handling > tracing: Have the error logs show up in the proper instances > > > kernel/trace/trace.c| 55 +- > kernel/trace/trace.h| 8 +- > kernel/trace/trace_events_filter.c | 25 --- > kernel/trace/trace_events_hist.c| 145 > > kernel/trace/trace_events_trigger.c | 3 +- > kernel/trace/trace_probe.c | 2 +- > 6 files changed, 142 insertions(+), 96 deletions(-) -- Masami Hiramatsu
[PATCH v2] Input: i8042 - disable KBD port on Razer Blade Stealth V2 (2017 model)
The late 2017 model of the Razer Blade Stealth has a built-in USB
keyboard, but for some reason the BIOS exposes an i8042 controller with
a connected KBD port. While this fake AT Keyboard device doesn't appear
to report any events, attempting to change the state of the caps lock
LED on it from on to off causes the entire system to hang.
So, introduce a quirk table for disabling keyboard probing by default,
i8042_dmi_nokbd_table, and add this specific model of Razer laptop to
that table.
Changes since v1:
- Correct model (should be V2, 2017)
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
drivers/input/serio/i8042-x86ia64io.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/input/serio/i8042-x86ia64io.h
b/drivers/input/serio/i8042-x86ia64io.h
index 136f6e7bf797..f65570691980 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -884,6 +884,22 @@ static const struct dmi_system_id __initconst
i8042_dmi_kbdreset_table[] = {
{ }
};
+static const struct dmi_system_id i8042_dmi_nokbd_table[] __initconst = {
+ {
+ /*
+* Razer Blade Stealth V2 (2017 model) - Keyboard is on USB
+* but the system exposes a fake AT keyboard that crashes the
+* system if the caps lock LED is changed
+*/
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Razer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Blade Stealth"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "2.04"),
+ },
+ },
+ { }
+};
+
#endif /* CONFIG_X86 */
#ifdef CONFIG_PNP
@@ -1040,6 +1056,9 @@ static int __init i8042_pnp_init(void)
#ifdef CONFIG_X86
if (dmi_check_system(i8042_dmi_nopnp_table))
i8042_nopnp = true;
+
+ if (dmi_check_system(i8042_dmi_nokbd_table))
+ i8042_nokbd = true;
#endif
if (i8042_nopnp) {
--
2.20.1
Re: [PATCH 03/16] staging: m57621-mmc: delete driver from the tree.
On Wed, Apr 03 2019, George Hilliard wrote:
> On Tue, Apr 2, 2019 at 3:45 PM Christian Lütke-Stetzkamp
> wrote:
>> There are two other larger differences that I found during my
>> work. One is that drivers/mmc/host/mtk-sd.c has much more features,
>> like voltage and clock handling and some support for high speed
>> modes. I don't know if these features are required/useful for this
>> device.
>
> For what it's worth, I found an old forum post of someone who was
> dealing with a crashy kernel on their mt7688. They removed the
> mt7621-mmc driver and hacked the clock code out of the mainline
> driver. Apparently it worked. I never got around to duplicating
> their work, however. (I too ran into severe instability problems with
> the mt7621-mmc driver, but they only appeared in conjunction with
> using the SLOB allocator. I could never debug it because when JTAG
> was turned on, the SDMC peripheral was disabled for some reason I
> never discovered. More info on that if someone is interested.)
>
> The correct way to do this would be to have a "compatible" flag that
> bypassed the clock handling code. I don't think there are any
> relevant clocks to set up on the MT7628/MT7688 - the MSDC peripheral
> does not appear in the clock plan.
>
>> The other thing is the card detect handling. This driver is
>> doing the card detect / read only detection on its own, where the in
>> tree one just uses some default gpio functions there and I don't know
>> weather this must be changed or weather there is a gpio driver for the
>> mt7621.
>
> There is a "mtk,mt7621-gpio"-compatible GPIO driver available.
> Probably it would work with GPIO on new hardware that did not to route
> CD to the CD pin, because the CD pin is muxed using the same "SD card"
> pin state as the SD data pins. I do not know if it is possible for
> the GPIO peripheral to read the pin while it is muxed to the SD
> controller, as would be necessary for existing hardware.
>
> George
FYI I have mmc working on my mt7621 board using the
drivers/mmc/host/mtk_sd.c driver and the following patch.
I haven't looked at the card-detect yet.
I'll post bits of this to relevant lists as they are ready, not to this
list any more. If anyone would like to hear about my progress, please
let me know.
Thanks,
NeilBrown
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 833ef0590af8..45ae93114a07 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -366,6 +366,8 @@ struct mtk_mmc_compatible {
u8 clk_div_bits;
bool hs400_tune; /* only used for MT8173 */
u32 pad_tune_reg;
+ u32 caps;
+ u32 ocr_avail;
bool async_fifo;
bool data_tune;
bool busy_check;
@@ -507,6 +509,21 @@ static const struct mtk_mmc_compatible mt7622_compat = {
.support_64g = false,
};
+static const struct mtk_mmc_compatible mt7620_compat = {
+ .clk_div_bits = 8,
+ .hs400_tune = false,
+ .pad_tune_reg = MSDC_PAD_TUNE,
+ .async_fifo = false,
+ .data_tune = false,
+ .busy_check = false,
+ .stop_clk_fix = false,
+ .enhance_rx = false,
+ .caps = (MMC_CAP_4_BIT_DATA | MMC_CAP_MMC_HIGHSPEED |
+MMC_CAP_SD_HIGHSPEED),
+ .ocr_avail = (MMC_VDD_28_29 | MMC_VDD_29_30 | MMC_VDD_30_31 |
+ MMC_VDD_31_32 | MMC_VDD_32_33),
+};
+
static const struct of_device_id msdc_of_ids[] = {
{ .compatible = "mediatek,mt8135-mmc", .data = _compat},
{ .compatible = "mediatek,mt8173-mmc", .data = _compat},
@@ -514,6 +531,7 @@ static const struct of_device_id msdc_of_ids[] = {
{ .compatible = "mediatek,mt2701-mmc", .data = _compat},
{ .compatible = "mediatek,mt2712-mmc", .data = _compat},
{ .compatible = "mediatek,mt7622-mmc", .data = _compat},
+ { .compatible = "ralink,mt7620-sdhci", .data = _compat},
{}
};
MODULE_DEVICE_TABLE(of, msdc_of_ids);
@@ -2194,13 +2212,17 @@ static int msdc_drv_probe(struct platform_device *pdev)
if (mmc->caps & MMC_CAP_SDIO_IRQ)
mmc->caps2 |= MMC_CAP2_SDIO_IRQ_NOTHREAD;
- mmc->caps |= MMC_CAP_ERASE | MMC_CAP_CMD23;
+ mmc->caps |= MMC_CAP_ERASE | MMC_CAP_CMD23 |
+ host->dev_comp->caps;
+ mmc->f_max = host->src_clk_freq;
/* MMC core transfer sizes tunable parameters */
mmc->max_segs = MAX_BD_NUM;
mmc->max_seg_size = BDMA_DESC_BUFLEN;
mmc->max_blk_size = 2048;
mmc->max_req_size = 512 * 1024;
mmc->max_blk_count = mmc->max_req_size / 512;
+ mmc->ocr_avail |= host->dev_comp->ocr_avail;
+
if (host->dev_comp->support_64g)
host->dma_mask = DMA_BIT_MASK(36);
else
@@ -2226,8 +2248,13 @@ static int msdc_drv_probe(struct platform_device *pdev)
msdc_ungate_clock(host);
msdc_init_hw(host);
- ret = devm_request_irq(>dev, host->irq, msdc_irq,
- IRQF_TRIGGER_LOW | IRQF_ONESHOT,
[PATCH 3/5] x86/MCE/AMD: Don't cache block addresses on SMCA systems
From: Yazen Ghannam
On legacy systems, the addresses of the MCA_MISC* registers need to be
recursively discovered based on a Block Pointer field in the registers.
On Scalable MCA systems, the register space is fixed, and particular
addresses can be derived by regular offsets for bank and register type.
This fixed address space includes the MCA_MISC* registers.
MCA_MISC0 is always available for each MCA bank. MCA_MISC1 through
MCA_MISC4 are considered available if MCA_MISC0[BlkPtr]=1.
Cache the value of MCA_MISC0[BlkPtr] for each bank and per CPU. This
needs to be done only during init. The values should be saved per CPU
to accommodate heterogeneous SMCA systems.
Redo smca_get_block_address() to directly return the block addresses.
Use the cached Block Pointer value to decide if the MCA_MISC1-4
addresses should be returned.
Signed-off-by: Yazen Ghannam
---
arch/x86/kernel/cpu/mce/amd.c | 71 +--
1 file changed, 35 insertions(+), 36 deletions(-)
diff --git a/arch/x86/kernel/cpu/mce/amd.c b/arch/x86/kernel/cpu/mce/amd.c
index e64de5149e50..f0644b59848d 100644
--- a/arch/x86/kernel/cpu/mce/amd.c
+++ b/arch/x86/kernel/cpu/mce/amd.c
@@ -101,11 +101,6 @@ static struct smca_bank_name smca_names[] = {
[SMCA_PCIE] = { "pcie", "PCI Express Unit" },
};
-static u32 smca_bank_addrs[MAX_NR_BANKS][NR_BLOCKS] __ro_after_init =
-{
- [0 ... MAX_NR_BANKS - 1] = { [0 ... NR_BLOCKS - 1] = -1 }
-};
-
static const char *smca_get_name(enum smca_bank_types t)
{
if (t >= N_SMCA_BANK_TYPES)
@@ -198,6 +193,7 @@ static char buf_mcatype[MAX_MCATYPE_NAME_LEN];
static DEFINE_PER_CPU(struct threshold_bank **, threshold_banks);
static DEFINE_PER_CPU(unsigned int, bank_map); /* see which banks are on */
+static DEFINE_PER_CPU(u32, smca_blkptr_map); /* see which banks use BlkPtr */
static void amd_threshold_interrupt(void);
static void amd_deferred_error_interrupt(void);
@@ -208,6 +204,28 @@ static void default_deferred_error_interrupt(void)
}
void (*deferred_error_int_vector)(void) = default_deferred_error_interrupt;
+static void smca_set_blkptr_map(unsigned int bank, unsigned int cpu)
+{
+ u32 low, high;
+
+ /*
+* For SMCA enabled processors, BLKPTR field of the first MISC register
+* (MCx_MISC0) indicates presence of additional MISC regs set (MISC1-4).
+*/
+ if (rdmsr_safe(MSR_AMD64_SMCA_MCx_CONFIG(bank), , ))
+ return;
+
+ if (!(low & MCI_CONFIG_MCAX))
+ return;
+
+ if (rdmsr_safe(MSR_AMD64_SMCA_MCx_MISC(bank), , ))
+ return;
+
+ if (low & MASK_BLKPTR_LO)
+ per_cpu(smca_blkptr_map, cpu) |= 1 << bank;
+
+}
+
static void smca_configure(unsigned int bank, unsigned int cpu)
{
unsigned int i, hwid_mcatype;
@@ -245,6 +263,8 @@ static void smca_configure(unsigned int bank, unsigned int
cpu)
wrmsr(smca_config, low, high);
}
+ smca_set_blkptr_map(bank, cpu);
+
/* Return early if this bank was already initialized. */
if (smca_banks[bank].hwid)
return;
@@ -455,42 +475,21 @@ static void deferred_error_interrupt_enable(struct
cpuinfo_x86 *c)
wrmsr(MSR_CU_DEF_ERR, low, high);
}
-static u32 smca_get_block_address(unsigned int bank, unsigned int block)
+static u32 smca_get_block_address(unsigned int bank, unsigned int block,
+ unsigned int cpu)
{
- u32 low, high;
- u32 addr = 0;
-
- if (smca_get_bank_type(bank) == SMCA_RESERVED)
- return addr;
-
if (!block)
return MSR_AMD64_SMCA_MCx_MISC(bank);
- /* Check our cache first: */
- if (smca_bank_addrs[bank][block] != -1)
- return smca_bank_addrs[bank][block];
-
- /*
-* For SMCA enabled processors, BLKPTR field of the first MISC register
-* (MCx_MISC0) indicates presence of additional MISC regs set (MISC1-4).
-*/
- if (rdmsr_safe(MSR_AMD64_SMCA_MCx_CONFIG(bank), , ))
- goto out;
-
- if (!(low & MCI_CONFIG_MCAX))
- goto out;
-
- if (!rdmsr_safe(MSR_AMD64_SMCA_MCx_MISC(bank), , ) &&
- (low & MASK_BLKPTR_LO))
- addr = MSR_AMD64_SMCA_MCx_MISCy(bank, block - 1);
+ if (!(per_cpu(smca_blkptr_map, cpu) & (1 << bank)))
+ return 0;
-out:
- smca_bank_addrs[bank][block] = addr;
- return addr;
+ return MSR_AMD64_SMCA_MCx_MISCy(bank, block - 1);
}
static u32 get_block_address(u32 current_addr, u32 low, u32 high,
-unsigned int bank, unsigned int block)
+unsigned int bank, unsigned int block,
+unsigned int cpu)
{
u32 addr = 0, offset = 0;
@@ -498,7 +497,7 @@ static u32 get_block_address(u32 current_addr, u32 low, u32
high,
return addr;
if (mce_flags.smca)
[PATCH 4/5] x86/MCE: Make number of MCA banks per_cpu
From: Yazen Ghannam
The number of MCA banks is provided per logical CPU. Historically, this
number has been the same across all CPUs, but this is not an
architectural guarantee. Future AMD systems may have MCA bank counts
that vary between logical CPUs in a system.
This issue was partially addressed in
commit ("006c077041dc x86/mce: Handle varying MCA bank counts")
by allocating structures using the maximum number of MCA banks and by
saving the maximum MCA bank count in a system as the global count. This
means that some extra structures are allocated. Also, this means that
CPUs will spend more time in the #MC and other handlers checking extra
MCA banks.
Define the number of MCA banks as a per_cpu variable. Replace all uses
of mca_cfg.banks with this.
Also, use the per_cpu bank count when allocating per_cpu structures.
Print the number of banks per CPU as a debug message for those who may
be interested.
Signed-off-by: Yazen Ghannam
---
arch/x86/kernel/cpu/mce/amd.c | 16 +-
arch/x86/kernel/cpu/mce/core.c | 49 +-
arch/x86/kernel/cpu/mce/inject.c | 7 +
arch/x86/kernel/cpu/mce/internal.h | 2 +-
4 files changed, 38 insertions(+), 36 deletions(-)
diff --git a/arch/x86/kernel/cpu/mce/amd.c b/arch/x86/kernel/cpu/mce/amd.c
index f0644b59848d..acce672efb45 100644
--- a/arch/x86/kernel/cpu/mce/amd.c
+++ b/arch/x86/kernel/cpu/mce/amd.c
@@ -493,7 +493,7 @@ static u32 get_block_address(u32 current_addr, u32 low, u32
high,
{
u32 addr = 0, offset = 0;
- if ((bank >= mca_cfg.banks) || (block >= NR_BLOCKS))
+ if ((bank >= per_cpu(num_banks, cpu)) || (block >= NR_BLOCKS))
return addr;
if (mce_flags.smca)
@@ -605,7 +605,7 @@ void mce_amd_feature_init(struct cpuinfo_x86 *c)
disable_err_thresholding(c);
- for (bank = 0; bank < mca_cfg.banks; ++bank) {
+ for (bank = 0; bank < this_cpu_read(num_banks); ++bank) {
if (mce_flags.smca)
smca_configure(bank, cpu);
@@ -948,7 +948,7 @@ static void amd_deferred_error_interrupt(void)
{
unsigned int bank;
- for (bank = 0; bank < mca_cfg.banks; ++bank)
+ for (bank = 0; bank < this_cpu_read(num_banks); ++bank)
log_error_deferred(bank);
}
@@ -989,7 +989,7 @@ static void amd_threshold_interrupt(void)
struct threshold_block *first_block = NULL, *block = NULL, *tmp = NULL;
unsigned int bank, cpu = smp_processor_id();
- for (bank = 0; bank < mca_cfg.banks; ++bank) {
+ for (bank = 0; bank < this_cpu_read(num_banks); ++bank) {
if (!(per_cpu(bank_map, cpu) & (1 << bank)))
continue;
@@ -1176,7 +1176,7 @@ static int allocate_threshold_blocks(unsigned int cpu,
unsigned int bank,
u32 low, high;
int err;
- if ((bank >= mca_cfg.banks) || (block >= NR_BLOCKS))
+ if ((bank >= per_cpu(num_banks, cpu)) || (block >= NR_BLOCKS))
return 0;
if (rdmsr_safe_on_cpu(cpu, address, , ))
@@ -1410,7 +1410,7 @@ int mce_threshold_remove_device(unsigned int cpu)
{
unsigned int bank;
- for (bank = 0; bank < mca_cfg.banks; ++bank) {
+ for (bank = 0; bank < per_cpu(num_banks, cpu); ++bank) {
if (!(per_cpu(bank_map, cpu) & (1 << bank)))
continue;
threshold_remove_bank(cpu, bank);
@@ -1431,14 +1431,14 @@ int mce_threshold_create_device(unsigned int cpu)
if (bp)
return 0;
- bp = kcalloc(mca_cfg.banks, sizeof(struct threshold_bank *),
+ bp = kcalloc(per_cpu(num_banks, cpu), sizeof(struct threshold_bank *),
GFP_KERNEL);
if (!bp)
return -ENOMEM;
per_cpu(threshold_banks, cpu) = bp;
- for (bank = 0; bank < mca_cfg.banks; ++bank) {
+ for (bank = 0; bank < per_cpu(num_banks, cpu); ++bank) {
if (!(per_cpu(bank_map, cpu) & (1 << bank)))
continue;
err = threshold_create_bank(cpu, bank);
diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index 14583c5c6e12..4a066c1e8ab2 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -64,6 +64,9 @@ static DEFINE_MUTEX(mce_sysfs_mutex);
DEFINE_PER_CPU(unsigned, mce_exception_count);
+DEFINE_PER_CPU_READ_MOSTLY(u8, num_banks);
+EXPORT_PER_CPU_SYMBOL_GPL(num_banks);
+
struct mce_bank {
u64 ctl;/* subevents to enable */
boolinit; /* initialise bank? */
@@ -699,7 +702,7 @@ bool machine_check_poll(enum mcp_flags flags, mce_banks_t
*b)
if (flags & MCP_TIMESTAMP)
m.tsc = rdtsc();
- for (i = 0; i < mca_cfg.banks; i++) {
+ for (i = 0; i < this_cpu_read(num_banks); i++) {
if (!this_cpu_read(mce_banks)[i].ctl || !test_bit(i, *b))
continue;
@@ -801,7 +804,7
[PATCH 0/5] Handle MCA banks in a per_cpu way
From: Yazen Ghannam The focus of this patchset is define and use the MCA bank structures and bank count per logical CPU. With the exception of patch 4, this set applies to systems in production today. Patch 1: Moves the declaration of struct mce_banks[] to the only file it's used. Patch 2: Splits struct mce_bank into a structure for fields common to MCA banks on all CPUs and another structure that can be used per_cpu. Patch 3: Brings full circle the saga of the threshold block addresses on SMCA systems. After taking a step back and reviewing the AMD documentation, I think that this implimentation is the simplest and more robust way to follow the spec. Patch 4: Saves and uses the MCA bank count as a per_cpu variable. This is to support systems that have MCA bank counts that are different between logical CPUs. Patch 5: Makes sure that sysfs reports the MCA_CTL value as set in hardware. This is not something related to making things per_cpu but rather just something I noticed while working on the other patches. Thanks, Yazen Yazen Ghannam (5): x86/MCE: Make struct mce_banks[] static x86/MCE: Handle MCA controls in a per_cpu way x86/MCE/AMD: Don't cache block addresses on SMCA systems x86/MCE: Make number of MCA banks per_cpu x86/MCE: Save MCA control bits that get set in hardware arch/x86/kernel/cpu/mce/amd.c | 87 +- arch/x86/kernel/cpu/mce/core.c | 138 +++-- arch/x86/kernel/cpu/mce/inject.c | 7 +- arch/x86/kernel/cpu/mce/internal.h | 12 +-- 4 files changed, 137 insertions(+), 107 deletions(-) -- 2.17.1
[PATCH 5/5] x86/MCE: Save MCA control bits that get set in hardware
From: Yazen Ghannam
The OS is expected to write all bits in MCA_CTL. However, only
implemented bits get set in the hardware.
Read back MCA_CTL so that the value in the hardware is saved and
reported through sysfs.
Signed-off-by: Yazen Ghannam
---
arch/x86/kernel/cpu/mce/core.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index 4a066c1e8ab2..ed5374ab3ac3 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -1566,10 +1566,13 @@ static void __mcheck_cpu_init_clear_banks(void)
for (i = 0; i < this_cpu_read(num_banks); i++) {
struct mce_bank *b = _cpu_read(mce_banks)[i];
- if (!b->init)
- continue;
- wrmsrl(msr_ops.ctl(i), b->ctl);
- wrmsrl(msr_ops.status(i), 0);
+ if (b->init) {
+ wrmsrl(msr_ops.ctl(i), b->ctl);
+ wrmsrl(msr_ops.status(i), 0);
+ }
+
+ /* Save bits set in hardware. */
+ rdmsrl(msr_ops.ctl(i), b->ctl);
}
}
@@ -2313,8 +2316,10 @@ static void mce_reenable_cpu(void)
for (i = 0; i < this_cpu_read(num_banks); i++) {
struct mce_bank *b = _cpu_read(mce_banks)[i];
- if (b->init)
+ if (b->init) {
wrmsrl(msr_ops.ctl(i), b->ctl);
+ rdmsrl(msr_ops.ctl(i), b->ctl);
+ }
}
}
--
2.17.1
[PATCH 2/5] x86/MCE: Handle MCA controls in a per_cpu way
From: Yazen Ghannam
Current AMD systems have unique MCA banks per logical CPU even though
the type of the banks may all align to the same bank number. Each CPU
will have control of a set of MCA banks in the hardware and these are
not shared with other CPUs.
For example, bank 0 may be the Load-Store Unit on every logical CPU, but
each bank 0 is a unique structure in the hardware. In other words, there
isn't a *single* Load-Store Unit at MCA bank 0 that all logical CPUs
share.
This idea extends even to non-core MCA banks. For example, CPU0 and CPU4
may see a Unified Memory Controller at bank 15, but each CPU is actually
seeing a unique hardware structure that is not shared with other CPUs.
Because the MCA banks are all unique hardware structures, it would be
good to control them in a more granular way. For example, if there is a
known issue with the Floating Point Unit on CPU5 and a user wishes to
disable an error type on the Floating Point Unit, then it would be good
to do this only for CPU5 rather than all CPUs.
Also, future AMD systems may have heterogeneous MCA banks. Meaning the
bank numbers may not necessarily represent the same types between CPUs.
For example, bank 20 visible to CPU0 may be a Unified Memory Controller
and bank 20 visible to CPU4 may be a Coherent Slave. So granular control
will be even more necessary should the user wish to control specific MCA
banks.
Split the device attributes from struct mce_bank leaving only the MCA
bank control fields.
Make struct mce_banks[] per_cpu in order to have more granular control
over individual MCA banks in the hardware.
Allocate the device attributes statically based on the maximum number of
MCA banks supported. The sysfs interface will use as many as needed per
CPU. Currently, this is set to mca_cfg.banks, but will be changed to a
per_cpu bank count in a future patch.
Allocate the MCA control bits dynamically. Use the maximum number of MCA
banks supported for now. This will be changed to a per_cpu bank count in
a future patch.
Redo the sysfs store/show functions to handle the per_cpu mce_banks[].
Signed-off-by: Yazen Ghannam
---
arch/x86/kernel/cpu/mce/core.c | 77 ++
1 file changed, 51 insertions(+), 26 deletions(-)
diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index 8d0d1e8425db..14583c5c6e12 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -64,16 +64,21 @@ static DEFINE_MUTEX(mce_sysfs_mutex);
DEFINE_PER_CPU(unsigned, mce_exception_count);
+struct mce_bank {
+ u64 ctl;/* subevents to enable */
+ boolinit; /* initialise bank? */
+};
+static DEFINE_PER_CPU_READ_MOSTLY(struct mce_bank*, mce_banks);
+
#define ATTR_LEN 16
/* One object for each MCE bank, shared by all CPUs */
-struct mce_bank {
- u64 ctl;/* subevents to enable
*/
- boolinit; /* initialise bank? */
+struct mce_bank_dev {
struct device_attribute attr; /* device attribute */
charattrname[ATTR_LEN]; /* attribute name */
+ u8 bank; /* bank number */
};
+static struct mce_bank_dev mce_bank_devs[MAX_NR_BANKS];
-static struct mce_bank *mce_banks __read_mostly;
struct mce_vendor_flags mce_flags __read_mostly;
struct mca_config mca_cfg __read_mostly = {
@@ -695,7 +700,7 @@ bool machine_check_poll(enum mcp_flags flags, mce_banks_t
*b)
m.tsc = rdtsc();
for (i = 0; i < mca_cfg.banks; i++) {
- if (!mce_banks[i].ctl || !test_bit(i, *b))
+ if (!this_cpu_read(mce_banks)[i].ctl || !test_bit(i, *b))
continue;
m.misc = 0;
@@ -1138,7 +1143,7 @@ static void __mc_scan_banks(struct mce *m, struct mce
*final,
if (!test_bit(i, valid_banks))
continue;
- if (!mce_banks[i].ctl)
+ if (!this_cpu_read(mce_banks)[i].ctl)
continue;
m->misc = 0;
@@ -1475,16 +1480,19 @@ static int __mcheck_cpu_mce_banks_init(void)
{
int i;
- mce_banks = kcalloc(MAX_NR_BANKS, sizeof(struct mce_bank), GFP_KERNEL);
- if (!mce_banks)
+ per_cpu(mce_banks, smp_processor_id()) =
+ kcalloc(MAX_NR_BANKS, sizeof(struct mce_bank), GFP_KERNEL);
+
+ if (!this_cpu_read(mce_banks))
return -ENOMEM;
for (i = 0; i < MAX_NR_BANKS; i++) {
- struct mce_bank *b = _banks[i];
+ struct mce_bank *b = _cpu_read(mce_banks)[i];
b->ctl = -1ULL;
b->init = 1;
}
+
return 0;
}
@@ -1504,7 +1512,7 @@ static int __mcheck_cpu_cap_init(void)
mca_cfg.banks = max(mca_cfg.banks, b);
- if (!mce_banks) {
+ if (!this_cpu_read(mce_banks)) {
[PATCH 1/5] x86/MCE: Make struct mce_banks[] static
From: Yazen Ghannam
The struct mce_banks[] array is only used in mce/core.c so move the
definition of struct mce_bank to mce/core.c and make the array static.
Also, change the "init" field to bool type.
Signed-off-by: Yazen Ghannam
---
arch/x86/kernel/cpu/mce/core.c | 11 ++-
arch/x86/kernel/cpu/mce/internal.h | 10 --
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index 58925e7ccb27..8d0d1e8425db 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -64,7 +64,16 @@ static DEFINE_MUTEX(mce_sysfs_mutex);
DEFINE_PER_CPU(unsigned, mce_exception_count);
-struct mce_bank *mce_banks __read_mostly;
+#define ATTR_LEN 16
+/* One object for each MCE bank, shared by all CPUs */
+struct mce_bank {
+ u64 ctl;/* subevents to enable
*/
+ boolinit; /* initialise bank? */
+ struct device_attribute attr; /* device attribute */
+ charattrname[ATTR_LEN]; /* attribute name */
+};
+
+static struct mce_bank *mce_banks __read_mostly;
struct mce_vendor_flags mce_flags __read_mostly;
struct mca_config mca_cfg __read_mostly = {
diff --git a/arch/x86/kernel/cpu/mce/internal.h
b/arch/x86/kernel/cpu/mce/internal.h
index af5eab1e65e2..032d52c66616 100644
--- a/arch/x86/kernel/cpu/mce/internal.h
+++ b/arch/x86/kernel/cpu/mce/internal.h
@@ -22,17 +22,8 @@ enum severity_level {
extern struct blocking_notifier_head x86_mce_decoder_chain;
-#define ATTR_LEN 16
#define INITIAL_CHECK_INTERVAL 5 * 60 /* 5 minutes */
-/* One object for each MCE bank, shared by all CPUs */
-struct mce_bank {
- u64 ctl;/* subevents to enable
*/
- unsigned char init; /* initialise bank? */
- struct device_attribute attr; /* device attribute */
- charattrname[ATTR_LEN]; /* attribute name */
-};
-
struct mce_evt_llist {
struct llist_node llnode;
struct mce mce;
@@ -47,7 +38,6 @@ struct llist_node *mce_gen_pool_prepare_records(void);
extern int (*mce_severity)(struct mce *a, int tolerant, char **msg, bool
is_excp);
struct dentry *mce_get_debugfs_dir(void);
-extern struct mce_bank *mce_banks;
extern mce_banks_t mce_banks_ce_disabled;
#ifdef CONFIG_X86_MCE_INTEL
--
2.17.1
Re: [GIT PULL] ARM: SoC fixes
On Sun, Apr 7, 2019 at 3:50 PM Olof Johansson wrote: > > Hi Linus, > > The following changes since commit 79a3aaa7b82e3106be97842dedfd8429248896e6: > > Linux 5.1-rc3 (2019-03-31 14:39:29 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/armsoc-fixes > > for you to fetch changes up to 9a8f32038a74cb800e9649afbf4b3dba2b7d6539: > > ARM: milbeaut: fix build with !CONFIG_HOTPLUG_CPU (2019-04-07 15:29:55 > -0700) > > > ARM: SoC fixes > > A collection of fixes from the last few weeks. Most of them are smaller > tweaks and fixes to DT and hardware descriptions for boards. Some of the > more significant ones are: > > - eMMC and RGMII stability tweaks for rk3288 > - DDC fixes for Rock PI 4 > - Audio fixes for two TI am335x eval boards > - D_CAN clock fix for am335x > - Compilation fixes for clang > - !SMP compilation fix for one of the new platforms this release (milbeaut) Whoops: CONFIG_HOTPLUG_CPU=n, not CONFIG_SMP=n. -Olof > - A revert of a gpio fix for nomadik that instead was fixed in the gpio >subsystem > - Whitespace fix for the DT JSON schema (no tabs allowed) > > > Arnd Bergmann (3): > ARM: orion: don't use using 64-bit DMA masks > ARM: iop: don't use using 64-bit DMA masks > ARM: milbeaut: fix build with !CONFIG_HOTPLUG_CPU > > Axel Lin (1): > reset: meson-audio-arb: Fix missing .owner setting of > reset_controller_dev > > David Engraf (1): > ARM: dts: at91: Fix typo in ISC_D0 on PC9 > > David Summers (1): > ARM: dts: rockchip: Fix SD card detection on rk3288-tinker > > Dinh Nguyen (1): > arm64: dts: stratix10: add the sysmgr-syscon property from the gmac's > > Douglas Anderson (3): > ARM: dts: rockchip: Fix gpu opp node names for rk3288 > ARM: dts: rockchip: Remove #address/#size-cells from rk3288 mipi_dsi > ARM: dts: rockchip: Remove #address/#size-cells from rk3288-veyron > gpio-keys > > Ezequiel Garcia (1): > arm64: dts: rockchip: add DDC bus on Rock Pi 4 > > Janusz Krzysztofik (1): > ARM: OMAP1: ams-delta: Fix broken GPIO ID allocation > > Jonas Karlman (1): > ARM: dts: rockchip: fix rk3288 cpu opp node reference > > Julia Lawall (1): > ARM: OMAP2+: add missing of_node_put after of_device_is_available > > Leonidas P. Papadakos (1): > arm64: dts: rockchip: fix rk3328-roc-cc gmac2io tx/rx_delay > > Maxime Ripard (1): > dt-bindings: cpu: Fix JSON schema > > Neil Armstrong (1): > dt-bindings: reset: meson-g12a: Add missing USB2 PHY resets > > Olof Johansson (6): > Merge tag 'reset-fixes-for-v5.1' of git://git.pengutronix.de/pza/linux > into arm/fixes > Merge tag 'stratix10_fix_for_v5.1' of > git://git.kernel.org/.../dinguyen/linux into arm/fixes > Merge tag 'v5.1-rockchip-dtfixes-1' of > git://git.kernel.org/.../mmind/linux-rockchip into arm/fixes > Merge tag 'at91-5.1-fixes' of git://git.kernel.org/.../at91/linux into > arm/fixes > Merge tag 'omap-for-v5.1/fixes-signed' of > git://git.kernel.org/.../tmlind/linux-omap into arm/fixes > Revert "ARM: dts: nomadik: Fix polarity of SPI CS" > > Peng Hao (1): > arm/mach-at91/pm : fix possible object reference leak > > Peter Geis (2): > arm64: dts: rockchip: fix rk3328 rgmii high tx error rate > arm64: dts: rockchip: fix rk3328 sdmmc0 write errors > > Peter Ujfalusi (2): > ARM: dts: am335x-evm: Correct the regulators for the audio codec > ARM: dts: am335x-evmsk: Correct the regulators for the audio codec > > Tomohiro Mayama (1): > arm64: dts: rockchip: Fix vcc_host1_5v GPIO polarity on rk3328-rock64 > > Tony Lindgren (2): > ARM: dts: Fix dcan clkctrl clock for am3 > Merge commit '7d56bedb2730dc2ea8abf0fd7240ee99ecfee3c9' into > omap-for-v5.1/fixes > > Documentation/devicetree/bindings/arm/cpus.yaml| 2 +- > arch/arm/boot/dts/am335x-evm.dts | 26 -- > arch/arm/boot/dts/am335x-evmsk.dts | 26 -- > arch/arm/boot/dts/am33xx-l4.dtsi | 4 +- > arch/arm/boot/dts/rk3288-tinker.dtsi | 3 +- > arch/arm/boot/dts/rk3288-veyron.dtsi | 2 - > arch/arm/boot/dts/rk3288.dtsi | 20 > arch/arm/boot/dts/sama5d2-pinfunc.h| 2 +- > arch/arm/boot/dts/ste-nomadik-nhk15.dts| 9 ++-- > arch/arm/mach-at91/pm.c| 6 ++- > arch/arm/mach-iop13xx/setup.c | 8 +-- > arch/arm/mach-iop13xx/tpmi.c | 10 ++-- > arch/arm/mach-milbeaut/platsmp.c | 4 ++ > arch/arm/mach-omap1/board-ams-delta.c | 2 + > arch/arm/mach-omap2/display.c | 4 +- > arch/arm/plat-iop/adma.c | 6 +-- >
Re: [PATCH] Input: i8042 - disable KBD port on Late-2016 Razer Blade Stealth
On Sun, 2019-04-07 at 15:10 -0700, Dmitry Torokhov wrote: > Hi Lyude, > > On Sun, Apr 07, 2019 at 05:37:34PM -0400, Lyude Paul wrote: > > The late 2016 model of the Razer Blade Stealth has a built-in USB > > keyboard, but for some reason the BIOS exposes an i8042 controller with > > a connected KBD port. While this fake AT Keyboard device doesn't appear > > to report any events, attempting to change the state of the caps lock > > LED on it from on to off causes the entire system to hang. > > > > So, introduce a quirk table for disabling keyboard probing by default, > > i8042_dmi_nokbd_table, and add this specific model of Razer laptop to > > that table. > > What does dmesg show about i8042 for this device? Especially line "PNP: > PS/2 Controller ..."? > Apr 07 18:42:46 malachite kernel: i8042: PNP: No PS/2 controller found. Apr 07 18:42:46 malachite kernel: i8042: Probing ports directly. Apr 07 18:42:46 malachite kernel: serio: i8042 KBD port at 0x60,0x64 irq 1 Apr 07 18:42:46 malachite kernel: serio: i8042 AUX port at 0x60,0x64 irq 12 Apr 07 18:42:46 malachite kernel: mousedev: PS/2 mouse device common for all mice Apr 07 18:42:46 malachite kernel: rtc_cmos 00:01: RTC can wake from S4 Apr 07 18:42:46 malachite kernel: rtc_cmos 00:01: registered as rtc0 Apr 07 18:42:46 malachite kernel: rtc_cmos 00:01: alarms up to one month, y3k, 242 bytes nvram, hpet irqs Apr 07 18:42:46 malachite kernel: device-mapper: uevent: version 1.0.3 Apr 07 18:42:46 malachite kernel: device-mapper: ioctl: 4.39.0-ioctl (2018-04- 03) initialised: dm-de...@redhat.com Apr 07 18:42:46 malachite kernel: intel_pstate: Intel P-state driver initializing Apr 07 18:42:46 malachite kernel: intel_pstate: HWP enabled Apr 07 18:42:46 malachite kernel: hidraw: raw HID events driver (C) Jiri Kosina Apr 07 18:42:46 malachite kernel: usbcore: registered new interface driver usbhid Apr 07 18:42:46 malachite kernel: usbhid: USB HID core driver Apr 07 18:42:46 malachite kernel: intel_pmc_core: initialized Apr 07 18:42:46 malachite kernel: drop_monitor: Initializing network drop monitor service Apr 07 18:42:46 malachite kernel: Initializing XFRM netlink socket Apr 07 18:42:46 malachite kernel: NET: Registered protocol family 10 Apr 07 18:42:46 malachite kernel: Segment Routing with IPv6 Apr 07 18:42:46 malachite kernel: mip6: Mobile IPv6 Apr 07 18:42:46 malachite kernel: NET: Registered protocol family 17 Apr 07 18:42:46 malachite kernel: RAS: Correctable Errors collector initialized. Apr 07 18:42:46 malachite kernel: microcode: sig=0x806e9, pf=0x80, revision=0x8e Apr 07 18:42:46 malachite kernel: microcode: Microcode Update Driver: v2.2. Apr 07 18:42:46 malachite kernel: AVX2 version of gcm_enc/dec engaged. Apr 07 18:42:46 malachite kernel: AES CTR mode by8 optimization enabled Apr 07 18:42:46 malachite kernel: battery: ACPI: Battery Slot [BAT0] (battery present) Apr 07 18:42:46 malachite kernel: sched_clock: Marking stable (1166896928, -586991)->(1172494398, -6184461) Apr 07 18:42:46 malachite kernel: registered taskstats version 1 Apr 07 18:42:46 malachite kernel: Loading compiled-in X.509 certificates Apr 07 18:42:46 malachite kernel: Loaded X.509 cert 'Fedora kernel signing key: eb55b2be431426c78789899a96d617d82132041e' Apr 07 18:42:46 malachite kernel: zswap: loaded using pool lzo/zbud Apr 07 18:42:46 malachite kernel: Key type big_key registered Apr 07 18:42:46 malachite kernel: Key type encrypted registered Apr 07 18:42:46 malachite kernel: integrity: Loading X.509 certificate: UEFI:db Apr 07 18:42:46 malachite kernel: integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4' Apr 07 18:42:46 malachite kernel: integrity: Loading X.509 certificate: UEFI:db Apr 07 18:42:46 malachite kernel: integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53' Apr 07 18:42:46 malachite kernel: ima: Allocated hash algorithm: sha1 Apr 07 18:42:46 malachite kernel: input: AT Raw Set 2 keyboard as /devices/platform/i8042/serio0/input/input4 Also: After doing a bit more research on wikipedia I just noticed that this laptop is actually a late 2017 model, so I'll respond with a respun patch in just a sec. > Thanks. > -- Cheers, Lyude Paul
Re: [GIT PULL v2] LM3532 backlight support improvements and relocation
Hi! > > Changes since v1: > > > > - synchronized DT label properties in DT bindings with what has been agreed > > for the patch "ARM: dts: omap4-droid4: Update backlight dt properties" > > > > The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b: > > > > Linux 5.1-rc1 (2019-03-17 14:22:26 -0700) > > > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git > > tags/lm3532-driver-improvements > > > > for you to fetch changes up to bc1b8492c764fea940fc66206047e37a7f8d77e1: > > > > leds: lm3532: Introduce the lm3532 LED driver (2019-04-07 20:45:49 +0200) > > > > Thanks, > > Jacek Anaszewski > > > > > > LM3532 backlight driver improvements and relocation > > > > Dan Murphy (4): > > dt: lm3532: Add lm3532 dt doc and update ti_lmu doc > > Sorry, this one will need more work. > > When did Rob acknowledge this? I do not remember that mail & quick > google does not find it. Aha, found it now: Date: Fri, 15 Mar 2019 18:35:01 -0500 From: Rob Herring To: Dan Murphy Subject: Re: [PATCH v4 1/4] dt: lm3532: Add lm3532 dt doc and update ti_lmu doc Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
[GIT PULL] ARM: SoC fixes
Hi Linus, The following changes since commit 79a3aaa7b82e3106be97842dedfd8429248896e6: Linux 5.1-rc3 (2019-03-31 14:39:29 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/armsoc-fixes for you to fetch changes up to 9a8f32038a74cb800e9649afbf4b3dba2b7d6539: ARM: milbeaut: fix build with !CONFIG_HOTPLUG_CPU (2019-04-07 15:29:55 -0700) ARM: SoC fixes A collection of fixes from the last few weeks. Most of them are smaller tweaks and fixes to DT and hardware descriptions for boards. Some of the more significant ones are: - eMMC and RGMII stability tweaks for rk3288 - DDC fixes for Rock PI 4 - Audio fixes for two TI am335x eval boards - D_CAN clock fix for am335x - Compilation fixes for clang - !SMP compilation fix for one of the new platforms this release (milbeaut) - A revert of a gpio fix for nomadik that instead was fixed in the gpio subsystem - Whitespace fix for the DT JSON schema (no tabs allowed) Arnd Bergmann (3): ARM: orion: don't use using 64-bit DMA masks ARM: iop: don't use using 64-bit DMA masks ARM: milbeaut: fix build with !CONFIG_HOTPLUG_CPU Axel Lin (1): reset: meson-audio-arb: Fix missing .owner setting of reset_controller_dev David Engraf (1): ARM: dts: at91: Fix typo in ISC_D0 on PC9 David Summers (1): ARM: dts: rockchip: Fix SD card detection on rk3288-tinker Dinh Nguyen (1): arm64: dts: stratix10: add the sysmgr-syscon property from the gmac's Douglas Anderson (3): ARM: dts: rockchip: Fix gpu opp node names for rk3288 ARM: dts: rockchip: Remove #address/#size-cells from rk3288 mipi_dsi ARM: dts: rockchip: Remove #address/#size-cells from rk3288-veyron gpio-keys Ezequiel Garcia (1): arm64: dts: rockchip: add DDC bus on Rock Pi 4 Janusz Krzysztofik (1): ARM: OMAP1: ams-delta: Fix broken GPIO ID allocation Jonas Karlman (1): ARM: dts: rockchip: fix rk3288 cpu opp node reference Julia Lawall (1): ARM: OMAP2+: add missing of_node_put after of_device_is_available Leonidas P. Papadakos (1): arm64: dts: rockchip: fix rk3328-roc-cc gmac2io tx/rx_delay Maxime Ripard (1): dt-bindings: cpu: Fix JSON schema Neil Armstrong (1): dt-bindings: reset: meson-g12a: Add missing USB2 PHY resets Olof Johansson (6): Merge tag 'reset-fixes-for-v5.1' of git://git.pengutronix.de/pza/linux into arm/fixes Merge tag 'stratix10_fix_for_v5.1' of git://git.kernel.org/.../dinguyen/linux into arm/fixes Merge tag 'v5.1-rockchip-dtfixes-1' of git://git.kernel.org/.../mmind/linux-rockchip into arm/fixes Merge tag 'at91-5.1-fixes' of git://git.kernel.org/.../at91/linux into arm/fixes Merge tag 'omap-for-v5.1/fixes-signed' of git://git.kernel.org/.../tmlind/linux-omap into arm/fixes Revert "ARM: dts: nomadik: Fix polarity of SPI CS" Peng Hao (1): arm/mach-at91/pm : fix possible object reference leak Peter Geis (2): arm64: dts: rockchip: fix rk3328 rgmii high tx error rate arm64: dts: rockchip: fix rk3328 sdmmc0 write errors Peter Ujfalusi (2): ARM: dts: am335x-evm: Correct the regulators for the audio codec ARM: dts: am335x-evmsk: Correct the regulators for the audio codec Tomohiro Mayama (1): arm64: dts: rockchip: Fix vcc_host1_5v GPIO polarity on rk3328-rock64 Tony Lindgren (2): ARM: dts: Fix dcan clkctrl clock for am3 Merge commit '7d56bedb2730dc2ea8abf0fd7240ee99ecfee3c9' into omap-for-v5.1/fixes Documentation/devicetree/bindings/arm/cpus.yaml| 2 +- arch/arm/boot/dts/am335x-evm.dts | 26 -- arch/arm/boot/dts/am335x-evmsk.dts | 26 -- arch/arm/boot/dts/am33xx-l4.dtsi | 4 +- arch/arm/boot/dts/rk3288-tinker.dtsi | 3 +- arch/arm/boot/dts/rk3288-veyron.dtsi | 2 - arch/arm/boot/dts/rk3288.dtsi | 20 arch/arm/boot/dts/sama5d2-pinfunc.h| 2 +- arch/arm/boot/dts/ste-nomadik-nhk15.dts| 9 ++-- arch/arm/mach-at91/pm.c| 6 ++- arch/arm/mach-iop13xx/setup.c | 8 +-- arch/arm/mach-iop13xx/tpmi.c | 10 ++-- arch/arm/mach-milbeaut/platsmp.c | 4 ++ arch/arm/mach-omap1/board-ams-delta.c | 2 + arch/arm/mach-omap2/display.c | 4 +- arch/arm/plat-iop/adma.c | 6 +-- arch/arm/plat-orion/common.c | 4 +- arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 3 ++ arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 4 +- arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 3 +- arch/arm64/boot/dts/rockchip/rk3328.dtsi | 58 +++---
Re: [patch V2 28/29] x86/irq/64: Remap the IRQ stack with guard pages
On Sat, 6 Apr 2019, Andy Lutomirski wrote: > On Fri, Apr 5, 2019 at 8:11 AM Thomas Gleixner wrote: > > > > From: Andy Lutomirski > > > > The IRQ stack lives in percpu space, so an IRQ handler that overflows it > > will overwrite other data structures. > > > > Use vmap() to remap the IRQ stack so that it will have the usual guard > > pages that vmap/vmalloc allocations have. With this the kernel will panic > > immediately on an IRQ stack overflow. > > The 0day bot noticed that this dies with DEBUG_PAGEALLOC on. This is > because the store_stackinfo() function is utter garbage and this patch > correctly detects just how broken it is. The attached patch "fixes" > it. (It also contains a reliability improvement that should probably > get folded in, but is otherwise unrelated.) > > A real fix would remove the generic kstack_end() function entirely > along with __HAVE_ARCH_KSTACK_END and would optionally replace > store_stackinfo() with something useful. Josh, do we have a generic > API to do a little stack walk like this? Otherwise, I don't think it > would be the end of the world to just remove the offending code. Actually we have: save_stack_trace()
Re: [PATCH] ARM: milbeaut: fix build with !CONFIG_HOTPLUG_CPU
On Wed, Mar 13, 2019 at 10:19:16PM +0100, Arnd Bergmann wrote:
> When HOTPLUG_CPU is disabled, some fields in the smp operations
> are not available or needed:
>
> arch/arm/mach-milbeaut/platsmp.c:90:3: error: field designator 'cpu_die' does
> not refer to any field in type
> 'struct smp_operations'
> .cpu_die= m10v_cpu_die,
> ^
> arch/arm/mach-milbeaut/platsmp.c:91:3: error: field designator 'cpu_kill'
> does not refer to any field in type
> 'struct smp_operations'
> .cpu_kill = m10v_cpu_kill,
> ^
>
> Hide them in an #ifdef like the other platforms do.
>
> Fixes: 9fb29c734f9e ("ARM: milbeaut: Add basic support for Milbeaut m10v SoC")
> Signed-off-by: Arnd Bergmann
Applied to fixes.
-Olof
Re: [PATCH v5 2/3] platform/chrome: Add Wilco EC keyboard backlight LEDs support
On Sun, Apr 7, 2019 at 3:18 PM Pavel Machek wrote: > > > > > > This document also states "The naming scheme above leaves scope > > > > for further attributes should they be needed". It does not permit, > > > > however, to redefine one of the fields to mean "location", much less > > > > the declaration that a devicename of "platform" shall refer to an > > > > "internal" backlight, or that there shall be no more than one > > > > "internal" backlight in a given system. > > > > > > "platform" is as good devicename as "wilco" or "chromeos". > > > > No, because "platform" is not a device, it is something that you are > > trying to assign a magic meaning to. > > "chromeos" is not a device, either. I agree, it is not a device name. We do not assign any specific meaning to it though. We could change it to "cros_ec" if so desired and nothing should break. Thanks. -- Dmitry
Re: [PATCH] dt-bindings: cpu: Fix JSON schema
On Tue, Apr 02, 2019 at 08:42:02PM +0900, Sugaya, Taichi wrote:
> Hi,
>
> On 2019/04/01 22:02, Sugaya, Taichi wrote:
> > Hi,
> >
> > On 2019/04/01 20:35, Maxime Ripard wrote:
> > > Hi,
> > >
> > > On Mon, Apr 01, 2019 at 07:52:06PM +0900, Sugaya, Taichi wrote:
> > > > On 2019/04/01 18:10, Maxime Ripard wrote:
> > > > > Hi Sugaya, Arnd, Olof,
> > > > >
> > > > > On Thu, Mar 28, 2019 at 02:35:54PM -0500, Rob Herring wrote:
> > > > > > +arm-soc
> > > > > >
> > > > > > On Mon, Mar 18, 2019 at 5:05 AM Maxime Ripard
> > > > > > wrote:
> > > > > > >
> > > > > > > Commit fd73403a4862 ("dt-bindings: arm: Add SMP enable-method for
> > > > > > > Milbeaut") added support for a new cpu enable-method, but did so
> > > > > > > using
> > > > > > > tabulations to ident. This is however invalid in the syntax, and
> > > > > > > resulted
> > > > > > > in a failure when trying to use that schemas for validation.
> > > > > > >
> > > > > > > Use spaces instead of tabs to indent to fix this.
> > > > > > >
> > > > > > > Fixes: fd73403a4862 ("dt-bindings: arm: Add SMP enable-method for
> > > > > > > Milbeaut")
> > > > > > > Signed-off-by: Maxime Ripard
> > > > > > > ---
> > > > > > > Documentation/devicetree/bindings/arm/cpus.yaml | 2 +-
> > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > Reviewed-by: Rob Herring
> > > > > >
> > > > > > This should be applied to arm-soc tree having the commit.
> > > > >
> > > > > Could you pick up that patch?
> > > >
> > > > I got it.
> > > > My mission is to resubmit your fix-patch added my singned-off tag and
> > > > Rob's reviewed tag...right?
> > >
> > > If you are part of arm-soc and send your pull requests to Arnd and
> > > Olof, simply pick it up in the same branch than the initial patch was
> > > in. And when you apply that patch, you indeed need to add your
> > > Signed-off-by (note that most commands to commit have an option to do
> > > that automatically: -s and that includes git am) and the Rob's
> > > reviewed-by.
> > >
> > > Then, send a new pull request to arm-soc.
> > >
> >
> > Okay, thanks for your suggestion.
> > I try to make pull request!
> >
>
> Sorry I realized that I couldn't make a private repository, so I'll send my
> Ack instead.
>
> Acked-by: Sugaya Taichi
Applied to arm/fixes now. Thanks!
-Olof
Re: [PATCH 1/2] ARM: orion: don't use using 64-bit DMA masks
On Mon, Mar 25, 2019 at 04:50:42PM +0100, Arnd Bergmann wrote: > clang warns about statically defined DMA masks from the DMA_BIT_MASK > macro with length 64: > > arch/arm/plat-orion/common.c:625:29: error: shift count >= width of type > [-Werror,-Wshift-count-overflow] > .coherent_dma_mask = DMA_BIT_MASK(64), > ^~~~ > include/linux/dma-mapping.h:141:54: note: expanded from macro 'DMA_BIT_MASK' > #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1)) > > The ones in orion shouldn't really be 64 bit masks, so changing them > to what the driver can support avoids the warning. > > Signed-off-by: Arnd Bergmann Applied to fixes. -Olof
Re: [PATCH 2/2] ARM: iop: don't use using 64-bit DMA masks
On Mon, Mar 25, 2019 at 04:50:43PM +0100, Arnd Bergmann wrote: > clang warns about statically defined DMA masks from the DMA_BIT_MASK > macro with length 64: > > arch/arm/mach-iop13xx/setup.c:303:35: error: shift count >= width of type > [-Werror,-Wshift-count-overflow] > static u64 iop13xx_adma_dmamask = DMA_BIT_MASK(64); > ^~~~ > include/linux/dma-mapping.h:141:54: note: expanded from macro 'DMA_BIT_MASK' > #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1)) > ^ ~~~ > > The ones in iop shouldn't really be 64 bit masks, so changing them > to what the driver can support avoids the warning. > > Signed-off-by: Arnd Bergmann Applied to fixes. -Olof
Re: [PATCH v5 2/3] platform/chrome: Add Wilco EC keyboard backlight LEDs support
> > > This document also states "The naming scheme above leaves scope > > > for further attributes should they be needed". It does not permit, > > > however, to redefine one of the fields to mean "location", much less > > > the declaration that a devicename of "platform" shall refer to an > > > "internal" backlight, or that there shall be no more than one > > > "internal" backlight in a given system. > > > > "platform" is as good devicename as "wilco" or "chromeos". > > No, because "platform" is not a device, it is something that you are > trying to assign a magic meaning to. "chromeos" is not a device, either. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v2 2/3] Input: add a driver for GPIO controllable vibrators
Hi Luca,
On Sun, Apr 07, 2019 at 05:58:41PM +0200, Luca Weiss wrote:
> Provide a simple driver for GPIO controllable vibrators.
> It will be used by the Fairphone 2.
>
> Signed-off-by: Luca Weiss
> ---
> drivers/input/misc/Kconfig | 12 ++
> drivers/input/misc/Makefile | 1 +
> drivers/input/misc/gpio-vibra.c | 214
> 3 files changed, 227 insertions(+)
> create mode 100644 drivers/input/misc/gpio-vibra.c
>
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index e15ed1bb8558..6dfe9e2fe5b1 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -290,6 +290,18 @@ config INPUT_GPIO_DECODER
>To compile this driver as a module, choose M here: the module
>will be called gpio_decoder.
>
> +config INPUT_GPIO_VIBRA
> + tristate "GPIO vibrator support"
> + depends on GPIOLIB || COMPILE_TEST
> + select INPUT_FF_MEMLESS
> + help
> + Say Y here to get support for GPIO based vibrator devices.
> +
> + If unsure, say N.
> +
> + To compile this driver as a module, choose M here: the module will be
> + called gpio-vibra.
> +
> config INPUT_IXP4XX_BEEPER
> tristate "IXP4XX Beeper support"
> depends on ARCH_IXP4XX
> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
> index b936c5b1d4ac..f38ebbdb05e2 100644
> --- a/drivers/input/misc/Makefile
> +++ b/drivers/input/misc/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_INPUT_DRV2667_HAPTICS) += drv2667.o
> obj-$(CONFIG_INPUT_GP2A) += gp2ap002a00f.o
> obj-$(CONFIG_INPUT_GPIO_BEEPER) += gpio-beeper.o
> obj-$(CONFIG_INPUT_GPIO_DECODER) += gpio_decoder.o
> +obj-$(CONFIG_INPUT_GPIO_VIBRA) += gpio-vibra.o
> obj-$(CONFIG_INPUT_HISI_POWERKEY)+= hisi_powerkey.o
> obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
> obj-$(CONFIG_INPUT_IMS_PCU) += ims-pcu.o
> diff --git a/drivers/input/misc/gpio-vibra.c b/drivers/input/misc/gpio-vibra.c
> new file mode 100644
> index ..14f9534668c8
> --- /dev/null
> +++ b/drivers/input/misc/gpio-vibra.c
> @@ -0,0 +1,214 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * GPIO vibrator driver
> + *
> + * Copyright (C) 2019 Luca Weiss
> + *
> + * Based on PWM vibrator driver:
> + * Copyright (C) 2017 Collabora Ltd.
> + *
> + * Based on previous work from:
> + * Copyright (C) 2012 Dmitry Torokhov
> + *
> + * Based on PWM beeper driver:
> + * Copyright (C) 2010, Lars-Peter Clausen
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +enum vibrator_state {
> + VIBRATOR_OFF,
> + VIBRATOR_ON
> +};
I'd probably go with simple "bool running".
> +
> +struct gpio_vibrator {
> + struct input_dev *input;
> + struct gpio_desc *gpio;
> + struct regulator *vcc;
> +
> + struct work_struct play_work;
> + enum vibrator_state state;
> + bool vcc_on;
> +};
> +
> +static int gpio_vibrator_start(struct gpio_vibrator *vibrator)
> +{
> + struct device *pdev = vibrator->input->dev.parent;
> + int err;
> +
> + if (!vibrator->vcc_on) {
> + err = regulator_enable(vibrator->vcc);
> + if (err) {
> + dev_err(pdev, "failed to enable regulator: %d", err);
> + return err;
> + }
> + vibrator->vcc_on = true;
> + }
> +
> + gpiod_set_value(vibrator->gpio, 1);
Since this is called by work item and thus from context that can sleep,
we can use gpiod_set_value_cansleep() so that "slow" GPIOs can be used
with the driver.
> +
> + return 0;
> +}
> +
> +static void gpio_vibrator_stop(struct gpio_vibrator *vibrator)
> +{
> + gpiod_set_value(vibrator->gpio, 0);
> +
> + if (vibrator->vcc_on) {
> + regulator_disable(vibrator->vcc);
> + vibrator->vcc_on = false;
> + }
> +}
> +
> +static void gpio_vibrator_play_work(struct work_struct *work)
> +{
> + struct gpio_vibrator *vibrator = container_of(work,
> + struct gpio_vibrator, play_work);
> +
> + if (vibrator->state == VIBRATOR_ON)
> + gpio_vibrator_start(vibrator);
> + else
> + gpio_vibrator_stop(vibrator);
> +}
> +
> +static int gpio_vibrator_play_effect(struct input_dev *dev, void *data,
> + struct ff_effect *effect)
> +{
> + struct gpio_vibrator *vibrator = input_get_drvdata(dev);
> +
> + int level = effect->u.rumble.strong_magnitude;
> +
> + if (!level)
> + level = effect->u.rumble.weak_magnitude;
> +
> + if (level)
> + vibrator->state = VIBRATOR_ON;
> + else
> + vibrator->state = VIBRATOR_OFF;
> +
> + schedule_work(>play_work);
> +
> + return 0;
> +}
> +
> +static void gpio_vibrator_close(struct input_dev *input)
> +{
> + struct gpio_vibrator *vibrator =
Re: [GIT PULL v2] LM3532 backlight support improvements and relocation
Hi! > Changes since v1: > > - synchronized DT label properties in DT bindings with what has been agreed > for the patch "ARM: dts: omap4-droid4: Update backlight dt properties" > > The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b: > > Linux 5.1-rc1 (2019-03-17 14:22:26 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git > tags/lm3532-driver-improvements > > for you to fetch changes up to bc1b8492c764fea940fc66206047e37a7f8d77e1: > > leds: lm3532: Introduce the lm3532 LED driver (2019-04-07 20:45:49 +0200) > > Thanks, > Jacek Anaszewski > > > LM3532 backlight driver improvements and relocation > > Dan Murphy (4): > dt: lm3532: Add lm3532 dt doc and update ti_lmu doc Sorry, this one will need more work. When did Rob acknowledge this? I do not remember that mail & quick google does not find it. I still don't like the fact that it is using different binding from other similar chips. It for example replaces "ramp-up-msec" with "ramp-up-us". This is certainly wrong: +Optional properties if ALS mode is used: + - ti,als-vmin - Minimum ALS voltage defined in Volts + - ti,als-vmax - Maximum ALS voltage defined in Volts + Per the data sheet the max ALS voltage is 2V and the min is 0V ...but milivolts (or microvolts?) make sense there, and clearly milivolts are used because 2000V is way out of range.: + ti,als-vmin = <0>; + ti,als-vmax = <2000>; Plus: +Required child properties: ... + - ti,led-mode : Defines if the LED strings are manually controlled or + if the LED strings are controlled by the ALS. + 0x00 - LED strings are I2C controlled via full scale brightness control register + 0x01 - LED strings are ALS controlled Dunno. Normally we'd have "ti,automatic-led-mode", and if it was not present, we'd default to manual, no? (Also "led-mode" is a bit too generic. ti,als-enabled would be better description). Plus, I'd kind of expect ALS enabled/disabled to be runtime controled, not from the device tree. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH 6/6] arm64/mm: Enable ZONE_DEVICE
On Thu, Apr 4, 2019 at 2:47 AM Robin Murphy wrote: > > On 04/04/2019 06:04, Dan Williams wrote: > > On Wed, Apr 3, 2019 at 9:42 PM Anshuman Khandual > > wrote: > >> > >> > >> > >> On 04/03/2019 07:28 PM, Robin Murphy wrote: > >>> [ +Dan, Jerome ] > >>> > >>> On 03/04/2019 05:30, Anshuman Khandual wrote: > Arch implementation for functions which create or destroy vmemmap mapping > (vmemmap_populate, vmemmap_free) can comprehend and allocate from inside > device memory range through driver provided vmem_altmap structure which > fulfils all requirements to enable ZONE_DEVICE on the platform. Hence > just > >>> > >>> ZONE_DEVICE is about more than just altmap support, no? > >> > >> Hot plugging the memory into a dev->numa_node's ZONE_DEVICE and > >> initializing the > >> struct pages for it has stand alone and self contained use case. The > >> driver could > >> just want to manage the memory itself but with struct pages either in the > >> RAM or > >> in the device memory range through struct vmem_altmap. The driver may not > >> choose > >> to opt for HMM, FS DAX, P2PDMA (use cases of ZONE_DEVICE) where it may > >> have to > >> map these pages into any user pagetable which would necessitate support for > >> pte|pmd|pud_devmap. > > > > What's left for ZONE_DEVICE if none of the above cases are used? > > > >> Though I am still working towards getting HMM, FS DAX, P2PDMA enabled on > >> arm64, > >> IMHO ZONE_DEVICE is self contained and can be evaluated in itself. > > > > I'm not convinced. What's the specific use case. > > The fundamental "roadmap" reason we've been doing this is to enable > further NVDIMM/pmem development (libpmem/Qemu/etc.) on arm64. The fact > that ZONE_DEVICE immediately opens the door to the various other stuff > that the CCIX folks have interest in is a definite bonus, so it would > certainly be preferable to get arm64 on par with the current state of > things rather than try to subdivide the scope further. > > I started working on this from the ZONE_DEVICE end, but got bogged down > in trying to replace my copied-from-s390 dummy hot-remove implementation > with something proper. Anshuman has stepped in to help with hot-remove > (since we also have cloud folks wanting that for its own sake), so is > effectively coming at the problem from the opposite direction, and I'll > be the first to admit that we've not managed the greatest job of meeting > in the middle and coordinating our upstream story; sorry about that :) > > Let me freshen up my devmap patches and post them properly, since that > discussion doesn't have to happen in the context of hot-remove; they're > effectively just parallel dependencies for ZONE_DEVICE. Sounds good. It's also worth noting that Ira's recent patches for supporting get_user_pages_fast() for "longterm" pins relies on PTE_DEVMAP to determine when fast-GUP is safe to proceed, or whether it needs to fall back to slow-GUP. So it really is the case that "devmap" support is an assumption for ZONE_DEVICE.
Re: [PATCH] Input: i8042 - disable KBD port on Late-2016 Razer Blade Stealth
Hi Lyude, On Sun, Apr 07, 2019 at 05:37:34PM -0400, Lyude Paul wrote: > The late 2016 model of the Razer Blade Stealth has a built-in USB > keyboard, but for some reason the BIOS exposes an i8042 controller with > a connected KBD port. While this fake AT Keyboard device doesn't appear > to report any events, attempting to change the state of the caps lock > LED on it from on to off causes the entire system to hang. > > So, introduce a quirk table for disabling keyboard probing by default, > i8042_dmi_nokbd_table, and add this specific model of Razer laptop to > that table. What does dmesg show about i8042 for this device? Especially line "PNP: PS/2 Controller ..."? Thanks. -- Dmitry
Re: [PATCH v5 3/3] platform/chrome: Standardize Chrome OS keyboard backlight name
Hi Jacek, On Fri, Apr 5, 2019 at 1:00 PM Jacek Anaszewski wrote: > > Hi all, > > On 4/5/19 10:42 AM, Enric Balletbo i Serra wrote: > > Hi, > > > > On 5/4/19 0:42, Guenter Roeck wrote: > >> On Thu, Apr 4, 2019 at 3:05 PM Pavel Machek wrote: > >>> > >>> On Thu 2019-04-04 14:48:35, Dmitry Torokhov wrote: > On Thu, Apr 4, 2019 at 1:42 PM Pavel Machek wrote: > > > > Hi! > > > And what to do if internal keyboard is not platform but USB? Like > Google "Whiskers"? (I am not sure why you decided to drop my mention > of internal USB keyboards completely off your reply). > >>> > >>> I don't have answers for everything. Even if you have USB keyboard, > >>> you'll > >>> likely still have backlight connected to embedded controller. If not, > >>> then maybe you have exception userland needs to know about. > >>> > >>> Still better than making everything an exception. > >> > >> You do not need to make everything exception. You just need to look > >> beyond the name, and see how the device is connected. And then apply > >> your exceptions for "weird" devices. > > > > "Where it is connected" is not interesting to the userland. "Is it > > backlight for internal keyboard" is the right question. It may be > > connected to embedded controller or some kind of controller over > > i2c... my shell scripts should not need to know about architecture of > > every notebook out there. > > Then your scripts will be failing for some setups. > >>> > >>> Well, yes. Do you want to guess what "lp5523:kb3" is? > >>> > >> > >> Oh, please. The discussion is about the driver name part, which you > >> want to overload with some string to mean "internal", which in turn > >> is, if anything, part of the functionality. > >> > >> With "platform", you'll at some point have two > >> "platform::kbd_backlight" entries. Remind me to send you a "told you > >> so" when that happens. > >> > >> Guenter > >> > > But I don't see why I should do additional work when its trivial for > > kernel to just name the LED in an useful way. > > > > "platform::kbd_backlight" has no disadvantages compared to > > "wilco::kbd_backlight" ... so lets just use it. > > It has disadvantages because it promises more than it can deliver IMO. > If device name != "platform::kbd_backlight" it does not mean that it > is not internal keyboard. > >>> > >>> My promise is if "platform::kbd_backlight" exists, it is backlight for > >>> internal keyboard. (And second half is "if it is easy for kernel, we > >>> name backlight for internal keyboard platform::kbd_backlight"). > >>> > And you still have not resolved how you will > handle cases when there is more than one deice that can be considered > internal and may have a backlight. > >>> > >>> Is that realistic? How would that device look like? > >>> > > > > Maybe is something "weird" in the PC/laptop world but in the Embedded world > > is > > not as weird as you think. I worked on devices that has two internal > > backlights, > > one to lit the qwerty keyboard and the other one to lit the numeric pad. We > > used > > the device field to differentiate both. > > > >keyboardist::kbd_backlight > >tclnumpad::kbd_backlight > > > > Taking this to the extreme you can also think in a device where every key > > has > > its own LED backlight, this happens for example in this device [1]. The > > device > > can lit only specific keys giving to the user a word prediction experience > > (i.e > > After press a key, only the keys that match with a possible word are lit on) > > While we have your attention at the subject of LED naming I would like > to invite you all to reviewing my recent patch set [0], available > also on the led_naming_v3 branch of linux-leds.git [1]. > > The patch set introduces generic, backward compatible mechanism for > composing LED class devices names. It also aims to deprecate current > LED naming convention and encourage dropping "devicename" section. >From looking at the docs section it looks like you propose to move from "device:color:fucntion" to simply "color:function" naming, and expect to have a suffix "_" to avoid problem with duplicate LED names. I do not think this is quite backward compatible, since previously userspace was supposed to split the device name on the colon boundaries and extract the 3rd component if it wanted to determine function. With the new proposed scheme it has to be modified to try and also fetch the 2nd component if there isn't 3rd one and consider it as function as well. It also need to recognize potential suffixes and drop them before matching on function name. I think if you want flexibility you really need to switch from encoding the information in the name to add LED class attributes describing the LED in more detail. This might include information about LEd placement (internal/external) if such
Re: [PATCH v5 2/3] platform/chrome: Add Wilco EC keyboard backlight LEDs support
On Sat, Apr 6, 2019 at 1:41 AM Pavel Machek wrote: > > On Fri 2019-04-05 13:15:34, Guenter Roeck wrote: > > On Thu, Apr 04, 2019 at 11:10:08AM -0600, Nick Crews wrote: > > > The EC is in charge of controlling the keyboard backlight on > > > the Wilco platform. We expose a standard LED class device at > > > /sys/class/leds/platform::kbd_backlight. This driver is modeled > > > after the standard Chrome OS keyboard backlight driver at > > > drivers/platform/chrome/cros_kbd_led_backlight.c > > > > > > Some Wilco devices do not support a keyboard backlight. This > > > is checked via wilco_ec_keyboard_leds_exist() in the core driver, > > > and a platform_device will only be registered by the core if > > > a backlight is supported. > > > > > > After an EC reset the backlight could be in a non-PWM mode. > > > Earlier in the boot sequence the BIOS should send a command to > > > the EC to set the brightness, so things **should** be set up, > > > but we double check in probe() as we query the initial brightness. > > > If not set up, then set the brightness to 0. > > > > > > Since the EC will never change the backlight level of its own accord, > > > we don't need to implement a brightness_get() method. > > > > > > v5 changes: > > > -Rename the LED device to "platform::kbd_backlight", to > > > denote that this is the built-in system keyboard. > > > > > > > NACK. > > Please keep it as it is, it is okay. > > > Per Documentation/leds/leds-class.txt, LED devices are named > > "devicename:colour:function" > > You failed to follow threads explaining this is being changed, even > when I pointed you at them. What you are doing here is not helpful. Pavel, what I find is unhelpful is you requiring to conform to the new rules that have not been accepted yet and for which there clearly are objections. You keep ignoring all the issues that we continue to point out with your proposed scheme. I will go and try to reply to Jacek's thread, but it is my firm belief that changing naming scheme is not what we need to do here. > > > This document also states "The naming scheme above leaves scope > > for further attributes should they be needed". It does not permit, > > however, to redefine one of the fields to mean "location", much less > > the declaration that a devicename of "platform" shall refer to an > > "internal" backlight, or that there shall be no more than one > > "internal" backlight in a given system. > > "platform" is as good devicename as "wilco" or "chromeos". No, because "platform" is not a device, it is something that you are trying to assign a magic meaning to. Thanks. -- Dmitry
Re: [PATCH v4 0/6] lib/string: Add strscpy_pad() function
On Fri, Apr 05, 2019 at 12:58:53PM +1100, Tobin C. Harding wrote: > Hi Shua, Apologies for continually leaving off the 'h' from your name Shuah. Tobin
[PATCH] Input: i8042 - disable KBD port on Late-2016 Razer Blade Stealth
The late 2016 model of the Razer Blade Stealth has a built-in USB
keyboard, but for some reason the BIOS exposes an i8042 controller with
a connected KBD port. While this fake AT Keyboard device doesn't appear
to report any events, attempting to change the state of the caps lock
LED on it from on to off causes the entire system to hang.
So, introduce a quirk table for disabling keyboard probing by default,
i8042_dmi_nokbd_table, and add this specific model of Razer laptop to
that table.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
drivers/input/serio/i8042-x86ia64io.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/input/serio/i8042-x86ia64io.h
b/drivers/input/serio/i8042-x86ia64io.h
index 136f6e7bf797..888f5f6feebf 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -884,6 +884,22 @@ static const struct dmi_system_id __initconst
i8042_dmi_kbdreset_table[] = {
{ }
};
+static const struct dmi_system_id i8042_dmi_nokbd_table[] __initconst = {
+ {
+ /*
+* Razer Blade Stealth (Late 2016 model) - Keyboard is on USB
+* but the system exposes a fake AT keyboard that crashes the
+* system if the caps lock LED is changed
+*/
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Razer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Blade Stealth"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "2.04"),
+ },
+ },
+ { }
+};
+
#endif /* CONFIG_X86 */
#ifdef CONFIG_PNP
@@ -1040,6 +1056,9 @@ static int __init i8042_pnp_init(void)
#ifdef CONFIG_X86
if (dmi_check_system(i8042_dmi_nopnp_table))
i8042_nopnp = true;
+
+ if (dmi_check_system(i8042_dmi_nokbd_table))
+ i8042_nokbd = true;
#endif
if (i8042_nopnp) {
--
2.20.1
[PATCH] perf vendor events arm64: Add Cortex-A72 events
The Cortex-A72 supports all ARMv8 recommended events up to the
RC_ST_SPEC (0x91) event, create an appropriate JSON file for mapping
those events and update the mapfile.csv for matching the Cortex-A72 MIDR
to that file.
Signed-off-by: Florian Fainelli
---
.../arm64/arm/cortex-a72/core-imp-def.json| 206 ++
tools/perf/pmu-events/arch/arm64/mapfile.csv | 1 +
2 files changed, 207 insertions(+)
create mode 100644
tools/perf/pmu-events/arch/arm64/arm/cortex-a72/core-imp-def.json
diff --git a/tools/perf/pmu-events/arch/arm64/arm/cortex-a72/core-imp-def.json
b/tools/perf/pmu-events/arch/arm64/arm/cortex-a72/core-imp-def.json
new file mode 100644
index ..eb82fc8529c6
--- /dev/null
+++ b/tools/perf/pmu-events/arch/arm64/arm/cortex-a72/core-imp-def.json
@@ -0,0 +1,206 @@
+[
+{
+"ArchStdEvent": "L1D_CACHE_RD",
+},
+{
+"ArchStdEvent": "L1D_CACHE_WR",
+},
+{
+"ArchStdEvent": "L1D_CACHE_REFILL_RD",
+},
+{
+"ArchStdEvent": "L1D_CACHE_REFILL_WR",
+},
+{
+"ArchStdEvent": "L1D_CACHE_REFILL_INNER",
+},
+{
+"ArchStdEvent": "L1D_CACHE_REFILL_OUTER",
+},
+{
+"ArchStdEvent": "L1D_CACHE_WB_VICTIM",
+},
+{
+"ArchStdEvent": "L1D_CACHE_WB_CLEAN",
+},
+{
+"ArchStdEvent": "L1D_CACHE_INVAL",
+},
+{
+"ArchStdEvent": "L1D_TLB_REFILL_RD",
+},
+{
+"ArchStdEvent": "L1D_TLB_REFILL_WR",
+},
+{
+"ArchStdEvent": "L1D_TLB_RD",
+},
+{
+"ArchStdEvent": "L1D_TLB_WR",
+},
+{
+"ArchStdEvent": "L2D_CACHE_RD",
+},
+{
+"ArchStdEvent": "L2D_CACHE_WR",
+},
+{
+"ArchStdEvent": "L2D_CACHE_REFILL_RD",
+},
+{
+"ArchStdEvent": "L2D_CACHE_REFILL_WR",
+},
+{
+"ArchStdEvent": "L2D_CACHE_WB_VICTIM",
+},
+{
+"ArchStdEvent": "L2D_CACHE_WB_CLEAN",
+},
+{
+"ArchStdEvent": "L2D_CACHE_INVAL",
+},
+{
+"ArchStdEvent": "L2D_TLB_REFILL_RD",
+},
+{
+"ArchStdEvent": "L2D_TLB_REFILL_WR",
+},
+{
+"ArchStdEvent": "L2D_TLB_RD",
+},
+{
+"ArchStdEvent": "L2D_TLB_WR",
+},
+{
+"ArchStdEvent": "BUS_ACCESS_RD",
+},
+{
+"ArchStdEvent": "BUS_ACCESS_WR",
+},
+{
+"ArchStdEvent": "BUS_ACCESS_SHARED",
+},
+{
+"ArchStdEvent": "BUS_ACCESS_NOT_SHARED",
+},
+{
+"ArchStdEvent": "BUS_ACCESS_NORMAL",
+},
+{
+"ArchStdEvent": "BUS_ACCESS_PERIPH",
+},
+{
+"ArchStdEvent": "MEM_ACCESS_RD",
+},
+{
+"ArchStdEvent": "MEM_ACCESS_WR",
+},
+{
+"ArchStdEvent": "UNALIGNED_LD_SPEC",
+},
+{
+"ArchStdEvent": "UNALIGNED_ST_SPEC",
+},
+{
+"ArchStdEvent": "UNALIGNED_LDST_SPEC",
+},
+{
+"ArchStdEvent": "LDREX_SPEC",
+},
+{
+"ArchStdEvent": "STREX_PASS_SPEC",
+},
+{
+"ArchStdEvent": "STREX_FAIL_SPEC",
+},
+{
+"ArchStdEvent": "STREX_SPEC",
+},
+{
+"ArchStdEvent": "LD_SPEC",
+},
+{
+"ArchStdEvent": "ST_SPEC",
+},
+{
+"ArchStdEvent": "LDST_SPEC",
+},
+{
+"ArchStdEvent": "DP_SPEC",
+},
+{
+"ArchStdEvent": "ASE_SPEC",
+},
+{
+"ArchStdEvent": "VFP_SPEC",
+},
+{
+"ArchStdEvent": "PC_WRITE_SPEC",
+},
+{
+"ArchStdEvent": "CRYPTO_SPEC",
+},
+{
+"ArchStdEvent": "BR_IMMED_SPEC",
+},
+{
+"ArchStdEvent": "BR_RETURN_SPEC",
+},
+{
+"ArchStdEvent": "BR_INDIRECT_SPEC",
+},
+{
+"ArchStdEvent": "ISB_SPEC",
+},
+{
+"ArchStdEvent": "DSB_SPEC",
+},
+{
+"ArchStdEvent": "DMB_SPEC",
+},
+{
+"ArchStdEvent": "EXC_UNDEF",
+},
+{
+"ArchStdEvent": "EXC_SVC",
+},
+{
+"ArchStdEvent": "EXC_PABORT",
+},
+{
+"ArchStdEvent": "EXC_DABORT",
+},
+{
+"ArchStdEvent": "EXC_IRQ",
+},
+{
+"ArchStdEvent": "EXC_FIQ",
+},
+{
+"ArchStdEvent": "EXC_SMC",
+},
+{
+"ArchStdEvent": "EXC_HVC",
+},
+{
+"ArchStdEvent": "EXC_TRAP_PABORT",
+},
+{
+"ArchStdEvent": "EXC_TRAP_DABORT",
+},
+{
+"ArchStdEvent": "EXC_TRAP_OTHER",
+},
+{
+"ArchStdEvent": "EXC_TRAP_IRQ",
+},
+{
+"ArchStdEvent": "EXC_TRAP_FIQ",
+},
+{
+"ArchStdEvent": "RC_LD_SPEC",
+},
+{
+"ArchStdEvent": "RC_ST_SPEC",
+},
+]
diff --git a/tools/perf/pmu-events/arch/arm64/mapfile.csv
b/tools/perf/pmu-events/arch/arm64/mapfile.csv
index 59cd8604b0bd..716d59248e82 100644
--- a/tools/perf/pmu-events/arch/arm64/mapfile.csv
+++ b/tools/perf/pmu-events/arch/arm64/mapfile.csv
@@ -13,6 +13,7 @@
#
[PATCH] rtc: test: use .set_time
Use .set_time instead of the deprecated .set_mmss64.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-test.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/rtc/rtc-test.c b/drivers/rtc/rtc-test.c
index f1a6dc5ad013..b298e9902f45 100644
--- a/drivers/rtc/rtc-test.c
+++ b/drivers/rtc/rtc-test.c
@@ -70,11 +70,11 @@ static int test_rtc_read_time(struct device *dev, struct
rtc_time *tm)
return 0;
}
-static int test_rtc_set_mmss64(struct device *dev, time64_t secs)
+static int test_rtc_set_time(struct device *dev, struct rtc_time *tm)
{
struct rtc_test_data *rtd = dev_get_drvdata(dev);
- rtd->offset = secs - ktime_get_real_seconds();
+ rtd->offset = rtc_tm_to_time64(tm) - ktime_get_real_seconds();
return 0;
}
@@ -94,15 +94,15 @@ static int test_rtc_alarm_irq_enable(struct device *dev,
unsigned int enable)
static const struct rtc_class_ops test_rtc_ops_noalm = {
.read_time = test_rtc_read_time,
- .set_mmss64 = test_rtc_set_mmss64,
+ .set_time = test_rtc_set_time,
.alarm_irq_enable = test_rtc_alarm_irq_enable,
};
static const struct rtc_class_ops test_rtc_ops = {
.read_time = test_rtc_read_time,
+ .set_time = test_rtc_set_time,
.read_alarm = test_rtc_read_alarm,
.set_alarm = test_rtc_set_alarm,
- .set_mmss64 = test_rtc_set_mmss64,
.alarm_irq_enable = test_rtc_alarm_irq_enable,
};
--
2.20.1
[PATCH] soc: brcmstb: Fix error path for unsupported CPUs
In case setup_hifcpubiuctrl_regs() returns an error, because of e.g:
an unsupported CPU type, just catch that error and return instead of
blindly continuing with the initialization. This fixes a NULL pointer
de-reference with the code continuing without having a proper array of
registers to use.
Fixes: 22f7a9116eba ("soc: brcmstb: Correct CPU_CREDIT_REG offset for
Brahma-B53 CPUs")
Signed-off-by: Florian Fainelli
---
drivers/soc/bcm/brcmstb/biuctrl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/bcm/brcmstb/biuctrl.c
b/drivers/soc/bcm/brcmstb/biuctrl.c
index 6d89ebf13b8a..c16273b31b94 100644
--- a/drivers/soc/bcm/brcmstb/biuctrl.c
+++ b/drivers/soc/bcm/brcmstb/biuctrl.c
@@ -246,7 +246,9 @@ static int __init brcmstb_biuctrl_init(void)
if (!np)
return 0;
- setup_hifcpubiuctrl_regs(np);
+ ret = setup_hifcpubiuctrl_regs(np);
+ if (ret)
+ return ret;
ret = mcp_write_pairing_set();
if (ret) {
--
2.17.1
linux-next: manual merge of the kspp-gustavo tree with Linus' tree
Hi all,
Today's linux-next merge of the kspp-gustavo tree got a conflict in:
arch/x86/include/asm/syscall.h
between commits:
b35f549df1d7 ("syscalls: Remove start and number from syscall_get_arguments()
args")
32d92586629a ("syscalls: Remove start and number from syscall_set_arguments()
args")
from Linus' tree and commit:
1f7ae812f87e ("x86/syscalls: Mark expected switch fall-throughs")
from the kspp-gustavo tree.
I fixed it up (I just used the version from Linus' tree) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging. You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpH9CD8qHsVI.pgp
Description: OpenPGP digital signature
[PATCH 1/3] rtc: tegra: set range
The Tegra 20 RTC is a 32bit seconds counter (with an unused millisecond
counter).
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-tegra.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/rtc/rtc-tegra.c b/drivers/rtc/rtc-tegra.c
index c6b0a99aa3a9..3f93a1f7abb5 100644
--- a/drivers/rtc/rtc-tegra.c
+++ b/drivers/rtc/rtc-tegra.c
@@ -306,6 +306,13 @@ static int __init tegra_rtc_probe(struct platform_device
*pdev)
info->tegra_rtc_irq = ret;
+ info->rtc_dev = devm_rtc_allocate_device(>dev);
+ if (IS_ERR(info->rtc_dev))
+ return PTR_ERR(info->rtc_dev);
+
+ info->rtc_dev->ops = _rtc_ops;
+ info->rtc_dev->range_max = U32_MAX;
+
info->clk = devm_clk_get(>dev, NULL);
if (IS_ERR(info->clk))
return PTR_ERR(info->clk);
@@ -327,16 +334,6 @@ static int __init tegra_rtc_probe(struct platform_device
*pdev)
device_init_wakeup(>dev, 1);
- info->rtc_dev = devm_rtc_device_register(>dev,
- dev_name(>dev), _rtc_ops,
- THIS_MODULE);
- if (IS_ERR(info->rtc_dev)) {
- ret = PTR_ERR(info->rtc_dev);
- dev_err(>dev, "Unable to register device (err=%d).\n",
- ret);
- goto disable_clk;
- }
-
ret = devm_request_irq(>dev, info->tegra_rtc_irq,
tegra_rtc_irq_handler, IRQF_TRIGGER_HIGH,
dev_name(>dev), >dev);
@@ -347,6 +344,13 @@ static int __init tegra_rtc_probe(struct platform_device
*pdev)
goto disable_clk;
}
+ ret = rtc_register_device(info->rtc_dev);
+ if (ret) {
+ dev_err(>dev, "Unable to register device (err=%d).\n",
+ ret);
+ goto disable_clk;
+ }
+
dev_notice(>dev, "Tegra internal Real Time Clock\n");
return 0;
--
2.20.1
[PATCH 2/3] rtc: tegra: switch to rtc_time64_to_tm/rtc_tm_to_time64
Call the 64bit versions of rtc_tm time conversion now that the range is
enforced by the core.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-tegra.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/rtc/rtc-tegra.c b/drivers/rtc/rtc-tegra.c
index 3f93a1f7abb5..e93092aa6f7d 100644
--- a/drivers/rtc/rtc-tegra.c
+++ b/drivers/rtc/rtc-tegra.c
@@ -123,7 +123,7 @@ static int tegra_rtc_read_time(struct device *dev, struct
rtc_time *tm)
spin_unlock_irqrestore(>tegra_rtc_lock, sl_irq_flags);
- rtc_time_to_tm(sec, tm);
+ rtc_time64_to_tm(sec, tm);
dev_vdbg(dev, "time read as %lu. %ptR\n", sec, tm);
@@ -137,7 +137,7 @@ static int tegra_rtc_set_time(struct device *dev, struct
rtc_time *tm)
int ret;
/* convert tm to seconds. */
- rtc_tm_to_time(tm, );
+ sec = rtc_tm_to_time64(tm);
dev_vdbg(dev, "time set to %lu. %ptR\n", sec, tm);
@@ -166,7 +166,7 @@ static int tegra_rtc_read_alarm(struct device *dev, struct
rtc_wkalrm *alarm)
} else {
/* alarm is enabled. */
alarm->enabled = 1;
- rtc_time_to_tm(sec, >time);
+ rtc_time64_to_tm(sec, >time);
}
tmp = readl(info->rtc_base + TEGRA_RTC_REG_INTR_STATUS);
@@ -204,7 +204,7 @@ static int tegra_rtc_set_alarm(struct device *dev, struct
rtc_wkalrm *alarm)
unsigned long sec;
if (alarm->enabled)
- rtc_tm_to_time(>time, );
+ sec = rtc_tm_to_time64(>time);
else
sec = 0;
--
2.20.1
[PATCH 3/3] rtc: tegra: convert to SPDX identifier
Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-tegra.c | 15 +-- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/drivers/rtc/rtc-tegra.c b/drivers/rtc/rtc-tegra.c index e93092aa6f7d..f0ce76865434 100644 --- a/drivers/rtc/rtc-tegra.c +++ b/drivers/rtc/rtc-tegra.c @@ -1,21 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0+ /* * An RTC driver for the NVIDIA Tegra 200 series internal RTC. * * Copyright (c) 2010, NVIDIA Corporation. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, but WITHOUT - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for - * more details. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */ #include -- 2.20.1
[PATCH 1/4] rtc: stmp3xxx: set range
>From the datasheet: "HW_RTC_SECONDS provides access to the 32-bit real-time seconds counter." Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-stmp3xxx.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/rtc/rtc-stmp3xxx.c b/drivers/rtc/rtc-stmp3xxx.c index b76318fd5bb0..a6a2963e89a5 100644 --- a/drivers/rtc/rtc-stmp3xxx.c +++ b/drivers/rtc/rtc-stmp3xxx.c @@ -361,8 +361,7 @@ static int stmp3xxx_rtc_probe(struct platform_device *pdev) STMP3XXX_RTC_CTRL_ALARM_IRQ_EN, rtc_data->io + STMP3XXX_RTC_CTRL + STMP_OFFSET_REG_CLR); - rtc_data->rtc = devm_rtc_device_register(>dev, pdev->name, - _rtc_ops, THIS_MODULE); + rtc_data->rtc = devm_rtc_allocate_device(>dev); if (IS_ERR(rtc_data->rtc)) return PTR_ERR(rtc_data->rtc); @@ -374,6 +373,13 @@ static int stmp3xxx_rtc_probe(struct platform_device *pdev) return err; } + rtc_data->rtc->ops = _rtc_ops; + rtc_data->rtc->range_max = U32_MAX; + + err = rtc_register_device(rtc_data->rtc); + if (err) + return err; + stmp3xxx_wdt_register(pdev); return 0; } -- 2.20.1
[PATCH 3/4] rtc: stmp3xxx: use .set_time
Use .set_time instead of the deprecated .set_mmss.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-stmp3xxx.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-stmp3xxx.c b/drivers/rtc/rtc-stmp3xxx.c
index dc0c6cc4849d..143486f69485 100644
--- a/drivers/rtc/rtc-stmp3xxx.c
+++ b/drivers/rtc/rtc-stmp3xxx.c
@@ -164,11 +164,11 @@ static int stmp3xxx_rtc_gettime(struct device *dev,
struct rtc_time *rtc_tm)
return 0;
}
-static int stmp3xxx_rtc_set_mmss(struct device *dev, unsigned long t)
+static int stmp3xxx_rtc_settime(struct device *dev, struct rtc_time *rtc_tm)
{
struct stmp3xxx_rtc_data *rtc_data = dev_get_drvdata(dev);
- writel(t, rtc_data->io + STMP3XXX_RTC_SECONDS);
+ writel(rtc_tm_to_time64(rtc_tm), rtc_data->io + STMP3XXX_RTC_SECONDS);
return stmp3xxx_wait_time(rtc_data);
}
@@ -233,7 +233,7 @@ static const struct rtc_class_ops stmp3xxx_rtc_ops = {
.alarm_irq_enable =
stmp3xxx_alarm_irq_enable,
.read_time = stmp3xxx_rtc_gettime,
- .set_mmss = stmp3xxx_rtc_set_mmss,
+ .set_time = stmp3xxx_rtc_settime,
.read_alarm = stmp3xxx_rtc_read_alarm,
.set_alarm = stmp3xxx_rtc_set_alarm,
};
--
2.20.1
[PATCH 2/4] rtc: stmp3xxx: switch to rtc_time64_to_tm/rtc_tm_to_time64
Call the 64bit versions of rtc_tm time conversion now that the range is
enforced by the core.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-stmp3xxx.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/rtc/rtc-stmp3xxx.c b/drivers/rtc/rtc-stmp3xxx.c
index a6a2963e89a5..dc0c6cc4849d 100644
--- a/drivers/rtc/rtc-stmp3xxx.c
+++ b/drivers/rtc/rtc-stmp3xxx.c
@@ -160,7 +160,7 @@ static int stmp3xxx_rtc_gettime(struct device *dev, struct
rtc_time *rtc_tm)
if (ret)
return ret;
- rtc_time_to_tm(readl(rtc_data->io + STMP3XXX_RTC_SECONDS), rtc_tm);
+ rtc_time64_to_tm(readl(rtc_data->io + STMP3XXX_RTC_SECONDS), rtc_tm);
return 0;
}
@@ -214,17 +214,15 @@ static int stmp3xxx_rtc_read_alarm(struct device *dev,
struct rtc_wkalrm *alm)
{
struct stmp3xxx_rtc_data *rtc_data = dev_get_drvdata(dev);
- rtc_time_to_tm(readl(rtc_data->io + STMP3XXX_RTC_ALARM), >time);
+ rtc_time64_to_tm(readl(rtc_data->io + STMP3XXX_RTC_ALARM), >time);
return 0;
}
static int stmp3xxx_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
{
- unsigned long t;
struct stmp3xxx_rtc_data *rtc_data = dev_get_drvdata(dev);
- rtc_tm_to_time(>time, );
- writel(t, rtc_data->io + STMP3XXX_RTC_ALARM);
+ writel(rtc_tm_to_time64(>time), rtc_data->io + STMP3XXX_RTC_ALARM);
stmp3xxx_alarm_irq_enable(dev, alm->enabled);
--
2.20.1
[PATCH 4/4] rtc: stmp3xxx: convert to SPDX identifier
Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-stmp3xxx.c | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/drivers/rtc/rtc-stmp3xxx.c b/drivers/rtc/rtc-stmp3xxx.c index 143486f69485..ff6488be385f 100644 --- a/drivers/rtc/rtc-stmp3xxx.c +++ b/drivers/rtc/rtc-stmp3xxx.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0+ /* * Freescale STMP37XX/STMP378X Real Time Clock driver * @@ -8,15 +9,6 @@ * Copyright 2008 Embedded Alley Solutions, Inc All Rights Reserved. * Copyright 2011 Wolfram Sang, Pengutronix e.K. */ - -/* - * The code contained herein is licensed under the GNU General Public - * License. You may obtain a copy of the GNU General Public License - * Version 2 or later at the following locations: - * - * http://www.opensource.org/licenses/gpl-license.html - * http://www.gnu.org/copyleft/gpl.html - */ #include #include #include -- 2.20.1
[PATCH 1/4] rtc: coh901331: set range
The COH 901 331 is a 32bit seconds counter.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-coh901331.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/rtc/rtc-coh901331.c b/drivers/rtc/rtc-coh901331.c
index 0b232c84f674..5b214db919d0 100644
--- a/drivers/rtc/rtc-coh901331.c
+++ b/drivers/rtc/rtc-coh901331.c
@@ -188,6 +188,13 @@ static int __init coh901331_probe(struct platform_device
*pdev)
return ret;
}
+ rtap->rtc = devm_rtc_allocate_device(>dev);
+ if (IS_ERR(rtap->rtc))
+ return PTR_ERR(rtap->rtc);
+
+ rtap->rtc->ops = _ops;
+ rtap->rtc->range_max = U32_MAX;
+
/* We enable/disable the clock only to assure it works */
ret = clk_prepare_enable(rtap->clk);
if (ret) {
@@ -197,12 +204,10 @@ static int __init coh901331_probe(struct platform_device
*pdev)
clk_disable(rtap->clk);
platform_set_drvdata(pdev, rtap);
- rtap->rtc = devm_rtc_device_register(>dev, "coh901331",
- _ops, THIS_MODULE);
- if (IS_ERR(rtap->rtc)) {
- ret = PTR_ERR(rtap->rtc);
+
+ ret = rtc_register_device(rtap->rtc);
+ if (ret)
goto out_no_rtc;
- }
return 0;
--
2.20.1
[PATCH 2/4] rtc: coh901331: switch to rtc_time64_to_tm/rtc_tm_to_time64
Call the 64bit versions of rtc_tm time conversion now that the range is
enforced by the core.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-coh901331.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/rtc/rtc-coh901331.c b/drivers/rtc/rtc-coh901331.c
index 5b214db919d0..1fd743fefe28 100644
--- a/drivers/rtc/rtc-coh901331.c
+++ b/drivers/rtc/rtc-coh901331.c
@@ -80,13 +80,14 @@ static int coh901331_read_time(struct device *dev, struct
rtc_time *tm)
clk_enable(rtap->clk);
/* Check if the time is valid */
- if (readl(rtap->virtbase + COH901331_VALID)) {
- rtc_time_to_tm(readl(rtap->virtbase + COH901331_CUR_TIME), tm);
+ if (!readl(rtap->virtbase + COH901331_VALID)) {
clk_disable(rtap->clk);
- return 0;
+ return -EINVAL;
}
+
+ rtc_time64_to_tm(readl(rtap->virtbase + COH901331_CUR_TIME), tm);
clk_disable(rtap->clk);
- return -EINVAL;
+ return 0;
}
static int coh901331_set_mmss(struct device *dev, unsigned long secs)
@@ -105,7 +106,7 @@ static int coh901331_read_alarm(struct device *dev, struct
rtc_wkalrm *alarm)
struct coh901331_port *rtap = dev_get_drvdata(dev);
clk_enable(rtap->clk);
- rtc_time_to_tm(readl(rtap->virtbase + COH901331_ALARM), >time);
+ rtc_time64_to_tm(readl(rtap->virtbase + COH901331_ALARM), >time);
alarm->pending = readl(rtap->virtbase + COH901331_IRQ_EVENT) & 1U;
alarm->enabled = readl(rtap->virtbase + COH901331_IRQ_MASK) & 1U;
clk_disable(rtap->clk);
@@ -116,9 +117,8 @@ static int coh901331_read_alarm(struct device *dev, struct
rtc_wkalrm *alarm)
static int coh901331_set_alarm(struct device *dev, struct rtc_wkalrm *alarm)
{
struct coh901331_port *rtap = dev_get_drvdata(dev);
- unsigned long time;
+ unsigned long time = rtc_tm_to_time64(>time);
- rtc_tm_to_time(>time, );
clk_enable(rtap->clk);
writel(time, rtap->virtbase + COH901331_ALARM);
writel(alarm->enabled, rtap->virtbase + COH901331_IRQ_MASK);
--
2.20.1
[PATCH 3/4] rtc: coh901331: use .set_time
Use .set_time instead of the deprecated .set_mmss.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-coh901331.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-coh901331.c b/drivers/rtc/rtc-coh901331.c
index 1fd743fefe28..bc9544329419 100644
--- a/drivers/rtc/rtc-coh901331.c
+++ b/drivers/rtc/rtc-coh901331.c
@@ -90,12 +90,12 @@ static int coh901331_read_time(struct device *dev, struct
rtc_time *tm)
return 0;
}
-static int coh901331_set_mmss(struct device *dev, unsigned long secs)
+static int coh901331_set_time(struct device *dev, struct rtc_time *tm)
{
struct coh901331_port *rtap = dev_get_drvdata(dev);
clk_enable(rtap->clk);
- writel(secs, rtap->virtbase + COH901331_SET_TIME);
+ writel(rtc_tm_to_time64(tm), rtap->virtbase + COH901331_SET_TIME);
clk_disable(rtap->clk);
return 0;
@@ -143,7 +143,7 @@ static int coh901331_alarm_irq_enable(struct device *dev,
unsigned int enabled)
static const struct rtc_class_ops coh901331_ops = {
.read_time = coh901331_read_time,
- .set_mmss = coh901331_set_mmss,
+ .set_time = coh901331_set_time,
.read_alarm = coh901331_read_alarm,
.set_alarm = coh901331_set_alarm,
.alarm_irq_enable = coh901331_alarm_irq_enable,
--
2.20.1
[PATCH 4/4] rtc: coh901331: convert to SPDX identifier
Use SPDX-License-Identifier instead of the custom license line. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-coh901331.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-coh901331.c b/drivers/rtc/rtc-coh901331.c index bc9544329419..4ac850837153 100644 --- a/drivers/rtc/rtc-coh901331.c +++ b/drivers/rtc/rtc-coh901331.c @@ -1,6 +1,6 @@ +// SPDX-License-Identifier: GPL-2.0 /* * Copyright (C) 2007-2009 ST-Ericsson AB - * License terms: GNU General Public License (GPL) version 2 * Real Time Clock interface for ST-Ericsson AB COH 901 331 RTC. * Author: Linus Walleij * Based on rtc-pl031.c by Deepak Saxena -- 2.20.1
PRINTER BUG LINUX MINT 19 TARA
Please see attached. It was working fine prior to installing Canon linux
drivers. CUPS disconnect maybe?
I am the only user. Local USB port. Just me. Canon D0550 image class.
Has worked fine in the past.
Deleted printer and reinstalled but no go.
thanks
JTK
Page 1 ():
{'cups_connection_failure': False}
Page 2 ():
{'local_server_exporting_printers': False}
Page 3 ():
{'cups_dest': ,
'cups_instance': None,
'cups_queue': 'Canon-D500-Series',
'cups_queue_listed': True}
Page 4 ():
{'cups_device_uri_scheme': 'cnusb',
'cups_printer_dict': {'device-uri': 'cnusb:/dev/usb/lp0',
'printer-info': 'Canon D500 Series',
'printer-is-shared': True,
'printer-location': 'hank-book-14',
'printer-make-and-model': 'Canon D500 Series UFRII LT',
'printer-state': 3,
'printer-state-message': '',
'printer-state-reasons': ['none'],
'printer-type': 8525012,
'printer-uri-supported':
'ipp://localhost/printers/Canon-D500-Series'},
'cups_printer_remote': False,
'is_cups_class': False,
'local_cups_queue_attributes': {'charset-configured': 'utf-8',
'charset-supported': ['us-ascii', 'utf-8'],
'color-supported': False,
'compression-supported': ['none', 'gzip'],
'copies-default': 1,
'copies-supported': (1, ),
'cups-version': '2.2.7',
'device-uri': 'cnusb:/dev/usb/lp0',
'document-format-default':
'application/octet-stream',
'document-format-supported':
['application/octet-stream',
'application/pdf',
'application/postscript',
'application/vnd.adobe-reader-postscript',
'application/vnd.cups-command',
'application/vnd.cups-pdf',
'application/vnd.cups-pdf-banner',
'application/vnd.cups-postscript',
'application/vnd.cups-raster',
'application/vnd.cups-raw',
'application/x-cshell',
'application/x-csource',
'application/x-perl',
'application/x-shell',
'image/gif',
'image/jpeg',
'image/png',
'image/pwg-raster',
'image/tiff',
'image/urf',
'image/x-bitmap',
'image/x-photocd',
'image/x-portable-anymap',
'image/x-portable-bitmap',
'image/x-portable-graymap',
'image/x-portable-pixmap',
'image/x-sgi-rgb',
'image/x-sun-raster',
'image/x-xbitmap',
'image/x-xpixmap',
'image/x-xwindowdump',
'text/css',
'text/html',
'text/plain'],
'finishings-default': 3,
'finishings-supported': [3, 51, 50],
'fitplot-default': True,
'generated-natural-language-supported':
