Re: [ 00/22] 3.0.57-stable review
Hi, LTP reports no new failed tests compared to 3.0.56 n. On Fri, Dec 14, 2012 at 02:25:45PM -0800, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.0.57 release. > There are 22 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Dec 16 22:16:57 UTC 2012. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.57-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > > - > Pseudo-Shortlog of commits: > > Greg Kroah-Hartman > Linux 3.0.57-rc1 > > Anton Blanchard > powerpc: Keep thread.dscr and thread.dscr_inherit in sync > > Anton Blanchard > powerpc: Update DSCR on all CPUs when writing sysfs dscr_default > > Dan Carpenter > ftrace: Clear bits properly in reset_iter_read() > > Sarah Sharp > xhci: Extend Fresco Logic MSI quirk. > > Alan Stern > USB: OHCI: workaround for hardware bug: retired TDs not added to the Done > Queue > > Zhang Rui > ACPI / video: ignore BIOS initial backlight value for HP Folio 13-2000 > > Rafael J. Wysocki > ACPI / PNP: Do not crash due to stale pointer use during system resume > > Kamil Iskra > ACPI / battery: Correct battery capacity values on Thinkpads > > Greg Kroah-Hartman > USB: mark uas driver as BROKEN > > Markus Becker > USB: cp210x: add Virtenio Preon32 device id > > Peter Korsgaard > usb: ftdi_sio: fixup BeagleBone A5+ quirk > > Martin Teichmann > USB: ftdi_sio: Add support for Newport AGILIS motor drivers > > Bjørn Mork > USB: option: blacklist network interface on Huawei E173 > > li.ru...@zte.com.cn > USB: add new zte 3g-dongle's pid to option.c > > Jan Beulich > x86: hpet: Fix masking of MSI interrupts > > Mel Gorman > tmpfs: fix shared mempolicy leak > > Dan Carpenter > telephony: ijx: buffer overflow in ixj_write_cid() > > Boris Ostrovsky > x86,AMD: Power driver support for AMD's family 16h processors > > Marek Szyprowski > mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls > > Tejun Heo > workqueue: convert BUG_ON()s in __queue_delayed_work() to WARN_ON_ONCE()s > > Benjamin Herrenschmidt > powerpc/ptrace: Fix build with gcc 4.6 > > Paul Walmsley > ARM: 7566/1: vfp: fix save and restore when running on pre-VFPv3 and > CONFIG_VFPv3 set > > > - > > Diffstat: > > Makefile | 4 +- > arch/arm/include/asm/hwcap.h | 3 +- > arch/arm/include/asm/vfpmacros.h | 12 +++--- > arch/arm/vfp/vfpmodule.c | 9 +++-- > arch/powerpc/kernel/ptrace.c | 18 +++-- > arch/powerpc/kernel/sysfs.c | 10 + > arch/powerpc/kernel/traps.c | 3 +- > arch/x86/kernel/hpet.c| 4 +- > drivers/acpi/battery.c| 77 > +++ > drivers/acpi/video.c | 14 +++ > drivers/hwmon/fam15h_power.c | 4 ++ > drivers/pnp/pnpacpi/core.c| 3 ++ > drivers/telephony/ixj.c | 24 ++-- > drivers/usb/host/ohci-q.c | 19 ++ > drivers/usb/host/xhci-pci.c | 7 +++- > drivers/usb/serial/cp210x.c | 1 + > drivers/usb/serial/ftdi_sio.c | 3 +- > drivers/usb/serial/ftdi_sio_ids.h | 6 +++ > drivers/usb/serial/option.c | 25 + > drivers/usb/storage/Kconfig | 2 +- > include/linux/mempolicy.h | 16 > kernel/trace/ftrace.c | 2 +- > kernel/workqueue.c| 4 +- > mm/dmapool.c | 31 > mm/mempolicy.c| 22 --- > mm/shmem.c| 22 ++- > 26 files changed, 236 insertions(+), 109 deletions(-) > > > -- > To unsubscribe from this list: send the line "unsubscribe stable" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- - Ing. Nikola CIPRICH LinuxBox.cz, s.r.o. 28. rijna 168, 709 00 Ostrava tel.: +420 591 166 214 fax:+420 596 621 273 mobil: +420 777 093 799 www.linuxbox.cz mobil servis: +420 737 238 656 email servis: ser...@linuxbox.cz - pgpNPnjZf8W9G.pgp Description: PGP signature
Re: [PATCH] fadvise: perform WILLNEED readahead in a workqueue
On Sun, Dec 16, 2012 at 03:15:49PM +1100, Dave Chinner wrote: > On Sun, Dec 16, 2012 at 03:35:49AM +, Eric Wong wrote: > > Dave Chinner wrote: > > > On Sun, Dec 16, 2012 at 12:25:49AM +, Eric Wong wrote: > > > > Alan Cox wrote: > > > > > On Sat, 15 Dec 2012 00:54:48 + > > > > > Eric Wong wrote: > > > > > > > > > > > Applications streaming large files may want to reduce disk spinups > > > > > > and > > > > > > I/O latency by performing large amounts of readahead up front > > > This could also be a use case for an audio/video player. > > Sure, but this can all be handled by a userspace application. If you > want to avoid/batch IO to enable longer spindown times, then you > have to load the file into RAM somewhere, and you don't need special > kernel support for that. > > > So no, there's no difference that matters between the approaches. > > But I think doing this in the kernel is easier for userspace users. > > The kernel provides mechanisms for applications to use. You have not > mentioned anything new that requires a new kernel mechanism to > acheive - you just need to have the knowledge to put the pieces > together properly. People have been solving this same problem for > the last 20 years without needing to tweak fadvise(). Or even having > an fadvise() syscall... > > Nothing about low latency IO or streaming IO is simple or easy, and > changing how readahead works doesn't change that fact. All it does > is change the behaviour of every other application that uses > fadvise() to minimise IO latency Hi Dave, I am wondering this patch might be a good idea to reduce the latency of fadvise() syscall itself. I do a really simple test in my desktop to measure the latency of fadvise syscall. Before applying this patch, fadvise syscall takes 32 microseconds. After applying the patch, it only takes 4 microseconds. (I was surprised that it takes a very long time!) Actually we observe a latency after using fadvise. But I don't find a proper time to look at this problem. So I guess this patch might be useful to reduce latency. Regards, - Zheng -- 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] mm: Downgrade mmap_sem before locking or populating on mmap
* Andy Lutomirski wrote:
> On Fri, Dec 14, 2012 at 6:49 AM, Al Viro wrote:
> > On Fri, Dec 14, 2012 at 03:14:50AM -0800, Andy Lutomirski wrote:
> >
> >> > Wait a minute. get_user_pages() relies on ->mmap_sem being held. Unless
> >> > I'm seriously misreading your patch it removes that protection. And yes,
> >> > I'm aware of execve-related exception; it's in special circumstances -
> >> > bprm->mm is guaranteed to be not shared (and we need to rearchitect that
> >> > area anyway, but that's a separate story).
> >>
> >> Unless I completely screwed up the patch, ->mmap_sem is still held for
> >> read (it's downgraded from write). It's just not held for write
> >> anymore.
> >
> > Huh? I'm talking about the call of get_user_pages() in aio_setup_ring().
> > With your patch it's done completely outside of ->mmap_sem, isn't it?
>
> Oh, /that/ call to get_user_pages. That would qualify as screwing up...
>
> Since dropping and reacquiring mmap_sem there is probably a
> bad idea there, I'll rework this and post a v2.
It probably does not matter much, as aio_setup() is an utter
slowpath, but I suspect you could still use the downgrading
variant of do_mmap_pgoff_unlock() here too:
int downgraded = 0;
...
down_write(&ctx->mm->mmap_sem);
/*
* XXX: If MCL_FUTURE is set, this will hold mmap_sem for write for
* longer than necessary.
*/
info->mmap_base = do_mmap_pgoff_helper(NULL, 0, info->mmap_size,
PROT_READ|PROT_WRITE,
MAP_ANONYMOUS|MAP_PRIVATE, 0,
&downgraded);
if (IS_ERR((void *)info->mmap_base)) {
up_read_write(&ctx->mm->mmap_sem, downgraded);
info->mmap_size = 0;
aio_free_ring(ctx);
return -EAGAIN;
}
dprintk("mmap address: 0x%08lx\n", info->mmap_base);
info->nr_pages = get_user_pages(current, ctx->mm,
info->mmap_base, nr_pages,
1, 0, info->ring_pages, NULL);
up_read_write(&ctx->mm->mmap_sem, downgraded);
Where up_read_write(lock, read) is a new primitive/wrapper that
does the up_read()/up_write() depending on the value of
'downgraded'.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/microcode] x86/microcode_intel_early.c: Early update ucode on Intel's CPU
On Sat, Dec 15, 2012 at 9:17 PM, Yinghai Lu wrote: > On Sat, Dec 15, 2012 at 6:09 PM, Yinghai Lu wrote: >> On Sat, Dec 15, 2012 at 1:40 PM, H. Peter Anvin wrote: >>> On 12/15/2012 12:55 PM, Yinghai Lu wrote: BTW, did you look at smp boot problem with early_level4_pgt version? >>> >>> >>> No, I have been busy with non-Linux stuff today. >>> >> >> ok, i sorted it out. I will split it to small pieces and post them. > > I updated for-x86-boot branch with it, and it is based on > linus:master > tip:x86/mm > tip:x86/urgent > tip:x86/mm2. > > also attach 7 new ones are just added to that branch. > just updated the branch to fix compiling problem that was found by Fengguang's kbuild test robot. git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-boot -- 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] mm: Downgrade mmap_sem before locking or populating on mmap
* Andy Lutomirski wrote:
> This is a serious cause of mmap_sem contention. MAP_POPULATE
> and MCL_FUTURE, in particular, are disastrous in multithreaded programs.
>
> Signed-off-by: Andy Lutomirski
> ---
>
> Changes from v1:
>
> The non-unlocking versions of do_mmap_pgoff and mmap_region are still
> available for aio_setup_ring's benefit. In theory, aio_setup_ring
> would do better with a lock-downgrading version, but that would be
> somewhat ugly and doesn't help my workload.
>
> arch/tile/mm/elf.c | 9 +++---
> fs/aio.c | 4 +++
> include/linux/mm.h | 19 ++--
> ipc/shm.c | 6 ++--
> mm/fremap.c| 10 --
> mm/mmap.c | 89
> --
> mm/util.c | 3 +-
> 7 files changed, 117 insertions(+), 23 deletions(-)
> +unsigned long mmap_region(struct file *file, unsigned long addr,
> + unsigned long len, unsigned long flags,
> + vm_flags_t vm_flags, unsigned long pgoff)
> +{
> + return mmap_region_helper(file, addr, len, flags, vm_flags, pgoff, 0);
> +}
> +
That 0 really wants to be NULL ...
Also, with your patch applied there's no user of mmap_region()
left anymore.
More fundamentally, while I agree with the optimization,
couldn't we de-uglify it a bit more?
In particular, instead of this wrappery:
> +unsigned long mmap_region_unlock(struct file *file, unsigned long addr,
> + unsigned long len, unsigned long flags,
> + vm_flags_t vm_flags, unsigned long pgoff)
> +{
> + int downgraded = 0;
> + unsigned long ret = mmap_region_helper(file, addr, len,
> + flags, vm_flags, pgoff, &downgraded);
> +
> + if (downgraded)
> + up_read(¤t->mm->mmap_sem);
> + else
> + up_write(¤t->mm->mmap_sem);
> +
> + return ret;
> +}
1)
We could at minimum wrap up the conditional unlocking as:
up_read_write(&mm->mmap_sem, read_locked);
With that I'd also suggest to rename 'downgraded' to
'read_locked', which more clearly expresses the locking state.
2)
More aggressively, we could just make it the _rule_ that the mm
lock gets downgraded to read in mmap_region_helper(), no matter
what.
>From a quick look I *think* all the usage sites (including
sys_aio_setup()) are fine with that unlocking - but I could be
wrong.
There's a couple of shorter codepaths that would now see an
extra op of downgrading:
down_write(&mm->mmap_sem);
...
downgrade_write(&mm->mmap_sem);
...
up_read(&mm->mmap_sem);
with not much work done with the lock read-locked - but I think
they are all fine and mostly affect error paths. So there's no
real value in keeping the conditional nature of the unlocking I
think.
That way all the usage sites could do a *much* cleaner pattern
of:
down_write(&mm->mmap_sem);
...
do_mmap_pgoff_downgrade_write(...);
...
up_read(&mm->mmap_sem);
... and that kind of cleanliness would instantly halve the size
of your patch, it would improve all use sites, and would turn
your patch into something I'd want to see applied straight away.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] Change IBS PMU to use perf_hw_context
* suravee.suthikulpa...@amd.com wrote: > From: Suravee Suthikulpanit > > Currently, the AMD IBS PMU initialize pmu.task_ctx_nr to > perf_invalid_context which only allows IBS to be running only > in system-wide mode (e.g. perf record -a). IBS hardware is > available in each core and should be per-context. This patch > modifies the task_ctx_nr to use the perf_hw_context (default) > instead. I'm wondering how extensively was it tested/verified that it's safe to enable IBS in per context mode as well, and that the profiling results are precise and accurate? We never used the IBS hardware in this fashion before, so some extra care is prudent - and traces of that extra care should be visible in the changelog as well. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] context_tracking: Add comments on interface and internals
* Frederic Weisbecker wrote:
> This subsystem lacks many explanations on its purpose and
> design. Add these missing comments.
>
> v2: Address comments from Andrew
>
> Reported-by: Andrew Morton
> Signed-off-by: Frederic Weisbecker
> Cc: Gilad Ben-Yossef
> Cc: Thomas Gleixner
> Cc: Andrew Morton
> Cc: Paul E. McKenney
> Cc: Ingo Molnar
> Cc: Steven Rostedt
> Cc: Peter Zijlstra
> Cc: Li Zhong
> ---
> kernel/context_tracking.c | 73 ++--
> 1 files changed, 63 insertions(+), 10 deletions(-)
>
> diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
> index e0e07fd..9f6c38f 100644
> --- a/kernel/context_tracking.c
> +++ b/kernel/context_tracking.c
> @@ -1,3 +1,19 @@
> +/*
> + * Context tracking: Probe on high level context boundaries such as kernel
> + * and userspace. This includes syscalls and exceptions entry/exit.
> + *
> + * This is used by RCU to remove its dependency on the timer tick while a CPU
> + * runs in userspace.
> + *
> + * Started by Frederic Weisbecker:
> + *
> + * Copyright (C) 2012 Red Hat, Inc., Frederic Weisbecker
>
> + *
> + * Many thanks to Gilad Ben-Yossef, Paul McKenney, Ingo Molnar, Andrew
> Morton,
> + * Steven Rostedt, Peter Zijlstra for suggestions and improvements.
> + *
> + */
> +
> #include
> #include
> #include
> @@ -6,8 +22,8 @@
>
> struct context_tracking {
> /*
> - * When active is false, hooks are not set to
> - * minimize overhead: TIF flags are cleared
> + * When active is false, hooks are unset in order
> + * to minimize overhead: TIF flags are cleared
>* and calls to user_enter/exit are ignored. This
>* may be further optimized using static keys.
>*/
> @@ -24,6 +40,15 @@ static DEFINE_PER_CPU(struct context_tracking,
> context_tracking) = {
> #endif
> };
>
> +/**
> + * user_enter - Inform the context tracking that the CPU is going to
> + * enter userspace mode.
> + *
> + * This function must be called right before we switch from the kernel
> + * to userspace, when it's guaranteed the remaining kernel instructions
> + * to execute won't use any RCU read side critical section because this
> + * function sets RCU in extended quiescent state.
> + */
> void user_enter(void)
> {
> unsigned long flags;
> @@ -39,40 +64,68 @@ void user_enter(void)
> if (in_interrupt())
> return;
>
> + /* Kernel threads aren't supposed to go to userspace */
> WARN_ON_ONCE(!current->mm);
>
> local_irq_save(flags);
> if (__this_cpu_read(context_tracking.active) &&
> __this_cpu_read(context_tracking.state) != IN_USER) {
> __this_cpu_write(context_tracking.state, IN_USER);
> + /*
> + * At this stage, only low level arch entry code remains and
> + * then we'll run in userspace. We can assume there won't be
> + * any RCU read-side critical section until the next call to
> + * user_exit() or rcu_irq_enter(). Let's remove RCU's dependency
> + * on the tick.
> + */
> rcu_user_enter();
> }
> local_irq_restore(flags);
> }
>
> +
> +/**
> + * user_exit - Inform the context tracking that the CPU is
> + * exiting userspace mode and entering the kernel.
> + *
> + * This function must be called after we entered the kernel from userspace
> + * before any use of RCU read side critical section. This potentially include
> + * any high level kernel code like syscalls, exceptions, signal handling,
> etc...
> + *
> + * This call supports re-entrancy. This way it can be called from any
> exception
> + * handler without needing to know if we came from userspace or not.
> + */
> void user_exit(void)
> {
> unsigned long flags;
>
> - /*
> - * Some contexts may involve an exception occuring in an irq,
> - * leading to that nesting:
> - * rcu_irq_enter() rcu_user_exit() rcu_user_exit() rcu_irq_exit()
> - * This would mess up the dyntick_nesting count though. And rcu_irq_*()
> - * helpers are enough to protect RCU uses inside the exception. So
> - * just return immediately if we detect we are in an IRQ.
> - */
> if (in_interrupt())
> return;
>
> local_irq_save(flags);
> if (__this_cpu_read(context_tracking.state) == IN_USER) {
> __this_cpu_write(context_tracking.state, IN_KERNEL);
> + /*
> + * We are going to run code that may use RCU. Inform
> + * RCU core about that (ie: we may need the tick again).
> + */
> rcu_user_exit();
> }
> local_irq_restore(flags);
> }
>
> +
> +/**
> + * context_tracking_task_switch - context switch the syscall hooks
> + *
> + * The context tracking uses the syscall slow path to implement its
> user-kernel
> + * boundaries hooks on syscalls. This way it doesn't impact t
Re: [ANNOUNCE] 3.7-ck1, BFS 426 for linux-3.7
On Sun, 16 Dec 2012 11:16:31 Con Kolivas wrote: > These are patches designed to improve system responsiveness and > interactivity with specific emphasis on the desktop, but suitable to > any commodity hardware workload. > > Apply to 3.7.x: > -ck-ckhttp://ck.kolivas.org/patches/3.0/3.7/3.71/patch-3.71.bz2 > or > -ck-ckhttp://ck.kolivas.org/patches/3.0/3.7/3.71/patch-3.71.lrz > > Broken out tarball: > -ck-ckhttp://ck.kolivas.org/patches/3.0/3.7/3.71/3.71-broken-out.tar.bz2 > or > -ck-ckhttp://ck.kolivas.org/patches/3.0/3.7/3.71/3.71-broken-out.tar.lrz > > Discrete patches: > -ckhttp://ck.kolivas.org/patches/3.0/3.7/3.71/patches/ > > Latest BFS by itself: > http://ck.kolivas.org/patches/bfs/3.0/3.7/3.7-sched-bfs-426.patch > > Web: > http://kernel.kolivas.org > > Code blog when I feel like it: > http://ck-hack.blogspot.com/ Of course these links all got scrambled somehow, but I'm sure you can figure out where the patches are :p -- -ck -- 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] m68k updates for 3.8
On Sat, Dec 15, 2012 at 1:09 PM, Greg Ungerer
wrote:
> On 12/15/2012 07:48 AM, Rob Landley wrote:
>> On 12/14/2012 06:04:51 AM, Greg Ungerer wrote:
>>> Hi Rob,
Somebody got one of my images to boot under aranym but they had to patch
the kernel fairly extensively to add the emulated device support that
emulator provided. It doesn't emulate real devices the way qemu does,
but qemu doesn't fully emulate the processor (just coldfire in
mainline)...
>>>
>>> I use aranym for testing m68k. Though I don't really pound to heavily
>>> on the devices. I really only cross-compile small systems for testing
>>> on it.
>>
>> What kernel config do you use for aranym? I don't see an an aranym entry
>> in
>> arch/m68k/configs, and I stopped using it precisely because it required
>> several large patches to add emulated device support for everything from
>> serial console to block devices. (There was a kernel upgrade, it broke,
>> I cut a release without it. Pretty much the same reason I stopped using
>> squashfs for a year or so until it finally got merged.)
>
> arch/m68k/configs/atari_defconfig
The normal defconfig (aka multi_defconfig) should also work.
> AranyM is an Atari emulator. As far as I know all the special device
> support has been merged into mainline now.
Indeed, as of v2.6.39.
Even without that support, an Atari kernel should work (albeit slower), except
for networking.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: [ANNOUNCE] 3.7-ck1, BFS 426 for linux-3.7
On Sun, 16 Dec 2012 18:33:14 Hillf Danton wrote: > On Sun, Dec 16, 2012 at 5:54 PM, Con Kolivas wrote: > > On Sun, 16 Dec 2012 11:16:31 Con Kolivas wrote: > >> These are patches designed to improve system responsiveness and > >> interactivity with specific emphasis on the desktop, but suitable to > >> any commodity hardware workload. > >> > >> Apply to 3.7.x: > >> -ck-ckhttp://ck.kolivas.org/patches/3.0/3.7/3.71/patch-3.71.bz2 > >> or > >> -ck-ckhttp://ck.kolivas.org/patches/3.0/3.7/3.71/patch-3.71.lrz > >> > >> Broken out tarball: > >> -ck-ckhttp://ck.kolivas.org/patches/3.0/3.7/3.71/3.71-broken-out.tar.bz2 > >> or > >> -ck-ckhttp://ck.kolivas.org/patches/3.0/3.7/3.71/3.71-broken-out.tar.lrz > >> > >> Discrete patches: > >> -ckhttp://ck.kolivas.org/patches/3.0/3.7/3.71/patches/ > >> > >> Latest BFS by itself: > >> http://ck.kolivas.org/patches/bfs/3.0/3.7/3.7-sched-bfs-426.patch > >> > >> Web: > >> http://kernel.kolivas.org > >> > >> Code blog when I feel like it: > >> http://ck-hack.blogspot.com/ > > > > Of course these links all got scrambled somehow, but I'm sure you can > > figure out where the patches are :p > > Better if changes after 425 are directly attached? > > Hillf That's of not much use without all the merging changes as well. The 425 patch for mainline 3.7 looks nothing like the 425 patch for 3.6. see my blog for details. Con -- -ck -- 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/9] tx/rx LED trigger support
Hi all, this is a resend of the patch series on tx/rx LEDs trigger. The patch set was put on hold after the latest discussions on Kurt's rename patch due to a missing feature in the LED subsystem, which has been just merged in: a8df7b1 leds: add led_trigger_rename function So, as months passed since the latest developments, I'm reposting the whole set, rebased on current mainline. The first patches are the same that were merged in can-next/led-trigger, but there was some (trivial) conflict in the rebase. As for the test, I've tried the patch on the current mainline kernel with my custom usb-can interface. For the drivers, I don't have any SoC-enabled board anymore, so they have only been compile tested. Cheers, Fabio Fabio Baltieri (7): can: add tx/rx LED trigger support can: flexcan: add LED trigger support can: at91_can: add LED trigger support can: ti_hecc: add LED trigger support can: c_can: add LED trigger support can: mcp251x: add LED trigger support can: sja1000: add LED trigger support Kurt Van Dijck (2): can: export a safe netdev_priv wrapper for candev can: rename LED trigger name on netdev renames drivers/net/can/Kconfig | 12 drivers/net/can/Makefile | 2 + drivers/net/can/at91_can.c| 10 +++ drivers/net/can/c_can/c_can.c | 10 +++ drivers/net/can/dev.c | 18 ++ drivers/net/can/flexcan.c | 11 drivers/net/can/led.c | 129 ++ drivers/net/can/mcp251x.c | 23 +-- drivers/net/can/sja1000/sja1000.c | 17 - drivers/net/can/ti_hecc.c | 10 +++ include/linux/can/dev.h | 11 include/linux/can/led.h | 51 +++ 12 files changed, 299 insertions(+), 5 deletions(-) create mode 100644 drivers/net/can/led.c create mode 100644 include/linux/can/led.h -- 1.7.12.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/9] can: add tx/rx LED trigger support
This patch implements the functions to add two LED triggers, named
-tx and -rx, to a canbus device driver.
Triggers are called from specific handlers by each CAN device driver and
can be disabled altogether with a Kconfig option.
The implementation keeps the LED on when the interface is UP and blinks
the LED on network activity at a configurable rate.
This only supports can-dev based drivers, as it uses some support field
in the can_priv structure.
Supported drivers should call devm_can_led_init() and can_led_event() as
needed.
Cleanup is handled automatically by devres, so no *_exit function is
needed.
Supported events are:
- CAN_LED_EVENT_OPEN: turn on tx/rx LEDs
- CAN_LED_EVENT_STOP: turn off tx/rx LEDs
- CAN_LED_EVENT_TX: trigger tx LED blink
- CAN_LED_EVENT_RX: trigger tx LED blink
Cc: Wolfgang Grandegger
Cc: Marc Kleine-Budde
Signed-off-by: Fabio Baltieri
Acked-by: Oliver Hartkopp
---
drivers/net/can/Kconfig | 12 +++
drivers/net/can/Makefile | 2 ++
drivers/net/can/led.c| 89
include/linux/can/dev.h | 8 +
include/linux/can/led.h | 42 +++
5 files changed, 153 insertions(+)
create mode 100644 drivers/net/can/led.c
create mode 100644 include/linux/can/led.h
diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
index b56bd9e..8e59120 100644
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@ -54,6 +54,18 @@ config CAN_CALC_BITTIMING
arguments "tq", "prop_seg", "phase_seg1", "phase_seg2" and "sjw".
If unsure, say Y.
+config CAN_LEDS
+ bool "Enable LED triggers for Netlink based drivers"
+ depends on CAN_DEV
+ depends on LEDS_CLASS
+ select LEDS_TRIGGERS
+ ---help---
+ This option adds two LED triggers for packet receive and transmit
+ events on each supported CAN device.
+
+ Say Y here if you are working on a system with led-class supported
+ LEDs and you want to use them as canbus activity indicators.
+
config CAN_AT91
tristate "Atmel AT91 onchip CAN controller"
depends on CAN_DEV && (ARCH_AT91SAM9263 || ARCH_AT91SAM9X5)
diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile
index 7de5986..c744039 100644
--- a/drivers/net/can/Makefile
+++ b/drivers/net/can/Makefile
@@ -8,6 +8,8 @@ obj-$(CONFIG_CAN_SLCAN) += slcan.o
obj-$(CONFIG_CAN_DEV) += can-dev.o
can-dev-y := dev.o
+can-dev-$(CONFIG_CAN_LEDS) += led.o
+
obj-y += usb/
obj-y += softing/
diff --git a/drivers/net/can/led.c b/drivers/net/can/led.c
new file mode 100644
index 000..eaa14ac
--- /dev/null
+++ b/drivers/net/can/led.c
@@ -0,0 +1,89 @@
+/*
+ * Copyright 2012, Fabio Baltieri
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+static unsigned long led_delay = 50;
+module_param(led_delay, ulong, 0644);
+MODULE_PARM_DESC(led_delay,
+ "blink delay time for activity leds (msecs, default: 50).");
+
+/*
+ * Trigger a LED event in response to a CAN device event
+ */
+void can_led_event(struct net_device *netdev, enum can_led_event event)
+{
+ struct can_priv *priv = netdev_priv(netdev);
+
+ switch (event) {
+ case CAN_LED_EVENT_OPEN:
+ led_trigger_event(priv->tx_led_trig, LED_FULL);
+ led_trigger_event(priv->rx_led_trig, LED_FULL);
+ break;
+ case CAN_LED_EVENT_STOP:
+ led_trigger_event(priv->tx_led_trig, LED_OFF);
+ led_trigger_event(priv->rx_led_trig, LED_OFF);
+ break;
+ case CAN_LED_EVENT_TX:
+ if (led_delay)
+ led_trigger_blink_oneshot(priv->tx_led_trig,
+ &led_delay, &led_delay, 1);
+ break;
+ case CAN_LED_EVENT_RX:
+ if (led_delay)
+ led_trigger_blink_oneshot(priv->rx_led_trig,
+ &led_delay, &led_delay, 1);
+ break;
+ }
+}
+EXPORT_SYMBOL_GPL(can_led_event);
+
+static void can_led_release(struct device *gendev, void *res)
+{
+ struct can_priv *priv = netdev_priv(to_net_dev(gendev));
+
+ led_trigger_unregister_simple(priv->tx_led_trig);
+ led_trigger_unregister_simple(priv->rx_led_trig);
+}
+
+/*
+ * Register CAN LED triggers for a CAN device
+ *
+ * This is normally called from a driver's probe function
+ */
+void devm_can_led_init(struct net_device *netdev)
+{
+ struct can_priv *priv = netdev_priv(netdev);
+ void *res;
+
+ res = devres_alloc(can_led_release, 0, GFP_KERNEL);
+ if (!res) {
+ netdev_err(netd
[PATCH 5/9] can: c_can: add LED trigger support
Add support for canbus activity led indicators on c_can devices by
calling appropriate can_led functions.
These are only enabled when CONFIG_CAN_LEDS is Y, becomes no-op
otherwise.
Cc: Bhupesh Sharma
Cc: AnilKumar Ch
Cc: Wolfgang Grandegger
Cc: Marc Kleine-Budde
Signed-off-by: Fabio Baltieri
---
drivers/net/can/c_can/c_can.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index 5233b8f..57eb1e7 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include "c_can.h"
@@ -477,6 +478,8 @@ static int c_can_read_msg_object(struct net_device *dev,
int iface, int ctrl)
stats->rx_packets++;
stats->rx_bytes += frame->can_dlc;
+ can_led_event(dev, CAN_LED_EVENT_RX);
+
return 0;
}
@@ -751,6 +754,7 @@ static void c_can_do_tx(struct net_device *dev)
C_CAN_IFACE(MSGCTRL_REG, 0))
& IF_MCONT_DLC_MASK;
stats->tx_packets++;
+ can_led_event(dev, CAN_LED_EVENT_TX);
c_can_inval_msg_object(dev, 0, msg_obj_no);
} else {
break;
@@ -1115,6 +1119,8 @@ static int c_can_open(struct net_device *dev)
napi_enable(&priv->napi);
+ can_led_event(dev, CAN_LED_EVENT_OPEN);
+
/* start the c_can controller */
c_can_start(dev);
@@ -1143,6 +1149,8 @@ static int c_can_close(struct net_device *dev)
c_can_reset_ram(priv, false);
c_can_pm_runtime_put_sync(priv);
+ can_led_event(dev, CAN_LED_EVENT_STOP);
+
return 0;
}
@@ -1268,6 +1276,8 @@ int register_c_can_dev(struct net_device *dev)
err = register_candev(dev);
if (err)
c_can_pm_runtime_disable(priv);
+ else
+ devm_can_led_init(dev);
return err;
}
--
1.7.12.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/9] can: export a safe netdev_priv wrapper for candev
From: Kurt Van Dijck
In net_device notifier calls, it was impossible to determine
if a CAN device is based on candev in a safe way.
This patch adds such test in order to access candev storage
from within those notifiers.
Signed-off-by: Kurt Van Dijck
Acked-by: Oliver Hartkopp
---
drivers/net/can/dev.c | 13 +
include/linux/can/dev.h | 3 +++
2 files changed, 16 insertions(+)
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 8233e5e..13e7380 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -794,6 +794,19 @@ void unregister_candev(struct net_device *dev)
}
EXPORT_SYMBOL_GPL(unregister_candev);
+/*
+ * Test if a network device is a candev based device
+ * and return the can_priv* if so.
+ */
+struct can_priv *safe_candev_priv(struct net_device *dev)
+{
+ if ((dev->type != ARPHRD_CAN) || (dev->rtnl_link_ops != &can_link_ops))
+ return NULL;
+
+ return netdev_priv(dev);
+}
+EXPORT_SYMBOL_GPL(safe_candev_priv);
+
static __init int can_dev_init(void)
{
int err;
diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
index 7747d9b..fb0ab65 100644
--- a/include/linux/can/dev.h
+++ b/include/linux/can/dev.h
@@ -106,6 +106,9 @@ u8 can_len2dlc(u8 len);
struct net_device *alloc_candev(int sizeof_priv, unsigned int echo_skb_max);
void free_candev(struct net_device *dev);
+/* a candev safe wrapper around netdev_priv */
+struct can_priv *safe_candev_priv(struct net_device *dev);
+
int open_candev(struct net_device *dev);
void close_candev(struct net_device *dev);
--
1.7.12.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 9/9] can: rename LED trigger name on netdev renames
From: Kurt Van Dijck
The LED trigger name for CAN devices is based on the initial
CAN device name, but does never change. The LED trigger name
is not guaranteed to be unique in case of hotplugging CAN devices.
This patch tries to address this problem by modifying the
LED trigger name according to the CAN device name when
the latter changes.
v1 - Kurt Van Dijck
v2 - Fabio Baltieri
- remove rename blocking if trigger is bound
- use led-subsystem function for the actual rename (still WiP)
- call init/exit functions from dev.c
v3 - Kurt Van Dijck
- safe operation for non-candev based devices (vcan, slcan)
based on earlier patch
v4 - Kurt Van Dijck
- trivial patch mistakes fixed
Signed-off-by: Kurt Van Dijck
Signed-off-by: Fabio Baltieri
---
drivers/net/can/dev.c | 5 +
drivers/net/can/led.c | 40
include/linux/can/led.h | 9 +
3 files changed, 54 insertions(+)
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 13e7380..6abc6e5 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#define MOD_DESC "CAN device driver interface"
@@ -811,6 +812,8 @@ static __init int can_dev_init(void)
{
int err;
+ can_led_notifier_init();
+
err = rtnl_link_register(&can_link_ops);
if (!err)
printk(KERN_INFO MOD_DESC "\n");
@@ -822,6 +825,8 @@ module_init(can_dev_init);
static __exit void can_dev_exit(void)
{
rtnl_link_unregister(&can_link_ops);
+
+ can_led_notifier_exit();
}
module_exit(can_dev_exit);
diff --git a/drivers/net/can/led.c b/drivers/net/can/led.c
index eaa14ac..227d359 100644
--- a/drivers/net/can/led.c
+++ b/drivers/net/can/led.c
@@ -1,5 +1,6 @@
/*
* Copyright 2012, Fabio Baltieri
+ * Copyright 2012, Kurt Van Dijck
*
* 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
@@ -87,3 +88,42 @@ void devm_can_led_init(struct net_device *netdev)
devres_add(&netdev->dev, res);
}
EXPORT_SYMBOL_GPL(devm_can_led_init);
+
+/*
+ * NETDEV rename notifier to rename the associated led triggers too
+ */
+static int can_led_notifier(struct notifier_block *nb, unsigned long msg,
+ void *data)
+{
+ struct net_device *netdev = data;
+ struct can_priv *priv = safe_candev_priv(netdev);
+ char name[CAN_LED_NAME_SZ];
+
+ if (!priv)
+ return NOTIFY_DONE;
+
+ if (msg == NETDEV_CHANGENAME) {
+ snprintf(name, sizeof(name), "%s-tx", netdev->name);
+ led_trigger_rename_static(name, priv->tx_led_trig);
+
+ snprintf(name, sizeof(name), "%s-rx", netdev->name);
+ led_trigger_rename_static(name, priv->rx_led_trig);
+ }
+
+ return NOTIFY_DONE;
+}
+
+/* notifier block for netdevice event */
+static struct notifier_block can_netdev_notifier __read_mostly = {
+ .notifier_call = can_led_notifier,
+};
+
+int __init can_led_notifier_init(void)
+{
+ return register_netdevice_notifier(&can_netdev_notifier);
+}
+
+void __exit can_led_notifier_exit(void)
+{
+ unregister_netdevice_notifier(&can_netdev_notifier);
+}
diff --git a/include/linux/can/led.h b/include/linux/can/led.h
index 12d5549..9c1167b 100644
--- a/include/linux/can/led.h
+++ b/include/linux/can/led.h
@@ -26,6 +26,8 @@ enum can_led_event {
void can_led_event(struct net_device *netdev, enum can_led_event event);
void devm_can_led_init(struct net_device *netdev);
+int __init can_led_notifier_init(void);
+void __exit can_led_notifier_exit(void);
#else
@@ -36,6 +38,13 @@ static inline void can_led_event(struct net_device *netdev,
static inline void devm_can_led_init(struct net_device *netdev)
{
}
+static inline int can_led_notifier_init(void)
+{
+ return 0;
+}
+static inline void can_led_notifier_exit(void)
+{
+}
#endif
--
1.7.12.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/9] can: sja1000: add LED trigger support
Add support for canbus activity led indicators on sja1000 devices by
calling appropriate can_led functions.
These are only enabled when CONFIG_CAN_LEDS is Y, becomes no-op
otherwise.
Cc: Oliver Hartkopp
Cc: Wolfgang Grandegger
Cc: Marc Kleine-Budde
Signed-off-by: Fabio Baltieri
---
drivers/net/can/sja1000/sja1000.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/net/can/sja1000/sja1000.c
b/drivers/net/can/sja1000/sja1000.c
index 83ee11e..daf4013 100644
--- a/drivers/net/can/sja1000/sja1000.c
+++ b/drivers/net/can/sja1000/sja1000.c
@@ -60,6 +60,7 @@
#include
#include
+#include
#include "sja1000.h"
@@ -368,6 +369,8 @@ static void sja1000_rx(struct net_device *dev)
stats->rx_packets++;
stats->rx_bytes += cf->can_dlc;
+
+ can_led_event(dev, CAN_LED_EVENT_RX);
}
static int sja1000_err(struct net_device *dev, uint8_t isrc, uint8_t status)
@@ -521,6 +524,7 @@ irqreturn_t sja1000_interrupt(int irq, void *dev_id)
can_get_echo_skb(dev, 0);
}
netif_wake_queue(dev);
+ can_led_event(dev, CAN_LED_EVENT_TX);
}
if (isrc & IRQ_RI) {
/* receive interrupt */
@@ -575,6 +579,8 @@ static int sja1000_open(struct net_device *dev)
/* init and start chi */
sja1000_start(dev);
+ can_led_event(dev, CAN_LED_EVENT_OPEN);
+
netif_start_queue(dev);
return 0;
@@ -592,6 +598,8 @@ static int sja1000_close(struct net_device *dev)
close_candev(dev);
+ can_led_event(dev, CAN_LED_EVENT_STOP);
+
return 0;
}
@@ -639,6 +647,8 @@ static const struct net_device_ops sja1000_netdev_ops = {
int register_sja1000dev(struct net_device *dev)
{
+ int ret;
+
if (!sja1000_probe_chip(dev))
return -ENODEV;
@@ -648,7 +658,12 @@ int register_sja1000dev(struct net_device *dev)
set_reset_mode(dev);
chipset_init(dev);
- return register_candev(dev);
+ ret = register_candev(dev);
+
+ if (!ret)
+ devm_can_led_init(dev);
+
+ return ret;
}
EXPORT_SYMBOL_GPL(register_sja1000dev);
--
1.7.12.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/9] can: mcp251x: add LED trigger support
Add support for canbus activity led indicators on mcp251x devices by
calling appropriate can_led functions.
These are only enabled when CONFIG_CAN_LEDS is Y, becomes no-op
otherwise.
Cc: Christian Pellegrin
Cc: Wolfgang Grandegger
Cc: Marc Kleine-Budde
Signed-off-by: Fabio Baltieri
---
drivers/net/can/mcp251x.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/net/can/mcp251x.c b/drivers/net/can/mcp251x.c
index 5eaf47b..f32b9fc 100644
--- a/drivers/net/can/mcp251x.c
+++ b/drivers/net/can/mcp251x.c
@@ -60,6 +60,7 @@
#include
#include
+#include
#include
#include
#include
@@ -494,6 +495,9 @@ static void mcp251x_hw_rx(struct spi_device *spi, int
buf_idx)
priv->net->stats.rx_packets++;
priv->net->stats.rx_bytes += frame->can_dlc;
+
+ can_led_event(priv->net, CAN_LED_EVENT_RX);
+
netif_rx_ni(skb);
}
@@ -707,6 +711,8 @@ static int mcp251x_stop(struct net_device *net)
mutex_unlock(&priv->mcp_lock);
+ can_led_event(net, CAN_LED_EVENT_STOP);
+
return 0;
}
@@ -905,6 +911,7 @@ static irqreturn_t mcp251x_can_ist(int irq, void *dev_id)
if (intf & CANINTF_TX) {
net->stats.tx_packets++;
net->stats.tx_bytes += priv->tx_len - 1;
+ can_led_event(net, CAN_LED_EVENT_TX);
if (priv->tx_len) {
can_get_echo_skb(net, 0);
priv->tx_len = 0;
@@ -968,6 +975,9 @@ static int mcp251x_open(struct net_device *net)
mcp251x_open_clean(net);
goto open_unlock;
}
+
+ can_led_event(net, CAN_LED_EVENT_OPEN);
+
netif_wake_queue(net);
open_unlock:
@@ -1077,10 +1087,15 @@ static int mcp251x_can_probe(struct spi_device *spi)
pdata->transceiver_enable(0);
ret = register_candev(net);
- if (!ret) {
- dev_info(&spi->dev, "probed\n");
- return ret;
- }
+ if (ret)
+ goto error_probe;
+
+ devm_can_led_init(net);
+
+ dev_info(&spi->dev, "probed\n");
+
+ return ret;
+
error_probe:
if (!mcp251x_enable_dma)
kfree(priv->spi_rx_buf);
--
1.7.12.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/9] can: flexcan: add LED trigger support
Add support for canbus activity led indicators on flexcan devices by
calling appropriate can_led_* functions.
These are only enabled when CONFIG_CAN_LEDS is Y, becomes no-op
otherwise.
Cc: Oliver Hartkopp
Cc: Wolfgang Grandegger
Cc: Marc Kleine-Budde
Signed-off-by: Fabio Baltieri
---
drivers/net/can/flexcan.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 0289a6d..769d29e 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -564,6 +565,8 @@ static int flexcan_read_frame(struct net_device *dev)
stats->rx_packets++;
stats->rx_bytes += cf->can_dlc;
+ can_led_event(dev, CAN_LED_EVENT_RX);
+
return 1;
}
@@ -652,6 +655,7 @@ static irqreturn_t flexcan_irq(int irq, void *dev_id)
if (reg_iflag1 & (1 << FLEXCAN_TX_BUF_ID)) {
stats->tx_bytes += can_get_echo_skb(dev, 0);
stats->tx_packets++;
+ can_led_event(dev, CAN_LED_EVENT_TX);
flexcan_write((1 << FLEXCAN_TX_BUF_ID), ®s->iflag1);
netif_wake_queue(dev);
}
@@ -865,6 +869,9 @@ static int flexcan_open(struct net_device *dev)
err = flexcan_chip_start(dev);
if (err)
goto out_close;
+
+ can_led_event(dev, CAN_LED_EVENT_OPEN);
+
napi_enable(&priv->napi);
netif_start_queue(dev);
@@ -893,6 +900,8 @@ static int flexcan_close(struct net_device *dev)
close_candev(dev);
+ can_led_event(dev, CAN_LED_EVENT_STOP);
+
return 0;
}
@@ -1092,6 +1101,8 @@ static int flexcan_probe(struct platform_device *pdev)
goto failed_register;
}
+ devm_can_led_init(dev);
+
dev_info(&pdev->dev, "device registered (reg_base=%p, irq=%d)\n",
priv->base, dev->irq);
--
1.7.12.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/9] can: at91_can: add LED trigger support
Add support for canbus activity led indicators on at91_can devices by calling appropriate can_led functions. These are only enabled when CONFIG_CAN_LEDS is Y, becomes no-op otherwise. Cc: Wolfgang Grandegger Cc: Marc Kleine-Budde Signed-off-by: Fabio Baltieri --- drivers/net/can/at91_can.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/net/can/at91_can.c b/drivers/net/can/at91_can.c index 81baefd..44f3637 100644 --- a/drivers/net/can/at91_can.c +++ b/drivers/net/can/at91_can.c @@ -37,6 +37,7 @@ #include #include +#include #define AT91_MB_MASK(i)((1 << (i)) - 1) @@ -641,6 +642,8 @@ static void at91_read_msg(struct net_device *dev, unsigned int mb) stats->rx_packets++; stats->rx_bytes += cf->can_dlc; + + can_led_event(dev, CAN_LED_EVENT_RX); } /** @@ -875,6 +878,7 @@ static void at91_irq_tx(struct net_device *dev, u32 reg_sr) /* _NOTE_: subtract AT91_MB_TX_FIRST offset from mb! */ can_get_echo_skb(dev, mb - get_mb_tx_first(priv)); dev->stats.tx_packets++; + can_led_event(dev, CAN_LED_EVENT_TX); } } @@ -1128,6 +1132,8 @@ static int at91_open(struct net_device *dev) goto out_close; } + can_led_event(dev, CAN_LED_EVENT_OPEN); + /* start chip and queuing */ at91_chip_start(dev); napi_enable(&priv->napi); @@ -1159,6 +1165,8 @@ static int at91_close(struct net_device *dev) close_candev(dev); + can_led_event(dev, CAN_LED_EVENT_STOP); + return 0; } @@ -1321,6 +1329,8 @@ static int at91_can_probe(struct platform_device *pdev) goto exit_free; } + devm_can_led_init(dev); + dev_info(&pdev->dev, "device registered (reg_base=%p, irq=%d)\n", priv->reg_base, dev->irq); -- 1.7.12.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/9] can: ti_hecc: add LED trigger support
Add support for canbus activity led indicators on ti_hecc devices by calling appropriate can_led functions. These are only enabled when CONFIG_CAN_LEDS is Y, becomes no-op otherwise. Cc: Anant Gole Cc: Wolfgang Grandegger Cc: Marc Kleine-Budde Signed-off-by: Fabio Baltieri --- drivers/net/can/ti_hecc.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c index f898c63..f52a975 100644 --- a/drivers/net/can/ti_hecc.c +++ b/drivers/net/can/ti_hecc.c @@ -50,6 +50,7 @@ #include #include +#include #include #define DRV_NAME "ti_hecc" @@ -593,6 +594,7 @@ static int ti_hecc_rx_pkt(struct ti_hecc_priv *priv, int mbxno) spin_unlock_irqrestore(&priv->mbx_lock, flags); stats->rx_bytes += cf->can_dlc; + can_led_event(priv->ndev, CAN_LED_EVENT_RX); netif_receive_skb(skb); stats->rx_packets++; @@ -796,6 +798,7 @@ static irqreturn_t ti_hecc_interrupt(int irq, void *dev_id) stats->tx_bytes += hecc_read_mbx(priv, mbxno, HECC_CANMCF) & 0xF; stats->tx_packets++; + can_led_event(ndev, CAN_LED_EVENT_TX); can_get_echo_skb(ndev, mbxno); --priv->tx_tail; } @@ -851,6 +854,8 @@ static int ti_hecc_open(struct net_device *ndev) return err; } + can_led_event(ndev, CAN_LED_EVENT_OPEN); + ti_hecc_start(ndev); napi_enable(&priv->napi); netif_start_queue(ndev); @@ -869,6 +874,8 @@ static int ti_hecc_close(struct net_device *ndev) close_candev(ndev); ti_hecc_transceiver_switch(priv, 0); + can_led_event(ndev, CAN_LED_EVENT_STOP); + return 0; } @@ -961,6 +968,9 @@ static int ti_hecc_probe(struct platform_device *pdev) dev_err(&pdev->dev, "register_candev() failed\n"); goto probe_exit_clk; } + + devm_can_led_init(ndev); + dev_info(&pdev->dev, "device registered (reg_base=%p, irq=%u)\n", priv->base, (u32) ndev->irq); -- 1.7.12.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/6] iio: dac: ad5504: Don't set error code to voltage_uv
On 12/14/2012 12:06 PM, Axel Lin wrote: > regulator_get_voltage() may return negative error code. > Add error checking to avoid setting error code to voltage_uv. > > Signed-off-by: Axel Lin Axel, I would definitely have prefered a resend of the whole series rather than just the ones you have fixed up. I assumed Lars would have no objection to Acking these as well! Anyhow 1,2,6 from v1 and 3,4,5 from v2 added to fixes-togreg branch of iio.git. Thanks for all these! Jonathan > --- > v2: check if ret is negative value > drivers/iio/dac/ad5504.c |6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/iio/dac/ad5504.c b/drivers/iio/dac/ad5504.c > index 242bdc7..1e9a1f4 100644 > --- a/drivers/iio/dac/ad5504.c > +++ b/drivers/iio/dac/ad5504.c > @@ -296,7 +296,11 @@ static int __devinit ad5504_probe(struct spi_device *spi) > if (ret) > goto error_put_reg; > > - voltage_uv = regulator_get_voltage(reg); > + ret = regulator_get_voltage(reg); > + if (ret < 0) > + goto error_disable_reg; > + > + voltage_uv = ret; > } > > spi_set_drvdata(spi, indio_dev); > -- 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] iommu: moving initialization earlier
Alexey, On Thu, Dec 13, 2012 at 08:48:55AM -0700, Alex Williamson wrote: > Probably a good idea to CC the iommu list and maintainer... > > On Thu, 2012-12-13 at 17:28 +1100, Alexey Kardashevskiy wrote: > > Signed-off-by: Alexey Kardashevskiy Please resend the patch when the merge-window is closed. Thanks, Joerg -- 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/
[char-misc for 3.8] mei: avoid oops in watchdog unregister code path
With commit c7d3df3 "mei: use internal watchdog device registration
tracking" will crash the kernel on shutdown path on systems
where ME watchdog is not present.
Since the watchdog was never initialized in such case
the WDOG_UNREGISTERED bit is never set and the system
crashes on access to uninitialized variables down the path.
To solve the issue we query for NULL on watchdog driver driver_data
to check whether the device is registered. This is handled in the
driver and doesn't depend on watchdog core internals.
Cc: Borislav Petkov
Cc: Wanlong Gao
Signed-off-by: Jerry Snitselaar
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/wd.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/misc/mei/wd.c b/drivers/misc/mei/wd.c
index 636409f..9299a8c 100644
--- a/drivers/misc/mei/wd.c
+++ b/drivers/misc/mei/wd.c
@@ -370,7 +370,7 @@ void mei_watchdog_register(struct mei_device *dev)
void mei_watchdog_unregister(struct mei_device *dev)
{
- if (test_bit(WDOG_UNREGISTERED, &amt_wd_dev.status))
+ if (watchdog_get_drvdata(&amt_wd_dev) == NULL)
return;
watchdog_set_drvdata(&amt_wd_dev, NULL);
--
1.7.4.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: [regression] 3.7 ends in APIC panic
* Bernd Schubert wrote: > On 12/13/2012 01:16 PM, Bernd Schubert wrote: > >Hello, > > > > I just tried to boot 3.7 and it ends in an APIC panic. I > > tried to use the recommended "apic=debug", but that does not > > change anything in the output, at least not in the visible > > part. The last known kernel to boot was 3.5. If it matters I > > can try to boot 3.6. > > So linux-3.6 also boots. Any idea what is going on or do I > really need to bisect? Yeah, it's hard to tell based on that info alone - would be nice to send in a log/screen capture of the crash and of course bisecting would be useful as well, if the crash is deterministic. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] CLK: uninline clk_prepare_enable() and clk_disable_unprepare()
On 20 November 2012 14:52, Dmitry Torokhov wrote: > We'll need to invoke clk_disable_unprepare() via a pointer in our devm_* > conversion so let's uninline the pair. > > Signed-off-by: Dmitry Torokhov Mike, are you taking these patches? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] CLK: uninline clk_prepare_enable() and clk_disable_unprepare()
[Adding Linaro id of Mike] On 16 December 2012 17:10, Viresh Kumar wrote: > On 20 November 2012 14:52, Dmitry Torokhov wrote: >> We'll need to invoke clk_disable_unprepare() via a pointer in our devm_* >> conversion so let's uninline the pair. >> >> Signed-off-by: Dmitry Torokhov > > Mike, are you taking these patches? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] CLK: uninline clk_prepare_enable() and clk_disable_unprepare()
On Sun, Dec 16, 2012 at 05:10:36PM +0530, Viresh Kumar wrote: > On 20 November 2012 14:52, Dmitry Torokhov wrote: > > We'll need to invoke clk_disable_unprepare() via a pointer in our devm_* > > conversion so let's uninline the pair. > > > > Signed-off-by: Dmitry Torokhov > > Mike, are you taking these patches? And what about my comments, some of which you've failed to reply to? -- 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] subsystem: proc filesystem
Not, this permissions saved for all users for later, check please. Чтв 13 Дек 2012 20:22:10 +0400, Al Viro написал: > On Thu, Dec 13, 2012 at 05:15:44PM +0400, tux2...@front.ru wrote: > > > > > > This patch strengthens file permissions of pid record in proc filesystem. > > When pid and pidentry records created, his permissions strengthens by > > creator umask. > > > > NAK. "Creator" in this case means "whoever had done lookup first". -- 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] m68knommu arch updates for 3.8
Hi Linus,
Can you please pull the m68knommu git tree, for-next branch, at:
git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-next
This one has a major restructuring of the non-mmu 68000 support. It merges
all the related SoC types that use the original 68000 cpu core internally
so they can share the same core code. It also allows for supporting the
original stand alone 68000 cpu in its own right. There is also a
generalization of the clock support of the ColdFire parts, some merging of
common ColdFire code, and a couple of bug fixes as well.
Regards
Greg
The following changes since commit b69f0859dc8e633c5d8c06845811588fe17e68b3:
Linus Torvalds (1):
Linux 3.7-rc8
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-next
Greg Ungerer (15):
m68knommu: merge ColdFire 5249 and 525x definitions
m68knommu: make non-MMU page_to_virt() return a void *
m68k: fix unused variable warning in mempcy.c
m68knommu: add clock creation support macro for other ColdFire CPUs
m68knommu: add clock definitions for 5206 ColdFire CPU types
m68knommu: add clock definitions for 523x ColdFire CPU types
m68knommu: add clock definitions for 5249 ColdFire CPU types
m68knommu: add clock definitions for 525x ColdFire CPU types
m68knommu: add clock definitions for 5272 ColdFire CPU types
m68knommu: add clock definitions for 527x ColdFire CPU types
m68knommu: add clock definitions for 528x ColdFire CPU types
m68knommu: add clock definitions for 5307 ColdFire CPU types
m68knommu: add clock definitions for 5407 ColdFire CPU types
m68knommu: add clock definitions for 54xx ColdFire CPU types
m68knommu: modify clock code so it can be used by all ColdFire CPU types
Luis Alves (3):
m68knommu: platform code merge for 68000 core cpus
m68knommu: allow for configuration of true 68000 based systems
m68knommu: disable MC68000 cpu target when MMU is selected
arch/m68k/Kconfig.cpu |3 +-
arch/m68k/Makefile |6 +-
arch/m68k/include/asm/m5249sim.h | 269
arch/m68k/include/asm/m525xsim.h | 116 +-
arch/m68k/include/asm/mcfclk.h |9 +-
arch/m68k/include/asm/mcfsim.h |5 +-
arch/m68k/include/asm/page_no.h|2 +-
arch/m68k/lib/memcpy.c |3 +-
arch/m68k/platform/68000/Makefile | 18 ++
.../{68VZ328/bootlogo.h => 68000/bootlogo-vz.h}|0
arch/m68k/platform/{68328 => 68000}/bootlogo.h |0
arch/m68k/platform/{68328 => 68000}/entry.S|0
arch/m68k/platform/68000/head.S| 240 +
arch/m68k/platform/{68328 => 68000}/ints.c |2 +-
.../platform/{68328/config.c => 68000/m68328.c}|2 +-
.../{68EZ328/config.c => 68000/m68EZ328.c} |2 +-
.../{68VZ328/config.c => 68000/m68VZ328.c} |4 +-
arch/m68k/platform/{68328 => 68000}/romvec.S |2 +-
arch/m68k/platform/{68328 => 68000}/timers.c |2 +-
arch/m68k/platform/68328/Makefile | 21 --
arch/m68k/platform/68328/head-de2.S| 128 --
arch/m68k/platform/68328/head-pilot.S | 207 ---
arch/m68k/platform/68328/head-ram.S| 141 --
arch/m68k/platform/68328/head-rom.S| 105
arch/m68k/platform/68EZ328/Makefile|5 -
arch/m68k/platform/68VZ328/Makefile|5 -
arch/m68k/platform/coldfire/clk.c | 100 +++-
arch/m68k/platform/coldfire/intc-5249.c|8 +-
arch/m68k/platform/coldfire/m5206.c| 20 ++
arch/m68k/platform/coldfire/m523x.c| 28 ++
arch/m68k/platform/coldfire/m5249.c| 28 ++-
arch/m68k/platform/coldfire/m525x.c| 20 ++
arch/m68k/platform/coldfire/m5272.c| 26 ++
arch/m68k/platform/coldfire/m527x.c| 30 +++
arch/m68k/platform/coldfire/m528x.c| 28 ++
arch/m68k/platform/coldfire/m5307.c| 20 ++
arch/m68k/platform/coldfire/m5407.c| 20 ++
arch/m68k/platform/coldfire/m54xx.c| 26 ++
38 files changed, 680 insertions(+), 971 deletions(-)
delete mode 100644 arch/m68k/include/asm/m5249sim.h
create mode 100644 arch/m68k/platform/68000/Makefile
rename arch/m68k/platform/{68VZ328/bootlogo.h => 68000/bootlogo-vz.h} (100%)
rename arch/m68k/platform/{68328 => 68000}/bootlogo.h (100%)
rename arch/m68k/platform/{68328 => 68000}/entry.S (100%)
create mode 100644 arch/m68k/platform/68000/head.S
rename arch/m68k/platform/{68328 => 68000}/ints.c (98%)
rename arch/m68k/platform/{68328/config.c => 680
Re: [RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x
On Fri, Dec 14, 2012 at 09:59:11PM +0200, Terje Bergström wrote: > On 14.12.2012 18:21, Stephen Warren wrote: > > On 12/13/2012 11:09 PM, Terje Bergström wrote: > >> They want to get the global data by getting drvdata of their parent. > > > > There's no reason that /has/ to be so; they can get any information from > > wherever it is, rather than trying to require it to be somewhere it isn't. > > Exactly, this was also my solution. > > >> The dummy device is not their parent - host1x is. There's no > >> connection between the dummy and the real client devices. > > > > It's quite possible for the client devices to ask their actual parent > > (host1x) for the tegradrm struct device *, by calling a host1x API, and > > have host1x implement that API by returning the dummy/virtual device > > that it created. That should be just 1-2 lines of code to implement in > > host1x, plus maybe a couple more to correctly return -EPROBE_DEFERRED > > when appropriate. > > My solution was to just have one global, and an getter for the global. > Instead of drvdata, the pointer is retrieved with the getter. No need > for dummy device, or passing points between host1x and tegradrm. Okay, so we're back on the topic of using globals. I need to assert again that this is not an option. If we were to use globals, then we could just as well leave out the dummy device and just do all of that in the tegra-drm driver's initialization function. The whole point of all this is to link the host1x and it's particular tegra-drm instance. I will see if I can find the time to implement this in the existing driver, so that the host1x code that you want to remove registers the tegra-drm dummy device and the tegra-drm devices use the accessors as discussed previously to access host1x and the dummy device. Once that is implemented, removing the original host1x implementation should be much easier since you will only have to keep the dummy device instantiation along with the one or two accessor functions. Thierry pgpn4ytik4IqI.pgp Description: PGP signature
Re: [PATCH 2/3] CLK: uninline clk_prepare_enable() and clk_disable_unprepare()
On 16 December 2012 17:27, Russell King - ARM Linux wrote: > On Sun, Dec 16, 2012 at 05:10:36PM +0530, Viresh Kumar wrote: >> On 20 November 2012 14:52, Dmitry Torokhov wrote: >> > We'll need to invoke clk_disable_unprepare() via a pointer in our devm_* >> > conversion so let's uninline the pair. >> > >> > Signed-off-by: Dmitry Torokhov >> >> Mike, are you taking these patches? > > And what about my comments, some of which you've failed to reply to? Surprised!! I thought there was nothing missing after the last discussion i remember. Dmitry agreed to drop the first patch and all other looked fine, as nobody objected to them again. Yes, you did in the beginning but there were valid replies to them, on which you never objected. So, i thought its all good now. Can you point again to the issues still left ? -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: wlan-ng: Update get_tx_power()/set_tx_power() signature
In file included from drivers/staging/wlan-ng/p80211netdev.c:92:
drivers/staging/wlan-ng/cfg80211.c:735: warning: initialization from
incompatible pointer type
drivers/staging/wlan-ng/cfg80211.c:736: warning: initialization from
incompatible pointer type
Cfr. commit c8442118ad9cd05cfe3b993f058e70ab25b1009a ("cfg80211: allow per
interface TX power setting"), which added a new parameter.
Signed-off-by: Geert Uytterhoeven
---
drivers/staging/wlan-ng/cfg80211.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/wlan-ng/cfg80211.c
b/drivers/staging/wlan-ng/cfg80211.c
index 18c06a5..1d31eab 100644
--- a/drivers/staging/wlan-ng/cfg80211.c
+++ b/drivers/staging/wlan-ng/cfg80211.c
@@ -638,8 +638,8 @@ int prism2_leave_ibss(struct wiphy *wiphy, struct
net_device *dev)
}
-int prism2_set_tx_power(struct wiphy *wiphy, enum nl80211_tx_power_setting
type,
- int mbm)
+int prism2_set_tx_power(struct wiphy *wiphy, struct wireless_dev *wdev,
+ enum nl80211_tx_power_setting type, int mbm)
{
struct prism2_wiphy_private *priv = wiphy_priv(wiphy);
wlandevice_t *wlandev = priv->wlandev;
@@ -665,7 +665,8 @@ exit:
return err;
}
-int prism2_get_tx_power(struct wiphy *wiphy, int *dbm)
+int prism2_get_tx_power(struct wiphy *wiphy, struct wireless_dev *wdev,
+ int *dbm)
{
struct prism2_wiphy_private *priv = wiphy_priv(wiphy);
wlandevice_t *wlandev = priv->wlandev;
--
1.7.0.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 v2] mm: Downgrade mmap_sem before locking or populating on mmap
On Fri, Dec 14, 2012 at 6:17 PM, Andy Lutomirski wrote: > This is a serious cause of mmap_sem contention. MAP_POPULATE > and MCL_FUTURE, in particular, are disastrous in multithreaded programs. > > Signed-off-by: Andy Lutomirski > --- > > Changes from v1: > > The non-unlocking versions of do_mmap_pgoff and mmap_region are still > available for aio_setup_ring's benefit. In theory, aio_setup_ring > would do better with a lock-downgrading version, but that would be > somewhat ugly and doesn't help my workload. Hi Andy, I agree that the long mmap_sem hold times when using MAP_POPULATE, MAP_LOCKED or MCL_FUTURE are a problem. However, I'm not entirely happy with your proposed solution. My main concern is that just downgrading the mmap_sem only hides the problem: as soon as a writer gets queued on that mmap_sem, reader/writer fairness kicks in and blocks any new readers, which makes the problem reappear. So in order to completely fix the issue, we should look for a way that doesn't require holding the mmap_sem (even in read mode) for the entire duration of the populate or mlock operation. I think this could be done by extending the mlock work I did as part of v2.6.38-rc1. The commit message for fed067da46ad3b9acedaf794a5f05d0bc153280b explains the idea; basically mlock() was split into do_mlock() which just sets the VM_LOCKED flag on vmas as needed, and do_mlock_pages() which goes through a range of addresses and actually populates/mlocks each individual page that is part of a VM_LOCKED vma. This could be easily extended for mlocks that happen in mmap_region() due to MAP_LOCKED or MCL_FUTURE: mmap_region() would just set the VM_LOCKED flag and defer the work of actually populating/mlocking the individual pages. I think the only constraint here is that the pages must be locked before returning to userspace, so we may be able to use the task_work mechanism to achieve that. Later on (but before returning to userspace) we would notice we have some mlock work to do and call do_mlock_pages() to achieve that. I think the benefits of this approach would be: - no mmap_sem locking changes around mmap_region() - which also means that all code paths to mmap_region() can instantly benefit - do_mlock_pages() doesn't need to hold a read lock on mmap_sem for the entire duration of the operation, so we can fully solve the problem instead of just making it harder to trigger Now for handling MAP_POPULATE, we would probably want to use a similar mechanism as well, so that we don't need to hold the mmap_sem for the entire duration of the populate. This is similar in principle to the MAP_LOCKED case; however this may require the introduction of a new VM_POPULATE vma flag in order to avoid the possibility of a race where someone replaces our vma with another before we get a chance to populate it. I don't have an implementation for this idea yet; however I'm hoping to come up with one before xmas. Before then, any comments on the idea ? -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] CLK: uninline clk_prepare_enable() and clk_disable_unprepare()
On Sun, Dec 16, 2012 at 05:50:44PM +0530, Viresh Kumar wrote: > On 16 December 2012 17:27, Russell King - ARM Linux > wrote: > > On Sun, Dec 16, 2012 at 05:10:36PM +0530, Viresh Kumar wrote: > >> On 20 November 2012 14:52, Dmitry Torokhov > >> wrote: > >> > We'll need to invoke clk_disable_unprepare() via a pointer in our devm_* > >> > conversion so let's uninline the pair. > >> > > >> > Signed-off-by: Dmitry Torokhov > >> > >> Mike, are you taking these patches? > > > > And what about my comments, some of which you've failed to reply to? > > Surprised!! I thought there was nothing missing after the last > discussion i remember. > Dmitry agreed to drop the first patch and all other looked fine, as > nobody objected > to them again. Yes, you did in the beginning but there were valid > replies to them, on > which you never objected. > > So, i thought its all good now. Can you point again to the issues still left ? Well, there's my comment against patch 2 which never got a reply: "Again, what about stuff not using drivers/clk/clk.c ?" Has this been addressed? -- 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] x86/uapi for 3.8
On Sat, 2012-12-15 at 17:35 +0100, Markus Trippelsdorf wrote:
> On 2012.12.15 at 17:33 +0100, Markus Trippelsdorf wrote:
> > On 2012.12.14 at 17:47 -0800, Linus Torvalds wrote:
> > > On Fri, Dec 14, 2012 at 5:41 PM, Linus Torvalds
> > > wrote:
> > > > I was wrong. It's not the x86 UAPI split, it's the DT pull. More people
> > > > added.
> > >
> > > Looking at the merge (just in case it could have done something odd),
> > > I'm starting to worry that this is some nasty heisenbug, and my
> > > bisection is not trustworthy at all. Because the DT pull sure as heck
> > > doesn't look like a likely candidate for anything either.
> > >
> > > Ho humm. Anybody else see anything strange?
> >
> > Yes. I'm seeing a BUG early during boot on my machine (RIP=NULL):
> >
> > BUG: unable to handle kernel NULL pointer dereference at (null)
> >
> > This is caused by:
> >
> > commit 53b87cf088e2ea68d7c59619d0214cc15bb76133
> > Author: Matt Fleming
> > Date: Fri Sep 7 18:23:51 2012 +0100
> >
> > x86, mm: Include the entire kernel memory map in trampoline_pgd
> >
> > There are various pieces of code in arch/x86 that require a page table
> > with an identity mapping. Make trampoline_pgd a proper kernel page
> > table, it currently only includes the kernel text and module space
> > mapping.
> >
> > One new feature of trampoline_pgd is that it now has mappings for the
> > physical I/O device addresses, which are inserted at ioremap()
> > time. Some broken implementations of EFI firmware require these
> > mappings to always be around.
> >
> > Acked-by: Jan Beulich
> > Signed-off-by: Matt Fleming
> >
>
> Adding Matt to CC.
Markus, could you please send me your full dmesg, or if possible the
dmesgs from both a working and non-working kernel.
After looking at your memory map layout, nothing immediately jumps out.
Could you try this revised patch and see if things work better? It's the
only thing I noticed that looked wrong with the original patch (apart
from the >512G ram bug that Yinghai pointed out).
---
>From dbc2a0bc1f3ea6c4df591e691916801e5aac85e3 Mon Sep 17 00:00:00 2001
From: Matt Fleming
Date: Fri, 7 Sep 2012 18:23:51 +0100
Subject: [PATCH] x86, mm: Include the entire kernel memory map in
trampoline_pgd
There are various pieces of code in arch/x86 that require a page table
with an identity mapping. Make trampoline_pgd a proper kernel page
table, it currently only includes the kernel text and module space
mapping.
One new feature of trampoline_pgd is that it now has mappings for the
physical I/O device addresses, which are inserted at ioremap()
time. Some broken implementations of EFI firmware require these
mappings to always be around.
Acked-by: Jan Beulich
Signed-off-by: Matt Fleming
---
v2: Ensure we update 'paddr' as we work our way through the pgtables.
arch/x86/mm/init_64.c| 9 +++-
arch/x86/mm/ioremap.c| 111 +++
arch/x86/realmode/init.c | 17 +++-
3 files changed, 134 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 2b6b4a3..fd4404f 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -108,13 +108,13 @@ void sync_global_pgds(unsigned long start, unsigned long
end)
for (address = start; address <= end; address += PGDIR_SIZE) {
const pgd_t *pgd_ref = pgd_offset_k(address);
struct page *page;
+ pgd_t *pgd;
if (pgd_none(*pgd_ref))
continue;
spin_lock(&pgd_lock);
list_for_each_entry(page, &pgd_list, lru) {
- pgd_t *pgd;
spinlock_t *pgt_lock;
pgd = (pgd_t *)page_address(page) + pgd_index(address);
@@ -130,6 +130,13 @@ void sync_global_pgds(unsigned long start, unsigned long
end)
spin_unlock(pgt_lock);
}
+
+ pgd = __va(real_mode_header->trampoline_pgd);
+ pgd += pgd_index(address);
+
+ if (pgd_none(*pgd))
+ set_pgd(pgd, *pgd_ref);
+
spin_unlock(&pgd_lock);
}
}
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 78fe3f1..353b64b 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -50,6 +50,113 @@ int ioremap_change_attr(unsigned long vaddr, unsigned long
size,
return err;
}
+#ifdef CONFIG_X86_64
+static void ident_pte_range(unsigned long paddr, unsigned long vaddr,
+ pmd_t *ppmd, pmd_t *vpmd, unsigned long end)
+{
+ pte_t *ppte = pte_offset_kernel(ppmd, paddr);
+ pte_t *vpte = pte_offset_kernel(vpmd, vaddr);
+
+ do {
+ set_pte(ppte, *vpte);
+ } while (ppte++, vpte++, vaddr += PAGE_SIZE, vaddr != end);
+}
+
+static int ident_pmd_range(unsigned long paddr, unsigned long vaddr,
+
Re: [PATCH] avoid entropy starvation due to stack protection
Am 16.12.2012 01:30, schrieb Theodore Ts'o: On Fri, Dec 14, 2012 at 06:36:41PM +0100, Stephan Mueller wrote: That patch is about one week from a mainline merge, btw. Initially I was also thinking about get_random_int. But stack protection depends on non-predictable numbers to ensure it cannot be defeated. As get_random_int depends on MD5 which is assumed to be broken now, I discarded the idea of using get_random_int. The original use of get_random_int() was for applications where the speed impact of using a heavierweight cryptographic primitive was not something which could be tolerated. However, the strength of get_random_int() is actually pretty good. Note that we never expose the full MD5 hash; we only export the first 32-bits of the hash. So even if you ignore the effects of: hash[0] += current->pid + jiffies + get_cycles(); I see that, but I consider that just getting some time stamps, where the interesting high-resolution time stamp is not guaranteed to exist, calculate a broken hash and take some parts of that hash as a random value does not sound very promising, even for stack protection. ... What I would do instead is use an AES-based cryptographic random number generator. That is, at boot time, grab enough randomness to for an AES key, and then use that key to create a cryptographic random number generator by encrypting a counter with said AES key. This is a cryptographic primitive which has been very carefully studied, and for architectures where you have a hardware support for AES (including ARMv8, Power 7, Sparc T4, as well as x86 processors with the AES-NI instructions), this will be much faster and require much less memory and CPU resources than replicating the /dev/urandom infrastructure. Well, we already have such an RNG in the kernel: the ansi_cprng out of the kernel crypto API. That RNG implements an ANSI X9.31 RNG with an AES core. Maybe that RNG should be given more centerstage where it is seeded with good entropy where the seed key and the seed is at least having each 256 bits of entropy? In this case we have a standard CSPRNG seeded with hardware-based entropy. Whether or not we really need this level of paranoia for hardening stack randomization I'll leave for someone else to decide. Personally, my philosophy is if someone has managed to get unprivileged shell acess, trying to protect against a privilege escalation attack is largely hopeless on most Linux systems. The name I would not concur with that statement because it would render all attempts to make the local system more secure irrelevant. ;-) But that is just my view. of the game is to protect against someone who does not yet have the ability to run arbitrary unprivileged code on the system of interest. In that case, the attacker isn't going to be able to get access to the output of get_random_int(), so even if there was a cryptographic weakness where an attacker who had access to the get_random_int() output stream could guess the internal state of the MD5-based RNG, in the case of a remote attacker, they wouldn't have access to the output of the RNG in the first place. Ciao Stephan -- 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] x86/uapi for 3.8
On Sat, 2012-12-15 at 15:37 -0800, Linus Torvalds wrote: > And why do we have to call the get-time calls so early? Couldn't we > move them later and avoid all the crazy "let's create silly magical > page tables just for the idiotic EFI problems". Unfortunately not, because this patch series fixes the case where some ASUS EFI machines ignore parts of the memory map that we invalidate with SetVirtualAddressMap() - so the firmware is accessing mappings for devices after we explicitly tell it they're no longer valid. It's possible to trigger this broken behaviour at whatever point we interact with the firmware. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] cpufreq: Manage only online cpus
On Sunday, December 16, 2012 11:20:08 AM Viresh Kumar wrote:
> cpufreq core doesn't manage offline cpus and if driver->init() has returned
> mask including offline cpus, it may result in unwanted behavior by cpufreq
> core
> or governors.
>
> We need to get only online cpus in this mask. There are two places to fix this
> mask, cpufreq core and cpufreq driver. It makes sense to do this at common
> place
> and hence is done in core.
Well, this series makes sense to me, but I'd like to hear what the other people
think.
Thanks,
Rafael
> Signed-off-by: Viresh Kumar
> ---
> drivers/cpufreq/cpufreq.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 1f93dbd..de99517 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -970,6 +970,13 @@ static int cpufreq_add_dev(struct device *dev, struct
> subsys_interface *sif)
> pr_debug("initialization failed\n");
> goto err_unlock_policy;
> }
> +
> + /*
> + * affected cpus must always be the one, which are online. We aren't
> + * managing offline cpus here.
> + */
> + cpumask_and(policy->cpus, policy->cpus, cpu_online_mask);
> +
> policy->user_policy.min = policy->min;
> policy->user_policy.max = policy->max;
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
BUG: unable to handle kernel NULL pointer dereference + panic on 3.2.11 (with various networking pointers, on Dell r720xd)
Hi, a server running 3.2.11 just crashed with rather lengthy (~3 MB) dump: http://www.virtall.com/files/temp/3.2.11-panic.txt Any pointers, info if it was fixed or not, appreciated. The server is Dell r720xd, 128 GB RAM, plenty of disks and around 1 Gbit/s constant traffic. # lspci 00:00.0 Host bridge: Intel Corporation Sandy Bridge DMI2 (rev 07) 00:01.0 PCI bridge: Intel Corporation Sandy Bridge IIO PCI Express Root Port 1a (rev 07) 00:01.1 PCI bridge: Intel Corporation Sandy Bridge IIO PCI Express Root Port 1b (rev 07) 00:02.0 PCI bridge: Intel Corporation Sandy Bridge IIO PCI Express Root Port 2a (rev 07) 00:02.2 PCI bridge: Intel Corporation Sandy Bridge IIO PCI Express Root Port 2c (rev 07) 00:03.0 PCI bridge: Intel Corporation Sandy Bridge IIO PCI Express Root Port 3a in PCI Express Mode (rev 07) 00:05.0 System peripheral: Intel Corporation Sandy Bridge Address Map, VTd_Misc, System Management (rev 07) 00:05.2 System peripheral: Intel Corporation Sandy Bridge Control Status and Global Errors (rev 07) 00:11.0 PCI bridge: Intel Corporation Patsburg PCI Express Virtual Root Port (rev 05) 00:16.0 Communication controller: Intel Corporation X79 series chipset HECI Controller #2 (rev 05) 00:16.1 Communication controller: Intel Corporation X79 series chipset IDE-r Controller (rev 05) 00:1a.0 USB controller: Intel Corporation X79 series chipset USB2 Enhanced Host Controller #2 (rev 05) 00:1c.0 PCI bridge: Intel Corporation X79 series chipset PCI Express Root Port 1 (rev b5) 00:1c.7 PCI bridge: Intel Corporation X79 series chipset PCI Express Root Port 8 (rev b5) 00:1d.0 USB controller: Intel Corporation X79 series chipset USB2 Enhanced Host Controller #1 (rev 05) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a5) 00:1f.0 ISA bridge: Intel Corporation X79 series chipset LPC Controller (rev 05) 01:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet PCIe 01:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet PCIe 02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet PCIe 02:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet PCIe 03:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 2208 [Thunderbolt] (rev 01) 08:00.0 PCI bridge: Renesas Technology Corp. SH7757 PCIe Switch [PS] 09:00.0 PCI bridge: Renesas Technology Corp. SH7757 PCIe Switch [PS] 09:01.0 PCI bridge: Renesas Technology Corp. SH7757 PCIe Switch [PS] 0a:00.0 PCI bridge: Renesas Technology Corp. SH7757 PCIe-PCI Bridge [PPB] 0b:00.0 VGA compatible controller: Matrox Graphics, Inc. G200eR2 3f:08.0 System peripheral: Intel Corporation Sandy Bridge QPI Link 0 (rev 07) 3f:09.0 System peripheral: Intel Corporation Sandy Bridge QPI Link 1 (rev 07) 3f:0a.0 System peripheral: Intel Corporation Sandy Bridge Power Control Unit 0 (rev 07) 3f:0a.1 System peripheral: Intel Corporation Sandy Bridge Power Control Unit 1 (rev 07) 3f:0a.2 System peripheral: Intel Corporation Sandy Bridge Power Control Unit 2 (rev 07) 3f:0a.3 System peripheral: Intel Corporation Sandy Bridge Power Control Unit 3 (rev 07) 3f:0b.0 System peripheral: Intel Corporation Sandy Bridge Interrupt Control Registers (rev 07) 3f:0b.3 System peripheral: Intel Corporation Sandy Bridge Semaphore and Scratchpad Configuration Registers (rev 07) 3f:0c.0 System peripheral: Intel Corporation Sandy Bridge Unicast Register 0 (rev 07) 3f:0c.1 System peripheral: Intel Corporation Sandy Bridge Unicast Register 0 (rev 07) 3f:0c.2 System peripheral: Intel Corporation Sandy Bridge Unicast Register 0 (rev 07) 3f:0c.3 System peripheral: Intel Corporation Sandy Bridge Unicast Register 0 (rev 07) 3f:0c.6 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller System Address Decoder 0 (rev 07) 3f:0c.7 System peripheral: Intel Corporation Sandy Bridge System Address Decoder (rev 07) 3f:0d.0 System peripheral: Intel Corporation Sandy Bridge Unicast Register 0 (rev 07) 3f:0d.1 System peripheral: Intel Corporation Sandy Bridge Unicast Register 0 (rev 07) 3f:0d.2 System peripheral: Intel Corporation Sandy Bridge Unicast Register 0 (rev 07) 3f:0d.3 System peripheral: Intel Corporation Sandy Bridge Unicast Register 0 (rev 07) 3f:0d.6 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller System Address Decoder 1 (rev 07) 3f:0e.0 System peripheral: Intel Corporation Sandy Bridge Processor Home Agent (rev 07) 3f:0e.1 Performance counters: Intel Corporation Sandy Bridge Processor Home Agent Performance Monitoring (rev 07) 3f:0f.0 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller Registers (rev 07) 3f:0f.1 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller RAS Registers (rev 07) 3f:0f.2 System peripheral: Intel Corporation Sandy Bridge Integrated Memory Controller Target Address Decoder 0 (rev 07) 3f:0f.3 System peripheral: Intel Cor
Re: [PATCH 2/3] CLK: uninline clk_prepare_enable() and clk_disable_unprepare()
On 16 December 2012 18:10, Russell King - ARM Linux wrote: > Well, there's my comment against patch 2 which never got a reply: > > "Again, what about stuff not using drivers/clk/clk.c ?" > > Has this been addressed? Hmm.. I misread it and thought it is same as breaking other platforms because there are no dummy routines. But i was wrong :( So, the problem is, platform not using common-clock framework uses this routine, and they don't want it to be dummy but call prepare & enable.. Because Dmirty requires this one to be non-inline, either he can move these routines to drivers/clk/clk-devres.c (which would be wrong) or can add wrappers over them in clk-devres file. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] CLK: uninline clk_prepare_enable() and clk_disable_unprepare()
On Sun, Dec 16, 2012 at 06:35:24PM +0530, Viresh Kumar wrote: > On 16 December 2012 18:10, Russell King - ARM Linux > wrote: > > Well, there's my comment against patch 2 which never got a reply: > > > > "Again, what about stuff not using drivers/clk/clk.c ?" > > > > Has this been addressed? > > Hmm.. I misread it and thought it is same as breaking other platforms > because there are > no dummy routines. But i was wrong :( > > So, the problem is, platform not using common-clock framework uses > this routine, and they > don't want it to be dummy but call prepare & enable.. > > Because Dmirty requires this one to be non-inline, either he can move > these routines to > drivers/clk/clk-devres.c (which would be wrong) or can add wrappers > over them in clk-devres > file. The point of the inlines in linux/clk.h is so that people using the clk API have a way to transition to the new prepare+enable solution without having their drivers break. This patch series totally wrecks that by making clk_prepare() private to the common clock framework. All the time that it does that, it's totally and utterly unsuitable for going into mainline. Is that strong enough language that my point is properly heard? -- 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/
redefinition of devm_gpio_request
On current linus/HEAD, m68k allmodconfig gives:
drivers/gpio/devres.c:52: error: redefinition of ‘devm_gpio_request’
include/linux/gpio.h:99: error: previous definition of
‘devm_gpio_request’ was here
drivers/gpio/devres.c:82: error: redefinition of ‘devm_gpio_request_one’
include/linux/gpio.h:111: error: previous definition of
‘devm_gpio_request_one’ was here
drivers/gpio/devres.c:114: error: redefinition of ‘devm_gpio_free’
include/linux/gpio.h:129: error: previous definition of
‘devm_gpio_free’ was here
make[5]: *** [drivers/gpio/devres.o] Error 1
The !CONFIG_GENERIC_GPIO dummy definitions in include/linux/gpio.h conflict
with the real ones in drivers/gpio/devres.c.
Should devres.c really be compiled if !CONFIG_GENERIC_GPIO?
In 3.7, this doesn't show up as CONFIG_GPIOLIB is not enabled. I assume
it gets selected by some driver.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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] x86/uapi for 3.8
On 2012.12.16 at 12:43 +, Matt Fleming wrote: > On Sat, 2012-12-15 at 17:35 +0100, Markus Trippelsdorf wrote: > > On 2012.12.15 at 17:33 +0100, Markus Trippelsdorf wrote: > > > On 2012.12.14 at 17:47 -0800, Linus Torvalds wrote: > > > > On Fri, Dec 14, 2012 at 5:41 PM, Linus Torvalds > > > > wrote: > > > > > I was wrong. It's not the x86 UAPI split, it's the DT pull. More > > > > > people added. > > > > > > > > Looking at the merge (just in case it could have done something odd), > > > > I'm starting to worry that this is some nasty heisenbug, and my > > > > bisection is not trustworthy at all. Because the DT pull sure as heck > > > > doesn't look like a likely candidate for anything either. > > > > > > > > Ho humm. Anybody else see anything strange? > > > > > > Yes. I'm seeing a BUG early during boot on my machine (RIP=NULL): > > > > > > BUG: unable to handle kernel NULL pointer dereference at (null) > > > > > > This is caused by: > > > > > > commit 53b87cf088e2ea68d7c59619d0214cc15bb76133 > > > Author: Matt Fleming > > > Date: Fri Sep 7 18:23:51 2012 +0100 > > > > > > x86, mm: Include the entire kernel memory map in trampoline_pgd > > > > > > There are various pieces of code in arch/x86 that require a page table > > > with an identity mapping. Make trampoline_pgd a proper kernel page > > > table, it currently only includes the kernel text and module space > > > mapping. > > > > > > One new feature of trampoline_pgd is that it now has mappings for the > > > physical I/O device addresses, which are inserted at ioremap() > > > time. Some broken implementations of EFI firmware require these > > > mappings to always be around. > > > > > > Acked-by: Jan Beulich > > > Signed-off-by: Matt Fleming > > > > > > > Adding Matt to CC. > > Markus, could you please send me your full dmesg, or if possible the > dmesgs from both a working and non-working kernel. > > After looking at your memory map layout, nothing immediately jumps out. > > Could you try this revised patch and see if things work better? It's the > only thing I noticed that looked wrong with the original patch (apart > from the >512G ram bug that Yinghai pointed out). Matt, your patch fixes the problem for me. Thanks. -- Markus Linux version 3.7.0-08451-g2b83188-dirty (markus@x4) (gcc version 4.8.0 20121214 (experimental) (GCC) ) #143 SMP Sat Dec 15 22:34:34 CET 2012 Command line: root=PARTUUID=1E3384D0-CAE6-41BB-8CD6-4F640164EFD7 init=/sbin/minit fbcon=rotate:3 drm_kms_helper.poll=0 quiet KERNEL supported cpus: AMD AuthenticAMD e820: BIOS-provided physical RAM map: BIOS-e820: [mem 0x0100-0x0009fbff] usable BIOS-e820: [mem 0x0009fc00-0x0009] reserved BIOS-e820: [mem 0x000e6000-0x000f] reserved BIOS-e820: [mem 0x0010-0xdfe8] usable BIOS-e820: [mem 0xdfe9-0xdfea7fff] ACPI data BIOS-e820: [mem 0xdfea8000-0xdfec] ACPI NVS BIOS-e820: [mem 0xdfed-0xdfef] reserved BIOS-e820: [mem 0xfff0-0x] reserved BIOS-e820: [mem 0x0001-0x00021fff] usable NX (Execute Disable) protection: active DMI present. DMI: System manufacturer System Product Name/M4A78T-E, BIOS 350304/13/2011 e820: update [mem 0x-0x] usable ==> reserved e820: remove [mem 0x000a-0x000f] usable e820: last_pfn = 0x22 max_arch_pfn = 0x4 MTRR default type: uncachable MTRR fixed ranges enabled: 0-9 write-back A-E uncachable F-F write-protect MTRR variable ranges enabled: 0 base mask 8000 write-back 1 base 8000 mask C000 write-back 2 base C000 mask E000 write-back 3 base F000 mask F800 write-combining 4 disabled 5 disabled 6 disabled 7 disabled TOM2: 00022000 aka 8704M x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106 e820: last_pfn = 0xdfe90 max_arch_pfn = 0x4 initial memory mapped: [mem 0x-0x1fff] Base memory trampoline at [88099000] 99000 size 24576 Using GB pages for direct mapping init_memory_mapping: [mem 0x-0xdfe8] [mem 0x-0xbfff] page 1G [mem 0xc000-0xdfdf] page 2M [mem 0xdfe0-0xdfe8] page 4k kernel direct mapping tables up to 0xdfe8 @ [mem 0x1fffd000-0x1fff] init_memory_mapping: [mem 0x1-0x21fff] [mem 0x1-0x1] page 1G [mem 0x2-0x21fff] page 2M kernel direct mapping tables up to 0x21fff @ [mem 0xdfe8e000-0xdfe8] ACPI: RSDP 000fb880 00024 (v02 ACPIAM) ACPI: XSDT dfe90100 0005C (v01 041311 XSDT1656 20110413 MSFT 0097) ACPI: FACP dfe90290 000F4 (v03 041311 FACP1656 20110413 MSFT 0097) ACPI BIOS Bug: Warning: Optional FADT field Pm2ControlBlock has zero address or length: 0x00
[PATCH] ACPI / PM: Do not apply ACPI_SUCCESS() to acpi_bus_get_device() result
From: Rafael J. Wysocki Since the return value of acpi_bus_get_device() is not of type acpi_status, ACPI_SUCCESS() should not be used for checking its return value. Fix that. Signed-off-by: Rafael J. Wysocki --- drivers/acpi/device_pm.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) Index: linux/drivers/acpi/device_pm.c === --- linux.orig/drivers/acpi/device_pm.c +++ linux/drivers/acpi/device_pm.c @@ -358,8 +358,7 @@ static struct acpi_device *acpi_dev_pm_g acpi_handle handle = DEVICE_ACPI_HANDLE(dev); struct acpi_device *adev; - return handle && ACPI_SUCCESS(acpi_bus_get_device(handle, &adev)) ? - adev : NULL; + return handle && !acpi_bus_get_device(handle, &adev) ? adev : NULL; } /** -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] cpufreq: Manage only online cpus
On 16 December 2012 18:34, Rafael J. Wysocki wrote: > On Sunday, December 16, 2012 11:20:08 AM Viresh Kumar wrote: >> cpufreq core doesn't manage offline cpus and if driver->init() has returned >> mask including offline cpus, it may result in unwanted behavior by cpufreq >> core >> or governors. >> >> We need to get only online cpus in this mask. There are two places to fix >> this >> mask, cpufreq core and cpufreq driver. It makes sense to do this at common >> place >> and hence is done in core. > > Well, this series makes sense to me, but I'd like to hear what the other > people > think. That sounds great :) Some more information for others about how i reached to these issues is present here: https://lkml.org/lkml/2012/12/10/44 -- 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] ACPI: Drop the second argument of acpi_bus_scan()
From: Rafael J. Wysocki
After the removal of acpi_start_single_object() and acpi_bus_start()
the second argument of acpi_bus_scan() is not necessary any more,
so drop it and update acpi_bus_check_add() accordingly.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/scan.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
Index: linux/drivers/acpi/scan.c
===
--- linux.orig/drivers/acpi/scan.c
+++ linux/drivers/acpi/scan.c
@@ -1592,8 +1592,8 @@ static int acpi_bus_type_and_status(acpi
return 0;
}
-static acpi_status acpi_bus_check_add(acpi_handle handle, u32 lvl,
- void *context, void **return_value)
+static acpi_status acpi_bus_check_add(acpi_handle handle, u32 lvl_not_used,
+ void *not_used, void **return_value)
{
struct acpi_device *device = NULL;
int type;
@@ -1625,7 +1625,7 @@ static acpi_status acpi_bus_check_add(ac
if (!device)
return AE_CTRL_DEPTH;
- device->add_type = context ? ACPI_BUS_ADD_START : ACPI_BUS_ADD_MATCH;
+ device->add_type = ACPI_BUS_ADD_START;
out:
if (!*return_value)
@@ -1664,18 +1664,16 @@ static acpi_status acpi_bus_device_attac
return status;
}
-static int acpi_bus_scan(acpi_handle handle, bool start,
-struct acpi_device **child)
+static int acpi_bus_scan(acpi_handle handle, struct acpi_device **child)
{
void *device = NULL;
acpi_status status;
int ret = -ENODEV;
- status = acpi_bus_check_add(handle, 0, (void *)start, &device);
+ status = acpi_bus_check_add(handle, 0, NULL, &device);
if (ACPI_SUCCESS(status))
acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
- acpi_bus_check_add, NULL, (void *)start,
- &device);
+ acpi_bus_check_add, NULL, NULL, &device);
if (!device)
goto out;
@@ -1719,7 +1717,7 @@ int acpi_bus_add(acpi_handle handle, str
{
int err;
- err = acpi_bus_scan(handle, false, ret);
+ err = acpi_bus_scan(handle, ret);
if (err)
return err;
@@ -1825,7 +1823,7 @@ int __init acpi_scan_init(void)
/*
* Enumerate devices in the ACPI namespace.
*/
- result = acpi_bus_scan(ACPI_ROOT_OBJECT, true, &acpi_root);
+ result = acpi_bus_scan(ACPI_ROOT_OBJECT, &acpi_root);
if (!result)
result = acpi_bus_scan_fixed();
--
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] ACPI: Remove acpi_start_single_object() and acpi_bus_start()
From: Rafael J. Wysocki
The ACPI PCI root bridge driver was the only ACPI driver implementing
the .start() callback, which isn't used by any ACPI drivers any more
now.
For this reason, acpi_start_single_object() has no purpose any more,
so remove it and all references to it. Also remove
acpi_bus_start_device(), whose only purpose was to call
acpi_start_single_object().
Moreover, since after the removal of acpi_bus_start_device() the
only purpose of acpi_bus_start() remains to call
acpi_update_all_gpes(), move that into acpi_bus_add() and drop
acpi_bus_start() too, remove its header from acpi_bus.h and
update all of its former users accordingly.
This change was previously proposed in a different from by
Yinghai Lu.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/container.c | 16 +---
drivers/acpi/scan.c| 66 -
drivers/pci/hotplug/acpiphp_glue.c |4 --
drivers/pci/hotplug/sgi_hotplug.c |2 -
include/acpi/acpi_bus.h|1
5 files changed, 12 insertions(+), 77 deletions(-)
Index: linux/drivers/acpi/scan.c
===
--- linux.orig/drivers/acpi/scan.c
+++ linux/drivers/acpi/scan.c
@@ -612,7 +612,6 @@ static void acpi_device_remove_notify_ha
}
static int acpi_bus_driver_init(struct acpi_device *, struct acpi_driver *);
-static int acpi_start_single_object(struct acpi_device *);
static int acpi_device_probe(struct device * dev)
{
struct acpi_device *acpi_dev = to_acpi_device(dev);
@@ -621,9 +620,6 @@ static int acpi_device_probe(struct devi
ret = acpi_bus_driver_init(acpi_dev, acpi_drv);
if (!ret) {
- if (acpi_dev->add_type == ACPI_BUS_ADD_START)
- acpi_start_single_object(acpi_dev);
-
if (acpi_drv->ops.notify) {
ret = acpi_device_install_notify_handler(acpi_dev);
if (ret) {
@@ -802,24 +798,6 @@ acpi_bus_driver_init(struct acpi_device
return 0;
}
-static int acpi_start_single_object(struct acpi_device *device)
-{
- int result = 0;
- struct acpi_driver *driver;
-
-
- if (!(driver = device->driver))
- return 0;
-
- if (driver->ops.start) {
- result = driver->ops.start(device);
- if (result && driver->ops.remove)
- driver->ops.remove(device, ACPI_BUS_REMOVAL_NORMAL);
- }
-
- return result;
-}
-
/**
* acpi_bus_register_driver - register a driver with the ACPI bus
* @driver: driver being registered
@@ -1716,59 +1694,31 @@ static int acpi_bus_scan(acpi_handle han
}
/*
- * acpi_bus_add and acpi_bus_start
+ * acpi_bus_add
*
* scan a given ACPI tree and (probably recently hot-plugged)
- * create and add or starts found devices.
+ * create and add found devices.
*
* If no devices were found -ENODEV is returned which does not
* mean that this is a real error, there just have been no suitable
* ACPI objects in the table trunk from which the kernel could create
- * a device and add/start an appropriate driver.
+ * a device and add an appropriate driver.
*/
int
acpi_bus_add(struct acpi_device **child,
struct acpi_device *parent, acpi_handle handle, int type)
{
- return acpi_bus_scan(handle, false, child);
-}
-EXPORT_SYMBOL(acpi_bus_add);
-
-static acpi_status acpi_bus_start_device(acpi_handle handle, u32 lvl,
-void *not_used, void **ret_not_used)
-{
- struct acpi_device *device;
- unsigned long long sta_not_used;
- int type_not_used;
-
- /*
-* Ignore errors ignored by acpi_bus_check_add() to avoid terminating
-* namespace walks prematurely.
-*/
- if (acpi_bus_type_and_status(handle, &type_not_used, &sta_not_used))
- return AE_OK;
-
- if (acpi_bus_get_device(handle, &device))
- return AE_CTRL_DEPTH;
-
- return acpi_start_single_object(device);
-}
-
-int acpi_bus_start(struct acpi_device *device)
-{
- if (!device)
- return -EINVAL;
+ int err;
- if (ACPI_SUCCESS(acpi_start_single_object(device)))
- acpi_walk_namespace(ACPI_TYPE_ANY, device->handle,
- ACPI_UINT32_MAX, acpi_bus_start_device,
- NULL, NULL, NULL);
+ err = acpi_bus_scan(handle, false, child);
+ if (err)
+ return err;
acpi_update_all_gpes();
return 0;
}
-EXPORT_SYMBOL(acpi_bus_start);
+EXPORT_SYMBOL(acpi_bus_add);
int acpi_bus_trim(struct acpi_device *start, int rmdevice)
{
Index: linux/include/acpi/acpi_bus.h
===
--- linux.orig/include/acpi/acpi_bus.h
+++ linux/include/acpi/acpi_bus.h
@@ -402,7 +402,6 @@ int acpi_bus_add(struct acpi_device **ch
acpi_h
Re: [ 00/22] 3.0.57-stable review
At Fri, 14 Dec 2012 14:25:45 -0800, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.0.57 release. > There are 22 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Dec 16 22:16:57 UTC 2012. > Anything received after that time might be too late. This kernel can be built and boot without any problem. Building a kernel with this kernel also works fine. - Build Machine: debian wheezy x86_64 CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 memory: 8GB - Test machine: debian wheezy x86_64(KVM guest on the Build Machine) vCPU: x2 memory: 2GB I reviewed the following patches and it looks good to me. > Dan Carpenter > ftrace: Clear bits properly in reset_iter_read() > > Jan Beulich > x86: hpet: Fix masking of MSI interrupts > > Mel Gorman > tmpfs: fix shared mempolicy leak > > Marek Szyprowski > mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls > > Tejun Heo > workqueue: convert BUG_ON()s in __queue_delayed_work() to WARN_ON_ONCE()s Thanks, Satoru -- 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] ACPI: Make acpi_bus_scan() and acpi_bus_add() take only one argument
From: Rafael J. Wysocki
The callers of acpi_bus_add() usually assume that if it has
succeeded, then a struct acpi_device object has been attached to
the handle passed as the first argument. Unfortunately, however,
this assumption is wrong, because acpi_bus_scan(), and acpi_bus_add()
too as a result, may return a pointer to a different struct
acpi_device object on success (it may be an object corresponding to
one of the descendant ACPI nodes in the namespace scope below that
handle).
For this reason, the callers of acpi_bus_add() who care about
whether or not a struct acpi_device object has been created for
its first argument need to check that using acpi_bus_get_device()
anyway, so the second argument of acpi_bus_add() is not really
useful for them. The same observation applies to acpi_bus_scan()
executed directly from acpi_scan_init().
Therefore modify the relevant callers of acpi_bus_add() to check the
existence of the struct acpi_device in question with the help of
acpi_bus_get_device() and drop the no longer necessary second
argument of acpi_bus_add(). Accordingly, modify acpi_scan_init() to
use acpi_bus_get_device() to get acpi_root and drop the no longer
needed second argument of acpi_bus_scan().
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/acpi_memhotplug.c |7 +-
drivers/acpi/container.c |7 +-
drivers/acpi/dock.c|4 ++-
drivers/acpi/processor_driver.c|8 +--
drivers/acpi/scan.c| 38 ++---
drivers/pci/hotplug/acpiphp_glue.c | 19 ++
drivers/pci/hotplug/sgi_hotplug.c |3 --
include/acpi/acpi_bus.h|2 -
8 files changed, 45 insertions(+), 43 deletions(-)
Index: linux/drivers/acpi/scan.c
===
--- linux.orig/drivers/acpi/scan.c
+++ linux/drivers/acpi/scan.c
@@ -1663,37 +1663,27 @@ static acpi_status acpi_bus_device_attac
return status;
}
-static int acpi_bus_scan(acpi_handle handle, struct acpi_device **child)
+static int acpi_bus_scan(acpi_handle handle)
{
void *device = NULL;
- acpi_status status;
- int ret = -ENODEV;
- status = acpi_bus_check_add(handle, 0, NULL, &device);
- if (ACPI_SUCCESS(status))
+ if (ACPI_SUCCESS(acpi_bus_check_add(handle, 0, NULL, &device)))
acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
acpi_bus_check_add, NULL, NULL, &device);
if (!device)
- goto out;
+ return -ENODEV;
- ret = 0;
- status = acpi_bus_device_attach(handle, 0, NULL, NULL);
- if (ACPI_SUCCESS(status))
+ if (ACPI_SUCCESS(acpi_bus_device_attach(handle, 0, NULL, NULL)))
acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
acpi_bus_device_attach, NULL, NULL, NULL);
- out:
- if (child)
- *child = device;
-
- return ret;
+ return 0;
}
/**
* acpi_bus_add - Add ACPI device node objects in a given namespace scope.
* @handle: Root of the namespace scope to scan.
- * @ret: Location to store a return struct acpi_device pointer.
*
* Scan a given ACPI tree (probably recently hot-plugged) and create and add
* found devices.
@@ -1702,21 +1692,12 @@ static int acpi_bus_scan(acpi_handle han
* there has been a real error. There just have been no suitable ACPI objects
* in the table trunk from which the kernel could create a device and add an
* appropriate driver.
- *
- * If 0 is returned, the memory location pointed to by @ret will be populated
- * with a pointer to a struct acpi_device created while scanning the namespace.
- * If @handle corresponds to a device node, that will be a pointer to the
struct
- * acpi_device object corresponding to @handle. Otherwise, it will be a
pointer
- * to a struct acpi_device corresponding to one of its descendants.
- *
- * If an error code is returned, NULL will be stored in the memory location
- * pointed to by @ret.
*/
-int acpi_bus_add(acpi_handle handle, struct acpi_device **ret)
+int acpi_bus_add(acpi_handle handle)
{
int err;
- err = acpi_bus_scan(handle, ret);
+ err = acpi_bus_scan(handle);
if (err)
return err;
@@ -1820,8 +1801,11 @@ int __init acpi_scan_init(void)
/*
* Enumerate devices in the ACPI namespace.
*/
- result = acpi_bus_scan(ACPI_ROOT_OBJECT, &acpi_root);
+ result = acpi_bus_scan(ACPI_ROOT_OBJECT);
+ if (result)
+ return result;
+ result = acpi_bus_get_device(ACPI_ROOT_OBJECT, &acpi_root);
if (!result)
result = acpi_bus_scan_fixed();
Index: linux/include/acpi/acpi_bus.h
===
--- linux.orig/include/acpi/acpi_bus.h
+++ linux/include/acpi/acpi_bus.h
@@ -391,
[PATCH 5/6] ACPI: Replace ACPI device add_type field with a match_driver flag
From: Rafael J. Wysocki
After the removal of the second argument of acpi_bus_scan() there is
no difference between the ACPI_BUS_ADD_MATCH and ACPI_BUS_ADD_START
add types, so the add_type field in struct acpi_device may be
replaced with a single flag. Do that calling the flag match_driver.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/scan.c | 21 +
include/acpi/acpi_bus.h | 11 ++-
2 files changed, 11 insertions(+), 21 deletions(-)
Index: linux/drivers/acpi/scan.c
===
--- linux.orig/drivers/acpi/scan.c
+++ linux/drivers/acpi/scan.c
@@ -535,7 +535,7 @@ static int acpi_bus_match(struct device
struct acpi_device *acpi_dev = to_acpi_device(dev);
struct acpi_driver *acpi_drv = to_acpi_driver(drv);
- return acpi_dev->add_type >= ACPI_BUS_ADD_MATCH
+ return acpi_dev->flags.match_driver
&& !acpi_match_device_ids(acpi_dev, acpi_drv->ids);
}
@@ -1451,8 +1451,7 @@ static void acpi_hot_add_bind(struct acp
static int acpi_add_single_object(struct acpi_device **child,
acpi_handle handle, int type,
- unsigned long long sta,
- enum acpi_bus_add_type add_type)
+ unsigned long long sta, bool match_driver)
{
int result;
struct acpi_device *device;
@@ -1468,7 +1467,6 @@ static int acpi_add_single_object(struct
device->device_type = type;
device->handle = handle;
device->parent = acpi_bus_get_parent(handle);
- device->add_type = add_type;
STRUCT_TO_INT(device->status) = sta;
acpi_device_get_busid(device);
@@ -1519,9 +1517,10 @@ static int acpi_add_single_object(struct
if ((result = acpi_device_set_context(device)))
goto end;
+ device->flags.match_driver = match_driver;
result = acpi_device_register(device);
- if (device->add_type >= ACPI_BUS_ADD_MATCH)
+ if (device->flags.match_driver)
acpi_hot_add_bind(device);
end:
@@ -1550,7 +1549,7 @@ static void acpi_bus_add_power_resource(
acpi_bus_get_device(handle, &device);
if (!device)
acpi_add_single_object(&device, handle, ACPI_BUS_TYPE_POWER,
- ACPI_STA_DEFAULT, ACPI_BUS_ADD_START);
+ ACPI_STA_DEFAULT, true);
}
static int acpi_bus_type_and_status(acpi_handle handle, int *type,
@@ -1621,11 +1620,11 @@ static acpi_status acpi_bus_check_add(ac
return AE_CTRL_DEPTH;
}
- acpi_add_single_object(&device, handle, type, sta, ACPI_BUS_ADD_BASIC);
+ acpi_add_single_object(&device, handle, type, sta, false);
if (!device)
return AE_CTRL_DEPTH;
- device->add_type = ACPI_BUS_ADD_START;
+ device->flags.match_driver = true;
out:
if (!*return_value)
@@ -1792,16 +1791,14 @@ static int acpi_bus_scan_fixed(void)
if ((acpi_gbl_FADT.flags & ACPI_FADT_POWER_BUTTON) == 0) {
result = acpi_add_single_object(&device, NULL,
ACPI_BUS_TYPE_POWER_BUTTON,
- ACPI_STA_DEFAULT,
- ACPI_BUS_ADD_START);
+ ACPI_STA_DEFAULT, true);
device_init_wakeup(&device->dev, true);
}
if ((acpi_gbl_FADT.flags & ACPI_FADT_SLEEP_BUTTON) == 0) {
result = acpi_add_single_object(&device, NULL,
ACPI_BUS_TYPE_SLEEP_BUTTON,
- ACPI_STA_DEFAULT,
- ACPI_BUS_ADD_START);
+ ACPI_STA_DEFAULT, true);
}
return result;
Index: linux/include/acpi/acpi_bus.h
===
--- linux.orig/include/acpi/acpi_bus.h
+++ linux/include/acpi/acpi_bus.h
@@ -63,13 +63,6 @@ acpi_get_physical_device_location(acpi_h
#define ACPI_BUS_FILE_ROOT "acpi"
extern struct proc_dir_entry *acpi_root_dir;
-enum acpi_bus_add_type {
- ACPI_BUS_ADD_BASIC = 0,
- ACPI_BUS_ADD_MATCH,
- ACPI_BUS_ADD_START,
- ACPI_BUS_ADD_TYPE_COUNT
-};
-
enum acpi_bus_removal_type {
ACPI_BUS_REMOVAL_NORMAL = 0,
ACPI_BUS_REMOVAL_EJECT,
@@ -150,7 +143,8 @@ struct acpi_device_flags {
u32 power_manageable:1;
u32 performance_manageable:1;
u32 eject_pending:1;
- u32 reserved:24;
+ u32 match_driver:1;
+ u32 reserved:23;
};
/* File System */
@@ -285,7 +279,6 @@ struct acpi_device {
struct acpi_driver *driver;
void *driver_data;
struct device dev;
- enum acpi_b
[PATCH 0/6] ACPI: Simplify namespace scanning for devices
Hi All, This series is on top of the one I sent on Thursday: https://lkml.org/lkml/2012/12/13/632 It goes one step farther and makes some simplifications that become possible after applying that patchset. [1/6] Fold acpi_pci_root_start() into acpi_pci_root_add() [2/6] Remove acpi_start_single_object() and acpi_bus_start() [3/6] Remove the arguments of acpi_bus_add() that are not used [4/6] Drop the second argument of acpi_bus_scan() [5/6] Replace ACPI device add_type field with a match_driver flag [6/6] Make acpi_bus_scan() and acpi_bus_add() take only one argument It survives booting on Toshiba Portege R500 without any visible issues. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] ACPI / PCI: Fold acpi_pci_root_start() into acpi_pci_root_add()
From: Rafael J. Wysocki
Move the code from the ACPI PCI root bridge's .start() callback
routine, acpi_pci_root_start(), directly into acpi_pci_root_add()
and drop acpi_pci_root_start().
It is safe to do that, because it is now always guaranteed that
when struct pci_dev objects are created, their companion struct
acpi_device objects are already present, so it is not necessary to
wait for them to be created before calling pci_bus_add_devices().
This change was previously proposed in a different form by
Yinghai Lu.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/pci_root.c | 26 --
1 file changed, 8 insertions(+), 18 deletions(-)
Index: linux/drivers/acpi/pci_root.c
===
--- linux.orig/drivers/acpi/pci_root.c
+++ linux/drivers/acpi/pci_root.c
@@ -47,7 +47,6 @@ ACPI_MODULE_NAME("pci_root");
#define ACPI_PCI_ROOT_DEVICE_NAME "PCI Root Bridge"
static int acpi_pci_root_add(struct acpi_device *device);
static int acpi_pci_root_remove(struct acpi_device *device, int type);
-static int acpi_pci_root_start(struct acpi_device *device);
#define ACPI_PCIE_REQ_SUPPORT (OSC_EXT_PCI_CONFIG_SUPPORT \
| OSC_ACTIVE_STATE_PWR_SUPPORT \
@@ -67,7 +66,6 @@ static struct acpi_driver acpi_pci_root_
.ops = {
.add = acpi_pci_root_add,
.remove = acpi_pci_root_remove,
- .start = acpi_pci_root_start,
},
};
@@ -453,6 +451,7 @@ static int __devinit acpi_pci_root_add(s
struct acpi_pci_root *root;
acpi_handle handle;
struct acpi_device *child;
+ struct acpi_pci_driver *driver;
u32 flags, base_flags;
root = kzalloc(sizeof(struct acpi_pci_root), GFP_KERNEL);
@@ -628,6 +627,13 @@ static int __devinit acpi_pci_root_add(s
if (device->wakeup.flags.run_wake)
device_set_run_wake(root->bus->bridge, true);
+ mutex_lock(&acpi_pci_root_lock);
+ list_for_each_entry(driver, &acpi_pci_drivers, node)
+ if (driver->add)
+ driver->add(root);
+ mutex_unlock(&acpi_pci_root_lock);
+
+ pci_bus_add_devices(root->bus);
return 0;
out_del_root:
@@ -639,22 +645,6 @@ end:
return result;
}
-static int acpi_pci_root_start(struct acpi_device *device)
-{
- struct acpi_pci_root *root = acpi_driver_data(device);
- struct acpi_pci_driver *driver;
-
- mutex_lock(&acpi_pci_root_lock);
- list_for_each_entry(driver, &acpi_pci_drivers, node)
- if (driver->add)
- driver->add(root);
- mutex_unlock(&acpi_pci_root_lock);
-
- pci_bus_add_devices(root->bus);
-
- return 0;
-}
-
static int acpi_pci_root_remove(struct acpi_device *device, int type)
{
struct acpi_pci_root *root = acpi_driver_data(device);
--
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] ACPI: Remove the arguments of acpi_bus_add() that are not used
From: Rafael J. Wysocki
Notice that acpi_bus_add() uses only 2 of its 4 arguments and
redefine its header to match the body. Update all of its callers as
necessary and observe that this leads to quite a number of removed
lines of code (Linus will like that).
Add a kerneldoc comment documenting acpi_bus_add() and wonder how
its callers make wrong assumptions about the second argument (make
note to self to take care of that later).
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/acpi_memhotplug.c | 18 +-
drivers/acpi/container.c | 16 +---
drivers/acpi/dock.c| 13 ++---
drivers/acpi/processor_driver.c| 24 +---
drivers/acpi/scan.c| 34 +-
drivers/pci/hotplug/acpiphp_glue.c | 21 -
drivers/pci/hotplug/sgi_hotplug.c |3 +--
include/acpi/acpi_bus.h|3 +--
8 files changed, 32 insertions(+), 100 deletions(-)
Index: linux/drivers/acpi/scan.c
===
--- linux.orig/drivers/acpi/scan.c
+++ linux/drivers/acpi/scan.c
@@ -1693,25 +1693,33 @@ static int acpi_bus_scan(acpi_handle han
return ret;
}
-/*
- * acpi_bus_add
+/**
+ * acpi_bus_add - Add ACPI device node objects in a given namespace scope.
+ * @handle: Root of the namespace scope to scan.
+ * @ret: Location to store a return struct acpi_device pointer.
*
- * scan a given ACPI tree and (probably recently hot-plugged)
- * create and add found devices.
+ * Scan a given ACPI tree (probably recently hot-plugged) and create and add
+ * found devices.
*
- * If no devices were found -ENODEV is returned which does not
- * mean that this is a real error, there just have been no suitable
- * ACPI objects in the table trunk from which the kernel could create
- * a device and add an appropriate driver.
+ * If no devices were found, -ENODEV is returned, but it does not mean that
+ * there has been a real error. There just have been no suitable ACPI objects
+ * in the table trunk from which the kernel could create a device and add an
+ * appropriate driver.
+ *
+ * If 0 is returned, the memory location pointed to by @ret will be populated
+ * with a pointer to a struct acpi_device created while scanning the namespace.
+ * If @handle corresponds to a device node, that will be a pointer to the
struct
+ * acpi_device object corresponding to @handle. Otherwise, it will be a
pointer
+ * to a struct acpi_device corresponding to one of its descendants.
+ *
+ * If an error code is returned, NULL will be stored in the memory location
+ * pointed to by @ret.
*/
-
-int
-acpi_bus_add(struct acpi_device **child,
-struct acpi_device *parent, acpi_handle handle, int type)
+int acpi_bus_add(acpi_handle handle, struct acpi_device **ret)
{
int err;
- err = acpi_bus_scan(handle, false, child);
+ err = acpi_bus_scan(handle, false, ret);
if (err)
return err;
Index: linux/include/acpi/acpi_bus.h
===
--- linux.orig/include/acpi/acpi_bus.h
+++ linux/include/acpi/acpi_bus.h
@@ -398,8 +398,7 @@ static inline int acpi_bus_generate_proc
#endif
int acpi_bus_register_driver(struct acpi_driver *driver);
void acpi_bus_unregister_driver(struct acpi_driver *driver);
-int acpi_bus_add(struct acpi_device **child, struct acpi_device *parent,
-acpi_handle handle, int type);
+int acpi_bus_add(acpi_handle handle, struct acpi_device **ret);
void acpi_bus_hot_remove_device(void *context);
int acpi_bus_trim(struct acpi_device *start, int rmdevice);
acpi_status acpi_bus_get_ejd(acpi_handle handle, acpi_handle * ejd);
Index: linux/drivers/pci/hotplug/sgi_hotplug.c
===
--- linux.orig/drivers/pci/hotplug/sgi_hotplug.c
+++ linux/drivers/pci/hotplug/sgi_hotplug.c
@@ -448,8 +448,7 @@ static int enable_slot(struct hotplug_sl
if (ACPI_SUCCESS(ret) &&
(adr>>16) == (slot->device_num + 1)) {
- ret = acpi_bus_add(&device, pdevice, chandle,
- ACPI_BUS_TYPE_DEVICE);
+ ret = acpi_bus_add(chandle, &device);
if (ACPI_FAILURE(ret)) {
printk(KERN_ERR "%s: acpi_bus_add "
"failed (0x%x) for slot %d "
Index: linux/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux/drivers/pci/hotplug/acpiphp_glue.c
@@ -734,15 +734,9 @@ static unsigned char acpiphp_max_busnr(s
*/
static int acpiphp_bus_add(struct acpiphp_func *func)
{
- acpi_handle phandle;
- struct acpi_de
Re: Re: [PATCH] subsystem: pr??oc filesystem
On Sun, Dec 16, 2012 at 04:02:03PM +0400, tux2...@front.ru wrote: > Not, this permissions saved for all users for later, check please. ... and that's why it's bogus. umask of whoever had done lookup for /proc/ affects everybody else. For as long as the thing stays in dcache. At which point it's up for grabs (in that sense) again. Do (umask 777; ls -l /proc) with your kernel and watch the results. Note that you don't need to be root to cause that - anyone can do it. Realize that dentries and inodes in /proc//* are created on demand whenever somebody does a lookup. So running ps(1) suddenly makes you a creator of a bunch of those. Unless somebody else had done ps(1) (or ls -l /proc, or...) first. Basing any security decisions on _that_ is insane. -- 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] x86/uapi for 3.8
On Sun, 2012-12-16 at 14:25 +0100, Markus Trippelsdorf wrote: > Matt, your patch fixes the problem for me. Thanks. That's great! Thanks for testing so quickly. At least we now know the problem wasn't caused by a memory map issue, just my buggy patch. Linus, Peter, how should we proceed from here? Since the commit and its dependants have been reverted should we punt for now and try again next merge window? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Resend][PATCH] PM: Move disabling/enabling runtime PM to late suspend/early resume
On Sun, 16 Dec 2012, Rafael J. Wysocki wrote: > On Saturday, December 15, 2012 10:16:29 PM Jiri Kosina wrote: > > On Sat, 15 Dec 2012, Rafael J. Wysocki wrote: > > > > > From: Rafael J. Wysocki > > > > > > Currently, the PM core disables runtime PM for all devices right > > > after executing subsystem/driver .suspend() callbacks for them > > > and re-enables it right before executing subsystem/driver .resume() > > > callbacks for them. This may lead to problems when there are > > > two devices such that the .suspend() callback executed for one of > > > them depends on runtime PM working for the other. In that case, > > > if runtime PM has already been disabled for the second device, > > > the first one's .suspend() won't work correctly (and analogously > > > for resume). > > > > > > To make those issues go away, make the PM core disable runtime PM > > > for devices right before executing subsystem/driver .suspend_late() > > > callbacks for them and enable runtime PM for them right after > > > executing subsystem/driver .resume_early() callbacks for them. This > > > way the potential conflitcs between .suspend_late()/.resume_early() > > > and their runtime PM counterparts are still prevented from happening, > > > but the subtle ordering issues related to disabling/enabling runtime > > > PM for devices during system suspend/resume are much easier to avoid. > > > > > > Reported-and-tested-by: Jan-Matthias Braun > > > Signed-off-by: Rafael J. Wysocki > > > > Hi Rafael, > > > > just curious what is the reason for resend? Do you want to gather more > > Acks before pushing this upstream? > > Well, I thought that some people might actually look at it when they found it > again in their mailboxes. :-) I did look at it the first time it appeared. It seemed to be okay, but I haven't tried any testing. Alan Stern -- 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: [regression] 3.7 ends in APIC panic
On 12/16/2012 12:35 PM, Ingo Molnar wrote: > > * Bernd Schubert wrote: > >> On 12/13/2012 01:16 PM, Bernd Schubert wrote: >>> Hello, >>> >>> I just tried to boot 3.7 and it ends in an APIC panic. I >>> tried to use the recommended "apic=debug", but that does not >>> change anything in the output, at least not in the visible >>> part. The last known kernel to boot was 3.5. If it matters I >>> can try to boot 3.6. >> >> So linux-3.6 also boots. Any idea what is going on or do I >> really need to bisect? > > Yeah, it's hard to tell based on that info alone - would be nice > to send in a log/screen capture of the crash and of course > bisecting would be useful as well, if the crash is > deterministic. I already sent a screen capture in my first mail, but now uploaded two pictures here: http://www.aakef.fastmail.fm/linux/ I think the 2nd one is with apic=debug. Unfortunately the system does not have ipmi, which would allow me to do the bisecting now. It is also my desktop system at work and I don't know yet when (and if at all) I will find the time to do the reboot cycles. Cheers, Bernd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] bcma: BCMA_DRIVER_GPIO should depend on GPIOLIB instead of selecting it
Commit cf0936b06d8e98a157630e99f647e2ff6d29d7ad ("bcma: add GPIO driver")
added BCMA_DRIVER_GPIO, which unconditionally selects GPIOLIB, causing
a Kconfig warning:
warning: (ARCH_REQUIRE_GPIOLIB && SSB_DRIVER_GPIO && BCMA_DRIVER_GPIO &&
MFD_TC6393XB && FB_VIA) selects GPIOLIB which has unmet direct dependencies
(ARCH_WANT_OPTIONAL_GPIOLIB || ARCH_REQUIRE_GPIOLIB)
and build failure for m68k/allmodconfig:
In file included from include/linux/bcma/bcma.h:8,
from drivers/bcma/bcma_private.h:9,
from drivers/bcma/main.c:9:
include/linux/bcma/bcma_driver_chipcommon.h:582: error: field ‘gpio’ has
incomplete type
In file included from include/linux/bcma/bcma.h:12,
from drivers/bcma/bcma_private.h:9,
from drivers/bcma/main.c:9:
include/linux/ssb/ssb.h:440: error: field ‘gpio’ has incomplete type
make[4]: *** [drivers/bcma/main.o] Error 1
make[3]: *** [drivers/bcma/] Error 2
Turn the select into a dependency to fix this.
Signed-off-by: Geert Uytterhoeven
---
drivers/bcma/Kconfig |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig
index d7b56a8..8b4221c 100644
--- a/drivers/bcma/Kconfig
+++ b/drivers/bcma/Kconfig
@@ -67,8 +67,7 @@ config BCMA_DRIVER_GMAC_CMN
config BCMA_DRIVER_GPIO
bool "BCMA GPIO driver"
- depends on BCMA
- select GPIOLIB
+ depends on BCMA && GPIOLIB
help
Driver to provide access to the GPIO pins of the bcma bus.
--
1.7.0.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 2/2] ssb: SSB_DRIVER_GPIO should depend on GPIOLIB instead of selecting it
Commit ec43b08b5733494ad88aa618ecdf534320dd8207 ("ssb: add GPIO driver")
added SSB_DRIVER_GPIO, which unconditionally selects GPIOLIB, causing
a Kconfig warning:
warning: (ARCH_REQUIRE_GPIOLIB && SSB_DRIVER_GPIO && BCMA_DRIVER_GPIO &&
MFD_TC6393XB && FB_VIA) selects GPIOLIB which has unmet direct dependencies
(ARCH_WANT_OPTIONAL_GPIOLIB || ARCH_REQUIRE_GPIOLIB)
and build failure for m68k/allmodconfig:
In file included from drivers/ssb/ssb_private.h:5,
from drivers/ssb/main.c:12:
include/linux/ssb/ssb.h:440: error: field ‘gpio’ has incomplete type
make[4]: *** [drivers/ssb/main.o] Error 1
make[3]: *** [drivers/ssb/] Error 2
Turn the select into a dependency to fix this.
Signed-off-by: Geert Uytterhoeven
---
drivers/ssb/Kconfig |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/ssb/Kconfig b/drivers/ssb/Kconfig
index ff3c8a2..5d6f2ec 100644
--- a/drivers/ssb/Kconfig
+++ b/drivers/ssb/Kconfig
@@ -162,8 +162,7 @@ config SSB_DRIVER_GIGE
config SSB_DRIVER_GPIO
bool "SSB GPIO driver"
- depends on SSB
- select GPIOLIB
+ depends on SSB && GPIOLIB
help
Driver to provide access to the GPIO pins on the bus.
--
1.7.0.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] ACPI / PM: Do not apply ACPI_SUCCESS() to acpi_bus_get_device() result
On Sun, Dec 16, 2012 at 02:32:06PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Since the return value of acpi_bus_get_device() is not of type > acpi_status, ACPI_SUCCESS() should not be used for checking its > return value. Fix that. > > Signed-off-by: Rafael J. Wysocki Reviewed-by: Mika Westerberg > --- > drivers/acpi/device_pm.c |3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > Index: linux/drivers/acpi/device_pm.c > === > --- linux.orig/drivers/acpi/device_pm.c > +++ linux/drivers/acpi/device_pm.c > @@ -358,8 +358,7 @@ static struct acpi_device *acpi_dev_pm_g > acpi_handle handle = DEVICE_ACPI_HANDLE(dev); > struct acpi_device *adev; > > - return handle && ACPI_SUCCESS(acpi_bus_get_device(handle, &adev)) ? > - adev : NULL; > + return handle && !acpi_bus_get_device(handle, &adev) ? adev : NULL; > } > > /** -- 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/6] ACPI: Simplify namespace scanning for devices
Hi Rafael, Great idea to get rid of the .start() staff, it could also simplify our hotplug framework too. Thanks! Gerry On 12/16/2012 09:47 PM, Rafael J. Wysocki wrote: > Hi All, > > This series is on top of the one I sent on Thursday: > > https://lkml.org/lkml/2012/12/13/632 > > It goes one step farther and makes some simplifications that become possible > after applying that patchset. > > [1/6] Fold acpi_pci_root_start() into acpi_pci_root_add() > [2/6] Remove acpi_start_single_object() and acpi_bus_start() > [3/6] Remove the arguments of acpi_bus_add() that are not used > [4/6] Drop the second argument of acpi_bus_scan() > [5/6] Replace ACPI device add_type field with a match_driver flag > [6/6] Make acpi_bus_scan() and acpi_bus_add() take only one argument > > It survives booting on Toshiba Portege R500 without any visible issues. > > Thanks, > Rafael > > -- 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] block: Optionally snapshot page contents to provide stable pages during write
On Thu, Dec 13, 2012 at 12:08:11AM -0800, Darrick J. Wong wrote:
> diff --git a/mm/bounce.c b/mm/bounce.c
> index 0420867..fa11935 100644
> --- a/mm/bounce.c
> +++ b/mm/bounce.c
> @@ -178,6 +178,38 @@ static void bounce_end_io_read_isa(struct bio *bio, int
> err)
> __bounce_end_io_read(bio, isa_page_pool, err);
> }
>
> +#ifdef CONFIG_NEED_BOUNCE_POOL
> +static int might_snapshot_stable_page_write(struct bio **bio_orig)
> +{
> + return bio_data_dir(*bio_orig) == WRITE;
> +}
> +
> +static int should_snapshot_stable_pages(struct page *page, int rw)
> +{
> + struct backing_dev_info *bdi;
> + struct address_space *mapping = page_mapping(page);
> +
> + if (!mapping)
> + return 0;
> + bdi = mapping->backing_dev_info;
> + if (!bdi_cap_stable_pages_required(bdi))
> + return 0;
> +
> + return mapping->host->i_sb->s_flags & MS_SNAP_STABLE &&
> +rw == WRITE;
> +}
> +#else
> +static int might_snapshot_stable_page_write(struct bio **bio_orig)
> +{
> + return 0;
> +}
> +
> +static int should_snapshot_static_pages(struct page *page, int rw)
^^
It should be _stable_.
Regards,
- Zheng
> +{
> + return 0;
> +}
> +#endif /* CONFIG_NEED_BOUNCE_POOL */
> +
> static void __blk_queue_bounce(struct request_queue *q, struct bio
> **bio_orig,
> mempool_t *pool)
> {
> @@ -192,7 +224,8 @@ static void __blk_queue_bounce(struct request_queue *q,
> struct bio **bio_orig,
> /*
>* is destination page below bounce pfn?
>*/
> - if (page_to_pfn(page) <= queue_bounce_pfn(q))
> + if (page_to_pfn(page) <= queue_bounce_pfn(q) &&
> + !should_snapshot_stable_pages(page, rw))
> continue;
>
> /*
> @@ -284,7 +317,8 @@ void blk_queue_bounce(struct request_queue *q, struct bio
> **bio_orig)
>* don't waste time iterating over bio segments
>*/
> if (!(q->bounce_gfp & GFP_DMA)) {
> - if (queue_bounce_pfn(q) >= blk_max_pfn)
> + if (queue_bounce_pfn(q) >= blk_max_pfn &&
> + !might_snapshot_stable_page_write(bio_orig))
> return;
> pool = page_pool;
> } else {
--
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/
dma_mmap_coherent / ARCH_HAS_DMA_MMAP_COHERENT
drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_mmap’:
drivers/media/v4l2-core/videobuf2-dma-contig.c:204: error: implicit
declaration of function ‘dma_mmap_coherent’
drivers/media/v4l2-core/videobuf2-dma-contig.c: In function
‘vb2_dc_get_base_sgt’:
drivers/media/v4l2-core/videobuf2-dma-contig.c:387: error: implicit
declaration of function ‘dma_get_sgtable’
make[6]: *** [drivers/media/v4l2-core/videobuf2-dma-contig.o] Error 1
make[6]: Target `__build' not remade because of errors.
make[5]: *** [drivers/media/v4l2-core] Error 2
Both dma_mmap_coherent() and dma_get_sgtable() are defined in
include/asm-generic/dma-mapping-common.h only, which is included by
on alpha, arm, arm64, hexagon, ia64, microblaze, mips,
openrisc, powerpc, s390, sh, sparc, tile, unicore32, x86.
Should the remaining architectures include this, too?
Should it be moved to ?
Furthermore, there's ARCH_HAS_DMA_MMAP_COHERENT, which is defined
by powerpc only:
arch/powerpc/include/asm/dma-mapping.h:#define ARCH_HAS_DMA_MMAP_COHERENT
and handled in some fishy way in sound/core/pcm_native.c:
#ifndef ARCH_HAS_DMA_MMAP_COHERENT
/* This should be defined / handled globally! */
#ifdef CONFIG_ARM
#define ARCH_HAS_DMA_MMAP_COHERENT
#endif
#endif
/*
* mmap the DMA buffer on RAM
*/
int snd_pcm_lib_default_mmap(struct snd_pcm_substream *substream,
struct vm_area_struct *area)
{
area->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
#ifdef ARCH_HAS_DMA_MMAP_COHERENT
if (!substream->ops->page &&
substream->dma_buffer.dev.type == SNDRV_DMA_TYPE_DEV)
return dma_mmap_coherent(substream->dma_buffer.dev.dev,
area,
substream->runtime->dma_area,
substream->runtime->dma_addr,
area->vm_end - area->vm_start);
#elif defined(CONFIG_MIPS) && defined(CONFIG_DMA_NONCOHERENT)
if (substream->dma_buffer.dev.type == SNDRV_DMA_TYPE_DEV &&
!plat_device_is_coherent(substream->dma_buffer.dev.dev))
area->vm_page_prot = pgprot_noncached(area->vm_page_prot);
#endif /* ARCH_HAS_DMA_MMAP_COHERENT */
/* mmap with fault handler */
area->vm_ops = &snd_pcm_vm_ops_data_fault;
return 0;
}
EXPORT_SYMBOL_GPL(snd_pcm_lib_default_mmap);
What's up here?
Thx!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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][V2] cpuidle - optimize the select function for the 'menu' governor
Hi Daniel,
On 12/14/2012 02:57 PM, Daniel Lezcano wrote:
> As the power is backward sorted in the states array and we are looking for
> the state consuming the little power as possible, instead of looking from
> the beginning of the array, we look from the end. That should save us some
> iterations in the loop each time we select a state at idle time.
>
> Signed-off-by: Daniel Lezcano
> ---
> drivers/cpuidle/governors/menu.c | 12 ++--
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/cpuidle/governors/menu.c
> b/drivers/cpuidle/governors/menu.c
> index fe343a0..05b8998 100644
> --- a/drivers/cpuidle/governors/menu.c
> +++ b/drivers/cpuidle/governors/menu.c
> @@ -367,24 +367,24 @@ static int menu_select(struct cpuidle_driver *drv,
> struct cpuidle_device *dev)
>* Find the idle state with the lowest power while satisfying
>* our constraints.
>*/
> - for (i = CPUIDLE_DRIVER_STATE_START; i < drv->state_count; i++) {
> + for (i = drv->state_count - 1; i >= CPUIDLE_DRIVER_STATE_START; i--) {
> struct cpuidle_state *s = &drv->states[i];
> struct cpuidle_state_usage *su = &dev->states_usage[i];
>
> if (s->disabled || su->disable)
> continue;
> - if (s->target_residency > data->predicted_us) {
> - low_predicted = 1;
> - continue;
> - }
> if (s->exit_latency > latency_req)
> continue;
> + if (s->target_residency > data->predicted_us)
> + continue;
> if (s->exit_latency * multiplier > data->predicted_us)
> continue;
>
> + low_predicted = i - CPUIDLE_DRIVER_STATE_START;
You are altering the semantics of low_predicted, which is supposed to be
non-zero when the deepest C-state has not been chosen because its target
residency is more than the predicted residency.
It seems to me that the if block where target_residency is compared with
the predicted residency should be left as is.
> data->last_state_idx = i;
> data->exit_us = s->exit_latency;
> - }
> + break;
> + }
>
> /* not deepest C-state chosen for low predicted residency */
> if (low_predicted) {
--
Francesco
--
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] make CONFIG_EXPERIMENTAL invisible and default
On Sun, Dec 16, 2012 at 05:29:21AM +0100, Jan Engelhardt wrote: > > On Wednesday 2012-10-03 18:17, Greg Kroah-Hartman wrote: > >> > >> OK, I will bite... How should I flag an option that is initially only > >> intended for those willing to take some level of risk? > > > >In the text say "You really don't want to enable this option, use at > >your own risk!" Or something like that :) > > You know that won't not work, just like "everybody is encouraged > to upgrade" for -stable. It needs to say "All users must disable this!" The thought expressed earlier in this thread of unconditionally splatting during boot seemed pretty compelling to me. ;-) Thanx, Paul -- 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 v2 6/8] gpu: drm: tegra: Remove redundant host1x
On 16.12.2012 14:16, Thierry Reding wrote: > Okay, so we're back on the topic of using globals. I need to assert > again that this is not an option. If we were to use globals, then we > could just as well leave out the dummy device and just do all of that in > the tegra-drm driver's initialization function. > The whole point of all this is to link the host1x and it's particular > tegra-drm instance. I will see if I can find the time to implement this > in the existing driver, so that the host1x code that you want to remove > registers the tegra-drm dummy device and the tegra-drm devices use the > accessors as discussed previously to access host1x and the dummy device. > Once that is implemented, removing the original host1x implementation > should be much easier since you will only have to keep the dummy device > instantiation along with the one or two accessor functions. I'm not sure what you have discussed with Stephen, so I might be missing the reason why this is a problem that needs to be solved with new dependency between tegradrm and host1x instead of locally in tegradrm driver itself. As far I remember, we had two reasons for discussing the dummy device. First reason is for DC, HDMI probe calls to find the global data. Second is giving something to DRM framework's drm_platform_init(). The easiest way to solve the probe problem is just to have a tegradrm accessor for the global data in the way I proposed in the patchset. Dummy device doesn't help there, as the dummy device is in no relationship to DC and HDMI. Sure we could tell DC to ask its parent (host1x), and call host1x driver with platform_device pointer found that way, and host1x would return a pointer to tegradrm's data. Hanging the data onto host1x driver is just a more complicated way of implementing global data, and it's breaking the responsibility split between host1x driver and tegradrm. To me, host1x driver is responsible of host1x, and tegradrm is responsible of the DRM interface and everything related to that. All other parts of code use drm_device->dev_private for getting the global data, so the access problem is only for the probe calls. drm_platform_init() needing a device is another problem. drm_platform_init() leads to a call to the CMA FB helper. That again needed the coherent_dma_mask set for the device give to it. I guess that problem can be solved by just setting the mask to 0x. But that is still something that can be handled inside tegradrm without involving the host1x driver. Terje -- 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] ipv6: Fix Makefile offload objects
The following commit breaks IPv6 TCP transmission for me: Commit 75fe83c32248d99e6d5fe64155e519b78bb90481 Author: Vlad Yasevich Date: Fri Nov 16 09:41:21 2012 + ipv6: Preserve ipv6 functionality needed by NET This patch fixes the typo "ipv6_offload" which should be "ipv6-offload". I don't know why not including the offload modules should break TCP. Disabling all offload options on the NIC didn't help. Outgoing pulseaudio traffic kept stalling. Signed-off-by: Simon Arlott --- net/ipv6/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/ipv6/Makefile b/net/ipv6/Makefile index 2068ac4..4ea2448 100644 --- a/net/ipv6/Makefile +++ b/net/ipv6/Makefile @@ -41,6 +41,6 @@ obj-$(CONFIG_IPV6_TUNNEL) += ip6_tunnel.o obj-$(CONFIG_IPV6_GRE) += ip6_gre.o obj-y += addrconf_core.o exthdrs_core.o -obj-$(CONFIG_INET) += output_core.o protocol.o $(ipv6_offload) +obj-$(CONFIG_INET) += output_core.o protocol.o $(ipv6-offload) obj-$(subst m,y,$(CONFIG_IPV6)) += inet6_hashtables.o -- 1.7.8.rc3 -- Simon Arlott -- 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] mm: Downgrade mmap_sem before locking or populating on mmap
On Fri, Dec 14, 2012 at 08:12:45AM -0800, Andy Lutomirski wrote: > On Fri, Dec 14, 2012 at 6:49 AM, Al Viro wrote: > > On Fri, Dec 14, 2012 at 03:14:50AM -0800, Andy Lutomirski wrote: > > > >> > Wait a minute. get_user_pages() relies on ->mmap_sem being held. Unless > >> > I'm seriously misreading your patch it removes that protection. And yes, > >> > I'm aware of execve-related exception; it's in special circumstances - > >> > bprm->mm is guaranteed to be not shared (and we need to rearchitect that > >> > area anyway, but that's a separate story). > >> > >> Unless I completely screwed up the patch, ->mmap_sem is still held for > >> read (it's downgraded from write). It's just not held for write > >> anymore. > > > > Huh? I'm talking about the call of get_user_pages() in aio_setup_ring(). > > With your patch it's done completely outside of ->mmap_sem, isn't it? > > Oh, /that/ call to get_user_pages. That would qualify as screwing up... > > Since dropping and reacquiring mmap_sem there is probably a bad idea > there, I'll rework this and post a v2. FWIW, I've done some checking of ->mmap_sem uses yesterday. Got further than the last time; catch so far, just from find_vma() audit: * arm swp_emulate.c - missing ->mmap_sem around find_vma(). Fix sent to rmk. * blackfin ptrace - find_vma() without any protection, definitely broken * m68k sys_cacheflush() - ditto * mips process_fpemu_return() - ditto * mips octeon_flush_cache_sigtramp() - ditto * omap_vout_uservirt_to_phys() - ditto, patch sent * vb2_get_contig_userptr() - probaly a bug, unless I've misread the (very twisty maze of) v4l2 code leading to it * vb2_get_contig_userptr() - ditto * gntdev_ioctl_get_offset_for_vaddr() - definitely broken and there's a couple of dubious places in arch/* I hadn't finished with, plus a lot in mm/* proper. That's just from a couple of days of RTFS. The locking in there is far too convoluted as it is; worse, it's not localized code-wise, so rechecking correctness is going to remain a big time-sink ;-/ Making it *more* complex doesn't look like a good idea, TBH... BTW, the __get_user_pages()/find_extend_vma()/mlock_vma_pages_range() pile is really asking for trouble; sure, the recursion there is limited, but it deserves a comment. Moreover, the damn thing is reachable from coredump path and there we do *not* have ->mmap_sem held. We don't reach the VM_BUG_ON() in __mlock_vma_pages_range(), but the reason for that also deserves a comment, IMO. Moreover, I'm not quite convinced that huge_memory.c and ksm.c can't run into all kinds of interesting races with ongoing coredump. Looking into it... -- 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] ipv6: Fix Makefile offload objects
From: Simon Arlott Date: Sun, 16 Dec 2012 16:47:50 + > The following commit breaks IPv6 TCP transmission for me: > Commit 75fe83c32248d99e6d5fe64155e519b78bb90481 > Author: Vlad Yasevich > Date: Fri Nov 16 09:41:21 2012 + > ipv6: Preserve ipv6 functionality needed by NET > > This patch fixes the typo "ipv6_offload" which should be > "ipv6-offload". > > I don't know why not including the offload modules should > break TCP. Disabling all offload options on the NIC didn't > help. Outgoing pulseaudio traffic kept stalling. > > Signed-off-by: Simon Arlott Applied, since the fix is so obvious. I'll let Vlad explain why it has such an unexpected effect. 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/
[PATCH/WIP/RFC 01/14] ARM: sh-mobile: Protect ipmmu.h header with ifndef/define
Signed-off-by: Laurent Pinchart --- arch/arm/mach-shmobile/include/mach/ipmmu.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-shmobile/include/mach/ipmmu.h b/arch/arm/mach-shmobile/include/mach/ipmmu.h index ede2f0b..4b805b1f 100644 --- a/arch/arm/mach-shmobile/include/mach/ipmmu.h +++ b/arch/arm/mach-shmobile/include/mach/ipmmu.h @@ -1,3 +1,6 @@ +#ifndef __SHMOBILE_IPMMU_H__ +#define __SHMOBILE_IPMMU_H__ + #ifdef CONFIG_SHMOBILE_IPMMU_TLB void ipmmu_tlb_flush(struct device *ipmmu_dev); void ipmmu_tlb_set(struct device *ipmmu_dev, unsigned long phys, int size, @@ -14,3 +17,5 @@ static int ipmmu_iommu_init(struct device *dev) return -EINVAL; } #endif + +#endif /* __SHMOBILE_IPMMU_H__ */ -- 1.7.8.6 -- 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/WIP/RFC 14/14] shmobile-ipmmu: Store iommu_mapping in struct shmobile_ipmmu
And remove the global iommu_mapping variable.
Signed-off-by: Laurent Pinchart
---
drivers/iommu/shmobile-iommu.c | 14 --
drivers/iommu/shmobile-ipmmu.h |4
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/shmobile-iommu.c b/drivers/iommu/shmobile-iommu.c
index 2592d25..8cf45df 100644
--- a/drivers/iommu/shmobile-iommu.c
+++ b/drivers/iommu/shmobile-iommu.c
@@ -47,7 +47,6 @@ struct shmobile_iommu_domain {
atomic_t active;
};
-static struct dma_iommu_mapping *iommu_mapping;
static struct device *ipmmu_devices;
static struct dma_pool *l1pool, *l2pool;
static spinlock_t lock;
@@ -311,19 +310,22 @@ static struct iommu_ops shmobile_iommu_ops = {
static int shmobile_iommu_attach_all_devices(struct shmobile_ipmmu *ipmmu)
{
+ struct dma_iommu_mapping *mapping;
struct device *dev;
- iommu_mapping = arm_iommu_create_mapping(&platform_bus_type, 0x0,
-L1_LEN << 20, 0);
- if (IS_ERR_OR_NULL(iommu_mapping))
- return PTR_ERR(iommu_mapping);
+ mapping = arm_iommu_create_mapping(&platform_bus_type, 0,
+ L1_LEN << 20, 0);
+ if (IS_ERR(mapping))
+ return PTR_ERR(mapping);
+
+ ipmmu->iommu_mapping = mapping;
for (dev = ipmmu_devices; dev; ) {
struct shmobile_iommu_arch_data *data = dev->archdata.iommu;
data->ipmmu = ipmmu;
- if (arm_iommu_attach_device(dev, iommu_mapping))
+ if (arm_iommu_attach_device(dev, mapping))
pr_err("arm_iommu_attach_device failed\n");
dev = data->next;
diff --git a/drivers/iommu/shmobile-ipmmu.h b/drivers/iommu/shmobile-ipmmu.h
index 1458a97..f8f0f57 100644
--- a/drivers/iommu/shmobile-ipmmu.h
+++ b/drivers/iommu/shmobile-ipmmu.h
@@ -1,11 +1,15 @@
#ifndef __SHMOBILE_IPMMU_H__
#define __SHMOBILE_IPMMU_H__
+struct dma_iommu_mapping;
+
struct shmobile_ipmmu {
struct device *dev;
void __iomem *ipmmu_base;
int tlb_enabled;
struct mutex flush_lock;
+
+ struct dma_iommu_mapping *iommu_mapping;
};
#ifdef CONFIG_SHMOBILE_IPMMU_TLB
--
1.7.8.6
--
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/WIP/RFC 11/14] shmobile-ipmmu: Store a struct shmobile_iommu_arch_data in archdata.iommu
Signed-off-by: Laurent Pinchart
---
drivers/iommu/shmobile-iommu.c | 20 +---
include/linux/sh_iommu.h | 10 --
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/shmobile-iommu.c b/drivers/iommu/shmobile-iommu.c
index 423993c..f27d842 100644
--- a/drivers/iommu/shmobile-iommu.c
+++ b/drivers/iommu/shmobile-iommu.c
@@ -308,25 +308,39 @@ static int shmobile_iommu_attach_all_devices(void)
ret = PTR_ERR(iommu_mapping);
goto err;
}
- for (dev = ipmmu_devices; dev; dev = dev->archdata.iommu) {
+ for (dev = ipmmu_devices; dev; ) {
+ struct shmobile_iommu_arch_data *data = dev->archdata.iommu;
+
if (arm_iommu_attach_device(dev, iommu_mapping))
pr_err("arm_iommu_attach_device failed\n");
+
+ dev = data->next;
}
err:
spin_unlock(&lock_add);
return 0;
}
-void ipmmu_add_device(struct device *dev)
+int ipmmu_add_device(struct device *dev)
{
+ struct shmobile_iommu_arch_data *data;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (data == NULL)
+ return -ENOMEM;
+
+ dev->archdata.iommu = data;
+
spin_lock(&lock_add);
- dev->archdata.iommu = ipmmu_devices;
+ data->next = ipmmu_devices;
ipmmu_devices = dev;
if (!IS_ERR_OR_NULL(iommu_mapping)) {
if (arm_iommu_attach_device(dev, iommu_mapping))
pr_err("arm_iommu_attach_device failed\n");
}
spin_unlock(&lock_add);
+
+ return 0;
}
int ipmmu_iommu_init(struct shmobile_ipmmu *ipmmu)
diff --git a/include/linux/sh_iommu.h b/include/linux/sh_iommu.h
index cc669a0..8b7b51d 100644
--- a/include/linux/sh_iommu.h
+++ b/include/linux/sh_iommu.h
@@ -1,10 +1,16 @@
#ifndef __SH_IOMMU_H__
#define __SH_IOMMU_H__
+struct device;
+
+struct shmobile_iommu_arch_data {
+ struct device *next;
+};
+
#ifdef CONFIG_SHMOBILE_IPMMU_TLB
-void ipmmu_add_device(struct device *dev);
+int ipmmu_add_device(struct device *dev);
#else
-static inline void ipmmu_add_device(struct device *dev)
+static inline int ipmmu_add_device(struct device *dev)
{
}
#endif
--
1.7.8.6
--
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/WIP/RFC 12/14] shmobile-ipmmu: Store ipmmu pointer in iommu arch data and iommu domain
This gets rid of the global ipmmu_access_device pointer.
Signed-off-by: Laurent Pinchart
---
drivers/iommu/shmobile-iommu.c | 37 ++---
include/linux/sh_iommu.h |2 ++
2 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/drivers/iommu/shmobile-iommu.c b/drivers/iommu/shmobile-iommu.c
index f27d842..bf1d0a4 100644
--- a/drivers/iommu/shmobile-iommu.c
+++ b/drivers/iommu/shmobile-iommu.c
@@ -41,6 +41,7 @@ struct shmobile_iommu_domain_pgtable {
};
struct shmobile_iommu_domain {
+ struct shmobile_ipmmu *ipmmu;
struct shmobile_iommu_domain_pgtable l1, l2[L1_LEN];
spinlock_t map_lock;
atomic_t active;
@@ -53,7 +54,17 @@ static spinlock_t lock;
static DEFINE_SPINLOCK(lock_add);
static struct shmobile_iommu_domain *attached;
static int num_attached_devices;
-static struct shmobile_ipmmu *ipmmu_access_device;
+
+/**
+ * dev_to_ipmmu() - retrieves an shmobile ipmmu object from a user device
+ * @dev: ipmmu client device
+ */
+static inline struct shmobile_ipmmu *dev_to_ipmmu(struct device *dev)
+{
+ struct shmobile_iommu_arch_data *arch_data = dev->archdata.iommu;
+
+ return arch_data->ipmmu;
+}
static int shmobile_iommu_domain_init(struct iommu_domain *domain)
{
@@ -97,6 +108,7 @@ static int shmobile_iommu_attach_device(struct iommu_domain
*domain,
struct device *dev)
{
struct shmobile_iommu_domain *sh_domain = domain->priv;
+ struct shmobile_ipmmu *ipmmu = dev_to_ipmmu(dev);
int ret = -EBUSY;
spin_lock(&lock);
@@ -104,12 +116,12 @@ static int shmobile_iommu_attach_device(struct
iommu_domain *domain,
if (attached)
goto err;
atomic_set(&sh_domain->active, 1);
- ipmmu_tlb_set(ipmmu_access_device, sh_domain->l1.handle,
L1_SIZE,
- 0);
+ ipmmu_tlb_set(ipmmu, sh_domain->l1.handle, L1_SIZE, 0);
wmb();
- ipmmu_tlb_flush(ipmmu_access_device);
+ ipmmu_tlb_flush(ipmmu);
attached = sh_domain;
num_attached_devices = 0;
+ sh_domain->ipmmu = ipmmu;
}
num_attached_devices++;
ret = 0;
@@ -122,14 +134,16 @@ static void shmobile_iommu_detach_device(struct
iommu_domain *domain,
struct device *dev)
{
struct shmobile_iommu_domain *sh_domain = domain->priv;
+ struct shmobile_ipmmu *ipmmu = dev_to_ipmmu(dev);
spin_lock(&lock);
atomic_set(&sh_domain->active, 0);
num_attached_devices--;
if (!num_attached_devices) {
- ipmmu_tlb_set(ipmmu_access_device, 0, 0, 0);
- ipmmu_tlb_flush(ipmmu_access_device);
+ ipmmu_tlb_set(ipmmu, 0, 0, 0);
+ ipmmu_tlb_flush(ipmmu);
attached = NULL;
+ sh_domain->ipmmu = NULL;
}
spin_unlock(&lock);
}
@@ -208,7 +222,7 @@ static int shmobile_iommu_map(struct iommu_domain *domain,
unsigned long iova,
}
if (!ret && atomic_read(&sh_domain->active)) {
wmb();
- ipmmu_tlb_flush(ipmmu_access_device);
+ ipmmu_tlb_flush(sh_domain->ipmmu);
l2realfree(&l2);
}
return ret;
@@ -252,7 +266,7 @@ static size_t shmobile_iommu_unmap(struct iommu_domain
*domain,
done:
if (ret && atomic_read(&sh_domain->active)) {
wmb();
- ipmmu_tlb_flush(ipmmu_access_device);
+ ipmmu_tlb_flush(sh_domain->ipmmu);
l2realfree(&l2);
}
return ret;
@@ -296,7 +310,7 @@ static struct iommu_ops shmobile_iommu_ops = {
.pgsize_bitmap = 0x111000,
};
-static int shmobile_iommu_attach_all_devices(void)
+static int shmobile_iommu_attach_all_devices(struct shmobile_ipmmu *ipmmu)
{
struct device *dev;
int ret = 0;
@@ -311,6 +325,8 @@ static int shmobile_iommu_attach_all_devices(void)
for (dev = ipmmu_devices; dev; ) {
struct shmobile_iommu_arch_data *data = dev->archdata.iommu;
+ data->ipmmu = ipmmu;
+
if (arm_iommu_attach_device(dev, iommu_mapping))
pr_err("arm_iommu_attach_device failed\n");
@@ -356,9 +372,8 @@ int ipmmu_iommu_init(struct shmobile_ipmmu *ipmmu)
goto nomem_pool2;
spin_lock_init(&lock);
attached = NULL;
- ipmmu_access_device = ipmmu;
bus_set_iommu(&platform_bus_type, &shmobile_iommu_ops);
- if (shmobile_iommu_attach_all_devices())
+ if (shmobile_iommu_attach_all_devices(ipmmu))
pr_err("shmobile_iommu_attach_all_devices failed\n");
return 0;
nomem_pool2:
diff --git a/include/linux/sh_iommu.h b/include/linux/sh_iommu.h
index 8b7b51d..76b6e51 100644
--- a/include/linux/sh_iommu.h
+++ b/include/li
[PATCH/WIP/RFC 13/14] shmobile-ipmmu: Remove unneeded lock_add spinlock
ipmmu_add_device() can never race with
shmobile_iommu_attach_all_devices(), called by ipmmu_iommu_init() as the
former is called from an arch initcall and the later from a subsys
initcall.
Remove the unneeded spinlock as well as the arm_iommu_attach_device() in
ipmmu_add_device(), as the condition that guards the call is always
false.
Signed-off-by: Laurent Pinchart
---
drivers/iommu/shmobile-iommu.c | 18 +++---
1 files changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/iommu/shmobile-iommu.c b/drivers/iommu/shmobile-iommu.c
index bf1d0a4..2592d25 100644
--- a/drivers/iommu/shmobile-iommu.c
+++ b/drivers/iommu/shmobile-iommu.c
@@ -51,7 +51,6 @@ static struct dma_iommu_mapping *iommu_mapping;
static struct device *ipmmu_devices;
static struct dma_pool *l1pool, *l2pool;
static spinlock_t lock;
-static DEFINE_SPINLOCK(lock_add);
static struct shmobile_iommu_domain *attached;
static int num_attached_devices;
@@ -313,15 +312,12 @@ static struct iommu_ops shmobile_iommu_ops = {
static int shmobile_iommu_attach_all_devices(struct shmobile_ipmmu *ipmmu)
{
struct device *dev;
- int ret = 0;
- spin_lock(&lock_add);
iommu_mapping = arm_iommu_create_mapping(&platform_bus_type, 0x0,
L1_LEN << 20, 0);
- if (IS_ERR_OR_NULL(iommu_mapping)) {
- ret = PTR_ERR(iommu_mapping);
- goto err;
- }
+ if (IS_ERR_OR_NULL(iommu_mapping))
+ return PTR_ERR(iommu_mapping);
+
for (dev = ipmmu_devices; dev; ) {
struct shmobile_iommu_arch_data *data = dev->archdata.iommu;
@@ -332,8 +328,6 @@ static int shmobile_iommu_attach_all_devices(struct
shmobile_ipmmu *ipmmu)
dev = data->next;
}
-err:
- spin_unlock(&lock_add);
return 0;
}
@@ -347,14 +341,8 @@ int ipmmu_add_device(struct device *dev)
dev->archdata.iommu = data;
- spin_lock(&lock_add);
data->next = ipmmu_devices;
ipmmu_devices = dev;
- if (!IS_ERR_OR_NULL(iommu_mapping)) {
- if (arm_iommu_attach_device(dev, iommu_mapping))
- pr_err("arm_iommu_attach_device failed\n");
- }
- spin_unlock(&lock_add);
return 0;
}
--
1.7.8.6
--
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/WIP/RFC 06/14] shmobile-iommu: Sort header files alphabetically
Signed-off-by: Laurent Pinchart --- drivers/iommu/shmobile-iommu.c | 10 +- drivers/iommu/shmobile-ipmmu.c |4 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/iommu/shmobile-iommu.c b/drivers/iommu/shmobile-iommu.c index bbbf1bc..9f2243e3 100644 --- a/drivers/iommu/shmobile-iommu.c +++ b/drivers/iommu/shmobile-iommu.c @@ -17,14 +17,14 @@ * */ -#include +#include +#include #include -#include -#include +#include #include -#include +#include +#include #include -#include #define L1_SIZE CONFIG_SHMOBILE_IOMMU_L1SIZE #define L1_LEN (L1_SIZE / 4) diff --git a/drivers/iommu/shmobile-ipmmu.c b/drivers/iommu/shmobile-ipmmu.c index d6df0b4..edec3b8 100644 --- a/drivers/iommu/shmobile-ipmmu.c +++ b/drivers/iommu/shmobile-ipmmu.c @@ -17,10 +17,10 @@ * */ -#include -#include #include #include +#include +#include #include #include -- 1.7.8.6 -- 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/WIP/RFC 10/14] shmobile-ipmmu: Pass a struct shmobile_ipmmu to IPMMU functions
Signed-off-by: Laurent Pinchart
---
drivers/iommu/shmobile-iommu.c | 12 +++---
drivers/iommu/shmobile-ipmmu.c | 90 +++
drivers/iommu/shmobile-ipmmu.h |9 ++--
3 files changed, 55 insertions(+), 56 deletions(-)
diff --git a/drivers/iommu/shmobile-iommu.c b/drivers/iommu/shmobile-iommu.c
index 1a37be2..423993c 100644
--- a/drivers/iommu/shmobile-iommu.c
+++ b/drivers/iommu/shmobile-iommu.c
@@ -53,7 +53,7 @@ static spinlock_t lock;
static DEFINE_SPINLOCK(lock_add);
static struct shmobile_iommu_domain *attached;
static int num_attached_devices;
-static struct device *ipmmu_access_device;
+static struct shmobile_ipmmu *ipmmu_access_device;
static int shmobile_iommu_domain_init(struct iommu_domain *domain)
{
@@ -329,20 +329,20 @@ void ipmmu_add_device(struct device *dev)
spin_unlock(&lock_add);
}
-int ipmmu_iommu_init(struct device *dev)
+int ipmmu_iommu_init(struct shmobile_ipmmu *ipmmu)
{
- dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
- l1pool = dma_pool_create("shmobile-iommu-pgtable1", dev,
+ dma_set_coherent_mask(ipmmu->dev, DMA_BIT_MASK(32));
+ l1pool = dma_pool_create("shmobile-iommu-pgtable1", ipmmu->dev,
L1_SIZE, L1_ALIGN, 0);
if (!l1pool)
goto nomem_pool1;
- l2pool = dma_pool_create("shmobile-iommu-pgtable2", dev,
+ l2pool = dma_pool_create("shmobile-iommu-pgtable2", ipmmu->dev,
L2_SIZE, L2_ALIGN, 0);
if (!l2pool)
goto nomem_pool2;
spin_lock_init(&lock);
attached = NULL;
- ipmmu_access_device = dev;
+ ipmmu_access_device = ipmmu;
bus_set_iommu(&platform_bus_type, &shmobile_iommu_ops);
if (shmobile_iommu_attach_all_devices())
pr_err("shmobile_iommu_attach_all_devices failed\n");
diff --git a/drivers/iommu/shmobile-ipmmu.c b/drivers/iommu/shmobile-ipmmu.c
index b308292..9858c91 100644
--- a/drivers/iommu/shmobile-ipmmu.c
+++ b/drivers/iommu/shmobile-ipmmu.c
@@ -34,99 +34,97 @@
#define IMCTR1_TLBEN (1 << 0)
#define IMCTR1_FLUSH (1 << 1)
-static void ipmmu_reg_write(struct shmobile_ipmmu *priv, unsigned long reg_off,
+static void ipmmu_reg_write(struct shmobile_ipmmu *ipmmu, unsigned long
reg_off,
unsigned long data)
{
- iowrite32(data, priv->ipmmu_base + reg_off);
+ iowrite32(data, ipmmu->ipmmu_base + reg_off);
}
-void ipmmu_tlb_flush(struct device *dev)
+void ipmmu_tlb_flush(struct shmobile_ipmmu *ipmmu)
{
- struct shmobile_ipmmu *priv;
-
- if (!dev)
+ if (!ipmmu)
return;
- priv = dev_get_drvdata(dev);
- mutex_lock(&priv->flush_lock);
- if (priv->tlb_enabled)
- ipmmu_reg_write(priv, IMCTR1, IMCTR1_FLUSH | IMCTR1_TLBEN);
+
+ mutex_lock(&ipmmu->flush_lock);
+ if (ipmmu->tlb_enabled)
+ ipmmu_reg_write(ipmmu, IMCTR1, IMCTR1_FLUSH | IMCTR1_TLBEN);
else
- ipmmu_reg_write(priv, IMCTR1, IMCTR1_FLUSH);
- mutex_unlock(&priv->flush_lock);
+ ipmmu_reg_write(ipmmu, IMCTR1, IMCTR1_FLUSH);
+ mutex_unlock(&ipmmu->flush_lock);
}
-void ipmmu_tlb_set(struct device *dev, unsigned long phys, int size, int asid)
+void ipmmu_tlb_set(struct shmobile_ipmmu *ipmmu, unsigned long phys, int size,
+ int asid)
{
- struct shmobile_ipmmu *priv;
-
- if (!dev)
+ if (!ipmmu)
return;
- priv = dev_get_drvdata(dev);
- mutex_lock(&priv->flush_lock);
+
+ mutex_lock(&ipmmu->flush_lock);
switch (size) {
default:
- priv->tlb_enabled = 0;
+ ipmmu->tlb_enabled = 0;
break;
case 0x2000:
- ipmmu_reg_write(priv, IMTTBCR, 1);
- priv->tlb_enabled = 1;
+ ipmmu_reg_write(ipmmu, IMTTBCR, 1);
+ ipmmu->tlb_enabled = 1;
break;
case 0x1000:
- ipmmu_reg_write(priv, IMTTBCR, 2);
- priv->tlb_enabled = 1;
+ ipmmu_reg_write(ipmmu, IMTTBCR, 2);
+ ipmmu->tlb_enabled = 1;
break;
case 0x800:
- ipmmu_reg_write(priv, IMTTBCR, 3);
- priv->tlb_enabled = 1;
+ ipmmu_reg_write(ipmmu, IMTTBCR, 3);
+ ipmmu->tlb_enabled = 1;
break;
case 0x400:
- ipmmu_reg_write(priv, IMTTBCR, 4);
- priv->tlb_enabled = 1;
+ ipmmu_reg_write(ipmmu, IMTTBCR, 4);
+ ipmmu->tlb_enabled = 1;
break;
case 0x200:
- ipmmu_reg_write(priv, IMTTBCR, 5);
- priv->tlb_enabled = 1;
+ ipmmu_reg_write(ipmmu, IMTTBCR, 5);
+ ipmmu->tlb_enabled = 1;
break;
case 0x100:
- ipmmu_reg_write(priv, IMTTBCR, 6);
-
[PATCH/WIP/RFC 08/14] shmobile-iommu: Rename shmobile_iommu_priv to shmobile_iommu_domain
Signed-off-by: Laurent Pinchart
---
drivers/iommu/shmobile-iommu.c | 152
1 files changed, 76 insertions(+), 76 deletions(-)
diff --git a/drivers/iommu/shmobile-iommu.c b/drivers/iommu/shmobile-iommu.c
index 463da32..1a37be2 100644
--- a/drivers/iommu/shmobile-iommu.c
+++ b/drivers/iommu/shmobile-iommu.c
@@ -35,13 +35,13 @@
#define L2_LEN (L2_SIZE / 4)
#define L2_ALIGN L2_SIZE
-struct shmobile_iommu_priv_pgtable {
+struct shmobile_iommu_domain_pgtable {
uint32_t *pgtable;
dma_addr_t handle;
};
-struct shmobile_iommu_priv {
- struct shmobile_iommu_priv_pgtable l1, l2[L1_LEN];
+struct shmobile_iommu_domain {
+ struct shmobile_iommu_domain_pgtable l1, l2[L1_LEN];
spinlock_t map_lock;
atomic_t active;
};
@@ -51,64 +51,64 @@ static struct device *ipmmu_devices;
static struct dma_pool *l1pool, *l2pool;
static spinlock_t lock;
static DEFINE_SPINLOCK(lock_add);
-static struct shmobile_iommu_priv *attached;
+static struct shmobile_iommu_domain *attached;
static int num_attached_devices;
static struct device *ipmmu_access_device;
static int shmobile_iommu_domain_init(struct iommu_domain *domain)
{
- struct shmobile_iommu_priv *priv;
+ struct shmobile_iommu_domain *sh_domain;
int i;
- priv = kmalloc(sizeof(*priv), GFP_KERNEL);
- if (!priv)
+ sh_domain = kmalloc(sizeof(*sh_domain), GFP_KERNEL);
+ if (!sh_domain)
return -ENOMEM;
- priv->l1.pgtable = dma_pool_alloc(l1pool, GFP_KERNEL,
- &priv->l1.handle);
- if (!priv->l1.pgtable) {
- kfree(priv);
+ sh_domain->l1.pgtable = dma_pool_alloc(l1pool, GFP_KERNEL,
+ &sh_domain->l1.handle);
+ if (!sh_domain->l1.pgtable) {
+ kfree(sh_domain);
return -ENOMEM;
}
for (i = 0; i < L1_LEN; i++)
- priv->l2[i].pgtable = NULL;
- memset(priv->l1.pgtable, 0, L1_SIZE);
- spin_lock_init(&priv->map_lock);
- atomic_set(&priv->active, 0);
- domain->priv = priv;
+ sh_domain->l2[i].pgtable = NULL;
+ memset(sh_domain->l1.pgtable, 0, L1_SIZE);
+ spin_lock_init(&sh_domain->map_lock);
+ atomic_set(&sh_domain->active, 0);
+ domain->priv = sh_domain;
return 0;
}
static void shmobile_iommu_domain_destroy(struct iommu_domain *domain)
{
- struct shmobile_iommu_priv *priv = domain->priv;
+ struct shmobile_iommu_domain *sh_domain = domain->priv;
int i;
for (i = 0; i < L1_LEN; i++) {
- if (priv->l2[i].pgtable)
- dma_pool_free(l2pool, priv->l2[i].pgtable,
- priv->l2[i].handle);
+ if (sh_domain->l2[i].pgtable)
+ dma_pool_free(l2pool, sh_domain->l2[i].pgtable,
+ sh_domain->l2[i].handle);
}
- dma_pool_free(l1pool, priv->l1.pgtable, priv->l1.handle);
- kfree(priv);
+ dma_pool_free(l1pool, sh_domain->l1.pgtable, sh_domain->l1.handle);
+ kfree(sh_domain);
domain->priv = NULL;
}
static int shmobile_iommu_attach_device(struct iommu_domain *domain,
struct device *dev)
{
- struct shmobile_iommu_priv *priv = domain->priv;
+ struct shmobile_iommu_domain *sh_domain = domain->priv;
int ret = -EBUSY;
spin_lock(&lock);
- if (attached != priv) {
+ if (attached != sh_domain) {
if (attached)
goto err;
- atomic_set(&priv->active, 1);
- ipmmu_tlb_set(ipmmu_access_device, priv->l1.handle, L1_SIZE,
+ atomic_set(&sh_domain->active, 1);
+ ipmmu_tlb_set(ipmmu_access_device, sh_domain->l1.handle,
L1_SIZE,
0);
wmb();
ipmmu_tlb_flush(ipmmu_access_device);
- attached = priv;
+ attached = sh_domain;
num_attached_devices = 0;
}
num_attached_devices++;
@@ -121,10 +121,10 @@ err:
static void shmobile_iommu_detach_device(struct iommu_domain *domain,
struct device *dev)
{
- struct shmobile_iommu_priv *priv = domain->priv;
+ struct shmobile_iommu_domain *sh_domain = domain->priv;
spin_lock(&lock);
- atomic_set(&priv->active, 0);
+ atomic_set(&sh_domain->active, 0);
num_attached_devices--;
if (!num_attached_devices) {
ipmmu_tlb_set(ipmmu_access_device, 0, 0, 0);
@@ -135,34 +135,34 @@ static void shmobile_iommu_detach_device(struct
iommu_domain *domain,
}
static int
-l2alloc(struct shmobile_iommu_priv *priv, unsigned int l1index)
+l2alloc(struct shmobile_iommu_domain *sh_domain, unsigned int l1index)
{
-
[PATCH/WIP/RFC 05/14] ARM: iommu: Include linux/kref.h in asm/dma-iommu.h
The dma_iommu_mapping structure defined in asm/dma-iommu.h embeds a
struct kref, include the appropriate header file.
Signed-off-by: Laurent Pinchart
---
arch/arm/include/asm/dma-iommu.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/dma-iommu.h b/arch/arm/include/asm/dma-iommu.h
index 799b094..666d8a8 100644
--- a/arch/arm/include/asm/dma-iommu.h
+++ b/arch/arm/include/asm/dma-iommu.h
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
struct dma_iommu_mapping {
/* iommu specific data */
--
1.7.8.6
--
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/WIP/RFC 09/14] shmobile-ipmmu: Rename ipmmu_priv to shmobile_ipmmu
And expose the structure to the IOMMU driver.
Signed-off-by: Laurent Pinchart
---
drivers/iommu/shmobile-ipmmu.c | 14 --
drivers/iommu/shmobile-ipmmu.h |6 ++
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/shmobile-ipmmu.c b/drivers/iommu/shmobile-ipmmu.c
index 34e3c66..b308292 100644
--- a/drivers/iommu/shmobile-ipmmu.c
+++ b/drivers/iommu/shmobile-ipmmu.c
@@ -34,13 +34,7 @@
#define IMCTR1_TLBEN (1 << 0)
#define IMCTR1_FLUSH (1 << 1)
-struct ipmmu_priv {
- void __iomem *ipmmu_base;
- int tlb_enabled;
- struct mutex flush_lock;
-};
-
-static void ipmmu_reg_write(struct ipmmu_priv *priv, unsigned long reg_off,
+static void ipmmu_reg_write(struct shmobile_ipmmu *priv, unsigned long reg_off,
unsigned long data)
{
iowrite32(data, priv->ipmmu_base + reg_off);
@@ -48,7 +42,7 @@ static void ipmmu_reg_write(struct ipmmu_priv *priv, unsigned
long reg_off,
void ipmmu_tlb_flush(struct device *dev)
{
- struct ipmmu_priv *priv;
+ struct shmobile_ipmmu *priv;
if (!dev)
return;
@@ -63,7 +57,7 @@ void ipmmu_tlb_flush(struct device *dev)
void ipmmu_tlb_set(struct device *dev, unsigned long phys, int size, int asid)
{
- struct ipmmu_priv *priv;
+ struct shmobile_ipmmu *priv;
if (!dev)
return;
@@ -110,7 +104,7 @@ void ipmmu_tlb_set(struct device *dev, unsigned long phys,
int size, int asid)
static int ipmmu_probe(struct platform_device *pdev)
{
struct resource *res;
- struct ipmmu_priv *priv;
+ struct shmobile_ipmmu *priv;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
diff --git a/drivers/iommu/shmobile-ipmmu.h b/drivers/iommu/shmobile-ipmmu.h
index 0e0a6a4..5c17a46 100644
--- a/drivers/iommu/shmobile-ipmmu.h
+++ b/drivers/iommu/shmobile-ipmmu.h
@@ -1,6 +1,12 @@
#ifndef __SHMOBILE_IPMMU_H__
#define __SHMOBILE_IPMMU_H__
+struct shmobile_ipmmu {
+ void __iomem *ipmmu_base;
+ int tlb_enabled;
+ struct mutex flush_lock;
+};
+
#ifdef CONFIG_SHMOBILE_IPMMU_TLB
void ipmmu_tlb_flush(struct device *ipmmu_dev);
void ipmmu_tlb_set(struct device *ipmmu_dev, unsigned long phys, int size,
--
1.7.8.6
--
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/WIP/RFC 07/14] shmobile-iommu: Move header file from arch/ to drivers/iommu/
And split the function used by board code to its own
include/linux/sh_iommu.h header.
Signed-off-by: Laurent Pinchart
---
arch/arm/mach-shmobile/board-ap4evb.c |2 +-
arch/arm/mach-shmobile/board-mackerel.c|2 +-
arch/arm/mach-shmobile/setup-sh7372.c |2 +-
drivers/iommu/shmobile-iommu.c |4 +++-
drivers/iommu/shmobile-ipmmu.c |3 ++-
.../mach/ipmmu.h => drivers/iommu/shmobile-ipmmu.h |5 -
include/linux/sh_iommu.h | 12
7 files changed, 20 insertions(+), 10 deletions(-)
rename arch/arm/mach-shmobile/include/mach/ipmmu.h =>
drivers/iommu/shmobile-ipmmu.h (78%)
create mode 100644 include/linux/sh_iommu.h
diff --git a/arch/arm/mach-shmobile/board-ap4evb.c
b/arch/arm/mach-shmobile/board-ap4evb.c
index 7006abb..0c40d72 100644
--- a/arch/arm/mach-shmobile/board-ap4evb.c
+++ b/arch/arm/mach-shmobile/board-ap4evb.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -61,7 +62,6 @@
#include
#include
#include
-#include
#include
#include
diff --git a/arch/arm/mach-shmobile/board-mackerel.c
b/arch/arm/mach-shmobile/board-mackerel.c
index 1c34520..a9cdfc2 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -45,6 +45,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -60,7 +61,6 @@
#include
#include
#include
-#include
#include
#include
diff --git a/arch/arm/mach-shmobile/setup-sh7372.c
b/arch/arm/mach-shmobile/setup-sh7372.c
index aadb769..5dd3576 100644
--- a/arch/arm/mach-shmobile/setup-sh7372.c
+++ b/arch/arm/mach-shmobile/setup-sh7372.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -38,7 +39,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/drivers/iommu/shmobile-iommu.c b/drivers/iommu/shmobile-iommu.c
index 9f2243e3..463da32 100644
--- a/drivers/iommu/shmobile-iommu.c
+++ b/drivers/iommu/shmobile-iommu.c
@@ -23,8 +23,10 @@
#include
#include
#include
+#include
#include
-#include
+
+#include "shmobile-ipmmu.h"
#define L1_SIZE CONFIG_SHMOBILE_IOMMU_L1SIZE
#define L1_LEN (L1_SIZE / 4)
diff --git a/drivers/iommu/shmobile-ipmmu.c b/drivers/iommu/shmobile-ipmmu.c
index edec3b8..34e3c66 100644
--- a/drivers/iommu/shmobile-ipmmu.c
+++ b/drivers/iommu/shmobile-ipmmu.c
@@ -22,7 +22,8 @@
#include
#include
#include
-#include
+
+#include "shmobile-ipmmu.h"
#define IMCTR1 0x000
#define IMCTR2 0x004
diff --git a/arch/arm/mach-shmobile/include/mach/ipmmu.h
b/drivers/iommu/shmobile-ipmmu.h
similarity index 78%
rename from arch/arm/mach-shmobile/include/mach/ipmmu.h
rename to drivers/iommu/shmobile-ipmmu.h
index 4b805b1f..0e0a6a4 100644
--- a/arch/arm/mach-shmobile/include/mach/ipmmu.h
+++ b/drivers/iommu/shmobile-ipmmu.h
@@ -5,13 +5,8 @@
void ipmmu_tlb_flush(struct device *ipmmu_dev);
void ipmmu_tlb_set(struct device *ipmmu_dev, unsigned long phys, int size,
int asid);
-void ipmmu_add_device(struct device *dev);
int ipmmu_iommu_init(struct device *dev);
#else
-static inline void ipmmu_add_device(struct device *dev)
-{
-}
-
static int ipmmu_iommu_init(struct device *dev)
{
return -EINVAL;
diff --git a/include/linux/sh_iommu.h b/include/linux/sh_iommu.h
new file mode 100644
index 000..cc669a0
--- /dev/null
+++ b/include/linux/sh_iommu.h
@@ -0,0 +1,12 @@
+#ifndef __SH_IOMMU_H__
+#define __SH_IOMMU_H__
+
+#ifdef CONFIG_SHMOBILE_IPMMU_TLB
+void ipmmu_add_device(struct device *dev);
+#else
+static inline void ipmmu_add_device(struct device *dev)
+{
+}
+#endif
+
+#endif /* __SH_IOMMU_H__ */
--
1.7.8.6
--
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/WIP/RFC 04/14] shmobile-iommu: Use devm_* managed functions
Signed-off-by: Laurent Pinchart
---
drivers/iommu/shmobile-ipmmu.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/shmobile-ipmmu.c b/drivers/iommu/shmobile-ipmmu.c
index 2339f91..d6df0b4 100644
--- a/drivers/iommu/shmobile-ipmmu.c
+++ b/drivers/iommu/shmobile-ipmmu.c
@@ -116,16 +116,16 @@ static int ipmmu_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "cannot get platform resources\n");
return -ENOENT;
}
- priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
if (!priv) {
dev_err(&pdev->dev, "cannot allocate device data\n");
return -ENOMEM;
}
mutex_init(&priv->flush_lock);
- priv->ipmmu_base = ioremap_nocache(res->start, resource_size(res));
+ priv->ipmmu_base = devm_ioremap_nocache(&pdev->dev, res->start,
+ resource_size(res));
if (!priv->ipmmu_base) {
dev_err(&pdev->dev, "ioremap_nocache failed\n");
- kfree(priv);
return -ENOMEM;
}
platform_set_drvdata(pdev, priv);
--
1.7.8.6
--
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/WIP/RFC 03/14] shmobile-iommu: Remove __devinit
CONFIG_HOTPLUG is going away as an option, remove __devinit.
Signed-off-by: Laurent Pinchart
---
drivers/iommu/shmobile-ipmmu.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/iommu/shmobile-ipmmu.c b/drivers/iommu/shmobile-ipmmu.c
index 72cacb9..2339f91 100644
--- a/drivers/iommu/shmobile-ipmmu.c
+++ b/drivers/iommu/shmobile-ipmmu.c
@@ -106,7 +106,7 @@ void ipmmu_tlb_set(struct device *dev, unsigned long phys,
int size, int asid)
mutex_unlock(&priv->flush_lock);
}
-static int __devinit ipmmu_probe(struct platform_device *pdev)
+static int ipmmu_probe(struct platform_device *pdev)
{
struct resource *res;
struct ipmmu_priv *priv;
--
1.7.8.6
--
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/WIP/RFC 00/14] Renesas IPMMU driver work in progress
Dear Eiraku-san, Here's a couple of patches that rework your IPMMU driver in the direction pointed to by my comments. Feel free to use them as a base, squash them into your code (my name doesn't need to be kept in commit messages) or even ignore them completely where they make no sense. Patch 5/14 has been sent to the linux-arm-kernel mailing list already as it's an independent fix (but required by the next patches in the series). After these 14 patches I ran into the issue of matching devices with a particular IPMMU instance. This turned out to be more complex than I initially thought. There's currently no driver in mainline that performs that task, and I'm not sure whether the core infrastructure allows for doing so without resorting to hacks. The problem has been discussed very recently on the iommu list, you can find more information at http://patchwork.ozlabs.org/patch/203717/. No solution has been agreed on so far, maybe you could reply to the mail thread. Feel free to CC me. I'm unsure whether we should use a single ARM IOMMU mapping or one mapping per device. This needs to be investigated as there's little documentation on the subject. I would advice contacting Marek Szyprowski (the author of the ARM DMA IOMMU code) to discuss this matter. Once again feel free to CC me, as well as the appropriate mailing lists. In my opinion the shmobile_iommu_attach_all_devices() function should be removed, and devices should be attached with an IOMMU either as they are added to the system, or as they are probed. Bus notifiers might be usable to achieve that, as implemented in the above Tegra SMMU patch. This requires the IOMMU being registered and fully operational at attachment time, so explicit IOMMU attachment in driver code might be a better solution for now. That would likely require one ARM DMA IOMMU mapping per device, device drivers would explicitly call arm_iommu_create_mapping() and arm_iommu_attach_device(). Laurent Pinchart (14): ARM: sh-mobile: Protect ipmmu.h header with ifndef/define shmobile-iommu: Move IPMMU driver to drivers/iommu shmobile-iommu: Remove __devinit shmobile-iommu: Use devm_* managed functions ARM: iommu: Include linux/kref.h in asm/dma-iommu.h shmobile-iommu: Sort header files alphabetically shmobile-iommu: Move header file from arch/ to drivers/iommu/ shmobile-iommu: Rename shmobile_iommu_priv to shmobile_iommu_domain shmobile-ipmmu: Rename ipmmu_priv to shmobile_ipmmu shmobile-ipmmu: Pass a struct shmobile_ipmmu to IPMMU functions shmobile-ipmmu: Store a struct shmobile_iommu_arch_data in archdata.iommu shmobile-ipmmu: Store ipmmu pointer in iommu arch data and iommu domain shmobile-ipmmu: Remove unneeded lock_add spinlock shmobile-ipmmu: Store iommu_mapping in struct shmobile_ipmmu arch/arm/include/asm/dma-iommu.h |1 + arch/arm/mach-shmobile/Kconfig |6 - arch/arm/mach-shmobile/Makefile|3 - arch/arm/mach-shmobile/board-ap4evb.c |2 +- arch/arm/mach-shmobile/board-mackerel.c|2 +- arch/arm/mach-shmobile/include/mach/ipmmu.h| 16 -- arch/arm/mach-shmobile/setup-sh7372.c |2 +- drivers/iommu/Kconfig |6 + drivers/iommu/Makefile |1 + drivers/iommu/shmobile-iommu.c | 259 +++- .../ipmmu.c => drivers/iommu/shmobile-ipmmu.c | 107 - drivers/iommu/shmobile-ipmmu.h | 27 ++ include/linux/sh_iommu.h | 20 ++ 13 files changed, 248 insertions(+), 204 deletions(-) delete mode 100644 arch/arm/mach-shmobile/include/mach/ipmmu.h rename arch/arm/mach-shmobile/ipmmu.c => drivers/iommu/shmobile-ipmmu.c (51%) create mode 100644 drivers/iommu/shmobile-ipmmu.h create mode 100644 include/linux/sh_iommu.h -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH/WIP/RFC 02/14] shmobile-iommu: Move IPMMU driver to drivers/iommu
Signed-off-by: Laurent Pinchart --- arch/arm/mach-shmobile/Kconfig |6 -- arch/arm/mach-shmobile/Makefile|3 --- drivers/iommu/Kconfig |6 ++ drivers/iommu/Makefile |1 + .../ipmmu.c => drivers/iommu/shmobile-ipmmu.c |0 5 files changed, 7 insertions(+), 9 deletions(-) rename arch/arm/mach-shmobile/ipmmu.c => drivers/iommu/shmobile-ipmmu.c (100%) diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig index de69ab3..8ae100c 100644 --- a/arch/arm/mach-shmobile/Kconfig +++ b/arch/arm/mach-shmobile/Kconfig @@ -210,12 +210,6 @@ endmenu config SH_CLK_CPG bool -config SHMOBILE_IPMMU - bool - -config SHMOBILE_IPMMU_TLB - bool - source "drivers/sh/Kconfig" endif diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile index 4ffba9d..fe2c97c 100644 --- a/arch/arm/mach-shmobile/Makefile +++ b/arch/arm/mach-shmobile/Makefile @@ -60,6 +60,3 @@ obj-$(CONFIG_MACH_KZM9G) += board-kzm9g.o # Framework support obj-$(CONFIG_SMP) += $(smp-y) obj-$(CONFIG_GENERIC_GPIO) += $(pfc-y) - -# IPMMU/IPMMUI -obj-$(CONFIG_SHMOBILE_IPMMU) += ipmmu.o diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index 265829f..cb2a3e8 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -187,6 +187,12 @@ config EXYNOS_IOMMU_DEBUG Say N unless you need kernel log message for IOMMU debugging +config SHMOBILE_IPMMU + bool + +config SHMOBILE_IPMMU_TLB + bool + config SHMOBILE_IOMMU bool "IOMMU for Renesas IPMMU/IPMMUI" default n diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile index 62cf917..e65384f 100644 --- a/drivers/iommu/Makefile +++ b/drivers/iommu/Makefile @@ -13,3 +13,4 @@ obj-$(CONFIG_TEGRA_IOMMU_GART) += tegra-gart.o obj-$(CONFIG_TEGRA_IOMMU_SMMU) += tegra-smmu.o obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o obj-$(CONFIG_SHMOBILE_IOMMU) += shmobile-iommu.o +obj-$(CONFIG_SHMOBILE_IPMMU) += shmobile-ipmmu.o diff --git a/arch/arm/mach-shmobile/ipmmu.c b/drivers/iommu/shmobile-ipmmu.c similarity index 100% rename from arch/arm/mach-shmobile/ipmmu.c rename to drivers/iommu/shmobile-ipmmu.c -- 1.7.8.6 -- 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/6] ACPI: Simplify namespace scanning for devices
On Sun, Dec 16, 2012 at 5:47 AM, Rafael J. Wysocki wrote: > Hi All, > > This series is on top of the one I sent on Thursday: > > https://lkml.org/lkml/2012/12/13/632 > > It goes one step farther and makes some simplifications that become possible > after applying that patchset. > > [1/6] Fold acpi_pci_root_start() into acpi_pci_root_add() > [2/6] Remove acpi_start_single_object() and acpi_bus_start() > [3/6] Remove the arguments of acpi_bus_add() that are not used > [4/6] Drop the second argument of acpi_bus_scan() > [5/6] Replace ACPI device add_type field with a match_driver flag > [6/6] Make acpi_bus_scan() and acpi_bus_add() take only one argument > > It survives booting on Toshiba Portege R500 without any visible issues. Do you have git branch that i could test? I'd like to rebase for-pci-root-bus-hotplug patches, so what should be base? It would be hard for me to base on your acpi tree and Bjorn's pci tree. Thanks Yinghai -- 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: 3.8.0-rc0 on xen-unstable: RCU Stall during boot as dom0 kernel after IOAPIC
On Fri, Dec 14, 2012 at 04:55:57PM +0100, Sander Eikelenboom wrote: > Hi Konrad, > > I just tried to boot a 3.8.0-rc0 kernel (last commit: > 7313264b899bbf3988841296265a6e0e8a7b6521) as dom0 on my machine with current > xen-unstable. Yeah, saw it over the Dec 11->Dec 12 merges and was out on vacation during that time (just got back). Did you by any chance try to do a git bisect to narrow down which merge it was? Thanks! > The boot stalls: > > [0.00] ACPI: PM-Timer IO Port: 0x808 > [0.00] ACPI: Local APIC address 0xfee0 > [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) > [0.00] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) > [0.00] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) > [0.00] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) > [0.00] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled) > [0.00] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] enabled) > [0.00] ACPI: IOAPIC (id[0x06] address[0xfec0] gsi_base[0]) > [0.00] IOAPIC[0]: apic_id 6, version 33, address 0xfec0, GSI 0-23 > [0.00] ACPI: IOAPIC (id[0x07] address[0xfec2] gsi_base[24]) > [0.00] IOAPIC[1]: apic_id 7, version 33, address 0xfec2, GSI 24- > [ 64.598628] INFO: rcu_preempt detected stalls on CPUs/tasks: > [ 64.598676] 0: (1 GPs behind) idle=aed/140/0 drain=5 . timer > not pending > [ 64.598683] (detected by 1, t=18004 jiffies, g=18446744073709551414, > c=18446744073709551413, q=162) > [ 64.598692] sending NMI to all CPUs: > [ 64.598716] xen: vector 0x2 is not implemented > > > Perhaps an interesting line is the incomplete (no end of range, and it stalls > there some time before the kernel reports the stall itself: > [0.00] IOAPIC[1]: apic_id 7, version 33, address 0xfec2, GSI 24- > > > The exact seem config with 3.7.0 as kernel works fine. > Complete serial log is attached. > > -- > > Sander > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] asm-generic/dma-mapping-broken.h: Provide dma_alloc_attrs()/dma_free_attrs()
Since commit 0049fb2603b7afb1080776ee691dfa5a3d282357 ("OMAPFB: use
dma_alloc_attrs to allocate memory") we have one non-arch user of
dma_{alloc,free}_attrs().
Hence provide these functions, as wrappers around
dma_{alloc,free}_coherent().
Note that most architectures do it the other way around. But as these are
dummy functions, we don't care.
Signed-off-by: Geert Uytterhoeven
---
include/asm-generic/dma-mapping-broken.h | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/include/asm-generic/dma-mapping-broken.h
b/include/asm-generic/dma-mapping-broken.h
index ccf7b4f..6c32af9 100644
--- a/include/asm-generic/dma-mapping-broken.h
+++ b/include/asm-generic/dma-mapping-broken.h
@@ -16,6 +16,22 @@ extern void
dma_free_coherent(struct device *dev, size_t size, void *cpu_addr,
dma_addr_t dma_handle);
+static inline void *dma_alloc_attrs(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t flag,
+ struct dma_attrs *attrs)
+{
+ /* attrs is not supported and ignored */
+ return dma_alloc_coherent(dev, size, dma_handle, flag);
+}
+
+static inline void dma_free_attrs(struct device *dev, size_t size,
+ void *cpu_addr, dma_addr_t dma_handle,
+ struct dma_attrs *attrs)
+{
+ /* attrs is not supported and ignored */
+ dma_free_coherent(dev, size, cpu_addr, dma_handle);
+}
+
#define dma_alloc_noncoherent(d, s, h, f) dma_alloc_coherent(d, s, h, f)
#define dma_free_noncoherent(d, s, v, h) dma_free_coherent(d, s, v, h)
--
1.7.0.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 1/2] m68k: Provide dma_alloc_attrs()/dma_free_attrs()
Since commit 0049fb2603b7afb1080776ee691dfa5a3d282357 ("OMAPFB: use
dma_alloc_attrs to allocate memory") we have one non-arch user of
dma_{alloc,free}_attrs().
Hence provide these functions, as wrappers around
dma_{alloc,free}_coherent().
Note that most architectures do it the other way around. But as so far
m68k doesn't support the attributes at all, our solution should generate
smaller code.
Signed-off-by: Geert Uytterhoeven
---
arch/m68k/include/asm/dma-mapping.h | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/m68k/include/asm/dma-mapping.h
b/arch/m68k/include/asm/dma-mapping.h
index 17f7a45..3e6b844 100644
--- a/arch/m68k/include/asm/dma-mapping.h
+++ b/arch/m68k/include/asm/dma-mapping.h
@@ -21,6 +21,22 @@ extern void *dma_alloc_coherent(struct device *, size_t,
extern void dma_free_coherent(struct device *, size_t,
void *, dma_addr_t);
+static inline void *dma_alloc_attrs(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t flag,
+ struct dma_attrs *attrs)
+{
+ /* attrs is not supported and ignored */
+ return dma_alloc_coherent(dev, size, dma_handle, flag);
+}
+
+static inline void dma_free_attrs(struct device *dev, size_t size,
+ void *cpu_addr, dma_addr_t dma_handle,
+ struct dma_attrs *attrs)
+{
+ /* attrs is not supported and ignored */
+ dma_free_coherent(dev, size, cpu_addr, dma_handle);
+}
+
static inline void *dma_alloc_noncoherent(struct device *dev, size_t size,
dma_addr_t *handle, gfp_t flag)
{
--
1.7.0.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/
[GIT PULL] (swiotlb) stable/for-linus-3.8-rc0-tag
Hey Linus, Please git pull the following tag: git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git stable/for-linus-3.8-rc0-tag which has one feature in the SWIOTLB code. That is to remove the multitude of phys_to_virt/virt_to_phys calls and instead operate on the physical addresses instead of virtual in many of the internal functions. This does provide a speed up in interrupt handlers that do DMA operations and use SWIOTLB. Please pull! drivers/xen/swiotlb-xen.c | 25 ++-- include/linux/swiotlb.h | 20 ++-- lib/swiotlb.c | 269 +++-- 3 files changed, 163 insertions(+), 151 deletions(-) Alexander Duyck (7): swiotlb: Make io_tlb_end a physical address instead of a virtual one swiotlb: Make io_tlb_start a physical address instead of a virtual one swiotlb: Make io_tlb_overflow_buffer a physical address swiotlb: Return physical addresses when calling swiotlb_tbl_map_single swiotlb: Use physical addresses for swiotlb_tbl_unmap_single swiotlb: Use physical addresses instead of virtual in swiotlb_tbl_sync_single swiotlb: Do not export swiotlb_bounce since there are no external consumers -- 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: [regression] 3.7 ends in APIC panic
On Fri, Dec 14, 2012 at 6:58 AM, Bernd Schubert wrote: > On 12/13/2012 01:16 PM, Bernd Schubert wrote: >> >> Hello, >> >> I just tried to boot 3.7 and it ends in an APIC panic. I tried to use >> the recommended "apic=debug", but that does not change anything in the >> output, at least not in the visible part. The last known kernel to boot >> was 3.5. If it matters I can try to boot 3.6. > > > So linux-3.6 also boots. Any idea what is going on or do I really need to > bisect? interesting, your system have x2apic enabled by BIOS, switching to x2apic ops so can you try to append "nox2apic" to command line with v3.7, to see if we can get dmesg there? Thanks Yinghai -- 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: [regression] 3.7 ends in APIC panic
On Sun, Dec 16, 2012 at 9:43 AM, Yinghai Lu wrote: > On Fri, Dec 14, 2012 at 6:58 AM, Bernd Schubert > wrote: >> On 12/13/2012 01:16 PM, Bernd Schubert wrote: >>> >>> Hello, >>> >>> I just tried to boot 3.7 and it ends in an APIC panic. I tried to use >>> the recommended "apic=debug", but that does not change anything in the >>> output, at least not in the visible part. The last known kernel to boot >>> was 3.5. If it matters I can try to boot 3.6. >> >> >> So linux-3.6 also boots. Any idea what is going on or do I really need to >> bisect? > > interesting, your system have > > x2apic enabled by BIOS, switching to x2apic ops > > so can you try to append "nox2apic" to command line with v3.7, to see > if we can get dmesg there? can you post your .config for v3.7 ? wonder if you have x2apic in .config Thanks Yinghai -- 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 v3 03/10] x86/common.c: Make have_cpuid_p() a global function
From: Fenghua Yu
Remove static declaration in have_cpuid_p() to make it a global function. The
function will be called in early loading microcode.
Signed-off-by: Fenghua Yu
---
arch/x86/include/asm/processor.h | 8
arch/x86/kernel/cpu/common.c | 17 +++--
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 888184b..3d722fd 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -190,6 +190,14 @@ extern void init_amd_cacheinfo(struct cpuinfo_x86 *c);
extern void detect_extended_topology(struct cpuinfo_x86 *c);
extern void detect_ht(struct cpuinfo_x86 *c);
+#ifdef CONFIG_X86_32
+extern int have_cpuid_p(void);
+#else
+static inline int have_cpuid_p(void)
+{
+ return 1;
+}
+#endif
static inline void native_cpuid(unsigned int *eax, unsigned int *ebx,
unsigned int *ecx, unsigned int *edx)
{
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 9c3ab43..d814772 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -37,6 +37,8 @@
#include
#include
#include
+#include
+#include
#ifdef CONFIG_X86_LOCAL_APIC
#include
@@ -213,7 +215,7 @@ static inline int flag_is_changeable_p(u32 flag)
}
/* Probe for the CPUID instruction */
-static int __cpuinit have_cpuid_p(void)
+int __cpuinit have_cpuid_p(void)
{
return flag_is_changeable_p(X86_EFLAGS_ID);
}
@@ -249,11 +251,6 @@ static inline int flag_is_changeable_p(u32 flag)
{
return 1;
}
-/* Probe for the CPUID instruction */
-static inline int have_cpuid_p(void)
-{
- return 1;
-}
static inline void squash_the_stupid_serial_number(struct cpuinfo_x86 *c)
{
}
@@ -1223,6 +1220,12 @@ void __cpuinit cpu_init(void)
int cpu;
int i;
+ /*
+* Load microcode on this cpu if a valid microcode is available.
+* This is early microcode loading procedure.
+*/
+ load_ucode_ap();
+
cpu = stack_smp_processor_id();
t = &per_cpu(init_tss, cpu);
oist = &per_cpu(orig_ist, cpu);
@@ -1314,6 +1317,8 @@ void __cpuinit cpu_init(void)
struct tss_struct *t = &per_cpu(init_tss, cpu);
struct thread_struct *thread = &curr->thread;
+ show_ucode_info_early();
+
if (cpumask_test_and_set_cpu(cpu, cpu_initialized_mask)) {
printk(KERN_WARNING "CPU#%d already initialized!\n", cpu);
for (;;)
--
1.8.0.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 00/10] x86/microcode: Early load microcode
From: Fenghua Yu The problem in current microcode loading method is that we load a microcode way, way too late; ideally we should load it before turning paging on. This may only be practical on 32 bits since we can't get to 64-bit mode without paging on, but we should still do it as early as at all possible. Similarly, we should load the microcode update as early as possible during AP bringup and when processors are brought back online after hotplug or S3/S4. In order to do that, the microcode patch needs to be permanently present in kernel memory. Each individual patch is fairly small, so that is OK, but the entire blob with support for each CPU is too big. Since only CPU's with same model can be in the same platform, we store microcode with the same model as BSP. Later on APs can upload microcode from the saved microcodep patches. Note, however, that Linux users have gotten used to being able to install a microcode patch in the field without having a reboot; we support that model too. v3: Change .hex to .bin in 01/10 and 05/10 patches. Fix some compilation warnings. In x86_32 mode, access global varialbes by __pa_symobl() and fix static string issue in x86_vendor(). Call load_ucode_ap() in real mode as well. Add debug info. v2: Detect vendor before loading microcode. Move some functions from microcode_intel_early.c to microcode_intel_lib.c. Change some early loading microcode dependencies in Kconfig. Reword doc. Fenghua Yu (10): Documentation/x86: Early load microcode x86/microcode_intel.h: Define functions and macros for early loading ucode x86/common.c: Make have_cpuid_p() a global function x86/microcode_core_early.c: Define interfaces for early loading ucode x86/microcode_intel_lib.c: Early update ucode on Intel's CPU x86/microcode_intel_early.c: Early update ucode on Intel's CPU x86/head_32.S: Early update ucode in 32-bit x86/head64.c: Early update ucode in 64-bit x86/mm/init.c: Copy ucode from initrd image to memory x86/Kconfig: Configurations to enable/disable the feature Documentation/x86/early-microcode.txt | 43 ++ arch/x86/Kconfig| 18 + arch/x86/include/asm/microcode.h| 11 + arch/x86/include/asm/microcode_intel.h | 82 arch/x86/include/asm/processor.h| 8 + arch/x86/kernel/Makefile| 3 + arch/x86/kernel/cpu/common.c| 17 +- arch/x86/kernel/head64.c| 6 + arch/x86/kernel/head_32.S | 12 + arch/x86/kernel/microcode_core.c| 7 +- arch/x86/kernel/microcode_core_early.c | 77 arch/x86/kernel/microcode_intel.c | 198 ++-- arch/x86/kernel/microcode_intel_early.c | 775 arch/x86/kernel/microcode_intel_lib.c | 174 +++ arch/x86/mm/init.c | 10 + 15 files changed, 1264 insertions(+), 177 deletions(-) create mode 100644 Documentation/x86/early-microcode.txt create mode 100644 arch/x86/include/asm/microcode_intel.h create mode 100644 arch/x86/kernel/microcode_core_early.c create mode 100644 arch/x86/kernel/microcode_intel_early.c create mode 100644 arch/x86/kernel/microcode_intel_lib.c -- 1.8.0.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 09/10] x86/mm/init.c: Copy ucode from initrd image to memory
From: Fenghua Yu
Before initrd image is freed, copy valid ucode patches from initrd image
to kernel virtual memory. The saved ucode will be used to update AP in resume
or hotplug.
Signed-off-by: Fenghua Yu
---
arch/x86/mm/init.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index d7aea41..e5e7973 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -16,6 +16,7 @@
#include
#include
#include/* for MAX_DMA_PFN */
+#include
unsigned long __initdata pgt_buf_start;
unsigned long __meminitdata pgt_buf_end;
@@ -391,6 +392,15 @@ void free_initmem(void)
#ifdef CONFIG_BLK_DEV_INITRD
void __init free_initrd_mem(unsigned long start, unsigned long end)
{
+#ifdef CONFIG_MICROCODE_EARLY
+ /*
+* Remember, initrd memory may contain microcode or other useful things.
+* Before we lose initrd mem, we need to find a place to hold them
+* now that normal virtual memory is enabled.
+*/
+ save_microcode_in_initrd();
+#endif
+
/*
* end could be not aligned, and We can not align that,
* decompresser could be confused by aligned initrd_end
--
1.8.0.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] fbdev changes for 3.8
* Dave Jones [121215 14:27]: > On Sat, Dec 15, 2012 at 01:11:04PM -0800, Linus Torvalds wrote: > > On Fri, Dec 14, 2012 at 2:22 AM, Tomi Valkeinen > wrote: > > > Hi Linus, > > > > > > Florian, the fbdev maintainer, has been very busy lately, so I offered > to send > > > the pull request for fbdev for this merge window. > > > > Pulled. However, with this I get the Kconfig question > > > >OMAP2+ Display Subsystem support (OMAP2_DSS) [N/m/y/?] (NEW) > > > > which doesn't make a whole lot of sense on x86-64, unless there's > > something about OMAP2 that I don't know. > > > > So I'd suggest making that OMAP2_DSS be dependent on OMAP2. Or at > > least ARM. Because showing it to anybody else seems insane. > > > > Same goes for FB_OMAP2 for that matter. I realize that it's likely > > nice to get compile testing for this on x86-64 too, but if that's the > > intent, we need to think about it some more. I don't think it's good > > to ask actual normal users questions like this just for compile > > coverage. > > This OMAP stuff has been creeping into x86 builds for a while. > Grep from my current build config .. > > # CONFIG_OMAP_OCP2SCP is not set > # CONFIG_KEYBOARD_OMAP4 is not set > # CONFIG_OMAP2_DSS is not set > # CONFIG_OMAP_USB2 is not set > > There was some other arm-ism that does the same that I' currently forgetting, > or maybe that got fixed.. Those are all omap internal devices and should be all marked with depends on ARCH_OMAP2PLUS. It's a different story for external devices that may be used on other architectures. I only came up with one reason to compile internal devices for other architectures: In some cases the driver subsystem maintainer may want to be able to compile test subsystem wide changes without having to compile for each target separately. But for those cases it's trivial to carry a compile test patch that just drops the depends Kconfig entries. 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/
[PATCH v3 10/10] x86/Kconfig: Configurations to enable/disable the feature
From: Fenghua Yu MICROCODE_INTEL_LIB, MICROCODE_INTEL_EARLY, and MICROCODE_EARLY are three new configurations to enable or disable the feature. Signed-off-by: Fenghua Yu --- arch/x86/Kconfig | 18 ++ 1 file changed, 18 insertions(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 65a872b..edf6fd2 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1028,6 +1028,24 @@ config MICROCODE_OLD_INTERFACE def_bool y depends on MICROCODE +config MICROCODE_INTEL_LIB + def_bool y + depends on MICROCODE_INTEL + +config MICROCODE_INTEL_EARLY + bool "Early load microcode" + depends on MICROCODE_INTEL && BLK_DEV_INITRD + default y + help + This option provides functionality to read additional microcode data + at the beginning of initrd image. The data tells kernel to load + microcode to CPU's as early as possible. No functional change if no + microcode data is glued to the initrd, therefore it's safe to say Y. + +config MICROCODE_EARLY + def_bool y + depends on MICROCODE_INTEL_EARLY + config X86_MSR tristate "/dev/cpu/*/msr - Model-specific register support" ---help--- -- 1.8.0.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 07/10] x86/head_32.S: Early update ucode in 32-bit
From: Fenghua Yu This updates ucode in 32-bit kernel. At this point, there is no paging and no virtual address yet. Signed-off-by: Fenghua Yu --- arch/x86/kernel/head_32.S | 12 1 file changed, 12 insertions(+) diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S index 8e7f655..fdc11f6 100644 --- a/arch/x86/kernel/head_32.S +++ b/arch/x86/kernel/head_32.S @@ -144,6 +144,12 @@ ENTRY(startup_32) movl %eax, pa(olpc_ofw_pgd) #endif +#ifdef CONFIG_MICROCODE_EARLY + /* Early load ucode on BSP. */ + movl $pa(boot_params), %eax + call load_ucode_bsp +#endif + /* * Initialize page tables. This creates a PDE and a set of page * tables, which are located immediately beyond __brk_base. The variable @@ -299,6 +305,12 @@ ENTRY(startup_32_smp) movl %eax,%ss leal -__PAGE_OFFSET(%ecx),%esp +#ifdef CONFIG_MICROCODE_EARLY + /* Early load ucode on AP. */ + call load_ucode_ap +#endif + + default_entry: /* * New page tables may be in 4Mbyte page mode and may -- 1.8.0.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 05/10] x86/microcode_intel_lib.c: Early update ucode on Intel's CPU
From: Fenghua Yu
Define interfaces microcode_sanity_check() and get_matching_microcode(). They
are called both in early boot time and in microcode Intel driver.
Signed-off-by: Fenghua Yu
---
arch/x86/kernel/microcode_intel_lib.c | 174 ++
1 file changed, 174 insertions(+)
create mode 100644 arch/x86/kernel/microcode_intel_lib.c
diff --git a/arch/x86/kernel/microcode_intel_lib.c
b/arch/x86/kernel/microcode_intel_lib.c
new file mode 100644
index 000..ce69320
--- /dev/null
+++ b/arch/x86/kernel/microcode_intel_lib.c
@@ -0,0 +1,174 @@
+/*
+ * Intel CPU Microcode Update Driver for Linux
+ *
+ * Copyright (C) 2012 Fenghua Yu
+ *H Peter Anvin"
+ *
+ * This driver allows to upgrade microcode on Intel processors
+ * belonging to IA-32 family - PentiumPro, Pentium II,
+ * Pentium III, Xeon, Pentium 4, etc.
+ *
+ * Reference: Section 8.11 of Volume 3a, IA-32 Intel? Architecture
+ * Software Developer's Manual
+ * Order Number 253668 or free download from:
+ *
+ * http://developer.intel.com/Assets/PDF/manual/253668.pdf
+ *
+ * For more information, go to http://www.urbanmyth.org/microcode
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ */
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static inline int
+update_match_cpu(unsigned int csig, unsigned int cpf,
+unsigned int sig, unsigned int pf)
+{
+ return (!sigmatch(sig, csig, pf, cpf)) ? 0 : 1;
+}
+
+int
+update_match_revision(struct microcode_header_intel *mc_header, int rev)
+{
+ return (mc_header->rev <= rev) ? 0 : 1;
+}
+
+int microcode_sanity_check(void *mc, int print_err)
+{
+ unsigned long total_size, data_size, ext_table_size;
+ struct microcode_header_intel *mc_header = mc;
+ struct extended_sigtable *ext_header = NULL;
+ int sum, orig_sum, ext_sigcount = 0, i;
+ struct extended_signature *ext_sig;
+
+ total_size = get_totalsize(mc_header);
+ data_size = get_datasize(mc_header);
+
+ if (data_size + MC_HEADER_SIZE > total_size) {
+ if (print_err)
+ pr_err("error! Bad data size in microcode data file\n");
+ return -EINVAL;
+ }
+
+ if (mc_header->ldrver != 1 || mc_header->hdrver != 1) {
+ if (print_err)
+ pr_err("error! Unknown microcode update format\n");
+ return -EINVAL;
+ }
+ ext_table_size = total_size - (MC_HEADER_SIZE + data_size);
+ if (ext_table_size) {
+ if ((ext_table_size < EXT_HEADER_SIZE)
+|| ((ext_table_size - EXT_HEADER_SIZE) % EXT_SIGNATURE_SIZE)) {
+ if (print_err)
+ pr_err("error! Small exttable size in microcode
data file\n");
+ return -EINVAL;
+ }
+ ext_header = mc + MC_HEADER_SIZE + data_size;
+ if (ext_table_size != exttable_size(ext_header)) {
+ if (print_err)
+ pr_err("error! Bad exttable size in microcode
data file\n");
+ return -EFAULT;
+ }
+ ext_sigcount = ext_header->count;
+ }
+
+ /* check extended table checksum */
+ if (ext_table_size) {
+ int ext_table_sum = 0;
+ int *ext_tablep = (int *)ext_header;
+
+ i = ext_table_size / DWSIZE;
+ while (i--)
+ ext_table_sum += ext_tablep[i];
+ if (ext_table_sum) {
+ if (print_err)
+ pr_warn("aborting, bad extended signature table
checksum\n");
+ return -EINVAL;
+ }
+ }
+
+ /* calculate the checksum */
+ orig_sum = 0;
+ i = (MC_HEADER_SIZE + data_size) / DWSIZE;
+ while (i--)
+ orig_sum += ((int *)mc)[i];
+ if (orig_sum) {
+ if (print_err)
+ pr_err("aborting, bad checksum\n");
+ return -EINVAL;
+ }
+ if (!ext_table_size)
+ return 0;
+ /* check extended signature checksum */
+ for (i = 0; i < ext_sigcount; i++) {
+ ext_sig = (void *)ext_header + EXT_HEADER_SIZE +
+ EXT_SIGNATURE_SIZE * i;
+ sum = orig_sum
+ - (mc_header->sig + mc_header->pf + mc_header->cksum)
+ + (ext_sig->sig + ext_sig->pf + ext_sig->cksum);
+ if (sum) {
+ if (print_err)
+ pr_err("aborting, bad checksum\n");
+
[PATCH v3 01/10] Documentation/x86: Early load microcode
From: Fenghua Yu Documenation for early loading microcode methodology. Signed-off-by: Fenghua Yu --- Documentation/x86/early-microcode.txt | 43 +++ 1 file changed, 43 insertions(+) create mode 100644 Documentation/x86/early-microcode.txt diff --git a/Documentation/x86/early-microcode.txt b/Documentation/x86/early-microcode.txt new file mode 100644 index 000..4aaf0df --- /dev/null +++ b/Documentation/x86/early-microcode.txt @@ -0,0 +1,43 @@ +Early load microcode + +By Fenghua Yu + +Kernel can update microcode in early phase of boot time. Loading microcode early +can fix CPU issues before they are observed during kernel boot time. + +Microcode is stored in an initrd file. The microcode is read from the initrd +file and loaded to CPUs during boot time. + +The format of the combined initrd image is microcode in cpio format followed by +the initrd image (maybe compressed). Kernel parses the combined initrd image +during boot time. The microcode file in cpio name space is: +kernel/x86/microcode/GenuineIntel.bin + +During BSP boot (before SMP starts), if the kernel finds the microcode file in +the initrd file, it parses the microcode and saves matching microcode in memory. +If matching microcode is found, it will be uploaded in BSP and later on in all +APs. + +The cached microcode patch is applied when CPUs resume from a sleep state. + +There are two legacy user space interfaces to load microcode, either through +/dev/cpu/microcode or through /sys/devices/system/cpu/microcode/reload file +in sysfs. + +In addition to these two legacy methods, the early loading method described +here is the third method with which microcode can be uploaded to a system's +CPUs. + +The following example script shows how to generate a new combined initrd file in +/boot/initrd-3.5.0.ucode.img with original microcode microcode.bin and +original initrd image /boot/initrd-3.5.0.img. + +mkdir initrd +cd initrd +mkdir kernel +mkdir kernel/x86 +mkdir kernel/x86/microcode +cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin +find .|cpio -oc >../ucode.cpio +cd .. +cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img -- 1.8.0.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 06/10] x86/microcode_intel_early.c: Early update ucode on Intel's CPU
From: Fenghua Yu
Implementation of early update ucode on Intel's CPU.
load_ucode_intel_bsp() scans ucode in initrd image file which is a cpio format
ucode followed by ordinary initrd image file. The binary ucode file is stored
in kernel/x86/microcode/GenuineIntel.bin in the cpio data. All ucode
patches with the same model as BSP are saved in memory. A matching ucode patch
is updated on BSP.
load_ucode_intel_ap() reads saved ucoded patches and updates ucode on AP.
Signed-off-by: Fenghua Yu
---
arch/x86/kernel/microcode_intel_early.c | 775
1 file changed, 775 insertions(+)
create mode 100644 arch/x86/kernel/microcode_intel_early.c
diff --git a/arch/x86/kernel/microcode_intel_early.c
b/arch/x86/kernel/microcode_intel_early.c
new file mode 100644
index 000..6a8e04b
--- /dev/null
+++ b/arch/x86/kernel/microcode_intel_early.c
@@ -0,0 +1,775 @@
+/*
+ * Intel CPU microcode early update for Linux
+ *
+ * Copyright (C) 2012 Fenghua Yu
+ *H Peter Anvin"
+ *
+ * This allows to early upgrade microcode on Intel processors
+ * belonging to IA-32 family - PentiumPro, Pentium II,
+ * Pentium III, Xeon, Pentium 4, etc.
+ *
+ * Reference: Section 9.11 of Volume 3, IA-32 Intel Architecture
+ * Software Developer's Manual.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+unsigned long mc_saved_in_initrd[MAX_UCODE_COUNT];
+struct mc_saved_data {
+ unsigned int mc_saved_count;
+ struct microcode_intel **mc_saved;
+} mc_saved_data;
+
+static enum ucode_state __cpuinit
+generic_load_microcode_early(struct microcode_intel **mc_saved_p,
+unsigned int mc_saved_count,
+struct ucode_cpu_info *uci)
+{
+ struct microcode_intel *ucode_ptr, *new_mc = NULL;
+ int new_rev = uci->cpu_sig.rev;
+ enum ucode_state state = UCODE_OK;
+ unsigned int mc_size;
+ struct microcode_header_intel *mc_header;
+ unsigned int csig = uci->cpu_sig.sig;
+ unsigned int cpf = uci->cpu_sig.pf;
+ int i;
+
+ for (i = 0; i < mc_saved_count; i++) {
+ ucode_ptr = mc_saved_p[i];
+
+ mc_header = (struct microcode_header_intel *)ucode_ptr;
+ mc_size = get_totalsize(mc_header);
+ if (get_matching_microcode(csig, cpf, ucode_ptr, new_rev)) {
+ new_rev = mc_header->rev;
+ new_mc = ucode_ptr;
+ }
+ }
+
+ if (!new_mc) {
+ state = UCODE_NFOUND;
+ goto out;
+ }
+
+ uci->mc = (struct microcode_intel *)new_mc;
+out:
+ return state;
+}
+
+static void __cpuinit
+microcode_pointer(struct microcode_intel **mc_saved,
+ unsigned long *mc_saved_in_initrd,
+ unsigned long initrd_start, int mc_saved_count)
+{
+ int i;
+
+ for (i = 0; i < mc_saved_count; i++)
+ mc_saved[i] = (struct microcode_intel *)
+ (mc_saved_in_initrd[i] + initrd_start);
+}
+
+#ifdef CONFIG_X86_32
+static void __cpuinit
+microcode_phys(struct microcode_intel **mc_saved_tmp,
+ struct mc_saved_data *mc_saved_data)
+{
+ int i;
+ struct microcode_intel ***mc_saved;
+
+ mc_saved = (struct microcode_intel ***)
+ __pa_symbol(&mc_saved_data->mc_saved);
+ for (i = 0; i < mc_saved_data->mc_saved_count; i++) {
+ struct microcode_intel *p;
+
+ p = *(struct microcode_intel **)
+ __pa(mc_saved_data->mc_saved + i);
+ mc_saved_tmp[i] = (struct microcode_intel *)__pa(p);
+ }
+}
+#endif
+
+static enum ucode_state __cpuinit
+load_microcode(struct mc_saved_data *mc_saved_data,
+ unsigned long *mc_saved_in_initrd,
+ unsigned long initrd_start,
+ struct ucode_cpu_info *uci)
+{
+ struct microcode_intel *mc_saved_tmp[MAX_UCODE_COUNT];
+ unsigned int count = mc_saved_data->mc_saved_count;
+
+ if (!mc_saved_data->mc_saved) {
+ microcode_pointer(mc_saved_tmp, mc_saved_in_initrd,
+ initrd_start, count);
+
+ return generic_load_microcode_early(mc_saved_tmp, count, uci);
+ } else {
+#ifdef CONFIG_X86_32
+ microcode_phys(mc_saved_tmp, mc_saved_data);
+ return generic_load_microcode_early(mc_saved_tmp, count, uci);
+#else
+ return generic_load_microcode_early(mc_saved_data->mc_saved,
+ count, uci);
+#endif
+ }
+
