Re: [Patch v3 6/7] x86/PCI/ACPI: Use common interface to support PCI host bridge
On 2015/5/22 21:55, Hanjun Guo wrote:
> On 2015年05月14日 16:56, Jiang Liu wrote:
>> Use common interface to simplify ACPI PCI host bridge implementation.
>>
>> Signed-off-by: Jiang Liu
>> ---
>> arch/x86/pci/acpi.c | 292
>> +++
>> 1 file changed, 85 insertions(+), 207 deletions(-)
>>
> [...]
>> -static void release_pci_root_info(struct pci_host_bridge *bridge)
>> +static void pci_acpi_root_release_info(struct acpi_pci_root_info *ci)
>> {
>> -struct resource *res;
>> -struct resource_entry *entry;
>> -struct pci_root_info *info = bridge->release_data;
>> -
>> -resource_list_for_each_entry(entry, >windows) {
>> -res = entry->res;
>> -if (res->parent &&
>> -(res->flags & (IORESOURCE_MEM | IORESOURCE_IO)))
>> -release_resource(res);
>> -}
>> -
>> -teardown_mcfg_map(info);
>> -kfree(info);
>> +teardown_mcfg_map(ci);
>> +kfree(ci);
>
> Implicit pointer cast? I think add a comment here that %p of ci
> is same as %p of info would be helpful for review and easy understood.
Good point, will change as:
kfree(container_of(ci, struct pci_root_info, common));
Thanks!
Gerry
>
> other than that,
>
> Reviewed-by: Hanjun Guo
>
> Thanks
> Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/debug: Remove perpetually broken, unmaintainable dwarf annotations
* Andy Lutomirski wrote: > On Mon, Jun 1, 2015 at 12:45 PM, Josh Poimboeuf wrote: > > On Fri, May 29, 2015 at 10:47:31AM -0700, Andy Lutomirski wrote: > >> On Thu, May 28, 2015 at 6:17 AM, Ingo Molnar wrote: > >> > > >> > * Jan Beulich wrote: > >> > > >> >> > and meanwhile you can keep a revert of this patch ported to SUSE > >> >> > kernels in > >> >> > whatever fashion you prefer. > >> >> > >> >> Funny suggestion - I don't think that's reasonable for us to do. Or if > >> >> we were > >> >> to, we could as well invest in doing the re-work you're asking for; I > >> >> don't > >> >> think anyone will have the time to do either. > >> > > >> > That's fair enough: if there's not enough resources to keep a feature > >> > maintainable > >> > upstream then it should not be upstream in that form. > >> > > >> > This isn't just some driver we can let bit-rot in peace until it finds a > >> > maintainer (or not), without affecting anyone but users of that driver. > >> > > >> > This is hundreds of usage sites of ugly code intermixed with critical > >> > pieces of > >> > assembly code that negatively affects the hackability of everything. > >> > > >> > Also, with the feature missing completely, maybe someone finds a method > >> > to > >> > introduce it in a maintainable fashion, while with the feature included > >> > upstream > >> > there's very little pressure to do that. As a bonus we'd also win a > >> > workable dwarf > >> > unwinder. > >> > >> Before doing something drastic like this, I think we should get Josh's > >> opinion, since I think he's working on a new (?) unwinder. > >> > >> FWIW, musl is considering some kind of automatic annotation scheme: > >> > >> http://www.openwall.com/lists/musl/2015/05/13/5 > > > > Thanks for the link! I found a newer version of it here: > > > > http://www.openwall.com/lists/musl/2015/05/31/5 > > > > Overall I think that script is a really good solution. > > > > From what I can tell, it tracks the CFA (stack pointer) perfectly. > > (Which is actually pretty straightfoward if you just hook into function > > entry/exit, push/pop, and add/sub to rsp). > > > > It also does a nice job at making a best effort at tracking the caller's > > register values (which are less important than CFA but still nice to > > have). > > It might be nice to be able to reliably unwind out from an exception / > interrupt > / syscall frame into userspace or into the kernel code that trapped, complete > with registers. > > In any event, we'll almost certainly have to manually annotate these weird > types > of entries. I wonder if we could manage to annotate just the entry parts and > let a magic script do the rest. Even the entry parts we could help without uglifying the code: - either by adding a 'RET' instruction after IRET/SYSRET/SYSEXIT/etc. that the tooling can recognize as 'return from function'. That's much nicer than ugly annotations. - enhancing the tooling script to also recognize these instructions as function returns - because they _are_ function returns. So I'll commit the removal patch - it's clear at this point that the old annotations won't be used and they are actively getting in the way of bug fixes and new work. This became glaringly obvious during and after the big asm code refresh we did in v4.1. If anyone needs debuginfo badly (who?) then they should help Josh get it all upstream again ASAP, it doesn't seem much is missing to get all that done in a much cleaner way. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vTPM: set virtual device before passing to ibmvtpm_reset_crq
Thanks for the patch. Looks good to me.
Reviewed-by: Ashley Lai
--Ashley Lai
On Fri, 22 May 2015, Hon Ching(Vicky) Lo wrote:
tpm_ibmvtpm_probe() calls ibmvtpm_reset_crq(ibmvtpm) without having yet
set the virtual device in the ibmvtpm structure. So in ibmvtpm_reset_crq,
the phype call contains empty unit addresses, ibmvtpm->vdev->unit_address.
Signed-off-by: Hon Ching(Vicky) Lo
Signed-off-by: Joy Latten
---
drivers/char/tpm/tpm_ibmvtpm.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index 42ffa5e..27ebf95 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -578,6 +578,9 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
goto cleanup;
}
+ ibmvtpm->dev = dev;
+ ibmvtpm->vdev = vio_dev;
+
crq_q = >crq_queue;
crq_q->crq_addr = (struct ibmvtpm_crq *)get_zeroed_page(GFP_KERNEL);
if (!crq_q->crq_addr) {
@@ -622,8 +625,6 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
crq_q->index = 0;
- ibmvtpm->dev = dev;
- ibmvtpm->vdev = vio_dev;
TPM_VPRIV(chip) = (void *)ibmvtpm;
spin_lock_init(>rtce_lock);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [RFC] arm: Add for atomic half word exchange
I made the CONFIG_ARCH_MULTI_V6=y and
CONFIG_CPU_V6K=y
CONFIG_CPU_32v6=y
CONFIG_CPU_32v6K=y
and compiled 4.0.4 with the patch. Result is a compilation success.
Regards,
Sarbojit
--- Original Message ---
Sender : Arnd Bergmann
Date : May 19, 2015 18:51 (GMT+09:00)
Title : Re: [RFC] arm: Add for atomic half word exchange
On Tuesday 19 May 2015 09:39:33 Sarbojit Ganguly wrote:
> Since 16 bit half word exchange was not there and MCS based qspinlock by
> Waiman's xchg_tail() requires an atomic exchange on a half word,
> here is a small modification to __xchg() code.
We have discussed a similar patch before, see
https://lkml.org/lkml/2015/2/25/390
> #if __LINUX_ARM_ARCH__ >= 6
> @@ -50,6 +52,23 @@
> : "r" (x), "r" (ptr)
> : "memory", "cc");
> break;
> + /*
> +* halfword exclusive exchange
> +* This is new implementation as qspinlock
> +* wants 16 bit atomic CAS.
> +*/
> + case 2:
> + asm volatile("@ __xchg2\n"
> + "1: ldrexh %0, [%3]\n"
> + " strexh %1, %2, [%3]\n"
> + " teq %1, #0\n"
> + " bne 1b"
> + : "=" (ret), "=" (tmp)
> + : "r" (x), "r" (ptr)
> + : "memory", "cc");
> + break;
> case 4:
> asm volatile("@ __xchg4\n"
> "1: ldrex %0, [%3]\n"
Please try to find a way to make this compile when CONFIG_CPU_V6
is set.
Arnd
Re: MIPS/IRQCHIP: some remainders of IRQ_CPU
Hi Ralf,
thanks for your answer.
On Mon, Jun 1, 2015 at 9:53 PM, Ralf Baechle wrote:
> On Mon, Jun 01, 2015 at 04:51:48PM +0200, Valentin Rothberg wrote:
>
>> Hi Ralf,
>>
>> your commit 1f1786e60b53 ("MIPS/IRQCHIP: Move irq_chip from arch/mips
>> to drivers/irqchip.") is in today's linux-next tree (i.e.,
>> next-20150601). It renames the Kconfig option IRQ_CPU to
>> IRQ_MIPS_CPU, but misses to rename a few Kconfig selects (see git
>> grep) in arch/mips.
>>
>> If you agree, I can send a trivial patch that renames those remainders?
>
> sed -i -e 's@\bIRQ_CPU\b@IRQ_MIPS_CPU@' $(git grep -l -w IRQ_CPU)
>
> or something like that.
I am not sure if you want me to send a patch, do you?
Kind regards,
Valentin
>> I detected the issue with ./scripts/checkkconfigsymbols.py by diffing
>> the last and today's linux tree.
>>
>> Some advertisement for a small tool I started a few month a go, which
>> is made for such cases. With vgrep [1] you can grep for symbols in
>> the current directory tree and afterwards open specific lines in your
>> editor. It's more or less a comfortable wrapper around (git) grep. I
>> use it a lot to study source code as well as to manage code changes.
>> The most prominent user I know is Greg KH who uses it as a replacement
>> for cgvg.
>>
>> Kind regards,
>> Valentin
>>
>> [1] https://github.com/vrothberg/vgrep
>
> Thanks for reporting!
>
> Ralf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] kprobes/x86: Use 16 bytes for each instruction slot again
* Eugene Shatokhin wrote:
> Commit 91e5ed49fca0 ("x86/asm/decoder: Fix and enforce max instruction
> size in the insn decoder") has changed MAX_INSN_SIZE from 16 to 15 bytes
> on x86.
>
> As a side effect, the slots Kprobes use to store the instructions became
> 1 byte shorter. This is unfortunate because, for example, the Kprobes'
> "boost" feature can not be used now for the instructions of length 11,
> like a quite common kind of MOV:
> * movq $0x,-0x3fe8(%rax) (48 c7 80 18 c0 ff ff ff ff ff ff)
> * movq $0x0,0x88(%rdi) (48 c7 87 88 00 00 00 00 00 00 00)
> and so on.
>
> This patch makes the insn slots 16 bytes long, like they were before while
> keeping MAX_INSN_SIZE intact.
>
> Other tools may benefit from this change as well.
>
> Signed-off-by: Eugene Shatokhin
> ---
> arch/x86/include/asm/kprobes.h | 1 +
> arch/x86/kernel/kprobes/core.c | 2 +-
> kernel/kprobes.c | 8 ++--
> 3 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/include/asm/kprobes.h b/arch/x86/include/asm/kprobes.h
> index 4421b5d..f3f0b4e 100644
> --- a/arch/x86/include/asm/kprobes.h
> +++ b/arch/x86/include/asm/kprobes.h
> @@ -27,6 +27,7 @@
> #include
>
> #define __ARCH_WANT_KPROBES_INSN_SLOT
> +#define KPROBE_INSN_SLOT_SIZE 16
Naming aside, it's totally unacceptable to add a define like this with no
explanation in the code at all.
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -90,6 +89,11 @@ static raw_spinlock_t *kretprobe_table_lock_ptr(unsigned
> long hash)
> static LIST_HEAD(kprobe_blacklist);
>
> #ifdef __ARCH_WANT_KPROBES_INSN_SLOT
> +
> +#ifndef KPROBE_INSN_SLOT_SIZE
> +#define KPROBE_INSN_SLOT_SIZE MAX_INSN_SIZE
> +#endif
Ditto. There's no explanation, no way for an arch maintainer to find out
whether
to redefine this or not.
This adds some magic logic that is just as likely to break in the future as the
old code did. This series needs to fix the primary cause (==poorly documented,
illogical code), not just the symptom/bug.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [v3,33/36] genirq: Use helper function to access irq_data->msi_desc
On 2015/6/2 11:45, Michael Ellerman wrote: > On Mon, 2015-01-06 at 08:05:42 UTC, Jiang Liu wrote: >> Use irq_data access helper to access irq_data->msi_desc, so we could >> move msi_desc from struct irq_data into struct irq_common_data later. >> >> Signed-off-by: Jiang Liu >> --- >> arch/powerpc/sysdev/xics/ics-opal.c |2 +- >> arch/powerpc/sysdev/xics/ics-rtas.c |2 +- >> >> diff --git a/arch/powerpc/sysdev/xics/ics-opal.c >> b/arch/powerpc/sysdev/xics/ics-opal.c >> index 3996393c254d..27c936c080a6 100644 >> --- a/arch/powerpc/sysdev/xics/ics-opal.c >> +++ b/arch/powerpc/sysdev/xics/ics-opal.c >> @@ -72,7 +72,7 @@ static unsigned int ics_opal_startup(struct irq_data *d) >> * card, using the MSI mask bits. Firmware doesn't appear to unmask >> * at that level, so we do it here by hand. >> */ >> -if (d->msi_desc) >> +if (irq_data_get_msi_desc(d)) >> pci_msi_unmask_irq(d); >> #endif >> >> diff --git a/arch/powerpc/sysdev/xics/ics-rtas.c >> b/arch/powerpc/sysdev/xics/ics-rtas.c >> index e2665a9dfc0f..3854dd41558d 100644 >> --- a/arch/powerpc/sysdev/xics/ics-rtas.c >> +++ b/arch/powerpc/sysdev/xics/ics-rtas.c >> @@ -75,7 +75,7 @@ static unsigned int ics_rtas_startup(struct irq_data *d) >> * card, using the MSI mask bits. Firmware doesn't appear to unmask >> * at that level, so we do it here by hand. >> */ >> -if (d->msi_desc) >> +if (irq_data_get_msi_desc(d)) >> pci_msi_unmask_irq(d); >> #endif >> /* unmask it */ > > These look OK. > > Though I would point out we already have 16 irq_foo_get_bar() accessors?! Hi Michael, Thanks for review. We are trying to solve some issues introduced by hierarchy irqdomain/irqchip by splitting irq_data into a common part (irq_common_data) and per-chip part(irq_data). These accessors are used to ease the transition and hide implementation details. Thanks! Gerry > > Acked-by: Michael Ellerman > > cheers > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] kprobes/x86: Use 16 bytes for each instruction slot again
* Masami Hiramatsu wrote:
> On 2015/06/02 2:04, Andy Lutomirski wrote:
> > On Mon, Jun 1, 2015 at 9:32 AM, Eugene Shatokhin
> > wrote:
> >> Commit 91e5ed49fca0 ("x86/asm/decoder: Fix and enforce max instruction
> >> size in the insn decoder") has changed MAX_INSN_SIZE from 16 to 15 bytes
> >> on x86.
> >>
> >> As a side effect, the slots Kprobes use to store the instructions became
> >> 1 byte shorter. This is unfortunate because, for example, the Kprobes'
> >> "boost" feature can not be used now for the instructions of length 11,
> >> like a quite common kind of MOV:
> >> * movq $0x,-0x3fe8(%rax) (48 c7 80 18 c0 ff ff ff ff ff ff)
> >> * movq $0x0,0x88(%rdi) (48 c7 87 88 00 00 00 00 00 00 00)
> >> and so on.
> >>
> >> This patch makes the insn slots 16 bytes long, like they were before while
> >> keeping MAX_INSN_SIZE intact.
> >>
> >> Other tools may benefit from this change as well.
> >
> > What is a "slot" and why does this patch make sense? Naively, I'd
> > expect that the check you're patching is entirely unnecessary -- I
> > don't see what the size of the instruction being probed has to do with
> > the safety of executing it out of line and then jumping back.
> >
> > Is there another magic 16 somewhere that this is enforcing that we
> > don't overrun?
>
> The kprobe-"booster" adds a jump back code (jmp length>)
> right after the instruction in the out-of-code buffer(slot). So we need at
> least
> the insn-length + 5 bytes for the slot, it's the trick of the magic :)
Please at minimum rename it to 'dynamic code buffer' or some other sensible
name -
the name 'slot' is pretty meaningless at best and misleading at worst.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] cpufreq/hotplug: Fix cpu-hotplug cpufreq race conditions
On 02-06-15, 11:01, Preeti U Murthy wrote: > How will a policy lock help here at all, when cpus from multiple > policies are calling into __cpufreq_governor() ? How will a policy lock > serialize their entry into cpufreq_governor_dbs() ? So different policies don't really depend on each other. The only thing common to them are the governor's sysfs files (only if governor-per-policy isn't set, i.e. in your case). Those sysfs files and their kernel counterpart variables aren't touched unless all the policies have EXITED. All these START/STOP calls touch only the data relevant to those policies only. In case of per-policy governors, even those sysfs files are separate for each policy. And so a policy lock should be sufficient, rest should be handled within the governors with locks or whatever. > > These band-aid wouldn't take us anywhere. > > Why do you say that the approach mentioned in this patch is a bandaid ? > The patch ensures that there are no interruptions in a logical sequence > of calls into cpufreq_governor_dbs(), as it should be. Because this happened as we are forced to drop the policy-locks. That's the real problem. This whole thing should be performed under locks, instead of setting variables to mark governor busy under locks. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] staging: rtl8192u: ieee80211: Fix sparse endianness warnings
On Mon, Jun 01, 2015 at 09:43:31PM -0300, Gaston Gonzalez wrote: > Fix the following sparse warnings: > > drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c > b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c > index d2e8b12..d0a6a59 100644 > --- a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c > +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c > @@ -660,8 +660,10 @@ inline struct sk_buff > *ieee80211_authentication_req(struct ieee80211_network *be > auth = (struct ieee80211_authentication *) > skb_put(skb, sizeof(struct ieee80211_authentication)); > > - auth->header.frame_ctl = IEEE80211_STYPE_AUTH; > - if (challengelen) auth->header.frame_ctl |= IEEE80211_FCTL_WEP; > + if (challengelen) > + auth->header.frame_ctl = cpu_to_le16(IEEE80211_STYPE_AUTH | > IEEE80211_FCTL_WEP); it is introducing new checkpatch warning of "line over 80 characters". regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/urgent] x86/asm/entry/32, selftests: Add a selftest for kernel entries from VM86 mode
Commit-ID: c2affbf9a50882572e04645d5946ab0a921f061f
Gitweb: http://git.kernel.org/tip/c2affbf9a50882572e04645d5946ab0a921f061f
Author: Andy Lutomirski
AuthorDate: Fri, 29 May 2015 14:58:24 -0700
Committer: Ingo Molnar
CommitDate: Sat, 30 May 2015 10:21:32 +0200
x86/asm/entry/32, selftests: Add a selftest for kernel entries from VM86 mode
Test a couple of special cases in 32-bit kernels for entries
from vm86 mode. This will OOPS both old kernels due to a bug
and and 4.1-rc5 due to a regression I introduced, and it should
make sure that the SYSENTER-from-vm86-mode hack in the kernel
keeps working.
Signed-off-by: Andy Lutomirski
Cc: Jan Beulich
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Shuah Khan
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/09a9916761e0a9e42d4922f147af45a0079cc1e8.1432936374.git.l...@kernel.org
Tests: 394838c96013 x86/asm/entry/32: Fix user_mode() misuses
Tests: 7ba554b5ac69 x86/asm/entry/32: Really make user_mode() work correctly
for VM86 mode
Signed-off-by: Ingo Molnar
---
tools/testing/selftests/x86/Makefile | 6 +-
tools/testing/selftests/x86/entry_from_vm86.c | 114 ++
2 files changed, 118 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/x86/Makefile
b/tools/testing/selftests/x86/Makefile
index 5bdb781..9b0d8ba 100644
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@ -5,8 +5,10 @@ include ../lib.mk
.PHONY: all all_32 all_64 warn_32bit_failure clean
TARGETS_C_BOTHBITS := sigreturn single_step_syscall
+TARGETS_C_32BIT_ONLY := entry_from_vm86
-BINARIES_32 := $(TARGETS_C_BOTHBITS:%=%_32)
+TARGETS_C_32BIT_ALL := $(TARGETS_C_BOTHBITS) $(TARGETS_C_32BIT_ONLY)
+BINARIES_32 := $(TARGETS_C_32BIT_ALL:%=%_32)
BINARIES_64 := $(TARGETS_C_BOTHBITS:%=%_64)
CFLAGS := -O2 -g -std=gnu99 -pthread -Wall
@@ -32,7 +34,7 @@ all_64: $(BINARIES_64)
clean:
$(RM) $(BINARIES_32) $(BINARIES_64)
-$(TARGETS_C_BOTHBITS:%=%_32): %_32: %.c
+$(TARGETS_C_32BIT_ALL:%=%_32): %_32: %.c
$(CC) -m32 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl
$(TARGETS_C_BOTHBITS:%=%_64): %_64: %.c
diff --git a/tools/testing/selftests/x86/entry_from_vm86.c
b/tools/testing/selftests/x86/entry_from_vm86.c
new file mode 100644
index 000..5c38a18
--- /dev/null
+++ b/tools/testing/selftests/x86/entry_from_vm86.c
@@ -0,0 +1,114 @@
+/*
+ * entry_from_vm86.c - tests kernel entries from vm86 mode
+ * Copyright (c) 2014-2015 Andrew Lutomirski
+ *
+ * This exercises a few paths that need to special-case vm86 mode.
+ *
+ * GPL v2.
+ */
+
+#define _GNU_SOURCE
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static unsigned long load_addr = 0x1;
+static int nerrs = 0;
+
+asm (
+ ".pushsection .rodata\n\t"
+ ".type vmcode_bound, @object\n\t"
+ "vmcode:\n\t"
+ "vmcode_bound:\n\t"
+ ".code16\n\t"
+ "bound %ax, (2048)\n\t"
+ "int3\n\t"
+ "vmcode_sysenter:\n\t"
+ "sysenter\n\t"
+ ".size vmcode, . - vmcode\n\t"
+ "end_vmcode:\n\t"
+ ".code32\n\t"
+ ".popsection"
+ );
+
+extern unsigned char vmcode[], end_vmcode[];
+extern unsigned char vmcode_bound[], vmcode_sysenter[];
+
+static void do_test(struct vm86plus_struct *v86, unsigned long eip,
+ const char *text)
+{
+ long ret;
+
+ printf("[RUN]\t%s from vm86 mode\n", text);
+ v86->regs.eip = eip;
+ ret = vm86(VM86_ENTER, v86);
+
+ if (ret == -1 && errno == ENOSYS) {
+ printf("[SKIP]\tvm86 not supported\n");
+ return;
+ }
+
+ if (VM86_TYPE(ret) == VM86_INTx) {
+ char trapname[32];
+ int trapno = VM86_ARG(ret);
+ if (trapno == 13)
+ strcpy(trapname, "GP");
+ else if (trapno == 5)
+ strcpy(trapname, "BR");
+ else if (trapno == 14)
+ strcpy(trapname, "PF");
+ else
+ sprintf(trapname, "%d", trapno);
+
+ printf("[OK]\tExited vm86 mode due to #%s\n", trapname);
+ } else if (VM86_TYPE(ret) == VM86_UNKNOWN) {
+ printf("[OK]\tExited vm86 mode due to unhandled GP fault\n");
+ } else {
+ printf("[OK]\tExited vm86 mode due to type %ld, arg %ld\n",
+ VM86_TYPE(ret), VM86_ARG(ret));
+ }
+}
+
+int main(void)
+{
+ struct vm86plus_struct v86;
+ unsigned char *addr = mmap((void *)load_addr, 4096,
+ PROT_READ | PROT_WRITE | PROT_EXEC,
+ MAP_ANONYMOUS | MAP_PRIVATE, -1,0);
+ if (addr != (unsigned char *)load_addr)
+ err(1, "mmap");
+
+ memcpy(addr, vmcode, end_vmcode - vmcode);
+ addr[2048] = 2;
+ addr[2050] = 3;
+
+
Re: [RFC PATCH] cpufreq/hotplug: Fix cpu-hotplug cpufreq race conditions
On 06/01/2015 12:49 PM, Viresh Kumar wrote:
> On 01-06-15, 01:40, Preeti U Murthy wrote:
>
> I have to mention that this is somewhat inspired by:
>
> https://git.linaro.org/people/viresh.kumar/linux.git/commit/1e37f1d6ae12f5896e4e216f986762c3050129a5
>
> and I was waiting to finish some core-changes to make all this simple.
>
> I am fine to you trying to finish it though :)
>
>> The problem showed up when running hotplug operations and changing
>> governors in parallel. The crash would be at:
>>
>> [ 174.319645] Unable to handle kernel paging request for data at address
>> 0x
>> [ 174.319782] Faulting instruction address: 0xc053b3e0
>> cpu 0x1: Vector: 300 (Data Access) at [c3fdb870]
>> pc: c053b3e0: __bitmap_weight+0x70/0x100
>> lr: c085a338: need_load_eval+0x38/0xf0
>> sp: c3fdbaf0
>>msr: 90019033
>>dar: 0
>> dsisr: 4000
>> current = 0xc3151a40
>> paca= 0xc7da0980softe: 0irq_happened: 0x01
>> pid = 842, comm = kworker/1:2
>> enter ? for help
>> [c3fdbb40] c085a338 need_load_eval+0x38/0xf0
>> [c3fdbb70] c0856a10 od_dbs_timer+0x90/0x1e0
>> [c3fdbbe0] c00f489c process_one_work+0x24c/0x910
>> [c3fdbc90] c00f50dc worker_thread+0x17c/0x540
>> [c3fdbd20] c00fed70 kthread+0x120/0x140
>> [c3fdbe30] c0009678 ret_from_kernel_thread+0x5c/0x64
>>
>> While debugging the issue, other problems in this area were uncovered,
>> all of them necessitating serialized calls to __cpufreq_governor(). One
>> potential race condition that can happen today is the below:
>>
>> CPU0 CPU1
>>
>> cpufreq_set_policy()
>>
>> __cpufreq_governor
>> (CPUFREQ_GOV_POLICY_EXIT)
>> __cpufreq_remove_dev_finish()
>>
>> free(dbs_data) __cpufreq_governor
>> (CPUFRQ_GOV_START)
>>
>> dbs_data->mutex <= NULL dereference
>>
>> The issue here is that calls to cpufreq_governor_dbs() is not serialized
>> and they can conflict with each other in numerous ways. One way to sort
>> this out would be to serialize all calls to cpufreq_governor_dbs()
>> by setting the governor busy if a call is in progress and
>> blocking all other calls. But this approach will not cover all loop
>> holes. Take the above scenario: CPU1 will still hit a NULL dereference if
>> care is not taken to check for a NULL dbs_data.
>>
>> To sort such scenarios, we could filter out the sequence of events: A
>> CPUFREQ_GOV_START cannot be called without an INIT, if the previous
>> event was an EXIT. However this results in analysing all possible
>> sequence of events and adding each of them as a filter. This results in
>> unmanagable code. There is high probability of missing out on a race
>> condition. Both the above approaches were tried out earlier [1]
>
> I agree.
>
>> Let us therefore look at the heart of the issue.
>
> Yeah, we should :)
>
>> It is not really about
>> serializing calls to cpufreq_governor_dbs(), it seems to be about
>> serializing entire sequence of CPUFREQ_GOV* operations. For instance, in
>> cpufreq_set_policy(), we STOP,EXIT the old policy and INIT and START the
>> new policy. Between the EXIT and INIT, there must not be
>> anybody else starting the policy. And between INIT and START, there must
>> be nobody stopping the policy.
>
> Hmm..
>
>> A similar argument holds for the CPUFREQ_GOV* operations in
>> __cpufreq_policy_dev_{prepare|finish} and cpufreq_add_policy(). Hence
>> until each of these functions complete in totality, none of the others
>> should run in parallel. The interleaving of the individual calls to
>> cpufreq_governor_dbs() is resulting in invalid operations. This patch
>> therefore tries to serialize entire cpufreq functions calling CPUFREQ_GOV*
>> operations, with respect to each other.
>
> We were forced to put band-aids until this time and I am really
> looking into getting this fixed at the root.
>
> The problem is that we drop policy locks before calling
> __cpufreq_governor() and that's the root cause of all these problems
> we are facing. We did that because we were getting warnings about
> circular locks (955ef4833574 ("cpufreq: Drop rwsem lock around
> CPUFREQ_GOV_POLICY_EXIT"))..
>
> I have explained that problem here (Never sent this upstream, as I was
> waiting for some other patches to get included first):
> https://git.linaro.org/people/viresh.kumar/linux.git/commit/57714d5b1778f2f610bcc5c74d85b29ba1cc1995
>
> The actual problem was:
> If we hold any locks, that the attribute operations grab, when
> removing the attribute, then it can result in a ABBA deadlock.
>
> show()/store() holds the policy->rwsem lock while accessing any sysfs
> attributes under cpu/cpuX/cpufreq/ directory.
>
> But something like what I have done is the real way to tackle all
>
[PATCH] clk: mediatek: Add MT8173 MMPLL change rate support
MT8173 MMPLL frequency settings are different from common PLLs.
It needs different post divider settings for some ranges of frequency.
This patch add support for MT8173 MMPLL frequency setting, includes:
1. Add div-rate table for PLLs.
2. Increase the max ost divider setting from 3 (/8) to 4 (/16).
3. Write postdiv and pcw settings at the same time.
Signed-off-by: James Liao
---
drivers/clk/mediatek/clk-mt8173.c | 24 +---
drivers/clk/mediatek/clk-mtk.h| 1 +
drivers/clk/mediatek/clk-pll.c| 37 +
3 files changed, 47 insertions(+), 15 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mt8173.c
b/drivers/clk/mediatek/clk-mt8173.c
index 357b080..821de7d 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -779,8 +779,9 @@ CLK_OF_DECLARE(mtk_pericfg, "mediatek,mt8173-pericfg",
mtk_pericfg_init);
#define CON0_MT8173_RST_BARBIT(24)
-#define PLL(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _pcwbits, _pd_reg,
_pd_shift, \
- _tuner_reg, _pcw_reg, _pcw_shift) { \
+#define PLL_B(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _pcwbits, \
+ _pd_reg, _pd_shift, _tuner_reg, _pcw_reg, \
+ _pcw_shift, _div_rate) {\
.id = _id, \
.name = _name, \
.reg = _reg,\
@@ -795,14 +796,31 @@ CLK_OF_DECLARE(mtk_pericfg, "mediatek,mt8173-pericfg",
mtk_pericfg_init);
.tuner_reg = _tuner_reg,\
.pcw_reg = _pcw_reg,\
.pcw_shift = _pcw_shift,\
+ .div_rate = _div_rate, \
}
+#define PLL(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _pcwbits,\
+ _pd_reg, _pd_shift, _tuner_reg, _pcw_reg, \
+ _pcw_shift) \
+ PLL_B(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _pcwbits, \
+ _pd_reg, _pd_shift, _tuner_reg, _pcw_reg, _pcw_shift, \
+ NULL)
+
+const unsigned long mmpll_div_rate[] = {
+ MT8173_PLL_FMAX,
+ 10,
+ 70200,
+ 25350,
+ 12675,
+ 0,
+};
+
static const struct mtk_pll_data plls[] = {
PLL(CLK_APMIXED_ARMCA15PLL, "armca15pll", 0x200, 0x20c, 0x0001, 0,
21, 0x204, 24, 0x0, 0x204, 0),
PLL(CLK_APMIXED_ARMCA7PLL, "armca7pll", 0x210, 0x21c, 0x0001, 0,
21, 0x214, 24, 0x0, 0x214, 0),
PLL(CLK_APMIXED_MAINPLL, "mainpll", 0x220, 0x22c, 0xf101,
HAVE_RST_BAR, 21, 0x220, 4, 0x0, 0x224, 0),
PLL(CLK_APMIXED_UNIVPLL, "univpll", 0x230, 0x23c, 0xfe01,
HAVE_RST_BAR, 7, 0x230, 4, 0x0, 0x234, 14),
- PLL(CLK_APMIXED_MMPLL, "mmpll", 0x240, 0x24c, 0x0001, 0, 21, 0x244,
24, 0x0, 0x244, 0),
+ PLL_B(CLK_APMIXED_MMPLL, "mmpll", 0x240, 0x24c, 0x0001, 0, 21,
0x244, 24, 0x0, 0x244, 0, mmpll_div_rate),
PLL(CLK_APMIXED_MSDCPLL, "msdcpll", 0x250, 0x25c, 0x0001, 0, 21,
0x250, 4, 0x0, 0x254, 0),
PLL(CLK_APMIXED_VENCPLL, "vencpll", 0x260, 0x26c, 0x0001, 0, 21,
0x260, 4, 0x0, 0x264, 0),
PLL(CLK_APMIXED_TVDPLL, "tvdpll", 0x270, 0x27c, 0x0001, 0, 21,
0x270, 4, 0x0, 0x274, 0),
diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
index 61035b9..645af7c 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -150,6 +150,7 @@ struct mtk_pll_data {
int pcwbits;
uint32_t pcw_reg;
int pcw_shift;
+ const unsigned long *div_rate;
};
void __init mtk_clk_register_plls(struct device_node *node,
diff --git a/drivers/clk/mediatek/clk-pll.c b/drivers/clk/mediatek/clk-pll.c
index 44409e9..4680a09 100644
--- a/drivers/clk/mediatek/clk-pll.c
+++ b/drivers/clk/mediatek/clk-pll.c
@@ -90,20 +90,23 @@ static unsigned long __mtk_pll_recalc_rate(struct
mtk_clk_pll *pll, u32 fin,
static void mtk_pll_set_rate_regs(struct mtk_clk_pll *pll, u32 pcw,
int postdiv)
{
- u32 con1, pd, val;
+ u32 con1, val;
int pll_en;
- /* set postdiv */
- pd = readl(pll->pd_addr);
- pd &= ~(POSTDIV_MASK << pll->data->pd_shift);
- pd |= (ffs(postdiv) - 1) << pll->data->pd_shift;
- writel(pd, pll->pd_addr);
-
pll_en = readl(pll->base_addr + REG_CON0) & CON0_BASE_EN;
- /* set pcw */
- val = readl(pll->pcw_addr);
+ /* set postdiv */
+ val = readl(pll->pd_addr);
+ val &= ~(POSTDIV_MASK << pll->data->pd_shift);
+ val |= (ffs(postdiv) - 1) << pll->data->pd_shift;
+
+ /* postdiv and pcw need to set at the same time if on same register */
Re: [PATCH 2/3 v4] Staging: rtl8192u: Remove two useless lines at ieee80211_wep_null
On Tue, Jun 02, 2015 at 12:19:12AM +0200, pmarzo wrote:
> On Sun, 2015-05-31 at 10:39 +0900, Greg KH wrote:
> > On Thu, May 21, 2015 at 02:25:18AM +0200, Pedro Marzo Perez wrote:
> > > Remove two lines at ieee80211_wep_null which checkpatch.pl reported as
> > > errors.
> > > The first one because it has a C99 comment style and the second one
> > > because it is a void
> > > return which is useless.
> > >
> > > Signed-off-by: Pedro Marzo Perez
> > > ---
> > > drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c | 2 --
> > > 1 file changed, 2 deletions(-)
> > >
> > > diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
> > > b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
> > > index bd789d1..94622cc 100644
> > > --- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
> > > +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
> > > @@ -279,6 +279,4 @@ void __exit ieee80211_crypto_wep_exit(void)
> > >
> > > void ieee80211_wep_null(void)
> > > {
> > > -// printk(">%s()\n", __func__);
> > > - return;
> > > }
> >
> > Please just delete the function.
>
> It is not so easy, the function is exported at file
> drivers/staging/rtl8192u/ieee80211/ieee80211.h and used at
> drivers/staging/rtl8192u/ieee80211/ieee80211_module.c line 179 with
> several other "null" functions, it seems a dirty trick to force module
> loading:
> /* These function were added to load crypte module autoly */
> ieee80211_tkip_null();
> ieee80211_wep_null();
> ieee80211_ccmp_null();
>
> I guess all this stuff should be rewritten to force the autoload
> properly but I don't have the knowledge to fix all this.
> Sorry Greg :-(
Ugh, that's a mess. Ok, I'll take this patch again, please resend it.
thanks,
greg k-h
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/12] wilc1000: dead code removal and other cleanup
On Tue, Jun 02, 2015 at 01:53:31PM +0900, Greg KH wrote: > On Mon, Jun 01, 2015 at 09:06:33PM +0200, Arnd Bergmann wrote: > > Hi Greg, > > > > Next try, I've rebased on top of your staging-testing branch > > and fixed the two build errors. > > > > While I had done my normal build testing on the driver (a few > > hundred randconfig builds), I don't normally do 'make clean', > > so the stale Makefile entry ended up picking the old object > > files and succeeding with that. > > Thanks, I've applied these but there are still a bunch of warnings. > It's obvious no one has ever built this code on a 64bit processor > (Atmel, come on, not all the world is 32bits...) > > I'll take a pass at it to see if I can clean up some stuff to maybe > reduce the number of warnings, but right now, it's still way too many > for linux-next to want to enable as it blows up their logs... Ugh, that's a rabbit hole you can disappear into for a long time. I did a few patches but ran out of time, I can spend days mucking down in there unwinding the mess... Johnny, Rachel, Dean, and Chris, can you all fix up all of the build warnings as soon as possible? Take my tree and work off of that, just build it on your desktop 64bit Linux build and get rid of all of them properly and send me the patches. Hopefully by the end of this week so that linux-next can get some testing with this driver enabled. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: rtl8192u: Patch to modify if, else conditions
On Sun, May 31, 2015 at 10:38:18AM +0900, gre...@linuxfoundation.org wrote: > On Tue, May 19, 2015 at 04:55:57PM +, Dhere, Chaitanya (C.) wrote: > > In this patch: > > 1. the if condition is modified to remove > > the unnecessary equality check. > > 2. The else if condition is replaced by an else condition > > since the variable checked in the if statement is a bool > > making the else if unnecessary. > > 3. Fixed indentation problem on line 1369. > > These changes were detected with help of coccinelle tool. > > 3 different things means you need to send 3 different patches. Please > only do one logical thing per patch. > > thanks, > > greg k-h Hello, I will make the correction in subject and resend the patch Thanks, chaitanya -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] mfd: 88pm800: allocate pdata->rtc if not allocated earlier
On Monday 01 June 2015 01:52 PM, Lee Jones wrote:
On Sat, 30 May 2015, Vaibhav Hiremath wrote:
RTC in pmic 88PM800 can run even the core is powered off, and user
can set alarm in RTC. When the alarm is timed out, the PMIC will power up
the core, and the whole system will boot up. And during PMIC driver probe,
it will read some register to find out whether this boot is caused by RTC
timeout or not, and pass on this information to the RTC driver.
So we need rtc platform data to be existed in PMIC driver to pass this
information.
Signed-off-by: Chao Xie
Signed-off-by: Vaibhav Hiremath
---
drivers/mfd/88pm800.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index 8ea4467..34546a1 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -586,6 +586,25 @@ static int pm800_probe(struct i2c_client *client,
return ret;
}
+ /*
+* RTC in pmic can run even the core is powered off, and user can set
+* alarm in RTC. When the alarm is time out, the PMIC will power up
+* the core, and the whole system will boot up. When PMIC driver is
+* probed, it will read out some register to find out whether this
+* boot is caused by RTC timeout or not, and it need pass this
+* information to RTC driver.
+* So we need rtc platform data to be existed to pass this information.
+*/
+ if (!pdata->rtc) {
+ pdata->rtc = devm_kzalloc(>dev,
+ sizeof(*(pdata->rtc)), GFP_KERNEL);
+ if (!pdata->rtc) {
+ dev_err(>dev,
+ "failed to allocate memory for rtc\n");
+ return -ENOMEM;
+ }
+ }
+
Where is this memory first used?
In the same file, look for field "rtc_wakeup".
FYI,
This field is used in two files,
drivers/mfd/88pm800.c
and
drivers/rtc/rtc-88pm800.c [sets the "platform_data" field]
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ASoC: qcom: Remove QCOM dependency from LPASS variants
From: Kenneth Westfield
Remove the dependency on SND_SOC_QCOM from the user-
invisible LPASS variant options. This will fix
randconfig build errors.
Reported-by: Jim Davis
Fixes: dc1ebd1811e9 ("ASoC: qcom: Add apq8016 lpass driver support")
Fixes: 9bae4880acee ("ASoC: qcom: move ipq806x specific bits out of lpass
driver")
Signed-off-by: Kenneth Westfield
---
Created fix in response to Jim's bug report:
http://mailman.alsa-project.org/pipermail/alsa-devel/2015-May/092870.html
Note: I did some searching but didn't see an example of a fix for the
same type of bug introduced by 2 commits. If this needs to be split into
two fixes, let me know.
sound/soc/qcom/Kconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
index 29fff6d..10837bd 100644
--- a/sound/soc/qcom/Kconfig
+++ b/sound/soc/qcom/Kconfig
@@ -14,13 +14,11 @@ config SND_SOC_LPASS_PLATFORM
config SND_SOC_LPASS_IPQ806X
tristate
- depends on SND_SOC_QCOM
select SND_SOC_LPASS_CPU
select SND_SOC_LPASS_PLATFORM
config SND_SOC_LPASS_APQ8016
tristate
- depends on SND_SOC_QCOM
select SND_SOC_LPASS_CPU
select SND_SOC_LPASS_PLATFORM
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH kernel v11 34/34] vfio: powerpc/spapr: Support Dynamic DMA windows
On Fri, May 29, 2015 at 06:44:58PM +1000, Alexey Kardashevskiy wrote: > This adds create/remove window ioctls to create and remove DMA windows. > sPAPR defines a Dynamic DMA windows capability which allows > para-virtualized guests to create additional DMA windows on a PCI bus. > The existing linux kernels use this new window to map the entire guest > memory and switch to the direct DMA operations saving time on map/unmap > requests which would normally happen in a big amounts. > > This adds 2 ioctl handlers - VFIO_IOMMU_SPAPR_TCE_CREATE and > VFIO_IOMMU_SPAPR_TCE_REMOVE - to create and remove windows. > Up to 2 windows are supported now by the hardware and by this driver. > > This changes VFIO_IOMMU_SPAPR_TCE_GET_INFO handler to return additional > information such as a number of supported windows and maximum number > levels of TCE tables. > > DDW is added as a capability, not as a SPAPR TCE IOMMU v2 unique feature > as we still want to support v2 on platforms which cannot do DDW for > the sake of TCE acceleration in KVM (coming soon). > > Signed-off-by: Alexey Kardashevskiy > [aw: for the vfio related changes] > Acked-by: Alex Williamson Reviewed-by: David Gibson -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpV2Dns2ZlUx.pgp Description: PGP signature
Re: [PATCH v2 1/4] staging: wilc1000: Fix some compile time warnings
On Mon, Jun 01, 2015 at 09:56:18PM +0300, Stanislav Kholmanskikh wrote: > Signed-off-by: Stanislav Kholmanskikh > --- > Changes since V1: > > Split the V1 series into more logically unrelated patches > and updated patch descriptions accordingly. This series doesn't apply on my tree due to other changes from someone else that I just took. Can you rebase it and resend? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/12] wilc1000: dead code removal and other cleanup
On Mon, Jun 01, 2015 at 09:06:33PM +0200, Arnd Bergmann wrote: > Hi Greg, > > Next try, I've rebased on top of your staging-testing branch > and fixed the two build errors. > > While I had done my normal build testing on the driver (a few > hundred randconfig builds), I don't normally do 'make clean', > so the stale Makefile entry ended up picking the old object > files and succeeding with that. Thanks, I've applied these but there are still a bunch of warnings. It's obvious no one has ever built this code on a 64bit processor (Atmel, come on, not all the world is 32bits...) I'll take a pass at it to see if I can clean up some stuff to maybe reduce the number of warnings, but right now, it's still way too many for linux-next to want to enable as it blows up their logs... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the clockevents tree with the arm tree
Hi Daniel,
Today's linux-next merge of the clockevents tree got a conflict in
drivers/clocksource/Makefile between commit 5261ef2ea836 ("ARM: 8366/1:
move Dual-Timer SP804 driver to drivers/clocksource") from the arm tree
and commit 17b85e25f282 ("clocksource/drivers/armv7m_systick: Add ARM
System timer driver") from the clockevents tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/clocksource/Makefile
index 12ec793f7fff,06919b619084..
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@@ -45,7 -46,7 +47,8 @@@ obj-$(CONFIG_MTK_TIMER) += mtk_timer.
obj-$(CONFIG_ARM_ARCH_TIMER) += arm_arch_timer.o
obj-$(CONFIG_ARM_GLOBAL_TIMER)+= arm_global_timer.o
+obj-$(CONFIG_ARM_TIMER_SP804) += timer-sp804.o
+ obj-$(CONFIG_ARMV7M_SYSTICK) += armv7m_systick.o
obj-$(CONFIG_CLKSRC_METAG_GENERIC)+= metag_generic.o
obj-$(CONFIG_ARCH_HAS_TICK_BROADCAST) += dummy_timer.o
obj-$(CONFIG_ARCH_KEYSTONE) += timer-keystone.o
pgpPIBSeOPEGY.pgp
Description: OpenPGP digital signature
Re: [PATCH 3/6] PM / OPP: Support adjusting OPP voltages at runtime
On 01-06-15, 18:47, Stephen Boyd wrote: > +int dev_pm_opp_adjust_voltage(struct device *dev, unsigned long freq, > +unsigned long u_volt); > +static inline int dev_pm_opp_adjust_voltage(struct device *dev, > + unsigned long freq, unsigned long u_volt) The 'u' of 'unsigned' isn't aligned to the opening curly brace. Try running with checkpatch --strict and you will see some warnings. Otherwise, Acked-by: Viresh Kumar -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH kernel v11 33/34] vfio: powerpc/spapr: Register memory and define IOMMU v2
On Fri, May 29, 2015 at 06:44:57PM +1000, Alexey Kardashevskiy wrote: > The existing implementation accounts the whole DMA window in > the locked_vm counter. This is going to be worse with multiple > containers and huge DMA windows. Also, real-time accounting would requite > additional tracking of accounted pages due to the page size difference - > IOMMU uses 4K pages and system uses 4K or 64K pages. > > Another issue is that actual pages pinning/unpinning happens on every > DMA map/unmap request. This does not affect the performance much now as > we spend way too much time now on switching context between > guest/userspace/host but this will start to matter when we add in-kernel > DMA map/unmap acceleration. > > This introduces a new IOMMU type for SPAPR - VFIO_SPAPR_TCE_v2_IOMMU. > New IOMMU deprecates VFIO_IOMMU_ENABLE/VFIO_IOMMU_DISABLE and introduces > 2 new ioctls to register/unregister DMA memory - > VFIO_IOMMU_SPAPR_REGISTER_MEMORY and VFIO_IOMMU_SPAPR_UNREGISTER_MEMORY - > which receive user space address and size of a memory region which > needs to be pinned/unpinned and counted in locked_vm. > New IOMMU splits physical pages pinning and TCE table update > into 2 different operations. It requires: > 1) guest pages to be registered first > 2) consequent map/unmap requests to work only with pre-registered memory. > For the default single window case this means that the entire guest > (instead of 2GB) needs to be pinned before using VFIO. > When a huge DMA window is added, no additional pinning will be > required, otherwise it would be guest RAM + 2GB. > > The new memory registration ioctls are not supported by > VFIO_SPAPR_TCE_IOMMU. Dynamic DMA window and in-kernel acceleration > will require memory to be preregistered in order to work. > > The accounting is done per the user process. > > This advertises v2 SPAPR TCE IOMMU and restricts what the userspace > can do with v1 or v2 IOMMUs. > > In order to support memory pre-registration, we need a way to track > the use of every registered memory region and only allow unregistration > if a region is not in use anymore. So we need a way to tell from what > region the just cleared TCE was from. > > This adds a userspace view of the TCE table into iommu_table struct. > It contains userspace address, one per TCE entry. The table is only > allocated when the ownership over an IOMMU group is taken which means > it is only used from outside of the powernv code (such as VFIO). > > Signed-off-by: Alexey Kardashevskiy > [aw: for the vfio related changes] > Acked-by: Alex Williamson > --- > Changes: > v11: > * mm_iommu_put() does not return a code so this does not check it > * moved "v2" in tce_container to pack the struct > > v10: > * moved it_userspace allocation to vfio_iommu_spapr_tce as it VFIO > specific thing > * squashed "powerpc/iommu: Add userspace view of TCE table" into this as > it is > a part of IOMMU v2 > * s/tce_iommu_use_page_v2/tce_iommu_prereg_ua_to_hpa/ > * fixed some function names to have "tce_iommu_" in the beginning rather > just "tce_" > * as mm_iommu_mapped_inc() can now fail, check for the return code > > v9: > * s/tce_get_hva_cached/tce_iommu_use_page_v2/ > > v7: > * now memory is registered per mm (i.e. process) > * moved memory registration code to powerpc/mmu > * merged "vfio: powerpc/spapr: Define v2 IOMMU" into this > * limited new ioctls to v2 IOMMU > * updated doc > * unsupported ioclts return -ENOTTY instead of -EPERM > > v6: > * tce_get_hva_cached() returns hva via a pointer > > v4: > * updated docs > * s/kzmalloc/vzalloc/ > * in tce_pin_pages()/tce_unpin_pages() removed @vaddr, @size and > replaced offset with index > * renamed vfio_iommu_type_register_memory to vfio_iommu_spapr_register_memory > and removed duplicating vfio_iommu_spapr_register_memory > --- > Documentation/vfio.txt | 31 ++- > arch/powerpc/include/asm/iommu.h| 6 + > drivers/vfio/vfio_iommu_spapr_tce.c | 512 > ++-- > include/uapi/linux/vfio.h | 27 ++ > 4 files changed, 487 insertions(+), 89 deletions(-) > > diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt > index 96978ec..7dcf2b5 100644 > --- a/Documentation/vfio.txt > +++ b/Documentation/vfio.txt > @@ -289,10 +289,12 @@ PPC64 sPAPR implementation note > > This implementation has some specifics: > > -1) Only one IOMMU group per container is supported as an IOMMU group > -represents the minimal entity which isolation can be guaranteed for and > -groups are allocated statically, one per a Partitionable Endpoint (PE) > +1) On older systems (POWER7 with P5IOC2/IODA1) only one IOMMU group per > +container is supported as an IOMMU table is allocated at the boot time, > +one table per a IOMMU group which is a Partitionable Endpoint (PE) > (PE is often a PCI domain but not always). > +Newer systems (POWER8 with IODA2) have improved hardware design which allows > +to remove this limitation and have multiple IOMMU
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On 1 June 2015 at 22:52, Tony Lindgren wrote: > OK that must be the case I've seen then. Probably that happens > when a device is not clocked. It happens for any interconnect error reported as a result of instruction fetch, but that is itself not a very common occurrence and obviously doesn't apply to device memory. Another case where the L3 error irq may be taken first is if the bus error is asynchronous, but I don't think this combo can be produced on a dm81xx or am335x, but that's mainly due to the strictly in-order Cortex-A8 making almost every abort synchronous. I'd expect async aborts are more common on an A9. > Hmm well it should be just MT_DEVICE for anything Linux ioremaps.. Yikes, so both /dev/mem and uio are behaving unlike any device driver: both use remap_pfn_range() after running the vm_page_prot though pgprot_noncached() to set the memory type to L_PTE_MT_UNCACHED, which counterintuitively turns out to mean strongly-ordered. o.O Especially uio is acting inappropriate here imho. But this is problematic... these ranges are already mapped by the kernel, and ARM explicitly forbids mapping the same physical range twice with different memory attributes (and it's not the only architecture to do so). Hmmz... Anyhow, drifting a bit off-topic here. I'm going to some more reading and thinking about this. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 3/7] ARM64: add SBSA Generic Watchdog device node in amd-seattle-soc.dtsi
From: Fu Wei
This can be a example of adding SBSA Generic Watchdog device node
into some dts files for the Soc which contains SBSA Generic Watchdog.
Acked-by: Arnd Bergmann
Acked-by: Suravee Suthikulpanit
Tested-by: Suravee Suthikulpanit
Signed-off-by: Fu Wei
---
arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index 2874d92..95994eb 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -84,6 +84,17 @@
clock-names = "uartclk", "apb_pclk";
};
+ watchdog0: watchdog@e0bb {
+ compatible = "arm,sbsa-gwdt";
+ reg = <0x0 0xe0bb 0 0x1>,
+ <0x0 0xe0bc 0 0x1>;
+ reg-names = "refresh",
+ "control";
+ interrupts = <0 337 4>;
+ interrupt-names = "ws0";
+ timeout-sec = <10 5>;
+ };
+
spi0: ssp@e102 {
status = "disabled";
compatible = "arm,pl022", "arm,primecell";
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 5/7] Watchdog: introduce ARM SBSA watchdog driver
From: Fu Wei
This driver bases on linux kernel watchdog framework, and
use "pretimeout" in the framework. It supports getting timeout and
pretimeout from parameter and FDT at the driver init stage.
In first timeout, the interrupt routine run panic to save
system context.
Signed-off-by: Fu Wei
---
drivers/watchdog/Kconfig | 12 ++
drivers/watchdog/Makefile| 1 +
drivers/watchdog/sbsa_gwdt.c | 426 +++
3 files changed, 439 insertions(+)
create mode 100644 drivers/watchdog/sbsa_gwdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index e5e7c55..20f9980 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -152,6 +152,18 @@ config ARM_SP805_WATCHDOG
ARM Primecell SP805 Watchdog timer. This will reboot your system when
the timeout is reached.
+config ARM_SBSA_WATCHDOG
+ tristate "ARM SBSA Generic Watchdog"
+ depends on ARM64
+ depends on ARM_ARCH_TIMER
+ select WATCHDOG_CORE
+ select ACPI_GTDT if ACPI
+ help
+ ARM SBSA Generic Watchdog. This watchdog has two Watchdog timeouts.
+ The first timeout will trigger a panic; the second timeout will
+ trigger a system reset.
+ More details: ARM DEN0029B - Server Base System Architecture (SBSA)
+
config AT91RM9200_WATCHDOG
tristate "AT91RM9200 watchdog"
depends on SOC_AT91RM9200 && MFD_SYSCON
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 5c19294..471f1b7c 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
# ARM Architecture
obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
+obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o
obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o
obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o
obj-$(CONFIG_CADENCE_WATCHDOG) += cadence_wdt.o
diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
new file mode 100644
index 000..76b6763
--- /dev/null
+++ b/drivers/watchdog/sbsa_gwdt.c
@@ -0,0 +1,426 @@
+/*
+ * SBSA(Server Base System Architecture) Generic Watchdog driver
+ *
+ * Copyright (c) 2015, Linaro Ltd.
+ * Author: Fu Wei
+ * Suravee Suthikulpanit
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License 2 as published
+ * by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * Note: This SBSA Generic watchdog driver is compatible with
+ * the pretimeout concept of Linux kernel.
+ * The timeout and pretimeout are set by the different REGs.
+ * The first watch period is set by writing WCV directly,
+ * that can support more than 10s timeout at the maximum
+ * system counter frequency.
+ * The second watch period is set by WOR(32bit) which will be loaded
+ * automatically by hardware, when WS0 is triggered.
+ * This gives a maximum watch period of around 10s at the maximum
+ * system counter frequency.
+ * The System Counter shall run at maximum of 400MHz.
+ * More details: ARM DEN0029B - Server Base System Architecture (SBSA)
+ *
+ * Kernel/API: P-| pretimeout
+ * |---T timeout
+ * SBSA GWDT: P--WOR---WS1 pretimeout
+ * |---WCV--WS0T timeout
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* SBSA Generic Watchdog register definitions */
+/* refresh frame */
+#define SBSA_GWDT_WRR 0x000
+
+/* control frame */
+#define SBSA_GWDT_WCS 0x000
+#define SBSA_GWDT_WOR 0x008
+#define SBSA_GWDT_WCV_LO 0x010
+#define SBSA_GWDT_WCV_HI 0x014
+
+/* refresh/control frame */
+#define SBSA_GWDT_W_IIDR 0xfcc
+#define SBSA_GWDT_IDR 0xfd0
+
+/* Watchdog Control and Status Register */
+#define SBSA_GWDT_WCS_EN BIT(0)
+#define SBSA_GWDT_WCS_WS0 BIT(1)
+#define SBSA_GWDT_WCS_WS1 BIT(2)
+
+/**
+ * struct sbsa_gwdt - Internal representation of the SBSA GWDT
+ * @wdd: kernel watchdog_device structure
+ * @clk: store the System Counter clock frequency, in Hz.
+ * @refresh_base: Virtual address of the watchdog refresh frame
+ * @control_base: Virtual address of the watchdog control frame
+ */
+struct sbsa_gwdt {
+ struct watchdog_device wdd;
+ u32 clk;
+
[PATCH v4 6/7] ACPI: add GTDT table parse driver into ACPI driver
From: Fu Wei
This driver adds support for parsing SBSA Generic Watchdog
Structure in GTDT, and creating a platform device with that
information. This allows the operating system to obtain device
data from the resource of platform device.
The platform device named "sbsa-gwdt" can be used by the
ARM SBSA Generic Watchdog driver.
Signed-off-by: Fu Wei
Signed-off-by: Hanjun Guo
---
drivers/acpi/Kconfig | 9
drivers/acpi/Makefile | 1 +
drivers/acpi/gtdt.c | 137 ++
3 files changed, 147 insertions(+)
create mode 100644 drivers/acpi/gtdt.c
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 1bbaa3d..e125698 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -433,4 +433,13 @@ config XPOWER_PMIC_OPREGION
endif
+config ACPI_GTDT
+ bool "ACPI GTDT Support"
+ depends on ARM64
+ help
+ GTDT (Generic Timer Description Table) provides information
+ for per-processor timers and Platform (memory-mapped) timers
+ for ARM platforms. Select this option to provide information
+ needed for the timers init.
+
endif # ACPI
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 431e587..2c5a194 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -96,3 +96,4 @@ obj-$(CONFIG_ACPI_EXTLOG) += acpi_extlog.o
obj-$(CONFIG_PMIC_OPREGION)+= pmic/intel_pmic.o
obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o
obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o
+obj-$(CONFIG_ACPI_GTDT)+= gtdt.o
diff --git a/drivers/acpi/gtdt.c b/drivers/acpi/gtdt.c
new file mode 100644
index 000..a92abf2
--- /dev/null
+++ b/drivers/acpi/gtdt.c
@@ -0,0 +1,137 @@
+/*
+ * ARM Specific GTDT table Support
+ *
+ * Copyright (C) 2015, Linaro Ltd.
+ * Author: Fu Wei
+ * Hanjun Guo
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int __init map_generic_timer_interrupt(u32 interrupt, u32 flags)
+{
+ int trigger, polarity;
+
+ if (!interrupt)
+ return 0;
+
+ trigger = (flags & ACPI_GTDT_INTERRUPT_MODE) ? ACPI_EDGE_SENSITIVE
+ : ACPI_LEVEL_SENSITIVE;
+
+ polarity = (flags & ACPI_GTDT_INTERRUPT_POLARITY) ? ACPI_ACTIVE_LOW
+ : ACPI_ACTIVE_HIGH;
+
+ return acpi_register_gsi(NULL, interrupt, trigger, polarity);
+}
+
+/*
+ * Initialize a SBSA generic Watchdog platform device info from GTDT
+ * According to SBSA specification the size of refresh and control
+ * frames of SBSA Generic Watchdog is SZ_4K(Offset 0x000 – 0xFFF).
+ */
+static int __init gtdt_import_sbsa_gwdt(struct acpi_gtdt_watchdog *wd,
+ int index)
+{
+ struct platform_device *pdev;
+ int irq = map_generic_timer_interrupt(wd->timer_interrupt,
+ wd->timer_flags);
+ struct resource res[] = {
+ DEFINE_RES_IRQ_NAMED(irq, "ws0"),
+ DEFINE_RES_MEM_NAMED(wd->refresh_frame_address, SZ_4K,
+"refresh"),
+ DEFINE_RES_MEM_NAMED(wd->control_frame_address, SZ_4K,
+"control"),
+ };
+
+ pr_debug("GTDT: a Watchdog GT(0x%llx/0x%llx gsi:%u flags:0x%x)\n",
+wd->refresh_frame_address, wd->control_frame_address,
+wd->timer_interrupt, wd->timer_flags);
+
+ if (!(wd->refresh_frame_address &&
+ wd->control_frame_address &&
+ wd->timer_interrupt)) {
+ pr_err("GTDT: failed geting the device info.\n");
+ return -EINVAL;
+ }
+
+ if (irq < 0) {
+ pr_err("GTDT: failed to register GSI of the Watchdog GT.\n");
+ return -EINVAL;
+ }
+
+ /*
+* Add a platform device named "sbsa-gwdt" to match the platform driver.
+* "sbsa-gwdt": SBSA(Server Base System Architecture) Generic Watchdog
+* The platform driver (like drivers/watchdog/sbsa_gwdt.c)can get device
+* info below by matching this name.
+*/
+ pdev = platform_device_register_simple("sbsa-gwdt", index, res,
+ ARRAY_SIZE(res));
+ if (IS_ERR(pdev)) {
+ acpi_unregister_gsi(wd->timer_interrupt);
+ return PTR_ERR(pdev);
+ }
+
+ return 0;
+}
+
+static int __init gtdt_platform_timer_parse(struct acpi_table_header *table)
+{
+ struct acpi_gtdt_header *header;
+ struct acpi_table_gtdt *gtdt;
+ void *gtdt_subtable;
+ int i, gwdt_index;
+ int ret = 0;
+
+ if (table->revision < 2) {
+ pr_warn("GTDT: Revision:%d doesn't
[PATCH v4 1/7] Documentation: add sbsa-gwdt.txt documentation
From: Fu Wei
The sbsa-gwdt.txt documentation in devicetree/bindings/watchdog is for
introducing SBSA(Server Base System Architecture) Generic Watchdog
device node info into FDT.
Acked-by: Arnd Bergmann
Signed-off-by: Fu Wei
---
.../devicetree/bindings/watchdog/sbsa-gwdt.txt | 36 ++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
new file mode 100644
index 000..010e5c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
@@ -0,0 +1,36 @@
+* SBSA(Server Base System Architecture) Generic Watchdog
+
+The SBSA Generic Watchdog Timer is used for resetting the system after
+two stages of timeout.
+More details: ARM-DEN-0029 - Server Base System Architecture (SBSA)
+
+Required properties:
+- compatible : Should at least contain "arm,sbsa-gwdt".
+
+- reg : base physical address of the frames and length of memory mapped region.
+
+- reg-names : Should contain the resource reg names to show the order of
+ the values in "reg".
+ Must include the following entries : "refresh", "control".
+
+- interrupts : Should at least contain WS0 interrupt,
+ the WS1 Signal is optional.
+
+- interrupt-names : Should contain the resource interrupt names.
+ Must include the following entries : "ws0". "ws1" is optional.
+
+Optional properties
+- timeout-sec : Watchdog pre-timeout and timeout values (in seconds).
+ The first is timeout values, then pre-timeout.
+
+Example for FVP Foundation Model v8:
+
+watchdog@2a44 {
+ compatible = "arm,sbsa-gwdt";
+ reg = <0x0 0x2a44 0 0x1>,
+ <0x0 0x2a45 0 0x1>;
+ reg-names = "control", "refresh";
+ interrupts = <0 27 4>;
+ interrupt-names = "ws0";
+ timeout-sec = <10 5>;
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 7/7] clocksource: simplify ACPI code in arm_arch_timer.c
From: Fu Wei
The patch update arm_arch_timer driver to use the function
provided by the new GTDT driver of ACPI.
By this way, arm_arch_timer.c can be simplified, and separate
all the ACPI GTDT knowledge from this timer driver.
Signed-off-by: Fu Wei
Signed-off-by: Hanjun Guo
---
arch/arm64/kernel/time.c | 4 +--
drivers/acpi/gtdt.c | 43 ++
drivers/clocksource/Kconfig | 1 +
drivers/clocksource/arm_arch_timer.c | 60 +++-
include/clocksource/arm_arch_timer.h | 8 +
include/linux/acpi.h | 5 +++
include/linux/clocksource.h | 4 +--
7 files changed, 72 insertions(+), 53 deletions(-)
diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
index 42f9195..2cabea6 100644
--- a/arch/arm64/kernel/time.c
+++ b/arch/arm64/kernel/time.c
@@ -75,9 +75,9 @@ void __init time_init(void)
/*
* Since ACPI or FDT will only one be available in the system,
-* we can use acpi_generic_timer_init() here safely
+* we can use arch_timer_acpi_init() here safely
*/
- acpi_generic_timer_init();
+ arch_timer_acpi_init();
arch_timer_rate = arch_timer_get_rate();
if (!arch_timer_rate)
diff --git a/drivers/acpi/gtdt.c b/drivers/acpi/gtdt.c
index a92abf2..699c9fd 100644
--- a/drivers/acpi/gtdt.c
+++ b/drivers/acpi/gtdt.c
@@ -17,6 +17,8 @@
#include
#include
+#include
+
static int __init map_generic_timer_interrupt(u32 interrupt, u32 flags)
{
int trigger, polarity;
@@ -33,6 +35,47 @@ static int __init map_generic_timer_interrupt(u32 interrupt,
u32 flags)
return acpi_register_gsi(NULL, interrupt, trigger, polarity);
}
+struct arch_timer_data __initdata *arch_timer_data_p;
+
+static int __init arch_timer_data_init(struct acpi_table_header *table)
+{
+ struct acpi_table_gtdt *gtdt;
+
+ gtdt = container_of(table, struct acpi_table_gtdt, header);
+
+ arch_timer_data_p->phys_secure_ppi =
+ map_generic_timer_interrupt(gtdt->secure_el1_interrupt,
+ gtdt->secure_el1_flags);
+
+ arch_timer_data_p->phys_nonsecure_ppi =
+ map_generic_timer_interrupt(gtdt->non_secure_el1_interrupt,
+ gtdt->non_secure_el1_flags);
+
+ arch_timer_data_p->virt_ppi =
+ map_generic_timer_interrupt(gtdt->virtual_timer_interrupt,
+ gtdt->virtual_timer_flags);
+
+ arch_timer_data_p->hyp_ppi =
+ map_generic_timer_interrupt(gtdt->non_secure_el2_interrupt,
+ gtdt->non_secure_el2_flags);
+
+ arch_timer_data_p->c3stop = !(gtdt->non_secure_el1_flags &
+ ACPI_GTDT_ALWAYS_ON);
+
+ return 0;
+}
+
+/* Initialize the arch_timer_data struct for arm_arch_timer by GTDT info */
+int __init gtdt_arch_timer_data_init(struct arch_timer_data *data)
+{
+ if (acpi_disabled || !data)
+ return -EINVAL;
+
+ arch_timer_data_p = data;
+
+ return acpi_table_parse(ACPI_SIG_GTDT, arch_timer_data_init);
+}
+
/*
* Initialize a SBSA generic Watchdog platform device info from GTDT
* According to SBSA specification the size of refresh and control
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 51d7865f..ea94a6f 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -109,6 +109,7 @@ config CLKSRC_EFM32
config ARM_ARCH_TIMER
bool
select CLKSRC_OF if OF
+ select ACPI_GTDT if ACPI
config ARM_ARCH_TIMER_EVTSTREAM
bool "Support for ARM architected timer event stream generation"
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index 0aa135d..99505bb 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -817,68 +817,30 @@ CLOCKSOURCE_OF_DECLARE(armv7_arch_timer_mem,
"arm,armv7-timer-mem",
arch_timer_mem_init);
#ifdef CONFIG_ACPI
-static int __init map_generic_timer_interrupt(u32 interrupt, u32 flags)
-{
- int trigger, polarity;
-
- if (!interrupt)
- return 0;
-
- trigger = (flags & ACPI_GTDT_INTERRUPT_MODE) ? ACPI_EDGE_SENSITIVE
- : ACPI_LEVEL_SENSITIVE;
-
- polarity = (flags & ACPI_GTDT_INTERRUPT_POLARITY) ? ACPI_ACTIVE_LOW
- : ACPI_ACTIVE_HIGH;
-
- return acpi_register_gsi(NULL, interrupt, trigger, polarity);
-}
-
/* Initialize per-processor generic timer */
-static int __init arch_timer_acpi_init(struct acpi_table_header *table)
+void __init arch_timer_acpi_init(void)
{
- struct acpi_table_gtdt *gtdt;
+ struct arch_timer_data data;
if (arch_timers_present & ARCH_CP15_TIMER) {
pr_warn("arch_timer: already initialized,
[PATCH v4 4/7] Watchdog: introdouce "pretimeout" into framework
From: Fu Wei
Also update Documentation/watchdog/watchdog-kernel-api.txt to
introduce:
(1)the new elements in the watchdog_device and watchdog_ops struct;
(2)the new API "watchdog_init_timeouts"
Reasons:
(1)kernel already has two watchdog drivers are using "pretimeout":
drivers/char/ipmi/ipmi_watchdog.c
drivers/watchdog/kempld_wdt.c(but the definition is different)
(2)some other drivers are going to use this: ARM SBSA Generic Watchdog
Signed-off-by: Fu Wei
---
Documentation/watchdog/watchdog-kernel-api.txt | 47 --
drivers/watchdog/watchdog_core.c | 115 +++--
drivers/watchdog/watchdog_dev.c| 53
include/linux/watchdog.h | 33 ++-
4 files changed, 212 insertions(+), 36 deletions(-)
diff --git a/Documentation/watchdog/watchdog-kernel-api.txt
b/Documentation/watchdog/watchdog-kernel-api.txt
index a0438f3..95b355d 100644
--- a/Documentation/watchdog/watchdog-kernel-api.txt
+++ b/Documentation/watchdog/watchdog-kernel-api.txt
@@ -49,6 +49,9 @@ struct watchdog_device {
unsigned int timeout;
unsigned int min_timeout;
unsigned int max_timeout;
+ unsigned int pretimeout;
+ unsigned int min_pretimeout;
+ unsigned int max_pretimeout;
void *driver_data;
struct mutex lock;
unsigned long status;
@@ -70,6 +73,9 @@ It contains following fields:
* timeout: the watchdog timer's timeout value (in seconds).
* min_timeout: the watchdog timer's minimum timeout value (in seconds).
* max_timeout: the watchdog timer's maximum timeout value (in seconds).
+* pretimeout: the watchdog timer's pretimeout value (in seconds).
+* min_pretimeout: the watchdog timer's minimum pretimeout value (in seconds).
+* max_pretimeout: the watchdog timer's maximum pretimeout value (in seconds).
* bootstatus: status of the device after booting (reported with watchdog
WDIOF_* status bits).
* driver_data: a pointer to the drivers private data of a watchdog device.
@@ -92,6 +98,7 @@ struct watchdog_ops {
int (*ping)(struct watchdog_device *);
unsigned int (*status)(struct watchdog_device *);
int (*set_timeout)(struct watchdog_device *, unsigned int);
+ int (*set_pretimeout)(struct watchdog_device *, unsigned int);
unsigned int (*get_timeleft)(struct watchdog_device *);
void (*ref)(struct watchdog_device *);
void (*unref)(struct watchdog_device *);
@@ -153,9 +160,19 @@ they are supported. These optional routines/operations are:
and -EIO for "could not write value to the watchdog". On success this
routine should set the timeout value of the watchdog_device to the
achieved timeout value (which may be different from the requested one
- because the watchdog does not necessarily has a 1 second resolution).
+ because the watchdog does not necessarily has a 1 second resolution;
+ If the driver supports pretimeout, then the timeout value must be greater
+ than that).
(Note: the WDIOF_SETTIMEOUT needs to be set in the options field of the
watchdog's info structure).
+* set_pretimeout: this routine checks and changes the pretimeout of the
+ watchdog timer device. It returns 0 on success, -EINVAL for "parameter out of
+ range" and -EIO for "could not write value to the watchdog". On success this
+ routine should set the pretimeout value of the watchdog_device to the
+ achieved pretimeout value (which may be different from the requested one
+ because the watchdog does not necessarily has a 1 second resolution).
+ (Note: the WDIOF_PRETIMEOUT needs to be set in the options field of the
+ watchdog's info structure).
* get_timeleft: this routines returns the time that's left before a reset.
* ref: the operation that calls kref_get on the kref of a dynamically
allocated watchdog_device struct.
@@ -219,8 +236,28 @@ extern int watchdog_init_timeout(struct watchdog_device
*wdd,
unsigned int timeout_parm, struct device
*dev);
The watchdog_init_timeout function allows you to initialize the timeout field
-using the module timeout parameter or by retrieving the timeout-sec property
from
-the device tree (if the module timeout parameter is invalid). Best practice is
-to set the default timeout value as timeout value in the watchdog_device and
-then use this function to set the user "preferred" timeout value.
+using the module timeout parameter or by retrieving the first element of
+the timeout-sec property from the device tree (if the module timeout parameter
+is invalid). Best practice is to set the default timeout value as timeout value
+in the watchdog_device and then use this function to set the user "preferred"
+timeout value.
+This routine returns zero on success and a negative errno code for failure.
+
+Some watchdog timers have two stage of timeouts(timeout and pretimeout),
+to initialize the timeout and pretimeout fields at the same time, the following
[PATCH v4 2/7] ARM64: add SBSA Generic Watchdog device node in foundation-v8.dts
From: Fu Wei
This can be a example of adding SBSA Generic Watchdog device node
into some dts files for the Soc which contains SBSA Generic Watchdog.
Acked-by: Arnd Bergmann
Signed-off-by: Fu Wei
---
arch/arm64/boot/dts/arm/foundation-v8.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/arm/foundation-v8.dts
b/arch/arm64/boot/dts/arm/foundation-v8.dts
index 4eac8dc..962a07e 100644
--- a/arch/arm64/boot/dts/arm/foundation-v8.dts
+++ b/arch/arm64/boot/dts/arm/foundation-v8.dts
@@ -237,4 +237,14 @@
};
};
};
+ watchdog@2a44 {
+ compatible = "arm,sbsa-gwdt";
+ reg = <0x0 0x2a44 0 0x1>,
+ <0x0 0x2a45 0 0x1>;
+ reg-names = "control",
+ "refresh";
+ interrupts = <0 27 4>;
+ interrupt-names = "ws0";
+ timeout-sec = <10 5>;
+ };
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/7] Watchdog: introduce ARM SBSA watchdog driver
From: Fu Wei This patchset: (1)Introduce Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt for FDT info of SBSA Generic Watchdog, and give two examples of adding SBSA Generic Watchdog device node into the dts files: foundation-v8.dts and amd-seattle-soc.dtsi. (2)Introduce ACPI GTDT parser: drivers/acpi/gtdt.c Parse SBSA Generic Watchdog Structure in GTDT table of ACPI, and create a platform device with that information. This platform device can be used by This Watchdog driver. drivers/clocksource/arm_arch_timer.c is simplified by this GTDT support. (3)Introduce "pretimeout" into the watchdog framework, and update Documentation/watchdog/watchdog-kernel-api.txt to introduce: (1)the new elements in the watchdog_device and watchdog_ops struct; (2)the new API "watchdog_init_timeouts". (4)Introduce ARM SBSA watchdog driver: a.Use linux kernel watchdog framework; b.Work with FDT on ARM64; c.Use "pretimeout" in watchdog framework; d.In first timeout, do panic to save system context; e.Support getting timeout and pretimeout from parameter and FDT at the driver init stage. This patchset has been tested with watchdog daemon (ACPI/FDT, module/build-in) on the following platforms: (1)ARM Foundation v8 model Changelog: v4: Refactor GTDT support code: remove it from arch/arm64/kernel/acpi.c, put it into drivers/acpi/gtdt.c file. Integrate the GTDT code of drivers/clocksource/arm_arch_timer.c into drivers/acpi/gtdt.c. Improve pretimeout support, fix "pretimeout == 0" problem. Simplify sbsa_gwdt driver: (1)timeout/pretimeout limits setup; (2)keepalive function; (3)delete "clk == 0" check; (4)delete WS0 status bit check in interrupt routine; (5)sbsa_gwdt_set_wcv function. v3: Delete "export arch_timer_get_rate" patch. Driver back to use arch_timer_get_cntfrq. Improve watchdog_init_timeouts function and update relevant documentation. Improve watchdog_timeout_invalid and watchdog_pretimeout_invalid. Improve foundation-v8.dts: delete the unnecessary tag of device node. Remove "ARM64 || COMPILE_TEST" from Kconfig. Add comments in arch/arm64/kernel/acpi.c Fix typoes and incorrect comments. v2: Improve watchdog-kernel-api.txt documentation for pretimeout support. Export "arch_timer_get_rate" in arm_arch_timer.c. Add watchdog_init_timeouts API for pretimeout support in framework. Improve suspend and resume foundation in driver Improve timeout/pretimeout values init code in driver. Delete unnecessary items of the sbsa_gwdt struct and #define. Delete all unnecessary debug info in driver. Fix 64bit division bug. Use the arch_timer interface to get watchdog clock rate. Add MODULE_DEVICE_TABLE for platform device id. Fix typoes. v1: The first version upstream patchset to linux mailing list. Fu Wei (7): Documentation: add sbsa-gwdt.txt documentation ARM64: add SBSA Generic Watchdog device node in foundation-v8.dts ARM64: add SBSA Generic Watchdog device node in amd-seattle-soc.dtsi Watchdog: introdouce "pretimeout" into framework Watchdog: introduce ARM SBSA watchdog driver ACPI: add GTDT table parse driver into ACPI driver clocksource: simplify ACPI code in arm_arch_timer.c .../devicetree/bindings/watchdog/sbsa-gwdt.txt | 36 ++ Documentation/watchdog/watchdog-kernel-api.txt | 47 ++- arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 11 + arch/arm64/boot/dts/arm/foundation-v8.dts | 10 + arch/arm64/kernel/time.c | 4 +- drivers/acpi/Kconfig | 9 + drivers/acpi/Makefile | 1 + drivers/acpi/gtdt.c| 180 + drivers/clocksource/Kconfig| 1 + drivers/clocksource/arm_arch_timer.c | 60 +-- drivers/watchdog/Kconfig | 12 + drivers/watchdog/Makefile | 1 + drivers/watchdog/sbsa_gwdt.c | 426 + drivers/watchdog/watchdog_core.c | 115 -- drivers/watchdog/watchdog_dev.c| 53 +++ include/clocksource/arm_arch_timer.h | 8 + include/linux/acpi.h | 5 + include/linux/clocksource.h| 4 +- include/linux/watchdog.h | 33 +- 19 files changed, 927 insertions(+), 89 deletions(-) create mode 100644 Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt create mode 100644 drivers/acpi/gtdt.c create mode 100644 drivers/watchdog/sbsa_gwdt.c -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 0/6] arm64,hi6220: Enable Hisilicon Hi6220 SoC
Hi Will, Mark and other ARM64 DT maintainers, Could you help ack this version? although Will, Kevin and Tyler have tested this patch set, I think also need an ack from you. The clock driver has been merged to linux-next, so I just add the clock header file to this patch set to avoid compilation error. Thanks, Bintian On 2015/5/30 9:50, Bintian Wang wrote: Hi6220 is one mobile solution of Hisilicon, this patchset contains initial support for Hi6220 SoC and HiKey development board, which supports octal ARM Cortex A53 cores. Initial support is minimal and includes just the arch configuration, device tree configuration, the clock driver has been picked up by clock maintainers in clk tree. PSCI is enabled in device tree and there is no problem to boot all the octal cores, and the CPU hotplug is also working now, you can download and compile the latest firmware based on the following link to run this patch set: https://github.com/96boards/documentation/wiki/UEFI Chnages v9: * Rebase to linus/master 4.1-rc1 * Remove the clock driver from this version because the clock maintainers have queued up the clock driver: git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next-hi6220 * This version also includes clock header file: [PATCH v9 6/6] dt-bindings: Add header file of hi6220 clock driver Although above patch is included in clock driver, I add to this series because the device tree file includes it, there will be compile error without it. At last, we just need to keep one when merged together. Changes v6~v8: This three versions only modified the clock drivers based on the Stephen's review advices. * clk-hi6220.c: ** Split the clock header file from clock driver ** Delete setting the parents clock of UART1 to HI6220_150M in clock driver, we can do that using assigned-clock in dts when enable UART1 in the future. * clkdivider-hi6220.c: ** Reuse some functions exported by clk-divider.c ** Remove "pr_err" and CLK_IS_BASIC flag ** Fix some programing style problems * hisilicon/clk.h: remove the "__init" markings on some funcition prototypes. Changes v5: * Rebase to kernel 4.1-rc2 * Add compatible string "hisilicon,hi6220-pl011" for Hisilicon designed UART * clk-hi6220.c: use __initdata for non-const arrays based on the commit 692d8328e8c039f9497eb862c6cf835de922c061 Changes v4: * Rebase to kernel 4.1-rc1 * Delete "arm,cortex-a15-gic" from the gic node in dts Changes v3: * Verified the CPU hotplug based on the new released firmware * Redefined the compatible strings of four system controllers in dts * Setting COMMON_CLK_HI6220 to a bool symbol * Keep CONFGI_ARCH_HISI sorted alphabetically Changes v2: * Split the DT bindings documents into earlier patches * Change SMP enable method from spin-table to PSCI in device tree * Remove "clock-frequency" from armv8-timer device node in device tree * Add more description about Hisilicon designed system controllers in DT bindings document * Enable high speed clock on UART1 mux * Other changes based on the discussion in the mailing list: https://lkml.org/lkml/2015/2/5/147 Bintian Wang (6): arm64: Enable Hisilicon ARMv8 SoC family in Kconfig and defconfig arm64: hi6220: Document devicetree bindings for Hisilicon hi6220 SoC clk: hi6220: Document devicetree bindings for hi6220 clock Documentation: DT: PL011: hi6220: add compatible string for Hisilicon designed UART arm64: dts: Add dts files for Hisilicon Hi6220 SoC dt-bindings: Add header file of hi6220 clock driver .../bindings/arm/hisilicon/hisilicon.txt | 87 ++ .../devicetree/bindings/clock/hi6220-clock.txt | 34 Documentation/devicetree/bindings/serial/pl011.txt |4 +- arch/arm64/Kconfig |5 + arch/arm64/boot/dts/Makefile |1 + arch/arm64/boot/dts/hisilicon/Makefile |5 + arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 31 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 172 +++ arch/arm64/configs/defconfig |1 + include/dt-bindings/clock/hi6220-clock.h | 173 10 files changed, 512 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/clock/hi6220-clock.txt create mode 100644 arch/arm64/boot/dts/hisilicon/Makefile create mode 100644 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts create mode 100644 arch/arm64/boot/dts/hisilicon/hi6220.dtsi create mode 100644 include/dt-bindings/clock/hi6220-clock.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation, intel_pstate: Add a better description of the intel_pstate legacy mode internal governors
On 01-06-15, 09:36, Prarit Bhargava wrote: > This patchset was originally submitted and acked here > > http://marc.info/?l=linux-kernel=140203008832333=2 > > but lost at some point. > > P. > > 8< I don't think this is the right place to have this information, you should have added it after the three dashes below. (---). > The current documentation is incomplete wrt the intel_pstate legacy > internal governors. The confusion comes from the general cpufreq > governors which also use the names performance and powersave. This patch > better differentiates between the two sets of governors and gives an > explanation of how the internal P-state governors behave differently from > one another. > > Also fix two minor typos. > > Cc: Jonathan Corbet > Cc: Prarit Bhargava > Cc: "Rafael J. Wysocki" > Cc: Kristen Carlson Accardi > Cc: Dirk Brandewie > Cc: linux-...@vger.kernel.org > Cc: Viresh Kumar > Cc: x...@kernel.org > Signed-off-by: Prarit Bhargava You could have carried my Ack :) Acked-by: Viresh Kumar -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/6] xhci: probe phy before add usb_hcd
Mathias.
On 01/06/15 18:17, Mathias Nyman wrote:
On 01.06.2015 17:52, Yingjoe Chen wrote:
On Wed, 2015-05-27 at 07:18 -0500, Felipe Balbi wrote:
On Wed, May 27, 2015 at 07:48:00PM +0800, chunfeng@mediatek.com wrote:
From: Chunfeng Yun
find the phy driver before add primary usb_hcd to avoid acessing
xHCI register which may hangup the system when the phy is not loaded
yet and the related powers or clocks put in phy driver are not
enabled.
it seems like the same clock is needed by PHY and XHCI. This patch looks
incorrect.
Hi,
I agree that the driver should enable clock it used by itself and not
depends on init order. This should be fixed.
But in general, I think it make sense to only add hcd after all required
resource are ready. At least it remove unnecessary calls to
usb_add_hcd/usb_remove_hcd. Is it better if the commit message is
changed to something like the below?
Currently xhci_plat_probe() call usb_add_hcd before trying to init the
phy. However if the phy is not ready at the moment, it have to remove
the hcd and probe again later
Change the init order so we only add hcd when all required resource are
ready.
Hi
Rogers Quadros patchseries that changes how HCDs are created and added for
xhci-plat was just sent forward. It first creates both HCDs, then adds them.
Doesn't usb_add_hcd() as it's first task take care of the PHYs?
I'm hoping to remove that part completely from xhci-plat.c but haven't
looked into it properly yet.
usb_add_hcd() does
if (IS_ENABLED(CONFIG_USB_PHY) && !hcd->usb_phy) {
struct usb_phy *phy = usb_get_phy_dev(hcd->self.controller, 0);
...
if (IS_ENABLED(CONFIG_GENERIC_PHY) && !hcd->phy) {
struct phy *phy = phy_get(hcd->self.controller, "usb");
...
but xhci-plat.c does
hcd->usb_phy = devm_usb_get_phy_by_phandle(>dev, "usb-phy", 0);
So there needs to be some alignment.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [v3,33/36] genirq: Use helper function to access irq_data->msi_desc
On Mon, 2015-01-06 at 08:05:42 UTC, Jiang Liu wrote: > Use irq_data access helper to access irq_data->msi_desc, so we could > move msi_desc from struct irq_data into struct irq_common_data later. > > Signed-off-by: Jiang Liu > --- > arch/powerpc/sysdev/xics/ics-opal.c |2 +- > arch/powerpc/sysdev/xics/ics-rtas.c |2 +- > > diff --git a/arch/powerpc/sysdev/xics/ics-opal.c > b/arch/powerpc/sysdev/xics/ics-opal.c > index 3996393c254d..27c936c080a6 100644 > --- a/arch/powerpc/sysdev/xics/ics-opal.c > +++ b/arch/powerpc/sysdev/xics/ics-opal.c > @@ -72,7 +72,7 @@ static unsigned int ics_opal_startup(struct irq_data *d) >* card, using the MSI mask bits. Firmware doesn't appear to unmask >* at that level, so we do it here by hand. >*/ > - if (d->msi_desc) > + if (irq_data_get_msi_desc(d)) > pci_msi_unmask_irq(d); > #endif > > diff --git a/arch/powerpc/sysdev/xics/ics-rtas.c > b/arch/powerpc/sysdev/xics/ics-rtas.c > index e2665a9dfc0f..3854dd41558d 100644 > --- a/arch/powerpc/sysdev/xics/ics-rtas.c > +++ b/arch/powerpc/sysdev/xics/ics-rtas.c > @@ -75,7 +75,7 @@ static unsigned int ics_rtas_startup(struct irq_data *d) >* card, using the MSI mask bits. Firmware doesn't appear to unmask >* at that level, so we do it here by hand. >*/ > - if (d->msi_desc) > + if (irq_data_get_msi_desc(d)) > pci_msi_unmask_irq(d); > #endif > /* unmask it */ These look OK. Though I would point out we already have 16 irq_foo_get_bar() accessors?! Acked-by: Michael Ellerman cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] ARM: EXYNOS: DTS improvements for 4.2, 3rd
Krzysztof Kozlowski wrote: > Dear Kukjin, > > Quite big set of changes, mostly refactor. > > You can find them also on the lists with my reviewed-by. Thanks for your gentle reminder and gathering. I'm sorting them out and it should be fine tonight in my tree... If any differences with yours, I'll let you know and please check them tomorrow morning so that it could be sent out to arm-soc tomorrow for 4.2. Thanks, Kukjin > > Best regards, > Krzysztof > > > The following changes since commit 5c78bc1b466701c1b13d7b734f5b39cdd65babab: > > Merge branch 'samsung-defconfig-2nd' into for-next (2015-05-23 12:28:59 > +0900) > > are available in the git repository at: > > https://github.com/krzk/linux.git tags/samsung-dt-for-4.2-3 > > for you to fetch changes up to a33a220172cd832fd4b9f8c26f4e6053899d68c4: > > ARM: dts: Add Odroid XU3 Lite support (2015-05-30 13:22:45 +0900) > > > Device Tree improvements for Exynos based boards: > 1. Refactor DT sources to label notation. All new Exynos boards follow >this convention so only old DTS are changed: Exynos4 family, Exynos5 >and s3c2416. >This convention reduces duplication of addresses in nodes >and reduces possible mistakes when overriding nodes. > 2. Switch LEDs on Odroid XU3 to PWM control. > 3. Add nodes for JPEG codec on Exynos542x. > 4. Enable wake alarm on Odroid XU3. > 5. Add support for new board: Odroid XU3 Lite. The board is actually >very similar to existing Odroid XU3. > > > Andrzej Pietrasiewicz (1): > ARM: dts: exynos5420: add nodes for jpeg codec > > Krzysztof Kozlowski (26): > ARM: dts: Add labels to exynos4 nodes > ARM: dts: Use labels for overriding nodes in exynos4210 > ARM: dts: Use labels for overriding nodes in exynos4210-origen > ARM: dts: Use labels for overriding nodes in exynos4210-smdkv310 > ARM: dts: Use labels for overriding nodes in exynos4210-trats > ARM: dts: Use labels for overriding nodes in exynos4212 > ARM: dts: Use labels for overriding nodes in exynos4x12 > ARM: dts: Use labels for overriding nodes in exynos4412 > ARM: dts: Use labels for overriding nodes in exynos4412-odroid > ARM: dts: Use labels for overriding nodes in exynos4412-smdk4412 > ARM: dts: Use labels for overriding nodes in exynos4412-trats2 > ARM: dts: Use labels for overriding nodes in exynos4412-origen > ARM: dts: Use labels for overriding nodes in exynos4412-tiny4412 > ARM: dts: Add labels to exynos5 nodes > ARM: dts: Use labels for overriding nodes in exynos5250 > ARM: dts: Remove duplicated I2C7 nodes in exynos5250-snow > ARM: dts: Use labels for overriding nodes in exynos5420-arndale-octa > ARM: dts: Use labels for overriding nodes in exynos542x > ARM: dts: Use labels for overriding nodes in exynos5420-smdk5420 > ARM: dts: Use labels for overriding nodes in exynos5440 boards > ARM: dts: Use labels for overriding nodes in exynos5422-odroidxu3 > ARM: dts: s3c2416: Add labels to S3C2416 nodes > ARM: dts: s3c2416: Use labels for overriding nodes in SMDK2416 > ARM: dts: odroidxu3: Enable wake alarm of S2MPS11 RTC > of: Add vendor prefix for Hardkernel > ARM: dts: Add Odroid XU3 Lite support > > Peter Chubb (1): > ARM: dts: exynos5422-odroidxu3: Hook up PWM and use it for LEDs > > .../devicetree/bindings/vendor-prefixes.txt|1 + > arch/arm/boot/dts/Makefile |1 + > arch/arm/boot/dts/exynos4.dtsi | 22 +- > arch/arm/boot/dts/exynos4210-origen.dts| 418 +++--- > arch/arm/boot/dts/exynos4210-smdkv310.dts | 280 ++-- > arch/arm/boot/dts/exynos4210-trats.dts | 592 - > arch/arm/boot/dts/exynos4210.dtsi | 49 +- > arch/arm/boot/dts/exynos4212.dtsi | 12 +- > arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 732 +-- > arch/arm/boot/dts/exynos4412-odroidx.dts | 16 +- > arch/arm/boot/dts/exynos4412-origen.dts| 892 ++--- > arch/arm/boot/dts/exynos4412-smdk4412.dts | 210 +-- > arch/arm/boot/dts/exynos4412-tiny4412.dts | 54 +- > arch/arm/boot/dts/exynos4412-trats2.dts| 1332 ++-- > arch/arm/boot/dts/exynos4412.dtsi | 20 +- > arch/arm/boot/dts/exynos4x12-pinctrl.dtsi |8 +- > arch/arm/boot/dts/exynos4x12.dtsi | 218 ++-- > arch/arm/boot/dts/exynos5.dtsi |6 +- > arch/arm/boot/dts/exynos5250-snow.dts | 46 +- > arch/arm/boot/dts/exynos5250.dtsi | 82 +- > arch/arm/boot/dts/exynos5420-arndale-octa.dts | 634 +- > arch/arm/boot/dts/exynos5420-peach-pit.dts |2 +- >
Re: [PATCH] neighbour: Convert if statment in the function, neigh_add_timer to a WARN_ON
On Mon, Jun 1, 2015 at 7:37 PM, YOSHIFUJI Hideaki/吉藤英明
wrote:
> Nicholas Krause wrote:
>> This converts the if statement for dumping the stack into a
>> WARN_ON in order to make this function's debugging check
>> simpler and have a cleaner output when this condition
>> occurs inside this function for when bugs related to
>> adding a duplicate neighbour table timer arise.
>>
>> Signed-off-by: Nicholas Krause
>> ---
>> net/core/neighbour.c | 6 +-
>> 1 file changed, 1 insertion(+), 5 deletions(-)
>>
>> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
>> index 3de6542..0bf71da 100644
>> --- a/net/core/neighbour.c
>> +++ b/net/core/neighbour.c
>> @@ -165,11 +165,7 @@ static int neigh_forced_gc(struct neigh_table *tbl)
>> static void neigh_add_timer(struct neighbour *n, unsigned long when)
>> {
>> neigh_hold(n);
>> - if (unlikely(mod_timer(>timer, when))) {
>> - printk("NEIGH: BUG, double timer add, state is %x\n",
>> -n->nud_state);
>> - dump_stack();
>> - }
>> + WARN_ON(unlikely(mod_timer(>timer, when)));
>> }
>
> NACK, please do not use WARN_ON for things with side effects.
Just:
int ret = mod_timer(...);
WARN_ON(ret);
...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH 4/6] OPP: Allow notifiers to call dev_pm_opp_get_{voltage,freq} RCU-free
On 02.06.2015 10:47, Stephen Boyd wrote:
> We pass the dev_pm_opp structure to OPP notifiers but the users
> of the notifier need to surround calls to dev_pm_opp_get_*() with
> RCU read locks to avoid lockdep warnings. The notifier is already
> called with the dev_opp's srcu lock held, so it should be safe to
> assume the devm_pm_opp structure is already protected inside the
> notifier. Update the lockdep check for this.
>
> Cc: Krzysztof Kozlowski
> Signed-off-by: Stephen Boyd
> ---
>
> This is probably wrong, but it's what I had to hack up
> to be able to use the OPP functions from within the notifier
> to figure out the new values of the OPP without having to take
> an RCU read lock.
>
> drivers/base/power/opp.c | 19 +++
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
> index b997a7eabcd4..6d75022c6a0e 100644
> --- a/drivers/base/power/opp.c
> +++ b/drivers/base/power/opp.c
> @@ -108,9 +108,10 @@ static LIST_HEAD(dev_opp_list);
> /* Lock to allow exclusive modification to the device and opp lists */
> static DEFINE_MUTEX(dev_opp_list_lock);
>
> -#define opp_rcu_lockdep_assert() \
> +#define opp_rcu_lockdep_assert(s)\
> do { \
> rcu_lockdep_assert(rcu_read_lock_held() || \
> + (s && srcu_read_lock_held(s)) ||\
> lockdep_is_held(_opp_list_lock),\
> "Missing rcu_read_lock() or "\
> "dev_opp_list_lock protection"); \
> @@ -169,9 +170,10 @@ unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp
> *opp)
> struct dev_pm_opp *tmp_opp;
> unsigned long v = 0;
>
> - opp_rcu_lockdep_assert();
> + opp_rcu_lockdep_assert(>dev_opp->srcu_head.srcu);
>
> - tmp_opp = rcu_dereference(opp);
> + tmp_opp = srcu_dereference_check(opp, >dev_opp->srcu_head.srcu,
> + rcu_read_lock_held());
It looks strange. The notifier's SRCU is part of device_opp but here we
want to protect the dev_pm_opp.
Because of this difference I am not sure that it is safe having around
this a srcu_read_lock() from notifiers instead of rcu_read_lock().
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v5] QE: Move QE from arch/powerpc to drivers/soc
On Tue, 2015-06-02 at 10:53, Wood Scott wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, June 02, 2015 10:53 AM
> To: Zhao Qiang-B45475
> Cc: linuxppc-...@lists.ozlabs.org; linux-kernel@vger.kernel.org;
> net...@vger.kernel.org
> Subject: Re: [PATCH v5] QE: Move QE from arch/powerpc to drivers/soc
>
> On Tue, 2015-06-02 at 10:37 +0800, Zhao Qiang wrote:
> > ls1 has qe and ls1 has arm cpu.
> > move qe from arch/powerpc to drivers/soc/fsl to adapt to powerpc and
> > arm
> >
> > Signed-off-by: Zhao Qiang
> > ---
> > Changes for v2:
> > - move code to driver/soc
> > Changes for v3:
> > - change drivers/soc/qe to drivers/soc/fsl-qe Changes for v4:
> > - move drivers/soc/fsl-qe to drivers/soc/fsl/qe
> > - move head files for qe from include/linux/fsl to
> include/soc/fsl
> > - move qe_ic.c to drivers/irqchip/ Changes for v5:
> > - update MAINTAINERS
> >
> > MAINTAINERS| 5 +++--
> > arch/powerpc/platforms/83xx/km83xx.c | 4 ++--
> > arch/powerpc/platforms/83xx/misc.c | 2 +-
> > arch/powerpc/platforms/83xx/mpc832x_mds.c | 4 ++--
> > arch/powerpc/platforms/83xx/mpc832x_rdb.c | 4 ++--
> > arch/powerpc/platforms/83xx/mpc836x_mds.c | 4 ++--
> > arch/powerpc/platforms/83xx/mpc836x_rdk.c | 4 ++--
> > arch/powerpc/platforms/85xx/common.c | 2 +-
> > arch/powerpc/platforms/85xx/corenet_generic.c | 2 +-
> > arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 ++--
> > arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 4 ++--
> > arch/powerpc/platforms/85xx/twr_p102x.c| 4 ++--
> > arch/powerpc/platforms/Kconfig | 19
> > --
> > arch/powerpc/sysdev/qe_lib/Kconfig | 23 ++--
> > --
> > arch/powerpc/sysdev/qe_lib/Makefile| 10 +++---
> > arch/powerpc/sysdev/qe_lib/gpio.c | 2 +-
> > arch/powerpc/sysdev/qe_lib/qe_io.c | 2 +-
> > arch/powerpc/sysdev/qe_lib/usb.c | 4 ++--
> > drivers/irqchip/Makefile | 1 +
> > .../sysdev/qe_lib => drivers/irqchip}/qe_ic.c | 2 +-
> > .../sysdev/qe_lib => drivers/irqchip}/qe_ic.h | 2 +-
> > drivers/net/ethernet/freescale/fsl_pq_mdio.c | 2 +-
> > drivers/net/ethernet/freescale/ucc_geth.c | 8
> > drivers/net/ethernet/freescale/ucc_geth.h | 8
> > drivers/soc/Kconfig| 2 ++
> > drivers/soc/Makefile | 1 +
> > drivers/soc/fsl/Makefile | 5 +
> > .../sysdev/qe_lib => drivers/soc/fsl/qe}/Kconfig | 16 +---
> > ---
> > drivers/soc/fsl/qe/Makefile| 8
> > .../sysdev/qe_lib => drivers/soc/fsl/qe}/qe.c | 4 ++--
> > .../sysdev/qe_lib => drivers/soc/fsl/qe}/ucc.c | 6 +++---
> > .../qe_lib => drivers/soc/fsl/qe}/ucc_fast.c | 8
> > .../qe_lib => drivers/soc/fsl/qe}/ucc_slow.c | 8
> > drivers/spi/spi-fsl-cpm.c | 2 +-
> > drivers/tty/serial/ucc_uart.c | 2 +-
> > drivers/usb/gadget/fsl_qe_udc.c| 2 +-
> > drivers/usb/host/fhci-hcd.c| 2 +-
> > drivers/usb/host/fhci-hub.c| 2 +-
> > drivers/usb/host/fhci-sched.c | 2 +-
> > drivers/usb/host/fhci.h| 4 ++--
> > .../include/asm => include/linux/fsl}/qe_ic.h | 0
> > .../include/asm => include/soc/fsl}/immap_qe.h | 0
> > {arch/powerpc/include/asm => include/soc/fsl}/qe.h | 2 +-
> > .../powerpc/include/asm => include/soc/fsl}/ucc.h | 4 ++--
> > .../include/asm => include/soc/fsl}/ucc_fast.h | 6 +++---
> > .../include/asm => include/soc/fsl}/ucc_slow.h | 6 +++---
> > 46 files changed, 103 insertions(+), 115 deletions(-) rename
> > {arch/powerpc/sysdev/qe_lib => drivers/irqchip}/qe_ic.c (99%) rename
> > {arch/powerpc/sysdev/qe_lib => drivers/irqchip}/qe_ic.h (98%) create
> > mode 100644 drivers/soc/fsl/Makefile copy {arch/powerpc/sysdev/qe_lib
> > => drivers/soc/fsl/qe}/Kconfig
> > (50%)
> > create mode 100644 drivers/soc/fsl/qe/Makefile rename
> > {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/qe.c (99%) rename
> > {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/ucc.c
> > (98%)
> > rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/ucc_fast.c
> > (99%) rename {arch/powerpc/sysdev/qe_lib =>
> > drivers/soc/fsl/qe}/ucc_slow.c (98%) rename {arch/powerpc/include/asm
> > => include/linux/fsl}/qe_ic.h
> > (100%)
> > rename {arch/powerpc/include/asm => include/soc/fsl}/immap_qe.h
> > (100%)
> > rename {arch/powerpc/include/asm => include/soc/fsl}/qe.h (99%)
> > rename {arch/powerpc/include/asm =>
Re: [PATCH RESEND 3/3] drivers/rtc/sunxi: Replace deprecated rtc_tm_to_time()
Hi Arnd,
Arnd Bergmann wrote 2015-06-02 AM 03:53:03:
> Re: [PATCH RESEND 3/3] drivers/rtc/sunxi: Replace deprecated
rtc_tm_to_time()
>
> On Friday 29 May 2015 23:04:37 Xunlei Pang wrote:
> > }
> >
> > - rtc_tm_to_time(alrm_tm, _set);
> > - rtc_tm_to_time(_now, _now);
> > + time_set = rtc_tm_to_time64(alrm_tm);
> > + time_now = rtc_tm_to_time64(_now);
> > if (time_set <= time_now) {
> > dev_err(dev, "Date to set in the past\n");
> > return -EINVAL;
> > }
> >
> > + if (time_set > time_now + 255 * SEC_IN_DAY) {
> > + dev_err(dev, "Day must be in the range 0 - 255\n");
> > + return -EINVAL;
> > + }
> > +
> >
>
> So this driver also uses the two values just to do a comparison
> and to take the difference in seconds.
>
> If we have a helper function that returns the difference between
> two rtc_tm values as a time64_t, we can use that for both
> this driver and isl1208.
Indeed, will do.
Thanks,
-Xunlei
ZTE Information Security Notice: The information contained in this mail (and
any attachment transmitted herewith) is privileged and confidential and is
intended for the exclusive use of the addressee(s). If you are not an intended
recipient, any disclosure, reproduction, distribution or other dissemination or
use of the information contained is strictly prohibited. If you have received
this mail in error, please delete it and notify us immediately.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] NTP: rtc: Add CONFIG_RTC_SYSTOHC_DEVICE for NTP synchronization
Hi Paul, Paul Bolle wrote 2015-06-01 PM 04:27:40: > > Re: [PATCH v2 1/4] NTP: rtc: Add CONFIG_RTC_SYSTOHC_DEVICE for NTP > synchronization > > On Fri, 2015-05-29 at 22:46 +0800, Xunlei Pang wrote: > > --- a/drivers/rtc/Kconfig > > +++ b/drivers/rtc/Kconfig > > > config RTC_HCTOSYS_DEVICE > > string "RTC used to set the system time" > > - depends on RTC_HCTOSYS = y || RTC_SYSTOHC = y > > + depends on RTC_HCTOSYS = y > > RTC_HCTOSYS and RTC_SYSTOHC are bool symbols. The "= y" test is not > needed and the common idiom is to use only >depends on RTC_HCTOSYS > > Since you're touching this you might as well switch to that idiom. > > > default "rtc0" > > help > > The RTC device that will be used to (re)initialize the system > > minutes if userspace reports synchronized NTP status. > > > +config RTC_SYSTOHC_DEVICE > > + string "RTC used to synchronize NTP adjustment" > > + depends on RTC_SYSTOHC = y > > Likewise. Yea, thanks for pointing this out. -Xunlei > > > + default "rtc0" > > + help > > + The RTC device used for NTP synchronization. The main difference > > + between RTC_HCTOSYS_DEVICE and RTC_SYSTOHC_DEVICE is that this > > + one can sleep when setting time, because it runs in the workqueue > > + context. > > > Paul Bolle > ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5] QE: Move QE from arch/powerpc to drivers/soc
ls1 has qe and ls1 has arm cpu.
move qe from arch/powerpc to drivers/soc/fsl
to adapt to powerpc and arm
Signed-off-by: Zhao Qiang
---
Changes for v2:
- move code to driver/soc
Changes for v3:
- change drivers/soc/qe to drivers/soc/fsl-qe
Changes for v4:
- move drivers/soc/fsl-qe to drivers/soc/fsl/qe
- move head files for qe from include/linux/fsl to include/soc/fsl
- move qe_ic.c to drivers/irqchip/
Changes for v5:
- update MAINTAINERS
MAINTAINERS| 5 +++--
arch/powerpc/platforms/83xx/km83xx.c | 4 ++--
arch/powerpc/platforms/83xx/misc.c | 2 +-
arch/powerpc/platforms/83xx/mpc832x_mds.c | 4 ++--
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 4 ++--
arch/powerpc/platforms/83xx/mpc836x_mds.c | 4 ++--
arch/powerpc/platforms/83xx/mpc836x_rdk.c | 4 ++--
arch/powerpc/platforms/85xx/common.c | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 ++--
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 4 ++--
arch/powerpc/platforms/85xx/twr_p102x.c| 4 ++--
arch/powerpc/platforms/Kconfig | 19 --
arch/powerpc/sysdev/qe_lib/Kconfig | 23 ++
arch/powerpc/sysdev/qe_lib/Makefile| 10 +++---
arch/powerpc/sysdev/qe_lib/gpio.c | 2 +-
arch/powerpc/sysdev/qe_lib/qe_io.c | 2 +-
arch/powerpc/sysdev/qe_lib/usb.c | 4 ++--
drivers/irqchip/Makefile | 1 +
.../sysdev/qe_lib => drivers/irqchip}/qe_ic.c | 2 +-
.../sysdev/qe_lib => drivers/irqchip}/qe_ic.h | 2 +-
drivers/net/ethernet/freescale/fsl_pq_mdio.c | 2 +-
drivers/net/ethernet/freescale/ucc_geth.c | 8
drivers/net/ethernet/freescale/ucc_geth.h | 8
drivers/soc/Kconfig| 2 ++
drivers/soc/Makefile | 1 +
drivers/soc/fsl/Makefile | 5 +
.../sysdev/qe_lib => drivers/soc/fsl/qe}/Kconfig | 16 +--
drivers/soc/fsl/qe/Makefile| 8
.../sysdev/qe_lib => drivers/soc/fsl/qe}/qe.c | 4 ++--
.../sysdev/qe_lib => drivers/soc/fsl/qe}/ucc.c | 6 +++---
.../qe_lib => drivers/soc/fsl/qe}/ucc_fast.c | 8
.../qe_lib => drivers/soc/fsl/qe}/ucc_slow.c | 8
drivers/spi/spi-fsl-cpm.c | 2 +-
drivers/tty/serial/ucc_uart.c | 2 +-
drivers/usb/gadget/fsl_qe_udc.c| 2 +-
drivers/usb/host/fhci-hcd.c| 2 +-
drivers/usb/host/fhci-hub.c| 2 +-
drivers/usb/host/fhci-sched.c | 2 +-
drivers/usb/host/fhci.h| 4 ++--
.../include/asm => include/linux/fsl}/qe_ic.h | 0
.../include/asm => include/soc/fsl}/immap_qe.h | 0
{arch/powerpc/include/asm => include/soc/fsl}/qe.h | 2 +-
.../powerpc/include/asm => include/soc/fsl}/ucc.h | 4 ++--
.../include/asm => include/soc/fsl}/ucc_fast.h | 6 +++---
.../include/asm => include/soc/fsl}/ucc_slow.h | 6 +++---
46 files changed, 103 insertions(+), 115 deletions(-)
rename {arch/powerpc/sysdev/qe_lib => drivers/irqchip}/qe_ic.c (99%)
rename {arch/powerpc/sysdev/qe_lib => drivers/irqchip}/qe_ic.h (98%)
create mode 100644 drivers/soc/fsl/Makefile
copy {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/Kconfig (50%)
create mode 100644 drivers/soc/fsl/qe/Makefile
rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/qe.c (99%)
rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/ucc.c (98%)
rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/ucc_fast.c (99%)
rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/ucc_slow.c (98%)
rename {arch/powerpc/include/asm => include/linux/fsl}/qe_ic.h (100%)
rename {arch/powerpc/include/asm => include/soc/fsl}/immap_qe.h (100%)
rename {arch/powerpc/include/asm => include/soc/fsl}/qe.h (99%)
rename {arch/powerpc/include/asm => include/soc/fsl}/ucc.h (96%)
rename {arch/powerpc/include/asm => include/soc/fsl}/ucc_fast.h (98%)
rename {arch/powerpc/include/asm => include/soc/fsl}/ucc_slow.h (99%)
diff --git a/MAINTAINERS b/MAINTAINERS
index c43ea88..84b234b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3743,8 +3743,9 @@ F:include/linux/fs_enet_pd.h
FREESCALE QUICC ENGINE LIBRARY
L: linuxppc-...@lists.ozlabs.org
S: Orphan
-F: arch/powerpc/sysdev/qe_lib/
-F: arch/powerpc/include/asm/*qe.h
+F: drivers/soc/fsl/qe/
+F: include/soc/fsl/*qe*.h
+F: include/soc/fsl/*ucc*.h
FREESCALE USB PERIPHERAL DRIVERS
M: Li Yang
diff --git a/arch/powerpc/platforms/83xx/km83xx.c
Re: Fwd: [RFC] make kthread_worker_fn to be freezable
2015-06-01 19:40 GMT+08:00 Tejun Heo : > Hello, > > On Mon, Jun 01, 2015 at 06:05:58PM +0800, yalin wang wrote: >> I notice that kthread_worker_fn() call try_to_freeze() function, >> but it don't make itself to be a freezable kthread, >> kthread default behavior is not freezable, we should change it if >> want try_to_freeze() work correctly. >> >> Signed-off-by: yalin wang > > Whether a kthread worker should be able to freeze or not is to be > determined by the owner of the specific kthread. If the kthread is > marked freezable, kthread_worker will freeze. If not, it won't. > this means i need create kthread like this : struct task_struct *kworker_task = kthread_run(kthread_worker_fn, , "nvme%d", dev->instance); kworker_task->flags &= ~PF_NOFREEZE; is it safe to do like this ? i don't see an API to set other thread to be freezable . only set_freezable() , which set the current thread to be freezable . am i missing something ? Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kconfiglib -- a flexible Kconfig parser -- now on GitHub
On Mon, Jun 1, 2015 at 6:58 PM, Ulf Magnusson wrote: > Hello, > > A few years ago I posted patches for a Python Kconfig parser and > library I was working on (https://lkml.org/lkml/2011/2/6/151). As not > many people are probably aware of it, an updated version of that > library has been at https://github.com/ulfalizer/Kconfiglib for a > while now, and is being used for some tasks in e.g. Buildroot and Das > U-Boot. > > As a concrete example, I just noticed scripts/checkkconfigsymbols.py > and remembered that I have an example script that does the same thing > (minus some functionality): > https://github.com/ulfalizer/Kconfiglib/blob/master/examples/print_undefined.py. > > I have no intention to get Kconfiglib into the kernel (unless there > would be a demand), and it's definitely not meant to replace the C > implementation or introduce a Python dependency for standard builds. > It's just an auxiliary helper library which some people might find > useful -- especially when doing "unusual" things with Kconfig-based > configuration systems. Huh, I have a todo item to write the old 2.6.12 snapshot of kconfig I have in http://landley.net/toybox (it's the only gpl code left in the build), but I just got finished _removing_ python as a bulid dependency last year and am reluctant to reintroduce it. I gave up trying to patch upstream kconfig after a half-dozen rounds of https://lwn.net/Articles/161086/ and such were all ignored. (I just documented http://landley.net/aboriginal/FAQ.html#dev_miniconfig and went on with my life. Yes, still using miniconfig.sh a decade later...) (I have rather elaborate kconfig parsing to extract help text, I use specially formatted menuconfig help entries to create command help, and merge the sub-options to create a unified usage: line and alphabetically sorted option description list. That's the stuff that used to be python, which I rewrote in C last year. Somebody submitted a kconfig parser written in awk to toybox a couple years ago, but I can't maintain awk...) Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: usb: gadget: f_fs: O_NONBLOCK waits MAX_SCHEDULE_TIMEOUT
> > Thank you, that sounds like the best approach. > In this case I think perhaps the long wait without any data is an > problem with the imx6 Chipidea USB controller. > >>> > >>> What's the possible problem? > >> > >> Sorry for the delay in replying, I have been getting some more > >> details with a USB Analyser. > >> > >> The scenario is that the NCM device is enumerating so we see the > messages to: > >> > >> SetAddress (1) > >> GetDescriptor (Device) > >> GetDescriptor (StringN) > >> GetDescriptor (Configuration) > >> SetConfiguration (1) > >> GetDescriptor (String iInterface) > >> GetDescriptor (String iInterface) > >> > >> At this point the NCM host sends Writes to the F_FS EP0 but for some > >> reason the host device does not respond and only issues SOF packets > >> for hours. This happens occasionally and is fixed by turning the device off > and on again. > >> > >> > > > > We may find this 'some reason', is it device error or host error? > > > > Do you have below patch in your code: > > > > commit 953c66469735aed8d2ada639a72b150f01dae605 > > Author: Abbas Raza > > Date: Thu Jul 17 19:34:31 2014 +0800 > > > > usb: chipidea: udc: Disable auto ZLP generation on ep0 > > > > There are 2 methods for ZLP (zero-length packet) generation: > > 1) In software > > 2) Automatic generation by device controller > > > > 1) is implemented in UDC driver and it attaches ZLP to IN packet if > >descriptor->size < wLength > > 2) can be enabled/disabled by setting ZLT bit in the QH > > > > Peter > > Yes I have that patch, could that be a problem? > No, you need that patch. Get to know which side has problem first. Peter > Jim > > > > >> Unless I am mistaken from a NCM gadget point of view the attached > >> device is working correctly and there is no way to know it has failed, is > >> that > correct? > >> > >>> > > I guess it should suspend and drop the connections if there is no > traffic for more than 10ms? > > >>> > >>> If the Device side NAK host's IN/OUT token continually, the pipe > >>> will not be stopped, the host will send token continually until the > >>> application cancel this request. > >>> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] QE: Move QE from arch/powerpc to drivers/soc
On Tue, 2015-06-02 at 10:37 +0800, Zhao Qiang wrote:
> ls1 has qe and ls1 has arm cpu.
> move qe from arch/powerpc to drivers/soc/fsl
> to adapt to powerpc and arm
>
> Signed-off-by: Zhao Qiang
> ---
> Changes for v2:
> - move code to driver/soc
> Changes for v3:
> - change drivers/soc/qe to drivers/soc/fsl-qe
> Changes for v4:
> - move drivers/soc/fsl-qe to drivers/soc/fsl/qe
> - move head files for qe from include/linux/fsl to include/soc/fsl
> - move qe_ic.c to drivers/irqchip/
> Changes for v5:
> - update MAINTAINERS
>
> MAINTAINERS| 5 +++--
> arch/powerpc/platforms/83xx/km83xx.c | 4 ++--
> arch/powerpc/platforms/83xx/misc.c | 2 +-
> arch/powerpc/platforms/83xx/mpc832x_mds.c | 4 ++--
> arch/powerpc/platforms/83xx/mpc832x_rdb.c | 4 ++--
> arch/powerpc/platforms/83xx/mpc836x_mds.c | 4 ++--
> arch/powerpc/platforms/83xx/mpc836x_rdk.c | 4 ++--
> arch/powerpc/platforms/85xx/common.c | 2 +-
> arch/powerpc/platforms/85xx/corenet_generic.c | 2 +-
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 ++--
> arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 4 ++--
> arch/powerpc/platforms/85xx/twr_p102x.c| 4 ++--
> arch/powerpc/platforms/Kconfig | 19
> --
> arch/powerpc/sysdev/qe_lib/Kconfig | 23 ++--
> --
> arch/powerpc/sysdev/qe_lib/Makefile| 10 +++---
> arch/powerpc/sysdev/qe_lib/gpio.c | 2 +-
> arch/powerpc/sysdev/qe_lib/qe_io.c | 2 +-
> arch/powerpc/sysdev/qe_lib/usb.c | 4 ++--
> drivers/irqchip/Makefile | 1 +
> .../sysdev/qe_lib => drivers/irqchip}/qe_ic.c | 2 +-
> .../sysdev/qe_lib => drivers/irqchip}/qe_ic.h | 2 +-
> drivers/net/ethernet/freescale/fsl_pq_mdio.c | 2 +-
> drivers/net/ethernet/freescale/ucc_geth.c | 8
> drivers/net/ethernet/freescale/ucc_geth.h | 8
> drivers/soc/Kconfig| 2 ++
> drivers/soc/Makefile | 1 +
> drivers/soc/fsl/Makefile | 5 +
> .../sysdev/qe_lib => drivers/soc/fsl/qe}/Kconfig | 16 +---
> ---
> drivers/soc/fsl/qe/Makefile| 8
> .../sysdev/qe_lib => drivers/soc/fsl/qe}/qe.c | 4 ++--
> .../sysdev/qe_lib => drivers/soc/fsl/qe}/ucc.c | 6 +++---
> .../qe_lib => drivers/soc/fsl/qe}/ucc_fast.c | 8
> .../qe_lib => drivers/soc/fsl/qe}/ucc_slow.c | 8
> drivers/spi/spi-fsl-cpm.c | 2 +-
> drivers/tty/serial/ucc_uart.c | 2 +-
> drivers/usb/gadget/fsl_qe_udc.c| 2 +-
> drivers/usb/host/fhci-hcd.c| 2 +-
> drivers/usb/host/fhci-hub.c| 2 +-
> drivers/usb/host/fhci-sched.c | 2 +-
> drivers/usb/host/fhci.h| 4 ++--
> .../include/asm => include/linux/fsl}/qe_ic.h | 0
> .../include/asm => include/soc/fsl}/immap_qe.h | 0
> {arch/powerpc/include/asm => include/soc/fsl}/qe.h | 2 +-
> .../powerpc/include/asm => include/soc/fsl}/ucc.h | 4 ++--
> .../include/asm => include/soc/fsl}/ucc_fast.h | 6 +++---
> .../include/asm => include/soc/fsl}/ucc_slow.h | 6 +++---
> 46 files changed, 103 insertions(+), 115 deletions(-)
> rename {arch/powerpc/sysdev/qe_lib => drivers/irqchip}/qe_ic.c (99%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/irqchip}/qe_ic.h (98%)
> create mode 100644 drivers/soc/fsl/Makefile
> copy {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/Kconfig
> (50%)
> create mode 100644 drivers/soc/fsl/qe/Makefile
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/qe.c (99%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl/qe}/ucc.c
> (98%)
> rename {arch/powerpc/sysdev/qe_lib =>
> drivers/soc/fsl/qe}/ucc_fast.c (99%)
> rename {arch/powerpc/sysdev/qe_lib =>
> drivers/soc/fsl/qe}/ucc_slow.c (98%)
> rename {arch/powerpc/include/asm => include/linux/fsl}/qe_ic.h
> (100%)
> rename {arch/powerpc/include/asm => include/soc/fsl}/immap_qe.h
> (100%)
> rename {arch/powerpc/include/asm => include/soc/fsl}/qe.h (99%)
> rename {arch/powerpc/include/asm => include/soc/fsl}/ucc.h (96%)
> rename {arch/powerpc/include/asm => include/soc/fsl}/ucc_fast.h
> (98%)
> rename {arch/powerpc/include/asm => include/soc/fsl}/ucc_slow.h
> (99%)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c43ea88..84b234b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3743,8 +3743,9 @@ F: include/linux/fs_enet_pd.h
> FREESCALE QUICC ENGINE LIBRARY
> L: linuxppc-...@lists.ozlabs.org
> S: Orphan
> -F: arch/powerpc/sysdev/qe_lib/
> -F:
Re: [PATCH] livepatch: add module locking around kallsyms calls
On Mon, Jun 1, 2015 at 11:48 PM, Miroslav Benes wrote:
> The list of loaded modules is walked through in
> module_kallsyms_on_each_symbol (called by kallsyms_on_each_symbol). The
> module_mutex lock should be acquired to prevent potential corruptions
> in the list.
>
> This was uncovered with new lockdep asserts in module code introduced by
> the commit 0be964be0d45 ("module: Sanitize RCU usage and locking") in
> recent next- trees.
>
> Signed-off-by: Miroslav Benes
> ---
> kernel/livepatch/core.c | 18 +-
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> index e6c8d54..c40ebcc 100644
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@ -179,7 +179,9 @@ static int klp_find_object_symbol(const char *objname,
> const char *name,
> .count = 0
> };
>
> + mutex_lock(_mutex);
> kallsyms_on_each_symbol(klp_find_callback, );
> + mutex_unlock(_mutex);
>
> if (args.count == 0)
> pr_err("symbol '%s' not found in symbol table\n", name);
> @@ -219,13 +221,19 @@ static int klp_verify_vmlinux_symbol(const char *name,
> unsigned long addr)
> .name = name,
> .addr = addr,
> };
> + int ret;
>
> - if (kallsyms_on_each_symbol(klp_verify_callback, ))
> - return 0;
> + mutex_lock(_mutex);
> + ret = kallsyms_on_each_symbol(klp_verify_callback, );
> + mutex_unlock(_mutex);
>
Hi.
In livepatch code path, returning value 0 may represent the right, but
sometime represent wrong, like the above function.
Is it possible that we can wrap such function and return the unified
value? Thus we can not confuse the returning value any more.
Otherwise annotation is appreciate.
Thanks
Minfei
> - pr_err("symbol '%s' not found at specified address 0x%016lx, kernel
> mismatch?\n",
> - name, addr);
> - return -EINVAL;
> + if (!ret) {
> + pr_err("symbol '%s' not found at specified address 0x%016lx,
> kernel mismatch?\n",
> + name, addr);
> + return -EINVAL;
> + }
> +
> + return 0;
> }
>
> static int klp_find_verify_func_addr(struct klp_object *obj,
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe live-patching" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the sound-asoc tree
Hi all,
After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
sound/soc/soc-dapm.c: In function 'dapm_kcontrol_data_alloc':
sound/soc/soc-dapm.c:387:4: error: implicit declaration of function
'snd_soc_dapm_new_control' [-Werror=implicit-function-declaration]
data->widget = snd_soc_dapm_new_control(widget->dapm,
^
sound/soc/soc-dapm.c:387:17: warning: assignment makes pointer from integer
without a cast
data->widget = snd_soc_dapm_new_control(widget->dapm,
^
sound/soc/soc-dapm.c: At top level:
sound/soc/soc-dapm.c:3269:1: error: conflicting types for
'snd_soc_dapm_new_control'
snd_soc_dapm_new_control(struct snd_soc_dapm_context *dapm,
^
sound/soc/soc-dapm.c:387:19: note: previous implicit declaration of
'snd_soc_dapm_new_control' was here
data->widget = snd_soc_dapm_new_control(widget->dapm,
^
Caused by commit 02aa78abec6e ("ASoC: DAPM: Add APIs to create
individual DAPM controls").
I have used the sound-asoc tree from next-20150601 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpxA35fG4Vex.pgp
Description: OpenPGP digital signature
[Patch v2 2/4] PCI, x86: Allocate PCI IRQ on demand and free it when not used anymore
To support IOAPIC hotplug, we need to correctly manage IOAPIC pin usage,
which is to allocate IRQs on demand and free them when not used anymore.
So use pcibios_alloc_irq() and pcibios_free_irq() to dynamically allocate
and free PCI IRQs.
Also remove obseleted code mp_should_keep_irq().
Signed-off-by: Jiang Liu
---
arch/x86/include/asm/pci_x86.h |2 --
arch/x86/pci/common.c | 20 +---
arch/x86/pci/intel_mid_pci.c |7 +--
arch/x86/pci/irq.c | 15 +--
drivers/acpi/pci_irq.c |9 +
5 files changed, 16 insertions(+), 37 deletions(-)
diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index 164e3f8d3c3d..fa1195dae425 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -93,8 +93,6 @@ extern raw_spinlock_t pci_config_lock;
extern int (*pcibios_enable_irq)(struct pci_dev *dev);
extern void (*pcibios_disable_irq)(struct pci_dev *dev);
-extern bool mp_should_keep_irq(struct device *dev);
-
struct pci_raw_ops {
int (*read)(unsigned int domain, unsigned int bus, unsigned int devfn,
int reg, int len, u32 *val);
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 8fd6f44aee83..dc78a4a9a466 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -673,24 +673,22 @@ int pcibios_add_device(struct pci_dev *dev)
return 0;
}
-int pcibios_enable_device(struct pci_dev *dev, int mask)
+int pcibios_alloc_irq(struct pci_dev *dev)
{
- int err;
-
- if ((err = pci_enable_resources(dev, mask)) < 0)
- return err;
-
- if (!pci_dev_msi_enabled(dev))
- return pcibios_enable_irq(dev);
- return 0;
+ return pcibios_enable_irq(dev);
}
-void pcibios_disable_device (struct pci_dev *dev)
+void pcibios_free_irq(struct pci_dev *dev)
{
- if (!pci_dev_msi_enabled(dev) && pcibios_disable_irq)
+ if (pcibios_disable_irq)
pcibios_disable_irq(dev);
}
+int pcibios_enable_device(struct pci_dev *dev, int mask)
+{
+ return pci_enable_resources(dev, mask);
+}
+
int pci_ext_cfg_avail(void)
{
if (raw_pci_ext_ops)
diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
index 27062303c881..fb7a1f96d80c 100644
--- a/arch/x86/pci/intel_mid_pci.c
+++ b/arch/x86/pci/intel_mid_pci.c
@@ -234,10 +234,13 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
static void intel_mid_pci_irq_disable(struct pci_dev *dev)
{
- if (!mp_should_keep_irq(>dev) && dev->irq_managed &&
- dev->irq > 0) {
+ if (dev->irq_managed && dev->irq > 0) {
mp_unmap_irq(dev->irq);
dev->irq_managed = 0;
+ /*
+* Don't reset dev->irq here, otherwise
+* intel_mid_pci_irq_enable() will fail on next call.
+*/
}
}
diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
index 9bd115484745..72108f0b66b1 100644
--- a/arch/x86/pci/irq.c
+++ b/arch/x86/pci/irq.c
@@ -1257,22 +1257,9 @@ static int pirq_enable_irq(struct pci_dev *dev)
return 0;
}
-bool mp_should_keep_irq(struct device *dev)
-{
- if (dev->power.is_prepared)
- return true;
-#ifdef CONFIG_PM
- if (dev->power.runtime_status == RPM_SUSPENDING)
- return true;
-#endif
-
- return false;
-}
-
static void pirq_disable_irq(struct pci_dev *dev)
{
- if (io_apic_assign_pci_irqs && !mp_should_keep_irq(>dev) &&
- dev->irq_managed && dev->irq) {
+ if (io_apic_assign_pci_irqs && dev->irq_managed && dev->irq) {
mp_unmap_irq(dev->irq);
dev->irq = 0;
dev->irq_managed = 0;
diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index b1def411c0b8..e7f718d6918a 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -485,14 +485,6 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
if (!pin || !dev->irq_managed || dev->irq <= 0)
return;
- /* Keep IOAPIC pin configuration when suspending */
- if (dev->dev.power.is_prepared)
- return;
-#ifdef CONFIG_PM
- if (dev->dev.power.runtime_status == RPM_SUSPENDING)
- return;
-#endif
-
entry = acpi_pci_irq_lookup(dev, pin);
if (!entry)
return;
@@ -513,5 +505,6 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
if (gsi >= 0) {
acpi_unregister_gsi(gsi);
dev->irq_managed = 0;
+ dev->irq = 0;
}
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch v2 4/4] PCI, MSI: Optionally free legacy PCI IRQ when enabling MSI/MSI-X
Once PCI MSI/MSI-X is enabled by the device driver, PCI device won't make use of legacy PCI IRQ until PCI MSI/MSI-X is disabled again. So optionally free legacy PCI IRQ when enabling MSI/MSI-X and reallocate when disabling MSI/MSI-X. Signed-off-by: Jiang Liu --- drivers/pci/msi.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c index c3e7dfcf9ff5..47cf72c669f0 100644 --- a/drivers/pci/msi.c +++ b/drivers/pci/msi.c @@ -686,6 +686,7 @@ static int msi_capability_init(struct pci_dev *dev, int nvec) msi_set_enable(dev, 1); dev->msi_enabled = 1; + pcibios_free_irq(dev); dev->irq = entry->irq; return 0; } @@ -813,9 +814,10 @@ static int msix_capability_init(struct pci_dev *dev, /* Set MSI-X enabled bits and unmask the function */ pci_intx_for_msi(dev, 0); dev->msix_enabled = 1; - msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_MASKALL, 0); + pcibios_free_irq(dev); + return 0; out_avail: @@ -930,6 +932,7 @@ void pci_msi_shutdown(struct pci_dev *dev) /* Restore dev->irq to its default pin-assertion irq */ dev->irq = desc->msi_attrib.default_irq; + pcibios_alloc_irq(dev); } void pci_disable_msi(struct pci_dev *dev) @@ -1030,6 +1033,7 @@ void pci_msix_shutdown(struct pci_dev *dev) msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_ENABLE, 0); pci_intx_for_msi(dev, 1); dev->msix_enabled = 0; + pcibios_alloc_irq(dev); } void pci_disable_msix(struct pci_dev *dev) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch v2 3/4] PCI: Introduce helpers to manage pci_dev->irq and pci_dev->irq_managed
Introduce three helpers to manage pci_dev->irq and pci_dev->irq_managed,
which helps to improve maintenance.
Signed-off-by: Jiang Liu
---
arch/x86/pci/intel_mid_pci.c |4 ++--
arch/x86/pci/irq.c | 10 --
drivers/acpi/pci_irq.c | 10 --
include/linux/pci.h | 17 +
4 files changed, 27 insertions(+), 14 deletions(-)
diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
index fb7a1f96d80c..22aaefb4f1ca 100644
--- a/arch/x86/pci/intel_mid_pci.c
+++ b/arch/x86/pci/intel_mid_pci.c
@@ -211,7 +211,7 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
struct irq_alloc_info info;
int polarity;
- if (dev->irq_managed && dev->irq > 0)
+ if (pci_has_managed_irq(dev))
return 0;
if (intel_mid_identify_cpu() == INTEL_MID_CPU_CHIP_TANGIER)
@@ -234,7 +234,7 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
static void intel_mid_pci_irq_disable(struct pci_dev *dev)
{
- if (dev->irq_managed && dev->irq > 0) {
+ if (pci_has_managed_irq(dev)) {
mp_unmap_irq(dev->irq);
dev->irq_managed = 0;
/*
diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
index 72108f0b66b1..32e70343e6fd 100644
--- a/arch/x86/pci/irq.c
+++ b/arch/x86/pci/irq.c
@@ -1202,7 +1202,7 @@ static int pirq_enable_irq(struct pci_dev *dev)
struct pci_dev *temp_dev;
int irq;
- if (dev->irq_managed && dev->irq > 0)
+ if (pci_has_managed_irq(dev))
return 0;
irq = IO_APIC_get_PCI_irq_vector(dev->bus->number,
@@ -1230,8 +1230,7 @@ static int pirq_enable_irq(struct pci_dev *dev)
}
dev = temp_dev;
if (irq >= 0) {
- dev->irq_managed = 1;
- dev->irq = irq;
+ pci_set_managed_irq(dev, irq);
dev_info(>dev, "PCI->APIC IRQ transform: "
"INT %c -> IRQ %d\n", 'A' + pin - 1,
irq);
return 0;
@@ -1259,9 +1258,8 @@ static int pirq_enable_irq(struct pci_dev *dev)
static void pirq_disable_irq(struct pci_dev *dev)
{
- if (io_apic_assign_pci_irqs && dev->irq_managed && dev->irq) {
+ if (io_apic_assign_pci_irqs && pci_has_managed_irq(dev)) {
mp_unmap_irq(dev->irq);
- dev->irq = 0;
- dev->irq_managed = 0;
+ pci_reset_managed_irq(dev);
}
}
diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index e7f718d6918a..9d6343d02f7e 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -413,7 +413,7 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
return 0;
}
- if (dev->irq_managed && dev->irq > 0)
+ if (pci_has_managed_irq(dev))
return 0;
entry = acpi_pci_irq_lookup(dev, pin);
@@ -458,8 +458,7 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
kfree(entry);
return rc;
}
- dev->irq = rc;
- dev->irq_managed = 1;
+ pci_set_managed_irq(dev, rc);
if (link)
snprintf(link_desc, sizeof(link_desc), " -> Link[%s]", link);
@@ -482,7 +481,7 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
u8 pin;
pin = dev->pin;
- if (!pin || !dev->irq_managed || dev->irq <= 0)
+ if (!pin || !pci_has_managed_irq(dev))
return;
entry = acpi_pci_irq_lookup(dev, pin);
@@ -504,7 +503,6 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
dev_dbg(>dev, "PCI INT %c disabled\n", pin_name(pin));
if (gsi >= 0) {
acpi_unregister_gsi(gsi);
- dev->irq_managed = 0;
- dev->irq = 0;
+ pci_reset_managed_irq(dev);
}
}
diff --git a/include/linux/pci.h b/include/linux/pci.h
index f50d16a04abc..4bc640eef76f 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -958,6 +958,23 @@ static inline int pci_is_managed(struct pci_dev *pdev)
return pdev->is_managed;
}
+static inline void pci_set_managed_irq(struct pci_dev *pdev, unsigned int irq)
+{
+ pdev->irq = irq;
+ pdev->irq_managed = 1;
+}
+
+static inline void pci_reset_managed_irq(struct pci_dev *pdev)
+{
+ pdev->irq = 0;
+ pdev->irq_managed = 0;
+}
+
+static inline bool pci_has_managed_irq(struct pci_dev *pdev)
+{
+ return pdev->irq_managed && pdev->irq > 0;
+}
+
void pci_disable_device(struct pci_dev *dev);
extern unsigned int pcibios_max_latency;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[Patch v2 0/4] Introduce a mechanism to allocate PCI IRQ on demand
This patch set introduces a mechanism to allocate PCI IRQ on demand and free it when not used anymore by hooking pci_device_probe() and pci_device_remove(). It will be used to track IOAPIC pin usage on x86 so we could support IOAPIC hot-removal. The patch set passes Fengguang's 0day test suite. V1->V2: 1) Refine pci_device_probe() to optimize for mainline code as suggested by Bjorn 2) Reorder patch set to put optional patch as the last (Patch 4) Thanks! Gerry Jiang Liu (4): PCI: Add hooks to allocate/free IRQ resources when binding/unbinding driver PCI, x86: Allocate PCI IRQ on demand and free it when not used anymore PCI: Introduce helpers to manage pci_dev->irq and pci_dev->irq_managed PCI, MSI: Optionally free legacy PCI IRQ when enabling MSI/MSI-X arch/x86/include/asm/pci_x86.h |2 -- arch/x86/pci/common.c | 20 +--- arch/x86/pci/intel_mid_pci.c |9 ++--- arch/x86/pci/irq.c | 23 --- drivers/acpi/pci_irq.c | 17 - drivers/pci/msi.c |6 +- drivers/pci/pci-driver.c | 26 -- include/linux/pci.h| 19 +++ 8 files changed, 67 insertions(+), 55 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch v2 1/4] PCI: Add hooks to allocate/free IRQ resources when binding/unbinding driver
Add two hook points pcibios_{alloc|free}_irq() into PCI core, which will
be called when binding/unbinding PCI device drivers. Then PCI arch code
may hook into these two points to allocate IRQ resources on demand and
free them when not used anymore.
Signed-off-by: Jiang Liu
---
drivers/pci/pci-driver.c | 26 --
include/linux/pci.h |2 ++
2 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 3cb2210de553..450ad36ffc77 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -388,18 +388,31 @@ static int __pci_device_probe(struct pci_driver *drv,
struct pci_dev *pci_dev)
return error;
}
+int __weak pcibios_alloc_irq(struct pci_dev *dev)
+{
+ return dev->irq;
+}
+
+void __weak pcibios_free_irq(struct pci_dev *dev)
+{
+}
+
static int pci_device_probe(struct device *dev)
{
- int error = 0;
- struct pci_driver *drv;
- struct pci_dev *pci_dev;
+ int error;
+ struct pci_dev *pci_dev = to_pci_dev(dev);
+ struct pci_driver *drv = to_pci_driver(dev->driver);
+
+ error = pcibios_alloc_irq(pci_dev);
+ if (error < 0)
+ return error;
- drv = to_pci_driver(dev->driver);
- pci_dev = to_pci_dev(dev);
pci_dev_get(pci_dev);
error = __pci_device_probe(drv, pci_dev);
- if (error)
+ if (error) {
+ pcibios_free_irq(pci_dev);
pci_dev_put(pci_dev);
+ }
return error;
}
@@ -415,6 +428,7 @@ static int pci_device_remove(struct device *dev)
drv->remove(pci_dev);
pm_runtime_put_noidle(dev);
}
+ pcibios_free_irq(pci_dev);
pci_dev->driver = NULL;
}
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 353db8dc4c6e..f50d16a04abc 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1656,6 +1656,8 @@ int pcibios_set_pcie_reset_state(struct pci_dev *dev,
int pcibios_add_device(struct pci_dev *dev);
void pcibios_release_device(struct pci_dev *dev);
void pcibios_penalize_isa_irq(int irq, int active);
+int pcibios_alloc_irq(struct pci_dev *dev);
+void pcibios_free_irq(struct pci_dev *dev);
#ifdef CONFIG_HIBERNATE_CALLBACKS
extern struct dev_pm_ops pcibios_pm_ops;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] neighbour: Convert if statment in the function, neigh_add_timer to a WARN_ON
Nicholas Krause wrote:
> This converts the if statement for dumping the stack into a
> WARN_ON in order to make this function's debugging check
> simpler and have a cleaner output when this condition
> occurs inside this function for when bugs related to
> adding a duplicate neighbour table timer arise.
>
> Signed-off-by: Nicholas Krause
> ---
> net/core/neighbour.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
> index 3de6542..0bf71da 100644
> --- a/net/core/neighbour.c
> +++ b/net/core/neighbour.c
> @@ -165,11 +165,7 @@ static int neigh_forced_gc(struct neigh_table *tbl)
> static void neigh_add_timer(struct neighbour *n, unsigned long when)
> {
> neigh_hold(n);
> - if (unlikely(mod_timer(>timer, when))) {
> - printk("NEIGH: BUG, double timer add, state is %x\n",
> -n->nud_state);
> - dump_stack();
> - }
> + WARN_ON(unlikely(mod_timer(>timer, when)));
> }
NACK, please do not use WARN_ON for things with side effects.
--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATH] Fix ies/smt and register irq fail bug.
On Wed, 2015-05-27 at 02:43 -0700, Hongzhou Yang wrote: > Hi Linus, > After integration test, we found some bugs in the code you just merged. > The first is that I missed ies/smt configuration for MSDC3. > The seconed is the if judgement for "interrupt-controller" I added last > time should on the contrary. So adding these two patches to fix them. > Sorry about this. And please help to merge them, many thanks. > > These patches include below changes: > - Adding MSDC3 ies/smt support for mt8173. > - Since mt6397 is no need to support interrupt controller, > I judged "interrupt-controller" property to skip it last time, > but the if judgement should on the contrary, this is a bug. > so adding this patch to fix it. > > Hongzhou Yang (2): > pinctrl: mediatek: Fix bug of ies/smt setting for mt8173. > pinctrl: mediatek: Fix pinctrl register irq fail bug. > > drivers/pinctrl/mediatek/pinctrl-mt8173.c | 10 +- > drivers/pinctrl/mediatek/pinctrl-mtk-common.c |4 ++-- > 2 files changed, 11 insertions(+), 3 deletions(-) > > -- > 1.7.9.5 > Hi Linus, Do you have any suggestion about these two patches? Since we can't boot up device without these two patches, could you please help to merge them? Thank you very much. Yours, Hongzhou -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] livepatch: add support on arm64
On 05/30/2015 09:01 AM, Masami Hiramatsu wrote: > On 2015/05/28 14:51, Li Bin wrote: >> This patchset propose a method for gcc -mfentry feature(profile >> before prologue) implementation for arm64, and propose the livepatch >> implementation for arm64 based on this feature. >> The gcc implementation about this feature will be post to the gcc >> community soon. >> >> With this -mfentry feature, the entry of each function like: >> >> foo: >> mov x9, x30 >> bl __fentry__ >> mov x30, x9 >> [prologue] >> ... >> >> The x9 is a callee corruptible register, and the __fentry__ function >> is responsible to protect all registers, so it can be used to protect >> the x30. And the added two instructions which is register mov operation >> have ralatively small impact on performance. > > Hm, this implementation looks good to me :) > This also enables us to KPROBES_ON_FTRACE too. Even if x9 is a callee-saved register, there is no way to restore its original value in setting up a pt_regs in ftrace_reg_caller. It's not the right thing for KPROBES_ON_FTRACE, is it? Saving Link register in stack is not a big deal since the overhead of ftrace is much bigger. -Takahiro AKASHI > Thanks, > >> >> This patchset has been tested on arm64 platform. >> >> Li Bin (4): >>livepatch: ftrace: arm64: Add support for DYNAMIC_FTRACE_WITH_REGS >>livepatch: ftrace: add ftrace_function_stub_ip function >>livepatch: ftrace: arm64: Add support for -mfentry on arm64 >>livepatch: arm64: add support for livepatch on arm64 >> >> Xie XiuQi (1): >>livepatch: arm64: support relocation in a module >> >> arch/arm64/Kconfig |5 + >> arch/arm64/include/asm/ftrace.h|9 + >> arch/arm64/include/asm/livepatch.h | 45 + >> arch/arm64/kernel/Makefile |1 + >> arch/arm64/kernel/arm64ksyms.c |4 + >> arch/arm64/kernel/entry-ftrace.S | 154 +++- >> arch/arm64/kernel/ftrace.c | 28 +++- >> arch/arm64/kernel/livepatch.c | 41 >> arch/arm64/kernel/module.c | 355 >> ++-- >> include/linux/ftrace.h |1 + >> kernel/livepatch/core.c| 17 ++- >> kernel/trace/ftrace.c | 32 >> scripts/recordmcount.pl|2 +- >> 13 files changed, 508 insertions(+), 186 deletions(-) >> create mode 100644 arch/arm64/include/asm/livepatch.h >> create mode 100644 arch/arm64/kernel/livepatch.c >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ >> > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] USB patches for v4.2 merge window
On Mon, Jun 01, 2015 at 11:21:52AM -0500, Felipe Balbi wrote: > Hi Greg, > > Here's my giant pull request for v4.2 merge window. > > This time "only" 96 non-merge commits. The important > stuff is listed below. > > Let me know if you require any changes to the pull request. > > cheers > > The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031: > > Linux 4.1-rc1 (2015-04-26 17:59:10 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git > tags/usb-for-v4.2 Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] compat: fix possible out-of-bound accesses in compat_get_bitmap() and compat_put_bitmap()
On Mon, Jun 1, 2015 at 11:44 AM, Helge Deller wrote:
>
> Since nr_compat_longs gets unconditionally decremented in each loop, it's type
> needs to be signed instead of unsigned to avoid possibly accessing userspace
> memory behind the bitmap which shouldn't be accessed.
I'd actually prefer to instead just make the decrement conditional,
since that would seem to be the more obvious code. Make the logic be
"iff I have more to go, do the access, and then decrement the counter"
Also, compat_put_bitmap() has the exact same code, and should have the same fix.
Finally, I don't think this is an *actual* bug, just bad and stupid
code. The thing is, the inner loop is only executed twice anyway, and
on that last iteration where "nr_compat_longs" could go negative, the
_outer_ loop will break out too. So there is no actual way we can
enter the thing with nr_compat_longs <= 1 to begin with.
So I don't think the code ever really actually overflows. I do agree
that the code looks bad, so I think a patch like the attached would be
a good idea. Not necessarily marked for stable, unless you can point
out why I'm wrong about the edge condition.
Hmm?
Linus
kernel/compat.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/kernel/compat.c b/kernel/compat.c
index 24f00610c575..333d364be29d 100644
--- a/kernel/compat.c
+++ b/kernel/compat.c
@@ -912,7 +912,8 @@ long compat_get_bitmap(unsigned long *mask, const
compat_ulong_t __user *umask,
* bitmap. We must however ensure the end of the
* kernel bitmap is zeroed.
*/
- if (nr_compat_longs-- > 0) {
+ if (nr_compat_longs) {
+ nr_compat_longs--;
if (__get_user(um, umask))
return -EFAULT;
} else {
@@ -954,7 +955,8 @@ long compat_put_bitmap(compat_ulong_t __user *umask,
unsigned long *mask,
* We dont want to write past the end of the userspace
* bitmap.
*/
- if (nr_compat_longs-- > 0) {
+ if (nr_compat_longs) {
+ nr_compat_longs--;
if (__put_user(um, umask))
return -EFAULT;
}
[PATCH 1/6] regulator: core: Don't spew backtraces on duplicate sysfs
We don't consider a failure to add the sysfs node as a problem,
so use sysfs_create_link_nowarn() so that we don't print a
backtrace when duplicated files exist. Also, downgrade the printk
message to a debug statement so that we're quiet here. This
allows multiple drivers to request a CPU's regulator so that
CPUfreq and AVSish drivers can coexist.
Signed-off-by: Stephen Boyd
---
drivers/regulator/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 443eaab933fc..f6989485c382 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1192,10 +1192,10 @@ static struct regulator *create_regulator(struct
regulator_dev *rdev,
if (regulator->supply_name == NULL)
goto overflow_err;
- err = sysfs_create_link(>dev.kobj, >kobj,
+ err = sysfs_create_link_nowarn(>dev.kobj, >kobj,
buf);
if (err) {
- rdev_warn(rdev, "could not add device link %s err %d\n",
+ rdev_dbg(rdev, "could not add device link %s err %d\n",
dev->kobj.name, err);
/* non-fatal */
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] power: avs: Add support for CPR (Core Power Reduction)
RBCPR (RapidBridge Core Power Reduction) is a technology to reduce core power on a CPU or other device. It reads voltage settings in efuse from product test process as initial settings and populates OPPs for the device being "monitored". Each OPP corresponds to a "corner" that has a range of valid voltages for a particular frequency. While the device is running at a particular frequency, CPR monitors dynamic factors such as temperature, etc. and adjusts the voltage for that frequency accordingly to save power and meet silicon characteristic requirements. This driver is based on work by others on codeaurora.org[1]. TODO: * DT binding documentation [1] https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/drivers/regulator/cpr-regulator.c?h=msm-3.10 Cc: David Collins Signed-off-by: Stephen Boyd --- There's still some TODOs left, but it's mostly surrounding the step voltage reading part, hotplug, and DT documentation. drivers/power/avs/Kconfig| 14 + drivers/power/avs/Makefile |1 + drivers/power/avs/qcom-cpr.c | 1983 ++ 3 files changed, 1998 insertions(+) create mode 100644 drivers/power/avs/qcom-cpr.c diff --git a/drivers/power/avs/Kconfig b/drivers/power/avs/Kconfig index 7f3d389bd601..82e604b363a6 100644 --- a/drivers/power/avs/Kconfig +++ b/drivers/power/avs/Kconfig @@ -11,6 +11,20 @@ menuconfig POWER_AVS Say Y here to enable Adaptive Voltage Scaling class support. +config QCOM_CPR + tristate "QCOM Core Power Reduction (CPR) support" + select PM_OPP + help + Say Y here to enable support for the CPR hardware found on Qualcomm + SoCs like MSM8916. + + This driver populates CPU OPPs tables and makes adjustments to the + tables based on feedback from the CPR hardware. If you want to do + CPUfrequency scaling say Y here. + + To compile this driver as a module, choose M here: the module will + be called qcom-cpr + config ROCKCHIP_IODOMAIN tristate "Rockchip IO domain support" depends on ARCH_ROCKCHIP && OF diff --git a/drivers/power/avs/Makefile b/drivers/power/avs/Makefile index ba4c7bc69225..88f4d5d49cba 100644 --- a/drivers/power/avs/Makefile +++ b/drivers/power/avs/Makefile @@ -1,2 +1,3 @@ obj-$(CONFIG_POWER_AVS_OMAP) += smartreflex.o obj-$(CONFIG_ROCKCHIP_IODOMAIN)+= rockchip-io-domain.o +obj-$(CONFIG_QCOM_CPR) += qcom-cpr.o diff --git a/drivers/power/avs/qcom-cpr.c b/drivers/power/avs/qcom-cpr.c new file mode 100644 index ..b5d4c4042b8c --- /dev/null +++ b/drivers/power/avs/qcom-cpr.c @@ -0,0 +1,1983 @@ +/* + * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 and + * only version 2 as published by the Free Software Foundation. + * + * 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. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* Register Offsets for RB-CPR and Bit Definitions */ + +/* RBCPR Version Register */ +#define REG_RBCPR_VERSION 0 +#define RBCPR_VER_20x02 + +/* RBCPR Gate Count and Target Registers */ +#define REG_RBCPR_GCNT_TARGET(n) (0x60 + 4 * n) + +#define RBCPR_GCNT_TARGET_TARGET_SHIFT 0 +#define RBCPR_GCNT_TARGET_TARGET_MASK GENMASK(11, 0) +#define RBCPR_GCNT_TARGET_GCNT_SHIFT 12 +#define RBCPR_GCNT_TARGET_GCNT_MASKGENMASK(9, 0) + +/* RBCPR Timer Control */ +#define REG_RBCPR_TIMER_INTERVAL 0x44 +#define REG_RBIF_TIMER_ADJUST 0x4c + +#define RBIF_TIMER_ADJ_CONS_UP_MASKGENMASK(3, 0) +#define RBIF_TIMER_ADJ_CONS_UP_SHIFT 0 +#define RBIF_TIMER_ADJ_CONS_DOWN_MASK GENMASK(3, 0) +#define RBIF_TIMER_ADJ_CONS_DOWN_SHIFT 4 +#define RBIF_TIMER_ADJ_CLAMP_INT_MASK GENMASK(7, 0) +#define RBIF_TIMER_ADJ_CLAMP_INT_SHIFT 8 + +/* RBCPR Config Register */ +#define REG_RBIF_LIMIT 0x48 +#define RBIF_LIMIT_CEILING_MASKGENMASK(5, 0) +#define RBIF_LIMIT_CEILING_SHIFT 6 +#define RBIF_LIMIT_FLOOR_BITS 6 +#define RBIF_LIMIT_FLOOR_MASK GENMASK(5, 0) + +#define RBIF_LIMIT_CEILING_DEFAULT RBIF_LIMIT_CEILING_MASK +#define RBIF_LIMIT_FLOOR_DEFAULT 0 + +#define REG_RBIF_SW_VLEVEL 0x94 +#define RBIF_SW_VLEVEL_DEFAULT 0x20 + +#define REG_RBCPR_STEP_QUOT0x80 +#define RBCPR_STEP_QUOT_STEPQUOT_MASK GENMASK(7, 0) +#define RBCPR_STEP_QUOT_IDLE_CLK_MASK GENMASK(3, 0)
[PATCH 5/6] cpufreq-dt: Handle OPP voltage adjust events
On some SoCs the Adaptive Voltage Scaling (AVS) technique is
employed to optimize the operating voltage of a device. At a
given frequency, the hardware monitors dynamic factors and either
makes a suggestion for how much to adjust a voltage for the
current frequency, or it automatically adjusts the voltage
without software intervention.
In the former case, an AVS driver will call
dev_pm_opp_modify_voltage() and update the voltage for the
particular OPP the CPUs are using. Add an OPP notifier to
cpufreq-dt so that we can adjust the voltage of the CPU when AVS
updates the OPP.
Signed-off-by: Stephen Boyd
---
drivers/cpufreq/cpufreq-dt.c | 73
1 file changed, 67 insertions(+), 6 deletions(-)
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index bab67db54b7e..616218f133be 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -34,8 +34,48 @@ struct private_data {
struct regulator *cpu_reg;
struct thermal_cooling_device *cdev;
unsigned int voltage_tolerance; /* in percentage */
+ struct notifier_block opp_nb;
+ struct mutex lock;
+ unsigned long opp_freq;
};
+
+static int opp_notifier(struct notifier_block *nb, unsigned long event,
+ void *data)
+{
+ struct dev_pm_opp *opp = data;
+ struct private_data *priv = container_of(nb, struct private_data,
+opp_nb);
+ struct device *cpu_dev = priv->cpu_dev;
+ struct regulator *cpu_reg = priv->cpu_reg;
+ unsigned long volt, tol, freq;
+ int ret = 0;
+
+ switch (event) {
+ case OPP_EVENT_ADJUST_VOLTAGE:
+ volt = dev_pm_opp_get_voltage(opp);
+ freq = dev_pm_opp_get_freq(opp);
+ tol = volt * priv->voltage_tolerance / 100;
+
+ mutex_lock(>lock);
+ if (freq == priv->opp_freq)
+ ret = regulator_set_voltage_tol(cpu_reg, volt,
+ tol);
+ mutex_unlock(>lock);
+ if (ret) {
+ dev_err(cpu_dev,
+ "failed to scale voltage up: %d\n",
+ ret);
+ return ret;
+ }
+ break;
+ default:
+ break;
+ }
+
+ return 0;
+}
+
static int set_target(struct cpufreq_policy *policy, unsigned int index)
{
struct dev_pm_opp *opp;
@@ -47,6 +87,7 @@ static int set_target(struct cpufreq_policy *policy, unsigned
int index)
unsigned long volt = 0, volt_old = 0, tol = 0;
unsigned int old_freq, new_freq;
long freq_Hz, freq_exact;
+ unsigned long opp_freq = 0;
int ret;
freq_Hz = clk_round_rate(cpu_clk, freq_table[index].frequency * 1000);
@@ -57,8 +98,8 @@ static int set_target(struct cpufreq_policy *policy, unsigned
int index)
new_freq = freq_Hz / 1000;
old_freq = clk_get_rate(cpu_clk) / 1000;
+ mutex_lock(>lock);
if (!IS_ERR(cpu_reg)) {
- unsigned long opp_freq;
rcu_read_lock();
opp = dev_pm_opp_find_freq_ceil(cpu_dev, _Hz);
@@ -66,7 +107,8 @@ static int set_target(struct cpufreq_policy *policy,
unsigned int index)
rcu_read_unlock();
dev_err(cpu_dev, "failed to find OPP for %ld\n",
freq_Hz);
- return PTR_ERR(opp);
+ ret = PTR_ERR(opp);
+ goto out;
}
volt = dev_pm_opp_get_voltage(opp);
opp_freq = dev_pm_opp_get_freq(opp);
@@ -87,7 +129,7 @@ static int set_target(struct cpufreq_policy *policy,
unsigned int index)
if (ret) {
dev_err(cpu_dev, "failed to scale voltage up: %d\n",
ret);
- return ret;
+ goto out;
}
}
@@ -96,7 +138,7 @@ static int set_target(struct cpufreq_policy *policy,
unsigned int index)
dev_err(cpu_dev, "failed to set clock rate: %d\n", ret);
if (!IS_ERR(cpu_reg) && volt_old > 0)
regulator_set_voltage_tol(cpu_reg, volt_old, tol);
- return ret;
+ goto out;
}
/* scaling down? scale voltage after frequency */
@@ -106,9 +148,12 @@ static int set_target(struct cpufreq_policy *policy,
unsigned int index)
dev_err(cpu_dev, "failed to scale voltage down: %d\n",
ret);
clk_set_rate(cpu_clk, old_freq * 1000);
+
[PATCH 2/6] regulator: core: Print at debug level on debugfs creation failure
Failure to create a debugfs node is not an error, but we print a
warning upon failure to create the node. Downgrade this to a
debug printk so that we're quiet here. This allows multiple
drivers to request a CPU's regulator so that CPUfreq and AVSish
drivers can coexist.
The downside of this approach is that whoever gets to debugfs first
the others who come later to not have any debugfs attributes associated
with them.
Signed-off-by: Stephen Boyd
---
drivers/regulator/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index f6989485c382..9dba0a3d4526 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1208,7 +1208,7 @@ static struct regulator *create_regulator(struct
regulator_dev *rdev,
regulator->debugfs = debugfs_create_dir(regulator->supply_name,
rdev->debugfs);
if (!regulator->debugfs) {
- rdev_warn(rdev, "Failed to create debugfs directory\n");
+ rdev_dbg(rdev, "Failed to create debugfs directory\n");
} else {
debugfs_create_u32("uA_load", 0444, regulator->debugfs,
>uA_load);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH 4/6] OPP: Allow notifiers to call dev_pm_opp_get_{voltage,freq} RCU-free
We pass the dev_pm_opp structure to OPP notifiers but the users
of the notifier need to surround calls to dev_pm_opp_get_*() with
RCU read locks to avoid lockdep warnings. The notifier is already
called with the dev_opp's srcu lock held, so it should be safe to
assume the devm_pm_opp structure is already protected inside the
notifier. Update the lockdep check for this.
Cc: Krzysztof Kozlowski
Signed-off-by: Stephen Boyd
---
This is probably wrong, but it's what I had to hack up
to be able to use the OPP functions from within the notifier
to figure out the new values of the OPP without having to take
an RCU read lock.
drivers/base/power/opp.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index b997a7eabcd4..6d75022c6a0e 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -108,9 +108,10 @@ static LIST_HEAD(dev_opp_list);
/* Lock to allow exclusive modification to the device and opp lists */
static DEFINE_MUTEX(dev_opp_list_lock);
-#define opp_rcu_lockdep_assert() \
+#define opp_rcu_lockdep_assert(s) \
do { \
rcu_lockdep_assert(rcu_read_lock_held() || \
+ (s && srcu_read_lock_held(s)) ||\
lockdep_is_held(_opp_list_lock),\
"Missing rcu_read_lock() or "\
"dev_opp_list_lock protection"); \
@@ -169,9 +170,10 @@ unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp
*opp)
struct dev_pm_opp *tmp_opp;
unsigned long v = 0;
- opp_rcu_lockdep_assert();
+ opp_rcu_lockdep_assert(>dev_opp->srcu_head.srcu);
- tmp_opp = rcu_dereference(opp);
+ tmp_opp = srcu_dereference_check(opp, >dev_opp->srcu_head.srcu,
+rcu_read_lock_held());
if (unlikely(IS_ERR_OR_NULL(tmp_opp)) || !tmp_opp->available)
pr_err("%s: Invalid parameters\n", __func__);
else
@@ -201,9 +203,10 @@ unsigned long dev_pm_opp_get_freq(struct dev_pm_opp *opp)
struct dev_pm_opp *tmp_opp;
unsigned long f = 0;
- opp_rcu_lockdep_assert();
+ opp_rcu_lockdep_assert(>dev_opp->srcu_head.srcu);
- tmp_opp = rcu_dereference(opp);
+ tmp_opp = srcu_dereference_check(opp, >dev_opp->srcu_head.srcu,
+rcu_read_lock_held());
if (unlikely(IS_ERR_OR_NULL(tmp_opp)) || !tmp_opp->available)
pr_err("%s: Invalid parameters\n", __func__);
else
@@ -282,7 +285,7 @@ struct dev_pm_opp *dev_pm_opp_find_freq_exact(struct device
*dev,
struct device_opp *dev_opp;
struct dev_pm_opp *temp_opp, *opp = ERR_PTR(-ERANGE);
- opp_rcu_lockdep_assert();
+ opp_rcu_lockdep_assert(NULL);
dev_opp = _find_device_opp(dev);
if (IS_ERR(dev_opp)) {
@@ -330,7 +333,7 @@ struct dev_pm_opp *dev_pm_opp_find_freq_ceil(struct device
*dev,
struct device_opp *dev_opp;
struct dev_pm_opp *temp_opp, *opp = ERR_PTR(-ERANGE);
- opp_rcu_lockdep_assert();
+ opp_rcu_lockdep_assert(NULL);
if (!dev || !freq) {
dev_err(dev, "%s: Invalid argument freq=%p\n", __func__, freq);
@@ -380,7 +383,7 @@ struct dev_pm_opp *dev_pm_opp_find_freq_floor(struct device
*dev,
struct device_opp *dev_opp;
struct dev_pm_opp *temp_opp, *opp = ERR_PTR(-ERANGE);
- opp_rcu_lockdep_assert();
+ opp_rcu_lockdep_assert(NULL);
if (!dev || !freq) {
dev_err(dev, "%s: Invalid argument freq=%p\n", __func__, freq);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] PM / OPP: Support adjusting OPP voltages at runtime
On some SoCs the Adaptive Voltage Scaling (AVS) technique is
employed to optimize the operating voltage of a device. At a
given frequency, the hardware monitors dynamic factors and either
makes a suggestion for how much to adjust a voltage for the
current frequency, or it automatically adjusts the voltage
without software intervention. Add an API to the OPP library for
the former case, so that AVS type devices can update the voltages
for an OPP when the hardware determines the voltage should
change. The assumption is that drivers like CPUfreq or devfreq
will register for the OPP notifiers and adjust the voltage
according to suggestions that AVS makes.
Cc: Nishanth Menon
Cc: Viresh Kumar
Signed-off-by: Stephen Boyd
---
This should probably be cleanded up to share code with the enable/disable
APIs.
drivers/base/power/opp.c | 77
include/linux/pm_opp.h | 10 +++
2 files changed, 87 insertions(+)
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index 677fb2843553..b997a7eabcd4 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -748,6 +748,83 @@ unlock:
}
/**
+ * dev_pm_opp_adjust_voltage() - helper to change the voltage of an opp
+ * @dev: device for which we do this operation
+ * @freq: OPP frequency to adjust voltage of
+ * @u_volt:new OPP voltage
+ *
+ * Change the voltage of an OPP with an RCU operation.
+ *
+ * Return: -EINVAL for bad pointers, -ENOMEM if no memory available for the
+ * copy operation, returns 0 if no modifcation was done OR modification was
+ * successful.
+ *
+ * Locking: The internal device_opp and opp structures are RCU protected.
+ * Hence this function internally uses RCU updater strategy with mutex locks to
+ * keep the integrity of the internal data structures. Callers should ensure
+ * that this function is *NOT* called under RCU protection or in contexts where
+ * mutex locking or synchronize_rcu() blocking calls cannot be used.
+ */
+int dev_pm_opp_adjust_voltage(struct device *dev, unsigned long freq,
+unsigned long u_volt)
+{
+ struct device_opp *dev_opp;
+ struct dev_pm_opp *new_opp, *tmp_opp, *opp = ERR_PTR(-ENODEV);
+ int r = 0;
+
+ /* keep the node allocated */
+ new_opp = kmalloc(sizeof(*new_opp), GFP_KERNEL);
+ if (!new_opp)
+ return -ENOMEM;
+
+ mutex_lock(_opp_list_lock);
+
+ /* Find the device_opp */
+ dev_opp = _find_device_opp(dev);
+ if (IS_ERR(dev_opp)) {
+ r = PTR_ERR(dev_opp);
+ dev_warn(dev, "%s: Device OPP not found (%d)\n", __func__, r);
+ goto unlock;
+ }
+
+ /* Do we have the frequency? */
+ list_for_each_entry(tmp_opp, _opp->opp_list, node) {
+ if (tmp_opp->rate == freq) {
+ opp = tmp_opp;
+ break;
+ }
+ }
+ if (IS_ERR(opp)) {
+ r = PTR_ERR(opp);
+ goto unlock;
+ }
+
+ /* Is update really needed? */
+ if (opp->u_volt == u_volt)
+ goto unlock;
+ /* copy the old data over */
+ *new_opp = *opp;
+
+ /* plug in new node */
+ new_opp->u_volt = u_volt;
+
+ list_replace_rcu(>node, _opp->node);
+ mutex_unlock(_opp_list_lock);
+ call_srcu(_opp->srcu_head.srcu, >rcu_head, _kfree_opp_rcu);
+
+ /* Notify the change of the OPP */
+ srcu_notifier_call_chain(_opp->srcu_head, OPP_EVENT_ADJUST_VOLTAGE,
+new_opp);
+
+ return 0;
+
+unlock:
+ mutex_unlock(_opp_list_lock);
+ kfree(new_opp);
+ return r;
+}
+
+/**
* dev_pm_opp_enable() - Enable a specific OPP
* @dev: device for which we do this operation
* @freq: OPP frequency to enable
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index cec2d4540914..80f2c41e7daa 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -22,6 +22,7 @@ struct device;
enum dev_pm_opp_event {
OPP_EVENT_ADD, OPP_EVENT_REMOVE, OPP_EVENT_ENABLE, OPP_EVENT_DISABLE,
+ OPP_EVENT_ADJUST_VOLTAGE,
};
#if defined(CONFIG_PM_OPP)
@@ -46,6 +47,9 @@ int dev_pm_opp_add(struct device *dev, unsigned long freq,
unsigned long u_volt);
void dev_pm_opp_remove(struct device *dev, unsigned long freq);
+int dev_pm_opp_adjust_voltage(struct device *dev, unsigned long freq,
+ unsigned long u_volt);
+
int dev_pm_opp_enable(struct device *dev, unsigned long freq);
int dev_pm_opp_disable(struct device *dev, unsigned long freq);
@@ -95,6 +99,12 @@ static inline void dev_pm_opp_remove(struct device *dev,
unsigned long freq)
{
}
+static inline int dev_pm_opp_adjust_voltage(struct device *dev,
+ unsigned long freq, unsigned long u_volt)
+{
+ return 0;
+}
+
static inline int
[PATCH 0/6] Support CPR on MSM8916
This patch series adds support for CPR on MSM8916. It depends on
a few different patch series to be fully functional. It needs SPMI
regulator support[1] and secondly it needs the NVMEM framework[2].
It also needs a patch that provides a "corner" voting mechanism to the
SMD RPM regulators (and it relies on the SMD RPM regulators to function
properly). If possible I would like to get rid of that patch entirely.
Finally it needs CPU clock support to support scaling CPU frequencies.
Once you have those 4 or 5 patch series in place you can apply these
patches and enable cpufreq-dt and add the cpufreq-dt device (maybe the
CPR driver should add the cpufreq-dt device?) and you'll see interrupts
for CPR and OPP voltage adjustments triggering CPUfreq to modify voltages.
Stephen Boyd (6):
regulator: core: Don't spew backtraces on duplicate sysfs
regulator: core: Print at debug level on debugfs creation failure
PM / OPP: Support adjusting OPP voltages at runtime
OPP: Allow notifiers to call dev_pm_opp_get_{voltage,freq} RCU-free
cpufreq-dt: Handle OPP voltage adjust events
power: avs: Add support for CPR (Core Power Reduction)
drivers/base/power/opp.c | 96 +-
drivers/cpufreq/cpufreq-dt.c | 73 +-
drivers/power/avs/Kconfig| 14 +
drivers/power/avs/Makefile |1 +
drivers/power/avs/qcom-cpr.c | 1983 ++
drivers/regulator/core.c |6 +-
include/linux/pm_opp.h | 10 +
7 files changed, 2166 insertions(+), 17 deletions(-)
create mode 100644 drivers/power/avs/qcom-cpr.c
[1]
http://lkml.kernel.org/r/1431466787-32247-1-git-send-email-sb...@codeaurora.org
[2]
http://lkml.kernel.org/r/1432226535-8640-1-git-send-email-srinivas.kandaga...@linaro.org
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PCI: imx6: Return the function value directly
From: Fabio Estevam Simplify a trivial if-return sequence by returning the function value directly. The semantic patch that makes this change is available in scripts/coccinelle/misc/simple_return.cocci. Signed-off-by: Fabio Estevam --- drivers/pci/host/pci-imx6.c | 12 ++-- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c index fdb9536..f28f00d 100644 --- a/drivers/pci/host/pci-imx6.c +++ b/drivers/pci/host/pci-imx6.c @@ -115,11 +115,7 @@ static int pcie_phy_wait_ack(void __iomem *dbi_base, int addr) val = addr << PCIE_PHY_CTRL_DATA_LOC; writel(val, dbi_base + PCIE_PHY_CTRL); - ret = pcie_phy_poll_ack(dbi_base, 0); - if (ret) - return ret; - - return 0; + return pcie_phy_poll_ack(dbi_base, 0); } /* Read from the 16-bit PCIe PHY control registers (not memory-mapped) */ @@ -146,11 +142,7 @@ static int pcie_phy_read(void __iomem *dbi_base, int addr , int *data) /* deassert Read signal */ writel(0x00, dbi_base + PCIE_PHY_CTRL); - ret = pcie_phy_poll_ack(dbi_base, 0); - if (ret) - return ret; - - return 0; + return pcie_phy_poll_ack(dbi_base, 0); } static int pcie_phy_write(void __iomem *dbi_base, int addr, int data) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH kernel v11 28/34] vfio: powerpc/spapr: powerpc/powernv/ioda: Define and implement DMA windows API
On Fri, May 29, 2015 at 06:44:52PM +1000, Alexey Kardashevskiy wrote: > This extends iommu_table_group_ops by a set of callbacks to support > dynamic DMA windows management. > > create_table() creates a TCE table with specific parameters. > it receives iommu_table_group to know nodeid in order to allocate > TCE table memory closer to the PHB. The exact format of allocated > multi-level table might be also specific to the PHB model (not > the case now though). > This callback calculated the DMA window offset on a PCI bus from @num > and stores it in a just created table. > > set_window() sets the window at specified TVT index + @num on PHB. > > unset_window() unsets the window from specified TVT. > > This adds a free() callback to iommu_table_ops to free the memory > (potentially a tree of tables) allocated for the TCE table. > > create_table() and free() are supposed to be called once per > VFIO container and set_window()/unset_window() are supposed to be > called for every group in a container. > > This adds IOMMU capabilities to iommu_table_group such as default > 32bit window parameters and others. This makes use of new values in > vfio_iommu_spapr_tce. IODA1/P5IOC2 do not support DDW so they do not > advertise pagemasks to the userspace. > > Signed-off-by: Alexey Kardashevskiy > Acked-by: Alex Williamson Reviewed-by: David Gibson -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgp5HKZU_S4hN.pgp Description: PGP signature
Re: [PATCH kernel v11 30/34] powerpc/iommu/ioda2: Add get_table_size() to calculate the size of future table
On Fri, May 29, 2015 at 06:44:54PM +1000, Alexey Kardashevskiy wrote: > This adds a way for the IOMMU user to know how much a new table will > use so it can be accounted in the locked_vm limit before allocation > happens. > > This stores the allocated table size in pnv_pci_ioda2_get_table_size() > so the locked_vm counter can be updated correctly when a table is > being disposed. > > This defines an iommu_table_group_ops callback to let VFIO know > how much memory will be locked if a table is created. > > Signed-off-by: Alexey Kardashevskiy Reviewed-by: David Gibson -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgp1p9QMFxPHG.pgp Description: PGP signature
Re: [PATCH kernel v11 31/34] vfio: powerpc/spapr: powerpc/powernv/ioda2: Use DMA windows API in ownership control
On Fri, May 29, 2015 at 06:44:55PM +1000, Alexey Kardashevskiy wrote: > Before the IOMMU user (VFIO) would take control over the IOMMU table > belonging to a specific IOMMU group. This approach did not allow sharing > tables between IOMMU groups attached to the same container. > > This introduces a new IOMMU ownership flavour when the user can not > just control the existing IOMMU table but remove/create tables on demand. > If an IOMMU implements take/release_ownership() callbacks, this lets > the user have full control over the IOMMU group. When the ownership > is taken, the platform code removes all the windows so the caller must > create them. > Before returning the ownership back to the platform code, VFIO > unprograms and removes all the tables it created. > > This changes IODA2's onwership handler to remove the existing table > rather than manipulating with the existing one. From now on, > iommu_take_ownership() and iommu_release_ownership() are only called > from the vfio_iommu_spapr_tce driver. > > Old-style ownership is still supported allowing VFIO to run on older > P5IOC2 and IODA IO controllers. > > No change in userspace-visible behaviour is expected. Since it recreates > TCE tables on each ownership change, related kernel traces will appear > more often. > > This adds a pnv_pci_ioda2_setup_default_config() which is called > when PE is being configured at boot time and when the ownership is > passed from VFIO to the platform code. > > Signed-off-by: Alexey Kardashevskiy > [aw: for the vfio related changes] > Acked-by: Alex Williamson Reviewed-by: David Gibson -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpwDQDCyXQYn.pgp Description: PGP signature
Re: [PATCH kernel v11 32/34] powerpc/mmu: Add userspace-to-physical addresses translation cache
On Fri, May 29, 2015 at 06:44:56PM +1000, Alexey Kardashevskiy wrote: > We are adding support for DMA memory pre-registration to be used in > conjunction with VFIO. The idea is that the userspace which is going to > run a guest may want to pre-register a user space memory region so > it all gets pinned once and never goes away. Having this done, > a hypervisor will not have to pin/unpin pages on every DMA map/unmap > request. This is going to help with multiple pinning of the same memory. > > Another use of it is in-kernel real mode (mmu off) acceleration of > DMA requests where real time translation of guest physical to host > physical addresses is non-trivial and may fail as linux ptes may be > temporarily invalid. Also, having cached host physical addresses > (compared to just pinning at the start and then walking the page table > again on every H_PUT_TCE), we can be sure that the addresses which we put > into TCE table are the ones we already pinned. > > This adds a list of memory regions to mm_context_t. Each region consists > of a header and a list of physical addresses. This adds API to: > 1. register/unregister memory regions; > 2. do final cleanup (which puts all pre-registered pages); > 3. do userspace to physical address translation; > 4. manage usage counters; multiple registration of the same memory > is allowed (once per container). > > This implements 2 counters per registered memory region: > - @mapped: incremented on every DMA mapping; decremented on unmapping; > initialized to 1 when a region is just registered; once it becomes zero, > no more mappings allowe; > - @used: incremented on every "register" ioctl; decremented on > "unregister"; unregistration is allowed for DMA mapped regions unless > it is the very last reference. For the very last reference this checks > that the region is still mapped and returns -EBUSY so the userspace > gets to know that memory is still pinned and unregistration needs to > be retried; @used remains 1. > > Host physical addresses are stored in vmalloc'ed array. In order to > access these in the real mode (mmu off), there is a real_vmalloc_addr() > helper. In-kernel acceleration patchset will move it from KVM to MMU code. > > Signed-off-by: Alexey Kardashevskiy There's a bunch of ways this could be cleaned up, but those can be done later. So, Reviewed-by: David Gibson -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpNVjpols48V.pgp Description: PGP signature
Re: [PATCH kernel v11 29/34] powerpc/powernv/ioda2: Use new helpers to do proper cleanup on PE release
On Fri, May 29, 2015 at 06:44:53PM +1000, Alexey Kardashevskiy wrote: > The existing code programmed TVT#0 with some address and then > immediately released that memory. > > This makes use of pnv_pci_ioda2_unset_window() and > pnv_pci_ioda2_set_bypass() which do correct resource release and > TVT update. > > Signed-off-by: Alexey Kardashevskiy Reviewed-by: David Gibson -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpAk7NiUPQ9b.pgp Description: PGP signature
Re: Future of Ozwpan Driver - Maintainer? [Was: Re: [PATCH 0/4] ozwpan: Four remote packet-of-death vulnerabilities]
On Mon, Jun 01, 2015 at 03:34:57PM +0200, Jason A. Donenfeld wrote: > Hi all, > > With four security critical bug patches having finally been put in > Greg's for-linus branch [1][2][3][4], I'd like to turn attention back > at the bigger issue. Where is the maintainer of this driver during > these discussions? The MAINTAINERS file lists Shigekatsu Tateno, and > in a commit [5] from May of last year, Rupesh Gujare turned over > maintenance to him. > > I ask because I also noted another important vulnerability in my > original patch series cover letter, with the hope that the actual > maintainer would take care of patching this, as it is likely a little > bit nuanced: > > On Wed, May 13, 2015 at 8:33 PM, Jason A. Donenfeld wrote: > > On a slightly related note, there are several other vulnerabilities in > > this driver that are worth looking into. When ozwpan receives a packet, > > it casts the packet into a variety of different structs, based on the > > value of type and length parameters inside the packet. When making these > > casts, and when reading bytes based on this length parameter, the actual > > length of the packet in the socket buffer is never actually consulted. As > > such, it's very likely that a packet could be sent that results in the > > kernel reading memory in adjacent buffers, resulting in an information > > leak, or from unpaged addresses, resulting in a crash. In the former case, > > it may be possible with certain message types to actually send these > > leaked adjacent bytes back to the sender of the packet. So, I'd highly > > recommend the maintainers of this driver go branch-by-branch from the > > initial rx function, adding checks to ensure all reads and casts are > > within the bounds of the socket buffer. > > It seems a bit odd to not receive any review from the actual > maintainer, and seeing that there is still a pending security issue > that hasn't been addressed, I wonder if we should revisit what Dan > suggested last week: > > On Thu, May 28, 2015 at 1:04 PM, Dan Carpenter > wrote: > > Maybe we should just delete these ozwpan drivers entirely... They were > > merged when Ozmodevices was its own company and I don't think anyone is > > working on them any more. > > I know for a fact that the drivers *are* in use places, though not > necessarily with the upstream codebase. Also, it was more or less > exactly a year ago when Atmel appointed the new maintainer, which > makes me hope that somebody there still cares about them. But I'm not > sure exactly. > > What's the best way to proceed? Is anybody in a position to reach out > and nudge the maintainer? Or is it just the case that Atmel's vacation > policy is awesome, and he's just been hanging out on the beach, and > I'm jumping the gun with this email? I don't know, but I'm a bit loath to delete the driver from the tree as then people will just continue to use the version with all of the bugs. If Atmel doesn't want to maintain the code anymore, do you want to do it? You can always send patches for this issue, as you seem to have the hardware and can do testing, which I can't. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] regulator: wm831x: Pass the IRQF_ONESHOT flag
From: Fabio Estevam
Since commit 1c6c69525b40 ("genirq: Reject bogus threaded irq requests")
threaded IRQs without a primary handler need to be requested with
IRQF_ONESHOT, otherwise the request will fail.
So pass the IRQF_ONESHOT flag in this case.
The semantic patch that makes this change is available
in scripts/coccinelle/misc/irqf_oneshot.cocci.
Signed-off-by: Fabio Estevam
---
drivers/regulator/wm831x-dcdc.c | 12
drivers/regulator/wm831x-isink.c | 3 ++-
drivers/regulator/wm831x-ldo.c | 6 --
3 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/regulator/wm831x-dcdc.c b/drivers/regulator/wm831x-dcdc.c
index 0d7e164..8cbb82c 100644
--- a/drivers/regulator/wm831x-dcdc.c
+++ b/drivers/regulator/wm831x-dcdc.c
@@ -533,7 +533,8 @@ static int wm831x_buckv_probe(struct platform_device *pdev)
irq = wm831x_irq(wm831x, platform_get_irq_byname(pdev, "UV"));
ret = devm_request_threaded_irq(>dev, irq, NULL,
wm831x_dcdc_uv_irq,
- IRQF_TRIGGER_RISING, dcdc->name, dcdc);
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+ dcdc->name, dcdc);
if (ret != 0) {
dev_err(>dev, "Failed to request UV IRQ %d: %d\n",
irq, ret);
@@ -543,7 +544,8 @@ static int wm831x_buckv_probe(struct platform_device *pdev)
irq = wm831x_irq(wm831x, platform_get_irq_byname(pdev, "HC"));
ret = devm_request_threaded_irq(>dev, irq, NULL,
wm831x_dcdc_oc_irq,
- IRQF_TRIGGER_RISING, dcdc->name, dcdc);
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+ dcdc->name, dcdc);
if (ret != 0) {
dev_err(>dev, "Failed to request HC IRQ %d: %d\n",
irq, ret);
@@ -669,7 +671,8 @@ static int wm831x_buckp_probe(struct platform_device *pdev)
irq = wm831x_irq(wm831x, platform_get_irq_byname(pdev, "UV"));
ret = devm_request_threaded_irq(>dev, irq, NULL,
wm831x_dcdc_uv_irq,
- IRQF_TRIGGER_RISING, dcdc->name, dcdc);
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+ dcdc->name, dcdc);
if (ret != 0) {
dev_err(>dev, "Failed to request UV IRQ %d: %d\n",
irq, ret);
@@ -785,7 +788,8 @@ static int wm831x_boostp_probe(struct platform_device *pdev)
irq = wm831x_irq(wm831x, platform_get_irq_byname(pdev, "UV"));
ret = devm_request_threaded_irq(>dev, irq, NULL,
wm831x_dcdc_uv_irq,
- IRQF_TRIGGER_RISING, dcdc->name,
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+ dcdc->name,
dcdc);
if (ret != 0) {
dev_err(>dev, "Failed to request UV IRQ %d: %d\n",
diff --git a/drivers/regulator/wm831x-isink.c b/drivers/regulator/wm831x-isink.c
index 1e88391..1442828 100644
--- a/drivers/regulator/wm831x-isink.c
+++ b/drivers/regulator/wm831x-isink.c
@@ -204,7 +204,8 @@ static int wm831x_isink_probe(struct platform_device *pdev)
irq = wm831x_irq(wm831x, platform_get_irq(pdev, 0));
ret = devm_request_threaded_irq(>dev, irq, NULL,
wm831x_isink_irq,
- IRQF_TRIGGER_RISING, isink->name,
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+ isink->name,
isink);
if (ret != 0) {
dev_err(>dev, "Failed to request ISINK IRQ %d: %d\n",
diff --git a/drivers/regulator/wm831x-ldo.c b/drivers/regulator/wm831x-ldo.c
index 7ae2dc8..5a7b65e 100644
--- a/drivers/regulator/wm831x-ldo.c
+++ b/drivers/regulator/wm831x-ldo.c
@@ -287,7 +287,8 @@ static int wm831x_gp_ldo_probe(struct platform_device *pdev)
irq = wm831x_irq(wm831x, platform_get_irq_byname(pdev, "UV"));
ret = devm_request_threaded_irq(>dev, irq, NULL,
wm831x_ldo_uv_irq,
- IRQF_TRIGGER_RISING, ldo->name,
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+ ldo->name,
ldo);
if (ret != 0) {
dev_err(>dev, "Failed to request UV IRQ %d: %d\n",
@@ -496,7 +497,8 @@ static int wm831x_aldo_probe(struct platform_device *pdev)
irq = wm831x_irq(wm831x, platform_get_irq_byname(pdev, "UV"));
ret = devm_request_threaded_irq(>dev, irq, NULL,
Re: [PATCH 2/2] Bluetooth: btusb: Add reset_resume function
Hi Laura,
> Some USB hubs may lose power across suspend/resume.
> Add a reset_resume callback to properly reset those bluetoot devices.
>
> Signed-off-by: Laura Abbott
> ---
> Now the setup function is called again with the HCI_RESET_RESUME
> flag set. The various functions could then use that RESET_RESUME
> flag to determine if loading the firmware is appropriate or not.
> ---
> drivers/bluetooth/btusb.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 3c10d4d..34884cf 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -3382,6 +3382,21 @@ done:
>
> return err;
> }
> +
> +static int btusb_reset_resume(struct usb_interface *intf)
> +{
> + struct btusb_data *data = usb_get_intfdata(intf);
> + struct hci_dev *hdev = data->hdev;
> + int ret;
> +
> + BT_DBG("intf %p", intf);
> +
> + ret = btusb_resume(intf);
> + if (ret)
> + return ret;
> +
> + return hci_reset_resume_dev(hdev);
> +}
it seems convenient to call btusb_resume, but I would really prefer if we
didn’t. From what I know is that when reset_resume callback is called, then the
device has been reset. So that means any prior transfer we have remembered is
null and void. So even trying to replay any of it is just a lost cause.
Instead we should clear any pending transfers and clear everything and instead
pretend that we bring the transport back to its virgin state. It also means
that isochronous transfers should be all killed since we will have no SCO
connections after this. Remember that we are telling the Bluetooth core to
reset this device.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1] staging: lustre: libcfs: add __user annotation in libcfs_ioctl_data
On Mon, Jun 01, 2015 at 12:21:30PM -0700, David Decotigny wrote: > Thanks for reviewing. > > The 2 struct members were not marked as __user, which this patch does > here. This was causing warnings with copy from/to user (see commit > description). This patch also propagates the annotation to the couple > of functions that are using those members. Lustre's structures are a total mess of kernel and user pointers and trying to properly mark them as which they are supposed to be at what point in time is a very difficult task. People keep trying and get it wrong, so I suggest just leaving this alone until the developers unwind the structure mess as that will be necessary for this code to get merged into the main part of the kernel. sorry, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/6] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others
Hi Stefan, Late review... On Wed, Mar 25, 2015 at 05:28:24PM +0100, Stefan Agner wrote: > This driver supports Freescale NFC (NAND flash controller) found on > Vybrid (VF610), MPC5125, MCF54418 and Kinetis K70. > > Limitations: > - DMA and pipelining not used > - Pages larger than 2k are not supported > - No hardware ECC > > The driver has only been tested on Vybrid (VF610). > > Signed-off-by: Bill Pringlemeir > Signed-off-by: Stefan Agner > --- > MAINTAINERS | 6 + > drivers/mtd/nand/Kconfig | 12 + > drivers/mtd/nand/Makefile| 1 + > drivers/mtd/nand/vf610_nfc.c | 686 > +++ > 4 files changed, 705 insertions(+) > create mode 100644 drivers/mtd/nand/vf610_nfc.c > ... > diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c > new file mode 100644 > index 000..23c1510 > --- /dev/null > +++ b/drivers/mtd/nand/vf610_nfc.c > @@ -0,0 +1,686 @@ > +/* > + * Copyright 2009-2015 Freescale Semiconductor, Inc. and others > + * > + * Description: MPC5125, VF610, MCF54418 and Kinetis K70 Nand driver. > + * Jason ported to M54418TWR and MVFA5 (VF610). > + * Authors: Stefan Agner > + * Bill Pringlemeir > + * Shaohui Xie > + * Jason Jin > + * > + * Based on original driver mpc5121_nfc.c. It's not supremely obvious to me: what's the relationship between these drivers? How similar is the IP, if at all? > + * > + * This 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. > + * > + * Limitations: > + * - Untested on MPC5125 and M54418. > + * - DMA not used. > + * - 2K pages or less. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define DRV_NAME"vf610_nfc" > + > +/* Register Offsets */ > +#define NFC_FLASH_CMD1 0x3F00 > +#define NFC_FLASH_CMD2 0x3F04 > +#define NFC_COL_ADDR 0x3F08 > +#define NFC_ROW_ADDR 0x3F0c > +#define NFC_ROW_ADDR_INC 0x3F14 > +#define NFC_FLASH_STATUS10x3F18 > +#define NFC_FLASH_STATUS20x3F1c > +#define NFC_CACHE_SWAP 0x3F28 > +#define NFC_SECTOR_SIZE 0x3F2c > +#define NFC_FLASH_CONFIG 0x3F30 > +#define NFC_IRQ_STATUS 0x3F38 > + > +/* Addresses for NFC MAIN RAM BUFFER areas */ > +#define NFC_MAIN_AREA(n) ((n) * 0x1000) > + > +#define PAGE_2K 0x0800 > +#define OOB_64 0x0040 > + > +/* > + * NFC_CMD2[CODE] values. See section: > + * - 31.4.7 Flash Command Code Description, Vybrid manual > + * - 23.8.6 Flash Command Sequencer, MPC5125 manual > + * > + * Briefly these are bitmasks of controller cycles. > + */ > +#define READ_PAGE_CMD_CODE 0x7EE0 > +#define PROGRAM_PAGE_CMD_CODE0x7FC0 > +#define ERASE_CMD_CODE 0x4EC0 > +#define READ_ID_CMD_CODE 0x4804 > +#define RESET_CMD_CODE 0x4040 > +#define STATUS_READ_CMD_CODE 0x4068 > + > +/* NFC ECC mode define */ > +#define ECC_BYPASS 0 > + > +/*** Register Mask and bit definitions */ > + > +/* NFC_FLASH_CMD1 Field */ > +#define CMD_BYTE2_MASK 0xFF00 > +#define CMD_BYTE2_SHIFT 24 > + > +/* NFC_FLASH_CM2 Field */ > +#define CMD_BYTE1_MASK 0xFF00 > +#define CMD_BYTE1_SHIFT 24 > +#define CMD_CODE_MASK0x0000 > +#define CMD_CODE_SHIFT 8 > +#define BUFNO_MASK 0x0006 > +#define BUFNO_SHIFT 1 > +#define START_BIT(1<<0) > + > +/* NFC_COL_ADDR Field */ > +#define COL_ADDR_MASK0x > +#define COL_ADDR_SHIFT 0 > + > +/* NFC_ROW_ADDR Field */ > +#define ROW_ADDR_MASK0x00FF > +#define ROW_ADDR_SHIFT 0 > +#define ROW_ADDR_CHIP_SEL_RB_MASK0xF000 > +#define ROW_ADDR_CHIP_SEL_RB_SHIFT 28 > +#define ROW_ADDR_CHIP_SEL_MASK 0x0F00 > +#define ROW_ADDR_CHIP_SEL_SHIFT 24 > + > +/* NFC_FLASH_STATUS2 Field */ > +#define STATUS_BYTE1_MASK0x00FF > + > +/* NFC_FLASH_CONFIG Field */ > +#define CONFIG_ECC_SRAM_REQ_BIT (1<<21) > +#define CONFIG_DMA_REQ_BIT (1<<20) > +#define CONFIG_ECC_MODE_MASK 0x000E > +#define
[RFC 7/9] net: dsa: mv88e6352: lock CPU port from learning addresses
This commit disables SA learning and refreshing for the CPU port. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx.c | 8 +--- drivers/net/dsa/mv88e6xxx.h | 1 + 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c index d2beb10..ed49bd8 100644 --- a/drivers/net/dsa/mv88e6xxx.c +++ b/drivers/net/dsa/mv88e6xxx.c @@ -1761,10 +1761,12 @@ static int mv88e6xxx_setup_port(struct dsa_switch *ds, int port) /* Port Association Vector: when learning source addresses * of packets, add the address to the address database using * a port bitmap that has only the bit for this port set and -* the other bits clear. +* the other bits clear, except for the CPU port. */ - ret = _mv88e6xxx_reg_write(ds, REG_PORT(port), PORT_ASSOC_VECTOR, - 1 << port); + reg = BIT(port); + if (dsa_is_cpu_port(ds, port)) + reg |= PORT_ASSOC_VECTOR_LOCKED_PORT; + ret = _mv88e6xxx_reg_write(ds, REG_PORT(port), PORT_ASSOC_VECTOR, reg); if (ret) goto abort; diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h index 412d14e..e26eb0c 100644 --- a/drivers/net/dsa/mv88e6xxx.h +++ b/drivers/net/dsa/mv88e6xxx.h @@ -144,6 +144,7 @@ #define PORT_RATE_CONTROL 0x09 #define PORT_RATE_CONTROL_20x0a #define PORT_ASSOC_VECTOR 0x0b +#define PORT_ASSOC_VECTOR_LOCKED_PORT BIT(13) #define PORT_ATU_CONTROL 0x0c #define PORT_PRI_OVERRIDE 0x0d #define PORT_ETH_TYPE 0x0f -- 2.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 3/9] net: dsa: mv88e6xxx: add support for VTU ops
This commit implements the port_vlan_add and port_vlan_del functions in
the dsa_switch_driver structure for Marvell 88E6xxx compatible switches.
This allows to access a switch VLAN Table Unit, and thus define VLANs
from standard userspace commands such as "bridge vlan".
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx.c | 278
drivers/net/dsa/mv88e6xxx.h | 27 +
2 files changed, 305 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 7fba330..49ef2f8 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -2,6 +2,9 @@
* net/dsa/mv88e6xxx.c - Marvell 88e6xxx switch chip support
* Copyright (c) 2008 Marvell Semiconductor
*
+ * Copyright (c) 2015 CMC Electronics, Inc.
+ * Added support for 802.1q VLAN Table Unit operations
+ *
* 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
@@ -1348,6 +1351,281 @@ static void mv88e6xxx_bridge_work(struct work_struct
*work)
}
}
+static int _mv88e6xxx_vtu_wait(struct dsa_switch *ds)
+{
+ return _mv88e6xxx_wait(ds, REG_GLOBAL, GLOBAL_VTU_OP,
+ GLOBAL_VTU_OP_BUSY);
+}
+
+static int _mv88e6xxx_vtu_cmd(struct dsa_switch *ds, u16 op)
+{
+ int ret;
+
+ ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_VTU_OP, op);
+ if (ret < 0)
+ return ret;
+
+ return _mv88e6xxx_vtu_wait(ds);
+}
+
+static int _mv88e6xxx_stu_loadpurge(struct dsa_switch *ds, u8 sid, bool valid)
+{
+ int ret, data;
+
+ ret = _mv88e6xxx_vtu_wait(ds);
+ if (ret < 0)
+ return ret;
+
+ data = sid & GLOBAL_VTU_SID_MASK;
+ if (valid)
+ data |= GLOBAL_VTU_VID_VALID;
+
+ ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_VTU_VID, data);
+ if (ret < 0)
+ return ret;
+
+ /* Unused (yet) data registers */
+ ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_VTU_DATA_0_3, 0);
+ if (ret < 0)
+ return ret;
+
+ ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_VTU_DATA_4_7, 0);
+ if (ret < 0)
+ return ret;
+
+ ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_VTU_DATA_8_11, 0);
+ if (ret < 0)
+ return ret;
+
+ return _mv88e6xxx_vtu_cmd(ds, GLOBAL_VTU_OP_STU_LOAD_PURGE);
+}
+
+static int _mv88e6xxx_vtu_getnext(struct dsa_switch *ds, u16 vid,
+ struct mv88e6xxx_vtu_entry *entry)
+{
+ int ret, i;
+
+ ret = _mv88e6xxx_vtu_wait(ds);
+ if (ret < 0)
+ return ret;
+
+ ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_VTU_VID,
+ vid & GLOBAL_VTU_VID_MASK);
+ if (ret < 0)
+ return ret;
+
+ ret = _mv88e6xxx_vtu_cmd(ds, GLOBAL_VTU_OP_VTU_GET_NEXT);
+ if (ret < 0)
+ return ret;
+
+ ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL, GLOBAL_VTU_VID);
+ if (ret < 0)
+ return ret;
+
+ entry->vid = ret & GLOBAL_VTU_VID_MASK;
+ entry->valid = !!(ret & GLOBAL_VTU_VID_VALID);
+
+ if (entry->valid) {
+ /* Ports 0-3, offsets 0, 4, 8, 12 */
+ ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL, GLOBAL_VTU_DATA_0_3);
+ if (ret < 0)
+ return ret;
+
+ for (i = 0; i < 4; ++i)
+ entry->tags[i] = (ret >> (i * 4)) & 3;
+
+ /* Ports 4-6, offsets 0, 4, 8 */
+ ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL, GLOBAL_VTU_DATA_4_7);
+ if (ret < 0)
+ return ret;
+
+ for (i = 4; i < 7; ++i)
+ entry->tags[i] = (ret >> ((i - 4) * 4)) & 3;
+
+ ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL, GLOBAL_VTU_FID);
+ if (ret < 0)
+ return ret;
+
+ entry->fid = ret & GLOBAL_VTU_FID_MASK;
+
+ ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL, GLOBAL_VTU_SID);
+ if (ret < 0)
+ return ret;
+
+ entry->sid = ret & GLOBAL_VTU_SID_MASK;
+ }
+
+ return 0;
+}
+
+static int _mv88e6xxx_vtu_loadpurge(struct dsa_switch *ds,
+ struct mv88e6xxx_vtu_entry *entry)
+{
+ u16 data = 0;
+ int ret, i;
+
+ ret = _mv88e6xxx_vtu_wait(ds);
+ if (ret < 0)
+ return ret;
+
+ if (entry->valid) {
+ /* Set Data Register, ports 0-3, offsets 0, 4, 8, 12 */
+ for (data = i = 0; i < 4; ++i)
+ data |= entry->tags[i] << (i * 4);
+ ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_VTU_DATA_0_3,
+ data);
+
[RFC 8/9] net: dsa: mv88e6352: set port 802.1Q mode to Secure
This commit changes the 802.1Q mode of each port from Disabled to
Secure. This enables the VLAN support, by checking the VTU entries on
ingress.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx.c | 14 +++---
drivers/net/dsa/mv88e6xxx.h | 5 +
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index ed49bd8..35243d8 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -1723,13 +1723,11 @@ static int mv88e6xxx_setup_port(struct dsa_switch *ds,
int port)
goto abort;
}
- /* Port Control 2: don't force a good FCS, set the maximum
-* frame size to 10240 bytes, don't let the switch add or
-* strip 802.1q tags, don't discard tagged or untagged frames
-* on this port, do a destination address lookup on all
-* received packets as usual, disable ARP mirroring and don't
-* send a copy of all transmitted/received frames on this port
-* to the CPU.
+ /* Port Control 2: don't force a good FCS, set the maximum frame size to
+* 10240 bytes, enable secure 802.1q tags, don't discard tagged or
+* untagged frames on this port, do a destination address lookup on all
+* received packets as usual, disable ARP mirroring and don't send a
+* copy of all transmitted/received frames on this port to the CPU.
*/
reg = 0;
if (mv88e6xxx_6352_family(ds) || mv88e6xxx_6351_family(ds) ||
@@ -1751,6 +1749,8 @@ static int mv88e6xxx_setup_port(struct dsa_switch *ds,
int port)
reg |= PORT_CONTROL_2_FORWARD_UNKNOWN;
}
+ reg |= PORT_CONTROL_2_8021Q_SECURE;
+
if (reg) {
ret = _mv88e6xxx_reg_write(ds, REG_PORT(port),
PORT_CONTROL_2, reg);
diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
index e26eb0c..02528aa 100644
--- a/drivers/net/dsa/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx.h
@@ -134,6 +134,11 @@
#define PORT_CONTROL_2_JUMBO_1522 (0x00 << 12)
#define PORT_CONTROL_2_JUMBO_2048 (0x01 << 12)
#define PORT_CONTROL_2_JUMBO_10240 (0x02 << 12)
+#define PORT_CONTROL_2_8021Q_MASK (0x03 << 10)
+#define PORT_CONTROL_2_8021Q_DISABLED (0x00 << 10)
+#define PORT_CONTROL_2_8021Q_FALLBACK (0x01 << 10)
+#define PORT_CONTROL_2_8021Q_CHECK (0x02 << 10)
+#define PORT_CONTROL_2_8021Q_SECURE(0x03 << 10)
#define PORT_CONTROL_2_DISCARD_TAGGED BIT(9)
#define PORT_CONTROL_2_DISCARD_UNTAGGEDBIT(8)
#define PORT_CONTROL_2_MAP_DA BIT(7)
--
2.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 5/9] net: dsa: mv88e6352: disable mirroring
Disable the mirroring policy in the monitor control register, since this feature is not needed. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6352.c | 10 +++--- drivers/net/dsa/mv88e6xxx.h | 1 + 2 files changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c index 838494a..f541362 100644 --- a/drivers/net/dsa/mv88e6352.c +++ b/drivers/net/dsa/mv88e6352.c @@ -63,13 +63,9 @@ static int mv88e6352_setup_global(struct dsa_switch *ds) REG_WRITE(REG_GLOBAL, GLOBAL_CONTROL, GLOBAL_CONTROL_PPU_ENABLE | GLOBAL_CONTROL_DISCARD_EXCESS); - /* Configure the upstream port, and configure the upstream -* port as the port to which ingress and egress monitor frames -* are to be sent. -*/ - reg = upstream_port << GLOBAL_MONITOR_CONTROL_INGRESS_SHIFT | - upstream_port << GLOBAL_MONITOR_CONTROL_EGRESS_SHIFT | - upstream_port << GLOBAL_MONITOR_CONTROL_ARP_SHIFT; + /* Configure the upstream port, and disable policy mirroring. */ + reg = upstream_port << GLOBAL_MONITOR_CONTROL_ARP_SHIFT | + GLOBAL_MONITOR_CONTROL_MIRROR_DISABLED; REG_WRITE(REG_GLOBAL, GLOBAL_MONITOR_CONTROL, reg); /* Disable remote management for now, and set the switch's diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h index 42032c3..f4ea66a 100644 --- a/drivers/net/dsa/mv88e6xxx.h +++ b/drivers/net/dsa/mv88e6xxx.h @@ -237,6 +237,7 @@ #define GLOBAL_MONITOR_CONTROL_ARP_SHIFT 4 #define GLOBAL_MONITOR_CONTROL_MIRROR_SHIFT0 #define GLOBAL_MONITOR_CONTROL_ARP_DISABLED(0xf0) +#define GLOBAL_MONITOR_CONTROL_MIRROR_DISABLED 0x0f #define GLOBAL_CONTROL_2 0x1c #define GLOBAL_CONTROL_2_NO_CASCADE0xe000 #define GLOBAL_CONTROL_2_MULTIPLE_CASCADE 0xf000 -- 2.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 4/9] net: dsa: mv88e6352: add support for VLAN
This commit adds support for the VTU operations to the mv88e6352 driver.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6352.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c
index b524bd3..838494a 100644
--- a/drivers/net/dsa/mv88e6352.c
+++ b/drivers/net/dsa/mv88e6352.c
@@ -397,6 +397,8 @@ struct dsa_switch_driver mv88e6352_switch_driver = {
.fdb_add= mv88e6xxx_port_fdb_add,
.fdb_del= mv88e6xxx_port_fdb_del,
.fdb_getnext= mv88e6xxx_port_fdb_getnext,
+ .port_vlan_add = mv88e6xxx_port_vlan_add,
+ .port_vlan_del = mv88e6xxx_port_vlan_del,
};
MODULE_ALIAS("platform:mv88e6352");
--
2.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Bluetooth: Add reset_resume function
Hi Laura,
> Bluetooth devices off of some buses such as USB may lose power across
> suspend/resume. When this happens, drivers may need to have the setup
> function called again and behave differently than a cold power on.
> Add a reset_resume function for drivers to call. During the
> reset_resume case, the flag HCI_RESET_RESUME will be set to allow
> drivers to differentate.
>
> Signed-off-by: Laura Abbott
> ---
> This matches with what hci_reset_dev does and also ensures
> the setup function gets called again.
> ---
> include/net/bluetooth/hci.h | 1 +
> include/net/bluetooth/hci_core.h | 1 +
> net/bluetooth/hci_core.c | 16
> 3 files changed, 18 insertions(+)
>
> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> index d95da83..6285410 100644
> --- a/include/net/bluetooth/hci.h
> +++ b/include/net/bluetooth/hci.h
> @@ -185,6 +185,7 @@ enum {
> HCI_RAW,
>
> HCI_RESET,
> + HCI_RESET_RESUME,
> };
no more addition to this list of flags please. These are userspace exposed
flags and with that ABI that we are never ever touching again. If you need
flags on a per device basis, then use the second list.
> /* HCI socket flags */
> diff --git a/include/net/bluetooth/hci_core.h
> b/include/net/bluetooth/hci_core.h
> index a056c2b..14f9c72 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -941,6 +941,7 @@ int hci_register_dev(struct hci_dev *hdev);
> void hci_unregister_dev(struct hci_dev *hdev);
> int hci_suspend_dev(struct hci_dev *hdev);
> int hci_resume_dev(struct hci_dev *hdev);
> +int hci_reset_resume_dev(struct hci_dev *hdev);
> int hci_reset_dev(struct hci_dev *hdev);
> int hci_dev_open(__u16 dev);
> int hci_dev_close(__u16 dev);
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index c4802f3..090762b 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -1558,6 +1558,7 @@ static int hci_dev_do_close(struct hci_dev *hdev)
> BT_DBG("%s %p", hdev->name, hdev);
>
> if (!hci_dev_test_flag(hdev, HCI_UNREGISTER) &&
> + !test_bit(HCI_RESET_RESUME, >flags) &&
> test_bit(HCI_UP, >flags)) {
> /* Execute vendor specific shutdown routine */
> if (hdev->shutdown)
> @@ -2110,6 +2111,7 @@ static void hci_power_on(struct work_struct *work)
>*/
> mgmt_index_added(hdev);
> }
> + hci_dev_test_and_clear_flag(hdev, HCI_RESET_RESUME);
If you do not use the result of the test, why bother testing at all. Also you
realize that you are a now clearing the flag on hdev->dev_flags and not
hdev->flags.
It also means that this code is not tested when you actually have had a reset
resume and then get a clean power down. Not running the shutdown procedure
would be actually wrong in that case.
> }
>
> static void hci_power_off(struct work_struct *work)
> @@ -3298,6 +3300,20 @@ int hci_reset_dev(struct hci_dev *hdev)
> }
> EXPORT_SYMBOL(hci_reset_dev);
>
> +/*
> + * For USB reset_resume callbacks
> + */
> +int hci_reset_resume_dev(struct hci_dev *hdev)
> +{
> + set_bit(HCI_RESET_RESUME, >flags);
> + hci_dev_do_close(hdev);
> + hci_dev_set_flag(hdev, HCI_SETUP);
> +
> + queue_work(hdev->req_workqueue, >power_on);
> + return 0;
> +}
> +EXPORT_SYMBOL(hci_reset_resume_dev);
> +
When we are reacting to a hardware error, we do hci_dev_do_close followed
hci_dev_do_open. Why would you queue the power on work here. It sounds more
like that this should be actually similar to hci_error_reset that gets queued.
And this is where I said the really tricky part comes in. Is the device keeping
the firmware or not. We really need to know that one first. If it keeps its
firmware, then we do not need to run through hdev->setup again.
>From a driver point of view, the current guarantee is that hdev->setup is only
>executed once. And this means really only once. It does not need to protect
>itself against being run again. So it should only be run again if the device
>looses all its states.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 1/9] net: dsa: add basic support for switchdev obj
This patch adds the switchdev operations to add and delete switchdev
objects. This will be necessary to add fdb or VLAN entries.
Signed-off-by: Vivien Didelot
---
net/dsa/slave.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 04ffad3..cbda00a 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -363,6 +363,43 @@ static int dsa_slave_port_attr_set(struct net_device *dev,
return ret;
}
+static int dsa_slave_port_obj_add(struct net_device *dev,
+ struct switchdev_obj *obj)
+{
+ int err;
+
+ /*
+* Skip the prepare phase, since currently the DSA drivers don't need to
+* allocate any memory for operations and they will not fail to HW
+* (unless something horrible goes wrong on the MDIO bus, in which case
+* the prepare phase wouldn't have been able to predict anyway).
+*/
+ if (obj->trans != SWITCHDEV_TRANS_COMMIT)
+ return 0;
+
+ switch (obj->id) {
+ default:
+ err = -ENOTSUPP;
+ break;
+ }
+
+ return err;
+}
+
+static int dsa_slave_port_obj_del(struct net_device *dev,
+ struct switchdev_obj *obj)
+{
+ int err;
+
+ switch (obj->id) {
+ default:
+ err = -EOPNOTSUPP;
+ break;
+ }
+
+ return err;
+}
+
static int dsa_slave_bridge_port_join(struct net_device *dev,
struct net_device *br)
{
@@ -702,6 +739,8 @@ static const struct net_device_ops dsa_slave_netdev_ops = {
static const struct switchdev_ops dsa_slave_switchdev_ops = {
.switchdev_port_attr_get= dsa_slave_port_attr_get,
.switchdev_port_attr_set= dsa_slave_port_attr_set,
+ .switchdev_port_obj_add = dsa_slave_port_obj_add,
+ .switchdev_port_obj_del = dsa_slave_port_obj_del,
};
static void dsa_slave_adjust_link(struct net_device *dev)
--
2.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 2/9] net: dsa: add basic support for VLAN operations
This patch adds the glue between DSA and switchdev to add and delete
SWITCHDEV_OBJ_PORT_VLAN objects.
This will allow the DSA switch drivers implementing the port_vlan_add
and port_vlan_del functions to access the switch VLAN database through
userspace commands such as "bridge vlan".
Signed-off-by: Vivien Didelot
---
include/net/dsa.h | 7 +++
net/dsa/slave.c | 61 +--
2 files changed, 66 insertions(+), 2 deletions(-)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index fbca63b..726357b 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -302,6 +302,13 @@ struct dsa_switch_driver {
const unsigned char *addr, u16 vid);
int (*fdb_getnext)(struct dsa_switch *ds, int port,
unsigned char *addr, bool *is_static);
+
+ /*
+* VLAN support
+*/
+ int (*port_vlan_add)(struct dsa_switch *ds, int port, u16 vid,
+u16 bridge_flags);
+ int (*port_vlan_del)(struct dsa_switch *ds, int port, u16 vid);
};
void register_switch_driver(struct dsa_switch_driver *type);
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index cbda00a..52ba5a1 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -363,6 +363,25 @@ static int dsa_slave_port_attr_set(struct net_device *dev,
return ret;
}
+static int dsa_slave_port_vlans_add(struct net_device *dev,
+ struct switchdev_obj_vlan *vlan)
+{
+ struct dsa_slave_priv *p = netdev_priv(dev);
+ struct dsa_switch *ds = p->parent;
+ int vid, err = 0;
+
+ if (!ds->drv->port_vlan_add)
+ return -ENOTSUPP;
+
+ for (vid = vlan->vid_start; vid <= vlan->vid_end; ++vid) {
+ err = ds->drv->port_vlan_add(ds, p->port, vid, vlan->flags);
+ if (err)
+ break;
+ }
+
+ return err;
+}
+
static int dsa_slave_port_obj_add(struct net_device *dev,
struct switchdev_obj *obj)
{
@@ -378,6 +397,9 @@ static int dsa_slave_port_obj_add(struct net_device *dev,
return 0;
switch (obj->id) {
+ case SWITCHDEV_OBJ_PORT_VLAN:
+ err = dsa_slave_port_vlans_add(dev, >u.vlan);
+ break;
default:
err = -ENOTSUPP;
break;
@@ -386,12 +408,34 @@ static int dsa_slave_port_obj_add(struct net_device *dev,
return err;
}
+static int dsa_slave_port_vlans_del(struct net_device *dev,
+ struct switchdev_obj_vlan *vlan)
+{
+ struct dsa_slave_priv *p = netdev_priv(dev);
+ struct dsa_switch *ds = p->parent;
+ int vid, err = 0;
+
+ if (!ds->drv->port_vlan_del)
+ return -ENOTSUPP;
+
+ for (vid = vlan->vid_start; vid <= vlan->vid_end; ++vid) {
+ err = ds->drv->port_vlan_del(ds, p->port, vid);
+ if (err)
+ break;
+ }
+
+ return err;
+}
+
static int dsa_slave_port_obj_del(struct net_device *dev,
struct switchdev_obj *obj)
{
int err;
switch (obj->id) {
+ case SWITCHDEV_OBJ_PORT_VLAN:
+ err = dsa_slave_port_vlans_del(dev, >u.vlan);
+ break;
default:
err = -EOPNOTSUPP;
break;
@@ -473,6 +517,15 @@ static netdev_tx_t dsa_slave_notag_xmit(struct sk_buff
*skb,
return NETDEV_TX_OK;
}
+static int dsa_slave_vlan_noop(struct net_device *dev, __be16 proto, u16 vid)
+{
+ /* NETIF_F_HW_VLAN_CTAG_FILTER requires ndo_vlan_rx_add_vid and
+* ndo_vlan_rx_kill_vid, otherwise the VLAN acceleration is considered
+* buggy (see net/core/dev.c).
+*/
+ return 0;
+}
+
/* ethtool operations ***/
static int
@@ -734,6 +787,10 @@ static const struct net_device_ops dsa_slave_netdev_ops = {
.ndo_fdb_dump = dsa_slave_fdb_dump,
.ndo_do_ioctl = dsa_slave_ioctl,
.ndo_get_iflink = dsa_slave_get_iflink,
+ .ndo_vlan_rx_add_vid= dsa_slave_vlan_noop,
+ .ndo_vlan_rx_kill_vid = dsa_slave_vlan_noop,
+ .ndo_bridge_setlink = switchdev_port_bridge_setlink,
+ .ndo_bridge_dellink = switchdev_port_bridge_dellink,
};
static const struct switchdev_ops dsa_slave_switchdev_ops = {
@@ -924,7 +981,7 @@ int dsa_slave_create(struct dsa_switch *ds, struct device
*parent,
if (slave_dev == NULL)
return -ENOMEM;
- slave_dev->features = master->vlan_features;
+ slave_dev->features = master->vlan_features | NETIF_F_VLAN_FEATURES;
slave_dev->ethtool_ops = _slave_ethtool_ops;
eth_hw_addr_inherit(slave_dev, master);
slave_dev->tx_queue_len = 0;
@@ -936,7 +993,7 @@ int dsa_slave_create(struct
[RFC 9/9] net: dsa: fix EDSA frame from hwaccel frame
If the underlying network device features NETIF_F_HW_VLAN_CTAG_TX, an EDSA frame is prepended with a 802.1q header once queued. To fix this, push the VLAN tag to the payload if present, before checking the frame protocol. [note: we may prefer to access directly VLAN TCI from hwaccel frames, but this approach is simpler.] Signed-off-by: Vivien Didelot --- net/dsa/tag_edsa.c | 5 + 1 file changed, 5 insertions(+) diff --git a/net/dsa/tag_edsa.c b/net/dsa/tag_edsa.c index 9aeda59..c1c9548 100644 --- a/net/dsa/tag_edsa.c +++ b/net/dsa/tag_edsa.c @@ -9,6 +9,7 @@ */ #include +#include #include #include #include "dsa_priv.h" @@ -24,6 +25,10 @@ static netdev_tx_t edsa_xmit(struct sk_buff *skb, struct net_device *dev) dev->stats.tx_packets++; dev->stats.tx_bytes += skb->len; + skb = vlan_hwaccel_push_inside(skb); + if (unlikely(!skb)) + return -ENOMEM; + /* * Convert the outermost 802.1q tag to a DSA tag and prepend * a DSA ethertype field is the packet is tagged, or insert -- 2.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 6/9] net: dsa: mv88e6352: allow egress of unknown multicast
This patch disables egress of unknown unicast destination addresses.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx.c | 3 ++-
drivers/net/dsa/mv88e6xxx.h | 5 +
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 49ef2f8..d2beb10 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -1686,7 +1686,8 @@ static int mv88e6xxx_setup_port(struct dsa_switch *ds,
int port)
mv88e6xxx_6185_family(ds))
reg = PORT_CONTROL_IGMP_MLD_SNOOP |
PORT_CONTROL_USE_TAG | PORT_CONTROL_USE_IP |
- PORT_CONTROL_STATE_FORWARDING;
+ PORT_CONTROL_STATE_FORWARDING |
+ PORT_CONTROL_EGRESS_FLOODS_NO_UNKNOWN_UNICAST_DA;
if (dsa_is_cpu_port(ds, port)) {
if (mv88e6xxx_6095_family(ds) || mv88e6xxx_6185_family(ds))
reg |= PORT_CONTROL_DSA_TAG;
diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
index f4ea66a..412d14e 100644
--- a/drivers/net/dsa/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx.h
@@ -117,6 +117,11 @@
#define PORT_CONTROL_STATE_BLOCKING0x01
#define PORT_CONTROL_STATE_LEARNING0x02
#define PORT_CONTROL_STATE_FORWARDING 0x03
+#define PORT_CONTROL_EGRESS_FLOODS_MASK(0x03
<< 2)
+#define PORT_CONTROL_EGRESS_FLOODS_NO_UNKNOWN_ANY_DA (0x00 << 2)
+#define PORT_CONTROL_EGRESS_FLOODS_NO_UNKNOWN_MULTICAST_DA (0x01 << 2)
+#define PORT_CONTROL_EGRESS_FLOODS_NO_UNKNOWN_UNICAST_DA (0x02 << 2)
+#define PORT_CONTROL_EGRESS_FLOODS_ANY_DA (0x03 << 2)
#define PORT_CONTROL_1 0x05
#define PORT_BASE_VLAN 0x06
#define PORT_DEFAULT_VLAN 0x07
--
2.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 0/9] net: dsa: mv88e6352: add 802.1q VLAN support
This patchset brings support for the 802.1q and VLAN operations to the Marvell 88E6352 switch and compatibles. The patch 1/9 adds more glue between switchdev and DSA. Patches 2/9 to 4/9 add the VLAN operations to DSA and the mv88e6xxx family of switches. Patches 5/9 to 9/9 is the necessary configuration that I figured out during the VLAN tests I did. So far, I was able to confirm the following scenarios: * Port untagged to Port untagged * Port untagged to Port tagged * Port tagged to Port tagged * Port untagged to CPU tagged * Port tagged to CPU tagged * CPU tagged to port tagged >From the userspace, here's a few commands I use to start using VLANs: # create bridge ip link set dev eth0 up ip link add name br0 type bridge echo 1 > /sys/class/net/br0/bridge/vlan_filtering ip link set dev br0 up # setup switch ports for i in $(seq 0 4); do ip link set dev swp$i up master br0 # HACK: bridge assumes the following but doesn't call ndo_bridge_setlink bridge vlan add vid 1 pvid untagged dev swp$i master self done Best, -v Vivien Didelot (9): net: dsa: add basic support for switchdev obj net: dsa: add basic support for VLAN operations net: dsa: mv88e6xxx: add support for VTU ops net: dsa: mv88e6352: add support for VLAN net: dsa: mv88e6352: disable mirroring net: dsa: mv88e6352: allow egress of unknown multicast net: dsa: mv88e6352: lock CPU port from learning addresses net: dsa: mv88e6352: set port 802.1Q mode to Secure net: dsa: fix EDSA frame from hwaccel frame drivers/net/dsa/mv88e6352.c | 12 +- drivers/net/dsa/mv88e6xxx.c | 303 ++-- drivers/net/dsa/mv88e6xxx.h | 39 ++ include/net/dsa.h | 7 + net/dsa/slave.c | 100 ++- net/dsa/tag_edsa.c | 5 + 6 files changed, 446 insertions(+), 20 deletions(-) -- 2.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] Bluetooth: btusb: Add reset_resume function
Some USB hubs may lose power across suspend/resume.
Add a reset_resume callback to properly reset those bluetoot devices.
Signed-off-by: Laura Abbott
---
Now the setup function is called again with the HCI_RESET_RESUME
flag set. The various functions could then use that RESET_RESUME
flag to determine if loading the firmware is appropriate or not.
---
drivers/bluetooth/btusb.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 3c10d4d..34884cf 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -3382,6 +3382,21 @@ done:
return err;
}
+
+static int btusb_reset_resume(struct usb_interface *intf)
+{
+ struct btusb_data *data = usb_get_intfdata(intf);
+ struct hci_dev *hdev = data->hdev;
+ int ret;
+
+ BT_DBG("intf %p", intf);
+
+ ret = btusb_resume(intf);
+ if (ret)
+ return ret;
+
+ return hci_reset_resume_dev(hdev);
+}
#endif
static struct usb_driver btusb_driver = {
@@ -3391,6 +3406,7 @@ static struct usb_driver btusb_driver = {
#ifdef CONFIG_PM
.suspend= btusb_suspend,
.resume = btusb_resume,
+ .reset_resume = btusb_reset_resume,
#endif
.id_table = btusb_table,
.supports_autosuspend = 1,
--
2.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] Bluetooth: Add reset_resume function
Bluetooth devices off of some buses such as USB may lose power across
suspend/resume. When this happens, drivers may need to have the setup
function called again and behave differently than a cold power on.
Add a reset_resume function for drivers to call. During the
reset_resume case, the flag HCI_RESET_RESUME will be set to allow
drivers to differentate.
Signed-off-by: Laura Abbott
---
This matches with what hci_reset_dev does and also ensures
the setup function gets called again.
---
include/net/bluetooth/hci.h | 1 +
include/net/bluetooth/hci_core.h | 1 +
net/bluetooth/hci_core.c | 16
3 files changed, 18 insertions(+)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index d95da83..6285410 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -185,6 +185,7 @@ enum {
HCI_RAW,
HCI_RESET,
+ HCI_RESET_RESUME,
};
/* HCI socket flags */
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index a056c2b..14f9c72 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -941,6 +941,7 @@ int hci_register_dev(struct hci_dev *hdev);
void hci_unregister_dev(struct hci_dev *hdev);
int hci_suspend_dev(struct hci_dev *hdev);
int hci_resume_dev(struct hci_dev *hdev);
+int hci_reset_resume_dev(struct hci_dev *hdev);
int hci_reset_dev(struct hci_dev *hdev);
int hci_dev_open(__u16 dev);
int hci_dev_close(__u16 dev);
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index c4802f3..090762b 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1558,6 +1558,7 @@ static int hci_dev_do_close(struct hci_dev *hdev)
BT_DBG("%s %p", hdev->name, hdev);
if (!hci_dev_test_flag(hdev, HCI_UNREGISTER) &&
+ !test_bit(HCI_RESET_RESUME, >flags) &&
test_bit(HCI_UP, >flags)) {
/* Execute vendor specific shutdown routine */
if (hdev->shutdown)
@@ -2110,6 +2111,7 @@ static void hci_power_on(struct work_struct *work)
*/
mgmt_index_added(hdev);
}
+ hci_dev_test_and_clear_flag(hdev, HCI_RESET_RESUME);
}
static void hci_power_off(struct work_struct *work)
@@ -3298,6 +3300,20 @@ int hci_reset_dev(struct hci_dev *hdev)
}
EXPORT_SYMBOL(hci_reset_dev);
+/*
+ * For USB reset_resume callbacks
+ */
+int hci_reset_resume_dev(struct hci_dev *hdev)
+{
+ set_bit(HCI_RESET_RESUME, >flags);
+ hci_dev_do_close(hdev);
+ hci_dev_set_flag(hdev, HCI_SETUP);
+
+ queue_work(hdev->req_workqueue, >power_on);
+ return 0;
+}
+EXPORT_SYMBOL(hci_reset_resume_dev);
+
/* Receive frame from HCI drivers */
int hci_recv_frame(struct hci_dev *hdev, struct sk_buff *skb)
{
--
2.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v5 00/30] perf tools: filtering events using eBPF programs
Em Mon, Jun 01, 2015 at 05:48:38PM -0700, Alexei Starovoitov escreveu: > On Mon, Jun 01, 2015 at 07:37:46AM +, Wang Nan wrote: > > This is the 5th version of patch series which tries to introduce eBPF > > programs to perf. It enables 'perf record' to filter events using eBPF > > thanks! As far as I could review this set addresses all of my earlier > comments. > > > Patch 4/30 - 22/30 introduce libbpf, which first parse eBPF object > >files then load maps and programs into kernel. > > the libbpf side looks good. > For the patches that I haven't explictly acked yet: > Acked-by: Alexei Starovoitov > > > Patch 23-30 - 30/30 are perf side modifications, introducing > >new syntax: '--event [.*].(o|bpf)' to enable passing eBPF object > >files to 'perf record', create probing points and attach programs > >to those points. > > Looks good to me as well. > Arnaldo, please take a deep look :) I'll try applying and testing it, from looking at the description of the changes it looks as well that my concerns have been addressed, Thanks! - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] x86 TSC: set X86_FEATURE_TSC_RELIABLE, per CPUID
On Mon, Jun 1, 2015 at 5:45 PM, Len Brown wrote: > On Mon, Jun 1, 2015 at 2:40 PM, Andy Lutomirski wrote: >> On 05/30/2015 10:44 PM, Len Brown wrote: >>> >>> From: Len Brown >>> >>> Speed cpu_up() by believing CPUID's "invariant TSC" flag, >>> and skipping the TSC warp test on single socket systems. >> >> >> I'm typing this email on a "Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz" with a >> "X79A-GD65 (8D) (MS-7760)" motherboard. (DO NOT BUY THAT MOTHERBOARD!) >> >> The brilliant stock firmware breaks TSC sync on bootup. Even with the >> updated firmware I'm using, it's broken on resume from S3. > > So the stock firmware broke the TSC on boot _and_ S3. > The updated firmware does not break the TSC on boot, but still breaks it on > S3? Exactly. > > For this board, please send the output from > $ dmesg | grep -i tsc [0.00] tsc: Fast TSC calibration using PIT [0.00] tsc: Detected 3199.952 MHz processor [0.192253] TSC deadline timer enabled [1.712495] tsc: Refined TSC clocksource calibration: 3199.960 MHz [2.712791] Switched to clocksource tsc ... suspend and resume ... [ 61.414518] TSC synchronization [CPU#0 -> CPU#1]: [ 61.414518] Measured 6137255520 cycles TSC warp between CPUs, turning off TS clock. [ 61.414522] tsc: Marking TSC unstable due to check_tsc_sync_source failed > > I would think we could detect this issue much faster than requesting > the full 2ms test. > >> If you want to make this depend on X86_FEATURE_TSC_ADJUST and confirm that >> all cores have the same IA32_TSC_ADJUST value, then maybe that would be >> okay. > > That suggestion sounds reasonable. > > BTW, it also begs the question if Linux could actually *repair* the BIOS > damage? Quite possibly. Is there such thing as a single-socket CPU that claims invariant CPU on which setting TSC_ADJUST to zero on all cores won't result in a synchronized TSC? (This is moot for my CPU. I don't have TSC_ADJUST.) On a somewhat related note, why are we still calibrating the TSC frequency based on the PIT? intel_pstate appears to know how to read it off directly. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Build break in drivers/net/ethernet/mellanox/mlx4/eq.c:1240 (was Re: linux-next: Tree for Jun 1)
On Mon, 2015-06-01 at 23:10 +1000, Stephen Rothwell wrote: > Hi all, > > Changes since 20150529: Commit c66fa19c "net/mlx4: Add EQ pool" breaks the SMP=n build for powerpc: drivers/net/ethernet/mellanox/mlx4/eq.c:1240:11: error: 'eq' undeclared (first use in this function) make[6]: *** [drivers/net/ethernet/mellanox/mlx4/eq.o] Error 1 http://kisskb.ellerman.id.au/kisskb/buildresult/12435167/ This will also break for any config with CONFIG_RFS_ACCEL=n. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] net: core: 'ethtool' issue with querying phy settings
On Mon, 2015-06-01 at 16:53 -0700, Arun Parameswaran wrote: > On 15-06-01 02:46 PM, David Miller wrote: > > From: Arun Parameswaran > > Date: Mon, 1 Jun 2015 14:41:43 -0700 > > > >> It would be nice for the 'ethtool' to be flexible to support querying > >> specific PHY irrespective of the net implementation, but that is being > >> discussed in the other thread. > > > > Please stop arguing about this, it isn't valid. > > > > Your device is a switch, and therefore needs to be represented properly > > with the proper number of net_device objects. > > > > Even more importantly, the ethtool API is established and you cannot > > change these semantics without potentially breaking lots of applications > > and libraries out there. > > > > Your change is reverted, and I will absolutely not entertain any > > attempt to again change the semantics of this ethtool operation. > > > > Thanks. > > > I apologize if the patch broke any conventions, it was not my intend. I > understand the implications on other programs that use the interface. > > Just so that I don’t make this mistake in the future and to understand this > better, does this mean that the 'phyad' parameter specified in the > 'ethtool' command line is ignored ? There are some very old Ethernet cards where the driver can't automatically detect which PHY address to use, or where the MAC can be attached to one of several different PHYs. This is what the 'phyad' parameter is used for. I think the only remaining driver that supports changing the PHY address like this is natsemi. Ben. -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates signature.asc Description: This is a digitally signed message part
Re: [RFC PATCH v5 00/30] perf tools: filtering events using eBPF programs
On Mon, Jun 01, 2015 at 07:37:46AM +, Wang Nan wrote: > This is the 5th version of patch series which tries to introduce eBPF > programs to perf. It enables 'perf record' to filter events using eBPF thanks! As far as I could review this set addresses all of my earlier comments. > Patch 4/30 - 22/30 introduce libbpf, which first parse eBPF object >files then load maps and programs into kernel. the libbpf side looks good. For the patches that I haven't explictly acked yet: Acked-by: Alexei Starovoitov > Patch 23-30 - 30/30 are perf side modifications, introducing >new syntax: '--event [.*].(o|bpf)' to enable passing eBPF object >files to 'perf record', create probing points and attach programs >to those points. Looks good to me as well. Arnaldo, please take a deep look :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] staging: rtl8192u: ieee80211: Fix sparse endianness warnings
Fix the following sparse warnings: drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:663:32: warning: incorrect type in assignment (different base types) drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:663:32:expected restricted __le16 [usertype] frame_ctl drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:663:32:got int drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:664:50: warning: invalid assignment: |= drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:664:50:left side has type restricted __le16 drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c:664:50:right side has type int Signed-off-by: Gaston Gonzalez --- Changes since V1: rearrange the code to set auth->header.frame_ctl only once. drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c index d2e8b12..d0a6a59 100644 --- a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c @@ -660,8 +660,10 @@ inline struct sk_buff *ieee80211_authentication_req(struct ieee80211_network *be auth = (struct ieee80211_authentication *) skb_put(skb, sizeof(struct ieee80211_authentication)); - auth->header.frame_ctl = IEEE80211_STYPE_AUTH; - if (challengelen) auth->header.frame_ctl |= IEEE80211_FCTL_WEP; + if (challengelen) + auth->header.frame_ctl = cpu_to_le16(IEEE80211_STYPE_AUTH | IEEE80211_FCTL_WEP); + else + auth->header.frame_ctl = cpu_to_le16(IEEE80211_STYPE_AUTH); auth->header.duration_id = 0x013a; //FIXME -- 2.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] x86 TSC: set X86_FEATURE_TSC_RELIABLE, per CPUID
On Mon, Jun 1, 2015 at 2:40 PM, Andy Lutomirski wrote: > On 05/30/2015 10:44 PM, Len Brown wrote: >> >> From: Len Brown >> >> Speed cpu_up() by believing CPUID's "invariant TSC" flag, >> and skipping the TSC warp test on single socket systems. > > > I'm typing this email on a "Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz" with a > "X79A-GD65 (8D) (MS-7760)" motherboard. (DO NOT BUY THAT MOTHERBOARD!) > > The brilliant stock firmware breaks TSC sync on bootup. Even with the > updated firmware I'm using, it's broken on resume from S3. So the stock firmware broke the TSC on boot _and_ S3. The updated firmware does not break the TSC on boot, but still breaks it on S3? For this board, please send the output from $ dmesg | grep -i tsc I would think we could detect this issue much faster than requesting the full 2ms test. > If you want to make this depend on X86_FEATURE_TSC_ADJUST and confirm that > all cores have the same IA32_TSC_ADJUST value, then maybe that would be > okay. That suggestion sounds reasonable. BTW, it also begs the question if Linux could actually *repair* the BIOS damage? thanks, Len Brown, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the mips tree with the arm and h8300 trees
Hi Ralf,
Today's linux-next merge of the mips tree got a conflict in
drivers/irqchip/Makefile between commits 22b67acd99c0 ("ARM: 8368/1:
sa1100: move irq driver to drivers/irqchip/") from the arm tree and
eba5540f0103 ("h8300: IRQ chip driver") from the h8300 tree and commit
a7c64f0e29a6 ("MIPS/IRQCHIP: Move Ingenic SoC intc driver to
drivers/irqchip") from the mips tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/irqchip/Makefile
index ed9553322638,db014e8e12c9..
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@@ -47,6 -48,4 +48,7 @@@ obj-$(CONFIG_KEYSTONE_IRQ)+= irq-keys
obj-$(CONFIG_MIPS_GIC)+= irq-mips-gic.o
obj-$(CONFIG_ARCH_MEDIATEK) += irq-mtk-sysirq.o
obj-$(CONFIG_ARCH_DIGICOLOR) += irq-digicolor.o
+obj-$(CONFIG_ARCH_SA1100) += irq-sa11x0.o
+obj-$(CONFIG_RENESAS_H8300H_INTC) += irq-renesas-h8300h.o
+obj-$(CONFIG_RENESAS_H8S_INTC)+= irq-renesas-h8s.o
+ obj-$(CONFIG_INGENIC_IRQ) += irq-ingenic.o
pgpI19tC91KX7.pgp
Description: OpenPGP digital signature
[PATCH v5 03/21] libnvdimm: control character device and libnvdimm bus sysfs attributes
The control device for a libnvdimm bus is registered as an "nd" class
device. The expectation is that there will usually only be one "nd" bus
registered under /sys/class/nd. However, we allow for the possibility
of multiple buses and they will listed in discovery order as
ndctl0...ndctlN. This character device hosts the ioctl for passing
control messages. The initial command set has a 1:1 correlation with
the commands listed in the by the "NFIT DSM Example" document [1], but
this scheme is extensible to future command sets.
Note, nd_ioctl() and the backing ->ndctl() implementation are defined in
a subsequent patch. This is simply the initial registrations and sysfs
attributes.
[1]: http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
Cc: Neil Brown
Cc: Greg KH
Cc:
Cc: Robert Moore
Cc: Rafael J. Wysocki
Signed-off-by: Dan Williams
---
drivers/acpi/nfit.c | 28 ++
drivers/acpi/nfit.h |5 ++
drivers/nvdimm/Makefile |1
drivers/nvdimm/bus.c| 83 +
drivers/nvdimm/core.c | 87 ++-
drivers/nvdimm/nd-private.h |6 +++
include/linux/libnvdimm.h |6 ++-
7 files changed, 213 insertions(+), 3 deletions(-)
create mode 100644 drivers/nvdimm/bus.c
diff --git a/drivers/acpi/nfit.c b/drivers/acpi/nfit.c
index 314cf9d2522b..ec228ab336b3 100644
--- a/drivers/acpi/nfit.c
+++ b/drivers/acpi/nfit.c
@@ -316,6 +316,33 @@ static int nfit_mem_init(struct acpi_nfit_desc *acpi_desc)
return 0;
}
+static ssize_t revision_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct nvdimm_bus *nvdimm_bus = to_nvdimm_bus(dev);
+ struct nvdimm_bus_descriptor *nd_desc = to_nd_desc(nvdimm_bus);
+ struct acpi_nfit_desc *acpi_desc = to_acpi_desc(nd_desc);
+
+ return sprintf(buf, "%d\n", acpi_desc->nfit->header.revision);
+}
+static DEVICE_ATTR_RO(revision);
+
+static struct attribute *acpi_nfit_attributes[] = {
+ _attr_revision.attr,
+ NULL,
+};
+
+static struct attribute_group acpi_nfit_attribute_group = {
+ .name = "nfit",
+ .attrs = acpi_nfit_attributes,
+};
+
+static const struct attribute_group *acpi_nfit_attribute_groups[] = {
+ _bus_attribute_group,
+ _nfit_attribute_group,
+ NULL,
+};
+
static int acpi_nfit_init(struct acpi_nfit_desc *acpi_desc, acpi_size sz)
{
struct device *dev = acpi_desc->dev;
@@ -372,6 +399,7 @@ static int acpi_nfit_add(struct acpi_device *adev)
nd_desc = _desc->nd_desc;
nd_desc->provider_name = "ACPI.NFIT";
nd_desc->ndctl = acpi_nfit_ctl;
+ nd_desc->attr_groups = acpi_nfit_attribute_groups;
acpi_desc->nvdimm_bus = nvdimm_bus_register(dev, nd_desc);
if (!acpi_desc->nvdimm_bus)
diff --git a/drivers/acpi/nfit.h b/drivers/acpi/nfit.h
index 2d98cc1b7b6c..735e463edbf7 100644
--- a/drivers/acpi/nfit.h
+++ b/drivers/acpi/nfit.h
@@ -86,4 +86,9 @@ static inline struct acpi_nfit_memory_map
*__to_nfit_memdev(struct nfit_mem *nfi
return nfit_mem->memdev_dcr;
return nfit_mem->memdev_pmem;
}
+
+static inline struct acpi_nfit_desc *to_acpi_desc(struct nvdimm_bus_descriptor
*nd_desc)
+{
+ return container_of(nd_desc, struct acpi_nfit_desc, nd_desc);
+}
#endif /* __NFIT_H__ */
diff --git a/drivers/nvdimm/Makefile b/drivers/nvdimm/Makefile
index 10bc7af47992..8a8293c72c7c 100644
--- a/drivers/nvdimm/Makefile
+++ b/drivers/nvdimm/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_LIBNVDIMM) += libnvdimm.o
libnvdimm-y := core.o
+libnvdimm-y += bus.o
diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c
new file mode 100644
index ..312caef5b0e9
--- /dev/null
+++ b/drivers/nvdimm/bus.c
@@ -0,0 +1,83 @@
+/*
+ * Copyright(c) 2013-2015 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ */
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include
+#include
+#include
+#include
+#include
+#include "nd-private.h"
+
+static int nvdimm_bus_major;
+static struct class *nd_class;
+
+int nvdimm_bus_create_ndctl(struct nvdimm_bus *nvdimm_bus)
+{
+ dev_t devt = MKDEV(nvdimm_bus_major, nvdimm_bus->id);
+ struct device *dev;
+
+ dev = device_create(nd_class, _bus->dev, devt, nvdimm_bus,
"ndctl%d",
+ nvdimm_bus->id);
+
+ if (IS_ERR(dev)) {
+ dev_dbg(_bus->dev, "failed to register ndctl%d: %ld\n",
+ nvdimm_bus->id, PTR_ERR(dev));
+ return
