Shawn Guo [Thu, 12 Jun 2014 07:43:56 +0000 (15:43 +0800)]
ENGR00317981: pxp: use DMA_COMPLETE for dma completion status
DMA_SUCCESS is removed by commit 7db5f7274a0b (dmaengine: remove unused
DMA_SUCCESS). Let's follow commit 409bff6a0f46 (dmaengine: imx-sdma: use
DMA_COMPLETE for dma completion status) to use DMA_COMPLETE instead.
This is to fix the following build error.
CC drivers/dma/pxp/pxp_dma_v2.o
drivers/dma/pxp/pxp_dma_v2.c: In function ‘pxp_tx_status’:
drivers/dma/pxp/pxp_dma_v2.c:1512:9: error: ‘DMA_SUCCESS’ undeclared (first use in this function)
Shawn Guo [Fri, 13 Jun 2014 03:37:29 +0000 (11:37 +0800)]
ENGR00317981: drm: vivante: drm_platform_exit is gone
The function drm_platform_exit() is removed by commit e2577d455adb (drm:
rip out drm_platform_exit). To fix the build error below, we need to
call drm_put_dev directly.
CC drivers/gpu/drm/vivante/vivante_drv.o
drivers/gpu/drm/vivante/vivante_drv.c: In function ‘vivante_exit’:
drivers/gpu/drm/vivante/vivante_drv.c:100:3: error: implicit declaration of function ‘drm_platform_exit’ [-Werror=implicit-function-declaration]
Note, this only works with commit "ENGR00317981: drm: set drm_device
pointer into drvdata".
Shawn Guo [Fri, 13 Jun 2014 08:02:58 +0000 (16:02 +0800)]
ENGR00317981: drm: set drm_device pointer into drvdata
If drvdata is not used by platform driver, let's set drm_device
pointer into it. We take this as the default usage of drvdata,
and platform driver is free to overwrite it later as needed.
Shawn Guo [Fri, 13 Jun 2014 02:45:39 +0000 (10:45 +0800)]
ENGR00317981: drm: vivante: flag DRIVER_USE_MTRR is gone
The flag DRIVER_USE_MTRR is removed by commit 281856477cda (drm: rip out
drm_core_has_MTRR checks). Drop it from vivante driver to fix the build
error below.
CC drivers/gpu/drm/vivante/vivante_drv.o
drivers/gpu/drm/vivante/vivante_drv.c:72:21: error: ‘DRIVER_USE_MTRR’ undeclared here (not in a function)
Shawn Guo [Thu, 12 Jun 2014 06:02:43 +0000 (14:02 +0800)]
ENGR00317981: gpu-viv: use reinit_completion instead of INIT_COMPLETION
INIT_COMPLETION was removed by commit 62026aedaace (sched: remove
INIT_COMPLETION), so we're seeing the following build error.
CC drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.o
drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.c: In function ‘gckOS_Signal’:
drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.c:7506:9: error: implicit declaration of function ‘INIT_COMPLETION’ [-Werror=implicit-function-declaration]
Follow commit 16735d022f72 (tree-wide: use reinit_completion instead of
INIT_COMPLETION) to fix the error.
Shawn Guo [Thu, 12 Jun 2014 02:13:32 +0000 (10:13 +0800)]
ENGR00317981: mxc: forward mxc drivers to 3.14 kernel
Forward imx_3.10.y mxc drivers to 3.14 kernel. This includes all
the imx_3.10.y drivers in drivers/mxc folder except ASRC. We will try
to use upstream ASRC driver on 3.14 kernel.
Anson Huang [Wed, 12 Feb 2014 10:06:35 +0000 (18:06 +0800)]
thermal: imx: update formula for thermal sensor
Thermal sensor used to need two calibration points which are
in fuse map to get a slope for converting thermal sensor's raw
data to real temperature in degree C. Due to the chip calibration
limitation, hardware team provides an universal formula to get
real temperature from internal thermal sensor raw data:
Anson Huang [Thu, 8 Aug 2013 17:20:40 +0000 (13:20 -0400)]
ENGR00274056-1 thermal: add device cooling for thermal driver
cpu cooling is not enough when temperature is
too hot, as some devices may contribute a lot of heat
to SOC, such as GPU, so we need to add device cooling
as well, when system is too hot, devices can also take
their actions to lower SOC temperature.
when temperature cross the passive trip, device cooling
driver will send out notification, those devices who
register this devfreq_cooling notification will take
actions to lower SOC temperature.
Shawn Guo [Thu, 12 Jun 2014 02:56:24 +0000 (10:56 +0800)]
ENGR00317981: busfreq: fix the use of MT_MEMORY_NONCACHED
Since commit 2e2c9de207be (ARM: add permission annotations to MT_MEMORY*
mapping types), MT_MEMORY_NONCACHED is not available any more. Thus, we
see following build error.
CC arch/arm/mach-imx/busfreq_ddr3.o
arch/arm/mach-imx/busfreq_ddr3.c: In function ‘init_mmdc_settings’:
arch/arm/mach-imx/busfreq_ddr3.c:464:7: error: ‘MT_MEMORY_NONCACHED’ undeclared (first use in this function)
Fix it by using the new enum MT_MEMORY_RWX_NONCACHED.
Peter Chen [Mon, 24 Feb 2014 02:21:04 +0000 (10:21 +0800)]
usb: phy: mxs: Add sync time after controller clear phcd
After clear portsc.phcd, PHY needs 200us stable time for switch
32K clock to AHB clock.
Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
[shawn.guo: cherry-pick commit 47d1845ffac0 from upstream]
Peter Chen [Mon, 24 Feb 2014 02:21:03 +0000 (10:21 +0800)]
usb: phy: mxs: Add system suspend/resume API
We need this to keep PHY's power on or off during the system
suspend mode. If we need to enable USB wakeup, then we
must keep PHY's power being on during the system suspend mode.
Otherwise, we need to keep PHY's power being off to save power.
Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
[shawn.guo: cherry-pick commit bf7834380086 from upstream]
Peter Chen [Mon, 24 Feb 2014 02:21:02 +0000 (10:21 +0800)]
usb: phy: mxs: Add implementation of set_wakeup
When we need the PHY can be waken up by external signals,
we can call this API. Besides, we call mxs_phy_disconnect_line
at this API to close the connection between USB PHY and
controller, after that, the line state from controller is SE0.
Once the PHY is out of power, without calling mxs_phy_disconnect_line,
there are unknown wakeups due to dp/dm floating at device mode.
Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
[shawn.guo: cherry-pick commit 3f1265056be0 from upstream]
Peter Chen [Mon, 24 Feb 2014 02:21:01 +0000 (10:21 +0800)]
usb: phy: Add set_wakeup API
This API is used to set wakeup enable at PHY registers, in that
case, the PHY can be waken up from suspend due to external events,
like vbus change, dp/dm change and id change.
Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
[shawn.guo: cherry-pick commit 57bf9b09a6ad from upstream]
Peter Chen [Mon, 24 Feb 2014 02:21:00 +0000 (10:21 +0800)]
usb: phy: mxs: add controller id
It is used to access un-regulator registers according to
different controllers.
Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
[shawn.guo: cherry-pick commit 83be181b6422 from upstream]
Peter Chen [Mon, 24 Feb 2014 02:20:59 +0000 (10:20 +0800)]
usb: phy: mxs: Enable IC fixes for related SoCs
Two PHY bugs are fixed by IC logic, but these bits are not
enabled by default, so we enable them at driver.
The two bugs are: MXS_PHY_ABNORMAL_IN_SUSPEND and MXS_PHY_SENDING_SOF_TOO_FAST
which are described at code.
Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
[shawn.guo: cherry-pick commit 22db05ecf2ba from upstream]
Peter Chen [Mon, 24 Feb 2014 02:20:58 +0000 (10:20 +0800)]
usb: phy: mxs: change description of usb device speed
Change "high speed" to "HS"
Change "non-high speed" to "FS/LS"
Implementation of notify_suspend and notify_resume will be different
according to mxs_phy_data->flags.
Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
[shawn.guo: cherry-pick commit f6a158243e56 from upstream]
Peter Chen [Mon, 24 Feb 2014 02:20:57 +0000 (10:20 +0800)]
usb: phy: mxs: Add anatop regmap
It is needed by imx6 SoC series, but not for imx23 and imx28.
Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
[shawn.guo: cherry-pick commit 0d896538d836 from upstream]
Peter Chen [Mon, 24 Feb 2014 02:20:56 +0000 (10:20 +0800)]
usb: doc: phy-mxs: update binding for adding anatop phandle
Add anatop phandle which is used to access anatop registers to
control PHY's power and other USB operations.
Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
[shawn.guo: cherry-pick commit d9c130328d2e from upstream]
Peter Chen [Mon, 24 Feb 2014 02:20:55 +0000 (10:20 +0800)]
usb: phy: mxs: Add auto clock and power setting
The auto setting is used to open related power and clocks
automatically after receiving wakeup signal.
With this feature, the PHY's clock and power can be recovered
correctly from low power mode, it is guaranteed by IC logic.
Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
[shawn.guo: cherry-pick commit 1364414411ac from upstream]
Peter Chen [Mon, 24 Feb 2014 02:20:54 +0000 (10:20 +0800)]
usb: phy: mxs: Add platform judgement code
The mxs-phy has several bugs and features at different
versions, the driver code can get it through of_device_id.data.
Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
[shawn.guo: cherry-pick commit 2400780ea18a from upstream]
Peter Chen [Mon, 24 Feb 2014 02:20:53 +0000 (10:20 +0800)]
usb: doc: phy-mxs: Add more compatible strings
Add "fsl,imx6q-usbphy" for imx6dq and imx6dl, add
"fsl,imx6sl-usbphy" for imx6sl, and "fsl,imx23-usbphy"
is still a fallback for other strings.
Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
[shawn.guo: cherry-pick commit 14de8c3a62b9 from upstream]
Peter Chen [Wed, 19 Feb 2014 05:41:41 +0000 (13:41 +0800)]
usb: chipidea: udc: refine ep operation at isr_tr_complete_handler
- delete the warning message at interrupt handler, and adds judgement at
ep_enable, if non-ep0 requests ctrl transfer, it will indicate an error.
- delete hw_test_and_clear_setup_status which is a broken code
- Tested with g_mass_storage, g_ncm, g_ether
Cc: matthieu.castet@parrot.com Reported-by: Michael Grzeschik <mgr@pengutronix.de> Acked-by: Michael Grzeschik <mgr@pengutronix.de> Tested-by: Michael Grzeschik <mgr@pengutronix.de> Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[shawn.guo: cherry-pick commit 64fc06c40e01 from upstream]
Peter Chen [Wed, 19 Feb 2014 05:41:40 +0000 (13:41 +0800)]
usb: chipidea: refine PHY operation
- Delete global_phy due to we can get the phy from phy layer now
- using devm_usb_get_phy to instead of usb_get_phy
- delete the otg_set_peripheral, which should be handled by otg layer
Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[shawn.guo: cherry-pick commit c859aa65a7ec from upstream]
Troy Kisky [Fri, 20 Dec 2013 18:47:10 +0000 (11:47 -0700)]
ARM: dts: imx6qdl: use interrupts-extended for fec
We need to be able to override interrupts in board file to
workaround a hardware bug for ethernet interrupts
waking the processor by using interrupts-extended.
So, use interrupts-extended here as well.
ERR006687 ENET: Only the ENET wake-up interrupt request can wake the
system from Wait mode.
The ENET block generates many interrupts. Only one of these interrupt lines
is connected to the General Power Controller (GPC) block, but a logical OR
of all of the ENET interrupts is connected to the General Interrupt Controller
(GIC). When the system enters Wait mode, a normal RX Done or TX Done does not
wake up the system because the GPC cannot see this interrupt. This impacts
performance of the ENET block because its interrupts are serviced only when
the chip exits Wait mode due to an interrupt from some other wake-up source.
Adding MX6QDL_PAD_GPIO_6__ENET_IRQ is the 1st step to
workaround this problem.
The input reg is set to 0x3c to set IOMUX_OBSRV_MUX1 to ENET_IRQ.
The mux reg value is 0x11, so that the observable mux is routed to
this pin and to the gpio controller(sion bit). These magic values
come from Ranjani Vaidyanathan's patch:
"ENGR00257847-1 MX6Q/DL-Fix Ethernet performance issue when WAIT mode is active"
Fabio Estevam [Thu, 19 Dec 2013 23:08:52 +0000 (21:08 -0200)]
ARM: dts: imx6: Use 'vddarm' as the regulator name
Instead of calling the regulator for the ARM core as 'cpu', let's rename it
as 'vddarm', so that we keep a better consistency with the other internal
regulators:
vdd1p1: 800 <--> 1375 mV at 1100 mV
vdd3p0: 2800 <--> 3150 mV at 3000 mV
vdd2p5: 2000 <--> 2750 mV at 2400 mV
vddarm: 725 <--> 1450 mV at 1150 mV
vddpu: 725 <--> 1450 mV at 1150 mV
vddsoc: 725 <--> 1450 mV at 1200 mV
Nicolin Chen [Sat, 8 Feb 2014 02:14:28 +0000 (10:14 +0800)]
ARM: dts: imx: specify the value of audmux pinctrl instead of 0x80000000
We must specify the value of audmux pinctrl if we want to use pinctrl_pm().
Thus change bypass value 0x80000000 to what we exactly need.
This patch also seperately unset PUE bit for TXD so that IOMUX won't pull
up/down the pin after turning into tristate. When we use SSI normal mode to
playback monaural audio via I2S signal, there'd be a pulled curve occur to
its signal at the second slot if setting PUE bit for TXD. And it will make
the second channel to play a constant noise. So by keeping the signal level
in the second slot, we can get a constant high level signal (-1) or a low
level one (0).
Shawn Guo [Fri, 7 Feb 2014 15:22:50 +0000 (23:22 +0800)]
ARM: dts: imx6: use generic node name for fixed regulator
The device tree specification recommends that generic name should be
used for nodes. So instead of naming those fixed regulator nodes
arbitrarily, let's use the generic name 'regulator@num' for those nodes.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
[shawn.guo: cherry-pick commit 56160e3361c6 from upstream]
Shawn Guo [Mon, 4 Nov 2013 02:49:04 +0000 (10:49 +0800)]
ARM: dts: imx6sl: make pinctrl nodes board specific
Currently, all pinctrl setting nodes are defined in <soc>.dtsi, so that
boards that share the same pinctrl setting do not have to define it time
and time again in <board>.dts. However, along with the devices and use
cases being added continuously, the pinctrl setting nodes under iomuxc
becomes more than expected. This bloats device tree blob for particular
board unnecessarily since only a small subset of those pinctrl setting
nodes will be used by the board. It impacts not only the DTB file size
but also the run-time device tree lookup efficiency.
The patch moves all the pinctrl data into individual boards as needed.
With the changes, the pinctrl setting nodes becomes local to particular
board, and it makes no sense to continue numbering the setting for
given peripheral. Thus, all the pinctrl phandler name gets updated to
have only peripheral name in there.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
[shawn.guo: cherry-pick from commit fffaa65dc463 upstream]
Shawn Guo [Wed, 23 Oct 2013 07:36:09 +0000 (15:36 +0800)]
ARM: dts: imx6qdl: make pinctrl nodes board specific
Currently, all pinctrl setting nodes are defined in <soc>.dtsi, so that
boards that share the same pinctrl setting do not have to define it time
and time again in <board>.dts. However, along with the devices and use
cases being added continuously, the pinctrl setting nodes under iomuxc
becomes more than expected. This bloats device tree blob for particular
board unnecessarily since only a small subset of those pinctrl setting
nodes will be used by the board. It impacts not only the DTB file size
but also the run-time device tree lookup efficiency.
The patch moves all the pinctrl data into individual boards as needed.
With the changes, the pinctrl setting nodes becomes local to particular
board, and it makes no sense to continue numbering the setting for
given peripheral. Thus, all the pinctrl phandler name gets updated to
have only peripheral name in there.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
[shawn.guo: cherry-pick commit 817c27a128e1 from upstream]
Anson Huang [Wed, 12 Feb 2014 09:57:02 +0000 (17:57 +0800)]
ARM: dts: imx6q: add 852MHz setpoint for CPU freq
According to datasheet, i.MX6Q has setpoint of 852MHz
which is exclusive with 996MHz, the fuse map of speed_grading
defines the max speed of ARM, here we add this 852MHz
setpoint opp info, kernel will check the speed_grading
fuse and remove all illegal setpoints.
Anson Huang [Thu, 19 Dec 2013 14:16:48 +0000 (09:16 -0500)]
ARM: dts: imx6q: add vddsoc/pu setpoint info
i.MX6Q needs to update vddarm, vddsoc/pu regulators when cpu freq
is changed, each setpoint has different voltage, so we need to
pass vddarm, vddsoc/pu's freq-voltage info from dts together.
Anson Huang [Mon, 16 Dec 2013 21:07:37 +0000 (16:07 -0500)]
ARM: dts: imx6q: update setting of VDDARM_CAP voltage
According to datasheet, VDD_CACHE_CAP must not exceed VDDARM_CAP
by more than 200mV, as all of i.MX6Q boards' VDD_CACHE_CAP currently
are connected to VDDSOC_CAP, so we need to follow this rule by
increasing VDDARM_CAP's voltage.
It's quite common on i.MX that one gate bit controls the gating of
multiple clocks, i.e. this is a shared gate. The patch adds the
function imx_clk_gate2_shared() for such case. The clocks controlled
by the same gate bits should call this function with a pointer to a
single share count variable, so that the gate bits will only be
operated on the first enabling and the last disabling of these shared
gate clocks.
Thanks to Gerhard Sittig <gsi@denx.de> for this idea.
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
[shawn.guo: cherry-pick commit f9f28cdf2167 from upstream]
The imx clk-gate2 driver implements an i.MX specific gate clock, which
has two bits controlling the gate states. While this is a completely
separate gate driver from the common clk-gate one, it reuses the common
clk_gate structure. Such reusing makes the extending of clk_gate2
clumsy. Let's define struct clk_gate2 on our own to make the driver
independent of the common clk-gate one, and ease the clk_gate2 extending
at a later time.
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
[shawn.guo: cherry-pick commit 54ee1471f820 from upstream]
Philipp Zabel [Mon, 14 Apr 2014 14:20:40 +0000 (16:20 +0200)]
ARM: i.MX6: ipu_di_sel clocks can set parent rates
To obtain exact pixel clocks, allow the DI clock selectors to influence
the PLLs that they are derived from.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
[shawn.guo: cherry-pick commit 4591b13289b5 from upstream]
Shawn Guo [Thu, 27 Feb 2014 08:30:24 +0000 (16:30 +0800)]
ARM: imx6: drop .text.head section annotation from headsmp.S
The function v7_secondary_startup() works just fine in .text section, so
there is no need to have .text.head section annotation at all. Drop it.
Suggested-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
[shawn.guo: cherry-pick commit c8ae7e9bfc8c from upstream]
Shawn Guo [Thu, 27 Feb 2014 08:00:55 +0000 (16:00 +0800)]
ARM: imx6: build suspend-imx6.o with CONFIG_SOC_IMX6
Even when CONFIG_SUSPEND is enabled, it makes no sense to build
suspend-imx6.o if none of i.MX6 support is built in. Let's build
suspend-imx6.o only when both CONFIG_SUSPEND and CONFIG_SOC_IMX6 are
enabled.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
[shawn.guo: cherry-pick commit 6a5637e52eca from upstream]
Shawn Guo [Wed, 26 Feb 2014 13:28:18 +0000 (21:28 +0800)]
ARM: imx6: call suspend_set_ops() from suspend routine
Rename function imx6q_ocram_suspend_init() to imx6q_suspend_init() and
call suspend_set_ops() from there. Now we get a centralized function
for suspend initialization.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
[shawn.guo: cherry-pick commit afc51f464306 from upstream]
Shawn Guo [Wed, 26 Feb 2014 11:57:56 +0000 (19:57 +0800)]
ARM: imx6: build headsmp.o only on CONFIG_SMP
With v7_cpu_resume() being moved out of headsmp.S, all the remaining
code in the file is only needed by CONFIG_SMP build. So we can control
the build of headsmp.o with only obj-$(CONFIG_SMP) now.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
[shawn.guo: cherry-pick commit facadba6a128 from upstream]
Shawn Guo [Wed, 26 Feb 2014 11:48:33 +0000 (19:48 +0800)]
ARM: imx6: move v7_cpu_resume() into suspend-imx6.S
The suspend-imx6.S is introduced recently for suspend low-level assembly
code. Since function v7_cpu_resume() is only used by suspend support,
it makes sense to move the function into suspend-imx6.S, and control the
build of the file with CONFIG_SUSPEND option.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
[shawn.guo: cherry-pick commit c356bdb407ba from upstream]
Anson Huang [Tue, 11 Feb 2014 08:25:48 +0000 (16:25 +0800)]
ARM: imx: avoid calling clk APIs in idle thread which may cause schedule
As clk_pllv3_wait_lock will call usleep_range, and the clk APIs
mutex lock may be held when CPU entering idle, so calling clk
APIs must be avoided in cpu idle thread, this is to avoid reschedule
warning in cpu idle, just access register directly to achieve that.
Shawn Guo [Thu, 6 Feb 2014 05:22:02 +0000 (13:22 +0800)]
ARM: imx6q: support ptp and rmii clock from pad
On imx6qdl, the ENET RMII and PTP clock can come from either internal
ANATOP/CCM or external clock source through pad GPIO_16. But in case
of the external clock source, bit IOMUXC_GPR1[21] needs to be cleared.
The patch adds the support for systems that use an external clock source
and distinguishes above two cases by checking if the PTP clock specified
in device tree is the one coming from the internal ANATOP/CCM.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
[shawn.guo: cherry-pick commit 810c0ca87909 from upstream]
Shawn Guo [Thu, 6 Feb 2014 03:28:58 +0000 (11:28 +0800)]
ARM: imx6q: remove unneeded clk lookups
Since commit (a94f8ec ARM: imx6q: remove board specific CLKO setup),
a number of clk lookups in imx6q clock driver is no longer needed.
Let's remove them.
The cpu0 lookup is also removed since we are now running imx6 cpufreq
driver and looking up clocks from device tree.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
[shawn.guo: cherry-pick commit b30c6d018094 from upstream]
The imx can support timer-based delays, so implement this.
Skips past jiffy calibration.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
[shawn.guo: cherry-pick commit 1119c84aa305 from upstream]
Anson Huang [Wed, 22 Jan 2014 07:14:47 +0000 (15:14 +0800)]
ARM: imx: add always-on clock array for i.mx6sl to maintain correct usecount
IPG, ARM and MMDC's clock should be enabled during kernel boot up,
so we need to maintain their usecount, otherwise, they may be
disabled unexpectedly if their children's clock are turned off, and
caused their parent PLLs also get disabled, which is incorrect.
Anson Huang [Fri, 17 Jan 2014 03:39:07 +0000 (11:39 +0800)]
ARM: imx: add suspend in ocram support for i.mx6sl
i.MX6SL's suspend in ocram function is derived from i.MX6Q,
it can lower the DDR IO power from ~10mA@1.2V to ~1mA@1.2V,
measured on i.MX6SL EVK board, SH5.
Anson Huang [Fri, 17 Jan 2014 03:39:06 +0000 (11:39 +0800)]
ARM: imx: add suspend in ocram support for i.mx6dl
i.MX6DL's suspend in ocram function is derived from i.MX6Q,
it can lower the DDR IO power from ~26mA@1.5V to ~15mA@1.5V,
measured on i.MX6DL SabreSD board, R25.
Anson Huang [Fri, 17 Jan 2014 03:39:05 +0000 (11:39 +0800)]
ARM: imx: add suspend in ocram support for i.mx6q
When system enter suspend, we can set the DDR IO to
high-Z state to save DDR IOs' power consumption, this
operation can save many power(from ~26mA@1.5V to ~15mA@1.5V,
measured on i.MX6Q SabreSD board, R25) of DDR IOs. To
achieve that, we need to copy the suspend code to ocram
and run the low level hardware related code(set DDR IOs
to high-Z state) in ocram.
If there is no ocram space available, then system will
still do suspend in external DDR, hence no DDR IOs will
be set to high-Z.
There should be no duplicate const specifiers for those static
constant character string arrays defined for clock mux options.
Also, the arrays are only taken as the 5th argument for the
imx_clk_mux() function, which is in the type of 'const char
**parents'. So, let's remove the 2nd const specifier right
after 'char'.
Anson Huang [Thu, 9 Jan 2014 08:03:16 +0000 (16:03 +0800)]
ARM: imx: add cpuidle support for i.mx6sl
Add cpuidle support for i.MX6SL, currently only support
two cpuidle levels(ARM wfi and WAIT mode), and add software
workaround for WAIT mode errata as below:
ERR005311 CCM: After exit from WAIT mode, unwanted interrupt(s) taken
during WAIT mode entry process could cause cache memory
corruption.
Software workaround:
To prevent this issue from occurring, software should ensure that
the ARM to IPG clock ratio is less than 12:5 (that is < 2.4x), before
entering WAIT mode.
Anson Huang [Tue, 7 Jan 2014 17:46:04 +0000 (12:46 -0500)]
ARM: imx: AHB rate must be set to 132MHz on i.mx6sl
The reset value of AHB divider is 3, so current AHB rate
is 99MHz which is not correct for kernel, need to ensure
AHB rate is 132MHz in clk driver, as ipg is sourcing from
AHB, and it should be 66MHz by default.
When we abort a transaction we iterate over all the ranges marked as dirty
in fs_info->freed_extents[0] and fs_info->freed_extents[1], clear them
from those trees, add them back (unpin) to the free space caches and, if
the fs was mounted with "-o discard", perform a discard on those regions.
Also, after adding the regions to the free space caches, a fitrim ioctl call
can see those ranges in a block group's free space cache and perform a discard
on the ranges, so the same issue can happen without "-o discard" as well.
This causes corruption, affecting one or multiple btree nodes (in the worst
case leaving the fs unmountable) because some of those ranges (the ones in
the fs_info->pinned_extents tree) correspond to btree nodes/leafs that are
referred by the last committed super block - breaking the rule that anything
that was committed by a transaction is untouched until the next transaction
commits successfully.
I ran into this while running in a loop (for several hours) the fstest that
I recently submitted:
[PATCH] fstests: add btrfs test to stress chunk allocation/removal and fstrim
The corruption always happened when a transaction aborted and then fsck complained
like this:
_check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent
*** fsck.btrfs output ***
Check tree block failed, want=94945280, have=0
Check tree block failed, want=94945280, have=0
Check tree block failed, want=94945280, have=0
Check tree block failed, want=94945280, have=0
Check tree block failed, want=94945280, have=0
read block failed check_tree_block
Couldn't open file system
In this case 94945280 corresponded to the root of a tree.
Using frace what I observed was the following sequence of steps happened:
1) transaction N started, fs_info->pinned_extents pointed to
fs_info->freed_extents[0];
4) transaction N commit starts, fs_info->pinned_extents now points to
fs_info->freed_extents[1], and transaction N completes;
5) transaction N + 1 starts;
6) eb is COWed, and btrfs_free_tree_block() called for this eb;
7) eb range (94945280 to 94945280 + 16Kb) is added to
fs_info->pinned_extents (fs_info->freed_extents[1]);
8) Something goes wrong in transaction N + 1, like hitting ENOSPC
for example, and the transaction is aborted, turning the fs into
readonly mode. The stack trace I got for example:
[112065.253935] [<ffffffff8140c7b6>] dump_stack+0x4d/0x66
[112065.254271] [<ffffffff81042984>] warn_slowpath_common+0x7f/0x98
[112065.254567] [<ffffffffa0325990>] ? __btrfs_abort_transaction+0x50/0x10b [btrfs]
[112065.261674] [<ffffffff810429e5>] warn_slowpath_fmt+0x48/0x50
[112065.261922] [<ffffffffa032949e>] ? btrfs_free_path+0x26/0x29 [btrfs]
[112065.262211] [<ffffffffa0325990>] __btrfs_abort_transaction+0x50/0x10b [btrfs]
[112065.262545] [<ffffffffa036b1d6>] btrfs_remove_chunk+0x537/0x58b [btrfs]
[112065.262771] [<ffffffffa033840f>] btrfs_delete_unused_bgs+0x1de/0x21b [btrfs]
[112065.263105] [<ffffffffa0343106>] cleaner_kthread+0x100/0x12f [btrfs]
(...)
[112065.264493] ---[ end trace dd7903a975a31a08 ]---
[112065.264673] BTRFS: error (device sdc) in btrfs_remove_chunk:2625: errno=-28 No space left
[112065.264997] BTRFS info (device sdc): forced readonly
9) The clear kthread sees that the BTRFS_FS_STATE_ERROR bit is set in
fs_info->fs_state and calls btrfs_cleanup_transaction(), which in
turn calls btrfs_destroy_pinned_extent();
10) Then btrfs_destroy_pinned_extent() iterates over all the ranges
marked as dirty in fs_info->freed_extents[], and for each one
it calls discard, if the fs was mounted with "-o discard", and
adds the range to the free space cache of the respective block
group;
11) btrfs_trim_block_group(), invoked from the fitrim ioctl code path,
sees the free space entries and performs a discard;
12) After an umount and mount (or fsck), our eb's location on disk was full
of zeroes, and it should have been untouched, because it was marked as
dirty in the fs_info->pinned_extents tree, and therefore used by the
trees that the last committed superblock points to.
Fix this by not performing a discard and not adding the ranges to the free space
caches - it's useless from this point since the fs is now in readonly mode and
we won't write free space caches to disk anymore (otherwise we would leak space)
nor any new superblock. By not adding the ranges to the free space caches, it
prevents other code paths from allocating that space and write to it as well,
therefore being safer and simpler.
We use the modified list to keep track of which extents have been modified so we
know which ones are candidates for logging at fsync() time. Newly modified
extents are added to the list at modification time, around the same time the
ordered extent is created. We do this so that we don't have to wait for ordered
extents to complete before we know what we need to log. The problem is when
something like this happens
log extent 0-4k on inode 1
copy csum for 0-4k from ordered extent into log
sync log
commit transaction
log some other extent on inode 1
ordered extent for 0-4k completes and adds itself onto modified list again
log changed extents
see ordered extent for 0-4k has already been logged
at this point we assume the csum has been copied
sync log
crash
On replay we will see the extent 0-4k in the log, drop the original 0-4k extent
which is the same one that we are replaying which also drops the csum, and then
we won't find the csum in the log for that bytenr. This of course causes us to
have errors about not having csums for certain ranges of our inode. So remove
the modified list manipulation in unpin_extent_cache, any modified extents
should have been added well before now, and we don't want them re-logged. This
fixes my test that I could reliably reproduce this problem with. Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com> Signed-off-by: Chris Mason <clm@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Chernenkov used KASAN to discover that eCryptfs writes past the
end of the allocated buffer during encrypted filename decoding. This
fix corrects the issue by getting rid of the unnecessary 0 write when
the current bit offset is 2.
The ecryptfs_encrypted_view mount option greatly changes the
functionality of an eCryptfs mount. Instead of encrypting and decrypting
lower files, it provides a unified view of the encrypted files in the
lower filesystem. The presence of the ecryptfs_encrypted_view mount
option is intended to force a read-only mount and modifying files is not
supported when the feature is in use. See the following commit for more
information:
This patch forces the mount to be read-only when the
ecryptfs_encrypted_view mount option is specified by setting the
MS_RDONLY flag on the superblock. Additionally, this patch removes some
broken logic in ecryptfs_open() that attempted to prevent modifications
of files when the encrypted view feature was in use. The check in
ecryptfs_open() was not sufficient to prevent file modifications using
system calls that do not operate on a file descriptor.
UDF specification allows arbitrarily large symlinks. However we support
only symlinks at most one block large. Check the length of the symlink
so that we don't access memory beyond end of the symlink block.
Reported-by: Carl Henrik Lunde <chlunde@gmail.com> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
alloc_pid() does get_pid_ns() beforehand but forgets to put_pid_ns() if it
fails because disable_pid_allocation() was called by the exiting
child_reaper.
We could simply move get_pid_ns() down to successful return, but this fix
tries to be as trivial as possible.
Signed-off-by: Oleg Nesterov <oleg@redhat.com> Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Aaron Tomlin <atomlin@redhat.com> Cc: Pavel Emelyanov <xemul@parallels.com> Cc: Serge Hallyn <serge.hallyn@ubuntu.com> Cc: Sterling Alexander <stalexan@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If some error happens in NCP_IOC_SETROOT ioctl, the appropriate error
return value is then (in most cases) just overwritten before we return.
This can result in reporting success to userspace although error happened.
This bug was introduced by commit 2e54eb96e2c8 ("BKL: Remove BKL from
ncpfs"). Propagate the errors correctly.
If a request is backlogged, it's complete() handler will get called
twice: once with -EINPROGRESS, and once with the final error code.
af_alg's complete handler, unlike other users, does not handle the
-EINPROGRESS but instead always completes the completion that recvmsg()
is waiting on. This can lead to a return to user space while the
request is still pending in the driver. If userspace closes the sockets
before the requests are handled by the driver, this will lead to
use-after-frees (and potential crashes) in the kernel due to the tfm
having been freed.
The crashes can be easily reproduced (for example) by reducing the max
queue length in cryptod.c and running the following (from
http://www.chronox.de/libkcapi.html) on AES-NI capable hardware:
A regression was caused by commit 780a7654cee8:
audit: Make testing for a valid loginuid explicit.
(which in turn attempted to fix a regression caused by e1760bd)
When audit_krule_to_data() fills in the rules to get a listing, there was a
missing clause to convert back from AUDIT_LOGINUID_SET to AUDIT_LOGINUID.
This broke userspace by not returning the same information that was sent and
expected.
The rule:
auditctl -a exit,never -F auid=-1
gives:
auditctl -l
LIST_RULES: exit,never f24=0 syscall=all
when it should give:
LIST_RULES: exit,never auid=-1 (0xffffffff) syscall=all
Tag it so that it is reported the same way it was set. Create a new
private flags audit_krule field (pflags) to store it that won't interact with
the public one from the API.
Signed-off-by: Richard Guy Briggs <rgb@redhat.com> Signed-off-by: Paul Moore <pmoore@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A security fix in caused the way the unprivileged remount tests were
using user namespaces to break. Tweak the way user namespaces are
being used so the test works again.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now that setgroups can be disabled and not reenabled, setting gid_map
without privielge can now be enabled when setgroups is disabled.
This restores most of the functionality that was lost when unprivileged
setting of gid_map was removed. Applications that use this functionality
will need to check to see if they use setgroups or init_groups, and if they
don't they can be fixed by simply disabling setgroups before writing to
gid_map.
Reviewed-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
- Expose the knob to user space through a proc file /proc/<pid>/setgroups
A value of "deny" means the setgroups system call is disabled in the
current processes user namespace and can not be enabled in the
future in this user namespace.
A value of "allow" means the segtoups system call is enabled.
- Descendant user namespaces inherit the value of setgroups from
their parents.
- A proc file is used (instead of a sysctl) as sysctls currently do
not allow checking the permissions at open time.
- Writing to the proc file is restricted to before the gid_map
for the user namespace is set.
This ensures that disabling setgroups at a user namespace
level will never remove the ability to call setgroups
from a process that already has that ability.
A process may opt in to the setgroups disable for itself by
creating, entering and configuring a user namespace or by calling
setns on an existing user namespace with setgroups disabled.
Processes without privileges already can not call setgroups so this
is a noop. Prodcess with privilege become processes without
privilege when entering a user namespace and as with any other path
to dropping privilege they would not have the ability to call
setgroups. So this remains within the bounds of what is possible
without a knob to disable setgroups permanently in a user namespace.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If you did not create the user namespace and are allowed
to write to uid_map or gid_map you should already have the necessary
privilege in the parent user namespace to establish any mapping
you want so this will not affect userspace in practice.
Limiting unprivileged uid mapping establishment to the creator of the
user namespace makes it easier to verify all credentials obtained with
the uid mapping can be obtained without the uid mapping without
privilege.
Limiting unprivileged gid mapping establishment (which is temporarily
absent) to the creator of the user namespace also ensures that the
combination of uid and gid can already be obtained without privilege.
This is part of the fix for CVE-2014-8989.
Reviewed-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
setresuid allows the euid to be set to any of uid, euid, suid, and
fsuid. Therefor it is safe to allow an unprivileged user to map
their euid and use CAP_SETUID privileged with exactly that uid,
as no new credentials can be obtained.
I can not find a combination of existing system calls that allows setting
uid, euid, suid, and fsuid from the fsuid making the previous use
of fsuid for allowing unprivileged mappings a bug.
This is part of a fix for CVE-2014-8989.
Reviewed-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As any gid mapping will allow and must allow for backwards
compatibility dropping groups don't allow any gid mappings to be
established without CAP_SETGID in the parent user namespace.
For a small class of applications this change breaks userspace
and removes useful functionality. This small class of applications
includes tools/testing/selftests/mount/unprivilged-remount-test.c
Most of the removed functionality will be added back with the addition
of a one way knob to disable setgroups. Once setgroups is disabled
setting the gid_map becomes as safe as setting the uid_map.
For more common applications that set the uid_map and the gid_map
with privilege this change will have no affect.
This is part of a fix for CVE-2014-8989.
Reviewed-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
setgroups is unique in not needing a valid mapping before it can be called,
in the case of setgroups(0, NULL) which drops all supplemental groups.
The design of the user namespace assumes that CAP_SETGID can not actually
be used until a gid mapping is established. Therefore add a helper function
to see if the user namespace gid mapping has been established and call
that function in the setgroups permission check.
This is part of the fix for CVE-2014-8989, being able to drop groups
without privilege using user namespaces.
Reviewed-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The rule is simple. Don't allow anything that wouldn't be allowed
without unprivileged mappings.
It was previously overlooked that establishing gid mappings would
allow dropping groups and potentially gaining permission to files and
directories that had lesser permissions for a specific group than for
all other users.
This is the rule needed to fix CVE-2014-8989 and prevent any other
security issues with new_idmap_permitted.
The reason for this rule is that the unix permission model is old and
there are programs out there somewhere that take advantage of every
little corner of it. So allowing a uid or gid mapping to be
established without privielge that would allow anything that would not
be allowed without that mapping will result in expectations from some
code somewhere being violated. Violated expectations about the
behavior of the OS is a long way to say a security issue.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
projects / karo-tx-linux.git / log