Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 10 5月, 2012 14 次提交
  3. 28 4月, 2012 1 次提交
  5. 27 4月, 2012 9 次提交
    • I
      ARM: PXA2xx: MFP: fix potential direction bug · ef7c7c69
      由 Igor Grinberg 提交于 
      Pins configured as input and have MFP_LPM_DRIVE_* flag set, can have a
wrong output value for some period of time (spike) during the suspend
sequence.
This can happen because the direction of the pins (GPDR) is set by
software and the output level is set by hardware (PGSR) at a later
stage.

Fix the above potential bug by setting the output levels first.
Also save the actual levels of the pins before the suspend and restore
them after the resume, but before the direction settings take place, so
the same bug as described above will not happen in the resume sequence.
Reported-by: NPaul Parsons <lost.distance@yahoo.com>
Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il>
Tested-by: NPaul Parsons <lost.distance@yahoo.com>
Signed-off-by: NHaojian Zhuang <haojian.zhuang@gmail.com>
      ef7c7c69
    • I
      ARM: PXA2xx: MFP: fix bug with MFP_LPM_KEEP_OUTPUT · a13b8787
      由 Igor Grinberg 提交于 
      Pins that have MFP_LPM_KEEP_OUTPUT set and are configured for output
must retain the output state in low power mode.
Currently, the pin direction configuration is overrided with values
in gpdr_lpm[] array and do not obey the MFP_LPM_KEEP_OUTPUT setting.

Fix the above bug and add some documentation to clarify the
MFP_LPM_KEEP_OUTPUT setting purpose.
Reported-by: NPaul Parsons <lost.distance@yahoo.com>
Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il>
Tested-by: NPaul Parsons <lost.distance@yahoo.com>
Signed-off-by: NHaojian Zhuang <haojian.zhuang@gmail.com>
      a13b8787
    • D
      arm/sa1100: fix sa1100-rtc memory resource · 9f9d27e3
      由 Dmitry Artamonow 提交于 
      DEFINE_RES_MEM() takes the size of resource as a second argument,
not the end address. Passing end address leads to following error
in runtime during device registration:
sa1100-rtc: failed to claim resource 0

Fix it.
Signed-off-by: NDmitry Artamonow <mad_soft@inbox.ru>
Signed-off-by: NHaojian Zhuang <haojian.zhuang@gmail.com>
      9f9d27e3
    • R
      ARM: pxa: fix gpio wakeup setting · b95ace54
      由 Robert Jarzmik 提交于 
      In 3.3, gpio wakeup setting was broken. The call
enable_irq_wake() didn't set up the PXA gpio registers
(PWER, ...) anymore.

Fix it at least for pxa27x. The driver doesn't seem to be
used in pxa25x (weird ...), and the fix doesn't extend to
pxa3xx and pxa95x (which don't have a gpio_set_wake()
available).
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NHaojian Zhuang <haojian.zhuang@gmail.com>
      b95ace54
    • K
      xen/smp: Fix crash when booting with ACPI hotplug CPUs. · cf405ae6
      由 Konrad Rzeszutek Wilk 提交于 
      When we boot on a machine that can hotplug CPUs and we
are using 'dom0_max_vcpus=X' on the Xen hypervisor line
to clip the amount of CPUs available to the initial domain,
we get this:

(XEN) Command line: com1=115200,8n1 dom0_mem=8G noreboot dom0_max_vcpus=8 sync_console mce_verbosity=verbose console=com1,vga loglvl=all guest_loglvl=all
.. snip..
DMI: Intel Corporation S2600CP/S2600CP, BIOS SE5C600.86B.99.99.x032.072520111118 07/25/2011
.. snip.
SMP: Allowing 64 CPUs, 32 hotplug CPUs
installing Xen timer for CPU 7
cpu 7 spinlock event irq 361
NMI watchdog: disabled (cpu7): hardware events not enabled
Brought up 8 CPUs
.. snip..
	[acpi processor finds the CPUs are not initialized and starts calling
	arch_register_cpu, which creates /sys/devices/system/cpu/cpu8/online]
