* [PATCH] PCI: layerscape: Fix kernel panic on accessing NULL pointer
From: Bjorn Helgaas @ 2016-10-21 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476740647-11155-1-git-send-email-leoyang.li@nxp.com>
On Mon, Oct 17, 2016 at 04:44:06PM -0500, Li Yang wrote:
> Commit fefe6733e added reference to the pcie->drvdata before it is
> initialized which causes a kernel panic. Fix the problem by
> initializing the pcie->drvdata earlier before it is used.
>
> Reported-by: Stuart Yoder <stuart.yoder@nxp.com>
> Signed-off-by: Li Yang <leoyang.li@nxp.com>
I applied Marc Zyngier's identical patch to for-linus for v4.9. I don't
know which was posted first, but I saw Marc's first. Sorry I didn't at
least credit you when I applied it.
> ---
> drivers/pci/host/pci-layerscape.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/host/pci-layerscape.c b/drivers/pci/host/pci-layerscape.c
> index 2cb7315..958187f 100644
> --- a/drivers/pci/host/pci-layerscape.c
> +++ b/drivers/pci/host/pci-layerscape.c
> @@ -245,6 +245,7 @@ static int __init ls_pcie_probe(struct platform_device *pdev)
> if (!pcie)
> return -ENOMEM;
>
> + pcie->drvdata = match->data;
> pp = &pcie->pp;
> pp->dev = dev;
> pp->ops = pcie->drvdata->ops;
> @@ -256,7 +257,6 @@ static int __init ls_pcie_probe(struct platform_device *pdev)
> return PTR_ERR(pcie->pp.dbi_base);
> }
>
> - pcie->drvdata = match->data;
> pcie->lut = pcie->pp.dbi_base + pcie->drvdata->lut_offset;
>
> if (!ls_pcie_is_bridge(pcie))
> --
> 1.9.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state
From: Philipp Zabel @ 2016-10-21 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477055857-17936-1-git-send-email-geert+renesas@glider.be>
A. Hi Geert,
Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
> Hi Philipp, Mike, Stephen, Simon, Magnus,
> (see questions *** below!)
>
> Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> state of the mode pins either by a call from the platform code, or
> directly by using a hardcoded register access. This is a bit messy, and
> creates a dependency between driver and platform code.
>
> This patch series converts the various Renesas R-Car clock drivers
> and support code from reading the mode pin states using a hardcoded
> register access to using a new minimalistic R-Car RST driver.
>
> All R-Car clock drivers will rely on the presence in DT of a device node
> for the RST module. Backwards compatibility with old DTBs is retained
> only for R-Car Gen2, which has fallback code using its own private copy
> of rcar_gen2_read_mode_pins().
I think you should add a binding doc even though the DT bindings are
still trivial.
> After this, there is still one remaining user of
> rcar_gen2_read_mode_pins() left in platform code. A patch series to
> remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
>
> This series consists of 5 parts:
> A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
> driver,
> B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
> files,
> C. Patches 12-17 convert the clock drivers to call into the new R-Car
> RST driver,
> D. Patches 18-20 remove passing mode pin state to the clock drivers
> from the platform code,
> E. Patches 21-23 remove dead code from the clock drivers.
>
> As is usually the case with moving functionality from platform code to
> DT, there are lots of hard dependencies:
> - The DT updates in Part B can be merged as soon as the DT bindings in
> Part A have been approved,
> - The clock driver updates in Part C depend functionally on the driver
> code in Part A, and on the DT updates in Part B,
> - The board code cleanups in Part D depend on the clock driver updates
> in Part C,
> - The block driver cleanups in part E depend on the board code
> cleanups in part D.
>
> Hence to maintain the required lockstep between SoC driver, clock
> drivers, shmobile platform code, and shmobile DT, I propose to queue up
> all patches in a single branch against v4.9-rc1, and send pull requests
> to both Mike/Stephen (clock) and Simon (rest).
>
> ***
>
> - Philip: While this is a driver for a reset-controller, currently it
> doesn't provide any reset-controller functionality. Hence I added it
> to drivers/soc/renesas/. Is that OK for you?
Absolutely, as long as the driver isn't even a reset controller
provider, this is the right place.
regards
Philipp
^ permalink raw reply
* [RFC PATCH 08/13] dwmac-meson8b: add support for phy selection
From: Andrew Lunn @ 2016-10-21 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477060838-14164-9-git-send-email-narmstrong@baylibre.com>
On Fri, Oct 21, 2016 at 04:40:33PM +0200, Neil Armstrong wrote:
> The Meson GXL dwmac Glue Layer also provides switching between an external PHY
> and an internal RMII 10/100 PHY.
> Add a way to setup the correct PHY switching from a device tree attribute.
Hi Neil
Can this be made automatic?
The internal PHY appears to be on address 8. Can there also be an
external PHY on address 8? Could you follow the phy-handle link to the
phy node, check the address, and if it is 8, configure for an internal
PHY?
Andrew
^ permalink raw reply
* [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state
From: Philipp Zabel @ 2016-10-21 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477064730.2508.24.camel@pengutronix.de>
Am Freitag, den 21.10.2016, 17:45 +0200 schrieb Philipp Zabel:
> A. Hi Geert,
>
> Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
> > Hi Philipp, Mike, Stephen, Simon, Magnus,
> > (see questions *** below!)
> >
> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> > state of the mode pins either by a call from the platform code, or
> > directly by using a hardcoded register access. This is a bit messy, and
> > creates a dependency between driver and platform code.
> >
> > This patch series converts the various Renesas R-Car clock drivers
> > and support code from reading the mode pin states using a hardcoded
> > register access to using a new minimalistic R-Car RST driver.
> >
> > All R-Car clock drivers will rely on the presence in DT of a device node
> > for the RST module. Backwards compatibility with old DTBs is retained
> > only for R-Car Gen2, which has fallback code using its own private copy
> > of rcar_gen2_read_mode_pins().
>
> I think you should add a binding doc even though the DT bindings are
> still trivial.
Disregard that, I literally sent this mail and a second later noticed
patch 1 for the first time.
regards
Philipp
^ permalink raw reply
* [PATCH v4 01/23] reset: Add renesas,rst DT bindings
From: Philipp Zabel @ 2016-10-21 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477055857-17936-2-git-send-email-geert+renesas@glider.be>
Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
> Add DT bindings for the Renesas R-Car Reset Controller (R-Car Gen1
> RESET/WDT and R-Car Gen2/Gen3 and RZ/G RST).
>
> As the features provided by the hardware module differ a lot across the
> various SoC families and members, only SoC-specific compatible values
> are defined.
>
> For now we use the RST only for providing access to the state of the
> mode pins, which is needed by the clock driver.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Magnus Damm <damm+renesas@opensource.se>
> Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> v4:
> - Add Acked-by,
> - Fix comma and period in list,
> - Add RZ/G1M and RZ/G1E,
>
> v3:
> - Clarify current usage,
> - Use "renesas,<soctype>-rst" instead of "renesas,rst-<soctype>",
> - Drop "syscon" compatible value,
> - Add R-Car M3-W,
> - Add R-Car Gen1,
>
> v2:
> - Add Acked-by.
> ---
> .../devicetree/bindings/reset/renesas,rst.txt | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/renesas,rst.txt
>
> diff --git a/Documentation/devicetree/bindings/reset/renesas,rst.txt b/Documentation/devicetree/bindings/reset/renesas,rst.txt
> new file mode 100644
> index 0000000000000000..fe5e0f37b3c93579
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/renesas,rst.txt
> @@ -0,0 +1,37 @@
> +DT bindings for the Renesas R-Car and RZ/G Reset Controllers
> +
> +The R-Car and RZ/G Reset Controllers provide reset control, and implement the
> +following functions:
> + - Latching of the levels on mode pins when PRESET# is negated,
> + - Mode monitoring register,
> + - Reset control of peripheral devices (on R-Car Gen1),
> + - Watchdog timer (on R-Car Gen1),
> + - Register-based reset control and boot address registers for the various CPU
> + cores (on R-Car Gen2 and Gen3, and on RZ/G).
> +
> +
> +Required properties:
> + - compatible: Should be
> + - "renesas,<soctype>-reset-wdt" for R-Car Gen1,
> + - "renesas,<soctype>-rst" for R-Car Gen2 and Gen3, and RZ/G
> + Examples with soctypes are:
> + - "renesas,r8a7743-rst" (RZ/G1M)
> + - "renesas,r8a7745-rst" (RZ/G1E)
> + - "renesas,r8a7778-reset-wdt" (R-Car M1A)
> + - "renesas,r8a7779-reset-wdt" (R-Car H1)
> + - "renesas,r8a7790-rst" (R-Car H2)
> + - "renesas,r8a7791-rst" (R-Car M2-W)
> + - "renesas,r8a7792-rst" (R-Car V2H
> + - "renesas,r8a7793-rst" (R-Car M2-N)
> + - "renesas,r8a7794-rst" (R-Car E2)
> + - "renesas,r8a7795-rst" (R-Car H3)
> + - "renesas,r8a7796-rst" (R-Car M3-W)
> + - reg: Address start and address range for the device.
> +
> +
> +Example:
> +
> + rst: reset-controller at e6160000 {
> + compatible = "renesas,r8a7795-rst";
> + reg = <0 0xe6160000 0 0x0200>;
> + };
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
regards
Philipp
^ permalink raw reply
* [PATCH 2/3] ARM: convert to generated system call tables
From: Russell King - ARM Linux @ 2016-10-21 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4337157.Eff9E2riVH@wuerfel>
On Fri, Oct 21, 2016 at 05:18:30PM +0200, Arnd Bergmann wrote:
> On Friday, October 21, 2016 2:37:08 PM CEST Russell King - ARM Linux wrote:
> > On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
>
> > > If we hit this case, why not just use the wrapper on both EABI
> > > and OABI for simplicity? It's not like we care a lot about
> > > micro-optimizing OABI any more.
> >
> > I'd still like to retain the ability to only add to EABI in the future.
>
> Do you mean to add an EABI specific workaround for a specific syscall
> if necessary, or to stop adding OABI syscalls altogether?
To stop adding OABI syscalls altogether. I'm sure that there will
come a point (if it hasn't already) that glibc no longer supports
OABI, and at that point it probably becomes rather silly to keep
adding OABI syscalls.
> > > That brings up an interesting issue: it would be nice to use the
> > > same input file for arch/arm/ and the compat mode of arch/arm64,
> > > like x86 does. If we handle both oabi and arm64-compat in the same
> > > file, we end up with a superset of what x86 does, and we could
> > > use a single script again, and generate all four tables for
> > > ARM (native OABI, OABI-on-EABI, native EABI, EABI-on-arm64).
> >
> > OABI-compat != ARM64-EABI-compat though. They're two completely
> > different things.
>
> For the purpose of generating the tables, I don't see much
> difference: we either use the fourth column only in native
> mode, or we use the fifth column to override values from
> the fourth one when emulating the ABI on the "other" kernel.
The table generation method can be shared, but I've no idea about the
feasibility of sharing the table between ARM64 and ARM - I don't know
enough about ARM64 to know whether things like an "long" argument to
a syscall (which would be 64-bit on ARM64) would be or would not be a
problem if called from a 32-bit user application.
I've zero knowledge of the whole 32-bit application on 64-bit CPUs
thing, so it's pointless trying to discuss this aspect with me. Even
for x86, all I care there is that it works, I've no knowledge of how
it works.
> That's similar to x86, 32-bit syscalls use the traditional numbers
> with an optionally different entry point for compat mode, while
> 64-bit syscalls use a somewhat reduced table that now has support
> for both native 64-bit and "x32" mode. x86-64 and x32 share a
> syscall table but not the unistd.h list, all three generated
> from syscall_64.tbl.
What's the point of the x32 mode?
> ARM64 has a separate list of syscalls for compat mode in
> arch/arm64/include/asm/unistd32.h, this list has the same format
> as include/asm-generic/uapi/unistd.h and must be updated manually
> to match the arch/arm/ table today.
Looking through it, sort-of. It could have re-used the numbering
from the arch/arm include file, but because ARM64 wanted to be an
entirely separate architecture, it duplicates a lot from 32-bit ARM.
I pointed that out at the time, and was shouted down (which is why
today I have absolutely nothing to do with ARM64, and as a result
have very little knowledge about ARM64 - I lost interest in it as
a result of the responses I got to my comments.)
So... if you don't mind, this isn't an issue I care one iota about.
In order for something to work like what you're alluding to, ARM64
would have to ferret around in arch/arm to pull out the bits it
wants, and I see zero reason for that to be acceptable on either
side of the ARM64 vs ARM divide - it will make my job harder because
I'm then into the position where I need acks from ARM64 people to
change ARM code, and that doesn't interest me at all. I'm not going
to put myself into a position where I'm at the mercy of ARM64 folk.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 0/6] ARM: sun5i: chip: Misc improvements
From: Maxime Ripard @ 2016-10-21 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65L=Cf1EWgZ1YPyFA_g7aiqAGwNkC-e0vs3OM8BJ2OEbA@mail.gmail.com>
On Fri, Oct 21, 2016 at 11:02:23AM +0800, Chen-Yu Tsai wrote:
> On Mon, Oct 17, 2016 at 7:48 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi,
> >
> > This is a bunch of patches I gathered for the CHIP, that enables a few
> > things, like the WiFi regulators (and its associated power sequence), a few
> > optional buses, etc.
Applied all with your Acked-by
> FYI this series makes more sense if you mention the Pocket CHIP DT overlays.
Not really, most of these patches are for the CHIP itself. The Pocket
CHIP, just like all the other DIPs so far, uses the LCD pins, but
that's pretty much the only DIP-specific patch there.
Thanks!
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: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161021/81295753/attachment.sig>
^ permalink raw reply
* [RFC PATCH 08/13] dwmac-meson8b: add support for phy selection
From: Andrew Lunn @ 2016-10-21 15:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477060838-14164-9-git-send-email-narmstrong@baylibre.com>
On Fri, Oct 21, 2016 at 04:40:33PM +0200, Neil Armstrong wrote:
> The Meson GXL dwmac Glue Layer also provides switching between an external PHY
> and an internal RMII 10/100 PHY.
> Add a way to setup the correct PHY switching from a device tree attribute.
Humm, actually. Maybe PHY_IS_INTERNAL in the phydrv->flags is the
better solution. The MAC can then use phy_is_internal(ndev->phydev) to
decide if this register needs programming.
Andrew
^ permalink raw reply
* [PATCH V6 00/10] dmaengine: qcom_hidma: add MSI interrupt support
From: Sinan Kaya @ 2016-10-21 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021065723.GA2467@localhost>
On 10/20/2016 11:57 PM, Vinod Koul wrote:
>> It looks like patches were applied out of order.
> When applying, if I get a conflict I try to skip them. Typically subsequent
> patches fail, sometimes they apply. I think couple of them did in this case
>
> It built for me, 0day also gave me success report, so unless we have bisect
> regression, I would like rest of the patches on top of this please..
>
OK. Let me work on it.
--
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
* [PATCH 0/5] Remove STiH415/416 SoC platform support remaining parts
From: patrice.chotard at st.com @ 2016-10-21 15:57 UTC (permalink / raw)
To: linux-arm-kernel
From: Patrice Chotard <patrice.chotard@st.com>
ST have sent patches which remove clock support for these SoCs [1]
which once applied mean the platform will no longer boot.
This series cleans up remaining STi drivers which have
support for these SoC's, by removing code, and updating the DT
documentation accordingly. Some drivers such as st_thermal_syscfg
can be removed completely because the IP is only found on these
legacy SoC's.
Patrice Chotard (5):
thermal: st_thermal_syscfg: Remove obsolete STiH415/416 platform
support.
ARM: multi_v7_defconfig: Remove ST_THERMAL_SYSCFG Kconfig symbol
ARM: multi_v7_defconfig: Remove CONFIG_ST_THERMAL_MEMMAP Kconfig
symbol
irqchip: st: remove STiH415/416 irqchip support
irqchip: st: Remove obsolete platforms from dt binding doc
.../interrupt-controller/st,sti-irq-syscfg.txt | 6 +-
arch/arm/configs/multi_v7_defconfig | 2 -
drivers/irqchip/irq-st.c | 10 --
drivers/thermal/st/Kconfig | 4 -
drivers/thermal/st/Makefile | 1 -
drivers/thermal/st/st_thermal_syscfg.c | 178 ---------------------
6 files changed, 2 insertions(+), 199 deletions(-)
delete mode 100644 drivers/thermal/st/st_thermal_syscfg.c
--
1.9.1
^ permalink raw reply
* [PATCH 1/5] thermal: st_thermal_syscfg: Remove obsolete STiH415/416 platform support.
From: patrice.chotard at st.com @ 2016-10-21 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477065443-10668-1-git-send-email-patrice.chotard@st.com>
From: Patrice Chotard <patrice.chotard@st.com>
STiH415/6 SoC support is being removed from the kernel.
This patch removes support from the syscfg thermal driver.
This driver also supports STiD127 SoC which has never been
upstreamed.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Cc: <rui.zhang@intel.com>
Cc: <edubezval@gmail.com>
---
drivers/thermal/st/Kconfig | 4 -
drivers/thermal/st/Makefile | 1 -
drivers/thermal/st/st_thermal_syscfg.c | 178 ---------------------------------
3 files changed, 183 deletions(-)
delete mode 100644 drivers/thermal/st/st_thermal_syscfg.c
diff --git a/drivers/thermal/st/Kconfig b/drivers/thermal/st/Kconfig
index 490fdbe..ce84267 100644
--- a/drivers/thermal/st/Kconfig
+++ b/drivers/thermal/st/Kconfig
@@ -3,10 +3,6 @@ config ST_THERMAL
help
Support for thermal sensors on STMicroelectronics STi series of SoCs.
-config ST_THERMAL_SYSCFG
- select ST_THERMAL
- tristate "STi series syscfg register access based thermal sensors"
-
config ST_THERMAL_MEMMAP
select ST_THERMAL
tristate "STi series memory mapped access based thermal sensors"
diff --git a/drivers/thermal/st/Makefile b/drivers/thermal/st/Makefile
index b388789..27197e1 100644
--- a/drivers/thermal/st/Makefile
+++ b/drivers/thermal/st/Makefile
@@ -1,3 +1,2 @@
obj-$(CONFIG_ST_THERMAL) := st_thermal.o
-obj-$(CONFIG_ST_THERMAL_SYSCFG) += st_thermal_syscfg.o
obj-$(CONFIG_ST_THERMAL_MEMMAP) += st_thermal_memmap.o
diff --git a/drivers/thermal/st/st_thermal_syscfg.c b/drivers/thermal/st/st_thermal_syscfg.c
deleted file mode 100644
index 3df5b789..0000000
--- a/drivers/thermal/st/st_thermal_syscfg.c
+++ /dev/null
@@ -1,178 +0,0 @@
-/*
- * ST Thermal Sensor Driver for syscfg based sensors.
- * Author: Ajit Pal Singh <ajitpal.singh@st.com>
- *
- * Copyright (C) 2003-2014 STMicroelectronics (R&D) Limited
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#include <linux/of.h>
-#include <linux/module.h>
-#include <linux/mfd/syscon.h>
-
-#include "st_thermal.h"
-
-/* STiH415 */
-#define STIH415_SYSCFG_FRONT(num) ((num - 100) * 4)
-#define STIH415_SAS_THSENS_CONF STIH415_SYSCFG_FRONT(178)
-#define STIH415_SAS_THSENS_STATUS STIH415_SYSCFG_FRONT(198)
-#define STIH415_SYSCFG_MPE(num) ((num - 600) * 4)
-#define STIH415_MPE_THSENS_CONF STIH415_SYSCFG_MPE(607)
-#define STIH415_MPE_THSENS_STATUS STIH415_SYSCFG_MPE(667)
-
-/* STiH416 */
-#define STIH416_SYSCFG_FRONT(num) ((num - 1000) * 4)
-#define STIH416_SAS_THSENS_CONF STIH416_SYSCFG_FRONT(1552)
-#define STIH416_SAS_THSENS_STATUS1 STIH416_SYSCFG_FRONT(1554)
-#define STIH416_SAS_THSENS_STATUS2 STIH416_SYSCFG_FRONT(1594)
-
-/* STiD127 */
-#define STID127_SYSCFG_CPU(num) ((num - 700) * 4)
-#define STID127_THSENS_CONF STID127_SYSCFG_CPU(743)
-#define STID127_THSENS_STATUS STID127_SYSCFG_CPU(767)
-
-static const struct reg_field st_415sas_regfields[MAX_REGFIELDS] = {
- [TEMP_PWR] = REG_FIELD(STIH415_SAS_THSENS_CONF, 9, 9),
- [DCORRECT] = REG_FIELD(STIH415_SAS_THSENS_CONF, 4, 8),
- [OVERFLOW] = REG_FIELD(STIH415_SAS_THSENS_STATUS, 8, 8),
- [DATA] = REG_FIELD(STIH415_SAS_THSENS_STATUS, 10, 16),
-};
-
-static const struct reg_field st_415mpe_regfields[MAX_REGFIELDS] = {
- [TEMP_PWR] = REG_FIELD(STIH415_MPE_THSENS_CONF, 8, 8),
- [DCORRECT] = REG_FIELD(STIH415_MPE_THSENS_CONF, 3, 7),
- [OVERFLOW] = REG_FIELD(STIH415_MPE_THSENS_STATUS, 9, 9),
- [DATA] = REG_FIELD(STIH415_MPE_THSENS_STATUS, 11, 18),
-};
-
-static const struct reg_field st_416sas_regfields[MAX_REGFIELDS] = {
- [TEMP_PWR] = REG_FIELD(STIH416_SAS_THSENS_CONF, 9, 9),
- [DCORRECT] = REG_FIELD(STIH416_SAS_THSENS_CONF, 4, 8),
- [OVERFLOW] = REG_FIELD(STIH416_SAS_THSENS_STATUS1, 8, 8),
- [DATA] = REG_FIELD(STIH416_SAS_THSENS_STATUS2, 10, 16),
-};
-
-static const struct reg_field st_127_regfields[MAX_REGFIELDS] = {
- [TEMP_PWR] = REG_FIELD(STID127_THSENS_CONF, 7, 7),
- [DCORRECT] = REG_FIELD(STID127_THSENS_CONF, 2, 6),
- [OVERFLOW] = REG_FIELD(STID127_THSENS_STATUS, 9, 9),
- [DATA] = REG_FIELD(STID127_THSENS_STATUS, 11, 18),
-};
-
-/* Private OPs for System Configuration Register based thermal sensors */
-static int st_syscfg_power_ctrl(struct st_thermal_sensor *sensor,
- enum st_thermal_power_state power_state)
-{
- return regmap_field_write(sensor->pwr, power_state);
-}
-
-static int st_syscfg_alloc_regfields(struct st_thermal_sensor *sensor)
-{
- struct device *dev = sensor->dev;
-
- sensor->pwr = devm_regmap_field_alloc(dev, sensor->regmap,
- sensor->cdata->reg_fields[TEMP_PWR]);
-
- if (IS_ERR(sensor->pwr)) {
- dev_err(dev, "failed to alloc syscfg regfields\n");
- return PTR_ERR(sensor->pwr);
- }
-
- return 0;
-}
-
-static int st_syscfg_regmap_init(struct st_thermal_sensor *sensor)
-{
- sensor->regmap =
- syscon_regmap_lookup_by_compatible(sensor->cdata->sys_compat);
- if (IS_ERR(sensor->regmap)) {
- dev_err(sensor->dev, "failed to find syscfg regmap\n");
- return PTR_ERR(sensor->regmap);
- }
-
- return 0;
-}
-
-static const struct st_thermal_sensor_ops st_syscfg_sensor_ops = {
- .power_ctrl = st_syscfg_power_ctrl,
- .alloc_regfields = st_syscfg_alloc_regfields,
- .regmap_init = st_syscfg_regmap_init,
-};
-
-/* Compatible device data for stih415 sas thermal sensor */
-static const struct st_thermal_compat_data st_415sas_cdata = {
- .sys_compat = "st,stih415-front-syscfg",
- .reg_fields = st_415sas_regfields,
- .ops = &st_syscfg_sensor_ops,
- .calibration_val = 16,
- .temp_adjust_val = 20,
- .crit_temp = 120,
-};
-
-/* Compatible device data for stih415 mpe thermal sensor */
-static const struct st_thermal_compat_data st_415mpe_cdata = {
- .sys_compat = "st,stih415-system-syscfg",
- .reg_fields = st_415mpe_regfields,
- .ops = &st_syscfg_sensor_ops,
- .calibration_val = 16,
- .temp_adjust_val = -103,
- .crit_temp = 120,
-};
-
-/* Compatible device data for stih416 sas thermal sensor */
-static const struct st_thermal_compat_data st_416sas_cdata = {
- .sys_compat = "st,stih416-front-syscfg",
- .reg_fields = st_416sas_regfields,
- .ops = &st_syscfg_sensor_ops,
- .calibration_val = 16,
- .temp_adjust_val = 20,
- .crit_temp = 120,
-};
-
-/* Compatible device data for stid127 thermal sensor */
-static const struct st_thermal_compat_data st_127_cdata = {
- .sys_compat = "st,stid127-cpu-syscfg",
- .reg_fields = st_127_regfields,
- .ops = &st_syscfg_sensor_ops,
- .calibration_val = 8,
- .temp_adjust_val = -103,
- .crit_temp = 120,
-};
-
-static const struct of_device_id st_syscfg_thermal_of_match[] = {
- { .compatible = "st,stih415-sas-thermal", .data = &st_415sas_cdata },
- { .compatible = "st,stih415-mpe-thermal", .data = &st_415mpe_cdata },
- { .compatible = "st,stih416-sas-thermal", .data = &st_416sas_cdata },
- { .compatible = "st,stid127-thermal", .data = &st_127_cdata },
- { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, st_syscfg_thermal_of_match);
-
-static int st_syscfg_probe(struct platform_device *pdev)
-{
- return st_thermal_register(pdev, st_syscfg_thermal_of_match);
-}
-
-static int st_syscfg_remove(struct platform_device *pdev)
-{
- return st_thermal_unregister(pdev);
-}
-
-static struct platform_driver st_syscfg_thermal_driver = {
- .driver = {
- .name = "st_syscfg_thermal",
- .pm = &st_thermal_pm_ops,
- .of_match_table = st_syscfg_thermal_of_match,
- },
- .probe = st_syscfg_probe,
- .remove = st_syscfg_remove,
-};
-module_platform_driver(st_syscfg_thermal_driver);
-
-MODULE_AUTHOR("STMicroelectronics (R&D) Limited <ajitpal.singh@st.com>");
-MODULE_DESCRIPTION("STMicroelectronics STi SoC Thermal Sensor Driver");
-MODULE_LICENSE("GPL v2");
--
1.9.1
^ permalink raw reply related
* [PATCH 2/5] ARM: multi_v7_defconfig: Remove ST_THERMAL_SYSCFG Kconfig symbol
From: patrice.chotard at st.com @ 2016-10-21 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477065443-10668-1-git-send-email-patrice.chotard@st.com>
From: Patrice Chotard <patrice.chotard@st.com>
STiH415/6 SoC support is being removed from the kernel and
was the only platform using this Kconfig symbol
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Cc: <rui.zhang@intel.com>
Cc: <edubezval@gmail.com>
---
arch/arm/configs/multi_v7_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 437d074..15b2f99 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -450,7 +450,6 @@ CONFIG_RCAR_THERMAL=y
CONFIG_ARMADA_THERMAL=y
CONFIG_DAVINCI_WATCHDOG=m
CONFIG_EXYNOS_THERMAL=m
-CONFIG_ST_THERMAL_SYSCFG=y
CONFIG_ST_THERMAL_MEMMAP=y
CONFIG_WATCHDOG=y
CONFIG_DA9063_WATCHDOG=m
--
1.9.1
^ permalink raw reply related
* [PATCH 3/5] ARM: multi_v7_defconfig: Remove CONFIG_ST_THERMAL_MEMMAP Kconfig symbol
From: patrice.chotard at st.com @ 2016-10-21 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477065443-10668-1-git-send-email-patrice.chotard@st.com>
From: Patrice Chotard <patrice.chotard@st.com>
Driver code has been already removed, see
http://www.spinics.net/lists/devicetree/msg143322.html
Remove the multi_v7_defconfig part
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Cc: <rui.zhang@intel.com>
Cc: <edubezval@gmail.com>
---
arch/arm/configs/multi_v7_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 15b2f99..45e252b 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -450,7 +450,6 @@ CONFIG_RCAR_THERMAL=y
CONFIG_ARMADA_THERMAL=y
CONFIG_DAVINCI_WATCHDOG=m
CONFIG_EXYNOS_THERMAL=m
-CONFIG_ST_THERMAL_MEMMAP=y
CONFIG_WATCHDOG=y
CONFIG_DA9063_WATCHDOG=m
CONFIG_XILINX_WATCHDOG=y
--
1.9.1
^ permalink raw reply related
* [PATCH 4/5] irqchip: st: remove STiH415/416 irqchip support
From: patrice.chotard at st.com @ 2016-10-21 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477065443-10668-1-git-send-email-patrice.chotard@st.com>
From: Patrice Chotard <patrice.chotard@st.com>
Support for STiH415/6 SoCs is being removed from the
kernel because the platforms are obsolete. This patch removes
the irqchip for these SoC's.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Cc: <tglx@linutronix.de>
Cc: <jason@lakedaemon.net>
Cc: <marc.zyngier@arm.com>
---
drivers/irqchip/irq-st.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/drivers/irqchip/irq-st.c b/drivers/irqchip/irq-st.c
index 9af48a8..3ac9226 100644
--- a/drivers/irqchip/irq-st.c
+++ b/drivers/irqchip/irq-st.c
@@ -18,8 +18,6 @@
#include <linux/regmap.h>
#include <linux/slab.h>
-#define STIH415_SYSCFG_642 0x0a8
-#define STIH416_SYSCFG_7543 0x87c
#define STIH407_SYSCFG_5102 0x198
#define STID127_SYSCFG_734 0x088
@@ -48,14 +46,6 @@ struct st_irq_syscfg {
static const struct of_device_id st_irq_syscfg_match[] = {
{
- .compatible = "st,stih415-irq-syscfg",
- .data = (void *)STIH415_SYSCFG_642,
- },
- {
- .compatible = "st,stih416-irq-syscfg",
- .data = (void *)STIH416_SYSCFG_7543,
- },
- {
.compatible = "st,stih407-irq-syscfg",
.data = (void *)STIH407_SYSCFG_5102,
},
--
1.9.1
^ permalink raw reply related
* [PATCH 5/5] irqchip: st: Remove obsolete platforms from dt binding doc
From: patrice.chotard at st.com @ 2016-10-21 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477065443-10668-1-git-send-email-patrice.chotard@st.com>
From: Patrice Chotard <patrice.chotard@st.com>
STiH415/6 SoC support is being removed from the kernel.
This patch updates the sti irchip and removes
references to these obsolete platforms.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Cc: <tglx@linutronix.de>
Cc: <jason@lakedaemon.net>
Cc: <marc.zyngier@arm.com>
---
.../devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt b/Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt
index ced6014..23d1e1c 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt
@@ -7,8 +7,6 @@ This driver is used to unmask them prior to use.
Required properties:
- compatible : Should be set to one of:
- "st,stih415-irq-syscfg"
- "st,stih416-irq-syscfg"
"st,stih407-irq-syscfg"
"st,stid127-irq-syscfg"
- st,syscfg : Phandle to Cortex-A9 IRQ system config registers
@@ -25,8 +23,8 @@ Optional properties:
Example:
irq-syscfg {
- compatible = "st,stih416-irq-syscfg";
- st,syscfg = <&syscfg_cpu>;
+ compatible = "st,stih407-irq-syscfg";
+ st,syscfg = <&syscfg_core>;
st,irq-device = <ST_IRQ_SYSCFG_PMU_0>,
<ST_IRQ_SYSCFG_PMU_1>;
st,fiq-device = <ST_IRQ_SYSCFG_DISABLED>,
--
1.9.1
^ permalink raw reply related
* [PATCH 10/10] arm64: split thread_info from task stack
From: Mark Rutland @ 2016-10-21 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <580A2B3A.7000300@arm.com>
Hi James,
On Fri, Oct 21, 2016 at 03:50:34PM +0100, James Morse wrote:
> > arch/arm64/kernel/entry.S | 4 ++--
>
> 4? That was too easy...
Indeed... ;)
> > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> > index 2d4c83b..e781391 100644
> > --- a/arch/arm64/kernel/entry.S
> > +++ b/arch/arm64/kernel/entry.S
> > @@ -123,6 +123,7 @@
> > * Set sp_el0 to current thread_info.
> > */
> > .if \el == 0
> > + ldr_this_cpu tsk, __entry_task, x21
> > msr sp_el0, tsk
> > .endif
> >
> > @@ -674,8 +675,7 @@ ENTRY(cpu_switch_to)
> > ldp x29, x9, [x8], #16
> > ldr lr, [x8]
> > mov sp, x9
> > - and x9, x9, #~(THREAD_SIZE - 1)
> > - msr sp_el0, x9
> > + msr sp_el0, x1
> > ret
> > ENDPROC(cpu_switch_to)
> >
>
> So now tsk is current instead of current_thread_info(), but we still access it
> with TI_* offsets:
Yes; luckily thread_info is the first member of task_struct, so this
works (as offsetof(struct task_struct, thread_info) == 0). The core code
also relies on this, e.g. in <linux/thread_info.h>:
#ifdef CONFIG_THREAD_INFO_IN_TASK
#define current_thread_info() ((struct thread_info *)current)
#endif
... regardless, I should have commented that, mentioned it in the commit
message, and perhaps put a BUILD_BUG_ON()-style assert somewhere. I'll
need to double-check, but IIRC I can't update asm-offsets to base the
TI_* offsets on task_struct without introducing a potential circular
include dependency.
I could at least s/TI_/TSK_/, with a comment.
> The 're-entered irq stack' check is going to need re-thinking:
> entry.S:195
> > /*
> > * Compare sp with the current thread_info, if the top
> > * ~(THREAD_SIZE - 1) bits match, we are on a task stack, and
> > * should switch to the irq stack.
> > */
> > and x25, x19, #~(THREAD_SIZE - 1)
> > cmp x25, tsk
> > b.ne 9998f
>
> It was done like this as the irq stack isn't naturally aligned, so this check
> implicitly assumes tsk is on the stack. I will try and come up with an alternative.
Ouch; I clearly didn't vet this thoroughly enough.
If we can corrupt another register here, we can load task_struct::stack
to compare against instead.
> And there are a few other things like this:
> entry.S:431
> > ldr w24, [tsk, #TI_PREEMPT] // get preempt count
> > cbnz w24, 1f // preempt count != 0
> > ldr x0, [tsk, #TI_FLAGS] // get flags
> > tbz x0, #TIF_NEED_RESCHED, 1f // needs rescheduling?
> > bl el1_preempt
>
> (It may be worth renaming the register alias 'tsk' as it isn't really a
> struct_task. This would catch any missed users at build time, including
> any patches in flight...)
Entertainingly, with these patches 'tsk' *is* task_struct, whereas
before it wasn't.
> > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> > index 2679722..cde25f4 100644
> > --- a/arch/arm64/kernel/smp.c
> > +++ b/arch/arm64/kernel/smp.c
> > @@ -149,6 +149,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
> > * We need to tell the secondary core where to find its stack and the
> > * page tables.
> > */
> > + secondary_data.task = idle;
> > secondary_data.stack = task_stack_page(idle) + THREAD_START_SP;
> > update_cpu_boot_status(CPU_MMU_OFF);
> > __flush_dcache_area(&secondary_data, sizeof(secondary_data));
> > @@ -173,6 +174,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
> > pr_err("CPU%u: failed to boot: %d\n", cpu, ret);
> > }
> >
> > + secondary_data.task = NULL;
> > secondary_data.stack = NULL;
> > status = READ_ONCE(secondary_data.status);
> > if (ret && status) {
> >
>
> Nit-territory: Something we should remember is that __entry_task isn't written
> on secondary startup, so its stale (CPU0s idle task) until the first
> __switch_to(). This isn't a problem as its only read on entry from EL0.
Good point. I think I can initialise this in the hotplug path, if
nothing else but to save us any surprises when debugging.
Thanks,
Mark.
^ permalink raw reply
* [RFC PATCH 08/13] dwmac-meson8b: add support for phy selection
From: Neil Armstrong @ 2016-10-21 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021155408.GR16974@lunn.ch>
On 10/21/2016 05:54 PM, Andrew Lunn wrote:
> On Fri, Oct 21, 2016 at 04:40:33PM +0200, Neil Armstrong wrote:
>> The Meson GXL dwmac Glue Layer also provides switching between an external PHY
>> and an internal RMII 10/100 PHY.
>> Add a way to setup the correct PHY switching from a device tree attribute.
>
> Humm, actually. Maybe PHY_IS_INTERNAL in the phydrv->flags is the
> better solution. The MAC can then use phy_is_internal(ndev->phydev) to
> decide if this register needs programming.
>
> Andrew
>
Hi Andrew,
Yes this would be a good idea if we were able to scan the internal and external PHYs at the same time,
but with our limited knowledge the values we write in the register seems to switch a mux for the whole RMII
and MDIO signals to either interface.
Do you have knowledge if this case is already handled upstream ?
Thanks for your help,
Neil
^ permalink raw reply
* [PATCH] PCI: layerscape: Fix kernel panic on accessing NULL pointer
From: Leo Li @ 2016-10-21 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021153701.GC9007@localhost>
> -----Original Message-----
> From: Bjorn Helgaas [mailto:helgaas at kernel.org]
> Sent: Friday, October 21, 2016 10:37 AM
> To: Leo Li <leoyang.li@nxp.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>; Minghuan Lian
> <minghuan.Lian@freescale.com>; Mingkai Hu <mingkai.hu@freescale.com>;
> Roy Zang <tie-fei.zang@freescale.com>; linux-pci at vger.kernel.org; linux-
> kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; Stuart Yoder
> <stuart.yoder@nxp.com>
> Subject: Re: [PATCH] PCI: layerscape: Fix kernel panic on accessing NULL pointer
>
> On Mon, Oct 17, 2016 at 04:44:06PM -0500, Li Yang wrote:
> > Commit fefe6733e added reference to the pcie->drvdata before it is
> > initialized which causes a kernel panic. Fix the problem by
> > initializing the pcie->drvdata earlier before it is used.
> >
> > Reported-by: Stuart Yoder <stuart.yoder@nxp.com>
> > Signed-off-by: Li Yang <leoyang.li@nxp.com>
>
> I applied Marc Zyngier's identical patch to for-linus for v4.9. I don't know which
> was posted first, but I saw Marc's first. Sorry I didn't at least credit you when I
> applied it.
It's ok. Seems Marc sent the patch earlier and I didn't notice his patch. There is no difference as long as the problem is addressed. :)
Regards,
Leo
^ permalink raw reply
* [RFC PATCH 08/13] dwmac-meson8b: add support for phy selection
From: Andrew Lunn @ 2016-10-21 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dc810494-6ece-c4ae-d412-ed9af3fac9c2@baylibre.com>
Hi Neil
> Yes this would be a good idea if we were able to scan the internal
> and external PHYs at the same time, but with our limited knowledge
> the values we write in the register seems to switch a mux for the
> whole RMII and MDIO signals to either interface.
Ah, O.K. So you need something like:
drivers/net/phy/mdio-mux-mmioreg.c
This seems to be limited to a single byte for the mux register, so you
might need to make some extensions.
Andrew
^ permalink raw reply
* [PATCH V4 2/3] Revert "ACPI,PCI,IRQ: remove SCI penalize function"
From: Sinan Kaya @ 2016-10-21 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021144535.GB877@localhost>
On 10/21/2016 7:45 AM, Bjorn Helgaas wrote:
> [1] http://marc.info/?l=linux-acpi&m=145580159209240&w=2)
>
>> > Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> Wait a minute, I still have a question here: what about other ACPI
> arches (ia64, arm64)? Don't they need to call acpi_penalize_sci_irq()
> somewhere?
>
ACPI ARM64 architecture implements reduced ACPI profile which doesn't
have GED object. Instead, ARM64 architecture uses onchip peripherals
for similar functionality. If there is a need to signal interrupts,
this is done by ACPI Notify in ASL or if absolutely needed using
ACPI Generic Event Device (GED).
--
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
* [PATCH v3 0/2] Add MK808 RK3066 device
From: Heiko Stuebner @ 2016-10-21 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1475957884.git.paweljarosz3691@gmail.com>
Am Samstag, 8. Oktober 2016, 22:21:47 CEST schrieb Pawe? Jarosz:
> Add MK808 RK3066 device
>
> This patchset adds support for Rikomagic MK808 v1 device with RK901 wifi.
>
> It is hdmi stick with two usb ports(host and otg), sdmmc, wifi and uart
> onboard.
>
> It is RK3066 based.
>
> Pawe? Jarosz (2):
> devicetree: Add vendor prefix for Rikomagic
> ARM: dts: rockchip: Add rk3066 MK808 board
applied both patches with received tags for 4.10.
If you have time could try to do a followup patch, adding (and testing) the
usbphy supplies please?
Should be like
&usbphy0 {
phy-supply = <&vcc_otg>;
};
&usbphy1 {
phy-supply = <&vcc_host>;
};
That way we can drop the regulator-always-on property from those two supplies.
Thanks
Heiko
^ permalink raw reply
* [PATCH 10/10] arm64: split thread_info from task stack
From: Mark Rutland @ 2016-10-21 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <580A2B3A.7000300@arm.com>
On Fri, Oct 21, 2016 at 03:50:34PM +0100, James Morse wrote:
> Hi Mark,
>
> This looks great, we should definitely do this.
> There are a few things missing from entry.S below:
>
> On 19/10/16 20:10, Mark Rutland wrote:
> > This patch moves arm64's struct thread_info from the task stack into
> > task_struct. This protects thread_info from corruption in the case of
> > stack overflows, and makes its address harder to determine if stack
> > addresses are leaked, making a number of attacks more difficult. Precise
> > detection and handling of overflow is left for subsequent patches.
> >
> > Largely, this involves changing code to store the task_struct in sp_el0,
> > and acquire the thread_info from the task struct (which is the opposite
> > way around to the current code). Both secondary entry and idle are
> > updated to stash the sp and task pointer separately.
> >
> > Userspace clobbers sp_el0, and we can no longer restore this from the
> > stack. Instead, the current task is cached in a per-cpu variable that we
> > can safely access from early assembly as interrupts are disabled (and we
>
> > arch/arm64/Kconfig | 1 +
> > arch/arm64/include/asm/Kbuild | 1 -
> > arch/arm64/include/asm/current.h | 22 ++++++++++++++++++++++
> > arch/arm64/include/asm/smp.h | 1 +
> > arch/arm64/include/asm/thread_info.h | 24 ------------------------
> > arch/arm64/kernel/asm-offsets.c | 1 +
>
> > arch/arm64/kernel/entry.S | 4 ++--
>
> 4? That was too easy...
Far to easy; just looking at kernel_entry there' a glaring error:
.if \el == 0
mrs x21, sp_el0
mov tsk, sp
and tsk, tsk, #~(THREAD_SIZE - 1) // Ensure MDSCR_EL1.SS is clear,
ldr x19, [tsk, #TI_FLAGS] // since we can unmask debug
disable_step_tsk x19, x20 // exceptions when scheduling.
...it's amazing how broken a kernel will boot quite happily.
I've fixed that up locally.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 1/2] iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s
From: Robin Murphy @ 2016-10-21 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019124932.GP9193@arm.com>
On 19/10/16 13:49, Will Deacon wrote:
> On Mon, Oct 17, 2016 at 12:06:20PM +0100, Robin Murphy wrote:
>> We now delay installing our per-bus iommu_ops until we know an SMMU has
>> successfully probed, as they don't serve much purpose beforehand, and
>> doing so also avoids fights between multiple IOMMU drivers in a single
>> kernel. However, the upshot of passing the return value of bus_set_iommu()
>> back from our probe function is that if there happens to be more than
>> one SMMUv3 device in a system, the second and subsequent probes will
>> wind up returning -EBUSY to the driver core and getting torn down again.
>>
>> There are essentially 3 cases in which bus_set_iommu() returns nonzero:
>> 1. The bus already has iommu_ops installed
>> 2. One of the add_device callbacks from the initial notifier failed
>> 3. Allocating or installing the notifier itself failed
>>
>> The first two are down to devices other than the SMMU in question, so
>> shouldn't abort an otherwise-successful SMMU probe, whilst the third is
>> indicative of the kind of catastrophic system failure which isn't going
>> to get much further anyway. Consequently, there is little harm in
>> ignoring the return value either way.
>>
>> CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/iommu/arm-smmu-v3.c | 11 ++++-------
>> 1 file changed, 4 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
>> index 15c01c3cd540..74fbef384deb 100644
>> --- a/drivers/iommu/arm-smmu-v3.c
>> +++ b/drivers/iommu/arm-smmu-v3.c
>> @@ -2637,16 +2637,13 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
>> of_iommu_set_ops(dev->of_node, &arm_smmu_ops);
>> #ifdef CONFIG_PCI
>> pci_request_acs();
>> - ret = bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
>> - if (ret)
>> - return ret;
>> + bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
>> #endif
>> #ifdef CONFIG_ARM_AMBA
>> - ret = bus_set_iommu(&amba_bustype, &arm_smmu_ops);
>> - if (ret)
>> - return ret;
>> + bus_set_iommu(&amba_bustype, &arm_smmu_ops);
>> #endif
>> - return bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
>> + bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
>> + return 0;
>
> In which case, we should probably add an iommu_present check, like we
> have for the v2 driver.
As touched upon in the commit message, the first thing bus_set_iommu()
does is perform that same check and return immediately if any ops are
already set. Do you really want redundant checks added, or shall I spin
that cleanup patch removing them from v2 that I proposed to Lorenzo?
Robin.
>
> Will
>
^ permalink raw reply
* Disabling an interrupt in the handler locks the system up
From: Mason @ 2016-10-21 16:37 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
On my platform, one HW block pulls the interrupt line high
as long as it remains idle, and low when it is busy.
The device tree node is:
test at 22222 {
compatible = "vendor,testme";
interrupts = <23 IRQ_TYPE_LEVEL_HIGH>;
};
I wrote a minimal driver which registers the irq.
And in the interrupt handler, I disable said irq.
Since the irq is IRQ_TYPE_LEVEL_HIGH, it will fire as soon as
it is registered (because the block is idle).
Here is the code I've been running, request_irq doesn't return.
#include <linux/module.h>
#include <linux/of_irq.h>
#include <linux/interrupt.h>
#include <linux/platform_device.h>
static irqreturn_t test_isr(int irq, void *dev)
{
printk("irq=%d dev=%p\n", irq, dev);
disable_irq_nosync(irq);
printk("IRQ %d NOW DISABLED\n", irq);
return IRQ_HANDLED;
}
static int test_probe(struct platform_device *pdev)
{
unsigned res, virq;
printk("ENTER %s\n", __func__);
virq = irq_of_parse_and_map(pdev->dev.of_node, 0);
printk("virq = %u\n", virq);
res = request_irq(virq, test_isr, 0, "testme", (void *)0x42);
printk("request_irq = %d\n", res);
return 0;
}
static const struct of_device_id test_ids[] = {
{ .compatible = "vendor,testme" },
{ /* sentinel */ }
};
static struct platform_driver test_driver = {
.probe = test_probe,
.driver = {
.name = "test",
.of_match_table = test_ids,
},
};
module_platform_driver(test_driver);
MODULE_LICENSE("GPL");
And here's what I get when I try to load the module:
(I'm using the default CONFIG_RCU_CPU_STALL_TIMEOUT=21)
$ insmod test.ko
[ 91.571065] ENTER test_probe
[ 91.574208] virq = 21
[ 91.576902] irq=21 dev=00000042
[ 91.580061] IRQ 21 NOW DISABLED
[ 102.038544] nfs: server 172.27.64.1 not responding, still trying
[ 112.571855] INFO: rcu_preempt self-detected stall on CPU
[ 112.577201] 0-...: (6298 ticks this GP) idle=c45/140000000000002/0 softirq=1295/1295 fqs=2045
[ 112.585942] (t=6300 jiffies g=208 c=207 q=20)
[ 112.590497] Task dump for CPU 0:
[ 112.593735] insmod R running 0 951 929 0x00000002
[ 112.600124] Backtrace:
[ 112.602601] [<c010b9a4>] (dump_backtrace) from [<c010bba0>] (show_stack+0x18/0x1c)
[ 112.610207] r7:c0702434[ 112.612571] r6:c07024c8
r5:000003a1[ 112.616163] r4:df570dc0
[ 112.618701]
[ 112.620202] [<c010bb88>] (show_stack) from [<c0143a28>] (sched_show_task+0xbc/0x110)
[ 112.627989] [<c014396c>] (sched_show_task) from [<c0145ef0>] (dump_cpu_task+0x40/0x48)
[ 112.635943] r5:00000000[ 112.638307] r4:00000000
[ 112.640845]
[ 112.642347] [<c0145eb0>] (dump_cpu_task) from [<c01a8130>] (rcu_dump_cpu_stacks+0xb0/0xcc)
[ 112.650651] r5:00000000[ 112.653014] r4:c070a840
[ 112.655553]
[ 112.657055] [<c01a8080>] (rcu_dump_cpu_stacks) from [<c01743ec>] (rcu_check_callbacks+0x8f8/0x9b0)
[ 112.666058] r10:c07024c0[ 112.668509] r9:c0702518
r8:1f5a3000[ 112.672100] r7:c070a840
r6:c0702100[ 112.675691] r5:c0637f40
[ 112.678230] r4:dfbdaf40[ 112.680592] r3:ffff2458
[ 112.683130]
[ 112.684629] [<c0173af4>] (rcu_check_callbacks) from [<c0177b70>] (update_process_times+0x3c/0x64)
[ 112.693545] r10:c0188c54[ 112.695995] r9:00000001
r8:dfbd870c[ 112.699588] r7:0000001a
r6:00000000[ 112.703178] r5:df570dc0
[ 112.705717] r4:ffffe000[ 112.708080]
[ 112.709581] [<c0177b34>] (update_process_times) from [<c0188c50>] (tick_sched_handle+0x50/0x54)
[ 112.718322] r7:0000001a[ 112.720684] r6:35192494
r5:def2dab8[ 112.724274] r4:dfbd88f8
[ 112.726812]
[ 112.728309] [<c0188c00>] (tick_sched_handle) from [<c0188cb0>] (tick_sched_timer+0x5c/0xa0)
[ 112.736705] [<c0188c54>] (tick_sched_timer) from [<c0178bf4>] (__hrtimer_run_queues+0x11c/0x1ac)
[ 112.745533] r7:00000000[ 112.747896] r6:dfbd8700
r5:dfbd88f8[ 112.751486] r4:dfbd86c0
[ 112.754025]
[ 112.755519] [<c0178ad8>] (__hrtimer_run_queues) from [<c0178e88>] (hrtimer_interrupt+0xbc/0x20c)
[ 112.764347] r10:dfbd8738[ 112.766798] r9:dfbd8778
r8:dfbd8758[ 112.770389] r7:dfbd86d4
r6:ffffffff[ 112.773979] r5:00000003
[ 112.776518] r4:dfbd86c0[ 112.778881]
[ 112.780378] [<c0178dcc>] (hrtimer_interrupt) from [<c010ed0c>] (twd_handler+0x38/0x48)
[ 112.788332] r10:def2dab8[ 112.790782] r9:df402400
r8:00000001[ 112.794373] r7:df408700
r6:00000013[ 112.797964] r5:c0702744
[ 112.800504] r4:00000001[ 112.802866]
[ 112.804362] [<c010ecd4>] (twd_handler) from [<c016a134>] (handle_percpu_devid_irq+0x94/0x14c)
[ 112.812928] r5:c0702744[ 112.815291] r4:df405300
[ 112.817829]
[ 112.819327] [<c016a0a0>] (handle_percpu_devid_irq) from [<c0165134>] (generic_handle_irq+0x2c/0x3c)
[ 112.828417] r7:def2dbd0[ 112.830780] r6:00000013
r5:00000000[ 112.834370] r4:c0635ec4
[ 112.836909]
[ 112.838404] [<c0165108>] (generic_handle_irq) from [<c01656dc>] (__handle_domain_irq+0x84/0xf4)
[ 112.847150] [<c0165658>] (__handle_domain_irq) from [<c01014ac>] (gic_handle_irq+0x50/0x94)
[ 112.855541] r10:def2dbd0[ 112.857992] r9:e0803100
r8:e0802100[ 112.861583] r7:def2dab8
r6:e080210c[ 112.865173] r5:c0702744
[ 112.867712] r4:c070ff50[ 112.870076] r3:def2dab8
[ 112.872614]
[ 112.874107] [<c010145c>] (gic_handle_irq) from [<c010c70c>] (__irq_svc+0x6c/0xa8)
[ 112.881626] Exception stack(0xdef2dab8 to 0xdef2db00)
[ 112.886699] daa0: 00000000 c057c9b4
[ 112.894919] dac0: c07216c0 00000000 00000202 ffffe000 00000013 00000000 00000001 df402400
[ 112.903140] dae0: def2dbd0 def2db64 def2daf8 def2db08 c030db68 c0121068 20000113 ffffffff
[ 112.911356] r9:def2c000[ 112.913719] r8:00000001
r7:def2daec[ 112.917310] r6:ffffffff
r5:20000113[ 112.920901] r4:c0121068
[ 112.923448] [<c0120fc0>] (__do_softirq) from [<c0121520>] (irq_exit+0xd4/0x110)
[ 112.930792] r10:def2dbd0[ 112.933242] r9:df402400
r8:00000001[ 112.936833] r7:00000000
r6:00000013[ 112.940423] r5:00000000
[ 112.942962] r4:c0635ec4[ 112.945324]
[ 112.946819] [<c012144c>] (irq_exit) from [<c01656e0>] (__handle_domain_irq+0x88/0xf4)
[ 112.954690] [<c0165658>] (__handle_domain_irq) from [<c01014ac>] (gic_handle_irq+0x50/0x94)
[ 112.963080] r10:00000000[ 112.965531] r9:e0803100
r8:e0802100[ 112.969122] r7:def2dbd0
r6:e080210c[ 112.972714] r5:c0702744
[ 112.975253] r4:c070ff50[ 112.977617] r3:def2dbd0
[ 112.980154]
[ 112.981648] [<c010145c>] (gic_handle_irq) from [<c010c70c>] (__irq_svc+0x6c/0xa8)
[ 112.989166] Exception stack(0xdef2dbd0 to 0xdef2dc18)
[ 112.994240] dbc0: df506260 60000013 00000000 00000005
[ 113.002460] dbe0: dedbd680 df506200 00000015 df506260 60000013 df506238 00000000 def2dc2c
[ 113.010679] dc00: def2dc30 def2dc20 c0167f90 c04d68d0 60000013 ffffffff
[ 113.017324] r9:def2c000[ 113.019687] r8:60000013
r7:def2dc04[ 113.023277] r6:ffffffff
r5:60000013[ 113.026868] r4:c04d68d0
[ 113.029418] [<c04d68a8>] (_raw_spin_unlock_irqrestore) from [<c0167f90>] (__setup_irq+0x440/0x5f0)
[ 113.038426] [<c0167b50>] (__setup_irq) from [<c0168300>] (request_threaded_irq+0xf0/0x188)
[ 113.046730] r10:00000000[ 113.049179] r9:00000015
r8:df506210[ 113.052770] r7:00000000
r6:df506200[ 113.056362] r5:00000000
[ 113.058901] r4:dedbd680[ 113.061263]
[ 113.062767] [<c0168210>] (request_threaded_irq) from [<bf0040b8>] (test_probe+0x74/0x90 [zozo])
[ 113.071508] r10:00000000[ 113.073959] r9:21242a5c
r8:00000001[ 113.077550] r7:fffffdfb
r6:bf004320[ 113.081142] r5:df516810
[ 113.083681] r4:00000015[ 113.086044] r3:00000000
[ 113.088582]
[ 113.090085] [<bf004044>] (test_probe [zozo]) from [<c03595e8>] (platform_drv_probe+0x54/0xb8)
[ 113.098652] r4:c0752d30[ 113.101014]
[ 113.102510] [<c0359594>] (platform_drv_probe) from [<c0357b88>] (driver_probe_device+0x228/0x2b8)
[ 113.111425] r7:bf004320[ 113.113789] r6:df516844
r5:df516810[ 113.117379] r4:c0752d30
[ 113.119917]
[ 113.121412] [<c0357960>] (driver_probe_device) from [<c0357cd8>] (__driver_attach+0xc0/0xc4)
[ 113.129891] r9:21242a5c[ 113.132255] r8:00000001
r7:00000000[ 113.135845] r6:df516844
r5:bf004320[ 113.139436] r4:df516810
[ 113.141980] [<c0357c18>] (__driver_attach) from [<c0355d00>] (bus_for_each_dev+0x70/0xa4)
[ 113.150196] r7:00000000[ 113.152560] r6:c0357c18
r5:bf004320[ 113.156150] r4:00000000
[ 113.158689]
[ 113.160183] [<c0355c90>] (bus_for_each_dev) from [<c03573d4>] (driver_attach+0x24/0x28)
[ 113.168224] r6:c0714090[ 113.170587] r5:df7efc80
r4:bf004320[ 113.174178]
[ 113.175673] [<c03573b0>] (driver_attach) from [<c0356fa0>] (bus_add_driver+0x1a8/0x220)
[ 113.183719] [<c0356df8>] (bus_add_driver) from [<c0358498>] (driver_register+0x80/0x100)
[ 113.191848] r7:bf004380[ 113.194211] r6:dedbdc80
r5:bf006000[ 113.197801] r4:bf004320
[ 113.200339]
[ 113.201834] [<c0358418>] (driver_register) from [<c0359548>] (__platform_driver_register+0x48/0x50)
[ 113.210924] r5:bf006000[ 113.213287] r4:c0714090
[ 113.215826]
[ 113.217323] [<c0359500>] (__platform_driver_register) from [<bf006020>] (test_driver_init+0x20/0x24 [zozo])
[ 113.227113] r5:bf006000[ 113.229475] r4:ffffe000
[ 113.232014]
[ 113.233511] [<bf006000>] (test_driver_init [zozo]) from [<c01017f4>] (do_one_initcall+0x4c/0x17c)
[ 113.242432] [<c01017a8>] (do_one_initcall) from [<c01a81b4>] (do_init_module+0x68/0x3a4)
[ 113.250561] r10:dedbd5c8[ 113.253011] r9:21242a5c
r8:00000001[ 113.256602] r7:bf004380
r6:dedbdc80[ 113.260193] r5:00000001
[ 113.262732] r4:bf004380[ 113.265094]
[ 113.266591] [<c01a814c>] (do_init_module) from [<c01925f0>] (load_module+0x1dc0/0x2180)
[ 113.274633] r6:dedbd5c0[ 113.276997] r5:00000001
r4:def2df34[ 113.280587]
[ 113.282082] [<c0190830>] (load_module) from [<c0192b08>] (SyS_init_module+0x158/0x170)
[ 113.290037] r10:00000051[ 113.292487] r9:def2c000
r8:01bbf008[ 113.296078] r7:e08682cc
r6:00000000[ 113.299667] r5:01bc02e4
[ 113.302207] r4:000012cc[ 113.304569]
[ 113.306065] [<c01929b0>] (SyS_init_module) from [<c0107ba0>] (ret_fast_syscall+0x0/0x3c)
[ 113.314194] r10:00000000[ 113.316645] r9:def2c000
r8:c0107d64[ 113.320236] r7:00000080
r6:be98bb54[ 113.323828] r5:be98bc6d
[ 113.326368] r4:000012cc[ 113.328729]
Are we not supposed to disable the irq in the handler?
Regards.
^ permalink raw reply
* [PATCH V7 0/4] dmaengine: qcom_hidma: add MSI interrupt support
From: Sinan Kaya @ 2016-10-21 16:37 UTC (permalink / raw)
To: linux-arm-kernel
The new version of the HW supports MSI interrupts instead of wired
interrupts. The MSI interrupts are especially useful for the guest machine
execution. The wired interrupts usually trap to the hypervisor and then are
relayed to the actual interrupt.
The MSI interrupts can be directly fed into the interrupt controller.
Adding a new OF compat string (qcom,hidma-1.1) and ACPI string (QCOM8062)
to distinguish newer HW from the older ones.
v7:
* rebase on top of Vinod's topic/qcom
* drop first 6 patches as they are already applied
v6:
http://www.spinics.net/lists/devicetree/msg146700.html
* rebase 4.9 kernel
v5:
http://www.spinics.net/lists/arm-kernel/msg537014.html
* dmaengine: qcom_hidma: add MSI support for interrupts
** Return MSI interrupts before calling platform_msi_domain_free_irqs.
Also cleanup MSI interrupts on the error path.
** Free the legacy IRQ only if MSI is disabled
* add dmaengine: qcom_hidma: break completion processing on error
in order to break the completions if an error is observed while servicing
completed work.
* drop dmaengine: qcom_hidma: make error and success path common
as the success path assumes that we'll get the number of notifications for
the
jobs queued. This is not true under error conditions.
* simplify dmaengine: qcom_hidma: protect common data structures. We just
need to protect the TRE processed offset. It is the variable that keeps
track
of outstanding requests.
v4:
http://www.spinics.net/lists/devicetree/msg144563.html
* device tree binding update to refer to msi.txt
v3:
* day 0 fix for when ACPI is not compiled in
* https://www.spinics.net/lists/arm-kernel/msg532179.html
v2:
https://patchwork.kernel.org/patch/9326399/
* Documentation update for DT bindings
* Rebased to slave-next
* Dropped dmaengine: qcom_hidma: eliminate processed variables. Replaced it
with dmaengine: qcom_hidma: protect common data structures
v1:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/444167.html
* initial implementation
Sinan Kaya (4):
dmaengine: qcom_hidma: make pending_tre_count atomic
dmaengine: qcom_hidma: bring out interrupt cause
dmaengine: qcom_hidma: protect common data structures
dmaengine: qcom_hidma: add MSI support for interrupts
drivers/dma/qcom/hidma.c | 143 +++++++++++++++++++++++++++++++++++++++++--
drivers/dma/qcom/hidma.h | 4 +-
drivers/dma/qcom/hidma_dbg.c | 3 +-
drivers/dma/qcom/hidma_ll.c | 127 ++++++++++++++++++--------------------
4 files changed, 200 insertions(+), 77 deletions(-)
--
1.9.1
^ 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