Change the chip id definition and detection and then:
1. We no longer need to add PM800_CHIP_XXX for the coming revision.
2. We no longer need to pass driver_data in i2c_device_id as we
can distinguish the chips from the CHIP_ID register.
Signed-off-by: Chao Xie <chao.xie@marvell.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.
Signed-off-by: Matt Porter <mporter@ti.com>
Acked-by: Chris Ball <cjb@laptop.org> # davinci_mmc.c
Acked-by: Mark Brown <broonie@linaro.org>
Acked-by: Olof Johansson <olof@lixom.net>
[nsekhar@ti.com: dropped davinci sffsdr changes]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
This set of headers comes from commit ab23167f (current master of the
project on ohwr.org). They define the basic data structures for FMC
and its SDB support.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
Acked-by: Juan David Gonzalez Cobas <dcobas@cern.ch>
Acked-by: Emilio G. Cota <cota@braap.org>
Acked-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This is the driver for the USB comparator built into the palmas chip. It
handles the various USB OTG events that can be generated by cable
insertion/removal.
Signed-off-by: Graeme Gregory <gg@slimlogic.co.uk>
Signed-off-by: Moiz Sonasath <m-sonasath@ti.com>
Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: George Cherian <george.cherian@ti.com>
[kishon@ti.com: adapted palmas usb driver to use the extcon framework]
Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Myungjoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
88pm800 has two addtional pages - power and gpadc.
The address of the pages depends on the address of 88pm800.
So do not need pass the address of the power and gpadc in
platform data.
Signed-off-by: Chao Xie <chao.xie@marvell.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The wm8997 is a compact, high-performance audio hub CODEC with SLIMbus
interfacing, for smartphones, tablets and other portable audio devices
based on the Arizona platform.
This patch integrates the wm8997 into the Arizona mfd.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The Tegra EHCI driver directly calls various functions in the Tegra USB
PHY driver. The reverse is also true; the PHY driver calls into the EHCI
driver. This is problematic when the two are built as modules.
The calls from the PHY to EHCI driver were originally added in commit
bbdabdb "usb: add APIs to access host registers from Tegra PHY", for the
following reasons:
1) The register being touched is an EHCI register, so logically only the
EHCI driver should touch it.
2) (1) implies that some locking may be needed to correctly implement the
r/m/w access to this shared register.
3) We were expecting to pass only the PHY register space to the Tegra PHY
driver, and hence it would not have access to touch the shared
registers.
To solve this, that commit added functions in the EHCI driver to touch the
shared register on behalf of the PHY driver.
In practice, we ended up not having any locking in the implementaiton of
those functions, and I've been led to believe this is safe. Equally, (3)
did not happen either. Hence, it is possible for the PHY driver to touch
the shared register directly.
Given that, this patch moves the code to touch the shared register back
into the PHY driver, to eliminate the module problems. If we actually
need locking or co-ordination in the future, I propose we put the lock
support into some pre-existing core module, or into a third separate
module, in order to avoid the circular dependencies.
I apologize for my contribution to code churn here.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Even if a chipidea core is otg capable the board may not be. This allows
to explicitly set the core to host/peripheral mode. Without these flags
the driver falls back to the old behaviour.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch makes it possible to configure the PTW, PTS and STS bits
inside the portsc register for host and device mode before the driver
starts and the phy can be addressed as hardware implementation is
designed.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We had the limit of 255 USB to serial devices on one system for almost
15 years, with no complaints. But now it's time to move on from these
tiny "baby" systems, and bump the number up to 512, which should last
us a few more years:
"512 is a nice number" -- Tobias Winter
Note, this is still a static value, and uses up tty core memory with
this many tty devices allocated. Converting the driver to use
TTY_DRIVER_DYNAMIC_DEV is the next thing to do in order to remove this
limitation.
Reported-by: Tobias Winter <tobias@linuxdingsda.de>
Tested-by: Tobias Winter <tobias@linuxdingsda.de>
Reviewed-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This moves the allocation of minor device numbers from a static array to
be dynamic, using the idr interface. This means that you could
potentially get "gaps" in a minor number range for a single USB serial
device with multiple ports, but all should still work properly.
We remove the 'minor' field from the usb_serial structure, as it no
longer makes any sense for it (use the field in the usb_serial_port
structure if you really want to know this number), and take the fact
that we were overloading a number in this field to determine if we had
initialized the minor numbers or not, and just use a flag variable
instead.
Note, we still have the limitation of 255 USB to serial devices in the
system, as that is all we are registering with the TTY layer at this
point in time.
Tested-by: Tobias Winter <tobias@linuxdingsda.de>
Reviewed-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
minimum_to_wake is unique to N_TTY processing, and belongs in
per-ldisc data.
Add the ldisc method, ldisc_ops::fasync(), to notify line disciplines
when signal-driven I/O is enabled or disabled. When enabled for N_TTY
(by fcntl(F_SETFL, O_ASYNC)), blocking reader/polls will be woken
for any readable input. When disabled, blocking reader/polls are not
woken until the read buffer is full.
Canonical mode (L_ICANON(tty), n_tty_data::icanon) is not affected by
the minimum_to_wake setting.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This data allow writing for example MTD driver.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It is counter-intuitive to have "0" mean disable in a boolean
manner for electronic properties of pins such as pull-up and
pull-down. Therefore, define that a pull-up/pull-down argument
of 0 to such a generic option means that the pin is
short-circuited to VDD or GROUND. Pull disablement shall be
done using PIN_CONFIG_BIAS_DISABLE.
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by Heiko Stuebner <heiko@sntech.de>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The comment introduced with the recently added pinctrl_gpio_range.pins
element was wrong. This corrects it.
Thanks to Patrice Chotard for pointing this out.
Signed-off-by: Christian Ruppert <christian.ruppert@abilis.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The stubs for the !PINCTRL case were placed in the wrong
part of the file, causing breakage in linux-next when compiling
SH without pinctrl. Fix it up by moving the stubs to the right
place.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Traditionally, GPIO ranges are based on consecutive ranges of both GPIO
and pin numbers. This patch allows for GPIO ranges with arbitrary lists
of pin numbers.
Signed-off-by: Christian Ruppert <christian.ruppert@abilis.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This deletes the dependency on any platform data for
the COH901 pin controller. There is only one user in the
kernel, and if we at some point want to support more
variants, they shall provide their variant info through
the device tree.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
percpu-refcount was incorrectly using preempt_disable/enable() for RCU
critical sections against call_rcu(). 6a24474da8 ("percpu-refcount:
consistently use plain (non-sched) RCU") fixed it by converting the
preepmtion operations with rcu_read_[un]lock() citing that there isn't
any advantage in using sched-RCU over using the usual one; however,
rcu_read_[un]lock() for the preemptible RCU implementation -
CONFIG_TREE_PREEMPT_RCU, chosen when CONFIG_PREEMPT - are slightly
more expensive than preempt_disable/enable().
In a contrived microbench which repeats the followings,
- percpu_ref_get()
- copy 32 bytes of data into percpu buffer
- percpu_put_get()
- copy 32 bytes of data into percpu buffer
rcu_read_[un]lock() used in percpu_ref_get/put() makes it go slower by
about 15% when compared to using sched-RCU.
As the RCU critical sections are extremely short, using sched-RCU
shouldn't have any latency implications. Convert to RCU-sched.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Kent Overstreet <koverstreet@google.com>
Acked-by: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Rusty Russell <rusty@rustcorp.com.au>
If a device have sleep and idle states in addition to the
default state, look up these in the core and stash them in
the pinctrl state container.
Add accessor functions for pinctrl consumers to put the pins
into "default", "sleep" and "idle" states passing nothing but
the struct device * affected.
Solution suggested by Kevin Hilman, Mark Brown and Dmitry
Torokhov in response to a patch series from Hebbar
Gururaja.
Cc: Hebbar Gururaja <gururaja.hebbar@ti.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
There exist controllers that don't support to set the pull to up or down
separately but instead automatically set the pull direction based on
embedded knowledge inside the controller, for example depending on the
selected mux function of the pin.
Therefore this patch adds another config option to use this default
pull-state for a pin where it is not possible to know or decide if the
pin will be pulled up or down.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add a new PIN_CONFIG_BIAS_BUS_HOLD pin configuration for a bus holder
pin mode (also known as bus keeper, or repeater). This is a weak latch
which drives the last value on a tristate bus. Another device on the bus
can drive the bus high or low before going tristate to change the value
driven by the pin.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
In Rockchip Cortex-A9 based chips, they don't use paradigm of
reading-changing-writing the register contents. Instead they
use a hiword mask to indicate the changed bits.
When b1 should be set as gate, it also needs to indicate the change
by setting hiword mask (b1 << 16).
The patch adds gate flag for this usage.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
In both Hisilicon & Rockchip Cortex-A9 based chips, they don't use the
paradigm of reading-changing-writing the register contents.
Instead they use a hiword mask to indicate the changed bits.
When b01 should be set as setting divider, it also needs to indicate
the change by setting hiword mask (b11 << 16).
The patch adds divider flag for this usage.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
In both Hisilicon & Rockchip Cortex-A9 based chips, they don't use the
paradigm of reading-changing-writing the register contents.
Instead they use a hiword mask to indicate the changed bits.
When b01 should be set as switching mux, it also needs to indicate
the change by setting hiword mask (b11 << 16).
The patch adds mux flag for this usage.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Thanks to commit f91eb62f71 ("init: scream bloody murder if interrupts
are enabled too early"), "bloody murder" is now being screamed.
With a MIPS OCTEON config, we use on_each_cpu() in our
irq_chip.irq_bus_sync_unlock() function. This gets called in early as a
result of the time_init() call. Because the !SMP version of
on_each_cpu() unconditionally enables irqs, we get:
WARNING: at init/main.c:560 start_kernel+0x250/0x410()
Interrupts were enabled early
CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.0-rc5-Cavium-Octeon+ #801
Call Trace:
show_stack+0x68/0x80
warn_slowpath_common+0x78/0xb0
warn_slowpath_fmt+0x38/0x48
start_kernel+0x250/0x410
Suggested fix: Do what we already do in the SMP version of
on_each_cpu(), and use local_irq_save/local_irq_restore. Because we
need a flags variable, make it a static inline to avoid name space
issues.
[ Change from v1: Convert on_each_cpu to a static inline function, add
#include <linux/irqflags.h> to avoid build breakage on some files.
on_each_cpu_mask() and on_each_cpu_cond() suffer the same problem as
on_each_cpu(), but they are not causing !SMP bugs for me, so I will
defer changing them to a less urgent patch. ]
Signed-off-by: David Daney <david.daney@cavium.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
From Simon Horman:
Renesas ARM based SoC GPIO R-Car updates for v3.11
DT support to GPIO R-Car driver by Laurent Pinchart.
* tag 'renesas-gpio-rcar-for-v3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: (131 commits)
gpio-rcar: Add DT support
From Simon Horman:
Renesas USB updates for v3.11
These updates are by Sergei Shtylyov to clean-up USB support
present for R8A7779/Marzen and then extend USB support coverage to
R8A7778/BOCK-W.
* tag 'renesas-phy-rcar-usb-for-v3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
ARM: shmobile: BOCK-W: add USB support
ARM: shmobile: r8a7778: add USB support
phy-rcar-usb: add R8A7778 support
phy-rcar-usb: handle platform data
ARM: shmobile: Marzen: pass platform data to USB PHY device
phy-rcar-usb: add platform data
phy-rcar-usb: correct base address
ARM: shmobile: r8a7779: remove USB PHY 2nd memory resource
phy-rcar-usb: remove EHCI internal buffer setup
ARM: shmobile: r8a7779: setup EHCI internal buffer
ehci-platform: add pre_setup() method to platform data
ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code
Conflicts:
arch/arm/mach-shmobile/board-marzen.c
arch/arm/mach-shmobile/setup-r8a7778.c
Signed-off-by: Olof Johansson <olof@lixom.net>
From Linus Walleij:
Second set of DMA40 changes: refactorings and device tree
support for the DMA40. Now with MUSB and some platform
data removal.
* tag 'ux500-dma40-for-arm-soc-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson:
dmaengine: ste_dma40: Fetch disabled channels from DT
dmaengine: ste_dma40: Fetch the number of physical channels from DT
ARM: ux500: Stop passing DMA platform data though AUXDATA
dmaengine: ste_dma40: Allow memcpy channels to be configured from DT
dmaengine: ste_dma40_ll: Replace meaningless register set with comment
dmaengine: ste_dma40: Convert data_width from register bit format to value
dmaengine: ste_dma40_ll: Use the BIT macro to replace ugly '(1 << x)'s
ARM: ux500: Remove recently unused stedma40_xfer_dir enums
dmaengine: ste_dma40: Replace ST-E's home-brew DMA direction defs with generic ones
ARM: ux500: Replace ST-E's home-brew DMA direction definition with the generic one
dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
ARM: ux500: Remove empty function u8500_of_init_devices()
ARM: ux500: Remove ux500-musb platform registation when booting with DT
usb: musb: ux500: add device tree probing support
usb: musb: ux500: attempt to find channels by name before using pdata
usb: musb: ux500: harden checks for platform data
usb: musb: ux500: take the dma_mask from coherent_dma_mask
usb: musb: ux500: move the MUSB HDRC configuration into the driver
usb: musb: ux500: move channel number knowledge into the driver
From Tony Lindgren:
Omap SoC changes. Mostly improves am33xx support, and adds
minimal support for am43x SoCs.
* tag 'omap-for-v3.11/soc-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP2+: AM43x: SRAM base and size
ARM: OMAP2+: AM43x: GP or HS ?
ARM: OMAP2+: AM43x: early init
ARM: OMAP2+: AM43x: static mapping
ARM: OMAP2+: AM437x: SoC revision detection
ARM: OMAP2+: AM43x: soc_is support
ARM: OMAP2+: AM43x: kbuild
ARM: OMAP2+: AM43x: Kconfig
ARM: OMAP2+: separate out OMAP4 restart
ARM: AM33XX: clk: Add clock node for EHRPWM TBCLK
ARM: OMAP3: clock data: get rid of unused USB host clock aliases and dummies
ARM: OMAP2+: AM33xx: Add missing reset status info to GFX hwmod
+ Linux 3.10-rc5
Signed-off-by: Olof Johansson <olof@lixom.net>
From Tony Lindgren:
Move omap4 over to device tree based booting. This allows us to get rid
a big pile of platform init code for things that are already handled by
device tree related code. As am33xx is already device tree based, we
can also remove the same data for am33xx.
* tag 'omap-for-v3.11/cleanup-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP4: hwmod data: Remove irq entries from mcspi, mmc hwmods
ARM: OMAP4: hwmod data: add DSS data back
ARM: OMAP4: hwmod data: Clean up the data file
ARM: AM33XX: hwmod data: irq, dma and addr info clean up
ARM: OMAP2+: Remove omap4 ocp2scp pdata
ARM: OMAP2+: Remove omap4 pdata for USB
ARM: OMAP2+: Remove omap4 pdata from hsmmc.c
ARM: OMAP2+: Remove legacy mux data for omap4
ARM: OMAP2+: Remove board-omap4panda.c
ARM: OMAP2+: Remove board-4430sdp.c
ARM: OMAP2+: Legacy support for wl12xx when booted with devicetree
Resolved merge conflict due to a fix for 3.10 (the fix is removed since
the code is no longer used -- data comes from device tree).
Signed-off-by: Olof Johansson <olof@lixom.net>
Pulling in a set of fixes from Tony Lindgren to resolve conflicts with later
cleanup branch:
A set of small fixes for omaps for the -rc cycle:
- am7303 iva2 reset PM regression fix
- am33xx uart2 dma channel fix
- am33xx gpmc properties fix
- omap44xx rtc wake-up mux fix for nirq pins
- omap36xx clock divider restore fix
There's also one tiny non-critical .dts fix for omap5
timer pwm properties.
* tag 'omap-for-v3.10/fixes-v3.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: omap3: clock: fix wrong container_of in clock36xx.c
ARM: dts: OMAP5: Fix missing PWM capability to timer nodes
ARM: dts: omap4-panda|sdp: Fix mux for twl6030 IRQ pin and msecure line
ARM: dts: AM33xx: Fix properties on gpmc node
arm: omap2: fix AM33xx hwmod infos for UART2
+ Linux 3.10-rc4
Signed-off-by: Olof Johansson <olof@lixom.net>
From Tony Lindgren:
Non-critical fixes for omaps for v3.11 merge window.
* tag 'omap-for-v3.11/fixes-non-critical-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP2+: omap-usb-host: Fix memory leaks
ARM: OMAP2+: Fix serial init for device tree based booting
arm/omap: use const char properly
ARM: OMAP2+: devices: Do not print error when dss_hdmi hwmod lookup fails
ARM: OMAP2+: devices: Do not print error when DMIC hwmod lookup fails
ARM: OMAP2+: devices: Do not print error when McPDM hwmod lookup fails
ARM: OMAP: add vdds_sdi supply for omapdss_sdi.0
ARM: OMAP: add vdds_dsi supply for omapdss_dpi.0
ARM: OMAP: fix dsi regulator names
+ Linux 3.10-rc5
Signed-off-by: Olof Johansson <olof@lixom.net>
All Transparent Huge Pages are allocated by the buddy allocator.
A compile time check is in place that fails when the order of a
transparent huge page is too large to be allocated by the buddy
allocator. Unfortunately that compile time check passes when:
HPAGE_PMD_ORDER == MAX_ORDER
( which is incorrect as the buddy allocator can only allocate
memory of order strictly less than MAX_ORDER. )
This patch updates the compile time check to fail in the above
case.
Signed-off-by: Steve Capper <steve.capper@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Under x86, multiple puds can be made to reference the same bank of
huge pmds provided that they represent a full PUD_SIZE of shared
huge memory that is aligned to a PUD_SIZE boundary.
The code to share pmds does not require any architecture specific
knowledge other than the fact that pmds can be indexed, thus can
be beneficial to some other architectures.
This patch copies the huge pmd sharing (and unsharing) logic from
x86/ to mm/ and introduces a new config option to activate it:
CONFIG_ARCH_WANTS_HUGE_PMD_SHARE
Signed-off-by: Steve Capper <steve.capper@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
f12dc02014 ("cgroup: mark "tasks" cgroup file as insane") and
cc5943a781 ("cgroup: mark "notify_on_release" and "release_agent"
cgroup files insane") forgot to update the changed behavior
documentation in cgroup.h. Update it.
Signed-off-by: Tejun Heo <tj@kernel.org>
A css (cgroup_subsys_state) is how each cgroup is represented to a
controller. As such, it can be used in hot paths across the various
subsystems different controllers are associated with.
One of the common operations is reference counting, which up until now
has been implemented using a global atomic counter and can have
significant adverse impact on scalability. For example, css refcnt
can be gotten and put multiple times by blkcg for each IO request.
For highops configurations which try to do as much per-cpu as
possible, the global frequent refcnting can be very expensive.
In general, given the various and hugely diverse paths css's end up
being used from, we need to make it cheap and highly scalable. In its
usage, css refcnting isn't very different from module refcnting.
This patch converts css refcnting to use the recently added
percpu_ref. css_get/tryget/put() directly maps to the matching
percpu_ref operations and the deactivation logic is no longer
necessary as percpu_ref already has refcnt killing.
The only complication is that as the refcnt is per-cpu,
percpu_ref_kill() in itself doesn't ensure that further tryget
operations will fail, which we need to guarantee before invoking
->css_offline()'s. This is resolved collecting kill confirmation
using percpu_ref_kill_and_confirm() and initiating the offline phase
of destruction after all css refcnt's are confirmed to be seen as
killed on all CPUs. The previous patches already splitted destruction
into two phases, so percpu_ref_kill_and_confirm() can be hooked up
easily.
This patch removes css_refcnt() which is used for rcu dereference
sanity check in css_id(). While we can add a percpu refcnt API to ask
the same question, css_id() itself is scheduled to be removed fairly
soon, so let's not bother with it. Just drop the sanity check and use
rcu_dereference_raw() instead.
v2: - init_cgroup_css() was calling percpu_ref_init() without checking
the return value. This causes two problems - the obvious lack
of error handling and percpu_ref_init() being called from
cgroup_init_subsys() before the allocators are up, which
triggers warnings but doesn't cause actual problems as the
refcnt isn't used for roots anyway. Fix both by moving
percpu_ref_init() to cgroup_create().
- The base references were put too early by
percpu_ref_kill_and_confirm() and cgroup_offline_fn() put the
refs one extra time. This wasn't noticeable because css's go
through another RCU grace period before being freed. Update
cgroup_destroy_locked() to grab an extra reference before
killing the refcnts. This problem was noticed by Kent.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Kent Overstreet <koverstreet@google.com>
Acked-by: Li Zefan <lizefan@huawei.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Mike Snitzer <snitzer@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: "Alasdair G. Kergon" <agk@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Mikulas Patocka <mpatocka@redhat.com>
Cc: Glauber Costa <glommer@gmail.com>
Chao Xie