CPU 8 got hotplugged
CPU 9 got hotplugged
CPU 10 got hotplugged
.. snip..
initcall 1_acpi_battery_init_async+0x0/0x1b returned 0 after 406 usecs
calling  erst_init+0x0/0x2bb @ 1

	[and the scheduler sticks newly started tasks on the new CPUs, but
	said CPUs cannot be initialized b/c the hypervisor has limited the
	amount of vCPUS to 8 - as per the dom0_max_vcpus=8 flag.
	The spinlock tries to kick the other CPU, but the structure for that
	is not initialized and we crash.]
BUG: unable to handle kernel paging request at fffffffffffffed8
IP: [<ffffffff81035289>] xen_spin_lock+0x29/0x60
PGD 180d067 PUD 180e067 PMD 0
Oops: 0002 [#1] SMP
CPU 7
Modules linked in:

Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc2upstream-00001-gf5154e8 #1 Intel Corporation S2600CP/S2600CP
RIP: e030:[<ffffffff81035289>]  [<ffffffff81035289>] xen_spin_lock+0x29/0x60
RSP: e02b:ffff8801fb9b3a70  EFLAGS: 00010282

With this patch, we cap the amount of vCPUS that the initial domain
can run, to exactly what dom0_max_vcpus=X has specified.

In the future, if there is a hypercall that will allow a running
domain to expand past its initial set of vCPUS, this patch should
be re-evaluated.

CC: stable@kernel.org
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      cf405ae6
    • N
      sh: Fix up tracepoint build fallout from static key introduction. · ec2ccd88
      由 Nobuhiro Iwamatsu 提交于 
      With the introduction of static keys, anything using tracepoints blows up
in the following manner:

include/trace/events/oom.h:8:13: error: initializer element is not constant
include/trace/events/oom.h:8:13: error: (near initialization for '__tracepoint_oom_score_adj_update')
include/trace/events/oom.h:8:13: error: initializer element is not constant
include/trace/events/oom.h:8:13: error: (near initialization for '__tracepoint_oom_score_adj_update.key')

This is a result of the STATIC_KEY_INIT_xxx defs wrapping ATOMIC_INIT()
which on sh includes an atomic_t typecast. Given that we don't really
need the typecast for anything anymore, the simplest solution is simply
to kill off the cast.
Signed-off-by: NNobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      ec2ccd88
    • P
      xtensa: fix build fail on undefined ack_bad_irq · 8e12a038
      由 Paul Gortmaker 提交于 
      Commit e520c410

    "xtensa: convert to asm-generic/hardirq.h"

converted over to using the asm-generic parts, but it also
added the sentinel

	#define ack_bad_irq ack_bad_irq

which tells asm-generic to _not_ use the common ack_bad_irq.

Since e520c410 deleted the duplicated code from the arch specific
file, we _do_ want the asm-generic one in scope.  So delete
the trigger define above which hides it.  In doing so we'll
realize that we've got to delete the almost-duplicate prototype
as well to avoid "static declaration ... follows non-static".

Cc: Christoph Hellwig <hch@lst.de>
Cc: Chris Zankel <chris@zankel.net>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      8e12a038
    • K
      xen/enlighten: Disable MWAIT_LEAF so that acpi-pad won't be loaded. · df88b2d9
      由 Konrad Rzeszutek Wilk 提交于 
      There are exactly four users of __monitor and __mwait:

 - cstate.c (which allows acpi_processor_ffh_cstate_enter to be called
   when the cpuidle API drivers are used. However patch
   "cpuidle: replace xen access to x86 pm_idle and default_idle"
   provides a mechanism to disable the cpuidle and use safe_halt.
 - smpboot (which allows mwait_play_dead to be called). However
   safe_halt is always used so we skip that.
 - intel_idle (same deal as above).
 - acpi_pad.c. This the one that we do not want to run as we
   will hit the below crash.

Why do we want to expose MWAIT_LEAF in the first place?
We want it for the xen-acpi-processor driver - which uploads
C-states to the hypervisor. If MWAIT_LEAF is set, the cstate.c
sets the proper address in the C-states so that the hypervisor
can benefit from using the MWAIT functionality. And that is
the sole reason for using it.

Without this patch, if a module performs mwait or monitor we
get this:

invalid opcode: 0000 [#1] SMP
CPU 2
.. snip..
Pid: 5036, comm: insmod Tainted: G           O 3.4.0-rc2upstream-dirty #2 Intel Corporation S2600CP/S2600CP
RIP: e030:[<ffffffffa000a017>]  [<ffffffffa000a017>] mwait_check_init+0x17/0x1000 [mwait_check]
RSP: e02b:ffff8801c298bf18  EFLAGS: 00010282
RAX: ffff8801c298a010 RBX: ffffffffa03b2000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff8801c29800d8 RDI: ffff8801ff097200
RBP: ffff8801c298bf18 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
R13: ffffffffa000a000 R14: 0000005148db7294 R15: 0000000000000003
FS:  00007fbb364f2700(0000) GS:ffff8801ff08c000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000179f038 CR3: 00000001c9469000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process insmod (pid: 5036, threadinfo ffff8801c298a000, task ffff8801c29cd7e0)
Stack:
 ffff8801c298bf48 ffffffff81002124 ffffffffa03b2000 00000000000081fd
 000000000178f010 000000000178f030 ffff8801c298bf78 ffffffff810c41e6
 00007fff3fb30db9 00007fff3fb30db9 00000000000081fd 0000000000010000
Call Trace:
 [<ffffffff81002124>] do_one_initcall+0x124/0x170
 [<ffffffff810c41e6>] sys_init_module+0xc6/0x220
 [<ffffffff815b15b9>] system_call_fastpath+0x16/0x1b
Code: <0f> 01 c8 31 c0 0f 01 c9 c9 c3 00 00 00 00 00 00 00 00 00 00 00 00
RIP  [<ffffffffa000a017>] mwait_check_init+0x17/0x1000 [mwait_check]
 RSP <ffff8801c298bf18>
---[ end trace 16582fc8a3d1e29a ]---
Kernel panic - not syncing: Fatal exception

With this module (which is what acpi_pad.c would hit):

MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>");
MODULE_DESCRIPTION("mwait_check_and_back");
MODULE_LICENSE("GPL");
MODULE_VERSION();

static int __init mwait_check_init(void)
{
	__monitor((void *)&current_thread_info()->flags, 0, 0);
	__mwait(0, 0);
	return 0;
}
static void __exit mwait_check_exit(void)
{
}
module_init(mwait_check_init);
module_exit(mwait_check_exit);
Reported-by: NLiu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      df88b2d9
    • P
      blackfin: fix ifdef fustercluck in mach-bf538/boards/ezkit.c · fa83af7e
      由 Paul Gortmaker 提交于 
      This file has lots and lots of ifdef, around structure decls
and structure usages.  The failure issue was that we would
build the BF538-EZKIT_defconfig and get:

 arch/blackfin/mach-bf538/boards/ezkit.c:924:3: error: 'bfin_lq035q1_device'
 undeclared here (not in a function)

even though the same ifdef _appeared_ to enable both the struct
declaration and the code that used it.  Yet cpp was telling us we
didn't have the struct, but we still had the usage of it.

However, _appeared_ is the operative word.  After marking all the
anonymous #endif with their parent #ifdef config options, it was
_then_ clear that there was a misplaced #endif that was hiding
the struct declaration.

The real guts of the patch boils down to this:

-#endif
+#endif /* CONFIG_MTD_M25P80 */
+#endif /* CONFIG_SPI_BFIN5XX */
 [...]
-#endif  /* spi master and devices */

but since I had to tag the #endif with their respective #ifdef
options to find this misplaced SPI endif, it would be silly to
then go and delete them all.  So they stay.

Cc: Sonic Zhang <sonic.zhang@analog.com>
Cc: Bob Liu <lliubbo@gmail.com>
Acked-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      fa83af7e
  7. 26 4月, 2012 2 次提交
  9. 25 4月, 2012 7 次提交
  11. 24 4月, 2012 7 次提交