[PATCH 1/1] x86, kgdb: correct kgdb_arch_remove_breakpoint
From: He Zhe
On 3.19-rc2, kgdbts boot time test fails with default parameter V1F100
"KGDB: BP remove failed: 81049070"
Then system is hanged.
When CONFIG_DEBUG_RODATA is on, kgdb_arch_set_breakpoint firstly tries
probe_kernel_write to set breakpoints and mark their type as BP_BREAKPOINT. If
fails it would use text_poke and mark their type as BP_POKE_BREAKPOINT.
On the other hand, kgdb_arch_remove_breakpoint uses probe_kernel_write to delete
breakpoints if they are BP_BREAKPOINT, or uses text_poke if they are
BP_POKE_BREAKPOINT.
The kgdbts' boot time test case loops for do_fork and/or sys_open may run
through initialization. During this procedure, the read only area is created. If
a breakpoint is marked as BP_BREAKPOINT before creating read only area and then
its address is put into that area, it would fail to be deleted due to
kgdb_arch_remove_breakpoint would use wrong function.
This patch:
- Make kgdb_arch_remove_breakpoint work like kgdb_arch_set_breakpoint, trying
probe_kernel_write first then trying text_poke if fails.
- Remove BP_POKE_BREAKPOINT as it is only used in these two functions.
Signed-off-by: He Zhe
---
arch/x86/kernel/kgdb.c | 25 +
include/linux/kgdb.h | 1 -
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kernel/kgdb.c b/arch/x86/kernel/kgdb.c
index 7ec1d5f..f5f7772 100644
--- a/arch/x86/kernel/kgdb.c
+++ b/arch/x86/kernel/kgdb.c
@@ -749,7 +749,6 @@ int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
char opc[BREAK_INSTR_SIZE];
#endif /* CONFIG_DEBUG_RODATA */
- bpt->type = BP_BREAKPOINT;
err = probe_kernel_read(bpt->saved_instr, (char *)bpt->bpt_addr,
BREAK_INSTR_SIZE);
if (err)
@@ -772,34 +771,36 @@ int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
return err;
if (memcmp(opc, arch_kgdb_ops.gdb_bpt_instr, BREAK_INSTR_SIZE))
return -EINVAL;
- bpt->type = BP_POKE_BREAKPOINT;
#endif /* CONFIG_DEBUG_RODATA */
return err;
}
int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
{
-#ifdef CONFIG_DEBUG_RODATA
int err;
+#ifdef CONFIG_DEBUG_RODATA
char opc[BREAK_INSTR_SIZE];
+#endif /* CONFIG_DEBUG_RODATA */
- if (bpt->type != BP_POKE_BREAKPOINT)
- goto knl_write;
+ err = probe_kernel_write((char *)bpt->bpt_addr,
+(char *)bpt->saved_instr, BREAK_INSTR_SIZE);
+#ifdef CONFIG_DEBUG_RODATA
+ if (!err)
+ return err;
/*
* It is safe to call text_poke() because normal kernel execution
* is stopped on all cores, so long as the text_mutex is not locked.
*/
if (mutex_is_locked(_mutex))
- goto knl_write;
+ return -EBUSY;
text_poke((void *)bpt->bpt_addr, bpt->saved_instr, BREAK_INSTR_SIZE);
err = probe_kernel_read(opc, (char *)bpt->bpt_addr, BREAK_INSTR_SIZE);
- if (err || memcmp(opc, bpt->saved_instr, BREAK_INSTR_SIZE))
- goto knl_write;
- return err;
-knl_write:
+ if (err)
+ return err;
+ if (memcmp(opc, bpt->saved_instr, BREAK_INSTR_SIZE))
+ return -EINVAL;
#endif /* CONFIG_DEBUG_RODATA */
- return probe_kernel_write((char *)bpt->bpt_addr,
- (char *)bpt->saved_instr, BREAK_INSTR_SIZE);
+ return err;
}
struct kgdb_arch arch_kgdb_ops = {
diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h
index fc513db..cded3c75 100644
--- a/include/linux/kgdb.h
+++ b/include/linux/kgdb.h
@@ -63,7 +63,6 @@ enum kgdb_bptype {
BP_WRITE_WATCHPOINT,
BP_READ_WATCHPOINT,
BP_ACCESS_WATCHPOINT,
- BP_POKE_BREAKPOINT,
};
enum kgdb_bpstate {
--
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
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] spi/spidev: Convert to use unified device property API
On Mon, Dec 29, 2014 at 04:03:16PM +, Mark Brown wrote: > On Mon, Dec 29, 2014 at 11:41:14AM +0200, Mika Westerberg wrote: > > This will allow the driver to match using DT compatible property if the > > device has ACPI _HID of "PRP0001" and accompanying "compatible" property > > listed in _DSD. > > Which nobody should be doing since it's already totally broken for > something to be using this on the DT side except in the one case of the > Rohm device which is listed there. I don't want to merge anything which > allows the breakage we're seeing with people putting spidev in their DTs > to be propagated into ACPI, at most we should have something that > specifically identifies individual devices only. It is pretty convenient for testing SPI bus and that's why I thought it would be good to have possibility to enumerate this in similar way than DT does but I understand your point. -- 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/3] i8k: Remove laptop specific config data (fan_mult, fan_max) from driver
On Mon, Dec 29, 2014 at 01:50:22PM +0100, Gabriele Mazzotta wrote: > On Monday 29 December 2014 13:22:52 Pali Rohár wrote: > > On Sunday 28 December 2014 17:17:14 Gabriele Mazzotta wrote: > > > OK, I wanted to double check in case I had something missing. > > > > > > Patches tested on my XPS13: the correct values for fan_mult > > > and fan_man are automatically selected. > > > > Great. Are there any other problems? Now probe time when loading > > module should be lower and could not freeze system, right? > > Yes, the system doesn't hang on module load. The only problem I have > right night now is that the system temporarily hangs when I read or set > the speed of the fan. This is a known problem on some Dell laptops; one of mine has the same problem. Nothing we can do about that, unfortunately. Only thing you can do is to not read the fan speed. Guenter -- 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/4] kstrdup optimization
On 12/30/2014 07:45 AM, Andi Kleen wrote: > Andrzej Hajda writes: > >> kstrdup if often used to duplicate strings where neither source neither >> destination will be ever modified. In such case we can just reuse the source >> instead of duplicating it. The problem is that we must be sure that >> the source is non-modifiable and its life-time is long enough. > What happens if someone is to kfree() these strings? > > -Andi > kstrdup_const must be accompanied by kfree_const, I did not mention it in cover letter but it is described in the 1st patch commit message. Simpler alternative (but I am not sure if better) would be to add similar check (ie. if pointer is in .rodata) to kfree itself. Regards Andrzej -- 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/4] kstrdup optimization
Andrzej Hajda writes: > kstrdup if often used to duplicate strings where neither source neither > destination will be ever modified. In such case we can just reuse the source > instead of duplicating it. The problem is that we must be sure that > the source is non-modifiable and its life-time is long enough. What happens if someone is to kfree() these strings? -Andi -- a...@linux.intel.com -- Speaking for myself only -- 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: comedi: dmm32at: fix style issues
On Mon, Dec 29, 2014 at 03:12:53PM -0800, David Decotigny wrote: > thanks! I have a preference for the v2 I sent: my $EDITOR handles the > indentation for me; using 2 tabs forces me to manually override my editor's > behavior. But if there is a strong push for a v3 of this patch with 2 tabs > instead of current v2 indentation, I'll do it, please let me know. well, if you check CodingStyle in Documentation, it clearly says: "Outside of comments, documentation and except in Kconfig, spaces are never used for indentation". Sudip > > On Fri, Dec 26, 2014 at 11:00 PM, Sudip Mukherjee < > sudipm.mukher...@gmail.com> wrote: > > > On Thu, Dec 25, 2014 at 12:28:28PM -0800, David Decotigny wrote: > > > Before: > > > 1 ERROR: code indent should use tabs where possible > > > 1 WARNING: please, no spaces at the start of a line > > > > > > After: > > > (none) > > > > > > Signed-off-by: David Decotigny > > > --- > > > drivers/staging/comedi/drivers/dmm32at.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/staging/comedi/drivers/dmm32at.c > > b/drivers/staging/comedi/drivers/dmm32at.c > > > index 6df298a..31919b8 100644 > > > --- a/drivers/staging/comedi/drivers/dmm32at.c > > > +++ b/drivers/staging/comedi/drivers/dmm32at.c > > > @@ -365,7 +365,7 @@ static void dmm32at_setaitimer(struct comedi_device > > *dev, unsigned int nansec) > > > /* enable the ai conversion interrupt and the clock to start scans > > */ > > > outb(DMM32AT_INTCLK_ADINT | > > >DMM32AT_INTCLK_CLKEN | DMM32AT_INTCLK_CLKSEL, > > > - dev->iobase + DMM32AT_INTCLK_REG); > > > + dev->iobase + DMM32AT_INTCLK_REG); > > > > another suggestion: > > if you do like the following patch (use 2 tabs) then you do not need to > > give spaces to indent the code. > > > > diff --git a/drivers/staging/comedi/drivers/dmm32at.c > > b/drivers/staging/comedi/drivers/dmm32at.c > > index 6df298a..cedf8ed 100644 > > --- a/drivers/staging/comedi/drivers/dmm32at.c > > +++ b/drivers/staging/comedi/drivers/dmm32at.c > > @@ -364,8 +364,8 @@ static void dmm32at_setaitimer(struct comedi_device > > *dev, unsigned int nansec) > > > > /* enable the ai conversion interrupt and the clock to start scans > > */ > > outb(DMM32AT_INTCLK_ADINT | > > -DMM32AT_INTCLK_CLKEN | DMM32AT_INTCLK_CLKSEL, > > - dev->iobase + DMM32AT_INTCLK_REG); > > + DMM32AT_INTCLK_CLKEN | DMM32AT_INTCLK_CLKSEL, > > + dev->iobase + DMM32AT_INTCLK_REG); > > } > > > > static int dmm32at_ai_cmd(struct comedi_device *dev, struct > > comedi_subdevice *s) > > > > > > thanks > > sudip > > > > > } > > > > > > static int dmm32at_ai_cmd(struct comedi_device *dev, struct > > comedi_subdevice *s) > > > -- > > > 2.2.0.rc0.207.ga3a616c > > > > > > -- > > > 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: [PATCH 3/3] net: ieee802154: don't use devm_pinctrl_get_select_default() in probe
Hi Wolfram, > Since commit ab78029ecc34 (drivers/pinctrl: grab default handles from device > core), we can rely on device core for setting the default pins. > > Signed-off-by: Wolfram Sang > --- > drivers/net/ieee802154/cc2520.c | 7 --- > 1 file changed, 7 deletions(-) patch has been applied to bluetooth-next tree. 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: [resend][PATCH v9 1/3] procfs: show hierarchy of pid namespace
Chen Hanxiao writes:
> We lack of pid hierarchy information, and this will lead to:
> a) we don't know pids' relationship, who is whose child:
>/proc/PID/ns/pid only tell us whether two pids live in different ns
> b) bring trouble to nested lxc container checkpoint/restore/migration
> c) bring trouble to pid translation between containers;
>
> This patch will show the hierarchy of pid namespace
> by pidns_hierarchy like:
>
>
I am still trying to figure out if this is a good idea.
The problem is real, though I am not certain how severe? Is there code
interesting code this would allow you to write?
It would be nice if we could use the same solution for both user
namespace and pid namespace hierarchy description. This solution
doesn't have a chance of doing that.
The patch itself though is currently incorrect. What is read from a
file should be determined at open time, and better still be constant
whoever reads the file.
Your pidns_hierarchy file morphs depending on who is reading it and that
is at a minimum confusing, and will cause problems if someone decides to
pass the file descriptor.
There is also an issue that this hierarchy does not seem to be able to
deal with pid namespaces that currently have no pids in them. If the
goal is to use this for checkpoint/restart that may be a make certain
pid namespace states uncheckpointable. So that seems like a significant
oversight.
Eric
> Ex:
> [root@localhost ~]#cat /proc/pidns_hierarchy
> 18060 1 1
> 18102 18060 2
> 1534 18102 3
> 1600 18102 3
> 1550 1 1
> *Note: numbers represent the pid 1 in different ns
>
> It shows the pid hierarchy below:
>
> init_pid_ns 1
> │
> ┌┐
> ns1 ns2
> ││
> 155018060
> │
> │
> ns3
> │
> 18102
> │
> ┌──┐
> ns4 ns5
> ││
> 1534 1600
>
> Every pid printed in pidns_hierarchy
> is the init pid of that pid ns level.
>
> Acked-by: Richard Weinberer
>
> Signed-off-by: Chen Hanxiao
> ---
> v9: fix codes be included if CONFIG_PID_NS=n
> v8: use max() from kernel.h
> fix some improper comments
> v7: change stype to be consistent with current interface like
>
> remove EXPERT dependent in Kconfig
> v6: fix a get_pid leak and do some cleanups;
> v5: collect pid by find_ge_pid;
> use local list inside nslist_proc_show;
> use get_pid, remove mutex lock.
> v4: simplify pid collection and some performance optimizamtion
> fix another race issue.
> v3: fix a race issue and memory leak issue
> v2: use a procfs text file instead of dirs under /proc
>
> fs/proc/Kconfig | 6 +
> fs/proc/Makefile | 1 +
> fs/proc/internal.h| 9 ++
> fs/proc/pidns_hierarchy.c | 280
> ++
> fs/proc/root.c| 1 +
> 5 files changed, 297 insertions(+)
> create mode 100644 fs/proc/pidns_hierarchy.c
>
> diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
> index 2183fcf..82dda55 100644
> --- a/fs/proc/Kconfig
> +++ b/fs/proc/Kconfig
> @@ -71,3 +71,9 @@ config PROC_PAGE_MONITOR
> /proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
> /proc/kpagecount, and /proc/kpageflags. Disabling these
>interfaces will reduce the size of the kernel by approximately 4kb.
> +
> +config PROC_PID_HIERARCHY
> + bool "Enable /proc/pidns_hierarchy support"
> + depends on PROC_FS
> + help
> + Show pid namespace hierarchy information
> diff --git a/fs/proc/Makefile b/fs/proc/Makefile
> index 7151ea4..33e384b 100644
> --- a/fs/proc/Makefile
> +++ b/fs/proc/Makefile
> @@ -30,3 +30,4 @@ proc-$(CONFIG_PROC_KCORE) += kcore.o
> proc-$(CONFIG_PROC_VMCORE) += vmcore.o
> proc-$(CONFIG_PRINTK)+= kmsg.o
> proc-$(CONFIG_PROC_PAGE_MONITOR) += page.o
> +proc-$(CONFIG_PROC_PID_HIERARCHY)+= pidns_hierarchy.o
> diff --git a/fs/proc/internal.h b/fs/proc/internal.h
> index 6fcdba5..18e0773 100644
> --- a/fs/proc/internal.h
> +++ b/fs/proc/internal.h
> @@ -280,6 +280,15 @@ struct proc_maps_private {
> #endif
> };
>
> +/*
> + * pidns_hierarchy.c
> + */
> +#ifdef CONFIG_PROC_PID_HIERARCHY
> + extern void proc_pidns_hierarchy_init(void);
> +#else
> + static inline void proc_pidns_hierarchy_init(void) {}
> +#endif
> +
> struct mm_struct *proc_mem_open(struct inode *inode, unsigned int mode);
>
> extern const struct file_operations proc_pid_maps_operations;
> diff --git a/fs/proc/pidns_hierarchy.c b/fs/proc/pidns_hierarchy.c
> new file mode 100644
> index 000..ab1c665
> --- /dev/null
> +++ b/fs/proc/pidns_hierarchy.c
> @@ -0,0 +1,280 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
>
Re: [PATCH 05/37] perf tools: Create separate mmap for dummy tracking event
On Mon, Dec 29, 2014 at 03:44:21PM +0200, Adrian Hunter wrote:
> > @@ -843,9 +889,22 @@ static int perf_evlist__mmap_per_evsel(struct
> > perf_evlist *evlist, int idx,
> >
> > fd = FD(evsel, cpu, thread);
> >
> > - if (*output == -1) {
> > + if (perf_evsel__is_dummy_tracking(evsel)) {
> > + struct mmap_params track_mp = {
> > + .prot = mp->prot,
> > + .len= TRACK_MMAP_SIZE,
> > + };
> > +
> > + if (__perf_evlist__mmap(evlist,
> > >track_mmap[idx],
> > + _mp, fd) < 0)
> > + return -1;
> > +
> > + /* mark idx as track mmap idx (negative) */
> > + idx = track_mmap_idx(idx);
>
> Do you not still need to do SET_OUTPUT when there are multiple cpus and
> multiple pids?
You're right. I just considered simple cases, will fix.
Thanks,
Namhyung
>
>
> > + } else if (*output == -1) {
> > *output = fd;
> > - if (__perf_evlist__mmap(evlist, idx, mp, *output) < 0)
> > + if (__perf_evlist__mmap(evlist, >mmap[idx],
> > + mp, *output) < 0)
> > return -1;
> > } else {
> > if (ioctl(fd, PERF_EVENT_IOC_SET_OUTPUT, *output) != 0)
> > @@ -874,6 +933,11 @@ static int perf_evlist__mmap_per_evsel(struct
> > perf_evlist *evlist, int idx,
> > perf_evlist__set_sid_idx(evlist, evsel, idx, cpu,
> > thread);
> > }
> > +
> > + if (mp->track && perf_evsel__is_dummy_tracking(evsel)) {
> > + /* restore idx as normal idx (positive) */
> > + idx = track_mmap_idx(idx);
> > + }
> > }
> >
> > return 0;
--
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 02/37] perf record: Use a software dummy event to track task/mmap events
Hi Adrian,
On Mon, Dec 29, 2014 at 02:58:12PM +0200, Adrian Hunter wrote:
> On 27/12/14 07:28, Namhyung Kim wrote:
> > Hi David,
> >
> > On Sat, Dec 27, 2014 at 1:27 AM, David Ahern wrote:
> >> On 12/24/14 12:14 AM, Namhyung Kim wrote:
> >>>
> >>> Prepend a software dummy event into evlist to track task/comm/mmap
> >>> events separately. This is a preparation of multi-file/thread support
> >>> which will come later.
> >>
> >>
> >> Are you are making this the first event because of how perf internals are
> >> coded -- that the first event tracks tasks events? With the tracking bit in
> >> evsel you should not need to do that. Is there another reason?
> >
> > Yeah, I know the tracking bit can be set to any evsel in the evlist.
> > But I'd like to keep it at a fixed index so that it can be easily
> > identified at later stages (like perf report) too. Ideally, it'd be
> > great if we have a way to distinguish this auto-added dummy tracking
> > event from other (user-added) (dummy?) tracking events if any.
> >
> >>
> >> ---8<---
> >>
> >>> diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
> >>> index cfbe2b99b9aa..72dff295237e 100644
> >>> --- a/tools/perf/util/evlist.c
> >>> +++ b/tools/perf/util/evlist.c
> >>> @@ -193,6 +193,44 @@ int perf_evlist__add_default(struct perf_evlist
> >>> *evlist)
> >>> return -ENOMEM;
> >>> }
> >>>
> >>> +int perf_evlist__prepend_dummy(struct perf_evlist *evlist)
> >>> +{
> >>> + struct perf_event_attr attr = {
> >>> + .type = PERF_TYPE_SOFTWARE,
> >>> + .config = PERF_COUNT_SW_DUMMY,
>
> Probably need .exclude_kernel = 1, here
Ah, right.
>
> >>> + };
> >>> + struct perf_evsel *evsel, *pos;
> >>> +
> >>> + event_attr_init();
> >>> +
> >>> + evsel = perf_evsel__new();
> >>> + if (evsel == NULL)
> >>> + goto error;
> >>> +
> >>> + /* use strdup() because free(evsel) assumes name is allocated */
> >>> + evsel->name = strdup("dummy");
> >>> + if (!evsel->name)
> >>> + goto error_free;
> >>> +
> >>> + list_for_each_entry(pos, >entries, node) {
> >>> + pos->idx += 1;
> >>> + pos->tracking = false;
> >>> + }
> >>> +
> >>> + list_add(>node, >entries);
> >>> + evsel->idx = 0;
> >>> + evsel->tracking = true;
> >>
> >>
> >> perf_evlist__set_tracking_event()?
> >
> > I found that after I wrote this, so yes, it can use the function
> > instead of the oped-code. But the loop traversal is needed anyway to
> > fixup the evsel->idx.
>
> perf_evlist__set_tracking_event() also ensures there is only one tracking
> event so it is easy to identify. It is the only event with attr->mmap etc
> set to 1. Then you can use perf_evlist__add().
Well, yes, I think we can put the dummy tracking event anywhere in the
evlist with this, but I still slightly prefer put it at a fixed
location for a possible code simplification..
Thanks,
Namhyung
--
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] powerpc/powernv: Select CONFIG_PRINTK to fix build failure
On Mon, Dec 29, 2014 at 4:01 AM, Michael Ellerman wrote: > On Sat, 2014-12-27 at 12:17 -0500, Pranith Kumar wrote: >> In an allnoconfig we get the following build failure: > > An allnoconfig doesn't include CONFIG_PPC_POWERNV? But I think I know what you > mean. > >> arch/powerpc/platforms/built-in.o: In function >> `.__machine_initcall_powernv_opal_init': >> opal.c:(.init.text+0x468): undefined reference to `.log_buf_addr_get' >> opal.c:(.init.text+0x474): undefined reference to `.log_buf_len_get' >> make: *** [vmlinux] Error 1 >> >> This happens because powernv requires printk() support. Enable it in the >> config >> file. > > Sort of. It just requires those two routines. Or is there a stronger > dependency? > > I think the better fix is for those two routines to be defined for > CONFIG_PRINTK=n, but return NULL and zero respectively. > > And the opal code could skip registering the region when they return > NULL/zero. > > Care to do a couple of patches? > Sure, I will give it a try. Thanks for the review! -- Pranith -- 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] assoc_array: Include rcupdate.h for call_rcu() definition
Include rcupdate.h header to provide call_rcu() definition. This was implicitly being provided by slab.h file which include srcu.h somewhere in its include hierarchy which in-turn included rcupdate.h. Lately, tinification effort added support to remove srcu entirely because of which we are encountering build errors like lib/assoc_array.c: In function 'assoc_array_apply_edit': lib/assoc_array.c:1426:2: error: implicit declaration of function 'call_rcu' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors Fix these by including rcupdate.h explicitly. Signed-off-by: Pranith Kumar Reported-by: Scott Wood --- lib/assoc_array.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/assoc_array.c b/lib/assoc_array.c index 2404d03..03dd576 100644 --- a/lib/assoc_array.c +++ b/lib/assoc_array.c @@ -11,6 +11,7 @@ * 2 of the Licence, or (at your option) any later version. */ //#define DEBUG +#include #include #include #include -- 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 v2] srcu: Isolate srcu sections using CONFIG_SRCU
Isolate the SRCU functions and data structures within CONFIG_SRCU so that there
is a compile time failure if srcu is used when not enabled. This was decided to
be better than waiting until link time for a failure to occur.
There are places which include kvm headers and utilize kvm data structures
without checking if KVM is enabled. In two such archs(s390, ppc64), the current
patch makes the uses of KVM conditional on KVM being enabled. The other option,
which is to enable KVM unconditionally seemed a bit too much as we could easily
figure out KVM only parts and enclose them in ifdefs.
Signed-off-by: Pranith Kumar
CC: Scott Wood
---
v2:
- fix build failures reported by Scott Wood
arch/powerpc/kernel/setup_64.c | 7 ++-
arch/powerpc/kernel/smp.c | 9 +++-
arch/s390/kernel/asm-offsets.c | 7 ++-
include/linux/notifier.h | 47 --
include/linux/srcu.h | 6 +-
5 files changed, 52 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 4f3cfe1..f55302f 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -65,10 +65,13 @@
#include
#include
#include
-#include
#include
#include
+#if IS_ENABLED(CONFIG_KVM)
+#include
+#endif
+
#ifdef DEBUG
#define DBG(fmt...) udbg_printf(fmt)
#else
@@ -286,8 +289,10 @@ void __init early_setup(unsigned long dt_ptr)
*/
cpu_ready_for_interrupts();
+#if IS_ENABLED(CONFIG_KVM)
/* Reserve large chunks of memory for use by CMA for KVM */
kvm_cma_reserve();
+#endif
/*
* Reserve any gigantic pages requested on the command line.
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 71e186d..0001daa 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -36,7 +36,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -54,6 +53,10 @@
#include
#include
+#if IS_ENABLED(CONFIG_KVM)
+#include
+#endif
+
#ifdef DEBUG
#include
#define DBG(fmt...) udbg_printf(fmt)
@@ -470,7 +473,11 @@ int generic_check_cpu_restart(unsigned int cpu)
static bool secondaries_inhibited(void)
{
+#if IS_ENABLED(CONFIG_KVM)
return kvm_hv_mode_active();
+#else
+ return false;
+#endif
}
#else /* HOTPLUG_CPU */
diff --git a/arch/s390/kernel/asm-offsets.c b/arch/s390/kernel/asm-offsets.c
index ef279a1..2813a3c 100644
--- a/arch/s390/kernel/asm-offsets.c
+++ b/arch/s390/kernel/asm-offsets.c
@@ -7,12 +7,15 @@
#define ASM_OFFSETS_C
#include
-#include
#include
#include
#include
#include
+#if IS_ENABLED(CONFIG_KVM)
+#include
+#endif
+
/*
* Make sure that the compiler is new enough. We want a compiler that
* is known to work with the "Q" assembler constraint.
@@ -182,8 +185,10 @@ int main(void)
DEFINE(__LC_PGM_TDB, offsetof(struct _lowcore, pgm_tdb));
DEFINE(__THREAD_trap_tdb, offsetof(struct task_struct,
thread.trap_tdb));
DEFINE(__GMAP_ASCE, offsetof(struct gmap, asce));
+#if IS_ENABLED(CONFIG_KVM)
DEFINE(__SIE_PROG0C, offsetof(struct kvm_s390_sie_block, prog0c));
DEFINE(__SIE_PROG20, offsetof(struct kvm_s390_sie_block, prog20));
+#endif /* CONFIG_KVM */
#endif /* CONFIG_32BIT */
return 0;
}
diff --git a/include/linux/notifier.h b/include/linux/notifier.h
index d14a4c3..fe4f02a 100644
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -47,6 +47,8 @@
* runtime initialization.
*/
+struct notifier_block;
+
typedefint (*notifier_fn_t)(struct notifier_block *nb,
unsigned long action, void *data);
@@ -70,12 +72,6 @@ struct raw_notifier_head {
struct notifier_block __rcu *head;
};
-struct srcu_notifier_head {
- struct mutex mutex;
- struct srcu_struct srcu;
- struct notifier_block __rcu *head;
-};
-
#define ATOMIC_INIT_NOTIFIER_HEAD(name) do { \
spin_lock_init(&(name)->lock); \
(name)->head = NULL;\
@@ -88,11 +84,6 @@ struct srcu_notifier_head {
(name)->head = NULL;\
} while (0)
-/* srcu_notifier_heads must be initialized and cleaned up dynamically */
-extern void srcu_init_notifier_head(struct srcu_notifier_head *nh);
-#define srcu_cleanup_notifier_head(name) \
- cleanup_srcu_struct(&(name)->srcu);
-
#define ATOMIC_NOTIFIER_INIT(name) { \
.lock = __SPIN_LOCK_UNLOCKED(name.lock),\
.head = NULL }
@@ -101,7 +92,6 @@ extern void srcu_init_notifier_head(struct
srcu_notifier_head *nh);
.head = NULL }
#define RAW_NOTIFIER_INIT(name){ \
.head = NULL }
-/* srcu_notifier_heads cannot be initialized statically */
#define ATOMIC_NOTIFIER_HEAD(name) \
struct
[alsa-devel] [PATCH] mfd: wm8994: use PLATFORM_DEVID_AUTO for regulator devs creation to avoid conflicts
After commit: 6e3f62f0793e ("mfd: core: Fix platform-device id generation")
We must set the id base when register a duplicate name of mfd_cell.
but, if we use PLATFORM_DEVID_AUTO flag, cell ids are automatically
allocated and managed without cell id setting.
Signed-off-by: Inha Song
---
drivers/mfd/wm8994-core.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/mfd/wm8994-core.c b/drivers/mfd/wm8994-core.c
index e6fab94..0505e45 100644
--- a/drivers/mfd/wm8994-core.c
+++ b/drivers/mfd/wm8994-core.c
@@ -36,12 +36,10 @@
static const struct mfd_cell wm8994_regulator_devs[] = {
{
.name = "wm8994-ldo",
- .id = 1,
.pm_runtime_no_callbacks = true,
},
{
.name = "wm8994-ldo",
- .id = 2,
.pm_runtime_no_callbacks = true,
},
};
@@ -344,7 +342,7 @@ static int wm8994_device_init(struct wm8994 *wm8994, int
irq)
dev_set_drvdata(wm8994->dev, wm8994);
/* Add the on-chip regulators first for bootstrapping */
- ret = mfd_add_devices(wm8994->dev, -1,
+ ret = mfd_add_devices(wm8994->dev, PLATFORM_DEVID_AUTO,
wm8994_regulator_devs,
ARRAY_SIZE(wm8994_regulator_devs),
NULL, 0, NULL);
--
2.0.0.390.gcb682f8
--
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: [resend][PATCH v9 2/3] /proc/PID/status: show all sets of pid according to ns
Chen Hanxiao writes: > If some issues occurred inside a container guest, host user > could not know which process is in trouble just by guest pid: > the users of container guest only knew the pid inside containers. > This will bring obstacle for trouble shooting. > > This patch adds four fields: NStgid, NSpid, NSpgid and NSsid: > a) In init_pid_ns, nothing changed; > > b) In one pidns, will tell the pid inside containers: > NStgid: 21776 5 1 > NSpid: 21776 5 1 > NSpgid: 21776 5 1 > NSsid: 21729 1 0 > ** Process id is 21776 in level 0, 5 in level 1, 1 in level 2. > > c) If pidns is nested, it depends on which pidns are you in. > NStgid: 5 1 > NSpid: 5 1 > NSpgid: 5 1 > NSsid: 1 0 > ** Views from level 1 > > Acked-by: Serge Hallyn > Tested-by: Serge Hallyn > > Signed-off-by: Chen Hanxiao Acked-by: "Eric W. Biederman" At a quick review and read through this looks good. Once I finish clearing the security bug fixes from my tree I will see about picking this up. Eric > --- > v9: rebased on 3.19-rc1 > No change from v4-v8 > v3: add another two fielsd: NSpgid and NSsid. > v2: add two new fields: NStgid and NSpid. > keep fields of Tgid and Pid unchanged for back compatibility. > > fs/proc/array.c | 16 > 1 file changed, 16 insertions(+) > > diff --git a/fs/proc/array.c b/fs/proc/array.c > index bd117d0..35205d4 100644 > --- a/fs/proc/array.c > +++ b/fs/proc/array.c > @@ -208,6 +208,22 @@ static inline void task_state(struct seq_file *m, struct > pid_namespace *ns, > from_kgid_munged(user_ns, GROUP_AT(group_info, g))); > put_cred(cred); > > + seq_puts(m, "\nNStgid:"); > + for (g = ns->level; g <= pid->level; g++) > + seq_printf(m, "\t%d ", > + task_tgid_nr_ns(p, pid->numbers[g].ns)); > + seq_puts(m, "\nNSpid:"); > + for (g = ns->level; g <= pid->level; g++) > + seq_printf(m, "\t%d ", > + task_pid_nr_ns(p, pid->numbers[g].ns)); > + seq_puts(m, "\nNSpgid:"); > + for (g = ns->level; g <= pid->level; g++) > + seq_printf(m, "\t%d ", > + task_pgrp_nr_ns(p, pid->numbers[g].ns)); > + seq_puts(m, "\nNSsid:"); > + for (g = ns->level; g <= pid->level; g++) > + seq_printf(m, "\t%d ", > + task_session_nr_ns(p, pid->numbers[g].ns)); > seq_putc(m, '\n'); > } -- 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: "perf top -g" leaking ~300MB per second.
Hi David and Markus,
On Sat, Dec 13, 2014 at 11:16:43AM -0700, David Ahern wrote:
> On 12/13/14 8:26 AM, Arnaldo Carvalho de Melo wrote:
> >The callchain code was done initially for 'report' and when I made 'top'
> >reuse the hist_entry code allowing 'top' to collect callchains was too
> >easy, but then we need to go thru the callchain/hists/hist_entry code to
> >make sure that they don't leak, will try to do it...
> >
>
> As I recall it is build up of the dead_threads list.
Maybe. But I guess it's because of leak of callchains..
Markus, could you please test below patch how much it affects?
>From b29ccd79727654653986ab1170e0b1f5d6518035 Mon Sep 17 00:00:00 2001
From: Namhyung Kim
Date: Tue, 30 Dec 2014 14:28:45 +0900
Subject: [PATCH] perf callchain: Free callchains when hist entries are deleted
Markus reported that "perf top -g" can leak ~300MB per second on his
machine. This is partly because it missed to free callchains when
hist entries are deleted. Fix it.
Reported-by: Markus Trippelsdorf
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/util/callchain.c | 30 ++
tools/perf/util/callchain.h | 2 ++
tools/perf/util/hist.c | 1 +
3 files changed, 33 insertions(+)
diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index 64b377e591e4..14e7a123d43b 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -841,3 +841,33 @@ char *callchain_list__sym_name(struct callchain_list *cl,
return bf;
}
+
+static void free_callchain_node(struct callchain_node *node)
+{
+ struct callchain_list *list, *tmp;
+ struct callchain_node *child;
+ struct rb_node *n;
+
+ list_for_each_entry_safe(list, tmp, >val, list) {
+ list_del(>list);
+ free(list);
+ }
+
+ n = rb_first(>rb_root_in);
+ while (n) {
+ child = container_of(n, struct callchain_node, rb_node_in);
+ n = rb_next(n);
+ rb_erase(>rb_node_in, >rb_root_in);
+
+ free_callchain_node(child);
+ free(child);
+ }
+}
+
+void free_callchain(struct callchain_root *root)
+{
+ if (!symbol_conf.use_callchain)
+ return;
+
+ free_callchain_node(>node);
+}
diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
index dbc08cf5f970..c0ec1acc38e4 100644
--- a/tools/perf/util/callchain.h
+++ b/tools/perf/util/callchain.h
@@ -198,4 +198,6 @@ static inline int arch_skip_callchain_idx(struct thread
*thread __maybe_unused,
char *callchain_list__sym_name(struct callchain_list *cl,
char *bf, size_t bfsize, bool show_dso);
+void free_callchain(struct callchain_root *root);
+
#endif /* __PERF_CALLCHAIN_H */
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 30ff2cb92884..e17163fcb702 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -945,6 +945,7 @@ void hist_entry__delete(struct hist_entry *he)
zfree(>mem_info);
zfree(>stat_acc);
free_srcline(he->srcline);
+ free_callchain(he->callchain);
free(he);
}
--
2.1.3
--
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] srcu: Isolate srcu sections using CONFIG_SRCU
On Mon, Dec 29, 2014 at 6:05 PM, Scott Wood wrote: > On Sat, 2014-12-27 at 12:17 -0500, Pranith Kumar wrote: >> Isolate the SRCU functions and data structures within CONFIG_SRCU so that >> there >> is a compile time failure if srcu is used when not enabled. This was decided >> to >> be better than waiting until link time for a failure to occur. > > Yes, false positives and extra ifdefs are so much better. :-P > > Why not just ifdef the functions/macros, and leave the types alone? If > you're worried about direct access to struct members, you could even > ifdef the members away while leaving the struct itself. It is not > normal practice in Linux to need ifdefs around #includes. Yup, totally agree that this is not ideal. The idea here is to not even compile the structure for tinification purposes. ifdefs for headers are ugly, but given the current code structure, I was not able to figure out any other way around it without major overhaul. > >> There are places which include kvm headers and utilize kvm data structures >> without checking if KVM is enabled. In two such archs(s390, ppc64), the >> current >> patch makes the uses of KVM conditional on KVM being enabled. The other >> option, >> which is to enable KVM unconditionally seemed a bit too much as we could >> easily >> figure out KVM only parts and enclose them in ifdefs. > > Maybe not so easy (mpc85xx_smp_defconfig with NOTIFY stuff turned off so > that SRCU gets deselected): > > In file included from > /home/scott/fsl/git/linux/upstream/arch/powerpc/include/asm/kvm_ppc.h:30:0, > from > /home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/smp.c:39: > /home/scott/fsl/git/linux/upstream/include/linux/kvm_host.h:366:21: error: > field 'srcu' has incomplete type > /home/scott/fsl/git/linux/upstream/include/linux/kvm_host.h:367:21: error: > field 'irq_srcu' has incomplete type > /home/scott/fsl/git/linux/upstream/scripts/Makefile.build:257: recipe for > target 'arch/powerpc/kernel/smp.o' failed > make[2]: *** [arch/powerpc/kernel/smp.o] Error 1 > /home/scott/fsl/git/linux/upstream/Makefile:955: recipe for target > 'arch/powerpc/kernel' failed > make[1]: *** [arch/powerpc/kernel] Error 2 > make[1]: *** Waiting for unfinished jobs > > Are you sure KVM is the only SRCU user so impacted? It's also likely > that new such problems get introduced, because most people are going to > have SRCU enabled and thus not notice the breakage they're adding. Well, it is the major one which I encountered until now. There might be other problems lurking which I will gladly try to fix if and when they are reported. > > There's also at least one place that needs to be fixed, that currently > expects to get other headers indirectly via srcu.h: > > /home/scott/fsl/git/linux/upstream/lib/assoc_array.c: In function > 'assoc_array_apply_edit': > /home/scott/fsl/git/linux/upstream/lib/assoc_array.c:1425:2: error: implicit > declaration of function 'call_rcu' [-Werror=implicit-function-declaration] > cc1: some warnings being treated as errors > /home/scott/fsl/git/linux/upstream/scripts/Makefile.build:257: recipe for > target 'lib/assoc_array.o' failed I will send a patch fixing this(need to use rcupdate.h here explicitly). Thanks for reporting these! > > -Scott > > -- Pranith -- 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/3] CMA: Add cma_alloc_counter to make cma_alloc work better if it meet busy range
On Thu, Dec 25, 2014 at 05:43:28PM +0800, Hui Zhu wrote: > In [1], Joonsoo said that cma_alloc_counter is useless because pageblock > is isolated. > But if alloc_contig_range meet a busy range, it will undo_isolate_page_range > before goto try next range. At this time, __rmqueue_cma can begin allocd > CMA memory from the range. Is there any real issue from this? When failed, we will quickly re-isolate pageblock for adjacent page so there is no big problem I guess. If there is real issue, how about doing start_isolation/undo_isolation in cma_alloc()? It would reduce useless do/undo isolation due to failed trial. 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: [PATCH 1/3] CMA: Fix the bug that CMA's page number is substructed twice
On Thu, Dec 25, 2014 at 05:43:26PM +0800, Hui Zhu wrote: > In Joonsoo's CMA patch "CMA: always treat free cma pages as non-free on > watermark checking" [1], it changes __zone_watermark_ok to substruct CMA > pages number from free_pages if system use CMA: > if (IS_ENABLED(CONFIG_CMA) && z->managed_cma_pages) > free_pages -= zone_page_state(z, NR_FREE_CMA_PAGES); Hello, In fact, without that patch, watermark checking has a problem in current kernel. If there is reserved CMA region, watermark check for high order allocation is done loosly. See following thread. https://lkml.org/lkml/2014/5/30/320 Your patch can fix this situation, so, how about submitting this patch separately? 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: [PATCH 0/3] mm: cma: /proc/cmainfo
On Mon, Dec 29, 2014 at 11:52:58AM -0800, Laura Abbott wrote: > On 12/28/2014 6:36 PM, Minchan Kim wrote: > >Hello, > > > >On Fri, Dec 26, 2014 at 05:39:01PM +0300, Stefan I. Strogin wrote: > >>Hello all, > >> > >>Here is a patch set that adds /proc/cmainfo. > >> > >>When compiled with CONFIG_CMA_DEBUG /proc/cmainfo will contain information > >>about about total, used, maximum free contiguous chunk and all currently > >>allocated contiguous buffers in CMA regions. The information about allocated > >>CMA buffers includes pid, comm, allocation latency and stacktrace at the > >>moment of allocation. > > > >It just says what you are doing but you didn't say why we need it. > >I can guess but clear description(ie, the problem what you want to > >solve with this patchset) would help others to review, for instance, > >why we need latency, why we need callstack, why we need new wheel > >rather than ftrace and so on. > > > >Thanks. > > > > > I've been meaning to write something like this for a while so I'm > happy to see an attempt made to fix this. I can't speak for the > author's reasons for wanting this information but there are > several reasons why I was thinking of something similar. > > The most common bug reports seen internally on CMA are 1) CMA is > too slow and 2) CMA failed to allocate memory. For #1, not all > allocations may be slow so it's useful to be able to keep track > of which allocations are taking too long. For #2, migration Then, I don't think we could keep all of allocations. What we need is only slow allocations. I hope we can do that with ftrace. ex) # cd /sys/kernel/debug/tracing # echo 1 > options/stacktrace # echo cam_alloc > set_ftrace_filter # echo your_threshold > tracing_thresh I know it doesn't work now but I think it's more flexible and general way to handle such issues(ie, latency of some functions). So, I hope we could enhance ftrace rather than new wheel. Ccing ftrace people. Futhermore, if we really need to have such information, we need more data (ex, how many of pages were migrated out, how many pages were dropped without migrated, how many pages were written back, how many pages were retried with the page lock and so on). In this case, event trace would be better. > failure is fairly common but it's still important to rule out > a memory leak from a dma client. Seeing all the allocations is > also very useful for memory tuning (e.g. how big does the CMA > region need to be, which clients are actually allocating memory). Memory leak is really general problem and could we handle it with page_owner? > > ftrace is certainly usable for tracing CMA allocation callers and > latency. ftrace is still only a fixed size buffer though so it's > possible for information to be lost if other logging is enabled. Sorry, I don't get with only above reasons why we need this. :( > For most of the CMA use cases, there is a very high cost if the > proper debugging information is not available so the more that > can be guaranteed the better. > > It's also worth noting that the SLUB allocator has a sysfs > interface for showing allocation callers when CONFIG_SLUB_DEBUG > is enabled. > > Thanks, > Laura > > -- > Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- Kind regards, Minchan Kim -- 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 v16 01/12] input: cyapa: re-design driver to support multi-trackpad in one driver
Dmitry, Thanks a lot for your review and detail comments. Please see my replies below. Thanks, Dudley > -Original Message- > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] > Sent: 2014?12?30? 9:06 > To: Dudley Du > Cc: jmmah...@gmail.com; rydb...@euromail.se; ble...@google.com; > linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH v16 01/12] input: cyapa: re-design driver to support > multi-trackpad in one driver > > Hi Dudley, > > On Thu, Dec 18, 2014 at 06:00:45PM +0800, Dudley Du wrote: > > In order to support multiple different chipsets and communication protocols > > trackpad devices in one cyapa driver, the new cyapa driver is re-designed > > with one cyapa driver core and multiple device specific functions component. > > The cyapa driver core is contained in this patch, it supplies basic > > functions > > that working with kernel and input subsystem, and also supplies the > > interfaces > > that the specific devices' component can connect and work together with as > > one driver. > > TEST=test on Chromebooks. > > Thank you for making changes to the driver. It shapes up nicely, still > I have a few comments: > > 1. I'd rather we did not check for presence of various methods in ops > structure but rather rely on providers to supply stubs if they do not > need actual implementation (see a draft of a patch below). > I will supply stubs for both in the ops structure. > 2. Please consider changing CYAPA_BOOTLOADER() and friends to be static > inline functions (like cyapa_is_bootloader_mode())- it provides better > type checking. > I will supply statci inlie function cyapa_is_bootloader_mode() and cyapa_is_operational_mode() instead of CYAPA_BOOTLOADER() and CYAPA_OPERATIONAL() > 3. The ops->initialize() method should be called after we determine the > generation of the device, not before. > No, it cannot be called after we determine the generation of the device. Because the ops->initialize() is used to prepare the communication status for the driver. It will initialize and parpare the communication for gen5 command process which will be used in cyapa_detect() when detecting gen5, so It cannot be called after we determine the generation of the device. > 4. I wonder why cyapa_read_block() is in gen3 file and not in main file > - it seems it is used by generic code? > cyapa_read_block() is mainly used to read block data from gen3 TP. It is used in both main file and gen3 file. And this function will use static variables cyapa_smbus_cmd[] and cyapa_i2c_cmds[] which are dedicated to gen3 TP and defined in gen3 file, so I think it should be put in the gen3 file instead of in main file to avoid put the variables cyapa_smbus_cmd[] and cyapa_i2c_cmds[] into main file. That why put it in gen3 file. > 5. Is bootloader mode different between gen3 and gen5 devices? Or should > you detect and handle bootloader mode directly in the core, maybe as a > "fake generation"? > Yes, the bootloader mode is completely different between gen3 and gen5 device. No protocol or mechanism could be shared. For detect and handle bootloader mode directly in the core, do you mean add the function to exit bootloader mode as do for firmware update? Currently, the bootloader operation porcess of firmware update is abstracted into cyapa_firmware() and put it in the core, other operations that are dedicated to gen3/gen5 TP device are seperated in to gen3/gen5 file. > Thanks! > > > > > Signed-off-by: Dudley Du > > --- > > drivers/input/mouse/Makefile |3 +- > > drivers/input/mouse/cyapa.c | 1047 > > ++ > > drivers/input/mouse/cyapa.h | 307 +++ > > drivers/input/mouse/cyapa_gen3.c | 801 + > > 4 files changed, 1492 insertions(+), 666 deletions(-) > > create mode 100644 drivers/input/mouse/cyapa.h > > create mode 100644 drivers/input/mouse/cyapa_gen3.c > > > > diff --git a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile ... > > + > > +.irq_handler = cyapa_gen3_irq_handler, > > +.irq_cmd_handler = cyapa_gen3_irq_cmd_handler, > > + > > +.set_power_mode = cyapa_gen3_set_power_mode, > > +}; > > -- > > 1.9.1 > > > > -- > Dmitry > > Input: cyapa - misc changes > > From: Dmitry Torokhov > > Signed-off-by: Dmitry Torokhov > --- > drivers/input/mouse/cyapa.c | 50 > --- > 1 file changed, 28 insertions(+), 22 deletions(-) > > diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c > index ae1df15..27ae5e61 100644 > --- a/drivers/input/mouse/cyapa.c > +++ b/drivers/input/mouse/cyapa.c > @@ -36,10 +36,8 @@ const char product_id[] = "CYTRA"; > static int cyapa_reinitialize(struct cyapa *cyapa); > > /* Returns 0 on success, else negative errno on failure. */ > -static ssize_t cyapa_i2c_read(struct cyapa *cyapa, u8 reg, size_t len, > -u8 *values) > +static int cyapa_i2c_read(struct cyapa *cyapa, u8 reg, size_t len, u8 >
[PATCH] tty: 8250: Add 64byte UART support for FSL platforms
Some of FSL SoCs like T1040 has new version of UART controller which
can support 64byte FiFo.
To enable 64 byte support, following needs to be done:
-FCR[EN64] needs to be programmed to 1 to enable it.
-Also, when FCR[EN64]==1, RTL bits to be used as below
to define various Receive Trigger Levels:
-FCR[RTL] = 00 1 byte
-FCR[RTL] = 01 16 bytes
-FCR[RTL] = 10 32 bytes
-FCR[RTL] = 11 56 bytes
-tx_loadsz is set to 32-bytes instead of 64-bytes to implement
workaround of errata A-008006 which states that tx_loadsz should
be configured less than Maximum supported fifo bytes
Signed-off-by: Vijay Rai
Signed-off-by: Priyanka Jain
Signed-off-by: Poonam Aggrwal
---
drivers/tty/serial/8250/8250_core.c | 20 +++-
include/uapi/linux/serial_core.h|3 ++-
include/uapi/linux/serial_reg.h |3 ++-
3 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 11c6685..565748c 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -329,6 +329,14 @@ static const struct serial8250_config uart_config[] = {
.fcr= UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
.flags = UART_CAP_FIFO | UART_CAP_AFE,
},
+ [PORT_16550A_FSL64] = {
+ .name = "16550A_FSL64",
+ .fifo_size = 64,
+ .tx_loadsz = 32,
+ .fcr= UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10 |
+ UART_FCR7_64BYTE,
+ .flags = UART_CAP_FIFO,
+ },
};
/* Uart divisor latch read */
@@ -956,7 +964,17 @@ static void autoconfig_16550a(struct uart_8250_port *up)
up->port.type = PORT_16650;
up->capabilities |= UART_CAP_EFR | UART_CAP_SLEEP;
} else {
- DEBUG_AUTOCONF("Motorola 8xxx DUART ");
+ serial_out(up, UART_LCR, 0);
+ serial_out(up, UART_FCR, UART_FCR_ENABLE_FIFO |
+ UART_FCR7_64BYTE);
+ status1 = serial_in(up, UART_IIR) >> 5;
+ serial_out(up, UART_FCR, 0);
+ serial_out(up, UART_LCR, 0);
+
+ if (status1 == 7)
+ up->port.type = PORT_16550A_FSL64;
+ else
+ DEBUG_AUTOCONF("Motorola 8xxx DUART ");
}
serial_out(up, UART_EFR, 0);
return;
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index c172180..a3b4491 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -55,7 +55,8 @@
#define PORT_ALTR_16550_F64 27 /* Altera 16550 UART with 64 FIFOs */
#define PORT_ALTR_16550_F128 28 /* Altera 16550 UART with 128 FIFOs */
#define PORT_RT288029 /* Ralink RT2880 internal UART */
-#define PORT_MAX_8250 29 /* max port ID */
+#define PORT_16550A_FSL64 30 /* Freescale 16550 UART with 64 FIFOs */
+#define PORT_MAX_8250 31 /* max port ID */
/*
* ARM specific type numbers. These are not currently guaranteed
diff --git a/include/uapi/linux/serial_reg.h b/include/uapi/linux/serial_reg.h
index 53af3b7..00adb01 100644
--- a/include/uapi/linux/serial_reg.h
+++ b/include/uapi/linux/serial_reg.h
@@ -86,7 +86,8 @@
#define UART_FCR6_T_TRIGGER_8 0x10 /* Mask for transmit trigger set at 8 */
#define UART_FCR6_T_TRIGGER_24 0x20 /* Mask for transmit trigger set at 24 */
#define UART_FCR6_T_TRIGGER_30 0x30 /* Mask for transmit trigger set at 30 */
-#define UART_FCR7_64BYTE 0x20 /* Go into 64 byte mode (TI16C750) */
+#define UART_FCR7_64BYTE 0x20 /* Go into 64 byte mode (TI16C750 and
+ some Freescale UARTs) */
#define UART_FCR_R_TRIG_SHIFT 6
#define UART_FCR_R_TRIG_BITS(x)\
--
1.7.9.5
--
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/
perf-probe crash in dwarf_getcfi_elf
Hi Namhyung: Using perf-probe from top of Linus' tree I get a segfault on both Fedora 16 and 18 (does not crash on Fedora 20). Command used is: perf probe -x /lib64/libc-2.14.90.so -a 'malloc size=%di' git bisect points to: commit 03d89412981a7681971bc77edba1669595763030 Author: Namhyung Kim Date: Mon Apr 7 16:05:48 2014 +0900 perf probe: Use dwarf_getcfi_elf() instead of dwarf_getcfi() Backtrace at time of crash is: (gdb) bt #0 parse_eh_frame_hdr (hdr=0x0, hdr_size=2596, hdr_vaddr=71788, ehdr=0x7fffd390, eh_frame_vaddr= 0x7fffd378, table_entries=0x8808d8, table_encoding=0x8808e0 "") at dwarf_getcfi_elf.c:79 #1 0x00385f81615a in getcfi_scn_eh_frame (hdr_vaddr=71788, hdr_scn=0x8839b0, shdr=0x7fffd2f0, scn=, ehdr=0x7fffd390, elf=0x882b30) at dwarf_getcfi_elf.c:231 #2 getcfi_shdr (ehdr=0x7fffd390, elf=0x882b30) at dwarf_getcfi_elf.c:283 #3 dwarf_getcfi_elf (elf=0x882b30) at dwarf_getcfi_elf.c:309 #4 0x004d5bac in debuginfo__find_probes (pf=0x7fffd4f0, dbg=Unhandled dwarf expression opcode 0xfa ) at util/probe-finder.c:993 #5 0x004d634a in debuginfo__find_trace_events (dbg=0x880840, pev=, tevs=0x880f88, max_tevs=) at util/probe-finder.c:1200 #6 0x004aed6b in try_to_find_probe_trace_events (target=0x881b20 "/lib64/libpthread-2.14.90.so", max_tevs=128, tevs=0x880f88, pev=0x859b30) at util/probe-event.c:482 #7 convert_to_probe_trace_events (target=0x881b20 "/lib64/libpthread-2.14.90.so", max_tevs=128, tevs=0x880f88, pev=0x859b30) at util/probe-event.c:2356 #8 add_perf_probe_events (pevs=, npevs=1, max_tevs=128, target= 0x881b20 "/lib64/libpthread-2.14.90.so", force_add=false) at util/probe-event.c:2391 #9 0x0044014f in __cmd_probe (argc=, argv=0x7fffe2f0, prefix=Unhandled dwarf expression opcode 0xfa ) at builtin-probe.c:488 #10 0x00440313 in cmd_probe (argc=5, argv=0x7fffe2f0, prefix=) at builtin-probe.c:506 #11 0x0041d133 in run_builtin (p=0x805680, argc=5, argv=0x7fffe2f0) at perf.c:341 #12 0x0041c8b2 in handle_internal_command (argv=, argc=) at perf.c:400 #13 run_argv (argv=, argcp=) at perf.c:444 #14 main (argc=5, argv=0x7fffe2f0) at perf.c:559 David -- 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/3] mm: cma: introduce /proc/cmainfo
On Fri, Dec 26, 2014 at 05:39:03PM +0300, Stefan I. Strogin wrote:
> /proc/cmainfo contains a list of currently allocated CMA buffers for every
> CMA area when CONFIG_CMA_DEBUG is enabled.
Hello,
I think that providing these information looks useful, but, we need better
implementation. As Laura said, it is better to use debugfs. And,
instead of re-implementing the wheel, how about using tracepoint
to print these information? See below comments.
>
> Format is:
>
> - ( kB), allocated by \
> (), latency us
>
>
> Signed-off-by: Stefan I. Strogin
> ---
> mm/cma.c | 202
> +++
> 1 file changed, 202 insertions(+)
>
> diff --git a/mm/cma.c b/mm/cma.c
> index a85ae28..ffaea26 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -34,6 +34,10 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> +#include
>
> struct cma {
> unsigned long base_pfn;
> @@ -41,8 +45,25 @@ struct cma {
> unsigned long *bitmap;
> unsigned int order_per_bit; /* Order of pages represented by one bit */
> struct mutexlock;
> +#ifdef CONFIG_CMA_DEBUG
> + struct list_head buffers_list;
> + struct mutexlist_lock;
> +#endif
> };
>
> +#ifdef CONFIG_CMA_DEBUG
> +struct cma_buffer {
> + unsigned long pfn;
> + unsigned long count;
> + pid_t pid;
> + char comm[TASK_COMM_LEN];
> + unsigned int latency;
> + unsigned long trace_entries[16];
> + unsigned int nr_entries;
> + struct list_head list;
> +};
> +#endif
> +
> static struct cma cma_areas[MAX_CMA_AREAS];
> static unsigned cma_area_count;
> static DEFINE_MUTEX(cma_mutex);
> @@ -132,6 +153,10 @@ static int __init cma_activate_area(struct cma *cma)
> } while (--i);
>
> mutex_init(>lock);
> +#ifdef CONFIG_CMA_DEBUG
> + INIT_LIST_HEAD(>buffers_list);
> + mutex_init(>list_lock);
> +#endif
> return 0;
>
> err:
> @@ -347,6 +372,86 @@ err:
> return ret;
> }
>
> +#ifdef CONFIG_CMA_DEBUG
> +/**
> + * cma_buffer_list_add() - add a new entry to a list of allocated buffers
> + * @cma: Contiguous memory region for which the allocation is performed.
> + * @pfn: Base PFN of the allocated buffer.
> + * @count: Number of allocated pages.
> + * @latency: Nanoseconds spent to allocate the buffer.
> + *
> + * This function adds a new entry to the list of allocated contiguous memory
> + * buffers in a CMA area. It uses the CMA area specificated by the device
> + * if available or the default global one otherwise.
> + */
> +static int cma_buffer_list_add(struct cma *cma, unsigned long pfn,
> +int count, s64 latency)
> +{
> + struct cma_buffer *cmabuf;
> + struct stack_trace trace;
> +
> + cmabuf = kmalloc(sizeof(struct cma_buffer), GFP_KERNEL);
> + if (!cmabuf)
> + return -ENOMEM;
> +
> + trace.nr_entries = 0;
> + trace.max_entries = ARRAY_SIZE(cmabuf->trace_entries);
> + trace.entries = >trace_entries[0];
> + trace.skip = 2;
> + save_stack_trace();
> +
> + cmabuf->pfn = pfn;
> + cmabuf->count = count;
> + cmabuf->pid = task_pid_nr(current);
> + cmabuf->nr_entries = trace.nr_entries;
> + get_task_comm(cmabuf->comm, current);
> + cmabuf->latency = (unsigned int) div_s64(latency, NSEC_PER_USEC);
> +
> + mutex_lock(>list_lock);
> + list_add_tail(>list, >buffers_list);
> + mutex_unlock(>list_lock);
> +
> + return 0;
> +}
> +
> +/**
> + * cma_buffer_list_del() - delete an entry from a list of allocated buffers
> + * @cma: Contiguous memory region for which the allocation was performed.
> + * @pfn: Base PFN of the released buffer.
> + *
> + * This function deletes a list entry added by cma_buffer_list_add().
> + */
> +static void cma_buffer_list_del(struct cma *cma, unsigned long pfn)
> +{
> + struct cma_buffer *cmabuf;
> +
> + mutex_lock(>list_lock);
> +
> + list_for_each_entry(cmabuf, >buffers_list, list)
> + if (cmabuf->pfn == pfn) {
> + list_del(>list);
> + kfree(cmabuf);
> + goto out;
> + }
> +
Is there more elegant way to find buffer? This linear search overhead
would change system behaviour if there are lots of buffers.
> + pr_err("%s(pfn %lu): couldn't find buffers list entry\n",
> +__func__, pfn);
> +
> +out:
> + mutex_unlock(>list_lock);
> +}
> +#else
> +static int cma_buffer_list_add(struct cma *cma, unsigned long pfn,
> +int count, s64 latency)
> +{
> + return 0;
> +}
> +
> +static void cma_buffer_list_del(struct cma *cma, unsigned long pfn)
> +{
> +}
> +#endif /* CONFIG_CMA_DEBUG */
> +
> /**
> * cma_alloc() - allocate pages from contiguous area
> * @cma: Contiguous memory region for which the allocation is performed.
> @@ -361,11 +466,15 @@ struct page *cma_alloc(struct cma *cma, int count,
>
Re: [PATCH] srcu: Isolate srcu sections using CONFIG_SRCU
On Mon, Dec 29, 2014 at 5:03 AM, Martin Schwidefsky wrote: > On Sat, 27 Dec 2014 12:17:43 -0500 > Pranith Kumar wrote: > >> @@ -65,10 +65,13 @@ >> #include >> #include >> #include >> -#include >> #include >> #include >> >> +#if IS_ENABLED(CONFIG_KVM) >> +#include >> +#endif >> + >> #ifdef DEBUG >> #define DBG(fmt...) udbg_printf(fmt) >> #else > > I always cringe when I see an include protected by an #ifdef. > Is this really necessary? All that is done in asm-offsets.c is > to calculate offsets, the code where the two offsets in question > are used (entry64.S) does have the #ifdef for CONFIG_KVM. I agree that this is not the ideal way to do this. But, it has been the way things were already being done. If you see arch/powerpc/kernel/asm-offsets.c, there are quite some includes which are within ifdefs. I've considered other alternatives (though not in-depth) and found that they will require quite some refactoring. One simple idea is to move this #ifdef to within kvm_ppc.h. That should make the inclusion of this file a no-op in all the places where this is being included without KVM being enabled. But I am not 100% sure of that approach. Any suggestions are welcome. -- Pranith -- 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/
problems with perf probe and system libraries
Hi Masami: I have been looking at perf-probe again and having a number of problems with top of tree. Here's the first one I have isolated: $ perf probe -x /lib64/libc-2.18.so -a 'malloc size=%di' Probe point 'malloc' not found. Error: Failed to add events. $ perf probe -x /lib64/libc-2.18.so -F | grep malloc malloc malloc@plt malloc_atfork malloc_check malloc_consolidate malloc_hook_ini malloc_info malloc_printerr mallochook ptmalloc_init ptmalloc_init.part.8 ptmalloc_lock_all ptmalloc_unlock_all ptmalloc_unlock_all2 tr_mallochook $ perf probe -x /lib64/libc-2.18.so -a 'malloc=malloc size=%di' Probe point 'malloc' not found. Error: Failed to add events. A year ago (v3.12) this worked fine so I did a git bisect which points to: commit fb7345bbf7fad9bf72ef63a19c707970b9685812 Author: Masami Hiramatsu Date: Thu Dec 26 05:41:53 2013 + perf probe: Support basic dwarf-based operations on uprobe events I have tried top of tree on Fedora 16, 18 and 20 with a variety of kernels - and a variety of results. Reverting to 8a613d40e389b723fd5889ac8d4033ed4030be31 which is the commit before this one and it works again. David -- 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: [Linux-ima-user] Initramfs and IMA Appraisal
On 12/29/2014 09:20 PM, Mimi Zohar wrote: > On Mon, 2014-12-29 at 19:55 -0600, Rob Landley wrote: >>> Thanks Rob for the explanation. The problem is that ramfs does not >>> support extended attributes, while tmpfs does. >> >> If you're _using_ initramfs/initmpfs, there's no reason to specify a root=. > > The menu entry looks like: > linux /vmlinuz-3.17.0+ root=UUID=94595ff7-0fd4-4ea3-99f2-f7ddf8fbc91f > ro ... > initrd /initramfs-3.17.0+.img > > Because "root=" is specified, rootfs is not using tmpfs. Yes. Pilot error. If you want tmpfs to switch to UUID $THINGY you can do ROOT= and have it use that. You're asking for something to be interpreted by the kernel sometimes and passed on to userspace other times and have no side effects even though it's interpeted by the kernel. >>> The boot loader could >>> "measure" (trusted boot) the initramfs, but as the initramfs is >>> generated on the target system, the initramfs is not signed, preventing >>> it from being appraised (secure Boot). To close the initramfs integrity >>> appraisal gap requires verifying the individual initramfs file >>> signatures, which are stored as extended attributes. >> >> Faced with the phrases "trusted boot" and "integrity appraisal", I plead >> the third. > > Fine. Bottom line, rootfs needs to support extended attributes. I added a patch to make it work as tmpfs a year ago. You now know what trivial configuration mistake you make that's preventing it from working. If you'd like me to submit a documentation update patch to make it easier to avoid in future, I can do that. >> (In the wake of the Snowden infodump, > > All the more reason to allow only those files that are properly signed > to be read/executed. Using the infrastructure the NSA provided, which is intentionally so complicated that "you are not expected to understand this". Good luck with that. > Mimi 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: Remove TO DO in jfs_xtree.c
On 12/29/2014 09:48 PM, ty...@mit.edu wrote: > On Mon, Dec 29, 2014 at 04:13:37PM -0600, Dave Kleikamp wrote: >> On 12/27/2014 06:58 PM, nick wrote: >>> Greetings Dave, >>> I am wondering why there is a TO DO above this code: >>> * ToDo: tlocks should be on doubly-linked list, so we can >>> * quickly remove it and add it to the end. >> >> I'm sure the idea was to avoid the for loop needed to find the previous >> entry in the linked list. A doubly-linked list makes it much simpler to >> remove an item from an arbitrary position in the list. > > Hi Dave, > > Just in case you weren't aware, Nick has been banned from the LKML > list for being a troll. Thanks, Ted. Now I remember some earlier threads. Forgot it was the same person. Just figured him for a novice looking for something to contribute. Thanks, Shaggy -- 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: Remove TO DO in jfs_xtree.c
On Mon, Dec 29, 2014 at 04:13:37PM -0600, Dave Kleikamp wrote: > On 12/27/2014 06:58 PM, nick wrote: > > Greetings Dave, > > I am wondering why there is a TO DO above this code: > > * ToDo: tlocks should be on doubly-linked list, so we can > > * quickly remove it and add it to the end. > > I'm sure the idea was to avoid the for loop needed to find the previous > entry in the linked list. A doubly-linked list makes it much simpler to > remove an item from an arbitrary position in the list. Hi Dave, Just in case you weren't aware, Nick has been banned from the LKML list for being a troll. A common troll trick is to send e-mail to a number of individuals with a mailing list (in this case, LKML) cc'ed, in the hopes that people will reply, quoting the troll's words, so they can get around the mailing list ban. The reason why he has been banned is because he has apparently been desperate to get _some_ patches into the Linux kernel. Enough so that he has proposed patches which do not compile, and/or were not tested and/or for which he had no hardware (so he couldn't possibly have tested it). As a maintainer, you should be aware of his past history, and chose for yourself whether, in the future, you feel you should respond to any e-mail that he might send you. Regards, - Ted P.S. Personally, the best reason for banning him isn't that he has been wasting maintainers' time, but that he was responding to users who were reporting bugs with nonsensical responses that were actively harmful to users who were looking for help. -- 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] SCSI:STORVSC Use SCSI layer to allocate memory for per-command device request data
> -Original Message-
> From: Christoph Hellwig [mailto:h...@lst.de]
> Sent: Monday, December 29, 2014 8:05 PM
> To: KY Srinivasan; Haiyang Zhang; jbottom...@parallels.com
> Cc: linux-s...@vger.kernel.org; de...@linuxdriverproject.org; linux-
> ker...@vger.kernel.org; Long Li; Christoph Hellwig
> Subject: [PATCH] SCSI:STORVSC Use SCSI layer to allocate memory for per-
> command device request data
>
> STORVSC uses its own momory pool to manage device request data.
> However, SCSI layer already has a mechanisim for allocating additional
> memory for each command issued to device driver. This patch removes the
> memory pool in STORVSC and makes it use SCSI layer to allocate memory for
> device request data.
>
> Reviewed-by: Long Li
> Signed-off-by: Christoph Hellwig
Thanks Christoph.
Signed-off-by: K. Y. Srinivasan
> ---
> drivers/scsi/storvsc_drv.c | 119
> +++--
> 1 file changed, 8 insertions(+), 111 deletions(-)
>
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index
> 4cff0dd..14ee98e 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -32,7 +32,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -309,14 +308,6 @@ enum storvsc_request_type {
> * This is the end of Protocol specific defines.
> */
>
> -
> -/*
> - * We setup a mempool to allocate request structures for this driver
> - * on a per-lun basis. The following define specifies the number of
> - * elements in the pool.
> - */
> -
> -#define STORVSC_MIN_BUF_NR 64
> static int storvsc_ringbuffer_size = (20 * PAGE_SIZE);
>
> module_param(storvsc_ringbuffer_size, int, S_IRUGO); @@ -346,7 +337,6
> @@ static void storvsc_on_channel_callback(void *context);
> #define STORVSC_IDE_MAX_CHANNELS 1
>
> struct storvsc_cmd_request {
> - struct list_head entry;
> struct scsi_cmnd *cmd;
>
> unsigned int bounce_sgl_count;
> @@ -357,7 +347,6 @@ struct storvsc_cmd_request {
> /* Synchronize the request/response if needed */
> struct completion wait_event;
>
> - unsigned char *sense_buffer;
> struct hv_multipage_buffer data_buffer;
> struct vstor_packet vstor_packet;
> };
> @@ -389,11 +378,6 @@ struct storvsc_device {
> struct storvsc_cmd_request reset_request; };
>
> -struct stor_mem_pools {
> - struct kmem_cache *request_pool;
> - mempool_t *request_mempool;
> -};
> -
> struct hv_host_device {
> struct hv_device *dev;
> unsigned int port;
> @@ -1070,10 +1054,8 @@ static void storvsc_command_completion(struct
> storvsc_cmd_request *cmd_request) {
> struct scsi_cmnd *scmnd = cmd_request->cmd;
> struct hv_host_device *host_dev = shost_priv(scmnd->device-
> >host);
> - void (*scsi_done_fn)(struct scsi_cmnd *);
> struct scsi_sense_hdr sense_hdr;
> struct vmscsi_request *vm_srb;
> - struct stor_mem_pools *memp = scmnd->device->hostdata;
> struct Scsi_Host *host;
> struct storvsc_device *stor_dev;
> struct hv_device *dev = host_dev->dev; @@ -1109,14 +1091,7 @@
> static void storvsc_command_completion(struct storvsc_cmd_request
> *cmd_request)
> cmd_request->data_buffer.len -
> vm_srb->data_transfer_length);
>
> - scsi_done_fn = scmnd->scsi_done;
> -
> - scmnd->host_scribble = NULL;
> - scmnd->scsi_done = NULL;
> -
> - scsi_done_fn(scmnd);
> -
> - mempool_free(cmd_request, memp->request_mempool);
> + scmnd->scsi_done(scmnd);
> }
>
> static void storvsc_on_io_completion(struct hv_device *device, @@ -1160,7
> +1135,7 @@ static void storvsc_on_io_completion(struct hv_device *device,
> SRB_STATUS_AUTOSENSE_VALID) {
> /* autosense data available */
>
> - memcpy(request->sense_buffer,
> + memcpy(request->cmd->sense_buffer,
> vstor_packet->vm_srb.sense_data,
> vstor_packet->vm_srb.sense_info_length);
>
> @@ -1378,55 +1353,6 @@ static int storvsc_do_io(struct hv_device *device,
> return ret;
> }
>
> -static int storvsc_device_alloc(struct scsi_device *sdevice) -{
> - struct stor_mem_pools *memp;
> - int number = STORVSC_MIN_BUF_NR;
> -
> - memp = kzalloc(sizeof(struct stor_mem_pools), GFP_KERNEL);
> - if (!memp)
> - return -ENOMEM;
> -
> - memp->request_pool =
> - kmem_cache_create(dev_name(>sdev_dev),
> - sizeof(struct storvsc_cmd_request), 0,
> - SLAB_HWCACHE_ALIGN, NULL);
> -
> - if (!memp->request_pool)
> - goto err0;
> -
> - memp->request_mempool = mempool_create(number,
> mempool_alloc_slab,
> - mempool_free_slab,
> -
[PATCH RFC v7 06/21] ARM: imx6q: clk: Change hdmi_isfr clock's parent to be video_27m clock
According to the table 33-1 in the i.MX6Q reference manual, the hdmi_isfr
clock's parent should be the video_27m clock. The i.MX6DL reference manual
has the same statement. This patch changes the hdmi_isfr clock's parent
from the pll3_pfd1_540m clock to the video_27m clock.
Suggested-by: Philipp Zabel
Signed-off-by: Liu Ying
---
v6->v7:
* None.
v5->v6:
* None.
v4->v5:
* None.
v3->v4:
* None.
v2->v3:
* Newly introduced in v3.
arch/arm/mach-imx/clk-imx6q.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 9470df3..f19472a 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -401,7 +401,7 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
clk[IMX6QDL_CLK_GPU2D_CORE] = imx_clk_gate2("gpu2d_core",
"gpu2d_core_podf", base + 0x6c, 24);
clk[IMX6QDL_CLK_GPU3D_CORE] = imx_clk_gate2("gpu3d_core",
"gpu3d_core_podf", base + 0x6c, 26);
clk[IMX6QDL_CLK_HDMI_IAHB]= imx_clk_gate2("hdmi_iahb", "ahb",
base + 0x70, 0);
- clk[IMX6QDL_CLK_HDMI_ISFR]= imx_clk_gate2("hdmi_isfr",
"pll3_pfd1_540m",base + 0x70, 4);
+ clk[IMX6QDL_CLK_HDMI_ISFR]= imx_clk_gate2("hdmi_isfr",
"video_27m", base + 0x70, 4);
clk[IMX6QDL_CLK_I2C1] = imx_clk_gate2("i2c1",
"ipg_per", base + 0x70, 6);
clk[IMX6QDL_CLK_I2C2] = imx_clk_gate2("i2c2",
"ipg_per", base + 0x70, 8);
clk[IMX6QDL_CLK_I2C3] = imx_clk_gate2("i2c3",
"ipg_per", base + 0x70, 10);
--
2.1.0
--
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 RFC v7 02/21] of: Add vendor prefix for Himax Technologies Inc.
Signed-off-by: Liu Ying --- v6->v7: * None. v5->v6: * None. v4->v5: * None. v3->v4: * Fix an ordering issue to address Stefan Wahren's comment. v2->v3: * None. v1->v2: * None. Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 78efebb..f46adb2 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -67,6 +67,7 @@ gumstix Gumstix, Inc. gw Gateworks Corporation hannstar HannStar Display Corporation haoyu Haoyu Microelectronic Co. Ltd. +himax Himax Technologies, Inc. hisilicon Hisilicon Limited. hitHitachi Ltd. honeywell Honeywell -- 2.1.0 -- 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 RFC v7 00/21] Add support for i.MX MIPI DSI DRM driver
Hi, This version addresses some comments from Andrzej Hajda on v6. The comments are only for the Himax HX8369A DRM panel driver(PATCH 16/21). The i.MX MIPI DSI is a Synopsys DesignWare MIPI DSI host controller IP. This series adds support for a Synopsys DesignWare MIPI DSI host controller DRM bridge driver and a i.MX MIPI DSI specific DRM driver. Currently, the MIPI DSI drivers only support the burst with sync pulse mode. This series also includes a DRM panel driver for the Truly TFT480800-16-E panel which is driven by the Himax HX8369A driver IC. The driver IC data sheet could be found at [1]. As mentioned by the data sheet, the driver IC supports several interface modes. Currently, the DRM panel driver only supports the MIPI DSI video mode. New interface modes could be added later(perhaps, just like the way the DRM simple panel driver supports both MIPI DSI interface panels and simple(parallel) interface panels). The MIPI DSI feature is tested on i.MX6Q SabreSD board and i.MX6DL SabreSD board. The MIPI DSI display could be enabled directly on i.MX6Q SabreSD board after applying this series, because the 26.4MHz pixel clock the panel requires could be derived from the IPU HSP clock(264MHz) with an integer divider. On i.MX6DL SabreSD board, we need to manually disable the LVDS and HDMI displays in the device tree blob, since the i.MX6DL IPU HSP clock is 198MHz at present, which makes the pixel clock share the PLL5 video clock source with the LVDS and HDMI, thus, the panel cannot get the pixel clock rate it wants. Patch 01/21 is needed to get a precise pixel clock rate(26.4MHz) from the PLL5 video clock. If we don't have this patch, the pixel clock rate is about 20MHz, which causes a horitonal shift on the display image. This series can be applied on the drm-next branch. [1] http://www.allshore.com/pdf/Himax_HX8369-A.pdf Liu Ying (21): clk: divider: Correct parent clk round rate if no bestdiv is normally found of: Add vendor prefix for Himax Technologies Inc. of: Add vendor prefix for Truly Semiconductors Limited ARM: imx6q: Add GPR3 MIPI muxing control register field shift bits definition ARM: imx6q: clk: Add the video_27m clock ARM: imx6q: clk: Change hdmi_isfr clock's parent to be video_27m clock ARM: imx6q: clk: Change hsi_tx clock to be a shared clock gate ARM: imx6q: clk: Add support for mipi_core_cfg clock as a shared clock gate ARM: dts: imx6qdl: Move existing MIPI DSI ports into a new 'ports' node drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format Documentation: dt-bindings: Add bindings for Synopsys DW MIPI DSI DRM bridge driver drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver Documentation: dt-bindings: Add bindings for i.MX specific Synopsys DW MIPI DSI driver drm: imx: Support Synopsys DesignWare MIPI DSI host controller Documentation: dt-bindings: Add bindings for Himax HX8369A DRM panel driver drm: panel: Add support for Himax HX8369A MIPI DSI panel ARM: dtsi: imx6qdl: Add support for MIPI DSI host controller ARM: dts: imx6qdl-sabresd: Add support for TRULY TFT480800-16-E MIPI DSI panel ARM: imx_v6_v7_defconfig: Cleanup for imx drm being moved out of staging ARM: imx_v6_v7_defconfig: Add support for MIPI DSI host controller ARM: imx_v6_v7_defconfig: Add support for Himax HX8369A panel .../devicetree/bindings/drm/bridge/dw_mipi_dsi.txt | 73 ++ .../devicetree/bindings/drm/imx/mipi_dsi.txt | 78 ++ .../devicetree/bindings/panel/himax,hx8369a.txt| 39 + .../devicetree/bindings/vendor-prefixes.txt| 2 + arch/arm/boot/dts/imx6q.dtsi | 20 +- arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 20 + arch/arm/boot/dts/imx6qdl.dtsi | 29 +- arch/arm/configs/imx_v6_v7_defconfig | 17 +- arch/arm/mach-imx/clk-imx6q.c | 7 +- drivers/clk/clk-divider.c | 3 +- drivers/gpu/drm/bridge/Kconfig | 5 + drivers/gpu/drm/bridge/Makefile| 1 + drivers/gpu/drm/bridge/dw_mipi_dsi.c | 996 + drivers/gpu/drm/imx/Kconfig| 7 + drivers/gpu/drm/imx/Makefile | 1 + drivers/gpu/drm/imx/dw_mipi_dsi-imx.c | 230 + drivers/gpu/drm/panel/Kconfig | 5 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-himax-hx8369a.c| 614 + include/drm/bridge/dw_mipi_dsi.h | 27 + include/drm/drm_mipi_dsi.h | 14 + include/dt-bindings/clock/imx6qdl-clock.h | 4 +- include/linux/mfd/syscon/imx6q-iomuxc-gpr.h| 1 + 23 files changed, 2164 insertions(+), 30 deletions(-) create mode 100644 Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt create mode 100644
[PATCH RFC v7 07/21] ARM: imx6q: clk: Change hsi_tx clock to be a shared clock gate
The CG8 field of the CCM CCGR3 register is named as 'mipi_core_cfg'
clock, according to the i.MX6q/sdl reference manuals. This clock is
actually the gate for several clocks, including the hsi_tx_sel clock's
output and the video_27m clock's output. So, this patch changes the
hsi_tx clock to be a shared clock gate.
Suggested-by: Philipp Zabel
Signed-off-by: Liu Ying
---
v6->v7:
* None.
v5->v6:
* None.
v4->v5:
* None.
v3->v4:
* None.
v2->v3:
* Newly introduced in v3.
arch/arm/mach-imx/clk-imx6q.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index f19472a..080d5b7 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -119,6 +119,7 @@ static unsigned int share_count_asrc;
static unsigned int share_count_ssi1;
static unsigned int share_count_ssi2;
static unsigned int share_count_ssi3;
+static unsigned int share_count_mipi_core_cfg;
static void __init imx6q_clocks_init(struct device_node *ccm_node)
{
@@ -416,7 +417,7 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
clk[IMX6QDL_CLK_LDB_DI0] = imx_clk_gate2("ldb_di0",
"ldb_di0_podf", base + 0x74, 12);
clk[IMX6QDL_CLK_LDB_DI1] = imx_clk_gate2("ldb_di1",
"ldb_di1_podf", base + 0x74, 14);
clk[IMX6QDL_CLK_IPU2_DI1] = imx_clk_gate2("ipu2_di1",
"ipu2_di1_sel", base + 0x74, 10);
- clk[IMX6QDL_CLK_HSI_TX] = imx_clk_gate2("hsi_tx",
"hsi_tx_podf", base + 0x74, 16);
+ clk[IMX6QDL_CLK_HSI_TX] = imx_clk_gate2_shared("hsi_tx",
"hsi_tx_podf", base + 0x74, 16, _count_mipi_core_cfg);
if (cpu_is_imx6dl())
/*
* The multiplexer and divider of the imx6q clock gpu2d get
--
2.1.0
--
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 RFC v7 04/21] ARM: imx6q: Add GPR3 MIPI muxing control register field shift bits definition
This patch adds a macro to define the GPR3 MIPI muxing control register field shift bits. Signed-off-by: Liu Ying --- v6->v7: * None. v5->v6: * None. v4->v5: * None. v3->v4: * None. v2->v3: * None. v1->v2: * None. include/linux/mfd/syscon/imx6q-iomuxc-gpr.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h b/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h index ff44374..3b0bed4 100644 --- a/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h +++ b/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h @@ -207,6 +207,7 @@ #define IMX6Q_GPR3_LVDS0_MUX_CTL_IPU1_DI1 (0x1 << 6) #define IMX6Q_GPR3_LVDS0_MUX_CTL_IPU2_DI0 (0x2 << 6) #define IMX6Q_GPR3_LVDS0_MUX_CTL_IPU2_DI1 (0x3 << 6) +#define IMX6Q_GPR3_MIPI_MUX_CTL_SHIFT 4 #define IMX6Q_GPR3_MIPI_MUX_CTL_MASK (0x3 << 4) #define IMX6Q_GPR3_MIPI_MUX_CTL_IPU1_DI0 (0x0 << 4) #define IMX6Q_GPR3_MIPI_MUX_CTL_IPU1_DI1 (0x1 << 4) -- 2.1.0 -- 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 RFC v7 03/21] of: Add vendor prefix for Truly Semiconductors Limited
Signed-off-by: Liu Ying --- v6->v7: * None. v5->v6: * None. v4->v5: * None. v3->v4: * None. v2->v3: * None. v1->v2: * None. Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index f46adb2..0e67bad 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -158,6 +158,7 @@ tlm Trusted Logic Mobility toradexToradex AG toshibaToshiba Corporation toumaz Toumaz +truly Truly Semiconductors Limited usiUniversal Scientific Industrial Co., Ltd. v3 V3 Semiconductor variscite Variscite Ltd. -- 2.1.0 -- 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 RFC v7 08/21] ARM: imx6q: clk: Add support for mipi_core_cfg clock as a shared clock gate
The CG8 field of the CCM CCGR3 register is named as 'mipi_core_cfg' clock,
according to the i.MX6q/sdl reference manuals. This clock is actually the
gate for several clocks, including the hsi_tx_sel clock's output and the
video_27m clock's output. The MIPI DSI host controller embedded in the
i.MX6q/sdl SoCs uses the video_27m clock to generate PLL reference clock and
MIPI core configuration clock. In order to gate/ungate the two MIPI DSI
host controller relevant clocks, this patch adds the mipi_core_cfg clock as
a shared clock gate.
Suggested-by: Philipp Zabel
Signed-off-by: Liu Ying
---
v6->v7:
* None.
v5->v6:
* Add two spaces in the clock driver to eliminate two errors reported by
the checkpatch.pl script.
v4->v5:
* None.
v3->v4:
* None.
v2->v3:
* Newly introduced in v3.
arch/arm/mach-imx/clk-imx6q.c | 1 +
include/dt-bindings/clock/imx6qdl-clock.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 080d5b7..0f4d07c 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -418,6 +418,7 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
clk[IMX6QDL_CLK_LDB_DI1] = imx_clk_gate2("ldb_di1",
"ldb_di1_podf", base + 0x74, 14);
clk[IMX6QDL_CLK_IPU2_DI1] = imx_clk_gate2("ipu2_di1",
"ipu2_di1_sel", base + 0x74, 10);
clk[IMX6QDL_CLK_HSI_TX] = imx_clk_gate2_shared("hsi_tx",
"hsi_tx_podf", base + 0x74, 16, _count_mipi_core_cfg);
+ clk[IMX6QDL_CLK_MIPI_CORE_CFG] = imx_clk_gate2_shared("mipi_core_cfg",
"video_27m", base + 0x74, 16, _count_mipi_core_cfg);
if (cpu_is_imx6dl())
/*
* The multiplexer and divider of the imx6q clock gpu2d get
diff --git a/include/dt-bindings/clock/imx6qdl-clock.h
b/include/dt-bindings/clock/imx6qdl-clock.h
index 25625bf..dbc828c 100644
--- a/include/dt-bindings/clock/imx6qdl-clock.h
+++ b/include/dt-bindings/clock/imx6qdl-clock.h
@@ -249,6 +249,7 @@
#define IMX6QDL_PLL7_BYPASS236
#define IMX6QDL_CLK_GPT_3M 237
#define IMX6QDL_CLK_VIDEO_27M 238
-#define IMX6QDL_CLK_END239
+#define IMX6QDL_CLK_MIPI_CORE_CFG 239
+#define IMX6QDL_CLK_END240
#endif /* __DT_BINDINGS_CLOCK_IMX6QDL_H */
--
2.1.0
--
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 RFC v7 05/21] ARM: imx6q: clk: Add the video_27m clock
This patch supports the video_27m clock which is a fixed factor
clock of the pll3_pfd1_540m clock.
Signed-off-by: Liu Ying
---
v6->v7:
* None.
v5->v6:
* None.
v4->v5:
* None.
v3->v4:
* None.
v2->v3:
* None.
v1->v2:
* None.
arch/arm/mach-imx/clk-imx6q.c | 1 +
include/dt-bindings/clock/imx6qdl-clock.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 4e79da7..9470df3 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -246,6 +246,7 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
clk[IMX6QDL_CLK_PLL3_60M] = imx_clk_fixed_factor("pll3_60m",
"pll3_usb_otg", 1, 8);
clk[IMX6QDL_CLK_TWD] = imx_clk_fixed_factor("twd", "arm",
1, 2);
clk[IMX6QDL_CLK_GPT_3M]= imx_clk_fixed_factor("gpt_3m","osc",
1, 8);
+ clk[IMX6QDL_CLK_VIDEO_27M] = imx_clk_fixed_factor("video_27m",
"pll3_pfd1_540m", 1, 20);
if (cpu_is_imx6dl()) {
clk[IMX6QDL_CLK_GPU2D_AXI] = imx_clk_fixed_factor("gpu2d_axi",
"mmdc_ch0_axi_podf", 1, 1);
clk[IMX6QDL_CLK_GPU3D_AXI] = imx_clk_fixed_factor("gpu3d_axi",
"mmdc_ch0_axi_podf", 1, 1);
diff --git a/include/dt-bindings/clock/imx6qdl-clock.h
b/include/dt-bindings/clock/imx6qdl-clock.h
index b690cdb..25625bf 100644
--- a/include/dt-bindings/clock/imx6qdl-clock.h
+++ b/include/dt-bindings/clock/imx6qdl-clock.h
@@ -248,6 +248,7 @@
#define IMX6QDL_PLL6_BYPASS235
#define IMX6QDL_PLL7_BYPASS236
#define IMX6QDL_CLK_GPT_3M 237
-#define IMX6QDL_CLK_END238
+#define IMX6QDL_CLK_VIDEO_27M 238
+#define IMX6QDL_CLK_END239
#endif /* __DT_BINDINGS_CLOCK_IMX6QDL_H */
--
2.1.0
--
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 RFC v7 10/21] drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format
Signed-off-by: Liu Ying
---
v6->v7:
* None.
v5->v6:
* Address the over 80 characters in one line warning reported by the
checkpatch.pl script.
v4->v5:
* None.
v3->v4:
* None.
v2->v3:
* None.
v1->v2:
* Thierry Reding suggested that the mipi_dsi_pixel_format_to_bpp() function
could be placed at the common DRM MIPI DSI driver.
This patch is newly added.
include/drm/drm_mipi_dsi.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index f1d8d0d..3662021 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -163,6 +163,20 @@ static inline struct mipi_dsi_device
*to_mipi_dsi_device(struct device *dev)
return container_of(dev, struct mipi_dsi_device, dev);
}
+static inline int mipi_dsi_pixel_format_to_bpp(enum mipi_dsi_pixel_format fmt)
+{
+ switch (fmt) {
+ case MIPI_DSI_FMT_RGB888:
+ case MIPI_DSI_FMT_RGB666:
+ return 24;
+ case MIPI_DSI_FMT_RGB666_PACKED:
+ return 18;
+ case MIPI_DSI_FMT_RGB565:
+ return 16;
+ }
+ return -EINVAL;
+}
+
struct mipi_dsi_device *of_find_mipi_dsi_device_by_node(struct device_node
*np);
int mipi_dsi_attach(struct mipi_dsi_device *dsi);
int mipi_dsi_detach(struct mipi_dsi_device *dsi);
--
2.1.0
--
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 RFC v7 13/21] Documentation: dt-bindings: Add bindings for i.MX specific Synopsys DW MIPI DSI driver
This patch adds device tree bindings for i.MX specific Synopsys DW MIPI DSI
driver.
Signed-off-by: Liu Ying
---
v6->v7:
* None.
v5->v6:
* Add the #address-cells and #size-cells properties in the example 'ports'
node.
* Remove the useless pllref_gate clock from the required clocks, clock-names
property.
v4->v5:
* None.
v3->v4:
* Newly introduced in v4. This is separated from the relevant driver patch
in v3 to address Stefan Wahren's comment.
.../devicetree/bindings/drm/imx/mipi_dsi.txt | 78 ++
1 file changed, 78 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/imx/mipi_dsi.txt
diff --git a/Documentation/devicetree/bindings/drm/imx/mipi_dsi.txt
b/Documentation/devicetree/bindings/drm/imx/mipi_dsi.txt
new file mode 100644
index 000..75a7766
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/imx/mipi_dsi.txt
@@ -0,0 +1,78 @@
+i.MX specific Device-Tree bindings for Synopsys DesignWare MIPI DSI host
controller
+
+MIPI DSI host controller
+
+
+The MIPI DSI host controller is a Synopsys DesignWare IP.
+The common device tree documentation for this controller can be found
+at [1].
+
+Required properties:
+ - #address-cells: Should be <1>.
+ - #size-cells: Should be <0>.
+ - compatible: The compatible string should be "fsl,imx6q-mipi-dsi"
+ for i.MX6q/sdl SoCs.
+ - reg: Physical base address of the controller and length of memory
+ mapped region.
+ - interrupts: The controller's interrupt number to the CPU(s).
+ - gpr: Should be <>.
+ The phandle points to the iomuxc-gpr region containing the
+ multiplexer control register for the controller.
+ - clocks, clock-names: Phandles to the controller pllref and core_cfg clocks,
+ as described in [2] and [3].
+
+Required sub-nodes:
+ - ports: This node may contain up to four port nodes with endpoint
+ definitions as defined in [4], corresponding to the four inputs to
+ the controller multiplexer.
+ - A node to represent a DSI peripheral as described in [5].
+
+[1] Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt.
+[2] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[3] Documentation/devicetree/bindings/clock/imx6q-clock.txt
+[4] Documentation/devicetree/bindings/media/video-interfaces.txt
+[5] Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
+
+example:
+ gpr: iomuxc-gpr@020e {
+ /* ... */
+ };
+
+ mipi_dsi: mipi@021e {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,imx6q-mipi-dsi";
+ reg = <0x021e 0x4000>;
+ interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
+ gpr = <>;
+ clocks = < IMX6QDL_CLK_MIPI_CORE_CFG>,
+< IMX6QDL_CLK_MIPI_CORE_CFG>;
+ clock-names = "pllref", "core_cfg";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mipi_mux_0: endpoint {
+ remote-endpoint = <_di0_mipi>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mipi_mux_1: endpoint {
+ remote-endpoint = <_di1_mipi>;
+ };
+ };
+ };
+
+ panel {
+ compatible = "truly,tft480800-16-e-dsi";
+ reg = <0>;
+ /* ... */
+ };
+ };
--
2.1.0
--
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 RFC v7 14/21] drm: imx: Support Synopsys DesignWare MIPI DSI host controller
This patch adds support for Synopsys DesignWare MIPI DSI host controller
which is embedded in the i.MX6q/sdl SoCs.
Signed-off-by: Liu Ying
---
v6->v7:
* None.
v5->v6:
* Make the checkpatch.pl script be happier.
v4->v5:
* None.
v3->v4:
* Move the relevant dt-bindings to a separate patch to address Stefan
Wahren's comment.
v2->v3:
* To address Andy Yan's comments, move the common Synopsys DesignWare MIPI DSI
host controller logic into it's drm/bridge driver and leave the i.MX specific
logic only.
v1->v2:
* Address almost all comments from Thierry Reding and Russell.
* Update the DT documentation to remove the display-timings node in the panel
node.
* Update the DT documentation to state that the nodes which represent the
possible
DRM CRTCs the controller may connect with should be placed in the node
"ports".
* Remove the flag 'enabled' from the struct imx_mipi_dsi.
* Move the format_to_bpp() function in v1 to the common DRM MIPI DSI driver.
* Improve the way we wait for check status for DPHY and command packet
transfer.
* Improve the DPMS support for the encoder.
* Split the functions of ->host_attach() and ->mode_valid() clearly as
suggested by
Thierry Reding.
* Improve the logics in imx_mipi_dsi_dcs_long_write().
* Enable/disable the pllref_clk and pllref_gate_clk at the component
binding/unbinding
stages to help remove the flag 'enabled'.
* Update the module license to be "GPL".
* Other minor changes, such as coding style issues and macro naming issues.
drivers/gpu/drm/imx/Kconfig | 7 ++
drivers/gpu/drm/imx/Makefile | 1 +
drivers/gpu/drm/imx/dw_mipi_dsi-imx.c | 230 ++
3 files changed, 238 insertions(+)
create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx.c
diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
index 82fb758..c576f6b 100644
--- a/drivers/gpu/drm/imx/Kconfig
+++ b/drivers/gpu/drm/imx/Kconfig
@@ -51,3 +51,10 @@ config DRM_IMX_HDMI
depends on DRM_IMX
help
Choose this if you want to use HDMI on i.MX6.
+
+config DRM_IMX_MIPI_DSI
+ tristate "Freescale i.MX DRM MIPI DSI"
+ select DRM_DW_MIPI_DSI
+ depends on DRM_IMX
+ help
+ Choose this if you want to use MIPI DSI on i.MX6.
diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
index 582c438..f0dc278 100644
--- a/drivers/gpu/drm/imx/Makefile
+++ b/drivers/gpu/drm/imx/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
imx-ipuv3-crtc-objs := ipuv3-crtc.o ipuv3-plane.o
obj-$(CONFIG_DRM_IMX_IPUV3)+= imx-ipuv3-crtc.o
obj-$(CONFIG_DRM_IMX_HDMI) += imx-hdmi.o
+obj-$(CONFIG_DRM_IMX_MIPI_DSI) += dw_mipi_dsi-imx.o
diff --git a/drivers/gpu/drm/imx/dw_mipi_dsi-imx.c
b/drivers/gpu/drm/imx/dw_mipi_dsi-imx.c
new file mode 100644
index 000..b2c96e2
--- /dev/null
+++ b/drivers/gpu/drm/imx/dw_mipi_dsi-imx.c
@@ -0,0 +1,230 @@
+/*
+ * i.MX drm driver - MIPI DSI Host Controller
+ *
+ * Copyright (C) 2011-2014 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "imx-drm.h"
+
+#define DRIVER_NAME"imx-mipi-dsi"
+
+struct imx_mipi_dsi {
+ struct drm_encoder encoder;
+ struct device *dev;
+ struct regmap *regmap;
+};
+
+static inline struct imx_mipi_dsi *enc_to_dsi(struct drm_encoder *enc)
+{
+ return container_of(enc, struct imx_mipi_dsi, encoder);
+}
+
+static void imx_mipi_dsi_set_ipu_di_mux(struct imx_mipi_dsi *dsi, int ipu_di)
+{
+ regmap_update_bits(dsi->regmap, IOMUXC_GPR3,
+ IMX6Q_GPR3_MIPI_MUX_CTL_MASK,
+ ipu_di << IMX6Q_GPR3_MIPI_MUX_CTL_SHIFT);
+}
+
+static struct drm_encoder_funcs imx_mipi_dsi_encoder_funcs = {
+ .destroy = imx_drm_encoder_destroy,
+};
+
+static bool imx_mipi_dsi_encoder_mode_fixup(struct drm_encoder *encoder,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ return true;
+}
+
+static void imx_mipi_dsi_encoder_prepare(struct drm_encoder *encoder)
+{
+ u32 encoder_pix_fmt, interface_pix_fmt;
+
+ encoder_pix_fmt = dw_mipi_dsi_get_encoder_pixel_format(encoder);
+
+ switch (encoder_pix_fmt) {
+ case MIPI_DSI_FMT_RGB888:
+ interface_pix_fmt = V4L2_PIX_FMT_RGB24;
+
[PATCH RFC v7 16/21] drm: panel: Add support for Himax HX8369A MIPI DSI panel
This patch adds support for Himax HX8369A MIPI DSI panel.
Reviewed-by: Andrzej Hajda
Signed-off-by: Liu Ying
---
v6->v7:
* Address Andrzej Hajda's following comments.
* Simplify the return logic in hx8369a_dcs_write().
* Replace the macro hx8369a_dsi_init_helper() with a function array to improve
the code quality.
* Handle error cases during getting gpios in probe().
* Add 'Reviewed-by: Andrzej Hajda '.
v5->v6:
* Make the checkpatch.pl script be happier.
* Do not set the dsi channel number to be zero in probe(), because the MIPI DSI
bus driver would set it.
v4->v5:
* Address Andrzej Hajda's comments.
* Get the bs-gpios property instead of the bs[3:0]-gpios properties.
* Implement error propagation for panel register configurations.
* Other minor changes to improve the code quality.
v3->v4:
* Move the relevant dt-bindings to a separate patch to address Stefan
Wahren's comment.
v2->v3:
* Sort the included header files alphabetically.
v1->v2:
* Address almost all comments from Thierry Reding.
* Remove several DT properties as they can be implied by the compatible string.
* Add the HIMAX/himax prefixes to the driver's Kconfig name and driver name.
* Move the driver's Makefile entry place to sort the entries alphabetically.
* Reuse several standard DCS functions instead of inventing wheels.
* Move the panel resetting and power logics to the driver probe/remove stages.
This may simplify panel prepare/unprepare hooks. The power consumption should
not change a lot at DPMS since the panel enters sleep mode at that time.
* Add the module author.
* Other minor changes, such as coding style issues.
drivers/gpu/drm/panel/Kconfig | 5 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-himax-hx8369a.c | 614
3 files changed, 620 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-himax-hx8369a.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 024e98e..81b0bf0 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -16,6 +16,11 @@ config DRM_PANEL_SIMPLE
that it can be automatically turned off when the panel goes into a
low power state.
+config DRM_PANEL_HIMAX_HX8369A
+ tristate "Himax HX8369A panel"
+ depends on OF
+ select DRM_MIPI_DSI
+
config DRM_PANEL_LD9040
tristate "LD9040 RGB/SPI panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 4b2a043..d5dbe06 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_HIMAX_HX8369A) += panel-himax-hx8369a.o
obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
diff --git a/drivers/gpu/drm/panel/panel-himax-hx8369a.c
b/drivers/gpu/drm/panel/panel-himax-hx8369a.c
new file mode 100644
index 000..dd3b604
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-himax-hx8369a.c
@@ -0,0 +1,614 @@
+/*
+ * Himax HX8369A panel driver.
+ *
+ * Copyright (C) 2011-2014 Freescale Semiconductor, Inc.
+ *
+ * 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.
+ *
+ * This driver is based on Samsung s6e8aa0 panel driver.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define WRDISBV0x51
+#define WRCTRLD0x53
+#define WRCABC 0x55
+#define SETPOWER 0xb1
+#define SETDISP0xb2
+#define SETCYC 0xb4
+#define SETVCOM0xb6
+#define SETEXTC0xb9
+#define SETMIPI0xba
+#define SETPANEL 0xcc
+#define SETGIP 0xd5
+#define SETGAMMA 0xe0
+
+#define HX8369A_MIN_BRIGHTNESS 0x00
+#define HX8369A_MAX_BRIGHTNESS 0xff
+
+enum hx8369a_mpu_interface {
+ HX8369A_DBI_TYPE_A_8BIT,
+ HX8369A_DBI_TYPE_A_9BIT,
+ HX8369A_DBI_TYPE_A_16BIT,
+ HX8369A_DBI_TYPE_A_18BIT,
+ HX8369A_DBI_TYPE_B_8BIT,
+ HX8369A_DBI_TYPE_B_9BIT,
+ HX8369A_DBI_TYPE_B_16BIT,
+ HX8369A_DBI_TYPE_B_18BIT,
+ HX8369A_DSI_CMD_MODE,
+ HX8369A_DBI_TYPE_B_24BIT,
+ HX8369A_DSI_VIDEO_MODE,
+ HX8369A_MDDI,
+ HX8369A_DPI_DBI_TYPE_C_OPT1,
+ HX8369A_DPI_DBI_TYPE_C_OPT2,
+ HX8369A_DPI_DBI_TYPE_C_OPT3
+};
+
+enum hx8369a_resolution {
+ HX8369A_RES_480_864,
+ HX8369A_RES_480_854,
+ HX8369A_RES_480_800,
+ HX8369A_RES_480_640,
+ HX8369A_RES_360_640,
+ HX8369A_RES_480_720,
+};
+
+struct hx8369a_panel_desc {
+ const struct drm_display_mode *mode;
+
+ /* ms */
+ unsigned int
[PATCH RFC v7 21/21] ARM: imx_v6_v7_defconfig: Add support for Himax HX8369A panel
This patch adds support for Himax HX8369A panel. The new imx_v6_v7_defconfig is generated in this way: * make ARCH=arm imx_v6_v7_defconfig * make ARCH=arm menuconfig and manually choose to build in the Himax HX8369A panel driver * make ARCH=arm savedefconfig * cp defconfig arch/arm/configs/imx_v6_v7_defconfig Signed-off-by: Liu Ying --- v6->v7: * None. v5->v6: * None. v4->v5: * None. v3->v4: * None. v2->v3: * None. v1->v2: * Add the HIMAX prefix in the Kconfig name. arch/arm/configs/imx_v6_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig index 3e0e589..27db91b 100644 --- a/arch/arm/configs/imx_v6_v7_defconfig +++ b/arch/arm/configs/imx_v6_v7_defconfig @@ -192,6 +192,7 @@ CONFIG_SOC_CAMERA_OV2640=y CONFIG_IMX_IPUV3_CORE=y CONFIG_DRM=y CONFIG_DRM_PANEL_SIMPLE=y +CONFIG_DRM_PANEL_HIMAX_HX8369A=y CONFIG_DRM_IMX=y CONFIG_DRM_IMX_FB_HELPER=y CONFIG_DRM_IMX_PARALLEL_DISPLAY=y -- 2.1.0 -- 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 RFC v7 18/21] ARM: dts: imx6qdl-sabresd: Add support for TRULY TFT480800-16-E MIPI DSI panel
The TRULY TFT480800-16-E panel is driven by the Himax HX8369A driver IC.
The driver IC supports several display/control interface modes, including
the MIPI DSI video mode and command mode.
Signed-off-by: Liu Ying
---
v6->v7:
* None.
v5->v6:
* None.
v4->v5:
* Replace the bs[3:0]-gpios properties with the bs-gpios property.
This addresses Andrzej Hajda's comment.
v3->v4:
* None.
v2->v3:
* None.
v1->v2:
* To address Thierry Reding's comments, remove several unnecessary
properties as they can be implied by the compatible string.
* Fix the compatible string.
* Remove the display-timings node from the panel node as it can be
implied by the compatible string as well.
* Remove the status property as it is unneeded.
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index baf2f00..4e3a666 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -482,6 +482,13 @@
MX6QDL_PAD_SD4_DAT7__SD4_DATA7 0x17059
>;
};
+
+ pinctrl_mipi_panel: mipipanelgrp {
+ fsl,pins = <
+ MX6QDL_PAD_NANDF_CS0__GPIO6_IO11 0x1b0b0
+ MX6QDL_PAD_NANDF_CS1__GPIO6_IO14 0x1b0b0
+ >;
+ };
};
gpio_leds {
@@ -518,6 +525,19 @@
};
};
+_dsi {
+ status = "okay";
+
+ panel {
+ compatible = "truly,tft480800-16-e-dsi";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_mipi_panel>;
+ reset-gpios = < 11 GPIO_ACTIVE_LOW>;
+ bs-gpios = <0>, <0>, < 14 GPIO_ACTIVE_HIGH>, <0>;
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pcie>;
--
2.1.0
--
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 RFC v7 20/21] ARM: imx_v6_v7_defconfig: Add support for MIPI DSI host controller
This patch adds support for MIPI DSI host controller. The new imx_v6_v7_defconfig is generated in this way: * make ARCH=arm imx_v6_v7_defconfig * make ARCH=arm menuconfig and manually choose to build in the MIPI DSI host controller driver * make ARCH=arm savedefconfig * cp defconfig arch/arm/configs/imx_v6_v7_defconfig Signed-off-by: Liu Ying --- v6->v7: * None. v5->v6: * None. v4->v5: * None. v3->v4: * None. v2->v3: * None. v1->v2: * None. arch/arm/configs/imx_v6_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig index 0dbd0c3..3e0e589 100644 --- a/arch/arm/configs/imx_v6_v7_defconfig +++ b/arch/arm/configs/imx_v6_v7_defconfig @@ -199,6 +199,7 @@ CONFIG_DRM_IMX_TVE=y CONFIG_DRM_IMX_LDB=y CONFIG_DRM_IMX_IPUV3=y CONFIG_DRM_IMX_HDMI=y +CONFIG_DRM_IMX_MIPI_DSI=y CONFIG_LCD_CLASS_DEVICE=y CONFIG_LCD_L4F00242T03=y CONFIG_LCD_PLATFORM=y -- 2.1.0 -- 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 RFC v7 17/21] ARM: dtsi: imx6qdl: Add support for MIPI DSI host controller
This patch adds support for MIPI DSI host controller.
Signed-off-by: Liu Ying
---
v6->v7:
* None.
v5->v6:
* None.
v3->v4:
* None.
v2->v3:
* As suggested by Phillip Zabel, change the clocks and the clock-names
properties to use the pllref and core_cfg clocks only.
v1->v2:
* None.
arch/arm/boot/dts/imx6qdl.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 96bf2a0..7b1c313 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1006,7 +1006,13 @@
mipi_dsi: mipi@021e {
#address-cells = <1>;
#size-cells = <0>;
+ compatible = "fsl,imx6q-mipi-dsi";
reg = <0x021e 0x4000>;
+ interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
+ gpr = <>;
+ clocks = < IMX6QDL_CLK_MIPI_CORE_CFG>,
+< IMX6QDL_CLK_MIPI_CORE_CFG>;
+ clock-names = "pllref", "core_cfg";
status = "disabled";
ports {
--
2.1.0
--
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 RFC v7 19/21] ARM: imx_v6_v7_defconfig: Cleanup for imx drm being moved out of staging
The new imx_v6_v7_defconfig is generated in this way: * make ARCH=arm imx_v6_v7_defconfig * make ARCH=arm savedefconfig * cp defconfig arch/arm/configs/imx_v6_v7_defconfig Signed-off-by: Liu Ying --- v6->v7: * None. v5->v6: * None. v4->v5: * None. v3->v4: * None. v2->v3: * None. v1->v2: * None. arch/arm/configs/imx_v6_v7_defconfig | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig index 6790f1b..0dbd0c3 100644 --- a/arch/arm/configs/imx_v6_v7_defconfig +++ b/arch/arm/configs/imx_v6_v7_defconfig @@ -192,7 +192,13 @@ CONFIG_SOC_CAMERA_OV2640=y CONFIG_IMX_IPUV3_CORE=y CONFIG_DRM=y CONFIG_DRM_PANEL_SIMPLE=y -CONFIG_BACKLIGHT_LCD_SUPPORT=y +CONFIG_DRM_IMX=y +CONFIG_DRM_IMX_FB_HELPER=y +CONFIG_DRM_IMX_PARALLEL_DISPLAY=y +CONFIG_DRM_IMX_TVE=y +CONFIG_DRM_IMX_LDB=y +CONFIG_DRM_IMX_IPUV3=y +CONFIG_DRM_IMX_HDMI=y CONFIG_LCD_CLASS_DEVICE=y CONFIG_LCD_L4F00242T03=y CONFIG_LCD_PLATFORM=y @@ -249,13 +255,6 @@ CONFIG_IMX_SDMA=y CONFIG_MXS_DMA=y CONFIG_FSL_EDMA=y CONFIG_STAGING=y -CONFIG_DRM_IMX=y -CONFIG_DRM_IMX_FB_HELPER=y -CONFIG_DRM_IMX_PARALLEL_DISPLAY=y -CONFIG_DRM_IMX_TVE=y -CONFIG_DRM_IMX_LDB=y -CONFIG_DRM_IMX_IPUV3=y -CONFIG_DRM_IMX_HDMI=y # CONFIG_IOMMU_SUPPORT is not set CONFIG_PWM=y CONFIG_PWM_IMX=y -- 2.1.0 -- 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 RFC v7 12/21] drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver
This patch adds Synopsys DesignWare MIPI DSI host controller driver support. Currently, the driver supports the burst with sync pulses mode only. Signed-off-by: Liu Ying --- v6->v7: * None. v5->v6: * Make the checkpatch.pl script be happier. v4->v5: * Remove 'dsi->panel = NULL;' in dw_mipi_dsi_host_detach() to address Andrzej Hajda's comment. v3->v4: * Move the relevant dt-bindings to a separate patch to address Stefan Wahren's comment. v2->v3: * Newly introduced in v3 to address Andy Yan's comment. This is based on the i.MX MIPI DSI driver in v2. To make the Synopsys DesignWare MIPI DSI host controller driver less platform-dependant, this patch places it at the drm/bridge directory as a DRM bridge driver. drivers/gpu/drm/bridge/Kconfig | 5 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/dw_mipi_dsi.c | 996 +++ include/drm/bridge/dw_mipi_dsi.h | 27 + 4 files changed, 1029 insertions(+) create mode 100644 drivers/gpu/drm/bridge/dw_mipi_dsi.c create mode 100644 include/drm/bridge/dw_mipi_dsi.h diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 884923f..8180477 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -1,3 +1,8 @@ +config DRM_DW_MIPI_DSI + bool "Synopsys DesignWare MIPI DSI host controller bridge" + depends on DRM + select DRM_KMS_HELPER + config DRM_PTN3460 tristate "PTN3460 DP/LVDS bridge" depends on DRM diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index b4733e1..b326ad5 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -1,3 +1,4 @@ ccflags-y := -Iinclude/drm +obj-$(CONFIG_DRM_DW_MIPI_DSI) += dw_mipi_dsi.o obj-$(CONFIG_DRM_PTN3460) += ptn3460.o diff --git a/drivers/gpu/drm/bridge/dw_mipi_dsi.c b/drivers/gpu/drm/bridge/dw_mipi_dsi.c new file mode 100644 index 000..2b54d44 --- /dev/null +++ b/drivers/gpu/drm/bridge/dw_mipi_dsi.c @@ -0,0 +1,996 @@ +/* + * Synopsys DesignWare(DW) MIPI DSI Host Controller + * + * Copyright (C) 2011-2014 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#define DSI_VERSION0x00 + +#define DSI_PWR_UP 0x04 +#define RESET 0 +#define POWERUPBIT(0) + +#define DSI_CLKMGR_CFG 0x08 +#define TO_CLK_DIVIDSION(div) (((div) & 0xff) << 8) +#define TX_ESC_CLK_DIVIDSION(div) (((div) & 0xff) << 0) + +#define DSI_DPI_CFG0x0c +#define EN18_LOOSELY BIT(10) +#define COLORM_ACTIVE_LOW BIT(9) +#define SHUTD_ACTIVE_LOW BIT(8) +#define HSYNC_ACTIVE_LOW BIT(7) +#define VSYNC_ACTIVE_LOW BIT(6) +#define DATAEN_ACTIVE_LOW BIT(5) +#define DPI_COLOR_CODING_16BIT_1 (0x0 << 2) +#define DPI_COLOR_CODING_16BIT_2 (0x1 << 2) +#define DPI_COLOR_CODING_16BIT_3 (0x2 << 2) +#define DPI_COLOR_CODING_18BIT_1 (0x3 << 2) +#define DPI_COLOR_CODING_18BIT_2 (0x4 << 2) +#define DPI_COLOR_CODING_24BIT (0x5 << 2) +#define DPI_VID(vid) (((vid) & 0x3) << 0) + +#define DSI_DBI_CFG0x10 +#define DSI_DBIS_CMDSIZE 0x14 + +#define DSI_PCKHDL_CFG 0x18 +#define GEN_VID_RX(vid)(((vid) & 0x3) << 5) +#define EN_CRC_RX BIT(4) +#define EN_ECC_RX BIT(3) +#define EN_BTA BIT(2) +#define EN_EOTN_RX BIT(1) +#define EN_EOTP_TX BIT(0) + +#define DSI_VID_MODE_CFG 0x1c +#define FRAME_BTA_ACK BIT(11) +#define EN_NULL_PKTBIT(10) +#define EN_NULL_PKT_MASK BIT(10) +#define EN_MULTI_PKT BIT(9) +#define ENABLE_LOW_POWER (0x3f << 3) +#define ENABLE_LOW_POWER_MASK (0x3f << 3) +#define VID_MODE_TYPE_NONBURST_SYNC_PULSES (0x0 << 1) +#define VID_MODE_TYPE_NONBURST_SYNC_EVENTS (0x1 << 1) +#define VID_MODE_TYPE_BURST_SYNC_PULSES(0x3 << 1) +#define VID_MODE_TYPE_MASK (0x3 << 1) +#define ENABLE_VIDEO_MODE BIT(0) +#define DISABLE_VIDEO_MODE 0 +#define
[PATCH RFC v7 09/21] ARM: dts: imx6qdl: Move existing MIPI DSI ports into a new 'ports' node
The MIPI DSI node contains some ports which represent possible DRM CRTCs
it can connect with. Each port has a 'reg' property embedded. This
property will be wrongly interpretted by the MIPI DSI bus driver, because
the driver will take each subnode which contains a 'reg' property as a
DSI peripheral device. This patch moves the existing MIPI DSI ports into
a new 'ports' node so that the MIPI DSI bus driver may distinguish its
DSI peripheral device(s) from the existing ports.
Acked-by: Philipp Zabel
Signed-off-by: Liu Ying
---
v6->v7:
* None.
v5->v6:
* None.
v4->v5:
* None.
v3->v4:
* None.
v2->v3:
* Add Philipp's Ack.
v1->v2:
* Newly added, as suggested by Thierry Reding.
arch/arm/boot/dts/imx6q.dtsi | 20 +++-
arch/arm/boot/dts/imx6qdl.dtsi | 23 ++-
2 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index e9f3646..9c0990b 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -292,19 +292,21 @@
};
_dsi {
- port@2 {
- reg = <2>;
+ ports {
+ port@2 {
+ reg = <2>;
- mipi_mux_2: endpoint {
- remote-endpoint = <_di0_mipi>;
+ mipi_mux_2: endpoint {
+ remote-endpoint = <_di0_mipi>;
+ };
};
- };
- port@3 {
- reg = <3>;
+ port@3 {
+ reg = <3>;
- mipi_mux_3: endpoint {
- remote-endpoint = <_di1_mipi>;
+ mipi_mux_3: endpoint {
+ remote-endpoint = <_di1_mipi>;
+ };
};
};
};
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 9596ed5..96bf2a0 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1009,19 +1009,24 @@
reg = <0x021e 0x4000>;
status = "disabled";
- port@0 {
- reg = <0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
- mipi_mux_0: endpoint {
- remote-endpoint =
<_di0_mipi>;
+ mipi_mux_0: endpoint {
+ remote-endpoint =
<_di0_mipi>;
+ };
};
- };
- port@1 {
- reg = <1>;
+ port@1 {
+ reg = <1>;
- mipi_mux_1: endpoint {
- remote-endpoint =
<_di1_mipi>;
+ mipi_mux_1: endpoint {
+ remote-endpoint =
<_di1_mipi>;
+ };
};
};
};
--
2.1.0
--
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 RFC v7 11/21] Documentation: dt-bindings: Add bindings for Synopsys DW MIPI DSI DRM bridge driver
This patch adds device tree bindings for Synopsys DesignWare MIPI DSI
host controller DRM bridge driver.
Signed-off-by: Liu Ying
---
v6->v7:
* None.
v5->v6:
* Add the #address-cells and #size-cells properties in the example 'ports'
node.
* Remove the useless input-port properties from the example port@0 and port@1
nodes.
v4->v5:
* None.
v3->v4:
* Newly introduced in v4. This is separated from the relevant driver patch
in v3 to address Stefan Wahren's comment.
.../devicetree/bindings/drm/bridge/dw_mipi_dsi.txt | 73 ++
1 file changed, 73 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
b/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
new file mode 100644
index 000..f88a8d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
@@ -0,0 +1,73 @@
+Device-Tree bindings for Synopsys DesignWare MIPI DSI host controller
+
+The controller is a digital core that implements all protocol functions
+defined in the MIPI DSI specification, providing an interface between
+the system and the MIPI DPHY, and allowing communication with a MIPI DSI
+compliant display.
+
+Required properties:
+ - #address-cells: Should be <1>.
+ - #size-cells: Should be <0>.
+ - compatible: The compatible string should be "fsl,imx6q-mipi-dsi" for
+ i.MX6q/sdl SoCs. For other SoCs, please refer to their specific
+ device tree binding documentations.
+ - reg: Represent the physical address range of the controller.
+ - interrupts: Represent the controller's interrupt to the CPU(s).
+ - clocks, clock-names: Phandles to the controller pll reference and
+ core configuration clocks, as described in [1].
+
+For more required properties, please refer to relevant device tree binding
+documentations which describe the controller embedded in specific SoCs.
+
+Required sub-nodes:
+ - A node to represent a DSI peripheral as described in [2].
+
+For more required sub-nodes, please refer to relevant device tree binding
+documentations which describe the controller embedded in specific SoCs.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
+
+example:
+ gpr: iomuxc-gpr@020e {
+ /* ... */
+ };
+
+ mipi_dsi: mipi@021e {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,imx6q-mipi-dsi";
+ reg = <0x021e 0x4000>;
+ interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
+ gpr = <>;
+ clocks = < IMX6QDL_CLK_MIPI_CORE_CFG>,
+< IMX6QDL_CLK_MIPI_CORE_CFG>;
+ clock-names = "pllref", "core_cfg";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mipi_mux_0: endpoint {
+ remote-endpoint = <_di0_mipi>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mipi_mux_1: endpoint {
+ remote-endpoint = <_di1_mipi>;
+ };
+ };
+ };
+
+ panel {
+ compatible = "truly,tft480800-16-e-dsi";
+ reg = <0>;
+ /* ... */
+ };
+ };
--
2.1.0
--
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 RFC v7 15/21] Documentation: dt-bindings: Add bindings for Himax HX8369A DRM panel driver
This patch adds device tree bindings for Himax HX8369A DRM panel driver.
Signed-off-by: Liu Ying
---
v6->v7:
* None.
v5->v6:
* None.
v4->v5:
* Merge the bs[3:0]-gpios properties into one property - bs-gpios.
This addresses Andrzej Hajda's comment.
v3->v4:
* Newly introduced in v4. This is separated from the relevant driver patch
in v3 to address Stefan Wahren's comment.
.../devicetree/bindings/panel/himax,hx8369a.txt| 39 ++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/panel/himax,hx8369a.txt
diff --git a/Documentation/devicetree/bindings/panel/himax,hx8369a.txt
b/Documentation/devicetree/bindings/panel/himax,hx8369a.txt
new file mode 100644
index 000..3a44b70
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/himax,hx8369a.txt
@@ -0,0 +1,39 @@
+Himax HX8369A WVGA 16.7M color TFT single chip driver with internal GRAM
+
+Himax HX8369A is a WVGA resolution driving controller.
+It is designed to provide a single chip solution that combines a source
+driver and power supply circuits to drive a TFT dot matrix LCD with
+480RGBx864 dots at the maximum.
+
+The HX8369A supports several interface modes, including MPU MIPI DBI Type
+A/B mode, MIPI DPI/DBI Type C mode, MIPI DSI video mode, MIPI DSI command
+mode and MDDI mode. The interface mode is selected by the external hardware
+pins BS[3:0].
+
+Currently, only the MIPI DSI video mode is supported.
+
+Required properties:
+ - compatible: should be a panel's compatible string
+ - reg: the virtual channel number of a DSI peripheral, as described in [1]
+ - reset-gpios: a GPIO spec for the reset pin, as described in [2]
+
+Optional properties:
+ - vdd1-supply: I/O and interface power supply
+ - vdd2-supply: analog power supply
+ - vdd3-supply: logic power supply
+ - dsi-vcc-supply: DSI and MDDI power supply
+ - vpp-supply: OTP programming voltage
+ - bs-gpios: a GPIO spec for the pins BS[3:0], as described in [2]
+
+[1] Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
+[2] Documentation/devicetree/bindings/gpio/gpio.txt
+
+Example:
+ panel {
+ compatible = "truly,tft480800-16-e-dsi";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_mipi_panel>;
+ reset-gpios = < 11 GPIO_ACTIVE_LOW>;
+ bs-gpios = <0>, <0>, < 14 GPIO_ACTIVE_HIGH>, <0>;
+ };
--
2.1.0
--
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 RFC v7 01/21] clk: divider: Correct parent clk round rate if no bestdiv is normally found
If no best divider is normally found, we will try to use the maximum divider.
We should not set the parent clock rate to be 1Hz by force for being rounded.
Instead, we should take the maximum divider as a base and calculate a correct
parent clock rate for being rounded.
Signed-off-by: Liu Ying
---
v6->v7:
* None.
v5->v6:
* None.
v4->v5:
* None.
v3->v4:
* None.
v2->v3:
* None.
v1->v2:
* None.
drivers/clk/clk-divider.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index c0a842b..f641d4b 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -311,7 +311,8 @@ static int clk_divider_bestdiv(struct clk_hw *hw, unsigned
long rate,
if (!bestdiv) {
bestdiv = _get_maxdiv(divider);
- *best_parent_rate = __clk_round_rate(__clk_get_parent(hw->clk),
1);
+ *best_parent_rate = __clk_round_rate(__clk_get_parent(hw->clk),
+ MULT_ROUND_UP(rate, bestdiv));
}
return bestdiv;
--
2.1.0
--
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: [Linux-ima-user] Initramfs and IMA Appraisal
On Mon, 2014-12-29 at 19:55 -0600, Rob Landley wrote:
>
> On 12/29/2014 03:46 PM, Mimi Zohar wrote:
> > On Mon, 2014-12-29 at 14:34 -0600, Rob Landley wrote:
> >> On 12/29/2014 07:45 AM, Mimi Zohar wrote:
> >>> On Thu, 2014-11-27 at 10:15 +0100, Christophe Fillot wrote:
> >
> > Are you using an initrd not an initramfs? According to
> > Documentation/filesystems/ramfs-rootfs-initramfs.txt, "If
> CONFIG_TMPFS
> > is enabled, rootfs will use tmpfs instead of ramfs by default".
> >
> Yes, that what I thought too, but it seems that it is not really the
> case because of this test:
>
> if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
> (!root_fs_names || strstr(root_fs_names, "tmpfs"))) {
> err = shmem_init();
> is_tmpfs = true;
> } else {
> err = init_ramfs_fs();
> }
> >>>
> >>> [CC'ing Rob Landley, lsm, lkml]
> >>>
> >>> Thanks! "saved_root_name" is set to the boot command line "root="
> >>> option, which in my case is the UUID. I'm not sure why real root should
> >>> impact the initramfs tmpfs/ramfs decision.
> >>>
> >>> Unless there is a good explanation, did you want to post a patch to
> >>> remove the test?
> >>
> >> I added support last year, here's the start of the patch series:
> >>
> >> https://lkml.org/lkml/2013/6/29/101
> >>
> >> The logic is that if you specify a fallback root via root=, then you're
> >> not staying on rootfs (that's what root= _means_, "here is the root
> >> filesystem the kernel is to mount over rootfs"), and thus the extra
> >> infrastructure for tmpfs instead of ramfs is unnecessary.
> >
> > Thanks Rob for the explanation. The problem is that ramfs does not
> > support extended attributes, while tmpfs does.
>
> If you're _using_ initramfs/initmpfs, there's no reason to specify a root=.
The menu entry looks like:
linux /vmlinuz-3.17.0+ root=UUID=94595ff7-0fd4-4ea3-99f2-f7ddf8fbc91f
ro ...
initrd /initramfs-3.17.0+.img
Because "root=" is specified, rootfs is not using tmpfs.
> > The boot loader could
> > "measure" (trusted boot) the initramfs, but as the initramfs is
> > generated on the target system, the initramfs is not signed, preventing
> > it from being appraised (secure Boot). To close the initramfs integrity
> > appraisal gap requires verifying the individual initramfs file
> > signatures, which are stored as extended attributes.
>
> Faced with the phrases "trusted boot" and "integrity appraisal", I plead
> the third.
Fine. Bottom line, rootfs needs to support extended attributes.
> (In the wake of the Snowden infodump,
All the more reason to allow only those files that are properly signed
to be read/executed.
Mimi
--
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: [Nouveau] [PATCH nouveau 09/11] drm: export some variable and functions to resue the PM functions
Hi Emil,
On 12/30/2014 10:34 AM, Emil Velikov wrote:
On 23/12/14 10:40, Vince Hsu wrote:
This patch adds some checks in the suspend/resume functions to distinguish
the dGPU and mobile GPU and exports some variables/functions so that the
nouveau platform device can reuse them.
Hi Vince,
Afaiu one needs to export a symbol as it's used by another module or
subsystem. With the follow up two patches you are not doing either one,
so I'd assume that you can just omit the EXPORT_* changes.
The nouveau platform device driver is built as another module -
nouveau_platform.ko. :)
Thanks,
Vince
I could be wrong though :-)
Cheers
Emil
Signed-off-by: Vince Hsu
---
drm/nouveau_drm.c | 16 +++-
drm/nouveau_drm.h | 2 ++
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drm/nouveau_drm.c b/drm/nouveau_drm.c
index afb93bb72f97..0ed99ef80211 100644
--- a/drm/nouveau_drm.c
+++ b/drm/nouveau_drm.c
@@ -72,6 +72,7 @@ module_param_named(modeset, nouveau_modeset, int, 0400);
MODULE_PARM_DESC(runpm, "disable (0), force enable (1), optimus only default (-1)");
int nouveau_runtime_pm = -1;
+EXPORT_SYMBOL(nouveau_runtime_pm);
module_param_named(runpm, nouveau_runtime_pm, int, 0400);
static struct drm_driver driver_stub;
@@ -543,7 +544,7 @@ nouveau_drm_remove(struct pci_dev *pdev)
nouveau_drm_device_remove(dev);
}
-static int
+int
nouveau_do_suspend(struct drm_device *dev, bool runtime)
{
struct nouveau_drm *drm = nouveau_drm(dev);
@@ -559,8 +560,10 @@ nouveau_do_suspend(struct drm_device *dev, bool runtime)
return ret;
}
- NV_INFO(drm, "evicting buffers...\n");
- ttm_bo_evict_mm(>ttm.bdev, TTM_PL_VRAM);
+ if (dev->pdev) {
+ NV_INFO(drm, "evicting buffers...\n");
+ ttm_bo_evict_mm(>ttm.bdev, TTM_PL_VRAM);
+ }
NV_INFO(drm, "waiting for kernel channels to go idle...\n");
if (drm->cechan) {
@@ -612,8 +615,9 @@ fail_display:
}
return ret;
}
+EXPORT_SYMBOL(nouveau_do_suspend);
-static int
+int
nouveau_do_resume(struct drm_device *dev, bool runtime)
{
struct nouveau_drm *drm = nouveau_drm(dev);
@@ -635,7 +639,8 @@ nouveau_do_resume(struct drm_device *dev, bool runtime)
nvif_client_resume(>base);
}
- nouveau_run_vbios_init(dev);
+ if (dev->pdev)
+ nouveau_run_vbios_init(dev);
if (dev->mode_config.num_crtc) {
NV_INFO(drm, "resuming display...\n");
@@ -646,6 +651,7 @@ nouveau_do_resume(struct drm_device *dev, bool runtime)
return 0;
}
+EXPORT_SYMBOL(nouveau_do_resume);
int
nouveau_pmops_suspend(struct device *dev)
diff --git a/drm/nouveau_drm.h b/drm/nouveau_drm.h
index 8ae36f265fb8..897d295dd1e3 100644
--- a/drm/nouveau_drm.h
+++ b/drm/nouveau_drm.h
@@ -177,6 +177,8 @@ nouveau_drm(struct drm_device *dev)
int nouveau_pmops_suspend(struct device *);
int nouveau_pmops_resume(struct device *);
+int nouveau_do_suspend(struct drm_device *dev, bool runtime);
+int nouveau_do_resume(struct drm_device *dev, bool runtime);
#define nouveau_platform_device_create(p, u) \
nouveau_platform_device_create_(p, sizeof(**u), (void **)u)
--
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 2/2] regulator: rk808: add dvs support
On 12/30/2014 01:25 AM, Mark Brown wrote: On Mon, Dec 15, 2014 at 11:07:58AM +0800, Chris Zhong wrote: + sel <<= ffs(rdev->desc->vsel_mask) - 1; + sel |= old_sel & ~rdev->desc->vsel_mask; + + ret = regmap_write(rdev->regmap, reg, sel); + if (ret) + return ret; + + gpiod_set_value(gpio, !gpio_level); So, this seems a bit odd. What we appear to be doing here is alternating between the two different voltage setting registers which is all well and good but makes me wonder why we're bothering - it's a bit more work than just sticking with one. We do get... you mean check the old_selector and selector? I think _regulator_do_set_voltage have done it. + /* +* dvsok pin would be pull down when dvs1/2 pin changed, and +* it would be pull up once the voltage regulate complete. +* No need to wait dvsok signal when voltage falling. +*/ ...this but unless the voltage typically ramps much faster than spec it's never clear to me that we're actually winning by polling the pin instead of just dead reckoning the time, it's more work for the CPU to poll the GPIO than to sleep after all. Actually, it's slower than spec, so I think getting this dvsok pin state is safer than delay. One thing we can do with hardware like this is to program in a voltage we're likely to want to switch to quickly and then use the GPIO to get there. That can be a bit hard to arrange with the regulator API as it currently stands since we don't exactly have an interface for it. We can just check to see what the two values are current set to before switching and skip the register write if it's the same (making things faster since we're typically avoiding an I2C or SPI transaction by doing that) but that's a bit meh. We can also try to do things like keep the top voltage from the voltage ranges we're being given programmed which for DVS typically ends up doing a reasonable job since governors often like to jump straight to top speed when things get busy so that's one of the common cases where we most want to change voltages as quickly as possible. -- 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: [Linux-ima-user] Initramfs and IMA Appraisal
On Mon, 2014-12-29 at 18:25 -0800, David Lang wrote: > On Mon, 29 Dec 2014, Mimi Zohar wrote: > > > Thanks Rob for the explanation. The problem is that ramfs does not > > support extended attributes, while tmpfs does. The boot loader could > > "measure" (trusted boot) the initramfs, but as the initramfs is > > generated on the target system, the initramfs is not signed, preventing > > it from being appraised (secure Boot). To close the initramfs integrity > > appraisal gap requires verifying the individual initramfs file > > signatures, which are stored as extended attributes. > > what's the point of checking the files on the filesystem against signatures > stored on the same filesystem? If someone could alter the file contents they > can > alter the signatures as well. It's all about limiting which public keys can be used to verify the file signatures. As of 3.17, only keys signed by a "trusted" key on the system keyring may be added to the IMA keyring. Mimi -- 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: Bisected regression from 3.17 still present in 3.19-rc1
On Sun, 2014-12-28 at 18:54 +, Carlos R. Mafra wrote:
> The laptop is a 2-year-old macbook Pro with retina display.
>
> I use a dockapp called wmlaptop2 (http://repo.or.cz/w/wmlaptop2.git)
> which, among other things, displays battery information (% of charge
> remaining etc).
>
> With the kernel v3.17 the battery information stopped working and it
> still does not work in the latest v3.19-rc1.
What is CONFIG_ACPI_SBS set to?
--
Matthew Garrett
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [alsa-devel][PATCH v4] ASoC: wm8960: Let wm8960 codec driver manage its own MCLK
On Mon, Dec 29, 2014 at 04:05:14PM +, Mark Brown wrote: > On Mon, Dec 29, 2014 at 10:59:08AM +, Zidan Wang wrote: > > Hi Mark, > > Don't top post and please fix your mailer to word wrap within paragraphs > and avoid corrupting the mail it's quoting. > > > You are right. When PM is disabled, the codec will not work. But there are > > also some codecs enable mclk in PM, such as wm8962, cs42xx8. > > And some codecs enable codec mclk in i2c probe(), startup() and > > set_bias_level(). It makes me confused. > > Can you tell me what's the general idiom to enable mclk. Thanks. > > Like I said in the mail to which you replied: > > > > This isn't going to work if PM is disabled (which is still a valid > > > configuration). The general idiom for this is that the driver should > > > start up with everything powered up then let runtime idle turn things off > > > if they're not required. That way if runtime PM is disabled then the > > > system will still work as everything will just stay powered on all the > > > time. I want put mclk enable to set_bias_level. Do you thinks it make sense? -- 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] SCSI:STORVSC Use SCSI layer to allocate memory for per-command device request data
STORVSC uses its own momory pool to manage device request data. However, SCSI
layer already has a mechanisim for allocating additional memory for each
command issued to device driver. This patch removes the memory pool in STORVSC
and makes it use SCSI layer to allocate memory for device request data.
Reviewed-by: Long Li
Signed-off-by: Christoph Hellwig
---
drivers/scsi/storvsc_drv.c | 119 +++--
1 file changed, 8 insertions(+), 111 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 4cff0dd..14ee98e 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -32,7 +32,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -309,14 +308,6 @@ enum storvsc_request_type {
* This is the end of Protocol specific defines.
*/
-
-/*
- * We setup a mempool to allocate request structures for this driver
- * on a per-lun basis. The following define specifies the number of
- * elements in the pool.
- */
-
-#define STORVSC_MIN_BUF_NR 64
static int storvsc_ringbuffer_size = (20 * PAGE_SIZE);
module_param(storvsc_ringbuffer_size, int, S_IRUGO);
@@ -346,7 +337,6 @@ static void storvsc_on_channel_callback(void *context);
#define STORVSC_IDE_MAX_CHANNELS 1
struct storvsc_cmd_request {
- struct list_head entry;
struct scsi_cmnd *cmd;
unsigned int bounce_sgl_count;
@@ -357,7 +347,6 @@ struct storvsc_cmd_request {
/* Synchronize the request/response if needed */
struct completion wait_event;
- unsigned char *sense_buffer;
struct hv_multipage_buffer data_buffer;
struct vstor_packet vstor_packet;
};
@@ -389,11 +378,6 @@ struct storvsc_device {
struct storvsc_cmd_request reset_request;
};
-struct stor_mem_pools {
- struct kmem_cache *request_pool;
- mempool_t *request_mempool;
-};
-
struct hv_host_device {
struct hv_device *dev;
unsigned int port;
@@ -1070,10 +1054,8 @@ static void storvsc_command_completion(struct
storvsc_cmd_request *cmd_request)
{
struct scsi_cmnd *scmnd = cmd_request->cmd;
struct hv_host_device *host_dev = shost_priv(scmnd->device->host);
- void (*scsi_done_fn)(struct scsi_cmnd *);
struct scsi_sense_hdr sense_hdr;
struct vmscsi_request *vm_srb;
- struct stor_mem_pools *memp = scmnd->device->hostdata;
struct Scsi_Host *host;
struct storvsc_device *stor_dev;
struct hv_device *dev = host_dev->dev;
@@ -1109,14 +1091,7 @@ static void storvsc_command_completion(struct
storvsc_cmd_request *cmd_request)
cmd_request->data_buffer.len -
vm_srb->data_transfer_length);
- scsi_done_fn = scmnd->scsi_done;
-
- scmnd->host_scribble = NULL;
- scmnd->scsi_done = NULL;
-
- scsi_done_fn(scmnd);
-
- mempool_free(cmd_request, memp->request_mempool);
+ scmnd->scsi_done(scmnd);
}
static void storvsc_on_io_completion(struct hv_device *device,
@@ -1160,7 +1135,7 @@ static void storvsc_on_io_completion(struct hv_device
*device,
SRB_STATUS_AUTOSENSE_VALID) {
/* autosense data available */
- memcpy(request->sense_buffer,
+ memcpy(request->cmd->sense_buffer,
vstor_packet->vm_srb.sense_data,
vstor_packet->vm_srb.sense_info_length);
@@ -1378,55 +1353,6 @@ static int storvsc_do_io(struct hv_device *device,
return ret;
}
-static int storvsc_device_alloc(struct scsi_device *sdevice)
-{
- struct stor_mem_pools *memp;
- int number = STORVSC_MIN_BUF_NR;
-
- memp = kzalloc(sizeof(struct stor_mem_pools), GFP_KERNEL);
- if (!memp)
- return -ENOMEM;
-
- memp->request_pool =
- kmem_cache_create(dev_name(>sdev_dev),
- sizeof(struct storvsc_cmd_request), 0,
- SLAB_HWCACHE_ALIGN, NULL);
-
- if (!memp->request_pool)
- goto err0;
-
- memp->request_mempool = mempool_create(number, mempool_alloc_slab,
- mempool_free_slab,
- memp->request_pool);
-
- if (!memp->request_mempool)
- goto err1;
-
- sdevice->hostdata = memp;
-
- return 0;
-
-err1:
- kmem_cache_destroy(memp->request_pool);
-
-err0:
- kfree(memp);
- return -ENOMEM;
-}
-
-static void storvsc_device_destroy(struct scsi_device *sdevice)
-{
- struct stor_mem_pools *memp = sdevice->hostdata;
-
- if (!memp)
- return;
-
- mempool_destroy(memp->request_mempool);
- kmem_cache_destroy(memp->request_pool);
- kfree(memp);
- sdevice->hostdata = NULL;
-}
-
static int
Re: [Nouveau] [PATCH nouveau 09/11] drm: export some variable and functions to resue the PM functions
On 23/12/14 10:40, Vince Hsu wrote:
> This patch adds some checks in the suspend/resume functions to distinguish
> the dGPU and mobile GPU and exports some variables/functions so that the
> nouveau platform device can reuse them.
>
Hi Vince,
Afaiu one needs to export a symbol as it's used by another module or
subsystem. With the follow up two patches you are not doing either one,
so I'd assume that you can just omit the EXPORT_* changes.
I could be wrong though :-)
Cheers
Emil
> Signed-off-by: Vince Hsu
> ---
> drm/nouveau_drm.c | 16 +++-
> drm/nouveau_drm.h | 2 ++
> 2 files changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drm/nouveau_drm.c b/drm/nouveau_drm.c
> index afb93bb72f97..0ed99ef80211 100644
> --- a/drm/nouveau_drm.c
> +++ b/drm/nouveau_drm.c
> @@ -72,6 +72,7 @@ module_param_named(modeset, nouveau_modeset, int, 0400);
>
> MODULE_PARM_DESC(runpm, "disable (0), force enable (1), optimus only default
> (-1)");
> int nouveau_runtime_pm = -1;
> +EXPORT_SYMBOL(nouveau_runtime_pm);
> module_param_named(runpm, nouveau_runtime_pm, int, 0400);
>
> static struct drm_driver driver_stub;
> @@ -543,7 +544,7 @@ nouveau_drm_remove(struct pci_dev *pdev)
> nouveau_drm_device_remove(dev);
> }
>
> -static int
> +int
> nouveau_do_suspend(struct drm_device *dev, bool runtime)
> {
> struct nouveau_drm *drm = nouveau_drm(dev);
> @@ -559,8 +560,10 @@ nouveau_do_suspend(struct drm_device *dev, bool runtime)
> return ret;
> }
>
> - NV_INFO(drm, "evicting buffers...\n");
> - ttm_bo_evict_mm(>ttm.bdev, TTM_PL_VRAM);
> + if (dev->pdev) {
> + NV_INFO(drm, "evicting buffers...\n");
> + ttm_bo_evict_mm(>ttm.bdev, TTM_PL_VRAM);
> + }
>
> NV_INFO(drm, "waiting for kernel channels to go idle...\n");
> if (drm->cechan) {
> @@ -612,8 +615,9 @@ fail_display:
> }
> return ret;
> }
> +EXPORT_SYMBOL(nouveau_do_suspend);
>
> -static int
> +int
> nouveau_do_resume(struct drm_device *dev, bool runtime)
> {
> struct nouveau_drm *drm = nouveau_drm(dev);
> @@ -635,7 +639,8 @@ nouveau_do_resume(struct drm_device *dev, bool runtime)
> nvif_client_resume(>base);
> }
>
> - nouveau_run_vbios_init(dev);
> + if (dev->pdev)
> + nouveau_run_vbios_init(dev);
>
> if (dev->mode_config.num_crtc) {
> NV_INFO(drm, "resuming display...\n");
> @@ -646,6 +651,7 @@ nouveau_do_resume(struct drm_device *dev, bool runtime)
>
> return 0;
> }
> +EXPORT_SYMBOL(nouveau_do_resume);
>
> int
> nouveau_pmops_suspend(struct device *dev)
> diff --git a/drm/nouveau_drm.h b/drm/nouveau_drm.h
> index 8ae36f265fb8..897d295dd1e3 100644
> --- a/drm/nouveau_drm.h
> +++ b/drm/nouveau_drm.h
> @@ -177,6 +177,8 @@ nouveau_drm(struct drm_device *dev)
>
> int nouveau_pmops_suspend(struct device *);
> int nouveau_pmops_resume(struct device *);
> +int nouveau_do_suspend(struct drm_device *dev, bool runtime);
> +int nouveau_do_resume(struct drm_device *dev, bool runtime);
>
> #define nouveau_platform_device_create(p, u)
> \
> nouveau_platform_device_create_(p, sizeof(**u), (void **)u)
>
--
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 RFC v6 16/21] drm: panel: Add support for Himax HX8369A MIPI DSI panel
On 12/29/2014 06:50 PM, Andrzej Hajda wrote:
On 12/29/2014 11:07 AM, Liu Ying wrote:
On 12/29/2014 05:09 PM, Andrzej Hajda wrote:
On 12/29/2014 07:39 AM, Liu Ying wrote:
This patch adds support for Himax HX8369A MIPI DSI panel.
Signed-off-by: Liu Ying
---
v5->v6:
* Make the checkpatch.pl script be happier.
* Do not set the dsi channel number to be zero in probe(), because the MIPI
DSI
bus driver would set it.
v4->v5:
* Address Andrzej Hajda's comments.
* Get the bs-gpios property instead of the bs[3:0]-gpios properties.
* Implement error propagation for panel register configurations.
* Other minor changes to improve the code quality.
v3->v4:
* Move the relevant dt-bindings to a separate patch to address Stefan
Wahren's comment.
v2->v3:
* Sort the included header files alphabetically.
v1->v2:
* Address almost all comments from Thierry Reding.
* Remove several DT properties as they can be implied by the compatible
string.
* Add the HIMAX/himax prefixes to the driver's Kconfig name and driver name.
* Move the driver's Makefile entry place to sort the entries alphabetically.
* Reuse several standard DCS functions instead of inventing wheels.
* Move the panel resetting and power logics to the driver probe/remove
stages.
This may simplify panel prepare/unprepare hooks. The power consumption
should
not change a lot at DPMS since the panel enters sleep mode at that time.
* Add the module author.
* Other minor changes, such as coding style issues.
drivers/gpu/drm/panel/Kconfig | 5 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-himax-hx8369a.c | 614
3 files changed, 620 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-himax-hx8369a.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 024e98e..81b0bf0 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -16,6 +16,11 @@ config DRM_PANEL_SIMPLE
that it can be automatically turned off when the panel goes into a
low power state.
+config DRM_PANEL_HIMAX_HX8369A
+ tristate "Himax HX8369A panel"
+ depends on OF
+ select DRM_MIPI_DSI
+
config DRM_PANEL_LD9040
tristate "LD9040 RGB/SPI panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 4b2a043..d5dbe06 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_HIMAX_HX8369A) += panel-himax-hx8369a.o
obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
diff --git a/drivers/gpu/drm/panel/panel-himax-hx8369a.c
b/drivers/gpu/drm/panel/panel-himax-hx8369a.c
new file mode 100644
index 000..eee36a7
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-himax-hx8369a.c
@@ -0,0 +1,614 @@
+/*
+ * Himax HX8369A panel driver.
+ *
+ * Copyright (C) 2011-2014 Freescale Semiconductor, Inc.
+ *
+ * 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.
+ *
+ * This driver is based on Samsung s6e8aa0 panel driver.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define WRDISBV0x51
+#define WRCTRLD0x53
+#define WRCABC 0x55
+#define SETPOWER 0xb1
+#define SETDISP0xb2
+#define SETCYC 0xb4
+#define SETVCOM0xb6
+#define SETEXTC0xb9
+#define SETMIPI0xba
+#define SETPANEL 0xcc
+#define SETGIP 0xd5
+#define SETGAMMA 0xe0
+
+#define HX8369A_MIN_BRIGHTNESS 0x00
+#define HX8369A_MAX_BRIGHTNESS 0xff
+
+enum hx8369a_mpu_interface {
+ HX8369A_DBI_TYPE_A_8BIT,
+ HX8369A_DBI_TYPE_A_9BIT,
+ HX8369A_DBI_TYPE_A_16BIT,
+ HX8369A_DBI_TYPE_A_18BIT,
+ HX8369A_DBI_TYPE_B_8BIT,
+ HX8369A_DBI_TYPE_B_9BIT,
+ HX8369A_DBI_TYPE_B_16BIT,
+ HX8369A_DBI_TYPE_B_18BIT,
+ HX8369A_DSI_CMD_MODE,
+ HX8369A_DBI_TYPE_B_24BIT,
+ HX8369A_DSI_VIDEO_MODE,
+ HX8369A_MDDI,
+ HX8369A_DPI_DBI_TYPE_C_OPT1,
+ HX8369A_DPI_DBI_TYPE_C_OPT2,
+ HX8369A_DPI_DBI_TYPE_C_OPT3
+};
+
+enum hx8369a_resolution {
+ HX8369A_RES_480_864,
+ HX8369A_RES_480_854,
+ HX8369A_RES_480_800,
+ HX8369A_RES_480_640,
+ HX8369A_RES_360_640,
+ HX8369A_RES_480_720,
+};
+
+struct hx8369a_panel_desc {
+ const struct drm_display_mode *mode;
+
+ /* ms */
+ unsigned int power_on_delay;
+ unsigned int reset_delay;
+
+ unsigned int dsi_lanes;
+};
+
Re: [Linux-ima-user] Initramfs and IMA Appraisal
On Mon, 29 Dec 2014, Mimi Zohar wrote: Thanks Rob for the explanation. The problem is that ramfs does not support extended attributes, while tmpfs does. The boot loader could "measure" (trusted boot) the initramfs, but as the initramfs is generated on the target system, the initramfs is not signed, preventing it from being appraised (secure Boot). To close the initramfs integrity appraisal gap requires verifying the individual initramfs file signatures, which are stored as extended attributes. what's the point of checking the files on the filesystem against signatures stored on the same filesystem? If someone could alter the file contents they can alter the signatures as well. David Lang -- 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/3] cma: add functions to get region pages counters
On Fri, Dec 26, 2014 at 05:39:04PM +0300, Stefan I. Strogin wrote:
> From: Dmitry Safonov
>
> Here are two functions that provide interface to compute/get used size
> and size of biggest free chunk in cma region.
> Added that information in cmainfo.
>
> Signed-off-by: Dmitry Safonov
> ---
> include/linux/cma.h | 2 ++
> mm/cma.c| 34 ++
> 2 files changed, 36 insertions(+)
>
> diff --git a/include/linux/cma.h b/include/linux/cma.h
> index 9384ba6..855e6f2 100644
> --- a/include/linux/cma.h
> +++ b/include/linux/cma.h
> @@ -18,6 +18,8 @@ struct cma;
> extern unsigned long totalcma_pages;
> extern phys_addr_t cma_get_base(struct cma *cma);
> extern unsigned long cma_get_size(struct cma *cma);
> +extern unsigned long cma_get_used(struct cma *cma);
> +extern unsigned long cma_get_maxchunk(struct cma *cma);
>
> extern int __init cma_declare_contiguous(phys_addr_t base,
> phys_addr_t size, phys_addr_t limit,
> diff --git a/mm/cma.c b/mm/cma.c
> index ffaea26..5e560ed 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -78,6 +78,36 @@ unsigned long cma_get_size(struct cma *cma)
> return cma->count << PAGE_SHIFT;
> }
>
> +unsigned long cma_get_used(struct cma *cma)
> +{
> + unsigned long ret = 0;
> +
> + mutex_lock(>lock);
> + /* pages counter is smaller than sizeof(int) */
> + ret = bitmap_weight(cma->bitmap, (int)cma->count);
> + mutex_unlock(>lock);
> +
> + return ret << (PAGE_SHIFT + cma->order_per_bit);
> +}
> +
> +unsigned long cma_get_maxchunk(struct cma *cma)
> +{
> + unsigned long maxchunk = 0;
> + unsigned long start, end = 0;
> +
> + mutex_lock(>lock);
> + for (;;) {
> + start = find_next_zero_bit(cma->bitmap, cma->count, end);
> + if (start >= cma->count)
> + break;
> + end = find_next_bit(cma->bitmap, cma->count, start);
> + maxchunk = max(end - start, maxchunk);
> + }
> + mutex_unlock(>lock);
> +
> + return maxchunk << (PAGE_SHIFT + cma->order_per_bit);
> +}
> +
> static unsigned long cma_bitmap_aligned_mask(struct cma *cma, int
> align_order)
> {
> if (align_order <= cma->order_per_bit)
> @@ -591,6 +621,10 @@ static int s_show(struct seq_file *m, void *p)
> struct cma_buffer *cmabuf;
> struct stack_trace trace;
>
> + seq_printf(m, "CMARegion stat: %8lu kB total, %8lu kB used, %8lu kB max
> contiguous chunk\n\n",
> +cma_get_size(cma) >> 10,
> +cma_get_used(cma) >> 10,
> +cma_get_maxchunk(cma) >> 10);
> mutex_lock(>list_lock);
>
> list_for_each_entry(cmabuf, >buffers_list, list) {
Hello,
How about changing printing format like as meminfo or zoneinfo?
CMARegion #
Total: XXX
Used: YYY
MaxContig: ZZZ
It would help to parse information.
And, how about adding how many pages are used now as system pages?
You can implement it by iterating range of CMA region and checking
Buddy flag.
UsedBySystem = Total - UsedByCMA - freepageinCMARegion
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: [PATCH 3.2 00/27] 3.2.66-rc1 review
On Tue, 2014-12-30 at 09:26 +0900, Satoru Takeuchi wrote: > At Mon, 29 Dec 2014 02:11:30 +0100, > Ben Hutchings wrote: > > > > This is the start of the stable review cycle for the 3.2.66 release. > > There are 27 patches in this series, which will be posted as responses > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Wed Dec 31 12:00:00 UTC 2014. > > Anything received after that time might be too late. > > This kernel passed my test. > > - Test Cases: >- Build this kernel. >- Boot this kernel. >- Build the latest mainline kernel with this kernel. > > - Test Tool: >https://github.com/satoru-takeuchi/test-linux-stable > > - Test Result (kernel .config, ktest config and test log): >http://satoru-takeuchi.org/test-linux-stable/results/- datetime>.tar.xz > > - Build Environment: >- OS: Debian Jessy x86_64 >- CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 >- memory: 8GB > > - Test Target Environment: >- Debian Jessy x86_64 (KVM guest on the Build Environment) >- # of vCPU: 2 >- memory: 2GB Thanks for testing. Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one. signature.asc Description: This is a digitally signed message part
Re: [Linux-ima-user] Initramfs and IMA Appraisal
On 12/29/2014 03:46 PM, Mimi Zohar wrote:
> On Mon, 2014-12-29 at 14:34 -0600, Rob Landley wrote:
>> On 12/29/2014 07:45 AM, Mimi Zohar wrote:
>>> On Thu, 2014-11-27 at 10:15 +0100, Christophe Fillot wrote:
>
> Are you using an initrd not an initramfs? According to
> Documentation/filesystems/ramfs-rootfs-initramfs.txt, "If
CONFIG_TMPFS
> is enabled, rootfs will use tmpfs instead of ramfs by default".
>
Yes, that what I thought too, but it seems that it is not really the
case because of this test:
if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
(!root_fs_names || strstr(root_fs_names, "tmpfs"))) {
err = shmem_init();
is_tmpfs = true;
} else {
err = init_ramfs_fs();
}
>>>
>>> [CC'ing Rob Landley, lsm, lkml]
>>>
>>> Thanks! "saved_root_name" is set to the boot command line "root="
>>> option, which in my case is the UUID. I'm not sure why real root should
>>> impact the initramfs tmpfs/ramfs decision.
>>>
>>> Unless there is a good explanation, did you want to post a patch to
>>> remove the test?
>>
>> I added support last year, here's the start of the patch series:
>>
>> https://lkml.org/lkml/2013/6/29/101
>>
>> The logic is that if you specify a fallback root via root=, then you're
>> not staying on rootfs (that's what root= _means_, "here is the root
>> filesystem the kernel is to mount over rootfs"), and thus the extra
>> infrastructure for tmpfs instead of ramfs is unnecessary.
>
> Thanks Rob for the explanation. The problem is that ramfs does not
> support extended attributes, while tmpfs does.
If you're _using_ initramfs/initmpfs, there's no reason to specify a root=.
> The boot loader could
> "measure" (trusted boot) the initramfs, but as the initramfs is
> generated on the target system, the initramfs is not signed, preventing
> it from being appraised (secure Boot). To close the initramfs integrity
> appraisal gap requires verifying the individual initramfs file
> signatures, which are stored as extended attributes.
Faced with the phrases "trusted boot" and "integrity appraisal", I plead
the third.
(In the wake of the Snowden infodump, people no longer want to use the
elliptic curve cryptography the NSA designed, but they still happily
base their system configuration on SELinux with a stack of thousands of
rules you just have to take on faith. Possibly they're unaware the NSA
designed and still maintains SELinux? Dunno...)
>> Possibly the documentation needs to elaborate, but I expect what we
>> really need is a CONFIG_VERBOSE_ROOT_SETUP that sticks in a bunch of
>> printfs so the /dev/console output explains what it's doing. ("could not
>> exec /init out of initramfs (errno %d, file %s), falling back to
>> root=\nAdd blather=1 to kernel cmdline to see cpio
>> filenames/permissions.", and so on. Where "actual exec" shows where your
>> dynamic linker is when that's what wasn't there.)
>
> To add to the confusion
> Documentation/filesystems/ramfs-rootfs-initramfs.txt says, "If
> CONFIG_TMPFS is enabled, rootfs will use tmpfs instead of ramfs by
> default." This statement should be modified to reflect the actual code.
Actually I modified the code to reflect the documentation last year. (I
wrote the docs in 2005, the initmpfs code in 2013.)
The rootfs code _does_ use tmpfs by default. Specifying root= disables
it, because it indicates you aren't using ramfs but are requesting the
kernel overmount it with another filesystem before launching PID 1.
That's what root= _means_.
I can add a paragraph describing what root= means and that it's
inappropriate to use it with ramfs in general? (And that root=/dev/ram0
is a nonsensical option despite what some bits of the internet seem to
think.)
> Mimi
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: [PATCH V6] UBI: Extend UBI layer debug/messaging capabilities
On 2014/12/29 22:15, Tanya Brokhman wrote: > Hi Hu, > > On 12/29/2014 5:14 AM, hujianyang wrote: >> On 2014/11/3 21:58, Tanya Brokhman wrote: >>> If there is more then one UBI device mounted, there is no way to >>> distinguish between messages from different UBI devices. >>> Add device number to all ubi layer message types. >>> >>> The R/O block driver messages were replaced by pr_* since >>> ubi_device structure is not used by it. >>> >>> Amended a bit by Artem. >>> >>> Signed-off-by: Tanya Brokhman >>> Signed-off-by: Artem Bityutskiy >>> --- >>> Changes from V1: >> >> >> Hi Artem and Tanya, >> >> Do you think the similar effort is worth to be done on ubifs-level? > > We already did this for UBIFS as well and have been working with this patch > for some time now. Its in our todo to share it, just got pulled into some > urgent staff unfortunately. > Got it~! I'd like to wait for your patch, thanks for your work. Hu > > Thanks, > Tanya Brokhman -- 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: [resend][PATCH v9 1/3] procfs: show hierarchy of pid namespace
> -Original Message-
> From: containers-boun...@lists.linux-foundation.org
> [mailto:containers-boun...@lists.linux-foundation.org] On Behalf Of Chen
> Hanxiao
> Sent: Tuesday, December 23, 2014 6:21 PM
> To: Eric W. Biederman; Serge Hallyn; Andrew Morton; Pavel Emelyanov
> Cc: Richard Weinberger; contain...@lists.linux-foundation.org;
> linux-kernel@vger.kernel.org; Oleg Nesterov; David Howells; Mateusz Guzik
> Subject: [resend][PATCH v9 1/3] procfs: show hierarchy of pid namespace
>
> We lack of pid hierarchy information, and this will lead to:
> a) we don't know pids' relationship, who is whose child:
>/proc/PID/ns/pid only tell us whether two pids live in different ns
> b) bring trouble to nested lxc container checkpoint/restore/migration
> c) bring trouble to pid translation between containers;
>
> This patch will show the hierarchy of pid namespace
> by pidns_hierarchy like:
>
>
>
Hi Eric, Pavel
Any comments?
Regards,
- Chen
> Ex:
> [root@localhost ~]#cat /proc/pidns_hierarchy
> 18060 1 1
> 18102 18060 2
> 1534 18102 3
> 1600 18102 3
> 1550 1 1
> *Note: numbers represent the pid 1 in different ns
>
> It shows the pid hierarchy below:
>
> init_pid_ns 1
> │
> ┌┐
> ns1 ns2
> ││
> 155018060
> │
> │
> ns3
> │
> 18102
> │
> ┌──┐
> ns4 ns5
> ││
> 1534 1600
>
> Every pid printed in pidns_hierarchy
> is the init pid of that pid ns level.
>
> Acked-by: Richard Weinberer
>
> Signed-off-by: Chen Hanxiao
> ---
> v9: fix codes be included if CONFIG_PID_NS=n
> v8: use max() from kernel.h
> fix some improper comments
> v7: change stype to be consistent with current interface like
>
> remove EXPERT dependent in Kconfig
> v6: fix a get_pid leak and do some cleanups;
> v5: collect pid by find_ge_pid;
> use local list inside nslist_proc_show;
> use get_pid, remove mutex lock.
> v4: simplify pid collection and some performance optimizamtion
> fix another race issue.
> v3: fix a race issue and memory leak issue
> v2: use a procfs text file instead of dirs under /proc
>
> fs/proc/Kconfig | 6 +
> fs/proc/Makefile | 1 +
> fs/proc/internal.h| 9 ++
> fs/proc/pidns_hierarchy.c | 280
> ++
> fs/proc/root.c| 1 +
> 5 files changed, 297 insertions(+)
> create mode 100644 fs/proc/pidns_hierarchy.c
>
> diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
> index 2183fcf..82dda55 100644
> --- a/fs/proc/Kconfig
> +++ b/fs/proc/Kconfig
> @@ -71,3 +71,9 @@ config PROC_PAGE_MONITOR
> /proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
> /proc/kpagecount, and /proc/kpageflags. Disabling these
>interfaces will reduce the size of the kernel by approximately 4kb.
> +
> +config PROC_PID_HIERARCHY
> + bool "Enable /proc/pidns_hierarchy support"
> + depends on PROC_FS
> + help
> + Show pid namespace hierarchy information
> diff --git a/fs/proc/Makefile b/fs/proc/Makefile
> index 7151ea4..33e384b 100644
> --- a/fs/proc/Makefile
> +++ b/fs/proc/Makefile
> @@ -30,3 +30,4 @@ proc-$(CONFIG_PROC_KCORE) += kcore.o
> proc-$(CONFIG_PROC_VMCORE) += vmcore.o
> proc-$(CONFIG_PRINTK)+= kmsg.o
> proc-$(CONFIG_PROC_PAGE_MONITOR) += page.o
> +proc-$(CONFIG_PROC_PID_HIERARCHY)+= pidns_hierarchy.o
> diff --git a/fs/proc/internal.h b/fs/proc/internal.h
> index 6fcdba5..18e0773 100644
> --- a/fs/proc/internal.h
> +++ b/fs/proc/internal.h
> @@ -280,6 +280,15 @@ struct proc_maps_private {
> #endif
> };
>
> +/*
> + * pidns_hierarchy.c
> + */
> +#ifdef CONFIG_PROC_PID_HIERARCHY
> + extern void proc_pidns_hierarchy_init(void);
> +#else
> + static inline void proc_pidns_hierarchy_init(void) {}
> +#endif
> +
> struct mm_struct *proc_mem_open(struct inode *inode, unsigned int mode);
>
> extern const struct file_operations proc_pid_maps_operations;
> diff --git a/fs/proc/pidns_hierarchy.c b/fs/proc/pidns_hierarchy.c
> new file mode 100644
> index 000..ab1c665
> --- /dev/null
> +++ b/fs/proc/pidns_hierarchy.c
> @@ -0,0 +1,280 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * /proc/pidns_hierarchy
> + *
> + * show the hierarchy of pid namespace as:
> + *
> + *
> + * init_PID: child reaper in ns
> + * parent_of_init_PID: init_PID's parent, child reaper too
> + * relative PID level: pid level relative to caller's ns
> + */
> +
> +#define NS_HIERARCHY "pidns_hierarchy"
> +
> +/* list for host pid collection */
> +struct pidns_list {
> + struct list_head
Re: [PATCH v16 01/12] input: cyapa: re-design driver to support multi-trackpad in one driver
Hi Dudley, On Thu, Dec 18, 2014 at 06:00:45PM +0800, Dudley Du wrote: > In order to support multiple different chipsets and communication protocols > trackpad devices in one cyapa driver, the new cyapa driver is re-designed > with one cyapa driver core and multiple device specific functions component. > The cyapa driver core is contained in this patch, it supplies basic functions > that working with kernel and input subsystem, and also supplies the interfaces > that the specific devices' component can connect and work together with as > one driver. > TEST=test on Chromebooks. Thank you for making changes to the driver. It shapes up nicely, still I have a few comments: 1. I'd rather we did not check for presence of various methods in ops structure but rather rely on providers to supply stubs if they do not need actual implementation (see a draft of a patch below). 2. Please consider changing CYAPA_BOOTLOADER() and friends to be static inline functions (like cyapa_is_bootloader_mode())- it provides better type checking. 3. The ops->initialize() method should be called after we determine the generation of the device, not before. 4. I wonder why cyapa_read_block() is in gen3 file and not in main file - it seems it is used by generic code? 5. Is bootloader mode different between gen3 and gen5 devices? Or should you detect and handle bootloader mode directly in the core, maybe as a "fake generation"? Thanks! > > Signed-off-by: Dudley Du > --- > drivers/input/mouse/Makefile |3 +- > drivers/input/mouse/cyapa.c | 1047 > ++ > drivers/input/mouse/cyapa.h | 307 +++ > drivers/input/mouse/cyapa_gen3.c | 801 + > 4 files changed, 1492 insertions(+), 666 deletions(-) > create mode 100644 drivers/input/mouse/cyapa.h > create mode 100644 drivers/input/mouse/cyapa_gen3.c > > diff --git a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile > index 560003d..8bd950d 100644 > --- a/drivers/input/mouse/Makefile > +++ b/drivers/input/mouse/Makefile > @@ -8,7 +8,7 @@ obj-$(CONFIG_MOUSE_AMIGA) += amimouse.o > obj-$(CONFIG_MOUSE_APPLETOUCH) += appletouch.o > obj-$(CONFIG_MOUSE_ATARI)+= atarimouse.o > obj-$(CONFIG_MOUSE_BCM5974) += bcm5974.o > -obj-$(CONFIG_MOUSE_CYAPA)+= cyapa.o > +obj-$(CONFIG_MOUSE_CYAPA)+= cyapatp.o > obj-$(CONFIG_MOUSE_ELAN_I2C) += elan_i2c.o > obj-$(CONFIG_MOUSE_GPIO) += gpio_mouse.o > obj-$(CONFIG_MOUSE_INPORT) += inport.o > @@ -24,6 +24,7 @@ obj-$(CONFIG_MOUSE_SYNAPTICS_I2C) += synaptics_i2c.o > obj-$(CONFIG_MOUSE_SYNAPTICS_USB)+= synaptics_usb.o > obj-$(CONFIG_MOUSE_VSXXXAA) += vsxxxaa.o > > +cyapatp-objs := cyapa.o cyapa_gen3.o > psmouse-objs := psmouse-base.o synaptics.o focaltech.o > > psmouse-$(CONFIG_MOUSE_PS2_ALPS) += alps.o > diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c > index 1bece8c..ae1df15 100644 > --- a/drivers/input/mouse/cyapa.c > +++ b/drivers/input/mouse/cyapa.c > @@ -20,408 +20,100 @@ > #include > #include > #include > +#include > #include > +#include > +#include "cyapa.h" > > -/* APA trackpad firmware generation */ > -#define CYAPA_GEN3 0x03 /* support MT-protocol B with tracking ID. */ > - > -#define CYAPA_NAME "Cypress APA Trackpad (cyapa)" > - > -/* commands for read/write registers of Cypress trackpad */ > -#define CYAPA_CMD_SOFT_RESET 0x00 > -#define CYAPA_CMD_POWER_MODE 0x01 > -#define CYAPA_CMD_DEV_STATUS 0x02 > -#define CYAPA_CMD_GROUP_DATA 0x03 > -#define CYAPA_CMD_GROUP_CMD0x04 > -#define CYAPA_CMD_GROUP_QUERY 0x05 > -#define CYAPA_CMD_BL_STATUS0x06 > -#define CYAPA_CMD_BL_HEAD 0x07 > -#define CYAPA_CMD_BL_CMD 0x08 > -#define CYAPA_CMD_BL_DATA 0x09 > -#define CYAPA_CMD_BL_ALL 0x0a > -#define CYAPA_CMD_BLK_PRODUCT_ID 0x0b > -#define CYAPA_CMD_BLK_HEAD 0x0c > - > -/* report data start reg offset address. */ > -#define DATA_REG_START_OFFSET 0x > - > -#define BL_HEAD_OFFSET 0x00 > -#define BL_DATA_OFFSET 0x10 > - > -/* > - * Operational Device Status Register > - * > - * bit 7: Valid interrupt source > - * bit 6 - 4: Reserved > - * bit 3 - 2: Power status > - * bit 1 - 0: Device status > - */ > -#define REG_OP_STATUS 0x00 > -#define OP_STATUS_SRC 0x80 > -#define OP_STATUS_POWER 0x0c > -#define OP_STATUS_DEV 0x03 > -#define OP_STATUS_MASK (OP_STATUS_SRC | OP_STATUS_POWER | OP_STATUS_DEV) > - > -/* > - * Operational Finger Count/Button Flags Register > - * > - * bit 7 - 4: Number of touched finger > - * bit 3: Valid data > - * bit 2: Middle Physical Button > - * bit 1: Right Physical Button > - * bit 0: Left physical Button > - */ > -#define REG_OP_DATA1 0x01 > -#define OP_DATA_VALID 0x08 > -#define OP_DATA_MIDDLE_BTN 0x04 > -#define OP_DATA_RIGHT_BTN 0x02 > -#define
Re: sched: spinlock recursion in sched_rr_get_interval
On 12/28/2014 03:17 PM, Davidlohr Bueso wrote: >> That is, what race condition specifically creates the >> > 'lock->owner == current' situation in the debug check? > Why do you suspect a race as opposed to a legitimate recursion issue? > Although after staring at the code for a while, I cannot see foul play > in sched_rr_get_interval. Because it's not specific to sched_rr_get_interval. I've seen the same error with different traces, and when the only common thing is the spinlock debug output looking off then that's what I'm going to blame. Here's an example of a completely sched-unrelated trace: [ 1971.009744] BUG: spinlock lockup suspected on CPU#7, trinity-c436/29017 [ 1971.013170] lock: 0x88016e0d8af0, .magic: dead4ead, .owner: trinity-c404/541, .owner_cpu: 12 [ 1971.017630] CPU: 7 PID: 29017 Comm: trinity-c436 Not tainted 3.19.0-rc1-next-20141226-sasha-00051-g2dd3d73-dirty #1639 [ 1971.023642] 880102fe3000 88014e923658 [ 1971.027654] b13501de 0055 88016e0d8af0 88014e923698 [ 1971.031716] a1588205 88016e0d8af0 88016e0d8b00 88016e0d8af0 [ 1971.035695] Call Trace: [ 1971.037081] dump_stack (lib/dump_stack.c:52) [ 1971.040175] spin_dump (kernel/locking/spinlock_debug.c:68 (discriminator 8)) [ 1971.043138] do_raw_spin_lock (include/linux/nmi.h:48 kernel/locking/spinlock_debug.c:119 kernel/locking/spinlock_debug.c:137) [ 1971.046155] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 kernel/locking/spinlock.c:151) [ 1971.048801] ? __page_check_address (include/linux/spinlock.h:309 mm/rmap.c:633) [ 1971.052152] __page_check_address (include/linux/spinlock.h:309 mm/rmap.c:633) [ 1971.055129] try_to_unmap_one (include/linux/rmap.h:204 mm/rmap.c:1176) [ 1971.057738] ? vma_interval_tree_iter_next (mm/interval_tree.c:24 (discriminator 4)) [ 1971.061181] rmap_walk (mm/rmap.c:1747 mm/rmap.c:1772) [ 1971.062582] try_to_munlock (mm/rmap.c:1631) [ 1971.064829] ? try_to_unmap_nonlinear (mm/rmap.c:1167) [ 1971.068741] ? SyS_msync (mm/rmap.c:1546) [ 1971.072252] ? page_get_anon_vma (mm/rmap.c:450) [ 1971.074321] __munlock_isolated_page (mm/mlock.c:132) [ 1971.075431] __munlock_pagevec (mm/mlock.c:388) [ 1971.076345] ? munlock_vma_pages_range (include/linux/mm.h:906 mm/mlock.c:521) [ 1971.077371] munlock_vma_pages_range (mm/mlock.c:533) [ 1971.078339] exit_mmap (mm/internal.h:227 mm/mmap.c:2827) [ 1971.079153] ? retint_restore_args (arch/x86/kernel/entry_64.S:844) [ 1971.080197] ? __khugepaged_exit (./arch/x86/include/asm/atomic.h:118 include/linux/sched.h:2463 mm/huge_memory.c:2151) [ 1971.081055] ? __khugepaged_exit (./arch/x86/include/asm/atomic.h:118 include/linux/sched.h:2463 mm/huge_memory.c:2151) [ 1971.081915] mmput (kernel/fork.c:659) [ 1971.082578] do_exit (./arch/x86/include/asm/thread_info.h:164 kernel/exit.c:438 kernel/exit.c:732) [ 1971.083360] ? sched_clock_cpu (kernel/sched/clock.c:311) [ 1971.084191] ? get_signal (kernel/signal.c:2338) [ 1971.084984] ? _raw_spin_unlock_irq (./arch/x86/include/asm/paravirt.h:819 include/linux/spinlock_api_smp.h:168 kernel/locking/spinlock.c:199) [ 1971.085862] do_group_exit (include/linux/sched.h:775 kernel/exit.c:858) [ 1971.086659] get_signal (kernel/signal.c:2358) [ 1971.087486] ? sched_clock_local (kernel/sched/clock.c:202) [ 1971.088359] ? sched_clock (./arch/x86/include/asm/paravirt.h:192 arch/x86/kernel/tsc.c:304) [ 1971.089142] do_signal (arch/x86/kernel/signal.c:703) [ 1971.089896] ? vtime_account_user (kernel/sched/cputime.c:701) [ 1971.090853] ? context_tracking_user_exit (./arch/x86/include/asm/paravirt.h:809 (discriminator 2) kernel/context_tracking.c:144 (discriminator 2)) [ 1971.091950] ? trace_hardirqs_on (kernel/locking/lockdep.c:2609) [ 1971.092806] do_notify_resume (arch/x86/kernel/signal.c:756) [ 1971.093618] int_signal (arch/x86/kernel/entry_64.S:587) Thanks, Sasha -- 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.19 2/3] x86, mpx: Short-circuit the instruction decoder for unexpected opcodes
On Mon, Dec 29, 2014 at 4:52 PM, Andy Lutomirski wrote: > This reduces the degree to which we're exposing the instruction decoder > to malicious user code and very little complexity cost. Don't apply this as is -- it's obviously incorrect. I'll send a v2 in a couple of days. However: can an MPX instruction use a segment override? FS and GS seem plausible for TLS. If so, is the current decoding logic handling it correctly? Presumably the byte 0 == 0x0f check will completely prevent it from working, even if the decode logic would later forget to correct for the segment base. --Andy > > Signed-off-by: Andy Lutomirski > --- > arch/x86/mm/mpx.c | 26 +- > 1 file changed, 17 insertions(+), 9 deletions(-) > > diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c > index 082ab9c4ac1c..cefa615becb3 100644 > --- a/arch/x86/mm/mpx.c > +++ b/arch/x86/mm/mpx.c > @@ -230,6 +230,23 @@ static int mpx_insn_decode(struct insn *insn, > */ > if (!nr_copied) > return -EFAULT; > + > + /* > +* We only _really_ need to decode bndcl/bndcn/bndcu > +* Error out on anything else. Check this before decoding the > +* instruction to reduce our exposure to intentionally bad code > +* to some extent. Note that this shortcut cat incorrectly return > +* -EINVAL instead of -EFAULT under some circumstances. This > +* discrepency has no effect. > +*/ > + if (nr_copied < 2) > + goto bad_opcode; > + if (insn->opcode.bytes[0] != 0x0f) > + goto bad_opcode; > + if ((insn->opcode.bytes[1] != 0x1a) && > + (insn->opcode.bytes[1] != 0x1b)) > + goto bad_opcode; > + > insn_init(insn, buf, nr_copied, x86_64); > insn_get_length(insn); > /* > @@ -244,15 +261,6 @@ static int mpx_insn_decode(struct insn *insn, > return -EFAULT; > > insn_get_opcode(insn); > - /* > -* We only _really_ need to decode bndcl/bndcn/bndcu > -* Error out on anything else. > -*/ > - if (insn->opcode.bytes[0] != 0x0f) > - goto bad_opcode; > - if ((insn->opcode.bytes[1] != 0x1a) && > - (insn->opcode.bytes[1] != 0x1b)) > - goto bad_opcode; > > return 0; > bad_opcode: > -- > 2.1.0 > -- Andy Lutomirski AMA Capital Management, LLC -- 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 v16 04/12] input: cyapa: add runtime power management interfaces support for the device
Hi Dudley,
On Thu, Dec 18, 2014 at 06:00:48PM +0800, Dudley Du wrote:
> Add runtime_suspend_scanrate_ms power management interfaces in device's
> power group, so users or applications can control the runtime power
> management strategy of trackpad device as their requirements.
> TEST=test on Chromebooks.
>
> Signed-off-by: Dudley Du
> ---
> drivers/input/mouse/cyapa.c | 171
> +++-
> drivers/input/mouse/cyapa.h | 4 ++
> 2 files changed, 174 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
> index 73f6817..3bcfce3 100644
> --- a/drivers/input/mouse/cyapa.c
> +++ b/drivers/input/mouse/cyapa.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include "cyapa.h"
>
>
> @@ -327,6 +328,8 @@ static int cyapa_open(struct input_dev *input)
> }
>
> enable_irq(client->irq);
> + pm_runtime_set_active(>dev);
> + pm_runtime_enable(>dev);
> out:
> mutex_unlock(>state_sync_lock);
> return error;
> @@ -340,8 +343,10 @@ static void cyapa_close(struct input_dev *input)
> mutex_lock(>state_sync_lock);
>
> disable_irq(client->irq);
> + pm_runtime_disable(>dev);
> if (!CYAPA_BOOTLOADER(cyapa) && cyapa->ops->set_power_mode)
> cyapa->ops->set_power_mode(cyapa, PWR_MODE_OFF, 0);
> + pm_runtime_set_suspended(>dev);
>
> mutex_unlock(>state_sync_lock);
> }
> @@ -542,6 +547,7 @@ static irqreturn_t cyapa_irq(int irq, void *dev_id)
> struct device *dev = >client->dev;
> bool cont;
>
> + pm_runtime_get_sync(dev);
> if (device_may_wakeup(dev))
> pm_wakeup_event(dev, 0);
>
> @@ -572,6 +578,8 @@ static irqreturn_t cyapa_irq(int irq, void *dev_id)
> }
>
> out:
> + pm_runtime_mark_last_busy(dev);
> + pm_runtime_put_sync_autosuspend(dev);
> return IRQ_HANDLED;
> }
>
> @@ -665,6 +673,116 @@ static void cyapa_remove_power_wakeup_group(void *data)
> }
> #endif /* CONFIG_PM_SLEEP */
>
> +#ifdef CONFIG_PM_RUNTIME
> +static ssize_t cyapa_show_rt_suspend_scanrate(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct cyapa *cyapa = dev_get_drvdata(dev);
> + u8 pwr_cmd;
> + u16 sleep_time;
> + int error;
> +
> + error = mutex_lock_interruptible(>state_sync_lock);
> + if (error)
> + return error;
> + pwr_cmd = cyapa->runtime_suspend_power_mode;
> + sleep_time = cyapa->runtime_suspend_sleep_time;
> + mutex_unlock(>state_sync_lock);
> +
> + if (cyapa->gen == CYAPA_GEN3)
> + return scnprintf(buf, PAGE_SIZE, "%u\n",
> + cyapa_pwr_cmd_to_sleep_time(pwr_cmd));
> + return scnprintf(buf, PAGE_SIZE, "%u\n", sleep_time);
> +}
> +
> +static ssize_t cyapa_update_rt_suspend_scanrate(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct cyapa *cyapa = dev_get_drvdata(dev);
> + u16 time;
> + int error;
> +
> + if (buf == NULL || count == 0 || kstrtou16(buf, 10, )) {
> + dev_err(dev, "invalid runtime suspend scanrate ms parameter\n");
> + return -EINVAL;
> + }
> +
> + /*
> + * When the suspend scanrate is changed, pm_runtime_get to resume
> + * a potentially suspended device, update to the new pwr_cmd
> + * and then pm_runtime_put to suspend into the new power mode.
> + */
> + pm_runtime_get_sync(dev);
> + error = mutex_lock_interruptible(>state_sync_lock);
> + if (error)
> + return error;
> + cyapa->runtime_suspend_sleep_time = max_t(u16, time, 1000);
> + cyapa->runtime_suspend_power_mode =
> + cyapa_sleep_time_to_pwr_cmd(cyapa->runtime_suspend_sleep_time);
> + mutex_unlock(>state_sync_lock);
> + pm_runtime_put_sync_autosuspend(dev);
> +
> + return count;
> +}
> +
> +static DEVICE_ATTR(runtime_suspend_scanrate_ms, S_IRUGO|S_IWUSR,
> +cyapa_show_rt_suspend_scanrate,
> +cyapa_update_rt_suspend_scanrate);
> +
> +static struct attribute *cyapa_power_runtime_entries[] = {
> + _attr_runtime_suspend_scanrate_ms.attr,
> + NULL,
> +};
> +
> +static const struct attribute_group cyapa_power_runtime_group = {
> + .name = power_group_name,
> + .attrs = cyapa_power_runtime_entries,
> +};
> +
> +static void cyapa_remove_power_runtime_group(void *data)
> +{
> + struct cyapa *cyapa = data;
> +
> + sysfs_unmerge_group(>client->dev.kobj,
> + _power_runtime_group);
> +}
> +
> +static int cyapa_start_runtime(struct cyapa *cyapa)
> +{
> + struct device *dev = >client->dev;
> + int error;
> +
> + cyapa->runtime_suspend_power_mode = PWR_MODE_IDLE;
> +
[PATCH 3.19 2/3] x86, mpx: Short-circuit the instruction decoder for unexpected opcodes
This reduces the degree to which we're exposing the instruction decoder to malicious user code and very little complexity cost. Signed-off-by: Andy Lutomirski --- arch/x86/mm/mpx.c | 26 +- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c index 082ab9c4ac1c..cefa615becb3 100644 --- a/arch/x86/mm/mpx.c +++ b/arch/x86/mm/mpx.c @@ -230,6 +230,23 @@ static int mpx_insn_decode(struct insn *insn, */ if (!nr_copied) return -EFAULT; + + /* +* We only _really_ need to decode bndcl/bndcn/bndcu +* Error out on anything else. Check this before decoding the +* instruction to reduce our exposure to intentionally bad code +* to some extent. Note that this shortcut cat incorrectly return +* -EINVAL instead of -EFAULT under some circumstances. This +* discrepency has no effect. +*/ + if (nr_copied < 2) + goto bad_opcode; + if (insn->opcode.bytes[0] != 0x0f) + goto bad_opcode; + if ((insn->opcode.bytes[1] != 0x1a) && + (insn->opcode.bytes[1] != 0x1b)) + goto bad_opcode; + insn_init(insn, buf, nr_copied, x86_64); insn_get_length(insn); /* @@ -244,15 +261,6 @@ static int mpx_insn_decode(struct insn *insn, return -EFAULT; insn_get_opcode(insn); - /* -* We only _really_ need to decode bndcl/bndcn/bndcu -* Error out on anything else. -*/ - if (insn->opcode.bytes[0] != 0x0f) - goto bad_opcode; - if ((insn->opcode.bytes[1] != 0x1a) && - (insn->opcode.bytes[1] != 0x1b)) - goto bad_opcode; return 0; bad_opcode: -- 2.1.0 -- 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.19 3/3] x86, mpx: Change the MPX enable/disable API to arch_prctl
Enabling and disabling kernel assistance for MPX is as arch-specific
as it gets. Update the API to use arch_prctl.
This has the benefit the it avoids cluttering prctl with more
arch-specific functionality. The down side is that arch_prctl will
need to be wired up as a 32-bit syscall to add 32-bit support for
MPX.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/uapi/asm/prctl.h | 15 +++
arch/x86/kernel/process_64.c | 10 ++
include/uapi/linux/prctl.h| 6 --
kernel/sys.c | 12
4 files changed, 21 insertions(+), 22 deletions(-)
diff --git a/arch/x86/include/uapi/asm/prctl.h
b/arch/x86/include/uapi/asm/prctl.h
index 3ac5032fae09..a39aef96a922 100644
--- a/arch/x86/include/uapi/asm/prctl.h
+++ b/arch/x86/include/uapi/asm/prctl.h
@@ -1,9 +1,16 @@
#ifndef _ASM_X86_PRCTL_H
#define _ASM_X86_PRCTL_H
-#define ARCH_SET_GS 0x1001
-#define ARCH_SET_FS 0x1002
-#define ARCH_GET_FS 0x1003
-#define ARCH_GET_GS 0x1004
+#define ARCH_SET_GS0x1001
+#define ARCH_SET_FS0x1002
+#define ARCH_GET_FS0x1003
+#define ARCH_GET_GS0x1004
+
+/*
+ * Tell the kernel to start/stop helping userspace manage bounds tables.
+ * For both of these functions, addr must be zero.
+ */
+#define ARCH_ENABLE_MPX0x1005
+#define ARCH_DISABLE_MPX 0x1006
#endif /* _ASM_X86_PRCTL_H */
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 5a2c02913af3..d11355668e58 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -586,6 +586,16 @@ long do_arch_prctl(struct task_struct *task, int code,
unsigned long addr)
ret = put_user(base, (unsigned long __user *)addr);
break;
}
+ case ARCH_ENABLE_MPX: {
+ if (addr != 0)
+ return -EINVAL;
+ ret = mpx_enable_management(task);
+ }
+ case ARCH_DISABLE_MPX: {
+ if (addr != 0)
+ return -EINVAL;
+ ret = mpx_disable_management(task);
+ }
default:
ret = -EINVAL;
diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h
index 89f63503f903..513df75d0fc9 100644
--- a/include/uapi/linux/prctl.h
+++ b/include/uapi/linux/prctl.h
@@ -179,10 +179,4 @@ struct prctl_mm_map {
#define PR_SET_THP_DISABLE 41
#define PR_GET_THP_DISABLE 42
-/*
- * Tell the kernel to start/stop helping userspace manage bounds tables.
- */
-#define PR_MPX_ENABLE_MANAGEMENT 43
-#define PR_MPX_DISABLE_MANAGEMENT 44
-
#endif /* _LINUX_PRCTL_H */
diff --git a/kernel/sys.c b/kernel/sys.c
index a8c9f5a7dda6..1eaa2f0b0246 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -91,12 +91,6 @@
#ifndef SET_TSC_CTL
# define SET_TSC_CTL(a)(-EINVAL)
#endif
-#ifndef MPX_ENABLE_MANAGEMENT
-# define MPX_ENABLE_MANAGEMENT(a) (-EINVAL)
-#endif
-#ifndef MPX_DISABLE_MANAGEMENT
-# define MPX_DISABLE_MANAGEMENT(a) (-EINVAL)
-#endif
/*
* this is where the system-wide overflow UID and GID are defined, for
@@ -2209,12 +2203,6 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2,
unsigned long, arg3,
me->mm->def_flags &= ~VM_NOHUGEPAGE;
up_write(>mm->mmap_sem);
break;
- case PR_MPX_ENABLE_MANAGEMENT:
- error = MPX_ENABLE_MANAGEMENT(me);
- break;
- case PR_MPX_DISABLE_MANAGEMENT:
- error = MPX_DISABLE_MANAGEMENT(me);
- break;
default:
error = -EINVAL;
break;
--
2.1.0
--
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.19 0/3] Possible MPX improvements for 3.19
I don't have the hardware, so this is only compile-tested. Patches 1 and 2 should be safe. Patch 1 is a bugfix, although given the bitness sensitivity of the MPX data structures, any user code that hits the bug is probably doomed to failure anyway. Patch 2 is a hardening change that adds almost no complexity (it's mostly just reordering some code) that will make it considerably harder to exploit a possibly insn decoder vulnerability using threads that modify MPX instructions that send #BR before the trap handler runs. Patch 3 will be much more controversial, since it's a complete ABI break. The ABI in question has never appeared in a released kernel, though. If patch 3 is not okay, then I want to fix the prctl implementation to at least validate its arguments. Andy Lutomirski (3): x86, mpx: Check user mode bitness correctly when decoding instructions x86, mpx: Short-circuit the instruction decoder for unexpected opcodes x86, mpx: Change the MPX enable/disable API to arch_prctl arch/x86/include/asm/ptrace.h | 5 + arch/x86/include/uapi/asm/prctl.h | 15 +++ arch/x86/kernel/process_64.c | 10 ++ arch/x86/mm/mpx.c | 28 ++-- include/uapi/linux/prctl.h| 6 -- kernel/sys.c | 12 6 files changed, 44 insertions(+), 32 deletions(-) -- 2.1.0 -- 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.19 1/3] x86, mpx: Check user mode bitness correctly when decoding instructions
When decoding a user instruction, the bitness depends on CS, not on
TIF_IA32.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/ptrace.h | 5 +
arch/x86/mm/mpx.c | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
index 86fc2bb82287..189113c74726 100644
--- a/arch/x86/include/asm/ptrace.h
+++ b/arch/x86/include/asm/ptrace.h
@@ -144,6 +144,11 @@ static inline bool user_64bit_mode(struct pt_regs *regs)
(test_thread_flag(TIF_IA32) \
? current_pt_regs()->sp\
: this_cpu_read(old_rsp))
+#else
+static inline bool user_64bit_mode(struct pt_regs *regs)
+{
+ return false;
+}
#endif
#ifdef CONFIG_X86_32
diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c
index 67ebf5751222..082ab9c4ac1c 100644
--- a/arch/x86/mm/mpx.c
+++ b/arch/x86/mm/mpx.c
@@ -217,7 +217,7 @@ static int mpx_insn_decode(struct insn *insn,
struct pt_regs *regs)
{
unsigned char buf[MAX_INSN_SIZE];
- int x86_64 = !test_thread_flag(TIF_IA32);
+ int x86_64 = user_64bit_mode(regs);
int not_copied;
int nr_copied;
--
2.1.0
--
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 v16 03/12] input: cyapa: add power management interfaces support for the device
Hi Dudley,
On Thu, Dec 18, 2014 at 06:00:47PM +0800, Dudley Du wrote:
> Add suspend_scanrate_ms power management interfaces in device's
> power group, so users or applications can control the power management
> strategy of trackpad device as their requirements.
> TEST=test on Chromebooks.
>
> Signed-off-by: Dudley Du
> ---
> drivers/input/mouse/cyapa.c | 111
>
> 1 file changed, 111 insertions(+)
>
> diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
> index d4560a3..73f6817 100644
> --- a/drivers/input/mouse/cyapa.c
> +++ b/drivers/input/mouse/cyapa.c
> @@ -575,6 +575,96 @@ out:
> return IRQ_HANDLED;
> }
>
> +/*
> + **
> + * sysfs interface
> + **
> +*/
> +#ifdef CONFIG_PM_SLEEP
> +static ssize_t cyapa_show_suspend_scanrate(struct device *dev,
> +struct device_attribute *attr,
> +char *buf)
> +{
> + struct cyapa *cyapa = dev_get_drvdata(dev);
> + u8 pwr_cmd = cyapa->suspend_power_mode;
> + u16 sleep_time;
> + int len;
> + int error;
> +
> + error = mutex_lock_interruptible(>state_sync_lock);
> + if (error)
> + return error;
> + pwr_cmd = cyapa->suspend_power_mode;
> + sleep_time = cyapa->suspend_sleep_time;
> + mutex_unlock(>state_sync_lock);
> +
> + if (pwr_cmd == PWR_MODE_BTN_ONLY) {
> + len = scnprintf(buf, PAGE_SIZE, "%s\n", BTN_ONLY_MODE_NAME);
> + } else if (pwr_cmd == PWR_MODE_OFF) {
> + len = scnprintf(buf, PAGE_SIZE, "%s\n", OFF_MODE_NAME);
> + } else {
> + if (cyapa->gen == CYAPA_GEN3)
> + sleep_time = cyapa_pwr_cmd_to_sleep_time(pwr_cmd);
> + len = scnprintf(buf, PAGE_SIZE, "%u\n", sleep_time);
> + }
> +
> + return len;
> +}
> +
> +static ssize_t cyapa_update_suspend_scanrate(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct cyapa *cyapa = dev_get_drvdata(dev);
> + u16 sleep_time;
> + int error;
> +
> + error = mutex_lock_interruptible(>state_sync_lock);
> + if (error)
> + return error;
> +
> + if (sysfs_streq(buf, BTN_ONLY_MODE_NAME)) {
> + cyapa->suspend_power_mode = PWR_MODE_BTN_ONLY;
> + } else if (sysfs_streq(buf, OFF_MODE_NAME)) {
> + cyapa->suspend_power_mode = PWR_MODE_OFF;
> + } else if (!kstrtou16(buf, 10, _time)) {
> + cyapa->suspend_sleep_time = max_t(u16, sleep_time, 1000);
> + cyapa->suspend_power_mode =
> + cyapa_sleep_time_to_pwr_cmd(cyapa->suspend_sleep_time);
> + } else {
> + count = 0;
> + }
> +
> + mutex_unlock(>state_sync_lock);
> +
> + if (!count)
> + dev_err(dev, "invalid suspend scanrate ms parameters\n");
I'd rather we just return -EINVAL and not display the message so as to
not fill the logs.
> + return count ? count : -EINVAL;
> +}
> +
> +static DEVICE_ATTR(suspend_scanrate_ms, S_IRUGO|S_IWUSR,
> +cyapa_show_suspend_scanrate,
> +cyapa_update_suspend_scanrate);
> +
> +static struct attribute *cyapa_power_wakeup_entries[] = {
> + _attr_suspend_scanrate_ms.attr,
> + NULL,
> +};
> +
> +static const struct attribute_group cyapa_power_wakeup_group = {
> + .name = power_group_name,
> + .attrs = cyapa_power_wakeup_entries,
> +};
> +
> +static void cyapa_remove_power_wakeup_group(void *data)
> +{
> + struct cyapa *cyapa = data;
> +
> + sysfs_unmerge_group(>client->dev.kobj,
> + _power_wakeup_group);
> +}
> +#endif /* CONFIG_PM_SLEEP */
> +
> static int cyapa_probe(struct i2c_client *client,
> const struct i2c_device_id *dev_id)
> {
> @@ -614,6 +704,27 @@ static int cyapa_probe(struct i2c_client *client,
> return error;
> }
>
> +#ifdef CONFIG_PM_SLEEP
> + if (device_can_wakeup(dev)) {
> + error = sysfs_merge_group(>dev.kobj,
> + _power_wakeup_group);
> + if (error) {
> + dev_err(dev, "failed to add power wakeup group: %d\n",
> + error);
> + return error;
> + }
> +
> + error = devm_add_action(dev,
> + cyapa_remove_power_wakeup_group, cyapa);
> + if (error) {
> + cyapa_remove_power_wakeup_group(cyapa);
> + dev_err(dev, "failed to add power cleanup action: %d\n",
> + error);
> + return error;
> + }
> + }
> +#endif /* CONFIG_PM_SLEEP */
Please split out
Re: [PATCH] tty: serial: msm_serial: Remove duplicate call to msm_set_baud_rate
On 12/22/2014 6:44 AM, Pramod Gurav wrote: > The function 'msm_set_baud_rate' is called twice while setting up > msm console. Once in msm_console_setup and next when uart_set_options > calls port->ops->set_termios ie. msm_set_termios(). > > Remove the duplicate call in msm_console_setup. Tested on IFC6410 > console. > > Signed-off-by: Pramod Gurav > --- > drivers/tty/serial/msm_serial.c |1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c > index dbc278d..4c4a250 100644 > --- a/drivers/tty/serial/msm_serial.c > +++ b/drivers/tty/serial/msm_serial.c > @@ -945,7 +945,6 @@ static int __init msm_console_setup(struct console *co, > char *options) > > if (baud < 300 || baud > 115200) > baud = 115200; > - msm_set_baud_rate(port, baud); > > msm_reset(port); > There seems to be more stuff done in this console setup path that is duplicated by the msm_set_termios() function. Can we clean it all up? I would bet that the msm_reset() is there because we changed the buad rate and so if we remove the baud rate setting we can remove the reset as well (see commit a12f1b406f2d tty: serial: msm: Reset uartdm after baud rate change, 2014-10-29). We might as well dump the CR_CMD_PROTECTION_EN and CR_TX_ENABLE thing as well given that we do the same in msm_set_baud_rate() already. And maybe we can even get rid of the baud rate capping and forced 8N1 setting that goes on here too. Just let the user do what they want? -- Qualcomm Innovation Center, Inc. is a member of 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: [RFC PATCH] f2fs: add extent cache base on rb-tree
Hi all,
On Mon, Dec 29, 2014 at 01:23:00PM -0800, Jaegeuk Kim wrote:
> Hi Chao,
>
> On Mon, Dec 29, 2014 at 03:19:18PM +0800, Chao Yu wrote:
>
> [snip]
>
> Nice draft. :)
>
> >
> > Please see the draft below.
> >
> > 1) Extent management:
> > If we use global management that managing all extents which are from
> > different
> > inodes in sbi, we will face with serious lock contention when we access
> > these
> > extents belong to different inodes concurrently, the loss may outweights the
> > gain.
>
> Agreed.
>
> > So we choose a local management for extent which means all extents are
> > managed by inode itself to avoid above lock contention. Addtionlly, we
> > manage
> > all extents globally by linking all inode into a global lru list for extent
> > cache shrinker.
> > Approach:
> > a) build extent tree/rwlock/lru list/extent count in each inode.
> > *extent tree: link all extent in rb-tree;
> > *rwlock: protect fields when accessing extent cache
> > concurrently;
> > *lru list: sort all extents in accessing time order;
> > *extent count: record total count of extents in cache.
> > b) use lru shrink list in sbi to manage all inode which cached extents.
> > *inode will be added or repostioned in this global list whenever
> > extent is being access in this inode.
> > *use spinlock to protect this shrink list.
>
> 1. How about adding a data structure with inode number instead of referring
> inode pointer?
>
> 2. How about managing extent entries globally and setting an upper bound to
> the number of extent entries instead of limiting them per each inode?
> (The rb-tree will handle many extents per inode.)
>
> 3. It needs to set a minimum length for the candidate of extent cache.
> (e.g., 64)
>
Agreed.
> So, for example,
> struct ino_entry_for_extents {
> inode number;
> rb_tree for extent_entry objects;
> rwlock;
> };
>
> struct extent_entry {
> blkaddr, len;
> list_head *;
> };
>
> Something like this.
>
> [A, B, C, ... are extent entry]
>
> The sbi has
> 1. an extent_list: (LRU) A -> B -> C -> D -> E -> F -> G (MRU)
> 2. radix_tree: ino_entry_for_extents (#10) has D, B in rb-tree
> ` ino_entry_for_extents (#11) has A, C in rb-tree
> ` ino_entry_for_extents (#12) has Fin rb-tree
> ` ino_entry_for_extents (#13) has G, E in rb-tree
>
> In f2fs_update_extent_cache and __get_data_block for #10,
> ino_entry_for_extents (#10) was founded and updated D or B.
> Then, updated entries are moved to MRU.
>
> In f2fs_evict_inode for #11, A and C are moved to LRU.
> But, if this inode is unlinked, all the A, C, and ino_entry_for_extens (#11)
> should be released.
>
> In f2fs_balance_fs_bg, some LRU extents are released according to the amount
> of consumed memory. Then, it frees any ino_entry_for_extents having no extent.
>
> IMO, we don't need to consider readahead for this, since get_data_block will
> be called by VFS readahead.
>
> Furthermore, we need to think about whether LRU is really best or not.
> IMO, the extent cache aims to improve second access speed, rather than initial
> cold misses. So, maybe MRU or another algorithms would be better.
>
Right. It's very comflicated to judge which is better.
In read or write path, extents could be made every time. At that time, we should
decide which extent evicts instead of new extents if we set upper bound.
In update, one extent could be seperated into 3. It requires 3 insertion and 1
deletion.
So if update happends frequently, we could give up extent management for some
ranges.
And we need to bring ideas from vm managemnt. For example,
active/inactive list and second chance to promotion, or batch work for
insertion/deletion
I thought suddenly 'Simple is best'.
Let's think about better ideas together.
> Thanks,
>
> >
> > 2) Limitation:
> > In one inode, as we split or add extent in extent cache when read/write,
> > extent
> > number will enlarge, so memory and CPU overhead will increase.
> > In order to control the overhead of memory and CPU, we try to set a upper
> > bound
> > number to limit total extent number in each inode, This number is global
> > configuration which is visable to all inode. This number will be exported to
> > sysfs for configuring according to requirement of user. By default, designed
> > number is 8.
> >
Chao,
It's better which # of extent are controlled globally rather than limit extents
per inode as Jaegeuk said to reduce extent management overhead.
> > 3) Shrinker:
> > There are two shrink paths:
> > a) one is triggered when extent count has exceed the upper bound of
> > inode's extent cache. We will try to release extent(s) from head of
> > inode's inner extent lru list until extent count is equal to upper
> > bound.
> > This operation could be in f2fs_update_extent_cache().
> > b) the other one is triggered
Re: [PATCH] mm/debug_pagealloc: remove obsolete Kconfig options
On Tue, 23 Dec 2014, Joonsoo Kim wrote:
> These are obsolete since commit e30825f1869a ("mm/debug-pagealloc:
> prepare boottime configurable on/off") is merged. Remove them.
>
> Reported-by: Paul Bolle
> Signed-off-by: Joonsoo Kim
Acked-by: David Rientjes
--
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.2 00/27] 3.2.66-rc1 review
At Mon, 29 Dec 2014 02:11:30 +0100, Ben Hutchings wrote: > > This is the start of the stable review cycle for the 3.2.66 release. > There are 27 patches in this series, which will be posted as responses > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Dec 31 12:00:00 UTC 2014. > Anything received after that time might be too late. This kernel passed my test. - Test Cases: - Build this kernel. - Boot this kernel. - Build the latest mainline kernel with this kernel. - Test Tool: https://github.com/satoru-takeuchi/test-linux-stable - Test Result (kernel .config, ktest config and test log): http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz - Build Environment: - OS: Debian Jessy x86_64 - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 - memory: 8GB - Test Target Environment: - Debian Jessy x86_64 (KVM guest on the Build Environment) - # of vCPU: 2 - memory: 2GB Thanks, Satoru > > A combined patch relative to 3.2.65 will be posted as an additional > response to this. A shortlog and diffstat can be found below. > > Ben. > > - > > Al Viro (2): > deal with deadlock in d_walk() > [ca5358ef75fc69fee5322a38a340f5739d997c10] > move d_rcu from overlapping d_child to overlapping d_alias > [946e51f2bf37f1656916eb75bd0742ba33983c28] > > Anatol Pomozov (1): > ext4: make orphan functions be no-op in no-journal mode > [c9b92530a723ac5ef8e352885a1862b18f31b2f5] > > Andy Lutomirski (2): > x86, kvm: Clear paravirt_enabled on KVM guests for espfix32's benefit > [29fa6825463c97e5157284db80107d1bfac5d77b] > x86/tls: Validate TLS entries to protect espfix > [41bdc78544b8a93a9c6814b8bbbfef966272abbe] > > Ard Biesheuvel (1): > crypto: ghash-clmulni-intel - use C implementation for setkey() > [8ceee72808d1ae3fb191284afc2257a2be964725] > > Ben Hutchings (2): > drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets > [5188cd44c55db3e92cd9e77a40b5baa7ed4340f7] > drivers/net: macvtap and tun depend on INET > [de11b0e8c569b96c2cf6a811e3805b7aeef498a3] > > Dan Carpenter (1): > [media] ttusb-dec: buffer overflow in ioctl > [f2e323ec96077642d397bb1c355def536d489d16] > > Daniel Borkmann (3): > net: sctp: fix NULL pointer dereference in af->from_addr_param on > malformed packet > [e40607cbe270a9e8360907cb1e62ddf0736e4864] > net: sctp: fix memory leak in auth key management > [4184b2a79a7612a9272ce20d639934584a1f3786] > net: sctp: use MAX_HEADER for headroom reserve in output path > [9772b54c55266ce80c639a80aa68eeb908f8ecf5] > > Daniel Vetter (1): > drm/i915: Unlock panel even when LVDS is disabled > [b0616c5306b342ceca07044dbc4f917d95c4f825] > > David Herrmann (1): > drm: fix DRM_IOCTL_MODE_GETFB handle-leak > [101b96f32956ee99bf1468afaf572b88cda9f88b] > > Devin Ryles (1): > AHCI: Add DeviceIDs for Sunrise Point-LP SATA controller > [249cd0a187ed4ef1d0af7f74362cc2791ec5581b] > > Dmitry Torokhov (1): > sata_fsl: fix error handling of irq_of_parse_and_map > [aad0b624129709c94c2e19e583b6053520353fa8] > > Eric Dumazet (2): > tcp: md5: do not use alloc_percpu() > [349ce993ac706869d553a1816426d3a4bfda02b1] > tcp: md5: remove spinlock usage in fast path > [71cea17ed39fdf1c0634f530ddc6a2c2fc601c2b] > > Grygorii Strashko (1): > i2c: davinci: generate STP always when NACK is received > [9ea359f7314132cbcb5a502d2d8ef095be1f45e4] > > Hugh Dickins (1): > mm: fix swapoff hang after page migration and fork > [2022b4d18a491a578218ce7a4eca8666db895a73] > > Jan Kara (1): > udf: Avoid infinite loop when processing indirect ICBs > [c03aa9f6e1f938618e6db2e23afef0574efeeb65] > > Jiri Pirko (1): > ipv4: fix nexthop attlen check in fib_nh_match > [f76936d07c4eeb36d8dbb64ebd30ab46ff85d9f7] > > Martin Schwidefsky (1): > s390,time: revert direct ktime path for s390 clockevent device > [8adbf78ec4839c1dc4ff20c9a1f332a7bc99e6e6] > > Nadav Amit (1): > KVM: x86: Don't report guest userspace emulation error to userspace > [a2b9e6c1a35afcc0973acb72e591c714e78885ff] > > Paolo Bonzini (1): > x86: kvm: use alternatives for VMCALL vs. VMMCALL if kernel text is > read-only > [c1118b3602c2329671ad5ec8bdf8e374323d6343] > > Tejun Heo (1): > ahci: disable MSI on SAMSUNG 0xa800 SSD > [2b21ef0aae65f22f5ba86b13c4588f6f0c2dbefb] > > Vasily Averin (1): > ipv4: dst_entry leak in ip_send_unicast_reply() > [4062090e3e5caaf55bed4523a69f26c3265cc1d2] > > Makefile | 4 +- > arch/powerpc/platforms/cell/spufs/inode.c | 4 +- > arch/s390/kernel/time.c|
[PATCH] crypto: sha-mb - Add avx2_supported check.
From: Vinson Lee This patch fixes this allyesconfig target build error with older binutils. LD arch/x86/crypto/built-in.o ld: arch/x86/crypto/sha-mb/built-in.o: No such file: No such file or directory Cc: sta...@vger.kernel.org # 3.18+ Signed-off-by: Vinson Lee --- arch/x86/crypto/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/crypto/Makefile b/arch/x86/crypto/Makefile index fd0f848..5a4a089 100644 --- a/arch/x86/crypto/Makefile +++ b/arch/x86/crypto/Makefile @@ -26,7 +26,6 @@ obj-$(CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL) += ghash-clmulni-intel.o obj-$(CONFIG_CRYPTO_CRC32C_INTEL) += crc32c-intel.o obj-$(CONFIG_CRYPTO_SHA1_SSSE3) += sha1-ssse3.o -obj-$(CONFIG_CRYPTO_SHA1_MB) += sha-mb/ obj-$(CONFIG_CRYPTO_CRC32_PCLMUL) += crc32-pclmul.o obj-$(CONFIG_CRYPTO_SHA256_SSSE3) += sha256-ssse3.o obj-$(CONFIG_CRYPTO_SHA512_SSSE3) += sha512-ssse3.o @@ -46,6 +45,7 @@ endif ifeq ($(avx2_supported),yes) obj-$(CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64) += camellia-aesni-avx2.o obj-$(CONFIG_CRYPTO_SERPENT_AVX2_X86_64) += serpent-avx2.o + obj-$(CONFIG_CRYPTO_SHA1_MB) += sha-mb/ endif aes-i586-y := aes-i586-asm_32.o aes_glue.o -- 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/
[PATCH] ASoC: fsl_esai: Fix incorrect xDC field width of xCCR registers
The xDC field should have 5 bit width according to Reference Manual. Thus this patch fixes it. Signed-off-by: Aurelien BOUIN Signed-off-by: Nicolin Chen --- The patch was originally submitted by Aurelien BOUIN while in an informal way. And he hasn't finished any re-submitting during the past two weeks. Thus I create a new patch with his signed-off included so as to fix the probelm as soon as possible, not sure whether it's decent or not though. --Nicolin sound/soc/fsl/fsl_esai.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/fsl/fsl_esai.h b/sound/soc/fsl/fsl_esai.h index 91a550f..5e793bb 100644 --- a/sound/soc/fsl/fsl_esai.h +++ b/sound/soc/fsl/fsl_esai.h @@ -302,7 +302,7 @@ #define ESAI_xCCR_xFP_MASK (((1 << ESAI_xCCR_xFP_WIDTH) - 1) << ESAI_xCCR_xFP_SHIFT) #define ESAI_xCCR_xFP(v) v) - 1) << ESAI_xCCR_xFP_SHIFT) & ESAI_xCCR_xFP_MASK) #define ESAI_xCCR_xDC_SHIFT 9 -#define ESAI_xCCR_xDC_WIDTH4 +#define ESAI_xCCR_xDC_WIDTH5 #define ESAI_xCCR_xDC_MASK (((1 << ESAI_xCCR_xDC_WIDTH) - 1) << ESAI_xCCR_xDC_SHIFT) #define ESAI_xCCR_xDC(v) v) - 1) << ESAI_xCCR_xDC_SHIFT) & ESAI_xCCR_xDC_MASK) #define ESAI_xCCR_xPSR_SHIFT 8 -- 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 3.13 106/162] KVM: x86: Fix far-jump to non-canonical check
On Thu, Nov 6, 2014 at 2:36 PM, Kamal Mostafa wrote:
> 3.13.11.11 -stable review patch. If anyone has any objections, please let me
> know.
>
> --
>
> From: Nadav Amit
>
> commit 7e466f6cd5dbf3c7bd04a7e75d19475ac9f2 upstream.
>
> Commit d1442d85cc30 ("KVM: x86: Handle errors when RIP is set during far
> jumps") introduced a bug that caused the fix to be incomplete. Due to
> incorrect evaluation, far jump to segment with L bit cleared (i.e., 32-bit
> segment) and RIP with any of the high bits set (i.e, RIP[63:32] != 0) set may
> not trigger #GP. As we know, this imposes a security problem.
>
> In addition, the condition for two warnings was incorrect.
>
> Fixes: d1442d85cc30ea75f7d399474ca738e0bc96f715
> Reported-by: Dan Carpenter
> Signed-off-by: Nadav Amit
> [Add #ifdef CONFIG_X86_64 to avoid complaints of undefined behavior. - Paolo]
> Signed-off-by: Paolo Bonzini
> [ kamal: backport to 3.13-stable: omitted WARN_ON fixes (not in 3.13) ]
> Signed-off-by: Kamal Mostafa
> ---
> arch/x86/kvm/emulate.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
> index a440bea..4ae37e7 100644
> --- a/arch/x86/kvm/emulate.c
> +++ b/arch/x86/kvm/emulate.c
> @@ -581,12 +581,14 @@ static inline int assign_eip_far(struct
> x86_emulate_ctxt *ctxt, ulong dst,
> case 4:
> ctxt->_eip = (u32)dst;
> break;
> +#ifdef CONFIG_X86_64
> case 8:
> if ((cs_l && is_noncanonical_address(dst)) ||
> - (!cs_l && (dst & ~(u32)-1)))
> + (!cs_l && (dst >> 32) != 0))
> return emulate_gp(ctxt, 0);
> ctxt->_eip = dst;
> break;
> +#endif
> default:
> WARN(1, "unsupported eip assignment size\n");
> }
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi.
Should the WARN_ON fixes have been included as well in 3.13.11.11?
WARN_ON hunks were added with the backport of "KVM: x86: Handle errors
when RIP is set during far jumps" in 3.13.11.11 commit
b8ba339d86fb627d54fea929492114d45f6835c2.
Cheers,
Vinson
--
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 09/11 linux-next] [media] uvcvideo: remove unnecessary version.h inclusion
Hi Fabian, Thank you for the patch. On Monday 29 December 2014 15:29:43 Fabian Frederick wrote: > Based on versioncheck. > > Signed-off-by: Fabian Frederick Acked-by: Laurent Pinchart Should I take the patch in my tree or do you plan to send a pull request for the whole series elsewhere ? > --- > drivers/media/usb/uvc/uvc_v4l2.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/media/usb/uvc/uvc_v4l2.c > b/drivers/media/usb/uvc/uvc_v4l2.c index 9c5cbcf..43e953f 100644 > --- a/drivers/media/usb/uvc/uvc_v4l2.c > +++ b/drivers/media/usb/uvc/uvc_v4l2.c > @@ -13,7 +13,6 @@ > > #include > #include > -#include > #include > #include > #include -- Regards, Laurent Pinchart -- 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 04/12] irqchip: nvic: increase number of external interrupts to 112
So far, only vectors for up to 48 external interrupts have been
allocated in the vector table. The first 16 vectors of the vector
table are reserved for internal exceptions (Reset, SVC...). The
external interrupts start at offset 16. Hence, by increasing the
vector table to 128 vectors, we increase the amount of vectors
reserved for external interrupts to 112. Also, only register the
amount of IRQ's we have vectors available for.
Note: the vector table must align to the number of entries in the
vector table, hence increase the alignment to 0x200.
Signed-off-by: Stefan Agner
---
When I started developing, I added UART0 with IRQ 61 to the device
tree. The framework happily accepted that, even though only 48
vectors for external interrupts were available. This was the
initial reason I added the WARN (in v1). However, when thinking
about it, just registering the amount of IRQ's actually supported
according to the vector table makes much more sense, since this
would warn the user on the offending IRQ's request call...
arch/arm/kernel/entry-v7m.S | 8
drivers/irqchip/irq-nvic.c | 9 +
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/arch/arm/kernel/entry-v7m.S b/arch/arm/kernel/entry-v7m.S
index 2260f18..c38a5e5 100644
--- a/arch/arm/kernel/entry-v7m.S
+++ b/arch/arm/kernel/entry-v7m.S
@@ -115,9 +115,9 @@ ENTRY(__switch_to)
ENDPROC(__switch_to)
.data
- .align 8
+ .align 9
/*
- * Vector table (64 words => 256 bytes natural alignment)
+ * Vector table (128 words => 512 bytes natural alignment)
*/
ENTRY(vector_table)
.long 0 @ 0 - Reset stack pointer
@@ -136,6 +136,6 @@ ENTRY(vector_table)
.long __invalid_entry @ 13 - Reserved
.long __pendsv_entry @ 14 - PendSV
.long __invalid_entry @ 15 - SysTick
- .rept 64 - 16
- .long __irq_entry @ 16..64 - External Interrupts
+ .rept 128 - 16
+ .long __irq_entry @ 16..128 - External Interrupts
.endr
diff --git a/drivers/irqchip/irq-nvic.c b/drivers/irqchip/irq-nvic.c
index 5fac910..740cc55 100644
--- a/drivers/irqchip/irq-nvic.c
+++ b/drivers/irqchip/irq-nvic.c
@@ -38,6 +38,11 @@
* 16 irqs.
*/
#define NVIC_MAX_IRQ ((NVIC_MAX_BANKS - 1) * 32 + 16)
+/*
+ * Number of IRQ's supported is limited by the size of the vector table
+ * defined in entry-v7m.S
+ */
+#define NVIC_MAX_IRQ_VECTORS (128 - 16)
static struct irq_domain *nvic_irq_domain;
@@ -46,6 +51,8 @@ nvic_handle_irq(irq_hw_number_t hwirq, struct pt_regs *regs)
{
unsigned int irq = irq_linear_revmap(nvic_irq_domain, hwirq);
+ BUG_ON(hwirq >= NVIC_MAX_IRQ_VECTORS);
+
handle_IRQ(irq, regs);
}
@@ -93,6 +100,8 @@ static int __init nvic_of_init(struct device_node *node,
irqs = numbanks * 32;
if (irqs > NVIC_MAX_IRQ)
irqs = NVIC_MAX_IRQ;
+ if (irqs > NVIC_MAX_IRQ_VECTORS)
+ irqs = NVIC_MAX_IRQ_VECTORS;
nvic_irq_domain =
irq_domain_add_linear(node, irqs, _irq_domain_ops, NULL);
--
2.2.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 v2 00/12] ARM: vf610m4: Add Vybrid Cortex-M4 support
This version of the patchset does not contain the interrupt router driver anymore (MSCM). The driver has been sent in a seperate patchset with GIC (Cortex-A5) support only: https://lkml.org/lkml/2014/12/16/454 This patchset extends the NVIC driver to support irq domain hierarchy and the MSCM driver to support NVIC as a parent irq controller. I'm happy with the outcome of the MSCM driver, the irq domain hierarchy support has proven to work with GIC and NVIC as intendet. This version also does not add any new architecture or SoC anymore. Instead, it allows to select ARCH_MULTIPLATFORM in the !MMU case and add ARCH_MULTI_V7M as a new CPU choice. This change is based on patches found in Arnd's git tree, however, it tries to allow MULTIPLATFORM with !MMU in a way which should not allow to make other selections than before (except ARCH_MULTI_V7M of course). This makes ARCH_MXC and SOC_VF610 available for the !MMU CPU V7M. With a small change, SOC_VF610 is now useable for the Cortex-M4 CPU too. The patchset has proven to be working on the Cortex-A5 as well as on the Cortex-M4 of the Vybrid SoC. Changes since v1: - Remove MSCM driver - Support irq domain hierarchy with NVIC irq controller - Extend MSCM interrupt router with NVIC as parent in the irq domain hierarchy - Rebased on v3.19-rc1 with MSCM driver - NVIC: Register only the amount of IRQ's which vectors are available for Changes since RFC: - Unified addruart calls for MMU/!MMU - Add MSCM support along with routable IRQ support in NVIC - Rebased on Shawns for-next tree which made some changes obsolete (mainly the Vybrid SoC device tree files in for-next are already prepared for Cortex-M4 support) - Removed SRC_GPR3 hack, this is now part of a mini boot-loader: https://github.com/falstaff84/vf610m4bootldr Arnd Bergmann (1): ARM: efm32: move into multiplatform Stefan Agner (11): genirq: generic chip: support hierarchy domain irqchip: nvic: support hierarchy irq domain irqchip: vf610-mscm: support NVIC parent irqchip: nvic: increase number of external interrupts to 112 clocksource: add dependencies for Vybrid pit clocksource ARM: unify MMU/!MMU addruart calls ARM: imx: depend MXC debug board on 3DS machines ARM: allow MULTIPLATFORM with !MMU ARM: vf610: enable Cortex-M4 on Vybrid SoC ARM: dts: add support for Vybrid running on Cortex-M4 ARM: vf610m4: add defconfig for Linux on Vybrids Cortex-M4 Documentation/devicetree/bindings/arm/fsl.txt | 3 ++ arch/arm/Kconfig | 56 +-- arch/arm/boot/dts/Makefile| 1 + arch/arm/boot/dts/vf610m4-colibri.dts | 52 + arch/arm/boot/dts/vf610m4.dtsi| 10 + arch/arm/configs/efm32_defconfig | 2 + arch/arm/configs/vf610m4_defconfig| 53 + arch/arm/include/debug/efm32.S| 2 +- arch/arm/kernel/debug.S | 2 +- arch/arm/kernel/entry-v7m.S | 8 ++-- arch/arm/mach-imx/Kconfig | 37 +++--- arch/arm/mach-imx/Makefile.boot | 0 arch/arm/mach-imx/mach-vf610.c| 1 + drivers/clocksource/Kconfig | 2 + drivers/irqchip/irq-nvic.c| 37 +- drivers/irqchip/irq-vf610-mscm.c | 31 --- kernel/irq/generic-chip.c | 5 +-- 17 files changed, 243 insertions(+), 59 deletions(-) create mode 100644 arch/arm/boot/dts/vf610m4-colibri.dts create mode 100644 arch/arm/boot/dts/vf610m4.dtsi create mode 100644 arch/arm/configs/vf610m4_defconfig create mode 100644 arch/arm/mach-imx/Makefile.boot -- 2.2.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 v2 06/12] ARM: unify MMU/!MMU addruart calls
Remove the needless differences between MMU/!MMU addruart calls. This allows to use the same addruart macro on SoC level. Useful for SoC consisting of multiple CPUs with and without MMU such as Freescale Vybrid. Signed-off-by: Stefan Agner --- arch/arm/include/debug/efm32.S | 2 +- arch/arm/kernel/debug.S| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/include/debug/efm32.S b/arch/arm/include/debug/efm32.S index 2265a19..660fa1e 100644 --- a/arch/arm/include/debug/efm32.S +++ b/arch/arm/include/debug/efm32.S @@ -16,7 +16,7 @@ #defineUARTn_TXDATA0x0034 - .macro addruart, rx, tmp + .macro addruart, rx, tmp, tmp2 ldr \rx, =(CONFIG_DEBUG_UART_PHYS) /* diff --git a/arch/arm/kernel/debug.S b/arch/arm/kernel/debug.S index 78c91b5..ea9646c 100644 --- a/arch/arm/kernel/debug.S +++ b/arch/arm/kernel/debug.S @@ -35,7 +35,7 @@ #else /* !CONFIG_MMU */ .macro addruart_current, rx, tmp1, tmp2 - addruart\rx, \tmp1 + addruart\rx, \tmp1, \tmp2 .endm #endif /* CONFIG_MMU */ -- 2.2.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 v2 12/12] ARM: vf610m4: add defconfig for Linux on Vybrids Cortex-M4
Add defconfig for Linux on Vybrid (vf610) on the secondary Cortex- M4 CPU. The use of a XIP image has been tested which needs to be loaded (e.g. using the custom m4boot loader) to the end of the available RAM at address 0x8f00. The Cortex-M4 has a code-alias which makes sure that the instructions get fetched through the code bus (alias starts at 0x0080 => 0x8080 in system address). Hence, to get optimal performance, use 0x0f00 as XIP_PHYS_ADDR. This address is additionally shifted by the length of the minimal loader which is inserted by m4boot. Currently, this offset is 0x80. The standard DRAM base address is configured to 0x8C00, which gives the Cortex-M4 48MiB of RAM. Signed-off-by: Stefan Agner --- arch/arm/configs/vf610m4_defconfig | 53 ++ 1 file changed, 53 insertions(+) create mode 100644 arch/arm/configs/vf610m4_defconfig diff --git a/arch/arm/configs/vf610m4_defconfig b/arch/arm/configs/vf610m4_defconfig new file mode 100644 index 000..392bc1d --- /dev/null +++ b/arch/arm/configs/vf610m4_defconfig @@ -0,0 +1,53 @@ +CONFIG_NAMESPACES=y +CONFIG_BLK_DEV_INITRD=y +# CONFIG_RD_BZIP2 is not set +# CONFIG_RD_LZMA is not set +# CONFIG_RD_XZ is not set +# CONFIG_RD_LZ4 is not set +# CONFIG_KALLSYMS is not set +CONFIG_EMBEDDED=y +# CONFIG_MMU is not set +CONFIG_ARCH_MULTI_V7M=y +CONFIG_ARCH_MXC=y +CONFIG_SOC_VF610=y +CONFIG_VF_USE_PIT_TIMER=y +CONFIG_SET_MEM_PARAM=y +CONFIG_DRAM_BASE=0x8c00 +CONFIG_FLASH_MEM_BASE=0x8f00 +CONFIG_FLASH_SIZE=0x0100 +CONFIG_CMDLINE="console=/dev/ttyLP2" +CONFIG_XIP_KERNEL=y +CONFIG_XIP_PHYS_ADDR=0x0f80 +CONFIG_BINFMT_FLAT=y +CONFIG_BINFMT_ZFLAT=y +CONFIG_BINFMT_SHARED_FLAT=y +# CONFIG_SUSPEND is not set +# CONFIG_UEVENT_HELPER is not set +# CONFIG_STANDALONE is not set +# CONFIG_PREVENT_FIRMWARE_BUILD is not set +# CONFIG_FIRMWARE_IN_KERNEL is not set +# CONFIG_ALLOW_DEV_COREDUMP is not set +CONFIG_BLK_DEV_RAM=y +CONFIG_BLK_DEV_RAM_COUNT=4 +CONFIG_BLK_DEV_XIP=y +# CONFIG_INPUT_MOUSEDEV is not set +# CONFIG_KEYBOARD_ATKBD is not set +CONFIG_KEYBOARD_GPIO=y +CONFIG_KEYBOARD_GPIO_POLLED=y +# CONFIG_INPUT_MOUSE is not set +# CONFIG_SERIO is not set +CONFIG_SERIAL_FSL_LPUART=y +CONFIG_SERIAL_FSL_LPUART_CONSOLE=y +# CONFIG_HW_RANDOM is not set +# CONFIG_HID is not set +# CONFIG_USB_SUPPORT is not set +CONFIG_MMC=y +CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_PLTFM=y +CONFIG_MMC_SDHCI_ESDHC_IMX=y +# CONFIG_IOMMU_SUPPORT is not set +CONFIG_EXT4_FS=y +# CONFIG_MISC_FILESYSTEMS is not set +CONFIG_DEBUG_MEMORY_INIT=y +# CONFIG_FTRACE is not set +# CONFIG_CRYPTO_HW is not set -- 2.2.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 v2 07/12] ARM: imx: depend MXC debug board on 3DS machines
Depend the MXC debug board on machines which actually support it. Signed-off-by: Stefan Agner --- This configuration appeared lonely when I enabled ARCH_MULTI_V7M. Afaik, the selection of it only makes sense with one of the supported boards... arch/arm/mach-imx/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 3c5859e..96c8eb8 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -21,6 +21,7 @@ config MXC_AVIC config MXC_DEBUG_BOARD bool "Enable MXC debug board(for 3-stack)" + depends on CONFIG_MACH_MX27_3DS || CONFIG_MACH_MX31_3DS || CONFIG_MACH_MX35_3DS help The debug board is an integral part of the MXC 3-stack(PDK) platforms, it can be attached or removed from the peripheral -- 2.2.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 v2 05/12] clocksource: add dependencies for Vybrid pit clocksource
Add the minimal dependencies required to use the Vybrid PIT clocksource driver. Those are not part of the SoC dependencies. Signed-off-by: Stefan Agner --- drivers/clocksource/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig index fc01ec2..a2eb7a2 100644 --- a/drivers/clocksource/Kconfig +++ b/drivers/clocksource/Kconfig @@ -154,6 +154,8 @@ config FSL_FTM_TIMER config VF_PIT_TIMER bool + select CLKSRC_MMIO + select CLKSRC_OF help Support for Period Interrupt Timer on Freescale Vybrid Family SoCs. -- 2.2.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] skein: checkpatch: trailing whitespace
This small patch will fix the trailing whitespace in
drivers/staging/skein/skein_generic.c.
After applying the patch, there will only remain the checkpatch warning:
WARNING: Single statement macros should not use a do {} while (0) loop
in files which are in the directory drivers/staging/skein/
Signed-off-by: Andreas Siegling
Signed-off-by: Zhutao Lu
---
drivers/staging/skein/skein_generic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/skein/skein_generic.c
b/drivers/staging/skein/skein_generic.c
index 85bd7d0..4eaae1d 100644
--- a/drivers/staging/skein/skein_generic.c
+++ b/drivers/staging/skein/skein_generic.c
@@ -191,7 +191,7 @@ static int __init skein_generic_init(void)
return 0;
-
+
unreg512:
crypto_unregister_shash();
unreg256:
--
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 v2 11/12] ARM: dts: add support for Vybrid running on Cortex-M4
This adds an initial device tree to run Linux on the Cortex-M4 on
the Vybrid based Colibri VF61.
Signed-off-by: Stefan Agner
---
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/vf610m4-colibri.dts | 52 +++
arch/arm/boot/dts/vf610m4.dtsi| 10 +++
3 files changed, 63 insertions(+)
create mode 100644 arch/arm/boot/dts/vf610m4-colibri.dts
create mode 100644 arch/arm/boot/dts/vf610m4.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 91bd5bd..4211dfb 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -271,6 +271,7 @@ dtb-$(CONFIG_ARCH_MXC) += \
ls1021a-twr.dtb \
vf500-colibri-eval-v3.dtb \
vf610-colibri-eval-v3.dtb \
+ vf610m4-colibri.dtb \
vf610-cosmic.dtb \
vf610-twr.dtb
dtb-$(CONFIG_ARCH_MXS) += imx23-evk.dtb \
diff --git a/arch/arm/boot/dts/vf610m4-colibri.dts
b/arch/arm/boot/dts/vf610m4-colibri.dts
new file mode 100644
index 000..ebff03e
--- /dev/null
+++ b/arch/arm/boot/dts/vf610m4-colibri.dts
@@ -0,0 +1,52 @@
+/*
+ * Device tree for Colibri VF61 Cortex-M4 support
+ *
+ * Copyright 2014 Stefan Agner
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+/dts-v1/;
+#include "vf610m4.dtsi"
+
+/ {
+ model = "VF610 Cortex-M4";
+ compatible = "fsl,vf610m4";
+
+ chosen {
+ bootargs = "console=ttyLP2,115200 clk_ignore_unused
init=/linuxrc rw";
+ };
+
+ memory {
+ reg = <0x8c00 0x300>;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_esdhc1>;
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ vf610-colibri {
+ pinctrl_esdhc1: esdhc1grp {
+ fsl,pins = <
+ VF610_PAD_PTA24__ESDHC1_CLK 0x31ef
+ VF610_PAD_PTA25__ESDHC1_CMD 0x31ef
+ VF610_PAD_PTA26__ESDHC1_DAT00x31ef
+ VF610_PAD_PTA27__ESDHC1_DAT10x31ef
+ VF610_PAD_PTA28__ESDHC1_DATA2 0x31ef
+ VF610_PAD_PTA29__ESDHC1_DAT30x31ef
+ VF610_PAD_PTB20__GPIO_420x219d
+ >;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/vf610m4.dtsi b/arch/arm/boot/dts/vf610m4.dtsi
new file mode 100644
index 000..3d8fa02
--- /dev/null
+++ b/arch/arm/boot/dts/vf610m4.dtsi
@@ -0,0 +1,10 @@
+/*
+ * Device tree for VF6xx Cortex-M4 support
+ */
+
+#include "armv7-m.dtsi"
+#include "vfxxx.dtsi"
+
+ {
+ interrupt-parent = <>;
+};
--
2.2.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 v2 09/12] ARM: efm32: move into multiplatform
From: Arnd Bergmann Since the multiplatform configuration can support no-MMU kernels now, there is nothing stopping us from moving the efm32 platform in there as well. This introduces a new ARCH_MULTI_V7M CPU architecture selection option, since v7-M is incompatible with v7-A, and we can have either of the two enabled for multiplatform, but not both at the same time. Signed-off-by: Arnd Bergmann Signed-off-by: Stefan Agner --- arch/arm/Kconfig | 35 --- arch/arm/configs/efm32_defconfig | 2 ++ 2 files changed, 18 insertions(+), 19 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 95007b9..8fe035b 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -314,7 +314,7 @@ config ARCH_MULTIPLATFORM select COMMON_CLK select GENERIC_CLOCKEVENTS select MIGHT_HAVE_PCI - select MULTI_IRQ_HANDLER + select MULTI_IRQ_HANDLER if !ARCH_MULTI_V7M select SPARSE_IRQ select USE_OF @@ -400,24 +400,6 @@ config ARCH_EBSA110 Ethernet interface, two PCMCIA sockets, two serial ports and a parallel port. -config ARCH_EFM32 - bool "Energy Micro efm32" - depends on !MMU - select ARCH_REQUIRE_GPIOLIB - select ARM_NVIC - select AUTO_ZRELADDR - select CLKSRC_OF - select COMMON_CLK - select CPU_V7M - select GENERIC_CLOCKEVENTS - select NO_DMA - select NO_IOPORT_MAP - select SPARSE_IRQ - select USE_OF - help - Support for Energy Micro's (now Silicon Labs) efm32 Giant Gecko - processors. - config ARCH_EP93XX bool "EP93xx-based" select ARCH_HAS_HOLES_MEMORYMODEL @@ -778,6 +760,14 @@ menu "Multiple platform selection" comment "CPU Core family selection" +config ARCH_MULTI_V7M + bool "ARMv7-M based platforms (Cortex-M)" + depends on !MMU && !(ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7) + select CPU_V7M + select ARM_NVIC + select NO_DMA # for now + select NO_IOPORT_MAP # for now + config ARCH_MULTI_V4 bool "ARMv4 based platforms (FA526)" depends on !ARCH_MULTI_V6_V7 && MMU @@ -834,6 +824,13 @@ config ARCH_VIRT select ARM_PSCI select HAVE_ARM_ARCH_TIMER +config ARCH_EFM32 + bool "Energy Micro efm32" if ARCH_MULTI_V7M + depends on !MMU + help + Support for Energy Micro's (now Silicon Labs) efm32 Giant Gecko + processors. + # # This is sorted alphabetically by mach-* pathname. However, plat-* # Kconfigs may be included either alphabetically (according to the diff --git a/arch/arm/configs/efm32_defconfig b/arch/arm/configs/efm32_defconfig index f59fffb..7bd2486 100644 --- a/arch/arm/configs/efm32_defconfig +++ b/arch/arm/configs/efm32_defconfig @@ -16,6 +16,8 @@ CONFIG_EMBEDDED=y # CONFIG_IOSCHED_DEADLINE is not set # CONFIG_IOSCHED_CFQ is not set # CONFIG_MMU is not set +# CONFIG_ARCH_MULTI_V7 is not set +CONFIG_ARCH_MULTI_V7M=y CONFIG_ARCH_EFM32=y # CONFIG_KUSER_HELPERS is not set CONFIG_SET_MEM_PARAM=y -- 2.2.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 v2 10/12] ARM: vf610: enable Cortex-M4 on Vybrid SoC
This patch allows to build the Kernel for Vybrid (VF6xx) SoC
when ARMv7-M CPU is selected. The resulting image runs on the
secondary Cortex-M4 core. This core has equally access to all
peripherals as the main Cortex-A5 core. However, there is no
resource control mechanism, hence when both cores are used
simultaneously, orthogonal device tree's are required.
The boot CPU is dependent on the SoC variant, however the
commonly available boards use variants where the Cortex-A5 is
the primary/boot CPU. Booting the secondary Cortex-M4 CPU
needs SoC specific register written. There is no in kernel
support for this right now, a external userspace utility
called "m4boot" can be used to boot the kernel:
m4boot xipImage initramfs.cpio.lzo vf610m4-colibri.dtb
Signed-off-by: Stefan Agner
---
Documentation/devicetree/bindings/arm/fsl.txt | 3 +++
arch/arm/mach-imx/Kconfig | 36 +--
arch/arm/mach-imx/Makefile.boot | 0
arch/arm/mach-imx/mach-vf610.c| 1 +
4 files changed, 27 insertions(+), 13 deletions(-)
create mode 100644 arch/arm/mach-imx/Makefile.boot
diff --git a/Documentation/devicetree/bindings/arm/fsl.txt
b/Documentation/devicetree/bindings/arm/fsl.txt
index c830b5b..f396088 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -81,12 +81,15 @@ Freescale Vybrid Platform Device Tree Bindings
For the Vybrid SoC familiy all variants with DDR controller are supported,
which is the VF5xx and VF6xx series. Out of historical reasons, in most
places the kernel uses vf610 to refer to the whole familiy.
+The compatible string "fsl,vf610m4" is used for the secondary Cortex-M4
+core support.
Required root node compatible property (one of them):
- compatible = "fsl,vf500";
- compatible = "fsl,vf510";
- compatible = "fsl,vf600";
- compatible = "fsl,vf610";
+- compatible = "fsl,vf610m4";
Freescale LS1021A Platform Device Tree Bindings
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 96c8eb8..4f26942 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -1,5 +1,5 @@
menuconfig ARCH_MXC
- bool "Freescale i.MX family" if ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7
+ bool "Freescale i.MX family" if ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 ||
ARCH_MULTI_V7M
select ARCH_REQUIRE_GPIOLIB
select ARM_CPU_SUSPEND if PM
select CLKSRC_MMIO
@@ -558,9 +558,11 @@ config MACH_VPR200
endif
+comment "Device tree only"
+
if ARCH_MULTI_V7
-comment "Device tree only"
+comment "Cortex-A platforms"
config SOC_IMX5
bool
@@ -630,10 +632,28 @@ config SOC_IMX6SX
help
This enables support for Freescale i.MX6 SoloX processor.
+
+config SOC_LS1021A
+ bool "Freescale LS1021A support"
+ select ARM_GIC
+ select HAVE_ARM_ARCH_TIMER
+ select PCI_DOMAINS if PCI
+ select ZONE_DMA if ARM_LPAE
+
+ help
+ This enable support for Freescale LS1021A processor.
+
+endif
+
+comment "Cortex-A/Cortex-M asymmetric multiprocessing platforms"
+
+if ARCH_MULTI_V7 || ARCH_MULTI_V7M
+
config SOC_VF610
bool "Vybrid Family VF610 support"
select VF610_MSCM
- select ARM_GIC
+ select ARM_GIC if ARCH_MULTI_V7
+ select ARM_NVIC if ARCH_MULTI_V7M
select PINCTRL_VF610
select PL310_ERRATA_769419 if CACHE_L2X0
@@ -660,16 +680,6 @@ choice
endchoice
-config SOC_LS1021A
- bool "Freescale LS1021A support"
- select ARM_GIC
- select HAVE_ARM_ARCH_TIMER
- select PCI_DOMAINS if PCI
- select ZONE_DMA if ARM_LPAE
-
- help
- This enable support for Freescale LS1021A processor.
-
endif
source "arch/arm/mach-imx/devices/Kconfig"
diff --git a/arch/arm/mach-imx/Makefile.boot b/arch/arm/mach-imx/Makefile.boot
new file mode 100644
index 000..e69de29
diff --git a/arch/arm/mach-imx/mach-vf610.c b/arch/arm/mach-imx/mach-vf610.c
index 2e7c75b..b20f6c1 100644
--- a/arch/arm/mach-imx/mach-vf610.c
+++ b/arch/arm/mach-imx/mach-vf610.c
@@ -17,6 +17,7 @@ static const char * const vf610_dt_compat[] __initconst = {
"fsl,vf510",
"fsl,vf600",
"fsl,vf610",
+ "fsl,vf610m4",
NULL,
};
--
2.2.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 v2 01/12] genirq: generic chip: support hierarchy domain
Use the new helper function irq_domain_set_info to make sure the
function irq_domain_set_hwirq_and_chip is being called, which is
crucial to save irqdomain specific data to irq_data.
Signed-off-by: Stefan Agner
---
kernel/irq/generic-chip.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/kernel/irq/generic-chip.c b/kernel/irq/generic-chip.c
index 61024e8..15b370d 100644
--- a/kernel/irq/generic-chip.c
+++ b/kernel/irq/generic-chip.c
@@ -360,7 +360,7 @@ static struct lock_class_key irq_nested_lock_class;
int irq_map_generic_chip(struct irq_domain *d, unsigned int virq,
irq_hw_number_t hw_irq)
{
- struct irq_data *data = irq_get_irq_data(virq);
+ struct irq_data *data = irq_domain_get_irq_data(d, virq);
struct irq_domain_chip_generic *dgc = d->gc;
struct irq_chip_generic *gc;
struct irq_chip_type *ct;
@@ -405,8 +405,7 @@ int irq_map_generic_chip(struct irq_domain *d, unsigned int
virq,
else
data->mask = 1 << idx;
- irq_set_chip_and_handler(virq, chip, ct->handler);
- irq_set_chip_data(virq, gc);
+ irq_domain_set_info(d, virq, hw_irq, chip, gc, ct->handler, NULL, NULL);
irq_modify_status(virq, dgc->irq_flags_to_clear, dgc->irq_flags_to_set);
return 0;
}
--
2.2.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 v2 03/12] irqchip: vf610-mscm: support NVIC parent
Support the NVIC interrupt controller as node parent of the MSCM
interrupt router. On the dual-core variants of Vybird (VF6xx), the
NVIC interrupt controller is used by the Cortex-M4. To support
running Linux on this core too, MSCM needs NVIC parent support too.
Signed-off-by: Stefan Agner
---
drivers/irqchip/irq-vf610-mscm.c | 31 +--
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/irqchip/irq-vf610-mscm.c b/drivers/irqchip/irq-vf610-mscm.c
index 7a284d5..f4f7d78 100644
--- a/drivers/irqchip/irq-vf610-mscm.c
+++ b/drivers/irqchip/irq-vf610-mscm.c
@@ -30,6 +30,7 @@ struct vf610_mscm_chip_data {
void __iomem *mscm_base;
u16 cpu_mask;
u16 saved_irsprc[MSCM_IRSPRC_NUM];
+ bool is_nvic;
};
static struct vf610_mscm_chip_data *mscm_data;
@@ -74,6 +75,7 @@ static void vf610_mscm_enable(struct irq_data *data)
{
irq_hw_number_t hwirq = data->hwirq;
struct vf610_mscm_chip_data *chip_data = data->chip_data;
+ struct irq_data *parent = data->parent_data;
u16 irsprc;
irsprc = readw_relaxed(chip_data->mscm_base + MSCM_IRSPRC(hwirq));
@@ -84,17 +86,24 @@ static void vf610_mscm_enable(struct irq_data *data)
writew_relaxed(chip_data->cpu_mask,
chip_data->mscm_base + MSCM_IRSPRC(hwirq));
- irq_chip_unmask_parent(data);
+ if (parent->chip->irq_enable)
+ parent->chip->irq_enable(parent);
+ else
+ parent->chip->irq_unmask(parent);
}
static void vf610_mscm_disable(struct irq_data *data)
{
irq_hw_number_t hwirq = data->hwirq;
struct vf610_mscm_chip_data *chip_data = data->chip_data;
+ struct irq_data *parent = data->parent_data;
writew_relaxed(0x0, chip_data->mscm_base + MSCM_IRSPRC(hwirq));
- irq_chip_mask_parent(data);
+ if (parent->chip->irq_enable)
+ parent->chip->irq_disable(parent);
+ else
+ parent->chip->irq_mask(parent);
}
static struct irq_chip vf610_mscm_irq_chip = {
@@ -126,10 +135,17 @@ static int vf610_mscm_domain_alloc(struct irq_domain
*domain, unsigned int virq,
domain->host_data);
gic_data.np = domain->parent->of_node;
- gic_data.args_count = 3;
- gic_data.args[0] = GIC_SPI;
- gic_data.args[1] = irq_data->args[0];
- gic_data.args[2] = irq_data->args[1];
+
+ if (mscm_data->is_nvic) {
+ gic_data.args_count = 1;
+ gic_data.args[0] = irq_data->args[0];
+ } else {
+ gic_data.args_count = 3;
+ gic_data.args[0] = GIC_SPI;
+ gic_data.args[1] = irq_data->args[0];
+ gic_data.args[2] = irq_data->args[1];
+ }
+
return irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, _data);
}
@@ -171,6 +187,9 @@ static int __init vf610_mscm_of_init(struct device_node
*node,
goto out_unmap;
}
+ if (of_device_is_compatible(domain->parent->of_node, "arm,armv7m-nvic"))
+ mscm_data->is_nvic = true;
+
mscm_data->cpu_mask = 0x1 << readl_relaxed(mscm_data->mscm_base +
MSCM_CPxNUM);
cpu_pm_register_notifier(_notifier_block);
--
2.2.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 v2 02/12] irqchip: nvic: support hierarchy irq domain
Add support for hierarchy irq domain. Use to support the interrupt
router found in Vybrid SoC, which is between the NVIC and the
peripherals.
Signed-off-by: Stefan Agner
---
drivers/irqchip/irq-nvic.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-nvic.c b/drivers/irqchip/irq-nvic.c
index 4ff0805..5fac910 100644
--- a/drivers/irqchip/irq-nvic.c
+++ b/drivers/irqchip/irq-nvic.c
@@ -49,6 +49,31 @@ nvic_handle_irq(irq_hw_number_t hwirq, struct pt_regs *regs)
handle_IRQ(irq, regs);
}
+static int nvic_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
+ unsigned int nr_irqs, void *arg)
+{
+ int i, ret;
+ irq_hw_number_t hwirq;
+ unsigned int type = IRQ_TYPE_NONE;
+ struct of_phandle_args *irq_data = arg;
+
+ ret = irq_domain_xlate_onecell(domain, irq_data->np, irq_data->args,
+ irq_data->args_count, , );
+ if (ret)
+ return ret;
+
+ for (i = 0; i < nr_irqs; i++)
+ irq_map_generic_chip(domain, virq + i, hwirq + i);
+
+ return 0;
+}
+
+static const struct irq_domain_ops nvic_irq_domain_ops = {
+ .xlate = irq_domain_xlate_onecell,
+ .alloc = nvic_irq_domain_alloc,
+ .free = irq_domain_free_irqs_top,
+};
+
static int __init nvic_of_init(struct device_node *node,
struct device_node *parent)
{
@@ -70,7 +95,8 @@ static int __init nvic_of_init(struct device_node *node,
irqs = NVIC_MAX_IRQ;
nvic_irq_domain =
- irq_domain_add_linear(node, irqs, _generic_chip_ops, NULL);
+ irq_domain_add_linear(node, irqs, _irq_domain_ops, NULL);
+
if (!nvic_irq_domain) {
pr_warn("Failed to allocate irq domain\n");
return -ENOMEM;
--
2.2.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 v2 08/12] ARM: allow MULTIPLATFORM with !MMU
In order to support SoC with heterogenous CPU architectures (such as Freescale Vybrid/i.MXSX) it is preferable to use the same architecture (ARCH_MXC in this case) for the MMU enabled and !MMU CPU. Hence allow to select MULTIPLATFORM even without MMU. Signed-off-by: Stefan Agner --- arch/arm/Kconfig | 21 ++--- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 97d07ed..95007b9 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -228,7 +228,7 @@ config VECTORS_BASE in size. config ARM_PATCH_PHYS_VIRT - bool "Patch physical to virtual translations at runtime" if EMBEDDED + bool "Patch physical to virtual translations at runtime" if EMBEDDED || (ARCH_MULTIPLATFORM && MMU) default y depends on !XIP_KERNEL && MMU depends on !ARCH_REALVIEW || !SPARSEMEM @@ -303,15 +303,12 @@ config MMU # choice prompt "ARM system type" - default ARCH_VERSATILE if !MMU - default ARCH_MULTIPLATFORM if MMU + default ARCH_MULTIPLATFORM config ARCH_MULTIPLATFORM bool "Allow multiple platforms to be selected" - depends on MMU select ARCH_WANT_OPTIONAL_GPIOLIB select ARM_HAS_SG_CHAIN - select ARM_PATCH_PHYS_VIRT select AUTO_ZRELADDR select CLKSRC_OF select COMMON_CLK @@ -783,13 +780,13 @@ comment "CPU Core family selection" config ARCH_MULTI_V4 bool "ARMv4 based platforms (FA526)" - depends on !ARCH_MULTI_V6_V7 + depends on !ARCH_MULTI_V6_V7 && MMU select ARCH_MULTI_V4_V5 select CPU_FA526 config ARCH_MULTI_V4T bool "ARMv4T based platforms (ARM720T, ARM920T, ...)" - depends on !ARCH_MULTI_V6_V7 + depends on !ARCH_MULTI_V6_V7 && MMU select ARCH_MULTI_V4_V5 select CPU_ARM920T if !(CPU_ARM7TDMI || CPU_ARM720T || \ CPU_ARM740T || CPU_ARM9TDMI || CPU_ARM922T || \ @@ -797,7 +794,7 @@ config ARCH_MULTI_V4T config ARCH_MULTI_V5 bool "ARMv5 based platforms (ARM926T, XSCALE, PJ1, ...)" - depends on !ARCH_MULTI_V6_V7 + depends on !ARCH_MULTI_V6_V7 && MMU select ARCH_MULTI_V4_V5 select CPU_ARM926T if !(CPU_ARM946E || CPU_ARM1020 || \ CPU_ARM1020E || CPU_ARM1022 || CPU_ARM1026 || \ @@ -808,11 +805,13 @@ config ARCH_MULTI_V4_V5 config ARCH_MULTI_V6 bool "ARMv6 based platforms (ARM11)" + depends on MMU select ARCH_MULTI_V6_V7 select CPU_V6K config ARCH_MULTI_V7 - bool "ARMv7 based platforms (Cortex-A, PJ4, Scorpion, Krait)" + bool "ARMv7-A based platforms (Cortex-A, PJ4, Scorpion, Krait)" + depends on MMU default y select ARCH_MULTI_V6_V7 select CPU_V7 @@ -823,7 +822,7 @@ config ARCH_MULTI_V6_V7 select MIGHT_HAVE_CACHE_L2X0 config ARCH_MULTI_CPU_AUTO - def_bool !(ARCH_MULTI_V4 || ARCH_MULTI_V4T || ARCH_MULTI_V6_V7) + def_bool !(ARCH_MULTI_V4 || ARCH_MULTI_V4T || ARCH_MULTI_V6_V7) && MMU select ARCH_MULTI_V5 endmenu @@ -1960,7 +1959,7 @@ endchoice config XIP_KERNEL bool "Kernel Execute-In-Place from ROM" - depends on !ARM_LPAE && !ARCH_MULTIPLATFORM + depends on !ARM_LPAE && (!ARCH_MULTIPLATFORM || ARCH_MULTI_V7M) help Execute-In-Place allows the kernel to run from non-volatile storage directly addressable by the CPU, such as NOR flash. This saves RAM -- 2.2.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/
Another SCHED_DEADLINE bug (with bisection and possible fix)
Hi all,
when running some experiments on current git master, I noticed a
regression respect to version 3.18 of the kernel: when invoking
sched_setattr() to change the SCHED_DEADLINE parameters of a task that
is already scheduled by SCHED_DEADLINE, it is possible to crash the
system.
The bug can be reproduced with this testcase:
http://disi.unitn.it/~abeni/reclaiming/bug-test.tgz
Uncompress it, enter the "Bug-Test" directory, and type "make test".
After few cycles, my test machine (a laptop with an intel i7 CPU)
becomes unusable, and freezes.
Since I know that 3.18 is not affected by this bug, I tried a bisect,
that pointed to commit 67dfa1b756f250972bde31d65e3f8fde6aeddc5b
(sched/deadline: Implement cancel_dl_timer() to use in
switched_from_dl()).
By looking at that commit, I suspect the problem is that it removes the
following lines from init_dl_task_timer():
- if (hrtimer_active(timer)) {
- hrtimer_try_to_cancel(timer);
- return;
- }
As a result, when changing the parameters of a SCHED_DEADLINE task
init_dl_task_timer() is invoked again, and it can initialize a pending
timer (not sure why, but this seems to be the cause of the freezes I am
seeing).
So, I modified core.c::__setparam_dl() to invoke init_dl_task_timer()
only if the task is not already scheduled by SCHED_DEADLINE...
Basically, I changed
init_dl_task_timer(dl_se);
into
if (p->sched_class != _sched_class) {
init_dl_task_timer(dl_se);
}
I am not sure if this is the correct fix, but with this change the
kernel survives my test script (mentioned above), and arrives to 500
cycles (without my patch, it crashes after 2 or 3 cycles).
What do you think? Is my patch correct, or should I fix the issue in a
different way?
Thanks,
Luca
--
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] srcu: Isolate srcu sections using CONFIG_SRCU
On Sat, 2014-12-27 at 12:17 -0500, Pranith Kumar wrote: > Isolate the SRCU functions and data structures within CONFIG_SRCU so that > there > is a compile time failure if srcu is used when not enabled. This was decided > to > be better than waiting until link time for a failure to occur. Yes, false positives and extra ifdefs are so much better. :-P Why not just ifdef the functions/macros, and leave the types alone? If you're worried about direct access to struct members, you could even ifdef the members away while leaving the struct itself. It is not normal practice in Linux to need ifdefs around #includes. > There are places which include kvm headers and utilize kvm data structures > without checking if KVM is enabled. In two such archs(s390, ppc64), the > current > patch makes the uses of KVM conditional on KVM being enabled. The other > option, > which is to enable KVM unconditionally seemed a bit too much as we could > easily > figure out KVM only parts and enclose them in ifdefs. Maybe not so easy (mpc85xx_smp_defconfig with NOTIFY stuff turned off so that SRCU gets deselected): In file included from /home/scott/fsl/git/linux/upstream/arch/powerpc/include/asm/kvm_ppc.h:30:0, from /home/scott/fsl/git/linux/upstream/arch/powerpc/kernel/smp.c:39: /home/scott/fsl/git/linux/upstream/include/linux/kvm_host.h:366:21: error: field 'srcu' has incomplete type /home/scott/fsl/git/linux/upstream/include/linux/kvm_host.h:367:21: error: field 'irq_srcu' has incomplete type /home/scott/fsl/git/linux/upstream/scripts/Makefile.build:257: recipe for target 'arch/powerpc/kernel/smp.o' failed make[2]: *** [arch/powerpc/kernel/smp.o] Error 1 /home/scott/fsl/git/linux/upstream/Makefile:955: recipe for target 'arch/powerpc/kernel' failed make[1]: *** [arch/powerpc/kernel] Error 2 make[1]: *** Waiting for unfinished jobs Are you sure KVM is the only SRCU user so impacted? It's also likely that new such problems get introduced, because most people are going to have SRCU enabled and thus not notice the breakage they're adding. There's also at least one place that needs to be fixed, that currently expects to get other headers indirectly via srcu.h: /home/scott/fsl/git/linux/upstream/lib/assoc_array.c: In function 'assoc_array_apply_edit': /home/scott/fsl/git/linux/upstream/lib/assoc_array.c:1425:2: error: implicit declaration of function 'call_rcu' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors /home/scott/fsl/git/linux/upstream/scripts/Makefile.build:257: recipe for target 'lib/assoc_array.o' failed -Scott -- 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/
