Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 05 9月, 2011 1 次提交
    • P
      OMAP2430: hwmod: musb: add missing terminator to omap2430_usbhsotg_addrs[] · 10167873
      由 Paul Walmsley 提交于 
      Add a missing array terminator to omap2430_usbhsotg_addrs[].  Without
this terminator, the omap_hwmod resource building code runs off the
end of the array, resulting in at least this error -- if not worse
behavior:

[    0.578002] musb-omap2430: failed to claim resource 4
[    0.583465] omap_device: musb-omap2430: build failed (-16)
[    0.589294] Could not build omap_device for musb-omap2430 usb_otg_hs

This should have been part of commit
78183f3f ("omap_hwmod: use a null
structure record to terminate omap_hwmod_addr_space arrays") but was
evidently missed.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      10167873
  3. 27 8月, 2011 3 次提交
  5. 26 8月, 2011 5 次提交
  7. 25 8月, 2011 2 次提交
  9. 24 8月, 2011 5 次提交
  11. 23 8月, 2011 1 次提交
    • P
      OMAP3: clock: indicate that gpt12_fck and wdt1_fck are in the WKUP clockdomain · e21757a0
      由 Paul Walmsley 提交于 
      The oscillator that supplies GPT12_FCLK and WDT1_FCLK exists in the
WKUP powerdomain[1].  This resolves at least one boot-time warning:

omap_hwmod: gpt12_fck: missing clockdomain for gpt12_fck.

1. _OMAP34xx Multimedia High Security (HS) Device Silicon Revision 3.1.x
   Security Addendum Version K (SWPU119K)_  Figure 3-29.  August 2010.
      e21757a0
  13. 22 8月, 2011 2 次提交
  15. 21 8月, 2011 2 次提交
    • P
      OMAP4: clock: fix compile warning · 450a37d2
      由 Paul Walmsley 提交于 
      Fix the following compile warning:

arch/arm/mach-omap2/clock44xx_data.c: In function 'omap4xxx_clk_init':
arch/arm/mach-omap2/clock44xx_data.c:3371:6: warning: 'cpu_clkflg' may be used uninitialized in this function

The approach taken here is intended to work if omap4xxx_clk_init() is
converted into an initcall.

Thanks to Bjarne Steinsbo <bsteinsbo@gmail.com> for proposing another
approach.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Bjarne Steinsbo <bsteinsbo@gmail.com>
      450a37d2
    • D
      sparc: Allow handling signals when stack is corrupted. · 5598473a
      由 David S. Miller 提交于 
      If we can't push the pending register windows onto the user's stack,
we disallow signal delivery even if the signal would be delivered on a
valid seperate signal stack.

Add a register window save area in the signal frame, and store any
unsavable windows there.

On sigreturn, if any windows are still queued up in the signal frame,
try to push them back onto the stack and if that fails we kill the
process immediately.

This allows the debug/tst-longjmp_chk2 glibc test case to pass.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5598473a
  17. 20 8月, 2011 3 次提交
    • P
      OMAP4: clock: re-enable previous clockdomain enable/disable sequence · 9c5f5601
      由 Paul Walmsley 提交于 
      After commit 665d0013 ("OMAP2+: hwmod:
Follow the recommended PRCM module enable sequence"), device drivers
for OMAP IP blocks that do not use runtime PM can cause oopses or
kernel instability[1][2].

This is because those non-runtime PM drivers do not use the hwmod
code, which implements the correct IP block enable and disable
sequence.

Several options for dealing with this problem have been proposed:

1. Add a new field to the OMAP struct clk to mark clocks that are
   currently used by non-runtime PM drivers.  Modify the clock code to
   use the old clockdomain sequence for these marked clocks.  As
   drivers are converted to use runtime PM, remove the annotation from
   the clocks.

2. Similar to #1, but associate the flag with the struct omap_clk
   instead.

3. Add IDLEST wait support to the OMAP4 clock code, similar to the way
   it is implemented for OMAP2/3, and enable it in each struct clk
   currently used by non-runtime PM drivers.  As drivers are converted
   to use runtime PM, remove the annotation from the clocks.

4. Do nothing; leave the problem to those responsible for the
   unconverted drivers.

5. Re-enable clock-based clockdomain control in the OMAP4 clock code.
   This would revert back to the behavior of Linux 3.0, simply with a
   slightly longer module enable/disable latency.

Unfortunately, no approach seemed particularly good.  Options 1
through 3 seemed unwise due to the following reasons:

A. The OMAP struct clks are intended primarily to describe hardware
   clock nodes, and the intention is that no driver-specific data
   should be stored there (applies to #1)

B. The resulting patch would have been quite large for the -rc series
   (applies to #1, #2, #3)

C. The patch would have been a new, yet temporary hack; and similar fixes
   have drawn negative comments in the recent past (see for example [3])

Option 4 is undesirable because commit
665d0013 ("OMAP2+: hwmod: Follow the
recommended PRCM module enable sequence") has resulted in a less
stable kernel; and kernel stability is more important than OMAP4 power
management.

Option 5 is the approach taken in this patch.  This seemed to be the
least intrusive approach for 3.1-rc.

The approach in this patch was originally proposed by Ohad Ben-Cohen
<ohad@wizery.com>.  I'm simply writing the commit message and passing
it along.

...

Thanks to Luciano Coelho <coelho@ti.com> for reporting the problem.
Thanks to Ohad Ben-Cohen <ohad@wizery.com> for tracking the problem
down, generating a temporary workaround, and proposing a patch to deal
with the problem.  Thanks to Rajendra Nayak <rnayak@ti.com> for
proposing another patch to deal with the problem.  Thanks to Felipe
Balbi <balbi@ti.com> for comments.

1. Coelho, Luciano <coelho@ti.com>.  _Re: Oops on ehci_hcd when
   booting 3.0.0-rc2 on panda_.  Tue, 09 Aug 2011 14:26:08 +0300.
   Posted to the <linux-omap@vger.kernel.org> mailing list.  Available
   from (among others)
   http://www.spinics.net/linux/lists/linux-omap/msg55213.html

2. Munegowda, Keshava <keshava_mgowda@ti.com>. _Re: Oops on ehci_hcd
   when booting 3.0.0-rc2 on panda_.  Thu, 11 Aug 2011 13:51:05 +0530.
   Posted to the <linux-omap@vger.kernel.org> mailing list.  Available
   from (among others)
   http://www.spinics.net/linux/lists/linux-omap/msg55371.html

3. King, Russell <linux@arm.linux.org.uk>.  _Re: [PATCH 5/8] OMAP4:
   PM: TEMP: Prevent l3init from idling/force sleep_.  Thu, 23 Jun
   2011 16:22:49 +0100.  Posted to the <linux-omap@vger.kernel.org>
   mailing list.  Available from (among others)
   http://www.mail-archive.com/linux-omap@vger.kernel.org/msg51392.htmlSigned-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Luciano Coelho <coelho@ti.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      9c5f5601
    • S
      OMAP: clockdomain: Wait for powerdomain to be ON when using clockdomain force wakeup · b1cbdb00
      由 Santosh Shilimkar 提交于 
      While using clockdomain force wakeup method, not waiting for powerdomain
to be effectively ON may end up locking the clockdomain FSM until a
next wakeup event occurs.

One such issue was seen on OMAP4430, where L4_PER was periodically
getting stuck in in-transition state when transitioning from from OSWR to ON.

This issue was reported and investigated by Patrick Titiano <p-titiano@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Reported-by: NPatrick Titiano <p-titiano@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
[paul@pwsan.com: updated to apply; added transition wait on clkdm_deny_idle();
 remove two superfluous pwrdm_wait_transition() calls]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      b1cbdb00
    • R
      OMAP: powerdomains: Make all powerdomain target states as ON at init · c956b753
      由 Rajendra Nayak 提交于 
      Program all powerdomain target state as ON; this is to prevent domains
from hitting low power states (if bootloader has target states set to
something other than ON) and potentially even losing context while PM
is not fully initialized, which can cause the system to crash.  The PM
late init code can then program the desired target state for all the
power domains.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
[paul@pwsan.com: dropped comment typo hunk; fixed comment indent and moved
 to kerneldoc; moved code to pwrdm_init(); changed pwrdm_init() argument name
 to prevent clash; cleaned up patch description]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      c956b753
  19. 19 8月, 2011 1 次提交
    • I
      sparc: fix array bounds error setting up PCIC NMI trap · 4a0342ca
      由 Ian Campbell 提交于 
        CC      arch/sparc/kernel/pcic.o
arch/sparc/kernel/pcic.c: In function 'pcic_probe':
arch/sparc/kernel/pcic.c:359:33: error: array subscript is above array bounds [-Werror=array-bounds]
arch/sparc/kernel/pcic.c:359:8: error: array subscript is above array bounds [-Werror=array-bounds]
arch/sparc/kernel/pcic.c:360:33: error: array subscript is above array bounds [-Werror=array-bounds]
arch/sparc/kernel/pcic.c:360:8: error: array subscript is above array bounds [-Werror=array-bounds]
arch/sparc/kernel/pcic.c:361:33: error: array subscript is above array bounds [-Werror=array-bounds]
arch/sparc/kernel/pcic.c:361:8: error: array subscript is above array bounds [-Werror=array-bounds]
cc1: all warnings being treated as errors

I'm not particularly familiar with sparc but t_nmi (defined in head_32.S via
the TRAP_ENTRY macro) and pcic_nmi_trap_patch (defined in entry.S) both appear
to be 4 instructions long and I presume from the usage that instructions are
int sized.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a0342ca
  21. 17 8月, 2011 2 次提交
    • J
      xen/x86: replace order-based range checking of M2P table by linear one · ccbcdf7c
      由 Jan Beulich 提交于 
      The order-based approach is not only less efficient (requiring a shift
and a compare, typical generated code looking like this

	mov	eax, [machine_to_phys_order]
	mov	ecx, eax
	shr	ebx, cl
	test	ebx, ebx
	jnz	...

whereas a direct check requires just a compare, like in

	cmp	ebx, [machine_to_phys_nr]
	jae	...

), but also slightly dangerous in the 32-on-64 case - the element
address calculation can wrap if the next power of two boundary is
sufficiently far away from the actual upper limit of the table, and
hence can result in user space addresses being accessed (with it being
unknown what may actually be mapped there).

Additionally, the elimination of the mistaken use of fls() here (should
have been __fls()) fixes a latent issue on x86-64 that would trigger
if the code was run on a system with memory extending beyond the 44-bit
boundary.

CC: stable@kernel.org
Signed-off-by: NJan Beulich <jbeulich@novell.com>
[v1: Based on Jeremy's feedback]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      ccbcdf7c
    • R
      KVM: uses TASKSTATS, depends on NET · df3d8ae1
      由 Randy Dunlap 提交于 
      CONFIG_TASKSTATS just had a change to use netlink, including
a change to "depends on NET".  Since "select" does not follow
dependencies, KVM also needs to depend on NET to prevent build
errors when CONFIG_NET is not enabled.

Sample of the reported "undefined reference" build errors:

taskstats.c:(.text+0x8f686): undefined reference to `nla_put'
taskstats.c:(.text+0x8f721): undefined reference to `nla_reserve'
taskstats.c:(.text+0x8f8fb): undefined reference to `init_net'
taskstats.c:(.text+0x8f905): undefined reference to `netlink_unicast'
taskstats.c:(.text+0x8f934): undefined reference to `kfree_skb'
taskstats.c:(.text+0x8f9e9): undefined reference to `skb_clone'
taskstats.c:(.text+0x90060): undefined reference to `__alloc_skb'
taskstats.c:(.text+0x901e9): undefined reference to `skb_put'
taskstats.c:(.init.text+0x4665): undefined reference to `genl_register_family'
taskstats.c:(.init.text+0x4699): undefined reference to `genl_register_ops'
taskstats.c:(.init.text+0x4710): undefined reference to `genl_unregister_ops'
taskstats.c:(.init.text+0x471c): undefined reference to `genl_unregister_family'
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      df3d8ae1
  23. 16 8月, 2011 4 次提交
  25. 12 8月, 2011 1 次提交
  27. 11 8月, 2011 8 次提交