During own review but also reported by Dmitry's syzkaller [1] it has been
noticed that we trigger a heap out-of-bounds access on eBPF array maps
when updating elements. This happens with each map whose map->value_size
(specified during map creation time) is not multiple of 8 bytes.
In array_map_alloc(), elem_size is round_up(attr->value_size, 8) and
used to align array map slots for faster access. However, in function
array_map_update_elem(), we update the element as ...
memcpy(array->value + array->elem_size * index, value, array->elem_size);
... where we access 'value' out-of-bounds, since it was allocated from
map_update_elem() from syscall side as kmalloc(map->value_size, GFP_USER)
and later on copied through copy_from_user(value, uvalue, map->value_size).
Thus, up to 7 bytes, we can access out-of-bounds.
Same could happen from within an eBPF program, where in worst case we
access beyond an eBPF program's designated stack.
Since 1be7f75d16 ("bpf: enable non-root eBPF programs") didn't hit an
official release yet, it only affects priviledged users.
In case of array_map_lookup_elem(), the verifier prevents eBPF programs
from accessing beyond map->value_size through check_map_access(). Also
from syscall side map_lookup_elem() only copies map->value_size back to
user, so nothing could leak.
[1] http://github.com/google/syzkaller
Fixes: 28fbcfa08d ("bpf: add array type of eBPF maps")
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Passing -1 as the pipe for vblank events now triggers a WARN_ON, but had
previously made multi-screen unusable anyway. Pass the correct pipe to
the event-send function, and use the new API to make this a bit easier
for us.
Fixes WARN present since cc1ef118fc for every pageflip event sent:
[ 209.549969] ------------[ cut here ]------------
[ 209.554592] WARNING: CPU: 3 PID: 238 at drivers/gpu/drm/drm_irq.c:924 drm_vblank_count_and_time+0x80/0x88 [drm]()
[ 209.564832] Modules linked in: [...]
[ 209.612401] CPU: 3 PID: 238 Comm: irq/41-ff940000 Tainted: G W 4.3.0-rc6+ #71
[ 209.620647] Hardware name: Rockchip (Device Tree)
[ 209.625348] [<c001bb80>] (unwind_backtrace) from [<c001615c>] (show_stack+0x20/0x24)
[ 209.633079] [<c001615c>] (show_stack) from [<c02b2c50>] (dump_stack+0x8c/0x9c)
[ 209.640289] [<c02b2c50>] (dump_stack) from [<c0052e88>] (warn_slowpath_common+0x94/0xc4)
[ 209.648364] [<c0052e88>] (warn_slowpath_common) from [<c0052f74>] (warn_slowpath_null+0x2c/0x34)
[ 209.657139] [<c0052f74>] (warn_slowpath_null) from [<bf17dc30>] (drm_vblank_count_and_time+0x80/0x88 [drm])
[ 209.666875] [<bf17dc30>] (drm_vblank_count_and_time [drm]) from [<bf17e484>] (drm_send_vblank_event+0x74/0x7c [drm])
[ 209.677385] [<bf17e484>] (drm_send_vblank_event [drm]) from [<bf4c1144>] (vop_win_state_complete+0x4c/0x70 [rockchip_drm_vop])
[ 209.688757] [<bf4c1144>] (vop_win_state_complete [rockchip_drm_vop]) from [<bf4c3bdc>] (vop_isr_thread+0x170/0x1d4 [rockchip_drm_vop])
[ 209.700822] [<bf4c3bdc>] (vop_isr_thread [rockchip_drm_vop]) from [<c00ab93c>] (irq_thread_fn+0x2c/0x50)
[ 209.710284] [<c00ab93c>] (irq_thread_fn) from [<c00abcac>] (irq_thread+0x13c/0x188)
[ 209.717927] [<c00abcac>] (irq_thread) from [<c00723c8>] (kthread+0xec/0x104)
[ 209.724965] [<c00723c8>] (kthread) from [<c0011638>] (ret_from_fork+0x14/0x3c)
[ 209.732171] ---[ end trace 0690bc604f5d535d ]---
Signed-off-by: Daniel Stone <daniels@collabora.com>
Cc: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Heiko Stuebner <heiko@sntech.de>
Tested-By: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Thierry Reding <treding@nvidia.com>
So far, only the bus clock has been assigned, but in reality the
SAI IP has for clock inputs. The driver has been updated to
make use of the additional clock inputs by c3ecef21c3 ("ASoC:
fsl_sai: add sai master mode support"). Due to a bug in the
clock tree, the audio clock has been enabled none the less by
the specified bus clock (see "ARM: imx: clk-vf610: fix SAI
clock tree"), which made master mode even without the proper
clock assigned working.
This patch completes the clock definition for SAI2. On Vybrid,
only two MCLK out of the four options are available (the first
being the bus clock itself). See chapter 8.10.1.2.3 of the
Vybrid Reference manual ("SAI transmitter and receiver options
for MCLK selection"). Note: The audio clocks are only required
in master mode.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The Synchronous Audio Interface (SAI) instances are clocked by
independent clocks: The bus clock and the audio clock (as shown in
Figure 51-1 in the Vybrid Reference Manual). The clock gates in
CCGR0/CCGR1 for SAI0 through SAI3 are bus clock gates, as access
tests to the registers with/without gating those clocks have shown.
The audio clock is gated by the SAIx_EN gates in CCM_CSCDR1,
followed by a clock divider (SAIx_DIV). Currently, the parent of
the bus clock gates has been assigned to SAIx_DIV, which is not
involved in the bus clock path for the SAI instances (see chapter
9.10.12, SAI clocking in the Vybrid Reference Manual).
Fix this by define the parent clock of VF610_CLK_SAIx to be the bus
clock.
If the driver needs the audio clock (when used in master mode), a
fixed device tree is required which assign the audio clock properly
to VF610_CLK_SAIx_DIV.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Commit 4d6b4e69a2 ("x86/PCI/ACPI: Use common interface to support
PCI host bridge") converted x86 to use the common interface
acpi_pci_root_create, but the conversion missed on code piece in
arch/x86/pci/bus_numa.c, which causes regression on some legacy
AMD platforms as reported by Arthur Marsh <arthur.marsh@internode.on.net>.
The root causes is that acpi_pci_root_create() fails to insert
host bridge resources into iomem_resource/ioport_resource because
x86_pci_root_bus_resources() has already inserted those resources.
So change x86_pci_root_bus_resources() to not insert resources into
iomem_resource/ioport_resource.
Fixes: 4d6b4e69a2 ("x86/PCI/ACPI: Use common interface to support PCI host bridge")
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Reported-and-tested-by: Arthur Marsh <arthur.marsh@internode.on.net>
Reported-and-tested-by: Krzysztof Kolasa <kkolasa@winsoft.pl>
Reported-and-tested-by: Keith Busch <keith.busch@intel.com>
Reported-and-tested-by: Hans de Bruin <jmdebruin@xmsnet.nl>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
VOP_WINx_DSP_ST does not require subtracting 1 from the values written to
it. It actually causes the screen to be shifted by one pixel.
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Tested-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Dominik Behr <dbehr@chromium.org>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Commit 371f0f085f ("ARM: 8426/1: dma-mapping: add missing range check
in dma_mmap()") introduced offset-checking for mappings, which collides
with the fake-offset the drm sets for gems.
Other drm-drivers set this offset to 0 before doing the mapping, so
this looks like the correct way to go for rockchip as well.
Fixes: 371f0f085f ("ARM: 8426/1: dma-mapping: add missing range check in dma_mmap()")
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Most rk3368 boards (especially those with Pmic that followed the lead
from rk3368-evb-act8846) have a PWM regulator on them for vdd_logic.
This is the main voltage for all kinds of misc stuff including the
memory controller.
On these boards it is critically important to make sure that the PWM
never ever glitches and never loses its clock. Any glitch could
crash the system.
Right now there are no users of the PWM regulator and also Linux
thinks that the PWM regulator is disabled. Things happen to work
because firmware configured the PWM and Linux doesn't touch it.
..and the PWM's clock is marked as "ignore unused".
...but things _stop_ working if we turn off serial console. Why?
Because:
1. Serial console shares a parent clock with the PWM (pclk_cpu)
2. If we have no serial console then nobody is holding pclk_cpu on
at reboot time. It gets disabled.
We need to fix a lot of the above problems, but until we get
everything right the cleanest "hack" seems like it is to just keep
the "rk_pwm" clock on always.
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
This board is similar with the rk3288 evb board but the rk3368 top
board. There exist the act8846 as the pmic.
Moment, add the balight/thermal/emmc/usb.. stuff,
Let the board can happy work.
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The pulse-width modulator (PWM) feature is very common in
embedded systems. On the rk3368 there exist 4 built-in PWM channels.
In general, the pwm pins can via the pinctrl to
configure iomux mode except the pwm2 since the pwm2 iomux mode from
the SoC control register.
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Commit 8306095fd2 ("USB: Disable USB 3.0 LPM in critical sections.")
adds usb3_lpm_enabled member to struct usb_device. There is no reference
to this member now. Hence, it could be removed.
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB3 LPM is default on in Linux kernel if both xHCI host controller
and the USB devices declare to be LPM-capable. Unfortunately, some
devices are known to work well with LPM disabled, but to be broken
if LPM is enabled, although it declares the LPM capability. Users
won't be able to use this kind of devices, until someone puts them
in the kernel blacklist and gets the kernel upgraded.
This patch adds a sysfs node to permit or forbit USB3 LPM U1 or U2
entry for a port. The settings apply to both before and after device
enumeration. Supported values are "0" - neither u1 nor u2 permitted,
"u1" - only u1 is permitted, "u2" - only u2 is permitted, "u1_u2" -
both u1 and u2 are permitted. With this interface, users can use an
LPM-unfriendly USB device on a released Linux kernel.
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Zhuang Jin Can <jin.can.zhuang@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 655fe4effe ("usbcore: add sysfs support to xHCI usb3
hardware LPM") introduced usb3_hardware_lpm sysfs node. This
doesn't show the correct status of USB3 U1 and U2 LPM status.
This patch fixes this by replacing usb3_hardware_lpm with two
nodes, usb3_hardware_lpm_u1 (for U1) and usb3_hardware_lpm_u2
(for U2), and recording the U1/U2 LPM status in right places.
This patch should be back-ported to kernels as old as 4.3,
that contains Commit 655fe4effe ("usbcore: add sysfs support
to xHCI usb3 hardware LPM").
Cc: stable@vger.kernel.org
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch sets the AHBMODE to allow for posted data writes. This
results in higher performance.
Signed-off-by: Andy Gross <agross@codeaurora.org>
Tested-by: Georgi Djakov <georgi.djakov@linaro.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch sets the AHBMODE to allow for posted data writes. This
results in higher performance.
Signed-off-by: Andy Gross <agross@codeaurora.org>
Acked-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
struct mon_bin_hdr allows for a 64-bit seconds timestamp. The code
currently uses 'struct timeval' to populate the timestamp in mon_bin_hdr,
which has a 32-bit seconds field and will overflow in year 2038 and beyond.
This patch replaces 'struct timeval' with 'struct timespec64' which is
y2038 safe. This patch is part of a larger attempt to remove instances
of struct timeval and other 32-bit timekeeping (time_t, struct timespec)
from the kernel.
Signed-off-by: Tina Ruchandani <ruchandani.tina@gmail.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
timeval is deprecated and not y2038 safe. Its size also changes according
to 32 bit/ 64 bit compilation. Replace it with 32 and 64 bit versions of
its individual fields, giving two ioctls with different code values.
The two ioctls are necessary to maintain the 32 bit and 64 bit userspace
compatibility with a 64/32 bit kernel.
Change unsigned to __u32 types for a definitive userspace interface.
This is in accordance with the psABI that the unsigned type is always
32 bits.
Also use motonic timer instead of real time to ensure positive delta
values.
Refactor usbtest_ioctl for readability to isolate the handling of the
testing timing measurement.
The official testusb userspace tool can be changed in a separate patch
to reflect the __u32 changes as well. It can use the usbtest_param_32
struct, since 32 bit seconds is long enough for test durations.
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
struct timeval' uses 32-bits for its seconds field and will overflow in
the year 2038 and beyond. This patch replaces the usage of 'struct timeval'
in mon_get_timestamp() with timespec64 which uses a 64-bit seconds field
and is y2038-safe. mon_get_timestamp() truncates the timestamp at 4096 seconds,
so the correctness of the code is not affected. This patch is part of a larger
attempt to remove instances of struct timeval and other 32-bit timekeeping
(time_t, struct timespec) from the kernel.
Signed-off-by: Tina Ruchandani <ruchandani.tina@gmail.com>
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
So far we were using simple (legacy) GPIO functions & some poor logic to
control power. It got many drawbacks: we were ignoring OF flags
(GPIO_ACTIVE_LOW), we were not setting direction to output and we were
assuming gpio_request success all the time.
Fix it by switching to gpiod functions and adding appropriate checks.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb_parse_ss_endpoint_companion() now decodes the burst multiplier
correctly in order to check that it's <= 3, but still uses the wrong
expression if warning that it's > 3.
Fixes: ff30cbc8da ("usb: Use the USB_SS_MULT() macro to get the ...")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
qset_fill_page_list() do not check for dma mapping errors.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When a USB 3.0 mass storage device is disconnected in transporting
state, storage device driver may handle it as a transport error and
reset the device by invoking usb_reset_and_verify_device()
and following could happen:
in usb_reset_and_verify_device():
udev->bos = NULL;
For U1/U2 enabled devices, driver will disable LPM, and in some
conditions:
from usb_unlocked_disable_lpm()
--> usb_disable_lpm()
--> usb_enable_lpm()
udev->bos->ss_cap->bU1devExitLat;
And it causes 'NULL pointer' and 'kernel panic':
[ 157.976257] Unable to handle kernel NULL pointer dereference
at virtual address 00000010
...
[ 158.026400] PC is at usb_enable_link_state+0x34/0x2e0
[ 158.031442] LR is at usb_enable_lpm+0x98/0xac
...
[ 158.137368] [<ffffffc0006a1cac>] usb_enable_link_state+0x34/0x2e0
[ 158.143451] [<ffffffc0006a1fec>] usb_enable_lpm+0x94/0xac
[ 158.148840] [<ffffffc0006a20e8>] usb_disable_lpm+0xa8/0xb4
...
[ 158.214954] Kernel panic - not syncing: Fatal exception
This commit moves 'udev->bos = NULL' behind usb_unlocked_disable_lpm()
to prevent from NULL pointer access.
Issue can be reproduced by following setup:
1) A SS pen drive behind a SS hub connected to the host.
2) Transporting data between the pen drive and the host.
3) Abruptly disconnect hub and pen drive from host.
4) With a chance it crashes.
Signed-off-by: Hans Yang <hansy@nvidia.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On ixp4xx, the readl() function returns an 'unsigned long' output
when indirect I/O is used. This is unlike any other platform, and
it causes lots of harmless compiler warnings, such as:
drivers/ata/libahci.c: In function 'ahci_show_host_version':
drivers/ata/libahci.c:254:22: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
drivers/block/mtip32xx/mtip32xx.c: In function 'mtip_hw_read_registers':
drivers/block/mtip32xx/mtip32xx.c:2602:31: warning: format '%X' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
drivers/block/cciss.c: In function 'print_cfg_table':
drivers/block/cciss.c:3845:25: warning: format '%d' expects argument of type 'int', but argument 4 has type 'long unsigned int' [-Wformat=]
This changes all six of the ixp4xx specific I/O read functions
to return the same types that we have in the normal asm/io.h,
to avoid the warnings.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Krzysztof Halasa <khalasa@piap.pl>
The usb_mon_operations structure is never modified, so declare it as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now the function of complicated_callback is not only used for iso
transfer, improve the error message to reflect it.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
for checking if a property is present or not,
of_property_read_bool is more appropriate than of_get_property()
Signed-off-by: Saurabh Sengar <saurabh.truth@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This function must be called with a spinlock held.
Memory can be allocated only with GFP_ATOMIC. Passing
a gfp_t argument is a waste.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use this macro to make the driver more readable.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
BXT power well support is not yet stable. Starting with patch
commit 9f836f9016
Author: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Date: Mon Nov 16 16:20:01 2015 +0100
drm/i915/gen9: Turn DC handling into a power well
DPMS off operations may actually cause the entire system to powerdown or
reboot. Disable power well support for now until Broxton gets fixes
similar to what we have for SKL.
Cc: Imre Deak <imre.deak@intel.com>
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
References: http://lists.freedesktop.org/archives/intel-gfx/2015-November/081037.html
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448990818-11005-1-git-send-email-matthew.d.roper@intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
The dma_pool_destroy() function tests whether its argument is NULL
and then returns immediately. Thus the test around the calls is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
replace dma_pool_alloc and memset with a single call to dma_pool_zalloc
Signed-off-by: Saurabh Sengar <saurabh.truth@gmail.com>
Acked-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
uwbd() calls try_to_freeze(), but the thread doesn't mark itself freezable
through set_freezable(), so the try_to_freeze() call is useless.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
All ELAN hid devices seem to require the ALWAYS_POLL quirk. Let's use
this quirk for all devices from this vendor, rather than maintaining a
list of all its known product IDs.
Tested-by: Adrien Vergé <adrienverge@gmail.com>
Signed-off-by: Adrien Vergé <adrienverge@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This adds tlv bytes topology control creation and control load to
initialize kcontrol data. And this also adds the callbacks for
the these tlv byte kcontrols
Signed-off-by: Mythri P K <mythri.p.k@intel.com>
Signed-off-by: Divya Prakash <divya1.prakash@intel.com>
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This adds support to configure module parameter during module
initialization or after module init using set module param
required by the DSP firmware sequence.
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some DSP modules has user configurable parameters, which are
required by some modules at module initialization.
To configure the module algorithm parameter during initialization
we add helpers here
Signed-off-by: Divya Prakash <divya1.prakash@intel.com>
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some DSP modules have user configurable parameters. These
parameters are required by modules in the following scenario
- during initialization
- after initialization using set parameter
This patch adds helper routine to set module parameters using
large config set IPC message and removes params to be passed as
init module routine.
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
On Skylake we can support upton 4DMICs on the PDM port, so update
the PCM capabilities accordingly
Also add a new DAI for DMIC pin which can be used for getting raw
DMIC data
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Dharageswari.R <dharageswari.r@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch is specifically for PCI support on the Versatile PB board using
a DT. Currently, the dynamic IRQ mapping is broken when using DTs. For
example, on QEMU, the SCSI driver is unable to request the IRQ. To fix
this issue, this patch replaces the current dynamic mechanism with a
static value as is done in the non-DT case.
Signed-off-by: Guillaume Delbergue <guillaume.delbergue@greensocs.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: stable@vger.kernel.org
This patch enables the QCOM SPMI and PMIC related drivers that are now
required to boot some supported devices.
Signed-off-by: Andy Gross <agross@codeaurora.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Many ARM sub-architectures use prompts followed by "if" conditional,
but it is wrong.
Please notice the difference between
config ARCH_FOO
bool "Foo SoCs" if ARCH_MULTI_V7
and
config ARCH_FOO
bool "Foo SoCs"
depends on ARCH_MULTI_V7
These two are *not* equivalent!
In the former statement, it is not ARCH_FOO, but its prompt that
depends on ARCH_MULTI_V7. So, it is completely valid that ARCH_FOO
is selected by another, but ARCH_MULTI_V7 is still disabled. As it is
not unmet dependency, Kconfig never warns. This is probably not what
you want.
The former should be used only when you need to do so, and you really
understand what you are doing. (In most cases, it should be wrong!)
For enabling/disabling sub-architectures, the latter is always correct.
As a good side effect, this commit fixes some entries over 80 columns
(mach-imx, mach-integrator, mach-mbevu).
[Arnd: I note that there is not really a bug here, according to
the discussion that followed, but I can see value in being consistent
and in making the lines shorter]
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Patrice Chotard <patrice.chotard@st.com>
Acked-by: Liviu Dudau <Liviu.Dudau@arm.com>
Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: Jun Nie <jun.nie@linaro.org>
Acked-by: Matthias Brugger <matthias.bgg@gmail.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: Shawn Guo <shawnguo@kernel.org>
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Acked-by: Krzysztof Halasa <khc@piap.pl>
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The ARM core kernel already calls clocksource_of_init() so why
go to all the trouble of locating and probing this node in the
machine. CLOCKSOURCE_OF_DECLARE() will take care of it in the
clocksource driver, and thus we can also get rid of the
dangling header file <linux/clksrc-dbx500-prcmu.h>
Suggested-by: Arnd Bergmann <arndb@linaro.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
These three structures are only defined and referenced in
mach-hisi/platsmp.c.
Drop the declarations from the header and add static qualifier
to the definitions.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Wei Xu <xuwei5@hisilicon.com>
The set_event_pid filter relies on attaching to the sched_switch and
sched_wakeup tracepoints to see if it should filter the tracing on schedule
tracepoints. By adding the callbacks to sched_wakeup, pids in the
set_event_pid file will trace the wakeups of those tasks with those pids.
But sched_wakeup_new and sched_waking were missed. These two should also be
traced. Luckily, these tracepoints share the same class as sched_wakeup
which means they can use the same pre and post callbacks as sched_wakeup
does.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
The 'sc' ISDN driver relies on using readl() to access ISA I/O memory.
This has been deprecated and produced warnings since linux-2.3.23,
disabled by default since 2.4.10 and finally removed in 2.6.5.
I found this because the compiling the driver for ARM produces
a warning:
In file included from ../drivers/isdn/sc/includes.h:8:0,
from ../drivers/isdn/sc/init.c:13:
../arch/arm/include/asm/io.h:115:21: note: expected 'const volatile void *' but argument is of type 'long unsigned int'
It is pretty clear that this driver has not been used for a long time
and there is no point fixing it now, so let's remove it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
For GMAC newer than 3.40a there is a new register (Reg_9) that provides the
status of all modules of the transmit and receive paths and FIFO status.
These can be exposed via ethtool.
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Yuval Mintz says:
====================
qede/qed: Implement various ethtool operations
This series adds several new ethtool operations to qede:
- {get, set}_channels
- {get, set}_ringparam
- set_phys_id
- nway_reset
- {get, set}_pauseparam
As well as extending the qed APIs to support these commands.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
