* [PATCH 1/4] arm/arm64: smccc/psci: add arm_smccc_get_conduit()
From: Mark Rutland @ 2018-05-03 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503170330.5591-1-mark.rutland@arm.com>
SMCCC callers are currently amassing a collection of enums for the SMCCC
conduit, and are having to dig into the PSCI driver's internals in order
to figure out what to do.
Let's clean this up, with common SMCCC_CONDUIT_* definitions, and an
arm_smccc_get_conduit() helper that abstracts the PSCI driver's internal
state.
We can kill off the PSCI_CONDUIT_* definitions once we've migrated users
over to the nerw interface.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
drivers/firmware/psci.c | 15 +++++++++++++++
include/linux/arm-smccc.h | 16 ++++++++++++++++
2 files changed, 31 insertions(+)
diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index c80ec1d03274..310882185ca4 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -64,6 +64,21 @@ struct psci_operations psci_ops = {
.smccc_version = SMCCC_VERSION_1_0,
};
+enum arm_smccc_conduit arm_smccc_get_conduit(void)
+{
+ if (psci_ops.smccc_version < SMCCC_VERSION_1_1)
+ return SMCCC_CONDUIT_NONE;
+
+ switch (psci_ops.conduit) {
+ case PSCI_CONDUIT_SMC:
+ return SMCCC_CONDUIT_SMC;
+ case PSCI_CONDUIT_HVC:
+ return SMCCC_CONDUIT_HVC;
+ default:
+ return SMCCC_CONDUIT_NONE;
+ }
+}
+
typedef unsigned long (psci_fn)(unsigned long, unsigned long,
unsigned long, unsigned long);
static psci_fn *invoke_psci_fn;
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index a031897fca76..193e9d8a1ac2 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -84,6 +84,22 @@
#include <linux/linkage.h>
#include <linux/types.h>
+
+enum arm_smccc_conduit {
+ SMCCC_CONDUIT_NONE,
+ SMCCC_CONDUIT_SMC,
+ SMCCC_CONDUIT_HVC,
+};
+
+/**
+ * arm_smccc_get_conduit()
+ *
+ * Returns the conduit to be used for SMCCCv1.1 or later.
+ *
+ * When SMCCCv1.1 is not present, returns SMCCC_CONDUIT_NONE.
+ */
+enum arm_smccc_conduit arm_smccc_get_conduit(void);
+
/**
* struct arm_smccc_res - Result from SMC/HVC call
* @a0-a3 result values from registers 0 to 3
--
2.11.0
^ permalink raw reply related
* [PATCH 0/4] arm64: SMCCC conduit cleanup
From: Mark Rutland @ 2018-05-03 17:03 UTC (permalink / raw)
To: linux-arm-kernel
Currently, the cpu errata code goes digging into PSCI internals to
discover the SMCCC conduit, using the (arguably misnamed) PSCI_CONDUIT_*
definitions. This lack of abstraction is somewhat unfortunate.
Further, the SDEI code has an almost identical set of CONDUIT_*
definitions, and the duplication is rather unfortunate.
Let's unify things behind a common set of SMCCC_CONDUIT_* definitions,
and expose the SMCCCv1.1 conduit via a new helper that hides the PSCI
driver internals.
Mark.
Mark Rutland (4):
arm/arm64: smccc/psci: add arm_smccc_get_conduit()
arm64: errata: use arm_smccc_get_conduit()
firmware/psci: use common SMCCC_CONDUIT_*
firmware: arm_sdei: use common SMCCC_CONDUIT_*
arch/arm64/kernel/cpu_errata.c | 11 +++--------
arch/arm64/kernel/sdei.c | 3 ++-
drivers/firmware/arm_sdei.c | 12 ++++++------
drivers/firmware/psci.c | 24 ++++++++++++++++--------
include/linux/arm-smccc.h | 16 ++++++++++++++++
include/linux/arm_sdei.h | 6 ------
include/linux/psci.h | 9 ++-------
7 files changed, 45 insertions(+), 36 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH v2 03/27] coresight: Add helper device type
From: Mathieu Poirier @ 2018-05-03 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525165857-11096-4-git-send-email-suzuki.poulose@arm.com>
On Tue, May 01, 2018 at 10:10:33AM +0100, Suzuki K Poulose wrote:
> Add a new coresight device type, which do not belong to any
> of the existing types, i.e, source, sink, link etc. A helper
> device could be connected to a coresight device, which could
> augment the functionality of the coresight device.
>
> This is intended to cover Coresight Address Translation Unit (CATU)
> devices, which provide improved Scatter Gather mechanism for TMC
> ETR. The idea is that the helper device could be controlled by
> the driver of the device it is attached to (in this case ETR),
> transparent to the generic coresight driver (and paths).
>
> The operations include enable(), disable(), both of which could
> accept a device specific "data" which the driving device and
> the helper device could share. Since they don't appear in the
> coresight "path" tracked by software, we have to ensure that
> they are powered up/down whenever the master device is turned
> on.
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> drivers/hwtracing/coresight/coresight.c | 46 ++++++++++++++++++++++++++++++---
> include/linux/coresight.h | 24 +++++++++++++++++
> 2 files changed, 67 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
> index 389c4ba..fd0251e 100644
> --- a/drivers/hwtracing/coresight/coresight.c
> +++ b/drivers/hwtracing/coresight/coresight.c
> @@ -430,6 +430,43 @@ struct coresight_device *coresight_get_enabled_sink(bool deactivate)
> return dev ? to_coresight_device(dev) : NULL;
> }
>
> +/*
> + * coresight_prepare_device - Prepare this device and any of the helper
> + * devices connected to it for trace operation. Since the helper devices
> + * don't appear on the trace path, they should be handled along with the
> + * the master device.
> + */
> +static void coresight_prepare_device(struct coresight_device *csdev)
> +{
> + int i;
> +
> + for (i = 0; i < csdev->nr_outport; i++) {
> + struct coresight_device *child = csdev->conns[i].child_dev;
> +
> + if (child && child->type == CORESIGHT_DEV_TYPE_HELPER)
> + pm_runtime_get_sync(child->dev.parent);
> + }
> +
> + pm_runtime_get_sync(csdev->dev.parent);
> +}
> +
> +/*
> + * coresight_release_device - Release this device and any of the helper
> + * devices connected to it for trace operation.
> + */
> +static void coresight_release_device(struct coresight_device *csdev)
> +{
> + int i;
> +
> + for (i = 0; i < csdev->nr_outport; i++) {
> + struct coresight_device *child = csdev->conns[i].child_dev;
> +
> + if (child && child->type == CORESIGHT_DEV_TYPE_HELPER)
> + pm_runtime_put(child->dev.parent);
> + }
There is a newline here in coresight_prepare_device(). Either add one (or not)
in both function but please be consistent.
> + pm_runtime_put(csdev->dev.parent);
> +}
> +
> /**
> * _coresight_build_path - recursively build a path from a @csdev to a sink.
> * @csdev: The device to start from.
> @@ -480,8 +517,7 @@ static int _coresight_build_path(struct coresight_device *csdev,
>
> node->csdev = csdev;
> list_add(&node->link, path);
> - pm_runtime_get_sync(csdev->dev.parent);
> -
> + coresight_prepare_device(csdev);
There was a newline between pm_runtime_get_sync() and the return statement in
the original code.
> return 0;
> }
>
> @@ -524,7 +560,7 @@ void coresight_release_path(struct list_head *path)
> list_for_each_entry_safe(nd, next, path, link) {
> csdev = nd->csdev;
>
> - pm_runtime_put_sync(csdev->dev.parent);
> + coresight_release_device(csdev);
> list_del(&nd->link);
> kfree(nd);
> }
> @@ -775,6 +811,10 @@ static struct device_type coresight_dev_type[] = {
> .name = "source",
> .groups = coresight_source_groups,
> },
> + {
> + .name = "helper",
> + },
> +
Extra newline.
> };
>
> static void coresight_device_release(struct device *dev)
> diff --git a/include/linux/coresight.h b/include/linux/coresight.h
> index 556fe59..5e926f7 100644
> --- a/include/linux/coresight.h
> +++ b/include/linux/coresight.h
> @@ -47,6 +47,7 @@ enum coresight_dev_type {
> CORESIGHT_DEV_TYPE_LINK,
> CORESIGHT_DEV_TYPE_LINKSINK,
> CORESIGHT_DEV_TYPE_SOURCE,
> + CORESIGHT_DEV_TYPE_HELPER,
> };
>
> enum coresight_dev_subtype_sink {
> @@ -69,6 +70,10 @@ enum coresight_dev_subtype_source {
> CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE,
> };
>
> +enum coresight_dev_subtype_helper {
> + CORESIGHT_DEV_SUBTYPE_HELPER_NONE,
> +};
> +
> /**
> * union coresight_dev_subtype - further characterisation of a type
> * @sink_subtype: type of sink this component is, as defined
> @@ -77,6 +82,8 @@ enum coresight_dev_subtype_source {
> * by @coresight_dev_subtype_link.
> * @source_subtype: type of source this component is, as defined
> * by @coresight_dev_subtype_source.
> + * @helper_subtype: type of helper this component is, as defined
> + * by @coresight_dev_subtype_helper.
> */
> union coresight_dev_subtype {
> /* We have some devices which acts as LINK and SINK */
> @@ -85,6 +92,7 @@ union coresight_dev_subtype {
> enum coresight_dev_subtype_link link_subtype;
> };
> enum coresight_dev_subtype_source source_subtype;
> + enum coresight_dev_subtype_helper helper_subtype;
> };
>
> /**
> @@ -181,6 +189,7 @@ struct coresight_device {
> #define source_ops(csdev) csdev->ops->source_ops
> #define sink_ops(csdev) csdev->ops->sink_ops
> #define link_ops(csdev) csdev->ops->link_ops
> +#define helper_ops(csdev) csdev->ops->helper_ops
>
> /**
> * struct coresight_ops_sink - basic operations for a sink
> @@ -240,10 +249,25 @@ struct coresight_ops_source {
> struct perf_event *event);
> };
>
> +/**
> + * struct coresight_ops_helper - Operations for a helper device.
> + *
> + * All operations could pass in a device specific data, which could
> + * help the helper device to determine what to do.
> + *
> + * @enable : Turn the device ON.
> + * @disable : Turn the device OFF.
There is a discrepancy between the comment and the operations, i.e enabling a
device is not synonymous of turning it on. Looking at patch 04/27 the ops is
called in tmc_etr_enable/disable_catu() so the comment propably needs to be
changed.
> + */
> +struct coresight_ops_helper {
> + int (*enable)(struct coresight_device *csdev, void *data);
> + int (*disable)(struct coresight_device *csdev, void *data);
> +};
> +
> struct coresight_ops {
> const struct coresight_ops_sink *sink_ops;
> const struct coresight_ops_link *link_ops;
> const struct coresight_ops_source *source_ops;
> + const struct coresight_ops_helper *helper_ops;
> };
>
> #ifdef CONFIG_CORESIGHT
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 4/6] mm, arm64: untag user addresses in mm/gup.c
From: Andrey Konovalov @ 2018-05-03 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503152432.q742zvdbv6xtvo34@kshutemo-mobl1>
On Thu, May 3, 2018 at 5:24 PM, Kirill A. Shutemov <kirill@shutemov.name> wrote:
> On Thu, May 03, 2018 at 04:09:56PM +0200, Andrey Konovalov wrote:
>> On Wed, May 2, 2018 at 7:25 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> I wasn't able to find anything that calls follow_page with pointers
>> passed from userspace except for the memory subsystem syscalls, and we
>> deliberately don't add untagging in those.
>
> I guess I missed this part, but could you elaborate on this? Why?
> Not yet or not ever?
Check out the discussion here:
https://www.spinics.net/lists/arm-kernel/msg640936.html
>
> Also I wounder if we can find (with sparse?) all places where we cast out
> __user. This would give a nice list of places where to pay attention.
The way I tested this is I added BUG_ON(top byte tag is set) to
find_vma and find_extend_vma and ran a modified version of syzkaller
that embeds tags into pointers overnight. The only crashes that I saw
were coming from memory subsystem syscalls. I then temporarily added
untagging to suppress those crashes
(https://gist.github.com/xairy/3aa1f57798fa62522c8ac53fad9b74ca), and
didn't see any crashes after that.
^ permalink raw reply
* [PATCH 2/2] arm64: Clear the stack
From: Kees Cook @ 2018-05-03 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fc4f2832-4e8f-3e70-6ab0-9f077790eca0@linux.com>
On Thu, May 3, 2018 at 9:05 AM, Alexander Popov <alex.popov@linux.com> wrote:
> Hello Laura and Kees,
>
> On 03.05.2018 02:07, Laura Abbott wrote:
>> On 05/02/2018 02:31 PM, Kees Cook wrote:
>>> On Wed, May 2, 2018 at 1:33 PM, Laura Abbott <labbott@redhat.com> wrote:
>>>>
>>>> Implementation of stackleak based heavily on the x86 version
>>>
>>> Awesome! Notes below for both you and Alexander, since I think we can
>>> create a common code base instead of having near-duplicates in the
>>> arch/ trees...
>
> Yes, sure.
>
> I will extract the common part and send v12 for x86. Then Laura will be able to
> add arm64 support in a separate patch series. Is it fine?
Sure, though if you could fold the plugin fix from her, that would be
ideal. I'll likely carry both patch sets together once the arm64 one
stabilizes.
>> This was based on the earlier version of x86. I'll confess to
>> not seeing how the current x86 version ended up with get_stack_info
>> but I suspect it's either related to ORC unwinding or it's best
>> practice.
>
> I've changed that in v4. Quote from the changelog:
> - Fixed the surplus and erroneous code for calculating stack_left in
> check_alloca() on x86_64. That code repeats the work which is already
> done in get_stack_info() and it misses the fact that different
> exception stacks on x86_64 have different size.
>
> http://www.openwall.com/lists/kernel-hardening/2017/10/04/68
>
> We can see that in arch/x86/kernel/dumpstack_64.c.
>
> Is it fine if check_alloca() would be arch-specific?
I'm fine if check_alloca() remains arch-specific.
Thanks!
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* [PATCH v2] arm: exynos/s3c: dts: Remove leading 0x and 0s from bindings notation
From: Krzysztof Kozlowski @ 2018-05-03 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180502201153.7459-1-malat@debian.org>
On Wed, May 02, 2018 at 10:11:52PM +0200, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
... and dropped because apparently it does not work in all cases:
arch/arm/boot/dts/exynos5422-odroidhc1.dtb: Warning (unit_address_format): /firmware at 02073000: unit name should not have leading 0s
Can you check why these were not fixed?
Best regards,
Krzysztof
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]\+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0\+\(.*\) {/@0\1 {/g" {} +
>
> For simplicity, two sed expressions were used to solve each warnings separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This will solve as a side effect warning:
>
> Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>
> Reported-by: David Daney <ddaney@caviumnetworks.com>
> Suggested-by: Rob Herring <robh@kernel.org>
> Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> v2: intermediate patch contained unrelated changes. restrict to S3 and Exynos*
>
> arch/arm/boot/dts/exynos5420.dtsi | 36 ++++++++++++++++++------------------
> arch/arm/boot/dts/s3c2416.dtsi | 8 ++++----
> 2 files changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
> index 2f3cb2a97f71..633952a96427 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -761,7 +761,7 @@
> #include "exynos5420-tmu-sensor-conf.dtsi"
> };
>
> - sysmmu_g2dr: sysmmu at 0x10A60000 {
> + sysmmu_g2dr: sysmmu at 10a60000 {
> compatible = "samsung,exynos-sysmmu";
> reg = <0x10A60000 0x1000>;
> interrupt-parent = <&combiner>;
> @@ -771,7 +771,7 @@
> #iommu-cells = <0>;
> };
>
> - sysmmu_g2dw: sysmmu at 0x10A70000 {
> + sysmmu_g2dw: sysmmu at 10a70000 {
> compatible = "samsung,exynos-sysmmu";
> reg = <0x10A70000 0x1000>;
> interrupt-parent = <&combiner>;
> @@ -781,7 +781,7 @@
> #iommu-cells = <0>;
> };
>
> - sysmmu_tv: sysmmu at 0x14650000 {
> + sysmmu_tv: sysmmu at 14650000 {
> compatible = "samsung,exynos-sysmmu";
> reg = <0x14650000 0x1000>;
> interrupt-parent = <&combiner>;
> @@ -792,7 +792,7 @@
> #iommu-cells = <0>;
> };
>
> - sysmmu_gscl0: sysmmu at 0x13E80000 {
> + sysmmu_gscl0: sysmmu at 13e80000 {
> compatible = "samsung,exynos-sysmmu";
> reg = <0x13E80000 0x1000>;
> interrupt-parent = <&combiner>;
> @@ -803,7 +803,7 @@
> #iommu-cells = <0>;
> };
>
> - sysmmu_gscl1: sysmmu at 0x13E90000 {
> + sysmmu_gscl1: sysmmu at 13e90000 {
> compatible = "samsung,exynos-sysmmu";
> reg = <0x13E90000 0x1000>;
> interrupt-parent = <&combiner>;
> @@ -814,7 +814,7 @@
> #iommu-cells = <0>;
> };
>
> - sysmmu_scaler0r: sysmmu at 0x12880000 {
> + sysmmu_scaler0r: sysmmu at 12880000 {
> compatible = "samsung,exynos-sysmmu";
> reg = <0x12880000 0x1000>;
> interrupt-parent = <&combiner>;
> @@ -824,7 +824,7 @@
> #iommu-cells = <0>;
> };
>
> - sysmmu_scaler1r: sysmmu at 0x12890000 {
> + sysmmu_scaler1r: sysmmu at 12890000 {
> compatible = "samsung,exynos-sysmmu";
> reg = <0x12890000 0x1000>;
> interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
> @@ -833,7 +833,7 @@
> #iommu-cells = <0>;
> };
>
> - sysmmu_scaler2r: sysmmu at 0x128A0000 {
> + sysmmu_scaler2r: sysmmu at 128a0000 {
> compatible = "samsung,exynos-sysmmu";
> reg = <0x128A0000 0x1000>;
> interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
> @@ -842,7 +842,7 @@
> #iommu-cells = <0>;
> };
>
> - sysmmu_scaler0w: sysmmu at 0x128C0000 {
> + sysmmu_scaler0w: sysmmu at 128c0000 {
> compatible = "samsung,exynos-sysmmu";
> reg = <0x128C0000 0x1000>;
> interrupt-parent = <&combiner>;
> @@ -852,7 +852,7 @@
> #iommu-cells = <0>;
> };
>
> - sysmmu_scaler1w: sysmmu at 0x128D0000 {
> + sysmmu_scaler1w: sysmmu at 128d0000 {
> compatible = "samsung,exynos-sysmmu";
> reg = <0x128D0000 0x1000>;
> interrupt-parent = <&combiner>;
> @@ -862,7 +862,7 @@
> #iommu-cells = <0>;
> };
>
> - sysmmu_scaler2w: sysmmu at 0x128E0000 {
> + sysmmu_scaler2w: sysmmu at 128e0000 {
> compatible = "samsung,exynos-sysmmu";
> reg = <0x128E0000 0x1000>;
> interrupt-parent = <&combiner>;
> @@ -872,7 +872,7 @@
> #iommu-cells = <0>;
> };
>
> - sysmmu_rotator: sysmmu at 0x11D40000 {
> + sysmmu_rotator: sysmmu at 11d40000 {
> compatible = "samsung,exynos-sysmmu";
> reg = <0x11D40000 0x1000>;
> interrupt-parent = <&combiner>;
> @@ -882,7 +882,7 @@
> #iommu-cells = <0>;
> };
>
> - sysmmu_jpeg0: sysmmu at 0x11F10000 {
> + sysmmu_jpeg0: sysmmu at 11f10000 {
> compatible = "samsung,exynos-sysmmu";
> reg = <0x11F10000 0x1000>;
> interrupt-parent = <&combiner>;
> @@ -892,7 +892,7 @@
> #iommu-cells = <0>;
> };
>
> - sysmmu_jpeg1: sysmmu at 0x11F20000 {
> + sysmmu_jpeg1: sysmmu at 11f20000 {
> compatible = "samsung,exynos-sysmmu";
> reg = <0x11F20000 0x1000>;
> interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
> @@ -901,7 +901,7 @@
> #iommu-cells = <0>;
> };
>
> - sysmmu_mfc_l: sysmmu at 0x11200000 {
> + sysmmu_mfc_l: sysmmu at 11200000 {
> compatible = "samsung,exynos-sysmmu";
> reg = <0x11200000 0x1000>;
> interrupt-parent = <&combiner>;
> @@ -912,7 +912,7 @@
> #iommu-cells = <0>;
> };
>
> - sysmmu_mfc_r: sysmmu at 0x11210000 {
> + sysmmu_mfc_r: sysmmu at 11210000 {
> compatible = "samsung,exynos-sysmmu";
> reg = <0x11210000 0x1000>;
> interrupt-parent = <&combiner>;
> @@ -923,7 +923,7 @@
> #iommu-cells = <0>;
> };
>
> - sysmmu_fimd1_0: sysmmu at 0x14640000 {
> + sysmmu_fimd1_0: sysmmu at 14640000 {
> compatible = "samsung,exynos-sysmmu";
> reg = <0x14640000 0x1000>;
> interrupt-parent = <&combiner>;
> @@ -934,7 +934,7 @@
> #iommu-cells = <0>;
> };
>
> - sysmmu_fimd1_1: sysmmu at 0x14680000 {
> + sysmmu_fimd1_1: sysmmu at 14680000 {
> compatible = "samsung,exynos-sysmmu";
> reg = <0x14680000 0x1000>;
> interrupt-parent = <&combiner>;
> diff --git a/arch/arm/boot/dts/s3c2416.dtsi b/arch/arm/boot/dts/s3c2416.dtsi
> index 3c7385cab248..46cf85f3c18b 100644
> --- a/arch/arm/boot/dts/s3c2416.dtsi
> +++ b/arch/arm/boot/dts/s3c2416.dtsi
> @@ -30,7 +30,7 @@
> compatible = "samsung,s3c2416-irq";
> };
>
> - clocks: clock-controller at 0x4c000000 {
> + clocks: clock-controller at 4c000000 {
> compatible = "samsung,s3c2416-clock";
> reg = <0x4c000000 0x40>;
> #clock-cells = <1>;
> @@ -69,7 +69,7 @@
> <&clocks SCLK_UART>;
> };
>
> - uart_3: serial at 5000C000 {
> + uart_3: serial at 5000c000 {
> compatible = "samsung,s3c2440-uart";
> reg = <0x5000C000 0x4000>;
> interrupts = <1 18 24 4>, <1 18 25 4>;
> @@ -80,7 +80,7 @@
> status = "disabled";
> };
>
> - sdhci_1: sdhci at 4AC00000 {
> + sdhci_1: sdhci at 4ac00000 {
> compatible = "samsung,s3c6410-sdhci";
> reg = <0x4AC00000 0x100>;
> interrupts = <0 0 21 3>;
> @@ -91,7 +91,7 @@
> status = "disabled";
> };
>
> - sdhci_0: sdhci at 4A800000 {
> + sdhci_0: sdhci at 4a800000 {
> compatible = "samsung,s3c6410-sdhci";
> reg = <0x4A800000 0x100>;
> interrupts = <0 0 20 3>;
> --
> 2.11.0
>
^ permalink raw reply
* [PATCH v2] arm: exynos/s3c: dts: Remove leading 0x and 0s from bindings notation
From: Krzysztof Kozlowski @ 2018-05-03 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180502201153.7459-1-malat@debian.org>
On Wed, May 02, 2018 at 10:11:52PM +0200, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]\+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0\+\(.*\) {/@0\1 {/g" {} +
>
> For simplicity, two sed expressions were used to solve each warnings separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This will solve as a side effect warning:
>
> Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>
> Reported-by: David Daney <ddaney@caviumnetworks.com>
> Suggested-by: Rob Herring <robh@kernel.org>
> Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> v2: intermediate patch contained unrelated changes. restrict to S3 and Exynos*
>
> arch/arm/boot/dts/exynos5420.dtsi | 36 ++++++++++++++++++------------------
> arch/arm/boot/dts/s3c2416.dtsi | 8 ++++----
> 2 files changed, 22 insertions(+), 22 deletions(-)
>
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] ARM: EXYNOS: no need to select ARCH_HAS_BANDGAP any longer
From: Krzysztof Kozlowski @ 2018-05-03 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9721484.FBO9LEPOs5@amdc3058>
On Wed, May 02, 2018 at 04:30:26PM +0200, Bartlomiej Zolnierkiewicz wrote:
> This is not needed since commit fcbb1e02ee54 ("drivers: thermal:
> Remove ARCH_HAS_BANDGAP dependency for samsung") from 2014.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> ---
> arch/arm/mach-exynos/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 1/2] ARM: dts: am335x: Replace numeric pinmux address with macro defines
From: Tony Lindgren @ 2018-05-03 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <234521ee-3d8e-b413-65dd-5eefd44486d8@ti.com>
* Grygorii Strashko <grygorii.strashko@ti.com> [180503 15:54]:
>
>
> On 04/30/2018 12:31 PM, Tony Lindgren wrote:
> > Hi,
> >
> > * Christina Quast <cquast@baylibre.com> [180430 11:23]:
> >> The values are extraced from the "AM335x SitaraTM Processors Technical
> >> Reference Manual", Section 9.3.1 CONTROL_MODULE Registers, based on the
> >> file autogenerated by TI PinMux.
> >
> > This certainly makes things easier to mux :)
> >
> > Have you verified that the registers are the same across all am335x
> > models and different revisions?
> >
> > It used to be that different SoC revisions could have different
> > amount of registers and also different options in some cases.
> >
> >> +#define AM335X_CONTROL_REVISION 0x0
> >> +#define AM335X_CONTROL_HWINFO 0x4
> >> +#define AM335X_CONTROL_SYSCONFIG 0x10
> >> +#define AM335X_CONTROL_STATUS 0x40
> >
> > You should only list the padconf mux registers here, no need to
> > list any of the controller registers.
> >
>
> To be honest, I do think it's right thing to do - DT by itself is
> documentation and previously DT maintainers were not very happy regarding
> introducing more defines instead of const.
Sounds like you mean "I don't think" above instead of "I do think"?
Care to clarify..
> Adding such defines will introduce big headers in Linux common or
> platform folders again which we've just got rid of.
>
> If smth is unclear - comments can be used in DT.
>
> Just my 5c.
The problem earlier was that we had just too many variants as
the padconf registers got changed even between SoC revisions.
Not always and not for many registers but still. The padconf
register range seems to stay the same for a SoC though.
I do see value at being able to mux the registers easier though.
Regards,
Tony
^ permalink raw reply
* [PATCH 2/2] arm64: Clear the stack
From: Alexander Popov @ 2018-05-03 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4b7e94c1-79c9-0380-25c6-762762ed595f@redhat.com>
Hello Laura and Kees,
On 03.05.2018 02:07, Laura Abbott wrote:
> On 05/02/2018 02:31 PM, Kees Cook wrote:
>> On Wed, May 2, 2018 at 1:33 PM, Laura Abbott <labbott@redhat.com> wrote:
>>>
>>> Implementation of stackleak based heavily on the x86 version
>>
>> Awesome! Notes below for both you and Alexander, since I think we can
>> create a common code base instead of having near-duplicates in the
>> arch/ trees...
Yes, sure.
I will extract the common part and send v12 for x86. Then Laura will be able to
add arm64 support in a separate patch series. Is it fine?
>>> Signed-off-by: Laura Abbott <labbott@redhat.com>
>>> ---
>>> Now written in C instead of a bunch of assembly.
>>> ---
>>> arch/arm64/Kconfig | 1 +
>>> arch/arm64/include/asm/processor.h | 6 ++++
>>> arch/arm64/kernel/Makefile | 3 ++
>>> arch/arm64/kernel/entry.S | 6 ++++
>>> arch/arm64/kernel/erase.c | 55 +++++++++++++++++++++++++++++++++++
>>> arch/arm64/kernel/process.c | 16 ++++++++++
>>> drivers/firmware/efi/libstub/Makefile | 3 +-
>>> scripts/Makefile.gcc-plugins | 5 +++-
>>> 8 files changed, 93 insertions(+), 2 deletions(-)
>>> create mode 100644 arch/arm64/kernel/erase.c
>>>
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index eb2cf4938f6d..b0221db95dc9 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -92,6 +92,7 @@ config ARM64
>>> select HAVE_ARCH_MMAP_RND_BITS
>>> select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
>>> select HAVE_ARCH_SECCOMP_FILTER
>>> + select HAVE_ARCH_STACKLEAK
>>> select HAVE_ARCH_THREAD_STRUCT_WHITELIST
>>> select HAVE_ARCH_TRACEHOOK
>>> select HAVE_ARCH_TRANSPARENT_HUGEPAGE
>>> diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
>>> index 767598932549..d31ab80ff647 100644
>>> --- a/arch/arm64/include/asm/processor.h
>>> +++ b/arch/arm64/include/asm/processor.h
>>> @@ -124,6 +124,12 @@ struct thread_struct {
>>> unsigned long fault_address; /* fault info */
>>> unsigned long fault_code; /* ESR_EL1 value */
>>> struct debug_info debug; /* debugging */
>>> +#ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>>> + unsigned long lowest_stack;
>>> +#ifdef CONFIG_STACKLEAK_METRICS
>>> + unsigned long prev_lowest_stack;
>>> +#endif
>>> +#endif
>>
>> I wonder if x86 and arm64 could include a common struct here that was
>> empty when the plugin is disabled... it would keep the ifdefs in one
>> place. Maybe include/linux/stackleak.h could be:
>>
>> ---start---
>> /* Poison value points to the unused hole in the virtual memory map */
>> #define STACKLEAK_POISON -0xBEEF
>> #define STACKLEAK_POISON_CHECK_DEPTH 128
>>
>> struct stackleak {
>> #ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>> unsigned long lowest;
>> #ifdef CONFIG_STACKLEAK_METRICS
>> unsigned long prev_lowest;
>> #endif
>> #endif
>> };
>>
>
> Is this well defined across all compilers if the plugin is off?
> This seems to compile with gcc at least but 0 sized structs
> make me a little uneasy.
Empty struct is not defined by C standard but is permitted by gcc
https://gcc.gnu.org/onlinedocs/gcc/Empty-Structures.html#Empty-Structures
Fast example:
#include <stdio.h>
int main(void)
{
struct a {};
printf("size %zu\n", sizeof(struct a));
return 0;
}
# gcc -pedantic t.c -o t
t.c: In function ?main?:
t.c:5:9: warning: struct has no members [-Wpedantic]
struct a {};
^
# clang -Weverything t.c -o tc
t.c:5:2: warning: empty struct has size 0 in C, size 1 in C++ [-Wc++-compat]
struct a {};
^
t.c:5:2: warning: empty struct is a GNU extension [-Wgnu-empty-struct]
2 warnings generated.
But both programs print "size 0". There are a lot of empty structs around the
kernel, so I'll create another one.
>> asmlinkage void erase_kstack(void);
>> ---eof---
>>
>> and arch/*/include/asm/processor.h could do:
>>
>> @@ -124,6 +124,12 @@ struct thread_struct {
>> unsigned long fault_address; /* fault info */
>> unsigned long fault_code; /* ESR_EL1 value */
>> struct debug_info debug; /* debugging */
>> + struct stackleak stackleak;
>>
>> and arch/x86/entry/erase.c could move to maybe kernel/stackleak.c?
>> (Oh, I notice this needs an SPDX line too.)
Thanks, I'll add it.
>>> static inline void arch_thread_struct_whitelist(unsigned long *offset,
>>> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
>>> index bf825f38d206..0ceea613c65b 100644
>>> --- a/arch/arm64/kernel/Makefile
>>> +++ b/arch/arm64/kernel/Makefile
>>> @@ -55,6 +55,9 @@ arm64-reloc-test-y := reloc_test_core.o reloc_test_syms.o
>>> arm64-obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
>>> arm64-obj-$(CONFIG_ARM_SDE_INTERFACE) += sdei.o
>>>
>>> +arm64-obj-$(CONFIG_GCC_PLUGIN_STACKLEAK) += erase.o
>>> +KASAN_SANITIZE_erase.o := n
>>> +
>>> obj-y += $(arm64-obj-y) vdso/ probes/
>>> obj-m += $(arm64-obj-m)
>>> head-y := head.o
>>> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
>>> index ec2ee720e33e..3144f1ebdc18 100644
>>> --- a/arch/arm64/kernel/entry.S
>>> +++ b/arch/arm64/kernel/entry.S
>>> @@ -401,6 +401,11 @@ tsk .req x28 // current thread_info
>>>
>>> .text
>>>
>>> + .macro ERASE_KSTACK
>>> +#ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>>> + bl erase_kstack
>>> +#endif
>>> + .endm
>>> /*
>>> * Exception vectors.
>>> */
>>> @@ -906,6 +911,7 @@ ret_to_user:
>>> cbnz x2, work_pending
>>> finish_ret_to_user:
>>> enable_step_tsk x1, x2
>>> + ERASE_KSTACK
>>> kernel_exit 0
>>> ENDPROC(ret_to_user)
>>
>> Nice. All of the return paths end up here (I went looking for
>> ret_from_fork's path). :)
>>
>>>
>>> diff --git a/arch/arm64/kernel/erase.c b/arch/arm64/kernel/erase.c
>>> new file mode 100644
>>> index 000000000000..b8b5648d893b
>>> --- /dev/null
>>> +++ b/arch/arm64/kernel/erase.c
>>> @@ -0,0 +1,55 @@
>>> +#include <linux/bug.h>
>>> +#include <linux/sched.h>
>>> +#include <asm/current.h>
>>> +#include <asm/linkage.h>
>>> +#include <asm/processor.h>
>>> +
>>> +asmlinkage void erase_kstack(void)
>>> +{
>>> + unsigned long p = current->thread.lowest_stack;
>>> + unsigned long boundary = p & ~(THREAD_SIZE - 1);
>>> + unsigned long poison = 0;
>>> + const unsigned long check_depth = STACKLEAK_POISON_CHECK_DEPTH /
>>> + sizeof(unsigned long);
>>> +
>>> + /*
>>> + * Let's search for the poison value in the stack.
>>> + * Start from the lowest_stack and go to the bottom.
>>> + */
>>> + while (p > boundary && poison <= check_depth) {
>>> + if (*(unsigned long *)p == STACKLEAK_POISON)
>>> + poison++;
>>> + else
>>> + poison = 0;
>>> +
>>> + p -= sizeof(unsigned long);
>>> + }
>>> +
>>> + /*
>>> + * One long int at the bottom of the thread stack is reserved and
>>> + * should not be poisoned (see CONFIG_SCHED_STACK_END_CHECK).
>>> + */
>>> + if (p == boundary)
>>> + p += sizeof(unsigned long);
>>> +
>>> +#ifdef CONFIG_STACKLEAK_METRICS
>>> + current->thread.prev_lowest_stack = p;
>>> +#endif
>>> +
>>> + /*
>>> + * So let's write the poison value to the kernel stack.
>>> + * Start from the address in p and move up till the new boundary.
>>> + */
>>> + boundary = current_stack_pointer;
>>
>> This is the only difference between x86 and arm64 in this code. What
>> do you think about implementing on_thread_stack() to match x86:
>>
>> if (on_thread_stack())
>> boundary = current_stack_pointer;
>> else
>> boundary = current_top_of_stack();
>>
>> then we could make this common code too instead of having two copies in arch/?
>>
>
> The issue isn't on_thread_stack, it's current_top_of_stack which isn't
> defined on arm64. I agree it would be good if the code would be common
> but I'm not sure how much we want to start trying to force APIs.
>
>>> + BUG_ON(boundary - p >= THREAD_SIZE);
>>> +
>>> + while (p < boundary) {
>>> + *(unsigned long *)p = STACKLEAK_POISON;
>>> + p += sizeof(unsigned long);
>>> + }
>>> +
>>> + /* Reset the lowest_stack value for the next syscall */
>>> + current->thread.lowest_stack = current_stack_pointer;
>>> +}
>>> +
>>> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
>>> index f08a2ed9db0d..156fa0a0da19 100644
>>> --- a/arch/arm64/kernel/process.c
>>> +++ b/arch/arm64/kernel/process.c
>>> @@ -364,6 +364,9 @@ int copy_thread(unsigned long clone_flags, unsigned long stack_start,
>>> p->thread.cpu_context.pc = (unsigned long)ret_from_fork;
>>> p->thread.cpu_context.sp = (unsigned long)childregs;
>>>
>>> +#ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>>> + p->thread.lowest_stack = (unsigned long)task_stack_page(p);
>>> +#endif
I think it should be (unsigned long)task_stack_page(p) + sizeof(unsigned long).
>>> ptrace_hw_copy_thread(p);
>>>
>>> return 0;
>>> @@ -493,3 +496,16 @@ void arch_setup_new_exec(void)
>>> {
>>> current->mm->context.flags = is_compat_task() ? MMCF_AARCH32 : 0;
>>> }
>>> +
>>> +#ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>>> +void __used check_alloca(unsigned long size)
>>> +{
>>> + unsigned long sp, stack_left;
>>> +
>>> + sp = current_stack_pointer;
>>> +
>>> + stack_left = sp & (THREAD_SIZE - 1);
>>> + BUG_ON(stack_left < 256 || size >= stack_left - 256);
>>> +}
>>> +EXPORT_SYMBOL(check_alloca);
>>
>> This is pretty different from x86. Is this just an artifact of ORC, or
>> something else?
>>
>
> This was based on the earlier version of x86. I'll confess to
> not seeing how the current x86 version ended up with get_stack_info
> but I suspect it's either related to ORC unwinding or it's best
> practice.
I've changed that in v4. Quote from the changelog:
- Fixed the surplus and erroneous code for calculating stack_left in
check_alloca() on x86_64. That code repeats the work which is already
done in get_stack_info() and it misses the fact that different
exception stacks on x86_64 have different size.
http://www.openwall.com/lists/kernel-hardening/2017/10/04/68
We can see that in arch/x86/kernel/dumpstack_64.c.
Is it fine if check_alloca() would be arch-specific?
>>> +#endif
>>> diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
>>> index a34e9290a699..25dd2a14560d 100644
>>> --- a/drivers/firmware/efi/libstub/Makefile
>>> +++ b/drivers/firmware/efi/libstub/Makefile
>>> @@ -20,7 +20,8 @@ cflags-$(CONFIG_EFI_ARMSTUB) += -I$(srctree)/scripts/dtc/libfdt
>>> KBUILD_CFLAGS := $(cflags-y) -DDISABLE_BRANCH_PROFILING \
>>> -D__NO_FORTIFY \
>>> $(call cc-option,-ffreestanding) \
>>> - $(call cc-option,-fno-stack-protector)
>>> + $(call cc-option,-fno-stack-protector) \
>>> + $(DISABLE_STACKLEAK_PLUGIN)
>>>
>>> GCOV_PROFILE := n
>>> KASAN_SANITIZE := n
>>> diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
>>> index 8d6070fc538f..6cc0e35d3324 100644
>>> --- a/scripts/Makefile.gcc-plugins
>>> +++ b/scripts/Makefile.gcc-plugins
>>> @@ -37,11 +37,14 @@ ifdef CONFIG_GCC_PLUGINS
>>>
>>> gcc-plugin-$(CONFIG_GCC_PLUGIN_STACKLEAK) += stackleak_plugin.so
>>> gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STACKLEAK) += -DSTACKLEAK_PLUGIN -fplugin-arg-stackleak_plugin-track-min-size=$(CONFIG_STACKLEAK_TRACK_MIN_SIZE)
>>> + ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>>> + DISABLE_STACKLEAK_PLUGIN += -fplugin-arg-stackleak_plugin-disable
>>> + endif
>>>
>>> GCC_PLUGINS_CFLAGS := $(strip $(addprefix -fplugin=$(objtree)/scripts/gcc-plugins/, $(gcc-plugin-y)) $(gcc-plugin-cflags-y))
>>>
>>> export PLUGINCC GCC_PLUGINS_CFLAGS GCC_PLUGIN GCC_PLUGIN_SUBDIR
>>> - export SANCOV_PLUGIN DISABLE_LATENT_ENTROPY_PLUGIN
>>> + export SANCOV_PLUGIN DISABLE_LATENT_ENTROPY_PLUGIN DISABLE_STACKLEAK_PLUGIN
>>>
>>> ifneq ($(PLUGINCC),)
>>> # SANCOV_PLUGIN can be only in CFLAGS_KCOV because avoid duplication.
>>> --
>>> 2.14.3
>>>
Best regards,
Alexander
^ permalink raw reply
* [PATCH 1/2] ARM: dts: am335x: Replace numeric pinmux address with macro defines
From: Grygorii Strashko @ 2018-05-03 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180430173146.GG5671@atomide.com>
On 04/30/2018 12:31 PM, Tony Lindgren wrote:
> Hi,
>
> * Christina Quast <cquast@baylibre.com> [180430 11:23]:
>> The values are extraced from the "AM335x SitaraTM Processors Technical
>> Reference Manual", Section 9.3.1 CONTROL_MODULE Registers, based on the
>> file autogenerated by TI PinMux.
>
> This certainly makes things easier to mux :)
>
> Have you verified that the registers are the same across all am335x
> models and different revisions?
>
> It used to be that different SoC revisions could have different
> amount of registers and also different options in some cases.
>
>> +#define AM335X_CONTROL_REVISION 0x0
>> +#define AM335X_CONTROL_HWINFO 0x4
>> +#define AM335X_CONTROL_SYSCONFIG 0x10
>> +#define AM335X_CONTROL_STATUS 0x40
>
> You should only list the padconf mux registers here, no need to
> list any of the controller registers.
>
To be honest, I do think it's right thing to do - DT by itself is
documentation and previously DT maintainers were not very happy regarding
introducing more defines instead of const.
Adding such defines will introduce big headers in Linux common or
platform folders again which we've just got rid of.
If smth is unclear - comments can be used in DT.
Just my 5c.
--
regards,
-grygorii
^ permalink raw reply
* [PATCH v9 07/27] ARM: davinci: dm355: add new clock init using common clock framework
From: David Lechner @ 2018-05-03 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d9633747-0c50-2934-d3b2-ba745f021077@ti.com>
On 05/03/2018 10:34 AM, Sekhar Nori wrote:
> On Friday 27 April 2018 05:47 AM, David Lechner wrote:
>> This adds the new board-specific clock init in mach-davinci/dm355.c
>> using the new common clock framework drivers.
>>
>> The #ifdefs are needed to prevent compile errors until the entire
>> ARCH_DAVINCI is converted.
>>
>> Also clean up the #includes since we are adding some here.
>>
>> Signed-off-by: David Lechner <david@lechnology.com>
>
> I am having trouble booting DM355 EVM with the series applied.
> Still to debug what is going wrong.
Can you dump the PLL registers using /sys/kernel/debug/clk/... ?
^ permalink raw reply
* [PATCH v1 0/2] Add I2C support for STM32H743
From: Alexandre Torgue @ 2018-05-03 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1524215122-14046-1-git-send-email-pierre-yves.mordret@st.com>
Hi,
On 04/20/2018 11:05 AM, Pierre-Yves MORDRET wrote:
> Add I2C support on STM32H743 SoC.
> Activate I2C1 on STM32H743I Evaluation Board.
> ---
> Version history:
> v1:
> * Initial
> ---
>
> Pierre-Yves MORDRET (2):
> ARM: dts: stm32: Add I2C support for STM32H743 SoC
> ARM: dts: stm32: Add I2C1 support for STM32H743I-EVAL Board
>
> arch/arm/boot/dts/stm32h743-pinctrl.dtsi | 10 +++++++
> arch/arm/boot/dts/stm32h743.dtsi | 48 ++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/stm32h743i-eval.dts | 8 ++++++
> 3 files changed, 66 insertions(+)
>
Series applied on stm32-next.
Regards
Alex
^ permalink raw reply
* [RESEND PATCH 3/3] ARM: dts: stm32: update pwm-cells for LPTimer on stm32h743
From: Alexandre Torgue @ 2018-05-03 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1519392965-28235-4-git-send-email-fabrice.gasnier@st.com>
Hi Fabrice
On 02/23/2018 02:36 PM, Fabrice Gasnier wrote:
> LPTimer pwm cells should be updated to 3, to allow initialization of
> channel, period and polarity.
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> ---
Applied on stm32-next.
Thanks.
Alex
> arch/arm/boot/dts/stm32h743.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32h743.dtsi b/arch/arm/boot/dts/stm32h743.dtsi
> index bbfcbac..40d7d76 100644
> --- a/arch/arm/boot/dts/stm32h743.dtsi
> +++ b/arch/arm/boot/dts/stm32h743.dtsi
> @@ -85,6 +85,7 @@
>
> pwm {
> compatible = "st,stm32-pwm-lp";
> + #pwm-cells = <3>;
> status = "disabled";
> };
>
> @@ -238,6 +239,7 @@
>
> pwm {
> compatible = "st,stm32-pwm-lp";
> + #pwm-cells = <3>;
> status = "disabled";
> };
>
> @@ -264,6 +266,7 @@
>
> pwm {
> compatible = "st,stm32-pwm-lp";
> + #pwm-cells = <3>;
> status = "disabled";
> };
>
> @@ -285,6 +288,7 @@
>
> pwm {
> compatible = "st,stm32-pwm-lp";
> + #pwm-cells = <3>;
> status = "disabled";
> };
> };
> @@ -300,6 +304,7 @@
>
> pwm {
> compatible = "st,stm32-pwm-lp";
> + #pwm-cells = <3>;
> status = "disabled";
> };
> };
>
^ permalink raw reply
* [PATCH v9 07/27] ARM: davinci: dm355: add new clock init using common clock framework
From: Sekhar Nori @ 2018-05-03 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180427001745.4116-8-david@lechnology.com>
On Friday 27 April 2018 05:47 AM, David Lechner wrote:
> This adds the new board-specific clock init in mach-davinci/dm355.c
> using the new common clock framework drivers.
>
> The #ifdefs are needed to prevent compile errors until the entire
> ARCH_DAVINCI is converted.
>
> Also clean up the #includes since we are adding some here.
>
> Signed-off-by: David Lechner <david@lechnology.com>
I am having trouble booting DM355 EVM with the series applied.
Still to debug what is going wrong.
Thanks,
Sekhar
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 4.17.0-rc2-08642-g4dee494ef1ee (a0875516 at psplinux063) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #202 PREEM8
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
CPU: VIVT data cache, VIVT instruction cache
Machine: DaVinci DM355 EVM
Memory policy: Data cache writethrough
cma: Reserved 16 MiB at 0x86c00000
DaVinci dm355 variant 0x0
random: get_random_bytes called from start_kernel+0x88/0x3f4 with crng_init=0
Built 1 zonelists, mobility grouping on. Total pages: 32512
Kernel command line: console=ttyS0,115200n8 root=/dev/nfs rw nfsroot=172.24.210.141:/datalocal/Sekhar/new/debian/armel ip=dhcp
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 107044K/131072K available (4684K kernel code, 283K rwdata, 1068K rodata, 240K init, 134K bss, 7644K reserved, 16384K cma-res)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
vmalloc : 0xc8800000 - 0xff800000 ( 880 MB)
lowmem : 0xc0000000 - 0xc8000000 ( 128 MB)
modules : 0xbf000000 - 0xc0000000 ( 16 MB)
.text : 0x(ptrval) - 0x(ptrval) (4686 kB)
.init : 0x(ptrval) - 0x(ptrval) ( 240 kB)
.data : 0x(ptrval) - 0x(ptrval) ( 284 kB)
.bss : 0x(ptrval) - 0x(ptrval) ( 135 kB)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Preemptible hierarchical RCU implementation.
Tasks RCU enabled.
NR_IRQS: 245
clocksource: timer0_1: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
Console: colour dummy device 80x30
Calibrating delay loop... 106.90 BogoMIPS (lpj=534528)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0x80008400 - 0x80008458
Hierarchical SRCU implementation.
devtmpfs: initialized
Built 1 zonelists, mobility grouping on. Total pages: 30857
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
futex hash table entries: 256 (order: -1, 3072 bytes)
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
mux: initialized INT_EDMA_CC
mux: Setting register INT_EDMA_CC
mux: INTMUX (0x00000018) = 0x00000000 -> 0x00000004
cpuidle: using governor menu
edma edma.0: Legacy memcpy is enabled, things might not work
edma edma.0: TI EDMA DMA engine driver
dm355evm_msp 1-0025: firmware v.A5, TVP5146 as video-in
clocksource: Switched to clocksource timer0_1
NET: Registered protocol family 2
tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes)
TCP established hash table entries: 1024 (order: 0, 4096 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
workingset: timestamp_bits=30 max_order=15 bucket_order=0
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
io scheduler noop registered (default)
io scheduler mq-deadline registered
io scheduler kyber registered
Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled
console [ttyS0] disabled
serial8250.0: ttyS0 at MMIO 0x1c20000 (irq = 40, base_baud = 1500000) is a 16550A
console [ttyS0] enabled
serial8250.1: ttyS1 at MMIO 0x1c20400 (irq = 41, base_baud = 1500000) is a 16550A
serial8250 serial8250.2: unable to register port at index 0 (IO0 MEM1e06000 IRQ14): -22
brd: module loaded
libphy: Fixed MDIO Bus: probed
dm9000 dm9000: incomplete constraints, dummy supplies not allowed
eth0: dm9000a at (ptrval),(ptrval) IRQ 65 MAC: 00:0e:99:02:cb:91 (eeprom)
i2c /dev entries driver
davinci-wdt davinci-wdt: heartbeat 60 sec
Division by zero in kernel.
CPU: 0 PID: 1 Comm: swapper Not tainted 4.17.0-rc2-08642-g4dee494ef1ee #202
Hardware name: DaVinci DM355 EVM
Backtrace:
[<c000dfa4>] (dump_backtrace) from [<c000e274>] (show_stack+0x18/0x1c)
r7:00000000 r6:00000000 r5:fee11000 r4:c6acd400
[<c000e25c>] (show_stack) from [<c047eedc>] (dump_stack+0x20/0x28)
[<c047eebc>] (dump_stack) from [<c000e104>] (__div0+0x18/0x20)
[<c000e0ec>] (__div0) from [<c047d510>] (Ldiv0+0x8/0x10)
[<c0343e48>] (calculate_clk_divider) from [<c0344014>] (mmc_davinci_set_ios+0x58/0x168)
r9:c6ac6b80 r8:c05ed140 r7:0000001a r6:00000001 r5:c6acd5e8 r4:c6acd400
[<c0343fbc>] (mmc_davinci_set_ios) from [<c0330480>] (mmc_set_initial_state+0x9c/0xa0)
r5:c6acd5e8 r4:c6acd400
[<c03303e4>] (mmc_set_initial_state) from [<c03304bc>] (mmc_power_up.part.8+0x38/0x110)
r5:00000015 r4:c6acd400
[<c0330484>] (mmc_power_up.part.8) from [<c033198c>] (mmc_start_host+0x94/0xa8)
r7:0000001a r6:c05ed130 r5:00000000 r4:c6acd400
[<c03318f8>] (mmc_start_host) from [<c0332c5c>] (mmc_add_host+0x60/0x88)
r5:00000000 r4:c6acd400
[<c0332bfc>] (mmc_add_host) from [<c0344630>] (davinci_mmcsd_probe+0x3f8/0x5dc)
r5:c6acd754 r4:c6acd400
[<c0344238>] (davinci_mmcsd_probe) from [<c02d1f70>] (platform_drv_probe+0x58/0xb4)
r10:c05a61d4 r9:00000000 r8:00000000 r7:fffffdfb r6:c061f3e4 r5:ffffffed
r4:c05ed140
[<c02d1f18>] (platform_drv_probe) from [<c02d0380>] (driver_probe_device+0x258/0x33c)
r7:c061f3e4 r6:00000000 r5:c06458d0 r4:c05ed140
[<c02d0128>] (driver_probe_device) from [<c02d0510>] (__driver_attach+0xac/0xb0)
r9:00000000 r8:ffffe000 r7:c05e7008 r6:c05ed174 r5:c061f3e4 r4:c05ed140
[<c02d0464>] (__driver_attach) from [<c02ce384>] (bus_for_each_dev+0x78/0xbc)
r7:c05e7008 r6:c02d0464 r5:c061f3e4 r4:00000000
[<c02ce30c>] (bus_for_each_dev) from [<c02cfcc4>] (driver_attach+0x20/0x28)
r7:00000000 r6:c061b670 r5:c6ad7960 r4:c061f3e4
[<c02cfca4>] (driver_attach) from [<c02cf704>] (bus_add_driver+0x178/0x20c)
[<c02cf58c>] (bus_add_driver) from [<c02d0f00>] (driver_register+0x80/0xfc)
r7:00000000 r6:c05c4a30 r5:c05e7008 r4:c061f3e4
[<c02d0e80>] (driver_register) from [<c02d1ebc>] (__platform_driver_register+0x34/0x48)
r5:c05e7008 r4:c062ae60
[<c02d1e88>] (__platform_driver_register) from [<c05c4a48>] (davinci_mmcsd_driver_init+0x18/0x20)
[<c05c4a30>] (davinci_mmcsd_driver_init) from [<c000a56c>] (do_one_initcall+0x50/0x1a4)
[<c000a51c>] (do_one_initcall) from [<c05a8eb4>] (kernel_init_freeable+0x120/0x1e4)
r8:c05a8614 r7:c05d4830 r6:00000007 r5:c062ae60 r4:c05e2ae8
[<c05a8d94>] (kernel_init_freeable) from [<c04940f4>] (kernel_init+0x10/0xfc)
r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c04940e4
r4:00000000
[<c04940e4>] (kernel_init) from [<c00090e0>] (ret_from_fork+0x14/0x34)
Exception stack(0xc6839fb0 to 0xc6839ff8)
9fa0: 00000000 00000000 00000000 00000000
9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
r5:c04940e4 r4:00000000
Division by zero in kernel.
CPU: 0 PID: 1 Comm: swapper Not tainted 4.17.0-rc2-08642-g4dee494ef1ee #202
Hardware name: DaVinci DM355 EVM
Backtrace:
[<c000dfa4>] (dump_backtrace) from [<c000e274>] (show_stack+0x18/0x1c)
r7:00000000 r6:00000000 r5:fee11000 r4:c6acd400
[<c000e25c>] (show_stack) from [<c047eedc>] (dump_stack+0x20/0x28)
[<c047eebc>] (dump_stack) from [<c000e104>] (__div0+0x18/0x20)
[<c000e0ec>] (__div0) from [<c047d510>] (Ldiv0+0x8/0x10)
[<c0343e48>] (calculate_clk_divider) from [<c0344014>] (mmc_davinci_set_ios+0x58/0x168)
r9:c6ac6b80 r8:c05ed140 r7:00000000 r6:00000001 r5:c6acd5e8 r4:c6acd400
[<c0343fbc>] (mmc_davinci_set_ios) from [<c033057c>] (mmc_power_up.part.8+0xf8/0x110)
r5:c6acd5e8 r4:c6acd400
[<c0330484>] (mmc_power_up.part.8) from [<c033198c>] (mmc_start_host+0x94/0xa8)
r7:0000001a r6:c05ed130 r5:00000000 r4:c6acd400
[<c03318f8>] (mmc_start_host) from [<c0332c5c>] (mmc_add_host+0x60/0x88)
r5:00000000 r4:c6acd400
[<c0332bfc>] (mmc_add_host) from [<c0344630>] (davinci_mmcsd_probe+0x3f8/0x5dc)
r5:c6acd754 r4:c6acd400
[<c0344238>] (davinci_mmcsd_probe) from [<c02d1f70>] (platform_drv_probe+0x58/0xb4)
r10:c05a61d4 r9:00000000 r8:00000000 r7:fffffdfb r6:c061f3e4 r5:ffffffed
r4:c05ed140
[<c02d1f18>] (platform_drv_probe) from [<c02d0380>] (driver_probe_device+0x258/0x33c)
r7:c061f3e4 r6:00000000 r5:c06458d0 r4:c05ed140
[<c02d0128>] (driver_probe_device) from [<c02d0510>] (__driver_attach+0xac/0xb0)
r9:00000000 r8:ffffe000 r7:c05e7008 r6:c05ed174 r5:c061f3e4 r4:c05ed140
[<c02d0464>] (__driver_attach) from [<c02ce384>] (bus_for_each_dev+0x78/0xbc)
r7:c05e7008 r6:c02d0464 r5:c061f3e4 r4:00000000
[<c02ce30c>] (bus_for_each_dev) from [<c02cfcc4>] (driver_attach+0x20/0x28)
r7:00000000 r6:c061b670 r5:c6ad7960 r4:c061f3e4
[<c02cfca4>] (driver_attach) from [<c02cf704>] (bus_add_driver+0x178/0x20c)
[<c02cf58c>] (bus_add_driver) from [<c02d0f00>] (driver_register+0x80/0xfc)
r7:00000000 r6:c05c4a30 r5:c05e7008 r4:c061f3e4
[<c02d0e80>] (driver_register) from [<c02d1ebc>] (__platform_driver_register+0x34/0x48)
r5:c05e7008 r4:c062ae60
[<c02d1e88>] (__platform_driver_register) from [<c05c4a48>] (davinci_mmcsd_driver_init+0x18/0x20)
[<c05c4a30>] (davinci_mmcsd_driver_init) from [<c000a56c>] (do_one_initcall+0x50/0x1a4)
[<c000a51c>] (do_one_initcall) from [<c05a8eb4>] (kernel_init_freeable+0x120/0x1e4)
r8:c05a8614 r7:c05d4830 r6:00000007 r5:c062ae60 r4:c05e2ae8
[<c05a8d94>] (kernel_init_freeable) from [<c04940f4>] (kernel_init+0x10/0xfc)
r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c04940e4
r4:00000000
[<c04940e4>] (kernel_init) from [<c00090e0>] (ret_from_fork+0x14/0x34)
Exception stack(0xc6839fb0 to 0xc6839ff8)
9fa0: 00000000 00000000 00000000 00000000
9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
r5:c04940e4 r4:00000000
Division by zero in kernel.
CPU: 0 PID: 14 Comm: kworker/0:1 Not tainted 4.17.0-rc2-08642-g4dee494ef1ee #202
davinci_mmc dm6441-mmc.0: Using DMA, 4-bit mode
Division by zero in kernel.
Hardware name: DaVinci DM355 EVM
Workqueue: events_freezable mmc_rescan
Backtrace:
[<c000dfa4>] (dump_backtrace) from [<c000e274>] (show_stack+0x18/0x1c)
CPU: 0 PID: 1 Comm: swapper Not tainted 4.17.0-rc2-08642-g4dee494ef1ee #202
Hardware name: DaVinci DM355 EVM
Backtrace:
[<c000dfa4>] (dump_backtrace) from [<c000e274>] (show_stack+0x18/0x1c)
r7:00000000 r6:00000000 r5:fee11000 r4:c6acd400
[<c000e25c>] (show_stack) from [<c047eedc>] (dump_stack+0x20/0x28)
r7:00000000 r6:00000000 r5:fee00000 r4:c6acd800
[<c000e25c>] (show_stack) from [<c047eedc>] (dump_stack+0x20/0x28)
[<c047eebc>] (dump_stack) from [<c000e104>] (__div0+0x18/0x20)
[<c047eebc>] (dump_stack) from [<c000e104>] (__div0+0x18/0x20)
[<c000e0ec>] (__div0) from [<c047d510>] (Ldiv0+0x8/0x10)
[<c000e0ec>] (__div0) from [<c047d510>] (Ldiv0+0x8/0x10)
[<c0343e48>] (calculate_clk_divider) from [<c0344014>] (mmc_davinci_set_ios+0x58/0x168)
[<c0343e48>] (calculate_clk_divider) from [<c0344014>] (mmc_davinci_set_ios+0x58/0x168)
r9:00000000 r8:c05ff7b0 r7:60000013 r6:c6acd400 r5:c6acd5e8 r4:c6acd400
r9:c6ac6d00 r8:c05ed2e0 r7:0000001b r6:00000001 r5:c6acd9e8 r4:c6acd800
[<c0343fbc>] (mmc_davinci_set_ios) from [<c0330480>] (mmc_set_initial_state+0x9c/0xa0)
[<c0343fbc>] (mmc_davinci_set_ios) from [<c0330480>] (mmc_set_initial_state+0x9c/0xa0)
r5:c6acd5e8 r4:c6acd400
[<c03303e4>] (mmc_set_initial_state) from [<c03307ac>] (mmc_power_off.part.9+0x30/0x44)
r5:c6acd9e8 r4:c6acd800
[<c03303e4>] (mmc_set_initial_state) from [<c03304bc>] (mmc_power_up.part.8+0x38/0x110)
r5:00000000 r4:c6acd400
[<c033077c>] (mmc_power_off.part.9) from [<c03317b0>] (mmc_rescan+0x3b8/0x500)
r5:00000015 r4:c6acd800
[<c0330484>] (mmc_power_up.part.8) from [<c033198c>] (mmc_start_host+0x94/0xa8)
r5:00000000 r4:c6acd640
[<c03313f8>] (mmc_rescan) from [<c0031de0>] (process_one_work+0x1d8/0x41c)
r7:0000001b r6:c05ed2d0 r5:00000000 r4:c6acd800
[<c03318f8>] (mmc_start_host) from [<c0332c5c>] (mmc_add_host+0x60/0x88)
r9:00000000 r8:c05ff7b0 r7:00000000 r6:c7ee9500 r5:c68156c0 r4:c6acd640
[<c0031c08>] (process_one_work) from [<c0032060>] (worker_thread+0x3c/0x670)
r10:00000008 r9:c05ff7c4 r8:c060f080 r7:c68156d8 r6:ffffe000 r5:c05ff7b0
r5:00000000 r4:c6acd800
[<c0332bfc>] (mmc_add_host) from [<c0344630>] (davinci_mmcsd_probe+0x3f8/0x5dc)
r5:c6acdb54 r4:c6acd800
[<c0344238>] (davinci_mmcsd_probe) from [<c02d1f70>] (platform_drv_probe+0x58/0xb4)
r4:c68156c0
[<c0032024>] (worker_thread) from [<c0038280>] (kthread+0x134/0x14c)
r10:c05a61d4 r9:00000000 r8:00000000 r7:fffffdfb r6:c061f3e4 r5:ffffffed
r4:c05ed2e0
r10:c6847e90 r9:c0032024 r8:c68156c0 r7:c6878000 r6:00000000 r5:c680dee0
r4:c6868300
[<c003814c>] (kthread) from [<c00090e0>] (ret_from_fork+0x14/0x34)
[<c02d1f18>] (platform_drv_probe) from [<c02d0380>] (driver_probe_device+0x258/0x33c)
Exception stack(0xc6879fb0 to 0xc6879ff8)
9fa0: 00000000 00000000 00000000 00000000
r7:c061f3e4 r6:00000000 r5:c06458d0 r4:c05ed2e0
[<c02d0128>] (driver_probe_device) from [<c02d0510>] (__driver_attach+0xac/0xb0)
9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
r9:00000000 r8:ffffe000 r7:c05e7008 r6:c05ed314 r5:c061f3e4 r4:c05ed2e0
9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c003814c
[<c02d0464>] (__driver_attach) from [<c02ce384>] (bus_for_each_dev+0x78/0xbc)
r7:c05e7008 r6:c02d0464 r5:c061f3e4 r4:00000000
r4:c680dee0
[<c02ce30c>] (bus_for_each_dev) from [<c02cfcc4>] (driver_attach+0x20/0x28)
r7:00000000 r6:c061b670 r5:c6ad7960 r4:c061f3e4
[<c02cfca4>] (driver_attach) from [<c02cf704>] (bus_add_driver+0x178/0x20c)
[<c02cf58c>] (bus_add_driver) from [<c02d0f00>] (driver_register+0x80/0xfc)
r7:00000000 r6:c05c4a30 r5:c05e7008 r4:c061f3e4
[<c02d0e80>] (driver_register) from [<c02d1ebc>] (__platform_driver_register+0x34/0x48)
r5:c05e7008 r4:c062ae60
[<c02d1e88>] (__platform_driver_register) from [<c05c4a48>] (davinci_mmcsd_driver_init+0x18/0x20)
[<c05c4a30>] (davinci_mmcsd_driver_init) from [<c000a56c>] (do_one_initcall+0x50/0x1a4)
[<c000a51c>] (do_one_initcall) from [<c05a8eb4>] (kernel_init_freeable+0x120/0x1e4)
r8:c05a8614 r7:c05d4830 r6:00000007 r5:c062ae60 r4:c05e2ae8
[<c05a8d94>] (kernel_init_freeable) from [<c04940f4>] (kernel_init+0x10/0xfc)
r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c04940e4
random: fast init done
r4:00000000
[<c04940e4>] (kernel_init) from [<c00090e0>] (ret_from_fork+0x14/0x34)
Exception stack(0xc6839fb0 to 0xc6839ff8)
9fa0: 00000000 00000000 00000000 00000000
9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
r5:c04940e4 r4:00000000
Division by zero in kernel.
CPU: 0 PID: 1 Comm: swapper Not tainted 4.17.0-rc2-08642-g4dee494ef1ee #202
Hardware name: DaVinci DM355 EVM
Backtrace:
[<c000dfa4>] (dump_backtrace) from [<c000e274>] (show_stack+0x18/0x1c)
r7:00000000 r6:00000000 r5:fee00000 r4:c6acd800
[<c000e25c>] (show_stack) from [<c047eedc>] (dump_stack+0x20/0x28)
[<c047eebc>] (dump_stack) from [<c000e104>] (__div0+0x18/0x20)
[<c000e0ec>] (__div0) from [<c047d510>] (Ldiv0+0x8/0x10)
[<c0343e48>] (calculate_clk_divider) from [<c0344014>] (mmc_davinci_set_ios+0x58/0x168)
r9:c6ac6d00 r8:c05ed2e0 r7:00000000 r6:00000001 r5:c6acd9e8 r4:c6acd800
[<c0343fbc>] (mmc_davinci_set_ios) from [<c033057c>] (mmc_power_up.part.8+0xf8/0x110)
r5:c6acd9e8 r4:c6acd800
[<c0330484>] (mmc_power_up.part.8) from [<c033198c>] (mmc_start_host+0x94/0xa8)
r7:0000001b r6:c05ed2d0 r5:00000000 r4:c6acd800
[<c03318f8>] (mmc_start_host) from [<c0332c5c>] (mmc_add_host+0x60/0x88)
r5:00000000 r4:c6acd800
[<c0332bfc>] (mmc_add_host) from [<c0344630>] (davinci_mmcsd_probe+0x3f8/0x5dc)
r5:c6acdb54 r4:c6acd800
[<c0344238>] (davinci_mmcsd_probe) from [<c02d1f70>] (platform_drv_probe+0x58/0xb4)
r10:c05a61d4 r9:00000000 r8:00000000 r7:fffffdfb r6:c061f3e4 r5:ffffffed
r4:c05ed2e0
[<c02d1f18>] (platform_drv_probe) from [<c02d0380>] (driver_probe_device+0x258/0x33c)
r7:c061f3e4 r6:00000000 r5:c06458d0 r4:c05ed2e0
[<c02d0128>] (driver_probe_device) from [<c02d0510>] (__driver_attach+0xac/0xb0)
r9:00000000 r8:ffffe000 r7:c05e7008 r6:c05ed314 r5:c061f3e4 r4:c05ed2e0
[<c02d0464>] (__driver_attach) from [<c02ce384>] (bus_for_each_dev+0x78/0xbc)
r7:c05e7008 r6:c02d0464 r5:c061f3e4 r4:00000000
[<c02ce30c>] (bus_for_each_dev) from [<c02cfcc4>] (driver_attach+0x20/0x28)
r7:00000000 r6:c061b670 r5:c6ad7960 r4:c061f3e4
[<c02cfca4>] (driver_attach) from [<c02cf704>] (bus_add_driver+0x178/0x20c)
[<c02cf58c>] (bus_add_driver) from [<c02d0f00>] (driver_register+0x80/0xfc)
r7:00000000 r6:c05c4a30 r5:c05e7008 r4:c061f3e4
[<c02d0e80>] (driver_register) from [<c02d1ebc>] (__platform_driver_register+0x34/0x48)
r5:c05e7008 r4:c062ae60
[<c02d1e88>] (__platform_driver_register) from [<c05c4a48>] (davinci_mmcsd_driver_init+0x18/0x20)
[<c05c4a30>] (davinci_mmcsd_driver_init) from [<c000a56c>] (do_one_initcall+0x50/0x1a4)
[<c000a51c>] (do_one_initcall) from [<c05a8eb4>] (kernel_init_freeable+0x120/0x1e4)
r8:c05a8614 r7:c05d4830 r6:00000007 r5:c062ae60 r4:c05e2ae8
[<c05a8d94>] (kernel_init_freeable) from [<c04940f4>] (kernel_init+0x10/0xfc)
r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c04940e4
r4:00000000
[<c04940e4>] (kernel_init) from [<c00090e0>] (ret_from_fork+0x14/0x34)
Exception stack(0xc6839fb0 to 0xc6839ff8)
9fa0: 00000000 00000000 00000000 00000000
9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
r5:c04940e4 r4:00000000
Division by zero in kernel.
CPU: 0 PID: 14 Comm: kworker/0:1 Not tainted 4.17.0-rc2-08642-g4dee494ef1ee #202
davinci_mmc dm6441-mmc.1: Using DMA, 4-bit mode
NET: Registered protocol family 10
Hardware name: DaVinci DM355 EVM
Workqueue: events_freezable mmc_rescan
Backtrace:
[<c000dfa4>] (dump_backtrace) from [<c000e274>] (show_stack+0x18/0x1c)
r7:00000000 r6:00000000 r5:fee00000 r4:c6acd800
[<c000e25c>] (show_stack) from [<c047eedc>] (dump_stack+0x20/0x28)
Segment Routing with IPv6
sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
NET: Registered protocol family 17
[<c047eebc>] (dump_stack) from [<c000e104>] (__div0+0x18/0x20)
[<c000e0ec>] (__div0) from [<c047d510>] (Ldiv0+0x8/0x10)
[<c0343e48>] (calculate_clk_divider) from [<c0344014>] (mmc_davinci_set_ios+0x58/0x168)
r9:00000000 r8:c05ff7b0 r7:60000013 r6:c6acd800 r5:c6acd9e8 r4:c6acd800
[<c0343fbc>] (mmc_davinci_set_ios) from [<c0330480>] (mmc_set_initial_state+0x9c/0xa0)
r5:c6acd9e8 r4:c6acd800
[<c03303e4>] (mmc_set_initial_state) from [<c03307ac>] (mmc_power_off.part.9+0x30/0x44)
r5:00000000 r4:c6acd800
[<c033077c>] (mmc_power_off.part.9) from [<c03317b0>] (mmc_rescan+0x3b8/0x500)
r5:00000000 r4:c6acda40
[<c03313f8>] (mmc_rescan) from [<c0031de0>] (process_one_work+0x1d8/0x41c)
r9:00000000 r8:c05ff7b0 r7:00000000 r6:c7ee9500 r5:c68156c0 r4:c6acda40
[<c0031c08>] (process_one_work) from [<c0032060>] (worker_thread+0x3c/0x670)
r10:00000008 r9:c05ff7c4 r8:c060f080 r7:c68156d8 r6:ffffe000 r5:c05ff7b0
r4:c68156c0
[<c0032024>] (worker_thread) from [<c0038280>] (kthread+0x134/0x14c)
r10:c6847e90 r9:c0032024 r8:c68156c0 r7:c6878000 r6:00000000 r5:c680dee0
r4:c6868300
[<c003814c>] (kthread) from [<c00090e0>] (ret_from_fork+0x14/0x34)
Exception stack(0xc6879fb0 to 0xc6879ff8)
9fa0: 00000000 00000000 00000000 00000000
9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c003814c
r4:c680dee0
console [netcon0] enabled
netconsole: network logging started
hctosys: unable to open rtc device (rtc0)
dm9000 dm9000 eth0: link down
IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Sending DHCP requests .
dm9000 dm9000 eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
, OK
IP-Config: Got DHCP answer from 172.24.188.3, my address is 172.24.190.9
IP-Config: Complete:
device=eth0, hwaddr=00:0e:99:02:cb:91, ipaddr=172.24.190.9, mask=255.255.252.0, gw=172.24.188.1
host=172.24.190.9, domain=india.ti.com, nis-domain=(none)
bootserver=0.0.0.0, rootserver=172.24.210.141, rootpath= nameserver0=192.0.2.2, nameserver1=192.0.2.3
this is MT29F16G08FAA device
^ permalink raw reply
* [PATCH v2] ARM: dts: cygnus: fix irq type for arm global timer
From: Clément Péron @ 2018-05-03 15:32 UTC (permalink / raw)
To: linux-arm-kernel
As per ARM documentation
PPI(0) ID27 - global timer interrupt is rising-edge sensitive.
set IRQ triggering type to IRQ_TYPE_EDGE_RISING for ARM Global timers.
Fixes: c9ad7bc5fe3 ("ARM: dts: Enable Broadcom Cygnus SoC")
Signed-off-by: Cl?ment P?ron <peron.clem@gmail.com>
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 699fdf94d139..9fe4f5a6379e 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -69,7 +69,7 @@
timer at 20200 {
compatible = "arm,cortex-a9-global-timer";
reg = <0x20200 0x100>;
- interrupts = <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_PPI 11 IRQ_TYPE_EDGE_RISING>;
clocks = <&periph_clk>;
};
--
2.17.0
^ permalink raw reply related
* [PATCH 4/6] mm, arm64: untag user addresses in mm/gup.c
From: Kirill A. Shutemov @ 2018-05-03 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAeHK+zh0LSpq2VFJeHrV7AETnL1b9R+yex3iPMg5SetbEyxwg@mail.gmail.com>
On Thu, May 03, 2018 at 04:09:56PM +0200, Andrey Konovalov wrote:
> On Wed, May 2, 2018 at 7:25 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> > On Wed, May 2, 2018 at 5:36 PM, Kirill A. Shutemov
> > <kirill.shutemov@linux.intel.com> wrote:
> >> On Wed, May 02, 2018 at 02:38:42PM +0000, Andrey Konovalov wrote:
> >>> > Does having a tagged address here makes any difference? I couldn't hit a
> >>> > failure with my simple tests (LD_PRELOAD a library that randomly adds
> >>> > tags to pointers returned by malloc).
> >>>
> >>> I think you're right, follow_page_mask is only called from
> >>> __get_user_pages, which already untagged the address. I'll remove
> >>> untagging here.
> >>
> >> It also called from follow_page(). Have you covered all its callers?
> >
> > Oh, missed that, will take a look.
>
> I wasn't able to find anything that calls follow_page with pointers
> passed from userspace except for the memory subsystem syscalls, and we
> deliberately don't add untagging in those.
I guess I missed this part, but could you elaborate on this? Why?
Not yet or not ever?
Also I wounder if we can find (with sparse?) all places where we cast out
__user. This would give a nice list of places where to pay attention.
--
Kirill A. Shutemov
^ permalink raw reply
* [PATCH 2/2] perf cs-etm: Remove redundant space
From: Leo Yan @ 2018-05-03 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525360703-26159-1-git-send-email-leo.yan@linaro.org>
There have two spaces ahead function name cs_etm__set_pid_tid_cpu(), so
remove one space and correct indentation.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
tools/perf/util/cs-etm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 417302c..3137fbe 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -612,8 +612,8 @@ cs_etm__get_trace(struct cs_etm_buffer *buff, struct cs_etm_queue *etmq)
return buff->len;
}
-static void cs_etm__set_pid_tid_cpu(struct cs_etm_auxtrace *etm,
- struct auxtrace_queue *queue)
+static void cs_etm__set_pid_tid_cpu(struct cs_etm_auxtrace *etm,
+ struct auxtrace_queue *queue)
{
struct cs_etm_queue *etmq = queue->priv;
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] perf cs-etm: Support unknown_thread in cs_etm_auxtrace
From: Leo Yan @ 2018-05-03 15:18 UTC (permalink / raw)
To: linux-arm-kernel
CoreSight doesn't allocate thread structure for unknown_thread in etm
auxtrace, so unknown_thread is NULL pointer. If the perf data doesn't
contain valid tid and then cs_etm__mem_access() uses unknown_thread
instead as thread handler, this results in segmentation fault when
thread__find_addr_map() accesses thread handler.
This commit creates new thread data which is used by unknown_thread, so
CoreSight tracing can roll back to use unknown_thread if perf data
doesn't include valid thread info. This commit also releases thread
data for initialization failure case and for normal auxtrace free flow.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
tools/perf/util/cs-etm.c | 25 +++++++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 6533b1a..417302c 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -239,6 +239,7 @@ static void cs_etm__free(struct perf_session *session)
for (i = 0; i < aux->num_cpu; i++)
zfree(&aux->metadata[i]);
+ thread__zput(aux->unknown_thread);
zfree(&aux->metadata);
zfree(&aux);
}
@@ -266,6 +267,7 @@ static u32 cs_etm__mem_access(struct cs_etm_queue *etmq, u64 address,
if (!thread) {
if (cpumode != PERF_RECORD_MISC_KERNEL)
return -EINVAL;
+
thread = etmq->etm->unknown_thread;
}
@@ -1355,6 +1357,23 @@ int cs_etm__process_auxtrace_info(union perf_event *event,
etm->auxtrace.free = cs_etm__free;
session->auxtrace = &etm->auxtrace;
+ etm->unknown_thread = thread__new(999999999, 999999999);
+ if (!etm->unknown_thread)
+ goto err_free_queues;
+
+ /*
+ * Initialize list node so that at thread__zput() we can avoid
+ * segmentation fault at list_del_init().
+ */
+ INIT_LIST_HEAD(&etm->unknown_thread->node);
+
+ err = thread__set_comm(etm->unknown_thread, "unknown", 0);
+ if (err)
+ goto err_delete_thread;
+
+ if (thread__init_map_groups(etm->unknown_thread, etm->machine))
+ goto err_delete_thread;
+
if (dump_trace) {
cs_etm__print_auxtrace_info(auxtrace_info->priv, num_cpu);
return 0;
@@ -1369,16 +1388,18 @@ int cs_etm__process_auxtrace_info(union perf_event *event,
err = cs_etm__synth_events(etm, session);
if (err)
- goto err_free_queues;
+ goto err_delete_thread;
err = auxtrace_queues__process_index(&etm->queues, session);
if (err)
- goto err_free_queues;
+ goto err_delete_thread;
etm->data_queued = etm->queues.populated;
return 0;
+err_delete_thread:
+ thread__zput(etm->unknown_thread);
err_free_queues:
auxtrace_queues__free(&etm->queues);
session->auxtrace = NULL;
--
2.7.4
^ permalink raw reply related
* [PATCH v8 11/13] arm64: topology: enable ACPI/PPTT based CPU topology
From: Morten Rasmussen @ 2018-05-03 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180425233121.13270-12-jeremy.linton@arm.com>
On Wed, Apr 25, 2018 at 06:31:19PM -0500, Jeremy Linton wrote:
> Propagate the topology information from the PPTT tree to the
> cpu_topology array. We can get the thread id and core_id by assuming
> certain levels of the PPTT tree correspond to those concepts.
> The package_id is flagged in the tree and can be found by calling
> find_acpi_cpu_topology_package() which terminates
> its search when it finds an ACPI node flagged as the physical
> package. If the tree doesn't contain enough levels to represent
> all of the requested levels then the root node will be returned
> for all subsequent levels.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Acked-by: Morten Rasmussen <morten.rasmussen@arm.com>
^ permalink raw reply
* [PATCH v8 10/13] arm64: topology: rename cluster_id
From: Morten Rasmussen @ 2018-05-03 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180425233121.13270-11-jeremy.linton@arm.com>
On Wed, Apr 25, 2018 at 06:31:18PM -0500, Jeremy Linton wrote:
> Lets match the name of the arm64 topology field
> to the kernel macro that uses it.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Acked-by: Morten Rasmussen <morten.rasmussen@arm.com>
^ permalink raw reply
* [PATCH] ARM: dts: cygnus: add ethernet0 alias
From: Florian Fainelli @ 2018-05-03 15:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503095618.2312-1-peron.clem@gmail.com>
+Ray, Scott, Eric, list
On 05/03/2018 02:56 AM, Cl?ment P?ron wrote:
> In order to avoid Linux generating a random mac address on every boot,
> add an ethernet0 alias that will allow u-boot to patch the dtb with
> the MAC address.
>
> Signed-off-by: Cl?ment P?ron <peron.clem@gmail.com>
> ---
> arch/arm/boot/dts/bcm-cygnus.dtsi | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
> index 9fe4f5a6379e..1a05b8f48b54 100644
> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
> @@ -41,6 +41,10 @@
> model = "Broadcom Cygnus SoC";
> interrupt-parent = <&gic>;
>
> + aliases {
> + ethernet0 = ð0;
> + };
> +
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
>
--
Florian
^ permalink raw reply
* [PATCH v8 13/13] arm64: topology: divorce MC scheduling domain from core_siblings
From: Morten Rasmussen @ 2018-05-03 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180425233121.13270-14-jeremy.linton@arm.com>
On Wed, Apr 25, 2018 at 06:31:21PM -0500, Jeremy Linton wrote:
> Now that we have an accurate view of the physical topology
> we need to represent it correctly to the scheduler. Generally MC
> should equal the LLC in the system, but there are a number of
> special cases that need to be dealt with.
>
> In the case of NUMA in socket, we need to assure that the sched
> domain we build for the MC layer isn't larger than the DIE above it.
> Similarly for LLC's that might exist in cross socket interconnect or
> directory hardware we need to assure that MC is shrunk to the socket
> or NUMA node.
>
> This patch builds a sibling mask for the LLC, and then picks the
> smallest of LLC, socket siblings, or NUMA node siblings, which
> gives us the behavior described above. This is ever so slightly
> different than the similar alternative where we look for a cache
> layer less than or equal to the socket/NUMA siblings.
>
> The logic to pick the MC layer affects all arm64 machines, but
> only changes the behavior for DT/MPIDR systems if the NUMA domain
> is smaller than the core siblings (generally set to the cluster).
> Potentially this fixes a possible bug in DT systems, but really
> it only affects ACPI systems where the core siblings is correctly
> set to the socket siblings. Thus all currently available ACPI
> systems should have MC equal to LLC, including the NUMA in socket
> machines where the LLC is partitioned between the NUMA nodes.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
This patch looks good to me.
Acked-by: Morten Rasmussen <morten.rasmussen@arm.com>
^ permalink raw reply
* [PATCH v1 0/3] Append additional I2C instances and activate I2C1.
From: Alexandre Torgue @ 2018-05-03 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1524215110-13967-1-git-send-email-pierre-yves.mordret@st.com>
Hi,
On 04/20/2018 11:05 AM, Pierre-Yves MORDRET wrote:
> This patch intends to appends 3 additional I2C instances (2, 3 and 4).
> In the same time I2C1 is setup for both STM32F746 and STM32F769 Discovery
> boards.
> ---
> Version history:
> v1:
> * Initial
> ---
>
> Pierre-Yves MORDRET (3):
> ARM: dts: stm32: Append additional I2Cs for STM32F746 SoC
> ARM: dts: stm32: Add I2C1 support for STM32F769-DISCO Board
> ARM: dts: stm32: Add I2C1 support for STM32F746-DISCO Board
>
> arch/arm/boot/dts/stm32f746-disco.dts | 8 ++++++++
> arch/arm/boot/dts/stm32f746.dtsi | 36 +++++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/stm32f769-disco.dts | 8 ++++++++
> 3 files changed, 52 insertions(+)
>
Series applied on stm32-next.
Regards
Alex
^ permalink raw reply
* [PATCH] tty/serial: atmel: use port->name as name in request_irq()
From: Richard Genoud @ 2018-05-03 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <921729c6-7c3f-11cd-8634-044a5c52f810@sorico.fr>
On 03/05/2018 15:34, Richard Genoud wrote:
> On 03/05/2018 14:44, Sebastian Andrzej Siewior wrote:
>> On 2018-05-03 14:36:03 [+0200], Richard Genoud wrote:
>>> Could resend your patch with Fixes: in the commit message ?
>>
>> will do shortly.
>>
>>> BTW, I didn't manage to reproduce the behavior you describe, could you
>>> give me your .config and describe a little more how you manage to
>>> trigger this bug ?
>> .config sent offlist.
>> Did you not reproduce this even with the second/debug patch I've sent?
> Nope. (I tried on a sam9g35 with buildroot/busybox)
>
> I have a sama5d3 with a debian as a home server, I'll give it a try.
Ok, I reproduced the use-after-free on a SAMA5D2 and on a SAMA5D3, both
with debian (sid / stretch).
After the patch, no mode funny things in /proc/interrupts.
>
>>
>>> (do you use the console on serial debug ? which board ? )
>> up to date debian sid booting with systemd. After boot completed I do
>> "cat /proc/interrupts" and check for the "gone" string.
>> This is
>> [ 0.000000] OF: fdt:Machine model: SAMA5D3 Xplained
>> [ 0.000000] Kernel command line: earlyprintk=ttyS0,115200 console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait
>> [ 0.520000] AT91: Detected SoC family: sama5d3
>> [ 0.520000] AT91: Detected SoC: sama5d36, revision 2
>>
>> at91-sama5d3_xplained.dtb
>>
>> Is this enough?
>
> Great,
>
> Thanks !
>
^ 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