Re: [Intel-gfx] [PATCH v3 2/4] drm/i915/pmu: Use kstat_irqs to get interrupt count
+ Tvrtko and Chris for comments
Code seems to be added in:
commit 0cd4684d6ea9a4ffec33fc19de4dd667bb90d0a5
Author: Tvrtko Ursulin
Date: Tue Nov 21 18:18:50 2017 +
drm/i915/pmu: Add interrupt count metric
I think later in the thread there was a suggestion to replace this with
simple counter increment in IRQ handler.
Regards, Joonas
Quoting Thomas Gleixner (2020-12-06 18:38:44)
> On Fri, Dec 04 2020 at 18:43, Jerry Snitselaar wrote:
>
> > Now that kstat_irqs is exported, get rid of count_interrupts in
> > i915_pmu.c
> > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > @@ -423,22 +423,6 @@ static enum hrtimer_restart i915_sample(struct hrtimer
> > *hrtimer)
> > return HRTIMER_RESTART;
> > }
> >
> > -static u64 count_interrupts(struct drm_i915_private *i915)
> > -{
> > - /* open-coded kstat_irqs() */
> > - struct irq_desc *desc = irq_to_desc(i915->drm.pdev->irq);
> > - u64 sum = 0;
> > - int cpu;
> > -
> > - if (!desc || !desc->kstat_irqs)
> > - return 0;
> > -
> > - for_each_possible_cpu(cpu)
> > - sum += *per_cpu_ptr(desc->kstat_irqs, cpu);
> > -
> > - return sum;
> > -}
>
> May I ask why this has been merged in the first place?
>
> Nothing in a driver has ever to fiddle with the internals of an irq
> descriptor. We have functions for properly accessing them. Just because
> C allows to fiddle with everything is not a justification. If the
> required function is not exported then adding the export with a proper
> explanation is not asked too much.
>
> Also this lacks protection or at least a comment why this can be called
> safely and is not subject to a concurrent removal of the irq descriptor.
> The same problem exists when calling kstat_irqs(). It's even documented
> at the top of the function.
>
> Thanks,
>
> tglx
>
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: linux-next: Fixes tag needs some work in the clk tree
Hi Stephen²,
On Wed, Dec 9, 2020 at 6:29 PM Stephen Boyd wrote:
> Quoting Geert Uytterhoeven (2020-12-08 00:37:00)
> > On Mon, Dec 7, 2020 at 11:06 PM Stephen Rothwell
> > wrote:
> > > In commit
> > >
> > > c3f207f6d23d ("clk: renesas: r8a779a0: Make
> > > rcar_r8a779a0_cpg_clk_register() static")
> > >
> > > Fixes tag
> > >
> > > Fixes: c07439dea94050b6 ("clk: renesas: cpg-mssr: Add support for R-Car
> > > V3U")
> > >
> > > has these problem(s):
> > >
> > > - Target SHA1 does not exist
> >
> > Oops, my bad.
> >
> > > Maybe you meant
> > >
> > > Fixes: 17bcc8035d2d ("clk: renesas: cpg-mssr: Add support for R-Car V3U")
> >
> > Yes I did.
> >
> > Mike/Stephen: do you want me to respin my pull requests?
>
> Sure a respin is fine. I can fix it up in clk tree. Any chance your
Done, sorry for the mess.
> trees can be pulled into linux-next? That would find this earlier.
That sounds like a great idea, also for pinctrl.
Can you please add the following:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
renesas-clk
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
renesas-pinctrl
?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 00/20] ethernet: ucc_geth: assorted fixes and simplifications
On 05/12/2020 22.27, Jakub Kicinski wrote: > On Sat, 5 Dec 2020 22:11:39 +0100 Rasmus Villemoes wrote: >>> Looks like a nice clean up on a quick look. >>> >>> Please separate patches 1 and 11 (which are the two bug fixes I see) >> >> I think patch 2 is a bug fix as well, but I'd like someone from NXP to >> comment. > > Sure, makes sense. > >>> rebase (retest) and post them against the net tree: >>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/ >> >> So I thought this would go through Li Yang's tree. Li, any preference? Will you take this series, or are you ok with the three soc/fsl/qe patches going through the net tree along with the rest? Rasmus
[PATCH v9] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver
The CPUfreq HW present in some Mediatek chipsets offloads the steps necessary for changing the frequency of CPUs. The driver implements the cpufreq driver interface for this hardware engine. This patch depends on MT6779 DTS patchset[1] submitted by Hanks Chen. >From v8 to v9, there are three more modifications. 1. Based on patchset[2], align binding with scmi for performance domain. 2. Add the CPUFREQ fast switch function support and define DVFS latency. 3. Based on patchser[3], add energy model API parameter for mW. >From v7 to v8, there are three more patches based on patchset v8[4]. This patchset is about to register power table to Energy model for EAS and thermal usage. 1. EM CPU power table - Register energy model table for EAS and thermal cooling device usage. - Read the coresponding LUT for power table. 2. SVS initialization - The SVS(Smart Voltage Scaling) engine is a hardware which is used to calculate optimized voltage values for CPU power domain. DVFS driver could apply those optimized voltage values to reduce power consumption. - Driver will polling if HW engine is done for SVS initialization. After that, driver will read power table and register it to EAS. - CPUs must be in power on state when doing SVS. Use pm_qos to block cpu-idle state for SVS initializing. 3. Cooling device flag - Add cooling device flag for thermal [1] https://lkml.org/lkml/2020/8/4/1094 [2] https://lore.kernel.org/lkml/20201116181356.804590-1-sudeep.ho...@arm.com/ [3] https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next=c250d50fe2ce627ca9805d9c8ac11cbbf922a4a6 [4] https://lkml.org/lkml/2020/9/23/384 Hector.Yuan (2): cpufreq: mediatek-hw: Add support for CPUFREQ HW dt-bindings: cpufreq: add bindings for MediaTek cpufreq HW .../bindings/cpufreq/cpufreq-mediatek-hw.yaml | 112 ++ drivers/cpufreq/Kconfig.arm| 12 + drivers/cpufreq/Makefile |1 + drivers/cpufreq/mediatek-cpufreq-hw.c | 370 4 files changed, 495 insertions(+) create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml create mode 100644 drivers/cpufreq/mediatek-cpufreq-hw.c
[PATCH v9 1/2] cpufreq: mediatek-hw: Add support for CPUFREQ HW
From: "Hector.Yuan"
Add cpufreq HW support.
Signed-off-by: Hector.Yuan
---
drivers/cpufreq/Kconfig.arm | 12 ++
drivers/cpufreq/Makefile |1 +
drivers/cpufreq/mediatek-cpufreq-hw.c | 370 +
3 files changed, 383 insertions(+)
create mode 100644 drivers/cpufreq/mediatek-cpufreq-hw.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 015ec0c..3031471 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -123,6 +123,18 @@ config ARM_MEDIATEK_CPUFREQ
help
This adds the CPUFreq driver support for MediaTek SoCs.
+config ARM_MEDIATEK_CPUFREQ_HW
+ tristate "MediaTek CPUFreq HW driver"
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ default m
+ help
+ Support for the CPUFreq HW driver.
+ Some MediaTek chipsets have a HW engine to offload the steps
+ necessary for changing the frequency of the CPUs. Firmware loaded
+ in this engine exposes a programming interface to the OS.
+ The driver implements the cpufreq interface for this HW engine.
+ Say Y if you want to support CPUFreq HW.
+
config ARM_OMAP2PLUS_CPUFREQ
bool "TI OMAP2+"
depends on ARCH_OMAP2PLUS
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index f1b7e3d..ffc61cd 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_ARM_IMX6Q_CPUFREQ) +=
imx6q-cpufreq.o
obj-$(CONFIG_ARM_IMX_CPUFREQ_DT) += imx-cpufreq-dt.o
obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
obj-$(CONFIG_ARM_MEDIATEK_CPUFREQ) += mediatek-cpufreq.o
+obj-$(CONFIG_ARM_MEDIATEK_CPUFREQ_HW) += mediatek-cpufreq-hw.o
obj-$(CONFIG_MACH_MVEBU_V7)+= mvebu-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)+= omap-cpufreq.o
obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o
diff --git a/drivers/cpufreq/mediatek-cpufreq-hw.c
b/drivers/cpufreq/mediatek-cpufreq-hw.c
new file mode 100644
index 000..604af18
--- /dev/null
+++ b/drivers/cpufreq/mediatek-cpufreq-hw.c
@@ -0,0 +1,370 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020 MediaTek Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LUT_MAX_ENTRIES32U
+#define LUT_FREQ GENMASK(11, 0)
+#define LUT_ROW_SIZE 0x4
+#define CPUFREQ_HW_STATUS BIT(0)
+#define SVS_HW_STATUS BIT(1)
+#define POLL_USEC 1000
+#define TIMEOUT_USEC 30
+
+enum {
+ REG_FREQ_LUT_TABLE,
+ REG_FREQ_ENABLE,
+ REG_FREQ_PERF_STATE,
+ REG_FREQ_HW_STATE,
+ REG_EM_POWER_TBL,
+ REG_FREQ_LATENCY,
+
+ REG_ARRAY_SIZE,
+};
+
+struct cpufreq_mtk {
+ struct cpufreq_frequency_table *table;
+ void __iomem *reg_bases[REG_ARRAY_SIZE];
+ int nr_opp;
+ cpumask_t related_cpus;
+};
+
+static const u16 cpufreq_mtk_offsets[REG_ARRAY_SIZE] = {
+ [REG_FREQ_LUT_TABLE]= 0x0,
+ [REG_FREQ_ENABLE] = 0x84,
+ [REG_FREQ_PERF_STATE] = 0x88,
+ [REG_FREQ_HW_STATE] = 0x8c,
+ [REG_EM_POWER_TBL] = 0x90,
+ [REG_FREQ_LATENCY] = 0x110,
+};
+
+static struct cpufreq_mtk *mtk_freq_domain_map[NR_CPUS];
+
+static int __maybe_unused
+mtk_cpufreq_get_cpu_power(unsigned long *mW,
+ unsigned long *KHz, struct device *cpu_dev)
+{
+ struct cpufreq_mtk *c = mtk_freq_domain_map[cpu_dev->id];
+ int i;
+
+ for (i = 0; i < c->nr_opp; i++) {
+ if (c->table[i].frequency < *KHz)
+ break;
+ }
+ i--;
+
+ *KHz = c->table[i].frequency;
+ *mW = readl_relaxed(c->reg_bases[REG_EM_POWER_TBL] +
+ i * LUT_ROW_SIZE) / 1000;
+
+ return 0;
+}
+
+static int mtk_cpufreq_hw_target_index(struct cpufreq_policy *policy,
+ unsigned int index)
+{
+ struct cpufreq_mtk *c = policy->driver_data;
+
+ writel_relaxed(index, c->reg_bases[REG_FREQ_PERF_STATE]);
+
+ return 0;
+}
+
+static unsigned int mtk_cpufreq_hw_get(unsigned int cpu)
+{
+ struct cpufreq_mtk *c;
+ unsigned int index;
+
+ c = mtk_freq_domain_map[cpu];
+
+ index = readl_relaxed(c->reg_bases[REG_FREQ_PERF_STATE]);
+ index = min(index, LUT_MAX_ENTRIES - 1);
+
+ return c->table[index].frequency;
+}
+
+static unsigned int mtk_cpufreq_hw_fast_switch(struct cpufreq_policy *policy,
+ unsigned int target_freq)
+{
+ struct cpufreq_mtk *c = policy->driver_data;
+ unsigned int index;
+
+ index = cpufreq_table_find_index_dl(policy, target_freq);
+
+ writel_relaxed(index, c->reg_bases[REG_FREQ_PERF_STATE]);
+
+
[PATCH v9 2/2] dt-bindings: cpufreq: add bindings for MediaTek cpufreq HW
From: "Hector.Yuan"
Add devicetree bindings for MediaTek HW driver.
Signed-off-by: Hector.Yuan
---
.../bindings/cpufreq/cpufreq-mediatek-hw.yaml | 112
1 file changed, 112 insertions(+)
create mode 100644
Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
new file mode 100644
index 000..1ce2a17
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cpufreq/cpufreq-mediatek-hw.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek's CPUFREQ Bindings
+
+maintainers:
+ - Hector Yuan
+
+description:
+ CPUFREQ HW is a hardware engine used by MediaTek
+ SoCs to manage frequency in hardware. It is capable of controlling frequency
+ for multiple clusters.
+
+properties:
+ compatible:
+const: mediatek,cpufreq-hw
+
+ reg:
+minItems: 1
+maxItems: 2
+description: |
+ Addresses and sizes for the memory of the HW bases in each frequency
domain.
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+cpus {
+#address-cells = <1>;
+#size-cells = <0>;
+
+cpu0: cpu@0 {
+device_type = "cpu";
+compatible = "arm,cortex-a55";
+enable-method = "psci";
+performance-domains = < 0>;
+reg = <0x000>;
+};
+
+cpu1: cpu@100 {
+device_type = "cpu";
+compatible = "arm,cortex-a55";
+enable-method = "psci";
+performance-domains = < 0>;
+reg = <0x100>;
+};
+
+cpu2: cpu@200 {
+device_type = "cpu";
+compatible = "arm,cortex-a55";
+enable-method = "psci";
+performance-domains = < 0>;
+reg = <0x200>;
+};
+
+cpu3: cpu@300 {
+device_type = "cpu";
+compatible = "arm,cortex-a55";
+enable-method = "psci";
+performance-domains = < 0>;
+reg = <0x300>;
+};
+
+cpu4: cpu@400 {
+device_type = "cpu";
+compatible = "arm,cortex-a55";
+enable-method = "psci";
+performance-domains = < 1>;
+reg = <0x400>;
+};
+
+cpu5: cpu@500 {
+device_type = "cpu";
+compatible = "arm,cortex-a55";
+enable-method = "psci";
+performance-domains = < 1>;
+reg = <0x500>;
+};
+
+cpu6: cpu@600 {
+device_type = "cpu";
+compatible = "arm,cortex-a75";
+enable-method = "psci";
+performance-domains = < 1>;
+reg = <0x600>;
+};
+
+cpu7: cpu@700 {
+device_type = "cpu";
+compatible = "arm,cortex-a75";
+enable-method = "psci";
+performance-domains = < 1>;
+reg = <0x700>;
+};
+};
+
+/* ... */
+
+soc {
+#address-cells = <2>;
+#size-cells = <2>;
+performance: performance-controller@11bc00 {
+compatible = "mediatek,cpufreq-hw";
+reg = <0 0x0011bc10 0 0x120>, <0 0x0011bd30 0 0x120>;
+#performance-domain-cells = <1>;
+};
+};
--
1.7.9.5
[PATCH] [v3] blk-mq-tag: make blk_mq_tag_busy() return void
As no one cares about the return value of blk_mq_tag_busy() and
__blk_mq_tag_busy(), so make them return void.
Other change is to simplify blk_mq_tag_idle().
Signed-off-by: Xianting Tian
Reviewed-by: Ming Lei
---
block/blk-mq-tag.c | 4 +---
block/blk-mq-tag.h | 16 ++--
2 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
index 9c92053e7..01c0bb1fb 100644
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -21,7 +21,7 @@
* to get tag when first time, the other shared-tag users could reserve
* budget for it.
*/
-bool __blk_mq_tag_busy(struct blk_mq_hw_ctx *hctx)
+void __blk_mq_tag_busy(struct blk_mq_hw_ctx *hctx)
{
if (blk_mq_is_sbitmap_shared(hctx->flags)) {
struct request_queue *q = hctx->queue;
@@ -35,8 +35,6 @@ bool __blk_mq_tag_busy(struct blk_mq_hw_ctx *hctx)
!test_and_set_bit(BLK_MQ_S_TAG_ACTIVE, >state))
atomic_inc(>tags->active_queues);
}
-
- return true;
}
/*
diff --git a/block/blk-mq-tag.h b/block/blk-mq-tag.h
index 7d3e6b333..4b4ccd794 100644
--- a/block/blk-mq-tag.h
+++ b/block/blk-mq-tag.h
@@ -60,23 +60,19 @@ enum {
BLK_MQ_TAG_MAX = BLK_MQ_NO_TAG - 1,
};
-extern bool __blk_mq_tag_busy(struct blk_mq_hw_ctx *);
+extern void __blk_mq_tag_busy(struct blk_mq_hw_ctx *);
extern void __blk_mq_tag_idle(struct blk_mq_hw_ctx *);
-static inline bool blk_mq_tag_busy(struct blk_mq_hw_ctx *hctx)
+static inline void blk_mq_tag_busy(struct blk_mq_hw_ctx *hctx)
{
- if (!(hctx->flags & BLK_MQ_F_TAG_QUEUE_SHARED))
- return false;
-
- return __blk_mq_tag_busy(hctx);
+ if (hctx->flags & BLK_MQ_F_TAG_QUEUE_SHARED)
+ __blk_mq_tag_busy(hctx);
}
static inline void blk_mq_tag_idle(struct blk_mq_hw_ctx *hctx)
{
- if (!(hctx->flags & BLK_MQ_F_TAG_QUEUE_SHARED))
- return;
-
- __blk_mq_tag_idle(hctx);
+ if (hctx->flags & BLK_MQ_F_TAG_QUEUE_SHARED)
+ __blk_mq_tag_idle(hctx);
}
static inline bool blk_mq_tag_is_reserved(struct blk_mq_tags *tags,
--
2.17.1
RE: [PATCH v3 2/3] scsi: ufs: Keep device active mode only fWriteBoosterBufferFlushDuringHibernate == 1
> On Wed, 2020-12-09 at 07:40 +, Avri Altman wrote: > > > According to the JEDEC UFS 3.1 Spec, If > > > fWriteBoosterBufferFlushDuringHibernate > > > is set to one, the device flushes the WriteBooster Buffer data > > > automatically > > > whenever the link enters the hibernate (HIBERN8) state. While the > > > flushing > > > operation is in progress, the device should be kept in Active power > > > mode. > > > Currently, we set this flag during the UFSHCD probe stage, but we > > > didn't deal > > > with its programming failure. Even this failure is less likely to > > > occur, but > > > still it is possible. > > > > How about reading it on every ufshcd_wb_need_flush? > > > > Thanks, > > Avri > > > Hi Avri > I was using that way, no different from the current my way. Instead, > reading on every time will add some delay. As long as the UFS device > returns the successful, we assume that this flag has been properly > set. so, just keeping is_hibern8_wb_flush if set, I think it is > enough. Right. But it is a small price, and you no longer need to worry about rare error event. Also adding an if (fWriteBoosterBufferFlushDuringHibernate == 1) will allow some more flexibility, e.g. shutting it off from user-space (ufs-utils), unlike today, that it is categorically on for all platforms / devices. Anyway, if you decided to add new capability, Preferable to do it in a different series. Thanks, Avri
Re: [PATCH 4/4] phy: freescale: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support
Hi,
On Tue, Dec 08, 2020 at 06:03:05PM +0800, Liu Ying wrote:
> On Tue, 2020-12-08 at 10:24 +0100, Guido Günther wrote:
> > Hi Liu,
> > some minor comments inline:
> >
> > On Fri, Dec 04, 2020 at 03:33:44PM +0800, Liu Ying wrote:
> > > i.MX8qxp SoC embeds a Mixel MIPI DPHY + LVDS PHY combo which supports
> > > either a MIPI DSI display or a LVDS display. The PHY mode is controlled
> > > by SCU firmware and the driver would call a SCU firmware function to
> > > configure the PHY mode. The single LVDS PHY has 4 data lanes to support
> > > a LVDS display. Also, with a master LVDS PHY and a slave LVDS PHY, they
> > > may work together to support a LVDS display with 8 data lanes(usually,
> > > dual
> > > LVDS link display). Note that this patch supports the LVDS PHY mode only
> > > for the i.MX8qxp Mixel combo PHY, i.e., the MIPI DPHY mode is yet to be
> > > supported, so for now error would be returned from ->set_mode() if MIPI
> > > DPHY mode is passed over to it for the combo PHY.
> > >
> > > Cc: Guido Günther
> > > Cc: Robert Chiras
> > > Cc: Kishon Vijay Abraham I
> > > Cc: Vinod Koul
> > > Cc: Shawn Guo
> > > Cc: Sascha Hauer
> > > Cc: Pengutronix Kernel Team
> > > Cc: Fabio Estevam
> > > Cc: NXP Linux Team
> > > Signed-off-by: Liu Ying
> > > ---
> > > drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c | 266
> > > -
> > > 1 file changed, 255 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > > b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > > index a95572b..37084a9 100644
> > > --- a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > > +++ b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > > @@ -4,17 +4,31 @@
> > > * Copyright 2019 Purism SPC
> > > */
> > >
> > > +#include
> > > #include
> > > #include
> > > #include
> > > +#include
> > > +#include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > #include
> > > #include
> > > #include
> > > +#include
> > > +
> > > +/* Control and Status Registers(CSR) */
> > > +#define PHY_CTRL 0x00
> > > +#define CCM_MASKGENMASK(7, 5)
> > > +#define CCM(n) FIELD_PREP(CCM_MASK, (n))
> > > +#define CA_MASK GENMASK(4, 2)
> > > +#define CA(n) FIELD_PREP(CA_MASK, (n))
> > > +#define RFB BIT(1)
> > > +#define LVDS_EN BIT(0)
> > >
> > > /* DPHY registers */
> > > #define DPHY_PD_DPHY 0x00
> > > @@ -55,8 +69,15 @@
> > > #define PWR_ON 0
> > > #define PWR_OFF 1
> > >
> > > +#define MIN_VCO_FREQ 64000
> > > +#define MAX_VCO_FREQ 15
> > > +
> > > +#define MIN_LVDS_REFCLK_FREQ 2400
> > > +#define MAX_LVDS_REFCLK_FREQ 15000
> > > +
> > > enum mixel_dphy_devtype {
> > > MIXEL_IMX8MQ,
> > > + MIXEL_IMX8QXP,
> > > };
> > >
> > > struct mixel_dphy_devdata {
> > > @@ -65,6 +86,7 @@ struct mixel_dphy_devdata {
> > > u8 reg_rxlprp;
> > > u8 reg_rxcdrp;
> > > u8 reg_rxhs_settle;
> > > + bool is_combo; /* MIPI DPHY and LVDS PHY combo */
> > > };
> > >
> > > static const struct mixel_dphy_devdata mixel_dphy_devdata[] = {
> > > @@ -74,6 +96,10 @@ static const struct mixel_dphy_devdata
> > > mixel_dphy_devdata[] = {
> > > .reg_rxlprp = 0x40,
> > > .reg_rxcdrp = 0x44,
> > > .reg_rxhs_settle = 0x48,
> > > + .is_combo = false,
> > > + },
> > > + [MIXEL_IMX8QXP] = {
> > > + .is_combo = true,
> > > },
> > > };
> > >
> > > @@ -95,8 +121,12 @@ struct mixel_dphy_cfg {
> > > struct mixel_dphy_priv {
> > > struct mixel_dphy_cfg cfg;
> > > struct regmap *regmap;
> > > + struct regmap *lvds_regmap;
> > > struct clk *phy_ref_clk;
> > > const struct mixel_dphy_devdata *devdata;
> > > + struct imx_sc_ipc *ipc_handle;
> > > + bool is_slave;
> > > + int id;
> > > };
> > >
> > > static const struct regmap_config mixel_dphy_regmap_config = {
> > > @@ -317,7 +347,8 @@ static int mixel_dphy_set_pll_params(struct phy *phy)
> > > return 0;
> > > }
> > >
> > > -static int mixel_dphy_configure(struct phy *phy, union
> > > phy_configure_opts *opts)
> > > +static int
> > > +mixel_dphy_configure_mipi_dphy(struct phy *phy, union phy_configure_opts
> > > *opts)
> > > {
> > > struct mixel_dphy_priv *priv = phy_get_drvdata(phy);
> > > struct mixel_dphy_cfg cfg = { 0 };
> > > @@ -345,15 +376,118 @@ static int mixel_dphy_configure(struct phy *phy,
> > > union phy_configure_opts *opts)
> > > return 0;
> > > }
> > >
> > > +static int
> > > +mixel_dphy_configure_lvds_phy(struct phy *phy, union phy_configure_opts
> > > *opts)
> > > +{
> > > + struct mixel_dphy_priv *priv = phy_get_drvdata(phy);
> > > + struct phy_configure_opts_lvds *lvds_opts = >lvds;
> > > + unsigned long data_rate;
> > > + unsigned long fvco;
> > > + u32 rsc;
> > > + u32 co;
Re: [PATCH 3/3] s390/mm: Define arch_get_mappable_range()
On 12/10/20 12:34 PM, David Hildenbrand wrote:
>
>> Am 10.12.2020 um 07:58 schrieb Heiko Carstens :
>>
>> On Thu, Dec 10, 2020 at 09:48:11AM +0530, Anshuman Khandual wrote:
> Alternatively leaving __segment_load() and vmem_add_memory() unchanged
> will create three range checks i.e two memhp_range_allowed() and the
> existing VMEM_MAX_PHYS check in vmem_add_mapping() on all the hotplug
> paths, which is not optimal.
Ah, sorry. I didn't follow this discussion too closely. I just thought
my point of view would be clear: let's not have two different ways to
check for the same thing which must be kept in sync.
Therefore I was wondering why this next version is still doing
that. Please find a way to solve this.
>>>
>>> The following change is after the current series and should work with
>>> and without memory hotplug enabled. There will be just a single place
>>> i.e vmem_get_max_addr() to update in case the maximum address changes
>>> from VMEM_MAX_PHYS to something else later.
>>
>> Still not. That's way too much code churn for what you want to achieve.
>> If the s390 specific patch would look like below you can add
>>
>> Acked-by: Heiko Carstens
>>
>> But please make sure that the arch_get_mappable_range() prototype in
>> linux/memory_hotplug.h is always visible and does not depend on
>> CONFIG_MEMORY_HOTPLUG. I'd like to avoid seeing sparse warnings
>> because of this.
>>
>> Thanks.
>>
>> diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
>> index 77767850d0d0..e0e78234ae57 100644
>> --- a/arch/s390/mm/init.c
>> +++ b/arch/s390/mm/init.c
>> @@ -291,6 +291,7 @@ int arch_add_memory(int nid, u64 start, u64 size,
>>if (WARN_ON_ONCE(params->pgprot.pgprot != PAGE_KERNEL.pgprot))
>>return -EINVAL;
>>
>> +VM_BUG_ON(!memhp_range_allowed(start, size, 1));
>>rc = vmem_add_mapping(start, size);
>>if (rc)
>>return rc;
>> diff --git a/arch/s390/mm/vmem.c b/arch/s390/mm/vmem.c
>> index b239f2ba93b0..ccd55e2f97f9 100644
>> --- a/arch/s390/mm/vmem.c
>> +++ b/arch/s390/mm/vmem.c
>> @@ -4,6 +4,7 @@
>> *Author(s): Heiko Carstens
>> */
>>
>> +#include
>> #include
>> #include
>> #include
>> @@ -532,11 +533,23 @@ void vmem_remove_mapping(unsigned long start, unsigned
>> long size)
>>mutex_unlock(_mutex);
>> }
>>
>> +struct range arch_get_mappable_range(void)
>> +{
>> +struct range range;
>> +
>> +range.start = 0;
>> +range.end = VMEM_MAX_PHYS;
>> +return range;
>> +}
>> +
>> int vmem_add_mapping(unsigned long start, unsigned long size)
>> {
>> +struct range range;
>>int ret;
>>
>> -if (start + size > VMEM_MAX_PHYS ||
>> +range = arch_get_mappable_range();
>> +if (start < range.start ||
>> +start + size > range.end ||
>>start + size < start)
>>return -ERANGE;
>>
>>
>
> Right, what I had in mind as reply to v1. Not sure if we really need new
> checks in common code. Having a new memhp_get_pluggable_range() would be
> sufficient for my use case (virtio-mem).
Didn't quite understand "Not sure if we really need new checks in common code".
Could you please be more specific. New checks as in pagemap_range() ? Because
other places it is either replacing erstwhile check_hotplug_memory_addressable()
or just moving existing checks from platform arch_add_memory() to the beginning
of various hotplug paths.
[PATCH 1/7] vfio: iommu_type1: Clear added dirty bit when unwind pin
Currently we do not clear added dirty bit of bitmap when unwind
pin, so if pin failed at halfway, we set unnecessary dirty bit
in bitmap. Clearing added dirty bit when unwind pin, userspace
will see less dirty page, which can save much time to handle them.
Note that we should distinguish the bits added by pin and the bits
already set before pin, so introduce bitmap_added to record this.
Signed-off-by: Keqian Zhu
---
drivers/vfio/vfio_iommu_type1.c | 33 ++---
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 67e827638995..f129d24a6ec3 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -637,7 +637,11 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
struct vfio_iommu *iommu = iommu_data;
struct vfio_group *group;
int i, j, ret;
+ unsigned long pgshift = __ffs(iommu->pgsize_bitmap);
unsigned long remote_vaddr;
+ unsigned long bitmap_offset;
+ unsigned long *bitmap_added;
+ dma_addr_t iova;
struct vfio_dma *dma;
bool do_accounting;
@@ -650,6 +654,12 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
mutex_lock(>lock);
+ bitmap_added = bitmap_zalloc(npage, GFP_KERNEL);
+ if (!bitmap_added) {
+ ret = -ENOMEM;
+ goto pin_done;
+ }
+
/* Fail if notifier list is empty */
if (!iommu->notifier.head) {
ret = -EINVAL;
@@ -664,7 +674,6 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
do_accounting = !IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu);
for (i = 0; i < npage; i++) {
- dma_addr_t iova;
struct vfio_pfn *vpfn;
iova = user_pfn[i] << PAGE_SHIFT;
@@ -699,14 +708,10 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
}
if (iommu->dirty_page_tracking) {
- unsigned long pgshift = __ffs(iommu->pgsize_bitmap);
-
- /*
-* Bitmap populated with the smallest supported page
-* size
-*/
- bitmap_set(dma->bitmap,
- (iova - dma->iova) >> pgshift, 1);
+ /* Populated with the smallest supported page size */
+ bitmap_offset = (iova - dma->iova) >> pgshift;
+ if (!test_and_set_bit(bitmap_offset, dma->bitmap))
+ set_bit(i, bitmap_added);
}
}
ret = i;
@@ -722,14 +727,20 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
pin_unwind:
phys_pfn[i] = 0;
for (j = 0; j < i; j++) {
- dma_addr_t iova;
-
iova = user_pfn[j] << PAGE_SHIFT;
dma = vfio_find_dma(iommu, iova, PAGE_SIZE);
vfio_unpin_page_external(dma, iova, do_accounting);
phys_pfn[j] = 0;
+
+ if (test_bit(j, bitmap_added)) {
+ bitmap_offset = (iova - dma->iova) >> pgshift;
+ clear_bit(bitmap_offset, dma->bitmap);
+ }
}
pin_done:
+ if (bitmap_added)
+ bitmap_free(bitmap_added);
+
mutex_unlock(>lock);
return ret;
}
--
2.23.0
[PATCH 4/7] vfio: iommu_type1: Fix missing dirty page when promote pinned_scope
When we pin or detach a group which is not dirty tracking capable,
we will try to promote pinned_scope of vfio_iommu.
If we succeed to do so, vfio only report pinned_scope as dirty to
userspace next time, but these memory written before pin or detach
is missed.
The solution is that we must populate all dma range as dirty before
promoting pinned_scope of vfio_iommu.
Signed-off-by: Keqian Zhu
---
drivers/vfio/vfio_iommu_type1.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index bd9a94590ebc..00684597b098 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -1633,6 +1633,20 @@ static struct vfio_group
*vfio_iommu_find_iommu_group(struct vfio_iommu *iommu,
return group;
}
+static void vfio_populate_bitmap_all(struct vfio_iommu *iommu)
+{
+ struct rb_node *n;
+ unsigned long pgshift = __ffs(iommu->pgsize_bitmap);
+
+ for (n = rb_first(>dma_list); n; n = rb_next(n)) {
+ struct vfio_dma *dma = rb_entry(n, struct vfio_dma, node);
+ unsigned long nbits = dma->size >> pgshift;
+
+ if (dma->iommu_mapped)
+ bitmap_set(dma->bitmap, 0, nbits);
+ }
+}
+
static void promote_pinned_page_dirty_scope(struct vfio_iommu *iommu)
{
struct vfio_domain *domain;
@@ -1657,6 +1671,10 @@ static void promote_pinned_page_dirty_scope(struct
vfio_iommu *iommu)
}
iommu->pinned_page_dirty_scope = true;
+
+ /* Set all bitmap to avoid missing dirty page */
+ if (iommu->dirty_page_tracking)
+ vfio_populate_bitmap_all(iommu);
}
static bool vfio_iommu_has_sw_msi(struct list_head *group_resv_regions,
--
2.23.0
[PATCH 6/7] vfio: iommu_type1: Drop parameter "pgsize" of vfio_iova_dirty_bitmap.
We always use the smallest supported page size of vfio_iommu as
pgsize. Remove parameter "pgsize" of vfio_iova_dirty_bitmap.
Signed-off-by: Keqian Zhu
---
drivers/vfio/vfio_iommu_type1.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 32ab889c8193..2d7a5cd9b916 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -1026,11 +1026,12 @@ static int update_user_bitmap(u64 __user *bitmap,
struct vfio_iommu *iommu,
}
static int vfio_iova_dirty_bitmap(u64 __user *bitmap, struct vfio_iommu *iommu,
- dma_addr_t iova, size_t size, size_t pgsize)
+ dma_addr_t iova, size_t size)
{
struct vfio_dma *dma;
struct rb_node *n;
- unsigned long pgshift = __ffs(pgsize);
+ unsigned long pgshift = __ffs(iommu->pgsize_bitmap);
+ size_t pgsize = (size_t)1 << pgshift;
int ret;
/*
@@ -2861,8 +2862,7 @@ static int vfio_iommu_type1_dirty_pages(struct vfio_iommu
*iommu,
if (iommu->dirty_page_tracking)
ret = vfio_iova_dirty_bitmap(range.bitmap.data,
iommu, range.iova,
-range.size,
-range.bitmap.pgsize);
+range.size);
else
ret = -EINVAL;
out_unlock:
--
2.23.0
[PATCH 5/7] vfio: iommu_type1: Drop parameter "pgsize" of vfio_dma_bitmap_alloc_all
We always use the smallest supported page size of vfio_iommu as
pgsize. Remove parameter "pgsize" of vfio_dma_bitmap_alloc_all.
Signed-off-by: Keqian Zhu
---
drivers/vfio/vfio_iommu_type1.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 00684597b098..32ab889c8193 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -236,9 +236,10 @@ static void vfio_dma_populate_bitmap(struct vfio_dma *dma,
size_t pgsize)
}
}
-static int vfio_dma_bitmap_alloc_all(struct vfio_iommu *iommu, size_t pgsize)
+static int vfio_dma_bitmap_alloc_all(struct vfio_iommu *iommu)
{
struct rb_node *n;
+ size_t pgsize = (size_t)1 << __ffs(iommu->pgsize_bitmap);
for (n = rb_first(>dma_list); n; n = rb_next(n)) {
struct vfio_dma *dma = rb_entry(n, struct vfio_dma, node);
@@ -2798,12 +2799,9 @@ static int vfio_iommu_type1_dirty_pages(struct
vfio_iommu *iommu,
return -EINVAL;
if (dirty.flags & VFIO_IOMMU_DIRTY_PAGES_FLAG_START) {
- size_t pgsize;
-
mutex_lock(>lock);
- pgsize = 1 << __ffs(iommu->pgsize_bitmap);
if (!iommu->dirty_page_tracking) {
- ret = vfio_dma_bitmap_alloc_all(iommu, pgsize);
+ ret = vfio_dma_bitmap_alloc_all(iommu);
if (!ret)
iommu->dirty_page_tracking = true;
}
--
2.23.0
[PATCH 2/7] vfio: iommu_type1: Initially set the pinned_page_dirty_scope
Currently there are 3 ways to promote the pinned_page_dirty_scope status of vfio_iommu: 1. Through pin interface. 2. Detach a group without dirty tracking. 3. Attach a group with dirty tracking. For point 3, the only chance to change the pinned status is that the vfio_iommu is newly created. Consider that we can safely set the pinned status when create a new vfio_iommu, as we do it, the point 3 can be removed to reduce operations. Signed-off-by: Keqian Zhu --- drivers/vfio/vfio_iommu_type1.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c index f129d24a6ec3..c52bcefba96b 100644 --- a/drivers/vfio/vfio_iommu_type1.c +++ b/drivers/vfio/vfio_iommu_type1.c @@ -2064,12 +2064,8 @@ static int vfio_iommu_type1_attach_group(void *iommu_data, * Non-iommu backed group cannot dirty memory directly, * it can only use interfaces that provide dirty * tracking. -* The iommu scope can only be promoted with the -* addition of a dirty tracking group. */ group->pinned_page_dirty_scope = true; - if (!iommu->pinned_page_dirty_scope) - update_pinned_page_dirty_scope(iommu); mutex_unlock(>lock); return 0; @@ -2457,6 +2453,7 @@ static void *vfio_iommu_type1_open(unsigned long arg) INIT_LIST_HEAD(>iova_list); iommu->dma_list = RB_ROOT; iommu->dma_avail = dma_entry_limit; + iommu->pinned_page_dirty_scope = true; mutex_init(>lock); BLOCKING_INIT_NOTIFIER_HEAD(>notifier); -- 2.23.0
[PATCH 3/7] vfio: iommu_type1: Make an explicit "promote" semantic
When we want to promote pinned_page_scope of vfio_iommu, we
should call the "update" function to visit all vfio_group,
but when we want to downgrade it, we can set the flag directly.
Giving above, we can give an explicit "promote" semantic to
that function. BTW, if vfio_iommu has been promoted, then it
can return early.
Signed-off-by: Keqian Zhu
---
drivers/vfio/vfio_iommu_type1.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index c52bcefba96b..bd9a94590ebc 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -148,7 +148,7 @@ static int put_pfn(unsigned long pfn, int prot);
static struct vfio_group *vfio_iommu_find_iommu_group(struct vfio_iommu *iommu,
struct iommu_group *iommu_group);
-static void update_pinned_page_dirty_scope(struct vfio_iommu *iommu);
+static void promote_pinned_page_dirty_scope(struct vfio_iommu *iommu);
/*
* This code handles mapping and unmapping of user data buffers
* into DMA'ble space using the IOMMU
@@ -719,7 +719,7 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
group = vfio_iommu_find_iommu_group(iommu, iommu_group);
if (!group->pinned_page_dirty_scope) {
group->pinned_page_dirty_scope = true;
- update_pinned_page_dirty_scope(iommu);
+ promote_pinned_page_dirty_scope(iommu);
}
goto pin_done;
@@ -1633,27 +1633,26 @@ static struct vfio_group
*vfio_iommu_find_iommu_group(struct vfio_iommu *iommu,
return group;
}
-static void update_pinned_page_dirty_scope(struct vfio_iommu *iommu)
+static void promote_pinned_page_dirty_scope(struct vfio_iommu *iommu)
{
struct vfio_domain *domain;
struct vfio_group *group;
+ if (iommu->pinned_page_dirty_scope)
+ return;
+
list_for_each_entry(domain, >domain_list, next) {
list_for_each_entry(group, >group_list, next) {
- if (!group->pinned_page_dirty_scope) {
- iommu->pinned_page_dirty_scope = false;
+ if (!group->pinned_page_dirty_scope)
return;
- }
}
}
if (iommu->external_domain) {
domain = iommu->external_domain;
list_for_each_entry(group, >group_list, next) {
- if (!group->pinned_page_dirty_scope) {
- iommu->pinned_page_dirty_scope = false;
+ if (!group->pinned_page_dirty_scope)
return;
- }
}
}
@@ -2348,7 +2347,7 @@ static void vfio_iommu_type1_detach_group(void
*iommu_data,
struct vfio_iommu *iommu = iommu_data;
struct vfio_domain *domain;
struct vfio_group *group;
- bool update_dirty_scope = false;
+ bool promote_dirty_scope = false;
LIST_HEAD(iova_copy);
mutex_lock(>lock);
@@ -2356,7 +2355,7 @@ static void vfio_iommu_type1_detach_group(void
*iommu_data,
if (iommu->external_domain) {
group = find_iommu_group(iommu->external_domain, iommu_group);
if (group) {
- update_dirty_scope = !group->pinned_page_dirty_scope;
+ promote_dirty_scope = !group->pinned_page_dirty_scope;
list_del(>next);
kfree(group);
@@ -2386,7 +2385,7 @@ static void vfio_iommu_type1_detach_group(void
*iommu_data,
continue;
vfio_iommu_detach_group(domain, group);
- update_dirty_scope = !group->pinned_page_dirty_scope;
+ promote_dirty_scope = !group->pinned_page_dirty_scope;
list_del(>next);
kfree(group);
/*
@@ -2422,8 +2421,8 @@ static void vfio_iommu_type1_detach_group(void
*iommu_data,
* Removal of a group without dirty tracking may allow the iommu scope
* to be promoted.
*/
- if (update_dirty_scope)
- update_pinned_page_dirty_scope(iommu);
+ if (promote_dirty_scope)
+ promote_pinned_page_dirty_scope(iommu);
mutex_unlock(>lock);
}
--
2.23.0
[PATCH 7/7] vfio: iommu_type1: Drop parameter "pgsize" of update_user_bitmap
We always use the smallest supported page size of vfio_iommu as
pgsize. Drop parameter "pgsize" of update_user_bitmap.
Signed-off-by: Keqian Zhu
---
drivers/vfio/vfio_iommu_type1.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 2d7a5cd9b916..edb0a6468e8d 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -989,10 +989,9 @@ static void vfio_update_pgsize_bitmap(struct vfio_iommu
*iommu)
}
static int update_user_bitmap(u64 __user *bitmap, struct vfio_iommu *iommu,
- struct vfio_dma *dma, dma_addr_t base_iova,
- size_t pgsize)
+ struct vfio_dma *dma, dma_addr_t base_iova)
{
- unsigned long pgshift = __ffs(pgsize);
+ unsigned long pgshift = __ffs(iommu->pgsize_bitmap);
unsigned long nbits = dma->size >> pgshift;
unsigned long bit_offset = (dma->iova - base_iova) >> pgshift;
unsigned long copy_offset = bit_offset / BITS_PER_LONG;
@@ -1057,7 +1056,7 @@ static int vfio_iova_dirty_bitmap(u64 __user *bitmap,
struct vfio_iommu *iommu,
if (dma->iova > iova + size - 1)
break;
- ret = update_user_bitmap(bitmap, iommu, dma, iova, pgsize);
+ ret = update_user_bitmap(bitmap, iommu, dma, iova);
if (ret)
return ret;
@@ -1203,7 +1202,7 @@ static int vfio_dma_do_unmap(struct vfio_iommu *iommu,
if (unmap->flags & VFIO_DMA_UNMAP_FLAG_GET_DIRTY_BITMAP) {
ret = update_user_bitmap(bitmap->data, iommu, dma,
-unmap->iova, pgsize);
+unmap->iova);
if (ret)
break;
}
--
2.23.0
[PATCH 0/7] vfio: iommu_type1: Some fixes and optimization
Hi folks, This patch series aim to fix up or optimize some code about vfio dirty log tracking. patch 1: Optimize dirty log when unwind pin pages. patch 2-3: Optimize promoting pinned_page_dirty_scope. patch 4: Fix up dirty log missing when promote pinned_page_dirty_scope. patch 5-7: Drop superfluous parameter "pgsize" of some functions. Wish they improves the robustness of vfio dirty log tracking. Thanks, Keqian Keqian Zhu (7): vfio: iommu_type1: Clear added dirty bit when unwind pin vfio: iommu_type1: Initially set the pinned_page_dirty_scope vfio: iommu_type1: Make an explicit "promote" semantic vfio: iommu_type1: Fix missing dirty page when promote pinned_scope vfio: iommu_type1: Drop parameter "pgsize" of vfio_dma_bitmap_alloc_all vfio: iommu_type1: Drop parameter "pgsize" of vfio_iova_dirty_bitmap. vfio: iommu_type1: Drop parameter "pgsize" of update_user_bitmap drivers/vfio/vfio_iommu_type1.c | 108 +++- 1 file changed, 65 insertions(+), 43 deletions(-) -- 2.23.0
Re: [RFC v2 1/1] vfio/platform: add support for msi
HI Eric,
On Tue, Dec 8, 2020 at 2:13 AM Auger Eric wrote:
>
> Hi Vikas,
>
> On 12/3/20 3:50 PM, Vikas Gupta wrote:
> > Hi Eric,
> >
> > On Wed, Dec 2, 2020 at 8:14 PM Auger Eric wrote:
> >>
> >> Hi Vikas,
> >>
> >> On 11/24/20 5:16 PM, Vikas Gupta wrote:
> >>> MSI support for platform devices.
> >>>
> >>> Signed-off-by: Vikas Gupta
> >>> ---
> >>> drivers/vfio/platform/vfio_platform_common.c | 99 ++-
> >>> drivers/vfio/platform/vfio_platform_irq.c | 260 +-
> >>> drivers/vfio/platform/vfio_platform_private.h | 16 ++
> >>> include/uapi/linux/vfio.h | 43 +++
> >>> 4 files changed, 401 insertions(+), 17 deletions(-)
> >>>
> >>> diff --git a/drivers/vfio/platform/vfio_platform_common.c
> >>> b/drivers/vfio/platform/vfio_platform_common.c
> >>> index c0771a9567fb..b0bfc0f4ee1f 100644
> >>> --- a/drivers/vfio/platform/vfio_platform_common.c
> >>> +++ b/drivers/vfio/platform/vfio_platform_common.c
> >>> @@ -16,6 +16,7 @@
> >>> #include
> >>> #include
> >>> #include
> >>> +#include
> >>>
> >>> #include "vfio_platform_private.h"
> >>>
> >>> @@ -344,9 +345,16 @@ static long vfio_platform_ioctl(void *device_data,
> >>>
> >>> } else if (cmd == VFIO_DEVICE_GET_IRQ_INFO) {
> >>> struct vfio_irq_info info;
> >>> + struct vfio_info_cap caps = { .buf = NULL, .size = 0 };
> >>> + struct vfio_irq_info_cap_msi *msi_info = NULL;
> >>> + unsigned long capsz;
> >>> + int ext_irq_index = vdev->num_irqs - vdev->num_ext_irqs;
> >>>
> >>> minsz = offsetofend(struct vfio_irq_info, count);
> >>>
> >>> + /* For backward compatibility, cannot require this */
> >>> + capsz = offsetofend(struct vfio_irq_info, cap_offset);
> >>> +
> >>> if (copy_from_user(, (void __user *)arg, minsz))
> >>> return -EFAULT;
> >>>
> >>> @@ -356,9 +364,89 @@ static long vfio_platform_ioctl(void *device_data,
> >>> if (info.index >= vdev->num_irqs)
> >>> return -EINVAL;
> >>>
> >>> + if (info.argsz >= capsz)
> >>> + minsz = capsz;
> >>> +
> >>> + if (info.index == ext_irq_index) {
> >> nit: n case we add new ext indices afterwards, I would check info.index
> >> - ext_irq_index against an VFIO_EXT_IRQ_MSI define.
> >>> + struct vfio_irq_info_cap_type cap_type = {
> >>> + .header.id = VFIO_IRQ_INFO_CAP_TYPE,
> >>> + .header.version = 1 };
> >>> + int i;
> >>> + int ret;
> >>> + int num_msgs;
> >>> + size_t msi_info_size;
> >>> + struct vfio_platform_irq *irq;
> >> nit: I think generally the opposite order (length) is chosen. This also
> >> would better match the existing style in this file
> > Ok will fix it
> >>> +
> >>> + info.index = array_index_nospec(info.index,
> >>> + vdev->num_irqs);
> >>> +
> >>> + irq = >irqs[info.index];
> >>> +
> >>> + info.flags = irq->flags;
> >> I think this can be removed given [*]
> > Sure.
> >>> + cap_type.type = irq->type;
> >>> + cap_type.subtype = irq->subtype;
> >>> +
> >>> + ret = vfio_info_add_capability(,
> >>> +_type.header,
> >>> +sizeof(cap_type));
> >>> + if (ret)
> >>> + return ret;
> >>> +
> >>> + num_msgs = irq->num_ctx;
> >> do would want to return the cap even if !num_ctx?
> > If num_ctx = 0 then VFIO_IRQ_INFO_CAP_MSI_DESCS should not be written.
> > I`ll take care of same.
> >>> +
> >>> + msi_info_size = struct_size(msi_info, msgs,
> >>> num_msgs);
> >>> +
> >>> + msi_info = kzalloc(msi_info_size, GFP_KERNEL);
> >>> + if (!msi_info) {
> >>> + kfree(caps.buf);
> >>> + return -ENOMEM;
> >>> + }
> >>> +
> >>> + msi_info->header.id = VFIO_IRQ_INFO_CAP_MSI_DESCS;
> >>> + msi_info->header.version = 1;
> >>> + msi_info->nr_msgs = num_msgs;
> >>> +
> >>> + for (i = 0; i < num_msgs; i++) {
> >>> + struct vfio_irq_ctx *ctx = >ctx[i];
> >>> +
> >>> + msi_info->msgs[i].addr_lo =
> >>> ctx->msg.address_lo;
> >>> + msi_info->msgs[i].addr_hi =
> >>> ctx->msg.address_hi;
> >>> + msi_info->msgs[i].data = ctx->msg.data;
> >>> + }
> >>> +
> >>> + ret =
Re: [PATCH 3/3] mfd: bd9571mwv: Add support for BD9574MWF
On Thu, 2020-12-10 at 04:44 +, Yoshihiro Shimoda wrote:
> Hi Geert-san,
>
> Thank you for your review!
>
> > From: Geert Uytterhoeven, Sent: Wednesday, December 9, 2020 10:30
> > PM
>
> > > --- a/drivers/mfd/bd9571mwv.c
> > > +++ b/drivers/mfd/bd9571mwv.c
> > >
> > > @@ -182,6 +272,8 @@ static int bd9571mwv_probe(struct i2c_client
> > > *client,
> > > product_code = (unsigned int)ret;
> > > if (product_code == BD9571MWV_PRODUCT_CODE_VAL)
> > > bd->data = _data;
> > > + else if (product_code == BD9574MWF_PRODUCT_CODE_VAL)
> > > + bd->data = _data;
> > >
> > > if (!bd->data) {
> > > dev_err(bd->dev, "No found supported device
> > > %d\n",
> >
> > While BD9571MWV and BD9574MWF can be distinguished at runtime,
> > I think it would still be a good idea to document a
> > "rohm,bd9574mwf"
> > compatible value in the DT bindings, and let the driver match on
> > that.
>
> In this driver point of view, we can use such the DT bindings,
> however, in the board point of view, it's difficult to describe
> which chip is installed on r8a77990-ebisu.dts. So, I'd like to
> keep this runtime detection.
First of all - I don't want to insist changes here so my comment can be
ignored. I would definitely like seeing the support for BD9574 in-tree!
But as a 'nit':
I don't know what are the difficulties you are referring to so it's
hard for me to comment this. Without better understanding of board dts
files - I think BD9574MWF should really have own compatible as I
understood it is different from the BD9571MWV. Relying on product code
probing sounds like something that may easily break when/if new
variants are produced. ( I've seen new HW variants using the same
ID information being produced in previous companies I've worked. Sure
ROHM wouldn't do this but still... :] ). And producing boards where DTS
does not allow describing the correct components sounds like asking for
a nose-bleed to me... If probing of IC type fails AND there is devices
with wrong PMIC information burned in DT - then fixing it can be a
nightmare. So I would really try make DTS files such that they can be
changed to match the actual board. (Perhaps introduce the compatible
for BD9574MWF - make this driver to match both of the PMICs - leave the
runtime probing here for now - and in parallel work with the DTS files
so that eventually the probing can be removed(?) That was my 10 cents
on this topic :] )
Best Regards
Matti Vaittinen
Re: [PATCH net v2] lan743x: fix rx_napi_poll/interrupt ping-pong
Am 10.12.2020 um 04:55 schrieb Sven Van Asbroeck:
> From: Sven Van Asbroeck
>
> Even if there is more rx data waiting on the chip, the rx napi poll fn
> will never run more than once - it will always read a few buffers, then
> bail out and re-arm interrupts. Which results in ping-pong between napi
> and interrupt.
>
> This defeats the purpose of napi, and is bad for performance.
>
> Fix by making the rx napi poll behave identically to other ethernet
> drivers:
> 1. initialize rx napi polling with an arbitrary budget (64).
> 2. in the polling fn, return full weight if rx queue is not depleted,
>this tells the napi core to "keep polling".
> 3. update the rx tail ("ring the doorbell") once for every 8 processed
>rx ring buffers.
>
> Thanks to Jakub Kicinski, Eric Dumazet and Andrew Lunn for their expert
> opinions and suggestions.
>
> Tested with 20 seconds of full bandwidth receive (iperf3):
> rx irqs softirqs(NET_RX)
> -
> before 2382733620
> after 129 4081
>
In addition you could play with sysfs attributes
/sys/class/net//gro_flush_timeout
/sys/class/net//napi_defer_hard_irqs
> Tested-by: Sven Van Asbroeck # lan7430
> Fixes: 23f0703c125be ("lan743x: Add main source files for new lan743x driver")
> Signed-off-by: Sven Van Asbroeck
> ---
>
> Tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git #
> b7e4ba9a91df
>
> To: Bryan Whitehead
> To: Microchip Linux Driver Support
> To: "David S. Miller"
> To: Jakub Kicinski
> Cc: Andrew Lunn
> Cc: net...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
>
> drivers/net/ethernet/microchip/lan743x_main.c | 44 ++-
> 1 file changed, 23 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/net/ethernet/microchip/lan743x_main.c
> b/drivers/net/ethernet/microchip/lan743x_main.c
> index 87b6c59a1e03..30ec308b9a4c 100644
> --- a/drivers/net/ethernet/microchip/lan743x_main.c
> +++ b/drivers/net/ethernet/microchip/lan743x_main.c
> @@ -1964,6 +1964,14 @@ static struct sk_buff *lan743x_rx_allocate_skb(struct
> lan743x_rx *rx)
> length, GFP_ATOMIC | GFP_DMA);
> }
>
> +static void lan743x_rx_update_tail(struct lan743x_rx *rx, int index)
> +{
> + /* update the tail once per 8 descriptors */
> + if ((index & 7) == 7)
> + lan743x_csr_write(rx->adapter, RX_TAIL(rx->channel_number),
> + index);
> +}
> +
> static int lan743x_rx_init_ring_element(struct lan743x_rx *rx, int index,
> struct sk_buff *skb)
> {
> @@ -1994,6 +2002,7 @@ static int lan743x_rx_init_ring_element(struct
> lan743x_rx *rx, int index,
> descriptor->data0 = (RX_DESC_DATA0_OWN_ |
> (length & RX_DESC_DATA0_BUF_LENGTH_MASK_));
> skb_reserve(buffer_info->skb, RX_HEAD_PADDING);
> + lan743x_rx_update_tail(rx, index);
>
> return 0;
> }
> @@ -2012,6 +2021,7 @@ static void lan743x_rx_reuse_ring_element(struct
> lan743x_rx *rx, int index)
> descriptor->data0 = (RX_DESC_DATA0_OWN_ |
> ((buffer_info->buffer_length) &
> RX_DESC_DATA0_BUF_LENGTH_MASK_));
> + lan743x_rx_update_tail(rx, index);
> }
>
> static void lan743x_rx_release_ring_element(struct lan743x_rx *rx, int index)
> @@ -2223,34 +2233,26 @@ static int lan743x_rx_napi_poll(struct napi_struct
> *napi, int weight)
> struct lan743x_rx *rx = container_of(napi, struct lan743x_rx, napi);
> struct lan743x_adapter *adapter = rx->adapter;
> u32 rx_tail_flags = 0;
> - int count;
> + int count, result;
>
> if (rx->vector_flags & LAN743X_VECTOR_FLAG_SOURCE_STATUS_W2C) {
> /* clear int status bit before reading packet */
> lan743x_csr_write(adapter, DMAC_INT_STS,
> DMAC_INT_BIT_RXFRM_(rx->channel_number));
> }
> - count = 0;
> - while (count < weight) {
> - int rx_process_result = lan743x_rx_process_packet(rx);
> -
> - if (rx_process_result == RX_PROCESS_RESULT_PACKET_RECEIVED) {
> - count++;
> - } else if (rx_process_result ==
> - RX_PROCESS_RESULT_NOTHING_TO_DO) {
> + for (count = 0; count < weight; count++) {
> + result = lan743x_rx_process_packet(rx);
> + if (result == RX_PROCESS_RESULT_NOTHING_TO_DO)
> break;
> - } else if (rx_process_result ==
> - RX_PROCESS_RESULT_PACKET_DROPPED) {
> - continue;
> - }
> }
> rx->frame_count += count;
> - if (count == weight)
> - goto done;
> + if (count == weight || result == RX_PROCESS_RESULT_PACKET_RECEIVED)
> + return weight;
>
> if (!napi_complete_done(napi, count))
> - goto done;
> + return count;
>
>
Re: [PATCH 1/1] net/ipv4/inet_fragment: Batch fqdir destroy works
On Thu, 10 Dec 2020 01:17:58 +0100 Eric Dumazet wrote:
>
>
> On 12/8/20 10:45 AM, SeongJae Park wrote:
> > From: SeongJae Park
> >
> > In 'fqdir_exit()', a work for destruction of the 'fqdir' is enqueued.
> > The work function, 'fqdir_work_fn()', calls 'rcu_barrier()'. In case of
> > intensive 'fqdir_exit()' (e.g., frequent 'unshare(CLONE_NEWNET)'
> > systemcalls), this increased contention could result in unacceptably
> > high latency of 'rcu_barrier()'. This commit avoids such contention by
> > doing the destruction in batched manner, as similar to that of
> > 'cleanup_net()'.
>
> Any numbers to share ? I have never seen an issue.
On our 40 CPU cores / 70GB DRAM machine, 15GB of available memory was reduced
within 2 minutes while my artificial reproducer runs. The reproducer merely
repeats 'unshare(CLONE_NEWNET)' in a loop for 50,000 times. The reproducer is
not only artificial but resembles the behavior of our real workloads.
While the reproducer runs, 'cleanup_net()' was called only 4 times. First two
calls quickly finished, but third call took about 30 seconds, and the fourth
call didn't finished until the reproducer finishes. We also confirmed the
third and fourth calls just waiting for 'rcu_barrier()'.
I think you've not seen this issue before because we are doing very intensive
'unshare()' calls. Also, this is not reproducible on every hardware. On my 6
CPU machine, the problem didn't reproduce.
>
> >
> > Signed-off-by: SeongJae Park
> > ---
> > include/net/inet_frag.h | 2 +-
> > net/ipv4/inet_fragment.c | 28
> > 2 files changed, 21 insertions(+), 9 deletions(-)
> >
> > diff --git a/include/net/inet_frag.h b/include/net/inet_frag.h
> > index bac79e817776..558893d8810c 100644
> > --- a/include/net/inet_frag.h
> > +++ b/include/net/inet_frag.h
> > @@ -20,7 +20,7 @@ struct fqdir {
> >
> > /* Keep atomic mem on separate cachelines in structs that include it */
> > atomic_long_t mem cacheline_aligned_in_smp;
> > - struct work_struct destroy_work;
> > + struct llist_node destroy_list;
> > };
> >
> > /**
> > diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c
> > index 10d31733297d..796b559137c5 100644
> > --- a/net/ipv4/inet_fragment.c
> > +++ b/net/ipv4/inet_fragment.c
> > @@ -145,12 +145,19 @@ static void inet_frags_free_cb(void *ptr, void *arg)
> > inet_frag_destroy(fq);
> > }
> >
> > +static LLIST_HEAD(destroy_list);
> > +
> > static void fqdir_work_fn(struct work_struct *work)
> > {
> > - struct fqdir *fqdir = container_of(work, struct fqdir, destroy_work);
> > - struct inet_frags *f = fqdir->f;
> > + struct llist_node *kill_list;
> > + struct fqdir *fqdir;
> > + struct inet_frags *f;
> > +
> > + /* Atomically snapshot the list of fqdirs to destroy */
> > + kill_list = llist_del_all(_list);
> >
> > - rhashtable_free_and_destroy(>rhashtable, inet_frags_free_cb,
> > NULL);
> > + llist_for_each_entry(fqdir, kill_list, destroy_list)
> > + rhashtable_free_and_destroy(>rhashtable,
> > inet_frags_free_cb, NULL);
> >
>
>
> OK, it seems rhashtable_free_and_destroy() has cond_resched() so we are not
> going
> to hold this cpu for long periods.
>
> > /* We need to make sure all ongoing call_rcu(..., inet_frag_destroy_rcu)
> > * have completed, since they need to dereference fqdir.
> > @@ -158,10 +165,13 @@ static void fqdir_work_fn(struct work_struct *work)
> > */
> > rcu_barrier();
> >
> > - if (refcount_dec_and_test(>refcnt))
> > - complete(>completion);
> > + llist_for_each_entry(fqdir, kill_list, destroy_list) {
>
> Don't we need the llist_for_each_entry_safe() variant here ???
Oh, indeed. I will do so in the next version.
>
> > + f = fqdir->f;
> > + if (refcount_dec_and_test(>refcnt))
> > + complete(>completion);
> >
> > - kfree(fqdir);
> > + kfree(fqdir);
> > + }
Thanks,
SeongJae Park
Re: [PATCH] dt-bindings: leds: Document commonly used LED triggers
On Thu, Dec 10, 2020 at 02:57:09PM +0800, Leizhen (ThunderTown) wrote:
>
>
> On 2020/12/10 14:14, Manivannan Sadhasivam wrote:
> > This commit documents the LED triggers used commonly in the SoCs. Not
> > all triggers are documented as some of them are very application specific.
> > Most of the triggers documented here are currently used in devicetrees
> > of many SoCs.
> >
> > Signed-off-by: Manivannan Sadhasivam
> > ---
> > .../devicetree/bindings/leds/common.yaml | 72 ++-
> > 1 file changed, 54 insertions(+), 18 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/leds/common.yaml
> > b/Documentation/devicetree/bindings/leds/common.yaml
> > index f1211e7045f1..eee4eb7a4535 100644
> > --- a/Documentation/devicetree/bindings/leds/common.yaml
> > +++ b/Documentation/devicetree/bindings/leds/common.yaml
> > @@ -79,24 +79,60 @@ properties:
> >the LED.
> > $ref: /schemas/types.yaml#definitions/string
> >
> > -enum:
> > -# LED will act as a back-light, controlled by the framebuffer
> > system
> > - - backlight
> > -# LED will turn on (but for leds-gpio see "default-state" property
> > in
> > -# Documentation/devicetree/bindings/leds/leds-gpio.yaml)
> > - - default-on
> > -# LED "double" flashes at a load average based rate
> > - - heartbeat
> > -# LED indicates disk activity
> > - - disk-activity
> > -# LED indicates IDE disk activity (deprecated), in new
> > implementations
> > -# use "disk-activity"
> > - - ide-disk
> > -# LED flashes at a fixed, configurable rate
> > - - timer
> > -# LED alters the brightness for the specified duration with one
> > software
> > -# timer (requires "led-pattern" property)
> > - - pattern
> > +oneOf:
> > + - items:
> > + - enum:
> > +# LED will act as a back-light, controlled by the
> > framebuffer system
> > + - backlight
> > +# LED will turn on (but for leds-gpio see "default-state"
> > property in
> > +# Documentation/devicetree/bindings/leds/leds-gpio.yaml)
> > + - default-on
> > +# LED "double" flashes at a load average based rate
> > + - heartbeat
> > +# LED indicates disk activity
> > + - disk-activity
> > +# LED indicates IDE disk activity (deprecated), in new
> > implementations
> > +# use "disk-activity"
> > + - ide-disk
> > +# LED flashes at a fixed, configurable rate
> > + - timer
> > +# LED alters the brightness for the specified duration
> > with one software
> > +# timer (requires "led-pattern" property)
> > + - pattern
> > +# LED indicates camera flash state
> > + - flash
> > +# LED indicates camera torch state
> > + - torch
> > +# LED indicates audio mute state
> > + - audio-mute
> > +# LED indicates mic mute state
> > + - audio-micmute
> > +# LED indicates bluetooth power state
> > + - bluetooth-power
> > +# LED indicates USB gadget activity
> > + - usb-gadget
> > +# LED indicates USB host activity
> > + - usb-host
> > +# LED indicates MTD memory activity
> > + - mtd
> > +# LED indicates NAND memory activity (deprecated),
> > +# in new implementations use "mtd"
> > + - nand-disk
> > +# LED indicates disk read activity
> > + - disk-read
> > +# LED indicates disk write activity
> > + - disk-write
> > +# No trigger assigned to the LED. This is the default mode
> > +# if trigger is absent
> > + - none
> > +# LED indicates activity of all CPUs
> > + - cpu
> The triggers phy0tx and hci0-power are missed.
>
Yes, I just reworked my previous patch. Will add them.
> Since you've rewritten it, please consider sorting these property strings
> in ascending alphabetical order.
>
Makes sense!
> > + - items:
> > +# LED indicates activity of [N]th CPU
> > + - pattern: "^cpu[0-9][0-9]$"
> should be ^cpu[0-9]{1,2}$, otherwise, it always requires two digit.
>
Aww... Yes. Will fix it.
> > + - items:
> > +# LED indicates [N]th MMC storage activity
> > + - pattern: '^mmc[0-9][0-9]$'
> should be '^mmc[0-9]{1,2}$'
>
> Why CPU use "", and mmc use ''，It's better to keep them consistent.
>
Sure.
Thanks,
Mani
> >
> >led-pattern:
> > description: |
> >
>
[PATCH v16 0/4] userspace MHI client interface driver
This patch series adds support for UCI driver. UCI driver enables userspace clients to communicate to external MHI devices like modem. UCI driver probe creates standard character device file nodes for userspace clients to perform open, read, write, poll and release file operations. These file operations call MHI core layer APIs to perform data transfer using MHI bus to communicate with MHI device. Patch is tested using arm64 and x86 based platform. v16: - Removed reference of WLAN as an external MHI device in documentation and cover letter. v15: - Updated documentation related to poll and release operations. V14: - Fixed device file node format to /dev/ instead of /dev/mhi_ because "mhi" is already part of mhi device name. For example old format: /dev/mhi_mhi0_QMI new format: /dev/mhi0_QMI. - Updated MHI documentation to reflect index mhi controller name in QMI usage example. V13: - Removed LOOPBACK channel from mhi_device_id table from this patch series. Pushing a new patch series to add support for LOOPBACK channel and the user space test application. Also removed the description from kernel documentation. - Added QMI channel to mhi_device_id table. QMI channel has existing libqmi support from user space. - Updated kernel Documentation for QMI channel and provided external reference for libqmi. - Updated device file node name by appending mhi device name only, which already includes mhi controller device name. V12: - Added loopback test driver under selftest/drivers/mhi. Updated kernel documentation for the usage of the loopback test application. - Addressed review comments for renaming variable names, updated inline comments and removed two redundant dev_dbg. V11: - Fixed review comments for UCI documentation by expanding TLAs and rewording some sentences. V10: - Replaced mutex_lock with mutex_lock_interruptible in read() and write() file ops call back. V9: - Renamed dl_lock to dl_pending _lock and pending list to dl_pending for clarity. - Used read lock to protect cur_buf. - Change transfer status check logic and only consider 0 and -EOVERFLOW as only success. - Added __int to module init function. - Print channel name instead of minor number upon successful probe. V8: - Fixed kernel test robot compilation error by changing %lu to %zu for size_t. - Replaced uci with UCI in Kconfig, commit text, and comments in driver code. - Fixed minor style related comments. V7: - Decoupled uci device and uci channel objects. uci device is associated with device file node. uci channel is associated with MHI channels. uci device refers to uci channel to perform MHI channel operations for device file operations like read() and write(). uci device increments its reference count for every open(). uci device calls mhi_uci_dev_start_chan() to start the MHI channel. uci channel object is tracking number of times MHI channel is referred. This allows to keep the MHI channel in start state until last release() is called. After that uci channel reference count goes to 0 and uci channel clean up is performed which stops the MHI channel. After the last call to release() if driver is removed uci reference count becomes 0 and uci object is cleaned up. - Use separate uci channel read and write lock to fine grain locking between reader and writer. - Use uci device lock to synchronize open, release and driver remove. - Optimize for downlink only or uplink only UCI device. V6: - Moved uci.c to mhi directory. - Updated Kconfig to add module information. - Updated Makefile to rename uci object file name as mhi_uci - Removed kref for open count V5: - Removed mhi_uci_drv structure. - Used idr instead of creating global list of uci devices. - Used kref instead of local ref counting for uci device and open count. - Removed unlikely macro. V4: - Fix locking to protect proper struct members. - Updated documentation describing uci client driver use cases. - Fixed uci ref counting in mhi_uci_open for error case. - Addressed style related review comments. V3: Added documentation for MHI UCI driver. V2: - Added mutex lock to prevent multiple readers to access same - mhi buffer which can result into use after free. Hemant Kumar (4): bus: mhi: core: Add helper API to return number of free TREs bus: mhi: core: Move MHI_MAX_MTU to external header file docs: Add documentation for userspace client interface bus: mhi: Add userspace client interface driver Documentation/mhi/index.rst | 1 + Documentation/mhi/uci.rst | 95 ++ drivers/bus/mhi/Kconfig | 13 + drivers/bus/mhi/Makefile| 3 + drivers/bus/mhi/core/internal.h | 1 - drivers/bus/mhi/core/main.c | 12 + drivers/bus/mhi/uci.c | 664 include/linux/mhi.h | 12 + 8 files changed, 800 insertions(+), 1 deletion(-) create mode 100644 Documentation/mhi/uci.rst create mode 100644 drivers/bus/mhi/uci.c -- The
[PATCH v16 3/4] docs: Add documentation for userspace client interface
MHI userspace client driver is creating device file node for user application to perform file operations. File operations are handled by MHI core driver. Currently QMI MHI channel is supported by this driver. Signed-off-by: Hemant Kumar Reviewed-by: Jeffrey Hugo --- Documentation/mhi/index.rst | 1 + Documentation/mhi/uci.rst | 95 + 2 files changed, 96 insertions(+) create mode 100644 Documentation/mhi/uci.rst diff --git a/Documentation/mhi/index.rst b/Documentation/mhi/index.rst index 1d8dec3..c75a371 100644 --- a/Documentation/mhi/index.rst +++ b/Documentation/mhi/index.rst @@ -9,6 +9,7 @@ MHI mhi topology + uci .. only:: subproject and html diff --git a/Documentation/mhi/uci.rst b/Documentation/mhi/uci.rst new file mode 100644 index 000..1e0a015 --- /dev/null +++ b/Documentation/mhi/uci.rst @@ -0,0 +1,95 @@ +.. SPDX-License-Identifier: GPL-2.0 + += +Userspace Client Interface (UCI) += + +UCI driver enables userspace clients to communicate to external MHI devices +like modem. UCI driver probe creates standard character device file nodes for +userspace clients to perform open, read, write, poll and release file +operations. UCI device object represents UCI device file node which gets +instantiated as part of MHI UCI driver probe. UCI channel object represents +MHI uplink or downlink channel. + +Operations +== + +open + + +Instantiates UCI channel object and starts MHI channels to move it to running +state. Inbound buffers are queued to downlink channel transfer ring. Every +subsequent open() increments UCI device reference count as well as UCI channel +reference count. + +read + + +When data transfer is completed on downlink channel, transfer ring element +buffer is copied to pending list. Reader is unblocked and data is copied to +userspace buffer. Transfer ring element buffer is queued back to downlink +channel transfer ring. + +write +- + +Write buffer is queued to uplink channel transfer ring if ring is not full. Upon +uplink transfer completion buffer is freed. + +poll + + +Returns EPOLLIN | EPOLLRDNORM mask if pending list has buffers to be read by +userspace. Returns EPOLLOUT | EPOLLWRNORM mask if MHI uplink channel transfer +ring is not empty. When the uplink channel transfer ring is non-empty, more +data may be sent to the device. Returns EPOLLERR when UCI driver is removed. + +release +--- + +Decrements UCI device reference count and UCI channel reference count. Upon +last release() UCI channel clean up is performed. MHI channel moves to disable +state and inbound buffers are freed. + +Usage += + +Device file node is created with format:- + +/dev/ + +mhi_device_name includes mhi controller name and the name of the MHI channel +being used by MHI client in userspace to send or receive data using MHI +protocol. + +There is a separate character device file node created for each channel +specified in MHI device id table. MHI channels are statically defined by MHI +specification. The list of supported channels is in the channel list variable +of mhi_device_id table in UCI driver. + +Qualcomm MSM Interface(QMI) Channel +--- + +Qualcomm MSM Interface(QMI) is a modem control messaging protocol used to +communicate between software components in the modem and other peripheral +subsystems. QMI communication is of request/response type or an unsolicited +event type. libqmi is userspace MHI client which communicates to a QMI service +using UCI device. It sends a QMI request to a QMI service using MHI channel 14 +or 16. QMI response is received using MHI channel 15 or 17 respectively. libqmi +is a glib-based library for talking to WWAN modems and devices which speaks QMI +protocol. For more information about libqmi please refer +https://www.freedesktop.org/wiki/Software/libqmi/ + +Usage Example +~ + +QMI command to retrieve device mode +$ sudo qmicli -d /dev/mhi0_QMI --dms-get-model +[/dev/mhi0_QMI] Device model retrieved: +Model: 'FN980m' + +Other Use Cases +--- + +Getting MHI device specific diagnostics information to userspace MHI diagnostic +client using DIAG channel 4 (Host to device) and 5 (Device to Host). -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v16 4/4] bus: mhi: Add userspace client interface driver
This MHI client driver allows userspace clients to transfer
raw data between MHI device and host using standard file operations.
Driver instantiates UCI device object which is associated to device
file node. UCI device object instantiates UCI channel object when device
file node is opened. UCI channel object is used to manage MHI channels
by calling MHI core APIs for read and write operations. MHI channels
are started as part of device open(). MHI channels remain in start
state until last release() is called on UCI device file node. Device
file node is created with format
/dev/
Currently it supports QMI channel.
Signed-off-by: Hemant Kumar
Reviewed-by: Manivannan Sadhasivam
Reviewed-by: Jeffrey Hugo
Tested-by: Loic Poulain
---
drivers/bus/mhi/Kconfig | 13 +
drivers/bus/mhi/Makefile | 3 +
drivers/bus/mhi/uci.c| 664 +++
3 files changed, 680 insertions(+)
create mode 100644 drivers/bus/mhi/uci.c
diff --git a/drivers/bus/mhi/Kconfig b/drivers/bus/mhi/Kconfig
index da5cd0c..5194e8e 100644
--- a/drivers/bus/mhi/Kconfig
+++ b/drivers/bus/mhi/Kconfig
@@ -29,3 +29,16 @@ config MHI_BUS_PCI_GENERIC
This driver provides MHI PCI controller driver for devices such as
Qualcomm SDX55 based PCIe modems.
+config MHI_UCI
+ tristate "MHI UCI"
+ depends on MHI_BUS
+ help
+ MHI based Userspace Client Interface (UCI) driver is used for
+ transferring raw data between host and device using standard file
+ operations from userspace. Open, read, write, poll and close
+ operations are supported by this driver. Please check
+ mhi_uci_match_table for all supported channels that are exposed to
+ userspace.
+
+ To compile this driver as a module, choose M here: the module will be
+ called mhi_uci.
diff --git a/drivers/bus/mhi/Makefile b/drivers/bus/mhi/Makefile
index 0a2d778..69f2111 100644
--- a/drivers/bus/mhi/Makefile
+++ b/drivers/bus/mhi/Makefile
@@ -4,3 +4,6 @@ obj-y += core/
obj-$(CONFIG_MHI_BUS_PCI_GENERIC) += mhi_pci_generic.o
mhi_pci_generic-y += pci_generic.o
+# MHI client
+mhi_uci-y := uci.o
+obj-$(CONFIG_MHI_UCI) += mhi_uci.o
diff --git a/drivers/bus/mhi/uci.c b/drivers/bus/mhi/uci.c
new file mode 100644
index 000..1df2377
--- /dev/null
+++ b/drivers/bus/mhi/uci.c
@@ -0,0 +1,664 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright (c) 2018-2020, The Linux Foundation. All rights reserved.*/
+
+#include
+#include
+#include
+#include
+#include
+
+#define MHI_UCI_DRIVER_NAME "mhi_uci"
+#define MHI_MAX_UCI_MINORS 128
+
+static DEFINE_IDR(uci_idr);
+static DEFINE_MUTEX(uci_drv_mutex);
+static struct class *uci_dev_class;
+static int uci_dev_major;
+
+/**
+ * struct uci_chan - MHI channel for a UCI device
+ * @udev: associated UCI device object
+ * @ul_wq: wait queue for writer
+ * @write_lock: mutex write lock for ul channel
+ * @dl_wq: wait queue for reader
+ * @read_lock: mutex read lock for dl channel
+ * @dl_pending_lock: spin lock for dl_pending list
+ * @dl_pending: list of dl buffers userspace is waiting to read
+ * @cur_buf: current buffer userspace is reading
+ * @dl_size: size of the current dl buffer userspace is reading
+ * @ref_count: uci_chan reference count
+ */
+struct uci_chan {
+ struct uci_dev *udev;
+ wait_queue_head_t ul_wq;
+
+ /* ul channel lock to synchronize multiple writes */
+ struct mutex write_lock;
+
+ wait_queue_head_t dl_wq;
+
+ /* dl channel lock to synchronize multiple reads */
+ struct mutex read_lock;
+
+ /*
+* protects pending list in bh context, channel release, read and
+* poll
+*/
+ spinlock_t dl_pending_lock;
+
+ struct list_head dl_pending;
+ struct uci_buf *cur_buf;
+ size_t dl_size;
+ struct kref ref_count;
+};
+
+/**
+ * struct uci_buf - UCI buffer
+ * @data: data buffer
+ * @len: length of data buffer
+ * @node: list node of the UCI buffer
+ */
+struct uci_buf {
+ void *data;
+ size_t len;
+ struct list_head node;
+};
+
+/**
+ * struct uci_dev - MHI UCI device
+ * @minor: UCI device node minor number
+ * @mhi_dev: associated mhi device object
+ * @uchan: UCI uplink and downlink channel object
+ * @mtu: max TRE buffer length
+ * @enabled: Flag to track the state of the UCI device
+ * @lock: mutex lock to manage uchan object
+ * @ref_count: uci_dev reference count
+ */
+struct uci_dev {
+ unsigned int minor;
+ struct mhi_device *mhi_dev;
+ struct uci_chan *uchan;
+ size_t mtu;
+ bool enabled;
+
+ /* synchronize open, release and driver remove */
+ struct mutex lock;
+ struct kref ref_count;
+};
+
+static void mhi_uci_dev_chan_release(struct kref *ref)
+{
+ struct uci_buf *buf_itr, *tmp;
+ struct uci_chan *uchan =
+ container_of(ref, struct uci_chan, ref_count);
+
+ if (uchan->udev->enabled)
+
[PATCH v16 1/4] bus: mhi: core: Add helper API to return number of free TREs
Introduce mhi_get_free_desc_count() API to return number
of TREs available to queue buffer. MHI clients can use this
API to know before hand if ring is full without calling queue
API.
Signed-off-by: Hemant Kumar
Reviewed-by: Jeffrey Hugo
Reviewed-by: Manivannan Sadhasivam
---
drivers/bus/mhi/core/main.c | 12
include/linux/mhi.h | 9 +
2 files changed, 21 insertions(+)
diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index 702c31b..74a25e7 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -260,6 +260,18 @@ int mhi_destroy_device(struct device *dev, void *data)
return 0;
}
+int mhi_get_free_desc_count(struct mhi_device *mhi_dev,
+ enum dma_data_direction dir)
+{
+ struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
+ struct mhi_chan *mhi_chan = (dir == DMA_TO_DEVICE) ?
+ mhi_dev->ul_chan : mhi_dev->dl_chan;
+ struct mhi_ring *tre_ring = _chan->tre_ring;
+
+ return get_nr_avail_ring_elements(mhi_cntrl, tre_ring);
+}
+EXPORT_SYMBOL_GPL(mhi_get_free_desc_count);
+
void mhi_notify(struct mhi_device *mhi_dev, enum mhi_callback cb_reason)
{
struct mhi_driver *mhi_drv;
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index aa9757e..e36d575 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -599,6 +599,15 @@ void mhi_set_mhi_state(struct mhi_controller *mhi_cntrl,
void mhi_notify(struct mhi_device *mhi_dev, enum mhi_callback cb_reason);
/**
+ * mhi_get_free_desc_count - Get transfer ring length
+ * Get # of TD available to queue buffers
+ * @mhi_dev: Device associated with the channels
+ * @dir: Direction of the channel
+ */
+int mhi_get_free_desc_count(struct mhi_device *mhi_dev,
+ enum dma_data_direction dir);
+
+/**
* mhi_prepare_for_power_up - Do pre-initialization before power up.
*This is optional, call this before power up if
*the controller does not want bus framework to
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v16 2/4] bus: mhi: core: Move MHI_MAX_MTU to external header file
Currently this macro is defined in internal MHI header as
a TRE length mask. Moving it to external header allows MHI
client drivers to set this upper bound for the transmit
buffer size.
Signed-off-by: Hemant Kumar
Reviewed-by: Jeffrey Hugo
Reviewed-by: Manivannan Sadhasivam
---
drivers/bus/mhi/core/internal.h | 1 -
include/linux/mhi.h | 3 +++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
index 6f80ec3..2b9c063 100644
--- a/drivers/bus/mhi/core/internal.h
+++ b/drivers/bus/mhi/core/internal.h
@@ -453,7 +453,6 @@ enum mhi_pm_state {
#define CMD_EL_PER_RING128
#define PRIMARY_CMD_RING 0
#define MHI_DEV_WAKE_DB127
-#define MHI_MAX_MTU0x
#define MHI_RANDOM_U32_NONZERO(bmsk) (prandom_u32_max(bmsk) + 1)
enum mhi_er_type {
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index e36d575..f072605 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -15,6 +15,9 @@
#include
#include
+/* MHI client drivers to set this upper bound for tx buffer */
+#define MHI_MAX_MTU 0x
+
#define MHI_MAX_OEM_PK_HASH_SEGMENTS 16
struct mhi_chan;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH v3 1/4] Input: adp5589-keys - add default platform data
Hi Alexandru, Lars-Peter, On Fri, Nov 27, 2020 at 01:14:17PM +0200, Alexandru Ardelean wrote: > From: Lars-Peter Clausen > > If no platform data is supplied use a dummy platform data that configures > the device in GPIO only mode. This change adds a adp5589_kpad_pdata_get() > helper that returns the default platform-data. This can be later extended > to load configuration from device-trees or ACPI. I was looking at this and I do not think it is a good idea, as later we will need to add negation if someone does nor want use GPIO mode. We should use the standard "gpio-controller" property from the beginning. Thanks. -- Dmitry
[PATCH] arm64: topology: Cleanup init_amu_fie() a bit
Every time I have stumbled upon this routine, I get confused with the
way 'have_policy' is used and I have to dig in to understand why is it
so.
Here is an attempt to make it easier to understand, and hopefully it is
an improvement. This is based on the logic that amu_fie_cpus will be
empty if cpufreq policy wasn't available for any CPU.
Signed-off-by: Viresh Kumar
---
Ionela, I think it would be even better to do this over this patch
- /*
-* If none of the CPUs have cpufreq support, we only enable
-* the use of the AMU feature for FIE if all CPUs support AMU.
-* Otherwise, enable_policy_freq_counters has already enabled
-* policy cpus.
-*/
- if (cpumask_empty(amu_fie_cpus) &&
- cpumask_equal(valid_cpus, cpu_present_mask))
+ /* Overwrite amu_fie_cpus if all CPUs support AMU */
+ if (cpumask_equal(valid_cpus, cpu_present_mask))
cpumask_copy(amu_fie_cpus, cpu_present_mask);
This will also take care of the case where the cpufreq policy isn't
there for a small group of CPUs, which do have AMUs enabled for them.
(This doesn't normally happen though).
---
arch/arm64/kernel/topology.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index f6faa697e83e..7f7d8de325b6 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -199,14 +199,14 @@ static int freq_inv_set_max_ratio(int cpu, u64 max_rate,
u64 ref_rate)
return 0;
}
-static inline bool
+static inline void
enable_policy_freq_counters(int cpu, cpumask_var_t valid_cpus)
{
struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
if (!policy) {
pr_debug("CPU%d: No cpufreq policy found.\n", cpu);
- return false;
+ return;
}
if (cpumask_subset(policy->related_cpus, valid_cpus))
@@ -214,8 +214,6 @@ enable_policy_freq_counters(int cpu, cpumask_var_t
valid_cpus)
amu_fie_cpus);
cpufreq_cpu_put(policy);
-
- return true;
}
static DEFINE_STATIC_KEY_FALSE(amu_fie_key);
@@ -225,7 +223,6 @@ static int __init init_amu_fie(void)
{
bool invariance_status = topology_scale_freq_invariant();
cpumask_var_t valid_cpus;
- bool have_policy = false;
int ret = 0;
int cpu;
@@ -245,17 +242,18 @@ static int __init init_amu_fie(void)
continue;
cpumask_set_cpu(cpu, valid_cpus);
- have_policy |= enable_policy_freq_counters(cpu, valid_cpus);
+ enable_policy_freq_counters(cpu, valid_cpus);
}
/*
-* If we are not restricted by cpufreq policies, we only enable
+* If none of the CPUs have cpufreq support, we only enable
* the use of the AMU feature for FIE if all CPUs support AMU.
* Otherwise, enable_policy_freq_counters has already enabled
* policy cpus.
*/
- if (!have_policy && cpumask_equal(valid_cpus, cpu_present_mask))
- cpumask_or(amu_fie_cpus, amu_fie_cpus, valid_cpus);
+ if (cpumask_empty(amu_fie_cpus) &&
+ cpumask_equal(valid_cpus, cpu_present_mask))
+ cpumask_copy(amu_fie_cpus, cpu_present_mask);
if (!cpumask_empty(amu_fie_cpus)) {
pr_info("CPUs[%*pbl]: counters will be used for FIE.",
--
2.25.0.rc1.19.g042ed3e048af
Re: KRETPROBES are broken since kernel 5.8
Hi,
On Thu, Dec 10, 2020 at 10:25:07AM +0900, Masami Hiramatsu wrote:
> Hi Adam,
>
> Thank you for reporting and debugging, actually we had investigated this
> issue in Aug. Please read this thread.
>
> https://lkml.kernel.org/r/8816bdbbc55c4d2397e0b02aad282...@trendmicro.com
>
Thanks for the link. I've read the entire history of proposed fix - very
informative :)
> We finally fixed this issue by commit e03b4a084ea6 ("kprobes: Remove NMI
> context check") and commit 645f224e7ba2 ("kprobes: Tell lockdep about
> kprobe nesting"). Yeah, it will be in the v5.10.
>
> Could you try to test whether these commits can solve the issue?
I've applied these commits on the top of kernel 5.9.7 and verified that it
works well. Non-optimized KRETPROBES are back to life.
However, there might be another issue which I wanted to brought / discuss -
problem with optimizer. Until kernel 5.9 KRETPROBE on e.g.
'ftrace_enable_sysctl' function was correctly optimized without any problems.
Since 5.9 it can't be optimized anynmore. I didn't see any changes in the
sources regarding the optimizer, neither function itself.
When I looked at the generated vmlinux binary, I can see that GCC generated
padding at the end of this function using INT3 opcode:
...
8130528b: 41 bd f0 ff ff ff mov$0xfff0,%r13d
81305291: e9 fe fe ff ff jmpq 81305194
81305296: cc int3
81305297: cc int3
81305298: cc int3
81305299: cc int3
8130529a: cc int3
8130529b: cc int3
8130529c: cc int3
8130529d: cc int3
8130529e: cc int3
8130529f: cc int3
Such padding didn't exist in this function in generated images for older
kernels. Nevertheless, such padding is not unusual and it's pretty common.
Optimizer logic fails here:
try_to_optimize_kprobe() -> alloc_aggr_kprobe() -> __prepare_optimized_kprobe()
-> arch_prepare_optimized_kprobe() -> can_optimize():
/* Decode instructions */
addr = paddr - offset;
while (addr < paddr - offset + size) { /* Decode until function end */
unsigned long recovered_insn;
if (search_exception_tables(addr))
/*
* Since some fixup code will jumps into this function,
* we can't optimize kprobe in this function.
*/
return 0;
recovered_insn = recover_probed_instruction(buf, addr);
if (!recovered_insn)
return 0;
kernel_insn_init(, (void *)recovered_insn, MAX_INSN_SIZE);
insn_get_length();
/* Another subsystem puts a breakpoint */
if (insn.opcode.bytes[0] == INT3_INSN_OPCODE)
return 0;
/* Recover address */
insn.kaddr = (void *)addr;
insn.next_byte = (void *)(addr + insn.length);
/* Check any instructions don't jump into target */
if (insn_is_indirect_jump() ||
insn_jump_into_range(, paddr + INT3_INSN_SIZE,
DISP32_SIZE))
return 0;
addr += insn.length;
}
One of the check tries to protect from the situation when another subsystem
puts a breakpoint there as well:
/* Another subsystem puts a breakpoint */
if (insn.opcode.bytes[0] == INT3_INSN_OPCODE)
return 0;
However, that's not the case here. INT3_INSN_OPCODE is placed at the end of
the function as padding (and protect from NOP-padding problems).
I wonder, if optimizer should take this special case into account? Is it worth
to still optimize such functions when they are padded with INT3?
> If it is OK, we should backport those to stable tree.
Agreed.
Thanks,
Adam
> Thank you,
>
> On Wed, 9 Dec 2020 22:50:01 +0100
> Adam Zabrocki wrote:
>
> > Hello,
> >
> > Starting from kernel 5.8 all non-optimized kretprobes don't work. Until 5.8,
> > when #DB exception was raised, entry to the NMI was not fully performed.
> > Among
> > others, the following logic was executed:
> > https://elixir.bootlin.com/linux/v5.7.19/source/arch/x86/kernel/traps.c#L589
> >
> > if (!user_mode(regs)) {
> > rcu_nmi_enter();
> > preempt_disable();
> > }
> >
> > In some older kernels function ist_enter() was called instead. Inside this
> > function we can see the following logic:
> > https://elixir.bootlin.com/linux/v5.7.19/source/arch/x86/kernel/traps.c#L91
> >
> > if (user_mode(regs)) {
> > RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
> > } else {
> > /*
> > * We might have interrupted pretty much anything. In
> > * fact, if we're a machine check, we can even interrupt
> > * NMI processing. We don't want
Re: [PATCH v4] PM: domains: create debugfs nodes when adding power domains
On Tue, 8 Dec 2020 at 20:20, Thierry Strudel wrote:
>
> debugfs nodes were created in genpd_debug_init alled in late_initcall
> preventing power domains registered though loadable modules to have
> a debugfs entry.
>
> Create/remove debugfs nodes when the power domain is added/removed
> to/from the internal gpd_list.
>
> Signed-off-by: Thierry Strudel
> Change-Id: I8a2e0616746afe2a6bbd9c24bc3a0eaa84725a75
Thierry, thanks for fixing this!
Reviewed-by: Ulf Hansson
Kind regards
Uffe
> ---
> v2: fix forward declaration and genpd_debugfs_dir being NULL - Ulf
> v3: remove extra trailing char added by mistake in v2 - kernel test robot
> v4: cleanup includes and regroup CONFIG_DEBUG_FS CPP blocks - Greg
> drivers/base/power/domain.c | 73 +++--
> 1 file changed, 45 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 2cb5e04cf86c..49c87607cba7 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
>
> #include "power.h"
>
> @@ -210,6 +211,18 @@ static void genpd_sd_counter_inc(struct
> generic_pm_domain *genpd)
> }
>
> #ifdef CONFIG_DEBUG_FS
> +static struct dentry *genpd_debugfs_dir;
> +
> +static void genpd_debug_add(struct generic_pm_domain *genpd);
> +
> +static void genpd_debug_remove(struct generic_pm_domain *genpd)
> +{
> + struct dentry *d;
> +
> + d = debugfs_lookup(genpd->name, genpd_debugfs_dir);
> + debugfs_remove(d);
> +}
> +
> static void genpd_update_accounting(struct generic_pm_domain *genpd)
> {
> ktime_t delta, now;
> @@ -234,6 +247,8 @@ static void genpd_update_accounting(struct
> generic_pm_domain *genpd)
> genpd->accounting_time = now;
> }
> #else
> +static inline void genpd_debug_add(struct generic_pm_domain *genpd) {}
> +static inline void genpd_debug_remove(struct generic_pm_domain *genpd) {}
> static inline void genpd_update_accounting(struct generic_pm_domain *genpd)
> {}
> #endif
>
> @@ -1827,6 +1842,7 @@ int pm_genpd_init(struct generic_pm_domain *genpd,
>
> mutex_lock(_list_lock);
> list_add(>gpd_list_node, _list);
> + genpd_debug_add(genpd);
> mutex_unlock(_list_lock);
>
> return 0;
> @@ -1860,6 +1876,7 @@ static int genpd_remove(struct generic_pm_domain *genpd)
> kfree(link);
> }
>
> + genpd_debug_remove(genpd);
> list_del(>gpd_list_node);
> genpd_unlock(genpd);
> cancel_work_sync(>power_off_work);
> @@ -2764,14 +2781,6 @@ core_initcall(genpd_bus_init);
> /***debugfs support***/
>
> #ifdef CONFIG_DEBUG_FS
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -static struct dentry *genpd_debugfs_dir;
> -
> /*
> * TODO: This function is a slightly modified version of rtpm_status_show
> * from sysfs.c, so generalize it.
> @@ -3047,9 +3056,34 @@ DEFINE_SHOW_ATTRIBUTE(total_idle_time);
> DEFINE_SHOW_ATTRIBUTE(devices);
> DEFINE_SHOW_ATTRIBUTE(perf_state);
>
> -static int __init genpd_debug_init(void)
> +static void genpd_debug_add(struct generic_pm_domain *genpd)
> {
> struct dentry *d;
> +
> + if (!genpd_debugfs_dir)
> + return;
> +
> + d = debugfs_create_dir(genpd->name, genpd_debugfs_dir);
> +
> + debugfs_create_file("current_state", 0444,
> + d, genpd, _fops);
> + debugfs_create_file("sub_domains", 0444,
> + d, genpd, _domains_fops);
> + debugfs_create_file("idle_states", 0444,
> + d, genpd, _states_fops);
> + debugfs_create_file("active_time", 0444,
> + d, genpd, _time_fops);
> + debugfs_create_file("total_idle_time", 0444,
> + d, genpd, _idle_time_fops);
> + debugfs_create_file("devices", 0444,
> + d, genpd, _fops);
> + if (genpd->set_performance_state)
> + debugfs_create_file("perf_state", 0444,
> + d, genpd, _state_fops);
> +}
> +
> +static int __init genpd_debug_init(void)
> +{
> struct generic_pm_domain *genpd;
>
> genpd_debugfs_dir = debugfs_create_dir("pm_genpd", NULL);
> @@ -3057,25 +3091,8 @@ static int __init genpd_debug_init(void)
> debugfs_create_file("pm_genpd_summary", S_IRUGO, genpd_debugfs_dir,
> NULL, _fops);
>
> - list_for_each_entry(genpd, _list, gpd_list_node) {
> - d = debugfs_create_dir(genpd->name, genpd_debugfs_dir);
> -
> - debugfs_create_file("current_state", 0444,
> - d, genpd, _fops);
> - debugfs_create_file("sub_domains", 0444,
> - d, genpd, _domains_fops);
> - debugfs_create_file("idle_states", 0444,
> -
Re: [PATCH] mt76: Fixed kernel test robot warning
Souptick Joarder writes: > Kernel test robot throws below warning -> > >drivers/net/wireless/mediatek/mt76/tx.c: In function > 'mt76_txq_schedule': >>> drivers/net/wireless/mediatek/mt76/tx.c:499:21: warning: variable 'q' >>> set but not used [-Wunused-but-set-variable] > 499 | struct mt76_queue *q; > | ^ > > This patch will silence this warning. > > Reported-by: kernel test robot > Signed-off-by: Souptick Joarder I would like to take this directly to wireless-drivers-next, ok? I'll also change the title to: mt76: remove unused variable q -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: Urgent: BUG: PPP ioctl Transport endpoint is not connected
And one other
From other mailing I see you send patch to Denys Fedoryshchenko this patch is :
diff --git a/drivers/net/ppp/ppp_generic.c
b/drivers/net/ppp/ppp_generic.c
index 255a5def56e9..2acf4b0eabd1 100644
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -3161,6 +3161,15 @@ ppp_connect_channel(struct channel *pch, int
unit)
goto outl;
ppp_lock(ppp);
+ spin_lock_bh(>downl);
+ if (!pch->chan) {
+ /* Don't connect unregistered channels */
+ ppp_unlock(ppp);
+ spin_unlock_bh(>downl);
+ ret = -ENOTCONN;
+ goto outl;
+ }
+ spin_unlock_bh(>downl);
if (pch->file.hdrlen > ppp->file.hdrlen)
ppp->file.hdrlen = pch->file.hdrlen;
hdrlen = pch->file.hdrlen + 2; /* for protocol bytes */
But in official stable kernel three In ppp_generic.c is this :
spin_lock_bh(>downl);
if (!pch->chan) {
/* Don't connect unregistered channels */
spin_unlock_bh(>downl);
ppp_unlock(ppp);
ret = -ENOTCONN;
goto outl; }
spin_unlock_bh(>downl);
It is normal to unlock ppp after spin_unlock ?
shouldn't it be as you wrote it?
In your patch first :
+ ppp_unlock(ppp);
+ spin_unlock_bh(>downl);
But in stable kernel is :
spin_unlock_bh(>downl);
ppp_unlock(ppp);
> On 9 Dec 2020, at 20:10, Guillaume Nault wrote:
>
> On Wed, Dec 09, 2020 at 06:57:44PM +0200, Martin Zaharinov wrote:
>>> On 9 Dec 2020, at 18:40, Guillaume Nault wrote:
>>> On Wed, Dec 09, 2020 at 04:47:52PM +0200, Martin Zaharinov wrote:
Hi All
I have problem with latest kernel release
And the problem is base on this late problem :
https://www.mail-archive.com/search?l=net...@vger.kernel.org=subject:%22Re%5C%3A+ppp%5C%2Fpppoe%2C+still+panic+4.15.3+in+ppp_push%22=newest=1
I have same problem in kernel 5.6 > now I use kernel 5.9.13 and have same
problem.
In kernel 5.9.13 now don’t have any crashes in dimes but in one moment
accel service stop with defunct and in log have many of this line :
error: vlan608: ioctl(PPPIOCCONNECT): Transport endpoint is not connected
error: vlan617: ioctl(PPPIOCCONNECT): Transport endpoint is not connected
error: vlan679: ioctl(PPPIOCCONNECT): Transport endpoint is not connected
In one moment connected user bump double or triple and after that service
defunct and need wait to drop all session to start .
I talk with accel-ppp team and they said this is kernel related problem
and to back to kernel 4.14 there is not this problem.
Problem is come after kernel 4.15 > and not have solution to this moment.
>>>
>>> I'm sorry, I don't understand.
>>> Do you mean that v4.14 worked fine (no crash, no ioctl() error)?
>>> Did the problem start appearing in v4.15? Or did v4.15 work and the
>>> problem appeared in v4.16?
>>
>> In Telegram group I talk with Sergey and Dimka and told my the problem is
>> come after changes from 4.14 to 4.15
>> Sergey write this : "as I know, there was a similar issue in kernel 4.15 so
>> maybe it is still not fixed"
>
> Ok, but what is your experience? Do you have a kernel version where
> accel-ppp reports no ioctl() error and doesn't crash the kernel?
>
> There wasn't a lot of changes between 4.14 and 4.15 for PPP.
> The only PPP patch I can see that might have been risky is commit
> 0171c4183559 ("ppp: unlock all_ppp_mutex before registering device").
>
>> I don’t have options to test with this old kernel 4.14.xxx i don’t have
>> support for them.
>>
>>
>>>
Please help to find the problem.
Last time in link I see is make changes in ppp_generic.c
ppp_lock(ppp);
spin_lock_bh(>downl);
if (!pch->chan) {
/* Don't connect unregistered channels */
spin_unlock_bh(>downl);
ppp_unlock(ppp);
ret = -ENOTCONN;
goto outl;
}
spin_unlock_bh(>downl);
But this fix only to don’t display error and freeze system
The problem is stay and is to big.
>>>
>>> Do you use accel-ppp's unit-cache option? Does the problem go away if
>>> you stop using it?
>>>
>>
>> No I don’t use unit-cache , if I set unit-cache accel-ppp defunct same but
>> user Is connect and disconnet more fast.
>>
>> The problem is same with unit and without .
>> Only after this patch I don’t see error in dimes but this is not solution.
>
> Soryy, what's "in dimes"?
> Do you mean that reverting commit 77f840e3e5f0 ("ppp: prevent
> unregistered channels from connecting to PPP units") fixes your problem?
>
>> In network have customer what have power cut problem, when drop 600 user and
>> back Is normal but in this moment kernel is locking and start to make this :
>> sessions:
>> starting: 4235
>> active: 3882
>> finishing: 378
>> The problem is starting session is not real user normal
[PATCH] gpiolib: irq hooks: fix recursion in gpiochip_irq_unmask
irqchip shared with multiple gpiochips, leads to recursive call of
gpiochip_irq_mask/gpiochip_irq_unmask which was assigned to
rqchip->irq_mask/irqchip->irq_unmask, these happens becouse of
only irqchip->irq_enable == gpiochip_irq_enable is checked.
Let's add an additional check to make sure shared irqchip is detected
even if irqchip->irq_enable wasn't defined.
Fixes: a8173820f441 ("gpio: gpiolib: Allow GPIO IRQs to lazy disable")
Signed-off-by: Nikita Shubin
---
drivers/gpio/gpiolib.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 589eceecf374..5ce0c14c637b 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1419,7 +1419,8 @@ static void gpiochip_set_irq_hooks(struct gpio_chip *gc)
if (WARN_ON(gc->irq.irq_enable))
return;
/* Check if the irqchip already has this hook... */
- if (irqchip->irq_enable == gpiochip_irq_enable) {
+ if (irqchip->irq_enable == gpiochip_irq_enable ||
+ irqchip->irq_mask == gpiochip_irq_mask) {
/*
* ...and if so, give a gentle warning that this is bad
* practice.
--
2.26.2
Re: [PATCH V2 3/3] perf: Optimize sched_task() in a context switch
Hi Peter and Kan,
How can we move this forward?
Thanks,
Namhyung
On Fri, Dec 4, 2020 at 4:14 PM Namhyung Kim wrote:
>
> Hi Peter,
>
> On Wed, Dec 2, 2020 at 2:29 AM Peter Zijlstra wrote:
> >
> > On Mon, Nov 30, 2020 at 11:38:42AM -0800, kan.li...@linux.intel.com wrote:
> > > From: Kan Liang
> > >
> > > Some calls to sched_task() in a context switch can be avoided. For
> > > example, large PEBS only requires flushing the buffer in context switch
> > > out. The current code still invokes the sched_task() for large PEBS in
> > > context switch in.
> >
> > I still hate this one, how's something like this then?
> > Which I still don't really like.. but at least its simpler.
> >
> > (completely untested, may contain spurious edits, might ICE the
> > compiler and set your pets on fire if it doesn't)
>
> I've tested this version... and it worked well besides the optimization.. :)
>
> [SNIP]
> > +static void context_sched_task(struct perf_cpu_context *cpuctx,
> > + struct perf_event_context *ctx,
> > + bool sched_in)
> > +{
> > + struct pmu *pmu = ctx->pmu;
> > +
> > + if (cpuctx->sched_cb_dir[sched_in] && pmu->sched_task)
> > + pmu->sched_task(ctx, false);
>
> applied: s/false/sched_in/
>
>
> > +}
> > +
> > static void perf_event_context_sched_out(struct task_struct *task, int
> > ctxn,
> > struct task_struct *next)
> > {
> > @@ -3424,9 +3433,7 @@ static void perf_event_context_sched_out
> > WRITE_ONCE(next_ctx->task, task);
> >
> > perf_pmu_disable(pmu);
> > -
> > - if (cpuctx->sched_cb_usage && pmu->sched_task)
> > - pmu->sched_task(ctx, false);
> > + context_sched_task(cpuctx, ctx, false);
> >
> > /*
> > * PMU specific parts of task perf context can
> > require
> > @@ -3465,8 +3472,7 @@ static void perf_event_context_sched_out
> > raw_spin_lock(>lock);
> > perf_pmu_disable(pmu);
> >
> > - if (cpuctx->sched_cb_usage && pmu->sched_task)
> > - pmu->sched_task(ctx, false);
> > + context_sched_task(cpuctx, ctx, false);
> > task_ctx_sched_out(cpuctx, ctx, EVENT_ALL);
> >
> > perf_pmu_enable(pmu);
>
> [SNIP]
> > @@ -3563,8 +3582,7 @@ void __perf_event_task_sched_out(struct
> > {
> > int ctxn;
> >
> > - if (__this_cpu_read(perf_sched_cb_usage))
> > - perf_pmu_sched_task(task, next, false);
> > + perf_pmu_sched_task(task, next, false);
>
> I think the reason is this change. It now calls perf_pmu_sched_task()
> without checking the counter. And this is for per-cpu events.
>
> >
> > if (atomic_read(_switch_events))
> > perf_event_switch(task, next, false);
> > @@ -3828,8 +3846,7 @@ static void perf_event_context_sched_in(
> > cpu_ctx_sched_out(cpuctx, EVENT_FLEXIBLE);
> > perf_event_sched_in(cpuctx, ctx, task);
> >
> > - if (cpuctx->sched_cb_usage && pmu->sched_task)
> > - pmu->sched_task(cpuctx->task_ctx, true);
> > + context_sched_task(cpuctx, ctx, true);
> >
> > perf_pmu_enable(pmu);
> >
> > @@ -3875,8 +3892,7 @@ void __perf_event_task_sched_in(struct t
> > if (atomic_read(_switch_events))
> > perf_event_switch(task, prev, true);
> >
> > - if (__this_cpu_read(perf_sched_cb_usage))
> > - perf_pmu_sched_task(prev, task, true);
> > + perf_pmu_sched_task(prev, task, true);
>
> Ditto.
>
> > }
> >
> > static u64 perf_calculate_period(struct perf_event *event, u64 nsec, u64
> > count)
>
> So I made a change like below.. and it could bring the optimization back.
>
> Thanks,
> Namhyung
>
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 9107e7c3ccfb..a30243a9fab5 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -3528,6 +3528,9 @@ static void __perf_pmu_sched_task(struct
> perf_cpu_context *cpuctx, bool sched_in
> {
> struct pmu *pmu;
>
> + if (!cpuctx->sched_cb_dir[sched_in])
> + return;
> +
> pmu = cpuctx->ctx.pmu; /* software PMUs will not have sched_task */
>
> if (WARN_ON_ONCE(!pmu->sched_task))
[tip:x86/cache] BUILD SUCCESS WITH WARNING 2ba836dbe2467d31fffb439258c2f454c6f1a317
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/cache branch HEAD: 2ba836dbe2467d31fffb439258c2f454c6f1a317 x86/resctrl: Fix incorrect local bandwidth when mba_sc is enabled Warning reports: https://lore.kernel.org/lkml/202012100516.h7stnehl-...@intel.com Warning in current branch: arch/x86/kernel/cpu/resctrl/monitor.c:291:6: warning: variable 'chunks' set but not used [-Wunused-but-set-variable] Warning ids grouped by kconfigs: gcc_recent_errors |-- i386-allyesconfig | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used |-- i386-randconfig-a001-20201209 | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used |-- i386-randconfig-a002-20201209 | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used |-- i386-randconfig-a002-20201210 | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used |-- i386-randconfig-a004-20201210 | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used |-- i386-randconfig-a006-20201210 | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used |-- i386-randconfig-a012-20201209 | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used |-- i386-randconfig-a014-20201209 | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used |-- i386-randconfig-a016-20201209 | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used |-- i386-randconfig-c001-20201209 | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used |-- i386-randconfig-c001-20201210 | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used |-- i386-randconfig-s001-20201209 | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used |-- i386-randconfig-s002-20201209 | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used |-- x86_64-allmodconfig | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used |-- x86_64-allyesconfig | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used |-- x86_64-randconfig-a011-20201209 | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used |-- x86_64-randconfig-a013-20201209 | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used |-- x86_64-randconfig-a014-20201209 | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used |-- x86_64-randconfig-p002-20201209 | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used |-- x86_64-randconfig-r023-20201209 | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used |-- x86_64-randconfig-r024-20201209 | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used |-- x86_64-randconfig-s021-20201209 | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used |-- x86_64-randconfig-s022-20201209 | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used |-- x86_64-randconfig-s022-20201210 | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used |-- x86_64-rhel | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used |-- x86_64-rhel-7.6-kselftests | `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used `-- x86_64-rhel-8.3 `-- arch-x86-kernel-cpu-resctrl-monitor.c:warning:variable-chunks-set-but-not-used i386-tinyconfig vmlinux size: +---+--+--+ | DELTA |SYMBOL| COMMIT | +---+--+--+ | +1718 | TOTAL| 3650b228f83a..2ba836dbe246 (ALL COMMITS) | | +1647 | TEXT | 3650b228f83a..2ba836dbe246 (ALL COMMITS) | | +68 | BSS | 3650b228f83a..2ba836dbe246 (ALL COMMITS) | | +774 | seq_read_iter() | 3650b228f83a..2ba836dbe246 (ALL COMMITS) | | +250 | __invalidate_mapping_pages() | 3650b228f83a..2ba836dbe246 (ALL COMMITS) | | +225 | intel_pmu_drain_pebs_icl() | 3650b228f83a..2ba836dbe246 (ALL COMMITS) | | +218 | intel_pmu_drain_pebs_nhm() | 3650b228f83a..2ba836dbe246 (ALL COMMITS) | | +201 | intel_pmu_drain_pebs_core() | 3650b228f83a..2ba836dbe246 (ALL COMMITS) | | +117 | init.text| 3650b228f83a..2ba836dbe246 (ALL COMMITS) | | +68 | dummy_iregs | 3650b228f83a..2ba836dbe246 (ALL COMMITS) | | +66 | perf_event_aux_event() | 3650b228f83a..2ba836dbe246 (ALL COMMITS) | | +66 | perf_log_throttle
Re: Urgent: BUG: PPP ioctl Transport endpoint is not connected
> On 9 Dec 2020, at 20:10, Guillaume Nault wrote:
>
> On Wed, Dec 09, 2020 at 06:57:44PM +0200, Martin Zaharinov wrote:
>>> On 9 Dec 2020, at 18:40, Guillaume Nault wrote:
>>> On Wed, Dec 09, 2020 at 04:47:52PM +0200, Martin Zaharinov wrote:
Hi All
I have problem with latest kernel release
And the problem is base on this late problem :
https://www.mail-archive.com/search?l=net...@vger.kernel.org=subject:%22Re%5C%3A+ppp%5C%2Fpppoe%2C+still+panic+4.15.3+in+ppp_push%22=newest=1
I have same problem in kernel 5.6 > now I use kernel 5.9.13 and have same
problem.
In kernel 5.9.13 now don’t have any crashes in dimes but in one moment
accel service stop with defunct and in log have many of this line :
error: vlan608: ioctl(PPPIOCCONNECT): Transport endpoint is not connected
error: vlan617: ioctl(PPPIOCCONNECT): Transport endpoint is not connected
error: vlan679: ioctl(PPPIOCCONNECT): Transport endpoint is not connected
In one moment connected user bump double or triple and after that service
defunct and need wait to drop all session to start .
I talk with accel-ppp team and they said this is kernel related problem
and to back to kernel 4.14 there is not this problem.
Problem is come after kernel 4.15 > and not have solution to this moment.
>>>
>>> I'm sorry, I don't understand.
>>> Do you mean that v4.14 worked fine (no crash, no ioctl() error)?
>>> Did the problem start appearing in v4.15? Or did v4.15 work and the
>>> problem appeared in v4.16?
>>
>> In Telegram group I talk with Sergey and Dimka and told my the problem is
>> come after changes from 4.14 to 4.15
>> Sergey write this : "as I know, there was a similar issue in kernel 4.15 so
>> maybe it is still not fixed"
>
> Ok, but what is your experience? Do you have a kernel version where
> accel-ppp reports no ioctl() error and doesn't crash the kernel?
>
> There wasn't a lot of changes between 4.14 and 4.15 for PPP.
> The only PPP patch I can see that might have been risky is commit
> 0171c4183559 ("ppp: unlock all_ppp_mutex before registering device").
May be or is other bug in ppp but how to debug or find fix…
>
>> I don’t have options to test with this old kernel 4.14.xxx i don’t have
>> support for them.
>>
>>
>>>
Please help to find the problem.
Last time in link I see is make changes in ppp_generic.c
ppp_lock(ppp);
spin_lock_bh(>downl);
if (!pch->chan) {
/* Don't connect unregistered channels */
spin_unlock_bh(>downl);
ppp_unlock(ppp);
ret = -ENOTCONN;
goto outl;
}
spin_unlock_bh(>downl);
But this fix only to don’t display error and freeze system
The problem is stay and is to big.
>>>
>>> Do you use accel-ppp's unit-cache option? Does the problem go away if
>>> you stop using it?
>>>
>>
>> No I don’t use unit-cache , if I set unit-cache accel-ppp defunct same but
>> user Is connect and disconnet more fast.
>>
>> The problem is same with unit and without .
>> Only after this patch I don’t see error in dimes but this is not solution.
>
> Soryy, what's "in dimes"?
> Do you mean that reverting commit 77f840e3e5f0 ("ppp: prevent
> unregistered channels from connecting to PPP units") fixes your problem?
May be no if revert system will display crash report and go to freeze .
>
>> In network have customer what have power cut problem, when drop 600 user and
>> back Is normal but in this moment kernel is locking and start to make this :
>> sessions:
>> starting: 4235
>> active: 3882
>> finishing: 378
>> The problem is starting session is not real user normal user in this server
>> is ~4k customers .
>
> What type of session is it? L2TP, PPPoE, PPTP?
>
>> I use pppd_compat .
>>
>> Any idea ?
>>
Please help to fix.
>> Martin
Re: [PATCH 3/3] s390/mm: Define arch_get_mappable_range()
> Am 10.12.2020 um 07:58 schrieb Heiko Carstens :
>
> On Thu, Dec 10, 2020 at 09:48:11AM +0530, Anshuman Khandual wrote:
Alternatively leaving __segment_load() and vmem_add_memory() unchanged
will create three range checks i.e two memhp_range_allowed() and the
existing VMEM_MAX_PHYS check in vmem_add_mapping() on all the hotplug
paths, which is not optimal.
>>>
>>> Ah, sorry. I didn't follow this discussion too closely. I just thought
>>> my point of view would be clear: let's not have two different ways to
>>> check for the same thing which must be kept in sync.
>>> Therefore I was wondering why this next version is still doing
>>> that. Please find a way to solve this.
>>
>> The following change is after the current series and should work with
>> and without memory hotplug enabled. There will be just a single place
>> i.e vmem_get_max_addr() to update in case the maximum address changes
>> from VMEM_MAX_PHYS to something else later.
>
> Still not. That's way too much code churn for what you want to achieve.
> If the s390 specific patch would look like below you can add
>
> Acked-by: Heiko Carstens
>
> But please make sure that the arch_get_mappable_range() prototype in
> linux/memory_hotplug.h is always visible and does not depend on
> CONFIG_MEMORY_HOTPLUG. I'd like to avoid seeing sparse warnings
> because of this.
>
> Thanks.
>
> diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
> index 77767850d0d0..e0e78234ae57 100644
> --- a/arch/s390/mm/init.c
> +++ b/arch/s390/mm/init.c
> @@ -291,6 +291,7 @@ int arch_add_memory(int nid, u64 start, u64 size,
>if (WARN_ON_ONCE(params->pgprot.pgprot != PAGE_KERNEL.pgprot))
>return -EINVAL;
>
> +VM_BUG_ON(!memhp_range_allowed(start, size, 1));
>rc = vmem_add_mapping(start, size);
>if (rc)
>return rc;
> diff --git a/arch/s390/mm/vmem.c b/arch/s390/mm/vmem.c
> index b239f2ba93b0..ccd55e2f97f9 100644
> --- a/arch/s390/mm/vmem.c
> +++ b/arch/s390/mm/vmem.c
> @@ -4,6 +4,7 @@
> *Author(s): Heiko Carstens
> */
>
> +#include
> #include
> #include
> #include
> @@ -532,11 +533,23 @@ void vmem_remove_mapping(unsigned long start, unsigned
> long size)
>mutex_unlock(_mutex);
> }
>
> +struct range arch_get_mappable_range(void)
> +{
> +struct range range;
> +
> +range.start = 0;
> +range.end = VMEM_MAX_PHYS;
> +return range;
> +}
> +
> int vmem_add_mapping(unsigned long start, unsigned long size)
> {
> +struct range range;
>int ret;
>
> -if (start + size > VMEM_MAX_PHYS ||
> +range = arch_get_mappable_range();
> +if (start < range.start ||
> +start + size > range.end ||
>start + size < start)
>return -ERANGE;
>
>
Right, what I had in mind as reply to v1. Not sure if we really need new checks
in common code. Having a new memhp_get_pluggable_range() would be sufficient
for my use case (virtio-mem).
tnc.c:undefined reference to `ubifs_bad_hash'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: a2f5ea9e314ba6778f885c805c921e9362ec0420 commit: 0da310e82d3a9bff6ef6b0f2fbf45d1a05cc64fe riscv: gcov: enable gcov for RISC-V date: 11 months ago config: riscv-randconfig-r003-20201209 (attached as .config) compiler: riscv32-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0da310e82d3a9bff6ef6b0f2fbf45d1a05cc64fe git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 0da310e82d3a9bff6ef6b0f2fbf45d1a05cc64fe # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=riscv If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): riscv32-linux-ld: fs/ubifs/tnc.o: in function `.L345': >> tnc.c:(.text+0x4c9c): undefined reference to `ubifs_bad_hash' riscv32-linux-ld: fs/ubifs/tnc.o: in function `.L362': tnc.c:(.text+0x544a): undefined reference to `ubifs_bad_hash' riscv32-linux-ld: fs/ubifs/tnc_misc.o: in function `.L36': >> tnc_misc.c:(.text+0x778): undefined reference to `ubifs_bad_hash' riscv32-linux-ld: fs/ubifs/tnc_misc.o: in function `.L187': tnc_misc.c:(.text+0x2cce): undefined reference to `ubifs_bad_hash' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH 3/3] arm64: dts: mt8183: Add display nodes for MT8183
Hi, Enric:
On Fri, 2020-11-27 at 11:49 +0100, Enric Balletbo i Serra wrote:
> Add display subsystem device nodes to allow video output.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 114 +++
> 1 file changed, 114 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index ba9ff192cda3..34d83f517b07 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -6,6 +6,7 @@
> */
>
> #include
> +#include
This should be
#include
Regards,
CK
> #include
> #include
> #include
> @@ -33,6 +34,11 @@ aliases {
> i2c9 =
> i2c10 =
> i2c11 =
> + ovl0 =
> + ovl-2l0 = _2l0;
> + ovl-2l1 = _2l1;
> + rdma0 =
> + rdma1 =
> };
>
> cpus {
> @@ -964,6 +970,107 @@ mmsys: syscon@1400 {
> #clock-cells = <1>;
> };
>
> + ovl0: ovl@14008000 {
> + compatible = "mediatek,mt8183-disp-ovl";
> + reg = <0 0x14008000 0 0x1000>;
> + interrupts = ;
> + power-domains = < MT8183_POWER_DOMAIN_DISP>;
> + clocks = < CLK_MM_DISP_OVL0>;
> + iommus = < M4U_PORT_DISP_OVL0>;
> + mediatek,larb = <>;
> + mediatek,gce-client-reg = < SUBSYS_1400 0x8000
> 0x1000>;
> + };
> +
> + ovl_2l0: ovl@14009000 {
> + compatible = "mediatek,mt8183-disp-ovl-2l";
> + reg = <0 0x14009000 0 0x1000>;
> + interrupts = ;
> + power-domains = < MT8183_POWER_DOMAIN_DISP>;
> + clocks = < CLK_MM_DISP_OVL0_2L>;
> + iommus = < M4U_PORT_DISP_2L_OVL0_LARB0>;
> + mediatek,larb = <>;
> + mediatek,gce-client-reg = < SUBSYS_1400 0x9000
> 0x1000>;
> + };
> +
> + ovl_2l1: ovl@1400a000 {
> + compatible = "mediatek,mt8183-disp-ovl-2l";
> + reg = <0 0x1400a000 0 0x1000>;
> + interrupts = ;
> + power-domains = < MT8183_POWER_DOMAIN_DISP>;
> + clocks = < CLK_MM_DISP_OVL1_2L>;
> + iommus = < M4U_PORT_DISP_2L_OVL1_LARB0>;
> + mediatek,larb = <>;
> + mediatek,gce-client-reg = < SUBSYS_1400 0xa000
> 0x1000>;
> + };
> +
> + rdma0: rdma@1400b000 {
> + compatible = "mediatek,mt8183-disp-rdma";
> + reg = <0 0x1400b000 0 0x1000>;
> + interrupts = ;
> + power-domains = < MT8183_POWER_DOMAIN_DISP>;
> + clocks = < CLK_MM_DISP_RDMA0>;
> + iommus = < M4U_PORT_DISP_RDMA0>;
> + mediatek,larb = <>;
> + mediatek,rdma_fifo_size = <5120>;
> + mediatek,gce-client-reg = < SUBSYS_1400 0xb000
> 0x1000>;
> + };
> +
> + rdma1: rdma@1400c000 {
> + compatible = "mediatek,mt8183-disp-rdma";
> + reg = <0 0x1400c000 0 0x1000>;
> + interrupts = ;
> + power-domains = < MT8183_POWER_DOMAIN_DISP>;
> + clocks = < CLK_MM_DISP_RDMA1>;
> + iommus = < M4U_PORT_DISP_RDMA1>;
> + mediatek,larb = <>;
> + mediatek,rdma_fifo_size = <2048>;
> + mediatek,gce-client-reg = < SUBSYS_1400 0xc000
> 0x1000>;
> + };
> +
> + color0: color@1400e000 {
> + compatible = "mediatek,mt8183-disp-color",
> + "mediatek,mt8173-disp-color";
> + reg = <0 0x1400e000 0 0x1000>;
> + interrupts = ;
> + power-domains = < MT8183_POWER_DOMAIN_DISP>;
> + clocks = < CLK_MM_DISP_COLOR0>;
> + mediatek,gce-client-reg = < SUBSYS_1400 0xe000
> 0x1000>;
> + };
> +
> + ccorr0: ccorr@1400f000 {
> + compatible = "mediatek,mt8183-disp-ccorr";
> + reg = <0 0x1400f000 0 0x1000>;
> + interrupts = ;
> + power-domains = < MT8183_POWER_DOMAIN_DISP>;
> + clocks = < CLK_MM_DISP_CCORR0>;
> + };
> +
> + aal0: aal@1401 {
> + compatible = "mediatek,mt8183-disp-aal",
> + "mediatek,mt8173-disp-aal";
> + reg = <0 0x1401 0 0x1000>;
> + interrupts = ;
> +
Re: [PATCH 3/3] s390/mm: Define arch_get_mappable_range()
On Thu, Dec 10, 2020 at 09:48:11AM +0530, Anshuman Khandual wrote:
> >> Alternatively leaving __segment_load() and vmem_add_memory() unchanged
> >> will create three range checks i.e two memhp_range_allowed() and the
> >> existing VMEM_MAX_PHYS check in vmem_add_mapping() on all the hotplug
> >> paths, which is not optimal.
> >
> > Ah, sorry. I didn't follow this discussion too closely. I just thought
> > my point of view would be clear: let's not have two different ways to
> > check for the same thing which must be kept in sync.
> > Therefore I was wondering why this next version is still doing
> > that. Please find a way to solve this.
>
> The following change is after the current series and should work with
> and without memory hotplug enabled. There will be just a single place
> i.e vmem_get_max_addr() to update in case the maximum address changes
> from VMEM_MAX_PHYS to something else later.
Still not. That's way too much code churn for what you want to achieve.
If the s390 specific patch would look like below you can add
Acked-by: Heiko Carstens
But please make sure that the arch_get_mappable_range() prototype in
linux/memory_hotplug.h is always visible and does not depend on
CONFIG_MEMORY_HOTPLUG. I'd like to avoid seeing sparse warnings
because of this.
Thanks.
diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
index 77767850d0d0..e0e78234ae57 100644
--- a/arch/s390/mm/init.c
+++ b/arch/s390/mm/init.c
@@ -291,6 +291,7 @@ int arch_add_memory(int nid, u64 start, u64 size,
if (WARN_ON_ONCE(params->pgprot.pgprot != PAGE_KERNEL.pgprot))
return -EINVAL;
+ VM_BUG_ON(!memhp_range_allowed(start, size, 1));
rc = vmem_add_mapping(start, size);
if (rc)
return rc;
diff --git a/arch/s390/mm/vmem.c b/arch/s390/mm/vmem.c
index b239f2ba93b0..ccd55e2f97f9 100644
--- a/arch/s390/mm/vmem.c
+++ b/arch/s390/mm/vmem.c
@@ -4,6 +4,7 @@
*Author(s): Heiko Carstens
*/
+#include
#include
#include
#include
@@ -532,11 +533,23 @@ void vmem_remove_mapping(unsigned long start, unsigned
long size)
mutex_unlock(_mutex);
}
+struct range arch_get_mappable_range(void)
+{
+ struct range range;
+
+ range.start = 0;
+ range.end = VMEM_MAX_PHYS;
+ return range;
+}
+
int vmem_add_mapping(unsigned long start, unsigned long size)
{
+ struct range range;
int ret;
- if (start + size > VMEM_MAX_PHYS ||
+ range = arch_get_mappable_range();
+ if (start < range.start ||
+ start + size > range.end ||
start + size < start)
return -ERANGE;
Re: memory leak in bpf
syzbot has found a reproducer for the following issue on: HEAD commit:a68a0262 mm/madvise: remove racy mm ownership check git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=11facf1750 kernel config: https://syzkaller.appspot.com/x/.config?x=4305fa9ea70c7a9f dashboard link: https://syzkaller.appspot.com/bug?extid=f3694595248708227d35 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=159a961350 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11bf712350 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+f3694595248708227...@syzkaller.appspotmail.com Debian GNU/Linux 9 syzkaller ttyS0 Warning: Permanently added '10.128.0.9' (ECDSA) to the list of known hosts. executing program executing program executing program BUG: memory leak unreferenced object 0x88810efccc80 (size 64): comm "syz-executor334", pid 8460, jiffies 4294945724 (age 13.850s) hex dump (first 32 bytes): c0 cb 14 04 00 ea ff ff c0 c2 11 04 00 ea ff ff c0 56 3f 04 00 ea ff ff 40 18 38 04 00 ea ff ff .V?.@.8. backtrace: [<36ae98a7>] kmalloc_node include/linux/slab.h:575 [inline] [<36ae98a7>] bpf_ringbuf_area_alloc kernel/bpf/ringbuf.c:94 [inline] [<36ae98a7>] bpf_ringbuf_alloc kernel/bpf/ringbuf.c:135 [inline] [<36ae98a7>] ringbuf_map_alloc kernel/bpf/ringbuf.c:183 [inline] [<36ae98a7>] ringbuf_map_alloc+0x1be/0x410 kernel/bpf/ringbuf.c:150 [] find_and_alloc_map kernel/bpf/syscall.c:122 [inline] [ ] map_create kernel/bpf/syscall.c:825 [inline] [ ] __do_sys_bpf+0x7d0/0x30a0 kernel/bpf/syscall.c:4381 [<8feaf393>] do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 [ ] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Re: [PATCH] dt-bindings: leds: Document commonly used LED triggers
On 2020/12/10 14:14, Manivannan Sadhasivam wrote:
> This commit documents the LED triggers used commonly in the SoCs. Not
> all triggers are documented as some of them are very application specific.
> Most of the triggers documented here are currently used in devicetrees
> of many SoCs.
>
> Signed-off-by: Manivannan Sadhasivam
> ---
> .../devicetree/bindings/leds/common.yaml | 72 ++-
> 1 file changed, 54 insertions(+), 18 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/leds/common.yaml
> b/Documentation/devicetree/bindings/leds/common.yaml
> index f1211e7045f1..eee4eb7a4535 100644
> --- a/Documentation/devicetree/bindings/leds/common.yaml
> +++ b/Documentation/devicetree/bindings/leds/common.yaml
> @@ -79,24 +79,60 @@ properties:
>the LED.
> $ref: /schemas/types.yaml#definitions/string
>
> -enum:
> -# LED will act as a back-light, controlled by the framebuffer system
> - - backlight
> -# LED will turn on (but for leds-gpio see "default-state" property in
> -# Documentation/devicetree/bindings/leds/leds-gpio.yaml)
> - - default-on
> -# LED "double" flashes at a load average based rate
> - - heartbeat
> -# LED indicates disk activity
> - - disk-activity
> -# LED indicates IDE disk activity (deprecated), in new
> implementations
> -# use "disk-activity"
> - - ide-disk
> -# LED flashes at a fixed, configurable rate
> - - timer
> -# LED alters the brightness for the specified duration with one
> software
> -# timer (requires "led-pattern" property)
> - - pattern
> +oneOf:
> + - items:
> + - enum:
> +# LED will act as a back-light, controlled by the
> framebuffer system
> + - backlight
> +# LED will turn on (but for leds-gpio see "default-state"
> property in
> +# Documentation/devicetree/bindings/leds/leds-gpio.yaml)
> + - default-on
> +# LED "double" flashes at a load average based rate
> + - heartbeat
> +# LED indicates disk activity
> + - disk-activity
> +# LED indicates IDE disk activity (deprecated), in new
> implementations
> +# use "disk-activity"
> + - ide-disk
> +# LED flashes at a fixed, configurable rate
> + - timer
> +# LED alters the brightness for the specified duration with
> one software
> +# timer (requires "led-pattern" property)
> + - pattern
> +# LED indicates camera flash state
> + - flash
> +# LED indicates camera torch state
> + - torch
> +# LED indicates audio mute state
> + - audio-mute
> +# LED indicates mic mute state
> + - audio-micmute
> +# LED indicates bluetooth power state
> + - bluetooth-power
> +# LED indicates USB gadget activity
> + - usb-gadget
> +# LED indicates USB host activity
> + - usb-host
> +# LED indicates MTD memory activity
> + - mtd
> +# LED indicates NAND memory activity (deprecated),
> +# in new implementations use "mtd"
> + - nand-disk
> +# LED indicates disk read activity
> + - disk-read
> +# LED indicates disk write activity
> + - disk-write
> +# No trigger assigned to the LED. This is the default mode
> +# if trigger is absent
> + - none
> +# LED indicates activity of all CPUs
> + - cpu
The triggers phy0tx and hci0-power are missed.
Since you've rewritten it, please consider sorting these property strings
in ascending alphabetical order.
> + - items:
> +# LED indicates activity of [N]th CPU
> + - pattern: "^cpu[0-9][0-9]$"
should be ^cpu[0-9]{1,2}$, otherwise, it always requires two digit.
> + - items:
> +# LED indicates [N]th MMC storage activity
> + - pattern: '^mmc[0-9][0-9]$'
should be '^mmc[0-9]{1,2}$'
Why CPU use "", and mmc use ''，It's better to keep them consistent.
>
>led-pattern:
> description: |
>
[PATCH v3] dt-bindings: usb: Add new compatible string for AM64 SoC
Add compatible string in j721e-usb binding file as the same USB subsystem is present in AM64. Signed-off-by: Aswath Govindraju Acked-by: Roger Quadros --- Changes since v2: - added changes done over the versions Changes since v1: - replaced the '\t' at the beginning of the lines with spaces as it was causing the dt_binding_check to fail Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml index 388245b91a55..453587f6d304 100644 --- a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml +++ b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml @@ -11,8 +11,11 @@ maintainers: properties: compatible: -items: - - const: ti,j721e-usb +anyOf: + - items: + - const: ti,j721e-usb + - items: + - const: ti,am64-usb reg: description: module registers -- 2.17.1
Re: [PATCH v4 0/6] MIPS: ralink: add CPU clock detection and clock driver for MT7621
Hi all, On Sun, Nov 22, 2020 at 10:55 AM Sergio Paracuellos wrote: > > This patchset ports CPU clock detection for MT7621 from OpenWrt > and adds a complete clock plan for the mt7621 SOC. > > The documentation for this SOC only talks about two registers > regarding to the clocks: > * SYSC_REG_CPLL_CLKCFG0 - provides some information about boostrapped > refclock. PLL and dividers used for CPU and some sort of BUS (AHB?). > * SYSC_REG_CPLL_CLKCFG1 - a banch of gates to enable/disable clocks for > all or some ip cores. > > No documentation about a probably existent set of dividers for each ip > core is included in the datasheets. So we cannot make anything better, > AFAICT. > > Looking into driver code, and some openWRT patched there are > another frequences which are used in some drivers (uart, sd...). > According to all of this information the clock plan for this > SoC is set as follows: > - Main top clock "xtal" from where all the rest of the world is >derived. > - CPU clock "cpu" derived from "xtal" frequencies and a bunch of >register reads and predividers. > - BUS clock "bus" derived from "cpu" and with (cpu / 4) MHz. > - Fixed clocks from "xtal": > * "50m": 50 MHz. > * "125m": 125 MHz. > * "150m": 150 MHz. > * "250m": 250 MHz. > * "270m": 270 MHz. > > We also have a buch of gate clocks with their parents: > - "hsdma": "150m" > - "fe": "250m" > - "sp_divtx": "270m" > - "timer": "50m" > - "pcm": "270m" > - "pio": "50m" > - "gdma": "bus" > - "nand": "125m" > - "i2c": "50m" > - "i2s": "270m" > - "spi": "bus" > - "uart1": "50m" > - "uart2": "50m" > - "uart3": "50m" > - "eth": "50m" > - "pcie0": "125m" > - "pcie1": "125m" > - "pcie2": "125m" > - "crypto": "250m" > - "shxc": "50m" > > There was a previous attempt of doing this here[0] but the author > (Chuanhong Guo) did not wanted to make assumptions of a clock plan > for the platform that time. It seems that now he has a better idea of > how the clocks are dispossed for this SoC so he share code[1] where > some frequencies and clock parents for the gates are coded from a > real mediatek private clock plan. > > I do really want this to be upstreamed so according to the comments > in previous attempt[0] from Oleksij Rempel and the frequencies in > code[1] I have tried to do this by myself. > > All of this patches have been tested in a GNUBee PC1 resulting in a > working platform. > > Changes in v4: > - Add Acked-by from Rob Herring for binding headers (PATCH 1/6). > - Convert bindings to not use syscon phandle and declare clock as >a child of the syscon node. Update device tree and binding doc >accordly. > - Make use of 'syscon_node_to_regmap' in driver code instead of >get this using the phandle function. > - Properly unregister clocks for the error path of the function >'mt7621_clk_init'. > - Include ARRAY_SIZE of fixed clocks in the 'count' to kzalloc >of 'clk_data'. > - Add new patch changing invalid vendor 'mtk' in favour of 'mediatek' >which is the one listed in 'vendor-prefixes.yaml'. Update mt7621 code >accordly. I have added this patch inside this series because clk >binding is referring syscon node and the string for that node was >with not listed vendor. Hence update and have all of this correct >in the same series. Any comments on this?? Should I resend the series to get reviewed? Thanks in advance for your time! Best regards, Sergio Paracuellos > > Changes in v3: > - Fix compilation warnings reported by kernel test robot because of >ignoring return values of 'of_clk_hw_register' in functions >'mt7621_register_top_clocks' and 'mt7621_gate_ops_init'. > - Fix dts file and binding documentation 'clock-output-names'. > > Changes in v2: > - Remove the following patches: >* dt: bindings: add mt7621-pll device tree binding documentation. >* MIPS: ralink: add clock device providing cpu/ahb/apb clock for mt7621. > - Move all relevant clock code to 'drivers/clk/ralink/clk-mt7621.c' and >unify there previous 'mt7621-pll' and 'mt7621-clk' into a unique driver >and binding 'mt7621-clk'. > - Driver is not a platform driver anymore and now make use of > 'CLK_OF_DECLARE' >because we need clocks available in 'plat_time_init' before setting up >the timer for the GIC. > - Use new fixed clocks as parents for different gates and deriving from > 'xtal' >using frequencies in[1]. > - Adapt dts file and bindings header and documentation for new changes. > - Change MAINTAINERS file to only contains clk-mt7621.c code and >mediatek,mt7621-clk.yaml file. > > [0]: https://www.lkml.org/lkml/2019/7/23/1044 > [1]: > https://github.com/981213/linux/commit/2eca1f045e4c3db18c941135464c0d7422ad8133 > > > Sergio Paracuellos (6): > dt-bindings: clock: add dt binding header for mt7621 clocks > dt: bindings: add mt7621-clk device tree binding documentation > clk: ralink: add clock driver for mt7621 SoC > staging:
[PATCH] gpio: aspeed: Lock GPIO pin used as IRQ
GPIO pins can be used as IRQ indicators. When they do,
those pins should be flaged with locks to avoid kernel
warning message.
Signed-off-by: Chia-Wei, Wang
Signed-off-by: Troy Lee
---
drivers/gpio/gpio-aspeed.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
index b966f5e28ebf..f5b3e1d89fbf 100644
--- a/drivers/gpio/gpio-aspeed.c
+++ b/drivers/gpio/gpio-aspeed.c
@@ -651,6 +651,13 @@ static int aspeed_gpio_set_type(struct irq_data *d,
unsigned int type)
aspeed_gpio_copro_release(gpio, offset);
spin_unlock_irqrestore(>lock, flags);
+ rc = gpiochip_lock_as_irq(>chip, d->hwirq);
+ if (rc) {
+ dev_err(gpio->chip.parent, "unable to lock GPIO %lu as IRQ\n",
+ d->hwirq);
+ return rc;
+ }
+
irq_set_handler_locked(d, handler);
return 0;
--
2.17.1
Re: linux-next: manual merge of the staging tree with the phy-next tree
Hi Stephen,
On Thu, Dec 10, 2020 at 7:40 AM Stephen Rothwell wrote:
>
> Hi all,
>
> Today's linux-next merge of the staging tree got conflicts in:
>
> drivers/staging/Kconfig
> drivers/staging/Makefile
>
> between commit:
>
> 53e7c92c7fa0 ("staging: mt7621-pci-phy: remove driver from staging")
>
> from the phy-next tree and commit:
>
> 518b466a21ad ("pinctrl: ralink: add a pinctrl driver for the rt2880 family")
>
> from the staging tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Thanks for doing this. Removing both in staging is the correct thing to do.
>
> --
> Cheers,
> Stephen Rothwell
Best regards,
Sergio Paracuellos
>
> diff --cc drivers/staging/Kconfig
> index 4d7a5ddf9992,c42708e60afc..
> --- a/drivers/staging/Kconfig
> +++ b/drivers/staging/Kconfig
> @@@ -94,8 -92,8 +92,6 @@@ source "drivers/staging/pi433/Kconfig
>
> source "drivers/staging/mt7621-pci/Kconfig"
>
> - source "drivers/staging/mt7621-pinctrl/Kconfig"
> -source "drivers/staging/mt7621-pci-phy/Kconfig"
> --
> source "drivers/staging/mt7621-dma/Kconfig"
>
> source "drivers/staging/ralink-gdma/Kconfig"
> diff --cc drivers/staging/Makefile
> index 89bde2370eee,ebcc646d7b51..
> --- a/drivers/staging/Makefile
> +++ b/drivers/staging/Makefile
> @@@ -37,7 -36,7 +36,6 @@@ obj-$(CONFIG_GREYBUS) += greybus
> obj-$(CONFIG_BCM2835_VCHIQ) += vc04_services/
> obj-$(CONFIG_PI433) += pi433/
> obj-$(CONFIG_PCI_MT7621) += mt7621-pci/
> - obj-$(CONFIG_PINCTRL_RT2880) += mt7621-pinctrl/
> -obj-$(CONFIG_PCI_MT7621_PHY) += mt7621-pci-phy/
> obj-$(CONFIG_SOC_MT7621) += mt7621-dma/
> obj-$(CONFIG_DMA_RALINK) += ralink-gdma/
> obj-$(CONFIG_SOC_MT7621) += mt7621-dts/
[PATCH] sh: kdump: add some attribute to function
add '__iomem' for ioremap() and '__user' for copy_to_user().
Signed-off-by: Yejune Deng
---
arch/sh/kernel/crash_dump.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/sh/kernel/crash_dump.c b/arch/sh/kernel/crash_dump.c
index a908612..5b41b59 100644
--- a/arch/sh/kernel/crash_dump.c
+++ b/arch/sh/kernel/crash_dump.c
@@ -26,7 +26,7 @@
ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
size_t csize, unsigned long offset, int userbuf)
{
- void *vaddr;
+ void __iomem *vaddr;
if (!csize)
return 0;
@@ -34,7 +34,7 @@ ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
vaddr = ioremap(pfn << PAGE_SHIFT, PAGE_SIZE);
if (userbuf) {
- if (copy_to_user(buf, (vaddr + offset), csize)) {
+ if (copy_to_user((void __user *)buf, (vaddr + offset), csize)) {
iounmap(vaddr);
return -EFAULT;
}
--
1.9.1
Re: [PATCH v2 0/3] PCI: J721E: Fix Broken DT w.r.t SYSCON DT
Hi Lorenzo, On 04/12/20 1:21 pm, Kishon Vijay Abraham I wrote: > Previously a subnode to syscon node was added which has the > exact memory mapped address of pcie_ctrl but based on review comment > provided by Rob [1], the offset is now being passed as argument to > "ti,syscon-pcie-ctrl" phandle. > > This series has both driver change and DT change. The driver change > should be merged first and the driver takes care of maintaining old > DT compatibility. Can you queue the 1st two patches of this series for this merge window? I'll ask NM to queue the DTS patch. Let me know if you want me to resend only the first two patches as a separate series. Thank You, Kishon > > Changes frm v1: > *) Remove use of allOf in schema > *) Added Fixes tag > *) Maintain old DT compatibility > > [1] -> > http://lore.kernel.org/r/cal_jsqkiuco76bo1goepwm1tusjwoty_bry2hfsgtevmqtr...@mail.gmail.com > > Kishon Vijay Abraham I (3): > dt-bindings: pci: ti,j721e: Fix "ti,syscon-pcie-ctrl" to take argument > PCI: j721e: Get offset within "syscon" from "ti,syscon-pcie-ctrl" > phandle arg > arm64: dts: ti: k3-j721e-main: Remove "syscon" nodes added for > pcieX_ctrl > > .../bindings/pci/ti,j721e-pci-ep.yaml | 11 +++-- > .../bindings/pci/ti,j721e-pci-host.yaml | 11 +++-- > arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 48 --- > drivers/pci/controller/cadence/pci-j721e.c| 28 +++ > 4 files changed, 41 insertions(+), 57 deletions(-) >
Re: linux-next: build warning after merge of the kbuild tree
Stephen Rothwell wrote on Thu, Dec 10, 2020: > On Wed, 9 Dec 2020 14:01:30 +0100 Dominique Martinet > wrote: > > > > I guess it's possible to make kbuild check both sbin and PATH, would > > that be acceptable? > > I guess so. But, have you actually found any setup where depmod is not > /sbin/depmod? i.e. what problem are you trying to solve. As far as I > can see all this change does is (ever so slightly) slow down the build > for no gain. On nixos, depmod is in /run/current-system/sw/bin/depmod (as a link to /nix/store/r3r39rzsrikdsv68rvswn3hhank706gj-kmod-27/bin/depmod or wherever the current version wants to be). developers on guix probably face the same problem. There is no sbin, the only things in /bin is sh, and in /usr/bin env as I think is mandated by posix. For their official builds they just modify the build scripts in place before starting the build, but for dev as I keep rebasing it's annoying to keep a couple of local patches just for this. I could obviously manually create a link from /sbin/depmod to the current system's but that doesn't solve the problem for all other nixos users. I'll send an updated patch later today.. -- Dominique
Re: [PATCH 1/1] net/ipv4/inet_fragment: Batch fqdir destroy works
On Wed, 9 Dec 2020 15:16:59 -0800 Jakub Kicinski wrote:
> On Tue, 8 Dec 2020 10:45:29 +0100 SeongJae Park wrote:
> > From: SeongJae Park
> >
> > In 'fqdir_exit()', a work for destruction of the 'fqdir' is enqueued.
> > The work function, 'fqdir_work_fn()', calls 'rcu_barrier()'. In case of
> > intensive 'fqdir_exit()' (e.g., frequent 'unshare(CLONE_NEWNET)'
> > systemcalls), this increased contention could result in unacceptably
> > high latency of 'rcu_barrier()'. This commit avoids such contention by
> > doing the destruction in batched manner, as similar to that of
> > 'cleanup_net()'.
> >
> > Signed-off-by: SeongJae Park
>
> Looks fine to me, but you haven't CCed Florian or Eric who where the
> last two people to touch this function. Please repost CCing them and
> fixing the nit below, thanks!
Thank you for let me know that. I will send the next version so.
>
> > static void fqdir_work_fn(struct work_struct *work)
> > {
> > - struct fqdir *fqdir = container_of(work, struct fqdir, destroy_work);
> > - struct inet_frags *f = fqdir->f;
> > + struct llist_node *kill_list;
> > + struct fqdir *fqdir;
> > + struct inet_frags *f;
>
> nit: reorder fqdir and f to keep reverse xmas tree variable ordering.
Hehe, ok, I will. :)
Thanks,
SeongJae Park
[PATCH v3 5/5] f2fs: introduce sb_status sysfs node
Introduce /sys/fs/f2fs//stat/sb_status to show superblock
status in real time as a hexadecimal value.
value sb status macro description
0x1 SBI_IS_DIRTY, /* dirty flag for checkpoint */
0x2 SBI_IS_CLOSE, /* specify unmounting */
0x4 SBI_NEED_FSCK, /* need fsck.f2fs to fix */
0x8 SBI_POR_DOING, /* recovery is doing or not */
0x10SBI_NEED_SB_WRITE, /* need to recover superblock */
0x20SBI_NEED_CP,/* need to checkpoint */
0x40SBI_IS_SHUTDOWN,/* shutdown by ioctl */
0x80SBI_IS_RECOVERED, /* recovered orphan/data */
0x100 SBI_CP_DISABLED,/* CP was disabled last mount */
0x200 SBI_CP_DISABLED_QUICK, /* CP was disabled quickly */
0x400 SBI_QUOTA_NEED_FLUSH, /* need to flush quota info in
CP */
0x800 SBI_QUOTA_SKIP_FLUSH, /* skip flushing quota in
current CP */
0x1000 SBI_QUOTA_NEED_REPAIR, /* quota file may be corrupted
*/
0x2000 SBI_IS_RESIZEFS,/* resizefs is in process */
Signed-off-by: Chao Yu
---
v3:
- just print one single value as output
Documentation/ABI/testing/sysfs-fs-f2fs | 21 +
fs/f2fs/sysfs.c | 8
2 files changed, 29 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs
b/Documentation/ABI/testing/sysfs-fs-f2fs
index 3dfee94e0618..9b2f93eda1f8 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -377,3 +377,24 @@ Description: This gives a control to limit the bio
size in f2fs.
Default is zero, which will follow underlying block layer limit,
whereas, if it has a certain bytes value, f2fs won't submit a
bio larger than that size.
+
+What: /sys/fs/f2fs//stat/sb_status
+Date: December 2020
+Contact: "Chao Yu"
+Description: Show status of f2fs superblock in real time.
+
+ value sb status macro description
+ 0x1 SBI_IS_DIRTY, /* dirty flag
for checkpoint */
+ 0x2 SBI_IS_CLOSE, /* specify
unmounting */
+ 0x4 SBI_NEED_FSCK, /* need
fsck.f2fs to fix */
+ 0x8 SBI_POR_DOING, /* recovery is
doing or not */
+ 0x10SBI_NEED_SB_WRITE, /* need to
recover superblock */
+ 0x20SBI_NEED_CP,/* need to
checkpoint */
+ 0x40SBI_IS_SHUTDOWN,/* shutdown by
ioctl */
+ 0x80SBI_IS_RECOVERED, /* recovered
orphan/data */
+ 0x100 SBI_CP_DISABLED,/* CP was
disabled last mount */
+ 0x200 SBI_CP_DISABLED_QUICK, /* CP was
disabled quickly */
+ 0x400 SBI_QUOTA_NEED_FLUSH, /* need to
flush quota info in CP */
+ 0x800 SBI_QUOTA_SKIP_FLUSH, /* skip
flushing quota in current CP */
+ 0x1000 SBI_QUOTA_NEED_REPAIR, /* quota file
may be corrupted */
+ 0x2000 SBI_IS_RESIZEFS,/* resizefs is
in process */
diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
index ebca0b4961e8..d5198689ab02 100644
--- a/fs/f2fs/sysfs.c
+++ b/fs/f2fs/sysfs.c
@@ -101,6 +101,12 @@ static ssize_t lifetime_write_kbytes_show(struct f2fs_attr
*a,
sbi->sectors_written_start) >> 1)));
}
+static ssize_t sb_status_show(struct f2fs_attr *a,
+ struct f2fs_sb_info *sbi, char *buf)
+{
+ return sprintf(buf, "%lx\n", sbi->s_flag);
+}
+
static ssize_t features_show(struct f2fs_attr *a,
struct f2fs_sb_info *sbi, char *buf)
{
@@ -711,7 +717,9 @@ static struct attribute *f2fs_feat_attrs[] = {
};
ATTRIBUTE_GROUPS(f2fs_feat);
+F2FS_GENERAL_RO_ATTR(sb_status);
static struct attribute *f2fs_stat_attrs[] = {
+ ATTR_LIST(sb_status),
NULL,
};
ATTRIBUTE_GROUPS(f2fs_stat);
--
2.29.2
Re: [PATCH net-next] net: lapbether: Consider it successful if (dis)connecting when already (dis)connected
On 2020-12-08 23:50, Xie He wrote:
When the upper layer instruct us to connect (or disconnect), but we
have
already connected (or disconnected), consider this operation successful
rather than failed.
This can help the upper layer to correct its record about whether we
are
connected or not here in layer 2.
The upper layer may not have the correct information about whether we
are
connected or not. This can happen if this driver has already been
running
for some time when the "x25" module gets loaded.
Another X.25 driver (hdlc_x25) is already doing this, so we make this
driver do this, too.
Looks good to me.
Acked-by: Martin Schiller
Cc: Martin Schiller
Signed-off-by: Xie He
---
drivers/net/wan/lapbether.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wan/lapbether.c b/drivers/net/wan/lapbether.c
index b6be2454b8bd..605fe555e157 100644
--- a/drivers/net/wan/lapbether.c
+++ b/drivers/net/wan/lapbether.c
@@ -55,6 +55,9 @@ struct lapbethdev {
static LIST_HEAD(lapbeth_devices);
+static void lapbeth_connected(struct net_device *dev, int reason);
+static void lapbeth_disconnected(struct net_device *dev, int reason);
+
/*
*/
/*
@@ -167,11 +170,17 @@ static netdev_tx_t lapbeth_xmit(struct sk_buff
*skb,
case X25_IFACE_DATA:
break;
case X25_IFACE_CONNECT:
- if ((err = lapb_connect_request(dev)) != LAPB_OK)
+ err = lapb_connect_request(dev);
+ if (err == LAPB_CONNECTED)
+ lapbeth_connected(dev, LAPB_OK);
+ else if (err != LAPB_OK)
pr_err("lapb_connect_request error: %d\n", err);
goto drop;
case X25_IFACE_DISCONNECT:
- if ((err = lapb_disconnect_request(dev)) != LAPB_OK)
+ err = lapb_disconnect_request(dev);
+ if (err == LAPB_NOTCONNECTED)
+ lapbeth_disconnected(dev, LAPB_OK);
+ else if (err != LAPB_OK)
pr_err("lapb_disconnect_request err: %d\n", err);
fallthrough;
default:
linux-next: manual merge of the staging tree with the phy-next tree
Hi all,
Today's linux-next merge of the staging tree got conflicts in:
drivers/staging/Kconfig
drivers/staging/Makefile
between commit:
53e7c92c7fa0 ("staging: mt7621-pci-phy: remove driver from staging")
from the phy-next tree and commit:
518b466a21ad ("pinctrl: ralink: add a pinctrl driver for the rt2880 family")
from the staging tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/staging/Kconfig
index 4d7a5ddf9992,c42708e60afc..
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@@ -94,8 -92,8 +92,6 @@@ source "drivers/staging/pi433/Kconfig
source "drivers/staging/mt7621-pci/Kconfig"
- source "drivers/staging/mt7621-pinctrl/Kconfig"
-source "drivers/staging/mt7621-pci-phy/Kconfig"
--
source "drivers/staging/mt7621-dma/Kconfig"
source "drivers/staging/ralink-gdma/Kconfig"
diff --cc drivers/staging/Makefile
index 89bde2370eee,ebcc646d7b51..
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@@ -37,7 -36,7 +36,6 @@@ obj-$(CONFIG_GREYBUS) += greybus
obj-$(CONFIG_BCM2835_VCHIQ) += vc04_services/
obj-$(CONFIG_PI433) += pi433/
obj-$(CONFIG_PCI_MT7621) += mt7621-pci/
- obj-$(CONFIG_PINCTRL_RT2880) += mt7621-pinctrl/
-obj-$(CONFIG_PCI_MT7621_PHY) += mt7621-pci-phy/
obj-$(CONFIG_SOC_MT7621) += mt7621-dma/
obj-$(CONFIG_DMA_RALINK) += ralink-gdma/
obj-$(CONFIG_SOC_MT7621) += mt7621-dts/
pgpe2jHxjK1xZ.pgp
Description: OpenPGP digital signature
Re: [PATCH net-next] net: x25: Fix handling of Restart Request and Restart Confirmation
On 2020-12-09 21:16, Xie He wrote: On Wed, Dec 9, 2020 at 2:31 AM Martin Schiller wrote: >> 1. When the x25 module gets loaded, layer 2 may already be running and >> connected. In this case, although we are in X25_LINK_STATE_0, we still >> need to handle the Restart Request received, rather than ignore it. > > Hmm... I've never loaded the X.25 module after the interface is UP, but > in this case we really have to fix it. > This seems to be a regression caused by moving the Layer2 link handling into the lapb driver, which wasn't intended in my original patchset. I also have another patch on my todo list which aims orphan packet handling in the x25_receive_data() function. Maybe it is better to catch the whole thing there. OK.. Currently it's not clear to me what your future patches would be. Maybe we can first have this patch applied? Because based on the current code I think this patch is necessary. When you are ready to submit your patches, you can replace my code and we can discuss further. Yes, that's also the reason why I already acked this patch. We can solve this later a little bit cleaner if necessary. My patch that takes care of the orphaned packets in x25_receive_data() has again a dependency on other patches, especially the patch to configure the neighbor parameters (DCE/DTE, number of channels etc.), which I already sent before but still have to revise. Unfortunately I have only limited time for this topic, so I am not as fast as some people would wish. Sorry for that. Martin
Re: [PATCH 2/2] Input: elantech - Some module tp of tracpoint report has a smbus protocol error.
Hi Jingle,
On Mon, Dec 07, 2020 at 05:08:00PM +0800, jingle.wu wrote:
> 1. Add the conditional expression to distinguish different patterns regarding
> 0, 1, 2.
> 2. Add the function to get or set more bytes from register
> 3. Get and correct the device informations including ic_type, module id from
> different pattern.
> 4. Add the function to change the report id 0x5F of trackpoint.
> 5. Some module has a bug which makes default SMBUS trackpoint report 0x5E has
> a smbus protocol error.
Your Signed-off-by is missing.
> ---
> drivers/input/mouse/elantech.c | 128 -
> drivers/input/mouse/elantech.h | 4 ++
> 2 files changed, 131 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
> index 90f8765f9efc..b3240775ceca 100644
> --- a/drivers/input/mouse/elantech.c
> +++ b/drivers/input/mouse/elantech.c
> @@ -89,6 +89,57 @@ static int elantech_ps2_command(struct psmouse *psmouse,
> return rc;
> }
>
> +/*
> + * Send an Elantech style special command to read 3 bytes from a register
> + */
> +static int elantech_read_reg_params(struct psmouse *psmouse, unsigned char
> reg,
> +unsigned char *param)
> +{
> + int rc = 0;
> +
Extra tab here. Please run through checkpatch to catch these.
> + if (elantech_ps2_command(psmouse, NULL, ETP_PS2_CUSTOM_COMMAND) ||
> + elantech_ps2_command(psmouse, NULL, ETP_REGISTER_READWRITE) ||
> + elantech_ps2_command(psmouse, NULL, ETP_PS2_CUSTOM_COMMAND) ||
> + elantech_ps2_command(psmouse, NULL, reg) ||
> + elantech_ps2_command(psmouse, param, PSMOUSE_CMD_GETINFO)) {
> + rc = -1;
This is weird indentation. You can also move the error message here and
get rid of "rc" variable.
> + }
> +
> + if (rc)
> + psmouse_err(psmouse,
> + "failed to read register 0x%02x.\n", reg);
> + return rc;
> +}
> +
> +/*
> + * Send an Elantech style special command to write a register with a
> parameter
> + */
> +static int elantech_write_reg_params(struct psmouse *psmouse, unsigned char
> reg,
> + unsigned char *param)
> +{
> +
> + int rc = 0;
> +
> + if (elantech_ps2_command(psmouse, NULL, ETP_PS2_CUSTOM_COMMAND) ||
> + elantech_ps2_command(psmouse, NULL, ETP_REGISTER_READWRITE)
> ||
> + elantech_ps2_command(psmouse, NULL, ETP_PS2_CUSTOM_COMMAND)
> ||
> + elantech_ps2_command(psmouse, NULL, reg) ||
> + elantech_ps2_command(psmouse, NULL, ETP_PS2_CUSTOM_COMMAND)
> ||
> + elantech_ps2_command(psmouse, NULL, param[0]) ||
> + elantech_ps2_command(psmouse, NULL, ETP_PS2_CUSTOM_COMMAND)
> ||
> + elantech_ps2_command(psmouse, NULL, param[1]) ||
> + elantech_ps2_command(psmouse, NULL,
> PSMOUSE_CMD_SETSCALE11)) {
> + rc = -1;
> + }
> +
> + if (rc)
> + psmouse_err(psmouse,
> + "failed to write register 0x%02x with value
> 0x%02x0x%02x.\n",
> + reg, param[0], param[1]);
> + return rc;
> +
> +}
> +
> /*
> * Send an Elantech style special command to read a value from a register
> */
> @@ -1529,6 +1580,27 @@ static const struct dmi_system_id
> no_hw_res_dmi_table[] = {
> { }
> };
>
> +/*
> + * Change Report id 0x5E to 0x5F.
> + */
> +static int elantech_change_report_id(struct psmouse *psmouse)
> +{
> + unsigned char param[2] = { 0x10, 0x03 };
> +
> + if (elantech_write_reg_params(psmouse, 0x7, param) == 0) {
> + if (elantech_read_reg_params(psmouse, 0x7, param) == 0) {
> + if ((param[0] == 0x10) && (param[1] == 0x03)) {
> + return 0;
> + }
> + psmouse_err(psmouse,
> + "Elantech change report id Fail. (0x%02x, 0x%02x)\n",
> + param[0], param[1]);
Awkward indentation/formatting.
> + }
> + }
> + psmouse_err(psmouse,
> + "Elantech change report id Fail.\n");
> + return -1;
> +}
> /*
> * determine hardware version and set some properties according to it.
> */
> @@ -1556,6 +1628,18 @@ static int elantech_set_properties(struct
> elantech_device_info *info)
> return -1;
> }
> }
> +
> +
> + /* Get information pattern for hw_version 4 */
> + if (ver == 15) {
> + if ((info->fw_version & 0xff) == 0x01)
> + info->pattern = 0x01;
> + else if ((info->fw_version & 0xff) == 0x02)
> + info->pattern = 0x02;
> + else
> + info->pattern = 0x00;
> + } else
> + info->pattern = 0x00;
Re: [PATCH v2 1/8] mm/gup: perform check_dax_vmas only when FS_DAX is enabled
> There is no need to check_dax_vmas() and run through the npage loop of
> pinned pages if FS_DAX is not enabled.
>
> Add a stub check_dax_vmas() function for no-FS_DAX case.
>
> Signed-off-by: Pavel Tatashin
> Reviewed-by: John Hubbard
> ---
> mm/gup.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/mm/gup.c b/mm/gup.c
> index 98eb8e6d2609..cdb8b9eeb016 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -1568,6 +1568,7 @@ struct page *get_dump_page(unsigned long addr)
> #endif /* CONFIG_ELF_CORE */
>
> #if defined(CONFIG_FS_DAX) || defined (CONFIG_CMA)
> +#ifdef CONFIG_FS_DAX
> static bool check_dax_vmas(struct vm_area_struct **vmas, long nr_pages)
> {
> long i;
> @@ -1586,6 +1587,12 @@ static bool check_dax_vmas(struct vm_area_struct
> **vmas, long nr_pages)
> }
> return false;
> }
> +#else
> +static bool check_dax_vmas(struct vm_area_struct **vmas, long nr_pages)
> +{
> + return false;
> +}
> +#endif
>
> #ifdef CONFIG_CMA
> static long check_and_migrate_cma_pages(struct mm_struct *mm,
Reviewed-by: Pankaj Gupta
Re: [PATCH 3/3] mfd: bd9571mwv: Add support for BD9574MWF
Hi deee Ho Yoshihiro-san, Geert, All, On Wed, 2020-12-09 at 14:30 +0100, Geert Uytterhoeven wrote: > Hi Shimoda-san, > > CC Matti (BD9573/6 driver for R-Car platforms) Thank Geert! I wouldn't have noticed this :) > > (I don't have the BD9574 datasheet, so I have to base my review on > https://www.rohm.com/r-car-pmic) > > On Tue, Dec 8, 2020 at 9:06 AM Yoshihiro Shimoda > wrote: > > From: Khiem Nguyen > > > > The new PMIC BD9574MWF inherits features from BD9571MWV. > > Add the support of new PMIC to existing bd9571mwv driver. > > > > Signed-off-by: Khiem Nguyen > > [shimoda: rebase and refactor] > > Signed-off-by: Yoshihiro Shimoda > > Thanks for your patch! > Indeed! It's really nice to see other people working on upstreaming drivers for ROHM PMICs! Thanks for all the good work! Can you please add me to CC if you ever resend the series? I like to know what kind of support there is added in-tree for ROHM PMICs :) Best Regards Matti -- Matti Vaittinen, Linux device drivers ROHM Semiconductors, Finland SWDC Kiviharjunlenkki 1E 90220 OULU FINLAND ~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~ Simon says - in Latin please. "non cogito me" dixit Rene Descarte, deinde evanescavit (Thanks for the translation Simon)
Re: [PATCH net-next v7 4/5] net/x25: fix restart request/confirm handling
On 2020-12-09 23:11, Xie He wrote: On Wed, Dec 9, 2020 at 1:47 AM Xie He wrote: On Wed, Dec 9, 2020 at 1:41 AM Martin Schiller wrote: > > Right. > By the way: A "Restart Collision" is in practice a very common event to > establish the Layer 3. Oh, I see. Thanks! Hi Martin, When you submit future patch series, can you try ensuring the code to be in a completely working state after each patch in the series? This makes reviewing the patches easier. After the patches get applied, this also makes tracing bugs (for example, with "git bisect") through the commit history easier. Well I thought that's what patch series are for: Send patches that belong together and should be applied together. Of course I will try to make each patch work on its own, but this is not always possible with major changes or ends up in monster patches. And nobody wants that. Martin
RE: [PATCH] [v2] blk-mq-tag: make blk_mq_tag_busy() return void
Yes,
Sorry, In V2. I missed it, so I sent v3 :)
-Original Message-
From: Chaitanya Kulkarni [mailto:chaitanya.kulka...@wdc.com]
Sent: Thursday, December 10, 2020 2:21 PM
To: tianxianting (RD) ; ax...@kernel.dk
Cc: ming@redhat.com; linux-bl...@vger.kernel.org;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [v2] blk-mq-tag: make blk_mq_tag_busy() return void
On 12/9/20 22:06, Xianting Tian wrote:
> As no one cares about the return value of blk_mq_tag_busy() and
> __blk_mq_tag_busy(), so make them return void.
>
> Other change is to simplify blk_mq_tag_idle().
>
> Signed-off-by: Xianting Tian
> Reviewed-by: Ming Lei
> ---
> block/blk-mq-tag.c | 4 ++--
> block/blk-mq-tag.h | 16 ++--
> 2 files changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c index
> 9c92053e7..21ff7d156 100644
> --- a/block/blk-mq-tag.c
> +++ b/block/blk-mq-tag.c
> @@ -21,7 +21,7 @@
> * to get tag when first time, the other shared-tag users could reserve
> * budget for it.
> */
> -bool __blk_mq_tag_busy(struct blk_mq_hw_ctx *hctx)
> +void __blk_mq_tag_busy(struct blk_mq_hw_ctx *hctx)
> {
> if (blk_mq_is_sbitmap_shared(hctx->flags)) {
> struct request_queue *q = hctx->queue; @@ -36,7 +36,7 @@ bool
> __blk_mq_tag_busy(struct blk_mq_hw_ctx *hctx)
> atomic_inc(>tags->active_queues);
> }
>
> - return true;
> + return;
if above return is the last statement then you need to remove that instead of
using return with no value.
Also, please add the version history.
Re: [PATCH] [v2] blk-mq-tag: make blk_mq_tag_busy() return void
On 12/9/20 22:06, Xianting Tian wrote:
> As no one cares about the return value of blk_mq_tag_busy() and
> __blk_mq_tag_busy(), so make them return void.
>
> Other change is to simplify blk_mq_tag_idle().
>
> Signed-off-by: Xianting Tian
> Reviewed-by: Ming Lei
> ---
> block/blk-mq-tag.c | 4 ++--
> block/blk-mq-tag.h | 16 ++--
> 2 files changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
> index 9c92053e7..21ff7d156 100644
> --- a/block/blk-mq-tag.c
> +++ b/block/blk-mq-tag.c
> @@ -21,7 +21,7 @@
> * to get tag when first time, the other shared-tag users could reserve
> * budget for it.
> */
> -bool __blk_mq_tag_busy(struct blk_mq_hw_ctx *hctx)
> +void __blk_mq_tag_busy(struct blk_mq_hw_ctx *hctx)
> {
> if (blk_mq_is_sbitmap_shared(hctx->flags)) {
> struct request_queue *q = hctx->queue;
> @@ -36,7 +36,7 @@ bool __blk_mq_tag_busy(struct blk_mq_hw_ctx *hctx)
> atomic_inc(>tags->active_queues);
> }
>
> - return true;
> + return;
if above return is the last statement then you need to remove that
instead of using return with no value.
Also, please add the version history.
Re: [PATCH 1/1] dt-bindings: leds: add onboard LED triggers of 96Boards
On Thu, Dec 10, 2020 at 02:14:57PM +0800, Leizhen (ThunderTown) wrote: > > > On 2020/12/10 11:31, Manivannan Sadhasivam wrote: > > Hi, > > > > On Thu, Dec 10, 2020 at 11:12:03AM +0800, Zhen Lei wrote: > >> For all 96Boards, the following standard is used for onboard LEDs. > >> > >> green:user1 default-trigger: heartbeat > >> green:user2 default-trigger: mmc0/disk-activity(onboard-storage) > >> green:user3 default-trigger: mmc1 (SD-card) > >> green:user4 default-trigger: none, panic-indicator > >> yellow:wlan default-trigger: phy0tx > >> blue:bt default-trigger: hci0-power > >> > >> Link to 96Boards CE Specification: https://linaro.co/ce-specification > >> > > > > This is just a board configuration and there is absolutely no need to > > document > > this in common LED binding. But if your intention is to document the missing > No, I don't think so. The common just means the property linux,default-trigger > is common, but not it values. This can be proved by counter-proving：none of > the triggerrs currently defined in common.yaml is used by 96Boards. > Right, but I was not happy with you mentioning 96Boards in the binding. Because the triggers are used in more platforms other than 96Boards and they are not specific to 96Boards. The documentation of triggers itself is fine. > > triggers, then you should look at the patch I submitted long ago. > > I'm just trying to eliminate the warnings related to Hisilicon that YAML > detected. > So I didn't pay attention to other missing triggers. > No worries :) > > > > https://lore.kernel.org/patchwork/patch/1146359/ > > > > Maybe I should resubmit it again in YAML format. (thanks for reminding me > > :P) > > Yes, I hope that you will resubmit it. After all, these false positives are > entirely due to YAML's failure to list all triggers. The DTS itself is fine. > > By the way, the description of this patch I copied from your patch： > 953d9f390365 arm64: dts: rockchip: Add on-board LED support on rk3399-rock960 > > That's why I Cc to you. > I've now submitted the patch. Please take a look! Thanks, Mani > > > > Thanks, > > Mani > > > >> Signed-off-by: Zhen Lei > >> Cc: Darshak Patel > >> Cc: Manivannan Sadhasivam > >> Cc: Shawn Guo > >> Cc: Dong Aisheng > >> Cc: Guodong Xu > >> Cc: Wei Xu > >> Cc: Linus Walleij > >> Cc: Lad Prabhakar > >> Cc: Marian-Cristian Rotariu > >> Cc: Geert Uytterhoeven > >> Cc: Heiko Stuebner > >> --- > >> Documentation/devicetree/bindings/leds/common.yaml | 10 ++ > >> 1 file changed, 10 insertions(+) > >> > >> diff --git a/Documentation/devicetree/bindings/leds/common.yaml > >> b/Documentation/devicetree/bindings/leds/common.yaml > >> index f1211e7045f12f3..525752d6c5c84fd 100644 > >> --- a/Documentation/devicetree/bindings/leds/common.yaml > >> +++ b/Documentation/devicetree/bindings/leds/common.yaml > >> @@ -97,6 +97,16 @@ properties: > >> # LED alters the brightness for the specified duration with one > >> software > >> # timer (requires "led-pattern" property) > >>- pattern > >> +#For all 96Boards, Green, disk-activity(onboard-storage) > >> + - mmc0 > >> +#For all 96Boards, Green, SD-card > >> + - mmc1 > >> +#For all 96Boards, Green, panic-indicator > >> + - none > >> +#For all 96Boards, Yellow, WiFi activity LED > >> + - phy0tx > >> +#For all 96Boards, Blue, Bluetooth activity LED > >> + - hci0-power > >> > >>led-pattern: > >> description: | > >> -- > >> 1.8.3 > >> > >> > > > > . > > >
Re: [PATCH] [v2] tty: Protect disc_data in n_tty_close and n_tty_flush_buffer
On Thu, Dec 10, 2020 at 10:25:07AM +0800, Yan.Gao wrote: > n_tty_flush_buffer can happen in parallel with n_tty_close that the > tty->disc_data will be set to NULL. n_tty_flush_buffer accesses > tty->disc_data, so we must prevent n_tty_close clear tty->disc_data > while n_tty_flush_buffer has a non-NULL view of tty->disc_data. > > So we need to make sure that accesses to disc_data are atomic using > tty->termios_rwsem. > > There is an example I meet: > When n_tty_flush_buffer accesses tty struct, the disc_data is right. > However, then reset_buffer_flags accesses tty->disc_data, disc_data > become NULL, So kernel crash when accesses tty->disc_data->real_tail. > I guess there could be another thread change tty->disc_data to NULL, > and during N_TTY line discipline, n_tty_close will set tty->disc_data > to be NULL. So use tty->termios_rwsem to protect disc_data between close > and flush_buffer. > > IP: reset_buffer_flags+0x9/0xf0 > PGD 0 P4D 0 > Oops: 0002 [#1] SMP > CPU: 23 PID: 2087626 Comm: (agetty) Kdump: loaded Tainted: G > Hardware name: UNISINSIGHT X3036P-G3/ST01M2C7S, BIOS 2.00.13 01/11/2019 > task: 9c4e9da71e80 task.stack: b30cfe898000 > RIP: 0010:reset_buffer_flags+0x9/0xf0 > RSP: 0018:b30cfe89bca8 EFLAGS: 00010246 > RAX: 9c4e9da71e80 RBX: 9c368d1bac00 RCX: > RDX: RSI: 9c4ea17b50f0 RDI: > RBP: b30cfe89bcc8 R08: 0100 R09: 0001 > R10: 0001 R11: R12: 9c368d1bacc0 > R13: 9c20cfd18428 R14: 9c4ea17b50f0 R15: 9c368d1bac00 > FS: 7f9fbbe97940() GS:9c375c74() > knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 2260 CR3: 002f72233003 CR4: 007606e0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > PKRU: 5554 > Call Trace: > ? n_tty_flush_buffer+0x2a/0x60 > tty_buffer_flush+0x76/0x90 > tty_ldisc_flush+0x22/0x40 > vt_ioctl+0x5a7/0x10b0 > ? n_tty_ioctl_helper+0x27/0x110 > tty_ioctl+0xef/0x8c0 > do_vfs_ioctl+0xa7/0x5e0 > ? __audit_syscall_entry+0xaf/0x100 > ? syscall_trace_enter+0x1d0/0x2b0 > SyS_ioctl+0x79/0x90 > do_syscall_64+0x6c/0x1b0 > entry_SYSCALL64_slow_path+0x25/0x25 > > n_tty_flush_buffer--->tty->disc_data is OK > ->reset_buffer_flags -->tty->disc_data is NULL > > Signed-off-by: Yan.Gao > Reviewed-by: Xianting Tian > --- > drivers/tty/n_tty.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c > index 7e5e36315..e78124ce1 100644 > --- a/drivers/tty/n_tty.c > +++ b/drivers/tty/n_tty.c > @@ -1892,8 +1892,10 @@ static void n_tty_close(struct tty_struct *tty) > if (tty->link) > n_tty_packet_mode_flush(tty); > > + down_write(>termios_rwsem); > vfree(ldata); > tty->disc_data = NULL; > + up_write(>termios_rwsem); > } > > /** So does this solve your problem in testing? Do you have a reproducer for this problem? thanks, greg k-h
Re: "irq 4: Affinity broken due to vector space exhaustion." warning on restart of ttyS0 console
On Wed, Dec 09, 2020 at 07:28:49PM +0100, Thomas Gleixner wrote: > But the fix is not to tone down the warning. The proper fix is to do the > search in the correct order. Agree. Thank you for the speedy fix! Tested-by: Shung-Hsi Yu
Re: [PATCH -next] fs/ntfs: fix set but not used variable 'log_page_mask'
Hi Anton and Andrew, Hi Andrew, Ah, oops! Thank you and apologies. Quite right the alternative patch was even better. No need to apply this patch after all... Zheng, the log_page_mask variable was removed altogether so your patch no longer makes sense. Best regards, Anton On 10 Dec 2020, at 02:36, Andrew Morton wrote: On Tue, 8 Dec 2020 08:24:02 + Anton Altaparmakov wrote: Can you please apply this? ... --- a/fs/ntfs/logfile.c +++ b/fs/ntfs/logfile.c @@ -507,7 +507,7 @@ bool ntfs_check_logfile(struct inode *log_vi, RESTART_PAGE_HEADER **rp) * optimize log_page_size and log_page_bits into constants. */ log_page_bits = ntfs_ffs(log_page_size) - 1; - size &= ~(s64)(log_page_size - 1); + size &= ~(s64)(log_page_mask); /* * Ensure the log file is big enough to store at least the two restart * pages and the minimum number of log record pages. https://lore.kernel.org/lkml/1604821092-54631-1-git-send-email-alex@linux.alibaba.com/ addressed this? It's ok, thank you all the same!
Re: [PATCH] block: blk-iocost: fix build for ARCH with missing local64.h files
On Wed, Dec 09, 2020 at 10:16:20PM -0800, Randy Dunlap wrote: > include/asm-generic/local64.h has comments about some $arch could do > its things better/faster instead of using asm-generic, but no $arch has > done that since 2010 when it was added. > > Is that conclusive? > If it is, why even use mandatory-y? > Why not just change all occurrences of > to ? asm-generic must not be included by non-arch code directly. So the sensible options are either: a) mark it as mandatory-y in include/asm-generic/Kbuild b) rename it to linux/local64.h and fixup all references a) seems much less invasive, but b) might be the better option long term.
Re: [PATCH] block: blk-iocost: fix build for ARCH with missing local64.h files
On 12/9/20 10:07 PM, Christoph Hellwig wrote: > On Wed, Dec 09, 2020 at 12:46:57PM -0800, Randy Dunlap wrote: >> When building block/blk-iocost.c on arch/x6x/ or arch/nios2/, the >> build fails due to missing the file. > > Please mark it mandatory-y if the asm-generic version is suitable > for everyone and random pieces of kernel code are supposed to include > it. include/asm-generic/local64.h has comments about some $arch could do its things better/faster instead of using asm-generic, but no $arch has done that since 2010 when it was added. Is that conclusive? If it is, why even use mandatory-y? Why not just change all occurrences of to ? thanks. -- ~Randy
Re: [PATCH 1/1] dt-bindings: leds: add onboard LED triggers of 96Boards
On 2020/12/10 11:31, Manivannan Sadhasivam wrote: > Hi, > > On Thu, Dec 10, 2020 at 11:12:03AM +0800, Zhen Lei wrote: >> For all 96Boards, the following standard is used for onboard LEDs. >> >> green:user1 default-trigger: heartbeat >> green:user2 default-trigger: mmc0/disk-activity(onboard-storage) >> green:user3 default-trigger: mmc1 (SD-card) >> green:user4 default-trigger: none, panic-indicator >> yellow:wlan default-trigger: phy0tx >> blue:bt default-trigger: hci0-power >> >> Link to 96Boards CE Specification: https://linaro.co/ce-specification >> > > This is just a board configuration and there is absolutely no need to document > this in common LED binding. But if your intention is to document the missing No, I don't think so. The common just means the property linux,default-trigger is common, but not it values. This can be proved by counter-proving：none of the triggerrs currently defined in common.yaml is used by 96Boards. > triggers, then you should look at the patch I submitted long ago. I'm just trying to eliminate the warnings related to Hisilicon that YAML detected. So I didn't pay attention to other missing triggers. > > https://lore.kernel.org/patchwork/patch/1146359/ > > Maybe I should resubmit it again in YAML format. (thanks for reminding me :P) Yes, I hope that you will resubmit it. After all, these false positives are entirely due to YAML's failure to list all triggers. The DTS itself is fine. By the way, the description of this patch I copied from your patch： 953d9f390365 arm64: dts: rockchip: Add on-board LED support on rk3399-rock960 That's why I Cc to you. > > Thanks, > Mani > >> Signed-off-by: Zhen Lei >> Cc: Darshak Patel >> Cc: Manivannan Sadhasivam >> Cc: Shawn Guo >> Cc: Dong Aisheng >> Cc: Guodong Xu >> Cc: Wei Xu >> Cc: Linus Walleij >> Cc: Lad Prabhakar >> Cc: Marian-Cristian Rotariu >> Cc: Geert Uytterhoeven >> Cc: Heiko Stuebner >> --- >> Documentation/devicetree/bindings/leds/common.yaml | 10 ++ >> 1 file changed, 10 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/leds/common.yaml >> b/Documentation/devicetree/bindings/leds/common.yaml >> index f1211e7045f12f3..525752d6c5c84fd 100644 >> --- a/Documentation/devicetree/bindings/leds/common.yaml >> +++ b/Documentation/devicetree/bindings/leds/common.yaml >> @@ -97,6 +97,16 @@ properties: >> # LED alters the brightness for the specified duration with one >> software >> # timer (requires "led-pattern" property) >>- pattern >> +#For all 96Boards, Green, disk-activity(onboard-storage) >> + - mmc0 >> +#For all 96Boards, Green, SD-card >> + - mmc1 >> +#For all 96Boards, Green, panic-indicator >> + - none >> +#For all 96Boards, Yellow, WiFi activity LED >> + - phy0tx >> +#For all 96Boards, Blue, Bluetooth activity LED >> + - hci0-power >> >>led-pattern: >> description: | >> -- >> 1.8.3 >> >> > > . >
[PATCH] dt-bindings: leds: Document commonly used LED triggers
This commit documents the LED triggers used commonly in the SoCs. Not all triggers are documented as some of them are very application specific. Most of the triggers documented here are currently used in devicetrees of many SoCs. Signed-off-by: Manivannan Sadhasivam --- .../devicetree/bindings/leds/common.yaml | 72 ++- 1 file changed, 54 insertions(+), 18 deletions(-) diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml index f1211e7045f1..eee4eb7a4535 100644 --- a/Documentation/devicetree/bindings/leds/common.yaml +++ b/Documentation/devicetree/bindings/leds/common.yaml @@ -79,24 +79,60 @@ properties: the LED. $ref: /schemas/types.yaml#definitions/string -enum: -# LED will act as a back-light, controlled by the framebuffer system - - backlight -# LED will turn on (but for leds-gpio see "default-state" property in -# Documentation/devicetree/bindings/leds/leds-gpio.yaml) - - default-on -# LED "double" flashes at a load average based rate - - heartbeat -# LED indicates disk activity - - disk-activity -# LED indicates IDE disk activity (deprecated), in new implementations -# use "disk-activity" - - ide-disk -# LED flashes at a fixed, configurable rate - - timer -# LED alters the brightness for the specified duration with one software -# timer (requires "led-pattern" property) - - pattern +oneOf: + - items: + - enum: +# LED will act as a back-light, controlled by the framebuffer system + - backlight +# LED will turn on (but for leds-gpio see "default-state" property in +# Documentation/devicetree/bindings/leds/leds-gpio.yaml) + - default-on +# LED "double" flashes at a load average based rate + - heartbeat +# LED indicates disk activity + - disk-activity +# LED indicates IDE disk activity (deprecated), in new implementations +# use "disk-activity" + - ide-disk +# LED flashes at a fixed, configurable rate + - timer +# LED alters the brightness for the specified duration with one software +# timer (requires "led-pattern" property) + - pattern +# LED indicates camera flash state + - flash +# LED indicates camera torch state + - torch +# LED indicates audio mute state + - audio-mute +# LED indicates mic mute state + - audio-micmute +# LED indicates bluetooth power state + - bluetooth-power +# LED indicates USB gadget activity + - usb-gadget +# LED indicates USB host activity + - usb-host +# LED indicates MTD memory activity + - mtd +# LED indicates NAND memory activity (deprecated), +# in new implementations use "mtd" + - nand-disk +# LED indicates disk read activity + - disk-read +# LED indicates disk write activity + - disk-write +# No trigger assigned to the LED. This is the default mode +# if trigger is absent + - none +# LED indicates activity of all CPUs + - cpu + - items: +# LED indicates activity of [N]th CPU + - pattern: "^cpu[0-9][0-9]$" + - items: +# LED indicates [N]th MMC storage activity + - pattern: '^mmc[0-9][0-9]$' led-pattern: description: | -- 2.25.1
Re: [PATCH 1/2] Input: elan_i2c - Add new trackpoint report type 0x5F.
Hi Jingle,
On Mon, Dec 07, 2020 at 05:07:51PM +0800, jingle.wu wrote:
> The 0x5F is new trackpoint report type of some module.
>
> Signed-off-by: Jingle Wu
> ---
> drivers/input/mouse/elan_i2c_core.c | 2 ++
> drivers/input/mouse/elan_i2c_smbus.c | 3 ++-
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/mouse/elan_i2c_core.c
> b/drivers/input/mouse/elan_i2c_core.c
> index 61ed3f5ca219..8f0c4663167c 100644
> --- a/drivers/input/mouse/elan_i2c_core.c
> +++ b/drivers/input/mouse/elan_i2c_core.c
> @@ -52,6 +52,7 @@
> #define ETP_REPORT_ID0x5D
> #define ETP_REPORT_ID2 0x60/* High precision report */
> #define ETP_TP_REPORT_ID 0x5E
> +#define ETP_TP_REPORT_ID20x5F
> #define ETP_REPORT_ID_OFFSET 2
> #define ETP_TOUCH_INFO_OFFSET3
> #define ETP_FINGER_DATA_OFFSET 4
I think we might need to move this into elan_i2c.h so that we can
reference it from elan_i2c_smbus.c.
> @@ -1076,6 +1077,7 @@ static irqreturn_t elan_isr(int irq, void *dev_id)
> elan_report_absolute(data, report, true);
> break;
> case ETP_TP_REPORT_ID:
> + case ETP_TP_REPORT_ID2:
> elan_report_trackpoint(data, report);
> break;
> default:
> diff --git a/drivers/input/mouse/elan_i2c_smbus.c
> b/drivers/input/mouse/elan_i2c_smbus.c
> index 1820f1cfc1dc..1226d47ec3cf 100644
> --- a/drivers/input/mouse/elan_i2c_smbus.c
> +++ b/drivers/input/mouse/elan_i2c_smbus.c
> @@ -45,6 +45,7 @@
> #define ETP_SMBUS_CALIBRATE_QUERY0xC5
>
> #define ETP_SMBUS_REPORT_LEN 32
> +#define ETP_SMBUS_REPORT_LEN27
> #define ETP_SMBUS_REPORT_OFFSET 2
> #define ETP_SMBUS_HELLOPACKET_LEN5
> #define ETP_SMBUS_IAP_PASSWORD 0x1234
> @@ -497,7 +498,7 @@ static int elan_smbus_get_report(struct i2c_client
> *client,
> return len;
> }
>
> - if (len != ETP_SMBUS_REPORT_LEN) {
> + if ((len != ETP_SMBUS_REPORT_LEN) && (len != ETP_SMBUS_REPORT_LEN2)) {
I would prefer if we validated report length versus the packet type
before accepting it.
> dev_err(>dev,
> "wrong report length (%d vs %d expected)\n",
> len, ETP_SMBUS_REPORT_LEN);
> --
> 2.17.1
>
Thanks.
--
Dmitry
Re: [PATCH] files: rcu free files_struct
On Wed, Dec 09, 2020 at 03:32:38PM -0600, Eric W. Biederman wrote:
> Al Viro writes:
>
> > On Wed, Dec 09, 2020 at 11:13:38AM -0800, Linus Torvalds wrote:
> >> On Wed, Dec 9, 2020 at 10:05 AM Eric W. Biederman
> >> wrote:
> >> >
> >> > - struct file * file = xchg(>fd[i],
> >> > NULL);
> >> > + struct file * file = fdt->fd[i];
> >> > if (file) {
> >> > + rcu_assign_pointer(fdt->fd[i],
> >> > NULL);
> >>
> >> This makes me nervous. Why did we use to do that xchg() there? That
> >> has atomicity guarantees that now are gone.
> >>
> >> Now, this whole thing should be called for just the last ref of the fd
> >> table, so presumably that atomicity was never needed in the first
> >> place. But the fact that we did that very expensive xchg() then makes
> >> me go "there's some reason for it".
> >>
> >> Is this xchg() just bogus historical leftover? It kind of looks that
> >> way. But maybe that change should be done separately?
> >
> > I'm still not convinced that exposing close_files() to parallel
> > 3rd-party accesses is safe in all cases, so this patch still needs
> > more analysis.
>
> That is fine. I just wanted to post the latest version so we could
> continue the discussion. Especially with comments etc.
It's probably safe. I've spent today digging through the mess in
fs/notify and kernel/bpf, and while I'm disgusted with both, at
that point I believe that close_files() exposure is not going to
create problems with either. And xchg() in there _is_ useless.
Said that, BPF "file iterator" stuff is potentially very unpleasant -
it allows to pin a struct file found in any process' descriptor table
indefinitely long. Temporary struct file references grabbed by procfs
code, while unfortunate, are at least short-lived; with this stuff sky's
the limit.
I'm not happy about having that available, especially if it's a user-visible
primitive we can't withdraw at zero notice ;-/
What are the users of that thing and is there any chance to replace it
with something saner? IOW, what *is* realistically called for each
struct file by the users of that iterator?
[PATCH 2/2] perf evlist: Support pipe mode display
Likewise, perf evlist command should print event attributes by reading
PERF_RECORD_HEADER_ATTR records.
Before:
$ perf record -o- true | ./perf evlist -i-
(prints nothing)
After:
$ perf record -o- true | ./perf evlist -i-
cycles:pppH
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-evlist.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-evlist.c b/tools/perf/builtin-evlist.c
index 98e992801251..4617b32c9c97 100644
--- a/tools/perf/builtin-evlist.c
+++ b/tools/perf/builtin-evlist.c
@@ -17,6 +17,14 @@
#include "util/data.h"
#include "util/debug.h"
#include
+#include "util/tool.h"
+
+static int process_header_feature(struct perf_session *session __maybe_unused,
+ union perf_event *event __maybe_unused)
+{
+ session_done = 1;
+ return 0;
+}
static int __cmd_evlist(const char *file_name, struct perf_attr_details
*details)
{
@@ -27,12 +35,20 @@ static int __cmd_evlist(const char *file_name, struct
perf_attr_details *details
.mode = PERF_DATA_MODE_READ,
.force = details->force,
};
+ struct perf_tool tool = {
+ /* only needed for pipe mode */
+ .attr = perf_event__process_attr,
+ .feature = process_header_feature,
+ };
bool has_tracepoint = false;
- session = perf_session__new(, 0, NULL);
+ session = perf_session__new(, 0, );
if (IS_ERR(session))
return PTR_ERR(session);
+ if (data.is_pipe)
+ perf_session__process_events(session);
+
evlist__for_each_entry(session->evlist, pos) {
evsel__fprintf(pos, details, stdout);
--
2.29.2.576.ga3fc446d84-goog
[PATCH 1/2] perf report: Support --header-only for pipe mode
The --header-only checks file header and prints the feature data. But
as pipe mode doesn't have it in the header it prints almost nothing.
Change it to process first few records until it founds HEADER_FEATURE.
Before:
$ perf record -o- true | perf report -i- --header-only
#
# captured on: Thu Dec 10 14:34:59 2020
# header version : 1
# data offset: 0
# data size : 0
# feat offset: 0
#
#
After:
$ perf record -o- true | perf report -i- --header-only
#
# captured on: Thu Dec 10 14:49:11 2020
# header version : 1
# data offset: 0
# data size : 0
# feat offset: 0
#
#
# hostname : balhae
# os release : 5.7.17-1xxx
# perf version : 5.10.rc6.gdb0ea13cc741
# arch : x86_64
# nrcpus online : 8
# nrcpus avail : 8
# cpudesc : Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz
# cpuid : GenuineIntel,6,142,12
# total memory : 16158916 kB
# cmdline : perf record -o- true
# event : name = cycles, , id = { 81, 82, 83, 84, 85, 86, 87, 88 }, size =
120, ...
# CPU_TOPOLOGY info available, use -I to display
# NUMA_TOPOLOGY info available, use -I to display
# pmu mappings: intel_pt = 9, intel_bts = 8, software = 1, power = 20, uprobe
= 7, ...
# time of first sample : 0.00
# time of last sample : 0.00
# sample duration : 0.000 ms
# MEM_TOPOLOGY info available, use -I to display
# cpu pmu capabilities: branches=32, max_precise=3, pmu_name=skylake
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-report.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 5efbd0602f17..2a845d6cac09 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -226,6 +226,8 @@ static int process_feature_event(struct perf_session
*session,
pr_err("failed: wrong feature ID: %" PRI_lu64 "\n",
event->feat.feat_id);
return -1;
+ } else if (rep->header_only) {
+ session_done = 1;
}
/*
@@ -1512,6 +1514,13 @@ int cmd_report(int argc, const char **argv)
perf_session__fprintf_info(session, stdout,
report.show_full_info);
if (report.header_only) {
+ if (data.is_pipe) {
+ /*
+* we need to process first few records
+* which contains PERF_RECORD_HEADER_FEATURE.
+*/
+ perf_session__process_events(session);
+ }
ret = 0;
goto error;
}
--
2.29.2.576.ga3fc446d84-goog
Re: [PATCH] usb: cdns3: Fixed kernel test robot warning
On Thu, Dec 10, 2020 at 01:45:52AM +0530, Souptick Joarder wrote:
> Kernel test robot throws below warning ->
>
> In file included from drivers/usb/cdns3/core.c:23:
> >> drivers/usb/cdns3/host-export.h:27:51: warning: 'struct usb_hcd'
> >> declared inside parameter list will not be visible outside of this
> >> definition or declaration
> 27 | static inline int xhci_cdns3_suspend_quirk(struct usb_hcd
> *hcd)
> | ^~~
>
> This patch will silence it.
>
> Reported-by: kernel test robot
> Signed-off-by: Souptick Joarder
> ---
> drivers/usb/cdns3/host-export.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/cdns3/host-export.h b/drivers/usb/cdns3/host-export.h
> index fb8541b..c1259af 100644
> --- a/drivers/usb/cdns3/host-export.h
> +++ b/drivers/usb/cdns3/host-export.h
> @@ -24,7 +24,7 @@ static inline int cdns_host_init(struct cdns *cdns)
> }
>
> static inline void cdns_host_exit(struct cdns *cdns) { }
> -static inline int xhci_cdns3_suspend_quirk(struct usb_hcd *hcd)
> +static int xhci_cdns3_suspend_quirk(struct usb_hcd *hcd)
That should not change anything for this warning, sorry.
Re: [PATCH v2 3/5] dt-bindings: clock: Add SM8350 GCC clock bindings
On 09-12-20, 22:01, Rob Herring wrote: > On Tue, Dec 08, 2020 at 12:17:00PM +0530, Vinod Koul wrote: > > +required: > > + - compatible > > + - clocks > > + - clock-names > > + - reg > > + - '#clock-cells' > > + - '#reset-cells' > > You may or may not have power domains? I have not added them in the driver yet, so I dont think it made sense to add them when they are not present. For basic stuff it is not required but eventually yes, so I plan to update binding and driver at that time -- ~Vinod
[PATCH 2/2] platform/chrome: cros_ec_typec: Send mux configuration acknowledgment to EC
In some corner cases downgrade of the superspeed typec device(e.g. Dell
typec Dock, apple dongle) was seen because before the SOC mux configuration
finishes, EC starts configuring the next mux state.
With this change, once the SOC mux is configured, kernel will send an
acknowledgment to EC via Host command EC_CMD_USB_PD_MUX_ACK [1].
After sending the host event EC will wait for the acknowledgment from
kernel before starting the PD negotiation for the next mux state. This
helps to have a framework to build better error handling along with the
synchronization of timing sensitive mux states.
This change also brings in corresponding EC header updates from the EC code
base [1].
[1]:
https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/master/include/ec_commands.h
Signed-off-by: Utkarsh Patel
---
drivers/platform/chrome/cros_ec_typec.c| 16
include/linux/platform_data/cros_ec_commands.h | 17 +
2 files changed, 33 insertions(+)
diff --git a/drivers/platform/chrome/cros_ec_typec.c
b/drivers/platform/chrome/cros_ec_typec.c
index 650aa5332055..e6abe205890c 100644
--- a/drivers/platform/chrome/cros_ec_typec.c
+++ b/drivers/platform/chrome/cros_ec_typec.c
@@ -74,6 +74,7 @@ struct cros_typec_data {
struct notifier_block nb;
struct work_struct port_work;
bool typec_cmd_supported;
+ bool needs_mux_ack;
};
static int cros_typec_parse_port_props(struct typec_capability *cap,
@@ -503,6 +504,7 @@ static int cros_typec_configure_mux(struct cros_typec_data
*typec, int port_num,
struct ec_response_usb_pd_control_v2 *pd_ctrl)
{
struct cros_typec_port *port = typec->ports[port_num];
+ struct ec_params_usb_pd_mux_ack mux_ack;
enum typec_orientation orientation;
int ret;
@@ -543,6 +545,18 @@ static int cros_typec_configure_mux(struct cros_typec_data
*typec, int port_num,
ret = -ENOTSUPP;
}
+ if (!typec->needs_mux_ack)
+ return ret;
+
+ /* Sending Acknowledgment to EC */
+ mux_ack.port = port_num;
+
+ if (cros_typec_ec_command(typec, 0, EC_CMD_USB_PD_MUX_ACK, _ack,
+ sizeof(mux_ack), NULL, 0) < 0)
+ dev_warn(typec->dev,
+"Failed to send Mux ACK to EC for port: %d\n",
+port_num);
+
return ret;
}
@@ -908,6 +922,8 @@ static int cros_typec_probe(struct platform_device *pdev)
typec->typec_cmd_supported = !!cros_typec_feature_supported(typec,
EC_FEATURE_TYPEC_CMD);
+ typec->needs_mux_ack = !!cros_typec_feature_supported(typec,
+ EC_FEATURE_TYPEC_MUX_REQUIRE_AP_ACK);
ret = cros_typec_ec_command(typec, 0, EC_CMD_USB_PD_PORTS, NULL, 0,
, sizeof(resp));
diff --git a/include/linux/platform_data/cros_ec_commands.h
b/include/linux/platform_data/cros_ec_commands.h
index 7f54fdcdd8cb..3b53e45cb5a0 100644
--- a/include/linux/platform_data/cros_ec_commands.h
+++ b/include/linux/platform_data/cros_ec_commands.h
@@ -1286,6 +1286,16 @@ enum ec_feature_code {
EC_FEATURE_ISH = 40,
/* New TCPMv2 TYPEC_ prefaced commands supported */
EC_FEATURE_TYPEC_CMD = 41,
+ /*
+* The EC will wait for direction from the AP to enter Type-C alternate
+* modes or USB4.
+*/
+ EC_FEATURE_TYPEC_REQUIRE_AP_MODE_ENTRY = 42,
+ /*
+* The EC will wait for an acknowledge from the AP after setting the
+* mux.
+*/
+ EC_FEATURE_TYPEC_MUX_REQUIRE_AP_ACK = 43,
};
#define EC_FEATURE_MASK_0(event_code) BIT(event_code % 32)
@@ -6054,6 +6064,13 @@ struct ec_params_charger_control {
uint8_t allow_charging;
} __ec_align_size1;
+/* Get ACK from the USB-C SS muxes */
+#define EC_CMD_USB_PD_MUX_ACK 0x0603
+
+struct ec_params_usb_pd_mux_ack {
+ uint8_t port; /* USB-C port number */
+} __ec_align1;
+
/*/
/*
* Reserve a range of host commands for board-specific, experimental, or
--
2.25.1
[PATCH 0/2] Send acknowledgment to ec from cors_ec_typec
This adds mechanism of sending mux configuration acknowledgment from kernel to EC. It also modifies cros_typec_cmds_supported() to support multiple feature flags. Utkarsh Patel (2): platform/chrome: cros_ec_typec: Parameterize cros_typec_cmds_supported() platform/chrome: cros_ec_typec: Send mux configuration acknowledgment to EC drivers/platform/chrome/cros_ec_typec.c | 28 +++ .../linux/platform_data/cros_ec_commands.h| 17 +++ 2 files changed, 40 insertions(+), 5 deletions(-) -- 2.25.1
[PATCH 1/2] platform/chrome: cros_ec_typec: Parameterize cros_typec_cmds_supported()
cros_typec_cmds_supported() is currently being used to check only one
feature flag.
Add a new feature parameter to it so that it can be used to check
multiple feature flags supported in cros_ec.
Rename cros_typec_cmds_supported() to cros_typec_feature_supported().
Signed-off-by: Utkarsh Patel
---
drivers/platform/chrome/cros_ec_typec.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_typec.c
b/drivers/platform/chrome/cros_ec_typec.c
index ce031a10eb1b..650aa5332055 100644
--- a/drivers/platform/chrome/cros_ec_typec.c
+++ b/drivers/platform/chrome/cros_ec_typec.c
@@ -829,8 +829,8 @@ static int cros_typec_get_cmd_version(struct
cros_typec_data *typec)
return 0;
}
-/* Check the EC feature flags to see if TYPEC_* commands are supported. */
-static int cros_typec_cmds_supported(struct cros_typec_data *typec)
+/* Check the EC feature flags to see if TYPEC_* features are supported. */
+static int cros_typec_feature_supported(struct cros_typec_data *typec, enum
ec_feature_code feature)
{
struct ec_response_get_features resp = {};
int ret;
@@ -839,11 +839,12 @@ static int cros_typec_cmds_supported(struct
cros_typec_data *typec)
, sizeof(resp));
if (ret < 0) {
dev_warn(typec->dev,
-"Failed to get features, assuming typec commands
unsupported.\n");
+"Failed to get features, assuming typec feature=%d
unsupported.\n",
+feature);
return 0;
}
- return resp.flags[EC_FEATURE_TYPEC_CMD / 32] &
EC_FEATURE_MASK_1(EC_FEATURE_TYPEC_CMD);
+ return resp.flags[feature / 32] & EC_FEATURE_MASK_1(feature);
}
static void cros_typec_port_work(struct work_struct *work)
@@ -905,7 +906,8 @@ static int cros_typec_probe(struct platform_device *pdev)
return ret;
}
- typec->typec_cmd_supported = !!cros_typec_cmds_supported(typec);
+ typec->typec_cmd_supported = !!cros_typec_feature_supported(typec,
+ EC_FEATURE_TYPEC_CMD);
ret = cros_typec_ec_command(typec, 0, EC_CMD_USB_PD_PORTS, NULL, 0,
, sizeof(resp));
--
2.25.1
Re: [PATCH] block: blk-iocost: fix build for ARCH with missing local64.h files
On Wed, Dec 09, 2020 at 12:46:57PM -0800, Randy Dunlap wrote: > When building block/blk-iocost.c on arch/x6x/ or arch/nios2/, the > build fails due to missing the file. Please mark it mandatory-y if the asm-generic version is suitable for everyone and random pieces of kernel code are supposed to include it.
[PATCH v12 2/5] leds: flash: Fix multicolor no-ops registration by return 0
From: Gene Chen
Fix multicolor no-ops registration by return 0,
and move the same registration functions outside of #ifdef block.
Signed-off-by: Gene Chen
Acked-by: Jacek Anaszewski
---
include/linux/led-class-multicolor.h | 42 +---
1 file changed, 15 insertions(+), 27 deletions(-)
diff --git a/include/linux/led-class-multicolor.h
b/include/linux/led-class-multicolor.h
index 5116f9a..210d57b 100644
--- a/include/linux/led-class-multicolor.h
+++ b/include/linux/led-class-multicolor.h
@@ -44,12 +44,6 @@ int led_classdev_multicolor_register_ext(struct device
*parent,
struct led_classdev_mc *mcled_cdev,
struct led_init_data *init_data);
-static inline int led_classdev_multicolor_register(struct device *parent,
- struct led_classdev_mc *mcled_cdev)
-{
- return led_classdev_multicolor_register_ext(parent, mcled_cdev, NULL);
-}
-
/**
* led_classdev_multicolor_unregister - unregisters an object of led_classdev
* class with support for multicolor LEDs
@@ -68,13 +62,6 @@ int devm_led_classdev_multicolor_register_ext(struct device
*parent,
struct led_classdev_mc *mcled_cdev,
struct led_init_data *init_data);
-static inline int devm_led_classdev_multicolor_register(struct device *parent,
-struct led_classdev_mc *mcled_cdev)
-{
- return devm_led_classdev_multicolor_register_ext(parent, mcled_cdev,
-NULL);
-}
-
void devm_led_classdev_multicolor_unregister(struct device *parent,
struct led_classdev_mc *mcled_cdev);
#else
@@ -83,27 +70,33 @@ static inline int
led_classdev_multicolor_register_ext(struct device *parent,
struct led_classdev_mc *mcled_cdev,
struct led_init_data *init_data)
{
- return -EINVAL;
-}
-
-static inline int led_classdev_multicolor_register(struct device *parent,
- struct led_classdev_mc *mcled_cdev)
-{
- return led_classdev_multicolor_register_ext(parent, mcled_cdev, NULL);
+ return 0;
}
static inline void led_classdev_multicolor_unregister(struct led_classdev_mc
*mcled_cdev) {};
static inline int led_mc_calc_color_components(struct led_classdev_mc
*mcled_cdev,
enum led_brightness brightness)
{
- return -EINVAL;
+ return 0;
}
static inline int devm_led_classdev_multicolor_register_ext(struct device
*parent,
struct led_classdev_mc *mcled_cdev,
struct led_init_data *init_data)
{
- return -EINVAL;
+ return 0;
+}
+
+static inline void devm_led_classdev_multicolor_unregister(struct device
*parent,
+ struct led_classdev_mc *mcled_cdev)
+{};
+
+#endif /* IS_ENABLED(CONFIG_LEDS_CLASS_MULTICOLOR) */
+
+static inline int led_classdev_multicolor_register(struct device *parent,
+ struct led_classdev_mc *mcled_cdev)
+{
+ return led_classdev_multicolor_register_ext(parent, mcled_cdev, NULL);
}
static inline int devm_led_classdev_multicolor_register(struct device *parent,
@@ -113,9 +106,4 @@ static inline int
devm_led_classdev_multicolor_register(struct device *parent,
NULL);
}
-static inline void devm_led_classdev_multicolor_unregister(struct device
*parent,
- struct led_classdev_mc *mcled_cdev)
-{};
-
-#endif /* IS_ENABLED(CONFIG_LEDS_CLASS_MULTICOLOR) */
#endif /* _LINUX_MULTICOLOR_LEDS_H_INCLUDED */
--
2.7.4
[PATCH] [v2] blk-mq-tag: make blk_mq_tag_busy() return void
As no one cares about the return value of blk_mq_tag_busy() and
__blk_mq_tag_busy(), so make them return void.
Other change is to simplify blk_mq_tag_idle().
Signed-off-by: Xianting Tian
Reviewed-by: Ming Lei
---
block/blk-mq-tag.c | 4 ++--
block/blk-mq-tag.h | 16 ++--
2 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
index 9c92053e7..21ff7d156 100644
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -21,7 +21,7 @@
* to get tag when first time, the other shared-tag users could reserve
* budget for it.
*/
-bool __blk_mq_tag_busy(struct blk_mq_hw_ctx *hctx)
+void __blk_mq_tag_busy(struct blk_mq_hw_ctx *hctx)
{
if (blk_mq_is_sbitmap_shared(hctx->flags)) {
struct request_queue *q = hctx->queue;
@@ -36,7 +36,7 @@ bool __blk_mq_tag_busy(struct blk_mq_hw_ctx *hctx)
atomic_inc(>tags->active_queues);
}
- return true;
+ return;
}
/*
diff --git a/block/blk-mq-tag.h b/block/blk-mq-tag.h
index 7d3e6b333..4b4ccd794 100644
--- a/block/blk-mq-tag.h
+++ b/block/blk-mq-tag.h
@@ -60,23 +60,19 @@ enum {
BLK_MQ_TAG_MAX = BLK_MQ_NO_TAG - 1,
};
-extern bool __blk_mq_tag_busy(struct blk_mq_hw_ctx *);
+extern void __blk_mq_tag_busy(struct blk_mq_hw_ctx *);
extern void __blk_mq_tag_idle(struct blk_mq_hw_ctx *);
-static inline bool blk_mq_tag_busy(struct blk_mq_hw_ctx *hctx)
+static inline void blk_mq_tag_busy(struct blk_mq_hw_ctx *hctx)
{
- if (!(hctx->flags & BLK_MQ_F_TAG_QUEUE_SHARED))
- return false;
-
- return __blk_mq_tag_busy(hctx);
+ if (hctx->flags & BLK_MQ_F_TAG_QUEUE_SHARED)
+ __blk_mq_tag_busy(hctx);
}
static inline void blk_mq_tag_idle(struct blk_mq_hw_ctx *hctx)
{
- if (!(hctx->flags & BLK_MQ_F_TAG_QUEUE_SHARED))
- return;
-
- __blk_mq_tag_idle(hctx);
+ if (hctx->flags & BLK_MQ_F_TAG_QUEUE_SHARED)
+ __blk_mq_tag_idle(hctx);
}
static inline bool blk_mq_tag_is_reserved(struct blk_mq_tags *tags,
--
2.17.1
[PATCH v12 5/5] leds: mt6360: Add LED driver for MT6360
From: Gene Chen
Add MT6360 LED driver include 2-channel Flash LED with torch/strobe mode,
3-channel RGB LED support Register/Flash/Breath Mode, and 1-channel for
moonlight LED.
Signed-off-by: Gene Chen
---
drivers/leds/Kconfig | 13 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-mt6360.c | 827 +
3 files changed, 841 insertions(+)
create mode 100644 drivers/leds/leds-mt6360.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 1c181df..4f533bc 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -271,6 +271,19 @@ config LEDS_MT6323
This option enables support for on-chip LED drivers found on
Mediatek MT6323 PMIC.
+config LEDS_MT6360
+ tristate "LED Support for Mediatek MT6360 PMIC"
+ depends on LEDS_CLASS && OF
+ depends on LEDS_CLASS_FLASH || !LEDS_CLASS_FLASH
+ depends on LEDS_CLASS_MULTICOLOR || !LEDS_CLASS_MULTICOLOR
+ depends on V4L2_FLASH_LED_CLASS || !V4L2_FLASH_LED_CLASS
+ depends on MFD_MT6360
+ help
+ This option enables support for dual Flash LED drivers found on
+ Mediatek MT6360 PMIC.
+ Independent current sources supply for each flash LED support torch
+ and strobe mode.
+
config LEDS_S3C24XX
tristate "LED Support for Samsung S3C24XX GPIO LEDs"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index c2c7d7a..5596427 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_LEDS_MIKROTIK_RB532) += leds-rb532.o
obj-$(CONFIG_LEDS_MLXCPLD) += leds-mlxcpld.o
obj-$(CONFIG_LEDS_MLXREG) += leds-mlxreg.o
obj-$(CONFIG_LEDS_MT6323) += leds-mt6323.o
+obj-$(CONFIG_LEDS_MT6360) += leds-mt6360.o
obj-$(CONFIG_LEDS_NET48XX) += leds-net48xx.o
obj-$(CONFIG_LEDS_NETXBIG) += leds-netxbig.o
obj-$(CONFIG_LEDS_NIC78BX) += leds-nic78bx.o
diff --git a/drivers/leds/leds-mt6360.c b/drivers/leds/leds-mt6360.c
new file mode 100644
index 000..42d18a8
--- /dev/null
+++ b/drivers/leds/leds-mt6360.c
@@ -0,0 +1,827 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum {
+ MT6360_LED_ISNK1 = 0,
+ MT6360_LED_ISNK2,
+ MT6360_LED_ISNK3,
+ MT6360_LED_ISNKML,
+ MT6360_LED_FLASH1,
+ MT6360_LED_FLASH2,
+ MT6360_MAX_LEDS
+};
+
+#define MT6360_REG_RGBEN 0x380
+#define MT6360_REG_ISNK(_led_no) (0x381 + (_led_no))
+#define MT6360_ISNK_ENMASK(_led_no)BIT(7 - (_led_no))
+#define MT6360_ISNK_MASK GENMASK(4, 0)
+#define MT6360_CHRINDSEL_MASK BIT(3)
+
+/* Virtual definition for multicolor */
+#define MT6360_VIRTUAL_MULTICOLOR (MT6360_MAX_LEDS + 1)
+#define MULTICOLOR_NUM_CHANNELS3
+
+#define MT6360_REG_FLEDEN 0x37E
+#define MT6360_REG_STRBTO 0x373
+#define MT6360_REG_FLEDBASE(_id) (0x372 + 4 * (_id - MT6360_LED_FLASH1))
+#define MT6360_REG_FLEDISTRB(_id) (MT6360_REG_FLEDBASE(_id) + 2)
+#define MT6360_REG_FLEDITOR(_id) (MT6360_REG_FLEDBASE(_id) + 3)
+#define MT6360_REG_CHGSTAT20x3E1
+#define MT6360_REG_FLEDSTAT1 0x3E9
+#define MT6360_ITORCH_MASK GENMASK(4, 0)
+#define MT6360_ISTROBE_MASKGENMASK(6, 0)
+#define MT6360_STRBTO_MASK GENMASK(6, 0)
+#define MT6360_TORCHEN_MASKBIT(3)
+#define MT6360_STROBEN_MASKBIT(2)
+#define MT6360_FLCSEN_MASK(_id)BIT(MT6360_LED_FLASH2 - _id)
+#define MT6360_FLEDCHGVINOVP_MASK BIT(3)
+#define MT6360_FLED1STRBTO_MASKBIT(11)
+#define MT6360_FLED2STRBTO_MASKBIT(10)
+#define MT6360_FLED1STRB_MASK BIT(9)
+#define MT6360_FLED2STRB_MASK BIT(8)
+#define MT6360_FLED1SHORT_MASK BIT(7)
+#define MT6360_FLED2SHORT_MASK BIT(6)
+#define MT6360_FLEDLVF_MASKBIT(3)
+
+#define MT6360_ISNKRGB_STEPUA 2000
+#define MT6360_ISNKRGB_MAXUA 24000
+#define MT6360_ISNKML_STEPUA 5000
+#define MT6360_ISNKML_MAXUA15
+
+#define MT6360_ITORCH_MINUA25000
+#define MT6360_ITORCH_STEPUA 12500
+#define MT6360_ITORCH_MAXUA40
+#define MT6360_ISTRB_MINUA 5
+#define MT6360_ISTRB_STEPUA12500
+#define MT6360_ISTRB_MAXUA 150
+#define MT6360_STRBTO_MINUS64000
+#define MT6360_STRBTO_STEPUS 32000
+#define MT6360_STRBTO_MAXUS2432000
+
+#define STATE_OFF 0
+#define STATE_KEEP 1
+#define STATE_ON 2
+
+struct mt6360_led {
+ union {
+ struct led_classdev isnk;
+ struct led_classdev_mc
[PATCH v12 1/5] leds: flash: Add flash registration with undefined CONFIG_LEDS_CLASS_FLASH
From: Gene Chen
Add flash registration with undefined CONFIG_LEDS_CLASS_FLASH,
and move the same registration functions outside of #ifdef block.
Signed-off-by: Gene Chen
Acked-by: Jacek Anaszewski
---
include/linux/led-class-flash.h | 42 -
1 file changed, 33 insertions(+), 9 deletions(-)
diff --git a/include/linux/led-class-flash.h b/include/linux/led-class-flash.h
index 21a3358..612b4ca 100644
--- a/include/linux/led-class-flash.h
+++ b/include/linux/led-class-flash.h
@@ -85,6 +85,7 @@ static inline struct led_classdev_flash *lcdev_to_flcdev(
return container_of(lcdev, struct led_classdev_flash, led_cdev);
}
+#if IS_ENABLED(CONFIG_LEDS_CLASS_FLASH)
/**
* led_classdev_flash_register_ext - register a new object of LED class with
* init data and with support for flash LEDs
@@ -98,12 +99,6 @@ int led_classdev_flash_register_ext(struct device *parent,
struct led_classdev_flash *fled_cdev,
struct led_init_data *init_data);
-static inline int led_classdev_flash_register(struct device *parent,
- struct led_classdev_flash *fled_cdev)
-{
- return led_classdev_flash_register_ext(parent, fled_cdev, NULL);
-}
-
/**
* led_classdev_flash_unregister - unregisters an object of led_classdev class
*with support for flash LEDs
@@ -118,15 +113,44 @@ int devm_led_classdev_flash_register_ext(struct device
*parent,
struct led_init_data *init_data);
+void devm_led_classdev_flash_unregister(struct device *parent,
+ struct led_classdev_flash *fled_cdev);
+
+#else
+
+static inline int led_classdev_flash_register_ext(struct device *parent,
+ struct led_classdev_flash *fled_cdev,
+ struct led_init_data *init_data)
+{
+ return 0;
+}
+
+static inline void led_classdev_flash_unregister(struct led_classdev_flash
*fled_cdev) {};
+static inline int devm_led_classdev_flash_register_ext(struct device *parent,
+struct led_classdev_flash *fled_cdev,
+struct led_init_data *init_data)
+{
+ return 0;
+}
+
+static inline void devm_led_classdev_flash_unregister(struct device *parent,
+ struct led_classdev_flash *fled_cdev)
+{};
+
+#endif /* IS_ENABLED(CONFIG_LEDS_CLASS_FLASH) */
+
+static inline int led_classdev_flash_register(struct device *parent,
+ struct led_classdev_flash *fled_cdev)
+{
+ return led_classdev_flash_register_ext(parent, fled_cdev, NULL);
+}
+
static inline int devm_led_classdev_flash_register(struct device *parent,
struct led_classdev_flash *fled_cdev)
{
return devm_led_classdev_flash_register_ext(parent, fled_cdev, NULL);
}
-void devm_led_classdev_flash_unregister(struct device *parent,
- struct led_classdev_flash *fled_cdev);
-
/**
* led_set_flash_strobe - setup flash strobe
* @fled_cdev: the flash LED to set strobe on
--
2.7.4
[PATCH v12 4/5] dt-bindings: leds: Add bindings for MT6360 LED
From: Gene Chen
Add bindings document for LED support on MT6360 PMIC
Signed-off-by: Gene Chen
---
.../devicetree/bindings/leds/leds-mt6360.yaml | 159 +
1 file changed, 159 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-mt6360.yaml
diff --git a/Documentation/devicetree/bindings/leds/leds-mt6360.yaml
b/Documentation/devicetree/bindings/leds/leds-mt6360.yaml
new file mode 100644
index 000..cb1f4b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-mt6360.yaml
@@ -0,0 +1,159 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-mt6360.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LED driver for MT6360 PMIC from MediaTek Integrated.
+
+maintainers:
+ - Gene Chen
+
+description: |
+ This module is part of the MT6360 MFD device.
+ see Documentation/devicetree/bindings/mfd/mt6360.yaml
+ Add MT6360 LED driver include 2-channel Flash LED with torch/strobe mode,
+ and 4-channel RGB LED support Register/Flash/Breath Mode
+
+properties:
+ compatible:
+const: mediatek,mt6360-led
+
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+patternProperties:
+ "^(multi-)?led@[0-5]$":
+type: object
+$ref: common.yaml#
+description:
+ Properties for a single LED.
+
+properties:
+ reg:
+description: Index of the LED.
+enum:
+ - 0 # LED output ISINK1
+ - 1 # LED output ISINK2
+ - 2 # LED output ISINK3
+ - 3 # LED output ISINKML
+ - 4 # LED output FLASH1
+ - 5 # LED output FLASH2
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include
+ led-controller {
+ compatible = "mediatek,mt6360-led";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ multi-led@0 {
+ reg = <0>;
+ function = LED_FUNCTION_INDICATOR;
+ color = ;
+ led-max-microamp = <24000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ led@0 {
+ reg = <0>;
+ color = ;
+ };
+ led@1 {
+ reg = <1>;
+ color = ;
+ };
+ led@2 {
+ reg = <2>;
+ color = ;
+ };
+ };
+ led@3 {
+ reg = <3>;
+ function = LED_FUNCTION_MOONLIGHT;
+ color = ;
+ led-max-microamp = <15>;
+ };
+ led@4 {
+ reg = <4>;
+ function = LED_FUNCTION_FLASH;
+ color = ;
+ function-enumerator = <1>;
+ led-max-microamp = <20>;
+ flash-max-microamp = <50>;
+ flash-max-timeout-us = <1024000>;
+ };
+ led@5 {
+ reg = <5>;
+ function = LED_FUNCTION_FLASH;
+ color = ;
+ function-enumerator = <2>;
+ led-max-microamp = <20>;
+ flash-max-microamp = <50>;
+ flash-max-timeout-us = <1024000>;
+ };
+ };
+
+ - |
+
+ led-controller {
+ compatible = "mediatek,mt6360-led";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ function = LED_FUNCTION_INDICATOR;
+ color = ;
+ led-max-microamp = <24000>;
+ };
+ led@1 {
+ reg = <1>;
+ function = LED_FUNCTION_INDICATOR;
+ color = ;
+ led-max-microamp = <24000>;
+ };
+ led@2 {
+ reg = <2>;
+ function = LED_FUNCTION_INDICATOR;
+ color = ;
+ led-max-microamp = <24000>;
+ };
+ led@3 {
+ reg = <3>;
+ function = LED_FUNCTION_MOONLIGHT;
+ color = ;
+ led-max-microamp = <15>;
+ };
+ led@4 {
+ reg = <4>;
+ function = LED_FUNCTION_FLASH;
+ color = ;
+ function-enumerator = <1>;
+ led-max-microamp = <20>;
+ flash-max-microamp = <50>;
+ flash-max-timeout-us = <1024000>;
+ };
+ led@5 {
+ reg = <5>;
+ function = LED_FUNCTION_FLASH;
+ color = ;
+ function-enumerator = <2>;
+ led-max-microamp = <20>;
+ flash-max-microamp = <50>;
+ flash-max-timeout-us = <1024000>;
+ };
+ };
+...
--
2.7.4
[PATCH v12 3/5] dt-bindings: leds: Add LED_FUNCTION_MOONLIGHT definitions
From: Gene Chen Add LED_FUNCTION_MOONLIGHT definitions Signed-off-by: Gene Chen Acked-by: Jacek Anaszewski Acked-by: Rob Herring --- include/dt-bindings/leds/common.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/leds/common.h b/include/dt-bindings/leds/common.h index 52b619d..843e65d 100644 --- a/include/dt-bindings/leds/common.h +++ b/include/dt-bindings/leds/common.h @@ -78,6 +78,7 @@ #define LED_FUNCTION_INDICATOR "indicator" #define LED_FUNCTION_LAN "lan" #define LED_FUNCTION_MAIL "mail" +#define LED_FUNCTION_MOONLIGHT "moonlight" #define LED_FUNCTION_MTD "mtd" #define LED_FUNCTION_PANIC "panic" #define LED_FUNCTION_PROGRAMMING "programming" -- 2.7.4
[PATCH v12 0/5] leds: mt6360: Add LED driver for MT6360
This patch series add MT6360 LED support contains driver and binding document Gene Chen (5) leds: flash: Add flash registration with undefined CONFIG_LEDS_CLASS_FLASH leds: flash: Fix multicolor no-ops registration by return 0 dt-bindings: leds: Add LED_COLOR_ID_MOONLIGHT definitions dt-bindings: leds: Add bindings for MT6360 LED leds: mt6360: Add LED driver for MT6360 Documentation/devicetree/bindings/leds/leds-mt6360.yaml | 159 +++ drivers/leds/Kconfig| 13 drivers/leds/Makefile |1 drivers/leds/leds-mt6360.c | 827 include/dt-bindings/leds/common.h |1 include/linux/led-class-flash.h | 42 include/linux/led-class-multicolor.h| 42 7 files changed, 1049 insertions(+), 36 deletions(-) changelogs between v1 & v2 - add led driver with mfd changelogs between v2 & v3 - independent add led driver - add dt-binding document - refactor macros definition for easy to debug - parse device tree by fwnode - use devm*ext to register led class device changelogs between v3 & v4 - fix binding document description - use GENMASK and add unit postfix to definition - isink register led class device changelogs between v4 & v5 - change rgb isink to multicolor control - add binding reference to mfd yaml changelogs between v5 & v6 - Use DT to decide RGB LED is multicolor device or indicator device only changelogs between v6 & v7 - Add binding multicolor device sample code - Add flash ops mutex lock - Remove V4L2 init with indicator device changelogs between v7 & v8 - Add mutex for led fault get ops - Fix flash and multicolor no-ops return 0 - Add LED_FUNCTION_MOONLIGHT changelogs between v8 & v9 - reuse api in flash and multicolor header changelogs between v9 & v10 - add comment for reuse registration functions in flash and multicolor changelogs between v10 & v11 - match dt-binding reg property comment to the functionality name - remove exist patch in linux-next - dicide multicolor channel by color definitiion changelogs between v11 & v12 - Fix print size_t by %lu - Fix dt-binding name regular experssion
[PATCH] serial: 8250_omap: Avoid FIFO corruption caused by MDR1 access
It has been observed that once per 300-1300 port openings the first
transmitted byte is being corrupted on AM3352 ("v" written to FIFO appeared
as "e" on the wire). It only happened if single byte has been transmitted
right after port open, which means, DMA is not used for this transfer and
the corruption never happened afterwards.
Therefore I've carefully re-read the MDR1 errata (link below), which says
"when accessing the MDR1 registers that causes a dummy under-run condition
that will freeze the UART in IrDA transmission. In UART mode, this may
corrupt the transferred data". Strictly speaking,
omap_8250_mdr1_errataset() performs a read access and if the value is the
same as should be written, exits without errata-recommended FIFO reset.
A brief check of the serial_omap_mdr1_errataset() from the competing
omap-serial driver showed it has no read access of MDR1. After removing the
read access from omap_8250_mdr1_errataset() the data corruption never
happened any more.
Link: https://www.ti.com/lit/er/sprz360i/sprz360i.pdf
Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver")
Cc: sta...@vger.kernel.org
Signed-off-by: Alexander Sverdlin
---
drivers/tty/serial/8250/8250_omap.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 562087df7d33..0cc6d35a0815 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -184,11 +184,6 @@ static void omap_8250_mdr1_errataset(struct uart_8250_port
*up,
struct omap8250_priv *priv)
{
u8 timeout = 255;
- u8 old_mdr1;
-
- old_mdr1 = serial_in(up, UART_OMAP_MDR1);
- if (old_mdr1 == priv->mdr1)
- return;
serial_out(up, UART_OMAP_MDR1, priv->mdr1);
udelay(2);
--
2.29.2
Re: [PATCH v1 bpf-next 03/11] tcp: Migrate TCP_ESTABLISHED/TCP_SYN_RECV sockets in accept queues.
From: Martin KaFai Lau Date: Wed, 9 Dec 2020 17:53:19 -0800 > On Thu, Dec 10, 2020 at 01:57:19AM +0900, Kuniyuki Iwashima wrOAote: > [ ... ] > > > > > > I think it is a bit complex to pass the new listener from > > > > > reuseport_detach_sock() to inet_csk_listen_stop(). > > > > > > > > > > __tcp_close/tcp_disconnect/tcp_abort > > > > > |-tcp_set_state > > > > > | |-unhash > > > > > | |-reuseport_detach_sock (return nsk) > > > > > |-inet_csk_listen_stop > > > > Picking the new listener does not have to be done in > > > > reuseport_detach_sock(). > > > > > > > > IIUC, it is done there only because it prefers to pick > > > > the last sk from socks[] when bpf prog is not attached. > > > > This seems to get into the way of exploring other potential > > > > implementation options. > > > > > > Yes. > > > This is just idea, but we can reserve the last index of socks[] to hold > > > the > > > last 'moved' socket in reuseport_detach_sock() and use it in > > > inet_csk_listen_stop(). > > > > > > > > > > Merging the discussion on the last socks[] pick from another thread: > > > > > > > > > > I think most applications start new listeners before closing > > > > > listeners, in > > > > > this case, selecting the moved socket as the new listener works well. > > > > > > > > > > > > > > > > That said, if it is still desired to do a random pick by kernel when > > > > > > there is no bpf prog, it probably makes sense to guard it in a > > > > > > sysctl as > > > > > > suggested in another reply. To keep it simple, I would also keep > > > > > > this > > > > > > kernel-pick consistent instead of request socket is doing something > > > > > > different from the unhash path. > > > > > > > > > > Then, is this way better to keep kernel-pick consistent? > > > > > > > > > > 1. call reuseport_select_migrated_sock() without sk_hash from any > > > > > path > > > > > 2. generate a random number in reuseport_select_migrated_sock() > > > > > 3. pass it to __reuseport_select_sock() only for select-by-hash > > > > > (4. pass 0 as sk_hash to bpf_run_sk_reuseport not to use it) > > > > > 5. do migration per queue in inet_csk_listen_stop() or per request > > > > > in > > > > > receive path. > > > > > > > > > > I understand it is beautiful to keep consistensy, but also think > > > > > the kernel-pick with heuristic performs better than random-pick. > > > > I think discussing the best kernel pick without explicit user input > > > > is going to be a dead end. There is always a case that > > > > makes this heuristic (or guess) fail. e.g. what if multiple > > > > sk(s) being closed are always the last one in the socks[]? > > > > all their child sk(s) will then be piled up at one listen sk > > > > because the last socks[] is always picked? > > > > > > There can be such a case, but it means the newly listened sockets are > > > closed earlier than old ones. > > > > > > > > > > Lets assume the last socks[] is indeed the best for all cases. Then why > > > > the in-progress req don't pick it this way? I feel the implementation > > > > is doing what is convenient at that point. And that is fine, I think > > > > > > In this patchset, I originally assumed four things: > > > > > > migration should be done > > > (i) from old to new > > > (ii) to redistribute requests evenly as possible > > > (iii) to keep the order of requests in the queue > > > (resulting in splicing queues) > > > (iv) in O(1) for scalability > > > (resulting in fix-up rsk_listener approach) > > > > > > I selected the last socket in unhash path to satisfy above four because > > > the > > > last socket changes at every close() syscall if application closes from > > > older socket. > > > > > > But in receiving ACK or retransmitting SYN+ACK, we cannot get the last > > > 'moved' socket. Even if we reserve the last 'moved' socket in the last > > > index by the idea above, we cannot sure the last socket is changed after > > > close() for each req->listener. For example, we have listeners A, B, C, > > > and > > > D, and then call close(A) and close(B), and receive the final ACKs for A > > > and B, then both of them are assigned to C. In this case, A for D and B > > > for > > > C is desired. So, selecting the last socket in socks[] for incoming > > > requests cannnot realize (ii). > > > > > > This is why I selected the last moved socket in unhash path and a random > > > listener in receive path. > > > > > > > > > > for kernel-pick, it should just go for simplicity and stay with > > > > the random(/hash) pick instead of pretending the kernel knows the > > > > application must operate in a certain way. It is fine > > > > that the pick was wrong, the kernel will eventually move the > > > > childs/reqs to the survived listen sk. > > > > > > Exactly. Also the heuristic way is not fair for every application. > > > > > > After reading below idea (migrated_sk), I think random-pick is better > > > at
Re: [f2fs-dev] [PATCH] fs: f2fs: fix potential shift-out-of-bounds error in sanity_check_raw_super()
Jaegeuk, Could you please help to add signed-off of Anant manually in f2fs: fix shift-out-of-bounds in sanity_check_raw_super() Thanks, On 2020/12/10 10:14, Anant Thazhemadam wrote: On 10/12/20 7:40 am, Chao Yu wrote: On 2020/12/10 10:00, Anant Thazhemadam wrote: On 10/12/20 7:16 am, Chao Yu wrote: Hi Anant, I've posted a patch a little earlier. :P https://lore.kernel.org/linux-f2fs-devel/20201209084936.31711-1-yuch...@huawei.com/T/#u Ah well, that's alright, especially considering that your patch looks better. Glad that bug has been fixed nonetheless. :) Anyway, thanks a lot for taking time to fix f2fs bug. :) I prefer to add your Signed-off-by into "f2fs: fix shift-out-of-bounds in sanity_check_raw_super()" if you don't mind. Sure, I'd appreciate that. Thank you! :D Thanks, Anant .
Re: [PATCH] perf test: Skip test 68 for Powerpc
On 12/9/20 11:19 PM, Arnaldo Carvalho de Melo wrote:
Em Tue, Dec 08, 2020 at 10:32:33PM +0530, Ravi Bangoria escreveu:
On 12/8/20 8:13 PM, Thomas Richter wrote:
On 12/7/20 5:35 PM, Arnaldo Carvalho de Melo wrote:
Em Tue, Nov 24, 2020 at 03:04:53PM +0530, Ravi Bangoria escreveu:
On 11/19/20 7:20 PM, Kajol Jain wrote:
Commit ed21d6d7c48e6e ("perf tests: Add test for PE binary format support")
adds a WINDOWS EXE file named tests/pe-file.exe, which is
examined by the test case 'PE file support'. As powerpc doesn't support
it, we are skipping this test.
Result in power9 platform before this patach:
[command]# ./perf test -F 68
68: PE file support : Failed!
Result in power9 platform after this patch:
[command]# ./perf test -F 68
68: PE file support : Skip
Signed-off-by: Kajol Jain
Reviewed-by: Ravi Bangoria
But why is it failing? I.e. what is that
perf test -v -F 68
outputs?
Using 'perf report' on a perf.data file containing samples in such
binaries, collected on x86 should work on whatever workstation a
developer uses.
Say, on a MacBook aarch64 one can look at a perf.data file collected on
a x86_64 system where Wine running a PE binary was present.
What is the distro you are using?
I observed the same issue on s390 but this was fixed for fedora33 somehow.
The error just went away after a dnf update
[root@m35lp76 perf]# cat /etc/fedora-release
Fedora release 33 (Thirty Three)
[root@m35lp76 perf]# ./perf test -F 68
68: PE file support : Ok
[root@m35lp76 perf]#
However on my fedora32 machine it still fails:
[root@t35lp46 perf]# cat /etc/fedora-release
Fedora release 32 (Thirty Two)
[root@t35lp46 perf]# ./perf test -F 68
68: PE file support : FAILED!
[root@t35lp46 perf]#
Note that I am running the same kernel on both machines: linux 5.10.0rc7
downloaded
this morning.
Ok that's interesting. I don't see that on powerpc.
Fedora 32 with 5.10.0-rc2+ kernel:
$ ./perf test -vv -F 68
68: PE file support :
--- start ---
filename__read_build_id: cannot read ./tests/pe-file.exe bfd file.
FAILED tests/pe-file-parsing.c:40 Failed to read build_id
end
PE file support: FAILED!
Fedora 33 with 5.10.0-rc3 kernel:
$ ./perf test -vv -F 68
68: PE file support :
--- start ---
filename__read_build_id: cannot read ./tests/pe-file.exe bfd file.
FAILED tests/pe-file-parsing.c:40 Failed to read build_id
end
PE file support: FAILED!
Ubuntu 18.04.5 with 4.15.0-126-generic kernel:
$ ./perf test -vv -F 68
68: PE file support :
--- start ---
filename__read_build_id: cannot read ./tests/pe-file.exe bfd file.
FAILED tests/pe-file-parsing.c:41 Failed to read build_id
end
PE file support: FAILED!
I assumed bfd is not capable to parse PE files on powerpc. Though,
I didn't check it in more detail. I'll look into it tomorrow.
Humm, so this is something related to installation? I.e. that
pe-file.exe isn't being found...
It first assumes that the developers are in the tools/perf/ directory,
can you please add the patch below and see if it helps?
I'm using upstream perf from tools/perf/
I checked bfd code and it's bfd_check_format() who is returning error
"bfd_error_file_not_recognized".
I cross verified with objdump as well:
On x86:
$ objdump -d ./tests/pe-file.exe
./tests/pe-file.exe: file format pei-x86-64
Disassembly of section .text:
00401000 <__mingw_invalidParameterHandler>:
401000: c3 retq
401001: 66 66 2e 0f 1f 84 00data16 nopw %cs:0x0(%rax,%rax,1)
401008: 00 00 00 00
40100c: 0f 1f 40 00 nopl 0x0(%rax)
On powerpc:
$ objdump -d ./tests/pe-file.exe
objdump: ./tests/pe-file.exe: file format not recognized
Objdump is also returning *same* error.
I dig more into bfd logs and found that Powerpc PE support was removed
recently (Jul 2020) with this commit:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=fe49679d5193f6ff7cfd333e30883d293112a3d1
Ravi
Re: [linux-safety] [PATCH] kernel: trace: Remove deadstore in trace_uprobe.c
On Wed, Dec 9, 2020 at 2:17 PM Milan Lakhani
wrote:
>
> In trace_uprobe.c, trace_uprobe_create assigns ret to 0 but then never
> uses this value.
>
Milan, the patch makes sense, but I fear you did not run
./scripts/get_maintainers.pl because you did not include any specific
maintainer as recipient.
The patch subject could be: remove unneeded initialization (instead of
the very generic "dead store" term).
It is also interesting to see who added this initialization; was it
unneeded since the existence of this function, did it become obsolete
at some point in time due to refactoring?
Run ./scripts/get_maintainers.pl and please CC: me; then you will get
your Reviewed-by: tag.
Lukas
> Signed-off-by: Milan Lakhani
> ---
> kernel/trace/trace_uprobe.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
> index 3cf7128..c7c7070 100644
> --- a/kernel/trace/trace_uprobe.c
> +++ b/kernel/trace/trace_uprobe.c
> @@ -541,7 +541,6 @@ static int trace_uprobe_create(int argc, const char
> **argv)
> bool is_return = false;
> int i, ret;
>
> - ret = 0;
> ref_ctr_offset = 0;
>
> switch (argv[0][0]) {
> --
> 2.7.4
>
[PATCH] arm64: topology: Drop the useless update to per-cpu cycles
The previous call to update_freq_counters_refs() has already updated the
per-cpu variables, don't overwrite them with the same value again.
Fixes: 4b9cf23c179a ("arm64: wrap and generalise counter read functions")
Signed-off-by: Viresh Kumar
---
arch/arm64/kernel/topology.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index c8308befdb1e..f6faa697e83e 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -314,7 +314,7 @@ void topology_scale_freq_tick(void)
if (unlikely(core_cnt <= prev_core_cnt ||
const_cnt <= prev_const_cnt))
- goto store_and_exit;
+ return;
/*
* /\corearch_max_freq_scale
@@ -331,10 +331,6 @@ void topology_scale_freq_tick(void)
scale = min_t(unsigned long, scale, SCHED_CAPACITY_SCALE);
this_cpu_write(freq_scale, (unsigned long)scale);
-
-store_and_exit:
- this_cpu_write(arch_core_cycles_prev, core_cnt);
- this_cpu_write(arch_const_cycles_prev, const_cnt);
}
#ifdef CONFIG_ACPI_CPPC_LIB
--
2.25.0.rc1.19.g042ed3e048af
Re: [PATCH net-next 3/7] net: hns3: add support for forwarding packet to queues of specified TC when flow director rule hit
On Thu, 2020-12-10 at 11:42 +0800, Huazhong Tan wrote:
> From: Jian Shen
>
> For some new device, it supports forwarding packet to queues
> of specified TC when flow director rule hit. So extend the
> command handle to support it.
>
...
> static int hclge_config_action(struct hclge_dev *hdev, u8 stage,
> struct hclge_fd_rule *rule)
> {
> + struct hclge_vport *vport = hdev->vport;
> + struct hnae3_knic_private_info *kinfo = >nic.kinfo;
> struct hclge_fd_ad_data ad_data;
>
> + memset(_data, 0, sizeof(struct hclge_fd_ad_data));
> ad_data.ad_id = rule->location;
>
> if (rule->action == HCLGE_FD_ACTION_DROP_PACKET) {
> ad_data.drop_packet = true;
> - ad_data.forward_to_direct_queue = false;
> - ad_data.queue_id = 0;
> + } else if (rule->action == HCLGE_FD_ACTION_SELECT_TC) {
> + ad_data.override_tc = true;
> + ad_data.queue_id =
> + kinfo->tc_info.tqp_offset[rule->tc];
> + ad_data.tc_size =
> + ilog2(kinfo->tc_info.tqp_count[rule->tc]);
In the previous patch you copied this info from mqprio, which is an
egress qdisc feature, this patch is clearly about rx flow director, I
think the patch is missing some context otherwise it doesn't make any
sense.
> } else {
> - ad_data.drop_packet = false;
> ad_data.forward_to_direct_queue = true;
> ad_data.queue_id = rule->queue_id;
> }
> @@ -5937,7 +5950,7 @@ static int hclge_add_fd_entry(struct
> hnae3_handle *handle,
> return -EINVAL;
> }
>
> - action = HCLGE_FD_ACTION_ACCEPT_PACKET;
> + action = HCLGE_FD_ACTION_SELECT_QUEUE;
> q_index = ring;
> }
>
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
> b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
> index b3c1301..a481064 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
> @@ -572,8 +572,9 @@ enum HCLGE_FD_PACKET_TYPE {
> };
>
> enum HCLGE_FD_ACTION {
> - HCLGE_FD_ACTION_ACCEPT_PACKET,
> + HCLGE_FD_ACTION_SELECT_QUEUE,
> HCLGE_FD_ACTION_DROP_PACKET,
> + HCLGE_FD_ACTION_SELECT_TC,
what is SELECT_TC ? you never actually write this value anywhere in
this patch.
[PATCH v2] dt-bindings: usb: Add new compatible string for AM64 SoC
Add compatible string in j721e-usb binding file as the same USB subsystem is present in AM64. Signed-off-by: Aswath Govindraju Acked-by: Roger Quadros --- Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml index 388245b91a55..453587f6d304 100644 --- a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml +++ b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml @@ -11,8 +11,11 @@ maintainers: properties: compatible: -items: - - const: ti,j721e-usb +anyOf: + - items: + - const: ti,j721e-usb + - items: + - const: ti,am64-usb reg: description: module registers -- 2.17.1
[PATCH v4 6/6] MAINTAINERS: add maintainer for i.MX8qxp DPU DRM driver
Add myself as the maintainer of the i.MX8qxp DPU DRM driver. Signed-off-by: Liu Ying --- v3->v4: * No change. v2->v3: * No change. v1->v2: * No change. MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 970d9ce..dee4586 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5834,6 +5834,15 @@ F: Documentation/devicetree/bindings/display/imx/ F: drivers/gpu/drm/imx/ F: drivers/gpu/ipu-v3/ +DRM DRIVERS FOR FREESCALE i.MX8QXP +M: Liu Ying +L: dri-de...@lists.freedesktop.org +S: Maintained +F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml +F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml +F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml +F: drivers/gpu/drm/imx/dpu/ + DRM DRIVERS FOR GMA500 (Poulsbo, Moorestown and derivative chipsets) M: Patrik Jakobsson L: dri-de...@lists.freedesktop.org -- 2.7.4
[PATCH v4 1/6] dt-bindings: display: imx: Add i.MX8qxp/qm DPU binding
This patch adds bindings for i.MX8qxp/qm Display Processing Unit. Reviewed-by: Rob Herring Signed-off-by: Liu Ying --- Note that this depends on the 'two cell binding' clock patch set which has already landed in Shawn's i.MX clk/imx git branch. Otherwise, imx8-lpcg.h won't be found. v3->v4: * Improve compatible property by using enum instead of oneOf+const. (Rob) * Add Rob's R-b tag. v2->v3: * No change. v1->v2: * Fix yamllint warnings. * Require bypass0 and bypass1 clocks for both i.MX8qxp and i.MX8qm, as the display controller subsystem spec does say that they exist. * Use new dt binding way to add clocks in the example. * Trivial tweaks for the example. .../bindings/display/imx/fsl,imx8qxp-dpu.yaml | 416 + 1 file changed, 416 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml new file mode 100644 index ..817c7f3 --- /dev/null +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml @@ -0,0 +1,416 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX8qm/qxp Display Processing Unit + +maintainers: + - Liu Ying + +description: | + The Freescale i.MX8qm/qxp Display Processing Unit(DPU) is comprised of two + main components that include a blit engine for 2D graphics accelerations + and a display controller for display output processing, as well as a command + sequencer. + +properties: + compatible: +enum: + - fsl,imx8qxp-dpu + - fsl,imx8qm-dpu + + reg: +maxItems: 1 + + interrupts: +items: + - description: | + store9 shadow load interrupt(blit engine) + - description: | + store9 frame complete interrupt(blit engine) + - description: | + store9 sequence complete interrupt(blit engine) + - description: | + extdst0 shadow load interrupt + (display controller, content stream 0) + - description: | + extdst0 frame complete interrupt + (display controller, content stream 0) + - description: | + extdst0 sequence complete interrupt + (display controller, content stream 0) + - description: | + extdst4 shadow load interrupt + (display controller, safety stream 0) + - description: | + extdst4 frame complete interrupt + (display controller, safety stream 0) + - description: | + extdst4 sequence complete interrupt + (display controller, safety stream 0) + - description: | + extdst1 shadow load interrupt + (display controller, content stream 1) + - description: | + extdst1 frame complete interrupt + (display controller, content stream 1) + - description: | + extdst1 sequence complete interrupt + (display controller, content stream 1) + - description: | + extdst5 shadow load interrupt + (display controller, safety stream 1) + - description: | + extdst5 frame complete interrupt + (display controller, safety stream 1) + - description: | + extdst5 sequence complete interrupt + (display controller, safety stream 1) + - description: | + disengcfg0 shadow load interrupt + (display controller, display stream 0) + - description: | + disengcfg0 frame complete interrupt + (display controller, display stream 0) + - description: | + disengcfg0 sequence complete interrupt + (display controller, display stream 0) + - description: | + framegen0 programmable interrupt0 + (display controller, display stream 0) + - description: | + framegen0 programmable interrupt1 + (display controller, display stream 0) + - description: | + framegen0 programmable interrupt2 + (display controller, display stream 0) + - description: | + framegen0 programmable interrupt3 + (display controller, display stream 0) + - description: | + signature0 shadow load interrupt + (display controller, display stream 0) + - description: | + signature0 measurement valid interrupt + (display controller, display stream 0) + - description: | + signature0 error condition interrupt + (display controller, display stream 0) + - description: | + disengcfg1 shadow load interrupt + (display controller, display stream 1) + - description: | + disengcfg1 frame complete interrupt + (display controller, display stream 1) + - description: | +
[PATCH v4 4/6] drm/atomic: Avoid unused-but-set-variable warning on for_each_old_plane_in_state
Artifically use 'plane' and 'old_plane_state' to avoid 'not used' warning. The precedent has already been set by other macros in the same file. Acked-by: Daniel Vetter Signed-off-by: Liu Ying --- v3->v4: * Add Daniel's A-b tag. v2->v3: * Add a missing blank line. v1->v2: * No change. include/drm/drm_atomic.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h index 54e051a..2e087d7 100644 --- a/include/drm/drm_atomic.h +++ b/include/drm/drm_atomic.h @@ -888,7 +888,10 @@ void drm_state_dump(struct drm_device *dev, struct drm_printer *p); (__i)++) \ for_each_if ((__state)->planes[__i].ptr && \ ((plane) = (__state)->planes[__i].ptr, \ - (old_plane_state) = (__state)->planes[__i].old_state, 1)) + (void)(plane) /* Only to avoid unused-but-set-variable warning */, \ + (old_plane_state) = (__state)->planes[__i].old_state, \ + (void)(old_plane_state) /* Only to avoid unused-but-set-variable warning */, 1)) + /** * for_each_new_plane_in_state - iterate over all planes in an atomic update * @__state: drm_atomic_state pointer -- 2.7.4
[PATCH v4 3/6] dt-bindings: display: imx: Add i.MX8qxp/qm DPR channel binding
This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Channel.
Reviewed-by: Rob Herring
Signed-off-by: Liu Ying
---
Note that this depends on the 'two cell binding' clock patch set which has
already landed in Shawn's i.MX clk/imx git branch. Otherwise, imx8-lpcg.h
won't be found.
v3->v4:
* Improve compatible property by using enum instead of oneOf+const. (Rob)
* Add Rob's R-b tag.
v2->v3:
* No change.
v1->v2:
* Use new dt binding way to add clocks in the example.
.../bindings/display/imx/fsl,imx8qxp-dprc.yaml | 87 ++
1 file changed, 87 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
diff --git
a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
new file mode 100644
index ..9e05c83
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dprc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Display Prefetch Resolve Channel
+
+maintainers:
+ - Liu Ying
+
+description: |
+ The i.MX8qm/qxp Display Prefetch Resolve Channel(DPRC) is an engine which
+ fetches display data before the display pipeline needs the data to drive
+ pixels in the active display region. This data is transformed, or resolved,
+ from a variety of tiled buffer formats into linear format, if needed.
+ The DPR works with a double bank memory structure. This memory structure is
+ implemented in the Resolve Tile Memory(RTRAM) and the banks are referred to
+ as A and B. Each bank is either 4 or 8 lines high depending on the source
+ frame buffer format.
+
+properties:
+ compatible:
+enum:
+ - fsl,imx8qxp-dpr-channel
+ - fsl,imx8qm-dpr-channel
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+items:
+ - description: apb clock
+ - description: b clock
+ - description: rtram clock
+
+ clock-names:
+items:
+ - const: apb
+ - const: b
+ - const: rtram
+
+ fsl,sc-resource:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: The SCU resource ID associated with this DPRC instance.
+
+ fsl,prgs:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+description: |
+ List of phandle which points to Prefetch Resolve Gaskets(PRGs)
+ associated with this DPRC instance.
+
+ power-domains:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - fsl,sc-resource
+ - fsl,prgs
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+dpr-channel@5610 {
+compatible = "fsl,imx8qxp-dpr-channel";
+reg = <0x5610 0x1>;
+interrupts = ;
+clocks = <_dpr1_lpcg IMX_LPCG_CLK_4>,
+ <_dpr1_lpcg IMX_LPCG_CLK_5>,
+ <_rtram1_lpcg IMX_LPCG_CLK_0>;
+clock-names = "apb", "b", "rtram";
+fsl,sc-resource = ;
+fsl,prgs = <_prg4>, <_prg5>;
+power-domains = < IMX_SC_R_DC_0>;
+};
--
2.7.4
[PATCH v4 2/6] dt-bindings: display: imx: Add i.MX8qxp/qm PRG binding
This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Gasket.
Reviewed-by: Rob Herring
Signed-off-by: Liu Ying
---
Note that this depends on the 'two cell binding' clock patch set which has
already landed in Shawn's i.MX clk/imx git branch. Otherwise, imx8-lpcg.h
won't be found.
v3->v4:
* Improve compatible property by using enum instead of oneOf+const. (Rob)
* Add Rob's R-b tag.
v2->v3:
* No change.
v1->v2:
* Use new dt binding way to add clocks in the example.
.../bindings/display/imx/fsl,imx8qxp-prg.yaml | 60 ++
1 file changed, 60 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
new file mode 100644
index ..3ff46e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-prg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Display Prefetch Resolve Gasket
+
+maintainers:
+ - Liu Ying
+
+description: |
+ The i.MX8qm/qxp Prefetch Resolve Gasket (PRG) is a gasket interface between
+ RTRAM controller and Display Controller. The main function is to convert
+ the AXI interface to the RTRAM interface, which includes re-mapping the
+ ARADDR to a RTRAM address.
+
+properties:
+ compatible:
+enum:
+ - fsl,imx8qxp-prg
+ - fsl,imx8qm-prg
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: rtram clock
+ - description: apb clock
+
+ clock-names:
+items:
+ - const: rtram
+ - const: apb
+
+ power-domains:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+prg@5604 {
+compatible = "fsl,imx8qxp-prg";
+reg = <0x5604 0x1>;
+clocks = <_prg0_lpcg IMX_LPCG_CLK_0>,
+ <_prg0_lpcg IMX_LPCG_CLK_4>;
+clock-names = "rtram", "apb";
+power-domains = < IMX_SC_R_DC_0>;
+};
--
2.7.4
