To improve human readability and enable automatic validation, the tuples
in the various properties containing interrupt specifiers should be
grouped. While "make dtbs_check" does not impose this yet for the
"interrupts" property, it does for the "interrupt-map" property.
Fix this by grouping the tuples of the "interrupts" and "interrupt-map"
properties using angle brackets.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191213164115.3697-7-geert+renesas@glider.be
Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
To improve human readability and enable automatic validation, the tuples
in the "states" properties of device nodes compatible with
"regulator-gpio" should be grouped, as reported by "make dtbs_check":
$ make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/regulator/gpio-regulator.yaml
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dt.yaml: regulator-vccq-sdhi0: states:0: Additional items are not allowed (1800000, 0 were unexpected)
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dt.yaml: regulator-vccq-sdhi0: states:0: [3300000, 1, 1800000, 0] is too long
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dt.yaml: regulator-vccq-sdhi3: states:0: Additional items are not allowed (1800000, 0 were unexpected)
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dt.yaml: regulator-vccq-sdhi3: states:0: [3300000, 1, 1800000, 0] is too long
...
Fix this by grouping the tuples using angle brackets.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191213164115.3697-6-geert+renesas@glider.be
Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
The asound.h isn't always available while asoc.h itself is distributed
in alsa-lib package. So we need to avoid the unnecessary inclusion of
asound.h from there.
Link: https://lore.kernel.org/r/20191220153415.2740-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent changes in uapi/asoundlib.h caused some build errors in
alsa-lib side because of a typo and the new included files.
Basically asound.h is supposed to be usable also on non-Linux systems,
so we've tried to avoid the Linux-specific include files.
This patch is an attempt to recover from those changes.
Fixes: 3ddee7f88a ("ALSA: Avoid using timespec for struct snd_pcm_status")
Fixes: 80fe7430c7 ("ALSA: add new 32-bit layout for snd_pcm_mmap_status/control")
Link: https://lore.kernel.org/r/20191220153415.2740-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The hdspm.h uapi header has been used also from non-Linux or platforms
that don't have linux/*.h. It was OK in the past because alsa-lib
contained the modified version of this header file, but now it tries
to the verbatim copy, so it broke the build. This fixes it again.
Link: https://lore.kernel.org/r/20191220153415.2740-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Recently alsa-lib updated its content of sound/hdsp.h just by copying
the latest Linus kernel uapi/*.h, and this broke the build of
alsa-tools programs. We used to modify the headers so that they can
be built without asoundlib.h and linux kernel headers, and the
verbatim copy doesn't work as is.
This patch removes again the linux/types.h inclusion and drop __user
prefix that broke the build and adjusts the corresponding code.
Link: https://lore.kernel.org/r/20191220153415.2740-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Recently we updated the content in alsa-lib uapi header files by just
copying from the latest Linus kernel uapi/*.h, and noticed that it
broke the build of some alsa-tools programs. The reason is that we
used to have a modified version in the past, so that the program can
be built without referring to the unexported stuff like
snd_ctl_elem_id or __user prefix.
This patch attempts to restore that, i.e. dropping the stuff that
can't be referred in the user-space. For adapting the changes in
uapi/emu10k1.h, the emu10k1 driver code is also slightly modified.
Most of changes are pointer cast.
Link: https://lore.kernel.org/r/20191220153415.2740-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
To improve human readability and enable automatic validation, the tuples
in the "ranges" and "dma-ranges" properties of PCI devices nodes should
be grouped. Not doing so causes "make dtbs_check" to emit warnings
like:
pcie@fe000000: dma-ranges: [[1107296256, 0, 1073741824, 0, 1073741824, 0, 2147483648, 1124073472, 2, 0, 2, 0, 1, 0]] is not valid under any of the given schemas (Possible causes of the failure):
pcie@fe000000: dma-ranges: [[1107296256, 0, 1073741824, 0, 1073741824, 0, 2147483648, 1124073472, 2, 0, 2, 0, 1, 0]] is not of type 'boolean'
pcie@fe000000: dma-ranges:0: [1107296256, 0, 1073741824, 0, 1073741824, 0, 2147483648, 1124073472, 2, 0, 2, 0, 1, 0] is too long
Fix this by grouping the tuples of the "ranges" and "dma-ranges"
properties using angle brackets.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191213164115.3697-5-geert+renesas@glider.be
Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
To improve human readability and enable automatic validation, the tuples
in the various properties containing interrupt specifiers should be
grouped. While "make dtbs_check" does not impose this yet for the
"interrupts" property, it does for the "interrupt-map" property, leading
to warnings like:
pci@ee090000: interrupt-map:0: [0, 0, 0, 1, 5, 0, 108, 4, 2048, 0, 0, 1, 5, 0, 108, 4, 4096, 0, 0, 2, 5, 0, 108, 4] is too long
pci@ee0d0000: interrupt-map:0: [0, 0, 0, 1, 5, 0, 113, 4, 2048, 0, 0, 1, 5, 0, 113, 4, 4096, 0, 0, 2, 5, 0, 113, 4] is too long
Fix this by grouping the tuples of the "interrupts" and "interrupt-map"
properties using angle brackets.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191213164115.3697-4-geert+renesas@glider.be
Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
We use it in some spots, but not consistently. Convert the rest over,
makes it easier to read as well.
No functional changes in this patch.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
To improve human readability and enable automatic validation, the tuples
in the "states" properties of device nodes compatible with
"regulator-gpio" should be grouped, as reported by "make dtbs_check":
$ make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/regulator/gpio-regulator.yaml
arch/arm/boot/dts/r8a7791-koelsch.dt.yaml: regulator-vccq-sdhi0: states:0: Additional items are not allowed (1800000, 0 were unexpected)
arch/arm/boot/dts/r8a7791-koelsch.dt.yaml: regulator-vccq-sdhi0: states:0: [3300000, 1, 1800000, 0] is too long
arch/arm/boot/dts/r8a7791-koelsch.dt.yaml: regulator-vccq-sdhi1: states:0: Additional items are not allowed (1800000, 0 were unexpected)
arch/arm/boot/dts/r8a7791-koelsch.dt.yaml: regulator-vccq-sdhi1: states:0: [3300000, 1, 1800000, 0] is too long
arch/arm/boot/dts/r8a7791-koelsch.dt.yaml: regulator-vccq-sdhi2: states:0: Additional items are not allowed (1800000, 0 were unexpected)
arch/arm/boot/dts/r8a7791-koelsch.dt.yaml: regulator-vccq-sdhi2: states:0: [3300000, 1, 1800000, 0] is too long
...
Fix this by grouping the tuples using angle brackets.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191213164115.3697-2-geert+renesas@glider.be
Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
Add a device node for the global timer, which is part of the Cortex-A9
MPCore.
The global timer can serve as an accurate (4 ns) clock source for
scheduling and delay loops.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191211135222.26770-4-geert+renesas@glider.be
Add a device node for the global timer, which is part of the Cortex-A9
MPCore.
The global timer can serve as an accurate (3 ns) clock source for
scheduling and delay loops.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191211135222.26770-3-geert+renesas@glider.be
The "TWD" clock is actually the Cortex-A9 MPCore "PERIPHCLK" clock,
which not only clocks the private timers and watchdogs (TWD), but also
the interrupt controller and global timer.
Hence rename it from "twd" to "periph".
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191211135222.26770-2-geert+renesas@glider.be
The malidp_mw_connector_helper_funcs is not referenced by name
outside of the file it is in, so make it static to avoid the
following warning:
drivers/gpu/drm/arm/malidp_mw.c:59:41: warning: symbol 'malidp_mw_connector_helper_funcs' was not declared. Should it be static?
Signed-off-by: Ben Dooks (Codethink) <ben.dooks@codethink.co.uk>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191217115309.2133503-1-ben.dooks@codethink.co.uk
Since this message is printed for each port, it creates a lot of output
during boot and would serve better only during debugging.
Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20191212135301.17915-1-chris.brandt@renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
R-Car Gen3 Hardware Manual Errata for Rev. 2.00 of October 24, 2019
changed the configuration bits for drive and bias control for the
DU_DOTCLKIN3 pin on R-Car M3-N, to match the same pin on R-Car H3.
Update the driver to reflect this.
After this, the handling of drive and bias control for the various
DU_DOTCLKINx pins is consistent across all of the R-Car H3, M3-W,
M3-W+, and M3-N SoCs.
Fixes: 86c045c2e4 ("pinctrl: sh-pfc: r8a77965: Replace DU_DOTCLKIN2 by DU_DOTCLKIN3")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191113101653.28428-1-geert+renesas@glider.be
I was unable to get clk_set_rate() setting a lower RPC-IF clock frequency
and that issue boiled down to me not passing CLK_SET_RATE_PARENT flag to
clk_register_composite() when registering the RPC[D2] clocks...
Fixes: db4a0073cc ("clk: renesas: rcar-gen3: Add RPC clocks")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Link: https://lore.kernel.org/r/be27a344-d8bf-9e0c-8950-2d1b48498496@cogentembedded.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Convert the stm32-pwr regulator binding to DT schema format using
json-schema.
Signed-off-by: Pascal Paillet <p.paillet@st.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20191205161359.20755-1-p.paillet@st.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Simplify LDO6 voltage getting on BD71828 by removing the
get_voltage call-back and providing the fixed voltage in
regulator_desc instead
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Suggested-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20191219113444.GA28299@localhost.localdomain
Signed-off-by: Mark Brown <broonie@kernel.org>
gnttab_request_version() always sets the gnttab_interface variable
and the assertions to check for empty gnttab_interface is unnecessary.
The patch eliminates multiple such assertions.
Signed-off-by: Aditya Pakki <pakki001@umn.edu>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
By simply re-attaching to shared rings during connect_ring() rather than
assuming they are freshly allocated (i.e assuming the counters are zero)
it is possible for vbd instances to be unbound and re-bound from and to
(respectively) a running guest.
This has been tested by running:
while true;
do fio --name=randwrite --ioengine=libaio --iodepth=16 \
--rw=randwrite --bs=4k --direct=1 --size=1G --verify=crc32;
done
in a PV guest whilst running:
while true;
do echo vbd-$DOMID-$VBD >unbind;
echo unbound;
sleep 5;
echo vbd-$DOMID-$VBD >bind;
echo bound;
sleep 3;
done
in dom0 from /sys/bus/xen-backend/drivers/vbd to continuously unbind and
re-bind its system disk image.
This is a highly useful feature for a backend module as it allows it to be
unloaded and re-loaded (i.e. updated) without requiring domUs to be halted.
This was also tested by running:
while true;
do echo vbd-$DOMID-$VBD >unbind;
echo unbound;
sleep 5;
rmmod xen-blkback;
echo unloaded;
sleep 1;
modprobe xen-blkback;
echo bound;
cd $(pwd);
sleep 3;
done
in dom0 whilst running the same loop as above in the (single) PV guest.
Some (less stressful) testing has also been done using a Windows HVM guest
with the latest 9.0 PV drivers installed.
Signed-off-by: Paul Durrant <pdurrant@amazon.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Currently these macros are defined to re-initialize a front/back ring
(respectively) to values read from the shared ring in such a way that any
requests/responses that are added to the shared ring whilst the front/back
is detached will be skipped over. This, in general, is not a desirable
semantic since most frontend implementations will eventually block waiting
for a response which would either never appear or never be processed.
Since the macros are currently unused, take this opportunity to re-define
them to re-initialize a front/back ring using specified values. This also
allows FRONT/BACK_RING_INIT() to be re-defined in terms of
FRONT/BACK_RING_ATTACH() using a specified value of 0.
NOTE: BACK_RING_ATTACH() will be used directly in a subsequent patch.
Signed-off-by: Paul Durrant <pdurrant@amazon.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
If a driver probe() fails then leave the xenstore state alone. There is no
reason to modify it as the failure may be due to transient resource
allocation issues and hence a subsequent probe() may succeed.
If the driver supports re-binding then only force state to closed during
remove() only in the case when the toolstack may need to clean up. This can
be detected by checking whether the state in xenstore has been set to
closing prior to device removal.
NOTE: Re-bind support is indicated by new boolean in struct xenbus_driver,
which defaults to false. Subsequent patches will add support to
some backend drivers.
Signed-off-by: Paul Durrant <pdurrant@amazon.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
...and make it static
xenbus_dev_shutdown() is seemingly intended to cause clean shutdown of PV
frontends when a guest is rebooted. Indeed the function waits for a
conpletion which is only set by a call to xenbus_frontend_closed().
This patch removes the shutdown() method from backends and moves
xenbus_dev_shutdown() from xenbus_probe.c into xenbus_probe_frontend.c,
renaming it appropriately and making it static.
NOTE: In the case where the backend is running in a driver domain, the
toolstack should have already terminated any frontends that may be
using it (since Xen does not support re-startable PV driver domains)
so xenbus_dev_shutdown() should never be called.
Signed-off-by: Paul Durrant <pdurrant@amazon.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Clang warns:
../drivers/block/xen-blkfront.c:1117:4: warning: misleading indentation;
statement is not part of the previous 'if' [-Wmisleading-indentation]
nr_parts = PARTS_PER_DISK;
^
../drivers/block/xen-blkfront.c:1115:3: note: previous statement is here
if (err)
^
This is because there is a space at the beginning of this line; remove
it so that the indentation is consistent according to the Linux kernel
coding style and clang no longer warns.
While we are here, the previous line has some trailing whitespace; clean
that up as well.
Fixes: c80a420995 ("xen-blkfront: handle Xen major numbers other than XENVBD")
Link: https://github.com/ClangBuiltLinux/linux/issues/791
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
The pin control must be set to default as soon as possible to
establish a good video link between tv & bridge hdmi
(encoder mode set is call before encoder enable).
Signed-off-by: Yannick Fertre <yannick.fertre@st.com>
Acked-by: Philippe Cornu <philippe.cornu@st.com>
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1574850218-13257-1-git-send-email-yannick.fertre@st.com
The fw already support scan api v12,
v11 is not needed anymore.
Signed-off-by: Tova Mussai <tova.mussai@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Before we start looping over the internal TX FIFOs increase the fifo
number, but that's incorrect and causes a FIFO to be skipped. This is
probably due to a copy and paste from the previous loop.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
This fixes a long-standing bug - we haven't been able to check the
firmware image that was loaded for D3/not-D3 since the introduction
of the unified image...
Fix this by keeping a status flag for D3 instead of checking for
the firmware image that's loaded.
This reduces occurrences of checks for IWL_UCODE_WOWLAN to just the
code that actually loads the image or deals with it in other ways.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Decide whether or not we need to disable arbitration within user batches
based on our intel_engine_has_preemption() flag.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191213151331.1788371-1-chris@chris-wilson.co.uk
It's typical for the QHP PHY to take slightly above 1ms to initialize,
so increase the timeout of the PHY ready check to 10ms - as already done
in the downstream PCIe driver.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Tested-by: Evan Green <evgreen@chromium.org>
Tested-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
The sifive_l2_cache.c is in no way related to RISC-V architecture
memory management. It is a little stub driver working around the fact
that the EDAC maintainers prefer their drivers to be structured in a
certain way that doesn't fit the SiFive SOCs.
Move the file to drivers/soc and add a Kconfig option for it, as well
as the whole drivers/soc boilerplate for CONFIG_SOC_SIFIVE.
Fixes: a967a289f1 ("RISC-V: sifive_l2_cache: Add L2 cache controller driver for SiFive SoCs")
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Borislav Petkov <bp@suse.de>
[paul.walmsley@sifive.com: keep the MAINTAINERS change specific to the L2$ controller code]
Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
Move the tracking that records the page in the SKB for later
free (refcount decrement) into the get_page_hdr() function
for better code reuse.
While at it, also add an assertion that this doesn't overwrite
any existing page pointer in the skb.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
we should not send the PPAG (Per-Platform Antenna Gain)
command to FW unless the platform has this ACPI table and it was
read and validated during the init flow. also no need to send the
command if the feature is disabled, so check if enabled before
sending, as if there is no valid table the feature is disabled.
Signed-off-by: Gil Adam <gil.adam@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
pfn_to_page & page_to_pfn depend on vmemmap being available before the calls
if kernel is configured with CONFIG_SPARSEMEM_VMEMMAP=y. This was caused
by NOMMU changes which moved vmemmap definition bellow functions definitions
calling pfn_to_page & page_to_pfn.
Noticed while compiled 5.5-rc2 kernel for Fedora/RISCV.
v2:
- Add a comment for vmemmap in source
Signed-off-by: David Abdurachmanov <david.abdurachmanov@sifive.com>
Fixes: 6bd33e1ece ("riscv: add nommu support")
Reviewed-by: Anup Patel <anup@brainfault.org>
Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
This patch fixes that the sscratch register clearing in M-mode. It cleared
sscratch register in M-mode, but it should clear mscratch register. That will
cause kernel trap if the CPU core doesn't support S-mode when trying to access
sscratch.
Fixes: 9e80635619 ("riscv: clear the instruction cache and all registers when booting")
Signed-off-by: Greentime Hu <greentime.hu@sifive.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
In Kconfig files, config options are written without the CONFIG_ prefix.
Fixes: 6bd33e1ece ("riscv: add nommu support")
Signed-off-by: Andreas Schwab <schwab@suse.de>
Reviewed-by: Anup Patel <anup@brainfault.org>
Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
The driver calls clk_prepare_enable in probe but the corresponding
clk_disable_unprepare() is in ti_pipe3_disable_clocks().
Move clk_disable_unprepare() to remove to make them symmetric.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
This patch corrects the SPDX License Identifier style in
header files related to PHY drivers for Qualcomm platforms.
For C header files Documentation/process/license-rules.rst
mandates C-like comments (opposed to C source files where
C++ style should be used).
Changes made by using a script provided by Joe Perches here:
https://lkml.org/lkml/2019/2/7/46.
Suggested-by: Joe Perches <joe@perches.com>
Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^ /\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
If musb_mailbox() returns an error, we must still continue to finish
configuring the phy.
Otherwise the phy state may end up only half initialized, and this can
cause the debug serial console to stop working. And this will happen if the
usb driver musb controller is not loaded.
Let's fix the issue by adding helper for cpcap_usb_try_musb_mailbox().
Fixes: 6d6ce40f63 ("phy: cpcap-usb: Add CPCAP PMIC USB support")
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Telit FN980 flashing device 0x1bc7/0x9010 requires zero packet
to be sent if out data size is is equal to the endpoint max size.
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
[ johan: switch operands in conditional ]
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Instead of rummaging through the intel_context to peek at the GEM
context in the middle of request submission to decide whether to use
semaphores, store that information on the intel_context itself.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Andi Shyti <andi.shyti@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191220101230.256839-2-chris@chris-wilson.co.uk
Keep the intel_context as being the primary state for i915_request, with
the GEM context a backpointer from the low level state for the rarer
cases we need client information. Our goal is to remove such references
to clients from the backend, and leave the HW submission agnostic to
client interfaces and self-contained.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Andi Shyti <andi.shyti@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191220101230.256839-1-chris@chris-wilson.co.uk
