* [PATCH 1/2] ASoC: dt-bindings: fsl_aud2htx: Add binding doc for aud2htx module
From: Shengjiu Wang @ 2020-10-26 10:40 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, broonie, perex, tiwai,
alsa-devel, lgirdwood, robh+dt, devicetree
Cc: linuxppc-dev, linux-kernel
AUD2HTX (Audio Subsystem TO HDMI TX Subsystem) is a new
IP module found on i.MX8MP.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
.../bindings/sound/fsl,aud2htx.yaml | 67 +++++++++++++++++++
1 file changed, 67 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/fsl,aud2htx.yaml
diff --git a/Documentation/devicetree/bindings/sound/fsl,aud2htx.yaml b/Documentation/devicetree/bindings/sound/fsl,aud2htx.yaml
new file mode 100644
index 000000000000..18548d0889a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,aud2htx.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/fsl,aud2htx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP Audio Subsystem to HDMI RTX Subsystem Controller
+
+maintainers:
+ - Shengjiu Wang <shengjiu.wang@nxp.com>
+
+properties:
+ $nodename:
+ pattern: "^aud2htx@.*"
+
+ compatible:
+ const: fsl,imx8mp-aud2htx
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Peripheral clock
+
+ clock-names:
+ items:
+ - const: bus
+
+ dmas:
+ items:
+ - description: DMA controller phandle and request line for TX
+
+ dma-names:
+ items:
+ - const: tx
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - dmas
+ - dma-names
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/imx8mp-clock.h>
+
+ aud2htx: aud2htx@30cb0000 {
+ compatible = "fsl,imx8mp-aud2htx";
+ reg = <0x30cb0000 0x10000>;
+ interrupts = <GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&audiomix_clk IMX8MP_CLK_AUDIOMIX_AUD2HTX_IPG>;
+ clock-names = "bus";
+ dmas = <&sdma2 26 2 0>;
+ dma-names = "tx";
+ power-domains = <&audiomix_pd>;
+ };
--
2.27.0
^ permalink raw reply related
* [PATCH 2/2] ASoC: fsl_aud2htx: Add aud2htx module driver
From: Shengjiu Wang @ 2020-10-26 10:40 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, broonie, perex, tiwai,
alsa-devel, lgirdwood, robh+dt, devicetree
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1603708855-2663-1-git-send-email-shengjiu.wang@nxp.com>
The AUD2HTX is a digital module that provides a bridge between
the Audio Subsystem and the HDMI RTX Subsystem. This module
includes intermediate storage to queue SDMA transactions prior
to being synchronized and passed to the HDMI RTX Subsystem over
the Audio Link.
The AUD2HTX contains a DMA request routed to the SDMA module.
This DMA request is controlled based on the watermark level in
the 32-entry sample buffer.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
sound/soc/fsl/Kconfig | 8 +
sound/soc/fsl/Makefile | 2 +
sound/soc/fsl/fsl_aud2htx.c | 322 ++++++++++++++++++++++++++++++++++++
sound/soc/fsl/fsl_aud2htx.h | 67 ++++++++
4 files changed, 399 insertions(+)
create mode 100644 sound/soc/fsl/fsl_aud2htx.c
create mode 100644 sound/soc/fsl/fsl_aud2htx.h
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 3f76ff71ea47..5234d9ab9884 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -95,6 +95,14 @@ config SND_SOC_FSL_EASRC
destination sample rate. It is a new design module compare with the
old ASRC.
+config SND_SOC_FSL_AUD2HTX
+ tristate "AUDIO TO HDMI TX module support"
+ select REGMAP_MMIO
+ select SND_SOC_IMX_PCM_DMA if SND_IMX_SOC != n
+ select SND_SOC_GENERIC_DMAENGINE_PCM
+ help
+ Say Y if you want to add AUDIO TO HDMI TX support for NXP.
+
config SND_SOC_FSL_UTILS
tristate
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index b835eebf8825..78bc088b39d5 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -25,6 +25,7 @@ snd-soc-fsl-utils-objs := fsl_utils.o
snd-soc-fsl-dma-objs := fsl_dma.o
snd-soc-fsl-mqs-objs := fsl_mqs.o
snd-soc-fsl-easrc-objs := fsl_easrc.o
+snd-soc-fsl-aud2htx-objs := fsl_aud2htx.o
obj-$(CONFIG_SND_SOC_FSL_AUDMIX) += snd-soc-fsl-audmix.o
obj-$(CONFIG_SND_SOC_FSL_ASOC_CARD) += snd-soc-fsl-asoc-card.o
@@ -38,6 +39,7 @@ obj-$(CONFIG_SND_SOC_FSL_UTILS) += snd-soc-fsl-utils.o
obj-$(CONFIG_SND_SOC_FSL_MQS) += snd-soc-fsl-mqs.o
obj-$(CONFIG_SND_SOC_FSL_EASRC) += snd-soc-fsl-easrc.o
obj-$(CONFIG_SND_SOC_POWERPC_DMA) += snd-soc-fsl-dma.o
+obj-$(CONFIG_SND_SOC_FSL_AUD2HTX) += snd-soc-fsl-aud2htx.o
# MPC5200 Platform Support
obj-$(CONFIG_SND_MPC52xx_DMA) += mpc5200_dma.o
diff --git a/sound/soc/fsl/fsl_aud2htx.c b/sound/soc/fsl/fsl_aud2htx.c
new file mode 100644
index 000000000000..8c4b897db6f0
--- /dev/null
+++ b/sound/soc/fsl/fsl_aud2htx.c
@@ -0,0 +1,322 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (C) 2020 NXP
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/delay.h>
+#include <linux/dmaengine.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/of_address.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/time.h>
+#include <linux/pm_qos.h>
+#include <sound/core.h>
+#include <sound/dmaengine_pcm.h>
+#include <sound/pcm_params.h>
+#include <linux/dma-mapping.h>
+
+#include "fsl_aud2htx.h"
+#include "imx-pcm.h"
+
+static int fsl_aud2htx_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params,
+ struct snd_soc_dai *cpu_dai)
+{
+ struct fsl_aud2htx *aud2htx = snd_soc_dai_get_drvdata(cpu_dai);
+
+ /* DMA request when number of entries < WTMK_LOW */
+ regmap_update_bits(aud2htx->regmap, AUD2HTX_CTRL_EXT,
+ AUD2HTX_CTRE_DT_MASK, 0);
+
+ /* Disable interrupts*/
+ regmap_update_bits(aud2htx->regmap, AUD2HTX_IRQ_MASK,
+ AUD2HTX_WM_HIGH_IRQ_MASK |
+ AUD2HTX_WM_LOW_IRQ_MASK |
+ AUD2HTX_OVF_MASK,
+ AUD2HTX_WM_HIGH_IRQ_MASK |
+ AUD2HTX_WM_LOW_IRQ_MASK |
+ AUD2HTX_OVF_MASK);
+
+ /* Configur watermark */
+ regmap_update_bits(aud2htx->regmap, AUD2HTX_CTRL_EXT,
+ AUD2HTX_CTRE_WL_MASK,
+ AUD2HTX_WTMK_LOW << AUD2HTX_CTRE_WL_SHIFT);
+ regmap_update_bits(aud2htx->regmap, AUD2HTX_CTRL_EXT,
+ AUD2HTX_CTRE_WH_MASK,
+ AUD2HTX_WTMK_HIGH << AUD2HTX_CTRE_WH_SHIFT);
+ return 0;
+}
+
+static int fsl_aud2htx_trigger(struct snd_pcm_substream *substream, int cmd,
+ struct snd_soc_dai *dai)
+{
+ struct fsl_aud2htx *aud2htx = snd_soc_dai_get_drvdata(dai);
+
+ switch (cmd) {
+ case SNDRV_PCM_TRIGGER_START:
+ case SNDRV_PCM_TRIGGER_RESUME:
+ case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+ regmap_update_bits(aud2htx->regmap, AUD2HTX_CTRL,
+ AUD2HTX_CTRL_EN, AUD2HTX_CTRL_EN);
+ regmap_update_bits(aud2htx->regmap, AUD2HTX_CTRL_EXT,
+ AUD2HTX_CTRE_DE, AUD2HTX_CTRE_DE);
+ break;
+ case SNDRV_PCM_TRIGGER_SUSPEND:
+ case SNDRV_PCM_TRIGGER_STOP:
+ case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+ regmap_update_bits(aud2htx->regmap, AUD2HTX_CTRL_EXT,
+ AUD2HTX_CTRE_DE, 0);
+ regmap_update_bits(aud2htx->regmap, AUD2HTX_CTRL,
+ AUD2HTX_CTRL_EN, 0);
+ break;
+ default:
+ return -EINVAL;
+ }
+ return 0;
+}
+
+static const struct snd_soc_dai_ops fsl_aud2htx_dai_ops = {
+ .hw_params = fsl_aud2htx_hw_params,
+ .trigger = fsl_aud2htx_trigger,
+};
+
+static int fsl_aud2htx_dai_probe(struct snd_soc_dai *cpu_dai)
+{
+ struct fsl_aud2htx *aud2htx = dev_get_drvdata(cpu_dai->dev);
+
+ snd_soc_dai_init_dma_data(cpu_dai, &aud2htx->dma_params_tx,
+ &aud2htx->dma_params_rx);
+
+ return 0;
+}
+
+static struct snd_soc_dai_driver fsl_aud2htx_dai = {
+ .probe = fsl_aud2htx_dai_probe,
+ .playback = {
+ .stream_name = "CPU-Playback",
+ .channels_min = 1,
+ .channels_max = 8,
+ .rates = SNDRV_PCM_RATE_32000 |
+ SNDRV_PCM_RATE_44100 |
+ SNDRV_PCM_RATE_48000 |
+ SNDRV_PCM_RATE_88200 |
+ SNDRV_PCM_RATE_96000 |
+ SNDRV_PCM_RATE_176400 |
+ SNDRV_PCM_RATE_192000,
+ .formats = FSL_AUD2HTX_FORMATS,
+ },
+ .ops = &fsl_aud2htx_dai_ops,
+};
+
+static const struct snd_soc_component_driver fsl_aud2htx_component = {
+ .name = "fsl-aud2htx",
+};
+
+static const struct reg_default fsl_aud2htx_reg_defaults[] = {
+ {AUD2HTX_CTRL, 0x00000000},
+ {AUD2HTX_CTRL_EXT, 0x00000000},
+ {AUD2HTX_WR, 0x00000000},
+ {AUD2HTX_STATUS, 0x00000000},
+ {AUD2HTX_IRQ_NOMASK, 0x00000000},
+ {AUD2HTX_IRQ_MASKED, 0x00000000},
+ {AUD2HTX_IRQ_MASK, 0x00000000},
+};
+
+static bool fsl_aud2htx_readable_reg(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case AUD2HTX_CTRL:
+ case AUD2HTX_CTRL_EXT:
+ case AUD2HTX_STATUS:
+ case AUD2HTX_IRQ_NOMASK:
+ case AUD2HTX_IRQ_MASKED:
+ case AUD2HTX_IRQ_MASK:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static bool fsl_aud2htx_writeable_reg(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case AUD2HTX_CTRL:
+ case AUD2HTX_CTRL_EXT:
+ case AUD2HTX_WR:
+ case AUD2HTX_IRQ_NOMASK:
+ case AUD2HTX_IRQ_MASKED:
+ case AUD2HTX_IRQ_MASK:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static bool fsl_aud2htx_volatile_reg(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case AUD2HTX_STATUS:
+ case AUD2HTX_IRQ_NOMASK:
+ case AUD2HTX_IRQ_MASKED:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static const struct regmap_config fsl_aud2htx_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+
+ .max_register = AUD2HTX_IRQ_MASK,
+ .reg_defaults = fsl_aud2htx_reg_defaults,
+ .num_reg_defaults = ARRAY_SIZE(fsl_aud2htx_reg_defaults),
+ .readable_reg = fsl_aud2htx_readable_reg,
+ .volatile_reg = fsl_aud2htx_volatile_reg,
+ .writeable_reg = fsl_aud2htx_writeable_reg,
+ .cache_type = REGCACHE_RBTREE,
+};
+
+static const struct of_device_id fsl_aud2htx_dt_ids[] = {
+ { .compatible = "fsl,imx8mp-aud2htx",},
+ {}
+};
+MODULE_DEVICE_TABLE(of, fsl_aud2htx_dt_ids);
+
+static irqreturn_t fsl_aud2htx_isr(int irq, void *dev_id)
+{
+ return IRQ_HANDLED;
+}
+
+static int fsl_aud2htx_probe(struct platform_device *pdev)
+{
+ struct fsl_aud2htx *aud2htx;
+ struct resource *res;
+ void __iomem *regs;
+ int ret, irq;
+
+ aud2htx = devm_kzalloc(&pdev->dev, sizeof(*aud2htx), GFP_KERNEL);
+ if (!aud2htx)
+ return -ENOMEM;
+
+ aud2htx->pdev = pdev;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(regs)) {
+ dev_err(&pdev->dev, "failed ioremap\n");
+ return PTR_ERR(regs);
+ }
+
+ aud2htx->regmap = devm_regmap_init_mmio(&pdev->dev, regs,
+ &fsl_aud2htx_regmap_config);
+ if (IS_ERR(aud2htx->regmap)) {
+ dev_err(&pdev->dev, "failed to init regmap");
+ return PTR_ERR(aud2htx->regmap);
+ }
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0) {
+ dev_err(&pdev->dev, "no irq for node %s\n",
+ dev_name(&pdev->dev));
+ return irq;
+ }
+
+ ret = devm_request_irq(&pdev->dev, irq, fsl_aud2htx_isr, 0,
+ dev_name(&pdev->dev), aud2htx);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to claim irq %u: %d\n", irq, ret);
+ return ret;
+ }
+
+ aud2htx->bus_clk = devm_clk_get(&pdev->dev, "bus");
+ if (IS_ERR(aud2htx->bus_clk)) {
+ dev_err(&pdev->dev, "failed to get mem clock\n");
+ return PTR_ERR(aud2htx->bus_clk);
+ }
+
+ aud2htx->dma_params_tx.chan_name = "tx";
+ aud2htx->dma_params_tx.maxburst = AUD2HTX_MAXBURST;
+ aud2htx->dma_params_tx.addr = res->start + AUD2HTX_WR;
+
+ platform_set_drvdata(pdev, aud2htx);
+ pm_runtime_enable(&pdev->dev);
+
+ regcache_cache_only(aud2htx->regmap, true);
+
+ ret = devm_snd_soc_register_component(&pdev->dev,
+ &fsl_aud2htx_component,
+ &fsl_aud2htx_dai, 1);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to register ASoC DAI\n");
+ return ret;
+ }
+
+ ret = imx_pcm_dma_init(pdev, IMX_DEFAULT_DMABUF_SIZE);
+ if (ret)
+ dev_err(&pdev->dev, "failed to init imx pcm dma: %d\n", ret);
+
+ return ret;
+}
+
+static int fsl_aud2htx_remove(struct platform_device *pdev)
+{
+ pm_runtime_disable(&pdev->dev);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM
+static int fsl_aud2htx_runtime_suspend(struct device *dev)
+{
+ struct fsl_aud2htx *aud2htx = dev_get_drvdata(dev);
+
+ regcache_cache_only(aud2htx->regmap, true);
+ clk_disable_unprepare(aud2htx->bus_clk);
+
+ return 0;
+}
+
+static int fsl_aud2htx_runtime_resume(struct device *dev)
+{
+ struct fsl_aud2htx *aud2htx = dev_get_drvdata(dev);
+ int ret;
+
+ ret = clk_prepare_enable(aud2htx->bus_clk);
+ if (ret)
+ return ret;
+
+ regcache_cache_only(aud2htx->regmap, false);
+ regcache_mark_dirty(aud2htx->regmap);
+ regcache_sync(aud2htx->regmap);
+
+ return 0;
+}
+#endif /*CONFIG_PM*/
+
+static const struct dev_pm_ops fsl_aud2htx_pm_ops = {
+ SET_RUNTIME_PM_OPS(fsl_aud2htx_runtime_suspend,
+ fsl_aud2htx_runtime_resume,
+ NULL)
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
+};
+
+static struct platform_driver fsl_aud2htx_driver = {
+ .probe = fsl_aud2htx_probe,
+ .remove = fsl_aud2htx_remove,
+ .driver = {
+ .name = "fsl-aud2htx",
+ .pm = &fsl_aud2htx_pm_ops,
+ .of_match_table = fsl_aud2htx_dt_ids,
+ },
+};
+module_platform_driver(fsl_aud2htx_driver);
+
+MODULE_AUTHOR("Shengjiu Wang <Shengjiu.Wang@nxp.com>");
+MODULE_DESCRIPTION("NXP AUD2HTX driver");
+MODULE_LICENSE("GPL v2");
diff --git a/sound/soc/fsl/fsl_aud2htx.h b/sound/soc/fsl/fsl_aud2htx.h
new file mode 100644
index 000000000000..ffa98e6af5ec
--- /dev/null
+++ b/sound/soc/fsl/fsl_aud2htx.h
@@ -0,0 +1,67 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020 NXP
+ */
+
+#ifndef _FSL_AUD2HTX_H
+#define _FSL_AUD2HTX_H
+
+#define FSL_AUD2HTX_FORMATS (SNDRV_PCM_FMTBIT_S24_LE | \
+ SNDRV_PCM_FMTBIT_S32_LE)
+
+/* AUD2HTX Register Map */
+#define AUD2HTX_CTRL 0x0 /* AUD2HTX Control Register */
+#define AUD2HTX_CTRL_EXT 0x4 /* AUD2HTX Control Extended Register */
+#define AUD2HTX_WR 0x8 /* AUD2HTX Write Register */
+#define AUD2HTX_STATUS 0xC /* AUD2HTX Status Register */
+#define AUD2HTX_IRQ_NOMASK 0x10 /* AUD2HTX Nonmasked Interrupt Flags Register */
+#define AUD2HTX_IRQ_MASKED 0x14 /* AUD2HTX Masked Interrupt Flags Register */
+#define AUD2HTX_IRQ_MASK 0x18 /* AUD2HTX IRQ Masks Register */
+
+/* AUD2HTX Control Register */
+#define AUD2HTX_CTRL_EN BIT(0)
+
+/* AUD2HTX Control Extended Register */
+#define AUD2HTX_CTRE_DE BIT(0)
+#define AUD2HTX_CTRE_DT_SHIFT 0x1
+#define AUD2HTX_CTRE_DT_WIDTH 0x2
+#define AUD2HTX_CTRE_DT_MASK ((BIT(AUD2HTX_CTRE_DT_WIDTH) - 1) \
+ << AUD2HTX_CTRE_DT_SHIFT)
+#define AUD2HTX_CTRE_WL_SHIFT 16
+#define AUD2HTX_CTRE_WL_WIDTH 5
+#define AUD2HTX_CTRE_WL_MASK ((BIT(AUD2HTX_CTRE_WL_WIDTH) - 1) \
+ << AUD2HTX_CTRE_WL_SHIFT)
+#define AUD2HTX_CTRE_WH_SHIFT 24
+#define AUD2HTX_CTRE_WH_WIDTH 5
+#define AUD2HTX_CTRE_WH_MASK ((BIT(AUD2HTX_CTRE_WH_WIDTH) - 1) \
+ << AUD2HTX_CTRE_WH_SHIFT)
+
+/* AUD2HTX IRQ Masks Register */
+#define AUD2HTX_WM_HIGH_IRQ_MASK BIT(2)
+#define AUD2HTX_WM_LOW_IRQ_MASK BIT(1)
+#define AUD2HTX_OVF_MASK BIT(0)
+
+#define AUD2HTX_FIFO_DEPTH 0x20
+#define AUD2HTX_WTMK_LOW 0x10
+#define AUD2HTX_WTMK_HIGH 0x10
+#define AUD2HTX_MAXBURST 0x10
+
+/**
+ * fsl_aud2htx: AUD2HTX private data
+ *
+ * @pdev: platform device pointer
+ * @regmap: regmap handler
+ * @bus_clk: clock source to access register
+ * @dma_params_rx: DMA parameters for receive channel
+ * @dma_params_tx: DMA parameters for transmit channel
+ */
+struct fsl_aud2htx {
+ struct platform_device *pdev;
+ struct regmap *regmap;
+ struct clk *bus_clk;
+
+ struct snd_dmaengine_dai_dma_data dma_params_rx;
+ struct snd_dmaengine_dai_dma_data dma_params_tx;
+};
+
+#endif /* _FSL_AUD2HTX_H */
--
2.27.0
^ permalink raw reply related
* Re: [PATCH 1/4] mm: introduce debug_pagealloc_map_pages() helper
From: David Hildenbrand @ 2020-10-26 11:05 UTC (permalink / raw)
To: Mike Rapoport, Andrew Morton
Cc: Peter Zijlstra, Dave Hansen, linux-mm, Paul Mackerras,
Pavel Machek, H. Peter Anvin, sparclinux, Christoph Lameter,
Will Deacon, linux-riscv, linux-s390, x86, Mike Rapoport,
Christian Borntraeger, Ingo Molnar, Catalin Marinas, Len Brown,
Albert Ou, Vasily Gorbik, linux-pm, Heiko Carstens,
David Rientjes, Borislav Petkov, Andy Lutomirski, Paul Walmsley,
Kirill A. Shutemov, Thomas Gleixner, linux-arm-kernel,
Rafael J. Wysocki, linux-kernel, Pekka Enberg, Palmer Dabbelt,
Joonsoo Kim, Edgecombe, Rick P, linuxppc-dev, David S. Miller
In-Reply-To: <20201025101555.3057-2-rppt@kernel.org>
On 25.10.20 11:15, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
>
> When CONFIG_DEBUG_PAGEALLOC is enabled, it unmaps pages from the
> kernel direct mapping after free_pages(). The pages than need to be
> mapped back before they could be used. Theese mapping operations use
> __kernel_map_pages() guarded with with debug_pagealloc_enabled().
>
> The only place that calls __kernel_map_pages() without checking
> whether DEBUG_PAGEALLOC is enabled is the hibernation code that
> presumes availability of this function when ARCH_HAS_SET_DIRECT_MAP
> is set. Still, on arm64, __kernel_map_pages() will bail out when
> DEBUG_PAGEALLOC is not enabled but set_direct_map_invalid_noflush()
> may render some pages not present in the direct map and hibernation
> code won't be able to save such pages.
>
> To make page allocation debugging and hibernation interaction more
> robust, the dependency on DEBUG_PAGEALLOC or ARCH_HAS_SET_DIRECT_MAP
> has to be made more explicit.
>
> Start with combining the guard condition and the call to
> __kernel_map_pages() into a single debug_pagealloc_map_pages()
> function to emphasize that __kernel_map_pages() should not be called
> without DEBUG_PAGEALLOC and use this new function to map/unmap pages
> when page allocation debug is enabled.
>
> As the only remaining user of kernel_map_pages() is the hibernation
> code, mode that function into kernel/power/snapshot.c closer to a
> caller.
s/mode/move/
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> ---
> include/linux/mm.h | 16 +++++++--------- kernel/power/snapshot.c
> | 11 +++++++++++ mm/memory_hotplug.c | 3 +-- mm/page_alloc.c
> | 6 ++---- mm/slab.c | 8 +++----- 5 files changed, 24
> insertions(+), 20 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h index
> ef360fe70aaf..14e397f3752c 100644 --- a/include/linux/mm.h +++
> b/include/linux/mm.h @@ -2927,21 +2927,19 @@ static inline bool
> debug_pagealloc_enabled_static(void) #if
> defined(CONFIG_DEBUG_PAGEALLOC) ||
> defined(CONFIG_ARCH_HAS_SET_DIRECT_MAP) extern void
> __kernel_map_pages(struct page *page, int numpages, int enable);
>
> -/* - * When called in DEBUG_PAGEALLOC context, the call should most
> likely be - * guarded by debug_pagealloc_enabled() or
> debug_pagealloc_enabled_static() - */ -static inline void
> -kernel_map_pages(struct page *page, int numpages, int enable)
> +static inline void debug_pagealloc_map_pages(struct page *page, +
> int numpages, int enable) { - __kernel_map_pages(page, numpages,
> enable); + if (debug_pagealloc_enabled_static()) +
> __kernel_map_pages(page, numpages, enable); } + #ifdef
> CONFIG_HIBERNATION extern bool kernel_page_present(struct page
> *page); #endif /* CONFIG_HIBERNATION */ #else /*
> CONFIG_DEBUG_PAGEALLOC || CONFIG_ARCH_HAS_SET_DIRECT_MAP */ -static
> inline void -kernel_map_pages(struct page *page, int numpages, int
> enable) {} +static inline void debug_pagealloc_map_pages(struct page
> *page, + int numpages, int enable) {} #ifdef
> CONFIG_HIBERNATION static inline bool kernel_page_present(struct page
> *page) { return true; } #endif /* CONFIG_HIBERNATION */ diff --git
> a/kernel/power/snapshot.c b/kernel/power/snapshot.c index
> 46b1804c1ddf..fa499466f645 100644 --- a/kernel/power/snapshot.c +++
> b/kernel/power/snapshot.c @@ -76,6 +76,17 @@ static inline void
> hibernate_restore_protect_page(void *page_address) {} static inline
> void hibernate_restore_unprotect_page(void *page_address) {} #endif
> /* CONFIG_STRICT_KERNEL_RWX && CONFIG_ARCH_HAS_SET_MEMORY */
>
> +#if defined(CONFIG_DEBUG_PAGEALLOC) ||
> defined(CONFIG_ARCH_HAS_SET_DIRECT_MAP) +static inline void
> +kernel_map_pages(struct page *page, int numpages, int enable) +{ +
> __kernel_map_pages(page, numpages, enable); +} +#else +static inline
> void +kernel_map_pages(struct page *page, int numpages, int enable)
> {} +#endif +
That change should go into a separate patch.
For the debug_pagealloc_map_pages() parts
Reviewed-by: David Hildenbrand <david@redhat.com>
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH 1/4] mm: introduce debug_pagealloc_map_pages() helper
From: Mike Rapoport @ 2020-10-26 11:54 UTC (permalink / raw)
To: David Hildenbrand
Cc: Peter Zijlstra, Dave Hansen, linux-mm, Paul Mackerras,
Pavel Machek, H. Peter Anvin, sparclinux, Christoph Lameter,
Will Deacon, linux-riscv, linux-s390, x86, Mike Rapoport,
Christian Borntraeger, Ingo Molnar, Catalin Marinas, Len Brown,
Albert Ou, Vasily Gorbik, linux-pm, Heiko Carstens,
David Rientjes, Borislav Petkov, Andy Lutomirski, Paul Walmsley,
Kirill A. Shutemov, Thomas Gleixner, Joonsoo Kim,
linux-arm-kernel, Rafael J. Wysocki, linux-kernel, Pekka Enberg,
Palmer Dabbelt, Andrew Morton, Edgecombe, Rick P, linuxppc-dev,
David S. Miller
In-Reply-To: <8720c067-7dc5-2b02-918b-e54dd642bfd6@redhat.com>
On Mon, Oct 26, 2020 at 12:05:13PM +0100, David Hildenbrand wrote:
> On 25.10.20 11:15, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt@linux.ibm.com>
> >
> > When CONFIG_DEBUG_PAGEALLOC is enabled, it unmaps pages from the
> > kernel direct mapping after free_pages(). The pages than need to be
> > mapped back before they could be used. Theese mapping operations use
> > __kernel_map_pages() guarded with with debug_pagealloc_enabled().
> >
> > The only place that calls __kernel_map_pages() without checking
> > whether DEBUG_PAGEALLOC is enabled is the hibernation code that
> > presumes availability of this function when ARCH_HAS_SET_DIRECT_MAP
> > is set. Still, on arm64, __kernel_map_pages() will bail out when
> > DEBUG_PAGEALLOC is not enabled but set_direct_map_invalid_noflush()
> > may render some pages not present in the direct map and hibernation
> > code won't be able to save such pages.
> >
> > To make page allocation debugging and hibernation interaction more
> > robust, the dependency on DEBUG_PAGEALLOC or ARCH_HAS_SET_DIRECT_MAP
> > has to be made more explicit.
> >
> > Start with combining the guard condition and the call to
> > __kernel_map_pages() into a single debug_pagealloc_map_pages()
> > function to emphasize that __kernel_map_pages() should not be called
> > without DEBUG_PAGEALLOC and use this new function to map/unmap pages
> > when page allocation debug is enabled.
> >
> > As the only remaining user of kernel_map_pages() is the hibernation
> > code, mode that function into kernel/power/snapshot.c closer to a
> > caller.
>
> s/mode/move/
>
> >
> > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> ---
> > include/linux/mm.h | 16 +++++++--------- kernel/power/snapshot.c
> > | 11 +++++++++++ mm/memory_hotplug.c | 3 +-- mm/page_alloc.c
> > | 6 ++---- mm/slab.c | 8 +++----- 5 files changed, 24
> > insertions(+), 20 deletions(-)
> >
> > diff --git a/include/linux/mm.h b/include/linux/mm.h index
> > ef360fe70aaf..14e397f3752c 100644 --- a/include/linux/mm.h +++
> > b/include/linux/mm.h @@ -2927,21 +2927,19 @@ static inline bool
> > debug_pagealloc_enabled_static(void) #if
> > defined(CONFIG_DEBUG_PAGEALLOC) ||
> > defined(CONFIG_ARCH_HAS_SET_DIRECT_MAP) extern void
> > __kernel_map_pages(struct page *page, int numpages, int enable);
> >
> > -/* - * When called in DEBUG_PAGEALLOC context, the call should most
> > likely be - * guarded by debug_pagealloc_enabled() or
> > debug_pagealloc_enabled_static() - */ -static inline void
> > -kernel_map_pages(struct page *page, int numpages, int enable)
> > +static inline void debug_pagealloc_map_pages(struct page *page, +
> > int numpages, int enable) { - __kernel_map_pages(page, numpages,
> > enable); + if (debug_pagealloc_enabled_static()) +
> > __kernel_map_pages(page, numpages, enable); } + #ifdef
> > CONFIG_HIBERNATION extern bool kernel_page_present(struct page
> > *page); #endif /* CONFIG_HIBERNATION */ #else /*
> > CONFIG_DEBUG_PAGEALLOC || CONFIG_ARCH_HAS_SET_DIRECT_MAP */ -static
> > inline void -kernel_map_pages(struct page *page, int numpages, int
> > enable) {} +static inline void debug_pagealloc_map_pages(struct page
> > *page, + int numpages, int enable) {} #ifdef
> > CONFIG_HIBERNATION static inline bool kernel_page_present(struct page
> > *page) { return true; } #endif /* CONFIG_HIBERNATION */ diff --git
> > a/kernel/power/snapshot.c b/kernel/power/snapshot.c index
> > 46b1804c1ddf..fa499466f645 100644 --- a/kernel/power/snapshot.c +++
> > b/kernel/power/snapshot.c @@ -76,6 +76,17 @@ static inline void
> > hibernate_restore_protect_page(void *page_address) {} static inline
> > void hibernate_restore_unprotect_page(void *page_address) {} #endif
> > /* CONFIG_STRICT_KERNEL_RWX && CONFIG_ARCH_HAS_SET_MEMORY */
> >
> > +#if defined(CONFIG_DEBUG_PAGEALLOC) ||
> > defined(CONFIG_ARCH_HAS_SET_DIRECT_MAP) +static inline void
> > +kernel_map_pages(struct page *page, int numpages, int enable) +{ +
> > __kernel_map_pages(page, numpages, enable); +} +#else +static inline
> > void +kernel_map_pages(struct page *page, int numpages, int enable)
> > {} +#endif +
>
> That change should go into a separate patch.
Hmm, I beleive you refer to moving kernel_map_pages() to snapshot.c,
right?
> For the debug_pagealloc_map_pages() parts
>
> Reviewed-by: David Hildenbrand <david@redhat.com>
Thanks!
> --
> Thanks,
>
> David / dhildenb
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH 1/4] mm: introduce debug_pagealloc_map_pages() helper
From: David Hildenbrand @ 2020-10-26 11:55 UTC (permalink / raw)
To: Mike Rapoport
Cc: Peter Zijlstra, Dave Hansen, linux-mm, Paul Mackerras,
Pavel Machek, H. Peter Anvin, sparclinux, Christoph Lameter,
Will Deacon, linux-riscv, linux-s390, x86, Mike Rapoport,
Christian Borntraeger, Ingo Molnar, Catalin Marinas, Len Brown,
Albert Ou, Vasily Gorbik, linux-pm, Heiko Carstens,
David Rientjes, Borislav Petkov, Andy Lutomirski, Paul Walmsley,
Kirill A. Shutemov, Thomas Gleixner, Joonsoo Kim,
linux-arm-kernel, Rafael J. Wysocki, linux-kernel, Pekka Enberg,
Palmer Dabbelt, Andrew Morton, Edgecombe, Rick P, linuxppc-dev,
David S. Miller
In-Reply-To: <20201026115443.GF1154158@kernel.org>
On 26.10.20 12:54, Mike Rapoport wrote:
> On Mon, Oct 26, 2020 at 12:05:13PM +0100, David Hildenbrand wrote:
>> On 25.10.20 11:15, Mike Rapoport wrote:
>>> From: Mike Rapoport <rppt@linux.ibm.com>
>>>
>>> When CONFIG_DEBUG_PAGEALLOC is enabled, it unmaps pages from the
>>> kernel direct mapping after free_pages(). The pages than need to be
>>> mapped back before they could be used. Theese mapping operations use
>>> __kernel_map_pages() guarded with with debug_pagealloc_enabled().
>>>
>>> The only place that calls __kernel_map_pages() without checking
>>> whether DEBUG_PAGEALLOC is enabled is the hibernation code that
>>> presumes availability of this function when ARCH_HAS_SET_DIRECT_MAP
>>> is set. Still, on arm64, __kernel_map_pages() will bail out when
>>> DEBUG_PAGEALLOC is not enabled but set_direct_map_invalid_noflush()
>>> may render some pages not present in the direct map and hibernation
>>> code won't be able to save such pages.
>>>
>>> To make page allocation debugging and hibernation interaction more
>>> robust, the dependency on DEBUG_PAGEALLOC or ARCH_HAS_SET_DIRECT_MAP
>>> has to be made more explicit.
>>>
>>> Start with combining the guard condition and the call to
>>> __kernel_map_pages() into a single debug_pagealloc_map_pages()
>>> function to emphasize that __kernel_map_pages() should not be called
>>> without DEBUG_PAGEALLOC and use this new function to map/unmap pages
>>> when page allocation debug is enabled.
>>>
>>> As the only remaining user of kernel_map_pages() is the hibernation
>>> code, mode that function into kernel/power/snapshot.c closer to a
>>> caller.
>>
>> s/mode/move/
>>
>>>
>>> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> ---
>>> include/linux/mm.h | 16 +++++++--------- kernel/power/snapshot.c
>>> | 11 +++++++++++ mm/memory_hotplug.c | 3 +-- mm/page_alloc.c
>>> | 6 ++---- mm/slab.c | 8 +++----- 5 files changed, 24
>>> insertions(+), 20 deletions(-)
>>>
>>> diff --git a/include/linux/mm.h b/include/linux/mm.h index
>>> ef360fe70aaf..14e397f3752c 100644 --- a/include/linux/mm.h +++
>>> b/include/linux/mm.h @@ -2927,21 +2927,19 @@ static inline bool
>>> debug_pagealloc_enabled_static(void) #if
>>> defined(CONFIG_DEBUG_PAGEALLOC) ||
>>> defined(CONFIG_ARCH_HAS_SET_DIRECT_MAP) extern void
>>> __kernel_map_pages(struct page *page, int numpages, int enable);
>>>
>>> -/* - * When called in DEBUG_PAGEALLOC context, the call should most
>>> likely be - * guarded by debug_pagealloc_enabled() or
>>> debug_pagealloc_enabled_static() - */ -static inline void
>>> -kernel_map_pages(struct page *page, int numpages, int enable)
>>> +static inline void debug_pagealloc_map_pages(struct page *page, +
>>> int numpages, int enable) { - __kernel_map_pages(page, numpages,
>>> enable); + if (debug_pagealloc_enabled_static()) +
>>> __kernel_map_pages(page, numpages, enable); } + #ifdef
>>> CONFIG_HIBERNATION extern bool kernel_page_present(struct page
>>> *page); #endif /* CONFIG_HIBERNATION */ #else /*
>>> CONFIG_DEBUG_PAGEALLOC || CONFIG_ARCH_HAS_SET_DIRECT_MAP */ -static
>>> inline void -kernel_map_pages(struct page *page, int numpages, int
>>> enable) {} +static inline void debug_pagealloc_map_pages(struct page
>>> *page, + int numpages, int enable) {} #ifdef
>>> CONFIG_HIBERNATION static inline bool kernel_page_present(struct page
>>> *page) { return true; } #endif /* CONFIG_HIBERNATION */ diff --git
>>> a/kernel/power/snapshot.c b/kernel/power/snapshot.c index
>>> 46b1804c1ddf..fa499466f645 100644 --- a/kernel/power/snapshot.c +++
>>> b/kernel/power/snapshot.c @@ -76,6 +76,17 @@ static inline void
>>> hibernate_restore_protect_page(void *page_address) {} static inline
>>> void hibernate_restore_unprotect_page(void *page_address) {} #endif
>>> /* CONFIG_STRICT_KERNEL_RWX && CONFIG_ARCH_HAS_SET_MEMORY */
>>>
>>> +#if defined(CONFIG_DEBUG_PAGEALLOC) ||
>>> defined(CONFIG_ARCH_HAS_SET_DIRECT_MAP) +static inline void
>>> +kernel_map_pages(struct page *page, int numpages, int enable) +{ +
>>> __kernel_map_pages(page, numpages, enable); +} +#else +static inline
>>> void +kernel_map_pages(struct page *page, int numpages, int enable)
>>> {} +#endif +
>>
>> That change should go into a separate patch.
>
> Hmm, I beleive you refer to moving kernel_map_pages() to snapshot.c,
> right?
Sorry, yes!
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH 2/2] ASoC: fsl_aud2htx: Add aud2htx module driver
From: Mark Brown @ 2020-10-26 13:30 UTC (permalink / raw)
To: Shengjiu Wang
Cc: devicetree, alsa-devel, timur, Xiubo.Lee, lgirdwood, linuxppc-dev,
tiwai, perex, nicoleotsuka, robh+dt, festevam, linux-kernel
In-Reply-To: <1603708855-2663-2-git-send-email-shengjiu.wang@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]
On Mon, Oct 26, 2020 at 06:40:55PM +0800, Shengjiu Wang wrote:
> +static int fsl_aud2htx_hw_params(struct snd_pcm_substream *substream,
> + struct snd_pcm_hw_params *params,
> + struct snd_soc_dai *cpu_dai)
> +{
> + struct fsl_aud2htx *aud2htx = snd_soc_dai_get_drvdata(cpu_dai);
> +
> + /* DMA request when number of entries < WTMK_LOW */
> + regmap_update_bits(aud2htx->regmap, AUD2HTX_CTRL_EXT,
> + AUD2HTX_CTRE_DT_MASK, 0);
> +
> + /* Disable interrupts*/
> + regmap_update_bits(aud2htx->regmap, AUD2HTX_IRQ_MASK,
> + AUD2HTX_WM_HIGH_IRQ_MASK |
> + AUD2HTX_WM_LOW_IRQ_MASK |
> + AUD2HTX_OVF_MASK,
> + AUD2HTX_WM_HIGH_IRQ_MASK |
> + AUD2HTX_WM_LOW_IRQ_MASK |
> + AUD2HTX_OVF_MASK);
> +
> + /* Configur watermark */
> + regmap_update_bits(aud2htx->regmap, AUD2HTX_CTRL_EXT,
> + AUD2HTX_CTRE_WL_MASK,
> + AUD2HTX_WTMK_LOW << AUD2HTX_CTRE_WL_SHIFT);
> + regmap_update_bits(aud2htx->regmap, AUD2HTX_CTRL_EXT,
> + AUD2HTX_CTRE_WH_MASK,
> + AUD2HTX_WTMK_HIGH << AUD2HTX_CTRE_WH_SHIFT);
> + return 0;
> +}
This doesn't look like a hw_params operation - it doesn't appear to
reference the params at all, or even containt any conditional
statements. Shouldn't this be configured just once at driver load?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [Bug 209869] New: Kernel 5.10-rc1 fails to boot on a PowerMac G4 3, 6 at an early stage
From: bugzilla-daemon @ 2020-10-26 13:40 UTC (permalink / raw)
To: linuxppc-dev
https://bugzilla.kernel.org/show_bug.cgi?id=209869
Bug ID: 209869
Summary: Kernel 5.10-rc1 fails to boot on a PowerMac G4 3,6 at
an early stage
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: 5.10-rc1
Hardware: PPC-32
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: PPC-32
Assignee: platform_ppc-32@kernel-bugs.osdl.org
Reporter: erhard_f@mailbox.org
Regression: Yes
Created attachment 293201
--> https://bugzilla.kernel.org/attachment.cgi?id=293201&action=edit
kernel .config (5.10-rc1, PowerMac G4 DP)
With current 5.10-rc1 my PowerMac G4 DP fails to boot. The kernel gets
decompressed but shortly afterwards the machine freezes, displaying in black
letters on a white screen:
done
found display : /pci@f0000000/ATY,AlteracParent@10/ATY,Alterac_B@1,
opening...
Kernel 5.9.1 works well on this machine, the kernel .config was carried over
from 5.9.1 with make oldconfig.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH v3 01/16] dt-bindings: usb: usb-hcd: Convert generic USB properties to DT schema
From: Serge Semin @ 2020-10-26 16:46 UTC (permalink / raw)
To: Chunfeng Yun, Rob Herring, Greg Kroah-Hartman, Rob Herring
Cc: Neil Armstrong, linux-kernel, Pavel Parkhomenko, Kevin Hilman,
Krzysztof Kozlowski, Andy Gross, linux-snps-arc, devicetree,
Mathias Nyman, Martin Blumenstingl, Lad Prabhakar, Alexey Malahov,
Bjorn Andersson, linux-arm-kernel, Roger Quadros, Felipe Balbi,
Yoshihiro Shimoda, linux-usb, linux-mips, Serge Semin,
Manu Gautam, linuxppc-dev
In-Reply-To: <20201021154621.a3vtoa4lriwkpnfo@mobilestation>
Folks, any comment on my previous message below?
On Wed, Oct 21, 2020 at 06:46:21PM +0300, Serge Semin wrote:
> On Wed, Oct 21, 2020 at 11:00:36AM +0800, Chunfeng Yun wrote:
> > On Tue, 2020-10-20 at 14:20 +0300, Serge Semin wrote:
> > > The generic USB HCD properties have been described in the legacy bindings
> > > text file: Documentation/devicetree/bindings/usb/generic.txt . Let's
> > > convert it' content into the USB HCD DT schema properties so all USB DT
> > ^ its?
> > > nodes would be validated to have them properly utilized.
> > >
> > > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > > Reviewed-by: Rob Herring <robh@kernel.org>
> > >
> > > ---
> > >
> > > Changelog v2:
> > > - Discard '|' in all the new properties, since we don't need to preserve
> > > the text formatting.
> > > - Convert abbreviated form of the "maximum-speed" enum restriction into
> > > the multi-lined version of the list.
> > > - Drop quotes from around the string constants.
> > > ---
> > > .../devicetree/bindings/usb/generic.txt | 57 ------------
> > > .../devicetree/bindings/usb/usb-hcd.yaml | 88 +++++++++++++++++++
>
> > Do we need change the file name or modify it's title?
> > the title is "Generic USB Host Controller Device Tree Bindings", but
> > some generic properties, such as, dr_mode, usb-role-switch, otg related
> > ones, are usually used by DRD controller, this may cause some confusion.
>
> Hm, good question. A problem of the naming and the properties inclusion do
> exist here. I haven't thought that through when moved all the generic
> properties into the usb-hcd.yaml bindings file. But I don't think it's a good
> idea to rename the file. Most likely the best solution would be to split the
> functionality up as follows:
>
> 1) usb.yaml - common USB controller with generic properties for all USB modes (host, peripheral, otg):
> + $nodename
> + phys
> + phy-names
> + usb-phy
> + maximum-speed
> + phy_type
> 2) usb-hcd.yaml - DT schema for USB host controllers (EHCI/OHCI/UHCI):
> + allOf: [usb.yaml#]
> + companion
> 3) usb-xhci.yaml - DT schema for USB host controllers (xHCI):
> + allOf: [usb-hcd.yaml#]
> + usb2-lpm-disable
> + usb3-lpm-capable
> + quirk-broken-port-ped
> + imod-interval-ns
> 4) usb-drd.yaml - DT schema for USB OTG controllers:
> + otg-rev
> + hnp-disable
> + srp-disable
> + adp-disable
> + usb-role-switch
> + role-switch-default-mode
> + tpl-support
> + dr_mode: [host, peripheral, otg]
>
> So in case if an USB controller is DRD with EHCI host, then it will need
> to pass evaluation of allOf: [usb-hcd.yaml#, usb-drd.yaml#]. If an USB
> controller is DRD with xHCI host, then the next schema can be applied:
> [usb-xhci.yaml#, usb-drd.yaml#]. A conditional schema is also applicable
> here, like this:
> allOf:
> - $ref: usb-drd.yaml#
> - if:
> properties:
> dr_mode:
> const: host
> then:
> $ref: usb-hcd.yaml# (or usb-xhci.yaml#)
> else:
> #ref: usb.yaml#
>
> What do you think? @Rob, @Greg, we need your opinion here.
>
> -Sergey
>
> >
> > > 2 files changed, 88 insertions(+), 57 deletions(-)
> > > delete mode 100644 Documentation/devicetree/bindings/usb/generic.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> > > deleted file mode 100644
> > > index ba472e7aefc9..000000000000
> > > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > > +++ /dev/null
> > > @@ -1,57 +0,0 @@
> > > -Generic USB Properties
> > > -
> > > -Optional properties:
> > > - - maximum-speed: tells USB controllers we want to work up to a certain
> > > - speed. Valid arguments are "super-speed-plus",
> > > - "super-speed", "high-speed", "full-speed" and
> > > - "low-speed". In case this isn't passed via DT, USB
> > > - controllers should default to their maximum HW
> > > - capability.
> > > - - dr_mode: tells Dual-Role USB controllers that we want to work on a
> > > - particular mode. Valid arguments are "host",
> > > - "peripheral" and "otg". In case this attribute isn't
> > > - passed via DT, USB DRD controllers should default to
> > > - OTG.
> > > - - phy_type: tells USB controllers that we want to configure the core to support
> > > - a UTMI+ PHY with an 8- or 16-bit interface if UTMI+ is
> > > - selected. Valid arguments are "utmi" and "utmi_wide".
> > > - In case this isn't passed via DT, USB controllers should
> > > - default to HW capability.
> > > - - otg-rev: tells usb driver the release number of the OTG and EH supplement
> > > - with which the device and its descriptors are compliant,
> > > - in binary-coded decimal (i.e. 2.0 is 0200H). This
> > > - property is used if any real OTG features(HNP/SRP/ADP)
> > > - is enabled, if ADP is required, otg-rev should be
> > > - 0x0200 or above.
> > > - - companion: phandle of a companion
> > > - - hnp-disable: tells OTG controllers we want to disable OTG HNP, normally HNP
> > > - is the basic function of real OTG except you want it
> > > - to be a srp-capable only B device.
> > > - - srp-disable: tells OTG controllers we want to disable OTG SRP, SRP is
> > > - optional for OTG device.
> > > - - adp-disable: tells OTG controllers we want to disable OTG ADP, ADP is
> > > - optional for OTG device.
> > > - - usb-role-switch: boolean, indicates that the device is capable of assigning
> > > - the USB data role (USB host or USB device) for a given
> > > - USB connector, such as Type-C, Type-B(micro).
> > > - see connector/usb-connector.yaml.
> > > - - role-switch-default-mode: indicating if usb-role-switch is enabled, the
> > > - device default operation mode of controller while usb
> > > - role is USB_ROLE_NONE. Valid arguments are "host" and
> > > - "peripheral". Defaults to "peripheral" if not
> > > - specified.
> > > -
> > > -
> > > -This is an attribute to a USB controller such as:
> > > -
> > > -dwc3@4a030000 {
> > > - compatible = "synopsys,dwc3";
> > > - reg = <0x4a030000 0xcfff>;
> > > - interrupts = <0 92 4>
> > > - usb-phy = <&usb2_phy>, <&usb3,phy>;
> > > - maximum-speed = "super-speed";
> > > - dr_mode = "otg";
> > > - phy_type = "utmi_wide";
> > > - otg-rev = <0x0200>;
> > > - adp-disable;
> > > -};
> > > diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.yaml b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> > > index 7263b7f2b510..ee7ea205c71d 100644
> > > --- a/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> > > +++ b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> > > @@ -22,9 +22,97 @@ properties:
> > > description:
> > > Name specifier for the USB PHY
> > >
> > > + maximum-speed:
> > > + description:
> > > + Tells USB controllers we want to work up to a certain speed. In case this
> > > + isn't passed via DT, USB controllers should default to their maximum HW
> > > + capability.
> > > + $ref: /schemas/types.yaml#/definitions/string
> > > + enum:
> > > + - low-speed
> > > + - full-speed
> > > + - high-speed
> > > + - super-speed
> > > + - super-speed-plus
> > > +
> > > + dr_mode:
> > > + description:
> > > + Tells Dual-Role USB controllers that we want to work on a particular
> > > + mode. In case this attribute isn't passed via DT, USB DRD controllers
> > > + should default to OTG.
> > > + $ref: /schemas/types.yaml#/definitions/string
> > > + enum: [host, peripheral, otg]
> > > +
> > > + phy_type:
> > > + description:
> > > + Tells USB controllers that we want to configure the core to support a
> > > + UTMI+ PHY with an 8- or 16-bit interface if UTMI+ is selected. In case
> > > + this isn't passed via DT, USB controllers should default to HW
> > > + capability.
> > > + $ref: /schemas/types.yaml#/definitions/string
> > > + enum: [utmi, utmi_wide]
> > > +
> > > + otg-rev:
> > > + description:
> > > + Tells usb driver the release number of the OTG and EH supplement with
> > > + which the device and its descriptors are compliant, in binary-coded
> > > + decimal (i.e. 2.0 is 0200H). This property is used if any real OTG
> > > + features (HNP/SRP/ADP) is enabled. If ADP is required, otg-rev should be
> > > + 0x0200 or above.
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > +
> > > + companion:
> > > + description: Phandle of a companion device
> > > + $ref: /schemas/types.yaml#/definitions/phandle
> > > +
> > > + hnp-disable:
> > > + description:
> > > + Tells OTG controllers we want to disable OTG HNP. Normally HNP is the
> > > + basic function of real OTG except you want it to be a srp-capable only B
> > > + device.
> > > + type: boolean
> > > +
> > > + srp-disable:
> > > + description:
> > > + Tells OTG controllers we want to disable OTG SRP. SRP is optional for OTG
> > > + device.
> > > + type: boolean
> > > +
> > > + adp-disable:
> > > + description:
> > > + Tells OTG controllers we want to disable OTG ADP. ADP is optional for OTG
> > > + device.
> > > + type: boolean
> > > +
> > > + usb-role-switch:
> > > + description:
> > > + Indicates that the device is capable of assigning the USB data role
> > > + (USB host or USB device) for a given USB connector, such as Type-C,
> > > + Type-B(micro). See connector/usb-connector.yaml.
> > > +
> > > + role-switch-default-mode:
> > > + description:
> > > + Indicates if usb-role-switch is enabled, the device default operation
> > > + mode of controller while usb role is USB_ROLE_NONE.
> > > + $ref: /schemas/types.yaml#/definitions/string
> > > + enum: [host, peripheral]
> > > + default: peripheral
> > > +
> > > examples:
> > > - |
> > > usb {
> > > phys = <&usb2_phy1>, <&usb3_phy1>;
> > > phy-names = "usb";
> > > };
> > > + - |
> > > + usb@4a030000 {
> > > + compatible = "snps,dwc3";
> > > + reg = <0x4a030000 0xcfff>;
> > > + interrupts = <0 92 4>;
> > > + usb-phy = <&usb2_phy>, <&usb3_phy>;
> > > + maximum-speed = "super-speed";
> > > + dr_mode = "otg";
> > > + phy_type = "utmi_wide";
> > > + otg-rev = <0x0200>;
> > > + adp-disable;
> > > + };
> >
^ permalink raw reply
* Re: [PATCH 0/4] arch, mm: improve robustness of direct map manipulation
From: Edgecombe, Rick P @ 2020-10-26 18:05 UTC (permalink / raw)
To: rppt@kernel.org
Cc: david@redhat.com, peterz@infradead.org, catalin.marinas@arm.com,
dave.hansen@linux.intel.com, linux-mm@kvack.org, paulus@samba.org,
pavel@ucw.cz, hpa@zytor.com, sparclinux@vger.kernel.org,
cl@linux.com, will@kernel.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, x86@kernel.org, rppt@linux.ibm.com,
borntraeger@de.ibm.com, mingo@redhat.com, rientjes@google.com,
Brown, Len, aou@eecs.berkeley.edu, gor@linux.ibm.com,
linux-pm@vger.kernel.org, hca@linux.ibm.com, bp@alien8.de,
luto@kernel.org, paul.walmsley@sifive.com, kirill@shutemov.name,
tglx@linutronix.de, iamjoonsoo.kim@lge.com,
linux-arm-kernel@lists.infradead.org, rjw@rjwysocki.net,
linux-kernel@vger.kernel.org, penberg@kernel.org,
palmer@dabbelt.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
In-Reply-To: <20201026090526.GA1154158@kernel.org>
On Mon, 2020-10-26 at 11:05 +0200, Mike Rapoport wrote:
> On Mon, Oct 26, 2020 at 01:13:52AM +0000, Edgecombe, Rick P wrote:
> > On Sun, 2020-10-25 at 12:15 +0200, Mike Rapoport wrote:
> > > Indeed, for architectures that define
> > > CONFIG_ARCH_HAS_SET_DIRECT_MAP
> > > it is
> > > possible that __kernel_map_pages() would fail, but since this
> > > function is
> > > void, the failure will go unnoticed.
> >
> > Could you elaborate on how this could happen? Do you mean during
> > runtime today or if something new was introduced?
>
> A failure in__kernel_map_pages() may happen today. For instance, on
> x86
> if the kernel is built with DEBUG_PAGEALLOC.
>
> __kernel_map_pages(page, 1, 0);
>
> will need to split, say, 2M page and during the split an allocation
> of
> page table could fail.
On x86 at least, DEBUG_PAGEALLOC expects to never have to break a page
on the direct map and even disables locking in cpa because it assumes
this. If this is happening somehow anyway then we should probably fix
that. Even if it's a debug feature, it will not be as useful if it is
causing its own crashes.
I'm still wondering if there is something I'm missing here. It seems
like you are saying there is a bug in some arch's, so let's add a WARN
in cross-arch code to log it as it crashes. A warn and making things
clearer seem like good ideas, but if there is a bug we should fix it.
The code around the callers still functionally assume re-mapping can't
fail.
> Currently, the only user of __kernel_map_pages() outside
> DEBUG_PAGEALLOC
> is hibernation, but I think it would be safer to entirely prevent
> usage
> of __kernel_map_pages() when DEBUG_PAGEALLOC=n.
I totally agree it's error prone FWIW. On x86, my mental model of how
it is supposed to work is: If a page is 4k and NP it cannot fail to be
remapped. set_direct_map_invalid_noflush() should result in 4k NP
pages, and DEBUG_PAGEALLOC should result in all 4k pages on the direct
map. Are you seeing this violated or do I have wrong assumptions?
Beyond whatever you are seeing, for the latter case of new things
getting introduced to an interface with hidden dependencies... Another
edge case could be a new caller to set_memory_np() could result in
large NP pages. None of the callers today should cause this AFAICT, but
it's not great to rely on the callers to know these details.
^ permalink raw reply
* Re: [PATCH] ibmveth: Fix use of ibmveth in a bridge.
From: Jakub Kicinski @ 2020-10-26 18:52 UTC (permalink / raw)
To: Michal Suchanek
Cc: Cristobal Forno, netdev, linux-kernel, Thomas Bogendoerfer,
Paul Mackerras, linuxppc-dev, David S. Miller, Cris Forno
In-Reply-To: <20201026104221.26570-1-msuchanek@suse.de>
On Mon, 26 Oct 2020 11:42:21 +0100 Michal Suchanek wrote:
> From: Thomas Bogendoerfer <tbogendoerfer@suse.de>
>
> The check for src mac address in ibmveth_is_packet_unsupported is wrong.
> Commit 6f2275433a2f wanted to shut down messages for loopback packets,
> but now suppresses bridged frames, which are accepted by the hypervisor
> otherwise bridging won't work at all.
>
> Fixes: 6f2275433a2f ("ibmveth: Detect unsupported packets before sending to the hypervisor")
> Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Since the From: line says Thomas we need a signoff from him.
^ permalink raw reply
* Re: [PATCH 2/4] PM: hibernate: improve robustness of mapping pages in the direct map
From: Edgecombe, Rick P @ 2020-10-26 18:57 UTC (permalink / raw)
To: rppt@kernel.org
Cc: david@redhat.com, peterz@infradead.org, catalin.marinas@arm.com,
dave.hansen@linux.intel.com, linux-mm@kvack.org, paulus@samba.org,
pavel@ucw.cz, hpa@zytor.com, sparclinux@vger.kernel.org,
cl@linux.com, will@kernel.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, x86@kernel.org, rppt@linux.ibm.com,
borntraeger@de.ibm.com, mingo@redhat.com, rientjes@google.com,
Brown, Len, aou@eecs.berkeley.edu, gor@linux.ibm.com,
linux-pm@vger.kernel.org, hca@linux.ibm.com, bp@alien8.de,
luto@kernel.org, paul.walmsley@sifive.com, kirill@shutemov.name,
tglx@linutronix.de, iamjoonsoo.kim@lge.com,
linux-arm-kernel@lists.infradead.org, rjw@rjwysocki.net,
linux-kernel@vger.kernel.org, penberg@kernel.org,
palmer@dabbelt.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
In-Reply-To: <20201026091554.GB1154158@kernel.org>
On Mon, 2020-10-26 at 11:15 +0200, Mike Rapoport wrote:
> On Mon, Oct 26, 2020 at 12:38:32AM +0000, Edgecombe, Rick P wrote:
> > On Sun, 2020-10-25 at 12:15 +0200, Mike Rapoport wrote:
> > > From: Mike Rapoport <rppt@linux.ibm.com>
> > >
> > > When DEBUG_PAGEALLOC or ARCH_HAS_SET_DIRECT_MAP is enabled a page
> > > may
> > > be
> > > not present in the direct map and has to be explicitly mapped
> > > before
> > > it
> > > could be copied.
> > >
> > > On arm64 it is possible that a page would be removed from the
> > > direct
> > > map
> > > using set_direct_map_invalid_noflush() but __kernel_map_pages()
> > > will
> > > refuse
> > > to map this page back if DEBUG_PAGEALLOC is disabled.
> >
> > It looks to me that arm64 __kernel_map_pages() will still attempt
> > to
> > map it if rodata_full is true, how does this happen?
>
> Unless I misread the code, arm64 requires both rodata_full and
> debug_pagealloc_enabled() to be true for __kernel_map_pages() to do
> anything.
> But rodata_full condition applies to set_direct_map_*_noflush() as
> well,
> so with !rodata_full the linear map won't be ever changed.
Hmm, looks to me that __kernel_map_pages() will only skip it if both
debug pagealloc and rodata_full are false.
But now I'm wondering if maybe we could simplify things by just moving
the hibernate unmapped page logic off of the direct map. On x86,
text_poke() used to use this reserved fixmap pte thing that it could
rely on to remap memory with. If hibernate had some separate pte for
remapping like that, then we could not have any direct map restrictions
caused by it/kernel_map_pages(), and it wouldn't have to worry about
relying on anything else.
^ permalink raw reply
* Re: [PATCH] treewide: Convert macro and uses of __section(foo) to __section("foo")
From: Guenter Roeck @ 2020-10-26 19:36 UTC (permalink / raw)
To: Joe Perches
Cc: Miguel Ojeda, Linus Torvalds, Nick Desaulniers, linux-kernel,
clang-built-linux, linuxppc-dev
In-Reply-To: <fe8abcc88cff676ead8ee48db1e993e63b0611c7.1603327264.git.joe@perches.com>
On Wed, Oct 21, 2020 at 07:36:07PM -0700, Joe Perches wrote:
> Use a more generic form for __section that requires quotes to avoid
> complications with clang and gcc differences.
>
> Remove the quote operator # from compiler_attributes.h __section macro.
>
> Convert all unquoted __section(foo) uses to quoted __section("foo").
> Also convert __attribute__((section("foo"))) uses to __section("foo")
> even if the __attribute__ has multiple list entry forms.
>
> Conversion done using a script:
>
> Link: https://lore.kernel.org/lkml/75393e5ddc272dc7403de74d645e6c6e0f4e70eb.camel@perches.com/2-convert_section.pl
>
> Signed-off-by: Joe Perches <joe@perches.com>
> Reviewed-by: Nick Desaulniers <ndesaulniers@gooogle.com>
> Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
s390 (all builds):
Error log:
error: section .boot.preserved.data differs between vmlinux and arch/s390/boot/compressed/vmlinux
make[2]: *** [arch/s390/boot/section_cmp.boot.preserved.data] Error 1
make[2]: *** Waiting for unfinished jobs....
error: section .boot.data differs between vmlinux and arch/s390/boot/compressed/vmlinux
make[2]: *** [arch/s390/boot/section_cmp.boot.data] Error 1
make[1]: *** [bzImage] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [__sub-make] Error 2
Reverting this patch fixes the problem.
Guenter
^ permalink raw reply
* Re: [PATCH] treewide: Convert macro and uses of __section(foo) to __section("foo")
From: Guenter Roeck @ 2020-10-26 19:41 UTC (permalink / raw)
To: Joe Perches
Cc: Miguel Ojeda, Linus Torvalds, Nick Desaulniers, linux-kernel,
clang-built-linux, linuxppc-dev
In-Reply-To: <fe8abcc88cff676ead8ee48db1e993e63b0611c7.1603327264.git.joe@perches.com>
On Wed, Oct 21, 2020 at 07:36:07PM -0700, Joe Perches wrote:
> Use a more generic form for __section that requires quotes to avoid
> complications with clang and gcc differences.
>
> Remove the quote operator # from compiler_attributes.h __section macro.
>
> Convert all unquoted __section(foo) uses to quoted __section("foo").
> Also convert __attribute__((section("foo"))) uses to __section("foo")
> even if the __attribute__ has multiple list entry forms.
>
> Conversion done using a script:
>
> Link: https://lore.kernel.org/lkml/75393e5ddc272dc7403de74d645e6c6e0f4e70eb.camel@perches.com/2-convert_section.pl
>
> Signed-off-by: Joe Perches <joe@perches.com>
> Reviewed-by: Nick Desaulniers <ndesaulniers@gooogle.com>
> Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
> ---
>
make ARCH=um SUBARCH=x86_64 defconfig:
Building um:defconfig ... failed
--------------
Error log:
arch/um/kernel/skas/clone.c:24:16: error: expected declaration specifiers or '...' before string constant
24 | void __section(".__syscall_stub")
| ^~~~~~~~~~~~~~~~~
make[3]: *** [arch/um/kernel/skas/clone.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [arch/um/kernel/skas] Error 2
make[2]: *** Waiting for unfinished jobs....
arch/um/os-Linux/signal.c: In function 'sig_handler_common':
arch/um/os-Linux/signal.c:51:1: warning: the frame size of 2960 bytes is larger than 1024 bytes [-Wframe-larger-than=]
51 | }
| ^
arch/um/os-Linux/signal.c: In function 'timer_real_alarm_handler':
arch/um/os-Linux/signal.c:95:1: warning: the frame size of 2960 bytes is larger than 1024 bytes [-Wframe-larger-than=]
95 | }
| ^
make[1]: *** [arch/um/kernel] Error 2
make[1]: *** Waiting for unfinished jobs....
arch/x86/um/stub_segv.c:11:16: error: expected declaration specifiers or '...' before string constant
11 | void __section(".__syscall_stub")
| ^~~~~~~~~~~~~~~~~
make[2]: *** [arch/x86/um/stub_segv.o] Error 1
make[1]: *** [arch/x86/um] Error 2
make: *** [__sub-make] Error 2
As with s390, reverting this patch fixes the problem.
Guenter
^ permalink raw reply
* Re: [PATCH] treewide: Convert macro and uses of __section(foo) to __section("foo")
From: Nathan Chancellor @ 2020-10-26 19:44 UTC (permalink / raw)
To: Guenter Roeck
Cc: Miguel Ojeda, linuxppc-dev, Nick Desaulniers, linux-kernel,
clang-built-linux, Joe Perches, Linus Torvalds
In-Reply-To: <20201026193652.GA77796@roeck-us.net>
On Mon, Oct 26, 2020 at 12:36:52PM -0700, Guenter Roeck wrote:
> On Wed, Oct 21, 2020 at 07:36:07PM -0700, Joe Perches wrote:
> > Use a more generic form for __section that requires quotes to avoid
> > complications with clang and gcc differences.
> >
> > Remove the quote operator # from compiler_attributes.h __section macro.
> >
> > Convert all unquoted __section(foo) uses to quoted __section("foo").
> > Also convert __attribute__((section("foo"))) uses to __section("foo")
> > even if the __attribute__ has multiple list entry forms.
> >
> > Conversion done using a script:
> >
> > Link: https://lore.kernel.org/lkml/75393e5ddc272dc7403de74d645e6c6e0f4e70eb.camel@perches.com/2-convert_section.pl
> >
> > Signed-off-by: Joe Perches <joe@perches.com>
> > Reviewed-by: Nick Desaulniers <ndesaulniers@gooogle.com>
> > Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
>
> s390 (all builds):
>
> Error log:
> error: section .boot.preserved.data differs between vmlinux and arch/s390/boot/compressed/vmlinux
> make[2]: *** [arch/s390/boot/section_cmp.boot.preserved.data] Error 1
> make[2]: *** Waiting for unfinished jobs....
> error: section .boot.data differs between vmlinux and arch/s390/boot/compressed/vmlinux
> make[2]: *** [arch/s390/boot/section_cmp.boot.data] Error 1
> make[1]: *** [bzImage] Error 2
> make[1]: *** Waiting for unfinished jobs....
> make: *** [__sub-make] Error 2
>
> Reverting this patch fixes the problem.
>
> Guenter
>
Seems like this should be fixed by commit 8e90b4b1305a ("s390: correct
__bootdata / __bootdata_preserved macros").
Cheers,
Nathan
^ permalink raw reply
* Re: Build regressions/improvements in v5.10-rc1
From: Nathan Lynch @ 2020-10-26 20:17 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Scott Cheloha, linuxppc-dev, Linux Kernel Mailing List
In-Reply-To: <CAMuHMdXbsJPnsXg6bA_e32zJkBG1Zzqj-ja5WzHDKL0d9OcfPg@mail.gmail.com>
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> On Mon, Oct 26, 2020 at 10:46 AM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> Below is the list of build error/warning regressions/improvements in
>> v5.10-rc1[1] compared to v5.9[2].
>>
>> Summarized:
>> - build errors: +3/-7
>> - build warnings: +26/-28
>>
>> Happy fixing! ;-)
>>
>> Thanks to the linux-next team for providing the build service.
>>
>> [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/3650b228f83adda7e5ee532e2b90429c03f7b9ec/ (all 192 configs)
>> [2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/bbf5c979011a099af5dc76498918ed7df445635b/ (all 192 configs)
>>
>>
>> *** ERRORS ***
>>
>> 3 error regressions:
>> + /kisskb/src/arch/um/kernel/skas/clone.c: error: expected declaration specifiers or '...' before string constant: => 24:16
>
> um-all{mod,yes}config
>
>> + error: hotplug-memory.c: undefined reference to `of_drconf_to_nid_single': => .text+0x5e0)
>
> powerpc-gcc5/pseries_le_defconfig+NO_NUMA
Probably introduced by:
commit 72cdd117c449896c707fc6cfe5b90978160697d0
Author: Scott Cheloha <cheloha@linux.ibm.com>
Date: Wed Sep 16 09:51:22 2020 -0500
pseries/hotplug-memory: hot-add: skip redundant LMB lookup
Scott?
^ permalink raw reply
* Re: [PATCH] treewide: Convert macro and uses of __section(foo) to __section("foo")
From: Linus Torvalds @ 2020-10-26 20:33 UTC (permalink / raw)
To: Guenter Roeck
Cc: Miguel Ojeda, Nick Desaulniers, Linux Kernel Mailing List,
clang-built-linux, Joe Perches, linuxppc-dev
In-Reply-To: <20201026194127.GA106214@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 826 bytes --]
On Mon, Oct 26, 2020 at 12:41 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> make ARCH=um SUBARCH=x86_64 defconfig:
>
> Building um:defconfig ... failed
> --------------
> Error log:
> arch/um/kernel/skas/clone.c:24:16: error: expected declaration specifiers or '...' before string constant
> arch/x86/um/stub_segv.c:11:16: error: expected declaration specifiers or '...' before string constant
Weird. Is __section() not defined somehow for those files?
It does look like they have very minimal headers, so undoing that
patch just for those two files is likely the right thing to do.
> As with s390, reverting this patch fixes the problem.
s390 should be fixed already.
Is the attached minimal patch sufficient for um to get back to working
order, or is there something else hiding there too?
Linus
[-- Attachment #2: patch --]
[-- Type: application/octet-stream, Size: 935 bytes --]
arch/um/kernel/skas/clone.c | 2 +-
arch/x86/um/stub_segv.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git b/arch/um/kernel/skas/clone.c a/arch/um/kernel/skas/clone.c
index 95c355181dcd..bfb70c456b30 100644
--- b/arch/um/kernel/skas/clone.c
+++ a/arch/um/kernel/skas/clone.c
@@ -21,7 +21,7 @@
* on some systems.
*/
-void __section(".__syscall_stub")
+void __attribute__ ((__section__ (".__syscall_stub")))
stub_clone_handler(void)
{
struct stub_data *data = (struct stub_data *) STUB_DATA;
diff --git b/arch/x86/um/stub_segv.c a/arch/x86/um/stub_segv.c
index fdcd58af707a..27361cbb7ca9 100644
--- b/arch/x86/um/stub_segv.c
+++ a/arch/x86/um/stub_segv.c
@@ -8,7 +8,7 @@
#include <sysdep/mcontext.h>
#include <sys/ucontext.h>
-void __section(".__syscall_stub")
+void __attribute__ ((__section__ (".__syscall_stub")))
stub_segv_handler(int sig, siginfo_t *info, void *p)
{
ucontext_t *uc = p;
^ permalink raw reply related
* Re: [PATCH] ibmveth: Fix use of ibmveth in a bridge.
From: Thomas Bogendoerfer @ 2020-10-26 19:04 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Cristobal Forno, netdev, linux-kernel, Paul Mackerras,
Michal Suchanek, linuxppc-dev, David S. Miller, Cris Forno
In-Reply-To: <20201026115237.21b114fe@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
On Mon, 26 Oct 2020 11:52:37 -0700
Jakub Kicinski <kuba@kernel.org> wrote:
> On Mon, 26 Oct 2020 11:42:21 +0100 Michal Suchanek wrote:
> > From: Thomas Bogendoerfer <tbogendoerfer@suse.de>
> >
> > The check for src mac address in ibmveth_is_packet_unsupported is wrong.
> > Commit 6f2275433a2f wanted to shut down messages for loopback packets,
> > but now suppresses bridged frames, which are accepted by the hypervisor
> > otherwise bridging won't work at all.
> >
> > Fixes: 6f2275433a2f ("ibmveth: Detect unsupported packets before sending to the hypervisor")
> > Signed-off-by: Michal Suchanek <msuchanek@suse.de>
>
> Since the From: line says Thomas we need a signoff from him.
you can add
Signed-off-by: tbogendoerfer@suse.de
Thomas.
--
SUSE Software Solutions Germany GmbH
HRB 36809 (AG Nürnberg)
Geschäftsführer: Felix Imendörffer
^ permalink raw reply
* Re: [PATCH] treewide: Convert macro and uses of __section(foo) to __section("foo")
From: Guenter Roeck @ 2020-10-26 21:27 UTC (permalink / raw)
To: Linus Torvalds
Cc: Miguel Ojeda, Nick Desaulniers, Linux Kernel Mailing List,
clang-built-linux, Joe Perches, linuxppc-dev
In-Reply-To: <CAHk-=whjhHuwANGerJLJyn7jXCfMQMiaBAW+o2r_T+n=Ki+New@mail.gmail.com>
On Mon, Oct 26, 2020 at 01:33:48PM -0700, Linus Torvalds wrote:
> On Mon, Oct 26, 2020 at 12:41 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > make ARCH=um SUBARCH=x86_64 defconfig:
> >
> > Building um:defconfig ... failed
> > --------------
> > Error log:
> > arch/um/kernel/skas/clone.c:24:16: error: expected declaration specifiers or '...' before string constant
> > arch/x86/um/stub_segv.c:11:16: error: expected declaration specifiers or '...' before string constant
>
> Weird. Is __section() not defined somehow for those files?
>
> It does look like they have very minimal headers, so undoing that
> patch just for those two files is likely the right thing to do.
>
> > As with s390, reverting this patch fixes the problem.
>
> s390 should be fixed already.
>
> Is the attached minimal patch sufficient for um to get back to working
> order, or is there something else hiding there too?
>
That works for me.
Tested-by: Guenter Roeck <linux@roeck-us.net>
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH] ibmvscsi: fix race potential race after loss of transport
From: Martin K. Petersen @ 2020-10-26 22:17 UTC (permalink / raw)
To: Tyrel Datwyler
Cc: martin.petersen, linux-scsi, linux-kernel, james.bottomley,
brking, linuxppc-dev
In-Reply-To: <20201025001355.4527-1-tyreld@linux.ibm.com>
Tyrel,
> After a loss of tranport due to an adatper migration or
> crash/disconnect from the host partner there is a tiny window where we
> can race adjusting the request_limit of the adapter.
Applied to 5.10/scsi-fixes, thanks!
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* Re: [PATCH v2] ASoC: fsl_spdif: Add support for higher sample rates
From: Mark Brown @ 2020-10-26 23:45 UTC (permalink / raw)
To: Xiubo.Lee, timur, Shengjiu Wang, perex, tiwai, festevam,
alsa-devel, nicoleotsuka
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1602557360-18795-1-git-send-email-shengjiu.wang@nxp.com>
On Tue, 13 Oct 2020 10:49:20 +0800, Shengjiu Wang wrote:
> Add 88200Hz and 176400Hz sample rates support for TX.
> Add 88200Hz, 176400Hz, 192000Hz sample rates support for RX.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: fsl_spdif: Add support for higher sample rates
commit: 1bfa3eaa4511256ab14555ab2573e6e75194b1fa
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* [REGRESSION] mm: process_vm_readv testcase no longer works after compat_prcoess_vm_readv removed
From: Kyle Huey @ 2020-10-26 22:55 UTC (permalink / raw)
To: open list, Christoph Hellwig
Cc: linux-aio, David Howells, linux-mm, keyrings, sparclinux,
Robert O'Callahan, linux-arch, linux-s390, linux-scsi,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), Linus Torvalds,
Arnd Bergmann, linux-block, Alexander Viro, io-uring,
moderated list:ARM PORT, Jens Axboe, linux-parisc, netdev,
linux-mips, linux-security-module,
open list:FILESYSTEMS (VFS and infrastructure), Andrew Morton,
linuxppc-dev
A test program from the rr[0] test suite, vm_readv_writev[1], no
longer works on 5.10-rc1 when compiled as a 32 bit binary and executed
on a 64 bit kernel. The first process_vm_readv call (on line 35) now
fails with EFAULT. I have bisected this to
c3973b401ef2b0b8005f8074a10e96e3ea093823.
It should be fairly straightforward to extract the test case from our
repository into a standalone program.
- Kyle
[0] https://rr-project.org/
[1] https://github.com/mozilla/rr/blob/master/src/test/vm_readv_writev.c
^ permalink raw reply
* Re: [PATCH v4 0/2] DAI driver for new XCVR IP
From: Mark Brown @ 2020-10-26 23:45 UTC (permalink / raw)
To: linuxppc-dev, Liam Girdwood, Timur Tabi, Nicolin Chen,
Viorel Suman, Philipp Zabel, Shengjiu Wang,
Cosmin-Gabriel Samoila, linux-kernel, Fabio Estevam, Rob Herring,
Xiubo Li, Matthias Schiffer, Jaroslav Kysela, devicetree,
Takashi Iwai, Viorel Suman (OSS), alsa-devel
In-Reply-To: <20201013121733.83684-1-viorel.suman@oss.nxp.com>
On Tue, 13 Oct 2020 15:17:31 +0300, Viorel Suman (OSS) wrote:
> DAI driver for new XCVR IP found in i.MX8MP.
>
> Viorel Suman (2):
> ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver
> ASoC: dt-bindings: fsl_xcvr: Add document for XCVR
>
> Changes since v1:
> - improved 6- and 12-ch layout comment
> - used regmap polling function, improved
> clocks handling in runtime_resume
> - added FW size check in FW load function,
> improved IRQ handler, removed dummy IRQ handlers
> - fixed yaml file
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/2] ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver
commit: 28564486866fa889b78264360022c94836fa8072
[2/2] ASoC: dt-bindings: fsl_xcvr: Add document for XCVR
commit: 0afb88d5a602488f877380ad1ec37cc20c927c68
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH 1/2] ASoC: dt-bindings: fsl_spdif: Add new compatible string for i.MX8QM
From: Mark Brown @ 2020-10-26 23:46 UTC (permalink / raw)
To: Xiubo.Lee, timur, lgirdwood, Shengjiu Wang, perex, devicetree,
tiwai, festevam, robh+dt, alsa-devel, nicoleotsuka
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1602739728-4433-1-git-send-email-shengjiu.wang@nxp.com>
On Thu, 15 Oct 2020 13:28:47 +0800, Shengjiu Wang wrote:
> Add new compatible string "fsl,imx8qm-spdif" for supporting spdif
> module on i.MX8QM.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/2] ASoC: dt-bindings: fsl_spdif: Add new compatible string for i.MX8QM
commit: 87b2fc1139a13cf81d0a95fb2cbaba7daeee8908
[2/2] ASoC: fsl_spdif: Add support for i.MX8QM platform
commit: 516232e3609f485be04445b03723fbaed64a5321
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* [PATCH AUTOSEL 5.9 001/147] powerpc/vmemmap: Fix memory leak with vmemmap list allocation failures.
From: Sasha Levin @ 2020-10-26 23:46 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, Aneesh Kumar K.V, linuxppc-dev
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
[ Upstream commit ccaea15296f9773abd43aaa17ee4b88848e4a505 ]
If we fail to allocate vmemmap list, we don't keep track of allocated
vmemmap block buf. Hence on section deactivate we skip vmemmap block
buf free. This results in memory leak.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200731113500.248306-1-aneesh.kumar@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/mm/init_64.c | 35 ++++++++++++++++++++++++++++-------
1 file changed, 28 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
index 8459056cce671..2ae42c2a5cf04 100644
--- a/arch/powerpc/mm/init_64.c
+++ b/arch/powerpc/mm/init_64.c
@@ -162,16 +162,16 @@ static __meminit struct vmemmap_backing * vmemmap_list_alloc(int node)
return next++;
}
-static __meminit void vmemmap_list_populate(unsigned long phys,
- unsigned long start,
- int node)
+static __meminit int vmemmap_list_populate(unsigned long phys,
+ unsigned long start,
+ int node)
{
struct vmemmap_backing *vmem_back;
vmem_back = vmemmap_list_alloc(node);
if (unlikely(!vmem_back)) {
- WARN_ON(1);
- return;
+ pr_debug("vmemap list allocation failed\n");
+ return -ENOMEM;
}
vmem_back->phys = phys;
@@ -179,6 +179,7 @@ static __meminit void vmemmap_list_populate(unsigned long phys,
vmem_back->list = vmemmap_list;
vmemmap_list = vmem_back;
+ return 0;
}
static bool altmap_cross_boundary(struct vmem_altmap *altmap, unsigned long start,
@@ -199,6 +200,7 @@ static bool altmap_cross_boundary(struct vmem_altmap *altmap, unsigned long star
int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
struct vmem_altmap *altmap)
{
+ bool altmap_alloc;
unsigned long page_size = 1 << mmu_psize_defs[mmu_vmemmap_psize].shift;
/* Align to the page size of the linear mapping. */
@@ -228,13 +230,32 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
p = vmemmap_alloc_block_buf(page_size, node, altmap);
if (!p)
pr_debug("altmap block allocation failed, falling back to system memory");
+ else
+ altmap_alloc = true;
}
- if (!p)
+ if (!p) {
p = vmemmap_alloc_block_buf(page_size, node, NULL);
+ altmap_alloc = false;
+ }
if (!p)
return -ENOMEM;
- vmemmap_list_populate(__pa(p), start, node);
+ if (vmemmap_list_populate(__pa(p), start, node)) {
+ /*
+ * If we don't populate vmemap list, we don't have
+ * the ability to free the allocated vmemmap
+ * pages in section_deactivate. Hence free them
+ * here.
+ */
+ int nr_pfns = page_size >> PAGE_SHIFT;
+ unsigned long page_order = get_order(page_size);
+
+ if (altmap_alloc)
+ vmem_altmap_free(altmap, nr_pfns);
+ else
+ free_pages((unsigned long)p, page_order);
+ return -ENOMEM;
+ }
pr_debug(" * %016lx..%016lx allocated at %p\n",
start, start + page_size, p);
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.9 002/147] powerpc/powernv/smp: Fix spurious DBG() warning
From: Sasha Levin @ 2020-10-26 23:46 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, linuxppc-dev, Oliver O'Halloran, Joel Stanley
In-Reply-To: <20201026234905.1022767-1-sashal@kernel.org>
From: Oliver O'Halloran <oohall@gmail.com>
[ Upstream commit f6bac19cf65c5be21d14a0c9684c8f560f2096dd ]
When building with W=1 we get the following warning:
arch/powerpc/platforms/powernv/smp.c: In function ‘pnv_smp_cpu_kill_self’:
arch/powerpc/platforms/powernv/smp.c:276:16: error: suggest braces around
empty body in an ‘if’ statement [-Werror=empty-body]
276 | cpu, srr1);
| ^
cc1: all warnings being treated as errors
The full context is this block:
if (srr1 && !generic_check_cpu_restart(cpu))
DBG("CPU%d Unexpected exit while offline srr1=%lx!\n",
cpu, srr1);
When building with DEBUG undefined DBG() expands to nothing and GCC emits
the warning due to the lack of braces around an empty statement.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200804005410.146094-2-oohall@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/platforms/powernv/smp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/smp.c b/arch/powerpc/platforms/powernv/smp.c
index b2ba3e95bda73..bbf361f23ae86 100644
--- a/arch/powerpc/platforms/powernv/smp.c
+++ b/arch/powerpc/platforms/powernv/smp.c
@@ -43,7 +43,7 @@
#include <asm/udbg.h>
#define DBG(fmt...) udbg_printf(fmt)
#else
-#define DBG(fmt...)
+#define DBG(fmt...) do { } while (0)
#endif
static void pnv_smp_setup_cpu(int cpu)
--
2.25.1
^ 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