1. 27 7月, 2013 1 次提交
  2. 25 7月, 2013 1 次提交
  3. 18 6月, 2013 1 次提交
    • F
      serial: imx: Fix serial clock unbalance · 80c48497
      Fabio Estevam 提交于
      Since commit 0c375501 (serial: imx: enable the clocks for console), the
      imx_startup() function calls clk_prepare_enable conditionally, so we
      need to call clk_disable_unprepare inside imx_shutdown() under the same
      condition to avoid unbalanced clock calls.
      
      This avoids the following warning:
      
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 70 at drivers/clk/clk.c:780 __clk_disable+0x68/0x84()
      Modules linked in:
      CPU: 0 PID: 70 Comm: mountall Not tainted 3.10.0-rc4-next-20130607+ #435
      Backtrace:
      [<800116a4>] (dump_backtrace+0x0/0x10c) from [<80011844>] (show_stack+0x18/0x1c)
       r6:8069f4e8 r5:0000030c r4:00000000 r3:00000000
      [<8001182c>] (show_stack+0x0/0x1c) from [<8053bce0>] (dump_stack+0x78/0x94)
      [<8053bc68>] (dump_stack+0x0/0x94) from [<80023df8>] (warn_slowpath_common+0x6c/0x8c)
       r4:00000000 r3:00000000
      [<80023d8c>] (warn_slowpath_common+0x0/0x8c) from [<80023e3c>] (warn_slowpath_null+0x24/0x2c)
       r8:bf2ed008 r7:bfaa9810 r6:000f0013 r5:bf824b80 r4:bf824b80
      [<80023e18>] (warn_slowpath_null+0x0/0x2c) from [<8041af84>] (__clk_disable+0x68/0x84)
      [<8041af1c>] (__clk_disable+0x0/0x84) from [<8041b098>] (clk_disable+0x20/0x2c)
       r4:600f0013 r3:00000001
      [<8041b078>] (clk_disable+0x0/0x2c) from [<802c93e8>] (imx_shutdown+0xbc/0xec)
       r5:bf824b80 r4:bfaa9810
      [<802c932c>] (imx_shutdown+0x0/0xec) from [<802c63a0>] (uart_port_shutdown+0x34/0x40)
       r5:bf86f860 r4:bfaa9810
      [<802c636c>] (uart_port_shutdown+0x0/0x40) from [<802c68c0>] (uart_shutdown+0x98/0xc4)
       r4:bf86f800 r3:00000000
      [<802c6828>] (uart_shutdown+0x0/0xc4) from [<802c7514>] (uart_close+0x5c/0x198)
       r7:bfaa9810 r6:bf274400 r5:bf86f86c r4:bf86f800
      [<802c74b8>] (uart_close+0x0/0x198) from [<802ac648>] (tty_release+0xf8/0x500)
      [<802ac550>] (tty_release+0x0/0x500) from [<800c5a30>] (__fput+0x9c/0x208)
      [<800c5994>] (__fput+0x0/0x208) from [<800c5bac>] (____fput+0x10/0x14)
      [<800c5b9c>] (____fput+0x0/0x14) from [<80040234>] (task_work_run+0xb4/0xec)
      [<80040180>] (task_work_run+0x0/0xec) from [<80029238>] (do_exit+0x2b0/0x920)
       r8:8000e144 r7:000000f8 r6:bf306300 r5:00000000 r4:bfac1180
      [<80028f88>] (do_exit+0x0/0x920) from [<80029a4c>] (do_group_exit+0x50/0xd4)
       r7:000000f8
      [<800299fc>] (do_group_exit+0x0/0xd4) from [<80029ae8>] (__wake_up_parent+0x0/0x28)
       r7:000000f8 r6:00000001 r5:0006f7ae r4:0006f79a
      [<80029ad0>] (SyS_exit_group+0x0/0x18) from [<8000dfc0>] (ret_fast_syscall+0x0/0x30)
      ---[ end trace 16d080eb7efea4e9 ]---
      Reported-by: NShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
      Tested-by: NShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      80c48497
  4. 09 6月, 2013 1 次提交
  5. 07 6月, 2013 2 次提交
  6. 04 6月, 2013 2 次提交
  7. 21 5月, 2013 1 次提交
  8. 19 2月, 2013 1 次提交
  9. 15 2月, 2013 1 次提交
    • T
      serial: imx: Fix recursive locking bug · 677fe555
      Thomas Gleixner 提交于
      commit 9ec1882d (tty: serial: imx: console write routing is unsafe
      on SMP) introduced a recursive locking bug in imx_console_write().
      
      The callchain is:
      
      imx_rxint()
        spin_lock_irqsave(&sport->port.lock,flags);
        ...
        uart_handle_sysrq_char();
          sysrq_function();
            printk();
              imx_console_write();
                spin_lock_irqsave(&sport->port.lock,flags); <--- DEAD
      
      The bad news is that the kernel debugging facilities can dectect the
      problem, but the printks never surface on the serial console for
      obvious reasons.
      
      There is a similar issue with oops_in_progress. If the kernel crashes
      we really don't want to be stuck on the lock and unable to tell what
      happened.
      
      In general most UP originated drivers miss these checks and nobody
      ever notices because CONFIG_PROVE_LOCKING seems to be still ignored by
      a large number of developers.
      
      The solution is to avoid locking in the sysrq case and trylock in the
      oops_in_progress case.
      
      This scheme is used in other drivers as well and it would be nice if
      we could move this to a common place, so the usual copy/paste/modify
      bugs can be avoided.
      
      Now there is another issue with this scheme:
      
      CPU0 	    	     	 CPU1
      printk()
      			 rxint()
      			   sysrq_detection() -> sets port->sysrq
      			 return from interrupt
        console_write()
           if (port->sysrq)
           	avoid locking
      
      port->sysrq is reset with the next receive character. So as long as
      the port->sysrq is not reset and this can take an endless amount of
      time if after the break no futher receive character follows, all
      console writes happen unlocked.
      
      While the current writer is protected against other console writers by
      the console sem, it's unprotected against open/close or other
      operations which fiddle with the port. That's what the above mentioned
      commit tried to solve.
      
      That's an issue in all drivers which use that scheme and unfortunately
      there is no easy workaround. The only solution is to have a separate
      indicator port->sysrq_cpu. uart_handle_sysrq_char() then sets it to
      smp_processor_id() before calling into handle_sysrq() and resets it to
      -1 after that. Then change the locking check to:
      
           if (port->sysrq_cpu == smp_processor_id())
           	 locked = 0;
           else if (oops_in_progress)
               locked = spin_trylock_irqsave(port->lock, flags);
           else
        	 spin_lock_irqsave(port->lock, flags);
      
      That would force all other cpus into the spin_lock path. Problem
      solved, but that's way beyond the scope of this fix and really wants
      to be implemented in a common function which calls the uart specific
      write function to avoid another gazillion of hard to debug
      copy/paste/modify bugs.
      Reported-and-tested-by: NTim Sander <tim@krieglstein.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: stable <stable@vger.kernel.org>  # 3.6+
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      677fe555
  10. 07 2月, 2013 1 次提交
  11. 06 2月, 2013 1 次提交
  12. 18 1月, 2013 1 次提交
  13. 16 1月, 2013 7 次提交
  14. 22 9月, 2012 2 次提交
  15. 14 9月, 2012 1 次提交
  16. 06 9月, 2012 3 次提交
  17. 03 8月, 2012 1 次提交
  18. 01 7月, 2012 1 次提交
  19. 13 6月, 2012 1 次提交
  20. 11 5月, 2012 1 次提交
  21. 25 4月, 2012 1 次提交
    • S
      serial i.MX: do not depend on grouped clocks · 3a9465fa
      Sascha Hauer 提交于
      the current i.MX clock support groups together unrelated clocks
      to a single clock which is then used by the driver. This can't
      be accomplished with the generic clock framework so we instead
      request the individual clocks in the driver. For i.MX there are
      generally three different clocks:
      
      ipg: bus clock (needed to access registers)
      ahb: dma relevant clock, sometimes referred to as hclk in the datasheet
      per: bit clock, pixel clock
      
      This patch changes the driver to request the individual clocks.
      Currently all clk_get will get the same clock until the SoCs
      are converted to the generic clock framework
      Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
      3a9465fa
  22. 01 2月, 2012 1 次提交
  23. 05 1月, 2012 6 次提交
  24. 27 11月, 2011 1 次提交