Re: [PATCH] drm/i915/tv: clear adjusted_mode.flags
Hi Daniel!
This patch is definitely needed for 3.12, but it is still missing in 3.12-rc2
...
cu,
Knut
On 10.09.2013 11:44, Daniel Vetter wrote:
The native TV encoder has it's own flags to adjust sync modes and
enabled interlaced modes which are totally irrelevant for the adjusted
mode. This worked out nicely since the input modes used by both the
load detect code and reported in the ->get_modes callbacks all have no
flags set, and we also don't fill out any of them in the ->get_config
callback.
This changed with the additional sanitation done with
commit 2960bc9cceecb5d556ce1c07656a6609e2f7e8b0
Author: Imre Deak
Date: Tue Jul 30 13:36:32 2013 +0300
drm/i915: make user mode sync polarity setting explicit
sinc now the "no flags at all" state wouldn't fit through core code
any more. So fix this up again by explicitly clearing the flags in the
->compute_config callback.
Aside: We have zero checking in place to make sure that the requested
mode is indeed the right input mode we want for the selected TV mode.
So we'll happily fall over if userspace tries to pull us. But that's
definitely work for a different patch series. So just add a FIXME
comment for now.
Reported-by: Knut Petersen
Cc: Knut Petersen
Cc: Imre Deak
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_tv.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index f2c6d79..dd6f84b 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -916,6 +916,14 @@ intel_tv_compute_config(struct intel_encoder *encoder,
DRM_DEBUG_KMS("forcing bpc to 8 for TV\n");
pipe_config->pipe_bpp = 8*3;
+ /* TV has it's own notion of sync and other mode flags, so clear them. */
+ pipe_config->adjusted_mode.flags = 0;
+
+ /*
+* FIXME: We don't check whether the input mode is actually what we want
+* or whether userspace is doing something stupid.
+*/
+
return true;
}
--
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] powerpc/irq: Run softirqs off the top of the irq stack
Nowadays, irq_exit() calls __do_softirq() pretty much directly
instead of calling do_softirq() which switches to the decicated
softirq stack.
This has lead to observed stack overflows on powerpc since we call
irq_enter() and irq_exit() outside of the scope that switches to
the irq stack.
This fixes it by moving the stack switching up a level, making
irq_enter() and irq_exit() run off the irq stack.
Signed-off-by: Benjamin Herrenschmidt
v2: Garbage collect now empty handle_one_irq()
---
arch/powerpc/include/asm/irq.h | 4 +-
arch/powerpc/kernel/irq.c | 104 -
arch/powerpc/kernel/misc_32.S | 9 ++--
arch/powerpc/kernel/misc_64.S | 10 ++--
4 files changed, 62 insertions(+), 65 deletions(-)
diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h
index 0e40843..41f13ce 100644
--- a/arch/powerpc/include/asm/irq.h
+++ b/arch/powerpc/include/asm/irq.h
@@ -69,9 +69,9 @@ extern struct thread_info *softirq_ctx[NR_CPUS];
extern void irq_ctx_init(void);
extern void call_do_softirq(struct thread_info *tp);
-extern int call_handle_irq(int irq, void *p1,
- struct thread_info *tp, void *func);
+extern void call_do_irq(struct pt_regs *regs, struct thread_info *tp);
extern void do_IRQ(struct pt_regs *regs);
+extern void __do_irq(struct pt_regs *regs);
int irq_choose_cpu(const struct cpumask *mask);
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index c69440c..2234a12 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -441,50 +441,6 @@ void migrate_irqs(void)
}
#endif
-static inline void handle_one_irq(unsigned int irq)
-{
- struct thread_info *curtp, *irqtp;
- unsigned long saved_sp_limit;
- struct irq_desc *desc;
-
- desc = irq_to_desc(irq);
- if (!desc)
- return;
-
- /* Switch to the irq stack to handle this */
- curtp = current_thread_info();
- irqtp = hardirq_ctx[smp_processor_id()];
-
- if (curtp == irqtp) {
- /* We're already on the irq stack, just handle it */
- desc->handle_irq(irq, desc);
- return;
- }
-
- saved_sp_limit = current->thread.ksp_limit;
-
- irqtp->task = curtp->task;
- irqtp->flags = 0;
-
- /* Copy the softirq bits in preempt_count so that the
-* softirq checks work in the hardirq context. */
- irqtp->preempt_count = (irqtp->preempt_count & ~SOFTIRQ_MASK) |
- (curtp->preempt_count & SOFTIRQ_MASK);
-
- current->thread.ksp_limit = (unsigned long)irqtp +
- _ALIGN_UP(sizeof(struct thread_info), 16);
-
- call_handle_irq(irq, desc, irqtp, desc->handle_irq);
- current->thread.ksp_limit = saved_sp_limit;
- irqtp->task = NULL;
-
- /* Set any flag that may have been set on the
-* alternate stack
-*/
- if (irqtp->flags)
- set_bits(irqtp->flags, >flags);
-}
-
static inline void check_stack_overflow(void)
{
#ifdef CONFIG_DEBUG_STACKOVERFLOW
@@ -501,9 +457,9 @@ static inline void check_stack_overflow(void)
#endif
}
-void do_IRQ(struct pt_regs *regs)
+void __do_irq(struct pt_regs *regs)
{
- struct pt_regs *old_regs = set_irq_regs(regs);
+ struct irq_desc *desc;
unsigned int irq;
irq_enter();
@@ -519,18 +475,64 @@ void do_IRQ(struct pt_regs *regs)
*/
irq = ppc_md.get_irq();
- /* We can hard enable interrupts now */
+ /* We can hard enable interrupts now to allow perf interrupts */
may_hard_irq_enable();
/* And finally process it */
- if (irq != NO_IRQ)
- handle_one_irq(irq);
- else
+ if (unlikely(irq == NO_IRQ))
__get_cpu_var(irq_stat).spurious_irqs++;
+ else {
+ desc = irq_to_desc(irq);
+ if (likely(desc))
+ desc->handle_irq(irq, desc);
+ }
trace_irq_exit(regs);
irq_exit();
+}
+
+void do_IRQ(struct pt_regs *regs)
+{
+ struct pt_regs *old_regs = set_irq_regs(regs);
+ struct thread_info *curtp, *irqtp;
+ unsigned long saved_sp_limit;
+
+ /* Switch to the irq stack to handle this */
+ curtp = current_thread_info();
+ irqtp = hardirq_ctx[raw_smp_processor_id()];
+
+ /* Already there ? */
+ if (unlikely(curtp == irqtp)) {
+ __do_irq(regs);
+ set_irq_regs(old_regs);
+ return;
+ }
+
+ /* Adjust the stack limit */
+ saved_sp_limit = current->thread.ksp_limit;
+ current->thread.ksp_limit = (unsigned long)irqtp +
+ _ALIGN_UP(sizeof(struct thread_info), 16);
+
+
+ /* Prepare the thread_info in the irq stack */
+ irqtp->task = curtp->task;
+ irqtp->flags = 0;
+
+ /* Copy the preempt_count so that the [soft]irq checks work. */
+
Re: [RFC] gpio/omap: auto-setup a GPIO when used as an IRQ
On 09/23/2013 10:15 PM, Linus Walleij wrote: > On Sun, Sep 22, 2013 at 4:40 PM, Javier Martinez Canillas > wrote: > >> To use a GPIO pin as an interrupt line, two previous configurations >> have to be made: >> >> a) Map the GPIO pin as an interrupt line into the Linux irq space >> b) Enable the GPIO bank and configure the GPIO direction as input >> >> Most GPIO/IRQ chip drivers just create a mapping for every single >> GPIO pin with irq_create_mapping() on .probe so users usually can >> assume a) and only have to do b) by using the following sequence: >> >> gpio_request(gpio, "foo IRQ"); >> gpio_direction_input(gpio); >> >> and then request a IRQ with: >> >> irq = gpio_to_irq(gpio); >> request_irq(irq, ...); > > I guess I have to live with this approach, but I'd like to - if possible - > address my pet issue. > > - It is OK that the HW get set up as GPIO input by the IRQ > request function alone. (Through gpio_irq_type I guess). > Yes, this is how is made on this patch indeed. > - When a second caller calls omap_gpio_request() it should > be OK as well, but only if the flags corresponds to the > previously enabled input mode. Else it should be > disallowed. > > - The same should happen for _set_gpio_direction() if a pin > previously set up for IRQ gets a request to be used as > output. > > If this cannot be tracked in the driver, it is certainly a candidate > for something that gpiolib should be doing. And then I'm open to > solutions to how we can do that. > Ok, this can be tracked in the driver, will add it when posting v2 soon. > If this needs to be applied pronto to fix the regression I'm > happy with that too, if we add a big boilerplate stating the above > problem and that it needs to be *fixed* at some point. > > But in either case I want this to be tested on OMAP1 before > I apply it, as in a Tested-by tag. > Agreed. Even though this is a fix for a long standing issue I prefer it to be tested extensively than applying the patch in a rush just to learn that causes regressions and have to be reverted as it happens last time. So as you said let's wait until we have a few Tested-by tags by people using different OMAP platforms specially OMAP1. > Yours, > Linus Walleij > Thanks a lot and best regards, Javier -- 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] EFI: Runtime services virtual mapping
On 09/24/13 at 12:58pm, Dave Young wrote:
> On 09/24/13 at 12:57pm, Dave Young wrote:
> > On 09/23/13 at 08:06pm, H. Peter Anvin wrote:
> > > Okay... I see two problems.
> > >
> > > 1. It looks like we subtract the region size after, rather than before,
> > > assigning an address.
Could you explain more about this problem? Where is the code?
> > >
> > > 2. The second region is assigned the same address in the secondary kernel
> > > as in the first, implying the size of the first region was somehow set to
> > > zero.
> >
> > I find the reason, efi_reserve_boot_services will reserve the
> > BOOT_SERVICE_DATA region
> > thus the memmap size is changed to 0, so in 2nd kernel the virtual mapping
> > addr after
> > the md will be not same as 1st kernel, see below code:
> >
> > void __init efi_map_region(efi_memory_desc_t *md)
> > {
> > unsigned long size = md->num_pages << PAGE_SHIFT;
> >
> > efi_va -= size;
> > ^^^
> > [snip]
> > }
>
> So how about just reserve BOOT_SERVICE_DATA region but keep the md.numpages
> as is?
Hmm, num_pages = 0 is only set when boot service region reservation is
imporsible, I'm
lost.. But there must be somewhere set the size to 0.
>
> >
> >
> > >
> > > Dave Young wrote:
> > > >On 09/22/13 at 08:27am, H. Peter Anvin wrote:
> > > >> The address that faults is interesting in that it is indeed just
> > > >below -4G. The question at hand is probably what information you are
> > > >using to build the EFI mappings in the secondary kernel and what could
> > > >make it not match the primary.
> > > >>
> > > >> Assuming it isn't as simple as the mappings never get built at all.
> > > >
> > > >Here is my debug output, diff efi-mapping-1st-kernel
> > > >efi-mapping-2nd-kernel:
> > > >Obviously, the high address mapping is not same:
> > > >
> > > >--- efi-mapping-1.txt2013-09-24 10:46:09.977746047 +0800
> > > >+++ efi-mapping-2.txt2013-09-24 10:46:33.871421806 +0800
> > > >@@ -1,30 +1,30 @@
> > > > efi mapping PA 0x80 -> VA 0x80
> > > > efi mapping PA 0x80 -> VA 0x
> > > > efi mapping PA 0x7c00 -> VA 0x7c00
> > > >-efi mapping PA 0x7c00 -> VA 0xfffefffe
> > > >+efi mapping PA 0x7c00 -> VA 0x
> > > > efi mapping PA 0x7d5e2000 -> VA 0x7d5e2000
> > > >-efi mapping PA 0x7d5e2000 -> VA 0xfffefffdf000
> > > >+efi mapping PA 0x7d5e2000 -> VA 0xfffef000
> > > > efi mapping PA 0x7d77d000 -> VA 0x7d77d000
> > > >-efi mapping PA 0x7d77d000 -> VA 0xfffefffde000
> > > >+efi mapping PA 0x7d77d000 -> VA 0xfffee000
> > > > efi mapping PA 0x7d864000 -> VA 0x7d864000
> > > >-efi mapping PA 0x7d864000 -> VA 0xfffeff8d4000
> > > >+efi mapping PA 0x7d864000 -> VA 0xfffeff8f4000
> > > > efi mapping PA 0x7df6e000 -> VA 0x7df6e000
> > > >-efi mapping PA 0x7df6e000 -> VA 0xfffeff6ae000
> > > >+efi mapping PA 0x7df6e000 -> VA 0xfffeff6ce000
> > > > efi mapping PA 0x7e194000 -> VA 0x7e194000
> > > >-efi mapping PA 0x7e194000 -> VA 0xfffeff6ac000
> > > >+efi mapping PA 0x7e194000 -> VA 0xfffeff6cc000
> > > > efi mapping PA 0x7e196000 -> VA 0x7e196000
> > > >-efi mapping PA 0x7e196000 -> VA 0xfffeff696000
> > > >+efi mapping PA 0x7e196000 -> VA 0xfffeff6b6000
> > > > efi mapping PA 0x7e1ac000 -> VA 0x7e1ac000
> > > >-efi mapping PA 0x7e1ac000 -> VA 0xfffeff681000
> > > >+efi mapping PA 0x7e1ac000 -> VA 0xfffeff6a1000
> > > > efi mapping PA 0x7e1c1000 -> VA 0x7e1c1000
> > > >-efi mapping PA 0x7e1c1000 -> VA 0xfffefe041000
> > > >+efi mapping PA 0x7e1c1000 -> VA 0xfffefe061000
> > > > efi mapping PA 0x7f802000 -> VA 0x7f802000
> > > >-efi mapping PA 0x7f802000 -> VA 0xfffefdec2000
> > > >+efi mapping PA 0x7f802000 -> VA 0xfffefdee2000
> > > > efi mapping PA 0x7f981000 -> VA 0x7f981000
> > > >-efi mapping PA 0x7f981000 -> VA 0xfffefde92000
> > > >+efi mapping PA 0x7f981000 -> VA 0xfffefdeb2000
> > > > efi mapping PA 0x7f9b1000 -> VA 0x7f9b1000
> > > >-efi mapping PA 0x7f9b1000 -> VA 0xfffefde6e000
> > > >+efi mapping PA 0x7f9b1000 -> VA 0xfffefde8e000
> > > > efi mapping PA 0x7f9e5000 -> VA 0x7f9e5000
> > > >-efi mapping PA 0x7f9e5000 -> VA 0xfffefd873000
> > > >+efi mapping PA 0x7f9e5000 -> VA 0xfffefd893000
> > > > efi mapping PA 0x7ffe -> VA 0x7ffe
> > > >-efi mapping PA 0x7ffe -> VA 0xfffefd853000
> > > >+efi mapping PA 0x7ffe -> VA 0xfffefd873000
> > > >
> > > >>
> > > >>
> > > >> Borislav Petkov wrote:
> > > >> >On Sun, Sep 22, 2013 at 08:35:15PM +0800, Dave Young wrote:
> > > >> >> I tested your new patch, it works both with efi stub and grub boot
> > > >in
> > > >> >> 1st kernel.
> > > >> >
> > > >> >Good, thanks!
> > > >> >
> > > >> >> But it paniced in kexec boot with my kexec related patcheset, the
> > > >> >patchset
> > > >> >
> > > >> >That's the second kernel, right?
> > > >> >
> > > >> >> contains 3 patch:
> > > >> >> 1. introduce cmdline
[Query] Stack Overflow in "arch/arm/kernel/unwind.c" while unwinding frame
Hi All, While executing unwind backtrace instructions in ARM, in the function unwind_exec_insn() there are chances that SP overflows from stack. For example while executing instruction with opcode 0xAE, vsp can go beyond stack to area that has not been allocated till now. unsigned long *vsp = (unsigned long *)ctrl->vrs[SP]; int reg; /* pop R4-R[4+bbb] */ for (reg = 4; reg <= 4 + (insn & 7); reg++) ctrl->vrs[reg] = *vsp++; The above scenario can happen while executing any of the unwind instruction. One of the ways to fix the problem is to check for vsp with stack limits before we increment it, but doing it for all the instructions seems a little bad. I just want to know that if anyone has faced the problem before I am working on Linux kernel for Android phones and I saw one case when this happened. I am new to Linux Kernel so not sure if this is the right place to ask the question. -- Anurag Aggarwal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/9] i2c: prepare runtime PM support for I2C client devices
On Tue, Sep 17, 2013 at 01:07:37PM +0200, Sylwester Nawrocki wrote: > On 09/16/2013 10:47 AM, Mika Westerberg wrote: > > I'm actually thinking that it is probably better now if we don't touch the > > client runtime PM at all in the I2C core. > > > > I proposed a less intrusive solution in this same thread where we power the > > I2C controller briefly at the client ->probe() (In order to have all the > > ACPI power resources etc. and the controller on) and let the client driver > > handle their own runtime PM as they do currently. > > > > Do you think that would work better wrt. fimc-isp-i2c driver? > > That would be no different for this particular driver, as long as the > I2C bus controller is activated right before the I2C client's probe(). Rafael pointed out that we can use ->ignore_children for the I2C adapter device for everything else than ACPI devices. That should keep the existing behavior. For ACPI devices we don't set that flag and the runtime PM core will activate the adapter whenever we try to power on I2C client device. This will make ACPI happy as well. If there are no objections, I'm going to send a new version based on the above. Thanks everyone for valuable input :) -- 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] EFI: Runtime services virtual mapping
On 09/24/13 at 12:57pm, Dave Young wrote:
> On 09/23/13 at 08:06pm, H. Peter Anvin wrote:
> > Okay... I see two problems.
> >
> > 1. It looks like we subtract the region size after, rather than before,
> > assigning an address.
> >
> > 2. The second region is assigned the same address in the secondary kernel
> > as in the first, implying the size of the first region was somehow set to
> > zero.
>
> I find the reason, efi_reserve_boot_services will reserve the
> BOOT_SERVICE_DATA region
> thus the memmap size is changed to 0, so in 2nd kernel the virtual mapping
> addr after
> the md will be not same as 1st kernel, see below code:
>
> void __init efi_map_region(efi_memory_desc_t *md)
> {
> unsigned long size = md->num_pages << PAGE_SHIFT;
>
> efi_va -= size;
> ^^^
> [snip]
> }
So how about just reserve BOOT_SERVICE_DATA region but keep the md.numpages as
is?
>
>
> >
> > Dave Young wrote:
> > >On 09/22/13 at 08:27am, H. Peter Anvin wrote:
> > >> The address that faults is interesting in that it is indeed just
> > >below -4G. The question at hand is probably what information you are
> > >using to build the EFI mappings in the secondary kernel and what could
> > >make it not match the primary.
> > >>
> > >> Assuming it isn't as simple as the mappings never get built at all.
> > >
> > >Here is my debug output, diff efi-mapping-1st-kernel
> > >efi-mapping-2nd-kernel:
> > >Obviously, the high address mapping is not same:
> > >
> > >--- efi-mapping-1.txt 2013-09-24 10:46:09.977746047 +0800
> > >+++ efi-mapping-2.txt 2013-09-24 10:46:33.871421806 +0800
> > >@@ -1,30 +1,30 @@
> > > efi mapping PA 0x80 -> VA 0x80
> > > efi mapping PA 0x80 -> VA 0x
> > > efi mapping PA 0x7c00 -> VA 0x7c00
> > >-efi mapping PA 0x7c00 -> VA 0xfffefffe
> > >+efi mapping PA 0x7c00 -> VA 0x
> > > efi mapping PA 0x7d5e2000 -> VA 0x7d5e2000
> > >-efi mapping PA 0x7d5e2000 -> VA 0xfffefffdf000
> > >+efi mapping PA 0x7d5e2000 -> VA 0xfffef000
> > > efi mapping PA 0x7d77d000 -> VA 0x7d77d000
> > >-efi mapping PA 0x7d77d000 -> VA 0xfffefffde000
> > >+efi mapping PA 0x7d77d000 -> VA 0xfffee000
> > > efi mapping PA 0x7d864000 -> VA 0x7d864000
> > >-efi mapping PA 0x7d864000 -> VA 0xfffeff8d4000
> > >+efi mapping PA 0x7d864000 -> VA 0xfffeff8f4000
> > > efi mapping PA 0x7df6e000 -> VA 0x7df6e000
> > >-efi mapping PA 0x7df6e000 -> VA 0xfffeff6ae000
> > >+efi mapping PA 0x7df6e000 -> VA 0xfffeff6ce000
> > > efi mapping PA 0x7e194000 -> VA 0x7e194000
> > >-efi mapping PA 0x7e194000 -> VA 0xfffeff6ac000
> > >+efi mapping PA 0x7e194000 -> VA 0xfffeff6cc000
> > > efi mapping PA 0x7e196000 -> VA 0x7e196000
> > >-efi mapping PA 0x7e196000 -> VA 0xfffeff696000
> > >+efi mapping PA 0x7e196000 -> VA 0xfffeff6b6000
> > > efi mapping PA 0x7e1ac000 -> VA 0x7e1ac000
> > >-efi mapping PA 0x7e1ac000 -> VA 0xfffeff681000
> > >+efi mapping PA 0x7e1ac000 -> VA 0xfffeff6a1000
> > > efi mapping PA 0x7e1c1000 -> VA 0x7e1c1000
> > >-efi mapping PA 0x7e1c1000 -> VA 0xfffefe041000
> > >+efi mapping PA 0x7e1c1000 -> VA 0xfffefe061000
> > > efi mapping PA 0x7f802000 -> VA 0x7f802000
> > >-efi mapping PA 0x7f802000 -> VA 0xfffefdec2000
> > >+efi mapping PA 0x7f802000 -> VA 0xfffefdee2000
> > > efi mapping PA 0x7f981000 -> VA 0x7f981000
> > >-efi mapping PA 0x7f981000 -> VA 0xfffefde92000
> > >+efi mapping PA 0x7f981000 -> VA 0xfffefdeb2000
> > > efi mapping PA 0x7f9b1000 -> VA 0x7f9b1000
> > >-efi mapping PA 0x7f9b1000 -> VA 0xfffefde6e000
> > >+efi mapping PA 0x7f9b1000 -> VA 0xfffefde8e000
> > > efi mapping PA 0x7f9e5000 -> VA 0x7f9e5000
> > >-efi mapping PA 0x7f9e5000 -> VA 0xfffefd873000
> > >+efi mapping PA 0x7f9e5000 -> VA 0xfffefd893000
> > > efi mapping PA 0x7ffe -> VA 0x7ffe
> > >-efi mapping PA 0x7ffe -> VA 0xfffefd853000
> > >+efi mapping PA 0x7ffe -> VA 0xfffefd873000
> > >
> > >>
> > >>
> > >> Borislav Petkov wrote:
> > >> >On Sun, Sep 22, 2013 at 08:35:15PM +0800, Dave Young wrote:
> > >> >> I tested your new patch, it works both with efi stub and grub boot
> > >in
> > >> >> 1st kernel.
> > >> >
> > >> >Good, thanks!
> > >> >
> > >> >> But it paniced in kexec boot with my kexec related patcheset, the
> > >> >patchset
> > >> >
> > >> >That's the second kernel, right?
> > >> >
> > >> >> contains 3 patch:
> > >> >> 1. introduce cmdline kexecboot=<0|1|2>; 1 == kexec, 2 == kdump
> > >> >> 2. export physical addr fw_vendor, runtime, tables to
> > >> >/sys/firmware/efi/systab
> > >> >> 3. if kexecboot != 0, use fw_vendor, runtime, tables from
> > >bootparams;
> > >> >Also do not
> > >> >>call SetVirtualAddressMao in case kexecboot.
> > >> >>
> > >> >> The panic happens at the last line of efi_init:
> > >> >> /* clean DUMMY object */
> > >> >> efi.set_variable(efi_dummy_name,
Re: [PATCH -v2] EFI: Runtime services virtual mapping
On 09/23/13 at 08:06pm, H. Peter Anvin wrote:
> Okay... I see two problems.
>
> 1. It looks like we subtract the region size after, rather than before,
> assigning an address.
>
> 2. The second region is assigned the same address in the secondary kernel as
> in the first, implying the size of the first region was somehow set to zero.
I find the reason, efi_reserve_boot_services will reserve the BOOT_SERVICE_DATA
region
thus the memmap size is changed to 0, so in 2nd kernel the virtual mapping addr
after
the md will be not same as 1st kernel, see below code:
void __init efi_map_region(efi_memory_desc_t *md)
{
unsigned long size = md->num_pages << PAGE_SHIFT;
efi_va -= size;
^^^
[snip]
}
>
> Dave Young wrote:
> >On 09/22/13 at 08:27am, H. Peter Anvin wrote:
> >> The address that faults is interesting in that it is indeed just
> >below -4G. The question at hand is probably what information you are
> >using to build the EFI mappings in the secondary kernel and what could
> >make it not match the primary.
> >>
> >> Assuming it isn't as simple as the mappings never get built at all.
> >
> >Here is my debug output, diff efi-mapping-1st-kernel
> >efi-mapping-2nd-kernel:
> >Obviously, the high address mapping is not same:
> >
> >--- efi-mapping-1.txt2013-09-24 10:46:09.977746047 +0800
> >+++ efi-mapping-2.txt2013-09-24 10:46:33.871421806 +0800
> >@@ -1,30 +1,30 @@
> > efi mapping PA 0x80 -> VA 0x80
> > efi mapping PA 0x80 -> VA 0x
> > efi mapping PA 0x7c00 -> VA 0x7c00
> >-efi mapping PA 0x7c00 -> VA 0xfffefffe
> >+efi mapping PA 0x7c00 -> VA 0x
> > efi mapping PA 0x7d5e2000 -> VA 0x7d5e2000
> >-efi mapping PA 0x7d5e2000 -> VA 0xfffefffdf000
> >+efi mapping PA 0x7d5e2000 -> VA 0xfffef000
> > efi mapping PA 0x7d77d000 -> VA 0x7d77d000
> >-efi mapping PA 0x7d77d000 -> VA 0xfffefffde000
> >+efi mapping PA 0x7d77d000 -> VA 0xfffee000
> > efi mapping PA 0x7d864000 -> VA 0x7d864000
> >-efi mapping PA 0x7d864000 -> VA 0xfffeff8d4000
> >+efi mapping PA 0x7d864000 -> VA 0xfffeff8f4000
> > efi mapping PA 0x7df6e000 -> VA 0x7df6e000
> >-efi mapping PA 0x7df6e000 -> VA 0xfffeff6ae000
> >+efi mapping PA 0x7df6e000 -> VA 0xfffeff6ce000
> > efi mapping PA 0x7e194000 -> VA 0x7e194000
> >-efi mapping PA 0x7e194000 -> VA 0xfffeff6ac000
> >+efi mapping PA 0x7e194000 -> VA 0xfffeff6cc000
> > efi mapping PA 0x7e196000 -> VA 0x7e196000
> >-efi mapping PA 0x7e196000 -> VA 0xfffeff696000
> >+efi mapping PA 0x7e196000 -> VA 0xfffeff6b6000
> > efi mapping PA 0x7e1ac000 -> VA 0x7e1ac000
> >-efi mapping PA 0x7e1ac000 -> VA 0xfffeff681000
> >+efi mapping PA 0x7e1ac000 -> VA 0xfffeff6a1000
> > efi mapping PA 0x7e1c1000 -> VA 0x7e1c1000
> >-efi mapping PA 0x7e1c1000 -> VA 0xfffefe041000
> >+efi mapping PA 0x7e1c1000 -> VA 0xfffefe061000
> > efi mapping PA 0x7f802000 -> VA 0x7f802000
> >-efi mapping PA 0x7f802000 -> VA 0xfffefdec2000
> >+efi mapping PA 0x7f802000 -> VA 0xfffefdee2000
> > efi mapping PA 0x7f981000 -> VA 0x7f981000
> >-efi mapping PA 0x7f981000 -> VA 0xfffefde92000
> >+efi mapping PA 0x7f981000 -> VA 0xfffefdeb2000
> > efi mapping PA 0x7f9b1000 -> VA 0x7f9b1000
> >-efi mapping PA 0x7f9b1000 -> VA 0xfffefde6e000
> >+efi mapping PA 0x7f9b1000 -> VA 0xfffefde8e000
> > efi mapping PA 0x7f9e5000 -> VA 0x7f9e5000
> >-efi mapping PA 0x7f9e5000 -> VA 0xfffefd873000
> >+efi mapping PA 0x7f9e5000 -> VA 0xfffefd893000
> > efi mapping PA 0x7ffe -> VA 0x7ffe
> >-efi mapping PA 0x7ffe -> VA 0xfffefd853000
> >+efi mapping PA 0x7ffe -> VA 0xfffefd873000
> >
> >>
> >>
> >> Borislav Petkov wrote:
> >> >On Sun, Sep 22, 2013 at 08:35:15PM +0800, Dave Young wrote:
> >> >> I tested your new patch, it works both with efi stub and grub boot
> >in
> >> >> 1st kernel.
> >> >
> >> >Good, thanks!
> >> >
> >> >> But it paniced in kexec boot with my kexec related patcheset, the
> >> >patchset
> >> >
> >> >That's the second kernel, right?
> >> >
> >> >> contains 3 patch:
> >> >> 1. introduce cmdline kexecboot=<0|1|2>; 1 == kexec, 2 == kdump
> >> >> 2. export physical addr fw_vendor, runtime, tables to
> >> >/sys/firmware/efi/systab
> >> >> 3. if kexecboot != 0, use fw_vendor, runtime, tables from
> >bootparams;
> >> >Also do not
> >> >>call SetVirtualAddressMao in case kexecboot.
> >> >>
> >> >> The panic happens at the last line of efi_init:
> >> >> /* clean DUMMY object */
> >> >> efi.set_variable(efi_dummy_name, _DUMMY_GUID,
> >> >> EFI_VARIABLE_NON_VOLATILE |
> >> >> EFI_VARIABLE_BOOTSERVICE_ACCESS |
> >> >> EFI_VARIABLE_RUNTIME_ACCESS,
> >> >> 0, NULL);
> >> >>
> >> >> Below is the dmesg:
> >> >> [0.003359] pid_max: default: 32768 minimum: 301
> >> >> [
Re: [PATCH 0/6] ARM: shmobile: kzm9d-reference: migrate to common clock framework with DT
[ Cc Laurent ] On Tue, Sep 24, 2013 at 01:05:26PM +0900, Takashi Yoshii wrote: > This patch series makes kzm9d-reference to move to new clk implementation > based on the common clock framework and device tree. Magnus, Laurent, I would appreciate it if you could take a look over the approach taken here. Thanks > > First three are for preparation. > [PATCH 1/6] clocksource: em_sti: convert to clk_prepare/unprepare > [PATCH 2/6] serial8250-em: convert to clk_prepare/unprepare > [PATCH 3/6] sh: clkfwk: Select sh-/common- clkfwk alternatively > > Next one is a proposal document of DT bindings. > [PATCH 4/6] ARM: shmobile: emev2: Define SMU clock DT bindings > > This is the implementation, and dts which carries clock tree description. > [PATCH 5/6] clk: emev2: Add support for emev2 SMU clocks with DT > > Last one is small modification needed for migration. > [PATCH 6/6] ARM: shmobile: kzm9d-reference: Use common clock > > These patches do not remove sh-clkfwk version, even on emev2. > kzm9d(without -reference) target still uses sh-clkfwk. > I believe this method encourages step-by-step migration on other sh-mobile > targets, too. > > Patches should be applied and compiled both on > v3.12-rc2 and > kernel/git/horms/renesas.git tag:renesas-devel-20130922 > > Confirmed on kernel/git/horms/renesas.git tag:renesas-devel-20130922 > for boot up to command prompt. > - kzm9d board / multiplatform + kzm9d-reference configuration > - kzm9d board / kzm9d-reference configuration > - kzm9d board / kzm9d (with sh-clkfwk) configuration for regression. > - ape6evm (with sh-clkfwk) for regression. > for compile only > - sh7757lcr (in arch/sh with sh-clkfwk) for regression. > > > Shinya Kuribayashi (2): > clocksource: em_sti: convert to clk_prepare/unprepare > serial8250-em: convert to clk_prepare/unprepare > > Takashi YOSHII (4): > sh: clkfwk: Select sh-/common- clkfwk alternatively > ARM: shmobile: emev2: Define SMU clock DT bindings > clk: emev2: Add support for emev2 SMU clocks with DT > ARM: shmobile: kzm9d-reference: Use common clock framework > > .../devicetree/bindings/clock/emev2-clock.txt | 99 > arch/arm/Kconfig | 2 +- > arch/arm/boot/dts/emev2.dtsi | 84 + > arch/arm/mach-shmobile/Kconfig | 1 + > arch/arm/mach-shmobile/board-kzm9d-reference.c | 5 +- > arch/sh/Kconfig| 1 + > drivers/clk/Makefile | 2 + > drivers/clk/shmobile/Makefile | 5 + > drivers/clk/shmobile/clk-emev2.c | 104 > + > drivers/clocksource/em_sti.c | 4 +- > drivers/sh/clk/Makefile| 3 +- > drivers/tty/serial/8250/8250_em.c | 6 +- > 12 files changed, 305 insertions(+), 11 deletions(-) > create mode 100644 Documentation/devicetree/bindings/clock/emev2-clock.txt > create mode 100644 drivers/clk/shmobile/Makefile > create mode 100644 drivers/clk/shmobile/clk-emev2.c > > -- > 1.8.1.5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-sh" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] ARM: shmobile: kzm9d-reference: Use common clock framework
On Tue, Sep 24, 2013 at 01:17:03PM +0900, takas...@ops.dti.ne.jp wrote:
> Use common clock framework version of clock
> drivers/clk/shmobile/clk-emev2.c
> instead of sh-clkfwk version
> arch/arm/mach-shmobile/clock-emev2.c
>
> kzm9d(without -reference) still uses sh-clkfwk version.
>
> Because two of that framework can not live in one kernel binary,
> there will be SoCs and Boards that can not be in one binary as
> multiplatform binary or so.
> For example, kzm9d and kzm9d-reference is now exclusive.
>
> Signed-off-by: Takashi Yoshii
Magnus, could you confirm whether or not you would like
common clocks to be mandatory for -reference in the near-term?
> ---
> arch/arm/mach-shmobile/Kconfig | 1 +
> arch/arm/mach-shmobile/board-kzm9d-reference.c | 5 ++---
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
> index 50bab8d..d20d4ce 100644
> --- a/arch/arm/mach-shmobile/Kconfig
> +++ b/arch/arm/mach-shmobile/Kconfig
> @@ -237,6 +237,7 @@ config MACH_KZM9D_REFERENCE
> depends on ARCH_EMEV2
> select REGULATOR_FIXED_VOLTAGE if REGULATOR
> select USE_OF
> + select COMMON_CLK
> ---help---
> Use reference implementation of KZM9D board support
> which makes a greater use of device tree at the expense
> diff --git a/arch/arm/mach-shmobile/board-kzm9d-reference.c
> b/arch/arm/mach-shmobile/board-kzm9d-reference.c
> index 8f8bb2f..e0b8317 100644
> --- a/arch/arm/mach-shmobile/board-kzm9d-reference.c
> +++ b/arch/arm/mach-shmobile/board-kzm9d-reference.c
> @@ -20,15 +20,14 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
>
> static void __init kzm9d_add_standard_devices(void)
> {
> - if (!IS_ENABLED(CONFIG_COMMON_CLK))
> - emev2_clock_init();
> -
> + of_clk_init(NULL);
> of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> }
>
> --
> 1.8.1.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/
Re: [PATCH 2/2] gpio / ACPI: add support for GPIO operation regions
On Tue, Sep 24, 2013 at 12:47:56AM +, Zheng, Lv wrote: > > From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com] > > Sent: Tuesday, September 17, 2013 4:37 PM > > > > On Mon, Sep 16, 2013 at 11:35:56PM +, Zheng, Lv wrote: > > > > From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com] > > > > Sent: Monday, September 16, 2013 4:11 PM > > > > > > > > On Mon, Sep 16, 2013 at 01:21:53AM +, Zheng, Lv wrote: > > > > > > A pseudo device may be created to access the GPIO operation region > > > > > > fields provided by one GPIO device. > > > > > > The pseudo device may have other functions to access other GPIO > > > > > > operation region fields provided by other GPIO devices, or even > > worse > > > > to > > > > > > access other ACPI provided value-adds. > > > > > > So hierarchically the pseudo device only requires CPU, thus should > > > > > > not be under the GPIO device, which means the GPIO operation > > > > regions > > > > > > have nothing to do with the GPIO devices' ACPI handle. > > > > > > > > > > Sorry for the wording. > > > > > It's better to say the GPIO operation region users haven't strict > > > > > relationship to the GPIO operation region providers. > > > > > As the installation is to provide GPIO operation regions to the > > > > > users, it > > > > > shouldn't relate to the providers' ACPI handle. > > > > > > > > If I understand you correctly you mean that there might be multiple > > > > users > > > > (different devices) for the same GPIO operation region, right? > > > > > > No, this is not what I meant. > > > Can one vendor device uses two or more GPIO pins from different GPIO > > > ports? > > > > Yes. > > So how can such a device under one of these GPIO ports? > It can only be under one particular GPIO port device, right? > > Thus I believe such device will appear below other devices rather than > below a GPIO port device in the ACPI namespace. I'm sorry, but I can't follow what you mean. > > > > That shouldn't be a problem as far as I can tell. > > > > > > > > What comes to the hierarchy you refer, I'm not sure if that is a problem > > > > either (unless I'm missing something). The GPIO can be used anywhere in > > > > the > > > > ASL, it doesn't have to be descendant of the GPIO device. You only need > > > > to > > > > do something like this: > > > > > > > > // Assert the GPIO > > > > Store(1, \_SB.PCI0.SHD3) > > > > > > > > In other words, use the fully qualified name. > > > > > > Yes, which means this line of code can be everywhere in the namespace. > > > It is not required to be under one particular GPIO device as long as > > > there is an operation region defined in that scope. > > > > > > The problem is the installation, the first parameter for > > > acpi_install_address_space_handler() is a namespace node, the function > > > will call _REG for all OperationRegions below the scope whose top most > > > node is the specified node. > > > The nodes out of this scope are not affected. So if an OperationRegion > > > is defined out of this scope, problem happens. > > > > I suppose for that operation region another GPIO device should be > > introduced then, no? > > I believe the answer is no. Consider a situation, where you have two different GPIO controllers and the ASL code needs to access GPIOs on both controllers. That requires introducing two GPIO devices in ACPI namespace and two separate drivers as well. > > > So if we don't have a GPIO driver for the given operation region, what can > > we do? We don't want the ASL code to erroneusly think that there is an > > operation region available when it is not. > > I think GPIO "address_space_handler" should be provided by an ACPI GPIO > address space module rather than provided by a particular GPIO driver. > > Actually, without the readiness of the GPIO driver, currently ASL code > can still access the GPIO fields, though it just results in "handler not > found" ACPICA error message. If the "setup" callback is implemented, > then the proper GPIO driver can be matched in this "setup" callback. If > the GPIO driver hasn't been loaded by Linux and thus not matched in the > "setup" callback, from users' point of view, the result is just changing > the error message from "handler not found" to "driver not found". Well, I'm fine implementing a single global GPIO region handler (instead of what is done in this series). Rafael, do you have any comments on this? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] ARM: shmobile: emev2: Define SMU clock DT bindings
[ Cc Laurent ]
On Tue, Sep 24, 2013 at 01:13:31PM +0900, takas...@ops.dti.ne.jp wrote:
> Device tree clock binding document for EMMA Mobile EV2 SMU.
> Following nodes are defined to describe clock tree.
> - renesas,emev2-smu
> - renesas,emev2-smu-clkdiv
> - renesas,emev2-smu-gclk
I realise this has been entirely consistent in the past and
even as recently as Linus' pre v3.12-rc2 master branch.
However, after some recent discussion we are now trying to make our
compatibility strings consistently of the form renesas,-.
With this in mind I believe the strings should be:
- renesas,smu-emev2
- renesas,smu-clkdiv-emev2
- renesas,smu-gclk-emev2
To be honest I am not quite sure about the "-clkdiv" and "-gclk"
bits and I would appreciate some review from others.
I have CCed Laurent as he may have some advice to offer here.
>
> These bindings are designed manually based on
> 19UH0037EJ1000_SMU : System Management Unit User's Manual
>
> Signed-off-by: Takashi Yoshii
> ---
> .../devicetree/bindings/clock/emev2-clock.txt | 99
> ++
> 1 file changed, 99 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/emev2-clock.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/emev2-clock.txt
> b/Documentation/devicetree/bindings/clock/emev2-clock.txt
> new file mode 100644
> index 000..f8649eb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/emev2-clock.txt
> @@ -0,0 +1,99 @@
> +Device tree Clock bindings for Renesas EMMA Mobile EV2
> +
> +This binding uses the common clock binding.
> +
> +* SMU
> +System Management Unit described in user's manual R19UH0037EJ1000_SMU.
> +This is not a clock provider, but clocks under SMU depend on it.
> +
> +Required properties:
> +- compatible: Should be "renesas,emev2-smu"
> +- reg: Address and Size of SMU registers
> +
> +* SMU_CLKDIV
> +Function block with an input mux and a divider, which corresponds to
> +"Serial clock generator" in fig."Clock System Overview" of the manual,
> +and "xxx frequency division setting register" (XXXCLKDIV) registers.
> +This makes internal (neither input nor output) clock that is provided
> +to input of xxxGCLK block.
> +
> +Required properties:
> +- compatible: Should be "renesas,emev2-smu-clkdiv"
> +- reg: Byte offset from SMU base and Bit position in the register
> +- clocks: Parent clocks. Input clocks as described in clock-bindings.txt
> +- #clock-cells: Should be <0>
> +
> +* SMU_GCLK
> +Clock gating node shown as "Clock stop processing block" in the
> +fig."Clock System Overview" of the manual.
> +Registers are "xxx clock gate control register" (XXXGCLKCTRL).
> +
> +Required properties:
> +- compatible: Should be "renesas,emev2-smu-gclk"
> +- reg: Byte offset from SMU base and Bit position in the register
> +- clocks: Input clock as described in clock-bindings.txt
> +- #clock-cells: Should be <0>
> +
> +Example of provider:
> +
> +usia_u0_sclkdiv: usia_u0_sclkdiv {
> + compatible = "renesas,emev2-smu-clkdiv";
> + reg = <0x610 0>;
> + clocks = <_fo>, <_fo>, <_fo>, <_fo>;
> + #clock-cells = <0>;
> +};
> +
> +usia_u0_sclk: usia_u0_sclk {
> + compatible = "renesas,emev2-smu-gclk";
> + reg = <0x4a0 1>;
> + clocks = <_u0_sclkdiv>;
> + #clock-cells = <0>;
> +};
> +
> +Example of consumer:
> +
> +uart@e102 {
> + compatible = "renesas,em-uart";
> + reg = <0xe102 0x38>;
> + interrupts = <0 8 0>;
> + clocks = <_u0_sclk>;
> + clock-names = "sclk";
> +};
> +
> +Example of clock-tree description:
> +
> + This describes a clock path in the clock tree
> + c32ki -> pll3_fo -> usia_u0_sclkdiv -> usia_u0_sclk
> +
> +smu {
> + compatible = "renesas,emev2-smu";
> + reg = <0xe011 0x1>;
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + c32ki: c32ki {
> + compatible = "fixed-clock";
> + clock-frequency = <32768>;
> + #clock-cells = <0>;
> + };
> + pll3_fo: pll3_fo {
> + compatible = "fixed-factor-clock";
> + clocks = <>;
> + clock-div = <1>;
> + clock-mult = <7000>;
> + #clock-cells = <0>;
> + };
> + usia_u0_sclkdiv: usia_u0_sclkdiv {
> + compatible = "renesas,emev2-smu-clkdiv";
> + reg = <0x610 0>;
> + clocks = <_fo>;
> + #clock-cells = <0>;
> + };
> + usia_u0_sclk: usia_u0_sclk {
> + compatible = "renesas,emev2-smu-gclk";
> + reg = <0x4a0 1>;
> + clocks = <_u0_sclkdiv>;
> + #clock-cells = <0>;
> + };
> +};
> +
> --
> 1.8.1.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/
Re: [PATCH 2/6] serial8250-em: convert to clk_prepare/unprepare
[ CCed Greg Kroah-Hartman, the serial maintainer for his review ]
On Tue, Sep 24, 2013 at 01:10:39PM +0900, takas...@ops.dti.ne.jp wrote:
> From: Shinya Kuribayashi
>
> Add calls to clk_prepare and unprepare so that EMMA Mobile EV2 can
> migrate to the common clock framework.
>
> Signed-off-by: Shinya Kuribayashi
> [takashi.yoshii...@renesas.com: edited for conflicts]
> Signed-off-by: Takashi Yoshii
> ---
> drivers/tty/serial/8250/8250_em.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_em.c
> b/drivers/tty/serial/8250/8250_em.c
> index 5f3bba1..d1a9078 100644
> --- a/drivers/tty/serial/8250/8250_em.c
> +++ b/drivers/tty/serial/8250/8250_em.c
> @@ -122,7 +122,7 @@ static int serial8250_em_probe(struct platform_device
> *pdev)
> up.port.dev = >dev;
> up.port.private_data = priv;
>
> - clk_enable(priv->sclk);
> + clk_prepare_enable(priv->sclk);
> up.port.uartclk = clk_get_rate(priv->sclk);
>
> up.port.iotype = UPIO_MEM32;
> @@ -134,7 +134,7 @@ static int serial8250_em_probe(struct platform_device
> *pdev)
> ret = serial8250_register_8250_port();
> if (ret < 0) {
> dev_err(>dev, "unable to register 8250 port\n");
> - clk_disable(priv->sclk);
> + clk_disable_unprepare(priv->sclk);
> return ret;
> }
>
> @@ -148,7 +148,7 @@ static int serial8250_em_remove(struct platform_device
> *pdev)
> struct serial8250_em_priv *priv = platform_get_drvdata(pdev);
>
> serial8250_unregister_port(priv->line);
> - clk_disable(priv->sclk);
> + clk_disable_unprepare(priv->sclk);
> return 0;
> }
>
> --
> 1.8.1.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Sep 24
Hi all, Heads up: I will be having a 3 week break leading up to the kernel summit. This means that next-20130927 (next Friday) will be the last linux-next release until next-20131028 (or maybe 29). I presume that Linus will be up to v3.12-rc7 by then and -rc7 is often the last before a release ... Please plan accordingly. Changes since 20130923: Removed tree: cputime (finished with) The ipsec-next tree gained a conflict against the net-next tree. The pinctrl tree lost its build failure. The random tree lost its build failure. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 214 trees (counting Linus' and 30 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (4a10c2a Linux 3.12-rc2) Merging fixes/master (fa8218d Merge tag 'regmap-v3.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap) Merging kbuild-current/rc-fixes (ad81f05 Linux 3.11-rc1) Merging arc-current/for-curr (272b98c Linux 3.12-rc1) Merging arm-current/fixes (40190c8 ARM: 7837/3: fix Thumb-2 bug in AES assembler code) Merging m68k-current/for-linus (21e884b m68k/m68knommu: Implement __get_user_unaligned/__put_user_unaligned()) Merging metag-fixes/fixes (3b2f64d Linux 3.11-rc2) Merging powerpc-merge/merge (363edbe powerpc: Default arch idle could cede processor on pseries) Merging sparc/master (4de9ad9 Merge git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile) Merging net/master (9fe34f5 mrp: add periodictimer to allow retries when packets get lost) Merging ipsec/master (33fce60 xfrm: Guard IPsec anti replay window against replay bitmap) Merging sound-current/for-linus (4028b6c ALSA: compress: Fix compress device unregister.) Merging pci-current/for-linus (4a10c2a Linux 3.12-rc2) Merging wireless/master (b75ff5e Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging driver-core.current/driver-core-linus (272b98c Linux 3.12-rc1) Merging tty.current/tty-linus (93a8d41 n_tty: Fix EOF push index when termios changes) Merging usb.current/usb-linus (9d23108 Merge tag 'staging-3.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging) Merging staging.current/staging-linus (6174081 Merge tag 'iio-fixes-for-3.12a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus) Merging char-misc.current/char-misc-linus (272b98c Linux 3.12-rc1) Merging input-current/for-linus (2f0d260 Input: i8042 - i8042_flush fix for a full 8042 buffer) Merging md-current/for-linus (f94c0b6 md/raid5: fix interaction of 'replace' and 'recovery'.) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (26052f9 crypto: crct10dif - Add fallback for broken initrds) Merging ide/master (64110c1 ide: sgiioc4: Staticize ioc4_ide_attach_one()) Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging devicetree-current/devicetree/merge (cf9e236 of/irq: init struct resource to 0 in of_irq_to_resource()) Merging rr-fixes/fixes (6c2580c Merge branch 'for-linus' of git://git.kernel.org/pub/
Re: [RFC GIT PULL] softirq: Consolidation and stack overrun fix
On Tue, 2013-09-24 at 04:44 +0200, Frederic Weisbecker wrote: > So the safest way to fix this is to unconditionally call do_softirq() > from irq_exit(). > A performance penalty may come along but safety primes. > > We should probably do that and work on longer term solutions (Kconfig > based arch switch, etc...) > for the next merge window? As you prefer, though I'm keen on getting the "fast" version in RHEL7 if RH will take it :-) >From the generic code POV, it's a one-liner #ifdef to select between do_softirq and __do_softirq() right ? Then it's up to the arch to #define I_CAN_DO_FAST ! > I'll respin the series plus the regression fix, unless somebody has a > better solution. Cheers, Ben. -- 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/6] clocksource: em_sti: convert to clk_prepare/unprepare
[ CCed Daniel Lezcano and Thomas Gleixner, the clocksource maintainers ]
On Tue, Sep 24, 2013 at 01:09:24PM +0900, takas...@ops.dti.ne.jp wrote:
> From: Shinya Kuribayashi
>
> Add calls to clk_prepare and unprepare so that EMMA Mobile EV2 can
> migrate to the common clock framework.
>
> Signed-off-by: Shinya Kuribayashi
> ---
> drivers/clocksource/em_sti.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clocksource/em_sti.c b/drivers/clocksource/em_sti.c
> index 3a5909c..9d17083 100644
> --- a/drivers/clocksource/em_sti.c
> +++ b/drivers/clocksource/em_sti.c
> @@ -78,7 +78,7 @@ static int em_sti_enable(struct em_sti_priv *p)
> int ret;
>
> /* enable clock */
> - ret = clk_enable(p->clk);
> + ret = clk_prepare_enable(p->clk);
> if (ret) {
> dev_err(>pdev->dev, "cannot enable clock\n");
> return ret;
> @@ -107,7 +107,7 @@ static void em_sti_disable(struct em_sti_priv *p)
> em_sti_write(p, STI_INTENCLR, 3);
>
> /* stop clock */
> - clk_disable(p->clk);
> + clk_disable_unprepare(p->clk);
> }
>
> static cycle_t em_sti_count(struct em_sti_priv *p)
> --
> 1.8.1.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/
[PATCH 4/6] ARM: shmobile: emev2: Define SMU clock DT bindings
Device tree clock binding document for EMMA Mobile EV2 SMU.
Following nodes are defined to describe clock tree.
- renesas,emev2-smu
- renesas,emev2-smu-clkdiv
- renesas,emev2-smu-gclk
These bindings are designed manually based on
19UH0037EJ1000_SMU : System Management Unit User's Manual
Signed-off-by: Takashi Yoshii
---
.../devicetree/bindings/clock/emev2-clock.txt | 99 ++
1 file changed, 99 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/emev2-clock.txt
diff --git a/Documentation/devicetree/bindings/clock/emev2-clock.txt
b/Documentation/devicetree/bindings/clock/emev2-clock.txt
new file mode 100644
index 000..f8649eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/emev2-clock.txt
@@ -0,0 +1,99 @@
+Device tree Clock bindings for Renesas EMMA Mobile EV2
+
+This binding uses the common clock binding.
+
+* SMU
+System Management Unit described in user's manual R19UH0037EJ1000_SMU.
+This is not a clock provider, but clocks under SMU depend on it.
+
+Required properties:
+- compatible: Should be "renesas,emev2-smu"
+- reg: Address and Size of SMU registers
+
+* SMU_CLKDIV
+Function block with an input mux and a divider, which corresponds to
+"Serial clock generator" in fig."Clock System Overview" of the manual,
+and "xxx frequency division setting register" (XXXCLKDIV) registers.
+This makes internal (neither input nor output) clock that is provided
+to input of xxxGCLK block.
+
+Required properties:
+- compatible: Should be "renesas,emev2-smu-clkdiv"
+- reg: Byte offset from SMU base and Bit position in the register
+- clocks: Parent clocks. Input clocks as described in clock-bindings.txt
+- #clock-cells: Should be <0>
+
+* SMU_GCLK
+Clock gating node shown as "Clock stop processing block" in the
+fig."Clock System Overview" of the manual.
+Registers are "xxx clock gate control register" (XXXGCLKCTRL).
+
+Required properties:
+- compatible: Should be "renesas,emev2-smu-gclk"
+- reg: Byte offset from SMU base and Bit position in the register
+- clocks: Input clock as described in clock-bindings.txt
+- #clock-cells: Should be <0>
+
+Example of provider:
+
+usia_u0_sclkdiv: usia_u0_sclkdiv {
+ compatible = "renesas,emev2-smu-clkdiv";
+ reg = <0x610 0>;
+ clocks = <_fo>, <_fo>, <_fo>, <_fo>;
+ #clock-cells = <0>;
+};
+
+usia_u0_sclk: usia_u0_sclk {
+ compatible = "renesas,emev2-smu-gclk";
+ reg = <0x4a0 1>;
+ clocks = <_u0_sclkdiv>;
+ #clock-cells = <0>;
+};
+
+Example of consumer:
+
+uart@e102 {
+ compatible = "renesas,em-uart";
+ reg = <0xe102 0x38>;
+ interrupts = <0 8 0>;
+ clocks = <_u0_sclk>;
+ clock-names = "sclk";
+};
+
+Example of clock-tree description:
+
+ This describes a clock path in the clock tree
+ c32ki -> pll3_fo -> usia_u0_sclkdiv -> usia_u0_sclk
+
+smu {
+ compatible = "renesas,emev2-smu";
+ reg = <0xe011 0x1>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ c32ki: c32ki {
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ #clock-cells = <0>;
+ };
+ pll3_fo: pll3_fo {
+ compatible = "fixed-factor-clock";
+ clocks = <>;
+ clock-div = <1>;
+ clock-mult = <7000>;
+ #clock-cells = <0>;
+ };
+ usia_u0_sclkdiv: usia_u0_sclkdiv {
+ compatible = "renesas,emev2-smu-clkdiv";
+ reg = <0x610 0>;
+ clocks = <_fo>;
+ #clock-cells = <0>;
+ };
+ usia_u0_sclk: usia_u0_sclk {
+ compatible = "renesas,emev2-smu-gclk";
+ reg = <0x4a0 1>;
+ clocks = <_u0_sclkdiv>;
+ #clock-cells = <0>;
+ };
+};
+
--
1.8.1.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/
[PATCH 3/6] sh: clkfwk: Select sh-/common- clkfwk alternatively
Make sh clock framework core depend on HAVE_MACH_CLKDEV, and set it - y on sh for backward compatibility - !CONFIG_COMMON_CLK on sh-mobile This is a preparation for migration to common clock framework from sh clock framework on sh-mobile. Signed-off-by: Takashi Yoshii --- arch/arm/Kconfig| 2 +- arch/sh/Kconfig | 1 + drivers/sh/clk/Makefile | 3 +-- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 3f7714d..53044ca 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -650,7 +650,7 @@ config ARCH_SHMOBILE select HAVE_ARM_SCU if SMP select HAVE_ARM_TWD if SMP select HAVE_CLK - select HAVE_MACH_CLKDEV + select HAVE_MACH_CLKDEV if !COMMON_CLK select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 select MULTI_IRQ_HANDLER diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig index 224f4bc..f57e47f 100644 --- a/arch/sh/Kconfig +++ b/arch/sh/Kconfig @@ -41,6 +41,7 @@ config SUPERH select MODULES_USE_ELF_RELA select OLD_SIGSUSPEND select OLD_SIGACTION + select HAVE_MACH_CLKDEV help The SuperH is a RISC processor targeted for use in embedded systems and consumer electronics; it was also used in the Sega Dreamcast diff --git a/drivers/sh/clk/Makefile b/drivers/sh/clk/Makefile index 5d15ebf..e73b031 100644 --- a/drivers/sh/clk/Makefile +++ b/drivers/sh/clk/Makefile @@ -1,3 +1,2 @@ -obj-y := core.o - +obj-$(CONFIG_HAVE_MACH_CLKDEV) += core.o obj-$(CONFIG_SH_CLK_CPG) += cpg.o -- 1.8.1.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/
Re: [PATCH] kernel/groups.c: consider about NULL for 'group_info' in all related extern functions
On 09/24/2013 12:06 PM, Tejun Heo wrote: > Hello, > > On Tue, Sep 24, 2013 at 11:42:56AM +0800, Chen Gang wrote: >> Hmm... can user be permitted to call other system call (e.g. getgroups) >> before call groups_alloc()? (may the user space already give check, but >> for our kernel, we can not only depend on their checking). > > I don't think so. > >> According to group_alloc() and setgroups() usage in kernel source code, >> 'group_info' may be not set if kernel/process is running (although user >> space may be sure "if kernel is running, 'group_info' must be set"). >> >> The below is the proof for "kernel itself can not be sure 'group_info' >> must be set during kernel/process is running", please check, thanks. > .. >> The related conclusion: >> >> during kernel startup or process creation, kernel does not intend to set >> 'group_info'. > > No, this is not a proof or any meaningful conclusion. This is just > some random suspicions combined with supposedly related grep output. > For real world, /sbin/init will call setgroups, so user space 'help' kernel itself to protect this issue, but I think, we don't only depend on the user space help checking. The proof is below: [root@gchenlinux tmp]# grep setgroups /sbin/* Binary file /sbin/init matches Binary file /sbin/rpc.statd matches Binary file /sbin/rsyslogd matches Binary file /sbin/runuser matches >From reading kernel source code, kernel itself does not intend to set 'group_info', it is triggered by user space or another kernel mode sub-systems. >> In extern function groups_search (which also called by export function >> in_group_p and in_egroup_p), it checks "if 'cred->group_info' is NULL". >> >> So "kernel/groups.c" have 9 extern/export/system-call functions, and >> 4/9 notice about "if 'cred->group_info' is NULL" (e.g. groups_alloc, >> groups_search, in_group_p, in_egroup_p). >> >> So for API self-consistency, all of extern/export/system-call functions >> need notice about it. > > I'm afraid this isn't useful. If you want to change the code, you > actually need to understand what's going on. "this seems weird to me" > is a good starting point but you need to go way beyond that to > actually make changes. > If some of APIs check the related parameters, but the other not, this interface must assume some usage condition from the callers which callers can break out (although the callers may not break out, now). > Thanks. > -- Chen Gang -- 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 08/12] bluetooth: Remove extern from function prototypes
Hi Joe, > There are a mix of function prototypes with and without extern > in the kernel sources. Standardize on not using extern for > function prototypes. > > Function prototypes don't need to be written with extern. > extern is assumed by the compiler. Its use is as unnecessary as > using auto to declare automatic/local variables in a block. > > Signed-off-by: Joe Perches > --- > include/net/bluetooth/bluetooth.h | 16 > include/net/bluetooth/hci_core.h | 23 +++ > include/net/bluetooth/rfcomm.h| 4 ++-- > 3 files changed, 21 insertions(+), 22 deletions(-) Acked-by: Marcel Holtmann 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: False positive in checkpatch
On Mon, 2013-09-23 at 15:59 -0700, Paul E. McKenney wrote: > Hello! > > The checkpatch.pl script complains as follows: > > ERROR: need consistent spacing around '*' (ctx:WxB) > #57: FILE: include/linux/rcupdate.h:564: > + ACCESS_ONCE(p) = (typeof(*(v)) __force space *)(v); \ > > Of course, the two uses of '*' are doing different things, so it should > be OK for the spacing to be different. > > Could you please fix this? > > Thanx, Paul > Hi Paul. Try this patch: https://lkml.org/lkml/2013/9/2/428 Andy? Can you verify this suggested patch please? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] clocksource: em_sti: convert to clk_prepare/unprepare
From: Shinya Kuribayashi
Add calls to clk_prepare and unprepare so that EMMA Mobile EV2 can
migrate to the common clock framework.
Signed-off-by: Shinya Kuribayashi
---
drivers/clocksource/em_sti.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clocksource/em_sti.c b/drivers/clocksource/em_sti.c
index 3a5909c..9d17083 100644
--- a/drivers/clocksource/em_sti.c
+++ b/drivers/clocksource/em_sti.c
@@ -78,7 +78,7 @@ static int em_sti_enable(struct em_sti_priv *p)
int ret;
/* enable clock */
- ret = clk_enable(p->clk);
+ ret = clk_prepare_enable(p->clk);
if (ret) {
dev_err(>pdev->dev, "cannot enable clock\n");
return ret;
@@ -107,7 +107,7 @@ static void em_sti_disable(struct em_sti_priv *p)
em_sti_write(p, STI_INTENCLR, 3);
/* stop clock */
- clk_disable(p->clk);
+ clk_disable_unprepare(p->clk);
}
static cycle_t em_sti_count(struct em_sti_priv *p)
--
1.8.1.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/
[PATCH 2/6] serial8250-em: convert to clk_prepare/unprepare
From: Shinya Kuribayashi
Add calls to clk_prepare and unprepare so that EMMA Mobile EV2 can
migrate to the common clock framework.
Signed-off-by: Shinya Kuribayashi
[takashi.yoshii...@renesas.com: edited for conflicts]
Signed-off-by: Takashi Yoshii
---
drivers/tty/serial/8250/8250_em.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_em.c
b/drivers/tty/serial/8250/8250_em.c
index 5f3bba1..d1a9078 100644
--- a/drivers/tty/serial/8250/8250_em.c
+++ b/drivers/tty/serial/8250/8250_em.c
@@ -122,7 +122,7 @@ static int serial8250_em_probe(struct platform_device *pdev)
up.port.dev = >dev;
up.port.private_data = priv;
- clk_enable(priv->sclk);
+ clk_prepare_enable(priv->sclk);
up.port.uartclk = clk_get_rate(priv->sclk);
up.port.iotype = UPIO_MEM32;
@@ -134,7 +134,7 @@ static int serial8250_em_probe(struct platform_device *pdev)
ret = serial8250_register_8250_port();
if (ret < 0) {
dev_err(>dev, "unable to register 8250 port\n");
- clk_disable(priv->sclk);
+ clk_disable_unprepare(priv->sclk);
return ret;
}
@@ -148,7 +148,7 @@ static int serial8250_em_remove(struct platform_device
*pdev)
struct serial8250_em_priv *priv = platform_get_drvdata(pdev);
serial8250_unregister_port(priv->line);
- clk_disable(priv->sclk);
+ clk_disable_unprepare(priv->sclk);
return 0;
}
--
1.8.1.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/
[PATCH 6/6] ARM: shmobile: kzm9d-reference: Use common clock framework
Use common clock framework version of clock
drivers/clk/shmobile/clk-emev2.c
instead of sh-clkfwk version
arch/arm/mach-shmobile/clock-emev2.c
kzm9d(without -reference) still uses sh-clkfwk version.
Because two of that framework can not live in one kernel binary,
there will be SoCs and Boards that can not be in one binary as
multiplatform binary or so.
For example, kzm9d and kzm9d-reference is now exclusive.
Signed-off-by: Takashi Yoshii
---
arch/arm/mach-shmobile/Kconfig | 1 +
arch/arm/mach-shmobile/board-kzm9d-reference.c | 5 ++---
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 50bab8d..d20d4ce 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -237,6 +237,7 @@ config MACH_KZM9D_REFERENCE
depends on ARCH_EMEV2
select REGULATOR_FIXED_VOLTAGE if REGULATOR
select USE_OF
+ select COMMON_CLK
---help---
Use reference implementation of KZM9D board support
which makes a greater use of device tree at the expense
diff --git a/arch/arm/mach-shmobile/board-kzm9d-reference.c
b/arch/arm/mach-shmobile/board-kzm9d-reference.c
index 8f8bb2f..e0b8317 100644
--- a/arch/arm/mach-shmobile/board-kzm9d-reference.c
+++ b/arch/arm/mach-shmobile/board-kzm9d-reference.c
@@ -20,15 +20,14 @@
#include
#include
+#include
#include
#include
#include
static void __init kzm9d_add_standard_devices(void)
{
- if (!IS_ENABLED(CONFIG_COMMON_CLK))
- emev2_clock_init();
-
+ of_clk_init(NULL);
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
--
1.8.1.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/
[PATCH 5/6] clk: emev2: Add support for emev2 SMU clocks with DT
Common clock framework version of emev2 clock support.
smu_clkdiv and smu_gclk are handled.
So far, reparent is not implemented, and is fixed to index #0.
SMU and small numbers of clocks are described in emev2.dtsi.
That function and numbers of clocks are equivalent to current
sh-clkfwk version. It is just enough to run kzm9d-reference.
Signed-off-by: Takashi Yoshii
---
arch/arm/boot/dts/emev2.dtsi | 84 +++
drivers/clk/Makefile | 2 +
drivers/clk/shmobile/Makefile| 5 ++
drivers/clk/shmobile/clk-emev2.c | 104 +++
4 files changed, 195 insertions(+)
create mode 100644 drivers/clk/shmobile/Makefile
create mode 100644 drivers/clk/shmobile/clk-emev2.c
diff --git a/arch/arm/boot/dts/emev2.dtsi b/arch/arm/boot/dts/emev2.dtsi
index 9063a44..c6a4767 100644
--- a/arch/arm/boot/dts/emev2.dtsi
+++ b/arch/arm/boot/dts/emev2.dtsi
@@ -52,34 +52,118 @@
<0 121 4>;
};
+ smu {
+ compatible = "renesas,emev2-smu";
+ reg = <0xe011 0x1>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ c32ki: c32ki {
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ #clock-cells = <0>;
+ };
+ pll3_fo: pll3_fo {
+ compatible = "fixed-factor-clock";
+ clocks = <>;
+ clock-div = <1>;
+ clock-mult = <7000>;
+ #clock-cells = <0>;
+ };
+ usia_u0_sclkdiv: usia_u0_sclkdiv {
+ compatible = "renesas,emev2-smu-clkdiv";
+ reg = <0x610 0>;
+ clocks = <_fo>;
+ #clock-cells = <0>;
+ };
+ usib_u1_sclkdiv: usib_u1_sclkdiv {
+ compatible = "renesas,emev2-smu-clkdiv";
+ reg = <0x65c 0>;
+ clocks = <_fo>;
+ #clock-cells = <0>;
+ };
+ usib_u2_sclkdiv: usib_u2_sclkdiv {
+ compatible = "renesas,emev2-smu-clkdiv";
+ reg = <0x65c 16>;
+ clocks = <_fo>;
+ #clock-cells = <0>;
+ };
+ usib_u3_sclkdiv: usib_u3_sclkdiv {
+ compatible = "renesas,emev2-smu-clkdiv";
+ reg = <0x660 0>;
+ clocks = <_fo>;
+ #clock-cells = <0>;
+ };
+ usia_u0_sclk: usia_u0_sclk {
+ compatible = "renesas,emev2-smu-gclk";
+ reg = <0x4a0 1>;
+ clocks = <_u0_sclkdiv>;
+ #clock-cells = <0>;
+ };
+ usib_u1_sclk: usib_u1_sclk {
+ compatible = "renesas,emev2-smu-gclk";
+ reg = <0x4b8 1>;
+ clocks = <_u1_sclkdiv>;
+ #clock-cells = <0>;
+ };
+ usib_u2_sclk: usib_u2_sclk {
+ compatible = "renesas,emev2-smu-gclk";
+ reg = <0x4bc 1>;
+ clocks = <_u2_sclkdiv>;
+ #clock-cells = <0>;
+ };
+ usib_u3_sclk: usib_u3_sclk {
+ compatible = "renesas,emev2-smu-gclk";
+ reg = <0x4c0 1>;
+ clocks = <_u3_sclkdiv>;
+ #clock-cells = <0>;
+ };
+ sti_sclk: sti_sclk {
+ compatible = "renesas,emev2-smu-gclk";
+ reg = <0x528 1>;
+ clocks = <>;
+ #clock-cells = <0>;
+ };
+ };
+
sti@e018 {
compatible = "renesas,em-sti";
reg = <0xe018 0x54>;
interrupts = <0 125 0>;
+ clocks = <_sclk>;
+ clock-names = "sclk";
};
uart@e102 {
compatible = "renesas,em-uart";
reg = <0xe102 0x38>;
interrupts = <0 8 0>;
+ clocks = <_u0_sclk>;
+ clock-names = "sclk";
};
uart@e103 {
compatible = "renesas,em-uart";
reg = <0xe103 0x38>;
interrupts = <0 9 0>;
+ clocks = <_u1_sclk>;
+ clock-names = "sclk";
};
uart@e104 {
compatible = "renesas,em-uart";
reg = <0xe104 0x38>;
interrupts = <0 10 0>;
+ clocks = <_u2_sclk>;
+ clock-names = "sclk";
};
uart@e105 {
Re: [PATCH v6] fat: additions to support fat_fallocate
2013/9/23, OGAWA Hirofumi :
> Namjae Jeon writes:
>
+ if (MSDOS_I(inode)->mmu_private > round_up(i_size, sb->s_blocksize)
+ && pos > i_size) {
+ err = fat_zero_falloc_area(file, mapping, pos);
+ if (err) {
+ fat_msg(sb, KERN_ERR,
+ "Error (%d) zeroing fallocated area", err);
+ return err;
+ }
+ }
>>>
>>> Again, I'm not fan of this way.
>>>
>>> Normally, get_block() returns with buffer_new(). Then, caller checks
>>> blockdev buffer with
>>>
>>> unmap_underlying_metadata(bh->b_bdev, bh->b_blocknr);
>>>
>>> then, zeroed buffer. Do we really don't need to check this race?
>> We considered after your advice before. we reach for the conclusion
>> that use this method.
>> because, Cluster is already allocated in fat fallocate and
>> when we write with radom offset over i_size on fallocated region, It
>> will be hit by fat cache in fat_bmap of get_block, which mean buffer
>> is not set to new.
>
> Hm, how does it hit to fat cache? I think fat_alloc_clusters() and
> fat_chain_add() doesn't update fat cache, right? I.e. initial write
> after fallocate() should not hit fat cache over i_size?
Ah.. Sorry for wrong reply. old memory make me confusing.
By allocating cluster in fat fallocate, when write, fat_bmap of
get_block return physical sector number.
So buffer is not set to new in _fat_get_block.
When we fallocate with keep size on -> only clusters are added to the
fat chain calling fat_get_cluster(),and add the cluster to cluster
chain.
This doesn’t call fat_get_block() .
Now when we try to write in the fallocated region in the
fat_write_begin() when it is called first time it checks that the
mismatch is present between the mmu_private and mmu_actual (i.e., the
file has pre-allocated blocks), and hence zero out the region ;
Since buffer_new() is not set for fallocated region by fat_get_block()
, we explicitly zero out the lseek'ed region using
“fat_zero_falloc_area” and normal write occurs beyond that,and i_size
is updated accordingly.
Thanks :)
>
> Thanks.
> --
> OGAWA Hirofumi
>
--
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: Lightweight type analysis for memory safety through verification of API uses
Marcelo Sousa writes: > I've designed and implemented a tool similar to sparse and CQUAL that > does type inference of user specified type qualifiers, e.g. iomem. It > receives an API specification with the type qualifiers and also a > partial order, e.g. IOAddr is not compatible with KernelAddr and > ioremap returns a pointer to IOAddr while __kmalloc returns a pointer > to a KernelAddr. Tracking iomem is ultimatively not very interesting, as in many common architectures it's just a normal pointer. __user is much more interesting, as that is real security bugs. You can probably find some in standard security advisories. Really interesting would be static lock set tracking for pointers and similar. -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] kernel/groups.c: consider about NULL for 'group_info' in all related extern functions
Hello, On Tue, Sep 24, 2013 at 11:42:56AM +0800, Chen Gang wrote: > Hmm... can user be permitted to call other system call (e.g. getgroups) > before call groups_alloc()? (may the user space already give check, but > for our kernel, we can not only depend on their checking). I don't think so. > According to group_alloc() and setgroups() usage in kernel source code, > 'group_info' may be not set if kernel/process is running (although user > space may be sure "if kernel is running, 'group_info' must be set"). > > The below is the proof for "kernel itself can not be sure 'group_info' > must be set during kernel/process is running", please check, thanks. ... > The related conclusion: > > during kernel startup or process creation, kernel does not intend to set > 'group_info'. No, this is not a proof or any meaningful conclusion. This is just some random suspicions combined with supposedly related grep output. > In extern function groups_search (which also called by export function > in_group_p and in_egroup_p), it checks "if 'cred->group_info' is NULL". > > So "kernel/groups.c" have 9 extern/export/system-call functions, and > 4/9 notice about "if 'cred->group_info' is NULL" (e.g. groups_alloc, > groups_search, in_group_p, in_egroup_p). > > So for API self-consistency, all of extern/export/system-call functions > need notice about it. I'm afraid this isn't useful. If you want to change the code, you actually need to understand what's going on. "this seems weird to me" is a good starting point but you need to go way beyond that to actually make changes. Thanks. -- tejun -- 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 0/6] ARM: shmobile: kzm9d-reference: migrate to common clock framework with DT
This patch series makes kzm9d-reference to move to new clk implementation based on the common clock framework and device tree. First three are for preparation. [PATCH 1/6] clocksource: em_sti: convert to clk_prepare/unprepare [PATCH 2/6] serial8250-em: convert to clk_prepare/unprepare [PATCH 3/6] sh: clkfwk: Select sh-/common- clkfwk alternatively Next one is a proposal document of DT bindings. [PATCH 4/6] ARM: shmobile: emev2: Define SMU clock DT bindings This is the implementation, and dts which carries clock tree description. [PATCH 5/6] clk: emev2: Add support for emev2 SMU clocks with DT Last one is small modification needed for migration. [PATCH 6/6] ARM: shmobile: kzm9d-reference: Use common clock These patches do not remove sh-clkfwk version, even on emev2. kzm9d(without -reference) target still uses sh-clkfwk. I believe this method encourages step-by-step migration on other sh-mobile targets, too. Patches should be applied and compiled both on v3.12-rc2 and kernel/git/horms/renesas.git tag:renesas-devel-20130922 Confirmed on kernel/git/horms/renesas.git tag:renesas-devel-20130922 for boot up to command prompt. - kzm9d board / multiplatform + kzm9d-reference configuration - kzm9d board / kzm9d-reference configuration - kzm9d board / kzm9d (with sh-clkfwk) configuration for regression. - ape6evm (with sh-clkfwk) for regression. for compile only - sh7757lcr (in arch/sh with sh-clkfwk) for regression. Shinya Kuribayashi (2): clocksource: em_sti: convert to clk_prepare/unprepare serial8250-em: convert to clk_prepare/unprepare Takashi YOSHII (4): sh: clkfwk: Select sh-/common- clkfwk alternatively ARM: shmobile: emev2: Define SMU clock DT bindings clk: emev2: Add support for emev2 SMU clocks with DT ARM: shmobile: kzm9d-reference: Use common clock framework .../devicetree/bindings/clock/emev2-clock.txt | 99 arch/arm/Kconfig | 2 +- arch/arm/boot/dts/emev2.dtsi | 84 + arch/arm/mach-shmobile/Kconfig | 1 + arch/arm/mach-shmobile/board-kzm9d-reference.c | 5 +- arch/sh/Kconfig| 1 + drivers/clk/Makefile | 2 + drivers/clk/shmobile/Makefile | 5 + drivers/clk/shmobile/clk-emev2.c | 104 + drivers/clocksource/em_sti.c | 4 +- drivers/sh/clk/Makefile| 3 +- drivers/tty/serial/8250/8250_em.c | 6 +- 12 files changed, 305 insertions(+), 11 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/emev2-clock.txt create mode 100644 drivers/clk/shmobile/Makefile create mode 100644 drivers/clk/shmobile/clk-emev2.c -- 1.8.1.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/
Re: [RFC] PWM: Add support for pwm-bcm2835
On 09/21/2013 04:09 AM, Johannes Thumshirn wrote:
> Add support for the PWM controller of the BCM2835 SoC found on Raspberry PI
>
> The driver isn't as much tested as I wanted it to be and devicetree
> support is still missing, but I thought it would be nice to have some
> comments if I'm in the right direction.
Presumably if DT support is missing, the driver can't have been tested
at all?
> diff --git a/drivers/pwm/pwm-bcm2835.c b/drivers/pwm/pwm-bcm2835.c
> +/* Address Mappings (offsets) from Broadcom BCM2835 ARM Periperals Manual
> + * Section 9.6 Page 141ff
s/141ff/141/
> +/* Control registers 0 and 1 are mirrored on a distance of 4 bits */
> +#define HWPWM(x) ((x) << 4)
Distances between registers aren't really measured in bits although
admittedly a certain minimum number of bits would be required to
represent that distance. I would suggest s/4 bits/16 bytes/. People are
likely to be familiar with "<< 4" being equivalent to "* 16".
> +/* TODO: We only need this register set once and use HWPWM macro to
> + * access 2nd output
> + */
I don't really understand what the TODO message says still needs to be
done. The comment format is wrong; /* should be on its own line.
> +static inline u32 bcm2835_readl(struct bcm2835_pwm_dev *chip,
> + unsigned int hwpwm, unsigned int num)
> +{
> + num <<= HWPWM(hwpwm);
This doesn't work for hwpwm==1; HWPWM() already shifted the ID left, so
you want "num += HWPWM(hwpwm)" here, I think. But as Thierry said, this
function really doesn't need to do anything other than take an offset.
Same comment for bcm2835_writel().
BTW, bcm2835_readl() isn't a good name for a PWM-specific function,
since it's pretty generic. While the name is static, so it won't cause
linker problems, it might confuse a symbolic debugger. Better make it
bcm2835_pwm_readl().
> +static int bcm2835_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> + int duty_ns, int period_ns)
> + /* write period */
> + bcm2835_writel(bcm, pwm->hwpwm, BCM2835_PWM_RNG1, period_ns);
> +
> + /* write duty */
> + bcm2835_writel(bcm, pwm->hwpwm, BCM2835_PWM_DAT1, duty_ns);
Presumably those registers are a count of clock cycles, not an absolute
time in ns. The two are only equal if the PWM module clock runs at 1GHz.
So, don't you need to convert time to clock cycle count here, using
clk_get_rate(pwm_clk) as the ratio?
> +static int bcm2835_pwm_probe(struct platform_device *pdev)
...
> + bcm = devm_kzalloc(>dev, sizeof(*bcm), GFP_KERNEL);
> + if (!bcm)
> + return -ENOMEM;
...
> + ret = pwmchip_add(>chip);
> + if (ret < 0)
> + return ret;
> +
> + platform_set_drvdata(pdev, bcm);
You should really set the drvdata as soon as you've allocated it, and at
least before calling pwmchip_add(); as soon as you've added the PWM
chip, the PWM core could call functions on the PWM object, and if those
callbacks rely on the drvdata, then they're going to fail if the drvdata
hasn't been set yet.
> +static const struct of_device_id bcm2835_pwm_of_match[] = {
> + { .compatible = "brcm,bcm2835-pwm" },
> + {},
> +};
You need to write a DT binding document if you're going to ad DT support.
--
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] Fix coalescing host bridge windows in arch/x86/pci/acpi.c
On 2013/9/23 14:15, Alexey Neyman wrote: > [Resending due to no response to the original message in a week] > > Hi all, > > I have a board with a BIOS bug that reports the following I/O port regions in > _CRS on one of the host bridges: > > 0x-0x03af // #0 > 0x03e0-0x0cf7 // #1 > 0x03b0-0x03bb // #2 > 0x03c0-0x03df // #3 > 0x-0xdfff // #4 > 0xf000-0x // #5 > > Obviously, region number #4 is erroneous as it overlaps with regions #0..3. > The code in coalesce_windows() in arch/x86/pci/acpi.c attempts to recover > from > such kind of BIOS bugs by merging the overlapping regions. Current code > expands region #0 to 0x-0xd and makes region #4 ignored. As a result, > overlap of the expanded region #0 with regions #1..3 remains undetected (as > the inner loop already compared them with region #0). As a result, regions > #1..3 are inserted into the resource tree even though they overlap with > adjusted region #0 - which later results in resource conflicts for PCI > devices > with IO ports in one of those regions (e.g., for an PCI IDE controller in > legacy mode - which has port 0x3f6). The kernel then refuses to initialize > these devices. > > The fix: instead of expanding res1 and ignoring res2, do the opposite. The > res2 window is yet to be compared against all windows between res1 and res2 > (regions #1..3 in the above example), so the resulting resource map will > include just the expanded region - and will ignore any overlapping ones. > > Signed-off-by: Alexey Neyman > It looks fine to me, but I have no platform to test it. :) -- Thanks! Yijing -- 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] fs/bio-integrity: remove duplicate code
Most code of function bio_integrity_verify and bio_integrity_generate
is the same, so introduce a common function bio_integrity_generate_verify()
to remove the reduplicate code.
v2:
fix a minor logic mistake.
Signed-off-by: Gu Zheng
---
fs/bio-integrity.c | 86 +++-
1 files changed, 38 insertions(+), 48 deletions(-)
diff --git a/fs/bio-integrity.c b/fs/bio-integrity.c
index 6025084..4773ab2 100644
--- a/fs/bio-integrity.c
+++ b/fs/bio-integrity.c
@@ -287,24 +287,25 @@ int bio_integrity_get_tag(struct bio *bio, void *tag_buf,
unsigned int len)
EXPORT_SYMBOL(bio_integrity_get_tag);
/**
- * bio_integrity_generate - Generate integrity metadata for a bio
- * @bio: bio to generate integrity metadata for
- *
- * Description: Generates integrity metadata for a bio by calling the
- * block device's generation callback function. The bio must have a
- * bip attached with enough room to accommodate the generated
- * integrity metadata.
+ * bio_integrity_generate_verify - Generate/verify integrity metadata for a bio
+ * @bio: bio to generate/verify integrity metadata for
+ * @operate: operate number, 1 for generate, 0 for verify
*/
-static void bio_integrity_generate(struct bio *bio)
+static int bio_integrity_generate_verify(struct bio *bio, int operate)
{
struct blk_integrity *bi = bdev_get_integrity(bio->bi_bdev);
struct blk_integrity_exchg bix;
struct bio_vec *bv;
- sector_t sector = bio->bi_sector;
- unsigned int i, sectors, total;
+ sector_t sector;
+ unsigned int i, sectors, total, ret;
void *prot_buf = bio->bi_integrity->bip_buf;
- total = 0;
+ if (operate)
+ sector = bio->bi_sector;
+ else
+ sector = bio->bi_integrity->bip_sector;
+
+ ret = total = 0;
bix.disk_name = bio->bi_bdev->bd_disk->disk_name;
bix.sector_size = bi->sector_size;
@@ -314,8 +315,15 @@ static void bio_integrity_generate(struct bio *bio)
bix.data_size = bv->bv_len;
bix.prot_buf = prot_buf;
bix.sector = sector;
-
- bi->generate_fn();
+ if (operate) {
+ bi->generate_fn();
+ } else {
+ ret = bi->verify_fn();
+ if (ret) {
+ kunmap_atomic(kaddr);
+ return ret;
+ }
+ }
sectors = bv->bv_len / bi->sector_size;
sector += sectors;
@@ -325,6 +333,22 @@ static void bio_integrity_generate(struct bio *bio)
kunmap_atomic(kaddr);
}
+
+ return ret;
+}
+
+/**
+ * bio_integrity_generate - Generate integrity metadata for a bio
+ * @bio: bio to generate integrity metadata for
+ *
+ * Description: Generates integrity metadata for a bio by calling the
+ * block device's generation callback function. The bio must have a
+ * bip attached with enough room to accommodate the generated
+ * integrity metadata.
+ */
+static void bio_integrity_generate(struct bio *bio)
+{
+ bio_integrity_generate_verify(bio, 1);
}
static inline unsigned short blk_integrity_tuple_size(struct blk_integrity *bi)
@@ -439,41 +463,7 @@ EXPORT_SYMBOL(bio_integrity_prep);
*/
static int bio_integrity_verify(struct bio *bio)
{
- struct blk_integrity *bi = bdev_get_integrity(bio->bi_bdev);
- struct blk_integrity_exchg bix;
- struct bio_vec *bv;
- sector_t sector = bio->bi_integrity->bip_sector;
- unsigned int i, sectors, total, ret;
- void *prot_buf = bio->bi_integrity->bip_buf;
-
- ret = total = 0;
- bix.disk_name = bio->bi_bdev->bd_disk->disk_name;
- bix.sector_size = bi->sector_size;
-
- bio_for_each_segment(bv, bio, i) {
- void *kaddr = kmap_atomic(bv->bv_page);
- bix.data_buf = kaddr + bv->bv_offset;
- bix.data_size = bv->bv_len;
- bix.prot_buf = prot_buf;
- bix.sector = sector;
-
- ret = bi->verify_fn();
-
- if (ret) {
- kunmap_atomic(kaddr);
- return ret;
- }
-
- sectors = bv->bv_len / bi->sector_size;
- sector += sectors;
- prot_buf += sectors * bi->tuple_size;
- total += sectors * bi->tuple_size;
- BUG_ON(total > bio->bi_integrity->bip_size);
-
- kunmap_atomic(kaddr);
- }
-
- return ret;
+ return bio_integrity_generate_verify(bio, 0);
}
/**
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/groups.c: consider about NULL for 'group_info' in all related extern functions
On 09/23/2013 11:06 PM, Tejun Heo wrote: > Hello, > > (I have no idea about this but Andrew tagged me, probably thinking it > was related to cgroups, so here it goes ;) > First, thank you for spending your time resource to discuss this patch. > On Tue, Aug 20, 2013 at 11:01:14AM +0800, Chen Gang wrote: >> groups_alloc() can return NULL for 'group_info', also group_search() >> already considers about NULL for 'group_info', so can assume the caller >> has right to use all related extern functions when 'group_info' is NULL. >> >> For groups_free(), need check NULL to match groups_alloc(), just like >> kmalloc/free(). > > While it is somewhat customary to make free routines handle NULL > inputs, the convention isn't a very strong one and given that the > above change doesn't actually benefit any of the existing use cases, > it seems gratuituous. > Hmm... can user be permitted to call other system call (e.g. getgroups) before call groups_alloc()? (may the user space already give check, but for our kernel, we can not only depend on their checking). According to group_alloc() and setgroups() usage in kernel source code, 'group_info' may be not set if kernel/process is running (although user space may be sure "if kernel is running, 'group_info' must be set"). The below is the proof for "kernel itself can not be sure 'group_info' must be set during kernel/process is running", please check, thanks. The related usage of group_alloc() is below: arch/s390/kernel/compat_linux.c:257: group_info = groups_alloc(gidsetsize); drivers/staging/lustre/lustre/include/linux/lustre_common.h:10: ginfo = groups_alloc(0); drivers/staging/lustre/lustre/ptlrpc/service.c:2287: ginfo = groups_alloc(0); fs/nfsd/auth.c:46:gi = groups_alloc(0); fs/nfsd/auth.c:55:gi = groups_alloc(rqgi->ngroups); kernel/uid16.c:184: group_info = groups_alloc(gidsetsize); /* called by setgroups16 */ kernel/groups.c:241: group_info = groups_alloc(gidsetsize); /* called by setgroups */ net/sunrpc/svcauth_unix.c:506:ug.gi = groups_alloc(gids); net/sunrpc/svcauth_unix.c:752:cred->cr_group_info = groups_alloc(0); net/sunrpc/svcauth_unix.c:823:cred->cr_group_info = groups_alloc(slen); net/sunrpc/auth_gss/gss_rpc_xdr.c:218:creds->cr_group_info = groups_alloc(N); net/sunrpc/auth_gss/svcauth_gss.c:467:rsci.cred.cr_group_info = groups_alloc(N); except "kernel/*", others are all related with sub-systems or architectures, so we need search 'setgroups'. The related usage of setgroups() is below: arch/ia64/include/uapi/asm/unistd.h:69:#define __NR_setgroups 1078 arch/ia64/kernel/entry.S:1531:data8 sys_setgroups arch/ia64/kernel/fsys.S:606: data8 0 // setgroups arch/microblaze/include/uapi/asm/unistd.h:95:#define __NR_setgroups 81 /* ok */ arch/microblaze/include/uapi/asm/unistd.h:222:#define __NR_setgroups32 206 /* ok - without 32 */ arch/microblaze/kernel/syscall_table.S:84:.long sys_setgroups arch/microblaze/kernel/syscall_table.S:209: .long sys_setgroups arch/arm64/include/asm/unistd32.h:105:__SYSCALL(81, sys_setgroups16) arch/arm64/include/asm/unistd32.h:230:__SYSCALL(206, sys_setgroups) arch/mn10300/include/uapi/asm/unistd.h:95:#define __NR_setgroups 81 arch/mn10300/include/uapi/asm/unistd.h:220:#define __NR_setgroups32 206 arch/mn10300/kernel/entry.S:511: .long sys_setgroups16 arch/mn10300/kernel/entry.S:636: .long sys_setgroups arch/m68k/include/uapi/asm/unistd.h:89:#define __NR_setgroups 81 arch/m68k/include/uapi/asm/unistd.h:214:#define __NR_setgroups32 206 arch/m68k/kernel/syscalltable.S:104: .long sys_setgroups16 arch/m68k/kernel/syscalltable.S:229: .long sys_setgroups arch/sparc/include/uapi/asm/unistd.h:120:#define __NR_setgroups 80 /* Common */ arch/sparc/include/uapi/asm/unistd.h:123:#define __NR_setgroups32 82 /* Linux sparc32, setpgrp under SunOS */ arch/sparc/kernel/systbls_64.S:37:/*80*/ .word sys_setgroups16, sys_getpgrp, sys_setgroups, compat_sys_setitimer, sys32_ftruncate64 arch/sparc/kernel/systbls_64.S:115:/*80*/ .word sys_setgroups, sys_getpgrp, sys_nis_syscall, sys_setitimer, sys_nis_syscall arch/sparc/kernel/systbls_32.S:35:/*80*/ .long sys_setgroups16, sys_getpgrp, sys_setgroups, sys_setitimer, sys_ftruncate64 arch/alpha/include/uapi/asm/unistd.h:84:#define __NR_setgroups 80 arch/alpha/kernel/systbls.S:94: .quad sys_setgroups /* 80 */ arch/sh/include/uapi/asm/unistd_64.h:98:#define __NR_setgroups 81 arch/sh/include/uapi/asm/unistd_64.h:223:#define __NR_setgroups32 206 arch/sh/include/uapi/asm/unistd_32.h:93:#define __NR_setgroups 81
[PATCH 1/3] ARM: debug: Create CONFIG_DEBUG_MSM_UART and re-organize the selects for MSM
Create the hidden config DEBUG_MSM_UART and clean-up the default selection for CONFIG_DEBUG_LL_INCLUDE. Signed-off-by: Rohit Vaswani --- arch/arm/Kconfig.debug | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 9762c84..e18a6fc 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -318,6 +318,7 @@ choice config DEBUG_MSM_UART1 bool "Kernel low-level debugging messages via MSM UART1" depends on ARCH_MSM7X00A || ARCH_MSM7X30 || ARCH_QSD8X50 + select DEBUG_MSM_UART help Say Y here if you want the debug print routines to direct their output to the first serial port on MSM devices. @@ -325,6 +326,7 @@ choice config DEBUG_MSM_UART2 bool "Kernel low-level debugging messages via MSM UART2" depends on ARCH_MSM7X00A || ARCH_MSM7X30 || ARCH_QSD8X50 + select DEBUG_MSM_UART help Say Y here if you want the debug print routines to direct their output to the second serial port on MSM devices. @@ -332,6 +334,7 @@ choice config DEBUG_MSM_UART3 bool "Kernel low-level debugging messages via MSM UART3" depends on ARCH_MSM7X00A || ARCH_MSM7X30 || ARCH_QSD8X50 + select DEBUG_MSM_UART help Say Y here if you want the debug print routines to direct their output to the third serial port on MSM devices. @@ -340,6 +343,7 @@ choice bool "Kernel low-level debugging messages via MSM 8660 UART" depends on ARCH_MSM8X60 select MSM_HAS_DEBUG_UART_HS + select DEBUG_MSM_UART help Say Y here if you want the debug print routines to direct their output to the serial port on MSM 8660 devices. @@ -348,6 +352,7 @@ choice bool "Kernel low-level debugging messages via MSM 8960 UART" depends on ARCH_MSM8960 select MSM_HAS_DEBUG_UART_HS + select DEBUG_MSM_UART help Say Y here if you want the debug print routines to direct their output to the serial port on MSM 8960 devices. @@ -880,6 +885,10 @@ config DEBUG_STI_UART bool depends on ARCH_STI +config DEBUG_MSM_UART + bool + depends on ARCH_MSM + config DEBUG_LL_INCLUDE string default "debug/8250.S" if DEBUG_LL_UART_8250 || DEBUG_UART_8250 @@ -895,11 +904,7 @@ config DEBUG_LL_INCLUDE DEBUG_IMX53_UART ||\ DEBUG_IMX6Q_UART || \ DEBUG_IMX6SL_UART - default "debug/msm.S" if DEBUG_MSM_UART1 || \ -DEBUG_MSM_UART2 || \ -DEBUG_MSM_UART3 || \ -DEBUG_MSM8660_UART || \ -DEBUG_MSM8960_UART + default "debug/msm.S" if DEBUG_MSM_UART default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART default "debug/sirf.S" if DEBUG_SIRFPRIMA2_UART1 || DEBUG_SIRFMARCO_UART1 default "debug/sti.S" if DEBUG_STI_UART -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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/
[PATCHv4 2/3] ARM: msm: Add support for APQ8074 Dragonboard
This patch adds basic board support for APQ8074 Dragonboard
which belongs to the Snapdragon 800 family.
For now, just support a basic machine with device tree.
Signed-off-by: Rohit Vaswani
---
arch/arm/Kconfig.debug | 9 +++
arch/arm/boot/dts/Makefile | 3 ++-
arch/arm/boot/dts/qcom-apq8074-dragonboard.dts | 6 +
arch/arm/boot/dts/qcom-msm8974.dtsi| 35 ++
arch/arm/include/debug/msm.S | 5
arch/arm/mach-msm/Kconfig | 13 ++
arch/arm/mach-msm/board-dt.c | 9 +++
7 files changed, 79 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
create mode 100644 arch/arm/boot/dts/qcom-msm8974.dtsi
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index e18a6fc..959b2c7 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -357,6 +357,15 @@ choice
Say Y here if you want the debug print routines to direct
their output to the serial port on MSM 8960 devices.
+ config DEBUG_MSM8974_UART
+ bool "Kernel low-level debugging messages via MSM 8974 UART"
+ depends on ARCH_MSM8974
+ select MSM_HAS_DEBUG_UART_HS
+ select DEBUG_MSM_UART
+ help
+ Say Y here if you want the debug print routines to direct
+ their output to the serial port on MSM 8974 devices.
+
config DEBUG_MVEBU_UART
bool "Kernel low-level debugging messages via MVEBU UART (old
bootloaders)"
depends on ARCH_MVEBU
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 000cf76..e71a3ec 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -102,7 +102,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
kirkwood-openblocks_a6.dtb
dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
- msm8960-cdp.dtb
+ msm8960-cdp.dtb \
+ qcom-apq8074-dragonboard.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
armada-370-mirabox.dtb \
armada-370-netgear-rn102.dtb \
diff --git a/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
new file mode 100644
index 000..bb6f3c4
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
@@ -0,0 +1,6 @@
+/include/ "qcom-msm8974.dtsi"
+
+/ {
+ model = "Qualcomm APQ8074 Dragonboard";
+ compatible = "qcom,apq8074-dragonboard", "qcom,apq8074";
+};
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
new file mode 100644
index 000..f04b643
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -0,0 +1,35 @@
+/dts-v1/;
+
+/include/ "skeleton.dtsi"
+
+/ {
+ model = "Qualcomm MSM8974";
+ compatible = "qcom,msm8974";
+ interrupt-parent = <>;
+
+ soc: soc { };
+};
+
+ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ compatible = "simple-bus";
+
+ intc: interrupt-controller@f900 {
+ compatible = "qcom,msm-qgic2";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0xf900 0x1000>,
+ <0xf9002000 0x1000>;
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <1 2 0xf08>,
+<1 3 0xf08>,
+<1 4 0xf08>,
+<1 1 0xf08>;
+ clock-frequency = <1920>;
+ };
+};
diff --git a/arch/arm/include/debug/msm.S b/arch/arm/include/debug/msm.S
index 9166e1b..9d653d4 100644
--- a/arch/arm/include/debug/msm.S
+++ b/arch/arm/include/debug/msm.S
@@ -46,6 +46,11 @@
#define MSM_DEBUG_UART_PHYS0x1644
#endif
+#ifdef CONFIG_DEBUG_MSM8974_UART
+#define MSM_DEBUG_UART_BASE0xFA71E000
+#define MSM_DEBUG_UART_PHYS0xF991E000
+#endif
+
.macro addruart, rp, rv, tmp
#ifdef MSM_DEBUG_UART_PHYS
ldr \rp, =MSM_DEBUG_UART_PHYS
diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
index 2586c28..086bcb9 100644
--- a/arch/arm/mach-msm/Kconfig
+++ b/arch/arm/mach-msm/Kconfig
@@ -64,6 +64,19 @@ config ARCH_MSM_DT
select SPARSE_IRQ
select USE_OF
+config ARCH_MSM8974
+ bool "MSM8974"
+ select ARM_GIC
+ select CPU_V7
+ select HAVE_ARM_ARCH_TIMER
+ select HAVE_SMP
+ select MSM_SCM if SMP
+ select USE_OF
+
+config ARCH_MSM_DT
+ def_bool y
+ depends on (ARCH_MSM8X60 || ARCH_MSM8960 || ARCH_MSM8974)
+
config MSM_HAS_DEBUG_UART_HS
bool
diff --git a/arch/arm/mach-msm/board-dt.c b/arch/arm/mach-msm/board-dt.c
index 266a280..5211e80 100644
--- a/arch/arm/mach-msm/board-dt.c
+++ b/arch/arm/mach-msm/board-dt.c
@@ -26,7
[no subject]
Date: Mon, 23 Sep 2013 19:51:25 -0700 Subject: [PATCH 1/3] ARM: debug: Create CONFIG_DEBUG_MSM_UART and re-organize the selects for MSM Create the hidden config DEBUG_MSM_UART and clean-up the default selection for CONFIG_DEBUG_LL_INCLUDE. Signed-off-by: Rohit Vaswani --- arch/arm/Kconfig.debug | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 9762c84..e18a6fc 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -318,6 +318,7 @@ choice config DEBUG_MSM_UART1 bool "Kernel low-level debugging messages via MSM UART1" depends on ARCH_MSM7X00A || ARCH_MSM7X30 || ARCH_QSD8X50 + select DEBUG_MSM_UART help Say Y here if you want the debug print routines to direct their output to the first serial port on MSM devices. @@ -325,6 +326,7 @@ choice config DEBUG_MSM_UART2 bool "Kernel low-level debugging messages via MSM UART2" depends on ARCH_MSM7X00A || ARCH_MSM7X30 || ARCH_QSD8X50 + select DEBUG_MSM_UART help Say Y here if you want the debug print routines to direct their output to the second serial port on MSM devices. @@ -332,6 +334,7 @@ choice config DEBUG_MSM_UART3 bool "Kernel low-level debugging messages via MSM UART3" depends on ARCH_MSM7X00A || ARCH_MSM7X30 || ARCH_QSD8X50 + select DEBUG_MSM_UART help Say Y here if you want the debug print routines to direct their output to the third serial port on MSM devices. @@ -340,6 +343,7 @@ choice bool "Kernel low-level debugging messages via MSM 8660 UART" depends on ARCH_MSM8X60 select MSM_HAS_DEBUG_UART_HS + select DEBUG_MSM_UART help Say Y here if you want the debug print routines to direct their output to the serial port on MSM 8660 devices. @@ -348,6 +352,7 @@ choice bool "Kernel low-level debugging messages via MSM 8960 UART" depends on ARCH_MSM8960 select MSM_HAS_DEBUG_UART_HS + select DEBUG_MSM_UART help Say Y here if you want the debug print routines to direct their output to the serial port on MSM 8960 devices. @@ -880,6 +885,10 @@ config DEBUG_STI_UART bool depends on ARCH_STI +config DEBUG_MSM_UART + bool + depends on ARCH_MSM + config DEBUG_LL_INCLUDE string default "debug/8250.S" if DEBUG_LL_UART_8250 || DEBUG_UART_8250 @@ -895,11 +904,7 @@ config DEBUG_LL_INCLUDE DEBUG_IMX53_UART ||\ DEBUG_IMX6Q_UART || \ DEBUG_IMX6SL_UART - default "debug/msm.S" if DEBUG_MSM_UART1 || \ -DEBUG_MSM_UART2 || \ -DEBUG_MSM_UART3 || \ -DEBUG_MSM8660_UART || \ -DEBUG_MSM8960_UART + default "debug/msm.S" if DEBUG_MSM_UART default "debug/omap2plus.S" if DEBUG_OMAP2PLUS_UART default "debug/sirf.S" if DEBUG_SIRFPRIMA2_UART1 || DEBUG_SIRFMARCO_UART1 default "debug/sti.S" if DEBUG_STI_UART -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH V2 0/2] Auto stop async-write on block device when device removed.
>majianpeng writes:
>
>> For async-write on block device,if device removed,but the vfs don't know it.
>> It will continue to do.
>> Patch1 set size of inode of block device to zero when removed disk.By
>> this,vfs know
>> disk changed.
>> Path2 add size-check on blk_aio_write.If pos of write larger than size of
>> inode,it will
>> return zero.So the user can check disk state.
>
>OK, so the basic problem is that __generic_file_aio_write will always
>return 0 after device removal, yes? I'm not sure why that's a real
>issue, can you explain exactly why you're trying to change this?
>
At prenset, the __generic_file_aio_write don't return zero rather that the
wanted size.
So the user can't know the disk removed.
For example:
dd if=/dev/zero of=usb-disk bs=64k
When removed usb-disk, dd stoped until reached the endof usb-disk.
Using this patch, after removed disk, the aio-write will return zero.I think
the upper user will check.
(or if the size of block is zero, we return -ENOSPC).
>As for your patches, I don't think that putting the i_size_write into
>invalidate_partitions is a good idea. Consider the case of rescanning
>partitions: you will always detect a size change now, which is not good.
>
Yes.But in func rescan_partitions, after invalidate_partitions it will call
check_disk_size_change to set size of block_device.
Thanks!
Jianpeng Ma
>Cheers,
>JeffN�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
> 0鹅h���i
Re: [PATCH -v2] EFI: Runtime services virtual mapping
Okay... I see two problems. 1. It looks like we subtract the region size after, rather than before, assigning an address. 2. The second region is assigned the same address in the secondary kernel as in the first, implying the size of the first region was somehow set to zero. Dave Young wrote: >On 09/22/13 at 08:27am, H. Peter Anvin wrote: >> The address that faults is interesting in that it is indeed just >below -4G. The question at hand is probably what information you are >using to build the EFI mappings in the secondary kernel and what could >make it not match the primary. >> >> Assuming it isn't as simple as the mappings never get built at all. > >Here is my debug output, diff efi-mapping-1st-kernel >efi-mapping-2nd-kernel: >Obviously, the high address mapping is not same: > >--- efi-mapping-1.txt 2013-09-24 10:46:09.977746047 +0800 >+++ efi-mapping-2.txt 2013-09-24 10:46:33.871421806 +0800 >@@ -1,30 +1,30 @@ > efi mapping PA 0x80 -> VA 0x80 > efi mapping PA 0x80 -> VA 0x > efi mapping PA 0x7c00 -> VA 0x7c00 >-efi mapping PA 0x7c00 -> VA 0xfffefffe >+efi mapping PA 0x7c00 -> VA 0x > efi mapping PA 0x7d5e2000 -> VA 0x7d5e2000 >-efi mapping PA 0x7d5e2000 -> VA 0xfffefffdf000 >+efi mapping PA 0x7d5e2000 -> VA 0xfffef000 > efi mapping PA 0x7d77d000 -> VA 0x7d77d000 >-efi mapping PA 0x7d77d000 -> VA 0xfffefffde000 >+efi mapping PA 0x7d77d000 -> VA 0xfffee000 > efi mapping PA 0x7d864000 -> VA 0x7d864000 >-efi mapping PA 0x7d864000 -> VA 0xfffeff8d4000 >+efi mapping PA 0x7d864000 -> VA 0xfffeff8f4000 > efi mapping PA 0x7df6e000 -> VA 0x7df6e000 >-efi mapping PA 0x7df6e000 -> VA 0xfffeff6ae000 >+efi mapping PA 0x7df6e000 -> VA 0xfffeff6ce000 > efi mapping PA 0x7e194000 -> VA 0x7e194000 >-efi mapping PA 0x7e194000 -> VA 0xfffeff6ac000 >+efi mapping PA 0x7e194000 -> VA 0xfffeff6cc000 > efi mapping PA 0x7e196000 -> VA 0x7e196000 >-efi mapping PA 0x7e196000 -> VA 0xfffeff696000 >+efi mapping PA 0x7e196000 -> VA 0xfffeff6b6000 > efi mapping PA 0x7e1ac000 -> VA 0x7e1ac000 >-efi mapping PA 0x7e1ac000 -> VA 0xfffeff681000 >+efi mapping PA 0x7e1ac000 -> VA 0xfffeff6a1000 > efi mapping PA 0x7e1c1000 -> VA 0x7e1c1000 >-efi mapping PA 0x7e1c1000 -> VA 0xfffefe041000 >+efi mapping PA 0x7e1c1000 -> VA 0xfffefe061000 > efi mapping PA 0x7f802000 -> VA 0x7f802000 >-efi mapping PA 0x7f802000 -> VA 0xfffefdec2000 >+efi mapping PA 0x7f802000 -> VA 0xfffefdee2000 > efi mapping PA 0x7f981000 -> VA 0x7f981000 >-efi mapping PA 0x7f981000 -> VA 0xfffefde92000 >+efi mapping PA 0x7f981000 -> VA 0xfffefdeb2000 > efi mapping PA 0x7f9b1000 -> VA 0x7f9b1000 >-efi mapping PA 0x7f9b1000 -> VA 0xfffefde6e000 >+efi mapping PA 0x7f9b1000 -> VA 0xfffefde8e000 > efi mapping PA 0x7f9e5000 -> VA 0x7f9e5000 >-efi mapping PA 0x7f9e5000 -> VA 0xfffefd873000 >+efi mapping PA 0x7f9e5000 -> VA 0xfffefd893000 > efi mapping PA 0x7ffe -> VA 0x7ffe >-efi mapping PA 0x7ffe -> VA 0xfffefd853000 >+efi mapping PA 0x7ffe -> VA 0xfffefd873000 > >> >> >> Borislav Petkov wrote: >> >On Sun, Sep 22, 2013 at 08:35:15PM +0800, Dave Young wrote: >> >> I tested your new patch, it works both with efi stub and grub boot >in >> >> 1st kernel. >> > >> >Good, thanks! >> > >> >> But it paniced in kexec boot with my kexec related patcheset, the >> >patchset >> > >> >That's the second kernel, right? >> > >> >> contains 3 patch: >> >> 1. introduce cmdline kexecboot=<0|1|2>; 1 == kexec, 2 == kdump >> >> 2. export physical addr fw_vendor, runtime, tables to >> >/sys/firmware/efi/systab >> >> 3. if kexecboot != 0, use fw_vendor, runtime, tables from >bootparams; >> >Also do not >> >>call SetVirtualAddressMao in case kexecboot. >> >> >> >> The panic happens at the last line of efi_init: >> >> /* clean DUMMY object */ >> >> efi.set_variable(efi_dummy_name, _DUMMY_GUID, >> >> EFI_VARIABLE_NON_VOLATILE | >> >> EFI_VARIABLE_BOOTSERVICE_ACCESS | >> >> EFI_VARIABLE_RUNTIME_ACCESS, >> >> 0, NULL); >> >> >> >> Below is the dmesg: >> >> [0.003359] pid_max: default: 32768 minimum: 301 >> >> [0.004792] BUG: unable to handle kernel paging request at >> >fffefde97e70 >> >> [0.00] IP: [] >> >virt_efi_set_variable+0x40/0x54 >> >> [0.00] PGD 36981067 PUD 35828063 PMD 0 >> > >> >Here it is - fffefde97e70 is not mapped in the pagetable, PMD is >0. >> > >> >Ok, can you upload your patches somewhere and tell me exactly how to >> >reproduce this so that I can take a look too? >> > >> >Thanks. >> >> -- >> Sent from my mobile phone. Please pardon brevity and lack of >formatting. -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a
Re: [PATCH -v2] EFI: Runtime services virtual mapping
On 09/22/13 at 08:27am, H. Peter Anvin wrote: > The address that faults is interesting in that it is indeed just below -4G. > The question at hand is probably what information you are using to build the > EFI mappings in the secondary kernel and what could make it not match the > primary. > > Assuming it isn't as simple as the mappings never get built at all. Here is my debug output, diff efi-mapping-1st-kernel efi-mapping-2nd-kernel: Obviously, the high address mapping is not same: --- efi-mapping-1.txt 2013-09-24 10:46:09.977746047 +0800 +++ efi-mapping-2.txt 2013-09-24 10:46:33.871421806 +0800 @@ -1,30 +1,30 @@ efi mapping PA 0x80 -> VA 0x80 efi mapping PA 0x80 -> VA 0x efi mapping PA 0x7c00 -> VA 0x7c00 -efi mapping PA 0x7c00 -> VA 0xfffefffe +efi mapping PA 0x7c00 -> VA 0x efi mapping PA 0x7d5e2000 -> VA 0x7d5e2000 -efi mapping PA 0x7d5e2000 -> VA 0xfffefffdf000 +efi mapping PA 0x7d5e2000 -> VA 0xfffef000 efi mapping PA 0x7d77d000 -> VA 0x7d77d000 -efi mapping PA 0x7d77d000 -> VA 0xfffefffde000 +efi mapping PA 0x7d77d000 -> VA 0xfffee000 efi mapping PA 0x7d864000 -> VA 0x7d864000 -efi mapping PA 0x7d864000 -> VA 0xfffeff8d4000 +efi mapping PA 0x7d864000 -> VA 0xfffeff8f4000 efi mapping PA 0x7df6e000 -> VA 0x7df6e000 -efi mapping PA 0x7df6e000 -> VA 0xfffeff6ae000 +efi mapping PA 0x7df6e000 -> VA 0xfffeff6ce000 efi mapping PA 0x7e194000 -> VA 0x7e194000 -efi mapping PA 0x7e194000 -> VA 0xfffeff6ac000 +efi mapping PA 0x7e194000 -> VA 0xfffeff6cc000 efi mapping PA 0x7e196000 -> VA 0x7e196000 -efi mapping PA 0x7e196000 -> VA 0xfffeff696000 +efi mapping PA 0x7e196000 -> VA 0xfffeff6b6000 efi mapping PA 0x7e1ac000 -> VA 0x7e1ac000 -efi mapping PA 0x7e1ac000 -> VA 0xfffeff681000 +efi mapping PA 0x7e1ac000 -> VA 0xfffeff6a1000 efi mapping PA 0x7e1c1000 -> VA 0x7e1c1000 -efi mapping PA 0x7e1c1000 -> VA 0xfffefe041000 +efi mapping PA 0x7e1c1000 -> VA 0xfffefe061000 efi mapping PA 0x7f802000 -> VA 0x7f802000 -efi mapping PA 0x7f802000 -> VA 0xfffefdec2000 +efi mapping PA 0x7f802000 -> VA 0xfffefdee2000 efi mapping PA 0x7f981000 -> VA 0x7f981000 -efi mapping PA 0x7f981000 -> VA 0xfffefde92000 +efi mapping PA 0x7f981000 -> VA 0xfffefdeb2000 efi mapping PA 0x7f9b1000 -> VA 0x7f9b1000 -efi mapping PA 0x7f9b1000 -> VA 0xfffefde6e000 +efi mapping PA 0x7f9b1000 -> VA 0xfffefde8e000 efi mapping PA 0x7f9e5000 -> VA 0x7f9e5000 -efi mapping PA 0x7f9e5000 -> VA 0xfffefd873000 +efi mapping PA 0x7f9e5000 -> VA 0xfffefd893000 efi mapping PA 0x7ffe -> VA 0x7ffe -efi mapping PA 0x7ffe -> VA 0xfffefd853000 +efi mapping PA 0x7ffe -> VA 0xfffefd873000 > > > Borislav Petkov wrote: > >On Sun, Sep 22, 2013 at 08:35:15PM +0800, Dave Young wrote: > >> I tested your new patch, it works both with efi stub and grub boot in > >> 1st kernel. > > > >Good, thanks! > > > >> But it paniced in kexec boot with my kexec related patcheset, the > >patchset > > > >That's the second kernel, right? > > > >> contains 3 patch: > >> 1. introduce cmdline kexecboot=<0|1|2>; 1 == kexec, 2 == kdump > >> 2. export physical addr fw_vendor, runtime, tables to > >/sys/firmware/efi/systab > >> 3. if kexecboot != 0, use fw_vendor, runtime, tables from bootparams; > >Also do not > >>call SetVirtualAddressMao in case kexecboot. > >> > >> The panic happens at the last line of efi_init: > >> /* clean DUMMY object */ > >> efi.set_variable(efi_dummy_name, _DUMMY_GUID, > >> EFI_VARIABLE_NON_VOLATILE | > >> EFI_VARIABLE_BOOTSERVICE_ACCESS | > >> EFI_VARIABLE_RUNTIME_ACCESS, > >> 0, NULL); > >> > >> Below is the dmesg: > >> [0.003359] pid_max: default: 32768 minimum: 301 > >> [0.004792] BUG: unable to handle kernel paging request at > >fffefde97e70 > >> [0.00] IP: [] > >virt_efi_set_variable+0x40/0x54 > >> [0.00] PGD 36981067 PUD 35828063 PMD 0 > > > >Here it is - fffefde97e70 is not mapped in the pagetable, PMD is 0. > > > >Ok, can you upload your patches somewhere and tell me exactly how to > >reproduce this so that I can take a look too? > > > >Thanks. > > -- > Sent from my mobile phone. Please pardon brevity and lack of formatting. -- 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/5] memblock: Improve memblock to support allocation from lower address.
Hello, On Tue, Sep 24, 2013 at 10:41:51AM +0800, Zhang Yanfei wrote: > I see. But I think memblock_set_alloc_above_kernel may lose the info > that we are doing bottom-up allocation. So my idea is we introduce > pure bottom-up allocation mode in previous patches and we use the > bottom-up allocation here and limit the start address above the kernel > , with explicit comments to indicate this. It probably doesn't matter either way. I was just a bit bothered that it's called bottom-up when it implies more including the retry logic. Its use of bottom-up allocation is really an implementation logic to achieve the goal of allocating memory above kernel image after all, but yeah minor point either way. Thanks. -- tejun -- 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 GIT PULL] softirq: Consolidation and stack overrun fix
On Mon, Sep 23, 2013 at 02:40:34PM +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2013-09-22 at 07:45 +1000, Benjamin Herrenschmidt wrote:
> > What I *can* do that would help I suppose would be to switch to the irq
> > stack before irq_enter/exit which would at least mean that softirq would
> > run from the top of the irq stack which is better than the current
> > situation.
> >
> > I'm fact I'll whip up a quick fix see if that might be enough of a band
> > aid for RHEL7.
>
> OK I've done that, it seems to work so far. Heads up guys: i386 and sparc
> at least seem to need the same treatment. I haven't looked at others except
> ARM which doesn't seem to have irq stacks to begin with.
>
> We can also instead apply Fred's series to put back in the switch to the
> softirq stack since this is actually a regression , but then, arguably,
> making sure irq_exit() is called off the irq stack is better and means
> we do one instead of two stack switches.
>
> Fred: Maybe revert partially under an arch #define/Kconfig so we can get
> the best of both worlds ?
Aye, I did not realize that's indeed a regression, caused by
("irq: Sanitize invoke_softirq") facd8b80c67a3cf64a467c4a2ac5fb31f2e6745b
which converted do_softirq() to __do_softirq() on irq_exit(). It indeed
looked like the macro-conditional call was only there for irq disability
reasons. But then these crashes...
So the safest way to fix this is to unconditionally call do_softirq() from
irq_exit().
A performance penalty may come along but safety primes.
We should probably do that and work on longer term solutions (Kconfig based
arch switch, etc...)
for the next merge window?
I'll respin the series plus the regression fix, unless somebody has a better
solution.
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 v3 2/5] memblock: Improve memblock to support allocation from lower address.
Hello tejun,
On 09/24/2013 04:21 AM, Tejun Heo wrote:
> Hello,
>
> On Tue, Sep 24, 2013 at 02:07:13AM +0800, Zhang Yanfei wrote:
>> Yes, I am following your advice in principle but kind of confused by
>> something you said above. Where should the set_memblock_alloc_above_kernel
>> be used? IMO, the function is like:
>>
>> find_in_range_node()
>> {
>> if (ok) {
>>/* bottom-up */
>>ret = __memblock_find_in_range(max(start, _end_of_kernel),
>> end...);
>>if (!ret)
>> return ret;
>> }
>>
>> /* top-down retry */
>> return __memblock_find_in_range_rev(start, end...)
>> }
>>
>> For bottom-up allocation, we always start from max(start, _end_of_kernel).
>
> Oh, I was talking about naming of the memblock_set_bottom_up()
> function. We aren't really doing pure bottom up allocations, so I
> think it probably would be clearer if the name clearly denotes that
> we're doing above-kernel allocation.
I see. But I think memblock_set_alloc_above_kernel may lose the info
that we are doing bottom-up allocation. So my idea is we introduce
pure bottom-up allocation mode in previous patches and we use the
bottom-up allocation here and limit the start address above the kernel
, with explicit comments to indicate this.
How do you think?
Thanks.
>
> Thanks.
>
--
Thanks.
Zhang Yanfei
--
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] mmc: cb710: drop free_irq for devm_request_irq allocated irq
From: Wei Yongjun
irq allocated with devm_request_irq should not be freed using
free_irq, because doing so causes a dangling pointer, and a
subsequent double free.
Signed-off-by: Wei Yongjun
---
drivers/misc/cb710/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/cb710/core.c b/drivers/misc/cb710/core.c
index 2e50f81..fb397e7 100644
--- a/drivers/misc/cb710/core.c
+++ b/drivers/misc/cb710/core.c
@@ -176,7 +176,7 @@ static int cb710_suspend(struct pci_dev *pdev, pm_message_t
state)
{
struct cb710_chip *chip = pci_get_drvdata(pdev);
- free_irq(pdev->irq, chip);
+ devm_free_irq(>dev, pdev->irq, chip);
pci_save_state(pdev);
pci_disable_device(pdev);
if (state.event & PM_EVENT_SLEEP)
--
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: new binutils needed for arm in 3.12-rc1
On 09/23/2013 06:59:17 PM, Pavel Machek wrote: During 3.12-rc, Will Deacon introduced code into arch/arm that requires binutils 2.22. I'm sorry, it occurs to me I should have been more explicit: HH! KILL IT WITH FIRE!!! 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/
linux-next: manual merge of the ipsec-next tree with the net-next tree
Hi Steffen,
Today's linux-next merge of the ipsec-next tree got a conflict in
include/net/xfrm.h between commit d511337a1eda ("xfrm.h: Remove extern
from function prototypes") from the net-next tree and commit aba826958830
("{ipv4,xfrm}: Introduce xfrm_tunnel_notifier for xfrm tunnel mode
callback") from the ipsec-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc include/net/xfrm.h
index 7657461,c7afa6e..000
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@@ -1493,39 -1495,35 +1499,39 @@@ static inline int xfrm4_rcv_spi(struct
return xfrm4_rcv_encap(skb, nexthdr, spi, 0);
}
-extern int xfrm4_extract_output(struct xfrm_state *x, struct sk_buff *skb);
-extern int xfrm4_prepare_output(struct xfrm_state *x, struct sk_buff *skb);
-extern int xfrm4_output(struct sk_buff *skb);
-extern int xfrm4_output_finish(struct sk_buff *skb);
-extern int xfrm4_tunnel_register(struct xfrm_tunnel *handler, unsigned short
family);
-extern int xfrm4_tunnel_deregister(struct xfrm_tunnel *handler, unsigned
short family);
-extern int xfrm4_mode_tunnel_input_register(struct xfrm_tunnel_notifier
*handler);
-extern int xfrm4_mode_tunnel_input_deregister(struct xfrm_tunnel_notifier
*handler);
-extern int xfrm6_extract_header(struct sk_buff *skb);
-extern int xfrm6_extract_input(struct xfrm_state *x, struct sk_buff *skb);
-extern int xfrm6_rcv_spi(struct sk_buff *skb, int nexthdr, __be32 spi);
-extern int xfrm6_transport_finish(struct sk_buff *skb, int async);
-extern int xfrm6_rcv(struct sk_buff *skb);
-extern int xfrm6_input_addr(struct sk_buff *skb, xfrm_address_t *daddr,
- xfrm_address_t *saddr, u8 proto);
-extern int xfrm6_tunnel_register(struct xfrm6_tunnel *handler, unsigned short
family);
-extern int xfrm6_tunnel_deregister(struct xfrm6_tunnel *handler, unsigned
short family);
-extern __be32 xfrm6_tunnel_alloc_spi(struct net *net, xfrm_address_t *saddr);
-extern __be32 xfrm6_tunnel_spi_lookup(struct net *net, const xfrm_address_t
*saddr);
-extern int xfrm6_extract_output(struct xfrm_state *x, struct sk_buff *skb);
-extern int xfrm6_prepare_output(struct xfrm_state *x, struct sk_buff *skb);
-extern int xfrm6_output(struct sk_buff *skb);
-extern int xfrm6_output_finish(struct sk_buff *skb);
-extern int xfrm6_find_1stfragopt(struct xfrm_state *x, struct sk_buff *skb,
- u8 **prevhdr);
+int xfrm4_extract_output(struct xfrm_state *x, struct sk_buff *skb);
+int xfrm4_prepare_output(struct xfrm_state *x, struct sk_buff *skb);
+int xfrm4_output(struct sk_buff *skb);
+int xfrm4_output_finish(struct sk_buff *skb);
+int xfrm4_tunnel_register(struct xfrm_tunnel *handler, unsigned short family);
+int xfrm4_tunnel_deregister(struct xfrm_tunnel *handler, unsigned short
family);
- int xfrm4_mode_tunnel_input_register(struct xfrm_tunnel *handler);
- int xfrm4_mode_tunnel_input_deregister(struct xfrm_tunnel *handler);
++int xfrm4_mode_tunnel_input_register(struct xfrm_tunnel_notifier *handler);
++int xfrm4_mode_tunnel_input_deregister(struct xfrm_tunnel_notifier *handler);
+void xfrm4_local_error(struct sk_buff *skb, u32 mtu);
+int xfrm6_extract_header(struct sk_buff *skb);
+int xfrm6_extract_input(struct xfrm_state *x, struct sk_buff *skb);
+int xfrm6_rcv_spi(struct sk_buff *skb, int nexthdr, __be32 spi);
+int xfrm6_transport_finish(struct sk_buff *skb, int async);
+int xfrm6_rcv(struct sk_buff *skb);
+int xfrm6_input_addr(struct sk_buff *skb, xfrm_address_t *daddr,
+ xfrm_address_t *saddr, u8 proto);
+int xfrm6_tunnel_register(struct xfrm6_tunnel *handler, unsigned short
family);
+int xfrm6_tunnel_deregister(struct xfrm6_tunnel *handler,
+ unsigned short family);
+__be32 xfrm6_tunnel_alloc_spi(struct net *net, xfrm_address_t *saddr);
+__be32 xfrm6_tunnel_spi_lookup(struct net *net, const xfrm_address_t *saddr);
+int xfrm6_extract_output(struct xfrm_state *x, struct sk_buff *skb);
+int xfrm6_prepare_output(struct xfrm_state *x, struct sk_buff *skb);
+int xfrm6_output(struct sk_buff *skb);
+int xfrm6_output_finish(struct sk_buff *skb);
+int xfrm6_find_1stfragopt(struct xfrm_state *x, struct sk_buff *skb,
+u8 **prevhdr);
+void xfrm6_local_error(struct sk_buff *skb, u32 mtu);
#ifdef CONFIG_XFRM
-extern int xfrm4_udp_encap_rcv(struct sock *sk, struct sk_buff *skb);
-extern int xfrm_user_policy(struct sock *sk, int optname, u8 __user *optval,
int optlen);
+int xfrm4_udp_encap_rcv(struct sock *sk, struct sk_buff *skb);
+int xfrm_user_policy(struct sock *sk, int optname,
+ u8 __user *optval, int optlen);
#else
static inline int xfrm_user_policy(struct sock *sk, int optname, u8 __user
*optval, int optlen)
{
pgpkzOd9Ks5_O.pgp
Description: PGP signature
Re: new binutils needed for arm in 3.12-rc1
On 09/23/2013 06:59:17 PM, Pavel Machek wrote: During 3.12-rc, Will Deacon introduced code into arch/arm that requires binutils 2.22. Um, my toolchain is using the last gplv2 snapshot of binutils out of git, which is just past 2.17 and can build armv7 (but not armv8). Binutils 2.12->2.22 is quite the jump. (11 years.) I'd except some thought to have gone into that? Possibly a mention of it? diff --git a/Documentation/Changes b/Documentation/Changes index b175808..0f8deaf 100644 --- a/Documentation/Changes +++ b/Documentation/Changes @@ -23,7 +23,7 @@ you probably needn't concern yourself with isdn4k-utils. o Gnu C 3.2 # gcc --version o Gnu make 3.80# make --version -o binutils 2.12# ld -v +o binutils 2.22# ld -v When the sh4 platform did this, I just reverted the patch. (It still reverts cleanly ~4 years later, and builds with my old tool versions...) 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: [GIT PULL] Keyrings patches
On Tue, 17 Sep 2013, David Howells wrote: > > There's a slight change upstream that means that my patchset needs > regenerating (the initconst changes). Can you bring your -next branch up to > date with linus/master so that I can rebase on top of it? I've merged my tree to -rc2 so you can rebase or merge (probably better). -- James Morris -- 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 0/5] memcg, cgroup: kill css id
Hi Tejun,
On Mon, 23 Sep 2013 21:52:11 -0400 Tejun Heo wrote:
>
> (cc'ing Stephen, hi!)
Hi :-)
> On Mon, Sep 23, 2013 at 09:30:58PM -0400, Tejun Heo wrote:
> >
> > On Mon, Sep 23, 2013 at 05:52:47PM -0700, Andrew Morton wrote:
> > > > I would love to see this patchset go through cgroup tree. The changes to
> > > > memcg is quite small,
> > >
> > > It seems logical to put this in the cgroup tree as that's where most of
> > > the impact occurs.
> >
> > Cool, applying the changes to cgroup/for-3.13.
>
> Stephen, Andrew, cgroup/for-3.13 will cause a minor conflict in
> mm/memcontrol.c with the patch which reverts Michal's reclaim changes.
>
> static void __mem_cgroup_free(struct mem_cgroup *memcg)
> {
> int node;
> size_t size = memcg_size();
>
> <<< HEAD
> ===
> mem_cgroup_remove_from_trees(memcg);
> free_css_id(_cgroup_subsys, >css);
>
> >>> 1fa8f71dfa6e28c89afad7ac71dcb19b8c8da8b7
> for_each_node(node)
> free_mem_cgroup_per_zone_info(memcg, node);
>
> It's a context conflict and just removing free_css_id() call resolves
> it.
>
> static void __mem_cgroup_free(struct mem_cgroup *memcg)
> {
> int node;
> size_t size = memcg_size();
>
> mem_cgroup_remove_from_trees(memcg);
>
> for_each_node(node)
> free_mem_cgroup_per_zone_info(memcg, node);
Thanks for the heads up, I guess I'll see that tomorrow.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpN8m0aQVULQ.pgp
Description: PGP signature
Re: [RFC GIT PULL] softirq: Consolidation and stack overrun fix
On Mon, 2013-09-23 at 18:19 -0700, Linus Torvalds wrote:
> On Mon, Sep 23, 2013 at 5:10 PM, Benjamin Herrenschmidt
> wrote:
> >
> > BTW, that boils down to a choice between using r13 as either a TLS for
> > current or current_thread_info, or as a per-cpu pointer, which one is
> > the most performance critical ?
>
> I think you can tune most of the architecture setup to best suit your needs.
>
> For example, on x86, we don't have much choice: the per-cpu accessors
> are going to be faster than the alternatives, and there are patches
> afoot to tune the preempt and rcu-readside counters to use the percpu
> area (and then save/restore things at task switch time). But having
> the counters natively in the thread_info struct is fine too and is
> what we do now.
Right, as long as the generic code doesn't move toward putting
everything in per-cpu without leaving us the option :-)
> Generally, we've put the performance-critical stuff into
> "current_thread_info" as opposed to "current", so it's likely that if
> the choice is between those two, then you might want to pick %r13
> pointing to the thread-info rather than the "struct task_struct" (ie
> things like low-level thread flags). But which is better probably
> depends on load, and again, some of it you can tweak by just making
> per-architecture structure choices and making the macros point at one
> or the other.
Well, if current_thread_info is basically inside the thread struct, it
will be the same, just a different offset from r13... task struct,
thread struct, thread info, it all becomes just one big structure
pointed to by r13.
> There's a few things that really depend on per-cpu areas, but I don't
> think it's a huge performance issue if you have to indirect off memory
> to get that. Most of the performance issues with per-cpu stuff is
> about avoiding cachelines ping-ponging back and forth, not so much
> about fast direct access. Of course, if some load really uses a *lot*
> of percpu accesses, you get both.
>
> The advantage of having %r13 point to thread data (which is "stable"
> as far as the compiler is concerned) as opposed to having it be a
> per-cpu pointer (which can change randomly due to task switching) is
> that from a correctness standpoint I really do think that either
> thread-info or current is *much* easier to handle than using it for
> the per-cpu base pointer.
Right. I had a chat with Alan Modra (gcc) and he reckons the "right" way
to make the per-cpu (or PACA) stuff work reasonably reliably is to do
something along the lines of:
register unsigned long per_cpu_offset asm("r13");
And have a barrier in preempt_enable/disable (and irq enable/disable,
though arguably we could just make barrier() do it) which marks r13 as
an *output* (not a clobber !).
>From there, gcc knows that after any such barrier, r13 can have changed
and we intend to use the new value (if it's marked as a clobber, it
assumes it was *clobbered* and thus need to be restored to it's
*previous* value).
So if that holds, we have a solid way to do per-cpu. On one side, I tend
to think that r13 being task/thread/thread_info is probably a better
overall choice, I'm worried that going in a different direction than x86
means generic code will get "tuned" to use per-cpu for performance
critical stuff rather than task/thread/thread_info in inflexible ways.
Cheers,
Ben.
> Linus
> --
> 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 v6 0/5] memcg, cgroup: kill css id
(cc'ing Stephen, hi!)
On Mon, Sep 23, 2013 at 09:30:58PM -0400, Tejun Heo wrote:
> Hello, Andrew.
>
> On Mon, Sep 23, 2013 at 05:52:47PM -0700, Andrew Morton wrote:
> > > I would love to see this patchset go through cgroup tree. The changes to
> > > memcg is quite small,
> >
> > It seems logical to put this in the cgroup tree as that's where most of
> > the impact occurs.
>
> Cool, applying the changes to cgroup/for-3.13.
Stephen, Andrew, cgroup/for-3.13 will cause a minor conflict in
mm/memcontrol.c with the patch which reverts Michal's reclaim changes.
static void __mem_cgroup_free(struct mem_cgroup *memcg)
{
int node;
size_t size = memcg_size();
<<< HEAD
===
mem_cgroup_remove_from_trees(memcg);
free_css_id(_cgroup_subsys, >css);
>>> 1fa8f71dfa6e28c89afad7ac71dcb19b8c8da8b7
for_each_node(node)
free_mem_cgroup_per_zone_info(memcg, node);
It's a context conflict and just removing free_css_id() call resolves
it.
static void __mem_cgroup_free(struct mem_cgroup *memcg)
{
int node;
size_t size = memcg_size();
mem_cgroup_remove_from_trees(memcg);
for_each_node(node)
free_mem_cgroup_per_zone_info(memcg, node);
Thanks.
--
tejun
--
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 0/5] memcg, cgroup: kill css id
On Mon, Sep 23, 2013 at 04:55:20PM +0800, Li Zefan wrote: > Hi Andrew, > > The whole patchset has been acked and reviewed by Michal and Tejun. > Could you merge it into mm tree? > > === > > This patchset converts memcg to use cgroup->id, and then we remove cgroup > css_id. Applied to cgroup/for-3.13. Thanks. -- tejun -- 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] LSM: ModPin LSM for module loading restrictions
[+rusty] On Mon, Sep 23, 2013 at 6:28 PM, James Morris wrote: > On Tue, 24 Sep 2013, James Morris wrote: > >> On Fri, 20 Sep 2013, Kees Cook wrote: >> >> > This LSM enforces that modules must all come from the same filesystem, >> > with the expectation that such a filesystem is backed by a read-only >> > device such as dm-verity or CDROM. This allows systems that have a >> > verified or unchanging filesystem to enforce module loading restrictions >> > without needing to sign the modules individually. >> > >> > Signed-off-by: Kees Cook >> >> Are you using this for ChromeOS? Yes. Chrome OS uses a read-only root filesystem that is backed by dm-verity. This lets us pin all module loading to that filesystem without needing per-module signatures. > Also, you should CC Rusty on this. Done! :) -Kees > > >> >> >> > --- >> > security/Kconfig |6 ++ >> > security/Makefile|2 + >> > security/modpin/Kconfig |9 +++ >> > security/modpin/Makefile |1 + >> > security/modpin/modpin.c | 197 >> > ++ >> > 5 files changed, 215 insertions(+) >> > create mode 100644 security/modpin/Kconfig >> > create mode 100644 security/modpin/Makefile >> > create mode 100644 security/modpin/modpin.c >> > >> > diff --git a/security/Kconfig b/security/Kconfig >> > index e9c6ac7..80172fd 100644 >> > --- a/security/Kconfig >> > +++ b/security/Kconfig >> > @@ -121,6 +121,7 @@ source security/selinux/Kconfig >> > source security/smack/Kconfig >> > source security/tomoyo/Kconfig >> > source security/apparmor/Kconfig >> > +source security/modpin/Kconfig >> > source security/yama/Kconfig >> > >> > source security/integrity/Kconfig >> > @@ -131,6 +132,7 @@ choice >> > default DEFAULT_SECURITY_SMACK if SECURITY_SMACK >> > default DEFAULT_SECURITY_TOMOYO if SECURITY_TOMOYO >> > default DEFAULT_SECURITY_APPARMOR if SECURITY_APPARMOR >> > + default DEFAULT_SECURITY_MODPIN if SECURITY_MODPIN >> > default DEFAULT_SECURITY_YAMA if SECURITY_YAMA >> > default DEFAULT_SECURITY_DAC >> > >> > @@ -150,6 +152,9 @@ choice >> > config DEFAULT_SECURITY_APPARMOR >> > bool "AppArmor" if SECURITY_APPARMOR=y >> > >> > + config DEFAULT_SECURITY_MODPIN >> > + bool "ModPin" if SECURITY_MODPIN=y >> > + >> > config DEFAULT_SECURITY_YAMA >> > bool "Yama" if SECURITY_YAMA=y >> > >> > @@ -164,6 +169,7 @@ config DEFAULT_SECURITY >> > default "smack" if DEFAULT_SECURITY_SMACK >> > default "tomoyo" if DEFAULT_SECURITY_TOMOYO >> > default "apparmor" if DEFAULT_SECURITY_APPARMOR >> > + default "modpin" if DEFAULT_SECURITY_MODPIN >> > default "yama" if DEFAULT_SECURITY_YAMA >> > default "" if DEFAULT_SECURITY_DAC >> > >> > diff --git a/security/Makefile b/security/Makefile >> > index c26c81e..73d0a05 100644 >> > --- a/security/Makefile >> > +++ b/security/Makefile >> > @@ -7,6 +7,7 @@ subdir-$(CONFIG_SECURITY_SELINUX) += selinux >> > subdir-$(CONFIG_SECURITY_SMACK)+= smack >> > subdir-$(CONFIG_SECURITY_TOMOYO)+= tomoyo >> > subdir-$(CONFIG_SECURITY_APPARMOR) += apparmor >> > +subdir-$(CONFIG_SECURITY_MODPIN) += modpin >> > subdir-$(CONFIG_SECURITY_YAMA) += yama >> > >> > # always enable default capabilities >> > @@ -22,6 +23,7 @@ obj-$(CONFIG_SECURITY_SMACK) += >> > smack/built-in.o >> > obj-$(CONFIG_AUDIT)+= lsm_audit.o >> > obj-$(CONFIG_SECURITY_TOMOYO) += tomoyo/built-in.o >> > obj-$(CONFIG_SECURITY_APPARMOR)+= apparmor/built-in.o >> > +obj-$(CONFIG_SECURITY_MODPIN) += modpin/built-in.o >> > obj-$(CONFIG_SECURITY_YAMA)+= yama/built-in.o >> > obj-$(CONFIG_CGROUP_DEVICE)+= device_cgroup.o >> > >> > diff --git a/security/modpin/Kconfig b/security/modpin/Kconfig >> > new file mode 100644 >> > index 000..5be9dd5 >> > --- /dev/null >> > +++ b/security/modpin/Kconfig >> > @@ -0,0 +1,9 @@ >> > +config SECURITY_MODPIN >> > + bool "Module filesystem origin pinning" >> > + depends on SECURITY >> > + help >> > + Module loading will be pinned to the first filesystem used for >> > + loading. Any modules that come from other filesystems will be >> > + rejected. This is best used on systems without an initrd that >> > + have a root filesystem backed by a read-only device such as >> > + dm-verity or a CDROM. >> > diff --git a/security/modpin/Makefile b/security/modpin/Makefile >> > new file mode 100644 >> > index 000..9080b29 >> > --- /dev/null >> > +++ b/security/modpin/Makefile >> > @@ -0,0 +1 @@ >> > +obj-$(CONFIG_SECURITY_MODPIN) += modpin.o >> > diff --git a/security/modpin/modpin.c b/security/modpin/modpin.c >> > new file mode 100644 >> > index 000..107b4d8 >> > --- /dev/null >> > +++ b/security/modpin/modpin.c >> > @@ -0,0 +1,197 @@ >> > +/* >> > + * Module Pinning Security Module >> > + * >> > + * Copyright 2011-2013
Re: [PATCH 1/2] Fix NULL pointer dereference while loading initramfs
On 09/23/2013 02:41:10 PM, Andrew Morton wrote:
On Sun, 15 Sep 2013 14:33:53 +0530 (IST) P J P
wrote:
> Make menuconfig allows one to choose compression format of an
> initial ramdisk image. But this choice does not result in duly
> compressed initial ramdisk image. Because - $ make install - does
> not pass on the selected compression choice to the dracut(8) tool,
> which creates the initramfs file. dracut(8) generates the image
> with the default compression, ie. gzip(1).
I've been building kernels, including with initramfs, and I don't have
dracut(8) installed? In today's git:
$ find . -type f | xargs grep -i dracut
./tools/testing/ktest/sample.conf:#POST_INSTALL = ssh user@target
/sbin/dracut -f /boot/initramfs-test.img $KERNEL_VERSION
./tools/testing/ktest/examples/kvm.conf:# that uses dracut for its
initfs. The POST_INSTALL will be executed
./tools/testing/ktest/examples/kvm.conf:POST_INSTALL = ${SSH}
/sbin/dracut -f /boot/initramfs-test.img $KERNEL_VERSION
./Documentation/ABI/testing/evm:
Documentation/keys-trusted-encrypted.txt. (A sample dracut
- Is anyone working on fixing up Kconfig/dracut(8) so the correct
decompression method is used?
I've been messing with this area and maight be interested if I had any
idea what this guy was talking about?
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 0/5] memcg, cgroup: kill css id
Hello, Andrew. On Mon, Sep 23, 2013 at 05:52:47PM -0700, Andrew Morton wrote: > > I would love to see this patchset go through cgroup tree. The changes to > > memcg is quite small, > > It seems logical to put this in the cgroup tree as that's where most of > the impact occurs. Cool, applying the changes to cgroup/for-3.13. > > and as -mm tree is based on -next it won't cause > > future conflicts. > > That's no longer the case - I'm staging -mm patches ahead of linux-next > now. Except in cases where that's impractical, such as the 3.12 memcg > changes which were pretty heavily impacted by cgroups tree changes. Please note that cgroup is likely to continue to go through a lot of changes for the foreseeable future and memcg is likely to be affected heavily. Thanks. -- tejun -- 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/
[f2fs-dev] [PATCH RESEND] f2fs: remove unneeded write checkpoint in recover_fsync_data
Previously, recover_fsync_data still to write checkpoint when there is
nothing to recover with normal umount image.
It may reduce mount performance and flash memory lifetime, so let's remove
it.
Signed-off-by: Tan Shu
Signed-off-by: Yu Chao
---
fs/f2fs/recovery.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index 51ef5ee..d43e4cd 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -419,6 +419,7 @@ int recover_fsync_data(struct f2fs_sb_info *sbi)
{
struct list_head inode_list;
int err;
+ int need_writecp = 0;
fsync_entry_slab = f2fs_kmem_cache_create("f2fs_fsync_inode_entry",
sizeof(struct fsync_inode_entry), NULL);
@@ -436,6 +437,8 @@ int recover_fsync_data(struct f2fs_sb_info *sbi)
if (list_empty(_list))
goto out;
+ need_writecp = 1;
+
/* step #2: recover data */
err = recover_data(sbi, _list, CURSEG_WARM_NODE);
BUG_ON(!list_empty(_list));
@@ -443,7 +446,7 @@ out:
destroy_fsync_dnodes(_list);
kmem_cache_destroy(fsync_entry_slab);
sbi->por_doing = 0;
- if (!err)
+ if (!err && need_writecp)
write_checkpoint(sbi, false);
return err;
}
---
--
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] LSM: ModPin LSM for module loading restrictions
On Tue, 24 Sep 2013, James Morris wrote: > On Fri, 20 Sep 2013, Kees Cook wrote: > > > This LSM enforces that modules must all come from the same filesystem, > > with the expectation that such a filesystem is backed by a read-only > > device such as dm-verity or CDROM. This allows systems that have a > > verified or unchanging filesystem to enforce module loading restrictions > > without needing to sign the modules individually. > > > > Signed-off-by: Kees Cook > > Are you using this for ChromeOS? Also, you should CC Rusty on this. > > > > --- > > security/Kconfig |6 ++ > > security/Makefile|2 + > > security/modpin/Kconfig |9 +++ > > security/modpin/Makefile |1 + > > security/modpin/modpin.c | 197 > > ++ > > 5 files changed, 215 insertions(+) > > create mode 100644 security/modpin/Kconfig > > create mode 100644 security/modpin/Makefile > > create mode 100644 security/modpin/modpin.c > > > > diff --git a/security/Kconfig b/security/Kconfig > > index e9c6ac7..80172fd 100644 > > --- a/security/Kconfig > > +++ b/security/Kconfig > > @@ -121,6 +121,7 @@ source security/selinux/Kconfig > > source security/smack/Kconfig > > source security/tomoyo/Kconfig > > source security/apparmor/Kconfig > > +source security/modpin/Kconfig > > source security/yama/Kconfig > > > > source security/integrity/Kconfig > > @@ -131,6 +132,7 @@ choice > > default DEFAULT_SECURITY_SMACK if SECURITY_SMACK > > default DEFAULT_SECURITY_TOMOYO if SECURITY_TOMOYO > > default DEFAULT_SECURITY_APPARMOR if SECURITY_APPARMOR > > + default DEFAULT_SECURITY_MODPIN if SECURITY_MODPIN > > default DEFAULT_SECURITY_YAMA if SECURITY_YAMA > > default DEFAULT_SECURITY_DAC > > > > @@ -150,6 +152,9 @@ choice > > config DEFAULT_SECURITY_APPARMOR > > bool "AppArmor" if SECURITY_APPARMOR=y > > > > + config DEFAULT_SECURITY_MODPIN > > + bool "ModPin" if SECURITY_MODPIN=y > > + > > config DEFAULT_SECURITY_YAMA > > bool "Yama" if SECURITY_YAMA=y > > > > @@ -164,6 +169,7 @@ config DEFAULT_SECURITY > > default "smack" if DEFAULT_SECURITY_SMACK > > default "tomoyo" if DEFAULT_SECURITY_TOMOYO > > default "apparmor" if DEFAULT_SECURITY_APPARMOR > > + default "modpin" if DEFAULT_SECURITY_MODPIN > > default "yama" if DEFAULT_SECURITY_YAMA > > default "" if DEFAULT_SECURITY_DAC > > > > diff --git a/security/Makefile b/security/Makefile > > index c26c81e..73d0a05 100644 > > --- a/security/Makefile > > +++ b/security/Makefile > > @@ -7,6 +7,7 @@ subdir-$(CONFIG_SECURITY_SELINUX) += selinux > > subdir-$(CONFIG_SECURITY_SMACK)+= smack > > subdir-$(CONFIG_SECURITY_TOMOYO)+= tomoyo > > subdir-$(CONFIG_SECURITY_APPARMOR) += apparmor > > +subdir-$(CONFIG_SECURITY_MODPIN) += modpin > > subdir-$(CONFIG_SECURITY_YAMA) += yama > > > > # always enable default capabilities > > @@ -22,6 +23,7 @@ obj-$(CONFIG_SECURITY_SMACK) += > > smack/built-in.o > > obj-$(CONFIG_AUDIT)+= lsm_audit.o > > obj-$(CONFIG_SECURITY_TOMOYO) += tomoyo/built-in.o > > obj-$(CONFIG_SECURITY_APPARMOR)+= apparmor/built-in.o > > +obj-$(CONFIG_SECURITY_MODPIN) += modpin/built-in.o > > obj-$(CONFIG_SECURITY_YAMA)+= yama/built-in.o > > obj-$(CONFIG_CGROUP_DEVICE)+= device_cgroup.o > > > > diff --git a/security/modpin/Kconfig b/security/modpin/Kconfig > > new file mode 100644 > > index 000..5be9dd5 > > --- /dev/null > > +++ b/security/modpin/Kconfig > > @@ -0,0 +1,9 @@ > > +config SECURITY_MODPIN > > + bool "Module filesystem origin pinning" > > + depends on SECURITY > > + help > > + Module loading will be pinned to the first filesystem used for > > + loading. Any modules that come from other filesystems will be > > + rejected. This is best used on systems without an initrd that > > + have a root filesystem backed by a read-only device such as > > + dm-verity or a CDROM. > > diff --git a/security/modpin/Makefile b/security/modpin/Makefile > > new file mode 100644 > > index 000..9080b29 > > --- /dev/null > > +++ b/security/modpin/Makefile > > @@ -0,0 +1 @@ > > +obj-$(CONFIG_SECURITY_MODPIN) += modpin.o > > diff --git a/security/modpin/modpin.c b/security/modpin/modpin.c > > new file mode 100644 > > index 000..107b4d8 > > --- /dev/null > > +++ b/security/modpin/modpin.c > > @@ -0,0 +1,197 @@ > > +/* > > + * Module Pinning Security Module > > + * > > + * Copyright 2011-2013 Google Inc. > > + * > > + * Authors: > > + * Kees Cook > > + * > > + * This software is licensed under the terms of the GNU General Public > > + * License version 2, as published by the Free Software Foundation, and > > + * may be copied, distributed, and modified under those terms. > > + * > > + * This program is distributed in the hope that it
[PATCH V2 1/6] clk: exynos-audss: convert to platform device
The Exynos AudioSS clock controller will later be modified to allow
input clocks to be specified via device-tree in order to support
multiple Exynos SoCs. This will introduce a dependency on the core
SoC clock controller being initialized first so that the AudioSS driver
can look up its input clocks, but the order in which clock providers
are probed in of_clk_init() is not guaranteed. Since deferred probing
is not supported in of_clk_init() and the AudioSS block is not the core
controller, we can initialize it later as a platform device.
Signed-off-by: Andrew Bresticker
---
Changes since v1:
- add clk_unregister() calls to remove callback
- fixed minor nits from Tomasz
---
drivers/clk/samsung/clk-exynos-audss.c | 78 --
1 file changed, 65 insertions(+), 13 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos-audss.c
b/drivers/clk/samsung/clk-exynos-audss.c
index 39b40aa..c512efd 100644
--- a/drivers/clk/samsung/clk-exynos-audss.c
+++ b/drivers/clk/samsung/clk-exynos-audss.c
@@ -14,6 +14,8 @@
#include
#include
#include
+#include
+#include
#include
@@ -62,24 +64,29 @@ static struct syscore_ops exynos_audss_clk_syscore_ops = {
#endif /* CONFIG_PM_SLEEP */
/* register exynos_audss clocks */
-static void __init exynos_audss_clk_init(struct device_node *np)
+static int exynos_audss_clk_probe(struct platform_device *pdev)
{
- reg_base = of_iomap(np, 0);
- if (!reg_base) {
- pr_err("%s: failed to map audss registers\n", __func__);
- return;
+ struct resource *res;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ reg_base = devm_ioremap_resource(>dev, res);
+ if (IS_ERR(reg_base)) {
+ dev_err(>dev, "failed to map audss registers\n");
+ return PTR_ERR(reg_base);
}
- clk_table = kzalloc(sizeof(struct clk *) * EXYNOS_AUDSS_MAX_CLKS,
+ clk_table = devm_kzalloc(>dev,
+ sizeof(struct clk *) * EXYNOS_AUDSS_MAX_CLKS,
GFP_KERNEL);
if (!clk_table) {
- pr_err("%s: could not allocate clk lookup table\n", __func__);
- return;
+ dev_err(>dev, "could not allocate clk lookup table\n");
+ return -ENOMEM;
}
clk_data.clks = clk_table;
clk_data.clk_num = EXYNOS_AUDSS_MAX_CLKS;
- of_clk_add_provider(np, of_clk_src_onecell_get, _data);
+ of_clk_add_provider(pdev->dev.of_node, of_clk_src_onecell_get,
+ _data);
clk_table[EXYNOS_MOUT_AUDSS] = clk_register_mux(NULL, "mout_audss",
mout_audss_p, ARRAY_SIZE(mout_audss_p),
@@ -128,8 +135,53 @@ static void __init exynos_audss_clk_init(struct
device_node *np)
#endif
pr_info("Exynos: Audss: clock setup completed\n");
+
+ return 0;
+}
+
+static int exynos_audss_clk_remove(struct platform_device *pdev)
+{
+ int i;
+
+ for (i = 0; i < EXYNOS_AUDSS_MAX_CLKS; i++) {
+ if (clk_table[i])
+ clk_unregister(clk_table[i]);
+ }
+
+ of_clk_del_provider(pdev->dev.of_node);
+
+ return 0;
}
-CLK_OF_DECLARE(exynos4210_audss_clk, "samsung,exynos4210-audss-clock",
- exynos_audss_clk_init);
-CLK_OF_DECLARE(exynos5250_audss_clk, "samsung,exynos5250-audss-clock",
- exynos_audss_clk_init);
+
+static const struct of_device_id exynos_audss_clk_of_match[] = {
+ { .compatible = "samsung,exynos4210-audss-clock", },
+ { .compatible = "samsung,exynos5250-audss-clock", },
+ {},
+};
+
+static struct platform_driver exynos_audss_clk_driver = {
+ .driver = {
+ .name = "exynos-audss-clk",
+ .owner = THIS_MODULE,
+ .of_match_table = exynos_audss_clk_of_match,
+ },
+ .probe = exynos_audss_clk_probe,
+ .remove = exynos_audss_clk_remove,
+};
+
+static int __init exynos_audss_clk_init(void)
+{
+ return platform_driver_register(_audss_clk_driver);
+}
+core_initcall(exynos_audss_clk_init);
+
+static void __init exynos_audss_clk_exit(void)
+{
+ platform_driver_unregister(_audss_clk_driver);
+}
+module_exit(exynos_audss_clk_exit);
+
+MODULE_AUTHOR("Padmavathi Venna ");
+MODULE_DESCRIPTION("Exynos Audio Subsystem Clock Controller");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:exynos-audss-clk");
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] LSM: ModPin LSM for module loading restrictions
On Fri, 20 Sep 2013, Kees Cook wrote: > This LSM enforces that modules must all come from the same filesystem, > with the expectation that such a filesystem is backed by a read-only > device such as dm-verity or CDROM. This allows systems that have a > verified or unchanging filesystem to enforce module loading restrictions > without needing to sign the modules individually. > > Signed-off-by: Kees Cook Are you using this for ChromeOS? > --- > security/Kconfig |6 ++ > security/Makefile|2 + > security/modpin/Kconfig |9 +++ > security/modpin/Makefile |1 + > security/modpin/modpin.c | 197 > ++ > 5 files changed, 215 insertions(+) > create mode 100644 security/modpin/Kconfig > create mode 100644 security/modpin/Makefile > create mode 100644 security/modpin/modpin.c > > diff --git a/security/Kconfig b/security/Kconfig > index e9c6ac7..80172fd 100644 > --- a/security/Kconfig > +++ b/security/Kconfig > @@ -121,6 +121,7 @@ source security/selinux/Kconfig > source security/smack/Kconfig > source security/tomoyo/Kconfig > source security/apparmor/Kconfig > +source security/modpin/Kconfig > source security/yama/Kconfig > > source security/integrity/Kconfig > @@ -131,6 +132,7 @@ choice > default DEFAULT_SECURITY_SMACK if SECURITY_SMACK > default DEFAULT_SECURITY_TOMOYO if SECURITY_TOMOYO > default DEFAULT_SECURITY_APPARMOR if SECURITY_APPARMOR > + default DEFAULT_SECURITY_MODPIN if SECURITY_MODPIN > default DEFAULT_SECURITY_YAMA if SECURITY_YAMA > default DEFAULT_SECURITY_DAC > > @@ -150,6 +152,9 @@ choice > config DEFAULT_SECURITY_APPARMOR > bool "AppArmor" if SECURITY_APPARMOR=y > > + config DEFAULT_SECURITY_MODPIN > + bool "ModPin" if SECURITY_MODPIN=y > + > config DEFAULT_SECURITY_YAMA > bool "Yama" if SECURITY_YAMA=y > > @@ -164,6 +169,7 @@ config DEFAULT_SECURITY > default "smack" if DEFAULT_SECURITY_SMACK > default "tomoyo" if DEFAULT_SECURITY_TOMOYO > default "apparmor" if DEFAULT_SECURITY_APPARMOR > + default "modpin" if DEFAULT_SECURITY_MODPIN > default "yama" if DEFAULT_SECURITY_YAMA > default "" if DEFAULT_SECURITY_DAC > > diff --git a/security/Makefile b/security/Makefile > index c26c81e..73d0a05 100644 > --- a/security/Makefile > +++ b/security/Makefile > @@ -7,6 +7,7 @@ subdir-$(CONFIG_SECURITY_SELINUX) += selinux > subdir-$(CONFIG_SECURITY_SMACK) += smack > subdir-$(CONFIG_SECURITY_TOMOYO)+= tomoyo > subdir-$(CONFIG_SECURITY_APPARMOR) += apparmor > +subdir-$(CONFIG_SECURITY_MODPIN) += modpin > subdir-$(CONFIG_SECURITY_YAMA) += yama > > # always enable default capabilities > @@ -22,6 +23,7 @@ obj-$(CONFIG_SECURITY_SMACK)+= > smack/built-in.o > obj-$(CONFIG_AUDIT) += lsm_audit.o > obj-$(CONFIG_SECURITY_TOMOYO)+= tomoyo/built-in.o > obj-$(CONFIG_SECURITY_APPARMOR) += apparmor/built-in.o > +obj-$(CONFIG_SECURITY_MODPIN)+= modpin/built-in.o > obj-$(CONFIG_SECURITY_YAMA) += yama/built-in.o > obj-$(CONFIG_CGROUP_DEVICE) += device_cgroup.o > > diff --git a/security/modpin/Kconfig b/security/modpin/Kconfig > new file mode 100644 > index 000..5be9dd5 > --- /dev/null > +++ b/security/modpin/Kconfig > @@ -0,0 +1,9 @@ > +config SECURITY_MODPIN > + bool "Module filesystem origin pinning" > + depends on SECURITY > + help > + Module loading will be pinned to the first filesystem used for > + loading. Any modules that come from other filesystems will be > + rejected. This is best used on systems without an initrd that > + have a root filesystem backed by a read-only device such as > + dm-verity or a CDROM. > diff --git a/security/modpin/Makefile b/security/modpin/Makefile > new file mode 100644 > index 000..9080b29 > --- /dev/null > +++ b/security/modpin/Makefile > @@ -0,0 +1 @@ > +obj-$(CONFIG_SECURITY_MODPIN) += modpin.o > diff --git a/security/modpin/modpin.c b/security/modpin/modpin.c > new file mode 100644 > index 000..107b4d8 > --- /dev/null > +++ b/security/modpin/modpin.c > @@ -0,0 +1,197 @@ > +/* > + * Module Pinning Security Module > + * > + * Copyright 2011-2013 Google Inc. > + * > + * Authors: > + * Kees Cook > + * > + * This software is licensed under the terms of the GNU General Public > + * License version 2, as published by the Free Software Foundation, and > + * may be copied, distributed, and modified under those terms. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#define pr_fmt(fmt) "ModPin LSM: " fmt > + > +#include >
Re: [PATCH 0/4] ipc: shm and msg fixes
On Mon, Sep 23, 2013 at 5:04 PM, Davidlohr Bueso wrote: > > Ok, so here's the code - again I've tested it with LTP on the resources > I have. This looks good to me. Manfred, mind giving this a look-over and see if this resolves your race concerns too? Linus -- 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: Oddness in security/Makefile
On Tue, 10 Sep 2013, Eric Paris wrote: > >From 4675ca3470e3c2e325c5be6d9a11f47ac0917537 Mon Sep 17 00:00:00 2001 > From: Eric Paris > Date: Tue, 10 Sep 2013 09:51:50 -0400 > Subject: [PATCH] security: remove erroneous comment about capabilities.o link > ordering > > Back when we had half ass LSM stacking we had to link capabilities.o > after bigger LSMs so that on initialization the bigger LSM would > register first and the capabilities module would be the one stacked as > the 'seconday'. Somewhere around 6f0f0fd496333777d53 (back in 2008) we > finally removed the last of the kinda module stacking code but this > comment in the makefile still lives today. > Applied to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next -- James Morris -- 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 GIT PULL] softirq: Consolidation and stack overrun fix
On Mon, Sep 23, 2013 at 5:10 PM, Benjamin Herrenschmidt wrote: > > BTW, that boils down to a choice between using r13 as either a TLS for > current or current_thread_info, or as a per-cpu pointer, which one is > the most performance critical ? I think you can tune most of the architecture setup to best suit your needs. For example, on x86, we don't have much choice: the per-cpu accessors are going to be faster than the alternatives, and there are patches afoot to tune the preempt and rcu-readside counters to use the percpu area (and then save/restore things at task switch time). But having the counters natively in the thread_info struct is fine too and is what we do now. Generally, we've put the performance-critical stuff into "current_thread_info" as opposed to "current", so it's likely that if the choice is between those two, then you might want to pick %r13 pointing to the thread-info rather than the "struct task_struct" (ie things like low-level thread flags). But which is better probably depends on load, and again, some of it you can tweak by just making per-architecture structure choices and making the macros point at one or the other. There's a few things that really depend on per-cpu areas, but I don't think it's a huge performance issue if you have to indirect off memory to get that. Most of the performance issues with per-cpu stuff is about avoiding cachelines ping-ponging back and forth, not so much about fast direct access. Of course, if some load really uses a *lot* of percpu accesses, you get both. The advantage of having %r13 point to thread data (which is "stable" as far as the compiler is concerned) as opposed to having it be a per-cpu pointer (which can change randomly due to task switching) is that from a correctness standpoint I really do think that either thread-info or current is *much* easier to handle than using it for the per-cpu base pointer. Linus -- 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: [f2fs-dev] [PATCH] f2fs: remove unneeded write checkpoint in recover_fsync_data
Hi Gu
> -Original Message-
> From: Gu Zheng [mailto:guz.f...@cn.fujitsu.com]
> Sent: Monday, September 23, 2013 9:54 AM
> To: Chao Yu
> Cc: Kim Jaegeuk; linux-f2fs-de...@lists.sourceforge.net;
> linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org; 谭姝
> Subject: Re: [f2fs-dev] [PATCH] f2fs: remove unneeded write checkpoint in
> recover_fsync_data
>
> On 09/22/2013 03:51 PM, Chao Yu wrote:
>
> > Previously, recover_fsync_data still to write checkpoint when there is
> > nothing to recover with normal umount image.
> > It may reduce mount performance and flash memory lifetime, so let's
> > remove it.
> >
> > Signed-off-by: Tan Shu
> > Signed-off-by: Yu Chao
> > ---
> > fs/f2fs/recovery.c |5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c index
> > 51ef5ee..6988e1b 100644
> > --- a/fs/f2fs/recovery.c
> > +++ b/fs/f2fs/recovery.c
> > @@ -419,6 +419,7 @@ int recover_fsync_data(struct f2fs_sb_info *sbi)
> > {
> > struct list_head inode_list;
> > int err;
> > + int is_writecp = 0;
>
> "need_writecp" may be more suitable.
Okay, it increase readability. I will change it.
Thanks.
>
> Thanks,
> Gu
>
> >
> > fsync_entry_slab = f2fs_kmem_cache_create("f2fs_fsync_inode_entry",
> > sizeof(struct fsync_inode_entry), NULL); @@ -436,6
+437,8
> @@ int
> > recover_fsync_data(struct f2fs_sb_info *sbi)
> > if (list_empty(_list))
> > goto out;
> >
> > + is_writecp = 1;
> > +
> > /* step #2: recover data */
> > err = recover_data(sbi, _list, CURSEG_WARM_NODE);
> > BUG_ON(!list_empty(_list));
> > @@ -443,7 +446,7 @@ out:
> > destroy_fsync_dnodes(_list);
> > kmem_cache_destroy(fsync_entry_slab);
> > sbi->por_doing = 0;
> > - if (!err)
> > + if (!err && is_writecp)
> > write_checkpoint(sbi, false);
> > return err;
> > }
> > ---
> >
> > --
> > 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 v3 0/3] mm/zswap bugfix: memory leaks and other problems
On Mon, Sep 23, 2013 at 04:19:36PM +0800, Weijie Yang wrote: > This patch series fix a few bugs in mm/zswap based on Linux-3.11. > > v2 --> v3 > - keep GFP_KERNEL flag Why do you drop this? It's plain BUG. I read Bob's reply but it couldn't justify to let the pain remain. First of all, let's fix it and better idea could come later. > > v1 --> v2 > - free memory in zswap_frontswap_invalidate_area(in patch 1) > - fix whitespace corruption (line wrapping) > > Corresponding mail thread: https://lkml.org/lkml/2013/8/18/59 > > These issues fixed/optimized are: > > 1. memory leaks when re-swapon > > 2. memory leaks when invalidate and reclaim occur concurrently > > 3. avoid unnecessary page scanning > > > Issues discussed in that mail thread NOT fixed as it happens rarely or > not a big problem or controversial: > > 1. a "theoretical race condition" when reclaim page > When a handle alloced from zbud, zbud considers this handle is used > validly by upper(zswap) and can be a candidate for reclaim. But zswap has > to initialize it such as setting swapentry and adding it to rbtree. > so there is a race condition, such as: > thread 0: obtain handle x from zbud_alloc > thread 1: zbud_reclaim_page is called > thread 1: callback zswap_writeback_entry to reclaim handle x > thread 1: get swpentry from handle x (it is random value now) > thread 1: bad thing may happen > thread 0: initialize handle x with swapentry > > 2. frontswap_map bitmap not cleared after zswap reclaim > Frontswap uses frontswap_map bitmap to track page in "backend" implementation, > when zswap reclaim a page, the corresponding bitmap record is not cleared. > > 3. the potential that zswap store and reclaim functions called recursively > > > mm/zswap.c | 28 > 1 file changed, 20 insertions(+), 8 deletions(-) > > -- > 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 v3 3/3] mm/zswap: avoid unnecessary page scanning
On Mon, Sep 23, 2013 at 04:21:49PM +0800, Weijie Yang wrote: > add SetPageReclaim before __swap_writepage so that page can be moved to the > tail of the inactive list, which can avoid unnecessary page scanning as this > page was reclaimed by swap subsystem before. > > Signed-off-by: Weijie Yang > Reviewed-by: Bob Liu > Cc: Minchan Kim > Cc: sta...@vger.kernel.org > Acked-by: Seth Jennings Reviewed-by: Minchan Kim -- 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 v3 2/3] mm/zswap: bugfix: memory leak when invalidate and reclaim occur concurrently
On Mon, Sep 23, 2013 at 04:21:49PM +0800, Weijie Yang wrote:
> Consider the following scenario:
> thread 0: reclaim entry x (get refcount, but not call
> zswap_get_swap_cache_page)
> thread 1: call zswap_frontswap_invalidate_page to invalidate entry x.
> finished, entry x and its zbud is not freed as its refcount != 0
> now, the swap_map[x] = 0
> thread 0: now call zswap_get_swap_cache_page
> swapcache_prepare return -ENOENT because entry x is not used any more
> zswap_get_swap_cache_page return ZSWAP_SWAPCACHE_NOMEM
> zswap_writeback_entry do nothing except put refcount
> Now, the memory of zswap_entry x and its zpage leak.
>
> Modify:
> - check the refcount in fail path, free memory if it is not referenced.
Hmm, I don't like this because zswap refcount routine is already mess for me.
I'm not sure why it was designed from the beginning. I hope we should fix it
first.
1. zswap_rb_serach could include zswap_entry_get semantic if it founds a entry
from
the tree. Of course, we should ranme it as find_get_zswap_entry like
find_get_page.
2. zswap_entry_put could hide resource free function like zswap_free_entry so
that
all of caller can use it easily following pattern.
find_get_zswap_entry
...
...
zswap_entry_put
Of course, zswap_entry_put have to check the entry is in the tree or not
so if someone already removes it from the tree, it should avoid double remove.
One of the concern I can think is that approach extends critical section
but I think it would be no problem because more bottleneck would be [de]compress
functions. If it were really problem, we can mitigate a problem with moving
unnecessary functions out of zswap_free_entry because it seem to be rather
over-enginnering.
> - use ZSWAP_SWAPCACHE_FAIL instead of ZSWAP_SWAPCACHE_NOMEM as the fail path
> can be not only caused by nomem but also by invalidate.
>
> Signed-off-by: Weijie Yang
> Reviewed-by: Bob Liu
> Cc: Minchan Kim
> Cc: sta...@vger.kernel.org
> Acked-by: Seth Jennings
> ---
> mm/zswap.c | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/mm/zswap.c b/mm/zswap.c
> index cbd9578..1be7b90 100644
> --- a/mm/zswap.c
> +++ b/mm/zswap.c
> @@ -387,7 +387,7 @@ static void zswap_free_entry(struct zswap_tree *tree,
> struct zswap_entry *entry)
> enum zswap_get_swap_ret {
> ZSWAP_SWAPCACHE_NEW,
> ZSWAP_SWAPCACHE_EXIST,
> - ZSWAP_SWAPCACHE_NOMEM
> + ZSWAP_SWAPCACHE_FAIL,
> };
>
> /*
> @@ -401,9 +401,9 @@ enum zswap_get_swap_ret {
> * added to the swap cache, and returned in retpage.
> *
> * If success, the swap cache page is returned in retpage
> - * Returns 0 if page was already in the swap cache, page is not locked
> - * Returns 1 if the new page needs to be populated, page is locked
> - * Returns <0 on error
> + * Returns ZSWAP_SWAPCACHE_EXIST if page was already in the swap cache
> + * Returns ZSWAP_SWAPCACHE_NEW if the new page needs to be populated, page
> is locked
> + * Returns ZSWAP_SWAPCACHE_FAIL on error
> */
> static int zswap_get_swap_cache_page(swp_entry_t entry,
> struct page **retpage)
> @@ -475,7 +475,7 @@ static int zswap_get_swap_cache_page(swp_entry_t entry,
> if (new_page)
> page_cache_release(new_page);
> if (!found_page)
> - return ZSWAP_SWAPCACHE_NOMEM;
> + return ZSWAP_SWAPCACHE_FAIL;
> *retpage = found_page;
> return ZSWAP_SWAPCACHE_EXIST;
> }
> @@ -529,11 +529,11 @@ static int zswap_writeback_entry(struct zbud_pool
> *pool, unsigned long handle)
>
> /* try to allocate swap cache page */
> switch (zswap_get_swap_cache_page(swpentry, )) {
> - case ZSWAP_SWAPCACHE_NOMEM: /* no memory */
> + case ZSWAP_SWAPCACHE_FAIL: /* no memory or invalidate happened */
> ret = -ENOMEM;
> goto fail;
>
> - case ZSWAP_SWAPCACHE_EXIST: /* page is unlocked */
> + case ZSWAP_SWAPCACHE_EXIST:
> /* page is already in the swap cache, ignore for now */
> page_cache_release(page);
> ret = -EEXIST;
> @@ -591,7 +591,12 @@ static int zswap_writeback_entry(struct zbud_pool *pool,
> unsigned long handle)
>
> fail:
> spin_lock(>lock);
> - zswap_entry_put(entry);
> + refcount = zswap_entry_put(entry);
> + if (refcount <= 0) {
> + /* invalidate happened, consider writeback as success */
> + zswap_free_entry(tree, entry);
> + ret = 0;
> + }
> spin_unlock(>lock);
> return ret;
> }
> --
> 1.7.10.4
>
>
> --
> 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
Re: [PATCH v6 0/5] memcg, cgroup: kill css id
On Tue, 24 Sep 2013 08:32:03 +0800 Li Zefan wrote: > On 2013/9/23 21:12, Tejun Heo wrote: > > On Mon, Sep 23, 2013 at 09:08:16AM -0400, Tejun Heo wrote: > >> Hello, > >> > >> On Mon, Sep 23, 2013 at 04:55:20PM +0800, Li Zefan wrote: > >>> The whole patchset has been acked and reviewed by Michal and Tejun. > >>> Could you merge it into mm tree? > >> > >> Ah... I really hoped that this had been merged during -rc1 window. > >> Andrew, would it be okay to carry this series through cgroup tree? It > >> doesn't really have much to do with mm proper and it's a PITA to have > >> to keep updating css_id code from cgroup side when it's scheduled to > >> go away. If carried in -mm, it's likely to cause conflicts with > >> ongoing cgroup changes too. > > I would love to see this patchset go through cgroup tree. The changes to > memcg is quite small, It seems logical to put this in the cgroup tree as that's where most of the impact occurs. > and as -mm tree is based on -next it won't cause > future conflicts. That's no longer the case - I'm staging -mm patches ahead of linux-next now. Except in cases where that's impractical, such as the 3.12 memcg changes which were pretty heavily impacted by cgroups tree changes. > > > > Also, wasn't this already in -mm during the last devel cycle? ISTR > > conflicts with it in -mm with other cgroup core changes. Is there any > > specific reason why this wasn't merged during the merge windw? > > > > No, it never went into -mm tree... I guess it's because Andrew was too > busy and overlooked this patchset? I'm not sure what happened to the August 7 patchset, actually. I don't often overlook stuff - I'll skip things if the timing is terrible or if the review comments indicate that another version is coming. But none of that seems to be the case here. hmm... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/2] gpio / ACPI: add support for GPIO operation regions
> From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com] > Sent: Tuesday, September 17, 2013 4:37 PM > > On Mon, Sep 16, 2013 at 11:35:56PM +, Zheng, Lv wrote: > > > From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com] > > > Sent: Monday, September 16, 2013 4:11 PM > > > > > > On Mon, Sep 16, 2013 at 01:21:53AM +, Zheng, Lv wrote: > > > > > A pseudo device may be created to access the GPIO operation region > > > > > fields provided by one GPIO device. > > > > > The pseudo device may have other functions to access other GPIO > > > > > operation region fields provided by other GPIO devices, or even > worse > > > to > > > > > access other ACPI provided value-adds. > > > > > So hierarchically the pseudo device only requires CPU, thus should > > > > > not be under the GPIO device, which means the GPIO operation > > > regions > > > > > have nothing to do with the GPIO devices' ACPI handle. > > > > > > > > Sorry for the wording. > > > > It's better to say the GPIO operation region users haven't strict > > > > relationship to the GPIO operation region providers. > > > > As the installation is to provide GPIO operation regions to the users, > > > > it > > > > shouldn't relate to the providers' ACPI handle. > > > > > > If I understand you correctly you mean that there might be multiple users > > > (different devices) for the same GPIO operation region, right? > > > > No, this is not what I meant. > > Can one vendor device uses two or more GPIO pins from different GPIO ports? > > Yes. So how can such a device under one of these GPIO ports? It can only be under one particular GPIO port device, right? Thus I believe such device will appear below other devices rather than below a GPIO port device in the ACPI namespace. > > > > That shouldn't be a problem as far as I can tell. > > > > > > What comes to the hierarchy you refer, I'm not sure if that is a problem > > > either (unless I'm missing something). The GPIO can be used anywhere in > > > the > > > ASL, it doesn't have to be descendant of the GPIO device. You only need to > > > do something like this: > > > > > > // Assert the GPIO > > > Store(1, \_SB.PCI0.SHD3) > > > > > > In other words, use the fully qualified name. > > > > Yes, which means this line of code can be everywhere in the namespace. > > It is not required to be under one particular GPIO device as long as there > > is an operation region defined in that scope. > > > > The problem is the installation, the first parameter for > > acpi_install_address_space_handler() is a namespace node, the function > > will call _REG for all OperationRegions below the scope whose top most > > node is the specified node. > > The nodes out of this scope are not affected. So if an OperationRegion > > is defined out of this scope, problem happens. > > I suppose for that operation region another GPIO device should be > introduced then, no? I believe the answer is no. > So if we don't have a GPIO driver for the given operation region, what can > we do? We don't want the ASL code to erroneusly think that there is an > operation region available when it is not. I think GPIO "address_space_handler" should be provided by an ACPI GPIO address space module rather than provided by a particular GPIO driver. Actually, without the readiness of the GPIO driver, currently ASL code can still access the GPIO fields, though it just results in "handler not found" ACPICA error message. If the "setup" callback is implemented, then the proper GPIO driver can be matched in this "setup" callback. If the GPIO driver hasn't been loaded by Linux and thus not matched in the "setup" callback, from users' point of view, the result is just changing the error message from "handler not found" to "driver not found". Thanks and best regards -Lv -- 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 0/5] memcg, cgroup: kill css id
On 2013/9/23 21:12, Tejun Heo wrote: > On Mon, Sep 23, 2013 at 09:08:16AM -0400, Tejun Heo wrote: >> Hello, >> >> On Mon, Sep 23, 2013 at 04:55:20PM +0800, Li Zefan wrote: >>> The whole patchset has been acked and reviewed by Michal and Tejun. >>> Could you merge it into mm tree? >> >> Ah... I really hoped that this had been merged during -rc1 window. >> Andrew, would it be okay to carry this series through cgroup tree? It >> doesn't really have much to do with mm proper and it's a PITA to have >> to keep updating css_id code from cgroup side when it's scheduled to >> go away. If carried in -mm, it's likely to cause conflicts with >> ongoing cgroup changes too. I would love to see this patchset go through cgroup tree. The changes to memcg is quite small, and as -mm tree is based on -next it won't cause future conflicts. > > Also, wasn't this already in -mm during the last devel cycle? ISTR > conflicts with it in -mm with other cgroup core changes. Is there any > specific reason why this wasn't merged during the merge windw? > No, it never went into -mm tree... I guess it's because Andrew was too busy and overlooked this patchset? -- 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 5/6] clk: exynos-audss: add support for Exynos 5420
The AudioSS block on Exynos 5420 has an additional clock gate for the
ADMA bus clock.
Signed-off-by: Andrew Bresticker
---
Changes since v1:
- added type enum and made comparison against that instead of compatibility
string
---
.../devicetree/bindings/clock/clk-exynos-audss.txt | 7 +++--
drivers/clk/samsung/clk-exynos-audss.c | 35 ++
include/dt-bindings/clk/exynos-audss-clk.h | 3 +-
3 files changed, 36 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
index 85b9e28..180e883 100644
--- a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
+++ b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
@@ -8,8 +8,10 @@ Required Properties:
- compatible: should be one of the following:
- "samsung,exynos4210-audss-clock" - controller compatible with all Exynos4
SoCs.
- - "samsung,exynos5250-audss-clock" - controller compatible with all Exynos5
SoCs.
-
+ - "samsung,exynos5250-audss-clock" - controller compatible with Exynos5250
+SoCs.
+ - "samsung,exynos5420-audss-clock" - controller compatible with Exynos5420
+SoCs.
- reg: physical base address and length of the controller's register set.
- #clock-cells: should be 1.
@@ -49,6 +51,7 @@ i2s_bus 6
sclk_i2s7
pcm_bus 8
sclk_pcm9
+adma10 Exynos5420
Example 1: An example of a clock controller node using the default input
clock names is listed below.
diff --git a/drivers/clk/samsung/clk-exynos-audss.c
b/drivers/clk/samsung/clk-exynos-audss.c
index afb53de..8ccf3788 100644
--- a/drivers/clk/samsung/clk-exynos-audss.c
+++ b/drivers/clk/samsung/clk-exynos-audss.c
@@ -19,6 +19,12 @@
#include
+enum exynos_audss_clk_type {
+ TYPE_EXYNOS4210,
+ TYPE_EXYNOS5250,
+ TYPE_EXYNOS5420,
+};
+
static DEFINE_SPINLOCK(lock);
static struct clk **clk_table;
static void __iomem *reg_base;
@@ -59,6 +65,16 @@ static struct syscore_ops exynos_audss_clk_syscore_ops = {
};
#endif /* CONFIG_PM_SLEEP */
+static const struct of_device_id exynos_audss_clk_of_match[] = {
+ { .compatible = "samsung,exynos4210-audss-clock",
+ .data = (void *)TYPE_EXYNOS4210, },
+ { .compatible = "samsung,exynos5250-audss-clock",
+ .data = (void *)TYPE_EXYNOS5250, },
+ { .compatible = "samsung,exynos5420-audss-clock",
+ .data = (void *)TYPE_EXYNOS5420, },
+ {},
+};
+
/* register exynos_audss clocks */
static int exynos_audss_clk_probe(struct platform_device *pdev)
{
@@ -67,6 +83,13 @@ static int exynos_audss_clk_probe(struct platform_device
*pdev)
const char *sclk_pcm_p = "sclk_pcm0";
struct clk *pll_ref, *pll_in, *cdclk, *sclk_audio, *sclk_pcm_in;
struct resource *res;
+ const struct of_device_id *match;
+ enum exynos_audss_clk_type variant;
+
+ match = of_match_node(exynos_audss_clk_of_match, pdev->dev.of_node);
+ if (!match)
+ return -EINVAL;
+ variant = (enum exynos_audss_clk_type)match->data;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
reg_base = devm_ioremap_resource(>dev, res);
@@ -145,6 +168,12 @@ static int exynos_audss_clk_probe(struct platform_device
*pdev)
sclk_pcm_p, CLK_SET_RATE_PARENT,
reg_base + ASS_CLK_GATE, 5, 0, );
+ if (variant == TYPE_EXYNOS5420) {
+ clk_table[EXYNOS_ADMA] = clk_register_gate(NULL, "adma",
+ "dout_srp", CLK_SET_RATE_PARENT,
+ reg_base + ASS_CLK_GATE, 9, 0, );
+ }
+
#ifdef CONFIG_PM_SLEEP
register_syscore_ops(_audss_clk_syscore_ops);
#endif
@@ -168,12 +197,6 @@ static int exynos_audss_clk_remove(struct platform_device
*pdev)
return 0;
}
-static const struct of_device_id exynos_audss_clk_of_match[] = {
- { .compatible = "samsung,exynos4210-audss-clock", },
- { .compatible = "samsung,exynos5250-audss-clock", },
- {},
-};
-
static struct platform_driver exynos_audss_clk_driver = {
.driver = {
.name = "exynos-audss-clk",
diff --git a/include/dt-bindings/clk/exynos-audss-clk.h
b/include/dt-bindings/clk/exynos-audss-clk.h
index 8279f42..0ae6f5a 100644
--- a/include/dt-bindings/clk/exynos-audss-clk.h
+++ b/include/dt-bindings/clk/exynos-audss-clk.h
@@ -19,7 +19,8 @@
#define EXYNOS_SCLK_I2S7
#define EXYNOS_PCM_BUS 8
#define EXYNOS_SCLK_PCM9
+#define EXYNOS_ADMA10
-#define EXYNOS_AUDSS_MAX_CLKS 10
+#define EXYNOS_AUDSS_MAX_CLKS 11
#endif
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
[PATCH V2 6/6] ARM: dts: exynos5420: add input clocks to audss clock controller
Specify the remaining input clocks (pll_ref, pll_in, and sclk_pcm_in)
for the AudioSS clock controller.
Signed-off-by: Andrew Bresticker
---
Changes since v1:
- specified additional input clocks
---
arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index d537cd7..056b55e 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -72,8 +72,8 @@
compatible = "samsung,exynos5420-audss-clock";
reg = <0x0381 0x0C>;
#clock-cells = <1>;
- clocks = < 148>;
- clock-names = "sclk_audio";
+ clocks = < 1>, < 5>, < 148>, < 149>;
+ clock-names = "pll_ref", "pll_in", "sclk_audio", "sclk_pcm_in";
};
codec@1100 {
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] perf trace: Add mmap2 handler
Arnaldo: I see this is you perf core tree; the problem exists in Linus' tree so it is needed in your urgent tree as well. David On 9/22/13 7:44 PM, David Ahern wrote: 5c5e854b changed perf_event__synthesize_mmap_events to generate MMAP2 events. Since perf-trace does not have a handler for it it dies with a segfault when trying to process files: perf trace -i /tmp/perf.data Segmentation fault Signed-off-by: David Ahern --- tools/perf/builtin-trace.c |1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c index 9c7f017..f61c968 100644 --- a/tools/perf/builtin-trace.c +++ b/tools/perf/builtin-trace.c @@ -1383,6 +1383,7 @@ static int trace__replay(struct trace *trace) trace->tool.sample = trace__process_sample; trace->tool.mmap = perf_event__process_mmap; + trace->tool.mmap2 = perf_event__process_mmap2; trace->tool.comm = perf_event__process_comm; trace->tool.exit = perf_event__process_exit; trace->tool.fork = perf_event__process_fork; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 3/6] clk: exynos5250: add clock ID for div_pcm0
There is no gate for the PCM clock input to the AudioSS block, so
the parent of sclk_pcm is div_pcm0. Add a clock ID for it so that
we can reference it in device trees.
Signed-off-by: Andrew Bresticker
Reviewed-by: Tomasz Figa
---
Documentation/devicetree/bindings/clock/exynos5250-clock.txt | 1 +
drivers/clk/samsung/clk-exynos5250.c | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 24765c1..67e9a47 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -62,6 +62,7 @@ clock which they consume.
div_i2s1 157
div_i2s2 158
sclk_hdmiphy 159
+ div_pcm0 160
[Peripheral Clock Gates]
diff --git a/drivers/clk/samsung/clk-exynos5250.c
b/drivers/clk/samsung/clk-exynos5250.c
index adf3234..dec5376 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -108,7 +108,7 @@ enum exynos5250_clks {
sclk_mmc0, sclk_mmc1, sclk_mmc2, sclk_mmc3, sclk_sata, sclk_usb3,
sclk_jpeg, sclk_uart0, sclk_uart1, sclk_uart2, sclk_uart3, sclk_pwm,
sclk_audio1, sclk_audio2, sclk_spdif, sclk_spi0, sclk_spi1, sclk_spi2,
- div_i2s1, div_i2s2, sclk_hdmiphy,
+ div_i2s1, div_i2s2, sclk_hdmiphy, div_pcm0,
/* gate clocks */
gscl0 = 256, gscl1, gscl2, gscl3, gscl_wa, gscl_wb, smmu_gscl0,
@@ -301,7 +301,7 @@ static struct samsung_div_clock exynos5250_div_clks[]
__initdata = {
DIV(none, "div_dp", "mout_dp", DIV_DISP1_0, 24, 4),
DIV(none, "div_jpeg", "mout_jpeg", DIV_GEN, 4, 4),
DIV(none, "div_audio0", "mout_audio0", DIV_MAU, 0, 4),
- DIV(none, "div_pcm0", "sclk_audio0", DIV_MAU, 4, 8),
+ DIV(div_pcm0, "div_pcm0", "sclk_audio0", DIV_MAU, 4, 8),
DIV(none, "div_sata", "mout_sata", DIV_FSYS0, 20, 4),
DIV(none, "div_usb3", "mout_usb3", DIV_FSYS0, 24, 4),
DIV(none, "div_mmc0", "mout_mmc0", DIV_FSYS1, 0, 4),
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 4/6] ARM: dts: exynos5250: add input clocks to audss clock controller
Specify pll_ref, pll_in, sclk_audio, and sclk_pcm_in for the AudioSS
clock controller.
Signed-off-by: Andrew Bresticker
---
Changes since v1:
- specified additional input clocks
---
arch/arm/boot/dts/exynos5250.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 7d7cc77..35e2838 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -88,6 +88,8 @@
compatible = "samsung,exynos5250-audss-clock";
reg = <0x0381 0x0C>;
#clock-cells = <1>;
+ clocks = < 1>, < 7>, < 138>, < 160>;
+ clock-names = "pll_ref, "pll_in", "sclk_audio", "sclk_pcm_in";
};
timer {
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 2/6] clk: exynos-audss: allow input clocks to be specified in device tree
This allows the input clocks to the Exynos AudioSS block to be
specified via device-tree bindings. Default names will be used
when an input clock is not given.
Signed-off-by: Andrew Bresticker
---
Changes since v1:
- listed input clocks as required properties
---
.../devicetree/bindings/clock/clk-exynos-audss.txt | 32 --
drivers/clk/samsung/clk-exynos-audss.c | 25 +
2 files changed, 50 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
index 75e2e19..85b9e28 100644
--- a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
+++ b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
@@ -14,6 +14,21 @@ Required Properties:
- #clock-cells: should be 1.
+- clocks:
+ - pll_ref: Fixed rate PLL reference clock, parent of mout_audss. "fin_pll"
+is used if not specified.
+ - pll_in: Input PLL to the AudioSS block, parent of mout_audss. "fout_epll"
+is used if not specified.
+ - cdclk: External i2s clock, parent of mout_i2s. "cdclk0" is used if not
+specified.
+ - sclk_audio: Audio bus clock, parent of mout_i2s. "sclk_audio0" is used if
+not specified.
+ - sclk_pcm_in: PCM clock, parent of sclk_pcm. "sclk_pcm0" is used if not
+specified.
+
+- clock-names: Aliases for the above clocks. They should be "pll_ref",
+ "pll_in", "cdclk", "sclk_audio", and "sclk_pcm_in" respectively.
+
The following is the list of clocks generated by the controller. Each clock is
assigned an identifier and client nodes use this identifier to specify the
clock which they consume. Some of the clocks are available only on a particular
@@ -35,15 +50,28 @@ sclk_i2s7
pcm_bus 8
sclk_pcm9
-Example 1: An example of a clock controller node is listed below.
+Example 1: An example of a clock controller node using the default input
+ clock names is listed below.
+
+clock_audss: audss-clock-controller@381 {
+ compatible = "samsung,exynos5250-audss-clock";
+ reg = <0x0381 0x0C>;
+ #clock-cells = <1>;
+};
+
+Example 2: An example of a clock controller node with the input clocks
+ specified.
clock_audss: audss-clock-controller@381 {
compatible = "samsung,exynos5250-audss-clock";
reg = <0x0381 0x0C>;
#clock-cells = <1>;
+ clocks = < 1>, < 7>, < 138>, < 160>,
+ <_i2s_clk>;
+ clock-names = "pll_ref", "pll_in", "sclk_audio", "sclk_pcm_in", "cdclk";
};
-Example 2: I2S controller node that consumes the clock generated by the clock
+Example 3: I2S controller node that consumes the clock generated by the clock
controller. Refer to the standard clock bindings for information
about 'clocks' and 'clock-names' property.
diff --git a/drivers/clk/samsung/clk-exynos-audss.c
b/drivers/clk/samsung/clk-exynos-audss.c
index c512efd..afb53de 100644
--- a/drivers/clk/samsung/clk-exynos-audss.c
+++ b/drivers/clk/samsung/clk-exynos-audss.c
@@ -34,10 +34,6 @@ static unsigned long reg_save[][2] = {
{ASS_CLK_GATE, 0},
};
-/* list of all parent clock list */
-static const char *mout_audss_p[] = { "fin_pll", "fout_epll" };
-static const char *mout_i2s_p[] = { "mout_audss", "cdclk0", "sclk_audio0" };
-
#ifdef CONFIG_PM_SLEEP
static int exynos_audss_clk_suspend(void)
{
@@ -66,6 +62,10 @@ static struct syscore_ops exynos_audss_clk_syscore_ops = {
/* register exynos_audss clocks */
static int exynos_audss_clk_probe(struct platform_device *pdev)
{
+ const char *mout_audss_p[] = {"fin_pll", "fout_epll"};
+ const char *mout_i2s_p[] = {"mout_audss", "cdclk0", "sclk_audio0"};
+ const char *sclk_pcm_p = "sclk_pcm0";
+ struct clk *pll_ref, *pll_in, *cdclk, *sclk_audio, *sclk_pcm_in;
struct resource *res;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -88,11 +88,23 @@ static int exynos_audss_clk_probe(struct platform_device
*pdev)
of_clk_add_provider(pdev->dev.of_node, of_clk_src_onecell_get,
_data);
+ pll_ref = devm_clk_get(>dev, "pll_ref");
+ pll_in = devm_clk_get(>dev, "pll_in");
+ if (!IS_ERR(pll_ref))
+ mout_audss_p[0] = __clk_get_name(pll_ref);
+ if (!IS_ERR(pll_in))
+ mout_audss_p[1] = __clk_get_name(pll_in);
clk_table[EXYNOS_MOUT_AUDSS] = clk_register_mux(NULL, "mout_audss",
mout_audss_p, ARRAY_SIZE(mout_audss_p),
CLK_SET_RATE_NO_REPARENT,
reg_base + ASS_CLK_SRC, 0, 1, 0, );
+ cdclk = devm_clk_get(>dev, "cdclk");
+ sclk_audio = devm_clk_get(>dev, "sclk_audio");
+ if (!IS_ERR(cdclk))
+ mout_i2s_p[1] = __clk_get_name(cdclk);
+ if (!IS_ERR(sclk_audio))
+ mout_i2s_p[2] =
Re: [Suspend-devel] [BUG] 3.7-rc regression bisected: s2disk fails to resume image: Processes could not be frozen, cannot continue resuming
Hi!
> > And from suspend_ioctls.h:
> > #define SNAPSHOT_IOC_MAGIC '3'
> > #define SNAPSHOT_FREEZE _IO(SNAPSHOT_IOC_MAGIC, 1)
> >
> > My mistake, should be '3' instead of 3.
>
> OK... The thing to test, then, is what does __usermodehelper_disable()
> return to freeze_processes(). If that's where this -EAGAIN comes from,
> we at least have a plausible theory re what's going on.
>
> freeze_processes() uses __usermodehelper_disable() to stop any new userland
> processes spawned by UMH (modprobe, etc.) and waits for ones it might be
> waiting for to complete. Then it does try_to_freeze_tasks(), which
> freezes remaining userland, carefully skipping the current thread.
> However, it misses the possibility that current thread might have been
> spawned by something that had been launched by UMH, with UMH waiting
> for it. Which is the case of everything spawned by linuxrc.
>
> I'd try something like diff below, but I'm *NOT* familiar with swsusp at
> all; it's not for mainline until ACKed by swsusp folks.
>
> diff --git a/kernel/kmod.c b/kernel/kmod.c
> index fb32636..d968882 100644
> --- a/kernel/kmod.c
> +++ b/kernel/kmod.c
> @@ -571,7 +571,8 @@ int call_usermodehelper_exec(struct subprocess_info
> *sub_info, int wait)
> DECLARE_COMPLETION_ONSTACK(done);
> int retval = 0;
>
> - helper_lock();
> + if (!(current->flags & PF_FREEZER_SKIP))
> + helper_lock();
> if (!khelper_wq || usermodehelper_disabled) {
> retval = -EBUSY;
> goto out;
> @@ -611,7 +612,8 @@ wait_done:
> out:
> call_usermodehelper_freeinfo(sub_info);
> unlock:
> - helper_unlock();
> + if (!(current->flags & PF_FREEZER_SKIP))
> + helper_unlock();
> return retval;
> }
> EXPORT_SYMBOL(call_usermodehelper_exec);
PF_FREEZER_SKIP flag is manipulated at about 1000 places, so I'm not
sure this will nest correctly. They seem to be in form of
|= FREEZER_SKIP
schedule()
&= ~FREEZER_SKIP
so this should be safe, but...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 00/10] VFS hot tracking
On Tue, Sep 17, 2013 at 06:17:45AM +0800, zwu.ker...@gmail.com wrote: > From: Zhi Yong Wu > > The patchset is trying to introduce hot tracking function in > VFS layer, which will keep track of real disk I/O in memory. > By it, you will easily know more details about disk I/O, and > then detect where disk I/O hot spots are. Also, specific FS > can take use of it to do accurate defragment, and hot relocation > support, etc. > > Now it's time to send out its V5 for external review, and > any comments or ideas are appreciated, thanks. FWIW, the most fundamental problem I see with this is that the data you are collecting is very sensitive to VM pressure details. The hotspots wrt accesses (i.e. the stuff accessed all the time) will not generate a lot of IO - they'll just sit in cache and look very cold for your code. The stuff that is accessed very rarely will also look cold. The hot ones will be those that get in and out of cache often; IOW, the ones that are borderline - a bit less memory pressure and they would've stayed in cache. I would expect that to vary very much from run to run, which would make its use for decisions like SSD vs. HD rather dubious... Do you have that data collected on some real tasks under varying memory pressure conditions? How stable the results are? Another question: do you have perf profiles for system with that stuff enabled, on boxen with many CPUs? You are using a lot of spinlocks there; how much contention and cacheline ping-pong are you getting on root->t_lock, for example? Ditto for cacheline ping-pong on root->hot_cnt, while we are at it... Comments re code: * don't export the stuff until it's used by a module. And as a general policy, please, do not use EXPORT_SYMBOL_GPL in fs/*. Either don't export at all, or pick a sane API that would not expose the guts of your code (== wouldn't require you to look at the users to decide what will and will not break on changes in your code) and export that. As far as I'm concerned, all variants of EXPORT_SYMBOL are greatly overused and EXPORT_SYMBOL_GPL is an exercise in masturbation... * hot_inode_item_lookup() is a couple of functions smashed together; split it, please, and lose the "alloc" argument. * hot_inode_item_unlink() is used when the last link is killed by unlink(2), but not when it's killed by successful rename(2). Why? * what happens when one opens a file, unlinks it and starts doing IO? hot_freqs_update() will be called, re-creating the inode item unlink has killed... * for pity sake, use inlines - the same hot_freqs_update() on a filesystem that doesn't have this stuff enabled will *still* branch pretty far out of line, only to return after checking that ->s_hot_root is NULL. Incidentally, we still have about twenty spare bits in inode flags; use one (S_TEMP_COLLECTED, or something like that) instead of that check. Checking it is considerably cheaper than checking ->i_sb->s_hot_root. * hot_bit_shift() is bloody annoying. Why does true mean "up", false - "down" and why is it easier to memorize that than just use explicit << and >>? * file->f_dentry->d_inode is spelled file_inode(file), TYVM (so does file->f_path.dentry->d_inode, actually). * #ifdef __KERNEL__ in include/linux/* is wrong; use include/uapi/linux/* for the bits userland needs to see. * checks for ->i_nlink belong under ->i_mutex. As it is, two unlink(2) killing two last links to the same file can very well _both_ call hot_inode_item_unlink(), with obvious unpleasant results. -- 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 2/2] RX-51: ARM errata 430973 workaround
Hi! > > Tony, if you did not have time for review this patch months ago > > or you found it only today - no problem, I understand it. But > > what I need to know is what will happen with board-rx51-* files > > (and when?) You can see that DT does not have definitions of all > > n900 hw parts (plus it is not in last 3.11 kernel!) which means > > that DT is not usable for me and other n900 people. This also > > means that I cannot rewrite my patches for DT and test if they > > working. > > I usually stop looking at new code around -rc4 and concentrate > on fixes until -rc1 or so. So there can be easily one month > delays on reviewing stuff depending on where we are with the > current merge window or -rc cycle, sorry if that's annoying. > > The .dts files will be separate from the kernel soonish, so > that's not be a show stopper. Just like all the board specific > .config files are separate from the kernel already. Too bad our > .dts changes did not get merged for v3.12 because of conflicts > with other branches, but hey, they should be independent from the > kernel anyways. Well... I'd say it is still time to merge them. "New hardware support" is ok after -rc1. > The board files will be going away as soon as things are working > with DT. We've been pretty much only applying fixes to them for > quite some time now. For the timeline, the earliest we'll be able > to remove the board-*.c files and platform data is for v3.13 And it would be good to merge n900 dts support for 3.12. Adding device tree at the same release as removing board support files in same release leaves zero room for testing, and practically guarantees regressions. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] device mapper fixes for 3.12
The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f: Linux 3.12-rc1 (2013-09-16 16:17:51 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git tags/dm-3.12-fixes for you to fetch changes up to e8603136cb04ec2d0c9b4b5be7a071fc003cb399: dm: add reserved_bio_based_ios module parameter (2013-09-23 10:42:24 -0400) Please pull, thanks. Mike A set of device-mapper fixes for 3.12. A few fixes for dm-snapshot, a 32 bit fix for dm-stats, a couple error handling fixes for dm-multipath. A fix for the thin provisioning target to not expose non-zero discard limits if discards are disabled. Lastly, add two DM module parameters which allow users to tune the emergency memory reserves that DM mainatins per device -- this helps fix a long-standing issue for dm-multipath. The conservative default reserve for request-based dm-multipath devices (256) has proven problematic for users with many multipathed SCSI devices but relatively little memory. To responsibly select a smaller value users should use the new nr_bios tracepoint info (via commit 75afb352 "block: Add nr_bios to block_rq_remap tracepoint") to determine the peak number of bios their workloads create. Jun'ichi Nomura (1): dm mpath: do not fail path on -ENOSPC Mike Snitzer (5): dm mpath: disable WRITE SAME if it fails dm thin: do not expose non-zero discard limits if discards disabled dm: lower bio-based mempool reservation dm: add reserved_rq_based_ios module parameter dm: add reserved_bio_based_ios module parameter Mikulas Patocka (3): dm stats: fix possible counter corruption on 32-bit systems dm snapshot: workaround for a false positive lockdep warning dm-snapshot: fix performance degradation due to small hash size drivers/md/dm-io.c | 7 ++-- drivers/md/dm-mpath.c | 18 --- drivers/md/dm-snap-persistent.c | 2 +- drivers/md/dm-snap.c| 5 ++- drivers/md/dm-stats.c | 23 + drivers/md/dm-thin.c| 14 ++-- drivers/md/dm.c | 71 ++--- drivers/md/dm.h | 3 ++ include/linux/device-mapper.h | 3 +- 9 files changed, 120 insertions(+), 26 deletions(-) -- 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 GIT PULL] softirq: Consolidation and stack overrun fix
On Sun, 2013-09-22 at 15:22 -0700, Linus Torvalds wrote: > - use %r13 for the per-thread thread-info pointer instead. A > per-thread pointer is *not* volatile like the per-cpu base is. .../... > Alternatively, make %r13 point to the percpu side, but make sure that > you always use an asm accessor to fetch the value. In particular, I > think you need to make __my_cpu_offset be an inline asm that fetches > %r13 into some other register. Otherwise you can never get it right. BTW, that boils down to a choice between using r13 as either a TLS for current or current_thread_info, or as a per-cpu pointer, which one is the most performance critical ? Now in the first case, it seems to me that using it as "current" rather than "current_thread_info()" is a better idea since we access current a LOT more overall in the kernel, from there we can find a way to put thread_info into task struct (via thread struct maybe) to make it a simple offset from current. The big pro of that approach is of course that r13 becomes the TLS as intended, and we can feel a lot more comfortable that we are "safe" vs. whatever crazyness gcc will come up with next. The flip side is that per-cpu will remain a load away, so getting the address of a per-cpu variable would typically be a 3 instruction deal involving a load and a pair of adds to get to the address, then the actual per-cpu access proper. This is equivalent to what we have today (we put the per-cpu offset in the PACA). Using r13 as per-cpu allows to avoid that first load. So what's the most worthwhile thing to do here ? I'm leaning toward 1, ie, stick current in r13 and feel a lot safer about it (I won't have to scrutinize generated code all over the place to convince myself things aren't crossing the barriers), and if the thread_info is in the task struct, that makes accessing it really trivial & fast as well. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger
Hi! > > No, isp1704 is power supply driver and export data via power > > supply (sysfs) interface. It is not regulator but charger driver. > > well it does not charge the battery directly, but just provides a > power line with 5 Volt and a specified amount of current to the > system, doesn't it? I don't want to talk about isp1704, but... LiION charger is just something that provides 4.2V power line with C/10 current limitation... (IOW line between regulators and chargers is very very thin, if it even exists). Pavel (who did use laboratory power supply as emergency battery charger) -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/3] mm/zswap: bugfix: memory leak when re-swapon
On Mon, Sep 23, 2013 at 04:21:49PM +0800, Weijie Yang wrote: > zswap_tree is not freed when swapoff, and it got re-kmalloc in swapon, > so memory-leak occurs. > > Modify: free memory of zswap_tree in zswap_frontswap_invalidate_area(). > > Signed-off-by: Weijie Yang > Reviewed-by: Bob Liu > Cc: Minchan Kim > Cc: sta...@vger.kernel.org > Acked-by: Seth Jennings Reviewed-by: Minchan Kim -- 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 0/4] ipc: shm and msg fixes
On Mon, 2013-09-23 at 09:54 -0700, Linus Torvalds wrote:
> On Sun, Sep 22, 2013 at 11:42 PM, Davidlohr Bueso wrote:
> >>
> >> More importantly, it's wrong. You do the call_rcu() unconditionally,
> >> but it might not be the last use! You need to do it with the same
> >> logic ipc_rcu_putref(), namely at the dropping of the last reference.
> >
> > This is the way IPC has handled things for a long time, no? Security
> > does not depend on the reference counter, as we unconditionally free
> > security structs.
>
> Yes, but that was ok back when the logic was idem-potent and you could
> call it multiple times. Modulo races (I didn't check if we held a
> lock).
>
> You can't do "call_rcu()" more than once, because you'll corrupt the
> rcu list if you do another call_rcu() while the first one is still
> active (and that's a pretty big race window to hit).
Ah, ok understood.
>
> That said, the old behavior was suspect for another reason too: having
> the security blob go away from under a user sounds like it could cause
> various other problems anyway, so I think the old code was at least
> _prone_ to bugs even if it didn't have catastrophic behavior.
Agreed. This makes a lot of sense, I just wanted to verify that we're
all on the same page with this, as it does change current and well
tested logic. Eric, Manfred, please shout if you see a problem,
otherwise I'd appreciate your ack/reviewed-by.
>
> (In reality, I suspect the reference count is never elevated in
> practice, so there is only one case that calls the security freeing
> thing, so this may all be pretty much theoretical, but at least from a
> logic standpoint the code clearly makes a big deal about the whole
> refcount and "last user turns off the lights").
Right, this would/should have come up years ago if it were actually
occurring in practice.
>
> > What you're suggesting, is (i) freeing security will now depend on the
> > refcount (wouldn't this cause cases where we actually never end up
> > freeing?)
>
> The security layer better not have any refcounted backpointers to the
> shm, so I don't see why that would be a new issue.
>
> > and (ii) in the scenarios we actually need to free the
> > security, delay it along with freeing the actual ipc_rcu stuff.
>
> Well, that's the whole point. The security blob should have the same
> lifetime as the ipc blob it is associated with.
>
> Getting rid of the security blob before the thing it is supposed to
> protect sounds like a bug to me. In fact, it's the bug that this
> whole thread has been about. No?
>
> > If I understand correctly, then we'd have:
> >
> > void ipc_rcu_putref(void *ptr, void (*func)(struct rcu_head *head))
> > {
> > struct ipc_rcu *p = ((struct ipc_rcu *)ptr) - 1;
> >
> > if (!atomic_dec_and_test(>refcount))
> > return;
> >
> > call_rcu(>rcu, func);
> > }
>
> Exactly.
Ok, so here's the code - again I've tested it with LTP on the resources
I have. While I have yet to hit the races we are trying to address, I
just wanted to make sure it doesn't affect in anything else. The changes
are pretty monotonous and affect all forms of IPC - it doesn't make
sense splitting it since we're changing the global putref logic. All in
all, it changes the following pattern (ie: sems):
- ipc_rcu_putref(sma);
+ ipc_rcu_putref(sma, ipc_rcu_free);
and
- security_sem_free(sma);
- ipc_rcu_putref(sma);
+ ipc_rcu_putref(sma, sem_rcu_free);
Note that for ipc/sem.c, it also gets rid of the useless sem_putref(),
which is a straight call to ipc_rcu_putref().
If taken, this should fix shm + msq + sem and I'll backport it to 3.11
for msq + sem and 3.10 for sems.
Thanks!
8<-
From: Davidlohr Bueso
Subject: [PATCH] ipc: fix race with LSMs
Currently, IPC mechanisms do security and auditing related checks under
RCU. However, since security modules can free the security structure, for
example, through selinux_[sem,msg_queue,shm]_free_security(), we can race
if the structure is freed before other tasks are done with it, creating a
use-after-free condition. Manfred illustrates this nicely, for instance with
shared mem and selinux:
--> do_shmat calls rcu_read_lock()
--> do_shmat calls shm_object_check().
Checks that the object is still valid - but doesn't acquire any locks.
Then it returns.
--> do_shmat calls security_shm_shmat (e.g. selinux_shm_shmat)
--> selinux_shm_shmat calls ipc_has_perm()
--> ipc_has_perm accesses ipc_perms->security
shm_close()
--> shm_close acquires rw_mutex & shm_lock
--> shm_close calls shm_destroy
--> shm_destroy calls security_shm_free (e.g. selinux_shm_free_security)
--> selinux_shm_free_security calls ipc_free_security(>shm_perm)
--> ipc_free_security calls kfree(ipc_perms->security)
This patch delays the freeing of the security structures after all RCU readers
are done. Furthermore it aligns the security life cycle with that of the rest of
IPC -
new binutils needed for arm in 3.12-rc1
During 3.12-rc, Will Deacon introduced code into arch/arm that requires binutils 2.22. Signed-off-by: Pavel Machek --- Or that changes should be reverted. I have updated my buildsystem on main machine, but ... it seems that debian-cross repository does not contain new enough bintuils for kernel now. We are talking 62cbbc42e0019aff6310259f275ae812463f8836 6af396a6b6c698eb3834184518fc9a59bc22c817 73a6fdc48bf52e93c26874dc8c0f0f8d5585a809 6abdd491698a27f7df04a32ca12cc453810e4396 diff --git a/Documentation/Changes b/Documentation/Changes index b175808..0f8deaf 100644 --- a/Documentation/Changes +++ b/Documentation/Changes @@ -23,7 +23,7 @@ you probably needn't concern yourself with isdn4k-utils. o Gnu C 3.2 # gcc --version o Gnu make 3.80# make --version -o binutils 2.12# ld -v +o binutils 2.22# ld -v o util-linux 2.10o # fdformat --version o module-init-tools 0.9.10 # depmod -V o e2fsprogs 1.41.4 # e2fsck -V -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation: Update x86_64/boot-options.txt
On 09/23/2013 02:36:57 PM, Richard Weinberger wrote: Removed obsolte parameters from boot-options.txt. Verified by grepping around in arch/x86/. Signed-off-by: Richard Weinberger Acked-by: Rob Landley And added it as patch #33 to my documentation todo heap. Now the merge window's worked its way through I should filter out the ones other people sent upstream and flush the queue. (Since everybody and their dog grabs documentation patches, forwarding 'em promptly just causes dupes, but it's about time to see what didn't already make it...) 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: [RFCv2 3/3] ARM: dts: N900: Add SSI information
Hi, On Mon, Sep 23, 2013 at 02:35:35PM -0600, Stephen Warren wrote: > On 09/15/2013 02:44 PM, Sebastian Reichel wrote: > > Add SSI device tree data for OMAP34xx and Nokia N900. > > What is an "SSI" device, ... Synchronous Serial Interface (SSI), which is an interface from the OMAP3 for modem connection. It's a legacy variant of High-speed Synchronous Serial Interface (HSI). This in turn is a standard from MIPI: http://www.mipi.org/specifications/high-speed-synchronous-serial-interface-hsi > > > diff --git a/Documentation/devicetree/bindings/hsi/omap_ssi.txt > > b/Documentation/devicetree/bindings/hsi/omap_ssi.txt > > ... and what is the "HSI" subsystem? A framework for HSI devices living in drivers/hsi. > > +OMAP SSI controller bindings > > + > > +Required properties: > > +- compatible: Should be set to the following value > > +ti,omap3-ssi (applicable to OMAP34xx devices) > > I think that'd be better phrased as: > > Should include "ti,omap3-ssi". > > The binding should not preclude other compatibel values being present > (e.g. a SoC-specific compatible value, to allow SoC-specific quirks to > be enabled later). Right. Will be fixed in the next RFC. > > +- ti,hwmods: Name of the hwmod associated to the controller, > > which > > + is "ssi". > > I don't think we should add any more of that, for new bindings. That basically means not adding new drivers until hwmod is completly removed, since no new drivers not using DT are accepted anymore. hwmod still holds some information, which are not yet mapped to DT. > > +- reg: Contains SSI register address range (base > > address and > > + length). > > +- reg-names: Contains the names of the address ranges. It's > > +expected, that "sys" and "gdd" address ranges are > > + provided. > > Why two entries in reg-names but only one in reg? > > I think it'd be better to write: > > reg-names:Contains the values "sys" and "gdd". > reg: Contains a register specifier for each entry in > reg-names. > > A similar re-ordering/-wording would apply to interrupts/interrupt-names. OK. Will be fixed in the next RFC. > > +- ranges Required as an empty node > > s/node/property/ > > Why must ranges be empty? As long as the content correctly represents > the bus setup, why does the content matter at all. How about: > > rangesRepresents the bus address mapping between the main > controller node and the child nodes below. OK. Will be fixed in the next RFC. > > +Each port is represented as a sub-node of the ti,omap3-ssi device. > > + > > +Required Port sub-node properties: > > +- compatible: Should be set to the following value > > +ti,omap3-ssi-port (applicable to OMAP34xx devices) > > Hmm. Is it really the case that there is 1 controller with n ports? Yes with n=2. > Are the ports really dependent upon some shared resource? Yes and runtime power management. > Couldn't the ports be represented as separate top-level SSI > controllers? Maybe with some phandles. The current layout is cleaner IMHO. The ports are part of the controller and actually most boards only use one of them. In the original driver only the controller hat platform data with memory areas called "port1_rx" etc. > > +- interrupts: Contains the interrupt information for the port. > > +- interrupt-names: Contains the names of the interrupts. It's expected, > > + that "mpu_irq0" and "mpu_irq1" are provided. > > What exactly are those interrupts? "MPU" sounds like an external > micro-controller/processor... > > > +- ti,ssi-cawake-gpio: Defines which GPIO pin is used to signify CAWAKE > > + events for the port. This is an optional board-specific > > + property. If it's missing the port will not be > > + enabled. > > That also sounds like something that's a higher-level protocol, rather > than whatever low-level transport "SSI" implements. Should this be part > of a child node that represents the device attached to the SSI controller? Both the interrupts and the cawake-gpio are used as irqs for starting data transfers. As far as I understand it none of them are specific to the attached device. NOTE: I do not have documentation for the chip. I just ported the old patch from Carlos Chinea (who developed the initial driver for Nokia) to the new kernel frameworks, since I want to use the modem of my Nokia N900. > Does the SSI controller (or its ports) not need any clocks, resets, > regulators, ...? The only other stuff needed is taken care of by hwmod, which can be seen in this patch: https://lkml.org/lkml/2013/9/15/97 As far as I understand it, this kind of information is not yet supported by DT on OMAP boards. On the other hand
Re: [PATCH 1/3] thermal: bcm281xx: Add thermal driver
On 23-09-2013 18:43, Wendy Ng wrote:
>
> On 9/23/2013 11:19 AM, Eduardo Valentin wrote:
>> On 23-09-2013 13:51, Wendy Ng wrote:
>>> This adds the support for reading out temperature from Broadcom bcm281xx
>>> SoCs.
>>>
>>> Signed-off-by: Wendy Ng
>>> Reviewed-by: Markus Mayer
>>> Reviewed-by: Christian Daudt
>>> ---
>>> .../bindings/thermal/bcm-kona-thermal.txt | 18 +++
>>> drivers/thermal/Kconfig| 10 ++
>>> drivers/thermal/Makefile |1 +
>>> drivers/thermal/bcm_thermal.c | 170
>>>
>>> 4 files changed, 199 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt
>>> create mode 100644 drivers/thermal/bcm_thermal.c
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt
>>> b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt
>>> new file mode 100644
>>> index 000..acca99e
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt
>>> @@ -0,0 +1,18 @@
>>> +* Broadcom Kona Thermal Management Unit
>>> +
>>> +This version is for the BCM281xx family of SoCs.
>>> +
>>> +Required properties:
>>> +- compatible : "brcm,bcm11351-thermal", "brcm,kona-thermal"
>>> +- reg : Address range of the thermal register
>>> +- thermal-name: this entry must be specified and it will be passed into
>>> +thermal_zone_device_register(). This name will also be reported
>>> under Hwmon
>>> +sysfs 'name' attribute.
>>> +
>>> +Example:
>>> +thermal@34008000 {
>>> +compatible = "brcm,bcm11351-thermal", "brcm,kona-thermal";
>>> +reg = <0x34008000 0x0024>;
>>> +thermal-name = "bcm_kona_therm";
>>> +status = "disabled";
>>> +};
>>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>>> index dbfc390..7f823f0 100644
>>> --- a/drivers/thermal/Kconfig
>>> +++ b/drivers/thermal/Kconfig
>>> @@ -134,6 +134,16 @@ config KIRKWOOD_THERMAL
>>> Support for the Kirkwood thermal sensor driver into the Linux
>>> thermal
>>> framework. Only kirkwood 88F6282 and 88F6283 have this sensor.
>>> +config BCM_THERMAL
>>> +tristate "Temperature sensor on Broadcom BCM281xx family of SoCs"
>>> +depends on ARCH_BCM
>>> +default y
>>> +help
>>> + If you say yes here you get support for TMU (Thermal Management
>>> + Unit) on Broadcom BCM281xx family of SoCs. This provides thermal
>>> + monitoring of CPU clusters, graphics, and SoC glue, but does not
>>> + include monitoring of charger temperature.
>>> +
>>> config DOVE_THERMAL
>>> tristate "Temperature sensor on Marvell Dove SoCs"
>>> depends on ARCH_DOVE
>>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
>>> index 584b363..3ea8c1c 100644
>>> --- a/drivers/thermal/Makefile
>>> +++ b/drivers/thermal/Makefile
>>> @@ -21,6 +21,7 @@ obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
>>> obj-$(CONFIG_RCAR_THERMAL)+= rcar_thermal.o
>>> obj-$(CONFIG_KIRKWOOD_THERMAL) += kirkwood_thermal.o
>>> obj-y+= samsung/
>>> +obj-$(CONFIG_BCM_THERMAL) += bcm_thermal.o
>>> obj-$(CONFIG_DOVE_THERMAL) += dove_thermal.o
>>> obj-$(CONFIG_DB8500_THERMAL)+= db8500_thermal.o
>>> obj-$(CONFIG_ARMADA_THERMAL)+= armada_thermal.o
>>> diff --git a/drivers/thermal/bcm_thermal.c
>>> b/drivers/thermal/bcm_thermal.c
>>> new file mode 100644
>>> index 000..131d3c4
>>> --- /dev/null
>>> +++ b/drivers/thermal/bcm_thermal.c
>>> @@ -0,0 +1,170 @@
>>> +/*
>>> + * Copyright 2013 Broadcom Corporation.
>>> + *
>>> + * 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 (the "GPL").
>>> + *
>>> + * 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.
>>> + *
>>> + * A copy of the GPL is available at
>>> http://www.broadcom.com/licenses/GPLv2.php,
>>> + * or by writing to the Free Software Foundation, Inc.,
>>> + * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
>>> + */
>>> +
>>> +/**
>>> +* Broadcom Thermal Management Unit - bcm_tmu
>>> +*/
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +/* From TMON Register Database */
>>> +#define TMON_TEMP_VAL_OFFSET0x001c
>>> +#define TMON_TEMP_VAL_TEMP_VAL_SHIFT0
>>> +#define TMON_TEMP_VAL_TEMP_VAL_MASK0x03ff
>>> +
>>> +/* Broadcom Thermal Zone Device Structure */
>>> +struct bcm_thermal_zone_priv {
>>> +char name[THERMAL_NAME_LENGTH];
>>> +void __iomem *base;
>>> +};
>>> +
>>> +/* Temperature conversion function for
Re: [PATCH] regulator: of_get_regulation_constraints: Use node name as fallback
On Mon, Sep 23, 2013 at 10:28:27PM +0200, Lars-Peter Clausen wrote: > On 09/23/2013 12:15 PM, Mark Brown wrote: > >On Sun, Sep 22, 2013 at 12:47:34PM +0200, Lars-Peter Clausen wrote: > >>If the "regulator-name" property is not present use the name of the > >>devicetree > >>node as a fallback. > >You're not supposed to use the node name for anything, the goal is that > >it's entirely ornamental noise. Which is a bit annoying but there we > >are. > Is this documented somewhere? I'd be interested in the rationale behind this. I have no idea, I've not seen any documentation but that doesn't mean there isn't any. My understanding is that the goal is to allow it to be freely used by the DT author without consequence, though as you can probably tell I'm not personally 100% behind this idea. signature.asc Description: Digital signature
Re: [PATCH 2/5] mfd: arizona: Add device tree binding for max_channels_clocked
On Mon, Sep 23, 2013 at 03:38:10PM -0600, Stephen Warren wrote: > On 09/23/2013 12:30 PM, Charles Keepax wrote: > > + - wlf,max-channels-clocked : The maximum number of channels to be > > clocked on > > +each AIF, useful for I2S systems with multiple data lines being > > mastered. > > +If specified three cells must supplied one for each AIF, specify zero > > for > > +AIFs that should be handled normally. > What determines the value of this property? Is it really a definition of > HW, or some kind of run-time configuration/limit? What goes into each of > the 3 cells? It's hardware, it's other devices wired in parallel on the bus that use the CODEC as a clock master. Personally I'd have this be set by the ASoC machine driver so it's invisible from a DT point of view, that's what it's really a property of. signature.asc Description: Digital signature
Re: [RESEND PATCH v5 1/4] mm/vmalloc: don't set area->caller twice
On Tue, 17 Sep 2013 07:29:41 +0800 Wanpeng Li wrote:
> >> to set it again in __vmalloc_area_node.
> >>
> >> Reviewed-by: Zhang Yanfei
> >> Signed-off-by: Wanpeng Li
> >> ---
> >> mm/vmalloc.c | 1 -
> >> 1 file changed, 1 deletion(-)
> >>
> >> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> >> index 1074543..d78d117 100644
> >> --- a/mm/vmalloc.c
> >> +++ b/mm/vmalloc.c
> >> @@ -1566,7 +1566,6 @@ static void *__vmalloc_area_node(struct vm_struct
> >> *area, gfp_t gfp_mask,
> >>pages = kmalloc_node(array_size, nested_gfp, node);
> >>}
> >>area->pages = pages;
> >> - area->caller = caller;
> >>if (!area->pages) {
> >>remove_vm_area(area->addr);
> >>kfree(area);
> >
> >Then, __vmalloc_area_node() no longer need "caller" argument. It can use
> >area->caller instead.
> >
>
> Thanks for pointing out, I will update it in next version.
I've seen so many versions of this patchset that my head has spun right
off. I'm not at all confident that I have the latest version and I'm
certainly not confident that I've kept up with the ack/nack trail.
So I think I'll drop everything and will await that "next version".
Please be careful to Cc everyone who was involved and that the
acked/reviewed-by paperwork is up to date.
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 v5 2/2] hwmon: (coretemp) Report power and energy consumption
On 09/23/2013 03:45 PM, Guenter Roeck wrote: On Mon, Sep 23, 2013 at 03:31:33PM -0700, Srinivas Pandruvada wrote: On 09/23/2013 01:34 PM, Guenter Roeck wrote: Supported by SandyBridge and newer CPUs. Cc: Fenghua Yu Signed-off-by: Guenter Roeck --- v5: Merged to 3.12-rc1 v4: Replaced INIT_DELAYED_WORK with INIT_DEFERRABLE_WORK v3: Added Cc: v2: Fix missing symbol error on i386 builds Dropped leftover pr_info from debugging I am inclined to drop this patch set, as I received neither test nor code review feedback even though the patch set has been out there for a long time. Also, I am concerned that it overlaps or even conflicts with the proposed Power Cap/RAPL driver (https://lkml.org/lkml/2013/9/19/260). Thought so. Have you thought about providing a hwmon bridge ? Thanks, Guenter Thanks, Srinivas -- 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] ADP1653 board code for Nokia RX-51
Hi! > > > > Right. So Tony, will you accept future patches for board files? > > > > > > Only fixes to board-*.c files please unless there's a _really_ > > > good reason to make things more complex with the platform data. > > > Let's not make the DT conversion any more complex than it > > > already is. > > > > > > Getting things working with DT for the devices is pretty trivial > > > in most cases. And we can also still initialize the legacy devices > > > using platform data the same way as earlier. > > > > Well... It was quite a struggle to get video working with device tree > > in 3.10, and now it is broken in 3.12-rc1, again. > > Hmm didn't Aaro reply that you just need to change the Kconfig > option for the panel to fix it? Aha, spam filters playing games :-(. Sorry about that. > > "Now, here, you see, it takes all the running you can do, to keep in > > the same place. If you want to get somewhere else, you must run at > > least twice as fast as that! " > > True at least for reading the mailing lists :) :-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger
* Sebastian Reichel [130923 13:55]: > On Mon, Sep 23, 2013 at 10:06:46PM +0200, Pali Rohár wrote: > > On Monday 23 September 2013 22:00:09 Sebastian Reichel wrote: > > > On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Rohár wrote: > > > > It is not as simple as it looks. This is reason why I > > > > submited this patch long time after I submited bq2415x > > > > driver. > > > > > > > > Problem is that for rx51 is needed specific function which > > > > connect to two drivers (bq2415x and isp1704) plus it call > > > > specific rx51 board functions. > > > > > > > > Something which cannot be in DT (unless DT support C/ASM > > > > code). > > > > > > mh could isp1704 driver expose the data via the regulator > > > framework? > > > > No, isp1704 is power supply driver and export data via power > > supply (sysfs) interface. It is not regulator but charger driver. > > well it does not charge the battery directly, but just provides a > power line with 5 Volt and a specified amount of current to the > system, doesn't it? > > From my POV this is a candiate for the regulator framework: > > https://www.kernel.org/doc/Documentation/power/regulator/overview.txt Yes I think we should be able handle that rail with the regulator framework. Regards, Tony -- 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] usb: LLVMLinux: Remove VLAIS from USB gadget
On 09/23/13 18:53, charl...@gmail.com wrote: From: Mark Charlebois The use of variable length arrays in structs (VLAIS) in the Linux Kernel code precludes the use of compilers which don't implement VLAIS (for instance the Clang compiler). This patch removes the use of VLAIS in the gadget driver. This version has been tested to compile cleanly. Signed-off-by: Mark Charlebois Signed-off-by: Behan Webster This is the fixed patch which was sent to Andrzej Pietrasiewicz. Behan -- Behan Webster beh...@converseincode.com -- 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] spi/tegra114: Correct support for cs_change
On Mon, Sep 23, 2013 at 2:14 PM, Stephen Warren wrote: > > That sounds broken. Normally, shouldn't CS assert before a transaction, > stay asserted during a transaction, then deassert after the transaction? > It shouldn't rise and fall very quickly in between parts of the transaction. That is normal, where a transaction is a spi_message made up of multiple spi_transfers. The cs_change bit for a transfer will insert a de-asserted pulse after a transfer or leave CS de-asserted after the last transfer. need to generate a falling-edge to trigger the beginning of a SPI transaction. Doing this write with the default value of SPI_COMMAND1 causes a brief rise and fall of CS, giving us our falling-edge. I wonder, is the real problem that the spi layer allows CS to possibly remain asserted between transactions to the same device? Normally you would expect it to be de-asserted at the end of a spi_message, but I believe the Linux spi semantics are that it may or may not actually be de-asserted at that time. It only guarantees that is will be de-asserted before a message to a different device starts. I guess this is supposed to be an optimization. Some drivers, like gpio bit-banging, probably have a cost associated with any CS change. Usually many messages in a row are to the same device. Most devices don't care if CS pulses between messages. Thus not pulsing CS between each message is faster. >> >> Otherwise, this logic allows us to skip the spi of COMMAND1 which would >> normally be used to create the falling edge to start a new transaction, >> leaving the previous one open for more transfers. > > This sounds like something the SPI core should be managing. If a driver > is using the SPI bus to communicate with a device in a way that needs CS > left active while outside a transaction, it shouldn't be possible for > another driver to come along and communicate with another device before > the first transaction is all complete. The bus should be locked. > Allowing anything else could corrupt the protocol that required specific > CS states outside the transaction. If the transaction is one message, which can be multiple transfers and multiple CS pulses, then the spi core always does it atomically. The limitation is the driver can't get the result of the transaction until the entire transaction is finished. If a driver needs to get part of a transaction to complete the rest, e.g. read a 16-bit length from the device and then read that many bytes, it can still be done. It doesn't seem to be documented in spi-summary, but the way to do this is with spi_bus_(un)lock() and spi_(a)sync_locked() calls. The driver must lock the bus, used the _locked versions to issue spi_messages, then unlock when done. This should prevent another device on the bus from getting a messages, and thus CS pulses, in the middle of the transaction. -- 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] kthread: Make kthread_create() killable.
On Mon, 16 Sep 2013 09:53:59 +0900 Tetsuo Handa
wrote:
> Subject: [PATCH v2] kthread: Make kthread_create() killable.
>
> Any users of wait_for_completion() might be chosen by the OOM killer while
> waiting for completion() call by some process which does memory allocation.
> kthread_create() is one of such users.
>
> When such users are chosen by the OOM killer when they are waiting for
> completion() in TASK_UNINTERRUPTIBLE, problem similar to CVE-2012-4398
> "kernel: request_module() OOM local DoS" can happen.
>
> This patch makes kthread_create() killable, using the same approach used for
> fixing CVE-2012-4398.
That's a pretty big patch. What's the status of this? Do you think
it's ready to go? Oleg?
I don't like the changelog much - it doesn't really describe the bug.
I can google "CVE-2012-4398" and that turns up a bunch of stuff but
it's more oriented toward sysadmins etc, rather than kernel developers.
Can we please have a conventional description? When the user does A,
the kernel does B because C, so we fix it via D?
From: Tetsuo Handa
Subject: kthread: make kthread_create() killable
Any users of wait_for_completion() might be chosen by the OOM killer while
waiting for completion() call by some process which does memory
allocation. kthread_create() is one of such users.
When such users are chosen by the OOM killer when they are waiting for
completion() in TASK_UNINTERRUPTIBLE, problem similar to CVE-2012-4398
"kernel: request_module() OOM local DoS" can happen.
This patch makes kthread_create() killable, using the same approach used for
fixing CVE-2012-4398.
Signed-off-by: Tetsuo Handa
Signed-off-by: Andrew Morton
---
kernel/kthread.c | 73 +
1 file changed, 55 insertions(+), 18 deletions(-)
diff -puN kernel/kthread.c~kthread-make-kthread_create-killable kernel/kthread.c
--- a/kernel/kthread.c~kthread-make-kthread_create-killable
+++ a/kernel/kthread.c
@@ -33,7 +33,7 @@ struct kthread_create_info
/* Result passed back to kthread_create() from kthreadd. */
struct task_struct *result;
- struct completion done;
+ struct completion *done;
struct list_head list;
};
@@ -178,6 +178,7 @@ static int kthread(void *_create)
struct kthread_create_info *create = _create;
int (*threadfn)(void *data) = create->threadfn;
void *data = create->data;
+ struct completion *done;
struct kthread self;
int ret;
@@ -187,10 +188,16 @@ static int kthread(void *_create)
init_completion();
current->vfork_done =
+ /* If user was SIGKILLed, I release the structure. */
+ done = xchg(>done, NULL);
+ if (!done) {
+ kfree(create);
+ do_exit(-EINTR);
+ }
/* OK, tell user we're spawned, wait for stop or wakeup */
__set_current_state(TASK_UNINTERRUPTIBLE);
create->result = current;
- complete(>done);
+ complete(done);
schedule();
ret = -EINTR;
@@ -223,8 +230,15 @@ static void create_kthread(struct kthrea
/* We want our own signal handler (we take no signals by default). */
pid = kernel_thread(kthread, create, CLONE_FS | CLONE_FILES | SIGCHLD);
if (pid < 0) {
+ /* If user was SIGKILLed, I release the structure. */
+ struct completion *done = xchg(>done, NULL);
+
+ if (!done) {
+ kfree(create);
+ return;
+ }
create->result = ERR_PTR(pid);
- complete(>done);
+ complete(done);
}
}
@@ -255,36 +269,59 @@ struct task_struct *kthread_create_on_no
const char namefmt[],
...)
{
- struct kthread_create_info create;
-
- create.threadfn = threadfn;
- create.data = data;
- create.node = node;
- init_completion();
+ DECLARE_COMPLETION_ONSTACK(done);
+ struct task_struct *task;
+ struct kthread_create_info *create = kmalloc(sizeof(*create),
+GFP_KERNEL);
+
+ if (!create)
+ return ERR_PTR(-ENOMEM);
+ create->threadfn = threadfn;
+ create->data = data;
+ create->node = node;
+ create->done =
spin_lock(_create_lock);
- list_add_tail(, _create_list);
+ list_add_tail(>list, _create_list);
spin_unlock(_create_lock);
wake_up_process(kthreadd_task);
- wait_for_completion();
-
- if (!IS_ERR(create.result)) {
+ /*
+* Wait for completion in killable state, for I might be chosen by
+* the OOM killer while kthreadd is trying to allocate memory for
+* new kernel thread.
+*/
+ if (unlikely(wait_for_completion_killable())) {
+ /*
+* If I was SIGKILLed
[PATCH 1/3] dma: edma: Split out PaRAM set calculations into its own function
PaRAM set calculation is abstracted into its own function to
enable better reuse for other DMA cases such as cyclic. We adapt
the Slave SG case to use the new function.
This provides a much cleaner abstraction to the internals of the
PaRAM set. However, any PaRAM attributes that are not common to
all DMA types must be set separately such as setting of interrupts.
This function takes care of the most-common attributes.
Also added comments clarifying A-sync case calculations.
Signed-off-by: Joel Fernandes
---
drivers/dma/edma.c | 198 ++---
1 file changed, 126 insertions(+), 72 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index ff50ff4..725b00c 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -250,6 +250,117 @@ static int edma_control(struct dma_chan *chan, enum
dma_ctrl_cmd cmd,
return ret;
}
+/*
+ * A PaRAM set configuration abstraction used by other modes
+ * @chan: Channel who's PaRAM set we're configuring
+ * @pset: PaRAM set to initialize and setup.
+ * @src_addr: Source address of the DMA
+ * @dst_addr: Destination address of the DMA
+ * @burst: In units of dev_width, how much to send
+ * @dev_width: How much is the dev_width
+ * @dma_length: Total length of the DMA transfer
+ * @direction: Direction of the transfer
+ */
+static int edma_config_pset(struct dma_chan *chan, struct edmacc_param *pset,
+ dma_addr_t src_addr, dma_addr_t dst_addr, u32 burst,
+ enum dma_slave_buswidth dev_width, unsigned int dma_length,
+ enum dma_transfer_direction direction)
+{
+ struct edma_chan *echan = to_edma_chan(chan);
+ struct device *dev = chan->device->dev;
+ int acnt, bcnt, ccnt, cidx;
+ int src_bidx, dst_bidx, src_cidx, dst_cidx;
+ int absync;
+
+ acnt = dev_width;
+ /*
+* If the maxburst is equal to the fifo width, use
+* A-synced transfers. This allows for large contiguous
+* buffer transfers using only one PaRAM set.
+*/
+ if (burst == 1) {
+ /*
+* For the A-sync case, bcnt and ccnt are the remainder
+* and quotient respectively of the division of:
+* (dma_length / acnt) by (SZ_64K -1). This is so
+* that in case bcnt over flows, we have ccnt to use.
+* Note: In A-sync tranfer only, bcntrld is used, but it
+* only applies for sg_dma_len(sg) >= SZ_64K.
+* In this case, the best way adopted is- bccnt for the
+* first frame will be the remainder below. Then for
+* every successive frame, bcnt will be SZ_64K-1. This
+* is assured as bcntrld = 0x in end of function.
+*/
+ absync = false;
+ ccnt = dma_length / acnt / (SZ_64K - 1);
+ bcnt = dma_length / acnt - ccnt * (SZ_64K - 1);
+ /*
+* If bcnt is non-zero, we have a remainder and hence an
+* extra frame to transfer, so increment ccnt.
+*/
+ if (bcnt)
+ ccnt++;
+ else
+ bcnt = SZ_64K - 1;
+ cidx = acnt;
+ } else {
+ /*
+* If maxburst is greater than the fifo address_width,
+* use AB-synced transfers where A count is the fifo
+* address_width and B count is the maxburst. In this
+* case, we are limited to transfers of C count frames
+* of (address_width * maxburst) where C count is limited
+* to SZ_64K-1. This places an upper bound on the length
+* of an SG segment that can be handled.
+*/
+ absync = true;
+ bcnt = burst;
+ ccnt = dma_length / (acnt * bcnt);
+ if (ccnt > (SZ_64K - 1)) {
+ dev_err(dev, "Exceeded max SG segment size\n");
+ return -EINVAL;
+ }
+ cidx = acnt * bcnt;
+ }
+
+ if (direction == DMA_MEM_TO_DEV) {
+ src_bidx = acnt;
+ src_cidx = cidx;
+ dst_bidx = 0;
+ dst_cidx = 0;
+ } else if (direction == DMA_DEV_TO_MEM) {
+ src_bidx = 0;
+ src_cidx = 0;
+ dst_bidx = acnt;
+ dst_cidx = cidx;
+ } else {
+ dev_err(dev, "%s: direction not implemented yet\n", __func__);
+ return -EINVAL;
+ }
+
+ pset->opt = EDMA_TCC(EDMA_CHAN_SLOT(echan->ch_num));
+ /* Configure A or AB synchronized transfers */
+ if (absync)
+ pset->opt |= SYNCDIM;
+
+ pset->src = src_addr;
+ pset->dst = dst_addr;
+
+ pset->src_dst_bidx = (dst_bidx << 16) | src_bidx;
+ pset->src_dst_cidx = (dst_cidx << 16) | src_cidx;
+
+
[PATCH 3/3] dma: edma: Increase maximum SG limit to 20
davinci-pcm uses 16 as the no.of periods. With this, in EDMA we have to allocate atleast 17 slots: 1 slot for channel, and 16 slots the periods. Due to this, the MAX_NR_SG limitation causes problems, set it to 20 to make cyclic DMA work when davinci-pcm is converted to use DMA Engine. Also add a comment clarifying this. Signed-off-by: Joel Fernandes --- drivers/dma/edma.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c index 9b63e1e..407b496 100644 --- a/drivers/dma/edma.c +++ b/drivers/dma/edma.c @@ -46,8 +46,14 @@ #define EDMA_CHANS 64 #endif /* CONFIG_ARCH_DAVINCI_DA8XX */ -/* Max of 16 segments per channel to conserve PaRAM slots */ -#define MAX_NR_SG 16 +/* + * Max of 20 segments per channel to conserve PaRAM slots + * Also note that MAX_NR_SG should be atleast the no.of periods + * that are required for ASoC, otherwise DMA prep calls will + * fail. Today davinci-pcm is the only user of this driver and + * requires atleast 17 slots, so we setup the default to 20. + */ +#define MAX_NR_SG 20 #define EDMA_MAX_SLOTS MAX_NR_SG #define EDMA_DESCRIPTORS 16 -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] dma: edma: Add support for Cyclic DMA
Using the PaRAM configuration function that we split for reuse by the
different DMA types, we implement Cyclic DMA support.
For the cyclic case, we pass different configuration parameters to this
function, and handle all the Cyclic-specific functionality separately.
Callbacks to the DMA users are handled using vchan_cyclic_callback in
the virt-dma layer. Linking is handled the same way as the slave SG case
except for the last slot where we link it back to the first one in a
cyclic fashion.
For continuity, we check for cases where no.of periods is great than the
MAX number of slots the driver can allocate for a particular descriptor
and error out on such cases.
Signed-off-by: Joel Fernandes
---
drivers/dma/edma.c | 159 ++---
1 file changed, 151 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 725b00c..9b63e1e 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -54,6 +54,7 @@
struct edma_desc {
struct virt_dma_descvdesc;
struct list_headnode;
+ int cyclic;
int absync;
int pset_nr;
int processed;
@@ -167,8 +168,13 @@ static void edma_execute(struct edma_chan *echan)
* then setup a link to the dummy slot, this results in all future
* events being absorbed and that's OK because we're done
*/
- if (edesc->processed == edesc->pset_nr)
- edma_link(echan->slot[nslots-1], echan->ecc->dummy_slot);
+ if (edesc->processed == edesc->pset_nr) {
+ if (edesc->cyclic)
+ edma_link(echan->slot[nslots-1], echan->slot[1]);
+ else
+ edma_link(echan->slot[nslots-1],
+ echan->ecc->dummy_slot);
+ }
edma_resume(echan->ch_num);
@@ -449,6 +455,138 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
return vchan_tx_prep(>vchan, >vdesc, tx_flags);
}
+static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
+ struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
+ size_t period_len, enum dma_transfer_direction direction,
+ unsigned long tx_flags, void *context)
+{
+ struct edma_chan *echan = to_edma_chan(chan);
+ struct device *dev = chan->device->dev;
+ struct edma_desc *edesc;
+ dma_addr_t src_addr, dst_addr;
+ enum dma_slave_buswidth dev_width;
+ u32 burst;
+ int i, ret, nr_periods;
+
+ if (unlikely(!echan || !buf_len || !period_len))
+ return NULL;
+
+ if (direction == DMA_DEV_TO_MEM) {
+ src_addr = echan->cfg.src_addr;
+ dst_addr = buf_addr;
+ dev_width = echan->cfg.src_addr_width;
+ burst = echan->cfg.src_maxburst;
+ } else if (direction == DMA_MEM_TO_DEV) {
+ src_addr = buf_addr;
+ dst_addr = echan->cfg.dst_addr;
+ dev_width = echan->cfg.dst_addr_width;
+ burst = echan->cfg.dst_maxburst;
+ } else {
+ dev_err(dev, "%s: bad direction?\n", __func__);
+ return NULL;
+ }
+
+ if (dev_width == DMA_SLAVE_BUSWIDTH_UNDEFINED) {
+ dev_err(dev, "Undefined slave buswidth\n");
+ return NULL;
+ }
+
+ if (unlikely(buf_len % period_len)) {
+ dev_err(dev, "Period should be multiple of Buffer length\n");
+ return NULL;
+ }
+
+ nr_periods = (buf_len / period_len) + 1;
+
+ /*
+* Cyclic DMA users such as audio cannot tolerate delays introduced
+* by cases where the number of periods is more than the maximum
+* number of SGs the EDMA driver can handle at a time. For DMA types
+* such as Slave SGs, such delays are tolerable and synchronized,
+* but the synchronization is difficult to achieve with Cyclic and
+* cannot be guaranteed, so we error out early.
+*/
+ if (nr_periods > MAX_NR_SG)
+ return NULL;
+
+ edesc = kzalloc(sizeof(*edesc) + nr_periods *
+ sizeof(edesc->pset[0]), GFP_ATOMIC);
+ if (!edesc) {
+ dev_dbg(dev, "Failed to allocate a descriptor\n");
+ return NULL;
+ }
+
+ edesc->cyclic = 1;
+ edesc->pset_nr = nr_periods;
+
+ dev_dbg(dev, "%s: nr_periods=%d\n", __func__, nr_periods);
+ dev_dbg(dev, "%s: period_len=%d\n", __func__, period_len);
+ dev_dbg(dev, "%s: buf_len=%d\n", __func__, buf_len);
+
+ for (i = 0; i < nr_periods; i++) {
+ /* Allocate a PaRAM slot, if needed */
+ if (echan->slot[i] < 0) {
+ echan->slot[i] =
+ edma_alloc_slot(EDMA_CTLR(echan->ch_num),
+
[PATCH 0/3] dma: edma: Add cyclic DMA support
The following series adds Cyclic DMA support to TI EDMA DMA Engine driver. First we split out the calculations for the Slave DMA case into a separate function so that we may reuse it for the calculations of Cyclic DMA parameters. Next patch then adds the actual support for Cyclic DMA, enables interrupts correctly and uses's the callbacks in virt-dma during interrupts thus signalling back to the ALSA layer that a period was transmitted. Some background on motivation for this series: Currently, only user of Cyclic DMA in EDMA is davinci-pcm driver. As of today, this driver directly calls into the EDMA private API (arch/arm/common/edma.c) without going through the DMAEngine. davinci-pcm in future will be modified to use DMA Engine framework for Cyclic DMA instead of directly using the Private API. However that's a much larger effort, involving dealing with ping-pong from SRAM on user's of the Davinci McASP, etc. As a first step, we add Cyclic DMA support to the EDMA driver so that this may be used when the actual conversion of davinci-pcm happens. Tested series along with couple of hacks to davinci-pcm to work with DMA Engine: g...@github.com:joelagnel/linux-kernel.git (branch dma/cyclic) Joel Fernandes (3): dma: edma: Split out PaRAM set calculations into its own function dma: edma: Add support for Cyclic DMA dma: edma: Increase maximum SG limit to 20 drivers/dma/edma.c | 350 + 1 file changed, 273 insertions(+), 77 deletions(-) -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 3.12-rc2
I really should have moved my release schedule back to Sunday - it got messed up by me releasing on Labor Day, and now it's been on Monday ever since. But hey, I didn't. So here it is, a full week later, the rc2 release. Things have been fairly quiet, probably because lots of people were traveling for LinuxCon and Linux Plumbers conference last week. So nothing very exciting stands out. It's mainly driver updates/fixes (gpu drivers stand out, but there's networking too, and smaller stuff all over). Apart from drivers there's arch updates (tile/arm/mips) and some filesystem noise (mainly btrfs). The shortlog is borderline too big to be really readable, but I'm appending it anyway. Linus --- Aaro Koskinen (6): staging: octeon-ethernet: make dropped packets to consume NAPI budget staging: octeon-ethernet: remove skb alloc failure warnings staging: octeon-ethernet: rgmii: enable interrupts that we can handle staging: octeon-ethernet: make dropped packets to consume NAPI budget staging: octeon-ethernet: remove skb alloc failure warnings staging: octeon-ethernet: rgmii: enable interrupts that we can handle Al Viro (3): autofs4: close the races around autofs4_notify_daemon() atomic_open: take care of EEXIST in no-open case with O_CREAT|O_EXCL in fs/namei.c 9p: don't forget to destroy inode cache if fscache registration fails Alan Stern (1): usb: gadget: fix a bug and a WARN_ON in dummy-hcd Alex Deucher (24): drm/radeon/cik: properly handle internal cp ints drm/radeon/si: properly handle internal cp ints drm/radeon/dce6/audio: make sure pin is valid before accessing it drm/radeon: add a connector property for audio drm/radeon: dpm updates for KV drm/radeon: protect concurrent smc register access with a spinlock drm/radeon: add spinlocks for indirect register accesss drm/radeon/cik: update gpu_init for an additional berlin gpu drm/radeon: add some additional berlin pci ids drm/radeon: fix typo in PG flags drm/radeon/r6xx: add a stubbed out set_uvd_clocks callback drm/radeon/dpm: fix fallback for empty UVD clocks drm/radeon/atom: workaround vbios bug in transmitter table on rs880 (v2) drm/radeon/dpm: handle bapm on trinity drm/radeon/dpm: handle bapm on kb/kv drm/radeon/dpm: add infrastructure to properly handle bapm drm/radeon/dpm: add bapm callback for trinity drm/radeon/dpm: add bapm callback for kb/kv drm/radeon/dpm/rs780: use drm_mode_vrefresh() drm/radeon/dpm/rs780: add some sanity checking to sclk scaling drm/radeon/dpm/rs780: don't enable sclk scaling if not required drm/radeon/dpm/rs780: fix force_performance state for same sclks drm/radeon/dpm: rework auto performance level enable drm/radeon: fix panel scaling with eDP and LVDS bridges Alexey Khoroshilov (3): rtl8187: fix use after free on failure path in rtl8187_init_urbs() net/irda/mcs7780: fix memory leaks in mcs_net_open() usb: gadget: mv_u3d_core: fix violation of locking discipline in mv_u3d_ep_disable() Anatol Pomozov (1): cfq: explicitly use 64bit divide operation for 64bit arguments Andrea Adami (1): ARM: sa1100: collie.c: fall back to jedec_probe flash detection Andrew Morton (1): drivers/staging/lustre/lustre/ptlrpc/sec_bulk.c: rename PTRS_PER_PAGE Andrzej Pietrasiewicz (1): usb: gadget: cdc2: fix conversion to new interface of f_ecm Andy Shevchenko (1): atm: nicstar: fix regression made by previous patch Anoop Thomas Mathew (1): ARM: OMAP4 SMP: Corrected a typo fucntions to functions Ansis Atteka (2): ip: use ip_hdr() in __ip_make_skb() to retrieve IP header ip: generate unique IP identificator if local fragmentation is allowed Anthoine Bourgeois (1): drm/radeon/dpm: implement force performance levels for rs780 (v2) Antonio Alecrim Jr (2): be2net: missing variable initialization isdn: hfcpci_softirq: get func return to suppress compiler warning Antonio Quartulli (1): batman-adv: set the TAG flag for the vid passed to BLA Arend van Spriel (1): brcmfmac: fix bus interface selection in Kconfig Arnaud Patard (1): ARM: imx51.dtsi: fix PATA device clock Aruna Balakrishnaiah (3): pstore: Adjust buffer size for compression for smaller registered buffers pstore: Use zlib_inflateInit2 instead of zlib_inflateInit pstore: Remove the messages related to compression failure Avinash Kumar (1): drivers: net: phy: cicada.c: clears warning Use #include instead of Ben Hutchings (6): sfc: Minimal support for 40G link speed sfc: Disable PTP on EF10 until we're ready to handle inline RX timestamps sfc: Reset derived rx_bad_bytes statistic when EF10 MC is rebooted sfc: Clean up validation of datapath capabilities sfc: Reinitialise and re-validate datapath caps after MC
