* [PATCH v2 08/12] drm/sun4i: backend: Wire in the frontend
From: Chen-Yu Tsai @ 2018-01-04 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9e8c0ce7192dc9ec59da6906e8f6e8f282ac3809.1513609024.git-series.maxime.ripard@free-electrons.com>
On Mon, Dec 18, 2017 at 10:57 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Now that we have a driver, we can make use of it. This is done by
> adding a flag to our custom plane state that will trigger whether we should
> use the frontend on that particular plane or not.
>
> The rest is just plumbing to set up the backend to not perform the DMA but
> receive its data from the frontend.
>
> Note that we're still not making any use of the frontend itself, as no one
> is setting the flag yet.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> drivers/gpu/drm/sun4i/sun4i_backend.c | 90 ++++++++++++++++++++++++++++-
> drivers/gpu/drm/sun4i/sun4i_backend.h | 8 ++-
> drivers/gpu/drm/sun4i/sun4i_crtc.c | 1 +-
> drivers/gpu/drm/sun4i/sun4i_layer.c | 33 +++++++++-
> drivers/gpu/drm/sun4i/sun4i_layer.h | 1 +-
> 5 files changed, 130 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index f971d3fb5ee4..29e1ca7e01fe 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -26,6 +26,7 @@
>
> #include "sun4i_backend.h"
> #include "sun4i_drv.h"
> +#include "sun4i_frontend.h"
> #include "sun4i_layer.h"
> #include "sunxi_engine.h"
>
> @@ -203,6 +204,30 @@ int sun4i_backend_update_layer_formats(struct sun4i_backend *backend,
> return 0;
> }
>
> +int sun4i_backend_update_layer_frontend(struct sun4i_backend *backend,
> + int layer, uint32_t fmt)
> +{
> + u32 val;
> + int ret;
> +
> + ret = sun4i_backend_drm_format_to_layer(NULL, fmt, &val);
> + if (ret) {
> + DRM_DEBUG_DRIVER("Invalid format\n");
> + return ret;
> + }
> +
> + regmap_update_bits(backend->engine.regs,
> + SUN4I_BACKEND_ATTCTL_REG0(layer),
> + SUN4I_BACKEND_ATTCTL_REG0_LAY_VDOEN,
> + SUN4I_BACKEND_ATTCTL_REG0_LAY_VDOEN);
You also need to select which frontend to use by setting LAY_VDOSEL.
> +
> + regmap_update_bits(backend->engine.regs,
> + SUN4I_BACKEND_ATTCTL_REG1(layer),
> + SUN4I_BACKEND_ATTCTL_REG1_LAY_FBFMT, val);
> +
> + return 0;
> +}
> +
> int sun4i_backend_update_layer_buffer(struct sun4i_backend *backend,
> int layer, struct drm_plane *plane)
> {
> @@ -246,6 +271,36 @@ int sun4i_backend_update_layer_buffer(struct sun4i_backend *backend,
> return 0;
> }
>
> +static void sun4i_backend_vblank_quirk(struct sunxi_engine *engine)
> +{
> + struct sun4i_backend *backend = engine_to_sun4i_backend(engine);
> + struct sun4i_frontend *frontend = backend->frontend;
> +
> + if (!frontend)
> + return;
> +
> + /*
> + * In a teardown scenario with the frontend involved, we have
> + * to keep the frontend enabled until the next vblank, and
> + * only then disable it.
> + *
> + * This is due to the fact that the backend will not take into
> + * account the new configuration (with the plane that used to
> + * be fed by the frontend now disabled) until we write to the
> + * commit bit and the hardware fetches the new configuration
> + * during the next vblank.
> + *
> + * So we keep the frontend around in order to prevent any
> + * visual artifacts.
> + */
> + spin_lock(&backend->frontend_lock);
> + if (backend->frontend_teardown) {
> + sun4i_frontend_exit(frontend);
> + backend->frontend_teardown = false;
> + }
> + spin_unlock(&backend->frontend_lock);
> +};
> +
> static int sun4i_backend_init_sat(struct device *dev) {
> struct sun4i_backend *backend = dev_get_drvdata(dev);
> int ret;
> @@ -330,11 +385,40 @@ static int sun4i_backend_of_get_id(struct device_node *node)
> return ret;
> }
>
> +static struct sun4i_frontend *sun4i_backend_find_frontend(struct sun4i_drv *drv,
> + struct device_node *node)
> +{
> + struct device_node *port, *ep, *remote;
> + struct sun4i_frontend *frontend;
> +
> + port = of_graph_get_port_by_id(node, 0);
> + if (!port)
> + return ERR_PTR(-EINVAL);
> +
> + for_each_available_child_of_node(port, ep) {
> + remote = of_graph_get_remote_port_parent(ep);
> + if (!remote)
> + continue;
> +
> + /* does this node match any registered engines? */
> + list_for_each_entry(frontend, &drv->frontend_list, list) {
> + if (remote == frontend->node) {
> + of_node_put(remote);
> + of_node_put(port);
> + return frontend;
This would return the same frontend for both backends in a dual pipeline setup.
Remember that we now have cross-connecting links between frontends and backends
of both pipelines.
Instead just match the frontend's ID to the backend's ID. BTW I think you left
out the ID thing in the frontend driver.
The rest looks good.
ChenYu
^ permalink raw reply
* [PATCH v2 09/12] drm/sun4i: backend: Add a custom atomic_check for the frontend
From: Chen-Yu Tsai @ 2018-01-04 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9c6cddb9eb16a8c4bdab2e66c072b2bc9a10fcd4.1513609024.git-series.maxime.ripard@free-electrons.com>
On Mon, Dec 18, 2017 at 10:57 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Now that we have everything in place, we can start enabling the frontend.
> This is more difficult than one would assume since there can only be one
> plane using the frontend per-backend.
>
> We therefore need to make sure that the userspace will not try to setup
> multiple planes using it, since that would be impossible. In order to
> prevent that, we can create an atomic_check callback that will check that
> only one plane will effectively make use of the frontend in a given
> configuration, and will toggle the switch in that plane state so that the
> proper setup function can do their role.
>
> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH 07/11] drm/sun4i: Add support for A83T second TCON
From: Maxime Ripard @ 2018-01-04 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171230210203.24115-8-jernej.skrabec@siol.net>
Hi,
On Sat, Dec 30, 2017 at 10:01:59PM +0100, Jernej Skrabec wrote:
> This TCON doesn't have channel 0, so quirk has_channel_0 is added in the
> process.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Ideally, this should be split in two patches, one to add the new flag,
and one to add the support for the A83t TCON-TV.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180104/f97ff576/attachment.sig>
^ permalink raw reply
* [PATCH 08/11] drm/sun4i: Add support for A83T second DE2 mixer
From: Maxime Ripard @ 2018-01-04 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171230210203.24115-9-jernej.skrabec@siol.net>
On Sat, Dec 30, 2017 at 10:02:00PM +0100, Jernej Skrabec wrote:
> It supports 1 VI and 1 UI plane and HW scaling on both planes.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180104/a550298e/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2] soc: Add SoC driver for Gemini
From: Arnd Bergmann @ 2018-01-04 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221231908.9664-1-linus.walleij@linaro.org>
On Fri, Dec 22, 2017 at 12:19 AM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> This adds an SoC driver for the Gemini. Currently there
> is only one thing not fitting into any other framework,
> and that is the bus arbitration setting.
>
> All Gemini vendor trees seem to be setting this register to
> exactly the same arbitration so we just add a small code
> snippet to do this at subsys_init() time before any other
> drivers kick in.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v1->v2:
> - Add a multiplatform guard, bail out silently if we are not
> running on Gemini.
>
> ARM SoC folks: please just apply this patch directly somewhere
> if you're pleased with it, it is fully idependent.
Applied to next/soc, thanks!
> Arnd wanted some rewording of the commit message but I can't
> figure out what, please entertain yourself editing it any way
> you like :)
The patch commit message is fine, the part I wanted to have
reworded was the "SoC driver for the Gemini. See the commit
for details." text in the pull request that did not seem right as
a git changelog message. As I applied the patch by itself now,
it's all good.
Arnd
^ permalink raw reply
* [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Andy Shevchenko @ 2018-01-04 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8e985f68-5887-b0d5-8c45-e22b5d8f60cf@codeaurora.org>
On Thu, 2018-01-04 at 09:46 -0600, Timur Tabi wrote:
> On 12/21/2017 07:46 PM, Stephen Boyd wrote:
> >
> > Maybe future HIDs could follow the DT design and then we can look
> > for the same device property name in both firmwares.
>
> DSDs generally don't have the vendor prefix that DT properties do.
There are more means to check hardware revisions:
HID - Hardware ID
CID - Compatible ID
UID - Unique ID (good to distinguish instances of the same device on the
board)
_HRV - Hardware Revision (6.1.6 describes this one)
Everything is described in the spec. Does anybody care to read?
P.S. More I reading this thread more I become thinking that people screw
ACPI use in many ways...
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC Fixes for v4.15
From: Arnd Bergmann @ 2018-01-04 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1513938447.git.horms+renesas@verge.net.au>
On Fri, Dec 22, 2017 at 11:30 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Renesas ARM Based SoC Fixes for v4.15
>
> Vladimir Zapolskiy says:
>
> The present change is a bug fix for AVB link iteratively up/down.
>
> Steps to reproduce:
> - start AVB TX stream (Using aplay via MSE),
> - disconnect+reconnect the eth cable,
> - after a reconnection the eth connection goes iteratively up/down
> without user interaction,
> - this may heal after some seconds or even stay for minutes.
>
> As the documentation specifies, the "renesas,no-ether-link" option
> should be used when a board does not provide a proper AVB_LINK signal.
> There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
> and ULCB starter kits since the AVB_LINK is correctly handled by HW.
>
> Choosing to keep or remove the "renesas,no-ether-link" option will
> have impact on the code flow in the following ways:
> - keeping this option enabled may lead to unexpected behavior since
> the RX & TX are enabled/disabled directly from adjust_link function
> without any HW interrogation,
> - removing this option, the RX & TX will only be enabled/disabled after
> HW interrogation. The HW check is made through the LMON pin in PSR
> register which specifies AVB_LINK signal value (0 - at low level;
> 1 - at high level).
>
> In conclusion, the change is also a safety improvement because it
> removes the "renesas,no-ether-link" option leading to a proper way
> of detecting the link state based on HW interrogation and not on
> software heuristic.
>
> Note that DTS files for V3M Starter Kit, Draak and Eagle boards
> contain the same property, the files are untouched due to unavailable
> schematics to verify if the fix applies to these boards as well.
Pulled into fixes, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] Allwinner fixes for 4.15
From: Arnd Bergmann @ 2018-01-04 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171228032240.GA2951@wens.csie.org>
On Thu, Dec 28, 2017 at 4:22 AM, Chen-Yu Tsai <wens@csie.org> wrote:
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-fixes-for-4.15
>
> for you to fetch changes up to eac6a3639decefcc8eb0941dd3cebe79993670ad:
>
> ARM: dts: sun8i: a711: Reinstate the PMIC compatible (2017-12-19 09:56:57 +0100)
>
> ----------------------------------------------------------------
> Allwinner fixes for 4.15
>
> First, one fix that adds proper regulator references for the EMAC
> external PHYs on A64 boards. The EMAC bindings were developed for 4.13,
> but reverted at the last minute. They were finalized and brought back
> for 4.15. However in the time between, regulator support for the A64
> boards was merged. When EMAC device tree changes were reintroduced,
> this was not taken into account.
>
> Second, a patch that adds OF based modalias uevent for RSB slave devices.
> This has been missing since the introduction of RSB, and recently with
> PMIC regulator support introduced for the A64, has been seen affecting
> distributions, which have the all-important PMIC mfd drivers built as
> modules, which then don't get loaded.
>
> Other minor cleanups include final conversion of raw indices to CCU
> binding macros for sun[4567]i HDMI, cleanup of dummy regulators on the
> A64 SOPINE, a SD card detection polarity fix for the Orange Pi Zero
> Plus2, and adding a missing compatible for the PMIC on the TBS A711
> tablet.
Pulled into fixes, thanks!
Arnd
^ permalink raw reply
* [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Graeme Gregory @ 2018-01-04 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPv3WKcM8WWvh64A=FTtuWkEr6V_QSKjBpNpWnMpp_P=cMU9sw@mail.gmail.com>
On Wed, Jan 03, 2018 at 12:12:06PM +0100, Marcin Wojtas wrote:
> Hi Graeme,
>
> 2018-01-03 12:00 GMT+01:00 Graeme Gregory <graeme.gregory@linaro.org>:
> > On Mon, Dec 18, 2017 at 10:40:31AM +0100, Ard Biesheuvel wrote:
> >> On 18 December 2017 at 10:17, Marcin Wojtas <mw@semihalf.com> wrote:
> >> > Hi,
> >> >
> >> > This patchset introduces ACPI support in mvpp2 and mvmdio drivers.
> >> > First three patches introduce fwnode helpers for obtaining PHY
> >> > information from nodes and also MDIO fwnode API for registering
> >> > the bus with its PHY/devices.
> >> >
> >> > Following patches update code of the mvmdio and mvpp2 drivers
> >> > to support ACPI tables handling. The latter is done in 4 steps,
> >> > as can be seen in the commits. For the details, please
> >> > refer to the commit messages.
> >> >
> >> > Drivers operation was tested on top of the net-next branch
> >> > with both DT and ACPI. Although for compatibility reasons
> >> > with older platforms, the mvmdio driver keeps using
> >> > of_ MDIO registering, new fwnode_ one proved to fully work
> >> > with DT as well (tested on MacchiatoBin board).
> >> >
> >> > mvpp2/mvmdio driver can work with the ACPI representation, as exposed
> >> > on a public branch:
> >> > https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/marvell-armada-wip
> >> > It was compiled together with the most recent Tianocore EDK2 revision.
> >> > Please refer to the firmware build instruction on MacchiatoBin board:
> >> > http://wiki.macchiatobin.net/tiki-index.php?page=Build+from+source+-+UEFI+EDK+II
> >> >
> >> > Above support configures 1G to use its PHY normally. 10G can work now
> >> > only with the link interrupt mode. Somehow reading of the
> >> > string property in fwnode_mdiobus_child_is_phy works only with
> >> > DT and cannot cope with 10G PHY nodes as in:
> >> > https://pastebin.com/3JnYpU0A
> >> >
> >> > Above root cause will be further checked. In the meantime I will
> >> > appreciate any comments or remarks for the kernel patches.
> >> >
> >>
> >> Hi Marcin,
> >>
> >> I have added linux-acpi and Graeme to cc. I think it makes sense to
> >> discuss the way you describe the device topology before looking at the
> >> patches in more detail.
> >>
> >> In particular, I would like to request feedback on the use of
> >> [redundant] 'reg' properties and the use of _DSD + compatible to
> >> describe PHYs. Usually, we try to avoid this, given that it is
> >> essentially a ACPI encapsulated DT dialect that is difficult to
> >> support in drivers unless they are based on DT to begin with. Also,
> >> non-standard _DSD properties require a vendor prefix, it is not
> >> freeform.
> >>
> >> For reference, the ACPI description is here (starting at line 175)
> >> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/72d5ac23b20dd74d479daa5e40ba443264b31261/Platforms/Marvell/Armada/AcpiTables/Armada80x0McBin/Dsdt.asl
> >>
> > So the representation of PHY's with _DSD was kind of formalised here
> >
> > http://www.uefi.org/sites/default/files/resources/nic-request-v2.pdf
> >
> > This is already in use in the kernel, and that DSDT seems to be along the same
> > lines. So seems ok in that manner.
> >
> > The "reg", 0 property seems a little odd, it would probably make more
> > sense to check for the lack of ranges passed in in ACPI manner _CRS.
> >
>
> I already agreed with 'reg' being awkward in the later emails.
> Wouldn't _ADR be more appropriate to specify PHY address on MDIO bus?
>
Ah it is an actual address, then yes _ADR is probably more appropriate.
Graeme
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180104/4dffe9ca/attachment-0001.sig>
^ permalink raw reply
* [PATCH 05/11] drivers/firmware: Expose psci_get_version through psci_ops structure
From: Lorenzo Pieralisi @ 2018-01-04 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515078515-13723-6-git-send-email-will.deacon@arm.com>
On Thu, Jan 04, 2018 at 03:08:29PM +0000, Will Deacon wrote:
> Entry into recent versions of ARM Trusted Firmware will invalidate the CPU
> branch predictor state in order to protect against aliasing attacks.
>
> This patch exposes the PSCI "VERSION" function via psci_ops, so that it
> can be invoked outside of the PSCI driver where necessary.
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> drivers/firmware/psci.c | 2 ++
> include/linux/psci.h | 1 +
> 2 files changed, 3 insertions(+)
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
> index d687ca3d5049..8b25d31e8401 100644
> --- a/drivers/firmware/psci.c
> +++ b/drivers/firmware/psci.c
> @@ -496,6 +496,8 @@ static void __init psci_init_migrate(void)
> static void __init psci_0_2_set_functions(void)
> {
> pr_info("Using standard PSCI v0.2 function IDs\n");
> + psci_ops.get_version = psci_get_version;
> +
> psci_function_id[PSCI_FN_CPU_SUSPEND] =
> PSCI_FN_NATIVE(0_2, CPU_SUSPEND);
> psci_ops.cpu_suspend = psci_cpu_suspend;
> diff --git a/include/linux/psci.h b/include/linux/psci.h
> index bdea1cb5e1db..6306ab10af18 100644
> --- a/include/linux/psci.h
> +++ b/include/linux/psci.h
> @@ -26,6 +26,7 @@ int psci_cpu_init_idle(unsigned int cpu);
> int psci_cpu_suspend_enter(unsigned long index);
>
> struct psci_operations {
> + u32 (*get_version)(void);
> int (*cpu_suspend)(u32 state, unsigned long entry_point);
> int (*cpu_off)(u32 state);
> int (*cpu_on)(unsigned long cpuid, unsigned long entry_point);
> --
> 2.1.4
>
^ permalink raw reply
* [GIT PULL] ARM: uniphier: fixes for v4.15 (2nd)
From: Arnd Bergmann @ 2018-01-04 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNAQodyYzeD9kujN05EQQzfZPwWOq1AmBCvKd2FDnnRF7AQ@mail.gmail.com>
On Fri, Dec 29, 2017 at 1:30 PM, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> Hi Arnd, Olof,
>
> This is the 2nd bug-fix pull request for v4.15.
> Just one DT fix. Please pull!
I've ended up cherry-picking that commit manually into the fixes branch:
We haven't updated the fixes branch to a later -rc, and your pull request
was based on -rc3, so pulling it would create an ugly backmerge.
You did nothing wrong here, so it seemed unnecessary to ask you for
a respin based on -rc1. Hope that works for you.
Arnd
^ permalink raw reply
* [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Andrew Lunn @ 2018-01-04 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180104160939.GA7785@xora-haswell>
> > I already agreed with 'reg' being awkward in the later emails.
> > Wouldn't _ADR be more appropriate to specify PHY address on MDIO bus?
> >
> Ah it is an actual address, then yes _ADR is probably more appropriate.
Newbie ACPI question. What is the definition of an address?
In this cause, we are talking about an address of a device on an MDIO
bus. It takes a value between 0 and 31.
How are IC2 device addresses represented in ACPI? MDIO devices and I2C
devices are pretty similar. So it would make sense to use the same as
what I2C uses.
Andrew
^ permalink raw reply
* [PATCH 01/11] arm64: use RET instruction for exiting the trampoline
From: Ard Biesheuvel @ 2018-01-04 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515078515-13723-2-git-send-email-will.deacon@arm.com>
On 4 January 2018 at 15:08, Will Deacon <will.deacon@arm.com> wrote:
> Speculation attacks against the entry trampoline can potentially resteer
> the speculative instruction stream through the indirect branch and into
> arbitrary gadgets within the kernel.
>
> This patch defends against these attacks by forcing a misprediction
> through the return stack: a dummy BL instruction loads an entry into
> the stack, so that the predicted program flow of the subsequent RET
> instruction is to a branch-to-self instruction which is finally resolved
> as a branch to the kernel vectors with speculation suppressed.
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/kernel/entry.S | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index 031392ee5f47..b9feb587294d 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -1029,6 +1029,9 @@ alternative_else_nop_endif
> .if \regsize == 64
> msr tpidrro_el0, x30 // Restored in kernel_ventry
> .endif
> + bl 2f
> + b .
> +2:
This deserves a comment, I guess?
Also, is deliberately unbalancing the return stack likely to cause
performance problems, e.g., in libc hot paths?
> tramp_map_kernel x30
> #ifdef CONFIG_RANDOMIZE_BASE
> adr x30, tramp_vectors + PAGE_SIZE
> @@ -1041,7 +1044,7 @@ alternative_insn isb, nop, ARM64_WORKAROUND_QCOM_FALKOR_E1003
> msr vbar_el1, x30
> add x30, x30, #(1b - tramp_vectors)
> isb
> - br x30
> + ret
> .endm
>
> .macro tramp_exit, regsize = 64
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH 06/11] arm64: Move post_ttbr_update_workaround to C code
From: Ard Biesheuvel @ 2018-01-04 16:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515078515-13723-7-git-send-email-will.deacon@arm.com>
On 4 January 2018 at 15:08, Will Deacon <will.deacon@arm.com> wrote:
> From: Marc Zyngier <marc.zyngier@arm.com>
>
> We will soon need to invoke a CPU-specific function pointer after changing
> page tables, so move post_ttbr_update_workaround out into C code to make
> this possible.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/include/asm/assembler.h | 13 -------------
> arch/arm64/kernel/entry.S | 2 +-
> arch/arm64/mm/context.c | 9 +++++++++
> arch/arm64/mm/proc.S | 3 +--
> 4 files changed, 11 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
> index c45bc94f15d0..cee60ce0da52 100644
> --- a/arch/arm64/include/asm/assembler.h
> +++ b/arch/arm64/include/asm/assembler.h
> @@ -476,17 +476,4 @@ alternative_endif
> mrs \rd, sp_el0
> .endm
>
> -/*
> - * Errata workaround post TTBRx_EL1 update.
> - */
> - .macro post_ttbr_update_workaround
> -#ifdef CONFIG_CAVIUM_ERRATUM_27456
> -alternative_if ARM64_WORKAROUND_CAVIUM_27456
> - ic iallu
> - dsb nsh
> - isb
> -alternative_else_nop_endif
> -#endif
> - .endm
> -
> #endif /* __ASM_ASSEMBLER_H */
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index b9feb587294d..6aa112baf601 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -277,7 +277,7 @@ alternative_else_nop_endif
> * Cavium erratum 27456 (broadcast TLBI instructions may cause I-cache
> * corruption).
> */
> - post_ttbr_update_workaround
> + bl post_ttbr_update_workaround
> .endif
> 1:
> .if \el != 0
> diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
> index 1cb3bc92ae5c..c1e3b6479c8f 100644
> --- a/arch/arm64/mm/context.c
> +++ b/arch/arm64/mm/context.c
> @@ -239,6 +239,15 @@ void check_and_switch_context(struct mm_struct *mm, unsigned int cpu)
> cpu_switch_mm(mm->pgd, mm);
> }
>
> +/* Errata workaround post TTBRx_EL1 update. */
> +asmlinkage void post_ttbr_update_workaround(void)
> +{
> + asm volatile(ALTERNATIVE("nop; nop; nop",
What does 'volatile' add here?
> + "ic iallu; dsb nsh; isb",
> + ARM64_WORKAROUND_CAVIUM_27456,
> + CONFIG_CAVIUM_ERRATUM_27456));
> +}
> +
> static int asids_init(void)
> {
> asid_bits = get_cpu_asid_bits();
> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> index 3146dc96f05b..6affb68a9a14 100644
> --- a/arch/arm64/mm/proc.S
> +++ b/arch/arm64/mm/proc.S
> @@ -145,8 +145,7 @@ ENTRY(cpu_do_switch_mm)
> isb
> msr ttbr0_el1, x0 // now update TTBR0
> isb
> - post_ttbr_update_workaround
> - ret
> + b post_ttbr_update_workaround // Back to C code...
> ENDPROC(cpu_do_switch_mm)
>
> .pushsection ".idmap.text", "ax"
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH V4 11/26] iommu/amd: deprecate pci_get_bus_and_slot()
From: Gary R Hook @ 2018-01-04 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8a5dad82-2886-2a51-28bc-b84ab253c361@codeaurora.org>
On 01/04/2018 06:25 AM, Sinan Kaya wrote:
> On 12/19/2017 12:37 AM, Sinan Kaya wrote:
>> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
>> where a PCI device is present. This restricts the device drivers to be
>> reused for other domain numbers.
>>
>> Getting ready to remove pci_get_bus_and_slot() function in favor of
>> pci_get_domain_bus_and_slot().
>>
>> Hard-code the domain number as 0 for the AMD IOMMU driver.
<snip>
>
> Any comments from the IOMMU people?
>
pci_get_bus_and_slot() appears to (now) be a convenience function that
wraps pci_get_domain_bus_and_slot() while using a 0 for the domain
value. Exactly what you are doing here, albeit in a more overt way.
How is this patch advantageous? Seems to me that if other domains need
to be enabled, that driver could be changed if and when that requirement
arises.
But perhaps I'm missing a nuance here.
^ permalink raw reply
* [PATCH 08/11] arm64: KVM: Use per-CPU vector when BP hardening is enabled
From: Ard Biesheuvel @ 2018-01-04 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515078515-13723-9-git-send-email-will.deacon@arm.com>
On 4 January 2018 at 15:08, Will Deacon <will.deacon@arm.com> wrote:
> From: Marc Zyngier <marc.zyngier@arm.com>
>
> Now that we have per-CPU vectors, let's plug then in the KVM/arm64 code.
>
Why does bp hardening require per-cpu vectors?
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm/include/asm/kvm_mmu.h | 10 ++++++++++
> arch/arm64/include/asm/kvm_mmu.h | 38 ++++++++++++++++++++++++++++++++++++++
> arch/arm64/kvm/hyp/switch.c | 2 +-
> virt/kvm/arm/arm.c | 8 +++++++-
> 4 files changed, 56 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
> index fa6f2174276b..eb46fc81a440 100644
> --- a/arch/arm/include/asm/kvm_mmu.h
> +++ b/arch/arm/include/asm/kvm_mmu.h
> @@ -221,6 +221,16 @@ static inline unsigned int kvm_get_vmid_bits(void)
> return 8;
> }
>
> +static inline void *kvm_get_hyp_vector(void)
> +{
> + return kvm_ksym_ref(__kvm_hyp_vector);
> +}
> +
> +static inline int kvm_map_vectors(void)
> +{
> + return 0;
> +}
> +
> #endif /* !__ASSEMBLY__ */
>
> #endif /* __ARM_KVM_MMU_H__ */
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index 672c8684d5c2..2d6d4bd9de52 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -309,5 +309,43 @@ static inline unsigned int kvm_get_vmid_bits(void)
> return (cpuid_feature_extract_unsigned_field(reg, ID_AA64MMFR1_VMIDBITS_SHIFT) == 2) ? 16 : 8;
> }
>
> +#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
> +#include <asm/mmu.h>
> +
> +static inline void *kvm_get_hyp_vector(void)
> +{
> + struct bp_hardening_data *data = arm64_get_bp_hardening_data();
> + void *vect = kvm_ksym_ref(__kvm_hyp_vector);
> +
> + if (data->fn) {
> + vect = __bp_harden_hyp_vecs_start +
> + data->hyp_vectors_slot * SZ_2K;
> +
> + if (!has_vhe())
> + vect = lm_alias(vect);
> + }
> +
> + return vect;
> +}
> +
> +static inline int kvm_map_vectors(void)
> +{
> + return create_hyp_mappings(kvm_ksym_ref(__bp_harden_hyp_vecs_start),
> + kvm_ksym_ref(__bp_harden_hyp_vecs_end),
> + PAGE_HYP_EXEC);
> +}
> +
> +#else
> +static inline void *kvm_get_hyp_vector(void)
> +{
> + return kvm_ksym_ref(__kvm_hyp_vector);
> +}
> +
> +static inline int kvm_map_vectors(void)
> +{
> + return 0;
> +}
> +#endif
> +
> #endif /* __ASSEMBLY__ */
> #endif /* __ARM64_KVM_MMU_H__ */
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index f7c651f3a8c0..8d4f3c9d6dc4 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -52,7 +52,7 @@ static void __hyp_text __activate_traps_vhe(void)
> val &= ~(CPACR_EL1_FPEN | CPACR_EL1_ZEN);
> write_sysreg(val, cpacr_el1);
>
> - write_sysreg(__kvm_hyp_vector, vbar_el1);
> + write_sysreg(kvm_get_hyp_vector(), vbar_el1);
> }
>
> static void __hyp_text __activate_traps_nvhe(void)
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index 6b60c98a6e22..1c9fdb6db124 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -1158,7 +1158,7 @@ static void cpu_init_hyp_mode(void *dummy)
> pgd_ptr = kvm_mmu_get_httbr();
> stack_page = __this_cpu_read(kvm_arm_hyp_stack_page);
> hyp_stack_ptr = stack_page + PAGE_SIZE;
> - vector_ptr = (unsigned long)kvm_ksym_ref(__kvm_hyp_vector);
> + vector_ptr = (unsigned long)kvm_get_hyp_vector();
>
> __cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
> __cpu_init_stage2();
> @@ -1403,6 +1403,12 @@ static int init_hyp_mode(void)
> goto out_err;
> }
>
> + err = kvm_map_vectors();
> + if (err) {
> + kvm_err("Cannot map vectors\n");
> + goto out_err;
> + }
> +
> /*
> * Map the Hyp stack pages
> */
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH 11/11] arm64: Implement branch predictor hardening for affected Cortex-A CPUs
From: Ard Biesheuvel @ 2018-01-04 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515078515-13723-12-git-send-email-will.deacon@arm.com>
On 4 January 2018 at 15:08, Will Deacon <will.deacon@arm.com> wrote:
> Cortex-A57, A72, A73 and A75 are susceptible to branch predictor aliasing
> and can theoretically be attacked by malicious code.
>
> This patch implements a PSCI-based mitigation for these CPUs when available.
> The call into firmware will invalidate the branch predictor state, preventing
> any malicious entries from affecting other victim contexts.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/kernel/bpi.S | 24 ++++++++++++++++++++++++
> arch/arm64/kernel/cpu_errata.c | 42 ++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 66 insertions(+)
>
> diff --git a/arch/arm64/kernel/bpi.S b/arch/arm64/kernel/bpi.S
> index 06a931eb2673..2b10d52a0321 100644
> --- a/arch/arm64/kernel/bpi.S
> +++ b/arch/arm64/kernel/bpi.S
> @@ -53,3 +53,27 @@ ENTRY(__bp_harden_hyp_vecs_start)
> vectors __kvm_hyp_vector
> .endr
> ENTRY(__bp_harden_hyp_vecs_end)
> +ENTRY(__psci_hyp_bp_inval_start)
> + stp x0, x1, [sp, #-16]!
> + stp x2, x3, [sp, #-16]!
> + stp x4, x5, [sp, #-16]!
> + stp x6, x7, [sp, #-16]!
> + stp x8, x9, [sp, #-16]!
> + stp x10, x11, [sp, #-16]!
> + stp x12, x13, [sp, #-16]!
> + stp x14, x15, [sp, #-16]!
> + stp x16, x17, [sp, #-16]!
> + stp x18, x19, [sp, #-16]!
Would it be better to update sp only once here?
Also, do x18 and x19 need to be preserved/restored here?
> + mov x0, #0x84000000
> + smc #0
> + ldp x18, x19, [sp], #16
> + ldp x16, x17, [sp], #16
> + ldp x14, x15, [sp], #16
> + ldp x12, x13, [sp], #16
> + ldp x10, x11, [sp], #16
> + ldp x8, x9, [sp], #16
> + ldp x6, x7, [sp], #16
> + ldp x4, x5, [sp], #16
> + ldp x2, x3, [sp], #16
> + ldp x0, x1, [sp], #16
> +ENTRY(__psci_hyp_bp_inval_end)
> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> index 16ea5c6f314e..cb0fb3796bb8 100644
> --- a/arch/arm64/kernel/cpu_errata.c
> +++ b/arch/arm64/kernel/cpu_errata.c
> @@ -53,6 +53,8 @@ static int cpu_enable_trap_ctr_access(void *__unused)
> DEFINE_PER_CPU_READ_MOSTLY(struct bp_hardening_data, bp_hardening_data);
>
> #ifdef CONFIG_KVM
> +extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
> +
> static void __copy_hyp_vect_bpi(int slot, const char *hyp_vecs_start,
> const char *hyp_vecs_end)
> {
> @@ -94,6 +96,9 @@ static void __install_bp_hardening_cb(bp_hardening_cb_t fn,
> spin_unlock(&bp_lock);
> }
> #else
> +#define __psci_hyp_bp_inval_start NULL
> +#define __psci_hyp_bp_inval_end NULL
> +
> static void __install_bp_hardening_cb(bp_hardening_cb_t fn,
> const char *hyp_vecs_start,
> const char *hyp_vecs_end)
> @@ -118,6 +123,21 @@ static void install_bp_hardening_cb(const struct arm64_cpu_capabilities *entry,
>
> __install_bp_hardening_cb(fn, hyp_vecs_start, hyp_vecs_end);
> }
> +
> +#include <linux/psci.h>
> +
> +static int enable_psci_bp_hardening(void *data)
> +{
> + const struct arm64_cpu_capabilities *entry = data;
> +
> + if (psci_ops.get_version)
> + install_bp_hardening_cb(entry,
> + (bp_hardening_cb_t)psci_ops.get_version,
> + __psci_hyp_bp_inval_start,
> + __psci_hyp_bp_inval_end);
> +
> + return 0;
> +}
> #endif /* CONFIG_HARDEN_BRANCH_PREDICTOR */
>
> #define MIDR_RANGE(model, min, max) \
> @@ -261,6 +281,28 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
> MIDR_ALL_VERSIONS(MIDR_CORTEX_A73),
> },
> #endif
> +#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
> + {
> + .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
> + MIDR_ALL_VERSIONS(MIDR_CORTEX_A57),
> + .enable = enable_psci_bp_hardening,
> + },
> + {
> + .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
> + MIDR_ALL_VERSIONS(MIDR_CORTEX_A72),
> + .enable = enable_psci_bp_hardening,
> + },
> + {
> + .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
> + MIDR_ALL_VERSIONS(MIDR_CORTEX_A73),
> + .enable = enable_psci_bp_hardening,
> + },
> + {
> + .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
> + MIDR_ALL_VERSIONS(MIDR_CORTEX_A75),
> + .enable = enable_psci_bp_hardening,
> + },
> +#endif
> {
> }
> };
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH V4 11/26] iommu/amd: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2018-01-04 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <46ccdb85-1c23-c9eb-994c-9a66e6fce7cc@amd.com>
On 1/4/2018 11:28 AM, Gary R Hook wrote:
> On 01/04/2018 06:25 AM, Sinan Kaya wrote:
>> On 12/19/2017 12:37 AM, Sinan Kaya wrote:
>>> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
>>> where a PCI device is present. This restricts the device drivers to be
>>> reused for other domain numbers.
>>>
>>> Getting ready to remove pci_get_bus_and_slot() function in favor of
>>> pci_get_domain_bus_and_slot().
>>>
>>> Hard-code the domain number as 0 for the AMD IOMMU driver.
>
> <snip>
>
>>
>> Any comments from the IOMMU people?
>>
>
> pci_get_bus_and_slot() appears to (now) be a convenience function that wraps pci_get_domain_bus_and_slot() while using a 0 for the domain value. Exactly what you are doing here, albeit in a more overt way.
>
> How is this patch advantageous? Seems to me that if other domains need to be enabled, that driver could be changed if and when that requirement arises.
>
> But perhaps I'm missing a nuance here.
>
>
The benefit of the change was discussed here:
https://lkml.org/lkml/2017/12/19/349
I hope it helps.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [GIT PULL] ARM: uniphier: fixes for v4.15 (2nd)
From: Masahiro Yamada @ 2018-01-04 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a1QVn0PXde3q3xVMtdm2r3gS5yqdvSh15V1V+BFtTt9aA@mail.gmail.com>
Hi Arnd,
2018-01-05 1:10 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
> On Fri, Dec 29, 2017 at 1:30 PM, Masahiro Yamada
> <yamada.masahiro@socionext.com> wrote:
>> Hi Arnd, Olof,
>>
>> This is the 2nd bug-fix pull request for v4.15.
>> Just one DT fix. Please pull!
>
> I've ended up cherry-picking that commit manually into the fixes branch:
> We haven't updated the fixes branch to a later -rc, and your pull request
> was based on -rc3, so pulling it would create an ugly backmerge.
>
> You did nothing wrong here, so it seemed unnecessary to ask you for
> a respin based on -rc1. Hope that works for you.
>
> Arnd
Works for me. Thanks!
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* ARM: SoC fixes for 4.15
From: Arnd Bergmann @ 2018-01-04 16:46 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit ce39882eb1d87dd9bb4f89d4ae09ef2547aee079:
Merge tag 'amlogic-fixes-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic
into fixes (2017-12-09 20:23:29 -0800)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
tags/armsoc-fixes
for you to fetch changes up to abb62c46d4949d44979fa647740feff3f7538799:
arm64: dts: uniphier: fix gpio-ranges property of PXs3 SoC
(2018-01-04 17:09:01 +0100)
----------------------------------------------------------------
ARM: SoC fixes for 4.15
Fixes this time include mostly device tree changes, as usual,
the notable ones include:
- A number of patches to fix most of the remaining DTC warnings
that got introduced when DTC started warning about some
obvious mistakes. We still have some remaining warnings that
probably may have to wait until 4.16 to get fixed while we
try to figure out what the correct contents should be.
- On Allwinner A64, Ethernet PHYs need a fix after a mistake in
coordination between patches merged through multiple branches.
- Various fixes for PMICs on allwinner based boards
- Two fixes for ethernet link detection on some Renesas machines
- Two stability fixes for rockchip based boards
Aside from device-tree, two other areas got fixes for older
problems:
- For TI Davinci DM365, a couple of fixes were needed to repair
the MMC DMA engine support, apparently this has been broken for
a while.
- One important fix for all Allwinner chips with the PMIC driver
as a loadable module.
----------------------------------------------------------------
[note: this is a bit larger than usual. Most of the fixes were merged
before Christmas into the fixes branch, but then neither of us
was around to send the pull request until now].
Alejandro Mery (3):
ARM: davinci: Use platform_device_register_full() to create pdev
for dm365's eDMA
ARM: davinci: Add dma_mask to dm365's eDMA device
ARM: davinci: fix mmc entries in dm365's dma_slave_map
Arnd Bergmann (8):
Merge tag 'v4.15-rockchip-dts32fixes-1' of
ssh://gitolite.kernel.org/.../mmind/linux-rockchip into fixes
Merge tag 'v4.15-rockchip-dts64fixes-1' of
ssh://gitolite.kernel.org/.../mmind/linux-rockchip into fixes
Merge tag 'at91-ab-4.15-dt-fixes' of
ssh://gitolite.kernel.org/.../abelloni/linux into fixes
Merge tag 'davinci-fixes-for-v4.15' of
ssh://gitolite.kernel.org/.../nsekhar/linux-davinci into fixes
ARM: dts: ls1021a: fix incorrect clock references
ARM: dts: tango4: remove bogus interrupt-controller property
Merge tag 'renesas-fixes-for-v4.15' of
ssh://gitolite.kernel.org/.../horms/renesas into fixes
Merge tag 'sunxi-fixes-for-4.15' of
ssh://gitolite.kernel.org/.../sunxi/linux into fixes
Bogdan Mirea (2):
arm64: dts: renesas: salvator-x: Remove renesas, no-ether-link property
arm64: dts: renesas: ulcb: Remove renesas, no-ether-link property
Chen-Yu Tsai (1):
ARM: dts: sunxi: Convert to CCU index macros for HDMI controller
David Lechner (1):
ARM: dts: da850-lego-ev3: Fix battery voltage gpio
Heiko Stuebner (3):
ARM: dts: rockchip: add cpu0-regulator on rk3066a-marsboard
arm64: dts: rockchip: fix trailing 0 in rk3328 tsadc interrupts
arm64: dts: rockchip: limit rk3328-rock64 gmac speed to 100MBit for now
Icenowy Zheng (1):
arm64: allwinner: a64: add Ethernet PHY regulator for several boards
Jagan Teki (1):
arm64: allwinner: a64-sopine: Fix to use dcdc1 regulator instead of vcc3v3
Javier Martinez Canillas (1):
ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
Joel Stanley (1):
ARM: dts: aspeed-g4: Correct VUART IRQ number
Klaus Goger (1):
arm64: dts: rockchip: remove vdd_log from rk3399-puma
Masahiro Yamada (1):
arm64: dts: uniphier: fix gpio-ranges property of PXs3 SoC
Maxime Ripard (1):
ARM: dts: sun8i: a711: Reinstate the PMIC compatible
Peter Rosin (1):
ARM: dts: at91: disable the nxp,se97b SMBUS timeout on the TSE-850
Rob Herring (1):
ARM: dts: rockchip: fix rk3288 iep-IOMMU interrupts property cells
Sergey Matyukevich (1):
arm64: dts: orange-pi-zero-plus2: fix sdcard detect
Stefan Br?ns (1):
sunxi-rsb: Include OF based modalias in device uevent
arch/arm/boot/dts/aspeed-g4.dtsi | 2 +-
arch/arm/boot/dts/at91-tse850-3.dts | 1 +
arch/arm/boot/dts/da850-lego-ev3.dts | 4 +--
arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 +++
arch/arm/boot/dts/ls1021a-qds.dts | 2 +-
arch/arm/boot/dts/ls1021a-twr.dts | 2 +-
arch/arm/boot/dts/rk3066a-marsboard.dts | 4 +++
arch/arm/boot/dts/rk3288.dtsi | 2 +-
arch/arm/boot/dts/sun4i-a10.dtsi | 4 +--
arch/arm/boot/dts/sun5i-a10s.dtsi | 4 +--
arch/arm/boot/dts/sun6i-a31.dtsi | 4 +--
arch/arm/boot/dts/sun7i-a20.dtsi | 4 +--
arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 1 +
arch/arm/boot/dts/tango4-common.dtsi | 1 -
arch/arm/mach-davinci/dm365.c | 29 ++++++++++++++--------
.../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 1 +
.../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 1 +
.../dts/allwinner/sun50i-a64-sopine-baseboard.dts | 3 ++-
.../boot/dts/allwinner/sun50i-a64-sopine.dtsi | 11 +-------
.../allwinner/sun50i-h5-orangepi-zero-plus2.dts | 2 +-
arch/arm64/boot/dts/renesas/salvator-common.dtsi | 1 -
arch/arm64/boot/dts/renesas/ulcb.dtsi | 1 -
arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 2 ++
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 2 +-
arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 11 --------
arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi | 4 +--
drivers/bus/sunxi-rsb.c | 1 +
27 files changed, 54 insertions(+), 54 deletions(-)
^ permalink raw reply
* [PATCH v3 0/3] arm64: dts: r8a779[56]: Add OPPs table for cpu devices
From: Simon Horman @ 2018-01-04 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180103173801.GF22490@bigcity.dyn.berto.se>
On Wed, Jan 03, 2018 at 06:38:01PM +0100, Niklas S?derlund wrote:
> Hi Simon,
>
> Thanks for your work.
>
> I tested these patches together with the dependencies of the
> topic/rcar-gen3-cpufreq-v4 branch, feel free to add to all patches in
> this series.
>
> Tested-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
Thanks, applied.
^ permalink raw reply
* [PATCH V7 11/12] arm64: dts: add syscon for whale2 platform
From: Arnd Bergmann @ 2018-01-04 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAfSe-tc6s6F-1AYEamZubJ7VfMXm-rp18c8pctE51izeHXsnA@mail.gmail.com>
On Fri, Dec 22, 2017 at 6:30 AM, Chunyan Zhang <zhang.lyra@gmail.com> wrote:
> On 22 December 2017 at 07:03, Stephen Boyd <sboyd@codeaurora.org> wrote:
>> On 12/07, Chunyan Zhang wrote:
>>> Some clocks on SC9860 are in the same address area with syscon
>>> devices, the proper syscon node will be quoted under the
>>> definitions of those clocks in DT.
>>>
>>> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
>>> ---
>>
>> These last two can go via arm-soc?
>
> Thanks Stephen!
>
> Hi Arnd, Olof
>
> Could you please take the patch 11, 12 through arm-soc?
Applied both to next/dt now, thanks!
Arnd
^ permalink raw reply
* [PATCH] ARM: dts: kirkwood: fix pin-muxing of MPP7
From: Thomas Petazzoni @ 2018-01-04 16:53 UTC (permalink / raw)
To: linux-arm-kernel
MPP7 is currently muxed as "gpio", but this function doesn't exist for
MPP7, only "gpo" is available. This causes the following error:
kirkwood-pinctrl f1010000.pin-controller: unsupported function gpio on pin mpp7
pinctrl core: failed to register map default (6): invalid type given
kirkwood-pinctrl f1010000.pin-controller: error claiming hogs: -22
kirkwood-pinctrl f1010000.pin-controller: could not claim hogs: -22
kirkwood-pinctrl f1010000.pin-controller: unable to register pinctrl driver
kirkwood-pinctrl: probe of f1010000.pin-controller failed with error -22
So the pinctrl driver is not probed, all device drivers (including the
UART driver) do a -EPROBE_DEFER, and therefore the system doesn't
really boot (well, it boots, but with no UART, and no devices that
require pin-muxing).
Back when the Device Tree file for this board was introduced, the
definition was already wrong. The pinctrl driver also always described
as "gpo" this function for MPP7. However, between Linux 4.10 and 4.11,
a hog pin failing to be muxed was turned from a simple warning to a
hard error that caused the entire pinctrl driver probe to bail
out. This is probably the result of commit 6118714275f0a ("pinctrl:
core: Fix pinctrl_register_and_init() with pinctrl_enable()").
This commit fixes the Device Tree to use the proper "gpo" function for
MPP7, which fixes the boot of OpenBlocks A7, which was broken since
Linux 4.11.
Fixes: f24b56cbcd9d ("ARM: kirkwood: add support for OpenBlocks A7 platform")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/boot/dts/kirkwood-openblocks_a7.dts | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-openblocks_a7.dts b/arch/arm/boot/dts/kirkwood-openblocks_a7.dts
index cf2f5240e176..27cc913ca0f5 100644
--- a/arch/arm/boot/dts/kirkwood-openblocks_a7.dts
+++ b/arch/arm/boot/dts/kirkwood-openblocks_a7.dts
@@ -53,7 +53,8 @@
};
pinctrl: pin-controller at 10000 {
- pinctrl-0 = <&pmx_dip_switches &pmx_gpio_header>;
+ pinctrl-0 = <&pmx_dip_switches &pmx_gpio_header
+ &pmx_gpio_header_gpo>;
pinctrl-names = "default";
pmx_uart0: pmx-uart0 {
@@ -85,11 +86,16 @@
* ground.
*/
pmx_gpio_header: pmx-gpio-header {
- marvell,pins = "mpp17", "mpp7", "mpp29", "mpp28",
+ marvell,pins = "mpp17", "mpp29", "mpp28",
"mpp35", "mpp34", "mpp40";
marvell,function = "gpio";
};
+ pmx_gpio_header_gpo: pxm-gpio-header-gpo {
+ marvell,pins = "mpp7";
+ marvell,function = "gpo";
+ };
+
pmx_gpio_init: pmx-init {
marvell,pins = "mpp38";
marvell,function = "gpio";
--
2.14.3
^ permalink raw reply related
* [PATCH v2 0/4] arm64: defconfig: enable additional led triggers
From: Arnd Bergmann @ 2018-01-04 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAP245DUnO6qoXXoAOakQ_HYTTbR+CgO-nQ-Jm5nOaPeySm968g@mail.gmail.com>
On Tue, Jan 2, 2018 at 8:19 AM, Amit Kucheria <amit.kucheria@linaro.org> wrote:
> On Thu, Dec 21, 2017 at 8:46 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wed, Dec 6, 2017 at 9:57 AM, Amit Kucheria <amit.kucheria@linaro.org> wrote:
>>> (Adding Arnd)
>>>
>>> Now that the merge window rush has abated, can you please apply this
>>> trivial series?
>>>
>>> On Mon, Nov 6, 2017 at 12:38 PM, Amit Kucheria <amit.kucheria@linaro.org> wrote:
>>>> This patchset enables the kernel panic and disk-activity trigger for LEDs
>>>> and then enables the panic trigger for three 96Boards - DB410c, Hikey and
>>>> Hikey960.
>>>>
>>>> DB410c and Hikey panic behaviour has been tested by triggering a panic
>>>> through /proc/sysrq-trigger, while Hikey960 is only compile-tested.
>>
>> I applied all four now, but it would have been easier for me if you had either
>> sent them to the platform maintainers, or to arm at kernel.org.
>
> The platform maintainers are cc'ed but I guess nobody took them since
> the patchset touched 3 different platforms and a common defconfig.
>
> I'll remember to cc arm at kernel.org in the future but is there any
> reason why this email address isn't listed in MAINTAINERS?
We normally want to have all patches merged through the platform
maintainers, and have no ambiguity regarding who picks things up.
More importantly, being listed in the MAINTAINERS file would result
in us getting thousands of patches each merge window mixed in with
the stuff that we actually do need to see, so that would likely be more
lossy and more work for us.
Arnd
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a77970: move node which has no reg property out of bus
From: Simon Horman @ 2018-01-04 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220122549.9452-1-horms+renesas@verge.net.au>
On Wed, Dec 20, 2017 at 01:25:49PM +0100, Simon Horman wrote:
> Move timer node from soc node to root node. The node that have been moved
> do not have any register properties and thus shouldn't be placed on the
> bus.
>
> This problem is flagged by the compiler as follows:
> $ make W=1
> ...
> DTC arch/arm64/boot/dts/renesas/r8a77970-eagle.dtb
> arch/arm64/boot/dts/renesas/r8a77970-eagle.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
> DTC arch/arm64/boot/dts/renesas/r8a77970-v3msk.dtb
> arch/arm64/boot/dts/renesas/r8a77970-v3msk.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Applied
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox