LSK 16.06 v4.4-android
* tag 'lsk-v4.4-16.06-android': (447 commits)
Linux 4.4.14
netfilter: x_tables: introduce and use xt_copy_counters_from_user
netfilter: x_tables: do compat validation via translate_table
netfilter: x_tables: xt_compat_match_from_user doesn't need a retval
netfilter: ip6_tables: simplify translate_compat_table args
netfilter: ip_tables: simplify translate_compat_table args
netfilter: arp_tables: simplify translate_compat_table args
netfilter: x_tables: don't reject valid target size on some architectures
netfilter: x_tables: validate all offsets and sizes in a rule
netfilter: x_tables: check for bogus target offset
netfilter: x_tables: check standard target size too
netfilter: x_tables: add compat version of xt_check_entry_offsets
netfilter: x_tables: assert minimum target size
netfilter: x_tables: kill check_entry helper
netfilter: x_tables: add and use xt_check_entry_offsets
netfilter: x_tables: validate targets of jumps
netfilter: x_tables: don't move to non-existent next rule
drm/core: Do not preserve framebuffer on rmfb, v4.
crypto: qat - fix adf_ctl_drv.c:undefined reference to adf_init_pf_wq
netfilter: x_tables: fix unconditional helper
...
The dw_mmc driver stores the physical address of the MMIO registers
in a pointer, which requires the use of type casts, and is actually
broken if anyone ever has this device on a 32-bit SoC in registers
above 4GB. Gcc warns about this possibility when the driver is built
with ARM LPAE enabled:
mmc/host/dw_mmc.c: In function 'dw_mci_edmac_start_dma':
mmc/host/dw_mmc.c:702:17: warning: cast from pointer to integer of different size
cfg.dst_addr = (dma_addr_t)(host->phy_regs + fifo_offset);
^
mmc/host/dw_mmc-pltfm.c: In function 'dw_mci_pltfm_register':
mmc/host/dw_mmc-pltfm.c:63:19: warning: cast to pointer from integer of different size
host->phy_regs = (void *)(regs->start);
This changes the code to use resource_size_t, which gets rid of the
warning, the bug and the useless casts.
Change-Id: I894c49cede8f0626efb80a9a3181a5385bbb2bcd
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 260b316436)
We've unfortunately started seeing a situation where percpu interrupts
are partitioned in the system: one arbitrary set of CPUs has an
interrupt connected to a type of device, while another disjoint
set of CPUs has the same interrupt connected to another type of device.
This makes it impossible to have a device driver requesting this interrupt
using the current percpu-interrupt abstraction, as the same interrupt number
is now potentially claimed by at least two drivers, and we forbid interrupt
sharing on per-cpu interrupt.
A solution to this is to turn things upside down. Let's assume that our
system describes all the possible partitions for a given interrupt, and
give each of them a unique identifier. It is then possible to create
a namespace where the affinity identifier itself is a form of interrupt
number. At this point, it becomes easy to implement a set of partitions
as a cascaded irqchip, each affinity identifier being the HW irq.
This allows us to keep a number of nice properties:
- Each partition results in a separate percpu-interrupt (with a restrictied
affinity), which keeps drivers happy.
- Because the underlying interrupt is still per-cpu, the overhead of
the indirection can be kept pretty minimal.
- The core code can ignore most of that crap.
For that purpose, we implement a small library that deals with some of
the boilerplate code, relying on platform-specific drivers to provide
a description of the affinity sets and a set of callbacks.
Conflicts:
drivers/irqchip/Kconfig
drivers/irqchip/Makefile
Change-Id: Ie6b2bc8c4c152f0dcd3fbcab8950fae781338322
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Rob Herring <robh+dt@kernel.org>
Link: http://lkml.kernel.org/r/1460365075-7316-4-git-send-email-marc.zyngier@arm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(cherry picked from commit 9e2c986cb4)
When iterating over the irq domain list, we try to match a domain
either by calling a match() function or by comparing a number
of fields passed as parameters.
Both approaches are a bit restrictive:
- match() is DT specific and only takes a device node
- the fallback case only deals with the fwnode_handle
It would be useful if we had a per-domain function that would
actually perform the matching check on the whole of the
irq_fwspec structure. This would allow for a domain to triage
matching attempts that need to extend beyond the fwnode.
Let's introduce irq_find_matching_fwspec(), which takes a full
blown irq_fwspec structure, and call into a select() function
implemented by the irqdomain. irq_find_matching_fwnode() is
made a wrapper around irq_find_matching_fwspec in order to
preserve compatibility.
Change-Id: I07df9af068d114c80cd97b9cb987a70c0e24afda
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Rob Herring <robh+dt@kernel.org>
Link: http://lkml.kernel.org/r/1460365075-7316-2-git-send-email-marc.zyngier@arm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(cherry picked from commit 651e8b54ab)
Let's take the (outlandish) example of an interrupt controller
capable of handling both wired interrupts and PCI MSIs.
With the current code, the PCI MSI domain is going to be tagged
with DOMAIN_BUS_PCI_MSI, and the wired domain with DOMAIN_BUS_ANY.
Things get hairy when we start looking up the domain for a wired
interrupt (typically when creating it based on some firmware
information - DT or ACPI).
In irq_create_fwspec_mapping(), we perform the lookup using
DOMAIN_BUS_ANY, which is actually used as a wildcard. This gives
us one chance out of two to end up with the wrong domain, and
we try to configure a wired interrupt with the MSI domain.
Everything grinds to a halt pretty quickly.
What we really need to do is to start looking for a domain that
would uniquely identify a wired interrupt domain, and only use
DOMAIN_BUS_ANY as a fallback.
In order to solve this, let's introduce a new DOMAIN_BUS_WIRED
token, which is going to be used exactly as described above.
Of course, this depends on the irqchip to setup the domain
bus_token, and nobody had to implement this so far.
Only so far.
Change-Id: Ia71c7475354eb38ab9b15423560aa3d28ae16381
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Link: http://lkml.kernel.org/r/1453816347-32720-2-git-send-email-marc.zyngier@arm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(cherry picked from commit 530cbe100e)
Since there will be several places checking if fwnode.type
is equal FWNODE_IRQCHIP, this patch adds a convenient function
for this purpose.
Change-Id: I65ab9e1350428de18864ba493256b959efc01f45
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(cherry picked from commit 75aba7b0e9)
This patch adds the DMA_ATTR_ALLOC_SINGLE_PAGES attribute to the
DMA-mapping subsystem.
This attribute can be used as a hint to the DMA-mapping subsystem that
it's likely not worth it to try to allocate large pages behind the
scenes. Large pages are likely to make an IOMMU TLB work more
efficiently but may not be worth it. See the Documentation contained in
this patch for more details about this attribute and when to use it.
Note that the name of the hint (DMA_ATTR_ALLOC_SINGLE_PAGES) is loosely
based on the name MADV_NOHUGEPAGE. Just as there is MADV_NOHUGEPAGE
vs. MADV_HUGEPAGE we could also add an "opposite" attribute to
DMA_ATTR_ALLOC_SINGLE_PAGES. Without having the "opposite" attribute
the lack of DMA_ATTR_ALLOC_SINGLE_PAGES means "use your best judgement
about whether to use small pages or large pages".
BUG=chromium:570532
TEST=Stress memory and watch cat videos.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
(am from https://patchwork.kernel.org/patch/8007151/)
Reviewed-on: https://chromium-review.googlesource.com/322334
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Change-Id: I9d0af41446b5c41d6f39a2b77e711179d0b40eca
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
When set to 1 for CAPTURE queues by the driver on calling vb2_queue_init(),
forces the buffers on the queue to be allocated/mapped with
DMA_BIDIRECTIONAL DMA direction flag, instead of DMA_FROM_DEVICE. This
allows the device not only to write to the buffers, but also read out from
them. This may be useful e.g. for codec hardware, which may be using
CAPTURE buffers as reference to decode other buffers.
This flag is ignored for OUTPUT queues, as we don't want to allow HW to
be able to write to OUTPUT buffers.
Signed-off-by: Pawel Osciak <posciak@chromium.org>
BUG=chrome-os-partner:45346
TEST=video playback
Reviewed-on: https://chromium-review.googlesource.com/300726
Commit-Ready: Pawel Osciak <posciak@chromium.org>
Tested-by: Pawel Osciak <posciak@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Change-Id: Ifba955eef75ac23c9a13edab04bc1fe7f5375c70
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Some drivers also need a control like
V4L2_CID_MPEG_MFC51_VIDEO_FORCE_FRAME_TYPE to force an encoder
key frame. Add a general V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME
so the new drivers and applications can use it.
Signed-off-by: Wu-Cheng Li <wuchengli@chromium.org>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
(cherry picked from commit 0c8485ca3f2aaf7842d45ba24c667a9492c9900f)
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium:572825
TEST=Build and boot oak-rev5 to UI
TEST=emerge-smaug chromeos-kernel-3_18
Reviewed-on: https://chromium-review.googlesource.com/328870
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Change-Id: I45de3048d41edbe443b3d202c17e79f2d448213b
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
DMA allocations might be subject to certain reqiurements specific to the
hardware using the buffers, such as availability of kernel mapping (for
contents fix-ups in the driver). The only entity that knows them is the
driver, so it must share this knowledge with vb2-dc.
This patch extends the alloc_ctx initialization interface to let the
driver specify DMA attrs, which are then stored inside the allocation
context and will be used for all allocations with that context.
As a side effect, all dma_*_coherent() calls are turned into
dma_*_attrs() calls, because the attributes need to be carried over
through all DMA operations.
BUG=chrome-os-partner:38873
TEST=compile
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/265363
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Change-Id: I0e6c040cf820c194b6ca6f3e6355217496bd1532
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
When queuing buffers allow for passing the configuration store ID that
should be associated with this buffer. Use the 'reserved2' field for this.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
BUG=chrome-os-partner:33728
TEST=build
Signed-off-by: Pawel Osciak <posciak@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232583
Trybot-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Wu-cheng Li <wuchengli@chromium.org>
Commit-Queue: Tomasz Figa <tfiga@chromium.org>
Conflicts:
drivers/media/v4l2-core/videobuf2-core.c
[rebase44(groeck): fixed conflicts; structural changes to match v4.4]
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Conflicts:
drivers/media/v4l2-core/v4l2-compat-ioctl32.c
Change-Id: Ibb823e9369bec79645e09651b0dda006ed53ecc5
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
The ctrl_class is fairly pointless when used with drivers that use the control
framework: you can just fill in 0 and it will just work fine. There are still
some old unconverted drivers that do not support 0 and instead want the control
class there. The idea being that all controls in the list all belong to that
class. This was done to simplify drivers in the absence of the control framework.
When using the control framework the framework itself is smart enough to allow
controls of any class to be included in the control list.
Since configuration store IDs are in the range 1..255 (or so, in any case a relatively
small non-zero positive integer) it makes sense to effectively rename ctrl_class
to config_store. Set it to 0 and you get the normal behavior (you change the current
control value), set it to a configuration store ID and you get/set the control for
that store.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
BUG=chrome-os-partner:33728
TEST=build
Signed-off-by: Pawel Osciak <posciak@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232582
Trybot-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Wu-cheng Li <wuchengli@chromium.org>
Commit-Queue: Tomasz Figa <tfiga@chromium.org>
Conflicts:
include/uapi/linux/videodev2.h
Change-Id: I862bb5796e27bcbbd055e22202ac9a1ed0cc6f7d
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Set the newly added id for i2s_src, so that they can be called
in other parts.
Change-Id: Ie4ecc4d19e3ae64a07d1f2a80aa08d40f38d09ad
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
This misc update would try to fix below comments from my eDP thread[0],
and lucky to say this version is stable, and i'm start to perpare the
pull request to David with this version. So i guess it's time to create
a misc FIXUP patch to address the comments.
[0]: https://patchwork.kernel.org/patch/9175613/
- Correct the misspell of "marcos" in commit message (Dominik, reviewed at Google Gerrit)
- Write a kerneldoc-style comment explaining the chips data fields (Tomasz, reviewed at Google Gerrit)
- Drop the '.lcdcsel_mask' number in chips data field (Tomasz, reviewed at Google Gerrit)
- Make this hack code more clear (Tomasz, reviewed at Google Gerrit)
reg = ~reg & REF_CLK_MASK; ---> reg ^= REF_CLK_MASK;
- Give the "rk3399-edp" a separate line for clarity in document (Tomasz, reviewed at Google Gerrit)
- Move 'output_type' setting before the return statement (Tomasz, reviewed at Google Gerrit)
- Avoid to change any internal driver state in .mode_valid interface. (Tomasz, reviewed at Google Gerrit)
- Hook the connector's color_formats in .get_modes directly. (Tomasz, reviewed at Google Gerrit)
Change-Id: Ic35f166ebac04e417ff3d135e7bf4573bbca2004
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
This patch adds a helper to parse the encoder endpoint connected to the
encoder's crtc and two helpers to return its id and port id.
This can be used to determine input mux setting from endpoint or port ids.
Change-Id: I48eb7c66edb951af40085e4e388afbd5d4b2c77b
Suggested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
(cherry pick from commit 4cacf91fcb)
commit d7591f0c41 upstream.
The three variants use same copy&pasted code, condense this into a
helper and use that.
Make sure info.name is 0-terminated.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ce683e5f9d upstream.
We're currently asserting that targetoff + targetsize <= nextoff.
Extend it to also check that targetoff is >= sizeof(xt_entry).
Since this is generic code, add an argument pointing to the start of the
match/target, we can then derive the base structure size from the delta.
We also need the e->elems pointer in a followup change to validate matches.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fc1221b3a1 upstream.
32bit rulesets have different layout and alignment requirements, so once
more integrity checks get added to xt_check_entry_offsets it will reject
well-formed 32bit rulesets.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7d35812c32 upstream.
Currently arp/ip and ip6tables each implement a short helper to check that
the target offset is large enough to hold one xt_entry_target struct and
that t->u.target_size fits within the current rule.
Unfortunately these checks are not sufficient.
To avoid adding new tests to all of ip/ip6/arptables move the current
checks into a helper, then extend this helper in followup patches.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dd5f1b049d upstream.
The INTID mask is wrong, and is made a signed value, which has
nteresting effects in the KVM emulation. Let's sanitize it.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 7e059158d5 ]
Prior to 4.3, openvswitch tunnel vports (vxlan, gre and geneve) could
transmit vxlan packets of any size, constrained only by the ability to
send out the resulting packets. 4.3 introduced netdevs corresponding
to tunnel vports. These netdevs have an MTU, which limits the size of
a packet that can be successfully encapsulated. The default MTU
values are low (1500 or less), which is awkwardly small in the context
of physical networks supporting jumbo frames, and leads to a
conspicuous change in behaviour for userspace.
Instead, set the MTU on openvswitch-created netdevs to be the relevant
maximum (i.e. the maximum IP packet size minus any relevant overhead),
effectively restoring the behaviour prior to 4.3.
Signed-off-by: David Wragg <david@weave.works>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit da4ed55165 ]
The problem is that fib_info->nh is [0] so the struct fib_info
allocation size depends on number of nexthops. If we just copy fib_info,
we do not copy the nexthops info and driver accesses memory which is not
ours.
Given the fact that fib4 does not defer operations and therefore it does
not need copy, just pass the pointer down to drivers as it was done
before.
Fixes: 850d0cbc91 ("switchdev: remove pointers from switchdev objects")
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The hdmi-codec is a platform device driver to be registered from
drivers of external HDMI encoders with I2S and/or spdif interface. The
driver in turn registers an ASoC codec for the HDMI encoder's audio
functionality.
The structures and definitions in the API header are mostly redundant
copies of similar structures in ASoC headers. This is on purpose to
avoid direct dependencies to ASoC structures in video side driver.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Acked-by: PC Liao <pc.liao@mediatek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 09184118a8)
Change-Id: I4fc0651b732c2604df58cb2e0ec5f5edeecdf412
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Add IEC958 channel status helper that gets the audio properties from
snd_pcm_hw_params instead of snd_pcm_runtime. This is needed to
produce the channel status bits already in audio stream configuration
phase.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 4a4436573a)
Change-Id: Ie19500cd63fb311ec273035c336acc8c568d84db
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
This patch exports related MAC clocks for dts reference.
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git
v4.8-shared/clkids commit 9ff59360b8)
Change-Id: Ib6f5f2a0ccd19a8b71c384abddacadbd4da291bb
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
There are four clocks that vop module would need to operate:
DCLK_VOP, HCLK_VOP, SCLK_VOP, ACLK_VOP,
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git
v4.8-shared/clkids commit 31b1fed36e)
Change-Id: Iea57109b85928c4139283e366ce5d60430e8984b
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
This patch adds 'SCLK_TSADC' and 'PCLK_TSADC' id found on rk3228 SoCs.
That will be needed by TSADC controller.
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Acked-by: Michael Turquette <mturquette@baylibre.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git
v4.8-clk/next commit 3629e70b8c)
Change-Id: Ia4c926d4decc9affd63510a794d7f2553f6be3a5
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Add the dt-bindings header for the rk3228, that gets shared between
the clock controller and the clock references in the dts.
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git
v4.8-shared/clkids commit abf1296599)
Change-Id: Id164aa064046276f22dc763c746e9e85c344cd81
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Some information, like driver specific configuration, is found
in the perf event structure. As such pass a 'struct perf_event'
to function setup_aux() rather than just the CPU number so that
individual drivers can make the right configuration when setting
up a session.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
It is entirely possible that some PMUs need specific configuration
that is currently not found in the perf options before a session
can be setup.
It is the case for the CoreSight PMU where a sink needs to be
provided. That sink doesn't fall in any of the current perf
options.
As such this patch adds the capability to receive driver
specific configuration using the existing ioctl() mechanism.
Once the configuration has been pushed down the kernel PMU
callbacks are used to deal with the information sent from user
space.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
The DMAengine API has a long standing race condition that is inherent to
the API itself. Calling dmaengine_terminate_all() is supposed to stop and
abort any pending or active transfers that have previously been submitted.
Unfortunately it is possible that this operation races against a currently
running (or with some drivers also scheduled) completion callback.
Since the API allows dmaengine_terminate_all() to be called from atomic
context as well as from within a completion callback it is not possible to
synchronize to the execution of the completion callback from within
dmaengine_terminate_all() itself.
This means that a user of the DMAengine API does not know when it is safe
to free resources used in the completion callback, which can result in a
use-after-free race condition.
This patch addresses the issue by introducing an explicit synchronization
primitive to the DMAengine API called dmaengine_synchronize().
The existing dmaengine_terminate_all() is deprecated in favor of
dmaengine_terminate_sync() and dmaengine_terminate_async(). The former
aborts all pending and active transfers and synchronizes to the current
context, meaning it will wait until all running completion callbacks have
finished. This means it is only possible to call this function from
non-atomic context. The later function does not synchronize, but can still
be used in atomic context or from within a complete callback. It has to be
followed up by dmaengine_synchronize() before a client can free the
resources used in a completion callback.
In addition to this the semantics of the device_terminate_all() callback
are slightly relaxed by this patch. It is now OK for a driver to only
schedule the termination of the active transfer, but does not necessarily
have to wait until the DMA controller has completely stopped. The driver
must ensure though that the controller has stopped and no longer accesses
any memory when the device_synchronize() callback returns.
This was in part done since most drivers do not pay attention to this
anyway at the moment and to emphasize that this needs to be done when the
device_synchronize() callback is implemented. But it also helps with
implementing support for devices where stopping the controller can require
operations that may sleep.
Change-Id: Ica0822ecbe803ec9605787e30751dfb098bdbe80
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(cherry picked from git.kernel.org next/linux-next.git master
commit b36f09c3c4)
