* [PATCH v4 04/12] clk: qcom: Add HFPLL driver
From: Rob Herring @ 2017-12-12 20:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512726150-7204-5-git-send-email-sricharan@codeaurora.org>
On Fri, Dec 08, 2017 at 03:12:22PM +0530, Sricharan R wrote:
> From: Stephen Boyd <sboyd@codeaurora.org>
>
> On some devices (MSM8974 for example), the HFPLLs are
> instantiated within the Krait processor subsystem as separate
> register regions. Add a driver for these PLLs so that we can
> provide HFPLL clocks for use by the system.
>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> .../devicetree/bindings/clock/qcom,hfpll.txt | 40 ++++++++
> drivers/clk/qcom/Kconfig | 8 ++
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/hfpll.c | 106 +++++++++++++++++++++
> 4 files changed, 155 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/qcom,hfpll.txt
> create mode 100644 drivers/clk/qcom/hfpll.c
>
> diff --git a/Documentation/devicetree/bindings/clock/qcom,hfpll.txt b/Documentation/devicetree/bindings/clock/qcom,hfpll.txt
> new file mode 100644
> index 0000000..fee92bb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/qcom,hfpll.txt
> @@ -0,0 +1,40 @@
> +High-Frequency PLL (HFPLL)
> +
> +PROPERTIES
> +
> +- compatible:
> + Usage: required
> + Value type: <string>
> + Definition: must be "qcom,hfpll"
Fine for a fallback, but please add SoC specific compatibles.
> +
> +- reg:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: address and size of HPLL registers. An optional second
> + element specifies the address and size of the alias
> + register region.
> +
> +- clock-output-names:
> + Usage: required
> + Value type: <string>
> + Definition: Name of the PLL. Typically hfpllX where X is a CPU number
> + starting at 0. Otherwise hfpll_Y where Y is more specific
> + such as "l2".
> +
> +Example:
> +
> +1) An HFPLL for the L2 cache.
> +
> + clock-controller at f9016000 {
> + compatible = "qcom,hfpll";
> + reg = <0xf9016000 0x30>;
> + clock-output-names = "hfpll_l2";
> + };
> +
> +2) An HFPLL for CPU0. This HFPLL has the alias register region.
> +
> + clock-controller at f908a000 {
> + compatible = "qcom,hfpll";
> + reg = <0xf908a000 0x30>, <0xf900a000 0x30>;
> + clock-output-names = "hfpll0";
> + };
> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
> index 20b5d6f..6c811bd 100644
> --- a/drivers/clk/qcom/Kconfig
> +++ b/drivers/clk/qcom/Kconfig
> @@ -205,3 +205,11 @@ config SPMI_PMIC_CLKDIV
> Technologies, Inc. SPMI PMIC. It configures the frequency of
> clkdiv outputs of the PMIC. These clocks are typically wired
> through alternate functions on GPIO pins.
> +
> +config QCOM_HFPLL
> + tristate "High-Frequency PLL (HFPLL) Clock Controller"
> + depends on COMMON_CLK_QCOM
> + help
> + Support for the high-frequency PLLs present on Qualcomm devices.
> + Say Y if you want to support CPU frequency scaling on devices
> + such as MSM8974, APQ8084, etc.
> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
> index 4795e21..4a4bf38 100644
> --- a/drivers/clk/qcom/Makefile
> +++ b/drivers/clk/qcom/Makefile
> @@ -36,3 +36,4 @@ obj-$(CONFIG_MSM_MMCC_8996) += mmcc-msm8996.o
> obj-$(CONFIG_QCOM_CLK_RPM) += clk-rpm.o
> obj-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o
> obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o
> +obj-$(CONFIG_QCOM_HFPLL) += hfpll.o
> diff --git a/drivers/clk/qcom/hfpll.c b/drivers/clk/qcom/hfpll.c
> new file mode 100644
> index 0000000..7405bb6
> --- /dev/null
> +++ b/drivers/clk/qcom/hfpll.c
> @@ -0,0 +1,106 @@
> +/*
> + * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
It's 2017.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
Use SPDX tags.
Rob
^ permalink raw reply
* [PATCH v4 05/12] clk: qcom: Add MSM8960/APQ8064's HFPLLs
From: Rob Herring @ 2017-12-12 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512726150-7204-6-git-send-email-sricharan@codeaurora.org>
On Fri, Dec 08, 2017 at 03:12:23PM +0530, Sricharan R wrote:
> From: Stephen Boyd <sboyd@codeaurora.org>
>
> Describe the HFPLLs present on MSM8960 and APQ8064 devices.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> drivers/clk/qcom/gcc-msm8960.c | 172 +++++++++++++++++++++++++++
> include/dt-bindings/clock/qcom,gcc-msm8960.h | 2 +
For the binding,
Acked-by: Rob Herring <robh@kernel.org>
> 2 files changed, 174 insertions(+)
^ permalink raw reply
* [PATCH v4 08/12] clk: qcom: Add KPSS ACC/GCC driver
From: Rob Herring @ 2017-12-12 20:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512726150-7204-9-git-send-email-sricharan@codeaurora.org>
On Fri, Dec 08, 2017 at 03:12:26PM +0530, Sricharan R wrote:
> From: Stephen Boyd <sboyd@codeaurora.org>
>
> The ACC and GCC regions present in KPSSv1 contain registers to
> control clocks and power to each Krait CPU and L2. For CPUfreq
> purposes probe these devices and expose a mux clock that chooses
> between PXO and PLL8.
>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt | 7 ++
> .../devicetree/bindings/arm/msm/qcom,kpss-gcc.txt | 28 +++++++
Please make bindings a separate patch.
> drivers/clk/qcom/Kconfig | 8 ++
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/kpss-xcc.c | 96 ++++++++++++++++++++++
> 5 files changed, 140 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
> create mode 100644 drivers/clk/qcom/kpss-xcc.c
>
> diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
> index 1333db9..382a574 100644
> --- a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
> +++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
> @@ -21,10 +21,17 @@ PROPERTIES
> the register region. An optional second element specifies
> the base address and size of the alias register region.
>
> +- clock-output-names:
> + Usage: optional
> + Value type: <string>
> + Definition: Name of the output clock. Typically acpuX_aux where X is a
> + CPU number starting at 0.
> +
> Example:
>
> clock-controller at 2088000 {
> compatible = "qcom,kpss-acc-v2";
> reg = <0x02088000 0x1000>,
> <0x02008000 0x1000>;
> + clock-output-names = "acpu0_aux";
> };
> diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
> new file mode 100644
> index 0000000..d1e12f1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
> @@ -0,0 +1,28 @@
> +Krait Processor Sub-system (KPSS) Global Clock Controller (GCC)
> +
> +PROPERTIES
> +
> +- compatible:
> + Usage: required
> + Value type: <string>
> + Definition: should be one of:
> + "qcom,kpss-gcc"
Only one implementation?
> +
> +- reg:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: base address and size of the register region
> +
> +- clock-output-names:
> + Usage: required
> + Value type: <string>
> + Definition: Name of the output clock. Typically acpu_l2_aux indicating
> + an L2 cache auxiliary clock.
> +
> +Example:
> +
> + l2cc: clock-controller at 2011000 {
> + compatible = "qcom,kpss-gcc";
> + reg = <0x2011000 0x1000>;
> + clock-output-names = "acpu_l2_aux";
> + };
^ permalink raw reply
* [PATCH v7 3/8] KVM: arm/arm64: Don't cache the timer IRQ level
From: Christoffer Dall @ 2017-12-12 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1604e8d6-5f9a-f91d-c199-57f323c09374@redhat.com>
On Tue, Dec 12, 2017 at 09:40:10AM +0100, Auger Eric wrote:
>
>
> On 11/12/17 21:51, Auger Eric wrote:
> > Hi Christoffer,
> > On 07/12/17 11:54, Christoffer Dall wrote:
> >> The timer was modeled after a strict idea of modelling an interrupt line
> >> level in software, meaning that only transitions in the level needed to
> >> be reported to the VGIC. This works well for the timer, because the
> >> arch timer code is in complete control of the device and can track the
> >> transitions of the line.
> >>
> >> However, as we are about to support using the HW bit in the VGIC not
> >> just for the timer, but also for VFIO which cannot track transitions of
> >> the interrupt line, we have to decide on an interface for level
> >> triggered mapped interrupts to the GIC, which both the timer and VFIO
> >> can use.
> >>
> >> VFIO only sees an asserting transition of the physical interrupt line,
> >> and tells the VGIC when that happens. That means that part of the
> >> interrupt flow is offloaded to the hardware.
> >>
> >> To use the same interface for VFIO devices and the timer, we therefore
> >> have to change the timer (we cannot change VFIO because it doesn't know
> >> the details of the device it is assigning to a VM).
> >>
> >> Luckily, changing the timer is simple, we just need to stop 'caching'
> >> the line level, but instead let the VGIC know the state of the timer
> >> every time there is a potential change in the line level, and when the
> >> line level should be asserted from the timer ISR. The VGIC can ignore
> >> extra notifications using its validate mechanism.
> >
> > I was confused by the fact we say we stop caching the line level but
> > vtimer->irq.level still exists, is updated in the vtimer host ISR and
> > kvm_timer_update_state() and read in many places.
> >
> > I feel difficult to figure out if each time we use the vtimer->irq.level
> > value it is safe to use it.
> >
> > Also for the validate() to succeed we need the vgic irq->line_level to
> > to be 0. I understand this is properly handled for mapped level irqs in
> > next patch which does that on the populate_lr. However I currently fail
> > to understand why the timer level sensitive mapped IRQ does not require
> > the next patch to work.
> OK reading again "[PATCH v7 7/8] KVM: arm/arm64: Provide a
> get_input_level for the arch timer", I now understand it works because
> we had the
> kvm_timer_sync_hwstate toggling down the line on VM exit. After the
> changes of next patch this can be safely removed.
Yes, but also note that this patch in isolation doesn't break anything,
it just ensures that we notify the GIC of an asserted line more often.
>
> Not related to this patch but I noticed
> Documentation/virtual/kvm/arm/vgic-mapped-irqs.txt now is outdated.
Good point, I have updated the docs and will include that in v8.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH 0/3] [v9] pinctrl: qcom: add support for sparse GPIOs
From: Timur Tabi @ 2017-12-12 20:50 UTC (permalink / raw)
To: linux-arm-kernel
A series of patches that add support for GPIO maps that have holes in
them. That is, even though a client driver has N consecutive GPIOs,
some are just unavailable for whatever reason, and the hardware should
not be accessed for those GPIOs.
Patch 1 reverts an old patch that triggers a get_direction of every
pin upon init, without attempting to request the pins first. The
direction is already being queried when the pin is requested.
Patch 2 adds support to pinctrl-msm for "unavailable" GPIOs.
Patch 3 extends that support to pinctrl-qdf2xxx. A recent ACPI change
on QDF2400 platforms blocks access to most pins, so the driver can only
register a subset.
This version drops the availability check in gpiolib, because it's no
necessary. Instead, just having pinctrl-msm return -EACCES is enough
to block all unavailable GPIOs. Patch 1 removes the only instance where
an unrequested GPIO is being accessed.
v9:
Removed "gpiolib: add bitmask for valid GPIO lines"
Timur Tabi (3):
[v2] Revert "gpio: set up initial state from .get_direction()"
[v8] pinctrl: qcom: disable GPIO groups with no pins
[v5] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
drivers/gpio/gpiolib.c | 31 ++-----
drivers/pinctrl/qcom/pinctrl-msm.c | 28 +++++--
drivers/pinctrl/qcom/pinctrl-qdf2xxx.c | 143 ++++++++++++++++++++++++---------
3 files changed, 137 insertions(+), 65 deletions(-)
--
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 1/3] [v2] Revert "gpio: set up initial state from .get_direction()"
From: Timur Tabi @ 2017-12-12 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513111858-6251-1-git-send-email-timur@codeaurora.org>
This reverts commit 72d3200061776264941be1b5a9bb8e926b3b30a5.
We cannot blindly query the direction of all GPIOs when the pins are
first registered. The get_direction callback normally triggers a
read/write to hardware, but we shouldn't be touching the hardware for
an individual GPIO until after it's been properly claimed.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
drivers/gpio/gpiolib.c | 31 +++++++------------------------
1 file changed, 7 insertions(+), 24 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 641a5eb552cb..168dd831551d 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1207,31 +1207,14 @@ int gpiochip_add_data_with_key(struct gpio_chip *chip, void *data,
struct gpio_desc *desc = &gdev->descs[i];
desc->gdev = gdev;
- /*
- * REVISIT: most hardware initializes GPIOs as inputs
- * (often with pullups enabled) so power usage is
- * minimized. Linux code should set the gpio direction
- * first thing; but until it does, and in case
- * chip->get_direction is not set, we may expose the
- * wrong direction in sysfs.
- */
-
- if (chip->get_direction) {
- /*
- * If we have .get_direction, set up the initial
- * direction flag from the hardware.
- */
- int dir = chip->get_direction(chip, i);
- if (!dir)
- set_bit(FLAG_IS_OUT, &desc->flags);
- } else if (!chip->direction_input) {
- /*
- * If the chip lacks the .direction_input callback
- * we logically assume all lines are outputs.
- */
- set_bit(FLAG_IS_OUT, &desc->flags);
- }
+ /* REVISIT: most hardware initializes GPIOs as inputs (often
+ * with pullups enabled) so power usage is minimized. Linux
+ * code should set the gpio direction first thing; but until
+ * it does, and in case chip->get_direction is not set, we may
+ * expose the wrong direction in sysfs.
+ */
+ desc->flags = !chip->direction_input ? (1 << FLAG_IS_OUT) : 0;
}
#ifdef CONFIG_PINCTRL
--
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 related
* [PATCH 2/3] [v8] pinctrl: qcom: disable GPIO groups with no pins
From: Timur Tabi @ 2017-12-12 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513111858-6251-1-git-send-email-timur@codeaurora.org>
pinctrl-msm only accepts an array of GPIOs from 0 to n-1, and it expects
each group to support have only one pin (npins == 1).
We can support "sparse" GPIO maps if we allow for some groups to have zero
pins (npins == 0). These pins are "hidden" from the rest of the driver
and gpiolib.
Access to unavailable GPIOs is blocked via a request callback. If the
requested GPIO is unavailable, -EACCES is returned, which prevents
further access to that GPIO.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
drivers/pinctrl/qcom/pinctrl-msm.c | 28 +++++++++++++++++++++++-----
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c
index 7a960590ecaa..d45b4c2b5af1 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -507,6 +507,11 @@ static void msm_gpio_dbg_show_one(struct seq_file *s,
};
g = &pctrl->soc->groups[offset];
+
+ /* If the GPIO group has no pins, then don't show it. */
+ if (!g->npins)
+ return;
+
ctl_reg = readl(pctrl->regs + g->ctl_reg);
is_out = !!(ctl_reg & BIT(g->oe_bit));
@@ -516,7 +521,7 @@ static void msm_gpio_dbg_show_one(struct seq_file *s,
seq_printf(s, " %-8s: %-3s %d", g->name, is_out ? "out" : "in", func);
seq_printf(s, " %dmA", msm_regval_to_drive(drive));
- seq_printf(s, " %s", pulls[pull]);
+ seq_printf(s, " %s\n", pulls[pull]);
}
static void msm_gpio_dbg_show(struct seq_file *s, struct gpio_chip *chip)
@@ -524,23 +529,36 @@ static void msm_gpio_dbg_show(struct seq_file *s, struct gpio_chip *chip)
unsigned gpio = chip->base;
unsigned i;
- for (i = 0; i < chip->ngpio; i++, gpio++) {
+ for (i = 0; i < chip->ngpio; i++, gpio++)
msm_gpio_dbg_show_one(s, NULL, chip, i, gpio);
- seq_puts(s, "\n");
- }
}
#else
#define msm_gpio_dbg_show NULL
#endif
+/*
+ * If the requested GPIO has no pins, then treat it as unavailable.
+ * Otherwise, call the standard request function.
+ */
+static int msm_gpio_request(struct gpio_chip *chip, unsigned int offset)
+{
+ struct msm_pinctrl *pctrl = gpiochip_get_data(chip);
+ const struct msm_pingroup *g = &pctrl->soc->groups[offset];
+
+ if (!g->npins)
+ return -EACCES;
+
+ return gpiochip_generic_request(chip, offset);
+}
+
static const struct gpio_chip msm_gpio_template = {
.direction_input = msm_gpio_direction_input,
.direction_output = msm_gpio_direction_output,
.get_direction = msm_gpio_get_direction,
.get = msm_gpio_get,
.set = msm_gpio_set,
- .request = gpiochip_generic_request,
+ .request = msm_gpio_request,
.free = gpiochip_generic_free,
.dbg_show = msm_gpio_dbg_show,
};
--
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 related
* [PATCH 3/3] [v5] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Timur Tabi @ 2017-12-12 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513111858-6251-1-git-send-email-timur@codeaurora.org>
Newer versions of the firmware for the Qualcomm Datacenter Technologies
QDF2400 restricts access to a subset of the GPIOs on the TLMM. To
prevent older kernels from accidentally accessing the restricted GPIOs,
we change the ACPI HID for the TLMM block from QCOM8001 to QCOM8002,
and introduce a new property "gpios". This property is an array of
specific GPIOs that are accessible. When an older kernel boots on
newer (restricted) firmware, it will fail to probe.
To implement the sparse GPIO map, we register all of the GPIOs, but set
the pin count for the unavailable GPIOs to zero. The pinctrl-msm
driver will block those unavailable GPIOs from being accessed.
To allow newer kernels to support older firmware, the driver retains
support for QCOM8001.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
drivers/pinctrl/qcom/pinctrl-qdf2xxx.c | 143 ++++++++++++++++++++++++---------
1 file changed, 107 insertions(+), 36 deletions(-)
diff --git a/drivers/pinctrl/qcom/pinctrl-qdf2xxx.c b/drivers/pinctrl/qcom/pinctrl-qdf2xxx.c
index bb3ce5c3e18b..90b32f424a28 100644
--- a/drivers/pinctrl/qcom/pinctrl-qdf2xxx.c
+++ b/drivers/pinctrl/qcom/pinctrl-qdf2xxx.c
@@ -38,68 +38,145 @@
/* maximum size of each gpio name (enough room for "gpioXXX" + null) */
#define NAME_SIZE 8
+enum {
+ QDF2XXX_V1,
+ QDF2XXX_V2,
+};
+
+static const struct acpi_device_id qdf2xxx_acpi_ids[] = {
+ {"QCOM8001", QDF2XXX_V1},
+ {"QCOM8002", QDF2XXX_V2},
+ {},
+};
+MODULE_DEVICE_TABLE(acpi, qdf2xxx_acpi_ids);
+
static int qdf2xxx_pinctrl_probe(struct platform_device *pdev)
{
+ const struct acpi_device_id *id =
+ acpi_match_device(qdf2xxx_acpi_ids, &pdev->dev);
struct pinctrl_pin_desc *pins;
struct msm_pingroup *groups;
char (*names)[NAME_SIZE];
unsigned int i;
u32 num_gpios;
+ unsigned int avail_gpios; /* The number of GPIOs we support */
+ u16 *gpios; /* An array of supported GPIOs */
int ret;
/* Query the number of GPIOs from ACPI */
ret = device_property_read_u32(&pdev->dev, "num-gpios", &num_gpios);
if (ret < 0) {
- dev_warn(&pdev->dev, "missing num-gpios property\n");
+ dev_err(&pdev->dev, "missing 'num-gpios' property\n");
return ret;
}
-
if (!num_gpios || num_gpios > MAX_GPIOS) {
- dev_warn(&pdev->dev, "invalid num-gpios property\n");
+ dev_err(&pdev->dev, "invalid 'num-gpios' property\n");
return -ENODEV;
}
+ /*
+ * The QCOM8001 HID contains only the number of GPIOs, and assumes
+ * that all of them are available. avail_gpios is the same as num_gpios.
+ *
+ * The QCOM8002 HID introduces the 'gpios' DSD, which lists
+ * specific GPIOs that the driver is allowed to access.
+ *
+ * The make the common code simpler, in both cases we create an
+ * array of GPIOs that are accessible. So for QCOM8001, that would
+ * be all of the GPIOs.
+ */
+ if (id->driver_data == QDF2XXX_V1) {
+ avail_gpios = num_gpios;
+
+ gpios = devm_kmalloc_array(&pdev->dev, avail_gpios,
+ sizeof(gpios[0]), GFP_KERNEL);
+ if (!gpios)
+ return -ENOMEM;
+
+ for (i = 0; i < avail_gpios; i++)
+ gpios[i] = i;
+ } else {
+ /* The number of GPIOs in the approved list */
+ ret = device_property_read_u16_array(&pdev->dev, "gpios",
+ NULL, 0);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "missing 'gpios' property\n");
+ return ret;
+ }
+ /*
+ * The number of available GPIOs should be non-zero, and no
+ * more than the total number of GPIOS.
+ */
+ if (!ret || ret > num_gpios) {
+ dev_err(&pdev->dev, "invalid 'gpios' property\n");
+ return -ENODEV;
+ }
+ avail_gpios = ret;
+
+ gpios = devm_kmalloc_array(&pdev->dev, avail_gpios,
+ sizeof(gpios[0]), GFP_KERNEL);
+ if (!gpios)
+ return -ENOMEM;
+
+ ret = device_property_read_u16_array(&pdev->dev, "gpios", gpios,
+ avail_gpios);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "could not read list of GPIOs\n");
+ return ret;
+ }
+ }
+
pins = devm_kcalloc(&pdev->dev, num_gpios,
sizeof(struct pinctrl_pin_desc), GFP_KERNEL);
groups = devm_kcalloc(&pdev->dev, num_gpios,
sizeof(struct msm_pingroup), GFP_KERNEL);
- names = devm_kcalloc(&pdev->dev, num_gpios, NAME_SIZE, GFP_KERNEL);
+ names = devm_kcalloc(&pdev->dev, avail_gpios, NAME_SIZE, GFP_KERNEL);
if (!pins || !groups || !names)
return -ENOMEM;
+ /*
+ * Initialize the array. GPIOs not listed in the 'gpios' array
+ * still need a number, but nothing else.
+ */
for (i = 0; i < num_gpios; i++) {
- snprintf(names[i], NAME_SIZE, "gpio%u", i);
-
pins[i].number = i;
- pins[i].name = names[i];
-
- groups[i].npins = 1;
- groups[i].name = names[i];
groups[i].pins = &pins[i].number;
+ }
- groups[i].ctl_reg = 0x10000 * i;
- groups[i].io_reg = 0x04 + 0x10000 * i;
- groups[i].intr_cfg_reg = 0x08 + 0x10000 * i;
- groups[i].intr_status_reg = 0x0c + 0x10000 * i;
- groups[i].intr_target_reg = 0x08 + 0x10000 * i;
-
- groups[i].mux_bit = 2;
- groups[i].pull_bit = 0;
- groups[i].drv_bit = 6;
- groups[i].oe_bit = 9;
- groups[i].in_bit = 0;
- groups[i].out_bit = 1;
- groups[i].intr_enable_bit = 0;
- groups[i].intr_status_bit = 0;
- groups[i].intr_target_bit = 5;
- groups[i].intr_target_kpss_val = 1;
- groups[i].intr_raw_status_bit = 4;
- groups[i].intr_polarity_bit = 1;
- groups[i].intr_detection_bit = 2;
- groups[i].intr_detection_width = 2;
+ /* Populate the entries that are meant to be exposes as GPIOs. */
+ for (i = 0; i < avail_gpios; i++) {
+ unsigned int gpio = gpios[i];
+
+ groups[gpio].npins = 1;
+ snprintf(names[i], NAME_SIZE, "gpio%u", gpio);
+ pins[gpio].name = names[i];
+ groups[gpio].name = names[i];
+
+ groups[gpio].ctl_reg = 0x10000 * gpio;
+ groups[gpio].io_reg = 0x04 + 0x10000 * gpio;
+ groups[gpio].intr_cfg_reg = 0x08 + 0x10000 * gpio;
+ groups[gpio].intr_status_reg = 0x0c + 0x10000 * gpio;
+ groups[gpio].intr_target_reg = 0x08 + 0x10000 * gpio;
+
+ groups[gpio].mux_bit = 2;
+ groups[gpio].pull_bit = 0;
+ groups[gpio].drv_bit = 6;
+ groups[gpio].oe_bit = 9;
+ groups[gpio].in_bit = 0;
+ groups[gpio].out_bit = 1;
+ groups[gpio].intr_enable_bit = 0;
+ groups[gpio].intr_status_bit = 0;
+ groups[gpio].intr_target_bit = 5;
+ groups[gpio].intr_target_kpss_val = 1;
+ groups[gpio].intr_raw_status_bit = 4;
+ groups[gpio].intr_polarity_bit = 1;
+ groups[gpio].intr_detection_bit = 2;
+ groups[gpio].intr_detection_width = 2;
}
+ devm_kfree(&pdev->dev, gpios);
+
qdf2xxx_pinctrl.pins = pins;
qdf2xxx_pinctrl.groups = groups;
qdf2xxx_pinctrl.npins = num_gpios;
@@ -109,12 +186,6 @@ static int qdf2xxx_pinctrl_probe(struct platform_device *pdev)
return msm_pinctrl_probe(pdev, &qdf2xxx_pinctrl);
}
-static const struct acpi_device_id qdf2xxx_acpi_ids[] = {
- {"QCOM8001"},
- {},
-};
-MODULE_DEVICE_TABLE(acpi, qdf2xxx_acpi_ids);
-
static struct platform_driver qdf2xxx_pinctrl_driver = {
.driver = {
.name = "qdf2xxx-pinctrl",
--
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 related
* [PATCH v4 09/12] clk: qcom: Add Krait clock controller driver
From: Rob Herring @ 2017-12-12 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512726150-7204-10-git-send-email-sricharan@codeaurora.org>
On Fri, Dec 08, 2017 at 03:12:27PM +0530, Sricharan R wrote:
> From: Stephen Boyd <sboyd@codeaurora.org>
>
> The Krait CPU clocks are made up of a primary mux and secondary
> mux for each CPU and the L2, controlled via cp15 accessors. For
> Kraits within KPSSv1 each secondary mux accepts a different aux
> source, but on KPSSv2 each secondary mux accepts the same aux
> source.
>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> .../devicetree/bindings/clock/qcom,krait-cc.txt | 22 ++
Please make bindings a separate patch.
> drivers/clk/qcom/Kconfig | 8 +
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/krait-cc.c | 350 +++++++++++++++++++++
> 4 files changed, 381 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/qcom,krait-cc.txt
> create mode 100644 drivers/clk/qcom/krait-cc.c
^ permalink raw reply
* [PATCH v3 1/8] SOC: brcmstb: add memory API
From: Jim Quinlan @ 2017-12-12 20:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205205926.GJ23510@bhelgaas-glaptop.roam.corp.google.com>
On Tue, Dec 5, 2017 at 3:59 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Tue, Nov 14, 2017 at 05:12:05PM -0500, Jim Quinlan wrote:
>> From: Florian Fainelli <f.fainelli@gmail.com>
>>
>> This commit adds a memory API suitable for ascertaining the sizes of
>> each of the N memory controllers in a Broadcom STB chip. Its first
>> user will be the Broadcom STB PCIe root complex driver, which needs
>> to know these sizes to properly set up DMA mappings for inbound
>> regions.
>>
>> We cannot use memblock here or anything like what Linux provides
>> because it collapses adjacent regions within a larger block, and here
>> we actually need per-memory controller addresses and sizes, which is
>> why we resort to manual DT parsing.
>>
>> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>> ---
>> drivers/soc/bcm/brcmstb/Makefile | 2 +-
>> drivers/soc/bcm/brcmstb/memory.c | 172 +++++++++++++++++++++++++++++++++++++++
>> include/soc/brcmstb/memory_api.h | 25 ++++++
>> 3 files changed, 198 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/soc/bcm/brcmstb/memory.c
>> create mode 100644 include/soc/brcmstb/memory_api.h
>>
>> diff --git a/drivers/soc/bcm/brcmstb/Makefile b/drivers/soc/bcm/brcmstb/Makefile
>> index 9120b27..4cea7b6 100644
>> --- a/drivers/soc/bcm/brcmstb/Makefile
>> +++ b/drivers/soc/bcm/brcmstb/Makefile
>> @@ -1 +1 @@
>> -obj-y += common.o biuctrl.o
>> +obj-y += common.o biuctrl.o memory.o
>> diff --git a/drivers/soc/bcm/brcmstb/memory.c b/drivers/soc/bcm/brcmstb/memory.c
>> new file mode 100644
>> index 0000000..eb647ad9
>> --- /dev/null
>> +++ b/drivers/soc/bcm/brcmstb/memory.c
>
> I sort of assume based on [1] that every new file should have an SPDX
> identifier ("The Linux kernel requires the precise SPDX identifier in
> all source files") and that the actual text of the GPL can be omitted.
>
> Only a few files in drivers/pci currently have an SPDX identifier. I
> don't know if that's oversight or work-in-progress or what.
>
> [1] https://lkml.kernel.org/r/20171204212120.484179273 at linutronix.de
>
Bjorn, Did you get a chance to review the other commits of this
submission (V3)? I would like any additional feedback before I send
out a V4 with SPDX fixes. Thanks, JimQ
>> @@ -0,0 +1,172 @@
>> +/*
>> + * Copyright ? 2015-2017 Broadcom
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * A copy of the GPL is available at
>> + * http://www.broadcom.com/licenses/GPLv2.php or from the Free Software
>> + * Foundation at https://www.gnu.org/licenses/ .
^ permalink raw reply
* arm64: unhandled level 0 translation fault
From: Geert Uytterhoeven @ 2017-12-12 20:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212165728.GC15783@arm.com>
Hi Will,
On Tue, Dec 12, 2017 at 5:57 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, Dec 12, 2017 at 05:00:33PM +0100, Geert Uytterhoeven wrote:
>> On Tue, Dec 12, 2017 at 4:11 PM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>> > On Tue, Dec 12, 2017 at 11:36 AM, Will Deacon <will.deacon@arm.com> wrote:
>> >> On Tue, Dec 12, 2017 at 11:20:09AM +0100, Geert Uytterhoeven wrote:
>> >>> During userspace (Debian jessie NFS root) boot on arm64:
>> >>>
>> >>> rpcbind[1083]: unhandled level 0 translation fault (11) at 0x00000008,
>> >>> esr 0x92000004, in dash[aaaaadf77000+1a000]
>> >>> CPU: 0 PID: 1083 Comm: rpcbind Not tainted
>> >>> 4.15.0-rc3-arm64-renesas-02176-g14f9a1826e48e355 #51
>> >>> Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+ (DT)
>> >>> pstate: 80000000 (Nzcv daif -PAN -UAO)
>> >>> pc : 0xaaaaadf8a51c
>> >>> lr : 0xaaaaadf8ac08
>> >>> sp : 0000ffffcffeac00
>> >>> x29: 0000ffffcffeac00 x28: 0000aaaaadfa1000
>> >>> x27: 0000ffffcffebf7c x26: 0000ffffcffead20
>> >>> x25: 0000aaaacea1c5f0 x24: 0000000000000000
>> >>> x23: 0000aaaaadfa1000 x22: 0000aaaaadfa1000
>> >>> x21: 0000000000000000 x20: 0000000000000008
>> >>> x19: 0000000000000000 x18: 0000ffffcffeb500
>> >>> x17: 0000ffffa22babfc x16: 0000aaaaadfa1ae8
>> >>> x15: 0000ffffa2363588 x14: ffffffffffffffff
>> >>> x13: 0000000000000020 x12: 0000000000000010
>> >>> x11: 0101010101010101 x10: 0000aaaaadfa1000
>> >>> x9 : 00000000ffffff81 x8 : 0000aaaaadfa2000
>> >>> x7 : 0000000000000000 x6 : 0000000000000000
>> >>> x5 : 0000aaaaadfa2338 x4 : 0000aaaaadfa2000
>> >>> x3 : 0000aaaaadfa2338 x2 : 0000000000000000
>> >>> x1 : 0000aaaaadfa28b0 x0 : 0000aaaaadfa4c30
>> >>>
>> >>> Sometimes it happens with other processes, but the main address, esr, and
>> >>> pstate values are always the same.
>> >>>
>> >>> I regularly run arm64/for-next/core (through bi-weekly renesas-drivers
>> >>> releases, so the last time was two weeks ago), but never saw the issue
>> >>> before until today, so probably v4.15-rc1 is OK.
>> >>> Unfortunately it doesn't happen during every boot, which makes it
>> >>> cumbersome to bisect.
>> >>>
>> >>> My first guess was UNMAP_KERNEL_AT_EL0, but even after disabling that,
>> >>> and even without today's arm64/for-next/core merged in, I still managed to
>> >>> reproduce the issue, so I believe it was introduced in v4.15-rc2 or
>> >>> v4.15-rc3.
>> >>
>> >> Urgh, this looks nasty. Thanks for the report! A few questions:
>> >>
>> >> - Can you share your .config somewhere please?
>> >
>> > I managed to reproduce it on plain v4.15-rc3 using both arm64_defconfig, and
>> > renesas_defconfig (from Simon's repo).
>>
>> v4.15-rc2 is affected, too.
>
> Do you reckon you can bisect between -rc1 and -rc2? We've been unable to
> reproduce this on any of our systems, unfortunately.
I've tried, but ended up on an unrelated XFS merge commit. Probably I
marked a few commits good due to not seeing this heisenbug.
For reference, here's the bisect log.
Bad commits showed one or both of "unhandled level 0 translation fault" and
"invalid pointer". Good commits didn't show any during 6 tries.
git bisect start
# bad: [ae64f9bd1d3621b5e60d7363bc20afb46aede215] Linux 4.15-rc2
git bisect bad ae64f9bd1d3621b5e60d7363bc20afb46aede215
# good: [4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323] Linux 4.15-rc1
git bisect good 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323
# good: [9e0600f5cf6cecfcab5046d1453a9538c054d8a7] Merge tag
'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
git bisect good 9e0600f5cf6cecfcab5046d1453a9538c054d8a7
# good: [503505bfea19b7d69e2572297e6defa0f9c2404e] Merge branch
'drm-fixes-4.15' of git://people.freedesktop.org/~agd5f/linux into
drm-fixes
git bisect good 503505bfea19b7d69e2572297e6defa0f9c2404e
# good: [ae753ee2771a1bacade56411bb98037b2545c929] Merge tag
'afs-fixes-20171201' of
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs
git bisect good ae753ee2771a1bacade56411bb98037b2545c929
# good: [e1ba1c99dad92c5917b22b1047cf36e4426b124a] Merge tag
'riscv-for-linus-4.15-rc2_cleanups' of
git://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux
git bisect good e1ba1c99dad92c5917b22b1047cf36e4426b124a
# bad: [2db767d9889cef087149a5eaa35c1497671fa40f] Merge tag
'nfs-for-4.15-2' of git://git.linux-nfs.org/projects/anna/linux-nfs
git bisect bad 2db767d9889cef087149a5eaa35c1497671fa40f
# good: [22a6c83777ac7c17d6c63891beeeac24cf5da450] xfs: ubsan fixes
git bisect good 22a6c83777ac7c17d6c63891beeeac24cf5da450
# bad: [788c1da05b73aee68ed98f05b577c308351f5619] Merge tag
'xfs-4.15-fixes-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
git bisect bad 788c1da05b73aee68ed98f05b577c308351f5619
# good: [3b42d385753c22b29d259ccb9d4c3f419e583b30] xfs: scrub inode
mode properly
git bisect good 3b42d385753c22b29d259ccb9d4c3f419e583b30
# good: [373b0589dc8d58bc09c9a28d03611ae4fb216057] xfs: Properly retry
failed dquot items in case of error during buffer writeback
git bisect good 373b0589dc8d58bc09c9a28d03611ae4fb216057
# first bad commit: [788c1da05b73aee68ed98f05b577c308351f5619] Merge
tag 'xfs-4.15-fixes-4' of
git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
Tomorrow there's another day in bisection paradise...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 1/1] dt-bindings: arm: document supported STM32 SoC family
From: Rob Herring @ 2017-12-12 21:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512741394-27341-1-git-send-email-ludovic.Barre@st.com>
On Fri, Dec 08, 2017 at 02:56:34PM +0100, Ludovic Barre wrote:
> From: Ludovic Barre <ludovic.barre@st.com>
>
> This adds a list of supported STM32 SoC bindings.
>
> Signed-off-by: Gwenael Treuveur <gwenael.treuveur@st.com>
> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> ---
> Documentation/devicetree/bindings/arm/stm32.txt | 9 +++++++++
> 1 file changed, 9 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/stm32.txt
Applied, thanks.
Rob
^ permalink raw reply
* WARNING: suspicious RCU usage
From: Fabio Estevam @ 2017-12-12 21:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212195435.GF10595@n2100.armlinux.org.uk>
Hi Russell,
On Tue, Dec 12, 2017 at 5:54 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> Which is exactly what I would expect with imx6. Just because it
> works for imx6 does not mean it works for everyone.
Sure, I trust your judgement.
You asked me to test with CONFIG_BL_SWITCHER=y and that's what I did
and reported back.
^ permalink raw reply
* [PATCH v3 1/8] SOC: brcmstb: add memory API
From: Bjorn Helgaas @ 2017-12-12 21:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANCKTBvoXpF-H8Pck5TsH+7tNM=di1-uoedqACE+kjNEAUodYg@mail.gmail.com>
[+cc Lorenzo]
On Tue, Dec 12, 2017 at 03:53:28PM -0500, Jim Quinlan wrote:
> On Tue, Dec 5, 2017 at 3:59 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Tue, Nov 14, 2017 at 05:12:05PM -0500, Jim Quinlan wrote:
> >> From: Florian Fainelli <f.fainelli@gmail.com>
> >>
> >> This commit adds a memory API suitable for ascertaining the sizes of
> >> each of the N memory controllers in a Broadcom STB chip. Its first
> >> user will be the Broadcom STB PCIe root complex driver, which needs
> >> to know these sizes to properly set up DMA mappings for inbound
> >> regions.
> >>
> >> We cannot use memblock here or anything like what Linux provides
> >> because it collapses adjacent regions within a larger block, and here
> >> we actually need per-memory controller addresses and sizes, which is
> >> why we resort to manual DT parsing.
> >>
> >> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
> >> ---
> >> drivers/soc/bcm/brcmstb/Makefile | 2 +-
> >> drivers/soc/bcm/brcmstb/memory.c | 172 +++++++++++++++++++++++++++++++++++++++
> >> include/soc/brcmstb/memory_api.h | 25 ++++++
> >> 3 files changed, 198 insertions(+), 1 deletion(-)
> >> create mode 100644 drivers/soc/bcm/brcmstb/memory.c
> >> create mode 100644 include/soc/brcmstb/memory_api.h
> >>
> >> diff --git a/drivers/soc/bcm/brcmstb/Makefile b/drivers/soc/bcm/brcmstb/Makefile
> >> index 9120b27..4cea7b6 100644
> >> --- a/drivers/soc/bcm/brcmstb/Makefile
> >> +++ b/drivers/soc/bcm/brcmstb/Makefile
> >> @@ -1 +1 @@
> >> -obj-y += common.o biuctrl.o
> >> +obj-y += common.o biuctrl.o memory.o
> >> diff --git a/drivers/soc/bcm/brcmstb/memory.c b/drivers/soc/bcm/brcmstb/memory.c
> >> new file mode 100644
> >> index 0000000..eb647ad9
> >> --- /dev/null
> >> +++ b/drivers/soc/bcm/brcmstb/memory.c
> >
> > I sort of assume based on [1] that every new file should have an SPDX
> > identifier ("The Linux kernel requires the precise SPDX identifier in
> > all source files") and that the actual text of the GPL can be omitted.
> >
> > Only a few files in drivers/pci currently have an SPDX identifier. I
> > don't know if that's oversight or work-in-progress or what.
> >
> > [1] https://lkml.kernel.org/r/20171204212120.484179273 at linutronix.de
> >
>
> Bjorn, Did you get a chance to review the other commits of this
> submission (V3)? I would like any additional feedback before I send
> out a V4 with SPDX fixes. Thanks, JimQ
Lorenzo is taking over drivers/pci/host/* and he'll no doubt have some
comments when he gets to this. I'll point out a few quick formatting
things in the meantime.
> >> @@ -0,0 +1,172 @@
> >> +/*
> >> + * Copyright ? 2015-2017 Broadcom
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License version 2 as
> >> + * published by the Free Software Foundation.
> >> + *
> >> + * This program is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> >> + * GNU General Public License for more details.
> >> + *
> >> + * A copy of the GPL is available at
> >> + * http://www.broadcom.com/licenses/GPLv2.php or from the Free Software
> >> + * Foundation at https://www.gnu.org/licenses/ .
^ permalink raw reply
* [linux-sunxi] [PATCH v2 3/6] ARM: sun4i: Convert to CCU
From: Kevin Hilman @ 2017-12-12 21:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212172635.2utwz3koyo5iwglt@plaes.org>
On Tue, Dec 12, 2017 at 9:26 AM, Priit Laes <plaes@plaes.org> wrote:
> On Mon, Dec 11, 2017 at 02:22:30PM -0800, Kevin Hilman wrote:
>> On Sun, Mar 26, 2017 at 10:20 AM, Priit Laes <plaes@plaes.org> wrote:
>> > Convert sun4i-a10.dtsi to new CCU driver.
>> >
>> > Signed-off-by: Priit Laes <plaes@plaes.org>
>>
>> I finally got around to bisecting a mainline boot failure on
>> sun4i-a10-cubieboard that's been happening for quite a while. Based
>> on on kernelci.org, it showed up sometime during the v4.15 merge
>> window[1]. It bisected down to this commit (in mainline as commit
>> 41193869f2bdb585ce09bfdd16d9482aadd560ad).
>>
>> When it fails, there is no output on the serial console, so I don't
>> know exactly how it's failing, just that it no longer boots.
>
> We tried out latest 4.15 with various compilers and it works:
> - gcc version 7.1.1 20170622 (Red Hat Cross 7.1.1-3) (GCC) - A10 Gemei G9 tablet
> - gcc 7.2.0-debian - A10 Cubieboard
And you can reproduce the bug with gcc5 or gcc6?
Very strange that a DT only patch would cause a gcc related regression
and if it does, it should be investigated. I don't think requiring
gcc7 is an appropriate solution.
@Chen-Yu, @Maxime: are you guys OK with requiring gcc7 for working
upstream boot for A10?
Kevin
^ permalink raw reply
* [PATCH] ARM: exynos_defconfig - enable CONFIG_EXYNOS_IOMMU
From: Shuah Khan @ 2017-12-12 21:31 UTC (permalink / raw)
To: linux-arm-kernel
EXYNOS_IOMMU is disabled in exynos_defconfig since it is known to cause
boot failures on Exynos Chrome-books. The recommendation is for IOMMU to
be enabled manually on systems as needed.
A recent exynos_drm change added a warning message when EXYNOS_IOMMU is
disabled. It is necessary to enable it to avoid the warning messages.
A few initial tests have shown that enabling EXYNOS_IOMMU might be safe
on Exynos Chrome-books.
Enable CONFIG_EXYNOS_IOMMU in exynos_defconfig.
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
---
arch/arm/configs/exynos_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
index f1d7834..0ccd5eb 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -281,6 +281,7 @@ CONFIG_DEVFREQ_GOV_POWERSAVE=y
CONFIG_DEVFREQ_GOV_USERSPACE=y
CONFIG_ARM_EXYNOS_BUS_DEVFREQ=y
CONFIG_DEVFREQ_EVENT_EXYNOS_NOCP=y
+CONFIG_EXYNOS_IOMMU=y
CONFIG_EXTCON=y
CONFIG_EXTCON_MAX14577=y
CONFIG_EXTCON_MAX77693=y
--
2.7.4
^ permalink raw reply related
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: Bhupesh Sharma @ 2017-12-12 21:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9oda1Ee8AoXsCEw+Bjn-XF3wZA_CsxvqhjtT6_bmJ7uA@mail.gmail.com>
Hi Ard, Akashi
On Mon, Dec 4, 2017 at 7:32 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 26 November 2017 at 08:29, Bhupesh SHARMA <bhupesh.linux@gmail.com> wrote:
>> Hi Akashi,
>>
>> On Thu, Nov 16, 2017 at 12:30 PM, AKASHI Takahiro
>> <takahiro.akashi@linaro.org> wrote:
>>> Bhupesh,
>>>
>>> On Wed, Nov 15, 2017 at 04:28:55PM +0530, Bhupesh Sharma wrote:
>>>>
>>> (snip)
>>>
>>>> # dmesg | grep -B 2 -i "ACPI reclaim"
>>>> [ 0.000000] efi: 0x000039670000-0x0000396bffff [Runtime Code |RUN| |
>>>> | | | | | |WB|WT|WC|UC]
>>>> [ 0.000000] efi: 0x0000396c0000-0x00003970ffff [Boot Code | | | |
>>>> | | | | |WB|WT|WC|UC]
>>>> [ 0.000000] efi: 0x000039710000-0x00003975ffff [ACPI Reclaim Memory|
>>>> | | | | | | | |WB|WT|WC|UC]
>>>>
>>>> 2. Now, I am not sure which kernel layer does the following changes (I am
>>>> still trying to dig it out more), but I see that the 'Boot Code' and ACPI
>>>> DSDT table regions are somehow merged into one memblock_region and appear as
>>>> range '396c0000-3975ffff' in the '/proc/iomem' interface:
>>>>
>>>> # cat /proc/iomem | grep -A 2 -B 2 39
>>>> 00000000-3961ffff : System RAM
>>>> 00080000-00b6ffff : Kernel code
>>>> 00cb0000-0167ffff : Kernel data
>>>> 0e800000-2e7fffff : Crash kernel
>>>> 39620000-396bffff : reserved
>>>> 396c0000-3975ffff : System RAM
>>>> 39760000-3976ffff : reserved
>>>> 39770000-397affff : reserved
>>>> 397b0000-3989ffff : reserved
>>>> 398a0000-398bffff : reserved
>>>> 398c0000-39d3ffff : reserved
>>>> 39d40000-3ed2ffff : System RAM
>>>>
>>> (snip)
>>>>
>>>> So, I am looking at what could be causing the 'Boot Code' and 'ACPI DSDT
>>>> table' ranges to be merged into a single region at
>>>> '0x0000396c0000-0x00003970ffff' which cannot be marked as RESERVED using
>>>> 'memblock_is_reserved'.
>>>
>>> Simple:) The short answer is that memblock_add() does.
>>>
>>> The long answer:
>>> First, please note that memblock maintains two type of regions list,
>>> "memory" and "reserved".
>>>
>>> efi_init()
>>> reserve_regions()
>>> early_init_dt_add_memory_arch()
>>> memblock_add()
>>> memblock_add_range(memblock.memory)
>>>
>>> The memory regions described in efi.memmap are added to "memory" list
>>> with all the neighboring regions being merged into ones,
>>> in this case, "Runtime Code", "Boot Code", "ACPI Reclaim Memory" and others.
>>>
>>> The secret here is that "Runtime Code" is also marked with "NOMAP" flag in
>>> reserve_regions(), which creates an isolated region since it now has
>>> a different attribute.
>>> Consequently only "Boot Code" and "ACPI Reclaim Memory" are
>>> unified.
>>>
>>> Look at request_standard_resources(). It handles only "memory" list,
>>> and doesn't care about whether any arbitrary part of memory is in
>>> "reserved" list or not.
>>
>> Thanks for the pointers. Now I did some experiments and traversed the
>> whole memblock path and I see
>> how these two regions get merged into a single region which is later
>> on recognized by
>> 'request_standard_resources()' as a System RAM region rather than a
>> RESERVED region.
>>
>> I recently reproduced this on a APM mustang with latest kernel as well
>> when acpi is used to boot the machine, which makes me believe that
>> this is a generic issue for arm64 machines with the 4.14 kernel and if
>> they use acpi=force as the boot method.
>>
>> I am not sure, if a fix/or hack would be suitable for all underlying
>> arm64 machines, but I am trying one on the arm64 machines I have to
>> see if it fixes the issue.
>>
>> @Ard:
>>
>> Hi Ard,
>>
>> I think to create and test a clean solution for all arm64 boards it
>> will take some time, in the meantime should we consider reverting the
>> commit [1] to make sure that acpi enabled arm64 machines can boot with
>> 4.14?
>>
>> Please let me know your opinion.
>>
>> [1] f56ab9a5b73ca2aee777ccdf2d355ae2dd31db5a (efi/arm: Don't mark
>> ACPI reclaim memory as MEMBLOCK_NOMAP)
>>
>
> I don't think that is really going to help tbh.
>
> ACPI reclaim regions are not the only regions that are
> memblock_reserve()d and need to be reserved by the incoming kernel as
> well. So as far as I can tell, this is a symptom of an underlying
> issue that we will need to solve, and reverting the code that exposed
> it will not make the bug go away.
>
Looking deeper into the issue, since the arm64 kexec-tools uses the
'linux,usable-memory-range' dt property to allow crash dump kernel to
identify its own usable memory and exclude, at its boot time, any
other memory areas that are part of the panicked kernel's memory.
(see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
, for details)
1). Now when 'kexec -p' is executed, this node is patched up only
with the crashkernel memory range:
/* add linux,usable-memory-range */
nodeoffset = fdt_path_offset(new_buf, "/chosen");
result = fdt_setprop_range(new_buf, nodeoffset,
PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
address_cells, size_cells);
(see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n465
, for details)
2). This excludes the ACPI reclaim regions irrespective of whether
they are marked as System RAM or as RESERVED. As,
'linux,usable-memory-range' dt node is patched up only with
'crash_reserved_mem' and not 'system_memory_ranges'
3). As a result when the crashkernel boots up it doesn't find this
ACPI memory and crashes while trying to access the same:
# kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
-r`.img --reuse-cmdline -d
[snip..]
Reserved memory range
000000000e800000-000000002e7fffff (0)
Coredump memory ranges
0000000000000000-000000000e7fffff (0)
000000002e800000-000000003961ffff (0)
0000000039d40000-000000003ed2ffff (0)
000000003ed60000-000000003fbfffff (0)
0000001040000000-0000001ffbffffff (0)
0000002000000000-0000002ffbffffff (0)
0000009000000000-0000009ffbffffff (0)
000000a000000000-000000affbffffff (0)
4). So if we revert Ard's patch or just comment the fixing up of the
memory cap'ing passed to the crash kernel inside
'arch/arm64/mm/init.c' (see below):
static void __init fdt_enforce_memory_region(void)
{
struct memblock_region reg = {
.size = 0,
};
of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
if (reg.size)
//memblock_cap_memory_range(reg.base, reg.size); /*
comment this out */
}
5). Both the above temporary solutions fix the problem.
6). However exposing all System RAM regions to the crashkernel is not
advisable and may cause the crashkernel or some crashkernel drivers to
fail.
6a). I am trying an approach now, where the ACPI reclaim regions are
added to '/proc/iomem' separately as ACPI reclaim regions by the
kernel code and on the other hand the user-space 'kexec-tools' will
pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
dt node 'linux,usable-memory-range'
6b). The kernel code currently looks like the following:
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 30ad2f085d1f..867bdec7c692 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -206,6 +206,7 @@ static void __init request_standard_resources(void)
{
struct memblock_region *region;
struct resource *res;
+ phys_addr_t addr_start, addr_end;
kernel_code.start = __pa_symbol(_text);
kernel_code.end = __pa_symbol(__init_begin - 1);
@@ -218,9 +219,17 @@ static void __init request_standard_resources(void)
res->name = "reserved";
res->flags = IORESOURCE_MEM;
} else {
- res->name = "System RAM";
- res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
+ addr_start =
__pfn_to_phys(memblock_region_reserved_base_pfn(region));
+ addr_end =
__pfn_to_phys(memblock_region_reserved_end_pfn(region)) - 1;
+ if ((efi_mem_type(addr_start) == EFI_ACPI_RECLAIM_MEMORY)
|| (efi_mem_type(addr_end) == EFI_ACPI_RECLAIM_MEMORY)) {
+ res->name = "ACPI reclaim region";
+ res->flags = IORESOURCE_MEM;
+ } else {
+ res->name = "System RAM";
+ res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
+ }
}
+
res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
@@ -292,6 +301,7 @@ void __init setup_arch(char **cmdline_p)
request_standard_resources();
+ efi_memmap_unmap();
early_ioremap_reset();
if (acpi_disabled)
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 80d1a885def5..a7c522eac640 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -259,7 +259,6 @@ void __init efi_init(void)
reserve_regions();
efi_esrt_init();
- efi_memmap_unmap();
memblock_reserve(params.mmap & PAGE_MASK,
PAGE_ALIGN(params.mmap_size +
After this change the ACPI reclaim regions are properly recognized in
'/proc/iomem':
# cat /proc/iomem | grep -i ACPI
396c0000-3975ffff : ACPI reclaim region
39770000-397affff : ACPI reclaim region
398a0000-398bffff : ACPI reclaim region
6c). I am currently changing the 'kexec-tools' and will finish the
testing over the next few days.
I just wanted to know your opinion on this issue, so that I will be
able to propose a fix on the above lines.
Also Cc'ing kexec mailing list for more inputs on changes proposed to
kexec-tools.
Thanks,
Bhupesh
^ permalink raw reply related
* [PATCH v3 3/8] PCI: brcmstb: Add Broadcom STB PCIe host controller driver
From: Bjorn Helgaas @ 2017-12-12 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1510697532-32828-4-git-send-email-jim2101024@gmail.com>
On Tue, Nov 14, 2017 at 05:12:07PM -0500, Jim Quinlan wrote:
> This commit adds the basic Broadcom STB PCIe controller. Missing is
> the ability to process MSI and also handle dma-ranges for inbound
> memory accesses. These two functionalities are added in subsequent
> commits.
>
> The PCIe block contains an MDIO interface. This is a local interface
> only accessible by the PCIe controller. It cannot be used or shared
> by any other HW. As such, the small amount of code for this
> controller is included in this driver as there is little upside to put
> it elsewhere.
>
> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
> ---
> drivers/pci/host/Kconfig | 9 +
> drivers/pci/host/Makefile | 1 +
> drivers/pci/host/pcie-brcmstb.c | 1124 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 1134 insertions(+)
> create mode 100644 drivers/pci/host/pcie-brcmstb.c
>
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index b868803..751463e 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -220,4 +220,13 @@ config VMD
> To compile this driver as a module, choose M here: the
> module will be called vmd.
>
> +config PCIE_BRCMSTB
> + tristate "Broadcom Brcmstb PCIe platform host driver"
> + depends on ARCH_BRCMSTB || BMIPS_GENERIC
> + depends on OF
> + depends on SOC_BRCMSTB
> + default ARCH_BRCMSTB || BMIPS_GENERIC
> + help
> + Adds support for Broadcom Settop Box PCIe host controller.
> +
> endmenu
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 1238278..a8b9923 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -21,6 +21,7 @@ obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
> obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
> obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
> obj-$(CONFIG_VMD) += vmd.o
> +obj-$(CONFIG_PCIE_BRCMSTB) += pcie-brcmstb.o
>
> # The following drivers are for devices that use the generic ACPI
> # pci_root.c driver but don't support standard ECAM config access.
> diff --git a/drivers/pci/host/pcie-brcmstb.c b/drivers/pci/host/pcie-brcmstb.c
> new file mode 100644
> index 0000000..d8a8f7a
> --- /dev/null
> +++ b/drivers/pci/host/pcie-brcmstb.c
> @@ -0,0 +1,1124 @@
> +/*
> + * Copyright (C) 2009 - 2017 Broadcom
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/compiler.h>
> +#include <linux/delay.h>
> +#include <linux/init.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/ioport.h>
> +#include <linux/irqdomain.h>
> +#include <linux/kernel.h>
> +#include <linux/list.h>
> +#include <linux/log2.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_pci.h>
> +#include <linux/of_pci.h>
> +#include <linux/of_platform.h>
> +#include <linux/pci.h>
> +#include <linux/printk.h>
> +#include <linux/sizes.h>
> +#include <linux/slab.h>
> +#include <soc/brcmstb/memory_api.h>
> +#include <linux/string.h>
> +#include <linux/types.h>
> +
> +/* BRCM_PCIE_CAP_REGS - Offset for the mandatory capability config regs */
> +#define BRCM_PCIE_CAP_REGS 0x00ac
Add a blank line before multi-line comments.
> +/*
> + * Broadcom Settop Box PCIE Register Offsets. The names are from
> + * the chip's RDB and we use them here so that a script can correlate
> + * this code and the RDB to prevent discrepancies.
Use "PCIe" capitalization in English text and messages.
> + */
> +#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1 0x0188
> +#define PCIE_RC_CFG_PRIV1_ID_VAL3 0x043c
> +#define PCIE_RC_DL_MDIO_ADDR 0x1100
> +#define PCIE_RC_DL_MDIO_WR_DATA 0x1104
> +#define PCIE_RC_DL_MDIO_RD_DATA 0x1108
> +#define PCIE_MISC_MISC_CTRL 0x4008
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO 0x400c
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI 0x4010
> +#define PCIE_MISC_RC_BAR1_CONFIG_LO 0x402c
> +#define PCIE_MISC_RC_BAR2_CONFIG_LO 0x4034
> +#define PCIE_MISC_RC_BAR2_CONFIG_HI 0x4038
> +#define PCIE_MISC_RC_BAR3_CONFIG_LO 0x403c
> +#define PCIE_MISC_PCIE_CTRL 0x4064
> +#define PCIE_MISC_PCIE_STATUS 0x4068
> +#define PCIE_MISC_REVISION 0x406c
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT 0x4070
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI 0x4080
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI 0x4084
> +#define PCIE_MISC_HARD_PCIE_HARD_DEBUG 0x4204
> +#define PCIE_INTR2_CPU_BASE 0x4300
> +
> +/*
> + * Broadcom Settop Box PCIE Register Field shift and mask info. The
> + * names are from the chip's RDB and we use them here so that a script
> + * can correlate this code and the RDB to prevent discrepancies.
> + */
> +#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR2_MASK 0xc
> +#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR2_SHIFT 0x2
> +#define PCIE_RC_CFG_PRIV1_ID_VAL3_CLASS_CODE_MASK 0xffffff
> +#define PCIE_RC_CFG_PRIV1_ID_VAL3_CLASS_CODE_SHIFT 0x0
> +#define PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_MASK 0x1000
> +#define PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_SHIFT 0xc
> +#define PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_MASK 0x2000
> +#define PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_SHIFT 0xd
> +#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_MASK 0x300000
> +#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_SHIFT 0x14
> +#define PCIE_MISC_MISC_CTRL_SCB0_SIZE_MASK 0xf8000000
> +#define PCIE_MISC_MISC_CTRL_SCB0_SIZE_SHIFT 0x1b
> +#define PCIE_MISC_MISC_CTRL_SCB1_SIZE_MASK 0x7c00000
> +#define PCIE_MISC_MISC_CTRL_SCB1_SIZE_SHIFT 0x16
> +#define PCIE_MISC_MISC_CTRL_SCB2_SIZE_MASK 0x1f
> +#define PCIE_MISC_MISC_CTRL_SCB2_SIZE_SHIFT 0x0
> +#define PCIE_MISC_RC_BAR1_CONFIG_LO_SIZE_MASK 0x1f
> +#define PCIE_MISC_RC_BAR1_CONFIG_LO_SIZE_SHIFT 0x0
> +#define PCIE_MISC_RC_BAR2_CONFIG_LO_SIZE_MASK 0x1f
> +#define PCIE_MISC_RC_BAR2_CONFIG_LO_SIZE_SHIFT 0x0
> +#define PCIE_MISC_RC_BAR3_CONFIG_LO_SIZE_MASK 0x1f
> +#define PCIE_MISC_RC_BAR3_CONFIG_LO_SIZE_SHIFT 0x0
> +#define PCIE_MISC_PCIE_CTRL_PCIE_PERSTB_MASK 0x4
> +#define PCIE_MISC_PCIE_CTRL_PCIE_PERSTB_SHIFT 0x2
> +#define PCIE_MISC_PCIE_CTRL_PCIE_L23_REQUEST_MASK 0x1
> +#define PCIE_MISC_PCIE_CTRL_PCIE_L23_REQUEST_SHIFT 0x0
> +#define PCIE_MISC_PCIE_STATUS_PCIE_PORT_MASK 0x80
> +#define PCIE_MISC_PCIE_STATUS_PCIE_PORT_SHIFT 0x7
> +#define PCIE_MISC_PCIE_STATUS_PCIE_DL_ACTIVE_MASK 0x20
> +#define PCIE_MISC_PCIE_STATUS_PCIE_DL_ACTIVE_SHIFT 0x5
> +#define PCIE_MISC_PCIE_STATUS_PCIE_PHYLINKUP_MASK 0x10
> +#define PCIE_MISC_PCIE_STATUS_PCIE_PHYLINKUP_SHIFT 0x4
> +#define PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_MASK 0x40
> +#define PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_SHIFT 0x6
> +#define PCIE_MISC_REVISION_MAJMIN_MASK 0xffff
> +#define PCIE_MISC_REVISION_MAJMIN_SHIFT 0
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_LIMIT_MASK 0xfff00000
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_LIMIT_SHIFT 0x14
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_BASE_MASK 0xfff0
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_BASE_SHIFT 0x4
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS 0xc
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI_BASE_MASK 0xff
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI_BASE_SHIFT 0x0
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI_LIMIT_MASK 0xff
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI_LIMIT_SHIFT 0x0
> +#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_MASK 0x2
> +#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_SHIFT 0x1
> +#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_MASK 0x08000000
> +#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_SHIFT 0x1b
> +#define PCIE_RGR1_SW_INIT_1_PERST_MASK 0x1
> +#define PCIE_RGR1_SW_INIT_1_PERST_SHIFT 0x0
> +
> +#define BRCM_NUM_PCIE_OUT_WINS 0x4
> +#define BRCM_MAX_SCB 0x4
> +
> +#define BRCM_MSI_TARGET_ADDR_LT_4GB 0x0fffffffcULL
> +#define BRCM_MSI_TARGET_ADDR_GT_4GB 0xffffffffcULL
> +
> +#define BURST_SIZE_128 0
> +#define BURST_SIZE_256 1
> +#define BURST_SIZE_512 2
> +
> +/* Offsets from PCIE_INTR2_CPU_BASE */
> +#define STATUS 0x0
> +#define SET 0x4
> +#define CLR 0x8
> +#define MASK_STATUS 0xc
> +#define MASK_SET 0x10
> +#define MASK_CLR 0x14
> +
> +#define PCIE_BUSNUM_SHIFT 20
> +#define PCIE_SLOT_SHIFT 15
> +#define PCIE_FUNC_SHIFT 12
> +
> +#if defined(__BIG_ENDIAN)
> +#define DATA_ENDIAN 2 /* PCIe->DDR inbound accesses */
> +#define MMIO_ENDIAN 2 /* CPU->PCIe outbound accesses */
> +#else
> +#define DATA_ENDIAN 0
> +#define MMIO_ENDIAN 0
> +#endif
> +
> +#define MDIO_PORT0 0x0
> +#define MDIO_DATA_MASK 0x7fffffff
> +#define MDIO_DATA_SHIFT 0x0
> +#define MDIO_PORT_MASK 0xf0000
> +#define MDIO_PORT_SHIFT 0x16
> +#define MDIO_REGAD_MASK 0xffff
> +#define MDIO_REGAD_SHIFT 0x0
> +#define MDIO_CMD_MASK 0xfff00000
> +#define MDIO_CMD_SHIFT 0x14
> +#define MDIO_CMD_READ 0x1
> +#define MDIO_CMD_WRITE 0x0
> +#define MDIO_DATA_DONE_MASK 0x80000000
> +#define MDIO_RD_DONE(x) (((x) & MDIO_DATA_DONE_MASK) ? 1 : 0)
> +#define MDIO_WT_DONE(x) (((x) & MDIO_DATA_DONE_MASK) ? 0 : 1)
> +#define SSC_REGS_ADDR 0x1100
> +#define SET_ADDR_OFFSET 0x1f
> +#define SSC_CNTL_OFFSET 0x2
> +#define SSC_CNTL_OVRD_EN_MASK 0x8000
> +#define SSC_CNTL_OVRD_EN_SHIFT 0xf
> +#define SSC_CNTL_OVRD_VAL_MASK 0x4000
> +#define SSC_CNTL_OVRD_VAL_SHIFT 0xe
> +#define SSC_STATUS_OFFSET 0x1
> +#define SSC_STATUS_SSC_MASK 0x400
> +#define SSC_STATUS_SSC_SHIFT 0xa
> +#define SSC_STATUS_PLL_LOCK_MASK 0x800
> +#define SSC_STATUS_PLL_LOCK_SHIFT 0xb
> +
> +#define IDX_ADDR(pcie) \
> + ((pcie)->reg_offsets[EXT_CFG_INDEX])
> +#define DATA_ADDR(pcie) \
> + ((pcie)->reg_offsets[EXT_CFG_DATA])
> +#define PCIE_RGR1_SW_INIT_1(pcie) \
> + ((pcie)->reg_offsets[RGR1_SW_INIT_1])
> +
> +enum {
> + RGR1_SW_INIT_1,
> + EXT_CFG_INDEX,
> + EXT_CFG_DATA,
> +};
> +
> +enum {
> + RGR1_SW_INIT_1_INIT_MASK,
> + RGR1_SW_INIT_1_INIT_SHIFT,
> + RGR1_SW_INIT_1_PERST_MASK,
> + RGR1_SW_INIT_1_PERST_SHIFT,
> +};
> +
> +enum pcie_type {
> + BCM7425,
> + BCM7435,
> + GENERIC,
> + BCM7278,
> +};
> +
> +struct brcm_window {
> + dma_addr_t pcie_addr;
> + phys_addr_t cpu_addr;
> + dma_addr_t size;
> +};
> +
> +/* Internal PCIe Host Controller Information.*/
> +struct brcm_pcie {
> + struct list_head list;
> + struct device *dev;
> + void __iomem *base;
> + struct list_head resources;
> + int irq;
> + struct clk *clk;
> + struct pci_bus *root_bus;
> + struct device_node *dn;
> + int id;
> + bool suspended;
> + int num_out_wins;
> + bool ssc;
> + int gen;
> + struct brcm_window out_wins[BRCM_NUM_PCIE_OUT_WINS];
> + unsigned int rev;
> + const int *reg_offsets;
> + const int *reg_field_info;
> + enum pcie_type type;
> +};
> +
> +struct pcie_cfg_data {
> + const int *reg_field_info;
> + const int *offsets;
> + const enum pcie_type type;
> +};
> +
> +static const int pcie_reg_field_info[] = {
> + [RGR1_SW_INIT_1_INIT_MASK] = 0x2,
> + [RGR1_SW_INIT_1_INIT_SHIFT] = 0x1,
> +};
> +
> +static const int pcie_reg_field_info_bcm7278[] = {
> + [RGR1_SW_INIT_1_INIT_MASK] = 0x1,
> + [RGR1_SW_INIT_1_INIT_SHIFT] = 0x0,
> +};
> +
> +static const int pcie_offset_bcm7425[] = {
> + [RGR1_SW_INIT_1] = 0x8010,
> + [EXT_CFG_INDEX] = 0x8300,
> + [EXT_CFG_DATA] = 0x8304,
> +};
> +
> +static const struct pcie_cfg_data bcm7425_cfg = {
> + .reg_field_info = pcie_reg_field_info,
> + .offsets = pcie_offset_bcm7425,
> + .type = BCM7425,
> +};
> +
> +static const int pcie_offsets[] = {
> + [RGR1_SW_INIT_1] = 0x9210,
> + [EXT_CFG_INDEX] = 0x9000,
> + [EXT_CFG_DATA] = 0x9004,
> +};
> +
> +static const struct pcie_cfg_data bcm7435_cfg = {
> + .reg_field_info = pcie_reg_field_info,
> + .offsets = pcie_offsets,
> + .type = BCM7435,
> +};
> +
> +static const struct pcie_cfg_data generic_cfg = {
> + .reg_field_info = pcie_reg_field_info,
> + .offsets = pcie_offsets,
> + .type = GENERIC,
> +};
> +
> +static const int pcie_offset_bcm7278[] = {
> + [RGR1_SW_INIT_1] = 0xc010,
> + [EXT_CFG_INDEX] = 0x9000,
> + [EXT_CFG_DATA] = 0x9004,
> +};
> +
> +static const struct pcie_cfg_data bcm7278_cfg = {
> + .reg_field_info = pcie_reg_field_info_bcm7278,
> + .offsets = pcie_offset_bcm7278,
> + .type = BCM7278,
> +};
> +
> +static void __iomem *brcm_pcie_map_conf(struct pci_bus *bus, unsigned int devfn,
> + int where);
> +
> +static struct pci_ops brcm_pcie_ops = {
> + .map_bus = brcm_pcie_map_conf,
> + .read = pci_generic_config_read,
> + .write = pci_generic_config_write,
> +};
> +
> +#if defined(CONFIG_MIPS)
> +/* Broadcom MIPs HW implicitly does the swapping if necessary */
> +#define bcm_readl(a) __raw_readl(a)
> +#define bcm_writel(d, a) __raw_writel(d, a)
> +#define bcm_readw(a) __raw_readw(a)
> +#define bcm_writew(d, a) __raw_writew(d, a)
> +#else
> +#define bcm_readl(a) readl(a)
> +#define bcm_writel(d, a) writel(d, a)
> +#define bcm_readw(a) readw(a)
> +#define bcm_writew(d, a) writew(d, a)
> +#endif
> +
> +/*
> + * These macros are designed to sxtract/insert fields to host controller's
> + * register set.
s/are designed to s/ e/ (I assume they actually *do* extract/insert)
> + */
> +#define RD_FLD(base, reg, field) \
> + rd_fld(base + reg, reg##_##field##_MASK, reg##_##field##_SHIFT)
> +#define WR_FLD(base, reg, field, val) \
> + wr_fld(base + reg, reg##_##field##_MASK, reg##_##field##_SHIFT, val)
> +#define WR_FLD_RB(base, reg, field, val) \
> + wr_fld_rb(base + reg, reg##_##field##_MASK, reg##_##field##_SHIFT, val)
> +#define WR_FLD_WITH_OFFSET(base, off, reg, field, val) \
> + wr_fld(base + reg + off, reg##_##field##_MASK, \
> + reg##_##field##_SHIFT, val)
> +#define EXTRACT_FIELD(val, reg, field) \
> + ((val & reg##_##field##_MASK) >> reg##_##field##_SHIFT)
> +#define INSERT_FIELD(val, reg, field, field_val) \
> + ((val & ~reg##_##field##_MASK) | \
> + (reg##_##field##_MASK & (field_val << reg##_##field##_SHIFT)))
> +
> +static struct list_head brcm_pcie = LIST_HEAD_INIT(brcm_pcie);
> +static phys_addr_t scb_size[BRCM_MAX_SCB];
> +static int num_memc;
> +static DEFINE_MUTEX(brcm_pcie_lock);
> +
> +static u32 rd_fld(void __iomem *p, u32 mask, int shift)
> +{
> + return (bcm_readl(p) & mask) >> shift;
> +}
> +
> +static void wr_fld(void __iomem *p, u32 mask, int shift, u32 val)
> +{
> + u32 reg = bcm_readl(p);
> +
> + reg = (reg & ~mask) | ((val << shift) & mask);
> + bcm_writel(reg, p);
> +}
> +
> +static void wr_fld_rb(void __iomem *p, u32 mask, int shift, u32 val)
> +{
> + wr_fld(p, mask, shift, val);
> + (void)bcm_readl(p);
> +}
> +
> +static const char *link_speed_to_str(int s)
> +{
> + switch (s) {
> + case 1:
> + return "2.5";
> + case 2:
> + return "5.0";
> + case 3:
> + return "8.0";
> + default:
> + break;
> + }
> + return "???";
> +}
> +
> +/*
> + * The roundup_pow_of_two() from log2.h invokes
> + * __roundup_pow_of_two(unsigned long), but we really need a
> + * such a function to take a native u64 since unsigned long
> + * is 32 bits on some configurations. So we provide this helper
> + * function below.
> + */
> +static u64 roundup_pow_of_two_64(u64 n)
> +{
> + return 1ULL << fls64(n - 1);
> +}
> +
> +/*
> + * This is to convert the size of the inbound bar region to the
> + * non-liniear values of PCIE_X_MISC_RC_BAR[123]_CONFIG_LO.SIZE
s/bar/BAR/ (This doesn't sound like a BAR in the PCI spec sense, but if
that's what you call it, might as well spell it as the acronym)
s/non-liniear/non-linear/
> + */
> +int encode_ibar_size(u64 size)
> +{
> + int log2_in = ilog2(size);
> +
> + if (log2_in >= 12 && log2_in <= 15)
> + /* Covers 4KB to 32KB (inclusive) */
> + return (log2_in - 12) + 0x1c;
> + else if (log2_in >= 16 && log2_in <= 37)
> + /* Covers 64KB to 32GB, (inclusive) */
> + return log2_in - 15;
> + /* Something is awry so disable */
> + return 0;
> +}
> +
> +static u32 mdio_form_pkt(int port, int regad, int cmd)
> +{
> + u32 pkt = 0;
> +
> + pkt |= (port << MDIO_PORT_SHIFT) & MDIO_PORT_MASK;
> + pkt |= (regad << MDIO_REGAD_SHIFT) & MDIO_REGAD_MASK;
> + pkt |= (cmd << MDIO_CMD_SHIFT) & MDIO_CMD_MASK;
> +
> + return pkt;
> +}
> +
> +/* negative return value indicates error */
> +static int mdio_read(void __iomem *base, u8 port, u8 regad)
> +{
> + int tries;
> + u32 data;
> +
> + bcm_writel(mdio_form_pkt(port, regad, MDIO_CMD_READ),
> + base + PCIE_RC_DL_MDIO_ADDR);
> + bcm_readl(base + PCIE_RC_DL_MDIO_ADDR);
> +
> + data = bcm_readl(base + PCIE_RC_DL_MDIO_RD_DATA);
> + for (tries = 0; !MDIO_RD_DONE(data) && tries < 10; tries++) {
> + udelay(10);
> + data = bcm_readl(base + PCIE_RC_DL_MDIO_RD_DATA);
> + }
> +
> + return MDIO_RD_DONE(data)
> + ? (data & MDIO_DATA_MASK) >> MDIO_DATA_SHIFT
> + : -EIO;
> +}
> +
> +/* negative return value indicates error */
> +static int mdio_write(void __iomem *base, u8 port, u8 regad, u16 wrdata)
> +{
> + int tries;
> + u32 data;
> +
> + bcm_writel(mdio_form_pkt(port, regad, MDIO_CMD_WRITE),
> + base + PCIE_RC_DL_MDIO_ADDR);
> + bcm_readl(base + PCIE_RC_DL_MDIO_ADDR);
> + bcm_writel(MDIO_DATA_DONE_MASK | wrdata,
> + base + PCIE_RC_DL_MDIO_WR_DATA);
> +
> + data = bcm_readl(base + PCIE_RC_DL_MDIO_WR_DATA);
> + for (tries = 0; !MDIO_WT_DONE(data) && tries < 10; tries++) {
> + udelay(10);
> + data = bcm_readl(base + PCIE_RC_DL_MDIO_WR_DATA);
> + }
> +
> + return MDIO_WT_DONE(data) ? 0 : -EIO;
> +}
> +
> +/* configures device for ssc mode; negative return value indicates error */
I guess "ssc" means Spread Spectrum Clocking? Maybe spell out the
first occurrence and spell as acronym in English text?
> +static int set_ssc(void __iomem *base)
> +{
> + int tmp;
> + u16 wrdata;
> + int pll, ssc;
> +
> + tmp = mdio_write(base, MDIO_PORT0, SET_ADDR_OFFSET, SSC_REGS_ADDR);
> + if (tmp < 0)
> + return tmp;
> +
> + tmp = mdio_read(base, MDIO_PORT0, SSC_CNTL_OFFSET);
> + if (tmp < 0)
> + return tmp;
> +
> + wrdata = INSERT_FIELD(tmp, SSC_CNTL_OVRD, EN, 1);
> + wrdata = INSERT_FIELD(wrdata, SSC_CNTL_OVRD, VAL, 1);
> + tmp = mdio_write(base, MDIO_PORT0, SSC_CNTL_OFFSET, wrdata);
> + if (tmp < 0)
> + return tmp;
> +
> + usleep_range(1000, 2000);
> + tmp = mdio_read(base, MDIO_PORT0, SSC_STATUS_OFFSET);
> + if (tmp < 0)
> + return tmp;
> +
> + ssc = EXTRACT_FIELD(tmp, SSC_STATUS, SSC);
> + pll = EXTRACT_FIELD(tmp, SSC_STATUS, PLL_LOCK);
> +
> + return (ssc && pll) ? 0 : -EIO;
> +}
> +
> +/* limits operation to a specific generation (1, 2, or 3) */
> +static void set_gen(void __iomem *base, int gen)
> +{
> + u32 lnkcap = bcm_readl(base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCAP);
> + u16 lnkctl2 = bcm_readw(base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCTL2);
> +
> + lnkcap = (lnkcap & ~PCI_EXP_LNKCAP_SLS) | gen;
> + bcm_writel(lnkcap, base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCAP);
> +
> + lnkctl2 = (lnkctl2 & ~0xf) | gen;
> + bcm_writew(lnkctl2, base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCTL2);
> +}
> +
> +static void brcm_pcie_set_outbound_win(struct brcm_pcie *pcie,
> + unsigned int win, phys_addr_t cpu_addr,
> + dma_addr_t pcie_addr, dma_addr_t size)
> +{
> + void __iomem *base = pcie->base;
> + phys_addr_t cpu_addr_mb, limit_addr_mb;
> + u32 tmp;
> +
> + /* Set the base of the pcie_addr window */
> + bcm_writel(lower_32_bits(pcie_addr) + MMIO_ENDIAN,
> + base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO + (win * 8));
> + bcm_writel(upper_32_bits(pcie_addr),
> + base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI + (win * 8));
> +
> + cpu_addr_mb = cpu_addr >> 20;
> + limit_addr_mb = (cpu_addr + size - 1) >> 20;
> +
> + /* Write the addr base low register */
> + WR_FLD_WITH_OFFSET(base, (win * 4),
> + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
> + BASE, cpu_addr_mb);
> + /* Write the addr limit low register */
> + WR_FLD_WITH_OFFSET(base, (win * 4),
> + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
> + LIMIT, limit_addr_mb);
> +
> + if (pcie->type != BCM7435 && pcie->type != BCM7425) {
> + /* Write the cpu addr high register */
> + tmp = (u32)(cpu_addr_mb >>
> + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS);
> + WR_FLD_WITH_OFFSET(base, (win * 8),
> + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI,
> + BASE, tmp);
> + /* Write the cpu limit high register */
> + tmp = (u32)(limit_addr_mb >>
> + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS);
> + WR_FLD_WITH_OFFSET(base, (win * 8),
> + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI,
> + LIMIT, tmp);
> + }
> +}
> +
> +/* Configuration space read/write support */
> +static int cfg_index(int busnr, int devfn, int reg)
> +{
> + return ((PCI_SLOT(devfn) & 0x1f) << PCIE_SLOT_SHIFT)
> + | ((PCI_FUNC(devfn) & 0x07) << PCIE_FUNC_SHIFT)
> + | (busnr << PCIE_BUSNUM_SHIFT)
> + | (reg & ~3);
> +}
> +
> +static bool brcm_pcie_rc_mode(struct brcm_pcie *pcie)
> +{
> + void __iomem *base = pcie->base;
> + u32 val = bcm_readl(base + PCIE_MISC_PCIE_STATUS);
> +
> + return !!EXTRACT_FIELD(val, PCIE_MISC_PCIE_STATUS, PCIE_PORT);
> +}
> +
> +static bool brcm_pcie_link_up(struct brcm_pcie *pcie)
> +{
> + void __iomem *base = pcie->base;
> + u32 val = bcm_readl(base + PCIE_MISC_PCIE_STATUS);
> + u32 dla = EXTRACT_FIELD(val, PCIE_MISC_PCIE_STATUS, PCIE_DL_ACTIVE);
> + u32 plu = EXTRACT_FIELD(val, PCIE_MISC_PCIE_STATUS, PCIE_PHYLINKUP);
> +
> + return (dla && plu) ? true : false;
> +}
> +
> +static bool brcm_pcie_valid_device(struct brcm_pcie *pcie, struct pci_bus *bus,
> + int dev)
> +{
> + if (pci_is_root_bus(bus)) {
> + if (dev > 0)
> + return false;
> + } else {
> + /* If there is no link, then there is no device */
> + if (!brcm_pcie_link_up(pcie))
> + return false;
This is racy, since the link can go down after you check but before
you do the config access. I assume your hardware can deal with a
config access that targets a link that is down?
> + }
> +
> + return true;
> +}
> +
> +static void __iomem *brcm_pcie_map_conf(struct pci_bus *bus, unsigned int devfn,
> + int where)
> +{
> + struct brcm_pcie *pcie = bus->sysdata;
> + void __iomem *base = pcie->base;
> + int idx;
> +
> + if (!brcm_pcie_valid_device(pcie, bus, PCI_SLOT(devfn)))
> + return NULL;
> +
> + /* Accesses to the RC go right to the RC registers */
> + if (pci_is_root_bus(bus))
> + return base + where;
> +
> + /* For devices, write to the config space index register */
> + idx = cfg_index(bus->number, devfn, where);
> + bcm_writel(idx, pcie->base + IDX_ADDR(pcie));
> + return base + DATA_ADDR(pcie) + (where & 0x3);
I guess this is protected by a higher-level config access lock?
> +}
> +
> +static inline void brcm_pcie_bridge_sw_init_set(struct brcm_pcie *pcie,
> + unsigned int val)
> +{
> + unsigned int offset;
> + unsigned int shift = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_SHIFT];
> + u32 mask = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_MASK];
> +
> + if (pcie->type != BCM7278) {
> + wr_fld_rb(pcie->base + PCIE_RGR1_SW_INIT_1(pcie), mask, shift,
> + val);
> + } else if (of_machine_is_compatible("brcm,bcm7278a0")) {
> + /*
> + * The two PCIe instances on 7278a0 are not even consistent with
> + * respect to each other for internal offsets, here we offset
> + * by 0x14000 + RGR1_SW_INIT_1's relative offset to account for
> + * that.
> + */
> + offset = pcie->id ? 0x14010 : pcie->reg_offsets[RGR1_SW_INIT_1];
> + wr_fld_rb(pcie->base + offset, mask, shift, val);
> + } else {
> + wr_fld_rb(pcie->base + PCIE_RGR1_SW_INIT_1(pcie), mask, shift,
> + val);
> + }
> +}
> +
> +static inline void brcm_pcie_perst_set(struct brcm_pcie *pcie,
> + unsigned int val)
> +{
> + if (pcie->type != BCM7278)
> + wr_fld_rb(pcie->base + PCIE_RGR1_SW_INIT_1(pcie),
> + PCIE_RGR1_SW_INIT_1_PERST_MASK,
> + PCIE_RGR1_SW_INIT_1_PERST_SHIFT, val);
> + else
> + /* Assert = 0, de-assert = 1 on 7278 */
> + WR_FLD_RB(pcie->base, PCIE_MISC_PCIE_CTRL, PCIE_PERSTB, !val);
> +}
> +
> +static int brcm_pcie_add_controller(struct brcm_pcie *pcie)
> +{
> + mutex_lock(&brcm_pcie_lock);
> + list_add_tail(&pcie->list, &brcm_pcie);
> + mutex_unlock(&brcm_pcie_lock);
> +
> + return 0;
> +}
> +
> +static void brcm_pcie_remove_controller(struct brcm_pcie *pcie)
> +{
> + struct list_head *pos, *q;
> + struct brcm_pcie *tmp;
> +
> + mutex_lock(&brcm_pcie_lock);
> + list_for_each_safe(pos, q, &brcm_pcie) {
> + tmp = list_entry(pos, struct brcm_pcie, list);
> + if (tmp == pcie) {
> + list_del(pos);
> + if (list_empty(&brcm_pcie))
> + num_memc = 0;
> + break;
> + }
> + }
> + mutex_unlock(&brcm_pcie_lock);
I'm missing something. I don't see that num_memc is ever set to
anything *other* than zero.
This pattern of keeping a list of controllers is highly unusual and
needs some explanation.
> +}
> +
> +static int brcm_pcie_parse_request_of_pci_ranges(struct brcm_pcie *pcie)
> +{
> + struct resource_entry *win;
> + int ret;
> +
> + ret = of_pci_get_host_bridge_resources(pcie->dn, 0, 0xff,
> + &pcie->resources, NULL);
> + if (ret) {
> + dev_err(pcie->dev, "failed to get host resources\n");
> + return ret;
> + }
> +
> + resource_list_for_each_entry(win, &pcie->resources) {
> + struct resource *parent, *res = win->res;
> + dma_addr_t offset = (dma_addr_t)win->offset;
> +
> + if (resource_type(res) == IORESOURCE_IO) {
> + parent = &ioport_resource;
> + } else if (resource_type(res) == IORESOURCE_MEM) {
> + if (pcie->num_out_wins >= BRCM_NUM_PCIE_OUT_WINS) {
> + dev_err(pcie->dev, "too many outbound wins\n");
> + return -EINVAL;
> + }
> + pcie->out_wins[pcie->num_out_wins].cpu_addr
> + = (phys_addr_t)res->start;
> + pcie->out_wins[pcie->num_out_wins].pcie_addr
> + = (dma_addr_t)(res->start
> + - (phys_addr_t)offset);
> + pcie->out_wins[pcie->num_out_wins].size
> + = (dma_addr_t)(res->end - res->start + 1);
> + pcie->num_out_wins++;
> + parent = &iomem_resource;
> + } else {
> + continue;
> + }
> +
> + ret = devm_request_resource(pcie->dev, parent, res);
> + if (ret) {
> + dev_err(pcie->dev, "failed to get res %pR\n", res);
> + return ret;
> + }
> + }
> + return 0;
> +}
> +
> +static int brcm_pcie_setup(struct brcm_pcie *pcie)
> +{
> + void __iomem *base = pcie->base;
> + unsigned int scb_size_val;
> + u64 rc_bar2_size = 0, rc_bar2_offset = 0, total_mem_size = 0;
Unnecessary initializations (at least of rc_bar2_size, I didn't check
the rest).
Add
struct device *dev = pcie->dev;
then use it below.
> + u32 tmp, burst;
> + int i, j, ret, limit;
> + u16 nlw, cls, lnksta;
> + bool ssc_good = false;
> +
> + /* reset the bridge and the endpoint device */
> + /* field: PCIE_BRIDGE_SW_INIT = 1 */
Not sure what these "field: ..." comments mean. Are they for some
automated tool? To a human, it looks like they repeat what the code
does.
> + brcm_pcie_bridge_sw_init_set(pcie, 1);
> +
> + /* field: PCIE_SW_PERST = 1, on 7278, we start de-asserted already */
> + if (pcie->type != BCM7278)
> + brcm_pcie_perst_set(pcie, 1);
> +
> + usleep_range(100, 200);
> +
> + /* take the bridge out of reset */
> + /* field: PCIE_BRIDGE_SW_INIT = 0 */
> + brcm_pcie_bridge_sw_init_set(pcie, 0);
> +
> + WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, SERDES_IDDQ, 0);
> + /* wait for serdes to be stable */
> + usleep_range(100, 200);
> +
> + /* Grab the PCIe hw revision number */
> + tmp = bcm_readl(base + PCIE_MISC_REVISION);
> + pcie->rev = EXTRACT_FIELD(tmp, PCIE_MISC_REVISION, MAJMIN);
> +
> + /* Set SCB_MAX_BURST_SIZE, CFG_READ_UR_MODE, SCB_ACCESS_EN */
> + tmp = INSERT_FIELD(0, PCIE_MISC_MISC_CTRL, SCB_ACCESS_EN, 1);
> + tmp = INSERT_FIELD(tmp, PCIE_MISC_MISC_CTRL, CFG_READ_UR_MODE, 1);
> + burst = (pcie->type == GENERIC || pcie->type == BCM7278)
> + ? BURST_SIZE_512 : BURST_SIZE_256;
> + tmp = INSERT_FIELD(tmp, PCIE_MISC_MISC_CTRL, MAX_BURST_SIZE, burst);
> + bcm_writel(tmp, base + PCIE_MISC_MISC_CTRL);
> +
> + /*
> + * Set up inbound memory view for the EP (called RC_BAR2,
> + * not to be confused with the BARs that are advertised by
> + * the EP).
> + */
> + for (i = 0; i < num_memc; i++)
> + total_mem_size += scb_size[i];
> +
> + /*
> + * The PCIe host controller by design must set the inbound
> + * viewport to be a contiguous arrangement of all of the
> + * system's memory. In addition, its size mut be a power of
> + * two. To further complicate matters, the viewport must
> + * start on a pcie-address that is aligned on a multiple of its
> + * size. If a portion of the viewport does not represent
> + * system memory -- e.g. 3GB of memory requires a 4GB viewport
> + * -- we can map the outbound memory in or after 3GB and even
> + * though the viewport will overlap the outbound memory the
> + * controller will know to send outbound memory downstream and
> + * everything else upstream.
> + */
> + rc_bar2_size = roundup_pow_of_two_64(total_mem_size);
> +
> + /*
> + * Set simple configuration based on memory sizes
> + * only. We always start the viewport at address 0.
> + */
> + rc_bar2_offset = 0;
> +
> + tmp = lower_32_bits(rc_bar2_offset);
> + tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
> + encode_ibar_size(rc_bar2_size));
> + bcm_writel(tmp, base + PCIE_MISC_RC_BAR2_CONFIG_LO);
> + bcm_writel(upper_32_bits(rc_bar2_offset),
> + base + PCIE_MISC_RC_BAR2_CONFIG_HI);
> +
> + /* field: SCB0_SIZE, default = 0xf (1 GB) */
> + scb_size_val = scb_size[0]
> + ? ilog2(scb_size[0]) - 15 : 0xf;
> + WR_FLD(base, PCIE_MISC_MISC_CTRL, SCB0_SIZE, scb_size_val);
> +
> + /* field: SCB1_SIZE, default = 0xf (1 GB) */
> + if (num_memc > 1) {
> + scb_size_val = scb_size[1]
> + ? ilog2(scb_size[1]) - 15 : 0xf;
> + WR_FLD(base, PCIE_MISC_MISC_CTRL, SCB1_SIZE, scb_size_val);
> + }
> +
> + /* field: SCB2_SIZE, default = 0xf (1 GB) */
> + if (num_memc > 2) {
> + scb_size_val = scb_size[2]
> + ? ilog2(scb_size[2]) - 15 : 0xf;
> + WR_FLD(base, PCIE_MISC_MISC_CTRL, SCB2_SIZE, scb_size_val);
> + }
> +
> + /* disable the PCIe->GISB memory window (RC_BAR1) */
> + WR_FLD(base, PCIE_MISC_RC_BAR1_CONFIG_LO, SIZE, 0);
> +
> + /* disable the PCIe->SCB memory window (RC_BAR3) */
> + WR_FLD(base, PCIE_MISC_RC_BAR3_CONFIG_LO, SIZE, 0);
> +
> + if (!pcie->suspended) {
> + /* clear any interrupts we find on boot */
> + bcm_writel(0xffffffff, base + PCIE_INTR2_CPU_BASE + CLR);
> + (void)bcm_readl(base + PCIE_INTR2_CPU_BASE + CLR);
> + }
> +
> + /* Mask all interrupts since we are not handling any yet */
> + bcm_writel(0xffffffff, base + PCIE_INTR2_CPU_BASE + MASK_SET);
> + (void)bcm_readl(base + PCIE_INTR2_CPU_BASE + MASK_SET);
> +
> + if (pcie->gen)
> + set_gen(base, pcie->gen);
> +
> + /* take the EP device out of reset */
> + /* field: PCIE_SW_PERST = 0 */
> + brcm_pcie_perst_set(pcie, 0);
<raises eyebrows> Take the *EP* out of reset? The host controller
driver shouldn't be touching an EP directly. Maybe the comment
doesn't match what the code actually does.
> +
> + /*
> + * Give the RC/EP time to wake up, before trying to configure RC.
> + * Intermittently check status for link-up, up to a total of 100ms
> + * when we don't know if the device is there, and up to 1000ms if
> + * we do know the device is there.
> + */
> + limit = pcie->suspended ? 1000 : 100;
> + for (i = 1, j = 0; j < limit && !brcm_pcie_link_up(pcie);
> + j += i, i = i * 2)
> + msleep(i + j > limit ? limit - j : i);
> +
> + if (!brcm_pcie_link_up(pcie)) {
> + dev_info(pcie->dev, "link down\n");
> + return -ENODEV;
> + }
> +
> + if (!brcm_pcie_rc_mode(pcie)) {
> + dev_err(pcie->dev, "PCIe misconfigured; is in EP mode\n");
> + return -EINVAL;
> + }
> +
> + for (i = 0; i < pcie->num_out_wins; i++)
> + brcm_pcie_set_outbound_win(pcie, i, pcie->out_wins[i].cpu_addr,
> + pcie->out_wins[i].pcie_addr,
> + pcie->out_wins[i].size);
> +
> + /*
> + * For config space accesses on the RC, show the right class for
> + * a PCIe-PCIe bridge (the default setting is to be EP mode).
> + */
> + WR_FLD_RB(base, PCIE_RC_CFG_PRIV1_ID_VAL3, CLASS_CODE, 0x060400);
> +
> + if (pcie->ssc) {
> + ret = set_ssc(base);
> + if (ret == 0)
> + ssc_good = true;
> + else
> + dev_err(pcie->dev,
> + "failed attempt to enter ssc mode\n");
> + }
> +
> + lnksta = bcm_readw(base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKSTA);
> + cls = lnksta & PCI_EXP_LNKSTA_CLS;
> + nlw = (lnksta & PCI_EXP_LNKSTA_NLW) >> PCI_EXP_LNKSTA_NLW_SHIFT;
> + dev_info(pcie->dev, "link up, %s Gbps x%u %s\n", link_speed_to_str(cls),
> + nlw, ssc_good ? "(SSC)" : "(!SSC)");
> +
> + /* PCIe->SCB endian mode for BAR */
> + /* field ENDIAN_MODE_BAR2 = DATA_ENDIAN */
> + WR_FLD_RB(base, PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1,
> + ENDIAN_MODE_BAR2, DATA_ENDIAN);
> +
> + /*
> + * Refclk from RC should be gated with CLKREQ# input when ASPM L0s,L1
> + * is enabled => setting the CLKREQ_DEBUG_ENABLE field to 1.
> + */
> + WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, CLKREQ_DEBUG_ENABLE, 1);
> +
> + return 0;
> +}
> +
> +static void enter_l23(struct brcm_pcie *pcie)
> +{
> + void __iomem *base = pcie->base;
> + int tries, l23;
> +
> + /* assert request for L23 */
> + WR_FLD_RB(base, PCIE_MISC_PCIE_CTRL, PCIE_L23_REQUEST, 1);
> + /* poll L23 status */
> + for (tries = 0, l23 = 0; tries < 1000 && !l23; tries++)
> + l23 = RD_FLD(base, PCIE_MISC_PCIE_STATUS, PCIE_LINK_IN_L23);
> + if (!l23)
> + dev_err(pcie->dev, "failed to enter L23\n");
What does "L23" mean? Some power management thing?
> +}
> +
> +static void turn_off(struct brcm_pcie *pcie)
> +{
> + void __iomem *base = pcie->base;
> +
> + if (brcm_pcie_link_up(pcie))
> + enter_l23(pcie);
> + /* Reset endpoint device */
> + brcm_pcie_perst_set(pcie, 1);
> + /* deassert request for L23 in case it was asserted */
> + WR_FLD_RB(base, PCIE_MISC_PCIE_CTRL, PCIE_L23_REQUEST, 0);
> + /* SERDES_IDDQ = 1 */
> + WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, SERDES_IDDQ, 1);
> + /* Shutdown PCIe bridge */
> + brcm_pcie_bridge_sw_init_set(pcie, 1);
> +}
> +
> +static int brcm_pcie_suspend(struct device *dev)
> +{
> + struct brcm_pcie *pcie = dev_get_drvdata(dev);
> +
> + turn_off(pcie);
> + clk_disable_unprepare(pcie->clk);
> + pcie->suspended = true;
> +
> + return 0;
> +}
> +
> +static int brcm_pcie_resume(struct device *dev)
> +{
> + struct brcm_pcie *pcie = dev_get_drvdata(dev);
> + void __iomem *base;
> + int ret;
> +
> + base = pcie->base;
> + clk_prepare_enable(pcie->clk);
> +
> + /* Take bridge out of reset so we can access the SERDES reg */
Some comments above and below spell it "serdes"; here you spell it
"SERDES".
> + brcm_pcie_bridge_sw_init_set(pcie, 0);
> +
> + /* SERDES_IDDQ = 0 */
> + WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, SERDES_IDDQ, 0);
> + /* wait for serdes to be stable */
> + usleep_range(100, 200);
> +
> + ret = brcm_pcie_setup(pcie);
> + if (ret)
> + return ret;
> +
> + pcie->suspended = false;
> +
> + return 0;
> +}
> +
> +static void _brcm_pcie_remove(struct brcm_pcie *pcie)
> +{
> + turn_off(pcie);
> + clk_disable_unprepare(pcie->clk);
> + clk_put(pcie->clk);
> + brcm_pcie_remove_controller(pcie);
> +}
> +
> +static int brcm_pcie_remove(struct platform_device *pdev)
> +{
> + struct brcm_pcie *pcie = platform_get_drvdata(pdev);
> +
> + pci_stop_root_bus(pcie->root_bus);
> + pci_remove_root_bus(pcie->root_bus);
> + _brcm_pcie_remove(pcie);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id brcm_pcie_match[] = {
> + { .compatible = "brcm,bcm7425-pcie", .data = &bcm7425_cfg },
> + { .compatible = "brcm,bcm7435-pcie", .data = &bcm7435_cfg },
> + { .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
> + { .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, brcm_pcie_match);
> +
> +static int brcm_pcie_probe(struct platform_device *pdev)
> +{
> + struct device_node *dn = pdev->dev.of_node;
> + const struct of_device_id *of_id;
> + const struct pcie_cfg_data *data;
> + int ret;
> + struct brcm_pcie *pcie;
> + struct resource *res;
> + void __iomem *base;
> + u32 tmp;
> + struct pci_host_bridge *bridge;
> + struct pci_bus *child;
> +
> + bridge = devm_pci_alloc_host_bridge(&pdev->dev, sizeof(*pcie));
> + if (!bridge)
> + return -ENOMEM;
> +
> + pcie = pci_host_bridge_priv(bridge);
> + INIT_LIST_HEAD(&pcie->resources);
> +
> + of_id = of_match_node(brcm_pcie_match, dn);
> + if (!of_id) {
> + dev_err(&pdev->dev, "failed to look up compatible string\n");
> + return -EINVAL;
> + }
> +
> + if (of_property_read_u32(dn, "dma-ranges", &tmp) == 0) {
> + dev_err(&pdev->dev, "cannot yet handle dma-ranges\n");
> + return -EINVAL;
> + }
> +
> + data = of_id->data;
> + pcie->reg_offsets = data->offsets;
> + pcie->reg_field_info = data->reg_field_info;
> + pcie->type = data->type;
> + pcie->dn = dn;
> + pcie->dev = &pdev->dev;
> +
> + pcie->id = of_get_pci_domain_nr(dn);
Why do you call of_get_pci_domain_nr() directly? No other driver
does.
> + if (pcie->id < 0)
> + return pcie->id;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res)
> + return -EINVAL;
> +
> + base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + pcie->clk = of_clk_get_by_name(dn, "sw_pcie");
> + if (IS_ERR(pcie->clk)) {
> + dev_err(&pdev->dev, "could not get clock\n");
> + pcie->clk = NULL;
> + }
> + pcie->base = base;
> +
> + ret = of_pci_get_max_link_speed(dn);
> + pcie->gen = (ret < 0) ? 0 : ret;
> +
> + pcie->ssc = of_property_read_bool(dn, "brcm,enable-ssc");
> +
> + ret = irq_of_parse_and_map(pdev->dev.of_node, 0);
> + if (ret == 0)
> + /* keep going, as we don't use this intr yet */
> + dev_warn(pcie->dev, "cannot get pcie interrupt\n");
> + else
> + pcie->irq = ret;
> +
> + ret = brcm_pcie_parse_request_of_pci_ranges(pcie);
> + if (ret)
> + return ret;
> +
> + ret = clk_prepare_enable(pcie->clk);
> + if (ret) {
> + dev_err(&pdev->dev, "could not enable clock\n");
> + return ret;
> + }
> +
> + ret = brcm_pcie_add_controller(pcie);
> + if (ret)
> + return ret;
> +
> + ret = brcm_pcie_setup(pcie);
> + if (ret)
> + goto fail;
> +
> + list_splice_init(&pcie->resources, &bridge->windows);
> + bridge->dev.parent = &pdev->dev;
> + bridge->busnr = 0;
> + bridge->ops = &brcm_pcie_ops;
> + bridge->sysdata = pcie;
> + bridge->map_irq = of_irq_parse_and_map_pci;
> + bridge->swizzle_irq = pci_common_swizzle;
> +
> + ret = pci_scan_root_bus_bridge(bridge);
> + if (ret < 0) {
> + dev_err(pcie->dev, "Scanning root bridge failed");
> + goto fail;
> + }
> +
> + pci_assign_unassigned_bus_resources(bridge->bus);
> + list_for_each_entry(child, &bridge->bus->children, node)
> + pcie_bus_configure_settings(child);
> + pci_bus_add_devices(bridge->bus);
> + platform_set_drvdata(pdev, pcie);
> + pcie->root_bus = bridge->bus;
> +
> + return 0;
> +
> +fail:
> + _brcm_pcie_remove(pcie);
> + return ret;
> +}
> +
> +static const struct dev_pm_ops brcm_pcie_pm_ops = {
> + .suspend_noirq = brcm_pcie_suspend,
> + .resume_noirq = brcm_pcie_resume,
> +};
> +
> +static struct platform_driver __refdata brcm_pcie_driver = {
Why do you need __refdata? There's only only other occurrence in
drivers/pci, and I'm dubious about that one as well.
> + .probe = brcm_pcie_probe,
> + .remove = brcm_pcie_remove,
> + .driver = {
> + .name = "brcm-pcie",
> + .owner = THIS_MODULE,
> + .of_match_table = brcm_pcie_match,
> + .pm = &brcm_pcie_pm_ops,
> + },
> +};
> +
> +module_platform_driver(brcm_pcie_driver);
> +
> +MODULE_LICENSE("GPL");
Copyright notice above says "GPL v2", which is not the same as the
"GPL" here.
> +MODULE_DESCRIPTION("Broadcom STB PCIE RC driver");
> +MODULE_AUTHOR("Broadcom");
> --
> 1.9.0.138.g2de3478
>
>
> _______________________________________________
> 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] rtc: sun6i: ensure rtc is kfree'd on error
From: Alexandre Belloni @ 2017-12-12 22:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171122171618.2460-1-colin.king@canonical.com>
On 22/11/2017 at 17:16:18 +0000, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The error return path on clk_data allocation failure does not kfree
> the allocated rtc object. Fix this with a kfree of rtc on the error
> exit path.
>
> Detected by CoverityScan, CID#1452264 ("Resource Leak")
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/rtc/rtc-sun6i.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic
From: Bjorn Helgaas @ 2017-12-12 22:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1510697532-32828-5-git-send-email-jim2101024@gmail.com>
On Tue, Nov 14, 2017 at 05:12:08PM -0500, Jim Quinlan wrote:
> The Broadcom STB PCIe host controller is intimately related to the
> memory subsystem. This close relationship adds complexity to how cpu
> system memory is mapped to PCIe memory. Ideally, this mapping is an
> identity mapping, or an identity mapping off by a constant. Not so in
> this case.
>
> Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB
> of system memory. Here is how the PCIe controller maps the
> system memory to PCIe memory:
>
> memc0-a@[ 0....3fffffff] <=> pci@[ 0....3fffffff]
> memc0-b@[100000000...13fffffff] <=> pci@[ 40000000....7fffffff]
> memc1-a@[ 40000000....7fffffff] <=> pci@[ 80000000....bfffffff]
> memc1-b@[300000000...33fffffff] <=> pci@[ c0000000....ffffffff]
> memc2-a@[ 80000000....bfffffff] <=> pci@[100000000...13fffffff]
> memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
>
> Although there are some "gaps" that can be added between the
> individual mappings by software, the permutation of memory regions for
> the most part is fixed by HW. The solution of having something close
> to an identity mapping is not possible.
>
> The idea behind this HW design is that the same PCIe module can
> act as an RC or EP, and if it acts as an EP it concatenates all
> of system memory into a BAR so anything can be accessed. Unfortunately,
> when the PCIe block is in the role of an RC it also presents this
> "BAR" to downstream PCIe devices, rather than offering an identity map
> between its system memory and PCIe space.
>
> Suppose that an endpoint driver allocs some DMA memory. Suppose this
> memory is located at 0x6000_0000, which is in the middle of memc1-a.
> The driver wants a dma_addr_t value that it can pass on to the EP to
> use. Without doing any custom mapping, the EP will use this value for
> DMA: the driver will get a dma_addr_t equal to 0x6000_0000. But this
> won't work; the device needs a dma_addr_t that reflects the PCIe space
> address, namely 0xa000_0000.
>
> So, essentially the solution to this problem must modify the
> dma_addr_t returned by the DMA routines routines. There are two
> ways (I know of) of doing this:
>
> (a) overriding/redefining the dma_to_phys() and phys_to_dma() calls
> that are used by the dma_ops routines. This is the approach of
>
> arch/mips/cavium-octeon/dma-octeon.c
>
> In ARM and ARM64 these two routines are defiend in asm/dma-mapping.h
> as static inline functions.
>
> (b) Subscribe to a notifier that notifies when a device is added to a
> bus. When this happens, set_dma_ops() can be called for the device.
> This method is mentioned in:
>
> http://lxr.free-electrons.com/source/drivers/of/platform.c?v=3.16#L152
>
> where it says as a comment
>
> "In case if platform code need to use own special DMA
> configuration, it can use Platform bus notifier and
> handle BUS_NOTIFY_ADD_DEVICE event to fix up DMA
> configuration."
>
> Solution (b) is what this commit does. It uses its own set of
> dma_ops which are wrappers around the arch_dma_ops. The
> wrappers translate the dma addresses before/after invoking
> the arch_dma_ops, as appropriate.
>
> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
> ---
> drivers/pci/host/Makefile | 4 +-
> drivers/pci/host/pcie-brcmstb-dma.c | 319 ++++++++++++++++++++++++++++++++++++
> drivers/pci/host/pcie-brcmstb.c | 139 +++++++++++++++-
> drivers/pci/host/pcie-brcmstb.h | 22 +++
> 4 files changed, 474 insertions(+), 10 deletions(-)
> create mode 100644 drivers/pci/host/pcie-brcmstb-dma.c
> create mode 100644 drivers/pci/host/pcie-brcmstb.h
>
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index a8b9923..6b94c9c 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -21,7 +21,9 @@ obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
> obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
> obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
> obj-$(CONFIG_VMD) += vmd.o
> -obj-$(CONFIG_PCIE_BRCMSTB) += pcie-brcmstb.o
> +
> +obj-$(CONFIG_PCIE_BRCMSTB) += brcmstb-pcie.o
> +brcmstb-pcie-objs := pcie-brcmstb.o pcie-brcmstb-dma.o
I do not like the addition of more files for this driver (we might
have talked about this before, I can't remember). If we end up with
2, 3, 4 files for every vendor it's going to be a hassle to manage.
It looks like the only caller of the pcie-brcmstb-dma.c is
pcie-brcmstb.c, so for now, at least, I don't see the point of
splitting them. They can always be split later if necessary.
> # The following drivers are for devices that use the generic ACPI
> # pci_root.c driver but don't support standard ECAM config access.
> diff --git a/drivers/pci/host/pcie-brcmstb-dma.c b/drivers/pci/host/pcie-brcmstb-dma.c
> new file mode 100644
> index 0000000..6c397be
> --- /dev/null
> +++ b/drivers/pci/host/pcie-brcmstb-dma.c
> @@ -0,0 +1,319 @@
> +/*
> + * Copyright (C) 2015-2017 Broadcom
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
Spurious blank comment line.
> + */
> +#include <linux/dma-mapping.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/of_address.h>
> +#include <linux/of_device.h>
> +#include <linux/of_pci.h>
> +#include <linux/pci.h>
> +#include <linux/platform_device.h>
> +#include <linux/smp.h>
> +
> +#include "pcie-brcmstb.h"
> +
> +static const struct dma_map_ops *arch_dma_ops;
> +static const struct dma_map_ops *brcm_dma_ops_ptr;
> +
> +static dma_addr_t brcm_to_pci(dma_addr_t addr)
> +{
> + struct of_pci_range *p;
> +
> + if (!num_dma_ranges)
> + return addr;
> +
> + for (p = dma_ranges; p < &dma_ranges[num_dma_ranges]; p++)
> + if (addr >= p->cpu_addr && addr < (p->cpu_addr + p->size))
> + return addr - p->cpu_addr + p->pci_addr;
> +
> + return addr;
> +}
> +
> +static dma_addr_t brcm_to_cpu(dma_addr_t addr)
> +{
> + struct of_pci_range *p;
> +
> + if (!num_dma_ranges)
> + return addr;
> +
> + for (p = dma_ranges; p < &dma_ranges[num_dma_ranges]; p++)
> + if (addr >= p->pci_addr && addr < (p->pci_addr + p->size))
> + return addr - p->pci_addr + p->cpu_addr;
> +
> + return addr;
> +}
> +
> +static void *brcm_alloc(struct device *dev, size_t size, dma_addr_t *handle,
> + gfp_t gfp, unsigned long attrs)
> +{
> + void *ret;
> +
> + ret = arch_dma_ops->alloc(dev, size, handle, gfp, attrs);
> + if (ret)
> + *handle = brcm_to_pci(*handle);
> + return ret;
> +}
> +
> +static void brcm_free(struct device *dev, size_t size, void *cpu_addr,
> + dma_addr_t handle, unsigned long attrs)
> +{
> + handle = brcm_to_cpu(handle);
> + arch_dma_ops->free(dev, size, cpu_addr, handle, attrs);
> +}
> +
> +static int brcm_mmap(struct device *dev, struct vm_area_struct *vma,
> + void *cpu_addr, dma_addr_t dma_addr, size_t size,
> + unsigned long attrs)
> +{
> + dma_addr = brcm_to_cpu(dma_addr);
> + return arch_dma_ops->mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
> +}
> +
> +static int brcm_get_sgtable(struct device *dev, struct sg_table *sgt,
> + void *cpu_addr, dma_addr_t handle, size_t size,
> + unsigned long attrs)
> +{
> + handle = brcm_to_cpu(handle);
> + return arch_dma_ops->get_sgtable(dev, sgt, cpu_addr, handle, size,
> + attrs);
> +}
> +
> +static dma_addr_t brcm_map_page(struct device *dev, struct page *page,
> + unsigned long offset, size_t size,
> + enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + return brcm_to_pci(arch_dma_ops->map_page(dev, page, offset, size,
> + dir, attrs));
> +}
> +
> +static void brcm_unmap_page(struct device *dev, dma_addr_t handle,
> + size_t size, enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + handle = brcm_to_cpu(handle);
> + arch_dma_ops->unmap_page(dev, handle, size, dir, attrs);
> +}
> +
> +static int brcm_map_sg(struct device *dev, struct scatterlist *sgl,
> + int nents, enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + int i, j;
> + struct scatterlist *sg;
> +
> + for_each_sg(sgl, sg, nents, i) {
> +#ifdef CONFIG_NEED_SG_DMA_LENGTH
> + sg->dma_length = sg->length;
> +#endif
> + sg->dma_address =
> + brcm_dma_ops_ptr->map_page(dev, sg_page(sg), sg->offset,
> + sg->length, dir, attrs);
> + if (dma_mapping_error(dev, sg->dma_address))
> + goto bad_mapping;
> + }
> + return nents;
> +
> +bad_mapping:
> + for_each_sg(sgl, sg, i, j)
> + brcm_dma_ops_ptr->unmap_page(dev, sg_dma_address(sg),
> + sg_dma_len(sg), dir, attrs);
> + return 0;
> +}
> +
> +static void brcm_unmap_sg(struct device *dev,
> + struct scatterlist *sgl, int nents,
> + enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + int i;
> + struct scatterlist *sg;
> +
> + for_each_sg(sgl, sg, nents, i)
> + brcm_dma_ops_ptr->unmap_page(dev, sg_dma_address(sg),
> + sg_dma_len(sg), dir, attrs);
> +}
> +
> +static void brcm_sync_single_for_cpu(struct device *dev,
> + dma_addr_t handle, size_t size,
> + enum dma_data_direction dir)
> +{
> + handle = brcm_to_cpu(handle);
> + arch_dma_ops->sync_single_for_cpu(dev, handle, size, dir);
> +}
> +
> +static void brcm_sync_single_for_device(struct device *dev,
> + dma_addr_t handle, size_t size,
> + enum dma_data_direction dir)
> +{
> + handle = brcm_to_cpu(handle);
> + arch_dma_ops->sync_single_for_device(dev, handle, size, dir);
> +}
> +
> +static dma_addr_t brcm_map_resource(struct device *dev, phys_addr_t phys,
> + size_t size,
> + enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + if (arch_dma_ops->map_resource)
> + return brcm_to_pci(arch_dma_ops->map_resource
> + (dev, phys, size, dir, attrs));
> + return brcm_to_pci((dma_addr_t)phys);
> +}
> +
> +static void brcm_unmap_resource(struct device *dev, dma_addr_t handle,
> + size_t size, enum dma_data_direction dir,
> + unsigned long attrs)
> +{
> + if (arch_dma_ops->unmap_resource)
> + arch_dma_ops->unmap_resource(dev, brcm_to_cpu(handle), size,
> + dir, attrs);
> +}
> +
> +void brcm_sync_sg_for_cpu(struct device *dev, struct scatterlist *sgl,
> + int nents, enum dma_data_direction dir)
> +{
> + struct scatterlist *sg;
> + int i;
> +
> + for_each_sg(sgl, sg, nents, i)
> + brcm_dma_ops_ptr->sync_single_for_cpu(dev, sg_dma_address(sg),
> + sg->length, dir);
> +}
> +
> +void brcm_sync_sg_for_device(struct device *dev, struct scatterlist *sgl,
> + int nents, enum dma_data_direction dir)
> +{
> + struct scatterlist *sg;
> + int i;
> +
> + for_each_sg(sgl, sg, nents, i)
> + brcm_dma_ops_ptr->sync_single_for_device(dev,
> + sg_dma_address(sg),
> + sg->length, dir);
> +}
> +
> +static int brcm_mapping_error(struct device *dev, dma_addr_t dma_addr)
> +{
> + return arch_dma_ops->mapping_error(dev, dma_addr);
> +}
> +
> +static int brcm_dma_supported(struct device *dev, u64 mask)
> +{
> + if (num_dma_ranges) {
> + /*
> + * It is our translated addresses that the EP will "see", so
> + * we check all of the ranges for the largest possible value.
> + */
> + int i;
> +
> + for (i = 0; i < num_dma_ranges; i++)
> + if (dma_ranges[i].pci_addr + dma_ranges[i].size - 1
> + > mask)
> + return 0;
> + return 1;
> + }
> +
> + return arch_dma_ops->dma_supported(dev, mask);
> +}
> +
> +#ifdef ARCH_HAS_DMA_GET_REQUIRED_MASK
> +u64 brcm_get_required_mask)(struct device *dev)
> +{
> + return arch_dma_ops->get_required_mask(dev);
> +}
> +#endif
> +
> +static const struct dma_map_ops brcm_dma_ops = {
> + .alloc = brcm_alloc,
> + .free = brcm_free,
> + .mmap = brcm_mmap,
> + .get_sgtable = brcm_get_sgtable,
> + .map_page = brcm_map_page,
> + .unmap_page = brcm_unmap_page,
> + .map_sg = brcm_map_sg,
> + .unmap_sg = brcm_unmap_sg,
> + .map_resource = brcm_map_resource,
> + .unmap_resource = brcm_unmap_resource,
> + .sync_single_for_cpu = brcm_sync_single_for_cpu,
> + .sync_single_for_device = brcm_sync_single_for_device,
> + .sync_sg_for_cpu = brcm_sync_sg_for_cpu,
> + .sync_sg_for_device = brcm_sync_sg_for_device,
> + .mapping_error = brcm_mapping_error,
> + .dma_supported = brcm_dma_supported,
> +#ifdef ARCH_HAS_DMA_GET_REQUIRED_MASK
> + .get_required_mask = brcm_get_required_mask,
> +#endif
> +};
> +
> +static void brcm_set_dma_ops(struct device *dev)
> +{
> + int ret;
> +
> + if (IS_ENABLED(CONFIG_ARM64)) {
> + /*
> + * We are going to invoke get_dma_ops(). That
> + * function, at this point in time, invokes
> + * get_arch_dma_ops(), and for ARM64 that function
> + * returns a pointer to dummy_dma_ops. So then we'd
> + * like to call arch_setup_dma_ops(), but that isn't
> + * exported. Instead, we call of_dma_configure(),
> + * which is exported, and this calls
> + * arch_setup_dma_ops(). Once we do this the call to
> + * get_dma_ops() will work properly because
> + * dev->dma_ops will be set.
> + */
> + ret = of_dma_configure(dev, dev->of_node);
> + if (ret) {
> + dev_err(dev, "of_dma_configure() failed: %d\n", ret);
> + return;
> + }
> + }
> +
> + arch_dma_ops = get_dma_ops(dev);
> + if (!arch_dma_ops) {
> + dev_err(dev, "failed to get arch_dma_ops\n");
> + return;
> + }
> +
> + set_dma_ops(dev, &brcm_dma_ops);
> +}
> +
> +static int brcmstb_platform_notifier(struct notifier_block *nb,
> + unsigned long event, void *__dev)
> +{
> + struct device *dev = __dev;
> +
> + brcm_dma_ops_ptr = &brcm_dma_ops;
> + if (event != BUS_NOTIFY_ADD_DEVICE)
> + return NOTIFY_DONE;
> +
> + brcm_set_dma_ops(dev);
> + return NOTIFY_OK;
> +}
> +
> +static struct notifier_block brcmstb_platform_nb = {
> + .notifier_call = brcmstb_platform_notifier,
> +};
> +
> +int brcm_register_notifier(void)
> +{
> + return bus_register_notifier(&pci_bus_type, &brcmstb_platform_nb);
> +}
> +
> +int brcm_unregister_notifier(void)
> +{
> + return bus_unregister_notifier(&pci_bus_type, &brcmstb_platform_nb);
> +}
> diff --git a/drivers/pci/host/pcie-brcmstb.c b/drivers/pci/host/pcie-brcmstb.c
> index d8a8f7a..5f4c6aa 100644
> --- a/drivers/pci/host/pcie-brcmstb.c
> +++ b/drivers/pci/host/pcie-brcmstb.c
> @@ -35,6 +35,7 @@
> #include <soc/brcmstb/memory_api.h>
> #include <linux/string.h>
> #include <linux/types.h>
> +#include "pcie-brcmstb.h"
>
> /* BRCM_PCIE_CAP_REGS - Offset for the mandatory capability config regs */
> #define BRCM_PCIE_CAP_REGS 0x00ac
> @@ -332,6 +333,10 @@ static void __iomem *brcm_pcie_map_conf(struct pci_bus *bus, unsigned int devfn,
> ((val & ~reg##_##field##_MASK) | \
> (reg##_##field##_MASK & (field_val << reg##_##field##_SHIFT)))
>
> +/* Also used by pci-brcmstb-dma.c */
> +struct of_pci_range *dma_ranges;
> +int num_dma_ranges;
These names are too generic for global symbols.
> +
> static struct list_head brcm_pcie = LIST_HEAD_INIT(brcm_pcie);
> static phys_addr_t scb_size[BRCM_MAX_SCB];
> static int num_memc;
> @@ -642,25 +647,42 @@ static inline void brcm_pcie_perst_set(struct brcm_pcie *pcie,
>
> static int brcm_pcie_add_controller(struct brcm_pcie *pcie)
> {
> + int ret = 0;
> +
> mutex_lock(&brcm_pcie_lock);
> + if (list_empty(&brcm_pcie)) {
> + ret = brcm_register_notifier();
> + if (ret) {
> + dev_err(pcie->dev,
> + "failed to register pci bus notifier\n");
> + goto done;
> + }
> + }
> list_add_tail(&pcie->list, &brcm_pcie);
> +done:
> mutex_unlock(&brcm_pcie_lock);
> -
> - return 0;
> + return ret;
> }
>
> static void brcm_pcie_remove_controller(struct brcm_pcie *pcie)
> {
> struct list_head *pos, *q;
> struct brcm_pcie *tmp;
> + static const char *err_msg = "failed to unregister pci bus notifier\n";
>
> mutex_lock(&brcm_pcie_lock);
> list_for_each_safe(pos, q, &brcm_pcie) {
> tmp = list_entry(pos, struct brcm_pcie, list);
> if (tmp == pcie) {
> list_del(pos);
> - if (list_empty(&brcm_pcie))
> + if (list_empty(&brcm_pcie)) {
> + if (brcm_unregister_notifier())
> + dev_err(pcie->dev, err_msg);
> + kfree(dma_ranges);
> + dma_ranges = NULL;
> + num_dma_ranges = 0;
> num_memc = 0;
> + }
> break;
> }
> }
> @@ -712,6 +734,75 @@ static int brcm_pcie_parse_request_of_pci_ranges(struct brcm_pcie *pcie)
> return 0;
> }
>
> +static int pci_dma_range_parser_init(struct of_pci_range_parser *parser,
> + struct device_node *node)
> +{
> + const int na = 3, ns = 2;
> + int rlen;
> +
> + parser->node = node;
> + parser->pna = of_n_addr_cells(node);
> + parser->np = parser->pna + na + ns;
> +
> + parser->range = of_get_property(node, "dma-ranges", &rlen);
> + if (!parser->range)
> + return -ENOENT;
> +
> + parser->end = parser->range + rlen / sizeof(__be32);
> +
> + return 0;
> +}
> +
> +static int brcm_pcie_parse_map_dma_ranges(struct brcm_pcie *pcie)
> +{
> + int i, ret = 0;
> + struct of_pci_range_parser parser;
> + struct device_node *dn = pcie->dn;
> +
> + mutex_lock(&brcm_pcie_lock);
> + if (dma_ranges)
> + goto done;
> +
> + /*
> + * Parse dma-ranges property if present. If there are multiple
> + * PCI controllers, we only have to parse from one of them since
> + * the others will have an identical mapping.
> + */
> + if (!pci_dma_range_parser_init(&parser, dn)) {
> + unsigned int max_ranges
> + = (parser.end - parser.range) / parser.np;
> +
> + dma_ranges = kcalloc(max_ranges, sizeof(struct of_pci_range),
> + GFP_KERNEL);
> + if (!dma_ranges) {
> + ret = -ENOMEM;
> + goto done;
> + }
> + for (i = 0; of_pci_range_parser_one(&parser, dma_ranges + i);
> + i++)
> + num_dma_ranges++;
> + }
> +
> + for (i = 0, num_memc = 0; i < BRCM_MAX_SCB; i++) {
> + u64 size = brcmstb_memory_memc_size(i);
> +
> + if (size == (u64)-1) {
> + dev_err(pcie->dev, "cannot get memc%d size", i);
> + ret = -EINVAL;
> + goto done;
> + } else if (size) {
> + scb_size[i] = roundup_pow_of_two_64(size);
> + num_memc++;
> + } else {
> + break;
> + }
> + }
> +
> +done:
> + mutex_unlock(&brcm_pcie_lock);
> + return ret;
> +}
> +
> static int brcm_pcie_setup(struct brcm_pcie *pcie)
> {
> void __iomem *base = pcie->base;
> @@ -781,6 +872,38 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
> */
> rc_bar2_offset = 0;
>
> + if (dma_ranges) {
> + /*
> + * The best-case scenario is to place the inbound
> + * region in the first 4GB of pci-space, as some
> + * legacy devices can only address 32bits.
> + * We would also like to put the MSI under 4GB
> + * as well, since some devices require a 32bit
> + * MSI target address.
> + */
> + if (total_mem_size <= 0xc0000000ULL &&
> + rc_bar2_size <= 0x100000000ULL) {
> + rc_bar2_offset = 0;
> + } else {
> + /*
> + * The system memory is 4GB or larger so we
> + * cannot start the inbound region at location
> + * 0 (since we have to allow some space for
> + * outbound memory @ 3GB). So instead we
> + * start it at the 1x multiple of its size
> + */
> + rc_bar2_offset = rc_bar2_size;
> + }
> +
> + } else {
> + /*
> + * Set simple configuration based on memory sizes
> + * only. We always start the viewport at address 0,
> + * and set the MSI target address accordingly.
> + */
> + rc_bar2_offset = 0;
> + }
> +
> tmp = lower_32_bits(rc_bar2_offset);
> tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
> encode_ibar_size(rc_bar2_size));
> @@ -995,7 +1118,6 @@ static int brcm_pcie_probe(struct platform_device *pdev)
> struct brcm_pcie *pcie;
> struct resource *res;
> void __iomem *base;
> - u32 tmp;
> struct pci_host_bridge *bridge;
> struct pci_bus *child;
>
> @@ -1012,11 +1134,6 @@ static int brcm_pcie_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> - if (of_property_read_u32(dn, "dma-ranges", &tmp) == 0) {
> - dev_err(&pdev->dev, "cannot yet handle dma-ranges\n");
> - return -EINVAL;
> - }
> -
> data = of_id->data;
> pcie->reg_offsets = data->offsets;
> pcie->reg_field_info = data->reg_field_info;
> @@ -1059,6 +1176,10 @@ static int brcm_pcie_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> + ret = brcm_pcie_parse_map_dma_ranges(pcie);
> + if (ret)
> + return ret;
> +
> ret = clk_prepare_enable(pcie->clk);
> if (ret) {
> dev_err(&pdev->dev, "could not enable clock\n");
> diff --git a/drivers/pci/host/pcie-brcmstb.h b/drivers/pci/host/pcie-brcmstb.h
> new file mode 100644
> index 0000000..d7233f0
> --- /dev/null
> +++ b/drivers/pci/host/pcie-brcmstb.h
> @@ -0,0 +1,22 @@
> +#ifndef __BRCMSTB_PCI_H
> +#define __BRCMSTB_PCI_H
> +/*
> + * Copyright (C) 2015 - 2017 Broadcom
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +int brcm_register_notifier(void);
> +int brcm_unregister_notifier(void);
> +
> +extern struct of_pci_range *dma_ranges;
> +extern int num_dma_ranges;
> +
> +#endif /* __BRCMSTB_PCI_H */
> --
> 1.9.0.138.g2de3478
>
^ permalink raw reply
* [PATCH] i2c: Include GPIO consumer header in main include
From: Wolfram Sang @ 2017-12-12 22:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171208133934.18038-1-linus.walleij@linaro.org>
On Fri, Dec 08, 2017 at 02:39:34PM +0100, Linus Walleij wrote:
> It seems most users of <linux/i2c.h> pick up their
> dependency of <linux/gpio/consumer.h> from other paths but
> that is not a universal law, so include the header
> explicitly so we have struct gpio_desc available.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Not sure. Having GPIOs is not really a requirement for I2C. I tend to
think drivers using it should include this explicitly?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171212/de103bf0/attachment.sig>
^ permalink raw reply
* [PATCH] i2c: imx: Include the right GPIO header
From: Wolfram Sang @ 2017-12-12 22:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171208133535.17562-1-linus.walleij@linaro.org>
On Fri, Dec 08, 2017 at 02:35:35PM +0100, Linus Walleij wrote:
> <linux/of_gpio.h> is not used in this file, by
> <linux/gpio/consumer.h> is.
>
> Someone is just lucky with their implicit includes.
>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Applied to for-next, thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171212/0ef31c42/attachment-0001.sig>
^ permalink raw reply
* [PATCH v3 6/8] PCI: brcmstb: Add MSI capability
From: Bjorn Helgaas @ 2017-12-12 22:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1510697532-32828-7-git-send-email-jim2101024@gmail.com>
On Tue, Nov 14, 2017 at 05:12:10PM -0500, Jim Quinlan wrote:
> This commit adds MSI to the Broadcom STB PCIe host controller. It does
> not add MSIX since that functionality is not in the HW. The MSI
> controller is physically located within the PCIe block, however, there
> is no reason why the MSI controller could not be moved elsewhere in
> the future.
>
> Since the internal Brcmstb MSI controller is intertwined with the PCIe
> controller, it is not its own platform device but rather part of the
> PCIe platform device.
>
> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
> ---
> drivers/pci/host/pcie-brcmstb.c | 372 ++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 359 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-brcmstb.c b/drivers/pci/host/pcie-brcmstb.c
> index 5f4c6aa..89bad31 100644
> --- a/drivers/pci/host/pcie-brcmstb.c
> +++ b/drivers/pci/host/pcie-brcmstb.c
> @@ -11,6 +11,7 @@
> * GNU General Public License for more details.
> */
>
> +#include <linux/bitops.h>
> #include <linux/clk.h>
> #include <linux/compiler.h>
> #include <linux/delay.h>
> @@ -18,15 +19,16 @@
> #include <linux/interrupt.h>
> #include <linux/io.h>
> #include <linux/ioport.h>
> +#include <linux/irqchip/chained_irq.h>
> #include <linux/irqdomain.h>
> #include <linux/kernel.h>
> #include <linux/list.h>
> #include <linux/log2.h>
> #include <linux/module.h>
> +#include <linux/msi.h>
> #include <linux/of_address.h>
> #include <linux/of_irq.h>
> #include <linux/of_pci.h>
> -#include <linux/of_pci.h>
> #include <linux/of_platform.h>
> #include <linux/pci.h>
> #include <linux/printk.h>
> @@ -56,6 +58,9 @@
> #define PCIE_MISC_RC_BAR2_CONFIG_LO 0x4034
> #define PCIE_MISC_RC_BAR2_CONFIG_HI 0x4038
> #define PCIE_MISC_RC_BAR3_CONFIG_LO 0x403c
> +#define PCIE_MISC_MSI_BAR_CONFIG_LO 0x4044
> +#define PCIE_MISC_MSI_BAR_CONFIG_HI 0x4048
> +#define PCIE_MISC_MSI_DATA_CONFIG 0x404c
> #define PCIE_MISC_PCIE_CTRL 0x4064
> #define PCIE_MISC_PCIE_STATUS 0x4068
> #define PCIE_MISC_REVISION 0x406c
> @@ -64,6 +69,7 @@
> #define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI 0x4084
> #define PCIE_MISC_HARD_PCIE_HARD_DEBUG 0x4204
> #define PCIE_INTR2_CPU_BASE 0x4300
> +#define PCIE_MSI_INTR2_BASE 0x4500
>
> /*
> * Broadcom Settop Box PCIE Register Field shift and mask info. The
> @@ -124,6 +130,8 @@
>
> #define BRCM_NUM_PCIE_OUT_WINS 0x4
> #define BRCM_MAX_SCB 0x4
> +#define BRCM_INT_PCI_MSI_NR 32
> +#define BRCM_PCIE_HW_REV_33 0x0303
>
> #define BRCM_MSI_TARGET_ADDR_LT_4GB 0x0fffffffcULL
> #define BRCM_MSI_TARGET_ADDR_GT_4GB 0xffffffffcULL
> @@ -212,6 +220,30 @@ struct brcm_window {
> dma_addr_t size;
> };
>
> +struct brcm_msi {
> + struct irq_domain *msi_domain;
> + struct irq_domain *inner_domain;
> + struct mutex lock; /* guards the alloc/free operations */
> + u64 target_addr;
> + int irq;
> + /* intr_base is the base pointer for interrupt status/set/clr regs */
> + void __iomem *intr_base;
> + /* intr_legacy_mask indicates how many bits are MSI interrupts */
> + u32 intr_legacy_mask;
> + /*
> + * intr_legacy_offset indicates bit position of MSI_01. It is
> + * to map the register bit position to a hwirq that starts at 0.
> + */
> + u32 intr_legacy_offset;
> + /* used indicates which MSI interrupts have been alloc'd */
> + unsigned long used;
> +
> + void __iomem *base;
> + struct device *dev;
> + struct device_node *dn;
> + unsigned int rev;
I think you aligned the structure elements for brcm_pcie, so do the
same here.
> +};
> +
> /* Internal PCIe Host Controller Information.*/
> struct brcm_pcie {
> struct list_head list;
> @@ -227,7 +259,10 @@ struct brcm_pcie {
> int num_out_wins;
> bool ssc;
> int gen;
> + u64 msi_target_addr;
> struct brcm_window out_wins[BRCM_NUM_PCIE_OUT_WINS];
> + struct brcm_msi *msi;
> + bool msi_internal;
> unsigned int rev;
> const int *reg_offsets;
> const int *reg_field_info;
> @@ -240,6 +275,13 @@ struct pcie_cfg_data {
> const enum pcie_type type;
> };
>
> +struct brcm_info {
> + int rev;
> + u64 msi_target_addr;
> + void __iomem *base;
> + struct brcm_msi *msi;
And here.
> +};
> +
> static const int pcie_reg_field_info[] = {
> [RGR1_SW_INIT_1_INIT_MASK] = 0x2,
> [RGR1_SW_INIT_1_INIT_SHIFT] = 0x1,
> @@ -546,6 +588,264 @@ static void brcm_pcie_set_outbound_win(struct brcm_pcie *pcie,
> }
> }
>
> +static struct irq_chip brcm_msi_irq_chip = {
> + .name = "Brcm_MSI",
> + .irq_mask = pci_msi_mask_irq,
> + .irq_unmask = pci_msi_unmask_irq,
> +};
> +
> +static struct msi_domain_info brcm_msi_domain_info = {
> + .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
> + MSI_FLAG_PCI_MSIX),
> + .chip = &brcm_msi_irq_chip,
> +};
> +
> +static void brcm_pcie_msi_isr(struct irq_desc *desc)
> +{
> + struct irq_chip *chip = irq_desc_get_chip(desc);
> + struct brcm_msi *msi;
> + unsigned long status, virq;
> + u32 mask, bit, hwirq;
> + struct device *dev;
> +
> + chained_irq_enter(chip, desc);
> + msi = irq_desc_get_handler_data(desc);
> + mask = msi->intr_legacy_mask;
> + dev = msi->dev;
> +
> + while ((status = bcm_readl(msi->intr_base + STATUS) & mask)) {
> + for_each_set_bit(bit, &status, BRCM_INT_PCI_MSI_NR) {
> + /* clear the interrupt */
> + bcm_writel(1 << bit, msi->intr_base + CLR);
> +
> + /* Account for legacy interrupt offset */
> + hwirq = bit - msi->intr_legacy_offset;
> +
> + virq = irq_find_mapping(msi->inner_domain, hwirq);
> + if (virq) {
> + if (msi->used & (1 << hwirq))
> + generic_handle_irq(virq);
> + else
> + dev_info(dev, "unhandled MSI %d\n",
> + hwirq);
> + } else {
> + /* Unknown MSI, just clear it */
> + dev_dbg(dev, "unexpected MSI\n");
> + }
> + }
> + }
> + chained_irq_exit(chip, desc);
> +}
> +
> +static void brcm_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> +{
> + struct brcm_msi *msi = irq_data_get_irq_chip_data(data);
> + u32 temp;
> +
> + msg->address_lo = lower_32_bits(msi->target_addr);
> + msg->address_hi = upper_32_bits(msi->target_addr);
> + temp = bcm_readl(msi->base + PCIE_MISC_MSI_DATA_CONFIG);
> + msg->data = ((temp >> 16) & (temp & 0xffff)) | data->hwirq;
> +}
> +
> +static int brcm_msi_set_affinity(struct irq_data *irq_data,
> + const struct cpumask *mask, bool force)
> +{
> + return -EINVAL;
> +}
> +
> +static struct irq_chip brcm_msi_bottom_irq_chip = {
> + .name = "Brcm_MSI",
> + .irq_compose_msi_msg = brcm_compose_msi_msg,
> + .irq_set_affinity = brcm_msi_set_affinity,
> +};
> +
> +static int brcm_msi_alloc(struct brcm_msi *msi)
> +{
> + int bit, hwirq;
> +
> + mutex_lock(&msi->lock);
> + bit = ~msi->used ? ffz(msi->used) : -1;
> +
> + if (bit >= 0 && bit < BRCM_INT_PCI_MSI_NR) {
> + msi->used |= (1 << bit);
> + hwirq = bit - msi->intr_legacy_offset;
> + } else {
> + hwirq = -ENOSPC;
> + }
> +
> + mutex_unlock(&msi->lock);
> + return hwirq;
> +}
> +
> +static void brcm_msi_free(struct brcm_msi *msi, unsigned long hwirq)
> +{
> + mutex_lock(&msi->lock);
> + msi->used &= ~(1 << (hwirq + msi->intr_legacy_offset));
> + mutex_unlock(&msi->lock);
> +}
> +
> +static int brcm_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
> + unsigned int nr_irqs, void *args)
> +{
> + struct brcm_msi *msi = domain->host_data;
> + int hwirq;
> +
> + hwirq = brcm_msi_alloc(msi);
> +
> + if (hwirq < 0)
> + return hwirq;
> +
> + irq_domain_set_info(domain, virq, (irq_hw_number_t)hwirq,
> + &brcm_msi_bottom_irq_chip, domain->host_data,
> + handle_simple_irq, NULL, NULL);
> + return 0;
> +}
> +
> +static void brcm_irq_domain_free(struct irq_domain *domain,
> + unsigned int virq, unsigned int nr_irqs)
> +{
> + struct irq_data *d = irq_domain_get_irq_data(domain, virq);
> + struct brcm_msi *msi = irq_data_get_irq_chip_data(d);
> +
> + brcm_msi_free(msi, d->hwirq);
> +}
> +
> +void brcm_msi_set_regs(struct brcm_msi *msi)
Static?
> +{
> + u32 data_val, msi_lo, msi_hi;
> +
> + if (msi->rev >= BRCM_PCIE_HW_REV_33) {
> + /*
> + * ffe0 -- least sig 5 bits are 0 indicating 32 msgs
> + * 6540 -- this is our arbitrary unique data value
> + */
> + data_val = 0xffe06540;
> + } else {
> + /*
> + * fff8 -- least sig 3 bits are 0 indicating 8 msgs
> + * 6540 -- this is our arbitrary unique data value
> + */
> + data_val = 0xfff86540;
> + }
> +
> + /*
> + * Make sure we are not masking MSIs. Note that MSIs can be masked,
> + * but that occurs on the PCIe EP device
> + */
> + bcm_writel(0xffffffff & msi->intr_legacy_mask,
> + msi->intr_base + MASK_CLR);
> +
> + msi_lo = lower_32_bits(msi->target_addr);
> + msi_hi = upper_32_bits(msi->target_addr);
> + /*
> + * The 0 bit of PCIE_MISC_MSI_BAR_CONFIG_LO is repurposed to MSI
> + * enable, which we set to 1.
> + */
> + bcm_writel(msi_lo | 1, msi->base + PCIE_MISC_MSI_BAR_CONFIG_LO);
> + bcm_writel(msi_hi, msi->base + PCIE_MISC_MSI_BAR_CONFIG_HI);
> + bcm_writel(data_val, msi->base + PCIE_MISC_MSI_DATA_CONFIG);
> +}
> +
> +static const struct irq_domain_ops msi_domain_ops = {
> + .alloc = brcm_irq_domain_alloc,
> + .free = brcm_irq_domain_free,
> +};
> +
> +static int brcm_allocate_domains(struct brcm_msi *msi)
> +{
> + struct fwnode_handle *fwnode = of_node_to_fwnode(msi->dn);
> + struct device *dev = msi->dev;
> +
> + msi->inner_domain = irq_domain_add_linear(NULL, BRCM_INT_PCI_MSI_NR,
> + &msi_domain_ops, msi);
> + if (!msi->inner_domain) {
> + dev_err(dev, "failed to create IRQ domain\n");
> + return -ENOMEM;
> + }
> +
> + msi->msi_domain = pci_msi_create_irq_domain(fwnode,
> + &brcm_msi_domain_info,
> + msi->inner_domain);
> + if (!msi->msi_domain) {
> + dev_err(dev, "failed to create MSI domain\n");
> + irq_domain_remove(msi->inner_domain);
> + return -ENOMEM;
> + }
> +
> + return 0;
> +}
> +
> +static void brcm_free_domains(struct brcm_msi *msi)
> +{
> + irq_domain_remove(msi->msi_domain);
> + irq_domain_remove(msi->inner_domain);
> +}
> +
> +void brcm_msi_remove(struct brcm_msi *msi)
Static?
> +{
> + if (!msi)
> + return;
> + irq_set_chained_handler(msi->irq, NULL);
> + irq_set_handler_data(msi->irq, NULL);
> + brcm_free_domains(msi);
> +}
> +
> +int brcm_msi_probe(struct platform_device *pdev, struct brcm_info *info)
Static?
I don't think we're probing a separate device here, so this isn't
quite the right name. I see it looks like you're using a pattern from
altera or xgene. But those have some weird structure where they have
extra of_match_tables, and you don't.
> +{
> + struct brcm_msi *msi;
> + int irq, ret;
> +
> + irq = irq_of_parse_and_map(pdev->dev.of_node, 1);
> + if (irq <= 0) {
> + dev_err(&pdev->dev, "cannot map msi intr\n");
> + return -ENODEV;
> + }
> +
> + msi = devm_kzalloc(&pdev->dev, sizeof(struct brcm_msi), GFP_KERNEL);
> + if (!msi)
> + return -ENOMEM;
> +
> + msi->dev = &pdev->dev;
> + msi->base = info->base;
> + msi->rev = info->rev;
> + msi->dn = pdev->dev.of_node;
> + msi->target_addr = info->msi_target_addr;
> + msi->irq = irq;
> +
> + ret = brcm_allocate_domains(msi);
> + if (ret)
> + return ret;
> +
> + irq_set_chained_handler_and_data(msi->irq, brcm_pcie_msi_isr, msi);
> +
> + if (msi->rev >= BRCM_PCIE_HW_REV_33) {
> + msi->intr_base = msi->base + PCIE_MSI_INTR2_BASE;
> + /*
> + * This version of PCIe hw has only 32 intr bits
> + * starting at bit position 0.
> + */
> + msi->intr_legacy_mask = 0xffffffff;
> + msi->intr_legacy_offset = 0x0;
> + msi->used = 0x0;
> +
> + } else {
> + msi->intr_base = msi->base + PCIE_INTR2_CPU_BASE;
> + /*
> + * This version of PCIe hw has only 8 intr bits starting
> + * at bit position 24.
> + */
> + msi->intr_legacy_mask = 0xff000000;
> + msi->intr_legacy_offset = 24;
> + msi->used = 0x00ffffff;
> + }
> +
> + brcm_msi_set_regs(msi);
> + info->msi = msi;
> +
> + return 0;
> +}
> +
> /* Configuration space read/write support */
> static int cfg_index(int busnr, int devfn, int reg)
> {
> @@ -812,6 +1112,7 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
> int i, j, ret, limit;
> u16 nlw, cls, lnksta;
> bool ssc_good = false;
> + u64 msi_target_addr;
>
> /* reset the bridge and the endpoint device */
> /* field: PCIE_BRIDGE_SW_INIT = 1 */
> @@ -855,14 +1156,17 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
> * The PCIe host controller by design must set the inbound
> * viewport to be a contiguous arrangement of all of the
> * system's memory. In addition, its size mut be a power of
> - * two. To further complicate matters, the viewport must
> - * start on a pcie-address that is aligned on a multiple of its
> - * size. If a portion of the viewport does not represent
> - * system memory -- e.g. 3GB of memory requires a 4GB viewport
> - * -- we can map the outbound memory in or after 3GB and even
> - * though the viewport will overlap the outbound memory the
> - * controller will know to send outbound memory downstream and
> - * everything else upstream.
> + * two. Further, the MSI target address must NOT be placed
> + * inside this region, as the decoding logic will consider its
> + * address to be inbound memory traffic. To further
> + * complicate matters, the viewport must start on a
> + * pcie-address that is aligned on a multiple of its size.
> + * If a portion of the viewport does not represent system
> + * memory -- e.g. 3GB of memory requires a 4GB viewport --
> + * we can map the outbound memory in or after 3GB and even
> + * though the viewport will overlap the outbound memory
> + * the controller will know to send outbound memory downstream
> + * and everything else upstream.
> */
> rc_bar2_size = roundup_pow_of_two_64(total_mem_size);
>
> @@ -875,7 +1179,7 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
> if (dma_ranges) {
> /*
> * The best-case scenario is to place the inbound
> - * region in the first 4GB of pci-space, as some
> + * region in the first 4GB of pcie-space, as some
> * legacy devices can only address 32bits.
> * We would also like to put the MSI under 4GB
> * as well, since some devices require a 32bit
> @@ -884,6 +1188,14 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
> if (total_mem_size <= 0xc0000000ULL &&
> rc_bar2_size <= 0x100000000ULL) {
> rc_bar2_offset = 0;
> + /* If the viewport is less then 4GB we can fit
> + * the MSI target address under 4GB. Otherwise
> + * put it right below 64GB.
> + */
> + msi_target_addr =
> + (rc_bar2_size == 0x100000000ULL)
> + ? BRCM_MSI_TARGET_ADDR_GT_4GB
> + : BRCM_MSI_TARGET_ADDR_LT_4GB;
> } else {
> /*
> * The system memory is 4GB or larger so we
> @@ -893,8 +1205,12 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
> * start it at the 1x multiple of its size
> */
> rc_bar2_offset = rc_bar2_size;
> - }
>
> + /* Since we are starting the viewport at 4GB or
> + * higher, put the MSI target address below 4GB
> + */
> + msi_target_addr = BRCM_MSI_TARGET_ADDR_LT_4GB;
> + }
> } else {
> /*
> * Set simple configuration based on memory sizes
> @@ -902,7 +1218,12 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
> * and set the MSI target address accordingly.
> */
> rc_bar2_offset = 0;
> +
> + msi_target_addr = (rc_bar2_size >= 0x100000000ULL)
> + ? BRCM_MSI_TARGET_ADDR_GT_4GB
> + : BRCM_MSI_TARGET_ADDR_LT_4GB;
> }
> + pcie->msi_target_addr = msi_target_addr;
>
> tmp = lower_32_bits(rc_bar2_offset);
> tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
> @@ -1076,6 +1397,9 @@ static int brcm_pcie_resume(struct device *dev)
> if (ret)
> return ret;
>
> + if (pcie->msi && pcie->msi_internal)
> + brcm_msi_set_regs(pcie->msi);
> +
> pcie->suspended = false;
>
> return 0;
> @@ -1083,6 +1407,7 @@ static int brcm_pcie_resume(struct device *dev)
>
> static void _brcm_pcie_remove(struct brcm_pcie *pcie)
> {
> + brcm_msi_remove(pcie->msi);
> turn_off(pcie);
> clk_disable_unprepare(pcie->clk);
> clk_put(pcie->clk);
> @@ -1111,7 +1436,7 @@ static int brcm_pcie_remove(struct platform_device *pdev)
>
> static int brcm_pcie_probe(struct platform_device *pdev)
> {
> - struct device_node *dn = pdev->dev.of_node;
> + struct device_node *dn = pdev->dev.of_node, *msi_dn;
> const struct of_device_id *of_id;
> const struct pcie_cfg_data *data;
> int ret;
> @@ -1194,6 +1519,28 @@ static int brcm_pcie_probe(struct platform_device *pdev)
> if (ret)
> goto fail;
>
> + msi_dn = of_parse_phandle(pcie->dn, "msi-parent", 0);
> + /* Use the internal MSI if no msi-parent property */
> + if (!msi_dn)
> + msi_dn = pcie->dn;
> +
> + if (pci_msi_enabled() && msi_dn == pcie->dn) {
> + struct brcm_info info;
> +
> + info.rev = pcie->rev;
> + info.msi_target_addr = pcie->msi_target_addr;
> + info.base = pcie->base;
> +
> + ret = brcm_msi_probe(pdev, &info);
> + if (ret)
> + dev_err(pcie->dev,
> + "probe of internal MSI failed: %d)", ret);
> + else
> + pcie->msi_internal = true;
> +
> + pcie->msi = info.msi;
> + }
> +
> list_splice_init(&pcie->resources, &bridge->windows);
> bridge->dev.parent = &pdev->dev;
> bridge->busnr = 0;
> @@ -1216,7 +1563,6 @@ static int brcm_pcie_probe(struct platform_device *pdev)
> pcie->root_bus = bridge->bus;
>
> return 0;
> -
> fail:
> _brcm_pcie_remove(pcie);
> return ret;
> --
> 1.9.0.138.g2de3478
>
^ permalink raw reply
* [PATCH v5 4/9] drivers: base cacheinfo: Add support for ACPI based firmware tables
From: Jeremy Linton @ 2017-12-12 22:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0hHdfE3khVvuqQm5JFMgY5R054c8UB9Nixii9ucq0Ecnw@mail.gmail.com>
Hi,
On 12/12/2017 11:25 AM, Rafael J. Wysocki wrote:
> On Tue, Dec 12, 2017 at 6:03 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
>> Hi,
>>
>>
>> On 12/11/2017 07:11 PM, Rafael J. Wysocki wrote:
>>>
>>> On Friday, December 1, 2017 11:23:25 PM CET Jeremy Linton wrote:
>>>>
>>>> Add a entry to to struct cacheinfo to maintain a reference to the PPTT
>>>> node which can be used to match identical caches across cores. Also
>>>> stub out cache_setup_acpi() so that individual architectures can
>>>> enable ACPI topology parsing.
>>>>
>>>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>>>> ---
>>>> drivers/acpi/pptt.c | 1 +
>>>> drivers/base/cacheinfo.c | 20 ++++++++++++++------
>>>> include/linux/cacheinfo.h | 13 ++++++++++++-
>>>> 3 files changed, 27 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
>>>> index 0f8a1631af33..a35e457cefb7 100644
>>>> --- a/drivers/acpi/pptt.c
>>>> +++ b/drivers/acpi/pptt.c
>>>> @@ -329,6 +329,7 @@ static void update_cache_properties(struct cacheinfo
>>>> *this_leaf,
>>>> {
>>>> int valid_flags = 0;
>>>> + this_leaf->firmware_node = cpu_node;
>>>> if (found_cache->flags & ACPI_PPTT_SIZE_PROPERTY_VALID) {
>>>> this_leaf->size = found_cache->size;
>>>> valid_flags++;
>>>> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
>>>> index eb3af2739537..ba89f9310e6f 100644
>>>> --- a/drivers/base/cacheinfo.c
>>>> +++ b/drivers/base/cacheinfo.c
>>>> @@ -86,7 +86,10 @@ static int cache_setup_of_node(unsigned int cpu)
>>>> static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
>>>> struct cacheinfo *sib_leaf)
>>>> {
>>>> - return sib_leaf->of_node == this_leaf->of_node;
>>>> + if (acpi_disabled)
>>>> + return sib_leaf->of_node == this_leaf->of_node;
>>>> + else
>>>> + return sib_leaf->firmware_node ==
>>>> this_leaf->firmware_node;
>>>> }
>>>> /* OF properties to query for a given cache type */
>>>> @@ -215,6 +218,11 @@ static inline bool cache_leaves_are_shared(struct
>>>> cacheinfo *this_leaf,
>>>> }
>>>> #endif
>>>> +int __weak cache_setup_acpi(unsigned int cpu)
>>>> +{
>>>> + return -ENOTSUPP;
>>>> +}
>>>> +
>>>> static int cache_shared_cpu_map_setup(unsigned int cpu)
>>>> {
>>>> struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
>>>> @@ -225,11 +233,11 @@ static int cache_shared_cpu_map_setup(unsigned int
>>>> cpu)
>>>> if (this_cpu_ci->cpu_map_populated)
>>>> return 0;
>>>> - if (of_have_populated_dt())
>>>> + if (!acpi_disabled)
>>>> + ret = cache_setup_acpi(cpu);
>>>> + else if (of_have_populated_dt())
>>>> ret = cache_setup_of_node(cpu);
>>>> - else if (!acpi_disabled)
>>>> - /* No cache property/hierarchy support yet in ACPI */
>>>> - ret = -ENOTSUPP;
>>>> +
>>>> if (ret)
>>>> return ret;
>>>> @@ -286,7 +294,7 @@ static void cache_shared_cpu_map_remove(unsigned
>>>> int cpu)
>>>> static void cache_override_properties(unsigned int cpu)
>>>> {
>>>> - if (of_have_populated_dt())
>>>> + if (acpi_disabled && of_have_populated_dt())
>>>> return cache_of_override_properties(cpu);
>>>> }
>>>> diff --git a/include/linux/cacheinfo.h b/include/linux/cacheinfo.h
>>>> index 3d9805297cda..7ebff157ae6c 100644
>>>> --- a/include/linux/cacheinfo.h
>>>> +++ b/include/linux/cacheinfo.h
>>>> @@ -37,6 +37,8 @@ enum cache_type {
>>>> * @of_node: if devicetree is used, this represents either the cpu node
>>>> in
>>>> * case there's no explicit cache node or the cache node itself in
>>>> the
>>>> * device tree
>>>> + * @firmware_node: When not using DT, this may contain pointers to other
>>>> + * firmware based values. Particularly ACPI/PPTT unique values.
>>>> * @disable_sysfs: indicates whether this node is visible to the user
>>>> via
>>>> * sysfs or not
>>>> * @priv: pointer to any private data structure specific to particular
>>>> @@ -65,8 +67,8 @@ struct cacheinfo {
>>>> #define CACHE_ALLOCATE_POLICY_MASK \
>>>> (CACHE_READ_ALLOCATE | CACHE_WRITE_ALLOCATE)
>>>> #define CACHE_ID BIT(4)
>>>> -
>>>> struct device_node *of_node;
>>>> + void *firmware_node;
>>>
>>>
>>> What about converting this to using struct fwnode instead of adding
>>> fields to it?
>>
>>
>> I didn't really want to add another field here, but I've also pointed out
>> how I thought converting it to a fwnode wasn't a good choice.
>>
>> https://lkml.org/lkml/2017/11/20/502
>>
>> Mostly because IMHO its even more misleading (lacking any fwnode_operations)
>> than misusing the of_node as a void *.
>
> I'm not sure what you mean.
Converting the DT drivers/cacheinfo.c code to use a fwnode_handle is
straightforward. But IMHO it doesn't solve the readability problem of
either casting the ACPI/PPTT token directly to the resulting
fwnode_handle *, or alternatively an actual fwnode_handle with bogus
fwnode_operations to wrap that token.
>
> Anyway, the idea is to have one pointer in there instead of two that
> cannot be used at the same time and there's no reason why of_node
> should be special.
Avoid two pointers for size, or readability? Because the last version
had a union with of_node, which isn't strictly necessary as I can just
cast the pptt token to of_node. There is exactly one line of code after
that which uses the token and it doesn't care about type.
(in cache_leaves_are_shared())
>
> of_node should just be one of multiple choices.
>
>> Given that I'm in the minority thinking this, how far down the fwnode path
>> on the ACPI side do we want to go?
>
> I have no idea. :-)
>
>> Is simply treating it as a void pointer
>> sufficient for the ACPI side, considering all the PPTT code needs is a
>> unique token?
>
> I guess you can think about it as of_node under a different name, but
> whether or not this is sufficient depends on what you need it for.
>
> Thanks,
> Rafael
>
^ permalink raw reply
* How to debug "insecure W+X mapping"?
From: Timur Tabi @ 2017-12-12 22:57 UTC (permalink / raw)
To: linux-arm-kernel
We have a 4.10-based kernel that occasionally displays an insecure W+X
mapping (courtesy of CONFIG_DEBUG_WX):
[ 7.151680] arm64/mm: Found insecure W+X mapping at address
0000345a049d2000/0x345a049d2000
...
[ 7.435481] Checked W+X mappings: FAILED, 4 W+X pages found, 0
non-UXN pages found
The number of actual W+X pages varies, e.g. sometimes it says 6 pages.
How do I go about debugging this? How do I identify the source of
0000345a049d2000?
--
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
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