* [PATCH -next] mmc: aspeed: Fix return value check in aspeed_sdc_probe()
From: Wei Yongjun @ 2019-08-26 12:00 UTC (permalink / raw)
To: Adrian Hunter, Ulf Hansson, Joel Stanley, Andrew Jeffery
Cc: linux-mmc, kernel-janitors, Wei Yongjun, linux-aspeed,
linux-arm-kernel
In case of error, the function of_platform_device_create() returns
NULL pointer not ERR_PTR(). The IS_ERR() test in the return value
check should be replaced with NULL test.
Fixes: 09eed7fffd33 ("mmc: Add support for the ASPEED SD controller")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/mmc/host/sdhci-of-aspeed.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-aspeed.c b/drivers/mmc/host/sdhci-of-aspeed.c
index 8bb095ca2fa9..d5acb5afc50f 100644
--- a/drivers/mmc/host/sdhci-of-aspeed.c
+++ b/drivers/mmc/host/sdhci-of-aspeed.c
@@ -261,9 +261,9 @@ static int aspeed_sdc_probe(struct platform_device *pdev)
struct platform_device *cpdev;
cpdev = of_platform_device_create(child, NULL, &pdev->dev);
- if (IS_ERR(cpdev)) {
+ if (!cpdev) {
of_node_put(child);
- ret = PTR_ERR(cpdev);
+ ret = -ENODEV;
goto err_clk;
}
}
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RFC PATCH V3 2/4] media: platform: Add Mediatek sensor interface driver KConfig
From: Sakari Ailus @ 2019-08-26 11:53 UTC (permalink / raw)
To: Louis Kuo
Cc: devicetree, Sean.Cheng, laurent.pinchart+renesas, Rynn.Wu,
christie.yu, srv_heupstream, holmes.chiou, Jerry-ch.Chen, tfiga,
keiichiw, jungo.lin, sj.huang, yuzhao, hans.verkuil, zwisler,
frederic.chen, matthias.bgg, linux-mediatek, mchehab,
linux-arm-kernel, linux-media
In-Reply-To: <1559815233-24796-3-git-send-email-louis.kuo@mediatek.com>
On Thu, Jun 06, 2019 at 06:00:31PM +0800, Louis Kuo wrote:
> This patch adds KConfig for sensor interface driver. Sensor interface
> driver
> is a MIPI-CSI2 host driver, namely, a HW camera interface controller.
> It support a widely adopted, simple, high-speed protocol primarily
> intended
> for point-to-point image and video transmission between cameras and host
> devices.
>
> Signed-off-by: Louis Kuo <louis.kuo@mediatek.com>
> ---
> drivers/media/platform/mtk-isp/Kconfig | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> create mode 100644 drivers/media/platform/mtk-isp/Kconfig
>
> diff --git a/drivers/media/platform/mtk-isp/Kconfig b/drivers/media/platform/mtk-isp/Kconfig
> new file mode 100644
> index 0000000..bc7fd01
> --- /dev/null
> +++ b/drivers/media/platform/mtk-isp/Kconfig
> @@ -0,0 +1,17 @@
> +config MTK_SENINF
> + bool "Mediatek mipi csi2 driver"
> + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> + depends on MEDIA_CAMERA_SUPPORT
> + select V4L2_FWNODE
> +
> + default n
> + help
> + This driver provides a mipi-csi2 host driver used as a
> + interface to connect camera with Mediatek's
> + MT8183 SOCs. It is able to handle multiple cameras
> + at the same time.
> +
> + Choose y if you want to use Mediatek SoCs to create image
> + capture application such as video recording and still image
> + capture.
Rather than being a separate patch, this should go in with the driver.
The DT bindings should precede the driver, and you'll need a MAINTAINERS
entry for the driver, too.
--
Sakari Ailus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH V3 3/4] dt-bindings: mt8183: Add sensor interface dt-bindings
From: Sakari Ailus @ 2019-08-26 11:52 UTC (permalink / raw)
To: Louis Kuo
Cc: devicetree, Sean.Cheng, laurent.pinchart+renesas, Rynn.Wu,
christie.yu, srv_heupstream, holmes.chiou, Jerry-ch.Chen, tfiga,
keiichiw, jungo.lin, sj.huang, yuzhao, hans.verkuil, zwisler,
frederic.chen, matthias.bgg, linux-mediatek, mchehab,
linux-arm-kernel, linux-media
In-Reply-To: <1559815233-24796-4-git-send-email-louis.kuo@mediatek.com>
Hi Louis,
On Thu, Jun 06, 2019 at 06:00:32PM +0800, Louis Kuo wrote:
> This patch adds the DT binding documentation for the sensor interface
> module in Mediatek SoCs.
>
> Signed-off-by: Louis Kuo <louis.kuo@mediatek.com>
> ---
> .../devicetree/bindings/media/mediatek-seninf.txt | 31 ++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/mediatek-seninf.txt
>
> diff --git a/Documentation/devicetree/bindings/media/mediatek-seninf.txt b/Documentation/devicetree/bindings/media/mediatek-seninf.txt
> new file mode 100644
> index 0000000..979063a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/mediatek-seninf.txt
> @@ -0,0 +1,31 @@
> +* Mediatek seninf MIPI-CSI2 host driver
Note that DT bindings document the hardware, not the driver implementation.
> +
> +Seninf MIPI-CSI2 host driver is a HW camera interface controller. It support a widely adopted,
Same here; driver apparently refers to software.
Please wrap before or at 80 characters per line.
> +simple, high-speed protocol primarily intended for point-to-point image and video
> +transmission between cameras and host devices.
Could you elaborate the properties of the hardware in a bit more detail,
such as how many ports there are and how many lanes they can support? See
e.g. Documentation/devicetree/bindings/media/ti,omap3isp.txt .
Please also refer to video-interfaces.txt and document the port nodes and
the relevant properties in the endpoint nodes, as in the binding example I
referred to.
> +
> +Required properties:
> + - compatible: "mediatek,mt8183-seninf"
> + - reg: Must contain an entry for each entry in reg-names.
> + - reg-names: Must include the following entries:
> + "base_reg": seninf registers base
> + "rx_reg": Rx analog registers base
> + - interrupts: interrupt number to the cpu.
> + - clocks : clock name from clock manager
> + - clock-names: must be CLK_CAM_SENINF and CLK_TOP_MUX_SENINF.
> + It is the clocks of seninf
> +
> +Example:
> + seninf: seninf@1a040000 {
> + compatible = "mediatek,mt8183-seninf";
> + reg = <0 0x1a040000 0 0x8000>,
> + <0 0x11C80000 0 0x6000>;
> + reg-names = "base_reg", "rx_reg";
> + interrupts = <GIC_SPI 251 IRQ_TYPE_LEVEL_LOW>;
> + power-domains = <&scpsys MT8183_POWER_DOMAIN_CAM>;
> + clocks =
> + <&camsys CLK_CAM_SENINF>, <&topckgen CLK_TOP_MUX_SENINF>;
Please wrap before 80 and align the above two lines.
> + clock-names =
> + "CLK_CAM_SENINF", "CLK_TOP_MUX_SENINF";
No need to wrap here.
> + }
> +
> --
> 1.9.1
This must be old.
--
Regards,
Sakari Ailus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC 5/9] dt-bindings: arm: samsung: Convert Exynos PMU bindings to json-schema
From: Rob Herring @ 2019-08-26 11:54 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni,
Lars-Peter Clausen, Arnd Bergmann, devicetree,
open list:IIO SUBSYSTEM AND DRIVERS, Marek Szyprowski,
linux-kernel@vger.kernel.org, Tomasz Figa, linux-samsung-soc,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Peter Meerwald-Stadler, Hartmut Knaack, Olof Johansson,
open list:REAL TIME CLOCK (RTC) SUBSYSTEM, notify,
Jonathan Cameron, Paweł Chmiel
In-Reply-To: <20190823145356.6341-5-krzk@kernel.org>
On Fri, Aug 23, 2019 at 9:54 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> Convert Samsung Exynos Power Management Unit (PMU) bindings to DT schema
> format using json-schema.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> .../devicetree/bindings/arm/samsung/pmu.txt | 72 --------------
> .../devicetree/bindings/arm/samsung/pmu.yaml | 93 +++++++++++++++++++
> 2 files changed, 93 insertions(+), 72 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/samsung/pmu.txt
> create mode 100644 Documentation/devicetree/bindings/arm/samsung/pmu.yaml
> diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.yaml b/Documentation/devicetree/bindings/arm/samsung/pmu.yaml
> new file mode 100644
> index 000000000000..818c6f3488ef
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/samsung/pmu.yaml
> @@ -0,0 +1,93 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/samsung/pmu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Samsung Exynos SoC series Power Management Unit (PMU)
> +
> +maintainers:
> + - Krzysztof Kozlowski <krzk@kernel.org>
> +
> +properties:
> + compatible:
> + items:
> + - enum:
> + - samsung,exynos3250-pmu
> + - samsung,exynos4210-pmu
> + - samsung,exynos4412-pmu
> + - samsung,exynos5250-pmu
> + - samsung,exynos5260-pmu
> + - samsung,exynos5410-pmu
> + - samsung,exynos5420-pmu
> + - samsung,exynos5433-pmu
> + - samsung,exynos7-pmu
> + - const: syscon
> +
> + reg:
> + maxItems: 1
> +
> + '#clock-cells':
> + const: 1
> +
> + clock-names:
> + description:
> + list of clock names for particular CLKOUT mux inputs
> + # TODO: what is the maximum number of elements (mux inputs)?
> + minItems: 1
> + maxItems: 32
> + items:
> + - enum:
This isn't correct as you are only defining possible names for the
first item. Drop the '-' (making items a schema instead of a list) and
then it applies to all. However, doing that will cause a meta-schema
error which I need to fix to allow. Or if there's a small set of
possibilities of number of inputs, you can list them under a 'oneOf'
list.
> + - clkout0
> + - clkout1
> + - clkout2
> + - clkout3
> + - clkout4
> + - clkout5
> + - clkout6
> + - clkout7
> + - clkout8
> + - clkout9
> + - clkout10
> + - clkout11
> + - clkout12
> + - clkout13
> + - clkout14
> + - clkout15
> + - clkout16
> +
> + clocks:
> + minItems: 1
> + maxItems: 32
> +
> + interrupt-controller:
> + description:
> + Some PMUs are capable of behaving as an interrupt controller (mostly
> + to wake up a suspended PMU).
> +
> + '#interrupt-cells':
> + # TODO: must be identical to the that of the parent interrupt controller.
There's not really a way to express that. Just state that in the
description if you want.
> + const: 3
> +
> + # TODO: Mark interrupt-controller and #interrupt-cells as required, if one is present
No need, the core schemas handle that dependency. It would be good to
define for which compatibles the properties are required. You can do
this with if/then schema. There's several examples in the tree.
> + # TODO: nodes defining the restart and poweroff syscon children
> +
> +required:
> + - compatible
> + - reg
> + - '#clock-cells'
> + - clock-names
> + - clocks
> +
> +examples:
> + - |
> + pmu_system_controller: system-controller@10040000 {
> + compatible = "samsung,exynos5250-pmu", "syscon";
> + reg = <0x10040000 0x5000>;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + interrupt-parent = <&gic>;
> + #clock-cells = <1>;
> + clock-names = "clkout16";
> + clocks = <&clock 0>; // CLK_FIN_PLL
> + };
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 00/19] Enhance CP110 COMPHY support
From: Kishon Vijay Abraham I @ 2019-08-26 11:51 UTC (permalink / raw)
To: Miquel Raynal
Cc: Andrew Lunn, Jason Cooper, devicetree, Antoine Tenart,
Grzegorz Jaszczyk, Gregory Clement, Russell King,
Maxime Chevallier, Nadav Haklai, Matt Pelland, Rob Herring,
Thomas Petazzoni, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20190824135414.5c490337@xps13>
Hi,
On 24/08/19 5:24 PM, Miquel Raynal wrote:
> Hi Kishon,
>
> + Matt Pelland
>
> Kishon Vijay Abraham I <kishon@ti.com> wrote on Fri, 23 Aug 2019
> 08:46:14 +0530:
>
>> On 31/07/19 5:51 PM, Miquel Raynal wrote:
>>> Armada CP110 have a COMPHY IP which supports configuring SERDES lanes
>>> in one mode, either:
>>> - SATA
>>> - USB3 host
>>> - PCIe (several width)
>>> - Ethernet (several modes)
>>>
>>> As of today, only a few Ethernet modes are supported and the code is
>>> embedded in the Linux driver. A more complete COMPHY driver that can
>>> be used by both Linux and U-Boot is embedded in the firmware and can
>>> be run through SMC calls.
>>>
>>> First the current COMPHY driver is updated to use SMC calls but
>>> fallbacks to the already existing functions if the firmware is not
>>> up-to-date. Then, more Ethernet modes are added (through SMC calls
>>> only). SATA, USB3H and PCIe modes are also supported one by one.
>>>
>>> There is one subtle difference with the PCIe functions: we must tell
>>> the firmware the number of lanes to configure (x1, x2 or x4). This
>>> parameter depends on the number of entries in the 'phys' property
>>> describing the PCIe PHY. We use the "submode" parameter of the generic
>>> PHY API to carry this value. The Armada-8k PCIe driver has been
>>> updated to follow this idea and this change has been merged already:
>>> http://patchwork.ozlabs.org/patch/1072763/
>>
>> Some of the patches are not applying cleanly. Care to resend the series after
>> rebasing to phy -next?
>
> Besides two conflicts that I can fix very easily about missing
> of_node_put() calls, you just merged in phy-next this patch:
>
> phy: marvell: phy-mvebu-cp110-comphy: implement RXAUI support
>
> Which totally conflicts with my series while I also add RXAUI support
> in patch 5. Please note that even the third version of my series
> was contributed before this patch.
>
> There is one difference to note though: in the patch from Matt Peland,
> RXAUI support is embedded in the driver while I do SMC calls.
>
> Anyway, would it be possible to change the order of application if
> you want both methods in the driver because it will be much easier
> to add Matt's patch on top of my series than the opposite. I can
> even do it myself if you wish.
I've resolved this. Can you review in phy -next if the changes looks okay?
Thanks
Kishon
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V5 1/3] mmc: mmci: add hardware busy timeout feature
From: Ulf Hansson @ 2019-08-26 11:39 UTC (permalink / raw)
To: Ludovic Barre
Cc: DTML, Alexandre Torgue, linux-mmc@vger.kernel.org,
Linux Kernel Mailing List, Rob Herring, Srinivas Kandagatla,
Maxime Coquelin, linux-stm32, Linux ARM
In-Reply-To: <20190813095951.26275-2-ludovic.Barre@st.com>
On Tue, 13 Aug 2019 at 12:00, Ludovic Barre <ludovic.Barre@st.com> wrote:
>
> From: Ludovic Barre <ludovic.barre@st.com>
>
> In some variants, the data timer starts and decrements
> when the DPSM enters in Wait_R or Busy state
> (while data transfer or MMC_RSP_BUSY), and generates a
> data timeout error if the counter reach 0.
I don't quite follow here, sorry. Can you please try to elaborate on
the use case(s) more exactly?
For example, what happens when a data transfer has just finished (for
example when MCI_DATAEND has been received) and we are going to send a
CMD12 to stop it? In this case the CMD12 has the MMC_RSP_BUSY flag
set.
Another example is the CMD5, which has no data with it.
>
> -Define max_busy_timeout (in ms) according to clock.
> -Set data timer register if the command has rsp_busy flag.
> If busy_timeout is not defined by framework, the busy
> length after Data Burst is defined as 1 second
> (refer: 4.6.2.2 Write of sd specification part1 v6-0).
One second is not sufficient for all operations, like ERASE for
example. However, I understand that you want to pick some value, as a
safety. I guess that's fine.
I am thinking that if the command has the MMC_RSP_BUSY flag set, the
core should really provide a busy timeout for it. That said, maybe the
host driver should splat a WARN in case there is not busy timeout
specified.
> -Add MCI_DATATIMEOUT error management in mmci_cmd_irq.
>
> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> ---
> drivers/mmc/host/mmci.c | 37 ++++++++++++++++++++++++++++++++-----
> drivers/mmc/host/mmci.h | 3 +++
> 2 files changed, 35 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> index c37e70dbe250..c50586540765 100644
> --- a/drivers/mmc/host/mmci.c
> +++ b/drivers/mmc/host/mmci.c
> @@ -1075,6 +1075,7 @@ static void
> mmci_start_command(struct mmci_host *host, struct mmc_command *cmd, u32 c)
> {
> void __iomem *base = host->base;
> + unsigned long long clks = 0;
>
> dev_dbg(mmc_dev(host->mmc), "op %02x arg %08x flags %08x\n",
> cmd->opcode, cmd->arg, cmd->flags);
> @@ -1097,6 +1098,19 @@ mmci_start_command(struct mmci_host *host, struct mmc_command *cmd, u32 c)
> else
> c |= host->variant->cmdreg_srsp;
> }
> +
> + if (host->variant->busy_timeout && !host->mrq->data) {
Suppose this is a CMD12 command, having the MMC_RSP_BUSY flag set. The
command would then be sent to stop the transmission and then
host->mrq->data would also be set.
If I recall earlier what you stated about the new sdmmc variant, the
CMD12 is needed to exit the DPSM. Hence don't you need to re-program a
new value for the MMCIDATATIMER register for this scenario?
> + if (cmd->flags & MMC_RSP_BUSY) {
> + if (!cmd->busy_timeout)
> + cmd->busy_timeout = 1000;
> +
> + clks = (unsigned long long)cmd->busy_timeout;
> + clks *= host->cclk;
Any problems with putting the above on one line?
> + do_div(clks, MSEC_PER_SEC);
> + }
> + writel_relaxed(clks, host->base + MMCIDATATIMER);
This is writing zero to MMCIDATATIMER in case the MMC_RSP_BUSY isn't
set, is that on purpose?
> + }
> +
> if (/*interrupt*/0)
> c |= MCI_CPSM_INTERRUPT;
>
> @@ -1203,6 +1217,7 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
> {
> void __iomem *base = host->base;
> bool sbc, busy_resp;
> + u32 err_msk;
>
> if (!cmd)
> return;
> @@ -1215,8 +1230,12 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
> * handling. Note that we tag on any latent IRQs postponed
> * due to waiting for busy status.
> */
> - if (!((status|host->busy_status) &
> - (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT|MCI_CMDSENT|MCI_CMDRESPEND)))
> + err_msk = MCI_CMDCRCFAIL | MCI_CMDTIMEOUT;
You might as well move the initial assignment of err_msk to the its
declaration above.
> + if (host->variant->busy_timeout && busy_resp)
> + err_msk |= MCI_DATATIMEOUT;
> +
> + if (!((status | host->busy_status) &
> + (err_msk | MCI_CMDSENT | MCI_CMDRESPEND)))
> return;
>
> /* Handle busy detection on DAT0 if the variant supports it. */
> @@ -1235,8 +1254,7 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
> * while, to allow it to be set, but tests indicates that it
> * isn't needed.
> */
> - if (!host->busy_status &&
> - !(status & (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT)) &&
> + if (!host->busy_status && !(status & err_msk) &&
> (readl(base + MMCISTATUS) & host->variant->busy_detect_flag)) {
>
> writel(readl(base + MMCIMASK0) |
> @@ -1290,6 +1308,9 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
> cmd->error = -ETIMEDOUT;
> } else if (status & MCI_CMDCRCFAIL && cmd->flags & MMC_RSP_CRC) {
> cmd->error = -EILSEQ;
> + } else if (host->variant->busy_timeout && busy_resp &&
> + status & MCI_DATATIMEOUT) {
> + cmd->error = -ETIMEDOUT;
> } else {
> cmd->resp[0] = readl(base + MMCIRESPONSE0);
> cmd->resp[1] = readl(base + MMCIRESPONSE1);
> @@ -1948,6 +1969,8 @@ static int mmci_probe(struct amba_device *dev,
> * Enable busy detection.
> */
> if (variant->busy_detect) {
> + u32 max_busy_timeout = 0;
> +
> mmci_ops.card_busy = mmci_card_busy;
> /*
> * Not all variants have a flag to enable busy detection
> @@ -1957,7 +1980,11 @@ static int mmci_probe(struct amba_device *dev,
> mmci_write_datactrlreg(host,
> host->variant->busy_dpsm_flag);
> mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY;
> - mmc->max_busy_timeout = 0;
> +
> + if (variant->busy_timeout)
> + max_busy_timeout = ~0UL / (mmc->f_max / MSEC_PER_SEC);
It looks like the max busy timeout is depending on the current picked
clock rate, right?
In such case, perhaps it's better to update mmc->max_busy_timeout as
part of the ->set_ios() callback, as it's from there the clock rate
gets updated. Or what do you think?
> +
> + mmc->max_busy_timeout = max_busy_timeout;
> }
>
> /* Prepare a CMD12 - needed to clear the DPSM on some variants. */
> diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
> index 833236ecb31e..d8b7f6774e8f 100644
> --- a/drivers/mmc/host/mmci.h
> +++ b/drivers/mmc/host/mmci.h
> @@ -287,6 +287,8 @@ struct mmci_host;
> * @signal_direction: input/out direction of bus signals can be indicated
> * @pwrreg_clkgate: MMCIPOWER register must be used to gate the clock
> * @busy_detect: true if the variant supports busy detection on DAT0.
> + * @busy_timeout: true if the variant starts data timer when the DPSM
> + * enter in Wait_R or Busy state.
> * @busy_dpsm_flag: bitmask enabling busy detection in the DPSM
> * @busy_detect_flag: bitmask identifying the bit in the MMCISTATUS register
> * indicating that the card is busy
> @@ -333,6 +335,7 @@ struct variant_data {
> u8 signal_direction:1;
> u8 pwrreg_clkgate:1;
> u8 busy_detect:1;
> + u8 busy_timeout:1;
> u32 busy_dpsm_flag;
> u32 busy_detect_flag;
> u32 busy_detect_mask;
> --
> 2.17.1
>
Kind regards
Uffe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC 1/9] dt-bindings: arm: samsung: Convert Samsung board/soc bindings to json-schema
From: Rob Herring @ 2019-08-26 11:37 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni,
Lars-Peter Clausen, Arnd Bergmann, devicetree,
open list:IIO SUBSYSTEM AND DRIVERS, Marek Szyprowski,
linux-kernel@vger.kernel.org, Tomasz Figa, linux-samsung-soc,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Peter Meerwald-Stadler, Hartmut Knaack, Olof Johansson,
open list:REAL TIME CLOCK (RTC) SUBSYSTEM, notify,
Jonathan Cameron, Paweł Chmiel
In-Reply-To: <20190823145356.6341-1-krzk@kernel.org>
On Fri, Aug 23, 2019 at 9:54 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> Convert Samsung S5P and Exynos SoC bindings to DT schema format using
> json-schema. This is purely conversion of already documented bindings
> so it does not cover all of DTS in the Linux kernel (few S5P/Exynos and
> all S3C are missing).
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> ---
>
> If the schema looks sensible, I will continue on converting other
> SoC and driver bindings and later adding missing schemas (S3C
> SoCs).
Looks pretty good.
> ---
> .../bindings/arm/samsung/samsung-boards.txt | 83 --------
> .../bindings/arm/samsung/samsung-boards.yaml | 188 ++++++++++++++++++
> 2 files changed, 188 insertions(+), 83 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
> create mode 100644 Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
> diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
> new file mode 100644
> index 000000000000..e963fd70c436
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
> @@ -0,0 +1,188 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/samsung/samsung-boards.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Samsung Exynos and S5P SoC based boards
> +
> +maintainers:
> + - Krzysztof Kozlowski <krzk@kernel.org>
> +
> +properties:
> + $nodename:
> + const: '/'
> + compatible:
> + oneOf:
> + - description: S5PV210 based Aries boards
> + items:
> + - enum:
> + - samsung,fascinate4g # Samsung Galaxy S Fascinate 4G (SGH-T959P)
> + - samsung,galaxys # Samsung Galaxy S (i9000)
> + - const: samsung,aries
> + - const: samsung,s5pv210
> +
> + - description: Exynos3250 based boards
> + items:
> + - enum:
> + - samsung,monk # Samsung Simband
> + - samsung,rinato # Samsung Gear2
> + - const: samsung,exynos3250
> + - const: samsung,exynos3
> +
> + - description: Samsung ARTIK5 boards
> + items:
> + - enum:
> + - samsung,artik5-eval # Samsung ARTIK5 eval board
> + - const: samsung,artik5 # Samsung ARTIK5 module
> + - const: samsung,exynos3250
> + - const: samsung,exynos3
> +
> + - description: Exynos4210 based boards
> + items:
> + - enum:
> + - insignal,origen # Insignal Origen
> + - samsung,smdkv310 # Samsung SMDKV310 eval
> + - samsung,trats # Samsung Tizen Reference
> + - samsung,universal_c210 # Samsung C210
> + - const: samsung,exynos4210
> + - const: samsung,exynos4
> +
> + - description: Exynos4412 based boards
> + items:
> + - enum:
> + - friendlyarm,tiny4412 # FriendlyARM TINY4412
> + - hardkernel,odroid-u3 # Hardkernel Odroid U3
> + - hardkernel,odroid-x # Hardkernel Odroid X
> + - hardkernel,odroid-x2 # Hardkernel Odroid X2
> + - insignal,origen4412 # Insignal Origen
> + - samsung,smdk4412 # Samsung SMDK4412 eval
> + - topeet,itop4412-elite # TOPEET Elite base
> + - const: samsung,exynos4412
> + - const: samsung,exynos4
> +
> + - description: Samsung Midas family boards
> + items:
> + - enum:
> + - samsung,i9300 # Samsung GT-I9300
> + - samsung,i9305 # Samsung GT-I9305
> + - samsung,n710x # Samsung GT-N7100/GT-N7105
> + - samsung,trats2 # Samsung Tizen Reference
> + - const: samsung,midas
> + - const: samsung,exynos4412
> + - const: samsung,exynos4
> +
> + - description: Exynos5250 based boards
> + items:
> + - enum:
> + - google,snow-rev5 # Google Snow Rev 5+
> + - google,spring # Google Spring
> + - insignal,arndale # Insignal Arndale
> + - samsung,smdk5250 # Samsung SMDK5250 eval
> + - const: samsung,exynos5250
> + - const: samsung,exynos5
> +
> + - description: Google Snow Boards (Rev 4+)
> + items:
> + - enum:
> + - google,snow-rev4
const here as I wouldn't expect this list to grow.
> + - const: google,snow
> + - const: samsung,exynos5250
> + - const: samsung,exynos5
> +
> + - description: Exynos5260 based boards
> + items:
> + - enum:
> + - samsung,xyref5260 # Samsung Xyref5260 eval
> + - const: samsung,exynos5260
> + - const: samsung,exynos5
> +
> + - description: Exynos5410 based boards
> + items:
> + - enum:
> + - hardkernel,odroid-xu # Hardkernel Odroid XU
> + - samsung,smdk5410 # Samsung SMDK5410 eval
> + - const: samsung,exynos5410
> + - const: samsung,exynos5
> +
> + - description: Exynos5420 based boards
> + items:
> + - enum:
> + - insignal,arndale-octa # Insignal Arndale Octa
> + - samsung,smdk5420 # Samsung SMDK5420 eval
> + - const: samsung,exynos5420
> + - const: samsung,exynos5
> +
> + - description: Google Peach Pit Boards (Rev 6+)
> + items:
> + - enum:
> + - google,pit-rev16
const
> + - const: google,pit-rev15
> + - const: google,pit-rev14
> + - const: google,pit-rev13
> + - const: google,pit-rev12
> + - const: google,pit-rev11
> + - const: google,pit-rev10
> + - const: google,pit-rev9
> + - const: google,pit-rev8
> + - const: google,pit-rev7
> + - const: google,pit-rev6
> + - const: google,pit
> + - const: google,peach
> + - const: samsung,exynos5420
> + - const: samsung,exynos5
> +
> + - description: Exynos5800 based boards
> + items:
> + - enum:
> + - hardkernel,odroid-xu3 # Hardkernel Odroid XU3
> + - hardkernel,odroid-xu3-lite # Hardkernel Odroid XU3 Lite
> + - hardkernel,odroid-xu4 # Hardkernel Odroid XU4
> + - hardkernel,odroid-hc1 # Hardkernel Odroid HC1
> + - const: samsung,exynos5800
> + - const: samsung,exynos5
> +
> + - description: Google Peach Pi Boards (Rev 10+)
> + items:
> + - enum:
> + - google,pi-rev16
> + - const: google,pi-rev15
> + - const: google,pi-rev14
> + - const: google,pi-rev13
> + - const: google,pi-rev12
> + - const: google,pi-rev11
> + - const: google,pi-rev10
> + - const: google,pi
> + - const: google,peach
> + - const: samsung,exynos5800
> + - const: samsung,exynos5
> +
> + - description: Exynos5433 based boards
> + items:
> + - enum:
> + - samsung,tm2 # Samsung TM2
> + - samsung,tm2e # Samsung TM2E
> + - const: samsung,exynos5433
> +
> + firmware:
This should be moved to its own file.
> + type: object
> + description:
> + node specifying presence and type of secure firmware
> + properties:
> + compatible:
> + enum:
> + - samsung,secure-firmware
> + reg:
> + description:
> + address of non-secure SYSRAM used for communication with firmware
> + maxItems: 1
> +
> +required:
> + - compatible
> +
> +examples:
> + - |
> + firmware@203f000 {
> + compatible = "samsung,secure-firmware";
> + reg = <0x0203F000 0x1000>;
> + };
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 09/11] dma-direct: turn ARCH_ZONE_DMA_BITS into a variable
From: Michael Ellerman @ 2019-08-26 11:33 UTC (permalink / raw)
To: Nicolas Saenz Julienne, catalin.marinas, hch, wahrenst,
marc.zyngier, robh+dt, Robin Murphy, linux-arm-kernel, devicetree,
linux-arch, iommu, linux-mm, linux-riscv, Marek Szyprowski
Cc: linux-s390, f.fainelli, Vasily Gorbik, Christian Borntraeger,
frowand.list, linuxppc-dev, Heiko Carstens, linux-kernel, eric,
mbrugger, Paul Mackerras, linux-rpi-kernel,
Benjamin Herrenschmidt, akpm, will, nsaenzjulienne
In-Reply-To: <20190820145821.27214-10-nsaenzjulienne@suse.de>
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> writes:
> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
> index 0d52f57fca04..73668a21ae78 100644
> --- a/arch/powerpc/include/asm/page.h
> +++ b/arch/powerpc/include/asm/page.h
> @@ -319,13 +319,4 @@ struct vm_area_struct;
> #endif /* __ASSEMBLY__ */
> #include <asm/slice.h>
>
> -/*
> - * Allow 30-bit DMA for very limited Broadcom wifi chips on many powerbooks.
This comment got lost.
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index 9191a66b3bc5..2a69f87585df 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -237,9 +238,14 @@ void __init paging_init(void)
> printk(KERN_DEBUG "Memory hole size: %ldMB\n",
> (long int)((top_of_ram - total_ram) >> 20));
>
> + if (IS_ENABLED(CONFIG_PPC32))
Can you please propagate it here?
> + zone_dma_bits = 30;
> + else
> + zone_dma_bits = 31;
> +
cheers
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/6] dt-bindings: pinctrl: k3: Introduce pinmux definitions for J721E
From: Rob Herring @ 2019-08-26 11:25 UTC (permalink / raw)
To: Lokesh Vutla
Cc: Nishanth Menon, Device Tree Mailing List, Keerthy, Linus Walleij,
Tero Kristo, open list:GPIO SUBSYSTEM, Linux ARM Mailing List
In-Reply-To: <da0286cb-8e4c-e12c-240c-b6de72bdd0ee@ti.com>
On Mon, Aug 26, 2019 at 5:27 AM Lokesh Vutla <lokeshvutla@ti.com> wrote:
>
> Hi Rob,
>
> On 22/08/19 2:32 AM, Rob Herring wrote:
> > On Fri, Aug 09, 2019 at 01:59:46PM +0530, Lokesh Vutla wrote:
> >> Add pinctrl macros for J721E SoC. These macro definitions are
> >> similar to that of AM6, but adding new definitions to avoid
> >> any naming confusions in the soc dts files.
> >>
> >> Acked-by: Nishanth Menon <nm@ti.com>
> >> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> >> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
> >> ---
> >> include/dt-bindings/pinctrl/k3.h | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/include/dt-bindings/pinctrl/k3.h b/include/dt-bindings/pinctrl/k3.h
> >> index 45e11b6170ca..499de6216581 100644
> >> --- a/include/dt-bindings/pinctrl/k3.h
> >> +++ b/include/dt-bindings/pinctrl/k3.h
> >> @@ -32,4 +32,7 @@
> >> #define AM65X_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
> >> #define AM65X_WKUP_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
> >>
> >> +#define J721E_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
> >> +#define J721E_WKUP_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
> >
> > checkpatch reports a parentheses error: (((pa) & 0x1fff) ((val) | (muxmode)))
>
> This was left intentionally as this macro is giving out two entries in DT like
> below:
>
> pinctrl-single,pins = <
> J721E_IOPAD(0x0, PIN_INPUT, 7)
> >;
>
> comes out as
>
> pinctrl-single,pins = <
> 0x0 (PIN_INPUT | 7)
> >;
>
> If parenthesis are added for the whole macro, the following build error occurs:
> DTC arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dtb
> Error: arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts:41.24-25 syntax error
> FATAL ERROR: Unable to parse input tree
Okay, NM.
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 10/11] arm64: edit zone_dma_bits to fine tune dma-direct min mask
From: Nicolas Saenz Julienne @ 2019-08-26 11:08 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, devicetree, linux-rpi-kernel, f.fainelli, will, eric,
marc.zyngier, catalin.marinas, frowand.list, linux-kernel,
linux-mm, iommu, robh+dt, wahrenst, mbrugger, linux-riscv,
m.szyprowski, Robin Murphy, akpm, linux-arm-kernel, phill
In-Reply-To: <20190826070633.GB11331@lst.de>
[-- Attachment #1.1: Type: text/plain, Size: 821 bytes --]
On Mon, 2019-08-26 at 09:06 +0200, Christoph Hellwig wrote:
> On Tue, Aug 20, 2019 at 04:58:18PM +0200, Nicolas Saenz Julienne wrote:
> > - if (IS_ENABLED(CONFIG_ZONE_DMA))
> > + if (IS_ENABLED(CONFIG_ZONE_DMA)) {
> > arm64_dma_phys_limit = max_zone_dma_phys();
> > + zone_dma_bits = ilog2((arm64_dma_phys_limit - 1) &
> > GENMASK_ULL(31, 0)) + 1;
>
Hi Christoph,
thanks for the rewiews.
> This adds a way too long line.
I know, I couldn't find a way to split the operation without making it even
harder to read. I'll find a solution.
> I also find the use of GENMASK_ULL
> horribly obsfucating, but I know that opinion is't shared by everyone.
Don't have any preference so I'll happily change it. Any suggestions? Using the
explicit 0xffffffffULL seems hard to read, how about SZ_4GB - 1?
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] ARM: exynos: Enable support for ARM architected timers
From: Marc Zyngier @ 2019-08-26 10:49 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Chanwoo Choi, linux-samsung-soc, Krzysztof Kozlowski,
linux-arm-kernel, Bartlomiej Zolnierkiewicz
In-Reply-To: <20190826103142.3477-4-m.szyprowski@samsung.com>
On 2019-08-26 11:31, Marek Szyprowski wrote:
> ARM architected timer can be used together with Exynos MultiCore
> Timer
> driver, so enable support for it. Support for ARM architected timers
> is
> essential for enabling proper KVM support.
How can you say that this is to "enable KVM support", while in the
previous
patch, you set "arm,cpu-registers-not-fw-configured" which implies that
you're
booting in secure mode with the timer's CP15 registers left to
undefined values?
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 4/4] dt-bindings/watchdog: Add access_cs0 option for alt-boot
From: Ivan Mikhaylov @ 2019-08-26 10:46 UTC (permalink / raw)
To: Guenter Roeck, Wim Van Sebroeck
Cc: Mark Rutland, devicetree, linux-watchdog, linux-aspeed,
Andrew Jeffery, openbmc, Alexander Amelkin, linux-kernel,
Rob Herring, Joel Stanley, Ivan Mikhaylov, linux-arm-kernel
In-Reply-To: <20190826104636.19324-1-i.mikhaylov@yadro.com>
The option for the ast2400/2500 to get access to CS0 at runtime.
Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com>
---
Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt b/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt
index c5077a1f5cb3..023a9b578df6 100644
--- a/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt
@@ -34,6 +34,13 @@ Optional properties:
engine is responsible for this.
- aspeed,alt-boot: If property is present then boot from alternate block.
+ At alternate side 'access_cs0' sysfs file provides:
+ ast2400: a way to get access to the primary SPI flash
+ chip at CS0 after booting from the alternate
+ chip at CS1.
+ ast2500: a way to restore the normal address mapping from
+ (CS0->CS1, CS1->CS0) to (CS0->CS0, CS1->CS1).
+
- aspeed,external-signal: If property is present then signal is sent to
external reset counter (only WDT1 and WDT2). If not
specified no external signal is sent.
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 3/4] watchdog/aspeed: add support for dual boot
From: Ivan Mikhaylov @ 2019-08-26 10:46 UTC (permalink / raw)
To: Guenter Roeck, Wim Van Sebroeck
Cc: Mark Rutland, devicetree, linux-watchdog, linux-aspeed,
Andrew Jeffery, openbmc, Alexander Amelkin, linux-kernel,
Rob Herring, Joel Stanley, Ivan Mikhaylov, linux-arm-kernel
In-Reply-To: <20190826104636.19324-1-i.mikhaylov@yadro.com>
Set WDT_CLEAR_TIMEOUT_AND_BOOT_CODE_SELECTION into WDT_CLEAR_TIMEOUT_STATUS
to clear out boot code source and re-enable access to the primary SPI flash
chip while booted via wdt2 from the alternate chip.
AST2400 datasheet says:
"In the 2nd flash booting mode, all the address mapping to CS0# would be
re-directed to CS1#. And CS0# is not accessable under this mode. To access
CS0#, firmware should clear the 2nd boot mode register in the WDT2 status
register WDT30.bit[1]."
Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com>
---
drivers/watchdog/aspeed_wdt.c | 62 ++++++++++++++++++++++++++++++++++-
1 file changed, 61 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/aspeed_wdt.c b/drivers/watchdog/aspeed_wdt.c
index cc71861e033a..bbc42847c0e3 100644
--- a/drivers/watchdog/aspeed_wdt.c
+++ b/drivers/watchdog/aspeed_wdt.c
@@ -53,6 +53,8 @@ MODULE_DEVICE_TABLE(of, aspeed_wdt_of_table);
#define WDT_CTRL_ENABLE BIT(0)
#define WDT_TIMEOUT_STATUS 0x10
#define WDT_TIMEOUT_STATUS_BOOT_SECONDARY BIT(1)
+#define WDT_CLEAR_TIMEOUT_STATUS 0x14
+#define WDT_CLEAR_TIMEOUT_AND_BOOT_CODE_SELECTION BIT(0)
/*
* WDT_RESET_WIDTH controls the characteristics of the external pulse (if
@@ -165,6 +167,57 @@ static int aspeed_wdt_restart(struct watchdog_device *wdd,
return 0;
}
+/* access_cs0 shows if cs0 is accessible, hence the reverted bit */
+static ssize_t access_cs0_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct aspeed_wdt *wdt = dev_get_drvdata(dev);
+ uint32_t status = readl(wdt->base + WDT_TIMEOUT_STATUS);
+
+ return sprintf(buf, "%u\n",
+ !(status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY));
+}
+
+static ssize_t access_cs0_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ struct aspeed_wdt *wdt = dev_get_drvdata(dev);
+ unsigned long val;
+
+ if (kstrtoul(buf, 10, &val))
+ return -EINVAL;
+
+ if (val)
+ writel(WDT_CLEAR_TIMEOUT_AND_BOOT_CODE_SELECTION,
+ wdt->base + WDT_CLEAR_TIMEOUT_STATUS);
+
+ return size;
+}
+
+/*
+ * At alternate side the 'access_cs0' sysfs node provides:
+ * ast2400: a way to get access to the primary SPI flash chip at CS0
+ * after booting from the alternate chip at CS1.
+ * ast2500: a way to restore the normal address mapping from
+ * (CS0->CS1, CS1->CS0) to (CS0->CS0, CS1->CS1).
+ *
+ * Clearing the boot code selection and timeout counter also resets to the
+ * initial state the chip select line mapping. When the SoC is in normal
+ * mapping state (i.e. booted from CS0), clearing those bits does nothing for
+ * both versions of the SoC. For alternate boot mode (booted from CS1 due to
+ * wdt2 expiration) the behavior differs as described above.
+ *
+ * This option can be used with wdt2 (watchdog1) only.
+ */
+static DEVICE_ATTR_RW(access_cs0);
+
+static struct attribute *bswitch_attrs[] = {
+ &dev_attr_access_cs0.attr,
+ NULL
+};
+ATTRIBUTE_GROUPS(bswitch);
+
static const struct watchdog_ops aspeed_wdt_ops = {
.start = aspeed_wdt_start,
.stop = aspeed_wdt_stop,
@@ -306,9 +359,16 @@ static int aspeed_wdt_probe(struct platform_device *pdev)
}
status = readl(wdt->base + WDT_TIMEOUT_STATUS);
- if (status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY)
+ if (status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY) {
wdt->wdd.bootstatus = WDIOF_CARDRESET;
+ if (of_device_is_compatible(np, "aspeed,ast2400-wdt") ||
+ of_device_is_compatible(np, "aspeed,ast2500-wdt"))
+ wdt->wdd.groups = bswitch_groups;
+ }
+
+ dev_set_drvdata(dev, wdt);
+
return devm_watchdog_register_device(dev, &wdt->wdd);
}
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/4] vesnin: add secondary SPI flash chip
From: Ivan Mikhaylov @ 2019-08-26 10:46 UTC (permalink / raw)
To: Guenter Roeck, Wim Van Sebroeck
Cc: Mark Rutland, devicetree, linux-watchdog, linux-aspeed,
Andrew Jeffery, openbmc, Alexander Amelkin, linux-kernel,
Rob Herring, Joel Stanley, Ivan Mikhaylov, linux-arm-kernel
In-Reply-To: <20190826104636.19324-1-i.mikhaylov@yadro.com>
Adds secondary SPI flash chip into dts for vesnin.
Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com>
---
arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts b/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts
index 2ee26c86a32e..db4cc3df61ce 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts
@@ -81,6 +81,14 @@
label = "bmc";
#include "openbmc-flash-layout.dtsi"
};
+
+ flash@1 {
+ status = "okay";
+ reg = < 1 >;
+ compatible = "jedec,spi-nor";
+ m25p,fast-read;
+ label = "alt";
+ };
};
&spi {
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 0/4] add dual-boot support
From: Ivan Mikhaylov @ 2019-08-26 10:46 UTC (permalink / raw)
To: Guenter Roeck, Wim Van Sebroeck
Cc: Mark Rutland, devicetree, linux-watchdog, linux-aspeed,
Andrew Jeffery, openbmc, Alexander Amelkin, linux-kernel,
Rob Herring, Joel Stanley, Ivan Mikhaylov, linux-arm-kernel
ASPEED SoCs support dual-boot feature for SPI Flash.
When strapped appropriately, the SoC starts wdt2 (/dev/watchdog1)
and if within a minute it is not disabled, it goes off and reboots
the SoC from an alternate SPI Flash chip by changing CS0 controls
to actually drive CS1 line.
When booted from alternate chip, in order to access the main chip
at CS0, the user must reset the appropriate bit in the watchdog
hardware. There is no interface that would allow to do that from
an embedded firmware startup script.
This commit implements support for that feature:
* Enable 'alt-boot' option for wdt2
* Enable secondary SPI flash chip
* Make it possible to get access to the primary SPI flash chip at CS0
after booting from the alternate chip at CS1. A sysfs interface is added
to provide an easy way for embedded firmware startup scripts to clear
the chip select bit to gain access to the primary flash chip in order
to allow for recovery of its contents.
Ivan Mikhaylov (4):
vesnin: add wdt2 section with alt-boot option
vesnin: add secondary SPI flash chip
watchdog/aspeed: add support for dual boot
dt-bindings/watchdog: Add access_cs0 option for alt-boot
.../bindings/watchdog/aspeed-wdt.txt | 7 +++
arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts | 12 ++++
drivers/watchdog/aspeed_wdt.c | 62 ++++++++++++++++++-
3 files changed, 80 insertions(+), 1 deletion(-)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/4] vesnin: add wdt2 section with alt-boot option
From: Ivan Mikhaylov @ 2019-08-26 10:46 UTC (permalink / raw)
To: Guenter Roeck, Wim Van Sebroeck
Cc: Mark Rutland, devicetree, linux-watchdog, linux-aspeed,
Andrew Jeffery, openbmc, Alexander Amelkin, linux-kernel,
Rob Herring, Joel Stanley, Ivan Mikhaylov, linux-arm-kernel
In-Reply-To: <20190826104636.19324-1-i.mikhaylov@yadro.com>
Adds wdt2 section with 'alt-boot' option into dts for vesnin.
Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com>
---
arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts b/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts
index 0b9e29c3212e..2ee26c86a32e 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts
@@ -222,3 +222,7 @@
&vuart {
status = "okay";
};
+
+&wdt2 {
+ aspeed,alt-boot;
+};
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 0/5] 0/6] arm64: meson-sm1: add support for DVFS
From: Jerome Brunet @ 2019-08-26 10:38 UTC (permalink / raw)
To: Neil Armstrong, khilman
Cc: linux-amlogic, linux-kernel, linux-clk, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190826072539.27725-1-narmstrong@baylibre.com>
On Mon 26 Aug 2019 at 09:25, Neil Armstrong <narmstrong@baylibre.com> wrote:
> Following DVFS support for the Amlogic G12A and G12B SoCs, this serie
> enables DVFS on the SM1 SoC for the SEI610 board.
>
> The SM1 Clock structure is slightly different because of the Cortex-A55
> core used, having the capability for each core of a same cluster to run
> at a different frequency thanks to the newly used DynamIQ Shared Unit.
>
> This is why SM1 has a CPU clock tree for each core and for DynamIQ Shared Unit,
> with a bypass mux to use the CPU0 instead of the dedicated trees.
>
> The DSU uses a new GP1 PLL as default clock, thus GP1 is added as read-only.
>
> The SM1 OPPs has been taken from the Amlogic Vendor tree, and unlike
> G12A only a single version of the SoC is available.
>
> Dependencies:
> - patch 6 is based on the "arm64: meson: add support for SM1 Power Domains" serie,
> but is not a strong dependency, it will work without
>
> Changes since v1:
> - exposed GP1, DSU and CPU 1,2,3 clock in patch 1
>
> Neil Armstrong (5):
> dt-bindings: clk: meson: add sm1 periph clock controller bindings
> clk: meson: g12a: add support for SM1 GP1 PLL
> clk: meson: g12a: add support for SM1 DynamIQ Shared Unit clock
> clk: meson: g12a: add support for SM1 CPU 1, 2 & 3 clocks
> arm64: dts: meson-sm1-sei610: enable DVFS
>
> .../bindings/clock/amlogic,gxbb-clkc.txt | 1 +
> .../boot/dts/amlogic/meson-sm1-sei610.dts | 59 +-
> arch/arm64/boot/dts/amlogic/meson-sm1.dtsi | 69 +++
> drivers/clk/meson/g12a.c | 544 ++++++++++++++++++
> drivers/clk/meson/g12a.h | 24 +-
> include/dt-bindings/clock/g12a-clkc.h | 5 +
> 6 files changed, 697 insertions(+), 5 deletions(-)
Applied 1 to 4
Nitpick: two checkpatch warnings regarding 75 char line wrap fixed in place.
>
> --
> 2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/2] ARM: dts: exynos: Add support ARM architected timers
From: Marek Szyprowski @ 2019-08-26 10:31 UTC (permalink / raw)
To: linux-samsung-soc, linux-arm-kernel
Cc: Chanwoo Choi, Bartlomiej Zolnierkiewicz, Krzysztof Kozlowski,
Marek Szyprowski
In-Reply-To: <20190826103142.3477-1-m.szyprowski@samsung.com>
All CortexA7/A15 based Exynos SoCs have ARM architected timers, so enable
support for them directly in the base dtsi for Exynos3250, Exynos5250
and Exynos54xx SoCs. None of the known firmware properly configures arch
timer registers, so mark them as not-fw-configured and set frequency
to 24MHz, which is the only configuration supported by the remaining
drivers (clocks) so far.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
arch/arm/boot/dts/exynos3250.dtsi | 10 ++++++++++
arch/arm/boot/dts/exynos5250.dtsi | 1 +
arch/arm/boot/dts/exynos54xx.dtsi | 10 ++++++++++
3 files changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
index 5659c4a10729..01e06b49d702 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -132,6 +132,16 @@
<GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
};
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+ clock-frequency = <24000000>;
+ arm,cpu-registers-not-fw-configured;
+ };
+
soc: soc {
compatible = "simple-bus";
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index 4157a1315db9..f78897413cbc 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -1089,6 +1089,7 @@
* so we need the value from DT.
*/
clock-frequency = <24000000>;
+ arm,cpu-registers-not-fw-configured;
};
};
diff --git a/arch/arm/boot/dts/exynos54xx.dtsi b/arch/arm/boot/dts/exynos54xx.dtsi
index 9c3b63b7cac6..4e6c29530632 100644
--- a/arch/arm/boot/dts/exynos54xx.dtsi
+++ b/arch/arm/boot/dts/exynos54xx.dtsi
@@ -45,6 +45,16 @@
status = "disabled";
};
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+ clock-frequency = <24000000>;
+ arm,cpu-registers-not-fw-configured;
+ };
+
soc: soc {
sysram@2020000 {
compatible = "mmio-sram";
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/2] ARM: exynos: Enable support for ARM architected timers
From: Marek Szyprowski @ 2019-08-26 10:31 UTC (permalink / raw)
To: linux-samsung-soc, linux-arm-kernel
Cc: Chanwoo Choi, Bartlomiej Zolnierkiewicz, Krzysztof Kozlowski,
Marek Szyprowski
In-Reply-To: <20190826103142.3477-1-m.szyprowski@samsung.com>
ARM architected timer can be used together with Exynos MultiCore Timer
driver, so enable support for it. Support for ARM architected timers is
essential for enabling proper KVM support.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
arch/arm/mach-exynos/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index d7422233a130..833ab92516fa 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -18,6 +18,7 @@ menuconfig ARCH_EXYNOS
select EXYNOS_SROM
select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
select GPIOLIB
+ select HAVE_ARM_ARCH_TIMER if VIRTUALIZATION
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/5] Exynos SoCs: enable support for ARM Architected Timers
From: Marek Szyprowski @ 2019-08-26 10:31 UTC (permalink / raw)
To: linux-samsung-soc, linux-arm-kernel
Cc: Chanwoo Choi, Bartlomiej Zolnierkiewicz, Krzysztof Kozlowski,
Marek Szyprowski
In-Reply-To: <CGME20190826103201eucas1p1358f33d8fbdc8cef8ba2ebdcb1b3a51a@eucas1p1.samsung.com>
Dear All,
ARM Architected Timers are present in all CortexA7/A15 based Samsung
Exynos SoCs. So far they were not enabled, because there were some issues
related to their initialization. Samsung Exynos SoCs used custom timer
hardware - Exynos MultiCore Timer. It turned out that enabling MCT it is
also needed to get ARM Architected Timers working, because they both
share some common hardware blocks (global system counter).
This patchset enables support for ARM Architected Timer driver together
with a standard Exynos MultiCore Timer driver, which is kept as a default
timer source on ARM 32bit platforms. Support for ARM architected timers
is essential for enabling proper KVM support on those platforms.
Some of the MCT cleanup patches were earlier a part of the similar
patchset for ARM64-based Exynos5433 SoC.
Best regards
Marek Szyprowski
Samsung R&D Institute Poland
Marek Szyprowski (5):
clocksource: exynos_mct: Remove dead code
clocksource: exynos_mct: Fix error path in timer resources
initialization
clocksource: exynos_mct: Increase priority over ARM arch timer
ARM: dts: exynos: Add support ARM architected timers
ARM: exynos: Enable support for ARM architected timers
arch/arm/boot/dts/exynos3250.dtsi | 10 ++++++++++
arch/arm/boot/dts/exynos5250.dtsi | 1 +
arch/arm/boot/dts/exynos54xx.dtsi | 10 ++++++++++
arch/arm/mach-exynos/Kconfig | 1 +
drivers/clocksource/exynos_mct.c | 27 +++++++++++++++++----------
include/linux/cpuhotplug.h | 2 +-
6 files changed, 40 insertions(+), 11 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 0/2] Exynos SoCs: enable support for ARM Architected Timers
From: Marek Szyprowski @ 2019-08-26 10:31 UTC (permalink / raw)
To: linux-samsung-soc, linux-arm-kernel
Cc: Chanwoo Choi, Bartlomiej Zolnierkiewicz, Krzysztof Kozlowski,
Marek Szyprowski
In-Reply-To: <20190826103142.3477-1-m.szyprowski@samsung.com>
Dear All,
ARM Architected Timers are present in all CortexA7/A15 based Samsung
Exynos SoCs. So far they were not enabled, because there were some issues
related to their initialization. Samsung Exynos SoCs used custom timer
hardware - Exynos MultiCore Timer. It turned out that enabling MCT it is
also needed to get ARM Architected Timers working, because they both
share some common hardware blocks (global system counter).
This patchset enables support for ARM Architected Timer driver together
with a standard Exynos MultiCore Timer driver, which is kept as a default
timer source on ARM 32bit platforms. Support for ARM architected timers
is essential for enabling proper KVM support on those platforms.
Best regards
Marek Szyprowski
Samsung R&D Institute Poland
Changelog:
v2:
- dropped MCT patches (merged to v5.1)
- dropped timer priority change patch (merged to v5.3)
v1: https://patchwork.kernel.org/cover/10814913/
- initial version, covers some MCT patches previously sent as a timer
rework for Exynos5433
Patch summary:
Marek Szyprowski (2):
ARM: dts: exynos: Add support ARM architected timers
ARM: exynos: Enable support for ARM architected timers
arch/arm/boot/dts/exynos3250.dtsi | 10 ++++++++++
arch/arm/boot/dts/exynos5250.dtsi | 1 +
arch/arm/boot/dts/exynos54xx.dtsi | 10 ++++++++++
arch/arm/mach-exynos/Kconfig | 1 +
4 files changed, 22 insertions(+)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/6] dt-bindings: pinctrl: k3: Introduce pinmux definitions for J721E
From: Lokesh Vutla @ 2019-08-26 10:26 UTC (permalink / raw)
To: Rob Herring
Cc: Nishanth Menon, Device Tree Mailing List, Keerthy, linus.walleij,
Tero Kristo, linux-gpio, Linux ARM Mailing List
In-Reply-To: <20190821210232.GA22578@bogus>
Hi Rob,
On 22/08/19 2:32 AM, Rob Herring wrote:
> On Fri, Aug 09, 2019 at 01:59:46PM +0530, Lokesh Vutla wrote:
>> Add pinctrl macros for J721E SoC. These macro definitions are
>> similar to that of AM6, but adding new definitions to avoid
>> any naming confusions in the soc dts files.
>>
>> Acked-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
>> ---
>> include/dt-bindings/pinctrl/k3.h | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/include/dt-bindings/pinctrl/k3.h b/include/dt-bindings/pinctrl/k3.h
>> index 45e11b6170ca..499de6216581 100644
>> --- a/include/dt-bindings/pinctrl/k3.h
>> +++ b/include/dt-bindings/pinctrl/k3.h
>> @@ -32,4 +32,7 @@
>> #define AM65X_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
>> #define AM65X_WKUP_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
>>
>> +#define J721E_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
>> +#define J721E_WKUP_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode))
>
> checkpatch reports a parentheses error: (((pa) & 0x1fff) ((val) | (muxmode)))
This was left intentionally as this macro is giving out two entries in DT like
below:
pinctrl-single,pins = <
J721E_IOPAD(0x0, PIN_INPUT, 7)
>;
comes out as
pinctrl-single,pins = <
0x0 (PIN_INPUT | 7)
>;
If parenthesis are added for the whole macro, the following build error occurs:
DTC arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dtb
Error: arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts:41.24-25 syntax error
FATAL ERROR: Unable to parse input tree
Thanks and regards,
Lokesh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] ftrace: introdue ftrace_call_init
From: Jisheng Zhang @ 2019-08-26 10:14 UTC (permalink / raw)
To: Miroslav Benes, Steven Rostedt, Mark Rutland, Torsten Duwe
Cc: Catalin Marinas, Will Deacon, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <alpine.LSU.2.21.1908201118190.9536@pobox.suse.cz>
Hi all,
On Tue, 20 Aug 2019 11:27:38 +0200 (CEST) Miroslav Benes wrote:
>
> Hi,
>
> On Mon, 19 Aug 2019, Jisheng Zhang wrote:
>
> > On some arch, the FTRACE_WITH_REGS is implemented with gcc's
> > -fpatchable-function-entry (=2), gcc adds 2 NOPs at the beginning
> > of each function, so this makes the MCOUNT_ADDR useless. In ftrace
> > common framework, MCOUNT_ADDR is mostly used to "init" the nop, so
> > let's introcude ftrace_call_init().
> >
> > Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> > ---
> > include/linux/ftrace.h | 1 +
> > kernel/trace/ftrace.c | 4 ++++
> > 2 files changed, 5 insertions(+)
> >
> > diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> > index 8a8cb3c401b2..8175ffb671f0 100644
> > --- a/include/linux/ftrace.h
> > +++ b/include/linux/ftrace.h
> > @@ -458,6 +458,7 @@ extern void ftrace_regs_caller(void);
> > extern void ftrace_call(void);
> > extern void ftrace_regs_call(void);
> > extern void mcount_call(void);
> > +extern int ftrace_call_init(struct module *mod, struct dyn_ftrace *rec);
> >
> > void ftrace_modify_all_code(int command);
> >
> > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> > index eca34503f178..9df5a66a6811 100644
> > --- a/kernel/trace/ftrace.c
> > +++ b/kernel/trace/ftrace.c
> > @@ -2500,7 +2500,11 @@ ftrace_code_disable(struct module *mod, struct dyn_ftrace *rec)
> > if (unlikely(ftrace_disabled))
> > return 0;
> >
> > +#ifdef MCOUNT_ADDR
> > ret = ftrace_make_nop(mod, rec, MCOUNT_ADDR);
> > +#else
> > + ret = ftrace_call_init(mod, rec);
> > +#endif
> > if (ret) {
> > ftrace_bug_type = FTRACE_BUG_INIT;
> > ftrace_bug(ret, rec);
>
> I may be missing something, but the patch does not seem to be complete.
> There is no ftrace_call_init() implemented. MCOUNT_ADDR is still defined,
> so it does not change much. I don't think it is what Mark had in his mind.
>
Here is patch to remove MCOUNT_ADDR from all arch, but I think it isn't
as good as current MCOUNT_ADDR. So how to remove the MCOUNT_ADDR depedency?
Could we
patch ftrace_make_nop to accept one more parameter? I.E
int ftrace_make_nop(struct module *mod, struct dyn_ftrace *rec,
unsigned long addr, bool init)
or
make "0" a special meaning to tell ftrace_make_nop to "init"?
Thanks
<---8
ftrace: introdue ftrace_call_init
On some arch, the FTRACE_WITH_REGS is implemented with gcc's
-fpatchable-function-entry (=2), gcc adds 2 NOPs at the beginning
of each function, so this makes the MCOUNT_ADDR useless. In ftrace
common framework, MCOUNT_ADDR is mostly used to "init" the nop, so
let's introcude ftrace_call_init() and remove MCOUNT_ADDR.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
---
arch/arm/include/asm/ftrace.h | 1 -
arch/arm/kernel/ftrace.c | 5 +++++
arch/arm64/include/asm/ftrace.h | 1 -
arch/arm64/kernel/ftrace.c | 5 +++++
arch/csky/kernel/ftrace.c | 5 +++++
arch/ia64/include/asm/ftrace.h | 2 --
arch/ia64/kernel/ftrace.c | 5 +++++
arch/microblaze/include/asm/ftrace.h | 1 -
arch/microblaze/kernel/ftrace.c | 5 +++++
arch/mips/include/asm/ftrace.h | 1 -
arch/mips/kernel/ftrace.c | 9 +++++++--
arch/nds32/include/asm/ftrace.h | 1 -
arch/nds32/kernel/ftrace.c | 5 +++++
arch/parisc/include/asm/ftrace.h | 1 -
arch/parisc/kernel/ftrace.c | 5 +++++
arch/powerpc/include/asm/ftrace.h | 1 -
arch/powerpc/kernel/trace/ftrace.c | 5 +++++
arch/riscv/include/asm/ftrace.h | 1 -
arch/riscv/kernel/ftrace.c | 5 +++++
arch/s390/include/asm/ftrace.h | 1 -
arch/s390/kernel/ftrace.c | 22 +++++++++++++++++-----
arch/sh/include/asm/ftrace.h | 2 --
arch/sh/kernel/ftrace.c | 5 +++++
arch/sparc/include/asm/ftrace.h | 1 -
arch/sparc/kernel/ftrace.c | 5 +++++
arch/x86/include/asm/ftrace.h | 1 -
arch/x86/kernel/ftrace.c | 28 +++++++++++++++-------------
arch/xtensa/include/asm/ftrace.h | 1 -
include/linux/ftrace.h | 1 +
kernel/trace/ftrace.c | 2 +-
30 files changed, 96 insertions(+), 37 deletions(-)
diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h
index 18b0197f2384..afb01ab7f956 100644
--- a/arch/arm/include/asm/ftrace.h
+++ b/arch/arm/include/asm/ftrace.h
@@ -7,7 +7,6 @@
#endif
#ifdef CONFIG_FUNCTION_TRACER
-#define MCOUNT_ADDR ((unsigned long)(__gnu_mcount_nc))
#define MCOUNT_INSN_SIZE 4 /* sizeof mcount call */
#ifndef __ASSEMBLY__
diff --git a/arch/arm/kernel/ftrace.c b/arch/arm/kernel/ftrace.c
index bda949fd84e8..fd3547bb4bfa 100644
--- a/arch/arm/kernel/ftrace.c
+++ b/arch/arm/kernel/ftrace.c
@@ -172,6 +172,11 @@ int ftrace_make_nop(struct module *mod,
return ret;
}
+int ftrace_call_init(struct module *mod, struct dyn_ftrace *rec)
+{
+ return ftrace_make_nop(mod, rec, (unsigned long)__gnu_mcount_nc);
+}
+
int __init ftrace_dyn_arch_init(void)
{
return 0;
diff --git a/arch/arm64/include/asm/ftrace.h b/arch/arm64/include/asm/ftrace.h
index 5ab5200b2bdc..de6f35ef3825 100644
--- a/arch/arm64/include/asm/ftrace.h
+++ b/arch/arm64/include/asm/ftrace.h
@@ -11,7 +11,6 @@
#include <asm/insn.h>
#define HAVE_FUNCTION_GRAPH_FP_TEST
-#define MCOUNT_ADDR ((unsigned long)_mcount)
#define MCOUNT_INSN_SIZE AARCH64_INSN_SIZE
#ifndef __ASSEMBLY__
diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
index 171773257974..8298b8a7d8f6 100644
--- a/arch/arm64/kernel/ftrace.c
+++ b/arch/arm64/kernel/ftrace.c
@@ -196,6 +196,11 @@ int ftrace_make_nop(struct module *mod, struct dyn_ftrace *rec,
return ftrace_modify_code(pc, old, new, validate);
}
+int ftrace_call_init(struct module *mod, struct dyn_ftrace *rec)
+{
+ return ftrace_make_nop(mod, rec, (unsigned long)_mcount);
+}
+
void arch_ftrace_update_code(int command)
{
command |= FTRACE_MAY_SLEEP;
diff --git a/arch/csky/kernel/ftrace.c b/arch/csky/kernel/ftrace.c
index 44f4880179b7..c1fce15caaa4 100644
--- a/arch/csky/kernel/ftrace.c
+++ b/arch/csky/kernel/ftrace.c
@@ -122,6 +122,11 @@ int ftrace_make_nop(struct module *mod, struct dyn_ftrace *rec,
return ftrace_modify_code(rec->ip, addr, false, false);
}
+int ftrace_call_init(struct module *mod, struct dyn_ftrace *rec)
+{
+ return ftrace_make_nop(mod, rec, (unsigned long)_mcount);
+}
+
int ftrace_update_ftrace_func(ftrace_func_t func)
{
int ret = ftrace_modify_code((unsigned long)&ftrace_call,
diff --git a/arch/ia64/include/asm/ftrace.h b/arch/ia64/include/asm/ftrace.h
index a07a8e575453..2aefd2098fc5 100644
--- a/arch/ia64/include/asm/ftrace.h
+++ b/arch/ia64/include/asm/ftrace.h
@@ -9,8 +9,6 @@
extern void _mcount(unsigned long pfs, unsigned long r1, unsigned long b0, unsigned long r0);
#define mcount _mcount
-/* In IA64, MCOUNT_ADDR is set in link time, so it's not a constant at compile time */
-#define MCOUNT_ADDR (((struct fnptr *)mcount)->ip)
#define FTRACE_ADDR (((struct fnptr *)ftrace_caller)->ip)
static inline unsigned long ftrace_call_adjust(unsigned long addr)
diff --git a/arch/ia64/kernel/ftrace.c b/arch/ia64/kernel/ftrace.c
index cee411e647ca..0cb2cbcea4fc 100644
--- a/arch/ia64/kernel/ftrace.c
+++ b/arch/ia64/kernel/ftrace.c
@@ -169,6 +169,11 @@ int ftrace_make_nop(struct module *mod,
return ftrace_modify_code(rec->ip, NULL, new, 0);
}
+int ftrace_call_init(struct module *mod, struct dyn_ftrace *rec)
+{
+ return ftrace_make_nop(mod, rec, ((struct fnptr *)mcount)->ip);
+}
+
int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
{
unsigned long ip = rec->ip;
diff --git a/arch/microblaze/include/asm/ftrace.h b/arch/microblaze/include/asm/ftrace.h
index 5db7f4489f05..02d185ef22fe 100644
--- a/arch/microblaze/include/asm/ftrace.h
+++ b/arch/microblaze/include/asm/ftrace.h
@@ -4,7 +4,6 @@
#ifdef CONFIG_FUNCTION_TRACER
-#define MCOUNT_ADDR ((unsigned long)(_mcount))
#define MCOUNT_INSN_SIZE 8 /* sizeof mcount call */
#ifndef __ASSEMBLY__
diff --git a/arch/microblaze/kernel/ftrace.c b/arch/microblaze/kernel/ftrace.c
index 224eea40e1ee..f3606e3cba94 100644
--- a/arch/microblaze/kernel/ftrace.c
+++ b/arch/microblaze/kernel/ftrace.c
@@ -149,6 +149,11 @@ int ftrace_make_nop(struct module *mod,
return ret;
}
+int ftrace_call_init(struct module *mod, struct dyn_ftrace *rec)
+{
+ return ftrace_make_nop(mod, rec, (unsigned long)_mcount);
+}
+
/* I believe that first is called ftrace_make_nop before this function */
int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
{
diff --git a/arch/mips/include/asm/ftrace.h b/arch/mips/include/asm/ftrace.h
index b463f2aa5a61..45b3f7064fcd 100644
--- a/arch/mips/include/asm/ftrace.h
+++ b/arch/mips/include/asm/ftrace.h
@@ -12,7 +12,6 @@
#ifdef CONFIG_FUNCTION_TRACER
-#define MCOUNT_ADDR ((unsigned long)(_mcount))
#define MCOUNT_INSN_SIZE 4 /* sizeof mcount call */
#ifndef __ASSEMBLY__
diff --git a/arch/mips/kernel/ftrace.c b/arch/mips/kernel/ftrace.c
index 2625232bfe52..85de81985e6f 100644
--- a/arch/mips/kernel/ftrace.c
+++ b/arch/mips/kernel/ftrace.c
@@ -61,7 +61,7 @@ static inline void ftrace_dyn_arch_init_insns(void)
/* la v1, _mcount */
v1 = 3;
buf = (u32 *)&insn_la_mcount[0];
- UASM_i_LA(&buf, v1, MCOUNT_ADDR);
+ UASM_i_LA(&buf, v1, (unsigned long)_mcount);
/* jal (ftrace_caller + 8), jump over the first two instruction */
buf = (u32 *)&insn_jal_ftrace_caller;
@@ -200,6 +200,11 @@ int ftrace_make_nop(struct module *mod,
#endif
}
+int ftrace_call_init(struct module *mod, struct dyn_ftrace *rec)
+{
+ return ftrace_make_nop(mod, rec, (unsigned long)_mcount);
+}
+
int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
{
unsigned int new;
@@ -232,7 +237,7 @@ int __init ftrace_dyn_arch_init(void)
ftrace_dyn_arch_init_insns();
/* Remove "b ftrace_stub" to ensure ftrace_caller() is executed */
- ftrace_modify_code(MCOUNT_ADDR, INSN_NOP);
+ ftrace_modify_code((unsigned long)_mcount, INSN_NOP);
return 0;
}
diff --git a/arch/nds32/include/asm/ftrace.h b/arch/nds32/include/asm/ftrace.h
index 2f96cc96aa35..97263241249d 100644
--- a/arch/nds32/include/asm/ftrace.h
+++ b/arch/nds32/include/asm/ftrace.h
@@ -7,7 +7,6 @@
#define HAVE_FUNCTION_GRAPH_FP_TEST
-#define MCOUNT_ADDR ((unsigned long)(_mcount))
/* mcount call is composed of three instructions:
* sethi + ori + jral
*/
diff --git a/arch/nds32/kernel/ftrace.c b/arch/nds32/kernel/ftrace.c
index fd2a54b8cd57..8f0c34f7bf5b 100644
--- a/arch/nds32/kernel/ftrace.c
+++ b/arch/nds32/kernel/ftrace.c
@@ -203,6 +203,11 @@ int ftrace_make_nop(struct module *mod, struct dyn_ftrace *rec,
return ftrace_modify_code(pc, call_insn, nop_insn, true);
}
+
+int ftrace_call_init(struct module *mod, struct dyn_ftrace *rec)
+{
+ return ftrace_make_nop(mod, rec, (unsigned long)_mcount);
+}
#endif /* CONFIG_DYNAMIC_FTRACE */
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
diff --git a/arch/parisc/include/asm/ftrace.h b/arch/parisc/include/asm/ftrace.h
index 958c0aa5dbb2..e0c7cc7958b8 100644
--- a/arch/parisc/include/asm/ftrace.h
+++ b/arch/parisc/include/asm/ftrace.h
@@ -5,7 +5,6 @@
#ifndef __ASSEMBLY__
extern void mcount(void);
-#define MCOUNT_ADDR ((unsigned long)mcount)
#define MCOUNT_INSN_SIZE 4
#define CC_USING_NOP_MCOUNT
extern unsigned long sys_call_table[];
diff --git a/arch/parisc/kernel/ftrace.c b/arch/parisc/kernel/ftrace.c
index b6fb30f2e4bf..4c9d8d1e5262 100644
--- a/arch/parisc/kernel/ftrace.c
+++ b/arch/parisc/kernel/ftrace.c
@@ -186,4 +186,9 @@ int ftrace_make_nop(struct module *mod, struct dyn_ftrace *rec,
insn, sizeof(insn)-4);
return 0;
}
+
+int ftrace_call_init(struct module *mod, struct dyn_ftrace *rec)
+{
+ return ftrace_make_nop(mod, rec, (unsigned long)mcount);
+}
#endif
diff --git a/arch/powerpc/include/asm/ftrace.h b/arch/powerpc/include/asm/ftrace.h
index 3dfb80b86561..bac76b982d2c 100644
--- a/arch/powerpc/include/asm/ftrace.h
+++ b/arch/powerpc/include/asm/ftrace.h
@@ -5,7 +5,6 @@
#include <asm/types.h>
#ifdef CONFIG_FUNCTION_TRACER
-#define MCOUNT_ADDR ((unsigned long)(_mcount))
#define MCOUNT_INSN_SIZE 4 /* sizeof mcount call */
#ifdef __ASSEMBLY__
diff --git a/arch/powerpc/kernel/trace/ftrace.c b/arch/powerpc/kernel/trace/ftrace.c
index be1ca98fce5c..728a357c51f0 100644
--- a/arch/powerpc/kernel/trace/ftrace.c
+++ b/arch/powerpc/kernel/trace/ftrace.c
@@ -472,6 +472,11 @@ int ftrace_make_nop(struct module *mod,
#endif /* CONFIG_MODULES */
}
+int ftrace_call_init(struct module *mod, struct dyn_ftrace *rec)
+{
+ return ftrace_make_nop(mod, rec, (unsigned long)_mcount);
+}
+
#ifdef CONFIG_MODULES
#ifdef CONFIG_PPC64
/*
diff --git a/arch/riscv/include/asm/ftrace.h b/arch/riscv/include/asm/ftrace.h
index c6dcc5291f97..5ca88b80de44 100644
--- a/arch/riscv/include/asm/ftrace.h
+++ b/arch/riscv/include/asm/ftrace.h
@@ -33,7 +33,6 @@ struct dyn_arch_ftrace {
* both auipc and jalr at the same time.
*/
-#define MCOUNT_ADDR ((unsigned long)_mcount)
#define JALR_SIGN_MASK (0x00000800)
#define JALR_OFFSET_MASK (0x00000fff)
#define AUIPC_OFFSET_MASK (0xfffff000)
diff --git a/arch/riscv/kernel/ftrace.c b/arch/riscv/kernel/ftrace.c
index b94d8db5ddcc..88fcdbf84ad8 100644
--- a/arch/riscv/kernel/ftrace.c
+++ b/arch/riscv/kernel/ftrace.c
@@ -88,6 +88,11 @@ int ftrace_make_nop(struct module *mod, struct dyn_ftrace *rec,
return __ftrace_modify_call(rec->ip, addr, false);
}
+int ftrace_call_init(struct module *mod, struct dyn_ftrace *rec)
+{
+ return ftrace_make_nop(mod, rec, (unsigned long)_mcount);
+}
+
int ftrace_update_ftrace_func(ftrace_func_t func)
{
int ret = __ftrace_modify_call((unsigned long)&ftrace_call,
diff --git a/arch/s390/include/asm/ftrace.h b/arch/s390/include/asm/ftrace.h
index 68d362f8d6c1..e70717c37f68 100644
--- a/arch/s390/include/asm/ftrace.h
+++ b/arch/s390/include/asm/ftrace.h
@@ -30,7 +30,6 @@ extern unsigned long ftrace_plt;
struct dyn_arch_ftrace { };
-#define MCOUNT_ADDR ((unsigned long)_mcount)
#define FTRACE_ADDR ((unsigned long)ftrace_caller)
#define KPROBE_ON_FTRACE_NOP 0
diff --git a/arch/s390/kernel/ftrace.c b/arch/s390/kernel/ftrace.c
index 1bb85f60c0dd..b74e35cc2262 100644
--- a/arch/s390/kernel/ftrace.c
+++ b/arch/s390/kernel/ftrace.c
@@ -110,11 +110,7 @@ int ftrace_make_nop(struct module *mod, struct dyn_ftrace *rec,
if (probe_kernel_read(&old, (void *) rec->ip, sizeof(old)))
return -EFAULT;
- if (addr == MCOUNT_ADDR) {
- /* Initial code replacement */
- ftrace_generate_orig_insn(&orig);
- ftrace_generate_nop_insn(&new);
- } else if (is_kprobe_on_ftrace(&old)) {
+ if (is_kprobe_on_ftrace(&old)) {
/*
* If we find a breakpoint instruction, a kprobe has been
* placed at the beginning of the function. We write the
@@ -136,6 +132,22 @@ int ftrace_make_nop(struct module *mod, struct dyn_ftrace *rec,
return 0;
}
+int ftrace_call_init(struct module *mod, struct dyn_ftrace *rec)
+{
+ struct ftrace_insn orig, new, old;
+
+ if (probe_kernel_read(&old, (void *) rec->ip, sizeof(old)))
+ return -EFAULT;
+ ftrace_generate_orig_insn(&orig);
+ ftrace_generate_nop_insn(&new);
+ /* Verify that the to be replaced code matches what we expect. */
+ if (memcmp(&orig, &old, sizeof(old)))
+ return -EINVAL;
+ s390_kernel_write((void *) rec->ip, &new, sizeof(new));
+
+ return 0;
+}
+
int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
{
struct ftrace_insn orig, new, old;
diff --git a/arch/sh/include/asm/ftrace.h b/arch/sh/include/asm/ftrace.h
index b1c1dc0cc261..5a7890b7a0d2 100644
--- a/arch/sh/include/asm/ftrace.h
+++ b/arch/sh/include/asm/ftrace.h
@@ -10,8 +10,6 @@
#ifndef __ASSEMBLY__
extern void mcount(void);
-#define MCOUNT_ADDR ((unsigned long)(mcount))
-
#ifdef CONFIG_DYNAMIC_FTRACE
#define CALL_ADDR ((long)(ftrace_call))
#define STUB_ADDR ((long)(ftrace_stub))
diff --git a/arch/sh/kernel/ftrace.c b/arch/sh/kernel/ftrace.c
index 1b04270e5460..f7a12102a93d 100644
--- a/arch/sh/kernel/ftrace.c
+++ b/arch/sh/kernel/ftrace.c
@@ -242,6 +242,11 @@ int ftrace_make_nop(struct module *mod,
return ftrace_modify_code(rec->ip, old, new);
}
+int ftrace_call_init(struct module *mod, struct dyn_ftrace *rec)
+{
+ return ftrace_make_nop(mod, rec, (unsigned long)mcount);
+}
+
int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
{
unsigned char *new, *old;
diff --git a/arch/sparc/include/asm/ftrace.h b/arch/sparc/include/asm/ftrace.h
index d3aa1a524431..a1eecda8976b 100644
--- a/arch/sparc/include/asm/ftrace.h
+++ b/arch/sparc/include/asm/ftrace.h
@@ -3,7 +3,6 @@
#define _ASM_SPARC64_FTRACE
#ifdef CONFIG_MCOUNT
-#define MCOUNT_ADDR ((unsigned long)(_mcount))
#define MCOUNT_INSN_SIZE 4 /* sizeof mcount call */
#ifndef __ASSEMBLY__
diff --git a/arch/sparc/kernel/ftrace.c b/arch/sparc/kernel/ftrace.c
index 684b84ce397f..7a16482fdd29 100644
--- a/arch/sparc/kernel/ftrace.c
+++ b/arch/sparc/kernel/ftrace.c
@@ -63,6 +63,11 @@ int ftrace_make_nop(struct module *mod, struct dyn_ftrace *rec, unsigned long ad
return ftrace_modify_code(ip, old, new);
}
+int ftrace_call_init(struct module *mod, struct dyn_ftrace *rec)
+{
+ return ftrace_make_nop(mod, rec, (unsigned long)_mcount);
+}
+
int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
{
unsigned long ip = rec->ip;
diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
index 287f1f7b2e52..58fe65fc5a63 100644
--- a/arch/x86/include/asm/ftrace.h
+++ b/arch/x86/include/asm/ftrace.h
@@ -6,7 +6,6 @@
#ifndef CC_USING_FENTRY
# error Compiler does not support fentry?
#endif
-# define MCOUNT_ADDR ((unsigned long)(__fentry__))
#define MCOUNT_INSN_SIZE 5 /* sizeof mcount call */
#ifdef CONFIG_DYNAMIC_FTRACE
diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index 024c3053dbba..3cdba006f848 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -149,26 +149,28 @@ ftrace_modify_code_direct(unsigned long ip, unsigned const char *old_code,
return 0;
}
-int ftrace_make_nop(struct module *mod,
- struct dyn_ftrace *rec, unsigned long addr)
+/*
+ * On boot up, and when modules are loaded, the __fentry__
+ * is converted to a nop, and will never become __fentry__
+ * again. This code is either running before SMP (on boot up)
+ * or before the code will ever be executed (module load).
+ * We do not want to use the breakpoint version in this case,
+ * just modify the code directly.
+ */
+int ftrace_call_init(struct module *mod, struct dyn_ftrace *rec)
{
unsigned const char *new, *old;
unsigned long ip = rec->ip;
- old = ftrace_call_replace(ip, addr);
+ old = ftrace_call_replace(ip, (unsigned long)__fentry__);
new = ftrace_nop_replace();
- /*
- * On boot up, and when modules are loaded, the MCOUNT_ADDR
- * is converted to a nop, and will never become MCOUNT_ADDR
- * again. This code is either running before SMP (on boot up)
- * or before the code will ever be executed (module load).
- * We do not want to use the breakpoint version in this case,
- * just modify the code directly.
- */
- if (addr == MCOUNT_ADDR)
- return ftrace_modify_code_direct(rec->ip, old, new);
+ return ftrace_modify_code_direct(ip, old, new);
+}
+int ftrace_make_nop(struct module *mod,
+ struct dyn_ftrace *rec, unsigned long addr)
+{
ftrace_expected = NULL;
/* Normal cases use add_brk_on_nop */
diff --git a/arch/xtensa/include/asm/ftrace.h b/arch/xtensa/include/asm/ftrace.h
index 6c6d9a9f185f..3ce2170291cd 100644
--- a/arch/xtensa/include/asm/ftrace.h
+++ b/arch/xtensa/include/asm/ftrace.h
@@ -28,7 +28,6 @@ extern unsigned long return_address(unsigned level);
#ifdef CONFIG_FUNCTION_TRACER
-#define MCOUNT_ADDR ((unsigned long)(_mcount))
#define MCOUNT_INSN_SIZE 3
#ifndef __ASSEMBLY__
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 8a8cb3c401b2..8175ffb671f0 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -458,6 +458,7 @@ extern void ftrace_regs_caller(void);
extern void ftrace_call(void);
extern void ftrace_regs_call(void);
extern void mcount_call(void);
+extern int ftrace_call_init(struct module *mod, struct dyn_ftrace *rec);
void ftrace_modify_all_code(int command);
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index eca34503f178..62ca6977e570 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -2500,7 +2500,7 @@ ftrace_code_disable(struct module *mod, struct dyn_ftrace *rec)
if (unlikely(ftrace_disabled))
return 0;
- ret = ftrace_make_nop(mod, rec, MCOUNT_ADDR);
+ ret = ftrace_call_init(mod, rec);
if (ret) {
ftrace_bug_type = FTRACE_BUG_INIT;
ftrace_bug(ret, rec);
--
2.23.0.rc1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v5 0/3] soc: ti: k3: Allow for exclusive and shared device requests
From: Lokesh Vutla @ 2019-08-26 10:11 UTC (permalink / raw)
To: santosh.shilimkar, Nishanth Menon, Tero Kristo, Santosh Shilimkar,
Rob Herring
Cc: Device Tree Mailing List, Sekhar Nori, Linux ARM Mailing List
In-Reply-To: <226a7b55-8a4d-aa25-9392-004d5ea097e4@oracle.com>
On 21/08/19 1:36 PM, santosh.shilimkar@oracle.com wrote:
> On 8/20/19 2:48 PM, Lokesh Vutla wrote:
>>
>>
>> On 29/07/19 5:54 PM, Lokesh Vutla wrote:
>>> Sysfw provides an option for requesting exclusive access for a
>>> device using the flags MSG_FLAG_DEVICE_EXCLUSIVE. If this flag is
>>> not used, the device is meant to be shared across hosts. Once a device
>>> is requested from a host with this flag set, any request to this
>>> device from a different host will be nacked by sysfw.
>>>
>>> Current tisci firmware and pm drivers always requests for device with
>>> exclusive permissions set. But this is not be true for certain devices
>>> that are expcted to be shared across different host contexts.
>>> So add support for getting the shared or exclusive permissions from DT
>>> and request firmware accordingly.
>>
>> Gentle Ping on this series.
>>
> I can queue this up.
Thanks Santosh.
Regards,
Lokesh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] bus: imx-weim: remove __init from 2 functions
From: Ilie Halip @ 2019-08-26 9:58 UTC (permalink / raw)
To: clang-built-linux
Cc: Ilie Halip, Sascha Hauer, Shawn Guo, linux-kernel,
linux-arm-kernel
A previous commit removed __init from weim_probe(), but this attribute is
still present for other functions called from it. Thus, these warnings
are triggered:
WARNING: Section mismatch in reference from the function weim_probe() to the function .init.text:imx_weim_gpr_setup()
WARNING: Section mismatch in reference from the function weim_probe() to the function .init.text:weim_timing_setup()
Remove the __init attribute from these functions as well, since they
don't seem to be used anywhere else.
Signed-off-by: Ilie Halip <ilie.halip@gmail.com>
Reported-by: "kernelci.org bot" <bot@kernelci.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: clang-built-linux@googlegroups.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/bus/imx-weim.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
index 79af0c27f5a3..d82e8c00523d 100644
--- a/drivers/bus/imx-weim.c
+++ b/drivers/bus/imx-weim.c
@@ -76,7 +76,7 @@ static const struct of_device_id weim_id_table[] = {
};
MODULE_DEVICE_TABLE(of, weim_id_table);
-static int __init imx_weim_gpr_setup(struct platform_device *pdev)
+static int imx_weim_gpr_setup(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct property *prop;
@@ -126,7 +126,7 @@ static int __init imx_weim_gpr_setup(struct platform_device *pdev)
}
/* Parse and set the timing for this device. */
-static int __init weim_timing_setup(struct device *dev,
+static int weim_timing_setup(struct device *dev,
struct device_node *np, void __iomem *base,
const struct imx_weim_devtype *devtype,
struct cs_timing_state *ts)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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